Multi-Tenant RAG iza OpenAI-kompatibilnog API Gatewaya

Asistenti s umjetnom inteligencijom koji su okrenuti prema korisniku trebaju generiranje prošireno dohvaćanjem, ali RAG postaje teži kada zahtjevi teku kroz API pristupnik kompatibilan s OpenAI-jem 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 čitača

Tim koji gradi pomoćnika umjetne inteligencije za mnoge klijente obično počinje jednostavnim tokom: učitajte dokumente, ugradite dijelove, dohvatite najbolje rezultate, stavite te isječke u upit i zatražite model odgovoriti. 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 proizvod pristupnika. Predviđanja su tamo gdje će ovoj arhitekturi vjerojatno trebati fleksibilnost jer se značajke dohvaćanja pružatelja stalno mijenjaju.

Referentna arhitektura

RAG dizajn na razini pristupnika trebao bi imati pet komponenti:

• Razlučivač stanara: mapira dolazni API ključ, radni prostor, korisnički račun ili partnera API klijenta kanonskom tenant_id.
• Profil dohvata: definira koji korpus pretraživati, koji model ugradnje koristiti, broj rezultata, filtre, opcije ponovnog rangiranja, zahtjeve za citiranje i zamjensko ponašanje.
• Sloj prilagodnika dohvaćanja: poziva izvorno dohvaćanje pružatelja usluga, vanjsku vektorsku bazu podataka ili uslugu prilagođenog pretraživanja putem jednog internog sučelja.
• Brzo sklapanje i generiranje adapter: prosljeđuje dohvaćeni kontekst odabranom pružatelju modela bez izlaganja pojedinosti pozadine vektora pozivateljima.
• Glavna knjiga korištenja i revizije: bilježi ugrađivanje, indeksiranje, dohvaćanje, tokene upita, tokene dovršetka, zakupca, modela, pružatelja i identifikatore praćenja.

Ugovor o minimalnom zahtjevu može ostati davatelj neutralan:

{
  "stanar_id": "stanar_123",
  "model": "gpt-kompatibilan-ili-claude-kompatibilan-model",
  "retrieval_profile": "support_docs_v2",
  "citation_required": točno,
  "poruke": [
    {"role": "user", "content": "Koja su naša pravila povrata za godišnje planove?"}
  ]
}

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

{
  "odgovor": "Godišnji planovi mogu se vratiti unutar konfiguriranog prozora pravila...",
  "citati": [
    {
      "source_id": "doc_789",
      "title": "Pravila naplate",
      "url_or_internal_ref": "kb://pravila-naplate",
      "chunk_id": "chunk_044",
      "pomaci": {"stranica": 3},
      "ocjena": 0,82,
      "retrieval_provider": "vector_db",
      "model_provider": "openai_compatible",
      "provider_payload": {}
    }
  ],
  "retrieval_trace_id": "rt_456",
  "billable_tenant": "stanar_123",
  "embedding_usage": null,
  "retrieval_usage": {"upiti": 1, "rezultati": 6},
  "model_usage": {"input_tokens": 1920, "output_tokens": 180}}

Činjenica: Značajke dohvaćanja pružatelja usluga nisu identične

OpenAI-jev API za vektorske pohrane podržava vektorske pohrane koje 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.

Kontrole podataka platforme OpenAI također čine dizajn životnog ciklusa važnim: korisnički sadržaj u vektorskim trgovinama zadržava se dok se ne izbriše. Ako stanar ode ili ako privremeni projekt istekne, gateway 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 navoda rezultata pretraživanja su sve ili ništa unutar zahtjeva, blokovi rezultata pretraživanja podržavaju tekstualni sadržaj, a granularnost navoda 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 autoritetom za dohvaćanje.

Preporuka: Koristite Adapteri 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 značajki pretraživanja datoteka jednog pružatelja ili pohrane vektora.
• Vanjska vektorska baza podataka: korisno kada proizvod mora podržavati mnoge pružatelje modela s dosljednom izolacijom stanara i kontrolama životnog ciklusa.
• Unaprijed dohvaćeni blokovi rezultata pretraživanja: korisno kada gateway 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: niz;
  stanarId: niz;
  corpusId: niz;
  komadi: niz<{
    sourceId: niz;
    naslov: niz;
    tekst: niz;
    urlOrInternalRef?: niz;
    chunkId: niz;
    pomaci?: { stranica?: broj; byteStart?: broj; byteEnd?: broj; tokenStart?: broj; tokenEnd?: broj };
    rezultat?: broj;
    metapodaci: Zapis;
    providerPayload?: nepoznato;
  }>;
  retrievalUsage: {
    pružatelj: niz;
    queryCount: broj;
    resultCount: broj;
    obračunske jedinice?: broj;
  };}

Ovo omogućuje sloju generacije da primi kontekst bez da zna 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 zajedničkog 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-tenancy 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 zakupca kao što su aktivan, neaktivan i isključen, što stvara opciju životnog ciklusa za rijetko korištene zakupce.

Kontrolni popis za implementaciju

