Garantir l’exactitude d’un stockage vectoriel : cycle de vie, gestion par locataires, métadonnées, recherche hybride.

Un technicien de terrain demande à un assistant de support interne comment remplacer une pompe hydraulique. La réponse semble correcte : famille d’équipements adéquate, type de pompe approprié, série de démarches logique. Cependant, elle date de six mois. La notice actuelle exige une mise à jour du firmware avant l’installation de la pompe, tandis que l’ancienne ne mentionne jamais cela. Les deux notices se trouvent dans le stockage vectoriel. La nouvelle a été correctement indexée, mais personne n’a jamais supprimé l’ancienne. Le modèle n’a inventé rien ; on lui a simplement fourni des informations obsolètes.

Des questions de ce type permettent de déterminer si un système de recherche est fiable.

• Quelle version d’un document peut être récupérée actuellement ?
• Quel délai s’écoule après l’approbation avant qu’une mise à jour ne devienne recherchable ?
• Un client peut-il jamais voir le contenu d’un autre client ?
• Que se passe-t-il lorsque l’utilisateur cherche un numéro de pièce exact plutôt qu’une idée générale ?

Quels champs de métadonnées doivent exister avant qu’un morceau de données ne puisse être intégré au corpus recherchable ?

Rien de tout cela ne concerne la qualité du modèle. Il s’agit plutôt du fonctionnement quotidien d’un stockage vectoriel.

Une configuration concrète : support technique multi-locataire

Imaginons une plateforme de support utilisée par des revendeurs d’équipements dans plusieurs pays. Elle contient des manuels de produits, des bulletins de réparation, des catalogues de pièces, des politiques de garantie, des procédures de maintenance ainsi que des notes écrites par chaque revendeur. Un technicien pourrait demander quelle procédure de remplacement est autorisée pour la pompe hydraulique MX-204, version 5.2, dans sa région.

Ce n’est pas une simple recherche sémantique. Le système doit comprendre l’intention d’entretien, conserver inchangés des identifiants précis tels que la version MX-204 5.2, restituer la procédure de réparation en vigueur, appliquer la politique régionale appropriée et exclure tout ce qui concerne d’autres concessionnaires ou comptes. Une simple requête de similarité ne peut pas offrir de telles garanties. La couche de récupération doit se comporter comme un service d’information géré.

Considérer l’indexation comme une gestion de la publication des documents

Dans les premières versions de RAG, l’indexation est généralement perçue comme une seule étape : téléchargement, segmentation, intégration, enregistrement, fin. Par la suite, le document reste recherchable jusqu’à ce que quelqu’un remarque un problème. Les échecs qui en résultent sont faciles à prévoir.

• Un manuel révisé coexiste avec son prédécesseur.
• Un projet de politique devient recherchable avant même qu’il ne soit approuvé.
• Une procédure retirée reste disponible car il n’existe pas de processus de suppression.
• Une panne dans le pipeline laisse un document partiellement indexé, de sorte que seuls des fragments peuvent être récupérés.

Pour un corpus de support, l’ensemble le plus réduit d’états du cycle de vie utiles est le suivant :

• Brouillon : reçu, pas encore approuvé pour être récupéré.
• Candidat : indexé et en cours de validation.
• Actif : approuvé et apte à être récupéré.
• Remplacé : remplacé par une version plus récente, conservé à des fins d’audit, caché des requêtes ordinaires.
• En quarantaine : retenu en raison d’un problème de validation, de vérification des métadonnées ou d’une révision du contenu.
• Supprimé : retiré du corpus, ainsi que du stockage sous-jacent lorsque les règles l’exigent.

Une règle est primordiale : la recherche ne doit concerner que les documents en état Actif. Elle doit être appliquée au moyen de filtres de métadonnées, et non grâce à des habitudes de nommage des fichiers ou à des instructions contenues dans une requête.

Chaque document nécessite également un identifiant stable ainsi qu’un identifiant de version distinct. Le premier désigne l’élément logique, comme un bulletin de réparation donné, tandis que le second identifie l’une de ses versions. L’approbation d’une nouvelle version active cette dernière et marque l’ancienne comme obsolète, et ce changement doit se produire de manière atomique. Avec cela en place, le système cesse de renvoyer du contenu qui est pertinent mais plus valide.

Mise à jour des embeddings : incrémentale, versionnée, réversible

La mise à jour des embeddings est souvent décrite comme une tâche à exécuter chaque fois que le modèle change. Les déclencheurs réels sont bien plus variés :

• Un document source est modifié.
• Une politique atteint sa date d’effet ou de péremption.
• Le schéma des métadonnées évolue.
• La stratégie de segmentation s’améliore.
• Le modèle d’incorporation est mis à jour.
• Un document est retiré ou réclassé.
• Les droits d’un utilisateur changent.

