Multi-Tenant RAG iza OpenAI-kompatibilnog API Gatewaya

Asistenti s umjetnom inteligencijom okrenuti korisniku trebaju generiranje prošireno dohvaćanjem, ali RAG postaje teži kada zahtjevi teku kroz OpenAI-kompatibilan API pristupnik umjesto izvornog skupa jednog dobavljača modela. Gateway mora držati podatke o stanarima izoliranima, čuvati citate među pružateljima modela, brisati indeksirani sadržaj prema rasporedu i pripisivati ​​troškove ugradnje, dohvaćanja i generiranja pravom kupcu.

Praktični odgovor je tretirati dohvaćanje kao prvorazredni podsustav pristupnika. Nemojte ga skrivati ​​unutar integracije jednog pružatelja usluga. Držite dohvaćanje odvojenim od generiranja, svakom zahtjevu dajte kontekst dohvaćanja u opsegu zakupca, normalizirajte citate prije nego što ih vratite i zabilježite svaki naplativi korak u glavnu knjigu.

Problem s čitačem

Tim koji gradi pomoćnika umjetne inteligencije za mnoge korisnike obično počinje jednostavnim tokom: učitajte dokumente, ugradite dijelove, dohvatite najbolje podudaranja, stavite te isječke u upitati i zamoliti modela da odgovori. To funkcionira sve dok proizvod ne treba više pružatelja modela, naplatu na razini korisnika, offboarding i mogućnost revizije.

Rizik nisu samo netočni odgovori. Veći operativni rizici su pogreške u prostoru imena stanara, citati koji se ne mogu provjeriti, zastarjeli indeksi nakon brisanja dokumenta i margine koje se ne mogu objasniti jer troškovi dohvaćanja nestaju u potrošnji generičke infrastrukture.

Ovaj članak razdvaja činjenice, preporuke i predviđanja. Činjenice su mogućnosti implementacije dokumentirane od strane trenutnog pružatelja i API-ja vektorske baze podataka. Preporuke su izbori arhitekture za pristupni proizvod. Predviđanja su gdje će ovoj arhitekturi vjerojatno trebati fleksibilnost jer se značajke dohvaćanja pružatelja neprestano mijenjaju.

Referentna arhitektura

RAG dizajn na razini pristupnika trebao bi imati pet komponenti:

• Razlučivač stanara: preslikava dolazni API ključ, radni prostor, korisnički račun ili Partner API klijent kanonskom tenant_id.
• Profil dohvaćanja: definira koji korpus pretraživati, koji model ugradnje koristiti, broj rezultata, filtre, opcije ponovnog rangiranja, zahtjeve za citiranje i ponašanje zamjene.
• Sloj prilagodnika dohvaćanja: poziva dohvat izvornog davatelja, vanjsku vektorsku bazu podataka ili uslugu prilagođenog pretraživanja putem jednog internog sučelja.
• Promptno sklapanje i adapter za generiranje: prosljeđuje dohvaćeni kontekst odabranom davatelju modela bez izlaganja pojedinosti pozadine vektora pozivateljima.
• Knjiga korištenja i revizije: ugrađivanje zapisa, indeksiranje, dohvaćanje, promptni tokeni, tokeni dovršetka, zakupac, model, pružatelj i identifikatori praćenja.

Ugovor o minimalnom zahtjevu može ostati neutralan prema pružatelju:

{
  "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?"}
  ]
}

Odgovor također treba biti neutralan prema pružatelju:

{
  "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}
}

Činjenica: Dohvaćanje pružatelja Značajke nisu identične

OpenAI's Vector Stores API podržava vektorska spremišta koja se mogu stvarati, pretraživati, konfigurirati pomoću strategija dijeljenja, povezivati s metapodacima datoteke i brisati. Pretraživanje vektorske trgovine podržava upite, filtre, maksimalan broj rezultata, opcije rangiranja, pragove rezultata i kontrole prepisivanja upita. Te kontrole daju autorima pristupnika korisne gumbe za kašnjenje, relevantnost i cijenu.

OpenAI kontrole podataka platforme također čine dizajn životnog ciklusa važnim: korisnički sadržaj u vektorskim pohranama zadržava se dok se ne izbriše.Ako zakupac ode ili ako privremeni projekt istekne, pristupnik ne može pretpostaviti da će pružatelj automatski ukloniti indeksirani sadržaj prema poslovnom rasporedu proizvoda.

