高置信度（0.9+）：12% 出错。低置信度（<0.5）：68% 正确。这个信号坏了。

LLM 自报的置信度分数对升级决策的校准很差。模型可以在给出错误的政策建议时报告 0.9 的置信度，又在一个能轻松解决的常规退货上报告 0.3。调任何阈值都修不了这个——信号本身就和是否需要升级不可靠地相关。

校准数据

5,000 个案例，记录了置信度和实际结果：

最高和最低之间只有 20 个百分点的区分度（88% 到 68%）。即使最高置信度下，12% 的案例是错的。最低置信度下，68% 仍然是对的。这么弱的区分度意味着没有阈值能在需要升级和不需要升级的案例之间产生清晰分割。

为什么阈值修不了这个

在 0.7 阈值下：

• 误升级： 0.7 以下 74% 的案例是正确的（浪费人工时间）
• 漏检错误： 0.9 以上 12% 的案例是错的（未被发现）

降低阈值能捕获更多错误但升级更多正确案例。提高阈值减少不必要的升级但漏更多错误。这个取舍无法逃避，因为信号本身就弱。

情绪分析：同样的问题，不同的信号

客户情绪与案例复杂度不相关。一个沮丧的客户可能只是物流延迟的简单问题，几秒钟就能解决。一个冷静的客户可能有需要人工权限的复杂政策例外。

数据：70% 由情绪触发的升级是简单问题，人工在 2 分钟内就解决了。同时，冷静客户的复杂政策问题由代理处理（处理错了），因为没触发情绪阈值。

情绪和复杂度是独立变量。情绪按错误的标准做路由。

组合两个弱信号也没用

即使组合情绪和置信度也只有 42% 的精度。显式标准达到 91%。正确的信号大幅优于错误的信号，无论怎么组合。

替代方案：可观测条件触发器

用显式的、可验证的条件替换情绪和置信度：

1. 客户明确要求人工 — 直接陈述，不需要解读
2. 检测到政策空白 — 没有政策覆盖该场景
3. 2 次实质性尝试后无有意义进展
4. 需要政策例外 — 请求需要代理没有的权限
5. 安全/合规问题 — 确定性的，规则引擎检查

每个触发器映射到一个具体的、可验证的人工介入理由——不是一个可能相关也可能不相关的代理信号。

代码审查：同样的原则

一个 CI 系统压制了一条关键的 SQL 注入发现（置信度：0.45），同时放行了误报的风格问题（置信度：0.85）。用显式的严重等级标准替换基于置信度的过滤：为 HIGH 发现定义具体条件（数据丢失、安全边界、崩溃路径），让过滤基于可验证的代码特征而非自我评估的置信度。

数据提取：编程式验证

用确定性检查替换基于置信度的质量门控：

• Schema 验证（字段类型、必填字段）
• 跨字段一致性（行项目加总等于 total）
• 源验证（提取值出现在源文档中）

这些检查捕获了置信度分数漏掉的错误，而没有 40% 的浪费审查——那些”低置信度”但实际正确的提取被路由到人工审查了。

一句话总结： LLM 置信度分数在最高和最低区间之间只有 20 个百分点的区分度——用显式的可观测条件触发器（91% 精度）替换它们，而不是在一个根本就弱的信号上调阈值（28-42% 精度）。