Billiges Routing, ungeprüfte Annahmen

Jev ist das Modell von TypeSafe für Entscheidungen statt für Fließtext. Sie schicken ihm einen Zustand und typisierte Fragen, und es liefert Antworten zurück, die auf die von Ihnen definierten Optionen beschränkt sind, jeweils mit einer Wahrscheinlichkeit. Eines der ersten Dinge, auf die Leute es angesetzt haben, war die Frage, welches LLM eine Anfrage bearbeiten soll.

Es gibt ein Repository namens jev-model-router, das unter Vorgaben zu Qualität, Kosten und Latenz ein Modell aus einem Katalog auswählt. In der Standardeinstellung ruft es Jev nie auf. Auf diesem Pfad ist das Ranking eine deterministische lokale Heuristik über den Katalog, und Jev kommt erst ins Spiel, wenn Sie den Provider wechseln. Dann agiert es als Richter über denselben Katalog. Das README behauptet nicht, dass beide Pfade gleich gut funktionieren, und der mitgelieferte Benchmark testet den Jev-Pfad nicht. Darüber, was besser routet, sagt das also nichts.

Was es aber zeigt, ist die Arbeitsteilung, und zwar ganz offen. Ein Router muss herausfinden, was eine Anfrage braucht, und das mit dem abgleichen, was Ihre Modelle leisten können. Jev ist an beidem beteiligt, denn die Kriterien, die Sie ihm mitgeben, sind das, wogegen es abgleicht. Was es nicht kann: diese Beschreibungen liefern oder Ihnen sagen, ob sie stimmen.

Was das Modell entscheidet

Die Routing-Middleware von LangChain, am 17. September angekündigt, ist die sauberste Formulierung des Musters. Sie deklarieren benannte Auswahlmöglichkeiten, jede mit einem Kriterien-String, der beschreibt, für welche Arbeit sie passt, dazu die Anweisung, das günstigste Modell zu wählen, das die Aufgabe sicher erledigen kann. Eine Choice-Frage pro Anfrage, und die Antwort samt Wahrscheinlichkeiten und Konfidenz landet im Agent-State, wo Ihr Code sie auslesen kann.

Udit Goenka hat seine eigene Migration beschrieben und dabei in einem einzigen Produkt einundvierzig Entscheidungen gezählt, die über ein Textmodell liefen. Der Prompt endete jedes Mal mit irgendeiner Variante von „antworte nur mit JSON“, und danach kam Code, dessen einzige Aufgabe es war, zu überleben, wenn das Modell diese Anweisung ignorierte. Eine typisierte Schnittstelle erspart Ihnen das Parsen und die Behandlung fehlerhafter Ausgaben. Semantische Validierung, Netzwerk-Retries und eine Fallback-Policy erspart sie Ihnen nicht, die müssen Sie weiterhin selbst schreiben.

Im Katalog stecken die Annahmen

Die zweite Aufgabe ergibt sich gar nicht aus der Anfrage. Jev kann Ihre Modelle nicht kennen, und TypeSafe sagt das selbst: Dieselben Gewichte bedienen jeden Account, es gibt kein Fine-Tuning auf Kundendaten, und alles, was das Modell über Ihre Situation weiß, kommt mit der Anfrage. Das Router-Repository formuliert dieselbe Einschränkung auf seine Weise: Fähigkeiten kommen ausschließlich aus dem Katalog, die Aufgabe kann keine hinzufügen.

Der Katalog ist also die Stelle, an der Annahmen über die Fähigkeiten von Modellen ins System gelangen. Ein Kriterium wie „Architektur, neuartige Ursachenanalyse und Entscheidungen mit hohem Risiko“ sagt dem Router, wofür Sie ein Modell vorgesehen haben. Dass das Modell das bei Ihren Anfragen zuverlässig schafft, ist damit nicht belegt. In solche Beschreibungen können Benchmarks und Erfahrungen aus der Produktion einfließen, gegen tatsächliche Ergebnisse testen müssen Sie sie trotzdem. Jedes neue Modell-Release ist ein Grund, wieder zu testen. Was die öffentlich verfügbaren Belege nicht verraten: wie viel diese Pflege in der Praxis kostet und wie oft eine veraltete Beschreibung dazu führt, dass falsch geroutet wird.

Eine dokumentierte Einschränkung bestimmt, wie Sie die Beschreibungen schreiben. Eine Choice-Frage akzeptiert bis zu 255 Optionen, das Inventar eines Gateways umfasst dagegen Tausende Modelle. Ihre Kandidatenmenge muss nicht das ganze Inventar sein, und dieselbe Seite beschreibt, wie man bei großen Taxonomien Fragen Ebene für Ebene verkettet. Am einfachsten ist es, auf Stufen zu routen und den Code anhand von Preis und Verfügbarkeit entscheiden zu lassen, welches Modell hinter einer Stufe steht. Damit ist die semantische Beurteilung von der Einkaufsentscheidung getrennt.