Anthropic izlaže drugačiji obrazac za citate. Aplikacije mogu pružiti blokove sadržaja rezultata pretraživanja s metapodacima izvora i naslova, a kada su citati omogućeni, model može priložiti reference citata generiranom tekstu. Postoje praktična ograničenja: postavke citata rezultata pretraživanja su sve ili ništa unutar zahtjeva, blokovi rezultata pretraživanja podržavaju tekstualni sadržaj, a granularnost citata ovisi o tome kako je sadržaj podijeljen u blokove.

Implikacija je izravna: pristupnik ne bi trebao izlagati oblik dohvaćanja jednog pružatelja kao svoj javni ugovor osim ako ne namjerava tog pružatelja učiniti stalnim dohvaćanjem autoritet.

Preporuka: Koristite adaptere za dohvaćanje, a ne zaključavanje za dohvaćanje

Stvorite interno sučelje adaptera za dohvaćanje. Gateway može podržavati nekoliko pozadina iza sebe:

• Dohvaćanje izvornog pružatelja usluga: korisno kada kupac želi najbrži put do pretraživanja datoteka jednog pružatelja usluga ili značajke pohrane vektora.
• Vanjska vektorska baza podataka: korisno kada proizvod mora podržavati mnoge pružatelje modela s dosljednom izolacijom stanara i životnim ciklusom kontrole.
• Unaprijed dohvaćeni blokovi rezultata pretraživanja: korisno kada pristupnik sastavlja dohvaćeni tekst i prosljeđuje ga pružatelju koji podržava eksplicitni kontekst svjestan citata.

Adapter bi trebao vratiti istu internu strukturu bez obzira na pozadinu:

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;
  };
}

Ovo omogućuje sloju generiranja primanje kontekstu bez znanja je li došao iz OpenAI vektorskih pohrana, Pinecone, Weaviate, indeksa pretraživanja cijelog teksta baze podataka ili internog hibridnog retrivera.

Izolacija stanara počinje prije vektorskog upita

Izolacija stanara ne smije ovisiti o brzim uputama. Mora se primijeniti prije dohvaćanja, na granici pohrane i granici upita.

Za sustave u stilu Pinecone, dokumentirani obrazac za više zakupaca je jedan prostor imena po zakupcu u indeksima bez poslužitelja. Operacije podatkovne ravnine ciljaju prostor imena, što pojednostavljuje izolaciju zakupca i isključivanje jer se brisanjem prostora imena uklanjaju zapisi tog zakupca. Pinecone također dokumentira kompromise između prostora imena i filtriranja metapodataka: filtriranje unutar velikog dijeljenog prostora imena može skenirati više podataka, koštati više i izvoditi sporije od upita s opsegom prostora imena.

Za sustave u stilu Weaviate, multi-tenant pohranjuje svakog zakupca na zasebnom shardu, tako da podaci jednog zakupca nisu vidljivi drugom zakupcu. Brisanje zakupca briše pridruženi shard.Weaviate također podržava stanja stanara kao što su aktivno, neaktivno i isključeno, što stvara opciju životnog ciklusa za rijetko korištene stanare.

Kontrolni popis implementacije

• Razriješi tenant_id iz autentificiranog identiteta pristupnika, a ne samo iz polja tijela koje daje korisnik.
• Map tenant_id na vektor namespace, shard ili identifikator pohrane vektora pružatelja putem registra na strani poslužitelja.
• Odbijte zahtjeve gdje se API ključni zakupac i traženi zakupac korpusa ne podudaraju.
• Držite zajedničke javne korpuse odvojene od privatnih zakupnih korpusa.
• Koristite filtriranje metapodataka za vrstu dokumenta, jezik, područje proizvoda ili datumski raspon nakon zakupca granica je već odabrana.
• Prostor imena dnevnika, shard, corpus_id, retrieval_profile i retrieval_trace_id za reviziju.

Rezervirajte pretraživanje među zakupcima za eksplicitne administrativne tijekove rada s odvojenim ovlaštenjima, odvojenim indeksima ili kontroliranim stazama združivanja. Neka pretraživanje među zakupcima ne bude slučajna nuspojava filtara metapodataka.

Normalizirajte citate kao pristupne objekte

Citati su ugovor o proizvodu, a ne samo ukras. Asistent za korisničku podršku, alat za izradu nacrta zakona ili interni asistent za znanje treba pokazati zašto je odgovor proizveden i odakle je došao popratni tekst.

Gateway bi trebao normalizirati podatke o citatima u vlastitu shemu:

{
  "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": {}
}

