Comment réussir une évaluation RAG fiable ?

En évaluant séparément le retrieval, la génération et le résultat final. Un RAG peut échouer à plusieurs endroits, même quand la réponse a l’air propre. Je vous montre quoi mesurer, avec RAGAS, TruLens et DeepEval, sans tomber dans les métriques jolies mais inutiles.

Pourquoi un RAG s’évalue autrement ?

Un RAG ne se juge pas comme un chatbot classique, parce qu’il y a deux endroits où ça peut dérailler. Le retriever, c’est la partie qui cherche les bons documents ou les bons morceaux de documents. Le générateur, c’est le modèle qui rédige la réponse à partir de ce qu’on lui donne. Si l’un des deux se trompe, le résultat final peut être mauvais, mais pas pour la même raison.

C’est là que beaucoup d’évaluations deviennent floues. Les métriques NLP classiques, comme BLEU ou ROUGE, viennent du traitement automatique du langage. Elles comparent souvent une réponse générée avec une réponse de référence, en regardant les mots en commun, les phrases proches, ce genre de choses. C’est utile pour certains cas, mais pour un RAG, ça ne suffit pas.

Une réponse peut ressembler à la bonne réponse, être bien écrite, avoir le bon ton, et pourtant inventer une information. À l’inverse, une réponse peut être un peu maladroite alors que le système a parfaitement récupéré les bons chunks. Si on regarde seulement la réponse finale, on mélange tout. On ne sait plus si le problème vient de la recherche, du modèle, du prompt, du découpage des documents, ou juste d’une consigne mal formulée.

Je pose toujours trois niveaux d’évaluation dès le départ :

• Qualité de la récupération : Est-ce que les bons documents arrivent vraiment dans le contexte du modèle ?
• Qualité de la génération : Est-ce que le modèle répond fidèlement avec ce contexte, sans broder ni inventer ?
• Qualité de bout en bout : Est-ce que l’utilisateur reçoit une réponse utile, correcte et exploitable ?

Sur le terrain, j’ai vu plusieurs équipes changer de modèle en pensant que le LLM était mauvais. En fait, le vrai problème était avant. Les chunks étaient trop gros, mal découpés, ou le retriever ramenait des passages vaguement liés mais pas ceux qui contenaient la réponse. Le modèle faisait ce qu’il pouvait avec un mauvais contexte. Forcément, ça donnait une réponse moyenne.

Pour moi, c’est la règle de base. Avant de juger la réponse, je regarde d’abord si le bon contexte arrive dans la fenêtre du modèle. Si le bon passage n’est pas là, le reste de l’évaluation raconte souvent une mauvaise histoire.

Quelles métriques pour le retrieval ?

Les bonnes métriques retrieval mesurent si le système retrouve les bons éléments, au bon rang, dans les K premiers résultats. K, c’est juste le nombre de résultats qu’on regarde. Par exemple les 3, 5 ou 10 premiers chunks récupérés avant de donner le contexte au modèle.

Precision@K, c’est la proportion de résultats pertinents dans les K premiers documents récupérés. Si je demande les 5 premiers chunks et que 3 sont vraiment utiles, ma Precision@5 vaut 3/5. Je l’utilise quand je veux éviter le contexte bruité. Trop de bruit dans le prompt, et le générateur part vite dans une réponse floue, ou pire, il hallucine avec beaucoup d’assurance.

Recall@K, c’est la capacité à récupérer tous les éléments pertinents disponibles. Si une question nécessite 4 sources et que mon retrieval n’en remonte que 2 dans le top 10, j’ai un problème. Même si la précision semble correcte. C’est souvent là qu’on voit les mauvais découpages de chunks, les embeddings trop faibles, ou les filtres metadata mal réglés.

MRR, pour Mean Reciprocal Rank, mesure le rang du premier résultat pertinent. Dit simplement, est-ce que la bonne source arrive tout de suite ou est-ce qu’elle traîne en position 8 ? C’est très utile quand une seule bonne source suffit, mais qu’elle doit apparaître très tôt. J’ai déjà vu des RAG “fonctionner” en démo, sauf que la bonne source arrivait trop bas. Le modèle ne la recevait pas, donc il répondait avec ce qu’il avait sous la main.

NDCG, pour Normalized Discounted Cumulative Gain, tient compte du rang et du niveau de pertinence. C’est pratique quand toutes les sources ne se valent pas. Un document officiel peut valoir plus qu’une note interne ancienne. Un chunk exact vaut plus qu’un chunk vaguement proche.

Pour mesurer ça sérieusement, il me faut souvent un petit jeu de questions avec les documents attendus. Il sera imparfait au départ, c’est normal. Mais sans ça, on juge au feeling, et le feeling ment très bien.

Métrique	Ce qu’elle mesure	Quand je l’utilise
Precision@K	La proportion de documents pertinents dans les K premiers résultats.	Quand je veux réduire le bruit dans le contexte.
Recall@K	La capacité à retrouver tous les documents pertinents disponibles.	Quand une réponse dépend de plusieurs sources.
MRR	Le rang du premier résultat pertinent.	Quand la bonne source doit arriver très tôt.
NDCG	Le rang et le niveau de pertinence des résultats.	Quand certaines sources sont meilleures que d’autres.

