Ragas : évaluer son RAG local avec des chiffres

#Pourquoi « ça a l'air bien » ne suffit pas

Ragas est une bibliothèque Python open source, sous licence Apache 2.0, qui met des chiffres sur la qualité d'une chaîne de recherche documentaire : la fidélité de la réponse aux passages fournis, sa pertinence par rapport à la question, la précision et le rappel du contexte récupéré. Elle sépare ainsi la faute de la recherche de celle du modèle. Elle peut tourner avec un juge local, servi par Ollama, à condition que ce modèle respecte le format de sortie structurée que Ragas lui impose et que son contexte contienne toute la question, les passages et la réponse. Avant de l'adopter, retenez trois points : ses scores servent à comparer deux versions d'un même système, pas à noter une qualité absolue ; le jeu de test compte plus que la bibliothèque ; et les tutoriels en ligne mélangent l'ancienne et la nouvelle API.

Quand une réponse est fausse, deux causes très différentes se cachent derrière le même symptôme : soit les passages récupérés ne contenaient pas l'information, soit ils la contenaient et le modèle a répondu à côté. La correction n'est pas la même — découpage et embeddings dans le premier cas, modèle et prompt dans le second. Sans mesure, on corrige au hasard, et une amélioration sur trois questions en dégrade cinq autres sans qu'on le voie.

L'autre écueil est la comparaison. « Le modèle de 27 milliards de paramètres est-il vraiment meilleur ici ? » se tranche en rejouant le même jeu de questions, pas en discutant. C'est ce que rend possible une évaluation reproductible. Ragas dépasse les 15 000 étoiles sur GitHub. La dernière version publiée sur PyPI est la 0.4.3, du 13 janvier 2026, et le dépôt a changé d'organisation GitHub (vibrantlabsai). Épinglez la version que vous utilisez.

#Les quatre mesures qui comptent

La documentation de Ragas précise que la pertinence de la réponse ne juge pas l'exactitude : elle mesure seulement l'adéquation à la question, et pénalise les réponses incomplètes ou pleines de détails inutiles. C'est pourquoi elle ne remplace pas la fidélité. La lecture croisée est ce qui rend ces chiffres utiles. Un rappel faible avec une fidélité élevée décrit un système honnête mais mal alimenté : il faut travailler la récupération. Une fidélité faible avec un bon rappel décrit l'inverse : l'information était là, le modèle a brodé. Les deux se corrigent à des endroits opposés de la chaîne.

#Construire un jeu de test

C'est la partie qui demande du travail, et elle n'est pas automatisable sans conséquence. Un jeu utile contient des questions réellement posées par les utilisateurs, avec leurs formulations maladroites, leurs abréviations maison et leurs fautes de frappe — pas des questions reformulées proprement par la personne qui a écrit la documentation.

1. 01
   Partir des vraies questions

   Trente à cinquante questions issues de l'usage réel valent mieux que deux cents questions inventées. Incluez celles qui ont échoué : ce sont les plus instructives.
2. 02
   Écrire la réponse de référence

   Pour chaque question, la réponse correcte, rédigée en une ou deux phrases. Ragas s'en sert pour estimer le rappel du contexte : la version fondée sur un LLM prend cette référence comme substitut des passages attendus, ce qui évite d'annoter les passages un par un.
3. 03
   Garder les cas sans réponse

   Des questions auxquelles le corpus ne répond pas. Un bon système doit le dire ; sans ces cas, on ne mesure jamais cette qualité-là.
4. 04
   Figer le jeu

   Il ne doit pas évoluer en même temps que le système, sinon aucune comparaison n'est possible dans le temps.

Ragas propose aussi une génération assistée de jeux de test synthétiques, à partir du corpus lui-même : la documentation distingue les questions à un saut (une seule source) des questions à plusieurs sauts (plusieurs sources à relier), spécifiques ou abstraites. Un guide officiel montre comment l'adapter à un corpus non anglophone, l'exemple traité étant l'espagnol, pour amorcer une première évaluation avant que les vraies questions des utilisateurs n'aient eu le temps de s'accumuler. C'est un point de départ commode, jamais un substitut : un jeu entièrement synthétique manque les formulations maladroites et les fautes de frappe qui, précisément, révèlent les faiblesses réelles d'une recherche documentaire.

#Tout faire tourner en local

Ragas s'appuie sur deux modèles pour évaluer : un modèle juge qui lit la question, les passages et la réponse, et un modèle d'embedding pour les mesures de similarité. Le quickstart de Ragas utilise OpenAI par défaut, mais montre la variante Ollama : un client compatible OpenAI pointé sur http://localhost:11434/v1, passé à la fonction llm_factory. Seule la pertinence de la réponse exige un modèle d'embedding : fidélité, précision et rappel du contexte n'utilisent que le juge.

Deux conditions pour que le juge local soit crédible. La première est la sortie structurée : les métriques actuelles demandent au juge des décisions intermédiaires dans un format imposé (extraction des affirmations, verdicts). Un modèle local peut répondre en prose et échouer à ce contrat, ce qui produit des erreurs de JSON ou des scores vides (NaN) ; un guide de OneUptime conseille de tester le juge sur un appel minuscule avant toute campagne. Aucune source officielle ne fixe une taille minimale de modèle : c'est à vous de le vérifier. La seconde est le contexte : Ollama applique par défaut 4 000 tokens de contexte en dessous de 24 Gio de VRAM, et la documentation conseille d'augmenter la valeur (variable OLLAMA_CONTEXT_LENGTH) pour les tâches lourdes. Un juge dont le contexte déborde note en réalité un texte tronqué.

