转录层的谎言：为何你的多模态管道会在下游产生幻觉

你的ASR系统返回了"the patient takes metaformin twice daily"。正确的词应该是metformin。转录看起来很干净——没有[INAUDIBLE]标记，没有错误标志。那个词的置信度是0.73。你的管道丢弃了这个数字，将干净的文本传给了LLM。LLM将其视为真实情况，围绕一种不存在的药物进行推理。

这就是转录层的谎言：一种隐性假设，认为中间文本表示——无论是由语音识别、OCR还是解析文档的视觉模型产生的——都足够可靠，可以不加保留地向下游传递。事实并非如此。但几乎每个生产管道都将其视为可信来源。

问题不在于ASR和OCR不准确。而在于它们对哪些部分不准确撒了谎。这些系统会为每个词、每个字段、每个token返回置信度分数。而标准工程模式是立即丢弃这些分数。

你正在丢弃的置信度信号

每个主要的ASR提供商都会为其输出附加逐词置信度分数。Whisper为每个token生成对数概率分数，通过对这些值求平均得出词级置信度。AWS Transcribe和Google Speech-to-Text都在0到1的范围内暴露词级置信度。OCR也是如此：Azure Document Intelligence将置信度分数精确到单个字段级别。Google Cloud Document AI也是如此。

但如果你按照大多数团队的方式构建管道，这些都无济于事：

音频 → ASR → 转录字符串 → LLM提示

转录字符串不记得哪些词是可信的，哪些是猜测。"metaformin"上的0.73被剥离了。LLM看到的是平铺文本，无从知晓中间某个词不可靠。它按照给定的输入进行推理。

OCR管道以略有不同的方式犯下这个错误。文档级置信度分数通常会被呈现——"此页面以92%的置信度提取"——但这个数字掩盖了所有真正有趣的信息。一份整体准确率92%的表单，可能有三个关键字段的提取置信度仅为0.40。文档级汇总数字用一个令人安心的数字掩盖了字段级别的失败。

微软在其Document Intelligence平台上的研究对此直言不讳：文档AI系统会无声地失败。下游使用者在没有任何信号的情况下对错误数据采取行动。

不确定性如何在下游复合

一个被误识别的词不仅仅是数据质量问题。它是一个会传播的损坏事件。

当LLM收到没有任何不确定性信号的嘈杂转录时，它会做两件事之一：按字面意思处理文本，或者尝试"修复"它。第二种行为实际上更糟糕。关于基于LLM的ASR错误纠正的研究表明，当模型尝试纠正转录时，它们会在尝试修复错误词的同时对正确的词产生幻觉。当整体输入质量下降时，准确文本上的幻觉率会增加——LLM无法区分哪些部分值得信任。

机制很简单。低置信度的词会破坏LLM依赖的注意力模式来构建连贯的解释。输入中的不确定性实际上与重要性负相关：模型最不确定的词往往是承载最多语义权重的词——名字、数字、领域特定术语、药物名称。

在基于智能体的管道中，复合效应更严重。产生嘈杂文本的感知步骤会为在此之上构建计划的推理步骤提供信息。计划再馈给行动步骤。错误在每次交接中累积。当系统采取行动时，原始的不确定性已被"洗白"——看起来像是自信、结构化的输出，但其溯源包含了两步之前一次抛硬币式的转录。

分布偏移使这个问题急剧恶化。ASR系统在未经调优的条件下最容易产生幻觉：重口音、背景噪音、专业词汇、跨语言音频。在这些条件下，一些系统会在静音期间生成虚假词语。下游LLM收到的是看起来正常的文本，却没有任何怀疑的依据。

三种真正有效的设计模式

置信度门控路由

最简单的修复是将置信度分数视为路由信号，而不是要丢弃的元数据。与其将所有转录输出统一传给LLM，不如构建一个基于阈值的路由器：

• 置信度高于阈值的词或字段（通常是通用场景0.80，高风险领域0.95）直接进入LLM管道。
• 低于阈值的词被标记、隔离或发送到单独的处理路径——人工审核、更慢更强大的模型，或者明确的澄清请求。

AWS Lex V2原生支持这种模式：来自AWS Transcribe的转录置信度分数可以控制机器人是尝试响应还是升级给人工客服。同样的模式可以推广到任何管道。关键洞察是你不需要LLM处理所有事情——你需要它处理它能正确处理的事情。

这种方法确实需要你在整个处理管道中保留置信度分数，这意味着改变你表示中间状态的方式。转录不是字符串。它是一个（词，置信度）对的列表。你的数据模型应该反映这一点。

