在这个言必称“大模型”的时代，当几乎所有智能问数方案都在比拼谁的模型参数更多、谁用的 GPU 更贵时，我们却要提出一个“离经叛道”的问题：
如果抛开大语言模型（LLM）和昂贵的 GPU 算力，仅凭一套精心设计的规则体系，我们能把 Text2SQL 做到什么程度？
答案是：比你想象中更强大、更可靠，且已经足以解决一个确定领域内大部分的实际问题。
润乾 NLQ 正是这条技术路径的实践者。它不依赖于概率生成，不进行“黑箱”推理，而是通过构建一个深度结构化、可解释的“领域专用语言理解系统”，实现了在商业智能（BI）场景下，高准确率的自然语言到数据查询的转换。
为什么可以不用 LLM？领域语言的“收敛性”是关键
要理解这条路径的可行性，首先要打破一个迷思：并非所有自然语言都是天马行空、无限自由的。
在特定的专业领域，比如企业的商业智能分析人们用于查询数据的语言，存在着极强的模式和规律。它更像是“行业黑话”或“专业术语”，而非随意的日常聊天。
试想这些业务场景：
“查一下上月华东区的销售 TOP10。”
“对比一下 A 产品和 B 产品本季度的毛利率。”
“列出回款周期超过 90 天且合同金额大于 100 万的客户。”
这些语句虽由自然词汇构成，但其语义结构高度收敛：
意图明确：无非是“查明细”、“做聚合”、“搞对比”。
对象固定：围绕“销售”、“产品”、“客户”、“订单”等有限的业务实体。
逻辑模式化：条件（过滤）、分组（维度）、计算（指标）的组合方式是可枚举的。
这就像下围棋，虽然棋盘上的可能性近乎无限，但高手们的“棋谱”和“定式”却是有限的、可学习的。润乾 NLQ 要做的，不是学会人类的全部语言，而是精通BI 查询这门“方言”的典型“定式”。
核心引擎：一本可无限扩展的“业务词典”与“语法手册”
当然，让机器精通这门“方言”也不容易。NLQ 的解决方案是构建一个结构化的领域知识库，它由两部分构成：
业务词典：将每个词汇锚定到数据世界
词典是一个多层次、关系化的映射网络：
实体与字段：“订单”对应哪张表？“销售额”对应哪个字段，其计算公式是什么？
维度与成员：“城市”是一个分析维度，“北京”、“上海”是其成员，映射到数据库中的编码 30101、30102。
动词与关系：“发往”这个动词，定义了其左侧参数应匹配“发货”字段簇（如发货城市），右侧参数应匹配“收货”字段簇（如收货城市）。
量词与转换：“万元”是一个量词，定义其换算系数为 10000，使“大于 20 万元”能被自动转换为 > 20*10000。
语法手册：定义词汇如何组成合法查询
这套规则定义了如何解析一个查询句子的结构：
组合规则：“发货 城市 日期”应被识别为一个整体（字段簇），返回“发货城市”和“发货日期”两个字段。
消除歧义：当“日期”单独出现时，默认指向“签单日期”；但在“发货 日期”上下文中，则明确指向“发货日期”。
逻辑连接：“且”、“或”定义了多个过滤条件之间的布尔关系。
这个“词典”加“语法”的体系，构成了一个确定性的、可解释的编译系统。它的工作方式不是“生成”，而是“匹配”与“转换”。
从自然语言到数据查询：一场精准的“编译”之旅
当用户输入一句查询，系统会启动如下流程，这更像一个编程语言的编译过程：
第 1 步：分词与词法分析
输入：“去年北京发往青岛的订单”
→ 分词：【去年】【北京】【发往】【青岛】【订单】
→ 过滤无效词（如“的”）。
第 2 步：语义标注与匹配
【去年】→ 识别为时间维词，计算为 year(ADDYEARS(now(),-1))。
【北京】→ 匹配“城市”维的常数词，值 =30101。
【发往】→ 识别为动词，触发规则：左参绑定“发货城市”，右参绑定“收货城市”。
【青岛】→ 匹配“城市”常数词，值 =20201。
【订单】→ 识别为核心查询实体（订单表）。
第 3 步：语法树构建与中间语言生成
根据匹配结果和语法规则，构建出结构化的查询意图树，并将其转换为精确的中间查询语言（MQL）：
SELECT 订单编码, 客户, 金额, ...
FROM 订单实体
WHERE (发货日期#Year=year(ADDYEARS(now(),-1))) AND (发货城市=30101) AND (客户城市=20201)
第 4 步：编译与执行
MQL 会被进一步编译为针对底层数据引擎的可执行指令。对于相对简单的查询，直接生成 DQL（消除表间关联）后转换成 SQL 查询数据；对于涉及复杂计算（如“连涨天数”）的查询，则会在取数后调度专门SPL引擎再处理。
上面这个例子最后执行的 SQL：
SELECT
YEAR(T_1_1.SHIPDATE) AS "发货日期_Year",
T_1_1.SHIPCITY AS "发货城市",
T_1_2.CITYCODE AS "客户城市",
T_1_1.ORDERID AS "订单编码",
T_1_1.SIGNDATE AS "签单日期",
T_1_1.SHIPDATE AS "发货日期",
T_1_1.RECEIVEDATE AS "收货日期",
T_1_1.AMOUNT AS "订单金额"
FROM ORDERS T_1_1
LEFT JOIN CUSTOMER T_1_2 ON T_1_1.CUSTOMERID = T_1_2.CUSTID
WHERE
(YEAR(T_1_1.SHIPDATE) = YEAR(DATEADD('yy', -1, NOW())))
AND (T_1_1.SHIPCITY = 30101)
AND (T_1_2.CITYCODE = 20201)
看看 SQL 中这些表的别名，明显不是人写的。这里已经有了令很多单纯基于大模型的 Text2SQL 方案生畏的 JOIN，不过这还算是最简单的。
整个过程，没有猜测，只有映射；没有幻觉，只有逻辑。其可靠性的根源，在于将自然语言中不确定的部分，通过“业务词典”的映射，转化为机器世界中完全确定的数据操作。
查询能力实测：究竟能应对多复杂的场景？
脱离 LLM 的规则引擎，能力天花板在哪里？让我们通过一组查询实例，不同类型和复杂度来具体展示。润乾 NLQ 的解析能力足以覆盖绝大多数数据分析需求。
明细查询：想要什么数据，直接列出来
从最基础的字段查看到智能的跨表组合，NLQ 都能精准应对。
简单列举：
“列出雇员姓名”
“商品编码、名称、重量、类别、库存量”
像点菜一样说出字段名，数据即刻呈现。
附带计算：
“雇员姓名、身高、体重、BMI 指数”
即使像“BMI 指数”这样的计算字段，只要预先定义好公式（如：体重 / 身高²），查询时就能自动算出。
智能消歧与组合：
“订单编码，发货 城市 日期，收货 城市 日期”
系统通过“发货”、“收货”等簇词，自动区分并返回“发货城市”、“发货日期”、“收货城市”、“收货日期”四列数据，无需人工指定复杂表头，完美消除歧义。
跨表关联（多表关联示例）：
查询语句：“订单编码，订单日期，产品名称，供应商名称和城市”
查询意图：用户想看到订单号、对应的产品名、该产品的供应商名及供应商所在城市。这需要自动关联订单、订单明细、产品、供应商至少四张表。
NLQ 生成的 MQL（清晰简洁）：
SELECT 订单 AS 订单编码,订单.发货日期 as 订单日期,产品.产品名称 AS 产品名称,厂家.供应商名称 AS 供应商名称,厂家.供应商城市编码 AS 供应商城市
FROM orderdetail
编译后执行的 SQL：
SELECT T_1_1.ORDERID "订单编码",T_1_2.SHIPDATE "订单日期",T_1_3.PRODUCTNAME "产品名称",T_1_4.NAME "供应商名称",T_1_4.CITY "供应商城市"
FROM ORDERDETAIL T_1_1
LEFT JOIN ORDERS T_1_2 ON T_1_1.ORDERID=T_1_2.ORDERID
LEFT JOIN PRODUCT T_1_3 ON T_1_1.PRODUCTID=T_1_3.PRODUCTID
LEFT JOIN SUPPLIER T_1_4 ON T_1_3.SUPPLIERID=T_1_4.SUPPLIERID
这句 SQL 有了三个 LEFT JOIN，需要清晰理解四张表关联关系才能写出的这样的语句。
复杂过滤：条件再刁钻，也能精确定位
NLQ 能够理解并处理各类业务场景下的复杂筛选逻辑。
多条件与逻辑组合：
“年龄 45 到 50 岁之间，且籍贯是北京的雇员”
“单价大于 100 或小于 10 的订单明细”
完美支持“且”、“或”、“在…之间”等逻辑，进行精确筛选。
业务术语过滤（宏词）：
“已售罄的商品信息”
只需将“已售罄”定义为宏词（对应逻辑：库存量 <= 0），即可用最直观的业务语言直接查询。
动词关联过滤：
“北京发往青岛的订单”
通过“发往”这个动词，系统能自动将“北京”绑定到发货城市，“青岛”绑定到收货城市，构建出发货城市 =‘北京’ AND 收货城市 =‘青岛’的关联条件。
时间智能处理：
“去年第 3 季度的订单”
“上周一的会话记录”
系统能理解“去年”、“上周”、“第 N 季度”等丰富的相对时间描述，并自动转换为数据库可执行的准确日期范围。
聚合分析：不只查看，更要洞察
从基础汇总到嵌套的聚合后过滤，NLQ 让数据分析师的工作更高效。
基础汇总：
“各城市发货的总金额”
“每月订单数”
轻松完成按维度分组和求和、计数等聚合计算。
聚合后筛选：
“总订单数超过 20 的客户”
“平均售价超过 500 元的海鲜商品”
先按业务逻辑完成聚合计算（如：每个客户的订单总数），再对聚合结果进行筛选（HAVING 子句逻辑），直达关键群体。
嵌套聚合（子表聚合条件查询示例）：
查询语句：“订单金额总和大于 20 万元的女员工”
查询意图：先按员工汇总其所有订单的总金额，再筛选出总金额 >20 万且性别为女的员工。这涉及对子表（订单）的聚合，并用聚合结果过滤主表（员工）。
NLQ 生成的 MQL（逻辑分明）：
SELECT 性别 AS 性别,雇员编码,姓名,职务,出生日期,年龄,ORDERS.sum(订单金额) AS 订单金额总和
FROM EMPLOYEE
WHERE (性别='女')
JOIN ORDERS
HAVING (ORDERS.sum(订单金额)>20*10000)
编译后执行的 SQL（展现多层逻辑）：
SELECT e.Name AS 员工姓名，e.Gender AS 性别, SUM(o.Amount) AS 订单金额
FROM Employees e
INNER JOIN Orders o ON e.EmployeeID = o.SalesPersonID
WHERE e.Gender = ‘女’
GROUP BY e.EmployeeID， e.Name， e.Gender
HAVING SUM(o.Amount) > 200000
将需要深刻理解 SQL 中 WHERE、GROUP BY、HAVING 子句区别及执行顺序的复杂查询，简化为一句平实的业务描述。
混合关联与复杂指标：应对综合业务场景
面对跨主题域整合和高级计算需求，NLQ 借助分层架构同样能够胜任。
多数据表汇总对齐：
查询语句："各省的员工数、产品数和订单数"
查询意图：需要分别从员工表、产品表、订单表中计数，再按 "省份" 维度对齐结果。
技术核心：这类查询的难点在于多表关联时的维度对齐。传统 Text2SQL 方案在此极易出错，生成错误的 JOIN 逻辑。润乾 NLQ 能自动识别“省”是三个表的公共分析维度，理解用户意图是进行“同维汇总与对齐”，而非简单的表连接。
NLQ 生成的 MQL（体现维度对齐逻辑）：
SELECT EMPLOYEE.count(1) AS 员工数, PRODUCT.count(1) AS 产品数, ORDERS.count(1) AS 订单数
ON Province AS 省
FROM EMPLOYEE
BY 籍贯省
JOIN PRODUCT
BY 供应商省
JOIN ORDERS
BY 发货省
编译后执行的 SQL：
SELECT
COALESCE(T_1.F_1, T_2.F_1, T_3.F_1) AS "省",
T_1.F_2 AS "员工数",
T_2.F_2 AS "产品数",
T_3.F_2 AS "订单数"
FROM (
SELECT
T_1_2.PROVINCE AS F_1,
COUNT(1) AS F_2
FROM EMPLOYEE T_1_1
LEFT JOIN CITY T_1_2 ON T_1_1.HOMECITY = T_1_2.CITYCODE
GROUP BY T_1_2.PROVINCE
) T_1
FULL JOIN (
SELECT
T_2_3.PROVINCE AS F_1,
COUNT(1) AS F_2
FROM PRODUCT T_2_1
LEFT JOIN SUPPLIER T_2_2 ON T_2_1.SUPPLIERID = T_2_2.SUPPLIERID
LEFT JOIN CITY T_2_3 ON T_2_2.CITY = T_2_3.CITYCODE
GROUP BY T_2_3.PROVINCE
) T_2 ON T_1.F_1 = T_2.F_1
FULL JOIN (
SELECT
T_3_2.PROVINCE AS F_1,
COUNT(1) AS F_2
FROM ORDERS T_3_1
LEFT JOIN CITY T_3_2 ON T_3_1.SHIPCITY = T_3_2.CITYCODE
GROUP BY T_3_2.PROVINCE
) T_3 ON COALESCE(T_1.F_1, T_2.F_1) = T_3.F_1
这句 SQL 更是嵌套了带有分组汇总的子查询，已经相当复杂，对某些 Text2SQL 方案已经是噩梦般的存在，但在 NLQ 模型下仍然可以正确无误地生成。
通过这些例子可以看到，基于规则的润乾 NLQ 引擎并非只能处理简单查询。通过精心设计的 MQL 中间语言、DQL 维度关联机制以及 SPL 计算引擎（实现 SQL 不易完成的的复杂指标计算）的协同，它能够理解复杂的业务语义，生成正确且高效的多表关联 SQL，处理嵌套的聚合条件，执行专业的数据分析计算。
其中，DQL层是解决多表关联难题的核心。它通过“外键属性化”机制，将传统 SQL 中复杂的 JOIN 关联，转换为类似“对象. 属性”的直观访问方式。例如，查询中涉及“收货城市”时，DQL 会将其表示为 customerid.citycode（即：外键字段. 目标表字段）。这使 NLQ 在 MQL 层面可以像操作单表一样编写查询，而 DQL 引擎则在底层自动、正确地转换为带 JOIN 的高效 SQL，避免了其它 Text2SQL 方案在复杂关联时常出现的逻辑混乱或错误关联问题。
坦诚对话：优势与代价，以及那个重要的 "不知为不知"
这种基于规则的技术路径带来了独特的优势，但也要求我们坦诚面对其局限性。
无可替代的优势
可解释性与可控性：每一个查询结果都可以精确追溯——是哪条词典规则、哪个字段映射、哪步计算逻辑得出的。调试、优化、审计异常简单。
企业级稳定与可靠：无随机性，相同问题永远返回相同逻辑的结果。这种确定性是企业生产系统的生命线。
极致的性能与成本：规则匹配的计算开销极低，毫秒级响应，普通服务器即可实现高并发，运营成本几乎可忽略不计。
不可否认的边界
NLQ 的准确是建立在“已知世界”（即预置的业务词典）的完备性之上，对于超出其认知范畴的查询，将无法理解或给出准确响应。比如：
无法识别未定义的业务新词：如果未在词典中配置“用户互动热度”及其计算规则，用户直接查询此指标将失败。
难以解析不规范的口语表达：面对如“我需要查询商品表中单价在 9 块五毛钱到等于 12 块钱的”或“南京的客户，或者任意直辖市的”这类包含口语化数字、非标准连词或逻辑的句子，需要先转化为规范的查询语句。
当碰到越过边界的问题时，NLQ 会表现出"不知为不知" 的可贵品质：这是与 LLM 最根本的区别之一。它会明确告诉你 "无法识别" 或 "请换种说法"。它可能查不出来，但绝不会查错。在数据准确性生死攸关的企业决策场景，这种保守和诚实比 "无论如何都给个答案" 的勇气更有价值。
必须付出的代价
前期知识注入：需要将企业的数据模型、业务指标、分析维度系统地 "翻译" 并注入到词典和规则中。这是一个需要业务与 IT 紧密协作的知识工程过程。
迭代依赖人工：当业务逻辑发生变化或需要新增分析视角时，需要手动更新词典和规则。系统本身不具备从交互中自动学习或举一反三的能力。
我们并非要否定 LLM 的宏大与神奇。通用大模型在理解开放性语言、进行创造性对话方面，是革命性的。正因清晰地认识到上述边界，润乾 NLQ 与 LLM 的协作才显得尤为恰当与务实。可以引入 LLM 作为“智能前端翻译”，将用户灵活多变、不甚规范的自然语言提问，转换为符合 NLQ 词典与语法规范的查询语句，再由 NLQ 引擎进行精准的数据查询。这种结合，既保留了用户使用自然语言的灵活性，又牢牢守住了企业级应用对查询结果准确性与复杂性的核心要求。
在企业核心的数据分析领域，我们更需要的是一个值得完全信赖的“领域专家”，而非一个才华横溢但可能出错的“通才”。润乾 NLQ 说明，深耕一个垂直领域，构建深度结构化的知识系统，我们可以在不依赖 LLM 和庞大数据算力的情况下，打造出一个能力强大、结果精准、行为可控、成本低廉的自然语言查询引擎。
它当然不能陪你吟诗作对，但当你问起“上个季度哪些区域的毛利率下滑超过了预警阈值”时，它给出的答案，你可以百分之百的信任。
这本质上是一种工程哲学的选择：用前期的确定性知识工程投入，换取生产环境中长期的确定性、高性能、低成本与全可控回报。对于业务逻辑稳定、分析需求规范、数据准确性要求极高的企业级 BI 场景，这是一笔划算的交易。
技术的价值，最终在于解决真实世界的问题。当一条路径被过度聚焦时，不妨看看另一条路上，或许已经繁花似锦。
想亲身感受一下这种“确定性智能”的体验吗？我们已经准备了一个真实的演示环境，里面预置了丰富的业务数据和查询案例。
