Screen2Words: Automatic Mobile UI Summarization with Multimodal Learning

https://arxiv.org/abs/2108.03353
2021 UIST'21

モバイルユーザインタフェース要約は、モバイル画面の重要なコンテンツや機能を伝えるための簡潔な言語記述を生成するものであり、多くの言語ベースのアプリケーションシナリオに有用である。我々は、画面の重要な情報を自動的に一貫した言語フレーズにカプセル化する新しい画面要約アプローチであるScreen2Wordsを発表する。モバイル画面の要約には、テキスト、画像、構造、およびUIセマンティクスを含むモバイルUIのマルチモーダルデータの全体的な理解が必要であり、我々のマルチモーダル学習アプローチの動機となっている。我々は、人間の作業者によってアノテーションされた大規模な画面要約のデータセットを収集し、分析しました。このデータセットには、約22,000のユニークなUI画面に対して112,000以上の言語が要約されています。次に、様々な構成のディープモデルを用いて実験を行いました。これらのモデルを自動精度指標と人間の評価の両方で評価した結果、我々のアプローチがモバイル画面用の高品質な要約を生成できることがわかりました。また、Screen2Wordsの潜在的な使用例を示し、言語とユーザーインターフェースの橋渡しをするための基礎を築くために、データセットとモデルをオープンソース化しました。

https://github.com/google-research/google-research/tree/master/screen2words

1 はじめに

モバイルユーザインタフェース画面には、ユーザが1つまたは複数の機能を果たすことができる、豊富なグラフィカルコンポーネントが含まれていることが多い。 UI画面についての簡潔な言語記述は、多くの言語ベースのアプリケーションシナリオに役立ちます。例えば、スクリーンサマリーは、会話エージェントとエンドユーザの両方が、言語を介してモバイルタスクを達成する際に、スクリーンの目的と状態を容易に把握することを可能にする[25, 26]。画面要約は、スクリーンリーダーが各要素をスキャンするのを待つことなく、スクリーンリーダーのユーザーが未知のモバイルUIのメンタルモデルを素早く確立するのを助けるために発表することができる。[19, 37]. より広く言えば、柔軟性と汎用性の高い言語でUI画面を表現することは、2つのコミュニケーション媒体の長所を組み合わせるための多くの機会を開きます。しかし、既存のアプリケーションでは、画面の要約はほとんど存在しません。また、ユーザーインターフェースは非常に多様で動的であるため、手動で画面要約を作成することは困難です。

そこで本研究では、UI画面を意味的に理解し、コンパクトで情報量の多い言語表現を生成するタスクである、自動画面要約に注目しています。自動画面要約は、画像キャプション[47]やテキスト要約[31]と似ていますが、モバイル画面が持つマルチモーダル1データの全体的な理解を必要とするという点でユニークです。既存の研究では、深層学習を用いてマルチモーダルなUIデータをベクトル表現にエンコードすることが検討されており[24]、これはUI検索などの様々な下流のタスクに有用であることが示されている[4, 16]。しかし、学習された意味表現と、人間のユーザとコミュニケーションできる自然言語との間のギャップを埋めるための取り組みはほとんど行われていない。一方、最近の研究[28, 50]では、マルチモーダルなデータソースを考慮することで、モバイル画面上のアイコンやウィジェットのalt-textラベルを予測しているが、それらは個々のコンポーネントに焦点を当てており、モバイルUI画面全体を説明できるフレーズを生成していないため、より困難な課題となっている。

本論文では、モバイルUIで提示される複雑な情報を簡潔な言語記述にカプセル化するための新しい生成アプローチであるScreen2Wordsを紹介します。 Screen2Wordsの開発のために、我々は初の大規模な画面要約データセットを収集した。これは、モバイル画面の公開コーパスであるRICO[7]からサンプリングした22,417個のAndroid UI画面に対する人間のアノテーションからなる。深層学習を用いたGUIセマンティクスの表現に関する最近の研究[4, 16, 24, 28]にヒントを得て，Screen2Wordsデータセットで一連の深層モデルを用いた実験を行い，画面要約に対する我々のアプローチの実現可能性と有効性を調べた．これらのモデルを，画像キャプションや機械翻訳のタスクで一般的に使用される一連の精度指標に基づいて評価した．その結果，すべての深層モデルがヒューリスティックな手法よりも優れていることがわかった．また、モデルのバリエーションを比較したところ、UI画面に関するマルチモーダルなデータソースを使用することで、優れた要約精度が得られることが分かりました。最も優れた結果が得られたのは，Transformer エンコーダ・デコーダモデル [42] と ResNet [14] を組み合わせて使用し，UI のテキスト，画像，構造などの複数のデータモダリティを活用した場合であった．

さらに，Mechanical Turkを用いて，さまざまなモデルのバリエーションとヒューリスティックなベースラインによって生成された要約に対する人間の評価を得た．その結果，主観的な評価において，我々の完全なモデルが他のすべての手法よりも優れていることがわかった．

最後に、Screen2Wordsから恩恵を受ける可能性のあるアプリケーションについて議論する。このタスクは、モバイル画面全体の言語記述を生成することで、画面理解と言語生成に関する先行研究を拡張するものである。このタスクは、言語ベースのインタラクションに重要な意味を持ちます。

我々は、UI画面の要約に特化した最初のデータセットを収集、分析し、オープンソース化した2。このデータセットには、22,417個のAndroid画面に対する112,085個の高品質な人間のアノテーションが含まれており、慎重に設計されたラベル付けプロセスとガイドラインによって収集されています。
このモデルは、言語の一貫性と画面上のフォーカスエリアの一貫性の両方において、ラベラー間の高い一致を実現しています。その結果、我々の完全なモデルは、自動測定基準と主観的な評価の両方において、ヒューリスティックなベースラインとモデルの亜種のすべてを大幅に上回り、Screen2Wordsを用いた我々のアプローチを検証した。
このデータセット、モデル、実証結果は、ユーザーインターフェースと自然言語の架け橋となる今後の研究のための確固たるベンチマークとなります。

