Multi-Tenant RAG za prehodom API, združljivim z OpenAI

Pomočniki umetne inteligence, obrnjeni k strankam, potrebujejo generiranje, razširjeno s pridobivanjem, vendar RAG postane težje, ko zahteve tečejo prek OpenAI-združljivega API prehoda namesto izvornega sklada enega ponudnika modela. Prehod mora ohranjati izolirane podatke o najemnikih, ohranjati navedbe med ponudniki modelov, brisati indeksirano vsebino po urniku in stroške vdelave, pridobivanja in generiranja pripisovati pravi stranki.

Praktični odgovor je, da iskanje obravnavamo kot prvovrsten podsistem prehoda. Ne skrivajte ga znotraj integracije enega ponudnika. Pridobivanje naj bo ločeno od generiranja, dajte vsaki zahtevi kontekst pridobivanja v obsegu najemnika, normalizirajte navedbe, preden jih vrnete, in zabeležite vsak plačljivi korak v knjigi.

Problem Reader

Ekipa, ki sestavlja pomočnika AI za mnoge stranke, se običajno začne s preprostim potekom: naložite dokumente, vdelajte kose, pridobite najboljša ujemanja, vstavite te delčke v vprašajte in prosite modela, da odgovori. To deluje, dokler izdelek ne potrebuje več ponudnikov modelov, zaračunavanje na ravni stranke, izključitev in revizijo.

Tveganje niso samo netočni odgovori. Večja operativna tveganja so napake imenskega prostora najemnika, nepreverljivi citati, zastareli indeksi po izbrisu dokumenta in robovi, ki jih ni mogoče razložiti, ker stroški pridobivanja izginejo v porabo splošne infrastrukture.

Ta članek ločuje dejstva, priporočila in napovedi. Dejstva so izvedbene zmogljivosti, dokumentirane s trenutnim ponudnikom in API-ji vektorske baze podatkov. Priporočila so izbire arhitekture za izdelek prehoda. Napovedi kažejo, da bo ta arhitektura verjetno potrebovala prilagodljivost, saj se funkcije ponudnika za iskanje nenehno spreminjajo.

Referenčna arhitektura

Zasnova RAG na ravni prehoda bi morala imeti pet komponent:

• Rezločevalec najemnikov: preslika dohodni ključ API, delovni prostor, račun stranke ali stranko partnerja API kanoničnemu tenant_id.
• Profil za iskanje: določa, v katerem korpusu je treba iskati, kateri model vdelave uporabiti, število rezultatov, filtre, možnosti prerazvrščanja, zahteve za citiranje in nadomestno vedenje.
• Prilagoditvena plast: pokliče izvorno pridobivanje ponudnika, zunanjo vektorsko zbirko podatkov ali storitev iskanja po meri prek enega notranjega vmesnika.
• Adapter za hitro sestavljanje in generiranje: posreduje pridobljeni kontekst izbranemu ponudniku modela, ne da bi klicateljem razkril podrobnosti vektorskega ozadja.
• Uporaba in revizijska knjiga: vdelava zapisov, indeksiranje, iskanje, žetoni za pozive, žetoni za dokončanje, identifikatorji najemnika, modela, ponudnika in sledenja.

Pogodba z minimalno zahtevo lahko ostane nevtralna glede ponudnika:

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

Odziv mora biti tudi nevtralen glede ponudnika:

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

Dejstvo: Pridobivanje ponudnika Funkcije niso enake

OpenAI's Vector Stores API podpira vektorske shrambe, ki jih je mogoče ustvariti, iskati, konfigurirati s strategijami razčlenjevanja, povezati z metapodatki datoteke in izbrisati. Iskanje v vektorski trgovini podpira poizvedbe, filtre, največje število rezultatov, možnosti razvrščanja, pragove rezultatov in kontrole za prepisovanje poizvedb. Te kontrole dajejo avtorjem prehodov uporabne gumbe za zakasnitev, ustreznost in stroške.

OpenAI Kontrole podatkov platforme prav tako naredijo pomembno zasnovo življenjskega cikla: vsebina strank v vektorskih trgovinah se ohrani, dokler ni izbrisana.Če se najemnik umakne ali če začasni projekt poteče, prehod ne more domnevati, da bo ponudnik samodejno odstranil indeksirano vsebino glede na poslovni urnik izdelka.

Anthropic razkrije drugačen vzorec za navedbe. Aplikacije lahko zagotovijo bloke vsebine rezultatov iskanja z metapodatki o izvoru in naslovu, in ko so citati omogočeni, lahko model pripne reference citatov ustvarjenemu besedilu. Obstajajo praktične omejitve: nastavitve citiranja rezultatov iskanja so znotraj zahteve vse ali nič, bloki rezultatov iskanja podpirajo besedilno vsebino, razdrobljenost citiranja pa je odvisna od tega, kako je vsebina razdeljena na bloke.

