Lorsque la similarité n’est pas pertinente : construire des systèmes RAG d’entreprise au-delà de la recherche vectorielle.

La recherche vectorielle est remarquablement efficace pour mettre en évidence des textes ressemblant à une question. Cependant, la ressemblance et l’utilité sont deux choses distinctes, et c’est la différence entre elles qui entraîne souvent des erreurs dans les systèmes RAG d’entreprise.

Un document récupéré peut partager le vocabulaire d’un utilisateur tout en étant obsolète, inaccessible, incomplet ou hors sujet par rapport à la situation commerciale actuelle. En même temps, le document qui pourrait véritablement répondre à la question peut être formulé différemment et obtenir un score plus bas. Le problème ne réside généralement ni dans le modèle d’embedding ni dans la base de données vectorielle. Il provient plutôt de l’idée erronée selon laquelle la similarité sémantique équivaut à une définition complète de la pertinence, ce qui n’est pas le cas.

Dans une entreprise, la pertinence dépend de bien plus que du simple choix des mots. La date de création, l’autorité des sources, la géographie, le type de document, les permissions des utilisateurs, l’état du flux de travail, les liens contractuels ainsi que les relations entre les entités commerciales jouent tous un rôle. Un système fiable doit prendre en compte l’ensemble de ces facteurs et ne pas considérer la proximité dans l’espace vectoriel comme le critère décisif.

Comment la recherche vectorielle est devenue la norme

La recherche par mots-clés repose fortement sur des termes exacts. Une personne cherchant "politique de départ des employés" pourrait manquer un fichier intitulé "Procédure de départ des collaborateurs", car les deux ne partagent aucun mot en commun.

La recherche vectorielle a été la solution à cette faiblesse. Les documents sont transformés en embeddings, des représentations numériques de leur signification, et la question de l’utilisateur est convertie en un vecteur du même type. Le système renvoie ensuite les fragments dont les vecteurs sont les plus proches de ceux de la requête. Il est ainsi possible de trouver des contenus conceptuellement liés, même lorsque la question et la source utilisent des formulations différentes.

Cela fait de la récupération vectorielle une solution adaptée à de nombreuses tâches : gérer les questions en langue naturelle, associer des synonymes et des paraphrases, rechercher dans des documents non structurés, prendre en charge des requêtes conversationnelles ou multilingues, et réduire une grande collection à une courte liste de candidats.

Ces atouts ont placé les bases de données vectorielles au cœur des premières conceptions RAG, et le flux de travail standard semblait bien organisé. Les documents étaient divisés en blocs, chaque bloc recevait une représentation vectorielle, et ces vecteurs étaient stockés. Lors de la pose d’une question, celle-ci était également convertie en représentation vectorielle, les blocs les plus proches étaient récupérés et transmis à un modèle de langage, qui écrivait ensuite la réponse.

Les démonstrations et de petites bases de connaissances fonctionnent bien avec cette approche. C’est dans les environnements d’entreprise que des difficultés commencent à apparaître.

La similarité n’est qu’un des signaux parmi d’autres

Imaginons qu’un responsable des achats tape : « Quelles conditions de paiement s’appliquent dans notre accord actuel avec Northstar Components ? »

Un système ne reposant que sur des vecteurs pourrait inclure un contrat en cours avec un fournisseur, un contrat expiré avec le même fournisseur, un modèle contenant des conditions de paiement standard, un e-mail concernant une modification proposée, une politique d’achats mentionnant les paiements aux fournisseurs, ainsi qu’un contrat relatif à une autre filiale de Northstar.

Chacun de ces éléments est sémantiquement lié à la question, mais un ou deux seulement sont opérationnellement importants. Choisir correctement signifie devoir répondre à d’autres questions : quelle entité juridique est visée par l’expression « notre » ? Quelle société de Northstar est concernée ? L’accord est-il toujours en vigueur, et les amendements ont-ils modifié les termes originaux ? Quelle juridiction le régit ? Cet utilisateur a-t-il l’autorisation de le consulter ? Existe-t-il une version signée, et quelle source a la plus grande autorité ?

Une embedding ne possède pas de compréhension intégrée de telles contraintes. Elle mesure la proximité dans un espace sémantique appris. Elle ne peut pas déterminer quel document est juridiquement contraignant ou opérationnellement valide.

