Multi-Tenant RAG za bránou API kompatibilnou s OpenAI

Asistenti AI orientovaní na zákazníka potrebujú generovanie rozšírené o vyhľadávanie, ale RAG sa stáva zložitejším, keď požiadavky prechádzajú cez bránu API kompatibilnú s OpenAI namiesto natívneho zásobníka jedného poskytovateľa modelu. Brána musí uchovávať údaje nájomníkov izolované, uchovávať citácie medzi poskytovateľmi modelov, odstraňovať indexovaný obsah podľa plánu a pripisovať náklady na vkladanie, vyhľadávanie a generovanie správnemu zákazníkovi.

Praktická odpoveď je považovať vyhľadávanie za prvotriedny podsystém brány. Neskrývajte to v rámci integrácie jedného poskytovateľa. Udržujte vyhľadávanie oddelené od generovania, poskytnite každej požiadavke kontext získavania v rozsahu nájomníka, normalizujte citácie pred ich vrátením a zaznamenajte každý fakturovateľný krok do knihy.

Problém s čitateľom

Tím zostavujúci asistenta AI pre mnohých zákazníkov zvyčajne začína jednoduchým postupom: nahrajte dokumenty, vložte časti, načítajte najlepšie zhody do modelu a vložte ich do úryvku. Funguje to dovtedy, kým produkt nepotrebuje viacerých poskytovateľov modelov, fakturáciu na úrovni zákazníka, offboarding a auditovateľnosť.

Rizikom nie sú len nepresné odpovede. Väčšie prevádzkové riziká sú chyby v mennom priestore nájomníkov, neoveriteľné citácie, neaktuálne indexy po odstránení dokumentu a marže, ktoré nemožno vysvetliť, pretože náklady na vyhľadávanie miznú do všeobecných výdavkov na infraštruktúru.

Tento článok oddeľuje fakty, odporúčania a predpovede. Fakty sú implementačné schopnosti zdokumentované súčasným poskytovateľom a vektorovými databázovými API. Odporúčania sú voľbami architektúry pre produkt brány. Predpovede sú miesta, kde táto architektúra bude pravdepodobne potrebovať flexibilitu, pretože funkcie získavania poskytovateľa sa neustále menia.

Referenčná architektúra

Návrh RAG na úrovni brány by mal mať päť komponentov:

• Tenant resolver: mapuje prichádzajúci kľúč API, pracovný priestor, zákaznícky účet alebo partnera API definuje profil na kanonický profil. ktorý korpus na vyhľadávanie, ktorý model vkladania použiť, počet výsledkov, filtre, možnosti zmeny poradia, požiadavky na citácie a záložné správanie.
• Vrstva adaptéra načítania: volá vyhľadávanie natívneho poskytovateľa, externú vektorovú databázu alebo službu vlastného vyhľadávania cez jedno interné rozhranie.
• Výzva na zostavenie a generovanie vektorového adaptéra: odovzdá načítaný kontext modelu vybranému poskytovateľovi. volajúcich.
• Hlavná kniha používania a auditu: zaznamenáva vkladanie, indexovanie, získavanie, tokeny výzvy, tokeny dokončenia, nájomníka, model, poskytovateľa a identifikátory sledovania.

Zmluva s minimálnou požiadavkou môže zostať neutrálna voči poskytovateľovi:

{
  "tenant_id": "tenant_123",
  "model": "gpt-compatible-or-claude-compatible-model",
  "retrieval_profile": "support_docs_v2",
  "citation_required": pravda,
  "správy": [
    {"role": "user", "content": "Aké sú naše pravidlá vrátenia peňazí pre ročné programy?"}
  ]
}

Odpoveď by tiež mala byť neutrálna voči poskytovateľovi:

