Verträge der Labeling-Engine

Ein Vertrag ist eine Aussage über die fertigen Labels, die die Labeling-Engine an menschlichen Labels einer Zufallsstichprobe testet. Jeder Vertrag nennt ein Annotationsschema (schema) und hat eine confidence, standardmäßig 0,9, also die Wahrscheinlichkeit, dass die Aussage zutrifft. Eine confidence von 0,9 lässt demnach eine Wahrscheinlichkeit von 10 % zu, dass ein erfüllter Vertrag falsch ist.

Die sechs Arten treffen unterschiedliche Aussagen und passen zu unterschiedlichen Studien:

Keiner dieser Verträge sagt, dass die Labels fehlerfrei sind. selective_risk begrenzt die Fehlerrate unter den akzeptierten Labels, und jeder Vertrag, der die Maschinen testet, misst sie an den Menschen, die die Stichprobe gelabelt haben.

Vertragsstatus

Jeder Vertrag hat einen von fünf Status, angezeigt auf der Admin-Seite, von potato label status und im Zertifikat:

Ein Maschinenlabel wird nur akzeptiert, wenn jeder selective_risk- und threshold_legacy-Vertrag auf seinem Schema erfüllt ist und es akzeptiert. Die Verträge legen fest, was die Labels erfüllen müssen. Ein nicht erfüllter Vertrag wird deshalb nicht übersprungen, sondern blockiert die Akzeptanz, und Status, Admin-Seite und Zertifikat nennen den Vertrag, der nicht erfüllt ist. Wenn keine Regel gelten kann und keine weitere Stichprobe gezogen wird (ein Vertrag ist nicht erfüllbar, die Kalibrierungsstichprobe ist abgeschlossen oder es ließ sich nichts hochrechnen), gehen die Items, die noch kein Label haben, an Menschen, innerhalb von budgets.human_labels.

dev- und cert-Split

Die Engine hält die Labels, die eine Regel wählen, getrennt von den Labels, die sie testen. Kalibrierungsanfragen werden zufällig mit einer gespeicherten Einschlusswahrscheinlichkeit gezogen, sind immer verblindet, und jede kommt zufällig in einen von zwei Splits:

• dev (humans.dev_fraction, standardmäßig die Hälfte) passt Kalibratoren an und wählt Schwellenwerte;
• cert testet die gewählte Regel, und nichts anderes liest ihn.

Looks

Jeder neue Test eines Vertrags, ein sogenannter Look, läuft auf einem strengeren Niveau, sodass erneutes Testen beim Eintreffen neuer Labels die Konfidenz nicht aufbläht. Look k erhält (1 - confidence) * 6 / (pi^2 k^2) des Fehlerbudgets. Über alle möglichen Looks summiert ergibt das das gesamte Budget, und der erste Look erhält 61 % davon.

• Looks werden pro Vertrag gezählt, über jede Kaskade hinweg, unter der er getestet wurde, und ein umbenannter Vertrag behält die Looks seiner alten ID. Prompts oder Modelle auszuprobieren, bis eines besteht, kostet jedes Mal einen Look. Auch die Rückkehr zu einer früheren Kaskade ist ein neuer Look, und ihr früheres Ergebnis wird nicht wiederhergestellt.
• Dieselben Daten erneut zu testen ist kein neuer Look. Dieselben cert-Labels, dieselben Vorhersagen und dieselbe auf dev gewählte Regel liefern das gespeicherte Ergebnis zurück. Ein Test, der nicht ausgeführt werden konnte, zum Beispiel weil eine Klasse keine cert-Labels hat, verbraucht nichts.
• potato label certify testet neue cert-Labels und neue Vorhersagen auf einmal, ebenso die Entsprechungen in REST, MCP und SDK. Wenn sich nur dev-Labels geändert haben, gibt der Befehl das gespeicherte Ergebnis mit dem Hinweis zurück, dass dev jetzt eine andere Regel wählt, und --retest testet diese Regel beim nächsten Look.
• Der Planer zertifiziert von selbst, während Labels eintreffen. Ein erfüllter selective_risk-Vertrag bleibt für seine Kaskade erfüllt, und Audits überwachen ihn. Ein nicht erfüllter Vertrag wird erneut getestet, sobald seine Labels um ein Viertel gewachsen sind, und um mindestens 10. Ergebnisse von ppi, distributional und no_worse_than_human sind Schätzungen und keine Tests mit Bestanden oder Nicht bestanden. Der Planer schätzt sie daher an denselben Meilensteinen neu und noch einmal, wenn die Kalibrierungsstichprobe vollständig ist.
• Ein bearbeitetes cert-Label sind neue Daten. Wenn eine annotierende Person ihre Antwort ändert, kostet die Bearbeitung nicht mehr als ein neues Label. Wird auf einen bereits getesteten Zustand zurückbearbeitet, kehrt das Ergebnis dieses Tests zurück. Sieht keiner der Tests des gespeicherten Ergebnisses nach der Bearbeitung mehr Fehler, bleiben das Ergebnis und sein Look bestehen. Andernfalls wartet der Planer, bis die Labels ab der ersten Bearbeitung um ein Viertel gewachsen sind, sodass eine Reihe von Korrekturen zu einem einzigen Test wird. Akzeptierte Labels bleiben in der Zwischenzeit akzeptiert, mit einem Hinweis am Vertrag. Wenn keine weiteren Labels mehr kommen, testet er sofort, und ein ausdrückliches Zertifizieren testet beim nächsten Look.

