过去很长一段时间里我都在帮团队验证多模态大模型的视觉能力到底能用在哪、能用到什么程度。最开始大家关心的是“模型能不能看图”后来发现几乎所有模型都能说出一段关于图片的话。等到真正接入 Agent 流程、把截图和文档图像喂进去做自动判断时问题才暴露出来模型确实“看”了图像但它的回答真的依赖这张图吗如果我把图换掉、遮住、甚至直接删掉输出会不会变这个研究方向就是标题里说的 The Illusion of Visual Tool-Use中文可以理解为“视觉工具使用的幻觉”。它讨论的是一类很隐蔽的问题模型在对话里表现出自己在使用视觉信息实际上结果可能来自文本提示、训练记忆或概率猜测图像根本没有参与因果推理。而 Causal Audit也就是因果审计是这类研究中用来分辨“真看图”和“假装看图”的方法论。这篇文章想解决的不是帮你复现论文里的某个实验而是把“怎么审计一个多模态模型是不是真的在视觉工具使用”这件事拆成可以落地执行的流程、指标和判断标准。适合正在做多模态应用、Agent 截图理解、文档问答、UI 自动化的人看。读完你至少知道怎么设计一轮最小可用的因果审计怎么读审计结果以及发现模型没有真正用图时下一步该往哪排查。1. 先理解“视觉工具使用”为什么会被质疑1.1 模型说自己“看到了”不等于真的在用这张图多模态大模型现在的交互方式很统一给一张图配一段文本模型输出一段回答。表面上这是“视觉工具使用”也就是模型把图像当作外部工具来获取信息、辅助推理。但这里有一个关键区别模型在输出里提到图和模型的输出真的由图像像素驱动是两件完全不同的事。我见过太多这样的例子。比如给模型一张后台数据看板的截图问它“上个月哪个渠道转化率最高”。模型回答得头头是道甚至连“折线图红色那条增长明显”都说得出来。但你如果把图换成一张完全无关的自然风景图只保留同样的文本问题模型可能仍然给出相似的答案。原因很简单这类问题在训练数据里大量存在模型可以依靠文本中的“上个月、渠道、转化率”这些词结合自己的先验知识编出一个看起来很合理的回答。这就是“幻觉”在视觉工具使用场景中的含义。它不一定指模型看到了不存在的物体而是指模型的推理路径没有真正经过视觉输入。模型表现出了“使用视觉工具”的样子但因果上没有依赖它。另一个常见场景是 UI 自动化。模型拿到一张软件界面截图被要求判断“当前页面是否有报错弹窗”。很多情况下模型会输出一个像模像样的判断。但如果把截图换成另一张完全不同的软件界面模型可能依然输出“有弹窗”。这说明决定输出的不是截图内容而是模型对“这个任务大概率会遇到什么情况”的猜测。1.2 因果审计要回答的问题普通评估问的是模型输出对不对因果审计问的是如果改变视觉输入模型输出会不会跟着变这个区别很关键。正确率一类的指标只能告诉你结果与标准答案的关系不能告诉你结果与输入图像的关系。一个在视觉问答测试集上拿到高分的模型并不一定真的在看图。它可能只是训练数据里的文本线索足够强模型学会了走捷径。因果审计的核心思路来自经典的因果推断要做归因就必须做干预。不能只观察模型“提到”图片而要把图片当成一个可以删掉、替换、遮挡、篡改的变量主动改变它观察输出是否发生可测量、可重复的变化。放到工程实践里因果审计要回答的问题通常包括删除图像后模型输出变化有多大把图换成一张语义无关的图模型会不会仍然给出相同结论裁剪掉关键信息区域后模型是否还能准确描述细节图像与文本描述冲突时模型到底信哪个这些问题背后指向同一个判断模型是在“读取图像信息”还是只是在“读过类似的题”。2. 为什么这个问题值得单独做一轮审计2.1 常规评估指标会掩盖真相很多人觉得只要模型在测试集上分数高就说明它视觉能力强。但常规的多模态评估有一个天然漏洞很多问题只靠文本就能回答甚至文本就是问题本身的一部分。这类样本会抬高整体分数却掩盖了模型对图像的真正依赖程度。举个例子一个文档问答测试集里问题是“发票号码是多少”而发票图片里恰好有一串数字。模型训练时见过大量类似格式它完全可以基于文本问题猜测一个数字格式。这样的输出在评估标准下可能算对但实际上跟图片没有因果联系。更隐蔽的情况是对话连贯性。一个 Agent 每隔几秒截一次屏模型每次都能说出一段与当前操作相关的话。因为中间有大量上下文图片其实只是“背景板”真正起作用的是历史消息。人眼看到的是模型在分析截图实际上模型只是在顺着对话惯性继续编。所以如果只在常规指标上做验证很容易误判一个模型“已经具备视觉工具使用能力”。这在 demo 阶段无所谓但一旦进入批量处理、自动化生产问题就会被放大模型会做出不符合当前画面的决策而且错误看起来很自然难以拦截。2.2 工具使用场景会放大“假看图”的代价多模态模型被当成 Agent 的工具使用是最近最热的方向之一。所谓视觉工具使用通常指模型调用视觉能力去完成截图理解、图像比对、文档识别、空间定位、流程判断等任务。这些场景比单纯的看图问答更危险因为输出通常是后续动作的直接依据。比如模型看完网页截图判断“登录按钮在页面右上角”然后让自动化脚本点击。模型看完报表截图判断“本月销量下降”然后生成分析报告。模型看完医疗影像描述图判断“病灶区域大小”然后写出结论。在这些任务里如果模型没有真正依赖图像后果不只是答案不准确而是整个自动化流程建立在一个虚假的承诺上。你以为系统有视觉能力其实它只是文本生成能力套了一层多模态外壳。这也是为什么“因果审计”不能省它测量的是系统能力的真实边界而不是表面行为。另外实际部署时还要考虑成本和延迟。如果模型根本不需要图像就能给出合理输出那引入视觉输入只会增加 token 消耗、传输时间和推理负载。审计一遍之后你甚至可能发现纯文本方案更合适。3. 因果审计的实操流程干预、对照、归因3.1 基础范式先正常跑再干预视觉输入因果审计不需要一开始就上复杂框架。我建议先把核心实验流程搭起来用最小样本验证再逐步扩展。基础范式分四步第一步准备一组样本。每一条样本要包含一张图像、一段文本提示、一条期望结果。样本必须来自真实业务场景不要只在公开测试集上做。公开集中有很多文本捷径你的业务数据才能反映真实问题。第二步正常跑一遍。把图像和文本一起喂给模型记录完整输出、推理耗时、置信度如果有、token 消耗。第三步设计干预。对同一图像做多种改变保持文本提示完全不变。改变方式需要针对你想审计的能力来选择。第四步比较输出。把正常输出和干预后的输出做对比判断模型是否因为视觉输入的变化产生了实质性的输出变化。这里有一个容易忽略的前提文本提示必须完全一致。如果连提示都改了你就分不清是提示词还是在图在起作用。同样的模型参数也要锁定。建议把 temperature 设为 0并固定随机种子。如果模型 API 不允许传 seed就同一实验跑 3 到 5 次取主要结果。3.2 干预方式对照表针对不同问题干预方式的选择也不同。下面这张表可以作为基础模板干预类型具体操作审计目的如果模型真的在用图删除图像只发送文本提示判断整体因果依赖输出应该明显退化或改变随机替换换成另一张无关图判断是否对图像内容敏感输出应该与图相关明显变化局部遮挡用色块遮住关键区域判断是否关注关键信息位置细节描述会丢失或出错模糊处理降低图像分辨率判断对细节的依赖程度精细能力下降粗粒度能力保留打乱布局对多区域图做位置乱序判断是否依赖空间结构空间判断类任务会出错文本图像冲突图与文本描述信息矛盾判断信息优先级模型应倾向图像或明确发现冲突实际测试时不一定要做全部选两到三种与业务最相关的即可。比如做 UI 自动化局部遮挡和删除图像最有价值做文档问答随机替换和模糊处理更有效做图表分析打乱布局能快速暴露“模型会不会真的读轴标签”。3.3 输出比较的判断指标很多因果审计卡在最后一步怎么判断输出“变了”。不能只靠肉眼扫一遍必须定义可量化指标。我一般会从四个维度看第一是文本一致性。用 ROUGE、BLEU 或字符串编辑距离计算输出相似度。这样能快速发现干预前后是否高度重合。如果删除图之后输出和正常输出几乎一模一样那基本可以判定视觉输入没有因果作用。第二是语义一致性。用 embedding 模型计算两个输出向量的余弦相似度。有的模型换了图之后说出来的话完全不同但意思一样说明它只是在用不同的表达覆盖同样的文本先验。这种情况文本指标会误判语义指标更靠谱。第三是下游动作一致性。这是业务上最关心的。把输出解析成结构化动作比如“点击按钮 A”“返回错误信息”“标记为可疑”比较干预前后动作是否一致。哪怕文本内容变了只要动作不变业务上仍然要警惕。第四是内部置信度。部分模型 API 会返回 logprobs 或置信度分数。干预后置信度明显下降也能说明模型“意识到”图像变化影响了判断但这只能作为辅助信号不能单独作为依据。4. 从样例选择到批量审计细节决定结果可信度4.1 样例要覆盖五类情况因果审计的结果是否可信很大程度上取决于样本有没有覆盖模型的“偷懒路径”。我的经验是至少覆盖以下五类答案只在图里、文本没有线索比如一张只有图片的表格问题是“第三行的值是多少”文本本身不含答案。文本有强提示、图像是补充比如问题里直接写了“图片中有三个按钮”让模型判断按钮状态。图像与文本冲突文本说“按钮是红色”图片里按钮是蓝色看模型采信哪个。多图多轮Agent 场景经常是多张截图连续出现模型可能只看最后一张。低质量图像模糊、光线差、分辨率低、旋转、倾斜这类输入最容易暴露模型是否在认真读图而不是靠猜测。样本数量上没有固定门槛。如果只是初步判断50 条足够看出倾向如果要作为上线依据建议至少 200 到 300 条并且和业务方确认每条的标准答案。4.2 批量跑法记录、命名和重试审计一旦批量执行就要把实验流程工程化不然数据一多就乱。我会把每个样例的元数据统一记录成一个 JSON 或 CSV 文件字段包括case_id唯一标识建议带业务前缀。intervention_type正常/删除/遮挡/替换等。image_path原始图像路径。prompt完整文本提示。model_output模型完整输出。latency_ms推理耗时。temperature/seed模型参数。timestamp任务执行时间。status成功、失败、超时。输出文件命名也要规范。我习惯用case_id加intervention_type作为文件名避免覆盖。注意不要把所有干预结果写进同一个文件最后分析时难以比对。批量任务还经常遇到 API 超时和限流。这里不要简单地把超时判为失败要区分“模型返回失败”和“请求没有送达”。建议设置固定重试次数重试时保持原参数不变不能因为重试就改 temperature否则会引入额外噪声。4.3 环境控制与模型版本很多团队跑了第一次审计没发现问题换了模型版本后突然出现大量“删图后输出不变”的情况就以为模型退化。实际上可能是上一版模型真的看图这一版模型因为对齐策略调整更依赖文本。所以审计报告必须带上完整的模型版本、接口地址、快照时间。如果使用开源模型要记录权重文件哈希值或 commit id。还有一个容易被忽略的变量是图像预处理管线。同一个模型你本地读图后转成 base64和通过 SDK 直接传文件效果可能不同。因为 SDK 可能会对图片做压缩、缩放或转码。审计时最好先验证这一步打印预处理后的图像尺寸、格式和文件大小确认传给模型的内容和你原始图像一致。5. 审计结果怎么读四类结果和判断标准5.1 四类结果有了干预数据和量化指标接下来就是把每条样本归类。我通常分成四类。第一类强依赖。删除图像后输出明显变化替换成无关图后输出也明显变化而且变化方向与新图像内容一致。这类样本说明模型确实在使用视觉信息因果链路完整。第二类部分依赖。删除图像后一部分字段或结论变了另一部分不变。这通常说明模型只使用了图像中的某些区域或某些通道。比如文档问答里模型读了标题但没读表格正文。这类结果提示的不是“没看图”而是“看得不够细”。第三类无依赖。删除图像后输出和正常输出高度一致。这种情况最常见的原因是任务本身依赖文本先验或者提示词让模型不自觉地绕开图像。对这类样本要先检查提示词是否明确要求必须基于图像回答。第四类反向依赖。删除图像后输出反而更准确。这说明图像不仅没有帮助还在干扰模型。常见于模型对图像做了过强的先验推断比如看到模糊截图就自动脑补出一个错误界面。5.2 判断标准要结合业务目标四类结果没有绝对的好坏。对同一个模型不同任务可能落在不同类别。比如一个模型在“识别图片里文字”的任务上是强依赖但在“判断界面布局是否合理”的任务上是无依赖。所以审计报告里不要写“模型有没有视觉能力”而要写“模型在哪些任务上使用视觉信息、在哪些任务上没有”。具体判断标准建议这样定如果业务要求模型基于截图做决策至少 80% 的样本落在“强依赖”或“部分依赖”才建议上线。如果模型会在“无依赖”样本上给出错误结论说明存在风险需要加入人工校验或规则兜底。如果出现“反向依赖”优先排查输入预处理和提示词这类问题经常不是模型本身能力不足而是图片经过管线压缩后信息丢失。5.3 审计的边界不要说成最终结论因果审计测量的是“当前样本、当前提示、当前模型版本”下的因果关系。它不能回答“模型是否天生具备视觉能力”也不能保证换一批样本后结论不变。所以每次报告都要写清楚边界本次审计只覆盖了业务场景中的哪些输入类型。样本量是多少有没有覆盖冲突和低质量图像。审计时用的提示词是什么是否经过了多轮迭代。模型版本和图像预处理参数是什么。后续模型更新、提示词改动、图像管线调整都需要重新跑审计。6. 如果视觉输入真没用接下来怎么排查6.1 先检查输入管线再怪模型发现大量“无依赖”样本时不要第一时间下结论说模型能力不行。按这个顺序排查第一确认图像真的传到了模型。用本地脚本打印请求体里图像字段的长度和内容然后对模型输出目录里的图像做验证。常见问题是 base64 编码过程出错、图像路径写错、多模态接口只接收了 URL 而 URL 实际打不开。第二检查图像预处理是否破坏了关键信息。很多外部图像经过缩放后小号文字会变得不可读。模型确实“收到了图”但图里的信息已经丢失了。这种情况下审计结果很可能是无依赖因为图里根本没有可用的视觉线索。第三检查提示词有没有给出清晰的“看图信号”。如果提示词是“请回答以下问题”模型可能优先走文本路径。改成“请基于提供的图像分析注意图像中的关键区域”结果会不同。但这属于提示工程优化不是因果审计本身。第四确认模型版本支持细粒度视觉推理。某些模型号称多模态但实际视觉编码器分辨率很低对密集文本和细节区域处理能力有限。可以通过一个简单测试验证给模型一张只包含一个数字的图片问“图中数字是几”。如果连这个都做不对说明视觉骨干网络有问题。6.2 改进方向从“看整图”到“分治法”如果审计确认模型确实没有有效使用视觉信息有几种改造思路。第一种是拆分任务。把“看图并回答”拆成“OCR 提取文字 结构化解析 文本推理”。例如报表分析先做大图 OCR再用传统规则或文本模型解析表格最后让语言模型做汇总。这样视觉部分只负责提取不负责推理更容易保证因果链路。第二种是图像预处理增强。对大图做关键区域裁剪把表格、图表、按钮区域分块放大分别输入模型最后汇总。很多情况下VLM 的视觉能力不是没用而是整图缩略后细节丢失太多。切块之后图像信息的可读性会大幅提升。第三种是提示词强制结构化输出。要求模型在回答中引用图像中的具体坐标、文字位置、颜色值或区域描述。比如“请输出按钮的 bounding box 坐标以及按钮上的文字”。这种要求会迫使模型从图像中提取具体证据降低凭空猜测的概率。第四种是加“无图基线”。在业务系统里内置一个纯文本版本只输入上下文和提示词不做视觉推理。当多模态输出与纯文本输出高度一致时自动标记该样本为“可能存在视觉幻觉”转人工处理。这样即使模型在某些样本上没有真正看图系统层面也能兜底。7. 给实际项目的一份最小审计清单7.1 动手前先准备好这些如果你决定在自己项目里做一轮因果审计建议先准备好四样东西一组可以复现的业务样本至少 50 条标注好预期结果。一个稳定的模型调用脚本记录请求参数、模型版本、完整输出。一张干预方式表明确每种干预要回答什么问题。一份结果记录模板每个样本至少包含正常结果和干预结果两组数据。工具上不需要额外的复杂框架Python 脚本加一个 CSV 文件就够了。如果业务方需要报告可以把结果整理成 Markdown 或 Excel每类结果给一个百分比。7.2 最小审计报告的字段一份能拿上项目例会的审计报告至少要有这些字段字段说明审计日期每次运行都要记录模型版本精确到接口版本或权重版本样本数量覆盖多少条业务样本干预类型删除、遮挡、替换等强依赖占比输出随图像显著变化的样本比例无依赖占比输出几乎不变的样本比例典型失败案例无依赖且输出错误的样本截图结论与建议是否可以上线、需要加什么兜底审计报告不要只写结论要附上能复现的样本。这样后续模型升级、提示词优化时可以快速回归。7.3 我的建议如果只是学习一个多模态模型默认配置跑一遍 demo 就好不需要做完整审计。但如果你准备把它接入自动化流程尤其是涉及截图、文档、界面判断的 Agent 场景我建议从第一天就把因果审计当成验收流程的一部分。先跑单条样本确认干预逻辑有问题再跑 50 条小样本判断四类结果占比如果判断结果可信再扩展到几百条同时把报告指标和业务验收标准绑定。真正值得记住的不是工具本身而是“模型提到图像”和“模型依赖图像”之间的距离。这个距离越短系统越能被信任。