Was das eine Routing-Experiment zeigt

Routing ist kein neues Thema. RouteLLM und die Arbeiten rundherum messen seit 2024 Routing-Strategien an öffentlichen Benchmarks. Speziell für Jev listete ein Community-Verzeichnis am 17. September 409 Projekte, großteils Demos, mit einem Bereich für Benchmarks und Forschung, der nach meiner Zählung rund siebzig Einträge hat. Genau einer davon ist eine Routing-Evaluierung.

TokenTrims jev-routing-experiment berichtet über zwei Durchläufe. Ein kleiner Pilot routet 100 gecachte RouterArena-Anfragen auf drei Modelle. Dort erreichte Jev mit einer eingefrorenen Schwierigkeitsrubrik 69,5 Prozent bei einem Median von 311 Millisekunden pro Entscheidung und schlug damit denselben Aufbau mit bloßen Fähigkeits-Labels. Keiner der getesteten Router erzielte bei diesem Pool unterm Strich eine Verbesserung gegenüber dem besten fixen Modell.

Wichtiger ist der größere Durchlauf. Auf LLMRouterBench, mit 5.835 zurückgehaltenen Anfragen über dreizehn Flaggschiffmodelle, erreichte ein Router 62,4 Prozent gegenüber 60,3 für das beste Einzelmodell, bei etwa 15 Prozent geringeren Kosten. Er kombiniert Jevs Schwierigkeitsbewertung mit Retrieval-Evidenz darüber, wie jedes Modell bei ähnlichen Anfragen abgeschnitten hat. Der Benchmark liefert vorab bewertete Antworten mit, gemessen wird also per Nachschlagen ohne Inferenz. Erst das macht einen Vergleich dieser Größe leistbar. Die Jev-Aufrufe kosteten etwa dreizehn Cent. Die ausgewiesenen Kosten umfassen die Antwort des gewählten Modells, nicht den Overhead des Routings.

Dann die Ablation, die der Autor selbst durchführt und berichtet. Nimmt man Jev heraus, kommt dieselbe Pipeline wieder auf 62,4 Prozent, 62,442 gegenüber 62,425 in den gespeicherten Ergebnissen. Man sollte genau hinschauen, was dabei entfernt wurde. Der Arm ohne Jev erzeugt weiterhin ein Embedding der Anfrage und holt ähnliche Beispiele, und sein Retrieval-Index ist pro Datensatz angelegt. Er weiß also auch, aus welchem Benchmark die Anfrage stammt. Weg fällt nur Jevs Schwierigkeitswert, der im Auswahlcode steuert, wie viel Kosten der Router toleriert. Der Befund ist daher eng gefasst: Diese Implementierung schnitt ungefähr gleich gut ab, wenn man Jevs Schwierigkeitsurteil nicht zur bereits vorhandenen Retrieval-Maschinerie hinzufügte.

Die gespeicherten Ergebnisse der beiden Arme, mit und ohne Jev, gehen weiter als das README. Nimmt man in jedem Arm die günstigste getestete Einstellung, die die Genauigkeit des besten Einzelmodells erreicht oder übertrifft, kommt der Jev-Arm dort mit etwa 33 Prozent unter den Kosten dieses Modells an, die Ablation mit etwa 43 Prozent. Das sind unterschiedliche Kostengewichtungen. Die Arme werden also nicht beim selben Sweep-Gewicht verglichen, und bei fixem Gewicht ist die Ablation nicht durchgehend genauer. Das README nennt den Unterschied gering.

Drei Einschränkungen wiegen schwerer als diese Formulierung. Die Evaluierungsanfragen bleiben zwar aus der Retrieval-Evidenz heraus, aber die hervorgehobenen Betriebspunkte werden nach einem Sweep aus der Evaluierungshälfte ausgewählt, ohne separaten finalen Test. In den Hauptergebnissen steckt also ein ungemessener Optimismus. Der Retrieval-Index kennt den Quelldatensatz jeder Anfrage, eine Information, die Sie bei echtem Traffic nicht haben. Und ich habe Code und gespeicherte Ergebnisse gelesen, den Lauf aber nicht reproduziert. Wer sich auf diese Zahlen stützen will, sollte sie aus den gecachten Antworten und aufgezeichneten Entscheidungen neu berechnen, die gewählten Einstellungen einfrieren, sie auf einem separaten Evaluierungsset testen und dann schauen, wie viel vom Vorsprung übrig bleibt, wenn man nicht weiß, aus welchem Benchmark eine Anfrage kommt.

