Warum ein Jev, das nicht chatten kann, zu einem Agent passt

Einem Agent fehlt oft ein Urteil, das direkt in einen Zweig gehen kann, nicht noch eine Strecke langen Textes. Der Text erklärt die drei Fragen, was das Workflow-Eval vergleicht, und warum ein heißer Pfad einen Chat nicht abwarten kann.

Folkbench folkbench.com

Mitautor: folkbench.com (Folkbench ist eine überprüfbare Bewertungs- und Auswahlplattform für KI-APIs, Modelldienste und verwandte Sites. Sie nutzt veröffentlichte Angaben zu Diensten, Preisen, Verfügbarkeit, Latenz und Evidenzfenstern, damit Nutzer Wege vergleichen und einen davon wählen können.)

Zehn Texte in dieser Reihe:

Was einem Agent oft fehlt, ist nicht noch eine Strecke langen Textes. Es ist ein Urteil, das direkt in den Kontrollfluss eingehen kann. Die üblichen sind, ob dieser Alarm geschlossen bleibt, ob diese Rechnung bezahlt wird, ob dieser Trace einen Menschen braucht und ob der nächste Satz im Kundendienst eskalieren soll. Diese Knoten sind nicht dazu da, dass das Modell eine Analyse schreibt. Der Code braucht einen Wert, den er vergleichen und verzweigen kann. Das tut Jev.

Die Formulierung von TypeSafe meint einen Funktionsaufruf mit Spitzenintelligenz. Zustand kommt hinein. Eine typisierte Wahrscheinlichkeitsentscheidung geht hinaus. Es erzeugt keine Strings. Der Satz für einen Menschen und das Urteil für ein Programm sind nicht derselbe Ausgang.

Zuerst die Ausgabe festlegen

Die Ausgabe der aktuellen großen Modelle ist ein String. Software, die weiterlaufen muss, muss ihn trotzdem zerlegen, prüfen und gegen Abdriften sichern. Ein Feld zu viel taucht auf. Der Absatz sieht vollständig aus, und das Enum passt nicht. Ein Mensch im Chat-Fenster merkt es und fragt noch einmal. Der Code merkt es nicht und läuft mit dem Fehler weiter. Mehrere Aufrufe tief vergraben, kann ein klügeres Modell es nicht zurückholen.

Jev legt den Ausgaberaum im Voraus fest. Sie sagen, was es zurückgeben darf, und es vergibt Wahrscheinlichkeit nur in diesem Raum. Ein Typfehler kann mathematisch nicht vorkommen. Es kann keine Form zurückgeben, die Sie nicht definiert haben. Das ist nicht dasselbe, wie dass das Urteil stimmt. Die Wahrscheinlichkeit kann sich zur falschen Seite neigen, und die Option kann die falsche sein. Typsicherheit schließt die Form, nicht Richtig und Falsch. Sobald die Form festliegt, lassen sich die Zweige danach schreiben. Sie müssen einen Wert nicht erst aus einem Absatz fischen.

Es gibt nur drei Fragen.

Noul ist Ja-Nein. Das Modell gibt eine Wahrscheinlichkeit von 0 bis 1. Nahe bei 1 ist Ja. Nahe bei 0 ist Nein. Nahe bei 0.5 ist unsicher. Es hängt keine eigene Konfidenz an. Die Wahrscheinlichkeit ist das Signal. Choice ist die Einfachauswahl. Sie listen die Optionen zuerst, mit einer Obergrenze von 255. Zurück kommen die gewählte Option, die Verteilung über jede Option und eine Konfidenz. Der Code benutzt diese Verteilung, um zu entscheiden, ob er handelt oder den Fall einem Menschen gibt. Score sind die Stufen. Die Stufen laufen von 2 bis 10, und Sie schreiben, was jede Stufe bedeutet. Zurück kommen eine Punktzahl, die Verteilung über die Stufen und eine Konfidenz. Die Punktzahl kann zwischen zwei Stufen landen, als Position auf der Skala.

Ein Ja-Nein wird als Bedingung geschrieben. Einfachauswahl und Stufen sind anders: Die erste sieht, auf welcher Option es gelandet ist, die zweite legt an die Punktzahl eine Schwelle. Eine gute Frage bleibt eng. Ein Urteil, das eine fachkundige Person eine Sekunde nach dem Lesen des Materials fällen kann, ist die Art, die man ihm gibt. Ob der Kunde eine Erstattung verlangt, ist so eine Frage. Den ganzen Brief zu lesen und dann die beste Handlung zu entscheiden, ist es nicht. Der zweite Satz will langsames Denken. Teilen Sie, dann fragen Sie. Die geteilten Fragen sehen denselben Zustand, unabhängig voneinander, und kommen in einer Anfrage zusammen zurück. Die Gewichte bleiben im Code. Ändert sich die Richtlinie, ändern Sie die Zahlen. Sie schreiben nicht den ganzen Prompt neu.

Die Gabelung hält Menschen auf

Was Menschen wirklich aufhält, ist oft ein Knoten dieser Form. Ein Alarm kommt mit Aufzeichnungen, die die Maschine schon hat, und der Schluss ist: schließen, an eine Analystin oder einen Analysten geben oder jetzt isolieren. Eine Rechnung hängt an einer Bestellung und einem Lieferbeleg, und jemand muss entscheiden: zahlen, halten oder zurückschicken. Ein Kundendienst-Agent ist fertig, die Werkzeugaufrufe stehen alle im Trace, und jemand muss entscheiden, ob dieser Trace angesehen wird und wie bald. Der Kunde schreibt wieder, und Thread und Kontostand sind beide da. Wie der nächste Satz weitergehen soll und ob eskaliert werden soll, ist dieselbe Form von Frage.

