4 篇博文 含有标签「hitl」

第一次事故很少表现为系统宕机。它通常是来自客户成功团队的一条 Slack 消息：“嘿，我们还好吗？在过去的一小时里，有五个客户升级了工单，这些工单在‘待审核’状态下已经躺了超过一天了。”你检查了模型延迟仪表盘。绿色。你检查了智能体（Agent）的成功率。绿色。你检查了单次调用成本图表。健康。你监测到的一切指标都正常。出故障的是一个你的监控栈根本不知道其存在的队列，负责该队列的人员其日历不在你的容量规划器的读取范围内，而管理它的 SLA（服务等级协议）甚至从未被书写下来。

那个队列就是你的人机回圈（human-in-the-loop, HITL）升级路径。你在三个月前为了“安全起见”添加了它——当智能体在极少数情况下置信度较低或操作风险较高时，它会将案例移交给人工审核员。上线之初，它每天可能只处理十几个条目。运维团队在处理其他任务的间隙就能搞定它们。它曾是一个兜底方案，而不是一个系统。如今，它正在处理数千个条目，解决时间的中位数翻了三倍，排队等待的客户正在悄无声息地流失。HITL 路径本身并没有失效。它只是不再被当作生产环境来对待了。

你的审核员今天早上做出的第 50 个决策与第 1 个决策的质量并不相同。架构图不会显示这一点。容量模型不会显示这一点。跟踪“每小时审批量”的仪表盘甚至在主动掩盖这一点。然而，你的人机回环（Human-in-the-loop，简称 HITL）系统的整个前提——即由人来捕捉模型产生的错误——从队列开始填充的那一刻起就在无形中退化。

大多数 HITL 设计将审核员的时间视为一种无限的、可互换的资源。团队设置一个置信度阈值，将所有低于该阈值的项路由到人工队列，并宣布系统是“安全”的。六周后，审批率已悄然升至 96%，队列深度是人员配置模型假设的两倍，抽样审计显示审核员正在对他们在第一天会标记出来的边缘案例点击“批准”。系统并没有崩溃，它只是通过“橡皮图章”式的盲目审批，让自己看起来运转良好。

大多数生产环境中的 AI 功能在发布时只带有一个置信度阈值。在阈值之上，模型给出回答；在阈值之下，用户会得到一句生硬的“我不确定”。这个单一的数值同时承担着两个完全不同的任务，这就是为什么即便你对已回答查询的准确率看起来不错，但信任度指标却已经连续两个季度下滑的原因。

正确的设计至少应该有两个切分点。一个“弃权”（abstain）阈值设在低位：低于该值时，模型拒绝回答，因为此时保持沉默比给出任何答案都更有价值。一个“升级”（escalate）阈值设在中间：在两个切分点之间，系统将案例交给人工审核员，而不是直接将其丢弃。将它们合并成一个刻度盘，你发布的产品在出错时和不确定时会让人感到同样无用——在用户只需打开另一个标签页就能找到免费替代品的市场中，这是最糟糕的处境。

这并不是什么新鲜想法。拒绝选项分类器（reject-option classifier）的文献自 20 世纪 70 年代以来就一直在主张拆分阈值，将“歧义”拒绝（输入介于已知类别之间）与“距离”拒绝（输入远离任何训练数据）区分开来。生产环境中的 AI 团队总是在以惨痛的方式重新学习这一教训，通常是在首次发布大约六个月后，当支持队列中挤满了询问“这玩意儿是坏了还是怎么了”的人时。

团队向 AI 工作流添加人工审批的方式，与他们在代码库中添加 if (isDangerous) requireHumanApproval() 的方式如出一辙：将其视为一个二进制开关，在设计时检查一次，然后便将其遗忘。架构图上的指标是“人工监督”旁边的一个绿色对勾。而真正重要的指标——人工花费了多长时间、他们是否阅读了任何内容、在点击批准时该条目是否仍然相关——却很少有对应的仪表板。

将人工审批者视为二进制开关，你就等于在不知不觉中构建了一个队列。而队列具有动态特性：积压量的增长速度超过了你的员工配置速度、陈旧性使昨天的决定变得毫无意义、疲劳让审查变成了“走过场”（rubber-stamping），以及优先级倒置让真正重要的那一个决策被排在三百个无关紧要的决策之后。架构图中看不到这些，但它们都会出现在事故回顾（incident retro）中。