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 prehoda API, združljivega z OpenAI, 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čen odgovor je obravnavati iskanje kot prvorazredni podsistem prehoda. Ne skrivajte ga znotraj integracije enega ponudnika. Pridobivanje naj bo ločeno od generiranja, vsaki zahtevi dajte kontekst pridobivanja v obsegu najemnika, normalizirajte navedbe, preden jih vrnete, in zabeležite vsak plačljivi korak v knjigi.

Težava pri bralcu

Ekipa, ki gradi pomočnika AI za mnoge stranke, se običajno začne s preprostim potekom: naložite dokumente, vdelajte dele, pridobite najvišja ujemanja, vstavite te delčke v poziv in vprašajte model za odgovor. 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 v imenskem prostoru najemnikov, 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:

• Razreševalec najemnikov: preslika dohodni ključ API-ja, delovni prostor, račun stranke ali stranko API-ja partnerja v kanonično stranko tenant_id.
• Pridobitveni profil: določa, kateri korpus za iskanje, kateri vdelani model uporabiti, število rezultatov, filtre, možnosti prerazvrščanja, zahteve za citiranje in nadomestno vedenje.
• Prilagodniški sloj za iskanje: pokliče izvorno iskanje ponudnika, zunanjo vektorsko zbirko podatkov ali iskalno storitev po meri prek enega notranjega vmesnika.
• Hitro sestavljanje in generiranje adapter: posreduje pridobljeni kontekst izbranemu ponudniku modela, ne da bi klicateljem razkril podrobnosti vektorskega ozadja.
• Knjiga uporabe in revizije: beleži vdelavo, indeksiranje, pridobivanje, žetone za pozive, žetone za dokončanje, identifikatorje najemnika, modela, ponudnika in sledenja.

Pogodba z minimalno zahtevo lahko ostane nevtralen glede ponudnika:

{
  "tenant_id": "najemnik_123",
  "model": "gpt-združljiv-ali-claude-združljiv-model",
  "retrieval_profile": "support_docs_v2",
  "citation_required": drži,
  "sporočila": [
    {"role": "user", "content": "Kakšna je naša politika vračil za letne načrte?"}
  ]
}

Odgovor mora biti tudi nevtralen glede ponudnika:

{
  "odgovor": "Vračilo letnih načrtov je mogoče v oknu s konfiguriranimi pravilniki ...",
  "citati": [
    {
      "source_id": "doc_789",
      "title": "Politika zaračunavanja",
      "url_or_internal_ref": "kb://pravilnik-zaračunavanja",
      "chunk_id": "chunk_044",
      "odmiki": {"stran": 3},
      "ocena": 0,82,
      "retrieval_provider": "vector_db",
      "model_provider": "openai_compatible",
      "provider_payload": {}
    }
  ],
  "retrieval_trace_id": "rt_456",
  "billable_tenant": "najemnik_123",
  "embedding_usage": nič,
  "retrieval_usage": {"poizvedbe": 1, "rezultati": 6},
  "model_usage": {"input_tokens": 1920, "output_tokens": 180}}

Dejstvo: Funkcije pridobivanja ponudnika niso enake

API za vektorske shrambe OpenAI podpira vektorske shrambe, ki jih je mogoče ustvariti, iskati, konfigurirati s strategijami združevanja, 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.

Kontrole podatkov platforme OpenAI 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 tega ponudnika določiti kot stalni organ za iskanje.

Priporočilo: Uporabite Adapterji za pridobivanje, ne zaklepanje za pridobivanje

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

• Pridobivanje izvornega ponudnika: uporabno, ko stranka želi najhitrejšo pot do funkcij iskanja datotek ali vektorske shrambe enega ponudnika.
• Zunanja vektorska zbirka podatkov: uporabno, ko mora izdelek podpirati številne ponudnike modelov z dosledno izolacijo najemnikov in nadzorom življenjskega cikla.
• Vnaprej pridobljeni bloki rezultatov iskanja: uporabno ko prehod sestavi pridobljeno besedilo in ga posreduje ponudniku, ki podpira eksplicitni kontekst, ki se zaveda citiranja.

Vmesnik mora vrniti isto notranjo strukturo ne glede na zaledje:

interface RetrievalResult {
  retrievalTraceId: niz;
  tenantId: niz;
  corpusId: niz;
  kosi: Array<{
    sourceId: niz;
    naslov: niz;
    besedilo: niz;
    urlOrInternalRef?: niz;
    chunkId: niz;
    odmiki?: { stran?: številka; byteStart?: število; byteEnd?: število; tokenStart?: številka; tokenEnd?: število };
    rezultat?: število;
    metapodatki: Zapis;
    ponudnikPayload?: neznano;
  }>;
  retrievalUsage: {
    ponudnik: niz;
    queryCount: število;
    resultCount: število;
    zaračunljiveEnote?: število;
  };}

To omogoča, da generacijski sloj prejme kontekst, ne da bi vedel, ali prihaja iz vektorskih shramb OpenAI, 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štvo 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šite tenant_id iz overjene identitete prehoda, ne samo iz polja telesa, ki ga poda uporabnik.
• Preslikajte tenant_id v vektorski imenski prostor, delček ali vektorsko shrambo ponudnika. identifikator prek registra na strani strežnika.
• Zavrnite zahteve, kjer se najemnik ključa API in zahtevani najemnik korpusa ne ujemata.
• Hranite javne korpuse v skupni rabi ločene od zasebnih korpusov najemnikov.
• Uporabite filtriranje metapodatkov za vrsto dokumenta, jezik, področje izdelka ali datumsko obdobje, potem ko je meja najemnika že izbrana.
• Imenski prostor dnevnika, shard, corpus_id, retrieval_profile in retrieval_trace_id za revizijo.

Iskanje med najemniki rezervirajte 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 pripravljen odgovor in od kod prihaja spremno besedilo.

Prehod mora normalizirati podatke o navedbah v lastno shemo:

{
  "source_id": "doc_123",
  "title": "Pogoji vračila",
  "url_or_internal_ref": "kb://pogoji-vračila",
  "chunk_id": "chunk_006",
  "offsets": {"page": 2, "byte_start": 4410, "byte_end": 5020},
  "ocena": 0,79,
  "retrieval_provider": "prepletati",
  "model_provider": "antropski",
  "model_provider_citation_payload": {}
}

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

Način strogega navajanja

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 zavrnitve, ponovne poskuse in zapletenost nadomestnega načina. 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 iskanje.

Življenjski cikel indeksa je značilnost izdelka

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

Priporočene kontrole življenjskega cikla vključujejo:

• Začasni potek korpusa: dokumenti, naloženi za kratkotrajno sejo, morajo imeti časovni žig poteka in opravilo za brisanje.
• Odstranjevanje najemnika: brisanje najemnika mora postaviti v čakalno vrsto brisanje imenskih prostorov, drobci, vektorske shrambe ponudnika in sorodni datotečni objekti.
• Hladno ravnanje s najemniki: kjer je podprto, se lahko neaktivni najemniki označijo kot neaktivni ali razbremenijo, da se zmanjša uporaba virov.
• Nadzor različice ponovnega indeksiranja: shranite model vdelave, pravilnik o razčlenjevanju, različico razčlenjevalnika in indexed_at za vsak kos.
• Stanje izbrisa izpostavljenost: Delovni tokovi partnerskega API-ja bi morali pokazati, ali je brisanje dokumentov, brisanje vektorjev in brisanje na strani ponudnika dokonč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 bi bilo obrnjeno 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 indeksa in ponovno indeksiranje.
• Stroški pridobivanja: branje vektorske baze podatkov, iskanje izvorne vektorske shrambe, prerazvrščanje, ponovno pisanje poizvedbe in rezultat razširitev.
• Stroški generiranja: vhodni žetoni iz uporabniških sporočil in pridobljenega konteksta, izhodni žetoni, klici orodij, ponovni poskusi in nadomestni stroški.

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

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

Načini napak za testiranje

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

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

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

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

Zunanje vektorske baze podatkov dodajo operativno površino. Prednost je močnejša prenosljivost med modeli, združljivimi z OpenAI, modeli Anthropic 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 možnost revizije. 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 domače, vendar prehodi še vedno potrebujejo lastno pogodbo

Funkcije pridobivanja, ki izvirajo iz ponudnika, bodo verjetno postale zmogljivejše. 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 API-ja za partnerje 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, priklica in generiranja.

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

Povezano branje

• pridobivanje sledi, uporaba žetona in analitika najemnika v enem modelu opazovanja
• normalizirajte izhode, specifične za ponudnika, za stabilno pogodbo o prehodu
• povežite zagotavljanje najemnikov in merjenje uporabe s poteki dela Partner API