Der Teil, den Regeln einfrieren können, ist Code. Brüchig sind die Ausnahmen, die sich nicht zu Ende schreiben lassen. Der Beleg passt, der Grund ist vage, und ein Schritt im Trace sieht schief aus. Handgeschriebene Logik zerspringt daran. Sie stopfen die ganze Richtlinie in einen Prompt und lassen das Modell sie einmal durchdenken, und Sie schreiben weniger Bedingungen. Der Ausgang wird wieder ein Stück Text. Damit Text in den Kontrollfluss kommt, schreiben Sie noch eine Schicht zum Zerlegen. Diese Schicht kann für sich falsch sein.

Das Workflow-Eval von TypeSafe misst diese Art des Verbindens. Die Eval teilt eine Aufgabe in viele enge Fragen. Was der Code entscheiden kann, entscheidet der Code. Das Modell beantwortet nur die Urteile, die der Code nicht festlegen kann. Die vier öffentlichen Abläufe sind ein Sicherheitsvorfall, die Beobachtbarkeit von Agent-Traces, die Bearbeitung von Rechnungen und der Kundendienst. Unter demselben Ablauf ist ein Modell auf dem Workflow genauer, als die ganze Richtlinie in einen Prompt zu stopfen, und es kostet weniger und braucht weniger Zeit. Über die vier Aufgaben gemittelt bewegen sich die geprüften Modelle in diese Richtung.

Die Handlungen danach folgen der Wahrscheinlichkeit, nicht einem Etikett, das zugeschlagen wurde. Das Ergebnis, das das System verlässt, ist trotzdem eine diskrete Handlung. Die Technik in der Mitte muss jedes Mal auf dieselbe Weise gemacht werden.

Die Eval misst Nähe

Diese Eval streitet nicht mit Ihnen darüber, ob der Ablauf selbst falsch geschrieben wurde. Sie nimmt an, dass das Harness richtig ist. Die Referenzantwort ist kein Gold-Label, das Frage für Frage von Hand markiert wurde. GPT-6 Astra und Claude Fable 5.1 beantworten jede Frage unter high thinking, und die zwei Antworten werden gemittelt. Andere Modelle nutzen das voreingestellte Reasoning des Anbieters. Erst wenn der Ablauf festliegt, lassen sie sich vergleichen. Die Eval vergleicht, wie nah ein Modell den Urteilen dieser zwei großen Modelle kommt, dazu Geschwindigkeit und Kosten.

Die Grafik beweist also nicht, dass Jev das Geschäft besser versteht als Astra. Astra und Fable sind hier das Lineal. Jev muss ihren Urteilen nahekommen, und es muss bei Latenz und Kosten eine Lücke öffnen. Wurden die Fragen falsch geteilt, hilft ein näheres Lineal nicht. Die Fragen zu teilen ist die Arbeit der Person, die den Ablauf schreibt.

Jev sitzt weit außen an der Front von „schnell und billig“. Die höheren Vielfachen auf der offiziellen Seite, etwa 193.6-mal schneller und 444.6-mal billiger, sind das hohe Ende dieser Eval. Dieses Vielfache gilt nicht für jeden Aufruf. Die Aufrufe hier liegen näher an der Automatisierungslast, die Sie wirklich ausliefern würden.

Es kommt der Wahrscheinlichkeit auf diesen engen Fragen nach der Teilung nahe, nicht der Schreibweise einer langen Analyse. Jev schreibt diese lange Analyse nicht.

Ein heißer Pfad kann nicht warten

Latenz ist für einen Agent hart. Ein Mensch kann noch 3 Sekunden warten. Sobald sich Schichten um Schichten legen, geht das nicht mehr. Dieselbe Kette hat auch einen Abruf, einen Schreibvorgang in die Datenbank und den nächsten Aufruf, und jeder Hop verbraucht dieselbe Zeit. Innerhalb von 70 bis 500 Millisekunden kann ein Urteil auf einem heißen Pfad sitzen. Außerhalb dieses Bereichs behandelt der Aufrufstapel es als blockierend.

Im Gespräch mit einem Menschen brauchen aktuelle Spitzenmodelle oft von 3 Sekunden bis über 300 Sekunden von Ende zu Ende. Diese Geschwindigkeit ergibt Sinn für einen Copilot oder für einen Coding-Agent, dem ein Mensch zusieht. Als Bedingung auf einem heißen Pfad ergibt diese Geschwindigkeit keinen Sinn. Jev stößt keinen Satz Token für Token aus. Die Wahrscheinlichkeiten, die zurückkommen sollen, kommen zusammen an. Daher kommt die Geschwindigkeit.

TypeSafe benutzt Jev auch zum Prüfen. Prompts, Reasoning-Spuren und Ausgaben anderer Modelle bewertet Jev, und es wirkt auch als Leitplanke und sucht nach Jailbreaks. Die Erzeugung bleibt beim Chat-Modell. Ob dieses Tor passiert wird, entscheidet ein Modell, das keine Strings erzeugt. Das ist ein Gelenk in einem Agent, kein Chat. Wenn das Nicken und die Prüfung noch auf langem Text sitzen, müssen Sie ein anderes Programm finden, das ihn liest. Jev schließt das Ergebnis zu Wahrscheinlichkeiten und Stufen, und die Prüfung lässt sich als Code schreiben.

Der Satz, der für den Nutzer geschrieben wird, bleibt Aufgabe des Chat-Modells. Jev nimmt diesen Satz nicht. Es nimmt das Routing davor und die Prüfung danach. Was einem Agent hier fehlt, ist nicht noch eine, längere Erklärung. Es ist ein Urteil, dessen Typ schon festliegt, sodass der Code damit gehen kann.

Quellen

Reihe