2 関連研究

本研究では，データセットとモデルの両方を開発し，単一および複数のモーダルコンテンツの要約，深層学習を用いたモバイル画面の理解，モバイルUIデータセットなど，いくつかの既存の研究分野に基づいている．

2.1 単峰性および多峰性コンテンツの要約

テキスト文書の要約[15, 33]やビデオキャプション[5, 10, 44]などの自動コンテンツ要約は、その豊富な用途から、過去数十年にわたって広く研究されてきた。最新の要約技術では，一般的に深層学習モデルを用いてコンテンツの基本的な表現を符号化し，短くて有益なテキスト要約を生成している．例えば、テキスト要約[35, 49]は大規模な文書の簡潔な要約を生成し、画像キャプション[45, 48]は入力画像を説明する自然言語のキャプションを生成します。多くの実世界のデータは本質的にマルチモーダルであるため、複数のデータモダリティを使用する要約技術も広く研究されている[11, 52, 53]。 UI画面の要約は、スクリーンショット画像、テキスト、モバイルUIの構造情報など、複数のデータソースからの入力を利用するため、マルチモーダル要約タスクとして定式化した。このタスクは、コンテンツの自動要約の問題領域に貢献し、言語ベースの人間とコンピュータのインタラクション問題のクラスを向上させる可能性があります。

2.2 深層学習を用いたモバイル画面理解

深層モデルを用いてモバイルUIの潜在的な表現を学習することへの関心が高まっており[4, 16, 24, 27, 28, 41]、これを画面理解と呼んでいる。例えば，Screen2Vec [24] は，テキストコンテンツ，画面のビジュアルデザインとレイアウトパターン，アプリのメタデータを用いて，モバイルUIの表現を学習する自己教師付きアプローチを採用しています．画面の理解は、多くの下流のタスクにとって重要であることがわかっています。例えば、TapShoe [41]は、UIのスクリーンショットをCNNでエンコードすることで、UI要素がタップ可能かどうかを予測しています。同様に、VINS [4]はUIデザインとワイヤーフレームをエンコードし、コンテンツベースのUI検索を可能にします。 Swire [16]は、スケッチとUI画像の両方をエンコードすることで、デザイナーがスケッチしたUIデザインを検索できるようにします。 Widget Captioning [28]およびScreen Recognition [50]は、GUIコンポーネントの意味的に意味のあるalt-textラベルを予測します。 Screen2Wordsは、これらの研究を拡張し、モバイルGUI全体の言語要約を予測する。これには、モデルが画面に関する全体的な理解を持ち、複雑な画面内容を簡潔な言語記述として要約する能力が必要である。

2.3 モバイルGUIとインタラクションのデータセット

大規模なモバイルGUIのデータレポジトリは、データ駆動型のモデル開発のための重要な構成要素である。 Rico dataset [7, 30] には，Google Play Store の 27 カテゴリにまたがる 9.7k 個の Android アプリの 66k 個のユニークな UI 画面の視覚，テキスト，構造，およびインタラクティブなデザイン特性が含まれています． ERICA [8]は，アプリの使用中に取得されたモバイルUIのユーザインタラクションデータのコレクションを提供しています． Swire [16]とVINS [4]は、UI検索モデルの学習に使用したデータセットをオープンソース化しています。この分野の別の研究では，言語の基礎付けと生成の両方のために，モバイルUIと自然言語を結びつける公開データセットを提供している[27, 28]．これまでの研究に基づき、本研究では、高品質な人間のアノテーション、詳細な分析、ベンチマークモデルを備えた、モバイルUI要約のための初のオープンソースの大規模データセットを提供する。

3 データセットの作成

本研究では、まず、22,417個のユニークなUI画面に対して112,085件の人間による注釈付き英文要約を作成するデータセットを作成することで、画面の自動要約のための手法を検討する。このデータセットは、画面要約のためのデータ駆動型のモデル開発の基礎となるものである。以下では、我々のデータ収集プロセスを説明し、収集したデータの分析結果を報告する。

3.1 モバイルUIコーパス

まず、オープンソースのデータセットであるRico-SCA3[27]から、画面からなるモバイルUIコーパスを構築しました。このコーパスには、Ricoデータセット[7]からフィルタリングされた画面のサブセットが含まれており、ビュー階層の欠落や不正確な画面が排除されています。我々のコーパスでは、各画面にUIのスクリーンショット画像と、ビュー階層のJSONファイルが含まれています。ビュー階層は、UIの構造的なツリー表現であり、UI要素に対応する各ノードには、要素のクラス、ユーザへの可視性、境界線などの様々なプロパティが含まれています。 Rico-SCAのフィルタリングされたコーパスから、合計22,417のユニークなスクリーンにラベルを付けました。

3.2 データアノテーション

要約アノテーションを生成するために、85人のプロのラベラーを募集した。このラベラーは、当社のML研究開発を支援するためにデータアノテーションのために雇われた契約者たちである。ラベラーは全員英語が堪能で，以前にも別の仕事で Android の UI をラベリングしたことがある．コーパスの各画面について、スクリーンショット画像、タスクの指示、アプリの説明をラベラーに提示し、5人の異なるラベラーから5つのアノテーションを集めた。ラベラーはテキストフィールドに回答を入力し、画面が理解できないと判断した場合は画面をスキップすることができた。各ラベラーは平均して約50時間かけてアノテーションを作成しました。ラベリングの際には、品質アナリストがラベル（画面の要約とSFAの両方）の約5％をサンプリングして監査し、品質を確保し、誤ってラベル付けされた画面は再度ラベル付けされた。ラベラーのトレーニングは、典型的な例、パイロットデータの収集、そして「やるべきこと」と「やってはいけないこと」を含む以下のガイドラインを用いて行った。

Do's

要約は5〜10語で行う。
最も重要な機能に焦点を当てる。
画面に表示されているテキストは、要約の助けになる。
"NOUN + CLAUSE" の構造で要約する。

注意点