Was sich daraus ableiten lässt, ist bescheiden, aber nützlich. Auf diesem Benchmark schnitt ein Router, der die Leistung bei ähnlichen Anfragen nutzt, mit oder ohne Jevs zusätzliches Schwierigkeitsurteil ungefähr gleich ab. Das legt nahe, dass dieses Urteil in diesem Design wenig beigetragen hat. Es zeigt nicht, dass man Anfragen nicht interpretieren muss, denn das Retrieval-System nutzt den Text der Anfrage ja bereits. Die Lehre zeigt in dieselbe Richtung wie das Argument zum Katalog: Messen Sie, was ein zusätzliches Routing-Modell über die Informationen und die Maschinerie hinaus beiträgt, die Sie schon haben.

Die Latenzsteuer

Drei frühe Berichte messen Jevs Latenz mit unterschiedlichen Methoden. Ein Entwickler auf r/AI_Agents ließ zwei Routing-Pipelines parallel laufen und sah ungefähr eine Sekunde gegenüber vier bis vierzehn für ein LLM mit strukturierter Ausgabe, informell und ohne veröffentlichte Methode. Die Studie der FGV Direito SP maß einen Median von 0,32 Sekunden bei zwölf Fragen pro Dokument, mit Konfidenzintervallen und veröffentlichtem Code. Browser Use protokollierte 178 Millisekunden innerhalb seiner Agent-Schleife, aus drei gematchten Paaren, die die Autoren selbst als dünne Basis bezeichnen. Der erste Wert betrifft eine ganze Pipeline, die anderen einen einzelnen Modellaufruf. Sie zu einer Bandbreite zusammenzufassen wäre irreführend.

Das Geld spielt keine Rolle, laut Goenkas Gateway-Abrechnungen sind es etwa zwei Tausendstel Cent pro Aufruf. Die Zeit schon. Setzen Sie einen Routing-Aufruf von 320 Millisekunden vor eine Antwort, die eine Sekunde braucht, macht das Routing rund ein Viertel der Gesamtzeit aus, und der Overhead trifft ausgerechnet die günstigen, schnellen Anfragen am härtesten, die der Router schützen soll. Innerhalb eines Laufs kommt ein zweiter Preis dazu: Die Middleware von LangChain klassifiziert die letzte menschliche Nachricht und behält das gewählte Modell für jeden Aufruf im Lauf bei. Eine Aufgabe, die sich drei Tool-Ergebnisse später als schwieriger herausstellt, wird also nie neu bewertet. Wenn Sie vor jedem Modellaufruf neu klassifizieren, lässt sich die Wahl revidieren, dafür kostet jede Iteration zusätzliche Latenz.

Geben Sie der Policy einen Notausgang

Eine Routing-Policy braucht einen Ort für Unsicherheit. Der Beitrag von Langfuse bringt das auf die Formel „Jev kann sich nicht enthalten“, wobei das Primitiv eigentlich nicht das Problem ist: Eine Choice liefert eine Wahrscheinlichkeit für jede Option und eine Konfidenz, und Ihr Code kann das Ergebnis jederzeit verwerfen. Die Choice-Seite von TypeSafe empfiehlt eine Option other, damit das Modell sagen kann, dass keine der Alternativen passt, und im ausgearbeiteten Beispiel dort geht eine Antwort mit niedriger Konfidenz an einen Menschen, statt dass danach gehandelt wird.

Beim Routing hat Nichtwissen eine richtige Antwort, und die lautet: eskalieren. Legen Sie fest, wo die Schwelle liegt, codieren Sie die sichere Richtung fest ein, damit Unsicherheit nach oben aufgelöst wird, und behandeln Sie Schwierigkeit und Risiko als getrennte Fragen. Deren Fehler und Schwellen lassen sich getrennt leichter bewerten als zusammengefasst in einer Zahl.

Das Leck, das eine AUC umgedreht hat

Goenkas Bericht enthält die nützlichste Warnung in diesem ganzen Material, und es hat ihn eine Nacht gekostet, sie zu finden. Er bewertete Kaltakquise-E-Mails mit sieben Jev-Fragen, gewichtet zu einem Gesamtwert, und kam auf eine AUC von 0,889 bei 113 E-Mails. Über 90 Tage Produktionsbetrieb, also bei 2.106 E-Mails, erreichte derselbe Gesamtwert 0,237. Umgedreht, schlechter als Zufall, in die falsche Richtung. Antworten hatten sich in der ersten Stichprobe in Threads gehäuft, deren Betreffzeile mit Re: begann. Ein bloßes Re:-Flag allein kam auf 0,816, und bei Kaltakquise ohne vorherigen Thread landeten alle sieben Fragen zwischen 0,47 und 0,56.

