供应商重新校准后，你的智能体所信任的转录置信度得分

语音智能体有一个门控机制。转录置信度高于 0.85 的任何内容都会直接进入规划步骤；低于该值的内容则会被路由给人工。该阈值是六个月前针对标记的真实客户通话语料库进行调优的，随后被固定在配置文件中并被遗忘。在六个月的时间里，它确实履行了职责。然后，转录服务提供商发布了模型升级——同样的 API、同样的响应形式、同样的延迟范围、同样记录在案的准确率——但在接下来的两周里，该智能体开始向错误的人授权电汇。

“给妈妈转账 50 美元”变成了“给 Tom 转账 5,000 美元”。新的转录结果返回的置信度为 0.91，远高于门控阈值。下游规划器看到了一个置信度很高的转录结果并据此执行。客户的申诉最终暴露了这个 Bug，但到那时，支持队列已经将一周内类似的事件作为欺诈纠纷过滤掉了。复盘分析将差距追溯到团队从未明确做出的一个决定：旧模型的 0.85 和新模型的 0.85 是同一个数字。

它们并非同一个数字。供应商的发布说明在六项变更日志中的第三项提到了“置信度头（confidence head）的校准更新”。供应商自身基准测试的词错率（WER）保持不变。然而，供应商在固定参考集上的置信度分布向上移动了大约 15 个百分点。之前得分在 0.70–0.85 范围内的所有转录结果（该范围曾是团队明确选择拦截的）现在的得分都在 0.85–0.95 之间，从而毫无阻碍地通过了门控。

置信度得分不是概率——它是一种校准

语音智能体架构中最常见的误读是将转录 API 返回的置信度数值视为概率。它并不是。它是针对供应商评估集上与正确性相关联而训练的独立的、特定于模型的“头（head）”的输出。一个校准良好的模型分配 80% 的置信度，那么它大约有 80% 的时间应该是正确的。大多数生产环境中的 ASR 模型并没有经过良好的校准，而那些针对一种分布进行了良好校准的模型，在针对另一种分布时通常会校准失衡。

这一点之所以重要，是因为两个供应商（或者同一供应商的两个模型版本）可能会产生完全相同的原始转录，但置信度数值却有实质性的差异。Deepgram、AssemblyAI 和 Whisper 都会提供 0 到 1 之间的浮点置信度，数值范围看起来是可以互换的。但事实并非如此。一个模型的 0.85 与另一个模型的 0.85 不具备可比性。在同一个门控之后更换供应商的团队，在不修改代码的情况下改变了门控的严格程度。

更深层次的问题是，即使在同一供应商内部，置信度头也可以独立于声学模型进行重新训练。供应商经常这样做。他们发布一个新的模型检查点，使用相同的名称、相同的 SLA、相同记录在案的 WER，但置信度头是在不同的数据上以不同的温度（temperature）训练的。准确率数值（大多数客户追踪的唯一指标）没有变化。校准曲线却不同了。关于 ASR 置信度校准的研究在过去二十年里一直在记录这些数值在领域偏移（domain shift）下是多么脆弱，但生产团队很少将这种脆弱性视为合同契约的一部分。

阈值是与特定分布达成的契约

当一个团队在配置中写入 confidence > 0.85 时，他们并不是在选择一个置信度水平——他们是在对他们所调优的数据上的置信度得分的经验分布进行编码。在该分布之外，那个数字没有任何语义。如果模型的置信度头被重新训练且分布发生偏移，相同的阈值现在就对应于一个不同的决策边界。

观察这一点的一个具体方法是：代码中的常量 0.85 同时承担着两项工作。它指定了目标精度（即被接纳的转录结果中应该是正确的比例），并指定了目标接受率（即通过门控的转录结果比例）。只有当置信度头的校准保持不变时，这两者才是同一个数字。当校准向上偏移时，接受率会上升，而团队却认为精度保持不变。门控变宽松的程度，正好是团队没有衡量到的那部分。

校准漂移可能来自几个方面，且大多数不会触发通知：

• 供应商侧的模型升级，改变了置信度头的训练机制。
• 团队自身侧音频采集质量的变化——不同的麦克风、不同的编解码器、不同的比特率——这使运行时分布偏离了调优分布。
• 用户群的统计学或口音转变，将输入分布移动到了供应商校准集中代表性不足的区域。
• 通话环境噪声概况的变化（55–65 dB SNR 的背景噪声水平已经可以根据编解码器的不同使准确率降低 15–30%，而在这种压力下，置信度的波动往往比准确率更大）。

在每一种情境下，团队的门控逻辑都准确执行了指令，但处理的是那些含义已经悄然改变的数字。智能体在自信中失败了。

加载中…