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. Cela fonctionne jusqu’au premier cas réel où l’utilisateur reçoit une réponse fausse avec assurance. É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.
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.
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. La bonne réponse n’est pas toujours de mieux classer, mais parfois de filtrer par métadonnées, par exemple 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, 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. Ce n’est pas parfait, mais 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 continu, réinitialisé à chaque modification du pipeline, 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 et corrélez 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.
L’accompagnement Agenticiel pour vos projets RAG
Mettre en place ces métriques demande de la méthode et du temps que les équipes internes peinent souvent à dégager, surtout quand le RAG doit sortir vite. C’est le genre de sujet où une équipe offshore francophone apporte de la valeur : nos développeurs à Madagascar conçoivent le jeu de test, implémentent les vérifications automatiques de fidélité et mettent en place le suivi, pendant que votre équipe garde la maîtrise des décisions produit et de la relecture des cas sensibles.
La sous-traitance de développement ne se limite pas à l’écriture de code : elle inclut aussi les pratiques de qualité qui rendent un système IA exploitable dans la durée. Nous intervenons sur votre RAG existant comme sur un projet neuf, avec un périmètre précis et un livrable mesurable à chaque étape.
Notre approche consiste à commencer par un état des lieux facturé 1 500 €, déduit du devis si vous poursuivez, pour identifier les métriques pertinentes pour votre cas et construire le jeu de référence avant toute modification du pipeline.