NUS veröffentlicht Jeva-4B: „Keine passende Option“ und Caching in der Entscheidungsarchitektur
Laut Newzhiyuan hat die xML Lab der National University of Singapore Jeva vorgestellt: Qwen3.5-4B als Backbone plus ein Entscheidungsblock, der direkt Auswahl, null oder Score ausgibt. Das Paper berichtet null Entscheidungsumkehrungen und 69,88 % Genauigkeit bei 2.048 Kandidaten; die Gewichte sind auf Hugging Face veröffentlicht.
Was sich geändert hat
Laut einem Bericht von Newzhiyuan vom 26. Oktober 2026 (Originalzeitstempel 1792987620000) hat die xML Lab der National University of Singapore ein Paper und Code veröffentlicht, in denen die für Entscheidungsaufgaben konzipierte Architektur Jeva vorgestellt wird, zusammen mit dem veröffentlichten Modell Jeva-4B. Dem Bericht zufolge nutzt das Modell Qwen3.5-4B als Backbone und ergänzt einen leichten Entscheidungsblock: Ein gemeinsamer Encoder stellt Anfrage und Kandidatenoptionen separat dar, der Entscheidungsblock liest die gesamte Kandidatenmenge und aktualisiert nur den Anfragezustand. Dadurch lassen sich die Optionseinbettungen zwischenspeichern und wiederverwenden, während die aktuelle Bewertung jeweils neu berechnet wird. Der Bericht nennt vier Designziele: zwischen „welcher Kandidat ist besser“ und „gibt es überhaupt eine akzeptable Antwort in der Gruppe“ unterscheiden, wobei Letzteres über eine separate Abdeckungswahrscheinlichkeit geschätzt wird und die Ausgabe null erlaubt; symmetrische Aggregation über die Kandidatenmenge, sodass die Wahrscheinlichkeit der Kandidatenidentität folgt und nicht der Listenposition; dieselbe Bewertungsregel für jeden Kandidaten, sodass die vollständige Kandidatenmenge direkt verarbeitet wird statt über mehrere Ausscheidungsrunden; Caching der semantischen Optionseinbettungen und ihrer Schichtprojektionen zur Wiederverwendung bei neu zusammengesetzten Kandidatenmengen. Dieselbe Berechnung unterstützt drei Ausgabetypen: Choice, Noul (Wahrscheinlichkeit, dass eine Aussage wahr ist) und Score. Die im Bericht genannten Ergebnisse stammen aus dem Paper: Auf 3.080 aus BANKING77 konstruierten Anfragen (je 16 Kandidaten, darunter 588 ohne passende Antwort) liegt die AUROC der null-Erkennung bei 98,66 %, verglichen mit KEV-BF16 93,61 %, InternDecision-4B 84,27 % und JevK5 79,44 %. Auf 600 Choice-Stichproben wurden Originalreihenfolge, umgekehrte Reihenfolge und bis zu drei zufällige Permutationen getestet; Jeva erreichte sowohl in der Originalreihenfolge als auch bei „in allen getesteten Reihenfolgen korrekt“ 76,67 %, ohne beobachtete Entscheidungsumkehr, während die Vergleichsmodelle Umkehrraten von 17,00 %, 22,67 % und 26,17 % zeigten. In ToolRet-Setups mit 32 bis 2.048 Kandidaten lag die Genauigkeit bei 2.048 Kandidaten bei 69,88 % mit einer medianen Anfrage-Latenz von 12,04 Sekunden auf einer einzelnen H200; JevK5 erreichte 67,47 % bei etwa 28,35 Sekunden. Bei 83 festen Fragen und einer Erweiterung der Kandidaten von 32 auf 2.048 beantwortete Jeva in allen Größenordnungen dieselben 58 Fragen korrekt, JevK5 48 und CLM 7. Im MLDR-Langdokument-Experiment sank die mediane Anfrage-Latenz von etwa 2,10 Sekunden auf 75,1 Millisekunden, wenn alle Kandidaten im Cache lagen; laut Bericht wurden unter verschiedenen Cache-Bedingungen keine Änderungen der Entscheidung beobachtet. Alle diese Zahlen sind Eigenangaben des Papers und wurden hier nicht unabhängig reproduziert.
Auswirkungen für Entwickler
Für Entwickler ist Jeva weniger ein weiteres Allzweck-Chatmodell als eine Form, die „Ranking + Ablehnung + Caching“ in den Inferenzpfad integriert; das verändert die Integrationsgestaltung mehrerer Systemtypen. Erstens ändert sich der Ausgabevertrag: Die Kandidatenmenge ist Eingabe einer Anfrage, das Modell liefert eine Verteilung oder einen Score mit null statt eines erneut parsebaren Textes. Wer bestehende Prompt-Ketten, in denen das Modell JSON mit einer Auswahl ausgeben soll, auf solche Modelle umstellt, muss in der Serviceschicht Kandidaten-IDs, Schwellenwerte für die Abdeckungswahrscheinlichkeit und das Fallback-Verhalten bei null definieren; auch das Logging muss die vollständige Kandidatenmenge der Anfrage erfassen, sonst lässt sich im Nachhinein nicht unterscheiden, ob eine Ablehnung an ungeeigneten Kandidaten oder an einem Modellfehler lag. Zweitens wandert das Caching von der Prompt-Ebene in die Architektur: Laut Bericht werden Optionseinbettungen gecacht, nicht Antworten. Das ist direkt relevant für Fälle wie Richtlinienklauseln, Langdokument-Sammlungen oder feste Bewertungsmaßstäbe, in denen Kandidaten relativ stabil und Fragen ständig wechselnd sind. Es bedeutet aber, dass Cache-Schlüssel an Modellversion, Entscheidungstyp und Encoder-Einstellungen gebunden werden müssen; ändert sich das Modell oder die Encoder-Konfiguration, müssen alte Caches ungültig werden. Drittens muss die Kandidatengröße nicht mehr über mehrere Ausscheidungsrunden begrenzt werden: Laut Bericht werden 2.048 Kandidaten noch im selben Entscheidungskopf verglichen, was das Reranking nach der Retrieval-Phase vereinfacht, aber Latenz direkt an Kandidatenanzahl und -länge koppelt. Die mediane Latenz von 12,04 Sekunden zeigt, dass große Kandidatenmengen weiterhin Offline- oder Asynchronaufgaben bleiben und keine interaktiven Aufrufe sind. Einschränkend ist zu sagen, dass die Namen der Vergleichsmodelle im Bericht (etwa Jev-1.13.0, JevK5, CLM) und die Angaben zu Baseline-Konfigurationen begrenzt sind; Leser sollten diese Vergleichszahlen nicht auf ihre eigene Datenverteilung oder chinesische Geschäftskandidatenmengen übertragen.
Integration und Bewertung
Im Folgenden handelt es sich um Empfehlungen und bedingte Analysen, nicht um berichtete Fakten. Entscheidung eins: Ob die bestehende „generative Auswahl“ durch eine Entscheidungskopf-Schnittstelle ersetzt wird, hängt davon ab, ob Ihre Kandidaten aufzählbar sind und ob eine Ablehnung explizit sein muss. Gibt es im Geschäft tatsächlich Fälle, in denen „die ganze Gruppe nicht passt“ (etwa Ticket-Zuweisung oder Intent-Routing), lohnt es sich, das im Bericht beschriebene null-aware Design gesondert zu prüfen: Bauen Sie eine Charge von Anfragen aus Ihrer realen Verteilung, in denen kein Kandidat passt, mischen Sie sie mit Anfragen mit Antwort, fahren Sie die Schwellenwerte durch und erfassen Sie AUROC sowie Recall bei einer festen Fehlablehnungsrate (etwa 5 %). Nur wenn diese Kennzahl deutlich besser ist als bei der bestehenden Prompt-Lösung, lohnt der Aufwand für die Schnittstellenänderung. Gibt es für Ihre Kandidaten immer eine richtige Antwort, ist der Nutzen dieser Fähigkeit begrenzt und die Priorität der Umstellung sollte sinken. Entscheidung zwei: Ob Optionen-Caching eingesetzt wird, hängt vom Wiederverwendungsmuster der Kandidatenbibliothek ab. Zählen Sie zunächst bei einer Charge von Produktionsanfragen den Überlappungsanteil zwischen Kandidatenmengen aus (im Bericht sind es schrittweise Überlappungen wie ABC, BCD, ACD). Ist die Überlappung hoch und sind die Kandidatentexte lang, können Sie nach dem Ansatz des Berichts den Latenzunterschied zwischen vollständigem Cache-Treffer und keinem Treffer messen. Gleichzeitig müssen Sie prüfen, ob dieselbe Anfrage vor und nach einem Cache-Treffer dieselbe Entscheidung ergibt, denn der Bericht sagt nur, dass in seinen Experimenten keine Änderung beobachtet wurde; das ist keine Garantie für Äquivalenz auf Ihren Daten. Sind die Kandidaten fast jedes Mal neu, kann der Zusatzaufwand der Cache-Schicht den Nutzen übersteigen. Entscheidung drei: Die Obergrenze der Kandidatenzahl sollte am Latenzbudget und nicht allein an der Genauigkeit festgelegt werden. Der Bericht nennt bei 2.048 Kandidaten 69,88 % Genauigkeit und 12,04 Sekunden mediane Latenz; beide Zahlen sind zusammen zu betrachten. Verlangt Ihr Szenario Antworten im Sekundenbereich, müssen Sie die Genauigkeitskurve bei kleineren Kandidatenmengen messen, den Knickpunkt finden, ab dem die Genauigkeit sinkt, und dann entscheiden, ob Sie die Kandidatenmenge erweitern oder die bestehende Retrieval-Begrenzung beibehalten. Fixieren Sie bei der Evaluation die Fragen und erhöhen Sie die Kandidaten schrittweise (die Methode des Berichts mit 83 Fragen von 32 auf 2.048 lässt sich direkt übernehmen) und erfassen Sie den Anteil „in allen Größenordnungen korrekt“; das deckt Stabilität besser auf als eine einzelne Genauigkeitszahl. Entscheidung vier: Reihenfolgerobustheit sollte als fester Regressionstest vor dem Produktivgang dienen. Testen Sie nach der Methode des Berichts dieselbe Stichprobe in Originalreihenfolge, umgekehrter Reihenfolge und mehreren zufälligen Permutationen, richten Sie die Ergebnisse an der Kandidatenidentität statt an der Position aus und erfassen Sie die Umkehrrate. In Szenarien mit Compliance, Risikokontrolle oder Scoring ist die Umkehrrate die wichtigere Kennzahl als die durchschnittliche Genauigkeit.
Grenzen und offene Fragen
Alle experimentellen Zahlen in diesem Artikel stammen aus Paper-Ergebnissen, die Newzhiyuan wiedergibt, und wurden nicht unabhängig reproduziert. Die Konfiguration und Trainingsdetails der Vergleichsmodelle sind im Bericht unvollständig; modellübergreifende Vergleiche sind mit Vorsicht zu behandeln. Der Bericht nennt keine konkreten Lizenzbedingungen für die Jeva-4B-Gewichte auf Hugging Face. Herunterladbare Gewichte bedeuten nicht, dass kommerzielle Nutzung oder Weitergabe erlaubt ist; prüfen Sie vor dem Deployment selbst die Modellkarte und den Lizenztext. Der Bericht enthält auch keine Angaben zu API-Service, Preisgestaltung oder gehosteter Verfügbarkeit; falls es Aufrufwege gibt, gelten die Angaben des Herausgebers. Zudem konzentrieren sich die Experimente auf englische Aufgaben wie BANKING77, ToolRet und MLDR; die Leistung bei chinesischen Kandidatenmengen, Fachterminologie und Langdokumenten ist unbekannt. Besonders wichtig: Die Version Jeva-4B ist derzeit nicht im KimiSeek-Modellkatalog enthalten; es gibt bei KimiSeek keinen exakt entsprechenden Eintrag. Aussagen zur API-Verfügbarkeit beziehen sich ausschließlich auf den Herausgeber und nicht auf diese Website. Für vergleichbare Entscheidungsaufgaben auf KimiSeek sollten Sie die dort gelisteten Modelle gesondert evaluieren und die Preisseite als maßgeblich betrachten.