Jev ist schnell und günstig. Der Open-Source-Konkurrent hat jetzt auch bei der Genauigkeit aufgeholt.

Letzte Woche habe ich einem Sprachmodell eine Anfrage gestellt, und die Antwort war kein Satz. Sie lautete 0,87. So beantwortet das neue Modell Jev von TypeSafe AI Fragen: Man beschreibt eine Situation in einfacher Sprache, stellt eine strukturierte Frage wie „Ist das eine Übereinstimmung?“ und erhält statt eines Fließtexts eine Wahrscheinlichkeit. TypeSafe bezeichnet Jev als „System-1“-Modell, das für schnelle, intuitive Entscheidungen entwickelt wurde, anstatt für das langsame, bewusste Schlussfolgern, auf das Chatmodelle optimiert sind. Ich wollte wissen, ob diese Unterscheidung tatsächlich zutrifft oder nur Marketing ist. Also habe ich es getestet. Dann entdeckte ich einen Open-Source-Konkurrenten, der rasch aufholt, und testete auch diesen. Anschließend untersuchte ich, ob er tatsächlich konkurrenzfähig gemacht werden kann.

Warum das gerade jetzt wichtig ist

Klassifizierungsentscheidungen wie „Ist das Spam?“, „Ist das eine Übereinstimmung?“ oder „Welcher Agent sollte diese Aufgabe übernehmen?“ befinden sich seit jeher in einer schwierigen Zwischenposition. Sie sind zu trivial, um einen vollständigen LLM-Aufruf zu rechtfertigen, und zu komplex, um sie mit traditionellem maschinellem Lernen und einem normalen Budget gut umzusetzen. Die Entwicklung eines eigenen Klassifikators kostet zwischen 10.000 und 1.000.000 US-Dollar. Hinzu kommen jährlich weitere 25 bis 75 Prozent dieser Kosten für die Wartung.

Nehmen wir ein konkretes Beispiel: den Aufbau eines einheitlichen Customer-360-Profils. Einzelhändler arbeiten häufig mit 5 bis 15 verschiedenen Systemen für denselben Kunden: einem Website-Konto, einem Treueprogramm, einem Callcenter-CRM und einem Kassensystem, jeweils mit einer eigenen ID. Die Zusammenführung dieser Daten zu einem einzigen Profil beginnt mit der Entitätsauflösung (Entity Resolution): Für jedes Datensatzpaar muss entschieden werden, ob beide dieselbe Person beschreiben. Genau diese Aufgabe, also die Entscheidung zwischen Übereinstimmung und Nichtübereinstimmung, wird in diesem Benchmark getestet.

Nach der Zuordnung muss der Datensatz in der Regel ein zweites Mal klassifiziert werden, um dem Zielschema zu entsprechen: Privat- oder Geschäftskonto, Produktkategorie, Privat- oder Geschäftsadresse. Reale Projekte zur Identitätsauflösung erfordern allein für die Matching-Logik einen erheblichen Entwicklungsaufwand, zusätzlich zu den Kosten für die Plattform, die ein Unternehmen bereits nutzt. Dabei sind die laufenden Kosten für die Sicherstellung der Genauigkeit bei Änderungen an den Quellsystemen noch nicht berücksichtigt.

Genau darum geht es in diesem Artikel: um Dutzende kleiner, einfach zu formulierender Klassifizierungsentscheidungen, deren zuverlässige Umsetzung jeweils teuer ist.

Eine universell einsetzbare LLM-API erscheint pro Aufruf günstig, bis man feststellt, dass identischer Datenverkehr je nach antwortendem Modell bis zu 43-mal mehr oder weniger kosten kann. Gleichzeitig geben 78 Prozent der Unternehmen an, dass sie noch nicht bereit sind, KI-Agenten einzusetzen, insbesondere weil ihre Kundendaten über verschiedene Systeme hinweg nicht übereinstimmen. Genau diese Lücke sollen Jev und die aufholenden Open-Source-Modelle schließen.

Was Jev tatsächlich macht

Technisch überspringt Jev den Schritt, der Chatmodelle langsam macht. Ein gewöhnliches LLM generiert ein Token nach dem anderen und führt das gesamte Modell für jedes Wort erneut aus. Anschließend muss das aufrufende System den erzeugten Text wieder in eine Entscheidung umwandeln. Die Architektur von Jev verwendet das, was TypeSafe als „Parallel Sampler“ bezeichnet: Ein einziger Vorwärtsdurchlauf erzeugt direkt eine Wahrscheinlichkeitsverteilung über eine kleine, im Voraus festgelegte Menge möglicher Ergebnisse.

