新加坡国立大学团队提出Jeva：让AI做选择题先分离理解与比较

你有没有想过，AI面对一道选择题时，内部到底在盘算什么？

客服系统要判断一条投诉该分给“账单部门”“技术支持”还是“物流部门”，智能助手要从一堆工具里挑出一个来用。任务看着不复杂，无非是从若干选项里选一个。可真去翻主流AI系统的内部逻辑，会发现一件挺反常识的事：不少所谓的“决策模型”，干的还是件笨活——把问题和所有选项拼成一整段文字，塞进模型，再看哪个词的概率最高。

这套做法听着没毛病。可只要稍微往深里追问几句，麻烦就全冒出来了。

选项换个顺序，答案会变吗？选项从3个变成300个，模型还认得出来吗？如果所有选项都不对，模型知不知道说“没有一个对”？同样一批候选工具，下一次换个新问题，还能不能不用重新算一遍？

新加坡国立大学的Qi Li和Xinchao Wang这篇论文，盯的就是这四个问题。他们给新系统起名Jeva，想从根子上把这些毛病治掉。

拼接式决策的四个老毛病

问题到底出在哪？先看现在很多开源“系统一”模型的做法。

所谓“系统一”模型，指那种不必生成一大段推理文字、直接给出判断结果的快速决策模型。它们采用的是一种叫联合编码的路子：把问题状态和所有候选选项一股脑塞进同一段文本，走一遍语言模型的编码器，再从输出的词概率里读答案。

系统一模型：指能够直接给出结构化判断（比如选择、是否、打分）而不需要生成长篇推理文字的AI决策模型，强调低延迟和直接性。

乍看很自然，但这个做法把三件本该分开的事情捆在了一起：语义理解、选项之间的相互比较、以及答案是否存在的判断。捆在一起的后果是什么？

论文里给出的数据很扎实。拿一个叫Typed Decisions的测试集来说，几个主流模型在选项顺序被打乱之后，答案翻车的比例相当高：JevK5翻车26.17%，InternDecision-4B翻车22.67%，连专门做校准优化的KEV-4B也有17%左右的翻车率。也就是说，差不多每四五道选择题里，就有一道题仅仅因为选项换了个排列顺序，模型给出的答案就变了。

这就像考试时同一张卷子只把选择题的A、B、C、D顺序打乱，分数却能拉开一大截。要是连换个座位重抄一遍答案都会变，那这张卷子考的到底是你的知识，还是你蒙题时的手气？

候选数量的问题更直接。不少按固定答案符号表搭建的实现，内部其实只预备了一个有限的答案池，候选选项一多到几十个甚至几百个，模型就不认了。论文测试里，InternDecision两个版本在候选数到128个之后，支持率直接掉到0%，等于当场罢工。

另有一个常被忽视的隐患：不少系统把“所有候选里哪个得分最高”和“候选里究竟有没有靠谱答案”当成了一回事。模型只是在给定选项内做归一化打分，却从没真正回答过：这些选项里会不会压根没一个是对的？

把这四件事拆开看，正是Jeva这篇论文想要解决的核心矛盾。

独立编码：把“认识”和“比较”分开

Jeva的第一个关键设计，是把问题状态和每个候选选项分开编码。系统用同一个共享的语言模型骨干，分别处理请求文本和每一个候选选项文本。

具体说，请求文本用一个模板，候选选项用另一个模板，两边互不混入。也就是说，模型在“理解”候选选项A是什么意思时，完全不知道这次请求里还有B、C、D存在，更不知道当前问题是什么。

语言模型骨干：指负责将文字转换成向量表示的核心神经网络组件，这里具体用的是Qwen3.5-4B。

好处一眼可见。候选选项内容若稳定不变，比如一个工具注册表、一份文档库、一套标签词汇，它们的向量表示就能提前算好存起来，下次新请求来了直接取现成的用，不必重算。

好比一座大图书馆，若每次有读者借书，管理员都得把全馆的书重翻一遍、重贴一遍标签，效率得多低。独立编码相当于事先把每本书分类编目、贴好标签摆上书架，读者来了照自己需求查目录就行，不用等管理员现场重新整理全馆图书。

