Konfiguration der Labeling-Engine

Alles, was die Labeling-Engine tut, wird in einem einzigen labeling_engine-Block festgelegt. Ein ungültiger Block hält den Server beim Start an und listet alle Probleme auf einmal auf. Damit Annotierende die Anfragen der Engine erhalten, setzen Sie außerdem assignment_strategy: engine. Diese Strategie ohne aktivierte Engine zu setzen, ist ein Validierungsfehler.

Der Block hat diese Abschnitte, die unten jeweils beschrieben sind:

assignment_strategy: engine
 
labeling_engine:
  enabled: true
  schemas: [sentiment]            # default: every scheme a source can label
  sources: []
  cascade: [laya, gemma]          # default: the first source alone
  contracts: []
  humans: {}
  crowd: {}
  budgets: {}
  runtime: {}
  features: {}
  redaction: {}
  distill: {}

Schlüssel der obersten Ebene

Fünf Schlüssel stehen direkt unter labeling_engine:

Quellen

Eine Quelle ist ein Modell oder ein vorhandener Satz von Labels, der für jedes Item ein Label und eine Konfidenz vorschlägt. Jede Quelle hat eine eindeutige id und eine kind, und ein unbekannter Schlüssel an einer Quelle ist ein Fehler:

Alles, was eine Antwort verändern kann (Modell, Prompt, Temperatur, Optionen), fließt in den Versions-Hash der Quelle ein. Eine neue Version macht jeden Vertrag, der von der Quelle abhängt, stale.

Eine Antwort, die kein Wert ist, den das Schema aufnehmen kann, etwa ein Label, das nicht in seiner Liste steht, ein Zahlenfeld, das keine Zahl ist, oder eine Liste bei einem Eine-aus-N-Schema, wird als Fehler gespeichert und nie als Label, und die Meldung des Laufs zählt diese Fehler. Ein Item, dessen Aufrufe scheitern, wird in späteren Läufen erneut angefragt, höchstens dreimal pro Quellversion, und danach wartet es auf eine geänderte Quelle (ein korrigierter Schlüssel oder Prompt ist eine neue Version). Ein Lauf, in dem eine Quelle scheitert, hält die anderen Stufen nicht an. Die nächste Stufe labelt jedes Item, und potato label run endet mit Status 1 und nennt die gescheiterte Quelle.

Konfidenzmethoden

Die Akzeptanzregeln der Engine setzen Schwellenwerte auf die Konfidenz jeder Vorhersage. Wie eine Quelle ihre Konfidenz angibt, entscheidet daher, wie viel die Engine akzeptieren kann. confidence.method nimmt einen von fünf Werten an:

Optionen je nach Art

Fünf Quellarten lesen eigene Optionen:

• decision umfasst Laya im Prozess oder jeden /v1/systemone-Server, etwa gehostetes Jev oder OpenJev. Ein einziger Forward Pass liefert eine Wahrscheinlichkeit für jede Option, und es funktioniert mit radio-, select-, likert- und slider-Schemata. endpoint_type muss laya oder systemone sein, und systemone braucht base_url, die Wurzel des Servers (eine URL, die auf /v1/systemone endet, wird ebenfalls akzeptiert). Der Zustand wird in beiden Fällen als {"text": ...} gesendet, sodass ein Checkpoint im Prozess und hinter laya-serve dieselben Antworten gibt, und options: {state_key: ""} sendet stattdessen den bloßen String. Auf Bewertungsskalen (likert, slider) folgen die Werte von Laya der Skala kaum, prüfen Sie deshalb einige Items, bevor Sie sich darauf verlassen. Der Endpunkt laya im Prozess benötigt pip install 'potato-annotation[decision]'.
• detector liest Begrenzungsrahmen eines Objektdetektors auf image_annotation-Schemata. keep_threshold (0,35) legt den Score fest, ab dem ein Rahmen zur Vorhersage gehört. Rahmen zwischen candidate_threshold (0,05) und keep_threshold senken die Konfidenz des Bildes. label_map ordnet Detektorklassen den Labels des Schemas zu, und nicht zugeordnete Klassen werden ignoriert. image_field nennt das Item-Feld mit dem Bildpfad oder der URL. Pfade werden so aufgelöst, wie die Annotationsseite sie auflöst, mit /media/x.jpg unter dem media_directory der Aufgabe und einem relativen Pfad unter task_dir.
• judge nimmt rubric (standardmäßig die Beschreibung des Schemas), fields (die Item-Felder, die dem Judge gezeigt werden, in Reihenfolge) und swap_order, das zweimal mit umgekehrter Label-Reihenfolge fragt und ein Urteil, das dabei kippt, in eine Enthaltung verwandelt. Auf Agenten-Trace-Schemata (process_reward, trajectory_eval, ...) labelt der Judge jeden Schritt.
• vlm verwendet einen Vision-Endpunkt (openai_vision, anthropic_vision, ollama_vision). Für ein selbst gehostetes Modell hinter einem OpenAI-kompatiblen Server verwenden Sie openai_vision mit base_url.
• trained nimmt artifact_dir, trainer (standardmäßig sklearn-text) und run_id. Diese Quelle entsteht meist durch Destillation und nicht durch eine von Hand geschriebene Konfiguration.

