Skip to content
Guides6 min read

Entscheidungsmodelle als günstige erste Labeling-Stufe

Ein Entscheidungsmodell bewertet jede Option in einem Forward Pass, ohne Text zu schreiben. Bei Fragen mit wenigen Optionen dient es als erste Stufe vor einem LLM.

Potato Team

Ein Entscheidungsmodell labelt eine Frage mit fester Auswahl in einem einzigen Forward Pass und gibt für jede Option eine Wahrscheinlichkeit zurück, ohne Text zu generieren. Setzen Sie es als erste Stufe einer Labeling-Kaskade bei Fragen mit einer Wahl aus N und einer Handvoll Optionen ein, schicken Sie die Items, bei denen es unsicher ist, an ein LLM und zertifizieren Sie seinen Schwellenwert an einer verblindeten menschlichen Stichprobe, denn seine Konfidenz kann auch bei Eingaben hoch bleiben, bei denen es falschliegt.

Ein Entscheidungsmodell ist ein Klassifikator, der ein Stück Text und eine Menge typisierter Fragen entgegennimmt und für jede Antwort eine Wahrscheinlichkeit zurückgibt. Er generiert keinen Text und kann daher weder einen Prompt noch eine Begründung noch eine Regel schreiben. Laya ist ein offenes Modell dieser Art. Seine Model Card nennt einen englischen Checkpoint auf einem ModernBERT-large-Encoder mit 421M Parametern unter der Lizenz Apache 2.0 und einen mehrsprachigen Checkpoint mit 322M Parametern. Die API /v1/systemone liefert dieselbe Art von Antwort über HTTP, von gehostetem Jev, von OpenJev oder von Layas eigenem Server.

Wo eine erste Stufe Geld spart

Eine Labeling-Kaskade probiert Modelle der Reihe nach aus, meist vom günstigsten bis zum leistungsfähigsten, und reicht ein Item nur weiter, wenn das aktuelle Modell nicht sicher genug ist. Hat ein Korpus einen großen Anteil leichter Items, hinterlässt ein günstiges Modell, das diese sicher labelt, dem LLM einen kleineren, schwierigeren Rest. Die Ersparnis hängt von diesem Anteil ab. Messen Sie ihn deshalb an Ihren eigenen Daten, bevor Sie damit planen.

Ein Entscheidungsmodell eignet sich für die erste Stufe, weil es jede Option in einem Durchgang beantwortet: Eine Frage mit fünf Labels kostet einen Forward Pass und keinen generierten Text. Seine Ausgabewahrscheinlichkeiten sind der Konfidenzwert, daher braucht es weder eine Nachfrage noch wiederholtes Sampling. Außerdem läuft es auf einer CPU. Die Model Card nennt 193 bis 464 ms pro Anfrage auf der CPU mit vorab geladenen Checkpoints und 39,5 ms für den englischen Checkpoint auf einer T4-GPU.

Bekannte Grenzen von Laya

Vier dieser Grenzen stammen aus der Model Card von Laya, die fünfte, zu Bewertungsskalen, aus Potatos Dokumentation:

  • Viele Optionen. Auf dem Intent-Benchmark Banking77 nennt die Card für Laya eine Genauigkeit von 0,425 bei 77 Labels, gegenüber 0,870 für Jev bei 72. Die Optionen teilen sich ein festes Token-Budget, sodass sich lange Labellisten gegenseitig verdrängen. Potatos Dokumentation merkt außerdem an, dass Laya bei Fragen mit 11 oder mehr Optionen warnt, seine Temperatur liege außerhalb des zulässigen Bereichs, und sie begrenzt.
  • Andere Schriften auf dem englischen Checkpoint. Die Card nennt für den englischen Checkpoint auf Khmer-Text eine Genauigkeit von 0,000 bei einer Konfidenz von 0,952. Ein Konfidenzschwellenwert kann keinen Fehler abfangen, bei dem sich das Modell sicher ist.
  • Zero-shot-Genauigkeit. Laut Card liegen die Basis-Checkpoints auf ihrem Benchmark für typisierte Entscheidungen im Zero-shot-Betrieb nahe am Zufall, bei 0,362 gegenüber einer Zufallsbasis von 0,318 und einer Mehrheitsklassenbasis von 0,461, und sie nennt Laya „eine schnelle Basis zum Spezialisieren, keine Zero-shot-Entscheidungsmaschine“.
  • Rohe Kalibrierung. Laut Card wird laya überkonfident ausgeliefert, mit einem mittleren erwarteten Kalibrierungsfehler von 0,466, der nach dem Neuanpassen der Temperaturen an Ihren eigenen Daten auf 0,081 sinkt. Die Kalibrierung variiert je nach Domäne, daher lässt sich ein Schwellenwert, der an den Daten anderer gewählt wurde, nicht übertragen.
  • Bewertungsskalen. Potatos Dokumentation stellt fest, dass die Werte von Laya bei likert- und slider-Schemata der Skala kaum folgen können, wie auch immer die Frage formuliert ist.

