Jev 使用指南：用结构化概率输出做判断层

Jev 是一个不生成自然语言的模型。给它一段非结构化的输入，它不会写出一段解释，而是对你事先定义好的若干选项逐一打分，返回一组带概率的判断结果。官方把这种形态概括为「非结构化状态输入，类型化概率决策输出」。它被设计成放在一个更大应用内部的「判断层」，用来做分类、路由，或者校验另一个大模型的输出，而不是取代通用大模型。如果你正在搭一套需要「让机器先判断、再由人决定要不要接手」的流程，Jev 这类输出形态值得了解；站内也有对应的工具条目可以参考：Jev。

需要先说明的是，本指南讲的是这种模型的接入方式与设计要点，不涉及任何实测体验。文中提到的价格、配额、可用性等信息都可能变化，请以官网当前信息为准。

准备工作

先想清楚你要它判断什么

Jev 与传统大模型最大的差别在于：它不会替你决定问题是什么。你必须先把判断问题写死成一组互斥的选项，模型才能工作。因此在写任何代码之前，先完成下面几件事。

确定判断的粒度。同一个业务问题，选项划分不同，模型实际在解的问题就完全不同。以工单分类为例，做成「销售 / 支持 / 其他」三选一，和做成「账单 / 技术问题 / 账号 / 功能请求 / 退订 / 其他」六选一，是两套系统，不是同一套系统的粗细版本。
检查选项是否覆盖真实情况。选项集合里如果缺少现实中高频的那一类，模型只能在剩下的选项里硬选，输出再漂亮也没有意义。判断选项是否完整，靠的是领域知识，不是模型能力。
想清楚每个选项对应什么动作。选项不只是标签，它背后是下游要执行的动作。如果两个选项对应的动作完全一样，它们大概率应该合并。

确认接入条件

Jev 由 TypeSafe AI 发布，属于其 System One 系列模型。接入前需要确认的事项包括：

可用的调用方式与鉴权方式（API 密钥的申请入口、密钥的存放方式）。
输入的长度上限。素材中提到输入按百万 token 计价、输出 token 不计费的说法，但具体计费口径与额度请以官网当前信息为准。
是否支持批量调用，以及单次请求能携带多少个待判断样本。
你所在地区是否在服务范围内。

这些都属于会变动的信息，不要在文档里抄一份数字就长期使用，接入前重新核对一次。

准备评估数据

因为 Jev 返回的是概率，你需要一批带真实标签的历史数据来验证这些概率是否可信。没有这批数据，你无法判断「模型说 0.9」到底意味着什么。建议在接入之前就把这批数据整理好，按下面的结构组织：

一条输入样本。
该样本在你这套选项体系下的正确选项。
该样本在业务上的处理成本（判断错了会怎样）。

第三项经常被忽略，但它直接决定后面阈值怎么定。

操作步骤

第一步：定义选项集合

把判断问题写成一份固定的选项清单。这份清单是接口契约的一部分，一旦上线就不要随意增删，因为增删选项会让历史概率失去可比性。

以「这条客户消息能否自动回复」为例，选项可以定义为：

auto_reply
review
reject

三个选项分别对应：可以直接自动回复、需要人工确认、不应自动处理。注意这里没有「其他」这种兜底选项——兜底选项会把本该暴露出来的分类缺陷掩盖掉。

第二步：构造请求

请求里需要包含两部分：待判断的输入，以及本次要评估的选项集合。概念上大致是这样：

{
  "input": "客户消息的原文或结构化后的状态描述",
  "options": ["auto_reply", "review", "reject"]
}

实际字段名、是否支持在请求里内联选项、是否支持一次提交多组选项，都要以官方接口文档为准。如果你的场景里选项集合是固定的，通常更适合把它固化在服务端配置里，而不是每次请求都传一遍。

第三步：读取返回结果

返回的不是一段文字，而是选项到概率的映射。概念上形如：

auto_reply  0.06
review      0.89
reject      0.05

这里的关键在于：概率之和为 1，且每个概率都对应一个你事先定义的选项。模型不会返回选项之外的东西，这是它相对生成式模型的一个结构性优势——它不会凭空造出一个你没定义过的类别。

但要注意，这个保证只覆盖「不越界」，不覆盖「选得对」。在选项集合内部选错，是完全正常会发生的事。

第四步：把概率映射成动作

拿到概率之后，真正的工程工作才开始。你需要为每个选项、每一档置信度定义下游动作。一个常见的分档方式是：

最高概率高于某个高阈值：直接执行该选项对应的动作，不经过人工。
最高概率落在中间区间：进入人工确认队列，把模型的判断和概率一并展示给处理人。
最高概率低于某个低阈值：不给出结论，转为补充信息或人工从头判断。

