Multi-Tenant RAG za bránou API kompatibilní s OpenAI

Asistenti umělé inteligence orientovaní na zákazníka potřebují generování rozšířené o načítání, ale RAG se stává obtížnějším, když požadavky procházejí bránou API kompatibilní s OpenAI namísto nativního zásobníku jednoho poskytovatele modelu. Brána musí uchovávat data tenantů izolovaná, uchovávat citace napříč poskytovateli modelů, mazat indexovaný obsah podle plánu a přiřazovat náklady na vkládání, načítání a generování správnému zákazníkovi.

Praktická odpověď je považovat vyhledávání za prvotřídní podsystém brány. Neschovávejte to uvnitř integrace jednoho poskytovatele. Udržujte vyhledávání oddělené od generování, poskytněte každému požadavku kontext vyhledávání v rozsahu tenanta, normalizujte citace před jejich vrácením a zaznamenejte každý zúčtovatelný krok do účetní knihy.

Problém čtenáře

Tým vytvářející asistenta AI pro mnoho zákazníků obvykle začíná jednoduchým postupem: nahrajte dokumenty, vkládejte části, načtěte nejlepší shody do modelu a vložte je do úryvku. To funguje, dokud produkt nepotřebuje více poskytovatelů modelů, fakturaci na úrovni zákazníka, offboarding a auditovatelnost.

Rizikem nejsou pouze nepřesné odpovědi. Většími provozními riziky jsou chyby v oboru názvů tenantů, neověřitelné citace, zastaralé indexy po smazání dokumentu a marže, které nelze vysvětlit, protože náklady na vyhledání zmizí do generických výdajů na infrastrukturu.

Tento článek odděluje fakta, doporučení a předpovědi. Fakta jsou implementační schopnosti dokumentované aktuálními poskytovateli a vektorovými databázovými API. Doporučení jsou volbami architektury pro produkt brány. Podle předpovědí bude tato architektura pravděpodobně potřebovat flexibilitu, protože funkce získávání poskytovatelů se neustále mění.

Referenční architektura

Návrh RAG na úrovni brány by měl mít pět komponent:

• Tenant resolver: mapuje příchozí klíč API, pracovní prostor, zákaznický účet nebo partnera API pro definování profilu na kanonický profil. který korpus prohledat, který model vkládání použít, počet výsledků, filtry, možnosti změny pořadí, požadavky na citace a záložní chování.
• Vrstva adaptéru načítání: volá načítání nativního poskytovatele, externí vektorovou databázi nebo službu vlastního vyhledávání prostřednictvím jednoho interního rozhraní.
• Výzva sestavení a generování vektorového adaptéru: předá načtený kontext modelu vybranému poskytovateli. volající.
• Jednotka využití a auditu: zaznamenává vkládání, indexování, načítání, tokeny výzvy, tokeny dokončení, identifikátory nájemce, modelu, poskytovatele a trasování.

Smlouva o minimálním požadavku může zůstat neutrální vůči poskytovateli:

{
  "tenant_id": "tenant_123",
  "model": "gpt-compatible-or-claude-compatible-model",
  "retrieval_profile": "support_docs_v2",
  "citation_required": true,
  "zprávy": [
    {"role": "user", "content": "Jaké jsou naše zásady vracení peněz u ročních tarifů?"}
  ]
}

Odpověď by také měla být neutrální vůči poskytovateli:

{
  "answer": "Roční plány lze vrátit v rámci nakonfigurovaného okna zásad...",
  "citace": [
    {
      "source_id": "doc_789",
      "title": "Fakturační zásady",
      "url_or_internal_ref": "kb://fakturace-zásady",
      "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}}

Skutečnost: Funkce získávání poskytovatelů nejsou totožné

Rozhraní Vector Stores API OpenAI podporuje vektorová úložiště, která lze vytvářet, prohledávat, konfigurovat pomocí strategií rozdělování, spojovat je s metadaty souborů a mazat. Vector store search supports queries, filters, maximum result counts, ranking options, score thresholds, and query rewriting controls. Tyto ovládací prvky poskytují autorům bran užitečné knoflíky pro latenci, relevanci a cenu.

Ovládací prvky dat platformy OpenAI také činí důležitým návrh životního cyklu: zákaznický obsah ve vektorových obchodech je zachován, dokud není smazán. Pokud nájemce odejde nebo vyprší dočasný projekt, brána nemůže předpokládat, že poskytovatel automaticky odstraní indexovaný obsah z obchodního plánu produktu.

Anthropic odhaluje jiný vzor pro citace. Aplikace mohou poskytovat bloky obsahu výsledků vyhledávání s metadaty zdroje a názvu, a když jsou povoleny citace, model může k vygenerovanému textu připojit odkazy na citace. Existují praktická omezení: nastavení citací výsledků vyhledávání je v rámci požadavku vše nebo nic, bloky výsledků vyhledávání podporují textový obsah a granularita citací závisí na tom, jak je obsah rozdělen do bloků.

Důsledek je přímý: brána by neměla odhalit podobu získávání jednoho poskytovatele jako svou veřejnou zakázku, pokud nemá v úmyslu učinit z tohoto poskytovatele trvalou autoritu pro získávání2>Recommendation:Retrieval2ers,

Lock-In

Create an internal retrieval adapter interface. Brána může podporovat několik backendů za ní:

• Načítání nativního poskytovatele: užitečné, když zákazník chce nejrychlejší cestu k funkcím vyhledávání souborů nebo úložiště vektorů jednoho poskytovatele.
• Externí vektorová databáze: užitečné, když produkt musí podporovat mnoho poskytovatelů sestavených modelů s konzistentní izolací tenantů a ovládacími prvky životního cyklu
užitečné bloky vyhledávání při opětovném vyhledáváníPretrie> text a předá jej poskytovateli, který podporuje explicitní citační kontext.

Adaptér by měl vrátit stejnou vnitřní strukturu bez ohledu na backend:

interface RetrievalResult {
  retrievalTraceId: řetězec;
  tenantId: řetězec;
  corpusId: řetězec;
  chunks: Array<{
    sourceId: řetězec;
    název: řetězec;
    text: string;
    urlOrInternalRef?: string;
    chunkId: řetězec;
    ofsety?: { strana?: číslo; byteStart?: číslo; byteEnd?: číslo; tokenStart?: číslo; tokenEnd?: číslo };
    skóre?: číslo;
    metadata: Záznam<řetězec, řetězec | číslo | boolean>;
    providerPayload?: neznámý;
  }>;
  retrievalUsage: {
    poskytovatel: řetězec;
    queryCount: číslo;
    vysledekPocet: cislo;
    billableUnits?: číslo;
  };}

To umožňuje generační vrstvě přijímat kontext, aniž by věděla, zda pochází z vektorových obchodů OpenAI, Pinecone, Weaviate, databázového fulltextového vyhledávacího indexu nebo interního hybridního retrieveru.

Izolace tenantů začíná před vektorovým dotazem

Izolace tenantů nesmí záviset na rychlých pokynech. Musí být vynuceno před načtením, na hranici úložiště a na hranici dotazu.

U systémů typu Pinecone je zdokumentovaný vzor více nájemců jeden jmenný prostor na tenanta v indexech bez serveru. Operace datové roviny se zaměřují na jmenný prostor, což zjednodušuje izolaci tenanta a offboarding, protože odstraněním jmenného prostoru se odstraní záznamy daného tenanta. Pinecone také dokumentuje kompromisy mezi jmennými prostory a filtrováním metadat: filtrování uvnitř velkého sdíleného jmenného prostoru může skenovat více dat, stát více a provádět pomaleji než dotazy s rozsahem jmenných prostorů.

U systémů ve stylu Weaviate ukládá více nájemců každého tenanta na samostatný fragment, takže data jednoho tenanta nejsou viditelná pro jiného tenanta. Smazáním tenanta odstraníte přidružený fragment. Weaviate také podporuje stavy tenantů, jako je aktivní, neaktivní a odložený, což vytváří možnost životního cyklu pro zřídka používané tenanty.

Kontrolní seznam implementace

• Vyřešte tenant_id z ověřené identity brány, nikoli z pole těla dodaného uživatelem.
• Mapujte tenant_id, přes vektorový server názvů nebo jmenný prostor poskytovatele, s. registru.
• Odmítněte požadavky, u kterých se tenant klíče API a požadovaný tenant korpusu neshodují.
• Uchovávejte sdílené veřejné korpusy oddělené od soukromých korpusů tenanta.
• Používejte filtrování metadat pro typ dokumentu, jazyk, oblast produktu nebo časové období poté, co již byla vybrána hranice tenanta.
• Zaznamenat jmenný prostor,corpus_trieprofil,refilid,refilter. retrieval_trace_id pro auditovatelnost.

Vyhrazujte si vyhledávání mezi tenanty pro explicitní administrativní pracovní postupy se samostatnou autorizací, samostatnými indexy nebo řízenými cestami agregace. Nedělejte z vyhledávání mezi nájemci náhodný vedlejší efekt filtrů metadat.

Normalizovat citace jako objekty brány

Citace jsou produktová smlouva, nikoli jen dekorace. Asistent zákaznické podpory, právní nástroj pro navrhování nebo interní znalostní asistent musí ukázat, proč byla vytvořena odpověď a odkud pochází podpůrný text.

Brána by měla normalizovat citační data do vlastního schématu:

{
  "source_id": "doc_123",
  "title": "Podmínky vrácení peněz",
  "url_or_internal_ref": "kb://refund-terms",
  "chunk_id": "chunk_006",
  "offsets": {"page": 2, "byte_start": 4410, "byte_end": 5020},
  "skóre": 0,79,
  "retrieval_provider": "weaviate",
  "model_provider": "antropický",
  "model_provider_citation_payload": {}
}

Uchovávejte normalizovaná pole stabilní a povolte rozšíření specifická pro poskytovatele. Někteří poskytovatelé vystaví bohatší podrobnosti o citacích než jiní. Někteří budou citovat bloky výsledků vyhledávání. Někteří budou citovat nahrané soubory. Některé neposkytnou přesný formát ofsetu, který vaše aplikace požaduje. Brána by měla zachovat to, co existuje, aniž by předstírala, že každý poskytovatel má identickou citační sémantiku.

Přísný režim citace

Když má citation_required hodnotu true, definujte chování při selhání předem. Přísný režim může vyžadovat, aby každý faktický odstavec obsahoval alespoň jednu citaci, nebo aby konečná odpověď obsahovala citace z načtených částí nad minimální hranici skóre. Pokud vybraný modelový poskytovatel nemůže splnit citační smlouvu, brána by měla rychle selhat, použít kompatibilního poskytovatele nebo vrátit strukturované odmítnutí.

Toto je doporučení, nikoli univerzální pravidlo. Režim přísných citací zlepšuje důvěru, ale může zvýšit počet odmítnutí, opakování a složitost řešení. Pro kreativní pracovní postupy s nízkým rizikem mohou být citace volitelné. Pro zákaznickou podporu nebo regulované interní pracovní postupy by citation_required měla být často součástí profilu vyhledávání.

Index Lifecycle is a Product Feature

Systémy RAG shromažďují data. Dočasná nahrávání se náhodou stanou trvalými. Bývalí zákazníci po sobě zanechávají vložené prvky. Produktové týmy mění rozdělovací strategie a zapomínají na obnovu starých indexů.Brána by měla explicitně uvádět ovládací prvky životního cyklu.

Doporučené ovládací prvky životního cyklu zahrnují:

• Dočasné vypršení platnosti korpusu: dokumenty nahrané pro krátkodobou relaci by měly mít časové razítko vypršení platnosti a úlohu mazání.
• Odchod nájemce: související smazáním poskytovatele, název poskytovatele a sdelení vektoru. souborové objekty.
• Cold tenant handling: kde je podporováno, mohou být neaktivní tenanti označeni jako neaktivní nebo přemístěni, aby se snížilo využití prostředků.
• Reindexace správy verzí: uložte model vkládání, zásady chunkingu, verzi analyzátoru a indexed_at pro každý blok.
• Zobrazení dokumentu o vymazání vektoru, zda by mělo fungovat rozhraní API partnera: deletion a odstranění na straně poskytovatele dokončeno.

Důležitým faktem je, že část obsahu vektorového úložiště je zachována, dokud není smazán. Doporučení pro architekturu je zviditelnit a otestovat mazání místo toho, aby bylo pohřbeno v asynchronní úloze bez zákaznického stavu.

Track Three Cost Ledgers

Jedna účetní kniha tokenů pro RAG nestačí. Brána potřebuje alespoň tři účetní knihy:

• Náklady na vkládání a indexování: analýza dokumentů, chunking, volání vkládání, ukládání souborů, zápisy do indexů a přeindexování.
• Cena načítání: čtení vektorové databáze, přehodnocení, přepisování nativních vektorů, přepisování dotazů a rozšiřování vstupních

To je důležité zejména pro agentury, dodavatele SaaS a interní týmy platforem, které přeprodávají nebo alokují náklady na AI. Bez samostatných účetních knih je obtížné vysvětlit marže RAG. Tenant s malou generací využití může být stále drahý, pokud neustále nahrává dokumenty, reindexuje velké korpusy nebo spouští rozsáhlé vyhledávací dotazy.

Každá událost hlavní knihy by měla obsahovat tenant_id, customer_id, pokud se liší, id klíče API, retrieval_profile, corpus_id, model, poskytovatel, trace_id a zúčtovatelné jednotky. Díky tomu může analytika využití zodpovědět praktické otázky: kteří nájemci mají drahé profily vyhledávání, které korpusy jsou zastaralé, které modely způsobují selhání citací a kteří zákazníci generují příliš velké výzvy, protože vyhledávání vrací příliš mnoho kontextu.

Režimy selhání k testování

Subsystém brány RAG by měl mít testy na poškození režimů selháníMulissing:li customer-visibles. citace: citation_required je pravda, ale odpověď poskytovatele neobsahuje žádné použitelné citační odkazy.