Multi-Tenant RAG achter een OpenAI-compatibele API-gateway

Klantgerichte AI-assistenten hebben ophaal-verbeterde generatie nodig, maar RAG wordt moeilijker wanneer verzoeken via een OpenAI-compatibele API-gateway stromen in plaats van de native stack van één modelprovider. De gateway moet tenantgegevens geïsoleerd houden, citaten van modelaanbieders behouden, geïndexeerde inhoud op tijd verwijderen en de insluitings-, ophaal- en generatiekosten toewijzen aan de juiste klant.

Het praktische antwoord is om het ophalen te behandelen als een eersteklas gateway-subsysteem. Verberg het niet binnen één providerintegratie. Houd het ophalen gescheiden van het genereren, geef elk verzoek een op de tenant gerichte ophaalcontext, normaliseer citaten voordat u ze retourneert en noteer elke factureerbare stap in een grootboek.

Het lezersprobleem

Het teambouwen van een AI-assistent voor veel klanten begint meestal met een eenvoudige stroom: documenten uploaden, stukjes insluiten, de beste overeenkomsten ophalen, die fragmenten in de prompt plaatsen en een model vragen om te antwoorden. Dat werkt totdat het product meerdere modelaanbieders, facturering op klantniveau, offboarding en controleerbaarheid nodig heeft.

Het risico schuilt niet alleen in onnauwkeurige antwoorden. De grotere operationele risico's zijn fouten in de naamruimte van tenants, niet-verifieerbare citaten, verouderde indexen na het verwijderen van documenten en marges die niet kunnen worden verklaard omdat de ophaalkosten verdwijnen in de uitgaven voor algemene infrastructuur.

In dit artikel worden feiten, aanbevelingen en voorspellingen gescheiden. De feiten zijn de implementatiemogelijkheden die zijn gedocumenteerd door de huidige provider- en vectordatabase-API's. De aanbevelingen zijn architectuurkeuzes voor een gatewayproduct. Volgens de voorspellingen zal deze architectuur waarschijnlijk flexibiliteit nodig hebben omdat de functies voor het ophalen van de provider voortdurend veranderen.

Referentiearchitectuur

Een RAG-ontwerp op gatewayniveau moet uit vijf componenten bestaan:

• Tenant-resolver: wijst de inkomende API-sleutel, werkruimte, klantaccount of Partner API-klant toe aan een canonieke tenant_id.
• Ophaalprofiel: definieert welk corpus moet worden gebruikt. zoeken, welk insluitingsmodel moet worden gebruikt, aantal resultaten, filters, herrangschikkingsopties, citatievereisten en fallback-gedrag.
• Ophaaladapterlaag: roept het ophalen van de native provider, een externe vectordatabase of een aangepaste zoekservice aan via één interne interface.
• Prompt-assemblage- en generatie-adapter: geeft de opgehaalde context door aan de gekozen modelprovider zonder vector-backend-details bloot te stellen aan bellers.
• Gebruik en generatie audit grootboek: registreert het insluiten, indexeren, ophalen, prompttokens, voltooiingstokens, tenant-, model-, provider- en trace-ID's.

Een minimaal verzoekcontract kan providerneutraal blijven:

{
  "tenant_id": "tenant_123",
  "model": "gpt-compatibel-of-claude-compatibel-model",
  "retrieval_profile": "support_docs_v2",
  "citation_required": waar,
  "berichten": [
    {"role": "user", "content": "Wat is ons terugbetalingsbeleid voor jaarabonnementen?"}
  ]
}

Het antwoord moet ook providerneutraal zijn:

