Jev 布尔判断实战：用概率化 Yes/No 构建自动分流

Jev 是一类面向软件系统的判断模型：它不负责写文章，而是接收一段 state（判断材料）和一个带类型的问题，返回可以直接被代码消费的判断结果。它提供三种提问方式，其中 Choice 用于在候选集合中选一个，Score 用于评估处在哪个有序等级，而 Boolean 用于回答 Yes/No 问题。Boolean 在官方 API 中被称为 Noul，两者指的是同一件事，只是不同界面的叫法不同。本教程聚焦 Boolean 这一类判断，讲清它返回的数值到底代表什么、如何据此写出自动处理与人工复核的分支，以及阈值应该怎么定。适合需要在业务流程里嵌入语义判断、又不想引入自由文本生成的后端与算法工程师阅读。

准备工作

开始之前需要明确几件事，它们决定了后续所有判断结果该怎么解读。

访问方式

Jev 可以通过第三方搭建的 Jev Playground 直接试用。按照素材记录的情况，该 Playground 无需信用卡、无需注册账号、也无需 API 密钥即可使用，页面上会提示免费试用、无需注册、但存在用量限制。也就是说，本教程中的全部操作都可以在不付费、不登录的前提下完成。由于这类免费额度和可用性随时可能调整，实际以官网当前信息为准。

如果要在生产系统中调用，则需要走正式的 API 接入方式，涉及密钥申请与配额，这部分同样以官网当前信息为准，本教程不涉及。

需要先建立的三个概念

在动手之前，先把下面三组概念分清楚，否则很容易把返回值读错。

• probability（概率）：模型给每个候选答案分配的支持程度。在 Choice 中表现为每个选项各有一个概率值，概率最大的那个成为 choice。
• confidence（置信度）：只在 Choice 和 Score 中出现，表示概率分布有多集中。集中在一个答案上则 confidence 高，分散在多个答案上则 confidence 低。
• correctness（正确性）：现实中这个判断是否真的对。它与前两者完全无关，模型无法给出这个值。

Boolean 这一类判断比较特殊：它没有单独的 confidence 字段，返回的那个 0 到 1 之间的数值本身就是 P(true)，也就是答案为 Yes 的概率。

Boolean 的数值怎么读

这是最容易出错的地方。Boolean 返回的数值不是「模型有多自信」，而是「Yes 的概率有多大」。

• 0.99 表示非常接近 True
• 0.80 表示偏向 True
• 0.52 表示几乎五五开
• 0.48 表示几乎五五开
• 0.20 表示偏向 False
• 0.01 表示非常接近 False

关键点在于：0.05 不是「只有 5% 的自信」，而是「False 相当有力」。因为 P(true) = 0.05，意味着 P(false) 约为 0.95。真正模糊的区间在 0.5 附近，而不是在接近 0 或接近 1 的两端。把 0.05 误读成「模型不确定」，是使用 Boolean 时最常见的错误。

操作步骤

第一步：跑通一个明确的 Boolean 判断

先从一个意图清晰的例子开始，确认输入输出的形态。

在 Playground 中把 Decision type 选为 Boolean，然后填入以下内容。

State:
The customer says: "I was charged twice. Please refund the duplicate charge."

Question:
Does the customer request a refund?

执行后返回的是 P(true)。如果结果是 0.99，含义是 true 占 99%、false 占 1%，也就是这位客户明确提出了退款请求。

这个例子里 State 中出现了 refund 这样的明确措辞，所以判断结果会非常偏向 True。

第二步：把输入改得模糊一些

接下来把 State 换成一段没有明确诉求的描述，观察数值如何变化。

State:
I was charged twice. Can you check what happened?

Question:
Does the customer request a refund?

这段话提到了重复扣款，但并没有说「请退款」。与上一步相比，P(true) 应该会下降，落在中间地带。这个对比正是 Boolean 的价值所在：它把「有没有提出退款请求」这种需要读语义才能回答的问题，变成了一个可以比较大小的数值。

注意这里不要期待一个固定的数字，模型对不同措辞的敏感程度需要用自己的数据去观察。

