Skip to content
Announcements8 min read

Potato 2.11: Die Labeling-Engine und zertifizierte Maschinenlabels

Potato 2.11 labelt mit Modellen, prüft die Labels an einer verblindeten menschlichen Stichprobe und schreibt ein Zertifikat. Inaktive Sitzungen enden nach 8 Stunden.

Potato Team

Potato 2.11 bringt die Labeling-Engine. Sie labelt einen Datensatz mit Modellen und misst an einer verblindeten Zufallsstichprobe menschlicher Labels, wie oft die Modelle falschliegen. Sie legen fest, was die fertigen Labels erfüllen müssen, zum Beispiel dass höchstens 10 % der akzeptierten Maschinenlabels falsch sind, bei 90 % Konfidenz. Die Engine akzeptiert die Maschinenlabels, die ein statistischer Test stützt, gibt die übrigen Items an Menschen weiter und schreibt ein Zertifikat, das festhält, was getestet wurde und an wie vielen menschlichen Labels. Außerdem erweitert das Release den Übereinstimmungsbericht auf 3D-Objekte, Temporal Grounding, mehrstufige Annotation und Agenten-Traces und behebt einen Fehler bei Bildern, durch den unberührte Items als beantwortet zählen konnten.

bash
pip install --upgrade potato-annotation

Hinweise zum Upgrade

Inaktive Sitzungen werden jetzt abgemeldet, standardmäßig nach 8 Stunden. Vor 2.11 hatte session_timeout_minutes in einer laufenden App keine Wirkung, weil die Prüfung an einem App-Objekt registriert war, das potato start verwirft. Eine Sitzung, die länger als eingestellt inaktiv bleibt, wird jetzt gelöscht, und ihre nächste Anfrage landet auf der Anmeldeseite. Auf Kiosk-Rechnern und gemeinsam genutzten Laborrechnern, die über Nacht angemeldet bleiben, kommt es dadurch zu Abmeldungen. Erhöhen Sie session_timeout_minutes also dort, wo eine Studie darauf angewiesen ist, dass Personen angemeldet bleiben. Bereits gespeicherte Annotationen sind nicht betroffen.

Drei ältere Schlüssel geben beim Start einen Hinweis aus. icl_labeling, judge_calibration und pre_annotation funktionieren genau wie bisher, und jeder gibt auf stderr eine Zeile aus, die mit NOTE: beginnt und sein Gegenstück in der Engine nennt. Die Hinweise dienen nur der Information, daher schlägt potato validate --strict ihretwegen nicht fehl. Die Schlüssel sollen in 3.0 entfernt werden, und potato label migrate-config schreibt den entsprechenden labeling_engine-Block für Sie.

Die Labeling-Engine

Die Engine ist für Studien gedacht, die mehr Items haben, als Menschen labeln können, und ein Modell, das meistens richtig liegt. Sie behandelt die Modelle als Quellen, die sie in einer Kaskade in der von Ihnen angegebenen Reihenfolge befragt, und nach der letzten Quelle geht ein Item an einen Menschen. Quellen können LLMs sein, Vision-Language-Modelle, Entscheidungsmodelle wie Laya, YOLO-Detektoren, LLM-Judges, Jurys, auf den eigenen Labels der Studie trainierte Modelle oder Labels, die Sie bereits haben.

Ein Vertrag ist das, was die Engine testet. Der wichtigste, selective_risk, begrenzt den Anteil falscher Labels unter den akzeptierten Maschinenlabels. Die Engine wählt an der einen Hälfte der verblindeten Stichprobe einen Konfidenzschwellenwert und testet ihn an der anderen Hälfte mit einem einseitigen Binomialtest, mit dem Fixed-Sequence-Verfahren von Learn-then-Test. Jeder neue Test läuft auf einem strengeren Niveau, sodass wiederholtes Zertifizieren, bis ein Test besteht, die Konfidenz nicht aufbläht. Der Vertrag ppi gibt die Prävalenz jedes Labels mit einem Intervall an, das mit Prediction-Powered Inference berechnet wird und unabhängig von der Qualität des Modells gültig bleibt. no_worse_than_human führt den Alternative-Annotator-Test aus, wenn eine Person oder ein Judge ersetzt werden soll, und distributional vergleicht die Labelverteilung des Modells damit, wie sich Menschen bei subjektiven Items aufteilen.

Eine Konfiguration, die ein LLM für ein Sentiment-Schema zertifiziert, ergänzt eine gewöhnliche Studie um zwei Schlüssel:

