SQL 开始调用 AI，但 AI 写 SQL 尚未成熟
假设你要分析一批产品评论：哪些是负面评价？用户抱怨的是物流、质量、服务，还是价格？
以前，分析师往往先从数据库提取评论，在独立环境中进行情感分析和分类，随后将结果回填至数据库。
如今，仅需一条 SQL 语句即可搞定：
第一步用 AI 函数判定情绪，第二步将投诉归类至物流、质量、服务或价格等板块。这些功能还能与常规的筛选、连接、聚合等 SQL 操作无缝结合。
这种查询被称为 AI-native SQL，即“原生调用 AI 能力的 SQL”。Snowflake、BigQuery 和 Databricks 等云数据平台纷纷推出此类功能。
看似只是 SQL 新增了几个函数，实则变化远不止于此。
以往，数据库负责执行确定的运算；如今，模型的判断也融入了查询流程。
因此，一条 SQL 不再仅仅是“能跑通就行”。它至少需要通过三道关卡。
以下三关并非论文原文的小标题，而是依据任务设计、错误分析及稳定性验证整理而成的。
Spider 2.0-AIFunc 是一项专门针对 AI-native SQL 的测试研究。它包含 465 个任务，源自 125 个真实数据库，涵盖了文本分类、语义筛选、情感分析、信息抽取、相似度计算和语义聚合六种 AI 函数。
实验显示，表现最佳的 Claude Opus 4.6 生成的 SQL，有 99.4% 能够成功执行。但进一步检查结果正确性时，准确率仅为 70.3%。
这意味着，接近三成的查询虽然未报错且返回了结果，但答案却是错误的。
错误来源既有传统 SQL 的问题：如表选错、过滤条件缺失、连接或汇总粒度不当；也有 AI 函数导致的问题：如选错函数、分类标签错误、抽取格式不符。
仅仅看到一张正常返回的结果表，已不足以证明查询是正确的。
论文在测试 GPT-5.4 时发现了一个有趣的现象。
研究者虽已提供了分类标签、提示文本和判断条件，模型仍会主动修改措辞，试图优化参数。
在此测试中，只要模型改写了题目明确指定的标签或条件，便不再符合标准查询要求。
研究者随后增加了严格规定：标签、提示文本和条件必须原样使用，不得自行改写。在论文的 GPT-5.4 测试设置下，准确率由 52.9% 提升至 63.0%。
此处最值得关注的是论文对任务边界的界定：
根据论文的评估要求，模型可以判定评论属于哪一类，但不能自行改写既定的分类体系。
论文要求题目清晰定义 AI 函数及参数，包括完整的分类标签和准确的抽取格式；模型需依据指定参数生成查询，而非自行修改。
这也解释了为何传统 Text-to-SQL Agent 在论文中未显优势。
以前的 Agent 方法主要辅助模型找表、找字段、拆解查询。论文测试的三套复杂框架，均未超越工具更少的基础方案。
论文对失败案例的分析发现，AI-native SQL 的错误可能出现在更细微之处：哪些数据先交给 AI、筛选发生在调用 AI 之前还是之后、函数参数是否被改写。
旧方法检查的是“SQL 如何编写”，新问题还要检查“SQL 中的模型做了何种判断”。
普通 SQL 中，1 + 1 每次都等于 2。AI 函数则不然。即便参数不变、随机性设置为零，大模型的输出仍可能出现微小波动；平台也可能在后台更新模型。
这引出了一个过去鲜少遇到的问题：同一条 SQL，在不同时间窗口运行，可能得出不同的分类结果。
为了发布这套测试题，论文对每条标准 SQL 进行了多轮重复执行。前四轮至少运行 35 次，随后又在三个不同时间窗口各运行 10 次。任何一个时间窗口内结果不一致，该题目即被删除。
正式评估时，标准 SQL 和模型生成的 SQL 也必须在同一时间窗口执行，以避免将今天的模型结果与过去保存的答案直接比较。
这也是论文无法沿用普通 Text-to-SQL 评估方式的原因：预先保存一份标准结果，一段时间后再拿新结果与之比较，可能已失公平。
综合这三关来看，论文给出的处理方法十分明确：分别统计“能否运行”和“结果是否正确”，明确写出 AI 函数及参数，再通过重复执行和同一时间窗口比较来排除不稳定结果。
这些方法解决的是基准如何构建、如何评估的问题。论文未进一步验证企业应如何保存历史结果、管理函数版本或设计线上审计流程，因此本文也无法替其补全生产方案。
Spider 2.0-AIFunc 仍仅是一个测试集，仅覆盖 Snowflake 上的六类 AI 函数。70.3% 不能作为企业上线的准确率。但它已表明，AI-native SQL 不仅仅是给 SQL 增加几个函数，而是在数据查询中引入了一层会变化的判断。
当模型判断融入 SQL，评估查询时也必须多问两件事：参数是否被改动，多次执行的结果是否稳定。
如果你身边有人正在从事 AI 问数、文本分析或数据平台工作，不妨把这篇文章转给他。SQL 引入 AI 后，过去那套查询检查方法也需随之升级。