画像やアイコンだけを要約するのではなく、画面全体を要約すること。
画面を見て感じたことを書かず、事実に基づく表現に徹する。
色や形、UI要素の名前だけを記述しないこと。
アプリの名前ではなく、カテゴリで表現する。

このガイドラインは，画像キャプションのデータセットとして有名なMicrosoft COCO Captions [6]のデータ収集に用いられたものを参考にした．このガイドラインは，ラベラーがスクリーンショットの見た目ではなく，UIの機能性に注目するように設計されている．パイロットスタディの結果に基づいて，ガイドラインとラベリング・インターフェースを繰り返し改良した．また、ラベラーが画面の要約を作成する理由を理解するために、画面を要約してフレーズを入力する際にSFA（Summary Focus Area）を選択してもらいました。 SFAとは、ラベラーがサマリーを作成する上で最も情報量が多いと判断したUI要素をカバーする画面上の領域のことです。 SFAのアノテーションは、モバイルUIにおける要約の重要性に焦点を当てており、先行研究[12]が焦点を当てている視覚的重要性とは異なる。我々は、パイロットデータ収集で見つけたラベラーの焦点の潜在的な不一致（例えば、広告バーとメインコンテンツ）を捕捉するためにSFAを装備した。ラベラーは、ドラッグ・アンド・ドロップでUI画面上のバウンディング・ボックスをマークするだけで、SFAにアノテーションを付けることができます。図2(a)は、2つのサンプル画面と、その画面概要およびSFAの注釈を示しています。

スクリーンショット 2021-10-24 14 08 34

3.3 データ解析

3.3.1 要約言語解析。

このデータセットには、6,269個のアプリの22,417個のユニークな画面が含まれており、人間の作業者が作成した112,085個の要約語句が得られた。収集された要約文から、ストップフレーズのショートリストを削除しました。これらのストップフレーズには、"in the app "の8つのバリエーションが含まれており、これらは要約フレーズにしばしば現れるが、要約にはあまり貢献しない。ストップフレーズを除去した後の平均フレーズ長は6.57語である。図3(a)は、収集した要約文の長さの分布を示している。各画面について，異なるラベラー間での要約の一貫性を測定するために，収集した要約の中で2回以上出現しているすべての単語について，単語レベルの精度とリコールを計算することで，アノテーター間の一致度を測定した（図3）．同じ手法は，COCO image captioning dataset [6]でも使用されている．単語レベルの精度とリコールは，コーパスに蓄積された各単語の真陽性（TP），偽陽性（FP），偽陰性（FN）のカウントを用いて計算される．各画面の要約について、その単語が同じ画面の他の4つの要約アノテーションに現れているか（TP）、全く現れていないか（FP）をチェックします。他の4つの要約にのみ現れ、チェックした要約には現れない単語はFNケースとしてカウントされる。サンプリングのばらつきを避けるために、すべての画面の5つの要約ラベルそれぞれについて、この計算を繰り返した。このプロセスにより、コーパス全体での各単語のTP/FP/FNカウントの累積値が得られ、これを精度とリコールの計算に使用します。ここでは，データセット中の上位4.5K語に焦点を当てて分析を行った。これらの語は，複数回出現し，サマリー中の全単語出現数の99.7%を占める。

図3(b)に示すように，収集したサマリーは，異なる人間のラベラーの間で，各画面について妥当な単語レベルの一致を示している．具体的には，4.5Kの単語について，語彙の中の連続する10個の単語ごとに，平均の精度とリコールを報告している（単語の頻度でソートしている）．その結果、図には450個のデータポイントが含まれており、それぞれが10個の単語の精度/リコールを表しています。データポイントの色付けには、語彙内の単語のランクが使用されています。ランクが低いほど、コーパス内の単語頻度が高いことを示しています。

3.3.2 要約フォーカスエリア分析。

SFAは、要約を行う際にラベラーがUIのどの部分に注目したかを示すおおよその指標であり、要約を目的とするラベラー間での画面上のUI要素の重要性の認識を理解するために使用します。平均して、SFAは画面の66.1%をカバーしており、これは画面全体を要約することを目的としている我々の予想の範囲内である。我々は、IoUスコア（Intersection over Union）を用いて、同一画面上で異なるラベラーがラベル付けした領域の一致度を測定した。ペアの平均IoUスコアは74.1%であり、画面の要約を作成する際に、画面上のどの領域に焦点を当てたかについて、ラベラー間で適切なコンセンサスが得られていることがわかる。 SFAは、当初、アノテーションのばらつきを考慮して導入されました。しかし、データ収集のガイドラインやラベリングのインターフェースを何度も修正していくうちに、ラベラー間の焦点のズレが少なくなり、彼らのSFAには画面上の関連するUI要素のほとんどが含まれていることがわかった。このような一貫性は、MLモデルにとって望ましいものであり、SFAは画面要約の一貫性のための保護と説明責任を果たすものです。図2(b)は、2つのサンプル画面に、異なるラベラーによってアノテーションされた5つのSFAを重ね合わせたものです。色の濃い部分は、多くのラベラーが画面を要約する際に重要視した部分である。

4 モデルデザイン

提案する画面要約タスクの課題と実現可能性を理解するために，深層学習モデルを利用する．モデルの設計は，画像キャプションや機械翻訳でよく用いられるエンコーダ・デコーダアーキテクチャに基づいて行いました．エンコーダ・デコーダ方式では，モデルはまず入力データを隠れた表現にエンコードし（エンコード），次にエンコードされた情報に基づいて出力をデコードする（デコーダ）．図4は、我々の画面要約モデルのアーキテクチャを示している。 Widget Captioning [28]のモデルと同様、画面のマルチモーダルな情報をエンコードするために、デュアル・エンコーダを使用しています。

当社のエンコーダは、 1）画面のUI構造と、その画面が属するアプリのテキスト説明をエンコードするTransformerエンコーダと、 2）画面上の各要素の画像ピクセルをエンコードするResNetから構成されています。

2つのエンコーダーの出力は、後半のフュージョン（融合）によって結合されます。こうして得られたすべてのUI要素の符号化結果が、画面のマルチモーダルな意味理解となり、Transformerデコーダに供給されて画面要約用のフレーズが生成されます。

