很多企业选型 Text2SQL，只算软件采购费和大模型 API 调用费，觉得 “一次查询几分钱” 很便宜。但真正落地才发现，成本大头从来不在 “买”，而在 “养”, 要让系统在真实业务里持续能用，背后的投入远超想象。

成本高低，本质是技术路线决定的。凡是靠纯 AI 手段扛准确率的，成本注定低不了。

纯 AI 路线的三本隐形账

现在行业里很少做全量微调了，主流是 RAG+Prompt 工程，看似门槛低、不用重 GPU 投入，实则成本都藏在水面下。

人力：得养专门的 AI 运维团队

RAG 不是搭完就一劳永逸。业务变了要更新知识库，指标改了要调 Prompt，模型版本升级要重新适配，日常还要处理各类查询异常。

更麻烦的是黑盒排错。查询出错了，分不清是 Prompt 问题、召回问题还是模型本身幻觉，普通开发根本搞不定，必须靠懂大模型调优的专业人员排查。

这相当于 “为了坐飞机，得养个地勤机组”，人力门槛和成本都下不来。

数据：领域知识注入是持续投入

通用大模型不懂企业专属业务。“大订单” 的定义、“活跃客户” 的口径、不同系统里的术语差异，这些都得人工梳理后喂给模型。

不管是做知识库切片还是整理示例样本，本质都是人工沉淀业务知识，且没法跨企业复用。要保证质量，还得找既懂业务又懂数据的人，这类人才稀缺，成本自然居高不下。

维护：修一个 bug 可能牵一发而动全身

AI 方案修复问题的链路极长：发现错误→定位根因→补样本 / 调 Prompt / 更知识库→全量回归验证→上线。

一圈走下来，少说几天，多则几周，业务根本等不起。更头疼的是，模型调优是全局影响，修好了这个场景，说不定另一个场景又出问题，永远在补窟窿，维护成本越滚越高。

用不确定性换确定性，只能堆成本

为什么这些成本绕不开？因为 LLM 天生带幻觉，要提升准确率，就必须持续注入领域知识。

无论是微调还是 RAG，本质都是 “堆成本换更高的正确概率”，只能缓解幻觉，没法根除。投入再多人力、样本、调优工作量，也只是提高了赌对的概率，变不成 100% 的确定性。

而业务决策容不得 “大概率正确”。更致命的是，业务人员看不懂 SQL，连 “这次结果对不对” 都判断不了，最后要么不敢用，要么得人工复核，等于没省人力。

换条路线：把成本从 “AI 模式” 切换到 “工程模式”

成本不是省出来的，是设计出来的。

既然 AI 天生不确定，那就别让它硬扛准确率，让 AI 只做它擅长的语义转换，准确性交给人类确认和规则引擎。

润乾 NLQ 走的就是这条工程化路线，核心架构一句话就能说清：LLM 做翻译，人做确认，规则引擎做转换。

用户的口语化提问，先由 LLM 转写成人人能懂的 “规范文本”，比如把 “去年谁还没开单？” 规整为 “去年没有订单的员工”。业务人员一眼就能确认意图对不对，确认无误后，再由规则引擎确定性地生成 SQL 执行。

整个流程里，AI 只负责 “把口语捋成规范表达”，不碰业务逻辑，自然就把全链路成本打了下来。

人力门槛骤降：普通开发就能运维

润乾 NLQ 不需要 AI 专家团队。实施的核心工作是构建业务词典，完成数据表、字段、业务术语的映射。这件事懂业务的数据库开发人员就能做，甚至熟悉数据的业务人员经过简单培训，也能参与维护。

不用养专门的 AI 调优团队，人力成本直接砍掉一大块。

无数据标注负担：复用现有资产

润乾 NLQ 不需要任何标注训练数据，也不用攒大量问答样本。词典直接基于企业已有的数据字典搭建，省去了 “收集查询→标注 SQL→训练模型” 的全套流程，数据采集、标注的成本全部省掉。

维护效率翻倍：补配置即刻生效

这是最核心的成本差异。润乾 NLQ 修复问题的流程极其简单：发现查询异常→定位是缺词条、映射错误还是规则未覆盖→补充词典配置→立即可用。

规则引擎是确定性的，改哪里影响哪里，不需要全量回归测试，不会牵一发而动全身。一个问题的修复，分钟到小时级就能完成，维护效率是 AI 路线的数十倍。

运行成本极轻：CPU 即可承载

润乾 NLQ 不需要 GPU，也不用本地部署大模型。LLM 只做一次轻量的文本规范化，token 消耗极低；后续的解析、转换全靠规则引擎，普通 CPU 服务器就能扛住高并发。单次查询的算力成本几乎可以忽略不计。

对比一下两条路线的账本

判断一个 Text2SQL 方案的长期成本高不高，方法特别简单：就看它修复一个问题需要什么级别的资源。

· 需要 AI 专家调模型、改 Prompt、做全量回归的，成本低不了。

· 补个配置就能搞定的，成本高不了。

Text2SQL 的实践成本，从来不由厂商定价决定，而由技术路线决定。靠 AI 堆准确率的路，越走越贵；把 AI 放回合适的位置，用工程化思路解决确定性问题，才是真正低成本的落地之道。