L’évaluation des systèmes d’IA générative augmentée par retrieval, ou RAG, fait face à un défi récurrent et souvent sous-estimé : le surapprentissage, ou overfitting. Ce phénomène se produit lorsque les équipes de développement utilisent leur propre jeu de données d’évaluation pour identifier les erreurs, corriger le système, puis le réévaluer sur les mêmes questions. Bien que cette approche semble responsable, elle transforme progressivement le jeu d’évaluation en jeu d’entraînement. La métrique obtenue cesse alors de refléter la capacité réelle du modèle à généraliser sur des données invisibles. En apprentissage automatique classique, la séparation stricte entre les ensembles d’entraînement, de validation et de test garantit que le modèle apprend des motifs sous-jacents et non des exemples spécifiques. Dans le contexte des applications RAG, cette frontière s’estompe facilement. Les ingénieurs peurent à identifier des échecs récurrents lors des tests, ajustent les prompts ou la logique de récupération, et constatent une hausse systématique des scores. Cette amélioration n’indique pas une meilleure performance globale, mais un ajustement excessif aux exemples de test. Plusieurs pratiques courantes accélèrent ce risque. Premièrement, l’optimisation directe des instructions système sur les questions d’évaluation. Deuxièmement, le choix sélectif d’exemples que le système maîtrise déjà, créant un ensemble de test biaisé vers les forces de l’outil au détriment de ses angles morts. Troisièmement, la formulation des questions de test à partir des mêmes documents utilisés pour l’indexation. Dans ce dernier cas, les données de test ne sont jamais véritablement indépendantes, ce qui fausse les indicateurs de performance tels que la précision, le rappel ou le score NDCG. Ce problème dépasse la simple technique et s’inscrit dans le cadre de la loi de Goodhart, selon laquelle une mesure devient inefficace lorsqu’elle est utilisée comme objectif direct. Dans l’IA, ce mécanisme se rapproche du hacking de récompense, où un système optimise un signal mal défini sans atteindre le résultat attendu. Sur le plan organisationnel, il s’agit d’un problème de rigueur méthodologique. Les équipes cherchent naturellement à obtenir des scores élevés pour valider leurs développements, mais cette optimisation prématurée compromet la robustesse en environnement de production. La solution repose sur une discipline stricte : conserver un jeu de données de test strictement indépendant, non consulté durant les phases itératives de développement. Les questions doivent être générées indépendamment du comportement connu du système et couvrir des scénarios variés et inattendus. Une métrique exceptionnellement élevée obtenue sur un ensemble de test réutilisé doit alerter les ingénieurs plutôt que les rassurer. À l’instar d’un étudiant qui mémoriserait les sujets d’examens précédents, une application RAG parfaitement ajustée sur des données connues échouera face aux requêtes réelles des utilisateurs finaux. En résumé, la fiabilité d’un pipeline RAG ne se mesure pas à sa capacité à satisfaire un benchmark, mais à sa résilience face à des données non vues. La prévention du surapprentissage exige de séparer clairement les phases d’itération et d’évaluation finale, et de privilégier une validation sur des jeux de données maintenus à l’écart du processus d’entraînement et d’optimisation. Cette rigueur garantit que les indicateurs de performance restent fidèles à l’usage réel en production.