Jev:一个专门为软件做判断的 AI 模型

Diogo Almeida 参与过一项影响很大的工作：InstructGPT。他是这篇 2022 年论文的共同作者，研究的是如何利用人类反馈，让语言模型更好地理解和遵循人的意图。原始论文〔1〕

2026 年 9 月 15 日，他创办的 TypeSafe AI 发布了 Jev。这次，模型面向的是软件中的一个个判断环节：选哪个类别、给多少分、某个条件成立的概率是多少。发布公告〔2〕

我对 Jev 的兴趣，正来自这种用途上的变化。如果软件需要的只是一个判断，模型能不能更快、更便宜地给出结果，同时让程序知道这个结果有多大把握？

这篇先把人物、用途和训练思路讲清楚，再看它与大语言模型之间的取舍。以下资料截至 2026 年 9 月 19 日，属于公开资料调研，尚未进行 API 实测。

从 InstructGPT 到软件中的判断

Almeida 此前在 OpenAI 从事研究。按照他在发布文章中的回顾，那段工作的重心，是让模型更好地遵循指令、与人交流；创办 TypeSafe 后，他把注意力放到了这些能力如何转化为自动化上。创始人自述〔2〕

Diogo Almeida，TypeSafe AI 联合创始人兼 CEO，InstructGPT 论文共同作者。

*照片来源：TypeSafe AI 官方团队页〔3〕。*

Jev 由团队共同开发。另外两位联合创始人是 Sasha Sheng 和 Erik Gafni：前者有 Meta/FAIR 的研究工程经历，后者长期从事 AI 系统与创业。团队介绍〔3〕

TypeSafe 把这类模型称为 System One，借用了《思考，快与慢》中快速、直觉式判断的概念。放在软件里，它处理的是范围清楚的局部问题，结果交给代码继续使用。System One 说明〔4〕

这也决定了读懂 Jev 的切入点：先看它能承担哪一步工作，再看整套系统是否因此变得更好。

Jev 的特点：先把答案范围定义好

调用 Jev 时，开发者提供两样东西：一份材料，以及针对材料的问题。

材料可以是客户消息、文档片段，也可以是包含业务状态的 JSON。问题需要指定答案类型，当前有三种：

| 类型 | 可以问什么 | 返回什么 ||---|---|---|| Choice，选择 | 应交给哪个部门？ | 选项、各选项概率和置信度 || Score，评分 | 按标准判断，客户有多不满？ | 分数、等级概率和置信度 || Noul，真假判断 | 客户是否要求退款？ | “是”的概率，介于 0 和 1 |

模型直接返回这些受约束的结果，不生成自由文本。它不会顺手写一封回信，也不会附上一段推理说明。接口介绍〔5〕

它还有一个值得注意的设计：同一份材料可以配上多个独立问题，并行计算答案。如果后一个问题必须依赖前一个答案，就需要分步调用，或者由代码组合处理。并行机制〔6〕

截至本文资料日期，官方列出的 Jev 1.13 输入价格是每百万 token 0.042 美元，输出免费。假设每次总输入 2,000 token，一万次调用的输入费约为 0.84 美元，不含其他系统成本。模型规格与价格〔7〕

官方报告的响应时间是 70～500 毫秒，并说明测试通常在靠近服务所在地的美国西海岸进行。国内访问、长输入和高并发时的表现，需要另外测量。性能说明〔2〕

它能放进哪些工作流程

用一个假设场景来看。

客户发来消息：“同一笔订单好像扣了两次钱，今天能帮我处理吗？”

系统可以让 Jev 判断：客户在反映什么问题？是否表达了紧急诉求？应该进入哪个处理队列？

接下来，代码查询订单和流水，核实是否真的重复扣款，并检查处理权限。需要回复时，再由生成模型组织语言。模型对客户表达的理解，与账本里的实际记录，各有自己的核验方式。

类似的分工可以扩展到几类任务：

