Decision Models: Die KI, die nicht schreibt, sondern entscheidet

Ein Sprachmodell erzeugt Text, Token für Token. Ein Decision Model erzeugt gar nichts. Es bekommt einen State, also Text oder JSON, dazu eine oder mehrere Fragen mit festgelegten Antwortmöglichkeiten, und liefert für jede Frage genau eine Antwort aus dieser Liste, mit einer Wahrscheinlichkeit pro Option. Kein Fließtext, nichts zu parsen, keine Antwort außerhalb des Schemas.

TypeSafe AI, das Unternehmen des früheren OpenAI-Forschers Diogo Almeida, hat die Kategorie mit Jev benannt und drei Fragetypen definiert, die andere Implementierungen übernommen haben:

• Choice: eine Option aus bis zu 255 benannten Möglichkeiten. Zurück kommen die Wahl, eine Wahrscheinlichkeit je Option und eine Konfidenz.
• Score: eine Einstufung auf einer geordneten Skala, etwa von "ruhig" bis "sehr wütend", mit Wahrscheinlichkeit je Stufe.
• Noul: ja oder nein, als Wahrscheinlichkeit zwischen 0 und 1.

Mehrere Fragen zum selben State gehen in einem einzigen Aufruf raus. Weil dabei keine Ausgabetoken entstehen, können Dienste wie Jev nur die Eingabe abrechnen; prüf trotzdem das Preismodell des jeweiligen Anbieters. Jev antwortet laut TypeSafe in 70 bis 500 Millisekunden. Laya, ein offenes Modell mit 322 Millionen Parametern, braucht auf einer Laptop-GPU 21 Millisekunden pro Entscheidung. Für einen normalen Aufruf von GPT-6 Luna werden etwa 1,6 Sekunden genannt. Hardware und Aufgaben unterscheiden sich, die Zahlen sind also kein Vergleich unter gleichen Bedingungen.

TypeSafe nennt Jev ein "System One Model", nach Daniel Kahnemans schnellem, intuitivem Denken. Der Name geht auf den Ökonomen William Stanley Jevons zurück. Sein Paradoxon: Wird eine Ressource effizienter und damit billiger nutzbar, steigt ihr Verbrauch, statt zu sinken. Darauf wettet das Unternehmen. Wenn eine Entscheidung nur Bruchteile eines Cents kostet, treffen Anwendungen sehr viel mehr davon.

Die technische Idee ist nicht neu. Ein Klassifikator auf BERT-Basis macht seit Jahren nichts anderes, und wer ein Sprachmodell nach einem Buchstaben fragt und die Logprobs liest, bekommt ebenfalls eine Verteilung über Optionen. Neu ist die Kombination aus drei Dingen.

Erstens die Zero-Shot-Fähigkeit. Du formulierst Frage und Optionen zur Laufzeit in natürlicher Sprache und brauchst kein Trainingsset pro Aufgabe.

Zweitens die Kalibrierung. TypeSafe trainiert Jev mit einem Verfahren namens Reinforcement Learning for Calibrated Decisions. Die Wahrscheinlichkeiten werden gegen tatsächliche Ergebnisse optimiert, nicht gegen menschliche Vorlieben. Gibt das Modell einer Antwort die Wahrscheinlichkeit 0,9, soll sie bei vergleichbaren Vorhersagen in etwa neun von zehn Fällen stimmen.

Drittens der Bedarf. Structured Output hat uns schema-gültigen Text gebracht, aber keine brauchbare Konfidenz. LLM-as-a-Judge ist in Evals langsam und teuer. Und Agenten vervielfachen die kleinen Urteile pro Aufgabe: Welches Tool? Welches Modell? Ist die Aufgabe erledigt? Darf das ausgeführt werden?

Der Markt hat die Lücke sofort bestätigt. Innerhalb von 24 Stunden nutzten laut Vercel knapp 13 Prozent der zahlenden Teams im AI Gateway das Modell, doppelt so viele wie bei der GPT-5.6-Familie und sechsmal so viele wie bei Fable 5.1. TypeSafe selbst spricht von bis zu 194-fach schnelleren und 445-fach günstigeren Workflows und räumt ein, dass diese Zahlen am oberen Rand dessen liegen, was in der Praxis zu erwarten ist.

Innerhalb von vier Wochen haben AWS, Cloudflare, OpenAI und Microsoft eigene Decision Models veröffentlicht. Diese Geschichte und die Fragen der Skeptiker stehen in einem eigenen Beitrag: Decision Models: Wer was gestartet hat und was offen ist. Hier schreiben wir Code.

Symfony AI unterstützt Jev seit Version 0.14.0. Die Bridge lebt im Paket symfony/ai-type-safe-platform und ist bewusst eine Platform-Bridge, kein Agent-Modell: Jev nimmt keine Messages entgegen, ruft keine Tools auf und streamt nicht. Statt Messages schickst du eine Evaluation aus State und Fragen.

Das kanonische Beispiel ist die Ticket-Triage im Support, weil sie alle drei Fragetypen auf einem State zeigt. Die Zahlen in den Kommentaren sind beispielhaft:

