See2Think：多模态模型真的使用了中间视觉状态吗？

关联论文：2607.26769
作者：Tom
更新：2026-08-01

一句话结论

多模态大模型在推理中生成草图、标注、中间图像——但它们真的依赖这些视觉状态吗？See2Think 实验答案是：高度依赖，但「faithful rendering」是最大瓶颈；且有了高反馈利用率也不一定转化为精度提升。

解决什么真问题

多模态 LLM（如 GPT-4V、Gemini、Qwen-VL 等）在推理时越来越多地使用中间视觉状态（intermediate visual states）：画草图、做标注、用工具渲染图像、生成中间帧等。但这里存在一个根本性的未回答问题：这些视觉状态是推理的必要中间步骤，还是模型只是在「表演思考」，实际仍靠文本 token 做推理？

之前 benchmark 的两大局限： 1. 任务覆盖窄，或存在「部分文本可解」样本（不真正需要视觉理解） 2. 只评估最终答案，没有诊断中间视觉状态「如何生成→如何渲染→如何被使用」这一完整链路

核心方法

See2Think 框架 = See2ThinkBench（评测基准）+ VAoT（Visual Action-of-Thought，视觉思维动作追踪）

See2ThinkBench

1,200 道开放式视觉依赖问题
覆盖 12 个任务类别，横跨三类场景：
2D 结构化推理（图表标注、空间布局）
3D 场景推理（几何关系、视角变换）
真实世界推理（多步骤视觉问答、场景理解）
每道题都不能靠纯文本解决，必须依赖原始视觉输入和中间视觉状态的正确渲染

VAoT（Visual Action-of-Thought）

在四种受控推理设置下同时记录： 1. Textual thoughts：纯文本推理步骤 2. Visual actions：调用了哪些视觉操作（画线、标注、生成图像等） 3. Rendered states：视觉操作的渲染结果 4. Subsequent reasoning：基于渲染结果的继续推理

通过分析这四步的因果链条，判断模型是否真正「在用」视觉状态。

关键实验操控

Feedback Manipulation：注入与任务相关的损坏视觉反馈，测量模型是否会被误导——若模型依赖视觉状态，准确率应显著下降；若有独立的文本推理路径，准确率应保持稳定。

关键实验与数据

视觉推理高度依赖模型和具体环境：没有一种推理设置在所有任务类型上始终最优
模型通常能选择相关的视觉操作（即知道应该用哪个视觉工具），但：
Faithful rendering 是最明显瓶颈：渲染准确性不足是导致推理失败的首要原因⚠️ 存疑：「首要原因」是原文结论还是摘要推断？原文对渲染错误和其他错误类型（文本推理错误、工具选择错误）的相对占比未给出量化对比
高反馈利用率 ≠ 高准确率：模型吸收了视觉反馈但不一定正确使用，无法转化为最终精度提升
受控干预实验（损坏反馈）：在任务相关维度注入错误视觉反馈，准确率下降 超过 10 个百分点（>10 pp），证明模型行为上确实依赖这些视觉状态——不是纯文本推理⚠️ 存疑：>10 pp 是平均降幅还是最优/最差配置下的降幅，各任务类型的分布未公开

亮点与局限

亮点： - 首个覆盖「生成→渲染→使用」完整链路的视觉思维评测框架 - VAoT 的四步记录机制使过程可分析、可复现，不像之前的工作只能看最终答案 - 发现了「faithful rendering」这一被严重低估的瓶颈——社区往往假设「只要调用了视觉工具就是有效的」，实际上渲染质量才是木桶的短板 - 揭示了「feedback uptake」和「accuracy」之间的 gap，提醒研究者不要把用了多少反馈和用对了多少反馈混为一谈

局限： - 评测基准 1,200 题，覆盖 12 类，仍是小规模；具体每类任务数量和难度分布原文未详列 - 四种受控推理设置的具体配置（如 CoT / Tool-use / 等等）细节未完全公开 - 实验模型覆盖「代表性闭源 + 开源多模态模型」，具体模型列表和版本未在摘要中说明 - 「损坏反馈」实验的干预程度（如何量化「task-relevant corrupted feedback」）定义细节待考 - ⚠️ 未量化：四种受控推理设置（具体如何定义和实现）细节未公开，他人无法复现 - ⚠️ 未量化：>10 pp 的准确率下降具体是平均降幅还是某一配置下的最差结果，任务级别的分布未公开

对工程落地的启发

如果产品依赖多模态模型的中间视觉推理（草图、标注、图像生成），需要评估 rendering pipeline 的可靠性：视觉工具调用的成功率 ≠ 渲染结果的可信度，需要对渲染质量独立做质量门控
多模态 Agent 不要假设「调用视觉工具 = 正确使用」：需要在工作流中加入「渲染结果验证」环节，确保中间视觉状态忠实于任务需求
反馈机制设计需要区分「用了」和「用对」：如果模型有高 tool-use 频率但精度不见提升，问题可能在渲染端而非推理端——优化方向应指向 rendering 保真度，而非增加反馈轮次
部署前应做 See2Talk 式的受控干预测试：在产品环境中人为注入损坏视觉反馈，验证系统是否真正依赖视觉状态，还是有隐性文本 fallback 路径

与同方向工作的关系

