神策数据算法专家：推荐系统的实践与思考（下）

推荐系统之在线服务

在解决了算法和数据层面的问题之后，我们需要构建一个推荐系统的在线服务，用来响应用户的推荐请求。假设企业初期的 DAU 是 10 万，当 DAU 涨到一百万的时候，希望能够通过增加机器的形式，解决服务性能响应的问题。如果每当 DAU 扩大时就要去重构推荐服务的话，代价实在太大，所以我们希望我们的推荐服务具备高可扩展性。

另外一些常见的需求是：如何实现高维向量的查询和计算？如何满足不同场景时效性不同的需求？监控和报警怎么做……

尽管深度学习的模型复杂、效果又好，但哪怕把模型训练出来之后，等过渡到在线服务时还是会遇到很大的挑战。今天我就几个实践问题在这里跟大家做一些分享。

1.如何做高维的向量查询？

举个例子。假设目前有 10 万个商品，每一个商品拥有一个向量的话，就会有 10 万个向量，当用户来到后，一个用户对应一个向量，这个时候我们需要在这 10 万个项目里面去查找到跟这一个用户向量最匹配的 100 个或者 500 个向量。同时还要保证在足够短的时间之内（10-20 毫秒）将向量找出，所以在响应时间的层面还面临着较大的挑战。

我们的解决方案是运用一个叫做 Faiss 的工具，它可以解决大规模的向量的相似度查找问题，且最大可支持 10 亿规模的内容空间。简而言之，当我们有 10 亿商品的时候，仍可以用此组件去做基于向量的相似度查找。

2.如何让推荐系统的在线服务具备高可扩展性？

我一直在强调，我希望我们的可扩展性是水平的，流量上来之后，仅通过加机器的方式就能解决服务的压力。我们的思路是，把在线服务分为三组：在线存储、在线服务群、模型服务群。

我们把模型服务和在线服务做一些逻辑上的解耦，从而保证整个架构在可扩展性上是水平的，这样既可去单加模型服务也可以去单加在线服务，解决服务器上的压力。

3.不同场景下不同的时效性，该如何支持？

我作为一个技术的人员，在做 Feed 流时经常会接到产品经理如下的需求，比如，需要在综合频道推荐最近 3 天的文章，最近 7 天的视频；历史频道的数据量对时效性要求没那么高，需要推荐近 30 天的文章和最近 60 天的视频；相关文章中要求推荐最近 7 天的文章，相关视频中推荐近 30 天的视频。

这些需求严格上来说是非常合理的，因为这是基于产品本身以及用户对于此产品的诉求，但这些需求其实会给推荐系统带来很大的问题。

我们简单来计算一下场景数量。

产品经理需要我们支持文章推荐和视频推荐两种类型，同时还要分成不同的频道，而综合频道和其他小频道所涵盖的内容和范围又不一样，小频道少则十几个，匹配上两种架构类型，大概 2×10=20 份数据，再加上相关文件的推荐，可能会产生 40 份数据。

为了支持不同的时效性，我就需要维护 40 套不同的数据，在推荐系统里面维护 40 套数据意味着维护成本和出错的风险都相当大。40 套数据，可能拥有 40 条逻辑，40 个数据流，一旦发生人员变动，对于接手的人员来说简直噩梦。

所以我们在整体的架构中，会去为不同场景、不同时效性设计一整套的工具和流程来解决诸如此类的问题，这可以使我们的线上管理较为简洁，不会出错但又非常灵活，即使有其他的时效性需求时，也能很容易地加入。

推荐系统之效果评估

评估一个推荐系统，会涉及到一些常用指标：点击率、点击人数比、人均点击次数、留存率、转化率等。

1. 点击人数比

指点击的人数除以推荐的曝光人数，这是一个用来衡量推荐系统触达率的一个重要指标。在评估一个模型效果时，可能点击率上涨，但点击人数比并没有变化，这说明推荐结果只对于部分老用户产生比较好的效果，对于触达不到的用户，仍然没有成功吸引他们来使用我们的推荐系统，所以点击人数比与点击率是对推荐系统在不同方面的评估。

2. 人均点击次数

指每个人在推荐系统里面平均每天点击了多少次。人均点击次数是需要大家持续去关注的指标，因为这个指标真正体现出用户在这款产品中的使用深度。

3. 留存率和转化率

留存率和转化率实际上来说对于推荐系统来说，可能并不是一个那么直接的指标，比如推荐对留存的影响到底有多大，很大程度上决定于不同的产品形态，但它仍是我们去评估推荐系统的一个指标，至少我们需要知道此次推荐系统的迭代到底对于留存率的影响有多大，如果迭代后的留存率下降，即使点击率和点击人数比都在上升，可能这一次迭代仍不能上线，因为它影响了留存的指标。

还有一些方面，其实在之前的文章中神策数据 VP 张涛：个性化推荐从入门到精通（附推荐产品经理修炼秘籍）已经跟大家提到过。

时效性。如果我们在做一个新闻产品的推荐系统，那么给用户推荐的内容就应该是实时的，而不是上周发生的事情。

多样性。多样性其实是容易被忽视的一个指标，因为如果不追求多样性的话，点击率的数据会好看一点。

