作者：林岚｜OC 开发者生态编辑

据 Communications of the ACM 文章，Michael Stonebraker 和 Peter Baile Chen 认为，现有 Text-to-SQL 基准并不能反映真实企业数据仓库的复杂性。他们构建的 Beaver Benchmark 基于真实数据仓库查询日志，结果显示纯 LLM 在该基准上准确率为 0%，加入 RAG、提示工程和 Agent 后也只提升到 10% 到 30% 区间。

一句话结论：Text-to-SQL 不是不会成功，而是“演示里能查数据库”和“公司里能放心查业务数”中间隔着一整座脏数据仓库。

这条新闻对开发者特别有意义，因为我们每天都能看到类似演示：用户问一句“上季度华东区销售额为什么下降”，AI 自动生成 SQL，图表立刻出来。看起来，BI 工具要被自然语言替代了。

但真实企业数据库不是教材。CACM 文章点出了几个很扎心的问题：真实数据仓库有 schema rot，字段名会随着组织变化变得混乱；同名字段可能语义不同；公司内部还有只有员工才懂的缩写、部门名、业务周期和历史包袱；真实查询也往往不只是一个 join。

这就解释了为什么公开榜单分数很好看，企业落地却经常卡住。Spider、Bird 这类基准能证明模型会写 SQL，但不一定证明模型理解你公司的数据。一个模型可能知道 revenue 是收入，却不知道你们表里的 rev_adj_q4_temp 到底是不是财务确认收入，也不知道某个部门在去年并购后换了编码规则。

林岚认为，这不是给 Text-to-SQL 判死刑，而是提醒大家别把它当成魔法。真正可用的方案，大概率不是“用户一句话，模型直接查生产库”，而是要有数据语义层、指标定义、权限控制、查询样例、审计日志、结果解释和人工确认。

更直接地说，公司要先把“人也容易查错”的数据问题解决一部分，AI 才能查得对。否则 LLM 只是把原来 BI 团队和数据工程师脑子里的隐性知识，错误地假装已经懂了。

关键事实

• 来源：Communications of the ACM
• 涉及基准：Spider、Bird-SQL、Spider 2.0、Beaver Benchmark
• 核心技术：Text-to-SQL、RAG、Agentic AI、数据仓库
• 关键数字：纯 LLM 在 Beaver 上准确率为 0%；加入 RAG/提示工程/Agent 后约 10%+；提供部分 gold SQL 结构后约 30%+

OC 判断

企业级 Text-to-SQL 的瓶颈不是 SQL 语法，而是业务语义。没有语义层和数据治理，AI 查库会把“看起来合理”的错答案包装得更像真的。

为什么重要

• 对开发者：不要让模型直接对生产库自由生成 SQL，至少要加权限、白名单和审计。
• 对企业：AI BI 项目的前置工作是指标治理，不是先买聊天机器人。
• 对用户：自然语言查数方便，但关键决策仍要看口径、来源和可复核 SQL。

参考来源

• Communications of the ACM: If You Think You Can Do Real-World Text-to-SQL
• Beaver Benchmark
• Spider 2.0