🤖 machine learning

Benchmarking Web API Integration Code Generation

本文介绍了 WAPIIBench，这是一个数据集和评估流水线，揭示了当前的开源大语言模型在生成正确的 Web API 集成代码方面存在显著困难，由于端点幻觉和参数使用错误等问题，其成功率不足 40%。

原作者： Daniel Maninger, Leon Chemnitz, Amir Molzam Sharifloo, Jannis Brugger, Mira Mezini

发布于 2026-07-07

📖 1 分钟阅读☕ 轻松阅读

原作者： Daniel Maninger, Leon Chemnitz, Amir Molzam Sharifloo, Jannis Brugger, Mira Mezini

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正在试图教一个非常聪明、博学多才的机器人如何从一份极其庞大且复杂的餐厅菜单中点一份特定的餐点。这份菜单不仅仅是一份菜品清单；它还包含了一套严格的规则，关于你应该如何写下你的订单、按下哪些按钮，以及必须列出哪些精确的配料。如果你哪怕错了一个细节，厨房都会退回你的订单。

这篇论文探讨的是如何测试这些“机器人”（实际上是大型语言模型，即 LLM——也就是 AI 聊天机器人背后的技术）在编写代码以向真实的 Web 服务（如 Google 日历、Slack 或 Asana）发送这些“订单”时的表现。

以下是研究人员的工作内容及其发现，我使用了简单的类比来进行说明：

问题所在：“魔法”尚未真正实现

开发者使用“Web API”来让不同的软件进行通信。这就像是将乐高积木连接在一起。通常情况下，人类必须编写指令来将这些积木拼装起来。人们曾希望 AI 可以自动完成这项工作。

研究人员提出了这样一个问题：AI 能否在看到一个简单的请求（例如“在我的日历中添加一个新事件”）后，编写出完美且无误的代码来实现这一目标？

实验过程：为 AI 打造一场“驾驶考试”

为了测试这一点，团队构建了一个名为 WAPIIBench 的特殊测试。你可以把它看作是针对 AI 的一场“驾驶考试”。

赛道： 他们利用四个流行的真实世界服务（Asana、Google 日历、Google 表格和 Slack）创建了 395 个特定的“驾驶场景”。
规则： 他们使用了这些服务的官方“驾驶手册”（OpenAPI 规范），以确保准确掌握一个正确的订单应该是怎样的。
测试： 他们给 AI 一个提示词（例如“创建一个新日历”），并要求它编写代码。
检查： 研究人员并没有仅仅通过阅读代码来查看其“看起来”是否正确，而是实际在安全受控的沙盒环境中运行了这些代码。如果代码尝试向不存在的地址发送订单，或者使用了错误的配料，则测试失败。

结果：AI 经常迷失方向

对于那些期待实现即时自动化的人来说，结果有些令人失望。

得分： 即便是表现最好的开源 AI 模型，也只能完全正确地完成约 30% 到 40% 的任务。表现最好的商业模型（GPT-4o）稍好一些，达到了 60-77%，但这仍然意味着它在近三分之一的情况下失败了。
“幻觉”问题： 这是最大的问题。AI 经常会凭空捏造信息。
- 虚假地址： AI 会发明不存在的 URL 地址（比如在餐厅实际位于“主街 456 号”时，却告诉出租车司机去“虚构街 123 号”）。这种情况在高达 39% 的案例中发生了。
- 错误的配料： AI 会包含该服务并不接受的参数（配料），或者遗漏了必须具备的参数。
部分成功： AI 擅长记住代码的“大致轮廓”（例如知道它需要使用 POST 方法，这就像是知道你需要“下单”而不是“取消订单”）。但当涉及到具体的细节——即要把东西发往“哪里”以及“具体要说什么”时，它在整合这些碎片信息方面表现挣扎。

一些令人意外的转折

并非越大越好： 有时，一个中等规模的 AI 模型表现得比一个极小的模型和一个极大的模型都要差。这就像是一个学生为了考错的试而学习过度，结果反而搞混了。
记忆 vs. 理解： AI 似乎“背诵”了其训练数据中的部分手册内容。它知道一些 URL 和参数名称，但无法可靠地将它们组合起来以解决一个新的、特定的问题。这就像一个学生背下了去年的数学考试答案，却无法解决今年的题目。
“填空”技巧： 当研究人员给出正确的地址（URL）并仅要求 AI 填充剩余部分时，AI 的表现要好得多。这表明，如果不需要先去猜测目的地，AI 是懂得如何遵循指令的。

核心结论

论文得出结论：虽然 AI 在编写代码方面正在进步，但它尚未可靠到可以在没有人类监督的情况下自动连接软件系统。如果你现在让 AI 编写代码来连接你的业务应用与互联网，它大约有 60% 到 70% 的概率会将你的数据发送到错误的地方，或者导致连接中断。

研究人员表示，在我们能够信任 AI 自主构建这些连接之前，我们需要更好的安全检查机制，以及新的方法来帮助 AI 在实时“查阅”规则（而不是仅仅依赖记忆）。

技术摘要：Web API 集成代码生成基准测试

问题陈述

Web API 集成是现代软件基础设施的基础组成部分，然而，为开发者编写用于调用这些 API 的正确代码仍然是一项具有挑战性且繁琐的任务。尽管大语言模型（LLMs）在自动化软件开发方面展现出了显著潜力，但它们在生成Web API 调用代码方面的具体效能仍很大程度上未被探索。与本地函数调用不同，Web API 调用涉及复杂的语法，包括特定的 HTTP 方法、参数化 URL、请求体、请求头以及查询参数，这些内容通常记录在外部规范（如 OpenAPI）中，而这些规范并不总是能被包含在模型的上下文窗口内。

