Wie setzt man LLM-Routing und Guardrails um? Ein Beispiel für die Zusammenarbeit von Jev mit großen Sprachmodellen

Interessen- und Evidenzoffenlegung: PandaNpc entwickelt eine Agent-Entscheidungsschicht, die Jev verwendet. Im Folgenden werden jeweils die offizielle TypeSafe-Dokumentation, das offizielle Cookbook sowie echte Jev-Aufrufe und Kalibrierungen synthetischer Szenarien aus unserem Repository zitiert. Unsere Kalibrierung verwendet einen skriptgesteuerten Fake-LLM-Provider und kann weder den echten Nutzerverkehr noch die Leistung der vollständigen Produktionskette repräsentieren.

LLM-Routing kann so aussehen: Zuerst lässt man Jev beurteilen, zu welcher Kategorie die Anfrage gehört und wie hoch das Risiko ist; dann entscheidet Code, ob sie an eine normale Funktion, ein spezialisiertes LLM oder eine menschliche Prüfung geht. Jev kann auch zwischen Retrieval und Generierung eingesetzt werden, um Evidenz zu filtern, oder nach der LLM-Ausgabe, um das Ergebnis zu prüfen. Es gibt geschlossene Optionen, Bewertungen und Wahrscheinlichkeiten zurück; offene Antworten, Codegenerierung und langes Reasoning werden weiterhin vom LLM erledigt. TypeSafe Hinweise zu Coding Agents weist ausdrücklich darauf hin, dass Jev nicht direkt das Chat-Modell hinter Claude Code oder Codex ersetzen kann.

Dieser Artikel erklärt anhand einer Kundenservice-Anfrage, einer RAG-Frage-Antwort-Pipeline und unseren eigenen Agent-Kalibrierungsaufzeichnungen, wo genau die beiden Modelltypen übergeben, und warum Ergebnisse mit niedriger Konfidenz einen klaren Zielpfad brauchen.

Was kann Jev beurteilen, und wofür bleibt weiterhin das LLM zuständig?

Stand 23. September 2026 ist das auf der TypeSafe-Modellseite aufgeführte stabile Modell jev-1.13.0. Die API akzeptiert einen state und eine Gruppe von questions und gibt über POST /v1/systemone entsprechende strukturierte answers zurück. jev-latest verwies an diesem Tag auf 1.13.0, aber Aliase ändern sich mit der Version; Systeme, deren Schwellenwerte kalibriert wurden, sollten die Version festlegen und die tatsächliche Modell-ID in der Antwort protokollieren.

Noul hat kein eigenes confidence-Feld; man darf eine Noul-Wahrscheinlichkeit nicht direkt als „Modellkonfidenz“ schreiben. Score sollte auch nicht zur Berechnung exakter Beträge verwendet werden. Beträge, Datumsvergleiche, Kontingente und Berechtigungsprüfungen sollten in deterministischen Programmen bleiben; offiziell sind diese Grenzen von Jev 1.13 aufgeführt.

Minimale Form eines Aufrufs

Die folgende Anfrageform entspricht der offiziellen API-Referenz; die Beispielfragen sind eine für diesen Artikel konstruierte illustrative Konfiguration und wurden hier nicht online getestet:

Das folgende JSON verwendet eine englische Kundennachricht; auf Deutsch würde der Kunde sagen: „Bei meiner Bestellung wurde der Betrag doppelt abgebucht, bitte erstatten Sie mir das Geld zurück.“

{
  "model": "jev-1.13.0",
  "state": {
    "message": "My order was charged twice. Please help me get a refund.",
    "account_note": "Customer asks about an order charge"
  },
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What does state.message primarily request?",
      "criteria": {
        "refund": "Money returned for a charge",
        "information": "An explanation only",
        "other": "Neither option fits"
      }
    },
    "asks_refund": {
      "type": "noul",
      "instructions": "Does state.message explicitly ask for money back?"
    }
  }
}