次に、本モデルの個々のコンポーネントについて詳しく説明します。私たちのモデル設計の多くの側面はベストプラクティスに従っていますが、ここでは完全性と再現性のためにそれらを説明したいと思います。一方で、アプリの説明を追加の「要素」として組み込むことで、エンコーディング時のTransformerの自己注意を促すなど、私たちのデザインのユニークな点にも注目しています。

4.1 モバイルUI画面のエンコード

モバイルUI画面の全体像を把握するために、デュアルエンコーダーを使用して、ビュー階層やアプリの説明などの構造的なテキスト情報と、スクリーンショットの生のピクセルの両方をエンコードします。そして、それぞれのエンコーダの出力を連結して、画面上の各UI要素のマルチモーダルなエンコーディングを行います。

4.1.1 構造情報とテキスト情報のエンコード

モバイルUIの構造情報とテキスト情報の両方をエンコードするために、Transformerモデル[42]を使用します。 Transformerモデルの中核となる考え方は自己注意であり、モデルは、神経的な注意メカニズムを介して、画面上に共存するすべての要素からの情報を活用することで、各画面要素を表現することを学習します。その結果、このアプローチでは、画面上の各UI要素の文脈表現を獲得することができます。 Transformerエンコーダは、コンテンツの埋め込みと位置のエンコードの両方を入力として必要としますが、モバイルの埋め込みに有効であることが示されているアプローチを採用しています[27, 28]。 breadth-first traversalを実行してビュー階層ツリーを平坦化し、Transformerモデルが必要とする入力要素の線形順序を取得します。画面上の要素の空間的な位置と、ビュー階層におけるツリー（DOM）の位置を用いて、位置的な埋め込みを計算します。フラット化されたツリーの各要素は、空間的な位置情報と構造的な位置情報の両方を持ちます。

要素の埋め込み

まず、UI上の個々の要素を埋め込みベクトルとして表現する必要があります。要素には豊富なプロパティセットがあります。ビュー階層から見ると、要素のクラス、クリッカビリティ、バウンズはそれぞれ、要素のタイプ、クリッカビリティの有無、画面上の2次元的な位置情報を表しています。要素のツリーポジションは、ビュー階層における順序前、順序後のトラバーサルポジションとその深さとして捉えられ、UI上の要素の構造的な位置を反映しています。要素の空間的な位置とツリーの位置の両方が、要素の位置情報を構成します。最後に、要素にはテキストコンテンツが含まれている場合がありますが、これは要素に関する意味的な情報の良いソースとなります。私たちは、これらの情報源をそれぞれ別個に要素に埋め込みます。テキストコンテンツについては、事前に学習されたGloVe単語埋め込み[36]を用いて各単語を表現し、要素のすべての単語に対して和プーリングを行い、要素の固定サイズのベクトルを取得します。それ以外の属性については、カテゴリー変数として扱い、別々に埋め込むことにする。要素の最終的な埋め込みは、連結によって行われる。

アプリの説明文の埋め込み。

データ収集の項で説明したように、アプリの説明文は、画面が属するアプリの背景情報を提供するため、画面要約を行う際に人間のラベラーにアプリの説明文を読ませます。アプリの説明文には、画面が属するアプリの背景情報が含まれているからです。画面要約において人間の知能を実現するための計算モデルを訓練するためには、モデルにも同じようにこの情報へのアクセスを与えることが重要です。そこで、Google Play Storeのアプリの説明文をもう一つの入力ソースとして用意しました。アプリの説明文は、テキストコンテンツを要素で表現するのと同様に、事前に学習したGloVe単語埋め込みを用いて各単語を埋め込み、アプリの説明文を単純に「単語の袋」として扱い、すべての単語の和プーリングを用いてアプリの説明文の最終的な埋め込みを取得しています。アプリの説明文がない画面では、空の説明文に対してオールゼロのエンベッディングを割り当てます。 LSTMのようなより複雑な手法は、アプリの説明を埋め込むためのモデルに簡単に組み込むことができますが、本論文の焦点ではありません。このプロセスの結果は、アプリの説明に対する固定サイズの埋め込みベクトルを得ることです。

トランスフォーマーによるエンコーディング。

図4に示すように、各要素とアプリの説明文を埋め込みベクトルとして表現した上で、各埋め込みベクトルをTransformerエンコーダーが必要とする目標次元に線形投影(𝑃)します。ここでは、アプリの説明文をTransformerエンコード処理に参加する特別な「要素」として扱っています。この設計により、Transformerエンコーダーモデルの自己注意メカニズムにより、各UI要素が要素のコンテキスト表現を形成する際に、アプリの説明文の埋め込みを参照することが自然に可能になります。具体的には、アプリ説明エンベッディングを要素エンベッディングに要素次元で追加することで、[num_of_elements + 1, embedding_size]の形をしたエンベッディングテンソル、𝐸を生成します。トランスフォーマーのエンコーダーが、実際のUI要素のエンベッディングベクトルとアプリの説明文のエンベッディングベクトルを区別できるように、各エンベッディングに、要素エンベッディングなのかアプリの説明文エンベッディングなのかを示すタグを付けていますが、これは単に、線形射影𝑃の前にワンショットのベクトルをエンベッディングに加えるだけです。その後、エンベッディングテンソルである𝐸をTransformerエンコーダーに供給し、UIの構造的-テキスト的エンコーディングを生成しました。

4.1.2 UIスクリーンショットの符号化。

