Data Agent Benchmark：企业多库问数智能体基准

本文是 arXiv 论文 Data Agent Benchmark（arXiv:2603.20576，CC BY 4.0）正文第 1 节至第 5 节的中文译文，由智测团队翻译。参考文献、附录 A 的逐条查询、附录 B 的提示词和附录 C 的失败轨迹样例未逐条译出。正文保留了论文主表中的通过率、费用和失败分类。

1 引言

企业里的用户越来越希望有数据智能体，也就是能用自然语言回答其数据问题的人工智能智能体。数据库厂商已经开始往平台里加智能体能力。组织也在重金自建。例如，Uber 的 QueryGPT 每个月处理超过 120 万次交互查询。OpenAI 建了一个内部数据智能体，供数千名员工查询 7 万个数据集，总量 600 PB。然而，可靠的数据智能体仍然难做。企业数据通常散落在多个数据库里。调查发现，72% 的组织把数据存在彼此分离的孤岛中，82% 报告这些孤岛扰乱了关键工作流。回答一个问题，常常要在若干个库之间整合和推理。

例如，销售分析师问：「上个季度哪些线索该跟进？」回答需要在客户关系管理工具里找到线索记录，到另一个文档库里匹配通话转写，从非结构化文本里判断每条线索的意图，再应用「什么样的线索值得追」这类领域知识。这些都要在同一次智能体会话里完成。

目前没有基准测量端到端的数据智能体能力。文本到 SQL 的基准测试的是：模型能不能把自然语言问题翻译成对单个关系数据库的一条正确查询。它们不要求多步推理，也不要求跨不同数据库整合。表格问答基准测试的是对直接放进提示词里的表做推理。生产里的表很少放得进上下文，必须直接对数据库查询。没有端到端基准，就无法系统地说数据智能体失败在哪里，以及最该补哪项能力。

新的数据智能体基准

作者因此提出 Data Agent Benchmark（DAB）。它是第一个在真实、复杂的数据任务上评测人工智能智能体的基准。为了让 DAB 反映生产负载，作者对 PromptQL 的企业客户做了形成性研究。PromptQL 由 Hasura 做生产数据智能体。行业有六个：技术、金融、餐饮、电商、SaaS 和医疗。他们收集用户向数据智能体提出的查询样例，以及模式描述、所用数据库系统、数据如何分布在这些系统上。

从这项研究里，作者找出四个让真实数据查询变难、而现有基准没有处理的性质。

（i）多数据库整合。一个问题可能要跨若干数据库查询，查询语言方言还不同，例如不同的 SQL 方言和 MongoDB 的查询语言。

（ii）格式不整齐的连接键。同一实体的标识在不同库里可能不一样，例如前缀不一致、尾部空白或缩写名称。智能体必须先发现并调和这些不一致，才能连接。

（iii）非结构化文本变换。答案可能嵌在文本字段里。智能体必须先把它们解析成结构化值，才能过滤、分组或连接。

（iv）领域知识。正确回答需要数据本身推不出来的专门知识。例如，股票波动率必须用调整后收盘价计算，才能计入拆股和分红。

把这些性质做成可复现的基准，需要仔细设计。DAB 有 54 条自然语言查询，分布在 12 个数据集、9 个领域、4 种数据库管理系统上。形成性研究里的企业数据是专有的，所以 DAB 用与那些行业对应的开源数据集来建。这些开源数据本身并不脏。挑战是有系统地扰动它们，使它们表现出生产里观察到的同样特征。

对每个数据集，作者把数据分布到至少两个数据库系统上，从 PostgreSQL、MongoDB、SQLite、DuckDB 里选，以对应形成性研究里用户把数据放在异构后端的方式。然后诱导其余性质：常常删掉能直接回答查询的列，把它们的值以别的形式保留下来，使恢复需要更多工作。连接键被重新格式化，使同一实体的标识在不同库里不同。结构化属性值被嵌进自由文本字段，智能体必须去解析。这些扰动必须足够真实、足够难，同时保留由原始数据导出的确定性地面真值，而不是由大模型生成或人工判断。12 个数据集都花了大量手工。每条查询、每个答案、每个数据集都由作者核验。DAB 的规模与其他精心策展、被广泛采用的基准相当，例如 FrontierMath 和 TerminalBench。

