VAKRA：IBM开源8000+真实API基准，大模型多跳跨源推理准确率断崖下跌超50%

VAKRA: Evaluating Multi-Hop Reasoning Across APIs and Retrieval Under Tool-Use Policies

论文原文 ↗ 论文发布 2026-08-12 解读发布 2026-09-07 解读：AI前沿分享

在各类大模型榜单上，函数调用（Function Calling）与单步工具调用的准确率往往显得格外亮眼。动辄 90% 以上的准确率，很容易让人产生一种错觉：大语言模型（LLM）驱动的自主智能体（Agent）似乎已经完全具备了在复杂系统内部自由穿梭的能力。

ArXiv URL：https://arxiv.org/abs/2608.12282v1

然而，一旦将模型置于真实的企业级工作流中，这种乐观预期通常会迅速破灭。真实的企业场景既包含高度结构化的业务数据库（以各类内部 API 的形式暴露），又包含非结构化的文档知识库（规章制度、工单记录、操作手册）。一个看似简单的“查询延误订单并确认赔偿标准”的任务，往往需要智能体跨越多个系统，经历多步状态依赖的推理，甚至还要严格遵守复杂的自然语言操作权限或业务规范。

为了探究模型在真实异构环境中的底色，来自 IBM 的研究团队推出了名为 VAKRA（eValuating API and Knowledge Retrieval Agents）的全新基准测试。该基准涵盖 62 个业务领域、包含超过 8000 个可执行的真实 API，并引入了跨源知识检索与自然语言工具使用策略（Tool-Use Policies）。

评测结果揭示了一个残酷的事实：哪怕是业内顶尖的前沿模型，在处理最简单的单跳端点 API 时准确率也仅勉强达到 70.4%，切换到组合式商业智能 API 时直接滑落至 50% 左右；随着推理链条拉长至 2 到 5 跳，大多数模型的准确率断崖式下跌超过 50%；更令人警惕的是，当业务策略明确指出某些问题受限而不可回答时，模型准确率甚至会暴跌至 2.4%。

详细的错误轨迹分析表明，限制 Agent 落地的真正瓶颈，早已不是模型能否输出合法的 JSON 语法或调起工具，而是隐匿在操作背后的“语言中介推理”（Language-Mediated Reasoning）——实体消歧、跨源数据对齐与业务约束理解。

从单点工具调用到异构长链的质变

在过往的 Agent 评测体系中，研究者往往将各项能力拆解成孤立的单项测试：要么专注于单独一轮的 API 参数填充，要么专注于网页点击与导航，要么专注于基于长文本的多跳检索（RAG）。然而在实际业务落地中，这些能力从来不是切片式孤立存在的。

以典型的企业客户支持场景为例，上图清晰呈现了智能体在处理延误订单投诉时必须攻克的连续关卡：

API 驱动的实体消歧：用户只提供了模糊的客户名称或片面的描述，Agent 需要先调用 CRM 系统的查询接口，从多个同名或相似的记录中精准锁定目标客户实体。
跨源信息接地（Cross-Source Grounding）：在定位客户后，Agent 需要从承运商提供的非结构化物流说明中提取出对应的物流单号。
参数对齐与状态传递：不同系统之间的命名规范往往完全脱节。例如，在承运商文档中被称为“Tracking ID”的字段，到了下游内部物流追踪 API 中可能变成了“consignment_no”，Agent 必须自主识别并将其映射为合规参数。
自然语言策略推理：最终确认了延误时长后，Agent 还必须结合非结构化的售后补偿政策，推断出该情境下到底应该退款、补偿代金券还是拒绝受理。

在这一系列流程中，前一步的输出动态决定了后一步的输入，任何一个中间状态的理解偏差都会引发雪崩式的级联失效。

为了彻底复原这种复杂性，VAKRA 基于 BIRD-SQL 衍生出的真实数据库生态，构建了覆盖金融、医疗、供应链等 62 个领域的 8000 余个可执行 API。为了支持跨源交互，研究人员还为每个领域构建了与业务对齐的非结构化向量检索库（结合了 ClapNQ 与 Wikidata5M），并设计了 2 到 5 跳的长推理链条，要求 Agent 在同一个推理轨迹中同时与结构化接口和非结构化检索打交道。

三重进阶难度：重新审视 API 交互范式

不仅是在长链推理上设卡，VAKRA 还首次系统性地探讨了不同的 API 接口设计风格对 Agent 推理能力的剧烈冲击。在企业软件架构中，并没有统一的工具抽象规范，VAKRA 将任务划分为三个难度递增的梯度：