• 请求与 Agent 路由。
  从预设处理路径中选择：查状态、调用某个工具、交给擅长复杂推理的模型，或转人工。路由示例〔8〕
• 检索结果筛选。
  先取回候选段落，再判断哪些相关、哪些与问题存在矛盾，供后续回答使用。检索筛选示例〔9〕
• 数据提取复核。
  小模型先抽取字段，Jev 检查是否有原文依据、是否遗漏；发现疑点，再交给更强的模型处理。提取复核示例〔10〕
• 文章引用检查。
  把主张和来源段落放在一起，判断来源究竟是支持、反驳，还是没有涉及这个主张。引用检查示例〔11〕

对公众号写作，最后一种尤其直观：一段引文确实存在，不代表它足以支持文章里的结论。这样的检查可以帮助编辑发现问题，但来源本身是否可信，仍需要另外判断。

这些场景有一个共同点：需要理解语言，答案范围又比较清楚，而且经常重复发生。调用频率越高，单次判断的延迟和成本就越值得计算。

训练方法变在哪里

先把两个层次分开。

常见自回归语言模型的预训练，主要通过预测后续 token 学习语言和知识。之后的后训练，再调整它遵循指令、推理和表达的方式。

InstructGPT 的路线就包括监督微调，再利用人类对回答的排序训练奖励模型，进行强化学习。这是 RLHF，也就是基于人类反馈的强化学习的一种具体实现。InstructGPT 论文〔1〕

TypeSafe 把自己的训练方法称为 RLCD，Reinforcement Learning for Calibrated Decisions，面向校准决策的强化学习。用简化的方式看，几种目标的侧重点如下：

| 训练方向 | 主要关注什么 ||---|---|| RLHF | 回答是否符合人类偏好，例如有帮助、准确、合适 || RLVR，可验证奖励强化学习 | 结果能否通过验证，例如答案正确、代码通过测试 || Jev 提出的 RLCD | 判断及其概率能否与实际结果相匹配 |

这些训练方式可以组合，不能把表格理解成三条互不相干的完整训练流水线。官方训练目标说明〔12〕

“校准”可以这样理解：假设有一百条消息，模型都给出“客户有退款诉求的概率为 80%”。如果其中大约八十条确实有退款诉求，这一组预测就比较符合它给出的概率。

这让程序有机会根据不确定性分配工作：把握足够的情况自动处理，含糊的情况补充信息或交给人。具体门槛要在自己的业务数据上确定。

不过，校准良好和判断准确是两个指标。一个模型如果对所有问题都报 50%，而实际也只对一半，它可能很“诚实”，却未必有用。模型既要能区分情况，也要合理表达把握程度。

接口里还有一个细节：Choice 和 Score 返回的 confidence，是从概率分布计算出的统计摘要，不能直接把 0.9 当成“这次有 90% 正确率”。置信度说明〔13〕

目前能确认的是，官方提出了上述训练目标，并声称采用新架构和并行采样器。我查到的公开资料中，尚未见足以复现的奖励函数、训练数据配方和完整算法。因此，对 RLCD 可以解释其方向，对底层实现还需要保留未知。

概率校准已有长期研究，用强化学习改善模型校准也有公开论文。例如《Rewarding Doubt》采用对数评分奖励，训练模型更合理地表达置信度。这些研究提供背景，却不能当成 Jev 的训练配方。既有校准研究〔14〕 · Rewarding Doubt〔15〕

与 LLM 比，应该比较哪些方面

这里的 LLM，主要指常见的自回归聊天和推理大模型。

有一个前提需要承认：LLM 本来就能做分类，也能返回结构化答案。TypeSafe 自己就提供了一个适配器，让其他大模型使用相似的判断接口，方便比较质量、速度和成本。官方比较工具〔16〕

因此，仅仅输出一个固定格式，解释不了 Jev 的全部价值。更有用的比较是下面这些取舍：