第三步：把 Boolean 当作 if 条件使用

Boolean 之所以在工程上好用，是因为它天然对应一个二分支结构。可以直接把返回值接到条件判断上。

if (p >= 0.85) {
  console.log('按有退款请求处理');
} else if (p <= 0.15) {
  console.log('按无退款请求处理');
} else {
  console.log('情况模糊，转人工确认');
}

这段伪代码体现的是三段式结构：高概率区间自动判为 Yes，低概率区间自动判为 No，中间区间交给人工。0.85 和 0.15 只是示例值，生产环境中的阈值必须根据自己的标注数据来确定，不能照搬。

再次强调：p <= 0.15 这一支的含义是「False 相当有力」，而不是「模型没把握」。

第四步：从同一个 state 派生多个判断

Jev 的一个实用特性是，同一个 state 可以同时支撑多个互相独立的提问。例如一条客户来信，可以同时问三件事。

• Choice：应该由哪个团队处理？
• Boolean：客户是否提出了退款请求？
• Score：这件事有多紧急？

结构上可以理解为：

一个 state
 ├─ route            → Choice
 ├─ refundRequested  → Boolean
 └─ urgency          → Score

这样做的好处是每个判断都足够小、足够聚焦，比把所有诉求塞进一个问题里要可靠得多。

第五步：把多个判断组合成业务分支

把上一步的三个判断结果合起来，就能写出比较完整的处理逻辑。

• 如果负责团队的 probability 高，且 confidence 也足够高，则自动分派。
• 如果第一名和第二名概率接近，或者 confidence 偏低，则转人工复核。
• 如果退款请求的 P(true) 大于等于 0.9，则按有退款请求处理。
• 如果 P(true) 落在 0.4 到 0.6 之间，则说明表述不够明确，需要人工确认。
• 如果紧急度 score 大于等于 2.5 且 confidence 足够高，则标记为高优先级。

需要划清界限的是：Jev 只负责语义判断。真正执行退款、删除数据、发送邮件、转移工单这些有副作用的动作，应该由应用代码来完成。

一个完整示例

下面把前面的步骤串成一个可以照着搭的最小流程，场景是客服来信的自动分流。

输入

State:
The customer says: "I was charged twice for my monthly subscription
and I need one of the duplicate charges refunded."

Question 1 (Boolean):
Does the customer request a refund?

Question 2 (Choice):
Which team should handle this?
Choices: Billing, Technical, Sales, Other

预期返回

Boolean 返回一个 0 到 1 之间的数值，例如 0.97，表示客户提出退款请求的概率很高。

Choice 返回选中项与各候选的概率分布，形态大致如下。

{
  "choice": "Billing",
  "probabilities": {
    "Billing": 0.96,
    "Technical": 0.02,
    "Sales": 0.01,
    "Other": 0.01
  }
}

注意这里真正有信息量的不只是 choice 等于 Billing，还有整个分布：Billing 0.96、Technical 0.02、Sales 0.01、Other 0.01。分布高度集中，说明判断比较明确。

处理逻辑

const refundP = booleanResult;          // 例如 0.97
const route = choiceResult.choice;      // "Billing"
const top = choiceResult.probabilities[route];

if (refundP >= 0.9 && top >= 0.85) {
  // 自动分派到 Billing，并标记为退款请求
  assignTo(route, { refundRequested: true });
} else {
  // 任一条件不满足，转人工
  queueForHumanReview();
}

换成模糊输入会怎样

把 State 换成下面这段，两个判断的结果都会发生变化。

The payment page stops responding after I enter my card.
I'm not sure whether I was charged.

这段话同时包含 Billing 和 Technical 的要素。Choice 的分布可能变得分散，例如 Technical 0.55、Billing 0.42、Other 0.03。此时更合理的读法不是「既然 Technical 排第一那就一定是 Technical」，而是「Technical 略占优势，但 Billing 也相当有可能」。这正是把第一名与第二名之间的差距、以及 confidence 纳入分支条件的意义。

注意事项

score 不等于 probability