humans

Der Block humans legt fest, wer labelt und wie die Engine Stichproben zieht:

crowd

Der Block crowd gilt, wenn crowd in humans.pools steht, und Prolific ist die einzige Crowd-Plattform, die die Engine steuern kann:

Die Rekrutierung über die Crowd ist standardmäßig ein Probelauf, und der Planer berichtet, was er tun würde. Um Geld auszugeben, braucht es features.crowd_live_spend: true und eine Obergrenze budgets.human_usd, und eine Konfiguration, die echte Ausgaben ohne diese Obergrenze einschaltet, wird abgelehnt. Wie Sie die Prolific-Studie selbst einrichten, beschreibt Crowdsourcing.

budgets

Der Block budgets stoppt Ausgaben, bevor eine Grenze überschritten wird:

runtime

Der Block runtime steuert Batching, Parallelität und wie lange eine Person eine Anfrage halten darf:

features

Jedes Feature ist standardmäßig aus, außer drift:

redaction

redaction.categories listet, welche von email, url, ip, card, ssn, phone und handle maskiert werden, und umfasst standardmäßig alle. Die Maskierung greift nur mit features.pii_redaction und nur bei APIs von Drittanbietern. Selbst gehostete Endpunkttypen (vllm, ollama, laya, yolo, ...) werden nicht maskiert, egal wo sie laufen, und ebenso wenig ein Endpunkt, dessen base_url auf demselben Rechner liegt.

distill

Mit features.distill trainiert die Engine ein günstiges Modell auf den Labels der Studie und setzt es an die erste Stelle der Kaskade:

Items aus den cert- und Audit-Splits kommen nie ins Trainingsset, sodass das destillierte Modell nie auf Labels getestet wird, mit denen es trainiert wurde.

Validierung

potato validate config.yaml prüft den Block labeling_engine zusammen mit dem Rest der Konfiguration, und jeder Fehler nennt seinen Schlüssel, zum Beispiel labeling_engine.sources[1].kind must be one of ... oder labeling_engine.contracts[0].error is required for selective_risk. Die Validierung lehnt außerdem ab:

• einen Vertragsschlüssel, den die Vertragsart nicht liest, etwa einen Tippfehler in error;
• einen Vertrag auf einem Schema, das keine Quelle der Kaskade labeln kann, mit dem Grund für jede Quelle;
• einen Vertrag auf einem Schema, das die Engine nicht bewerten kann (Freitext, paarweise);
• eine decision-Quelle, deren endpoint_type kein Entscheidungsmodell ist, und eine llm-, vlm- oder judge-Quelle, deren endpoint_type eines ist; und
• no_worse_than_human mit humans.overlap_k unter 3.

Die Validierung warnt außerdem, wenn budgets.human_labels zu klein ist, um einen selective_risk-Vertrag zu zertifizieren, selbst wenn jede Maschinenantwort richtig wäre. Erhöhen Sie das Budget oder lockern Sie error, bis diese Warnung verschwindet.

Weiterführende Lektüre

• Die Labeling-Engine
• Verträge der Labeling-Engine
• Kommandozeile, REST API, MCP-Tools und SDK
• AI-Unterstützung, zu den Endpunkttypen, die Quellen mit dem Rest von Potato teilen

Implementierungsdetails stehen in der Quelldokumentation.