jevals: typisierte Urteile statt LLM-Richter für Agenten

Was das README von jevals beschreibt

jevals ist eine Open-Source-Python-Bibliothek in der GitHub-Organisation openlayer-ai. Das README nennt sie „Evals und Guardrails für Agenten“, die Entscheidungsmodelle im Stil von Jev statt eines LLM-Richters nutzen. Die zentrale Aussage betrifft Kosten und Tempo. Alle Evals für eine Agenten-Trace gehen als eine einzige Anfrage hinaus. Laut README kostet diese Anfrage einige Tausendstel Cent und kommt nach einigen hundert Millisekunden zurück. Das sei schnell genug, um sie für jede Trace und sogar innerhalb der Agentenschleife auszuführen.

Dieser Artikel folgt allein dem README. Wir haben das Werkzeug weder installiert noch ausgeführt. Alle Zahlen unten sind Aussagen des Autors, und wir weisen dort darauf hin, wo das README selbst eine Zahl als Schätzung oder Illustration kennzeichnet.

Die wichtigsten Fakten aus dem README

Die Modellidee. Das README sagt, Jev erzeuge keinen Text. Man schickt ihm einen Zustand und eine Reihe typisierter Fragen: Ja/Nein, Auswahl aus mehreren Optionen oder Bewertung nach einem Raster. In einem einzigen Vorwärtsdurchlauf liefert es für jede Frage eine kalibrierte Wahrscheinlichkeit. Die Fragen werden unabhängig voneinander und parallel ausgewertet, sodass 40 Fragen ungefähr die gleiche Latenz haben wie eine. Das README nennt einen Preis von 0,042 $ pro Million Eingabe-Token ohne Ausgabe-Token und misst über das Gateway von Vercel ein p50 von 244 ms und ein p95 von 371 ms pro Anfrage. Der Schnellstart. Ein einziger Aufruf von `evaluate()` nimmt die Nachrichten und die Tool-Schemas entgegen, dazu eine Liste von Eval-Objekten wie `ToolChoice`, `UsedToolResult`, `Grounded`, `StayedInScope`, `AnswerRelevancy`, `Completeness`, `IndirectInjection` und `PHI`. Das README berichtet, dass acht Evals in einer einzigen HTTP-Anfrage liefen: 1.388 Token, 0,00006 $ und 0,33 Sekunden. Die Backends. Die Bibliothek wählt ihr Backend anhand von Umgebungsvariablen. Zur Auswahl stehen Jev direkt über `TYPESAFE_API_KEY` (laut README derzeit nur mit Wartelisten-Zugang), Jev über das Vercel AI Gateway, ein selbst gehostetes Kev, Laya im selben Prozess auf Apple Silicon oder ein gewöhnliches Chat-LLM über OpenRouter, das per Prompt emuliert wird, der nach Wahrscheinlichkeiten fragt. Das README warnt, nach einem Backend-Wechsel `jevals calibrate` erneut auszuführen, weil die Wahrscheinlichkeiten zwischen Modellen nicht zueinander passen.

Der Katalog. Das README listet Agenten-Evals (zum Beispiel `ToolChoice`, `Grounded`, `StayedInScope`, `LoopDetection`, `GoalCompletion` und `ToolCallRisk`), Sicherheits-Evals (`PromptInjection`, `IndirectInjection`, `Jailbreak`, `PII`, `PHI`, `SecretsExposure` und weitere) und Qualitätsmetriken im Stil von Ragas (`Faithfulness`, `AnswerRelevancy`, `ContextPrecision`, `ContextRecall` und weitere). Insgesamt zählt es 37 Evals. Die Vergleichstabelle. Das README vergleicht jevals mit Ragas auf denselben 20 Zeilen eines kleinen RAG-Datensatzes, gemessen am 2026-09-20. Ragas mit gpt-4.1-mini braucht 6,0 LLM-Anfragen pro Beispiel plus Embeddings, etwa 2,60 $ pro 1.000 Beispiele und 22 bis 35 Sekunden für die 20 Beispiele. jevals mit Jev braucht 1,0 Anfrage pro Beispiel, etwa 0,03 $ pro 1.000 Beispiele und 0,8 Sekunden. jevals mit gpt-4.1-mini, das Jev emuliert, braucht 1,0 Anfrage, 0,46 $ pro 1.000 Beispiele und 4 Sekunden. Die Zeilen für Kev-4B und Laya sind als Schätzungen gekennzeichnet. Die Faithfulness lag in allen drei gemessenen Zeilen bei 0,90 bis 0,92, Context Precision und Recall bei 1,0.