Ein reales System sollte außerdem zuerst per Code prüfen, ob die Abbuchungsdatensätze zur selben Bestellung gehören und ob eine Rückerstattung zulässig ist. Das obige Beispiel dient nur der Interpretation der Nutzerabsicht; dass der Nutzer eine Rückerstattung verlangt, bedeutet nicht, dass die Rückerstattungsberechtigung nachgewiesen ist, und ist erst recht keine Autorisierung, die Rückerstattung direkt auszuführen.

LLM-Routing mit Jev: drei Übergabepfade

Das offizielle TypeSafe-Beispiel zum Intent-Routing übergibt Kundenservice-Anfragen zuerst an Jev, um Absicht und Komplexität zu bestimmen, und leitet dann per Code weiter: Bestellstatus wird über Datenbankfunktionen abgefragt; Produktfragen und Rückgabe/Umtausch gehen an spezialisierte LLMs mit jeweils unterschiedlich geladenen Materialien; komplexe Beschwerden oder Ergebnisse mit niedriger Konfidenz landen in einer menschlichen Warteschlange. Genau das ist die am leichtesten verständliche Zusammenarbeit von Jev und LLM: Ersteres liefert strukturierte Urteile, Letzteres tritt nur auf, wenn Erklärungen oder Dialoge generiert werden müssen.

Bei der Umsetzung kann man in der folgenden Reihenfolge entwerfen, statt das Modell alle Aktionen frei entscheiden zu lassen:

1. Zuerst Pfade definieren: Klar auflisten, welche Anfragen normale Funktionen, die jeweiligen spezialisierten LLMs und menschliche Prüfung bearbeiten können, und für Choice eine other- oder vergleichbare Fallback-Option vorsehen.
2. Fakten in den state legen: Nutzeräußerung, Kontostatus und Bestelldatensätze als getrennte Felder; keine Webseitentexte unklarer Herkunft als Systemanweisungen behandeln.
3. Jeweils enge Fragen stellen: Für Absicht Choice, für Risiko oder Dringlichkeit Score, für einen zu bestätigenden Einzelfakt Noul. Offiziell wird empfohlen, mehrere unabhängige Fragen zum selben state in einer Anfrage parallel auszuwerten.
4. Den Code das endgültige Routing machen lassen: Zuerst Berechtungen und harte Regeln prüfen, dannevs Wahrscheinlichkeiten und die für dieses Geschäft kalibrierten Schwellenwerte; Anfragen mit niedriger Konfidenz oder fehlender Evidenz an Menschen geben oder nachfragen.
5. Ergebnisse protokollieren und überprüfen: Modellversion, Fragenversion, Wahrscheinlichkeiten, endgültigen Zielpfad und menschliche Korrekturergebnisse speichern, um beurteilen zu können, ob die Schwellenwerte passen.

Bildquelle: TypeSafe AI, „Introducing System One Models & Jev“, 2026-09-15. Die vier Workflows wurden von TypeSafe selbst erstellt, die Metriken werden je Workflow gleichgewichtet aggregiert; zur Bewertungsmethodik siehe TypeSafe workflow evals.

Diese offizielle Abbildung hilft zu verstehen, warum betont wird, „mehrere enge Urteile in einen Programm-Workflow einzubauen“. Die vertikale Achse übernimmt die Herstellerbezeichnung „accuracy“, aber ihre Referenzantwort stammt aus dem Konsens der vorhergesagten Wahrscheinlichkeiten zweier großer Modelle und ist keine manuell verifizierte eindeutige richtige Antwort; Kosten und Metriken hängen auch von diesen vier Workflows und der Bewertungsmethode des Herstellers ab und lassen sich nicht in „wie viel man in beliebigen Szenarien spart“ umrechnen.

Retrieval-Augmented Generation: Jev filtert Evidenz vor der LLM-Antwort