不知道大家有没有这样的体验，如果你对体育内容感兴趣，慢慢的你所有的推荐内容都变成了体育相关，似乎很难看到其他内容，推荐的内容越来越窄。短期来说，提升多样性可能会让点击率有一些损失，但是长期来说，多样性是为了提升整个产品用户体验所做的一种优化，这里需要考虑长期和短期的权衡。

稳定性。如果服务器经常挂掉，或者说响应时间总是五秒钟，这样的服务基本上是不可用的，我们一定要站在服务的角度去评估我们的推荐系统。

覆盖率。覆盖率指能够推荐出来足够多的长尾内容，一个 UGC 平台，需要去鼓励一些用户让他们来生成内容，即使是一些很小的用户，即使没有粉丝，我也希望他的内容可以有一些曝光，有曝光就会有人去点赞，久而久之会形成一种良性循环。

如果平台总是分发一些大 V 的内容，平台里小白用户的使用和体验就会变得非常糟糕，慢慢的就没有这些小的内容窗口了，平台将被大 V 占领，所以覆盖率也是一个推荐系统需要考虑的指标。

至于具体需要去考虑哪些指标，以及怎么去制定这些指标，我觉得要根据不同的产品形态以及产品不同的阶段而定。

那么面对这些指标，我们有给力的分析工具去支持我做这件事情吗？比如我想对比推荐系统的转化率和另外一个 banner 的转化率区别的时候，我们的分析工具具备这种能力吗？

在我的日常工作中，是依据神策分析去做整个转化率漏斗分析，以及留存分析等。留存分析其实是一种比较复杂的分析方法，它强调的维度比较多，它可能要从各个时间段以及各个条件去分析用户的留存行为。

如果想要去分析推荐效果对于留存的影响，可以直接在神策分析中去做留存率的分析。

另外，跟大家分享一些关于迭代的思路。

以下图为例，我们分析推荐系统在 12 月 18 号新增用户上的不同表现。

我们想知道，对于新用户和老用户而言，推荐系统的这次迭代表现究竟如何。

从图中可知，新用户在第二天有一个明显的提升，但是老用户并没有。说明这一次模型的上线对于新用户而言效果是较好的，我们要进一步去分析--为什么会对新用户的效果提升明显而对老用户没什么效果。

可能是因为使用的数据采样方式对于新用户更加有利，或者是因为对于新用户的特征反馈比较及时，而对老用户的一些长期特征做了一些不太合适的处理方式等等，都有可能。

所以，实现一个好用的推荐系统，可能面临这几方面的挑战：

第一，数据获取和处理质量，就是我前面提到的如何做数据的采集，以及如何做特征工程。

第二，将算法跟业务结合，我们怎么去深入地理解业务场景，以及去选择合适的算法方案。

第三，构建推荐系统和评价体系，以及如何去解决在线服务这部分的挑战。

第四，成本控制，当我们去从头构建算法、数据、在线服务以及评估方法这几个方面的事情时，人力和时间都会耗费相当大的成本。

最后回答演讲刚开始时大家问我的一个问题--如何搭建一个闭环，让其流程化体系化。其实就是神策智能推荐系统的核心优势--全流程、实时、可快速迭代的推荐闭环。

通过我的分享，大家也可以看到我们在实际构建一个推荐系统时，会遇到各种各样的问题，基于之前的经验，数据质量是非常需要注意的一部分。它包括全端采集数据、数据处理和建模、标签体系和用户画像建立。

接着，当我们有了数据后我们就去构建算法，我们拥有丰富的算法建模经验，并且数据基于神策分析，拥有实时数据反馈和快速的建模能力。

在算法生效之后，我们会对结果进行多维的验证分析，一方面我们要对于本次的推荐效果有一个认知，另外一方面要明白后续将如何改进。同时，在我们提供的解决方案里，还有两个比较重要的环节。

第一，神策数据是一家支持私有化部署的公司，所以神策智能推荐系统同样支持私有化部署，一整套系统都部署在客户自己的服务器层。

第二，具有开放性。各种中间数据和接口客户都可以自己去调用，比如我们帮助客户采集行为数据，在构建整个推荐系统时所生成的各种用户画像和模型结果，以及内容分析的一些结果，还有各个阶段产生的一些模型方法，客户都可以去调动。神策数据的解决方案是一个开放性的白盒，从实验设计，到数据的采集，到中间的特征工程，到模型构建，到最终推荐结果，里面的数据和接口都可供客户访问和查看。

最后，我想强调两点内容：

第一，推荐系统不只是算法，它是一个系统工程，算法只占四个部分中的一部分，通常我们去实现一个推荐系统时，构建算法的时间通常只占 20% 到 30%。

第二，数据先行，数据是一切算法的前提，根据过去的经验总结，很多时候真的不是因为模型的问题，也不是因为服务的问题，而就是因为数据没有做对，导致我们推荐系统的效果没有那么符合预期。

以上就是我从多年的工作经验和实践中总结出的一些关于推荐系统的思考，希望能对大家的工作有所启发。

更多互联网干货和案例，可关注【神策数据】公众号了解，回复关键词还能进交流群、获得报告、行业案例等福利哦~