Es gibt drei Ergebnistypen. Eine Ja/Nein-Prüfung mit einem einzelnen Konfidenzwert wird Noul genannt. Die Auswahl aus bis zu 255 Optionen, die als vollständige Wahrscheinlichkeitsverteilung zurückgegeben wird, heißt Choice. Eine Bewertung auf einer selbst definierten Skala mit 2 bis 10 beschrifteten Stufen wird Score genannt.

Nehmen wir das Beispiel von TypeSafe für den letzten Typ: eine dreistufige Frustrationsskala mit 0 für ruhig, 1 für frustriert und 2 für sehr frustriert. Jev wählt nicht einfach eine Kategorie aus, sondern gibt eine einzelne Zahl wie 1,4 zurück – einen wahrscheinlichkeitsgewichteten Mittelwert dieser Stufen. Ein Wert von 1,4 bedeutet also, dass das Modell eher zu „frustriert“ tendiert, aber auch eine gewisse Wahrscheinlichkeit für „sehr frustriert“ erkennt.

Für das Training verwendet TypeSafe eine Methode namens Reinforcement Learning for Calibrated Decisions. Der Unterschied zu einem gewöhnlichen Chatmodell ist klar definiert. Ein Chatmodell wird darauf trainiert, Texte zu erzeugen, die von menschlichen Bewertern positiv beurteilt werden, nicht darauf, dass seine angegebene Sicherheit mit der tatsächlichen Häufigkeit korrekter Antworten übereinstimmt. Jev wird umgekehrt trainiert: Seine Wahrscheinlichkeiten werden direkt anhand der tatsächlichen Ergebnisse optimiert. Wenn es also 70 Prozent angibt, sollte es bei vergleichbaren Vorhersagen in ungefähr 70 Prozent der Fälle richtig liegen.

Diese Eigenschaft wird Kalibrierung genannt und mithilfe einer Kennzahl namens Expected Calibration Error gemessen: Vorhersagen werden nach Konfidenzniveau gruppiert. Anschließend wird geprüft, ob die tatsächliche Genauigkeit innerhalb jeder Gruppe mit dem jeweiligen Konfidenzniveau übereinstimmt. Das ist eine überprüfbare Aussage und nicht nur ein Marketingversprechen. Allerdings weisen auch die eigenen Dokumentationen von TypeSafe ausdrücklich darauf hin, dass die Kalibrierung für Gruppen von Vorhersagen gilt, nicht für eine einzelne Antwort.

TypeSafe übernimmt die Bezeichnung „System 1“ aus der Unterscheidung des Psychologen Daniel Kahneman zwischen schnellem, intuitivem Denken und langsamem, bewusstem Schlussfolgern. System 1 steht für schnelle Bauchentscheidungen. System 2 bezeichnet das sorgfältige, schrittweise Vorgehen. Auf Jev übertragen bedeutet dies einen einzigen Vorwärtsdurchlauf ohne sichtbare Gedankenkette. Die Chain-of-Thought eines Chatbots würde nach derselben Logik zum System-2-Bereich gehören.

Die Bezeichnung ist ein etablierter Begriff aus dem maschinellen Lernen und wurde nicht eigens für diese Produkteinführung erfunden. Sie stammt aus einer psychologischen Theorie, die selbst umstritten ist: Eine häufig zitierte Kritik argumentiert, dass die klassische Unterscheidung zwischen Typ 1 und Typ 2 weitgehend nicht falsifizierbar sei und die meisten tatsächlichen Denkprozesse Merkmale beider Typen kombinieren. „System 1“ sollte daher als Beschreibung des Verhaltens verstanden werden – ein Durchlauf ohne sichtbaren Schlussfolgerungsprozess – und nicht als Aussage darüber, wie das Modell denkt.

Ein weiterer Punkt sollte klar erwähnt werden: TypeSafe hat nicht bekannt gegeben, wie groß Jev tatsächlich ist. Alle Quellen, die ich gefunden habe, sowohl offizielle als auch unabhängige, beschränken sich auf die Angabe „Transformer-basiert“. Diese Architektur ist außerdem keine exklusive Entwicklung von TypeSafe: Wie der nächste Abschnitt zeigt, implementiert bereits mindestens ein Open-Weight-Modell eine ähnliche Variante desselben Ansatzes und ist klein genug, um seine genaue Parameterzahl anzugeben.

Der Praxistest

