Calibrer un juge modèle par rapport à des notes humaines

Étude de cas 1
120 min
Facultative · 1 étude de cas requise pour le certificat

Étude de cas 1 sur 3 · Évaluer et tester les systèmes d'IACalibrer un juge modèle par rapport à des notes humaines

Aperçu du cours

1. Définir ce qui est « bon »

2. Créer un jeu de données d'évaluation

3. Choisir les métriques par composant

4. Utiliser des juges humains et des juges modèles

5. Comparer les systèmes de façon responsable

6. Automatiser l'évaluation et la rétroaction

7. Études de cas

Ce que vous saurez faire

Découvrez si un juge modèle peut remplacer des personnes pour une tâche : choisir la meilleure de deux réponses de robots conversationnels. Vous mesurez la fréquence des accords entre personnes et celle des accords de deux juges modèles avec elles. Vous repérez aussi les situations où les juges échouent. Ensuite, vous rédigez une politique de jugement et la testez une seule fois.

Étude de casPièce de portfolio

Jeu de données: MT-Bench human judgments (LMSYS)
Licence: CC BY 4.0 (votes); Apache-2.0 (requêtes, références)
Durée: Environ 2 h
S’exécute dans: Colab, Kaggle ou VS Code
Compétences utilisées: L'accord humain comme plafond
Étiquettes majoritaires
Juges par paires dans les deux ordres
Kappa de Cohen avec intervalles
Biais d'ordre et de longueur
Sous-groupes par catégorie
Une politique de jugement écrite
Un seul test sur les données réservées

Ouvrir dans Colab Ouvrir dans Kaggle Voir sur GitHub

Les carnets sont en anglais. Colab et Kaggle ouvrent votre propre copie. Pour utiliser VS Code, téléchargez le carnet depuis GitHub. Vous êtes bloqué ? Consultez le carnet de solution.

Le carnet (notebook) Jupyter exécute chaque étape de cette page, avec le même code et les mêmes sorties. Il ajoute quatre tâches avec des vérifications. Il télécharge deux fichiers (environ 2 Mo) et nécessite seulement Python et numpy. Il fonctionne donc dans Colab ou Kaggle sans configuration. Son exécution prend quelques secondes. Vous n’avez besoin ni de compte ni de clé : chaque jugement de modèle a été enregistré une fois. Le carnet le reproduit.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 120 minutes

Ce que vous devez savoir

Cette étude de cas va plus loin que le module 4. Ces leçons sont les plus importantes :

Le pourcentage d’accord et le kappa de Cohen, dans Calibrer les évaluateurs.
Les juges par paires, les deux ordres et le biais d’ordre, dans Le jugement par modèle.
Les intervalles par bootstrap, les différences appariées et les sous-groupes, dans Incertitude et sous-groupes.
Les données de développement et les données réservées, dans Éviter la contamination.

Ce qu’il vous faut sur votre ordinateur (seulement pour l’exécution locale; Colab et Kaggle n’en ont pas besoin)

Python 3.12 ou une version ultérieure avec numpy, et le carnet téléchargé de GitHub, dans VS Code ou JupyterLab. Le projet du cours n’est pas nécessaire.
La première cellule du carnet télécharge les données dans un nouveau dossier judge-calibration. Pour recommencer, supprimez ce dossier.

Testé sur macOS avec Python 3.12 et numpy 2.5.3, dans Jupyter après un nouveau démarrage. Windows, Linux, Colab et Kaggle n’ont pas été testés.

La situation

Ines dirige l’évaluation dans une petite entreprise qui crée un assistant conversationnel généraliste. Chaque semaine, l’équipe compare deux versions de l’assistant sur un ensemble fixe de questions. Les questions couvrent la rédaction, le jeu de rôle, le raisonnement, les mathématiques, la programmation, l’extraction, les sciences et les humanités. Pour chaque question, un évaluateur lit les deux réponses et choisit la meilleure, ou une égalité. Deux évaluateurs y consacrent presque une journée chaque semaine.

Daniel, un ingénieur de l’équipe, a une proposition. « Laissons un modèle choisir. L’article sur MT-Bench dit que GPT-4 est d’accord avec les gens plus de 80 % du temps. C’est aussi souvent que les gens sont d’accord entre eux. Nos modèles Azure sont plus récents que GPT-4. On peut arrêter les révisions. »

Ines ne dit pas non. Elle demande d’abord des preuves. « Montre-moi où le juge est d’accord avec les gens, sur des questions comme les nôtres. Puis montre-moi où il ne l’est pas. Je veux une règle écrite : ce que le juge décide seul, et ce qu’une personne doit encore lire. »

Un mauvais verdict peut mener à la mise en production de la moins bonne version. Tout lire coûte une journée par semaine à chacun des deux évaluateurs. Ines veut utiliser le juge là où il fait aussi bien qu’une personne. Ailleurs, elle veut garder les personnes.

Ce que vous allez créer

Vous allez créer une étude de calibration de deux juges modèles, puis une politique de jugement à partir de cette étude. L’étude mesure quatre choses à partir de vrais votes humains. À quelle fréquence les gens sont-ils d’accord entre eux? À quelle fréquence chaque juge est-il d’accord avec eux? Le verdict dépend-il de l’ordre ou de la longueur des réponses? Où le juge échoue-t-il, par catégorie? La politique transforme ces chiffres en règles. À la fin, vous testez la politique une seule fois, sur des questions qu’elle n’a jamais vues.

