[LLM] Google使用大模型与Mobile UI交互（CH

2023-08-19 本文已影响0人 nlpming

1.整体框架

本文实验探索通过单个LLM实现人机之间的交互的可行性，并在4个场景做了实验：屏幕问题生成（Screen Question-Generation）、屏幕摘要（Screen Summarization）、屏幕问答（Screen Question-Answering）、和映射用户指令到UI Action（Mapping Instruction to UI Action）。本文实验基于开源的Android UI数据集：
1） RICO数据集（RICO dataset | Kaggle）
2）Screen2Wrods数据集（https://paperswithcode.com/dataset/screen2words）
3）PixelHelp数据集 (https://paperswithcode.com/dataset/pixelhelp)
下面1中展示了用户与Agent交互的4个任务场景，按照主动请求信息或者提供信息分为两大类（纵坐标），横坐标表示按照Agent和用户划分。

Agent主动发起的任务有：
1）屏幕问题生成：a）当前屏幕信息：Home screen of a hotel search app；b) Agent发起问题：Which hotel do you want to search for your trip？
2）屏幕总结：a）当前屏幕信息：A list of hotel room options； b) Agent发起总结：The current screen shows the details of hotel rooms available；

用户主动发起的任务有：
3）屏幕问答：a) 当前屏幕信息：A list of hotel room options；b) 用户发起问题：What's the rate per night for the Fabulous King room？c) Agent回答：It's 330 dollars per night
4）指令到动作映射：a) 当前屏幕信息：A list of hotel room options；b) 用户指令：Click on the reserve buttom to book the the Fabulous King room；

人机交互4大任务分类.png

基于Gmail邮箱4个任务的可行性举例.png

2. 关键模块说明

2.1 屏幕信息表示

屏幕信息输入到LLM存在以下几个挑战：
1）大语言模型GPT3.5等只能接受文本信息作为输入，然而屏幕信息包含了文本、图像、和层次化的结构信息。
2）将屏幕中view hierarchy信息直接输入到大语言模型，容易造成token数量的超出，因为view hierarchy数据中存在大量的冗余信息。
将view hierarchy表示成html： 因为大语言模型的训练数据大多数来自于网上爬取，这些数据中包含自然语言和代码。比如PaLM模型大约5%的训练数据来自于github包含24种常用的计算机编程语言比如Java，HTML, Python等。因此本文中将包含屏幕信息的view hierarchy数据转为HTML表示，转换过程是通过深度优先搜索遍历view hierarchy tree得到的。
view hierarchy属性如何转换？ 将view hierarchy转化为html数据能够很好的，保留结点的详细属性和维持原有的层次化关系。view hierarchy转为html数据只保留部分跟文本描述相关的属性信息比如：
1）class: 结点类信息，Android类对象；
2）text：元素文本信息，对用户是可见的；
3）resource_id: 文本信息的标识；
4）content_desc：内容描述，用于有障碍阅读；
Android类映射成HTML标签： 本文将TextView映射为<p>标签因为他们都用于表示文本数据，将所有的button相关的类Button, ImageButton都映射为<button>标签；将所有的图像相关的类比如IMAGEVIEW都映射为<img>，包含icon和image；将文本输入类EDITTEXT映射为<input>标签；最后将所有的布局容器相关类都映射为<div>标签；
将可操作的元素加上数字索引： 为了帮助大语言模型找到特定的UI元素，在每个元素中插入一个id属性来唯一的标识这个UI元素；id的值来自于深度优先搜索的访问顺序；

2.2 基于COT的提示

Chain-of-Thought提示方法[参考：https://readpaper.com/paper/4588425171329622017]，通过将推理的中间过程加入到提示中使得大模型具有一定的推理能力。文本的实验中只是在"屏幕问答"问题中使用了COT提示，要求大模型执行多步的推理。

2.3 Prompt组成结构

下图给出了本文中使用Prompt的基本组成部分：
1）开场白：说明本次任务是干啥的，或者说描述扮演的角色等；
2）few shot例子：包含三个部分：a) 屏幕信息使用html表示；b) COT思维链，描述思考过程；c) 模型的输出格式；这张图中描述的是一个屏幕问题生成prompt的例子，最终针对每个输入生成的问题使用<SOQ><EOQ>标签给包含起来；

Prompt组成举例.png

2.3.1 Screen Question-Generation

包含4个组成部分：
1）任务描述：Given a screen, the agent needs to identify the elements requiring user input and generates corresponding questions；
2）屏幕信息html表示；
3）COT描述：Now reasoning starts ...
4）结果输出：To help the user ...
上述中2、3、4部分为一个few shot例子；

屏幕问题生成.png

2.3.2 Screen Summarization

包含3个组成部分：
1）任务描述：Given a screen, summarize its purpose；
2）屏幕信息html表示；
3）对屏幕摘要总结输出结果；
其中2、3部分组成一个few shot内容；

屏幕摘要总结.png

2.3.3 Screen Question-Answering(QA)

包含3个组成部分：
1）任务描述：Given a mobile screen and a question, provide the answer based on the screen information；
2）屏幕信息html表示；
3）问题和回答，回答使用<SOA>和<EOA>一对标签包含起来；