没有 GPU 不用 LLM 能把 Text2SQL 做到什么程度？

在这个言必称“大模型”的时代，当几乎所有智能问数方案都在比拼谁的模型参数更多、谁用的 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

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)

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 方案在复杂关联时常出现的逻辑混乱或错误关联问题。

坦诚对话：优势与代价，以及那个重要的 "不知为不知"

这种基于规则的技术路径带来了独特的优势，但也要求我们坦诚面对其局限性。

无可替代的优势

1. 可解释性与可控性：每一个查询结果都可以精确追溯——是哪条词典规则、哪个字段映射、哪步计算逻辑得出的。调试、优化、审计异常简单。
2. 企业级稳定与可靠：无随机性，相同问题永远返回相同逻辑的结果。这种确定性是企业生产系统的生命线。
3. 极致的性能与成本：规则匹配的计算开销极低，毫秒级响应，普通服务器即可实现高并发，运营成本几乎可忽略不计。

不可否认的边界

NLQ 的准确是建立在“已知世界”（即预置的业务词典）的完备性之上，对于超出其认知范畴的查询，将无法理解或给出准确响应。比如：

1. 无法识别未定义的业务新词：如果未在词典中配置“用户互动热度”及其计算规则，用户直接查询此指标将失败。
2. 难以解析不规范的口语表达：面对如“我需要查询商品表中单价在 9 块五毛钱到等于 12 块钱的”或“南京的客户，或者任意直辖市的”这类包含口语化数字、非标准连词或逻辑的句子，需要先转化为规范的查询语句。

当碰到越过边界的问题时，NLQ 会表现出"不知为不知" 的可贵品质：这是与 LLM 最根本的区别之一。它会明确告诉你 "无法识别" 或 "请换种说法"。它可能查不出来，但绝不会查错。在数据准确性生死攸关的企业决策场景，这种保守和诚实比 "无论如何都给个答案" 的勇气更有价值。

必须付出的代价

1. 前期知识注入：需要将企业的数据模型、业务指标、分析维度系统地 "翻译" 并注入到词典和规则中。这是一个需要业务与 IT 紧密协作的知识工程过程。
2. 迭代依赖人工：当业务逻辑发生变化或需要新增分析视角时，需要手动更新词典和规则。系统本身不具备从交互中自动学习或举一反三的能力。

我们并非要否定 LLM 的宏大与神奇。通用大模型在理解开放性语言、进行创造性对话方面，是革命性的。正因清晰地认识到上述边界，润乾 NLQ 与 LLM 的协作才显得尤为恰当与务实。可以引入 LLM 作为“智能前端翻译”，将用户灵活多变、不甚规范的自然语言提问，转换为符合 NLQ 词典与语法规范的查询语句，再由 NLQ 引擎进行精准的数据查询。这种结合，既保留了用户使用自然语言的灵活性，又牢牢守住了企业级应用对查询结果准确性与复杂性的核心要求。

在企业核心的数据分析领域，我们更需要的是一个值得完全信赖的“领域专家”，而非一个才华横溢但可能出错的“通才”。润乾 NLQ 说明，深耕一个垂直领域，构建深度结构化的知识系统，我们可以在不依赖 LLM 和庞大数据算力的情况下，打造出一个能力强大、结果精准、行为可控、成本低廉的自然语言查询引擎。

它当然不能陪你吟诗作对，但当你问起“上个季度哪些区域的毛利率下滑超过了预警阈值”时，它给出的答案，你可以百分之百的信任。

这本质上是一种工程哲学的选择：用前期的确定性知识工程投入，换取生产环境中长期的确定性、高性能、低成本与全可控回报。对于业务逻辑稳定、分析需求规范、数据准确性要求极高的企业级 BI 场景，这是一笔划算的交易。

技术的价值，最终在于解决真实世界的问题。当一条路径被过度聚焦时，不妨看看另一条路上，或许已经繁花似锦。

想亲身感受一下这种“确定性智能”的体验吗？我们已经准备了一个真实的演示环境，里面预置了丰富的业务数据和查询案例。欢迎go乾学院~