Decision Models vs. LLM-as-a-Judge: Jev, OpenAIs Decisions API und wer die Wahrscheinlichkeit kalibriert

Ein Decision Model ist ein Sprachmodell, dem das Schreiben verboten wurde. Du gibst ihm ein Dokument und eine typisierte Frage, und es liefert eine typisierte Antwort: die Wahrscheinlichkeit, dass eine Aussage stimmt, eine Verteilung über die Optionen, die du aufgelistet hast, oder eine Position auf einer Skala, die du definiert hast. Es gibt keine freie Prosa zum Parsen, falsch sein kann die Antwort trotzdem. Am 6. Oktober hat OpenAI so ein Modell als eigenen Endpoint veröffentlicht, die Decisions API, mit genau einem Modell namens gpt-6-luna. Es reiht sich ein neben Jev von TypeSafe AI, das im September gestartet ist, und zwei Open-Weight-Modellen: Laya von Convai Innovations und Strands Decider 2B von AWS Strands Labs.

Die Anbieter verkaufen Geschwindigkeit und Preis, und beides ist real. Mich interessiert aber die Zahl, die an jeder Antwort hängt. Eine Wahrscheinlichkeit sieht aus wie etwas, worauf Software direkt reagieren kann: routen ab 0,8, blocken ab 0,95. Bevor ich Code bei 0,8 verzweigen lasse, will ich wissen, wer geprüft hat, dass 0,8 wirklich acht von zehn bedeutet. Wer die Dokumentation der vier Anbieter bis zum Ende liest, bekommt überall dieselbe Antwort, auch bei dem Anbieter, dessen Produkt Kalibrierung ist: du selbst.

Was ist ein Decision Model, und wie unterscheiden sich Jev, Laya, Strands Decider und OpenAIs Decisions API?

Ein Decision Model nimmt unstrukturierten Input plus eine oder mehrere typisierte Fragen und liefert typisierte Entscheidungen mit numerischen Scores. Die vier Modelle hier teilen drei Primitive: ein Ja/Nein-Prädikat, eine Auswahl aus mehreren Optionen und einen ordinalen Score. Sie unterscheiden sich bei Gewichten, Input-Typen und Preis.

OpenAIs Guide sagt, die API liefere typisierte Antworten „about 10x faster than the Responses API“, eine Herstellerzahl ohne veröffentlichte Methode. Der Guide sagt auch, wann man sie nicht nehmen soll: Structured Outputs, um ein eigenes JSON-Schema zu erzeugen, Function Calling für Tool-Aufrufe. TypeSafes Launch-Post benennt den Tausch offen: Jev „gives up string generation“. Strands Decider ist ein Qwen3.5-2B, dessen textgenerierender Head entfernt wurde und durch einen Pointer-Head mit rund einer Million Parametern ersetzt ist, der die mitgegebenen Optionen bewertet.

Wofür taugen Decision Models? Sieben Muster der Anbieter, geprüft an Red Hats Benchmark

Das sind die Einsatzfälle, die die Anbieter selbst nennen. Red Hats vergleichender Benchmark betrifft drei davon, der Rest sind berichtete Muster. Wo eine Aussage vom Anbieter stammt, sage ich das.

Kann ein Decision Model ein if-Statement im Workflow ersetzen?

Ja, und genau damit eröffnet TypeSafe: „smart if-statements“ und das Map-Reduce einer Frage über einen großen Datensatz. Bei 0,042 $ pro Million Input-Tokens und kostenlosem Output kostet eine Ja/Nein-Frage über eine Million Tokens Support-Tickets etwa vier Cent, und die Antwort kommt als Zahl, auf die dein Code verzweigen kann. Bodenhaftung bekommt das Versprechen durch Jevs eigene Schwächenseite: Arithmetik, Zählen, Datumsvergleiche und Hex- oder RGB-Werte stehen dort als unzuverlässig, mit dem Rat, das im Code zu erledigen. Das Decision Model beantwortet die Ermessensfrage, die Mathematik macht weiterhin dein Code.

Kann ein Decision Model in einem Agent Anfragen routen und Tools auswählen?