Score 返回的数值是各等级编号按概率加权后的位置，因此出现小数是正常的。例如等级 0 到 3，概率分别为 0.00、0.00、0.70、0.30，则 score 为 0×0.00 + 1×0.00 + 2×0.70 + 3×0.30 = 2.30。

把 2.4 除以最大值 3 得到 0.8，并解读为「80% 的概率是危险」，是错误的。score 只表示在定义好的等级序列中处于什么位置，与概率不是一回事。

Score 要连 confidence 一起看

score 相同、confidence 不同的两个结果含义并不一样。score 2.0 配 confidence 1.0，说明概率强烈集中在某个等级；score 2.0 配 confidence 0.3，说明概率分散在多个等级上。只看 score 会丢掉这部分信息，因此建议 score、probabilities、confidence 三者一起读。

confidence 不是正确率

confidence 为 1.0 只表示概率分布集中在一个答案上，并不表示这个答案在现实中一定正确。confidence 描述的是分布是否清晰，correctness 描述的是事实是否成立，两者必须分开。

多个提问之间不会互相通信

同一个 state 上的多个提问是各自独立判断的，不存在「第二个问题读取第一个问题答案」的机制。如果确实需要根据前一个判断的结果来决定后一个问题的候选集合，就必须拆成两段：先让 Jev 判断，再由代码决定下一轮的候选，然后发起第二次判断。

阈值不能凭感觉定

直接写 probability 大于等于 0.9 就自动处理很容易，难的是说清为什么是 0.9。合理做法是准备带标注的数据，分别测试不同阈值下的表现：阈值 0.70 时自动处理的比例高但误处理也多；0.85 时在自动化率和准确率之间取得平衡；0.95 时误处理减少但转人工的量上升。最终要权衡的是误处理的代价与人工复核的成本。

按操作的危险程度调整阈值

不同动作的容错空间差别很大。调整工单归属这类操作即使判断错了也比较容易回退，可以采用相对宽松的阈值。而执行退款、删除数据、向外部发送信息、停用账号这类操作影响较大，应当采用更高的阈值并附加额外确认。

该用代码算的不要交给模型

金额合计、日期计算、字符数统计、ID 比对、权限校验、数据库约束、上限值检查，这些都应该由普通代码完成。例如判断「合计金额是否超过十万」，直接写 total > 100000 即可，不需要交给模型。适合交给 Jev 的是「这笔支出与常规购买模式相比是否异常」这类必须读语义才能回答的问题。

不要把大问题塞进一个提问

与其问「请分析这条来信并决定所有应对方式」，不如拆成若干小判断：负责团队是什么、是否提出退款、紧急程度如何、是否需要人工介入。最后再用代码把这些结果组合起来。

「不会产生幻觉」要正确理解

关于 Jev 有一句流传较广的说法是它不会产生幻觉。这句话的含义是：如果 Choice 的候选是 billing、technical、other，模型不会突然返回一个 free_refund_everyone 这样的未定义值。也就是说，它能避免跳出类型范围的失败，这一点确实很有价值。但它并不保证语义判断一定正确——把本该是 technical 的判成 billing 是完全可能发生的。形式上的正确与语义上的正确需要分开评估。

Jev 不是文本生成模型

让 Jev 去写一封回复邮件属于用错了工具。合理的分工是：Jev 负责判断来信类型、紧急程度、是否涉及退款；生成式模型负责撰写回复文本；代码负责规则、计算、权限和副作用。

内部实现不宜臆测

公开信息中能确认的是，Jev 采用了新的模型架构、并行采样器，以及用于校准决策的强化学习方法。至于它是否基于某种特定的编码器结构、参数量多少、网络如何搭建，公开材料中并没有给出，因此不应断言它属于某一类模型。从外部能够确认并且真正影响使用的，是「state 加带类型的问题，返回带类型的概率化判断」这一接口形态及其行为表现。

免费额度与可用性会变化

Playground 的免费试用、免注册、免密钥等条件，以及用量限制的具体数值，都可能随时间调整。正式接入的价格、配额、地区可用性同样如此，使用前请以官网当前信息为准。