智能问数 Agent 如何确保 SQL 生成 100% 准确？

在企业推进数据民主化的进程中，智能问数被寄予厚望——业务人员只需用自然语言提问，Agent 便能自动返回准确、可解释的数据洞察。然而，现实却常常令人失望：当不同业务人员问出“本月北京地区销售额是多少”这样看似简单的问题时，大模型却可能给出不一致甚至相互矛盾的结果。这不仅削弱了业务对数据的信任，更迫使他们反复向 IT 部门求证，陷入“问数——对数——核数”的低效循环。

问题出在哪里？为什么“无所不能”的大模型，面对企业内部数据分析时却频频“失准”？

三大核心矛盾：智能问数落地的真实困境

剖析这一现象，我们发现其背后存在三个根本性矛盾：

第一，大模型的“聪明” VS. 对业务的“未知”。大模型具备海量通识性知识，但对企业内部的数据口径却一无所知。例如，“销售额”在不同业务场景下含义迥异：是否包含退款？是否计入小样赠品价值？双十一消费券抵扣是否算入？这些细节决定了数据的准确性，而大模型无法凭空推断。

第二，生成的“随机性” VS. 决策的“确定性”。业务决策依赖稳定、一致的数据结果，但大模型本质上是概率生成模型，同一问题在不同时间或上下文中可能产生不同输出。这种“随机性”与企业对数据“唯一真相”的诉求天然相悖。

第三，追求“效率” VS. 现实的“反复”。引入大模型本意是降低数据使用门槛，但当结果不可信时，业务人员反而需要投入更多时间与 IT 反复确认口径，不仅未提升效率，反而增加了沟通成本。

破局关键：构建指标语义层，走向 NL2MQL2SQL

要解决上述矛盾，不能仅靠调优大模型提示词或增加训练数据——那只是在“概率的泥潭”中打转。真正的破局点，是在大模型与数据库之间，通过软件工程构建一个确定性的中间层：指标语义层。

传统智能问数方案采用 “NL2SQL” 范式：大模型直接解析用户问题，尝试从底层混乱的物理表结构中生成 SQL。这种方式将业务语义的复杂性完全压给大模型，导致同一指标因表结构理解偏差或字段映射错误而产生不同结果。

而 NL2MQL2SQL 新范式，则彻底改变了这一逻辑：

1. 用户提问（自然语言）

2. 大模型解析意图：识别出原子化数据要素——指标（如“销售额”）、维度（如“门店”）、筛选条件（如“城市=北京”）、时间范围（如“本月”）、衍生计算（如“排名”）

3. 指标语义层：基于预定义的指标、维度、逻辑模型、数据血缘等元数据知识库，将这些要素确定性地拼