数据问答应用 2026：语义层、SQL 校验与可信执行

一、问题的提出：为什么「问数据」是最难落地的一类终端 AI 应用

过去两年，AI 应用落地的公开讨论大多围绕通用助手展开：写作、总结、客服话术、代码补全。但在企业内部，最普遍也最刚需的场景其实是另一个——让业务人员直接「问数据」。传统路径是：业务方提需求，数据分析师写 SQL 跑数，排队一到两天，回一张静态报表。问数应用（常被称为 ChatBI、数据问答或自然语言查询）承诺的正是把这个链路压缩到几秒钟：业务同学用自然语言提问，系统生成并执行 SQL，直接返回数字和图表。

这个赛道的玩家在 2025 到 2026 年间明显密集起来。开源一侧，Vanna（GitHub 23,813 星，MIT 协议，截至 2026-10-25 实测）以「agentic retrieval 生成 text-to-SQL」为卖点，DB-GPT、Dataherald（3,650 星）与飞致云 2025 年 4 月开源的 SQLBot（6,960 星，基于大模型与 RAG 的智能问数系统）各有侧重；商业一侧，各大 BI 套件和云数据仓库都在控制台里内嵌了「AI 问数」入口。也就是说，问数已经不是要不要做的问题，而是怎么做对的问题。

它之所以是一类特别难做的终端 AI 应用，根源在于答案的「真值性」。写作助手写得不流畅，用户改改就行；RAG 应用引用错一段文档，用户可以追溯到原文；但问数应用返回的是一个数字——库存到底剩多少、上周转化率到底是多少——数据库里存在唯一可执行的真值，错就是对。这决定了问数应用必须同时过三道关：口径关（「活跃用户」「销售额」的业务定义必须与公司内部定义一致）、权限关（业务同学只能看到自己有权的数据）、成本关（一条失控的全表扫描查询就可能拖垮生产库）。

公开基准的进展也印证了难度。学术基准 Spider 上，主流模型早已做到 86% 量级的执行准确率；但同一条技术路线放到企业级工作流基准 Spider 2.0 上，o1-preview 只解决 17.1% 的任务，GPT-4o 只有 10.1%（Spider 2.0 官网数据，访问于 2026-10-25）。六倍以上的落差说明：把 text-to-SQL 从「演示能跑」推到「生产可信」，中间隔着的是工程，而不是模型。这篇文章就把这段工程拆开来看。

二、形式化：五元组与四层正确性

先把问数应用抽象成一个五元组 (Q, S, G, E, V)。Q 是自然语言问题，包含当前提问、多轮上下文与澄清回答；S 是语义层，包括数据库 schema、表列的业务描述、指标口径定义与值域知识；G 是生成器，把 (Q, S) 翻译成一条候选 SQL；E 是执行引擎，负责在正确的库上以正确的预算执行；V 是呈现层，把结果集变成表格、图表和解释。很多团队把精力全压在 G 上，但从失败案例的分布看，S、E、V 才是拉开「能用」与「敢用」差距的地方。

正确性可以分解成四层。L1 是语法正确：生成的字符串能被目标方言解析器接受。L2 是执行成功：查询在超时与资源预算内跑完，不抛运行时错误。L3 是结果正确：结果集与真值在语义等价的判定下一致。BIRD 基准采用的执行准确率（EX）衡量的正是 L2 与 L3 的复合——两条文本不同的 SQL 只要结果集等价即算对，官方同时说明带并列结果与不带并列结果两种判法均可（BIRD 官网，访问于 2026-10-25）。L4 是口径正确：查询在业务定义上成立。比如「上周」是自然周一到周日还是滚动七天，「销售额」含不含退款与内部测试订单。L4 没有任何公开基准覆盖，却是企业落地时返工率最高的一层。

