NL2SQL

一句话定义

NL2SQL（Natural Language to SQL）是把用户的自然语言数据需求转换为可执行 SQL 的技术与工程流程；在生产场景中，它通常需要语义层、元数据、检索、校验和人工治理共同约束，而不是让模型直接凭语言猜出查询。

摘要

它解决的是“业务人员如何用自己的问题访问数据”，但不能把它简化成一次模型翻译。自然语言经常缺少指标口径、时间范围、粒度、过滤条件、表关系和权限范围；而 SQL 即使能执行，也可能在口径、数据范围或成本上出错。因此，能否可靠交付取决于系统能否将隐含业务语义补全，并在生成后验证。

阿里技术的电商数研案例采用 NL2DSL2SQL：先将问题映射到规范化的指标—维度语义，再从语义生成 SQL。这个拆法把“猜表、猜字段、猜指标定义”的问题转化为可治理的资产问题，并把专家确认、资产健康度与执行结果校验放进同一条交付链。它与 RAG 有关联，但核心目标不只是检索相似文档，而是让生成结果符合明确的数据定义和可验证的查询契约。

详情

起源与背景

数据仓库、指标平台和 BI 系统积累了大量表、字段、指标与业务规则，使用者却往往不知道它们的命名和关系。传统分析依赖数据研发人员把业务问题转换成 SQL；NL2SQL 希望降低这一转换门槛，并将能力延展到自助分析和 ChatBI。

早期方案容易直接把用户问题与数据库 schema 一起交给模型生成 SQL。这在小 schema、低风险查询中可作为起点，但生产数据环境会迅速遇到歧义：例如“交易额”是否等于 GMV、是否含退款、按支付时间还是下单时间统计；“活跃商家”的口径和取数范围又是什么。没有明确语义时，语法正确的 SQL 仍可能给出错误业务结论。

核心机制 / 工作原理

可控的 NL2SQL 常分为四个连续层次：

1. 需求理解与澄清：识别指标、维度、时间、筛选、排序、聚合和结果用途；缺少关键条件时应追问或明确采用的默认口径。
2. 语义映射：把文本映射为受治理的指标、维度、实体及其边界，而非直接猜表字段。案例中的“标准名称 + 别名映射 + 语义边界”正是为这一步服务。
3. 查询规划与生成：依据语义层选择可用表、关联路径、聚合规则和预定义模板，再生成 SQL。模板适合高频、固定模式的分析，能够缩小模型的自由度。
4. 执行与验证：检查 SQL 是否符合权限、成本、语法和业务约束，并将结果、异常和人工修正回写为可复用的资产或规则。

自然语言问题
  → 需求澄清
  → 指标 / 维度语义（受治理的 DSL）
  → 表、关联和 SQL 模板选择
  → SQL 生成与执行校验
  → 结果、反馈与资产回写

这里的关键边界是：模型生成的是候选查询，不是已证实的业务事实。系统应把“解析到哪个指标”“使用什么口径”“生成了什么 SQL”“执行是否成功”变成独立可检查的证据。

应用 / 使用场景

• 数据研发：将需求分析、指标盘点、技术方案和 SQL 生成串为有状态的工作流。
• ChatBI：让业务人员以自然语言请求报表或分析，并以已沉淀的 SQL 模板提供 few-shot 示例。
• 指标平台：统一业务口径后，为检索、推荐、口径冲突预警和 SQL 生成提供同一份语义资产。
• 数据治理：从失败查询、人工修改和重复歧义中发现需要补充的别名、边界或资产规则。

局限与争议

• 语义资产冷启动昂贵：指标定义、依赖关系和口径边界需要领域专家确认，模型不能凭空替代这一工作。
• 生成正确不等于业务正确：数据库能运行的 SQL 仍可能选错时间字段、遗漏过滤条件或使用过期口径。
• 权限与成本不可后置：生产库必须在执行前控制数据范围、敏感字段、扫描量和高风险操作。
• 资产会持续劣化：表结构、指标和业务规则变化后，别名、模板、检索材料与评测集都需要持续更新。

与其他实体的关系

• RAG —— RAG 可为需求提供相关 schema、文档和示例，但需要语义层与校验将检索结果收束为正确查询。
• 知识库工程 —— 将指标、维度、模板、验证报告和反模式维护为可追溯资产，是 NL2SQL 持续可用的前提。
• Harness-Engineering —— 将多 Agent 协作、人工 Gate、结果证据和反馈回写编排为稳定的数据研发交付过程。

参考来源

• 从-Coder-到-Designer-电商团队数据研发的-Harness-Engineering实践 —— 电商数据研发中的 NL2DSL2SQL、语义资产治理与多 Agent 交付案例。