Un RAG sur 11 000 fichiers confondait les références produit et renvoyait les données de la machine voisine

Un bot d'aide aux ventes qui répond à partir de la documentation technique se trompe à un coût plus élevé qu'un chat de support de boutique en ligne. Le commercial obtient un chiffre, le transmet au client, et le client commande la mauvaise machine. C'est précisément le cas analysé sur Habr : 11 000 fichiers de documentation technique, plus de 100 commerciaux et un bot RAG qui citait avec aplomb les chiffres de la fiche d'un modèle voisin.

Ce que l'on sait du cas

La publication dans le flux de Habr n'est pour l'instant disponible que sous forme d'annonce ; nous nous appuyons donc uniquement sur ce qu'elle déclare. Le reste de cet article relève de la logique d'ingénierie générale de ce type de systèmes, et non d'un compte rendu des mesures de l'auteur.

• Corpus : environ 11 000 fichiers de documentation technique.
• Utilisateurs : plus de 100 commerciaux.
• Symptôme : le bot répond avec assurance, mais prend les paramètres dans la fiche d'une autre machine.
• Type de problème : requêtes portant sur une référence et sur la désignation exacte d'un modèle.
• Résultat annoncé : l'auteur décrit ce qui a fini par fonctionner, avec une analyse des causes.

Pourquoi les vecteurs confondent les références

Les embeddings denses compressent un fragment de texte en un vecteur qui reflète son sens. Pour la question « quelle est la puissance de la broche d'un centre d'usinage », cela fonctionne bien. Pour une requête par référence du type « XYZ-4200-B », la situation est différente. Le tokenizer découpe une telle chaîne en sous-mots, et le modèle d'embeddings n'est pas tenu de considérer la différence entre « 4200-B » et « 4200-D » comme significative. Dans l'espace vectoriel, ces désignations se retrouvent voisines.

Les fiches produit d'une même série aggravent le problème. Elles suivent un même gabarit : mêmes sections, mêmes formulations, mêmes tableaux. Seuls les chiffres diffèrent. Du point de vue de l'embedding, c'est quasiment le même document, et la recherche renvoie sans broncher dans le top 5 des chunks de plusieurs modèles à la fois.

La mécanique habituelle des LLM prend ensuite le relais. Quand un fragment plausible arrive dans son contexte, le modèle le cite. Il ne sait pas que la fiche n'est pas la bonne : la requête contient une référence, le contexte ne la contient pas, et personne ne vérifie cet écart. L'erreur survient à l'étape de retrieval, et non de génération ; corriger le prompt système est donc ici presque inutile.

Que vérifier dans votre RAG

La boîte à outils pour ce type de problème est connue, et chaque technique mérite d'être testée sur de vraies requêtes de commerciaux.

Premièrement : la recherche hybride. Un index lexical de type BM25 est placé à côté de l'index vectoriel, et les résultats sont fusionnés via Reciprocal Rank Fusion ou par pondération. La correspondance exacte de la chaîne de la référence obtient ainsi un poids que le vecteur ne lui donne pas.

Deuxièmement : l'extraction des identifiants de la requête. Si la question contient une référence, on peut la détecter par expression régulière ou à l'aide d'un référentiel de modèles, puis l'utiliser comme filtre strict sur les métadonnées du document. La fiche d'une autre machine ne remontera alors tout simplement pas dans les résultats.

Troisièmement : le contexte à l'intérieur du chunk. Si, lors du découpage, on ajoute à chaque fragment le nom du modèle, la série et le nom du fichier, le tableau de chiffres cesse d'être anonyme.

Quatrièmement : le reranker. Un cross-encoder appliqué aux N meilleurs candidats associe mieux la requête et le fragment qu'une comparaison entre deux vecteurs calculés indépendamment.

Cinquièmement, la solution la moins coûteuse : une vérification avant la réponse. Si la référence de la requête ne figure pas dans les sources transmises au contexte, le bot doit répondre « je n'ai rien trouvé » plutôt que de deviner.

Pour les tests, constituez un jeu de questions réelles contenant des références, y compris des paires de modèles proches, et mesurez la proportion de cas où le bon document apparaît dans le top-k. Cette métrique révélera le problème avant que le client ne le remarque.