1. 三种截然不同的 API 交互范式（API Styles）

SLOT 风格（组合式接口）：提供极少数（如 9 个）通用的底层操作算子（例如数据过滤、聚合、表连接、格式转换）。这种设计下，Agent 可选的工具极少，但每一步都需要自行在头脑中规划出复杂的数据流转管道，并逐一填入大量参数。
SEL 风格（扩展功能接口）：将底层通用函数与不同场景进行特化绑定，抽象成更多数量的具体工具（约 26 个候选工具）。单次调用的复杂度降低了，但 Agent 在工具选择上的搜索空间被放大。
Dashboard APIs（端点式接口）：提供高度定制化、面向具体业务看板的现成 REST 风格端点。工具候选池急剧膨胀（单个任务可能提供高达 116 个备选工具），系统把复杂的计算隐藏在后端，考验的是 Agent 在海量候选池中的语义检索与参数提取能力。

2. 多跳结构化长链推理（Multi-hop Reasoning）

在这一层级，Agent 必须面对 2 至 5 步的深层 API 链条。上一步工具返回的 JSON 结构需要经过解析，提取出关键实体或标识符，并转换为后续接口的输入参数，中间伴随着模式对齐（Schema Alignment）与中间结果的过滤重组。

3. 跨源多跳与自然语言策略约束（Multi-hop Multi-Source Reasoning）

这是最具挑战性的终极场景。Agent 不仅要处理结构化 API，还必须主动判断何时调用检索工具访问非结构化文档集合，并从杂乱的自然语言文本中提取准确参数喂给后续 API。更关键的是，研究团队引入了工具使用策略：以自然语言明确约束哪些工具是允许的、哪些数据源是禁止访问的、以及在何种业务边界下该问题不可由当前权限解答。

摒弃评测噪声：固定 ReAct 架构与真机动态执行

在过去的基准测试中，往往存在一个饱受争议的问题：测试成绩究竟反映的是底层大模型的通用推理能力，还是特定 Agent Harness（如预置的复杂规划器、反思框架、特定 Prompt 模版）的工程工程红利？

为了剔除这一变量，VAKRA 做出了一项关键技术取舍：冻结 Agent Harness，统一采用极简的 ReAct 循环。

所有接入测试的模型——无论是 GPT-5.5、Claude 还是各类开源大模型——均运行在基于 LangGraph 实现的标准化 ReAct 循环中。智能体在每个时间步只遵循最朴素的“思考（Thought）—行动（Action）—观察（Observation）”机制。模型不会被提前告知需要经历多少跳、是否需要检索，只能完全依据当前的上下文、工具库定义及策略文本自主摸索。这一设定不仅消除了工程框架差异带来的评测偏差，还利用 ReAct 强制输出思考过程的特性，为后续分析模型决策断点提供了高质量的追踪记录。

此外，在评测验证机制上，VAKRA 摒弃了仅比对最终输出文本语义相似度的弱验证方式，而是采用了端到端动态重执行机制（Live Re-execution）。

整个评测环境被封装于独立的 Docker 容器中，后端以真实的 SQLite 数据库与基于 IBM Granite 嵌入模型的 ChromaDB 向量库作为支撑，通过统一的模型上下文协议（Model Context Protocol，MCP）暴露给 Agent。评测系统不会机械地要求模型走出预设的唯一路径，而是会将模型实际预测出的工具调用序列直接在真实环境中重新执行。只要模型的中间调用合法、最终返回的数据状态和逻辑完备，即便采用了不同的路径也会被判定为正确。

为了精准捕获故障点，评估采用了多级“漏斗筛查”（Waterfall Sieve）机制：从工具名称是否正确，到参数键名是否正确，再到参数取值是否匹配，直至最终推理答案是否完全被事实支撑，层层截断。

实验结论：推理深度的剧烈衰减与策略盲区

基于上述严苛的环境，研究团队对当前的主流闭源商业模型与开源权重模型进行了全面测评，揭示出若干颠覆预期的现象。

1. 交互范式引发的能力错位与排名倒挂

在单一的 Dashboard API 任务中，前沿模型的表现尚可，最强的 GPT-5.5 取得了 70.4% 的完成率。然而，当面对需要显式规划数据流的 BI 商业智能接口（SLOT 和 SEL）时，顶尖模型的准确率普遍急剧跌落至 50% 到 51%。