把四层写成一个概率表达：可信度 = Pr[ G(Q,S) 可解析 ∧ 可执行 ∧ 结果等价 ∧ 口径对齐 ]。这四项是相乘关系——任何一层只有八成的把握，四层叠完就只剩四成。工程上的全部要领，就是给每一层分别建独立的保障机制，而不是指望一个更大的模型把四层同时搞定。这个分解也是后文各节的组织框架：第三节管 S 与 L4，第四、五节管 G 与 E 的 L1 到 L3，第六节管 V，第七节讲如何评估这四层，第八节讲失败时的回路。

三、语义层：schema linking 与口径对齐决定上限

企业数据库的现实是 schema 巨大且命名混乱。Spider 2.0 的数据来自真实企业应用，单个库常超过一千列，横跨本地库与 BigQuery、Snowflake 等云端系统；BIRD 更是刻意保留了「脏值」——数据以原始格式存储，同一个状态字段里混着 paid、PAID、已支付 三种写法，解析器必须先归一再推理。让模型直接面对一千列的 DDL，既装不下上下文，也会把注意力稀释在无关列上。

工程上的第一条路是检索式 schema linking：把每张表、每一列的名称、注释、样例值和历史上被采纳过的查询做成索引，问题进来先召回最相关的几张表、几十列，再把裁剪后的 schema 喂给生成器。CHESS（arXiv:2405.16755）把这个思路系统化了：先用实体抽取与值检索定位相关表，再做列过滤，最后才生成 SQL。实践中还有两个低成本高收益的补充：一是把「列的样例值」直接放进提示，模型看到 status 列的取值是 ['PAID','OVERDUE']，过滤条件的准确率立刻上升；二是把历史上被分析师修正过的查询做成 few-shot 池，这类查询隐含了口径与方言的知识。

第二条路是语义层，也是 2025 年以来变化最大的一层。Cube（GitHub 21,072 星，定位即开源语义层）与 dbt 的 metrics 体系把「GMV」「次日留存」这类业务指标定义成带主键、时间粒度、过滤条件与去重规则的物化定义。问数应用接入语义层后，生成策略从「自由写 SQL」变成「把问题解析到指标 + 维度 + 筛选条件，再由语义层展开成 SQL」。这一步的价值在于把 L4 口径正确从「模型猜」变成「系统保证」：指标只定义一次，所有问数、看板、导出走同一个定义，口径漂移在结构上被消灭。SQLBot 这类国产问数系统把 RAG 与语义配置结合，本质上也是这条路。

第三条路是值域与外部知识。BIRD 论文专门论证了外部知识注入的必要性：同一句「贷款要求账户类型是 owner」，对应的谓词是 account.type = 'OWNER'，这个映射不在 schema 里，而在业务文档里。工程做法是把这类映射沉淀成「口径卡片」——一段结构化的业务知识，检索时与 schema 一起注入。语义层不是锦上添花：它决定了这个应用的能力上限，模型再强也生成不出语义层里没定义的口径。

举一个具体的例子。「GMV」这个词在公司里至少有三种合法解释：含退款还是不含退款、按下单时间还是按支付时间归日、是否剔除内部测试账号。没有语义层时，模型每次都要在这三个自由度上各自掷骰子，用户看到的数字时对时错，而且错得很隐蔽——两个数字都落在合理区间里，只有月底对账时才会暴露。接入语义层之后，提示里出现的不再是自由文本的口径描述，而是一个带主键、时间字段、过滤条件与去重规则的指标定义，生成的 SQL 从「模型对口径的自由复述」变成「对唯一定义的机械展开」。口径修正也随之从「改提示词再祈祷」升级为「改定义」，一次修正全量生效。这正是语义层把 L4 从概率问题变成工程问题的含义。

四、生成与校验：把 LLM 输出当成不可信的候选 SQL

