Instrumenter la réunion de calibrage

Deux choses que toutes les équipes d'annotation font mal, parce que leurs outils ne les aident pas : la réunion de calibrage, qui se tient en partage d'écran et ne laisse aucune trace, et la compréhension du pourquoi un annotateur a choisi une étiquette, qui se réduit d'ordinaire à un champ de texte libre que personne ne remplit. Potato 2.7 instrumente les deux : une salle de normalisation en direct avec un indicateur d'accord en temps réel, et un enregistreur de pensée à voix haute dont la reconnaissance vocale tourne en local. Ni l'un ni l'autre n'a besoin d'un LLM.

La réunion qui ne laisse aucune preuve

Si vous avez mené un projet d'annotation à plus de deux personnes, vous avez tenu une séance de normalisation. Tout le monde étiquette la même poignée d'éléments, on se met en visio, on se dispute sur les désaccords, et on finit par converger sur ce que la consigne veut dire au juste.

Ça marche. Et ce n'est absolument pas instrumenté. Les votes que les gens tenaient avant la discussion sont perdus. Qui a changé d'avis, et s'il a changé parce qu'il a été convaincu ou parce qu'un collègue plus ancien a parlé en premier, est perdu. Et savoir si la réunion a seulement amélioré l'accord est une question à laquelle personne ne peut répondre, parce que personne ne l'a mesuré.

Les salles multijoueur font entrer cette séance dans l'outil.

Une salle de normalisation en pleine séance

rooms:
  enabled: true
  who_can_create: any
  persist_votes: true
  schema: sarcasm

Ouvrez /rooms, créez-en une, et elle reçoit un code de six lettres que vous pouvez lire à voix haute pendant l'appel. Le déroulé est délibéré :

1. Tout le monde vote à l'aveugle. Les membres voient qui a voté, jamais quoi. C'est appliqué côté serveur, donc les premières impressions sont réellement indépendantes.
2. L'hôte révèle. À cet instant, les votes à l'aveugle deviennent immuables.
3. Le groupe discute, dans un chat latéral ou pendant l'appel.
4. Chacun peut changer son vote. Chaque changement postérieur à la révélation est enregistré avec le vote de départ, le vote d'arrivée et la majorité du moment.

C'est la quatrième étape qui est intéressante. Un changement de vote après la révélation n'est pas le même événement qu'un vote ; c'est un changement en présence d'une majorité connue. L'enregistrer vous donne un relevé de conformité par membre, et c'est ainsi que vous remarquez qu'un annotateur bascule vers la majorité à chaque fois, sans exception. Cela vaut la peine d'être su avant de traiter son accord comme une preuve indépendante.

L'indicateur d'accord répond à « est-ce que ça valait le coup ? »

L'α de Krippendorff est calculé deux fois, en direct, sur les éléments révélés : une fois sur les votes à l'aveugle, une fois sur les votes actuels. L'écart entre les deux est le gain de normalisation de la séance, et il est à l'écran pendant qu'elle se déroule.

C'est le nombre qui rend la réunion redevable. Si une heure de discussion a fait passer l'α de 0.61 à 0.78, vous savez que l'heure a rapporté quelque chose. Si elle l'a fait passer de 0.61 à 0.62, vous avez appris que le désaccord ne porte pas sur l'interprétation. Il porte sur la consigne, et aucune quantité de discussion n'y changera rien. Allez plutôt réécrire la consigne.

Deux variantes valent d'être connues. Les huddles amorcent une salle avec exactement les éléments sur lesquels votre équipe est actuellement en désaccord, calculés en direct à partir de l'état d'annotation, ce qui en fait une version synchrone de l'arbitrage. Les salles shadow permettent aux personnes en formation de regarder un annotateur chevronné travailler en temps réel, y compris le passage de texte qu'il surligne. C'est ce qui se rapproche le plus du fait d'être assis à côté de quelqu'un pendant qu'il annote.

Les salles reposent sur un journal d'événements JSONL, si bien qu'une salle en cours survit à un redémarrage du serveur, et le journal fait aussi office de piste d'audit de la séance. Il n'y a aucun WebSocket ; les clients se synchronisent en sondant avec un curseur, ce qui veut dire que les salles fonctionnent sous n'importe quel déploiement WSGI.

