Évaluer la qualité d'un RAG : les métriques qui comptent

Un système RAG assemble une base de connaissances, un modèle d’embedding, une recherche et un LLM. Chaque maillon peut dégrader le résultat final, et les dégradations se cumulent : une recherche qui remonte un mauvais passage rend la réponse fausse même si le modèle est excellent.

Le réflexe le plus courant consiste à regarder quelques réponses, décider que « ça marche », et partir en production. Évaluer un RAG, c’est répondre à trois questions : la source retrouvée est-elle la bonne, la réponse est-elle conforme à cette source, l’utilisateur obtient-il ce qu’il cherche.

Ce guide pose les fondations d’une évaluation de RAG qui tient dans une PME : pas de plateforme d’annotateurs, mais un jeu de test limité, des métriques interprétables et un rituel de suivi. Vous repartez avec la liste de ce qu’il faut mesurer avant la production, et de ce qu’il faut surveiller ensuite. Si votre RAG répond déjà mal, les 6 erreurs classiques d’un RAG donnent des pistes de diagnostic à croiser avec ces métriques.

La fidélité d’abord, la pertinence ensuite

La métrique la plus importante d’un RAG est la fidélité : la réponse doit être entièrement soutenue par les passages retrouvés. Un modèle peut générer une phrase grammaticalement parfaite et factuellement fausse si elle s’appuie sur un passage hors sujet. Pour la mesurer, comparez la réponse à sa source, phrase par phrase, et comptez la proportion d’affirmations étayées.

Sur une réponse de cinq phrases, si une phrase avance un chiffre absent du document source, la fidélité est de quatre sur cinq. Ce ratio s’explique en une phrase à un non-technique, et il se corrèle directement avec le risque d’erreur perçu par l’utilisateur. Un RAG à faible fidélité ne se corrige pas en changeant de modèle : il se corrige en vérifiant ce que la recherche remonte.

La pertinence mesure l’inverse : la réponse couvre-t-elle la question posée, ou se contente-t-elle d’être vraie à côté du sujet ? Une réponse précise sur la TVA française est impertinente si la question portait sur la facturation intracommunautaire. On juge la pertinence sur la réponse seule, sans regarder la source. C’est un jugement plus subjectif, adapté à une annotation humaine sur un petit jeu.

Construire un jeu de référence représentatif

Toute évaluation repose sur un jeu de questions dont vous connaissez les bonnes réponses. La règle est la représentativité : le jeu doit refléter les vraies questions des utilisateurs, pas celles que votre équipe trouve intéressantes. Un jeu de trente questions relevées dans les demandes réelles vaut mieux qu’un jeu de deux cents questions inventées.

Vous partez des logs du support, des emails reçus et des questions posées lors des tests internes. Regroupez-les par type : recherche factuelle d’un chiffre, synthèse sur plusieurs documents, question de procédure. Gardez aussi les questions pièges : des documents qui se contredisent, une question sans source, un terme qui n’apparaît pas tel quel dans le document.

Pour chaque question, notez la réponse attendue et la liste des passages qui devraient être retrouvés. Cette étape est fastidieuse mais elle rend toutes les autres métriques lisibles : sans passages de référence, impossible de savoir si une erreur vient de la recherche ou de la génération. Comptez trois à quatre heures pour trente questions, une dépense qui évite des mois de débogage à l’aveugle. La construction de ce jeu est détaillée pas à pas dans évaluer un RAG : construire un jeu de test représentatif.

Les métriques de la recherche : recall et précision

La partie recherche se mesure séparément de la génération. Le recall indique si les passages pertinents ont été retrouvés : le passage de référence est-il dans les cinq premiers résultats ? La précision indique si les résultats sont propres : combien des passages retournés servent réellement à la réponse. Un bon RAG vise un recall élevé avec un nombre de passages limité, car chaque passage superflu ajoute du bruit que le LLM devra ignorer.

Prenons une question de procédure de remboursement. Le passage de référence décrit les étapes, mais un autre document contient le même terme avec une autre signification. Si les deux remontent dans le top cinq, le recall est bon mais la précision est faible, et le modèle devra départager deux sources ambiguës : c’est le scénario qui produit des hallucinations subtiles. Deux leviers : mieux classer, avec un reranker comme Cohere Rerank, ou filtrer par métadonnées, ce que Qdrant, Weaviate ou pgvector permettent, en restreignant la recherche au type de document adéquat.

La taille de la fenêtre de recherche dépend de vos documents : de petites fenêtres favorisent la précision, de larges fenêtres le recall. Testez deux ou trois variantes de découpage des documents, d’embedding ou de type de recherche, et gardez celle qui maximise le recall sans faire chuter la précision.

La génération : fidélité automatique et jugement humain

Pour la génération, deux outils. Le premier est une vérification automatique de fidélité, par exemple en demandant à un autre modèle de lister les affirmations de la réponse et de vérifier chacune contre la source. Ragas et DeepEval proposent ce calcul de fidélité prêt à l’emploi, avec le recall et la précision du contexte. Cela détecte les réponses manifestement décrochées et permet de suivre la tendance. Le second est le jugement humain : chaque semaine, relisez une dizaine de réponses et notez fidélité et pertinence à la main.

Cette double approche évite deux écueils : se fier uniquement aux métriques automatiques, qui ratent les erreurs subtiles de formulation, ou tout noter à la main, ce qu’on ne tient pas dans la durée. Le bon équilibre est un score automatique recalculé à chaque modification du pipeline, par exemple avec Promptfoo dans GitHub Actions, et une revue humaine hebdomadaire pour valider que les scores veulent encore dire quelque chose.

Préférez les causes aux scores : si la fidélité baisse, regardez quels types de questions échouent, quelle source est en cause, quel découpage produit les passages fautifs.

Suivre les usages réels en production

Les métriques sur le jeu de référence mesurent ce que le système sait faire. En production, mesurez aussi ce que les utilisateurs en font. Deux indicateurs se démarquent : la proportion de réponses restée sans retour de l’utilisateur, et la proportion de questions reformulées après une première réponse. Une reformulation signifie presque toujours que la première réponse n’a pas satisfait, sans que personne n’ait eu à se plaindre.

Ajoutez un bouton de retour simple sous chaque réponse. Un outil d’observabilité LLM comme Langfuse ou LangSmith rattache ce retour à la trace complète (question, passages, réponse), ce qui permet de corréler ces retours avec les réponses faibles sur la fidélité : les cas où l’utilisateur n’a pas aimé et a reçu une réponse peu fidèle sont vos priorités. Versez ces exemples dans le jeu de référence chaque trimestre, pour que l’évaluation suive l’évolution réelle des usages.

Pensez aussi au coût par réponse utile : si la moitié des réponses finissent en reformulation, le coût réel par utilisateur satisfait est le double du coût apparent. Ce chiffre parle en euros et déclenche souvent la vraie décision de correction, là où les scores de fidélité et de pertinence servent à choisir la correction à faire en premier.

En pratique : vos projets RAG

L’ordre de travail : un jeu de référence tiré des vraies questions, la recherche mesurée séparément de la génération, la fidélité avant la pertinence, puis le suivi des reformulations et des retours une fois en production. Sans ce socle, chaque modification du pipeline reste un pari.

Quand on construit ou qu’on reprend un chatbot RAG, c’est par là qu’on commence : constituer le jeu de référence avec votre équipe, qui reste maîtresse des réponses attendues et des cas sensibles, mesurer le point de départ, puis seulement toucher au découpage, aux embeddings ou au modèle. Chaque changement se juge alors sur des chiffres, pas sur trois réponses regardées à l’œil.