Multi-Tenant RAG egy OpenAI-kompatibilis API-átjáró mögött

Az ügyfelekkel szembesülő AI-asszisztenseknek visszakereséssel kiegészített generálásra van szükségük, de a RAG nehezebbé válik, ha a kérések egy OpenAI-kompatibilis API-átjárón keresztül áramlanak át, nem pedig egy modellszolgáltató natív veremén. Az átjárónak elkülönítve kell tartania a bérlői adatokat, meg kell őriznie a modellszolgáltatók hivatkozásait, ütemezetten törölnie kell az indexelt tartalmat, és a beágyazási, visszakeresési és generálási költségeket a megfelelő ügyfélhez kell rendelnie.

A gyakorlati válasz az, hogy a visszakeresést első osztályú átjáró alrendszerként kell kezelni. Ne rejtse el egy szolgáltatói integrációban. Tartsa elkülönítve a visszakeresést a generálástól, minden kérésnek adjon bérlői hatókörű lekérdezési kontextust, normalizálja az idézeteket, mielőtt visszaküldi őket, és rögzítsen minden számlázható lépést egy főkönyvben.

Az olvasói probléma

A sok ügyfél számára mesterséges intelligencia-asszisztenst építő csapat általában egy egyszerű folyamattal kezdődik: dokumentumok feltöltése, darabok beágyazása, a válaszok leggyakrabban egyezéseinek lekérése, a kérdőívek egyezése a modellbe. Ez addig működik, amíg a terméknek több modellszolgáltatóra, ügyfélszintű számlázásra, offboardozásra és auditálhatóságra van szüksége.

A kockázat nemcsak a pontatlan válaszokban rejlik. A nagyobb működési kockázatok a bérlői névterek hibái, az ellenőrizhetetlen hivatkozások, a dokumentumok törlése utáni elavult indexek és az olyan margók, amelyek nem magyarázhatók, mert a visszakeresési költségek eltűnnek az általános infrastrukturális ráfordítások között.

Ez a cikk szétválasztja a tényeket, az ajánlásokat és az előrejelzéseket. A tények a jelenlegi szolgáltatói és vektoradatbázis API-k által dokumentált megvalósítási képességek. Az ajánlások az átjárótermékek architektúrája. Az előrejelzések szerint ennek az architektúrának valószínűleg rugalmasságra van szüksége, mivel a szolgáltatói visszakeresési funkciók folyamatosan változnak.

Referenciaarchitektúra

Az átjáró szintű RAG-tervnek öt összetevőből kell állnia:

• Bérlői feloldó: a bejövő API-kulcsot, munkaterületet, ügyfélfiókot, vagypartneri API-ügyfelet egy azonosítóhoz rendeli. profil: meghatározza, hogy melyik korpuszban kell keresni, melyik beágyazási modellt kell használni, az eredmények számát, a szűrőket, az átsorolási lehetőségeket, a hivatkozási követelményeket és a tartalék viselkedést.
• Lekérési illesztőréteg: natív szolgáltatói lekérést, külső vektoradatbázist vagy egyéni keresési szolgáltatást hív meg egyetlen belső interfészen keresztül, a választott kontextus-szolgáltató generálása nélkül.
• Kikéri a generálást.
• Promptrie: vektoros háttérinformációk a hívók számára.
• Használati és ellenőrzési főkönyv: rögzíti a beágyazást, az indexelést, a visszakeresést, a prompt tokeneket, a befejezési jogkivonatokat, a bérlőt, a modellt, a szolgáltatót és a nyomkövetési azonosítókat.

A minimális kérési szerződés szolgáltatósemleges maradhat:

<-kód>
  "bérlő_azonosítója": "bérlő_123",
  "modell": "gpt-kompatibilis-or-claude-kompatibilis-modell",
  "retrieval_profile": "support_docs_v2",
  "citation_required": igaz,
  "üzenetek": [
    {"role": "user", "content": "Mi a visszatérítési irányelvünk az éves tervekre?"}
  ]
}

A válasznak szolgáltatósemlegesnek kell lennie:

