企业落地 NL2SQL，需要的是 AI-ready data 和小模型
作者 | 矩阵起源
转载自 | InfoQ
当 NL2SQL 从 Demo 走向生产，关键不在"更大的模型"，而是"更干净的数据底座 + 更小的专用模型 + 更可控的工程化流程"。
摘要
先数据、后模型：把元数据、业务语义、权限、样例 SQL 做成"AI-ready data"，是 NL2SQL 能否可靠落地的第一性问题。
小模型足够用：以 3B-7B 级别的代码/SQL 友好模型，配合 LoRA 微调 + 语法约束解码 + 执行校验，就能获得很好的效果。
落地成本低：相比动辄 100B 参数量以上的全量大模型，小模型的实际落地可能性更大，需要的算力支撑对于企业来说更加容易投入。
评估要换维度：Execution Accuracy（执行一致性） 比 Exact Match 更接近真实可用性，应与回放/灰度一起形成闭环。
工程化路径：建立"Schema 服务 → 计划器（小模型）→ 安全执行沙箱 → 观测与纠错回路"的最小可行系统（MVP），再逐步引入 AST 约束、检索增强、对齐训练。
"大模型 + 开箱即用"常常失灵
业务语义缺席：amt、dt、no 在不同库含义不同；缺少别名词典、指标口径、实体映射，模型只能基于已有训练资料进行推理。
治理与合规割裂：多租户/跨源 JOIN、限流、行列权限、审计等使"能生成 ≠ 能执行"。在真实生产环境业务流程背景来支撑查询，而模型往往无法直接获得这部分含义。
评估口径失真：只看字符串级 Exact Match，忽略"结果等价"与"能否在你的库上跑通"。
成本/延迟不可控：把大而全上下文塞给通用大模型，需要对于 prompt 做深度优化，同时过长的上下文还可能导致 Context-Rot 以及 Lost in the middle 的问题出现。
我们实际场景落地过程中发现，没有 AI-ready data，就没有可落地的 NL2SQL。
任务属性决定解法：NL2SQL 更像"受限代码生成/语义解析"
输出是形式语言（SQL）：语法强约束、词表相对小、可执行、可验证。
输入可结构化：数据库 Schema、主外键、候选列/表、样例值都可作为外部信号。
所需推理是"结构性推理"：列/表选择、聚合、条件组合、时间窗，而非开放域常识。
这类问题适合通过结构化约束 + 外部知识接口来"降维"，而不是单靠更大的通用常识模型"硬顶"。
为什么选小模型：理论支持 + 工程证据
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 测试与小模型灰度上线。降低运维难度和部署成本。
实践过程
我们在 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%**。
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）