OS-Genesis: 自动生成GUI Agent轨迹数据,高效构建高质量Agent

OS-Genesis框架自动生成GUI Agent轨迹数据,无需人工干预,高效构建高质量Agent,显著提升任务成功率。

原文标题:OS-Genesis来了,自动收集和标注Agent数据,高效且多样

原文作者:机器之心

冷月清谈:

OS-Genesis是一个无需人工监督的GUI数据合成框架,它通过反向任务合成(Reverse Task Synthesis)自动收集和标注Agent数据,高效且多样地生成了高质量的轨迹数据,解决了现有方法人工成本高、合成数据局限性大的问题。

OS-Genesis的核心思想是先在GUI环境中进行探索性交互,记录动作和状态变化,然后逆向生成低阶指令和高阶指令。具体来说,它首先捕捉动作三元组<状态前,动作,状态后>,然后利用GPT-4o模型将这些三元组转化为低阶指令,再结合环境导出高阶指令。最后,让模型执行合成的指令,生成完整的轨迹数据。

为了保证轨迹质量,OS-Genesis引入了轨迹奖励模型(TRM),根据完成度和一致性对轨迹进行评估和筛选。OS-Genesis的数据在移动端和Web端实验中都表现出色,显著提升了GUI agent的任务成功率,并在未见过的应用场景下展现了较强的泛化能力。

相比于人工标注和基于预定义任务的合成数据生成方法,OS-Genesis在效率、多样性和质量上都有显著优势,为构建通用GUI Agent提供了可靠的数据支持。

怜星夜思:

1、OS-Genesis使用GPT-4o生成低阶指令,这是否意味着该框架对大型语言模型有较强的依赖性?如果未来出现更优秀的模型,是否需要重新调整框架?
2、文章中提到OS-Genesis的数据在未见过的应用场景下表现出较强的泛化能力,这种泛化能力是如何实现的?它能否推广到更广泛的GUI类型,例如游戏界面?
3、OS-Genesis的轨迹奖励模型(TRM)是如何设计的?它如何平衡轨迹的完成度和一致性?是否存在一些局限性?

原文内容

图片

AIxiv专栏是机器之心发布学术、技术内容的栏目。过去数年,机器之心AIxiv专栏接收报道了2000多篇内容,覆盖全球各大高校与企业的顶级实验室,有效促进了学术交流与传播。如果您有优秀的工作想要分享,欢迎投稿或者联系报道。投稿邮箱:[email protected][email protected]

共同一作孙秋实是香港大学的博士生,此前在新加坡国立大学获得硕士学位,研究方向包括 LLM Agents 和神经代码智能等领域。共同一作金川杨是约翰霍普金斯大学的博士生,此前以专业第一名毕业于纽约大学,其开发的心智能力测试 MMToM-QA 荣获 ACL 2024 杰出论文奖。本文的 Shanghai AI Lab 吴志勇团队此前已发布了 OS-Copilot、OS-Atlas、SeeClick等同系列成果。



  • 论文题目:OS-Genesis: Automating GUI Agent Trajectory Construction via Reverse Task Synthesis
  • 项目地址:https://qiushisun.github.io/OS-Genesis-Home/
  • 研究机构:上海人工智能实验室,香港大学,上海交通大学,约翰霍普金斯大学,牛津大学,香港科技大学

1 背景与动机

有效的 Digital Agents 必须拥有两个能力:(1)Planning 能力,即任务规划能力,能将用户给定的(高阶)指令分步划分为子目标(2)Action 能力,即根据当前目标,执行相应的动作。

在构建高质量的 GUI agent 时,GUI 轨迹数据能最有效地让 agent 学习如何完成任务,其数据稀缺性是当前 digital agent 领域最关键挑战之一。以下是一个典型的 GUI 轨迹数据示例,它包括以下部分:

  • 高阶指令:明确规定任务目标,例如 “将 Broccoli 应用中的‘Avocado Toast with Egg’标记为收藏”。
  • 低阶指令:分解为具体的操作步骤,例如 “点击‘Avocado Toast with Egg’以查看更多选项”。
  • 动作:与低阶指令相关的具体操作,如 “CLICK [Avocado Toast with Egg]”。
  • 状态:包括执行动作前后的可视化和文本化表示,例如屏幕截图和 GUI 的 a11ytree 结构。

图片

现有的轨迹数据采集方法通常依赖于人工监督或基于预定义任务(Task-Driven)的合成数据生成。这些方法在实际应用中存在以下局限性:

