Text2SQL 破局便捷的技术解析之三：NLQ 词典与准确性

在本系列的前两篇文章（Text2SQL 破局技术解析之一：规范文本与灵活性和 Text2SQL 破局技术解析之二：MQL 达成与复杂性）中剖析了 Text2SQL 领域面临的 "灵活性、准确性与查询复杂性" 三难困境，并提出了润乾 NLQ 的破局架构：引入 LLM 处理自然语言的多样性来保障灵活性；通过人类可读的规范文本来消除 LLM 的幻觉问题，确保准确性；再用 MQL、DQL、SPL 的分工协作来支撑查询复杂性。

这一架构的优势在于实施可行性。引入规范文本和词典机制，不需要投入高昂成本进行 Fine-tuning 或构建 RAG 知识库，更无需组建专业的 AI 工艺团队，降低了实施 Text2SQL 的技术门槛。

那么，架构中的 NLQ 规则引擎，是如何能像“理解了一门语言”一样，将仍有相当自由程度的规范文本准确地转换为语法严格的 MQL？就像前篇所言，这个 NLQ 已经相当于实现了一个小语言模型（SLM）。这就是本篇将要解析的NLQ 词典，它是 NLQ 引擎的“大脑”与“规则手册”，支撑整个架构完成准确性。

NLQ 词典：语义的映射基础

一个结构化的业务 - 数据映射知识库，定义了业务语言中每个“词”在资料世界中身份、行为逻辑和关联关系。就是NLQ 词典

基本概念：构筑查询语义的积木

NLQ 词典的构建围绕以下几个概念展开，它们共同构成了从自然语言到 MQL 的转换路径：

表与实体：表对应数据库中的物理表。实体是表的业务化视图，本质上是表的子集，同一个物理表可以对应多个不同的实体。例如，“订单”是一个表，除了订单实体外，还可以有“新订单”（本年订单）实体，附带了 Year(签单日期)=Year(Now()) 的过滤逻辑。每个实体可以设置不同的字段组合和过滤条件，满足不同的业务查询需求。
宏字段：是查询的最小语义单元，可以映射到物理表的字段（如“订单金额”），并有更多的扩展性：
- 计算字段：通过已有字段计算得出，如通过“身高”和“体重”计算“BMI 指数”：EMPLOYEE.WEIGHT*10000.0/EMPLOYEE.HEIGHT/EMPLOYEE.HEIGHT。
- 外键字段：依据订单表中的“客户 ID”关联到客户表，从而引入“客户名称”、“客户城市”等字段，这里许可借助 DQL 的外键属性化思路，实现了跨表信息查询。

指标：通过表达式定义的聚合度量。有些复杂的计算指标会采用 SPL 语法实现 SQL 不擅长的计算。比如月活，留存率，股票连涨天数等。指标为困难业务场景提供了强大的计算能力。

字段簇与簇词：这是 NLQ 词典的特色，用于处理业务中常见的组合信息与语义歧义。
- 字段簇是一组在业务上紧密相关的宏字段的集合。例如，为订单表定义“发货”簇，包含“发货城市”、“发货日期”、“发货省份”；同时定义“收货”簇，包含“收货城市”、“收货日期”、“收货省份”。
- 簇词是字段簇的业务别名，如“发货”、“收货”。当用户在规范文本中使用簇词时，如“发货城市日期”，NLQ 引擎会优先在该簇词对应的字段簇内寻找“城市”和“日期”字段。这一机制避免了全局搜索可能带来的歧义，例如，能区分用户要的是“发货日期”而非“签单日期”。
- 举例：查询“订单编码，发货城市日期，收货城市日期”，引擎能准确识别出四个不同的字段，结果列标题也会清晰显示为“发货城市”、“发货日期”、“收货城市”、“收货日期”。
维、维词与常数词：用于描述数据的分析视角和构建过滤条件，实现智能过滤。
- 维定义了分析视角，如“城市”、“省份”、“年月”、“性别”。
- 维词是维的业务名称。
- 常数词与维绑定，将业务语言中的值映射到底层数据存储。例如，将“北京”、“上海”与“城市”维绑定，其“真实值”对应数据库中的城市编码（如 30101）。用户输入“籍贯北京的雇员”时，引擎能理解为 HOMECITY=30101，而用户无需知晓底层编码。
- 举例：查询“男雇员”或“直辖市客户”，尽管没有指定字段，引擎也能经过常数词“男”、“直辖市”自动关联到“性别”、“城市类型”等维，并找到表中与之匹配的字段进行过滤。

