企业落地 NL2SQL，需要的是「AI-ready Data」和「小模型」

当 NL2SQL 从 Demo 走向生产，关键不在“更大的模型”，而是“更干净的数据底座 + 更小的专用模型 + 更可控的工程化流程”。

摘要：

• 先数据、后模型：把元数据、业务语义、权限、样例 SQL 做成“AI-ready Data”，是 NL2SQL 能否可靠落地的第一性问题。

• 小模型足够用：以 3B–7B 级别的代码 /SQL 友好模型，配合 LoRA 微调 + 语法约束解码 + 执行校验，就能获得很好的效果

• 落地成本低：相比动辄 100B 参数量以上的全量大模型，小模型的实际落地可能性更大，需要的算力支撑对于企业来说更加容易投入。

• 评估要换维度：Execution Accuracy（执行一致性） 比 Exact Match 更接近真实可用性，应与回放 / 灰度一起形成闭环。

• 工程化路径：建立“Schema 服务 → 计划器（小模型）→ 安全执行沙箱 → 观测与纠错回路”的最小可行系统（MVP），再逐步引入 AST 约束、检索增强、对齐训练。

1. “大模型 + 开箱即用”常常失灵

• 业务语义缺席：amt、dt、no 在不同库含义不同；缺少 别名词典、指标口径、实体映射，模型只能基于已有训练资料进行推理。

• 治理与合规割裂：多租户 / 跨源 JOIN、限流、行列权限、审计等使“能生成 ≠ 能执行”。在真实生产环境业务流程背景来支撑查询，而模型往往无法直接获得这部分含义。

• 评估口径失真：只看字符串级 Exact Match，忽略“结果等价”与“能否在你的库上跑通”。

• 成本 / 延迟不可控：把大而全上下文塞给通用大模型，需要对于 prompt 做深度优化，同时过长的上下文还可能导致 Context-Rot 以及 Lost in the middle 的问题出现。

我们实际场景落地过程中发现，没有 AI-ready data，就没有可落地的 NL2SQL。

2. 任务属性决定解法：NL2SQL 更像“受限代码生成 / 语义解析”

• 输出是形式语言（SQL）：语法强约束、词表相对小、可执行、可验证。

• 输入可结构化：数据库 Schema、主外键、候选列 / 表、样例值都可作为外部信号。

• 所需推理是“结构性推理”：列 / 表选择、聚合、条件组合、时间窗，而非开放域常识。

这类问题适合通过 结构化约束 + 外部知识接口 来“降维”，而不是单靠更大的通用常识模型“硬顶”。

3. 为什么选小模型：理论支持 + 工程证据

3.1 语法 /AST 约束降低搜索熵

对形式语言施加 语法 /AST 约束解码（如 PICARD/CFG/JSON-Schema/XGrammar 一类），在解码每一步 屏蔽不合法 token，把“自由生成”变为“受限搜索”，显著降低无效 SQL、提升可执行率。

含义：当输出空间可被约束时，小模型 + 约束 = 大增益。

3.2 外部结构信息替代“内生常识”

引入 schema linking（表 / 列同义词、主外键、示例值） 与 候选集剪枝，把“隐式知识”外显为“可调用的结构化接口”。

含义：当外部信号充足时，模型无需承载过多通用知识，合适的容量即可。

3.3 规模 - 性能 - 成本的最优点

根据 scaling laws：质量与参数 / 数据 / 算力相关，但在企业场景必须把 推理成本与延迟 纳入目标函数。 这里我们参考了 DeepMind 的理论【Training Compute-Optimal Large Language Models】 ，在更高质量，更加密集的数据集上，参数较小的模型也能够在固定任务上超越大参数量模型。

在 Closed-book question answering 场景上，70B 的 Chinchilla 甚至能够超越 128B 的 GPT-3。

微软的 phi 系列模型也从侧面证实了这一点

含义：在可强约束、可外接结构信息的 NL2SQL 上，最优点通常落在 3B–7B 代码向模型，而不是一味做大。

3.4 工程证据：窄域任务上，代码向小模型常优于通用大模型

• 预训练偏置：代码 /SQL 语料带来强语法与组合性偏置，天生适配 SQL 生成。

• 确定性更强：配合保守解码（低温度 / 不采样 /beam 可选）与固定输出前缀，小模型更容易“按模板出活”。

• 延迟与成本优势：可本地 / 私有化部署，甚至可以做本地化的 A/B 测试 与小模型灰度上线。降低运维难度和部署成本

4. 实践过程

我们在 CSpider/CSpider 衍生数据上，围绕 M-Schema 数据表示、约束池数据增强、BM25→SIC 两级 Schema Linking 与 小模型 LoRA 微调，打通“从训练到推理”的一致性链路，并在内部集上显著降低结构 / 语义幻觉、提升执行一致性。

4.1 技术架构总览