生成环节的第一个工程决策是提示结构。DAIL-SQL（arXiv:2308.15363）系统比较过 schema 表示方式、问题表示方式与 few-shot 选择策略的组合，结论是结构良好的 schema 表示加相似问题检索的 few-shot 收益最大。DIN-SQL（arXiv:2304.11015）则验证了任务分解的价值：把「找表 → 找列 → 写条件 → 组装」拆成多步，配合自纠错，准确率显著超过单步直出。这两个结论在今天依然成立，只是每一步背后的模型换了代。

第二个决策是专用模型还是通用模型加检索。专用路线如 defog-ai 的 sqlcoder（4,046 星，Apache-2.0）与 Numbers Station 的 NSQL（253 星），在受限方言上延迟与成本占优；通用路线以 Vanna 为代表，用 RAG 管理训练数据与 DDL 文档，靠检索质量拉动生成质量。2026 年的工程共识大致是：核心路径用旗舰通用模型保下限，高频稳定场景用蒸馏的小模型降成本，检索资产（DDL 文档、口径卡片、修正后的查询对）两个路线共用，且资产比模型更值得长期投入。

无论哪条路线，生成结果都必须当作不可信的候选处理，过四道闸。第一道是语法闸：用 sqlglot（9,719 星，MIT，支持二十余种 SQL 方言的解析与转译）对输出做 AST 解析，解析失败直接进入修复回路。sqlglot 还能做方言归一，避免模型在 Databricks 方言里写出 ClickHouse 的语法。第二道是语义闸：AST 上校验引用的表、列在授权范围内真实存在，类型匹配，聚合与分组一致。第三道是安全闸：只读白名单——拒绝 DDL 与 DML、拒绝多语句、拒绝跨库访问，并对没有 LIMIT 的查询强制注入上限。这一道闸要写在代码里而不是提示里，提示可以被绕过，AST 改写不能。第四道是成本闸：先发 EXPLAIN 拿预估扫描量与行数，超过阈值（比如千万行级扫描）的查询拒绝执行或转人工确认。有团队会问能不能靠约束解码（grammar-constrained sampling）在生成时保证语法正确——可以，但它只覆盖 L1，L2 到 L4 的风险一点没少，四道闸一个都不能省。

五、执行层：查询下推、成本控制与结果集治理

生成对了 SQL，接下去的问题是在哪里执行。第一原则：绝不让分析型查询落在生产 OLTP 库上。订单库的主库是给交易用的，一条按月分组的聚合就足以拖慢下单。工程上有两条成熟路线：一是查询下推，把问数查询路由到专门的 OLAP 引擎——ClickHouse（50,588 星）、数据仓库或湖仓；二是本地执行，把相关表的数据抽取到会话级引擎里算，DuckDB（42,504 星，MIT，2026-10-23 仍在高频提交）是这个位置的事实标准：嵌入式、列式、单文件，一个分析会话起来就是一个进程。更进一步还有端侧路线——duckdb-wasm（2,148 星）让查询直接跑在浏览器里，数据不出域，对金融、医疗等强隐私场景有独特价值。两条路线的取舍点是数据驻留与时效性：下推保留数据的实时性与权限边界，抽取牺牲一点新鲜度换来执行隔离。

执行治理至少要做五件事。其一，超时与取消：每条查询带硬超时，用户点取消要能传导到引擎层的 KILL QUERY，而不是前端假死。其二，资源隔离：问数查询走独立资源组或只读副本，配并发上限，问数高峰不能影响报表链路。其三，结果集治理：聚合结果超过若干行就截断并明确告知「已截断，共 N 行」，明细查询强制分页——把一百万行明细吐给前端既是事故也是成本。其四，抽样预估：大范围统计先跑近似（比如对 1% 抽样估数量级），UI 显示「约」，用户需要精确值再全量跑。其五，多租户配额：按租户与用户维度限流限价，问数的单次成本差异极大，一条跨三年全表聚合的查询成本可能是一般查询的百倍。

