AI 远没那么聪明，能把传统 BI 的一问一答做稳做准就不错了
智能问数、ChatBI 的概念这两年越炒越热。很多企业选型时的预期被拉得很高：像聊天一样做分析、多轮对话深挖数据、AI 自动出结论……仿佛怼上数据库就能跑，业务人员随便问，系统全自动出结果。
但真正落地过的人都清楚，理想和现实的落差很大。问题出在期望上。
传统 BI 功能本身就很难做好
很多人觉得 Text2SQL 就是“把话转成 SQL”，能有多难？
实际上，传统 BI 的查询能力本身就是有门槛的。
多表关联、嵌套条件、跨表指标对齐、主子实体汇总，这些在传统 BI 里做起来都不简单，要写复杂的 SQL、要做模型设计。Text2SQL 要稳定地完成这些，面临的挑战比想象中大得多。
单轮复杂查询能做准，本身就是硬功夫。别一上来就聊多轮对话，先把单轮的复杂查询做好再说。
但是 AI 现在喊得太响了，导致用户经常有幻想。
两个不切实际的幻想
幻想一：指望像 OpenClaw 那样全链自动、无需审查。
用户输入一句话，AI 自动理解、自动生成 SQL、自动返回结果，全程不需要人介入；这是很多产品的宣传画面，也是 OpenClaw 这类 AI 智能体追求的“全自动执行”。
但在数据查询这个领域，全自动恰恰是最危险的事情。你根本不知道它是不是中间出了幻觉，它确实能算出个数，但你也搞不清对不对。跟经营决策挂钩的数据查询，你敢对 AI 生成的结果照单全收吗？
意图有没有理解对？指标口径有没有偏差？表关联逻辑有没有错？任何一处偏差都可能导致错误结论。全自动执行在日常办公场景下很酷，在严肃的数据分析场景下很危险。
幻想二：以为怼上数据库就能用，不需要费劲实施。
另一个常见的幻想是：都 AI 了、买个产品、接上数据库、就能用了。
实际上，企业数据环境的复杂性远超想象。字段名叫 ods_sales_amt、dws_stock_qty，大模型连这些是什么都猜不出来。“客户”在不同系统里可能叫“甲方”、“会员”、“用户”。同一个指标在不同部门口径完全不同。
大模型处理短上下文、单步推理时表现不错，比如把一句简单的话转成 SQL，它大概率能做好。但一旦上下文长了、需要多步推理了，它就记不住、会脑补、会漏信息。
这些问题不是靠模型参数能解决的。需要前置的数据治理、口径对齐、业务词典构建，这些实施工作省不掉。
“自动化”可以做，但要接受确认环节的插入
行业里理想的全自动对话式分析形态是：全程无断点、AI 自动承接上下文、一步步推导结论，全程不需要人工介入。
但这不是现实。
在严肃业务场景里，“丝滑的全自动 Chat 体验”和“结果可信”天然矛盾。想要流畅就不能打断，想要可信就必须确认。每一次关键查询，都要停下来核对意图、确认口径、校验结果。“连续对话”变成了“提问→确认→再提问→再确认”的断续流程。
想做实用的 ChatBI，要容忍插入的人类确认环节。如果不能接受，一定要实现全自动化流程，那要么是玩具场景，要么就是一地鸡毛。
这不是技术能不能做到的问题，是业务敢不敢信的问题。
润乾 NLQ：把确认做进流程里，把复杂查询做扎实
在行业普遍追逐“全自动 Chat”概念时，润乾 NLQ 走了一条务实的路线：不追“万能 Chat”，追“可靠问数”。
核心逻辑就一句话：LLM 做翻译，人做确认，规则做转换。
复杂查询能力是基础
润乾 NLQ 覆盖的是完整的传统 BI 查询场景：单表明细筛选、单表维度聚合、主子实体关联查询、跨表指标对齐汇总。多表关联通过 DQL 层的“外键属性化”消除显式 JOIN，用户看到的是单表表达，底层自动解析关联，不用关心 JOIN 逻辑。更复杂的指标用 SPL 定义好，查询时直接调用。
传统 BI 能覆盖的场景，它都能稳定输出，准确率不随复杂度上升而暴跌。这不是靠大模型现场“生成”出来的，是靠规则引擎的确定性转换保证的。
确认环节做得足够轻
用户口语输入“去年没开单的女员工”。
LLM 翻译成规范文本：“签单日期 去年， 没有 订单， 女 员工”。
这是大家都读得懂的汉语，不是 SQL，也不是 JSON，不是任何技术黑话。业务人员扫一眼就知道“对，这就是我想问的”，确认后执行。发现不对直接改表述重新来。确认环节不是体验的减分项，而是可信的必选项。
其他方案的中间层是 JSON、XML、自定义 DSL，机器能读，人看不懂。业务人员面对这些格式，跟面对 SQL 没什么两样，确认也就无从谈起。而规范文本是人机双向可读的 DSL，机器能解析，人也能看懂。
实施门槛低、效果还可控
润乾 NLQ 不依赖微调、RAG 这类 AI 手段来保证查询准确性。
很多 AI 路线要把企业数据喂给模型做微调，或者构建 RAG 知识库让模型在查询时检索。这条路的问题在于你永远不知道它能不能搞定。修一个问题可能要重新标注数据、重新微调、重新验证，而且你无法保证这次修好会不会在其他地方引入新问题。效果不可预期，是 AI 路线最大的风险。
润乾 NLQ用规则和词典来保证准确性，AI 只做翻译。
实施的核心工作是构建业务词典，把企业的表、字段、业务术语映射到词典里。这件事不需要 AI 专家，懂业务的数据库开发人员就能干。基于企业已有的数据字典构建即可，不需要从零标注数据。
维护也简单。查询错了，分析是词典缺词条、字段映射错了、还是规则覆盖不全，补个配置就能修，小时级完成。每一步转换都是确定性的、可追溯的、可调试的，你能清楚地知道系统为什么这么理解，出了问能从根上修，不是“再试试看”。
对比两条路线：
| AI 路线 | NLQ 路线 | |
| 人力 | AI 专家团队 | 数据库开发人员 |
| 实施 | 标注数据、微调模型、构建知识库 | 构建业务词典 |
| 维护 | 效果不可控，修问题可能引入新问题 | 补词典配置，可控可预期 |
润乾 NLQ 不跟你比模型参数，它跟你比业务人员到底敢不敢用，比出了问题你能不能修得明白。
Text2SQL 不是银弹。别指望怼上数据库就能全自动跑起来。也别指望像 OpenClaw 那样全链执行不用审查。
能做多表关联、能做复杂条件、用户执行前能看懂确认——这已经很了不起了。
能做到这一点，就已经比大部分停留在 Demo 里的方案务实得多。