{
  "answer": "Az éves előfizetések a beállított házirend-ablakon belül visszatéríthetők...",
  "idézetek": [
    {
      "source_id": "doc_789",
      "title": "Számlázási szabályzat",
      "url_or_internal_ref": "kb://billing-policy",
      "chunk_id": "chunk_044",
      "offsets": {"oldal": 3},
      "pontszám": 0,82,
      "retrieval_provider": "vector_db",
      "model_provider": "openai_compatibilis",
      "provider_payload": {}
    }
  ],
  "retrieval_trace_id": "rt_456",
  "billable_tenant": "bérlő_123",
  "embedding_usage": null,
  "retrieval_usage": {"queries": 1, "results": 6},
  "model_usage": {"input_tokens": 1920, "output_tokens": 180}}

Tény: A szolgáltató visszakeresési funkciói nem azonosak

Az OpenAI Vector Stores API támogatja a vektortárolókat, amelyek létrehozhatók, kereshetők, konfigurálhatók darabolási stratégiákkal, társíthatók a fájlok metaadataihoz és törölhetők. A vektoros áruházban végzett keresés támogatja a lekérdezéseket, szűrőket, maximális találatszámot, rangsorolási beállításokat, pontszámküszöböket és a lekérdezések átírási vezérlőit. Ezek a vezérlők hasznos gombokat adnak az átjárók készítőinek a várakozási idő, a relevancia és a költségek tekintetében.

Az OpenAI platform adatvezérlői az életciklus-tervezést is fontossá teszik: a vektortárak vásárlói tartalmát törlésig megőrzik. Ha egy bérlő kilép az alapból, vagy ha egy ideiglenes projekt lejár, az átjáró nem feltételezheti, hogy a szolgáltató automatikusan eltávolítja az indexelt tartalmat a termék üzleti ütemtervében.

Az Anthropic más mintát tesz közzé az idézetek esetében. Az alkalmazások a keresési eredmények tartalmi blokkjait forrás- és cím-metaadatokkal látják el, és ha a hivatkozások engedélyezve vannak, a modell hivatkozásokat csatolhat a generált szöveghez. Vannak gyakorlati korlátok: a keresési eredmények hivatkozási beállításai egy kérésben „mindent vagy semmit”, a keresési eredményblokkok támogatják a szöveges tartalmat, az idézetek részletessége pedig attól függ, hogy a tartalom hogyan van felosztva blokkra.

A következmény közvetlen: az átjáró nem teheti közzé egyik szolgáltató lekérési alakját nyilvános szerződésként, kivéve, ha azt a szolgáltatót kívánja állandó visszakeresési jogosultsággá tenni.

Reference: Visszakeresési adapterek, nem visszakeresési zárolás

Hozzon létre egy belső visszakereső adapter interfészt. Az átjáró több háttérprogramot is támogathat mögötte:

• Natív szolgáltató lekérése: akkor hasznos, ha az ügyfél a leggyorsabb elérési utat szeretné elérni egy szolgáltató fájlkeresői vagy vektortár funkcióihoz.
• Külső vektoradatbázis: akkor hasznos, ha a terméknek számos modellszolgáltatót kell támogatnia konzisztens bérlői elkülönítéssel és hasznos keresési eredményekpre-li>használattal. amikor az átjáró összeállítja a beolvasott szöveget, és átadja azt egy olyan szolgáltatónak, amely támogatja az explicit idézet-tudatos kontextust.

Az illesztőnek ugyanazt a belső struktúrát kell visszaadnia a háttértől függetlenül:

interface RetrievalResult {
  retrievalTraceId: string;
  bérlőId: karakterlánc;
  corpusId: string;
  darabok: tömb<{
    forrásazonosító: karakterlánc;
    cím: string;
    szöveg: string;
    urlOrInternalRef?: string;
    chunkId: string;
    eltolások?: { oldal?: szám; byteStart?: szám; byteEnd?: szám; tokenStart?: szám; tokenEnd?: szám };
    pontszám?: szám;
    metaadatok: Record;
    szolgáltatóPayload?: ismeretlen;
  }>;
  retrievalUsage: {
    szolgáltató: string;
    queryCount: szám;
    resultCount: szám;
    billableUnits?: szám;
  };}

Ez lehetővé teszi a generációs réteg számára, hogy kontextust kapjon anélkül, hogy tudná, hogy OpenAI vektortárolókból, Pinecone-ból, Weaviate-ből, egy adatbázis teljes szöveges keresési indexéből vagy egy belső hibrid retrieverből származik-e.

A bérlő elkülönítése a vektorlekérdezés előtt kezdődik

A bérlői elkülönítés nem függhet az azonnali utasításoktól. Kényszeríteni kell a visszakeresés előtt, a tárhely és a lekérdezés határán.

