智能搜索模型预估框架的建设与实践( 二 ) _框架

文章插图

这一套逻辑很简单，构建起来也不复杂，所以在建设初期，我们快速在主搜的核心业务逻辑中快速实现了这一架构，如下图所示。这样的一个架构使得我们可以在主搜的核心排序逻辑中，能够使用各类线性模型的预估，同时也可以借助公司的技术能力，进行深度模型的预估。关于特征抽取的部分，我们也简单实现了一套规则，方便算法同学可以自行实现一些简单的逻辑。

文章插图

3. 预估框架思路的改变3.1 老框架的局限
旧架构中模型预估与业务逻辑耦合的方式，在预估文档数和特征数量不大的时候可以提供较好的支持。
但是，从2018年开始，搜索业务瓶颈开始到来，点评事业部开始对整个搜索系统进行升级改造，并打造基于知识图谱的分层排序架构（详情可以参见点评搜索智能中心在2019年初推出的实践文章《大众点评搜索基于知识图谱的深度学习排序实践》）。这也意味着：更多需要模型预估的文档，更多的特征，更深层次的模型，更多的模型处理层级，以及更多的业务。
在这样的需求背景下，老框架开始出现了一些局限性，主要包括以下三个层面：

文章插图

性能瓶颈：核心层的模型预估的Size扩展到数千级别文档的时候，单机已经难以承载；近百万个特征值的传输开销已经难以承受。
复用困难：模型预估能力已经成为一个通用的需求，单搜索就有几十个场景都需要该能力；而老逻辑的业务耦合性让复用变得更加困难。
平台缺失：快速的业务迭代下，需要有一个平台可以帮助业务快速地进行模型和特征的管理，包括但不限于配置、上线、灰度、验证等等。

文章插图

3.2 新框架的边界
跟所有新系统的诞生故事一样，老系统一定会出现问题。原有架构在少特征以及小模型下虽有优势，但业务耦合，无法横向扩展，也难以复用。针对需求和老框架的种种问题，我们开始构建了新的高性能分布式模型预估框架Augur，该框架指导思路是：

业务解耦，设定框架边界：只做特征抽取和模型预估，对预估结果的处理等业务逻辑交给上层处理。
无状态，且可以做到分布式模型预估，无压力支持数千级别文档数的深度模型预估。

文章插图

架构上的改变，让Augur具备了复用的基础能力，同时也拥有了分布式预估的能力。可惜，系统架构设计中没有“银弹”：虽然系统具有了良好的弹性，但为此我们也付出了一些代价，我们会在文末进行解释。
4. 预估平台的构建过程框架思路只能解决“能用”的问题，平台则是为了“通用”与“好用” 。一个优秀的预估平台需要保证高性能，具备较为通用且接口丰富的核心预估框架，以及产品级别的业务管理系统。为了能够真正地提升预估能力和业务迭代的效率，平台需要回答以下几个问题：