Posledica je neposredna: prehod ne bi smel izpostaviti oblike iskanja enega ponudnika kot svojo javno pogodbo, razen če namerava temu ponudniku omogočiti trajno iskanje. organ.

Priporočilo: Uporabite adapterje za pridobivanje, ne zaklepanja za pridobivanje

Ustvarite notranji vmesnik vmesnika za pridobivanje. Prehod lahko podpira več ozadij za sabo:

• Pridobivanje izvornega ponudnika: uporabno, ko stranka želi najhitrejšo pot do iskanja datotek enega ponudnika ali funkcij vektorske shrambe.
• Zunanja vektorska zbirka podatkov: uporabno, ko mora izdelek podpirati številne ponudnike modelov z dosledno izolacijo najemnika in življenjskim ciklom kontrolniki.
• Vnaprej pridobljeni bloki rezultatov iskanja: uporabno, ko prehod sestavi pridobljeno besedilo in ga posreduje ponudniku, ki podpira eksplicitni kontekst, ki upošteva navedbe.

Vmesnik mora vrniti isto notranjo strukturo ne glede na zaledje:

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

To omogoča sloju za ustvarjanje prejemanje kontekstu, ne da bi vedeli, ali prihaja iz OpenAI vektorskih shramb, Pinecone, Weaviate, indeksa iskanja po celotnem besedilu baze podatkov ali notranjega hibridnega prinašalca.

Izolacija najemnika se začne pred vektorsko poizvedbo

Izolacija najemnika ne sme biti odvisna od hitrih navodil. Uveljaviti ga je treba pred pridobitvijo na meji pomnilnika in meji poizvedbe.

Za sisteme v slogu Pinecone je dokumentiran vzorec večnajemništva en imenski prostor na najemnika v indeksih brez strežnika. Operacije podatkovne ravnine ciljajo na imenski prostor, kar poenostavi izolacijo najemnika in izključitev, ker izbris imenskega prostora odstrani zapise tega najemnika. Pinecone dokumentira tudi kompromise med imenskimi prostori in filtriranjem metapodatkov: filtriranje znotraj velikega imenskega prostora v skupni rabi lahko skenira več podatkov, je dražje in izvaja počasneje kot poizvedbe v obsegu imenskega prostora.

Za sisteme v slogu Weaviate večnajemniški sistem shrani vsakega najemnika na ločeni delček, tako da podatki enega najemnika niso vidni drugemu najemniku. Izbris najemnika izbriše povezani delček.Weaviate podpira tudi stanja najemnikov, kot so aktivno, neaktivno in razbremenjeno, kar ustvari možnost življenjskega cikla za redko uporabljene najemnike.

Kontrolni seznam za implementacijo

• Razreši tenant_id iz overjene identitete prehoda, ne samo iz polja telesa, ki ga poda uporabnik.
• Preslikaj tenant_id v vektor imenskega prostora, drobca ali identifikatorja vektorske shrambe ponudnika prek registra na strani strežnika.
• Zavrnite zahteve, kjer se API ključni najemnik in zahtevani najemnik korpusa ne ujemata.
• Ohranite javne korpuse v skupni rabi ločene od zasebnih korpusov najemnikov.
• Uporabite filtriranje metapodatkov za vrsto dokumenta, jezik, področje izdelka ali datumsko obdobje po najemniku meja je že izbrana.
• Imenski prostor dnevnika, delček, corpus_id, retrieval_profile in retrieval_trace_id za revizijo.

Rezerviraj iskanje med najemniki za eksplicitne skrbniške poteke dela z ločeno avtorizacijo, ločenimi indeksi ali nadzorovanimi potmi združevanja. Naj iskanje med najemniki ne postane naključni stranski učinek filtrov metapodatkov.

Normalizirajte navedbe kot prehodne objekte

Navedbe so pogodba o izdelku, ne le okras. Pomočnik za podporo strankam, orodje za pripravo pravnih osnutkov ali interni asistent za znanje mora pokazati, zakaj je bil ustvarjen odgovor in od kod prihaja podporno besedilo.

Prehod mora normalizirati podatke o navedbah v lastno shemo:

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

Ohranjajte normalizirana polja stabilna in dovolite razširitve, specifične za ponudnika. Nekateri ponudniki bodo izpostavili bogatejše podatke o citatih kot drugi. Nekateri bodo navajali bloke rezultatov iskanja. Nekateri bodo citirali naložene datoteke. Nekateri ne bodo zagotovili natančnega formata zamika, ki ga želi vaša aplikacija. Prehod bi moral ohraniti, kar obstaja, ne da bi se pretvarjal, da ima vsak ponudnik enako semantiko citiranja.

