心法利器[29] | 把文本分类任务做成一个系统

心法利器

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

往期回顾

• 心法利器[24] | 以pytorch为例看我怎么自学新技术的

• 心法利器[25] | 如何做技术设计

• 心法利器[26] | 以搜代分：文本多分类新思路

• 心法利器[27] | 人工智能技术创新大赛决赛随想

• 心法利器[28] | 如何评估一个算法效果

有关分类的思路，我之前有完整的分享（心法利器[11] | 任务方案思考：文本分类篇），而最近我也提到过一种快速应对多分类的方法——以搜代分（心法利器[26] | 以搜代分：文本多分类新思路），总之分类的方法是多种多样的，然而在现实场景，尤其是一些开放域的产品，如大搜等，经典的文本分类可以让我们快速处理一些比较精准的意图，以搜代分又能处理比较长尾的意图，但是简单使用他们可能又太过简单，不能完整满足丰富而又复杂的分类需求，他们具体怎么协作来成一套更为完整的文本分类任务呢，本文就是来和大家讨论这个分类系统的问题。

问题和具体场景

说具体方法之前先说下场景吧。

相对开放域的搜索，在有比较初步的物料后，都会选择使用检索的方式快速完成初版本的设计和上线，但是随着逐步迭代发展，要对特定品类或者意图进行更为精准的设计，此时就需要把需要精准设计的模块挑出来，例如要做好天气，要做好电影电视剧，那就要从众多分散的query中找到，此时就需要对这个模块多足够精准的分类和拒绝，从而达到精细设计的效果。

例如产品最近要做一个天气类目的模块，即在用户输入天气相关的query的时候，能给用户返回天气的卡片，带有温度、湿度、是否下雨、天气指数等，为了下游精准的展示，我们就需要用专门的分类把天气意图的query从海量的用户query中挖掘出来，在本文，我要讲的分类系统，就是指这件事。

然而，哪怕是简单的一个天气技能的识别，也不是一个简单的事情，这可不是简单的“今天天气怎么样”而已，还会有“北京明天的天气”、“明天要带伞吗”、“这周六需要穿毛衣不”之类的，可能都会属于天气（最终是否属于，要看场景和实际产品需求），这里面就有大量的复杂情况，文本分类是否能覆盖，这就不太好说了。再者，还有类似“天气之子”、“下雨了我好难过”这种可能比较边缘的识别难题，让分类就变得非常困难。

分类系统的设计

方法盘点

有关分类的方法，其实我在之前的一份总结里面有提到一些常用的分类思路，结合以搜代分的思想，我们可用的工具很多，我们需要的是把他们结合现实情况有机组合起来，从而让我们把一整个完整的分类任务给做好。首先我们还是先来盘点下我们主要的分类思想，从简单到复杂地依次排列。

• if else规则。最简单粗暴的方式，能快速解决最直接明显的case。

• 词典。最强的干预方法，黑白名单加上热更新能灵活处理各种情况，同时对于名词性比较强的分类效果也很好，但前提是这些名词能够挖掘得到。

• 文本分类。应该是现在研究的主流，也是大家最容易想到的方式，这种方式的优点就是泛化能力强，在有足够数量和质量样本的情况下，我们就能构造出分类模型。

• 搜索。通过构造搜索集，然后通过搜索的方式完成分类。这种方法很适合处理长尾的情况，同时对于多语义空间簇的情况，可能要多个文本分类才能搞定的任务搜索只需要堆一些检索query即可完成。

方法很多，现在我们需要的就是把他们有机地组合在一起，完成这一整个完整的分类系统。而在开始之前，我们还是要看看我们需要做的分类任务，都是什么类型的，所谓的因地制宜，就是要熟悉问题后给出针对性的方案。

问题分析和思考

道理都懂，为了解决问题，我们需要分析问题，但具体怎么分析，其实非常模糊，我暂时也很难给出一套很完整的方法论，但是一些思路和建议还是可以和大家谈谈，而在谈的过程中如果有什么建议欢迎提出和交流。现在来回答我这几个问题：

• 数据：

• • 当前已有多少数据，质量怎么样。能否进一步挖掘到多少，难度咋样。

  • 是词典数据还是query类的文本数据？

  • 样本的语义空间是什么样的，大部分是否非常集中或者非常零散。

  • 覆盖应用场景的量怎么样。

• 应用场景：

• • 性能需求和硬件需求。大模型、大辞典可能因为性能原因用不到。

  • 该分类的名词性质怎么样，是否需要足够的名词信息支撑。类似音乐、电影之类的，名词类的模型会比较难学到。

  • 需要的泛化能力如何，例如如果是口语化的，那需要的泛化能力就要比较强，泛化能力需要来源于模型，无论是分类模型还是搜索用的语义匹配模型。

  • 需要的更新频次怎么样。定时更新的频率会比较高的，更新频率高的部分用文本分类会受到限制。