画面の視覚的側面を表現するために、画面上の各要素の画像をエンコードします。そのためには、UIスクリーンショットから各要素の画像を切り取り、切り取った画像を64x64x1の形をした固定サイズのテンソルにリスケールします（64x64は空間次元、1はグレースケールのシングルチャンネル）。各要素の画像エンコーディングが、下流の計算で期待される一定の形状になるように、画像のサイズを変更します。リサイズすることでアスペクト比は失われますが，要素画像を大きなターゲットサイズにパディングする場合に比べて，計算効率が向上します．ほとんどのUI要素のセマンティクスは色に依存しないため、グレースケール画像を使用します。画面上の各要素を指定するビュー階層が与えられているため、モデルに画面全体の符号化を求めるのではなく、切り取られた要素画像を直接使用するのが賢明です。この設計により、画像エンコーダは、スクリーンショットのピクセルからUI要素を抽出するための学習（オブジェクト検出問題）から解放されます。各UI要素のピクセル情報のエンコードには、多層構造の畳み込みニューラルネット（CNN）であるResNetを使用しました。 ResNetの構成要素は、3つの畳み込み2D層からなる残差ブロックで、第1層の入力が第3層の入力に追加されるという残差接続が行われています。各ブロックの最後の層は、垂直方向と水平方向の空間次元を半分にするストライド2を使用しています。マルチレイヤーCNNの出力は、スクリーン上の要素のビジュアル・エンコーディングを表している。

次に、前のセクションで説明した構造的・文脈的エンコーディングと視覚的エンコーディングを連結して、各UI要素の最終的なエンコーディングを形成します。なお、構造的テキストエンコーディングでは、アプリの説明文に含まれる要素が追加されているため、対応するビジュアルエンコーディングとしてパディング画像のエンコーディングを追加しています。これは、各要素の画像エンコーディングがすでにモデルに提供されているため、パディングエンコーディングを使用しています。もうひとつの方法は、画面全体の画像エンコーディングを使用することです。

4.2 スクリーンサマリーのデコーディング

前節で得られた最終的なエンコーディングは、スクリーン上の各要素に関する構造的なテキスト情報と視覚的な情報の両方を網羅している。このような表現は、各エンコーディングが画面上の他の要素に注意を払いながら計算されるため、文脈に沿ったものとなります。これらのエンコーディングに基づいて、Transformerデコーダ[42]モデルを使用して、画面に対する様々な長さの自然言語要約を生成します。 Transformerデコーダは、エンコーダと同様に、自己注意を用いて、要約時に生成された単語トークンの文脈に注意を払います。教師付き学習中に生成されていない将来のトークンからの情報漏洩を避けるために、自己注意をマスクして、マルチヘッドの注意が以前のトークン表現にのみ注意を払うようにしている。さらに、Transformerデコーダは、デコード処理の各ステップにおいて、エンコーダの出力、すなわちエンコーディングにアクセスする。これを実現するのが、エンコーダ・デコーダ間のアテンション層である。内部的には、各デコーディングステップのアテンション出力に、スクリーンエンコーディングの加重和を加えてから、位置を考慮した多層パーセプトロン（FFN）に入力します。画面上の個々の要素にキャプションを付けることに焦点を当てた先行研究[28]とは異なり、我々のTransformerデコーダは画面上のすべての要素に注目し、全体的な画面要約をデコードします。要約の各トークンの確率分布は、Transformerデコーダの出力に対するソフトマックスを用いて最終的に計算されます。エンコーダーとデコーダーを含むモデル全体の学習は、各画面の要約の各トークンを復号する際の平均クロスエントロピー損失Lを最小化することにより、エンドツーエンドで行われます。

ここで、𝑀はデコードする単語トークンの数、𝑁はミニバッチのスクリーン数、𝑦 ′ 𝑖,𝑗はグランドトゥルース要約の𝑗番目のトークン、𝑦𝑖,𝑗は対応する予測値である。トレーニングは、教師が強制的に行う方法で行われ、グランドトゥルースの要約の単語がデコーダに入力されます。予測時間中、モデルは自己回帰的に復号し、ビームサーチを用いて上位の要約候補を生成する。

5 実験

マルチモーダル深層学習に基づいて提案したScreen2Wordsアプローチの有効性を調べるために，画面の要約実験を行った．実験の目的は， 1）深層モデルがヒューリスティックな手法よりも優れた性能を発揮するかどうか， 2）複数のデータモダリティを組み込むことでより良い要約結果が得られるかどうかを検証することである．

まず、実験のセットアップとトレーニングの構成について説明します。そして、一般的に使用されているいくつかの指標に対するモデルの性能と、モデルの動作の分析を報告します。

5.1 実験データセット

モデルの開発と評価のために、表1に示すように、データセットをトレーニングセット、検証セット、テストセットに分割した。同じアプリ内の画面が似たようなスタイルやセマンティクスを共有している可能性があるため、情報漏えいを防ぐために、データをアプリごとに分割し、同じアプリのすべての画面が異なる分割で共有されないようにしました。その結果，テストデータセットに含まれるすべてのアプリと画面は，学習時には見たことがないものとなり，各モデルの構成がテスト時の見たことのない状況にどのように一般化するかを調べることができます．我々のボキャブラリーは10,000の最頻出単語を含み、トレーニングデータセットで遭遇した残りの単語には、ユニークな未知のトークンが割り当てられている。検証やテストの際には、デコードされたフレーズに含まれるは評価の前に削除される。今回のデータセットでは、1つの画面に5つの要約ラベルフレーズ（5人のラベラーによる）があるため、確率的学習の際には、そのうちの1つのラベルが毎回ランダムに学習対象として抽出される。テスト段階では、5つの画面の要約すべてがBLEUやCIDErなどの自動評価指標の参照セットとして使用されます。

5.2 モデルの構成と学習内容

学習データと検証データに基づいて，モデルの構成を調整した．単語の埋め込みは，事前に学習した400K-vocabの300次元GLOVE埋め込み[36]で初期化し，128次元のベクトル空間に投影した．埋め込みの重みは、スクリーンのエンコーダとデコーダの両方で共有しました。 Transformerエンコーダとデコーダの両方で，隠れたサイズが128の6つのTransformer層と，8つのヘッドアテンションを使用しています。画面上の要素のピクセルを符号化するために、7層のResNetが使用されました。 ResNetには合計で21の畳み込み層があり、最終層の出力は256サイズのベクトルにフラット化されている。畳み込み層ごとにバッチ正規化を行いました。各要素の画像の最終的なエンコーディングは128次元のベクトルで、トランスフォーマーのエンコーダの出力と連結してデコーディングされます。要約中の各単語は順次復号され、テスト時にはビームサイズ5のビームサーチを用いてトップ5の要約予測を生成する。モデルはTensorFlowで実装し，8個のTesla V100 GPUコアを用いてバッチサイズ128画面でモデルを学習し，Adamオプティマイザ[18]を使用した．実験したモデルはすべて2日以内に収束しました。

