Rag (Retrieval-Augmented Generation) is een patroon voor het bouwen van toepassingen waarbij basismodellen worden gebruikt om te redeneren boven eigendomsinformatie of andere informatie die niet openbaar beschikbaar is op internet. Over het algemeen roept een clienttoepassing een indelingslaag aan die relevante informatie ophaalt uit een gegevensarchief, zoals een vectordatabase. De indelingslaag geeft die gegevens als onderdeel van de context door aan het basismodel.
Een multitenant-oplossing wordt gebruikt door meerdere klanten, waarbij elke klant (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 die ze mogen zien.
Hoewel er zorgen zijn over meerdere tenants, behalve dat gebruikers alleen toegang hebben tot de informatie die ze moeten zien, richt dit artikel zich op dat aspect van multitenancy. Het artikel begint met een overzicht van RAG-architecturen met één tenant, bespreekt de uitdagingen met betrekking tot multitenancy met RAG en enkele algemene benaderingen die u moet volgen en eindigt met veilige overwegingen en aanbevelingen voor multitenancy.
Notitie
In dit artikel worden enkele azure OpenAI-specifieke functies besproken, zoals Azure OpenAI op uw gegevens. Dat gezegd hebbende, zijn de meeste principes die in dit document worden besproken, van toepassing op de meeste fundamentele AI-modellen, ongeacht hun hostplatform.
Rag-architectuur met één tenant met orchestrator
Figuur 1. RAG-architectuur met één tenant
Workflow
In deze rag-architectuur met één tenant heeft een orchestrator de verantwoordelijkheid om relevante eigen tenantgegevens op te halen uit de gegevensarchieven en deze als basisgegevens aan het basismodel te leveren. Hier volgt een werkstroom op hoog niveau:
- Een gebruiker geeft een aanvraag voor de intelligente webtoepassing uit.
- Een id-provider verifieert de aanvrager.
- De intelligente toepassing roept de orchestrator-API aan met de gebruikersquery en het autorisatietoken voor de gebruiker.
- 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, bijvoorbeeld een model dat beschikbaar is in Azure OpenAI, in de volgende stap.
- 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 Een RAG-oplossing ontwerpen en ontwikkelen voor meer informatie over de details van RAG.
Rag-architectuur met één tenant met directe gegevenstoegang
Een variant van de RAG-architectuur met één tenant maakt gebruik van de mogelijkheid van de Azure OpenAI-service om rechtstreeks te integreren met gegevensarchieven zoals Azure Search. In deze architectuur beschikt u niet over uw eigen orchestrator of heeft uw orchestrator minder verantwoordelijkheden. De Azure OpenAI-API heeft de verantwoordelijkheid om het gegevensarchief aan te roepen om de grondgegevens op te halen en die gegevens door te geven aan het taalmodel. U hebt op zijn beurt minder controle over welke grondgegevens moeten worden opgehaald en wat de relevantie van die gegevens is.
Notitie
De Azure OpenAI-service, beheerd door Microsoft, kan worden geïntegreerd met het gegevensarchief. Het model zelf kan niet worden geïntegreerd met de gegevensarchieven. Het model ontvangt grondgegevens op exact dezelfde manier als wanneer de gegevens worden opgehaald door een orchestrator.
Figuur 2. Rag-architectuur met één tenant met directe gegevenstoegang vanuit de Azure OpenAI-service
Workflow
In deze RAG-architectuur heeft de service die het basismodel biedt de verantwoordelijkheid om de juiste eigen tenantgegevens op te halen uit de gegevensarchieven en die gegevens te gebruiken als basisgegevens voor het basismodel. Hier volgt een werkstroom op hoog niveau (cursieve stappen zijn identiek aan de RAG-architectuur met één tenant met orchestratorwerkstroom):
- Een gebruiker geeft een aanvraag voor de intelligente webtoepassing uit.
- Een id-provider verifieert de aanvrager.
- De intelligente toepassing roept vervolgens de Azure OpenAI-service aan met de gebruikersquery.
- De Azure OpenAI-service maakt verbinding met ondersteunde gegevensarchieven, zoals Azure AI Search en Azure Blob Storage, om de grondgegevens op te halen. De grondgegevens worden gebruikt als onderdeel van de context wanneer de Azure OpenAI-service het OpenAI-taalmodel aanroept. De resultaten worden geretourneerd naar de intelligente toepassing.
Als u deze architectuur in een multitenant-oplossing wilt overwegen, moet de service, zoals Azure OpenAI, die rechtstreeks toegang heeft tot de grondgegevens, ondersteuning bieden voor de multitenant-logica die vereist is voor uw oplossing.
Multitenancy in RAG-architectuur
In multitenant-oplossingen kunnen tenantgegevens bestaan in een tenantspecifieke winkel of naast andere tenants in een multitenant-archief. Mogelijk zijn er ook gegevens in een archief dat wordt gedeeld tussen tenants. Alleen gegevens die de gebruiker mag zien, moeten worden gebruikt als grondgegevens. De gebruikers mogen alleen algemene (alle tenant)gegevens of gegevens van hun tenant zien met filterregels die zijn toegepast om ervoor te zorgen dat ze alleen gegevens zien die ze mogen zien.
Afbeelding 3: RAG-architectuur - met meerdere tenants voor gegevensopslag
Workflow
Deze werkstroom is hetzelfde als in de RAG-architectuur van één tenant met orchestrator , behalve stap 4.
- Een gebruiker geeft een aanvraag voor de intelligente webtoepassing uit.
- Een id-provider verifieert de aanvrager.
- De intelligente toepassing roept de orchestrator-API aan met de gebruikersquery en het autorisatietoken voor de gebruiker.
- 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 grondgegevens worden toegevoegd aan de prompt die in de volgende stap naar Azure OpenAI wordt verzonden. Enkele of alle van de volgende stappen zijn betrokken:
- Met de indelingslogica worden grondgegevens opgehaald uit het juiste tenantspecifieke gegevensarchiefexemplaar, waarbij mogelijk beveiligingsfilterregels worden toegepast om alleen de gegevens te retourneren die de gebruiker mag openen.
- Met de indelingslogica worden de grondgegevens van de juiste tenant opgehaald uit het gegevensarchief met meerdere tenants, waarbij mogelijk beveiligingsfilterregels worden toegepast om alleen de gegevens te retourneren die de gebruiker mag openen.
- De indelingslogica haalt gegevens op uit een gegevensarchief dat wordt gedeeld tussen tenants.
- 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
Opslagisolatiemodellen kiezen
Er zijn twee belangrijke architectuurmethoden voor opslag en gegevens in scenario's met meerdere tenants: opslag per tenant en multitenant-winkels. Deze benaderingen zijn naast winkels die gegevens bevatten die worden gedeeld tussen tenants. In deze sectie wordt elke benadering besproken. Er moet worden opgemerkt dat uw multitenant-oplossing een combinatie van deze benaderingen kan gebruiken.
Store-per-tenant
Zoals de naam al aangeeft, heeft elke tenant een eigen winkel in store-per-tenant. De voordelen van deze aanpak zijn zowel gegevens- als prestatieisolatie. De gegevens van elke tenant worden ingekapseld in een eigen archief. In de meeste gegevensservices zijn de geïsoleerde archieven niet vatbaar voor het probleem met lawaaierige buren van andere tenants. Deze aanpak vereenvoudigt ook de kostentoewijzing, omdat de volledige kosten van een winkelimplementatie kunnen worden toegeschreven aan één tenant.
De uitdagingen van deze aanpak zijn mogelijk hogere beheer- en operationele overhead en hogere kosten. Deze benadering moet niet worden overwogen wanneer er een groot aantal kleine tenants is, zoals business-to-consumer-scenario's. Deze aanpak kan ook worden uitgevoerd op basis van de servicebeperkingen.
In de context van dit AI-scenario betekent een opslag per tenant dat de grondgegevens die nodig zijn om relevantie in de context te brengen, 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 per tenant wordt gebruikt.
Multitenant stores
In multitenant-archieven bestaan meerdere tenants gegevens 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 onder andere de noodzaak om gegevensisolatie, gegevensbeheer, het potentieel voor ruisende buren antipatroon te garanderen en problemen bij het toewijzen van kosten aan tenants. Het waarborgen van gegevensisolatie is de belangrijkste zorg voor deze aanpak. U hebt de verantwoordelijkheid om de beveiligingsbenadering te implementeren om ervoor te zorgen dat tenants alleen toegang hebben tot hun gegevens. Gegevensbeheer kan ook een uitdaging zijn als tenants verschillende gegevenslevenscycli hebben waarvoor bewerkingen nodig kunnen zijn, zoals het bouwen van indexen volgens verschillende planningen.
Sommige platforms hebben functies waarvan u kunt profiteren wanneer u tenantgegevensisolatie implementeert in gedeelde archieven. Azure Cosmos DB biedt bijvoorbeeld systeemeigen ondersteuning voor partitionering en sharding. Het is gebruikelijk om een tenant-id als partitiesleutel te gebruiken om een bepaald isolatieniveau tussen tenants te bieden. Azure SQL en Postgres Flex bieden ondersteuning voor beveiliging op rijniveau, hoewel deze functie niet vaak wordt gebruikt in multitenant-oplossingen, omdat u uw oplossing rondom deze functies moet ontwerpen als u ze in uw multitenant-winkel wilt gebruiken.
In de context van dit AI-scenario betekent dit dat grondgegevens voor alle tenants in hetzelfde gegevensarchief worden geplaatst, zodat uw query naar dat gegevensarchief een tenantdiscriminator moet bevatten om ervoor te zorgen dat reacties alleen relevante gegevens binnen de context van de tenant kunnen terugbrengen.
Gedeelde winkels
Multitenant-oplossingen bevatten vaak gegevens die worden gedeeld tussen tenants. In een voorbeeld van een multitenant-oplossing voor het zorgdomein is er mogelijk een database waarin algemene medische gegevens of gegevens worden opgeslagen die niet specifiek zijn voor tenants.
In de context van dit AI-scenario zou dit een algemeen toegankelijk gegevensarchief zijn dat niet specifiek hoeft te worden gefilterd op basis van een tenant, omdat de gegevens relevant en geautoriseerd zijn voor alle tenants in het systeem.
Identiteit
Identiteit is een belangrijk aspect van multitenant-oplossingen , waaronder beveiligde multitenant RAG. De intelligente toepassing moet worden geïntegreerd met een id-provider (IdP) 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, waardoor downstreamservices zoals de orchestrator of zelfs het gegevensarchief zelf de gebruiker kunnen identificeren.
U hebt ook een middel nodig om een gebruiker toe te kennen aan een tenant, zodat u toegang kunt verlenen tot die tenantgegevens.
Uw tenant- en autorisatievereisten definiëren
Bij het bouwen van een multitenant RAG-oplossing moet u definiëren wat een tenant voor uw oplossing is. De twee algemene modellen waaruit u kunt kiezen, zijn B2B (business-to-business) en business-to-consumer (B2C). Deze bepaling helpt u te informeren over gebieden die u moet overwegen wanneer u uw oplossing ontwerpt. Inzicht in het aantal tenants is essentieel voor het bepalen van het gegevensarchiefmodel. Een groot aantal tenants kan een model met meerdere tenants per winkel vereisen, terwijl een kleiner aantal mogelijk een winkel per tenantmodel toestaat. De hoeveelheid gegevens per tenant is ook belangrijk. Als tenants grote hoeveelheden gegevens hebben waardoor u mogelijk geen multitenant-archieven kunt gebruiken vanwege groottebeperkingen voor het gegevensarchief.
In bestaande workloads die worden uitgebreid ter ondersteuning van dit AI-scenario, hebt u deze keuze mogelijk al gemaakt. Over het algemeen kunt u uw bestaande gegevensopslagtopologie gebruiken voor de grondgegevens als dat gegevensarchief voldoende relevantie kan bieden en aan andere niet-functionele vereisten kan voldoen. Als u echter nieuwe onderdelen zoals een speciaal vectorzoekarchief introduceert als een speciaal grounding-archief, moet u deze beslissing nemen, rekening houdend met factoren zoals uw huidige implementatiestempelstrategie, impact op het besturingsvlak van uw toepassing en eventuele verschillen in de levenscyclus van gegevens per tenant (zoals situaties met betalen voor prestaties.)
Zodra u definieert wat een tenant voor uw oplossing is, moet u vervolgens uw autorisatievereisten voor gegevens definiëren. Hoewel tenants alleen toegang hebben tot gegevens van hun tenant, zijn uw autorisatievereisten mogelijk gedetailleerder. In een gezondheidszorgoplossing 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 medische basiskennis 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 zijn ingesteld op documenten.
Zodra u een definitie hebt van wat een tenant is en een duidelijk inzicht hebt in de autorisatieregels, gebruikt u deze informatie als vereisten voor uw gegevensarchiefoplossing.
Filteren
Filteren, ook wel beveiligingsbeperkingen genoemd, verwijst naar het weergeven van alleen de gegevens voor gebruikers die ze mogen zien. 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. In Uw tenant en autorisatievereisten definiëren hebben we het belang besproken van het definiëren van de autorisatievereisten voor uw gegevens. Deze autorisatieregels moeten worden gebruikt als basis voor filteren.
U kunt filteren met behulp van mogelijkheden van het gegevensplatform, zoals beveiliging op rijniveau, of waarvoor aangepaste logica, gegevens of metagegevens nodig zijn. Nogmaals, deze platformfuncties worden niet vaak gebruikt in multitenant-oplossingen vanwege de noodzaak om uw systeem rond deze functies te ontwerpen.
Multitenant-gegevenslogica inkapselen
Het wordt aanbevolen om een API te hebben vóór elk opslagmechanisme dat u gebruikt. De API fungeert als gatekeeper en dwingt af dat gebruikers alleen toegang krijgen tot de informatie waartoe ze toegang moeten krijgen.
Figuur 4. Multitenant RAG-architectuur met een API die multitenant-tenantgegevenstoegangslogica inkapselt
Zoals eerder in dit artikel is vermeld, kan de gebruikerstoegang tot gegevens worden beperkt door:
- De tenant van de gebruiker
- Functies van het platform
- Aangepaste regels voor filteren/bijsnijden van beveiliging.
Deze laag moet de volgende verantwoordelijkheden hebben:
- De query doorsturen naar een tenantspecifieke winkel in een winkel-per-tenantmodel
- Selecteer alleen gegevens uit de tenant van de gebruiker in multitenant stores
- Gebruik de juiste identiteit voor een gebruiker om autorisatielogica met platformondersteuning te ondersteunen
- Aangepaste logica voor beveiligingsbeperkingen afdwingen
- Toegangslogboeken van grondinformatie opslaan voor controledoeleinden
Code die toegang moet hebben tot tenantgegevens, mag niet rechtstreeks een query kunnen uitvoeren op de back-endarchieven. Alle aanvragen voor gegevens moeten via deze API-laag stromen. Deze API-laag biedt een enkel beheerpunt of beveiligingslaag boven op uw tenantgegevens. Deze benadering zorgt ervoor dat de autorisatielogica voor tenant- en gebruikersgegevenstoegang in verschillende gebieden van de toepassing loopt. Deze logica wordt ingekapseld in de API-laag. Dankzij deze inkapseling is de oplossing eenvoudiger te valideren en te testen.
Samenvatting
Bij het ontwerpen van een multitenant RAG-deductieoplossing moet u rekening houden met het ontwerpen van de grondgegevensoplossing voor uw tenants. Krijg inzicht in het aantal tenants en de hoeveelheid gegevens per tenant die u opslaat. Deze informatie helpt u bij het ontwerpen van uw oplossing voor gegevenstenancy. U wordt aangeraden een API-laag te implementeren die de logica voor gegevenstoegang inkapselt, inclusief zowel multitenant- als filterlogica.
Medewerkers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
- John Downs | Principal Software Engineer
- Daniel Scott-Raynsford | Sr. Partner Solution Architect, Data & AI