别让 agent 看见你的表：从 2.2% 到 94.15%，中间站着一层手写的 YAML
先说这篇文章要讲的事：让 agent 查企业数据库，正确的做法可能是不给它看数据库。
这不是修辞。论文 arXiv 2606.31041 描述的系统里有一条硬约束：agent 被禁止查询 INFORMATION_SCHEMA，看不到物理表结构；它甚至不许在最终执行的 SQL 里写出语义模型的名字，只能用那些从编译器输出里“抬”出来的真实表名和列表达式。就这么把手绑住之后，它在 Spider2-snow 上拿到 94.15%，官方榜单第三。同一批任务上，把 schema 塞进 prompt 直接生成 SQL 的经典方案，最好的 31.26%，最差的 2.20%。
如果你在做数据 agent、指标平台或者对话式 BI，这篇的结论会直接改你的投入分配：准确率的天花板不在模型那边，在你那层语义定义有没有养好。 而更值得提前知道的是它的代价——论文第八章专门讨论了这层语义层会怎么烂掉。
一、从 2.2% 到 94.15%
Spider2-snow 不是学术玩具。它是 547 道跑在真实企业数仓上的任务，全部托管在 Snowflake，数据库常常超过一千列，有的超过三千列，标准答案动辄上百行、带着 CTE、窗口函数和多步聚合。官方给过一组对照说明这个落差：GPT-4o 在老版 Spider 1.0 上能做到 86.6%，到了 Spider 2.0 只有 10.1%，o1-preview 也只有 17.1%。“把 schema 放进 prompt 然后要 SQL”这套做法，在真实数仓上基本不成立。
榜单印证了这一点。下面是 Spider2-snow 官方榜单上几个有代表性的条目：
| 方法 | 准确率 |
|---|---|
| DIN-SQL + GPT-4o | 0.00% |
| CHESS + GPT-4o | 1.28% |
| Dail-SQL + GPT-4o | 2.20% |
| Spider-Agent + o1-preview | 23.58% |
| Spider-Agent + Claude-4-Sonnet | 25.78% |
| ReFoRCE + o1-preview | 31.26% |
| QUVI-3 + Gemini 3 Pro（本文主角） | 94.15% |
515 题对 547 题。作者是忠北大学的一个三人小组，系统叫 QUVI-3，用的模型是 Gemini 3 Pro 预览版，temperature 0.1，扩展思考开到 high，每题最多允许 20 轮 SMQ 迭代。
94.15% 在榜单上排第三。前面两位是 Genloop 的 Sentinel Agent v2 Pro（96.70%）和 usenative.ai 的 Native mini（96.53%），两家都是商业产品条目，没有论文，也没公开方法——这个榜单的头部，可核对性是往下走的。
同一批题目、同一套评分协议，一边 2.20%，一边 94.15%。这段距离里，有多少是模型挣来的？
论文作者自己把话说清楚了：语义层里编码了每个数据库的领域知识，而零样本基线拿不到这些知识，所以这个对比反映的是“语义层 + agent”这套系统的价值，不是 LLM 本身的价值。这种主动划清功劳边界的写法，在跑分论文里不常见。
顺着这个态度还得补一句：那张表只能当观察看，不能当归因用。七行里模型也在变，GPT-4o 到 Gemini 3 Pro 跨了两年多，架构范式的差别和模型代际的差别叠在一起，拆不开。
榜单上有一组是拆得开的，而且论文自己没报——同一个 DAQUV 团队交了两份提交：
| 提交条目 | 准确率 |
|---|---|
| QUVI-3 + Gemini-3-pro-preview | 94.15%（第 3） |
| QUVI-3 + Claude-Opus-4.6 | 86.28%（第 7） |
锁定这套架构、只换模型，差 7.87 个百分点。 记住这个数：第三节会出现一个比它大五倍的对照，而那个对照不在任何榜单上。
二、能力是靠减法拿到的
论文把企业 NL2SQL 的难点拆成两件事，这个拆法是全文的支点。
接地（grounding）：在几百张表、天书一样的列名里，找到哪些表和列相关、它们怎么 join。组装（composition）：在积木确定之后，拼出方言正确的 SQL。传统做法把两件事混在一次自由生成里，于是一个列名写错整个查询就废，而且模型没有任何结构化的表面可以退回去修。
QUVI-3 的做法是把接地整个搬走。每张物理表被包成一个语义模型，暴露出维度（分组和过滤的键）、度量（聚合的对象）和指标（预定义的聚合或派生计算）。每个元素带两样东西：一个给 LLM 读的自然语言描述，和一个 expr 字段装着精确的物理列表达式。抽象名字和物理表达式就此分离。表间的 join 在每个库的 join graph 里声明一次，连脏键上要不要 TRIM 都写进 on 条件。
agent 提问的方式叫 SMQ（Semantic Model Query），一个只有三个列表的紧凑 JSON——metrics（要什么）、filters（过滤什么）、group_by（按什么分组）。它故意不支持 CROSS JOIN、任意子查询、高级窗口函数和递归 CTE。
然后是四条硬约束，我认为这才是设计的实质：
- 禁止 schema introspection。 不许查
INFORMATION_SCHEMA，所有接地必须过语义层。 - 禁止把语义模型名当物理表用。 执行的 SQL 里出现的每一个表名和列表达式，都必须是从编译器输出里抬出来的。
- 每轮只许一个工具调用。 三个工具：列出模型的数据元素、编译 SMQ、执行 SQL。动作空间被压到最小，轨迹因此完全可审计。
- 执行是终止动作。 一次成功的
execute结束整个流程。
最反直觉的一条藏在提示词策略里：编译器产出的 SQL 不是答案。 SMQ 编译只用于探索——它的作用是让 agent 看见抽象元素到底映射到哪个物理列、这个方言的语法长什么样、join 是怎么接的。agent 把这些“已验证的积木”收集起来，然后自己组装最终查询，把 SMQ 表达不了的窗口函数、递归 CTE 加在上面。
这样一来，所有物理标识符都已经被一个确定性编译器验证过，agent 可能犯的错被关进了它自己加的那层结构里——而那层结构小、可读、出错了能通过重新探索修回来。这不是给模型更多能力，是给它更少的选择。
三、语义层的方差比模型的方差大
那个对照就在论文内部，而且它比榜单上任何一组都干净——同一个 agent、同一个模型、同一套循环，只按数据库来源分类：
| 实例来源 | 正确/总数 | 准确率 |
|---|---|---|
| SQLite 源 | 131 / 135 | 97.0% |
| GA4 源 | 24 / 25 | 96.0% |
| BigQuery 源 | 350 / 369 | 94.9% |
| 原生 Snowflake | 10 / 18 | 55.6% |
| 合计 | 515 / 547 | 94.15% |
从 97.0% 掉到 55.6%，四十多分。作者写得很直接：主导剩余失败的是各库语义层的成熟度和方言处理，不是 agent 循环本身。（原生 Snowflake 那类只有 18 题，方差大，这点要打折看。）
三类复发的失效模式也指向同一处：SMQ 编译缺口（引用的模型缺一条 join 关系，编译器组装不出片段）、组装错误（agent 自写的那部分在嵌套时间窗、精确舍入与排名语义上出错）、语义层欠定义（标准答案需要的列还没被暴露成一个描述过的元素）。第一类和第三类都靠改语义层解决，不靠改 agent。
论文因此把语义层称为系统的“主维护面”：因为接地被整个委托了出去，准确率就被每个库的语义模型描述得好不好、join 声明得全不全卡住了上限。作者说这件事在实践中是直接生效的——补上缺失的元素、把描述写准、把 join 边声明出来，那个库的准确率就跟着往上走。
还有一个配置细节值得单独说。论文提到 agent 的准确率对模型的思考配置很敏感，扩展思考正是让模型能组装出 Spider2-snow 要求的那种长多步 SQL 的原因，关掉它准确率会明显下降。这一点乍看和 dbt 今年重跑的语义层基准相反——那边推理档位几乎不影响结果，GPT-5.3 Codex 把推理关掉也能拿满分。但两者其实不矛盾，差别在于谁负责写最终的 SQL：dbt 的 MetricFlow 全权确定性生成，模型只挑指标和维度；而 QUVI-3 把最难的那部分留给了 agent 自己组装。你把多少 SQL 交给模型写，就得为它买多少思考预算。
四、可被优化的上下文，一定会被 Goodhart 化
论文第八章有一段讨论，我认为比 94.15% 这个数字重要得多。
既然语义层是准确率的主要杠杆，那么针对评测集去打磨它就成了理性行为。而这里有个 Goodhart 式的陷阱：那些给 LLM 读的自然语言描述，会从简洁、可复用的注解，慢慢漂移成冗长的文本，实际上把已知问题的预期答案编码进去了。这种上下文会推高基准分数，同时降低系统对未见问题和 schema 变更的鲁棒性。作者把它类比成奖励代理的过优化——这跟我在《模型为了作弊，打穿了两家公司》里写过的 verifier 缺陷是同一个结构：任何可被优化的代理指标，最终都会被优化到失真。
他们给出的应对是把语义层当代码来 review，两条判据相当可操作：
- 描述里只写可复用的 schema 知识，不写问题特定的提示。“Amazon 标准识别码”是知识，“用这个字段回答上季度按品类的营收问题”是答案泄漏。
- 结构信息住在 typed 字段里，不住在散文里。 join 关系、列表达式应该在
expr和 join graph 这些有类型的位置，而不是塞在描述文本中间。
论文把一个开放问题留在了这里，我觉得它是数据 agent 这个方向未来两年的核心工程问题之一：如何给“人工构造出来的上下文”定义一个内在质量信号，且这个信号独立于下游任务的准确率。 现在没有这样的度量。你没法在不跑基准的前提下判断一层语义定义是养好了还是养歪了，而一旦你只用基准分数来判断，你就已经在往歪的方向优化了。
五、落到工程上
先算投入分配。 如果换模型只值 7.87 分，而语义层成熟度能值四十分，那么“等下一代模型”不是最优策略。你的准确率被那层定义卡着上限，人力应该花在补维度、写清描述、声明 join 边上。这和《数据 Agent 答不对“上季度营收”，缺的不是模型，是上下文层》是同一个判断，现在它有了可核对的数字。
分清哪些查询有兜底。 SMQ 只覆盖常见分析核心——选择、过滤、分组和已声明的 join。CROSS JOIN、任意子查询、高级窗口函数、递归 CTE 都不在里面，只能由 agent 自己写在积木上面，而论文明确说这部分的正确性引擎并不保证。这条线就是风险边界：落在覆盖范围内的查询，物理名字和 join 条件都有确定性编译器兜底；超出去的，你依赖的是模型的自由组装。指标口径、审计口径这类不能出错的东西，值得先确认它能不能被语义层直接表达出来。
治理的性质变了。 指标口径、字段含义、join 关系，这些本来就是数据治理要管的东西，过去它们是合规成本，是没人愿意背的活儿。现在同一份资产直接决定 agent 能力的上限——它从成本项变成了能力输入。这是数据团队今年最好的一个论证材料。顺着《Agent 打破了 20 年数据治理：策略该放在库里，还是库外？》那篇的线索看，语义层其实给了第三个答案：既不在库里也不在库外，而在一层被当作代码来 review 的定义里。
收益是任务特定的，别外推。 同一个 DAQUV 团队在 Spider2-DBT 上只有 17.65%——那是个仓库级的代码 agent 任务，要求读懂项目代码再改。语义层中介解决的是“把业务问题翻译成一次查询”，不解决“理解并修改一个数据项目”。另外该说清楚的边界还有：这是单一基准的结果，用执行结果匹配来判分，边缘情况会给多或给少；最小的那类只有 18 题；而整套系统的成绩与每个库手写语义层的成熟度深度纠缠，这个成熟度本身参差不齐。
结论
- 企业 NL2SQL 的瓶颈从来不是模型会不会写 SQL，是它认不认识你的表。 同一批 547 道任务，schema-only 方案 2.20% 到 31.26%，语义层中介 94.15%。而作者自己声明：这反映的是系统的价值，不是 LLM 的价值。
- 能力靠减法：禁查 schema、只用编译器验证过的名字、每轮一个工具、编译产物只是积木不是答案。 把接地交给确定性编译器，agent 的犯错空间被关进它自己加的那层结构里。
- 换模型 7.87 分，换语义层成熟度 41.4 分。 前者在榜单上，后者不在任何榜单上，却是它的五倍多。你的钱应该花在后者。
- 覆盖范围内有兜底，范围外没有。 SMQ 只表达选择、过滤、分组和已声明的 join；窗口函数、递归 CTE 只能由 agent 自写，而论文明确说这部分的正确性引擎不保证。这条线就是风险边界。
- 代价是 Goodhart 化。 语义层是可优化的上下文资产，针对评测打磨它就会让描述从可复用知识漂移成答案泄漏。判据是把它当代码 review：知识写进描述，结构写进 typed 字段。
最后留个问题。语义层的维护成本随表数量线性增长，把写描述、补维度、声明 join 这些活儿交给模型，显然是下一步。
但论文刚刚论证了，这层资产最大的风险是描述从“可复用知识”漂移成“编码了预期答案”，而它同时承认：现在没有任何独立于基准分数的信号能测出这种漂移，只能靠人当代码去读。如果写描述的是 agent，判分的是基准，那谁来判断这层上下文是养好了还是养歪了？
参考资料
- Ha Jeong Kim、Saksonita Khoeurn、Ye Ji Yoon（忠北大学），《A Semantic-Layer-Mediated Agent for Natural Language to SQL over Heterogeneous Enterprise Databases》，arXiv:2606.31041，2026 年 6 月 30 日。https://arxiv.org/abs/2606.31041
- Spider 2.0 官方榜单（Spider2-Snow / Spider2-DBT / Spider2-Lite），XLang Lab。https://spider2-sql.github.io/
- Fangyu Lei 等，《Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows》，ICLR 2025，arXiv:2411.07763。https://arxiv.org/abs/2411.07763
- dbt Labs，《Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update》，dbt Developer Blog，2026 年（本文仅引用其推理档位一项结论作对照）。https://docs.getdbt.com/blog/semantic-layer-vs-text-to-sql-2026
- Minghang Deng 等，《ReFoRCE: A Text-to-SQL Agent with Self-Refinement, Consensus Enforcement, and Column Exploration》，arXiv:2502.00675。https://arxiv.org/abs/2502.00675
- ICE 数字实验室，《数据 Agent 答不对“上季度营收”，缺的不是模型，是上下文层》，2026 年 7 月 12 日。
- ICE 数字实验室，《Agent 打破了 20 年数据治理：策略该放在库里，还是库外？》，2026 年 7 月 3 日。
- ICE 数字实验室，《模型为了作弊，打穿了两家公司：Agent 安全的三处要害》，2026 年 7 月 27 日。
本文部分内容由 AI 辅助生成，经人工审校和补充后发布。