发布时间：2024 年 11 月 08 日
Agent应用
WorkflowLLM: Enhancing Workflow Orchestration Capability of Large Language Models
大型语言模型（LLM）的最新进展通过基于 LLM 自动化工作流编排流程，推动了流程自动化从机器人流程自动化到智能体流程自动化的革命性范式转变。然而，现有的 LLM（甚至先进的 OpenAI GPT-4o）在工作流编排方面的能力仍不尽人意。为了解决这一限制，我们提出了 WorkflowLLM，这是一个以数据为中心精心设计的框架，旨在增强 LLM 在工作流编排方面的能力。它首先构建了一个包含 106,763 个样本的大规模微调数据集 WorkflowBench，涵盖了来自 28 个类别的 83 个应用程序的 1,503 个 API。具体来说，构建过程可分为三个阶段：（1）数据收集：我们从 Apple Shortcuts 和 RoutineHub 收集真实世界的工作流数据，将其转录为 Python 风格的代码。我们还通过 ChatGPT 为其配备生成的分层思维。（2）查询扩展：我们提示 ChatGPT 生成更多任务查询，以丰富工作流的多样性和复杂性。（3）工作流生成：我们利用在收集数据上训练的注释器模型为合成查询生成工作流。最后，我们将通过质量确认的合成样本与收集的样本合并，以获得 WorkflowBench。基于 WorkflowBench，我们对 Llama-3.1-8B 进行微调以获得 WorkflowLlama。我们的实验表明，WorkflowLlama 展示出了编排复杂工作流的强大能力，同时在以前未见过的 API 上也实现了显著的泛化性能。此外，WorkflowBench 在分布外任务规划数据集 T-Eval 上表现出强大的零样本泛化能力。我们的数据和代码可在 https://github.com/OpenBMB/WorkflowLLM 上获取。
如遇无法添加，请+ vx: iamxxn886
添加时请注明 LLM
- 由RPA到APA ===========
流程自动化（Process Automation，PA）旨在让重复任务自动化，从而减少人力投入，提升效率。回溯到农业时代，人类就借助水车和牛来实现农业作业的自动化。
当前主流的 PA 技术——机器人流程自动化（Robotic Process Automation，RPA），通过协调各种动作（比如函数或 API），把重复任务抽象成工作流。虽然 RPA 借助自动工作流执行成功减轻了人力负担，但工作流的协调过程仍需大量人工操作。
LLM 的出现带来了范式转变的趋势，从机器人流程自动化（RPA）转向代理流程自动化（Agentic Process Automation，APA），利用 LLM 构建工作流，实现工作流协调过程的自动化。
然而，这一范式转变趋势受限于 LLM 协调复杂工作流的能力有限，进而导致当前 APA 方法存在两大局限性：
- • 动作规模受限 ：目前LLM 仅能协调动作数量有限的小规模工作流。即便是最先进的 OpenAI GPT-4，即便配备了先进的决策机制，能管理的工作流平均也只有 6.1 个动作 ，远不能满足现实需求的复杂程度。比如，Apple Shortcuts平均涉及 70.4 个动作。
- • 逻辑结构简单 ：目前，多数现有工作主要聚焦于生成顺序动作，但现实应用中的工作流通常包含复杂的逻辑结构，比如分支和循环。例如，Apple Shortcuts 平均有 2.6 个嵌套的分支/循环逻辑结构。所以，迫切需要释放 LLM 的工作流协调能力，以加快流程自动化的范式转变。
为应对这些挑战，本文作者提出工作流 LLM（WorkflowLLM）：一个以数据为中心的框架，涵盖数据集构建、模型训练和评估。
- 什么是工作流LLM?
上图展示了工作流（WorkflowLLM）概览，通过一个三阶段管道构建工作流基准，再对工作流 Llama 进行微调，能够依据用户的查询生成工作流。
上图展示了Workflow LLM 以数据为核心的框架，借由构建高质量的监督微调数据集 Workflow Bench 来提升 LLM 在工作流编排上的能力。数据集的构建流程分为三个不同阶段开展：数据收集、查询拓展以及工作流生成。
2.1 数据收集（DATA COLLECTION）
通过抓取和筛选苹果快捷指令和 RoutineHub获得高质量数据，然后将快捷指令转成 Python 风格的工作流代码。受思维链（Chain-of-Thought）启发，让 ChatGPT 生成分层的想法，包括注释、任务计划和任务查询，为每个快捷指令从细到粗逐步推进。
2.1.1 苹果快捷指令与 RoutineHub
苹果快捷指令是 RPA 的典型应用，由苹果公司开发。能让一系列动作自动化，方便用户高效完成各种任务。快捷指令里的动作由苹果内置应用（比如 Safari）和第三方应用（比如 OpenAI）提供的 API 组成。每个应用都可能提供多个动作，比如 OpenAI 提供的能和 ChatGPT 进行语音对话和文本交互的 API。通过简单的拖放界面，用户能构建像导航到最近咖啡店或者从 TikTok 下载无水印图片这样的复杂工作流 。
RoutineHub 是分享快捷指令的重要社区，在 iOS 和 macOS 平台上收集了数千个快捷指令。所有快捷指令都被分成 28 个工作流类别（比如商业、健康与健身、生产力等）。RoutineHub 会记录每个快捷指令的元数据（比如标题、描述、iCloud URL），提供有价值的信息。
2.1.2 抓取与筛选
对每个快捷指令，抓取标题、开发者提供的描述和链接到苹果的 iCloud URL。因为 RoutineHub 不提供快捷指令的源代码，所以从 iCloud URL 进一步抓取。此外，还合并了 ShortcutsBench 收集的快捷指令，这些来自 Share Shortcuts 和 MacStories 等平台，进一步扩大数据集规模。
不过，这些快捷指令的源代码缺少所涉及动作的详细信息，比如 API 元数据。受 Shortcuts Bench 启发，从 macOS 内置定义文件和第三方应用接口定义文件里提取动作信息。对于每个 API，记录其名称、描述、参数名、参数类型、默认值、返回值类型和返回值名称，这给 LLMs 高效解释和利用这些 API 提供了宝贵资源，哪怕是零样本场景。
为保证抓取的快捷指令和动作接口兼容，实行严格的筛选机制，验证所有 API 调用是否正确执行。这过程中，发现有些快捷指令包含作为 API 参数的无法解释的二进制序列，可能影响语言模型训练。为保证数据质量，把这些样本从数据集中剔除。最终整理出 14771 个高质量快捷指令 ，保证数据集对后续数据扩展和模型训练的可靠性。
2.1.3 快捷指令转录
原始快捷指令源代码是用属性列表格式写的，依次对分支、循环等逻辑结构编码。这种编码和 LLMs 预训练常用的数据类型差别很大。
为解决这个问题，把快捷指令转成抽象语法树（ASTs），用前序遍历转成 Python 代码。
而且，原始快捷指令用十六进制字符串当变量名，语义清晰度不高。为提高可解释性，用 ChatGPT 给这些变量重新分配更有上下文意义的名字，提升代码整体可读性和对后续语言模型训练的实用性。
2.1.4 想法生成
为给 LLMs 编排工作流提供丰富的指导，设计了从细到粗的三级思想层次：
-（1）低级注释是为阐明工作流中每个动作的目的。
-（2）中级计划是对一系列动作的抽象，概括这些步骤的共同目标。
-（3）高级查询反映用户需求，指定预期结果但不规定实现方法。
如上图，涵盖了任务查询、API文档、任务规划以及附有注释的工作流代码。
2.2 查询扩展
对收集到的数据进行全面的统计分析后：
数据复杂性较高 ：平均有 70.4 个操作和 12 个分支，其复杂程度超过了现有的工作流相关基准。
数据的多样性相对较低 ：40.3％的工作流属于“实用工具”类别，且超过 99％所使用的 API 为苹果内置 API。
所以，从两个关键方面来扩展数据集：
- • （1）多样性：弥补真实数据中多样性的不足，涵盖广泛的 API 和工作流类别，以增强模型的实用性和稳健性；
- • （2）复杂性：与现实世界数据的操作规模和逻辑复杂性相匹配，确保能有效代表现实世界的问题并相应地协调节点。
为此，从不同的应用程序和具有代表性逻辑结构（比如是否包含分支或循环）的多个工作流中采样 API 来合成额外的查询。
上图展示了进行数据扩展前后的数据对比：上图为扩展前的数据分布，下图为扩展后的数据分布。
扩展后的有着更均衡的类别分布，并使用了更多第三方 API。虽然使用的大多数 API 仍是内置 API，但考虑到它们承担着必要的操作，这是合理的。
2.3 工作流生成
为有效标注合成查询的对应工作流，依据收集的快捷方式数据训练了一个标注器模型，以支持更多元的应用和类别，并尽可能与真实世界数据保持一致。
2.3.1 标注器训练
首先，基于收集的人工标注快捷方式构建监督微调（SFT）数据集。每个工作流数据点包含一个查询Q、相应的动作文档D、任务计划P以及以带注释的 Python 代码A 组成的工作流。
在 SFT 过程中将查询Q和相应的动作文档D作为输入，引导模型生成任务计划P，接着逐步生成当前的想法和相应的动作，动作包含名称及其相关参数。用训练好的标注器从合成查询生成工作流。
2.3.2 质量确认
因标注器模型的准确性有限，生成的工作流可能存在一定错误。比如，发现与查询无关的多余分支、不正确的函数调用格式等问题。为提升整体质量，给 ChatGPT 提供上下文示例来优化带注释的 A 和 P，确保工作流能准确处理查询。然后，通过基于规则的过滤，删除存在根本错误的工作流。具体来说，就是剔除不包含代码、未使用给定 API 或违反这些 API 相关参数约束的样本。
最后，得到一个包含 91,992 个实例的合成数据集，与最初收集的数据结合，形成最终的工作流基准。它涵盖 106,763 个实例，涉及 83 个应用中的 1,503 个 API，用于训练工作流 Llama。
3. 效果如何
3.1 工作流LLM Llama的泛化性能
从两个层面衡量 Workflow Llama 的泛化性能：
-（1）未见过的指令，考虑同分布（ID）设定，即使用与训练数据相同的一组 API；
-（2）未见过的 API，考虑分布外（OOD）设定，仅涉及构建工作流所需的 50 个常见 API 以及训练数据中没有的 API。
- • 1.所有模型都具备一定的工作流编排能力。或许源于它们固有的遵循指令和生成代码的能力。发现像 GPT-4o 和 Llama-3.1-70B 这类在通用任务中表现出色的模型，在工作流编排方面也表现卓越。另外，利用上下文示例进行提示显著提升了模型的性能。
- • 2.所有模型在诸如 BLEU 和加权 N-gram 等文本重叠指标上得分均较低。即便是经过微调的 Work flow Llama，在这两项指标上也仅达 8.2％和 9.7％。原因在于参考代码主要由含函数名和参数的工作流构成，且 Python 相关关键字较少，致使精确匹配颇具难度 。相较而言，模型在语法 AST 匹配和语义数据流匹配方面得分更优。
- • 3.经过微调，Workflow Llama 在编排动作的能力上有显著提升。其性能甚至大幅超越强大的闭源模型 GPT-4o 与 ICL。Workflow Llama 在 CodeBLEU 上得分 39.3％，在 ID 设置下通过率达 76.9％，证明Workflow LLM框架和 Work flow Bench 数据集的有效性。
- • 4.Workflow Llama 展现出强大的泛化能力。即便未曾在相同指令或 API 上训练，它在所有指标上仍显著优于原始的 Llama-3.1，领先或接近更强大的基础模型。在 CodeBLEU 中达 35.1％，通过率达 70.4％，优于所有强劲的基线。
3.2 工作流复杂性之分析
上图展示了基于动作数量、分支和循环数量以及参考代码的嵌套深度的性能对比。
随着动作数量或逻辑复杂度的上升，所有模型的性能均下滑 ，表明编排复杂工作流颇具挑战。
不过，在所有复杂程度层级中，Workflow Llama 显著优于其他所有模型。而且，随着工作流复杂程度的提高，Workflow Llama 的相对性能也有所提升，这表明借助 WorkflowBench 进行微调极大地增强了模型处理更复杂工作流的能力。
3.3 针对 T-Eval 的分布外泛化
T-Eval 原本的数据格式基于 JSON 或字符串，这与 Work flow Bench 所采用的基于 Python 的格式差异显著。为保证评估指标与原论文一致，将 Workflow Bench 转为 JSON 格式，同时保留工作流的元数据和查询详情。
然后在转换后的数据集上重新训练 Workflow Llama。
即便在不同领域和任务中使用不同 API 训练，Workflow Llama 在 T-Eval 基准上展现出强大的分布外泛化性能。尤为突出的是，Workflow Llama 显著优于原始的 Llama3.1-8B 以及诸如 Llama-2-70B 和 Qwen-72B 等大型开源模型，这表明借助 Workflow Bench 进行微调增强了模型的分布外规划能力。
3.4 消融研究
上图呈现了模型在不同条件下训练的性能结果，包括使用合成数据、没有任务计划 、没有动作级别注释C 以及 C 和 P 都没有的情况。
实验结果表明：
- • 其一，两种类型的自然语言思考提升了模型的推理能力。去掉任何一种思考都会致使 CodeBLEU 性能降低。
- • 其二，在大规模合成数据上训练进一步提升了性能，凸显了 Work flow Bench 扩展流程的有效性。
3.5 案例研究
为进一步阐释微调对工作流基准的作用，在上图展示了一个典型示例。
原始的 Llama-3.1 模型存在两类错误：
- • 1.该模型未遵循给定的工作流编排指示，使用了所提供列表之外的 API，即幻觉 API。
- • 2.因其工作流编排能力相对较弱，该模型未能完成所有用户指令。
- • 论文原文: https://arxiv.org/abs/2411.05451
- • 获取更多最新 Arxiv 论文更新: https://github.com/HuggingAGI/HuggingArxiv!
- • 加入社群，+v: iamxxn886
- • 点击公众号菜单加入讨论