人工采集的过高成本:人工标注轨迹数据需要大量的人力资源,不仅需要手动设计高阶指令,还需逐步记录每一步操作。这使得数据收集过程成本高昂且效率低下。

合成数据的局限性:基于模型生成的轨迹数据虽然可以缓解人工标注的成本问题,但通常依赖于预定义的高阶任务。这种方法不仅限制了生成数据的多样性,还容易导致与真实环境的差距。特别是在中间步骤出错或任务目标 / 环境不匹配时,生成的轨迹可能是不完整或不连贯的。

因此,如何在成本可控的情况下,有效地构建 GUI Agents 轨迹是一个非常重要的课题。在此动机下,本文提出了 OS-Genesis:一套无需人工监督的高质量 GUI 数据合成框架。

2 OS-Genesis

OS-Genesis 的核心思想是:通过先探索性地交互 GUI 环境,捕捉每一步动作及其前后状态变化。

图片

然后基于这些变化逆向生成高质量的低阶指令(Low-level instruction,比如’点击 Calendar APP’),再根据环境导出一个高阶指令(High-level instruction,比如’添加日程:看机器之心推文’)。随后,让模型执行这一合成的指令,此过程完全摆脱了人工干预和任务预定义的限制,实现了 GUI 轨迹数据生成的高效性和多样性。本文可以为构建通用的 GUI agent 提供新的思路,其具体方法如下所示。

2-1 反向任务合成

反向任务合成(Reverse Task Synthesis)是 OS-Genesis 的核心,它帮助我们在构建 GUI 轨迹数据时摆脱需要人工 / 机器预定义任务的局限。其流程如下所示:

图片

动作记录与状态捕捉

在没有预定义任务的情况下,OS-Genesis 通过在 GUI 环境中系统性地执行基本动作(例如 CLICK、TYPE、SCROLL 等),生成大量的三元组数据 ⟨状态前,动作,状态后⟩,即 ⟨spre, action, spost⟩。这些三元组记录了每个动作对环境状态的影响,为后续的任务合成提供了原始数据。

低阶指令生成

利用 GPT-4o 模型,将每个三元组 ⟨spre, action, spost⟩ 转化为描述具体操作的低阶指令(Low-level Instruction)。例如,若动作 CLICK 使某菜单展开,低阶指令可能为 “点击下拉菜单以显示选项”。

高阶任务生成

在低阶指令的基础上,OS-Genesis 进一步生成高阶指令(High-level Instruction)。高阶指令通过结合低阶步骤和当前 GUI 环境,描述了一个更为抽象且目标明确的任务,例如 “配置应用程序设置”。这种从低阶到高阶的逐步生成方法不仅确保了指令的逻辑一致性,还能最大化利用 GUI 环境中的动态特性。

通过上述反向任务合成,OS-Genesis 可以在没有人工干预的情况下构建多样化、语义丰富的任务集合,显著提升了数据生成的效率和质量。

2-2 轨迹构建与奖励模型

反向任务合成生成的高阶指令随后被用作探索 GUI 环境的起点,进一步构建完整的轨迹数据(Trajectory)。为了确保生成轨迹的质量,OS-Genesis 引入了一个奖励模型(Trajectory Reward Model, TRM),对生成的轨迹进行质量评估和筛选。以下是轨迹构建与奖励模型的详细流程:

轨迹执行

利用反向任务合成生成的高阶指令,GUI agent 会执行一系列动作以完成任务。每条轨迹由以下内容组成:高阶指令、低阶指令、动作序列以及状态(包含截图和 a11ytree)。

轨迹奖励模型(Trajectory Reward Model)

为避免低质量或不完整轨迹对模型训练的负面影响,OS-Genesis 使用 TRM 对每条轨迹分配一个奖励分数。奖励分数基于以下两个指标:

  • 完成度(Completion):衡量轨迹是否成功完成高阶任务,包括每个步骤的正确性和逻辑连贯性。
  • 一致性(Coherence):评估轨迹的逻辑性,确保动作序列能够高效地实现任务目标。

奖励驱动的数据筛选

根据奖励分数,轨迹数据会被优先用于模型训练。与传统的二元过滤方法(即抛弃执行失败的任务)不同,TRM 允许部分不完整但具有探索价值的轨迹保留在数据集中,从而最大化地利用生成的数据。

图片

通过结合反向任务合成和奖励模型,OS-Genesis 实现了从任务生成到轨迹构建的端到端流程。实验结果表明,OS-Genesis 生成的数据在质量和多样性上均显著优于现有方法,为构建通用 GUI agent 提供了可靠的数据支持。

