Autoren: @eddiedzhou, @mr_cheu, @MatZhao, @CosmicPegasis19, @manav_ai
Jev ist ein Modell für typisierte Entscheidungen. Du sendest ihm einen Kontext sowie einen festen Satz an Fragen und Optionen – zurück erhältst du Auswahlentscheidungen, Scores und Wahrscheinlichkeiten statt generiertem Text. Es handelt sich um ein „System-One“-Modell!
Klassifizierung ist allerdings nichts Neues, ebenso wenig wie strukturierte Outputs, kleine Modelle oder das Auslesen von Wahrscheinlichkeiten aus Logits. Diese Vorgeschichte erklärt auch die gespaltenen Reaktionen auf Jev …
Die Skeptiker haben durchaus einen Punkt, aber Jev hat seinen festen Platz in diesem Ökosystem. Um das besser zu verstehen, sollten wir uns den gesamten Lösungsraum ansehen.
Was sind die Alternativen?
Wenn ein System ein Label, einen Score oder eine Ja/Nein-Antwort benötigt, gibt es vier sinnvolle Optionen:
Ansatz
Warum nutzen?
Kompromiss (Trade-off)
Ein allgemeines LLM
Zero-shot, flexibel, kann zusätzlich Argumente oder Erklärungen generieren. Durch Compute zur Inferenzzeit (Reasoning) lässt sich von einer „höheren Intelligenz“ sprechen.
Latenz und Kosten eines autoregressiven Modells für eine kleine Entscheidung bezahlen
Ein offener Zero-Shot-Klassifikator
Günstig, lokal und kontrollierbar
Schwankende Qualität; Modellauswahl und Serving liegen in deiner Verantwortung
Ein feingetunter Klassifikator
Meist die beste Wahl für stabile Aufgaben mit hohem Volumen und guten Labels
Datensammlung, Training, Deployment, Drift und eine weniger flexible Taxonomie
Jev
Zero-Shot-Flexibilität hinter einer sauberen, gehosteten API
Aufgabenabhängige Qualität, kein generierter Text, Abhängigkeit vom Anbieter
Das Argument für Jev: Ein Team kann Fragen und Optionen ändern, ohne einen neuen Trainingsdatensatz zu erstellen – und spart sich gleichzeitig den Aufwand, ein Modell zuverlässig bereitzustellen. Das sollte niemand unterschätzen. „Das könnten wir selbst bauen“ gilt für die meisten Infrastrukturprodukte.
Offene Nachbauten relativieren den Neuheitsanspruch. Implementierungen mit Qwen und SGLang, DiffusionGemma und vLLM sowie Kev bilden große Teile der API bzw. des Modells nach.
85,7 % für Jev und 79,6 % für Kev-8B bei n=764
Auch die externen Tests von Parallel zeigten, dass Jev beim Reranking konkurrenzfähig ist, während spezialisierte Modelle zwei Klassifizierungsaufgaben weiterhin für sich entschieden.
Unsere Erfahrungen bei Glean
Bleibt die praktische Frage: Wann schlägt Jevs Kombination aus Zero-Shot-Flexibilität und gehosteter Inferenz die Alternativen tatsächlich? Bei Glean haben wir vier klar abgegrenzte Entscheidungsprozesse getestet, für die bereits ein Baseline existierte und wir echte Enterprise-Qualität vergleichen konnten. Die meisten dieser Baselines sind LLM-basierte Systeme, daher erwarteten wir bei diesen Experimenten Verbesserungen um zwei Größenordnungen bei Kosten und Latenz. Die Ergebnisse reichten von deutlich schlechter als unsere Produktionslösung bis hin zu schneller und präziser als ein LLM-basierter Router.
Query-Klassifizierung
Bei der Query-Klassifizierung wird eine Anfrage einer übergeordneten Aufgabe zugeordnet, die von nachgelagerten Systemen genutzt wird. Das ist ein natürliches Einsatzgebiet für Jev: Zwar ist der Label-Raum pro Anfrage im Voraus bekannt, die Taxonomie kann sich jedoch schneller ändern, als ein feingetunter Klassifikator neu trainiert werden könnte.
In diesem Experiment konzentrieren wir uns darauf, wie stark Jev mit unseren Produktions-/Baseline-Vorhersagen übereinstimmt, die LLM-basiert sind. Wir erwarten und beobachten einen deutlichen Geschwindigkeitszuwachs beim Offline-Durchsatz mit Jev, weshalb wir die Übereinstimmung als einfachen Indikator für die Qualität heranziehen. Als weitere Baselines dienten Laya – ein Open-Weight-Entscheidungsmodell – sowie eine feingetunte Version davon. Dieses Fine-Tuning ließ sich lokal in wenigen Stunden durchführen, und das Modell ist klein genug, um auf einem Entwicklerrechner betrieben zu werden.
Experiment
Übereinstimmung bei übergeordneten Aufgaben
Performance
Jev Zero-Shot
66,8 %
~
12 Min. (Parallelität von 4
)
Basis-Laya
35,9 %
~
90 s (lokaler Entwicklerrechner)
Feingetuntes Laya
74,5 %
~
90 s (lokaler Entwicklerrechner)
Als praktisches Out-of-the-box-Modell ohne Trainingsaufwand übertrifft Jev Laya deutlich. Wenig überraschend bringt das Fine-Tuning Laya jedoch zum Glänzen – besonders angesichts der Performance-Werte. Der Preis dafür ist der Aufwand, gute Labels zu beschaffen und das Training aufzusetzen. Jev dürfte attraktiver bleiben, wenn eine Aufgabe neu ist oder sich ihre Labels häufig ändern.
Modell-Routing: Expert Transfer
Modell-Routing ist eng mit der Query-Klassifizierung verwandt. Hier fassen wir es als „Expert Transfer“ auf: Unser System entscheidet, welcher Experte bzw. welches Modell die Anfrage bearbeiten soll. Unsere aktuelle Produktions-Baseline überlässt diese Entscheidung nativ einem LLM innerhalb der agentischen Schleife des Harness. Das ist ein naheliegender Test, ob Jev einen generativen Aufruf durch eine begrenzte Entscheidung ersetzen kann. Eine wichtige technische Einschränkung besteht jedoch darin, dass Jev bei einem Nicht-Transfer strikt einen zusätzlichen Aufruf erzeugt. Im Gegensatz dazu kann die Produktions-Baseline bei Nicht-Transfers direkt mit demselben ersten LLM-Aufruf in die Tool-Ausführung starten.
Wir nutzten eine vereinfachte Version unseres Produktions-Routings mit nur drei Experten, spielten 751 vergleichbare Golden Entries durch den aktualisierten Jev-Router und verglichen die gewählte Route mit unserem bestehenden Prompt-basierten Router (betrieben mit einem klassischen LLM). Dabei maßen wir die Genauigkeit anhand des Golden Labels.
Zudem isolierten wir 40 Einträge, bei denen der bisherige Pfad tatsächlich einen Expert-Transfer-Aufruf durchführte (kleineres n), und verglichen die Aufruflatenz für genau diese Einträge.
Der mediane Geschwindigkeitszuwachs pro Eintrag lag bei 8,1×. Das ist eines der stärksten internen Jev-Ergebnisse bisher: Bei dieser begrenzten Routing-Aufgabe war Jev sowohl präziser als auch deutlich schneller. Die Größe des Unterschieds legt nahe, dass der „Blocking“-Nachteil bei Anfragen ohne Experten-Transfer ein akzeptabler Kompromiss sein könnte. Beachte, dass es sich weiterhin um einen Offline-Vergleich mit einem Golden Set handelt und die Latenzstichprobe nur 40 positive Transfers umfasst – es gibt also noch viel zu testen und Risiken auszuräumen!
Reranking
Ein Thema, das Glean besonders am Herzen liegt! Unsere Produktions-Baseline unten entspricht der Reihenfolge, die der bestehende Suchstack von Glean liefert. In diesem Experiment baten wir Jev, bis zu 50 Ergebnisse neu zu ordnen.
Wir haben vier Wege getestet, Relevanz über Jevs typisierte Outputs auszudrücken:
Formulierung
Wie sie Relevanz ausdrückt
Pointwise Noul
Für jedes Ergebnis wird eine separate Ja/Nein-Relevanzfrage gestellt, anschließend wird nach der Wahrscheinlichkeit für „Ja“ sortiert.
Shared-State Noul
Jev erhält den gesamten Kandidatensatz als gemeinsamen Kontext, danach wird für jedes Ergebnis dieselbe Ja/Nein-Frage gestellt.
Score
Jev weist jedem Kandidaten einen numerischen Relevanz-Score zu.
Choice
Alle Kandidaten werden als Optionen einer einzigen Entscheidung behandelt und anschließend nach ihren resultierenden Wahrscheinlichkeiten gerankt.
Wir führten dies mit einem internen Evalset durch, bei dem Nutzer keinen Zugriff auf alle kanonischen Dokumente haben. Die absoluten Werte spiegeln daher nicht unser Produktionsranking wider – die relativen Unterschiede sind jedoch interessant.
Jev „Choice“ war die stärkste Formulierung. Bei einer gepaarten Kontrolle von 4.855 erfassten Suchanfragen – ohne produktionsbasiertes Tie-Breaking – lautete das Ergebnis:
Jev Choice kostete etwa 0,00044 $ pro Anfrage und benötigte im Offline-Test 0,195 Sekunden bei p50. Allerdings vergab es bei durchschnittlich 37 der 41 Kandidaten pro Anfrage identische Scores. Wenn wir die Produktionsreihenfolge nutzten, um diese Gleichstände aufzulösen, stieg Recall@6 von 40,2 % auf 44,3 %. Dadurch wirkte das unkorrigierte Ergebnis stärker, als es Jevs reine Scores rechtfertigen würden. Wie üblich gibt es hier viele Einschränkungen, aber tendenziell gilt: Jev ist eine günstige, effiziente Baseline, kein Ersatz für Gleans Produktionsranker.
Beurteilung von Zitationsbelegen
Die Beurteilung von Zitaten stellt zwei verwandte Fragen: Verfügen Behauptungen, die Belege benötigen, über ausreichende Zitate (Citation Recall), und stützen die zitierten Quellen die ihnen zugeschriebenen Behauptungen tatsächlich (Citation Precision)? Auf den ersten Blick scheint dies wegen des begrenzten Output-/Label-Raums (ähnlich wie bei den meisten Judge-Szenarien) ein offensichtlicher Anwendungsfall für Jev zu sein. Die Bewertungskriterien sind jedoch komplex und erfordern möglicherweise das Zerlegen mehrerer Behauptungen. Zudem liefert Jev keine Begründung, die wir oft für Fehleranalysen nutzen – was gewisse Risiken für Qualität und Nutzbarkeit birgt.
Wir testeten Jev mit einer echten Produktions-Eval-Antwort von 1.448 Wörtern, wobei Antwort und Zitationsbelege fix blieben. Wir verglichen den kombinierten Precision-und-Recall-Durchlauf mit GPT-5.6 Luna ohne Reasoning sowie mit xhigh Reasoning. Um die Varianz zu reduzieren, ließen wir jeden Judge dreimal laufen.
Judge
Ursprünglich gemessene Zeit pro Antwort
Ursprünglich gemessene Kosten pro Antwort
Jev
6,6 s
$
0,014
GPT-5.6 Luna, kein Reasoning
81,3–85,5 s
$
0,030–
$
0,047
GPT-5.6 Luna,
xhigh
227,4–259,7 s
$
0,047–
$
0,060
Hinweis: Die Zeitangaben sind eher richtungsweisend als End-to-End: Jev meldet die sequenzielle Wall-Clock-Zeit des Clients, während bei Luna die Dauern der Modellaufufe summiert wurden. Die Kosten beinhalten das beobachtete Caching.
Außerdem verglichen wir die Konsistenz bei denselben 28 Absätzen. Ein geändertes Item bedeutet, dass der Judge in mindestens einem von drei Läufen mit identischem Input seine Einschätzung änderte, ob ein Absatz ausreichend belegt war. Die paarweisen Abweichungen zählen jeden Absatz über die drei Laufpaare hinweg – also 84 Vergleiche pro Judge.
Judge
Absätze mit geändertem Recall-Urteil
Paarweise Recall-Abweichungen
Jev
1 von 28 (3,6 %)
2 von 84 (2,4 %)
GPT-5.6 Luna, kein Reasoning
7 von 28 (25,0 %)
15 von 84 (17,9 %)
GPT-5.6 Luna,
xhigh
5 von 28 (17,9 %)
10 von 84 (11,9 %)
Bei Jev änderte sich lediglich, ob ein einzelner Absatz als belegpflichtig galt; die rohe Recall-Kategorie blieb unverändert. Jevs Urteile zur Zitationsabdeckung auf Absatzebene waren somit reproduzierbarer als bei beiden Luna-Konfigurationen.
Daraus schließen wir nicht, dass Jev der präzisere Judge ist (die Systeme nutzten unterschiedliche Unterstützungskriterien und Bewertungs-Nenner, und für unabhängige menschliche Labels fehlte die Zeit). Doch selbst mit xhigh Reasoning (was Lunas Modellzeit etwa verdreifachte) blieb es weniger konsistent als Jev. Das Ergebnis spricht für Jev als schnelle, günstige und vergleichsweise reproduzierbare Methode, um eine enge Zitationsrichtlinie umzusetzen.
Erkenntnisse aus den Experimenten und Praxisleitfaden
In manchen Fällen glänzt Jev als reibungslose Alternative zu klassischen LLMs und feingetunten Klassifikatoren. Ist die Baseline bereits stark (Reranking) oder lässt sich ein kleineres Modell leicht finetunen (Query-Klassifizierung), fällt der Vorteil geringer aus. Es gibt Anzeichen für höhere Qualität bei bestimmten Aufgaben (Modell-Routing) sowie Hinweise auf bessere Konsistenz und Stabilität (Zitations-Judge). In einigen unserer wichtigsten Workloads liefert es die erwarteten Kostensenkungen und Latenzverbesserungen gegenüber klassischen LLMs.
Die obigen Ergebnisse geben eine gute Richtung vor, und bei Glean sind wir sehr begeistert von Jev. Nach einigen weiteren Schritten (vor allem operative Reife wie Datenresidenz und Garantien) planen wir, Jev in einigen dieser Anwendungsfälle live einzusetzen. Außerdem wird Jev bei unserem internen Hackathon in dieser Woche eine große Rolle spielen – wir freuen uns darauf, weitere Ergebnisse zu teilen!
Zum Abschluss ein paar allgemeine Tipps: Wenn sich der Output im Voraus auflisten lässt, benche Jev. Sind Aufgabe und Labels stabil und das Volumen hoch, benche auch einen feingetunten Klassifikator. Muss der Aufruf eine Query, Erklärung oder anderen dynamischen Text generieren, behalte ein generatives Modell im Loop. Tool Calling ist ein gutes Beispiel: Jev kann bei der Tool-Auswahl helfen, aber die meisten Glean-Tools benötigen weiterhin dynamisch generierte Argumente (wie Suchanfragen).
Jev ändert nichts daran, dass es Klassifikatoren schon vorher gab. Es macht einen guten Zero-Shot-Klassifikator jedoch deutlich einfacher nutzbar. Das ist ein solides Produkt – auch wenn es nicht das neue Fundament für jedes KI-System darstellt.
