Multi-Tenant RAG în spatele unui gateway API compatibil OpenAI

Asistenții AI orientați către clienți au nevoie de generare îmbunătățită de recuperare, dar RAG devine mai greu atunci când solicitările circulă printr-un gateway API compatibil OpenAI în loc de stiva nativă a unui furnizor de model. Gateway-ul trebuie să țină izolate datele chiriașilor, să păstreze citările de la furnizorii de modele, să ștergă conținutul indexat în timp util și să atribuie costurile de încorporare, recuperare și generare clientului potrivit.

Răspunsul practic este de a trata recuperarea ca pe un subsistem gateway de primă clasă. Nu-l ascunde în cadrul integrării unui singur furnizor. Păstrați extragerea separată de generare, acordați fiecărei solicitări un context de recuperare în funcție de locatar, normalizați citările înainte de a le returna și înregistrați fiecare pas facturabil într-un registru.

Problema cititorului

O echipă care construiește un asistent AI pentru mulți clienți începe, de obicei, cu un flux simplu: încărcați documente, încorporați bucăți, preluați acele modele pentru a se potrivi și potriviți în cele mai sus. răspuns. Acest lucru funcționează până când produsul are nevoie de mai mulți furnizori de modele, facturare la nivel de client, offboarding și auditabilitate.

Riscul nu este doar răspunsurile inexacte. Riscurile operaționale mai mari sunt greșelile în spațiul de nume ale chiriașilor, citările neverificabile, indecșii învechiți după ștergerea documentului și marjele care nu pot fi explicate, deoarece costurile de recuperare dispar în cheltuielile generale ale infrastructurii.

Acest articol separă faptele, recomandările și previziunile. Faptele sunt capabilități de implementare documentate de furnizorul actual și API-urile de baze de date vectoriale. Recomandările sunt opțiuni de arhitectură pentru un produs gateway. Predicțiile sunt acolo unde este probabil ca această arhitectură să aibă nevoie de flexibilitate, deoarece caracteristicile de recuperare ale furnizorului se schimbă în continuare.

Arhitectură de referință

Un design RAG la nivel de gateway ar trebui să aibă cinci componente:

• Rezolvarea chiriașilor: mapează cheia API, spațiul de lucru, contul clientului sau clientul API al partenerului la un ID canonic>
• . profil: definește ce corp de căutat, ce model de încorporare să folosească, numărul de rezultate, filtrele, opțiunile de reclasificare, cerințele de citare și comportamentul alternativ.
• Stratul adaptorului de recuperare: apelează la preluarea furnizorului nativ, o bază de date vectorială externă sau un serviciu de căutare personalizat printr-o interfață internă.
• Assemblarea a fost solicitată de adaptor pentru a alege contextuli de generare. furnizor de model fără a expune detaliile vectorului backend-ului apelanților.
• Registrul de utilizare și audit: înregistrează încorporarea, indexarea, preluarea, indicatoarele prompte, indicatoarele de finalizare, identificatorii locatarului, modelului, furnizorului și urmăririi.

Un contract de solicitare minimă poate rămâne neutru față de furnizor:

  "tenant_id": "tenant_123",
  "model": "model-compatibil-gpt-sau-claude-compatibil",
  "retrieval_profile": "support_docs_v2",
  „citation_required”: adevărat,
  „mesaje”: [
    {"role": "user", "content": "Care este politica noastră de rambursare pentru planurile anuale?"}
  ]
}

Răspunsul ar trebui să fie, de asemenea, neutru pentru furnizor:

{
  "answer": "Planurile anuale pot fi rambursate în fereastra de politică configurată...",
  "citări": [
    {
      "source_id": "doc_789",
      "title": "Politica de facturare",
      "url_or_internal_ref": "kb://politica-facturare",
      "chunk_id": "chunk_044",
      "offsets": {"pagina": 3},
      „scor”: 0,82,
      "retrieval_provider": "vector_db",
      "model_provider": "openai_compatible",
      „provider_payload”: {}
    }
  ],
  "retrieval_trace_id": "rt_456",
  "bilable_tenant": "tenant_123",
  „embedding_usage”: nul,
  "retrieval_usage": {"interogări": 1, "rezultate": 6},
  "model_usage": {"input_tokens": 1920, "output_tokens": 180}}

