以下文章来源于爱奇艺技术产品团队，作者爱奇艺举荐中台

随着深度学习浪潮的衰亡，embedding 技术疾速倒退。Embedding 本身表达能力的加强使得间接利用该技术生成举荐列表成了可行的抉择。因而，利用 embedding 向量的相似性，将 embedding 作为举荐零碎召回层的计划逐步被推广开来。

在理解 embedding 生成的罕用算法模型之余，对于举荐零碎的实现而言，理解其工程化实际也十分重要，本文将介绍在线向量召回服务在爱奇艺的工程化实际。

背景综述：深度学习的衰亡

举荐零碎的架构已在多本书籍与多篇文章中被提及，而较为经典的流程形容之一如图 1 所示。从图中咱们可知，一个举荐服务包含几个模块：举荐池、用户画像、特色工程、召回、排序、策略等。整个举荐流程中，召回处于整个环节的第一环，它从整体内容池中圈定了一个子集，供举荐零碎从中再择优吐出至用户背后。从这个角度而言，召回候选集的好坏，从很大水平上决定了举荐的整体好坏，召回的重要性也就显而易见。

图 1. 举荐零碎的技术架构示意图

对于召回而言，有不少耳熟能详的办法，常见模型比照如下。

咱们能够看到，模型的一直更迭，都是为了能增强特色组合与抉择，以及整体泛化能力的强化，而随着深度学习浪潮的衰亡，这些问题又进一步被推动，深度学习能够使得模型同时具备记忆能力与泛化能力。

⚠️ 注：记忆能力能够了解为模型间接学习并利用历史数据中物品或者特色的共现频率的能力；泛化能力能够了解为模型传递特色的相关性，以及挖掘稠密甚至从未呈现过的罕见特色与最终标签相关性的能力。

深度学习的风行与 embedding 技术的倒退，使得 embedding 具备了 综合信息的能力强、能将高维稠密特征向量转换成低维浓密特征向量、能通过向量运算揭示内容及用户类似度等特点。embedding 自身也是极其重要的特征向量。embedding 本身表达能力的加强使得间接利用 embedding 生成举荐列表成了可行的抉择。因而，利用 embedding 向量的相似性，将 embedding 作为举荐零碎召回层的计划逐步被推广开来。以下图 2 是 YouTube 举荐利用 embedding 进行候选物品进行召回的做法。

图 2 YouTube 向量召回模型结构图

对于 embedding 的算法模型有很多，如对 embedding 具备奠基性意义的 Word2Vec，基于 Word2Vec 在举荐畛域推广进去的 Item2Vec，亦有狭义的 Item2Vec（如 DSSM 双塔模型），也有引入了更多构造信息的图嵌入技术的 graph embedding（如 DeepWalk，Node2vec，EGES 等），其对应的实现也有较多论文与文章讲述，因而本文中咱们对算法模型不再过多讲述，而是将焦点置于工程上如何能疾速部署在线向量召回服务，并能让举荐引擎在线上高效拜访，也就是图 2 的工程化落地实现。

在线向量召回服务化实际

1. 效率是第一生产力

在业务开发中，作为工程师都晓得，繁多服务于某个业务与同时向多个业务服务，所要思考的点是有较多不同的，后者须要更多的形象与通用性，而这也是举荐中台要解决的问题，只有这样，能力晋升服务搭建的效率，解放人力用于更多的业务思考当中，而不是反复工作。

在一个举荐零碎的研发过程中，往往须要算法工程师与零碎研发工程师的严密合作，前者的职责是基于业务实现可用的算法模型，而后者的职责，一者是协同算法工程师将模型封装服务化，二者是开发举荐引擎及其它依赖子服务将整个举荐流程进行串联，供上游调用举荐接口，如图 3 所示。

图 3 举荐零碎工程师的个别职责划分

如果咱们基于图 3，来看向量召回服务的接入过程，将会失去图 4 的后果。算法工程师将基于业务特点，进行算法编写并产出 embedding，同时，零碎研发工程师和算法工程师将合作搭建起在线的向量召回服务，供举荐引擎调用，举荐引擎负责线上所有用户的举荐，其对性能的要求是十分高的，因而向量召回服务的性能也极其重要。对于不同业务而言，如果向量召回服务没有通用化与服务化，则不同业务的算法与零碎开发工程师各自须要反复搭建，且须要自行进行服务运维，这无疑是减少了举荐开发工程师的累赘，也是对开发效率的损耗。

图 4 向量召回服务的接入过程