在 DAB 上评测前沿模型

作者用 ReAct 模式评测专有和开源前沿模型：GPT-5.2、GPT-5-mini、Gemini-3-Pro、Gemini-2.5-Flash 和 Kimi-K2。ReAct 让模型反复推理下一步，发出工具调用（数据库查询或 Python 脚本），观察结果，再决定下一个动作。每个智能体有列出可用数据库、对它们执行查询、运行 Python、返回最终答案的工具。每条查询对每个智能体跑 50 次独立试验，用 pass@k 估计 k 次尝试里至少一次成功的概率。

结果很严峻。最好的智能体 Gemini-3-Pro 只有 38% 的 pass@1。它的 pass@50，也就是 50 次尝试里任意一次正确的概率，也不超过 69%。有一个数据集完全没有被解开：所有试验里，没有任何智能体正确回答过它的任何查询。

评测还给出若干行为观察。探索模式和数据太少或太多都会变差。准确率最高的两个智能体，大约把 20% 的工具调用用于数据探索。错误分析显示，85% 的错误答案来自错误的计划或错误的实现，智能体很少选错数据源。每个智能体都用正则表达式从自由文本里抽结构化值，没有一个尝试基于自然语言处理或大模型的文本抽取。作者据此指出改进机会：智能体框架可以在 SQL 和 Python 之外提供更丰富的抽取原语，语义层可以减轻智能体的规划负担。

贡献有四条。第一，根据生产平台上观察到的模式，刻画真实数据智能体负载，指出四个使它们比文本到 SQL 或表格问答更复杂的性质。第二，给出 DAB：54 条查询、12 个数据集、4 种数据库系统。第三，评测五个大模型驱动的智能体，最好的模型只有 38% 的 pass@1，并在轨迹上建立失败分类，总结费用效率、数据探索策略和抽取工具设计上的可操作结论。第四，用专有生产数据智能体 PromptQL 做案例。同一模型下，它的 pass@1 比 ReAct 基线高 7 个百分点，但两种方法在需要从非结构化文本抽取的查询上都完全失败。

2 基准构建

第 2.1 节是形成性研究，第 2.2 节是构建过程，第 2.3 节是统计和一个例子。

2.1 形成性研究

形成性研究与 Hasura 合作。Hasura 做 PromptQL 数据智能体平台。它更早的产品 Hasura GraphQL Engine 下载量超过十亿，被一半以上的财富 100 强用来提供实时数据 API。PromptQL 把这套数据访问基础设施延伸到用自然语言查询、分析和操作企业数据的智能体。它连接 PostgreSQL、Snowflake、BigQuery、MongoDB、MySQL 和 SaaS 工具，部署达到数万用户和 PB 级数据量。

基准设计建立在对生产查询模式的定性研究上。Hasura 的共同作者对六个行业的企业客户做了半结构化访谈，收集用户向数据智能体提出的查询样例，以及底层模式、数据库系统、数据如何分布。伯克利和 Hasura 的共同作者然后做主题分析。他们独立审阅查询和模式并编码，再通过讨论把编码迭代归成更高层类别，直到共识。浮现出四个主题。

C1，多数据库整合。查询需要组合来自多个数据库或系统的信息。按跨源连接的方式分成四个子主题。（a）精确匹配连接，标识一一对应。（b）程序变换连接，标识指同一实体但格式不同，可以用确定性规则调和，例如把一个系统里的数字 ID 映射成另一个系统里带前缀的字符串。（c）模糊连接，要用近似字符串匹配或上下文推理做实体解析，例如调和 CRM 和内部库里的公司简称与全称。（d）API 整合，相关数据不在数据库里，而在外部 API，例如邮件客户端、网页搜索、第三方数据提供商，必须和数据库一起查。观察到最常见的后端是 Snowflake、PostgreSQL、MySQL、MongoDB、SQL Server 和 DuckDB，以及外部 API。

