Spider 2

定义

Spider 2是一个由问题集、配套数据库环境与自动评估脚本共同组成的评测框架，任务形式是给定自然语言问题、数据库接口以及项目代码库，要求被测系统产出可执行的SQL或最终结果表，再以执行结果与标准答案的一致性判定对错^[3]。完整版本共含632道源自企业级用例的题目，数据库来自真实数据应用，通常包含1000个以上的字段，存放于BigQuery、Snowflake等本地或云端数据库系统中^[1]。由于答案以执行结果比对，评测强调查询能否跑通并返回正确结果，而非字符串层面的相似度^[5]。

背景

在文本到SQL方向，早期基准以Spider 1.0和BIRD为代表，题目建立在规模较小、结构清晰、方言统一的数据库上^[6]。这类设置下，模型的成绩长期走高，在Spider 1.0测试集上已达91.2%左右，容易被解读为该任务接近解决^[3]。研究者在比对工业场景后指出，学术基准与真实部署之间存在系统性偏差：企业数据分散在多种系统中，Schema规模庞大且含嵌套结构，查询需要跨方言使用高级函数，还常常依赖项目文档与代码仓库^[6]。Spider 2的构建目的，正是在数据规模、方言多样性与工作流复杂度三个维度上向生产环境靠拢^[2]。

内容

Spider 2的数据库取自云数据仓库与本地引擎，覆盖BigQuery、Snowflake、SQLite、DuckDB、PostgreSQL、ClickHouse等系统，选题时要求每个数据库字段数超过200或具备嵌套结构，SQL长度超过50个词元且出自真实教程或项目，而非人工合成^[5]。为降低数据泄漏风险，标注者对查询做了表层的改写与语义层面的改写，并验证改写后的语句能够执行、在规定时间内完成并返回非空结果^[5]。统计上，完整集共632题，按词元数分为简单160题、中等279题、困难193题；含BigQuery的214题、Snowflake的198题，涉及DBT项目级任务的有78题^[5]。每个数据库平均约743.5个字段，每题SQL平均148.3个词元、使用约7.1个方言专用函数，均显著高于此前数据集^[5]。

基准按任务形式分为三个子集。Spider 2.0整体是代码智能体任务，模型需要在容器环境中读写文件、查询数据库、调用shell命令，反复迭代直至得出答案；Spider 2.0-Snow与Spider 2.0-Lite则退化为自包含的文本到SQL任务，只给Schema、问题与辅助文档，各含547题，前者全部位于Snowflake平台且对参赛者免费，后者混用BigQuery、Snowflake与SQLite^[7]。研究者同时提供了基线框架Spider-Agent，它基于ReAct式的推理-行动循环，封装了执行shell命令、创建与编辑文件、执行SQL、读取表结构与采样数据等动作^[2]。2025年5月，项目方又增设Spider2-DBT这一仅含68题的任务设置，聚焦仓库级的数据建模工作，并移除了最初的Spider2设置^[8]。

影响与争议

论文报告的结果显示，基于o1-preview的代码智能体框架在完整集上仅解决21.3%的任务，而在Spider 1.0上为91.2%、在BIRD上为73.0%；传统文本到SQL方法在Lite子集上的执行准确率只有个位数^[3][6]。在Snow与Lite两个子集上，o1-preview的总准确率分别为23.77%和23.22%，且随难度上升明显下滑，开源模型的成绩更低^[5]。错误分析把失分主因归于Schema链接错误、复杂查询规划以及缺少显式外键时的JOIN推理，而提供函数文档或少量示例只带来有限提升，说明难点在于把复杂需求准确落到SQL，而不在于语法知识^[5]。

该基准的公开榜单持续更新，参与方来自多国研究机构与企业，条目涵盖多智能体编排、知识图谱增强等不同技术路线^[9]。相关评测结果也被用于讨论模型在企业数据环境中的表现落差，即在学术基准上接近饱和的系统，换到字段规模与方言复杂度更高的场景后准确率大幅下降^[4]。研究者亦指出，该基准的标注成本高、扩展性受限，且现有模型尚难以应对其复杂度^[2]。围绕它的衍生工作也已出现，例如面向AI原生SQL函数的Spider 2.0-AIFunc，在125个真实数据库上构造了465个实例，用以考察模型生成内嵌AI函数的查询的能力^[10]。