跳到主要内容

13 篇博文 含有标签「multimodal」

查看所有标签

多模态通道冲突:当模型在视觉与文本之间自我矛盾时

· 阅读需 12 分钟
Tian Pan
Software Engineer

这张图片是一张红色八角形停止标志的照片。有人在中间的单词上贴了一张小贴纸,上面写着“YIELD”(让行)。你问多模态模型:“这个标志写了什么?”模型回答:“该标志指示驾驶员在交叉路口让行给迎面而来的车辆。” 表现得既自信又流利,却既不忠实于视觉证据,也不忠实于文本证据。它是一个混合体,在产生分歧的真相通道之间采取了折中方案。

这种故障模式目前还没有一个统一的名称。研究多模态幻觉(multimodal hallucination)的研究人员将其称为“语义幻觉”(semantic hallucination)、“跨模态偏差”(cross-modal bias)或“模态主导”(modality dominance),具体取决于撰写论文的细分领域。交付文档 AI、截图智能体和缺陷检测系统的从业者每周都会遇到这种情况,并在事故复盘中将其描述为“模型只是在瞎编”。它不是瞎编的。这是一种在最终层融合了两个通道、却没有任何原语来表示通道意见不一情况的架构的可预测输出。

多模态输入中的提示注入:纯文本防御所忽视的视觉攻击面

· 阅读需 12 分钟
Tian Pan
Software Engineer

当团队对 AI 管道进行提示注入加固时,通常只聚焦于文本:清洗用户输入字符串、扫描输出中的外泄数据、过滤已知的越狱(jailbreak)模式。这些工作固然重要,但对于现代 AI 系统而言,它们大约只覆盖了一半的攻击面。另一半隐藏在图像、PDF、音频片段和图表之中——这些格式能绕过你写下的每一条文本扫描规则,因为模型处理它们的通道与处理文本的通道完全不同。

针对视觉语言模型的隐写注入攻击(steganographic injection attacks),在包括 GPT-4V、Claude 和 LLaVA 在内的生产模型上,成功率约达 24%。这个数字并非实验室数据,而是来自真实的攻击载荷——隐藏在看似普通的图像中,使生产模型偏离预期行为。你的文本注入扫描器对此毫无察觉。

增加模态是一次隐私分类事件,而非简单的功能开关

· 阅读需 12 分钟
Tian Pan
Software Engineer

一位产品经理在周二联系了 AI 团队:“客户想在支持代理中粘贴截图。这应该是件小事,对吧?模型已经支持图像了。” 工程主管检查了 SDK,确认视觉端点接受 JPEG 和 PNG,在功能开关(feature flag)后发布了更改,并向 10% 的用户推送。两周后,法务团队转来了一封监管机构的信函,询问为什么用户的银行账单、驾照照片以及包含另一位客户订单 ID 的截图都出现在了该代理符合训练条件的日志中。AI 团队中没人标记这次模态变更(modality change),因为没人认为模态变更 算是一次 变更。批准文本代理的隐私审查从未针对图像变体重新运行——而图像变体最终适用的授权、留存和驻留规则完全不同。

这不是一个关于粗心工程师的故事。这是一个关于大多数团队发布 AI 功能时内置的范畴错误的故事。文本输入是一个已知的、具有稳定威胁模型的细分数据类别:用户输入,用户看到他们输入的内容,工程团队在记录什么和丢弃什么方面有多年的习惯。图像是一个具有不同威胁模型的不同数据类别——它们夹带了用户看不到的元数据,捕捉了用户并非有意分享的周边内容,并以其自身的驻留和合同条款创造了存储和处理足迹。将“现在支持视觉”视为一次 UX 迭代,而它实际上是一个隐私分类事件,这就是团队如何根据监管机构的要求发现他们的 PII 清单将实际暴露程度低估了一个数量级的原因。

视频会议中的数字人:构建用于视频会议的实时对话头像 AI

· 阅读需 13 分钟
Tian Pan
Software Engineer

拥有面孔的语音智能体并非简单的“带脸的语音助手”。它是一个同步视频 AI 系统,当人类第一次看到口型落后于音频三帧,并下意识地(即使无法准确说出原因)判定屏幕上的东西是假的时候,这种差异就显现出来了。那些构建了 300 毫秒语音流水线,然后又在末尾强行塞入一个渲染模型的纯语音团队,刚刚继承了一个他们在路线图中未曾预料到的实时多模态问题。

这个门槛并不宽松。在音视频偏移低于约 45 毫秒时,观众会认为是完美同步。一旦音频领先超过 125 毫秒或音频滞后超过 45 毫秒,大脑就会将这种不匹配标记为错误,即使观众无法指出具体原因。在一个数字人必须同时倾听、思考、说话和渲染的对话循环中——且在你和用户之间还隔着网络——音频输出和渲染面孔之间没有任何余地来容纳拙劣的衔接。

多模态评估漂移:为什么在文本表现稳定的情况下,图像和音频路径会出现回退

· 阅读需 13 分钟
Tian Pan
Software Engineer

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

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

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

生产环境中的多模态智能体:纯文本评估从未发现的问题

· 阅读需 11 分钟
Tian Pan
Software Engineer

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

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

多模态AI在生产环境中的落地:基准测试与现实之间的鸿沟

· 阅读需 12 分钟
Tian Pan
Software Engineer

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

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

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

· 阅读需 10 分钟
Tian Pan
Software Engineer

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

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

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

· 阅读需 13 分钟
Tian Pan
Software Engineer

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

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

生产环境中的多模态 RAG:如何同时搜索图像、音频和文本

· 阅读需 14 分钟
Tian Pan
Software Engineer

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

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

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

· 阅读需 12 分钟
Tian Pan
Software Engineer

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

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

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

生产环境中的多模态大模型:没人会预先计算的成本账

· 阅读需 14 分钟
Tian Pan
Software Engineer

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

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