多模态流水线在生产环境中的挑战：当你超越文本时会发生什么

大多数 LLM 工程经验 —— 缓存提示词、调整温度、控制 token 预算 —— 都假设输入是文本、输出也是文本。一旦加入图像、PDF 或音频，这些经验几乎全部失效。预处理方式不同，故障模式不同，成本模型也不同。而你为文本流水线构建的评估套件，根本发现不了新出现的问题。

企业知识中约有 50% 存储在非文本格式中：PDF、幻灯片、扫描表单、产品图像。当团队尝试处理这些数据时，他们会发现，引入多模态不仅仅是增加一种模态 —— 而是增加了一个全新的工程复杂度层面。

基准测试的差距比你想象的更大

在讨论生产环境中会出现什么问题之前，有必要先理解你的基准测试有多乐观。一个在干净基准数据集上报告 97% OCR 准确率的模型，在生产环境中处理金融文档时，准确率通常只有 75–80%。对于复杂的金融报告，编辑距离误差几乎是基准数据所示的两倍。

根本原因是数据分布不匹配。基准数据集经过精心筛选，干净整洁，且代表了模型训练时见过的问题。你的生产数据完全不同：包含多栏布局、带有倾斜和噪点的扫描文档、合并单元格的表格，以及经过 CDN 压缩的图像。基准与生产之间的差距不是模型质量问题 —— 而是你的评估套件尚未被设计来发现的数据质量问题。

一个实用的校准方法：如果模型在某项任务的标准基准上达到 X%，在获得实际证据之前，假设生产环境中会低 10–20 个百分点。

图像输入：Token 经济学与静默故障

将图像接入流水线时，第一个意外是成本模型与文本完全不同。图像成本与像素面积成正比。一张 1000×1000 的图像大约需要 1,334 个 token，而 200×200 的图像只需约 54 个。25 倍的尺寸差异带来 25 倍的 token 成本差异 —— 但不一定带来更好的结果。

几个硬性限制会导致难以调试的静默故障：

• 超过 API 提供商最大尺寸的图像会被直接拒绝，而不是被缩放
• 在单个请求中发送超过 20 张图像会对每张图像施加更严格的尺寸限制
• 超过请求大小限制（通常为 32 MB）的请求在任何模型推理运行之前就会被拒绝

这些故障都不像模型错误。它们看起来像网络错误、超时错误，或者根据客户端的处理方式而呈现为空响应。

一个不那么明显的性能问题：宽度超过约 1,568 像素的图像会在推理之前被服务端自动降采样。你支付原始图像的全部 token 费用并承受缩放带来的 TTFT（首 token 时间）损失，但模型看到的是较小版本。在发送之前将图像预缩放到合理的最大尺寸，不需要任何额外成本，就能消除延迟和计费低效的问题。

JPEG 压缩是另一个陷阱。对人眼不可见的压缩伪影 —— JPEG 质量 60、压缩比超过 10x —— 可能将 OCR 准确率从 90% 以上降至 60% 以下。CDN 和上传流水线经常会自动应用这种压缩。如果你的图像经过任何中间存储或分发层，请验证压缩设置是否在悄悄降低流水线依赖的输入质量。

PDF 提取：生产故障的主要来源

PDF 是大多数企业环境中最大量的多模态输入，也是造成最多生产故障的原因。核心问题在于，"PDF" 描述的是一种文件格式，而不是内容类型。一个文档处理流水线必须处理：

• 带有干净文本层的可搜索 PDF
• 带有不同质量 OCR 叠加层的扫描文档
• 线性文本提取会打乱阅读顺序的多栏学术论文
• 包含表格、脚注和侧边栏与正文交错的密集金融报告

没有任何单一的提取方案能正确处理所有这些情况。将所有 PDF 发送到同一个流水线是最常见的架构错误。

表格提取值得特别关注，因为表格频繁出现在团队最希望处理的高价值文档（金融报告、合同、研究论文）中。生产环境中常见的故障模式：

