RAG multi-inquilí darrere d'una passarel·la d'API compatible amb OpenAI

Els assistents d'IA orientats al client necessiten una generació augmentada per la recuperació, però RAG es fa més difícil quan les sol·licituds flueixen a través d'una passarel·la d'API compatible amb OpenAI en lloc de la pila nativa d'un proveïdor de models. La passarel·la ha de mantenir aïllades les dades dels inquilins, conservar les cites dels proveïdors de models, suprimir el contingut indexat a temps i atribuir els costos d'inserció, recuperació i generació al client adequat.

La resposta pràctica és tractar la recuperació com un subsistema de passarel·la de primera classe. No l'amagueu dins d'una integració de proveïdor. Manteniu la recuperació separada de la generació, doneu a cada sol·licitud un context de recuperació d'abast de l'inquilí, normalitzeu les citacions abans de retornar-les i registreu cada pas facturable en un llibre major.

El problema del lector

Un equip que construeix un assistent d'IA per a molts clients sol començar amb un flux senzill: carregar documents, incrustar fragments, recuperar-los en el model superior i posar-los com a sol·licituds com a coincidències. resposta. Això funciona fins que el producte necessita diversos proveïdors de models, facturació a nivell de client, offboarding i auditabilitat.

El risc no són només les respostes inexactes. Els riscos operatius més grans són els errors de l'espai de noms dels inquilins, les cites no verificables, els índexs obsolets després de la supressió del document i els marges que no es poden explicar perquè els costos de recuperació desapareixen en la despesa genèrica en infraestructura.

Aquest article separa fets, recomanacions i prediccions. Els fets són capacitats d'implementació documentades pel proveïdor actual i les API de bases de dades vectorials. Les recomanacions són opcions d'arquitectura per a un producte de passarel·la. Les prediccions són on és probable que aquesta arquitectura necessiti flexibilitat a mesura que les característiques de recuperació del proveïdor segueixen canviant.

Arquitectura de referència

Un disseny RAG a nivell de passarel·la hauria de tenir cinc components:

• Resolució de llogaters: mapeja la clau de l'API entrant, l'espai de treball, el compte del client o el client de l'API del partner a un client de l'API de socis. perfil: defineix quin corpus s'ha de cercar, quin model d'incrustació s'ha d'utilitzar, recompte de resultats, filtres, opcions de reclassificació, requisits de citació i comportament alternatiu.
• Capa d'adaptador de recuperació: crida a la recuperació del proveïdor natiu, a una base de dades de vectors extern o a un servei de cerca personalitzat a través d'una interfície interna.
• El context escollit
• demana l'adaptador de generació per recuperarel context. proveïdor de models sense exposar els detalls del backend vectorial als qui truca.
• Llibre d'ús i auditoria: registra la incrustació, la indexació, la recuperació, els testimonis d'indicació, els testimonis de finalització, els identificadors de l'inquilí, el model, el proveïdor i el rastreig.

Un contracte de sol·licitud mínima pot romandre neutral pel que fa al proveïdor:

  "tenant_id": "arrendatari_123",
  "model": "model-compatible-gpt-o-claude-compatible",
  "retrieval_profile": "support_docs_v2",
  "citation_required": cert,
  "missatges": [
    {"role": "user", "content": "Quina és la nostra política de reemborsament per als plans anuals?"}
  ]
}

La resposta també ha de ser neutral pel que fa al proveïdor:

{
  "answer": "Els plans anuals es poden reemborsar dins de la finestra de política configurada...",
  "citacions": [
    {
      "source_id": "doc_789",
      "title": "Política de facturació",
      "url_or_internal_ref": "kb://política-de-facturació",
      "chunk_id": "chunk_044",
      "offsets": {"page": 3},
      "puntuació": 0,82,
      "retrieval_provider": "vector_db",
      "model_provider": "openai_compatible",
      "provider_payload": {}
    }
  ],
  "retrieval_trace_id": "rt_456",
  "billable_tenant": "arrendatari_123",
  "embedding_usage": nul,
  "retrieval_usage": {"consultes": 1, "resultats": 6},
  "model_usage": {"input_tokens": 1920, "output_tokens": 180}}

Fet: les funcions de recuperació del proveïdor no són idèntiques

L'API de botigues de vectors d'OpenAI admet magatzems de vectors que es poden crear, cercar, configurar amb estratègies de fragmentació, associar-se amb metadades de fitxers i eliminar-los. La cerca de la botiga de vectors admet consultes, filtres, recomptes màxims de resultats, opcions de classificació, llindars de puntuació i controls de reescriptura de consultes. Aquests controls ofereixen als autors de passarel·les controls útils per a la latència, la rellevància i el cost.