TypeSafe-Cookbook für RAG-Passagen bietet ein konkreteres Multi-Modell-Beispiel: OpenAI-Embedding ruft zuerst Passagen ab, Jev stellt für jedes „Frage + Passage“-Paar vier Noul-Fragen – ob es relevant ist, ob es Evidenz enthält, die zur Beantwortung verwendet werden kann, ob es die Prämisse in der Frage widerlegt und ob es versucht, dem Antwortmodell Anweisungen zu geben. Code verarbeitet die vier Wahrscheinlichkeiten in einer Reihenfolge und entscheidet, ob die Passage in den Evidenzbereich, den Konfliktevidenzbereich kommt oder verworfen wird; schließlich schreibt Claude Sonnet 5 die Antwort.

Dieser Schritt löst ein häufiges Problem: Passagen mit hoher Vektorähnlichkeit sind nicht unbedingt brauchbar. Sie können nur ähnliche Wörter verwenden, oder es kann sich in einem Forenbeitrag eine Prompt-Injection mit „Ignoriere den vorherigen Text“ befinden. Das Cookbook-Beispiel setzt die Injection-Prüfung an die erste Stelle der Routing-Regeln und erinnert zugleich daran, dass die Schwellenwerte ein für dieses Korpus gewählter Ausgangspunkt sind, nicht der Standardwert für alle RAG-Anwendungen. Seine Demonstrationszahlen stammen aus jev-1.12 vom 2026-08-27 und dürfen nicht als neue Bewertungsergebnisse des aktuellen jev-1.13.0 gelten.

Nach der Generierung kann noch eine Prüfschicht folgen. Das TypeSafe-Cookbook zur Zitatprüfung sucht zuerst per Programm den zitierten Originaltext und lässt dann Jev beurteilen, ob die Passage die generierte Behauptung stützt, ihr widerspricht oder sie nicht erwähnt. Es kann Zitate herausfiltern, die eine Überprüfung verdienen; das Modellurteil selbst kann weiterhin falsch sein, und „hat die Prüfung bestanden“ darf nicht als Faktengarantie geschrieben werden.

Unsere Agent-Kalibrierung: Wo bleibt die Eskalation bei niedriger Konfidenz hängen?

Im PandaNpc-Repository setzen Jev-Client, Fragenkatalog und Orchestrator Jev für die Absichtserkennung des Agent, die Bewertung von Änderungskandidaten, die Prüfung der Abschlussbedingungen und die Entscheidung über die Übermittlung ein. Der Client führt außerdem begrenzte Wiederholungen bei Timeout, 429 und 5xx durch und begrenzt Request-Budget sowie veraltete Ergebnisse; die Ausführungsberechtigung liegt beim Orchestrator und der kontrollierten Tool-Schicht und wird nicht direkt durch ein Jev-Urteil erteilt.

Am 2026-09-22 haben wir mit jev-1.13.0 19 synthetische Turns je einmal im shadow- und einmal im enforce-Modus ausgeführt, insgesamt 38 Läufe, und 165 echte Jev-Entscheidungen protokolliert. Dieser interne Kalibrierungsbericht und die gespeicherten Antworten der realen Maschine verwenden einen skriptgesteuerten Fake-LLM-Provider; daher zeigen diese Daten nur die Entscheidungsleistung in kontrollierten Szenarien. Sie können weder die Gesamterfolgsrate unter echten Nutzeranfragen noch Einsparquote oder End-to-End-Latenz belegen.

Der wertvollste Befund war nicht die durchschnittliche Geschwindigkeit, sondern eine „scheinbar sichere“ Schwelle, die einen Stau verursacht: Von den 19 Turns im enforce-Modus wurden 13 bei Q2 „Reichen die Informationen aus, um mit Änderungen zu beginnen?“ eskaliert, weil die Noul-Wahrscheinlichkeit in das ursprünglich festgelegte Unsicherheitsintervall von 0,15–0,85 fiel; der LLM Worker hatte keine Gelegenheit, die nachfolgenden Schritte auszuführen. Die Kalibrierungsaufzeichnungen zeigen, dass unter 34 Q2-Entscheidungen, die als informationsreich genug markiert waren, viele Wahrscheinlichkeiten im mittleren Bereich lagen. Der Bericht empfiehlt, das komplexe Q2 in atomarere Urteile aufzuteilen oder die Eskalationsregeln anzupassen; dies sind Empfehlungen, keine bereits eingesetzten Schwellenwerte.