• Razriješite tenant_id iz autentificiranog identiteta pristupnika, a ne samo iz polja tijela koje je donio korisnik.
• Mapirajte tenant_id u prostor imena vektora, shard ili pohranu vektora pružatelja identifikator putem registra na strani poslužitelja.
• Odbijte zahtjeve gdje se zakupac API ključa i traženi zakupac korpusa ne podudaraju.
• Držite zajedničke javne korpuse odvojene od privatnih korpusa zakupaca.
• Koristite filtriranje metapodataka za vrstu dokumenta, jezik, područje proizvoda ili datumski raspon nakon što je granica zakupca 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 zasebnom autorizacijom, zasebnim indeksima ili kontroliranim stazama agregacije. 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 korisničke podrške, alat za izradu pravnih propisa ili interni asistent znanja 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": "Uvjeti povrata",
  "url_or_internal_ref": "kb://uvjeti-povrata",
  "chunk_id": "chunk_006",
  "offsets": {"page": 2, "byte_start": 4410, "byte_end": 5020},
  "ocjena": 0,79,
  "retrieval_provider": "prepletati",
  "model_provider": "antropski",
  "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 citata.

Način strogog citata

Kada je citation_required istinito, 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 često bi 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 za proizvode mijenjaju strategije usitnjavanja 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 zakupca: brisanje zakupca treba staviti u red brisanje prostora imena, krhotine, vektorske pohrane pružatelja i povezane objekte datoteka.
• Hladno rukovanje zakupcima: tamo gdje je podržano, neaktivni zakupci mogu se označiti kao neaktivni ili prenijeti kako bi se smanjila upotreba resursa.
• Reindeksiranje kontrole verzije: pohrana modela ugradnje, pravila dijeljenja, verzije parsera i indexed_at za svaki komad.
• Status brisanja izloženost: Tijekovi rada Partner API-ja trebali 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 dok se ne izbriše. 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 glavne knjige:

• Troškovi ugrađivanja i indeksiranja: raščlanjivanje dokumenata, dijeljenje na komade, pozivi ugrađivanja, pohranjivanje datoteka, pisanje indeksa i ponovno indeksiranje.
• Troškovi dohvaćanja: čitanja vektorske baze podataka, izvorno pretraživanje pohrane vektora, ponovno rangiranje, ponovno pisanje upita i rezultat proširenje.
• Troškovi generiranja: ulazni tokeni iz korisničkih poruka i dohvaćenog konteksta, izlazni tokeni, pozivi alata, ponovni pokušaji i vraćanja.

Ovo je posebno važno za agencije, dobavljače SaaS-a i interne platformske timove koji preprodaju ili raspoređuju troškove umjetne inteligencije. Bez zasebnih knjiga postaje teško objasniti RAG marže. Zakupac s malom upotrebom generacije i dalje može biti skup ako stalno učitava dokumente, ponovno indeksira velike korpuse ili pokreće široke upite za dohvaćanje.

Svaki događaj glavne knjige trebao bi uključivati ​​tenant_id, customer_id ako je drugačiji, API ključ ID, retrieval_profile, corpus_id, model, provider, 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 citate i 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 istinit, ali odgovor pružatelja ne sadrži upotrebljive reference citata.
• Zastarjeli indeksi: dokument je ažuriran ili izbrisan, ali se stari dijelovi i dalje pojavljuju u rezultatima dohvaćanja.
• Neusklađenost zakupca: zahtjev se rješava zakupcu A, dok korpus ili prostor imena pripada stanaru B.
• Preširoko dohvaćanje: profil vraća previše dijelova, povećavajući cijenu i slabeći kvalitetu odgovora.
• Neusklađenost veličine dijelova: dijelovi su toliko veliki da su citati neprecizni ili tako mali da kontekst gubi značenje.
• Neusklađenost značajki pružatelja usluga: jedan model može emitirati citate u potrebnom obliku dok drugi ne može.
• Neuspjeh životnog ciklusa: traži se brisanje, ali pohrana na strani pružatelja ostaje aktivna ili neprovjerena.

Ovi testovi trebaju se izvoditi na razini ugovora pristupnika, a ne samo unutar jednog adaptera pružatelja. 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 citata, kontrole upita i dostupnost značajki mogu postati vezani za jednog pružatelja usluga.

Vanjske vektorske baze podataka dodaju operativnu površinu. Prednost je veća 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 citiranja i reviziju. 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 obrađuje modele koji ne mogu proizvesti traženi format citata, š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 davatelja vjerojatno će postati sposobnije. 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 korištenja, tijekove rada Partner API-ja i obećanja o brisanju upućena korisniku. Značajke davatelja mogu se koristiti iza sloja adaptera, ali proizvod ne bi trebao prisiljavati svakog zakupca, model i radni tijek naplate u jednu davateljevu apstrakciju dohvaćanja.

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, citati, prenosivost, upravljanje životnim ciklusom i dodjeljivanje troškova.

Povezano čitanje

• dohvaćanje praćenja, korištenje tokena i analiza stanara u jednom modelu promatranja
• normalizirati izlaze specifične za pružatelja usluga iza stabilnog ugovora pristupnika
• povežite pružanje zakupaca i mjerenje upotrebe s tijekovima rada Partner API-ja