Els controls de dades de la plataforma OpenAI també fan que el disseny del cicle de vida sigui important: el contingut del client a les botigues de vectors es conserva fins que s'elimina. Si un inquilí es retira o si un projecte temporal caduca, la passarel·la no pot assumir que el proveïdor eliminarà automàticament el contingut indexat de la programació comercial del producte.

Anthropic exposa un patró diferent per a les citacions. Les aplicacions poden proporcionar blocs de contingut de resultats de cerca amb metadades d'origen i títol, i quan les cites estan habilitades, el model pot adjuntar referències de cites al text generat. Hi ha limitacions pràctiques: la configuració de la citació dels resultats de la cerca és tot o res dins d'una sol·licitud, els blocs de resultats de la cerca admeten contingut de text i la granularitat de la citació depèn de com es divideix el contingut en blocs.

La implicació és directa: una passarel·la no hauria d'exposar la forma de recuperació d'un proveïdor com a contracte públic tret que tingui la intenció de fer que la recuperació sigui permanent.

• Recuperació de proveïdors natius: útil quan un client vol el camí més ràpid cap a la cerca de fitxers d'un proveïdor o les funcions d'emmagatzematge de vectors.
• Base de dades de vectors externa: útil quan el producte ha d'admetre molts proveïdors de models amb un aïllament coherent d'inquilí i controls de cicle de vida útil quan es bloqueja la cerca >->. la passarel·la reuneix el text recuperat i el passa a un proveïdor que admet un context explícit de cites.

L'adaptador hauria de retornar la mateixa estructura interna independentment del backend:

interfície RetrievalResult {
  retrievalTraceId: cadena;
  tenantId: cadena;
  corpusId: cadena;
  trossos: matriu<{
    sourceId: cadena;
    títol: cadena;
    text: cadena;
    urlOrInternalRef?: cadena;
    chunkId: cadena;
    desplaçaments?: { pàgina?: nombre; byteStart?: nombre; byteEnd?: nombre; tokenStart?: nombre; tokenEnd?: nombre };
    puntuació?: nombre;
    metadades: Registre;
    providerPayload?: desconegut;
  }>;
  recuperacióUsage: {
    proveïdor: cadena;
    queryCount: nombre;
    resultCount: nombre;
    Unitats facturables?: nombre;
  };}

Això permet que la capa de generació rebi context sense saber si prové de botigues de vectors d'OpenAI, Pinecone, Weaviate, un índex de cerca de text complet de base de dades o un recuperador híbrid intern.

L'aïllament de l'inquilí comença abans de la consulta de vectors

L'aïllament de l'inquilí no ha de dependre d'instruccions ràpides. S'ha d'aplicar abans de la recuperació, al límit d'emmagatzematge i al límit de consulta.

Per als sistemes d'estil Pinecone, el patró de multitenència documentat és un espai de noms per inquilí en índexs sense servidor. Les operacions del pla de dades s'orienten a un espai de noms, la qual cosa simplifica l'aïllament i l'exclusió de l'inquilí, ja que la supressió de l'espai de noms elimina els registres d'aquest inquilí. Pinecone també documenta les compensacions entre els espais de noms i el filtratge de metadades: filtrar dins d'un espai de noms compartit gran pot escanejar més dades, costar més i fer més lent que les consultes amb l'àmbit de l'espai de noms.

Per als sistemes d'estil Weaviate, la multitenancy emmagatzema cada inquilí en un fragment independent, de manera que les dades d'un inquilí no són visibles per a un altre inquilí. La supressió del llogater suprimeix el fragment associat. Weaviate també admet estats d'inquilí com ara actiu, inactiu i descarregat, la qual cosa crea una opció de cicle de vida per als inquilins que s'utilitzen rarament.

Llista de comprovació d'implementació

• Resol tenant_id des de la identitat de la passarel·la autenticada, no només des d'un camp de cos subministrat per l'usuari.
• Identificador de l'arrendatari o espai vectorial del mapa, identificador vectorial de l'arrendatari o espai vectorial del mapa. mitjançant un registre del costat del servidor.
• Rebutja les sol·licituds en què l'inquilí de la clau de l'API i l'inquilí del corpus sol·licitat no coincideixin.
• Mantingueu els corpus públics compartits separats dels corpus de l'inquilí privat.
• Utilitzeu el filtratge de metadades per al tipus de document, l'idioma, l'àrea de producte o l'interval de dates després que el límit de l'inquilí ja s'hagi seleccionat,
• corpshard, namespace.
• retrieval_profile i retrieval_trace_id per a la seva auditabilitat.

Reserveu la cerca entre inquilins per a fluxos de treball administratius explícits amb autorització independent, índexs separats o camins d'agregació controlats. No feu que la cerca entre inquilins sigui un efecte secundari accidental dels filtres de metadades.

