Delen via

Een beveiligde multitenant RAG-deductieoplossing ontwerpen

  • Artikel

Retrieval-Augmented Generation (RAG) is een patroon voor het bouwen van toepassingen die gebruikmaken van basismodellen om te redeneren over bedrijfseigen informatie of andere gegevens die niet openbaar op het internet beschikbaar is. Over het algemeen roept een clienttoepassing een indelingslaag aan die relevante informatie ophaalt uit een gegevensarchief, zoals een vectordatabase. De orkestratielaag geeft die gegevens als onderdeel van de context als basisgegevens door aan het basismodel.

Een multitenant-oplossing wordt door meerdere klanten gebruikt. Elke klant of tenant bestaat uit meerdere gebruikers van dezelfde organisatie, hetzelfde bedrijf of dezelfde groep. In scenario's met meerdere tenants moet u ervoor zorgen dat tenants, of personen binnen tenants, alleen grondgegevens kunnen opnemen waartoe ze toegang hebben.

Er zijn problemen met meerdere tenants, behalve dat gebruikers alleen toegang hebben tot de informatie waartoe ze gemachtigd zijn. Dit artikel richt zich echter op dat aspect van multitenancy. Dit artikel begint met een overzicht van RAG-architecturen met één tenant. Hierin worden de uitdagingen besproken die u kunt tegenkomen in multitenancy met RAG en enkele veelvoorkomende benaderingen. Het bevat ook een overzicht van multitenancy-overwegingen en aanbevelingen voor verbeterde beveiliging.

Notitie

In dit artikel worden verschillende functies beschreven die specifiek zijn voor De Azure OpenAI-service, zoals de functie Azure OpenAI op uw gegevens. U kunt echter de meeste principes die in dit artikel worden beschreven, toepassen op basis-AI-modellen op elk platform.

RAG-architectuur voor één enkele tenant met een orchestrator

Diagram met een RAG-architectuur die gebruikmaakt van een database-exemplaar met één tenant.

Werkstroom

In deze RAG-architectuur met één tenant haalt een orchestrator relevante eigen tenantgegevens op uit de gegevensarchieven en biedt deze als grondgegevens aan het basismodel. In de volgende stappen wordt een werkstroom op hoog niveau beschreven.

  1. Een gebruiker geeft een aanvraag voor de intelligente webtoepassing uit.
  2. Een id-provider verifieert de aanvrager.
  3. De intelligente toepassing roept de orchestrator-API aan met de query van de gebruiker en het autorisatietoken voor de gebruiker.
  4. De indelingslogica extraheert de query van de gebruiker uit de aanvraag en roept de juiste gegevensopslag aan om relevante grondgegevens voor de query op te halen. De grondgegevens worden toegevoegd aan de prompt die wordt verzonden naar het basismodel, zoals een model dat wordt weergegeven in Azure OpenAI, in de volgende stap.
  5. De indelingslogica maakt verbinding met de deductie-API van het basismodel en verzendt de prompt die de opgehaalde grondgegevens bevat. De resultaten worden geretourneerd naar de intelligente toepassing.

Zie Ontwerp en ontwikkel een RAG-oplossingvoor meer informatie.

RAG-architectuur met één tenant met directe gegevenstoegang

Deze variant van de RAG-architectuur met één tenant maakt gebruik van de functie On Your Data van Azure OpenAI om rechtstreeks te integreren met gegevensarchieven zoals Azure AI Search. In deze architectuur beschikt u niet over uw eigen orchestrator of heeft uw orchestrator minder verantwoordelijkheden. De Azure OpenAI API doet een beroep op de dataopslag om de basisgegevens op te halen en deze gegevens door te geven aan het taalmodel. Met deze methode hebt u minder controle over welke grondgegevens moeten worden opgehaald en wat de relevantie van die gegevens is.

Notitie