• 两步式推理：先做 Schema Linking（筛表 / 列 / 外键），再做 SQL 生成（在精简 schema 上生成）。这样可在大库上显著降维并提升准确率。

• 小模型路线：以 Qwen2.5-Coder-3B/7B 为基座，LoRA 轻量精调；用 DeepSpeed 做显存 / 吞吐优化。

• 数据侧增强：以 M-Schema 提供字段类型 / 中文描述 / 主外键 / 真实值样例；引入 约束池 自动注入排序 / 去重 /Top-K/ 窗口等口径。

• 统一数据底座：整个流程建议构建于 MatrixOne 这类 HTAP 数据库之上。其架构能避免“元数据在交易库、数据在分析库”的割裂状态，从源头整合 Schema、业务数据与日志，为 AI-ready data 提供单一可信源。更进一步，Matrix Intelligence 平台在此基础上，将 Schema、元数据、业务词典与权限等进行统一纳管，形成面向 AI 的数据资产目录，从基础设施层面解决语义缺席问题。

4.2 数据与 Prompt：M-Schema + 约束池

M-Schema 在传统“表 / 列清单”之上，补充 类型、主键、中文释义、真实值示例，显著提升字段语义可读性与模型可对齐性（示例略）。

在训练数据构造上，我们进一步将 字段示例值 抽取注入训练样本；在推理时对不可读字段名做 临时可读映射→后处理映回，实际提高了“表 / 列命中”。

约束池 自动识别查询语义类型（计数 / 聚合 / 多行）并注入 去重、精度、排序、限制 等约束，增强数据多样性与鲁棒性。

这一系列“AI-ready data”的准备工作，从多源异构数据到高质量的 M-Schema，恰好是 MatrixOne Intelligence 这类平台的价值所在。它通过以下能力，将数据准备流程从手工作坊式的脚本开发，升级为可治理、可复用的工程化体系：

统一接入与纳管：通过内置连接器，自动化地从业务库、数据湖、SaaS 应用等数据源同步数据与元数据，形成统一的数据资产视图。

SQL 驱动的数据流：所有清洗、转换、特征构建（如拼接字段、构造 Flag）等步骤，都可以通过标准的 SQL 编排成可调度、可监控的数据工作流（Workflow），保证了过程的透明与可维护性。

向量化辅助质检：平台内建的向量引擎不仅用于下游的语义检索，更能在数据准备阶段发挥关键作用。例如，可以对业务术语、字段注释进行向量化，通过相似度计算辅助发现同义词、识别命名不规范的“影子字段”，或对历史查询日志进行聚类分析，挖掘数据质量的薄弱环节。

训练 / 推理输入统一采用 ChatML 指令格式，并只在 assistant 段计算损失以稳定输出。

4.3 Schema Linking：BM25 粗排 → SIC 精排（两级）

• BM25 粗排：把“表 + 列 + 注释”拼成文档，对问句做 BM25 打分，取 Top-k 表；毫秒级延迟可支持在线。

• SIC 精排：加载在域内数据微调过的 Schema Item Classifier（Encoder+ 交互层），对表 / 列逐项相关性打分，产出精简 schema。

• 结果封装：把精简 schema 序列化回 M-Schema，与问句拼装成 RESDSQL 风格样本；同一流程用于训练与推理，保证 Train-Infer 一致。

工程要点：BM25 <5 ms；SIC 批量推理单批可处理数百问句，显存 <2 GB；Prompt 中重复注入问句降低 schema 噪声干扰。

4.4 幻觉抑制与效果

问题刻画：结构 / 语义 / 事实三类幻觉导致执行失败与答案错误，是落地核心风险；其根因包括 先验缺失、数据稀疏、Prompt 不足、采样过随机、训练数值不稳。

我们的方案：

• 两级 Linking 从源头压缩搜索空间；

• 低随机性推理（低温度 / 束搜索）；

• 结合 Executor-Guided 与语法约束（训练时语法惩罚 / 对比学习可选）。

实测收益：结构幻觉率 7.9%→1.3%，语义误配约 -18%；在 Spider-S4 内部集 Execution Accuracy +6.4%。

5. Key Results

流程概览：

通过 M-Schema（结构与示例值）、约束池（口径与规则）、BM25→SIC 两级 Linking 与 小模型 LoRA 精调 + 训练 - 推理一致性，我们在不依赖超大通用模型的前提下，显著压降结构 / 语义幻觉并提升 EX 指标；在企业库与业务小样本上也获得了稳定收益。

引用链接：

Spider：https://arxiv.org/abs/1809.08887

wikiSQL：A Comprehensive Exploration on WikiSQL with Table-Aware Word Contextualization（https://arxiv.org/pdf/1902.01069）

Training Compute-Optimal Large Language Models（https://arxiv.org/pdf/2203.15556）

Textbooks is all you need（https://arxiv.org/pdf/2306.11644）

Qwen2.5-Coder Technical Report（https://arxiv.org/pdf/2409.12186）