大规模语言模型能否实现与移动UI的对话式交互？

自然语言处理 13/04/2023

三个要点
✔️ 第一篇研究使用大规模语言模型（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任务需要为每项具体任务建立单独的数据集和模型，这既昂贵又费力。然而，最近有研究表明，它可以通过预先训练的LLM进行通用化。本文通过应用一种新的提示技术，研究了使用LLMs进行移动UI和对话交互的可行性。

　本文提出了四个对话任务："屏幕问题生成"、"屏幕总结"、"屏幕提问-回答（QA）"和"将指令映射到用户界面动作"。研究。它提出了一种通用的方法来实现基于语言的移动交互，在这些任务中实现了与现有机器学习方法相当或更好的性能，而不需要专门的数据集或训练。

任务

　在本文中，PaLM被用作大规模的语言模型来验证下图中的四个任务：第一个任务是屏幕问题生成。这是一项任务，代理根据用户界面屏幕中需要操作的项目，生成适合用户的问题。例如，如果一个旅游网站的用户界面屏幕上有输入 "目的地 "和 "逗留日期 "的项目，代理可以提出诸如"你的目的地是哪里？你的逗留时间是什么时候？"等，这项任务就会产生诸如 "你的目的地是哪里？即使看不到屏幕的人也能理解所需的字段。

　第二个任务是屏幕总结。这项任务对用户界面屏幕上显示的内容进行总结，并将其传达给用户。例如，如果在一个旅游网站上显示一个可供选择的酒店列表，该内容必须被适当地传达给用户。即使是看不到屏幕的人也能理解显示的内容。

　第三项任务是屏幕提问-回答（QA）。这是一项用户通过代理在用户界面屏幕上请求信息的任务，而代理则以合适的信息进行回应。例如，如果一个旅游网站上显示了一个可用的酒店房间列表，而用户问："一个有特大号床的房间多少钱？"任务将根据用户界面屏幕的内容作出回应，"每晚330美元"。基于用户界面屏幕的内容。这个功能对于不能看到屏幕的人来说也很有用。它还能让他们从大量的信息中只检索出他们需要的信息。

　第四项任务是 "将指令映射到用户界面操作"。这项任务根据用户的要求执行适当的屏幕操作。例如，在酒店预订屏幕上，如果用户要求："点击预订按钮，预订一个有大床的房间 "。代理人就会点击相应的按钮并完成预订。这对无法看到或操作屏幕的人来说很有用。

实验（屏幕问题生成）。

　在这里，需要用户输入的用户界面元素被识别出来，并生成适合用户的问题。下图显示了一个生成问题的提示的例子。给定一个目标UI屏幕，一个思维链方法（chain-of-thought）被用来生成"需要输入的UI元素的数量"、"屏幕摘要 "和 "需要输入项目的元素列表 "作为中间结果。最后，它生成了包含在<SOQ>和<EOQ>标记中的问题。

　生成的问题在"语法正确性"、"用户界面相关性 "和 "问题范围 "方面进行评估。语法是指生成的问题的语法的正确程度。它是否可读和自然？采用李克特量表（5级）。UI的相关性是一个两点的量表，评估生成的问题是否'与UI元素相关'。问题的覆盖率（Coverage F1）"评估了生成的问题 "识别屏幕上的元素 "的程度。这是通过比较Ground Truth中输入元素的标签和思维链方法所识别的标签而自动计算出来的。结果显示在下面的表格中，其中LLM的结果被用于资源_id这个词，称为res_tokens，问题是 "什么是{res_tokens}？"结果与基于规则的方法（Template）进行了比较，该方法填补了一个名为的模板。

　三位评分者对Template和LLM的931个问题进行了评分。就语法而言，Template的平均分是3.6分，而LLM的平均分几乎是完美的4.98分。UI的相关性（Relevance）"显示，LLM生成的问题比Template的相关性高8.7%。对于'问题覆盖率（Coverage F1）'，LLM达到了95.9%（F1得分）（精确度=95.4%，召回率=96.3%）。

　基于规则的Template为所有的输入元素生成问题，这自然会导致100%的问题覆盖率，但这也表明LLM能够准确地识别输入元素并生成足够相关的问题。

　对LLM行为的进一步分析还表明，在生成特定问题时，LLM同时考虑了输入元素和屏幕背景（来自其他屏幕对象的信息）。下图显示了由LLM和Template为两个用户界面屏幕生成问题的例子。

　左边的图显示，LLM使用被要求输入信用卡信息的上下文来生成与每个输入字段有关的语法正确的问题。例如，在(2)中，LLM指出 "信用卡到期日"，而Template并没有提到 "信用"。另外，在（3）中，LLM正确地生成了'SSN的最后4位数字'的问题，而Template没有提到它。