Ich habe Jev mit dem Amazon-Google-Produktmatching-Benchmark getestet, einem etablierten Datensatz zur Entitätsauflösung. Dabei geht es darum zu entscheiden, ob zwei Produkteinträge aus unterschiedlichen Katalogen dasselbe Produkt beschreiben. Bei 2.570 ausgewerteten Paaren erreichte Jev eine Accuracy von 95,95 Prozent, eine Precision von 98,76 Prozent, einen Recall von 93,07 Prozent und einen F1-Score von 95,83 Prozent. Das gesamte Experiment, einschließlich einer Untersuchung von 720 Prompt-Aufrufen vor dem eigentlichen Test, kostete bei insgesamt 3.290 Aufrufen 0,0522 US-Dollar. Das sind fünf Cent, nicht die fünfzig Cent, die ich ursprünglich erwartet hatte. (Eine Einschränkung ist allerdings erwähnenswert: 57 Prozent der negativen Paare in diesem Datensatz sind „einfache“, zufällige Nichtübereinstimmungen, beispielsweise eine Maus im Vergleich zu einer Musik-CD. Beschränkt man den Test auf positive Paare und schwierigere negative Paare desselben Herstellers, sinkt die Accuracy auf immer noch starke 94,4 Prozent.)

Einige der tatsächlichen Produktpaare verdeutlichen die Aufgabe. Eine einfache Übereinstimmung: „sony turntable pslx350h“ gegenüber „sony pslx350h belt drive turntable“ – unterschiedliche Formulierungen, dasselbe Produkt. Jev erkannte die Übereinstimmung mit einer Konfidenz von 99 Prozent. Ein schwierigerer Fall ohne Übereinstimmung: „sibelius 4 professional edition“ gegenüber „sibelius compass music composition teaching software“ – derselbe Hersteller, aber tatsächlich unterschiedliche Produkte. Jev identifizierte sie korrekt als Nichtübereinstimmung mit einer Konfidenz von 96 Prozent. Die Prompt-Untersuchung vor dem eigentlichen Test umfasste 24 Varianten und zeigte ein klares Muster. Kurze, einfache Anweisungen, die den vollständigen Datensatz mit Titel, Hersteller und Preis enthielten, schnitten besser ab als ausführliche Anweisungen mit expliziten Regeln für Sonderfälle: 93 bis 97 Prozent Accuracy gegenüber 77 bis 87 Prozent. Das Weglassen von Hersteller und Preis zur Einsparung von Tokens schadete mehr, als es nützte. Dasselbe galt für ausdrücklich formulierte Vorsichtsregeln: Bei einem Testpaar mit „brain builder“ von „core learning“ und einem anders formulierten Produkteintrag desselben Herstellers erkannte der erfolgreichste Prompt-Stil die Übereinstimmung mit 92 Prozent Konfidenz. Ein stärker vorgeschriebener, regelbasierter Prompt übersah sie vollständig und bewertete sie mit 47 Prozent Konfidenz als Nichtübereinstimmung. Dieses Ergebnis zeigte sich während der gesamten Untersuchung: Man sollte dem Modell dieselben Felder geben, die ein Mensch bei einer manuellen Prüfung verwenden würde, und ihm sagen, was es entscheiden soll, nicht wie es darüber nachdenken soll.

Die durchschnittliche Latenz lag bei 0,65 Sekunden pro Aufruf, mit einem p99-Wert von 0,81 Sekunden und keinen Timeouts bei 2.569 Aufrufen. Die Fehler tendieren zur vorsichtigen Seite: 15 falsche Übereinstimmungen gegenüber 89 übersehenen Übereinstimmungen. Jev neigt bei Unsicherheit also eher dazu, „unterschiedlich“ zu sagen, als eine Übereinstimmung zu erfinden. Das sollte man wissen, bevor man es in einem Szenario einsetzt, in dem eine übersehene Übereinstimmung teurer ist als eine fälschlich erkannte – oder umgekehrt.

TypeSafe behauptet in seinem eigenen Marketing, dass Jev bis zu etwa 193-mal schneller und 444-mal günstiger als ein vergleichbares LLM sei, und bezeichnet diese Werte als oberes Ende realistischer Verbesserungen. Was ich bei genau dieser Aufgabe im Vergleich zu Claude Sonnet 5 und Haiku 4.5 tatsächlich gemessen habe, waren 25- bis 51-mal geringere Kosten. Das ist ein kleinerer Faktor als der vom Anbieter genannte, liegt aber dennoch in einer völlig anderen Kostenkategorie.

Der Open-Weight-Konkurrent

Ein interessanterer Vergleich als die Kostenunterschiede gegenüber einem führenden Chatmodell ist der Vergleich mit einem Modell, das auf derselben Grundidee wie Jev basiert, aber kostenlos verfügbar ist. Laya von ConvAI Innovations ist ein Open-Weight-Entscheidungsmodell vom Typ „System 1“. Es verarbeitet dieselbe Art von Eingaben – einen Zustand und typisierte Fragen – und gibt auf dieselbe Weise kalibrierte Wahrscheinlichkeiten zurück. Laut seiner eigenen Model Card ist es sechs- bis achtmal schneller als Jev. Anders als Jev steht Laya unter der Apache-2.0-Lizenz: ein englischsprachiger Checkpoint mit 421 Millionen Parametern, der vollständig auf eigener Hardware läuft, ohne API-Schlüssel und ohne Gebühren pro Aufruf. Ich habe es lokal auf der Apple-Silicon-GPU eines Laptops ausgeführt, ohne Cloud-Instanz, und demselben Test unterzogen.

