生产级 AI 流水线中的视觉输入：无人记录的预处理决策

你的视觉模型在评估套件上跑出了 90% 以上的分数。接着，真实用户上传了实体文档的照片、低 DPI 显示器的屏幕截图，以及经过三次传真机往返扫描的 PDF。准确率骤降。模型“正常运行”——它返回了连贯的响应——但在没有已知标准答案（ground truth）的情况下，这些响应的错误方式很难被察觉。你将其归咎于“模型限制”并继续前进。

模型本身可能不是问题，输入流水线才是。

大多数构建视觉大语言模型（Vision LLMs）的团队在提示词工程（prompt engineering）和模型选择上投入了巨大精力，而在图像到达模型之前的预处理上几乎投入为零。这种不对称正是生产环境质量崩盘的根源。那些无人记录的预处理决策，也是导致生产环境多模态系统准确率无声下降的最大元凶。

分辨率：无声的 Token 预算权衡

每个视觉模型供应商都有分辨率预算，且处理方式各不相同。Claude 会对长边超过 1.15 megapixels (1568px) 的图像进行降采样。GPT-4o 会将图像放入 2048×2048 的边界框中，将短边缩放至 768px，然后切分成 512×512 的分块（tiles）。Gemini 则有自己的切分流水线。同一张 2048×2048 的图像在 Claude 上大约消耗 1,590 个 token，在 GPT-4o（高细节模式）上消耗 1,105 个 token，而在 Gemini 上大约只需 280 个 token——这种实现细节掩盖了 5 倍的成本差异。

成本差异的重要性次于像素的变化。当供应商在后台悄悄缩小你的输入尺寸时，你无法得知哪些信息被丢弃了。对于名片的照片，缩放可能会抹除电话号码。对于医疗扫描，它可能会抹平你需要模型检测到的病变。Claude 的 API 文档指出，任何边长低于 200px 的图像“可能会降低输出质量”——但这种失效模式并不是报错，而是给出一个听起来合理但错误的响应。

MME-RealWorld 基准测试（ICLR 2025）使用了 13,366 张真实世界的图像（平均分辨率为 2,000×1,500px），结果发现即使是表现最好的模型，在高清真实场景下的准确率也难以突破 60%。而这些模型在传统基准测试中几乎达到了饱和。这种差距主要不在于模型能力，而在于干净的基准测试图像分布与用户实际产生的图像分布之间的不匹配。

该怎么做： 在将图像传递给 API 之前，先自行预缩放图像。设定明确的目标百万像素上限，通过信箱模式（letterboxing/padding）保持长宽比，并记录原始尺寸和输出尺寸。当你控制缩放时，你知道丢弃了什么。而当供应商代劳时，你并不知道。

压缩伪影：不是你想的那个问题，而是你忽略的那个

当团队遇到视觉质量问题时，首先调查的通常是 JPEG 压缩，但它往往不是主因。Vision Transformers 在 JPEG 质量因子为 85 时仍能保持 98% 以上的分类准确率，而在质量因子为 80 时，在标准分类基准测试中的下降最多只有 1.22 个百分点。在正常的 Web 质量设置下，JPEG 压缩是次要问题。

真正的核心问题是模糊，特别是来自移动端拍照的运动模糊。深度神经网络对模糊和噪声的敏感度远高于对 JPEG 压缩伪影或对比度变化的敏感度——这一结论从图像分类器延伸到了视觉语言模型。当用户在移动中用智能手机拍摄实体文档时，产生的模糊比上传流水线可能应用的任何压缩都更具破坏性。

第二个压缩问题具有不同的特性：OCR 任务中的压缩悬崖。在 10 倍压缩比下能达到 97% 字符级准确率的 OCR 系统，在 20 倍压缩比下准确率可能会骤降至 60%。这不是渐进式的退化，而是一种阈值效应。一个在网页截图和扫描 PDF 上表现良好的流水线，在处理从本身就是有损源生成的打印输出图像时，可能会发生灾难性的失败。

该怎么做： 在流水线处理的每张图像上记录模糊指标（拉普拉斯方差是一个廉价且有效的代理指标）。设置一个阈值，低于该阈值则拒绝输入、请求重新拍摄或降低对模型输出的置信度。模糊是可测量的且计算成本低廉；不测量它意味着你在面对最大的输入质量衰减因素时是在盲目飞行。

长宽比处理：无声累积的不匹配

标准的建议是使用信箱模式（填充）而非拉伸图像至目标尺寸。这种推理是正确的——拉伸会引入系统性的形状畸变，影响所有需要比例推理的任务。但真实世界的失效模式比“拉伸 vs 填充”更微妙。

问题在于一致性。如果你的训练或微调数据使用了一种长宽比策略进行预处理，而你的推理流水线使用了另一种，那么模型在推理时看到的输入在分布上是系统性偏差的。这很容易意外引入：微调数据是由数据科学团队使用默认拉伸的库预处理的；而推理流水线是由工程团队编写的，他们独立选择了填充。这两个选择单独看都是合理的，但结合起来就是一个无声的倒退。

GPT-4o 的分块流水线引入了一个相关问题：不寻常的长宽比可能会将具有语义重要性的区域切割到不同的分块边界。一张宽大的数据表格截图可能会从表头中间横向切断。模型接收到两个分块，每个看起来都很连贯，但却丢失了让原始图像具有可解释性的结构上下文。

该怎么做： 确定一种长宽比处理决策，并在训练、评估和推理中始终如一地执行。将其视为 API 合约：aspect_ratio_strategy: letterbox | pad_color: white | target: 1024x1024。如果你正在使用供应商的分块流水线且无法控制分块边界，请意识到宽全景图像和长文档扫描是风险最高的长宽比。