Normalitzar les cites com a objectes de passarel·la

Les cites són un contracte de producte, no només una decoració. Un assistent d'atenció al client, una eina de redacció legal o un assistent de coneixement intern han de mostrar per què s'ha produït una resposta i d'on prové el text de suport.

La passarel·la hauria de normalitzar les dades de citació en el seu propi esquema:

{
  "source_id": "doc_123",
  "title": "Condicions de reemborsament",
  "url_or_internal_ref": "kb://refund-terms",
  "chunk_id": "chunk_006",
  "offsets": {"page": 2, "byte_start": 4410, "byte_end": 5020},
  "puntuació": 0,79,
  "retrieval_provider": "weaviate",
  "model_provider": "antròpic",
  "model_provider_citation_payload": {}
}

Mantingueu estables els camps normalitzats i permeteu extensions específiques del proveïdor. Alguns proveïdors exposaran detalls de cites més rics que altres. Alguns citaran blocs de resultats de cerca. Alguns citaran els fitxers penjats. Alguns no proporcionaran el format de compensació exacte que vol la vostra aplicació. La passarel·la hauria de preservar el que existeix sense pretendre que tots els proveïdors tinguin una semàntica de citació idèntica.

Mode de citació estricte

Quan citation_required és cert, definiu el comportament d'error per endavant. Un mode estricte pot requerir que cada paràgraf de fets inclogui almenys una citació, o que la resposta final contingui cites de fragments recuperats per sobre d'un llindar de puntuació mínim. Si el proveïdor del model seleccionat no pot satisfer el contracte de citació, la passarel·la hauria de fallar ràpidament, utilitzar un proveïdor compatible o retornar una negativa estructurada.

Aquesta és una recomanació, no una regla universal. El mode de citació estricte millora la confiança, però pot augmentar les denegacions, els reintents i la complexitat de la alternativa. Per als fluxos de treball creatius de baix risc, les cites poden ser opcionals. Per a l'assistència orientada al client o els fluxos de treball interns regulats, citation_required sovint hauria de formar part del perfil de recuperació.

El cicle de vida de l'índex és una característica del producte

Els sistemes RAG acumulen dades. Les càrregues temporals esdevenen permanents per accident. Els antics clients deixen enrere incrustacions. Els equips de producte canvien les estratègies de fragmentació i s'obliden de reconstruir índexs antics.Una passarel·la hauria de fer que els controls del cicle de vida siguin explícits.

Els controls del cicle de vida recomanats inclouen:

• Caducitat temporal del corpus: els documents penjats per a una sessió de curta durada haurien de tenir una marca de temps de caducitat i una feina d'eliminació.
• Força de l'inquilí: s'hauria de suprimir el nom d'un inquilí, proporcionar un espai d'eliminació. magatzems de vectors i objectes de fitxers relacionats.
• Gestió d'inquilí en fred: quan s'admet, els inquilins inactius es poden marcar com a inactius o descarregats per reduir l'ús de recursos.
• Control de versions de reindexació: model d'incrustació de la botiga, política de fragmentació, versió de l'analitzador i indexed_at per a cada fragment de treball:
l'estat de treball del partner:de l'API. mostra si s'han completat la supressió del document, la supressió de vectors i la supressió del costat del proveïdor.

El fet important és que part del contingut de la botiga de vectors es conserva fins que s'elimina. La recomanació de l'arquitectura és fer que la supressió sigui visible i comprovable en lloc d'enterrar-la en una tasca asíncrona sense cap estat orientat al client.

Fer un seguiment de tres llibres de costos

Un únic registre de testimoni no és suficient per a RAG. Una passarel·la necessita com a mínim tres registres:

• Cost d'inserció i indexació: anàlisi de documents, fragmentació, trucades d'inserció, emmagatzematge de fitxers, escriptures d'índexs i reindexació.
• Cost de recuperació: lectures de bases de dades vectorials, cerca, reclassificació, ampliació de resultats de consultes, recerca de magatzems de vectors natius, reclassificació i ampliació de resultats de consultes. cost: fitxes d'entrada dels missatges d'usuari i context recuperat, testimonis de sortida, trucades d'eines, reintents i alternatives.

Això és especialment important per a agències, proveïdors de SaaS i equips de plataformes internes que revenden o assignen costos d'IA. Sense llibres de llibres separats, els marges RAG es tornen difícils d'explicar. Un inquilí amb un ús de generació petita encara pot ser car si penja documents constantment, reindexa corpus grans o executa consultes de recuperació àmplies.

