本文探讨了将检索方法应用于文本分类的思路，通过建立检索库，利用KNN思想找到最相似的query进行分类。这种方法需要充足的备选query以覆盖各类目，适用于类目有限且易于枚举的场景，优点在于可控性高、准确率不错，尤其适合多分类和快速上线需求。但缺点是需要足够的样本，对大类目覆盖率要求高。
【心法利器】
本栏目主要和大家一起讨论近期自己学习的心得和体会，与大家一起成长。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。
往期回顾
检索和分类，某种程度上是相通的，大家细品，对于一条query，我要把他划分到一个类目上，这就是分类，对一条query，我要在众多回复中找到最适合他的一种，这就是检索，说白了都是一个“选择”的过程，在这个抽象理解上，我们其实可以用搜索的方式来替代常用的文本分类方法去解决这种问题。
我也借此机会给大家介绍下我对方法学习的主要思路，我下面的讲解也是按照这个思路去走的：
核心思路。了解这个方法具体是怎么做的。
深入讨论和理解。知其所以然。
特点和优缺点。优缺点是方案选型的重要依据，借助对方法的深入理解即可了解方案的优缺点。
适用场景。这个方法借助优缺点提炼适用场景，从而实现方法选型。
核心思路
多分类问题的需求是对给定query找到最适合query的一个类。以搜代分的核心思路是，挖掘得到每个给定分类中，最具标志性、覆盖较为完整的备选query，例如体育话题下的篮球、乒乓球、羽毛球、田径赛事标题，军事新闻下的飞机、大炮、航母消息等，把他们统一存入检索库中，检索可以是传统的search切词倒排索引模式，也可以是泛化程度较高的语义向量索引，在准备好以后，就可以开始分类，给定query开始在检索库中找库内和他最接近的备选query，然后认为query所在的分类就和这个最接近的备选query一样。
好了讲完了。是不是觉得有点懂又有点不懂，我来细化一下吧。
准备阶段
一般的文本分类，都是给每个类准备一些文本，准备开始进行训练，检索方法的分类也是如此，所以下一步。
处理入库
一般的文本分类，都是开始拿着自己喜欢的文本分类模型开始进行训练，而检索方法则是会经过处理和信息抽取，然后放入到检索库中，这个大都可以分成两大思路：
切词，然后做倒排索引，这个和传统的文本检索是一样一样的。
现在比较潮流的做法就是把文本转化为向量然后做成向量索引。这个可以看我这篇文章：
对于向量检索，还有一点需要强调的是，这里依赖一个比较可靠的语义相似度模型，而且是表征式的，这块可以参考我之前的一些文章：
开始预测
一般文本分类的模型训练完就可以开始预测了，而检索方法亦然。给定一个query，开始进行搜索，向量也好文本也罢，通过检索可以得到一批和原始query相似的结果，经过一些规则和重排，即可得到与之最接近的query，从而得到他的类，这就完成了分类。
深入讨论和理解
应用场景思考
来看看检索式对话是怎么做的。库里面有很多的question-answer对，现在给定一个query，要找到一个与之接近的question，然后对应的answer返回。现在，我们可以把每个quesiton看做一个类，实质上就是对query进行分类，看这个query是否属于这个question的，如果属于那就可以用这个answer回答。
再次讲，其实检索本身和分类具有非常强烈的共通性，这种共同性能让我们用搜索来解决分类问题。
经典的KNN思想
机器学习的经典著作——《统计学习方法》的第一个模型就是KNN，很多人可能觉得这个方法非常low，但是究其实质，其实他是支撑整个检索技术的核心理论基础，甚至覆盖了检索式对话等多个领域，KNN的实质就是，在索引库中找到与之最接近的N个样本，看着N个样本大都属于什么类，那他就属于什么类，这不就是我说的以搜代分嘛，只不过这个接近我们定义为语义相似度或者文本相似度，这个检索我们用倒排索引或者向量索引而已，《统计学习方法》中介绍了KD树，也是一种非常经典的最近邻相似查询技术，现在的ball-tree，到现在的hnsw、ngt等都是他后面发展的。
检索空间的覆盖度问题
一个比较尴尬的问题，如果这个query就是属于某个类，但是由于某个类的备选query由于数量不够等原因并未覆盖，那就可能导致qery没法被这个来类召回，例如音乐，库里面没有周杰伦的《七里香》，就很难召回这首音乐了。这是一个特点，不完全是缺点，原因按下不表，我后面会说。
特点优缺点
刚才说了特点，一个最鲜明的特点，就是这个方法需要让每个类下的备选query能覆盖这个类尽可能多的情况，这就意味着，我们要有足够多的query来让这个类更加充实，表面上这是个缺点，但实质上对于某一些类其实是优点，甚至是多个有点，首先，对于一些比较小的类，例如天气，其实只要把几个特定的放入备选query，这个技能可以轻松解决；其次，对于一些变化比较大的分类，例如新闻分类、黄反识别，可以通过备选query的上下线来处理实现这个功能，说白了就是干预能力。
第二个特点就是，把文本分类问题实质上转化为一个只是比较通用的相似度问题，这个相似度是如果是文本，其实就是类似BM25之类的操作了，可以是比较无监督的方法，当然走语义也可以用相对通用的模型来做，这个相比端到端的分类模型，可能需要用到训练样本更少，而且准确率还更容易更高。
第三个特点来源于第一个特点，既然用query就能覆盖分类，那我就可以通过加备选query完成很多个分类的配置，从而实现多分类，从检索式问答当前的落地状态来看，甚至可以支持甚至达到十万级别的分类。
因此，整理下来这个方式的优点是：
对于简单覆盖的分类，可以挖掘到对应类目的各种query来作为备选query来实现分类。
可控性强，准确率高。
语义相似度模型的构建相对简单，可以用外部数据进行训练，不需要领域内标注数据。
超级多分类的处理存在空间。
但是也有缺点：
需要足量的备选query才能够实现较为精准的预测，缺少的话会影响召回。
从数量上优点挺多的，好像还挺好，但是事实上缺点如果出现是非常致命的，对于一些比较大的类目，例如音乐之类的，没有资源是很难可以覆盖完整的，不建议使用。
适用场景
说到适用场景，有了优缺点分析的基础，我们其实很容易得到一些方案选型的思路，来看看以搜代分类的适用条件吧：
类目下的情况比较少，可以枚举，或者有一些比较明确可靠的数据集。
不太好构造分类的训练样本。
需要快速上线，时间比较紧，只有一些样例query。
分类超级多，容易混淆，长尾的数量表也不少。
另外有的时候，对于类目比较多的文本分类，我们可以把问题拆分，部分高频的可以用普通的文本分类来处理，对于长尾的，文本分类多分类其实很难处理，很容易学不到，因此就可以用文本检索的方式来处理就会很轻松。
小结
以搜代分类，其本质的思想其实和词典匹配很类似，只不过相比词典匹配而言这个说法的外延更广，在日常的应用中这个方案也可以为大家提供一些思路。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