Unser Fragenkatalog klassifiziert den Einstieg als answer_only, inspect, modify oder out_of_scope; auf dem Schreibpfad werden vom Worker vorgeschlagene Änderungskandidaten zuerst per Score sortiert, und der endgültige Inhalt sowie die Änderungszusammenfassung durchlaufen danach Abnahme- und Übermittlungsurteile. Dies sind nur Entscheidungspunkte: Ob tatsächlich auf ein Objekt gelesen oder geschrieben werden darf, entscheidet weiterhin der kontrollierte Executor, der Berechtigungen phasenweise vergibt. Jev ist nicht befugt, die Tool-Allowlist selbst zu lockern, und kann die Konsistenzprüfung vor der Übermittlung nicht umgehen.

Die Kalibrierungsdaten offenbaren einen weiteren Trade-off. Im shadow-Modus gibt Jev Antworten und die vollständige Verteilung aus, ändert aber nicht den ursprünglichen Ausführungspfad des Workers; im enforce-Modus beeinflussen die Antworten, ob fortgefahren, eskaliert oder verworfen wird. Wenn man die Genauigkeit im shadow-Modus direkt als Abschlussrate im enforce-Modus nimmt, versteht man das System falsch: Die Eskalation bei Q2 stoppt Aufgaben vorzeitig, sodass spätere Kandidatenbewertung, Abnahme und Übermittlungsfragen gar nicht erst auftreten können. Deshalb liest dieser Bericht Verteilung je Frage, Eskalationsrichtung und Endzustand getrennt.

Bei den Änderungskandidaten gab es einen konkreten Vergleich: Im selben Turn erhielt der Kandidat, der das Ziel präzise änderte, 2,94 Punkte, während der Kandidat, der die gesamte Datei überschrieb, 0,38 Punkte erhielt; der Kandidat mit der höheren Punktzahl wurde ausgewählt. Dieses Beispiel zeigt nur, dass die Score-Frage in diesem synthetischen Kontext zwei Optionen unterschieden hat. Umgekehrt erhielt ein Kandidat mit abgeschnittener Evidenz 2,27 Punkte; nur weil der Wert „ganz ordentlich“ aussieht, darf man seine niedrige Konfidenz und die Truncation-Markierung nicht ignorieren. Unser Code kennzeichnet unvollständige Evidenz separat, damit das Modell nicht allein aufgrund des beibehaltenen Präfixes ein sicheres Schreiburteil fällt.

Wir haben außerdem „welchen Kandidaten auswählen“ und „ihn schreiben lassen“ in zwei verschiedene Schritte getrennt. Nachdem ein Kandidat von Jev bewertet wurde, gibt der kontrollierte Executor Schreibwerkzeuge nur in der Phase ACT/modify frei; das ausgestellte Einmal-Ticket ist an Tool-Aufruf-ID, aktuelle Revisionsnummer, Hash des Zielobjekts und Parameterzusammenfassung gebunden. Selbst wenn der Kandidatentext das Modell dazuleitet, „Beschränkungen zu ignorieren“, erhält er keine Tool-Berechtigung, die diese Prüfungen umgeht. Das ist unsere Erfahrung aus der Integration aufebene: Wahrscheinlichkeitsurteile entscheiden welcher Weg sich lohnt, während Berechtungen für Nebenwirkungen durch überprüfbare Programmebedingungen bestimmt werden.