5.3 モデルのバリエーションとベースライン

マルチモーダルなデータ表現を融合して画面を要約することの有効性を調べるために，我々のモデルの異なるバリエーションを比較した．

PixelOnly。既存の画像キャプションアプローチ[32, 45, 48]をベースにしたこのモデルは、マルチレイヤーCNNがUI要素画像からエンコードした視覚情報のみを利用して要約を生成します。
レイアウトオンリー。このバージョンでは、ビュー階層から抽出された要素のUIプロパティに基づいて、Transformerエンコーダでエンコードされた構造表現を使用します
Pixel+Layout。このバリアントでは、画像エンコーディングと構造情報の両方を使用します。
Pixel+Layout+Text（ピクセル＋レイアウト＋テキスト）。Pixel+Layoutをベースに、画面のテキストからエンコードされたテキスト情報を追加で使用するモデルです。
Pixel+Layout+Text+AppDesc：上記の情報に加え、アプリの説明文を使用する完全なモデルです。

画面の自動要約に特化した既存のベースライン技術は存在しないため、本実験では比較のためにテンプレートベースのベースラインをいくつか作成した。これらのベースラインは、トレーニングデータセットから、クエリ画面に最も類似した画面の要約を検索することで、見たことのない画面（クエリ画面）の要約を予測します（最近接アプローチ）。これらの手法では，各画面の特徴付けを，テキスト解析でよく知られているTF-IDFスコアのベクトル，あるいはピクセル値のベクトル，あるいはこれらの組み合わせで行っています．

TF-IDF ベクトルの長さは、語彙サイズです。ベクトルの各値は、語彙の中の単語のTF-IDFスコアに対応する。オリジナルのTF-IDF用語に基づいて、各画面をドキュメントとして、画面内の各単語を用語として扱います。語彙頻度(TF)は、ある単語のトークンが画面に現れる頻度を表し、逆文書頻度(IDF)は、学習コーパスの画面間でその単語がどれだけ稀であるかを表します。 TF-IDFスコアは、ある単語が画面の中でどれだけユニークかを測定します。 TF-IDF ベースラインは，sklearn [3] を用いて実装されています．ピクセル値ベクトルについては、画面をグレースケールに変換し、TF-IDFベクトルのサイズに合わせて、画面を100×100の次元にリサイズする。さらに、ピクセル値ベクトルを表現するために、CNNベースのオートエンコーダー4によって学習された画像エンコーディングを使用する、もう一つのピクセルベースのベースラインであるPixel-DLも加えています。各画面がTF-IDFベクトルおよび/またはピクセル値ベクトルとして表現されていれば，画面のペア間のコサイン類似度スコア∈[0, 1]を計算し，スコアまたは2つのスコアの合計を用いて最も類似した画面を見つけ，クエリ画面をトレーニングセット内の画面にマッチさせることができ，その性能を表2に示します．これらのベースラインにより，従来の最近傍探索やテンプレートベースの検索手法を用いることの難しさと，画面の自動要約に深い生成モデルを用いることの利点を理解することができた．以下の報告では，各ベースライン手法はすべてテンプレートベースのアプローチに基づいているため，Templateを接頭辞としている．

5.4 実験結果

このセクションでは，機械翻訳や画像キャプション作成のタスクで一般的に使用されるメトリクスに基づいて，我々のモデルのパフォーマンスを報告する． BLEU [34]，CIDEr [43]，ROUGE-L [29]，METOER [9]である（表2参照）．数字が大きいほど，これらの指標においてモデルの性能が高いことを意味し，予測されたフレーズとグランドトゥルースのフレーズの距離が近いことを意味する．テンプレートベースのベースラインでは、最も類似した画面から1つの要約をサンプリングしてその予測値とした。すべてのスコアは、学習段階ではモデルが見ていないテストデータセットで計算された。その結果，すべての生成モデルが，これらの指標においてテンプレートベースの検索ベースラインのすべてを大差で上回っており，我々が提案するモデリング手法が正当であることがわかった．ベースラインの中では、TF-IDFとピクセル値ベクトルの両方を用いた検索が最も高い性能を示し、マルチモーダルな情報の有用性が示されました。 TF-IDFベクトルを計算するためにアプリの説明を追加しても（表2のTemplate (TF-IDF+Pixel+AppDesc)）、性能は向上しませんでした。これは、同じアプリのすべてのスクリーンが同じアプリの説明を持ち、スクリーンのテキストがまばらな場合、それらが互いに区別できなくなるためと考えられます。 DLベースの画像エンコーディングを使用する「Template (Pixel-DL)」ベースラインは、生のピクセルを使用する場合に比べてわずかな改善しか見られません。一方，要素の画像符号化のみを用いる「Pixel-Only」モデルは，すべてのベースラインよりも大幅に性能が向上しています．また，モバイル UI の構造表現を取り込んだ Layout-Only モデルは，Pixel-Only モデルよりもわずかに優れた性能を示した． 2 つの入力を組み合わせると、Pixel+Layout はすべての評価指標でさらに向上します。同様に，Pixel+Layout+ScreenText は，スクリーンからのテキスト情報を追加で利用することで，さらに優れた結果を得ることができた．アプリの説明文を活用した「フルモデル」は、すべてのモデルの中で最高の精度を達成した。これらの結果は、モバイルUIのマルチモーダルデータがお互いに補完し合い、その組み合わせによってより良い要約結果が得られることを示している。図5は，同じテストセットの画面を用いて，異なるモデルのバリエーションによる要約結果の例を示している．すべてのモデルが、一貫性のある理解しやすい要約を作成することができ、中でもフルモデルは、画面の基本的なセマンティクスを捉え、最も正確な要約を作成することができる。 Pixel-Only」モデルでは、適切な説明文を生成できることもありますが（1行目）、より複雑な画面の意味を捉えることができないことが多くあります。 2行目の例では、レイアウト情報を追加することで、Pixel+Layoutモデルが要約のパフォーマンスを向上させることを示しています。フルモデルの結果では、アプリのカテゴリなど、画面を要約する際に、より多くのコンテキストや詳細を提供するためにテキスト情報が役立つことが明らかになりました（3行目）。また、どのような場合にモデルが失敗するかを示すために、すべてのモデルが非常に一般的な説明文しか生成できなかった例（4行目左）と、すべてのモデルが関連性のある要約を生成できなかった例（4行目右）を紹介します。

