Évaluation RAG quel framework choisir pour un chatbot fiable ?

Le bon framework dépend surtout de votre maturité RAG, de vos métriques et de votre besoin de suivi continu. Je vais comparer RAGAS, TruLens et DeepEval sans folklore, avec les métriques utiles, les pièges classiques et une façon simple de choisir sans se faire piéger par de belles réponses fausses.

Pourquoi BLEU et ROUGE ne suffisent pas ?

BLEU et ROUGE ne suffisent pas parce qu’un système RAG peut échouer côté retrieval ou côté génération, et ces métriques regardent surtout le chevauchement de mots avec une réponse attendue.

Le RAG, pour Retrieval Augmented Generation, assemble deux briques. D’abord un retriever, c’est le moteur qui va chercher les bons morceaux de documents, souvent appelés chunks, dans une base documentaire. Puis un LLM, le modèle de langage, qui rédige une réponse à partir de ce contexte.

Le problème, c’est qu’une mauvaise réponse peut venir de plusieurs endroits. Le bon document n’a peut-être jamais été récupéré. Ou alors il a été récupéré, mais le LLM l’a mal compris. Ou pire, le contexte était bon et le modèle a quand même inventé une réponse crédible. Dans les trois cas, BLEU et ROUGE vont avoir du mal à dire où ça casse.

Cas	Ce qui se passe	Ce qu’il faut mesurer
Retrieval faible	Les chunks récupérés sont hors sujet ou incomplets.	La pertinence des sources remontées.
Génération faible	Le bon contexte est là, mais la réponse est mal formulée ou inexacte.	La fidélité de la réponse au contexte.
Hallucination	Le modèle ajoute des informations non présentes dans les sources.	L’ancrage dans les documents fournis.

J’ai souvent vu des équipes valider un chatbot parce que les réponses semblaient propres. Le ton était bon, les phrases étaient fluides, ça donnait confiance. Mais quand on regardait les sources récupérées, elles étaient faibles, parfois hors sujet. C’est là que ça devient dangereux. Une réponse fluide peut masquer un mauvais diagnostic.

BLEU et ROUGE peuvent rester utiles pour comparer deux formulations sur un jeu de test très cadré. Mais pour un chatbot RAG fiable, ça ne suffit pas. On a besoin de savoir si le système trouve les bonnes informations, s’il les utilise correctement, et si l’utilisateur obtient une réponse réellement utile.

• Mesurer le retrieval pour vérifier que les bons documents remontent.
• Mesurer la génération pour vérifier que le LLM respecte le contexte.
• Mesurer l’expérience finale pour savoir si la réponse aide vraiment l’utilisateur.

Quelles couches faut-il évaluer ?

Il faut évaluer trois couches : la retrieval quality, la generation quality et la end-to-end quality. Si on n’en mesure qu’une seule, on peut facilement se tromper. J’ai déjà vu un chatbot donner une bonne réponse avec de mauvais documents, ou l’inverse, récupérer les bons chunks puis halluciner au moment de répondre.

La première couche, c’est la retrieval quality. La question est simple : est-ce que le système a retrouvé les bons chunks dans le top K ? Le top K, c’est la liste des K documents ou passages que le moteur de recherche renvoie au modèle. Là, on regarde trois choses : le bruit, les oublis et l’ordre. Le bruit, c’est quand le système remonte des chunks inutiles. Les oublis, c’est quand il rate une source importante. L’ordre compte aussi, parce qu’un chunk correct en position 12 ne sera peut-être jamais utilisé si le modèle ne lit que les 5 premiers.

La deuxième couche, c’est la generation quality. La question devient : est-ce que le modèle utilise correctement les chunks récupérés sans inventer ? Ici, on mesure la factualité, la groundedness et la fidélité au contexte. La groundedness veut dire que la réponse est bien “ancrée” dans les sources fournies. C’est un point critique, parce qu’un LLM peut écrire une réponse très crédible, très fluide, mais non supportée par les documents. Et c’est souvent là que le risque business commence.

