Six métriques d’évaluation RAG importantes en environnement de production

Les premiers tutoriels sur RAG donnent l’impression que le chemin à suivre est court : diviser les documents, les intégrer, stocker les vecteurs, choisir un petit top_k, appeler le modèle. Cette méthode peut sembler efficace dans une démonstration. En production, c’est moins simple.

Les questions arrivent de manière chaotique. Les documents sources se contredisent. Certaines requêtes nécessitent des éléments provenant de plusieurs endroits en même temps. Les utilisateurs inventent des formulations qui n’ont jamais figuré dans l’ensemble de test original. Une configuration qui obtenait de bons résultats sur des benchmarks prédéfinis commence à fournir des réponses étrangement fragiles.

Lors de l’ajustement du système de récupération pour un assistant de type entreprise, ce schéma s’est clairement manifesté. Le manque d’éléments de preuve a poussé l’équipe à augmenter la profondeur de recherche. Les scores de récupération hors ligne ont progressé, tout comme le taux de rappel. Les métriques papier indiquaient une « amélioration », mais la qualité des réponses générées s’est détériorée.

Le contexte supplémentaire n’aidait pas. Parfois, cela causait des problèmes. Les passages pertinents arrivaient entremêlés de doublons, de données peu fiables et de conflits occasionnels.

Cette expérience a redéfini l’évaluation. La question n’était plus « avons-nous téléchargé le bon fichier ? » mais plutôt « chaque étape du processus peut-elle prouver qu’elle accomplit sa tâche ? »

Le débogage des systèmes RAG en temps réel permet de distinguer plusieurs critères que les démonstrations regroupent en un seul score : la qualité de la récupération des données, l’efficacité du classement, la pertinence de la réponse, le fait que les affirmations soient fondées, le temps d’attente des utilisateurs et le coût de chaque requête. La question suivante que tout le monde se pose — comment choisir la taille des blocs et la valeur top-k ? — ne mérite plus une réponse basée sur des chiffres prédéfinis.

Abordez le problème comme une optimisation hors ligne : définissez des valeurs de référence, mesurez les indicateurs pertinents, identifiez les compromis, testez des requêtes inédites, puis vérifiez que la solution reste efficace en environnement de production.

Six indicateurs sont particulièrement utiles : Recall@K, nDCG, MRR, Faithfulness, Latency et Cost. Chacun révèle un type de défaillance différent. Ensemble, ils expliquent comment un prototype devient un système opérationnel.

Commencez par la récupération des informations

Lorsque les réponses se dégradent, revenez en amont du processus avant de réécrire les prompts, de changer de modèles ou d’ajouter des agents. Posez-vous la question directe : les éléments nécessaires sont-ils vraiment trouvés ? Un modèle ne peut pas utiliser de matériel qui n’a jamais été inclus dans la fenêtre de contexte.

1. Recall@K — couverture des éléments nécessaires

Recall@K indique quelle fraction d’éléments véritablement pertinents figure parmi les K premiers résultats.

Prenons un bot ITSM confronté à la question suivante : « Le service de paiement a échoué suite à un basculement de base de données — quels étapes de récupération dois-je exécuter ? » Supposons que cinq informations soient nécessaires. Les cinq premiers résultats obtenus ne contiennent que quatre d’entre elles. Le Recall@5 est donc de 0,80.

Ce seul chiffre guide déjà le débogage. Le générateur n’est pas forcément le coupable ; vingt pour cent des preuves nécessaires ne sont jamais arrivées. Règle générale : améliorez ce que le modèle voit avant de blâmer la manière dont il écrit.

Cela explique également pourquoi une valeur fixe de top_k = 5 n’est pas sacrée. En passant K de 5 à 10, on observe que le taux de rappel augmente de 0,80 à 0,94, ce qui indique que l’index contient bien le matériel requis mais que la sélection est trop superficielle. Augmenter K comporte aussi le risque de submerger l’instruction d’erreurs — c’est pourquoi les métriques de classement viennent ensuite.

2. nDCG — les meilleurs résultats se trouvent-ils en tête ?

La simple couverture n’est pas suffisante. La position compte.

Deux systèmes peuvent utiliser le même guide de procédures. L’un le place en premier, suivi d’une autre procédure utile, puis de sections moins pertinentes. L’autre cache ce guide à la huitième place, parmi des pages peu liées. Rappel similaire ; produits très différents.

