心法利器[57] | 文本多分类问题经验

心法利器

本栏目主要和大家一起讨论近期自己学习的心得和体会，与大家一起成长。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。

近期，我再次总结了我的历史文章，累积起来有50w字，百余篇文章了，有兴趣可以拿来看看，获取方式：七夕清流，百余篇累计50w字文章合集发布。

往期回顾

• 心法利器[52] | 口语化句子解析问题

• 心法利器[53] | 数据增强的现实应用思考

• 心法利器[54] | NLP任务上线前评测

• 心法利器[55] | 算法工程师读论文思路

• 心法利器[56] | 算法技术设计思路小结

最近是正好做一些文本多分类的工作，快到尾声了，所以总结一下这里面可能会面临的坑和经验吧。在整个过程中，其实我发现，绝大部分问题都不是模型的问题，模型的发挥很稳定，更多问题是在数据和标准上，所以本文其实聊的模型不会很多，更多是一些细节上的微操处理。

问题背景

文本分类本身是一个非常经典的问题了，各种方案也非常成熟，然而到了实际场景其实很多问题在我们日常学习可能很难接触到，多分类，尤其是超多分类这就是一个非常常见的问题，当分类的个数达到质变后，很多通用的方案的有效性其实未知，整个pipeline也都有可能会产生变化，这里，给大家聊一下文本多分类中可能出现的难点和解决方案吧。

主要的解决方案

说到文本分类，很容易想到一些常见的baseline模型，小型的有fasttext、textcnn，比较激进的可以尝试预训练模型文本分类方案，论基线，相信这块已经非常成熟了，网上甚至能找到开箱即用的代码，自己动手，丰衣足食，数据整理好以后，直接放入就能整了。

我的答案是，对于多分类的问题，这些方案还能用，但是我们并不能局限在这些方法里，要看到整个问题里的更多细节，要根据实际情况对我们的方法进行调整。

多分类问题的特殊难点

然而，如果只是把这些方案堆砌就能把问题解决，我们应该也很快会失业。我们要面临的，是一些通用方法下很难通用的点。下面是我遇到的问题以及常见的解决思路。

外部问题

有的时候，问题并不来源于问题内部，而是外部的问题，其实我想说的就是一些标准和数据的问题。

首先，由于类目会比较多，甚至极端的，类目多到十几二十类，甚至是更多的时候，类目体系的确定会非常困难，主要难点就在于边界的确定和界定，例如电煮锅算电器还是厨具，甚至可能有多标签，这种边界的模糊问题会传导到数据的标注上，随之而来的就是模型的训练和评测集的问题了，一旦数据不靠谱，再好再差的指标似乎都没什么代表性了。

其二，就是标注问题，虽然可能有很明确的指标体系了，但是对于标注人员来说，这无疑是一个巨大挑战，首先，我要熟悉这些类目的边界，其次，我还需要对每一个句子要分析出哪个类最好，这个难度其实比二分类来说难度大很多，这个也是影响数据质量的一个关键因素。

对于这种问题，本身其实不是模型的问题了，更多是前期的标准沟通和后续数据质量的把控问题，一方面，我们需要通过case分析和特定的数据指标来发现（后面会有一章聊到），另一方面是我们可以通过一些算法baseline，给出一些模型预测的建议，或者是通过多人标注之类的方式，给到定标准的产品、标注同学更好的标注建议，帮助他们更精准的标注和分析。

内部问题

内部问题其实就回归到算法内部了，在标准合理，数据质量足够的情况下，也并不代表模型套进去就能有很好的结果了，模型问题、数据结构的问题、样本分配问题之类的其实都有大量的学问和经验在里面。

首先是数据不均衡的问题，在类目逐渐增多的情况下，每个类下的样本其实非常不好控制，长尾效应非常明显，甚至有些类目压根就没数据（这时候还是要定向自己构造一些的，哪怕自己编几个），需要构造一些，众所周知，数据不均衡对预测的影响还是不小的，所以我们需要一些平衡的手段。有关数据不均衡问题，其实我之前已经做了相对完整的讨论（心法利器[44] | 样本不均衡之我见），大家可以参考这些文章找到问题根源和解决方案，方法和思路其实很多，列举一下：

• 简单的数据增强、正负采样、focal loss。泛化能力不足的情况下，分布过于不均匀的情况，可以这么做，属于锦上添花的方案。

• 当做few shot问题来解决，对长尾数据不足的类目，会有些提升。

