引言: “元规划者”的梦想

想象一下，你让你的数字助手规划一次周末旅行。你说: “帮我找一趟下周六从波特兰出发去温哥华的火车，然后在温哥华预订一间适合两人居住且评分至少为 4.2 的酒店。”

对于人类而言，这是一系列直截了当的任务。然而，对于大语言模型 (LLM) 来说，这却是一场由依赖关系、上下文切换和权限管理构成的噩梦。模型不能简单地“知道”答案。它必须使用工具——具体来说，就是应用程序编程接口 (API) ——来与现实世界进行交互。

虽然我们已经看到 LLM 使用计算器或搜索引擎，但上述场景代表了复杂性的一次巨大飞跃。模型必须意识到酒店的“入住日期”完全取决于火车的“到达日期”。它必须从交通类 App 切换到住宿类 App，并准确地跨越这一边界传递信息。

这种能力被称为元规划 (Meta-Planning) 。 这是 LLM 从聊天机器人转变为真正自主智能体 (Agent) 的前沿领域。但是，目前最先进的模型在这项任务上表现如何呢？

在这篇文章中，我们将深入探讨 AppBench , 这是一篇揭示了现有 LLM 在面对复杂的多 App 生态系统时局限性的研究论文。我们将探讨该基准测试是如何构建的，API 依赖的图状本质，以及为什么即使是 GPT-4o 在最困难的任务上也难以达到 2% 以上的成功率。

一个需要来自不同 App 的 API 的用户指令示例。

如图 1 所示，用户的请求需要模型识别“可见的 App”，选择正确的 API (如 findtrains 和 searchhouse) ，并规划一条数据在它们之间正确流动的路径。

问题: 为何现有基准测试不足

在了解解决方案之前，我们必须先了解现有研究的空白。之前的基准测试如 APIBench 或 ToolBench 在教导 LLM 使用工具方面发挥了重要作用。然而，它们通常集中在两个较简单的场景:

  1. 单一 API 调用: 用户提出一个问题，模型调用一个特定的函数。
  2. 有限的参数: API 很简单，通常只需要一两个输入。

现实世界的软件开发和用户交互很少如此孤立。研究人员发现了现有基准测试忽视的两个主要挑战:

1. 图结构 (复杂的依赖关系)

在现实世界中，API 是相互依赖的。你不能在 search_hotel (搜索酒店) 获得 ID 之前 book_hotel (预订酒店) 。你不能在 generate_invoice (生成发票) 之前 pay_bill (支付账单) 。这创造了一个图结构，其中一些任务并行运行，而另一些任务必须按顺序执行。一个 API 的输出会成为下一个 API 的输入参数。

2. 权限隔离

你的手机里有几十个 App (Uber、Airbnb、WhatsApp) 。这些是不同的生态系统 (“源”) 。充当元规划者的 LLM 必须尊重这些边界。它不能要求 Uber 预订房间，也不能要求 Airbnb 提供乘车服务。它必须通过为每个特定子任务选择正确的受信任代理 (App) 来获取“权限”。

为了直观地展示 AppBench 与之前工作的对比，请看下表。注意“MM” (多 App，多 API) 和“DP” (依赖性) 列——这正是 AppBench 的独到之处。

与现有评估基准的比较。

构建 AppBench: 面向复杂性的基准测试

手动创建一个包含复杂、相互依赖的 API 调用的数据集是非常困难的。AppBench 的作者设计了一个巧妙的自动化流程，利用现有的任务导向型对话数据集，特别是 SGD (Schema-Guided Dialogue) 数据集。

构建过程如下图所示，它模拟了人类助手的认知负荷。

收集 AppBench 数据集的高级处理流程。

流程

  1. 源素材: 他们采用了人类与系统之间的多轮对话 (例如，关于预订航班和酒店的长对话) 。
  2. 摘要生成: 利用 LLM 将这种多轮对话压缩成一条单一的、复杂的用户指令 。
  3. 依赖构建: Python 脚本分析原始对话的逻辑以构建“标准答案 (Ground Truth) ” API 调用。至关重要的是，他们识别出了参数重叠的地方——例如，如果航班搜索中的 destination (目的地) 与酒店搜索中的 city (城市) 相匹配，就会记录一个依赖关系。
  4. 质量控制: 过滤生成的指令，以确保流畅性和逻辑性，保证基准测试是公平且可解的。

