NUS releases Jeva-4B: building “no suitable option” and caching into the decision architecture
According to a Newzhiyuan report, the National University of Singapore's xML Lab proposes Jeva, which uses Qwen3.5-4B as its backbone plus a decision block that directly outputs a choice, null, or score; the paper reports zero order-flip rate and 69.88% accuracy with 2,048 candidates, and the weights have been released on Hugging Face.
What changed
According to an October 26, 2026 report by Newzhiyuan (corresponding to original timestamp 1792987620000), the National University of Singapore's xML Lab published a paper and code proposing the Jeva architecture for decision tasks, and released the Jeva-4B model. The report says the model uses Qwen3.5-4B as its backbone plus a lightweight decision block: a shared encoder represents the request and candidate options separately, and the decision block reads the entire candidate set and updates only the request state, so option representations can be cached and reused while the current judgment is recomputed each time. The report lists four design goals: distinguish “which candidate is better” from “whether the group contains any acceptable answer,” with the latter estimated separately via coverage probability and allowed to output null; aggregate symmetrically over the candidate set so probabilities follow candidate identity rather than list position; apply the same scoring rule to every candidate, directly handling the full candidate set instead of multiple elimination rounds; and cache option semantic representations and their layer projections for reuse when candidate sets are recombined. The same computation supports three output types: Choice, Noul (the probability a proposition is true), and Score. All experimental results in the report come from the paper: on 3,080 requests constructed from BANKING77 (16 candidates per request, including 588 answer-absent cases), null-detection AUROC was 98.66%, versus KEV-BF16 93.61%, InternDecision-4B 84.27%, and JevK5 79.44%; on 600 Choice samples tested under original order, reversed order, and up to three random permutations, Jeva's original-order accuracy and its accuracy on “correct under all tested orders” were both 76.67%, with no decision flips observed, while baselines flipped at 17.00%, 22.67%, and 26.17%; in ToolRet settings with 32 to 2,048 candidates, accuracy at 2,048 candidates was 69.88% with a median request latency of 12.04 seconds on a single H200, versus JevK5 at 67.47% and about 28.35 seconds; with 83 fixed questions and candidates expanded from 32 to 2,048, Jeva answered 58 of those questions correctly at every scale, versus 48 for JevK5 and 7 for CLM; and in MLDR long-document experiments, when all candidates hit the cache, median request latency fell from about 2.10 seconds to 75.1 milliseconds, with the report saying no decision changes were observed under different cache conditions. All these numbers are self-reported by the paper and were not independently reproduced here.
What it means for developers
For developers, Jeva is not another general chat model but a form that couples ranking, abstention, and caching into the inference path, which changes integration design for several kinds of systems. First, the output contract changes: the candidate set is the input to a single request, and the model returns a distribution or score that includes null, rather than a block of re-parseable text. Moving an existing “make the model output JSON and pick one” prompt chain onto such a model requires defining candidate IDs, a coverage-probability threshold, and null fallback behavior at the service layer, and logs must record the full candidate set for each request, otherwise you cannot later tell whether an abstention was caused by unsuitable candidates or by a model error. Second, caching moves down from the prompt layer to the architecture layer: what can be cached is option representations, not answers, which is directly relevant to scenarios such as policy clauses, long document libraries, and fixed scoring rubrics where candidates are relatively stable and questions keep changing, but it means cache keys must be tied to model version, decision type, and encoding settings, and old caches must be invalidated when the model or encoding configuration changes. Third, candidate scale no longer needs to be controlled through multiple elimination rounds: the report says 2,048 candidates are still compared within the same decision head, which simplifies retrieval reranking, but it also ties latency directly to candidate count and candidate length, and the 12.04-second median latency indicates that large candidate sets remain offline or asynchronous rather than interactive. Note that the baseline model names in the report (such as Jev-1.13.0, JevK5, and CLM) and baseline configuration details are limited, and readers should not extrapolate these comparison numbers to their own data distributions or Chinese business candidate sets.
Integration and evaluation
The following are recommendations and conditional analysis, not reported facts. Decision one: whether to replace existing “generative selection” with a decision-head interface depends on whether your candidates are enumerable and whether abstention must be explicit. If your business genuinely has cases where the whole group is inapplicable (for example, ticket routing or intent routing), the reported null-aware design is worth validating separately: build a batch of requests from your real distribution with “no suitable candidate,” mix them with answerable requests, sweep the threshold, and record AUROC and recall at a fixed false-rejection rate (for example, 5%); only if this metric is clearly better than your current prompt approach is the interface change worth it. If your candidates always contain a correct answer, the benefit of this capability is limited and the priority of the change should be lowered. Decision two: whether to adopt option caching depends on how your candidate library is reused. First collect a batch of production requests and compute the overlap ratio between candidate sets (the report's examples are progressive overlaps such as ABC, BCD, and ACD); if overlap is high and candidate texts are long, measure the request-latency difference between full cache hits and zero cache hits along the lines described in the report; you must also verify that the same request yields the same decision with and without a cache hit, because the report only says no decision changes were observed in its experiments, which does not guarantee equivalence on your data. If candidates are almost always new, the complexity of a cache layer may exceed the benefit. Decision three: the upper limit on candidate count should be set by latency budget, not by accuracy alone. The report gives 69.88% accuracy and 12.04 seconds median latency at 2,048 candidates, and these two numbers should be read together: if your scenario requires a response within seconds, measure the accuracy curve at smaller candidate sets, find the point where accuracy starts to drop, and then decide whether to expand candidates or keep existing recall pruning. When evaluating, fix the questions and gradually increase candidates (the report's approach of using 83 questions from 32 to 2,048 can be borrowed directly) and measure the share correct at all scales, which exposes stability better than single-point accuracy. Decision four: order robustness should be a fixed regression item before launch. Following the report's method, test the same samples under original order, reversed order, and several random permutations, align results by candidate identity rather than position, and record the flip rate. In compliance, risk-control, or scoring scenarios, flip rate is the metric to watch more than average accuracy.
Limits and open questions
All experimental numbers here come from paper results as relayed by Newzhiyuan and have not been independently reproduced; the report's baseline model configurations and training details are incomplete, so cross-model comparisons should be treated with caution. The report does not state the specific license terms under which the Jeva-4B weights are published on Hugging Face; downloadable weights do not mean commercially usable or redistributable, and the model card and license text should be checked before deployment. The report also gives no API service, pricing, or hosted-availability information; if any calling method exists, the publisher's statements govern. In addition, the reported experiments focus on English tasks such as BANKING77, ToolRet, and MLDR, and performance on Chinese candidate sets, industry terminology, and long documents is unknown. In particular: Jeva-4B is not currently in the KimiSeek model catalog, there is no entry on KimiSeek that exactly corresponds to this version, and any statement about its API availability refers only to the publisher and has nothing to do with this site; if you need to do similar decision tasks on KimiSeek, evaluate the models already listed on this site separately and rely on the pricing page.