Auch Fehlerpfade müssen entwor werden. Der Client wiederholt nur bei Timeout, Netzwerkfehler, 429 oder 5xx begrenzt; nach einem Abbruch oder nach Überschreiten der Turn-Deadline werden Antworten direkt verworfen. Wenn Jev im enforce-Modus nicht verfügbar ist, darf ohne Genehmigung für einen Degradationsmodus nicht fortgefahren werden; wenn llm_only genehmigt ist, sperrt der Executor auf Nur-Lesen. Wenn ein Branch bereits Änderungen vorgenommen hat und dann Jev verliert, markiert der Orchestrator die gesamte Runde als fehlgeschlagen, statt ein nachfolgendes LLM ohne Entscheidungsschicht Schreibvorgänge nachholen zu lassen. Diese Pfade kosten Nutzererfahrung, verhindern aber, dass „Modell vorübergehend nicht verfügbar“ still zu „Schreibberechtigung wie bisher“ wird.

Der Kalibrierungsbericht unterscheidet außerdem „Eskalation bei niedriger Konfidenz“ und „Ausführung verweigern“. Wenn beispielsweise ein korrektes discard die einheitliche 0,85-Schwelle bei der Konfidenz nicht erreicht, wird es als „Nutzerinput erforderlich“ erfasst; das ist nicht gleichbedeutend mit einer falschen Freigabe. Der Bericht empfiehlt darauf aufbauend, die Schwellenwerte für Übermittlung und Verwerfen zu trennen, doch derzeit ist das noch eine Empfehlung. Beim Schreiben von Workflows muss man falsche Freigabe, falsche Ablehnung und ausstehende Prüfung drei verschiedene Ergebnisse unterscheiden, sonst führt dieselbe Datenmenge zu falschen Schwellenwertschlussfolgerungen.

Dieser Fall zeigt, dass die Zusammenarbeit von Jev und LLM nicht einfach als „Jev urteilt zuerst, LLM arbeitet danach“ gezeichnet werden darf. Bei jedem Urteil muss man fragen: Wie breit ist das Unsicherheitsintervall? Verhindert es, dass nachfolgende Prozessoren jemals eine Aufgabe erhalten? Kann bei abgeschnittener Eingabeevidenz klar eskaliert werden, statt zu raten? In unserer Implementierung protokolliert der state-Builder evidence_truncated und lässt Aufrufer den Pfad mit fehlender Evidenz als unsicher behandeln; deterministische Berechnungen wie Zählen und Sortieren erfolgen zuerst im Code und werden nicht Jev zum Raten überlassen. Offizielle bekannte Einschränkungen von Jev 1.13 empfehlen ebenfalls, Zählen und Arithmetik im Code zu belassen.

Wo sollten LLM-Guardrails platziert werden?

TypeSafe-Cookbook für LLM-Guardrails platziert Jev auf beiden Seiten des LLM, bei Eingabe und Ausgabe. Es verwendet eine Gruppe von Noul-Fragen, um verschiedene Risiken zu erkennen, und Score, um den Schweregrad zu messen; anschließend entscheidet Code je nach Richtlinie über Freigabe, menschliche Überprüfung, Blockierung oder Weiterleitung an den Support. Auch Ausgaben müssen geprüft werden, denn selbst normale Eingaben können ungeeignete Generierungsergebnisse liefern.

Die Grenzen solcher Guardrails sind ebenso klar: Jev kann Inhalte anhand vorab geschriebener Fragen prüfen, ist aber kein Allzweck-Sicherheitsnachweis. Das offizielle Dokument zu Einschränkungen erwähntdrücklich, dass bösartige Inhalte das Urteil beeinflussen können, und verlangt, criteria klar zu schreiben und Grenzfälle zu testen. In unseren synthetischen Stichproben haben wir 16 Injection-Sonden gegen Kandidatenparameter durchgeführt und 0 Rangfolge-Umkehrungen verzeichnet; die Stichprobe ist zu klein, um daraus abzuleiten, dass „Prompt-Injection-Resistenz gelöst“ ist. Was Werkzeuge tatsächlich tun dürfen, bestimmen weiterhin Allowlists, Phasengates und Prüfungen vor der Übermittlung im Code.