Um aussagekräftige Ergebnisse mit Laya zu erzielen, war eine wichtige Korrektur notwendig. In der Dokumentation wird der Fragetyp Choice als primäres Muster aufgeführt, aber beim ersten Versuch verwendete ich denselben Score-Fragetyp, der bei Jev funktioniert hatte. Das Ergebnis war nicht besser als ein Münzwurf, mit Konfidenzwerten wie 0,0003 bei Paaren, die eigentlich eindeutig sein sollten. Der Wechsel zu Choice behob das Problem sofort. Die Erkenntnis ist also begrenzt, aber konkret: Für binäre Entscheidungen sollte man bei Laya nicht den Score-Typ verwenden.

Eine zweite Überraschung zeigte sich, sobald das funktionierte, und sie widersprach den Ergebnissen von Jev. Die Einbeziehung von Hersteller und Preis – genau der Felder, die Jev geholfen hatten – senkte die Accuracy von Laya auf dem Tuning-Datensatz auf 50 bis 67 Prozent, kaum besser als zufälliges Raten. Die Reduzierung der Eingabe auf den Produkttitel, also genau das Gegenteil dessen, was bei Jev funktionierte, verbesserte das Ergebnis auf bis zu 86,7 Prozent.

Beim Test mit denselben 2.570 Paaren, anhand derer Jev bewertet wurde, und mit denselben Prüfungen der Label-Integrität erreichte Laya eine Accuracy von 83,89 Prozent, eine Precision von 83,27 Prozent, einen Recall von 84,82 Prozent und einen F1-Score von 84,04 Prozent. Das entspricht einem tatsächlichen Rückstand von zwölf Prozentpunkten gegenüber Jev bei der Accuracy, der auch bei den schwierigeren negativen Paaren desselben Herstellers bestehen bleibt. Auch die Fehler unterscheiden sich: Jevs 15 False Positives gegenüber 89 False Negatives beschreiben ein Modell, das in eine Richtung eher vorsichtig entscheidet. Layas 219 False Positives gegenüber 195 False Negatives beschreiben ein kleineres Modell, das auf beiden Seiten deutliche Fehler macht. Das spricht eher für ein weniger leistungsfähiges Modell als für eines, das lediglich anders abgestimmt ist.

Layas Stärke liegt nicht in der Genauigkeit, sondern in allem, was auf die eigentliche Entscheidung folgt. Die durchschnittliche Latenz lag bei 28,7 Millisekunden pro Aufruf gegenüber 649 Millisekunden bei Jev – also ungefähr 23-mal schneller. Das entspricht grundsätzlich der Aussage in der Model Card, dass Laya sechs- bis achtmal schneller sei, auch wenn die beiden Messungen nicht ganz dasselbe erfassen: die tatsächliche Ausführungszeit auf lokaler Hardware gegenüber einem Netzwerk-Roundtrip. Der gesamte Test mit 2.570 Aufrufen verursachte 0 US-Dollar an API-Gebühren. Er lief auf einer GPU, die bereits auf einem Schreibtisch stand, anstatt pro Token abgerechnet zu werden. Allerdings berücksichtigen diese 0 US-Dollar weder Hardware- noch Hostingaufwand, die im Preis von Jev bereits enthalten sind. Es handelt sich nicht einfach um „Jev, nur 23-mal schneller“. Es ist ein tatsächlich kleineres, weniger genaues Modell, das zugleich kostenlos, lokal ausführbar und so schnell ist, dass die Latenz praktisch keine Rolle mehr spielt.

Dass die Beschränkung auf den Titel die Ergebnisse verbesserte – genau das Gegenteil dessen, was bei Jev funktionierte –, hatte ich damals als offenen Punkt vorgemerkt, den es sich genauer anzusehen lohnte. Es lohnt sich, darauf zurückzukommen, denn dieser Punkt erweist sich als wesentlich wichtiger als eine bloße Randbemerkung zum Prompt Engineering.

Schließt Fine-Tuning die Lücke tatsächlich?

Laya ist ein Open-Weight-Modell und lässt sich daher nicht nur durch Prompts steuern, sondern auch feinabstimmen. Ich habe es mit Abt-Buy trainiert, einem separaten Produktmatching-Datensatz ohne Überschneidungen mit Amazon-Google, und jede Epoche anhand eines zurückgehaltenen Teils von Amazon-Google selbst validiert. Dadurch blieb der Vergleich aussagekräftig: Der Fortschritt wurde während des gesamten Prozesses am eigentlichen Benchmark gemessen und nicht an einem Ersatzdatensatz.