特色词型：应对灵活表达的武器库

为了覆盖多样化的自然语言表达，NLQ 词典配备了多种特色词型：

无效词：用于过滤掉查询中的口语化虚词和语气词，如“请帮我查一下”、“有哪些”、“记录”等，使引擎能聚焦于有效信息。
宏词：用于处理口语化的业务概念，将其转换为规范的查询逻辑。例如，可以将“已售罄”定义为宏词，其背后对应的逻辑是“库存量 <= 0”。当用户查询“已售罄的商品”时，NLQ 引擎会将其转换为规范的过滤条件。
动词：用于建立更繁琐的过滤逻辑，特别是涉及多个字段簇时。例如，定义动词“发往”，可以将其左侧条件关联到“发货”簇，右侧条件关联到“收货”簇。这使得“北京发往青岛的订单”能被准确解析为“发货城市 = 北京且收货城市 = 青岛”。动词“入职超过 10 年”则能将“超过 10 年”映射到“雇用年数”这个计算字段。
量词：用于处理带有单位的数值，自动进行单位换算。例如，定义量词 "万元"，其换算系数为 10000。当用户查询 "金额大于 20 万元" 时，引擎会自动将 "20 万元" 转换为 200000 进行数值比较。用户在表达数值时可以使用更符合业务习惯的单位，而无需关心底层数据的存储形式。
比较词与连词：大于、小于、等于等比较词定义了过滤关系；且、或等连词则明确了多个过滤条件间的逻辑关系，从而支持“年龄大于 40 且性别男”这样的复杂筛选。

实例解析：从文本到 MQL 的转换

下面用几个示例，理解词典如何驱动 MQL 生成。

例 1：基础过滤查询

文本：姓名为李芳的职务、出生日期和年龄
NLQ 引擎解析：
- 分词：姓名，李芳，职务，出生日期，年龄。
- 识别：“姓名”、“职务”、“出生日期”、“年龄”被识别为字段词，确定它们来自员工实体。
- “李芳”被识别为常数，由于前一个词是字段词“姓名”，引擎将其构建为过滤条件姓名 ='李芳'。
- 生成 MQL：SELECT 姓名, 职务, 出生日期, 年龄 FROM EMPLOYEE WHERE 姓名 ='李芳'

例 2：字段簇与动词消除歧义

文本：查询北京发往青岛的订单
NLQ 引擎解析：
- 分词：北京，发往，青岛，订单。
- 识别：“订单”被识别为实体。
- “发往”被识别为动词簇词。查询动词定义，知其关联“发货”和“收货”两个字段簇。
- “北京”在动词左侧，被分配给“发货”簇中的“城市”字段。
- “青岛”在动词右侧，被分配给“收货”簇中的“城市”字段。
- 生成 MQL：SELECT ... FROM ORDERS WHERE (发货城市 =30101) AND (收货城市 =20201)(其中代码由常数词映射而来)

例 3：复杂聚合与子查询

文本：订单金额总和大于 20 万元的女员工
NLQ 引擎解析：
SELECT 性别 ,…,ORDERS.sum(订单金额) AS 订单金额总和
FROM EMPLOYEE
WHERE (性别 ='女')
JOIN ORDERS
HAVING 订单金额总和 >20*10000
- 识别主体“员工”为实体。
- “女”为常数词，与“性别”维匹配，过滤员工表。
- “订单金额总和大于 20 万元”是一个聚合条件。识别出“订单金额”来自订单表，“总和”是聚合词，“大于 20 万元”是比较条件。由于订单表与员工表通过“销售”字段关联，引擎识别出这是一个基于子表聚合结果的过滤。
- "大于 20 万元" 这个比较条件，NLQ 引擎会识别 "万元" 为量词，并根据词典中定义的换算系数（1 万元 =10000）自动进行单位转换。"20 万元" 在生成 MQL 时将被转换为 20*10000，而不是直接使用数值 200000，体现了量词保持业务表达的自然性。
- 生成 MQL：此 MQL 会表达为：从员工表中查询，其条件为子表（订单表）中对应销售员的订单金额总和大于 200000

例 4：多表汇总与复杂指标计算

文本：各省的员工数、产品数和大订单数
NLQ 引擎解析：
SELECT EMPLOYEE.count(雇员编码) AS 员工数,
PRODUCT.count(产品编码) AS 产品数,
ORDERS. 大订单数 () AS 大订单数
ON 省份
FROM EMPLOYEE BY 省份
JOIN PRODUCT BY 省份
JOIN ORDERS BY 省份
- 识别 "各省" 为维词，作为统一的分组维度。
- "员工数"、"产品数" 被识别为基于 EMPLOYEE 表和 PRODUCT 表的计数聚合。
- "大订单数" 是一复杂指标，该指标采用 SPL 语法定义，用于计算订单金额超过最大订单金额 50% 的订单数量。
- 引擎识别出这是一个多表同维汇总与复杂指标结合的查询，需要按照 "省份" 维度分别从员工表、产品表和订单表进行聚合计算，其中订单表需要调用 SPL 指标函数进行繁琐计算。
- 生成 MQL：此 MQL 会表达为按省份维度，分别统计员工数量、产品数量，并调用大订单数指标进行计算。

指标定义：
大订单数指标采用 SPL 语法定义，实现 SQL 难以直接表达的复杂计算：大订单数 = (x=?1.max( 订单金额)/2, ?1.count(订单金额 >=x))

该例子展示了 NLQ 如何同时处理多表关联（员工表、产品表、订单表按省份关联）、基础聚合（计数统计）和繁琐指标计算（基于相对阈值的大订单判定）。

解析过程是基于词典规则的、确定性的通过，不用“再训练”，每一步可追溯、可解释、可调试。当出现解析错误或无法解析的查询时，能够在规则框架下快速定位问题，是缺少词条、字段簇配置不当，还是维度映射不完整，当然也有可能是引擎的 BUG。这种可解释性将获得持续优化的能力，通过补充词典配置等操作即可修复问题。相反， LLM 过于复杂而失去可解释性，用它直接生成 SQL 或 MQL 也就缺乏可控性：生成失败时难以诊断根源，即使投入大量成本进行再训练，也难以预测和保证改进效果。

词典的构建、管理与工程实践

词典构建是实现准确性的核心，润乾 NLQ 提供了可视化的设计器来拥护这一过程。

元数据导入：从 DQL 语义层自动获取表、字段、维度和关联关系等基础信息，为词典奠定内容基础。
业务化封装：
- 定义字段词：将“SALARY”改为“薪水”，将“PRODUCT_NAME”改为“产品名称”。
- 创建字段簇：根据业务逻辑，将字段分组，如创建“发货信息”、“收货信息”、“客户信息”等簇。
- 设置实体：为同一张表创建不同业务视图，如“员工基础信息”、“员工财务信息”等，并部署不同的字段簇。
- 配置词汇表：维护维词、常数词、比较词、动词等。
持续测试与优化：借助设计器的“搜索实验”功能，使用真实例句进行测试，查看解析过程与结果，发现并修复词典配置的边界案例，迭代优化，逐步提升解析准确率。