大規模言語モデルでモバイルUIと会話型対話できるのか？
3つの要点
✔️ 大規模言語モデル（LLM）を使用して、モバイルUIでの会話型対話の実現可能性を調査する初の論文
✔️ GUIをLLMに入力し、LLMがモバイルUIで様々な会話型対話タスクを実行する一連の方法を提案
✔️ 従来の機械学習手法と同等以上の性能を達成、コードをオープンソース化
Enabling Conversational Interaction with Mobile UI using Large Language Models
written by Bryan Wang, Gang Li, Yang Li
(Submitted on 18 Sep 2022 (v1), last revised 17 Feb 2023 (this version, v2))
Comments: Published as a conference paper at CHI 2023
Subjects: Human-Computer Interaction (cs.HC); Artificial Intelligence (cs.AI)
code：
本記事で使用している画像は論文中のもの、紹介スライドのもの、またはそれを参考に作成したものを使用しております。
概要
日本でも厚生労働省を中心に「アクセシビリティ」が求められています。年齢や身体障害の有無に関係なく、誰でも必要とする情報に簡単にたどり着け、利用できることを目指しています。
この論文では、近年の大規模言語モデル（LLM）の技術進歩を応用して、LLMでモバイルUIを操作する汎用的な手法を提案しています。一般的に、自然言語でさまざまなUIタスクを実行するには特定のタスクごとに個別のデータセットとモデルを作成する必要があり、費用と労力がかかります。しかし、近年、事前学習されたLLMによって、一般化できることが示されています。この論文では、新たなプロンプト手法を適用して、LLMを使用したモバイルUIと会話型対話の実現可能性を調査しています。
この論文では、「Screen Question-Generation」「Screen Summarization」「Screen Question-Answering（QA）」「Mapping Instruction to UI Action」の4つの会話型対話のタスクを調査しています。専用のデータセットや学習を必要とせずに、これらのタスクで既存の機械学習の手法と同等以上の性能を達成し、言語ベースのモバイルインタラクションを可能にする汎用的なアプローチを提案しています。
タスク
この論文では、大規模言語モデルとしてPaLMを使用し、下図の4つのタスクを検証しています。1つ目のタスクは「Screen Question-Generation」です。これは、UI画面内で操作が必要な項目に応じて、エージェントがユーザーに適した質問を生成するタスクです。例えば、旅行サイトのUI画面に「目的地」や「宿泊日」を入力する項目がある場合、「目的地はどこですか？」「宿泊日はいつですか？」などの質問を生成するタスクです。画面が見えない人でも必要項目を把握することができます。
2つ目のタスクは「Screen Summarization」です。これは、UI画面の表示内容を要約してユーザーに伝えるタスクです。例えば、旅行サイトで宿泊可能なホテルの一覧が表示された場合、その内容をユーザーに適切に伝えることが求められます。画面が見えない人でも表示内容を把握することができます。
3つ目のタスクは「Screen Question-Answering（QA）」です。これは、ユーザーがエージェントを介してUI画面の情報を要求すると、エージェントが適した情報を回答するタスクです。例えば、旅行サイトで宿泊可能なホテルの部屋リストが表示されている場合に、ユーザーが「キングサイズのベッドがある部屋の料金はいくらですか？」と質問すると、UI画面の内容に基づいて「1泊330ドルです。」と回答するタスクです。この機能も画面が見えない人に役立ちます。また、膨大な情報から必要な情報だけを取得することができます。
4つ目のタスクは「Mapping Instruction to UI Action」です。ユーザーの要求に応じて適切な画面操作をするタスクです。例えば、ホテルの予約画面で、ユーザーが「予約ボタンをクリックして、キングサイズのベッドがある予約してください。」と要求した場合に、エージェントが対応するボタンをクリックして、予約を完了するタスクです。画面が見えない人、操作できない人に役立ちます。
実験（Screen Question-Generation）
ここでは、ユーザー入力を必要とするUI要素を識別してユーザーに適した質問を生成します。下図は質問を生成するプロンプトの例です。対象のUI画面が与えられると、思考連鎖手法（chain-of-thought）を利用して、「入力が必要なUI要素の数」、「画面の要約」、「入力項目な必要な要素の一覧」を中間結果として生成します。最後に<SOQ>と<EOQ>のトークンで囲まれた質問を生成します。
生成された質問は「文法の正しさ」「UIの関連性」「質問の範囲」の観点で評価されます。「文法の正しさ（Grammar）」は、生成された質問の文法が「どの程度正しいのか？」「読みやすく、自然か？」をリッカート尺度（5段階）で評価しています。「UIの関連性（Relevance）」は、生成された質問が「UI要素と関連しているかどうか」を2段階で評価しています。「質問の範囲（Coverage F1）」は、生成された質問が「画面上の要素をどの程度識別できているか」を評価しています。これはGround Truthの入力要素のタグと、思考連鎖手法で識別されたタグを比較することで自動的に計算しています。結果は下表の通りです。LLMの結果をres_tokensと呼ばれるresource_idの単語を使用して「{res_tokens} とは？」というテンプレートを埋めるルールベースのアプローチ（Template）と比較しています。
TemplateとLLMの両方について、3人の評価者が931の質問を評価しています。「文法の正しさ（Grammar）」は、Templateが平均3.6であるのに対して、LLMは4.98とほぼ完璧な平均スコアを示しています。「UIの関連性（Relevance）」では、LLMがTemplateと比較して8.7%も関連性が高い質問を生成しているという結果です。「質問範囲（Coverage F1）」は、LLMが95.9%（F1 Score）を達成します （Precision = 95.4%、Recall = 96.3%）。
ルールベースのTemplateでは、すべての入力要素に対して質問を生成するため、質問のカバレッジは当然100%になりますが、LLMにおいても入力要素を正確に識別し、十分に関連性の高い質問を生成できていることを示しています。
また、LLMの動作をさらに分析すると、特定の質問を生成するとき、LLMは入力項目の要素と画面コンテキスト（他の画面オブジェクトからの情報）の両方を考慮していることがわかります。下図は2つのUI画面に対して、LLMとTemplateが生成した質問の例です。
左図を見ると、LLMはクレジットカード情報の入力が求められているというコンテキストを利用して、各入力項目に関して、文法的に正しい質問を生成しています。例えば、②はLLMが「credit card expiration date」としている一方で、Templateは「credit」について言及していません。また、③でもLLMは「last 4 digits of SSN」と正確に質問を生成している一方で、Templateは言及していません。
また、右図を見ると、LLMが事前の情報を使用して、関連する複数の入力項目を組み合わせて1つの質問を生成することができる一方で、Templateはできていません。LLMは最小価格の項目と最大価格の項目を組み合わせて、価格範囲について質問する1つの質問を生成できています。
実験（Screen Summarization）
これは、UI画面の表示内容を要約してユーザーに伝えるタスクです。ユーザーがモバイルUIの内容をすばやく理解するのに役立ちます。特に、UI画面を見ることができない場合で役立ちます。プロンプトの例は下図の通りです。ここでは、タスクの中間結果を生成する必要がないため、思考連鎖手法は使用していません。
下図は、人間がラベル付けした要約と、Screen2WordsとLLMの両方が出力した要約を含む画面（例）を示しています。LLMは、San Francisco（左上）やTiramisu Cake Pop（左下）などの要約を作成するために、画面上の特定の（具体的な）テキストを使用する可能性が高いことがわかります。一方、Screen2Wordsは、 より一般的な（抽象的な）内容になっています。
さらに、LLMは画面上の複数の重要な要素を活用する、より拡張された要約を生成する可能性が高くなります。例えば、右上の画面は、LLMがアプリ名、ファイル送信ボタン、および受信者のファックスボタンを利用して、より長い要約を構成していることを示しています（"FaxFile app screen where a user can select a file to send via fax and pick recipients."）。
また、LLMの事前知識が画面の要約に役立つこともわかります。例えば、右下の画面は、ロンドンの地下鉄システムの駅検索結果ページを示しています。 LLMは "Search results for a subway stop in the London tube system."と予測しています。ただし、入力HTMLには「London」も「tube」も含まれていません。したがって、このモデルは、大規模な言語データセットから学習した駅名に関する事前知識を利用して、駅名がロンドンの地下鉄に属していると推測しています。このタイプの要約は、モデルがScreen2Wordsのみで学習された場合には生成されない可能性があり、LLMの優れている点と言えます。
実験（Screen Question-Answering）
ユーザーがエージェントを介してUI画面の情報を要求すると、エージェントが適した情報を回答するタスクです。プロンプトの例は下図の通りです。タスクの中間結果を生成する必要がないため、思考連鎖プロンプトは使用しませんでした。
図（左）は、Screen Question-Answeringの実験結果の例です。図（右）は、Screen Question-Answeringでの性能評価に使用される3つの指標です。回答の正確性を3段階（Exact Match、Contains Ground Truth、Sub-String of Ground Truth）で評価しています。
図（左）を見ると、LLMはベースラインであるDistillBertよりも大幅に優れています。LLMはQ1、Q2、Q4はExact Matchに該当し、正確な回答を生成しています。Q3においても、Contains Ground Truthに該当します。余計に「午前 4 時 50 分」という時間を回答していますが、「Dec 23rd, 2016」というGround Truthを含む回答を生成しています。
一方で、ベースラインであるDistillBertは、Q4において、Exact Matchに該当し、正確な回答を生成しているものの、他の質問に対しては、回答が不足していたり、全く異なっています。Q3は「2016」しか一致していません。また、Q2においては、HTMLのコードを回答しています。
実験（Mapping Instruction to UI Action）
これは、ユーザーの要求に応じて適切な画面操作をするタスクです。例えば、「Gmailを開く」と指示された場合、ホーム画面のGmailアイコンを正しく識別する必要があります。 このタスクも中間結果を生成する必要がないため、思考連鎖手法は使用していません。出力された回答は特別なタグ <SOI> と <EOI> で囲まれ、それぞれ予測された要素 ID の開始と終了を意味します。
プロンプトの例は下図の通りです。ここでは、"Open your device's clock app."という要求に対して、要素ID=29の時計アプリを予測しています。
Wi-Fi設定の切り替えやメールのチェックなど、Google Pixelスマートフォンで日常的なタスクを実行するための187の手順が含まれているPixelHelp データセットを使用しています。プロンプトモジュールとして、データセット内の特定のアプリパッケージごとに1つの画面をランダムにサンプリングしています。次に、プロンプトモジュールからランダムにサンプリングして、最終的なプロンプトを作成し、in-appとcross-appの2つの条件で実験を行っています。in-appでは、プロンプトにはテスト画面と同じアプリパッケージからのプロンプトモジュールが含まれますが、cross-appでは含まれません。
ここでは、ターゲット要素の部分一致（Partial）と完全一致（Complete）の割合を評価指標として利用しています。 結果は下表の通りです。LLMは、0-shotの場合、Partial、Completeともに、ほとんどタスクを実行できないことを示しています。
cross-appでは、1-shotの場合、Partialが74.69、Completeが31.67となっています。つまり、要求された要素の約75%が正しく予測され、30%以上のタスクが完全に正しいことを意味します。2-shotの場合、PartialとCompleteともにわずかですが性能が向上しています。in-appでは、1-shotと2-shotのいずれにおいても、cross-appよりも高いスコアを達成しています。2-shot LLM（in-app）では、Partialが80.36、Completeが45.00を達成しています。
まとめ
この論文では、大規模言語モデル（LLM）としてPaLMを使用して、自然言語でモバイスUI画面とインタラクティブなやり取りができるかどうかの実現可能性を調査しています。LLMがモバイルUI画面とインタラクティブにやり取りするための一連のプロンプト手法を提案し、4つのタスクにチャレンジしています。その結果、従来の機械学習手法と比較して、同等以上の性能を達成することがわかりました。
この記事に関するカテゴリー
