现在聊 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”而是“出了错能发现、改起来很方便、用起来很放心”的可用工具。
)