对于单业务撑持而言，咱们只需思考如何搭建起一个向量召回服务 ，从而能对海量 embedding 数据进行 top N 检索，同时保障服务的高性能即可。而对于举荐中台而言， 在服务于多业务的状况下，须要在此基础之上再思考如何将这个服务的搭建与运维繁难化、自助化、自动化以及平台化。

2. 高维向量检索引擎选型

近似最近邻算法（ANN）目前是对海量高维向量求 TOPN 类似内容的支流算法。而 Facebook 实现的 C++ 库 faiss 也是常常被应用的 lib，基于 faiss 去实现向量召回服务是一个抉择。此外，业界罕用的开发框架 vearch 和 Milvus 数据库也是可选的服务之一，图 5 是服务选型比照。

Milvus 数据库 自身是为海量特征向量的近似最近邻搜寻而设计，相比于 faiss 这样的算子库，其提供了残缺的向量数据更新、索引与查问框架。Milvus 数据库也反对利用 GPU 进行索引减速与查问减速，可大幅提高单机性能。目前 Milvus 也曾经失去了头部机器视觉公司的技术认可，技术社区气氛沉闷。

vearch 是一个分布式向量搜寻零碎，能够用来计算向量类似度，能利用于图像识别、视频辨认或自然语言解决等机器学习畛域。vearch 也是基于 faiss 实现，提供了疾速的向量检索性能。其提供相似 elasticsearch 的 restful api，能够不便地对数据及表构造进行治理查问等工作。

图 5 选型比照

自实现服务与开源框架的性能根本相似，且根本都是基于 C++ 实现。对于 0-1 的服务搭建，以及在充沛借力社区效率的考量下，在已有的服务框架下进行开发是个不错的抉择。在综合思考各服务实现的 sdk 丰盛度、性能指标、是否开源，开源社区是否沉闷，再联合业务上举荐引擎应用 java 语言实现的比例越来越高，最终选用 Milvus 框架来实现在线向量召回服务。

3. 向量召回服务化具体实现

在构建在线向量召回服务时，咱们思考到算法同学常常会针对不同场景去调整算法实现，因而，只通过封装并内置某些 embedding 算法实现，会使算法同学产生解放感。因而，咱们设定了 embedding 模型的 schema，并当算法同学在举荐中台上创立了服务后，凋谢给算法同学一个指定门路供寄存 embedding 模型，尔后，在设置一些必要参数后，可在举荐中台上启动在线向量召回服务，并暴露出标准接口供举荐引擎调用。其具体设计如图 6 所示，在向量检索引擎上，举荐中台与爱奇艺深度学习平台进行了单干共建。基于 Milvus 框架，咱们进行下层利用构建，来升高举荐业务开发同学的搭建老本；反对数据版本治理，来进步业务侧稳定性；反对多机房部署与服务衰弱检测机制，进步底层容灾能力。

图 6 在线向量召回服务的整体架构

在应用过程中，咱们也发现了一些问题。例如，Milvus 数据库在索引构建时 CPU 使用率会十分高，导致查问服务根本不可用，针对这个问题，咱们也进行了解决，当咱们进行数据版本更新时，咱们会另起一个服务独自更新，而当更新实现时，会进行线上服务的替换，线上数据版本会保留最近 2 个版本。如图 7 所示。

图 7 解决 Milvus 索引构建时 CPU 使用率过高问题

思考到业务举荐引擎应用 java 语言实现的比例越来越高，而 Milvus 数据库的查问接口以 grpc 接口为主，因而，咱们在其之上进行了 dubbo 接口的封装，便于 java 服务框架进行接入，这会在很大水平上简化服务的接入难度。通过 dubbo 服务发现，也实现了多机房部署对业务侧的无感知。

图 8 向量召回服务的 dubbo 服务封装示意图

在此服务封装与实现下，业务同学要创立在线向量召回服务时可达到无门槛分钟级创立，且反对在线调试。在 Milvus（2 核 6G）& dubbo 查问服务（4 核 12G）88 实例下，对 600w 64 维数据进行查问，当查问 QPS 在 3k 时，p99 提早在 20ms 左右。而业务同学的接入流程亦如图 9 所示，不须要再封装与搭建向量召回服务。

图 9 向量召回服务化后的接入过程

在线推理召回一体化

