Ragas : évaluer son RAG local avec des chiffres

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

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.

#Les quatre mesures qui comptent

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
2. 02
   Écrire la réponse attendue
3. 03
   Garder les cas sans réponse
4. 04
   Figer le jeu

#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é. Par défaut la bibliothèque attend un fournisseur distant, mais ces deux composants se remplacent par des modèles locaux servis par Ollama ou par un point d'accès compatible OpenAI.

Deux conditions pour que le juge local soit crédible : un modèle suffisamment grand — en dessous de 14 milliards de paramètres, les jugements deviennent instables et le format de sortie casse — et une fenêtre de contexte assez large pour contenir la question, les passages et la réponse en une seule fois. 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

#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

Un modèle qui évalue d'autres modèles préfère les réponses longues et bien tournées. 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 relève 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.

#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.

#FAQ