Fapt: Caracteristicile de recuperare a furnizorilor nu sunt identice

API-ul OpenAI Vector Stores acceptă magazine de vectori care pot fi create, căutate, configurate cu strategii de fragmentare, asociate cu metadatele fișierelor și șterse. Căutarea în magazin vector acceptă interogări, filtre, număr maxim de rezultate, opțiuni de clasare, praguri de scor și controale de rescriere a interogărilor. Aceste controale oferă autorilor de gateway-uri butoane utile pentru latență, relevanță și cost.

Controalele de date ale platformei OpenAI fac, de asemenea, importantă proiectarea ciclului de viață: conținutul clienților din magazinele de vectori este păstrat până când este șters. Dacă un chiriaș iese la bord sau dacă un proiect temporar expiră, gateway-ul nu poate presupune că furnizorul va elimina automat conținutul indexat în programul de afaceri al produsului.

Anthropic expune un model diferit pentru citări. Aplicațiile pot furniza blocuri de conținut pentru rezultatele căutării cu metadate sursă și titlu, iar atunci când citările sunt activate, modelul poate atașa referințe de citare textului generat. Există constrângeri practice: setările de citare a rezultatelor căutării sunt totul sau nimic într-o solicitare, blocurile de rezultate ale căutării acceptă conținut text, iar granularitatea citațiilor depinde de modul în care conținutul este împărțit în blocuri.

Implicația este directă: un gateway nu ar trebui să expună forma de recuperare a unui furnizor ca contract public decât dacă intenționează să ofere autoritatea permanentă.

Recomandări. Utilizați adaptoare de recuperare, nu blocare de recuperare

Creați o interfață de adaptor de recuperare internă. Gateway-ul poate accepta mai multe backend-uri în spatele acestuia:

• Recuperarea furnizorului nativ: util atunci când un client dorește calea cea mai rapidă către funcțiile de căutare de fișiere sau de stocare vectorială ale unui furnizor.
• Bază de date vectorială externă: utilă atunci când produsul trebuie să accepte mulți furnizori de modele cu izolare consecventă a chiriașilor și controale ale ciclului de viață util
• utilă atunci când se blochează ciclul de viață. gateway-ul adună textul preluat și îl transmite unui furnizor care acceptă context explicit care ține cont de citarea.

Adaptorul ar trebui să returneze aceeași structură internă, indiferent de backend:

interfață RetrievalResult {
  retrievalTraceId: șir;
  tenantId: șir;
  corpusId: șir;
  bucăți: matrice<{
    sourceId: șir;
    titlu: șir;
    text: șir;
    urlOrInternalRef?: șir;
    chunkId: șir;
    decalaje?: { pagina?: număr; byteStart?: număr; byteEnd?: număr; tokenStart?: număr; tokenEnd?: număr };
    scor?: număr;
    metadate: Înregistrare<șir, șir | număr | boolean>;
    providerPayload?: necunoscut;
  }>;
  recuperareUtilizare: {
    furnizor: șir;
    queryCount: număr;
    resultCount: număr;
    Unități facturabile?: număr;
  };}

Acest lucru permite stratului de generare să primească context fără să știe dacă provine din magazinele de vectori OpenAI, Pinecone, Weaviate, un index de căutare full-text în baza de date sau un retriever hibrid intern.

Izolarea chiriașului începe înainte de interogarea vectorului

Izolarea chiriașului nu trebuie să depindă de instrucțiuni prompte. Trebuie să fie aplicat înainte de recuperare, la limita de stocare și la granița interogării.

