Évaluer la qualité d'un RAG dans n8n : métriques, jeu de test et LLM-as-a-judge

Un RAG monté dans n8n fait presque toujours bonne impression le premier jour : trois questions, trois bonnes réponses, mise en production. Trois mois plus tard, les utilisateurs se plaignent de réponses à côté — et personne ne sait dire quand la qualité a baissé, parce que rien n'a jamais « cassé » au sens technique. Un RAG ne tombe pas en panne : il se dégrade en silence, au fil des documents ajoutés, des prompts retouchés et des modèles mis à jour. La seule parade est de mesurer : des métriques simples, un jeu de test de référence, et un workflow d'évaluation rejoué à chaque changement. Voici comment monter ce dispositif dans n8n.

Pourquoi un RAG se dégrade sans prévenir

Un pipeline RAG empile des étages qui dérivent chacun indépendamment : la base documentaire grossit et dilue les bons passages, un lot de documents mal découpés pollue la recherche, une retouche de prompt « anodine » change le comportement du modèle, le fournisseur met à jour son LLM sans préavis. Aucun de ces événements ne déclenche d'erreur. Et tester trois questions à la main ne détecte rien : celles qu'on connaît par cœur continuent de marcher, ce sont les quarante autres qui se dégradent.

La difficulté propre au RAG : quand une réponse est mauvaise, deux coupables sont possibles. Soit la recherche n'a pas remonté les bons passages (problème de retrieval), soit elle les a remontés mais le modèle en a fait une mauvaise réponse (problème de génération). Sans métriques séparées pour ces deux étages, on corrige au hasard — on change le prompt alors que le problème est dans le chunking, ou l'inverse.

Les métriques qui comptent, expliquées simplement

Côté retrieval : les bons passages remontent-ils ?

• Hit rate (taux de succès) — le passage qui contient la réponse figure-t-il dans le top-k retourné ? La métrique la plus simple et la plus parlante : un hit rate de 70 % signifie que 3 questions sur 10 sont perdues avant même d'atteindre le LLM.
• Rappel du contexte — quelle proportion des informations nécessaires se trouve dans les passages récupérés ? Utile quand la réponse complète exige plusieurs chunks.
• Précision du contexte — parmi les passages récupérés, combien sont réellement utiles ? Une précision faible signifie un prompt rempli de bruit qui distrait le modèle.
• MRR (Mean Reciprocal Rank) — à quelle position moyenne apparaît le premier bon passage ? Un bon passage classé 8ᵉ compte pour le hit rate mais révèle un classement médiocre.

Côté génération : la réponse est-elle bonne ?

• Fidélité au contexte (faithfulness) — la réponse s'appuie-t-elle uniquement sur les passages fournis, ou le modèle a-t-il ajouté des affirmations de son cru ? La métrique anti-hallucination par excellence.
• Pertinence de la réponse — répond-elle vraiment à la question posée, sans digression ?
• Exactitude — comparée à une réponse de référence rédigée par un humain, est-elle factuellement juste ?

Ce découpage n'est pas une invention maison : c'est la structure proposée par le framework RAGAS, décrit dans l'étude « RAGAS: Automated Evaluation of Retrieval Augmented Generation » d'Es, James, Espinosa-Anke et Schockaert publiée en 2023 (voir sur Google Scholar), qui formalise fidélité, pertinence et qualité du contexte comme dimensions évaluables automatiquement. RAGAS est le framework de référence si vous voulez creuser ; pour un RAG n8n, les mêmes principes s'appliquent sans rien installer.

Construire le jeu de test de référence

