智能问数SQL实战：超越黑盒的工业级解决方案解析
在Text2SQL领域，一个值得玩味的现象是：尽管相关讨论和宣传铺天盖地，厂商们热衷于展示高达90%以上的准确率，但一个可供公开、自由测试的DEMO却难觅踪影。
从技术实现角度看，构建一个演示前端的成本并不高昂。真正的原因在于，当前主流的Text2SQL技术本质上是“黑盒”方案。这类方案最致命的弱点，恰恰在于无法承受开放环境下的随机测试——AI模型随时可能产生一个完全错误的输出，导致演示彻底失败。
这并非单一厂商的技术短板，而是所有依赖纯AI黑盒方案所面临的共同结构性难题。
黑盒方案的困境：不稳定的“90%”，企业承受不起
目前主流的Text2SQL实现，无论架构如何包装，其核心都可归结为两类黑盒模式。
最直接的方式是端到端生成：用户输入自然语言，大模型直接输出SQL。这种方式可控性最差，模型幻觉、语法错误、表连接关系错乱等问题层出不穷。
更复杂的方案引入了中间层：让AI先生成一个结构化的中间表示（如JSON或自定义DSL），再通过程序将其编译为SQL。相比直接生成，中间层降低了复杂度，准确率有所提升，过程中还可能引入RAG等检索增强技术。
然而，无论提示工程如何优化，知识库如何完善，最关键的语义转换步骤——从自然语言到结构化表示——依然由概率模型完成。只要模型幻觉存在，这个环节就无法实现100%的可靠性。现有技术只能降低错误发生的概率，无法从根本上消除不确定性。
学术基准测试的数据已经揭示了严峻的现实。在更贴近企业复杂数据环境的Spider 2.0测试中，GPT-4o的准确率从Spider 1.0的86%骤降至6%；o1-preview模型更是从91.2%暴跌至21.3%。这种断崖式下跌，清晰暴露了学术评测与企业真实需求之间的巨大鸿沟。
更根本的挑战在于，评测基准本身也可能不可靠。近期研究发现，BIRD Mini-Dev数据集的注释错误率高达52.8%，Spider 2.0-Snow的错误率也达到62.8%。当基准数据本身存在过半错误时，基于其得出的“准确率”指标便失去了参考价值。
问题的严重性远超数字层面。即便一个系统在90%的情况下工作正常，那10%的失败也足以摧毁企业信任。当业务决策依赖于查询结果时，“本次结果可能存在错误”的不确定性是完全不可接受的。
根源在于执行链条的“黑盒”特性。用户输入问题，得到答案，中间的推理过程完全不可见。模型匹配了哪些表字段？它基于什么逻辑构建JOIN关系？它对过滤条件的理解是否与用户意图一致？这一切都无法追溯和审计。当结果可疑时，技术人员尚可人工核对生成的SQL（尽管效率低下），但Text2SQL的目标用户往往是看不懂SQL的业务人员。中间层方案只是将SQL替换为JSON或DSL，业务人员同样无法理解。连问题出在哪里都无法定位，更谈不上指导系统改进。
因此，黑盒方案的困境是结构性的：关键决策依赖概率模型，输出结果不确定、不可审计、不可解释。而企业级应用所要求的稳定性、可重现性与可解释性，恰恰是黑盒方案无法提供的。
白盒方案的根本区别：约束AI的不确定性，保留人类确认节点
解决黑盒问题，不能寄望于AI自身变得完美，而应在系统设计层面承认其局限性，并将其约束在可控范围内。
白盒方案遵循两条核心原则：
- 必须存在一个人类可读、可确认的中间层。AI仅负责将自然语言翻译为此中间层，之后必须经过人工（或领域专家）确认，方可进入下一步。
- 从中间层到SQL的转换，必须使用确定性规则进行编译，严禁再次引入AI。以此保证后续环节100%准确。
这可以概括为“以结构化的自然语言对抗模糊的自然语言”——用一个人类能理解的中介语言，将AI的不确定性阻挡在确认环节之前。一旦确认通过，后续便是纯规则的、确定性的编译过程，杜绝幻觉与猜测。
润乾NLQ采用的就是这种白盒路径。其中间层称为“规范文本”，是一种介于口语与SQL之间的结构化表达。例如：
- 用户口语：查一下去年从北京发往青岛的订单情况
- 规范文本：去年 北京 发往 青岛 订单
规范文本支持动词表达，上例的完整语义是“去年 发货 城市 北京 收货 城市 青岛 订单”。人类可以直观理解其意图。用户确认后，系统通过规则引擎将规范文本确定性地编译为MQL，最终转换为SQL执行。从规范文本到SQL的整个后半段，准确率是100%的，不存在随机错误。
正是基于这种确定性保障，润乾NLQ才敢于提供公开DEMO。它可能因无法理解某些问法而拒绝查询，但只要用户确认了规范文本，返回的结果就一定是正确的。即便程序偶有BUG导致出错，也可追踪调试并修复，错误会持续减少。
例如，在DEMO中直接查询：
- 商品名称 ‘龙虾’ 且 库存量小于50 商品 编码 名称 单价
该规范文本清晰地表达了包含多个过滤条件的明细查询。
再查询：
- 2025年 金额最大10 订单
这类单表聚合（TopN）查询，用规范文本也能轻松表达。
以及涉及多表关联、聚合后过滤的复杂查询：
- 去年 北京发货 订单数 大于1 客户信息
当然，一些过于口语化的非规范表达可能无法直接查询，例如：
- 我需要查询商品表中单价在9块五毛钱到等于12块钱的
此时，用户需要将其改写为规范文本，或利用DEMO提供的“LLM规范”功能，借助大模型完成口语到规范文本的翻译。
DEMO还提供“深度规范”选项，若初次转换结果不理想（LLM仍可能产生幻觉），可尝试进行更精准的转换。
白盒方案的挑战：通过率
那么，纯AI方案是否也能引入类似的“人类确认”机制？理论上，如果AI生成的中间层或SQL足够简单，简单到业务人员能读懂，那确实可以确认。但这会引发一个矛盾：中间层设计得太简单，其表达能力会严重受限，导致通过率很低；如果设计得复杂，业务人员又无法理解和确认。
或许有人设想：让AI先将中间层“翻译”成一段自然语言描述给用户确认，确认后再执行。但这并非真正的白盒方案，因为用于确认的自然语言描述仍是AI生成的，可能与中间层的实际逻辑不一致。用户确认的只是AI的描述，而非将要执行的逻辑本身，幻觉问题只是被转移，并未消除。
白盒方案的核心在于：用于确认的文本本身，必须是由规则引擎生成的，或其本身就是人类可读的确定性表达。并且，确认之后的执行路径必须是完全确定性的。润乾NLQ直接使用规范文本作为中间层，它既是规则引擎的确定性输入，又是人类可直接确认的自然语言，一举两得。
目前，规范文本的设计已足够丰富，支持四种主要查询范式（单表明细、单表聚合、主子实体、多维对齐汇总），配合词典中的字段词、实体、宏词、动词、指标等配置，能够覆盖BI场景下绝大部分查询需求。这不是一个简单的构想，而是一个经过实践检验、在保持人机可读性的同时具备充分表达能力的中间语言。
可以通过以下示例感受规范文本的能力范围：
一、单表明细
1. 零售价 包装方式 零件
2. 所在国家 中国 客户 名称 账户余额
3. 去年 订单
4. 零售价 小于 50元 零件
5. 订单状态 未完成 订单
6. 市场细分 汽车 客户
7. 区域 欧洲 供应商
8. 零件编号 名称 品牌 零件
9. 今年 3月 订单
10. 发货日期 等于 上周一 订单明细
11. 实际到货日期 大于 承诺到货日期 订单明细
12. 账户余额 大于 10000元 客户
13. 品牌 "Brand#" 开头 零件
14. 零售价 100元 到 200元 零件
15. 名称 联系电话 供应商
二、单表聚合
16. 平均 零售价
17. 上个月 客户 订单总金额 总和
18. 订单总金额 最大的5个 订单
19. 品牌 零件 数
20. 国家 客户 数
21. 所在国家 中国 客户 账户余额 总和
22. 最小 订单总金额 最大 订单总金额 平均 订单总金额
23. 订单日期 最早
24. 零件类型 零售价 最大
三、主子实体
25. 客户 订单 数
26. 没有 订单 客户
27. 客户 零件 大型抛光钢
28. 去年 有 订单 客户
29. 供应商 零件 数
30. 订单总金额 总和 大于 100000 客户
31. 上个月 没有 订单 客户
32. 零件 客户 数
33. 有 已退货明细 订单
34. 订单状态 未完成 客户 订单 数
四、多维对齐汇总
35. 国家 客户 数，供应商 数
36. 订单优先级 (已完成 订单 数) (未完成 订单 数)
37. 品牌 零件 数，供应商 数
38. 行业 (客户 数) (订单总金额 总和)
39. 年 区域 订单总金额 总和
深入讨论通过率，需区分两种场景：
若不接入LLM：用户必须自行书写规范文本。尽管规范文本覆盖的查询能力很强（单表明细、单表聚合、主子实体、多维对齐汇总，几乎涵盖BI核心操作），但业务用户需要学习这套规则。对于纯口语化输入，如“上个月没签单的客户有哪些”，不接LLM的系统会直接返回“无法识别”，口语通过率会很低。
若接入LLM：润乾NLQ允许接入任意大模型，先将口语问题转换为规范文本，再走规则引擎。实测配合一个表现良好的LLM（如DeepSeek），绝大部分日常问法都能顺利通过，口语通过率可大幅提升。
无论是否接入LLM，润乾NLQ都保留了最终的确定性兜底。LLM在此仅扮演翻译工具的角色（或由人工直接书写），负责将口语转为规范文本。一旦规范文本被确认并交由规则引擎，后续便是确定性执行。大模型是翻译官，而非决策者。
即便如此，仍会有一些查询是当前规范文本无法描述的。例如“按订单金额从高到低排序”。NLQ的解决方案是在查询结果界面，点击列标题即可实现排序，支持多字段、升降序。排序本身不是能力问题，用自然语言描述复杂排序逻辑反而笨拙：“先按金额降序，金额相同的再按订单日期升序”，写出来比用鼠标点几下更繁琐。对于这类操作，界面交互往往比自然语言更高效。
类似的还有跨行组计算（如环比、同比、累计、占比、排名等）。这类复杂运算可能涉及不同层次的范围，用SQL生成时还需用到繁琐且兼容性不佳的窗口函数。硬要在NLQ中用自然语言处理，不仅用户描述不便，生成难度也极高。对于这种情况，润乾的解决方案不是硬撑，而是承认边界，并用NLR（自然语言报表）来补足。
例如，要计算每月销售额增长率，可先用NLQ查出结果集，然后在NLR中通过汉语命令计算增长率：
输入两条汉语命令即可完成：
- 计算 订单金额求和 比例环比 命名为 增长率
- 位置 增长率 显示为 百分数格式
NLQ负责将数据查出，NLR负责在结果集上继续用汉语进行加工：计算环比、排名、设置格式、生成图表。再结合界面排序等辅助功能，便形成了一个从查询到分析再到展示的完整闭环。
只有采用这种白盒机制，引入人类确认环节，Text2SQL才能真正实现工业级落地。它不是靠宣称100%准确，而是依靠设计上的确定性来保证准确，依靠规范文本的丰富表达能力来保证通过率。
润乾NLQ的AI不一定比别人的更聪明，其关键在于不将命运完全交给AI。白盒方案的本质，是用确定性规则兜底，将AI的不确定性限制在人类可确认的范围内。这条路看起来不如黑盒方案“炫酷”和“智能”，但在追求稳定可靠的企业级应用落地上，这或许是唯一可行的路径。