Utforma en säker lösning för RAG-slutsatsdragning med flera hyresgäster
Retrieval-Augmented Generation (RAG) är ett mönster för att skapa program som använder grundläggande modeller för att resonera över upphovsrättsskyddad information eller andra data som inte är offentligt tillgängliga på Internet. I allmänhet anropar ett klientprogram ett orkestreringslager som hämtar relevant information från ett datalager, till exempel en vektordatabas. Orkestreringslagret skickar dessa data som en del av kontexten som grunddata till den grundläggande modellen.
En multitenantlösning används av flera kunder. Varje kund eller klientorganisation består av flera användare från samma organisation, företag eller grupp. I scenarier med flera klienter måste du se till att klientorganisationer, eller enskilda personer i klientorganisationer, bara kan införliva grunddata som de har behörighet att komma åt.
Det finns bekymmer med multitenans förutom att säkerställa att användarna endast får åtkomst till den information de har behörighet att komma åt. Den här artikeln fokuserar dock på den aspekten av multihyresgäststrukturen. Den här artikeln börjar med en översikt över RAG-arkitekturer med en enda klientorganisation. Den beskriver de utmaningar som du kan stöta på i flera miljöer med RAG och några vanliga metoder att ta. Den beskriver också överväganden och rekommendationer för flera innehavare för förbättrad säkerhet.
Not
Den här artikeln beskriver flera funktioner som är specifika för Azure OpenAI Service, till exempel funktionen Azure OpenAI On Your Data. Du kan dock tillämpa de flesta av de principer som beskrivs i den här artikeln på grundläggande AI-modeller på valfri plattform.
RAG-arkitektur med en enda klientorganisation med en orkestrerare
Arbetsflöde
I den här RAG-arkitekturen med en enda klientorganisation hämtar en orkestrerare relevanta proprietära data för klientorganisationen från datalager och tillhandahåller den som grundläggande data till den grundläggande modellen. Följande steg beskriver ett arbetsflöde på hög nivå.
- En användare skickar en begäran till det intelligenta webbprogrammet.
- En identitetsprovider autentiserar beställaren.
- Det intelligenta programmet anropar orchestrator-API:et med användarens fråga och auktoriseringstoken för användaren.
- Orkestreringslogik extraherar användarens fråga från begäran och anropar lämpligt datalager för att hämta relevanta grunddata för frågan. Grunddata läggs till i prompten som skickas till den grundläggande modellen, som en modell som exponeras i Azure OpenAI, i nästa steg.
- Orkestreringslogiken ansluter till grundmodellens slutsatsdragnings-API och skickar uppmaningen som innehåller hämtade grunddata. Resultaten returneras till det intelligenta programmet.
Mer information finns i Design och utveckla en RAG-lösning.
RAG-arkitektur med en enda klientorganisation med direkt dataåtkomst
Den här varianten av RAG-arkitekturen med en enda klientorganisation använder funktionen På dina data i Azure OpenAI för att integrera direkt med datalager som Azure AI Search. I den här arkitekturen har du antingen inte en egen orkestrerare eller så har orkestratorn färre ansvarsområden. Azure OpenAI-API:et anropar datalagret för att hämta grunddata och skickar dessa data till språkmodellen. Med den här metoden får du mindre kontroll över vilka jordningsdata som ska hämtas och hur relevanta dessa data är.
Not
Azure OpenAI hanteras av Microsoft. Den integreras med datalagret, men själva modellen integreras inte med datalagret. Modellen tar emot grunddata på samma sätt som när en orkestrerare hämtar data.
Arbetsflöde
I den här RAG-arkitekturen hämtar tjänsten som tillhandahåller den grundläggande modellen lämpliga proprietära klientdata från datalager och använder dessa data som grunddata till den grundläggande modellen. Följande steg beskriver ett arbetsflöde på hög nivå. De kursiviserade stegen är identiska med den tidigare RAG-arkitekturen med en enda klientorganisation som har ett orchestrator-arbetsflöde.
- En användare skickar en begäran till det intelligenta webbprogrammet.
- En identitetsprovider autentiserar beställaren.
- Det intelligenta programmet anropar Azure OpenAI med användarens fråga.
- Azure OpenAI ansluter till datalager som stöds, till exempel AI Search och Azure Blob Storage, för att hämta grunddata. Grunddata används som en del av kontexten när Azure OpenAI anropar OpenAI-språkmodellen. Resultaten returneras till det intelligenta programmet.
Om du vill använda den här arkitekturen i en lösning med flera klientorganisationer måste tjänsten som har direkt åtkomst till grunddata, till exempel Azure OpenAI, ha stöd för den logik för flera klientorganisationer som din lösning kräver.
Flertenantarkitektur i RAG-arkitektur
I lösningar för flera klientorganisationer kan klientdata finnas i ett klientspecifikt lager eller samexistera med andra klienter i ett lagringslager för flera klienter. Data kan också finnas i en lagringsplats som delas mellan klienter. Endast data som användaren har behörighet att komma åt ska användas som grunddata. Användaren bör endast se gemensamma data eller data som gäller alla hyresgäster, eller data från deras hyresgäst som filtreras för att försäkra att de bara ser den data de har behörighet till.
Arbetsflöde
Följande steg beskriver ett arbetsflöde på hög nivå. De kursiviserade stegen är identiska med RAG-arkitektur med en enda klientorganisation med ett orchestrator- arbetsflöde.
- En användare skickar en begäran till det intelligenta webbprogrammet.
- En identitetsprovider autentiserar beställaren.
- Det intelligenta programmet anropar orchestrator-API:et med användarens fråga och auktoriseringstoken för användaren.
- Orkestreringslogik extraherar användarens fråga från begäran och anropar lämpliga datalager för att hämta klientauktoriserade, relevanta grunddata för frågan. Grunddata läggs till i uppmaningen som skickas till Azure OpenAI i nästa steg. Några eller alla av följande steg ingår:
- Orkestreringslogik hämtar grunddata från lämplig klientspecifik datalagerinstans och tillämpar eventuellt säkerhetsfiltreringsregler för att endast returnera de data som användaren har behörighet att komma åt.
- Orkestreringslogik hämtar lämplig klients grunddata från datalagret för flera klienter och tillämpar eventuellt säkerhetsfiltreringsregler för att endast returnera de data som användaren har behörighet att komma åt.
- Orkestreringslogik hämtar data från ett datalager som delas mellan klienter.
- Orkestreringslogiken ansluter till grundmodellens slutsatsdragnings-API och skickar uppmaningen som innehåller hämtade grunddata. Resultaten returneras till det intelligenta programmet.
Designöverväganden för data med flera klienter i RAG
Tänk på följande alternativ när du utformar din flertenant RAG-inferenslösning.
Välj en modell för butiksisolering
De två huvudsakliga arkitekturella tillvägagångssätt för lagring och data i scenarier med flera hyresgäster är lagringslösningar per hyresgäst och lösningar för flera hyresgäster. Dessa tillvägagångssätt är ett komplement till lagringsutrymmen som innehåller data som delas mellan hyresgäster. Din lösning för flera klientorganisationer kan använda en kombination av dessa metoder.
Butiker per kund
I butiker per hyresgäst har varje hyresgäst sin egen butik. Fördelarna med den här metoden omfattar både data och prestandaisolering. Varje klientorganisations data kapslas in i sitt eget lager. I de flesta datatjänster är de isolerade butikerna inte mottagliga för det bullriga granneproblemet för andra klienter. Den här metoden förenklar även kostnadsallokeringen eftersom hela kostnaden för en butiksdistribution kan hänföras till en enda klientorganisation.
Den här metoden kan innebära utmaningar som ökad hantering och driftkostnader och högre kostnader. Du bör inte använda den här metoden om du har ett stort antal små klienter, till exempel i scenarier från företag till konsument. Den här metoden kan också nå eller överskrida tjänstbegränsningar.
I det här AI-scenariot innebär ett lager per klientorganisation att nödvändiga grunddata för att få relevans i kontexten kommer från ett befintligt eller nytt datalager som endast innehåller grunddata för klientorganisationen. I den här topologin är databasinstansen den identifierare som används för varje hyresgäst.
Multitenant-butiker
I flera klientlager samexisterar flera klientorganisationers data i samma lager. Fördelarna med den här metoden inkluderar potentialen för kostnadsoptimering, möjligheten att hantera ett högre antal hyresgäster än modellen med separat lagring för varje hyresgäst, samt lägre hanteringskostnader på grund av det lägre antalet lagringsinstanser.
Utmaningarna med att använda delade lager är behovet av dataisolering och hantering, potentialen för bullriga grannens antimönsteroch mer komplex kostnadsallokering till klienter. Dataisolering är det viktigaste problemet när du använder den här metoden. Du måste implementera säkra metoder för att hjälpa till att säkerställa att klientorganisationer bara kan komma åt sina data. Datahantering kan också vara svårt om klientorganisationer har olika datalivscykler som kräver åtgärder, till exempel att skapa index enligt olika scheman.
Vissa plattformar har funktioner som du kan använda när du implementerar klientdataisolering i delade butiker. Azure Cosmos DB har till exempel inbyggt stöd för datapartitionering och horisontell partitionering. Det är vanligt att använda en klientidentifierare som en partitionsnyckel för att tillhandahålla viss isolering mellan klienter. Azure SQL och Azure Database for PostgreSQL – Flexibel server stöder säkerhet på radnivå. De här funktionerna används dock vanligtvis inte i lösningar med flera klientorganisationer eftersom du måste utforma lösningen kring dessa funktioner om du planerar att använda dem i din lagringsplats för flera klientorganisationer.
I samband med det här AI-scenariot samlas grunddata för alla klienter i samma datalager. Därför måste din fråga till datalagret innehålla en klientidentifierare för att säkerställa att svaren begränsas så att endast relevant data hämtas tillbaka inom kontexten för klienten.
Delade butiker
Lösningar för flera klienter delar ofta data mellan klienter. I ett exempel på en lösning för flera klienter för sjukvårdsdomänen kan en databas lagra allmän medicinsk information eller information som inte är specifik för klientorganisationen.
I det här AI-scenariot är datalagret allmänt tillgängligt och behöver inte filtrering baserat på specifika klienter eftersom data är relevanta och auktoriserade för alla klienter i systemet.
Identitet
Identity är en viktig aspekt av lösningar för flera klientorganisationer, inklusive RAG-lösningar med flera klientorganisationer. Det intelligenta programmet bör integreras med en identitetsprovider för att autentisera användarens identitet. RAG-lösningen för flera hyresgäster behöver en identitetskatalog som lagrar auktoritativa identiteter eller referenser till identiteter. Den här identiteten måste flöda genom begärandekedjan och tillåta underordnade tjänster, till exempel orkestreraren eller själva datalagret, för att identifiera användaren.
Du behöver också ett sätt att mappa en användare till en klientorganisation så att du kan ge åtkomst till dessa klientdata.
Definiera dina klient- och auktoriseringskrav
När du skapar en RAG-lösning med flera hyresgäster måste du definiera vad en hyresgäst är för din lösning. De två vanliga modellerna att välja mellan är modeller från företag till företag och från företag till konsument. Den modell som du väljer hjälper dig att avgöra vilka andra faktorer du bör tänka på när du skapar din lösning. Det är viktigt att förstå antalet klienter för att välja datalagermodell. Ett stort antal klienter kan kräva en modell som har flera klienter för varje butik. Ett mindre antal hyresgäster kan tillåta en butik-per-hyresgäst modell. Mängden data för varje klientorganisation är också viktig. Klienter som har stora mängder data kan hindra dig från att använda flera klientlager på grund av storleksbegränsningar i datalagret.
Om du tänker utöka en befintlig arbetsbelastning för att stödja det här AI-scenariot kanske du redan har fattat det här beslutet. Generellt sett kan du använda din befintliga datalagringstopologi för jordningsdata om datalagret kan ge tillräcklig relevans och uppfylla andra icke-funktionella krav. Men om du planerar att introducera nya komponenter, till exempel ett dedikerat vektorsökningsarkiv som ett dedikerat jordningslager, måste du fortfarande fatta det här beslutet. Tänk på faktorer som din aktuella distributionsstämpelstrategi, påverkan på programkontrollplanet och eventuella skillnader i datalivscykeln per klientorganisation, till exempel situationer där du betalar för prestanda.
När du har definierat vad en klientorganisation är för din lösning måste du definiera dina auktoriseringskrav för data. Hyresgäster har bara åtkomst till data om deras egen hyresgäst, men dina auktoriseringskrav kan vara mer detaljerade. I en sjukvårdslösning kan du till exempel ha regler som:
- En patient kan bara komma åt sina egna patientdata.
- En sjukvårdspersonal kan komma åt sina patienters data.
- En ekonomianvändare kan bara komma åt ekonomirelaterade data.
- En klinisk revisor kan se alla patienters data.
- Alla användare kan komma åt grundläggande medicinska kunskaper i ett delat datalager.
I ett dokumentbaserat RAG-program kanske du vill begränsa användarnas åtkomst till dokument baserat på ett taggningsschema eller känslighetsnivåer som tilldelats dokumenten.
När du har en definition av vad en klientorganisation är och har en tydlig förståelse för auktoriseringsreglerna använder du den informationen som krav för din datalagerlösning.
Datafiltrering
Att begränsa åtkomsten till endast de data som användarna har behörighet att komma åt kallas filtrering eller säkerhetstrimning. I ett RAG-scenario med flera klienter kan en användare mappas till en klientspecifik lagringsplats. Det betyder inte att användaren ska kunna komma åt allt data i den butiken. Definiera dina klient- och auktoriseringskrav diskuterar vikten av att definiera auktoriseringskrav för dina data. Du bör använda dessa auktoriseringsregler som grund för filtrering.
Du kan använda dataplattformsfunktioner som säkerhet på radnivå för att implementera filtrering. Eller så kan du behöva anpassad logik, data eller metadata. Dessa plattformsfunktioner används vanligtvis inte i lösningar med flera klientorganisationer eftersom du behöver utforma systemet kring dessa funktioner.
Kapsla in datalogik för flera klientorganisationer
Vi rekommenderar att du har ett API framför den lagringsmekanism som du använder. API:et fungerar som en gatekeeper som hjälper till att se till att användarna bara får åtkomst till information som de har behörighet att komma åt.
Användarnas åtkomst till data kan begränsas av:
- Användarens klientorganisation.
- Plattformsfunktioner.
- Anpassad säkerhetsfiltrering eller trimningsregler.
API-lagret bör:
- Dirigera frågan till ett klientspecifikt lager i en modell för butik per klientorganisation.
- Välj endast data från användarens klientorganisation i multitenanta miljöer.
- Använd lämplig identitet för en användare för att stödja plattformsaktiverad auktoriseringslogik.
- Tillämpa anpassad logik för säkerhetstrimning.
- Lagra åtkomstloggar för grundinformation i granskningssyfte.
Kod som behöver komma åt hyresgästdata bör inte ha möjlighet att fråga mot back-end-lagringar direkt. Alla begäranden om data ska flöda genom API-lagret. Det här API-lagret ger en enda styrnings- eller säkerhetspunkt ovanpå dina klientdata. Detta tillvägagångssätt förhindrar att autentiseringslogiken för dataåtkomst av hyresgäster och användare når andra delar av applikationen. Den här logiken är inkapslad i API-lagret. Den här inkapslingen gör lösningen enklare att validera och testa.
Sammanfattning
När du utformar en multitenant RAG-slutledningslösning måste du överväga hur du utformar grunddatalösningen för dina klienter. Förstå antalet klienter och mängden data per klient som du lagrar. Den här informationen hjälper dig att utforma din lösning för databostadshantering. Vi rekommenderar att du implementerar ett API-lager som kapslar in dataåtkomstlogik, inklusive logik för flera klientorganisationer och filtreringslogik.
Bidragsgivare
Microsoft ansvarar för denna artikel. Följande deltagare skrev den här artikeln.
Huvudförfattare:
- John Downs | Huvudprogramtekniker
- Daniel Scott-Raynsford | Sr. Partner Solution Architect, Data & AI
Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.