卷到 90% 也没用，因为你不知道这一次是不是落到那剩下 10% 了
准确率这个指标，
从一开始就问错了方向
几乎所有 Text2SQL 产品都在卷准确率，隔三差五就有人宣布又提升了多少个百分点，从 70% 涨到 90% 甚至 95%，看起来一片繁荣。
但这只是一个“看起来很美”的指标。数字不是重点，逻辑才是：即便准确率达到 90%，用户怎么知道这一次有没有落在那 10% 里？
数据决策不是抽奖。一个语法正确、语义完全跑偏的 SQL，执行成功返回一个漂亮的结果，但根本不是用户想问的。这种错误，SQL 层面检查不出来，只有用到现实业务中才会发现错得离谱。
这是因为智能问数的用户是业务人员，不是 DBA。他们不懂 SQL，也看不懂 JSON、XML 或任何技术化的中间格式。不管后台技术多复杂，用户面对的就是一个黑箱，他只能输入问题，然后得到一个结果，中间过程完全不可见，也就无从验证对错。
无法验证的结果，再高的准确率也没有决策价值。
准确率不是“够不够高”的问题，
是“能不能确认”的问题
一个错配的逻辑：准确率从 80% 提到 90%，系统就更可用了。
实际上，从“不可用”到“可用”，跨越的不是 10 个百分点，而是一个质的变化：从“黑箱”变成“透明”。
80% 准确率的黑箱和 90% 准确率的黑箱，对用户来说没有本质区别。反正都看不懂中间过程，都不知道这一次对不对，只能赌这次运气好，落在了正确的那一边。
反过来，如果用户能在执行前发现并剔除错误，那 80% 的准确率就已经足够好用了，剩下的 20% 错误能被识别和拦截，用户只要说一声“这不对”，系统就重新来。准确率从 80% 到 90% 的意义，远不如“用户能不能发现那 10% 的错误”来得重要。
在严肃的经营决策场景里，没人敢于去赌。
这就是为什么 90% 的准确率也没用。不是 90% 不够高，是“不可确认”本身就不可接受。
正确的方向：
不是卷准确率，而是“可确认性”
问题的本质不是“能不能做对”，而是“做错了能不能被发现”。
破局方法：在查询执行之前，加一层用户能读懂的中间表示，让用户自己确认意图。
这层中间表示必须同时满足两个条件：
一、人类可读。用接近自然语言的形式，不用技术培训就能看懂。比如“2023 年北京发往青岛的订单金额汇总”，而不是 JSON、XML、自定义 DSL 或者 SQL。
二、机器可解析。有明确可用规则描述的结构，能确定性转换成 SQL，不依赖模型猜测。
就这么简单。验证方法也不复杂：随机拿几个真实业务问题，让用户看中间结果。能一眼确认“对，这就是我要问的”，方案就过了底线。看不懂，别的指标再漂亮也没用。
为什么大多数方案在卷准确率，而不是解决可确认性
不是不想，是做不到。
SQL 以及这些方案的中间层是机器导向的，用结构化的中间语法约束 LLM 的输出空间，减少幻觉。JSON 也好、自定义 MQL 也罢，有了约束，准确率确实提高了，但和 SQL 一样仍然是人看不懂。看不懂，校验环节就永远缺失。
中间层还有更糟的是恶性循环：设计得越复杂，LLM 越容易语法出错；为了保准确率，不得不把中间层做得很简单，有些甚至简单到只支持单表查询，把多表关联、子查询、复杂指标全部丢弃。企业级场景根本不够用。
业界在卷准确率，是因为大多数厂家只会卷准确率。中间层做不到人读，就谈不上“可确认性”。
润乾 NLQ：
不卷准确率，解决“人能确认”
润乾 NLQ 走的是另一条路：LLM 做翻译，规则做决策，人做确认。
LLM 不做复杂推理，只做语义转写，把五花八门的口语整理成标准化的规范文本。后续查询逻辑的准确性，交给规则引擎和人类确认。LLM 不需要生成 SQL 或中间层，只做它最擅长的自然语言理解。
整个流程分三步：自然语言 → LLM 翻译成规范文本（人机双向可读的 DSL）→ 用户确认 → 规则引擎确定性转换成 SQL。
第一步：LLM 把口语翻译成规范文本
LLM 只做一件事：把五花八门的口语表达，整理成标准化的“规范文本”（一种人机双向可读的 DSL）。
来看几个例子：
例 1：去掉口语废话
口语输入：嗯…我想看看去年签的订单。
规范文本：去年 订单
“嗯…我想看看”这类口语废话被去掉，只保留核心查询意图。
例 2：口语化条件转标准表达
口语输入：零售价低于 50 元的零件。
规范文本：零售价 小于 50 元 零件
“低于”被标准化为“小于”，更利于机器解析。
例 3：模糊时间转明确条件
口语输入：去年秋天签了多少订单
规范文本：签单日期 2025 年 9 月至 2025 年 11 月 订单数
“去年秋天”被识别为明确的时间范围。
例 4：复杂业务术语转标准条件
口语输入：已售罄的商品。
规范文本：库存量是 0 的商品
“已售罄”这种业务黑话，被翻译成明确的字段条件“库存量是 0”。
例 5：多条件组合查询
口语输入：帮我看看上个月华北区单价超过 100 块的订单有多少
规范文本：签单日期 上月 区域 华北 单价 大于 100 订单数
口语中的“帮我看看”“有多少”被过滤，“上个月”被识别为相对时间，“华北区”被映射到区域维度，“超过 100 块”被标准化为“大于 100”。
例 6：否定条件
口语输入：去年没开单的女员工
规范文本：签单日期 去年，没有 订单，女 员工
“没开单”被识别为否定条件，存在性判断，而不是“订单金额为零”。这是 LLM 语义理解能力的体现：它知道“没开单”不等于“订单金额 =0”，而是“不存在任何订单记录”。
这些规范文本的共同特点：一看就懂，不用翻译。用户不需要任何技术背景，扫一眼就知道“对，这就是我想问的”；或者“不对，这理解偏了”。
第二步：人类做确认
LLM 有幻觉，不一定每次都翻译对。所以必须加一道人类确认的关卡。
比如用户想问“北京客户下的订单”，LLM 可能翻译成：
发货城市 北京 订单—— 把“客户在北京”理解成了“发货在北京”
用户想查的是客户所在地为北京的订单，而 LLM 理解成了发货地为北京，翻译出来的文本语法通顺、结构完整，但意思完全错了。
如果不确认直接执行，返回的就是“发货城市 = 北京”的订单数据，跟用户想查的“北京客户下的订单”是两回事。拿到结果可能还意识不到错了——因为结果本身是合法的、有数据的，只是不是他想要的。
有了“规范文本”这个中间层，问题在执行前就被拦截了。用户看到“发货城市 北京”，一眼就能发现“不对，我要的是客户在北京”，然后返回修改提问，重新走第一步。
人类能确认的，才是能用的。这正是本文反复强调的核心观点。
第三步：规则引擎转 SQL 查数据
用户确认规范文本无误后，进入确定性转换阶段。
规范文本 → SQL，每一步都基于确定的规则和词典，100% 可追溯、可调试。没有 LLM 的“发挥空间”，没有“大概率正确”，只有确定性的转换和确定性的结果。
这一步不能再指望 AI，否则幻觉只是换了个位置。必须用规则引擎做确定性的编译转换，才能保证“确认无误”之后的执行环节不出差错。
润乾 NLQ 把 Text2SQL 从“AI 猜你问什么”变成了“你确认 AI 理解对了再执行”。LLM 做它最擅长的翻译，人做他最擅长的是非判断，规则引擎做它最擅长的确定性转换。各司其职，各取所长。
润乾 NLQ 不去比谁的准确率高，它比用户到底敢不敢信。
卷准确率是个无底洞。从 80% 卷到 85%，再卷到 90%，投入的成本指数级上升，但用户的信任度并没有同步提升，因为他还是看不懂、确认不了。
与其卷一个用户无法验证的指标，不如认真解决“用户能不能看懂、能不能确认”。
能确认，就能用。不能确认，90% 也没用。
