Jev 到底在判断什么

“一次模型判断，至少要分成文字状态、完成证据和程序动作来看。”

我开始关注 Jev，是因为一个很小的疑问。程序看到“晚饭送到了”，能不能就把任务标成完成？如果这句话出现在“要是我说‘晚饭送到了’，你是不是就不催了？”里面，答案显然不同。关键词规则很容易把两句话混在一起。

我想弄清四件事。Jev 到底怎样读这类话，它实际有没有帮助，它和已有的概率校准及人工接管研究有什么联系，最后又能放进哪些任务。下面的测试围绕这四个问题展开。

核心观点 / 起源

一句话里的五个状态

测试任务是“今天把晚饭送到爷爷家”。脚本一共准备了五个状态，下面先列出文章中最常见的三个。

这些词是我在测试脚本里预先规定的选项。Jev 从这五个选项里选择一个，unknown 和 cancelled 也会进入实际测试。

第一批离线测试只有关键词规则，没有调用 Jev。24 条作者编写的案例中，规则答对 14 条，准确率 58.33%。C13 把引号里的“晚饭送到了”当成完成，C18 把“送到了再告诉你”里的未来条件当成完成。两条消息都包含完成词，真正表达的状态却不同。

过程 / 推演

测试怎样运行

这次有三组结果。第一组是 24 条离线规则基线，完全没有调用 Jev。第二组是首轮线上试跑的 3 条，目的是看请求、返回和路由能否跑通。第三组是第二轮线上测试的 14 条，专门挑选规则容易出错的语境。

每条案例包含一个任务和按时间排列的一段或多段消息。24 条和 14 条都由我编写，预设标签也由我给出。脚本先用规则判断，再把同一份文字交给 Jev。Jev 收到任务、消息和三道小问题。第一道问题要求从五个状态中选一个。第二道问题只问消息有没有明确报告目标任务已完成。第三道问题用 0 到 2 的刻度表示证据有多直接。

第二道问题返回的 0 到 1 数字就是完成表达分数。它来自模型对“这段文字是否明确报告完成”的回答。0 接近没有完成报告，1 接近明确报告完成。0.86 代表文字证据偏向完成，不能把它理解成现实任务完成了 86%。

脚本把所选状态概率低于 0.85 的结果送人工复核。选中 done 时，完成表达低于 0.90 也会进入人工复核。blocked 会建议任务交接，committed 会保持任务打开，cancelled 会请求人工确认。第三道 0 到 2 的证据刻度只用于观察，本轮路由没有使用它。程序最后只提出动作建议，executed 一直是 false，所以测试没有替任何人发消息或关闭任务。

Jev 的官方文档把这种接口称为结构化判断。Choice 返回一个选项、每个选项的概率和置信度，Noul 返回一个 0 到 1 的是非概率，Score 返回刻度位置和各等级概率。System One 文档 和 问题类型文档 都强调，应用程序应当把这些结果接回自己的流程。

首轮三条真实调用

首轮调用使用模型 jev-1.13.0，三条请求都成功。结果如下。

C01 很能说明问题。Jev 选择了 done，所选状态概率是 0.99，完成表达分数是 0.86。程序仍然没有自动确认，因为完成表达没有达到 0.90。0.86 只描述文字证据，现实世界的完成比例仍然未知。

第二轮更难的案例

为了测试语境，我又准备了 14 条案例，覆盖引号、条件、多人接力、部分完成、撤回和对象变化。14 次调用全部成功，规则答对 10 条，Jev 与作者预设标签一致 14 条。规则有 2 次误报完成，Jev 没有出现这类误报。Jev 的中位耗时约 1727 毫秒，API 失败 0 次，所有动作都没有执行。下面只列出 14 条中的 5 条代表性样例。

R01 和 R02 说明 Jev 读到了句子的语气和时间关系。R04 说明它能追踪前后两条消息，但它自己也给出了不够高的概率，所以进入人工复核。R13 的后一段话改变了前一段的意义，Jev 把当前状态留在遇阻，并按规则建议任务交接。R14 的类别和预设标签一致，概率却只有 0.61，所以程序转人工复核。