上面这些问题的思考和回答，本质上就是在对应上面的每个方法，将问题和方法所对应起来，就能够设计好这些问题了。

开始设计方案！

有了上面的铺垫和思考，我们就可以开始设计方案了，首先我们思考的核心应该是，什么样的分类才更加契合我们的场景。来说几个比较突出有特色的场景，供大家理解。

电影类

任务是要区分用户是否是搜电影相关的意图，看看case基本都是“钢铁侠”、“战狼”之类的，顶多就是“我想看大圣归来”的泛化句子，而且这种句子更新的还挺频繁，新电影上映我们就要更新了，甚至会有“唐人街探案”这种电视剧、电影，甚至还有一些还有小说同名的意图，这种很不好做，最基本的方式应该就是维护一个定时更新的词典，借助这个词典做匹配就能够轻松完成文本分类。

当然的，如果有一些比较泛的需求，例如“给我来一部恐怖电影”，这种没有具体的电影名，则更加推荐使用模型来做分类了，毕竟话术比较模糊，泛化需求比较强，同时名词性质没有上面那种情况那么强了，此时这样设计会更加精细化。

知识问答类

知识问答类应该是最复杂的一种类目了，识别用户是不是在问一个“知识问题”，可以理解为用户是不是想问一些知识点，这种更适合出百度知道或者百科，这个领域非常广泛，但又十分零散，而且在一些小的方面，还可能会和意图打架，例如娱乐明星等人物介绍之类的。所以我们需要很小心地做好这套城墙。我给的方案和思路是这样的：

• 知识问答往往会伴随知识库，知识库是非常容易使用以搜代分的。

• 注意构造拒绝词典，开放域十分容易和其他意图出现混合，对于一些其他意图可能处理更好的query，我们要有特定的手段进行拒绝，而最好的方式就是词典。

• 对于一些比较模糊的泛需求，可能会由于知识库覆盖率问题而无法召回，此时我们可以用一个相对比较弱，但是有高准的文本分类兜一些回来。

天气类

天气类是我自己很喜欢举例子的一类，因为这一类里覆盖了很多分类需要面对的情况，咱来聊聊。

首先比较高频的应该类似"今天天气怎么样"之类的问句，词典可能成本比较高，文本分类可以一劳永逸，毕竟变动其实不会很大，当然觉得要灵活一些，以搜代分的形式也可以，后面召回不够可以再加。

然后还会有一些特定的疑问场景，类似"北京的天气"，"这周末杭州会下雨吗"之类的，可以结合槽位、词典来做转化，例如转化为[city]的天气然后来分类，这样接着做更简单。

但是，这并没有完，我们还是要做一些拒绝的工作，否则类似“天气之子”，“下雨天”这种名词性质的，其实是电影之类的，我们可以用词典做一些拒绝，即匹配到了就拒绝掉，肯定是负类。

多分类和排序

在大搜等开放域的场景下，我们需要对特定细节场景进行精细化管理和优化，文本分类就是进入各个细节场景的大门，于是多分类就成了一个关键问题，上面提到的是一些案例和思路方法，这里需要给大家讲几个比较关键的技术细节。

拒绝能力

多分类场景，很多query很容易就会产生所谓的多意图，此时我们就需要选择，甚至在一些场景下我们只能出一个的时候，我们只能选一个，最简单的方式就是使用一些拒绝策略，保证特定情况下我们不能出。

拒绝是一个灵活的需求，可能需要随着瞬息万变的在线情况进行随时的更改，所以一般是使用词典的形式完成，对高频的、新热的，如果有搜索库的话，可以加到检索库里面，如果匹配到了，则直接拒绝。

另外，拒绝本身也是一个提升性能的策略，用词典、关键词之类的方式过滤掉一些“肯定不属于”的query，由于这些方式性能很高，而且绝大部分情况应该是负类的话，这种拒绝对性能的提升就是个质变了。

排序

多意图势必会出现排序问题，通常下游会有一套非常完整的排序体系，本期篇幅有限我没有完整地聊，但是这的确是非常重要的，在应对多分类的问题上，简单的拒绝可能让我们的灵活性降低，所以我们可以在分类的过程中下放一些多意图的query，而不是直接拒绝。

举个例子，明星问答和百科可能会有重合，如果是有些明星的答案在明星问答中不存在，那就可以由百科来兜，此时我们就可以在明星问答和百科中都识别为正类，排序的问题交给排序模块。

小结和思考

在开放域里，分类问题并不是就那么简单了，我们需要根据场景特点，构造完整、可靠的分类系统，来尽可能完整地实现高效、精准的分类。回顾一下，我们需要的主要是两个关键点：

• 手里有足够多的方案选择，并且对这些方案的优缺点有足够的认识。

• 对问题也有足够的理解，知道问题有什么特点，可以用什么方式应对这种特点。