Les scores nDCG (gain cumulé déprécié normalisé) évaluent le degré de pertinence et récompensent davantage l’affichage précoce des éléments les plus pertinents. Le travail classique sur le gain déprécié mené par Järvelin et Kekäläinen existe précisément pour cette raison.

Le réclassement rend cela concret dans le cadre de RAG : on récupère vingt candidats, on en conserve cinq pour le modèle, et l’ordre de ces vingt détermine si les cinq retenus sont de qualité. Un taux de rappel élevé associé à un classement faible peut faire en sorte que le passage approprié reste dans la liste de candidats mais soit exclu du prompt final.

Le taux de rappel vérifie la capacité de découverte, tandis que le nDCG évalue l’ordre intelligent des résultats.

3. MRR — à quel moment apparaît la première réponse utile ?

Le Mean Reciprocal Rank se concentre sur le premier résultat pertinent :

[
RR = \frac{1}{\text{rank of first relevant result}}
]

Rang 1 → RR 1,0. Rang 5 → RR 0,2. En moyenne sur un ensemble de requêtes, le MRR constitue un indicateur clair lorsque la première réponse pertinente domine l’expérience utilisateur.

Les assistants interactifs s’arrêtent souvent après le premier passage pertinent. Un système de recherche qui cache le bon manuel de procédures à la neuvième position peut sembler performant lors du test Recall@20, mais rester défaillant dans l’interface utilisateur.

Lorsque « plus de contexte » a des effets contraires

Même après une amélioration du nombre de résultats trouvés, la qualité des réponses a continué à baisser. Le modèle était submergé de textes redondants et contradictoires. Les métriques de classement expliquent ce problème : un K plus élevé, sans amélioration de l’ordre des résultats, introduit du bruit dans la demande d’exécution. Cela entraîne des vérifications de cohérence.

4. Fidélité — affirmations liées au texte retrouvé

La fidélité consiste à vérifier si les affirmations contenues dans la réponse sont étayées par le contexte retrouvé. Un texte fluide qui invente une étape, un seuil ou fusionne deux politiques en une troisième manque à la fidélité, même s’il semble convaincant.

Il faut séparer la fidélité de la justesse.

Supposons que le corpus contienne encore une règle de mot de passe obsolète — expiration tous les 60 jours. Le modèle la récupère et la répète. La réponse peut être entièrement fidèle à la page récupérée tout en étant fausse par rapport à la source de vérité prévue.

• Fidélité : est-elle soutenue par ce qui a été récupéré ?
• Correction : est-elle conforme à la politique visée ?

Cette distinction est importante chaque fois que les bases de connaissances évoluent sous un système en ligne.

5. Latence — temps d’attente acceptable pour les utilisateurs

La qualité hors ligne est inutile si le produit ne peut pas supporter cet attendre.

Comparons deux configurations. A atteint 91 % de précision des réponses avec une latence de récupération de 120 ms. B atteint 93 % avec 650 ms. B l’emporte en termes de précision seule. Les contraintes du produit déterminent si B est réellement meilleur. Les assistants interactifs disposant d’un budget de réponse limité peuvent rejeter ce délai, et la récupération n’est qu’une partie du temps total.

Une requête en temps réel peut inclure la réécriture, la récupération des données, le reclassement, l’assemblage du contexte et la génération de contenu. Il convient d’évaluer les différentes étapes ainsi que le parcours du début à la fin. Préférer les distributions aux moyennes : une valeur moyenne de 400 ms avec un P95 de 1,8 s ne correspond en rien à un système dont les valeurs P50/P95/P99 restent faibles.

Intégrez la latence dans le plan d’évaluation dès le premier jour – et non en tant que métrique opérationnelle une fois l’architecture finalisée.

6. Coût – ce qui se passe avec des millions de requêtes

L’aspect économique devient pertinent dès que le prototype se transforme en produit.

Augmenter le nombre de résultats affichés (top-k) a un impact plus important que l’amélioration du taux de rappel. Cela peut entraîner une augmentation du travail de reclassement, de la taille du contexte final, du nombre de tokens d’entrée, de la latence et de la consommation d’infrastructure.

Si chaque bloc contient en moyenne 600 tokens, alors :

Final K = 5

environ 3 000 tokens sont récupérés. Aller à :

Final K = 15

et vous êtes proche de 9 000 — soit le triple de la masse récupérée. Un faible volume de requêtes cache les coûts réels. Des millions de demandes en font un choix commercial. Le paramètre top-k influence simultanément la qualité, le temps de réponse et les coûts.