Les compétences viennent de l’ensemble du cours. Les données de développement et les données réservées viennent de Éviter la contamination. L’accord et le kappa viennent de Calibrer les évaluateurs. Les juges dans les deux ordres viennent de Le jugement par modèle. Les intervalles et les sous-groupes viennent de Incertitude et sous-groupes.

Les données

En 2023, les auteurs de l’article sur MT-Bench ont posé les mêmes 80 questions à six robots conversationnels de l’époque. Ces robots étaient GPT-4, GPT-3.5, Claude v1, Vicuna-13B, Alpaca-13B et LLaMA-13B. Ils ont ensuite demandé à des personnes de comparer les réponses par paires. Le résultat est le jeu de données MT-Bench human judgments : environ 3 300 votes. Chaque vote indique laquelle de deux réponses est meilleure, ou une égalité.

Qui sont ces personnes? L’article indique : « 58 annotateurs humains de niveau expert… principalement des étudiants aux cycles supérieurs », de plus de dix universités. Ils ont reçu 20 $ US pour juger 20 questions. Certains auteurs de l’article ont aussi voté. Dans les données, chaque personne a un pseudonyme, comme expert_17 ou author_4. Ce sont de vraies évaluations humaines, faites par ces personnes. Les verdicts des modèles dans cette étude de cas sont des sorties de modèles. La page distingue les deux.

Le cours a aussi considéré HelpSteer3 (CC BY 4.0). Il publie « seulement les trois annotations qui s’accordent le plus entre elles ». Les personnes semblent donc plus cohérentes qu’elles ne le sont. MT-Bench conserve chaque vote et chaque pseudonyme.

Un élément

Un élément comprend une question, les premières réponses de deux robots conversationnels et les votes des personnes qui les ont comparées. Un vote vaut A (la réponse de model_1 est meilleure), B (la réponse de model_2 est meilleure) ou tie (égalité). model_1 est toujours le modèle dont le nom vient en premier par ordre alphabétique. Une étiquette signifie donc la même chose sur chaque ligne.

Champ	Signification
`item_id`, `question_id`, `category`	L’élément; la question MT-Bench (81 à 160); une des 8 catégories de 10 questions
`split`	`dev` (développement) ou `holdout` (données réservées), voir ci-dessous
`question`, `answer_1`, `answer_2`	La question et les deux réponses de 2023, provenant de `model_1` et `model_2`
`reference`	Pour le raisonnement, les mathématiques et la programmation : une réponse de référence, écrite par GPT-4 pour MT-Bench
`human_ratings`	Les votes : le pseudonyme de la personne et `A`, `B` ou `tie`
`gpt4_2023`	Le juge GPT-4 de l’article, interrogé dans les deux ordres en 2023 (`inconsistent` = l’ordre a changé son verdict)

Premières vérifications

Le carnet charge l’échantillon et compte :

items = [json.loads(line) for line in open("data/mtb_judge_sample.jsonl", encoding="utf-8")]
dev = [it for it in items if it["split"] == "dev"]
holdout = [it for it in items if it["split"] == "holdout"]
votes = [r for it in items for r in it["human_ratings"]]
print(len(items), "items |", len(dev), "dev |", len(holdout), "holdout")
print(len(votes), "human votes from", len({r["rater_id"] for r in votes}), "people")
print("votes per item:", dict(sorted(Counter(len(it["human_ratings"]) for it in items).items())))

La sortie :

320 items | 155 dev | 165 holdout
834 human votes from 65 people
votes per item: {2: 187, 3: 89, 4: 31, 5: 10, 6: 2, 7: 1}

Ce que cela nous indique. L’échantillon contient 320 éléments avec 834 votes de 65 personnes. La plupart des éléments n’ont que deux votes. Les « gens » pour un élément sont donc souvent seulement deux personnes. L’échantillon prend 40 des 484 éléments admissibles de chaque catégorie. C’est cinq fois l’échantillon de Calibrer les évaluateurs.

Définir le problème

Avant d’exécuter un juge, Ines et Daniel s’entendent sur quatre points.

L’unité : un élément, soit une question avec deux réponses.
La tâche du juge : choisir la meilleure réponse, ou une égalité. C’est la même tâche que celle des évaluateurs.
La séparation, par question. Chaque question MT-Bench apparaît dans plusieurs éléments, avec différentes paires de modèles. Si une question figurait des deux côtés, la politique pourrait l’apprendre en développement et la retrouver dans les données réservées. Dans chaque catégorie, 5 questions vont donc au développement : 155 éléments pour calibrer les juges et rédiger la politique. Les 5 autres vont aux données réservées : 165 éléments pour tester la politique une seule fois, à la fin.
Ce qui compte comme « correct ». « Quelle réponse est meilleure? » n’a pas de corrigé. Il n’y a que les votes des personnes. On compare donc le juge aux personnes, et l’accord entre personnes sert de plafond.

Ce dernier point est la nouvelle idée de cette étude de cas.

L’idée : les personnes fixent le plafond

Imaginez deux arbitres qui regardent le même match. Ils ne s’entendent pas sur certaines décisions, parce qu’elles sont difficiles. Un troisième arbitre s’accorde avec chacun aussi souvent qu’ils s’accordent entre eux. Il fait alors aussi bien qu’un arbitre. Vous ne pouvez pas demander davantage, car il n’existe pas de vraie décision à laquelle le comparer.