Način strogega citiranja

Ko je citation_required resničen, vnaprej definirajte obnašanje napake. Strogi način lahko zahteva, da vsak dejanski odstavek vključuje vsaj eno navedbo ali da končni odgovor vsebuje navedbe iz pridobljenih kosov nad minimalnim pragom točk. Če izbrani ponudnik modela ne more izpolniti pogodbe o citiranju, bi moral prehod hitro odpovedati, uporabiti združljivega ponudnika ali vrniti strukturirano zavrnitev.

To je priporočilo, ne univerzalno pravilo. Način strogega citiranja izboljša zaupanje, vendar lahko poveča zapletenost zavrnitev, ponovnih poskusov in nadomestne možnosti. Za ustvarjalne poteke dela z nizkim tveganjem so navedbe morda neobvezne. Za podporo, obrnjeno k strankam, ali regulirane notranje poteke dela bi moral biti citation_required pogosto del profila za pridobivanje.

Življenjski cikel indeksa je značilnost izdelka

Sistemi RAG kopičijo podatke. Začasna nalaganja po nesreči postanejo trajna. Nekdanje stranke za seboj puščajo vdelane izdelke. Skupine izdelkov spremenijo strategije razčlenjevanja in pozabijo obnoviti stare indekse.Prehod mora imeti eksplicitne kontrole življenjskega cikla.

Priporočeni kontrolniki življenjskega cikla vključujejo:

• Začasni potek korpusa: dokumenti, naloženi za kratkotrajno sejo, morajo imeti časovni žig poteka in opravilo izbrisa.
• Izključitev najemnika: brisanje najemnik bi moral postaviti v čakalno vrsto izbris imenskih prostorov, drobcev, vektorskih shramb ponudnika in sorodnih datotečnih objektov.
• Hladno ravnanje z najemniki: kjer je podprto, se neaktivni najemniki lahko označijo kot neaktivni ali razbremenijo, da se zmanjša uporaba virov.
• Ponovno indeksiranje nadzora različice: model vdelave shrambe, pravilnik o razčlenjevanju, različica razčlenjevalnika in indexed_at za vsak kos.
• Izpostavljenost statusa izbrisa: Delovni tokovi partnerja API bi morali pokazati, ali je brisanje dokumenta, brisanje vektorja in brisanje na strani ponudnika končano.

Pomembno dejstvo je, da se nekaj vsebine vektorske shrambe ohrani do izbrisa. Priporočilo za arhitekturo je, da je izbris viden in ga je mogoče preizkusiti, namesto da bi ga zakopali v asinhrono opravilo brez stanja, ki je usmerjeno k strankam.

Sledenje trem knjigam stroškov

Ena sama knjiga žetonov ni dovolj za RAG. Prehod potrebuje vsaj tri glavne knjige:

• Stroški vdelave in indeksiranja: razčlenjevanje dokumentov, razdeljevanje na kose, klici vdelave, shranjevanje datotek, pisanje indeksov in ponovno indeksiranje.
• Stroški pridobivanja: branje vektorske baze podatkov, iskanje izvorne vektorske shrambe, prerazvrščanje, prepisovanje poizvedb in razširitev rezultatov.
• Stroški generiranja: vhodni žetoni iz uporabniških sporočil in pridobljenega konteksta, izhodni žetoni, klici orodij, ponovni poskusi in nadomestni rezultati.

To je še posebej pomembno za agencije, prodajalce SaaS in interne skupine platform, ki preprodajajo ali dodeljujejo AI stroški. Brez ločenih knjig je marže RAG težko razložiti. Najemnik z majhno uporabo generacije je lahko še vedno drag, če nenehno nalaga dokumente, ponovno indeksira velike korpuse ali izvaja široke poizvedbe za iskanje.

Vsak dogodek v knjigi mora vključevati tenant_id, customer_id, če je drugačen, API ID ključa, retrieval_profile, corpus_id, model, ponudnik, trace_id in zaračunljive enote.To omogoča analitiki uporabe odgovorov na praktična vprašanja: kateri najemniki imajo drage profile pridobivanja, kateri korpusi so zastareli, kateri modeli povzročajo napake pri navajanju in katere stranke ustvarjajo prevelike pozive, ker pridobivanje vrne preveč konteksta.

Načini napak za testiranje

Podsistem prehoda RAG bi moral imeti teste za načine napak, ki ustvarjajo vidno stranki škoda:

