Évaluer les systèmes LLM en production : au-delà du vibe check

Tous les projets LLM que j'ai vus passent par la même première phase : quelqu'un lance le pipeline sur quelques exemples, lit les sorties, et dit "oui, ça a l'air bien." On expédie.

Le vibe check convient pour un prototype. Le problème, c'est ce qui se passe trois mois plus tard, quand on veut changer le prompt, remplacer le modèle ou ajuster le retrieval, et qu'on réalise qu'on n'a aucun moyen de savoir si le changement a amélioré ou dégradé les choses. Alors plus personne ne touche à rien. Le système se fossilise à "plutôt bien," tenu par la peur.

J'ai vécu ça sur un produit d'IA juridique, où "plutôt bien" n'est pas une réponse acceptable quand un avocat s'appuie sur la sortie. Voici la stack d'évaluation vers laquelle nous avons convergé, par ordre d'effort.

Niveau 1 : un golden dataset, même petit

L'artefact au meilleur ROI : un ensemble d'entrées réelles associées à des sorties validées comme bonnes. Pas des exemples synthétiques inventés, mais de vrais cas issus de la production, avec la réponse qu'un expert a validée.

Cinquante cas suffisent pour démarrer. La discipline est dans la curation : couvrir la majorité des cas faciles, mais sur-représenter délibérément les cas difficiles (la clause contractuelle ambiguë, la question sans réponse dans le corpus, l'entrée subtilement malformée). Votre dataset doit ressembler à vos cauchemars, pas à votre demo.

Puis la règle qui change tout : aucun changement de prompt, de modèle ou d'étape de retrieval n'est expédié sans avoir lancé le golden set. C'est un regression test, exactement comme en ingénierie classique, sauf que les assertions sont plus floues. Ce qui nous amène au scoring.

Niveau 2 : scoring, déterministe quand c'est possible, LLM-judge sinon

Certaines sorties se vérifient mécaniquement. Tâches d'extraction : les dates, les montants, les noms des parties correspondent-ils ? Classification : comparaison exacte du label. Structured output : ça parse, ça valide contre le schema ? Faites-le partout où vous le pouvez ; c'est peu coûteux et sans ambiguïté.

Pour les sorties en texte libre (résumés, analyses, recommandations), il vous faut un juge, et l'option pragmatique est un LLM qui note contre un rubric. Ça marche, avec des réserves que j'ai apprises à la dure :

• Un juge a besoin d'un rubric, pas d'un ressenti. "Note ça de 1 à 10" produit du bruit. "Le résumé mentionne-t-il la clause de résiliation ? oui/non. Invente-t-il un fait absent de la source ? oui/non" produit du signal. Décomposez la qualité en vérifications binaires.
• Calibrez le juge contre des humains avant de lui faire confiance. Prenez 30 cas, faites-les scorer par des experts, faites-les scorer par le juge, mesurez l'accord. Le nôtre sur-récompensait au départ les réponses confiantes et bien écrites mais subtilement fausses, le même biais que celui du modèle sous-jacent. Nous avons corrigé le rubric jusqu'à ce que l'accord soit acceptable. Sauter cette étape revient à automatiser votre propre angle mort.
• Utilisez comme juge un modèle différent de celui qui génère, ou au minimum une configuration différente. Un modèle qui corrige sa propre copie est exactement aussi fiable que ça en a l'air.

Niveau 3 : la production est la vraie eval

Les evals offline vous disent qu'un changement est sûr à expédier. Elles ne vous disent pas que le système fonctionne pour de vrais utilisateurs sur du vrai trafic, parce que les entrées de production dérivent d'une manière que votre golden set aura toujours du retard à suivre.

Trois choses ont prouvé leur valeur :

Loggez tout, en structure. Chaque génération : contexte d'entrée complet, sortie, version du modèle, version du prompt, latence, comptes de tokens. C'est votre matière première. Quand un utilisateur signale une mauvaise sortie, vous rejouez le contexte exact au lieu de deviner. Et ça alimente l'itération suivante du golden dataset : l'échec en production d'hier est le cas de regression test de demain.

Signaux online peu coûteux. L'utilisateur a-t-il réessayé la question ? Lourdement édité le brouillon généré ? Abandonné le flux ? Aucun de ces signaux n'est un score de qualité, mais ils se regroupent autour des problèmes et vous indiquent où regarder.

Échantillonnage human-in-the-loop. Chaque semaine, un expert métier passe en revue un échantillon de sorties de production contre le rubric. Sur le produit juridique, ce rituel de calibration a fait apparaître l'écart entre ce que disaient nos métriques et ce que voyaient les experts : la même leçon que celle apprise sur le scoring analytique. Le difficile n'est jamais le calcul, c'est l'alignement entre la mesure et la vérité terrain.

La boucle compte plus que n'importe quel composant isolé. Les échecs de production deviennent des golden cases, les golden cases conditionnent les releases, les releases génèrent des logs, les logs alimentent la revue par les experts. Un flywheel, pas une checklist.

Ce que ça coûte, honnêtement

Construire tout ça a pris quelques semaines étalées sur un trimestre, plus une heure ou deux récurrentes de temps d'expert par semaine. Ce temps d'expert est la partie à laquelle les équipes résistent : détourner un avocat senior ou un responsable CS de son travail pour noter des sorties paraît coûteux.

C'est l'assurance la moins chère que vous achèterez jamais. L'alternative, c'est le système fossilisé : personne n'ose changer le prompt, les montées de version du modèle sont reportées de mois en mois, et les discussions sur la qualité se font par anecdote et par séniorité plutôt que par la donnée. J'ai vu une équipe débattre pendant deux semaines pour savoir si un changement "semblait meilleur." La run d'eval aurait pris vingt minutes.

Ce que je me dirais au départ

Commencez le golden dataset le jour où vous commencez le prototype, pas le mois avant le lancement. Chaque cas intéressant que vous rencontrez pendant le développement est un cas d'eval gratuit, alors capturez-le à ce moment-là, parce que le reconstruire plus tard est pénible.

Et acceptez que les evals pour les systèmes LLM ne sont jamais terminées, contrairement aux tests pour du code déterministe. La distribution se déplace, les modèles changent, les utilisateurs vous surprennent. L'objectif n'est pas un score parfait. L'objectif, c'est de pouvoir changer votre système sans crainte. C'est ce que les evals vous achètent, et ça vaut chaque heure.