C’est pareil pour un juge. Comparez son accord avec une personne à l’accord d’une personne avec une autre personne : le même type de paire. C’est le plafond. L’accord avec la majorité des personnes sur un élément offre un deuxième point de vue utile. « Le juge donnerait-il la réponse habituelle de l’équipe? » Mais il est plus facile de s’accorder avec une majorité qu’avec une personne. Ne comparez donc jamais ces deux chiffres entre eux. Cette étude de cas fait cette erreur une fois, puis la repère.

The plan of the study. 320 MT-Bench items, with 834 votes from human judges, 2 to 7 per item, are split by question. Dev: 155 items, 40 questions, to calibrate the judges and write the policy. Holdout: 165 items, 40 other questions, to test the policy once at the end. On dev, five steps: 1 the ceiling, how often two people agree; 2 the judges, chat-small and chat-strong, each in both orders; 3 compare with the majority and with each person, with kappa; 4 where it fails: order, length, category, with or without a reference; 5 the policy: what the judge decides alone and what goes to a person. Step 6: on holdout, apply the policy once and measure how much the judge decides, and how well. — Le plan de l'étude. Tout est choisi sur les données de développement; les données réservées servent une seule fois, à la fin.

Le plafond : à quelle fréquence les personnes s’accordent-elles?

Le carnet prend chaque paire de personnes qui ont voté sur le même élément de développement. Il mesure leur accord et leur kappa. L’intervalle est calculé par bootstrap sur les éléments, avec 2 000 rééchantillons. Les votes sur un même élément ne sont pas indépendants.

per_item = [human_pairs(it) for it in dev]
print("pairs of people:", sum(len(p) for p in per_item))
print("agreement:", interval(per_item, 0))
print("kappa:    ", interval(per_item, 1))
print("agreement without ties:", interval([[p for p in ps if "tie" not in p] for ps in per_item], 0))

La sortie :

pairs of people: 376
agreement: (0.638, 0.563, 0.711)
kappa:     (0.451, 0.337, 0.554)
agreement without ties: (0.834, 0.759, 0.898)

Ce que cela nous indique. Deux personnes s’accordent sur 64% des votes, avec un kappa de 0.45. La plupart des désaccords opposent une « égalité » à un gagnant. Sans les égalités, elles s’accordent sur 83%. C’est le « plus de 80 % » de l’article, qui exclut aussi les égalités. Daniel a cité un chiffre sans sa condition. Avec les égalités, le plafond est d’environ deux votes sur trois. L’intervalle va de 56% à 71% : 155 éléments ne permettent pas de le déterminer avec précision.

Les personnes sont aussi divisées à parts égales sur 33 des 155 éléments de développement. Par exemple, une vote A et l’autre B. Ces éléments n’ont aucune majorité. Ils sont exclus de toutes les comparaisons avec la majorité. Ils ne sont pas difficiles seulement pour un juge; ils sont difficiles.

Références de base

Deux références de base encadrent les juges.

Choisir la réponse la plus longue. Aucun modèle et aucune lecture : choisir la réponse qui contient le plus de caractères. Un juge qui ne fait pas mieux n’apporte rien.
GPT-4 en 2023. Le jeu de données comprend les verdicts du juge de l’article, interrogé dans les deux ordres. C’est le résultat publié que Daniel a cité.

Les juges, interrogés deux fois

Le cours a interrogé deux juges modèles sur Azure : chat-small (gpt-6-luna) et chat-strong (gpt-6.1-sol). Les deux ont reçu la requête de comparaison par paires de l’article sur MT-Bench, mot pour mot. Le seul changement par rapport à l’article est donc le modèle. La requête dit notamment : « Veuillez agir comme un juge impartial… Évitez tout biais de position… Ne laissez pas la longueur des réponses influencer votre évaluation. »

Chaque élément a été soumis deux fois, comme dans Le jugement par modèle. La première fois, la réponse 1 était « Assistant A »; la deuxième fois, c’était la réponse 2. Pour le raisonnement, les mathématiques et la programmation, le cours a aussi utilisé la deuxième requête de l’article. Celle-ci ajoute la réponse de référence. Cela donne 1 760 appels enregistrés, dont 480 avec la référence, pour environ 2,70 $ US au total. Les modèles changent vite, et une nouvelle version voterait différemment sur certains éléments. Ces verdicts sont un instantané du 9 octobre 2026; la méthode reste valable.

Voici un véritable élément de développement, examiné à la main.

Question de programmation 129 : trouver le k-ième plus petit élément de l'union de deux listes triées, avec une complexité linéaire. Réponse 1, claude-v1, 1 007 caractères : du code avec des bogues et une explication. Réponse 2, llama-13b, 92 caractères : une phrase, sans code. Les personnes : author_2 et expert_12 disent toutes deux que la réponse 1 est meilleure. La majorité humaine choisit donc la réponse 1. Le juge chat-strong, interrogé deux fois. Avec la réponse 1 présentée comme A, il a choisi B, la réponse 2 : « B est préférable à une implémentation trompeuse et défectueuse. » Avec la réponse 2 présentée comme A, il a choisi B, maintenant la réponse 1 : « B est la réponse la plus utile, malgré les corrections nécessaires. » La réponse présentée en deuxième a gagné les deux fois. Le verdict est incohérent : il compte comme une égalité, et la politique l'envoie à une personne. — Un élément de développement et les verdicts enregistrés de chat-strong dans les deux ordres. Le juge a trouvé les mêmes bogues les deux fois, mais a choisi la réponse lue en deuxième.

