Jev：面向快速决策的 AI 如何工作
Neaptide · 2026年9月27日 · 12 分钟阅读
了解 Jev 的 Choice、Score、Noul、概率和局限，解读 System One 的公开性能数据，并在自己的业务中设计测试。
本文目录
客户发来一条消息：“产品目录导出不了。CSV 正常，XLSX 不行。今晚之前必须把文件发给供应商。”应用需要判断问题属于哪一类、故障对工作有多大影响，以及下一步该怎么处理。这时，模型生成一大段回答可能只会增加处理步骤：系统真正需要的是几个具体的值。
Jev 是 TypeSafe 为这类判断开发的模型。 你向它提供上下文，以及预先定义好答案类型的问题；它返回程序可以直接使用的值和概率。TypeSafe 将这种方式称为 System One。该模型不会撰写邮件、生成代码，也不会解释推理过程。
在 2026 年 9 月 15 日的公告中，TypeSafe 开放了早期访问，并强调决策速度和低成本。要理解 Jev 的实际价值，可以沿着完整的处理路径看一遍：从向模型提问，到应用执行操作。
Jev 在程序中承担什么工作
请求包含两部分：state 是需要评估的材料，questions 是针对这些材料提出的问题。上下文可以是一条消息、包含工单字段的 JSON 对象，或包含文本数据的数组。同一次调用中的问题共享上下文，但各自独立评估。Jev 目前只接受文本数据，图片和音频需要先转换成文字或所需字段。
在这个例子中，可以分别问：客户需要哪个部门处理？问题有多影响工作？客户是否要求与工作人员沟通？“把技术工单送入对应队列”的规则仍然写在代码里。客服流程改变时，开发者可以单独修改规则，不必连同问题一起重写。
拆分问题本身就有价值。“我们应该怎样处理这位客户的问题？”同时涉及文本理解、业务优先级和允许执行的操作。把问题问得具体，才更容易定位系统在哪一步判断错了。TypeSafe 的文档也推荐这种组织方式。
三种问题类型，三种答案含义
Jev 提供三种基本问题类型：Choice、Score 和 Noul。选择哪一种，取决于程序究竟需要知道什么。
Choice 适用于从固定选项中选择一个答案，例如 technical、billing 或 other。返回结果包含选中的选项、概率分布和 confidence。类别说明应当能清楚地区分各个选项。
Score 适用于有顺序的等级。评估故障影响时，可以定义为“不影响工作”“影响工作，但有替代办法”“工作已无法继续”。结果可以落在两个等级之间：它是各等级序号按概率加权后的平均值。在 0–2 的等级上得到 1.4，并不表示有 70% 的用户受到影响。
Noul 用来评估一个答案为“是”或“否”的问题，例如“客户是否明确要求与工作人员沟通？”返回值在 0 到 1 之间，表示答案为“是”的概率。接近 0.5 表示不确定，并不代表“中等程度的请求”。Noul 没有单独的 confidence 字段。
检查问题表述时，可以问自己：不听作者口头补充，同事能否分清这些选项？如果不能，先把类别和等级写清楚。业务规则本身的歧义，不能指望模型替开发者消除。
“不会产生幻觉”究竟保证了什么
在发布公告中，TypeSafe 将“没有幻觉”与受限的答案空间联系起来：模型返回的是结构允许的值。这解决了一个具体问题——程序明明需要某种类型的结果，却收到任意生成的答案。
如果有三个部门可选，选中了一个真实存在的部门，并不能证明工单分配正确。格式保证不能推出模型正确理解了文本。同样，符合结构约束，也不能证明后续业务操作就是正确的。
只拿 Jev 与被提示“请返回 JSON”的聊天模型比较，也不够充分。TypeSafe 自己的适配器就支持 LLM 原生的结构化输出模式。在实际项目中，应比较完整的集成方案：决策质量、延迟、成本，以及故障处理方式。
程序能据此采取行动，概率才有用
假设两次 Choice 回答都选中了技术支持。第一组结果中，几乎所有概率都集中在技术支持上；第二组中，另外两个选项紧随其后。如果只看被选中的部门名称，就看不出这种差异。
对于 Choice 和 Score，confidence 根据概率分布的形状计算。不能直接把它理解为“这个答案正确的概率”。TypeSafe 建议用它决定后续处理方式，并根据具体任务设置阈值。
校准是另一个概念。如果一大批可比较的预测都把某事件发生的概率设为 0.8，那么在校准良好的模型中，该事件应该大约有 80% 的情况下实际发生。这是针对一组预测的性质，并不保证每一次回答都正确。按照 TypeSafe 的说明，RLCD，即 Reinforcement Learning for Calibrated Decisions，旨在训练这样的概率输出。
实际设计时，应预先为模糊工单安排处理路径。例如，部门选择足够明确时自动分配；概率较分散时，送入统一的复核队列。合适的阈值取决于分错队列的代价，以及在你自己的消息上测试得到的结果。
如何理解速度和成本数据
公开数据适合用来做初步评估，但各项数据的依据不同。文档中的价格是收费标准，响应时间是特定条件下的测量，而测试集上的优势则是相对于选定方案的比较结果。
| 指标 | 已公开的信息 | 应如何使用 |
|---|---|---|
| 响应时间 | 公告给出的范围是 70–500 毫秒；评估通常从美国西海岸发起，当时服务也部署在该地区 | 从应用实际所在地区测量延迟，并观察较慢的请求 |
| Jev 1.13 价格 | 每百万输入 token 为 0.042 美元，输出 token 免费 | 计算全部输入，包括上下文和问题 |
| 工作流质量 | 四个场景：安全事件、智能体可观测性、发票处理和客户服务 | 阅读评估方法，再测试自己的场景 |
来源：公告中的测量条件、模型和价格、Workflow evals。核查日期：2026 年 9 月 27 日。
Workflow evals 以 GPT-6 Astra 和 Claude Fable 5.1 在高推理设置下的平均回答作为参考，其他参评模型使用各自服务商的默认设置。因此，结果衡量的是在指定流程中，与所选模型参考答案的一致程度。这不等于在独立标注的真实结果上测得的准确率。
用一个假设计算来理解价格量级：一百万次调用，每次一千个输入 token，总计十亿个 token，按公开费率收费 42 美元。这一千个 token 必须同时包含上下文和问题。计算没有包含重试、其他模型、基础设施或人工复核费用。
选择方案时，每条正确处理工单的成本更有参考价值。如果大量结果需要人工修正，单次调用便宜的意义就很有限。
哪些工作适合 Jev，哪些需要其他工具
对文本进行重复判断，是适合尝试的方向：识别请求主题、判断是否符合某项描述，或选择类别。后续步骤则取决于系统需要如何使用结果。
对于导出故障，Jev 可以判断投诉内容。检查服务是否可用、计算 SLA 规定的截止时间，以及修改工单状态，仍然是普通程序的工作。给客户的邮件可以套用模板，也可以交给生成式模型撰写，但应向它提供已核实的事实和选定的操作。
这种分工也符合 TypeSafe 对 Jev 1.13 局限的说明。模型在精确计数和日期比较方面并不可靠；长上下文中的无关信息会降低回答质量。特意构造的文本也可能影响分类。开发方建议将计算留在代码中，删去无关上下文，并测试复杂情况。
如果产品面向中文用户，应准备专门的中文测试集。文档指出，英语是主要训练语言，也是当前准确率最好的语言，其他语言的表现可能不同。如果工单里有缩写、错别字和行业术语，这一点尤其需要纳入试验。
如何在自己的产品中开始试验
选择一个高频、且正确结果明确的决策，例如把工单分给相应部门。保留现有处理方式作为基线。为试验标注真实、匿名化的样本，也要包含模糊案例，并把调试用的数据与最终评估集分开。
把两个指标放在一起看：有多少工单能够自动处理，以及自动处理的这部分中有多少出错。如果某个阈值把几乎所有工单都交给人工，准确率可能很好看，但自动化程度很低。阈值放宽后，则要结合修正错误的成本来评估。
还应记录 p95 延迟，即 95% 的实测请求能够在多长时间内完成，以及模型费用和人工工作量。用相同样本比较 Jev、现有流程和合适的 LLM。TypeSafe 的适配器可以返回概率，也可以返回离散决策；比较条件应符合应用的实际需求。
将模型版本、问题和阈值与结果一并保存。jev-latest 这个别名可能转而指向新版本；文档建议，在针对某个版本调好行为后，固定使用该版本的具体标识符。
Jev 的工程思路很清楚：把语义判断变成程序中一个小而可观察的步骤。适合验证它的地方，是这类步骤出现频繁，而且团队能够明确界定什么算错误的业务。这样的试验，才能说明哪些决策适合自动化，以及还有多少不确定性需要在自动化之外处理。
本文依据截至 2026 年 9 月 27 日核查的公开一手资料编写。示例和图解仅用于说明，未实际调用 Jev API，也未开展独立性能测试。