13 次报警全对，却漏掉 61 条已知故障里的 48 条
Cloudflare Clef Flash 在默认 0.50 阈值下只报警 13 次，13 次都对应已知故障，精确率 100%。同一批记录里还有 48 条已知故障没有被报出，召回率只有 21.3%。报警准不准和故障抓得全不全，在这里是两个数字。
Hamel Husain 与 Antaripa Saha 拿公寓租赁 AI 客服的生产轨迹做这次评测。助手通过电话和即时通讯处理预约看房、确认取消、转接人工。判定任务只有一条：这段对话里，助手的行为或工具调用有没有出现实质性故障。原始数据 100 条，去掉 2 条内部 QA（质量检查）记录后，性能分析用 98 条，其中 61 条标为已知故障，37 条在本次基准里没有标记故障。未标记不等于已经证明毫无问题。
参测六款方案是 Jev 1.13、Perplexity Decider 1.1 27B、Liquid d1、Liquid d1-ultra、Cloudflare Clef Flash，以及使用 GPT-6 Luna 的 OpenAI Decisions。Perplexity、Liquid、Clef 与 OpenAI 拿到的文字提示词和序列化输入完全一样；Jev 通过自己的结构化 API 接收等价准则。每条轨迹输出一个 0 到 1 的故障倾向分，原始对话属于私有数据，没有公开。
决策模型可以理解成嵌在代码里的判断组件：它不写长文，只回答预先问好的那一句，比如「助手有没有谎称预约成功」，然后返回分数。后面的动作由程序接手，分数过线就送人工复核，不过线就放行。
把报警线从 0.50 挪到别处，为什么就能改变漏报与误报？
默认 0.50 切在谁的刻度上，是第一个要查的事
阈值把连续的分数切成「报警」和「不报警」。假设某个模型给所有故障打 0.40、给所有正常记录打 0.10，线切在 0.30 就能把两类完全分开；照用 0.50，一条故障也报不出来。真实分布会重叠，所以移动这条线会同时改变误报和漏报。
默认 0.50 下的六款结果差别很大。Clef Flash 报警 13 次全对、漏 48 条，F1 0.35。Liquid d1 抓出 28 条、漏 33 条，召回率 45.9%。Perplexity Decider 抓出 39 条、漏 22 条，召回率 63.9%。Liquid d1-ultra 抓出 49 条、误报 12 次，精确率与召回率都是 80.3%。OpenAI Decisions 把两类分数拉得最开：抓出 55 条已知故障，召回率 90.2%，同时对 15 条未标记故障的轨迹报警，精确率 78.6%。这 15 次是相对于本次标签的误报，未标记轨迹里可能还有没被发现的问题。
评测者给这次选型设了一道示例门槛：精确率和召回率都不低于 80%。在 98 条全样本上扫遍所有阈值，只有 OpenAI Decisions、Liquid d1-ultra 和 Perplexity Decider 摸到过这条线：OpenAI 有较大一段阈值区间落在双 80% 里，Liquid d1-ultra 在 0.525 附近触到，Perplexity 要把阈值压到约 0.127 才行。Jev、Liquid d1 和 Clef Flash 怎么调都进不去。
80% 是这次业务约束的示例，不是行业统一红线。真到落地时，漏掉一条投诉和误报一条正常对话的代价并不对等，权重得自己定。业务不对称时，还可以用 F-beta 分数给精确率或召回率加权，而不是无脑最大化 F1。
这三款在全样本上摸到过线，换一批没参与挑线的记录还站得住吗？
100 个训练切分里，只有一款每次都找得到合格阈值
入选候选之后，评测者对 98 条记录做分层五折交叉验证：按故障与未标记故障的比例分成 5 份，每轮拿 4 份（约 78 条）选阈值，剩下 1 份（约 20 条）只用来测。这个过程重复 20 轮，共 100 个训练切分。选阈值只用已保存的模型分数，不需要重新调用模型。
三款候选的差别在这一步显出来。OpenAI Decisions 在全部 100 个切分里都找到了满足双 80% 的阈值，留出集平均精确率 86.9%、召回率 86.2%、F1 0.865。Liquid d1-ultra 有 29 个切分找不到合格阈值，按实验规则退到无约束的 F1 最优，留出均值掉到精确率 75.9%、召回率 81.7%、F1 0.787。Perplexity Decider 有 36 个切分触发同样回退，留出均值 75.4%、82.5%、F1 0.787。
也就是说，两款的留出平均精确率都跌到了 80% 以下，尽管它们在全样本扫描里都曾摸到过双 80%。训练折上选出的线，换一批记录就不一定守得住，这不是模型坏了，是样本扰动本身就在改写边界。
还有一层容易被忽略：重复 20 轮用的始终是同一批 98 条轨迹，切分再多次也没有增加一条新的生产数据。平均值不保证某一折达标，更不保证上线后达标。随文给出的示例提示词在这里和实际实验有一处不同：提示词要求找不到合格阈值就直接报告，而实验里用了回退，并把回退折一起算进了平均。
留出值为重复 20 轮五折的均值；费用按 100 次 API 评测与实验费率计算。 同一任务 98 条轨迹的均值，不保证每折或上线后达标；费用非统一现时报价。
既然分数排序能用，那个 0.80 能不能直接读成八成故障概率？
分数能排序，不等于它能当概率读
如果要把 0.80 读成「约八成风险」，需要满足一个条件：大量分数都在 0.80 附近的记录里，大约八成真的出了故障。校准图就是把这件事画出来——样本按预测概率从低到高分 5 组，每组 19 或 20 条，看每组的平均预测和实际故障比例是否贴着对角线。
Clef Flash 有一组的表现最刺眼：模型给这组的平均预测故障概率约 8%，组里实际有 60% 的轨迹包含故障。点是往对角线上方飘的，表示它在这段分数上低估了风险。Perplexity 和 Liquid d1 也有多个区间存在低估。Jev 与 Liquid d1-ultra 在这批数据上本来就比较贴线，缩放带来的调整很小。
常用来纠偏的办法是 Platt scaling（普拉特缩放）：用训练折的原始分数和 0/1 标签拟合一条把分数映射成概率的曲线（基于对数几率的逻辑回归），再把这条曲线套到没参与拟合的留出折上。逐折循环、汇总留出结果，避免同一批数据自己拟合自己评。图上 Perplexity、Liquid d1 和 Clef Flash 缩放后明显靠近对角线。
缩放不是万灵药。检验校准用 Brier 分数，即预测概率与真实标签之差的平方取平均，数值越低越好；它同时受区分能力和概率误差影响。在这次展示的对数几率拟合下，OpenAI Decisions 的 Brier 分数从 0.159 微升到 0.164。同一批数据还有一个对照：如果直接在概率尺度上做探索性重拟合，OpenAI 的 Brier 分数可以降到 0.154。同一批数据，换个拟合形式结论就反过来，所以校准效果本身也要在留出数据上测，不能假定它一定改善。
这些差异够不够决定别家客服系统也该选同一款？
四倍价格换来更高 F1，但这张表只对这批记录有效
调完阈值再把表现和费用放一起，三款候选的取舍很清楚。按每 100 次评测的 API Token（词元）用量和实验记录费率算，Perplexity Decider 花 0.82 美分，留出 F1 0.787；Liquid d1-ultra 花 1.52 美分，F1 0.787；OpenAI Decisions 花 3.72 美分，F1 0.865，约是 Perplexity 的 4.5 倍。费用覆盖含内部 QA 记录的 100 次调用，性能只算 98 条生产轨迹；Liquid 的费率经过重新核定（d1 从每百万输入 token 0.04 美元改为 0.02，d1-ultra 为 0.042），其余沿用实验时的记录，不是一份统一的现时报价。
速度这项没有可用排名。平均响应时间分别是 Jev 4.33 秒、Perplexity 7.85 秒、Liquid d1 7.38 秒、Liquid d1-ultra 1.56 秒、Clef Flash 2.09 秒、OpenAI 2.77 秒，但它们来自不同的独立运行，批处理、并发、机房距离和尾延迟都会改写结果，不能据此说谁更快。
标签也有来源限制。61 条已知故障由两部分构成：39 条来自原有人工审阅，22 条由 Braintrust 和 Arize 工具筛查后再人工核验。原始对话和逐条审阅依据都没有公开，37 条未标记故障的轨迹也不等于确认干净。所有结论都长在这一批 98 条租赁客服记录上，换业务、换故障类型、换时间都得重测。
想在自己数据上走一遍，顺序是三步：先用本任务的人工标签确认模型能不能把故障和正常记录分开；再在训练折选阈值、在留出折看误报与漏报是否守得住；最后只有在需要把分数当风险概率读时，才单独拟合校准并检验 Brier 分数。作者给了两段可直接交给编程 Agent（智能体）的提示词，一段做阈值调优、一段做校准，都强调复用已保存的分数，不发新的模型调用。作者还建议把宽泛的总判断拆成一种故障一个裁判，任务越窄，大小模型之间的差距越可能缩小。
