Zacharie Elbaz

Études

Réflexions autour de l’évaluation d’un LLM

Lorsqu’on change le modèle ou la configuration d’un bot, il faut pouvoir détecter une régression. Comme les classements publics ne répondent pas à cette question, je présente ici la méthode que j’utilise, les erreurs que j’ai commises ainsi que ce que la recherche dit de chaque étape.

Thème
Évaluation
Objet
Bots et assistants d’appel
Appui
8 travaux de recherche

Le besoin : détecter une régression après un changement

Je travaille sur des bots de relation client. Certains répondent directement à un client, tandis que d’autres assistent un conseiller pendant un appel en cochant les étapes d’un script au fil de la conversation.

Dès que nous changeons le modèle, la consigne ou l’architecture, nous devons savoir si le bot s’est amélioré ou s’il a régressé. Or un classement public ne répond pas à cette question, puisqu’il compare des modèles sur des tâches générales. J’ai donc besoin de vérifier qu’un bot réalise correctement une tâche précise sur les conversations d’un client donné.

Ce que je décris ici relève de ma pratique et non de l’état de l’art. C’est pourquoi j’indique, pour chaque étape, ce que la recherche en dit, avant de lister plus bas les points sur lesquels je m’en écarte.

La méthode en six étapes

  • de vraies conversations
  • le bot
  • ses réponses
  • ce qui était attendu
  • la personne qui l’a écrit
Fig. 1 Le banc d’essai. La réponse fausse apparaît en couleur, car c’est elle que nous lisons en premier.

1.Partir de vraies conversations

Je rejoue de vraies conversations plutôt que des exemples inventés. Je les regroupe ensuite en scénarios qui reprennent chacun une attente du client, dont je note l’origine.

2.Définir ce qui est attendu avant de mesurer

Avant de lancer le bot, j’écris ce que la bonne réponse doit contenir. Pour l’assistant d’appel, cela revenait à préciser quelle case devait être cochée après quelle phrase, ainsi que les cases qui ne devaient jamais l’être.

Chaque critère est d’abord essayé sur quelques cas écrits à la main dont je connais le verdict. Ce contrôle a ainsi permis d’écarter deux critères faux avant qu’ils ne produisent un chiffre.

3.Mesurer là où le bot agit et non là où il parle

L’un de mes critères devait vérifier que le bot n’inventait aucun identifiant, et affichait un score de 100 %. En réalité, le bot en forgeait un à chaque appel d’outil : mon test analysait uniquement la réponse finale adressée au client, tandis que l’erreur se glissait en amont, dans les paramètres transmis à l’outil.

  • ce que le bot répond au client
  • ce qu’il envoie à l’outil
  • là où regarde le critère
Fig. 2 Le critère regardait la réponse, qui était correcte, alors qu’il fallait le poser sur l’appel d’outil.

Une fois le critère placé au bon endroit, nous avons pu corriger le problème, ramenant le taux d’identifiants fabriqués de 38 % à 1 %.

J’ai constaté le même écart lors du suivi des procédures métier. Quatre critères affichaient 100 % de réussite, dont celui qui vérifiait le choix de la bonne fiche, alors même que sa réponse finale, longue de 147 caractères, se limitait à un simple accusé de réception. Sélectionner la bonne procédure ne garantit donc pas qu’elle soit réellement appliquée.

4.Faire relire par un second modèle et mesurer l’accord

Un second modèle relit un échantillon à l’aveugle, puis je mesure l’accord champ par champ. Je considère un champ comme fiable au-dessus de 85 %, comme indicatif entre 70 et 85 %, et je le retire en dessous.

Pour un événement rare, le pourcentage ne suffit pas, c’est pourquoi je vérifie aussi que les deux lecteurs repèrent les mêmes cas. Enfin, lorsque le juge hésite, je corrige la consigne avant de relancer et de mesurer à nouveau.

5.Répéter avant de conclure

Après l’exécution d’un quart du banc d’essai (24 %), une nouvelle architecture paraissait plus rapide de 2,4 secondes ; une fois l’évaluation menée à son terme, elle s’est pourtant révélée plus lente de 1,0 seconde.

De même, le temps de réponse d’un même bot est passé de 20,4 secondes à 13,9, puis à 18,7 au cours d’une seule journée : les variations de latence du fournisseur dépassaient en réalité l’écart entre les architectures comparées.

À 24 % du banc2,4 s plus rapide

Banc entier1,0 s plus lente

Fig. 3 Le pointillé marque un écart nul. La nouvelle architecture est plus rapide en dessous et plus lente au-dessus.

Depuis, je répète chaque mesure au moins trois fois et je compare des exécutions lancées en alternance plutôt que deux campagnes séparées dans le temps. Je calcule également un intervalle de confiance dès que l’échantillon est petit.

6.Lire les réponses à la main

