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

Kundevendte AI-assistenter trenger gjenvinningsutvidet generering, men RAG blir vanskeligere når forespørsler strømmer gjennom en OpenAI-kompatibel API-gateway i stedet for én modellleverandørs opprinnelige stack. Gatewayen må holde leietakerdata isolert, bevare referanser på tvers av modellleverandører, slette indeksert innhold etter planen og tilskrive innbygging, gjenfinning og generasjonskostnader til rett kunde.

Det praktiske svaret er å behandle gjenfinning som et førsteklasses gateway-undersystem. Ikke gjem den i én leverandørintegrasjon. Hold henting atskilt fra generasjon, gi hver forespørsel en leietaker-omfattet gjenfinningskontekst, normaliser sitater før du returnerer dem, og registrer hvert fakturerbart trinn i en hovedbok.

Leserproblemet

Et team som bygger en AI-assistent for mange kunder starter vanligvis med en enkel flyt: last opp dokumenter, legg inn biter, hent disse prøveutdragene, og legg inn promp-snuttene for å spørre. Det fungerer til produktet trenger flere modellleverandører, fakturering på kundenivå, offboarding og revisjonsevne.

Risikoen er ikke bare unøyaktige svar. De større operasjonelle risikoene er feil på navneområde for leietakere, ukontrollerbare siteringer, foreldede indekser etter sletting av dokumenter og marginer som ikke kan forklares fordi gjenfinningskostnader forsvinner inn i generisk infrastrukturutgifter.

Denne artikkelen skiller fakta, anbefalinger og spådommer. Fakta er implementeringsevner dokumentert av gjeldende leverandør og vektordatabase-APIer. Anbefalingene er arkitekturvalg for et gateway-produkt. Forutsigelsene er der denne arkitekturen sannsynligvis vil trenge fleksibilitet ettersom funksjonene for gjenfinning fra leverandøren stadig endres.

Referansearkitektur

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