四个难度等级

生成的数据集被分为四个难度递增的等级。这种分类使我们需要确切地指出 LLM 的推理在何处崩溃。

  1. SS (单 App，单 API) : 最简单的情况。“找一家餐馆。”
  2. SM (单 App，多 API) : “找一部电影，然后买票。” 存在依赖关系，但在同一个域内。
  3. MS (多 App，单 API) : “查天气 (App A) 并播放音乐 (App B) 。” 两个不同的域，可能并行执行。
  4. MM (多 App，多 API) : “终极关卡”。“找一趟航班 (App A) ，用到达时间预订出租车 (App B) ，并预订一家餐馆 (App C) 。” 这涉及复杂的图结构和跨 App 数据流。

图 3 提供了这些类别的具体示例。注意输出路径中的加粗文本——这些代表依赖于先前输出的参数 (例如 #restaurant_name) 。

AppBench 中不同样本类型的示例: SS、SM、MS 和 MM。

复杂性的规模

是什么让 MM 类别如此困难？这不仅仅是因为长度；这关乎任务的几何结构。如下面的统计表所示，MM 任务具有更高的“顺序规模”和“并行规模”。这意味着模型必须在工作记忆中保存更多信息，并推理更长的因果链。

拟议的 AppBench 的数据统计。

核心方法: 如何评估元规划者

为了评估 LLM 作为元规划者的表现，研究人员定义了如下任务: 给定用户指令和包含各种 App (每个 App 都有自己的 API) 的“虚拟移动环境”，模型必须生成一条可执行路径 。

该路径是一个列表，其中每一项指定了:

  1. 要使用的 App 。
  2. 该 App 内的 API 函数。
  3. 输入参数 , 可以是字面值 (如 “Portland”) 或来自先前步骤的变量 (如 output_of_step_1) 。

指标

论文使用严格的指标来为模型评分。仅仅“聊出”解决方案是不够的；模型必须编写有效的代码。

1. App 选择的 F1 分数 (\(F1_{app}\)) : 模型是否选择了正确的 App？为了计算这一点，我们要看精确率 (\(P_{app}\)) 和召回率 (\(R_{app}\)) 。

App 选择的精确率公式。

App 选择的召回率公式。

2. API 选择的 F1 分数 (\(F1_{api}\)) : 一旦选择了 App，模型是否选择了正确的函数？ (例如，当用户只是想搜索时，是否调用了 find_train 而不是 buy_ticket) 。

3. 成功率 (Succ) : 这是“困难模式”指标。只有当满足以下所有条件时，任务才算成功:

  • 所有 App 都识别正确。
  • 所有 API 都识别正确。
  • 所有参数 (输入和输出) 都与标准答案匹配，包括正确的依赖链接。

如果模型把其他都做对了，但错了一个开始时间或传递了错误的变量名，得分就是 0。

实验与结果: 现实检验

研究人员测试了 9 种不同的 LLM，涵盖了像 Mistral-7B 和 LLaMA-3 这样的开源模型，以及像 GPT-3.5 和 GPT-4o 这样的专有巨头。

主要结果如下表所示，揭示了 LLM 现状的残酷现实。

不同 LLM 在 AppBench 上的主要结果。

  • (注: 参考论文原文中的表 3) *

结果的关键要点:

  1. 复杂性扼杀性能: 看看几乎所有模型的性能下降情况。
  • SS (简单) : GPT-4o 达到 70.92% 的成功率。
  • MM (复杂) : GPT-4o 仅达到 2.00% 的成功率。
  • 这是一个灾难性的下降。这表明，虽然模型擅长简单的工具使用，但在处理多个 App 和依赖关系时，它们会失去连贯性。

  1. GPT-4o 王者依旧 (但仍然失败) : GPT-4o 显着优于其他模型，这可能归功于其卓越的推理和指令遵循能力。然而，在复杂任务上 2% 的成功率表明它还不足以可靠地用于自主智能体工作流。

  2. 开源模型落后: 像 Mistral 和 Qwen (7B/14B) 这样的模型甚至难以正确格式化输出，在复杂任务上通常得分为 0%。然而，更大的开源模型如 LLaMA-3-70B 表现出竞争力，有时甚至击败 GPT-3.5。

深度分析

为什么这些任务如此困难？研究人员进行了多项分析以找出瓶颈。

1. 敌人是深度，而不仅仅是广度

研究人员分析了“顺序规模” (多少步骤必须按顺序发生) 与“并行规模” (存在多少独立任务) 如何影响性能。

如图 4 所示，性能在两个方向上都在下降，但顺序规模尤其具有惩罚性。依赖链越深，模型就越容易“迷失思路”或产生幻觉，编造出一个尚不存在的变量。

GPT-4o 的性能与并行及顺序规模缩放之间的关系。

2. 提示策略: 分层 vs. 扁平

向 LLM 展示可用工具有两种方式:

  • 分层 (Hierarchical) : 首先，让 LLM 选择一个 App。然后，仅向其展示该 App 的 API。 (有利于节省上下文窗口) 。
  • 扁平 (Flat) : 一次性将每个 App 的每个 API 都放入提示中。

令人惊讶的是, GPT-4o 在扁平提示下表现更好 (下图中绿线) ，这可能是因为其巨大的上下文窗口允许它看到“全貌”并更有效地规划依赖关系。然而，GPT-3.5 在扁平设置下遭受了“信息过载”，在分层分解任务时表现更好 (红线) 。

分层提示与扁平提示在性能上的差距。

3. 它们究竟败在哪里？

表 4 中的错误分析很有启发性。模型通常不会在选择正确的 App 上失败 (App 选择相对容易) 。

失败发生在参数层面 , 特别是依赖值 (D-Values) 。 模型难以正确地将 API_A 的输出链接到 API_B 的输入。它们在“时空”推理方面也很挣扎——例如，计算如果火车下午 2:00 到达，汽车接送应该在下午 2:15。

GPT-4o 在 AppBench 上的错误分析。

我们能修复它吗？微调与上下文学习

如果基础模型失败了，我们能教它们变得更好吗？

微调

研究人员在 AppBench 数据集的训练集上微调了 LLaMA-3-8B 。 正如预期的那样，微调提高了“格式化”指标 (App 和 API 的 F1 分数) 。模型完美地学会了任务的语法。

然而，观察图 6 底部图表中的成功率 (Succ) , 对于复杂任务的提升微乎其微。微调有助于模型“讲好基准测试的语言”，但这并不一定赋予它解决复杂依赖逻辑的推理能力。

原始 LLaMA3-8B 与微调版本之间的性能差距。

上下文学习 (少样本提示)

如果我们只是在提示中给模型一些示例 (3-shot, 5-shot) 会怎样？

表 5 显示，对于 GPT-4o，提供示例在简单 (SS) 类别中有显著帮助 (从 70% 跃升至 81%) 。然而，对于复杂的 MM 类别，成功率停滞在 2-3% 左右。规划图的复杂性似乎超过了可以通过提示中的几个静态示例所能传授的范畴。

GPT-4o 在 AppBench 上的上下文学习结果。

结论与启示

AppBench 为 AI 行业提供了一次现实检验。它表明，虽然我们已经掌握了“聊天机器人”和“单工具智能体”的艺术，但在构建能够驾驭现实世界应用程序混乱、互联生态系统的元规划者方面，我们仍处于早期阶段。

论文强调，主要的瓶颈不仅仅是识别用户意图，还在于管理依赖关系 (图结构) 和处理多样化的来源 (权限隔离) 。

对于学生和研究人员来说，这开启了未来工作的激动人心的新方向:

  1. 智能体框架: 我们能否构建“系统 2”思维层，在生成代码之前显式地绘制出依赖图？
  2. 自我修正: 智能体能否学会“编译”它们的计划，捕捉依赖错误并重试？
  3. 混合架构: 将 LLM 与符号规划器结合，以处理 API 数据流的严格逻辑。

在解决这些挑战之前，我们的 AI 助手可能仍然只能帮我们查查天气，而在规划假期方面依然不值得信任。

本基准测试中使用的 App 和 API 完整列表如下所示，展示了模型测试所涉及的多样化领域。

AppBench 中所有 App 及其对应 API 的列表。