La troisième couche, c’est la end-to-end quality. Là, je me mets côté utilisateur : est-ce que la réponse finale aide vraiment la personne ? Cette couche mélange plusieurs critères : pertinence, lisibilité, complétude, sécurité, respect de la demande. Une réponse peut être factuellement correcte mais trop vague, trop longue, ou inutilisable dans le contexte métier.

Les frameworks ne couvrent pas ces niveaux de la même façon. RAGAS, TruLens et DeepEval peuvent aider, mais le bon choix dépend surtout de trois choses : votre besoin d’automatisation, la présence ou non de réponses de référence, et le stade du produit. Un prototype n’a pas besoin du même niveau de contrôle qu’un chatbot en production utilisé par des clients.

Couche	Ce qu’elle détecte	Risque si on ne mesure pas
Retrieval quality	Bons chunks, bruit, oublis, mauvais ordre	Le modèle répond avec un mauvais contexte
Generation quality	Hallucinations, manque de fidélité, réponses non sourcées	Une réponse crédible mais fausse passe en production
End-to-end quality	Utilité réelle, clarté, complétude, sécurité	L’utilisateur n’est pas aidé, même si la technique semble correcte

Quelles métriques de retrieval suivre ?

Les métriques de retrieval à suivre en priorité sont Precision@K, Recall@K, MRR et NDCG. C’est la base pour savoir si votre moteur de recherche ramène les bons chunks avant même de juger la réponse du LLM.

Precision@K mesure la part de résultats pertinents dans les K premiers résultats. Si 3 chunks pertinents apparaissent dans les 5 premiers résultats, Precision@5 vaut 3/5, donc 0,6. Je l’utilise beaucoup pour détecter le bruit. Si votre Precision@5 est faible, ça veut dire que le contexte envoyé au LLM contient trop de contenu inutile. Et là, même un très bon modèle peut partir de travers.

Recall@K mesure la part des chunks pertinents retrouvés parmi tous ceux qui existent dans le corpus. Si 4 chunks pertinents existent dans la base documentaire et que 3 sont récupérés dans le top 5, Recall@5 vaut 3/4, donc 0,75. Le piège classique, c’est que quand on augmente K, le recall monte souvent, mais la precision peut baisser. On récupère plus de bons éléments, oui, mais aussi plus de bruit. J’ai vu ça chez un client sur une base de procédures internes : à K=20, on trouvait presque tout, mais le LLM recevait tellement de contexte moyen qu’il répondait moins bien.

MRR, pour Mean Reciprocal Rank, regarde à quel rang arrive le premier bon chunk. Plus il arrive haut, meilleur est le score. Si sur trois requêtes, les premiers chunks pertinents arrivent aux rangs 1, 2 et 4, le calcul moyen utilise 1/1, 1/2 et 1/4. C’est très utile quand une seule bonne source suffit souvent à répondre.

NDCG est plus fine, parce qu’elle accepte une pertinence graduée. Un chunk peut être très pertinent, partiellement utile, ou juste vaguement lié. NDCG pénalise aussi les documents utiles placés trop bas. C’est pratique quand tous les bons résultats ne se valent pas.

Ces métriques ne suffisent pas à juger toute la réponse RAG. Elles ne disent pas si le LLM formule bien, cite correctement, ou évite les hallucinations. Mais elles évitent déjà de lui demander de faire de la magie avec un mauvais contexte.

Métrique	Ce qu’elle mesure	Quand je l’utilise
Precision@K	La proportion de chunks pertinents dans le top K.	Quand je veux limiter le bruit envoyé au LLM.
Recall@K	La proportion des chunks pertinents retrouvés.	Quand je veux vérifier que le moteur ne rate pas l’information importante.
MRR	Le rang du premier chunk pertinent.	Quand une bonne source suffit souvent à répondre.
NDCG	La qualité du classement avec des niveaux de pertinence.	Quand je veux évaluer finement l’ordre des résultats.

RAGAS TruLens ou DeepEval ?

RAGAS est souvent pratique pour une évaluation RAG rapide et structurée, TruLens est intéressant quand je veux instrumenter et observer une application, DeepEval colle bien à une logique de tests automatisés et de CI, c’est-à-dire l’intégration continue.

