Évaluer des LLM en production

1L'évaluation est une décision, pas un score

Un feu rouge en intégration continue ne dit pas « le code est à 7,3 sur 10 », il dit « on ne déploie pas ». Pour un LLM, les auteurs veulent pareil : « l'évaluation n'est pas un nombre, c'est un système de décision » (leçon 4). Il a quatre pièces. La preuve est ce que vous mesurez, l'incertitude dit combien vous pouvez la croire, le seuil est la frontière fixée à l'avance, l'action est ce que vous faites quand la frontière est franchie.

Exemple : on livre si la justesse du routage atteint 90 % au total et 88 % sur chaque intention critique. Sans seuil, « les métriques ne sont pas actionnables et les sorties deviennent des débats » (leçon 4). Les chiffres sont des illustrations : « les chiffres exacts dépendent du produit » (leçon 8). Le livre garde deux ou trois métriques décisives par axe (qualité, sécurité, coût, fiabilité), le reste explique pourquoi elles ont bougé.

2Le bon évaluateur est le moins cher qui tienne

Avant de payer un juge LLM, demandez-vous si une ligne de code peut trancher. Le livre empile quatre évaluateurs. Les validateurs déterministes vérifient ce qui est vrai ou faux, comme un JSON qui s'analyse. Les métriques à référence comparent à une étiquette, comme la catégorie d'un ticket. Le LLM-juge, un modèle chargé de noter les sorties d'un autre, couvre le subjectif. Les humains gardent les cas à risque. La règle : « choisir l'évaluateur le moins cher qui est fiable pour le mode de panne, puis n'escalader que si nécessaire » (leçon 11).

« Le remboursement a été effectué » n'est pas un problème de style. Le validateur lit la trace (le journal des appels d'outils) et cherche un appel de facturation réussi avant cette phrase.

3Le juge LLM est un instrument bruité, versionné comme du code

Une balance qui change de tare entre deux pesées ne vous apprend rien sur la farine. Les sorties d'un juge sont de même « des mesures bruitées, pas une vérité de terrain » (leçon 11). Le livre liste les défauts sans les chiffrer : incohérence d'un passage à l'autre, sensibilité à la rubrique (la grille de notation donnée au juge), goût pour les réponses longues.

Le remède tient en gestes concrets. Rubrique fixe, une dimension à la fois, échelle simple, preuve citée par le juge. Calibration, c'est-à-dire comparer ses notes à celles des humains, avec le conseil de calibrer sur « un petit jeu noté par des humains » (leçon 11). Puis versionner modèle, prompt et rubrique. Si le juge change, l'ancien et le nouveau notent le même jeu de calibration avant qu'on compare les courbes (leçons 17 et 58). Dernier piège, énoncé pour les juges de modèles de vision mais valable pour le texte : un juge qui hallucine comme le modèle évalué « confirmera ses hallucinations au lieu de les attraper » (leçon 58). D'où un juge d'une autre famille de modèles, ou calibré sur des jugements humains, avec une calibration suivie dans la durée.

Limite honnête : aucun taux de biais, aucun protocole de calibration chiffré. Le kappa (un accord entre évaluateurs corrigé du hasard) n'apparaît que dans un seul paragraphe de tout le texte, au détour de l'annotation de données (leçon 70). Le seul seuil donné est celui d'un alpha de Krippendorff, au moins 0,67, « sous réserve d'examen du domaine ».

4Ne pas réagir au bruit : intervalle et changement minimal

8,10 puis 8,18 ne prouve rien si deux passages identiques diffèrent déjà de 0,2. Le livre ajoute à chaque métrique bruitée un intervalle de confiance, la fourchette où la vraie valeur tombe avec une probabilité donnée. Méthode accessible, le bootstrap : on retire au hasard, avec remise, des cas parmi ceux évalués, on recalcule la moyenne, on répète, et la fourchette sort de la dispersion.

