Le Guide Définitif des Evals : Commencez avec 100 Revues Manuelles et un 'Dictateur Bienveillant'

Perspective

Voici Hamel Hussein et Shrea Shankar - enseignants du cours d’eval n°1 sur Maven, qui ont formé plus de 2 000 PMs et ingénieurs, y compris des équipes chez OpenAI et Anthropic. Leur processus est étonnamment manuel au début, et c’est justement le but.

“La principale idée fausse est : l’IA ne peut-elle pas simplement l’évaluer ?” Ça ne marche pas. Quand Hamel a montré une trace où une IA a planifié une visite virtuelle qui n’existait pas, ChatGPT a dit “ça a l’air bien” car il manque le contexte pour savoir que cette fonctionnalité n’existe pas. L’expert du domaine le détecte en quelques secondes. Les LLMs ratent l’intuition produit.

Le processus : open coding avec un dictateur bienveillant. Examinez les traces (logs des interactions LLM). Écrivez des notes rapides sur ce qui ne va pas - juste la première erreur ou l’erreur la plus en amont que vous voyez. N’essayez pas de tout trouver. N’utilisez pas de comités. Nommez une personne dont vous faites confiance au jugement (l’expert du domaine). Restez informel : “jank” est acceptable comme note. Faites au moins 100 traces jusqu’à atteindre la “saturation théorique” - quand vous cessez d’apprendre de nouvelles choses.

L’analyse d’erreurs précède l’écriture de tests. C’est différent de l’ingénierie logicielle où vous passez directement aux tests unitaires. Avec les LLMs, la surface d’attaque est trop grande et le comportement trop stochastique. Vous avez d’abord besoin d’une analyse de données pour comprendre ce qu’il faut même tester. Ce n’est qu’après l’open coding que vous codifiez les patterns en evals automatisés.

L’exemple de l’agent immobilier est parfait. L’utilisateur demande la disponibilité. L’IA dit “nous n’avons pas ça, bonne journée.” Techniquement correct. Du point de vue produit ? Terrible. Un outil de gestion de leads devrait transférer à un humain, pas fermer la conversation. C’est le genre de chose que seul un product manager détecte.

Ne rendez pas les evals coûteuses. Scores binaires uniquement (réussi/échoué). Un expert du domaine, pas un comité. Échantillonnez vos données, ne révisez pas tout. L’objectif n’est pas la perfection - c’est l’amélioration actionnable. Si vous rendez le processus coûteux, vous ne le ferez pas.

Points Clés

• Les LLMs ne peuvent pas faire l’analyse d’erreurs - Ils manquent de contexte ; disent “ça a l’air bien” sur des échecs produit évidents
• Open coding - Écrivez des notes rapides sur la première erreur ; ne trouvez pas tout ; soyez informel
• Dictateur bienveillant - Un expert du domaine dont vous faites confiance au jugement ; pas de comités
• 100 traces minimum - Jusqu’à saturation théorique ; vous deviendrez accro après 20
• Saturation théorique - Arrêtez quand vous cessez d’apprendre de nouvelles choses
• Scores binaires uniquement - Réussi/échoué ; ne faites pas d’échelles 1-5 ; rend tout gérable
• Analyse d’erreurs → tests - Différent de l’ingénierie logicielle ; comprendre avant de codifier
• Product manager requis - Les ingénieurs ratent l’intuition produit ; l’expertise du domaine est critique
• Échantillonnez, ne révisez pas tout - Rend le processus durable
• “Jank” est valide - Gardez les notes informelles ; la spécificité compte plus que le raffinement

Vue d’Ensemble

L’eval IA n’est pas des tests automatisés - c’est de l’analyse de données nécessitant un jugement humain. Les entreprises qui livrent des produits IA fiables n’utilisent pas de frameworks sophistiqués ; elles mettent des experts du domaine devant des traces et les laissent développer leur jugement. Il n’existe pas de raccourci.