RAGAS me plaît surtout quand il faut poser un cadre propre sans passer trois semaines à construire un banc de test maison. Il évalue notamment la context precision, donc est-ce que les passages récupérés sont vraiment utiles, le context recall, donc est-ce qu’on a bien récupéré les informations nécessaires, la fidélité, donc est-ce que la réponse reste alignée avec les sources, et la pertinence de réponse. Le point important, c’est qu’il ne cache pas tout dans un score magique. Il distingue la précision du contexte et le rappel du contexte, et ça change tout quand on débugge un chatbot RAG.

TruLens part d’une autre logique. Je l’utilise plutôt comme une couche d’observation autour de l’application LLM ou RAG. Son approche repose sur des feedback functions, des fonctions qui notent ou évaluent certains comportements. On peut suivre la pertinence du contexte, la pertinence de la réponse, le groundedness, c’est-à-dire le fait que la réponse soit bien ancrée dans les documents fournis. L’intérêt, c’est aussi de regarder ce qui se passe dans les appels, les traces, les étapes intermédiaires. Sur un projet client, c’est souvent là qu’on découvre que le problème ne vient pas du modèle, mais d’un mauvais chunking ou d’un retrieval trop large.

DeepEval est plus proche du test logiciel. On écrit des tests d’évaluation pour des cas RAG, on automatise des métriques, on compare des versions, et on peut brancher ça dans un workflow de validation. C’est utile quand l’équipe veut traiter l’évaluation comme une suite de tests reproductibles, un peu comme des tests unitaires, mais pour la qualité des réponses.

La lecture simple selon le stade du projet ressemble souvent à ça :

• Prototype : RAGAS aide à comprendre vite où ça casse.
• Pré-production : TruLens devient utile pour observer les traces et comprendre le comportement réel.
• Production : DeepEval prend du sens si l’équipe veut automatiser les validations à chaque changement.

Je ne dirais pas qu’un outil est meilleur dans l’absolu. Le bon choix dépend des références disponibles, du besoin d’automatisation, du volume de tests, de la surveillance continue et de la culture de l’équipe.

Framework	Approche	Points forts	Attention à garder	Cas d’usage typique
RAGAS	Évaluation structurée des composants RAG	Distingue context precision, context recall, fidélité et pertinence	Les scores restent à interpréter avec des exemples concrets	Comparer rapidement plusieurs versions d’un pipeline RAG
TruLens	Observation avec feedback functions et traces	Bon pour suivre contexte, réponse, groundedness et appels internes	Demande de bien instrumenter l’application	Comprendre le comportement d’une app RAG en pré-production
DeepEval	Tests automatisés proches du logiciel	Reproductible, intégrable dans une CI, pratique pour comparer des versions	Il faut maintenir les cas de test et les critères	Valider une release avant déploiement

Comment éviter les faux bons scores ?

On évite les faux bons scores en séparant clairement le retrieval et la génération, en gardant des jeux de test propres, et en surveillant les résultats dans le temps. Le retrieval, c’est la partie qui va chercher les bons morceaux de documents. La génération, c’est le modèle LLM, donc le modèle de langage, qui rédige la réponse finale.

Le piège classique, je le vois souvent chez des clients, c’est de dire “la réponse est bonne, donc le RAG marche”. Pas forcément. Le modèle peut avoir répondu correctement avec un mauvais contexte, juste parce qu’il connaît déjà le sujet ou parce que la question était trop simple. Ça donne un score rassurant, mais fragile.

Les faux bons scores viennent souvent des mêmes erreurs.

• Confondre une bonne réponse finale avec un bon retrieval. Le chatbot peut bien répondre même si les sources remontées sont mauvaises.
• Évaluer uniquement sur quelques exemples faciles. Dix questions évidentes ne prouvent pas grand-chose.
• Utiliser une seule métrique globale. Une moyenne cache très bien les échecs dangereux.
• Ignorer la qualité des chunks. Un chunk, c’est un morceau de document découpé pour être indexé. S’il est trop court, trop long ou mal coupé, le retrieval devient bancal.
• Oublier les requêtes ambiguës. En production, les utilisateurs ne posent pas toujours des questions propres.
• Ne pas tester les cas où la bonne réponse est “je ne sais pas”. C’est souvent là qu’on détecte les hallucinations.