Que signifie réellement « ajuster la taille des blocs et le paramètre top-k »

La question posée lors de l’entretien ne demande pas deux valeurs magiques, mais plutôt un plan d’expérimentation.

Créez environ 200 requêtes représentatives couvrant les problèmes de dépannage, les procédures, les incidents/RCA, les politiques, les cas d’ambiguïté, les scénarios à plusieurs étapes et les cas limites. Laissez les experts du domaine évaluer la pertinence.

Testez différentes tailles de blocs comme suit :

Chunk sizes:
256
512
1024
2048

et explorez les grilles de candidats-K comme suit :

Overlap:
64
128
256Candidate K:
5
10
20

Une grille 4 × 3 × 3 donne environ 36 configurations. Évaluez chacune avec plusieurs critères :

Recall@K
nDCG@K
MRR
Answer correctness
Faithfulness
Latency
Cost

Puis choisissez le compromis entre qualité, temps de réponse et coûts — et non nécessairement le taux de rappel maximal ou la valeur F1 par défaut.

Résultats d’expériences contre-intuitifs

Supposons que trois configurations donnent les résultats suivants :

• A : Recall@10 0,94, nDCG@10 0,81, précision 0,89, fidélité 0,95, P95 510 ms, 0,025 $
• B : Recall@10 0,91, nDCG@10 0,88, précision 0,94, fidélité 0,96, P95 560 ms, 0,027 $
• C : Recall@10 0,97, nDCG@10 0,79, précision 0,86, fidélité 0,76, P95 820 ms, 0,034 $

Le seul critère du Recall désigne C comme la meilleure. C produit les réponses les plus faibles — une récupération supplémentaire semble nuire à la génération. B présente un Recall inférieur mais excelle en nDCG, précision et fidélité, avec seulement une légère pénalité en termes de latence et de coût. C’est cette configuration qui mérite d’être étudiée en détail, et c’est aussi la raison pour laquelle le principe « celui qui a le meilleur score de récupération gagne » n’est pas une règle universelle valable. Il convient d’optimiser en fonction de l’objectif réel du produit.

Echec → prochaine investigation

• Recall@K faible → segmentation en blocs, embeddings, index, filtres de métadonnées, mise en forme des requêtes, stratégie de récupération

Rappel fort, nDCG faible → classement / reclassement

Récupération forte, précision des réponses faible → assemblage de contexte, tri, prompts, génération

Réponses plausibles mais non étayées → fidélité / ancrage

Bonne qualité, latence élevée → analyser chaque étape

Bonne qualité, coût élevé → nombre de candidats K, nombre final K, taille des blocs, compression, mise en cache, choix du modèle, efficacité des tokens

Cette liste de contrôle transforme le débogage en une procédure.

Garder le cycle actif en production

Un benchmark ponctuel n’est pas l’état final. Il faut une évaluation continue. Le trafic réel diffère des ensembles préparés : les formulations évoluent, les documents changent, les politiques sont mises à jour, de nouveaux services apparaissent, des cas limites surviennent. Élargir l’ensemble d’évaluation à partir des pannes en production.

Tableau de suivi mature

Aucune métrique isolée ne permet de raconter toute l’histoire. Une carte utile prend en compte simultanément la couverture, le classement, la précision, la fidélité, les percentiles de latence et les aspects économiques liés aux unités.

Poser des questions avant d’ajuster

Lorsque quelqu’un exige une taille de bloc et un seuil top-k, commencez par poser des questions : que cherchons-nous à optimiser, à quoi ressemble l’ensemble étiqueté, et quel est le coût d’une erreur de récupération ? Avec ces réponses, les configurations deviennent des résultats expérimentaux.

Un résultat possible pourrait être :

512 tokens
128 overlap
Candidate K = 20
Final K = 5

Un autre :

1024 tokens
64 overlap
Candidate K = 10
Final K = 4

Le découpage sémantique pourrait être supérieur aux deux approches. Un réordonneur pourrait rendre le K final plus important que le K candidat.

Ne faites pas confiance à une valeur universelle sans mesure. Un système RAG n’est pas « bon » simplement parce qu’il récupère plus d’informations, plus rapidement, ou parce que ses résultats semblent convaincants. Il est bon lorsqu’il trouve les preuves appropriées, les classe correctement, fournit au modèle la quantité adéquate de contexte, génère des réponses à la fois correctes et fondées, et reste dans les limites de latence et de coût prévues par le produit.

Cet écart — entre la mise en place d’un pipeline et l’ingénierie d’un système de production — est justement l’essentiel.