C’est ainsi qu’un score de similarité élevé engendre une confiance fausse. Le système récupère un texte plausible, le modèle de langage le transforme en une réponse soignée, et la prose fluide cache l’erreur de récupération.

Sept manières dont la similarité pure échoue

Plusieurs schémas d’échec récurrents rendent la recherche basée uniquement sur les vecteurs risquée.

Matériel obsolète. Les documents anciens ressemblent souvent à ceux actuels. Une police d’assurance expirée peut être identique à sa version remplacée, à l’exception d’un seul seuil, d’une date ou d’une règle d’approbation. Comme les formulations sont souvent similaires, les deux obtiennent de bons scores. En l’absence de contrôles de version et de date d’entrée en vigueur, le système peut finir par fournir des directives obsolètes, ce qui est particulièrement dangereux dans les domaines réglementés, où un petit changement dans la politique peut affecter la conformité, la tenue de rapports ou la manière dont les clients sont traités.

Indifférence envers l’autorité. Une note de réflexion, un e-mail interne et une politique approuvée peuvent traiter du même sujet, et la version informelle peut primer simplement parce que sa formulation ressemble à la question posée. La connaissance au sein d’une entreprise n’est pas une démocratie. Un contrat signé devrait généralement l’emporter sur un projet, une procédure approuvée sur un compte rendu de réunion, et une demande réglementaire validée sur les notes d’un analyste. La pertinence exige une hiérarchie des preuves.

Des relations séparées par fragmentation. Afin d’améliorer la précision et de respecter les limites des fenêtres de contexte, les systèmes RAG divisent les documents en petits fragments, ce qui peut isoler les faits des relations qui leur confèrent un sens. Un fragment peut définir une obligation de paiement, un autre indiquer le nom du fournisseur, et un troisième contenir une modification annulant la clause originale. Chaque fragment est incomplet en soi, et la récupération du passage le plus similaire ne garantit pas que l’ensemble des informations soit reconstruit.

Problèmes avec les identifiants exacts. Les embeddings sont optimisés pour le sens et représentent souvent mal les chaînes de caractères littérales. Les numéros de pièce, les numéros de compte, les références de clauses, les codes de médicaments, les identifiants d’équipement et les numéros de version en sont des exemples typiques. Une recherche pour "Model AX-1047" ne devrait pas renvoyer "AX-1041" simplement parce que leurs descriptions se ressemblent. La récupération d’informations dans le monde des affaires nécessite fréquemment à la fois précision littérale et précision sémantique.

Contraintes négatives. Les gens demandent souvent ce qui est absent : quels clients n’ont pas terminé la vérification, quels appareils ne relèvent pas de l’accord de maintenance en vigueur, quelles factures restent impayées après 60 jours, quels sites d’essai n’ont pas soumis les documents requis. De telles questions reposent sur l’absence, l’exclusion ou la comparaison entre des enregistrements. La recherche de similarité permet de retrouver du texte concernant un concept, mais elle ne peut pas déterminer de manière fiable ce qui manque.

Aucune notion d’état métier. Un objet d’entreprise passe par des états tels que brouillon, soumis, approuvé, suspendu, expiré et archivé. Deux documents concernant le même objet peuvent être presque identiques tout en étant dans des états différents, et l’état actuel peut déterminer si un document est pertinent ou non.

Aucune autorisation en soi ne suffit. Le document le plus pertinent sur le plan sémantique peut être celui que l’utilisateur n’a pas le droit de voir. Le contrôle d’accès ne peut pas se résumer à une simple instruction dans une demande. Le contenu restreint doit être supprimé avant d’atteindre le contexte du modèle, sinon le système risque de divulguer directement des informations sensibles ou de permettre au modèle de les déduire indirectement.

La pertinence a de multiples dimensions

Dans les systèmes RAG d’entreprise, la pertinence doit être considérée comme une combinaison de différents critères : similitude sémantique, pertinence basée sur des mots-clés ou des correspondances exactes, autorité de la source, validité temporelle, adéquation avec les règles commerciales, éligibilité en termes d’autorisation, ainsi que pertinence liée aux relations ou au graphe. Une formule de classement pourrait additionner ces critères, chacun ayant son propre poids.

Les pondérations dépendent du cas d’usage. Un assistant de recherche interne peut accorder une grande importance à la similarité sémantique. Un outil de réponse à des questions contractuelles peut privilégier les dates d’effet et l’autorité de la source. Une plateforme d’enquête peut être dominée par les relations entre personnes, événements, lieux et actifs.