C2，文本上的语义操作。查询常常要用语义算子处理文本字段，也就是对表的每一行做由大模型驱动的变换。子主题包括分类、抽取、聚类、生成与摘要，以及按含义而不是精确关键词在大语料上搜索。

C3，领域知识。查询需要不能只从模式或内容推出来的领域专门知识。客户还有自己公司对业务概念的定义。例如「高活跃用户」可能指功能使用量在第 80 百分位以上、管理多个项目并且经常登录的用户。他们期望智能体正确应用这些定义。

C4，开放式分析推理。查询常常是探索性的，智能体要自己制定分析方法，而不是遵循一份定义良好的规格。例如「我该怎么改进支持流程」。这类问题没有唯一正确答案。

因为形成性研究的客户数据是专有的，DAB 用开源数据集构建，查询去镜像形成性研究里观察到的模式。每条查询必须有确定性的地面真值，以便可复现评测。因此丢掉 C4（开放式推理）和 C1d（API 整合，因为活的 API 每次调用结果不同）。

从剩下的主题导出四个基准性质，每个对应故意诱导进查询的一个挑战。（i）多数据库整合，来自 C1。（ii）格式不整齐的连接键，来自 C1b 到 C1c。（iii）非结构化文本变换，来自 C2。（iv）领域知识，来自 C3。DAB 里每条查询都涉及（i），并且至少涉及（ii）或（iii）之一。（iv）出现的比例对应它在形成性研究里的普遍程度。

2.2 构建方法

数据集创建有四步，图 2 以 bookreview 为例。（1）收集开源数据集。（2）变换数据，以诱导性质（ii）和（iii）。（3）把表分布到多个数据库系统，以诱导性质（i）。（4）为每个数据集提供自然语言描述和提示文件。

12 个开源数据集覆盖新闻（agnews）、电商（bookreview）、客户关系与销售（crmarenapro）、软件工程（deps_dev_v1、github_repos）、本地商家与评论（googlelocal、yelp）、音乐（music_brainz_20k）、金融市场（stockindex、stockmarket）、医学研究（pancancer_atlas）、专利（patents）。crmarenapro 及其查询来自 CRMArena。其余数据集来自公共仓库，其余查询由作者拟定。

为诱导（ii）和（iii），作者删掉能直接回答查询的列，把内容重新嵌进其他列，使恢复不再平凡。对连接键，把跨表匹配的标识换成格式不同的版本，例如 123 在一张表变成 bid_123，在另一张变成 bref_123。对文本变换，去掉类别或标签列，用 GPT-4o 找一个自然插入点，把值嵌进评论或描述等自由文本，并要求尽量少改原文。例如在 yelp 里，餐馆位置被注入评论文本，智能体必须从散文里抽取，而不是读专门的列。

文本变换分两类。与数据规模无关的变换，可以用固定大小的程序解决，不管有多少行。例如 github_repos 里，星数嵌在自由文本描述中，可以用类似「数字加 stars」的正则抽出。bookreview 里，语言出现在自然语言的 details 字段，可以用 LIKE 识别。一个模式对每一行都适用。与数据有关的变换要求智能体检查单独的行，因为没有一套固定规则够用。例如判断销售线索的意图，必须逐条看。这些变换类型直接来自形成性研究里的例子，但是必然是风格化的。企业数据不能发布，注入的损坏模式只是更乱的真实变体的近似。

然后，每个数据集的数据分布到至少两个不同的数据库管理系统，每个库至少一张表。非结构化和面向客户的数据，例如文档、用户资料、评论，放在 MongoDB。结构化数据，例如销售记录、股价、元数据，放在 DuckDB、PostgreSQL 或 SQLite。只用开源系统，使 DAB 不需要商业许可证就能跑。智能体因此必须同时调和模式差异和查询方言差异。MongoDB 的查询语言和 SQL 差很多。即便在 SQL 系统之间，方言也不同。例如 PostgreSQL 对大小写敏感的列名要求双引号，SQLite 和 DuckDB 不要求。

