在 632 个取自真实数仓的企业数据工作流上,代码智能体解出 21.3% —— 同一类任务的学术版本是 91.2%

数据工程师职业页 →

事件日期 / 报道日期

2024-11-12

证据阶段

限制或撤回失败、撤回、监管或成本正在抑制采用。可以下调评估,或扩大不确定区间。

关联任务

把管道搭起来

从一个源头抽出来、把形状改对、装进一个能查询的地方,并给整件事排上调度。

正在自动化✓ 有证据支撑

为「一个数字是什么意思」负责

定义什么算活跃用户、什么算收入、什么算流失 —— 并在两个团队希望它有不同含义时守住这个定义。

仍由人主导✓ 有证据支撑

适用范围

632 道题来自 BigQuery 与 Snowflake 上真实的数据应用,数据库常常超过 1,000 列。难在哪里由作者写明,而那正是这个岗位每天所在的环境:答案需要翻数据库元数据与方言文档、读项目自己的代码库、扛住极长的上下文,并写出好几段不同方言、动辄上百行的查询。21.3% 是 2024 年底某个智能体框架配 o1-preview 的成绩,会过时;经得住时间的是它与 Spider 1.0 的 91.2%、BIRD 的 73.0% 之间的差距 —— 那是对「难度有多少其实长在数仓里、而不是长在 SQL 里」的一次测量。它没有说任何关于用工的事,也没有说任何关于「建管道」而非「查数据」的事:它考的是产出那条查询,不是运维那套持续产出查询的系统。

这意味着什么

这份工作的难度是可以被测量的,而它的大部分不在 SQL 里。当同一类任务被放到一个真实数仓上 —— 上千列、好几种方言、要翻的文档、要读的代码库 —— 成功率从大约十分之九掉到大约十分之二。这个差距,是数据工程师一直在说、又很少被相信的那件事的一个数字:写查询是容易的那部分,知道哪张表才是真的那张,才是这份工作。

还不能说明什么

基准分数不是雇主的决定,而分数低也不等于安全。这个数字来自 2024 年底某一个智能体框架、某一代模型,应当默认它已经变了;变得没那么快的是「它当初为什么低」。它考的还只是「产出一条正确的查询」,那只是这个职业的其中一项任务 —— 这里没有任何一句话涉及建管道、上游 schema 改了之后会怎样、或者数字停止到达的那天谁会被叫起来。

你可以核实什么

挑一个你们公司据以决策的数字,一路追回它是从哪些表算出来的。数一数这一路上有多少个判断是被写在任何地方的。那个数目,而不是 SQL,才是一件工具必须复现的东西。

是否改变评估

否。影响指数不会被单条事件改变。这条记录做到的是:上面 2 项关联任务的判断从「推断」变成了「有证据支撑」。

来源

Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows (arXiv:2411.07763) · 核实于 2026-09-12 · Claude (VOLO agent) — arXiv abstract page read; the 632-problem count, the 1,000-column note and the 21.3% / 91.2% / 73.0% comparison taken from the authors' own abstract · 解读于 2026-09-12 · Claude (VOLO agent)

一手来源 —— 由做这件事的当事人或记录的权威机构发布,无需联署。

这条记录被引用在