Getippte Entscheidungsmodelle gegen Anfragen an LLMs: Latenz und Stabilität an der Grenze
Ein 240-Anrufe umfassendes Experiment, das Jevs natürliche Wahrscheinlichkeiten mit den von einem LLM selbst gemeldeten vergleicht, sowie die Methode, dieses Signal in einen LangChain-Modell-Router umzuwandeln.
Quellen: **Does Every AI Decision Need an LLM? Testing Jev with LangChain**
Der moderne Agentencode ist voller kleiner Ja-oder-Nein-Entscheidungen: Ist dieser Ticket dringend, passt diese Toolaufrufmethode zur Anfrage, lohnt es sich, diesen Datensatz abzurufen? Die übliche Vorgehensweise besteht darin, jede dieser Fragen mit einem weiteren generativen LLM-Aufruf zu beantworten und die strukturierte Antwort zu analysieren – was funktioniert, aber sekundensweise Zeit kostet und zahlreiche unscharf definierte Ergebnisse liefert. In dieser Anleitung wird derselbe begrenzte Entscheidungsprozess insgesamt 240 Mal sowohl durch ein speziell dafür entwickeltes Entscheidungsmodell als auch durch ein allgemeines LLM durchgeführt, wobei die resultierenden Wahrscheinlichkeiten anschließend in einen LangChain-Router eingefügt werden. Am Ende wissen Sie, wie man eine solche Vergleichbarkeit fair bewerten kann, wie die Unterschiede in Latenz und Stabilität aussehen sowie wie man die Routing-Logik in reinem Code statt innerhalb eines Prompts speichert.
Begrenzte Entscheidungen sind keine Generierungsaufgaben
Betrachten Sie die Entscheidungen, die in einer typischen LLM-Anwendung vorkommen – viele davon dienen eigentlich nicht der Erstellung von Sprache:
- Soll dieser Support-Antrag als dringend behandelt werden?
- Stimmt das vorgeschlagene Tool tatsächlich mit dem überein, was der Benutzer gefragt hat?
- Erfüllt ein Dokument eine bestimmte Bedingung?
- Ist ein abgerufter Abschnitt relevant genug, um in den Kontext aufgenommen zu werden?
Die übliche Umsetzung übermittelt den aktuellen Zustand an ein LLM, bittet um eine strukturierte Antwort und wandelt diese Antwort in einen Branch im Code um. Prinzipiell ist daran nichts falsch. Die offene Frage ist, ob jeder dieser Branch-Punkte tatsächlich ein vollständiges autoregressives Modell erfordert.
Jev ist das erste Modell von TypeSafe AI aus der von dem Unternehmen als „System One“ bezeichneten Reihe, und es verfolgt einen gegensätzlichen Ansatz. Es erzeugt niemals freien Text. Man gibt ihm einen bestimmten Zustand sowie eine Reihe eingeschränkter Fragen, und es antwortet mit typisierten Entscheidungen sowie Wahrscheinlichkeiten. Der Anbieter präsentiert es als Baustein für Software – nicht als Ersatz für ein Chat- oder Reasoning-Modell. LangChain hat eine Integration veröffentlicht, die Jev in Agentenframeworks für Aufgaben wie die Auswahl eines Modells und die Überprüfung von Toolaufrufen verwendet. Beide Produkte waren zum Zeitpunkt der Erstellung neu, daher sollten Sie die aktuellen APIs vor der Nutzung überprüfen. Falls Sie hauptsächlich an den Kostenaspekten dieses Ansatzes interessiert sind, behandelt der Artikel unter Preisgestaltung eines typisierten Entscheidungsrouter vor Frontier LLM-Aufrufen dieses Thema; hier liegt der Fokus auf Verhalten und Latenz.
Entwurf des Vergleichs
Sowohl den Systemen wurde genau eine Frage gestellt, die hier umformuliert wird: Erfordert der Anfrage tatsächlich mehrstufiges Denken, oder handelt es sich um etwas Einfacheres wie eine direkte Abfrage, das Auslesen eines Wertes, eine einfache Berechnung, eine Umformulierung oder eine kleine lokale Bearbeitung?
Die vorgegebenen Anfragen neigten absichtlich zu mehrdeutigen Fällen. Offensichtliche Extreme liefern nur wenig Informationen; das interessante Verhalten eines Routers zeigt sich in der Zone, in der „einfach antworten“ zu „gründlich darüber nachdenken“ wird. Es wurden acht Anfragen von Entwicklern verwendet:
- Wörterbuchabfrage: Warum die Abfrage eines Schlüssels in einem Python-Dictionary typischerweise O(1) ist.
- Liste gegen Menge: Welche der beiden Strukturen eignet sich für eine Sammlung eindeutiger Benutzer IDs.
POST /users/{id}/delete sowie der Frage, ob eine sauberere REST-Struktur möglich ist.Jede Anfrage wurde in jeder der drei Konfigurationen zehnmal ausgeführt:
- Jev, abgefragt über einen
Noul, der die Wahrscheinlichkeit angibt, dass die Anfrage umfangreiche Verarbeitung erfordert.
Das Aufrufbudget ist wie folgt gestaltet.
8 prompts
× 10 repetitions
× 3 conditions
= 240 calls
Jeder Aufruf protokollierte seine Entscheidung, gegebenenfalls die Wahrscheinlichkeit, den Namen des Modells sowie die Round-Trip-Latenz. Es ist wichtig klarzustellen, was das Experiment nicht versucht zu tun: Es gibt keine echten Referenzwerte dafür, wie viel Logik eine bestimmte Anfrage „tatsächlich“ benötigt, daher spielt die Korrektheit keine Rolle. Stattdessen konzentriert sich das Experiment auf drei engere Fragen:
- Ergibt das Entscheidungsmodell und das generative Modell ähnliche Routenentscheidungen?
Die wichtigsten Erkenntnisse stammten von den grenzwertigen Anfragen, nicht von denen mit offensichtlicher Komplexität.
Drei Implementierungen derselben Entscheidung
Sämtliche drei Konfigurationen wurden in Python mit LangChain entwickelt.
Jev mit einem einzigen Noul
Ein Noul modelliert eine binäre Aussage, gibt aber anstelle einer sofortigen Entscheidung für „Wahr“ oder „Falsch“ eine Wahrscheinlichkeit zurück. Jev erhielt die Anfrage des Entwicklers als seinen Zustand sowie einen Noul, der die Frage enthält. Im Überblick sieht die Definition der Frage so aus:
Noul(
instructions="""
Does this request require substantial multi-step reasoning
rather than a direct lookup, extraction, simple calculation,
rewriting task, or small localized edit?
"""
)
Die Antwort ist einfach eine Zahl, zum Beispiel:
0.86
Der Wert gibt die Wahrscheinlichkeit an, dass die Aussage zutrifft:
P(requires substantial reasoning) = 0.86
Zur Vergleichbarkeit von Jev mit der binären LLM-Struktur gilt eine Wahrscheinlichkeit von 0,5 oder mehr als True.
GPT-5.6 Sol gibt seine eigene Wahrscheinlichkeit an
Als generativer Baseline wurde ChatOpenAI über LangChain verwendet, wobei ein Pydantic-Modell die Ausgabestruktur begrenzt. Die Grenzwerte Field(ge=0,0, le=1,0) stellen sicher, dass die Zahl zumindest im gewünschten Bereich liegt; sie sagen jedoch nichts darüber aus, ob sie sinnvoll ist.
class ReasoningProbability(BaseModel):
requires_reasoning: bool
probability: float = Field(ge=0.0, le=1.0)
Hier musste das Modell sowohl ein Urteil als auch eine Schätzung darüber liefern, wie wahrscheinlich ein „Ja“ ist. Dieser Unterschied verdient Aufmerksamkeit. Jevs Ausgabe ist das, wofür das Modell konzipiert wurde. Die Zahl der LLM ist ein von ihr generierter Text, da das Schema einen Float erfordert – es gibt keine Garantie, dass sie eine interne Wahrscheinlichkeit widerspiegelt. Die Behandlung beider Zahlen als derselbe Quantitätstyp ist eine Annahme, keine Selbstverständlichkeit.
GPT-5.6 Sol wurde in ein boolesches Modell gezwungen
In der dritten Konfiguration wurden alle Verweise auf Wahrscheinlichkeit entfernt, und dasselbe Modell wurde nach einem einzigen Feld gefragt:
class ReasoningBinary(BaseModel):
requires_reasoning: bool
Dadurch bleiben drei unterschiedliche Signale übrig: eine native Wahrscheinlichkeit sowie zwei generative Varianten.
Jev
→ native probabilistic decision
GPT-5.6 Sol
→ generated probability + decisionGPT-5.6 Sol
→ forced binary decision
Was die 240 Aufrufe zeigten
Drei Muster traten auf:
- Jev erreichte die begrenzte Entscheidung deutlich schneller.
- Bei Anfragen, die eindeutig eine Abwägung erforderten, stimmten die Systeme meist überein; sie unterschieden sich in der Nähe der Grenze.
- Bei einer grenzwertigen Anfrage schwankte die vom LLM selbst gemeldete Wahrscheinlichkeit bei identischen Aufrufen stark.
Latenz: Zehntel von Sekunden gegenüber Sekunden
Messt man den durchschnittlichen Hin- und Rückwegszeitraum, antwortete Jev in 128,8 ms pro Entscheidung. GPT-5.6 Sol benötigte 2.828,1 ms, um eine Wahrscheinlichkeit zurückzugeben, und 4.072,1 ms im rein binären Modus. Das ist etwa 22 Mal langsamer bei der Variante mit Wahrscheinlichkeiten und 32 Mal langsamer bei der booleschen Variante.
Betrachten Sie diese Zahlen eher als Momentaufnahme denn als Vergleichswert. Die Latenz einer gehosteten API hängt von der Belastung des Anbieters, der Modellversion, der Region sowie dem Netzwerkpfad ab. Der Größenordnung nach ist das die nützliche Information: Wenn es sich um eine einzige, eingeschränkte Entscheidung handelt, erfordert das Starten eines allgemeinen Generierungsmodells weitaus mehr Ressourcen, als die Aufgabe benötigt.
Das rein binäre Ergebnis ist eine Kuriosität, die man beachten sollte. Der Wunsch nach weniger Ausgabefeldern machte den Aufruf nicht schneller – im Gegenteil, er war sogar langsamer. Ein einziger kleiner Test reicht nicht aus, um den Grund zu erklären, doch er erinnert daran, dass die Gesamtlatenz von LLMs vor allem durch Faktoren bestimmt wird, die über die Anzahl der sichtbaren Ausgabetoken hinausgehen, wie beispielsweise Warteschlangenprozesse, Vorausfüllungen sowie jegliche verborgenen Überlegungsprozesse des Modells vor der Antwort.
Übereinstimmung bei extremen Fällen, Divergenz bei einfachen Aufgaben
Auf den offensichtlich komplexen Anfragen stimmten das Redis-Ersatzsystem sowie die aufgeteilten Microservices überein und bewerteten das Bedürfnis an Überlegungsprozessen als hoch. Bei den einfacher erscheinenden Anfragen öffnete sich die Lücke. Bei Aufgaben wie Wörterbuchabfragen, Vergleichen von Listen und Mengen sowie Fragen zur REST-Design ermittelte GPT-5.6 Sol Wahrscheinlichkeiten nahe Null, während Jev diese deutlich näher im mittleren Bereich ansetzte.
Die Überprüfung des REST-Designs war das deutlichste Beispiel:
Die Anfrage fordert eine Kritik an POST /users/{id}/delete sowie eine bessere RESTful-Alternative.
Jevs durchschnittliche Wahrscheinlichkeit lag bei 0,551, etwas über der Schwelle von 0,5. GPT-5.6 Sol lag bei 0,071. Es handelte sich dabei nicht um Rauschen an der Schwelle: In allen zehn Durchläufen klassifizierte Jev die Anfrage als auf logisches Denken angewiesen, während Sol in allen zehn Durchläufen beider LLM-Systeme dies nicht tat.
Das macht Jev jedoch noch nicht richtig. Ohne eine gelabelte Referenzwahrheit kann man nicht sagen, welche Beurteilung besser ist. Es zeigt jedoch, dass die beiden Signale nicht austauschbar sind und sich genau in dem Bereich unterscheiden, in dem ein Router am empfindlichsten auf die Definition seiner Grenzen reagiert. Wenn man eine Entscheidungsquelle durch eine andere ersetzt, sollte man mit Änderungen im Routing genau bei den Anfragen rechnen, bei denen man am wenigsten sicher ist.
Zwei Zahlen zwischen null und eins, die sich unterschiedlich verhalten
Durch die Wiederholung jeder Anfrage zehnmal wurde die Stabilität sichtbar. Die meisten Anfragen ergaben von beiden Systemen recht konsistente Ergebnisse. Die Ausnahme bildete die Anfrage, zwischen einem Queue-System und einem Pub/Sub-System für Bestellbenachrichtigungen zu wählen.
In zehn identischen Aufrufen lag die von GPT-5.6 Sol selbst gemeldete Wahrscheinlichkeit im Bereich von etwa 0,28 bis 0,90, während die Werte von Jev eng beieinander blieben. Die binäre LLM-Konfiguration antwortete in neun der zehn Durchläufe mit True; somit waren die Urteile zwar nicht konstant, was die angegebene Zuverlässigkeit betrifft, dennoch recht stabil.
Die Erklärung ist strukturell bedingt. Beide Systeme liefern etwas, das als Wert in [0, 1] dargestellt werden kann, doch die dahinterliegenden Prozesse unterscheiden sich. Bei Jev ist die Wahrscheinlichkeit die native Ausgabe des Modells für eine begrenzte Entscheidung. Beim LLM handelt es sich um eine Tokenfolge, die erzeugt wird, weil der Prompt eine Schätzung verlangt, und das Sampling kann von Ausführung zu Ausführung auf ganz unterschiedliche Zahlen führen. Bei dieser Aufgabe verhielt sich die vom LLM selbst gemeldete Wahrscheinlichkeit nicht zuverlässig wie die Ausgabe eines für probabilistische Entscheidungen konzipierten Modells. Wenn Sie planen, einen solchen Wert als Schwellenwert zu verwenden, sollten Sie vor dem Vertrauen darauf seine Varianz bei wiederholten Aufrufen messen.
Umwandlung der Wahrscheinlichkeit in einen LangChain-Router
Die Vergleichsergebnisse motivierten einen praktischen Test: Verwendung von Jevs Wahrscheinlichkeit zur Routierung echter Anfragen zwischen zwei OpenAI-Modellen.
- GPT-5.6 Luna kümmert sich um Anfragen, bei denen kein umfangreiches Reasoning erforderlich ist.
Jev wählt niemals direkt ein Modell aus. Es beantwortet dieselbe Noul-Frage des Experiments, ob die Anfrage umfangreiche mehrstufige Überlegungen erfordert, und gibt eine Wahrscheinlichkeit wie 0.54 zurück, was als P(requires substantial reasoning) = 0.54 gelesen wird.
Anschließend prüft der Anwendungscode diesen Wert gegen einen in herkömmlichem Python definierten Schwellenwert:
REASONING_THRESHOLD = 0.65
Auch der eigentliche Branch ist äußerst einfach gestrickt:
if reasoning_probability >= REASONING_THRESHOLD:
model = powerful_model
else:
model = fast_model
Der Schlüssel liegt in der Arbeitsteilung. Jev liefert die Wahrscheinlichkeit; die Anwendung entscheidet, was damit gemacht wird. Bei einem Schwellenwert von 0.65 wird eine Bewertung von 0.54 an Luna und eine Bewertung von 0.86 an Sol weitergeleitet. Die Richtlinie ist explizit, deterministisch und kann in einem Code-Diff überprüft werden, während das semantische Urteil beim Modell bleibt.
Der gesamte Ablauf sieht wie folgt aus:
User request
↓
Jev
↓
P(requires substantial reasoning)
↓
Python threshold = 0.65
↙ ↘
Luna Sol
Eine Anmerkung zu diesem Schwellenwert: 0,65 dient nur zur Veranschaulichung und ist nicht fein abgestimmt. Er wurde gewählt, damit in einer kleinen Demo die offensichtlich einfachen Anfragen auf eine Seite und die komplexeren Fragen zur Gestaltung sowie Architektur, die höhere Werte erzielten, auf die andere Seite gelangen. In der Produktion würde man ihn anhand einer größeren, beschrifteten Datensammlung empirisch auswählen und dabei zwei verschiedene Fehlerfaktoren abwägen: den Einsatz des teuren Modells bei einer einfachen Anfrage sowie den Versand einer wirklich schwierigen Anfrage an das weniger leistungsstarke Modell. Diese Kosten sind selten symmetrisch, weshalb der beste Schwellenwert selten 0,5 ist.
Wie sich der Router verhalten hat
Sechs Anfragen wurden durch den Router geleitet – von einer einfachen Berechnung bis hin zu einem Problem im Bereich der mehrregionalen Architektur. Die meisten Ergebnisse entsprachen der Intuition. Die Berechnungs- und Umformungsaufgaben erzielten sehr niedrige Werte und wurden an Luna weitergeleitet; die umfangreichen Architekturfragen erzielten hohen Werte und wurden an Sol weitergeleitet.
Die informativen Fälle lagen dazwischen:
- die Erklärung zur Wörterbuchabfrage erhielt eine Bewertung von 0,46
- die Überprüfung der REST API erhielt eine Bewertung von 0,54
- die Frage zu Queue versus Pub/Sub erhielt eine Bewertung von 0,86
Weil Jev eine kontinuierliche Bewertung statt eines festen Labels „einfach“ oder „schwierig“ zurückgibt, wird die Aggressivität bei der Routung zu einer separaten, anpassbaren Entscheidung. Bei 0,65 wurde die REST-Überprüfung an Luna und die Frage zu Queue versus Pub/Sub an Sol weitergeleitet. Das Anheben des Schwellenwerts würde weniger Anfragen an das größere Modell senden und Kosten sparen; das Senken des Schwellenwerts würde die Wahrscheinlichkeit verringern, schwierige Anfragen unzureichend zu bearbeiten. Das Urteil des Modells ändert sich nicht, wenn man den Schwellenwert verschiebt, was bedeutet, dass man die Richtlinien auch dynamisch anpassen kann, ohne etwas erneut abfragen zu müssen.
Beschränkungen dieses Experiments
Halten Sie die Aussagen im Verhältnis:
- Acht Anfragen können kein Modell im Allgemeinen charakterisieren, und die Frage der Kennzeichnung ist an sich subjektiv.
- Auflösung und Kalibrierung wurden nicht gemessen. Der Test vergleicht Verhalten, Konsistenz und Latenz, nicht Richtigkeit.
- Evs Wahrscheinlichkeiten sowie die vom LLM selbst gemeldeten Werte sollten nicht als statistisch gleichbedeutend angesehen werden.
- Die Latenzwerte hängen vom Anbieter sowie von den Bedingungen zum Zeitpunkt des Tests ab.
Eine gründlichere Untersuchung würde ein größeres, gekennzeichnetes Datensatz verwenden und den Router von Anfang bis Ende bewerten: Routing-Auflösung, Kalibrierung, Qualität der Ergebnisse, Kosten sowie Empfindlichkeit gegenüber verschiedenen Schwellenwerten.
Wann sich ein separates Entscheidungsmodell lohnt
Für eine kleine Anwendung ist es oft völlig ausreichend, einem LLM die Routenplanung zu überlassen; ein zusätzlicher Aufruf macht selten etwas aus. Die Situation ändert sich, wenn ein Agent Schritte zur Routenplanung, Informationsabrufung, Validierung und Tool-Überprüfung durchführt. Viele dieser Schritte sind begrenzte Urteile, und wenn jeder von ihnen zu einem weiteren mehrsekündigen generativen Aufruf wird, verlangsamt sich der Agentenzyklus und wird aufgrund von Faktoren, die nichts mit der eigentlichen Arbeit zu tun haben, teurer.
Eine klare Trennung der Verantwortlichkeiten sieht so aus:
- Ein Entscheidungsmodell kümmert sich um begrenzte semantische Urteile und gibt eine Wahrscheinlichkeit zurück.
- Der Anwendungscode ist für Schwellenwerte, Richtlinien und Entscheidungsbäume verantwortlich.
- Das LLM übernimmt das offene Denken und Schreiben.
Ein leistungsstarkes LLM könnte all diese Aufgaben bewältigen, doch das zwingt nicht jeden Teil des Systems dazu, denselben Modelltyp zu verwenden – insbesondere dann, wenn Latenzzeit eine Rolle spielt. Die übergeordnete Begründung dafür, Modelle an die jeweilige Aufgabe anzupassen, wird in right-sizing LLMs with routing, retrieval and evaluation erläutert.
Kernpunkte
- In diesem Test betrug die durchschnittliche Reaktionszeit des Entscheidungsmodells etwa 129 ms pro Bewertung, während die generativen Ansätze mehrere Sekunden benötigten.
- Auf nahezu zweideutigen Eingaben waren sich die beiden Systeme konsequent, nicht zufällig, uneinig; daher ändert das Ersetzen eines Signals durch das andere die Routenwahl an den empfindlichsten Stellen.
- Die vom LLM selbst gemeldete Wahrscheinlichkeit kann bei identischen Aufrufen stark variieren (hier etwa zwischen 0,28 und 0,90 für denselben Prompt); prüfen Sie die Varianz, bevor Sie einen Schwellenwert festlegen.