自然语言转 SQL（Text2SQL）技术旨在降低数据查询的技术门槛，但一直面临 "灵活性"、"准确性" 与 "查询复杂性" 难以兼顾的技术困境。直接由大语言模型生成 SQL 存在语义 "幻觉" 会带来准确性问题，引入结构化中间层通过牺牲查询复杂性换来准确性的有限提升，仍然难以满足企业级 BI 场景的需求。润乾 NLQ 技术采用 "规范文本" 作为中间层，构建人机均可理解的中介语言，将不确定性限制在自然语言理解阶段，并通过人类可确认的方式解决准确性问题，再利用规则引擎转换准确的 SQL 进行查询，同时 "规范文本" 的设计为支持复杂查询提供了基础。能够同时获得灵活性、准确性与复杂性，而且还有巨大的成本优势，为 Text2SQL 技术的实用化提供了一条可行的工程路径。

背景

在商业智能（BI）领域，如何让非技术背景的业务人员直接、高效地获取数据洞察，成为了一个关键的商业需求。ChatBI 等自然语言交互式查询技术的出现，正是为了满足这一需求，将用户以自然语言表述的查询意图，转换为可执行的 SQL 语句。大语言模型（LLM）的突破性进展，使得直接利用 LLM 实现从自然语言到 SQL 转换成为可能。

直接生成：基于大语言模型的“一步到位”及其局限

用 LLM 直接将自然语言转换为 SQL 语句是最直观的技术路径，具体来讲，就是通过提示工程、模型微调或检索增强生成等技术将领域知识注入模型，生成符合业务需求的 SQL 语句。

LLM 能够理解和泛化千变万化的口语，对用户而言几乎没有表达上的限制，体现出出色的灵活性。同时，得益于在海量代码数据上的预训练，LLM 理论上具备生成多表 JOIN、嵌套子查询等复杂 SQL 功能的能力，为处理复杂业务场景提供了可能。

然而，该方案有个根本性的缺陷：LLM 幻觉导致的准确性问题，这对企业级应用是致命的。LLM 可能生成语法正确但语义错误的 SQL，比如混淆关键业务指标、错误构建多表关联逻辑，或在时间计算等业务规则上出现偏差。在企业决策场景中，错误的查询结果就可能导致重大损失，这种不确定性是企业无法接受的。

不幸的是，缺乏有效的确认机制来克服幻觉问题。Text2SQL 的应用场景大都是 BI，其用户是业务人员，LLM 生成的 SQL 对业务人员而言是读不懂的 "天书"，也就无法确认查询意图是否被正确理解，这使得语义错误难以及时发现和纠正。

此外，该方案的实施成本极高。无论是通过微调训练专用模型，还是构建 RAG 知识库，都需要组建专业的 AI 技术团队，其技术难度和实施成本相当于 "为了坐飞机而建立飞行员团队"，对绝大多数企业而言不具备可操作性。

中间层路径：引入结构化层的“控幻”尝试及代价

为应对 LLM 直接生成 SQL 时的不可控性，业界引入 "中间表示" 的折中方案。这一路径采用 "分而治之" 的策略，将复杂的 Text2SQL 任务拆解为两个阶段：首先由 LLM 将自然语言转换为结构化的中间表示，比如许多解决方案会设计一套 MQL（Metrics Query Language）语法，再通过确定性的规则引擎将 MQL 编译为 SQL 执行。

然而，这种方案在准确性方面并未得到实质性提升。虽然将 LLM 的任务限定为生成结构固定的中间表示确实约束了其输出空间，但由于 MQL 等中间语言缺乏公开的大规模训练语料，当中间层设计得较为复杂时，未经训练的 LLM 会因不熟悉语法规则反而出现更严重的幻觉。即使投入成本进行 Fine-tuning，也因缺乏充足的训练样本而难以达到理想效果，准确性问题依然存在。

为了在表面上提升准确性，不得不严重压制查询的复杂性。将中间层设计得足够简单，LLM 受限后，准确性确实能大幅提高。但这又导致无法表达很多复杂业务逻辑（如多表关联、嵌套查询等）。这虽然在一定程度上降低了出错率，却又限制了应用范围。无论用户如何变换问法，都无法实施复杂功能的查询，制约了其实用价值。

而且，仍然缺乏有效的确认机制。简化中间层只能降低错误率，不可能完全消除 LLM 的幻觉。而以 JSON、XML 或自定义 MQL 格式呈现的中间层对业务用户而言仍然难以理解，无法有效确认，准确性问题不能根除。

此外，实施成本也依然居高不下。中间表示本身无法解决领域知识缺失的问题，仍需依赖 Fine-tuning、RAG 等高成本技术手段将企业特定的业务知识注入模型，导致整体实施与维护成本难以控制。

当前的技术路径未能完美解决 Text2SQL 的核心挑战，这是一个“三难困境”：在现有的技术框架下，灵活性（理解多样化表达）、准确性（生成正确 SQL）与查询复杂性（支持高级操作）三者难以兼得。

两条路径看似取舍不同，但核心困境如一：生成的 SQL 或 MQL 均无法被业务用户理解和确认。当查询的准确性始终存在疑虑且无法验证时，技术自然难以落地。

破局之路：基于“规范文本”的 NLQ 架构

针对上述困境，润乾 NLQ 提出了一种新的三阶段架构，其核心在于通过可确认的 "规范文本" 这一设计，重构了人机协作的查询生成流程。

流程架构

该架构的完整转换路径为：

在此流程中，增加了一个规范文本的环节。从自然语言到规范文本的转换由 LLM 实现；从规范文本到 MQL 的转换由专门的 NLQ 引擎完成；从 MQL 到 SQL 的转换则就是常规的代码翻译程序了。

这里的突破在于“规范文本”的引入，规范文本作为人类可读的中间层，为用户提供了确认查询意图的机会，这是解决准确性问题的关键。

“规范文本”：人机协同的语义枢纽

规范文本，顾名思义，就是一种规范的自然语言形式，其价值在于同时具备人类可读性与机器可解析性。

这里列举一些规范文本的例子：

• 出生日期在 1986 年 1 月至 1986 年 7 月的雇员
• 2023 年北京发往青岛的订单
• 商品单价大于等于 9.5 小于等于 12

可以看到仍然是自然语言形式的规范文本并不是非常死板，甚至有些还包含了动词，解析起来有相当的难度。

类似的，再举一些不规范文本，也就是灵活的自然语言的例子：

• 出生日期在 1986 年 1 月至 7 月的雇员（前后单位不统一，后面缺少年份）
• 请帮我查一下 2023 年北京发往青岛的订单（多了“请帮我查一下”这类虚词
• 查询商品表中单价在 9 块五毛钱到等于 12 块钱的（查询条件描述过于口语化）

规范文本具有一个关键特性：人机双向可读。

人类可确认性，这是最核心的价值。由于采用业务人员熟悉的自然语言形式，而非 JSON、XML 等技术格式，用户能够直观理解并确认："对，这就是我想查的！" 这一确认环节成为解决幻觉问题的关键。

同时，规范文本具备机器可解析性，虽然表现形式类似于自然语言，但遵循规范的结构约束和词汇表限制，可以通过确定的解析规则进行自动化处理。

规范文本的结构化特性为后续的 MQL 设计提供了基础，使其能支持包括多表关联、指标计算等复杂查询功能，而不会像以往中间层那样压制查询能力。

规范文本的意义

这个架构中，LLM 的角色定位发生了根本性转变。以往方法中，LLM 被期望直接生成精确的 SQL 或 MQL。而在新架构中，LLM 的任务被简化为将多变的自然语言表达转写为标准化的规范文本，这一任务与 LLM 的语义理解核心能力高度匹配。

这种角色转变带来了显著的技术优势。由于 LLM 仅需按照简单的 prompt 规则进行文本变换，无需深度理解企业特定的领域知识。现成的通用大模型就可以工作，不再需要投入高昂成本进行 Fine-tuning 或构建 RAG 知识库。实施的核心工作转变为构建 NLQ 业务词典，这一任务的技术门槛远低于模型训练，普通开发人员即可胜任。

任务简化还带来了明显的成本优势。LLM 的提示词长度大幅缩减，推理过程更加轻量，单次查询的token 消耗和计算成本可降低 1-2 个数量级。NLQ 引擎基于规则实现，涉及的词汇在数千到数万量级，不需要多大算力，用普通 CPU 即可实现高并发处理，整体成本很低。

在稳定性方面，即使 LLM 在生成规范文本时出现偏差，也有两重保障：一方面，规范文本的人类可读性使用户能够及时发现并纠正问题；另一方面，NLQ 引擎会对输入进行校验，确保只有符合规范的文本才会进入后续流程。

基于规范文本的 NLQ 架构成功解决了 Text2SQL 的核心困境，实现了灵活性、准确性和复杂性三者兼得。通过 LLM 处理自然语言的多样性，确保了灵活性；通过规范文本的可确认性和后续的确定性转换，从根本上保障了准确性；同时规范文本的结构化特性为支持复杂查询提供了基础，使得企业级应用的复杂需求能够得到满足。

其实，规范文本的生成并不强制依赖 LLM。由于规范文本本身就是自然语言形式，业务人员经过简单培训后可以直接编写，此时甚至不需要 LLM，只用 NLQ 引擎解析规范文本就可以实现 Text2SQL，这就形成了成本更低的解决方案，以适应更多应用场景。

实现的考虑

架构的核心实现涉及两个关键环节：MQL 的设计与 NLQ 引擎的开发。

MQL 层的必要性与挑战
在架构中引入 MQL 层具有关键意义。作为规范文本的确定性编译目标，MQL 承担着双重使命：首先，要利用它彻底消除自然语言中可能存在的残余歧义，规范过的文本，仍然有可能存在多种合理的解释或者无法解释，还需要有种严格精确的语法来确定最终的查询意义；其次，它要通过精心设计的语法结构，将查询能力进行限制，杜绝过于随意的查询请求，但仍要保持足够的复杂度。既满足企业级复杂需求，又可以基于可控性获得准确性。MQL 需要精心设计以平衡表达力与规范性，这其中的设计逻辑与实现细节，将在下一篇文章中深入探讨。

NLQ 引擎的开发挑战
另一个关键技术挑战在于 NLQ 引擎。该引擎需要具备一定程度的语言解析能力，能够准确理解规范文本中多样的表达方式。从技术层面看，这相当于构建了一个小语言模型（Small Language Model），其开发难度也不容小觑。由于 NLQ 引擎基于规则构建，不同语种的语法规则和表达习惯完全不同，无法直接通用。例如，汉语和英语在语序、分词、句式结构等方面存在根本性差异，需要分别构建独立的解析体系。这里将先聚焦于解决汉语环境下的 NLQ 解析问题。

尽管存在这些技术挑战，但该架构通过规范文本的创新设计，在自然语言的灵活性与机器处理的确定性之间找到了平衡点。特别是通过可确认的 "规范文本" 这一中间表示，解决困扰 Text2SQL 领域的准确性问题，为其在企业级应用中的规模化落地提供了切实可行的工程路径。