Le raisonnement que vous n'avez jamais capté

L'autre échec silencieux, ce sont les justifications. La plupart des outils offrent un champ de texte libre, et la plupart des annotateurs y tapent « évident », ou rien du tout.

Ce n'est pas de la paresse. Écrire son raisonnement est réellement plus lent que l'avoir, et si la tâche fait 400 éléments, le champ de justification est la première chose à sauter.

Le mode Think-Aloud supprime cette friction en changeant de modalité : les annotateurs parlent, tout simplement, pendant qu'ils travaillent.

Think-Aloud, avec une étiquette détectée

thinkaloud:
  enabled: true
  schema: politeness
  model: tiny.en

La reconnaissance vocale tourne en local via faster-whisper, qui fonctionne en temps réel sur CPU avec le modèle tiny.en de 39 Mo. L'audio ne quitte jamais la machine, et il n'y a aucune API cloud à appeler ni facture au token à payer. Pour beaucoup de données sensibles, c'est la différence entre « on peut s'en servir » et « le service juridique a dit non ».

Le protocole de pensée à voix haute était la référence pour étudier la façon dont les gens décident, bien avant que tout cela ne devienne computationnel. Il n'est jamais entré dans les outils d'annotation, parce que demander à quelqu'un de raconter dans un enregistreur puis de retranscrire à la main n'est pas un flux de travail que l'on tient.

Mot à mot, exprès

La transcription est conservée telle qu'elle a été prononcée, délibérément non résumée. C'est un vrai choix de conception, pas de la paresse : paraphraser un protocole de pensée à voix haute contamine l'objet recueilli. Les hésitations, les autocorrections, le « bon, ça pourrait être sarcastique, mais… » : c'est ça, les données. Un résumé bien propre en est un objet différent, et beaucoup moins utile.

Les annotateurs peuvent aussi valider une étiquette à la voix, au moyen de formulations fixées qu'un analyseur à base de règles repère :

• "I label this Polite"
• "My answer is impolite"
• "Final answer: neutral"

Seules ces formulations valident. Tout ce qui est dit pendant la réflexion est ignoré, et c'est ce qui rend un analyseur à base de règles suffisant. Il n'y a aucun LLM nulle part dans la chaîne, et aucun modèle qui décide de ce que vous vouliez dire. Prononcez une nouvelle formule plus tard et c'est la dernière validation qui l'emporte.

Vous obtenez aussi des signaux d'hésitation déterministes (nombre de tranches silencieuses, nombre de mots de remplissage), calculés par arithmétique plutôt que par un modèle. De longues pauses sur un élément sont une approximation correcte de sa difficulté, et elles ne coûtent rien à recueillir.

Pourquoi cela dépasse la question des justifications

Voici la partie qui rejoint le reste de Potato 2.7.

Think-Aloud est un enregistreur de chaîne de raisonnement humaine. Il capte la façon dont une personne raisonne réellement jusqu'à une étiquette : pas une justification nettoyée après coup, mais le raisonnement pendant qu'il se fait, faux départs compris.

L'annotation de récompense de processus de Potato fait le même travail pour un modèle : elle découpe la chaîne de raisonnement d'un modèle et la note étape par étape.

Même élément, deux chaînes de raisonnement, une humaine et une machine. Vous pouvez les mettre côte à côte et regarder où les raisonnements divergent. C'est vraiment quelque chose de nouveau, et c'est la matière première de meilleures données de récompense de processus, parce que « le modèle a trouvé la bonne réponse pour la mauvaise raison » est exactement l'échec que la notation sur la réponse finale ne peut pas voir.

Potato vous donne les deux surfaces de capture. Il ne calcule pas la différence entre elles à votre place. C'est une question de recherche plutôt qu'une fonctionnalité, et nous préférons vous remettre l'objet qu'une métrique inventée par nos soins.

Pour aller plus loin

• Salles multijoueur et mode Think-Aloud — la configuration complète
• Accord inter-annotateurs — ce que l'α mesure au juste
• Arbitrage et résolution du désaccord
• Des étiquettes avec barres d'erreur — la psychométrie signale les problèmes de livre de codes ; les salles sont l'endroit où on les corrige
• Modèles de récompense de processus — la chaîne de raisonnement côté modèle