TicketFlow AI 项目实践（六）：模型压缩、LLM 分类与 Flask 部署

完成BERT微调后项目继续探索模型压缩、大模型分类和服务化。本篇是TicketFlow AI系列的工程落地总结。一、为什么需要模型压缩BERT模型语义能力较强但权重较大、CPU推理成本较高。项目分别实现动态量化、非结构化剪枝和知识蒸馏比较模型大小、精度与推理延迟。模型本地文件大小说明原始BERT约390.23 MiBFP32分类模型动态量化约145.58 MiB部分Linear层转换为INT8非结构化剪枝约417.20 MiB稀疏权重和掩码不保证文件变小蒸馏BiLSTM约25.39 MiBBERT教师指导轻量学生模型二、动态量化quantized_model torch.quantization.quantize_dynamic( model, {torch.nn.Linear}, dtypetorch.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 公开演示版