Support-Tickets automatisch klassifizieren, Antwortkandidaten bewerten, Nutzerabsichten in Echtzeit routen – wenn man diese Urteile allesamt einem LLM überlässt, wartet man bei jedem Aufruf mehrere Sekunden, und die Kosten summieren sich schnell. TypeSafe AI hat mit Jev ein Modell vorgestellt, das genau diese häufigen, latenzkritischen „System One”-Aufgaben isoliert: 114 Millisekunden pro Aufruf, Kosten von $0.000081, typsichere Ergebnisse mit kalibriertem Konfidenzwert. Laut offiziellen Angaben 193,6× schneller und 444,6× günstiger als ein vergleichbares LLM.
Das wird nicht erreicht, indem man ein LLM kleiner und billiger macht, sondern durch ein Modell mit grundlegend anderer Architektur. Dieser Artikel erklärt das Konzept bis zur Architektur – damit du einschätzen kannst, wann Jev das richtige Werkzeug ist und wann du weiterhin ein LLM brauchst.
Kahnemans Rahmen: System 1 vs. System 2
Der Psychologe Daniel Kahneman beschrieb zwei Modi menschlichen Denkens:
- System 1: schnell, intuitiv, automatisch. Damit liest du ein Verkehrsschild, erkennst Sarkasmus oder beurteilst, ob eine E-Mail wie Spam aussieht. Reaktion in Millisekunden, ohne bewusste Anstrengung.
- System 2: langsam, überlegt, reflektierend. Damit schreibst du einen Aufsatz, beweist ein Theorem oder behebst eine Race Condition. Erfordert anhaltende Aufmerksamkeit und Arbeitsgedächtnnis.
Klassische LLMs – GPT, Claude, Gemini – sind im Kern System 2: Sie generieren tokenweise eine Inferenzkette und kommen erst am Ende zum Schluss. In offener Kreativität sind sie unerreicht, aber wenn du nur ein Ja/Nein-Urteil oder eine Bewertung auf einer Skala von 1–5 brauchst, ist eine tokenweise Inferenzkette reine Zeit- und Geldverschwendung.
Jev ist das System 1 für Software: Es nimmt strukturierte Eingaben entgegen und liefert direkt eine typisierte Entscheidung – ohne Inferenzkette.
Wie sich Jev von LLM + strukturiertem Output unterscheidet
Der gängige Ansatz heute: dem LLM ein JSON-Schema geben und hoffen, dass es sich daran hält:
response = llm.generate(
prompt="Klassifiziere dieses Ticket: 'Meine GPU brennt'",
schema={"category": str, "urgency": int, "confidence": float},
)Das LLM generiert weiterhin Text Token für Token, und du musst das Ergebnis parsen und validieren. Das Modell kann ein Feld halluzinieren, das JSON in Prosa einwickeln oder einen Aufzählungswert ausgeben, der gar nicht existiert – im besten Fall wirft dein Code einen Fehler, im schlimmsten Fall akzeptiert dein System stillschweigend einen falschen Typ.
Jev funktioniert anders. Der Entscheidungsraum ist vor der Inferenz definiert:
decision = jev.classify(
input=ticket_text,
choices=["billing", "hardware", "software", "other"],
)
# → {"choice": "hardware", "probability": 0.97, "confidence": 0.94}Das Modell bewertet die vordefinierten Optionen parallel und liefert direkt ein typisiertes Ergebnis. Es kann sich darüber irren, welche Option korrekt ist – aber es wird niemals ein Feld zurückgeben, das in deinem Schema nicht existiert. Es gibt kein Schema, das halluziniert werden könnte – das Schema ist die Architektur selbst.
Das ist mit „Null-Halluzination” bei Jev gemeint: Null Schema-Halluzination, nicht Null Fehler. Diese Unterscheidung ist entscheidend – Jev kann ein Ticket falsch klassifizieren, aber es kann niemals {"categori": "billng"} zurückgeben.
Drei Ausgabe-Primitive
Jev stellt drei primitive Fragetypen bereit, die jeweils eine Entscheidung samt Wahrscheinlichkeit und Konfidenz liefern:
| Primitiv | Zweck | Rückgabe | Beispiel |
|---|---|---|---|
| Choice | Eine Option aus begrenzter Auswahl wählen | Gewählte Option + Wahrscheinlichkeit + Konfidenz | ”Ist diese Suchanfrage wohlgeformt?” → valid, 0,98, 0,95 |
| Score | Nach Bewertungskriterien benoten | Bewertung + Wahrscheinlichkeit + Konfidenz | ”Bewerte diese Antwort mit 1–5 für faktische Genauigkeit” → 4, 0,82, 0,88 |
| Noul | Wahrscheinlichkeit einer binären Aussage beurteilen | Gleitkommazahl 0,0–1,0 | ”Ist diese Behauptung im Quelldokument belegt?” → 0,93 |
Diese Primitive lassen sich kombinieren. Eine komplexe Routing-Entscheidung lässt sich in drei parallele Choice-Aufrufe plus eine Noul-Schutzprüfung zerlegen – alle Ergebnisse in einem einzigen Round Trip.
Die Architektur: Drei Säulen
1. Eine neue Architektur, kein kleineres LLM
TypeSafe AI sagt es ausdrücklich: Jev ist „weder klein noch ein LLM”. Es verwendet eine von Grund auf für die Bewertung von Entscheidungsräumen entworfene Architektur – keine autoregressive Textgenerierung. Das ist kein GPT mit einem eingeschränkten Decoder darüber – es ist eine andere Art von Modell.
2. Paralleles Sampling über den Entscheidungsraum
Klassische LLMs generieren Token nacheinander. Um „Ist das Spam?” zu beantworten, müssen sie erst eine Inferenz erzeugen, dann ein Urteil, dann als JSON formatieren – jeder Schritt hängt vom vorherigen ab.
Jev bewertet in einer einzigen Abfrage alle Zweige des vordefinierten Entscheidungsraums parallel. Bei einer 4-fach-Klassifikation durchläuft es nicht erst Option A, dann B, dann C – es bewertet alle vier gleichzeitig und liefert die Wahrscheinlichkeitsverteilung über alle Optionen in einem Zug.
3. RLCD: Reinforcement Learning for Calibrated Decisions
Die meisten modernen Modelle werden mit RLHF (Reinforcement Learning from Human Feedback) getunt, optimiert auf menschliche Präferenz. RLHF erzeugt Modelle, die selbstbewusst und hilfsbereit klingen – aber häufig buchstäblich überconfident sind: Das Modell behauptet 90 % Sicherheit, die tatsächliche Trefferquote liegt vielleicht bei 70 %.
Jev wird mit RLCD (Reinforcement Learning for Calibrated Decisions) trainiert, optimiert auf Kalibrierung statt Präferenz. Kurz gesagt: Das Modell soll seine Sicherheit nicht übertreiben. Wenn Jev 80 % Konfidenz angibt, sollte die tatsächliche Trefferquote bei ähnlichen Eingaben bei etwa 80 % liegen. Für Produktionssysteme bedeutet das: Du kannst Konfidenzwerte bedenkenlos für Verzweigungslogik verwenden.
Leistung: Offizielle Zahlen
TypeSafe AI veröffentlichte folgenden Vergleich für einen System-One-Arbeitsablauf:
| Metrik | Jev | Vergleichbares LLM | Faktor |
|---|---|---|---|
| Kosten pro Aufruf | $0.000081 | $0.013880 | 444,6× günstiger |
| Latenz | 0,114 s | 8,566 s | 193,6× schneller |
Der Eingabepreis beträgt $42 pro Milliarde Tokens (etwa $0,042 pro Million) – laut Unternehmen 238× niedriger als Claude Fable 5.1. Für Jevs typisierte Ergebnisse fallen keine Output-Token-Gebühren an.
Hinweis: Auf der Jev-AI-Landingpage steht ein konservativer Bereich aus früheren Benchmarks (40–200× Geschwindigkeit, $0.042/M Input-Tokens). Die Werte 193,6× / 444,6× stammen aus TypeSafe AIs aktuellster Veröffentlichung (Stand September 2026).
Unabhängige Validierung: Das LangChain-Experiment
Benchmark-Ergebnisse des Anbieters sind Hinweise – unabhängige Validierung ist das, was zählt. LangChain setzte Jev als Agent-Evaluator in LangSmith ein und verglich ihn mit drei LLM-Evaluatoren:
- Setup: Fünf Weather-Agent-Läufe, jeder von vier Evaluatoren (Jev, GPT-5.6 Luna, GPT-5.6 Terra, Claude Sonnet 4.6) nach dem binären Kriterium
does_pass100-mal wiederholt bewertet, mit manuellen Annotationen als Referenz. - Jev-Ergebnis: Alle 500 Bewertungen stimmten mit den manuellen Annotationen überein (100 % Übereinstimmung).
- Varianz: Jevs durchschnittliche Per-Case-Varianz betrug 0,0000149. GPT-5.6 Luna lag 433× höher, GPT-5.6 Terra 913×, Claude Sonnet 4.6 92×.
- LLM-Übereinstimmung: Terra 99,8 %, Luna 96,4 %, Claude Sonnet 4.6 80,0 %.
LangChain selbst weist darauf hin: Das ist ein Beobachtungsexperiment auf einer einzelnen Aufgabe – es beweist nicht, dass die niedrige Varianz zwingend aus dem RLCD-Training resultiert. Das Ergebnis selbst ist aber bemerkenswert: Ein System-One-Modell erreichte in dieser Aufgabe perfekt stabile, perfekt genaue binäre Urteile – bei Kosten und Latenz, die nur einen Bruchteil jedes LLM-Evaluators ausmachen.
Damit positioniert sich Jev als dritte Kategorie von Evaluator:
- Code-Regel-Evaluation: schnell, deterministisch, günstig – aber nur Syntaxprüfung.
- LLM-as-judge: versteht Semantik – aber langsam, teuer, hohe Varianz.
- System-One-Evaluation (Jev): versteht Semantik und ist schnell, stabil, kalibriert.
Wann Jev (und wann nicht)
Jev eignet sich für Szenarien mit einer gemeinsamen Eigenschaft: Urteile müssen schnell und wiederholt getroffen werden, und der Antwortraum ist enumerierbar.
- Intelligente Verzweigung: starres if/else durch semantische Routung ersetzen.
- Klassifikation: Tickets, Logs, Dokumente, Absichten, Risikostufen.
- Bewertung: Antwortqualität, Relevanz, Sicherheit, faktische Genauigkeit.
- Schutzabfragen: “Ist diese Antwort faktisch belegt?” “Verstößt diese Ausgabe gegen die Inhaltsrichtlinie?”
- LLM-as-judge ersetzen: stabile, günstige automatisierte Bewertung im großen Maßstab.
- Batch-Verarbeitung: Millionen paralleler Entscheidungen in Map-Reduce-Pipelines.
Jev eignet sich nicht für:
- Langes Schreiben oder Codegenerierung – es gibt keine langen Freitexte aus.
- Komplexe mathematische Herleitung – es trifft Urteile, keine Beweise.
- Offene Exploration – du musst den Entscheidungsraum vorab definieren.
- Aufgaben mit mehrstufiger Inferenz – überlass sie einem System-2-LLM.
Das praktische Muster: Jev übernimmt die schnellen Entscheidungen um LLM-Aufrufe herum (Routing, Validierung, Bewertung), während LLMs für die Schritte bleiben, die tatsächlich generative Leistung erfordern.
Produktionsintegrations-Muster
Teams, die Jev einführen, sollten diese Praktiken befolgen:
- Den Entscheidungsraum klar definieren. Die Qualität von Jevs Output hängt von der Qualität deiner Options- und Bewertungskriterien ab – vage Kategorien ergeben vage Wahrscheinlichkeiten.
- Strukturierte Eingaben liefern. Metadaten, abgerufene Dokumente, Konversationszusammenfassungen als strukturierten Kontext übergeben – keine langen Freitexte einfach hineinwerfen.
- Auf Konfidenz verzweigen, nicht nur auf die Top-Option. Hohe Konfidenz → automatisch ausführen. Mittel → konservativer Pfad oder Retry. Niedrig → manuelle Prüfung oder LLM-Fallback.
- Kalibrierungskurven im Blick behalten. Prüfen, ob die angegebene Konfidenz mit der tatsächlichen Trefferquote übereinstimmt. Ändert sich die Datenverteilung, kann sich auch die Kalibrierung verschieben.
- In atomare Fragen zerlegen. Komplexe Entscheidungen in parallele Choice-/Score-/Noul-Aufrufe aufteilen, jeweils mit eigenständiger Konfidenz.
- Fallback vorsehen. Bei Hochrisiko-Entscheidungen mit unzureichender Konfidenz an einen Menschen oder ein stärkeres, aber langsameres LLM weiterleiten.
Hintergrund: TypeSafe AI
Jev wurde von TypeSafe AI entwickelt, gegründet von Diogo Almeida – öffentlichen Angaben zufolge ein Mit-Erfinder von ChatGPT. Das Unternehmen stellte Jev am 15. September 2026 als sein erstes öffentliches System-One-Modell vor.
Jev ausprobieren
Du kannst Jev über die Jev API testen – DefAPI bietet einen halben Preis: