Guide för att utforma en säker lösning för RAG-slutsatsdragning med flera klientorganisationer

RAG (Retrieval-Augmented Generation) är ett mönster för att skapa program där grundläggande modeller används för att resonera över upphovsrättsskyddad information eller annan information som inte är offentligt tillgänglig 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 lösning för flera klienter används av flera kunder, där varje kund (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 individer inom klientorganisationer, bara kan införliva grunddata som de har behörighet att se.

Även om det finns problem med flera klientorganisationer utöver att se till att användarna bara får åtkomst till den information de ska se, fokuserar den här artikeln på den aspekten av flera klientorganisationer. Artikeln börjar med en översikt över RAG-arkitekturer för enskild klientorganisation, beskriver utmaningarna med flera klientorganisationer med RAG och några vanliga metoder att följa och avslutas med säkra överväganden och rekommendationer för flera klientorganisationer.

RAG-arkitektur med enskild klientorganisation med orchestrator

Figur 1. RAG-arkitektur med en klientorganisation

Arbetsflöde

I den här rag-arkitekturen för en enskild klientorganisation har en orkestrerare ansvaret att hämta relevanta proprietära klientdata från datalager och tillhandahålla dem som grunddata till den grundläggande modellen. Följande är ett arbetsflöde på hög nivå:

1. En användare skickar en begäran till det intelligenta webbprogrammet.
2. En identitetsprovider autentiserar beställaren.
3. Det intelligenta programmet anropar orchestrator-API:et med användarfrågan och auktoriseringstoken för användaren.
4. 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. Jordningsdata läggs till i uppmaningen som skickas till den grundläggande modellen, till exempel en modell som exponeras i Azure OpenAI, i nästa steg.
5. Orkestreringslogiken ansluter till grundmodellens slutsatsdragnings-API och skickar uppmaningen som innehåller hämtade grunddata. Resultaten returneras till det intelligenta programmet.

Mer information om RAG finns i Designa och utveckla en RAG-lösning.

RAG-arkitektur för enskild klientorganisation med direkt dataåtkomst

En variant av RAG-arkitekturen för en enskild klientorganisation utnyttjar Azure OpenAI-tjänstens möjlighet att integrera direkt med datalager som Azure 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 har ansvaret att anropa till datalagret för att hämta grunddata och skicka dessa data till språkmodellen. Du har i sin tur mindre kontroll över vilka jordningsdata som ska hämtas och relevansen för dessa data.

Figur 2. RAG-arkitektur med en enda klientorganisation med direkt dataåtkomst från Azure OpenAI-tjänsten

Arbetsflöde

I den här RAG-arkitekturen har tjänsten som tillhandahåller den grundläggande modellen ansvaret att hämta lämpliga proprietära klientdata från datalager och använda dessa data som grunddata till den grundläggande modellen. Följande är ett arbetsflöde på hög nivå (kursivt steg är identiska med RAG-arkitekturen för enskild klientorganisation med orchestrator-arbetsflödet):

1. En användare skickar en begäran till det intelligenta webbprogrammet.
2. En identitetsprovider autentiserar beställaren.
3. Det intelligenta programmet anropar sedan Azure OpenAI-tjänsten med användarfrågan.
4. Azure OpenAI-tjänsten ansluter till datalager som stöds, till exempel Azure AI Search och Azure Blob Storage för att hämta grunddata. Grunddata används som en del av kontexten när Azure OpenAI-tjänsten anropar OpenAI-språkmodellen. Resultaten returneras till det intelligenta programmet.

För att kunna överväga den här arkitekturen i en lösning med flera klientorganisationer måste tjänsten, till exempel Azure OpenAI, som har direkt åtkomst till grunddata ha stöd för den logik för flera klientorganisationer som krävs av din lösning.

Multitenancy 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. Det kan också finnas data i ett arkiv som delas mellan klienter. Endast data som användaren har behörighet att se ska användas som grunddata. Användarna bör endast se vanliga (alla klient) data eller data från sin klientorganisation med filtreringsregler som tillämpas för att säkerställa att de bara ser data som de har behörighet att se.

Bild 3: RAG-arkitektur – med flera klientorganisationer för datalager

Arbetsflöde

Det här arbetsflödet är detsamma som i RAG-arkitekturen för enskild klientorganisation med orchestrator förutom steg 4.

1. En användare skickar en begäran till det intelligenta webbprogrammet.
2. En identitetsprovider autentiserar beställaren.
3. Det intelligenta programmet anropar orchestrator-API:et med användarfrågan och auktoriseringstoken för användaren.
4. 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 är inblandade:
   1. Orkestreringslogik hämtar jordningsdata från lämplig klientspecifik datalagerinstans, vilket potentiellt kan tillämpa säkerhetsfiltreringsregler för att returnera endast de data som användaren har behörighet att komma åt.
   2. Orkestreringslogik hämtar rätt klientorganisations grunddata från datalagret för flera klienter, och kan eventuellt tillämpa regler för säkerhetsfiltrering för att endast returnera de data som användaren har behörighet att komma åt.
   3. Orkestreringslogik hämtar data från ett datalager som delas mellan klienter.
5. 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

Välja butiksisoleringsmodeller

Det finns två huvudsakliga arkitekturmetoder för lagring och data i scenarier med flera klienter: store-per-tenant och multitenant-butiker. Dessa metoder är utöver lager som innehåller data som delas mellan klienter. Det här avsnittet berör varje metod. Det bör noteras att multitenantlösningen kan använda en kombination av dessa metoder.

Lagra per klientorganisation

I store-per-tenant, som namnet antyder, har varje klientorganisation en 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.

Utmaningarna med den här metoden kan vara högre hanterings- och driftkostnader och högre kostnader. Den här metoden bör inte beaktas när det finns ett stort antal små klienter, till exempel scenarier från företag till konsument. Den här metoden kan också stöta på tjänstbegränsningarna.

I det här AI-scenariot skulle en lagring per klientorganisation innebära att de grunddata som krävs för att få relevans i kontexten skulle komma från ett befintligt eller nytt datalager som endast innehåller grunddata för klientorganisationen. I den här topologin är databasinstansen den diskriminerande som används per klientorganisation.

Multitenant-butiker

I flera klientlager samexisterar flera klientorganisationer i samma lager. Fördelarna med den här metoden är potentialen för kostnadsoptimering, möjligheten att hantera ett högre antal klienter än modellen för lagring per klientorganisation och lägre hanteringskostnader på grund av det lägre antalet butiksinstanser.

Utmaningarna med att använda delade lager är bland annat behovet av att säkerställa dataisolering, datahantering, risken för störningar i grannens antimönster och svårigheter att allokera kostnader till klienter. Att säkerställa dataisolering är det viktigaste problemet med den här metoden. Du har ansvaret för att implementera säkerhetsmetoden för att säkerställa att klientorganisationer endast kan komma åt sina data. Datahantering kan också vara en utmaning om klientorganisationer har olika datalivscykler som kan kräva åtgärder, till exempel att skapa index enligt olika scheman.

Vissa plattformar har funktioner som du kan dra nytta av när du implementerar klientdataisolering i delade butiker. Azure Cosmos DB har till exempel inbyggt stöd för partitionering och horisontell partitionering, och det är vanligt att använda en klientidentifierare som en partitionsnyckel för att tillhandahålla en viss nivå av isolering mellan klienter. Azure SQL och Postgres Flex har stöd för säkerhet på radnivå, men den här funktionen används inte ofta i lösningar med flera klienter eftersom du måste utforma din lösning kring dessa funktioner om du planerar att använda dem i ditt multitenantarkiv.

I det här AI-scenariot skulle det innebära att grunddata för alla klienter kommer i samma datalager, på ett sådant sätt att din fråga till datalagret måste innehålla en klientdiskriminering för att säkerställa att svaren begränsas för att endast ta tillbaka relevanta data inom klientorganisationens kontext.

Delade butiker

Lösningar för flera klienter har ofta data som delas mellan klienter. I ett exempel på en lösning för flera klienter för sjukvårdsdomänen kan det finnas en databas som lagrar allmän medicinsk information eller information som inte är klientspecifik.

I det här AI-scenariot skulle detta vara ett allmänt tillgängligt grunddatalager som inte specifikt behöver filtrering baserat på någon klientorganisation eftersom data är relevanta och auktoriserade för alla klienter i systemet.

Identitet

Identitet är en viktig aspekt av lösningar för flera klientorganisationer , inklusive säker RAG för flera klientorganisationer. Det intelligenta programmet bör integreras med en identitetsprovider (IdP) för att autentisera användarens identitet. Rag-lösningen för flera klientorganisationer behöver en identitetskatalog där antingen auktoritativa identiteter eller referenser till identiteter lagras. Den här identiteten måste flöda genom begärandekedjan så att underordnade tjänster som orkestreraren eller till och med själva datalagret kan 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 klienter måste du definiera vad en klientorganisation är för din lösning. De två vanliga modellerna att välja mellan är B2B (business-to-business) och business-to-consumer (B2C). Den här beslutsamheten hjälper dig att informera dig om områden som du bör tänka på när du utformar din lösning. Det är viktigt att förstå antalet klienter för att bestämma datalagringsmodellen. Ett stort antal klienter kan kräva en modell med flera klienter per butik, medan ett mindre antal kan tillåta en butik per klientorganisationsmodell. Mängden data per klientorganisation är också viktig. Om klientorganisationer har stora mängder data som kan hindra dig från att använda flera klientlager på grund av storleksbegränsningar i datalagret.

I befintliga arbetsbelastningar som utökas för att stödja det här AI-scenariot kanske du redan har gjort det här valet. Generellt sett kan du använda din befintliga datalagringstopologi för grunddata om datalagret kan ge tillräcklig relevans och uppfylla andra icke-funktionella krav. Men om du introducerar nya komponenter, till exempel ett dedikerat vektorsökningslager som ett dedikerat jordningslager, måste du fatta det här beslutet med hänsyn till faktorer som din nuvarande distributionsstämpelstrategi, påverkan på programkontrollplanet och eventuella skillnader i datalivscykeln per klientorganisation (till exempel situationer med betalning 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. Klientorganisationer kommer bara åt data från sin klientorganisation, 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 endast komma åt ekonomirelaterade data
• En klinisk revisor kan se alla patienters data
• Alla användare kan komma åt grundläggande medicinsk kunskap 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 angetts för dokument.

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.

Filtrering

Filtrering, även kallat säkerhetstrimning, syftar på att endast exponera data för användare som de har behörighet att se. I ett RAG-scenario med flera klienter kan en användare mappas till ett klientspecifikt arkiv. Det betyder inte att användaren ska kunna komma åt alla data i det arkivet. I Definiera dina klient- och auktoriseringskrav diskuterade vi vikten av att definiera auktoriseringskraven för dina data. Dessa auktoriseringsregler bör användas som grund för filtrering.

Filtrering kan utföras med hjälp av dataplattformsfunktioner som säkerhet på radnivå eller så kan det kräva anpassad logik, data eller metadata. Återigen används dessa plattformsfunktioner inte ofta i lösningar med flera klientorganisationer på grund av behovet av att 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 och framtvingar att användarna bara får åtkomst till den information de ska få åtkomst till.

Figur 4. Multitenant RAG-arkitektur med ett API som kapslar in dataåtkomstlogik för flera klientorganisationer

Som nämnts tidigare i den här artikeln kan användaråtkomst till data begränsas av:

• Användarens klientorganisation
• Plattformsfunktioner
• Anpassade säkerhetsfiltrerings-/trimningsregler.

Det här lagret bör ha följande ansvarsområden:

• 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 lagringsplatser för flera klienter
• Använda lämplig identitet för en användare för att stödja plattformsaktiverad auktoriseringslogik
• Framtvinga anpassad säkerhetstrimningslogik
• Lagra åtkomstloggar för grundinformation i granskningssyfte

Kod som behöver komma åt klientdata ska inte kunna köra frågor mot serverdelsarkiven direkt. Alla begäranden om data ska flöda genom det här API-lagret. Det här API-lagret ger en enda styrnings- eller säkerhetsnivå ovanpå dina klientdata. Den här metoden hindrar klientorganisationens och användarens dataåtkomstauktoriseringslogik från att blöda i olika delar av programmet. 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 lösning för rag-slutsatsdragning med flera klienter måste du ta hänsyn till hur du skapar grunddatalösningen för dina klienter. Få en förståelse för antalet klienter och mängden data per klientorganisation som du lagrar. Den här informationen hjälper dig att utforma din lösning för datainnehavare. Vi rekommenderar att du implementerar ett API-lager som kapslar in dataåtkomstlogik, inklusive både logik för flera klientorganisationer och filtrering.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

• John Downs | Huvudprogramtekniker
• Daniel Scott-Raynsford | Sr. Partner Solution Architect, Data & AI

Nästa steg

Relaterade resurser

• SaaS- och lösningsarkitektur för flera klientorganisationer
• Grundläggande referensarkitektur för OpenAI-chatt från slutpunkt till slutpunkt
• Referensarkitektur för openAI från slutpunkt till slutpunkt
• Få åtkomst till Azure OpenAI och andra språkmodeller via en gateway