Un jour, tous mes critères étaient au vert. Pourtant, en lisant les réponses, j’ai constaté qu’elles étaient rédigées pour le téléphone, avec les nombres en toutes lettres et sans mise en forme, alors que le bot était un chat. Le banc appelait en effet le moteur sans préciser le canal, ce qui ne provoquait ni erreur ni critère en échec.

Comme les critères ne voient que ce qu’on leur a appris à regarder, la lecture à la main reste mon dernier contrôle.

Les erreurs que j’ai commises

Un accord pris pour une preuve, à deux reprises

La première fois, mon test annonçait 100 % d’accord entre deux modèles parce qu’il comparait deux ensembles vides.

La deuxième fois, je mesurais 65 % d’accord entre un nouveau modèle et l’ancien, et j’en ai conclu que le nouveau était moins bon. C’était faux, puisque ce chiffre mesurait la ressemblance avec l’ancien modèle et non la justesse.

En comparant à ce qui était attendu, le nouveau modèle obtenait en réalité 94 % de rappel contre 82 % pour l’ancien.

65 % d’accord entre les deux modèles

  • 82 % de rappell’ancien modèle
  • Ce qui était attenduécrit à la main
  • 94 % de rappelle nouveau modèle
Fig. 4 En pointillé, l’accord entre les deux modèles, que je mesurais. En couleur, l’écart de chacun avec ce qui était attendu, qu’il fallait mesurer.

Un cas de test erroné

L’un de mes scénarios visait à tester un cas exclu par l’offre du client. Or, faute de vérification préalable, j’avais retenu une demande qui était bel et bien prise en charge. Dès lors, si le bot ne fournissait pas le refus attendu par mon test, c’est en réalité parce qu’il avait raison.

Un chiffre juste mais mal interprété

J’ai présenté une corrélation de +0,81 comme un appui solide alors qu’elle ne portait que sur sept points. Son intervalle de confiance à 95 % allant de +0,15 à +0,97, elle reste compatible avec un effet bien plus faible.

Le calcul n’était donc pas faux, c’est l’interprétation que j’en faisais qui l’était.

Les écarts entre ma méthode et la recherche

Ma pratique vient du terrain, et la recherche va plus loin sur quatre points.

  • Je mesure un pourcentage d’accord. Or il peut être élevé alors que les notes diffèrent beaucoup [3], ce qui rend une deuxième mesure nécessaire.
  • Ce qui est attendu est écrit par une seule personne. Les travaux cités font noter un échantillon par des humains afin de vérifier l’évaluateur [1], alors que je ne dispose pas d’un second lecteur humain.
  • Je répète chaque mesure trois fois. Il s’agit d’un minimum, puisque la recherche recommande de prévoir avant le lancement la taille d’échantillon nécessaire pour observer l’écart recherché [4], [8].
  • Je mesure la régularité sur trois essais. τ-bench la mesure sur huit essais d’un même cas et montre que les agents testés sont irréguliers [5].

La complémentarité entre l’IA et l’humain

Dans ce banc, l’IA prend en charge le volume tandis que l’humain décide de ce qui est considéré comme juste.

Ce que fait l’IA

  • Rejouer chaque conversation du banc, autant de fois qu’il faut.
  • Relire un échantillon à l’aveugle, comme second lecteur.
  • Signaler les cas où elle hésite, pour corriger la consigne.

Ce que garde l’humain

  • Écrire ce qui est attendu, et vérifier que le cas de test est juste.
  • Lire les réponses, pour voir ce qu’aucun critère ne regarde.
  • Décider si l’écart mesuré suffit pour changer le bot.

La suite

Je souhaite ajouter une mesure d’accord qui tienne compte du hasard. Je prévois aussi de faire écrire ce qui est attendu par deux personnes afin de mesurer leur accord, puis de calculer la taille du banc avant de le lancer.

Références

  1. [1]Shankar, Zamfirescu-Pereira, Hartmann, Parameswaran et Arawjo (2024). Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences. arXiv:2404.12272.
  2. [2]Zheng, Chiang, Sheng et leurs coauteurs (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023, Datasets and Benchmarks.
  3. [3]Thakur, Choudhary, Ramayapally, Vaidyanathan et Hupkes (2024). Judging the Judges: Evaluating Alignment and Vulnerabilities in LLMs-as-Judges. arXiv:2406.12624, puis atelier GEM² 2025.
  4. [4]Miller (2024). Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations. arXiv:2411.00640.
  5. [5]Yao, Shinn, Razavi et Narasimhan (2024). τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. arXiv:2406.12045.
  6. [6]Northcutt, Athalye et Mueller (2021). Pervasive Label Errors in Test Sets Destabilize Machine Learning Benchmarks. NeurIPS 2021, Datasets and Benchmarks.
  7. [7]Ribeiro, Wu, Guestrin et Singh (2020). Beyond Accuracy: Behavioral Testing of NLP Models with CheckList. ACL 2020.
  8. [8]Card, Henderson, Khandelwal, Jia, Mahowald et Jurafsky (2020). With Little Power Comes Great Responsibility. EMNLP 2020.