Jev 置信度阈值怎么设？用自己的数据验证错误率与覆盖率

设置 Jev 置信度阈值，要同时衡量放行决策中的错误率，以及全部流量中有多少能被放行。不要因为 0.8 或 0.9 看起来让人放心，就直接把它写进生产代码。只有固定问题、模型版本、输入样本群体和回退行为，阈值才有明确含义。

本文提供离线评估脚本、答案已知的合成数据，以及从现有 Jev 日志走到留出集验收的完整流程。适用对象是 Choice 分类问题，例如把工单分配到不同支持队列。本文不调用真实 API，不声称测出了 Jev 准确率，也不据此批准自动执行高影响决策。还没有收集响应时，先看 Jev API 入门与使用指南。

先确认你要比较的是哪个数值

官方 API 把答案概率与 confidence 分开。对于包含 n 个选项的 Choice，文档给出的置信度公式是 (n × p_max − 1) / (n − 1)。若有三个选项，最大概率为 0.8，置信度就是 0.7。因此，对两个字段都设 0.8，并不是同一条放行规则。参见 TypeSafe 置信度文档。

2026 年 10 月 2 日采集的官方英文文档原始截图。截图展示字段定义，不能证明某个阈值适用于你的数据。

Score 使用另一套计算方式，会考虑有序等级之间的距离。Noul 返回 yes 概率，没有单独的置信度字段。不要把三类数值统统放进名为“确定性”的列，再套用一个阈值。本文的 CSV 只接收同一个固定问题返回的 Choice confidence。

还要区分两种评估。校准考察预测概率是否与分组后的实际结果相符；选择性评估考察按某个阈值放行后，放行结果里有多少错误。即使概率校准不好，只放行极少数流量，也可能得到看似漂亮的错误率。两者不能互相替代。

看结果之前，先写好验收条件

假设应用把工单分到 billing、technical 或 other。分类正确，是指预测与独立标注一致。遇到材料不全、内容互相矛盾或超出分类范围的工单，标注规则应先定义如何处理；否则你可能把审稿者也无法确认的猜测奖励为正确答案。

先确定可接受的错误率上限、最低放行流量、延迟预算，以及必须单独复核的错误类型。这些由业务场景决定，不是 Jev 给出的通用参数。可撤销的队列分配和不可逆的操作，即使都返回标签，也不应沿用同一验收标准。

准备带例子的标注指南，先解决人工标注分歧，再评估模型。条件允许时，不要让标注者提前看到模型预测。否则所谓“标准答案”可能逐渐变成对模型的认同，失去独立性。

把开发、验证和最终测试分开

用开发样本完善问题和分类定义，用验证集比较候选阈值。在最终留出集上运行之前，锁定问题与阈值。看过最终测试结果之后反复调整阈值，就等于把测试集又用成了验证集。

同一段对话、同一客户文档或同一模板家族可能产生高度相似的记录，应按这些单位划分数据，避免泄漏。纳入日常流量和重要边界案例；若特意提高了边界案例占比，就把它们单独报告。记录语言和输入长度分组，防止漂亮的平均值掩盖某个分组不可用。

不存在能普遍保证安全上线的样本数。尤其是少量放行样本中零错误，说明不了可靠性。作为粗略统计示例，在独立试验、零观测错误的前提下，“三法则”给出的约 95% 错误率上界是 3 / 放行样本数。它只适合初步规划，不能当认证：样本相关、选择偏差或分布变化都可能破坏解释。需要正式推断时，应由评估负责人选择合适的区间与抽样设计。

从固定问题的响应整理 CSV

下载并解压 Jev 离线决策工具包。需要 Python 3，脚本只使用标准库，不需要 Key，也不访问网络。

输入文件有五列：

实际响应模型、请求 ID、完整概率分布、问题版本和数据集划分，应保存在另一份通过 id 关联的追踪清单中。这个小工具不负责强制校验这些元数据。不要把多个模型版本或多个问题合到一个 CSV，然后声称验证了同一套策略。

下面是附件中人工编写的合成测试数据的一部分，不是 Jev 的真实响应：

id,gold,predicted,confidence,status
case-1,billing,billing,0.98,ok
case-2,technical,technical,0.94,ok
case-3,billing,technical,0.91,ok

整理自己的数据时，直接复制已保存响应的字段，比较阈值前不要四舍五入。请求失败也保留为 error 行，预测和置信度留空。删除超时请求，会人为抬高覆盖率。

运行评估脚本，先核对计算逻辑

在解压目录执行：

python3 evaluate.py synthetic.csv
python3 evaluate.py synthetic.csv --thresholds 0.8 0.9

我们用附件的八条合成样例在本地运行了第一条命令。以下结果验证的是计算器逻辑，不是 Jev 实测表现：

覆盖率等于 放行数 / 全部符合纳入条件的样本数；放行错误率等于 错误放行数 / 放行数。没有任何样本被放行时，脚本把错误率返回为 null，不会假装策略已经实现完美准确率。

注意，从 0.80 提高到 0.90 后，这组数据的观测错误率反而上升。有限样本中，更高的阈值不保证错误率单调下降。0.95 这一行虽然零错误，却只放行了一个案例，不足以证明可靠性。合成数据特意保留这两种现象，帮助你在使用真实数据前发现常见误读。

选定策略，再验收整条流程

在验证集上同时检查汇总结果和每条放行错误。先排除违反错误约束的策略，再在剩余策略中比较覆盖率、回退容量、成本与延迟。如果没有策略满足条件，结论应该是“这个问题暂不自动化”，而不是挑一个最不差的数字上线。

随后冻结阈值，在留出集上做一次最终评估。回退路径也需要验收：低置信度结果交给另一个模型或人工，并不自动等于任务成功。完整流程评分要包含处理器不可用，以及始终没有完成的案例。

可以采用下面的保守策略骨架：

if response_error or label_not_allowed or confidence_invalid:
    fallback()
elif confidence < validated_threshold:
    fallback()
else:
    enforce_permissions_and_business_rules()
    route_to_handler()

这是应用伪代码，不是可直接运行的 Jev SDK 示例。数值比较前，应拒绝缺失、非有限或越界的置信度；不能让 NaN 绕过阈值判断。权限检查、输入校验和业务规则仍由应用代码执行，高置信度不应绕过这些控制。路由操作涉及副作用时，沿用正常业务流程要求的幂等与确认机制。

对错误定位，不要把它从报告中删掉

有关论文结果的解释，参见 Jev 评测究竟能证明什么。公开基准中的校准结果，不能直接批准你自己的生产阈值。

阈值必须与版本绑定

需要可复现时，固定被评估的模型版本，同时记录响应实际报告的版本。修改问题、增加选项、翻译状态、调整预处理或更换模型之后，都要重新评估。即使阈值没变，输入变了，也可能已经是另一套策略。

先做影子决策，再进行范围有限、可以撤销的放量，并明确回滚负责人。用新标注样本持续观察放行错误、总覆盖率、回退负载和最终任务结果。保存旧策略，确保需要恢复时不用重新拼装实验。

最后，把实际测得的覆盖率代入 Jev 路由成本计算器。一个阈值有价值，是因为它满足质量要求且让应用可以正常运转，而不是因为小数点后的数字看起来漂亮。