Jev von TypeSafe: Ein Modell, das typisierte Entscheidungen statt Text liefert
Jev verzichtet auf Textgenerierung und liefert typisierte Auswahlen, Bewertungen und kalibrierte Wahrscheinlichkeiten in einem schnellen Aufruf. So funktioniert die API, das fanden Tester heraus und hier stößt sie an Grenzen.
Ein neues Modell von TypeSafe lässt die Textgenerierung komplett weg. Es liefert eine typisierte Entscheidung samt Wahrscheinlichkeit, und das verändert, welche Teile Ihres Codes ein KI-Modell überhaupt besetzen darf.
Das Modell heißt Jev und ist das erste aus einer Reihe, die das Unternehmen System One Models nennt. Der Name lehnt sich an Kahnemans Unterscheidung zwischen schnellem, automatischem und langsamem, bedachtem Denken an. Jev übernimmt die schnelle Hälfte, die bedachte bleibt bei großen Sprachmodellen.
Der Ankündigungspost auf typesafe.ai kletterte auf Hacker News auf fast tausend Punkte und sammelte über 300 Kommentare, von denen etwa die Hälfte über den Titel stritt. Es klingt nach dem nächsten Start eines kleinen, schnellen, billigen Modells, ist es aber nicht. Jev schreibt überhaupt nicht, eine Textausgabe gibt es nicht. Deshalb konkurriert es kaum mit den Chat-Modellen, die Sie schon nutzen. Es konkurriert mit einer if-Anweisung.
Die if-Anweisung, für die sich alle ständig entschuldigen
Fast jede Pipeline hat eine faule Stelle. Irgendwo in der Mitte muss eine Ermessensentscheidung fallen. Soll dieses Ticket vorgezogen werden? Klingt diese Antwort unhöflich? Lohnt es sich, diese Zeile zu behalten?
Jahrelang wurde diese Stelle mit Regeln gefüllt: Keyword-Listen, Regexe, ein Schwellenwert, der an irgendeinem Dienstag eingestellt und nie wieder angefasst wurde. All das bricht, sobald ein Kunde höflich, aber wutentbrannt schreibt.
Also haben Teams dort stattdessen ein LLM eingesetzt. Das funktioniert, ruiniert aber die Pipeline. Eine einzelne Entscheidung kann rund acht Sekunden dauern, und das JSON-Parsing scheitert in Zeile vierhundert. Pro Element über einen großen Datensatz oder in einer Schleife lässt sich das nicht laufen lassen, und schon gar nicht dort, wo ein Nutzer auf das Ergebnis wartet.
Intelligenz war nie das Problem
Der eigentliche Schmerz ist die Platzierung, und der hat wenig damit zu tun, dass Modelle zu dumm für die Aufgabe wären. Die klügsten Modelle sitzen an den Rändern der Software, während die innere Schleife weiterhin voller Regexe steckt.
Was TypeSafe ausgeliefert hat
Der Gründer fasst es in einem Satz zusammen: ein Funktionsaufruf mit Frontier-Intelligenz, der unstrukturierten Zustand entgegennimmt und typisierte, probabilistische Entscheidungen zurückgibt.
Sie übergeben einen state, etwa ein Support-Ticket, ein Dokument oder einen als Text serialisierten Spielframe, dazu ein Dictionary mit Fragen. Zurück kommen typisierte Antworten. Es gibt nur drei Fragetypen, und das ist die gesamte Oberfläche:
- Choice wählt eine Option aus einer Menge. Zurück kommen die Auswahl, eine Wahrscheinlichkeit pro Option und ein Konfidenzwert.
- Score bewertet etwas anhand geordneter, beschriebener Stufen und liefert dieselben Werte.
- Noul ist eine Ja/Nein-Frage, beantwortet als Wahrscheinlichkeit, dass die Antwort Ja lautet.
Alle Fragen eines Aufrufs werden parallel ausgewertet, jede für sich, gegen denselben Zustand in einem Durchlauf. Deshalb sagt TypeSafe, dass zusätzliche Fragen die Antwortzeit kaum verändern. Bezahlt wird pro Aufruf, nicht pro Frage.
Die angegebene Latenz liegt end-to-end zwischen 70 ms und 500 ms, der Preis bei $42 pro Milliarde Input-Tokens, Output ist kostenlos. Ob diese Zahl bedeutet, was sie zu bedeuten scheint, klären wir weiter unten.
Die gesamte API
Der Quickstart beginnt mit einem einzigen Import:
from typesafe_sdk import Choice, Noul, Score, TypeSafeClient
Dann geht ein Support-Ticket hinein, und drei Entscheidungen kommen zurück:
client = TypeSafeClient()ticket = "Hi, I've been trying to connect my Stripe account for 3 days and it keeps failing. I'm losing sales. Please help ASAP."response = client.system_one(
state=ticket,
questions={
"department": Choice(
instructions="Which team should handle this",
criteria={
"billing": "Payment or subscription issues",
"technical": "Bugs or integration problems",
"sales": "Pricing or account questions",
},
),
"frustration": Score(
instructions="How frustrated the customer appears",
criteria=[
"Calm, just stating facts",
"Frustrated but civil",
"Very angry, strong language",
],
),
"is_urgent": Noul(
instructions="The message conveys urgency or time-sensitivity",
),
},
)
Kein Prompt-Engineering, keine Anweisung „antworte nur mit gültigem JSON“ und kein Retry-Wrapper. Drei Entscheidungen kommen in einem Roundtrip. SDKs für Python und JavaScript sitzen auf einem einzigen POST-Endpunkt.
Der Teil, der verändert, wie Sie Code schreiben
Eine LLM-Antwort kommt mit derselben flachen Gewissheit daher, ob das Modell etwas weiß oder nur rät. Jev liefert stattdessen eine Verteilung.
Die Trainingsmethode heißt RLCD, kurz für Reinforcement Learning for Calibrated Decisions, und soll erreichen, dass diese Wahrscheinlichkeiten abbilden, wie oft das Modell tatsächlich richtig liegt. Damit können Sie nach Zweifel verzweigen:
- Über 0.9 wird das Element automatisch geroutet.
- Zwischen 0.6 und 0.9 geht es an ein größeres Modell.
- Darunter landet es bei einem Menschen.
Diesen Zweig wollten viele Teams seit Jahren. Bisher haben sie ihn mit der selbst gemeldeten Konfidenz eines LLM vorgetäuscht, die ungefähr so viel Vorhersagekraft hat wie Astrologie.
Was Tester am ersten Tag gemacht haben
Frühe Nutzer haben eine Reihe von Experimenten durchgeführt, und eines davon zeigt das Wesen des Produkts besser als jede Benchmark-Tabelle. Ein Autor eines Medienunternehmens gab Jev alle 27 seiner veröffentlichten Artikel plus 10 Fälschungen, die bewusst im KI-Stil geschrieben waren. Er stellte 21 parallele Fragen zu typischen Merkmalen maschinell erzeugter Texte. Insgesamt waren das 777 Entscheidungen über 37 Dokumente. Alle kamen in weniger als 0.7 Sekunden zurück und kosteten etwa ein Viertel Cent.
Der CEO des Unternehmens legte mit vier Prüfungen über 12 Textstellen nach, direkt gegen ein Frontier-LLM. Jev brauchte im Median 0.35 Sekunden pro Textstelle, das LLM 8.83. Das ist etwa 25-mal schneller und nach ihrer Rechnung rund 580-mal günstiger.
Die Doom-Demo
Eine Demo hat es für die Hacker-News-Leute schließlich klick machen lassen. TypeSafe ließ Jev Doom spielen. Es las keine Pixel, sondern bekam den Spielzustand als strukturierten Text, mit etwa zehn Anfragen pro Sekunde. Der Ingenieur, der das gebaut hat, machte sich angeblich Sorgen um diese Anfragerate, die etwa $7 pro Stunde kostet.
Eine KI mitten in der Spielschleife ist der ganze Pitch, buchstäblich umgesetzt.
Wo es scheitert
Die Startseite verspricht „Zero Hallucinations“, und genau diese Behauptung verdient den meisten Widerspruch. Garantiert ist nur, dass die Ausgabe Ihrem Schema entspricht, ein Choice landet also immer auf einer Ihrer Optionen. Richtig zu liegen ist etwas anderes. Jev kann eine gültige, selbstbewusst falsche Antwort liefern, und der Hacker-News-Thread hat das ausführlich festgestellt.
Das Experiment des Autors bestätigt das. Im Testset waren sieben Fehler versteckt. Jev fand sechs und übersah einen: einen Absatz über einen gemeinsamen Kalender, mit dem Eltern und Personal „gemeinsam unterrichten“. Das Vergleichs-LLM bemerkte ihn. Sein eigenes Urteil war offen: Bevor es in Produktion geht, sollte man die Genauigkeit sorgfältiger testen.
Auch die harten Grenzen sind real:
- Das Kontextfenster umfasst 32k Tokens, damit fällt die Arbeit mit ganzen Repositories weg.
- Ein Choice hat höchstens 255 Optionen.
- Bildeingaben gibt es noch nicht.
- Die Architektur wird unter Verschluss gehalten. Es gibt kein Paper und keine unabhängige Bewertung von RLCD, nur frühe Erfahrungsberichte.
Der Preis ist nicht der Tausch, den Sie erwarten
$42 pro Milliarde Input-Tokens wirkt neben einem Frontier-Modell absurd günstig, aber die Einheit ist eine andere. Sie kaufen Entscheidungen, und davon treffen Sie weit mehr, als Sie je LLM-Aufrufe gemacht haben. Der niedrige Preis pro Token ist genau das, was zehn Aufrufe pro Sekunde möglich macht. Von Ihrer aktuellen Rechnung lässt er sich nicht einfach abziehen.
Außerdem ist es Early Access mit Warteliste, Sie lesen also womöglich davon, bevor Sie es ausprobieren können.
Lohnt es Ihre Aufmerksamkeit?
Ja, aber nicht wegen der Geschwindigkeitsfaktoren. Jev fällt auf, weil es ehrlich abgegrenzt ist. Es chattet nicht, denkt nicht laut nach, erklärt sich nicht und tut auch nicht so.
Seine einzige Aufgabe ist, unordentliche Eingaben in eine typisierte Entscheidung zu verwandeln, die Ihr Compiler prüfen kann, und das schnell genug, um in einer Schleife zu sitzen. Vielleicht steckt in Ihrem Produkt ein Chat-Modell an einer Stelle, die eigentlich eine Entscheidung braucht. Für diesen Fall bietet Jev eine wirklich andere Lösung. Rechnen Sie damit, eher um den Konfidenzwert herum zu bauen als um die Latenz.
Testen Sie es mit Ihren eigenen Daten, bevor es in die Nähe von etwas Wichtigem kommt, das raten frühe Tester immer wieder. Viele bezweifeln ohnehin, dass ein einziges Allzweck-Textmodell das richtige Werkzeug für enge Aufgaben ist, und das hier ist der erste ernsthafte Versuch, es anders zu machen.