阈值不是拍脑袋定的，它由两类错误的相对代价决定。仍以「能否自动回复」为例：把本该人工处理的消息判成 auto_reply，代价是发错消息；把本可自动回复的消息判成 review，代价是多花人力。哪一类更贵，阈值就往哪边偏。

第五步：验证概率是否可信

概率数值本身没有意义，有意义的是「模型说 0.8 的那批样本，实际正确率是不是接近 0.8」。这一步必须用你自己的数据来做。

做法是把历史样本跑一遍，按预测概率分桶，然后统计每个桶里的实际正确率。如果 0.8 那一桶的实际正确率只有 0.5，说明概率偏高，你按 0.8 设的自动执行阈值会放进大量错误判断。

素材中提到，TypeSafe 采用了一种让概率向实际正确率靠拢的训练方法，并强调高置信度应当对应高正确率。但同时也指出，公开材料里没有给出校准误差这类量化指标，精度数字主要来自自建基准。这意味着校准这件事，最终要由使用方自己在自己的数据上验证。

第六步：持续监控

校准不是一次性验证。当输入数据的分布发生变化，或者你把它用到一个新的业务领域时，概率与实际正确率的对应关系会漂移。需要把第五步的验证做成周期性任务，而不是上线前跑一次就结束。

一个完整示例

下面用一个最小可跑通的流程，把上面的步骤串起来。场景是客服消息的自动回复分流。

场景与选项

输入是一条客户消息，输出是三个选项之一的概率分布：

auto_reply   可以直接自动回复
review       需要人工确认
reject       不应自动处理

请求

{
  "input": "客户询问上个月的账单为什么比平时多了三十元",
  "options": ["auto_reply", "review", "reject"]
}

auto_reply  0.06
review      0.89
reject      0.05

处理逻辑

假设当前设定的规则是：最高概率不低于 0.9 才自动执行，0.6 到 0.9 之间转人工，低于 0.6 则不给结论。这条样本的最高概率是 0.89，落在中间区间，因此进入人工确认队列，并把 review 这个判断和 0.89 这个数值一起展示给处理人。

如果同样的输入返回的是：

auto_reply  0.95
review      0.04
reject      0.01

那么按同一套规则，它会直接走自动回复流程。可以看到，两次返回的「最优选项」都是同一个方向，但一次需要人接手、一次不需要，差别完全来自概率数值。这正是把判断结构化的价值所在：人接手的边界可以被显式设计出来，而不是藏在模型的措辞里。

对照：为什么不用生成式模型

如果用通用大模型做同一件事，它可能返回「这条消息涉及账单疑问，建议人工确认，因为涉及金额……」这样一段话。这段话读起来合理，但它和模型内部的判断过程之间没有必然联系——同一段理由可以配在一个错误结论上。而且从这段话里，你读不出模型有多确定。是几乎确定要转人工，还是勉强倾向转人工？文本形态把这个信息抹掉了。

注意事项

概率高不等于判断可靠

看到 0.82 就认为这个判断可信，是常见误用。可信的前提是概率经过校准，即「说 0.8 的样本实际正确率接近 0.8」。没有在自己的数据上验证过这一点之前，任何阈值设定都是猜测。

「不越界」不等于「不出错」

Jev 保证的是不会输出定义之外的选项，而不是不会选错选项。在选项集合内部选错是正常现象。把「不会幻觉」理解成「不会出错」，会导致对结果的过度信任。

校准会漂移

输入数据分布变化、业务领域切换、选项集合调整，都会让原有的概率与实际正确率的对应关系失效。校准验证需要定期重跑。

选项设计是人的责任

模型无法告诉你选项划分是否合理，也无法告诉你是否漏掉了某个必要的类别。选项设计错了，再好的概率也没有意义。判断选项是否完整，依赖的是对业务和制度的理解。

举一个具体的例子：在判定某项资质是否满足条件时，直觉上会做成「满足 / 不满足」二选一。但熟悉实际操作的人会知道，现实中大量出现的是第三种情况——条件本身满足，只是材料不齐。这种情况和「不满足」的后续动作完全不同：前者是补材料，后者是放弃。所以选项需要三个，而第三个选项只有懂业务的人才想得出来。

阈值取决于错误代价

阈值高低不是技术参数，是业务决策。误判为通过可能带来合规风险，误判为不通过可能造成实际损失，两类代价孰轻孰重，决定了人工介入的线画在哪里。这个判断模型做不了。

问题设定本身就是系统设计

用这类模型时，把问题问清楚这件事的权重会明显上升。生成式模型对模糊的提问也能给出像样的回答，而结构化输出的模型要求你先把问题定义清楚。定义问题的过程，实际上就是系统设计的过程。

关于公开数据的局限

目前关于这类模型的公开材料，精度数据主要来自自建基准，独立验证仍在进行中。在把它用于关键流程之前，务必用自己的数据做一轮完整评估。价格、配额、可用地区等信息变动频繁，请以官网当前信息为准。