摘要
近年来大型视觉语言模型的成功表明，在推动在用户界面上运行的代理系统方面具有巨大潜力。 但是，我们认为，由于缺乏强大的屏幕解析技术，像 GPT-4V 这样的多模态模型在不同应用程序跨多个操作系统作为通用代理的能力被严重低估了，该技术能够：1) 可靠地识别用户界面中的可交互图标，以及 2) 理解屏幕截图中各种元素的语义，并将预期操作准确地与屏幕上的对应区域相关联。 为了填补这些空白，我们介绍了 OmniParser，这是一种将用户界面屏幕截图解析为结构化元素的综合方法，它显著增强了 GPT-4V 生成可以准确地定位在界面对应区域的操作的能力。 我们首先使用流行的网页和图标描述数据集策划了一个可交互图标检测数据集。 这些数据集被用于微调专门的模型：一个检测模型来解析屏幕上的可交互区域，以及一个字幕模型来提取检测到的元素的功能语义。 OmniParser 显着提高了 GPT-4V 在 ScreenSpot 基准测试中的性能。 在 Mind2Web 和 AITW 基准测试中，OmniParser 仅使用屏幕截图输入，其性能超过了需要屏幕截图之外的额外信息的 GPT-4V 基线。
1 引言
大型语言模型在理解和推理能力方面取得了巨大成功。 最近的一些工作探索了使用大型视觉语言模型 (VLMs) 作为代理来执行用户界面 (UI) 上的复杂任务，目的是完成繁琐的任务以取代人工操作 [YZL+23, YYZ+23, DGZ+23, ZGK+24, HWL+23, YZS+24, WXJ+24, GFH+24, CSC+24]。 尽管结果令人鼓舞，但在创建可广泛使用的代理方面，当前最先进的技术与能够跨多个平台工作的代理之间仍然存在很大差距，例如 Windows/MacOS、IOS/Android 和多个应用程序（Web 浏览器 Office365、Photoshop、Adobe），而之前大多数工作都集中在限制应用程序或平台上。
虽然像 GPT-4V 这样的大型多模态模型以及其他在 UI 数据上训练的模型 [HWL+23, YZS+24, CSC+24] 已证明能够理解 UI 屏幕截图的基本元素，但操作定位仍然是将 LLM 预测的操作转换为屏幕上实际操作的关键挑战之一，无论是键盘/鼠标移动还是 API 调用 [ZGK+24]。 据观察，GPT-4V 无法生成按钮位置的精确 x-y 坐标，标记集提示 [YZL+23] 提议在原始图像上叠加一组边界框，每个边界框都有唯一的数字 ID，作为发送到 GPT-4V 模型的视觉提示。 通过应用标记集提示，GPT-4V 能够将操作定位到具有真实位置的特定边界框中，而不是特定的 xy 坐标值，这极大地提高了操作定位的鲁棒性 [ZGK+24]。 然而，目前使用 SoM 的解决方案依赖于解析的 HTML 信息来提取可操作元素（如按钮）的边界框，这限制了其在网页浏览任务中的使用。 我们的目标是构建一个适用于各种平台和应用的通用方法。
在这项工作中，我们认为之前的纯视觉屏幕解析技术并不令人满意，这导致对 GPT-4V 模型的理解能力被严重低估。 并且，一种可靠的、在通用用户界面上表现良好的基于视觉的屏幕解析方法，是提高代理工作流在各种操作系统和应用程序上的鲁棒性的关键。 我们提出了 OmniParser，这是一种通用的屏幕解析工具，可以将来自 UI 屏幕截图的信息提取到结构化的边界框和标签中，从而提高 GPT-4V 在各种用户任务中进行动作预测的性能。
我们将我们的贡献列举如下：
- 我们使用从流行网页的 DOM 树中提取的边界框，构建了一个可交互区域检测数据集。
- 我们提出了 OmniParser，一种纯粹的基于视觉的用户界面屏幕解析方法，它结合了多个微调模型，以实现更好的屏幕理解和更轻松的接地动作生成。
- 我们在 ScreenSpot、Mind2Web 和 AITW 基准上评估了我们的方法，并证明了在不需除了屏幕截图以外的额外输入的情况下，与原始 GPT-4V 基线相比有了显著改进。
2 相关工作
2.1 UI 屏幕理解
一直以来，人们一直在研究对 UI 屏幕进行详细理解的建模工作，例如 Screen2Words [WLZ+21]、UI-BERT [BZX+21]、WidgetCaptioning [LLH+20]、Action-BERT [HSZ+21]。 这些工作展示了多模态模型在提取用户屏幕语义方面的有效应用。 但是，这些模型依赖于额外的信息，例如视图层次结构，或者被训练用于视觉问答任务或屏幕摘要任务。
还有一些公开可用的数据集，用于 UI 屏幕理解。 最值得注意的是 Rico 数据集 [DHF+17]，它包含超过 66,000 个独特的 UI 屏幕及其视图层次结构。 后来 [SWL+22] 通过在原始的 66k RICO 屏幕上提供 500k 人工标注来增强 Rico，这些标注根据形状和语义识别各种图标，以及选定的一般 UI 元素（如图标、表单字段、单选按钮、文本输入）与其文本标签之间的关联。 同样在移动平台上，PixelHelp [LHZ+20] 提供了一个数据集，其中包含跨越 88 种常见任务的屏幕的 UI 元素。 在同一篇论文中，他们还发布了 RicoSCA，它是 Rico 的一个清理版本。 对于 Web 和通用操作系统领域，有一些工作，例如 Mind2Web [DGZ+23]、MiniWob++[LGP+18]、Visual-WebArena [KLJ+24, ZXZ+24] 和 OS-World [XZC+24]，它们提供模拟环境，但没有明确提供数据集用于一般屏幕理解任务，例如在现实世界网站上检测可交互图标。
为了解决缺乏大规模通用 Web UI 理解数据集的问题，并跟上 UI 设计的快速发展步伐，我们使用 Web 上流行 URL 的 DOM 信息整理了一个图标检测数据集。 该数据集具有图标和按钮的最新设计，其边界框从 DOM 树中检索，提供地面真实位置。
2.2 自主 GUI 代理
最近，在设计自主 GUI 代理以代替人类用户执行任务方面做了很多工作。 一种工作思路是训练一个端到端模型来直接预测下一个动作，代表性作品包括：Web 领域的 Pixel2Act [SJC+23]、WebGUM[FLN+24]，移动领域的 Ferret [YZS+24]、CogAgent [HWL+23] 和 Fuyu [BEH+23]。 另一种工作思路是利用现有的多模态模型，如 GPT-4V 来执行用户任务。 代表性作品包括 Web 领域的 MindAct 代理 [DGZ+23]、SeeAct 代理 [ZGK+24] 以及移动领域的 [YYZ+23, WXY+24, RLR+23] 中的代理。 这些工作通常利用 Web 浏览器中的 DOM 信息或移动应用程序中的视图层次结构来获取屏幕可交互元素的地面真实位置，并使用 Set-Of-Marks [YZL+23] 将边界框叠加在屏幕截图上，然后馈送到视觉语言模型中。 但是，当目标是为跨平台和跨应用程序任务构建一个通用代理时，可交互元素的地面真实信息可能并不总是可用。 因此，我们专注于提供一种系统方法来从通用用户屏幕中获取结构化元素。
3 方法
一个复杂的任务通常可以分解成几个步骤的动作。 每个步骤都需要模型（例如 GPT-4V）具备以下能力：1）理解当前步骤中的 UI 屏幕，即分析屏幕内容的整体情况，以及检测到的标有数字 ID 的图标的功能，2）预测当前屏幕上可能有助于完成整个任务的下一个操作。 我们发现，与其试图在一项调用中完成这两个目标，不如在屏幕解析阶段提取一些信息，例如语义，以减轻 GPT-4V 的负担，使其能够利用解析后的屏幕信息，并更多地关注动作预测。
因此，我们提出了 OmniParser，它集成了来自微调的交互式图标检测模型、微调的图标描述模型和 OCR 模块的输出。 此组合生成一个结构化的、类似 DOM 的 UI 表示，以及一个覆盖了潜在交互式元素的边界框的屏幕截图。 在本节的剩余部分，我们将更详细地讨论 OmniParser 的每个组件。
3.1 交互区域检测
从 UI 屏幕中识别交互区域是推理给定用户任务应执行哪些操作的关键步骤。 我们没有直接提示 GPT-4V 预测它应该操作的屏幕的 xy 坐标值，而是遵循以前的工作，使用 Set-of-Marks 方法 [YZL+23] 在 UI 屏幕截图上覆盖交互式图标的边界框，并要求 GPT-4V 生成要执行操作的边界框 ID。 但是，与 [ZGK+24, KLJ+24] 使用从 Web 浏览器中的 DOM 树检索到的真实按钮位置不同， [YYZ+23] 使用 AITW 数据集 [RLR+23] 中标记的边界框，我们微调了一个检测模型来提取交互式图标/按钮。
具体来说，我们创建了一个交互式图标检测数据集，包含 67,000 张独特的屏幕截图图像，每张图像都用从 DOM 树派生的交互式图标的边界框标记。 我们首先从网上 [OXL+22] 获取了 100,000 个流行的公开可用 URL 的统一样本，并从每个 URL 的 DOM 树中收集了网页的交互区域的边界框。 网页和交互区域的一些示例显示在 2 中。
除了交互区域检测之外，我们还有一个 OCR 模块来提取文本的边界框。 然后，我们合并来自 OCR 检测模块和图标检测模块的边界框，同时移除重叠率高的框（我们使用 90% 作为阈值）。 对于每个边界框，我们使用一个简单的算法在它旁边标记一个唯一的 ID，以最大程度地减少数字标签与其他边界框之间的重叠。
3.2 结合功能的局部语义
我们发现，在许多情况下，仅输入带有边界框和相关 ID 的 UI 屏幕截图叠加会误导 GPT-4V。 我们认为，这种局限性源于 GPT-4V 同时执行识别每个图标的语义信息和预测特定图标框上的下一步操作的复合任务的能力有限。 这也已被其他几项工作观察到 [YYZ+23, ZGK+24]。 为了解决这个问题，我们将功能的局部语义纳入提示，即对于可交互区域检测模型检测到的每个图标，我们使用一个微调模型来生成图标功能描述，对于每个文本框，我们使用检测到的文本及其标签。
我们将在第 4.1 节中对该主题进行更详细的分析。 据我们所知，没有专门针对最新的 UI 图标描述训练的公开模型，并且适合我们的目的，可以为 UI 屏幕截图提供快速准确的局部语义。 因此，我们使用 GPT-4o 策划了一个包含 7k 个图标描述对的数据集，并在该数据集上微调了 BLIP-v2 模型 [LLSH23]。 数据集和训练的详细信息可以在附录 7.1 中找到。 微调后，我们发现该模型在对常见应用程序图标的描述方面更加可靠。 图 4 中可以看出示例。 并且在图 3 中，我们展示了将局部边界框的语义以文本提示的形式与 UI 屏幕截图视觉提示一起纳入是有帮助的。
图 1： 由 OmniParser 解析的屏幕截图图像和局部语义的示例。 OmniParse 的输入是用户任务和 UI 屏幕截图，它将生成：1) 解析后的屏幕截图图像，其中包含叠加的边界框和数字 ID，以及 2) 局部语义，包括提取的文本和图标描述。
图 2： 可交互区域检测数据集的示例。 这些边界框基于从网页的 DOM 树中提取的可交互区域。
4 实验与结果
我们在几个基准数据集上进行了实验，以证明 OmniParser 的有效性。 我们首先通过一个激励性实验表明，当前的 GPT-4V 模型使用一组标记提示 [YZL+23] 很容易错误地将标签 ID 分配给所指的边界框。 然后，我们在 Seeclick 基准数据集和 Mind2Web 上进行评估，以进一步展示 OmniParser 结合局部语义可以提高 GPT-4V 在不同平台和应用上针对真实用户任务的性能。
4.1 在 SeeAssign 任务上的评估
为了测试 GPT-4v 模型在给定边界框描述的情况下正确预测标签 ID 的能力，我们手工制作了一个 SeeAssign 数据集，该数据集包含 112 个任务，包含来自 3 个不同平台的样本：移动设备、桌面和 Web 浏览器。 每个任务都包含一个简明的任务描述和一个屏幕截图图像。 任务描述是手动创建的，我们确保每个任务都引用一个检测到的边界框，例如，“点击‘设置’”， “点击最小化按钮”。 在评估过程中，GPT-4V 被提示预测与其关联的边界框 ID。 详细的提示在附录中指定。 任务屏幕截图图像来自 ScreenSpot [CSC+24] 基准数据集，其中使用 OmniParser 对它们进行标记。 这些任务根据难度进一步分为 3 个子类别：简单（少于 10 个边界框）、中等（10-40 个边界框）和困难（超过 40 个边界框）。
从表 1 中，我们可以看到 GPT-4V 经常错误地将数字 ID 分配给表格，尤其是在屏幕上有大量边界框的情况下。 通过添加局部语义（包括框内的文本和检测到的图标的简短描述），GPT-4V 正确分配图标的能力从 0.705 提高到 0.938。
从图 3 中，我们可以看到，如果任务中没有描述所指图标，GPT-4V 经常无法将任务中所需的图标与 SoM 标记屏幕截图中的真实图标 ID 关联起来，从而导致响应出现幻觉。 通过在文本提示中添加细粒度的局部语义，GPT-4V 可以更轻松地找到所引用图标的正确图标 ID。
图 3： 来自 SeeAssign 评估的示例。 我们可以看到，细粒度的局部语义提高了 GPT-4V 为所引用图标分配正确标签的能力。
| Easy | Medium | Hard | Overall | |
|---|---|---|---|---|
| GPT-4V w.o. local semantics | 0.913 | 0.692 | 0.620 | 0.705 |
| GPT-4V w. local semantics | 1.00 | 0.949 | 0.900 | 0.938 |
表 1： GPT-4V 有无局部语义的比较
4.2 在 ScreenSpot 上的评估
ScreenSpot 数据集 [CSC+24] 是一个基准数据集，包含来自移动设备（iOS、Android）、桌面设备（macOS、Windows）和 Web 平台的 600 多个界面截图。 任务指令是手动创建的，以便每个指令都对应于 UI 屏幕上的一个可操作元素。 我们首先使用这个基准评估 omniparser 的性能。 在表 2 中，我们可以看到，在移动、桌面和 Web 这三个平台上，omniparser 显着地提高了 GPT-4V 的基线。 值得注意的是，omniparser 的性能甚至超过了专门针对 GUI 数据集进行微调的模型，包括 SeeClick、CogAgent 和 Fuyu，而且差距很大。 我们还注意到，加入局部语义（表中 omniparser w. LS）进一步提高了整体性能。 这与第 4.1 节中的发现相一致，即在文本格式中加入 UI 截图的局部语义，即添加 OCR 文本和图标边界框的描述，可以进一步帮助 GPT-4V 准确地识别要操作的正确元素。 此外，我们的研究结果表明，我们微调的交互区域检测（ID）模型与使用原始 Grounding DINO 模型相比，将整体准确率提高了 4.3%。 这强调了准确检测交互元素对于 UI 任务成功的意义。 总的来说，结果表明，GPT-4V 的 UI 屏幕理解能力被严重低估了，并且可以通过更准确的可交互元素检测以及功能性局部语义的结合得到极大的提高。
| Methods | Model Size | Mobile | Desktop | Web | Average |
|---|---|---|---|---|---|
| Text | Icon/Widget | Text | Icon/Widget | ||
| Fuyu | 8B | 41.0% | 1.3% | 33.0% | 3.6% |
| CogAgent | 18B | 67.0% | 24.0% | 74.2% | 20.0% |
| SeeClick | 9.6B | 78.0% | 52.0% | 72.2% | 30.0% |
| MiniGPT-v2 | 7B | 8.4% | 6.6% | 6.2% | 2.9% |
| Qwen-VL | 9.6B | 9.5% | 4.8% | 5.7% | 5.0% |
| GPT-4V | - | 22.6% | 24.5% | 20.2% | 11.8% |
| OmniParser (w.o. LS, w. GD) | - | 92.7% | 49.4% | 64.9% | 26.3% |
| OmniParser (w. LS + GD) | - | 94.8% | 53.7% | 89.3% | 44.9% |
| OmniParser (w. LS + ID) | - | 93.9% | 57.0% | 91.3% | 63.6% |
表 2： ScreenSpot 基准测试中不同方法的比较。 LS 代表功能性局部语义，GD 代表 Grounding DINO，ID 代表我们微调的可交互区域检测模型。
4.3 Mind2Web 上的评估
为了测试 OmniParser 如何帮助网页导航场景，我们在 [DGZ+23] 基准测试上进行评估。 测试集中有 3 种不同类型的任务：跨域、跨网站和跨任务。 我们使用从原始 HTML 转储处理的 Mind2Web 测试集的清理版本，该版本消除了少数具有不正确边界框的样本。 总共有 867 个、167 个和 242 个任务分别来自测试集中的跨域、跨网站和跨任务类别。 在评估期间，我们将解析后的屏幕结果和操作历史记录作为文本提示以及 SOM 标注的屏幕截图提供给 GPT-4V，类似于 [YYZ+23, ZGK+24] 中的提示策略。 遵循原始论文，我们进行离线评估，重点关注元素准确性、操作 F1 和跨任务的平均步骤成功率。
在表格的第一部分（第 1-3 行），我们报告了一组开源 VL 模型的数字，如 [ZGK+24, CSC+24] 中所示。 在这里，CogAgent 和 Qwen-VL 没有在 Mind2Web 训练集上进行微调。 有关模型设置的更详细的信息可以在附录 7.4 中找到。
在表格的第二部分（第 4-9 行），我们报告了 Mind2web 论文 [DGZ+23] 和 SeeAct [ZGK+24] 论文中的数字。 在这一部分中，所有方法都使用在 Mind2Web 训练集上微调的元素建议模型选定的 HTML 元素，该模型根据用户任务在 HTML 页面上生成前 50 个相关元素。 此外，GPT-4V+SOM 和 GPT-4V+ 文本选择分别对应于带有图像注释的 SeeAct 以及文本选择接地方法。 在 GPT-4V+SOM 中，一组标记 (SOM) 框从元素提议模型中选择，并用从 HTML 中提取的真实位置进行标记。 相反，GPT-4V+ 文本在文本提示中直接使用所选相关元素的 DOM 信息，而不是在屏幕截图上叠加边界框。 文本选择的更好性能与 4.1 中的实验结果相吻合。
在最后一部分（第 10-11 行），我们报告了来自 OmniParser 的数字。 我们观察到，在所有类别中，使用图标功能的局部语义和微调的可交互区域检测模型（w. LS + ID）增强了 GPT-4V，其性能优于使用原始接地 DINO 模型（w. LS + GD）的模型。
此外，在不使用解析后的 HTML 信息的情况下，OmniParser 能够在每个子类别中以较大的优势超越使用 HTML 的 GPT-4 的性能，这表明 OmniParser 提供的屏幕解析结果具有显著优势。 此外，OmniParser 以较大优势优于 GPT-4V+SOM。 与 GPT-4V+ 文本选择相比，OmniParser 在跨网站和跨域类别中明显优于 (+4.1% 和 +5.2%)，而在跨任务类别中略微低于 (-0.8%)，这表明 OmniParser 提供的质量比来自 DOM 的真实元素信息以及 GPT-4V+ 文本选择设置中使用的 top-k 相关元素提议要高，并且使 GPT-4V 更容易做出准确的动作预测。 最后，使用 GPT-4V 的 OmniParser 明显优于所有其他仅使用 UI 屏幕截图（例如 SeeClick 和 Qwen-VL）的训练模型。
| Methods | Input Types | Cross-Website | Cross-Domain | Cross-Task |
|---|---|---|---|---|
| HTML free | image | Ele.Acc | Op.F1 | |
| CogAgent | ✓ | ✓ | 18.4 | 42.2 |
| Qwen-VL | ✓ | ✓ | 13.2 | 83.5 |
| SeeClick | ✓ | ✓ | 21.4 | 80.6 |
| MindAct (gen) | × | × | 13.9 | 44.7 |
| MindAct | × | × | 42.0 | 65.2 |
| GPT-3.5-Turbo | × | × | 19.3 | 48.8 |
| GPT-4 | × | × | 35.8 | 51.1 |
| GPT-4V+som | × | ✓ | - | - |
| GPT-4V+textual choice | × | ✓ | 38.0 | 67.8 |
| OmniParser (w. LS + GD) | ✓ | ✓ | 41.5 | 83.2 |
| OmniParser (w. LS + ID) | ✓ | ✓ | 41.0 | 84.8 |
表 3： 在 Mind2Web 基准上，不同方法在各个类别中的比较。
4.4 在 AITW 上的评估
除了对多步骤网页浏览任务的评估之外，我们还评估了在移动导航基准 AITW [RLR+23] 上的 OmniParser，其中包含 30k 条指令和 715k 条轨迹。 我们使用与 [CSC+24] 中相同基于指令的训练/测试划分，该划分仅保留每条指令的一条轨迹，并且训练和测试之间没有交集。 为了公平比较，我们仅使用其测试集进行评估，并丢弃训练集，因为我们的方法不需要微调。
在表 4中，我们报告了 [YYZ+23] 论文中的 GPT-4V 基线，它对应于性能最佳的设置（GPT-4V ZS+history），该设置使用 IconNet [SWL+22] 通过一组标记提示 [YZL+23] 在评估的每一步检测到的 UI 元素，用于每个屏幕截图。 检测到的 UI 元素由 OCR 检测到的文本或图标类标签组成，后者是 IconNet 识别的 96 种可能的图标类型之一。 此外，在每一步的提示中也加入了操作历史。 我们使用了与 [YYZ+23] 中完全相同的提示格式，只是用微调的交互区域检测 (ID) 模型的输出替换了 IconNet 模型的结果。 有趣的是，我们发现 ID 模型可以很好地推广到移动屏幕。 通过用我们在收集的网页上微调的交互区域检测 (ID) 模型替换 IconNet，并结合图标功能的局部语义 (LS)，我们发现 OmniParser 在大多数子类别中都取得了显著的性能提升，与性能最佳的 GPT-4V + history 基线相比，总体得分提高了 4.7%。
| Methods | Modality | General | Install | GoogleApps | Single | WebShopping | Overall |
|---|---|---|---|---|---|---|---|
| ChatGPT-CoT | Text | 5.9 | 4.4 | 10.5 | 9.4 | 8.4 | 7.7 |
| PaLM2-CoT | Text | - | - | - | - | - | 39.6 |
| GPT-4V image-only | Image | 41.7 | 42.6 | 49.8 | 72.8 | 45.7 | 50.5 |
| GPT-4V + history | Image | 43.0 | 46.1 | 49.2 | 78.3 | 48.2 | 53.0 |
| OmniParser (w. LS + ID) | Image | 48.3 | 57.8 | 51.6 | 77.4 | 52.9 | 57.7 |
表 4: 不同方法在 AITW 基准测试中跨各种任务和整体性能的比较。
5 讨论
在本节中，我们将讨论 OmniParser 的几个常见失败案例，并提供示例和潜在改进方法。
重复的图标/文本 通过分析 GPT-4V 的响应日志，我们发现当 OmniParser 的结果包含多个重复的图标/文本时，GPT-4V 往往无法做出正确的预测，如果用户任务需要点击其中一个按钮，则会导致失败。 附录中的图 7（左）对此进行了说明。 对此问题的一个可能的解决方案是在 UI 屏幕截图中重复的元素添加更细粒度的描述，以便 GPT-4V 能够意识到重复元素的存在，并在预测下一个操作时将其考虑在内。
粗糙的边界框预测 OmniParser 的一个常见失败案例是它无法以正确的粒度检测边界框。 在图 7（右）中，任务是点击文本“更多”。 OmniParser 的 OCR 模块检测到文本边界框 8，它包含所需的文本。 但是，由于它使用盒子的中心作为预测的点击点，因此它超出了真实边界框。 这实际上是因为我们使用的 OCR 模块没有关于哪些文本区域是超链接和可点击的概念。 因此，我们计划训练一个将 OCR 和可交互区域检测合并到一个模块中的模型，以便它能够更好地检测可点击的文本/超链接。
图标误解 我们发现，在某些情况下，具有相似形状的图标可能具有不同的含义，具体取决于 UI 屏幕截图。
