企业官网建设流程全解析

完成BERT微调后，项目继续探索模型压缩、大模型分类和服务化。本篇是TicketFlow AI系列的工程落地总结。

一、为什么需要模型压缩

BERT模型语义能力较强，但权重较大、CPU推理成本较高。项目分别实现动态量化、非结构化剪枝和知识蒸馏，比较模型大小、精度与推理延迟。

二、动态量化

quantized_model = torch.quantization.quantize_dynamic( model, {torch.nn.Linear}, dtype=torch.qint8 )

量化后应在目标CPU上重新测试Macro-F1、平均延迟、P95延迟和内存。文件缩小不代表所有设备都能得到相同加速。

三、非结构化剪枝

项目对BERT多层Query权重做全局L1剪枝，将绝对值较小的权重置零。实验说明了一个重要问题：稀疏度提高不等于模型文件自动缩小，真正加速还需要稀疏算子和硬件支持。

四、知识蒸馏

教师模型使用BERT，学生模型使用BiLSTM。学生既学习真实标签，也学习教师输出的软概率分布：

总损失 = α × 软标签KL散度 + (1 - α) × 真实标签交叉熵

温度参数让教师分布更加平滑，使学生看到类别之间的相对关系。蒸馏效果应与“直接训练BiLSTM”进行对照。

五、LLM Prompt分类

项目接入DeepSeek和Agnes等OpenAI-compatible接口，通过系统提示词给出十类标签、类别说明、边界规则和输出约束。

大模型必须只输出一个固定英文类别名，代码还需要执行白名单校验：

allowed_labels = { "account_login", "permission_apply", "system_error", "data_exception", "payment_issue", "product_consult", "after_sales", "complaint", "feature_request", "other" }

GitHub中的API Key统一使用your_api_key或环境变量，真实Key绝不能提交到代码仓库。已经暴露的Key应立即撤销并重新生成。

六、Flask服务

GET /health POST /predict POST /predict_batch

接口层负责JSON校验、空文本处理、异常捕获和统一返回格式。Streamlit页面用于输入工单、展示类别名称和ID，并记录最近预测结果。

七、完整部署思路

用户提交工单 → 参数校验与敏感信息脱敏 → 本地分类模型 → 置信度判断 → 高置信度自动路由 → 低置信度人工复核或LLM兜底 → 保存预测与人工修正结果 → 定期增量训练

八、项目总结

TicketFlow AI覆盖了数据处理、传统机器学习、FastText、BERT微调、模型压缩、LLM Prompt、Flask API和Streamlit展示。分类标签不是终点，而是自动派单、相似工单检索、知识库推荐和客服Agent的入口。

项目地址：TicketFlow AI GitHub 公开演示版