3 实验

为了验证 OS-Genesis 在动态环境中生成高质量轨迹数据的能力,本文在动态环境上进行了实验。对于 Mobile 场景选择了 AndroidWorld 和 AndroidControl,对于 Web 场景则使用了 WebArena 作为测评基准。在这些复杂的环境中,作者测试用 OS-Genesis 合成数据训练的 agent 表现相对传统方法效果如何。

3-1 模型与基线

VLMs. 作者在实验中选择了代表性的 VLSs 作为 GUI agent 的基础模型,以便全面评估 OS-Genesis 生成的数据在不同模型上的的影响:

  • InternVL2-4B/8B:一种支持高分辨率动态输入的开源 VLM,主要用于视觉任务。其扩展版本 InternVL2-8B 具有更大的模型容量。
  • Qwen2-VL-7B-Instruct:一种多模态模型,具备一定的 GUI 交互能力,专为指令执行任务优化。

此外,作者还额外添加了 GPT-4o 作为一个强 baseline,来比较我们所训练的开源模型和商业模型之间的差距。

Baselinse. 所有的 baseline 接受的状态信息均为 Screenshots + a11ytree

  • Zero-Shot:直接使用未经过额外训练的模型完成任务。这种方法用于评估模型的原始能力。
  • Task-Driven:利用预定义任务和固定策略生成数据,广泛应用于传统数据生成流程。
  • Self-Instruct:在 Task-Driven 的基础上,引入自我指令生成机制来扩展任务的和覆盖范围。

3-2 Mobile

在 AndroidWorld(In-domain 实验)中,OS-Genesis 生成的数据显著提升了 GUI agents 的任务成功率,从基线的 9.82% 提升至 17.41%,几乎翻倍。尤其是在任务规划和复杂操作中,OS-Genesis 的数据展现了更强的适应性和泛化能力。


在 AndroidControl 中(OOD 实验),OS-Genesis 生成的轨迹在高阶和低阶任务中均表现出色,特别是在高阶任务中,其规划能力提升尤为明显。此外,OS-Genesis 在未见过的应用场景下表现出了较强的泛化能力,验证了其生成数据的高质量和多样性。

3-3 Web

OS-Genesis 在 WebArena 中的表现也显著优于基线方法。对于复杂的交互式网页任务(如 GitLab 和 Reddit),本工作的 agent 相比 Task-Driven 方法提升了约 50%。在多个动态网页场景中,通过 OS-Genesis 生成的数据,agent 表现出了更高的多样性和泛化能力,特别是在需要多步操作的任务中,其生成轨迹更符合逻辑和用户意图。


4 分析

本项工作对合成轨迹的质量进行了详尽的分析,特别是将 OS-Genesis 生成的数据与人工标注(Human-annotated)数据进行了对比,以全面评估其在实际应用中的可行性和有效性。

4-1 高阶指令对比

作者首先比较了 OS-Genesis 生成的高阶指令与人工编写的高阶指令在任务执行中的效果。实验基于 AndroidWorld 的 500 个人工标注轨高阶任务,采用 GPT-4o 探索其对应轨迹,并用这些轨迹训练基于 InternVL2-8B 和 Qwen2-VL-7B。为保证公平性,OS-Genesis 和各 baseline 的轨迹数量保持一致。

结果分析

在任务成功率上,OS-Genesis 生成的高阶指令显著优于人工编写的指令。这主要归因于以下两点:

  • 动态环境适配性:人工编写的任务往往难以与复杂环境完全匹配,而 OS-Genesis 通过反向任务合成生成的指令能够自适应 GUI 动态特性,更符合环境需求。
  • 逐步生成策略:OS-Genesis 从低阶指令逐步构建高阶指令,确保了指令的逻辑连贯性和可执行性,而人工编写的高阶指令有时会因缺乏细节而导致轨迹不完整。


4-2 轨迹数据对比

为了进一步验证轨迹质量,作者探讨了 OS-Genesis 生成的完整轨迹与人工标注(Human-annotated)轨迹在 GUI agent 训练中的差异。作者从 AndroidControl 的训练集中选取了 1,000 条众包标注的轨迹进行训练并对比。正如图下,OS-Genesis 显著缩小了合成轨迹与人工标注轨迹之间的性能差距。

这种提升在高阶任务中尤为显著,表明基于 OS-Genesis 轨迹训练的 agent 在任务规划和问题解决方面表现更接近于人类操作方式。从平均任务成功率来看,将人工标注数据视为 gold standard,OS-Genesis 数据的性能保留率超过了 80%。