Les deux justifications mentionnent les mêmes bogues. La lecture du juge n’a pas changé; sa pondération a changé, et la position a décidé. Interrogé une seule fois, il donnerait un verdict assuré.

Le carnet convertit chaque lettre enregistrée selon l’ordre fixe, puis combine les deux ordres. Le même verdict deux fois devient le verdict final. Deux verdicts différents sont incohérents et comptent comme une égalité, comme dans l’article.

for judge in ["chat-small", "chat-strong", "gpt-4 (2023)"]:
    print(f"{judge:13}", dict(Counter(verdicts[(judge, "pair-v2")].get(it["item_id"], "missing") for it in dev)))

La sortie :

chat-small    {'B': 67, 'A': 65, 'inconsistent': 12, 'tie': 11}
chat-strong   {'B': 68, 'A': 62, 'inconsistent': 8, 'tie': 17}
gpt-4 (2023)  {'B': 59, 'A': 49, 'inconsistent': 27, 'tie': 20}

Biais d'ordre : proportion des 155 éléments de développement où inverser les deux réponses a changé le verdict du juge. Les juges actuels sont beaucoup plus stables que GPT-4 en 2023, mais ce biais demeure.

Description textuelle du graphique

Un graphique à colonnes. chat-small: 12 of 155 items, 7.7%. chat-strong: 8 of 155 items, 5.2%. gpt-4 (2023): 27 of 155 items, 17.4%.

Ce que cela nous indique. L’ordre a changé le verdict de chat-strong sur 8 des 155 éléments de développement. Il a changé celui de chat-small sur 12. GPT-4 en 2023 a changé sur 27. Le biais d’ordre est donc beaucoup plus faible que dans l’article, mais il n’a pas disparu. Quand le verdict de chat-strong a changé, la réponse présentée en deuxième a gagné les deux fois sur 5 éléments. Celle présentée en premier a gagné sur 1.

Une comparaison équitable

Voici le tableau principal : chaque juge sur les mêmes éléments de développement, avec les mêmes deux mesures et des intervalles. « Avec la majorité » utilise les 122 éléments de développement qui en ont une. « Avec chaque personne » compare chaque vote humain au verdict du juge sur le même élément. C’est le même type de paire que pour le plafond.

for judge in ["longer answer", "chat-small", "chat-strong", "gpt-4 (2023)"]:
    v = verdicts[(judge, "pair-v2")]
    print(f"{judge:15}{str(interval(vs_majority(v, dev), 0)):32}{str(interval(vs_majority(v, dev), 1)):24}"
          f"{str(interval(vs_people(v, dev), 0)):30}{interval(vs_people(v, dev), 1)}")

La sortie (le carnet affiche d’abord le titre et le plafond) :

               with the majority: agreement    kappa                   with each person: agreement   kappa
person (ceiling)                                                        (0.638, 0.563, 0.711)         (0.451, 0.337, 0.554)
longer answer  (0.582, 0.5, 0.672)             (0.313, 0.196, 0.434)   (0.537, 0.473, 0.605)         (0.252, 0.165, 0.343)
chat-small     (0.73, 0.642, 0.803)            (0.573, 0.438, 0.684)   (0.639, 0.572, 0.699)         (0.439, 0.338, 0.525)
chat-strong    (0.738, 0.653, 0.811)           (0.588, 0.454, 0.701)   (0.646, 0.579, 0.704)         (0.449, 0.349, 0.537)
gpt-4 (2023)   (0.754, 0.675, 0.828)           (0.626, 0.507, 0.734)   (0.651, 0.59, 0.708)          (0.472, 0.382, 0.555)

Accord avec le vote d'une personne sur les éléments de développement, avec des intervalles par bootstrap à 95 % sur les éléments. La ligne grise est le plafond : une personne contre une autre. La ligne orange est la référence de base qui choisit la réponse la plus longue.

Description textuelle du graphique

Une ligne pour chacun, avec son intervalle. person vs person: 63.8% (56.3 to 71.1). longer answer: 53.7% (47.3 to 60.5). chat-small: 63.9% (57.2 to 69.9). chat-strong: 64.6% (57.9 to 70.4). gpt-4 (2023): 65.1% (59 to 70.8).

Ce que cela nous indique. Comparez ce qui est comparable. Face à une personne, les deux juges Azure s’accordent aussi souvent qu’une autre personne : 65% et 64%, pour un plafond de 64%. GPT-4 de 2023 est au même niveau. Le résultat principal de l’article tient donc aussi avec les modèles actuels. La règle de la réponse la plus longue est nettement plus basse, à 54%. Les juges lisent donc plus que la longueur. Face à la majorité, chaque chiffre est plus élevé, autour de 74%. C’est ce qui rend la comparaison de la colonne majoritaire au plafond tentante, mais incorrecte.

Une autre surprise. chat-small s’accorde avec les personnes aussi souvent que chat-strong. La différence appariée avec la majorité est de +0.008, avec un intervalle de -0.033 à 0.057. Sur les billets de soutien de Larkfield, dans Le jugement par modèle, chat-small était le juge peu fiable. La qualité d’un juge dépend d’une tâche, pas d’un modèle.

Là où le juge échoue

Longueur

La requête dit : « Ne laissez pas la longueur des réponses influencer votre évaluation. » Le carnet le vérifie. Pour chaque verdict décisif (A ou B), la réponse choisie est-elle la plus longue? Il fait la même vérification pour la majorité humaine, comme référence de base. Les gens peuvent aussi préférer les réponses longues, qui sont souvent plus complètes.

