Text2SQL 想落地，要在承认 AI 有幻觉的前提下设计方案
现在聊 Text2SQL，大家总在聊 “准确率又提升了多少”“模型又升级了几代”，仿佛只要模型足够强、知识喂得足够多，幻觉终会被彻底消灭，落地就是水到渠成的事。
但真实的落地现状恰恰相反：Demo 里百发百中，上线后错漏百出；实验室准确率 95%，真实业务场景直接打对折。根源其实很简单：很多方案从设计之初，就不肯直面 “AI 幻觉不可根除” 这个基本事实，总想着靠技术手段 “消弭” 幻觉，而不是在架构层面 “容纳” 幻觉。
Text2SQL 要真正落地，第一步不是选大模型、搭 RAG，而是先承认：幻觉永远会存在。所有的方案设计，都要在这个前提下展开。
幻觉，是 LLM 与生俱来的 “出厂设定”
很多人把幻觉当成技术缺陷，觉得只要持续优化就能彻底解决。但本质上，幻觉是大模型概率生成机制的必然产物，只要模型是基于统计概率预测下一个 token，就不可能做到 100% 的语义准确。
放到企业 Text2SQL 场景里，这个问题会被进一步放大：企业有专属的业务术语、自定义的指标口径、复杂的表间关联关系，还有大量个性化查询。无论是微调还是 RAG，都只能覆盖高频场景，永远会有模型没见过、没学好的边界情况，幻觉也就永远有生存空间。
更现实的问题是，消除幻觉的边际成本是指数级上升的。从 70% 准确率做到 90%，投入产出比很高；从 90% 做到 95%，成本会翻倍；从 99% 往 100% 逼近，投入会呈指数级增长，但效果微乎其微。对企业而言，为了最后几个百分点的准确率，投入数倍的人力、算力和数据成本，本身就是一笔不划算的账。
换言之，“零幻觉”是永远到不了的终点。不肯接受这个前提，所有的方案设计从根上就走错了方向。
两种设计路线：假装没幻觉 vs 承认有幻觉
对 AI 幻觉的态度，决定了两种完全不同的设计路线。
路线一：假装没有幻觉，追求“全自动”。
这条路线的逻辑是：把模型做大、把数据喂足、把 prompt 调优，尽可能逼近 100% 准确，最终实现“用户输入问题→AI 直接出结果，全程无人介入”。
听起来很美好，但问题是：你永远无法达到 100%。哪怕只有 1% 的错误，在经营决策场景里也是不可接受的。业务人员不知道这一次对不对，他只能赌。
而且这条路线的代价极高：经常需要 GPU 集群，维护需要 AI 专家团队，修一个问题可能要重新标注数据、重新训练模型。投入巨大，但用户依然不敢信。
路线二：承认有幻觉，内置容错机制。
这条路线的逻辑是：既然 AI 一定会犯错，那就让错误在执行前能被发现和拦截。不追求 AI 永不犯错，追求“AI 犯错时人能发现”。
这要做到两件事：第一，把幻觉限制在最小的环节里，不让它传导到核心业务逻辑；第二，幻觉必须暴露在用户眼前，让人能一眼发现、随手修正。基于这个原则，一套可落地的 Text2SQL 方案，至少要满足四个设计准则：
收缩 AI 职责边界：只让 AI 做它擅长的“语义理解与转译”，不让它负责业务逻辑与查询生成。AI 承担的职责越多，幻觉扩散的范围就越大。
设置人类可读的校验点：必须在 AI 输出之后、正式查询之前，设置一道确认关卡，且校验内容必须是业务人员能秒懂的自然语言，而非技术格式。
核心链路确定性：从确认后的内容到最终 SQL，必须走确定性规则引擎，全程可追溯、可调试，不再引入新的不确定性。
错误可定位可修复：出了问题能精准定位到具体环节，补充配置即可修复，不需要反复调模型、喂数据，陷入“打地鼠”式的维护循环。
润乾 NLQ 的工程实践：基于 “幻觉共存” 的架构设计
润乾 NLQ 从架构设计之初，就默认了 “LLM 一定会产生幻觉” 这个基本前提。它没有把准确率的赌注全压在模型能力上，而是设计了一套 “AI 做前端、规则做后端、人做兜底” 的分层架构，把幻觉严格限制在最前端的语义转换环节，实现了 “幻觉可见、可控、可修正”。
1. 把幻觉锁在 “规范文本” 层，让人一眼能看见
在润乾 NLQ 的架构里，LLM 只负责一件事：把用户五花八门的口语化提问，转写成标准化的规范文本。
比如用户随口说 “帮我查查上个月北京发往青岛的订单都有啥”，LLM 的输出不是 SQL，也不是结构化代码，而是一句人人能懂的业务描述：
签单日期 上个月，北京 发往 青岛，订单
幻觉只会出现在这一步文本转写里，而且因为输出的是纯自然语言，没有任何技术门槛，业务人员扫一眼就能发现偏差，是城市搞反了、时间错了，还是指标没理解对，一目了然。
发现不对，用户改个说法重新提问就行，错误在执行之前就被拦截了，根本不会流到后续查询环节。这比 “生成错误 SQL→跑出错误结果→事后人工排查” 的成本低了几个数量级。
2. 核心查询全链路规则化，不给幻觉留空间
规范文本经过用户确认之后，后续的所有解析、转换、SQL 生成都和 AI 无关，全部由确定性的规则引擎完成。
从 NLQ 业务词典到 MQL 的查询范式生成，再到 DQL 的外键关联处理，最后输出可执行 SQL，每一步都有明确的规则依据，可追溯、可复现、不会随机出错。
这一步不能再指望 AI，否则幻觉只是换了个位置。必须用规则引擎做确定性的编译转换，才能保证“确认无误”之后的执行环节不出差错。
也就是说，只要规范文本是对的，最终的查询结果就一定是对的。业务人员只需要确认自己看得懂的一句话，就等于确认了整个查询逻辑的正确性，不需要懂 SQL、不需要懂数据模型，真正实现了“看得懂、敢放心”。
3. 错误修复可控，不用跟幻觉 “打地鼠”
因为幻觉只出现在最前端的文本层，后续都是确定性规则，所以排错和修复的效率天差地别。
如果是 LLM 转写偏差，用户自己调整表述就能解决；
如果是业务术语识别不到，只需要在 NLQ 词典里补充一个词条，立刻生效；
如果是查询逻辑有遗漏，补充对应规则即可，不会影响其他场景。
这和纯 AI 方案 “调 Prompt、补样本、换模型，反复试错” 的维护模式有本质区别。纯 AI 方案修一个问题，可能引发十个新问题；而规则化的方案，改哪里就影响哪里，确定性极强，维护成本极低。
说到底，润乾 NLQ 的核心优势从来不是 “完全没有幻觉”，而是它坦然接受了幻觉的存在，并且通过架构设计，让幻觉变得可见、可控、可修正，不再是落地的阻碍。
Text2SQL 的落地，不是一场“消灭幻觉”的战争，而是一套“与幻觉共存”的工程。把希望寄托在模型变强上，等于把控制权交给模型厂商。真正靠谱的方案，一定是先承认 AI 会犯错，然后用人机协同的设计、确定性的规则、可感知的校验，把幻觉的影响降到最低。
企业需要的从来不是“永不犯错的 AI”，而是“出了错能发现、改起来很方便、用起来很放心”的可用工具。
