Hugging Face schlägt eine gemeinsame Schnittstelle für Entscheidungsmodelle vor: Transformers erhält DecisionPipeline und einen Endpunkt /v1/systemone, llama.cpp bedient dieselbe API, und drei Primitive (choice, score, noul) liefern Wahrscheinlichkeiten; der Beitrag berichtet keinen Benchmark zu Genauigkeit, Kalibrierung oder Latenz, und seine Rechenbeispiele sind nicht ganz stimmig

Am 10. November 2026 hat Hugging Face „Decision Models in Hugging Face“ veröffentlicht, einen langen Beitrag von Aritra Roy Gosthipaty, Lysandre, Pedro Cuenca und Tom Aarsen. Er beschreibt eine gemeinsame Schnittstelle für eine Art von Modell, das keinen Text schreibt. Ein Entscheidungsmodell liest einen Zustand, etwa eine Kundennachricht, sowie eine Menge typisierter Fragen mit erlaubten Antworten und gibt strukturierte Entscheidungen mit Wahrscheinlichkeiten zurück. Laut Beitrag weist das Modell Antworten, die die Anwendung schon versteht, Wahrscheinlichkeiten zu, statt Token für Token zu erzeugen. Die Schnittstelle wird so geschrieben: „State + Questions + Allowed Answers → Decisions + Probabilities“. Der Beitrag sagt, TypeSafe AI habe die Idee unter dem Namen Jev eingeführt und als „System-One-Modell“ bezeichnet, und die Community habe sich seither auf „Decision Model“ geeinigt, weil der Begriff die Rolle des Modells beschreibt und keine Theorie des Denkens.

Das Ausgangsbeispiel ist eine Support-Nachricht: „Mir wurde mein Abo doppelt berechnet. Ich brauche heute eine Rückerstattung.“ Eine Anwendung will daraus drei Dinge: welches Team zuständig ist, wie dringlich es ist und ob der Kunde eine Rückerstattung verlangt. Der Beitrag zeigt zunächst ein Sprachmodell, das JSON mit diesen Antworten schreibt, und plädiert dann für die Alternative. Er nennt drei Probleme, wenn man ein Sprachmodell um strukturierte Ausgabe bittet. Das Modell hält das verlangte Schema nicht garantiert ein, es kann ungültiges JSON, unerwartete Schlüssel oder eine Antwort außerhalb der erlaubten Auswahl liefern. Bibliotheken für eingeschränktes Dekodieren wie Outlines und XGrammar erzwingen eine Grammatik, bringen aber eigenen Aufwand mit. Und eine ganze Antwort zu erzeugen ist unnötige Arbeit, wenn die Anwendung nur zwischen festen Antworten wählen muss. Der Beitrag liefert keinen gemessenen Vergleich von Geschwindigkeit, Kosten oder Genauigkeit für diese Punkte, es sind also Argumente und keine Ergebnisse.

Eine Frage hat einen von drei Typen, Primitive genannt. Eine Auswahlfrage (choice) wählt eine von mehreren Antworten und gibt für jede eine Wahrscheinlichkeit zurück. Eine Bewertungsfrage (score) bewertet etwas auf einer geordneten Skala und gibt den Erwartungswert des Stufenindex zurück. Ein dritter Typ, nach der Bernoulli-Verteilung „noul“ genannt, beantwortet eine Ja/Nein-Frage mit der Wahrscheinlichkeit, dass die Aussage wahr ist. Bei Auswahl- und Bewertungsfragen enthält das Ergebnis außerdem ein Feld für das Vertrauen (confidence). Bei einer Auswahl mit K Optionen ist das Vertrauen die größte Wahrscheinlichkeit minus 1/K, geteilt durch 1 minus 1/K; eine Gleichverteilung ergibt 0, eine vollständig konzentrierte 1. Im Beispiel des Beitrags liefert die Abteilungsfrage „billing“ mit Wahrscheinlichkeit 0,998 und Vertrauen 0,997. Der Dringlichkeitswert beträgt 1,705 bei Vertrauen 0,558, was der Beitrag als Erwartungswert über die Verteilung erklärt und nicht als Stufe auf halbem Weg zwischen mittel und hoch.

Der Beitrag vergleicht Entscheidungsmodelle mit zwei älteren Ansätzen. Ein klassischer Klassifikator hat seine Ausgabeklassen im Klassifikationskopf festgelegt; eine vierte Abteilung wie Recht kann neue Daten und neues Training erfordern. Zero-Shot-Klassifikation liefert die Labels erst zur Inferenzzeit, und der Beitrag zeigt ein Modell, das Werte für Abrechnung, technischen Support, Vertrieb und nach einer Änderung auch Recht zurückgibt. Der Beitrag sagt, der Vorteil von Entscheidungsmodellen liege nicht darin, Laufzeit-Labels oder Wahrscheinlichkeiten erfunden zu haben. Er liege darin, sie in einer Schnittstelle zu bündeln, mit mehreren typisierten Fragen zum selben Zustand sowie nativer geordneter Bewertung und Ja/Nein-Entscheidungen. In der eigenen Tabelle des Beitrags liefert Klassifikation Wahrscheinlichkeiten über Auswahlmöglichkeiten, kann aber Labels nicht zur Inferenzzeit festlegen, und nur Entscheidungsmodelle haben mehrere typisierte Fragen.

