屏幕智能GUI Agent開源新秀技術解讀&實戰

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點擊下方名片即刻關注我們