Vier Konfigurationen wurden getestet. Die erste verwendete vollständige Metadaten mit denselben Feldern für Name, Beschreibung und Preis, die Jev geholfen hatten. Ein zweiter Durchlauf verwendete Layas weniger verbreiteten Fragetyp Noul. Ein dritter verwendete ausschließlich den Produkttitel und griff damit den offenen Punkt aus dem Zero-Shot-Test wieder auf. Ein vierter kombinierte Abt-Buy mit einem zweiten Entity-Matching-Datensatz, um zu prüfen, ob vielfältigere Trainingsdaten hilfreich wären.

Die Variante mit ausschließlich dem Titel gewann eindeutig. Vollständige Metadaten erreichten 88,8 Prozent Accuracy, der kombinierte Datensatz 90,3 Prozent und Noul 86,3 Prozent. Die Titel-only-Variante erreichte 95,3 Prozent Accuracy und einen F1-Score von 95,28 Prozent – nur 0,66 Prozentpunkte hinter Jevs 95,95 Prozent. Gleichzeitig behielt Laya seinen bereits im Zero-Shot-Test vorhandenen Vorteil bei der Latenz von ungefähr dem Faktor 23 sowie seine Grenzkosten von null.

Der Grund für dieses Ergebnis ist konkret. Vollständige Metadaten führten bei 2.270 Testpaaren zu 175 falschen Übereinstimmungen; die Beschränkung auf den Titel reduzierte diese Zahl auf 52, ein Rückgang um 70 Prozent, während sich die Zahl der False Negatives kaum veränderte. Die Produktbeschreibungen von Abt-Buy sind Marketingtexte, und unterschiedliche Produkte derselben Marke verwenden häufig nahezu wortgleiche Beschreibungen – beispielsweise zwei Softwareprodukte desselben Anbieters, deren Texte vom selben Marketingteam verfasst wurden. Ein Modell, das vollständige Beschreibungen verarbeitet, interpretiert diese gemeinsamen Formulierungen als Ähnlichkeitssignal und neigt dazu, unterschiedliche Produkte als identisch einzustufen. Entfernt man die Beschreibung, verschwinden auch diese Störsignale, und übrig bleibt das Feld, das das Produkt tatsächlich identifiziert. Die Zero-Shot-Prompt-Untersuchung hatte dieselbe Schwäche bereits Monate zuvor aufgedeckt. Damit wird sie auf eine zweite, unabhängige Weise bestätigt.

Eine Einschränkung sollte klar genannt werden: Dies wurde ausschließlich beim Produktmatching getestet. Ob das Ergebnis auch bei schwierigeren Fällen gilt, etwa beim Abgleich von Personen oder Organisationen anstelle von Produkten, ist weiterhin offen.

Das Muster über alle hier durchgeführten Tests hinweg: Einfachheit gewinnt. Jevs Prompt-Untersuchung zeigte, dass kurze, einfache Anweisungen besser funktionieren als ausführliche, regelbasierte Varianten. Layas Zero-Shot-Test zeigte dasselbe aus der entgegengesetzten Richtung: Vollständige Metadaten reduzierten die Accuracy auf ein Niveau, das kaum über zufälligem Raten lag, während die Beschränkung auf den Titel die Ergebnisse wieder verbesserte. Das Fine-Tuning durchbrach dieses Muster nicht, sondern bestätigte es auf einer völlig anderen Ebene: Das einfachste Eingabeformat schnitt um sechseinhalb Prozentpunkte besser ab als das informationsreichste. Jev und Laya sind beide System-1-Modelle, bei denen ein einzelner Vorwärtsdurchlauf die Eingabe direkt einer kalibrierten Wahrscheinlichkeit zuordnet, anstatt wie ein Chatmodell differenziert über eine Frage nachzudenken. Zusätzliche Anweisungen und zusätzliche Felder geben einem System-1-Modell nicht mehr Informationen zum Schlussfolgern. Sie erzeugen mehr Störsignale, die es verwirren können. Fortgeschrittenes Prompt Engineering, das bei einem Chatmodell zuverlässig hilft, bringt hier nicht nur keinen Nutzen. Es verschlechtert die Ergebnisse sogar aktiv.

Die andere wichtige Kennzahl: Trainingskosten

Die Accuracy war nicht die einzige Kennzahl, die es sich zu messen lohnte. Auch die Trainingskosten waren wichtig.