Azure OpenAI wordt beheerd door Microsoft. Het is geïntegreerd met het gegevensarchief, maar het model zelf kan niet worden geïntegreerd met het gegevensarchief. Het model ontvangt grondgegevens op dezelfde manier als wanneer een orchestrator de gegevens ophaalt.

diagram met een RAG-architectuur die directe toegang tot een database-exemplaar met één tenant van Azure OpenAI gebruikt.

Werkstroom

In deze RAG-architectuur haalt de service die het basismodel biedt de juiste eigen tenantgegevens op uit de gegevensarchieven en gebruikt deze gegevens als grondgegevens voor het basismodel. In de volgende stappen wordt een werkstroom op hoog niveau beschreven. De cursieve stappen zijn identiek aan de voorgaande RAG-architectuur met één tenant die een orchestratorwerkstroom heeft.

  1. Een gebruiker geeft een aanvraag voor de intelligente webtoepassing uit.
  2. Een id-provider verifieert de aanvrager.
  3. De intelligente toepassing roept Azure OpenAI aan met de query van de gebruiker.
  4. Azure OpenAI maakt verbinding met ondersteunde gegevensarchieven, zoals AI Search en Azure Blob Storage, om de grondgegevens op te halen. De grondgegevens worden gebruikt als onderdeel van de context wanneer Azure OpenAI het OpenAI-taalmodel aanroept. De resultaten worden geretourneerd naar de intelligente toepassing.

Als u deze architectuur in een multitenant-oplossing wilt gebruiken, moet de service die rechtstreeks toegang heeft tot de grondgegevens, zoals Azure OpenAI, ondersteuning bieden voor de multitenant-logica die uw oplossing nodig heeft.

Multitenancy in RAG-architectuur

In multitenant-oplossingen kunnen tenantgegevens bestaan in een tenantspecifieke opslag of naast andere tenants in een multitenant-opslag. Gegevens bevinden zich mogelijk ook in een opslag die wordt gedeeld door tenants. Alleen gegevens waartoe de gebruiker gemachtigd is, moeten worden gebruikt als grondgegevens. De gebruiker moet alleen algemene of alle tenantgegevens of gegevens van hun tenant zien die zijn gefilterd om ervoor te zorgen dat ze alleen de gegevens zien waartoe ze gemachtigd zijn.

diagram met een RAG-architectuur die gebruikmaakt van een gedeelde database, een multitenant-database en twee databases met één tenant.

Werkstroom

In de volgende stappen wordt een werkstroom op hoog niveau beschreven. De cursief gedrukte stappen zijn identiek aan de single-tenant RAG-architectuur met een orkestrator-werkstroom.

  1. Een gebruiker geeft een aanvraag voor de intelligente webtoepassing uit.
  2. Een id-provider verifieert de aanvrager.
  3. De intelligente toepassing roept de orchestrator-API aan met de query van de gebruiker en het autorisatietoken voor de gebruiker.
  4. De indelingslogica extraheert de query van de gebruiker uit de aanvraag en roept de juiste gegevensarchieven aan om door de tenant geautoriseerde, relevante grondgegevens voor de query op te halen. De groundinggegevens worden toegevoegd aan de prompt die bij de volgende stap naar Azure OpenAI wordt verzonden. Enkele of alle van de volgende stappen zijn opgenomen:
    1. Met de indelingslogica worden grondgegevens opgehaald uit het juiste tenantspecifieke gegevensarchiefexemplaar en worden mogelijk beveiligingsfilterregels toegepast om alleen de gegevens te retourneren waartoe de gebruiker is gemachtigd.
    2. De indelingslogica haalt de grondgegevens van de juiste tenant op uit het multitenant-gegevensarchief en past mogelijk beveiligingsfilterregels toe om alleen de gegevens te retourneren waartoe de gebruiker is gemachtigd.
    3. Met de orkestratielogica worden gegevens opgehaald uit een gegevensarchief dat wordt gedeeld tussen huurders.
  5. De indelingslogica maakt verbinding met de deductie-API van het basismodel en verzendt de prompt die de opgehaalde grondgegevens bevat. De resultaten worden geretourneerd naar de intelligente toepassing.