people (majority)  picks the longer answer in 75% of 95 decisive verdicts
chat-small         picks the longer answer in 63% of 132 decisive verdicts
chat-strong        picks the longer answer in 64% of 130 decisive verdicts
gpt-4 (2023)       picks the longer answer in 76% of 108 decisive verdicts

Ce que cela nous apprend. Les réponses longues gagnent généralement, auprès des gens aussi. Les juges actuels choisissent la réponse la plus longue moins souvent que les gens. Rien n’indique donc un biais de longueur supérieur à celui des gens. Et lorsque chat-strong contredit une majorité claire, il a choisi la réponse la plus longue seulement 4 fois sur 14. Pour les billets de Larkfield, dans Le jugement par modèle, le juge préférait les réponses longues : vérifiez-le pour chaque tâche.

Catégorie

Un chiffre global mélange les catégories. Séparez-les donc, comme dans Incertitude et sous-groupes, avec les effectifs et les intervalles à côté de chaque chiffre. Chaque catégorie ne compte que 14 à 24 éléments de développement.

Par catégorie, sur les données de développement : une personne contre une autre (gris) et chat-strong contre une personne (bleu; orange lorsque la politique confie la catégorie à une personne), avec des intervalles bootstrap à 95 %. Chaque catégorie compte 14 à 24 éléments, donc les intervalles sont larges.

Description textuelle du graphique

Pour chaque catégorie, deux lignes. writing (14 items): person vs person 58.3% (30.4 to 82.9), chat-strong vs person 54.1% (33.3 to 75). roleplay (22 items): person vs person 61.5% (44.2 to 79.1), chat-strong vs person 56.5% (38.2 to 75). reasoning (19 items): person vs person 60.9% (42.6 to 82), chat-strong vs person 72% (55.6 to 87.8). math (18 items): person vs person 56.2% (38.1 to 73.9), chat-strong vs person 62% (45.8 to 76.6). coding (22 items): person vs person 81.6% (67.7 to 97), chat-strong vs person 66% (46.8 to 85.4). extraction (24 items): person vs person 72.4% (52 to 93.2), chat-strong vs person 75.8% (60.6 to 89.8). stem (16 items): person vs person 61.8% (37.2 to 85), chat-strong vs person 67.5% (50 to 83.7). humanities (20 items): person vs person 58.8% (39.4 to 81.6), chat-strong vs person 60.4% (43.9 to 77.4).

Ce que cela nous apprend. La programmation se démarque. Les gens s’y accordent davantage que partout ailleurs, à 81.6 %. Le code est correct ou incorrect, et les gens l’ont vu. Le juge n’atteint que 66 %. La question 129 ci-dessus est un de ces éléments. En rédaction et en jeu de rôle, le juge se situe quelques points sous les gens. C’est aussi là que les gens s’accordent le moins. En raisonnement, en mathématiques, en sciences et en extraction, le juge égale ou dépasse les gens. Tous les intervalles sont larges : traitez ces résultats comme des indices, pas des preuves.

Avec et sans réponse de référence

En raisonnement, en mathématiques et en programmation, un juge qui lit deux réponses peut faire la même erreur qu’elles. La solution de l’article est d’inclure une réponse de référence dans la requête. Le carnet compare le même juge sur les mêmes éléments de développement, avec et sans cette référence. Il utilise un bootstrap apparié de la différence.

chat-small   49 items | without 0.735 | with the reference 0.735 | difference +0.000 [-0.082, +0.082]
chat-strong  50 items | without 0.780 | with the reference 0.760 | difference -0.020 [-0.060, +0.000]

Ce que cela nous apprend. La référence n’aide pas ces juges : la différence est nulle ou légèrement négative, et les deux intervalles incluent 0. Les juges actuels voient les erreurs des réponses de 2023 sans aide. De plus, une personne doit rédiger et vérifier la référence. Ici, cela n’en vaut pas la peine.

Refus et verdicts illisibles

Dans Le jugement par modèle (suite), le filtre de contenu d’Azure refusait chaque jugement du billet d’injection de Larkfield. Ici, le filtre n’a refusé aucun appel : ces questions ne contiennent aucune instruction visant le juge. Sur les données de développement, un jugement de chat-small avec référence expliquait son choix sans jamais écrire le format [[A]]. Un autre a fait la même chose sur les données réservées. La politique traite un verdict manquant comme un refus : une personne décide. Comptez ces résultats séparément à chaque exécution.

Erreur courante

Ne demander qu'une fois

Symptôme : une équipe interroge son juge une fois par paire, avec les réponses dans un ordre fixe. Le juge semble sûr de lui, et son accord avec les gens semble bon.

Cause : un seul ordre masque tous les éléments où la position, plutôt que le contenu, a déterminé le choix. Interrogé une seule fois, chat-strong ne donne aucun verdict incohérent. Son accord avec la majorité est de 73%, contre 74% avec les deux ordres. La moyenne change à peine. Ce qui change, c’est ce que vous savez : les 8 éléments où la position a déterminé le choix semblent aussi certains que les autres.

Solution : interrogez toujours le juge dans les deux ordres. Comptez les éléments dont le verdict a changé, traitez-les comme des égalités et confiez-les à une personne. Le deuxième appel double le coût du juge, qui reste faible comparé au temps d’une personne.

La politique du juge