• Manjkajoči citati: citation_required je resničen, vendar odgovor ponudnika ne vsebuje uporabnih referenc citatov.
• Zastareli indeksi: dokument je bil posodobljen ali izbrisan, vendar se v rezultatih iskanja še vedno pojavljajo stari kosi.
• Najemnik mismatch: zahteva se razreši na najemniku A, medtem ko korpus ali imenski prostor pripada najemniku B.
• Preširoko pridobivanje: profil vrne preveč kosov, kar poveča stroške in zmanjša kakovost odgovora.
• Neujemanje velikosti kosov: kosi so tako veliki da so citati nenatančni ali tako majhni, da kontekst izgubi pomen.
• Neusklajenost lastnosti ponudnika: en model lahko oddaja citate v zahtevani obliki, drugi pa ne.
• Napaka življenjskega cikla: zahteva se izbris, vendar shramba na strani ponudnika ostaja aktivna oz. nepreverjeno.

Ti testi bi se morali izvajati na ravni pogodbe o prehodu, ne samo znotraj adapterja enega ponudnika. Cilj je dokazati, da javno vedenje ostane stabilno, ko se spremeni zaledje za iskanje ali ponudnik generiranja.

Kompromisi

Pridobivanje izvornega ponudnika lahko zmanjša kodo aplikacije in pospeši prvo različico. Kompromis je v tem, da življenjski cikel shranjevanja, oblika navedbe, nadzor poizvedb in razpoložljivost funkcij lahko postanejo vezani na enega ponudnika.

Zunanje vektorske baze podatkov dodajajo operativno površino. Prednost je močnejša prenosljivost med OpenAI-kompatibilnimi modeli, Anthropic modeli in prihodnjimi ponudniki. Omogočajo tudi, da je imenske prostore ali drobce v obsegu najemnika lažje sklepati o tem, kdaj je prehod odgovoren za zaračunavanje in izključitev.

Drobno zrnati kosi izboljšajo natančnost navajanja in revizijo. Povečajo tudi velikost indeksa, obseg iskanja in zapletenost hitrega sestavljanja. Grobi kosi so preprostejši, vendar lahko proizvedejo navedbe, ki kažejo na široko stran ali razdelek in ne na natančen podporni odlomek.

Način stroge zahteve po navedbah izboljša zaupanje uporabnikov. Prehod tudi prisili, da obravnava modele, ki ne morejo ustvariti zahtevane oblike navedbe, kar lahko pomeni zavrnitev zahteve, spreminjanje modelov ali vrnitev odgovora z nižjim stanjem zaupanja.

Napoved: Pridobivanje bo postalo bolj izvorno, vendar prehodi še vedno potrebujejo lastno pogodbo

Funkcije pridobivanja, ki so izvorne ponudnikom, bodo verjetno postale bolj sposobni. Več modelov bo sprejelo pridobljeni kontekst s strukturiranimi izvornimi metapodatki. Več API-jev bo razkrilo nadzor razvrščanja, prepisovanje poizvedb in nastavitve citiranja. To ne odpravi potrebe po pogodbi o prehodu.

Prehod ima še vedno v lasti identiteto najemnika, upravljanje ključev, omejitve porabe, analitiko uporabe, poteke dela partnerja API in obljube o izbrisu, usmerjene k strankam. Funkcije ponudnika je mogoče uporabiti za plastjo adapterja, vendar izdelek ne bi smel prisiliti vsakega najemnika, modela in delovnega toka zaračunavanja v abstrakcijo priklica enega ponudnika.

Uporabni sklep

Zgradite RAG za več najemnikov kot podsistem prehoda z izrecnimi mejami.Razrešite identiteto najemnika pred pridobitvijo. Uporabite imenske prostore, drobce ali vektorske shrambe v obsegu najemnika. Naj bo iskanje za adapterji. Normalizirajte navedbe v shemo v lasti prehoda. Dodajte stanja življenjskega cikla in preverjanje izbrisa. Ločeno sledite stroškom vdelave, pridobivanja in generiranja.

Ta arhitektura ohranja RAG prizemljen, ne da bi izdelek zaklenil na enega ponudnika pridobivanja. Ekipam daje tudi operativne kontrole, ki jih potrebujejo, ko se pomočnik umetne inteligence premakne s prototipa na sistem, usmerjen v stranko: izolacijo, navedbe, prenosljivost, upravljanje življenjskega cikla in dodeljevanje stroškov.

Sorodno branje

• pridobivanje sledi, uporaba žetonov in analitika najemnikov v eni opazovalnici model
• normalizirajte izhode, specifične za ponudnika, za stabilno pogodbo o prehodu
• povežite oskrbo najemnika in merjenje uporabe s partnerskimi API poteki dela