Jev：面向快速决策的 AI 如何工作
Neaptide · 2026年9月27日 · 12 分钟阅读 · 更新于: 2026年10月3日
了解 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 年 10 月 3 日。
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 年 10 月 3 日核查的公开一手资料编写。示例和图解仅用于说明。我们没有实际调用 Jev API，也没有做独立性能测试。