Der Teil, der ein Decision Model von einem weiteren LLM-Aufruf unterscheidet, steht nicht im Prompt, sondern danach: ein Threshold in getestetem Code. Erreicht die Wahrscheinlichkeit der gewählten Option den Threshold, läuft das Ticket automatisch durch; darunter entscheidet ein Mensch. Beides wird mit Version der Fragen und Modell-ID geloggt, damit sich jede Entscheidung Monate später auf den genauen Wortlaut der Fragen zurückführen lässt.

Jeder Threshold ist ein Trade-off, und den verstehst du am besten, wenn du ihn ausprobierst. Unten liegen 50 ausgedachte Entscheidungen, jede dort eingezeichnet, wo die Wahrscheinlichkeit liegt, die das Modell ihr gegeben hat. Verschieb den Threshold und sieh zu, wie viele Fälle automatisch durchlaufen, wie viele falsche Antworten dabei mitrutschen und wie viele bei einem Menschen landen.

In einem Messenger-Handler sieht das so aus. Drei Dinge sind hier Absicht; wähl eine Erläuterung unter dem Code, um zu sehen, wo sie stehen:

Der zweite Einsatzort ist die Freigabe. Ein Tool-Call ist der Moment, in dem ein Agent handelt. Bevor er das darf, stellen wir einem Decision Model zwei Fragen zum geplanten Call. Strands Agents nennt das eine Intervention vor dem Tool-Call. In Symfony ist der natürliche Ort dafür ein Guard der Workflow-Komponente, weil die Transition dann für jeden Aufrufer gleich geschützt ist:

Eine Warteschlange für Freigaben entsteht dadurch noch nicht. Dein Workflow muss den Pfad zur menschlichen Prüfung vorsehen, und der Tool-Call darf erst nach einer erlaubten Transition stattfinden.

Prüf die Anbieterkompatibilität vor einem Wechsel. Die hier dokumentierte Bridge richtet sich an TypeSafe und liefert die Modell-IDs jev-latest, jev-preview und jev-1.13.0 mit. Liquid d1, Cloudflares Clef, Jeeves, Laya und Strands Decider bieten ähnliche Schnittstellen; daraus folgt noch nicht, dass die Bridge unverändert mit ihnen funktioniert. Wer was anbietet, steht in unserem Überblick über Decision Models.

Auch OpenAIs eigener Endpunkt /v1/decisions braucht eine passende Integration. Ähnliche Fragetypen machen ihn nicht zum direkten Ersatz für die TypeSafe-Bridge.

Weil der Aufruf in den Beispielen hinter PlatformInterface steckt, hast du eine geeignete Schnittstelle für einen anderen Anbieter oder ein selbst gehostetes Modell. Prüf dessen API-Verhalten und kalibrier die Thresholds neu, bevor du wechselst.

Unser wichtigstes Architekturmuster heißt seit Längerem "Das Modell schlägt vor, der Code entscheidet". Bisher kostete der Vorschlag einen vollen LLM-Aufruf mit Structured Output. Ein Decision Model kann diese kleinen Urteile beschleunigen und Wahrscheinlichkeiten liefern, die der Code gegen getestete Thresholds prüft. Wo unsere Agenten das Sprachmodell heute fragen, ob etwas relevant, sicher oder erledigt ist, würden wir ein Decision Model dagegen testen; das Schreiben bleibt beim LLM.

• Dokumenteneingang: Jede Datei bekommt beim Eintreffen ihre Pipeline und einen Risikowert, bevor ein LLM auch nur ein Feld extrahiert. Routinefälle brauchen das LLM gar nicht.
• Freigaben: Unsere Agenten liefern Entwürfe, Menschen geben frei. Ein kalibriertes "Braucht es einen Menschen?" könnte die Warteschlange dort verkürzen, wo automatische Bearbeitung bereits erlaubt ist. Welcher Anteil sicher automatisch durchlaufen kann, hängt von Aufgabe und Testergebnissen ab.
• Interviews und Umfragen bewerten: Score-Fragen gegen eine Rubrik liefern Stufe und Verteilung. Ob sie den bisherigen generativen Evaluator ersetzen können, muss für den jeweiligen Einsatz geprüft werden.
• Evals: LLM-as-a-Judge in der Testsuite durch ein Decision Model ersetzen, damit die Evals bei jedem Deploy laufen können.
• Modell-Routing: Vor jedem generativen Aufruf entscheidet ein kleines Modell, ob das günstige oder das große Modell dran ist. Bei ausreichendem Volumen kann das die Rechnung deutlich senken.

Die Regel dahinter ist einfach: Decision Model für das Ja oder Nein, Sprachmodell für die Prosa, getesteter Code für die Konsequenzen.

TypeSafe hat sein Modell nach dem Jevons-Paradoxon benannt, weil billigere Urteile zu sehr viel mehr automatisierten Urteilen führen werden. Deshalb sind der Threshold, der Guard und das Log keine Kür, sondern der Teil, der aus einer Demo ein System macht, das du verantworten kannst.

David Gorges ist Geschäftsführer von Dekkode in Hamburg; wir bauen Symfony-Anwendungen und KI-Funktionen. Wenn du ein Decision Model hinter einen Threshold gelegt hast, erzähl uns, wie es gelaufen ist: schreib uns. Den nächsten Beitrag bekommst du über den RSS-Feed des Blogs.