Chacun de ces cas exige une réponse différente. Une version révisée du bulletin peut nécessiter uniquement une mise à jour au niveau des sections. Un nouveau modèle d’incorporation peut obliger à reconstruire tout le système. Un nouveau champ de métadonnées requiert une insertion contrôlée, tandis qu’un document retiré doit être immédiatement retiré de l’index actif.

Le processus de mise à jour doit donc suivre quatre versions : la révision source, la logique de segmentation, le modèle d’incorporation et le schéma des métadonnées utilisé pour le filtrage. Sans cette traçabilité, personne ne peut expliquer pourquoi deux segments se comportent différemment au moment de la récupération.

En pratique, le fichier reçu est comparé à la version active au moyen d’un hash de contenu ou d’une différence structurée. Les sections qui ont changé sont à nouveau divisées en blocs et intégrées, tandis que les sections inchangées restent telles quelles, sauf si la méthode de segmentation ou d’intégration a changé.

Les mises à jour importantes des modèles exigent une procédure plus sûre : créer un index candidat parallèle, exécuter des requêtes d’évaluation sur les deux, vérifier les contrôles d’accès, et ne rediriger le trafic que lorsque le nouvel index fonctionne de manière satisfaisante. La question importante n’est pas de savoir si le nouveau modèle obtient de meilleurs résultats sur un test de référence, mais plutôt de savoir si le nouvel index fournit les preuves correctes et approuvées pour les requêtes réellement envoyées par les utilisateurs.

Imposer le principe de location avant la récupération, et non après

Une faille de conception dangereuse mais courante dans les systèmes RAG multi-locataires consiste à filtrer par locataire après la recherche. Le système récupère d’abord des résultats larges, puis élimine ceux qui appartiennent à d’autres organisations. C’est trop tard. Les filtres de locataire et d’accès doivent définir l’espace des résultats potentiels avant même que toute correspondance vectorielle ou par mot-clé ne commence.

Dans la plateforme de support, le contenu est réparti en trois groupes.

• Contenu global : manuels du fabricant et procédures de sécurité partagées.
• Contenu des revendeurs : guides de service internes, accords commerciaux et instructions d’exploitation locales.
• Contenu des clients : historique des actifs, conditions des contrats et notes d’exploitation confidentielles.

Ils n’ont pas besoin du même schéma de stockage. Le contenu global peut partager un corpus. Le contenu des revendeurs peut partager un index protégé par des filtres obligatoires par locataire. Les clients hautement sensibles peuvent avoir besoin de leurs propres collections ou d’index isolés, en fonction des exigences réglementaires, contractuelles et de risque.

Le locataire, le rôle, la région, les droits d’accès au produit et le niveau de confidentialité doivent provenir de la session authentifiée et jamais du texte d’une requête. Un technicien qui tape le nom d’un autre revendeur dans une requête ne doit pas pouvoir modifier les filtres. En effet, la demande de recherche indique de ne rechercher que ce à quoi cet utilisateur authentifié a accès, et ce n’est qu’alors que le classement sémantique ou par mots-clés commence. Cela protège la confidentialité et élimine également les résultats irrelevants.

Recherche hybride pour des identifiants exacts

La recherche vectorielle dense est particulièrement utile lorsque les gens décrivent un problème en langage courant, par exemple en demandant quelle version de firmware est nécessaire avant d’installer une pompe de remplacement sur le MX-204. Les numéros de pièce, les codes de contrôleur et les chaînes de version se comportent différemment, et un index lexical est bien plus efficace pour les associer avec précision.

Dans le cas du MX-204, la recherche lexicale peut permettre de trouver le bulletin exact, car il contient les identifiants du contrôleur et de la pompe, tandis que la recherche dense fournit des directives de maintenance pertinentes. Un réclassificateur peut ensuite privilégier le document qui indique les prérequis en matière de firmware ainsi que la séquence d’installation autorisée.

Lorsque la qualité de la recherche est faible, ajouter davantage de fragments au contexte aide rarement. Un ensemble de résultats plus large ne fait généralement qu’augmenter le bruit, les délais, et les chances d’obtenir une réponse plausible qui n’est étayée par rien. Il vaut mieux déterminer à quel stade l’opération a échoué.

• Le document approprié était-il inactif ?
• Un filtre de métadonnées défectueux l’a-t-il exclu ?
• La recherche lexicale a-t-elle manqué un format alternatif de numéro de pièce ?
• Le réclassificateur a-t-il privilégié un document général plutôt qu’un document plus spécifique ?

Chacun de ces problèmes constitue un problème système mesurable.

Les métadonnées en tant que plan de contrôle

Les métadonnées sont souvent traitées comme des balises optionnelles ajoutées lors de l’ingestion. En production, elles déterminent ce que le système peut récupérer. Un schéma utile couvre cinq domaines.

