System-One-Modelle erklärt: typisierte Entscheidungen statt Text

01

Was ist ein System-One-Modell?

Ein Modell, das für Software antwortet statt für Menschen. Es bekommt einen Zustand und eine Frage und gibt einen typisierten Wert mit Wahrscheinlichkeit zurück, den der aufrufende Code direkt verwenden kann.

Ein Sprachmodell erzeugt seine Antwort Wort für Wort und gibt Text zurück, den die aufrufende Software erst wieder zerlegen muss. Für ein Gespräch ist das die richtige Form. Für eine Zuordnung, eine Freigabe oder eine Bewertung ist es ein Umweg: Der Code wollte nie einen Satz, er wollte eine Klasse oder eine Zahl.

Ein System-One-Modell überspringt den Umweg. Es nimmt einen strukturierten Zustand entgegen, also einen Text, ein JSON-Objekt oder eine Liste von Abschnitten, und beantwortet dazu eine oder mehrere vorher festgelegte Fragen. Zurück kommt kein Text, sondern der Wert selbst und die Wahrscheinlichkeit, mit der das Modell ihn vertritt.

Die Einordnung dazwischen ist der eigentliche Punkt. Ein klassischer Klassifikator ist schneller und billiger, verlangt aber für jede neue Frage einen neuen Trainingslauf und beschriftete Daten. Ein Sprachmodell beantwortet jede Frage sofort, kostet dafür Latenz, Geld und einen Parser. Ein System-One-Modell liegt dazwischen: neue Fragen ohne Training, typisierte Antworten ohne Parser.

02

Welche Fragen kann ein solches Modell beantworten?

Drei Typen: eine Ja-Nein-Frage mit Wahrscheinlichkeit, eine Auswahl aus einer festen Optionsmenge und eine Einstufung auf einer Skala. Mehr gibt es nicht, und die Enge ist der Zweck.

Die Schnittstelle besteht aus drei Primitiven. Sie decken erstaunlich viel ab, weil sich die meisten Schritte einer Pipeline auf eine dieser drei Formen zurückführen lassen, sobald man sie einzeln formuliert.

Der praktisch wichtigste Hebel ist die Zerlegung. Statt einer Frage wie ob diese Rechnung in Ordnung sei, werden vier unabhängige Fragen gestellt: ob die Position zur Bestellung passt, ob der Preis im vereinbarten Rahmen liegt, ob der Lieferant bekannt ist, ob ein Liefernachweis vorliegt. Vier getrennte Wahrscheinlichkeiten lassen sich einzeln nachvollziehen und einzeln nachjustieren, ein zusammengefasstes Urteil nicht.

Zustand:  der Vorgang als Text oder JSON
Frage 1:  Auswahl  -> Kategorie aus fester Menge
Frage 2:  Skala    -> Dringlichkeit, Stufe 1 bis 5
Frage 3:  Ja-Nein  -> enthaelt alle Pflichtangaben
Frage 4:  Ja-Nein  -> braucht menschliche Pruefung

Rueckgabe: vier Werte, vier Wahrscheinlichkeiten, ein Durchlauf

Weil die Ausgabe klein ist und alle Antworten in einem Durchlauf zurückkommen, ist es günstiger, alle plausibel benötigten Fragen sofort mitzustellen, auch die, deren Antwort vielleicht ungenutzt bleibt. Die zweite Netzwerkrunde kostet mehr als die zusätzliche Frage.

03

Was bedeutet eine kalibrierte Wahrscheinlichkeit?

Sie ist eine Aussage über eine Verteilung, nicht über den Einzelfall. Sagt das Modell über viele Fälle hinweg 0,8, sind davon etwa acht von zehn richtig. Über den vorliegenden Fall sagt die Zahl nichts.

Wenn ein Sprachmodell eine Konfidenz von 0,9 nennt, schreibt es die Zeichen 0,9. Das ist eine Formulierung, keine Messung. Eine kalibrierte Wahrscheinlichkeit dagegen ist an der Häufigkeit geeicht: Über eine große Zahl von Fällen hinweg soll der Anteil der richtigen Antworten dem genannten Wert entsprechen.

Praktisch folgt daraus zweierlei. Erstens ist der Schwellenwert, ab dem ein Fall automatisch läuft oder an einen Menschen geht, eine Entscheidung über akzeptierten Fehler und gehört dokumentiert, nicht als Konstante in den Quellcode. Zweitens muss die Kalibrierung auf den eigenen Daten nachgemessen werden. Ein auf fremden Aufgaben kalibriertes Modell ist auf einem Rechnungsstapel aus einem bestimmten Haus nicht automatisch kalibriert.

04

Wo sitzt eine Entscheidungsschicht in einer KI-Pipeline?

Überall dort, wo heute ein Modellaufruf steht, dessen Ergebnis ohnehin ein JSON-Objekt ist: Eingangsklassifikation, Filterung von Suchtreffern, Werkzeugwahl, Prüfung extrahierter Felder und Guardrails.

Die Reihenfolge ist wichtiger als die einzelne Station. Die Entscheidungsschicht liefert Urteile, der Code besitzt die Folgen. Optionsmenge, Schwellenwert, Rechte und Rückfallpfad bleiben in gewöhnlichem Code, der geprüft und versioniert werden kann. Wo ein Projekt diese Trennung aufgibt und das Modell entscheiden lässt, was es tun darf, wird der Fehlerfall unbeherrschbar.