本文旨在解决的核心研究问题是：LLM 生成的 Web API 调用代码的正确性如何，以及此类代码中常见的错误类型有哪些？

方法论

为了回答这个问题，作者引入了 WAPIIBench，这是一个旨在系统评估该领域 LLM 能力的新型数据集和评估流水线。

1. 数据集创建 (WAPIIBench)

该数据集包含 395 个任务-配置对，这些对项源自四个遵循 OpenAPI 标准的真实世界 API：Asana、Google Calendar、Google Sheets 和 Slack Web。

合成： 不同于从现有代码仓库中获取数据（后者往往缺乏明确的任务描述），作者使用 Gemini 1.5 Pro 合成了任务。模型被提供了完整的 OpenAPI 规范和详细指令，以生成自然语言任务描述 ( $t$ ) 以及对应的地面真值（ground-truth）请求配置 ( $c$ )。
验证： 生成的数据经过严格的自动化和人工策展，以确保每个任务都有唯一的、可解的配置，并且参数能够正确反映。
结构： 每个样本代表一个 API 端点，捕捉了 HTTP 方法、URL 以及参数（请求体、请求头、查询参数）。

2. 评估流水线

评估遵循四个阶段的过程：

代码生成： LLM 的任务是根据任务描述完成起始代码（使用 Axios 库的 JavaScript）。测试了两种设置：
- 全量完成 (Full Completion)： 模型必须生成 HTTP 方法、URL 以及所有参数。
- 参数完成 (Argument Completion)： 模型被提供正确的方法和 URL，只需生成参数。
代码执行： 生成的代码在一个受控的沙盒环境（Mock）中执行，该环境会拦截传出的请求。这种方法优先考虑功能正确性而非语法相似性，从而捕捉代码实际发送的请求配置 ( $c'$ )。
正确性分析： 将捕获的配置 ( $c'$ ) 与地面真值 ( $c$ ) 进行比较，并根据 API 规范 ( $s$ ) 进行验证。
指标： 研究采用了细粒度的指标，包括：
- 正确实现 (Correct Implementations)： 匹配地面真值的可执行代码百分比。
- 非法实现 (Illegal Implementations)： 违反 API 规范的代码。
- URL/方法准确性 (URL/Method Accuracy)： 端点和 HTTP 方法的正确性。
- 参数精确度/召回率 (Argument Precision/Recall)： 参数名称和值的准确性。

3. 评估的模型

该基准测试评估了 21 个最先进的开源 LLM（包括 StarCoder、DeepSeek-Coder、Qwen-Coder、Code Llama 和 Llama 3.1），并结合商业模型（GPT-4o 和 GPT-4o mini）来建立性能基准。

关键结果

实验表明，生成正确的 Web API 调用代码对当前的 LLM 来说是一个重大挑战，即使是对最强大的开源模型也是如此。

整体正确性： 在评估的开源模型中，没有一个模型能解决超过 40% 的任务。
- 在全量完成设置下，表现最好的开源模型（Code Llama 70B）实现了 30% 的正确率，而 GPT-4o 达到了 60%。
- 在参数完成设置下（即端点已知时），Code Llama 70B 提升至 40%，而 GPT-4o 达到了 77%。
错误类型：
- 幻觉端点 (Hallucinated Endpoints)： 主要的失败模式是生成了错误或不存在的 URL。在全量完成设置中，高达 39% 的 URL 是非法的。
- 参数错误 (Argument Errors)： 模型经常幻觉出参数名称（高达 31% 的非法参数）或遗漏必要参数。
- 执行失败 (Execution Failures)： 由于语法错误或拒绝完成代码，若干模型（如 Qwen2.5-Coder、Llama 3.1）在全量完成设置中产生了不可执行的代码，导致其正确性指标为 0%。
模型行为：
- 模型在预测 HTTP 方法（GET/POST）方面通常表现良好，但在处理具有不受限性质的 URL 和参数时表现挣扎。
- 较大的模型并不总是优于较小的模型；在某些模型家族中，中等规模的版本表现甚至不如其较小和较大的版本。
- 性能在不同 API 之间存在显著差异，这可能与特定 API 在模型训练数据中的流行程度有关。

重要性与贡献

本文对软件工程和人工智能领域做出了三个主要贡献：

WAPIIBench 数据集： 这是同类研究中的首个数据集，包含近 400 个跨越四个真实世界 API 的 Web API 调用任务及预期结果对，专门为基于执行的正确性分析而设计。
开源评估流水线： 一种新型的、安全且自动化的流水线，用于使用细粒度指标评估代码生成模型在 Web API 任务上的表现，这些指标区分了语法正确性、规范合规性和功能成功。
实证见解： 本研究首次系统地证明，虽然 LLM 拥有一些关于 API 规范的记忆知识，但它们难以将这些知识综合为正确且符合规范的调用，而无需外部上下文。高频率的端点和参数幻觉凸显了当前模型在生产级 API 集成中的可靠性差距。

作者总结道，尽管 LLM 展现出了潜力，但局限性依然显著。他们强调，有必要将质量保证技术（如检索增强生成、微调或约束解码）集成到 AI 驱动的代码生成工作流中，以确保 Web API 集成代码的正确性和可靠性。该基准测试为改进这些能力的未来研究奠定了基础。