• Leietaker-løser: kartlegger den innkommende API-nøkkelen, arbeidsområdet, kundekontoen eller en partnerkonto. tenant_id.
• Hentingprofil: definerer hvilket korpus det skal søkes i, hvilken innebyggingsmodell som skal brukes, resultatantall, filtre, omrangeringsalternativer, krav om henvisning og reserveatferd.
• Hentingadapterlag: kaller opphenting av innebygd leverandør, en ekstern.grensesnitt-vektordatabase gjennom en > overfører hentet kontekst til den valgte modellleverandøren uten å eksponere vektorbackend-detaljer for innringere.
• Bruks- og revisjonsbok: registrerer innbygging, indeksering, henting, prompt-tokens, fullføringssymboler, leietaker, modell, leverandør og sporingsforespørsel-identifikatorer. leverandørnøytral:

  {
    "tenant_id": "tenant_123",
    "model": "gpt-kompatibel-eller-claude-kompatibel-modell",
    "retrieval_profile": "support_docs_v2",
    "citation_required": sant,
    "meldinger": [
      {"role": "user", "content": "Hva er refusjonsretningslinjene våre for årlige planer?"}
    ]
  }

  Svaret bør også være leverandørnøytralt:

  {
    "answer": "Årlige planer kan refunderes innenfor det konfigurerte policyvinduet...",
    "sitater": [
      {
        "source_id": "doc_789",
        "title": "Retningslinjer for fakturering",
        "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}}

  Fakta: funksjoner for leverandørhenting er ikke identiske

  OpenAIs Vector Stores API støtter vektorlagre som kan opprettes, søkes i, konfigureres med chunking-strategier, assosieres med filmetadata og slettes. Vektorbutikksøk støtter spørringer, filtre, maksimalt antall resultater, rangeringsalternativer, poenggrenser og kontroller for omskrivning av spørringer. Disse kontrollene gir gatewayforfattere nyttige knotter for ventetid, relevans og kostnader.

  OpenAI-plattformdatakontroller gjør også livssyklusdesign viktig: kundeinnhold i vektorlagre beholdes til det slettes. Hvis en leietaker går av, eller hvis et midlertidig prosjekt utløper, kan ikke gatewayen anta at leverandøren vil fjerne indeksert innhold automatisk på produktets forretningsplan.

  Anthropic avslører et annet mønster for siteringer. Applikasjoner kan gi innholdsblokker for søkeresultater med kilde- og tittelmetadata, og når siteringer er aktivert, kan modellen legge ved henvisningsreferanser til generert tekst. Det er praktiske begrensninger: innstillinger for sitering av søkeresultater er alt-eller-ingenting i en forespørsel, søkeresultatblokker støtter tekstinnhold, og sitatgranularitet avhenger av hvordan innholdet er delt opp i blokker.

  Implikasjonen er direkte: en gateway skal ikke avsløre en leverandørs gjenfinningsform som dens offentlige kontrakt med mindre den har til hensikt å gjøre den leverandøren til den permanente gjenhentingen.

  Hentingsadaptere, ikke gjenfinningslås

  Lag et internt grensesnitt for gjenfinningsadapter. Gatewayen kan støtte flere backends bak den:

  • Native provider retrieval:nyttig når en kunde vil ha den raskeste veien inn til én leverandørs filsøk eller vektorbutikkfunksjoner.
  • Ekstern vektordatabase: nyttig når produktet må støtte mange modellleverandører med konsistent leietakerisolasjon og livssyklusresultatkontroller

  Adapteren skal returnere den samme interne strukturen uavhengig av backend:

  interface RetrievalResult {
    retrievalTraceId: string;
    tenantId: streng;
    corpusId: streng;
    chunks: Array<{
      kilde-ID: streng;
      tittel: streng;
      tekst: streng;
      urlOrInternalRef?: streng;
      chunkId: streng;
      forskyvninger?: { side?: tall; byteStart?: nummer; byteEnd?: tall; tokenStart?: nummer; tokenEnd?: nummer };
      score?: tall;
      metadata: Record;
      providerPayload?: ukjent;
    }>;
    gjenfinningBruk: {
      leverandør: streng;
      queryCount: nummer;
      resultCount: number;
      fakturerbare enheter?: nummer;
    };}

  Dette lar generasjonslaget motta kontekst uten å vite om det kom fra OpenAI vektorlagre, Pinecone, Weaviate, en database fulltekst søkeindeks eller en intern hybrid retriever.

  Leietakerisolering starter før vektorspørringen

  Leierisolering må ikke avhenge av ledetekstinstruksjoner. Det må håndheves før henting, ved lagringsgrensen og spørringsgrensen.

  For systemer i Pinecone-stil er det dokumenterte multitenancy-mønsteret ett navneområde per leietaker i serverløse indekser. Dataplanoperasjoner retter seg mot et navneområde, noe som forenkler leietakers isolasjon og offboarding fordi sletting av navneområdet fjerner denne leietakerens poster. Pinecone dokumenterer også avveininger mellom navnerom og metadatafiltrering: filtrering inne i et stort delt navneområde kan skanne mer data, koste mer og utføre saktere spørringer enn navneomfang.

  For systemer i Weaviate-stil lagrer multi-tenancy hver leietaker på en separat shard, slik at en leietakers data ikke er synlig for en annen leietaker. Sletting av leietaker sletter det tilknyttede fragmentet. Weaviate støtter også leietakertilstander som aktiv, inaktiv og avlastet, noe som skaper et livssyklusalternativ for sjelden brukte leietakere.

  Implementeringssjekkliste

  • Løs tenant_id fra den autentiserte gateway-identiteten, ikke fra et brukeroppgitt kroppsfelt alene.
  • Oppgi en vektornavn, en vektor-identifikasjon eller en vektor-identifikasjon. et register på serversiden.
  • Avvis forespørsler der API-nøkkelleietaker og forespurt korpusleietaker ikke samsvarer.
  • Hold delte offentlige korpora atskilt fra private leietakerkorpora.
  • Bruk metadatafiltrering for dokumenttype, språk, produktområde eller datoperiode etter at leietakergrensen allerede er valgt.
  • Logli, corpus,

  Reserver søk på tvers av leietakere for eksplisitte administrative arbeidsflyter med separat autorisasjon, separate indekser eller kontrollerte aggregeringsbaner. Ikke gjør søk på tvers av leietakere til en utilsiktet bieffekt av metadatafiltre.

  Normaliser sitater som gatewayobjekter

  Siteringer er en produktkontrakt, ikke bare dekorasjon. En kundestøtteassistent, juridisk utarbeidelsesverktøy eller intern kunnskapsassistent må vise hvorfor et svar ble produsert og hvor støtteteksten kom fra.

  Gatewayen bør normalisere sitatdata til sitt eget skjema:

  {
    "source_id": "doc_123",
    "title": "Refusjonsvilkår",
    "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": "veve",
    "model_provider": "antropisk",
    "model_provider_citation_payload": {}
  }

  Hold de normaliserte feltene stabile og tillat leverandørspesifikke utvidelser. Noen leverandører vil avsløre rikere sitatdetaljer enn andre. Noen vil sitere søkeresultatblokker. Noen vil sitere opplastede filer. Noen vil ikke gi det eksakte offsetformatet applikasjonen din ønsker. Gatewayen bør bevare det som eksisterer uten å late som om hver leverandør har identisk siteringsemantikk.

  Streng sitatmodus

  Når citation_required er sant, definer feilatferd på forhånd. En streng modus kan kreve at hvert faktaavsnitt inkluderer minst én sitering, eller at det endelige svaret inneholder sitater fra hentede biter over en minimumsgrense for poengsum. Hvis den valgte modellleverandøren ikke kan tilfredsstille siteringskontrakten, bør gatewayen svikte raskt, bruke en kompatibel leverandør eller returnere et strukturert avslag.

  Dette er en anbefaling, ikke en universell regel. Streng sitatmodus forbedrer tilliten, men det kan øke avslag, gjenforsøk og fallback-kompleksitet. For kreative arbeidsflyter med lav risiko kan henvisninger være valgfrie. For kundevendt støtte eller regulerte interne arbeidsflyter, bør citation_required ofte være en del av gjenfinningsprofilen.

  Index Lifecycle er en produktfunksjon

  RAG-systemer akkumulerer data. Midlertidige opplastinger blir permanente ved et uhell. Tidligere kunder etterlater seg innebygginger. Produktteam endrer chunking-strategier og glemmer å gjenoppbygge gamle indekser.En gateway bør gjøre livssykluskontroller eksplisitt.

  Anbefalte livssykluskontroller inkluderer:

  • Midlertidig korpusutløp: dokumenter som lastes opp for en kortvarig økt skal ha et utløpstidsstempel og en slettejobb.
  • Leier offboarding: enqueue, tenant of nameue vektorlagre og relaterte filobjekter.
  • Kald leietakerhåndtering: der støttede, inaktive leietakere kan merkes som inaktive eller avlastet for å redusere ressursbruken.
  • Reindeksering av versjonskontroll: butikkinnbyggingsmodell, chunkingpolicy, parserversjon og indexed_at for hver del av eksponeringen for hver del Delele>

  Det viktige faktum er at noe vektorlagerinnhold beholdes til det slettes. Arkitekturanbefalingen er å gjøre sletting synlig og testbar i stedet for å begrave den i en asynkron jobb uten en kundevendt tilstand.

  Spor tre kostnadsreskontro

  En enkelt token-reskontro er ikke nok for RAG. En gateway trenger minst tre hovedbøker:

  • Innebyggings- og indekseringskostnader: dokumentparsing, chunking, innebygde kall, fillagring, indeksskriving og reindeksering.
  • Hentingskostnad: vektordatabaselesing, native vektorbutikksøk, reranking, query.>
  • input tokens fra brukermeldinger og hentet kontekst, output tokens, verktøykall, gjenforsøk og fallbacks.

  Dette er spesielt viktig for byråer, SaaS-leverandører og interne plattformteam som videreselger eller allokerer AI-kostnader. Uten separate reskontro blir RAG-marginene vanskelige å forklare. En leietaker med liten generasjonsbruk kan fortsatt være dyr hvis den konstant laster opp dokumenter, reindekserer store korpora eller kjører brede hentingsspørringer.

  Hver finanshendelse bør inkludere tenant_id, customer_id if different, API key id, retrieval_profile, corpus_id, model, provider, trace_id og fakturerbare enheter. Dette lar bruksanalyser svare på praktiske spørsmål: hvilke leietakere som har dyre gjenfinningsprofiler, hvilke korpora som er foreldede, hvilke modeller produserer siteringsfeil, og hvilke kunder som genererer overdimensjonerte meldinger fordi gjenfinning returnerer for mye kontekst.

  Feilmoduser å teste

  Et gateway RAG-undersystem bør ha tester som er synlige for kundens feilmodus. skade:

  • Manglende sitater: citation_required er sant, men leverandørens svar inneholder ingen brukbare sitatreferanser.
  • Foreldede indekser: et dokument ble oppdatert eller slettet, men gamle biter vises fortsatt i gjenfinningsresultater.
  • Tenant mismatch the corpu navneområdet tilhører leietaker B.
  • Overbredt gjenfinning: profilen returnerer for mange biter, øker kostnadene og fortynner svarkvaliteten.
  • Kunkstørrelsesmismatch: biter er så store at referansene er upresise, eller så små at konteksten mister mening i en funksjonsmodell.
  • den nødvendige formen mens en annen ikke kan det.
  • Livssyklusfeil: sletting er forespurt, men lagring på leverandørsiden forblir aktiv eller ubekreftet.

  Disse testene bør kjøre på gatewaykontraktnivå, ikke bare inne i én leverandøradapter. Målet er å bevise at den offentlige atferden forblir stabil når leverandøren av gjenoppretting eller generasjon endres.

  Trade-Offs

  Henting av innfødt leverandør kan redusere applikasjonskoden og akselerere en første versjon. Avveiningen er at lagringslivssyklus, siteringsformat, spørringskontroller og funksjonstilgjengelighet kan bli knyttet til én leverandør.

  Eksterne vektordatabaser legger til operasjonell overflate. Fordelen er sterkere portabilitet på tvers av OpenAI-kompatible modeller, antropiske modeller og fremtidige leverandører. De gjør også navneområder eller shards med leietaker lettere å resonnere om når gatewayen er ansvarlig for fakturering og offboarding.

  Finkornede biter forbedrer siteringspresisjon og reviderbarhet. De øker også indeksstørrelse, gjenfinningsvolum og rask monteringskompleksitet. Grove biter er enklere, men de kan produsere sitater som peker til en bred side eller en seksjon i stedet for den eksakte støtteteksten.

  Streng siteringskrevende modus forbedrer brukertilliten.Det tvinger også gatewayen til å håndtere modeller som ikke kan produsere det nødvendige sitatformatet, noe som kan bety å avslå forespørselen, endre modeller eller returnere et svar med en lavere konfidensstatus.

  Prediction: Retrieval Will Become More Native, But Gateways Still Need Their Own Contract

  Provider-funksjoner vil sannsynligvis bli mer tilgjengelige. Flere modeller vil akseptere hentet kontekst med strukturert kildemetadata. Flere APIer vil avsløre rangeringskontroller, omskriving av spørringer og innstillinger for sitering. Det fjerner ikke behovet for en gateway-kontrakt.

  Gatewayen eier fortsatt leietakeridentitet, nøkkeladministrasjon, forbruksgrenser, bruksanalyse, Partner API-arbeidsflyter og kundevendte slettingsløfter. Leverandørfunksjoner kan brukes bak adapterlaget, men produktet skal ikke tvinge hver leietaker, modell og faktureringsarbeidsflyt inn i én leverandørs gjenfinningsabstraksjon.

  Aksjonsbar konklusjon

  Bygg multi-tenant RAG som et gateway-undersystem med eksplisitte grenser. Løs leietakers identitet før henting. Bruk navneområder, shards eller vektorbutikker med leietakeromfang. Hold henting bak adaptere. Normaliser sitater til et gateway-eid skjema. Legg til livssyklustilstander og slettingsverifisering. Spor innbyggings-, henting- og generasjonskostnader separat.

  Denne arkitekturen holder RAG jordet uten å låse produktet til én hentingsleverandør. Det gir også teamene de operasjonelle kontrollene de trenger når en AI-assistent går fra en prototype til et kundevendt system: isolasjon, siteringer, portabilitet, livssyklusadministrasjon og kostnadsattribusjon.

  Relatert lesing

  • sporingsinnhenting, tokenbruk og leietakeranalyse i én observasjonsmodell
  • normaliser leverandørspesifikke utdata bak en stabil gatewaykontrakt
  • koble leietakerklargjøring og bruksmåling til Partner API-arbeidsflyter