La politique transforme les chiffres de développement en règles. Sa première version a été écrite avant l’analyse des jugements; le journal d’exécution indique l’heure. Sa règle 3 comparait l’accord du juge avec la majorité à l’accord entre deux personnes individuelles. C’est l’erreur signalée dans la section sur le plafond. Avec cette règle, le juge déciderait seul dans chaque catégorie, y compris la programmation. Les chiffres de développement ont révélé le défaut. La règle a été corrigée sur les données de développement, avant tout calcul sur les données réservées. La version 2 compare des éléments comparables :

Le juge est le juge Azure qui s’accorde le plus souvent avec la majorité humaine sur les données de développement : chat-strong. L’avance sur chat-small reste dans la marge du bruit. Une équipe soucieuse du coût pourrait donc choisir chat-small et le calibrer de la même façon.
La requête : en raisonnement, en mathématiques et en programmation, utilisez la requête avec référence si elle s’accorde au moins aussi souvent avec la majorité sur les données de développement. C’est le cas pour math and reasoning, où l’accord était égal.
Une catégorie est confiée à une personne lorsque l’accord du juge avec une personne est inférieur de plus de 0,05 à l’accord entre deux personnes, dans cette catégorie. Sur les données de développement, il s’agit de coding.
Tout élément dont le verdict change avec l’ordre est confié à une personne. Il en va de même pour chaque jugement refusé ou illisible.
Une personne lit un échantillon aléatoire des décisions du juge chaque semaine. Le carnet ne peut pas tester cette règle, mais elle permettra à l’équipe de remarquer un changement.

Le carnet calcule les règles 1 à 3 à partir des données de développement :

writing     pair-v2       judge vs person 0.541 | person vs person 0.583 -> judge alone
roleplay    pair-v2       judge vs person 0.565 | person vs person 0.615 -> judge alone
reasoning   pair-math-v1  judge vs person 0.740 | person vs person 0.609 -> judge alone
math        pair-math-v1  judge vs person 0.640 | person vs person 0.562 -> judge alone
coding      pair-v2       judge vs person 0.660 | person vs person 0.816 -> a person
extraction  pair-v2       judge vs person 0.758 | person vs person 0.724 -> judge alone
stem        pair-v2       judge vs person 0.675 | person vs person 0.618 -> judge alone
humanities  pair-v2       judge vs person 0.604 | person vs person 0.588 -> judge alone

Ce que cela nous apprend. Seule la programmation est confiée à une personne en raison de sa catégorie. La rédaction et le jeu de rôle passent, mais de justesse : le jeu de rôle est exactement 0,05 plus bas. Avec une marge de 0, ces catégories seraient aussi confiées à une personne. La dernière tâche du carnet vous demande de faire ce changement et d’en mesurer le coût.

Le test, une seule fois

Les éléments réservés sont 40 autres questions. Aucun choix de la politique ne repose sur ces questions. Le carnet applique la politique une seule fois et mesure deux choses : le travail repris par le juge et sa performance.

decisions = {it["item_id"]: route(it, policy) for it in holdout}
print("decisions:", dict(Counter(d for d, _ in decisions.values())))
alone = [it for it in holdout if decisions[it["item_id"]][0] == "judge"]
decided = {i: v for i, (d, v) in decisions.items()}
print(f"the judge decides alone on {len(alone)} of {len(holdout)} items ({len(alone) / len(holdout):.0%})")
print("there, agreement with the majority:", interval(vs_majority(decided, alone)), "| kappa", interval(vs_majority(decided, alone), 1))
print("there, person vs person:           ", interval([human_pairs(it) for it in alone]))
print("judge on every holdout item, no policy:", interval(vs_majority(verdicts[(policy["judge"], "pair-v2")], holdout)))

La sortie :

decisions: {'judge': 139, 'person: the order changed the verdict': 9, 'person: category': 17}
the judge decides alone on 139 of 165 items (84%)
there, agreement with the majority: (0.766, 0.688, 0.845) | kappa (0.62, 0.499, 0.741)
there, person vs person:            (0.657, 0.568, 0.745)
judge on every holdout item, no policy: (0.758, 0.68, 0.832)

Ce que cela nous apprend. Sur de nouvelles questions, le juge reprend 84% du travail. Les gens lisent encore 26 éléments : 17 éléments de programmation et 9 éléments dont le verdict a changé avec l’ordre. Là où le juge décide, son accord avec une personne est de 67% (61 to 74). L’accord entre personnes est de 66% (57 to 75) sur ces mêmes éléments. La politique a tenu : le juge vaut une deuxième personne là où il décide seul.

Les données réservées donnent un avertissement. Par catégorie, l’extraction n’a pas reproduit son résultat de développement. L’accord du juge avec une personne y est de 43%, et l’accord entre personnes, de 54%. Avec environ 20 éléments par catégorie, le classement d’une catégorie peut changer d’un échantillon à l’autre. La programmation est restée sous les gens (53% contre 58%). C’est pourquoi la règle 5, l’échantillon hebdomadaire, fait partie de la politique.

Une nouvelle comparaison, du début à la fin

La semaine prochaine, une nouvelle paire de réponses arrive. La politique décide qui la juge. Ici, un élément réservé joue le rôle de cette nouvelle comparaison :

new = next(it for it in holdout if it["item_id"] == "mtb-q116-gpt-4-vs-llama-13b")
decision, verdict = route(new, policy)

La sortie :

math | x+y = 4z, x*y = 4z^2, express x-y in z
judge in order 12: A | in order 21: A
decision: judge | verdict: A | the people said: ['A', 'A', 'A', 'A']