如果不这样做，每一次新的借书请求都要把整个图书馆重新理一遍，书架越大，等待时间越长，这正是前面说的“候选数一多就跑不动”问题的根源。

但独立编码也带来一个新麻烦：选项之间互相不认识对方，那模型怎么知道该选谁呢？毕竟很多选择题的答案，恰恰取决于候选选项之间的相对关系，比如“技术支持”和“账单问题”放在一起时哪个更贴切，可能跟“技术支持”单独出现时完全不是一回事。

决策模块：让状态去“读”选项，而不是选项去“认识”彼此——这就引出了Jeva的第二个核心设计：一个轻量级的决策模块，专门负责把请求状态和候选选项池联系起来。

这个模块每轮只更新请求状态，候选选项自始至终纹丝不动，相当于一座固定的“记忆库”。具体做法是：让请求状态像做阅读理解那样，去衡量记忆库里各个候选与本轮状态的相关度，再把汇总到的信息用来刷新自身的内部表示。整个过程中，候选选项一动不动。

论文给这套做法起的名字是候选条件状态细化，底层用的是注意力机制的一个变体。技术实现上还加了一条带熵正则化的权重分配规则，目的是让模型在盯住某个选项时别把全部注意力一股脑压上去，留出一点“犹豫空间”。

所谓候选条件状态细化，说的是决策模块只刷新请求的内部状态表示，候选选项的向量保持原样，于是状态可以依据当前这批候选来调整自己的判断倾向。

论文用一个很直观的实验说明了这套机制的价值。设有候选项A、B、C，其中C有C+和C-两个版本；把C+换成C-之后，A和B之间的相对优势竟然反了过来——本来A更优，换掉一个候选项后变成B更优。独立打分做不到这一点：在独立打分里，A和B的得分跟C是谁毫无关系，加不加C、换成哪个C，A和B的相对排名都不会动。

打个比方，面试一个候选人，假如面试官是孤立地给每个人打分，那中途换一个陪考的人进来，不该影响原先两人谁更强的结论。可现实招聘往往不是这样，有时一个候选人显得出色，恰恰是跟在场其他人比出来的。Jeva想抓住的就是这种相对比较效应，而独立打分的老办法天生抓不到。不引入这种状态细化机制，那些必须靠“参照系”才能做出的判断，模型就永远答不对。论文之所以反复强调“单块决策模块就能实现偏好反转”值得单独证明，原因也在这里。

覆盖率估计：把“没有答案”和“答案难选”分开

接下来是Jeva一个很巧妙的设计——覆盖率门控。

前面说过，不少系统用归一化打分来表达候选项之间的相对优劣，可这个相对优劣跟“这批候选项里究竟有没有一个是对的”完全是两码事。Jeva为此单独训练了一个组件来回答后一个问题：判断至少存在一个可接受候选项的概率有多大。

覆盖率门控就是一个独立估计“候选集合中是否存在正确答案”的概率模块，它跟候选项之间相互竞争的打分机制彼此独立，判断边界由一个学习到的阈值和温度参数来控制。

论文用一个很清楚的数学性质说明了这个设计的用意：只要候选项的最高得分不变，往候选集里塞进得分更低的新选项，覆盖率判断的结果就不会受影响。换句话说，加一堆明显不靠谱的选项进来，不该动摇模型对“已有最佳选项靠不靠谱”的判断。传统做法是在所有候选项（含一个显式的“无”选项）上统一做归一化，恰恰做不到这一点——候选数一变，“是否存在答案”的判断也跟着漂移。论文专门用公式证明了这种漂移必然背上一个log K的负担：候选项越多，被无中生有判成“没有答案”的倾向就越强。

这就像医院的分诊台。病人挂号时，分诊护士首先要判断的是“这人需不需要看急诊”，而“急诊科里哪个科室最适合接诊”是另一个完全独立的问题。两件事混在一起做会怎样？比如拿候选科室的数量去反推病情轻重，那医院科室分得越细，病人反而越容易被误判成“轻症不用急诊”，显然荒唐。覆盖率门控干的，就是把分诊和科室匹配拆成两道独立工序。

