Une baseline d'évaluation est la mesure chiffrée de la performance de votre RAG avant toute correction : un jeu de questions réelles, les réponses obtenues, et un score de qualité sur chacune. Sans elle, changer de modèle, augmenter le top-k ou réécrire le prompt n'est qu'une croyance, pas une amélioration vérifiée.
C'est le chiffre que presque personne ne mesure avant de se lancer dans les corrections. Une équipe qui bricole sans baseline ne sait pas si elle avance ou si elle déplace le problème. Elle tourne en rond, parfois pendant des semaines, pour cette seule raison.
Cet article donne une méthode accessible sans équipe MLOps : constituer un jeu de test à partir des vraies questions, séparer ce qui relève de la recherche documentaire de ce qui relève de la génération, choisir des métriques qui parlent au métier, et savoir ce qu'un modèle juge peut et ne peut pas faire.
En bref
- Une baseline est un jeu de questions réelles évaluées une première fois, avant toute correction du RAG
- Le jeu de test doit venir des vraies questions des utilisateurs, pas de questions inventées par l'équipe projet
- 30 à 50 questions réelles suffisent pour démarrer, 100 à 150 pour un suivi de régression fiable dans la durée
- Un RAG échoue soit parce qu'il ne trouve pas, soit parce qu'il trouve et répond mal, et les corrections sont différentes
- Un modèle juge accélère l'évaluation mais doit être calibré sur un échantillon noté par un humain
Pourquoi la baseline est le préalable à toute correction
Une baseline d'évaluation RAG est la photographie chiffrée de ce que produit votre système aujourd'hui, avant qu'on y touche. Sans elle, toute correction repose sur une impression, jamais sur une preuve. C'est la différence entre « ça semble mieux » et « le taux de bonnes réponses est passé de 62 % à 81 % ».
Le réflexe le plus courant face à un RAG décevant est de bricoler directement : changer de modèle, augmenter le nombre de passages récupérés, réécrire le prompt système. Chacun de ces changements peut améliorer les choses, les dégrader, ou les deux à la fois selon les questions. Sans mesure avant et après, personne ne peut trancher.
Ce constat revient systématiquement lors d'un audit technique RAG et Agents IA : les équipes qui ont déjà tenté plusieurs corrections ne savent souvent pas dire laquelle a réellement fonctionné, parce qu'aucune n'avait été mesurée avant et après sur le même jeu de questions. Le temps perdu ne vient pas d'un manque de bonnes idées de correction, il vient de l'absence de repère pour les juger.
Une baseline sert aussi à hiérarchiser l'effort. Si la mesure montre que 80 % des échecs viennent de la recherche documentaire et 20 % de la génération, inutile de commencer par changer de modèle : le gain sera marginal tant que le retrieval ne remonte pas les bons passages.
Constituer un jeu de test à partir des vraies questions
Un jeu de test fiable est composé de questions réellement posées par vos utilisateurs, jamais de questions imaginées en réunion. Les questions inventées reflètent la vision du système qu'a l'équipe projet, pas la manière, souvent plus floue et plus variée, dont les utilisateurs formulent réellement leurs besoins.
Où trouver les vraies questions
Plusieurs sources existent selon la maturité du projet :
- Les journaux de requêtes si le RAG est déjà en production, même en version bêta interne. C'est la source la plus fiable : ce sont les questions exactes, avec leurs fautes de frappe et leurs formulations imparfaites.
- Les tickets support et emails adressés à l'équipe métier avant le déploiement du RAG : ils révèlent les questions que les utilisateurs posent déjà à un humain, et que le système devra reprendre.
- Des sessions d'observation avec 5 à 10 futurs utilisateurs si aucune donnée d'usage n'existe encore. On leur demande de formuler leurs questions types sans les préparer à l'avance.
- La documentation existante (FAQ interne, procédures) pour identifier les sujets récurrents et vérifier qu'ils sont couverts par le jeu de test.
Classez ensuite ces questions par catégorie (facturation, procédure RH, spécification technique...) et par fréquence. Un jeu de test représentatif respecte à peu près la proportion réelle des sujets posés, plutôt que de donner un poids égal à une question rare et à une question quotidienne.
Quelle taille de jeu de test est utile
Il n'existe pas de taille unique valable pour tous les cas. L'objectif d'une baseline de correction n'est pas le même que celui d'un golden dataset construit pour comparer plusieurs modèles avant un choix définitif, un exercice plus exhaustif détaillé dans notre article sur l'évaluation d'un LLM en entreprise.
Pour une PME sans équipe dédiée, un premier jeu de 30 à 50 questions réelles, couvrant les catégories principales, suffit déjà à révéler les problèmes structurels et à comparer deux versions du système avec un signal exploitable. C'est un point de départ, pas un aboutissement.
Pour un suivi de régression fiable dans la durée, viser 100 à 150 questions annotées donne une base plus robuste, en particulier pour détecter qu'une correction qui améliore une catégorie de questions en dégrade une autre. Au-delà, le gain de fiabilité ralentit fortement par rapport à l'effort d'annotation supplémentaire.
Ce qui rend un jeu de test inutilisable
- Des questions rédigées par l'équipe technique dans un français plus précis que celui des utilisateurs réels
- Une majorité de questions faciles, sans cas limites ni questions hors périmètre
- L'absence de réponse de référence validée par un expert métier pour chaque question
- Un jeu de test réécrit à chaque évaluation, empêchant toute comparaison dans le temps
Séparer ce qui relève de la recherche de ce qui relève de la génération
Un RAG échoue de deux manières distinctes qui appellent des corrections différentes : il ne trouve pas les bons documents, ou il les trouve mais répond mal avec. Confondre les deux fait corriger le mauvais maillon et gaspille le temps de correction.
Pour trancher, il faut examiner séparément deux éléments pour chaque question du jeu de test : les passages effectivement récupérés par le retrieval, et la réponse générée à partir de ces passages. Cette décomposition est précisément le premier réflexe d'un audit technique RAG et Agents IA : établir une taxonomie d'erreurs qui distingue défaut de données, de retrieval et de génération, plutôt qu'un simple constat global de mauvaises réponses.
Le RAG ne trouve pas
Symptôme observable : les documents pertinents ne figurent pas dans les passages récupérés, même en les cherchant manuellement dans le corpus. La réponse générée est cohérente avec ce qui a été retrouvé, mais ce qui a été retrouvé ne contient pas l'information demandée.
Les causes probables se trouvent en amont de la génération : chunking qui coupe l'information au mauvais endroit, embeddings mal adaptés au vocabulaire métier, absence de recherche par mots-clés en complément de la recherche sémantique, ou top-k trop restrictif. Notre article sur l'optimisation d'un RAG détaille ces leviers une fois le diagnostic posé.
Le RAG trouve mais répond mal
Symptôme observable : en vérifiant manuellement les passages récupérés, l'information nécessaire s'y trouve bien. Pourtant la réponse générée l'ignore, la déforme, ou ajoute des éléments absents des documents fournis.
Les causes se trouvent cette fois dans la génération : instructions de prompt insuffisamment strictes sur la fidélité aux sources, modèle trop enclin à compléter les trous par plausibilité, ou fenêtre de contexte saturée par des passages non pertinents qui diluent l'information utile.
| Symptôme observé | Maillon en cause | Métrique à surveiller | Piste de correction |
|---|---|---|---|
| Bon document absent des passages récupérés | Retrieval | Context recall | Chunking, hybrid search, top-k |
| Passages récupérés peu pertinents malgré une réponse correcte | Retrieval | Context precision | Reranking, filtres de métadonnées |
| Réponse contredit ou ignore un passage pourtant présent | Génération | Fidélité (faithfulness) | Prompt système, instructions de citation |
| Réponse correcte mais hors sujet par rapport à la question | Génération | Pertinence de la réponse | Reformulation du prompt, exemples guidés |
Les métriques qui ont un sens côté métier
Une métrique technique ne vaut que si elle se relie à une conséquence métier constatable. Un score de fidélité de 0,74 ne dit rien à un dirigeant. Le fait que 3 réponses sur 20 inventent une clause contractuelle qui n'existe pas, si.
Les métriques classiques de l'évaluation RAG (context precision, context recall, faithfulness, pertinence de la réponse) restent utiles pour localiser un problème, comme détaillé dans la section précédente. Mais pour arbitrer et prioriser, il faut les traduire.
| Métrique technique | Question métier associée | Conséquence si dégradée |
|---|---|---|
| Taux de bonnes réponses global | Sur 10 questions posées, combien reçoivent une réponse exploitable telle quelle ? | Les utilisateurs abandonnent l'outil et reviennent au collègue ou au moteur de recherche interne |
| Taux d'hallucination | Combien de réponses affirment quelque chose d'absent des documents sources ? | Décision prise sur une information fausse, risque juridique ou opérationnel |
| Taux de « je ne sais pas » correct | Le système reconnaît-il quand l'information n'existe pas dans le corpus ? | Un système qui invente plutôt que d'admettre une lacune perd la confiance des utilisateurs |
| Latence perçue | Le temps de réponse reste-t-il compatible avec l'usage réel (support en direct, préparation de dossier) ? | Contournement de l'outil sur les usages où la rapidité prime |
Le taux de bonnes réponses reste la métrique la plus lisible pour un dirigeant, à condition de préciser sa définition exacte : une réponse jugée « correcte » exige-t-elle l'exactitude totale, ou tolère-t-elle une réponse partielle mais utile ? Cette définition doit être fixée avant la première mesure, sans quoi deux évaluations successives ne sont pas comparables.
Évaluer avec un modèle juge, et connaître ses limites
Un modèle juge, ou LLM-as-a-judge, est un modèle de langage utilisé pour noter automatiquement les réponses d'un RAG sur des critères définis, à la place d'une relecture humaine exhaustive. Il rend l'évaluation de 50 à 150 questions réalisable en quelques heures plutôt qu'en plusieurs jours.
C'est l'approche la plus praticable pour une PME sans équipe MLOps : des outils comme RAGAS, DeepEval ou Arize Phoenix intègrent nativement des modèles juges pour calculer la fidélité, la pertinence et la couverture du contexte sur l'ensemble du jeu de test, sans notation manuelle question par question. DeepEval, par exemple, reste activement maintenu, avec une version publiée en juillet 2026.
Mais le modèle juge a des limites documentées qu'il faut connaître avant de lui faire confiance aveuglément. Le Judge Reliability Harness, publié par la RAND Corporation en mars 2026, a testé la fiabilité de plusieurs modèles juges et a constaté qu'aucun n'était fiable de façon uniforme d'un test à l'autre, la cohérence se dégradant sur de simples changements de mise en forme ou de reformulation. Les travaux JudgeBiasBench relèvent par ailleurs que certains modèles de pointe dépassent 50 % de taux d'erreur sur les benchmarks de biais les plus exigeants. Les biais identifiés incluent la préférence pour la position d'une réponse dans une comparaison, et la tendance à mieux noter des réponses proches de son propre style de génération.
Comment fiabiliser un modèle juge
- Faire noter un échantillon de 20 à 30 réponses par un humain, en parallèle du modèle juge
- Comparer les deux notations et ajuster le prompt d'évaluation en cas d'écart systématique
- Répéter cette calibration après tout changement de modèle juge, y compris une mise à jour de version
- Réserver la relecture humaine intégrale aux catégories de questions les plus sensibles (juridique, financier, sécurité)
Le modèle juge est un accélérateur de mesure, pas une autorité infaillible. Utilisé sans calibration, il donne un chiffre rassurant qui peut être faux. Utilisé avec un contrôle humain périodique, il rend l'évaluation régulière réellement tenable pour une petite équipe.
À quelle fréquence réévaluer, et comment détecter une dérive
Réévaluez systématiquement après tout changement touchant le pipeline : mise à jour du modèle, modification du prompt, ajout ou retrait de documents dans le corpus, changement de paramétrage du retrieval. C'est la seule façon de vérifier qu'un changement corrige effectivement le problème visé sans en créer un nouveau ailleurs.
En dehors de ces changements ponctuels, deux rythmes complémentaires suffisent pour la plupart des PME :
- Un contrôle mensuel sur l'intégralité du jeu de test, pour suivre l'évolution du taux de bonnes réponses dans le temps et détecter une régression lente.
- Un suivi hebdomadaire léger sur un échantillon de requêtes réelles récentes, pour repérer rapidement une dégradation liée à un changement de comportement des utilisateurs ou à une mise à jour du modèle par le fournisseur.
Une dérive (ou drift) se manifeste rarement par un effondrement brutal. Elle se voit d'abord dans une baisse progressive sur une catégorie précise de questions, souvent après un changement invisible pour l'équipe : le fournisseur de LLM met à jour son modèle en silence, un nouveau type de document arrive dans le corpus sans passer par le même pipeline d'ingestion, ou le vocabulaire des utilisateurs évolue à mesure que l'outil se diffuse dans l'entreprise.
Le signal le plus précoce n'est souvent pas la métrique automatique, mais le retour utilisateur : une hausse des reformulations de la même question, un pouce baissé plus fréquent sur une catégorie, ou un retour au canal humain pour un sujet auparavant traité par le RAG. Croiser ce signal qualitatif avec le score mensuel sur le jeu de test permet de confirmer une dérive avant qu'elle ne devienne un motif de plainte généralisé.
Notre article sur les erreurs qui font échouer un projet RAG revient sur un piège fréquent lié à ce sujet : l'absence de tout indicateur de suivi après le déploiement, qui laisse la dérive s'installer sans que personne ne s'en aperçoive avant plusieurs mois.
Ce que la baseline change concrètement pour une PME
Établir une baseline avant de corriger un système RAG ne demande ni équipe MLOps, ni outillage complexe. Un tableur, 30 à 50 questions réelles, une réponse de référence par question, et un score avant et après chaque changement suffisent à sortir du bricolage à l'aveugle.
Ce même principe de mesure avant intervention s'applique à toute architecture qui combine recherche et raisonnement, y compris les approches plus avancées comme l'Agentic RAG, où le nombre d'étapes intermédiaires rend une baseline encore plus indispensable pour localiser l'origine d'une erreur. C'est aussi vrai au moment du déploiement initial : notre guide pour déployer un assistant IA sur des documents internes recommande de fixer cette baseline dès le POC, avant l'industrialisation.
La correction d'un RAG n'est jamais un acte de foi. C'est un cycle mesurer, corriger, remesurer. Sans le premier chiffre, tout le reste n'est qu'une opinion.
Questions fréquentes
Votre RAG déçoit en production ?
Établissons la baseline avant toute correction.
Articles recommandés
- RAG en entreprise : comprendre les fondamentaux du Retrieval-Augmented Generation avant d'aborder son évaluation.
- Optimiser un RAG : les 5 leviers techniques à activer une fois la baseline établie et le diagnostic posé.
- Évaluer un LLM en entreprise : la méthode complète pour construire un golden dataset et comparer plusieurs modèles.
- 5 erreurs qui font échouer un projet RAG : les pièges à éviter, dont l'absence de suivi après déploiement.
- Agentic RAG : pourquoi la mesure devient encore plus critique quand le système raisonne en plusieurs étapes.
- Déployer un assistant IA sur vos documents internes : où placer la première baseline dans le cycle du projet.
