Multi-Tenant RAG bakom en OpenAI-kompatibel API-gateway

Kundvända AI-assistenter behöver generering med utökad hämtning, men RAG blir svårare när förfrågningar flödar genom en OpenAI-kompatibel API-gateway istället för en modellleverantörs ursprungliga stack. Gatewayen måste hålla hyresgästdata isolerad, bevara citeringar mellan modellleverantörer, radera indexerat innehåll enligt schemat och tillskriva inbäddning, hämtning och genereringskostnader till rätt kund.

Det praktiska svaret är att behandla hämtning som ett förstklassigt gateway-undersystem. Göm det inte i en leverantörsintegration. Håll hämtning åtskild från generation, ge varje förfrågan ett hämtningssammanhang med hyresgäster, normalisera citat innan du returnerar dem och registrera varje fakturerbart steg i en reskontra.

Läsarproblemet

Ett team som bygger en AI-assistent för många kunder börjar vanligtvis med ett enkelt flöde: ladda upp dokument, bädda in bitar, hämta de här promptsiffrorna, i en modell för att be om svarsmatchningar. Det fungerar tills produkten behöver flera modellleverantörer, fakturering på kundnivå, offboarding och granskning.

Risken är inte bara felaktiga svar. De större operativa riskerna är misstag i hyresgästens namnområde, okontrollerbara citeringar, inaktuella index efter borttagning av dokument och marginaler som inte kan förklaras eftersom hämtningskostnader försvinner i generiska infrastrukturutgifter.

Den här artikeln separerar fakta, rekommendationer och förutsägelser. Fakta är implementeringsmöjligheter dokumenterade av nuvarande leverantör och vektordatabas API:er. Rekommendationerna är arkitekturval för en gatewayprodukt. Förutsägelserna är där den här arkitekturen sannolikt kommer att behöva flexibilitet eftersom funktioner för hämtning av leverantörer hela tiden förändras.

Referensarkitektur

En RAG-design på gatewaynivå bör ha fem komponenter:

• Tenant resolver: mappar den inkommande API-nyckeln, arbetsytan, kundkontot, eller Partnerical. tenant_id.
• Hämtningsprofil: definierar vilken korpus som ska sökas, vilken inbäddningsmodell som ska användas, resultatantal, filter, omrankningsalternativ, krav på hänvisningar och reservbeteende.
• Hämtningsadapterlager: anropar inbyggd leverantörshämtning, en extern.
anpassad söktjänstvektordatabas genom en >
• intern söktjänstdatabas, en >
• intern. monterings- och genereringsadapter: skickar hämtad kontext till den valda modellleverantören utan att exponera vektorbackend-detaljer för anropare.
• Användnings- och revisionsreskontra: registrerar inbäddning, indexering, hämtning, prompttokens, kompletteringstokens, hyresgäst, modell, leverantör och spårningsbegäran kan stanna
<-identifierare. leverantörsneutral:

{
  "tenant_id": "tenant_123",
  "model": "gpt-kompatibel-eller-claude-kompatibel-modell",
  "retrieval_profile": "support_docs_v2",
  "citation_required": sant,
  "meddelanden": [
    {"role": "user", "content": "Vad är vår återbetalningspolicy för årliga planer?"}
  ]
}

Svaret bör också vara leverantörsneutralt:

{
  "answer": "Årsplaner kan återbetalas inom det konfigurerade policyfönstret...",
  "citat": [
    {
      "source_id": "doc_789",
      "title": "Faktureringspolicy",
      "url_or_internal_ref": "kb://faktureringspolicy",
      "chunk_id": "chunk_044",
      "offsets": {"page": 3},
      "poäng": 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}}

Fakta: Funktioner för hämtning av leverantörer är inte identiska

OpenAI:s Vector Stores API stöder vektorlager som kan skapas, genomsökas, konfigureras med chunking-strategier, associeras med filmetadata och tas bort. Vektorbutiksökning stöder frågor, filter, maximalt antal resultat, rankningsalternativ, poängtrösklar och kontroller för omskrivning av frågor. Dessa kontroller ger gatewayförfattare användbara rattar för latens, relevans och kostnad.

Datakontroller för OpenAI-plattformen gör också livscykeldesign viktig: kundinnehåll i vektorbutiker behålls tills det raderas. Om en hyresgäst hoppar av, eller om ett tillfälligt projekt löper ut, kan gatewayen inte anta att leverantören tar bort indexerat innehåll automatiskt enligt produktens affärsschema.

Anthropic avslöjar ett annat mönster för citeringar. Applikationer kan tillhandahålla innehållsblock för sökresultat med käll- och titelmetadata, och när citeringar är aktiverade kan modellen bifoga hänvisningsreferenser till genererad text. Det finns praktiska begränsningar: inställningarna för citat för sökresultat är allt-eller-inget i en begäran, sökresultatblock stöder textinnehåll och citeringsgranularitet beror på hur innehållet är uppdelat i block.

Konsekvensen är direkt: en gateway ska inte avslöja en leverantörs hämtningsform som dess offentliga kontrakt om den inte har för avsikt att göra den leverantören till den permanenta hämtningsmyndigheten:

Rekommenderad hämtning. Hämtningsadaptrar, inte låsning för hämtning

Skapa ett internt gränssnitt för hämtningsadapter. Gatewayen kan stödja flera backends bakom den:

• Hämtning av inbyggd leverantör: användbar när en kund vill ha den snabbaste vägen till en leverantörs filsöknings- eller vektorbutiksfunktioner.
• Extern vektordatabas: användbar när produkten måste stödja många modellleverantörer med konsekvent hyresgästisolering och livscykelkontroller för sökresultat:
• . användbar när gatewayen sammanställer hämtad text och skickar den till en leverantör som stöder explicit citeringsmedveten kontext.

Adaptern bör returnera samma interna struktur oavsett backend:

interface RetrievalResult {
  retrievalTraceId: sträng;
  tenantId: sträng;
  corpusId: sträng;
  chunks: Array<{
    sourceId: sträng;
    titel: sträng;
    text: sträng;
    urlOrInternalRef?: sträng;
    chunkId: sträng;
    offsets?: { page?: number; byteStart?: nummer; byteEnd?: nummer; tokenStart?: nummer; tokenEnd?: nummer };
    poäng?: antal;
    metadata: Record;
    providerPayload?: okänd;
  }>;
  retrievalUsage: {
    provider: sträng;
    queryCount: nummer;
    resultCount: antal;
    fakturerbara enheter?: nummer;
  };}

Detta låter genereringsskiktet ta emot sammanhang utan att veta om det kom från OpenAI-vektorbutiker, Pinecone, Weaviate, ett sökindex för databas i fulltext eller en intern hybridhämtning.

Tenant Isolation startar före vektorfrågan

Tenant-isolering får inte bero på snabbinstruktioner. Det måste tillämpas före hämtning, vid lagringsgränsen och frågegränsen.

För Pinecone-liknande system är det dokumenterade multitenancy-mönstret ett namnområde per klient i serverlösa index. Dataplansoperationer är inriktade på ett namnområde, vilket förenklar hyresgästens isolering och offboarding eftersom en radering av namnområdet tar bort den hyresgästens uppgifter. Pinecone dokumenterar även avvägningar mellan namnutrymmen och metadatafiltrering: filtrering i ett stort delat namnområde kan skanna mer data, kosta mer och utföra långsammare sökfrågor än namnområdesområden.

För Weaviate-liknande system lagrar flera hyresgäster varje hyresgäst på ett separat fragment, så en hyresgästs data är inte synlig för en annan hyresgäst. Borttagning av hyresgäster tar bort det associerade fragmentet. Weaviate stöder även hyresgästtillstånd som aktiv, inaktiv och avladdad, vilket skapar ett livscykelalternativ för sällan använda hyresgäster.

Implementeringschecklista

• Lös tenant_id från den autentiserade gateway-identiteten, inte från enbart ett kroppsfält som användaren tillhandahållit.
• Ge en vektornamn, utrymmesidentifierare eller vektor-identifierare. ett register på serversidan.
• Avvisa förfrågningar där API-nyckelhyresgästen och den begärda corpushyresgästen inte matchar.
• Håll delade offentliga korpora åtskilda från privata hyresgästkorpora.
• Använd metadatafiltrering för dokumenttyp, språk, produktområde eller datumintervall efter att klientgränsen redan har valts ,Log, , , , , , , , . retrieval_profile och retrieval_trace_id för granskning.

Reservera sökning för flera klienter för explicita administrativa arbetsflöden med separat auktorisering, separata index eller kontrollerade aggregeringsvägar. Gör inte sökning på flera hyresgäster till en oavsiktlig bieffekt av metadatafilter.

Normalisera citeringar som gatewayobjekt

Citeringar är ett produktkontrakt, inte bara dekoration. En kundsupportassistent, juridiskt redaktionsverktyg eller intern kunskapsassistent måste visa varför ett svar togs fram och var stödtexten kom ifrån.

Gatewayen bör normalisera citatdata till sitt eget schema:

{
  "source_id": "doc_123",
  "title": "Återbetalningsvillkor",
  "url_or_internal_ref": "kb://refund-terms",
  "chunk_id": "chunk_006",
  "offsets": {"page": 2, "byte_start": 4410, "byte_end": 5020},
  "poäng": 0,79,
  "retrieval_provider": "weaviate",
  "model_provider": "antropisk",
  "model_provider_citation_payload": {}
}

Håll de normaliserade fälten stabila och tillåt leverantörsspecifika tillägg. Vissa leverantörer kommer att avslöja rikare citatdetaljer än andra. Vissa kommer att citera sökresultatblock. Vissa kommer att citera uppladdade filer. Vissa kommer inte att tillhandahålla det exakta offsetformatet som din applikation vill ha. Gatewayen bör bevara det som finns utan att låtsas att alla leverantörer har identisk citeringssemantik.

Strikt citeringsläge

När citation_required är sant, definiera felbeteende i förväg. Ett strikt läge kan kräva att varje faktastycke innehåller minst ett citat, eller att det slutliga svaret innehåller citat från hämtade bitar över en lägsta poängtröskel. Om den valda modellleverantören inte kan uppfylla citeringskontraktet bör gatewayen misslyckas snabbt, använda en kompatibel leverantör eller returnera ett strukturerat avslag.

Detta är en rekommendation, inte en universell regel. Strikt citeringsläge förbättrar förtroendet, men det kan öka avslag, omförsök och reservkomplexitet. För kreativa arbetsflöden med låg risk kan hänvisningar vara valfria. För kundinriktad support eller reglerade interna arbetsflöden bör citation_required ofta vara en del av hämtningsprofilen.

Indexlivscykel är en produktfunktion

RAG-system samlar data. Tillfälliga uppladdningar blir permanenta av misstag. Tidigare kunder lämnar efter sig inbäddningar. Produktteam ändrar chunking-strategier och glömmer att bygga om gamla index.En gateway bör göra livscykelkontroller explicita.

Rekommenderade livscykelkontroller inkluderar:

• Tillfälligt korpusförfall: dokument som laddas upp för en kortlivad session ska ha en utgångstidsstämpel och ett borttagningsjobb.
• Tenant offboarding: enqueue, tenant of nameue, tenant of name. vektorlagringar och relaterade filobjekt.
• Kall hyresgästhantering: där stöds kan inaktiva hyresgäster markeras som inaktiva eller avlastade för att minska resursanvändningen.
• Omindexering av versionskontroll: butiksinbäddningsmodell, chunkingpolicy, parserversion och indexed_at för varje bit av exponering för varje bit.
Delele>
• <> huruvida radering av dokument, vektorradering och radering på leverantörssidan har slutförts.

Det viktiga är att visst vektorlagerinnehåll behålls tills det raderas. Arkitekturrekommendationen är att göra radering synlig och testbar istället för att begrava den i ett asynkront jobb utan något kundinriktat tillstånd.

Spåra tre kostnadsreskontra

En enda token-reskontra räcker inte för RAG. En gateway behöver minst tre reskontra:

• Inbäddnings- och indexeringskostnad: dokumentanalys, chunking, inbäddningsanrop, fillagring, indexskrivningar och återindexering.
• Hämtningskostnad: läser vektordatabaser, inbyggd vektorlagringssökning, omrankning
av resultat,
• indatatoken från användarmeddelanden och hämtade sammanhang, utdatatoken, verktygsanrop, återförsök och reservdelar.

Detta är särskilt viktigt för byråer, SaaS-leverantörer och interna plattformsteam som återförsäljer eller allokerar AI-kostnader. Utan separata reskontra blir RAG-marginalerna svåra att förklara. En hyresgäst med liten generationsanvändning kan fortfarande vara dyr om den ständigt laddar upp dokument, indexerar om stora korpora eller kör breda hämtningsfrågor.

Varje reskontrohändelse bör inkludera tenant_id, customer_id if different, API key id, retrieval_profile, corpus_id, model, provider, trace_id och fakturerbara enheter. Detta låter användningsanalyser svara på praktiska frågor: vilka hyresgäster som har dyra hämtningsprofiler, vilka korpora som är inaktuella, vilka modeller som producerar citeringsfel och vilka kunder som genererar överdimensionerade uppmaningar eftersom hämtning returnerar för mycket sammanhang.

Fejllägen att testa

Ett gateway RAG-undersystem bör ha tester som är synliga för kundfel. skada:

• Saknade citat: citation_required är sant, men leverantörens svar innehåller inga användbara citatreferenser.
• Inaktuella index: ett dokument uppdaterades eller raderades, men gamla bitar visas fortfarande i hämtningsresultat.
• Tenant begär att en reläser inte matchar, eller tar bort den namnrymden tillhör hyresgästen B.
• Överbred hämtning: profilen returnerar för många bitar, vilket ökar kostnaderna och späder på svarskvaliteten.
• Bunkstorleksfel matchar: bitar är så stora att citat är oprecisa, eller så små att sammanhanget förlorar betydelse i en funktionsmodell.
• den önskade formen medan en annan inte kan.
• Livscykelfel: radering begärs men lagring på leverantörssidan förblir aktiv eller overifierad.

Dessa tester bör köras på gatewaykontraktsnivå, inte bara inuti en leverantörsadapter. Målet är att bevisa att det offentliga beteendet förblir stabilt när leverantören för hämtning av backend eller generation ändras.

Korter

Hämtning av inbyggd leverantör kan minska applikationskoden och påskynda en första version. Avvägningen är att lagringslivscykel, citeringsformat, frågekontroller och funktionstillgänglighet kan kopplas till en leverantör.

Externa vektordatabaser lägger till operativ yta. Fördelen är starkare portabilitet över OpenAI-kompatibla modeller, antropiska modeller och framtida leverantörer. De gör också namnutrymmen eller fragment av hyresgäster enklare att resonera kring när gatewayen ansvarar för fakturering och offboarding.

Finkorniga bitar förbättrar citeringsprecisionen och granskningsbarheten. De ökar också indexstorlek, hämtningsvolym och snabb monteringskomplexitet. Grova bitar är enklare, men de kan ge citat som pekar på en bred sida eller sektion snarare än den exakta stödjande passagen.

Strikt citeringskrävande läge förbättrar användarnas förtroende.Det tvingar också gatewayen att hantera modeller som inte kan producera det erforderliga citeringsformatet, vilket kan innebära att man avslår begäran, ändrar modeller eller returnerar ett svar med ett lägre konfidensläge.

Prognos: Hämtning kommer att bli mer inbyggd, men gateways behöver fortfarande sitt eget kontrakt

Provider-funktioner kommer sannolikt att bli fler tillgängliga. Fler modeller kommer att acceptera hämtad kontext med strukturerad källmetadata. Fler API:er kommer att exponera rankningskontroller, omskrivning av frågor och citeringsinställningar. Det tar inte bort behovet av ett gateway-kontrakt.

Gatewayen äger fortfarande hyresgästidentitet, nyckelhantering, utgiftsgränser, användningsanalys, Partner API-arbetsflöden och kundinriktade raderingslöften. Leverantörsfunktioner kan användas bakom adapterlagret, men produkten bör inte tvinga alla klienter, modeller och faktureringsarbetsflöden till en leverantörs hämtningsabstraktion.

Actionable slutsats

Bygg multi-tenant RAG som ett gateway-undersystem med explicita gränser. Fastställ hyresgästens identitet före hämtning. Använd namnutrymmen, shards eller vektorbutiker med hyresgästomfattning. Håll hämtning bakom adaptrar. Normalisera citat till ett gatewayägt schema. Lägg till livscykeltillstånd och raderingsverifiering. Spåra inbäddnings-, hämtnings- och genereringskostnader separat.

Denna arkitektur håller RAG jordad utan att låsa produkten till en hämtningsleverantör. Det ger också team de operativa kontroller de behöver när en AI-assistent går från en prototyp till ett kundinriktat system: isolering, citeringar, portabilitet, livscykelhantering och kostnadstillskrivning.

Relaterad läsning

• spårhämtning, tokenanvändning och klientanalys i en observerbarhetsmodell
• normalisera leverantörsspecifika utdata bakom ett stabilt gatewaykontrakt
• anslut tenant provisionering och användningsmätning till Partner API-arbetsflöden