• Identité : le document source, le système d’origine du morceau de données, et un hash du contenu.
• Cycle de vie : version, statut d’approbation, dates d’entrée en vigueur et d’expiration, ainsi que les priorités entre les versions.
• Accès : identifiant du client, région, droits liés au rôle, accès au produit, classe de confidentialité et restrictions légales.
• Récupération : type de document, langue, modèle d’équipement, famille de composants, ligne de produit et catégorie de contenu.

Opérations : version d’incorporation, version de segmentation, heure d’ingestion, identifiant de l’exécution du pipeline et statut de validation.

Avec cette structure, les questions qui seraient autrement complexes deviennent des requêtes simples. Quels documents actifs utilisent encore l’ancien modèle d’incorporation ? Quelles procédures de correction expirent le mois prochain ? Quels segments manquent de métadonnées régionales ? Quel utilisateur a le taux le plus élevé de résultats vides ? Quels systèmes sources causent le plus d’échecs d’ingestion ?

Les métadonnées doivent être validées avant qu’un document ne rejoigne le corpus actif. Un segment ne disposant ni de champ d’appartenance à un utilisateur, ni d’état de cycle de vie, ni de ligne de produit, ni de statut d’approbation ne doit pas devenir recherchable simplement parce que son embedding a été généré. De nombreux systèmes RAG deviennent peu fiables précisément à ce stade : la base de données fonctionne comme prévu, mais le modèle de métadonnées est insuffisant pour exprimer les règles réelles de l’organisation en matière d’accès, de cycle de vie et de politiques.

Observabilité permettant d’identifier l’étape défaillante

Lorsqu’un utilisateur signale une réponse incorrecte, plusieurs choses peuvent avoir mal tourné. La source appropriée n’a peut-être jamais été indexée, ou a été indexée mais marquée comme inactive, ou éliminée par un filtre. Elle a pu atteindre l’ensemble des candidats mais obtenir un classement trop bas. Elle a également pu entrer dans le contexte du modèle sans être prise en compte. Ou encore, le modèle a pu produire quelque chose que les preuves ne soutiennent pas. Chaque cas nécessite une solution différente.

Un service de récupération mature enregistre donc l’ensemble du parcours :

• La requête et le contexte de l’utilisateur.
• Les filtres d’accès et de cycle de vie qui ont été appliqués.
• Les candidats denses et les candidats lexicaux.
• Le classement fusionné et le résultat du réclassificateur.
• Les preuves finales transmises au modèle.
• Les citations utilisées dans la réponse.

Les mesures utiles comprennent le délai entre l’approbation de la source et l’activation de l’index, la part de contenu actif dans la version d’incorporation actuelle, les documents disposant de plus d’une version active, les taux de résultats nuls par type de requête, la couverture lors des tests de réponses connues, les taux de rejet par filtre ainsi que toute tentative d’accès inter-locataires.

Un indicateur pratique est la couverture des candidats : pour une requête ayant une réponse connue, la source correcte est-elle apparue parmi les candidats avant le réclassement ? Si ce n’est pas le cas, il faut examiner l’indexation, le filtrage ou la conception de la recherche. Si elle est apparue mais a été mal classée, il convient d’examiner les méthodes de fusion ou de réclassement. Si elle a été bien classée mais que la réponse l’a ignorée, le problème réside dans la génération du contenu ou l’assemblage des prompts. En séparant ces étapes, les équipes évitent de tenter de résoudre tout le problème en modifiant simplement le prompt.

Une routine opérationnelle

Un stockage vectoriel mérite la même discipline que tout service de données en production. Les vérifications quotidiennes doivent porter sur les échecs d’ingestion, les retards de mise à jour, les documents bloqués en état de candidature ou en quarantaine, l’absence de métadonnées obligatoires ainsi que les retards dans l’approbation avant indexation. Les revues hebdomadaires doivent évaluer la qualité des résultats de recherche pour de nombreux types de requêtes, allant des questions conversationnelles aux codes bruts, aux noms de produits, aux recherches de politiques, aux recherches dans d’autres langues et aux demandes vagues.

Toute modification concernant le découpage des données, les modèles d’embedding, le schéma des métadonnées ou les politiques d’accès doit d’abord être testée dans un environnement de candidature. L’ensemble d’évaluation doit comprendre des requêtes réelles d’utilisateurs, des cas avec des réponses connues, des tests de contrôle d’accès ainsi que des requêtes conçues pour détecter des fuites d’informations ou du contenu obsolète.

Le but n’est pas de récupérer davantage de documents. Il s’agit de fournir aux bons utilisateurs, au bon moment, les preuves approuvées appropriées. Un stockage vectoriel n’est pas une base de données passive derrière un chatbot, car c’est lui qui décide quelles preuves peuvent influencer une réponse. Lorsque des documents obsolètes restent actifs, les filtres propres aux utilisateurs deviennent optionnels, les identifiants disparaissent dans la correspondance sémantique ou les métadonnées ne parviennent pas à exprimer les règles métier ; le système devient alors peu fiable, quel que soit le niveau de performance du modèle.