Comment juger la génération ?

Je juge la génération en vérifiant trois choses très simples : est-ce que la réponse est pertinente, est-ce qu’elle reste fidèle au contexte récupéré, et est-ce qu’elle aide vraiment l’utilisateur. Si une réponse est bien écrite mais qu’elle invente un détail, pour moi elle échoue. C’est souvent là que les évaluations RAG deviennent intéressantes, parce qu’on ne juge pas juste du style, on juge la confiance.

La faithfulness, ou fidélité, mesure la capacité de la réponse à rester alignée avec les informations présentes dans le contexte récupéré. Si le contexte dit “le contrat se termine le 31 mars” et que la réponse dit “le contrat se termine fin avril”, c’est un problème de faithfulness. Même si la phrase est fluide. Même si elle semble crédible.

L’answer relevancy, ou pertinence de la réponse, regarde si la réponse répond vraiment à la question posée. Une réponse peut être fidèle au contexte, mais à côté de la plaque. Je l’ai vu chez un client sur une base documentaire RH : l’utilisateur demandait “Quels justificatifs fournir ?”, le bot répondait avec tout le processus d’onboarding. C’était vrai, mais pas utile.

La groundedness, qu’on peut traduire par ancrage dans les sources, va encore plus loin. L’idée, c’est que chaque affirmation importante doit pouvoir être rattachée aux documents fournis. Pas juste “ça a l’air cohérent”. On veut pouvoir pointer vers une source, un passage, une preuve.

L’hallucination arrive souvent quand le modèle comble les trous du contexte au lieu de dire “je ne sais pas”. C’est humainement tentant, et les modèles sont entraînés à produire une réponse. Mais dans un système RAG, une bonne réponse peut parfois être une réponse courte qui dit qu’il manque une information.

Les frameworks modernes utilisent souvent un LLM comme juge, c’est-à-dire un modèle de langage chargé de noter automatiquement ces dimensions. C’est pratique, rapide, scalable. Mais ce n’est pas magique.

• Je garde toujours des exemples de contrôle, avec des réponses attendues.
• Je suis les scores dans le temps, surtout après un changement de prompt, de modèle ou de retriever.
• Je lis des cas réels, parce qu’un score global flatteur peut masquer une réponse dangereuse sur un cas sensible.

C’est justement là que RAGAS, TruLens et DeepEval deviennent utiles. Chacun apporte une méthode différente pour mesurer ces signaux, automatiser une partie du jugement, et garder un œil critique sur ce que le RAG raconte vraiment.

RAGAS TruLens ou DeepEval ?

Je ne mets pas RAGAS, TruLens et DeepEval dans le même panier. Oui, les trois servent à évaluer un RAG, c’est-à-dire un système qui récupère des documents avant de générer une réponse. Mais dans une vraie équipe, ils ne répondent pas au même problème.

RAGAS est souvent le premier choix quand on veut mesurer automatiquement la qualité globale d’un pipeline RAG sur un jeu de questions-réponses. Il couvre des dimensions très utiles comme faithfulness, donc est-ce que la réponse reste fidèle aux sources, answer relevancy, context precision, context recall et context relevancy. C’est pratique pour suivre une tendance dans le temps. Vous changez votre chunking, votre moteur de recherche ou votre prompt, et vous voyez si la qualité monte ou descend.

TruLens est plus orienté observabilité. Là, je cherche moins à produire un score global qu’à comprendre ce qui se passe dans l’application. Sa logique de triade RAG est assez saine : context relevance, est-ce que les documents récupérés sont pertinents, groundedness, est-ce que la réponse est bien ancrée dans ces documents, et answer relevance, est-ce que la réponse répond vraiment à la question. Les feedback functions sont des fonctions d’évaluation qui notent ces comportements. C’est très utile quand un client me dit “le chatbot répond n’importe quoi parfois”, parce qu’on peut inspecter les traces et remonter à l’étape qui casse.

DeepEval est plus proche de l’esprit tests unitaires, mais pour des applications LLM. Un LLM, c’est simplement un modèle de langage comme GPT, Claude ou Mistral. DeepEval propose aussi des métriques RAG comme answer relevancy, faithfulness, contextual precision, contextual recall et contextual relevancy. Son intérêt, c’est l’intégration dans les workflows de test. Vous pouvez bloquer une mise en production si une régression qualité apparaît. C’est moins sexy qu’un dashboard, mais franchement, c’est souvent ce qui manque pour industrialiser.

Je ne choisis pas le framework le plus à la mode. Je choisis celui qui répond au problème d’équipe.

framework	point fort	métriques clés	meilleur cas d’usage
RAGAS	Évaluation automatique de jeux de questions-réponses	Faithfulness, answer relevancy, context precision, context recall, context relevancy	Suivre la qualité globale d’un pipeline RAG dans le temps
TruLens	Observabilité, traces et diagnostic fin	Context relevance, groundedness, answer relevance	Comprendre pourquoi une application LLM se comporte mal
DeepEval	Tests qualité intégrables au cycle de développement	Answer relevancy, faithfulness, contextual precision, contextual recall, contextual relevancy	Industrialiser des checks qualité avant déploiement

