9 篇博文 含有标签「multimodal」

仪表板显示，这个版本的质量提升了两个点。文本评估套件运行正常。你的模型供应商发布了一个新的 Checkpoint，在你跟踪的每个公开基准测试上都超过了前一个版本。你推进了发布。一周后，支持团队标记了一个隐蔽但持续增长的工单量上涨，内容关于上传的屏幕截图 —— 用户反映模型“读错了图表中的数字”或“漏掉了表格中的一行”。几天后，音频转录的投诉接踵而至，主要来自非美式英语使用者。这些都没有出现在你的评估流水线中。发布看起来很健康。但事实并非如此。

这就是多模态评估漂移（Multimodal Eval Drift），几乎每一个在以文本为核心的架构上硬塞进视觉和音频功能的团队都在发布这种问题。曾经适用于文本的评估规范 —— 黄金集（Gold Sets）、LLM 作为评委（LLM-as-judge）、漂移仪表板、以及决定是否发布的综合评分 —— 在多模态领域仅剩空名。每个模态的失败率不具可比性，捕捉文本错误的评分标准（Rubrics）捕捉不到图像错误，而且产生文本黄金集的标注流水线是针对每半年发布一次的工作量校准的，而不是针对伴随每次 Checkpoint 更新而来的多模态退化。

正确的心智模型是：多模态并不是同一个模型上的一个开关 —— 它是一个具有不同失败分布的不同产品面，而忽视了这一区别的评估规范在每次模型发布时都在输出隐形的退化。

大多数构建AI智能体的团队在投产三个月后都会发现同一个问题：他们精心设计的评估套件——围绕文本输入和JSON输出构建——当智能体遇到模糊的发票、扫描合同或从未见过的UI截图时，毫无参考价值。纯文本评估通过了，但用户提交了工单。

多模态输入不仅仅是另一种需要接入的模态，它们引入了一类截然不同的故障，需要不同的架构决策、不同的成本模型和不同的评估策略。将视觉能力视为对现有文本智能体的即插即用扩展的团队，无一例外地低估了所需的工作量。

大多数采用多模态AI的团队都会犯同样的错误：他们在精心策划的基准数据集上评估模型，并假设生产性能会与之相符。然而现实并非如此。视觉模型在MMMU基准上取得高分，与同一模型在生产中可靠地从发票中提取结构化数据之间，存在足以葬送产品发布的巨大差距。视觉编码器增加了基准排行榜上无法体现的延迟。空间推理在用户实际发送的图表类型上失效。在干净语音上表现良好的音频模型在真实世界的噪声下土崩瓦解。而多模态真正优于纯文本的任务类别，比供应商所暗示的要窄得多。

本文是关于这一差距的实战指南——它在哪里出现，为什么存在，以及哪些部署模式能在生产负载下保持稳定。

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

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

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

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

大多数团队在意识到他们的语料库中很大一部分内容——产品截图、演示录制、架构图、客服通话录音——对于纯文本检索系统是不可见的之后，会将多模态 RAG 加入到他们的路线图中。在生产环境中令他们感到惊讶的并不是嵌入模型的选择或向量数据库的选择，而是模态之间的差距：同一个语义概念，当被编码为图像和句子时，会落在向量空间中完全不同的区域，而搜索引擎根本不知道它们是相关的。

这篇文章涵盖了多模态嵌入对齐的技术原理、在大规模场景下真正有效的跨模态重排序策略、相对于纯文本 RAG 的成本和延迟状况，以及多模态检索特有的失效模式。

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

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

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

大多数团队在向现有的 LLM 流水线添加多模态能力时，往往没有先计算成本。他们用几张测试图片做了原型，运行良好，然后就上线了——直到收到第一张账单。根据调用量的大小，账单上的数字往往介于“令人尴尬”和“灾难性”之间。

问题不在于多模态 AI 在原则上有多贵，而在于每种模态都有独特的 Token 计算逻辑，它们会以一种你凭纯文本直觉无法预料的方式复合叠加。只需一个配置参数——比如视频帧率、图像分辨率模式，或者你是否在每一轮对话中重复发送系统提示词（System Prompt）——都可能在你不经意间，让你的推理费用翻上 10 倍甚至更多。

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

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