yaml
assignment_strategy: engine
 
labeling_engine:
  enabled: true
  sources:
    - id: gemma
      kind: llm
      endpoint_type: vllm
      model: google/gemma-4-12B-it-qat-w4a16-ct
      base_url: http://localhost:8001/v1
      confidence: {method: logprob}
  contracts:
    - id: accuracy
      kind: selective_risk
      schema: sentiment
      error: 0.1
      confidence: 0.9
  budgets:
    human_labels: 400

confidence: {method: logprob} liest die Konfidenz des Modells aus seinen Token-Wahrscheinlichkeiten. Das kostet einen Aufruf pro Item und ist unter den Konfidenzmethoden der Engine meist die am besten kalibrierte. Der Vertrag lässt höchstens 10 % falsche Labels unter den akzeptierten zu, und seine 90 % Konfidenz sind Potatos Standardwert. budgets.human_labels begrenzt, wie viele Anfragen an Menschen die Engine öffnen darf, und 400 ist die Obergrenze, die das mitgelieferte Textbeispiel verwendet.

Das Textbeispiel, das mit Potato ausgeliefert wird, schickt 481 Rezensionen durch eine Kaskade, in der Laya vor Gemma 12B steht. In diesem Lauf war der 10-%-Vertrag nach 165 menschlichen Labels erfüllt, und die Engine akzeptierte 316 Maschinenlabels, alle von Gemma, weil für Laya nie ein Schwellenwert festgelegt wurde. Ihr gemessener Fehler gegenüber den Referenzlabels lag bei 7,6 %. Das Beispiel für Agenten-Traces umfasst 288 synthetische Traces mit Referenzergebnissen. Der Judge lag bei 80 % davon richtig, gab aber jedem Urteil eine Konfidenz von 1,0, sodass selective_risk keinen Schwellenwert setzen konnte und nicht erfüllbar blieb. Das PPI-Intervall für den Aufgabenerfolg aus denselben Daten, [0,57; 0,76], enthielt die Referenzrate von 0,60, während der Judge allein 0,76 angab.

Grenzen eines erfüllten Vertrags

Ein erfüllter Vertrag ist eine Aussage über die Übereinstimmung mit den Menschen, die die Stichprobe gelabelt haben. Ob diese Menschen richtig liegen, prüft die Engine nicht. Ein Vertrag, der an nachlässigen Annotierenden getestet wurde, bescheinigt also Übereinstimmung mit nachlässigen Annotierenden. Drei Regeln sorgen dafür, dass diese Aussage gilt. Kalibrierungsanfragen sind verblindet, daher zeigt die Seite keine Vorannotation, kein Judge-Urteil und keine KI-Hilfe, solange eine Person eine solche Anfrage hält. Schwellenwerte werden an der einen Hälfte der Stichprobe gewählt und an der anderen getestet. Nur menschliche Labels zertifizieren, und jede Änderung an einer Quelle, einem Prompt oder einem Schema setzt die betroffenen Verträge auf stale, bis sie erneut getestet sind.

Schnittstellen zur Engine

Hinter jeder Schnittstelle steht dieselbe Datei engine.sqlite, daher können Sie eine Studie in der einen starten und in einer anderen zertifizieren:

  • potato label run|status|certify|certificate|export|calls|distill|optimize|migrate-config auf der Kommandozeile;
  • eine REST API unter /api/engine/v1;
  • fünf engine_*-Tools im MCP-Server;
  • potato.labeling_engine.sdk.Study in Python; und
  • eine Admin-Seite unter /admin/labeling-engine mit dem Status der Verträge, der Kurve aus Fehler und Abdeckung, einem Zuverlässigkeitsdiagramm pro Quelle und dem Protokoll der Modellaufrufe.

potato label export schreibt die Labels mit ihrer Herkunft, das Zertifikat als JSON, Markdown und HTML, eine Dataset Card und das Aufrufprotokoll. Die Labeling-Engine führt durch eine erste Studie, und Verträge der Labeling-Engine beschreibt, was jeder Vertrag testet und woran er scheitern kann.

Solo Mode