Wann ist der Einsatz geeignet, wann nicht?

Für Jev geeignet ist: Die Kandidatenmenge ist bekannt, die Frage lässt sich in einige kurze Urteile zerlegen, und die Software braucht Wahrscheinlichkeiten, um zwischen automatischer Bearbeitung und Eskalation an Menschen zu entscheiden. Beispiele sind Kundenservice-Routing, RAG-Passagenfilterung, Bewertung von Agent-Kandidatenaktionen und Zitatprüfung in generierten Ergebnissen. Wenn die Aufgabe darin besteht, eine Antwort zu schreiben, ein Stück Code zu ändern oder komplexes Reasoning zu erklären, übernimmt das LLM. Wenn die Aufgabe darin besteht, Geld exakt zu berechnen, Daten zu vergleichen oder Zugriffskontrolle zu prüfen, sollte das Programm direkt rechnen. Die Modellseite erklärt außerdem, dass Jev nur Text akzeptiert und Englisch die derzeit am besten abschneidende Trainingssprache ist; chinesischsprachige Szenarien müssen mit eigenen Daten bewertet werden, und die Schwellenwerte aus englischen Cookbooks dürfen nicht einfach übernommen werden.

Wenn man beobachten möchte, wie ein echter Agent Berechtigungen und Tool-Aufrufe behandelt, kann man zuerst PandaNpc Agent ansehen; zu den Grenzen und Einsatzszenarien von Coding Agents siehe auch Claude Code vs. Codex.

Leser können mit einem sehr kleinen Validierungsset beginnen: vier Probenkategorien vorbereiten – „klar automatisch bearbeitbar“, „klar abzulehnen“, „semantisch mehrdeutig“ und „enthält bösartige Anweisungen“; zuerst die menschliche Annotation festlegen, dann Jevs Wahrscheinlichkeiten je Frage und die Routing-Ergebnisse protokollieren. Das Erfolgskriterium ist nicht, dass jeder Fall automatisch durchgeht, sondern dass Fehlerrate des automatischen Pfads und der menschlichen Eskalationen in einem für Sie akzeptablen Bereich liegen. Wenn viele mehrdeutige Proben an derselben Frage hängen bleiben, prüfen Sie zuerst, ob die Frage mehrere Urteile vermischt, ob der state zu lang ist oder ob die Schwellenwerte an lokalen Daten kalibriert wurden.

FAQ

Kann Jev Claude Code, Codex oder Chat-Modelle ersetzen? Nein. TypeSafe positioniert es als strukturiertes Entscheidungsmodell innerhalb von Software; Chat, Schreiben und Codegenerierung benötigen weiterhin ein LLM.

Bedeuten feste Rückgabetypen, dass keine Fehler mehr passieren? Nein. Feste Typen reduzieren Parsing- und Out-of-Bounds-Ausgabeprobleme, aber Klassifizierung, Bewertung und Faktenurteile können weiterhin fehlerhaft sein. Pfade mit niedriger Konfidenz und hohem Risiko sollten menschliche Überprüfung behalten.

Wie viele Fragen können in einer Anfrage gestellt werden? Mehrere unabhängige Choice-, Score- und Noul-Fragen, die denselben state teilen, können in eine Anfrage gelegt werden. Die Fragen werden jeweils ausgewertet; komplexe Urteile sollten dennoch aufgeteilt und anschließend per Code kombiniert werden.

Kann Chinesisch verwendet werden? Offiziell wird Unterstützung für natürliche Sprachen einschließlich chinesischer, japanischer und koreanischer Schriftzeichen angegeben, aber Englisch hat derzeit die beste Genauigkeit. Chinesischsprachige Workloads müssen separat validiert und kalibriert werden.