Was die Werkzeuge verändert, ist die Unterstützung im Hugging-Face-Stack. Transformers hat jetzt eine DecisionPipeline, eine Klasse AutoModelForDecision und eine Klasse DecisionConfig. „transformers serve“ stellt mit einer kompatiblen Transformers-Version einen Endpunkt /v1/systemone bereit, und der Beitrag zeigt eine Anfrage mit drei Fragen, die drei typisierte Antworten liefert, bei einer Nutzung von 148 Eingabe-Token und 0 Ausgabe-Token. llama.cpp bedient Entscheidungsmodelle über dieselbe API: Das Beispiel startet „llama serve -hf ggml-org/Kev-4B-GGUF“, dessen Standard-Serverport 9931 ist. Der Beitrag ergänzt, die Schnittstelle funktioniere auch mit kompatiblen autoregressiven Sprachmodellen. Transformers baut die Entscheidungs-Prompts, liest die Logits der Antwortlabels in einem gebündelten Vorwärtsdurchlauf und wendet Softmax an, ohne Text zu erzeugen; Entwickler können die Schnittstelle also ausprobieren, ohne ein neues Modell zu trainieren.

Zu Auffindbarkeit und Training: Der Hub hat ein neues Tag „decision-model“. Laut Beitrag müssen Entscheidungsmodelle kein gemeinsames Grundgerüst teilen: Einige basieren auf Encodern wie ModernBERT, andere auf größeren generativen Sprachmodellen. Zum Training lassen sich Entscheidungsmodelle mit der Trainer-API feinabstimmen. Der Beitrag gibt ein bewusst kleines Beispiel, das autotrust/JEV-9B auf sechs Support-Nachrichten 30 Schritte lang mit einer Lernrate von 1e-3 feinabstimmt, mit schlichter Kreuzentropie über die Optionen bei einer Auswahlfrage. Er sagt, erstklassige Trainingsunterstützung in TRL komme, und der zugehörige Pull Request huggingface/trl#8040 sei beim Schreiben noch offen gewesen. Außerdem verweist er auf ein Unsloth-Rezept, das Modelle wie Qwen mit LoRA und einem Entscheidungs-Bewertungskopf feinabstimmt.

Der Beitrag hat Grenzen, die der Leser im Blick behalten sollte. Sein Text berichtet für kein benanntes Entscheidungsmodell einen Benchmark zu Genauigkeit, Kalibrierung oder Latenz; „verlässliche, kalibrierte Entscheidungen“ sind also ein genanntes Ziel und kein Befund. Bilder und Seiten, auf die der Beitrag verlinkt, hat dieser Bericht nicht geöffnet. Seine Rechenbeispiele sind nicht ganz stimmig: Eine Tabelle zeigt Dringlichkeitswahrscheinlichkeiten von 0,10, 0,26 und 0,72, die zusammen 1,08 ergeben, sodass die Tabelle keine gültige Wahrscheinlichkeitsverteilung ist, während die ausgegebene Antwort 0,0149, 0,2648 und 0,7203 zeigt. Ein Satz nennt eine Gewinnwahrscheinlichkeit von 0,80, bevor mit 0,99 gerechnet wird; bei drei Optionen ergibt die Formel 0,70 für 0,80 und 0,985 für 0,99, und der Beitrag druckt 0,98. Zwei ausgegebene Werte lassen sich aus den ausgegebenen Wahrscheinlichkeiten nachrechnen: die Konfidenz der choice-Frage, (0,99827 − 1/3) / (1 − 1/3) ≈ 0,9974, und der Erwartungswert der score-Frage, 0 × 0,0149 + 1 × 0,2648 + 2 × 0,7203 ≈ 1,705; beide stimmen mit der Ausgabe überein. Für die Konfidenz der score-Frage nennt der Beitrag keine Formel; die oben genannten 0,558 sind sein gemeldeter Wert, den dieser Bericht nicht geprüft hat. Die Zahlen in Tabelle und Fließtext sollte man als Veranschaulichung lesen. Die genannten Modelle autotrust/GEV-26B-Decide, ggml-org/Kev-4B-GGUF und autotrust/JEV-9B wurden für diesen Bericht nicht getestet, und der Beitrag nennt außer den Namen weder Lizenzen noch Eckdaten.

Für ein Team, das heute Tickets verteilt, Risiken bewertet oder Inhalte filtert, und zwar mit einem Sprachmodell, das JSON schreibt, ist die praktische Frage eng. Passt ein Modell, das Wahrscheinlichkeiten für feste Antworten liefert, zur Entscheidung, und gibt es einen Checkpoint, der für Ihre Sprache und Ihr Gebiet gut genug ist? Der Beitrag bietet eine gemeinsame API, einen Weg, sie an einem gewöhnlichen Sprachmodell auszuprobieren, und ein kleines Trainingsrezept. Einen Beleg, dass ein Entscheidungsmodell den heutigen Ansatz schlägt, bietet er nicht. Diesen Vergleich muss das Team mit den eigenen Daten durchführen.