一篇旧文。

总结

初赛

第一次接触NLP问题，初赛时间较为充裕，而Bert处理短文本性能足够。应尽量尝试多种可行方式解决问题，而不是只拿着Bert跑无意义的结果。

复赛&决赛

  • 复赛阶段数据量大，试错成本更高，完全应该进行大的改动再重新迭代。
  • 数据处理和基础模型没有大问题，但是完全忘记了在提交结果阶段使用集成学习方法。
  • 没有对长文本进行进一步处理，取首尾截断不如训练两个模型分别处理首尾之后再进行投票。
  • 程序总是有Bug，一个on_epoch_end的问题就是九个小时左右时间的浪费。
  • batch_size/model 过大，训练时无法测试
  • 虽然做了客服标记的统一化，但是标记本身是否正确未可知。
  • 复赛阶段工作量预估不足。

其他

  • 文本是机器翻译得来的， 可以进一步处理。（将方言转化得到的无意义的同音词替换为行业高频用词是一个好方向）
  • 或者将对话双方文本分别训练也是一个方向。
  • 长文本甚至可以做一个摘要生成的模型来处理成短文本。
  • BiLSTM+Attention机制没有做完，或者在BiLSTM各时间步上隐层上取Max做输出，在其他数据集上效果均优于直接使用BiLSTM。
  • 梯度累加变相增大Batch_size的实验没有做完，新建Module类可以解决loss和原计算图无法关联的问题。（较小的模型比如共享参数的TextCNN可以做到256的batch_size，16倍于bert方法）
  • Bert本身没有问题，但是训练用的语料不同效果不同，也可能影响最后效果。

后续应用

  • 落地方面思考不足，自然语言处理工作在客服对话上可用的有：

    1. 投诉分类（将和故障高度相关的投诉分类抽取，设置告警（一个问题是误告警怎么闭环处理，没有进行一个较好的回答）
    2. 多分类，客户可能存在多种需求，单个标签描述不便（程序上改为输出层sigmoid激活，使用二元分类损失，按每类概率>0.5取对应标签。
    3. 不局限于分类，语义理解聚类客户诉求、根据对话方式进行用户分类匹配客服、为什么会出现长对话（话术提炼、优化效率）。

  • TensorRT推理速度有极大提高（成百倍500ms->2ms），可以尝试。