生产环境中的多模态 LLM 输入：视觉、文档以及那些无人预警的失效模式

为 LLM 应用添加视觉能力看起来简单得令人误解。你将文本模型换成多模态模型，在提示词中加入一张图片，演示效果就非常出色。但在推向生产环境后，你会发现有一半的发票金额是错的，PDF 中的表格丢失了结构，而低质量的扫描件会产生言之凿凿的幻觉。调试这种系统的难度超过了你以前面对的任何纯文本系统，因为这些失败是视觉上的，且 LLM 不会告诉你它看不清楚。

本篇文章将介绍当多模态 LLM 输入从原型转向生产环境时，究竟会发生什么问题，以及能够防止这些失败的架构决策。

视觉 Token 不是免费的 —— 且呈二次方增长

生产环境中的第一个惊喜是成本。视觉 token 的定价通常比文本 token 高 2–5 倍，且消耗的 token 数量随图像分辨率呈二次方增长，而非线性增长。

GPT-4o 的高细节（high-detail）模式运作方式如下：图像被切分为 512×512 像素的块，每个切片耗费 170 token，外加 85 token 的基础开销。一张 1024×1024 的图像会产生 4 个切片 —— 仅一张图片就需 765 token。如果将其扩展到一个每天处理 50,000 份发票的文档流水线，在你还没写下一行提示词之前，这个数字就已经非常可观了。

Claude 的切片预算类似：图像被分解为网格，长边上限为 1568 像素，每个块都会增加 token 计数。供应商建议“使用能满足任务的最低分辨率”，这听起来理所当然，直到你意识到“能满足任务的最低分辨率”需要针对每种文档类型进行实证测试，而不是一个全局设置。

优化路径包括：

• 在发送之前，将图像缩小到供应商的最大限制（Claude 为 1568px，GPT-4o 为 2048px） —— 大多数来自手机摄像头的生产图像分辨率为 4032×3024
• 对于仅需粗略视觉特征的任务（分类、路由），使用供应商特定的低细节（low-detail）模式
• 当对同一份文档进行多次查询时缓存图像 —— 针对图像的提示词缓存（prompt caching）可减少 90% 的重复成本

许多团队忽略了一点：在高分辨率下，视觉编码器的延迟占据了主导地位。当你发送一张 4K 图像时，瓶颈不在于 LLM 的推理 —— 而在于视觉编码器的处理时间，这会显著增加首字响应时间（TTFT）。在这里，延迟和成本是同步增长的。

OCR 与原生视觉的选择并非二选一

常见的表述是：“我该用 OCR，还是直接把图片传给 LLM？” 这种表述会导致错误的架构。正确的问题应该是：“我想要防止哪种失败模式，哪种方法可以避开它？”

原生视觉擅长的场景：

• 文档模板差异巨大（来自 200 个不同供应商的发票，每张布局都不同）
• 任务在提取的同时需要语义推理（“哪个是主要的行项目？”）
• 文档包含手写内容或混合脚本
• 你需要从文档中嵌入的图表、示意图或图像中提取信息

传统 OCR 胜出的场景：

• 你需要确定性的、可复现的输出（财务记录、合规文档）
• 文本清晰且结构良好（机器打印的表单）
• 你需要高于 97% 的字符级准确率
• 成本是主要约束且文档格式稳定

实际的陷阱是：团队因为原生视觉能处理布局变化而选择它，然后发现模型在 5% 扫描质量下降的文档上产生了幻觉，给出了言之凿凿但错误的数据提取。LLM 不会说“我看不清这个”。它会编造一个看似合理的数值。

新兴的生产模式是两阶段混合架构。一个轻量级的质量分类器负责路由文档：清晰、高质量的扫描件进入快速的 OCR 流水线，而复杂或模糊的文档则交给视觉 LLM。Grab 构建其文档处理系统（Documint）的工程团队就采取了这一方向 —— 他们发现，仅靠专有 LLM 速度太慢、成本太高，且在没有专门训练数据的情况下，会对东南亚语言文档（泰语、越南语）产生幻觉。他们基于 Qwen2-VL 并使用合成 OCR 数据进行微调的定制视觉 LLM，在保持非拉丁文字准确率的同时，比基础模型提升了 50% 的速度。

教训：供应商的基准测试准确率是在干净的基准数据集上测得的。你的文档并不是干净的基准数据集。

PDF 表格是大多数文档流水线的克星

加载中…