• Eingangsklassifikation: Was ist eingegangen, und braucht es einen Menschen?
• Filterung im Retrieval: Stützt dieser Abschnitt die Antwort, widerspricht er ihr, enthält er eine eingeschleuste Anweisung?
• Werkzeug- und Routenwahl: Welcher der vorhandenen Wege passt, und wie sicher?
• Prüfung der Extraktion: Wirkt dieser Wert vollständig und plausibel gegen den Quelltext?
• Guardrails: Verstößt diese Anfrage oder diese Ausgabe gegen eine Regel?

Für Retrieval-Systeme ist die Filterung der wirksamste Einzelschritt. Der teure Fehler ist nicht der fehlende Textabschnitt, sondern der irrelevante, der zu einer selbstbewusst falschen Antwort verarbeitet wird. Warum das die Antwortqualität stärker bestimmt als die Modellgröße, steht unter Retrieval-Augmented Generation.

05

Was kostet eine Entscheidung, und wie schnell ist sie?

Die veröffentlichten Werte liegen bei 0,042 US-Dollar je Million Eingabe-Tokens bei kostenlosen Ausgabe-Tokens und 70 bis 500 Millisekunden Antwortzeit. Die Vergleichsfaktoren zu Sprachmodellen stammen vom Anbieter.

Die erste öffentliche Umsetzung dieser Modellklasse ist Jev von TypeSafe AI, veröffentlicht am 15. September 2026 nach einer Seed-Finanzierung von 40 Millionen US-Dollar. Die Zahlen unten stammen aus der Ankündigung und aus der Dokumentation der Plattformen, die das Modell anbieten.

Die Größenordnung ändert weniger die Rechnung als das Verhalten. Kostet eine Prüfung fast nichts, hört man auf zu rationieren: Es wird jeder Treffer bewertet statt einer Auswahl, jedes extrahierte Feld geprüft statt einer Stichprobe, jede Anfrage gegen die Regel gehalten statt nur der auffälligen. Genau dieses Muster meint der Name des ersten Modells, ein Verweis auf das Jevons-Paradoxon.

06

Wo liegen die Grenzen?

Keine Begründung, kein Weltwissen, nur Text als Eingabe, und eine Kalibrierung, die nur über viele Fälle gilt. Für alles, was formuliert, erklärt oder recherchiert werden muss, ist die Modellklasse die falsche Wahl.

Dazu kommen technische Grenzen. Zustand und Fragen teilen sich ein Budget von rund 64.000 Tokens. Eine Auswahl trägt bis zu 255 Optionen, eine Skala 2 bis 10 Stufen. Es gibt nur Text: kein Bild, kein Audio, kein Video. Wer eine Szene oder einen Maschinenzustand bewerten lassen will, muss ihn vorher in eine Beschreibung übersetzen, und diese Übersetzung ist die eigentliche Ingenieursarbeit.

Offen ist auch, wie dauerhaft der Vorsprung ist. In der technischen Diskussion wird eingewendet, ein großer Teil der Geschwindigkeit könnte aus eingeschränkter Dekodierung gegen eine feste Auswahlmenge stammen statt aus einer neuen Architektur. Träfe das zu, wäre der Ansatz reproduzierbar. Für die Architekturentscheidung spielt das keine Rolle: Die Trennung von Entscheidung und Sprache lohnt sich unabhängig davon, wer sie anbietet.

07

Wie fängt man damit an?

Einen bestehenden Klassifikationsaufruf auswählen, einen Monat produktiver Aufrufe erneut abspielen und die Abweichungen ansehen. Nicht den Gesamtscore, sondern die Fälle, in denen alt und neu sich widersprechen.

1. Den Kandidaten auswählen

   Ein Schritt im laufenden System, dessen Ergebnis ohnehin eine Klasse, eine Zahl oder ein Ja-Nein ist. Meist die Eingangsklassifikation oder die Filterung von Suchtreffern.

2. Die Frage zerlegen

   Aus einer weiten Frage mehrere enge machen, jede mit eigener Antwort. Was sich nicht in eine Auswahl, eine Skala oder ein Ja-Nein bringen lässt, gehört nicht in diese Schicht.

3. Gegen Produktion abspielen

   Einen Monat echter Aufrufe erneut durchlaufen lassen, Genauigkeit und Antwortzeit im oberen Perzentil vergleichen.

4. Die Abweichungen lesen

   Nur dort, wo alt und neu sich widersprechen, zeigt sich, ob die Aufgabe jemals eine Sprachaufgabe war.

5. Schwelle und Nachweis festlegen

   Ab welcher Wahrscheinlichkeit automatisch entschieden wird, wer das verantwortet, und was je Entscheidung protokolliert wird.

Der größere Gewinn liegt selten in der eingesparten Inferenz. Die meisten Pipelines haben dünne Beobachtbarkeit, weil die Bewertung jedes Schritts einen weiteren Modellaufruf kostet und dafür kein Budget eingeplant ist. Sinkt diese Bewertung auf einen Rundungsfehler, lässt sich jeder Schritt jedes Laufs bewerten und Drift erkennen, bevor ein Nutzer sie meldet.