• 列错位：来自不同列的文本合并，产生不连贯的内容
• 单元格关系丢失：合并单元格和跨行表头无法保留；原本结构化的表格变成无序文本
• 阅读顺序混乱：脚注和侧边栏出现在段落中间
• 公式损坏：数学符号变成乱码

约 30% 的生产 PDF 提取故障具体源于表格错位。解决方案很少是更好的提取器 —— 而是在选择提取策略之前先检测文档类型。一个轻量级分类器，将简单文本 PDF、复杂布局 PDF 和扫描图像区分开来，只需几毫秒，就能将每种文档路由到合适的工具。

来自已解决这一问题的团队的实践经验：在提取的文本中保留空白字符和制表符间距，通常比重建正式的 HTML 表格标记效果更好。模型能够理解文本中表示的空间布局；精心设计的 DOM 结构增加了复杂性，却没有带来相应的收益。

边缘情况的分布使路由问题更加复杂。通常，生产文档语料库中 15–20% 的文档造成了 60–80% 的提取故障。这些边缘情况在结构上往往与常见情况截然不同 —— 不寻常的布局、非标准字体、降质的扫描件。要为它们构建准确的评估，需要真实的生产样本，而不是合成或基准数据。针对边缘情况样本进行约 500–1,000 个有针对性的标注，比对提取栈进行任何通用改进都能更快解决大多数生产故障。

音频流水线：300 毫秒的预算

语音流水线面临一个文本或图像流水线不存在的延迟约束：对话式响应需要在用户停止说话后约一秒内开始，否则体验会显得卡顿。

顺序流水线架构 —— 转录音频、将文本发送给 LLM、合成响应 —— 会引入 2–4 秒的延迟。这对交互式应用来说是不可接受的。解决方案是在每个阶段都进行流式处理：在音频仍在传输时开始转录，在转录出第一批文字后立即开始 LLM 生成，在收到第一批 LLM token 时就开始 TTS 合成。

即使全程流式处理，预算也很紧张。粗略的时间分配：

• 音频传输：50ms 以内
• 语音转文字的第一个部分结果：100–200ms
• LLM 首 token 时间：200–400ms
• TTS 首段音频时间：100–300ms

任何阶段超出预算，累积延迟就会超过阈值。分别监控每个阶段很重要 —— STT 延迟的退化在端到端指标中是不可见的，直到它持续将总延迟推过阈值。

两个容易被忽略但回报很高的预处理步骤：语音活动检测（VAD）在音频到达计费系统之前去除静音，对于有自然停顿的录音来说可降低 30–40% 的成本。基于模型的轮次检测，而不是仅依赖 VAD 的轮次检测，能处理说话者中途停顿思考的常见情况，而不会触发过早的 LLM 响应。

跨模态幻觉：文本流水线中不存在的故障模式

纯文本 LLM 的幻觉表现为生成看似合理但无依据的文本。多模态模型还有一种额外的故障模式：基于模型预期看到的内容而不是实际内容来生成图像描述。

其机制是语言先验主导。当视觉证据模糊时 —— 低分辨率、重度压缩、低对比度 —— 模型会退而根据训练分布生成统计上可能的描述。一张呈现不寻常表现的医学图像可能会收到符合常见病理的描述，即使实际图像显示的是完全不同的东西。一张带有严重 JPEG 伪影的产品图像，其颜色或文字描述可能会根据学习到的关联被补全。

多模态模型中出现四种文本流水线不存在的幻觉类型：

• 物体幻觉：描述图像中不存在的元素
• 属性幻觉：物体正确，但属性错误（颜色、大小、数量）
• 关系幻觉：空间关系被颠倒或虚构
• 捏造描述：发明与视觉内容毫无关联的内容

一个实用的诊断方法是空白图像替换测试：比较模型在图像存在与替换为空白图像时的准确率。如果替换为空白图像后准确率下降很小，说明模型依赖的是语言先验而非视觉证据。更好的图像并不能解决这个问题；它需要模型层面的干预。

