最近有个研究方向挺有意思用拼图去测多模态大模型的空间推理能力并把它做成一个全新基准。结果很快指向同一个结论当前 VLM 能识别画面里有什么却经常说不清一块碎片应该放在哪里。听起来像“硬伤”其实更准确的描述是它们能很好地完成语义理解但空间推理仍是明显的短板。在具体展开之前先说我看到这个测试时的第一反应——这不只是多了一个刁钻的 benchmark而是用一种很朴素的方式问了一个很多模型评测没有问清楚的问题当模型说“我理解这张图”时它理解的是画面里的对象还是画面本身的结构拼图的残酷之处在于它能轻易区分这两种理解。你可以知道图里有雪山、有湖、有树但你未必知道湖应该在山的下方、树在湖的左边。这种“看懂了内容却摆不对位置”的现象在真实应用里远比我们想象中常见。下面这篇文章我想从四个角度聊聊拼图为什么能精准击中 VLM 的软肋这类能力短板到底卡在模型的哪一层如果要在项目里复现这类评测具体该怎么做以及知道这些短板后我们应该怎样正确使用多模态大模型。文章里不会给出某一个模型的“官方分数”因为依赖版本和测试实现变化太快。它更像是一条实践判断路径。1. 为什么偏偏是拼图它击中了 VLM 的什么软肋1.1 常规视觉问答很容易让模型“蒙混过关”多模态大模型最常见的评测方式是视觉问答。给定一张图问“图里有没有猫”“车是什么颜色”“描述这个场景”。这类问题当然有价值但它很容易被模型的语言先验和训练数据覆盖。比如一张客厅图片模型回答“沙发上有一个抱枕”可能并不困难因为它已经见过太多次类似布局即使不看图它也能用常识补全。就算问题改成“抱枕是不是在沙发左边”模型也未必真正在看图中的左右它常常根据物体的惯例位置去猜。而在真实图片里“左边”和“右边”往往有足够多语义暗示使得模型靠语言也能答对一整批问题。常规视觉推理数据集的得分看起来很高恰恰是因为很多问题没有把“空间证据”逼到墙角。问“杯子和书哪个离笔记本电脑更近”比问“猫在图像坐标里的 x 值是多少”要宽松得多。前者用模糊的比较关系就能应付后者必须精确到位置。于是一个 VLM 可以在 50 道看图题里答对 48 道却仍然不具备真正意义上的空间能力。这不是说所有 VQA 都无效而是提醒我们当测试题目允许模型通过语义先验绕过空间计算时分数很容易高估模型能力。1.2 拼图同时要求“看局部”和“想整体”拼图类任务为什么能精准刺穿这种高估因为它不是一个“认识对象”的任务而是一个“重建空间关系”的任务。把一张图片切成 3×3再打乱顺序。此时模型拿到的是若干个局部图块需要还原出它们原本的相对位置。模型至少需要完成几步识别每个图块中承载了语义信息的部分比如半张脸、半个车轮、一段边缘。找到图块之间的连续性包括颜色、纹理、边缘和语义线索。把这些局部关系映射到一个二维画布上的坐标。最后基于整体构图判断最优排列而不是只靠某一块单独下结论。这套流程里只有第一步贴近传统视觉识别后面的每一步都在做空间关联。更关键的是拼图不会给你太多“语言先验”的便宜可占。一个单独的拼图块往往语义不完整所以模型不能光凭常识说“它应该在左上角”。它必须真正比较其它图块的边缘和位置才能给出可靠答案。这正好把对象识别和空间推理的区别暴露出来了。1.3 模型缺少的不是“看图”而是空间关系建模如果我们把 VLM 的能力拆开来看其实可以分成两条线一条是对象感知一条是空间关系建模。对象感知关心“图里有什么”空间关系建模关心“这些对象在哪里、以什么相对位置排列、相互之间如何遮挡和连接”。传统视觉系统里这两条线往往分开处理。物体检测器先给出边界框再接一个关系网络去判断“左边/右边/上方/下方”。但多模态大模型的主流范式是通过视觉编码器把整张图转成一串视觉 token再交给语言模型。这意味着对象类别识别和关系计算都在一个隐空间里完成。对隐空间来说识别“这是一个轮子”比精确估计“轮子中心点像素在坐标(410, 230)”要容易得多。拼图测试恰好击中这个不对称性。拼图要求模型对图块之间的坐标关系做显式判断不是隐式猜个大概就行了。于是我们会看到一种很有代表性的失败模式模型知道某个图块里有“一只眼睛”也知道另一块里有“一只耳朵”但无法稳定地说出眼睛应该在耳朵的左上还是右上。它能“看懂零件”却组装不了整体。这正是当前许多多模态大模型空间推理能力的真实写照。2. 从拼图测试反推模型空间推理能力卡在哪一层拼图测试的成绩不理想不能简单归咎于“模型不够聪明”。更像是一个处理链路上有多处瓶颈被同时触发的结果。按我的经验遇到空间推理失败时可以从四个层面去排查输入层、编码层、推理层和输出层。2.1 输入层切片和缩放可能已经毁掉空间线索无论人类还是模型想完成拼图前提是能看到完整的边缘信息和局部细节。但很多视觉模型在输入阶段会做固定尺寸缩放。拼图块被切成小方块后如果又被压缩到 224×224 或 336×336 这类固定分辨率原始细节很容易丢失尤其是边界处只有几个像素宽的纹理差异。另一个隐蔽问题是拼图块被独立输入还是拼成一张大图输入。如果模型接口只接受单张图片你需要把多个图块合成一个布局这个布局本身又会引入边距、网格线、位置偏移等额外视觉信息。模型到底是根据原图图块推理还是根据输入位置的标签猜答案就很难分清了。评测若没有控制好输入层后续分析都不可靠。2.2 编码层视觉 token 之间的空间关系还不够强主流 VLM 会把图像切成 patch每个 patch 变成一个 token再和文本 token 一起交给 Transformer。视觉 patch 之间的相对位置确实会在模型内部被编码但这种位置编码是否足以支持“左边缘和右边缘是否连续”这种像素级判断目前看是存疑的。尤其是在深层的交叉注意力中模型可能把更多注意力放在“语义相近的 token”上看到天空的 patch就会去关注其它天空 patch看到轮廓清晰的拼块边缘又会关注对应的语义区域。这种注意力分布擅长组合语义纹理却不一定擅长比较精确坐标。结果就是模型像是一个能认出“这是山”和“这是云”的整体语义系统却不太像同步拿着尺子量每个 patch 坐标的几何引擎。2.3 推理层语言先验可能直接绕过了视觉证据另一个常见问题是模型会走捷径。当拼图块里出现“人脸”模型可能仅仅根据常见的人脸结构断定“眼睛在上面嘴在下面”而不仔细对齐图像里实际的边缘位置。这种依赖世界知识的推理不全是坏事但它很容易掩盖真实空间能力。在做拼图评测时需要特别警惕这种“语义作弊”。如果 9 个拼图块语义都很明确模型也许只需认识物体、套用常识布局就能答对而不是真正比较边缘。更干净的评测应当加入语义模糊或重复纹理的图片或者对图块加入旋转逼着模型只能用几何信息求解。否则测出来的可能不是空间推理而是“物体结构常识”。2.4 输出层没有稳定的坐标协议就算模型内部有空间信息最终也必须通过文本输出坐标或网格序号。这个问题比看起来更严重。语言模型输出是自回归式生成它没有专门的回归头来保证坐标数值连续且精确。假设接口返回的是“左上角”它能比较稳定但如果要求输出(row2, col3)模型需要生成“2”和“3”两个 token而 token 之间的数值关系并没有强约束。更常见的情况是模型在回答里夹杂大量描述你要用纯文本解析才能拿到最终结果。解析一旦不稳定测试成绩就会明显下降。所以拼图评测里的“输出格式”设计往往和模型本身一样影响结果。环节风险排查方向输入处理分辨率低、拼块合并引入噪声使用高分辨率保留原始拼块边缘避免额外边框视觉编码patch 化后局部关系弱化测试不同 patch 尺寸观察注意力是否忽略局部边缘语言推理走语言先验捷径加入旋转、高纹理图像减少语义提示文本输出坐标 token 精度不足限制输出为结构化 JSON多次采样取多数这个表格可以当作你自己做拼图评测时的检查清单。别一看到“模型答错”就下结论先逐层确认问题出在哪个环节。3. 一个更朴素的评测思路先跑通一张拼图再谈能力如果不想只是隔岸观火完全可以自己搭一个最小版拼图评测。它不需要昂贵的数据集也不需要复杂训练。下面这套流程我用过很多次核心是“先把单张样例跑通再谈规模化”。3.1 评测任务可以怎么设计建议从 3×3 的九宫格开始难度适中又可以压缩输出空间。基本步骤是准备一组图片内容不要全是常见物体最好加入纹理照片、自然风景、室内场景等空间关系依赖较强的图。把每张图裁成 3×3共 9 张子图。固定编号顺序比如从左到右、从上到下每个子图有唯一 id。打乱 id 顺序后将子图随机放在一个九宫格画布上并保留网格边框让模型能看出每个子图所在的位置。提问时要求模型输出每个 id 对应到画布上的哪个网格例如id1 - (0,0)。这里的关键是把“哪个子图属于哪个位置”的映射交给模型而不是把原图贴好再问“哪块不对”。后一种问法把问题转化为“比较两张大图”难度会降低很多。3.2 最小评估流程示例下面是一个示意性的 Python 结构用来生成问题图。它只负责数据准备部分模型调用部分需要按你实际使用的多模态模型接口来替换。from PIL import Image import random def split_into_tiles(image_path, grid3): img Image.open(image_path).convert(RGB) w, h img.size tile_w, tile_h w // grid, h // grid tiles [] for row in range(grid): for col in range(grid): box (col * tile_w, row * tile_h, (col 1) * tile_w, (row 1) * tile_h) tiles.append((row, col, img.crop(box))) return tiles def build_question_image(tiles, grid3): # tiles: list of (row, col, PIL.Image) # 这里按打乱后的顺序放进画布生成一张可供模型看的问题图 tile_w, tile_h tiles[0][2].size margin 10 side grid * tile_w (grid 1) * margin canvas Image.new(RGB, (side, side), black) # 示意仅表示流程实际落地需要仔细计算当前网格布局 shuffled tiles[:] random.shuffle(shuffled) labels {} for idx, (orig_row, orig_col, tile) in enumerate(shuffled, start1): row (idx - 1) // grid col (idx - 1) % grid x margin col * (tile_w margin) y margin row * (tile_h margin) canvas.paste(tile, (x, y)) labels[idx] (orig_row, orig_col) return canvas, labels注意这段代码只是稳定复现“生成拼图问题图”的骨架真正落地时还需要把输出格式、模型调用和结果解析都写完。3.3 怎么判分既要位置准确也要结构合理判分标准建议分成三个层次。完全正确率9 个图块全部归位才算正确。单块归位率允许部分正确统计单个图块位置是否恢复。这个指标能反映模型对局部线索的敏感度。相对顺序一致率不要求绝对坐标完全一致只检查两两图块的相对关系是否正确比如 A 是否在 B 的左上。只报告完全正确率可能太苛刻因为一次坐标偏移会导致整张图错误单看单块率又会忽略全局一致性问题。多维度判断能更接近模型真实能力。3.4 评测时的“作弊”风险做评测最容易被忽视的一点是模型可能不是在“拼图”而是在做文本编号匹配。如果你为每个子图手动画了明显的标签或角标模型很可能会去读角标而不是比较图像内容。为了让测试有效应该尽量避免在子图内混入编号 OCR 信息。如果模型输入还包括每个子图的文件名或位置说明那评测就变成了语言推理题。另一个风险是随机性。大模型生成不是确定性的同样的拼图状态不同采样温度会得到不同结果。做严谨测试时建议固定温度或多次采样取多数结果。否则很难分辨是能力波动还是随机失误。4. 如果模型测出了硬伤我们该怎么用 VLM拼图测试暴露短板并不是为了劝退所有多模态应用。更合理的心态是知道模型哪里不够强就不要把关键环节建立在它最不稳定的能力上。4.1 不要指望纯 VLM 完成像素级空间定位真实项目里那种“模型看一张截图直接算出元素坐标”的用法风险很高。例如用户上传一张货架照片问“第二层右数第三瓶是什么”纯 VLM 可能答出不存在的商品名。如果你把整个流程押在模型的空间推理上错误很难提前感知。更稳妥的做法是把任务拆开。先用传统视觉方案拿到候选框、OCR 文本、分层结构再让 VLM 在这个结构化结果上做语义问答。也就是说模型不再需要从原始像素猜测精确位置只需要在给定坐标集合里选择相关性最高的对象。后者的成功率会远超前者。4.2 工程上更稳的组合检测器 规则 LLM我一般会建议采用一种混合流程用目标检测模型找出图里的对象与坐标框。用 OCR 模块输出文字内容及其坐标。根据坐标计算出对象之间的“上下左右”关系。把这些结构化数据拼成一段文本交给语言模型做自然语言问答。这个流程不一定比“单模型直接看图片”更酷但它把空间计算交给了专门模块把语义理解交给了语言模型每一层都做自己擅长的事。这类架构在截图理解、文档解析、自动化操作等场景里通常会比端到端纯 VLM 更稳定。4.3 模型侧改进方向让空间能力成为显式一环从长远看多模态大模型的空间推理一定会改进但不会只靠堆数据。可能的路线包括引入更有利于坐标感知的图像编码方式在训练目标里加入几何关系预测而不是只做文本 token 的下一步预测或者增加一个类似“空间头”的输出分支让模型在生成坐标时不受词汇表失真的影响。这些方向还在快速演进中。对普通开发者来说与其等模型进化不如先把应用任务拆好。模型能力没到的地方用工程补足。5. 这轮反思背后的适用边界5.1 拼图只测一种空间推理拼图测试能测出“二维平面内局部与整体的关系”但空间推理远不止这一种。它没有覆盖真实世界里的三维深度、自遮挡、视角变化、移动规划也没有覆盖“从这个房间走到另一个房间”的导航式空间理解。一个模型在拼图上拿高分不代表它在机器人操作、自动驾驶、三维重建中同样可靠。反过来也一样。一个模型拼图分数不高不代表它在所有视觉任务上都不可用。空间推理是多种能力的合集。用拼图得到的结果应该理解为“窗口”而不是“定义”。5.2 分数低不等于模型整体没用拼图更像是一个压力测试。语言模型在自然语言对话里表现优秀多模态版本在图片摘要里表现可靠但这些都不能保证它在拼图这种“低语义、强几何”任务里同样出色。反过来说拼图成绩不理想也不影响它帮你负责文本摘要、图像打标、客服意图理解等工作。真正值得反思的不是“这个模型蠢”而是“我们是不是用错了模型”。如果你让一位资深设计师去当测绘员他可能也会出错但这不代表设计师没有专业能力。5.3 对普通开发者和爱好者的提醒如果这篇文章对你只有一个提醒我希望是做多模态应用时请先拆解任务里的空间精度要求。如果只是做图片情绪识别、内容摘要纯 VLM 足够。如果任务涉及像素坐标、截图回归、导航标记、版面还原一定要谨慎。如果模型可以直接提供一个看起来流畅却无法验证的答案那它很可能在空间推理上“一本正经地胡说”。一个小技巧是每次拿到新的多模态大模型先不要急着用复杂业务测试。花十分钟弄几张切成九宫格的图片问一遍比一百句产品宣传都更能帮你理解模型的能力边界。拼图测试真正让我在意的不是某张榜单上谁高谁低而是它提供了一条用低计算成本检验模型底层能力的路径。它像一面镜子平时我们都在夸模型能读懂图像里的故事拼图却提醒我们读懂故事和理解空间结构是两回事。以后如果你的项目里模型在一个看似“只用看图就能解决”的空间任务上翻车不妨回到这个镜子前想想——它缺的可能不是更多提示词而是更基础的空间关系建模能力。先用好传统视觉模块再在模型真正擅长的语义层大胆发挥这才是当前阶段多模态应用更务实的打开方式。