Održavajte normalizirana polja stabilnima i dopustite proširenja specifična za pružatelja usluga. Neki pružatelji će izložiti bogatije pojedinosti citata od drugih. Neki će citirati blokove rezultata pretraživanja. Neki će citirati učitane datoteke. Neki neće pružiti točan format pomaka koji vaša aplikacija želi. Gateway bi trebao sačuvati ono što postoji bez pretvaranja da svaki pružatelj ima identičnu semantiku citiranja.

Način strogog citiranja

Kada je citation_required točno, unaprijed definirajte ponašanje neuspjeha. Strogi način može zahtijevati da svaki činjenični odlomak uključuje barem jedan citat ili da konačni odgovor sadrži citate iz dohvaćenih dijelova iznad minimalnog praga rezultata. Ako odabrani pružatelj modela ne može zadovoljiti ugovor o citiranju, pristupnik bi trebao brzo otkazati, koristiti kompatibilnog pružatelja ili vratiti strukturirano odbijanje.

Ovo je preporuka, a ne univerzalno pravilo. Način strogog citiranja poboljšava povjerenje, ali može povećati složenost odbijanja, ponovnih pokušaja i povratne složenosti. Za kreativne tijekove rada s niskim rizikom citati mogu biti izborni. Za korisničku podršku ili regulirane interne tijekove rada, citation_required bi često trebao biti dio profila za dohvaćanje.

Životni ciklus indeksa je značajka proizvoda

RAG sustavi prikupljaju podatke. Privremeni prijenosi slučajno postaju trajni. Bivši kupci ostavljaju iza sebe ugrađene stvari. Timovi proizvoda mijenjaju strategije dijeljenja i zaboravljaju ponovno izgraditi stare indekse.Gateway bi trebao učiniti eksplicitnim kontrole životnog ciklusa.

Preporučene kontrole životnog ciklusa uključuju:

• Privremeni istek korpusa: dokumenti učitani za kratkotrajnu sesiju trebaju imati vremensku oznaku isteka i posao brisanja.
• Izbacivanje stanara: brisanje zakupac bi trebao staviti u red brisanja prostora imena, fragmenata, pohranjivanja vektora pružatelja usluga i srodnih objekata datoteka.
• Hladno rukovanje zakupcima: gdje je podržano, neaktivni zakupci mogu se označiti kao neaktivni ili skinuti kako bi se smanjila upotreba resursa.
• Reindeksiranje kontrole verzije: model ugradnje pohrane, politika chunkinga, verzija parsera i indexed_at za svaki chunk.
• Izloženost statusu brisanja: Partner API tijek rada trebao bi pokazati jesu li brisanje dokumenta, brisanje vektora i brisanje na strani pružatelja dovršeni.

Važna je činjenica da se neki sadržaj vektorske pohrane zadržava do brisanja. Preporuka arhitekture je da se brisanje učini vidljivim i da se može testirati umjesto da se zakopa u asinkroni posao bez stanja usmjerenog prema korisniku.

Praćenje tri knjige troškova

Jedna knjiga tokena nije dovoljna za RAG. Gateway treba najmanje tri knjige:

• Cijena ugrađivanja i indeksiranja: raščlanjivanje dokumenata, grupiranje, pozivi za ugrađivanje, pohranjivanje datoteka, pisanje indeksa i ponovno indeksiranje.
• Cijena dohvaćanja: čitanja vektorske baze podataka, pretraživanje izvorne vektorske pohrane, ponovno rangiranje, prepisivanje upita i proširenje rezultata.
• Cijena generiranja: ulazni tokeni iz korisničkih poruka i dohvaćenog konteksta, izlazni tokeni, pozivi alata, ponovni pokušaji i povratna rješenja.

Ovo je posebno važno za agencije, SaaS dobavljače i interne platformske timove koji preprodaju ili dodjeljuju AI troškovi. Bez zasebnih knjiga postaje teško objasniti RAG marže. Zakupac s malim korištenjem generacije i dalje može biti skup ako neprestano učitava dokumente, ponovno indeksira velike korpuse ili pokreće široke upite za dohvaćanje.

Svaki događaj u glavnoj knjizi trebao bi uključivati ​​tenant_id, customer_id ako je drugačiji, API ID ključa, retrieval_profile, corpus_id, model, davatelj, trace_id i naplative jedinice.To omogućuje analitici korištenja da odgovori na praktična pitanja: koji zakupci imaju skupe profile za dohvaćanje, koji su korpusi zastarjeli, koji modeli proizvode neuspjele citiranja, a koji klijenti generiraju prevelike upite jer dohvaćanje vraća previše konteksta.

Načini neuspjeha za testiranje

RAG podsustav pristupnika trebao bi imati testove za načine neuspjeha koji stvaraju vidljivost korisnicima šteta:

• Nedostajući citati: citation_required je istina, ali odgovor pružatelja ne sadrži upotrebljive reference citata.
• Zastarjeli indeksi: dokument je ažuriran ili izbrisan, ali stari dijelovi i dalje se pojavljuju u rezultatima dohvaćanja.
• Zakupac mismatch: zahtjev se rješava zakupcu A, dok korpus ili prostor imena pripada zakupcu B.
• Preširoko dohvaćanje: profil vraća previše dijelova, povećavajući cijenu i slabeći kvalitetu odgovora.
• Neusklađenost veličine dijela: dijelovi su tako veliki da su citati neprecizni ili toliko mali da kontekst gubi značenje.
• Neusklađenost značajki pružatelja: jedan model može emitirati citate u potrebnom obliku, dok drugi ne može.
• Kvar životnog ciklusa: zahtijeva se brisanje, ali pohrana na strani pružatelja ostaje aktivna ili neprovjereno.

Ovi testovi trebaju se izvoditi na razini ugovora pristupnika, a ne samo unutar adaptera jednog davatelja usluga. Cilj je dokazati da javno ponašanje ostaje stabilno kada se promijeni pozadina za dohvaćanje ili pružatelj generiranja.

Ustupci

Dohvaćanje izvornog pružatelja može smanjiti kod aplikacije i ubrzati prvu verziju. Kompromis je u tome što životni ciklus pohrane, format navoda, kontrole upita i dostupnost značajki mogu postati vezani za jednog pružatelja.

Vanjske vektorske baze podataka dodaju operativnu površinu. Prednost je bolja prenosivost preko OpenAI-kompatibilnih modela, Anthropic modela i budućih pružatelja usluga. Oni također olakšavaju zaključivanje prostora naziva ili fragmenata s opsegom zakupca o tome kada je pristupnik odgovoran za naplatu i otpremu.

Fino zrnati dijelovi poboljšavaju preciznost citata i mogućnost revizije. Oni također povećavaju veličinu indeksa, opseg dohvaćanja i složenost brzog sklapanja. Grubi dijelovi su jednostavniji, ali mogu proizvesti citate koji upućuju na široku stranicu ili odjeljak, a ne na točan prateći odlomak.

Način striktno zahtijevanog citata poboljšava povjerenje korisnika. Također prisiljava pristupnik da rukuje modelima koji ne mogu proizvesti traženi format navoda, što može značiti odbijanje zahtjeva, promjenu modela ili vraćanje odgovora s nižim stanjem pouzdanosti.

Predviđanje: dohvaćanje će postati izvornije, ali pristupnici i dalje trebaju vlastiti ugovor

Značajke dohvaćanja izvorne za pružatelja usluga vjerojatno će postati više sposoban. Više modela prihvatit će dohvaćeni kontekst sa strukturiranim izvornim metapodacima. Više API-ja izložit će kontrole rangiranja, prepisivanje upita i postavke citiranja. To ne uklanja potrebu za ugovorom o pristupniku.

Pristupnik i dalje posjeduje identitet stanara, upravljanje ključevima, ograničenja potrošnje, analitiku upotrebe, tijekove rada partnera API i obećanja o brisanju upućena klijentu. Značajke davatelja mogu se koristiti iza sloja adaptera, ali proizvod ne bi trebao prisiljavati svakog zakupca, model i radni tijek naplate u apstrakciju dohvaćanja jednog davatelja.

Zaključak koji se može učiniti

Izradite RAG za više zakupaca kao podsustav pristupnika s eksplicitnim granicama.Razriješite identitet stanara prije preuzimanja. Upotrijebite imenske prostore s opsegom stanara, fragmente ili vektorske pohrane. Držite preuzimanje iza adaptera. Normalizirajte citate u shemu u vlasništvu pristupnika. Dodajte stanja životnog ciklusa i potvrdu brisanja. Odvojeno pratite troškove ugradnje, dohvaćanja i generiranja.

Ova arhitektura drži RAG uzemljenim bez zaključavanja proizvoda na jednog pružatelja dohvaćanja. Također daje timovima operativne kontrole koje su im potrebne kada AI pomoćnik prijeđe s prototipa na sustav okrenut klijentu: izolacija, citiranje, prenosivost, upravljanje životnim ciklusom i dodjeljivanje troškova.

Povezano čitanje

• dohvaćanje tragova, korištenje tokena i analitika stanara u jednoj mogućnosti promatranja model
• normalizirati izlaze specifične za pružatelja usluga iza stabilnog ugovora pristupnika
• poveži pružanje usluga i mjerenje upotrebe zakupca s Partner API tijekovima rada