| 比较维度 | 通用 LLM | Jev ||---|---|---|| 输出自由度 | 文字、代码、结构化结果 | 预设选项、评分和概率 || 训练侧重 | 语言生成及多种后训练目标 | 官方强调校准决策 || 输出过程 | 通常逐个生成 token | 多个独立判断并行输出 || 复杂任务 | 可生成计划和多步推理过程 | 更适合拆分后的局部判断 || 不确定性 | 可估计或专门训练校准 | 概率是接口的重要组成部分 || 成本与延迟 | 随模型、推理和输出长度变化 | 针对判断任务优化，仍需同任务实测 || 软件集成 | 自由度大，需要明确约束 | 答案范围先定义，代码组织流程 || 任务边界 | 可覆盖写作、编码等开放任务 | 自由文本生成、精确计算等能力受限 |

表中的 Jev 定位来自其概念说明〔4〕和已知限制〔17〕，应当结合具体任务理解。

比如，一个流程有十个可以同时回答的小问题，Jev 的并行方式可能带来收益；如果每一步都要依赖上一步的新发现，就不能照搬这个预期。便宜模型后面如果接了大量人工复核，总成本也可能上升。

我会用同一批真实样本比较：判断错多少，多少案例可以自动处理，需要多久，以及加上重试和兜底后到底花多少钱。

还有“零幻觉”这个宣传说法。它主要依赖预先限定输出结构的保证。我的理解是：模型不能编出一个选项之外的新类别，却仍可能选错类别。格式合法与业务正确，必须分别验证。官方对类型安全的解释〔2〕

哪些地方值得试

我会先找一个高频、范围清楚、错误容易复核的环节，例如请求分类或引用检查，看看 Jev 能否以更低的成本达到所需质量。

现阶段仍有几项限制需要纳入选择：官方说明英语是主要训练语言，中文效果要单独验证；模型当前只直接接受文本；精确计算、日期比较、复杂间接推理，以及带有干扰或对抗内容的输入，都有已知问题。语言与输入支持〔7〕 · 限制清单〔17〕

对我来说，Jev 提供了一个值得尝试的分工方式：生成模型负责写作和复杂推理，决策模型承担反复出现的语义判断，代码管理计算、权限与执行。

回到那条售后消息，客户最终在意的是问题有没有被正确处理。哪个环节用了什么模型，可以由实际效果决定。Jev 是否值得接入，也应该在这样一条完整流程里得到答案。

资料来源

以下按文中编号列出来源地址，便于复制查阅。

〔1〕原始论文https://arxiv.org/abs/2203.02155

〔2〕发布公告https://typesafe.ai/blog/introducing-system-one-models-and-jev

〔3〕TypeSafe AI 官方团队页https://typesafe.ai/team

〔4〕System One 说明https://docs.typesafe.ai/concepts/system-one

〔5〕接口介绍https://docs.typesafe.ai/introduction

〔6〕并行机制https://docs.typesafe.ai/patterns/fan-out

〔7〕模型规格与价格https://docs.typesafe.ai/models

〔8〕路由示例https://docs.typesafe.ai/patterns/intent-routing

〔9〕检索筛选示例https://docs.typesafe.ai/cookbooks/classifying_rag_passages

〔10〕提取复核示例https://docs.typesafe.ai/cookbooks/sde_cascade

〔11〕引用检查示例https://docs.typesafe.ai/cookbooks/citation_check

〔12〕官方训练目标说明https://docs.typesafe.ai/introduction/machine-learning-primer

〔13〕置信度说明https://docs.typesafe.ai/confidence

〔14〕既有校准研究https://proceedings.mlr.press/v70/guo17a.html

〔15〕Rewarding Doubthttps://arxiv.org/abs/2503.02623

〔16〕官方比较工具https://github.com/typesafe-ai/system-one-adapter-python

〔17〕已知限制https://docs.typesafe.ai/model-jaggedness/jev-1.13