用不了多久就要實裝了？
這個星期，AI 大模型突然邁上了一個新台階，竟開始具備操作計算機的能力！
從 AI 創業公司，科技巨頭到手機廠商，都紛紛亮出了自己的新産品。
先是微軟發布了商業智能體，随後 Anthropic 推出了升級版大模型 Claude 3.5 Sonnet。它能夠根據用戶指令移動光标，輸入信息，像人一樣使用計算機。
甚至已經有人基于 Claude 3.5 Sonnet 的這個功能開發出了驗證碼破解工具 —— CAPTCHA 這個原本用來分辨人類與 bot 的驗證機制已然擋不住 AI 了。在 X 用戶 @elder_plinius 分享的這個示例中，Claude 突破了 Cloudflare 爲 OpenAI 提供的驗證碼服務，讓其相信自己是一個人類，然後成功打開了 ChatGPT 的聊天窗口。
據介紹，其實現起來也非常簡單，就是在系統指令中設定：當看見 CAPTCHA 時，就點擊有灰色邊框的白色方塊中心。
就在同一天，榮耀正式推出了 MagicOS 9，通過 AI 智能體開啓了「自動駕駛」手機的新模式。隻需要跟語音助手說我要點杯美式，AI 就會自動點開美團，選擇瑞幸的門店下單，你隻需要最後點擊付款就可以了。
這時候就有人問了： 鴻蒙什麽時候跟進？
其實最近，華爲的一些研究也正在探索這一領域。
我們知道，要讓 AI 操控手機，基于手機屏幕的 UI 元素等視覺信息來實現是一種非常通用的解決思路。用 GPT-4o 和 Claude 等大型模型固然能做到這一點，但問題在于使用成本比較高，而且響應速度也不佳，不太适合日常應用。
針對這些問題，華爲諾亞方舟實驗室和倫敦大學學院（UCL）汪軍團隊提出了一個手機控制架構：Lightweight Multi-modal App Control，即輕量級多模态應用控制，簡稱 LiMAC。
論文标題：Lightweight Neural App Control
論文地址：https://arxiv.org/pdf/2410.17883
該架構結合了 Transformer 網絡和一個小型的微調版 VLM。首先，由一個緊湊型模型（約 500M 參數量）處理任務描述和智能手機狀态，該模型可以有效地處理大部分動作。對于需要自然語言理解的動作（比如撰寫短信或查詢搜索引擎），就會調用一個 VLM 來生成必需的文本。這種混合方法可減少計算需求并提高響應能力，從而可顯著縮短執行時間（速度可提高 30 倍，平均每個任務隻需 3 秒）并提高準确度。
LiMAC 框架簡介
首先給出定義，對于用戶的目标 g 和手機在時間 t 的狀态，LiMAC 會使用 Action Transformer（AcT）來進行處理，以确定一個動作類型 a^type_t。如果預測得到的類型是 input-text 或 open-app 中的一個，則将 g、o_t 和 a^type_t 傳遞給一個經過微調的 VLM，其負責确定具體的動作 a^spec_t。
對于需要「點擊」的動作，AcT 會直接處理所有預測，但采用了一個不同的訓練目标，即對比 UI 元素嵌入以确定最可能交互的目标。
模型輸入
AcT 是負責預測動作類型的模型（之後還會點擊目标），其是基于一種經典 Transformer 架構構建的。但不同于标準 Transformer（其 token 是文本或字符），AcT 的 token 是映射到 Transformer 的隐藏維度的預訓練的嵌入。如圖 1 所示。
這些 token 表示了三個關鍵元素：用戶的目标 g、手機屏幕上的 UI 元素 o_{t,i} 和可能的動作。
通過使用這些預訓練的嵌入作爲輸入，該框架允許模型有效地捕獲用戶意圖、界面的當前狀态和可用動作集之間的關系。在該設計中，每種關鍵元素（UI 元素、動作和目标）都會被該 Transformer 處理成嵌入。每種元素的詳細編碼過程請訪問原論文。此外，爲了表示時間信息，該團隊還爲各個時間步驟的所有嵌入添加了一個可學習的位置編碼 p_t。
構建輸入序列
生成目标、UI 元素和動作嵌入後，需要将它們組織成一個代表整個交互事件（episode）的序列。數據集中的每個交互事件都被編碼爲嵌入序列 x，然後輸入到 Transformer 中。
該序列始于目标嵌入 e_g，然後是時間步驟 0 處的 UI 元素嵌入 e^ui_{0,i}，編碼所有 UI 元素之後，将添加一個特殊的結束标記 e^end。之後，再加上時間步驟 0 處的動作類型 e^type_0 和規範 e^spec_0 嵌入。每個後續時間步驟都會重複這一過程：編碼 UI 元素、附加 e^end 并添加動作嵌入。對于具有 H 個時間步驟的交互事件，最終序列爲：
在訓練過程中，會将完整序列輸入到該 Transformer。對于時間步驟 t 處的推理，則是處理直到第 t 次觀察的序列，并使用隐藏狀态 h_t（直到 e^end）來預測動作。
動作類型預測
在該工作流程中，對下一個動作的預測始于确定其動作類型。
預測動作類型 a^type_t 的任務可被描述爲一個分類問題 —— 具體來說，這裏包含 10 個不同的動作類型。這些動作類型代表各種可能的交互，例如單擊、打開應用、向下滾動、輸入文本或其他基本命令。
該團隊使用專門的 head 來實現動作類型預測。動作類型 head（記爲 f_type）可将 Transformer 的最終隐藏狀态 h_t（在 e^end token 之後）轉換爲可能動作類型的概率分布：
此任務的學習目标是最小化預測動作類型和實際動作類型之間的交叉熵損失。給定數據集 D，動作類型預測的交叉熵損失定義爲：
使用經過微調的 VLM 生成動作執行中的文本
如上所述，該智能體首先會預測動作類型。在十種動作類型中，有兩種需要文本：input-text 和 open-app 動作。顧名思義，input-text 動作就是将文本輸入到一個文本框中，而 open-app 動作需要指定要打開的應用的名稱。
對于這些動作，該團隊使用了一個應用控制數據集來微調 VLM。該數據集以類似字典的格式提供動作數據，例如：{"action-type":"open-app","app-name":"Chrome"}，其中一個鍵對應于動作類型，另一個對應于具體動作。
這個 VLM 的訓練目标是生成一個 token 序列并使該序列正确對應于每個動作的成功完成，從而根據每個時間步驟的觀察結果優化生成正确 token 的可能性。
在推理過程中，AcT 預測動作類型後，它會引導 VLM，做法是強制模型以預測的動作類型開始響應。
舉個例子，如果 AcT 預測的動作類型是 input-text，則會強制讓 VLM 按以下 token 模型開始給出響應：{"action-type":"input-text","text":
然後，該 VLM 會繼續補全這個具體動作，得到 a^spec_t，這是動作所需的文本内容。完整的動作選擇流程如圖 2 所示。
使用對比目标和 AcT 實現高效的點擊定位
在介紹了如何爲文本操作生成操作規範之後，我們再轉向點擊操作的情況，其中規範是與之交互的 UI 元素。
爲了預測點擊操作的正确 UI 元素，該方法采用了一種在整個情節中運行的對比學習方法，使用餘弦相似度和可學習的溫度參數。由于 UI 元素的數量随時間步長和情節而變化，因此對比方法比分類更合适，因爲分類在處理測試情節中比訓練期間看到的更多的 UI 元素時可能會受到類别不平衡和限制的影響。
讓 h^type_t 成爲 Transformer 的最後一個隐藏狀态，直到嵌入 e^type_t ，f_target 是将隐藏狀态投影到嵌入空間的仿射變換。同時，與 UI 元素嵌入相對應的 Transformer 的隐藏狀态（表示爲 h^ui）也被投影到相同的嵌入空間中：
假設嵌入空間位于 ℝ ^d 中，查詢嵌入 q^type_t 的維度爲 1 × D，而表示所有 UI 元素的矩陣 p^ui 的維度爲 K × D，其中 K 是交互事件中的 UI 元素總數。目标是訓練模型，使 q^type_t 與時間步驟 t 處的正确 UI 元素嵌入緊密對齊，使用餘弦相似度作爲對齊度量。爲了實現這一點，該團隊采用了對比訓練技術，并使用 InfoNCE 損失。我們首先計算查詢嵌入 q^type_t 與所有 UI 元素嵌入之間的相似度矩陣，并通過可學習參數 τ 縮放相似度。縮放餘弦相似度矩陣定義爲：
其中，
是 p 的每一行的 L2 範數。 爲了簡單，這裏去掉了上标。 于是，交互事件中 UI 元素選擇的 InfoNCE 損失的計算方式如下：
其中，S+ 是 Transformer 的輸出與點擊操作的正确 UI 元素之間的縮放相似度，S_i 表示輸出與所有其他 UI 元素之間的相似度。 在推理過程中，對于每個需要目标元素的操作，都會選擇相似度最高的 UI 元素。 這種對比方法使 AcT 能夠通過将情節中的所有其他 UI 元素視爲反面示例，有效地了解在點擊操作期間要與哪些 UI 元素進行交互。 餘弦相似度的使用側重于嵌入的方向對齊，而可學習溫度 τ 則在訓練期間調整相似度分布的銳度，從而允許更靈活、更精确地選擇 UI 元素。
實驗
在實際工作的驗證中，作者主要考察了兩個開放的手機控制數據集 AndroidControl 和 Android-in-the-Wild（AitW）。 這兩個數據集都包含大量人類演示的手機導航，涵蓋各種任務。
表 1： 在 AitW 和 AndroidControl 數據集上，模型的平均推理時間和總體準确度的比較。 該表顯示了每個模型的大小、平均推理時間（以秒爲單位，數字越小越好）以及兩個數據集的總體準确度（數字越大越好）。 T3A 和 M3A 是基于 GPT-4 操縱的基線。
下圖展示了一些成功和失敗的案例。
圖 4：黃色表示目标元素（時間步驟 3），紅色表示失敗的操作（最後時間步驟）。在最後時間步驟中，代理輸入文本「底特律」而不是「拉斯維加斯」，這明顯混淆了目标中所述的旅行的出發地和目的地，導緻預測錯誤。
圖 5：黃色表示輸入文本（時間步驟 4），整體成功。
綜上所述，LiMAC 作爲一個解決應用程序控制任務的輕量級框架，可以從手機屏幕中提取 UI 元素，并使用專門的視覺和文本模塊對其進行編碼，然後預測下一個操作的類型和規格。
對于需要文本生成的操作，LiMAC 也可以使用經過微調的 VLM 來确保成功完成。将 LiMAC 與由最先進的基礎模型支持的六個基線進行比較，并在兩個開源數據集上對它們進行評估。結果表明，LiMAC 可以超越基線，同時在訓練和推理方面所需的計算時間明顯減少。這表明 LiMAC 能夠在計算能力有限的設備上處理任務。
作者表示，目前 AI 操縱手機方法的主要限制在于訓練數據有限，這就阻礙了模型在更複雜任務上的能力。下一步研究的目标是通過結合在線學習技術（例如強化學習）來提高模型的性能。
