Votre RAG a 97% de réussite ? Attention au piège du 'bachotage'

Autour de la machine à café, on entend souvent des affirmations qui laissent sans voix. Celle-ci en fait partie : « On a construit une application RAG qui fonctionne très bien. On est en phase d'évaluation, et ça se passe à merveille parce qu'on identifie des problèmes et on les corrige au fur et à mesure. On est déjà à 97% de réussite. »

UNE AFFIRMATION QUI PARAÎT PARFAITE… MAIS QUI CACHE UN PIÈGE

À première vue, cette phrase semble tout à fait raisonnable. Repérer des problèmes et les corriger, c'est exactement ce qu'un bon processus d'évaluation devrait faire, non ? C'est même responsable. Alors, où est le problème ?

Le souci est subtil mais fondamental. Si vous utilisez votre processus d'évaluation pour identifier des problèmes, les corriger, puis réévaluer sur le même jeu de tests, vous n'évaluez plus vraiment. Un jeu d'évaluation a une propriété essentielle : le modèle ne l'a jamais vu auparavant. Chaque fois que vous affinez le modèle en fonction de ses résultats et que vous réévaluez sur le même jeu, vous lui retirez un peu plus cette propriété. En d'autres termes, le jeu d'évaluation est devenu un jeu d'entraînement sans que vous vous en rendiez compte.

LE PROBLÈME DU SURAPPRENTISSAGE : QUAND LE MODÈLE MÉMORISE AU LIEU D'APPRENDRE

Pour comprendre ce phénomène, faisons un détour par les bases du machine learning. Un modèle est généralement construit à partir de trois ensembles de données : un jeu d'entraînement, un jeu de validation et un jeu de test.

Le modèle est d'abord ajusté sur le jeu d'entraînement, qui sert à indiquer quel type de modèle utiliser et à ajuster ses paramètres. Ensuite, on utilise le modèle entraîné pour prédire les résultats sur le jeu de validation. Pour chaque donnée du jeu de validation, on génère une prédiction et on compare avec la réponse réelle pour ajuster le modèle.

Enfin, une fois le modèle choisi, on le teste sur le jeu de test. L'objectif du jeu de test est de voir comment le modèle généralise sur des données qu'il n'a jamais vues, en calculant ses scores. C'est pourquoi le jeu de test ne doit être utilisé qu'une seule fois.

L'objectif n'est pas de faire correspondre parfaitement le jeu d'entraînement, mais ce qu'il représente. Ainsi, on crée des modèles qui apprennent suffisamment les motifs sous-jacents pour faire des prédictions précises sur de nouvelles données.

Malheureusement, parfois, on échoue et on crée des modèles qui correspondent parfaitement à un jeu d'entraînement étroit sans généraliser. C'est ce qu'on appelle le surapprentissage. Résultat : le modèle performe exceptionnellement bien sur le jeu d'entraînement, avec des scores impressionnants, mais mal sur tout ce qui est nouveau.

POURQUOI LE SURAPPRENTISSAGE EST SI DANGEREUX DANS LES APPLICATIONS RAG

Revenons à notre exemple autour de la machine à café. L'équipe en question utilise son jeu d'évaluation pour identifier des problèmes, les corrige, puis réévalue sur les mêmes paires de questions et réponses. Naturellement, à chaque itération, les scores d'évaluation s'améliorent parce qu'ils ajustent l'application RAG sur le jeu de test.

Voici les façons les plus courantes dont cela peut se produire dans les applications RAG :

• Corriger les réponses du modèle en fonction des résultats du jeu de test.
• Ajuster les paramètres de récupération (retrieval) pour améliorer les scores sur le jeu de test.
• Modifier les prompts ou les instructions pour obtenir de meilleurs résultats sur le jeu de test.

La solution simple mais difficile pour éviter cela est la même que dans le machine learning classique : gardez un jeu de test véritablement réservé, que vous utilisez le moins possible. Construisez vos questions indépendamment du comportement connu du système et traitez avec scepticisme les métriques trop belles pour être vraies. Un système RAG qui performe à merveille sur un petit jeu d'évaluation soigneusement sélectionné et réutilisé fréquemment ressemble beaucoup à un étudiant qui a mémorisé les anciens sujets d'examen mais qui est complètement perdu face à une question réelle qui ne ressemble pas à celles qu'il a déjà vues.

COMMENT VÉRIFIER SI VOTRE PROCESSUS D'ÉVALUATION EST FIABLE

Si vous voulez vérifier la solidité de votre processus d'évaluation RAG, voici une liste de questions à vous poser honnêtement :

• Avez-vous un jeu de test réservé que vous n'utilisez qu'une seule fois ?
• Vos questions d'évaluation sont-elles construites indépendamment du comportement connu de votre système ?
• Vos métriques d'évaluation sont-elles basées sur des données que le modèle n'a jamais vues ?
• Vos scores d'évaluation reflètent-ils vraiment les performances en production ?

Si vous avez répondu non à la dernière question, vous pourriez déjà être l'équipe de notre histoire autour de la machine à café.

