UI-Ins 论文深度解读:Instruction-as-Reasoning 范式与 GUI Grounding 的多视角推理
论文: UI-Ins: Enhancing GUI Grounding with Multi-Perspective Instruction-as-Reasoning
作者: Liangyu Chen, Hanzhang Zhou, Chenglin Cai 等(中国人民大学 & 通义实验室)
链接: https://arxiv.org/abs/2510.20286
代码: https://github.com/alibaba/UI-Ins
一、论文概述
UI-Ins 提出了一个核心洞察:指令(instruction)不应被视为静态输入,而应被视为动态的推理路径。
GUI Grounding 的任务是将自然语言指令映射到屏幕截图上的可操作 UI 元素。传统方法把指令当成一个固定的字符串输入,模型学到的是"指令→坐标"的映射。UI-Ins 提出的 Instruction-as-Reasoning 范式,将指令重新定义为分析性推理的载体------同一个操作意图可以从外观、功能、位置、目标四种不同视角来描述,每种描述本质上是一条不同的推理路径。
最终产出的 UI-Ins-7B 和 UI-Ins-32B 在 5 个 grounding benchmark 上取得 SOTA,并在 AndroidWorld 上以 GPT-5 作为 planner 时达到 74.1% 成功率。
二、核心问题:指令到底有多重要?
这篇论文最有价值的部分其实在方法之前------Sec.2 的实证分析。作者用两个精心设计的实验回答了两个基本问题:
2.1 指令多样性的潜力有多大?
实验设计: 在 ScreenSpot-Pro 上,将原始指令分别重写为外观(Appearance)、功能(Functionality)、位置(Location)、意图(Intent)四种视角,用 Qwen2.5-VL-7B 进行零样本评测。
关键发现:
- 外观、功能、意图三种视角都显著优于原始指令
- 如果模型能针对每个样本自动选择最佳视角(Combined),可以获得 76% 的相对性能提升
- 这意味着无需任何训练,仅通过选择更好的指令视角,就有巨大的性能空间
深度解读: 这个 76% 的数字极其重要。它本质上说明了一件事------当前 grounding 模型的性能瓶颈可能不在视觉理解,而在指令理解。同一个模型、同一张截图,换个说法就能大幅提升准确率。这说明模型的视觉感知能力已经"够用"了,瓶颈在于指令和视觉信息之间的对齐质量。
2.2 现有数据集的指令质量如何?
实验设计: 人工检查了 OS-Atlas、AMEX、Widget Captioning 三个数据集共 1,909 条样本。
关键发现:
- 23.3% 的样本存在指令质量问题,包括歧义(一条指令对应多个 UI 元素)和错配(指令描述的元素在截图中不存在)
- 在清洗后的数据上训练,性能一致且显著提升
深度解读: 这个发现对整个领域有重要启示。我们在做 grounding 数据合成时,大量使用 LLM 生成指令,但很少有工作系统性地验证生成指令的质量。UI-Ins 用 OmniParser V2 做元素检测 + IoU 过滤 + GPT-4.1 验证的三步清洗流程,值得借鉴。
三、方法论:Instruction-as-Reasoning 框架
3.1 数据管线:从清洗到多视角增强
两阶段处理:
- 预处理(清洗): 使用 OmniParser V2 检测所有 UI 元素,用 IoU 方法校正/过滤原始 bbox 标注,同时删除有缺陷的指令
- 多视角指令增强: 用 GPT-4.1 从四种分析视角(外观、功能、位置、意图)生成新的指令描述,再用 GPT-4.1 进行验证,确保每条指令和目标元素的一一映射关系
深度解读: 这个数据管线的核心思想是 "先做减法再做加法"------先清除噪声(23.3%→<8%),再系统性地扩充指令多样性。验证步骤是关键:对每条生成的指令,让 GPT-4.1 反向确认它是否唯一指向目标元素,而不是模糊地匹配到多个元素。
3.2 SFT 阶段:教模型生成多视角推理
训练机制:
- 从四种视角中随机选两个,一个作为"输入指令的视角",另一个作为"推理输出的视角"
- 模型的输出格式是:推理文本(换一种视角重述指令) ⊕ 坐标点
- 在约 283k 实例上训练一个 epoch,batch size 256,lr 5e-6
深度解读: 这里有一个精妙的设计------SFT 阶段的"推理"不是自由发挥的 CoT,而是将指令从一种视角翻译到另一种视角。比如输入是"点击右上角的按钮"(位置视角),推理输出是"点击关闭文件管理器的按钮"(功能视角),然后输出坐标。
这种结构化推理相比自由形式的 CoT 有两个优势:
- 推理内容可控------不会跑偏到无关的思考
- 推理方向明确------每条推理路径都对应一种确定的分析视角
这跟领域内"SFT + 长 CoT 会损害 grounding 精度"的经验完全吻合(GUI-G2、UI-R1 等论文也有类似发现)。UI-Ins 用结构化的视角翻译代替自由 CoT,绕开了"推理越长 grounding 越差"的陷阱。
3.3 RL 阶段:学会选择最优视角
训练机制:
- 使用 GRPO(Group Relative Policy Optimization),33k 实例扩展为约 100k 训练样本
- 关键变化: RL 阶段的 prompt 只说"先想一想再回答",不指定具体视角
- 奖励函数:简单的 point-in-box 判断(预测坐标是否落在 gt bbox 内)
- 8 rollouts,lr 1e-6
深度解读: RL 阶段的设计体现了"SFT 教能力,RL 教选择"的哲学:
- SFT 阶段强制模型学习四种视角的推理能力(显式指定视角)
- RL 阶段放开约束(不指定视角),让模型自己探索哪种视角最有效
这里有一个非常关键的技术贡献:解决 SFT****→RL 的 policy collapse 问题。 传统做法中,SFT 只教模型输出坐标,导致模型的输出高度一致(都是类似的坐标格式),在 RL 阶段 rollout 几乎没有多样性,无法有效探索。UI-Ins 的 SFT 阶段教会了模型四种不同的推理视角,使得 RL 阶段的 rollout 天然具有多样性,从而避免了 policy collapse。
更有意思的是,RL 训练后模型还展现出涌现能力 ------不仅会选择训练中见过的四种视角,还会组合多种视角 或创造全新的推理视角。这说明 Instruction-as-Reasoning 不仅是一种训练技巧,更可能帮助模型建立了对 UI 元素的多维理解。
四、实验结果分析
4.1 SOTA 表现
核心数据一览:
- MMBench-GUI L2:UI-Ins-7B 83.1%,UI-Ins-32B 84.9%(vs GTA1-32B 83.4%)
- UI-I2E-Bench:UI-Ins-32B 87.3%(vs GTA1-32B 86.6%)
- ScreenSpot-Pro:UI-Ins-32B 57.0%(vs OpenCUA-32B 55.3%)
- ScreenSpot-V2:UI-Ins-32B 94.9%(vs UI-Venus-7B 94.1%)
- Showdown:UI-Ins-32B 73.8%(vs GTA1-32B 71.1%)
- AndroidWorld:UI-Ins-7B 74.1%(vs UI-TARS-2 73.3%)
4.2 关键发现:越难的指令,优势越大
这是最有意思的结果模式:
MMBench-GUI L2:
- UI-Ins-7B vs Qwen2.5-VL-7B:Basic +134.2%,Advanced +159.4%
- UI-Ins-32B vs Qwen2.5-VL-32B:Basic +12.3%,Advanced +24.5%
UI-I2E-Bench:
- UI-Ins-32B vs GTA1-32B:Explicit +1.6%,Implicit +6.6%
深度解读: "指令越难、优势越大"这个趋势直接验证了 Instruction-as-Reasoning 的核心假设------多视角推理的价值在困难场景下才能充分体现。 对于简单的 Basic/Explicit 指令(如"点击红色的X按钮"),大多数模型都能处理,视角翻译的价值不大。但对于 Advanced/Implicit 指令(如"关闭这个不需要的窗口"),模型需要从意图层面理解,然后映射到具体的视觉元素------这正是 Instruction-as-Reasoning 擅长的。
4.3 AndroidWorld 实战验证
- UI-Ins-7B(executor)+ GPT-5(planner)= 74.1% 成功率
- 对比 Qwen2.5-VL-7B(executor)+ GPT-5(planner)= 50.0%
- 甚至超过 UI-TARS-2(73.3%)和 Gemini 2.5 Computer Use(69.7%)
深度解读: 同样用 GPT-5 做 planner,只换了 executor(grounding 模型),成功率从 50.0% 跳到 74.1%。这说明在 planner+executor 的 agent 架构中,executor 的 grounding 能力是核心瓶颈之一。一个强大的 grounding 模型可以直接且大幅提升整体 agent 性能。
五、消融实验与深度洞察
5.1 训练阶段消融
SFT 和 RL 两个阶段缺一不可。仅 SFT 或仅 RL 都会导致所有 benchmark 上的性能下降。
5.2 推理组件消融
移除中间推理(直接输出坐标而不先做视角翻译)会导致显著性能下降,验证了 Instruction-as-Reasoning 推理过程本身的价值。
5.3 自由 CoT vs 结构化推理
与 GUI-G2、UI-R1 等工作的发现一致------自由形式的 CoT 在 GRPO 中往往降低 grounding 性能。而 UI-Ins 的结构化视角翻译则一致性地提升性能。这不是巧合:自由 CoT 的搜索空间太大,RL 难以收敛;结构化推理限定了有意义的搜索空间。
5.4 Policy Collapse 的发现与解决
传统 SFT(只教坐标输出)→ RL 时,模型 rollout 高度一致,导致 policy collapse。UI-Ins 的多视角 SFT 天然产生多样化输出,为 RL 提供了充分的探索空间。这是一个有实操意义的发现。
5.5 涌现能力
RL 训练后,模型不仅会选择训练中见过的四种视角,还展现出:
- 组合多种视角形成复合推理路径
- 创造全新的推理视角(训练中未见过的)
六、核心洞见总结
洞见 1:结构化推理 > 自由 CoT
对 grounding 任务,推理不是"想得越多越好",而是"想对方向最重要"。自由 CoT 可能生成大量与定位无关的推理,反而干扰坐标输出。UI-Ins 的"视角翻译"让每一步推理都直接服务于定位目标。
洞见 2:数据多样性 > 数据规模
UI-Ins 训练数据量不大(SFT 283k,RL 100k),但每条数据有四种视角变体。相比堆百万级单一风格数据,语义层面的多样性更有价值。
洞见 3:SFT 为 RL 打地基
"SFT 注入能力 → RL 优化策略"的两阶段范式正在成为标准。UI-Ins 的独特贡献是揭示了 SFT 阶段必须教会模型产生多样化输出,否则 RL 会 policy collapse。
洞见 4:指令视角 = 分析维度
四种指令视角本质上对应认识 UI 元素的四个维度:
- 外观:它长什么样(视觉特征)
- 功能:它是干什么的(语义理解)
- 位置:它在哪里(空间推理)
- 意图:用户为什么要操作它(任务理解)
这个分类框架可以直接指导数据合成和 prompt 设计。
七、与我们工作的关联
与实验三数据合成策略的对比
我们在实验三中采用了"input 多样化 + output 格式统一化"的策略------用 15 种 prompt 模板经 Gemini-3-pro-thinking 重写 instruction,output 统一为 JSON 格式。与 UI-Ins 的对比:
- UI-Ins 多样化对象: 指令视角(4种分析维度)
- 我们多样化对象: prompt 模板(15种风格变体)
- UI-Ins 统一化对象: 坐标输出格式
- 我们统一化对象: JSON 输出格式(action_type + value/point)
- UI-Ins 生成工具: GPT-4.1
- 我们生成工具: Gemini-3-pro-thinking
- UI-Ins 验证步骤: GPT-4.1 反向验证唯一映射
- 我们验证步骤: 无显式验证
- UI-Ins 数据量: SFT 283k + RL 100k
- 我们数据量: SFT 40k
可借鉴的点
- 增加验证步骤:我们的重写流程缺少对生成质量的系统性验证
- 视角维度更明确:我们的 15 种模板更偏向风格变体,UI-Ins 的四种视角更偏向分析维度------后者在语义层面的多样性可能更有价值
- RL 阶段设计:我们的 RL(实验五)直接在 SFT checkpoint 上做,可以考虑引入类似"不指定推理视角"的开放式探索
对 RL 训练的启示
我们在实验五中观察到"RL 对训练数据覆盖的指标能稳定提点,未覆盖的指标基本持平"。UI-Ins 的分析提供了一个可能的解释------如果 SFT 阶段模型输出多样性不够,RL 的探索空间就很有限,无法泛化到未见过的场景。 增加 SFT 阶段的推理多样性(如引入多视角推理)可能有助于 RL 更好地泛化。
八、总结
UI-Ins 的核心贡献可以用一句话概括:在 GUI Grounding 中,用结构化的多视角指令翻译代替自由 CoT,解决了"推理有害 grounding"的困境,同时为 SFT→RL 训练框架提供了天然的多样性基础。