Die Anbieter sagen ja. Strands nennt „model routing, tool selection, evaluations, guardrails, memory, context management, and policy classification“ als Einsätze, bei denen es Erfolg gesehen hat. Das führt den Punkt weiter, den ich im August zu Worker-Modellen gemacht habe: Das Modell muss zum Platz passen. Ein Platz, an dem nur gewählt wird, braucht kein Modell, das schreiben kann. Der Haken steht in der Model Card von Strands: „With the state and options fixed, a changed question often gets the same answer.“ Ein Router, der deine Frage ignoriert, sieht auf einem Testset, das aus einer einzigen Frage gebaut ist, gut aus. Teste ihn, indem du die Frage änderst, nicht nur den Input.

Funktioniert ein Decision Model für Content-Moderation gegen eine Policy in Klartext?

Hier fallen Red Hats Zahlen am günstigsten aus. Im Vergleich von neun Modellen auf klassenbalancierten englischen Datensätzen erreichte Jev bei Content Safety mit 86,2 % den Bestwert, vor Qwen3.6-35B als Judge mit 85,5 % und IBMs Granite-Guardian-HAP-Klassifikator mit 125M Parametern bei 80,3 %. Das Granite-Modell antwortete im Median in 33 ms, Jev in 360 ms, und in Jevs Wert steckt ein Netzwerk-Roundtrip, den die lokalen Modelle nicht hatten (die Autoren beziffern ihn auf mindestens etwa 56 ms). TechCrunch berichtet von einem auf Moderation spezialisierten Neuzugang, Musubis Open-Weight-Modell PolicyLM-1.7B, beworben mit Policies, die in Klartext geschrieben sind und sich ohne Neutraining ändern lassen. Miss dieses Versprechen am Abschnitt zur Policy weiter unten.

Ist ein Decision Model ein guter Prompt-Injection-Filter?

Als Filter ist es konkurrenzfähig, aber nicht der beste. Auf Red Hats Prompt-Injection-Set lag Qwen3.6-35B als Judge mit 89,3 % vorn, Protect AIs DeBERTa-v3-Klassifikator mit 200M Parametern, trainiert auf Prompt Injection, kam auf 89,0 % (54 ms Median laut Übersichtstabelle, eine Tabelle im Anhang nennt 80 ms), und Jev auf 86,4 % bei 348 ms Median. Die tiefere Grenze dokumentiert TypeSafe selbst:

State is data, and jev-1.13 does not treat it as hostile by default.
Content written to adversarially steer the model, whether that is an
injected instruction, a deliberately misleading framing, or text that
argues for its own classification, can move the answer.

Das ist ehrlich vom Anbieter, und es ist seine eigene Fassung des Arguments aus Your approval gate is a guess now: Ein Modell, das nach Ähnlichkeit urteilt, kann ranken und filtern, aber nicht die Grenze sein. Ein Decision Model ist dieselbe Vermutung mit einer saubereren API. Auf einen Float lässt sich leichter ein Schwellenwert setzen als auf einen Absatz, es bleibt aber ein Urteil über Bedeutung, und Bedeutung liegt auf der Seite der Linie, auf der kein Detektor die Lücke schließt. Nutz es, um zu sortieren, was bei einem Menschen landet. Die Aktionen sicherst du über das ab, was der Harness erlaubt.

Kann ein Decision Model LLM-as-a-Judge für Evals und Bewertungen ersetzen?

Teilweise. Das Score-Primitiv ist für Rubrik-Bewertungen gebaut, und Strands führt Evaluations unter seinen Einsätzen. Die Fehlerbilder sind aber die bekannten, nur leiser. Laut Jevs Dokumentation neigt es bei einer Auswahl zur ersten Option („leans toward the option that comes first“), und sie empfiehlt, die Optionen umzustellen, um zu prüfen, ob die Antwort hält. Laut Layas Card kann sich das Ja/Nein-Primitiv nach den Optionslabels statt nach dem State richten („can follow its option labels instead of the state“), und ordinale Scores sind sein schwächstes Primitiv. Ein Judge, der einen Absatz schreibt, liefert wenigstens eine Begründung, die man prüfen kann, auch wenn sie nicht garantiert der Grund für die Entscheidung ist. Ein Decision Model liefert nichts zum Prüfen. Simon Willison schrieb über Jev: „the only thing you’re going to get back is a floating point number.“ Für einen Eval, den du auditieren willst, ist das ein Kostenfaktor, kein Feature.

Kann ein Decision Model Bilder triagieren?

Von diesen vier kann es nur das von OpenAI. gpt-6-luna nimmt Bilder als Inline-Base64 an (gehostete URLs und File-IDs werden nicht unterstützt), und unter den Beispielen im Guide ist Schadenserkennung. Simon Willisons Plugin-Post zeigt, wie eine Antwort aussieht, auf ein Pelikanfoto mit der Frage, ob darauf Säugetiere zu sehen sind:

{"type": "predicate", "name": "evaluation", "probability": 0.0}

Eine saubere Null bei einer leichten Frage ist die Demo. Ob 0,3 bei einem schwierigen Foto eine Chance von 30 % bedeutet, ist die Frage, um die es im Rest dieses Texts geht.

Solltest du ein offenes Decision Model feinjustieren, statt eine API aufzurufen?

Wenn du Labels hast, sind die offenen Modelle genau dafür gebaut. Layas Model Card ist ungewöhnlich direkt: „Laya is a fast base to specialise, not a zero-shot decision engine.“ Der Basis-Checkpoint erreicht auf dem eigenen Typed-Decisions-Benchmark 0,362, unter der Majority-Class-Baseline von 0,461; die auf dem Trainings-Split dieses Benchmarks feinjustierte Version kommt auf 0,766. Red Hat hat Laya mit einem Policy-Prompt betrieben statt feinjustiert, und bei Content Safety landete es mit 57,9 % auf dem letzten Platz. Das sind verschiedene Aufgaben und verschiedene Setups, also lies sie nebeneinander, nicht als Urteil. Strands hat seine Trainingsskripte veröffentlicht, und laut Model Card dauert das komplette Rezept für ein Neutraining etwa 70 Minuten auf acht H100.

Kann man auf die Wahrscheinlichkeit eines Decision Models einen Schwellenwert setzen?

Nicht auf das Wort des Anbieters hin. Jeder Anbieter der Kategorie sagt dir, du sollst auf deinen eigenen Daten validieren, bevor du auf die Zahl reagierst, und zwei gehen weiter und sagen, du sollst die Wahrscheinlichkeiten selbst neu fitten. Lies ihre Aussagen der Reihe nach, vom größten Versprechen zum kleinsten.

TypeSafe verkauft Kalibrierung als Kern des Produkts, trainiert mit einer Methode, die es Reinforcement Learning for Calibrated Decisions nennt:

Always communicates confidence and uncertainty with every output.
Calibrated: higher confidence means higher accuracy.

Weder Launch-Post noch Schwächenseite nennen eine Kalibrierungsfehler-Kennzahl dazu, und der Rat der Schwächenseite lautet, die eigene Integration gründlich zu testen, bevor man sie ausrollt. Strands hat seine Kalibrierung auf einer Art von Daten gefittet und sagt das auch:

Calibration is one temperature per primitive, fitted on held-out short
classification. The confidence bands are established there only:
measure on your own traffic before you trust a threshold.

Laya veröffentlicht die Zahlen, und deshalb ist seine Card die nützlichste der vier:

Ships over-confident: Refitting one temperature per (question type,
option count) moves mean ECE 0.466 → 0.081 (laya) and 0.314 → 0.106
(laya-multilingual). Do this on your own data before trusting the
probabilities.

Dieselbe Card sagt, Layas Act/Escalate-Wahrscheinlichkeit „carries no usable signal yet“: Sie zeigt bei fast jedem Input 1,0, und ihr Rohsignal läuft gegen die Korrektheit (AUROC 0,30 auf 396 gelabelten Entscheidungen). Ausgerechnet das Feld, das nach genau der Entscheidung benannt ist, die du automatisieren willst, solltest du ignorieren.

Die Card gibt außerdem einen Bericht von Dritten wieder, keine eigene Messung der Autoren: Jev habe bei 16 % der DAIR-Emotion-Beispiele dem richtigen Label eine Wahrscheinlichkeit von null gegeben. Ein kalibriertes Modell darf sich irren; eine Null erklärt das richtige Label für ausgeschlossen.

OpenAI sagt am wenigsten. Der Guide definiert nirgends, wie das separate Feld confidence berechnet wird, und der Rat zu Schwellenwerten ist knapp:

Use labeled examples from your application to set thresholds for
routing, filtering, or review.

