# 在用真实企业数仓查询日志构建的 text-to-SQL 基准 Beaver 上,纯 LLM 得分为零、智能体方案约 10%,而公开基准上的成绩是 80% 至 90% 以上

网页: https://flyvolo.ai/zh/changes/ev-20260720-data-analyst-2
日期: 2026-07-20 · 阶段: 限制或撤回
这条记录能改变任务判断吗? 能
职业: https://flyvolo.ai/zh/careers/data-analyst

## 适用范围

作者就是这个基准的作者,而且他们还有一个竞争性系统(Rubicon)要推 —— 所以这里的利益相关方,立场正是「那些容易的基准是错的」。但底层说法是可核查的:Beaver 用的是 MIT 那个 1400 多张表的 Oracle 数仓以及另外三个数仓的真实查询日志,榜单也是公开的。文中给出的四个原因是结构性的,而不是关于模型好坏 —— 公开基准的数据本来就在训练语料里、真实 schema 会腐化成六个都叫 salary 的字段、数仓里有本地黑话、真实查询往往要连两三张表而不是一张。

## 来源

- BLOG@CACM (Stonebraker & Chen, MIT) — https://cacm.acm.org/blogcacm/if-you-think-you-can-do-real-world-text-to-sql (一手来源)

## 这意味着什么

公开基准上 90%、真实数仓里 10%,这中间的差距不是「下一个版本会修好」的模型问题,而是真实企业数据本来的样子。你的岗位为什么熬过了前三代 text-to-SQL 产品,原因就写在这里:schema 腐化、本地黑话、六个字段都叫 salary 而只有你知道哪个是哪个。那份知识才是这份工作 —— 它比写 SQL 更是。

## 它还不能说明什么

一个基准、四个数仓,而且作者在卖替代方案。这里没有任何内容说明哪家公司因此留住了分析师、或停止采购这类工具 —— 按着 90% 那个数字买软件的公司多的是。这个结论也未必对每个数仓都成立:文中给出的原因是结构性的,所以 schema 干净、查询简单、本地黑话少的场景是另一回事。

## 怎么自己核实

别信任何一边的数字,在自己的数仓上做一遍这个测试。从上个季度的真实需求里挑十个问题,只给模型你的 schema、别的什么都不给,再拿生成的 SQL 和你当初真正交付的对一遍。数一数:在没人告诉它该用哪些表的情况下,它做对了几个。那个数字就是你的岗位安全度的实测值 —— 而如果它偏高,那也正好是一份「该补文档的清单」。


更多: https://flyvolo.ai/llms.txt