Pourquoi les réponses de RAG semblent complètes alors que la recherche d’Azure DevOps prouve le contraire

La question qui a révélé la lacune

Les premières questions ont donné des réponses claires, bien documentées et peu inventives. Une question plus large — « Quel travail lié à l’IA est réalisé au sein de cette organisation ? » — semblait également satisfaisante : quelques paragraphes, quelques citations, rien d’évidemment incorrect. La même question soumise à az boards query, une recherche par force brute sans mécanisme de classement intelligent, a renvoyé des dizaines d’éléments que la réponse soignée n’avait jamais mentionnés. Aucun groupe de résultats concernant l’évaluation d’assistants de codage, la comparaison des coûts des modèles ou le débogage d’un outil spécifique n’apparaissait, car leur formulation différait peu de la question et ils ne figuraient jamais parmi les premiers résultats de la recherche sémantique.

Ce mode de défaillance est facile à manquer : une réponse bien classée n’est pas nécessairement une réponse complète, et le système ne fournit aucun indicateur pour vous indiquer laquelle vous avez reçue.

Une question qui n’a aidé que parfois

La première idée a été d’instruire le modèle à être plus prudent : pour les questions générales, il devait examiner les étiquettes de catégorie avant de répondre, plutôt que de se fier uniquement à la recherche. Cela a aidé de manière intermittente. La même formulation produisait des comportements différents à chaque exécution : parfois le modèle vérifiait les étiquettes, parfois il les ignorait. Rien dans la question ne changeait — seul le fait que l’instruction ait été suivie ou non à ce moment-là changeait.

Une instruction donnée à un modèle de langage n’est qu’un encouragement, pas une garantie. Lorsque la complétude est importante, le soin apporté ne peut pas dépendre de la décision du modèle, au dernier moment, d’être ou non méticuleux.

Rendre le parcours déterministe

Le changement suivant a mis fin aux demandes explicites. Le code vérifie systématiquement les balises pour chaque question générale, que le modèle estime ou non cela nécessaire. Résultat : un groupe de données fiables est passé d’environ la moitié des éléments identifiés à environ sept sur seize — ce qui est déjà mieux, mais toujours incomplet. Les prochaines étapes ont été inspirées par des lacunes concrètes constatées lors des tests, et non par de la spéculation :

Une étape consiste à analyser les résultats des recherches par balise afin de repérer des noms et des phrases répétés deux ou trois fois, puis à rechercher directement ces noms — de sorte qu’un nom de produit apparaît même lorsque personne ne l’a explicitement demandé, dès que le petit groupe d’éléments qui le contient est déjà visible.

Une étape qui prend en compte les relations entre graphes, et non seulement le texte, car des éléments de travail frères peuvent partager un même parent tout en n’ayant aucun mot de titre commun. Un élément intitulé comme un dépôt de tests de référence contenant des tâches de codage représentatives peut ne pas mentionner l’IA dans son propre texte et ne se relier qu’à travers la hiérarchie.

Une étape pour les dépôts, qui ne possèdent pas les mêmes balises de catégorie que les éléments de travail et resteraient donc invisibles pour les chemins basés sur des balises.

Une étape pour les personnes, après que des questions comme celle de savoir avec quelle fréquence deux collaborateurs ont travaillé ensemble aient donné des réponses fausses de manière convaincante.

Chacune a comblé une lacune mesurable. Finalement, le cas le plus difficile, composé de seize éléments, a été résolu complètement — pas partiellement, mais entièrement.

Un contexte supplémentaire rendait les réponses pires

Contre toute attente, une fois que la capacité de récupération s’est suffisamment améliorée pour que le pool du modèle passe de quelques centaines d’éléments à plus d’un millier, les réponses sont devenues plus courtes et moins complètes. Le modèle n’a pas planté ; il a simplement produit moins de contenu, bien qu’il disposât de davantage de matériel pertinent. Au-delà d’un certain seuil de volume, la qualité des réponses ne progresse pas avec l’ampleur du contexte — elle diminue. Les métriques de récupération se sont améliorées tandis que les métriques relatives aux réponses finales ont chuté au cours de la même expérience. La solution n’était pas d’« ajouter plus », mais de trouver ce plafond et de le respecter.

Une correction de transparence qui a inondé les questions restreintes

Lorsque le modèle résumait du contenu réel sans en indiquer le nom, une nouvelle section de réponse énumérait les éléments trouvés mais non nommés, de sorte que rien ne disparaissait silencieusement. La première version incluait dans ses réponses plus d’un millier d’éléments peu liés entre eux pour des questions précises, car le générateur de liste ne parvenait pas à distinguer les correspondances exactes du bruit généré par des étiquettes génériques. Une catégorie large rassemblait tout ce qui était vaguement lié et le traitait comme étant également digne d’être présenté.

La solution durable n’était pas seulement une limite numérique. Il s’agissait de séparer deux types d’éléments « trouvés mais non nommés » : un petit ensemble de correspondances exactes qui devaient toujours apparaître, et un grand groupe de bruit étiqueté de manière approximative qui nécessitait une limite stricte ainsi qu’une indication indiquant qu’il en existait davantage. Cette distinction était plus importante que la limite elle-même.

