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

简介: 智能问数存在“不可能三角”:灵活性、准确性、复杂性三者不可兼得。润乾NLQ创新破局——用LLM专司口语转规范文本(保灵活),用户确认后交由规则引擎编译SQL(保准确),再通过MQL/DQL/SPL分层支撑复杂查询(保复杂)。三角非攻克,而是拆解与协同。

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

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

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

智能问数的不可能三角

e47691b009b8d9b87bbb33b2f4e15ce3_1787270956520100.png

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

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

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

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

选哪两个,代价是什么?

路线一:要灵活 + 准确,牺牲复杂性。

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

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

路线二:要灵活 + 复杂,牺牲准确性。

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

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

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

路线三:要准确 + 复杂,牺牲灵活性。

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

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

为什么三者不可兼得?

根源在 LLM。

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

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

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

润乾 NLQ 怎么破这个局?

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

灵活性交给 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 分层承担不同粒度的复杂性。

各司其职,各取所长。

相关文章
人工智能 缓存 前端开发
12026 63
人工智能 JavaScript 开发工具
4812 17
Web App开发 人工智能 API
1385 1
人工智能 Java BI
1472 1
开发工具 Swift git
1974 6
人工智能 JavaScript 测试技术
2406 2
人工智能 自然语言处理 安全
992 0
人工智能 JavaScript 测试技术
1200 4
缓存 JavaScript Shell
2102 3

热门文章

最新文章