每个数据集还有两个文本文件，对所有查询相同。一个是自然语言描述，说明每个数据库的逻辑名、系统类型和模式。另一个是提示文件，说明数据集创建时做了哪些变换，例如重新格式化的标识需要模糊匹配，或者分类的候选类别。真实部署里用户很少提供这么细的指导。作者把提示文件放进来，是为了测试额外协助能不能让智能体更好，并把「缺少上下文」造成的失败和「推理或实现不够」造成的失败分开。领域知识既来自专门领域的选择，也来自写进提示里的领域定义。例如股票查询要金融知识，癌症图谱要医学和基因组知识，CRM 要销售运营知识。

2.3 查询与答案

每条查询包含自然语言问题、地面真值答案和校验脚本。每条查询至少包含四个性质中的两个。地面真值由两名作者合写 Python，在任何变换之前的原始数据上计算。因为智能体返回的是自由文本而不是结构化值，校验脚本检查地面真值是否出现在回答里。单值答案要求地面真值字符串是回答的子串。集合答案要求每个元素都出现。这个做法偏向召回：回答里多了无关内容，只要真值在，仍可能判对。

表 1 概括 12 个数据集。agnews 用 MongoDB 和 SQLite，3 张表、4 条查询、0 条需要领域知识。bookreview 用 PostgreSQL 和 SQLite，2 张表、3 条查询。crmarenapro 用 DuckDB、PostgreSQL、SQLite，27 张表、13 条查询，其中 10 条需要领域知识。deps_dev_v1 是 3 张表、2 条查询、2 条需要领域知识。github_repos 是 6 张表、4 条查询、4 条需要领域知识。googlelocal 是 2 张表、4 条查询。music_brainz_20k 是 2 张表、3 条查询。pancancer_atlas 是 3 张表、3 条查询，全部需要领域知识。patents 是 2 张表、3 条查询，全部需要领域知识。stockindex 是 2 张表、3 条查询，全部需要领域知识。stockmarket 有 2754 张表、5 条查询，全部需要领域知识。yelp 用 DuckDB 和 MongoDB，5 张表、7 条查询。

3 实验

作者用五个前沿大模型智能体在 DAB 上评测，每条查询每个智能体 50 次试验。总体表现低。最好的智能体只有 38% 的 pass@1，pass@50 不超过 69%。patents 这个数据集在所有试验里没有任何智能体正确回答过任何查询。全部轨迹公开。

3.1 设置

每个智能体使用一个前沿模型，配备数据库查询和 Python 执行工具，按 ReAct 循环运行。提示包含工具用法、查询，以及数据集级的描述和提示。50 次乘以查询和智能体，一共 13500 次试验，费用大约 3150 美元。

五个模型都支持通过 API 做工具调用。闭源的是经 Microsoft Azure Foundry 的 GPT-5.2 和 GPT-5-mini，以及经 Google Gemini API 的 Gemini-3-Pro 和 Gemini-2.5-Flash。开源的是经 Together.AI 的 Kimi-K2。温度和推理强度等可配置参数用提供商默认值。选这些模型是为了覆盖常用提供商，并同时包含更高能力和更低成本的模型。Kimi-K2 被选中，是因为它在 2025 年 12 月 20 日的 Terminal-Bench 2.0 榜上，开源模型里排第一。选择还受 API 额度约束。作者写明，当时没有拿到 Anthropic Claude 模型的额度。

四个工具是 list_db、query_db、execute_python 和 return_answer。它们分别用来枚举表、对指定数据库跑只读查询、执行任意 Python、返回最终答案并结束。每次工具执行返回是否成功，以及结果或错误信息。五个模型的 API 都支持在一次迭代里发出多个工具调用。

3.2 结果

pass@1 的平均是：Gemini-3-Pro 0.38，GPT-5-mini 0.30，GPT-5.2 0.25，Kimi-K2 0.23，Gemini-2.5-Flash 0.09。GPT-5-mini 比更大、更贵的 GPT-5.2 更高，说明模型规模本身不决定智能体表现。