Rien de tout cela ne signifie que chaque organisation a besoin d’un modèle de classement mathématique complexe. Cela signifie que la pertinence doit être définie intentionnellement et non héritée du score par défaut d’une base de données vectorielle.

À quoi ressemble une architecture de récupération plus solide

Un RAG fiable passe généralement par plusieurs étapes de récupération et de validation.

1. Comprendre la requête

Au préalable de la recherche, le système détermine ce qui est demandé. Cela peut impliquer l’ extraction de l’intention ainsi que de toutes les entités nommées, des plages de temps, des types de documents, des juridictions, des identifiants de clients ou de produits, des unités commerciales et du niveau d’autorisation requis, avant de décider si la question nécessite une recherche, un calcul, une comparaison ou un parcours dans un graphe.

Prenons l’exemple de la question « Qu’as‑tu changé dans notre politique de conservation des données en Europe cette année ? » Elle ne doit pas être traitée comme une recherche sémantique générique. Elle fait référence à une région, à une catégorie de document, à une fenêtre temporelle et à une comparaison de versions. La compréhension de la requête transforme une phrase vague en un plan de récupération structuré.

2. Filtrage des métadonnées

Les métadonnées réduisent l’espace de recherche avant ou pendant la récupération. Les champs utiles incluent la région, le propriétaire, l’unité commerciale, les dates d’entrée en vigueur et d’expiration d’un document, son statut d’approbation et sa version, le type de document, la classification des données, la famille de produits, les identifiants des clients ou des fournisseurs, ainsi que les attributs utilisés pour le contrôle d’accès.

L’application de filtres empêche les candidats clairement inéligibles de concurrencer ceux qui le sont. Elle fait également de la qualité des métadonnées un élément clé de la qualité du RAG : lorsque les documents sont ingérés sans dates fiables, propriétaires, statut de version ou étiquettes d’accès, la récupération reste fragile, quel que soit le modèle d’incorporation utilisé.

3. Récupération hybride

La récupération hybride combine la recherche sémantique avec la recherche lexicale. Les vecteurs gèrent le sens et les paraphrases, tandis que les méthodes lexicales comme BM25 s’occupent de la terminologie exacte, des identifiants et des termes rares. Un système hybride peut comprendre que « procédure de fin de contrat » est lié à « politique de départ », tout en exigeant une correspondance exacte pour « HR-OPS-204 ».

Les résultats peuvent être fusionnés par la fusion de rangs réciproques ou par une fonction de notation spécifique au domaine. Pour de nombreuses entreprises, il s’agit de l’une des mises à niveau les plus pratiques pour passer d’un processus basé uniquement sur des vecteurs.

4. Récupération de données structurées

Les fragments de documents ne constituent pas une source adaptée pour certaines questions. Tout ce qui concerne les comptages, les totaux, les seuils, les états ou les comparaisons convient généralement mieux aux requêtes SQL, aux index de recherche, aux API, aux entrepôts de données, aux bases de connaissances, aux systèmes de données maîtresses ou aux moteurs de règles.

Si quelqu’un demande « Combien de demandes en cours ont dépassé 500 000 roupies ce trimestre ? », la bonne approche consiste à interroger la source structurée qui contient les enregistrements des demandes. Un texte qui se contente de discuter des demandes ne peut pas fournir un chiffre précis. Une conception évoluée dirige chaque question vers le mécanisme le plus adapté.

5. Graphes de connaissances et recherche tenant compte des relations

Certaines questions portent essentiellement sur les relations entre éléments. Un graphe de connaissances peut modéliser les clients, les fournisseurs, les produits, les contrats, les lieux, les incidents et les réglementations, ainsi que les liens qui les relient.

Supposons qu’un analyste en risques souhaite savoir quels fournisseurs actifs sont connectés à des entités sanctionnées via des structures de propriété bénéficiaire. Il est peu probable qu’un seul paragraphe contienne toutes les preuves nécessaires. Pour y répondre, il faut suivre des liens à travers les archives des fournisseurs, les données de propriété des entreprises, les résultats des vérifications et l’état des contrats. La récupération de graphes permet de localiser le réseau d’entités concerné, et la recherche vectorielle peut ensuite extraire des passages pertinents sur ces entités ainsi que les liens qu’elle a révélés.

