智能问数的不可能三角：灵活、准确、复杂

许多领域都有“不可能三角”的说法，意思是说有三种特性最多只能同时得到其中两种，不可能三者全得，做智能问数也有这样的 “不可能三角”：

灵活性、准确性、复杂性，三者不可兼得。

这不是某个厂商的能力问题，是技术路线决定的宿命。你选哪条路，就得接受这条路的代价。

智能问数的不可能三角

灵活性：用户怎么问都行，口语、黑话、不完整的句子，系统都能理解。

准确性：生成的 SQL 有极高的正确率，语义不能跑偏，结果不能出错。

复杂性：多表 JOIN、嵌套子查询、跨表按维对齐、排名占比环比同比这些企业真实的查询需求，系统都能支持。

很遗憾，这三个角，你只能选两个。

选哪两个，代价是什么？

路线一：要灵活 + 准确，牺牲复杂性。

把查询范围缩窄——只查一张 BI 大宽表，字段都拍平了，没有 JOIN，没有子查询。LLM 在这种“温室”里确实能跑出很高的准确率，也能理解各种口语表达。

但代价是：企业真实的数据环境不是大宽表。真实业务需要关联四五张表、需要嵌套子查询、需要跨表汇总。一旦超出单表范围，这套方案就废了。

路线二：要灵活 + 复杂，牺牲准确性。

让 LLM 放手去生成 SQL，多表 JOIN、子查询、复杂条件统统支持，用户随便问。Demo 里看着很酷。

但代价是：准确率断崖式下跌。涉及多表 JOIN 时准确率经常降到 50% 以下；再来几层子查询，更惨不忍睹。而且还不稳定，今天对的明天错，这个写法对的那个写法错。

用户面对一个“可能出错”的系统，只能选择不用。

路线三：要准确 + 复杂，牺牲灵活性。

用规则引擎把一切逻辑写死，字段映射、表关联、指标定义全部预置。复杂查询能支持，结果也很准确。

但代价是：用户必须按规范方式提问，不能说口语，不能有歧义，不能省略字段。这相当于回退到前 AI 时代的拖拽 BI 了，AI 了个寂寞。

为什么三者不可兼得？

根源在 LLM。

LLM 擅长理解自然语言——这是灵活性的来源。但 LLM 天生有幻觉，不可能 100% 准确——这是准确性的天敌。

要压制幻觉、提升准确性，就得限制 LLM 的输出空间——缩窄查询范围（牺牲复杂性），反之，想提升复杂性，又只能容忍 LLM 的幻觉（特别准确性）。如果这两者都想要，那就只能放弃 LLM 写成死规则下的确定性查询（牺牲灵活性）。

你不可能让一个概率模型同时做到“什么都懂”和“永远不错”。

润乾 NLQ 怎么破这个局？

润乾 NLQ 的思路不是“选两个放弃一个”，而是把三角拆开，让不同部件承担不同角。

灵活性交给 LLM

用户口语进来，LLM 负责翻译成规范文本，把“上个月没有签单的客户”这种日常问法，转成结构清晰的表达。LLM 只做翻译，不做决策。

这一步的关键是：LLM 的任务被极大简化了。它不需要理解复杂的业务逻辑，不需要掌握 SQL 语法，不需要记忆表结构关联，只需要做文本规范化转写。通用大模型即可胜任，不用微调，无需构建庞大的 RAG 知识库。任务简化还会带来成本优势，单次查询的 token 消耗大幅降低，推理过程更加轻量。

准确性交给规则引擎，外加人类确认兜底

LLM 翻译出来的规范文本，需要用户先看一眼，确认“对，这就是我想查的”，再点执行。如果 LLM 翻译偏了，用户当场就能发现，改一下表述重新来。之后，就没有 LLM 的事了，SQL 是基于规则编译的，路径确定、可验证、可重复。规则引擎编译，不是概率猜测。从确认完成到 SQL 执行这一段，准确率 100%，没有“大概率正确”。这一步不能再指望 AI，否则幻觉只是换了个位置。

复杂性交给 MQL、DQL 和 SPL。

规范文本确认之后，要落地成 SQL，中间还有三层架构在支撑。

MQL（Metrics Query Language）是规范文本的确定性编译目标，通过四种查询范式——单表明细、单表聚合、主子实体、多维对齐汇总，把 BI 场景的典型查询模式全部覆盖。MQL 采用类 SQL 语法，在表达力与规范性之间实现了平衡。

DQL（Dimensional Query Language）解决的是多表关联问题。以往 Text2SQL 一碰到多表 JOIN 就翻车，DQL 通过“外键属性化”消除了显式 JOIN。比如查询“北京客户下的订单”，用户看到的是单表表达，底层自动解析客户表关联。无论有多少层表间关联，都可以通过点操作符逐级访问，FROM 后面只有一个单表。用户不关心也不需要懂 JOIN。

SPL（Structured Process Language）处理的是复杂计算。排名、占比、环比、同比这些跨行运算有了 SPL 的支持可以直接使用；而像月活、留存率、股票连涨天数这些更复杂的逻辑，可以预置好 SPL 指标，MQL 里直接调用。

当然对于用户来讲这些都是透明的，直接使用就好。

三角不是被“攻克”的，是被“拆解”的，这里的关键在于设计了人机双向可读的规范文本。人类可读才可以确认，从而挡住 LLM 的幻觉，保留了灵活性；机器可读才可以编译，同时获得了准确性和复杂性。

让 LLM 做它擅长的事（理解口语），不让它做它不擅长的事（稳定准确生成 SQL）。让规则引擎做它擅长的事（确定性编译），不让它做它不擅长的事（理解口语）。让 MQL、DQL、SPL 分层承担不同粒度的复杂性。

各司其职，各取所长。