OCR 预处理：将文本故障与视觉故障解耦

生产环境中最常见的视觉故障类别是文档图像中的文本提取。这种故障模式的代价尤其高昂，因为模型的响应通常看起来是正确的——语法通顺、格式得体——但却包含错误的数字或读错的字符，而这些问题只有在下游环节才会暴露出来。

可靠的 OCR 需要至少 300 DPI 的有效分辨率。移动端拍摄的纸质文档通常只有 72–150 DPI 的有效分辨率。低于这个阈值，无论模型能力如何，字符级识别都会变得不可靠。故障的原因并非模型缺乏 OCR 能力，而是输入的信息不足以恢复文本。

PreP-OCR 流水线研究表明，纠偏（deskewing）、降噪（denoising）和对比度增强是在将文档图像传递给视觉语言模型之前的必要步骤。这些不是可选的质量改进，而是“可处理输入”与“不可处理输入”之间的本质区别。一份倾斜 3 度且光照不均的扫描文档，在预处理后可以被正确读取，而没有预处理则会完全失败。

这里的实际工程模式是将文本识别故障与结构化理解故障解耦。对文档图像运行传统的 OCR 处理（如 Tesseract 或商业服务），并将原始图像和提取出的文本同时传递给视觉模型。这会为你提供两个独立的故障信号：如果 OCR 文本是乱码，说明输入质量有问题；如果 OCR 文本清晰但模型响应错误，说明模型推理有问题。没有这种区分，你就是在调试一个黑盒。

评估与部署的差距：为什么你的测试套件在撒谎

上述所有故障背后的模式都是一样的：评估数据比生产数据更干净，而模型学会了利用这种“干净”。

你的评估套件是用开发者生成的截图、光照良好的产品图以及从未经过打印和重新扫描的 PDF 构建的。这些图像比真实用户上传的任何内容都更清晰、构图更好、格式更统一。当模型在这样的评估中得分超过 90% 时，它证明的是它能处理看起来像测试用例的输入。它并不能证明它能处理一个 62 岁的用户在荧光灯下用屏幕碎裂的手机拍摄的账单照片。

针对视觉语言模型对图像伪影（artifacts）鲁棒性的研究在这一点上结论一致：模型对强且明显的伪影检出率很低（在受控研究中约为 11–19%），而弱伪影——那种在人类审核员看来没问题的伪影——会使准确率降低 3–10 个百分点，且不会触发任何可观察到的故障信号。模型不会说“我读不了”，它会读错。

更深层的问题是，视觉语言模型经常倾向于使用文本训练的先验知识，而不是视觉证据，尤其是在与训练数据分布相似的图像上。这意味着模型在干净的评估截图上看起来像是在进行视觉推理——通过模式匹配记忆的内容给出正确答案——但在需要真正视觉定位的生产环境图像上却会失败。评估结果令人印象深刻，部署效果却不然。

该怎么做： 建立一个生产环境图像的影子数据集。获取一份真实用户上传图像的样本（在获得适当授权并处理好隐私的前提下），运行模型，并人工审核其中的子集。根据评估准确率校准你的实际生产准确率。如果差距超过 10 个百分点，那么在改进模型之前，你的预处理流水线更需要优化。

一个最小化的归一化流水线

将模型故障与输入故障分开的归一化流水线并不复杂。然而，它却经常被系统性地忽略。

其组成部分包括：

• 验证门（Validation gate）：拒绝短边长度低于最小值（Claude 文档中规定的下限为 200px）的图像，检查损坏或不支持的格式，并返回结构化的错误，而不是静默传递损坏的输入。
• 分辨率归一化：根据你的目标像素预算调整大小，通过加黑边（letterboxing）保持纵横比，并记录每个请求的原始尺寸和缩放后尺寸。
• 模糊检测：计算拉普拉斯方差（Laplacian variance），记录该值，并将低于阈值的请求标记出来供后续分析。
• 格式标准化：在传递给 API 之前，将 WebP 和 GIF 转换为 PNG 或 JPEG；服务商对这些格式的处理逻辑文档较少，且可能存在差异。
• 针对文本密集型输入的 OCR 预处理：对于文档处理，运行传统的 OCR 步骤，并将图像和提取的文本同时传给模型；同时记录 OCR 的置信度分数和模型输出。
• 可观测性日志：记录每个请求的输入尺寸、模糊度得分、OCR 置信度、Token 成本和模型延迟。没有这些，你无法区分是模型退化还是输入质量退化。

没有任何一项需要自定义模型或重大的工程投入。大多数功能都可以在一个周末内实现。常见的故障模式并非因为它们难以构建，而是团队直到发生事故、意识到缺失它们的代价后才会去构建。

结论

关于多模态 AI 工程的讨论往往集中在模型能力上：哪个视觉模型的基准测试分数最高，哪种架构处理分辨率的效果最好，哪个供应商的切片算法效率最高。这些确实是需要考虑的因素，但与模型调用上游的预处理规范相比，它们都是次要的。

如果一个团队构建了严谨的归一化流水线 —— 验证输入、控制缩放行为、检测模糊、将 OCR 故障与模型故障解耦、记录每次请求的质量指标 —— 那么他们的表现将优于一个拥有更好模型但缺乏流水线规范的团队。这并不是因为他们的模型更好，而是因为他们知道模型何时失败以及为什么失败。

你在干净的屏幕截图上运行的评估套件只能告诉你模型在干净的屏幕截图上的表现。这是有用的信息，但它并不能预测生产环境的准确率。构建流水线，对其进行监控，然后你才会真正了解你的模型表现如何。