判定一套智能问数（Text2SQL）方案能不能用，只需要问一个问题：

查询结果出来之前，业务人员能不能确认 "这次问对了"？

能，方案就可落地。不能，榜单准确率再高、功能列表再长、演示再丝滑，都没用。

道理很简单，但 99% 的人搞反了。

为什么准确率这个指标没用

几乎所有 Text2SQL 产品都在卷准确率，Spider 上跑个 85%、90%，拿来说事。

但这是个典型的 "看起来很美" 的指标。Stack Overflow 2025 年的调查显示，只有 2.7% 的专业开发者高度信任 AI 工具。dbt 2026 年基准测试表明，最先进模型的 Text2SQL 准确率仅 64.5%。Thoughtworks 在 2025 年 11 月已将 Text to SQL 调整为 "Hold" 状态。

不过，数字不是重点，重点是逻辑有问题：

即便准确率达到 90%，业务人员怎么知道这一次有没有落在那 10% 里？

数据决策不是抽奖。一个语法正确、语义完全跑偏的 SQL，执行成功返回一个漂亮的结果，但根本不是用户想问的，这种错误，SQL 层面检查不出来，榜单准确率反映不出来，只有业务人员自己知道 "这不是我要的"。

然而业务人员看不懂 SQL。输出 SQL 或者任何只能让机器读的中间格式，等于告诉用户：你只能信我，没法验证。

无法验证的结果，再高的准确率也没有决策价值。

所以，准确率这个指标从一开始就问错了方向。

正确的判定标准：人机双向可读的中间层

问题的本质不是 "能不能做对"，而是 "做错了能不能被发现"。

破局方法只有一个：在查询执行之前，加一层业务人员能读懂的中间表示，让用户自己确认意图。

这层中间表示必须同时满足两个条件：

一、人类可读。用接近自然语言的形式、不用技术培训就能看懂。比如 "2023 年北京发往青岛的订单金额汇总" 这种，而不是 JSON、XML、自定义 DSL 或者 SQL。

二、机器可解析。遵循固定结构，能确定性转换成 SQL，100% 准确，不依赖模型猜测。

就这么简单。验证方法也不复杂：

随机拿几个真实业务问题，让业务人员看中间结果。能一眼确认 "对，这就是我要问的"，方案就过了底线。看不懂，别的指标再漂亮也没用。

为什么大多数方案做不到

"不就是在中间加一层人话吗？很难吗？"

难在设计理念上。大多数方案的中间层是机器导向的——设计目标是用结构化的中间语法约束 LLM 的输出空间，减少幻觉。JSON 也好、自定义 MQL 也罢，格式是固定了，但代价是人看不懂。业务人员看不懂，校验环节就永远缺失。

而且这条路会恶性循环：中间层设计得越复杂，LLM 越容易语法出错；为了保准确率，不得不把中间层做得很简单，简单到只支持单表查询，多表关联、子查询、复杂指标一概不支持，企业级场景根本用不上。

润乾 NLQ：把 "人确认" 打进方案中

润乾 NLQ 采用了人类可读的路线：LLM 不做复杂推理，只做语义转写，把五花八门的口语整理成标准化的规范文本。后续查询逻辑的准确性，交给规则引擎和人类确认。LLM 不需要懂 SQL、不需要记表结构、不需要做任何决策，只做它最擅长的自然语言理解。

核心思想就一句话：LLM 做翻译，规则做决策，人做确认。

整个流程分三步：自然语言 → LLM 翻译成规范文本（人机双向可读的 DSL）→ 业务人员确认 → 规则引擎确定性转换成 SQL。LLM 不碰 SQL，转换链路完全确定，实施不需要模型微调和 AI 团队，普通开发人员构建词典即可完成部署。

第一步：LLM 把口语翻译成规范文本

LLM 只做一件事：把五花八门的口语表达，整理成标准化的“规范文本”：一种人机双向可读的 DSL。

来看几个例子：

例 1：去掉口语废话

• 口语输入：嗯…我想看看去年签的订单。

• 规范文本：去年 订单

“嗯…我想看看”这类口语废话被去掉，只保留核心查询意图。

例 2：口语化条件转标准表达

• 口语输入：零售价低于 50 元的零件。

• 规范文本：零售价 小于 50 元 零件

“低于”被标准化为“小于”，更利于机器解析。

例 3：模糊时间转明确条件

• 口语输入：去年秋天签了多少订单

• 规范文本：签单日期 2025 年 9 月 至 2025 年 11 月 订单 数

“去年秋天”被识别为明确的时间范围。

例 4：复杂业务术语转标准条件

• 口语输入：已售罄的商品。

• 规范文本：库存量是 0 的商品

“已售罄”这种业务黑话，被翻译成明确的字段条件“库存量是 0”。

这些规范文本的共同特点：一看就懂，不用翻译。业务人员不需要任何技术背景，扫一眼就知道“对，这就是我想问的”；或者“不对，这理解偏了”。

第二步：人类做确认

LLM 有幻觉，不一定每次都翻译对。所以必须加一道人类确认的关卡。

比如用户想问“去年没开单的女员工”，LLM 可能翻译成：

• 【2025 年 签单，女，员工】—— 漏掉了“没开单”这个关键条件

• 或者【2025 年 签单，金额 是 0，女，员工】—— 把“没开单”理解成“订单金额为零”

这两种翻译语法没问题，但语义却跑偏了。如果不确认直接执行，返回的结果就是错的。

但有了“规范文本”这个中间层，问题在执行前就被拦截了。业务人员看到规范文本，一眼就能发现“这不对”，然后返回修改提问，重新走第一步。

人能确认的，才是能用的。

第三步：规则引擎转 SQL 查数据

用户确认规范文本无误后，进入确定性转换阶段。

规范文本→ SQL，每一步都基于确定的规则和词典，100% 可追溯、可调试。没有 LLM 的“发挥空间”，没有“大概率正确”，只有确定性的转换和确定性的结果。

这个阶段不需要人类参与，也不需要 AI 做任何决策，规则引擎全自动完成。

润乾 NLQ 把 Text2SQL 从“AI 猜你问什么”变成了“你确认 AI 理解对了再执行”。LLM 做它最擅长的翻译，人做他最擅长的是非判断，规则引擎做它最擅长的确定性转换。各司其职，各取所长。

判定 Text2SQL 能不能用，别看榜单、别看功能列表、别看 Demo。就看一个：

业务人员能不能在查询执行前，自己确认 "问对了"。

能确认，就能用。不能确认，就是玩具。