6 人間による評価

画面要約の品質をさらに理解するために，Mechanical Turk を用いて，生成された画面要約の品質を人間に評価してもらい，自動測定基準と人間の判断との相関関係を検証しました．

6.1 研究の設定

テストセットからランダムにサンプリングした1000枚のスクリーンと同じセットで、モデルバリエーションのPixel Only、Pixel+Layout、フルモデルのPixel+Layout+ScreenText+AppDesc、そして2つのテンプレートベースラインのTemplate (Pixel)とTemplate (TF-IDF+Pixel)を比較しました。各画面について，3人の評価者を募集し，要約の品質を評価してもらった．合計で1041人の人間が評価に参加したが，データセットのラベリングには誰も関与していなかった．レーティング中，人間の評価者には，これらのモデルのいずれかによって生成された画面要約が，対応するUIのスクリーンショットとともに提示された．人間の評価者は，評価対象の画面要約をどのモデルが生成したかを知らない．評価者には、次の3つの点を考慮するよう求めました。

画面の種類：画面の種類（サインインまたはサインアップ画面、設定メニュー、検索結果など）について要約が言及している場合、それがどの程度正確か、または関連性があるか。
UI要素。サマリーにUI要素（例：ポップアップ、リスト、オプション、検索バー、動画）が記載されている場合、その正確性や関連性はどうか？
アプリの種類。アプリの種類：ソーシャルアプリ、ニュースアプリ、学習アプリなど、アプリの種類について記載されている場合、その正確性や関連性はどうか？

評価尺度については、以前に人間の判断で画像キャプションの品質を評価した際に用いられた評価システムを採用しましたが、一般的な説明ではなく、要約が間違いなく画面を説明しているだけでなく、画面の有用な詳細情報を提供していることを示す5点目を追加しました。ラベラーに提供された正確な評価基準は以下の通りです

間違いなく画面を説明し、十分な詳細を提供している。
誤りなく画面を描写している。
軽微な誤りがあるが、画面を説明している。
多少、関連性のある記述をしている。
画面に関連性のない記述をしている。

6.2 研究結果

各画面について，3 人の異なる評価者からの評価を平均して，要約品質のスコアを得た。表3に示すように，人間が評価した各ディープモデルのバリアントの平均スコアは，自動評価指標の結果とよく相関している．フルモデルの評価が最も高く、次に「Pixel+Layout」、「Pixel-Only」の順となっている。 Template (Pixel) ベースラインの平均評価は最も低くなっています。興味深いことに、自動メトリクスで最強のベースラインである「Template (TF-IDF+Pixel)」は、テキスト情報を使用しない2つのディープモデルの亜種よりも高い人間の評価を達成しているが、これらのディープモデルは前述のように自動メトリクスでベースライン手法を上回っている。このような主観的な評価と自動メトリックのスコアの不一致は、次のような原因があるのではないかと推測しています。画面テキスト特徴には、人間が感じる画面とその要約の関連性を決定する上で決定的な役割を果たすキーワードが含まれている可能性があります。このキーワードは、TF-IDF+Pixelでは利用されていますが、これらの2つのディープモデルのバリエーションでは利用されていません。この欠点は、自動測定基準では、要約の関連性に関する人間の知覚に対する重要性に応じて重み付けをするのではなく、各単語を平等に扱うため、表示されません。しかし、人間による評価と自動評価の結果を合わせると、我々のフルモデルがテンプレートベースラインとディープモデルバリアントの全てを凌駕していることが明らかになった。ノンパラメトリックのMann-Whitney Uテストでは、我々のフルモデルと他のすべての設定の平均評価の間の差が有意であることを示しています（𝑝 < 0.0001）。さらに、フルモデルに対する評価のうち38.6%が最高点、すなわち5点を獲得しており、その割合は「テンプレート（TF-IDF+Pixel）」では32.2%、「Pixel+Layout」では29.5%に低下しています。これらの結果から，ベースラインと比較して，我々のフルモデルは，誤りがないだけでなく，十分な詳細を含む要約を生成する能力が高いことがわかる．

7 応用例

マルチモーダルなUI情報に基づいて自動的に画面を要約するアプローチであるScreen2Wordsを紹介し、高品質な画面要約を生成するための我々の提案モデルの能力を実証した。ここでは、3つのモックアップアプリケーションを提案することで、Screen2Wordsの潜在的な使用例を示す。

1) 言語ベースのユーザーインターフェース検索、 2) スクリーンリーダーの強化、 3) 会話型モバイルアプリケーションのための画面インデックス作成。

7.1 言語ベースのユーザーインターフェース検索

Screen2Words は、言語ベースのモバイル UI 検索を可能にすることで、デザイン検索を強化します。キーワードベースの検索では、クエリに含まれる単語と画面上のテキストを直接マッチングさせることでUIを検索しますが、Screen2Wordsモデルは、画面上に表示されるテキストコンテンツを超えてUIのセマンティクスを捉えることができ、そのことは要約結果と達成された精度からも明らかです。図6は、言語ベースのUI検索システムを示すモックアップインターフェースです。 Screen2Wordsによって取得されたUIセマンティクスにより、デザイナーは「sign up page」（図6左）のようなUIキーワードで検索できるだけでなく、「sign up page of a social network application」（図6右）のように、より具体的なセマンティクスの詳細を含むクエリを使用することができます。 Screen2Wordsを用いたUI検索では、このようなモックアップを用いて、想定されるユーザー体験をマッピングします。 Screen2Words モデルを我々のデータセットに基づいたトリプレットロスでトレーニングすることで、完全に機能するシステムを構築することができる。