Ce que cela nous apprend. Le juge a donné le même verdict dans les deux ordres : la réponse 1, de GPT-4, est meilleure. Les mathématiques sont une catégorie où le juge peut décider. La décision est donc judge (juge), sans intervention humaine. Les quatre personnes qui ont voté sont d’accord. Une comparaison de programmation, ou tout verdict qui change avec l’ordre, irait plutôt dans la file des évaluateurs.

Recommandations

Ines écrit à l’équipe dans ses mots, pas dans ceux des modèles :

Laissez le juge décider la plupart des comparaisons hebdomadaires. Sur de nouvelles questions, il a décidé seul pour 84% d’entre elles. Son accord avec chaque évaluateur y égalait l’accord entre évaluateurs.
Gardez des personnes pour la programmation. Pour le code, les évaluateurs s’accordent davantage que partout ailleurs, et le juge n’atteint pas leur niveau.
Interrogez le juge deux fois, dans les deux ordres, chaque fois. Confiez à une personne tout verdict qui change avec l’ordre. Cela représentait environ une comparaison sur vingt.
Lisez un échantillon chaque semaine. Une personne lit environ 10 décisions du juge par semaine, choisies au hasard. Une catégorie a déjà changé entre les données de développement et les données réservées.
Coût. Un jugement de chat-strong coûtait environ 0,003 $ US. Une semaine de 160 comparaisons dans les deux ordres coûte donc environ 1 $ US. chat-small s’accordait aussi bien avec les gens, pour moins du dixième du coût; il mérite son propre calibrage.

Et voici à quoi ne pas l’utiliser :

Pas pour décider seul d’une mise en production. La préférence d’un juge entre deux réponses est un élément parmi d’autres. Les règles de mise en production décident des cas bloquants et critiques, comme dans Compromis et régressions.
Pas pour d’autres types de questions sans nouveau calibrage : autres langues, autres sujets, conversations plus longues ou utilisateurs de l’équipe.
Pas pour noter des personnes. Il compare deux réponses de machines. Ce n’est pas un outil pour noter des étudiants, du personnel ou des candidats.

Limites

Réponses de 2023. Les six agents conversationnels sont anciens, et leurs erreurs sont faciles à voir. Les paires de réponses solides et récentes sont plus difficiles à départager, pour les gens comme pour les juges.
Un seul groupe d’évaluateurs. Les votants étaient surtout des étudiants aux cycles supérieurs, payés par question. Ce ne sont pas les utilisateurs de l’équipe. Leurs préférences ne représentent qu’un point de vue.
Les votes ne sont peut-être pas entièrement indépendants de GPT-4. Lorsqu’un vote différait de GPT-4, l’outil de collecte affichait le jugement de GPT-4 et demandait s’il était raisonnable. Selon l’article, les gens ont changé leur choix dans 34 % de ces cas. Les données n’indiquent pas quels votes ont changé.
Petites catégories. Environ 20 éléments par catégorie sur les données de développement, et autant sur les données réservées. Les décisions par catégorie sont approximatives, comme l’extraction l’a montré.
Un seul instantané. Deux modèles Azure le 9 octobre 2026, une seule requête, aucun réglage de température. Une nouvelle version du modèle exige un nouveau calibrage.
Le premier échange seulement. Le deuxième échange de MT-Bench demande au juge de lire une conversation entière. Ce n’est pas testé ici.

Utilisation responsable

Dites qui a évalué quoi. Les votes humains sont de vrais votes des juges rémunérés de l’étude MT-Bench. Ce sont surtout des étudiants aux cycles supérieurs et certains auteurs de l’article. Les verdicts des modèles sont des sorties de modèles. Ne les mettez jamais dans une même colonne appelée « notes ». N’appelez jamais le verdict d’un modèle une étiquette humaine, même lorsqu’il s’accorde avec les gens.
Une majorité l’emporte sur une minorité. Sur beaucoup d’éléments, les gens sont divisés. Un juge qui s’accorde avec la majorité reste en désaccord avec quelqu’un. Gardez les éléments divisés visibles et maintenez une intervention humaine là où les gens sont le plus en désaccord.
Revérifiez après chaque changement. Une nouvelle version du modèle, une nouvelle requête ou de nouveaux types de questions changent les chiffres. Donnez une version à la requête du juge, comme dans Le jugement par modèle (suite).

Faites-en un projet de portfolio

Une étude de calibrage montre à un employeur que vous ne faites pas confiance à un chiffre sans l’avoir mesuré. Personnalisez-la avec un changement. Par exemple, utilisez un autre modèle juge, comme un modèle local gratuit avec Ollama. Ou utilisez un autre jeu de données avec plusieurs notes humaines par élément. Vous pouvez aussi utiliser les questions de votre équipe, avec deux collègues comme évaluateurs. Puis rendez le projet public et facile à lire en cinq minutes.

Quoi mettre dans le dépôt :

README.md, la page que les gens lisent en premier (modèle ci-dessous).
Le carnet, exécuté du début à la fin, avec ses sorties.
JUDGE_POLICY.md : le juge, la requête et sa version, les règles, les chiffres derrière chaque règle et la prochaine vérification.
La source et la licence des données, avec le texte d’attribution de l’encadré ci-dessus. CC BY 4.0 permet de partager l’échantillon avec attribution; indiquez ce que vous avez changé.
Si vous enregistrez vos propres jugements : le script d’enregistrement, les requêtes exactes et un journal d’exécution avec la version du modèle, la date et le coût.

