RAGAS : mesurer objectivement la qualité d’un pipeline RAG en open source
Un pipeline RAG (Retrieval-Augmented Generation) bien conçu repose sur une dizaine de leviers : choix de l’embedding, taille des chunks, stratégie de découpage, reranker, modèle de génération, prompt, fenêtre de contexte. Quand l’un de ces leviers bouge, comment savoir si la qualité progresse vraiment, ou si l’on déplace simplement les erreurs ? RAGAS (Retrieval-Augmented Generation Assessment) est la réponse open source qui s’est imposée pour cette question : un framework Python sous licence Apache 2.0 qui produit des métriques chiffrées, comparables, sur la fidélité, la pertinence et la précision contextuelle des réponses générées. C’est le chaînon manquant entre une démo qui marche bien sur trois questions et un système RAG mis en production avec confiance.
Le problème de fond : un RAG qui semble bon n’est pas forcément bon
Les bugs les plus coûteux d’un RAG ne se voient pas à l’œil nu. Le modèle peut produire une réponse fluide qui n’utilise pas du tout les passages récupérés (faible faithfulness), ou s’appuyer sur un passage hors-sujet en répondant juste par chance, ou rater systématiquement les questions où la réponse est dispersée dans plusieurs documents. Sans métrique, on optimise à l’aveugle : on change le top-k, on ajoute un reranker, on gonfle le prompt système, et l’on confond amélioration ressentie sur quelques exemples avec amélioration réelle. Le coût est connu : régression silencieuse en production, perte de confiance utilisateur, démarche d’amélioration impossible à objectiver auprès d’un commanditaire.
Les métriques que RAGAS apporte
RAGAS découpe l’évaluation en métriques orthogonales, chacune mesurant un défaut différent du pipeline :
- Faithfulness : la réponse est-elle effectivement étayée par les passages récupérés, ou le modèle hallucine-t-il ? Métrique critique pour des SI publics ou réglementés.
- Answer relevancy : la réponse traite-t-elle réellement la question posée, ou divague-t-elle ?
- Context precision : parmi les passages remontés, lesquels étaient utiles ? Mesure indirectement la qualité du retriever et du reranker.
- Context recall : a-t-on remonté tous les passages nécessaires pour répondre ? Détecte les questions multi-documents mal couvertes.
- Answer correctness : la réponse correspond-elle à la vérité de référence (en présence d’un jeu de tests annoté) ?
- Noise sensitivity et response relevancy : robustesse face à des passages distracteurs.
Chaque métrique est un score entre 0 et 1, calculé pour chaque question, agrégé pour l’ensemble du jeu de tests. La combinaison faithfulness + context precision + answer relevancy suffit dans 80 % des cas pour comparer deux versions d’un pipeline.
Comment ça calcule, concrètement
RAGAS s’appuie sur un LLM juge : pour chaque question et chaque réponse, le framework appelle un modèle (par défaut OpenAI, mais on peut brancher Claude, un Llama local servi par vLLM, Mistral via LiteLLM, etc.) à qui l’on demande, par exemple, de décomposer la réponse en affirmations et de vérifier laquelle est appuyée par le contexte. Cette approche dite LLM-as-a-judge n’est pas parfaite (il faut idéalement un modèle juge plus puissant que le modèle évalué), mais elle a l’avantage d’éviter d’avoir à annoter manuellement des milliers d’exemples. Pour des secteurs sensibles, on combine RAGAS avec un petit échantillon noté à la main pour calibrer.
Mise en route en quelques lignes
L’installation est triviale : pip install ragas. On constitue ensuite un jeu d’évaluation au format Hugging Face Datasets ou simple liste de dictionnaires, avec quatre champs par exemple : question, contexts (les passages remontés par le retriever), answer (réponse du système), et optionnellement ground_truth.
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision
resultats = evaluate(
dataset=mon_jeu_test,
metrics=[faithfulness, answer_relevancy, context_precision],
llm=mon_juge, # ex : Claude Sonnet via litellm
embeddings=mes_embeddings,
)
print(resultats)Le résultat est un DataFrame pandas que l’on peut versionner, comparer entre deux runs, ou pousser dans un dashboard. RAGAS s’intègre nativement avec Langfuse, ce qui permet d’évaluer en continu sur des traces de production réelles, et avec Hugging Face Datasets pour la constitution de jeux de tests réutilisables.
Constituer son jeu de tests sans y passer un mois
La pierre d’achoppement classique d’un projet d’évaluation, c’est le jeu de questions. RAGAS propose un module de génération synthétique qui parcourt un corpus, en extrait des questions plausibles à différents niveaux de difficulté (simple, raisonnement, multi-contextes), et produit la vérité de référence associée. On obtient en quelques heures un jeu de 100 à 500 questions exploitable, qu’il reste à filtrer manuellement pour écarter les questions mal formées. Cette approche est imparfaite mais bien plus efficiente que d’annoter à froid, et permet de bootstrapper l’évaluation dès la phase POC.
L’ancrage côté Askem : ce que ça change dans un projet RAG
RAGAS permet de transformer trois conversations difficiles en exercices objectivables :
- Décider des arbitrages techniques : passer de pgvector à Qdrant, ajouter un reranker BGE, passer de chunks de 512 à 1024 tokens — chaque hypothèse devient un test mesurable, pas une intuition.
- Choisir un modèle : comparer Claude, Mistral, Llama et Qwen sur le même jeu, le même contexte, le même prompt, et publier le tableau résultant. Le débat sort du registre des opinions.
- Garantir la non-régression : intégrer RAGAS dans la CI au même titre que les tests unitaires. Une mise à jour de prompt qui dégrade la faithfulness de 5 points devient bloquante avant la mise en prod.
Limites et compléments
RAGAS reste un outil statistique : il évalue un comportement moyen, pas la conformité ligne à ligne. Pour des secteurs où chaque réponse doit être tracée et défendable, il faut le combiner avec des garde-fous d’exécution (NeMo Guardrails, Guardrails AI), une journalisation complète (Langfuse), et une revue humaine ciblée sur les cas à faible faithfulness. À noter aussi : DeepEval et Promptfoo sont deux alternatives open source pertinentes à connaître, le premier proche de RAGAS dans l’esprit, le second plus orienté tests de prompts façon pytest.
Ce qu’il faut retenir
On ne pilote pas ce qu’on ne mesure pas. RAGAS donne, en quelques lignes de Python et sans dépendance cloud, les métriques objectives qui transforment un pipeline RAG bricolé en système maîtrisé. C’est l’un des outils à intégrer dès la phase POC, pas après la mise en production.
