Spider 2.0-AIFunc：将真实世界Text-to-SQL扩展到AI原生SQL工作流

# Spider 2.0-AIFunc：将现实世界的 Text-to-SQL 扩展至 AI 原生 SQL 工作流  
来源：https://arxiv.org/html/2607.06229  

田阳刘¹，Canwen Xu²，方宇雷³，Nikki Lijing Kuang²，Jixuan Chen¹，  
陶宇³，Julian McAuley¹，Zhewei Yao²，Yuxiong He²  

¹加州大学圣地亚哥分校  
²Snowflake AI 研究  
³香港大学  

\{til040,jmcauley\}@ucsd.edu  
\{canwen.xu,zhewei.yao,yuxiong.he\}@snowflake.com  

###### 摘要  

主流云数据平台现已将大语言模型能力暴露为原生 SQL 函数，使分析师能够在普通 SQL 查询中执行分类、过滤、情感分析、提取、相似性搜索和聚合等操作。然而，现有的 Text-to-SQL 基准仅评估传统 SQL，无法衡量模型生成此类 AI 原生 SQL 的能力。我们推出了 Spider 2.0-AIFunc，这是一个包含 465 个经过验证的实例的基准，涵盖 Snowflake 平台上 125 个真实世界数据库中的六种 AI 函数类型。该基准基于现有企业级 Text-to-SQL 基准构建，通过一个基于 agent 的流水线将源任务重写为 AI 原生形式，同时转换目标查询并优化自然语言指令，以使预期的 AI 原生解决方案更加明确并减少歧义。所有实例均在时间上分离的多个窗口内经过多轮重复执行协议验证，确保结果稳定性后才发布。在对十个最新语言模型的评估中，我们发现最强的专有模型达到 67–70% 的执行准确率，而最佳开源模型仅为 58.1%，这一差距主要源于谓词规范、模式定位和 AI 函数参数化方面的错误。为传统 Text-to-SQL 挑战（如模式检索和相关表选择）设计的 agent 框架无法有效迁移到 AI 原生 SQL：一个最小的 agent 设置始终能与更复杂的替代方案持平甚至更优，这表明这些框架所采用的策略在此场景中不再那么关键。  

## 1 引言  

企业数据分析中的许多问题用自然语言提问很容易，但在传统 SQL 中却难以表达：哪些工单描述了计费问题？哪些调查回复提到了流失风险？哪些产品评价是负面的，客户在抱怨什么？以最后一个场景为例。一位数据分析师拥有一张存储在云数据仓库中的产品评价表，想要分析其情感倾向并将负面评价按投诉类型分类。直到不久以前，回答这类问题还需要从数据库中提取文本，在单独的环境中运行情感分析和分类模型，再将结果加载回去。如今，在 Snowflake 等平台上，可以直接使用 SQL 中的 AI 函数（如 `AI_SENTIMENT` 和 `AI_CLASSIFY`）来完成：  

```sql  
SELECT review_id,  
       AI_SENTIMENT(review_text) AS sentiment,  
       AI_CLASSIFY(review_text, ['shipping', 'quality', 'service', 'pricing']) AS complaint_type  
FROM product_reviews;  
```  