　另外，看右边的图，可以看出，虽然LLM能够利用先前的信息并结合多个相关的输入来生成一个问题，但Template却不能；LLM能够通过结合最低和最高价格项目来生成一个询问价格范围的问题；Template能够通过结合最低价格项目和最高价格项目生成一个询问价格范围的问题。LLM能够通过结合最低和最高价格项目来生成一个询问价格范围的单一问题。

实验（屏幕总结）。

这项任务总结并向用户传达了用户界面屏幕显示的内容。它可以帮助用户快速了解移动用户界面的内容。当不可能看到用户界面屏幕时，它尤其有用。一个提示的例子显示在下图中。这里没有使用思维链的方法，因为不需要生成任务的中间结果。

　下图显示了一个包含人类标记的摘要和由Screen2Words和LLMs输出的摘要的屏幕（例子），其中LLMs更倾向于使用屏幕上的具体（具体）文本来产生摘要，如旧金山（左上）或提拉米苏蛋糕流行（左下）。文本，表明他们更有可能使用该文本。另一方面，Screen2Words则是比较一般的（抽象的）。

　此外，LLM更有可能利用屏幕上的几个关键元素，生成更多的扩展摘要。例如，右上方的屏幕显示了LLM是如何利用应用程序名称、发送文件按钮和收件人的传真按钮来编写一个较长的摘要的（"FaxFile应用程序屏幕，用户可以选择一个文件通过传真发送，并选择收件人。挑选收件人。"）。

　这也表明，在总结屏幕时，对LLM的先前知识也是有用的。例如，右下方的屏幕显示了伦敦地铁系统的车站搜索结果页面。 LLM预测 "伦敦地铁系统中一个地铁站的搜索结果"。然而，输入的HTML既不包含 "伦敦 "也不包含 "地铁"。因此，该模型使用从一个大型语言数据集中学到的关于车站名称的先验知识来推断该车站名称属于伦敦地铁系统。如果仅在Screen2Words上训练模型，可能不会产生这种类型的摘要，这是LLM的一个优势。

实验（屏幕提问-回答）。

当用户通过代理在用户界面屏幕上请求信息时，代理会以合适的信息作出回应。一个提示的例子显示在下图中。由于不需要生成任务的中间结果，所以没有使用思维链提示。

　图（左）显示了一个屏幕提问-回答实验结果的例子。图（右）显示了用于评估屏幕提问-回答性能的三个指标。答案的准确性按三个级别评定（完全匹配、包含地面实况和地面实况的子字符串）。

　图（左）显示，LLM明显优于基线DistillBert；LLM为Q1、Q2和Q4生成了准确的答案，属于精确匹配；对于Q3，它也属于包含地面真相；对于Q4，它生成的答案包含地面真相 "2016年12月23日"。额外的时间 "4:50am "被回答了，但是它产生的回答包含了地面信息"2016年12月23日"。

　另一方面，基线DistillBert在Q4中属于精确匹配，并产生了准确的答案，但对于其他问题，Q3的答案缺失或完全不同，只匹配"2016"。另外，在Q2中，HTML代码的答案是。

实验（将指令映射到用户界面动作）。

　这是响应用户的要求，执行适当的屏幕操作的任务。例如，如果用户被指示 "打开Gmail"，就必须正确识别主屏幕上的Gmail图标。这个任务也不需要产生中间结果，所以没有使用思维链方法。输出响应被包围在特殊标签<SOI>和<EOI>中，分别意味着预测元素ID的开始和结束。

　下面是一个提示的例子。这里，一个元素ID=29的时钟应用程序被预测为请求 "打开你设备的时钟应用程序"。

　我们使用PixelHelp数据集，其中包含187个在谷歌Pixel智能手机上执行日常任务的提示，例如切换Wi-Fi设置或检查电子邮件。作为一个提示模块，我们对数据集中每个特定的应用包随机抽取一个屏幕。然后，我们从提示模块中随机抽样以创建最终的提示，并在两种条件下进行实验：应用内和跨应用。在应用内，提示包括与测试屏幕相同的应用包的提示模块，而在跨应用中，提示包括与测试屏幕相同的应用包的提示模块、在交叉应用中，它不包括。

　这里，目标元素的部分（Partial）和完全（Complete）匹配的比例被用作评价指标。结果如下表所示，其中LLM表明，在0次拍摄的情况下，部分和完整任务都很难执行。

　在交叉应用中，在1-shot的情况下，Partial是74.69，Complete是31.67。这意味着大约75%的请求元素被正确预测，超过30%的任务是完全正确的。2-shot在部分和完整方面都有轻微的性能改进、比交叉应用更高的分数：对于2-shot LLM（应用内），Partial达到了80.36，Complete达到了45.00。