Pentru sistemele în stil Pinecone, modelul documentat de închiriere multiplă este un spațiu de nume pentru fiecare locatar în indecșii fără server. Operațiunile din planul de date vizează un spațiu de nume, ceea ce simplifică izolarea locatarilor și deconectarea, deoarece ștergerea spațiului de nume elimină înregistrările locatarului respectiv. Pinecone documentează, de asemenea, compromisurile între spațiile de nume și filtrarea metadatelor: filtrarea în interiorul unui spațiu de nume partajat mare poate scana mai multe date, poate costa mai mult și poate performa mai lent decât interogările cu spațiu de nume.

Pentru sistemele în stil Weaviate, multi-chiriaș stochează fiecare chiriaș pe un fragment separat, astfel încât datele unui chiriaș nu sunt vizibile pentru alt chiriaș. Ștergerea locatarului șterge fragmentul asociat. Weaviate acceptă, de asemenea, stări de chiriaș, cum ar fi activ, inactiv și descărcat, ceea ce creează o opțiune de ciclu de viață pentru chiriașii utilizați rar.

Lista de verificare a implementării

• Rezolvați tenant_id din identitatea gateway-ului autentificat, nu doar dintr-un câmp de corp furnizat de utilizator.
• Hartă de nume vector de locatar sau de spațiu de stocare, furnizor de vector_id. printr-un registru de pe partea serverului.
• Respingeți cererile în care chiriașul cheii API și chiriașul de corpus solicitat nu se potrivesc.
• Păstrați corpus public partajat separat de corpus chiriașii privat.
• Utilizați filtrarea metadatelor pentru tipul documentului, limbă, zona de produs sau intervalul de date după ce limita locatarului a fost deja selectată.
• corpshard, namespace.
• retrieval_profile și retrieval_trace_id pentru auditabilitate.

Rezervați căutarea între locatari pentru fluxuri de lucru administrative explicite cu autorizare separată, indici separati sau căi de agregare controlate. Nu transformați căutarea între locatari un efect secundar accidental al filtrelor de metadate.

Normalizarea citațiilor ca obiecte Gateway

Citările sunt un contract de produs, nu doar un decor. Un asistent de asistență pentru clienți, un instrument de redactare juridică sau un asistent intern de cunoștințe trebuie să arate de ce a fost produs un răspuns și de unde provine textul suport.

Poarta de acces ar trebui să normalizeze datele de citare în propria sa schemă:

{
  "source_id": "doc_123",
  "title": "Condiții de rambursare",
  "url_or_internal_ref": "kb://refund-terms",
  "chunk_id": "chunk_006",
  "offsets": {"page": 2, "byte_start": 4410, "byte_end": 5020},
  „scor”: 0,79,
  "retrieval_provider": "weaviate",
  "model_provider": "antropic",
  „model_provider_citation_payload”: {}
}

Păstrați câmpurile normalizate stabile și permiteți extensii specifice furnizorului. Unii furnizori vor expune detalii de citare mai bogate decât alții. Unii vor cita blocuri cu rezultatele căutării. Unii vor cita fișiere încărcate. Unele nu vor furniza formatul exact de offset pe care îl dorește aplicația dvs. Gateway-ul ar trebui să păstreze ceea ce există fără a pretinde că fiecare furnizor are o semantică de citare identică.

Modul de citare strict

Când citation_required este adevărat, definiți comportamentul de eșec din față. Un mod strict poate cere ca fiecare paragraf de fapt să includă cel puțin o citare sau ca răspunsul final să conțină citate din fragmente preluate peste un prag minim de punctaj. Dacă furnizorul de model selectat nu poate îndeplini contractul de citare, gateway-ul ar trebui să eșueze rapid, să folosească un furnizor compatibil sau să returneze un refuz structurat.