7.2 スクリーンリーダーの強化

VoiceOverやTalkBackなどのスクリーンリーダーは、モバイル画面上のテキストや画像コンテンツを、UIを記述するメタデータに基づいて音声に変換する。これらは視覚障害者にとって不可欠なアクセシビリティ機能ですが、メタデータの欠落に悩まされることが多く[39, 40, 51]、最近では機械学習を用いて欠落したメタデータを予測する研究が盛んに行われています[28, 50]。 Screen2Words は、スクリーンリーダーのユーザーに概要説明を提供するための画面サマリーを予測することで、この取り組みに貢献できる。豊かな視覚的インターフェースによって未知の画面の目的を素早く理解できる目の見えるユーザーとは異なり、視覚障害のあるユーザーは、新しいUIのためのメンタルモデルを形成する前に、スクリーンリーダーを使って画面上の要素に目を通さなければならない。そのため、研究[2, 19, 37]では、視覚障害者が現在のページに時間を費やすべきかどうかを迅速に判断できるように、視覚障害者向けの画面概要の必要性を訴えています。具体的には、アプリスイッチャー（AndroidのOverviewやiOSのApp Switcherなど）を使ってアプリを切り替える場合、OSは通常、各アプリの最後に表示した画面をキャッシュし、ユーザーが常にホーム画面から起動する必要がないようにします。しかし、視覚障がいのあるユーザーはビジュアルを見ることができず、スクリーンリーダーは各アプリの名前を読むだけなので、アプリごとにどの画面がキャッシュされているのかを知ることはできませんでした。図7に示すように、Screen2Wordsは画面の概要を提供することで、アプリに切り替えた直後にアプリのどこにいるのかを探し出すことができる。

7.3 会話型モバイルアプリケーションのための画面のインデックス化

画面の要約を利用して、各画面に追加の言語メタデータを装備し、携帯電話上でインデックス化することができます。他のアプリのメタデータと組み合わせることで、ユーザーは「Gmailの設定画面」や「スターバックスアプリの注文画面」などと言って、手動で操作することなく目的の画面を素早く起動することができる。さらに，Screen2Wordsは，ユーザと協力してモバイルタスクを達成するマルチモーダルな会話エージェントに統合することができる[23, 25, 26]．例えば、SUGILITE [22]は、ユーザのデモンストレーションにより、新しいタスクの実行を学習する。 Screen2Wordsを用いた画面の索引付けにより，音声対話は手動による実演の一部を置き換えることができる．例えば、ユーザーがスターバックスのアプリでアメリカーノを注文する方法を実演したい場合、"Open the ordering page of the Starbucks app. "と言えばよい。注文ページが開くと、ユーザーは残りのステップを手動で実演することができます。手動で目的の画面に移動してタスクを完了するのに時間がかかる場合には、このハイブリッドなアプローチが有効です。

8 考察と今後の課題

Screen2Words は，モバイル UI と自然言語の橋渡しに一歩近づいたと言える．提案されたアプローチは、モバイルUIの全体的な理解を必要とする他のタスクにも適用可能であり、ウェブUIなどの異なるタイプのユーザーインターフェースにも一般化できる可能性がある。しかし、今後の課題として、いくつかの限界があります。第一に、我々の画面要約モデルは必ずしも正確ではありません。図5に示すように、一般的な要約や間違った要約を生成することがあります。これは、モデルが実際にはシーンに存在しないオブジェクトを「幻視」する傾向があるという、画像キャプションの長年の問題に似ています[38]。さらに，従来とは異なる視覚から言語へのタスクに関する先行研究[17, 46]と同様に，人間の評価と自動スコアが必ずしもうまく相関しないことがわかり，より優れた自動評価指標の必要性が示された．今後は，より良い要約結果を得るために，新しいモデルアーキテクチャと評価指標を検討することができる．シナリオによっては、アプリのメタデータが欠落し、Screen2Words の性能が低下する可能性がある。しかし、PixelOnly などの設定は、常に利用可能なピクセル入力のみに依存するため、我々のアプローチは依然として有用である。特に、ScreenTextがまばらであったり、全く存在しない場合には、ピクセル入力が重要であることがわかりました。このようなシナリオは、モダリティが欠落していても機能する、我々のマルチモーダルアプローチのモチベーションを高めるものです。もう一つの限界は，画面要約は画面全体の説明を生成するだけだということです．また、画面要約は画面全体の情報しか生成できないため、ユーザが画面上の特定の部分の情報を記述するように指示することはできません。したがって、Screen2Wordsの自然な拡張は、UI画面のVisual Question Answering（VQA）[1、13]に向かっています。このVQAは、モバイル画面と自由形式のオープンエンドの自然言語の質問を入力として受け取り、自然言語の回答を出力として生成します。 Screen2Wordsは、"What's on the screen? "などの質問への回答に特化したモデルと見なすことができます。フルレンジのScreen VQAは、"What action can I take with the screen?" や "What's the title of the first news article on the screen?" などのさらなる質問にも答えられるはずである。このような技術があれば、モバイル機器とのアイフリー・スピーチ・インタラクションを大きく促進することができる。最後に、Screen2Wordsのユースケースの1つとして、言語クエリによるUI検索の促進があります。すぐにできる次のステップは、言語記述に基づいてモバイルUIデザインを生成する我々のデータセットに基づいて、言語ベースのUI生成を検討することです。将来的には、ユーザーインターフェースデザインを生成するために、画面要約を条件としたグラフィカルレイアウト生成モデル[20, 21]を活用することができます。そのためには、我々のオープンソースのデータセットは、これらの研究の方向性を後押しする貴重なソースとなるでしょう。

e4exp / paper_manager_abstract