🤖 AI

PluginEval: A Diagnostic Benchmark for Fine-Grained Error Attribution in Function Calling

本文介绍了 PluginEval，这是一个诊断基准，它采用了一个结合了 LLM 生成与确定性 API 执行的两阶段框架，旨在系统地解决数据分布差异和缺乏对抗性测试的问题，从而实现针对大语言模型工具路由评估的细粒度错误归因。

原作者： Dongjie Xu, Julius, Hanchi Dong, Minghua Tang, Yuxuan Sun, Ziwei Nie, Zicheng Liu, Dujun Qing, Jiajie Xu

发布于 2026-08-11

📖 1 分钟阅读☕ 轻松阅读

原作者： Dongjie Xu, Julius, Hanchi Dong, Minghua Tang, Yuxuan Sun, Ziwei Nie, Zicheng Liu, Dujun Qing, Jiajie Xu

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

想象一下，你正在教一个非常聪明、非常热心的机器人管家如何使用一个装满了数千种不同小工具的巨大工具箱。你告诉机器人：“我饿了”，它必须决定三件事：首先，它是否真的需要使用工具，还是可以直接想到一种零食？第二，如果它需要工具，哪一个特定的工具才是正确的（是一个搅拌机，而不是一把锤子）？第三，它能否实际抓取那个工具并正确使用它而不将其损坏？这就是人工智能中的“函数调用”（function calling）领域。这项技能让 AI 模型不再仅仅是聊天，而是开始真正地“做事”，比如预订机票或查询天气。但问题的关键在于：仅仅因为机器人说了正确的词，并不意味着它选对了工具或使用正确的方式。我们需要一种方法来测试它是真的聪明，还是仅仅运气好。

这正是开发 PluginEval 的研究人员试图解决的问题。他们注意到，目前大多数针对这些 AI 机器人的测试就像是一个驾驶考试，而每个人拿到的都是一个简单、空旷的停车场。这些测试缺乏棘手的场景，无法捕捉到机器人失败的具体方式，并且通常依赖于其他机器人来给答案评分，这可能会产生偏差。因此，团队构建了一个全新的、难度更高的“驾驶考试”，专门针对中文查询。他们创建了一个系统，不仅看最终得分，还像侦探一样，找出机器人失败的究竟原因：是它忘了带工具，是它抓错了工具，还是它尝试使用正确的工具却把食材弄洒了？

侦探的工具箱：他们是如何构建测试的

为了构建这个新的基准测试，作者们并没有只是写下一堆问题然后听天由命。他们发明了一个“闭环构建框架”（PCCF），这是一种高级说法，意指他们构建了一个用于制作测试的自我修正机器。

把它想象成一个游戏关卡设计师，不断地重玩一个关卡直到它变得完美。

第一阶段（现实检查）： 首先，他们拿出一个问题（例如“帮我找一张去东京的便宜机票”），并要求几个 AI 模型尝试解决它。但这里的转折在于：他们并不只是相信 AI 的话。他们实际上会运行代码。如果 AI 说“我要调用航班 API”，系统就会尝试进行该调用。如果 API 返回“错误：缺少日期”，系统就知道 AI 失败了。这区分了“想法”与“现实”。
第二阶段（缺口填充）： 系统随后查看结果，并询问：“我们在哪里缺少棘手的问题？”也许测试中关于天气的简单问题太多，而关于预订复杂行程的难题太少。系统随后会生成新的、更难的问题，专门用来填补这些空白。它会创造“对抗性”问题——即旨在诱导 AI 犯错的陷阱。
循环： 这些新的、棘手的问题会回到第一阶段再次接受测试。如果它们太容易，系统就会让它们变得更难。如果它们太令人困惑，系统会利用识别证据在重新验证之前强化负面示例。这个循环会不断旋转，直到测试涵盖了 AI 可能感到困惑的所有可能方式，从简单的错误到复杂的逻辑陷阱。

判决：测试揭示了什么

一旦他们拥有了完美的测试（其中包括 3,000 个经过人工验证的问题，涵盖 54 种不同的工具），他们将世界上最聪明的五个 AI 模型投入了测试。其中包括 GPT-5.4、Claude 4.6 和 Gemini 3.1 Pro 等知名模型。

结果令人警醒。作者发现，综合得分（最终成绩）具有误导性。