Alle vier Konfigurationen konvergierten schnell bei der Validierung anhand des zurückgehaltenen Amazon-Google-Datensatzes: vollständige Metadaten nach Epoche 1, die Titel-only-Variante nach Epoche 2, Noul nach Epoche 5 und der kombinierte Datensatz, die langsamste der vier Konfigurationen, nach Epoche 9. Danach verbesserte sich keine der Konfigurationen mehr.

Beim On-Demand-Preis von AWS für die verwendete Instanz – SageMaker ml.g4dn.12xlarge für 6,112 US-Dollar pro Stunde in der Region EU (Frankfurt) – kosteten die Durchläufe zwischen 2,23 US-Dollar (Titel-only) und 4,54 US-Dollar (kombinierter Datensatz, der größere der vier). Angesichts der schnellen Konvergenz aller Konfigurationen lassen sich die Kosten mit einer Begrenzung auf 9 Epochen auf unter 1,30 US-Dollar pro Durchlauf senken. Diese Grenze bietet sogar mehr Spielraum, als die langsamste der vier Konfigurationen tatsächlich benötigte.

Für ein kleines, speziell entwickeltes Entscheidungsmodell, das mit einigen Tausend Paaren trainiert wird, ist das die entscheidende Zahl: Laya auf eine Accuracy von 95,3 Prozent zu bringen, kostet ungefähr einen Dollar an GPU-Zeit.

Wo dieser Ansatz tatsächlich sinnvoll ist

Keiner der drei Anwendungsfälle, mit denen geworben wird – Routing, Guardrails und Entity Resolution –, ist ein neues Problem. Jeder davon hat bereits einen etablierten Platz in produktiven Systemen, wo heute kleine Klassifikatoren eingesetzt werden. Der eigene Router von vLLM verwendet ein leichtgewichtiges Modell namens ModernBERT, um zwischen einem schnellen Verarbeitungspfad und einem Pfad für komplexere Schlussfolgerungen zu wählen. Dadurch werden die Latenz und der Tokenverbrauch ungefähr halbiert. Die OWASP-Leitlinien zur Absicherung von LLM-Anwendungen formalisieren Guardrails auf ähnliche Weise: Günstige Prüfungen verarbeiten den Großteil des Datenverkehrs, und nur mehrdeutige Fälle werden an eine langsamere Prüfinstanz weitergeleitet.

Entity Resolution funktioniert im großen Maßstab nach demselben Prinzip. Ein System der Commonwealth Bank of Australia, das bis zu 15,7 Millionen Datensätze verarbeitet, verwendet dieselbe zweistufige Struktur: Zunächst werden plausible Kandidaten herausgefiltert, anschließend wird jeder einzelne bewertet. Dieser Bewertungsschritt entspricht genau der Entscheidung zwischen Übereinstimmung und Nichtübereinstimmung aus dem zuvor genannten Customer-360-Beispiel. Traditionell war dafür ein eigener, speziell entwickelter Klassifikator erforderlich, der unabhängig von den Modellen trainiert und gewartet werden musste, die beispielsweise die Unterscheidung zwischen B2C- und B2B-Konten, Routing-Entscheidungen oder Guardrails übernahmen. Jevs Ansatz besteht darin, stattdessen ein einziges Modell für all diese Aufgaben zu verwenden: dieselbe API, die je nach Fragestellung neu konfiguriert wird, anstatt für jede Aufgabe neu trainiert zu werden. So muss ein Team nicht länger für jede dieser kleinen Entscheidungen ein separates kleines Modell entwickeln und warten.

Für Käufer liegt das wichtigere Signal eine Ebene höher. Gartner erwartet, dass Unternehmen bis 2027 kleine, auf bestimmte Aufgaben spezialisierte Modelle dreimal häufiger einsetzen werden als universell einsetzbare LLMs – genau aus diesem Grund: bessere Eignung und geringere Kosten bei domänenspezifischen Entscheidungen. Auch der Aspekt der Datensouveränität verdient ernsthafte Beachtung. TypeSafe hat die Gewichte von Jev nicht als Open Source veröffentlicht und auch keine entsprechenden Pläne angekündigt. Die GitHub-Organisation des Unternehmens enthält ein Dutzend Repositories, aber ausschließlich Client-SDKs, Adapter und Integrationswerkzeuge – keine Modellgewichte, keinen Checkpoint und keine Architekturdokumentation. Nur die Client-Werkzeuge sind öffentlich zugänglich.