{
  "answer": "Ročné plány je možné vrátiť v rámci nakonfigurovaného okna politiky...",
  "citácie": [
    {
      "source_id": "doc_789",
      "title": "Fakturačné pravidlá",
      "url_or_internal_ref": "kb://billing-policy",
      "chunk_id": "chunk_044",
      "offsets": {"page": 3},
      "skóre": 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}}

Fakt: Funkcie získavania poskytovateľov nie sú identické

Rozhranie Vector Stores API OpenAI podporuje vektorové obchody, ktoré možno vytvárať, vyhľadávať, konfigurovať pomocou stratégií chunkingu, spájať s metaúdajmi súborov a odstraňovať. Vyhľadávanie vektorových obchodov podporuje dotazy, filtre, maximálny počet výsledkov, možnosti hodnotenia, prahové hodnoty skóre a ovládacie prvky prepisovania dotazov. Tieto ovládacie prvky poskytujú autorom brán užitočné ovládače pre latenciu, relevanciu a náklady.

Ovládacie prvky dát platformy OpenAI tiež robia návrh životného cyklu dôležitým: obsah zákazníkov vo vektorových obchodoch sa uchováva až do vymazania. Ak nájomca odíde alebo ak vyprší dočasný projekt, brána nemôže predpokladať, že poskytovateľ automaticky odstráni indexovaný obsah z obchodného plánu produktu.

Anthropic odhaľuje iný vzor pre citácie. Aplikácie môžu poskytovať bloky obsahu výsledkov vyhľadávania s metadátami zdroja a názvu, a keď sú povolené citácie, model môže k vygenerovanému textu pripojiť odkazy na citácie. Existujú praktické obmedzenia: nastavenia citácií výsledkov vyhľadávania sú v rámci požiadavky všetko alebo nič, bloky výsledkov vyhľadávania podporujú textový obsah a granularita citácií závisí od toho, ako je obsah rozdelený do blokov.

Dôsledok je priamy: brána by nemala odhaľovať formu získavania jedného poskytovateľa ako svoju verejnú zmluvu, pokiaľ nemá v úmysle urobiť z tohto poskytovateľa stálu autoritu na získavanie2>Použitie:Retrieval:Retrieval ,

Lock-In

Vytvorte interné rozhranie adaptéra na vyhľadávanie. Brána môže podporovať niekoľko backendov za ňou:

• Natívne vyhľadávanie poskytovateľa: užitočné, keď zákazník chce najrýchlejšiu cestu k funkciám vyhľadávania súborov alebo ukladania vektorov od jedného poskytovateľa.
• Externá vektorová databáza: užitočné, keď produkt musí podporovať mnoho poskytovateľov zostavy modelov s konzistentnou izoláciou nájomníkov a ovládacími prvkami životného cyklu
užitočné bloky hľadania pri opätovnom vyhľadanípretrieť užitočný výsledok vyhľadávania. text a odovzdá ho poskytovateľovi, ktorý podporuje explicitný citačný kontext.

Adaptér by mal vrátiť rovnakú vnútornú štruktúru bez ohľadu na backend:

interface RetrievalResult {
  retrievalTraceId: reťazec;
  tenantId: reťazec;
  corpusId: string;
  chunks: Array<{
    sourceId: reťazec;
    názov: reťazec;
    text: reťazec;
    urlOrInternalRef?: string;
    chunkId: reťazec;
    ofsety?: { strana?: číslo; byteStart?: číslo; byteEnd?: číslo; tokenStart?: číslo; tokenEnd?: číslo };
    skóre?: číslo;
    metadáta: Záznam;
    providerPayload?: neznáme;
  }>;
  retrievalUsage: {
    poskytovateľ: reťazec;
    queryCount: číslo;
    vysledokPocet: cislo;
    billableUnits?: číslo;
  };}

To umožňuje generačnej vrstve prijímať kontext bez toho, aby vedela, či pochádza z vektorových obchodov OpenAI, Pinecone, Weaviate, databázového fulltextového vyhľadávacieho indexu alebo interného hybridného retrievera.

Izolácia nájomníkov sa začne pred vektorovým dotazom

Izolácia nájomníkov nesmie závisieť od rýchlych pokynov. Musí sa vynútiť pred načítaním, na hranici úložiska a na hranici dotazu.

Pre systémy typu Pinecone je zdokumentovaným vzorom viacerých nájomníkov jeden priestor názvov na nájomníka v indexoch bez serverov. Operácie dátovej roviny sa zameriavajú na priestor názvov, čo zjednodušuje izoláciu nájomníkov a vyraďovanie z platformy, pretože odstránením priestoru názvov sa odstránia záznamy daného nájomníka. Pinecone tiež dokumentuje kompromisy medzi priestormi názvov a filtrovaním metadát: filtrovanie vo veľkom zdieľanom priestore názvov môže skenovať viac údajov, stáť viac a vykonávať pomalšie ako dopyty s rozsahom názvov.

V prípade systémov v štýle Weaviate ukladá viacero nájomníkov každého nájomníka na samostatný zlomok, takže údaje jedného nájomníka nie sú viditeľné pre iného nájomníka. Odstránením nájomníka sa odstráni súvisiaci zlomok. Weaviate tiež podporuje stavy nájomníkov, ako sú aktívny, neaktívny a odložený, čo vytvára možnosť životného cyklu pre zriedkavo používaných nájomníkov.

Kontrolný zoznam implementácie

• Rozlišujte tenant_id z overenej identity brány, nie z poľa tela dodaného používateľom samotného.
• Mapujte tenant_id, cez vektorový server názvov alebo názvov vektora, s. registra.
• Odmietnite požiadavky, ak sa nájomník kľúča API a požadovaný nájomník korpusu nezhodujú.
• Zdieľané verejné korpusy uchovávajte oddelene od súkromných korpusov nájomníka.
• Použite filtrovanie metadát pre typ dokumentu, jazyk, oblasť produktu alebo rozsah dátumov, keď už bola vybratá hranica nájomníka.
• Zaznamenať priestor názvov,corpus_trieprofil,refil, retrieval_trace_id pre auditovateľnosť.

Vyhradzujte si vyhľadávanie medzi nájomníkmi pre explicitné administratívne pracovné postupy so samostatnou autorizáciou, samostatnými indexmi alebo riadenými cestami agregácie. Nerobte z vyhľadávania medzi nájomníkmi náhodný vedľajší efekt filtrov metadát.

Normalizácia citácií ako objektov brány

Citácie sú zmluvou o produkte, nie len ozdobou. Asistent zákazníckej podpory, právny nástroj na vytváranie návrhov alebo interný znalecký asistent musia ukázať, prečo bola odpoveď vytvorená a odkiaľ pochádza podporný text.

Brána by mala normalizovať citačné údaje do vlastnej schémy:

{
  "source_id": "doc_123",
  "title": "Podmienky vrátenia peňazí",
  "url_or_internal_ref": "kb://podmienky vrátenia platby",
  "chunk_id": "chunk_006",
  "offsets": {"page": 2, "byte_start": 4410, "byte_end": 5020},
  "skóre": 0,79,
  "retrieval_provider": "prepletať",
  "model_provider": "antropický",
  "model_provider_citation_payload": {}
}

Udržiavajte normalizované polia stabilné a povoľte rozšírenia špecifické pre poskytovateľa. Niektorí poskytovatelia odhalia bohatšie podrobnosti o citáciách ako iní. Niektorí budú citovať bloky výsledkov vyhľadávania. Niektorí budú citovať nahrané súbory. Niektoré neposkytnú presný formát ofsetu, ktorý vaša aplikácia požaduje. Brána by mala zachovať to, čo existuje, bez toho, aby predstierala, že každý poskytovateľ má rovnakú citačnú sémantiku.

Režim prísneho citovania

Keď má citation_required hodnotu true, definujte správanie zlyhania vopred. Striktný režim môže vyžadovať, aby každý faktický odsek obsahoval aspoň jednu citáciu, alebo aby konečná odpoveď obsahovala citácie z vrátených častí nad minimálnym skóre. Ak vybraný modelový poskytovateľ nemôže splniť citačnú zmluvu, brána by mala rýchlo zlyhať, použiť kompatibilného poskytovateľa alebo vrátiť štruktúrované odmietnutie.

Toto je odporúčanie, nie univerzálne pravidlo. Režim prísneho citovania zvyšuje dôveru, ale môže zvýšiť zložitosť odmietnutí, opakovaní a záložných riešení. Pre kreatívne pracovné postupy s nízkym rizikom môžu byť citácie voliteľné. Pre zákaznícku podporu alebo regulované interné pracovné postupy by citation_required mala byť často súčasťou profilu vyhľadávania.

Indexový životný cyklus je vlastnosť produktu

Systémy RAG zhromažďujú údaje. Dočasné nahrania sa náhodne stanú trvalými. Bývalí zákazníci zanechávajú vložené prvky. Produktové tímy menia stratégie rozdeľovania a zabúdajú na prestavbu starých indexov.Brána by mala explicitne uvádzať ovládacie prvky životného cyklu.

Odporúčané ovládacie prvky životného cyklu zahŕňajú:

• Dočasné uplynutie platnosti korpusu: dokumenty nahrané pre krátkodobú reláciu by mali mať časovú pečiatku vypršania platnosti a úlohu odstránenia.
• Odchod nájomníka: súvisiace s odstránením priestoru poskytovateľa, sdeleu vektora a sdeleu. súbor objektov.
• Chladné spracovanie nájomníkov: ak je to podporované, neaktívni nájomníci môžu byť označení ako neaktívni alebo stiahnutí, aby sa znížilo využitie prostriedkov.
• Opätovné indexovanie riadenia verzií: ukladajte model vkladania, politiku chunkingu, verziu analyzátora a indexed_at pre každý blok.
• Odstránenie by malo fungovať zobrazenie rozhrania API partnera: vymazanie a odstránenie na strane poskytovateľa je dokončené.

Dôležitým faktom je, že určitý obsah vektorového obchodu sa uchováva až do odstránenia. Odporúčanie architektúry je urobiť vymazanie viditeľným a testovateľným, namiesto toho, aby bolo pochované v asynchrónnej úlohe bez stavu, ktorý by mohol čeliť zákazníkovi.

Sledovať tri účtovné knihy nákladov

Jedna účtovná kniha tokenov pre RAG nestačí. Brána potrebuje aspoň tri účtovné knihy:

• Náklady na vkladanie a indexovanie: analyzovanie dokumentov, chunkovanie, volania vkladania, ukladanie súborov, zápisy do indexov a preindexovanie.
• Cena získania: čítanie vektorovej databázy, prehodnotenie, prepisovanie v obchodoch s natívnymi vektormi, prepisovanie dopytov
• vstupné náklady na výsledky a
• vstup do výsledkov. zo správ používateľov a načítaného kontextu, výstupných tokenov, volaní nástrojov, opakovaní a núdzových riešení.

Toto je dôležité najmä pre agentúry, predajcov SaaS a interné tímy platforiem, ktoré predávajú alebo alokujú náklady na AI. Bez samostatných účtovných kníh je ťažké vysvetliť marže RAG. Nájomník s malou generáciou využitia môže byť stále drahý, ak neustále nahráva dokumenty, reindexuje veľké korpusy alebo spúšťa rozsiahle vyhľadávacie dopyty.

Každá udalosť účtovnej knihy by mala zahŕňať tenant_id, customer_id, ak je iný, ID kľúča API, retrieval_profile, corpus_id, model, poskytovateľa, trace_id a fakturovateľné jednotky. To umožňuje analytike používania odpovedať na praktické otázky: ktorí nájomníci majú drahé profily na vyhľadávanie, ktoré korpusy sú neaktuálne, ktoré modely spôsobujú zlyhania citácií a ktorí zákazníci generujú príliš veľké výzvy, pretože vyhľadávanie vracia príliš veľa kontextu.

Režimy zlyhania na testovanie

Podsystém brány RAG by mal mať testy na zlyhávanieMódy zlyhávania, ktoré spôsobujú poškodenie zákazníka:>Mulissum: citácie: citation_required je pravdivé, ale odpoveď poskytovateľa neobsahuje žiadne použiteľné citačné referencie.