Labels, die Menschen nach dem Anblick einer Maschinenantwort gegeben haben (Prüfanfragen), und Labels, die außerhalb der Anfragen der Engine gegeben wurden, zertifizieren und schätzen nie etwas. Sie können ein destilliertes Modell trainieren.

selective_risk

selective_risk begrenzt den Anteil falscher Labels unter den akzeptierten Maschinenlabels. Der Schlüssel error ist die höchste tolerierte Fehlerrate unter den akzeptierten Labels und ist Pflicht:

- id: accuracy
  kind: selective_risk
  schema: sentiment
  error: 0.05          # required: largest tolerated error among accepted labels
  confidence: 0.9
  per_class: true      # test each predicted class separately
  tolerance: 0.5       # graded families only: loss at or below this counts as correct

Die Regel ist ein Konfidenzschwellenwert für jede Stufe der Kaskade und mit per_class für jede vorhergesagte Klasse. Für jede Stufe außer der letzten wird der Schwellenwert auf dev gewählt und einmal auf cert getestet. Die letzte Stufe probiert Schwellenwerte von der dev-Wahl aus zunehmend großzügiger durch, testet jeden nacheinander und hört beim ersten auf, der scheitert. Dieses Verfahren ist Learn-then-Test mit fester Reihenfolge (Angelopoulos et al., 2025). Jeder Test ist ein einseitiger Binomialtest darauf, dass der Fehler unter den akzeptierten Labels über error liegt, wobei das Niveau auf Stufen und Klassen aufgeteilt wird. Eine Stufe, die scheitert, akzeptiert nichts, und ihre Items gehen an Menschen.

Was als „richtig“ gilt, hängt von der Schemafamilie ab. Der Verlust für jede Familie steht in der Tabelle, und ein Label gilt als richtig, wenn sein Verlust höchstens tolerance beträgt:

Die Verluste für Regionen, Segmente, 3D-Objekte und Traces sind dieselben, die der Übereinstimmungsbericht unter /admin/iaa verwendet. Eine Maschine wird also so an einem Menschen gemessen, wie zwei Menschen aneinander gemessen werden. Freitext- und paarweise Schemata haben noch keine Familie, und das Zertifikat führt sie als nicht unterstützt auf.

Der Test setzt voraus, dass jede getestete Gruppe von cert-Items eine gleichverteilte Stichprobe ist. Eine Gruppe, deren Items mit ungleichen Wahrscheinlichkeiten gezogen wurden, wird nicht getestet, und das Ergebnis nennt sie.

Auf der letzten Stufe wird ein Schwellenwert auf dev nur dort gewählt, wo der Fehler auf dev höchstens die Hälfte des Ziels beträgt und genug cert-Labels zu erwarten sind, um einen ersten Test zu bestehen. Die Hochrechnung, wie viele Labels noch nötig sind, zählt nur Schwellenwerte, die auf diese Weise gewählt werden könnten. Wenn cert bereits die Labels hat, die die Hochrechnung verlangt hat, und der Test trotzdem scheitert, verwendet die nächste Hochrechnung die Fehlerrate, die dev und cert zusammen zeigen, nicht die von dev allein. Liegt der niedrigste Fehler auf dev unter dem Ziel, aber über dessen Hälfte, wird nichts getestet und nichts hochgerechnet. Das Ergebnis sagt das und nennt den Fehler, denn mehr Labels helfen nur, wenn sich der Fehler als niedriger herausstellt.

metrics.accepted_by_tier ist die Abdeckung der Regel über die gesamte Population, Kalibrierungsitems eingeschlossen, und keine Zählung ausgelieferter Maschinenlabels. Diese zählt die Zeile „Machine labels accepted, by source“ im Zertifikat.

Der Trace-Verlust vergleicht nur die Schritte, die beide Seiten gelabelt haben. Eine Person, die einige Schritte markiert hat, wird also auf diesen Schritten verglichen. Schritte, die niemand gelabelt hat, werden nicht geprüft, und eine Person, die nur Schritt 0 labelt und dort mit dem Judge übereinstimmt, zählt als übereinstimmend mit dem Label des gesamten Traces. Wo jeder Schritt geprüft werden muss, bitten Sie Menschen, jeden Schritt zu labeln.

