Gramax a montré comment comparer la qualité des réponses RAG sans évaluation manuelle subjective

Gramax a décrit la transition pratique de l'évaluation subjective des systèmes RAG vers la comparaison reproductible des réponses : l'équipe propose de ne pas se concentrer uniquement sur la qualité des métriques de retrieval, mais sur le fait que l'utilisateur obtient une réponse précise, complète et compréhensible de la base de connaissances. Le problème typique de presque toute recherche RAG dans la documentation ou une base de connaissances interne est que, même si le système trouve bien les chunks pertinents, cela ne garantit pas une réponse finale de qualité. L'utilisateur ne voit pas le DCG, le Recall@10, le reranking et autres indicateurs internes.

Il ne voit que le texte final. C'est à ce niveau que surgissent les principaux dysfonctionnements : le modèle peut ignorer une partie du contexte trouvé, répondre dans une mauvaise langue, ajouter des détails non vérifiés ou générer un texte assuré mais difficile à lire.

Gramax note qu'ils ont déjà travaillé à l'amélioration de la couche de retrieval : en sélectionnant des schémas de chunking, en ajoutant des métadonnées, en combinant différents types de recherche et en utilisant le reranking des résultats. Cet ensemble de techniques augmente réellement les chances d'extraire les fragments nécessaires de la base de connaissances. Mais après la stabilisation de la recherche, une nouvelle question se pose : comment savoir que toute la chaîne fonctionne pour l'utilisateur final, pas seulement pour l'ingénieur qui regarde le tableau de bord technique ? En pratique, cet écart entre la qualité de la recherche et la qualité de la réponse est souvent la cause du faux optimisme dans le développement RAG.

L'idée clé est que l'évaluation doit être liée au scénario utilisateur. Si quelqu'un pose une question sur la documentation, son intérêt n'est pas une liste de chunks bien extraits, mais la réponse concrète : le fait nécessaire s'y trouve-t-il, aucune nuance importante n'a-t-elle été perdue, y a-t-il des hallucinations, la langue de la demande a-t-elle été respectée et peut-on faire confiance à la formulation ? Ce changement de perspective oblige à construire autrement la vérification de la qualité.

Au lieu d'une évaluation « à l'œil », l'équipe propose de fixer un ensemble de critères et de comparer les modèles et configurations sur le même ensemble de questions. C'est particulièrement important quand les différences sont subtiles et que l'impression subjective fausse facilement le tableau global.

Une conclusion pratique distincte concerne la comparaison de modèles. Dans son article, Gramax souligne que pour les tâches RAG, il ne suffit pas de s'appuyer sur les benchmarks généraux ou la réputation du modèle sur le marché. Un même modèle peut être fort en génération mais plus faible dans la discipline de répondre en fonction du contexte trouvé. Il faut donc comparer dans une situation appliquée : sur vos propres questions, votre propre base de connaissances et avec des règles de validation claires. C'est ainsi qu'on peut voir quel modèle maintient mieux les faits, ne s'égare pas dans des fantasmes, fonctionne correctement avec la langue et répond régulièrement aux requêtes similaires.

Pour le marché, c'est un signal important. Les projets RAG sont de plus en plus déployés dans le support, les guides internes, les bases de règlementations et la documentation produit, où une erreur de réponse coûte plus cher qu'une baisse d'une métrique de recherche abstraite. L'approche décrite par Gramax déplace effectivement la conversation sur la qualité du plan technique au plan produit : un bon système est celui qui fournit régulièrement une réponse utile et vérifiable à l'utilisateur, pas celui qui a belle allure dans les rapports de retrieval.

Plus tôt les équipes commenceront à mesurer ce niveau, plus vite elles cesseront de confondre le contexte trouvé avec la tâche utilisateur réellement résolue. Cela signifie que le prochain stade d'évolution des systèmes RAG sera lié non seulement à l'amélioration de la recherche, mais aussi à la normalisation de l'évaluation des réponses comme produit distinct. Pour les équipes qui ont déjà configuré le chunking, la recherche hybride et le reranking, cette méthodologie peut être le moyen principal de comprendre quelle combinaison de modèles et de prompts fonctionne vraiment en production.