A Pinecone-stílusú rendszerek esetében a dokumentált többbérleti minta bérlőnként egy névtér a szerver nélküli indexekben. Az adatsík-műveletek egy névteret céloznak meg, ami leegyszerűsíti a bérlői elkülönítést és a kilépést, mivel a névtér törlésével eltávolítják a bérlő rekordjait. A Pinecone a névterek és a metaadat-szűrés közötti kompromisszumokat is dokumentálja: a nagy megosztott névtéren belüli szűrés több adatot vizsgálhat, többe kerülhet, és lassabban teljesíthet, mint a névtér hatókörű lekérdezések.

A Weaviate-stílusú rendszerek esetében a több bérlő minden bérlőt külön szilánkon tárol, így az egyik bérlő adatai nem láthatók a másik bérlő számára. A bérlő törlése törli a társított szilánkot. A Weaviate támogatja az olyan bérlői állapotokat is, mint például az aktív, az inaktív és a leterhelt, ami életciklus-beállítást hoz létre a ritkán használt bérlők számára.

Megvalósítási ellenőrzőlista

• A tenant_id megoldása a hitelesített átjáró-identitás alapján történik, ne csak a felhasználó által megadott törzsmezőből.
• Map vector name_id, vector name store, vector name_id. azonosító egy szerveroldali regisztrációs adatbázison keresztül.
• Az olyan kérések elutasítása, amelyekben az API-kulcs-bérlő és a kért korpuszbérlő nem egyezik.
• Tartsa elkülönítve a megosztott nyilvános korpuszokat a privát bérlői korpuszoktól.
• Használjon metaadat-szűrést a dokumentumtípushoz, nyelvhez, termékterülethez vagy dátumtartományhoz, miután a bérlői határ, corpusli>s már ki van választva. retrieval_profile és retrieval_trace_id az auditálhatóság érdekében.

Foglaljon bérlőközi keresést explicit adminisztrációs munkafolyamatokhoz külön jogosultsággal, külön indexekkel vagy ellenőrzött összesítési útvonalakkal. Ne tegye a bérlők közötti keresést a metaadatszűrők véletlen mellékhatásává.

Az idézetek normalizálása átjáróobjektumként

Az idézetek termékszerződést jelentenek, nem csak dekorációt. Az ügyfélszolgálati asszisztensnek, a jogi megfogalmazó eszköznek vagy a belső tudástársnak meg kell mutatnia, hogy miért jött létre a válasz, és honnan származik a támogató szöveg.

Az átjárónak normalizálnia kell a hivatkozási adatokat a saját sémájába:

{
  "source_id": "doc_123",
  "title": "Visszatérítési feltételek",
  "url_or_internal_ref": "kb://refund-terms",
  "chunk_id": "chunk_006",
  "offsets": {"page": 2, "byte_start": 4410, "byte_end": 5020},
  "pontszám": 0,79,
  "retrieval_provider": "weaviate",
  "model_provider": "antropikus",
  "model_provider_citation_payload": {}
}

Tartsa stabilan a normalizált mezőket, és engedélyezze a szolgáltató-specifikus bővítményeket. Egyes szolgáltatók gazdagabb hivatkozási adatokat tesznek közzé, mint mások. Egyesek keresési eredményblokkokat fognak idézni. Néhányan a feltöltött fájlokat idézik. Néhányan nem biztosítják az alkalmazás által kívánt pontos eltolási formátumot. Az átjárónak meg kell őriznie a létezőt anélkül, hogy azt tenné, hogy minden szolgáltató azonos hivatkozási szemantikával rendelkezzen.

Strict Citation Mode

Ha a citation_required értéke igaz, előre határozza meg a hibajelenséget. A szigorú mód megkövetelheti, hogy minden tényszerű bekezdés tartalmazzon legalább egy idézetet, vagy hogy a végső válasz tartalmazzon idézeteket a minimális pontszámérték feletti részletekből. Ha a kiválasztott modellszolgáltató nem tudja teljesíteni az idézési szerződést, az átjárónak gyorsan meg kell hibáznia, kompatibilis szolgáltatót kell használnia, vagy strukturált visszautasítást kell küldenie.

Ez egy ajánlás, nem pedig általános szabály. A szigorú idézési mód javítja a bizalmat, de növelheti az elutasításokat, az újrapróbálkozásokat és a tartalék összetettségét. Alacsony kockázatú kreatív munkafolyamatok esetén az idézetek nem kötelezőek. Az ügyfelek felé irányuló támogatás vagy szabályozott belső munkafolyamatok esetén a citation_required gyakran a visszakeresési profil részét kell, hogy képezze.