预聚合是执行层的最后一件大杀器。问数流量高度偏斜：绝大多数问题落在「按天分组的几个核心指标」上，这类查询完全不需要每次现算。工程做法是按语义层的指标定义物化日粒度汇总表，生成器在成本闸判定扫描量超阈值时自动把查询改写到汇总表上，毫秒级返回；明细数据仍可下钻，只是要接受更大的扫描预算。这套「粗粒度命中汇总、细粒度回退明细」的结构，就是数据库领域说了几十年的聚合感知（aggregate awareness）在问数场景的复用，它把长尾查询的延迟从秒级压到亚秒级，也让多租户场景下的成本曲线变得可预测。

这套治理的隐含逻辑是：执行层的职责不是「让查询跑得快」，而是「让坏查询造成的伤害有上界」。下限是由执行层兜住的——生成层再完美，没有超时、配额与结果集上限的问数应用在第一周就会被一条失控查询教会什么叫敬畏。

六、呈现层：从表格到图，答案必须可解释

表格是问数的默认呈现，图表是增强而不是装饰。自动图表选择可以用列类型驱动的启发式先覆盖八成场景：时间维度加数值度量走折线，低基数类别维度走柱状，占比构成走堆叠或环形，两维交叉走热力。规则之外，2025 年以来的常见做法是让模型直接输出结构化的图表规格——Vega-Lite（5,527 星，BSD-3-Clause）的 grammar of graphics 正适合这个位置：图表被描述成一个 JSON 声明（数据字段、变换、标记类型、编码通道），LLM 做的不再是自由发挥，而是一次受 schema 约束的结构化输出，出错可校验、可回退到默认规则。

呈现层有三个容易被低估的工程细节。第一，不确定性必须显式传递：结果被截断了、来自抽样估计、来自十分钟前的缓存，这三种情况都要在 UI 上有明确标注，否则用户会把「约 3.2 万」当成精确值写进周报。第二，「查询即资产」：把命中的 SQL、涉及的口径定义、时间范围与过滤条件随结果一并展示，允许用户改一个条件重跑。这是问数应用与普通聊天应用在信任上的分水岭——用户敢把结果写进汇报材料，前提是他能点开看一眼 SQL 长什么样。第三，多轮交互的状态管理：追问「那上个月呢」时要能复用上一轮的指标与分组结构，只替换时间过滤，这要求把每轮的语义解析结果（指标、维度、筛选）作为结构化中间态保存，而不是只存对话文本。

七、评估：三层口径，缺一层就会上线翻车

评估问数应用，公开基准只能覆盖前半程。BIRD（arXiv:2305.03111）包含 12,751 个问题-SQL 对、95 个数据库共 33.4 GB、覆盖 37 个专业领域，其官网排行榜（访问于 2026-10-25）显示 dev 集执行准确率最高档为 92.96%（即人类基线档位），test 集头部提交在 82% 到 83% 一带；但更值得看的是它的姊妹基准 BIRD-CRITIC——面向真实 SQL 调试任务时，官网披露旗舰档模型 GPT-5 (Med) 的成功率仅 8.67%。Spider 2.0（arXiv:2411.07763，ICLR 2025 Oral）给出另一组对照：632 个企业级工作流任务，库常超过 1,000 列，o1-preview 解决 17.1%，GPT-4o 解决 10.1%，而同一批模型在 Spider 1.0 上是 86.6%。两组数字合起来的结论很清晰：基准分数每往企业现实靠近一步，模型能力就掉一个量级，评估必须跟着往真实环境挪。

自建评估集因此是必需品，不是奢侈品。工程做法是从真实工单、历史报表需求里抽取问题，构成「问题—参考 SQL—口径说明」三元组，规模两三百条起步，覆盖五类难点：多表连接、时间边界、脏值过滤、口径歧义、方言特性。判定用执行准确率：参考 SQL 与候选 SQL 各跑一遍，结果集做语义等价比较（列序无关、行序无关、浮点容差），并处理并列结果。这个评估集要进 CI：每次换模型、改提示、动语义层定义，跑一遍回归，掉点即拦截。

