Évaluer un LLM avant la prod, comme un test

Ce qui se passe

L'équipe GitHub qui a branché un LLM sur le secret scanning — la détection d'identifiants commités par erreur — publie sa méthode d'évaluation. L'objectif du système n'était pas de « classer des chaînes », mais de réduire les faux positifs : beaucoup de chaînes ressemblent à un secret sans en être un, et chaque alerte inutile coûte du temps à un développeur.

Le constat de départ vaut pour tout le monde : un modèle peut très bien se comporter sur un banc d'essai propre et échouer sur les cas qui comptent en production. Les entrées réelles sont ambiguës, les étiquettes incohérentes, le contexte parfois tronqué, et les cas rares dans un benchmark deviennent les premières causes de panne en vrai.

Les trois idées à retenir

1. Partir de la décision produit, pas du modèle

Quand un système à base de LLM déçoit, le réflexe est de réécrire le prompt, d'ajouter du contexte, de changer de modèle. À faire après avoir défini la décision que l'évaluation doit éclairer.

Ici, la question était : peut-on réduire les faux positifs tout en gardant assez de rappel pour rester sûr ? D'où une hiérarchie de critères, qui ne sont surtout pas interchangeables :

• Résultat principal — le bénéfice visé : baisse des faux positifs, précision.
• Contrainte de sûreté — le rappel. Supprimer par erreur une alerte correspondant à un vrai identifiant est plus grave que d'en faire relire une de trop. Une expérience n'avance que si la perte de rappel reste dans une marge fixée à l'avance.
• Garde-fous opérationnels — latence, coût, fiabilité, compatibilité avec le système existant.

Une expérience qui améliore beaucoup la précision en passant sous le seuil de rappel n'avance pas. Une autre qui améliore la qualité en rendant le système trop lent ou trop cher non plus.

2. Traiter l'évaluation hors ligne comme un test d'intégration

Un système à base de LLM continue de changer après sa première évaluation réussie : prompts revus, modèle remplacé, contexte construit autrement, logique métier ajustée. Chacun de ces changements peut améliorer, casser, ou déplacer le problème.

D'où deux disciplines empruntées au test :

• Rejouer l'évaluation à chaque changement significatif, en enregistrant à chaque exécution le prompt, le modèle, la version du jeu de données et la configuration. Sans cela, on compare des résultats obtenus dans des conditions différentes et on attribue le gain au mauvais changement.
• Ne changer qu'une variable majeure à la fois. Le billet donne l'exemple d'une révision de prompt évaluée séparément d'une montée de modèle, avant de tester les deux ensemble.

Les prompts et les configurations d'évaluation se versionnent comme du code, avec un retour arrière possible. Le suivi tient dans un tableau : identifiant d'exécution, version de prompt, version de modèle, précision, rappel, latence, note.

Corollaire utile : quand un système sous-performe, on empile des instructions dans le prompt. Or une partie de cette complexité vient du modèle lui-même — un modèle plus récent fait parfois mieux avec un prompt plus simple qu'un ancien longuement réglé. Encore faut-il que l'évaluation soit assez peu coûteuse pour que tester un nouveau modèle devienne une routine.

3. Garder l'évaluation proche de la production

Une évaluation hors ligne ne vaut que si elle ressemble à la tâche réelle. En secret scanning, le modèle n'examine presque jamais une valeur isolée et propre : il juge un candidat au milieu du code environnant, avec des informations utiles, incomplètes, parfois distrayantes.

Le jeu d'évaluation doit donc préserver le candidat évalué, le contexte disponible, la mise en forme et les contraintes d'entrée, et la logique qui entoure le modèle. Un jeu de données trop propre retire précisément les cas ambigus qui font échouer le système — et produit un score flatteur.

À retenir

Rien de tout cela n'est spécifique aux LLM : ce sont des réflexes de test et de mesure, appliqués à un composant non déterministe. La partie la plus facile à négliger reste la première — décider ce qu'on optimise, et ce qu'on refuse de sacrifier pour l'obtenir.

Source : GitHub Blog