Cessez de deviner les paramètres

Aucune longueur de chunk mythique, aucun seuil top-k universel, et aucune métrique isolée ne peuvent déclarer qu’un déploiement est prêt. Un meilleur taux de rappel @K peut encore nuire à la qualité des réponses. Une capacité de récupération forte peut encore permettre des affirmations non étayées. Une haute précision peut encore échouer si la latence ou les coûts augmentent de manière exponentielle à grande échelle.

Équilibrez la couverture, le classement, la génération fondée sur des données réelles, la latence et les coûts en fonction du travail que vous effectuez réellement.

Préférez : vérité de référence → benchmarks de récupération → vérifications de classement → qualité des réponses du début à la fin → validation de la latence/coût → données non vues en attente → surveillance en production → retour des échecs dans l’ensemble.

Alors chunk_size=512 ou top_k=5 constituent une preuve, et non une croyance populaire.

Réunir les six métriques sur une seule page

Un tableau de suivi fonctionnel pour une revue hebdomadaire RAG pourrait ressembler à ceci :

• Recall@K et MRR pour savoir « avons-nous trouvé des preuves, et à quelle vitesse ? »
• nDCG pour savoir « avons-nous mis les meilleures preuves en premier ? »
• Fidélité et exactitude des réponses pour savoir « la génération est-elle restée honnête et fidèle ? »
• Latence P50/P95 pour savoir « les utilisateurs peuvent-ils attendre ? »
• Cost par réponse réussie pour savoir « le service financier peut-il attendre ? »

Examinez-les ensemble. Une augmentation de Recall@K accompagnée d’une baisse de la fidélité n’est pas une réussite. Une réduction de la latence qui entraîne une chute du nDCG n’est pas non plus une réussite. L’avantage du cadre à six métriques est de rendre visibles ces compromis au lieu de les cacher derrière un seul chiffre F1.

La vérité de référence est la ressource rare

Les métriques ne sont aussi bonnes que les étiquettes qui les sous-tendent. Si les experts du domaine ne jugent jamais quelles parties sont pertinentes, Recall@K n’a plus de sens. Si personne ne note le niveau de pertinence, le nDCG se réduit à une classification binaire bruyante. Si les juges de fidélité ne sont pas cohérents, les scores de référence s’écartent.

Allouez du temps pour l’étiquetage de la même manière que vous allouez du temps pour les expériences d’incorporation. Deux cents requêtes soigneusement évaluées apprennent généralement plus que deux mille requêtes non étiquetées. Mettez à jour cet ensemble à partir des tickets de production : chaque « déduction incorrecte », « règle de mot de passe obsolète » et « manuel non consulté » constitue un cas potentiel.

De l’expérience au contrôle des changements

Lorsqu’une configuration est retenue hors ligne, procédez à son déploiement comme pour n’importe quel autre changement en production. Enregistrez le réseau de recherche utilisé, les paramètres gagnants, les résultats des cas non inclus, ainsi que la fourchette de latence/coût acceptée. Ensuite, surveillez les mêmes indicateurs sur le trafic en direct pendant une période d’observation. Si les requêtes en production diffèrent, intégrez ces échecs dans l’ensemble étiqueté et relancez le réseau de recherche. Cet ensemble de boucles — et non la taille par défaut définie dans un article de blog — est ce qui distingue un système optimisé d’une démonstration chanceuse.

Pourquoi les prototypes mentent

Les notebooks de démonstration fixent généralement l’ensemble des requêtes, gèlent le corpus et masquent la latence derrière une seule appel. En production, c’est l’inverse : les requêtes évoluent, les documents changent constamment et les utilisateurs abandonnent les réponses lentes. C’est pourquoi une configuration qui semblait excellente lors d’un benchmark statique peut paraître peu fiable après le lancement. Les six métriques mentionnées ci-dessus permettent de rendre ces dimensions cachées explicites avant le déploiement, ainsi que de les maintenir explicites après celui-ci.

Lorsqu’on demande une taille de chunk par défaut et un top-k par défaut, il faut traduire cette demande en un plan d’expérience. Définissez l’objectif, le jeu de données étiqueté, le budget de latence et le plafond des coûts. Ensuite, laissez le système de grille générer les chiffres correspondants. Tout autre approche n’est qu’une supposition déguisée en ingénierie.

Gardez le tableau de suivi visible lors des réunions hebdomadaires afin que les compromis restent clairs pour toute l’équipe.