心法利器[16] | 向量表征和向量召回

【前沿重器】

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

往期回顾

• 心法利器[11] | 任务方案思考：文本分类篇

• 心法利器[12] | 任务方案思考：序列标注（NER）篇

• 心法利器[13] | 任务方案思考：句子相似度和匹配

• 心法利器[14] | 任务方案思考：人工特征机器学习

• 心法利器[15] | 准招分治效果调优方案

• 20->21：算法工程师的成长思考

最近公众号里面聊这个向量表征和向量召回比较多（例如近期阅读量不错的前沿重器[7] | 小布助手登顶百度千言短文本相似度的秘诀），有不少人问了这方面的细节，而现在大部分的论文和文章的确是都绕过了这里面的很多细节，或者说的确只会将其中的一两个细节展开讲，没有接触过的人很难理解整块的逻辑和具体使用方法，这次来给大家聊清楚，这整块是怎么落地实施的。

背景和需求

其实向量召回本质上是一个搜索问题，传统搜索本质上使用的是文本的搜索，经常是做一些query，提出里面的关键词然后在数据库里面搜，这种文本层面的召回泛化能力终究有限，为了解决一些同义词、特别说法、纠错的问题需要话费大量的时间精力，另一方面，类似推荐领域，要衡量用户和物料，靠显式的用户画像同样是有限的，接着深度学习发展的东风，有人开始尝试想把query、用户、物料进行抽象表示，然后进行匹配计算相似度，来提升无论是搜索还是推荐的泛化能力，向量表征和召回应运而生。

用户、query、物料，均可通过一定的手段，转化为特定的表现形式，这个表现实行不见得是显式地体现具体表征对象的特征，而是难解释、却能精准表现对象性质的一些形式，这种表现形式可以存储到数据库中，然后再被查出来，甚至能做一些计算，这整个过程就能走通了，而向量就能把这整个过程打通，这里实质上就是两个核心技术，向量表征和向量召回。

我分为角度来阐述这整套技术方案：逻辑架构、算法、工程。

逻辑架构

整套逻辑架构主要分为两个模块，离线和在线。

离线的任务有两个：

• 训练模型，这个模型的目标是能把特定的一个query、用户、物料表征成一个向量，这个向量能体现表征对象的特征。

• 利用这个模型，把需要入库待查的东西，如智能问答的标准query、协同过滤用的高频用户、待召回的物料转化为向量，并存储到向量召回索引（或者说数据库）中。

在线的任务是3个，但其实一般地向量召回索引工具能一次性完成2个，所以说是2个任务也行。

• 用户请求来了，可能是query或者是用户信息，此时把它用离线训练好的模型转化为向量。

• 将这个向量输入到数据库里面，数据库内自动找出与之最接近的向量，再把库里面的item找出来返回给用户。

• item根据相似度进行排序。

任务说清了，现在来将一个例子吧，看看具体逻辑是怎么执行的。来举一个场景，智能问答，业务方会构建一个知识库，有标准问和标准答案，现在我们希望给定一个用户query，能找到知识库里面和这个query最接近的标准问，然后把答案返回出来，这就是技术需求，那么实现逻辑就是这样的：

离线：

• 训练一个语义相似度表征模型。

• 用表征模型预测每一个知识库内标准问的语义向量。

• 将语义向量入库，即存到向量召回数据库中。

在线（来了一个query请求）：

• 用上面训练的表征模型预测query的向量。

• query向量输入到向量召回数据库中，召回用户query相近的标准问。

• 根据相似度完成粗排。

算法

作为算法，我们需要聚焦的肯定就是这个表征模型了。要用表征模型，先来看看他怎么用的：

• 离线，需要推入库的物料进行预测成向量，根据向量进行入库。

• 在线，将query或者用户信息整成向量，请求数据库找出最接近的物料，并按照相似度排序。

因此这里其实有两件事，预测物料成向量，预测用户信息成向量并计算相似度。一般情况下，我们用交互式的模型能有比较高的准度，但是预测物料的向量和预测query的向量这两步是分离的，这就要求我们只能用表征式了，说的专业点就是孪生网络了：

双塔

这是一个完整的双塔结构，涉及两个输入，input1和input2，在搜索或者对话里，就是query和索引问，在推荐系统里面就是用户和物料，他们之间计算匹配度，我们分两个阶段，训练和预测。

• 训练阶段，我们通过标注数据或者是用户的点击数据，挖掘到intput-input2-label形式的样本，有了这3者，就能完成这个模型的训练，即里面的network1和network2。

• 预测阶段，离线我们有标准问或者物料，假设就是input1，此时我们就用network1来进行预测，此时的预测只能拿到input1的输出，这个输出是向量，就可以加入到向量索引中；在线则是请求过来的用户query或者是用户信息，假设就是input2，此时可以用network2来预测，同样得到向量，这个向量可以请求向量索引库，达到与之最接近的向量，从而我们可以认为是查找和input2最接近的input1。

此处有几个注意点：

• input1和input2通过各自的network得到表征向量后，需要进行相似度计算，这个相似度由于索引工具、便捷性等原因，我们往往选择余弦相似度、欧氏距离等简单形式来作为相似度衡量的方案。

• network1和network2的结构可以相同也可以不相同，权重可以共享也可以不共享。一般如果input1和input2性质相同，可用同一种形式表征的时候，例如都是query，那就可以共享权重，即用network1和2是同一个，这里的共享不是指计算机交互矩阵之类的交互操作，只是在预测阶段有些积木可以共用而已。

至于具体的模型是啥，其实就是一个搭积木的问题，也和具体输入的内容结构有关，NLP领域的话就是word2vector开始，接上CNN、LSTM甚至是transformer encoder之类的操作，推荐系统则有一个更复杂的、结合特征性质的一些方案，大家可以根据实际领域来选择自己合适的积木组合。

工程

有了逻辑架构和算法的铺垫，工程其实就比较明确了，当然也会变得有些琐碎，我们一个一个来。

代码结构上，势必是至少要分为两个大模块的，离线和在线。

• 离线负责数据预处理、数据集构建、模型构建、模型训练、物料/索引问的向量预测、索引构建入库的核心操作，当然一些定时、日志、监控、校验等其他离线任务也会有的工作。

• 在线则有query/用户的向量预测、向量召回的工作，当然也有日志、监控、热更新、服务等其他算法服务也会有的工作。

很多工作其实都比较明确，其中有一个比较模糊的应该就是，向量召回的问题了，即给定一个向量，如何找到与之最接近的向量，这个问题的专业说法叫做最近邻问题，首先我们可以明确的是，由于库非常大，我们是没有办法针对给定的query，对库内每一个入库条目都进行相似度计算的，这个复杂度非常可怕。但这个东西其实我们并非没有见过，大家可以翻翻统计学方法，在这本书的KNN那一章后面部分提到的k-d树，就是很经典的一种最近邻相似方法，当然这个并非当前的最优或者流行的方案，annoy、hnsw等，都是非常流行的方式，而且都具有开源项目和工具，非常方便，在线的话也有支持分布式的向量召回工具，包括老牌搜索引擎工具ElasticSearch和facebook开源的向量召回工具faiss。

小结

向量表征和向量召回整块其实是一个非常常见的算法项目工作，但很可惜很多文章和论文都只是讲了其中的局部，对于没有接触过该项目的人其实会有很多地方理解可能会有些苦难，所以我把整体串讲了一遍，由于是串讲因此我不展开了，里面涉及到的一些技术细节，我都提到了名词，大家可以根据自己的需要按图索骥。