• Construire la chaîne RAG que vous allez évaluer
• Choisir un modèle d'embedding pour le français
• Ajouter un reranker quand la précision du contexte est faible
• Langfuse : tracer et stocker les scores obtenus

# pip install ragas openai
from openai import AsyncOpenAI
from ragas.llms import llm_factory
from ragas.metrics.collections import Faithfulness, ContextRecall

# Client compatible OpenAI pointé sur Ollama (la clé est un simple libellé)
client = AsyncOpenAI(api_key="ollama", base_url="http://localhost:11434/v1")
juge = llm_factory("mistral", provider="openai", client=client)  # nom du modèle tiré avec ollama pull

fidelite = Faithfulness(llm=juge)
resultat = fidelite.score(
    user_input="Où se trouve la tour Eiffel ?",
    response="La tour Eiffel se trouve à Paris.",
    retrieved_contexts=["La tour Eiffel est située à Paris, en France."],
)
print(resultat.value)  # entre 0 et 1

#Lire les résultats sans se tromper

Ce sont des indicateurs, pas des notes

Une fidélité de 0,82 ne signifie pas « 82 % de bonnes réponses ». Ce chiffre sert à comparer deux versions du même système, pas à certifier une qualité absolue.

Le juge a des biais

L'article de référence sur les juges LLM (arXiv 2306.05685) décrit des biais de position, de verbosité et d'auto-préférence. Gardez le même juge d'une campagne à l'autre, sinon les écarts mesurent le juge et non le système.

Une seule campagne ne prouve rien

La génération est variable. Sur un petit jeu de test, un écart de quelques centièmes peut relever du bruit.

Lisez quelques cas à la main

Les chiffres disent où regarder ; ils ne disent pas ce qui cloche. Les dix pires cas d'une campagne apprennent plus que la moyenne générale.

#Cas d'usage concrets

Choisir une taille de découpage

Rejouer le même jeu de test avec des morceaux de 256, 512 puis 1024 tokens donne un chiffre de rappel par configuration, plutôt qu'une préférence non vérifiée.

Valider un changement de modèle d'embedding

Un nouveau modèle d'embedding, même annoncé meilleur sur un benchmark général, peut dégrader la précision du contexte sur votre corpus précis ; seule une campagne locale le montre.

Justifier l'ajout d'un reranker

Comparer la précision du contexte avant et après reranking chiffre un gain qui, sinon, reste une impression partagée en réunion.

Suivre une régression après mise à jour du corpus

L'ajout de nouveaux documents peut diluer la recherche ; rejouer le jeu de test figé après chaque import détecte la dégradation avant qu'un utilisateur ne la signale.

Arbitrer entre deux prestataires ou architectures

Face à deux propositions concurrentes pour bâtir une même chaîne documentaire, un score obtenu sur le même jeu de test et le même corpus tranche plus vite qu'une démonstration commerciale.

#Organiser les campagnes

Fréquence des campagnes

Après chaque changement de découpage, de modèle d'embedding ou de modèle de génération. Pas besoin d'une campagne quotidienne sur un système stable.

Taille du corpus de test

Le jeu de questions reste petit ; c'est le corpus documentaire évalué, lui, qui doit être une copie réaliste — ou la totalité — du corpus de production.

Coût réel d'une campagne

Chaque métrique appelle le juge plusieurs fois (pour la fidélité : extraction des affirmations, puis vérification de chacune). Le coût croît donc avec le nombre de questions multiplié par le nombre de métriques : chronométrez cinq questions avant de lancer les cinquante, puis planifiez la campagne en conséquence.

#Les limites de la méthode

Évaluer avec un modèle revient à demander à une intelligence artificielle de juger une autre intelligence artificielle : la méthode est utile, économique et imparfaite. Elle détecte les régressions et classe des variantes ; elle ne remplace pas la relecture humaine sur un domaine à enjeu, où une erreur factuelle engage une responsabilité. Enfin, chaque campagne consomme du temps de calcul : sur une machine qui sert aussi les utilisateurs, on la lance quand la charge est basse, la nuit ou un week-end plutôt qu'en pleine heure d'usage.

Le biais de verbosité mérite un mot de plus, parce qu'il est contre-intuitif. Un article de OneUptime explique qu'un juge a plus d'occasions, dans une réponse longue, de citer les mots-clés de la grille, de paraître exhaustif et d'avancer une justification convaincante. Un prompt qui pousse le modèle évalué à être plus bavard peut donc faire grimper un score sans améliorer la réponse de l'utilisateur. Pour la fidélité, la documentation de Ragas mentionne aussi une variante appuyée sur HHEM-2.1-Open, un petit classificateur gratuit de détection d'hallucinations de Vectara : il remplace l'étape de vérification par un modèle spécialisé, à essayer si votre juge local est instable.

La parade la plus simple est méthodologique : ne jamais comparer un score de fidélité obtenu avec un juge à un score obtenu avec un autre, ni à un score publié par un tiers. Le chiffre n'a de sens qu'à l'intérieur d'une même configuration de mesure — même juge, même prompt d'évaluation, même version des métriques. C'est un outil de comparaison interne, pas un classement universel.

• Source : dépôt officiel Ragas sur GitHub
• Source : biais de verbosité des juges automatiques
• Source : documentation officielle de la métrique de fidélité
• Source : quickstart Ragas, variante Ollama
• Source : longueur de contexte par défaut d'Ollama
• Source : évaluer un RAG avec un juge local qui produit du JSON invalide
• Source : article de référence sur les juges LLM

#FAQ