Avant de crier à la régression (une baisse qui justifie d'agir), le livre pose quatre questions. Le changement dépasse-t-il la variation d'un passage à l'autre, et le changement minimal utile, le plus petit écart qui modifierait une décision ? Se concentre-t-il dans une tranche critique ? Franchit-il un seuil ? La question de fond n'est pas « le nombre a-t-il bougé », mais « a-t-il bougé assez pour changer la décision » (leçon 13).

5La boucle fermée : chaque incident devient un cas de test

Hors ligne, un jeu de cas fige la configuration et bloque une version qui régresse. Un canary (une mise en ligne sur une petite part du trafic) surveille ensuite. En ligne, on journalise, on mesure la dérive, on échantillonne pour relecture. Chaque incident repart dans la suite de tests : elle devient, dit le livre, « une mémoire de ce qui a cassé » (leçon 15). Sans traces, « les incidents restent des anecdotes » (leçon 17).

Deux précisions m'ont servi. Le jeu de développement, qu'on retouche, reste séparé du hold-out (jeu de réserve), qui sert aux décisions de sortie et sur lequel on ne règle jamais rien, sous peine d'optimiser contre ses propres examens. Une porte trop nerveuse provoque une « fatigue du retour arrière » (leçon 14) et l'équipe relève les seuils sans analyse.

6Contrat de sortie, boucle bornée, affirmation liée à une preuve

Un formulaire en ligne refuse une date fantaisiste avant d'ouvrir un dossier. Le livre l'exige de la sortie du modèle avec un contrat : champs et types attendus, souvent en JSON. Il y voit « une couche de contrôle, pas une métrique de qualité » (leçon 32). Il garantit une sortie utilisable, pas juste. Autour vient la boucle rejet-réparation, en trois règles : réparer seulement quand la réparation est « strictement syntaxique et sûre », basculer vers un repli quand le sens est ambigu, plafonner les essais. Chaque relance allonge la latence de queue et le coût (leçon 32).

# de mon cru, avec parse_json_object et contract_error du livre
brut = appeler_modele(prompt)
for essai in range(MAX_ESSAIS):
    obj = parse_json_object(brut)
    erreur = "json_invalide" if obj is None else contract_error(obj)
    if erreur is None:
        return obj
    if not reparable_syntaxiquement(brut):   # virgule en trop : oui. Sens douteux : non.
        break
    brut = reparer(brut)
return repli_sur(erreur)                     # gabarit sûr, code d'erreur journalisé

Le contrôle voisin est le plus fort. « Confirmer un remboursement n'est pas une tâche d'écriture », c'est une affirmation qui doit reposer sur une preuve exécutée (leçon 33). La porte lie la phrase à un indicateur tiré de la trace, pas à ce que le modèle déclare de lui-même. Si l'indicateur manque, on bloque la réponse, on replie sur un gabarit sûr et on ouvre un incident.

7Évaluer un agent marche par marche

Un agent qui annule une commande peut lire un mauvais statut, choisir le mauvais outil, réessayer sans progrès, puis annuler quand même. Le livre découpe donc l'évaluation en huit marches : validation de l'entrée et de l'état, choix de l'action, exécution, reprise, détection de boucle, achèvement, sécurité, latence et coût (leçon 102). Le texte ironise : dire « l'agent a échoué » n'est « pas une analyse de cause racine utile » (leçon 102).

Quatre idées en sortent.

• L'état final, pas la trajectoire : « le point clé n'est pas de savoir si l'agent suit exactement une trajectoire de référence » (leçon 102).
• L'échec d'un outil se classe (délai, droits, schéma, réponse mal formée) avant qu'on choisisse la parade parmi six : réessai borné, autre outil, question à l'utilisateur, retour arrière, humain, arrêt sûr (leçon 102). Le livre mesure seulement que la parade choisie correspond au type d'échec (leçon 103). Le replanning (refaire un plan après l'échec) se note à part.
• Une boucle se repère à des appels répétés avec les mêmes arguments, sans progrès, ou à un budget d'étapes dépassé.
• L'achèvement n'est pas un booléen : succès complet, partiel, échec sûr, échec dangereux, résolution par un humain (leçon 105). Pousser l'achèvement peut faire grimper les violations de sécurité.