L4 口径评估没有公开方案，只能自建双轨：一轨请业务分析师对每条候选 SQL 做人工评审，标注「口径对但写法丑 / 口径错」；另一轨做指标对账——同一业务问题，分别用语义层的物化定义和模型生成的 SQL 各算一遍，数字对不上就是口径事故。在线侧，最有效的信号是采纳率的分级：用户直接导出或下钻视为采纳，改写重问视为软失败，追问澄清视为歧义，连续失败视为硬失败。把采纳率按问题类型切片看，比看总分更能定位语义层的缺口。

评估集本身也需要工程治理。参考 SQL 会随口径修正而过期，所以要给每条样本标注口径版本，口径一改就重跑历史判定；评估集还要防泄漏——不要把评估问题放进 few-shot 池或修正样本池，否则回归分数会虚高。实验管理上，每次提交都要记录模型版本、提示版本、语义层版本与对应分数，任何一次掉点都能在十分钟内归因到具体变更。这三件事合起来，才是「评估进 CI」的完整含义：不是跑一个校验脚本，而是一套可追溯的实验制度。

八、可靠性与人在回路：修复回路、澄清与降级

执行失败不是终点，是回路起点。最基本的一条回路是错误反馈重生成：把引擎报错（语法错误、列不存在、类型不匹配、超时）连同原 SQL 一起喂回模型重试，DIN-SQL 把这个环节称为自纠错，工程上要控制的是重试上限（一般两到三次）与错误类型分流——语法与引用错误适合自动重试，权限与成本拒绝必须原样透传给用户，静默重试只会制造更深的信任裂痕。更结构化的做法是多智能体协作，MAC-SQL（arXiv:2312.11242）把生成、精化、预览拆成三个角色协同，简化版在工程里就是一个「生成器加一个拿着 EXPLAIN 结果挑毛病的评审器」。

澄清是第二类回路。BIRD 团队在 BIRD-Interact 方向上明确论证：交互与沟通是前沿模型成为可靠数据库助手的关键。落到产品上是歧义检测——当问题里的时间词、指标名或实体在语义层命中多个候选（「上周」两种解释、「GMV」三个口径），不要硬猜，给选项让用户点。实测经验是：一次便宜的澄清换来的是采纳率的成倍提升，比任何提示词优化都值钱。

第三类是降级与人在回路：置信度低或涉及高敏数据时，退一步出示候选 SQL 让用户确认后再执行；用户无权限的数据，引导到他有权限的语义层视图并说明原因，而不是报一个冷冰冰的权限错误。全程审计是第四件必做事：每次问数留痕——原始问题、解析出的语义结构、生成的 SQL、执行计划、结果摘要、用户反馈。这份留痕既是合规要求，也是最有价值的资产：被分析师修正过的查询是修正回路与评估集的天然来源，问数应用因此自带数据飞轮，用得越久越准。

九、落地清单：生产级问数应用的十二项检查

把前八节收拢成一张可勾选的清单，分四组。语义组四项：① schema 全量文档化，每列有业务描述与样例值；② 核心指标接入语义层（Cube 或 dbt metrics），禁止口头口径；③ 口径卡片沉淀歧义映射（脏值、同义词、时间词）；④ schema linking 检索上线，并有召回质量抽检。生成组三项：⑤ 提示结构固定为「裁剪 schema + 口径卡片 + 相似查询 few-shot」，进版本管理；⑥ sqlglot 语法闸加 AST 语义闸必开；⑦ 安全闸在代码层实施只读白名单与 LIMIT 注入。

执行组两项：⑧ 分析查询与 OLTP 物理隔离（下推 OLAP 或 DuckDB 会话引擎），带超时、资源组、结果集上限三件套；⑨ EXPLAIN 成本预算与多租户配额生效。治理组三项：⑩ 三元组评估集进 CI，执行准确率与指标对账双轨；⑪ 采纳率分级埋点加全链路审计留痕；⑫ 错误回路、澄清交互与人在回路降级三种失败路径都有产品化出口，而不是留白。

