💬 NLP

Spider 2.0-AIFunc: Extending Real-World Text-to-SQL to AI-Native SQL Workflows

本文介绍了 Spider 2.0-AIFunc，这是一个包含跨 125 个真实世界数据库的 465 个已验证实例的新基准，旨在评估大语言模型在 Snowflake 平台上生成 AI 原生 SQL 查询的能力，研究揭示了尽管顶尖的专有模型达到了 67-70% 的准确率，但目前针对传统文本转 SQL 任务优化的智能体框架并不能有效地迁移到这一新兴场景中。

原作者： Tianyang Liu, Canwen Xu, Fangyu Lei, Nikki Lijing Kuang, Jixuan Chen, Tao Yu, Julian McAuley, Zhewei Yao, Yuxiong He

发布于 2026-07-08

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Tianyang Liu, Canwen Xu, Fangyu Lei, Nikki Lijing Kuang, Jixuan Chen, Tao Yu, Julian McAuley, Zhewei Yao, Yuxiong He

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

想象一下，你拥有一个巨大的、高科技的图书馆（云数据库），人们在其中存储从客户评论到销售记录的一切信息。多年来，向这个图书馆提问需要使用一种非常严格、机械化的语言，叫做 SQL。这就像是在餐厅点餐时，只能通过一套由数字和符号组成的编码来进行交流。

最近，图书馆的所有者（如 Snowflake）增加了一个新功能：AI 函数（AI Functions）。你可以把它们想象成直接内置在订餐系统中的“智能助手”。现在，你不再只是询问“所有的红苹果”，而是可以要求系统“阅读这些苹果的评论，并告诉我人们是开心还是愤怒”，或者“寻找与这条评论相似的评论”。这使得数据库变成了一个 AI 原生（AI-Native） 系统，让你可以在单句指令中将标准的数据库命令与基于语言的智能思维结合起来。

问题所在：旧地图不再适用

研究人员注意到，虽然这些新的“智能助手”功能强大，但用于训练和测试计算机大脑（AI 模型）的测试方法已经过时了。旧的测试只检查计算机是否能说那种严格的机械化语言。它们并没有检查计算机是否能够使用这些新的“智能助手”。这就像是在测试一名司机时，只在一条笔直、空旷的路上进行测试，而忽视了现实世界中充满了交通、行人和施工区域。

解决方案：Spider 2.0-AIFunc

为了解决这个问题，团队创建了一个更严格的驾驶测试，名为 Spider 2.0-AIFunc。

转化过程： 他们将 513 个现有的“驾驶测试”（关于数据的提问）进行了重写。他们强制要求这些问题必须调用新的“智能助手”。
- 旧问题： “显示所有负面评论。”（需要人类先阅读评论）。
- 新问题： “显示所有 AI 助手判定为负面情绪的评论。”（由 AI 在数据库内部完成阅读）。
建设团队： 他们使用了一组 AI Agent（数字员工）来重写这些问题。这些 Agent 扮演着编辑和机械师的角色：
- 他们检查指令是否清晰（例如：“你所谓的‘负面’具体指什么？”）。
- 他们确保“智能助手”拥有执行任务所需的所有正确工具（参数）。
- 他们反复运行测试，以确保答案是稳定的，不会仅仅因为 AI 助手“状态不佳”就发生变化。
最终考试： 最终结果是一个包含 465 个经过验证的问题、涵盖 125 个不同数据库 的基准测试。它涵盖了六种类型的“智能助手”任务，例如按情感对评论进行排序、寻找相似文本或从一段文字中提取特定细节。

测试结果：谁通过了考试？

研究人员让 10 个不同的 AI 模型（即“驾驶员”）参加了这场新考试，以观察它们编写这些复杂的、由 AI 驱动的查询的能力如何。