与 Multimodal Reasoning Benchmark（如 MathVista、MathVision）相关，但 See2Think 更关注「过程」而非「答案」——诊断中间步骤，而非只打总分
与 Visual Program Execution / Tool-use for Vision 研究（如 Visual CoT、InternVGD）正交：那些工作设计更好的视觉工具，本文评估现有模型是否真的在使用它们
与 Model "Understands" vs "Performs" 的哲学讨论相关：See2Think 用实证方法逼近「模型是否真正理解视觉状态」这一难以直接测量的能力

适合谁读

多模态 LLM 研究者：需要系统性评估视觉推理过程而非只看最终答案
多模态 Agent / Vision-Language Tool Use 系统工程师：理解 rendering 瓶颈对整体系统的影响
Benchmark 设计者：参考「过程可分析」的评测框架设计思路
VLM 评估与对齐研究者：理解「调用视觉工具」和「真正依赖视觉状态」之间的 gap

工程落地与核查（Jay）

实际怎么落地

1. 判断你的系统是否处于 See2Think 高风险场景

高风险场景特征（满足任一即需关注）： - 模型调用视觉生成工具（canvas、标注、渲染）后直接用输出继续推理 - Pipeline 中存在「文本推理 ↔ 图像渲染」的多次交替 - 最终答案严重依赖中间图像/图表的正确性（而非仅作为展示辅助）

低风险场景：视觉仅用于最终呈现，中间推理完全在文本层完成。

2. 渲染质量门控的工程实现

# 伪代码：渲染结果质量门控
def render_with_verification(image: Image, task: str) -> Image:
    """在渲染任务图像后，追加一步质量检查"""
    quality_check = vlm_verify_render(image, task)
    # quality_check 返回：(is_faithful: bool, issues: list[str])
    if not quality_check.is_faithful:
        # 策略 1：降级为纯文本推理（牺牲视觉能力换取可靠性）
        logger.warning(f"Rendering unfaithful, falling back: {quality_check.issues}")
        return None  # 上游切换到 text-only pipeline
    return image

# ⚠️ 坑 1：质量检查 LLM 调用增加延迟（~300ms-1s/图像），实时产品需异步或预热
# ⚠️ 坑 2：检查 LLM 本身也可能被低质量渲染骗过，检查模型需比主模型更强或专精
# ⚠️ 坑 3：检查不通过时的 fallback 策略需要产品侧明确定义

3. 受控干预测试（Shadow Testing）生产部署方案

在 staging / shadow 环境中定期注入损坏视觉反馈，验证系统鲁棒性：

# 伪代码：shadow test 框架
def shadow_test_with_corruption(pipeline, test_cases, corruption_rate=0.1):
    """
    对 10% 的测试用例注入损坏视觉反馈，
    测量准确率下降是否在可接受范围内（<5 pp）
    """
    corrupted_results = []
    for tc in test_cases:
        if random.random() < corruption_rate:
            tc = inject_corrupted_visual_feedback(tc)
        result = pipeline.run(tc)
        corrupted_results.append(result)

    baseline_acc = measure_accuracy(baseline_results)
    corrupted_acc = measure_accuracy(corrupted_results)
    degradation = baseline_acc - corrupted_acc

    assert degradation < 0.05, f"Acc degradation {degradation:.2%} exceeds threshold"
    return degradation
# ⚠️ 坑：corrupted feedback 的注入方式和真实攻击的相似度无法保证

4. 各环节可靠性建设清单

组件	风险	检查方式	阈值
视觉工具调用	调用失败或调用错误工具	工具返回码 + 类型检查	失败率 < 1%
渲染保真度	渲染结果与任务意图不符	VLM quality check	faithful ratio > 0.85
反馈利用率	渲染结果被忽略或误用	VAoT 式四步 trace 分析	uptake rate > 0.7
端到端准确率	中间步骤全部正确但最终答案错	黄金数据集评估	acc > baseline - 5pp

5. 常见工程坑点

坑点	描述	解决方案
渲染异步性	渲染结果返回慢于推理继续，导致时序错误	强制渲染完成后再继续推理，加入显式 await
渲染版本不一致	同一图像被多次渲染产生不同结果，导致推理不一致	对渲染输入做 hash，输入相同则复用缓存结果
多模态模型版本差异	不同 VLM 版本对渲染质量的敏感度差异极大	A/B 测试时锁定模型版本，记录 degradation 曲线
文本 fallback 假象	文本 fallback 被当作「渲染失败后的正确处理」，实为精度损失	fallback 时记录"render_fail → text_fallback"事件，单独统计精度
高 uptake 低 accuracy 的误导	监控仪表板显示高 tool-use 频率，但精度未改善	同时展示 uptake rate 和 accuracy trend，两者背离时告警

6. 未解决的工程问题

论文未公开损坏反馈的注入量级（损坏多少比例的视觉操作）和各任务类型 accuracy 下降的分布，无法做精细化的产品风险评估
faithful rendering 的自动化评估（不依赖人工标注）未提供方案，工程实现时需自研或借用外部 VQA 工具
四种受控推理设置的具体配置未公开，「faithful rendering 是首要瓶颈」的结论是否在所有推理设置下均成立存疑
多模态 Agent 生产场景（连续多轮、跨工具链）的 rendering 错误累积效应未被研究，实际部署时可能比实验环境更严重