Für diese Lücke gibt es bereits zwei unabhängige Antworten, die nicht nur angenommen, sondern getestet wurden. Laya verliert ohne Fine-Tuning für seine Unabhängigkeit zwölf Prozentpunkte an Accuracy und benötigt eine Prompt-Optimierung in genau die entgegengesetzte Richtung zu Jev. Mit dem richtigen Eingabeformat feinabgestimmt, muss es diesen Genauigkeitsverlust jedoch nicht hinnehmen, und die dafür erforderliche GPU-Zeit kostet nur wenige Dollar. Unabhängig davon veröffentlichte ein Projekt namens jeff wenige Tage nach der Einführung von Jev eine selbst hostbare Alternative, die auf einem noch kleineren Encoder mit 400 Millionen Parametern basiert – klein genug für eine einzelne GPU oder einen Laptop. Auch dieses Modell schneidet bei veröffentlichten Benchmarks deutlich schlechter ab als Jev, beispielsweise mit ungefähr 64 Prozent gegenüber 90 Prozent bei einem Intelligenztest. Somit erreicht keines der beiden Projekte direkt nach der Installation die Leistung von Jev. Entscheidend ist jedoch nicht der Ausgangswert der beiden Projekte, sondern dass mehrere unabhängige Teams bereits gezeigt haben, dass diese Aufgabe kein Modell erfordert, das zu groß ist, um es selbst zu betreiben.

Jev selbst wurde erst am 15. September 2026 eingeführt. Es gibt daher noch keine lange Erfolgsgeschichte und keine Erfahrungswerte darüber, wie es sich unter anhaltender realer Last über mehrere Monate verhält. Der pragmatische Ansatz ist vorerst ein begrenztes Pilotprojekt: Das Modell auf einen kleinen Teil des Datenverkehrs anwenden, das bestehende System parallel als Fallback weiterbetreiben und die Rolle des neuen Modells – ob Jev oder eine selbst gehostete Alternative – erst dann schrittweise erweitern, wenn es sich bewährt hat. Man sollte nicht gleich am ersten Tag seinen einzigen Klassifikator durch ein brandneues Modell ersetzen.

Über Jev hinaus

Die Community, die darum konkurriert, Jev nachzubauen, befindet sich nicht mehr nur in einem Wettlauf. Sie hat inzwischen etwas geliefert, für das sich konkrete Zahlen nennen lassen: tatsächliche Kosten, gemessen am selben Benchmark. Ein Team muss sich nicht länger zwischen dem Vertrauen auf den Benchmark eines Anbieters, der Entwicklung eines Klassifikators von Grund auf und einem schlechteren, aber kostenlosen Modell entscheiden. Ein korrekt feinabgestimmtes offenes Modell kann die Accuracy eines führenden gehosteten Modells erreichen und gleichzeitig seinen Geschwindigkeits- und Kostenvorteil behalten – für wenige Dollar an GPU-Zeit. Damit geht es bei der Entscheidung um die betriebliche Eignung und die Datensouveränität sowie darum, wer für das Fine-Tuning verantwortlich ist, und nicht mehr um einen unvermeidlichen Kompromiss zwischen Genauigkeit und allem anderen. Jev selbst ist in einem Jahr möglicherweise nicht mehr das entscheidende Modell. Die Lücke, auf die es aufmerksam macht – Entscheidungen, die für ein LLM zu klein und für traditionelles maschinelles Lernen zu umständlich sind –, hat endlich echte Konkurrenz bekommen. Und diese Konkurrenz hat gerade gezeigt, was sie leisten kann.

Quellen

[S1] TypeSafe AI. "Introducing System One Models & Jev." TypeSafe AI Blog, September 15, 2026. https://typesafe.ai/blog/introducing-system-one-models-and-jev. Accessed September 21, 2026.

[S2] MarkTechPost. "TypeSafe AI Releases Jev: A System One Model That Returns Typed, Calibrated Decisions Instead of Text." MarkTechPost, September 19, 2026. https://www.marktechpost.com/2026/09/19/typesafe-ai-releases-jev/. Accessed September 21, 2026.

[S4] "From System 1 to System 2: A Survey of Reasoning Large Language Models." arXiv:2502.17419. https://arxiv.org/abs/2502.17419. Accessed September 21, 2026.

[S5] DataCamp. "Jev: TypeSafe's System One Model That Never Hallucinates." DataCamp Blog. https://www.datacamp.com/blog/system-one-models-jev. Accessed September 21, 2026.

[S10] TypeSafe AI. "Docs: Introduction." TypeSafe AI Documentation. https://docs.typesafe.ai/introduction. Accessed September 21, 2026.

[S12] TypeSafe AI. "Docs: full reference." TypeSafe AI Documentation. https://docs.typesafe.ai/llms-full.txt. Accessed September 21, 2026.

[S16] ITRex Group. "Machine Learning (ML) Costs: Price Factors and Real-World Estimates." ITRex Group Blog. https://itrexgroup.com/blog/machine-learning-costs-price-factors-and-estimates/. Accessed September 21, 2026.