Az index életciklusa a termék jellemzője

A RAG-rendszerek adatokat halmoznak fel. Az ideiglenes feltöltések véletlenül állandósulnak. A korábbi ügyfelek beágyazásokat hagynak maguk után. A termékcsapatok megváltoztatják a darabolási stratégiákat, és elfelejtik újjáépíteni a régi indexeket.Az átjárónak egyértelművé kell tennie az életciklus-vezérlőket.

A javasolt életciklus-vezérlők közé tartoznak a következők:

• Ideiglenes korpusz lejárata: a rövid időtartamú munkamenethez feltöltött dokumentumoknak lejárati időbélyeggel és törlési feladattal kell rendelkezniük.
• Bérlői terület törlése, név törlése: szilánkok, szolgáltatói vektortárolók és kapcsolódó fájlobjektumok.
• Hideg bérlői kezelés: ahol támogatott, az inaktív bérlők inaktívként jelölhetők meg vagy tehermentesíthetők az erőforrás-felhasználás csökkentése érdekében.
• Verzióvezérlés újraindexelése: tárolja a beágyazási modellt, a csonkolási házirendet, az elemző verzióját és az egyes partnerek állapotát exponálás
Az API-munkafolyamatoknak meg kell mutatniuk, hogy a dokumentumtörlés, a vektortörlés és a szolgáltató oldali törlés befejeződött-e.

A fontos tény az, hogy a vektortár tartalmának egy része törlésig megmarad. Az architektúra javaslata az, hogy a törlést láthatóvá és tesztelhetővé kell tenni, ahelyett, hogy egy aszinkron feladatba temetné el, ügyféloldali állapot nélkül.

Három költségkönyv követése

A RAG számára nem elegendő egyetlen token főkönyv. Egy átjárónak legalább három főkönyvre van szüksége:

• Beágyazási és indexelési költség: dokumentumelemzés, csonkolás, hívások beágyazása, fájlok tárolása, indexírás és újraindexelés.
• Lekérési költség: vektoros adatbázis olvasása, natív vektortár keresés, keresés és találatok átsorolása, bővítés.
• Előállítási költség: bemeneti tokenek a felhasználói üzenetekből és a lekért kontextusból, a kimeneti tokenek, az eszközhívások, az újrapróbálkozások és a tartalékok.

Ez különösen fontos az ügynökségek, a SaaS-szállítók és a mesterséges intelligencia költségeit továbbértékesítő vagy felosztó belső platformcsapatok számára. Külön főkönyvek nélkül az RAG margók nehezen magyarázhatók. Egy kis generációs használatú bérlő még mindig drága lehet, ha folyamatosan tölt fel dokumentumokat, újraindexel nagy korpuszokat vagy széles körű lekérdezési lekérdezéseket futtat.

Minden főkönyvi eseménynek tartalmaznia kell a tenant_id, customer_id, ha különbözik, az API kulcsazonosítót, a lekérési_profilt, a korpuszazonosítót, a modellt, a szolgáltatót, a nyomkövetési azonosítót és a számlázható egységeket. Ez lehetővé teszi, hogy a használati elemzés gyakorlati kérdésekre válaszoljon: mely bérlők rendelkeznek drága visszakeresési profillal, mely korpuszok elavultak, mely modellek idéznek elő hibákat, és mely ügyfelek generálnak túlméretezett felszólításokat, mert a visszakeresés túl sok kontextust ad vissza.

Tesztelendő hibamódok

Egy átjáró RAG-nak kell lennie, hogy tesztelje az ügyfél-látható hibamódokat. kár:

• Hiányzó hivatkozások: a citation_required igaz, de a szolgáltatói válasz nem tartalmaz használható hivatkozási hivatkozásokat.
• Elavult indexek: egy dokumentumot frissítettek vagy töröltek, de a régi darabok továbbra is megjelennek a lekérési eredményekben.
• A bérlő neve vagy a kérés feloldása, míg ahoz tartozó korpusz nem egyezik: B-bérlőnek.
• Túl széleskörű lekérdezés: a profil túl sok darabot ad vissza, ami növeli a költségeket és gyengíti a válasz minőségét.
• Részletméret eltérés: a darabok olyan nagyok, hogy az idézetek pontatlanok, vagy olyan kicsik, hogy a kontextus értelmét veszti.
• Míg a hivatkozások kibocsáthatják az egyik funkciót, amelyhez szükséges ch Provi: nem lehet.
• Életciklus-hiba: törlést kérnek, de a szolgáltató oldali tárhely aktív vagy ellenőrizetlen marad.