Zusammengenommen sprechen diese Grenzen dafür, das Entscheidungsmodell bei Fragen mit einer Wahl aus N und wenigen Optionen einzusetzen, in der Sprache, für die sein Checkpoint trainiert wurde. Wählen Sie seinen Schwellenwert anhand menschlicher Labels auf Ihrem eigenen Korpus.

Ein Entscheidungsmodell in Potato

Potato 2.11 bringt zwei Endpunkttypen für Entscheidungsmodelle. laya führt Laya im Potato-Prozess aus und braucht das Extra decision, pip install 'potato-annotation[decision]', das torch und transformers mitinstalliert. systemone spricht mit jedem Server, der die API /v1/systemone anbietet, und braucht nur eine base_url. Beide funktionieren mit radio-, select-, likert- und slider-Schemata, und Solo Mode startet nicht, wenn eines davon ein multiselect-, Span- oder Freitext-Schema labeln soll.

In der Labeling-Engine ist ein Entscheidungsmodell eine decision-Quelle, die zuerst in der Kaskade steht. Dieser Ausschnitt aus dem Textbeispiel, das mit Potato ausgeliefert wird, stellt Laya vor ein kleines Ollama-LLM und zertifiziert das Paar gegen ein Fehlerziel von 10 % bei Potatos Standardkonfidenz von 90 %:

yaml
labeling_engine:
  enabled: true
  sources:
    - id: laya
      kind: decision
      endpoint_type: laya
      model: convaiinnovations/laya
      options:
        device: cpu
    - id: llm
      kind: llm
      endpoint_type: ollama
      model: llama3.2:3b
      base_url: http://localhost:11434
      max_tokens: 200
  cascade: [laya, llm]
  contracts:
    - id: accuracy
      kind: selective_risk
      schema: sentiment
      error: 0.1
      confidence: 0.9

Die Engine wählt den Konfidenzschwellenwert für Laya an der einen Hälfte einer verblindeten menschlichen Stichprobe und testet ihn an der anderen, sodass der Schwellenwert aus Ihrem Korpus stammt und nicht aus der Model Card. Bis die dev-Hälfte der Stichprobe einen Schwellenwert für Laya festlegt, labelt das LLM jedes Item. Danach sieht das LLM nur noch die Items, bei denen sich Laya nicht sicher ist, und die Kalibrierungsstichprobe.

In dem Lauf, den die README des Beispiels dokumentiert, mit Gemma 12B als LLM, wurde für Laya nie ein Schwellenwert festgelegt, und das LLM lieferte alle akzeptierten Labels. Messen Sie also an Ihrem eigenen Korpus, was die erste Stufe beiträgt, bevor Sie darauf zählen. Weil die Engine die akzeptierten Labels jeder Stufe getrennt testet, zeigt sich ein sicherer Fehlgriff wie im Khmer-Fall als Fehler in der Zertifizierungsstichprobe, sofern die Stichprobe diese Art von Eingabe abdeckt. Der Vertrag distributional kann außerdem den vollständigen Wahrscheinlichkeitsvektor von Laya verwenden, was zu subjektiven Fragen passt, bei denen sich Annotierende aufteilen.

In Solo Mode steht ein Entscheidungsmodell in labeling_models und als erste Stufe von confidence_routing. Solo Mode braucht außerdem ein generatives Modell unter revision_models, weil Entscheidungsmodelle die Prompts und Regeln nicht schreiben können, die seine Revisionsschleife erzeugt.

Ein Entscheidungsmodell vor einem vollständigen Lauf testen

Lassen Sie das Modell auf ein paar Dutzend Items laufen, die Sie bereits gelabelt haben, bevor Sie ein ganzes Korpus hindurchleiten. Die Schaltfläche Try on 10 items in Solo Mode tut das für einen Prompt, und in der Engine zeigt potato label run, gefolgt von potato label status, wie viele Labels der Schwellenwert jeder Stufe noch braucht und welche Quelle Fehler erzeugt hat. Eine Stufe, die bei der Zertifizierung durchfällt, akzeptiert nichts und schickt die Items oberhalb ihres Schwellenwerts an Menschen statt an das LLM. Das verbraucht das Budget für menschliche Labels an Items, die das LLM vielleicht hätte labeln können. Wenn die Stufe des Entscheidungsmodells immer wieder bei der Zertifizierung durchfällt, nehmen Sie sie aus der Kaskade.

Weiterführende Lektüre