用拼图评测VLM空间推理:方法、代码与实测分析

用拼图评测VLM空间推理:方法、代码与实测分析 先问一个很实际的问题如果只给你看一张被打乱顺序的 2×2 拼图块你能判断出哪一块原本应该在左上角吗很多人能靠边缘连续性、物体结构和场景语义轻松完成这个任务。但当我把同样的问题抛给多模态大模型VLM时事情就变得非常微妙。在过去很长一段时间里VLM 的评测重点都放在“看图说话”“图文匹配”“视觉问答”这些偏语义理解的任务上。模型只要能描述出画面主体、识别出物体属性就已经算表现不错。可是一旦把任务从“理解画面内容”升级为“理解画面结构”很多主流多模态大模型的短板就会暴露出来。而拼图恰好是一种对空间推理要求极其苛刻的任务它能以很低的标注成本把模型的空间感知能力拆开来看。这篇内容就来讨论这类“拼图式”空间推理评测策略。我不打算只停留在概念层面而是要把它做成一套可以复现的小型评测流程理解空间推理与视觉语言模型的关系、设计一个拼图式评测集、调用真实 VLM 接口、编写自动化脚本计算成绩最后再分析模型的表现缺陷和可用的改进方向。如果你平时在开发多模态应用或者正在纠结怎么给模型做更细粒度的能力评测这篇文章应该能给你一些可落地的思路。1. 为什么用拼图测试多模态大模型空间推理1.1 多模态大模型不只是“能看懂图片”所谓多模态大模型行业内通常也叫 VLMVision-Language Model视觉语言模型。这类模型最早的核心能力是把图像输入和文本输入统一到一个模型中处理输入可以是图片、文字也可两者同时输入输出则是自然语言回答。GPT-4V、Gemini 系列、Claude 系列以及开源社区里的 LLaVA、Qwen-VL、InternVL 等都属于我们常说的视觉语言模型范畴。不过很多人对 VLM 的能力认知可能还停留在“它能看图回答”这个层面。实际开发中你会发现VLM 能做的事情远远超过简单问答比如文档信息抽取、截图理解、GUI 自动化、视频片段分析、机器人和自动驾驶场景理解等等。这些复杂任务对模型提出了一个共同要求不仅要知道图像里有什么还要知道物体之间在空间上是什么关系。举个最容易理解的例子一张桌面上有三本书、一台显示器和一杯咖啡。普通问答可能只需要识别出“显示器在桌子上”。但如果你想做一个“根据桌面照片自动整理物品”的机器人就必须知道书在显示器的左边还是右边、咖啡杯靠近书还是远离书、哪些物体在一个水平面上。这种对位置、方向、大小比例、遮挡关系、排列顺序的综合推理就是我这里说的空间推理。1.2 拼图任务为什么能测出空间推理能力讲空间推理方法其实很多常见的有目标检测坐标回归、视觉指代理解、最小包围盒判断、三维点云识别等。但拼图任务有个独特优势它天然地复用了“图块在二维平面上的组合关系”。把一张图切成多块并打乱顺序之后测试对象需要做几件事观察每个图块内部的内容特征抽象出图块之间的轮廓边缘和纹理连续性在图块之间建立空间位置假设利用全局场景信息对局部位置进行修正。这个问题设置实际上构成了一种“高不成低不就”的测试。对纯视觉系统来说边缘和轮廓不是问题对语言模型来说文本语义又成了主要依赖。而 VLM 恰恰卡在两者之间它既要看图又要用文本 token 生成最终结果因此当模型拿不稳空间关系时它很可能会“靠猜”或“靠常识补”。比如说一张风景图可以切成天空区域和地面区域。如果 VLM 能识别出一块是天空、另一块是草地的纹理理论上它应该能知道“天空应该在草地上面”。但实测中我们经常发现模型能准确描述两块各自的内容却无法把它们安放到正确的空间位置。这说明它缺少的是抽象的空间拼接能力而不只是简单的物体分类能力。1.3 这类评测基准要考察什么能力所以为了让评测结果能真实反映空间推理水平设计这类“拼图式”基准时通常需要考察以下几个维度第一局部识别能力。模型首先得描述出每一块的内容这时拼图块边缘可能是不完整的模型需要克服“信息缺失”。第二相对位置判断能力。两块之间是上下关系、左右关系还是对角线关系这类判断哪怕没有参考背景也要尽可能准确。第三全图重构能力。模型是否可以综合考虑多个图块的视觉线索还原出一个完整的场景布局。第四抗语言先验干扰能力。有些任务如果图上信息本身不够模型可能依赖“天空在上、草地在下”的文本先验来回答这种先验有时能帮助判断有时会形成干扰。评测中要把“猜对”和“真正看明白”区分开。于是用拼图这种任务做基准本质上是把模糊的“空间推理”拆成几个可以量化的问题然后用统一的测试模板反复去测试。2. 拼图式空间推理基准的设计思路2.1 从“让模型选答案”到“让模型摆位置”在设计评测集时一个常见的误区是喜欢让模型做选择题。比如给模型四个选项“A 块在左上角B 块在右下角……”然后要求选择正确描述。这种形式虽然方便判分却存在明显的文本先验问题模型可能没看着图片也能根据选项里常见的语法规律蒙对一部分。更合理的做法是让模型直接输出每个图块的坐标位置。以下是一个简单但有效的问题模板把原图切成 N×N 的方块给每个方块一个独立编号按随机顺序把方块放到新的画布上要求模型根据视觉内容判断“编号 X 的原位置在整幅图的哪个位置”。模型的输出被强制为结构化数据比如 JSON 数组见例[ {id: B, position: 左上}, {id: A, position: 右上} ]这样就把“理解”和“生成”牢牢绑定在一起。如果模型只是局部识别做得好但空间排列一团乱我们可以很快从结果中定位问题。2.2 评测难度分级与任务模块为了不把拼图评测做成单一的“还原正方形”小游戏一套完整的基准可以按难度划分评测模块常见有四种典型任务评测模块任务描述考察重点基础位置还原将 2×2/3×3 图块按随机顺序摆放模型输出每块原始坐标基本空间方位理解旋转方向判断将某个图块旋转 90°/180°/270°模型判断旋转角度方向感知与几何变换相对关系问答给出两个图块编号追问“哪个在上方”图块间的相对空间关系完整拼图排序输出所有图块按“从左到右、从上到下”的原始编号全局综合排序能力上面这些模块并不依赖同一套数据分布。评测时建议最好同时使用自然照片、简单几何图形、日常文档截图、室内场景图等不同类型的图像。原因在于几何图形可以测试纯粹的边缘匹配能力自然照片测试的是语义引导的空间推理而文档图片则能测试出模型是否会被文本噪声干扰。2.3 打分方式要避免“部分对就全给分”判断拼图结果是否正确不能只靠一个总的字符串匹配。假设正确答案是A B / C D模型输出成B A / C D它只错了一个左右顺序但如果按照“整条结果相等才得 1 分”的规则最终得分是 0。对空间推理模型来说这种罚分方式其实过于严格会掩盖模型“方向感正确但局部左右翻转”的真实情况。所以更精细的评判方法至少可以分为三个指标单块位置准确率每个图块是否落到正确位置正确比例是多少行顺序准确率同一行内图块的左右顺序是否正确块间邻接准确率每个图块四周的邻块是否匹配正确。邻接准确率对拼图任务尤其重要。因为某个模型可能无法说出绝对坐标但如果它判断出“A 的右边是 B、B 的下边是 C”它其实已经掌握了大量空间信息。只统计绝对坐标会高估模型的失败程度。这种多维度打分方式也更接近人类拼图时的思考逻辑先找边再拼内部最后调整整幅布局。3. 搭建 VLM 空间推理评测环境把基准设计讨论清楚后我们就进入实操环节。下面我会用 Python 脚本演示一个小型拼图评测闭环整套流程分成三个步骤先用 Python 的 Pillow 库切分图片并生成拼图测试画布再调用多模态大模型的接口读取画布最后把模型输出与正确答案做结构化比较。3.1 项目结构和基础依赖先创建一个实验目录并保持文件结构如下puzzle_bench/ ├── make_puzzle.py ├── run_eval.py ├── sample.jpg └── tasks/ ├── task_001.png └── task_001.json建议使用 Python 3.10 以上版本并安装以下依赖pip install pillow openai需要说明的是openai库只负责 API 调用。如果你使用的是其他厂商的兼容接口通常也可以通过修改base_url指向对应的服务地址。另外像 Qwen-VL 这类开源模型也可以替换成本地推理服务地址只要能提供兼容 OpenAI 格式的 HTTP 端点即可。还需要准备一张尺寸较大的原始图片用于后续拆分。这里以常见的sample.jpg为例。3.2 制作拼图测试任务的脚本下面先写一个负责生成任务的脚本。它会把一张 512×512 的图片切成 2×2 的图块打乱顺序并把随机顺序后的结果画在一个新画布上同时给每个图块标注一个字母编号。这样模型看到的是一张包含四个图块、但原始位置被打乱的图片。# 文件路径puzzle_bench/make_puzzle.py import os import json import random from PIL import Image, ImageDraw, ImageFont SRC_IMAGE sample.jpg OUTPUT_DIR tasks GRID 2 # 切分为 2×2 os.makedirs(OUTPUT_DIR, exist_okTrue) # 1. 读取并统一尺寸 image Image.open(SRC_IMAGE).convert(RGB) image image.resize((512, 512)) grid_size GRID patch_size 512 // grid_size # 2. 切块并按原始坐标记录编号 blocks [] for row in range(grid_size): for col in range(grid_size): box (col * patch_size, row * patch_size, (col 1) * patch_size, (row 1) * patch_size) block image.crop(box) block_id chr(ord(A) len(blocks)) # A, B, C, D blocks.append({ id: block_id, block: block, original_pos: (row, col) }) # 3. 将图块顺序打乱 random.shuffle(blocks) # 4. 绘制拼图测试画布 canvas_size (grid_size * patch_size, grid_size * patch_size) canvas Image.new(RGB, canvas_size, white) draw ImageDraw.Draw(canvas) try: font ImageFont.truetype(arial.ttf, 40) except Exception: font ImageFont.load_default() for idx, item in enumerate(blocks): row idx // grid_size col idx % grid_size x0 col * patch_size y0 row * patch_size canvas.paste(item[block], (x0, y0)) draw.text((x0 8, y0 8), item[id], fill(255, 0, 0), fontfont) # 5. 保存测试图和标准答案 task_path os.path.join(OUTPUT_DIR, task_001.png) canvas.save(task_path) answer {} for item in blocks: answer[item[id]] list(item[original_pos]) with open(os.path.join(OUTPUT_DIR, task_001.json), w, encodingutf-8) as f: json.dump(answer, f, ensure_asciiFalse, indent2) print(测试图片已生成, task_path) print(标准答案, answer)这里有一个容易忽略的细节输出答案时我记录的不是图块原本排在第几个而是它应该落在二维网格中的(row, col)坐标。原因在于大模型输出 “A 是左上B 是右下” 这种自然语言后我们很难直接比对而坐标形式很容易转换成位置索引。当然实际评测时可以给每个位置再编一个位置 ID例如0:左上, 1:右上, 2:左下, 3:右下。上面的代码有意保留了原始坐标便于后续调试。3.3 调起 VLM 评测函数图集生成后就可以将图交给多模态大模型来判断。这里推荐使用 JSON 输出模式而不是让模型自由发挥。JSON 模式会极大降低解析复杂度也更适合自动化评测。# 文件路径puzzle_bench/run_eval.py import os import json import base64 from openai import OpenAI client OpenAI(api_keyos.environ.get(OPENAI_API_KEY)) def encode_image_to_base64(image_path: str) - str: with open(image_path, rb) as f: return base64.b64encode(f.read()).decode(utf-8) def ask_vlm_for_puzzle(image_path: str) - str: image_base64 encode_image_to_base64(image_path) response client.chat.completions.create( modelgpt-4o, # 请根据你的实际可用模型调整 response_format{type: json_object}, messages[ { role: system, content: 你是空间推理评测助手。你只能输出 JSON。 }, { role: user, content: [ { type: text, text: ( 图片中有 4 个呈 2×2 网格排列的图块 它们本应来自同一张原图。 网格坐标定义左上为(0,0)右上为(0,1) 左下为(1,0)右下为(1,1)。 请根据图块的边缘连续性、内容位置和场景语义 判断每个字母对应的原图坐标。 输出 JSON格式为 {A: [row, col], B: [row, col], C: [row, col], D: [row, col]} ) }, { type: image_url, image_url: { url: fdata:image/png;base64,{image_base64} } } ] } ] ) return response.choices[0].message.content if __name__ __main__: result_text ask_vlm_for_puzzle(tasks/task_001.png) print(模型原始输出, result_text)这里要注意几点调chat.completions.create时当前常用的openaiPython SDK 版本是 1.x。如果你项目里还在用 0.x 老版本接口写法会有所不同需要按版本调整。我上面代码中的写法适用于openai1.0.0。另外把图片转成 base64 并用data:image/png;base64,拼接适用于大多数支持图像输入的在线接口。如果图像太大接口容易超时报错所以生成拼图任务时会把图片统一压到 512×512这也是为了减少传输延迟。3.4 解析结果并计算得分有了模型输出接下来就是解析和判分。下面代码可以读入标准答案并计算“单块位置准确率”。# 文件路径puzzle_bench/run_eval.py追加部分 def parse_model_result(text: str) - dict: try: return json.loads(text) except json.JSONDecodeError: # 某些模型仍可能输出 markdown 代码块简单清理 start text.find({) end text.rfind(}) 1 if start ! -1 and end start: return json.loads(text[start:end]) raise ValueError(模型输出无法解析为 JSON) def eval_single_task(model_output: str, answer: dict) - dict: pred parse_model_result(model_output) total len(answer) correct 0 details {} for block_id, right_pos in answer.items(): pred_pos pred.get(block_id) is_ok list(pred_pos) list(right_pos) if pred_pos else False details[block_id] { predict: pred_pos, answer: right_pos, correct: is_ok } if is_ok: correct 1 return { accuracy: round(correct / total, 4), correct_num: correct, total: total, details: details } if __name__ __main__: with open(tasks/task_001.json, r, encodingutf-8) as f: ans json.load(f) result_text ask_vlm_for_puzzle(tasks/task_001.png) report eval_single_task(result_text, ans) print(评测结果, json.dumps(report, ensure_asciiFalse, indent2))运行流程结束后你就能看到类似下面的输出{ accuracy: 0.5, correct_num: 2, total: 4, details: { A: { predict: [0, 1], answer: [0, 1], correct: true }, B: { predict: [0, 0], answer: [0, 0], correct: true }, C: { predict: [1, 0], answer: [1, 1], correct: false }, D: { predict: [1, 1], answer: [1, 0], correct: false } } }如果最终拿到 50% 的准确率不要先急着给模型下结论。可以把上面四块位置拿出来看如果是 C 和 D 这两个左下、右下位置发生了互换那就说明模型对行顺序的理解是基本正确的只是列级别相邻关系判错了。如果错得非常随机连同一行的相对左右关系都不稳定那才是更需要警惕的缺陷。4. 实测场景主流 VLM 在拼图评测中的“硬伤”4.1 模型会犯哪些典型错误我并不是在这里预测某个模型表现一定差但如果你用上面的脚本去测一些主流多模态大模型通常能稳定观察到三类错误。第一类是“只认内容不认位置”。模型能准确识别 A 是天空、B 是草地但它给出的坐标却可能是“草丛在右上角”。这说明模型对图像内容的理解没有和位置预测关联起来。第二类是“按语言习惯猜位置”。很多自然图片天生带有上下语义如天空在上、海洋在下、人脸在图片上方如果测试图大量使用这种图片模型会利用常识猜对不少但一旦你把图块旋转或者换成抽象几何图形准确率立刻下降。第三类是“旋转和镜像混淆”。模型经常把左右相邻关系搞反尤其是当一个图块内的纹理没有明显方向时。这些现象综合起来就构成了所谓 VLM 空间推理硬伤的核心模型对视觉 token 的利用更多停留在“统计相关”层面而不是真正建模了像素之间的空间排列。4.2 为什么空间布局会成为 VLM 的明显短板要理解这个问题可以从模型架构角度去分析。目前的视觉语言模型通常由视觉编码器、连接模块和语言模型主体组成。视觉编码器把图片切成若干固定大小的 patch把每个 patch 映射成一个视觉特征向量。这些特征向量随后被拼成一串序列和文本 token 一起输入语言模型。问题就出在这个序列化过程里。图片本身是二维拓扑结构但进入语言模型后所有 patch 都变成了一个线性序列。虽然模型理论上可以从注意权重中重新学习二维关系但它并没有一种天然的“看到整体画布”的归纳偏置。同时语言模型的训练很多时候偏向自然语言自然语言里并不会频繁出现“右下角第 3 个 patch 和左上角第 7 个 patch 拼接起来应该是一条边”这类监督信号。结果就是模型对相邻 patch 的特征差异不够敏感一旦拼图块跨越了大片连续区域模型很难捕捉到跨 patch 的长程空间关系。更关键的是训练数据里的视觉问答任务经常只要求“识别内容”并不需要模型对坐标空间做精确回归。这样的数据分布决定了模型很难内生出很强的空间位置推理能力。4.3 评测集太少会导致分数虚高还有一点需要提醒如果你只用 10 张测试图分数偶然性会很大。模型只要连续答对几张常见类型就会得到看似很高的准确率。因此在做正式空间推理基准时至少要保证测试图数量超过 100 张并覆盖多种类型和多种旋转方式。在小型实验中要把单张结果拆成多个指标观察而不要只报一个最终准确率。回到我们的脚本若要让评测变得更有说服力可以在生成阶段继续扩展任务对每个图块随机旋转 90 度要求模型先判断旋转角度再判断原始坐标也可以将网格扩大到 3×3。这类多角度评测才能暴露更多问题。5. 如何改善 VLM 的空间推理表现5.1 用坐标系统替代模糊方位描述如果你是在自己开发的应用里调用 VLM一个直接可行的改善方式就是永远不要使用“左边、上方、旁边”这类模糊短语来跟模型交流。对人类友好的自然语言对模型来说反而更容易出现二义性。更推荐在提示词里引入显式坐标参考系。例如先说明“图像左上角是 (0,0)宽度方向是 X 轴高度方向是 Y 轴”要求模型只能使用数字坐标回答给出一个夹具示例例如{A: [23, 45]}。在我生成拼图脚本时也使用了类似思想让模型输出(row, col)结构化坐标而不是输出汉字“左上”或“右下”。这样的格式化约束能明显减少 JSON 解析失败也让模型把更多注意力放到空间推理本身。5.2 提示模型采用“先描述、再比较、后输出”的思维链直接从视觉图片跳到空间坐标对很多模型来说挑战过大。可以试着在提示词中加入思维链引导把步骤拆开描述每个图块内部有什么内容找出图块的边缘特征和颜色变化比较相邻图块是否具有连续边缘输出最终坐标。虽然现在很多模型具备默认的隐式推理能力但在空间任务中显式要求“逐步推理”往往比直接输出更稳定。一个可行的做法是content [ { type: text, text: ( 请按以下步骤推理\n 1. 列出每个字母对应图块的核心内容。\n 2. 找出图块之间的边缘特征是否连续。\n 3. 根据内容与边缘特征推断 2×2 网格中的原始坐标。\n 4. 只输出 JSON不许输出其他文字。\n 格式{A: [row, col], B: [row, col], ...} ) }, { type: image_url, image_url: {url: image_data_url} } ]这样写提示词后即使最终坐标判断失败你也可以通过中间推理文本定位模型是在哪一步想错了从而判断它到底是视觉编码失败、边缘匹配失败还是最终决策失败。5.3 多模型投票或带参考答案的二次校验在真实的业务应用中如果空间推理结果非常关键建议不要只调用一次模型。最稳妥的方式是调用 3 次同样的模型或使用 3 个不同模型然后把返回的坐标结果进行投票如果三个结果不一致再让一个模型综合判断哪一个是更合理的。另一个实用技巧是“答案校验”模式第一次让模型生成坐标第二次不再让模型直接给答案而是把“已给出的答案”和原图一起再给模型让模型判断这些答案是否符合图像的空间排列。这种二次校验虽然不会提高模型上限但可以筛掉一批明显的随机错误。6. 拼图评测之外的工程建议6.1 视觉输入质量和图片传输方式空间推理对图像质量的依赖比普通问答大得多。图像一旦分辨率过低图块内的边缘就变得不明显模型判断自然容易失败。做测试时建议至少保持 512×512 以上的输入分辨率要控制压缩比。调接口时如果图片不是本地文件而是网络 URL也要注意链接有效期和跨域问题。本地图片最保险的方式还是转成 base64 字符串后放在请求体里。同时部分平台的 base64 请求体大小有限动态生成图片任务时一定要限制输出尺寸。6.2 安全使用 API 和敏感数据管理多模态大模型的 API 调用会把图片传到第三方接口这不适合处理包含个人隐私、商业机密的图像。进行 VLM 评测或业务开发时应当先确定图片内容的敏感级别。如果数据不能出内网就应该使用本地开源的 VLM 部署方案而不是把图片传到云 API。即使使用的是开源模型也应当遵循最小权限原则只给评测脚本提供必要的数据目录不要把服务器上的所有文件都暴露给推理进程不要将 API Key 写死在代码里应该从环境变量或本地密钥管理服务中读取。6.3 设计自己的评测集时要避开“数据泄漏”做空间推理基准和相关模型微调时最容易被忽视的问题是数据泄漏。如果用于评测的图片和模型训练数据分布高度重合模型可能已经见过这类图它给出的正确结果未必来自推理而是来自记忆。为尽量避免数据泄漏建议优先使用自己采集、新拍摄的图片或二次编辑过的合成图拼图块最好加入随机旋转和局部裁剪让图片不再与原始图完全一致不要反复使用同一批评测图去调模型提示词否则会产生“过拟合评测集”的假象。一个成熟的空间推理基准通常会把数据分为多个部分纯几何图形集、自然图像集、文档截图集、人工合成干扰图集。只有经过这样的多数据集交叉验证我们才能比较有信心地说“某个 VLM 是否有空间推理硬伤”。7. 常见报错与处理方式我在实际使用这套流程时遇到过一些频率很高的问题整理如下问题现象常见原因解决思路请求超时或网络不稳定图片 base64 体积太大或接口限流限制输入图片为 512×512增加重试与退避逻辑JSON 解析失败模型输出了 Markdown 代码块或额外解释文字在提示词中强制 JSON 输出并提供解析纠错函数图片无法显示base64 前缀拼写错误或图片格式不支持确认使用data:image/png;base64,或用 JPEG 时改为data:image/jpeg;base64,准确率波动很大测试图数量太少或图块旋转角度太少增加测试集数量并统计多次运行结果的均匀值模型不遵循坐标格式未提供明确的坐标系统说明给出一段格式示例并要求只输出 JSON模型描述图像内容很准但位置全错视觉编码较强但空间关联较弱加入思维链提示要求先描述图块边缘再输出位置空间位置总是左右翻转视觉 patch 序列化损失二维方位感知增加“左右镜像判断”专项测试必要时对模型进行有监督微调遇到模型返回异常时先不要急着改模型。建议先把模型原始输出打印出来确认再决定是提示词问题、图片问题还是调用代码问题。如果模型输出存在规律性的长句干扰可以在解析函数里做一层剥壳例如提取首个{和最后一个}之间的内容。8. 后续可以继续深挖的方向如果你按照前面的代码跑通了最简单版本接下来可以往三个方向继续扩。方向之一是做“多层级空间评测”。把 2×2 拼图扩展成 3×3、4×4并加入旋转块、空块和噪声块。随着网格数增加正确还原难度会指数级提升这时可以更明显地把不同模型的水平拉开。但要注意题面越难模型输出就越可能出现幻觉所以评测提示词也需要写得更细致。方向之二是“空间推理辅助的 Agent 应用”。很多开发者在做 GUI 自动化、移动端界面操作、文档解析等 Agent 能力时本质上都需要模型看懂界面元素的绝对位置和相对层级。可以把拼图评测的思路迁移到坐标输出能力上让模型把截图中的按钮、输入框、图片区域用 bounding box 坐标输出并进行严格校验。方向之三是“曲线救国式微调”。如果你使用的是开源 VLM可以尝试用拼图任务自动生成大量有监督训练数据把图片切成块、打乱、生成 prompt 和标准坐标。这是一类成本可控的自监督数据生产方式。用这种数据对模型做轻量级微调通常能在不损失通用能力的前提下提升空间方向判断能力。最后想说的是多模态大模型还处在快速演进阶段今天表现不好的空间推理可能在下一代模型里就得到明显改善。但只要我们坚持用结构化评测去发现短板而不是只依赖几个模糊的 demo 来判断模型能力整个技术栈的可靠性就会越来越高。如果你在自己的模型测试中也遇到类似的空间排序问题不妨在评论区分享下你用的是哪个模型、输出的是哪类错误我们可以一起把这类评测方法打磨得更完善。