Tout le dispositif repose sur un jeu de 20 à 50 paires question-réponse stocké dans un Google Sheet ou une Data Table n8n : la question, la réponse attendue (2-4 phrases rédigées par quelqu'un qui connaît le sujet), et idéalement l'identifiant du document source — c'est lui qui permet de calculer le hit rate.

Trois règles pour que ce jeu serve à quelque chose :

1. Partir des vraies questions. Piochez dans les logs du chatbot, les tickets support, les emails reçus. Les questions inventées sont trop propres ; les vraies contiennent des fautes, du flou et des références exactes.
2. Inclure des cas difficiles. Des réponses réparties sur plusieurs documents, des codes produit précis, et surtout 3 à 5 questions sans réponse dans la base — la réponse attendue est alors « je ne sais pas », et tout RAG qui invente à la place doit être pénalisé.
3. Enrichir à chaque incident. Chaque mauvaise réponse signalée en production devient une ligne du jeu de test : c'est ce qui empêche le même bug de revenir.

Le workflow LLM-as-a-judge dans n8n

Le principe : un workflow d'évaluation lit chaque ligne du jeu de test, appelle le pipeline RAG réel (isolé dans un sub-workflow pour ne pas dupliquer la logique), puis soumet le tout à un LLM juge qui note la réponse selon une grille explicite.

Le prompt du juge est le point critique. Une consigne vague (« note cette réponse ») produit des scores irreproductibles ; une grille détaillée avec sortie structurée, fiabilisée par le Structured Output Parser, donne des notes exploitables :

Tu es un évaluateur strict. On te fournit une QUESTION, le CONTEXTE
récupéré, la RÉPONSE générée et une RÉPONSE DE RÉFÉRENCE.

Note chaque critère de 1 à 5 :
- fidelite : chaque affirmation de la réponse est-elle appuyée par
  le contexte ? (5 = tout est sourcé, 1 = inventions manifestes)
- pertinence : la réponse traite-t-elle la question posée ?
- exactitude : la réponse est-elle cohérente avec la référence ?

Réponds UNIQUEMENT en JSON :
{"fidelite": n, "pertinence": n, "exactitude": n, "verdict": "pass|fail", "commentaire": "une phrase"}

L'approche est validée empiriquement : l'étude « Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena » de Zheng et al., publiée à NeurIPS 2023 (voir sur Google Scholar), montre qu'un juge LLM performant atteint plus de 80 % d'accord avec les évaluateurs humains — le niveau d'accord des humains entre eux — tout en documentant ses biais (position, verbosité, auto-complaisance). D'où deux précautions : un juge d'une autre famille que le modèle générateur, et une relecture humaine d'un échantillon de notes de temps en temps.

Plutôt que de tout câbler à la main, appuyez-vous sur les Evaluations natives de n8n : le node Evaluation Trigger lit le dataset, le node Evaluation enregistre les métriques, et l'onglet Evaluations historise les scores de chaque run — notre guide des Evaluations n8n détaille ce montage, où la grille de juge ci-dessus se branche comme métrique personnalisée. Pensez aussi à suivre le coût des appels IA de ces campagnes : modeste sur 50 questions, mais autant le connaître.

Quoi améliorer selon le diagnostic

C'est ici que la séparation retrieval/génération paie, parce qu'elle dicte le chantier à ouvrir :

• Hit rate ou rappel faible → le problème est en amont du LLM. Revoyez le découpage des documents, vérifiez le modèle d'embeddings, et si les échecs concernent des références exactes (codes, SKU), passez à la recherche hybride. Base multi-sources ? Le filtrage par métadonnées réduit l'espace de recherche.
• Hit rate correct mais MRR ou précision faibles → les bons passages sortent, mais mal classés ou noyés : c'est le cas d'usage du reranking.
• Retrieval bon, fidélité ou exactitude faibles → le problème est dans la génération : prompt trop permissif (ajoutez une consigne stricte « réponds uniquement à partir du contexte, sinon dis que tu ne sais pas », comme dans notre guide RAG Supabase), ou contexte trop long qui noie l'information — injectez moins de passages, pas plus.
• Pertinence faible partout → relisez les commentaires du juge cas par cas avant de toucher au pipeline.

Suivre dans le temps : la routine avant/après

Une évaluation isolée est une photo ; l'intérêt est le film. La routine : un score avant, un score après, pour chaque modification. Vous changez le chunking ? Run avant, run après, comparaison des moyennes. Le hit rate passe de 72 % à 86 % mais la fidélité baisse ? Vous le voyez immédiatement, au lieu de le découvrir dans les plaintes trois semaines plus tard. Conservez chaque run avec sa date et la description du changement, et planifiez un run périodique même sans modification : c'est lui qui attrape les dérives silencieuses, mise à jour de modèle chez le fournisseur ou évolution de la base documentaire.

En résumé

• Un RAG ne casse pas, il se dégrade en silence : sans mesure, vous l'apprendrez par vos utilisateurs.
• Séparez retrieval (hit rate, rappel, précision du contexte, MRR) et génération (fidélité, pertinence, exactitude) : le diagnostic dicte le remède.
• Un jeu de test de 20 à 50 paires tirées des vraies questions, cas difficiles et questions sans réponse inclus.
• Le pattern LLM-as-a-judge avec grille structurée automatise la notation, dans le cadre des Evaluations natives de n8n.
• Retrieval faible → chunking, embeddings, recherche hybride, reranking. Génération faible → prompt, contexte plus court.
• Mesurez avant/après chaque changement et périodiquement.