这组结果的边界要紧跟着数据一起看。案例由我编写，标签也由我给出，第二轮沿用了第一批的部分表达，没有独立留出集，也没有外部送达证据。14/14 表示这批针对性样例与作者标签一致，不能估计随机消息或真实业务的正确率。它也没有测出概率校准，0.85 和 0.90 只是脚本的演示门槛。完整的原始概率、模型版本、耗时和失败字段保存在 第二轮测试记录 中。

Jev 和普通程序的分工

普通程序擅长做确定的事情。它可以比较日期、检查权限、计算金额，也可以在概率低于阈值时转人工。它不擅长从“要是我说”“送到了再告诉你”这种句子里判断时间和语气，除非开发者不断增加规则。

Jev 处理的是这一小段含义。程序把任务和消息装进一个状态，再提出几道范围明确的问题。Jev 返回有限选项、概率和评分，程序把结果接到自己的分支里。官方介绍把这种方式概括为从非结构化状态得到带类型的概率判断，并把它放进软件流程。TypeSafe 的介绍

这也解释了 Jev 的边界。它读到“晚饭已送到”，只能判断文字是否这样报告，无法看见爷爷家门口，也无法验证说话人是否诚实。现实证据、权限和最终动作仍由其他系统或人工负责。Jev 官方的模型边界文档也提醒开发者测试字面表达、间接说法、矛盾标准和对抗性内容。Jev 1.13 边界说明

和已有研究的联系

Jev 返回概率，首先会遇到概率是否可信的问题。Guo 等人的研究把校准解释成概率能否代表长期的正确率，并发现很多神经网络的置信度并不可靠。On Calibration of Modern Neural Networks 给出了温度缩放等校准方法。我的 14 条案例没有测校准，因为没有足够多的独立样本，也没有把概率分桶后和真实正确率比较。

Jev 的人工复核路由也和选择性预测相连。SelectiveNet 研究了模型在不确定时拒答，并同时考虑覆盖多少样本和留下多少风险。SelectiveNet 说明了“自动处理多少”和“错误风险多大”要一起看。我们的脚本用 0.85 和 0.90 做演示门槛，这两个数字还没有经过业务数据校准。

最后，转人工的方式会影响结果。AAAI 的一项研究发现，人和模型组成团队时，系统怎样告诉人“这次需要你接手”，会影响人的判断。Role of Human-AI Interaction in Selective Prediction 人工复核环节同样需要设计和评估。

Jev 可以放在哪里

家庭照护是一个直观方向。家人发来的消息常常只有“我来”“在路上”“今天不行”，系统可以先判断是否有人接手、是否遇到困难，再把真正需要接力的任务交给人。是否真的送达，仍应由确认消息或其他证据完成。

行政材料也有类似问题。申请人说“材料准备好了”，系统可以进一步判断这句话是否提到目标表格、日期和附件。它能提示缺少哪类文字证据，不能替机构决定资格。

客服和团队任务可以用它做初步分拣。消息可能同时包含承诺、抱怨和问题，结构化判断可以把状态交给程序，低概率结果直接进入人工队列。日期、金额和权限仍交给确定规则处理。

结语 / 反思

这次测试让我把问题拆成三件事。文字表达了什么，文字对完成的支持有多强，程序是否允许下一步动作。规则在第一件事上遇到语境就容易失手，Jev 在第二件事上提供了概率，程序在第三件事上保留了门槛和人工复核。

Jev 值得尝试的地方，是把一小段难写成规则的语义判断接进代码。它给出的概率可以帮助程序决定何时停下来请人看。它没有替现实世界提供证据，也没有替业务承担责任。

如果要继续验证，下一步应收集独立标注的脱敏消息，单独统计误报完成、漏报、人工处理量、延迟和 API 失败。到那时，文章里的 14/14 才能和更可靠的基准比较。现在这组测试适合帮助读者看懂 Jev 怎样工作，也适合暴露规则为何会把承诺当成完成。