ChainCatcher 发布题为《深入底层看 Jev，能否戴上“范式革新”的王冠》的长文，作者为博阳，编辑为徐青阳。文章围绕 Jev 的底层架构、后训练方法、校准能力和适用边界展开拆解，核心判断是：Jev 在工程实现上有明显亮点，但现阶段还很难被定义为一次真正的“范式革新”。
Jev 想解决什么问题
文章称，Jev 自称是一个「系统一（System One）」模型，主打不生成长文本，而是直接给出判断和概率。与过去三四年常见的大语言模型不同，Jev 面向的是大量细粒度决策场景，例如「这条记忆是否相关」「这个请求该交给哪个工具」「这起事故是否需要人工复核」。
在这些业务里，开发者往往并不需要模型先写一大段解释，再输出结构化结果，而是更需要快速、直接的判断。文章认为，Jev 切中的正是这类真实需求中的 token 成本和延迟问题。
这条技术路线并不新，历史甚至早于 GPT
文章回顾称，Jev 所代表的方向并非突然出现。早在 2018 年，谷歌推出的 BERT 就采用 Encoder-only 架构，通过双向信息交互处理分类任务。相比后来成为主流的 Decoder-only 模型，BERT 在明确分类任务上一直具备优势。
文中提到，现代 LLM 也长期承担分类器角色。2019 年，OpenAI 在《Fine-Tuning Language Models from Human Preferences》中已开始让模型学习人类偏好；到 2020 年文本摘要研究中，技术路径进一步清晰：由人类标注员比较摘要，再训练奖励模型预测人类更偏好哪一份。奖励模型本身不需要生成长评语，只需读取问题与回答后直接输出分数。
文章认为，这种「继承语言模型理解能力，但不生成文字」的思路，本质上也是 RLHF 体系的一部分，并不是 Jev 独有。到 2023 年《Let’s Verify Step by Step》之后，奖励模型、验证器和评价指标继续细化，逐渐成为 AI 工业界常见的判断工具。
进入 2025 年至 2026 年，相关研究仍在推进。文中列举，2025 年 Galileo 发布 Luna-2，并在后续论文中展示如何把小语言模型训练成「单 Token 分类器」，通过一次前向计算直接读取目标类别概率；Skywork-Reward-V2 则推出从 0.6B 到 8B 的奖励模型系列，优化 LLM 直接评分路线。
从算法实现角度，文章判断，让 LLM 直接从隐藏表示计算候选分数，而不是生成一串文本，并不困难，后文提到的复刻实验里就出现了三种以上实现方式。
Jev 的差异点：RLCD 与并行计算
在作者看来，Jev 的核心差异主要体现在两个方向。
第一，是更通用的后训练目标。过去的评分器多针对单任务训练，而 Jev 试图提供一个更通用的概率接口。文章特别强调，这里的“通用”指向事实概率，而不是人类偏好概率。TypeSafe 团队把「概率校准」放在训练目标中心，并将方法命名为 RLCD，即面向校准决策的强化学习。相较之下，传统偏好奖励模型 RLHF 学的是人类偏好的概率，而非真实世界事件概率。
第二，是对并行计算的极致利用。文章称，Jev 可以围绕同一份材料同时回答上限 250 道问题，只要这些问题之间不存在先后依赖，就能被批量并行执行。这一点与过去主要给 token 打分的评分模型不同。
官方公开的信息：State、Questions 与三种原语
文章梳理了 TypeSafe 已公开的接口设计。Jev 的一次请求包含两类核心输入：
- State（状态）：共享背景材料，例如一段长客户投诉记录或系统日志。
- Questions（问题）：围绕同一份材料提出的多个独立问题。
为标准化提问方式，TypeSafe 将问题收束为三种原语：
- Noul：是非题，直接返回 0 到 1 的概率，例如「这件事紧急吗？」返回 0.95。
- Choice：选择题，返回多个候选项的概率分布，例如「转给技术部 0.8，转给财务部 0.2」。
- Score：打分题，返回各等级概率和最终加权得分，例如「客户愤怒指数 4.5 分」。
文章认为，这三种原语已经覆盖了大量常见判断输出形式。程序拿到数字后，再按自身规则执行后续动作。
TypeSafe 的官方说法是，Jev 只会把 State 读入一次，随后所有问题在同一个请求里围绕这份状态并行、独立地完成判断。如果第二道题依赖第一道题的结果，就必须拆成两次请求。
基于这一点，TypeSafe 鼓励一种名为「Speculative fan-out（推测性并发）」的用法。文章举例称，在处理一篇客诉时，即便最后发现不是系统故障，程序也可以一开始就同时询问「是不是故障」「故障有多严重」「该转给谁」，系统一次并行算出全部答案，再由下游代码丢弃无用结果。
黑盒测试与复刻项目如何还原 Jev
文章指出，在官方披露有限的情况下，外部研究者和开源社区的黑盒测试与复刻项目，成为理解 Jev 内部机制的重要线索。Archer Hume 对 Jev 做了一系列黑盒测试；Kev、NanoJev、minojev 等开源项目也陆续出现。
作者认为，这些项目未必 100% 还原 Jev，但通过比较它们与 Jev 在测试反馈上的接近程度，仍能反推出较可信的内部轮廓。
第一步：共享状态只读一次
文章称，如果每道题都要重新读取一遍长材料，题目越多，重复算力浪费越大。Archer Hume 查阅 API 计费账单与延迟数据后发现，提交一道最简单的是非题时，计费为 268 个输入 token；增加到两道题时，计费变为 276 个，多出的只是新增题目本身的字数开销，共同的 State 并未被重复计费。
同时，在题目数量增加到接近 100 道之前，服务端响应时间几乎保持水平。文章认为，这与官方「共同材料只读一次、各题批量计算」的说法高度一致。
在复刻方案中，Kev 的实现最清晰：先一次性处理状态，把中间结果冻结在 Kv Cache 中，后续 50 个问题共享这套 Kv Cache 继续计算，无需重复读取原文。
第二步：问题之间严格隔离
另一个关键问题是，多道题并行计算时是否会互相“串台”。Archer Hume 为此设计了「暗号实验」：在问题 A 中加入「暗号是 ZEBRA-7741」，再在问题 B 的选项中要求模型选出「另一道题提到的暗号」。结果显示，Jev 给出正确暗号的概率是 0.00。
但如果把同样的暗号从问题 A 移到共享的 State 文本里，问题 B 给出正确答案的概率会升到 0.90 以上。文章据此判断，Jev 对问题之间做了严格物理隔离：共享材料对所有问题可见，但相邻问题无法互相偷看。
Kev 为此给出两种实现方式。第一种是注意力掩码：当系统把「冻结的投诉原文 + 问题 1 + 问题 2」放在一起计算时，模型处理问题 1 时，掩码会把问题 2 的区域强制变成 0，只允许它关注共享原文和当前问题。
第二种是独立分支复用。文章提到，对于带有循环特征或特定架构的底座模型，如文中提到的 Qwen3.5，注意力掩码无法有效分隔，于是模型在读完投诉原文后，会以冻结记忆为起点，直接分裂出 50 条平行分支。每条分支都继承主干上已经处理好的投诉记忆，因此同样不必重读原文。
第三步：候选项之间会互相影响
在选择题内部，候选项如何被计算，是文章拆解的另一重点。最传统的方法是线性头加 Softmax，也就是 Zefan Open-Jev 版本尝试复现 Jev 时采用的模式。按这种方式，每个候选项会被独立打分，再通过 Softmax 转成概率。
但 Archer Hume 的测试显示，新增一个无逻辑的干扰项，例如「坏天气」，会改变原本两个正常选项之间的相对赔率。在十组随机排列测试中，这种变化都存在。文章据此认为，Jev 不是完全独立的「黑屋盲审」模式，候选项在最终打分前一定发生了交互。
开源社区给出两种主要实现图纸。
第一种是 Kev 的「指针头（Pointer Head）」模式。文章把它比作同场群面：模型先同时看到「财务、技术、坏天气」等所有候选项，形成整体语境，再从最后位置回头逐个指向前面的候选项并打分。由于评分发生在看完所有选项之后，参照系已经变化，原有候选项的分数也会随之波动。
第二种是 NanoJev 等项目采用的「候选间注意力模块（Inter-candidate Attention Module）」模式。这里每个候选项先被编码成特征向量，随后这些向量被一起送入一个注意力模块中相互比较和权衡。新增「坏天气」这样的干扰项后，整个比较结构会被重组，最终分数也会变化。
文章认为，这种候选项之间的“互相拉踩”并非炫技，而是因为真实业务中的正确答案往往是比较出来的。文中举例称，如果问题是「埃菲尔铁塔在哪里」，候选项为 A.欧洲、B.法国、C.巴黎，那么模型同时看到这三个选项时，选项本身就构成了题意线索，说明题目考察的是最高精度的地理位置。
第四步：直接输出概率，不走文本生成
在结果输出阶段，TypeSafe 的官方说法是，Jev 直接返回概率数字，不逐字生成文本。Archer Hume 的外部探测也支持这一点：当候选项从 2 个增加到 200 个时，API 返回文本虽然更长，但服务端处理时间并未按比例拉长。
文章据此判断，Jev 跳过了最耗时的自回归生成步骤。至于最终概率从哪里提取，不同复刻方案做法不同：
- openjev/openjev：在模型本该生成第一个字的作答位置，直接读取词表中指定候选字母 Token 的原始打分（Logits）。
- Kev：由指针头直接输出比对得分。
- minojev：由外挂的共享评分模块输出结果。
作者总结称，只要流程设计得当，大模型完全可以放弃冗长文本生成，在运算末端直接抽取数学概率，完成一次系统级自动决策。
不过，文章也给出明确判断：从目前评测和复刻所还原出的架构看，Jev 的结构本身并不复杂，很难称得上“范式革新”，更像是面向特定场景的一次优秀工程优化。
准确率从哪里来：关键在后训练而不是架构
文章认为，架构主要解决速度问题，Jev 较高准确率的来源在于 TypeSafe 所称的 RLCD 后训练方法。由于 RLCD 并未公开，外界只能从开源社区的尝试中推测其训练题构造和算法实现。
训练题如何构造
最简单的方式是直接合成。文章提到，Hmm 版复刻让 DeepSeek V4.1 在代码中列出 100 多个工作场景，包括退款处理、故障排查、检索相关性、邮件分流等。每次从中选一个场景，再搭配材料形式和出题要求，例如：
- 用一段带无关细节的长消息，写几组退款案例；
- 加入一个容易被关键词误导的案例；
- 每个案例附上 4 至 5 道选择、是非或等级问题。
随后由 DeepSeek V4.1 Flash 生成整份材料、问题、候选项、判断标准和答案。为了验证题目是否可用，系统会隐藏原答案，再让 DeepSeek V4.1 Flash 重新作答，默认调用 3 次，并要求每次给出选项概率。代码规定，至少有 2 次有效回复的题目才能保留。
Kev 的方法则是把现有新闻分类、评论情绪、文本蕴含等数据集统一转换成「材料 + 问题 + 候选答案」格式，再由模型生成规则和事实，算出答案并写成文字。
文章还提到，9 月 24 日的 Kev-4B 尝试利用真实工作环境构建题目，收集了 5,219 篇真实消费者金融投诉，围绕「涉及什么产品、主要问题是什么」制作题目。题目生成后，只有当两位不同教师模型的判断都与消费者原始填报标签一致时，标签才会被保留。
为了避免模型通过 Reward Hacking 硬背答案，复原试题还会设计成对陷阱题。比如规则完全相同，只改掉一个关键名字，签字人从有权限的 Mira 换成没权限的 Noah，答案就直接翻转。文章认为，这类题目能迫使模型学习问题与选项之间更深层的表征关系。
LoRA、蒸馏与交叉熵是否足够
在训练方法上，文章称，目前大多数采用后训练的复现版本，基本都使用「LoRA + 教师蒸馏」来提高正确选项的概率。
以 Winnow 为例，它在 Gemma 4 12B 指令模型上进行 LoRA 微调。LoRA 的作用是保留底座原有权重，只训练一小部分修正参数，以降低修改成本。
Winnow 同时使用两种监督方式：一种直接给出标准答案，要求模型提高正确选项的概率；另一种提供教师对所有选项的概率分配，让学生模型向这份分布靠近。只有当教师选出的第一名与标准答案一致时，第二种监督才会被采用。
两种监督都通过交叉熵计算训练误差。文章解释称，只有标准答案时，正确选项概率越低，惩罚越大；使用教师分布时，训练会推动学生模仿教师对各选项的分配，例如教师给 A、B、C 分别分配 80%、15%、5%，学生就会被要求学到这三者之间的区别。
作者认为，对于已经准备好题目、答案和参考分布的概率预测任务，LoRA、蒸馏和交叉熵通常已经够用。但问题在于，蒸馏学到的是教师概率，而不是 RLCD 所宣称的现实概率。如何跨过事实概率与教师概率之间的差距，现有复现并没有明确思路。
文章判断，如果 Jev 真要实现其宣称效果，理论上仍需要更大规模数据和更高样本效率的学习方式。不过，即便没有完全解决这一点，只要小型判断模型能接近大模型的判断准确度，它本身也已经具备实用价值。
校准能力可能才是 Jev 的真正看点
除准确率外，文章认为 Jev 的另一项关键卖点是校准能力。模型答对多少题，与它是否准确表达把握程度，并不是一回事。一个模型可能只答对 70%，却总报 90% 把握。
为验证 Jev 是否存在盲目自信，Archer Hume 做了一场「测谎实验」。他先给 Jev 输入 1,200 道 MMLU 测试题，再把所有被选中的答案按系统报出的概率分成 10 个档次。经过加权计算后，Jev 的校准误差为 0.031。
在 30 道简单三位数乘法中，Jev 的正确率为 86.7%，而它自己报出的平均把握是 83%，两者较为接近。当题目换成更难的「两步应用题」时，正确率降到 32%，而平均把握也同步降到 30%。
文章指出，后训练通常可以改善概率表现，但很多时候也会让模型更自信。为了复现 Jev 较好的校准能力，开源项目采用了一些方法。例如 Kev 会明确要求模型在证据缺失时降低确定性：训练集中加入关键证据被移除的样本，并在答案中降低相应概率，从而惩罚模型在无依据时把概率集中到某个选项。
不过，更多复现采用的是温度校准。工程师会拿一小批模型未见过的测试题，让训练好的模型作答；如果发现模型过度自信，就通过这批题计算整体自信度需要回调多少。调好后，模型以后输出的概率会被整体压平，像是戴上一个“谦虚滤镜”。
文章强调，温度校准不会改变同一道题的选项排名，因此最高概率答案不变，但概率门槛和按概率计算的评分会变化。以 Kev-9B 为例，做完温度校准后，校准误差从约 10.6 个百分点降到 4.2 个百分点，而答对题数没有变化。
作者认为，这种方法更像治标不治本，因为它主要来自整体自信度下调，而不是模型更准确地区分自己何时该自信。如果 Jev 真正实现了更有效的校准提升，那么 TypeSafe 在这一环节可能确实掌握了一些关键技巧。
Jev 的适用边界：有价值，但不够通用
文章明确表示，Jev 具备现实应用意义。它把原本只需要快速决策的任务，还原成快速决策本身。在 Agent 流程中，请求分类与路由、检索结果排序、按明确要求逐项检查等场景，都可能适合 Jev。客服分流、商品归类、反馈分析、数据标注，也都是高频应用。
但它是否具有“范式价值”，取决于适用边界有多大。文章认为，真正的通用性至少还要跨过两道坎：困难任务和泛化能力。
困难任务仍是明显短板
文章先定义了什么是判断中的困难任务：步骤越多、条件越多、细节理解要求越高，问题就越难。比如识别「用户想退款」只需理解字面语义，但判断「这笔退款该不该批」则需要核对日期、计算期限、比较条款优先级，难度明显更高。
在 JevBench 的困难题测试中，JevBench 设定了多条件判断、连续查找证据、比较日期和数字三个难度因子。结果显示，Jev 的多步查找准确率为 85.7%，长政策判断为 60.5%，时间与数字判断只有 26.7%，都明显低于 Flash 级模型。困难题合计，Jev 的正确率为 74.1%，而 DeepSeek V4.1 Flash 为 95.0%，接近人类专家水平。
文章同时给出速度对比：相应测试请求的中位耗时约为 0.67 秒和 3.15 秒，Jev 速度接近快 4 倍。但作者认为，在复杂任务上如此大的准确率差距，已经足以影响实际选择。
文中还指出，这里的多步查找并不等于真正多步推理，主要仍是查找任务。Archer Hume 的测试也显示，Jev 在简单乘法中正确率高达 86.7%，但换成两步应用题后，正确率立刻降到 32%。
briantrust 的更细致测评也得出类似结论。该测试让 Jev 和 GPT 5.6 Luna 从两个候选回答中选出正确答案，最终比较了 616 道有效题对。两个模型在知识题上的差距只有 1.6 个百分点，但在数学与推理上扩大到 19.3 个百分点，在代码题上达到 20 个百分点。
作者据此判断，Jev 很难说已经跨过困难判断这道门槛。
泛化能力存在明显不稳定性
文章认为，如果 Jev 真正通用，它应该能把学到的东西迁移到其他问题上，提升新任务判断精度。否则，它仍只是一个适用范围稍宽的专用判断模型。
现有测试显示，Jev 确实具备一定泛化能力，但这种能力在领域内并不稳定，跨出熟悉场景后风险更大。
首先，在完全相同的任务和事实下，Jev 的判断会明显受到信息呈现方式影响。OpenProse 实验在不改变事实、问题和计算量的前提下，只调整关键信息在文本中的位置：当关键关系集中在前部时，Jev 正确率为 80.5%；当这些关系被移到中间时，正确率直接降到 40.9%。
文章认为，这说明即便不更换业务领域，Jev 的表示稳健性也不足，判断能力高度依赖外部程序如何喂数据。
其次，在同一评测体系下换成新题目后，Jev 的表现波动也很大。JevBench 新版 v1.4 新增 308 道封闭难题后，Jev 的正确率从公开题上的 86.6% 跌到 36.7%；作为对照，使用思考模式的 DeepSeek V4.1 Flash 仍维持在 94.8%。
文章据此指出，Jev 在公开题上的高分，无法自动延续到未知复杂测试中。
在真实业务迁移中，Jev 的泛化表现同样有正有负。正面案例来自 Agent Journal 的提示注入检测：Jev 在原测试集上的准确率为 83.65%，迁移到另一份包含 2,000 多条外部数据的测试集后，准确率反而升到 95.58%，明显高于传统基线模型。
但在逻辑更复杂的业务里，这种泛化会失效。Scarif Labs 曾用 Jev 判断软件更新是否安全，当模型从一个软件生态迁移到另一个生态时，区分安全与危险更新的 AUROC 从 0.851 降到 0.605，已经接近随机猜测的 0.5。
作者总结称，至少从现有证据看，Jev 的泛化能力仍然有限，而且存在较大不确定性，距离真正的通用泛化标准还很远。
更适合放在哪些环节
既然 Jev 尚未跨过困难任务和泛化两道门槛，文章给出的建议是：把它放在标准明确、证据集中、判断结果可检查或纠正的环节。
仍以退款场景为例，判断用户是否表达退款意愿、投诉涉及物流还是商品质量、是否需要补充凭证，这些都属于可单独验证的语义判断，出现频繁，也不需要每次都让主模型展开推理。Jev 可以承担这类初步分流工作。
但一旦进入是否批准退款，就需要代码核对日期、按规则计算退款金额、处理条款冲突和例外情况。文章提到，TypeSafe 自己也建议把数学运算和日期比较交给代码，并尽量减少判断中的多层依赖。
对于更依赖精度的用途，例如奖励模型，情况会更复杂。因为这类任务往往要识别那些表面合理、实际有错的回答，模型需要分辨细微差异，还要抵抗表达风格干扰。至于规则本身就难以明确界定、带有较强主观评价的任务，文章建议至少先测试 Jev 的准确率，再决定是否部署。
单点响应快，不等于整个 Agent 更快
文章还提醒，Jev 自身响应快，并不自动意味着接入后整个 Agent 系统会更快。只有当它能提前处理一批简单请求，让这些请求不再调用主模型时，速度和成本优势才可能兑现。
如果每次都先调用 Jev，随后仍要调用同一个主模型，那么新增的判断步骤必须节省足够多的后续工作，才能抵消自身耗时和费用。
文中举例称，在 GitHub 上一组 Agent 记忆检索实验中，系统引入 Jev 判断检索到的信息是否有用。为了避免 Jev 错误丢弃有用信息，开发者不得不反复调整判断标准。虽然最终让 20 个常规案例全部通过，但系统总延迟从 649 毫秒升到 1087 毫秒，每千次调用费用也翻了两倍多。
作者认为，如果主模型本身就能从复杂材料中筛选答案，那么在前面再加一个 Jev 作为判断器，不仅增加等待时间，还会带来误判后漏掉关键证据的风险。
结论：工程价值明确，“范式革新”仍言之过早
文章最后把问题收束到一个核心：Jev 到底在学习什么。作者认为，一个用于判断的模型，真正要学的是如何根据新增事实作出有效判断，而这本身就是极高难度的表征学习。
文中以退款为例区分了三类问题：识别「我想退款」主要依赖语言理解；判断「按这份政策，该不该批准退款」需要理解政策、对照购买日期和商品状态、处理例外；再进一步问「退款是否有助于留住这位客户」，则已经进入对行为后果的预测。这三道题都可以输出「是的概率」，但背后依赖的知识和计算完全不同。
作者据此表示怀疑：仅凭目前文章所拆解出的这套学习方法，是否足以承载如此复杂的表征，仍然存疑。
不过，文章也承认，Jev 仍然可以被视为一个设计巧妙的工程工具。在规则清晰、材料齐备的业务管线里，它能够明显压缩等待时间和算力成本，这一点具有现实价值。
但在证明它确实学到了某种通用判断法则之前，让它戴上「范式革新」的王冠，文章认为还为时尚早。