安全性：每种模态都扩大了注入攻击面

纯文本流水线面临提示注入这一安全威胁。多模态流水线则在每种模态上都面临这一问题。

嵌入图像中的对抗性指令 —— 对人类审阅者不可见，但会被模型解读 —— 已被证实可针对所有主要视觉语言模型发起攻击。即使在限制注入内容显著性的隐蔽约束下，攻击仍然成功。

音频注入是一种更新且在操作上更令人担忧的变体。在合法输入前添加一段不到一秒的对抗性音频突发，会导致转录模型将合法内容视为次要内容或输入结束。在当前生产模型上，攻击成功率超过 85%，包括在音频通过扬声器播放到房间里而非直接注入音频流的物理世界条件下。

在生产环境中值得实施的缓解措施：

• 在处理之前重新编码图像 —— 这可以去除对抗性像素级模式
• 对于敏感操作，运行双模型架构：一个模型从多模态输入中提取内容，另一个模型在不访问原始输入的情况下对提取的文本进行操作
• 将每个用户提供的图像或音频文件视为不可信输入，而不是被动的数据来源

服务架构：模态干扰

当纯文本请求和图文混合请求共享同一推理工作节点时，它们会相互干扰。在 LLM 推理之前进行的视觉编码器预处理引入了可变的额外开销，可预见地会导致共存的文本请求出现延迟峰值。这种干扰模式在单独运行每种模态类型的基准测试中不会出现。

生产环境推荐的模式是按模态类型分配独立的工作节点池，并进行感知模态类型的自动扩缩容。扩缩容信号不同：文本工作负载根据请求数量和每秒 token 数进行扩缩；图像工作负载根据像素吞吐量和编码器计算量进行扩缩。混合这些指标会产生对两者都无法正确响应的自动扩缩规则。

生产多模态工作负载还表现出重尾分布特征 —— 少量非常大的文档或非常长的音频文件主导着计算消耗。一个按请求跟踪各模态计算成本（而非仅追踪 token）的成本归因系统，能让这一情况变得可见，并使容量规划能够加以考虑。

构建真正能发现多模态故障的评估套件

标准文本评估会遗漏整个类别的多模态故障。多模态流水线的评估套件需要三个层次：

使用生产样本进行离线测试。 基准数据集无法代表你的实际数据。从真实生产输入中整理测试集，特别是包含造成大多数故障的边缘情况文档和图像。特定领域的指标（金融文档的逐行对账准确率、产品目录的属性提取精度）比通用准确率分数能提供更多信息。

通过有针对性的采样进行在线监控。 对每个请求运行评判器，对于多模态输入来说成本过高。自适应采样 —— 根据模态类型、置信度信号或输出异常选择请求 —— 以可控成本提供覆盖范围。视觉依赖分数（比较正确与不匹配图像-问题对上的性能）在不需要标注真值的情况下就能检测语言先验主导。

从生产故障中进行回归控制。 每个到达用户的生产故障都应该成为一个固定的测试用例。这对于多模态流水线比文本流水线更重要，因为故障模式更难预测，输入的分布范围更广。将评估套件视为生产基础设施，而不是上线前的检查点。

普适性规律

已经稳定运行多模态生产流水线的团队，都汇聚到了几个共同的决策：在选择提取策略之前对输入复杂度进行分类，在任何 LLM 调用之前运行输入验证（分辨率检查、格式验证、大小限制），按模态类型分离服务基础设施，并从生产数据而非基准测试中构建评估。

其背后的原则是：多模态输入不可互换。文本 token 具有可预测的成本、可预测的质量和可预测的故障模式。图像 token、音频 token 和 PDF 页面如果没有前置的显式预处理和路由逻辑，则不具备这些特性。那些将多模态视为文本流水线的即插即用扩展的团队，最终会在生产环境中为这一假设付出代价。