Aceasta este o recomandare, nu o regulă universală. Modul strict de citare îmbunătățește încrederea, dar poate crește refuzurile, reîncercările și complexitatea de rezervă. Pentru fluxurile de lucru creative cu risc scăzut, citările pot fi opționale. Pentru asistență orientată către clienți sau fluxuri de lucru interne reglementate, citation_required ar trebui să facă deseori parte din profilul de recuperare.

Index Lifecycle Is a Product Feature

Sistemele RAG acumulează date. Încărcările temporare devin permanente din întâmplare. Foștii clienți lasă în urmă încorporații. Echipele de produse schimbă strategiile de fragmentare și uită să reconstruiască vechi indici.Un gateway ar trebui să explice controalele ciclului de viață.

Controalele ciclului de viață recomandate includ:

• Expirarea temporară a corpus: documentele încărcate pentru o sesiune de scurtă durată ar trebui să aibă un marcaj de timp de expirare și o sarcină de ștergere.
• Deconectarea chiriașului: ar trebui să ștergeți un nume de uhard, să furnizeze locatarii depozite vectoriale și obiecte de fișiere aferente.
• Gestionarea la rece a chiriașilor: acolo unde este acceptată, locatarii inactivi pot fi marcați ca inactivi sau descarcați pentru a reduce utilizarea resurselor.
• Reindexarea controlului versiunii: modelul de încorporare a stocării, politica de fragmentare, versiunea parserului și indexed_at pentru fiecare bucată de expunere a partenerului:
• arată dacă ștergerea documentului, ștergerea vectorului și ștergerea de partea furnizorului au fost finalizate.

Faptul important este că o parte din conținutul magazinului de vectori este păstrat până la ștergere. Recomandarea arhitecturii este de a face ștergerea vizibilă și testabilă, în loc să o îngropați într-o lucrare asincronă, fără o stare orientată către client.

Urmăriți trei registre de cost

Un singur registru cu simboluri nu este suficient pentru RAG. Un gateway are nevoie de cel puțin trei registre:

• Costul de încorporare și indexare: analizarea documentelor, fragmentarea, apelurile încorporate, stocarea fișierelor, scrierile de index și reindexarea.
• Costul de regăsire: citiri de baze de date vectoriale, căutare nativă în magazinul de vectori, reclasificare, extindere a rezultatelor
riririri. cost: jetoane de intrare din mesajele utilizatorului și contextul preluat, jetoane de ieșire, apeluri de instrumente, reîncercări și alternative.

Acest lucru este important în special pentru agenții, furnizorii SaaS și echipele interne ale platformei care revind sau alocă costuri AI. Fără registre separate, marjele RAG devin greu de explicat. Un chiriaș cu o generație mică de utilizare poate fi în continuare costisitor dacă încarcă în mod constant documente, reindexează corpuri mari sau execută interogări ample de recuperare.

Fiecare eveniment registru ar trebui să includă tenant_id, customer_id dacă este diferit, ID-ul cheii API, retrieval_profile, corpus_id, model, provider, trace_id și facturable unit. Acest lucru permite analizei de utilizare să răspundă la întrebări practice: ce chiriași au profiluri de recuperare scumpe, care corpuri sunt învechite, ce modele produc erori de citare și care clienți generează solicitări supradimensionate, deoarece recuperarea returnează prea mult context.

Moduri de eșec de testat

Un subsistem RAG gateway ar trebui să creeze moduri de eșec vizibile pentru client. deteriorare:

• Citate lipsă: citation_required este adevărată, dar răspunsul furnizorului nu conține referințe de citare utilizabile.
• Indexuri învechite: un document a fost actualizat sau șters, dar bucăți vechi apar în continuare în rezultatele extragerii.
• În timp ce solicitarea chiriașului se rezolvă nepotrivirea numelui sau a spațiului: aparține chiriașului B.
• Recuperare prea amplă: profilul returnează prea multe bucăți, crescând costul și diluând calitatea răspunsului.
• Nepotrivire dimensiunea bucăților: bucățile sunt atât de mari încât citatele sunt imprecise sau atât de mici încât contextul își pierde sensul.
• Formarea unui model poate fi necesară:
• Formarea unui model poate fi necesară:
• > nu pot.
• Eșec ciclului de viață: se solicită ștergerea, dar stocarea la nivelul furnizorului rămâne activă sau neverificată.