更有趣的是，模型在不同 API 风格下的能力排名出现了明显的倒挂。例如，部分中等体量的开源模型（如 Granite-4h-small）在面对组合式 BI 接口时表现极其糟糕，但切换到端点式 Dashboard API 时，却反超了数个规模远大于自身的开源巨模（包括部分参数量在数百 B 级别的庞大模型）。这直接证明了：并不存在一种普适的“工具调用基底能力”，应对扁平工具集与应对深度组合算子所需的认知路径截然不同。

2. 多跳长链下的性能“腰斩”

正如上方模型在不同推理深度下的表现趋势图所示，所有模型的准确率曲线均随着跳数（Hop Count）的增加呈现出陡峭的下坠走势。

在从 2 跳扩展至 5 跳的过程中，绝大部分模型遭遇了超过 50% 的性能损耗。推理链条每拉长一步，累积的不确定性就会以乘法效应侵蚀系统的可靠性。即便是在单跳场景下看似能够自洽行动的模型，一旦需要面对“先调用接口 A 获取中间 ID、再以此为参数结合接口 B 过滤、并从结果中提取实体去检索文档 C”的长依赖时，就会不可避免地陷入状态丢失或目标漂移。

3. 策略约束与“不可回答”查询的全面失守

引入自然语言工具使用策略后，模型的表现更是遭遇了滑铁卢。企业落地中最常见的合规要求，就是明确划定智能体的操作边界。在 VAKRA 的评测中，研究团队特意设置了由于策略约束而实际上“不可回答”（Unanswerable）的负样本测试。

在面对这种要求模型“知所不可为”的场景时，即便是最顶尖的前沿模型也表现出严重的拒答失效，在部分不可回答查询上的准确率甚至骤降至 2.4%。绝大多数模型在面临自然语言业务禁令时，依然表现出强烈的盲目调用冲动，试图绕过限制去强行猜测结果，这给企业级落地的安全性带来了极大的隐患。

深入轨迹深处：究竟卡在什么地方？

为了搞清楚大模型在多跳工具使用中究竟折戟于何处，研究人员进一步深入执行轨迹的细粒度漏斗分析。

在很多人的直觉中，模型使用 API 最容易出现的问题是“格式错误”：要么拼错了工具名，要么输出了不合法的 JSON 语法，或者把参数字段的拼写弄错了。但 VAKRA 的细粒度追踪完全推翻了这一假设。

在 SEL 风格的调用分析中，数据显示：只要模型正确锁定了目标工具的名称，后续成功填充参数名称（ArgN）和参数值（ArgV）的比例几乎保持平缓，并没有发生显著流失。这表明当代大模型在单纯的格式依从、工具契约理解等“机械操作层面”已经高度成熟。

真正的致命崩溃集中在更高维度的语言中介推理（Language-Mediated Reasoning）：

实体消歧失败：面对上游步骤返回的包含多个相似属性的数据包，模型难以依据用户的原始诉求建立稳定的实体关联，常常张冠李戴。
跨源信息接地（Cross-Source Grounding）断裂：在纯 API 链条走到最后一步时，大模型在答案提取与接地上的错误占比约为 40% 到 45%；而一旦任务形态转变为“先通过检索（RAG）从长文档提取线索，再作为参数去调用 API”时，这部分的错误占比瞬间飙升到了 70% 至 75%。模型极难从非结构化文字中稳定抽取出与后端数据库严格对齐的规范化参数值。
模式对齐的语义裂痕：当接口文档中的参数命名出现细微的语义跳跃时，模型过度依赖字面层面的精确重合，缺乏在业务上下文中进行自适应映射的鲁棒性。

从单纯调用工具，走向深层组合推理

VAKRA 的开源与评测成果，为当下火热的 AI Agent 研发注入了一剂清醒剂。

长久以来，学术界与工业界在工具调用能力的衡量上存在一定程度的“低维化倾向”——大家习惯于在格式合规率、单步执行成功率等浅层指标上卷出高分，进而误以为通往企业级自主智能体的道路只剩下工程接口的打通。

但 VAKRA 清楚地证明：让大模型学会调起一个 API 只是万里长征的第一步。在由成百上千个复杂接口、杂乱的企业知识库以及充满自然语言边界约束构成的真实世界里，决定系统能否存活的核心矛盾，在于模型在长链状态迁移中能否完成高密度的跨源实体消歧、深度的模式映射，以及对业务策略的绝对敬畏。

如果底层模型的多跳组合推理能力与业务约束理解力没有取得根本性突破，单纯在外部架构上堆叠复杂的工程套件，或许依然无法填平这高达 50% 甚至更深的性能断崖。