难度陷阱： 当测试主要是简单问题时，所有的 AI 看起来都像天才，得分超过 80%。但一旦遇到“困难”问题，得分就会骤降。对于最难的问题，即使是最优秀的 AI 也只有大约 10% 的正确率。这表明目前的模型非常脆弱；它们在处理简单任务时表现出色，但在事情变得复杂时就会崩溃。
不同模型的不同缺陷： 论文并没有仅仅说“模型 A 更好”。它像机械师检查汽车引擎一样拆解了错误。
- GPT-5.4 在识别所需工具和避免不必要调用方面表现最差，同时表现出最高的“漏召回”（忘记使用需要的工具）和“过召回”（在不该使用工具时使用了工具）率。
- Claude Opus 4.6 在记住使用工具方面表现最好（漏召回率最低），但有时会在不该使用时使用工具（过召回率高）。
- Gemini 3.1 Pro 拥有最平衡的错误分布，实现了最低的“过召回”率，这有助于它在召回率低于 Claude 的情况下仍保持具有竞争力的准确性。
“时间”问题： 每种模型都出现了一种特定的错误类型：时间错误（Temporal Errors）。无论是询问“下周二”还是“上个月”，AI 在处理日期和时间方面始终难以准确。这是所有模型中最主要的失败来源。

为什么这很重要

论文认为，我们不能仅仅通过一个百分比来判断一个 AI 使用工具的能力。一个模型得分高，可能是因为它擅长简单问题，也可能是因为它运气好。通过使用他们新的“金标锚定”（Gold-Anchored）评判系统——即将 AI 的答案与经过人工验证的“金标准”进行对比，而不是与另一个 AI 的猜测进行对比——他们能够精准定位机器人到底在哪里失败。

作者们建议，要制造真正可靠的 AI 智能体，我们不能再把它们当作一个要么成功、要么失败的“黑盒”。相反，我们需要像医生诊断一样去诊断它们：检查它们是漏掉了一个步骤，还是抓错了工具，或者仅仅是时间搞错了。他们的工作表明，虽然今天的 AI 功能强大，但仍存在显著的盲点，尤其是在任务变得困难或时间要求变得复杂时。这篇论文并不声称已经“解决了”AI 工具使用问题，但它提供了第一张关于机器人哪里会绊倒的真实地图，以便我们可以帮助它们走得更稳。

技术摘要：PluginEval

问题陈述

随着大语言模型（LLMs）日益作为自主智能体发挥作用，对工具路由（函数调用）进行可靠评估变得至关重要。目前的基准测试存在三个结构性局限：

数据分布偏差： 幂律分布导致稀有场景和边缘情况代表性不足。
缺乏对抗性严谨性： 缺乏硬负例（hard negatives）掩盖了模型之间的性能差异。
未经验证的标注流水线： 许多基准测试依赖于尚未通过实际执行验证的 LLM 判断来进行标注，这可能导致尽管结构正确但存在语义错误。

此外，现有的基准测试通常关注聚合成功率或调用语法，未能诊断特定的失败模式，例如漏掉工具调用、冗余调用或参数落地（grounding）错误。目前迫切需要一种能够结合可靠的、基于执行的标注，以及针对触发与排除边界进行结构化覆盖的基准测试，特别是针对经常具有歧义或依赖上下文的中文查询。

方法论：PluginEval 闭环构建框架 (PCCF)

本文引入了 PluginEval，这是一个通过两阶段闭环框架（PCCF）构建的基准测试，旨在将标注可靠性与覆盖需求解耦。

任务形式化

工具路由被形式化为一个包含三个决策的层级结构：

必要性 ( $f_1$ )： 是否需要工具？
相关性 ( $f_2$ )： 目标插件是否相关？
调用 ( $f_3$ )： 请求能否被落地为有效的调用并带有正确的参数，还是必须被拒绝？

第一阶段：基于执行的集成标注

此阶段侧重于为真实和合成查询建立可信的标注。

生成： 多个生成器独立提出完整的调用方案。
验证： 提议需经过多步验证过程：
- 确定性 Schema 验证： 检查结构有效性。
- 参数评估： LLM 评估器检查参数是否由查询支持，并与插件语义一致。
- 执行： 通过 MCP（模型上下文协议）执行提议。
- 结果评估： 独立的评估器检查执行响应是否满足用户请求。
精炼循环： 因违反 Schema、执行错误或语义不匹配而导致验证失败的提议将被保留为追踪记录（traces）。这些追踪记录连同独立的评估器评分，会被反馈给生成器进行精炼。该过程重复执行，直到提议达到置信阈值 $\tau$ 或被判定为合理的弃权，最大循环次数为 $R_{max}$ 。

第二阶段：基于场景的合成与行为校准

此阶段解决覆盖范围缺失和难度校准问题。