• 信息的完整性问题，有的类目就一两条甚至没有的话，上面的方式几乎都哑火，毕竟给到模型的信息不够，怎么都解不了。此时可以通过修改类目体系，自编数据，或者定向挖掘来获取。（极少数据的情况下，是不足以给模型描绘分类边界的，这个对人类的世界认知能力是类似的）

• 可以考虑用以搜代分的方式来对长尾，数据量比较少的类目进行处理的，具体操作细节可以看看这个文章：。

其次是数据少的问题，上面的类目不均衡的问题里，其实已经多少提到了，其实数据不均衡的问题大都都会对样本量比较少的类目进行一些处理，而数据少则是针对特定类目甚至是整体数据就比较少的情况，数据不够，模型肯定是吃不饱的，这个应该是做算法的各位都有的常识，那怎么解决呢？

• 自造数据，通过用户点击、物料库、关键词拼接甚至人工编辑的方式进行构造。

• 考虑其他形式的信息输入，例如词典等。

• 数据增强之类的，在有一定基础数据，多样性稍微可以的情况下，可以考虑试试。

• 数据的复制和训练策略调整，对数据量少但是重要的类目，可以考虑在每个batch内都增加这种样本，保证一定能学到。

• 在loss里面进行调整，对数据量低的多给一些权重。

这里其实会看到，我们在肆意地对训练集的分布进行调整，而并不关心他和测试集分布的一致性问题，因为测试集是为了验证模型或者方案在真实环境的效果，所以他需要和真实环境尽可能接近，而训练集，只需要让测试集的效果好而已，训练集分布和测试集就分布一致能不能对效果有收益这点并没有严格逻辑绑定，这点我也在之前的文章里有聊过（心法利器[49] | 数据分布的含义理解）。

第三，就是类目的混淆，随着数据量和类目增加，内部多少有一些非常容易混淆的情况，这些情况可以通过混淆矩阵观测出来，观测出来后，我们可以在样本层面增加一些hard case，例如手动增加，或者是看看训练样本的质量来做一些微调，都会有不少收益。

第四，但其实非常重要的是，要把控好测试集的质量。如果测试集里面有很多错误，那么我们算的所有指标都可能是不对的，我们要多去进行case分析，经常把控，才能发现问题，一定一定要养成这个习惯，具体这个问题发现了后，就当做是上面我聊的“外部问题”来解决就好了。

分析和观测的方法

多分类相比二分类，其实要观测的东西会多很多，我们设计足够多的观测点和分析思路，有利于我们更快发现、定位和解决问题。

指标

首先就是指标，为了确认我们算法方案的效果好坏，统计指标是非常重要的，这块的设计也是一门学问（挖个坑），在多分类里，我们要看的指标其实还是相对面明确的，就是准招，precision、recall和F1，多分类基本看不了AUC了，但是这块，其实我们也可以拆分很多角度来看，能发现很多问题：

• 加权or非加权，加权的会关注高频的类目，在业务上其实大家也更关心这个，非加权会更关注长尾的、困难的case，一定程度代表了目前算法的下限。

• 总体和分类目。总体的指标更倾向于对算法效果的定性，但是我们还需要关心每个类目的准招，我们能快速发现算法的短板，哪些类目预测不好，是标注问题、样本量问题还是什么原因，我们可以给出一些对类目的针对性优化。

• 混淆矩阵。混淆矩阵体现的是整个类目体系下一些容易混淆的位置，也就是模型拿不准的位置，这个可以通过混淆矩阵看出来，看出来以后，我们可以通过构造一些hard case的方式来进行优化，充分告诉模型他们的边界在哪，同时，如果类目的划分有些问题也能及时调整。

case分析

也有了上面的指标，我们能很快定位出一些短板，根据这些短板，我们能有针对性的进行一些case分析。

• 如果总体指标效果不好，其实我们直接从总体抽case进行分析即可，特别的，如果是加权的指标不足，可以看看高频的query和类目。

• 对于特定效果不好的类目，可以先看看是测试集不足还是类目确实分的不好，对于前者，如果是重要类目，那肯定就要加样本了，如果是后者，那就是要分析测试集，看重点问题在哪里。

• case分析时，需要主要看各种问题的分布，要多分析一些，看重点问题在哪，例如是标注问题、样本不足问题、知识缺失、样本均衡问题等，统计出具体问题的个数，然后根据比例针对性解决。

有关case分析，之前也一连花了好几篇，给出了我的解决case分析方法论，最后一篇在这里：心法利器[40] | bad case治疗术：解决篇。