顶尖驾驶员（闭源模型）： 大型闭源模型（如 Claude Opus 和 Gemini）表现最好。它们的正确率约为 67% 到 70%。它们擅长判断该使用哪种“智能助手”，以及如何向其提出正确的问题。
开源驾驶员： 最优秀的开源模型（如 Kimi K2.5）得分约为 58%。它们表现尚可，但也犯了不少错误。
差距所在： 开源模型表现挣扎的主要原因并不是它们无法编写基础代码，而是它们在“智能”部分遇到了困难：
- 误解规则： 选错了表或列。
- 指令不佳： 忘记告诉 AI 助手具体要寻找什么（例如，在分类任务中没有列出所有可能的类别）。
- 逻辑错误： 搞混了操作顺序（例如，在调用 AI 之前而不是之后进行数据过滤）。

令人惊讶的发现：少即是多

研究人员还测试了使用复杂的“Agent 框架”（即帮助 AI 规划步骤的精细工具包）是否会有所帮助。

发现： 令人惊讶的是，最复杂的工具包并没有带来多少帮助。事实上，一个极简的设置——仅包含一个查看数据库的工具和一个运行查询的工具——其表现与那些花哨的框架一样好，甚至更好。
隐喻： 这就像是给一位名厨一把小巧简单的菜刀，而不是一把巨大的、复杂的瑞士军刀。对于这种特定的烹饪方式（AI 原生 SQL），这位名厨并不需要额外的各种小工具；他只需要知道如何使用这把菜刀即可。那些为传统数据任务设计的复杂框架，反而成了累赘或未能提供额外价值。

总结

本论文介绍了一种新的、更真实的测试方法，用于检测 AI 模型是否能够使用现代的“AI 驱动型”数据库功能。研究发现，虽然顶尖的 AI 模型正在变得日益熟练，但顶尖模型与开源模型之间仍存在差距。成功的关键不在于使用更复杂的规划工具，而在于将 AI 函数的基础指令和参数设置得完全正确。

技术摘要：Spider 2.0-AIFunc

问题陈述

主要的云数据平台（如 Snowflake、BigQuery、Databricks）已开始将大语言模型（LLM）能力作为原生 SQL 函数进行暴露。这些“AI 原生”函数允许分析师直接在标准 SQL 查询中执行语义操作——例如分类、情感分析、相似性搜索和信息提取。然而，现有的 Text-to-SQL 基准测试（如 Spider 1.0、Spider 2.0、BIRD）仅评估针对结构化数据的常规 SQL。它们无法提供关于模型生成 AI 原生 SQL 能力的信号，而这不仅需要构建标准的查询，还需要正确地选择、参数化并集成 AI 函数调用。

方法论

作者引入了 Spider 2.0-AIFunc，这是一个旨在评估 AI 原生工作流背景下 Text-to-SQL 能力的基准测试。其构建和评估方法包含三个核心组件：

1. 通过智能体流水线构建基准

该基准测试源自 Spider2-Snow 数据集（Spider 2.0 的企业级子集，托管于 Snowflake）中的 513 个实例。作者采用了一个可复用的、基于智能体的流水线（使用 Claude Opus 4.5）将这些传统的任务转化为 AI 原生版本：

转换： 智能体重写目标 SQL，以纳入 Snowflake Cortex AI 函数，并同时优化自然语言指令，使预期的 AI 用法更加明确。
消除歧义： 对于具有多个有效 Gold SQL 的任务，通过精炼指令来指定确切的 AI 函数及其参数（例如，分类任务需提供完整的类别标签集），以确保存在唯一的正确答案。
两轮过程：
- 主轮： 智能体自由选择 AI 函数，导致结果分布由 AI_CLASSIFY、AI_FILTER 和 AI_SIMILARITY 主导。
- 多样性轮： 指示智能体优先处理代表性不足的函数（AI_SENTIMENT、AI_EXTRACT、AI_AGG），以确保对六种受支持的 AI 函数类型的广泛覆盖。

2. 确定性验证

评估 AI 函数的一个关键挑战是 执行确定性，因为即使在零温度设置下，LLM 的输出也可能表现出微小的差异。为了解决这个问题：

多轮验证： 每个候选实例都要经过四轮执行（总计 $\ge$ 35 次执行）。验证智能体会通过调整 SQL、指令或评估配置来修复结果不一致的实例。
时间稳定性： 幸存的实例会经过最终的稳定性检查，包括在三个时间间隔内进行 30 次执行。在这些间隔中产生不一致结果的实例将被剔除。
最终数据集： 该过程产生了涵盖 125 个真实数据库 的 465 个经过验证的实例。

