之前在做多模态 Agent 项目时我遇到一个很典型的现象模型明明在测试集上能把“看图 调用工具”的任务跑通一旦换到线上真实场景准确率就断崖式下跌。更让人困惑的是你很难说清楚模型到底是真正理解了图像内容还是仅仅根据上下文中的工具名称、参数格式、甚至一些和图像无关的统计规律“猜”对了答案。这种“会但没完全会”的状态在相关研究里被称为Visual Tool-Use 的幻觉问题。这篇文章我想围绕“视觉工具使用中的幻觉现象”展开重点介绍一种更严谨的评估思路——因果审计Causal Audit并拆解“Thinking with Images”这类多模态推理场景下模型能力为什么容易被高估。无论你是做算法评估、模型选型还是正在开发基于视觉大模型的 Agent 应用这篇文章都能帮你建立起一套更可靠的判断框架到底怎么评估模型是真会还是假会。文章包含核心概念讲解、因果审计的流程设计、实验思路、代码示例和工程建议内容偏方法论但又不止于理论。1. 背景Visual Tool-Use 是什么为什么值得关注先看一个最简单的场景。假设你做了一个 AI 助手它可以根据用户上传的户型图调用一个工具函数calculate_area(diagram_id)返回房间面积。这个过程中模型要完成两件事看图片理解户型图的房间布局。根据理解结果选择合适的工具并填入正确的参数。这就叫视觉工具使用Visual Tool-Use。它和普通的“看图说话”不同核心差异在于模型不只是输出文字描述而是要通过工具调用来完成一个实际动作。工具调用的参数、名称、格式是否准确直接决定任务成败。在传统视觉问答VQA任务里模型回答“沙发在茶几左边”答错了也就错了影响相对有限。但在工具使用场景里一个错误的参数可能引发后续一连串错误操作比如计算错误、下单错误、重复提交等。所以视觉工具使用能力直接决定了一个多模态 Agent 能否在真实业务中落地。1.1 视觉工具使用的典型链路为了便于理解我们可以把一次完整的视觉工具使用流程拆成几个阶段阶段说明常见模型/技术视觉感知输入图片提取视觉特征Vision Encoder如 ViT、CLIP 的视觉分支跨模态推理将图像信息与文本指令融合推理出需要执行的动作多模态大模型如 GPT-4V、Gemini、Qwen-VL 等工具选择从候选工具列表里选出最合适的一个模型自身的指令遵循能力参数生成根据图像内容生成工具调用参数模型的生成能力 结构化输出约束工具执行与反馈执行工具并返回结果模型根据结果进一步决策Agent 框架、Tool 执行引擎其中最容易出问题的就是“跨模态推理”和“参数生成”这两步。模型可能看懂了图但不知道选哪个工具也可能选对了工具但参数是从错误信息里推断出来的。1.2 所谓“幻觉能力”是什么“幻觉能力”是我自己归纳的一种说法指代以下现象模型在评估集上表现出很强的工具使用能力但这种能力并非来自对图像内容的真实理解而是来自数据集中的虚假关联、上下文捷径、或者模型内部先验知识的“巧合输出”。换句话说模型看起来会用视觉工具但实际上它的决策过程并不依赖图像本身。一旦把图像换成无关图片或者稍微改变图像中的关键信息模型的工具调用结果可能完全不变——因为它根本没有“看图”。这就是“The Illusion of Visual Tool-Use”的核心含义视觉工具使用的表象之下隐藏着对图像理解的缺失。2. 因果审计如何识别“真实能力”与“虚假能力”既然“看结果”不可靠那该怎么办我们需要一种更严格的评估方法。这就是因果审计Causal Audit的用武之地。2.1 因果审计的定义因果审计简单说就是通过人为干预模型输入中的关键变量观察输出是否发生“应有的”变化从而判断模型是否真正建立了输入与输出之间的因果联系。它的核心逻辑是如果模型真的理解图像内容那么改变图像中的关键信息模型的输出就应该跟着改变。如果模型输出对图像内容的变化“无动于衷”那就说明图像内容并不是模型决策的原因模型存在虚假能力。这就像审计一个员工的业绩——只看他签了多少单不够还要看他是不是真的有能力签单还是仅靠运气、关系、或者数据失真。2.2 因果审计与相关性评估的区别传统的模型评估本质上是在评估“相关性”输入图片 文本指令 → 模型输出工具调用 → 和标准答案比对 → 算准确率。这种评估方式只能说明在这些样本上模型的输出和期望输出是匹配的。至于这种匹配是“因果性”的还是“偶然性”的传统指标无法区分。因果审计则更进一步。它通过“对照实验”的方式去验证“图像输入”是否为“工具输出”的原因。用一张图来理解两者区别传统评估 图片A 指令 → 工具X正确 → 得出结论模型会看图 因果审计 图片A 指令 → 工具X正确 图片B篡改关键信息 指令 → 工具X依然正确 → 得出结论模型根本没看图输出和图像无关因果审计的价值就在于它能识别出传统评估里的“幸存者偏差”和“数据泄漏”。这在多模态模型评测中越来越重要。2.3 因果审计的三个核心步骤结合相关研究思路一个完整的因果审计通常包含三步构建干预选择图像中的关键视觉属性如物体颜色、位置、数量、空间关系等对这些属性进行系统性修改生成干预样本。目标是想清楚哪些视觉属性是工具调用应依赖的“因”。对比输出用原始图片和干预图片分别运行模型记录工具调用结果是否发生变化。因果判定如果干预后的输出与干预前一致说明模型没有建立“该视觉属性 → 工具调用”的因果链路存在幻觉能力的风险。这个流程和因果推断中的“干预Intervention”思想一致但在大模型时代它的实施重点变成了如何设计有效的干预策略以及如何解读模型输出的变化。3. Thinking with Images图像推理的复杂性在视觉工具使用场景中一个常见的误区是把“图像输入”当成“图像理解”。模型接入了图片并不等于模型依赖图片。这背后涉及多模态模型“Thinking with Images”用图像思考的复杂性。3.1 图像在推理链路中的角色当我们说“模型用图像思考”时至少包含以下三种可能角色含义举例图像作为信息源模型从图像中提取事实信息用于回答问题看图识别水果种类然后调用“下单”工具图像作为推理锚点图像触发模型调用已有先验知识看到一张机场照片模型调用“查询航班”工具图像作为无关干扰模型输出并不依赖图像内容无论图片是什么模型都调用同一个工具前两种是“合理使用图像”第三种则是幻觉能力的高发区。问题是我们很难从一次成功的输出中判断模型到底属于哪一种。同一个结果背后可能完全不同的推理路径。这就像两个人同时答对一道题一个人真正会做另一个蒙对了。如果只看分数无法区分。3.2 多模态推理中的“捷径学习”为什么模型会发展出这种“不依赖图像的捷径”原因通常有三个训练数据偏差训练数据中特定图像类型与特定工具调用之间存在高频共现。模型学到的是“这张图大致长这样 → 调用该工具”而不是“这类图像的某个具体特征 → 需要调用该工具”。文本先验主导多模态大模型本质上还是语言模型主导的架构。文本指令本身可能已经包含了足够多的线索让模型在不看图的情况下也能猜出答案。图像只是“装点门面”。评估集标注不严谨人工标注的评估集往往存在“可猜测性”——标注者本身就倾向于根据常见情况打分导致答案有规律可循模型可以利用规律。这些因素叠加就会导致一种结果模型在评估集上表现优秀但在真实世界的开放场景中一旦遇到“看图才能决定参数”的新情况能力迅速坍塌。3.3 为什么“开放场景”更脆弱在开放场景中图像与工具调用之间的关联是多样且可变的。比如用户上传的图片可能模糊、倾斜、光照异常。图片中的关键物体可能被遮挡或变形。图片内容与工具参数的关联可能依赖复杂的背景知识。如果模型只是学到了“训练集内图像 → 工具”的表层映射面对这些分布外的图像它就很容易失效。因果审计的价值正是要在模型上线前提前暴露这种脆弱性。4. 实战设计一个视觉工具使用的因果审计方案下面我们用一个简化示例展示如何实际落地一套因果审计实验。假设我们有一个多模态模型它需要根据用户上传的“商品图片 用户指令”调用一个get_price(product_info)工具返回商品价格。第一版评估结果准确率 85%看似不错。接下来我们用因果审计的方式重新评估模型的真实能力。4.1 定义审计目标和关键变量首先要明确工具调用的“因”应该是什么。在这个场景里模型要生成正确的工具参数商品名称、规格、数量等它必须从图片中识别出商品名称。所以关键视觉属性是商品名称比如红色保温杯、黑色无线鼠标商品外观特征比如带不带提手、是否是机械键盘审计问题修改图片中的商品对象模型是否相应改变“商品名称”参数4.2 构建干预样本我们准备两组图片对照组原始图片一张黑色无线鼠标的图片。干预组篡改图片将图片中的鼠标替换为键盘或者用文本提示词更明确地标注为“键盘”。这里的干预要遵循一个原则只改变要审计的视觉属性尽量保持图片其他属性不变。在实际操作中可以使用图像编辑工具、合成图片或者构造一个简单的图像插值实验。示例干预逻辑可以用伪代码表示def build_intervention_samples(original_image, visual_attribute, new_value): 根据原始图片生成干预样本。 这里只是示例思路实际需要接入图像编辑工具或调用图像生成模型。 intervened_image edit_image( imageoriginal_image, attributevisual_attribute, # 例如 object_category new_valuenew_value # 例如 keyboard ) return intervened_image4.3 运行相同指令记录输出对原始图片和干预图片分别输入完全相同的用户指令用户指令请根据商品图片调用 get_price 工具查询该商品的价格参数为商品名称。记录模型两次输出的工具调用参数。预期行为如果模型真的会看图干预后的商品名称应从“鼠标”变为“键盘”。如果模型存在幻觉能力两次输出可能完全相同仍然调用“鼠标”。4.4 对比结果并判定下面是两种可能的结果对比样本输入图片模型输出商品名称判定原始图片黑色鼠标鼠标正确干预图片替换为键盘黑色键盘鼠标异常干预图片替换为键盘黑色键盘键盘正常如果干预组输出仍是“鼠标”则说明模型输出并未真正依赖图像内容存在幻觉能力。4.5 扩展审计维度除了“替换物体”我们还可以从多个维度审计模型的视觉工具使用能力审计维度干预方式工具使用中应变化的参数物体类别鼠标 → 键盘商品名称物体数量一个苹果 → 三个苹果商品数量物体颜色红色杯子 → 蓝色杯子商品规格/款式空间位置左图与右图互换布局描述相关参数背景干扰干净背景 → 杂乱背景是否仍能识别主体每个维度都代表一种“视觉因果链”。模型只有能在多个维度上都“随图而变”才说明它建立了稳健的图像理解能力。5. 常见误区与排查思路在实施因果审计时我自己踩过几个坑也看到不少团队会犯类似错误。下面集中总结。5.1 干预样本构造不干净问题现象常见原因解决思路干预后模型输出变化但原因不明干预操作不仅改变了目标属性还改变了图片整体风格、亮度、对比度尽量使用可控的图像编辑工具或在干预前后做对比可视化确认只改了目标属性干预样本和真实场景差异过大用过于极端的图像拼接导致模型识别失败干预样本要贴近真实使用场景不要为“制造差异”而脱离实际图像中的文字信息泄漏图片中本身带有商品标签文字模型直接读文字审计时先检查图片中是否存在与答案直接相关的文本5.2 指令设计引入偏差问题现象常见原因解决思路模型输出正确但和图像无关指令中包含了答案线索审计时指令应只包含“任务说明”不包含“答案提示”指令过于复杂模型不理解把审计任务和推理过程混在一起审计时用最简单的指令聚焦单一工具调用提示词中注入工具名某些提示词模板会固定工具名审计工具选择时应让模型从多个候选中自由选择而不是直接给答案5.3 结果解读过度激进因果审计的结论不能只看一两次实验。模型输出具有随机性而且不同数据分布下的表现可能不同。建议每个干预维度至少测试 50 条以上样本。重复运行 2 到 3 次记录输出稳定性。对审计结果使用统计检验观察干预前后输出分布的差异是否显著。如果只是做了 5 张图就断言“模型没有视觉能力”结论可能不够稳。5.4 审计维度覆盖不全很多团队只审计“物体类别”一个维度其他维度完全不管。但真实业务里模型可能物体识别没问题但对“数量”和“空间关系”非常迟钝。审计之前先梳理一遍在这个工具使用任务中最终要生成的每个参数分别依赖图像中的哪些视觉信息建议做一个审计维度清单逐项排查不要只盯一个维度。6. 最佳实践构建可信的视觉工具评估方案经过因果审计的实践我觉得有几条经验特别值得分享。6.1 评估指标要分层不要只用“工具调用准确率”一个指标评估模型。建议至少分成三层评估层面指标含义工具选择工具命中率模型是否选对了工具参数生成参数准确率EM/F1模型生成的参数是否准确因果一致性视觉干预敏感度模型输出是否随关键视觉属性变化只有当“工具命中率”“参数准确率”和“因果敏感度”同时达标时才能谨慎地认为模型具备视觉工具使用能力。6.2 将因果审计纳入上线流程在模型上线前推荐按下面的流程做评估用常规评测集跑通基线指标。基于任务定义梳理工具参数与视觉属性的对应关系。构造干预样本做因果审计。审计不通过的维度针对性补充训练数据或进行提示词优化。审计通过后再进入灰度测试。这样可以避免一个很尴尬的局面模型在测试集上分数很高上线后被用户连续反馈“根本不会看图片”。6.3 利用审计结果指导数据标注因果审计不仅能用来评估模型还能反哺数据标注如果审计发现模型在“物体数量”维度上不敏感说明训练数据中“同图不同数量”的样本过少。如果审计发现模型在“空间关系”维度上不敏感说明训练数据的指令描述可能忽略了空间信息。标注新数据时可以有意识地增加“同场景、不同属性”的对比样本让模型更难走捷径。6.4 警惕“多模态能力”的虚假安全感作为工程开发者我们很容易被“多模态大模型”这个名词迷惑默认它具备很强的图像理解能力。但实际效果高度依赖具体任务、提示词和评测方式。任何结论都要用数据说话盲目的信任和盲目的否定都不可取。另外要提醒一点在涉及真实业务的视觉工具使用场景中模型的输出要经过严格的上下文校验。尤其是当工具调用涉及支付、订单、库存等关键操作时一定不能让模型“猜”参数。6.5 设计安全的工具调用兜底策略即使审计做完也不代表模型永远不会出错。建议在工程侧增加兜底机制参数校验工具调用前检查参数是否符合预期格式、取值范围、业务规则。二次确认对于关键操作返回结果前让用户确认信息。降级策略当模型对图片内容的置信度较低时主动请求用户补充文字描述而不是硬调用工具。这些工程手段可以在模型能力不足时保护业务不受影响也是负责任的 AI 应用应该具备的基本素养。7. 总结“模型会看图”这件事远比想象中复杂。通过因果审计的视角可以看到视觉工具使用能力中存在着不少“虚假的因果”——模型能够输出正确结果但并不依赖图像内容。这种能力一旦被高估轻则测评失真重则造成线上事故。本文围绕 Visual Tool-Use、Causal Audit、Thinking with Images 三个关键词梳理了视觉工具使用的背景、因果审计的原理、以及落地实施的方法与常见坑点。核心思想可以浓缩为一句话不要问“模型答得对不对”而要问“模型是不是因为正确的视觉原因才答对”。如果你正准备做多模态 Agent 的评测或者正在为模型“看似会看图但实际不会看图”而困惑建议从因果审计开始挑一个关键任务维度构造少量干预样本跑一遍你很可能会有新的发现。尤其是对于上线前的能力验收这套方法值得加入你的评估清单。如果这篇文章对你有帮助欢迎收藏备用。也欢迎在评论区聊聊你在多模态工具调用场景中遇到的“幻觉能力”案例一起交流排查经验。 视觉工具使用的幻觉：用因果审计评估多模态Agent真实能力
之前在做多模态 Agent 项目时我遇到一个很典型的现象模型明明在测试集上能把“看图 调用工具”的任务跑通一旦换到线上真实场景准确率就断崖式下跌。更让人困惑的是你很难说清楚模型到底是真正理解了图像内容还是仅仅根据上下文中的工具名称、参数格式、甚至一些和图像无关的统计规律“猜”对了答案。这种“会但没完全会”的状态在相关研究里被称为Visual Tool-Use 的幻觉问题。这篇文章我想围绕“视觉工具使用中的幻觉现象”展开重点介绍一种更严谨的评估思路——因果审计Causal Audit并拆解“Thinking with Images”这类多模态推理场景下模型能力为什么容易被高估。无论你是做算法评估、模型选型还是正在开发基于视觉大模型的 Agent 应用这篇文章都能帮你建立起一套更可靠的判断框架到底怎么评估模型是真会还是假会。文章包含核心概念讲解、因果审计的流程设计、实验思路、代码示例和工程建议内容偏方法论但又不止于理论。1. 背景Visual Tool-Use 是什么为什么值得关注先看一个最简单的场景。假设你做了一个 AI 助手它可以根据用户上传的户型图调用一个工具函数calculate_area(diagram_id)返回房间面积。这个过程中模型要完成两件事看图片理解户型图的房间布局。根据理解结果选择合适的工具并填入正确的参数。这就叫视觉工具使用Visual Tool-Use。它和普通的“看图说话”不同核心差异在于模型不只是输出文字描述而是要通过工具调用来完成一个实际动作。工具调用的参数、名称、格式是否准确直接决定任务成败。在传统视觉问答VQA任务里模型回答“沙发在茶几左边”答错了也就错了影响相对有限。但在工具使用场景里一个错误的参数可能引发后续一连串错误操作比如计算错误、下单错误、重复提交等。所以视觉工具使用能力直接决定了一个多模态 Agent 能否在真实业务中落地。1.1 视觉工具使用的典型链路为了便于理解我们可以把一次完整的视觉工具使用流程拆成几个阶段阶段说明常见模型/技术视觉感知输入图片提取视觉特征Vision Encoder如 ViT、CLIP 的视觉分支跨模态推理将图像信息与文本指令融合推理出需要执行的动作多模态大模型如 GPT-4V、Gemini、Qwen-VL 等工具选择从候选工具列表里选出最合适的一个模型自身的指令遵循能力参数生成根据图像内容生成工具调用参数模型的生成能力 结构化输出约束工具执行与反馈执行工具并返回结果模型根据结果进一步决策Agent 框架、Tool 执行引擎其中最容易出问题的就是“跨模态推理”和“参数生成”这两步。模型可能看懂了图但不知道选哪个工具也可能选对了工具但参数是从错误信息里推断出来的。1.2 所谓“幻觉能力”是什么“幻觉能力”是我自己归纳的一种说法指代以下现象模型在评估集上表现出很强的工具使用能力但这种能力并非来自对图像内容的真实理解而是来自数据集中的虚假关联、上下文捷径、或者模型内部先验知识的“巧合输出”。换句话说模型看起来会用视觉工具但实际上它的决策过程并不依赖图像本身。一旦把图像换成无关图片或者稍微改变图像中的关键信息模型的工具调用结果可能完全不变——因为它根本没有“看图”。这就是“The Illusion of Visual Tool-Use”的核心含义视觉工具使用的表象之下隐藏着对图像理解的缺失。2. 因果审计如何识别“真实能力”与“虚假能力”既然“看结果”不可靠那该怎么办我们需要一种更严格的评估方法。这就是因果审计Causal Audit的用武之地。2.1 因果审计的定义因果审计简单说就是通过人为干预模型输入中的关键变量观察输出是否发生“应有的”变化从而判断模型是否真正建立了输入与输出之间的因果联系。它的核心逻辑是如果模型真的理解图像内容那么改变图像中的关键信息模型的输出就应该跟着改变。如果模型输出对图像内容的变化“无动于衷”那就说明图像内容并不是模型决策的原因模型存在虚假能力。这就像审计一个员工的业绩——只看他签了多少单不够还要看他是不是真的有能力签单还是仅靠运气、关系、或者数据失真。2.2 因果审计与相关性评估的区别传统的模型评估本质上是在评估“相关性”输入图片 文本指令 → 模型输出工具调用 → 和标准答案比对 → 算准确率。这种评估方式只能说明在这些样本上模型的输出和期望输出是匹配的。至于这种匹配是“因果性”的还是“偶然性”的传统指标无法区分。因果审计则更进一步。它通过“对照实验”的方式去验证“图像输入”是否为“工具输出”的原因。用一张图来理解两者区别传统评估 图片A 指令 → 工具X正确 → 得出结论模型会看图 因果审计 图片A 指令 → 工具X正确 图片B篡改关键信息 指令 → 工具X依然正确 → 得出结论模型根本没看图输出和图像无关因果审计的价值就在于它能识别出传统评估里的“幸存者偏差”和“数据泄漏”。这在多模态模型评测中越来越重要。2.3 因果审计的三个核心步骤结合相关研究思路一个完整的因果审计通常包含三步构建干预选择图像中的关键视觉属性如物体颜色、位置、数量、空间关系等对这些属性进行系统性修改生成干预样本。目标是想清楚哪些视觉属性是工具调用应依赖的“因”。对比输出用原始图片和干预图片分别运行模型记录工具调用结果是否发生变化。因果判定如果干预后的输出与干预前一致说明模型没有建立“该视觉属性 → 工具调用”的因果链路存在幻觉能力的风险。这个流程和因果推断中的“干预Intervention”思想一致但在大模型时代它的实施重点变成了如何设计有效的干预策略以及如何解读模型输出的变化。3. Thinking with Images图像推理的复杂性在视觉工具使用场景中一个常见的误区是把“图像输入”当成“图像理解”。模型接入了图片并不等于模型依赖图片。这背后涉及多模态模型“Thinking with Images”用图像思考的复杂性。3.1 图像在推理链路中的角色当我们说“模型用图像思考”时至少包含以下三种可能角色含义举例图像作为信息源模型从图像中提取事实信息用于回答问题看图识别水果种类然后调用“下单”工具图像作为推理锚点图像触发模型调用已有先验知识看到一张机场照片模型调用“查询航班”工具图像作为无关干扰模型输出并不依赖图像内容无论图片是什么模型都调用同一个工具前两种是“合理使用图像”第三种则是幻觉能力的高发区。问题是我们很难从一次成功的输出中判断模型到底属于哪一种。同一个结果背后可能完全不同的推理路径。这就像两个人同时答对一道题一个人真正会做另一个蒙对了。如果只看分数无法区分。3.2 多模态推理中的“捷径学习”为什么模型会发展出这种“不依赖图像的捷径”原因通常有三个训练数据偏差训练数据中特定图像类型与特定工具调用之间存在高频共现。模型学到的是“这张图大致长这样 → 调用该工具”而不是“这类图像的某个具体特征 → 需要调用该工具”。文本先验主导多模态大模型本质上还是语言模型主导的架构。文本指令本身可能已经包含了足够多的线索让模型在不看图的情况下也能猜出答案。图像只是“装点门面”。评估集标注不严谨人工标注的评估集往往存在“可猜测性”——标注者本身就倾向于根据常见情况打分导致答案有规律可循模型可以利用规律。这些因素叠加就会导致一种结果模型在评估集上表现优秀但在真实世界的开放场景中一旦遇到“看图才能决定参数”的新情况能力迅速坍塌。3.3 为什么“开放场景”更脆弱在开放场景中图像与工具调用之间的关联是多样且可变的。比如用户上传的图片可能模糊、倾斜、光照异常。图片中的关键物体可能被遮挡或变形。图片内容与工具参数的关联可能依赖复杂的背景知识。如果模型只是学到了“训练集内图像 → 工具”的表层映射面对这些分布外的图像它就很容易失效。因果审计的价值正是要在模型上线前提前暴露这种脆弱性。4. 实战设计一个视觉工具使用的因果审计方案下面我们用一个简化示例展示如何实际落地一套因果审计实验。假设我们有一个多模态模型它需要根据用户上传的“商品图片 用户指令”调用一个get_price(product_info)工具返回商品价格。第一版评估结果准确率 85%看似不错。接下来我们用因果审计的方式重新评估模型的真实能力。4.1 定义审计目标和关键变量首先要明确工具调用的“因”应该是什么。在这个场景里模型要生成正确的工具参数商品名称、规格、数量等它必须从图片中识别出商品名称。所以关键视觉属性是商品名称比如红色保温杯、黑色无线鼠标商品外观特征比如带不带提手、是否是机械键盘审计问题修改图片中的商品对象模型是否相应改变“商品名称”参数4.2 构建干预样本我们准备两组图片对照组原始图片一张黑色无线鼠标的图片。干预组篡改图片将图片中的鼠标替换为键盘或者用文本提示词更明确地标注为“键盘”。这里的干预要遵循一个原则只改变要审计的视觉属性尽量保持图片其他属性不变。在实际操作中可以使用图像编辑工具、合成图片或者构造一个简单的图像插值实验。示例干预逻辑可以用伪代码表示def build_intervention_samples(original_image, visual_attribute, new_value): 根据原始图片生成干预样本。 这里只是示例思路实际需要接入图像编辑工具或调用图像生成模型。 intervened_image edit_image( imageoriginal_image, attributevisual_attribute, # 例如 object_category new_valuenew_value # 例如 keyboard ) return intervened_image4.3 运行相同指令记录输出对原始图片和干预图片分别输入完全相同的用户指令用户指令请根据商品图片调用 get_price 工具查询该商品的价格参数为商品名称。记录模型两次输出的工具调用参数。预期行为如果模型真的会看图干预后的商品名称应从“鼠标”变为“键盘”。如果模型存在幻觉能力两次输出可能完全相同仍然调用“鼠标”。4.4 对比结果并判定下面是两种可能的结果对比样本输入图片模型输出商品名称判定原始图片黑色鼠标鼠标正确干预图片替换为键盘黑色键盘鼠标异常干预图片替换为键盘黑色键盘键盘正常如果干预组输出仍是“鼠标”则说明模型输出并未真正依赖图像内容存在幻觉能力。4.5 扩展审计维度除了“替换物体”我们还可以从多个维度审计模型的视觉工具使用能力审计维度干预方式工具使用中应变化的参数物体类别鼠标 → 键盘商品名称物体数量一个苹果 → 三个苹果商品数量物体颜色红色杯子 → 蓝色杯子商品规格/款式空间位置左图与右图互换布局描述相关参数背景干扰干净背景 → 杂乱背景是否仍能识别主体每个维度都代表一种“视觉因果链”。模型只有能在多个维度上都“随图而变”才说明它建立了稳健的图像理解能力。5. 常见误区与排查思路在实施因果审计时我自己踩过几个坑也看到不少团队会犯类似错误。下面集中总结。5.1 干预样本构造不干净问题现象常见原因解决思路干预后模型输出变化但原因不明干预操作不仅改变了目标属性还改变了图片整体风格、亮度、对比度尽量使用可控的图像编辑工具或在干预前后做对比可视化确认只改了目标属性干预样本和真实场景差异过大用过于极端的图像拼接导致模型识别失败干预样本要贴近真实使用场景不要为“制造差异”而脱离实际图像中的文字信息泄漏图片中本身带有商品标签文字模型直接读文字审计时先检查图片中是否存在与答案直接相关的文本5.2 指令设计引入偏差问题现象常见原因解决思路模型输出正确但和图像无关指令中包含了答案线索审计时指令应只包含“任务说明”不包含“答案提示”指令过于复杂模型不理解把审计任务和推理过程混在一起审计时用最简单的指令聚焦单一工具调用提示词中注入工具名某些提示词模板会固定工具名审计工具选择时应让模型从多个候选中自由选择而不是直接给答案5.3 结果解读过度激进因果审计的结论不能只看一两次实验。模型输出具有随机性而且不同数据分布下的表现可能不同。建议每个干预维度至少测试 50 条以上样本。重复运行 2 到 3 次记录输出稳定性。对审计结果使用统计检验观察干预前后输出分布的差异是否显著。如果只是做了 5 张图就断言“模型没有视觉能力”结论可能不够稳。5.4 审计维度覆盖不全很多团队只审计“物体类别”一个维度其他维度完全不管。但真实业务里模型可能物体识别没问题但对“数量”和“空间关系”非常迟钝。审计之前先梳理一遍在这个工具使用任务中最终要生成的每个参数分别依赖图像中的哪些视觉信息建议做一个审计维度清单逐项排查不要只盯一个维度。6. 最佳实践构建可信的视觉工具评估方案经过因果审计的实践我觉得有几条经验特别值得分享。6.1 评估指标要分层不要只用“工具调用准确率”一个指标评估模型。建议至少分成三层评估层面指标含义工具选择工具命中率模型是否选对了工具参数生成参数准确率EM/F1模型生成的参数是否准确因果一致性视觉干预敏感度模型输出是否随关键视觉属性变化只有当“工具命中率”“参数准确率”和“因果敏感度”同时达标时才能谨慎地认为模型具备视觉工具使用能力。6.2 将因果审计纳入上线流程在模型上线前推荐按下面的流程做评估用常规评测集跑通基线指标。基于任务定义梳理工具参数与视觉属性的对应关系。构造干预样本做因果审计。审计不通过的维度针对性补充训练数据或进行提示词优化。审计通过后再进入灰度测试。这样可以避免一个很尴尬的局面模型在测试集上分数很高上线后被用户连续反馈“根本不会看图片”。6.3 利用审计结果指导数据标注因果审计不仅能用来评估模型还能反哺数据标注如果审计发现模型在“物体数量”维度上不敏感说明训练数据中“同图不同数量”的样本过少。如果审计发现模型在“空间关系”维度上不敏感说明训练数据的指令描述可能忽略了空间信息。标注新数据时可以有意识地增加“同场景、不同属性”的对比样本让模型更难走捷径。6.4 警惕“多模态能力”的虚假安全感作为工程开发者我们很容易被“多模态大模型”这个名词迷惑默认它具备很强的图像理解能力。但实际效果高度依赖具体任务、提示词和评测方式。任何结论都要用数据说话盲目的信任和盲目的否定都不可取。另外要提醒一点在涉及真实业务的视觉工具使用场景中模型的输出要经过严格的上下文校验。尤其是当工具调用涉及支付、订单、库存等关键操作时一定不能让模型“猜”参数。6.5 设计安全的工具调用兜底策略即使审计做完也不代表模型永远不会出错。建议在工程侧增加兜底机制参数校验工具调用前检查参数是否符合预期格式、取值范围、业务规则。二次确认对于关键操作返回结果前让用户确认信息。降级策略当模型对图片内容的置信度较低时主动请求用户补充文字描述而不是硬调用工具。这些工程手段可以在模型能力不足时保护业务不受影响也是负责任的 AI 应用应该具备的基本素养。7. 总结“模型会看图”这件事远比想象中复杂。通过因果审计的视角可以看到视觉工具使用能力中存在着不少“虚假的因果”——模型能够输出正确结果但并不依赖图像内容。这种能力一旦被高估轻则测评失真重则造成线上事故。本文围绕 Visual Tool-Use、Causal Audit、Thinking with Images 三个关键词梳理了视觉工具使用的背景、因果审计的原理、以及落地实施的方法与常见坑点。核心思想可以浓缩为一句话不要问“模型答得对不对”而要问“模型是不是因为正确的视觉原因才答对”。如果你正准备做多模态 Agent 的评测或者正在为模型“看似会看图但实际不会看图”而困惑建议从因果审计开始挑一个关键任务维度构造少量干预样本跑一遍你很可能会有新的发现。尤其是对于上线前的能力验收这套方法值得加入你的评估清单。如果这篇文章对你有帮助欢迎收藏备用。也欢迎在评论区聊聊你在多模态工具调用场景中遇到的“幻觉能力”案例一起交流排查经验。