LA LOI DE GOODHART : QUAND UNE MESURE DEVIENT UN OBJECTIF

La loi de Goodhart, formulée par l'économiste Charles Goodhart en 1975, est une sorte de proverbe qui dit : « Quand une mesure devient un objectif, elle cesse d'être une bonne mesure. »

Cette idée vient initialement de la politique monétaire, mais elle se généralise bien au-delà de l'économie. On la retrouve presque partout où un nombre est utilisé pour juger des performances, comme les KPI, les budgets ou toutes sortes de chiffres.

Imaginez un vendeur de voitures récompensé en fonction du nombre de voitures vendues chaque mois. Il pourrait finir par vendre plus de voitures, même à perte. Ou des hôpitaux qui cherchent à réduire la durée de séjour des patients et qui finissent par les libérer trop tôt. Ou encore des comptes de citations dans les publications scientifiques qui sont manipulés. Tous ces exemples fonctionnent avec le même mécanisme sous-jacent : une mesure quantitative est introduite pour suivre quelque chose d'important. Pendant un moment, la mesure et la réalité évoluent ensemble, et on a l'impression de pouvoir faire confiance à l'évolution de la mesure pour suivre celle de la réalité. Puis les gens (ou les systèmes) commencent à optimiser directement pour la mesure au lieu de l'objectif sous-jacent, et les deux se séparent discrètement. La mesure commence alors à s'améliorer sans que la réalité qu'elle était censée représenter ne s'améliore de la même manière.

Dans le domaine de l'IA, ce mode de défaillance s'appelle le reward hacking. Cela se produit lorsqu'un système d'IA optimise une récompense mal spécifiée sans atteindre réellement l'objectif visé. De même, dans le machine learning classique, le surapprentissage est ce qui arrive à un modèle lorsque le signal d'entraînement cesse de représenter le motif sous-jacent réel. La loi de Goodhart, c'est ce qui arrive aux humains qui conçoivent le système lorsque le signal d'évaluation cesse de représenter ce dont ils se soucient réellement.

POURQUOI LE SURAPPRENTISSAGE EST SI DANGEREUX DANS LES APPLICATIONS RAG

Ce qui est intéressant avec le surapprentissage, surtout dans les applications RAG, c'est qu'il ne s'agit pas vraiment d'un problème technique. C'est principalement un problème de compréhension et de respect du processus. Il est tentant de compromettre ce processus et d'optimiser directement pour les scores, surtout avec des jeux de données RAG qui ne ressemblent pas à ceux auxquels nous sommes habitués dans le machine learning classique.

Pourtant, ce schéma apparaît bien au-delà du machine learning et de l'IA. Dans la vie réelle comme dans le machine learning, le remède est le même : rester cohérent et ne jamais perdre de vue l'objectif réel que vous essayez d'atteindre. Dans le machine learning et l'IA, cet objectif est que le modèle fonctionne réellement et produise des résultats significatifs une fois en production, face à des données réelles, et non pas simplement pour obtenir des scores élevés pendant l'évaluation.

L'équipe de notre histoire autour de la machine à café ne fait rien de malveillant. Au contraire, ce qu'elle fait semble responsable : affiner l'application en fonction des résultats d'évaluation. Et c'est précisément ce qui rend le surapprentissage si dangereux. Cela ne ressemble pas à une erreur sur le moment. Cela ne ressemble à une erreur qu'à posteriori, une fois que le système rencontre le monde réel et que les scores ne tiennent plus.

COMMENT ÉVITER DE TOMBER DANS LE PIÈGE

Si vous voulez vous assurer que votre processus d'évaluation RAG est solide, voici quelques bonnes pratiques à suivre :

• Gardez un jeu de test réservé : Utilisez-le uniquement une fois, jamais pour ajuster le modèle.
• Construisez des questions indépendantes : Vos questions d'évaluation ne doivent pas être influencées par le comportement connu du système.
• Traitez les métriques avec scepticisme : Un score parfait sur un petit jeu d'évaluation n'est pas toujours représentatif des performances réelles.
• Documentez votre processus : Assurez-vous que chaque membre de l'équipe comprend l'importance de ne pas toucher au jeu de test.

LE VERDICT : VOTRE MODÈLE DOIT FONCTIONNER EN PRODUCTION, PAS SEULEMENT EN ÉVALUATION

Le surapprentissage est un piège subtil qui guette tous les projets d'IA, surtout ceux utilisant des applications RAG. Il est facile de se laisser emporter par l'envie d'améliorer les scores d'évaluation, mais cela peut conduire à un modèle qui performe bien en test et mal en production.

Rappelez-vous : l'objectif n'est pas d'avoir un modèle qui performe à 97% sur un jeu d'évaluation fermé, mais un modèle qui fonctionne correctement face à des données réelles et variées. Le surapprentissage est comme un étudiant qui a mémorisé ses cours : il peut réussir un examen, mais il sera perdu face à une question inédite.

En respectant les bonnes pratiques d'évaluation et en gardant un jeu de test réservé, vous pouvez éviter ce piège et construire des applications RAG qui tiennent vraiment leurs promesses.