TicketFlow AI 项目实践(五):BERT 微调与工单 BadCase 分析

📅 2026/7/17 21:03:08
TicketFlow AI 项目实践(五):BERT 微调与工单 BadCase 分析
TF-IDF和FastText主要依赖词频及局部特征。为了进一步处理上下文依赖、口语化和同义表达我使用 bert-base-chinese 完成工单十分类微调。一、BERT配置参数当前配置预训练模型bert-base-chinese类别数10Epoch3Batch Size32最大长度64学习率5e-5工单通常较短因此最大长度设置为64。实际项目应先统计长度分布再决定截断阈值而不是机械套用固定参数。二、Tokenizer输出encoded tokenizer( text, max_length64, paddingmax_length, truncationTrue, return_tensorspt )input_ids文本Token对应的词表IDattention_mask区分真实Token和Paddinglabel工单类别的监督信号三、模型结构input_ids attention_mask → BERT编码器 → CLS向量 → Dropout → Linear分类层 → 10类logits训练时使用交叉熵损失通过AdamW更新参数并在验证集上计算Accuracy、Precision、Recall和Macro-F1保存验证表现最好的模型。四、训练与验证训练循环需要明确区分 model.train() 和 model.eval()。验证阶段使用 torch.no_grad()避免构建梯度图降低显存占用并提高推理速度。optimizer.zero_grad() logits model(input_ids, attention_mask) loss criterion(logits, labels) loss.backward() optimizer.step()五、BadCase分析只看总体准确率无法说明模型是否真正理解业务边界。工单任务中常见的混淆包括system_error 与 payment_issue“支付页面报错”同时包含支付和报错。system_error 与 data_exception页面打不开与数据内容错误属于不同问题。product_consult 与 feature_request询问现有能力和要求新增能力边界接近。原始类别与 complaint用户既描述故障又强调多次未处理和投诉。优化时应检查原始文本、真实标签、预测标签和模型置信度判断问题来自标签规范、样本不足、模板泄漏还是模型能力。六、模型保存与推理最佳模型保存为本地权重文件预测时必须使用相同的模型结构、Tokenizer、类别顺序和最大长度。GitHub只保存训练和加载代码不直接提交数百MB权重。七、下一步BERT效果提升后还需要解决模型体积和CPU推理成本。下一篇将继续对比动态量化、非结构化剪枝、知识蒸馏和LLM分类并将模型封装为Flask接口。