中小企业做智能问数，面临一个死结：数据不能出内网，大模型API用不了；私有部署大模型，GPU服务器和运维成本又扛不住。这篇文章讲的是第三条路——用小模型+语义层+确定性编译引擎，纯CPU服务器跑起来，准确率照样99%以上。

中小企业的两难

中小企业做智能问数，卡在两个绕不过去的坎上：

1. 数据不出内网：金融、医疗、政务、制造——数据安全是红线，公有云大模型API方案直接不适用。

2. 硬件扛不住：私有部署一套大模型，GPU服务器30-50万起步，年耗电再加3-5万，中小企业全年IT预算搭进去都不够。

安全要求私有化，预算又够不着GPU门槛——两条路都堵死了。

问题出在哪？大模型"包揽"了太多活

传统智能问数方案的问题在于：从理解问题到生成SQL，全程依赖大模型。

用户："华南区上个月毛利率多少？"
    ↓
大模型（负责所有事情：理解意图 + 选表 + 写JOIN + 写WHERE + 写计算公式）
    ↓
SELECT ... FROM ... WHERE ...

这种"一条龙"模式下，大模型是绕不开的瓶颈——你必须买足够的GPU算力让它跑起来。

但换个思路：大模型真的需要做所有事吗？

换个思路：把"写SQL"这个活从大模型手里拿走

极昆仑iInsight的做法是大小模型分离：

用户："华南区上个月毛利率多少？"
    ↓
NLP小模型：意图分类 + 实体抽取
  - 意图：查询
  - 指标：毛利率
  - 维度：区域=华南区，时间=上月
    ↓
语义层：确定性映射
  - "毛利率" → (SUM(revenue) - SUM(cost)) / SUM(revenue) * 100
  - "华南区" → region = '华南'
  - "上月" → month = current_month - 1
  - 数据表：sales_fact JOIN product_dim ON sku_id
    ↓
确定性SQL编译器：按规则生成SQL（零幻觉，零概率）
    ↓
SELECT (SUM(revenue)-SUM(cost))/SUM(revenue)*100
FROM sales_fact
JOIN product_dim ON sales_fact.sku_id = product_dim.sku_id
WHERE region = '华南' AND month = '2026-07'

核心设计思想就一条：不要让模型写SQL。

• NLP小模型只做意图分类和实体抽取（参数量小，CPU可运行）

• 语义层充当"业务翻译官"（指标定义、表关系、维度映射提前建模）

• 确定性编译器按规则生成SQL（规则引擎，不是概率推理）

SQL生成这一步走出概率推理的范畴，变成了确定性执行。不错，就是不错。

靠着这套架构，极昆仑iInsight小模型方案的问数准确率同样达到了99%以上——不是某次demo的偶然表现，而是4100个测试文件、50160个测试用例全量回归验证出来的工程指标。

实际的硬件需求

部署极昆仑iInsight小模型方案，典型配置如下：

一台8核/32G内存的CPU服务器即可满足全部需求，硬件成本约3万元，足够支撑50人以下团队日常使用。

为什么小模型也能做到准确率这么高？

一个常见的疑问是：大模型几百亿参数，你一个小模型，凭什么准确率能到99%？

答案在架构分工，不在模型大小。智能问数场景里，最容易出错的一环是SQL生成——表关联写错、WHERE条件漏掉、计算公式对不上。大模型在这件事上并没有天然优势，因为每次生成SQL都是一次概率采样，同一个问题问两遍可能生成两条不同的SQL，一条对一条错，你还不知道为什么。

极昆仑的做法是把这件事从概率问题变成确定性问题：

第一，SQL生成不走模型，走规则引擎。 确定性编译器根据语义层里的预置规则拼SQL——指标怎么算、表怎么关联、条件怎么过滤，全部提前定义好。编译器只是"查字典+拼句子"，不涉及推理和采样。这步对了就永远对了。

第二，语义层把模糊的业务语言翻译成了精确的数据定义。 "毛利率"对应哪张表的哪几个字段、计算公式是什么，"上个月"对应哪个时间偏移函数——这些在语义层里建模一次，之后所有调用走同一条规则。LLM做这件事需要每次"猜"，语义层不需要。

第三，50160个测试用例的全量回归体系。 每次发版自动跑全量回归，任何一个已通过的测试用例复现错误，发版直接拦截。这意味着准确率不是某次评测的快照，而是一个持续可追溯、可复现的工程指标。

三管齐下，准确率的天花板不取决于模型参数有多大，而取决于三件事：语义层建得准不准、编译器规则全不全、回归体系覆不覆盖得住。小模型在这套架构里的角色只是"理解用户想问什么"，不承担"写SQL"这个出错率最高的环节——这才是核心。

适合什么样的企业？

这个方案不是给那些GPU预算充裕、想上最前沿大模型的团队设计的。它适合这样一群人：

• 数据不能出内网，公有云API方案直接不适用

• IT预算有限，买不起也不想养GPU集群

• 团队规模在20-200人，数据分析需求高频但不是海量

• 更看重"准确、可验证、不出错"，而不是"模型有多大"

如果你的需求是让业务人员能自己查数、做归因分析、生成数据报告，而不想让财务部为了一张A100显卡跟你吵三个月——这条路是走得通的。