实测效果上，在Banking77这个包含3080条匹配请求的数据集上，Jeva的null检测AUROC达到98.66%，对比之下KEV-4B是93.61%，InternDecision-4B是84.27%，JevK5只有79.44%。换算一下，在约5%误判率的前提下，Jeva能识别出93.88%的“确实没有答案”的情况，这个数字相当亮眼。

AUROC是一种衡量二分类判断准确性的指标，数值越接近100%，说明模型区分“有答案”和“无答案”的能力越强。

对称聚合与候选规模扩展

接下来说Jeva怎么应对候选数量的变化。

模块内部采用对称聚合方式：无论候选选项以什么顺序喂进去，决策模块处理它们的数学方式都保证结果不受顺序影响。论文给出了严谨证明——固定模型参数、用精确算术计算，打乱候选顺序只会让输出概率的顺序相应打乱，最终的状态表示、null概率和打分类输出全都保持不变。

对称聚合是一种数学设计，它保证模型处理一组无序候选集合时，输出结果不取决于候选项在输入里的排列顺序。

实测数据直接印证了这个理论保证。在600道选择题上，原始顺序、倒序以及若干随机打乱顺序下，Jeva的翻转率是0.00%，概率分布变化的均值只有3.17乘以10的负8次方，基本等同于完全不变。相比之下，表现最好的对比模型翻转率也有17%。这是从“大概率稳定”到“数学上保证稳定”的质变。

候选数量能不能灵活扩展，关键在于Jeva的打分头是共享的：候选变多，它不需要重新定义输出空间；在固定宽度和深度下，计算开销随候选数线性增长，而不是撞上某个硬编码的上限就直接崩掉。

在ToolRet这个基于工具检索场景构造的诊断测试上，候选数从32一路拉到2048个，Jeva全程完整支持，聚合准确率达到78.40%；对比的JevK5靠递归式逐个比较也能跑完全程，但准确率只有64.00%。更关键的是，在2048个候选项的极限测试下，经过批处理优化，Jeva的中位延迟从94.459秒降到12.040秒，提速达到7.85倍。

现实里的候选集合几乎永远在变大，电商平台的商品库、企业内部的文档系统，数量只会越滚越多。一个系统如果在选项变多时“做题能力”就突然失效，那它在真实世界里根本派不上用场。只能应付16选1、一换成2000选1就彻底歇菜，说到底就是个玩具。

缓存复用：候选不变就不用重新算

最后一个核心设计，是Jeva的缓存机制。

候选选项的向量表示本来就是各自独立算出来的，跟哪一次请求没有关系。既然这样，算好的结果完全可以存下来。下回新请求碰上同样的候选项，直接取现成的用，编码器不用再跑一遍。

论文给出两种缓存路子。精确集合缓存的条件很死：新请求的候选集合必须跟之前一模一样，连顺序都不能变，才算命中。混合缓存则灵活得多，候选集合哪怕是全新拼出来的，只要里面有些候选项以前见过，那部分算好的结果照样能拿来用，只把真正没露过面的新选项送去重算。

两者的差别说白了就在复用的门槛：精确集合缓存要候选集合完全一致才肯复用，混合缓存则允许候选集合重新组合、部分选项是新面孔，已有选项的计算结果依然能接着用。

实测数字很扎眼。50条匹配的MLDR长文档查询上，候选复用率按0%、约50%、100%三档来测。复用率拉到100%时，混合缓存的中位延迟加速比达到27.98倍，p50延迟从2102.0毫秒掉到75.1毫秒。共享候选库的常规场景下也不差，Typed Decisions数据集上的延迟从93.1毫秒降到46.6毫秒左右，99.2%的候选项重复编码被躲掉了。

这就像一个常年服务固定客户群的客服中心。客户每次来电，客服都把整本产品手册、所有常见问题从头念一遍再作答，效率低得离谱。更合理的做法是手册提前整理好、分门别类搁在手边，客服听清这次客户问什么，翻到对应那页就行。候选项缓存干的就是这件事：不随请求变化的内容提前备好，真正花时间处理的只有每次都不一样的那部分，也就是客户这次具体说了什么。没有这套缓存，每来一个新对话都得把整个产品库从头编码一遍，响应速度自然快不起来。