Ontwerpoverwegingen voor multitenant-gegevens in RAG

Houd rekening met de volgende opties wanneer u uw multitenant RAG-deductieoplossing ontwerpt.

Een winkelisolatiemodel kiezen

De twee belangrijkste architectuurbenaderingen voor opslag en gegevens in scenario's met meerdere tenants zijn opslag per tenant en multitenant-opslag. Deze benaderingen zijn in aanvulling op winkels die gegevens bevatten die worden gedeeld tussen huurders. Uw multitenant-oplossing kan een combinatie van deze benaderingen gebruiken.

Winkel-per-huurder-winkels

In winkels-per-huurder winkels heeft elke huurder zijn eigen winkel. De voordelen van deze aanpak zijn zowel gegevens- als prestatieisolatie. De gegevens van elke tenant worden ingekapseld in een eigen opslag. In de meeste gegevensservices zijn de geïsoleerde archieven niet vatbaar voor het probleem van lawaaierige buren van andere gebruikers. Deze aanpak vereenvoudigt ook de kostentoewijzing, omdat de volledige kosten van een winkelimplementatie kunnen worden toegeschreven aan één tenant.

Deze aanpak kan uitdagingen opleveren, zoals verhoogde beheer- en operationele overhead en hogere kosten. Gebruik deze benadering niet als u een groot aantal kleine tenants hebt, zoals in bedrijfs-naar-consumentenscenario's. Deze benadering zou ook de -servicelimieten kunnen bereiken of overschrijden.

In de context van dit AI-scenario betekent een winkel per tenant dat de benodigde grondgegevens voor het overbrengen van relevantie in de context afkomstig zijn van een bestaand of nieuw gegevensarchief dat alleen grondgegevens voor de tenant bevat. In deze topologie is het database-exemplaar de discriminator die voor elke tenant wordt gebruikt.

Multitenant-winkels

In multitenant-archieven bestaan de gegevens van meerdere tenants naast elkaar in hetzelfde archief. De voordelen van deze aanpak zijn onder andere het potentieel voor kostenoptimalisatie, de mogelijkheid om een hoger aantal tenants te verwerken dan het store-per-tenantmodel en lagere beheeroverhead vanwege het lagere aantal winkelexemplaren.

De uitdagingen van het gebruik van gedeelde archieven zijn de noodzaak van gegevensisolatie en -beheer, het potentieel voor de lawaaierige buur antipatroonen complexere kostentoewijzing aan tenants. Gegevensisolatie is de belangrijkste zorg wanneer u deze benadering gebruikt. U moet veilige benaderingen implementeren om ervoor te zorgen dat tenants alleen toegang hebben tot hun gegevens. Gegevensbeheer kan ook lastig zijn als tenants verschillende gegevenslevenscycli hebben waarvoor bewerkingen nodig zijn, zoals het bouwen van indexen volgens verschillende planningen.

Sommige platforms hebben functies die u kunt gebruiken wanneer u isolatie van tenantgegevens in gedeelde archieven implementeert. Azure Cosmos DB biedt bijvoorbeeld systeemeigen ondersteuning voor gegevenspartitionering en sharding. Het is gebruikelijk om een tenant-id te gebruiken als een partitiesleutel om enige isolatie tussen tenants te bieden. Azure SQL en Azure Database for PostgreSQL - Flexible Server ondersteunen beveiliging op rijniveau. Deze functies worden echter meestal niet gebruikt in multitenant-oplossingen, omdat u uw oplossing moet ontwerpen rond deze functies als u van plan bent deze te gebruiken in uw multitenant-winkel.

