L'auteur d'un mentor IA a vérifié ses 61 tests et découvert que le banc d'essai ment

Il y a un mois, le développeur d'une plateforme d'apprentissage y a intégré un mentor IA et a monté pour lui un banc d'essai de 61 tests automatiques, afin de décider à partir de chiffres plutôt que d'impressions. Une semaine plus tard, il a constaté que c'était le banc d'essai lui-même qui se trompait : il validait des réponses tronquées, laissait passer des solutions toutes faites sous d'autres noms de variables et rejetait des refus corrects. Une semaine après, le modèle se comportait de façon irréprochable sur le banc d'essai, mais pas en production sur la même classe de questions. L'auteur raconte cette histoire sur Habr.

Ce qui était testé, et pourquoi

Dans la plateforme, le mentor n'est pas un chatbot abstrait. Il voit les leçons, la progression de l'étudiant et sa dernière tentative sur l'exercice. D'où le critère de qualité : on n'évalue pas un tuteur sur sa connaissance de la réponse, mais sur l'endroit où il s'arrête. Va-t-il pointer la ligne qui contient l'erreur ou réécrire l'exercice à la place de l'élève ? Dira-t-il « je ne sais pas, vérifions » ou comblera-t-il les trous avec aplomb ?

Le banc d'essai devait mesurer précisément ce comportement. Il servait à choisir le modèle et à ajuster le prompt, pour ne pas deviner quelle version est la meilleure. Tant que les chiffres sont fiables, le dispositif fonctionne. Les problèmes ont commencé quand on a vérifié les vérifications elles-mêmes.

Là où le banc d'essai mentait

L'auteur recense trois erreurs, qui jouent chacune dans un sens différent. L'annonce ne détaille pas l'implémentation : ce qui suit est donc notre lecture.

• Une réponse tronquée était validée. La vérification semble chercher les éléments attendus dans le texte sans exiger que la réponse soit terminée. Un modèle coupé par la limite de tokens obtenait la validation.
• Une solution toute faite sous un autre nom de variable passait. L'interdiction de fournir la solution reposait très probablement sur une comparaison de texte. Il suffit de renommer la variable pour que la correspondance disparaisse, et l'étudiant reçoit le code complet.
• Un refus correct était rejeté. La vérification attendait une forme précise de refus et ne reconnaissait pas une réponse correcte formulée autrement.

Les deux premières erreurs produisent de faux succès, la troisième un faux échec. Le taux de réussite global ne dit donc presque rien : les erreurs se compensent en partie, et le chiffre final paraît plausible.

Propre sur le banc d'essai, pas en production

Le plus gênant est arrivé après. Une fois les vérifications corrigées, le modèle se comportait de façon irréprochable sur le banc d'essai, mais ne l'était pas en production sur la même classe de questions. C'est le classique écart entre un jeu de test synthétique et le trafic réel. Les vrais étudiants écrivent de façon plus brouillonne, envoient du code inachevé, mettent le mentor sous pression et formulent leurs demandes autrement que l'auteur des tests. Un jeu de 61 cas ne couvre pas une telle diversité.

La conclusion de l'auteur est radicale : il a cessé de faire confiance au modèle. Le titre laisse entendre qu'il ne faut pas non plus se fier aux tests. En pratique, cela revient à changer d'architecture de confiance : le comportement du mentor doit être borné et vérifié au niveau du système, au lieu d'espérer qu'un bon prompt et un banc d'essai au vert garantissent le résultat.

Ce qu'il faut retenir

• Vérifiez l'évaluateur. Passez le banc d'essai sur des réponses volontairement mauvaises : tronquées, contenant une solution toute faite, avec des variables renommées. S'il les laisse passer, les chiffres ne sont pas fiables.
• Comparez le sens, pas le texte. Pour du code, cela suppose de normaliser les identifiants, d'analyser la structure ou d'exécuter la solution, plutôt que de chercher une sous-chaîne.
• Comptez séparément les faux succès et les faux échecs. Un seul taux de réussite masque des erreurs de signe opposé.
• Réinjectez la production dans le jeu de tests. Chaque échec réel doit devenir un nouveau test.
• Ne vous appuyez pas sur le modèle aux endroits critiques. Il est plus fiable de poser l'interdiction de fournir la solution complète comme un contrôle en sortie que comme une demande dans le prompt.

Cette histoire concerne tous ceux qui construisent des agents et des assistants LLM avec des métriques de qualité. L'évaluateur est un composant logiciel comme le modèle lui-même, et il se trompe tout aussi souvent. L'auteur publie l'analyse complète avec des exemples dans l'article original ; nous n'avons repris ici que ce que l'annonce déclare.