RAG multi-tenant derrière une passerelle API compatible OpenAI

Les assistants IA destinés aux clients ont besoin d'une génération augmentée par récupération, mais RAG devient plus difficile lorsque les demandes transitent par une passerelle API compatible OpenAI au lieu de la pile native d'un fournisseur de modèles. La passerelle doit conserver les données des locataires isolées, conserver les citations entre les fournisseurs de modèles, supprimer le contenu indexé dans les délais et attribuer les coûts d'intégration, de récupération et de génération au bon client.

La réponse pratique consiste à traiter la récupération comme un sous-système de passerelle de première classe. Ne le cachez pas dans l’intégration d’un seul fournisseur. Séparez la récupération de la génération, attribuez à chaque demande un contexte de récupération adapté au locataire, normalisez les citations avant de les renvoyer et enregistrez chaque étape facturable dans un grand livre.

Le problème du lecteur

Une équipe qui crée un assistant IA pour de nombreux clients commence généralement par un flux simple : télécharger des documents, intégrer des morceaux, récupérer les principales correspondances, placer ces extraits dans l'invite et demander à un modèle de répondre. Cela fonctionne jusqu'à ce que le produit ait besoin de plusieurs fournisseurs de modèles, d'une facturation au niveau client, d'une exclusion et d'une auditabilité.

Le risque ne réside pas seulement dans des réponses inexactes. Les risques opérationnels les plus importants sont les erreurs d'espace de noms des locataires, les citations invérifiables, les index obsolètes après la suppression de documents et les marges qui ne peuvent pas être expliquées car les coûts de récupération disparaissent dans les dépenses d'infrastructure génériques.

Cet article sépare les faits, les recommandations et les prédictions. Les faits sont des capacités de mise en œuvre documentées par les API actuelles des fournisseurs et des bases de données vectorielles. Les recommandations sont des choix d'architecture pour un produit de passerelle. Les prédictions sont là où cette architecture aura probablement besoin de flexibilité à mesure que les fonctionnalités de récupération des fournisseurs continuent de changer.

Architecture de référence

Une conception RAG au niveau de la passerelle doit comporter cinq composants :

• Résolveur de locataire : mappe la clé API entrante, l'espace de travail, le compte client ou le client API partenaire à un identifiant de locataire canonique.
• Profil de récupération : définit le corpus à rechercher, lequel modèle d'intégration à utiliser, nombre de résultats, filtres, options de reclassement, exigences de citation et comportement de secours.
• Couche d'adaptateur de récupération : appelle la récupération du fournisseur natif, une base de données vectorielle externe ou un service de recherche personnalisé via une interface interne.
• Adaptateur d'assemblage et de génération d'invites : transmet le contexte récupéré au fournisseur de modèle choisi sans exposer les détails du backend vectoriel aux appelants.
• Utilisation et audit grand livre : enregistre l'intégration, l'indexation, la récupération, les jetons d'invite, les jetons d'achèvement, les identifiants de locataire, de modèle, de fournisseur et de trace.

Un contrat de requête minimal peut rester neutre à l'égard du fournisseur :

