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

Kundevendte AI-assistenter har brug for genfinding-augmented generation, men RAG bliver sværere, når anmodninger flyder gennem en OpenAI-kompatibel API-gateway i stedet for én modeludbyders oprindelige stack. Gatewayen skal holde lejerdata isoleret, bevare citater på tværs af modeludbydere, slette indekseret indhold efter tidsplan og tilskrive indlejring, genfinding og genereringsomkostninger til den rigtige kunde.

Det praktiske svar er at behandle hentning som et førsteklasses gateway-undersystem. Gem det ikke inde i én udbyderintegration. Hold hentning adskilt fra generation, giv hver forespørgsel en lejer-omfattet genfindingskontekst, normaliser citater, før du returnerer dem, og registrer hvert fakturerbart trin i en hovedbog.

Læserproblemet

Et team, der bygger en AI-assistent til mange kunder, starter normalt med et simpelt flow: upload dokumenter, indlejr bidder, indsæt disse prompt-snippets, indsæt disse prompt-snippets, og indsæt disse prompt-snippets. Det virker, indtil produktet har brug for flere modeludbydere, fakturering på kundeniveau, offboarding og auditabilitet.

Risikoen er ikke kun unøjagtige svar. De større operationelle risici er fejl i lejernavne, ukontrollerbare citater, uaktuelle indekser efter sletning af dokumenter og marginer, der ikke kan forklares, fordi omkostningerne til genfinding forsvinder i generiske infrastrukturudgifter.

Denne artikel adskiller fakta, anbefalinger og forudsigelser. Fakta er implementeringskapaciteter dokumenteret af nuværende udbyder og vektordatabase API'er. Anbefalingerne er arkitekturvalg for et gateway-produkt. Forudsigelserne er, hvor denne arkitektur sandsynligvis har brug for fleksibilitet, da udbyderens genfindingsfunktioner bliver ved med at ændre sig.

Referencearkitektur

Et RAG-design på gateway-niveau bør have fem komponenter:

• Lejer-resolver: kortlægger den indgående API-nøgle, arbejdsområde, kundekonto, eller en partnerisk partner. tenant_id.
• Hentningsprofil: definerer hvilket korpus der skal søges i, hvilken indlejringsmodel der skal bruges, resultatantal, filtre, genrangeringsmuligheder, krav til citering og reserveadfærd.
• Hentningsadapterlag: kalder indfødt udbyderhentning, en ekstern.
-vektortjenestedatabase gennem en >
• -intern søgegrænseflade. monterings- og generationsadapter: overfører hentet kontekst til den valgte modeludbyder uden at udsætte vektorbackend-detaljer for opkaldere.
• Brugs- og revisionsregnskab: registrerer indlejring, indeksering, hentning, prompt-tokens, færdiggørelsestokens, lejer, model, udbyder og sporingsanmodningsidentifikatorer kan forblive

{
  "tenant_id": "tenant_123",
  "model": "gpt-kompatibel-eller-claude-kompatibel-model",
  "retrieval_profile": "support_docs_v2",
  "citation_required": sandt,
  "beskeder": [
    {"role": "user", "content": "Hvad er vores refusionspolitik for årlige planer?"}
  ]
}

Svaret skal også være udbyderneutralt:

{
  "answer": "Årlige planer kan refunderes inden for det konfigurerede politikvindue...",
  "citater": [
    {
      "source_id": "doc_789",
      "title": "Faktureringspolitik",
      "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": "lejer_123",
  "embedding_usage": null,
  "retrieval_usage": {"queries": 1, "results": 6},
  "model_usage": {"input_tokens": 1920, "output_tokens": 180}}

Fakta: Funktioner til udbyderhentning er ikke identiske

OpenAIs Vector Stores API understøtter vektorlagre, der kan oprettes, søges i, konfigureres med chunking-strategier, associeres med filmetadata og slettes. Vektorbutikssøgning understøtter forespørgsler, filtre, maksimalt antal resultater, rangeringsmuligheder, scoretærskler og kontroller til omskrivning af forespørgsler. Disse kontroller giver gateway-forfattere nyttige knapper til latenstid, relevans og omkostninger.

OpenAI-platformens datakontroller gør også livscyklusdesign vigtigt: kundeindhold i vektorlagre bevares, indtil det slettes. Hvis en lejer forlader, eller hvis et midlertidigt projekt udløber, kan gatewayen ikke antage, at udbyderen automatisk vil fjerne indekseret indhold på produktets forretningsplan.

Anthropic afslører et andet mønster for citater. Applikationer kan give søgeresultatindholdsblokke med kilde- og titelmetadata, og når citater er aktiveret, kan modellen vedhæfte citationsreferencer til genereret tekst. Der er praktiske begrænsninger: Indstillinger for citat for søgeresultater er alt-eller-intet i en anmodning, søgeresultatblokke understøtter tekstindhold, og citationsgranularitet afhænger af, hvordan indholdet er opdelt i blokke.

Betydningen er direkte: En gateway bør ikke afsløre en udbyders genfindingsform som dens offentlige kontrakt, medmindre den har til hensigt at gøre den pågældende udbyder til den permanente hentningsautoritet:

Hentningsadaptere, ikke indlåsning til hentning

Opret en intern interface til henteadapter. Gatewayen kan understøtte flere backends bag sig:

• Native provider retrieval: nyttigt, når en kunde vil have den hurtigste vej ind i én udbyders filsøgning eller vektorbutiksfunktioner.
• Ekstern vektordatabase: nyttigt når produktet skal understøtte mange modeludbydere med konsekvent lejerisolering og livscyklus-resultatkontrol:
. nyttig, når gatewayen samler hentet tekst og sender den til en udbyder, der understøtter eksplicit citationsbevidst kontekst.

Adapteren skal returnere den samme interne struktur uanset backend:

interface RetrievalResult {
  retrievalTraceId: streng;
  lejerId: streng;
  corpusId: streng;
  chunks: Array<{
    sourceId: streng;
    titel: streng;
    tekst: streng;
    urlOrInternalRef?: streng;
    chunkId: streng;
    offsets?: { side?: nummer; byteStart?: nummer; byteEnd?: nummer; tokenStart?: nummer; tokenEnd?: nummer };
    score?: antal;
    metadata: Optag;
    providerPayload?: ukendt;
  }>;
  retrievalUsage: {
    udbyder: streng;
    queryCount: antal;
    resultCount: antal;
    fakturerbareEnheder?: nummer;
  };}

Dette lader generationslaget modtage kontekst uden at vide, om det kom fra OpenAI vektorlagre, Pinecone, Weaviate, et database fuldtekst søgeindeks eller en intern hybrid retriever.

Lejerisolering starter før vektorforespørgslen

Lejerisolering må ikke afhænge af promptinstruktioner. Det skal håndhæves før hentning, ved lagergrænsen og forespørgselsgrænsen.

For systemer i Pinecone-stil er det dokumenterede multitenancy-mønster ét navneområde pr. lejer i serverløse indekser. Dataplanoperationer er målrettet mod et navneområde, hvilket forenkler lejerisolering og offboarding, fordi sletning af navneområdet fjerner lejerens registreringer. Pinecone dokumenterer også afvejninger mellem navnerum og metadatafiltrering: filtrering i et stort delt navnerum kan scanne flere data, koste mere og udføre langsommere forespørgsler end navneområdeomfanget.

For systemer i Weaviate-stil gemmer multi-lejer hver lejer på et separat shard, så en lejers data er ikke synlige for en anden lejer. Sletning af lejer sletter det tilknyttede shard. Weaviate understøtter også lejertilstande såsom aktiv, inaktiv og aflastet, hvilket skaber en livscyklusmulighed for sjældent brugte lejere.

Implementeringstjekliste

• Løs tenant_id fra den autentificerede gateway-identitet, ikke fra et brugerleveret kropsfelt alene.
• Giv et vektornavn, en vektor-butik eller en vektor-identifikation. et register på serversiden.
• Afvis anmodninger, hvor API-nøglelejeren og den anmodede korpuslejer ikke stemmer overens.
• Hold delte offentlige korpora adskilt fra private lejerkorporaer.
• Brug metadatafiltrering for dokumenttype, sprog, produktområde eller datointerval, efter lejergrænsen allerede er valgt
• Log, corpus,
• Log, corpus,

Reserver søgning på tværs af lejere for eksplicitte administrative arbejdsgange med separat autorisation, separate indekser eller kontrollerede aggregeringsstier. Gør ikke søgning på tværs af lejere til en utilsigtet bivirkning af metadatafiltre.

Normaliser citater som gatewayobjekter

Citater er en produktkontrakt, ikke kun dekoration. En kundesupportassistent, juridisk udarbejdelsesværktøj eller intern vidensassistent skal vise, hvorfor et svar blev produceret, og hvor den understøttende tekst kom fra.

Gatewayen skal normalisere citatdata til sit eget skema:

{
  "source_id": "doc_123",
  "title": "Refusionsbetingelser",
  "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": "antropisk",
  "model_provider_citation_payload": {}
}

Hold de normaliserede felter stabile og tillad udbyderspecifikke udvidelser. Nogle udbydere vil afsløre rigere citatdetaljer end andre. Nogle vil citere søgeresultatblokke. Nogle vil citere uploadede filer. Nogle vil ikke give det nøjagtige offset-format, som din applikation ønsker. Gatewayen bør bevare det eksisterende uden at lade som om, at hver udbyder har identisk citationssemantik.

Strikt citationstilstand

Når citation_required er sandt, skal du definere fejladfærd på forhånd. En streng tilstand kan kræve, at hvert faktuelt afsnit indeholder mindst én citat, eller at det endelige svar indeholder citater fra hentede bidder over en minimumsscoretærskel. Hvis den valgte modeludbyder ikke kan opfylde citationskontrakten, bør gatewayen fejle hurtigt, bruge en kompatibel udbyder eller returnere et struktureret afslag.

Dette er en anbefaling, ikke en universel regel. Streng citattilstand forbedrer tilliden, men det kan øge afvisninger, genforsøg og fallback-kompleksitet. For kreative arbejdsgange med lav risiko kan citater være valgfrie. Til kundevendt support eller regulerede interne arbejdsgange bør citation_required ofte være en del af genfindingsprofilen.

Index Lifecycle Is a Product Feature

RAG-systemer akkumulerer data. Midlertidige uploads bliver permanente ved et uheld. Tidligere kunder efterlader indlejringer. Produktteams ændrer chunking-strategier og glemmer at genopbygge gamle indekser.En gateway skal gøre livscykluskontroller eksplicitte.

Anbefalede livscykluskontroller omfatter:

• Midlertidig korpusudløb: dokumenter, der er uploadet til en kortvarig session, skal have et udløbstidsstempel og et sletningsjob.
• Lejer offboarding: enqueue, tenant of names: enqueue, tenant of names. vektorlagre og relaterede filobjekter.
• Kold lejerhåndtering:hvor understøttede, inaktive lejere kan markeres som inaktive eller aflades for at reducere ressourceforbrug.
• Genindeksering af versionskontrol: butiksindlejringsmodel, chunking-politik, parserversion og indexed_at for hver del af eksponeringen for hver chunk.
Delele>

Det vigtige faktum er, at noget vektorlagerindhold bevares, indtil det slettes. Arkitekturanbefalingen er at gøre sletning synlig og testbar i stedet for at begrave den i et asynkront job uden en kundevendt tilstand.

Spor Three Cost Ledgers

En enkelt token-reskontro er ikke nok til RAG. En gateway har brug for mindst tre hovedbøger:

• Indlejrings- og indekseringsomkostninger: dokumentparsing, chunking, indlejringskald, fillagring, indeksskrivning og genindeksering.
• Hentningsomkostninger: vektordatabaselæsninger, native vektorlagersøgning, reranking, forespørgsel og inputtokens fra brugermeddelelser og hentet kontekst, outputtokens, værktøjskald, genforsøg og fallbacks.

Dette er især vigtigt for bureauer, SaaS-leverandører og interne platformsteams, der videresælger eller allokerer AI-omkostninger. Uden separate hovedbøger bliver RAG-margener svære at forklare. En lejer med lille generationsforbrug kan stadig være dyr, hvis den konstant uploader dokumenter, genindekserer store korpora eller kører brede hentningsforespørgsler.

Hver hovedbogsbegivenhed skal indeholde tenant_id, customer_id if different, API key id, retrieval_profile, corpus_id, model, provider, trace_id og fakturerbare enheder. Dette lader brugsanalyser besvare praktiske spørgsmål: hvilke lejere der har dyre genfindingsprofiler, hvilke korpora er forældede, hvilke modeller producerer citationsfejl, og hvilke kunder genererer overdimensionerede prompter, fordi genfinding returnerer for meget kontekst.

Fejltilstande til test

Et gateway RAG-undersystem bør have tests, der kan se kundens fejltilstande. skade:

• Manglende citater: citation_required er sandt, men udbyderens svar indeholder ingen brugbare citationsreferencer.
• Forældede indekser: et dokument blev opdateret eller slettet, men gamle bidder vises stadig i genfindingsresultater.
• Tenant mismatch the tenant or the corpus. navneområde tilhører lejer B.
• Over bred hentning: profilen returnerer for mange bidder, hvilket øger omkostningerne og fortynder svarkvaliteten.
• Kunkstørrelsesmismatch: bidder er så store, at citater er upræcise, eller så små, at konteksten mister mening i en funktionsmodel. den påkrævede form, mens en anden ikke kan.
• Livscyklusfejl: Der anmodes om sletning, men udbydersiden forbliver aktiv eller ubekræftet.

Disse tests bør køre på gateway-kontraktniveau, ikke kun inde i én udbyderadapter. Målet er at bevise, at den offentlige adfærd forbliver stabil, når backend- eller generationsleverandøren til hentning ændres.

Trade-Offs

Native provider-hentning kan reducere applikationskoden og fremskynde en første version. Afvejningen er, at lagerlivscyklus, citationsformat, forespørgselskontroller og funktionstilgængelighed kan blive knyttet til én udbyder.

Eksterne vektordatabaser tilføjer operationelt overfladeareal. Fordelen er stærkere portabilitet på tværs af OpenAI-kompatible modeller, antropiske modeller og fremtidige udbydere. De gør også lejer-omfattede navneområder eller shards nemmere at ræsonnere om, når gatewayen er ansvarlig for fakturering og offboarding.

Finkornede bidder forbedrer citationspræcision og auditerbarhed. De øger også indeksstørrelsen, hentningsvolumen og prompter monteringskompleksiteten. Grove bidder er enklere, men de kan producere citater, der peger på en bred side eller sektion i stedet for den nøjagtige understøttende passage.

Streng citat-påkrævet tilstand forbedrer brugernes tillid.Det tvinger også gatewayen til at håndtere modeller, der ikke kan producere det påkrævede citationsformat, hvilket kan betyde, at man afviser anmodningen, ændrer modeller eller returnerer et svar med en lavere konfidenstilstand.

Forudsigelse: Hentning vil blive mere indbygget, men gateways har stadig brug for deres egen kontrakt

Provider-funktioner vil sandsynligvis blive mere tilgængelige. Flere modeller vil acceptere hentet kontekst med struktureret kildemetadata. Flere API'er vil afsløre rangeringskontroller, forespørgselsomskrivning og citationsindstillinger. Det fjerner ikke behovet for en gateway-kontrakt.

Gatewayen ejer stadig lejeridentitet, nøgleadministration, forbrugsgrænser, brugsanalyse, Partner API-arbejdsgange og kundevendte løfter om sletning. Udbyderfunktioner kan bruges bag adapterlaget, men produktet bør ikke tvinge hver lejer, model og faktureringsarbejdsgang ind i én udbyders genfindingsabstraktion.

Aktiv konklusion

Byg multi-tenant RAG som et gateway-undersystem med eksplicitte grænser. Løs lejeridentitet før hentning. Brug lejer-omfattede navnerum, shards eller vektorbutikker. Hold hentning bag adaptere. Normaliser citater til et gateway-ejet skema. Tilføj livscyklustilstande og sletningsbekræftelse. Spor indlejrings-, hentning- og generationsomkostninger separat.

Denne arkitektur holder RAG jordet uden at låse produktet til én genfindingsudbyder. Det giver også teams de operationelle kontroller, de har brug for, når en AI-assistent flytter fra en prototype til et kundevendt system: isolering, citater, portabilitet, livscyklusstyring og omkostningstilskrivning.

Relateret læsning

• sporingshentning, tokenbrug og lejeranalyse i én observerbarhedsmodel
• normaliser udbyderspecifikke output bag en stabil gateway-kontrakt
• tilslut lejerklargøring og brugsmåling til Partner API-arbejdsgange