Solo Mode kann seinen Vorschlag jetzt verbergen. solo_mode.suggestions hält das Label des LLM bei allen Items oder bei einer Zufallsstichprobe zurück. Ein Vorschlag auf dem Bildschirm zieht die Antwort zu sich hin, daher liest die Übergabe die Übereinstimmung an den verblindeten Items ab. Entscheidungsmodelle (laya und jeder /v1/systemone-Server) können als schnelle erste Stufe dienen, und Solo Mode prüft ai_budget.cap_usd des Projekts vor dem Start des Labelings und vor jedem Batch. Neu sind außerdem ein Gold-Set, eine Labeling-Jury und eine Reihenfolge nach Curriculum. Wenn die Engine aktiv ist, schreibt Solo Mode seine Vorhersagen in den Speicher der Engine, sodass die Engine sie kalibrieren und zertifizieren kann. Die Konfigurationen stehen unter Solo Mode.

Übereinstimmung

/admin/iaa meldet jetzt die Übereinstimmung bei spatial_annotation, temporal_grounding, tiered_annotation und den fünf Agenten-Trace-Schemata, die bisher als nicht unterstützt übersprungen wurden. 3D-Objekte und Zeitsegmente erhalten eine mittlere Übereinstimmung über zugeordnete Mengen, die nicht zufallskorrigiert ist, und Schritte in Agenten-Traces erhalten Krippendorffs Alpha und Cohens Kappa, wobei jeder Schritt jedes Traces eine Einheit ist. /admin/api/agreement meldet keine strukturierten Schemata mehr und verweist stattdessen auf /admin/iaa, denn auf Labelnamen reduziert zeigten diese Schemata perfekte Übereinstimmung zwischen jedem Paar von Annotierenden. Zwei identische Segmente der Länge null gelten jetzt als übereinstimmend. Beim Veröffentlichen und im Paper-Modus fließen maschinelle Rater weder in Gold-Labels noch in Übereinstimmungswerte ein.

Korrekturen, die Studien mit 2.10 betreffen

Drei Korrekturen können Zahlen verändern, die Sie bereits erhoben oder berichtet haben:

  • Eine Bildseite speicherte eine vorausgefüllte Antwort von selbst. Bei einem image_annotation-Schema mit pre_annotation speicherte die Zeichenfläche die vorausgefüllten Formen als Antwort der annotierenden Person, wenn sie nach dem Laden ihr Layout neu berechnete, sodass ein unberührtes Item als beantwortet galt. Wenn in einer Bildstudie unter 2.10 mit Vorannotationen die gespeicherten Formen eines Items genau seiner Vorannotation entsprechen, wurde das Item möglicherweise nie angefasst. Behandeln Sie solche Items deshalb als ungeprüft, sofern Ihre Zeitdaten nichts anderes zeigen.
  • Der Paper-Modus berechnete Kappa mit eigenem Code. Der Paper-Modus und das Übereinstimmungsmodul berechnen Cohens Kappa jetzt über dieselbe Funktion wie /admin/iaa. Ein Kappa, das vor 2.11 aus dem Paper-Modus berichtet wurde, kann daher von dem Wert abweichen, den /admin/iaa für dieselben Daten zeigt.
  • Adjudikation und automatisches Skalieren bei Prolific zählten maschinelle Rater mit. Maschinelle Annotierende konnten ein Item in die Adjudikation schicken, min_human_annotations wurde ignoriert, und das automatische Skalieren bei Prolific zählte maschinelle Annotationen gegen die Obergrenzen pro Item.

Die übrigen Korrekturen ändern, was eine Studie tun kann. Bilder von Hosts, die keine CORS-Header senden, etwa cocodataset.org, laden jetzt. Bei einem solchen Bild erklären Regionsfüllung, SAM und Segmentierung per Textprompt jetzt, warum sie es nicht lesen können. Eine vorannotierte Form ohne color übernimmt die Farbe ihres Labels, statt verworfen zu werden. „Generate prompt“ in Solo Mode lässt jetzt das Revisionsmodell den ersten Prompt schreiben. Ablehnungen über potato mcp connect kommen als Tool-Fehler zurück statt als Erfolge. Die Suche nach Grenzfällen funktioniert jetzt unter vLLM, das die Grenzfall-Felder nicht zurückgab, bis sie in das Antwortschema aufgenommen wurden.

Installation von 2.11

Aktualisieren Sie mit pip install --upgrade potato-annotation oder ziehen Sie ghcr.io/davidjurgens/potato:2.11.0. Das Entscheidungsmodell Laya, das im Potato-Prozess läuft, braucht das neue Extra decision, pip install 'potato-annotation[decision]'. Es ist nicht Teil von all, weil es torch mitinstalliert. Die Release Notes führen jede Änderung auf, und Was ist neu fasst jedes 2.x-Release zusammen.