01引言不知庭霰今朝落，疑是林花昨夜开。今天要介绍的模型是一款用于屏幕理解的GUI Agent模型，该模型由新加坡国立大学Show Lab和微软共同提出。02简介ShowUI是一个视觉-语言-动作模型，旨在构建更高效的GUI助手。该模型通过创新的视觉Token选择、交替的多模态流和精心设计的训练数据集，实现了出色的GUI交互性能。Q1: 这篇文章想要解决什么问题？A1: 主要解决三个问题:如何高效处理高分辨率UI截图中的大量视觉Token如何有效管理GUI任务中的视觉-语言-动作交互如何构建高质量的GUI指令数据集Q2: 这篇文章如何解决这些问题？A2: 提出了三个主要创新:设计UI引导的视觉Token选择方案：通过构建UI连通图识别冗余Token，减少计算成本交替的视觉-语言-动作流：灵活统一不同模态的交互，有效管理视觉-行动历史，提高训练效率精心设计的训练数据及采样策略：通过数据分析和重采样解决数据不平衡问题Q3: 文章所提出方法的效果如何？A3: 基于Qwen2-VL-2B模型的ShowUI在多个基准测试中表现出色：在零样本截图定位任务上达到75.1%的精度Token选择方法减少33%冗余视觉Token，训练速度提升1.4倍在Web、Mobile和Online环境中展现出强大的导航能力Q4: 文章所提方法还有哪些不足？A4: 主要存在以下不足主要基于离线数据训练，在线环境表现有限，仍然有较大提升空间跨网站(Cross-Website)和跨域(Cross-Domain)的泛化能力需要提升视觉UI感知能力仍有提升空间GitHub地址：https://github.com/showlab/ShowUI论文地址：https://arxiv.org/abs/2411.17465公布高质量指令数据集：https://huggingface.co/datasets/showlab/ShowUI-desktop-8K在线Demo体验：https://huggingface.co/spaces/showlab/ShowUI03方法如图3所示，ShowUI建立在视觉-语言模型Qwen2-VL-2B的基础之上，并融入了以下针对GUI任务进行优化的关键组件:UI引导的视觉Token选择将UI截图转换为基于RGB值的连通图在每个连通分量内随机选择Token，保留位置信息实现高效的视觉建模同时保持性能交替视觉-语言-动作流统一处理不同设备上的动作变体灵活管理视觉历史和动作序列支持多轮对话提高训练效率GUI指令微调策略精选高质量的训练数据采用平衡采样策略针对不同设备特点优化数据配置图3：ShowUI的示意图。给定一个用户任务query、预定义的动作空间，以及初始屏幕截图作为观察输入，ShowUI将执行下一个动作，更新屏幕截图，并在此循环中继续进行。值得注意的是，ShowUI具有以下关键创新设计:(i) UI引导视觉Token选择，将处理输入的屏幕截图，构建基于UI分块的连通图。在训练过程中，每个连通分量中随机选取一个token子集，用于高效的视觉建模。(ii)交替视觉-语言-动作流，有效处理过去的屏幕截图和动作，提高导航性能。UI引导视觉Token选择经过标准分块后，高分辨率截图可能会产生大量视觉Token。如图4(a)所示，PC上1344×756分辨率在14×14分块后会产生约5184个原始Token，即使进行2×2合并后仍有1296个Token，这对自self-attention模块构成计算挑战。与自然视觉不同的是，UI截图本质上是结构化的，具有清晰的布局和一致的配色方案，以优化可读性和可用性。这意味着UI图像通常包含不携带重要信息的冗余(如空白区域或简单背景)。此外，某些尺寸较小但功能重要的元素(如图标或文本)则需要更高的突出度。因此，有必要制定一种策略，能够区分冗余和重要的视觉元素，从而有效地剪除无关的视觉Token而不会损害可用性。实践中发现RGB空间可作为此目的的一个有用指引，因为模式变体、字体等可通过其RGB值轻松识别。图4:UI引导的视觉Token选择示意图。左侧:从原始截图(左侧)开始，采用28×28的patch网格(中间)，产生1296个token，UI连通图基于RGB值自适应地将图像分割成不相连的区域，使同一区域内的patch可视为冗余。右侧:比较利用UI连通图进行视觉token建模的两种方法:Token合并将一个组件内的所有token pooling在一起，丢失了各个位置信息，而Token选择则在每个组件内随机采样部分token，仍保留了它们原始的位置关系。构建UI连通图。在将截图划分为规则patch之后，观察到许多相邻patch共享完全相同的RGB值，因此是冗余的。基于此，将每个patch表示为图中的一个节点，并将具有相同RGB值的相邻patch对应的节点连接，形成连通分量。这使能够基于其独特的RGB模式对冗余区域进行分组和简化，同时保留重要的视觉元素。通过设置patch tensor差异的阈值，可以轻松检测到视觉上相同的patch。基于这一洞察，使用并查集方法(Union-Find method)识别该UI连通图中的连通分量，如算法1所述。该算法产生了一个具有K个连通分量的图，其中K通常小于原始patch数。根据每个节点所属的组件，可以对patch之间的冗余关系进行建模。如图4(a)所示，该方法可以有效地基于其视觉信息量自适应平衡分量数量，在谷歌搜索页面这样具有稀疏区域的页面上使用较少的分量(更多冗余patch)(1296→291)，而在文本密集的Overleaf截图上则分配更多分量(更多独立patch)(1296→986)。在图5中，展示了ShowUI如何在不同设备上构建UI连通图。对于具有相同分辨率的截图，其初始视觉patch token相同(例如1272个)，文章的方法会根据截图的信息量自适应地构建连通分量。Token合并 v.s. Token选择。接下来，探讨如何利用这一UI连通图提高模型效率。实验过程发现目前视觉-语言模型的主要计算瓶颈在于级联自注意力层处理的长序列，影响了语言模型和视觉编码器。一种直接的方法是应用token合并方法，将一个组件(component)内的所有patch表示为单个token，如图4(b)左半部分所示。然而，这种方式破坏了位置关系，因为pooling后的token序列不可避免地丢失了原始的位置信息，而这对于准确地ground UI元素是至关重要的。为在不损失位置信息的情况下实现token压缩，受Mixture-of-Depth启发，通过路由机制稀疏采样token。归属同一component内的token可视为冗余，因此在训练期间随机跳过每个component内的一部分token，保留单patch分量不受影响以保留基本元素。对于选择的token，保留它们原始的位置嵌入，确保了自注意力在较短的token序列上仍能保持原始的位置关系。值得注意的是，该token选择方法无需额外的可学习参数。因此，在训练时以设定的比例随机进行token选择，而在推理时，该方法可灵活地选择使用或不使用token选择，因为两种选择都能保持全token序列内的一致位置关系。交替视觉-语言-动作流本节探讨如何构建动作以及动作与视觉、文本查询等其他模态之间的关联关系。动作与自然语言的差异性。GUI模型的核心功能是导航，基于文本查询，需要模型联合预测:正确的动作类型(如[CLICK]或[TYPE])以及相应的动作参数(如[CLICK]的坐标或[TYPE]的字符串)。在导航过程中的一大挑战来自于不同设备上动作的变体，例如:设备特定动作(如[CLICK]在移动设备上不可用，而[PRESS HOME]在网页上不存在)。相同动作但参数不同(如[SCROLL]在网页上有上下两个方向，而在移动设备上有四个方向)。测试时出现训练时未遇到的新动作。为应对这些挑战，采取了以下策略：首先以JSON格式(即{‘action’:’action_type’，’value’:’element’，’position’:[x，y]})结构化每个动作，其中[x，y]表示0-1范围内的相对坐标。这使得能够将不同设备的动作标准化为统一格式。其次，在系统提示中为模型提供了一个”自述文件”，即README，记录了每个动作在动作空间中的用法(例如，’CLICK’:单击一个元素，value不适用，需要提供位置[x，y])。这种设置鼓励模型解释动作空间文档，而不是死记硬背固定动作，使其能够以函数调用的方式在测试时执行动作。接下来，讨论动作与其他模态之间的关系，如图6所示。图6:交替视觉-文本-动作流示意图。截图中的视觉token数量(例如1.3K)远大于查询或动作的token数量(例如少于10个)。因此，引入了两种模式:(1)动作-视觉流，用于UI导航;(b)动作-查询流，用于UI定位。这些模式扩展了多轮对话的概念，使训练数据的利用更有效率。动作与视觉的交互。GUI导航通常涉及多步骤操作序列。模型需要理解当前状态并根据上下文决定下一步动作。这带来了历史信息管理的挑战：单纯的动作序列缺乏视觉上下文，而单纯的截图序列则缺失具体操作信息。为此，构建了交替的视觉-动作流，按时序记录视觉状态和操作行为。每执行完第i个动作后，系统将捕获第(i+1)个截图，并基于此生成第(i+1)个动作。在实际应用中，可根据具体场景选择性地处理视觉历史。例如：移动端：由于跨应用场景下界面变化频繁，保留完整视觉历史很有必要Web端：由于页面相对稳定，可适当省略重复的视觉信息以提高效率动作与文本查询的协同。在一步导航或元素定位中，可能会遇到一个截图对应多个并行动作或多个元素，其中截图往往是高分辨率的，导致token序列很长(例如1-2K个token)。与此同时，诸如UI元素名称和动作(坐标)等查询通常要短得多(通常少于10个token)。这种差异使得一张图像对应一个动作的方式效率低下。为优化训练数据利用率，采用了多轮对话的方式，在单次前向传播中为每个截图预测多个动作注释。GUI指令微调社区中存在各种GUI数据集，主要包括网页数据和移动端数据等，这些数据集可能包含元素坐标或用户交互轨迹。本研究并非简单汇总所有可用数据源，而是分析各类数据集特点后选择具有代表性的数据。ShowUI选择的数据如表1所示。以下主要讨论UI grounding(UI元素定位)数据，而导航任务则采用GUIAct中的移动端和网页设备数据。表1:指令微调数据概述。#Sample表示任务实例的数量(grounding中为截图数量，navigation中为任务数量);#Ele.表示元素的数量(即grounding中的bbox数量);#Cls.表示动作类别数;len.表示每个任务的平均轨迹长度。UI grounding主要数据来源包括三类：网页–视觉元素：网页提供了易于访问且富文本的UI数据源，可以方便地从HTML中爬取。统计分析显示，”静态文本”标签占了很大一部分(40%)。由于大多数VLM已经具备强大的OCR能力，研究重点转向收集视觉丰富的元素。为此，开发了一个解析器，收集了22K张截图，只保留了诸如带有”Button”或”Checkbox”标签的与视觉相关的元素。通过移除静态文本，获得了13K个视觉富元素桌面端–多样化查询：桌面端数据因难以自动收集而显得尤为珍贵。研究团队采用了OmniAct数据集，其包含来自iOS、Windows和Linux桌面的人工标注元素，虽然规模较小(100张图像中包含2K个元素)，且元素仅用原始名称标注(如”message_ash”)。为丰富数据集并增加多样性，采用反向工程技术，结合ground-truth边界框和文本元素，通过GPT-4配合突出目标元素的视觉提示，生成了外观、空间和意图三类查询，如图7所示。这一方法新增了6K个元素样本。在图8中，展示了更多示例，说明如何利用GPT4o基于外观、空间关系和意图为原始OmniAct-Desktop注释增加多样化的查询。移动端–功能性：移动端数据可以在Android上方便获取，其中提供了图标字幕。值得注意的是，Amex数据集包含了超越简单原子元素名称的有价值功能性描述。图7：借助GPT-4o从原始标注中提取了三类查询（外观、空间关系和意图）图8:说明如何基于外观、空间关系和意图为原始OmniAct-Desktop标注增加多样化的查询。数据采样平衡：如表1所示，不同类型数据的规模差异显著(如桌面端仅有100个样本)。为确保各类数据得到公平展现，在训练过程中采用特殊采样策略，使每个batch包含不同数据类型的概率趋于一致。04实验结果评测基准采用以下基准对模型进行全面评估。Grounding（定位能力）任务：采用Screenspot的零样本评估基准进行测试。该基准包含来自三种不同设备的多样化数据集，可分别对模型的文本识别和界面组件识别能力进行评估。Navigation（导航能力）任务：在四个不同设备平台的数据集上评估模型的导航性能：Web端：基于Mind2Web数据集进行评估，其动作空间涵盖三种类型的操作移动端：使用AITW数据集，包含11种不同类型的操作在线环境：采用MiniWob平台进行测试，该环境包含两种类型的操作。这一测试旨在补充离线基准，并验证模型在实时交互环境中的表现详细的训练参数设置和实验细节可参见原始论文中的补充材料。实验结果在视觉元素定位(grounding)任务上，ShowUI在零样本设置下达到了75.1%的准确率，展现出了很强的SOTA性能。在多种导航任务(网页、移动应用、在线环境)中，ShowUI也取得了令人瞩目的成绩，证实了该模型在GUI视觉Agent方面的有效性和潜力。通过消融研究，验证了UI引导的视觉token选择策略的有效性，在训练过程中减少了33%的视觉token冗余，加速了1.4倍。至于具体的实验结果，感兴趣的小伙伴可以进一步阅读原文。05实战环境安装conda create -n showui-py311 “cmake>=3.24” rust git python=3.11conda activate showui-py311git clone https://github.com/showlab/ShowUI.gitcd ShowUIpip3 install -r requirements.txt -i http://mirrors.aliyun.com/pypi/simple/ –trusted-host mirrors.aliyun.com实测：UI定位PC：按钮定位Mac上蓝牙按钮定位(右图红点表示定位到的位置)：Mac上下载按钮定位：手机：按钮定位综上，ShowUI在UI定位上确实相当精准，也支持中文！实测：手机UI导航以下主要测试手机场景下的UI导航。输入图：query = “search luckin coffee” 输出结果：{‘action’: ‘TAP’， ‘value’: None， ‘position’: [0.48， 0.06]}结果图：由于没有做对话管理，直接人工点击进入搜索框，然后将query改为：query = “Input Luckin Coffee”。此时输入图：预期是能够在该搜索框截图下识别INPUT这个Action及其对应的value，但是并没有：{‘action’: ‘TAP’， ‘value’: None， ‘position’: [0.49， 0.06]}结果图：可以看出，在中文app场景下的手机导航效果不佳。或许英文类app的效果会更好？实测：浏览器UI导航以下进行UI导航测试，使用的测试图片：英文query输入query=”Search today’s news”输出结果：{‘action’: ‘CLICK’， ‘value’: None， ‘position’: [0.47， 0.42]}，{‘action’: ‘INPUT’， ‘value’: ‘today’s news’， ‘position’: [0.47， 0.42]}可以看出，缺失了ENTER这个Action。PS：使用官方的范例query = “Search the weather for the New York city.”，输出结果同样缺失ENTER这个Action：{‘action’: ‘CLICK’， ‘value’: None， ‘position’: [0.47， 0.42]}，{‘action’: ‘INPUT’， ‘value’: ‘weather for New York city’， ‘position’: [0.47， 0.42]}这说明，在涉及多个Action方面，不够稳健，存在较大的优化空间。中文query输入query=”搜索今天的新闻”输出结果：{‘action’: ‘CLICK’， ‘value’: None， ‘position’: [0.49， 0.42]}，{‘action’: ‘INPUT’， ‘value’: ‘今天的新闻’， ‘position’: [0.49， 0.42]}06总结本文提出的ShowUI模型通过创新的视觉处理、多模态交互和数据策略，实现了高效的GUI交互。未来可改进方向包括:开发针对在线环境的专门学习策略提升跨域泛化能力增强视觉UI感知能力探索强化学习来增强在线交互能力END点击下方名片即刻关注我们