{
  "tenant_id": "tenant_123",
  "model": "modèle-compatible-gpt-ou-compatible-claude",
  "retrieval_profile": "support_docs_v2",
  "citation_required": vrai,
  "messages": [
    {"role": "user", "content": "Quelle est notre politique de remboursement pour les forfaits annuels ?"}
  ]

La réponse doit également être indépendante du fournisseur :

{
  "answer": "Les forfaits annuels peuvent être remboursés dans la fenêtre de politique configurée...",
  "citations": [
    {
      "source_id": "doc_789",
      "title": "Politique de facturation",
      "url_or_internal_ref": "kb://billing-policy",
      "chunk_id": "chunk_044",
      "offsets": {"page": 3},
      "score": 0,82,
      "retrieval_provider": "vecteur_db",
      "model_provider": "openai_compatible",
      "provider_payload": {}
    }
  ],
  "retrieval_trace_id": "rt_456",
  "billable_tenant": "tenant_123",
  "embedding_usage": nul,
  "retrieval_usage": {"queries": 1, "results": 6},
  "model_usage": {"input_tokens": 1920, "output_tokens": 180}

Fait : les fonctionnalités de récupération des fournisseurs ne sont pas identiques

L'API Vector Stores d'OpenAI prend en charge les magasins de vecteurs qui peuvent être créés, recherchés, configurés avec des stratégies de segmentation, associés aux métadonnées de fichiers et supprimés. La recherche dans le magasin de vecteurs prend en charge les requêtes, les filtres, le nombre maximum de résultats, les options de classement, les seuils de score et les contrôles de réécriture des requêtes. Ces contrôles donnent aux auteurs de passerelles des indicateurs utiles en matière de latence, de pertinence et de coût.

Les contrôles de données de la plateforme OpenAI rendent également la conception du cycle de vie importante : le contenu client dans les magasins vectoriels est conservé jusqu'à sa suppression. Si un locataire se retire ou si un projet temporaire expire, la passerelle ne peut pas supposer que le fournisseur supprimera automatiquement le contenu indexé selon le calendrier commercial du produit.

Anthropic expose un modèle différent pour les citations. Les applications peuvent fournir des blocs de contenu de résultats de recherche avec des métadonnées de source et de titre, et lorsque les citations sont activées, le modèle peut attacher des références de citation au texte généré. Il existe des contraintes pratiques : les paramètres de citation des résultats de recherche sont tout ou rien dans une requête, les blocs de résultats de recherche prennent en charge le contenu textuel et la granularité des citations dépend de la façon dont le contenu est divisé en blocs.

L'implication est directe : une passerelle ne doit pas exposer la forme de récupération d'un fournisseur comme son contrat public, à moins qu'elle n'ait l'intention de faire de ce fournisseur l'autorité de récupération permanente.

Recommandation : utilisez des adaptateurs de récupération, pas la récupération. Lock-In

Créez une interface d'adaptateur de récupération interne. La passerelle peut prendre en charge plusieurs backends :

• Récupération de fournisseur natif : utile lorsqu'un client souhaite accéder au chemin le plus rapide vers les fonctionnalités de recherche de fichiers ou de stockage de vecteurs d'un fournisseur.
• Base de données vectorielles externe : utile lorsque le produit doit prendre en charge de nombreux fournisseurs de modèles avec une isolation cohérente des locataires et des contrôles de cycle de vie.
• Blocs de résultats de recherche pré-extraits : utiles lorsque la passerelle rassemble le texte récupéré et le transmet à un fournisseur qui prend en charge le contexte explicite prenant en compte les citations.

L'adaptateur doit renvoyer la même structure interne quel que soit le backend :

interface RetrievalResult {
  récupérationTraceId : chaîne ;
  locataireId : chaîne ;
  corpusId : chaîne ;
  morceaux : Array<{
    ID source : chaîne ;
    titre : chaîne ;
    texte : chaîne ;
    urlOrInternalRef?: chaîne ;
    chunkId : chaîne ;
    décalages ? : { page ? : numéro ; byteStart?: nombre; byteEnd?: nombre; tokenStart? : numéro ; tokenEnd?: numéro };
    score ? : nombre ;
    métadonnées : Record ;
    fournisseurPayload ? : inconnu ;
  }> ;
  utilisation de récupération : {
    fournisseur : chaîne ;
    queryCount : nombre ;
    resultCount : nombre ;
    billableUnits? : nombre ;
  } ;

Cela permet à la couche de génération de recevoir du contexte sans savoir s'il provient de magasins de vecteurs OpenAI, Pinecone, Weaviate, d'un index de recherche en texte intégral de base de données ou d'un récupérateur hybride interne.

L'isolement des locataires commence avant la requête vectorielle

L'isolement des locataires ne doit pas dépendre d'instructions rapides. Il doit être appliqué avant la récupération, au niveau des limites de stockage et des limites de requête.

Pour les systèmes de style Pinecone, le modèle de multilocation documenté est un espace de noms par locataire dans les index sans serveur. Les opérations du plan de données ciblent un espace de noms, ce qui simplifie l'isolation et la désintégration du locataire, car la suppression de l'espace de noms supprime les enregistrements de ce locataire. Pinecone documente également les compromis entre les espaces de noms et le filtrage des métadonnées : le filtrage au sein d'un grand espace de noms partagé peut analyser plus de données, coûter plus cher et s'exécuter plus lentement que les requêtes portant sur l'espace de noms.

Pour les systèmes de style Weaviate, la multilocation stocke chaque locataire sur une partition distincte, de sorte que les données d'un locataire ne sont pas visibles par un autre locataire. La suppression du locataire supprime la partition associée. Weaviate prend également en charge les états de locataire tels que actif, inactif et déchargé, ce qui crée une option de cycle de vie pour les locataires rarement utilisés.

Liste de contrôle de mise en œuvre

• Résolvez tenant_id à partir de l'identité de la passerelle authentifiée, et non à partir d'un seul champ de corps fourni par l'utilisateur.
• Mappez tenant_id à un espace de noms vectoriel, une partition ou un identifiant de magasin de vecteurs de fournisseur via un registre côté serveur.
• Rejetez les demandes où le locataire de clé API et le locataire de corpus demandé ne correspondent pas.
• Gardez les corpus publics partagés séparés des corpus de locataires privés.
• Utilisez le filtrage des métadonnées pour le type de document, la langue, le domaine de produit ou la plage de dates une fois que la limite du locataire a déjà été sélectionnée.
• Espace de noms de journal, fragment, corpus_id, retrieval_profile et retrieval_trace_id pour l'auditabilité.

Réservez la recherche entre locataires pour workflows administratifs explicites avec autorisation distincte, index distincts ou chemins d'agrégation contrôlés. Ne faites pas de la recherche entre locataires un effet secondaire accidentel des filtres de métadonnées.

Normaliser les citations en tant qu'objets de passerelle

Les citations sont un contrat de produit, pas seulement une décoration. Un assistant d'assistance client, un outil de rédaction juridique ou un assistant de connaissances interne doit montrer pourquoi une réponse a été produite et d'où vient le texte à l'appui.

La passerelle doit normaliser les données de citation dans son propre schéma :

{
  "source_id": "doc_123",
  "title": "Conditions de remboursement",
  "url_or_internal_ref": "kb://conditions-de-remboursement",
  "chunk_id": "chunk_006",
  "offsets": {"page": 2, "byte_start": 4410, "byte_end": 5020},
  "score": 0,79,
  "retrieval_provider": "weaviate",
  "model_provider": "anthropique",
  "model_provider_citation_payload": {}

Gardez les champs normalisés stables et autorisez les extensions spécifiques au fournisseur. Certains fournisseurs exposent des détails de citation plus riches que d’autres. Certains citeront des blocs de résultats de recherche. Certains citeront les fichiers téléchargés. Certains ne fourniront pas le format de décalage exact souhaité par votre application. La passerelle doit préserver ce qui existe sans prétendre que chaque fournisseur a une sémantique de citation identique.

Mode de citation stricte

Lorsque citation_required est vrai, définissez dès le départ le comportement d'échec. Un mode strict peut exiger que chaque paragraphe factuel comprenne au moins une citation, ou que la réponse finale contienne des citations de morceaux récupérés au-dessus d'un seuil de score minimum. Si le fournisseur modèle sélectionné ne peut pas satisfaire au contrat de citation, la passerelle doit échouer rapidement, utiliser un fournisseur compatible ou renvoyer un refus structuré.

Il s'agit d'une recommandation, pas d'une règle universelle. Le mode de citation stricte améliore la confiance, mais il peut augmenter les refus, les tentatives et la complexité des solutions de secours. Pour les flux de travail créatifs à faible risque, les citations peuvent être facultatives. Pour le support client ou les flux de travail internes réglementés, citation_required doit souvent faire partie du profil de récupération.

Le cycle de vie de l'index est une fonctionnalité du produit

Les systèmes RAG accumulent des données. Les téléchargements temporaires deviennent permanents par accident. Les anciens clients laissent derrière eux des intégrations. Les équipes produit changent de stratégie de segmentation et oublient de reconstruire les anciens index.Une passerelle doit rendre les contrôles de cycle de vie explicites.

Les contrôles de cycle de vie recommandés incluent :

• Expiration temporaire du corpus : les documents téléchargés pour une session de courte durée doivent avoir un horodatage d'expiration et une tâche de suppression.
• Départ du locataire : la suppression d'un locataire doit entraîner la suppression des espaces de noms, des fragments, des magasins de vecteurs du fournisseur et des fichiers associés. objets.
• Gestion des locataires à froid : lorsqu'ils sont pris en charge, les locataires inactifs peuvent être marqués comme inactifs ou déchargés pour réduire l'utilisation des ressources.
• Contrôle de version de réindexation : stocke le modèle d'intégration, la politique de segmentation, la version de l'analyseur et indexed_at pour chaque fragment.
• Exposition de l'état de suppression : les workflows de l'API partenaire doivent indiquer si la suppression de documents, la suppression de vecteurs et la suppression côté fournisseur terminé.

Le fait important est que certains contenus du magasin de vecteurs sont conservés jusqu'à leur suppression. La recommandation en matière d'architecture est de rendre la suppression visible et testable au lieu de l'enterrer dans une tâche asynchrone sans état face au client.

Suivez trois registres de coûts

Un seul registre de jetons n'est pas suffisant pour RAG. Une passerelle a besoin d'au moins trois registres :

• Coût d'intégration et d'indexation : analyse de documents, segmentation, intégration d'appels, stockage de fichiers, écritures d'index et réindexation.
• Coût de récupération : lectures de bases de données vectorielles, recherche de magasins de vecteurs natifs, reclassement, réécriture de requêtes et expansion des résultats.
• Coût de génération : jetons d'entrée à partir des messages utilisateur et du contexte récupéré, jetons de sortie, appels d'outils, tentatives et solutions de secours.

Ceci est particulièrement important pour les agences, les fournisseurs SaaS et les équipes de plate-forme internes qui revendent ou répartissent les coûts de l'IA. Sans registres séparés, les marges RAG deviennent difficiles à expliquer. Un locataire avec une utilisation de petite génération peut toujours être coûteux s'il télécharge constamment des documents, réindexe de grands corpus ou exécute des requêtes de récupération larges.

Chaque événement du grand livre doit inclure tenant_id, customer_id s'il est différent, l'ID de clé API, retrieval_profile, corpus_id, modèle, fournisseur, trace_id et les unités facturables. Cela permet aux analyses d'utilisation de répondre à des questions pratiques : quels locataires ont des profils de récupération coûteux, quels corpus sont obsolètes, quels modèles produisent des échecs de citation et quels clients génèrent des invites surdimensionnées parce que la récupération renvoie trop de contexte.

Modes d'échec à tester

Un sous-système RAG de passerelle doit avoir des tests pour les modes d'échec qui créent des dommages visibles par le client :

• Citations manquantes : citation_required est vrai, mais la réponse du fournisseur ne contient aucune référence de citation utilisable.
• Index obsolètes : un document a été mis à jour ou supprimé, mais d'anciens morceaux apparaissent toujours dans les résultats de récupération.
• Incompatibilité de locataires : la requête est résolue sur le locataire A, tandis que le corpus ou l'espace de noms appartient au locataire B.
• Récupération trop large : le profil renvoie trop de morceaux, augmentant le coût et diluant la réponse qualité.
• Inadéquation de la taille des fragments : les fragments sont si grands que les citations sont imprécises, ou si petits que le contexte perd son sens.
• Inadéquation des fonctionnalités du fournisseur : un modèle peut émettre des citations dans la forme requise alors qu'un autre ne le peut pas.
• Échec du cycle de vie : la suppression est demandée mais le stockage côté fournisseur reste actif ou non vérifié.

Ces tests doivent être exécutés au niveau de la qualité. au niveau du contrat de passerelle, et pas seulement à l'intérieur d'un adaptateur de fournisseur. L'objectif est de prouver que le comportement public reste stable lorsque le backend de récupération ou le fournisseur de génération change.

Compromis

La récupération par le fournisseur natif peut réduire le code de l'application et accélérer une première version. Le compromis est que le cycle de vie du stockage, le format de citation, les contrôles de requête et la disponibilité des fonctionnalités peuvent être liés à un seul fournisseur.

Les bases de données vectorielles externes ajoutent une surface opérationnelle. L’avantage est une portabilité plus forte entre les modèles compatibles OpenAI, les modèles Anthropic et les futurs fournisseurs. Ils facilitent également le raisonnement des espaces de noms ou des partitions à l'échelle du locataire lorsque la passerelle est responsable de la facturation et de la désintégration.

Les fragments à granularité fine améliorent la précision et l'auditabilité des citations. Ils augmentent également la taille de l'index, le volume de récupération et la complexité de l'assemblage rapide. Les gros morceaux sont plus simples, mais ils peuvent produire des citations qui pointent vers une page ou une section large plutôt que vers le passage exact à l'appui.

Le mode de citation stricte requis améliore la confiance des utilisateurs.Cela oblige également la passerelle à gérer des modèles qui ne peuvent pas produire le format de citation requis, ce qui peut impliquer de refuser la demande, de modifier le modèle ou de renvoyer une réponse avec un état de confiance inférieur.

Prédiction : la récupération deviendra plus native, mais les passerelles auront toujours besoin de leur propre contrat

Les fonctionnalités de récupération natives du fournisseur deviendront probablement plus performantes. Un plus grand nombre de modèles accepteront le contexte récupéré avec des métadonnées sources structurées. Davantage d'API exposeront les contrôles de classement, la réécriture des requêtes et les paramètres de citation. Cela ne supprime pas le besoin d'un contrat de passerelle.

La passerelle possède toujours l'identité du locataire, la gestion des clés, les limites de dépenses, les analyses d'utilisation, les flux de travail des API partenaires et les promesses de suppression destinées aux clients. Les fonctionnalités du fournisseur peuvent être utilisées derrière la couche d'adaptateur, mais le produit ne doit pas forcer chaque locataire, modèle et flux de facturation à passer par l'abstraction de récupération d'un fournisseur.

Conclusion exploitable

Créez un RAG multi-tenant en tant que sous-système de passerelle avec des limites explicites. Résolvez l’identité du locataire avant la récupération. Utilisez des espaces de noms, des fragments ou des magasins de vecteurs à l'échelle du locataire. Gardez la récupération derrière les adaptateurs. Normalisez les citations dans un schéma appartenant à la passerelle. Ajoutez des états de cycle de vie et une vérification de suppression. Suivez les coûts d'intégration, de récupération et de génération séparément.

Cette architecture maintient RAG ancré sans verrouiller le produit sur un seul fournisseur de récupération. Il donne également aux équipes les contrôles opérationnels dont elles ont besoin lorsqu'un assistant IA passe d'un prototype à un système orienté client : isolation, citations, portabilité, gestion du cycle de vie et attribution des coûts.

Lecture connexe

• récupération de traces, utilisation des jetons et analyse des locataires dans un seul modèle d'observabilité
• normaliser les sorties spécifiques au fournisseur derrière un contrat de passerelle stable
• connecter le provisionnement des locataires et la mesure de l'utilisation aux flux de travail de l'API partenaire