Aceste teste ar trebui să se desfășoare la nivelul contractului de gateway, nu numai în interiorul unui adaptor de furnizor. Scopul este de a demonstra că comportamentul public rămâne stabil atunci când backend-ul de recuperare sau furnizorul de generație se schimbă.

Compartimente

Recuperarea furnizorului nativ poate reduce codul aplicației și poate accelera o primă versiune. Compensația este că ciclul de viață al stocării, formatul de citare, controalele de interogare și disponibilitatea caracteristicilor pot deveni legate de un singur furnizor.

Bazele de date vectoriale externe adaugă suprafață operațională. Avantajul este o portabilitate mai puternică între modelele compatibile cu OpenAI, modelele antropice și viitorii furnizori. De asemenea, facilitează raționarea spațiilor de nume sau shard-urilor la nivelul locatarului când gateway-ul este responsabil pentru facturare și offboarding.

Bucățile cu granulație fină îmbunătățesc precizia citărilor și auditabilitatea. De asemenea, cresc dimensiunea indexului, volumul de recuperare și complexitatea asamblarii prompte. Bucățile grosiere sunt mai simple, dar pot produce citații care indică o pagină sau o secțiune amplă, mai degrabă decât pasajul de sprijin exact.

Modul strict necesar pentru citarea îmbunătățește încrederea utilizatorilor.De asemenea, forțează gateway-ul să se ocupe de modele care nu pot produce formatul de citare necesar, ceea ce poate însemna refuzul cererii, schimbarea modelelor sau returnarea unui răspuns cu o stare de încredere mai scăzută.

Predicție: Recuperarea va deveni mai nativă, dar gateway-urile încă au nevoie de propriul contract

Este probabil ca caracteristicile furnizorului să devină mai capabile de regăsire native. Mai multe modele vor accepta contextul preluat cu metadate surse structurate. Mai multe API-uri vor expune controalele de clasare, rescrierea interogărilor și setările de citare. Acest lucru nu înlătură necesitatea unui contract de gateway.

Gateway-ul deține în continuare identitatea chiriașului, managementul cheilor, limitele de cheltuieli, analizele de utilizare, fluxurile de lucru API Partner și promisiunile de ștergere adresate clienților. Funcțiile furnizorului pot fi utilizate în spatele stratului adaptor, dar produsul nu ar trebui să forțeze fiecare locatar, model și flux de lucru de facturare să intre în abstracția de recuperare a unui singur furnizor.

Concluzie acționabilă

Construiți RAG multi-locatari ca subsistem gateway cu limite explicite. Rezolvați identitatea chiriașului înainte de recuperare. Utilizați spații de nume, fragmente sau depozite de vectori în funcție de chiriași. Păstrați recuperarea în spatele adaptoarelor. Normalizați citările într-o schemă deținută de gateway. Adăugați stări ciclului de viață și verificarea ștergerii. Urmăriți separat costurile de încorporare, recuperare și generare.

Această arhitectură menține RAG la pământ fără a bloca produsul la un singur furnizor de recuperare. De asemenea, oferă echipelor controalele operaționale de care au nevoie atunci când un asistent AI trece de la un prototip la un sistem orientat către clienți: izolarea, citarea, portabilitatea, managementul ciclului de viață și atribuirea costurilor.

Lectură similară

• recuperarea urmelor, utilizarea simbolurilor și analiza locatarului într-un singur model de observabilitate
• normalizați ieșirile specifice furnizorului în spatele unui contract de gateway stabil
• conectați furnizarea chiriașilor și contorizarea utilizării la fluxurile de lucru API Partner