Seine Zusammenfassung: Kalibrierung betrifft die Frage, die man gestellt hat, Signal betrifft, ob die Frage überhaupt zählt. Das lässt sich direkt aufs Routing übertragen. Ein Router, der in der Evaluierung hervorragend aussieht, orientiert sich vielleicht an der Länge der Anfrage, am Kanal, an der Kundenstufe oder an der Tageszeit, und jedes davon korreliert damit, an welches Modell Sie Anfragen derzeit schicken. Genau diese Korrelation ist das Label, gegen das Sie bewerten würden, wenn Sie den Router danach beurteilen, ob er mit Ihren bestehenden Regeln übereinstimmt.

Shadowing reicht nicht

Lassen Sie den Router im Schattenbetrieb laufen, erfahren Sie, wie oft er mit Ihrem Live-System übereinstimmt. Sie erfahren nicht, ob das günstige Modell eine brauchbare Antwort geliefert hätte, und genau das wollten Sie eigentlich wissen.

Sie brauchen ein vergleichbares Ergebnis für beide Optionen bei derselben Anfrage, bewertet nach Kriterien, die Sie vorher schriftlich festgelegt haben. Frische Inferenz ist ein Weg, aber nicht der einzige. Das Routing-Experiment oben vergleicht dreizehn Modelle über 5.835 Anfragen, ohne ein einziges davon aufzurufen, weil der Benchmark bewertete Antworten zum Nachschlagen mitliefert. Ausgaben, die Sie ohnehin schon von dem Modell haben, das Sie sonst verwendet hätten, zählen genauso. Bei einem Agenten, der Aktionen ausführt, ist kontrolliertes Replay sicherer als Live-Traffic. Teilen Sie die Ergebnisse dann nach dem Feld auf, das am ehesten das Ergebnis gratis mitliefert.

Ein Kommentator in jenem Reddit-Thread, der selbst ein Routing-Gateway baut, hat die Metriken besser formuliert, als ich es getan hätte: Routing-Genauigkeit, Enthaltungsrate, Fallback-Häufigkeit und die Kosten von Entscheidungen, die falsch und zugleich selbstsicher waren. Ich würde noch die Sichtweise aus LangChains kleinem Evaluator-Experiment ergänzen, das die Übereinstimmung mit dem Orakel mit der Wiederholbarkeit multipliziert. So kann ein Router, der schwierige Arbeit konsequent an das günstige Modell schickt, nicht allein durch seine Stabilität hervorragend aussehen. Protokollieren Sie zu all dem auch die fixierte Jev-Version, denn der Alias jev-latest wandert mit, sobald ein Release erscheint, und eine Schwelle, die gegen eine Version getunt wurde, sagt nur etwas über genau diese Version aus.

Die Fehler, die Sie nie sehen

Routing gilt meist als sicherer Einsatzort für ein günstiges Modell, weil eine falsche Antwort korrigierbar ist: Man fängt den Fehler ab und versucht es noch einmal mit dem größeren.

Die Rechnung dahinter geht auf. Angenommen, jede Anfrage geht zuerst an das günstige Modell, der Router kostet 0,01, das günstige Modell 0,10 und das teure 1,00. Braucht dann ein Fünftel der Anfragen das teure Modell, liegt der Durchschnitt bei 0,31 gegenüber 1,00, wenn man immer den vollen Preis zahlt. Darin sind die Kosten des Prüfschritts nicht enthalten, und es wird angenommen, dass der zweite Versuch gelingt. Fallbacks dürfen also häufig sein, und die Rechnung geht trotzdem auf.

Das Problem ist das Wort „abfangen“. Die Qualität des Routings offline zu messen, wie es das Routing-Experiment tut, ist machbar, wenn man einen Benchmark mit bewerteten Antworten hat. In der Produktion bei einer einzelnen Anfrage zu entscheiden, dass die Antwort, die gerade zurückgekommen ist, schlechter ist als die, die das größere Modell geliefert hätte, ist ein ganz anderes Problem, und nichts in dem Material, das ich gelesen habe, geht darauf ein. Eine fehlerhafte Antwort oder ein gescheiterter Tool-Aufruf fällt leicht auf. Eine Antwort, die bloß schlechter ist, nicht.

LangChains Vorbehalt zu Evaluatoren gilt hier unverändert: Niedrige Kosten verstärken Fehler, weil etwas, das konsequent falsch liegt, schlechte Ergebnisse in großem Maßstab produziert. Und ein Router ist ungewöhnlich gut darin, seine Fehler zu verstecken. Niemand eröffnet ein Ticket, weil das günstige Modell eine Frage beantwortet hat, die das teure besser erledigt hätte. Die Leute bekommen einfach die schlechtere Antwort, während das Dashboard die Ersparnis anzeigt.

Aus dem Englischen übersetzt: zum Originalbeitrag