用 2.4MB 的 Go 分类器替代 7B 大模型

很多开发者在做 AI 落地时有个惯性思维：只要是处理文本，第一反应就是接个 LLM。但实测发现，绝大多数生产环境的 AI 任务根本不需要大模型。比如给邮件分标签（工作、订阅号、推广），这在 20 年前就是被解决掉的经典分类问题，非要用 7B 参数的模型去跑，简直是拿大炮轰蚊子。

分享一个我的实战方案：我把一个基于 Ollama 运行的 Qwen 2.5 7B 替换成了一个极小的 Go 语言分类器，逻辑是“规则优先 → 小模型 → LLM 保底”。

具体的路由逻辑如下：

func (c *Classifier) decide(m Message) Decision {
	// 1. 确定性规则：一眼就能认出的发件人，直接拦截
	if d := preClassify(m); d != nil {
		return *d
	}
	// 2. 轻量级 ML 模型：CPU 运行，亚毫秒级响应
	pred := c.ml.Predict(m)
	if pred.Confidence >= c.threshold {
		return decisionFrom(pred)
	}
	// 3. LLM 最后出场：只有小模型拿不准的边缘案例才走云端/大模型
	return c.classifyWithLLM(m)
}

这种分层架构的实测效果非常明显：

• 确定性规则层： 处理那些发件人域名就直接暴露身份的邮件。规则是透明且可测试的，完全零成本。
• 轻量模型层： 针对模糊地带，我用了 TF-IDF + 逻辑回归（Logistic Regression）。这个模型只有 2.4MB，跑在 CPU 上，推理时间是亚毫秒级的。
• LLM 保底层： 只有当小模型的置信度低于阈值时，才会调用大模型。

对比下来，之前用 7B 模型需要 GPU 24 小时待命，容器还要盯着，响应速度慢得离谱。现在绝大多数请求在第一、二层就拦截了，GPU 压力骤减，成本直接掉下来，而且响应速度快到无感。

总结一个实操经验：在构建 AI 工作流时，应该把 LLM 放在链路的最末端。先用硬编码规则过滤，再用传统机器学习模型处理，最后才交给大模型做复杂决策。