置信度感知提示

当你必须将不确定内容发送给LLM时，上下文窗口是浮现你所知道信息的正确地方。与其发送：

转录：the patient takes metaformin twice daily

发送：

转录（方括号内为词语置信度）：the [0.98] patient [0.96] takes [0.99] metaformin [0.73] twice [0.97] daily [0.95]

置信度低于0.80的词可能被误识别。在未标注不确定性的情况下，不要根据低置信度词做出临床推断。

关于置信度增强提示的研究表明，当模型获得关于输入可靠性的明确信号时，下游错误率有可测量的降低。模型并不总能正确使用这些信息——它并不从根本上"理解"0.73意味着不确定——但提示中的明确不确定性标签降低了模型将边界输入视为权威信息的概率。

对于OCR管道，同样的技术在字段级别适用。与其传递一个提取字段的平铺JSON，不如包含一个并行的置信度映射。指示模型将低置信度字段视为缺失，除非文档中的其他证据能够确认。

歧义信号化而非静默纠正

嘈杂输入管道中最糟糕的模式是静默的最佳猜测纠正：系统选择最可能的解释并以确定性的态度继续。这就是自信的输出如何掩盖一条概率假设链。

更好的方法是使歧义明确，并以下一个组件能够处理的形式向下游传递。与其将"metaformin"解析为最佳猜测，不如将其表示为未解决的歧义：[metaformin|metformin|metroformin]。下游系统——无论是LLM、人工审核员还是业务规则引擎——可以根据该决策的风险程度来决定如何处理这个歧义。

关于歧义检测管道的研究将此形式化为三阶段过程：识别模糊输入、生成澄清问题或候选选项、结合上下文解决。解决步骤可以发生在LLM层（利用周围上下文选择最合理的选项）、人工层（向审核员呈现选项）或业务逻辑层（当高风险字段存在任何歧义时升级）。

重要的架构转变是：歧义不是在LLM看到输入之前需要消除的东西。它是需要在管道中携带的信息，直到具有足够上下文的组件能够解决它。

实践中的优雅降级

以上三种模式都需要管道变更，这意味着需要预先的工程投资。团队往往抵制这一点，因为问题是不可见的——管道看似正常工作，错误看起来像是模型问题而非数据质量问题，而且两步之前0.73的置信度分数与最终幻觉输出之间的联系很难追溯。

实际路径是从优雅降级作为回退方案而非重新设计开始：

将不确定案例路由出自动化路径。 任何汇总置信度低于阈值的输入都不应自动处理。这不需要重新考虑你的数据模型——只需在LLM调用之前添加一个置信度门控。

记录置信度分数，即使你不使用它们。 在没有这些数据的情况下，多模态管道的生产调试极为困难。如果你知道LLM产生错误输出的某次运行有一个包含三个低于0.70词语的转录，那是你可以采取行动的信号。如果你丢弃了这些分数，你就是在调试一个黑盒。

区分文档级别和字段级别的置信度。 如果你的OCR管道返回汇总分数，检查底层API是否支持字段级别分数。大多数现代文档AI提供商都支持。汇总分数恰好在最重要的字段上隐藏了失败。

在分布偏移条件下测试，而不仅仅是基准条件。 你的ASR系统的基准准确率是在提供商训练分布的干净音频上测量的。它对于它在你的呼叫中心音频、嘈杂仓库环境或非母语口音用户上的表现毫无说明。在将系统视为可靠之前，先在你的实际输入分布上测量词错误率和置信度校准。

更深层的模式

转录层问题是组合AI系统中一种更普遍故障模式的实例：中间表示丢失了原始模型产生的不确定性元数据，而下游组件从有损表示中推理，仿佛它是权威信息。

这在每个组合边界都会发生。向量嵌入丢失了检索模型的置信度分数。结构化提取丢失了提取步骤的不确定性。摘要丢失了源材料中的警告。每次转换都压缩了不确定性信息，到最终输出产生时，系统对本应不确定的事情表现出了自信。

解决方案不是放弃组合——而是将不确定性视为一种在管道中传递而不是在每个边界被剥离的一等数据类型。置信度分数不是在ASR调用返回后要丢弃的元数据。它们是关于后续所有内容可靠性的信号。

构建对不确定性保持诚实的多模态管道比不诚实的更难。但这是一个系统在错误输入上大声失败，与一个自信地产生错误输出直到三个月后人类注意到出了问题之间的区别。