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 modelaanbieder. De gateway moet huurdergegevens geïsoleerd houden, citaten van modelaanbieders behouden, geïndexeerde inhoud op tijd verwijderen en de insluitings-, ophaal- en generatiekosten aan de juiste klant toeschrijven.

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

Een team dat een AI-assistent bouwt, begint voor veel klanten meestal met een eenvoudige stroom: documenten uploaden, segmenten insluiten, de beste overeenkomsten ophalen, deze 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 heeft deze architectuur waarschijnlijk flexibiliteit nodig omdat de functies voor het ophalen van providers steeds 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 canonical tenant_id.
• Ophaalprofiel: definieert welk corpus moet worden doorzocht, welk insluitingsmodel moet worden gebruikt, het aantal resultaten, filters, herschikkingsopties, 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 opgehaalde context door aan de gekozen modelprovider zonder vector-backend-details bloot te stellen aan bellers.
• Gebruiks- en auditgrootboek: records insluiten, indexeren, ophalen, prompttokens, voltooiingstokens, tenant, model, provider en tracering identifiers.

Een minimaal verzoekcontract kan providerneutraal blijven:

{
  "tenant_id": "tenant_123",
  "model": "gpt-compatible-or-claude-compatible-model",
  "retrieval_profile": "support_docs_v2",
  "citation_required": true,
  "messages": [
    {"role": "user", "content": "What is our refund policy for annual plans?"}
  ]
}

Het antwoord moet ook providerneutraal zijn:

{
  "answer": "Annual plans can be refunded within the configured policy window...",
  "citations": [
    {
      "source_id": "doc_789",
      "title": "Billing Policy",
      "url_or_internal_ref": "kb://billing-policy",
      "chunk_id": "chunk_044",
      "offsets": {"page": 3},
      "score": 0.82,
      "retrieval_provider": "vector_db",
      "model_provider": "openai_compatible",
      "provider_payload": {}
    }
  ],
  "retrieval_trace_id": "rt_456",
  "billable_tenant": "tenant_123",
  "embedding_usage": null,
  "retrieval_usage": {"queries": 1, "results": 6},
  "model_usage": {"input_tokens": 1920, "output_tokens": 180}
}

Feit: de ophaalfuncties van de provider zijn niet identiek

OpenAI's vectorwinkels API ondersteunen 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 het contract verlaat 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 laat een ander patroon voor citaties zien. Applicaties kunnen inhoudsblokken voor zoekresultaten voorzien van bron- en titelmetagegevens, en wanneer citaten zijn ingeschakeld, kan het model citatiereferenties aan de gegenereerde tekst koppelen. 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 Ophaalfunctie Adapters, geen ophaaladapter

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

• Ophalen van native provider: handig wanneer een klant het snelste pad wil naar de functies voor het zoeken naar bestanden of vectoropslag van één provider.
• Externe vectordatabase: handig wanneer het product veel modelproviders moet ondersteunen met consistente tenantisolatie en levenscyclus controls.
• 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: string;
  tenantId: string;
  corpusId: string;
  chunks: Array<{
    sourceId: string;
    title: string;
    text: string;
    urlOrInternalRef?: string;
    chunkId: string;
    offsets?: { page?: number; byteStart?: number; byteEnd?: number; tokenStart?: number; tokenEnd?: number };
    score?: number;
    metadata: Record<string, string | number | boolean>;
    providerPayload?: unknown;
  }>;
  retrievalUsage: {
    provider: string;
    queryCount: number;
    resultCount: number;
    billableUnits?: number;
  };
}

Hierdoor kan de generatielaag context ontvangen zonder te weten of deze afkomstig is van OpenAI vectorwinkels, Pinecone, Weaviate, een zoekindex voor de volledige tekst 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 ontstaat voor zelden gebruikte tenants.

Implementatiechecklist

• Los tenant_id op vanuit de geverifieerde gateway-identiteit, niet alleen vanuit een door de gebruiker aangeleverd hoofdveld.
• Wijs tenant_id toe aan een vectornaamruimte, shard of vectorwinkel-ID van een provider via een register aan de serverzijde.
• Weiger 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.
• Logboeknaamruimte, shard, corpus_id, retrieval_profile en retrieval_trace_id voor controleerbaarheid.

Reserveer zoekopdrachten tussen tenants voor expliciete administratieve workflows met afzonderlijke autorisatie, afzonderlijke indexen of gecontroleerde aggregatiepaden. Zorg ervoor dat zoekopdrachten tussen verschillende tenants niet een toevallig neveneffect van metagegevensfilters worden.

Normaliseer citaten als gateway-objecten

Citaties zijn een productcontract en niet alleen maar decoratie. Een assistent voor de klantenondersteuning, een hulpprogramma voor het opstellen van juridische documenten of een 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": "Refund Terms",
  "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": "anthropic",
  "model_provider_citation_payload": {}
}

Houd de genormaliseerde velden stabiel en sta providerspecifieke extensies 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 een identieke 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 in de wachtrij worden geplaatst verwijdering van naamruimten, shards, vectorarchieven van providers en gerelateerde bestandsobjecten.
• Afhandeling van koude tenants: waar ondersteund, kunnen inactieve tenants als inactief of offload worden gemarkeerd om het gebruik van bronnen te verminderen.
• Versiecontrole opnieuw indexeren: winkelinsluitingsmodel, chunkingbeleid, parserversie en indexed_at voor elk chunk.
• Blootstelling aan verwijderingsstatus: Partner API-workflows moeten laten zien of het verwijderen van documenten, het verwijderen van vectoren en het verwijderen aan de providerzijde zijn 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 insluiten en indexeren: parseren, chunken, insluiten van aanroepen, bestandsopslag, indexschrijven en opnieuw indexeren.
• Ophaalkosten: vectordatabaselezingen, zoeken in native vectorwinkel, herrangschikken, herschrijven van zoekopdrachten en resultaat uitbreiding.
• Generatiekosten: invoertokens uit gebruikersberichten en opgehaalde context, uitvoertokens, 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 verouderd 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:

• Ontbreekt citations: 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 komt niet overeen: het verzoek wordt omgezet naar tenant A, terwijl het corpus of de naamruimte toebehoort aan tenant B.
• Te breed ophalen: het profiel retourneert te veel delen, waardoor de kosten stijgen en de antwoordkwaliteit afneemt.
• Brokkengrootte komt niet overeen: delen zijn zo groot dat citaten onnauwkeurig zijn, of zo klein dat de context betekenis verliest.
• Provider-functie mismatch: het ene model kan citaten 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 het gatewaycontractniveau, niet alleen binnen één provideradapter. Het doel is om te bewijzen dat het publieke gedrag stabiel blijft wanneer de backend- of generatieprovider voor het ophalen verandert.

Afwegingen

Het ophalen van de native provider 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 afhankelijk kunnen worden van één provider.

Externe vectordatabases voegen operationele oppervlakte toe. Het voordeel is een sterkere draagbaarheid 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 segmenten 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 beter in staat zijn. 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 identiteit van de huurder, het sleutelbeheer, de 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.

Actionable Conclusion

Bouw multi-tenant RAG 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, overdraagbaarheid, levenscyclusbeheer en kostentoeschrijving.

Gerelateerd lezen

• het ophalen van sporen, tokengebruik en tenantanalyses in één observatiemodel
• normaliseren van providerspecifieke output achter een stabiel gatewaycontract
• Verbind de tenantinrichting en gebruiksmeting met Partner API-workflows