Das Kalibrierungstreffen instrumentieren

Zwei Dinge macht jedes Annotationsteam schlecht, weil die Werkzeuge nicht helfen: das Kalibrierungstreffen, das per Bildschirmfreigabe stattfindet und keine Spur hinterlässt, und das Verständnis dafür, warum ein Annotator ein Label gewählt hat, was meist auf ein Freitextfeld hinausläuft, das niemand ausfüllt. Potato 2.7 instrumentiert beides: einen Live-Norming-Raum mit einer Echtzeitanzeige der Übereinstimmung und einen Rekorder fürs laute Denken, dessen Spracherkennung lokal läuft. Keines von beiden braucht ein LLM.

Das Treffen, das keine Belege hinterlässt

Wer je ein Annotationsprojekt mit mehr als zwei Leuten geleitet hat, hat eine Norming-Sitzung abgehalten. Alle labeln dieselbe Handvoll Elemente, dann trifft man sich in einer Konferenz, streitet über die Uneinigkeiten und einigt sich irgendwann darauf, was die Richtlinie eigentlich meint.

Das funktioniert. Es ist aber völlig uninstrumentiert. Die Stimmen, die die Leute vor der Diskussion hatten, sind weg. Wer seine Meinung geändert hat und ob aus Überzeugung oder weil eine erfahrene Kollegin zuerst gesprochen hat, ist weg. Und ob das Treffen die Übereinstimmung überhaupt verbessert hat, kann niemand beantworten, weil es niemand gemessen hat.

Multiplayer-Räume holen diese Sitzung ins Werkzeug.

Ein Norming-Raum mitten in der Sitzung

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

/rooms öffnen, einen Raum anlegen, und er bekommt einen sechsstelligen Code, den man in der Konferenz vorlesen kann. Der Ablauf ist mit Absicht so gebaut:

1. Alle stimmen blind ab. Die Mitglieder sehen, wer abgestimmt hat, nie was. Das wird serverseitig durchgesetzt, sodass die ersten Eindrücke wirklich unabhängig sind.
2. Der Host deckt auf. In diesem Moment werden die blinden Stimmen unveränderlich.
3. Die Gruppe diskutiert, im Seiten-Chat oder in der Konferenz.
4. Jeder darf seine Stimme ändern. Jede Änderung nach der Aufdeckung wird protokolliert, mit dem alten Wert, dem neuen Wert und der Mehrheit in diesem Moment.

Der vierte Schritt ist der interessante. Eine Stimmänderung nach der Aufdeckung ist nicht dasselbe Ereignis wie eine Stimme; sie ist eine Änderung bei bekannter Mehrheit. Protokolliert ergibt sie ein Konformitätsprotokoll pro Mitglied, und daran fällt auf, dass ein Annotator jedes einzelne Mal zur Mehrheit umschwenkt. Das sollte man wissen, bevor man seine Zustimmung als unabhängigen Beleg behandelt.

Die Übereinstimmungsanzeige beantwortet „Hat sich das gelohnt?"

Krippendorffs α wird live zweimal über die aufgedeckten Elemente berechnet: einmal auf den blinden Stimmen, einmal auf den aktuellen. Der Abstand dazwischen ist der Norming-Gewinn der Sitzung, und er steht auf dem Bildschirm, während die Sitzung läuft.

Diese Zahl macht das Treffen rechenschaftspflichtig. Hat eine Stunde Diskussion α von 0,61 auf 0,78 bewegt, dann hat die Stunde etwas gebracht. Ging es von 0,61 auf 0,62, dann liegt die Uneinigkeit nicht an der Auslegung. Sie liegt an der Richtlinie, und noch so viel Reden wird das nicht beheben. Dann besser die Richtlinie neu schreiben.

Zwei Varianten sollte man kennen. Huddles füllen einen Raum genau mit den Elementen, bei denen das Team derzeit uneinig ist, live aus dem Annotationsstand berechnet, was sie zur synchronen Fassung der Adjudikation macht. In Shadow-Räumen sehen Angelernte einem erfahrenen Annotator in Echtzeit bei der Arbeit zu, samt der Textstelle, die er gerade hervorhebt. Näher kommt man dem Danebensitzen beim Annotieren nicht.

Räume sind event-sourced in ein JSONL-Protokoll, ein laufender Raum übersteht also einen Serverneustart, und das Protokoll dient zugleich als Prüfpfad der Sitzung. WebSockets sind nicht beteiligt; die Clients fragen mit einem Cursor ab, und deshalb funktionieren Räume unter jedem WSGI-Deployment.