3. 评估协议

指标： 执行准确率 (EX)。与 Gold 结果是预先计算且静态的传统基准不同，Spider 2.0-AIFunc 要求将 Gold SQL ( $S_n$ ) 和预测 SQL ( $\hat{S}_n$ ) 在 同一个时间窗口内 执行，以确保它们是在相同的底层模型状态下进行评估。
比较逻辑： 使用列子集匹配进行比较（Gold 列必须出现在预测结果中；预测列可以包含额外的列）。
框架： 模型使用 Spider-Agent 框架进行评估，该框架配备了最小化的工具集（用于模式探索、SQL 执行和任务终止的 bash）。设置中包含了 Snowflake Cortex AI 函数的参考文档。

核心贡献

Spider 2.0-AIFunc 基准测试： 首个专门针对 AI 原生 Text-to-SQL 的基准测试，涵盖 465 个经过验证的实例、125 个数据库以及六种类型的 AI 函数（分类、过滤、情感分析、相似性、提取、聚合）。
基于智能体的构建流水线： 一种新型的自动化流水线，能够将现有的企业级 Text-to-SQL 任务转换为 AI 原生版本，同时优化指令并验证执行的确定性。
AI 原生 SQL 的实证分析： 对 10 个最先进的模型（5 个闭源，5 个开源）和 3 个智能体框架进行了全面评估，揭示了特定的失败模式以及传统 Text-to-SQL 策略在此新环境下的局限性。

结果

对 10 个模型在 Spider 2.0-AIFunc 上的评估得出以下发现：

闭源与开源模型的差距： 闭源模型明显优于开源模型。
- 顶尖闭源模型： Claude Opus 4.6 (70.3%)、Claude Sonnet 4.6 (69.0%) 和 Gemini 3.1 Pro (67.1%)。
- 顶尖开源模型： Kimi K2.5 (58.1%)。
- 该差距主要是由 谓词规范、模式落地 (Schema Grounding) 和 AI 函数参数化 方面的错误驱动的。
执行成功率： 大多数模型实现了较高的“执行成功率 (Exec.)”（90–99%），表明它们能够生成可以在没有错误的情况下运行的语法正确的 AI 原生 SQL。性能差距在于语义正确性。
智能体框架的可迁移性： 为传统 Text-to-SQL 挑战（如模式检索、表选择）设计的智能体框架 无法有效地迁移 到 AI 原生 SQL。
- 当使用相同的骨干模型（Claude Sonnet 4.6）时，复杂的框架（AutoLink、ReFoRCE、DSR-SQL）的表现与最小化的 Spider-Agent 设置持平，但并未超越后者。
- 这表明，对于传统的 SQL 支架策略而言，其重要性不如对 AI 函数使用的精确语义决策（例如，正确的参数化、过滤顺序）那么关键。
交互行为： 开源模型需要显著更多的交互轮数（19–30 轮 vs. 闭源模型的 10–12 轮）以及更多的 SQL 执行尝试才能达到正确结果，且经常无法正确终止。

意义与主张

本文主张 Spider 2.0-AIFunc 代表了 Text-to-SQL 评估的一次必要演进，即从纯粹的结构化数据操作转向将语义操作直接集成到 SQL 中的 AI 原生工作流。

作者强调：

现有基准测试不足： 现有的基准测试未能捕捉到将 LLM 能力集成到企业数据流水线中的复杂性。
确定性至关重要： 验证协议强调，由于 LLM 输出固有的非确定性，即使在受控环境下，对 AI 函数进行基准测试也需要严格的稳定性检查。
策略转变： 复杂智能体框架无法超越最小化设置的表现，这一事实表明，AI 原生 SQL 的主要瓶颈不在于模式检索或任务分解，而在于 AI 函数的精确规范与参数化。随着模型的改进，为传统 SQL 组件构建复杂支架的价值相对于准确调用语义函数的需求而言正在降低。

这项工作为评估和改进能够构建“AI 原生”数据分析工作流的模型奠定了基础，而这种能力正日益成为企业级数据平台的要求。