Votre RAG répond, cite ses sources, refuse parfois d'inventer. En lisant quelques réponses, vous le trouvez « plutôt bon ». Mais ce jugement à l'œil ne tient pas : une réponse peut être fluide, bien tournée, parfaitement plausible — et fausse. Et même si vos dix exemples passent, qu'en est-il des mille questions réelles des utilisateurs, ou de la prochaine version où vous aurez changé le chunking ? Sans mesure, vous naviguez à l'aveugle. Cet article explique pourquoi l'évaluation est indispensable, détaille les quatre métriques qui structurent le diagnostic d'un RAG, et montre comment les croiser pour localiser précisément la cause d'une défaillance — le tout automatisé par un framework comme RAGAS.
Une réponse plausible n'est pas une réponse correcte
Un LLM est entraîné pour produire du texte fluide et convaincant — pas nécessairement vrai. C'est précisément ce qui rend ses erreurs dangereuses : une hallucination ne ressemble pas à une erreur. Elle a le ton assuré, la grammaire impeccable et la structure d'une bonne réponse. Rien, dans la forme, ne signale qu'elle est fausse.
À la question « sous combien de jours suis-je remboursé ? », deux réponses peuvent sembler également crédibles : « sous 14 jours » et « sous 30 jours ». Une seule est dans la documentation. Juger « à l'intuition » revient à faire confiance à la forme, alors que c'est le fond qu'il faut vérifier. L'évaluation manuelle, elle, se heurte à trois murs : elle ne passe pas à l'échelle (relire 500 réponses à chaque modification, jamais), n'est pas reproductible (deux relecteurs ne notent pas pareil) et ne dit pas pourquoi (« mauvaise réponse » n'indique pas s'il faut corriger le chunking, le retrieval ou le prompt). D'où le besoin de métriques chiffrées, calculées automatiquement, rejouables à l'identique.
Évaluer un RAG, c'est évaluer deux choses
Un RAG n'est pas une boîte unique : c'est un pipeline en deux temps, retrieval puis génération. Une mauvaise réponse peut venir de l'un, de l'autre, ou des deux — et la correction n'est pas la même. Il faut donc séparer les responsabilités : le retrieval a-t-il remonté les bons passages ? Et, à supposer les bons passages présents, la génération s'appuie-t-elle fidèlement dessus tout en répondant à la question ? Cette séparation est la clé du diagnostic. À chaque étape correspond une paire de métriques, soit quatre indicateurs, tous exprimés entre 0 et 1 (plus c'est haut, mieux c'est).
Les métriques de récupération
Elles répondent à une seule question : le retrieval a-t-il remonté ce qu'il fallait ?
Context precision — les passages récupérés sont-ils pertinents, et bien classés ? Elle mesure la proportion de passages réellement utiles parmi ceux remontés, en valorisant l'ordre : les passages pertinents doivent arriver en tête. Une precision basse signifie que la base ramène du bruit — passages hors sujet, ou bons passages noyés en bas du classement.
Context recall — a-t-on récupéré tout ce qu'il fallait ? Elle mesure la part de l'information nécessaire à la réponse qui se trouve dans les passages récupérés. Un recall bas signifie qu'il manque un passage : l'information existait dans le corpus mais n'a pas été remontée. Symptôme d'un k trop petit, d'un chunking qui éparpille, ou d'un modèle d'embedding inadapté.
La precision sanctionne le bruit (on a ramené du superflu), le recall sanctionne l'oubli (on a laissé de côté de l'essentiel). Un bon retrieval vise les deux.
Les métriques de génération
Elles supposent les passages fournis et interrogent le travail du LLM : a-t-il bien exploité son contexte ?
Faithfulness (fidélité) — la réponse est-elle ancrée dans le contexte ? Elle mesure si chaque affirmation de la réponse peut être justifiée par les passages fournis. Une faithfulness basse est la signature de l'hallucination : le modèle a ajouté des informations qui ne sont pas dans le contexte. C'est la métrique anti-invention par excellence.
Answer relevancy (pertinence de la réponse) — la réponse adresse-t-elle la question posée ? Elle mesure si la réponse est directe et complète, sans hors-sujet ni remplissage. Une relevancy basse signale une réponse évasive ou à côté — même si tout ce qu'elle dit est vrai. Ces deux métriques sont complémentaires : une réponse peut être parfaitement fidèle mais hors sujet, et inversement. On veut les deux : ancrée et pertinente.
Le LLM-as-judge et RAGAS
Comment calculer « la réponse est-elle ancrée dans le contexte ? » automatiquement, sur des centaines de questions ? La réponse moderne est le LLM-as-judge : on confie l'évaluation à un LLM. Pour la faithfulness, on décompose la réponse en affirmations élémentaires et on demande à un modèle juge si chacune est étayée par le contexte. Le score tombe sans qu'un humain ait tout relu.
L'intérêt est considérable : on évalue sans jeu de référence annoté à la main pour la plupart des métriques (faithfulness, answer relevancy et context precision se calculent à partir de la question, des passages et de la réponse). Seul le context recall réclame en général une vérité terrain. C'est précisément ce qu'automatise le framework open-source RAGAS, devenu une référence pour évaluer un RAG en quelques lignes de Python.
Un mot de prudence : le juge est lui-même un LLM, donc imparfait. Ses scores sont d'excellents indicateurs relatifs (comparer deux versions, suivre une tendance) mais pas des vérités absolues. On s'en sert pour décider « cette version est-elle meilleure que la précédente ? », pas pour proclamer « ce RAG est correct à 87,3 % ».
Le diagnostic croisé
Tout l'intérêt de séparer les quatre métriques apparaît ici : leur combinaison localise la panne. Un score global bas ne dit rien d'actionnable ; le croisement, si.
| Récupération | Génération | Diagnostic | Où agir |
|---|
| ✅ bonne | ✅ bonne | Le RAG fonctionne | — |
| ❌ recall bas | (peu importe) | Le bon passage n'est pas récupéré | Chunking, k, embeddings |
| ❌ precision basse | ✅ faithfulness OK | Trop de bruit récupéré, mais le modèle fait le tri | k, re-ranking |
| ✅ bonne | ❌ faithfulness basse | Bon contexte, mais le modèle invente | Prompt (ancrage), modèle |
| ✅ bonne | ❌ relevancy basse | Bon contexte, mais réponse à côté | Prompt (formulation) |
La logique est toujours la même : on regarde d'abord la récupération. Si le recall est bas, inutile de toucher au prompt — le modèle n'avait pas l'information. Ce n'est qu'une fois la récupération saine qu'on interprète les métriques de génération.
Conclusion
Quatre métriques, deux familles : context precision et context recall jugent le retrieval (bruit et oubli) ; faithfulness et answer relevancy jugent la génération (ancrage et pertinence). Calculées automatiquement par LLM-as-judge — via RAGAS notamment —, elles évitent la relecture manuelle, et leur croisement localise la cause d'une défaillance : récupération d'abord, génération ensuite. On ne peut pas améliorer ce qu'on ne mesure pas — c'est le préalable indispensable à toute optimisation d'un RAG.