这类函数可以与标准 SQL 的聚合、过滤和连接操作结合使用，使分析师能够在普通 SQL 查询中对非结构化文本表达语义操作 (Snowflake, 2026 (https://arxiv.org/html/2607.06229#bib.bib28))。Snowflake 并非唯一朝此方向发展的平台。BigQuery (Google Cloud, 2026 (https://arxiv.org/html/2607.06229#bib.bib13))、Databricks (Databricks, 2026 (https://arxiv.org/html/2607.06229#bib.bib7)) 以及其他主流云平台都已引入 SQL 可调用的 AI 函数，使得从文本分类、情感分析到相似性搜索和信息提取等一系列语义操作都可以直接在 SQL 查询中表达。在企业环境中，分析师越来越多地将这些 AI 函数与传统的 SQL 操作符组合，构建出以前需要单独工具链才能实现的 AI 原生 SQL 工作流。  

Text-to-SQL 基准一直在逐步向更真实的评估环境演进 (Liu et al., 2025 (https://arxiv.org/html/2607.06229#bib.bib20))。WikiSQL (Zhong et al., 2017 (https://arxiv.org/html/2607.06229#bib.bib33)) 引入了基于简单单表查询的大规模评估。Spider 1.0 (Yu et al., 2019 (https://arxiv.org/html/2607.06229#bib.bib32)) 通过跨数据库泛化、连接和嵌套子查询提高了复杂度。BIRD (Li et al., 2023 (https://arxiv.org/html/2607.06229#bib.bib18)) 引入了真实世界的数据库值和外部知识。最近的 Spider 2.0 (Lei et al., 2025 (https://arxiv.org/html/2607.06229#bib.bib17)) 和 BEAVER (Chen et al., 2025 (https://arxiv.org/html/2607.06229#bib.bib6)) 更进一步，转向了企业级工作流，支持多种 SQL 方言，数据库列数往往超过 1000。这些基准共同推动着 Text-to-SQL 研究取得了显著进展。  

与此同时，所有这些基准都只针对完全由传统 SQL 操作符构成的、对结构化数据进行的查询。鉴于 AI 函数在企业 SQL 工作流中的日益普及，如上所述，一个自然的下一步是将 Text-to-SQL 评估扩展到 AI 原生 SQL，其中预期输出既包含传统 SQL 操作，也包含 AI 函数调用。图 1 (https://arxiv.org/html/2607.06229#S1.F1) 展示了这一转换的一个代表性示例。

（参见图注）  
图 1：将传统 SQL 任务转换为 Spider 2.0-AIFunc 中 AI 原生 SQL 实例的示例。原始指令和黄金 SQL 被重写以包含一个 Snowflake Cortex AI 函数 (`AI_SIMILARITY`)。高亮部分表示注入的 AI 需求及相应的 SQL 转换。

为此，Spider 2.0-AIFunc 扩展了 Spider2-Snow (Lei et al., 2025 (https://arxiv.org/html/2607.06229#bib.bib17))，将其源任务重写为 AI 原生 SQL 版本。我们从 513 个 Spider2-Snow 实例开始，每个实例包含其原始指令、一个或多个黄金 SQL 查询、它们的执行结果、数据库模式以及可选的外部知识。我们同时转换目标 SQL，以加入 Snowflake Cortex AI 函数，并相应修改指令以匹配。当一个源实例存在多个有效的黄金 SQL 时，我们会进一步细化指令以减少歧义，并使预期的 AI 原生 SQL 查询更加明确。我们设计了一个可复用的、基于 agent 的流水线来执行此构建：agent 直接与 Snowflake 环境交互，提出对 SQL 和指令的修改，在数据库上执行生成的查询，并迭代解决执行错误、超时和格式错误输出等问题，直到查询在可接受的时间范围内返回合理结果。Agent 还会检查 AI 函数参数是否明确指定（例如，`AI_CLASSIFY` 的完整类别标签集合），以及指令是否清晰表明了预期的 AI 函数使用方式。构建完成后，每个实例进入验证阶段，由另一个 agent 在多次运行中执行黄金 SQL，并修复产生不一致结果的实例。该基准分两轮构建：主轮和扩展轮，后者旨在增加对 AI 函数类型的覆盖范围。最终发布的基准包含 465 个经过验证的实例，涵盖 125 个数据库，涉及六种 Snowflake Cortex AI 函数。

我们使用 Spider-Agent 框架 (Lei et al., 2025 (https://arxiv.org/html/2607.06229#bib.bib17)) 在 Spider 2.0-AIFunc 上评估了一系列最新的语言模型。该框架为每个模型提供了最小的工具集，包括用于探索数据库模式和外部知识的 bash 工具、用于在 Snowflake 上执行查询的 SQL 执行工具，以及任务终止工具。模型还获得了相关 Snowflake Cortex AI 函数的参考文档。在我们评估的模型中，Claude Opus 4.6 达到了最高的执行准确率 70.3%，其次是 Claude Sonnet 4.6 的 69.0% 和 Gemini 3.1 Pro 的 67.1%。专有模型与开源模型之间存在持续的差距：最强的专有模型集中在 67–70% 区间，而最佳开源模型达到 58.1%，其余开源模型范围在 44.9% 到 57.0% 之间。专门为传统 Text-to-SQL 挑战设计的 agent 框架无法有效迁移到 AI 原生 SQL：在相同的主干模型和 AI 函数文档条件下，三个此类框架的表现与最小的 Spider-Agent 基线持平，但未能超越。

## 2 背景与预备知识  

### 2.1 Spider2-Snow  

Spider 2.0 (Lei et al., 2025 (https://arxiv.org/html/2607.06229#bib.bib17)) 是一个企业级 Text-to-SQL 基准，包含 632 个真实世界工作流问题，数据库来源于 Google Analytics 和 Salesforce 等工业应用，并托管在 BigQuery、Snowflake、SQLite、DuckDB 和 PostgreSQL 等多个数据库系统上。它提供了多个复杂度不同的评估设置。Spider 2.0-AIFunc 建立在 **Spider2-Snow** 之上，这是一个自包含的 Text-to-SQL 设置，其中所有 547 个示例完全托管在 Snowflake 上。在 Spider2-Snow 中，给定自然语言问题 \(Q\)、数据库模式 \(D\) 和辅助文档 \(E\)，Text-to-SQL 解析器 \(f(\cdot)\) 需要生成相应的 SQL 查询 \(S = f(Q, D, E \mid \theta)\)。性能通过检查预测的 SQL 在数据库上执行时是否产生与黄金 SQL 相同的结果来衡量。Spider 2.0 演进过程中一个值得注意的方面是，每个任务最初仅发布了一个黄金 SQL 查询；但随着更多团队提交结果并探索替代方案，维护者发现许多任务存在多个有效的 SQL 查询，它们产生不同的正确结果，从而导致评估套件的持续更新。

### 2.2 Snowflake Cortex AI 函数  

Snowflake Cortex AI 函数 (Snowflake, 2026 (https://arxiv.org/html/2607.06229#bib.bib28)) 是 Snowflake 平台提供的一系列内置 SQL 函数，它们在查询执行时调用大语言模型。用户可以像使用传统 SQL 函数一样在 SQL 语句中调用这些函数，但不同的是，它们执行的不是算术或字符串操作等确定性操作，而是分类、情感分析、信息提取和相似性计算等语义操作。一个典型的 AI 函数将一个或多个表列（通常包含文本）以及用户指定的参数作为输入，并将其输出作为查询结果的一部分返回。由于遵循标准 SQL 语法，AI 函数可以在单个查询中与 `WHERE`、`JOIN`、`GROUP BY` 和聚合函数等传统 SQL 操作符自由组合。在底层，每个 AI 函数调用由 Snowflake 环境中提供的某个语言模型提供服务。在任何给定时间点，每个函数的底层模型是固定的，并且推理时温度设为 0，这意味着相同输入原则上应产生相同输出。然而，实际上先前的工作表明，即使温度为零，LLM 的输出也可能存在轻微的不一致性 (He & Lab, 2025 (https://arxiv.org/html/2607.06229#bib.bib15); Atil et al., 2025 (https://arxiv.org/html/2607.06229#bib.bib4); Ouyang et al., 2025 (https://arxiv.org/html/2607.06229#bib.bib23))。这一特性与基准测试相关，因为通过执行准确率进行评估要求黄金 SQL 产生稳定的结果。我们将在第 3 节 (https://arxiv.org/html/2607.06229#S3) 中描述如何通过多轮执行验证来解决这一问题。

## 3 Spider 2.0-AIFunc 基准  

Spider 2.0-AIFunc 建立在 Spider2-Snow 之上，通过将源任务重写，在目标 SQL 中加入 Snowflake Cortex AI 函数。围绕 AI 原生 SQL 构建基准引入了两个传统 Text-to-SQL 基准中不会出现的挑战。第一个是 **指令层面的规范确定性**：AI 函数在传统 SQL 之外引入了额外的自由度，包括使用哪个函数以及如何指定其参数（例如，分类任务的类别标签集合）。指令必须足够精确以确定这些选择，否则正确答案的概念将变得模糊不清。第二个是 **执行层面的执行确定性**：如 §2.2 (https://arxiv.org/html/2607.06229#S2.SS2) 所述，AI 函数调用的语言模型即使在确定性设置下也可能输出略有差异的结果。因此，黄金 SQL 必须产生稳定结果，基于执行的评估才有意义。我们的构建过程（第 3.2 节 (https://arxiv.org/html/2607.06229#S3.SS2)）解决了规范确定性问题，而验证协议（第 3.3 节 (https://arxiv.org/html/2607.06229#S3.SS3)）解决了执行确定性问题。我们在第 3.1 节 (https://arxiv.org/html/2607.06229#S3.SS1) 中描述任务定义，第 3.4 节 (https://arxiv.org/html/2607.06229#S3.SS4) 中介绍数据集统计，第 3.5 节 (https://arxiv.org/html/2607.06229#S3.SS5) 中介绍评估设置。

### 3.1 任务定义  

每个 Spider 2.0-AIFunc 任务的输入包括：自然语言指令 \(Q\)、数据库模式 \(D\)、辅助文档 \(E\) 和 AI 函数参考文档 \(R\)。前三个部分与 Spider2-Snow 格式相同。额外的组件 \(R\) 提供相关 Snowflake Cortex AI 函数的定义、参数规范和使用指南，因为这些函数相对较新，不太可能充分存在于当前语言模型的训练数据中。给定这些输入，系统 \(f(\cdot)\)（可以是 Text-to-SQL 解析器、LLM 或 agent 框架）需要生成一个 SQL 查询 \(S = f(Q, D, E, R \mid \theta)\)，该查询包含一个或多个 AI 函数调用以及传统的 SQL 操作。在构建过程中，我们优化指令以减少歧义，并使预期的 AI 函数用法和参数更加明确，如第 3.2 节 (https://arxiv.org/html/2607.06229#S3.SS2) 所述。

### 3.2 任务构建  

我们的构建从 513 个 Spider2-Snow 源任务开始。对于每个任务，我们获取原始指令、一个或多个黄金 SQL 查询及其执行结果、数据库模式以及可选的外部知识作为输入。目标是通过在目标 SQL 中加入一个或多个 Snowflake Cortex AI 函数，生成该任务的 AI 原生 SQL 版本。我们的基准涵盖的六种 AI 函数类型是：`AI_CLASSIFY`（语义分类）、`AI_FILTER`（按语义相关性过滤行）、`AI_SENTIMENT`（情感分析）、`AI_SIMILARITY`（基于嵌入的相似性计算）、`AI_EXTRACT`（从文本中提取结构化信息）和 `AI_AGG`（使用自然语言指令跨行聚合内容）。这些代表了无法用传统 SQL 操作符表达的各种语义操作。注意，每个任务可能包含多个 AI 函数，我们的基准中大多数任务在单个查询中结合了两个函数。

构建过程由一个可复用的、基于 agent 的流水线执行，使用 Claude Opus 4.5 (Anthropic, 2025 (https://arxiv.org/html/2607.06229#bib.bib1))，每个任务最多 15 轮交互。Agent 直接与数据库交互，同时提出对 SQL 和指令的修改。对于 SQL，agent 注入或重写查询的某些部分，以加入 AI 函数调用。对于