VISTA：当GRPO在GUI上失效时，蚂蚁集团换了个视角——把固定截图变成多视角游戏

论文：VISTA: View-Consistent Self-Verified Training for GUI Grounding
arXiv: 2606.14579 | 2026年6月
机构：浙江大学 × 蚂蚁集团Venus团队
项目页/模型：详见论文

🔥 一句话总结

VISTA 发现了一个GRPO在GUI grounding上的致命盲区：对同一张固定截图重复采样，99%的情况要么全对要么全错，组内方差为零，梯度直接消失。解决方式出人意料——不改算法，改"视角"：从同一个GUI实例生成多个保留目标的裁剪视角，让模型在不同几何透视下做同一任务，自然引入有效方差。

🎯 问题：GRPO的"reward degeneracy"

GUI grounding 任务很简单：给一张截图 + 一条指令（"点击导出按钮"），输出点击坐标。

验证也简单：坐标落在目标框内 = +1，否则 0。

但把这个任务丢给 GRPO，出了大问题：

标准GRPO: \(A_i = (r_i - μ_G) / (σ_G + ε)\)

情况1（困难样本）: 目标太小/模糊 → 4个rollout全错
\(r = [0, 0, 0, 0] → μ=0, σ=0 → A = [0, 0, 0, 0]\) ❌

情况2（简单样本）: 目标很显眼 → 4个rollout全对
\(r = [1, 1, 1, 1] → μ=1, σ=0 → A = [0, 0, 0, 0]\) ❌

结果: <5%的训练分组是"有效分组"（既有对又有错）

这不是模型不够强，是GRPO的假设在GUI grounding上被打破了。 GRPO假设组内样本有足够方差来产生有意义的相对优势，但GUI坐标和截图几何强绑定——同一张图里，要么都能点到，要么都点不到。

⚙️ 核心技术：三个组件，解决同一个问题

1. 视角一致分组采样：换个角度看同一件事

核心思路：不再对同一张截图重复采样，而是对同一个GUI实例生成多个目标保留裁剪——每个裁剪都是独立的"视角"，但指向同一个语义目标。

具体做法：

原始UI截图 (1920×1080)
    ↓
目标框 B = (x1,y1,x2,y2)
    ↓
生成K个随机裁剪窗口 C_k，每个都完全包含B
    ↓
对裁剪后的图做坐标重映射:
    B_k = ((x1-l_k)/w_k × 1000, ...)
    ↓
每个视角采样n个rollout → 总共G=K×n个rollout构成一组

为什么有效？

原图视角: 导出按钮在右下角，很小 → 4个rollout全错 [0,0,0,0]
裁剪视角1: 放大右下角，按钮变清晰 → 2对2错 [1,0,1,0] ✓ 有方差了！
裁剪视角2: 放大整个工具栏 → 3对1错 [1,1,1,0] ✓ 有方差了！
裁剪视角3: 从左侧切入 → 按钮被部分遮挡 → 1对3错 [0,1,0,0] ✓ 有方差了！

同一个目标在不同视角下的难度不同，自然产生了组内方差。

关键设计细节：

• 裁剪尺寸默认原图90%，若不够大自动放大到框大小
• 20%概率保留全图（pass-through），避免过度裁剪
• 坐标精确重映射到0-1000空间，保证标签正确

2. 自验证跨视角锚定："你先证明自己行，我才给提示"

如果仅靠视角变化还不够怎么办？VISTA设计了一个条件性oracle监督机制：

条件: 当前分组中，模型自己有没有生成至少一个完全正确的预测？
    ↓
如果没有（g=0）: 不激活oracle，只保留GRPO的标准更新
    为什么？——模型还没学会，给oracle也没用，反而干扰
    
如果有（g=1）: 激活oracle锚点 y⁺ = 目标框中心坐标
    为什么？——模型已经会了，给个锚点帮它稳定，收敛更快

锚点只用作训练稳定信号，不参与GRPO的组统计计算——这是关键区别。

对比其他oracle方法：

3. 模型独占的组统计：oracle不掺和基线计算

GRPO基线: μ_m = 模型rollout的平均奖励（不含oracle锚点）
          σ_m = 模型rollout的奖励标准差

oracle锚点的优势: A⁺ = g × (R_max - μ_m) / (σ_m + ε)