Un système RAG peut régresser dès qu’on touche à un paramètre. Changer le modèle d’embedding, donc le modèle qui transforme les textes en vecteurs comparables, peut modifier les documents retrouvés. Changer le chunking, le top K, c’est-à-dire le nombre de passages récupérés, le reranking, donc le tri secondaire des résultats, le prompt ou le modèle LLM peut aussi casser un équilibre qui semblait bon. Ce n’est pas grave en soi, mais il faut le mesurer.

Chez un client, je partirais simple. Je créerais un petit jeu de questions critiques, pas énorme, mais représentatif des vrais risques métier. Je mesurerais séparément le retrieval avec des métriques comme la présence de la bonne source dans les résultats. Je mesurerais aussi la génération avec la fidélité à la source, la complétude et la capacité à refuser quand l’information manque. Puis je garderais quelques vérifications humaines régulières. Pas besoin de comité de 12 personnes, juste des revues courtes et utiles. Ensuite, je surveillerais la production avec les traces, les questions réelles, les clics, les retours utilisateurs et les cas signalés.

• Vérifier les sources utilisées pour produire la réponse.
• Comparer les versions avant et après chaque modification.
• Isoler les causes d’échec entre retrieval, chunking, prompt et génération.
• Surveiller les hallucinations surtout sur les questions sans réponse dans la base.
• Relancer les tests après chaque changement important.

Vous mesurez vraiment votre RAG ou juste ses belles réponses ?

L’évaluation RAG ne peut pas se résumer à une note jolie dans un dashboard. Il faut regarder le retrieval, la génération et la réponse finale, sinon on ne sait pas où le système casse. Precision@K, Recall@K, MRR et NDCG aident à comprendre la qualité des chunks récupérés. RAGAS, TruLens et DeepEval apportent chacun une façon différente de tester, diagnostiquer ou surveiller. Mon conseil reste simple : choisissez selon votre stade produit, pas selon la popularité de l’outil. Le bénéfice pour vous, c’est un RAG plus fiable, plus explicable et plus facile à améliorer.

FAQ

• Qu’est-ce que l’évaluation RAG mesure concrètement ? Elle mesure si le système retrouve les bons documents, si le LLM utilise correctement ce contexte, et si la réponse finale répond vraiment à la demande utilisateur. Les trois niveaux comptent, sinon on risque de valider une réponse agréable mais mal sourcée.
• Pourquoi les métriques BLEU et ROUGE sont limitées pour un RAG ? Elles comparent surtout des mots avec une réponse de référence. Ça peut être utile dans certains cas, mais ça ne dit pas si les bons chunks ont été récupérés, ni si le modèle a halluciné malgré un contexte correct.
• Quelle est la différence entre Precision@K et Recall@K ? Precision@K regarde la proportion de résultats pertinents dans les K premiers chunks. Recall@K regarde la part des chunks pertinents du corpus qui ont été retrouvés dans ces K résultats. La precision limite le bruit, le recall limite les oublis.
• RAGAS, TruLens ou DeepEval lequel choisir ? RAGAS est pratique pour structurer rapidement des métriques RAG comme context precision et context recall. TruLens aide à observer et instrumenter une application RAG. DeepEval est intéressant si vous voulez intégrer l’évaluation dans une logique de tests automatisés.
• Faut-il surveiller un RAG après sa mise en production ? Oui, parce qu’un RAG peut régresser après un changement de chunking, d’embedding model, de prompt, de top K ou de modèle LLM. Le suivi continu permet de repérer les hallucinations, les mauvaises sources et les pertes de qualité avant que les utilisateurs ne les subissent.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Avec mon agence webAnalyste et mon organisme Formations Analytics, j’accompagne des équipes qui veulent mettre de la mesure propre derrière leurs systèmes IA, pas juste brancher un modèle et espérer que ça tienne. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez fiabiliser vos projets IA ou RAG, je suis dispo, contactez-moi.