场景分解： 将插件分解为触发场景（支持的请求）和排除场景（不需要工具、需要其他工具或超出能力的请求）。
定向合成： 系统识别覆盖不足的单元（能力、意图与边界的组合），并合成新的查询以填补这些空白。
难度校准：
- 正例： 难度基于推理深度（0、1 或 $\ge$ 2 步）。
- 负例： 难度基于行为证据进行校准。一个冻结的参考路由模型会对合成的负例进行 $K$ 次评估。如果路由模型持续无法拒绝该负例（高假阳性率），则该示例被视为“难”；如果能轻易拒绝，则为“易”。
闭环： 合成的示例返回至第一阶段进行验证。循环持续进行，直到满足覆盖预算或改进进入平台期。

评估框架：金标锚定的评判器 (Gold-Anchored Judge)

为了超越聚合准确率，本文采用了金标锚定的 LLM 评判器：

输入： 预测的调用、经人工验证的金标调用以及用户查询。
约束： 评判器将金标调用列表视为唯一的锚点。它不能扩展或覆盖金标规范。
层级化验证：
1. 工具对齐： 匹配预测与金标之间的工具名称。
2. 参数过滤： 确保参数集非空且具有可比性。
3. 语义验证： 确定预测的参数在查询意图下是否与金标参数语义等价（允许别名和格式变化，但严格评估时间范围）。
错误归因： 失败被分类为互斥的类别：
- 漏召回 (Miss Recall)： 缺失必要的工具。
- 参数错误 (Parameter Error)： 语义错误的参数（细分为时间错误、缺失参数、数值错误）。
- 过召回 (Over Recall)： 在负例查询上产生冗余的工具激活。

核心贡献

PluginEval 基准测试： 一个包含 3,000 个经人工验证实例的中文函数调用基准测试，涵盖 54 个插件、63 个工具和 9 个领域。它具有明确的触发/排除场景、三种类型的边界负例以及基于行为校准的难度。
PCCF 框架： 一种闭环构建方法，通过执行驱动的验证实现标注可信度与覆盖需求的解耦。它利用 Schema 验证、独立评估和工具执行来修复标注。
细粒度错误归因： 一个评估框架，将失败归因为特定原因（漏召回、参数错误、过召回），而非仅仅依赖聚合成功指标。
实证分析： 对五种前沿 LLM（包括闭源和开源模型）的评估表明，聚合得分对难度组成高度敏感，且模型表现出截然不同的失败特征。

结果

本文评估了五种模型：GPT-5.4, Claude 4.6, Gemini 3.1 Pro, DeepSeek-V4-Pro, 和 Qwen3-235B-A22B。

性能敏感性： 聚合性能高度依赖于难度分布。在原始分布（40% 易、40% 中、20% 难）下，Claude Opus 4.6 表现最佳（召回率 67.60%，准确率 68.17%）。然而，在“难”实例上的性能显著下降（各模型的召回率降至 2.8%–10.8%）。
难度影响： 将分布转向易例权重（60% 易）显著提升了所有模型的表现（召回率提升了约 15–21 个百分点），这表明如果缺乏严格校准，现有基准测试可能会高估模型能力。
与现有基准对比： 模型在 PluginEval 上的表现普遍低于 BFCL、APIBench 或 NexusRaven。例如，Claude Opus 4.6 在 BFCL 上的召回率为 73.04%，而在 PluginEval 上降至 67.60%。这表明 PluginEval 捕捉到了更具挑战性、更真实且更具对抗性的场景。
错误特征：
- GPT-5.4： 表现出最高的漏召回率 (33.72%) 和最高的过召回率 (33.20%)，表明其在识别所需工具和避免不必要调用方面都存在实质性困难。
- Claude Opus 4.6： 具有最低的漏召回率 (13.95%)，但过召回率较高 (29.10%)，虽高于 Gemini 但低于 GPT-5.4。
- Gemini 3.1 Pro： 实现了最低的过召回率 (18.55%)，在较低的召回率下仍保持了竞争力的准确率。
- 时间错误： 在所有模型中，时间落地错误是最频繁的参数错误子类型，表明模型在处理基于时间的约束方面存在共同弱点。
可靠性： 人工审计确认，参考标注和评判归因具有高度一致性（Fleiss' $\kappa$ 高达 0.9451），验证了基准测试的可靠性。

重要性与主张

本文声称 PluginEval 解决了工具路由中诊断性评估的空白。通过超越聚合成功率，它揭示了：

聚合得分掩盖了不同的失败模式： 总体得分相似的模型可能因完全不同的原因（如工具选择 vs. 参数落地）而失败。
难度组成至关重要： 性能排名会根据易例与难例的比例而变化，因此需要基于模型行为的校准难度标签。
执行对于信任至关重要： 通过实际 API 执行和 Schema 检查来验证标注，对于确保语义正确性（而非仅仅是语法有效性）是必要的。

作者总结道，结构化的错误归因对于指导开发更鲁棒的智能体系统是必要的，并且他们的闭环框架为构建此类诊断性基准测试提供了一种可复现的方法。