Fournir des outils au modèle — avec des garde-fous

Une question cruciale a guidé le reste du travail : pourquoi un être humain peut-il répondre à ce que le système ne peut pas faire, alors que tous deux consultent les mêmes données ? Les humains peuvent rédiger une nouvelle requête lorsque des outils prédéfinis ne conviennent pas, et ils vérifient à nouveau les réponses qui semblent erronées. Le modèle ne possédait aucune de ces capacités. Il disposait d’un outil lui permettant d’écrire sa propre requête pour une base de données en lecture seule — laquelle imposait également un mode lecture seule, limitait le temps d’exécution et fixait une taille maximale pour les résultats.

Deux tours supplémentaires ont été nécessaires. Lorsqu’on lui a demandé avec quelle fréquence deux personnes nommées collaboraient, le modèle a d’abord supposé qu’elles partageaient un nom de famille en raison d’une mention commune, a obtenu un résultat vide, et a alors deviné en se basant sur des commentaires sans rapport plutôt que de remettre en question l’absence totale de résultats. La règle établie a été : résoudre d’abord chaque nom en fonction de son enregistrement exact, et considérer une requête auto-réalisée donnant un résultat vide comme preuve que la requête est incorrecte, et non comme indication qu’il n’y a pas de collaborations.

Lors de la tentative suivante, le système a résolu les deux cas, exécuté la bonne requête, obtenu vingt-cinq éléments partagés — sans pour autant indiquer ce chiffre, car toute affirmation factuelle nécessitait un identifiant de citation tandis qu’un comptage calculé n’en possédait pas. En appliquant strictement la règle des citations, une réponse correcte a été rejetée. Une exception explicite était requise : un nombre calculé pouvait être indiqué directement sans identifiant de source.

Aucun de ces échecs n’était dû à une incapacité ; ils représentaient plutôt un respect correct des instructions qui ne couvraient pas cette situation. Cette distinction est plus importante qu’il n’y paraît au premier abord.

Comment les tests sont restés honnêtes

La vérité de référence n’était pas une simple vérification. Pour le cluster le plus difficile, seize éléments connus étaient listés au préalable à partir de la recherche exhaustive, puis évalués après chaque modification de récupération : combien apparaissaient dans la réponse finale, combien étaient cités, combien étaient simplement omis. C’est ce tableau de scores qui a donné un sens à « sept sur seize » puis à « seize sur seize ». Sans une liste exhaustive externe, l’idée que quelque chose semble complet n’est qu’une question d’apparence.

Organiser le flux de travail sans submerger le modèle

Les étapes déterministes nécessitent néanmoins un ordre précis. L’expansion des balises élargit d’abord l’ensemble des candidats ; l’extraction de noms approfondit ensuite cet ensemble ; les parcours dans le graphe ajoutent des voisins structurels ; les étapes relatives aux dépôts et aux personnes comblent les lacunes en termes de modalités. Ce n’est qu’après avoir constitué cet ensemble que une limite de taille permet de réduire ce qui est inclus dans la demande. Inverser cet ordre — demander au modèle d’être exhaustif avant que l’ensemble ne soit formé — revient au problème des incitations. Le travail visant à assurer l’exhaustivité relève de la conception du pipeline, et non d’utiliser de meilleurs adjectifs dans le prompt du système.

Citations versus faits calculés

La règle « citation pour chaque affirmation » protège contre l’invention lorsque le modèle cite des éléments de travail. Elle devient préjudiciable lorsque le modèle effectue des calculs arithmétiques ou combine les résultats d’outils. En séparant l’« affirmation citée » de l’« agrégat calculé » dans les instructions, on a pu restaurer le comptage de vingt-cinq collaborations sans affaiblir la discipline de citation pour les affirmations narratives. Les systèmes RAG utilisant des outils ont besoin des deux règles, indiquées explicitement.

Où en est la recherche

Une requête de base de données brute est, par construction, exhaustive : aucune ligne correspondante ne peut être manquée. Elle ne peut pas non plus expliquer, regrouper ou narrer un sens — elle renvoie une liste, pas une réponse. Le système compare désormais l’exhaustivité de cette requête aux cas difficiles qui ont été identifiés et testés, tout en expliquant les résultats par des textes prosaïques accompagnés de sources vérifiables. Ce résultat est mesuré, et non supposé.

En résumé, il ne s’agit pas de dire que « la complétude des RAG est résolue ». Il s’agit plutôt du fait que chaque lacune spécifique pouvant être identifiée et testée a été comblée, avec des chiffres avant et après. Il est impossible de promettre qu’il n’y aura pas de nouvelles lacunes, et aucun système de ce type ne devrait le laisser croire. L’affirmation « Le modèle a généralement raison » n’est pas une base fiable pour la fiabilité — justement, le mot « généralement » est celui qui échoue lorsqu’il s’agit de la question cruciale.