→ oracle只在自己优势计算时用自己，不拉高或拉低基线
→ 避免了"ground-truth序列人为抬高baseline"的监督泄漏

📊 实验：ScreenSpot-Pro 暴涨 +13.3 分

主结果

ScreenSpot-Pro 是提升最猛的基准——它以"小目标、高密度、高分辨率"著称，恰恰是固定视角GRPO最吃瘪的场景。

35B-A3B规模达到72.9 SOTA。

跨骨干验证（Qwen3.5系列）

VISTA 在 Qwen3.5 上同样一致提升，不依赖特定初始化。

消融实验

关键发现：

• 单纯数据增强（SFT+aug）只提升0.7点 → 不是增强本身有效
• 无门控的归一化oracle反而损害性能 → 自验证门控是关键
• 视角分组（+3.3）和自适应锚定（+2.4）互补，缺一不可

裁剪鲁棒性

VISTA的裁剪准确率 > 原图准确率——训练时见过视角变化，对裁剪反而更鲁棒。

🧠 深度解读：VISTA 为什么有效？

1. 不是算法创新，是"问题重构"

VISTA 最聪明的地方在于：它没有改GRPO的公式，而是改了GRPO的输入。

传统思路遇到reward degeneracy会想：改算法（新的优势估计、新的奖励塑形、新的采样策略）。VISTA的思路是：算法没问题，问题是"固定截图"这个设定让任务本身 degenerate 了。换个视角，任务就活了。

这就像给棋手反复出同一道题——要么都会要么都不会，没有区分度。换成同一类题的多个变体，梯度自然就来了。

2. "自验证"哲学的普适性

VISTA 的 oracle 使用策略——"模型先证明自己能解，才给提示"——可以推广到其他RL场景：

• 代码生成：模型先写出一个能通过部分测试的解，再给完整测试用例
• 数学推理：模型先推导出中间步骤的正确答案，再给最终答案
• 对话对齐：模型先产生符合基本要求的回复，再给精细反馈

核心原则：提示（hint）不是替代思考，是加速收敛。

3. GUI grounding 的独特性

论文反复强调的是：GUI grounding 和其他视觉任务不同——

• 图像分类：换视角，猫还是猫，标签不变
• 目标检测：换视角，框要跟着变，但任务是"找出所有目标"
• GUI grounding：换视角，坐标必须精确重映射，任务是"点准这个按钮"

这种"坐标与几何强绑定"的特性，使得固定视角的RL几乎必然 degenerate。VISTA 的视角变化是"必要之恶"，不是可选增强。

⚠️ 局限与延伸

1. 裁剪依赖目标框：需要预先知道目标位置才能做目标保留裁剪。对于开放式指令（"找到所有可点击元素"），如何应用视角一致分组？

2. 20% pass-through：保留了部分全图样本，但如果任务本身在全图视角下就全对或全错，这部分仍然 degenerate。

3. 多模态扩展：论文提到可以扩展到非GUI的视觉任务，但不同任务的几何特性不同——医学图像、自动驾驶、机器人操作，视角变化的含义完全不同。

4. 计算开销：每个样本需要生成K个视角的裁剪和重映射，预处理成本增加。虽然相比模型推理可以忽略，但数据pipeline变复杂了。

🔗 相关阅读

• 论文原文：arXiv:2606.14579
• 对比基线：
  • SeeClick, ShowUI, Aria-UI — SFT-based GUI grounding
  • GTA1, UI-TARS, Step-GUI — RL-based GUI grounding（GRPO）
  • LUFFY, BREAD — Oracle引导的GRPO变体
• 评估基准：ScreenSpot-Pro（小目标高密度）、ScreenSpot-V2、OSWorld、MMBench

VISTA 的核心启示：有时候RL不收敛，不是算法的问题，是问题定义的问题。 在GUI grounding这种"坐标与几何强绑定"的任务上，固定视角本身就是对RL的"信息封锁"。换个视角，让同一目标在不同透视下呈现不同难度，梯度自然就流动起来了。这不是技巧，是对任务本质的重新理解。

#VISTA #GUI #GRPO #强化学习 #多模态 #视觉定位 #蚂蚁集团 #浙江大学 #论文解读 #AI研究