[S17] CDP.com. "CDP Pricing: Models, Ranges, and Hidden Costs to Budget For." https://cdp.com/articles/cdp-pricing/. Accessed September 21, 2026.

[S18] CloudZero. "LLM API Pricing Comparison in 2026: Every Major Model Ranked by Cost." CloudZero Blog, updated September 4, 2026. https://cloudzero.com/blog/llm-api-pricing-comparison/. Accessed September 21, 2026.

[S21] Mordor Intelligence. "Identity Resolution Software Market Size & Share Analysis (2026-2031)." https://mordorintelligence.com/industry-reports/identity-resolution-software-market. Accessed September 21, 2026.

[S23] Gartner. "Gartner Predicts By 2027, Organizations Will Use Small, Task-Specific AI Models Three Times More Than General-Purpose LLMs." Gartner Newsroom, April 9, 2025. https://www.gartner.com/en/newsroom/press-releases/2025-04-09-gartner-predicts-by-2027-organizations-will-use-small-task-specific-ai-models. Accessed September 21, 2026.

[S29] Pavlovic, Maja (Queen Mary University London). "Understanding Model Calibration: A Gentle Introduction and Visual Exploration of Calibration and the Expected Calibration Error (ECE)." arXiv:2501.19047. https://www.alphaxiv.org/abs/2501.19047. Accessed September 21, 2026.

[S31] vLLM Project. "vLLM Semantic Router." vLLM Blog, September 11, 2025. https://blog.vllm.ai/2025/09/11/semantic-router.html. Accessed September 21, 2026.

[S32] Kannangara, Sandeepa, et al. (Commonwealth Bank of Australia). "A Robust and Efficient Pipeline for Enterprise-Level Large-Scale Entity Resolution (MERAI)." arXiv:2508.03767. https://www.alphaxiv.org/abs/2508.03767. Accessed September 21, 2026.

[S33] OWASP. "LLM Prompt Injection Prevention Cheat Sheet." OWASP Cheat Sheet Series. https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html. Accessed September 21, 2026.

[S35] TypeSafe AI. "Docs: System One, Confidence, and Confidence-Gated Routing." TypeSafe AI Documentation. https://docs.typesafe.ai/concepts/system-one. Accessed September 21, 2026.[S39] Markewich, Logan. "jeff: a self-hosted drop-in replacement for TypeSafe's Jev." GitHub repository. https://github.com/logan-markewich/jeff. Accessed September 21, 2026.

[S41] Melnikoff, A.I. and Bargh, J.A. "The Mythical Number Two." Trends in Cognitive Sciences, 22(4), 280-293, 2018. https://pubmed.ncbi.nlm.nih.gov/29571664/. Accessed September 21, 2026.

[S42] ConvAI Innovations. "laya: a multilingual, non-autoregressive System 1 decision model." Hugging Face model card. https://huggingface.co/convaiinnovations/laya. Accessed September 28, 2026.

[S43] TypeSafe AI. GitHub organization. https://github.com/typesafe-ai. Accessed October 6, 2026.

[SEED-1] Author's own benchmark experiment: evaluating Jev against the Amazon-Google entity-resolution dataset, September 2026.

[SEED-2] Author's own benchmark experiment: 24-variant prompt sweep on a 30-pair tuning set, September 2026.

[SEED-3] Author's own benchmark experiment: full-run results and confusion matrix, September 2026.

[SEED-4] Author's own benchmark experiment: per-call latency measurements, September 2026.

[SEED-5] Author's own benchmark experiment: evaluating Laya (convaiinnovations/laya) against the identical Amazon- Google evaluation set used for Jev, including a 16-variant prompt/config sweep on the same 30-pair tuning set, September 2026.

[SEED-6] Author's own benchmark experiment: Laya full-run results, confusion matrix, and label-integrity audit, September 2026.

[SEED-7] Author's own benchmark experiment: Laya latency and cost measurements, local inference on Apple Silicon (MPS), September 2026.

[SEED-8] Author's own experiment: fine-tuning Laya on Abt-Buy product data, validated throughout against a held-out slice of the Amazon-Google dataset, across four configurations (full metadata, noul, title-only, blended training data), AWS SageMaker, October 2026.

[SEED-9] Reserved, internal diagnostic material (training-plateau root-cause analysis) not drawn on by this article; see FINETUNING_REPORT.md.

[SEED-10] Author's own experiment: per-epoch dev-set accuracy tracking across all four fine-tuning configurations, establishing convergence within 1-9 epochs, October 2026.

[SEED-11] Author's own experiment: production deployment of the fine-tuned model as a public HTTPS API (SageMaker Serverless Inference + API Gateway + Lambda), October 2026.

[SEED-12] AWS Pricing API: on-demand training price for ml.g4dn.12xlarge in EU (Frankfurt), retrieved October 2026.