Cette combinaison est souvent désignée sous le nom de GraphRAG, bien que les implementations diffèrent. Sa valeur réside non pas dans le fait que les graphes soient plus avancés que les vecteurs, mais plutôt dans le fait que les graphes conservent des relations explicites, alors que les embeddings les réduisent à une proximité statistique.

6. Réclassement

La récupération en première passe doit privilégier le taux de rappel : il s’agit de collecter un ensemble large de candidats potentiellement pertinents. Un réclassificateur évalue ensuite plus attentivement ces candidats par rapport à la requête complète. Des encodeurs croisés, des modèles de classement spécialisés ou des évaluateurs basés sur des LLM peuvent déterminer si un passage répond réellement à la question.

Les signaux qui peuvent être pris en compte incluent le degré de pertinence directe du passage, l’alignement avec les entités, l’autorité, la fraîcheur, la complétude, la spécificité, les contradictions ainsi que les règles métier. L’objectif est de distinguer les passages qui sont « sur le sujet » de ceux qui sont « utiles pour cette question ».

7. Assemblage du contexte

Transmettre les cinq principaux segments à un LLM n’est pas une stratégie de contexte. Les éléments de preuve peuvent nécessiter un regroupement par document, un ordre chronologique, un enrichissement avec les sections voisines, des liens vers des définitions ou des tableaux, une déduplication, une fusion avec des amendements, une comparaison entre différentes versions, des étiquettes indiquant la source et l’autorité, ainsi qu’une compression qui ne supprime pas les exceptions.

L’objectif est de préserver la structure nécessaire au raisonnement. Pour une clause contractuelle, cela signifie inclure ses définitions, ses exclusions ainsi que l’historique des amendements. Une procédure clinique peut avoir besoin des avertissements qui la entourent. Un résultat financier peut nécessiter sa période de reporting et son principe comptable.

8. Validation des éléments de preuve

Avant de rédiger une réponse définitive, le système doit vérifier si les éléments de preuve sont suffisants. Les sources soutiennent-elles directement la réponse, et sont-elles à jour ? Les sources fiables sont-elles en désaccord ? Un document nécessaire fait-il défaut ? La réponse repose-t-elle sur une inférence non étayée ? L’utilisateur peut-il réellement accéder à chaque passage cité ?

Lorsque les preuves sont insuffisantes, la réponse la plus sûre consiste peut-être à le préciser, à demander des éclaircissements ou à faire appel à une autorité supérieure. Le système RAG d’entreprise doit être conçu pour s’abstenir de répondre, et non seulement pour le faire.

Les règles commerciales ont un poids réel

Une grande partie des erreurs de récupération ne pourra jamais être corrigée par des embeddings améliorés, puisque la pertinence est définie par l’organisation. Règles représentatives : privilégier la politique la plus récente approuvée, sauf si une politique régionale s’applique ; appliquer les amendements au contrat dans l’ordre où ils ont été exécutés ; donner la priorité aux données financières auditées aux estimations de la direction ; exclure les documents réglementaires en version草案 ; identifier le client par son entité juridique et non par son nom commercial ; et ne restituer que les enregistrements appartenant au territoire auquel l’utilisateur a accès.

Ces règles doivent figurer dans le code de récupération, de classement ou d’orchestration. Espérer qu’un LLM les déduira du contexte est peu fiable et ne laisse rien à auditer. C’est pourquoi le RAG d’entreprise devient alors une démarche d’ingénierie système plutôt qu’une simple question de choix de modèle.

Évaluer au-delà de la précision des réponses

Un système peut produire une réponse correcte pour une raison erronée, en utilisant des preuves faibles et en s’appuyant sur les connaissances préalables du modèle. Il peut également sembler précis lors des tests mais échouer dès que les documents changent. L’évaluation doit donc examiner chaque étape du processus.

Récupération. Vérifier si les preuves nécessaires ont été trouvées : recall@k, precision@k, moyenne du rang réciproque et gain cumulatif déprécié normalisé, ainsi que la fréquence à laquelle des identifiants exacts sont trouvés et la fréquence à laquelle les résultats sont à jour et fiables.

Contexte. Vérifier si le matériel rassemblé est utilisable : complétude des preuves, redondance, taux de contradictions, pertinence du contexte, préservation des relations entre tableaux et sections, et cohérence des versions.

