Gramax montre comment comparer la qualité des réponses d'un RAG sans les juger « à l'œil »

Gramax a décrit un passage concret de l'évaluation subjective des systèmes RAG à une comparaison reproductible des réponses. L'équipe propose de ne pas regarder si les métriques de retrieval sont flatteuses, mais si l'utilisateur obtient, depuis la base de connaissances, une réponse précise, complète et compréhensible.

Ce qui a motivé la révision de l'approche est un problème typique de presque toute recherche RAG sur de la documentation ou une base de connaissances interne. Même si le système trouve bien les chunks pertinents, cela ne garantit pas une bonne réponse finale. L'utilisateur ne voit ni DCG, ni Recall@10, ni reranking, ni aucun autre indicateur interne. Il ne voit que le texte final. C'est à ce niveau que les principales défaillances apparaissent : le modèle peut ignorer une partie du contexte trouvé, répondre dans la mauvaise langue, ajouter des détails non confirmés ou produire un texte assuré mais peu lisible.

Chez Gramax, on précise avoir déjà travaillé sur la couche de retrieval : réglage du schéma de chunking, ajout de métadonnées, combinaison de plusieurs types de recherche et recours au reclassement des résultats. Cet ensemble de techniques augmente effectivement les chances d'extraire les bons passages de la base de connaissances. Mais une fois la recherche stabilisée, une nouvelle question se pose : comment savoir que toute la chaîne fonctionne pour l'utilisateur final, et pas seulement pour l'ingénieur qui regarde un tableau de bord technique ? En pratique, cet écart entre qualité de la recherche et qualité de la réponse est souvent source de faux optimisme dans le développement d'un RAG.

L'idée centrale de l'article est que l'évaluation doit être rattachée au scénario de l'utilisateur. Lorsqu'une personne pose une question sur la documentation, ce qui l'intéresse n'est pas une liste de chunks bien extraits, mais une réponse concrète : contient-elle le fait recherché, une nuance importante a-t-elle été perdue, y a-t-il des hallucinations, la langue de la requête est-elle respectée et peut-on se fier à la formulation ?

Ce déplacement de l'attention change la manière de construire le contrôle qualité. Au lieu d'un jugement « à l'œil », l'équipe propose de fixer un ensemble de critères et de comparer modèles et configurations sur le même échantillon de questions. C'est d'autant plus important que les différences entre variantes sont peu évidentes et que l'impression subjective laissée par quelques beaux exemples fausse facilement le tableau.

Une conclusion pratique distincte concerne la comparaison des modèles. Dans son article, Gramax souligne que, pour les tâches de RAG, il ne suffit pas de s'appuyer sur des benchmarks généraux ni sur la réputation d'un modèle sur le marché. Un même modèle peut être solide en génération mais moins rigoureux dans le respect du contexte trouvé. Il faut donc comparer en situation réelle : sur ses propres questions, sur sa propre base de connaissances et avec des règles de vérification claires. C'est ainsi que l'on voit quel modèle retient le mieux les faits, ne part pas dans l'invention, gère correctement la langue et répond de façon stable à des requêtes de même type.

Pour le marché, c'est un signal important. Les projets RAG sont de plus en plus déployés dans le support, les référentiels internes, les bases de règlements et la documentation produit, où une erreur dans la réponse coûte plus cher qu'un recul sur une métrique de recherche abstraite. L'approche décrite par Gramax fait en réalité passer la discussion sur la qualité du terrain de l'ingénierie à celui du produit : un bon système n'est pas celui qui fait bonne figure dans un rapport de retrieval, mais celui qui fournit de manière stable une réponse utile et vérifiable à la personne.

Plus tôt les équipes mesureront précisément cette couche, plus vite elles cesseront de confondre contexte trouvé et tâche utilisateur réellement résolue. Cela signifie que la prochaine étape du développement des systèmes RAG passera non seulement par l'amélioration de la recherche, mais aussi par la normalisation de l'évaluation de la réponse comme produit à part entière. Pour les équipes qui ont déjà configuré chunking, recherche hybride et reranking, cette méthode peut devenir le principal moyen de comprendre quelle combinaison de modèles et de prompts fonctionne vraiment en production.