Ezeknek a teszteknek az átjárószerződés szintjén kell futniuk, nem csak egy szolgáltatói adapteren belül. A cél annak bizonyítása, hogy a nyilvános viselkedés stabil marad, amikor a visszakeresési háttér- vagy generációs szolgáltató megváltozik.

Kiváltások

A natív szolgáltató lekérése csökkentheti az alkalmazáskódot és felgyorsíthatja az első verziót. A kompromisszum az, hogy a tárolási életciklus, a hivatkozási formátum, a lekérdezésvezérlők és a szolgáltatások elérhetősége egy szolgáltatóhoz köthető.

A külső vektoradatbázisok működési területet növelnek. Az előny az erősebb hordozhatóság az OpenAI-kompatibilis modellek, az Anthropic modellek és a jövőbeli szolgáltatók között. Ezenkívül megkönnyítik a bérlői hatókörű névterek vagy töredékek megfontolását, hogy az átjáró mikor felelős a számlázásért és az offboardingért.

A finomszemcsés darabok javítják az idézés pontosságát és ellenőrizhetőségét. Ezenkívül növelik az index méretét, a visszakeresési mennyiséget és az azonnali összeszerelés bonyolultságát. A durva darabok egyszerűbbek, de olyan idézeteket hozhatnak létre, amelyek egy széles oldalra vagy szakaszra mutatnak, nem pedig a pontos alátámasztó részre.

A szigorú hivatkozási mód javítja a felhasználók bizalmát.Arra is kényszeríti az átjárót, hogy kezelje azokat a modelleket, amelyek nem tudják előállítani a szükséges idézési formátumot, ami a kérés elutasítását, modellváltást vagy alacsonyabb megbízhatósági állapotú válasz visszaküldését jelentheti.

Előrejelzés: A visszakeresés natívabb lesz, de az átjáróknak továbbra is szükségük van saját szerződésre

A szolgáltató natív visszakeresési funkciói valószínűleg jobban használhatók lesznek. Több modell elfogadja a lekért kontextust strukturált forrás metaadatokkal. Több API teszi elérhetővé a rangsorolási vezérlőket, a lekérdezések átírását és a hivatkozási beállításokat. Ez nem szünteti meg az átjárószerződés szükségességét.

Az átjáró továbbra is birtokolja a bérlői identitást, a kulcskezelést, a ráfordítási korlátokat, a használati elemzést, a Partner API munkafolyamatait és az ügyfelekre vonatkozó törlési ígéreteket. A szolgáltatói funkciók használhatók az illesztőréteg mögött, de a termék nem kényszeríthet minden bérlőt, modellt és számlázási munkafolyamatot egyetlen szolgáltató lekérési absztrakciójába.

Cselekvő következtetés

A több-bérlős RAG létrehozása egyértelmű határokkal rendelkező átjáró alrendszerként. A visszakeresés előtt oldja meg a bérlő identitását. Használjon bérlői hatókörű névtereket, szilánkokat vagy vektortárolókat. Tartsa a visszakeresést az adapterek mögött. Normalizálja az idézeteket egy átjáró tulajdonában lévő sémává. Életciklus-állapotok hozzáadása és a törlés ellenőrzése. Külön nyomon követheti a beágyazás, a visszakeresés és az előállítás költségeit.

Ez az architektúra a RAG-ot földelve tartja anélkül, hogy a terméket egyetlen visszakeresési szolgáltatóhoz kötné. Ezenkívül biztosítja a csapatok számára azokat a működési vezérlőket, amelyekre szükségük van, amikor az AI-asszisztens prototípusról ügyfélközpontú rendszerre vált át: elkülönítés, hivatkozások, hordozhatóság, életciklus-kezelés és költség-hozzárendelés.

Kapcsolódó olvasmányok

• nyomkövetés, tokenhasználat és bérlői elemzés egyetlen megfigyelési modellben
• szolgáltatóspecifikus kimenetek normalizálása egy stabil átjárószerződés mögött
• a bérlői kiépítés és a használati mérés összekapcsolása a Partner API munkafolyamataival