今天是2024年10月29日，星期一，北京，天气晴。
最近这几天，让大模型具备控制电脑和手机的相关研究和应用好像很火，例如智谱的AutoGLM《AutoWebGLM: A Large Language Model-based Web Navigating》(https://github.com/THUDM/AutoWebGLMzarXiv,https://arxiv.org/pdf/2404.03648)，华为的LiMAC《Lightweight Neural App Control》(https://arxiv.org/pdf/2410.17883)，这些都是一种尝试，虽然离真实应用还是很远。
但是，我们可以从技术角度来思考这类场景，设备端的交互，也就是在用户界面内实现感知和交互的无缝自动化，就需要一个复杂的系统，其需要具备一系列关键能力，不仅要能完全理解屏幕内容，还要能关注屏幕内的特定UI元素。此外，它应当有能力进一步将自然语言指令映射到给定UI内对应的动作、执行高级推理并提供其交互的屏幕的详细信息，并针对一个大的目标，给出逐步的交互方案。
因此，本文先一个个看，看三个工作，一个是从实现技术上看设备端Agent的实现思路，一个是苹果的Ferret-UI屏幕理解方案，一个是微软的OmniParser的实现思路，这两个方案都偏向于屏幕理解这个任务，这个是整个交互的基础，我们看看其问题建模方式、数据构建方法，会有一些收获。
多思考，多阅读，会有收获，供大家一起参考。
一、从实现技术上看设备端Agent的实现思路
首先这类需求，需要使用两个主要介绍，一个是UI屏幕理解（UI Screen Understanding）和自主GUI代理（Autonomous GUI Agent）。
1、 UI屏幕理解（UI Screen Understanding）
之前已经有了专注于详细理解用户界面屏幕的建模工作，例如Screen2Words、UI-BERT、WidgetCaptioning和ActionBERT。这些工作展示了多模态模型在提取用户屏幕语义方面的有效性。但是，这些模型依赖于额外的信息，如视图层次结构，或者是为了视觉问题回答任务或屏幕摘要任务而训练的。
此外，也有一些公开可用的UI屏幕理解数据集，最著名的是Rico数据集，它包含了超过66k个独特的UI屏幕及其视图层次结构。后来的工作通过提供基于形状和语义识别各种图标的500k人类注释来增强Rico数据集，并关联选定的通用UI元素（如图标、表单字段、单选按钮、文本输入）和它们的文本标签。
在移动平台上，PixelHelp提供了一个包含跨越88个常见任务的UI元素屏幕的数据集。在同一篇论文中，他们还发布了RicoSCA，这是Rico的一个清理版本。对于Web和通用操作系统领域，有几项工作提供了模拟环境，但没有提供专门用于一般屏幕理解任务的公开数据集，例如在真实网站上检测可交互图标。
2、自主GUI代理（Autonomous GUI Agent）
自主GUI代理Autonomous GUI Agent，以代替人类用户执行任务的工作。一方面，有的工作是训练一个端到端的模型来直接预测下一个动作，代表性的工作包括Pixel2Act、WebGUM、Ferret、CogAgent和Fuyu。另一方面的工作涉及利用现有的多模态模型（如GPT-4V）来执行用户任务。
这些工作通常利用Web浏览器中的DOM信息，或移动应用中的视图层次结构来获取屏幕的可交互元素的真实位置，并使用Set-Of-Marks在屏幕截图上叠加边界框，然后输入到视觉-语言模型中。
然而，当目标是构建一个跨平台和跨应用程序任务的通用代理时，可交互元素的真实信息可能并不总是可用的。因此，作者们专注于提供一种系统化的方法，从通用用户屏幕中获取结构化元素。
二、苹果的Ferret-UI屏幕理解方案
Ferret-U是专门针对UI屏幕设计的用于精确引述和定基任务的MLLM，对于手机屏幕这个场景，还是不一样的，一个是手机屏幕的纵横比（见表 1a）与自然图像的不一样，通常更长一些。其次，UI相关任务涉及很多对象（即图标和文本等UI组件），并且这些组件通常比自然图像中的对象小得多。
《Ferret-UI: Grounded Mobile UI Understanding with Multimodal LLMs》，https://huggingface.co/papers/2404.05719，可以看看几个具像化的例子：
又如：
先看下如下例子：
1）Ferret-UI所处理的任务
图1显示了Ferret-UI能够在移动UI屏幕上执行涉及灵活输入格式（点、框、涂鸦）的指代任务（例如，部件分类、图标识别、OCR）以及定位任务（例如，查找部件、查找图标、查找文本、部件列表）。
这些基本任务为模型配备了丰富的视觉和空间知识，使其能够在粗略和精细层面区分UI类型，例如在各种图标或文本元素之间。
这种基础知识对于执行更高级的任务至关重要。具体而言，Ferret-UI不仅能够通过详细描述和感知对话讨论视觉元素，还能在交互对话中提出以目标为导向的行动，并通过功能推断推断出屏幕的整体功能。
2）对应任务的数据生成方式
基本任务数据生成概览如图3所示，创建了7个新的 UI 任务：用于引述的 OCR、图标识别和小部件分类；用于定基的小部件列表、查找文本、查找图标、查找小部件，并将引述（referring）任务定义为输入中有边界框的任务，而将定基（grounding）任务定义为输出中有边界框的任务。
UI检测器输出所有检测到的元素，包括每个元素的类型、文本和边界框。这些检测结果用于创建基本任务的训练样本。对于定位任务，使用所有元素检测结果来创建一个部件列表的样本，而其余任务则一次关注一个元素。将元素分为图标、文本和非图标/文本部件。对于每种类型，创建一个指代样本和一个定位样本。
对于高级任务数据生成如图4所示，包括详细描述、对话感知、对话交互和功能推断4个任务。
首先对检测输出的边界框坐标进行归一化处理，然后将检测结果、提示和可选的一次性示例发送给GPT-4。对于详细描述和功能推断，将生成的响应与预先选定的提示配对，以训练Ferret-UI。
对于对话任务，直接将GPT-4的输出转换为多轮对话。对应的prompt如下：
3）模型建模
图2：Ferret-UI-anyres架构概览如下：
虽然Ferret-UI-base紧密遵循Ferret的架构，Ferret 包含一个预训练的视觉编码器（如 CLIP-ViT-L/14）和一个仅解码器语言模型（如 Vicuna），但Ferret-UI-anyres加入了额外的细粒度图像特征。
特别是，一个预训练的图像编码器和投影层为整个屏幕产生图像特征。对于根据原始图像纵横比获得的每个子图像，会生成额外的图像特征。对于具有区域引用的文本，视觉采样器生成相应的区域连续特征。大模型使用全图像表示、子图像表示、区域特征和文本嵌入来生成响应。
三、微软的OmniParser的实现思路
这个工作从现在看来还是比较早的，《OmniParser for Pure Vision Based GUI Agent》(https://arxiv.org/abs/2408.00203,https://github.com/microsoft/OmniParser, https://huggingface.co/microsoft/OmniParser)，提出一种通用的纯视觉屏幕解析工具OMNIPARSER，通过解析用户界面截图中的结构化元素，显著提高GPT-4V在操作预测中的性能。
这个工作要解决的问题是如何在用户界面截图中可靠地识别可交互图标，并理解截图中各种元素的语义，从而准确地将预期动作与屏幕上的相应区域关联起来。
但在实现难度上，该问题的研究难点包括：1）在不同操作系统和应用中，如何跨平台识别可交互图标；2）如何在不依赖HTML信息的情况下，准确解析用户界面截图中的元素。
如图1是MNIPARSER解析的屏幕截图图像和局部语义的示例。
又如：
又如：
OmniParse的输入是用户任务和用户界面截图，它将产生：1) 带有叠加边框和数字ID的解析屏幕截图图像，以及2) 包含提取的文本和图标描述的局部语义。
1、可交互区域检测（Interactable Region Detection）
首先，使用流行的网页DOM树提取的可交互图标边界框，构建了一个包含67k张独特屏幕截图图像的数据集。然后，使用YOLOv8模型对该数据集进行微调，以检测屏幕上的可交互图标。
具体的，从流行的网页上收集了67k张独特的屏幕截图图像，并使用DOM树提取了可交互图标的边界框。每个截图中的可交互图标都被标注了边界框，这些边界框用于训练检测模型。
在模型训练上，使用YOLOv8框架在66990张样本上进行训练，其中95%（63641张）用于训练，5%（3349张）用于验证。训练过程中，模型被训练来识别和定位屏幕上的可交互图标，这个在可交互图标数据集上微调的检测模型，可可靠地识别屏幕截图中的可操作区域。
此外，还通过OCR模块，提取文本的边界框，并与图标检测模块的边界框合并，去除重叠度高的框。
2、 融合本地语义描述（Incorporating Local Semantics of Functionality）
一种最直接的方式，就是直接写prompt提示GPT4V来做，如下：
为了提高GPT-4V在特定图标框上预测下一个动作的能力，使用BLIP-v2模型对检测到的图标进行功能描述，这个在图标描述数据集上训练的字幕模型，该模型提取了检测到的元素的功能语义，生成对其预期操作的上下文准确的描述。
在图4中，可以看到原始的BLIP-2模型倾向于描述应用程序图标的形状和颜色，但在识别图标的语义方面却存在困难，所以，在一个图标描述数据集上对此模型进行微调。
这个图标描述数据集，旨在将每个UI元素与其相应功能相关联。该数据集是训练模型了解检测到元素语义的关键组成部分。
对于这个数据集，使用了通过可交互图标检测模型在ScreenSpot数据集上解析出的图标边界框的推断结果，因为它包含了移动设备和PC上的屏幕截图。对于描述部分，询问GPT-4o，呈现在解析边界框中的物体是否是应用程序图标。如果GPT-4o判断图像是图标，它会输出关于图标可能功能的一句描述。如果不是，GPT-4o将输出“这不是一个图标”，但仍然将其包含在数据集中。最终，收集了7185个图标-描述对用于微调。
为了获得这个数据，可以使用如下提示：
3、综合解析
将微调后的可交互区域检测模型、图标描述模型和OCR模块的输出结合起来，生成一个结构化的、类似DOM的用户界面表示，将这个输入到GPT4-V中发现，的确有性能上的提升。
这个是有用的，在包含112个任务的SeeAssign数据集上，GPT-4V在添加局部语义后，正确分配图标ID的能力从0.705提高到0.938。这表明局部语义显著提高了GPT-4V的任务理解能力。
但是，这种串联的方式，存在多个问题：
首先是重复图标/文本的处理，当Omniparser的结果中包含多个重复的图标或文本时，GPT-4V往往无法做出正确的预测。未来的改进可以通过为UI截图中的重复元素添加更细粒度的描述来解决这一问题；
其次是边界框预测的粗粒度，Omniparser在某些情况下无法以正确的粒度检测边界框。例如，OCR模块可能会检测到包含所需文本的较大边界框，但预测的点击点可能位于边界框的中心之外。未来的改进可以通过训练一个结合OCR和可交互区域检测的模型来更好地检测可点击的文本/超链接。
最后是图标的误解释，在某些情况下，相似形状的图标可能具有不同的含义，具体取决于UI截图的上下文。未来的改进可以通过训练一个能够理解整个图像上下文的图标描述模型。
可以看一个具体的例子，如图7失败案例分析所示，所有边界框的标签都仅依赖于屏幕截图。
左图：在解析的屏幕截图中，总共有7个相似的启用按钮，对应于7个不同的闹钟时间。正确的图标ID对应于7:30的闹钟是27。GPT-4V未能做出正确的预测。右图：点击的真实区域是边界框8中的文本“MORE”。可以看到，光学字符识别（OCR）未能检测到加粗的文本“MORE”，而只检测到了包含“MORE”的边界框8。由于预测的点击点是框的中心，所以预测的点击点落在了真实区域之外，这导致了这项任务的失败。
总结
本文主要看了三个工作，一个是从实现技术上看设备端Agent的实现思路，一个是苹果的Ferret-UI屏幕理解方案，一个是微软的OmniParser的实现思路，这两个方案都偏向于屏幕理解这个任务，这个是整个交互的基础，我们看看其问题建模方式、数据构建方法，会有一些收获。
参考文献
1、https://huggingface.co/papers/2404.05719
2、https://github.com/microsoft/OmniParser
关于我们
老刘，NLP开源爱好者与践行者，主页：https://liuhuanyong.github.io。
对大模型&知识图谱&RAG&文档理解感兴趣，并对每日早报、老刘说NLP历史线上分享、心得交流等感兴趣的，欢迎加入社区，社区持续纳新。
加入会员方式：关注公众号，在后台菜单栏中点击会员社区->会员入群加入