按数据集的 pass@1，Gemini-3-Pro 在 bookreview 上 0.89，在 crmarenapro 上 0.63，在 googlelocal 上 0.55，在 pancancer_atlas 上 0.56，在 github_repos 上 0.36，在 stockindex 上 0.38，在 stockmarket 上 0.40，在 agnews 上 0.20，在 yelp 上 0.19，在 music_brainz_20k 上 0.32，在 deps_dev_v1 上 0.02，在 patents 上 0。patents 上五个模型全是 0。deps_dev_v1 几乎同样难，最高 pass@1 只有 0.06，来自 GPT-5-mini。

排名在所有 k 上保持一致。Gemini-3-Pro 一直领先，然后是 GPT-5-mini、Kimi-K2、GPT-5.2、Gemini-2.5-Flash。k 等于 50 时，最好的也只有 69% 的 pass@50，其次是 GPT-5-mini 59%、Kimi-K2 56%、GPT-5.2 51%、Gemini-2.5-Flash 40%。pass@1 和 pass@50 之间的大缺口反映试验之间方差高。但即便 pass@50 仍然低，说明只增加尝试次数，不足以解开很多查询。

费用上，每个智能体 2700 次试验的总费用是：GPT-5-mini 67 美元，Gemini-2.5-Flash 140 美元，GPT-5.2 283 美元，Kimi-K2 1304 美元，Gemini-3-Pro 1355 美元。GPT-5-mini 的性价比最好：30% 的 pass@1，费用大约是 Gemini-3-Pro 的二十分之一，而后者是 38%。Kimi-K2 几乎和 Gemini-3-Pro 一样贵，准确率却低 15 个百分点。stockmarket 因为有 2754 张表，迫使智能体先发很多探索查询，在所有智能体上费用都最高。Gemini-3-Pro 在这个数据集上花了 500.79 美元。

轨迹上有四条结论。把聚合推进 SQL 更省。所有智能体的数据库查询都多于 Python 执行，但比例差很大。GPT-5-mini 的数据库对 Python 比例平均是 2.6 比 1，用 MAX、GROUP BY 这类聚合，大多数查询在 3 到 5 次工具调用内完成。Kimi-K2 平均是 1.1 比 1，把大结果集拉出来在 Python 里处理。在 stockmarket 的一条查询里，Kimi-K2 一次一个地查 25 只以上的股票，而不是用一条 UNION ALL。这在很大程度上解释了费用差：GPT-5-mini 总共 67 美元、30% pass@1，Kimi-K2 总共 1304 美元、23%。

更多迭代帮不了难查询。Kimi-K2 和 Gemini-3-Pro 最耗资源，平均每条轨迹 23 次和 12 次迭代，平均延迟超过 3 分钟和 2 分钟。最难的查询几乎都来自 stockmarket。轨迹可以到 50 次以上工具调用、超过 10 分钟，pass@1 仍接近零。按轨迹堆计算不够，迭代质量比数量重要。

并行工具调用用得少，但可能改善延迟和费用。GPT-5.2 并行最频繁，12.7% 的回合发出多个工具调用，最多 25 个并发。Gemini-3-Pro 是 6.1%。其余模型在不到 1.5% 的回合里并行。能力是有的：GPT-5-mini 平均每回合 1.27 次调用，标准差 3.72，单回合最多 234 次并发，说明它几乎总是顺序行动，偶尔爆发成大规模并行。多数据库负载天然适合并行，因为每个源可以独立查询。

探索太少或太多都更差。分析把工具调用分成探索性的（list_db、SELECT * LIMIT 5、查 information_schema）和分析性的。在每条查询的第 0 次运行、共 54 条轨迹上，探索调用占工具调用的比例是：Kimi-K2 24.3%，Gemini-3-Pro 22.7%，GPT-5-mini 19.9%，GPT-5.2 17.2%，Gemini-2.5-Flash 10.1%。准确率最高的两个智能体都把大约 20% 的调用用在探索上。

3.3 错误分析