5 总结与展望

本项工作提出了 OS-Genesis,为有效构建 GUI Agents 提供了全新的视角。通过引入一种全新的交互驱动合成方法,OS-Genesis 成功克服了以往数据收集中构建(1)有意义且(2)多样化的 GUI 任务的关键瓶颈。在多个挑战性的 online 基准测试中,作者证明了 OS-Genesis 生成的数据在构建 GUI agents 的规划和动作能力上实现了突破。此外,OS-Genesis 生成的轨迹数据展现出了更高的多样性,并显著缩小了合成数据与人工标注数据之间的质量差距。OS-Genesis 为生成高质量 GUI agents 训练轨迹数据提供了一个有前景的方向,使研究领域在实现数字世界自动化的道路上更进一步!


© THE END 
转载请联系本公众号获得授权
投稿或寻求报道:[email protected]

对于“OS-Genesis使用GPT-4o生成低阶指令,这是否意味着该框架对大型语言模型有较强的依赖性?如果未来出现更优秀的模型,是否需要重新调整框架?”这个问题,我的看法是,虽然现在依赖性强,但从长远来看,OS-Genesis 的核心在于“反向任务合成”的思想,而不是具体的模型。未来即使模型更替,只要能实现状态到指令的转换,框架就能运作。所以,与其说是依赖,不如说是合作。

引用“OS-Genesis使用GPT-4o生成低阶指令,这是否意味着该框架对大型语言模型有较强的依赖性?如果未来出现更优秀的模型,是否需要重新调整框架?”这个问题,我觉得是的,目前来看依赖性比较强。GPT-4o在理解上下文和生成指令方面表现出色,是OS-Genesis的核心组件。未来如果出现更优秀的模型,当然可以替换,甚至可能提升性能,但应该也需要进行一些调整,以确保新模型与框架的兼容性。

关于“OS-Genesis的轨迹奖励模型(TRM)是如何设计的?它如何平衡轨迹的完成度和一致性?是否存在一些局限性?”这个问题,文章里提到了TRM基于完成度和一致性两个指标,但具体设计细节没有展开。我猜测可能使用了某种加权平均的方法来平衡这两个指标。至于局限性,我觉得可能在于如何定义和量化“完成度”和“一致性”,这本身就是一个难题。

关于“文章中提到OS-Genesis的数据在未见过的应用场景下表现出较强的泛化能力,这种泛化能力是如何实现的?它能否推广到更广泛的GUI类型,例如游戏界面?”这个问题,我来谈谈我的看法。OS-Genesis的泛化能力可能源于它对底层GUI元素和交互逻辑的捕捉,而不是对具体应用的学习。至于推广到游戏界面,挑战在于游戏界面的状态变化更加复杂,需要更强大的模型和更精细的奖励机制。

关于“OS-Genesis使用GPT-4o生成低阶指令,这是否意味着该框架对大型语言模型有较强的依赖性?如果未来出现更优秀的模型,是否需要重新调整框架?”这个问题,其实可以这么理解,大型语言模型只是工具,就像我们写代码用编译器一样,换个编译器代码的逻辑不用变,但是编译器的参数要重新设置。OS-Genesis 框架本身的逻辑可能不用大改,但接口和参数肯定要调整。当然,如果未来模型牛逼到能直接理解状态变化并生成指令,那框架的依赖性自然就降低了。

关于OS-Genesis泛化能力的问题,我觉得主要在于它不依赖预定义任务,而是根据环境动态生成指令。这种方式更贴近真实的用户行为,所以泛化性更好。至于游戏界面,我觉得理论上可行,但游戏GUI的复杂度和动态性更高,可能需要对框架做一些适配。

对于这个问题,我想说的是,OS-Genesis的泛化能力很可能是因为它的数据生成方式更注重多样性,覆盖了更广的交互模式。至于游戏界面,我觉得需要考虑游戏的实时性和交互的复杂性,可能需要结合强化学习等方法来训练agent。

对于TRM的设计,我感觉文章描述的比较笼统,可能需要看源码才能了解细节。完成度和一致性的平衡应该是一个超参数调节的问题。局限性的话,我觉得可能在于奖励函数的设计是否足够全面,能否真正反映轨迹的质量。

TRM的设计确实比较关键,它直接影响数据的质量。我觉得一个可能的局限性在于,它可能更偏向于短期奖励,而忽略了长期目标。比如,一个轨迹虽然没有完全完成任务,但在探索过程中发现了一些有价值的信息,这种情况应该如何评估?