论文还专门查了一件事：不管开哪种缓存，模型给出的决策结果都没变，最大绝对概率差仅0.00736，基本可以忽略。缓存加速的是计算过程，决策逻辑本身没有让步。

整体表现：一套方案打包解决四个问题

把这几块拼起来，看看整体效果。

Jeva-4B的语言骨干用的是Qwen3.5-4B，上面只加了一个决策模块，走LoRA微调，训练参数量1337万个。对一个完整大模型来说，这个数字相当轻。

LoRA是一种低秩适配微调技术，只训练模型里一小部分额外参数，训练和部署开销大幅降低，原始大模型的通用能力同时保留下来。

通用评测套件上，Banking77和MASSIVE两个数据集在多个候选数配置下，Jeva的准确率都超过90%。Mind2Web的跨任务、跨网站、跨领域三个子任务，分别拿到79.99%、62.25%、66.23%，八项测试里七项是最佳表现。Typed Decisions测试把Noul（是非判断）和Score（打分）两类任务合在一起看，Noul的Brier分数（越低越好）只有0.0184，对比模型里最低；Score的MAE也是最低的0.2315。

开头提的四个毛病——顺序排颠倒、候选数量上限、无答案判断缺失、重复计算浪费——这套系统逐一给出了对应解法。独立编码对付缓存复用，候选条件状态细化补上相对比较的表达能力，覆盖率门控管答案存在性判断，对称聚合机制处理顺序敏感性。

表格数据

| 测试项目 | Jeva-4B | 最佳对比模型 |

|---|---|---|

| Banking77 K=16 准确率 | **91.62%** | InternDecision-4B 75.03% |

| MASSIVE K=16 准确率 | **90.22%** | InternDecision-4B 75.79% |

| 候选顺序翻转率 | **0.00%** | KEV-4B 17.17% |

| null检测AUROC | **98.66%** | KEV-4B 93.61% |

| 2048候选延迟加速比 | **7.85倍** | - |

| 全量复用缓存加速比 | **27.98倍** | - |

写在后面

读完论文，有个地方让我反复琢磨：Jeva其实没提出什么惊天动地的新模型结构，注意力机制还是常规的，语言模型骨干也是常规的，真正的创新落在“怎么组织计算流程”上。

这让人想到软件工程里那个老概念——关注点分离。语义理解、相互比较、答案存在性判断，这三件事过去常被混在一起处理，Jeva用架构把它们物理隔开，而不是指望一个端到端模型自己隐式学会区分。这种思路跟模型大小、参数规模没多大关系，更像一种工程纪律，一种对问题结构的诚实面对。

还有个细节值得留意。论文里那个几何证明讲的是候选选项被替换、两个未变选项之间偏好反而翻转，在决策表示空间里只用了二维向量就把道理说清了。有些看似复杂的模型行为，拆到最本质的层面，用非常简洁的数学语言就能表达，复杂性往往来自工程实现的堆叠，而不是原理本身有多晦涩。

论文留下的一个问题是：候选集合规模继续往上走，走到几十万甚至上百万量级，现在这种“候选记忆库”式的缓存方案还撑不撑得住。论文只测到2048个候选项，这个数字对工具调用、客服分流之类的场景也许够用，但一个要在百万级商品库里做决策的系统，答案还得靠更多数据来验证。

Q&A

先看Jeva的定位。它是新加坡国立大学团队提出的决策原生架构，针对的是AI做选择题时四个结构性问题：认不出没有答案的情况、选项顺序会左右判断、候选数量受限、计算没法跨请求复用。

它和传统联合编码决策模型的做法不一样。后者把问题跟所有候选选项拼成一段文本一起处理。Jeva改用独立编码，请求和每个候选项分别处理，再由一个轻量决策模块把两边联系起来。这么做的结果是，候选项的计算结果能跨请求复用，候选顺序也不再影响结果。

候选数量多的时候表现如何？在2048个候选项的测试中，Jeva仍能完整支持并保持较高准确率。经批处理优化后，中位延迟比未优化版本提速7.85倍。部分对比模型候选数一超过128就直接失效。