Comment choisir son approche ?

Je choisis rarement une approche d’évaluation RAG “idéale” sur le papier. Je la choisis selon trois choses très concrètes : le risque business, la maturité de l’équipe, et le moment du projet. Un prototype interne n’a pas besoin du même niveau de contrôle qu’un assistant utilisé par des juristes, des médecins ou des clients en autonomie.

Sur un prototype, je commence simple. Je veux savoir vite si le système tient debout. Je regarde souvent quatre métriques : context precision, pour vérifier si les documents récupérés sont vraiment utiles ; context recall, pour voir si on retrouve bien les infos nécessaires ; faithfulness, pour mesurer si la réponse reste fidèle aux sources ; et answer relevancy, pour vérifier si la réponse répond vraiment à la question. Ce n’est pas parfait, mais ça donne déjà une bonne boussole.

Quand l’application part en production, je durcis le jeu. Je versionne les jeux de tests, parce qu’un score sans historique ne raconte pas grand-chose. J’ajoute des cas difficiles, des questions ambiguës, des documents proches mais contradictoires, des formulations utilisateur un peu sales. Et surtout, je regarde régulièrement les réponses ratées. C’est souvent là qu’on apprend le plus. Chez un client, on avait un score moyen correct, mais les erreurs étaient concentrées sur trois familles de questions critiques. La moyenne nous rassurait, les exemples nous disaient la vérité.

Symptôme	Ce que je corrige d’abord
Le contexte récupéré est mauvais	Le chunking, c’est-à-dire la découpe des documents, l’indexation, les embeddings ou le ranking.
Le contexte est bon mais la réponse invente	Le prompt, les consignes de citation, les garde-fous ou le choix du modèle.
Les scores varient trop	Le jeu d’évaluation, la stabilité des exemples, puis l’analyse manuelle des cas au lieu de croire uniquement la moyenne.

Pour un cas sensible, je ne laisse jamais les scores automatiques décider seuls. Je combine les métriques avec une revue humaine, au moins sur les cas à risque. L’automatique aide à passer à l’échelle, l’humain garde le sens métier.

Une évaluation RAG utile n’est pas là pour décorer un dashboard. Elle doit m’aider à décider quoi corriger en premier. Si elle ne change aucune décision produit, technique ou métier, elle est probablement trop théorique.

On mesure quoi en premier maintenant ?

Pour évaluer un RAG sérieusement, je sépare toujours le problème en trois morceaux : le retrieval, la génération et la qualité de bout en bout. Les métriques comme Precision@K, Recall@K, MRR ou NDCG disent si le bon contexte arrive. Les métriques comme faithfulness, groundedness et answer relevancy disent si la réponse reste fiable. RAGAS, TruLens et DeepEval apportent chacun une manière différente de structurer ce contrôle. Le bon choix dépend surtout de votre usage, pas du buzz autour de l’outil. Le bénéfice pour vous est simple : vous savez où votre RAG casse, donc vous corrigez plus vite.

FAQ

• Pourquoi BLEU et ROUGE ne suffisent pas pour évaluer un RAG ?
  Parce qu’ils ne vérifient pas vraiment si le bon contexte a été récupéré ni si la réponse reste fidèle aux sources. Un RAG peut produire une phrase proche d’une référence tout en s’appuyant sur un mauvais document, ou donner une réponse bien écrite mais inventée.
• Quelle est la différence entre évaluer le retrieval et la génération ?
  L’évaluation du retrieval regarde si les bons documents ou chunks remontent dans les premiers résultats. L’évaluation de la génération regarde si la réponse produite est pertinente, fidèle au contexte et utile. Les deux sont nécessaires, sinon on ne sait pas où le système échoue.
• Quelles métriques suivre en priorité pour un RAG ?
  Je commence souvent avec context precision, context recall, faithfulness et answer relevancy. Si j’ai un jeu de documents attendus, j’ajoute Precision@K, Recall@K, MRR et NDCG pour diagnostiquer plus finement le retrieval.
• Quand utiliser RAGAS plutôt que TruLens ou DeepEval ?
  RAGAS est pratique pour scorer automatiquement un pipeline RAG sur des métriques dédiées. TruLens est très utile pour observer les traces et comprendre le comportement d’une application. DeepEval convient bien quand on veut intégrer des tests qualité dans un workflow de développement.
• Une évaluation RAG peut-elle être entièrement automatique ?
  Elle peut être largement automatisée, mais je garde toujours une part de revue humaine sur les cas importants. Les scores aident à détecter les dérives et comparer des versions, mais les exemples réels restent essentiels pour comprendre les erreurs et éviter les faux signaux.

 

 

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne des équipes sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA en entreprise et le SEO/GEO. J’ai travaillé avec des acteurs comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez cadrer, évaluer ou industrialiser vos projets IA et data sans perdre des semaines en tests flous, contactez-moi.