ppi

ppi gibt für die Prävalenz jedes Labels oder für einen mittleren Score ein Intervall an, das um die Fehler der Maschine korrigiert ist:

- id: prevalence
  kind: ppi
  schema: sentiment
  estimand: prevalence   # or mean, for numeric scores
  by: language           # optional: an interval per value of this item field
  confidence: 0.95
  max_width: 0.05        # optional: met once every interval is at most this wide

Prediction-Powered Inference (Angelopoulos et al., 2023) korrigiert die Schätzung der Maschine mit ihrem Fehler auf der von Menschen gelabelten Stichprobe. Das Intervall ist unabhängig von der Qualität der Maschine gültig. Eine gute Maschine macht es schmaler, als Menschen allein es könnten, und eine schlechte macht es nicht breiter. Bei gleichen Einschlusswahrscheinlichkeiten verwendet die Engine PPI++ mit einem abgestimmten Gewicht, bei ungleichen (geschichtete oder unsicherheitsgesteuerte Stichprobe) den Horvitz-Thompson-Differenzschätzer. Das Maschinenlabel, das sie verwendet, ist dasjenige, das die Kaskade ausliefern würde. Das Feld by wird aus den Items kopiert, wenn diese registriert werden. Ohne max_width ist der Vertrag erfüllt, sobald er genug Labels für eine Angabe hat.

no_worse_than_human

no_worse_than_human fragt, ob die Maschine mindestens so oft mit Menschen übereinstimmt wie ein Mensch:

- id: replaces-a-person
  kind: no_worse_than_human
  schema: verdict
  epsilon: 0.1

Der Vertrag führt den Alternative-Annotator-Test aus (Calderon et al., 2025). Er lässt nacheinander jede Person weg und testet, ob die Maschine mit den übrigen Menschen mindestens so oft übereinstimmt wie die weggelassene Person, bis auf epsilon. Die Maschine besteht, wenn sie gegen mindestens die Hälfte der Menschen gewinnt, wobei die False Discovery Rate über die Menschen hinweg kontrolliert wird.

Der Test braucht Items, die von mehreren Menschen gelabelt wurden. Setzen Sie humans.overlap (den Anteil der Stichprobe, der mehr als einmal gelabelt wird) und humans.overlap_k (Menschen pro Item, mindestens 3). Der Test braucht außerdem mindestens 3 Annotierende mit jeweils 30 Items. Bis dahin bleibt der Vertrag insufficient. Verwenden Sie diesen Vertrag, wenn ein festes Genauigkeitsziel vor allem das Rauschen der Annotierenden messen würde. Wenn zwei sorgfältige Menschen in 85 % der Fälle übereinstimmen, lässt sich für niemanden, der labelt, zeigen, dass er zu 95 % „richtig“ liegt.

budget_first

budget_first rechnet hoch, was ein Budget an menschlichen Labels einbringt, bevor Sie es ausgeben:

- id: plan
  kind: budget_first
  schema: sentiment
  human_labels: 500      # or human_usd, priced at the crowd reward

Die Hochrechnung stützt sich auf die bisher gesammelten dev-Labels. Für jedes Fehlerziel auf einem Raster gibt sie an, für welchen Anteil des Korpus sich die Maschinen mit diesem Budget zertifizieren ließen und wie breit jedes Prävalenzintervall wäre. Der Vertrag ist met, sobald genug dev-Labels für eine Hochrechnung vorliegen. Er verspricht nichts über die Labels. Das tun selective_risk und ppi, sobald die Labels vorliegen.

distributional

distributional vergleicht die Labelverteilung der Maschine damit, wie sich Menschen aufteilen. Das ist für subjektive Aufgaben gedacht, bei denen Menschen aus Gründen uneinig sind, die in die Daten gehören:

- id: disagreement
  kind: distributional
  schema: offensiveness
  max_distance: 0.15     # optional
  groups_by: age_band    # optional: a prestudy question whose answer groups the annotators

Jedes Item, das mehrere Menschen gelabelt haben (humans.distribution_k, standardmäßig 5), hat eine menschliche Labelverteilung. Der Vertrag gibt die mittlere Jensen-Shannon-Distanz zwischen der Verteilung der Maschine und der der Menschen an, mit einem Bootstrap-Intervall. Außerdem gibt er eine Rauschobergrenze an, nämlich dieselbe Distanz zwischen zwei zufälligen Hälften der Menschen auf jedem Item. Eine Maschine, die näher an den Menschen liegt als diese untereinander, ist so nah, wie es die Daten zulassen.

