讓AI像人類一樣操作手機，華為也做出來了

机器之心發表於2024-10-25
AI
用不了多久就要實裝了？

這個星期，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 操縱手機方法的主要限制在於訓練資料有限，這就阻礙了模型在更復雜任務上的能力。下一步研究的目標是透過結合線上學習技術（例如強化學習）來提高模型的效能。

相關文章