In diesen Zitaten stecken drei verschiedene Anweisungen, und es hilft, sie auseinanderzuhalten. Validierung sagt dir, wie oft das Modell auf deinem Traffic richtig liegt. Kalibrierung ändert, was ein Score bedeutet, sodass 0,8 wirklich acht von zehn ist. Ein Schwellenwert legt fest, was du bei einem Score tust, und ein brauchbarer braucht keine perfekte Kalibrierung, nur genug gelabelte Beispiele, um zu sehen, was dich jeder Cutoff kostet. Alle drei brauchen dasselbe Rohmaterial. Auch ein Decision Model braucht gelabelte Daten, nur zum Zeitpunkt des Schwellenwerts statt zum Zeitpunkt des Trainings. Eine Temperatur neu zu fitten ist ein viel kleineres Schätzproblem als einen Klassifikator zu trainieren, also braucht es weniger Labels, aber ab dem ersten Tag, und sie müssen deinem Traffic ähneln. Was du dafür bekommst: eine brauchbare erste Antwort, bevor du irgendetwas trainiert hast, und eine Policy, die du durch Bearbeiten von Text ändern kannst.

Ist der Policy-Text wichtiger als das Decision Model?

In Red Hats Setup hat die Policy die Genauigkeit stärker verschoben als der Abstand zwischen den meisten Modellen, also behandle eine Policy-Änderung wie einen Modellwechsel. Die Umstrukturierung von Layas Content-Safety-Policy, aufgeteilt in einzelne Ja/Nein-Fragen pro Schadenskategorie und geblockt, sobald eine Antwort über 0,5 lag, hob Laya von 57,87 % auf 75,20 %, also um 17,33 Punkte, und mehr als verdoppelte die Median-Latenz, von 118 ms auf 289 ms. Dieselbe optimierte Policy kostete Jev 3,67 Punkte.

Eine Policy ist also nicht zwischen Decision Models übertragbar, und innerhalb eines Modells ist sie nicht neutral. Das ist der Haken am „ohne Neutraining“-Versprechen: Die Gewichte ändern sich nicht, die Genauigkeit aber schon, und in welche Richtung, erfährst du nur durch Messen. Wenn jemand eine Policy in Klartext bearbeiten kann, ohne auf die Eval-Zahlen zu schauen, muss das Eval-Set bei jeder Änderung laufen, so wie eine Testsuite bei jedem Commit. Noch eine Grenze desselben Benchmarks: Er ist nur auf Englisch, er erschien vier Tage, bevor die Decisions API in die Public Beta ging, und OpenAIs Modell hat er nicht getestet.

Decision Model, feinjustierter Klassifikator oder LLM-Judge: Was solltest du diese Woche wählen?

Wähl danach, was die Aufgabe mit dir macht, wenn sie danebenliegt, und bau das gelabelte Set, bevor du irgendetwas auswählst. Hier meine Lesart der bisherigen Belege.

Eine feste Aufgabe unter Beschuss, Prompt Injection oder eine bekannte Missbrauchsklasse, verlangt nach einem kleinen feinjustierten Klassifikator. In Red Hats Test kam er bis auf ein Drittel Prozentpunkt an den besten Judge heran, bei einem Bruchteil der Latenz, und sein Verhalten verschiebt sich nicht, wenn jemand einen Prompt bearbeitet. Behalte ihn als Filter, nie als Grenze.

Eine Policy, die sich oft ändert und bei der ein Fehler eine menschliche Prüfung kostet, ist der Ort, an dem ein Decision Model seinen Platz verdient. Du bearbeitest die Policy, lässt das Eval-Set laufen und lieferst die Änderung am selben Nachmittag aus, ohne Trainingslauf dazwischen.

Eine Entscheidung, die du erklären musst, ein Audit oder eine Bewertung, gegen die jemand Einspruch erheben kann, verlangt nach einem LLM-Judge oder nach einem Decision Model mit einem Judge dahinter für die strittigen Fälle. Die Begründung des Judges beweist nicht, warum er entschieden hat, aber ein nackter Float gibt der Person mit dem Einspruch nichts, worüber sie streiten kann.

Das gelabelte Set ist der Teil, der die Wahl überdauert. Es setzt den Schwellenwert des Decision Models und bewertet jeden Klassifikator oder Judge, den du dagegen ausprobierst, solange du einen Teil davon aus jedem Fitting heraushältst und die Labels überprüfst, wenn sich die Policy ändert. Diese Produkte sind wenige Wochen alt, ihre Modelle werden ersetzt werden; die Beispiele, die du aus deinem eigenen Traffic gelabelt hast, sind das eine Asset, das auf jedes Modell übergeht, das am Ende gewinnt. Die Dokumentation jedes Anbieters endet mit der Bitte darum, also bau sie zuerst.