当前智能问数主要有两条技术路线：AI 生成方案和规则生成方案。

AI生成方案：什么都让 AI 干，成本高还不听话

绝大多数 Text2SQL 走的是这条路。怎么做呢？用户问一句话，大模型直接生成 SQL（或某种计算逻辑再转换成 SQL）。早期靠微调，得准备大量高质量标注数据。现在流行挂个 RAG 知识库，把表结构、字段名、业务术语全向量化存起来，每次查询时现去检索相关片段喂给大模型。不管咋弄都得养 AI 专家团队，硬件得堆 GPU 集群，向量库还得持续维护调优。

成本高也就算了，更要命的是这玩意儿不好伺候。AI 生成的 SQL，对不对全靠运气。出了问题怎么修？模型参数调一调？知识库数据补一补？改完之后又会影响什么？没人能说清楚。改对改错全靠试，试错成本没个底。

NLQ规则生成方案：规则引擎说了算，数据库工程师就能干

润乾 NLQ 换了个路子。SQL 和计算逻辑不靠 AI 生成，靠规则引擎生成。那 AI 干嘛？只做一件事，把口语化的自然语言转成有规则的自然语言，也就是“规范文本”。然后规则引擎根据预先配置好的业务词典和映射规则，把规范文本编译成 100% 准确的 SQL。

成本更是天壤之别。不用 GPU，普通 CPU 服务器就跑得稳稳当当。不用 AI 专家，熟悉数据库的开发人员就能上手。核心工作量在配置业务词典，把用户爱说的“华北区”“在途订单”这些词，跟数据库表和字段对上。词典维护是个细活儿，但方向清楚、结果可控。

关键是，规则是写死的、确定的。SQL 怎么生成、逻辑怎么组合，全都写在规则里。出了问题，查规则、改词典、补映射，改完就知道对不对，没有不确定性。

一个靠 AI 猜，一个靠规则编。一个烧 GPU 养 AI 团队，一个用 CPU 配普通工程师。成本差一两个量级，可控性天差地别。选哪个？答案很清楚。