最后一句话收束：问数应用的本质，是把「数据访问的语言学问题」翻译成「数据库的物理学问题」——模型负责翻译的第一稿，语义层决定翻译的上限，执行层为一切失误兜住下限，评估与审计决定这件事能不能对业务开口说话。四层契约齐了，text-to-SQL 才算从演示稿走向生产系统。

---

一句话摘要：问数应用的可信度不来自模型本身，而来自四层契约——语义层的口径约束决定上限，生成后的语法与安全校验挡住幻觉，执行层的成本治理兜住下限，可审计的呈现与三层评估决定它能否上线；Spider 2.0 与 BIRD 之间六倍的性能落差说明，这段路是工程问题，不是模型问题。

参考文献

1. Yu, T. et al. Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL Task. arXiv:1809.08887, 2018. https://arxiv.org/abs/1809.08887
2. Lei, F. et al. Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows. arXiv:2411.07763, 2024（ICLR 2025 Oral）. https://arxiv.org/abs/2411.07763
3. Li, J. et al. Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs（BIRD）. arXiv:2305.03111, 2023. https://arxiv.org/abs/2305.03111
4. Pourreza, M. 与 Rafiei, D. DIN-SQL: Decomposed In-Context Learning of Text-to-SQL with Self-Correction. arXiv:2304.11015, 2023. https://arxiv.org/abs/2304.11015
5. Gao, D. et al. Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation（DAIL-SQL）. arXiv:2308.15363, 2023. https://arxiv.org/abs/2308.15363
6. Li, J. et al. MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL. arXiv:2312.11242, 2023. https://arxiv.org/abs/2312.11242
7. Talaei, S. et al. CHESS: Contextual Harnessing for Efficient SQL Synthesis. arXiv:2405.16755, 2024. https://arxiv.org/abs/2405.16755
8. BIRD Benchmark 官网与排行榜（12,751 问题-SQL 对、95 库 33.4 GB、37 领域；EX 排行榜与 BIRD-CRITIC 数据），访问于 2026-10-25. https://bird-bench.github.io/
9. Spider 2.0 官网与排行榜（632 企业级工作流任务；o1-preview 17.1%、GPT-4o 10.1% 对照 Spider 1.0 的 86.6%），访问于 2026-10-25. https://spider2-sql.github.io/
10. DuckDB GitHub 仓库（42,504 星，MIT，pushed 2026-10-23），GitHub API 实测于 2026-10-25. https://github.com/duckdb/duckdb
11. sqlglot GitHub 仓库（9,719 星，MIT），GitHub API 实测于 2026-10-25. https://github.com/tobymao/sqlglot
12. Vega-Lite GitHub 仓库（5,527 星，BSD-3-Clause），GitHub API 实测于 2026-10-25. https://github.com/vega/vega-lite
13. Cube（开源语义层）GitHub 仓库（21,072 星），GitHub API 实测于 2026-10-25. https://github.com/cube-js/cube
14. Vanna GitHub 仓库（23,813 星，MIT，agentic retrieval text-to-SQL），GitHub API 实测于 2026-10-25. https://github.com/vanna-ai/vanna
15. defog-ai/sqlcoder GitHub 仓库（4,046 星，Apache-2.0），GitHub API 实测于 2026-10-25. https://github.com/defog-ai/sqlcoder
16. DataEase SQLBot GitHub 仓库（6,960 星，2025-04 开源的 RAG 智能问数系统），GitHub API 实测于 2026-10-25. https://github.com/dataease/SQLBot
17. duckdb-wasm GitHub 仓库（2,148 星，MIT），GitHub API 实测于 2026-10-25. https://github.com/duckdb/duckdb-wasm
18. dbt-core GitHub 仓库（14,074 星，Apache-2.0），GitHub API 实测于 2026-10-25. https://github.com/dbt-labs/dbt-core