Wie Evals und Gates funktionieren

Ein Eval ist eine Klasse mit drei Methoden. `state()` wählt aus, was das Modell ansehen soll. `questions()` legt fest, was gefragt wird. `reduce()` macht aus den zurückgegebenen Wahrscheinlichkeiten einen Wert. Übergibt man mehrere Evals an `evaluate()`, werden laut README ihre Zustände zusammengeführt und ihre Fragen in einer Anfrage gebündelt. Weil ein Eval nur vom Beispiel abhängt, kann dieselbe Klasse als Offline-Metrik, als Monitor für Produktions-Traces oder als Gate im Agenten dienen.

Ein Gate ist ein Eval plus eine Richtlinie, die Antworten auf „erlauben“, „eskalieren“ oder „blockieren“ abbildet. Das README zeigt ein YAML-Gate für das Risiko eines Tool-Aufrufs. Seine Richtlinie erlaubt einen Aufruf, wenn `action.approve >= 0.85` und `grounded >= 0.7` gelten, blockiert ihn bei `action.block >= 0.6` und eskaliert sonst. Das README zeigt die Anbindung an das OpenAI Agents SDK, an eine einfache asynchrone Schleife, an LangGraph und an einen `PreToolUse`-Hook des Claude Agent SDK. Ist das Backend nach den Wiederholungsversuchen weiter nicht erreichbar, lässt ein Gate den Aufruf standardmäßig durch. Mit `on_error="block"` kehrt man das für alles Unumkehrbare um.

Für PII und PHI beschreibt das README zwei Schritte. Zuerst kommt die Entitätserkennung. Dann geht eine Frage an das Modell: Handelt es sich um Gesundheitsinformationen über eine identifizierbare Person oder um die E-Mail-Adresse eines Supports? Das README sagt, die Entitätserkennung allein könne beides nicht unterscheiden, und das sei die Quelle der meisten PII-Fehlalarme.

Hintergrund und unsere Einschätzung

*Dieser Abschnitt ist unsere Analyse, nicht die des README.* Ein LLM-Richter heißt: Man lässt ein allgemeines Chat-Modell eine Ausgabe bewerten, meist über einen Prompt, der eine Begründung und eine JSON-Antwort verlangt. Das README argumentiert, dass die meisten Urteile eines Richters in drei Fragetypen passen und dass man vom Richter ohnehin ein Label behält. Wenn ein kleines Modell dieses Label in einem Durchlauf mit einer Wahrscheinlichkeit liefern kann, kann man es viel häufiger laufen lassen. Das ändert, wofür Evals taugen. Eine nächtliche Stichprobe wird zur Prüfung jeder Trace, und eine Prüfung jeder Trace kann in den Anfragepfad rücken.

Das README spricht auch die Varianz an. Es zitiert einen Vergleich von LangChain, in dem GPT- und Claude-Richter auf identischen Traces die 92- bis 913-fache Score-Varianz von Jev zeigten. Diesen Beitrag haben wir nicht gelesen. Außerdem lässt sich eine Wahrscheinlichkeit, anders als ein Textabsatz, mit einem Schwellenwert versehen, sodass sich der Kompromiss pro Aktion einstellen lässt. Das Beispiel zu `jevals calibrate` im README stellt Schwellenwerte den falschen und den verpassten Freigaben gegenüber. Das README rät zu Schwellenwerten pro Aktion, weil sich eine Erstattung und eine Abfrage keinen Schwellenwert teilen sollten.

Die erfundene Aussage im eigenen Beispiel des README zeigt, warum mehrere Metriken nützen. Der Agent sagte, es bleibe „die ganze Woche sonnig“, obwohl das Tool nur die heutige Vorhersage lieferte. Das Eval `grounded` gab diesem Satz p=0,05, während `answer_relevancy` bei 0,84 blieb. Das README folgert, dass RAG-artige Metriken allein die Trace durchgewinkt hätten.

