Évaluer un RAG : Ragas, Langfuse ou notation binaire ?

Pour évaluer un RAG, trois choses sont souvent mises sur le même plan alors qu'elles ne répondent pas à la même question. Ragas calcule des métriques (faithfulness, context precision, answer relevancy) à l'aide d'un LLM juge. Langfuse fournit l'infrastructure : traces, datasets, scores, annotation humaine. La notation binaire (juste ou pas juste, sur des questions réelles) donne le chiffre qui permet de décider d'une mise en production.

La méthode que j'applique sur nos projets combine les trois, dans cet ordre : un jeu de questions réelles, une notation binaire, le retrieval et la génération mesurés séparément, un LLM as a judge calibré sur des notes humaines, et un rejeu complet avant chaque mise en production. Les outils automatisent la méthode. Ils ne la remplacent pas.

Cet article s'adresse aux CTO, lead devs et équipes data qui ont un RAG en production ou en recette. Pour le panorama de l'architecture, voir notre guide du RAG en entreprise. Les fonctions des outils citées ici viennent de la documentation de Ragas et de Langfuse, relue le 5 novembre 2026.

Que mesurent les métriques Ragas ?

Ragas est une bibliothèque Python open source qui note un pipeline RAG à partir de triplets question, contexte récupéré, réponse, avec parfois une réponse de référence. Ses métriques principales séparent le retrieval (a-t-on récupéré les bons passages ?) de la génération (la réponse s'appuie-t-elle sur ces passages ?). La plupart sont calculées par un LLM juge, comme le décrit le papier d'origine de Ragas (Es et al., 2023).

Les métriques du retrieval

La context precision et le context recall regardent uniquement ce que la recherche a ramené. Un recall bas signifie que l'information n'était pas dans les passages : aucun prompt ne corrigera ça. Ragas propose plusieurs variantes de la context precision : avec juge LLM et réponse de référence, avec juge LLM sans référence, sans LLM (similarité de texte), ou par comparaison d'identifiants de documents.

Les métriques de la génération

La faithfulness et la response relevancy jugent la réponse. La première mesure la fidélité au contexte, la seconde l'adéquation à la question. Aucune des deux ne vérifie que la réponse est juste au sens du métier, point sur lequel on revient plus bas.

À quoi ressemble un appel

Dans les versions récentes, chaque métrique s'instancie avec un LLM juge et se calcule sur un échantillon, selon la documentation des métriques disponibles de Ragas :

from openai import AsyncOpenAI
from ragas.llms import llm_factory
from ragas.metrics.collections import ContextPrecision

llm = llm_factory("gpt-4o-mini", client=AsyncOpenAI())
scorer = ContextPrecision(llm=llm)

result = await scorer.ascore(
    user_input="Quel est le délai de prévenance pour un congé sans solde ?",
    reference="Deux mois avant la date de départ.",
    retrieved_contexts=[passage_1, passage_2, passage_3],
)
print(result.value)  # un nombre entre 0 et 1

La dernière ligne résume la suite : un nombre entre 0 et 1. Reste à savoir ce qu'on en fait.

Les limites des scores Ragas en production

Les scores Ragas sont continus et produits par un LLM. Les deux propriétés posent problème quand il faut décider si un assistant part en production : un 0,82 de faithfulness ne dit pas combien d'utilisateurs ont reçu une réponse fausse, et le même calcul relancé avec un autre juge ne donne pas le même chiffre.

Un score continu difficile à interpréter

Prenons une réponse de cinq affirmations, dont quatre sont soutenues par le contexte. Faithfulness : 0,8. Si l'affirmation non soutenue est le délai ou le montant que l'utilisateur cherchait, la réponse est inutilisable. Le score moyen sur un jeu de test agrège ces cas avec des réponses parfaites et produit un chiffre que personne, côté métier, ne sait lire.

D'autres cas trompent dans l'autre sens :

• Faithfulness à 1 sur une réponse fausse. Si le retrieval ramène l'ancienne version d'une procédure, une réponse fidèle à ce passage obtient le score maximal. Elle est fidèle au contexte, et fausse.
• Response relevancy basse sur la bonne réponse. Sur une question dont la réponse n'existe pas dans les documents, « l'information ne figure pas dans la base » est la réponse attendue. La métrique pénalise les réponses non engagées.
• Questions synthétiques. Un jeu de test généré à partir des documents ressemble aux documents, pas aux questions des utilisateurs, qui sont imprécises, multi-documents ou hors périmètre.

Un juge LLM bruité

Chaque métrique dépend du modèle juge, de sa version et de son prompt. Deux exécutions sur le même jeu peuvent donner des scores différents, et changer de juge entre deux mesures rend la comparaison caduque. Les biais des juges LLM sont documentés : l'étude « Judging LLM-as-a-Judge » (Zheng et al., 2023) décrit le biais de position, la préférence pour les réponses longues et la tendance d'un modèle à favoriser ses propres réponses.

Ragas reste utile. Un context recall qui s'effondre après un changement de découpage, c'est un signal clair. Ragas propose aussi un AspectCritic qui rend un verdict binaire sur un critère écrit en langage naturel, plus proche de ce qu'on cherche. Mais le chiffre qui sert à décider d'une mise en production doit venir d'une notation que le métier comprend et qu'un humain peut vérifier.

Ce que Langfuse apporte, et ce qu'il n'est pas

Langfuse est une plateforme open source d'observabilité et d'évaluation pour applications LLM. Pour évaluer un RAG, elle apporte quatre briques : les traces de chaque exécution, les datasets de questions, les experiments qui comparent deux versions sur le même dataset, et les scores, saisis à la main, calculés en code ou produits par un LLM as a judge. Langfuse n'est pas une métrique : il ne dit pas ce qu'est une bonne réponse.

D'après la documentation d'évaluation de Langfuse, les fonctions utiles à un RAG sont les suivantes :

• Scores typés. Numériques, catégoriels, booléens (1 ou 0) ou texte, attachés à une trace, à une étape (observation) ou à une session. Les score configs imposent un nom, un type et des valeurs autorisées, ce qui évite qu'un même critère soit noté de trois façons.
• Datasets et experiments. Le jeu de questions est versionné dans l'outil, et chaque version du pipeline produit un run comparable au précédent.
• LLM as a judge. Des évaluateurs configurables notent automatiquement des traces de production ou les runs d'un dataset.
• Annotation queues. Un expert métier note des traces dans l'interface, sans toucher au code. Ce sont ces notes qui servent à calibrer le juge.
• Intégration CI. Un experiment lancé dans la chaîne de déploiement peut bloquer une mise en production en cas de régression.

Le type booléen colle à la notation binaire. Un verdict se pousse en une ligne avec le SDK Python :

from langfuse import get_client

langfuse = get_client()
langfuse.create_score(
    trace_id=trace_id,
    name="reponse_juste",
    value=1 if verdict.juste else 0,
    data_type="BOOLEAN",
    comment=verdict.justification,
)

Ce que Langfuse ne fait pas : choisir les questions, écrire la réponse attendue, définir le critère de justesse, calibrer son propre juge. Son évaluateur LLM as a judge est un juge comme un autre, qui demande la même calibration. L'installation et les traces sont détaillées dans notre article Langfuse, observabilité LLM open source, et la comparaison avec DeepEval, LangSmith ou Phoenix dans le comparatif des outils d'évaluation et d'observabilité des LLM.

La notation binaire : la méthode qu'on applique

La méthode tient en une phrase : un jeu de questions réelles, chacune notée juste ou pas juste, avec le retrieval mesuré à part de la génération. Elle donne un pourcentage de performance dès le début du projet, et c'est ce pourcentage qui pilote la suite.

Le jeu de questions

On démarre avec 20 à 50 questions, prêtes dès les 2 à 3 premiers jours. Le jeu s'empile ensuite : pendant les tests, toutes les questions des utilisateurs sont reprises dans l'évaluation. Chaque entrée porte trois champs : la question, la réponse attendue, et le ou les documents où elle se trouve. Ce troisième champ est celui qu'on oublie, et c'est lui qui permet de diagnostiquer.

Juste, complète, fausse

On suit trois pourcentages, chacun en binaire : réponses justes, réponses complètes, réponses fausses. Pas de note de 1 à 5, peu pertinente : deux relecteurs ne mettent pas le même 3, et un 3 ne dit pas quoi corriger. La question binaire a un autre avantage : elle se calibre entre un humain et un juge, ce qu'une échelle à cinq niveaux rend très difficile. La logique côté décideur (pourquoi mesurer, ce que montre la première mesure) est détaillée dans notre article sur la mesure de la performance d'un RAG.

Séparer retrieval et génération

Pour chaque question, on vérifie d'abord, en binaire aussi, si le document attendu figure parmi les passages récupérés. Croisé avec le verdict sur la réponse, ce contrôle classe l'erreur sans juge supplémentaire :

En audit, cette séparation fait apparaître le cas le plus fréquent : des bugs dans la chaîne de traitement, pas le modèle. Trois exemples réels :

• un modèle d'embeddings différent à l'indexation et à la recherche, ce qui fausse toute la recherche ;
• un seul chunk extrait par mégarde, au lieu de plusieurs ;
• une recherche qui ne prend en compte que le dernier message au lieu de toute la conversation.

Aucun de ces bugs ne se voit dans une faithfulness moyenne. Tous se voient dès qu'on regarde, question par question, si le bon document est remonté.

Comment calibrer un LLM as a judge sur des notes humaines ?

Un LLM as a judge se calibre comme un instrument de mesure : on le compare à une référence humaine, on corrige ses écarts, et on ne l'utilise seul qu'une fois l'accord jugé suffisant par le métier. Sans cette étape, on remplace une impression humaine par une impression automatisée.

Le prompt du juge

Le juge reçoit la question, la réponse attendue et la réponse de l'assistant. Il rend une justification courte, puis un verdict booléen, en sortie structurée. Le critère est écrit noir sur blanc, avec les cas limites tranchés :

from pydantic import BaseModel

class Verdict(BaseModel):
    justification: str
    juste: bool

def prompt_juge(question, attendue, reponse):
    return f"""Compare la réponse de l'assistant à la réponse attendue.
Question : {question}
Réponse attendue : {attendue}
Réponse de l'assistant : {reponse}

La réponse est juste si elle ne contient aucune erreur ni
contradiction avec la réponse attendue. Une réponse exacte mais
incomplète reste juste (la complétude est notée à part).
Si l'information n'existe pas, « je ne sais pas » est juste.
Écris une justification courte, puis le verdict."""

Demander la justification avant le verdict rend chaque désaccord lisible : on voit pourquoi le juge a tranché, et donc quelle phrase du critère corriger.

Mesurer l'accord avec l'humain

Un expert du métier note un échantillon de réponses (dans Langfuse, via une annotation queue). Le juge note les mêmes. On compare :

# notes_humaines, notes_juge : dict question_id -> bool
communes = notes_humaines.keys() & notes_juge.keys()
accord = sum(notes_humaines[q] == notes_juge[q] for q in communes) / len(communes)
desaccords = [q for q in communes if notes_humaines[q] != notes_juge[q]]

Chaque désaccord est relu. Soit le critère était flou et on le précise, soit l'humain s'est trompé et on corrige la référence. On recommence jusqu'à ce que l'accord convienne au métier. Le modèle juge, sa version et son prompt sont ensuite figés : en changer revient à changer d'instrument, et oblige à recalibrer.

Où garder l'humain

Les réponses fausses sur des sujets à risque (montant, délai, conformité), les nouvelles familles de questions et un échantillon régulier de verdicts du juge restent relus par un humain. Le juge prend le volume, l'humain garde la référence. Pour les métriques d'un LLM hors RAG (classification, extraction, rédaction), voir notre article sur l'évaluation d'un LLM en entreprise.

Tests de régression avant chaque mise en production

Le jeu de questions complet se rejoue avant chaque mise en production : changement de modèle, de prompt, de découpage, de source documentaire ou de fonctionnalité. Sans ce rejeu, on ne sait pas si une modification améliore l'assistant ou le dégrade, et c'est la situation la plus fréquente quand on reprend un RAG existant.

La comparaison se fait question par question, pas seulement sur le pourcentage global. Un score stable peut cacher dix questions gagnées et dix perdues, et les perdues sont souvent celles qu'un utilisateur avait signalées.

regressions = [q for q in jeu if avant[q] and not apres[q]]
gains = [q for q in jeu if apres[q] and not avant[q]]
# Toute régression est relue avant la mise en production.

Ce que montrent les chiffres

Un RAG basique répond correctement à 50 à 70 % des questions. Le résultat de la première mesure surprend régulièrement le client. Après les premières corrections, qui portent surtout sur des bugs de la chaîne de traitement, voici les trajectoires observées sur nos projets :

• de 30 % à 70 % de réponses justes ;
• de 50 % à 70 % ;
• de 20 % à 50 % sur des cas d'usage complexes.

Ce que la mesure fait trancher

Sur un projet réel, l'ordre a été le suivant : évaluation et correction des petits bugs, collecte des retours des utilisateurs test, parsing, chunking, recherche hybride, puis reranking. Le reranking faisait passer la note de 89 % à 92 %. Il n'a pas été retenu : ce cas d'usage avait besoin d'un temps de réponse court, et trois points ne justifiaient pas l'attente supplémentaire. Le détail étape par étape est dans notre article sur l'ordre d'amélioration d'un RAG.

La mesure sert aussi à écarter. En expérimentation, plusieurs pistes n'ont rien apporté, dont le passage en agentic RAG. Sans jeu de test, ces pistes partent en production sur une intuition. Avec, elles se testent en quelques runs et se rejettent sur un chiffre.

Si votre RAG tourne sans jeu de test ni score de référence, c'est le point de départ de notre audit RAG et agents IA : on construit le jeu de questions sur vos documents, on pose la mesure binaire, et on vous remet le premier score avec les causes d'erreur classées.

Questions fréquentes sur l'évaluation d'un RAG avec Ragas et Langfuse

Pour aller plus loin

• Pipeline RAG en production
• Langfuse : observabilité LLM open source, guide pour PME
• Outils d'évaluation et d'observabilité des LLM
• Mesurer la performance d'un RAG : ce qu'on voit en mission
• Améliorer un RAG : pourquoi on a renoncé au reranking
• Sur ianas.fr, le protocole technique : évaluer un RAG en production avec les métriques Ragas

Sources consultées le 5 novembre 2026 : documentation des métriques Ragas, documentation d'évaluation Langfuse, Es et al., 2023 et Zheng et al., 2023.