别再用 7B 大模型做文本分类了，试试 2.4MB 的 Go 语言轻量化方案

在目前的 AI 落地实践中，很多开发者陷入了一个严重的“路径依赖”：只要涉及到文本处理，第一反应就是调用 LLM。这种思维在原型开发阶段很高效，但一旦进入生产环境，你会发现用一个 7B 参数的模型去处理邮件标签分类（比如区分工作、订阅号、推广），简直就像是用大炮轰蚊子，资源浪费极其严重。

最近我把一个基于 Ollama 运行的 Qwen 2.5 7B 模型替换成了一套分层路由方案，核心逻辑是“规则优先 → 小模型 → LLM 保底”。这次重构让我意识到，绝大多数所谓的“AI 任务”，其实在 20 年前就被传统机器学习解决了。

我分享一下具体的实现逻辑。在 Go 语言中，我构建了一个 Classifier 结构体，通过一个 decide 方法来分发请求，代码逻辑如下：

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)
}

这套架构的核心在于将 LLM 放在链路的最末端，而不是作为唯一的入口。

首先是“确定性规则层”。这层处理的是最简单的情况，比如某些发件人域名直接暴露了邮件属性，或者包含特定的过滤词。这部分逻辑是完全透明且可测试的，且运行成本几乎为零。

其次是“轻量模型层”。针对那些无法通过简单规则判定，但具有明显统计特征的模糊地带，我采用了 TF-IDF（词频-逆文档频率）结合逻辑回归（Logistic Regression）的方案。这个模型经过训练后，最终生成的二进制文件仅有 2.4MB。最关键的是，它完全运行在 CPU 上，单次推理时间达到了亚毫秒级。这意味着在绝大多数请求中，用户根本感知不到任何延迟。

最后才是“LLM 保底层”。只有当轻量模型的预测置信度（Confidence）低于预设阈值时，系统才会调用大模型进行复杂决策。

这次切换带来的性能提升是非常震撼的。在之前的方案中，我需要让 GPU 24 小时待命，不仅要维护复杂的容器环境，还要忍受 LLM 缓慢的 Token 生成速度，响应延迟经常在秒级。而采用分层架构后，绝大多数请求在第一、二层就被拦截并快速返回，GPU 的压力骤减，整体成本直线下降，且响应速度快到无感。

这次实操给我最大的启发是：构建 AI 工作流时，不要盲目追求模型的“规模”。一个优秀的工程方案应该是金字塔形的——底层用硬编码规则过滤，中层用传统机器学习处理，顶层才交给大模型做复杂推理。这样不仅能保证系统的鲁棒性，还能在成本和性能之间找到最优平衡点。