Cada esdeveniment del llibre major hauria d'incloure tenant_id, customer_id si és diferent, identificador de clau API, retrieval_profile, corpus_id, model, provider, trace_id i unitat facturable. Això permet que l'anàlisi d'ús respongui preguntes pràctiques: quins inquilins tenen perfils de recuperació cars, quins corpus són obsolets, quins models produeixen errors de citació i quins clients generen sol·licituds de gran mida perquè la recuperació retorna massa context.

Modes d'error per provar

Un subsistema RAG de passarel·la hauria de tenir proves de modes d'error visibles per al client. dany:

• Falten cites: citation_required és cert, però la resposta del proveïdor no conté referències de cites que es puguin utilitzar.
• Índexs obsolets: s'ha actualitzat o suprimit un document, però els fragments antics encara apareixen als resultats de la recuperació.
• Els noms de l'inquilí o la sol·licitud no coincideixen: pertany a l'arrendatari B.
• Recuperació massa àmplia: el perfil retorna massa fragments, augmentant el cost i diluint la qualitat de la resposta.
• Descoincidència de la mida dels fragments: els fragments són tan grans que les cites són imprecises o tan petites que el context perd el sentit.
• El model pot emetre un altre desajust:
• l'ha de donar forma a un altre model. no pot.
• Error del cicle de vida: es demana la supressió, però l'emmagatzematge del proveïdor continua actiu o no s'ha verificat.

Aquestes proves s'han d'executar a nivell de contracte de passarel·la, no només dins d'un adaptador de proveïdor. L'objectiu és demostrar que el comportament públic es manté estable quan canvia el servidor de recuperació o el proveïdor de generació.

Compartiments

La recuperació del proveïdor natiu pot reduir el codi de l'aplicació i accelerar una primera versió. La compensació és que el cicle de vida d'emmagatzematge, el format de citació, els controls de consultes i la disponibilitat de les funcions poden estar vinculats a un proveïdor.

Les bases de dades vectorials externes afegeixen una superfície operativa. El benefici és una portabilitat més forta entre models compatibles amb OpenAI, models antròpics i proveïdors futurs. També fan que els espais de noms o fragments de l'àmbit dels inquilins siguin més fàcils de raonar sobre quan la passarel·la és responsable de la facturació i l'exclusió.

Els fragments detallats milloren la precisió i l'auditabilitat de les cites. També augmenten la mida de l'índex, el volum de recuperació i la complexitat del muntatge ràpid. Els fragments gruixuts són més senzills, però poden produir cites que apunten a una pàgina o secció àmplia en lloc del passatge de suport exacte.

El mode de citació estricta millora la confiança dels usuaris.També obliga la passarel·la a gestionar els models que no poden produir el format de citació requerit, cosa que pot significar rebutjar la sol·licitud, canviar els models o retornar una resposta amb un estat de confiança més baix.

Predicció: la recuperació serà més nativa, però les passarel·les encara necessiten el seu propi contracte

És probable que les funcions natives del proveïdor siguin més capaces de recuperar. Més models acceptaran context recuperat amb metadades font estructurades. Més API exposaran els controls de classificació, la reescriptura de consultes i la configuració de cites. Això no elimina la necessitat d'un contracte de passarel·la.

La passarel·la encara posseeix la identitat de l'inquilí, la gestió de claus, els límits de despesa, les anàlisis d'ús, els fluxos de treball de l'API de partners i les promeses de supressió orientades al client. Les funcions del proveïdor es poden utilitzar darrere de la capa d'adaptador, però el producte no hauria de forçar tots els inquilins, models i fluxos de treball de facturació a l'abstracció de recuperació d'un proveïdor.

Conclusió accionable

Creeu un RAG multiinquilí com a subsistema de passarel·la amb límits explícits. Resol la identitat de l'inquilí abans de recuperar-la. Utilitzeu espais de noms, fragments o magatzems de vectors amb àmbit d'inquilí. Mantingueu la recuperació darrere dels adaptadors. Normalitzar les cites en un esquema propietat de la passarel·la. Afegiu estats de cicle de vida i verificació de supressió. Feu un seguiment dels costos d'inserció, recuperació i generació per separat.

Aquesta arquitectura manté RAG a terra sense bloquejar el producte a un proveïdor de recuperació. També ofereix als equips els controls operatius que necessiten quan un assistent d'IA passa d'un prototip a un sistema orientat al client: aïllament, citacions, portabilitat, gestió del cicle de vida i atribució de costos.

Lectura relacionada

• recuperació de traces, ús de testimonis i anàlisi d'inquilí en un model d'observabilitat
• normalitzar les sortides específiques del proveïdor darrere d'un contracte de passarel·la estable
• connecteu l'aprovisionament dels inquilins i la mesura de l'ús als fluxos de treball de l'API de partner