In de context van dit AI-scenario worden gegevens gezamenlijk beheerd voor alle tenants die zich in dezelfde gegevensopslag bevinden. Daarom moet uw query naar dat gegevensarchief een tenantdiscriminator bevatten om ervoor te zorgen dat antwoorden worden beperkt tot het terugbrengen van alleen relevante gegevens binnen de context van de tenant.

Gedeelde winkels

Multitenant-oplossingen delen vaak gegevens tussen tenants. In een voorbeeld van een multitenant-oplossing voor het gezondheidszorgdomein kan een database algemene medische informatie of informatie opslaan die niet specifiek is voor de tenant.

In de context van dit AI-scenario is het grondgegevensarchief algemeen toegankelijk en hoeft niet te worden gefilterd op basis van specifieke tenants, omdat de gegevens relevant en geautoriseerd zijn voor alle tenants in het systeem.

Identiteit

Identity is een belangrijk aspect van multitenant-oplossingen, waaronder multitenant RAG-oplossingen. De intelligente toepassing moet worden geïntegreerd met een id-provider om de identiteit van de gebruiker te verifiëren. De multitenant RAG-oplossing heeft een identiteitsmap nodig waarin gezaghebbende identiteiten of verwijzingen naar identiteiten worden opgeslagen. Deze identiteit moet door de aanvraagketen stromen en downstreamservices, zoals de orchestrator of het gegevensarchief zelf, toestaan om de gebruiker te identificeren.

U hebt ook een manier nodig om een gebruiker toe te wijzen aan een tenant zodat u toegang kunt verlenen tot die tenantgegevens.

Uw tenant- en autorisatievereisten definiëren

Wanneer u een multitenant RAG-oplossing bouwt, moet u definiëren wat een tenant is voor uw oplossing. De twee algemene modellen waaruit u kunt kiezen, zijn business-to-business- en business-to-consumer-modellen. Met het model dat u kiest, kunt u bepalen welke andere factoren u moet overwegen wanneer u uw oplossing bouwt. Inzicht in het aantal tenants is essentieel voor het kiezen van het gegevensarchiefmodel. Een groot aantal tenants vereist mogelijk een model met meerdere tenants voor elke winkel. Een kleiner aantal huurders kan een model met één winkel per huurder toestaan. De hoeveelheid gegevens voor elke tenant is ook belangrijk. Tenants met grote hoeveelheden gegevens kunnen voorkomen dat u multitenant-archieven gebruikt vanwege de groottebeperkingen voor het gegevensarchief.

Als u een bestaande workload wilt uitbreiden ter ondersteuning van dit AI-scenario, hebt u mogelijk al deze beslissing genomen. Over het algemeen kunt u uw bestaande topologie voor gegevensopslag gebruiken voor de grondgegevens als dat gegevensarchief voldoende relevantie kan bieden en aan andere niet-functionele vereisten kan voldoen. Als u echter van plan bent nieuwe onderdelen te introduceren, zoals een specifieke vectorzoekopslag als een specifieke basisopslag, dan moet u deze beslissing alsnog nemen. Houd rekening met factoren zoals uw huidige implementatiestempelstrategie, impact op het toepassingsbeheervlak en eventuele verschillen in de levenscyclus van gegevens per tenant, zoals situaties met betalen voor prestaties.

Nadat u hebt gedefinieerd wat een tenant voor uw oplossing is, moet u uw autorisatievereisten voor gegevens definiëren. Tenants hebben alleen toegang tot gegevens van hun tenant, maar uw autorisatievereisten zijn mogelijk gedetailleerder. In een oplossing voor gezondheidszorg hebt u bijvoorbeeld regels zoals:

  • Een patiënt heeft alleen toegang tot hun eigen patiëntgegevens.
  • Een gezondheidszorgprofessional heeft toegang tot de gegevens van hun patiënten.
  • Een financiële gebruiker heeft alleen toegang tot financiële gegevens.
  • Een klinische auditor kan de gegevens van alle patiënten zien.
  • Alle gebruikers hebben toegang tot basiskennis van medische gegevens in een gedeeld gegevensarchief.