Grenzen und offene Fragen

Das README ist offen über seine Grenzen. Es sagt, das Projekt sei Alpha und eine Woche alt, und die zugrunde liegenden Modelle seien ebenfalls eine Woche alt. Das direkte TypeSafe-Backend ist nach dem dokumentierten Übertragungsformat geschrieben und gegen einen Mock getestet, aber noch nicht live gelaufen. Die Framework-Adapter sind nach der SDK-Dokumentation geschrieben und gegen Attrappen getestet. Die Zeilen für Kev und Laya in der Tabelle sind Schätzungen, hochgerechnet aus Zahlen, die die Autoren dieser Modelle veröffentlichen. Mehrere Ausgabeblöcke tragen die Bezeichnung „Illustrative output“. Das README sagt außerdem, das Werkzeug erzeuge keine Testsätze, habe kein Dashboard und ersetze keinen LLM-Richter, wenn mehrstufiges Schlussfolgern oder eine schriftliche Kritik gefragt ist.

Zur Genauigkeit zitiert das README JevBench, einen unabhängigen Benchmark. Er sieht Jev bei Klassifikationsaufgaben ungefähr auf dem Niveau der kleinsten LLMs (83 bis 87 % auf Banking77 und CLINC150) und stellt fest, dass die Kalibrierung je nach Aufgabe schwankt. Das Ergebnis von LangChain mit 100 % Übereinstimmung mit einem Menschen über 500 Wiederholungen, gegenüber 80 % bei Claude, betraf laut README nur fünf Traces. Es berichtet ferner, dass das Gateway in einem Lauf bei einigen Verbindungen hing, sodass das p95 dieses Laufs eine Minute betrug, obwohl der Client es erneut versuchte und der Lauf endete. Uns sind kleine Unstimmigkeiten im README aufgefallen. Die Einleitung zeigt acht Evals mit 1.388 Token und 0,33 Sekunden, das längere Beispiel dagegen neun mit 1.423 Token und 0,50 Sekunden. Der Text spricht von „sechs Hundertstel Cent“ bei ausgegebenen Kosten von 0,00006 $, was sechs Tausendstel Cent entspricht. Das wirkt wie Formulierungsfehler aus verschiedenen Läufen und nicht wie ein tieferes Problem, zeigt aber, warum man selbst nachmessen sollte. Unsere Einschätzung: Die Ersparnis hängt davon ab, ob Ihre Fragen in die drei Typen passen und ob Ihre Daten der kleinen Stichprobe der Tabelle ähneln. Die schärfste Warnung liefert das README selbst: Der Klassifikator darf nicht zur Instanz werden, die Aktionen genehmigt. Ob eine Erstattung ausgeführt werden soll, hängt von Kontostand und Berechtigungen ab, die das Modell nicht sehen kann.

Praktische Hinweise für Leser

1. Wenn Sie bereits einen LLM-Richter auf einer Stichprobe Ihres Verkehrs laufen lassen, ist das LLM-Emulations-Backend aus dem README der reibungsärmste Weg, die API auszuprobieren. Das README sagt, es funktioniere heute, liefere aber Wahrscheinlichkeiten von 0,00 oder 1,00 statt kalibrierter Werte.

2. Beschriften Sie einige eigene Traces und führen Sie `jevals calibrate` aus, bevor Sie einem Schwellenwert trauen.

Laut README sind Kalibrierungsdaten der Beitrag, der am meisten helfen würde.

3. Setzen Sie bei unumkehrbaren Aktionen einen Menschen ein und stellen Sie bei den Gates davor `on_error="block"` ein.

4. Folgen Sie den Schreibtipps des README: eine Frage pro Sache, Optionen beschreiben statt nur benennen, den Zustand klein halten und eine Option „unzureichende Belege“ ergänzen, wenn der Zustand die Antwort möglicherweise nicht enthält.

5. Behandeln Sie die Framework-Adapter als raue Stellen, bis jemand sie live ausgeführt hat, und die Kostentabelle als Aussage des Autors. Wiederholen Sie den Vergleich mit Ihren eigenen Traces, bevor Sie darauf planen.