{
  "antwoord": "Jaarabonnementen kunnen worden terugbetaald binnen het geconfigureerde polisvenster...",
  "citaten": [
    {
      "source_id": "doc_789",
      "title": "Factuurbeleid",
      "url_or_internal_ref": "kb://factureringsbeleid",
      "chunk_id": "chunk_044",
      "offsets": {"pagina": 3},
      "score": 0,82,
      "retrieval_provider": "vector_db",
      "model_provider": "openai_compatibel",
      "provider_payload": {}
    }
  ],
  "retrieval_trace_id": "rt_456",
  "factureerbare_tenant": "tenant_123",
  "embedding_usage": null,
  "retrieval_usage": {"query's": 1, "resultaten": 6},
  "model_usage": {"input_tokens": 1920, "output_tokens": 180}

Feit: de functies voor het ophalen van providers zijn niet identiek

De Vector Stores API van OpenAI ondersteunt vectorwinkels die kunnen worden gemaakt, doorzocht, geconfigureerd met chunking-strategieën, gekoppeld aan bestandsmetagegevens en verwijderd. Zoeken in vectorwinkels ondersteunt zoekopdrachten, filters, maximale resultatenaantallen, rangschikkingsopties, scoredrempels en bedieningselementen voor het herschrijven van zoekopdrachten. Deze controles bieden gateway-auteurs handige knoppen voor latentie, relevantie en kosten.

OpenAI-platformgegevenscontroles maken het ontwerp van de levenscyclus ook belangrijk: klantinhoud in vectorwinkels wordt bewaard totdat deze wordt verwijderd. Als een huurder uit dienst gaat of als een tijdelijk project afloopt, kan de gateway er niet van uitgaan dat de provider de geïndexeerde inhoud automatisch zal verwijderen volgens de bedrijfsplanning van het product.

Anthropic legt een ander patroon bloot voor citaties. Applicaties kunnen inhoudsblokken voor zoekresultaten voorzien van bron- en titelmetagegevens, en wanneer citaten zijn ingeschakeld, kan het model citatiereferenties aan de gegenereerde tekst toevoegen. Er zijn praktische beperkingen: de citatie-instellingen voor zoekresultaten zijn alles-of-niets binnen een verzoek, zoekresultaatblokken ondersteunen tekstinhoud en de granulariteit van citaties hangt af van hoe de inhoud in blokken is opgesplitst.

De implicatie is direct: een gateway mag de ophaalvorm van een aanbieder niet blootstellen als zijn publieke contract, tenzij hij van plan is om van die aanbieder de permanente ophaalautoriteit te maken.

Aanbeveling: gebruik ophaaladapters, niet Ophaalvergrendeling

Maak een interne ophaaladapterinterface. De gateway kan verschillende backends erachter ondersteunen:

• Ophalen van native providers: handig wanneer een klant het snelste pad wil naar de bestandszoek- of vectoropslagfuncties van één provider.
• Externe vectordatabase: handig wanneer het product veel modelproviders moet ondersteunen met consistente tenantisolatie en levenscycluscontroles.
• Vooraf opgehaalde zoekresultaatblokken: handig wanneer de gateway opgehaalde tekst samenvoegt en deze doorgeeft aan een provider die expliciete citatiebewuste context ondersteunt.

De adapter moet dezelfde interne structuur retourneren, ongeacht de backend:

interface RetrievalResult {
  retrievalTraceId: tekenreeks;
  tenantId: tekenreeks;
  corpusId: string;
  stukjes: Array<{
    bronId: string;
    titel: tekenreeks;
    tekst: tekenreeks;
    urlOrInternalRef?: string;
    chunkId: tekenreeks;
    offsets?: { pagina?: nummer; byteStart?: nummer; byteEnd?: nummer; tokenStart?: nummer; tokenEnd?: nummer };
    score?: aantal;
    metagegevens: Record;
    providerPayload?: onbekend;
  }>;
  ophalenGebruik: {
    aanbieder: string;
    queryCount: getal;
    resultCount: aantal;
    factureerbareEenheden?: aantal;
  };}

Hierdoor kan de generatielaag context ontvangen zonder te weten of deze afkomstig is van OpenAI vectorwinkels, Pinecone, Weaviate, een volledige tekstzoekindex van een database of een interne hybride retriever.

Tenantisolatie begint vóór de vectorquery

Tenantisolatie mag niet afhankelijk zijn van promptinstructies. Het moet worden afgedwongen voordat het wordt opgehaald, op de opslag- en querygrens.

Voor systemen in Pinecone-stijl is het gedocumenteerde multitenancy-patroon één naamruimte per tenant in serverloze indexen. Bewerkingen op gegevensvlak zijn gericht op een naamruimte, wat de isolatie en offboarding van tenants vereenvoudigt, omdat het verwijderen van de naamruimte de records van die tenant verwijdert. Pinecone documenteert ook de afwegingen tussen naamruimten en het filteren van metagegevens: filteren binnen een grote gedeelde naamruimte kan meer gegevens scannen, meer kosten en langzamer uitvoeren dan zoekopdrachten met een naamruimtebereik.

Voor systemen in Weaviate-stijl slaat multi-tenancy elke tenant op een aparte shard op, zodat de gegevens van de ene tenant niet zichtbaar zijn voor een andere tenant. Als u een Tenant verwijdert, wordt de bijbehorende Shard verwijderd. Weaviate ondersteunt ook tenantstatussen zoals actief, inactief en offloaded, waardoor een levenscyclusoptie wordt gecreëerd voor zelden gebruikte tenants.

Implementatiechecklist

• Los tenant_id op aan de hand van de geverifieerde gateway-identiteit, niet alleen aan de hand van een door de gebruiker aangeleverd hoofdveld.
• Wijs tenant_id toe aan een vectornaamruimte, shard of vectorwinkel-ID van een provider via een serverregister.
• Weigeren verzoeken waarbij de API-sleuteltenant en de aangevraagde corpustenant niet overeenkomen.
• Houd gedeelde openbare corpora gescheiden van privé-tenantcorpora.
• Gebruik metadatafiltering voor documenttype, taal, productgebied of datumbereik nadat de tenantgrens al is geselecteerd.
• Lognaamruimte, shard, corpus_id, retrieval_profile en retrieval_trace_id voor controleerbaarheid.

Reserveer cross-tenant zoeken naar expliciete administratieve workflows met afzonderlijke autorisatie, afzonderlijke indexen of gecontroleerde aggregatiepaden. Maak zoekopdrachten tussen verschillende tenants niet tot een toevallig neveneffect van metadatafilters.

Normaliseer citaten als gateway-objecten

Citaties zijn een productcontract, niet alleen maar decoratie. Een klantondersteuningsassistent, juridisch hulpmiddel of interne kennisassistent moet laten zien waarom een antwoord is geproduceerd en waar de ondersteunende tekst vandaan komt.

De gateway moet citatiegegevens normaliseren in zijn eigen schema:

{
  "source_id": "doc_123",
  "title": "Restitutievoorwaarden",
  "url_or_internal_ref": "kb://refund-terms",
  "chunk_id": "chunk_006",
  "offsets": {"page": 2, "byte_start": 4410, "byte_end": 5020},
  "score": 0,79,
  "retrieval_provider": "weaviate",
  "model_provider": "antropisch",
  "model_provider_citation_payload": {}
}

Houd de genormaliseerde velden stabiel en sta providerspecifieke uitbreidingen toe. Sommige aanbieders zullen rijkere citatiedetails onthullen dan andere. Sommigen citeren blokken met zoekresultaten. Sommigen zullen geüploade bestanden citeren. Sommige bieden niet het exacte offsetformaat dat uw toepassing wenst. De gateway moet behouden wat er bestaat, zonder te doen alsof elke provider dezelfde citatie-semantiek heeft.

Strikte citatiemodus

Als citation_required waar is, definieer dan vooraf het foutgedrag. Een strikte modus kan vereisen dat elke feitelijke paragraaf ten minste één citaat bevat, of dat het uiteindelijke antwoord citaten bevat uit opgehaalde delen boven een minimale scoredrempel. Als de geselecteerde modelaanbieder niet aan het citatiecontract kan voldoen, moet de gateway snel falen, een compatibele provider gebruiken of een gestructureerde weigering retourneren.

Dit is een aanbeveling, geen universele regel. De strikte citatiemodus verbetert het vertrouwen, maar kan het aantal weigeringen, nieuwe pogingen en de complexiteit van terugval vergroten. Voor creatieve workflows met een laag risico kunnen citaten optioneel zijn. Voor klantgerichte ondersteuning of gereguleerde interne workflows moet citation_required vaak deel uitmaken van het ophaalprofiel.

Indexlevenscyclus is een productkenmerk

RAG-systemen verzamelen gegevens. Tijdelijke uploads worden per ongeluk permanent. Voormalige klanten laten inbedding achter. Productteams veranderen chunkingstrategieën en vergeten oude indexen opnieuw op te bouwen.Een gateway moet de controles op de levenscyclus expliciet maken.

Aanbevolen controles op de levenscyclus zijn onder meer:

• Tijdelijke vervaldatum van het corpus: documenten die zijn geüpload voor een kortstondige sessie moeten een vervaltijdstempel en een verwijderingstaak hebben.
• Tenant offboarding: het verwijderen van een tenant moet leiden tot het verwijderen van naamruimten, shards, providervectorstores en aanverwante zaken bestandsobjecten.
• Afhandeling van koude tenants: indien ondersteund, kunnen inactieve tenants als inactief of offload worden gemarkeerd om het gebruik van bronnen te verminderen.
• Versiecontrole opnieuw indexeren: het insluitingsmodel, het chunkingbeleid, de parserversie en indexed_at voor elk chunk opslaan.
• Blootstelling aan verwijderingsstatus: Partner API-workflows moeten laten zien of documentverwijdering, vectorverwijdering en providerzijde het verwijderen is voltooid.

Het belangrijke feit is dat sommige vectoropslaginhoud behouden blijft totdat deze wordt verwijderd. De architectuuraanbeveling is om de verwijdering zichtbaar en testbaar te maken in plaats van deze te begraven in een asynchrone taak zonder klantgerichte status.

Volg drie kostengrootboeken

Een enkel tokengrootboek is niet genoeg voor RAG. Een gateway heeft ten minste drie grootboeken nodig:

• Kosten voor inbedden en indexeren: het parseren van documenten, chunking, insluiten van aanroepen, bestandsopslag, schrijven van indexen en opnieuw indexeren.
• Ophaalkosten: lezen van vectordatabases, zoeken in native vectorwinkels, herrangschikken, herschrijven van zoekopdrachten en uitbreiden van resultaten.
• Generatiekosten: invoertokens uit gebruikersberichten en opgehaald context, outputtokens, toolaanroepen, nieuwe pogingen en fallbacks.

Dit is vooral belangrijk voor bureaus, SaaS-leveranciers en interne platformteams die AI-kosten doorverkopen of toewijzen. Zonder afzonderlijke grootboeken worden de RAG-marges moeilijk uit te leggen. Een tenant met een klein generatiegebruik kan nog steeds duur zijn als hij voortdurend documenten uploadt, grote corpora opnieuw indexeert of brede ophaalquery's uitvoert.

Elke grootboekgebeurtenis moet tenant_id, customer_id indien verschillend, API-sleutel-id, retrieval_profile, corpus_id, model, provider, trace_id en factureerbare eenheden bevatten. Hierdoor kunnen gebruiksanalyses praktische vragen beantwoorden: welke huurders dure ophaalprofielen hebben, welke corpora oud zijn, welke modellen citatiefouten veroorzaken en welke klanten te grote prompts genereren omdat het ophalen te veel context retourneert.

Foutmodi om te testen

Een gateway-RAG-subsysteem zou tests moeten hebben voor de faalmodi die voor de klant zichtbare schade veroorzaken:

• Ontbrekende citaten: citation_required is waar, maar het antwoord van de provider bevat geen bruikbare citatiereferenties.
• Verouderde indexen: een document is bijgewerkt of verwijderd, maar oude delen verschijnen nog steeds in de ophaalresultaten.
• Tenant-mismatch: het verzoek wordt omgezet naar tenant A, terwijl het corpus of de naamruimte toebehoort aan tenant B.
• Overbred ophalen: het profiel retourneert te veel brokken, waardoor de kosten stijgen en de kwaliteit van de antwoorden afneemt.
• Brokkengrootte komt niet overeen: brokken zijn zo groot dat citaties onnauwkeurig zijn, of zo klein dat de context betekenis verliest.
• Provider-functie komt niet overeen: het ene model kan citaties in de vereiste vorm uitzenden, terwijl het andere dat niet kan.
• Mislukt in de levenscyclus: verwijdering is aangevraagd, maar opslag aan de providerzijde blijft actief of niet geverifieerd.

Deze tests moeten worden uitgevoerd op gatewaycontractniveau, niet alleen binnen één provideradapter. Het doel is om te bewijzen dat het publieke gedrag stabiel blijft wanneer de herstelbackend of generatieprovider verandert.

Afwegingen

Het ophalen van native providers kan de applicatiecode verminderen en een eerste versie versnellen. De wisselwerking is dat de levenscyclus van de opslag, het citatieformaat, de controle op zoekopdrachten en de beschikbaarheid van functies gebonden kunnen worden aan één provider.

Externe vectordatabases voegen operationele oppervlakte toe. Het voordeel is een sterkere portabiliteit tussen OpenAI-compatibele modellen, Anthropic-modellen en toekomstige providers. Ze maken het ook gemakkelijker om op tenants gerichte naamruimten of shards te beredeneren wanneer de gateway verantwoordelijk is voor facturering en offboarding.

Fijnkorrelige brokken verbeteren de citatieprecisie en controleerbaarheid. Ze vergroten ook de indexgrootte, het ophaalvolume en de complexiteit van de promptassemblage. Grove stukken zijn eenvoudiger, maar ze kunnen citaten opleveren die naar een brede pagina of sectie verwijzen in plaats van naar de exacte ondersteunende passage.

De strikte citatie-vereiste modus verbetert het vertrouwen van de gebruiker.Het dwingt de gateway ook om modellen te verwerken die niet het vereiste citatieformaat kunnen produceren, wat kan betekenen dat het verzoek moet worden geweigerd, modellen moeten worden gewijzigd of een antwoord moet worden geretourneerd met een lagere betrouwbaarheidsstatus.

Voorspelling: het ophalen zal meer native worden, maar gateways hebben nog steeds hun eigen contract nodig

Provider-native ophaalfuncties zullen waarschijnlijk capabeler worden. Meer modellen zullen de opgehaalde context met gestructureerde bronmetagegevens accepteren. Meer API's zullen rangschikkingscontroles, het herschrijven van zoekopdrachten en citatie-instellingen blootleggen. Dat neemt de noodzaak van een gatewaycontract niet weg.

De gateway is nog steeds eigenaar van de tenantidentiteit, sleutelbeheer, bestedingslimieten, gebruiksanalyses, Partner API-workflows en klantgerichte verwijderingsbeloften. Providerfuncties kunnen achter de adapterlaag worden gebruikt, maar het product mag niet elke tenant, model en factureringsworkflow in de ophaalabstractie van één provider dwingen.

Bruikbare conclusie

Bouw RAG voor meerdere tenants als een gateway-subsysteem met expliciete grenzen. Los de identiteit van de tenant op voordat deze wordt opgehaald. Gebruik op tenants gerichte naamruimten, shards of vectorarchieven. Houd het ophalen achter adapters. Normaliseer citaten in een schema dat eigendom is van de gateway. Voeg levenscyclusstatussen en verwijderingsverificatie toe. Houd de kosten voor het insluiten, ophalen en genereren afzonderlijk bij.

Deze architectuur houdt RAG geaard zonder het product aan één ophaalprovider te koppelen. Het geeft teams ook de operationele controles die ze nodig hebben wanneer een AI-assistent overstapt van een prototype naar een klantgericht systeem: isolatie, citaties, portabiliteit, levenscyclusbeheer en kostentoeschrijving.

Gerelateerd lezen

• trace ophalen, tokengebruik en tenantanalyse in één observatiemodel
• providerspecifieke output achter een stabiel gatewaycontract normaliseren
• verbind de provisioning en gebruiksmeting van tenants met Partner API-workflows