Die Überlegung, die nie erfasst wurde

Das andere stille Versagen sind die Begründungen. Die meisten Werkzeuge bieten ein Freitextfeld an, und die meisten Annotatoren tippen „offensichtlich" hinein, oder gar nichts.

Das ist keine Faulheit. Die eigene Überlegung aufzuschreiben dauert wirklich länger, als sie zu haben, und bei einer Aufgabe mit 400 Elementen fällt das Begründungsfeld als Erstes weg.

Der Think-Aloud-Modus nimmt die Reibung heraus, indem er die Modalität wechselt: Annotatoren sprechen einfach, während sie arbeiten.

Think-Aloud, mit erkanntem Label

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

Die Spracherkennung läuft lokal über faster-whisper, das mit dem 39 MB großen Modell tiny.en auf der CPU echtzeitfähig ist. Das Audio verlässt den Rechner nie, es gibt keine Cloud-API aufzurufen und keine Rechnung pro Token. Bei vielen sensiblen Daten ist das der Unterschied zwischen „das können wir einsetzen" und „die Rechtsabteilung hat abgelehnt".

Das Lautes-Denken-Protokoll war der Goldstandard für die Untersuchung menschlicher Entscheidungen, lange bevor irgendetwas davon computergestützt war. In die Annotationswerkzeuge hat es den Sprung nie geschafft, denn jemanden in ein Aufnahmegerät sprechen und das Ganze dann von Hand abtippen zu lassen, hält als Arbeitsablauf niemand durch.

Wortgetreu, mit Absicht

Das Transkript wird genau so gespeichert, wie es gesprochen wurde, und bewusst nicht zusammengefasst. Das ist eine echte Entwurfsentscheidung und keine Bequemlichkeit: Wer ein Lautes-Denken-Protokoll paraphrasiert, verfälscht das Artefakt. Das Zögern, die Selbstkorrekturen, das „na ja, es könnte sarkastisch sein, aber…": Das sind die Daten. Eine aufgeräumte Zusammenfassung davon ist ein anderes und deutlich weniger nützliches Objekt.

Labels lassen sich auch per Stimme festlegen, über feste Formulierungen, die ein regelbasierter Parser erkennt:

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

Nur diese Formulierungen legen fest. Alles, was beim Nachdenken fällt, wird ignoriert, und genau deshalb reicht ein regelbasierter Parser. In der Pipeline steckt an keiner Stelle ein LLM, und kein Modell entscheidet, was gemeint war. Fällt später eine neue Formulierung, gilt die letzte Festlegung.

Dazu kommen deterministische Zögersignale (Zahl der stillen Chunks, Zahl der Füllwörter), mit Arithmetik statt mit einem Modell berechnet. Lange Pausen bei einem Element sind ein brauchbares Indiz für Schwierigkeit, und ihre Erhebung kostet nichts.

Warum das über Begründungen hinaus zählt

Hier ist der Teil, der an den Rest von Potato 2.7 anschließt.

Think-Aloud ist ein Rekorder für die Gedankenkette des Menschen. Er hält fest, wie eine Person sich tatsächlich zu einem Label durchdenkt: keine im Nachhinein aufgeräumte Rechtfertigung, sondern die Überlegung, während sie stattfindet, Fehlstarts inklusive.

Potatos Prozessbelohnungsannotation leistet dasselbe für ein Modell: Sie zerlegt die Gedankenkette eines Modells und bewertet sie Schritt für Schritt.

Dasselbe Element, zwei Gedankenketten, eine vom Menschen und eine vom Modell. Nebeneinandergelegt zeigt sich, wo die Überlegungen auseinandergehen. Das ist wirklich etwas Neues, und es ist der Rohstoff für bessere Prozessbelohnungsdaten, denn „das Modell hatte die richtige Antwort aus dem falschen Grund" ist genau der Fehler, den eine Bewertung der Endantwort nicht sehen kann.

Potato liefert beide Aufzeichnungsflächen. Ein Diff zwischen ihnen berechnet es nicht. Das ist eher eine Forschungsfrage als eine Funktion, und wir geben lieber das Artefakt heraus als eine Kennzahl, die wir uns ausgedacht haben.

Weiterführende Informationen

• Multiplayer-Räume und Think-Aloud-Modus — vollständige Konfiguration
• Inter-Annotator-Übereinstimmung — was α eigentlich misst
• Adjudikation und Uneinigkeit
• Labels mit Fehlerbalken — die Psychometrie markiert die Codebuch-Probleme; in Räumen behebt man sie
• Prozessbelohnungsmodelle — die Gedankenkette auf der Modellseite