Jev 每周回顾¶
Jev 把语言理解中的一类任务单独做成了接口：给定状态和问题，返回有限选项及其概率，让程序据此分类、路由或复核。它省去了生成完整答案的过程，但能否提高系统的效率，仍取决于判断是否准确、概率是否可信，以及下游是否正确使用结果。
这个专题持续关注 Jev 和相关 System One 决策模型的进展。每期覆盖周三至次周周二，最新一期放在前面，历史回顾保留当时的版本和结论。基础接口、部署边界与评估方法见 Jev System One 决策模型综述。
回顾目录¶
| 周期 | 本期重点 |
|---|---|
| 2026 年 9 月 30 日至 10 月 6 日 | 独立评测开始约束成本与校准宣传，社区应用转向具体工作流 |
2026 年 9 月 30 日至 10 月 6 日¶
本周最值得关注的进展是新增的独立研究，以及社区开始记录接入后的实际效果。官方模型页仍列出 jev-1.13.0；生态中出现的安全决策模型、视觉决策权重和 Agent 插件，分别属于研究或社区项目，不能合并理解为 Jev 的一次模型升级。官方模型页
官方模型与 SDK 状态¶
截至本期，官方公开信息如下。软件开发工具包（Software Development Kit，SDK）的版本与模型版本分别记录，客户端更新不代表服务端换了模型。
| 项目 | 当前状态 | 应用时需要注意 |
|---|---|---|
| 稳定模型 | jev-1.13.0 |
已有决策阈值应绑定具体模型版本 |
| 浮动别名 | jev-latest、jev-preview 均指向 1.13.0 |
官方当前没有单独的 Preview 模型 |
| 输入 | 文本，可组织成字符串、JSON 对象或文本数组 | 官方 Jev 不直接接收图片、音频或视频 |
| 上下文 | 请求总量 64K Token；状态加最长问题不超过 32K | 多问题共享状态仍需满足两个预算 |
| 价格 | 输入每百万 Token 0.042 美元，输出免费 | 这是 Token 单价，完整任务还包含后处理与复核成本 |
| 公布限额 | 100K Token/s、80 请求/s | 官方说明会动态调整，应处理限流并读取重试提示 |
规格及别名来自 TypeSafe 模型文档。生产系统应保存回包中的实际模型 ID；浮动别名变化后，原先调好的阈值未必仍适用。
官方 Python SDK 最新 Release 为 0.7.2，发布于 9 月 26 日，增加可选 HTTP/2 依赖与使用说明；JavaScript/TypeScript SDK 最新 Release 为 0.6.0，发布于 9 月 15 日。两者都是本期的版本基线，不属于本周新发布。Python SDK Releases、JavaScript SDK Releases
独立评测开始给出更具体的结论¶
10 月 5 日，Steven Denney 与 Matthew DiGiuseppe 发布预印本 JEV versus LLMs: Accuracy, Cost and Calibration on Seven Political Science Replications，比较 Jev、既有研究中的模型与人工标注，以及 GPT-6 Luna 和 Qwen3.8-27B。它的重要性在于把成本和概率校准放回了具体任务中，而不是只比较接口价格。论文
| 维度 | 论文报告的结果 | 怎样理解 |
|---|---|---|
| 任务能力 | Jev 在多种任务中达到或接近两种对照模型 | 支持其用于部分文本标注任务，不能外推到所有 Agent 决策 |
| 成本 | 按 OpenAI Batch 价格计算，未发现相对 GPT-6 Luna 的成本优势 | 在线低延迟调用与离线批处理应分别比较 |
| 概率校准 | 单次提问时，优于 GPT-6 Luna 的 Token 概率，但未持续优于 Qwen3.8-27B | 校准优势受任务与对照方式影响 |
| 使用便利 | 选项概率容易读取和解析 | 工程便利有价值，但不等于更高准确率 |
以上是这篇预印本在其研究设置下的结果。10 月 6 日的第二版只纠正了作者顺序的元数据，并非新增了一轮实验。论文版本记录
作为背景，9 月 29 日发表的 Evaluating and Benchmarking the System One Model Jev 覆盖 37 个数据集，使用 Jev 1.13.0 完成 346,009 次请求，报告费用低于 10 美元。对照模型在相同请求上读取候选答案的下一 Token 概率；Jev 在 27 个数据集上优于 Qwen3.8-27B，在全部 37 个数据集上优于 Gemma-4-E4B。论文
这项较早研究还给出了一个实用细节：二分类概率虽能较好排序，固定采用 0.5 阈值却可能表现不佳。在 UNFAIR-ToS 任务上，使用训练数据调整阈值后，micro-F1 从 0.50 提高到 0.75。micro-F1 是汇总全部类别的预测计数后计算的 F1 分数；这个变化说明“返回概率”与“可以直接按默认阈值执行”之间还有一步验证。同一论文
两篇研究采用不同任务、对照方式和计价口径。它们共同提醒我们：通用基准上的好成绩需要进一步落实到业务标签、错误成本和工作流中。用于即时路由时，等待时间可能比 API 费用重要；用于夜间批量标注时，批处理价格和人工返工量则更值得比较。
SecJev 探索领域专用的决策模型¶
10 月 2 日发表的 SecJev: Bringing Security Expertise to System One Decision Models 提出 0.8B 至 9B 的安全领域决策模型。它基于 Kev 的单次前向候选评分器，覆盖工具输出、流量、认证等场景，以 14 个任务、8 类来源构建训练与评估材料。这是一项 Jev-like 研究，不是对官方 Jev 权重的微调。SecJev 论文
作者报告，SecJev-0.8B 在其任务宏平均准确率上超过通用 Kev-9B 20.51 个百分点，但新流量采集条件下仍存在误报变化。这提示了值得继续验证的方向：将明确的安全策略与领域数据结合，小模型也可能完成有效判断；换一个来源或采集环境后，误报率仍需重新测量。SecJev 论文
对于安全工作流，平均准确率之外还要单独观察漏报、误报和人工复核量。模型可以辅助筛选事件或识别可疑输入，最终权限与执行范围仍应由确定性的策略控制。
社区生态开始覆盖实际工作流¶
下面记录截至本周的项目状态，不把仓库更新等同于正式版本发布。
| 项目 | 提供什么 | 适合关注的用途 | 当前边界 |
|---|---|---|---|
| Spring AI TypeSafe | Java 客户端与 Spring AI 集成，当前文档版本为 0.4.0 | 答案评判、内容检查、检索文档筛选、工具选择 | 社区集成；接通接口后仍需验证业务效果 |
| DSH Jev Plugin | DeepSeek Harness 的决策插件 | 技能与文件排序、任务检查、日志筛选 | 独立社区项目，12 项功能默认关闭；主模型继续规划与执行工具 |
| Vev | 基于 Qwen3.5 的 4B、9B 文本及视觉决策模型 | 自托管研究、界面状态判断、图像规则检查 | 研究预览；接口兼容不代表决策行为相同 |
Spring AI 的集成值得注意，因为它把判断放进了已有应用链路：检索后筛选材料，生成后检查标准，调用前筛选工具。0.4.0 的变更记录还修正了工具选择行为，避免用 Jev 判定为零概率的工具补满结果数量。这个细节反映了下游逻辑的重要性：模型排除了某个候选项，应用代码就应保留这个结果。Spring AI 变更记录
DSH 插件则把“返回判断”和“判断产生效果”分别记录。其文档明确区分答案、采纳、权限发放与执行结果，并披露过上下文裁剪影响判断的案例。这比仅记录 API 成功次数更有助于评估 Agent 集成；现有有限样例尚不足以推算自然任务的平均收益。插件说明与验证边界
Vev 的权重已经提供在 Hugging Face，包含 vev-4b 与 vev-9b，可用于研究本地的概率决策服务。需要特别区分许可证：代码采用 Apache-2.0，模型权重采用 CC BY-NC 4.0，仅限非商业使用。它支持图像并不意味着官方 Jev 增加了视觉能力，也不能据此将两者的概率和阈值直接互换。Vev 模型与许可说明
一个技能路由案例暴露了评估难点¶
jev-skill-router 作者公开了接入 Claude Code 后的一周观察。实验实际发生在 9 月 21 日至 28 日，使用日文提示词、52 至 66 个技能和 Jev 1.13.0；它属于本期讨论的较早案例。作者的实验记录
| 记录项 | 数量 |
|---|---|
| 判断次数 | 1,242 |
| 给出技能建议的次数 | 539 |
| 同一会话内 30 分钟内调用建议技能的次数 | 28 |
| 建议后出现对应调用的比例 | 约 5.2% |
作者最终移除了这个路由器，转而采用步骤由 Python 固定的研究流水线，让 Jev 判断新论文或仓库是否相关，让生成模型负责写笔记。固定流程使一个判断对后续处理的影响更容易观察。项目说明
28/539 不能理解成模型只有 5.2% 的准确率。 实验默认处于 Shadow Mode，即只记录判断、不向主模型注入建议；“后来调用了同一技能”衡量的是行为对应关系。它没有证明建议导致了调用，也没有证明未调用的建议全部错误。
这个案例揭示了接入方式对评估的影响。自主 Agent 本来就在选择技能，增加一个建议者后，需要同时追踪建议内容、是否展示、是否采纳和最终任务结果。若只记录模型输出，很难判断增加的调用到底节省了时间，还是带来了更多干扰。
当前更适合从可衡量的判断开始¶
根据这些研究与案例，我更倾向于先选择输入稳定、候选项清晰、结果容易验证的环节。例如：
| 场景 | Jev 负责的判断 | 应用保留的控制 | 主要观察指标 |
|---|---|---|---|
| 文档筛选 | 材料是否有助于回答问题 | 保留原始文档与检索结果，可回退到原流程 | 相关材料召回率、误删率、下游答案质量 |
| 工单路由 | 交给哪个处理组，是否不确定 | 低置信度转人工，不自动扩大权限 | 路由准确率、转人工率、返工次数 |
| 固定流程的结果检查 | 是否满足逐条验收条件 | 由测试或独立验证器确认完成 | 缺陷检出率、误拦截率、额外重试次数 |
| Agent 技能或工具筛选 | 哪些候选项相关，是否均不适用 | 允许返回无匹配，保留回退路径 | 选择正确率、实际采纳率、任务成功率 |
试验时可先固定任务集、主模型、输入材料和超时预算，比较原流程与加入判断后的流程。一次正确的判断只是中间结果，最终仍要看任务成功率、总耗时、人工介入和费用是否改善。
成本也应按完整任务计算：决策 API、主模型调用、额外重试与人工复核均计入，再除以成功任务数。否则，便宜的判断接口可能因为增加误判和返工，让整条流程更贵。
下一期继续关注什么¶
- 官方模型变化：稳定版与 Preview 是否分离，模型别名、价格、限额和语言能力是否变化。
- 独立复测：中文与真实业务任务中的准确率、概率校准、错误类别，以及公平的成本和延迟对照。
- 自托管生态：社区权重、商业使用许可和推理实现的变化，尤其是接口之外的能力与阈值差异。
- Agent 应用结果：从接通和演示继续观察到采纳、任务成功、恢复与返工，区分模拟测试和真实服务测量。
后续每周在同一地址新增一期，继续保留历史结果。若已有结论需要修正，会在对应周次注明修正日期和原因，避免用新版本结果覆盖旧实验。