Die Verteilung der Maschine besteht aus ihren Wahrscheinlichkeiten, wo die Quelle sie liefert (Entscheidungsmodelle, k_sample, logprob), oder aus ihrem Label als One-Hot-Vektor. Der Vertrag ist erfüllt, wenn das obere Ende des Intervalls höchstens max_distance beträgt, oder ohne max_distance, sobald es 20 Items gibt, die von 3 oder mehr Menschen gelabelt wurden. Liegt das untere Ende des Intervalls über max_distance, ist er infeasible, denn mehr Items verengen das Intervall nur um eine Distanz, die zu groß ist.

Mit groups_by werden dieselben Zahlen pro Gruppe von Annotierenden angegeben. Die Verteilung jeder Gruppe auf einem Item wird nur aus den Menschen dieser Gruppe gebildet, abgelesen an ihren Antworten auf die genannte Frage vor der Studie. Hat niemand die Frage beantwortet, sagt der Vertrag das.

threshold_legacy

threshold_legacy akzeptiert Maschinenlabels oberhalb einer festen Konfidenz und führt keinen statistischen Test aus:

- id: old-rule
  kind: threshold_legacy
  schema: sentiment
  threshold: 0.8

potato label migrate-config schreibt diesen Vertrag für icl_labeling mit dem alten confidence_threshold, sodass sich eine übersetzte Konfiguration wie zuvor verhält. Sie können ihn auch von Hand schreiben. Das Zertifikat markiert diese Labels als nicht zertifiziert und gibt ihren gemessenen Fehler auf den Kalibrierungslabels an, und der Export gibt ihnen den Status accepted_uncertified.

Ergebnisse der Beispielstudien

Die drei Beispielstudien unter examples/labeling-engine/ liefen mit LLM-, Judge- und Vision-Quellen, die auf Gemma 12B auf einem vLLM-Server zeigten, statt auf die Ollama-Modelle, die die eingecheckten Konfigurationen verwenden. Die README jedes Beispiels zeigt den geänderten Quellenblock, und mit den Ollama-Standards werden die Zahlen abweichen.

• Text-Sentiment (481 Rezensionen, Gemma 12B mit logprob-Konfidenz als letzte Stufe). selective_risk bei 10 % und 0,9 war auf 165 menschlichen Labels erfüllt, und 316 Maschinenlabels wurden akzeptiert. Ihr gemessener Fehler gegenüber den wahren Labels lag bei 7,6 %, und die PPI-Intervalle deckten die wahre Prävalenz aller drei Labels ab.
• Bilder (128 COCO-Bilder, YOLOv8n und Gemma 12B als Vision-Modell). Ein Label „enthält eine Person“ wurde bei 10 % zertifiziert. Der Vertrag für die Begrenzungsrahmen blieb insufficient, weil die Rahmen von YOLOv8n bei IoU 0,5 auf 32 % der dev-Bilder falsch waren.
• Agenten-Traces (288 Traces, Gemma 12B als Judge). Der Judge lag bei 80 % der Traces richtig, aber seine Konfidenz war durchweg 1,0, sodass selective_risk nicht erfüllbar war. Der Alternative-Annotator-Test blieb unzureichend, mit 0,82 für die Maschine gegenüber 0,93 für die Menschen. PPI schätzte den Aufgabenerfolg auf 0,66 [0,57; 0,76], bei einem wahren Wert von 0,60, während der Judge allein 0,76 angab, 16 Punkte zu hoch.

Weiterführende Lektüre

• Die Labeling-Engine
• Konfiguration der Labeling-Engine, einschließlich der humans-Schlüssel, die diese Verträge lesen
• Inter-Annotator-Übereinstimmung und Übereinstimmung über Geometrie, die dieselben Verluste für Regionen, Segmente und 3D-Objekte verwendet

Implementierungsdetails stehen in der Quelldokumentation.

Literatur

1. Angelopoulos, A. N., Bates, S., Candès, E. J., et al. (2025). Learn then test: Calibrating predictive algorithms to achieve risk control. The Annals of Applied Statistics. https://doi.org/10.1214/24-AOAS1998
2. Angelopoulos, A. N., Bates, S., Fannjiang, C., et al. (2023). Prediction-powered inference. Science, 382(6671). https://doi.org/10.1126/science.adi6000
3. Angelopoulos, A. N., Duchi, J. C., and Zrnic, T. (2023). PPI++: Efficient prediction-powered inference. arXiv. https://arxiv.org/abs/2311.01453
4. Calderon, N., Reichart, R., and Dror, R. (2025). The alternative annotator test for LLM-as-a-judge: How to statistically justify replacing human annotators with LLMs. Proceedings of ACL 2025. https://aclanthology.org/2025.acl-long.782/