在上述服务化实现中，做到了服务的通用化形象，当在一个业务中，举荐零碎开发人员要接入一个在线向量召回服务时，能够在平台上通用自助操作后，在分钟级就能取得一个服务并裸露一个通用接口供举荐引擎调用。但仔细一点会发现（能够参考图 9），在向量召回过程中，查问 query 的向量生成并没有蕴含到服务中，依然在举荐引擎模块中。而 query 向量的生成办法，一种较为简单的形式为可依据业务特点通过规定或简略算法对已有相干 embedding 进行加权生成，另一种就是利用 embedding 生成模型，在提供输出特色后实时生成。显然，将 query 向量的生成蕴含在服务中，无论是对于解放业务同学而言，还是对于整体举荐服务构建效率晋升而言，都是比拟重要的。

在对整体计划与选型进行了再评估后，首先对于 0-1 的疾速实现，抉择成熟封装好的 ANN 服务性价比是比拟高的，这也是最终抉择 Milvus 框架的起因之一。而随着服务建设的继续推动，后续对性能、性能的优化速度与符合度有较多考量，相似于 YouTube DNN 这种在线向量召回，心愿把推理与召回封装到一起，如果基于 Milvus 数据库会波及到新性能的依赖以及与社区迭代打算的匹配，与现阶段的外部诉求不肯定统一。另外在之前的实际过程中，咱们发现 Milvus 还有肯定的问题存在，当然 Milvus 社区也比拟沉闷，所存在的问题也在逐渐解决。但在综合评估之后，咱们决定联结爱奇艺深度学习平台，基于 hnsw lib 进行革新。之所以能够进行疾速切换，次要起因有：

（1）爱奇艺深度学习平台对 hnsw lib 进行了封装，并产出了一套相似于 Milvus 数据库的服务，并在疾速迭代降级；

（2）基于 hnsw lib 封装的服务在索引创立时，服务仍然可用，能够解决 Milvus 在索引创立时，cpu load 较高而查问不可用问题，也能简化整体设计；

（3）基于 hnsw lib 在实现相似 YouTube DNN 的在线推理召回一体化时相较于 milvus 较为便捷（咱们应该是轮子的使用者，而不是反复造轮子的人，除非已无轮子可用）；

（4）hnsw 的 ann 算法实现在成果上体现最好，如图 10 是在 2020-07-12 在 fashion-mnist-784-euclidean 数据集上的测试后果，越往右越靠上代表成果越好；

（5）在图 6 的设计过程中，咱们基于 Milvus 数据库作为底层镜像向上构建利用，并在设计之初也保留了未来对其切换为其它服务框架的思考，因而，对 Milvus 进行切换具备可行性。

图 10 2020-07-12 在 fashion-mnist-784-euclidean 数据集上的测试后果

为了将向量的在线推理局部纳入进来，咱们须要将模型的训练局部进行接管，但思考在实现上，算法工程师须要保留其自主批改算法的权力，因而在模型服务层面会反对其选用中台内置模型或使其依照中台定的标准去自实现算法。在原来的整体架构上进行肯定调整后，在线推理及召回一体化的设计如图 11 所示。

图 11 在线向量推理召回一体化服务整体设计

在对整体计划进行调整后，向量召回服务的接入过程如图 12 所示，此时，举荐引擎外部不须要关怀 query embedding 向量的生成实现过程，其只需提供须要的特色即可。

图 12 在线 embedding 推理召回一体化实现后的接入过程

总结与瞻望

本文已大抵介绍了爱奇艺举荐中台对于在线向量召回服务的工程化实际过程。对于举荐中台，对服务进行通用化、平台化形象，晋升业务方服务构建效率，亦是晋升业务迭代速度，帮助业务方晋升举荐成果的要害一环。

在线向量召回服务的工程化落地过程中，有一些关注点：

（1）底层检索引擎的选型，咱们认为 Milvus 数据库与 vearch 各有劣势，如 milvus 在 SDK 上较为丰盛，在与不同语言的后端服务进行对接时有较好的劣势，其沉闷的社区也让其一些问题的解决更为疾速。而 vearch 在 embedding 数据量微小时（如 6 亿条 128 维向量数据）会更为实用，但在耗时上也会更高一些。

（2）服务性能和稳定性是重中之重，这是线上举荐引擎服务是否良好运作及举荐成果是否能失去晋升的要害之一。

（3）将 query embedding 的推理过程与 top N 的召回过程进行对立，可能为业务方接入失去最大提效。

（4）模型会更新，对应的 embedding 数据也会更新，因而服务须要思考数据版本的治理，这也是业务诉求之一。

（5）思考实时 embedding 内容的入库问题

当然，在向量召回服务还是能够持续进行一直优化的，例如：

（1）embedding 的生成算法有很多，能够思考将业务上须要的生成模型一直内置化；

（2）在不同召回率的状况下，能够持续对高 QPS 下的响应性能进行优化。