Un modèle de README :

# Can a model judge replace people for pairwise reviews?

## Question
Choose the better of two chatbot answers: when may a model judge decide alone?

## Data and licence
MT-Bench human judgments (Zheng et al., 2023), CC BY 4.0: 320 items, 834 votes by
people (mostly graduate students), 8 categories. Split by question: dev 155, holdout 165.

## Method
Ceiling = person vs person. Judges: chat-small and chat-strong (Azure), the paper's
prompt, both orders; GPT-4 (2023) and "pick the longer answer" as baselines.
Agreement and kappa with the majority and with each person; bootstrap intervals over items.

## Results (dev)
Person vs person 0.64 (kappa 0.45). chat-strong vs person 0.65, chat-small 0.64,
longer answer 0.54. Order changed the verdict on 5% (chat-strong) vs 17% (GPT-4, 2023).
No gain from a reference answer. Coding: judge 0.66 vs people 0.82.

## Policy, tested once on holdout
The judge decides alone except coding and order-dependent verdicts: 139 of 165
items (84%); there, judge vs person 0.67, person vs person 0.66.

## Limits
2023 answers; one group of raters; about 20 items per category; one snapshot.

Comment le décrire en entrevue, en deux phrases : « J’ai comparé deux juges modèles à 834 vrais votes humains. Ils s’accordent avec une personne aussi souvent que deux personnes entre elles, sauf pour le code. Ma politique du juge, testée une fois sur de nouvelles questions, a permis au juge de prendre 84 % des évaluations avec un accord de niveau humain. »

Pour aller plus loin :

Interrogez chaque juge deux fois dans le même ordre. À quelle fréquence change-t-il son verdict sans permutation?
Comparez les juges sur les éléments où les gens sont divisés à parts égales. Faites d’abord une prédiction : que devrait dire un bon juge?
Remplacez la marge de 0,05 par la borne inférieure de l’intervalle de la différence entre le juge et les gens. Combien de catégories changent?
Répétez l’étude sur le deuxième échange de MT-Bench, où le juge doit lire une conversation entière.

Vérification des connaissances

Vérifiez votre compréhension

Daniel dit : l'article montre que GPT-4 s'accorde avec les gens plus de 80 % du temps. Sur cet échantillon, deux personnes s'accordent seulement sur environ deux votes sur trois. Qui a raison, et que mesure chaque chiffre?

Afficher la réponse

Les deux chiffres sont réels et mesurent des choses différentes. Le « plus de 80 % » compte uniquement les votes où aucun côté n’a dit « égalité ». Avec les égalités, les gens s’accordent sur environ deux votes sur trois. En effet, beaucoup de désaccords opposent une « égalité » à un gagnant. Un chiffre d’accord n’est utile qu’avec ses conditions : avec ou sans égalités, contre une personne ou la majorité, et avec son intervalle. Le plafond équitable pour un juge est l’accord entre deux personnes, mesuré de la même façon que pour le juge.

Vérifiez votre compréhension

La première version de la politique comparait l'accord du juge avec la majorité à l'accord entre deux personnes. Pourquoi est-ce injuste, et en faveur de qui?

Afficher la réponse

Il est plus facile de s’accorder avec une majorité qu’avec une personne. La majorité atténue les préférences individuelles, et les éléments sans majorité sont exclus. Le chiffre du juge est donc mesuré dans des conditions plus faciles que celui des gens. La règle favorise le juge. Dans la version 1, le juge déciderait seul dans chaque catégorie, y compris la programmation. Une règle équitable compare le même type de paire : le juge contre une personne, et une personne contre une autre.

Vérifiez votre compréhension

Sur un élément de programmation, le juge a choisi la réponse lue en deuxième, dans les deux ordres. Il a donné une justification assurée chaque fois. Que fait la politique de cet élément, et pourquoi ne pas garder le premier verdict?

Afficher la réponse

Elle confie l’élément à une personne. Un verdict qui change avec l’ordre dépend de la position, pas des réponses. Aucun des deux verdicts ne dit donc quelle réponse est meilleure. Garder le premier verdict transformerait un choix aléatoire en étiquette certaine. Pour les chiffres d’accord, cet élément compte comme une égalité, comme dans l’article MT-Bench.

Récapitulatif

Deux personnes s’accordent sur environ deux votes sur trois (kappa de 0,45) : c’est le plafond. Le « plus de 80 % » de l’article exclut les égalités.
Comparez des éléments comparables : le juge contre une personne, et une personne contre une autre. L’accord avec la majorité est plus élevé, et ce n’est pas le plafond.
Les deux juges Azure ont atteint le plafond globalement, comme GPT-4 en 2023. Le juge moins cher était aussi bon que le plus puissant pour cette tâche.
Interrogez un juge de comparaison par paire dans les deux ordres. Ici, l’ordre changeait encore environ un verdict sur vingt; avec un seul appel, ces verdicts semblent certains.
La politique du juge vient des données de développement : les gens gardent la programmation et tout verdict dépendant de l’ordre. Testé une fois sur les données réservées, le juge a décidé pour 84 % des éléments avec un accord de niveau humain.

Ensuite, un autre type de notation : des experts notent des résumés selon quatre qualités. Vous trouvez quelle mesure automatique s’accorde avec eux, et pour quelle qualité.

Leçon suivante : Évaluer des résumés par rapport aux notes d'experts