Génération. Vérifiez la réponse finale : fidélité aux preuves, exactitude des citations, exhaustivité, proportion de affirmations non étayées, abstention appropriée, ainsi que respect des autorisations et des politiques en vigueur.

Résultats commerciaux. Suivez la valeur opérationnelle : heures économisées, fréquence d’escalade des cas, effort de révision restant, gravité des erreurs, rapidité de résolution des problèmes, confiance des utilisateurs dans l’outil, incidents de conformité, et ampleur d’adoption des workflows. De meilleurs résultats de recherche sémantique servent à peu si des contrats expirés ou des documents inaccessibles continuent d’apparaître.

Erreurs commises par les équipes en passant à la recherche vectorielle

Les organisations constatent souvent les limites du RAG basé uniquement sur les vecteurs, puis ajoutent de la complexité sans disposer d’un modèle clair de pertinence.

Une erreur consiste à adopter toutes les techniques en même temps. Un graphe de connaissances, un outil de réclassement et un flux de travail agentiel ne permettront pas de corriger l’absence de métadonnées ou une mauvaise gouvernance des documents.

Une autre erreur est de faire du LLM l’arbitre universel. Les modèles sont utiles pour interpréter les requêtes et classer les preuves, mais les règles qui doivent être précises, comme les contrôles d’accès, les dates et les identifiants d’entité, devraient généralement rester du code déterministe.

Une troisième erreur est de ne se concentrer que sur les questions de benchmark. Les utilisateurs réels posent des requêtes vagues, partielles et riches en contexte ; par conséquent, les données de test doivent inclure de véritables cas limites, des documents obsolètes, des sources contradictoires et des limites de permissions.

Enfin, certaines équipes considèrent la récupération d’informations comme une simple acquisition d’infrastructure. Le choix d’une base de données vectorielle n’est qu’une des nombreuses décisions à prendre, car la pertinence dépend également de la manière dont les documents sont ingérés et structurés, des métadonnées associées, du traitement des identités, ainsi que de la gestion du classement, de l’orchestration et de la gouvernance.

Une approche pratique

Il n’est pas nécessaire de remplacer la plateforme RAG existante pour améliorer la pertinence ; elle peut évoluer pas à pas.

Commencez par les questions qui ont échoué et classez chaque erreur de récupération. S’agissait-il d’un manque de preuves pertinentes, d’un classement trop bas, d’un filtrage incorrect, d’une division en plusieurs parties, ou d’une source obsolète qui a pris le dessus ?

Ensuite, déterminez ce que signifie la pertinence pour le flux de travail spécifique en décidant quelles sources ont autorité, quels champs de métadonnées sont importants et quelles règles métier régissent la validité.

Ensuite, ajoutez le mécanisme le plus simple adapté à chaque cas d’échec. Les identifiants exacts nécessitent une recherche lexicale. Les dates, les régions et les types de documents exigent des filtres de métadonnées. Un jugement insuffisant entre la requête et le document requiert un réclassificateur. Les segments manquant de contexte nécessitent la récupération des sections voisines. Les questions analytiques relèvent des bases de données structurées. Les réponses dépendant des relations entre entités exigent une exploration du graphe. Les permissions doivent être vérifiées de manière déterministe avant la récupération, et les preuves incomplètes doivent déclencher des règles d’abstention.

Finalement, créez un ensemble d’évaluation à partir de questions réelles des utilisateurs et d’échecs réels, et testez séparément la récupération et la génération afin que les améliorations dans un domaine ne masquent pas les problèmes dans un autre.

Les preuves pertinentes plutôt que du texte similaire

La recherche vectorielle reste précieuse et excelle à localiser des passages sur des thèmes similaires. Ce qu’elle ne peut pas faire seule, c’est déterminer quel passage est à jour, fiable, autorisé, complet ou applicable à une situation commerciale particulière.

Une architecture de pertinence plus large est nécessaire, combinant la récupération sémantique avec la recherche par correspondance exacte, les métadonnées, les règles métier, les sources structurées, les relations graphiques, le réclassement et une vérification des preuves.

La prochaine vague de systèmes RAG ne sera pas gagnée en recueillant davantage de textes similaires. Les vainqueurs seront ceux qui fourniront les preuves correctes au bon utilisateur, dans le bon contexte, au bon moment.