In een op documenten gebaseerde RAG-toepassing wilt u mogelijk de toegang van gebruikers tot documenten beperken op basis van een tagschema of gevoeligheidsniveaus die aan de documenten zijn toegewezen.

Nadat u een definitie hebt van wat een tenant is en een duidelijk inzicht hebt in de autorisatieregels, gebruikt u die informatie als vereisten voor uw gegevensarchiefoplossing.

Gegevensfiltering

Het beperken van de toegang tot alleen de gegevens waartoe gebruikers gemachtigd zijn, wordt ook wel filteren of veiligheidstrimmengenoemd. In een multitenant RAG-scenario kan een gebruiker worden toegewezen aan een tenantspecifieke winkel. Dat betekent niet dat de gebruiker toegang moet hebben tot alle gegevens in dat archief. Definieer uw tenant- en autorisatievereisten bespreekt het belang van het definiëren van autorisatievereisten voor uw gegevens. U moet deze autorisatieregels gebruiken als basis voor filteren.

U kunt mogelijkheden voor gegevensplatformen gebruiken, zoals beveiliging op rijniveau, om filters te implementeren. Of u hebt mogelijk aangepaste logica, gegevens of metagegevens nodig. Deze platformfuncties worden doorgaans niet gebruikt in multitenant-oplossingen, omdat u uw systeem rondom deze functies moet ontwerpen.

Multitenant-gegevenslogica inkapselen

U wordt aangeraden een API te hebben vóór het opslagmechanisme dat u gebruikt. De API fungeert als een gatekeeper die ervoor zorgt dat gebruikers alleen toegang krijgen tot informatie waartoe ze gemachtigd zijn.

diagram met een RAG-architectuur met een gedeelde database, een multitenant-database en twee databases met één tenant. Een API-laag bevindt zich tussen de orchestrator en de databases.

De toegang van gebruikers tot gegevens kan worden beperkt door:

  • De tenant van de gebruiker.
  • Platformfuncties.
  • Aangepaste beveiligingsfilters of regels voor bijsnijden.

De API-laag moet:

  • Routeer de query naar een tenantspecifieke winkel in een store-per-tenantmodel.
  • Selecteer alleen gegevens uit de tenant van de gebruiker in winkels met meerdere tenants.
  • Gebruik de juiste identiteit voor een gebruiker om autorisatielogica met platformondersteuning te ondersteunen.
  • Aangepaste logica voor beveiligingsbeperkingen afdwingen.
  • Sla toegangslogboeken op met basisinformatie voor auditdoeleinden.

Code die toegang tot tenantgegevens nodig heeft, mag de back-end opslag niet rechtstreeks opvragen. Alle aanvragen voor gegevens moeten via de API-laag stromen. Deze API-laag biedt een punt van beheer of beveiliging voor uw tenantgegevens. Deze aanpak voorkomt dat de autorisatielogica voor tenant- en gebruikersgegevenstoegang andere gebieden van de toepassing bereikt. Deze logica wordt ingekapseld in de API-laag. Dankzij deze inkapseling is de oplossing eenvoudiger te valideren en te testen.

Samenvatting

Wanneer u een multitenant RAG-deductieoplossing ontwerpt, moet u overwegen hoe u de grondgegevensoplossing voor uw tenants ontwerpt. Inzicht in het aantal tenants en de hoeveelheid gegevens per tenant die u opslaat. Deze informatie helpt u uw oplossing voor databeheer ontwerpen. U wordt aangeraden een API-laag te implementeren die de logica voor gegevenstoegang inkapselt, inclusief multitenantlogica en filterlogica.

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Hoofdauteurs:

Meld u aan bij LinkedIn als u niet-openbare LinkedIn-profielen wilt zien.

Volgende stap

Een RAG-oplossing ontwerpen en ontwikkelen