失败模式有五类。FM1 是其他，包括不调用工具就回答。FM2 是计划错误，例如漏掉必须的操作，或加上无关操作，如不该有的 LIMIT 100。FM3 是选错数据，计划对，但选错表或列。例如语言信息在 details 列，智能体却去查 description。FM4 是实现错误，计划和数据源都对，但实现错。例如从 details 里抽出版年份时，正则可能匹配到 ISBN 里的四位数字，并返回最小的那个。FM5 是运行时错误，包括 API 失败、超过 600 秒、达到 100 次 API 调用、超出输入词元限制，或超过 1 小时总时限。GPT-5-mini 出现过工具调用数组超过 128 的 BadRequestError。Kimi-K2 出现过输入校验错误（400）和服务不可用（503）。

在完成了但答案错误的 1147 条轨迹里，FM4 占 45%，FM2 占 40%，FM3 占 15%，FM1 的其他类是 0%。FM2 和 FM4 合计 85%。智能体通常能找到对的表和列，难的是决定算什么，以及算对。Gemini-2.5-Flash 的失败主要是空响应：FM1 里不调用工具的比例达到 63.4%。FM5 对大多数智能体可忽略，Kimi-K2 有 6.6% 的试验因运行时错误失败，主要是 API 失败。所有智能体从自由文本抽值时都用正则，没有一个用自然语言处理或再叫一次大模型来抽取。

3.4 PromptQL 案例

Hasura 团队用 Claude-Opus-4.6，让 PromptQL 和作者的 ReAct 基线都跑，每条查询 5 次试验。PromptQL 的分层平均 pass@1 是 51%，ReAct 基线是 44%，高 7 个百分点。12 个数据集里，PromptQL 在 7 个上更高，ReAct 在 3 个上更高，2 个打平。瓶颈是找对表和列的数据集提升最大：yelp 高 40 个百分点（0.80 对 0.40），agnews 高 35 个百分点（0.65 对 0.30），stockindex 高 34 个百分点（0.67 对 0.33），stockmarket 高 20 个百分点（0.60 对 0.40）。两个智能体在 patents 的所有查询上都失败。这条需要从非结构化文本列做批量抽取。PromptQL 在难的是找数据时有帮助，还没有解决 DAB 里的全部挑战。同一模型下的这 7 个百分点，不能和前面五个模型、50 次试验的 38% 直接相减，因为模型和试验次数都不同。

4 相关工作

尽管数据库是最普遍的专业工具之一，前沿模型评测里没有数据库使用基准。作者把 DAB 放在五类相关工作旁边，并用一张表标出这四项性质谁覆盖了。

文本到 SQL。Spider、WikiSQL、BIRD 用公开数据库，表和模式相对干净。后来的工作扩展到多轮对话。Spider 2.0 覆盖 BigQuery、Snowflake 等云数据库方言。即便这些被称作企业规模的基准，也不反映真实企业数据的脏。BEAVER 在私有数据仓库上显示，当前大模型准确率很差。更根本的是，这些基准评的是查询生成，不是端到端的数据智能体工作流。BIRD 用 evidence 提示编码一部分业务逻辑，因此部分涉及领域知识。它们都不要求跨库整合、调和格式不整齐的连接键，或变换非结构化文本。近期工作还质疑基准可靠性：BIRD Mini-Dev 的标注错误率达到 52.8%，Spider 2.0-Snow 达到 62.8%。对十个智能体基准的系统审计发现，其中七个可能把表现相对误估到 100%。DAB 故意比这些基准小。每条查询都要在真实数据库系统上端到端执行，优先标注质量而不是数量。

表格问答把表直接放进提示词，让模型对单元格推理。生产表很少放得进上下文。

5 结论

DAB 是第一个在真实的多数据库查询上评测数据智能体的基准。它建立在企业负载的形成性研究上，包含 54 条查询、12 个数据集、9 个领域和 4 种数据库系统。它要求现有基准一直缺少的能力：多数据库整合、格式不整齐的连接键、非结构化文本变换和领域知识。最好的前沿模型也只有 38% 的 pass@1。错误分析表明，主要困难是制定正确的计划并正确实现它。作者希望这个基准帮助社区做出可以在生产中信任的数据智能体。