做智能问数 Text2SQL 要务实，期望太高的结果是一地鸡毛

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 里的方案务实得多。