算力不足时怎样做智能问数

智能问数绕不开算力。

RAG 要算力，微调要算力，在线推理更要算力。对于预算有限的中小企业，或者 IT 基础设施薄弱的传统行业，想尝鲜智能问数，却被算力挡在门外。

但智能问数不一定非靠大模型不可。如果愿意接受一种“没那么灵活，但仍然可用”的交互方式，普通 CPU 就能跑起来。

算力不够，体验来换

大多数智能问数产品的卖点是“随便问”。口语怎么来都行，系统都能理解。这种灵活性靠的是大模型的理解能力，背后是 GPU 算力支撑。

但如果把“随便问”换成“引导式输入”，事情就简单了。

润乾 NLQ 提供了这种种“字段提示”模式：用户在输入框里打字时，系统根据预先构建的词典和字段信息实时提示匹配项。你输入“商品”，系统自动提示相关的字段词、维词、常数词等，帮你把查询意图规范成系统能理解的表达。

截图展示的就是这个效果。用户输入“商品”，系统自动提示可用的查询组合。用户选一个，就是一个完整的规范查询。字段名是业务人员看得懂的中文，提示词引导用户按规范语法逐步构建查询。

这就是算力换体验的逻辑：牺牲一点“随便问”的灵活性，换取低成本的可运行。

规范文本也是自然语言，不难写

有人问：规范查询是不是要学语法？

是需要事先了解一下，不过规范查询本身就是自然语言，只是比口语更“规整”一些，上手并不难。

举个例子：

• 口语：“上个月北京发往青岛的订单有多少？”
• 规范查询：“上月 北京 发往 青岛 订单数”

业务人员一看就懂，也不需要专门培训。在提示的辅助下，用户看到字段名、维词、常数词，按顺序组合即可。学不会 SQL 的业务人员，用规范查询写 BI 需求毫无障碍。

而且提示词会帮助用户匹配字段。输入“北京”，系统提示这是一个“城市”维的常数词，可过滤“发货城市”或“收货城市”，用户只需确认选哪个，不用关心数据库里存的是“北京”还是“010”之类的编码。

规范文本查询同样支持完整的 BI 能力：多表 JOIN、嵌套子查询、跨表按维对齐、排名占比环比同比。降低的只是入口的“自由度”，不是核心的分析能力。

两种模式，丰俭由人

润乾 NLQ 支持两种运行模式：

模式一：接 LLM，口语随便问。

灵活性最高，用户怎么问都行。代价是需要 GPU 或 API 调用费用，单次查询有 token 消耗。适合预算充足、追求极致体验的场景。

模式二：不接 LLM，用字段提示写规范文本。

灵活性略降，用户需要按规范方式组织查询。但好处明显：不需要 GPU，普通 CPU 即可运行；没有 token 费用，没有 API 延迟；结果 100% 可预测、可追溯。适合预算有限、查询模式相对固定的场景。

两种模式共享同一套规则引擎。

对于排名、占比、同比、环比等跨行运算，以及多表关联的复杂查询，模式一靠 LLM 自动规划，用户问一句“去年各月销售额环比”，LLM 理解语义、拆解步骤、依次执行。效果很智能，但背后要有算力支撑。

模式二没有 LLM 帮忙规划，操作上会“辛苦”一点，先用 NLQ 查询出结果，再跳转到 NLR 做跨行组运算。

以“去年各月销售额环比”为例，模式二的操作步骤是：

• 第一步：查询 “去年 年月 订单金额”

• 第二步：计算 订单金额 比例环比 命名为 订单金额比例环比

第一步 NLQ 先查出 2025 年各月销售额，第二步在结果集上通过 NLR 计算环比增长率。每一步都是规范文本 + 规则引擎，不走 AI，结果 100% 可靠。

那什么是 NLR？润乾 NLR（自然语言报表）对 NLQ 查出来的数据做再处理，分组汇总、排名、环比、同比、占比、排序、过滤、条件格式、统计图绘制等。定位是“让用户用自然语言对结果集继续算”，而不是让 LLM 去规划多步 SQL。

算力不足，不等于智能问数没戏

中小企业做智能问数，不必非走“大模型 + 算力”这条路。

字段提示引导用户写出规范文本，牺牲的是“口语随便问”的灵活性，换来的是低成本的可用性。规范文本是自然语言，有提示辅助，学习成本不高。

算力不足，用体验来换。关键是：换了之后仍然可用。

NLQ 的规则引擎在普通 CPU 上就能跑，不需要 GPU 集群，不需要 AI 专家团队。普通 CPU 服务器即可支撑多个并发查询，长期持有成本可控，而不是持续消耗 Token 的计费模式。对于预算有限的企业来说，这是一条走得通的路。