19.03.29 神策.胡士文-推荐系统的实践与思考

19.03.29 神策.胡士文-推荐系统的实践与思考.pdf
本文内容来自神策数据《智能推荐——应用场景与技术难点剖析》闭门会分享内容整理，分享者为神策数据算法专家胡士文，分享主题为《推荐系统的实践与思考》。
大家好，在演讲开始前，我对在座的各位进行了一个小调查，得知大家普遍在工作中遇到的与推荐系统相关的问题是：“数据太稀疏、数据没有形成闭环、数据没办法跟其他系统结合”等等，这些内容，是摆在我们面前的实际问题，那么当我们真正要开始做一个推荐系统时，需要从几方面考虑问题呢？
第一，算法。到底应该选择什么样的算法？无论是协同过滤还是其他算法，都要基于自己的业务产品。
第二，数据。当确定了算法时，应该选择什么样的数据？怎样加工数据？用什么样方法采集数据？有句话叫做“机器学习=模型+数据”，即便拥有了一个很复杂的模型，在数据出现问题的情况下，也无法在推荐系统里面发挥很好的效果。
第三，在线服务。当模型训练完毕，数据准备充分之后，就会面对接收用户请求返回推荐结果的事项，这其中包含两个问题。其一，返回响应要足够迅速。如果当一个用户请求后的一秒钟才返回推荐结果，用户很可能因丧失耐心而流失。其二，如何让推荐系统具有高可扩展性。当 DAU 从最初的十万涨到一二百万时，推荐系统还能像最初那样很好地挡住大体量的请求吗？这都是在线服务方面需要考虑和面临的问题。
第四，评估效果。做好上述三点，并不代表万事大吉，一方面，我们要持续迭代推荐算法模型与结构，另一方面要去构建一套比较完整、系统的评价体系和评估方法，去分析推荐效果的现状以及后续的发展。
我会从以上四个方面，跟大家分享一下我们在实际情况中遇到的一些问题以及总结出的解决方法。

一、算法

在各种算法中，大家最容易想到的就是一种基于标签的方法。

如上图所示，标签可分为两种。
第一种——用户标签。假设我们拥有一部分用户标签，知道每一个用户的年龄、性别等信息，当某类年龄和某种性别的用户喜欢过某一个物品时，我们就可以把该物品推荐给具有同样年龄、性别等用户标签的其他用户。
第二种——内容标签。与用户标签的思路相似，如果用户喜欢过带有内容标签的物品，我们就可以为他推荐具有同样标签的内容。
但很明显，这种基于标签的方法有一个重要的缺点——它需要足够丰富的标签。也许在多产品中，可能并没有标签或者标签数量非常稀疏，所以标签的方法显然不足以应对。
另外，协同过滤也是一种非常经典、被较多人提及的一种方法，是一种常见且有效的思路。

随着技术的不断发展，基本从 2012 年以后，深度学习几乎被整个机器学习界进行反复的讨论和研究。谷歌在 2016 年提出一套基于深度学习的推荐模型，用深度学习去解决推荐的问题，利用用户的行为数据去构建推荐算法。

1. 深度学习的目的之一：向量化

推荐系统其实是在做一个关于“匹配”的事情，把人和物做匹配。看似很难的推荐系统，其实也有简单的思路——做人和物的匹配，把该用户可能感兴趣的物品推荐给他（她）。如果站在数学的角度去思考这个问题，我们如何去计算人和物的相似度匹配呢？
在推荐领域，深度学习的目的之一就是尝试将人和物向量化，即把某个人和某个物品学习成一种统一的表示方式，随后在这个统一的表示方式中计算这个人和物品的相似度，当人和物都映射到同一个可比较的空间中时，就能够基于计算结果去执行相关的内容推荐。

把最终的结果映射到这张二维的平面图表里，用户认为相似的内容就会映射在向量上，当拥有内容向量之后，之后再将用户映射进来即可，比如用户到达了上图某个地方，根据他所处的位置，可以向其推送教育、娱乐、科学、地理等内容。
讲到这里，有些朋友就会提出疑问：既然深度学习如此复杂，那在实践中究竟有没有作用？其实站在实战经验的角度来看，当具备一定的数据量时，会带来比较明显的效果提升，但当你要去搭建一个深度学习模型的时候，可能真的会遇到很多问题。比如：
用多少数据量去训练模型是可以的？训练数据该用什么格式？多“深”才算深度模型？训练模型太慢了怎么办等。这些关于在搭建深度学习模型时遇到的困难与解决方法，会在以后跟大家分享。

1. 冷启动

冷启动是算法部分经常遇到的问题，在冷启动阶段，数据比较稀疏，很难利用用户的行为数据实现个性化推荐。冷启动的问题分为两种：新内容的冷启动、新用户的冷启动。接下来，我们分享一下新内容的冷启动要如何实现。
举个例子，资讯场景的需求往往是将发布的新内容（如 10 分钟内发布的内容），以实时且个性化的方式分发到用户的推荐结果中去。

上图这篇文章在 17:41 发出，那么就需要在极短的时间内根据这篇文章的内容去做一些个性化的相关推荐。此文内容围绕美食展开，用户点开这篇文章之后，文章的相关推荐里面就要有跟美食相关的一些内容。当我们要在如此实时的环境中实现推荐效果的话，其实没办法去依赖用户的行为。
这时，我们尝试提供一种思路，一种基于深度学习的语义理解模型。
这个模型跟我们前面分享的内容有一个很大的区别就是——不需要用户行为，只需要分析用户文本，基于用户的内容去给每一篇文章生成一个向量。这和前面提到的模型也有相通的地方，第一，用深度学习的思路去解决问题，第二，用向量化的思路解决问题。我们只需要训练出文章的语义向量，获得文章与文章之间的相似度，从而得知文章和用户之间的相关性。

1. 召回、排序、规则

如今的推荐系统已经做得相当复杂，特别是在一些大规模的应用场景中，比如说今日头条的 Feed 流，淘宝的“猜你喜欢”等，都拥有一个非常复杂的推荐系统，这个推荐系统中的各个模块可能会涉及到很多的实验算法，在一个系统中，出现 10 个或者 20 个模型都很常见。那么怎么把这些模型有效地融合成一个真正的系统呢？
召回
召回，即从海量的内容里去召回每一个用户他可能感兴趣的内容，前提是——拥有海量的内容，因为当内容不足时，也就不需要去搭建复杂的推荐系统。所以，当有海量 Item 时，需要用召回的算法从不同类别的内容里为用户生成他可能感兴趣的内容。比如某位用户既喜欢体育内容，也喜欢军事内容，那么在第一步，无论用哪些模型，都希望达到为该用户生成一些体育、军事相关内容的效果。另一个用户可能喜欢美食和游戏，在召回阶段，我们就希望通过模型去为他生成一些美食和游戏相关的内容。
在召回阶段可能就会存在许多个模型。而经过召回阶段之后，尽管生成的是该用户可能感兴趣的内容，但这些内容实际并没有融合到一起，是一种乱序的状态。
排序
排序，即将召回出来的内容做统一排序。排序过程其实就是给每部分内容打分的过程，预测每一个用户对每一部分内容的感兴趣程度，从而获知每一个用户对每部分内容的偏好程度。
规则
推荐系统常常跟产品或者业务场景紧密相连，而在产品中一定有一些需求是无法用模型来解决的。因为模型只能从用户行为或者文本内容中去发掘用户和物品之间的关系，所以有些常见的业务需求要通过规则去实现。举个例子，部分推荐场景中会出现一些运营精选的内容，运营同事的需求是：保证每十条内容中都有一条编辑精选内容，而这个需求，只能通过规则实现，而不是通过算法。
一个比较复杂的推荐系统通常分为召回、排序、规则这三个步骤。首先召回用户感兴趣的内容，第二为用户生成一个排序列表，第三用规则解决一些产品、运营方面提出的需求。

二、数据

总是会听到一个这样的说法，“推荐算法的效果是由模型与数据所决定的”，即模型只占推荐效果中的一部分，另外一个非常重要的部分就是数据。那么我们究竟需要哪些数据？在一个实际的推荐系统中，哪些数据是有可能发挥作用的？我们又能拿到哪些数据？
通常来说一般会有四类数据：用户行为、物品信息、用户画像以及外部数据。

1. 用户行为

用户行为数据最为重要，几乎没有哪一个推荐系统可以直接表示不需要用户行为数据。一方面，用户行为数据是训练模型中的一个重要数据来源，另外一方面，需要通过用户的行为反馈，技术同事才能知道推荐系统到底做得如何。搭建推荐系统的一个秘籍就是积累用户行为数据，如果没有将重要的用户行为做采集，例如在电商场景中，如果只是记录最终的下单数据，那么离推荐系统的数据要求还是有一定的距离。
2.物品信息
物品信息指推荐系统中能采集到的描述每一个内容的信息。以电商场景为例，在录入一件具体物品时，录入商品的品牌、价格、品类、上架时间等就是我们要收集的物品信息。假设在电商场景中，如果并不清楚每个商品的品牌，也就无法从一些物体的描述信息中去提取某个商品到底属于何种品牌，那么推荐效果自然受到限制。当物品信息采集的足够丰富时，对推荐系统的效果就会有一定的帮助。

1. 用户画像

在传统的思路中，认为用户画像里面存储的实际还是用户的标签，但在很多实际场景中标签数量少、维度粗，可能根本不具备去给用户打标签的能力，这种传统的“标签式”想法，就会限制搭建推荐系统的思路。
而从深度学习的角度出发，用户画像中储存的并不是通常理解的“标签”，他可能存储的是这个人的向量，深度学习是把人和物品做向量化，但这个向量是不可被理解的，即我们可能并不知道这个向量表示的是什么意思，当我们看到某个用户对应的向量，我们也不知道他是对体育、音乐或是娱乐感兴趣，但我们仍能够通过向量去为他推荐其感兴趣的内容。

1. 外部数据

有的人会迷信外部数据，觉得自己的数据量不够，所以一定要去购买阿里或者是腾讯的外部数据来充实用户画像，从而提高推荐系统的效果。甚至有人认为推荐系统效果不好，是因为没有外部数据。
但其实，外部数据对于推荐系统的效果，个人认为还需要一个极为谨慎的推理和验证。
首先，要先验证自己的这批用户群跟所购买的外部数据能发生多少交集。假如一个游戏平台，购买了阿里的外部数据，而这样的外部数据可能只能告诉你用户到底是喜欢买衣服、买车还是买电子产品，这样的信息对游戏平台有用吗？
假设购买的外部数据恰好命中了业务场景，可能会发挥一定的作用，但实际上，能够同时命中用户群体和标签的情况也并不常见。
大家不要认为上述的 4 种数据比较容易理解，所以获取时也会比较简单。其实我和我们神策团队在去构建一个实际的推荐系统时，消耗我们人力的地方往往不是算法，反而是怎么去得到正确的数据，接下来我们以用户行为数据为例，与大家分享应该如何获取我们所需要的用户行为数据？
这时候我们就要思考，当我们想去获取用户行为数据时，到底希望用户行为数据能给我们带来什么样的作用？
我总结为以下几个方面：
第一，我们希望用户行为数据能用来训练模型，这是非常重要的一个方面。比如我给某个用户推荐十件商品，其中有两件商品发生了点击行为，模型中就会觉得这两条数据是正例，其他是负例。所以，我们需要用户行为数据作为模型的训练数据。
第二，我们希望用户行为数据能够验证效果。推荐系统上线之后，需要用户行为数据来反馈推荐到底做得怎么样。比如点击率上升说明效果变好，点击率下降、负反馈变多、用户流失，说明推荐系统可能出现了问题。
第三，我们希望用户行为数据能够支持我们去看 A/B Test 效果。模型上线一定要基于 A/B Test，我们需要知道此次上线到底比之前的推荐算法、推荐系统等效果如何。这样，我们才能判断这一次的迭代是否有效，如果有效就将其全量，如果无效，则进一步迭代。
第四，我们希望它能够帮助我们分析问题。我们将推荐系统上线之后，可能会碰到一些懊恼的问题，比如点击率并没有发生变化，甚至效果变差，毕竟不可能每一次迭代的效果都是上升的，所以我们希望行为数据能够定位到此次推荐系统上线后效果不理想的原因。如果上线后效果不错，此时我们希望行为数据能够分析到底是哪些因素使效果变好。
那我们应该如何去获取满足我们这些需求的行为数据呢？以曝光日志中的第一个字段 exp_id 为例，exp_id 的中文的意思是实验 ID。
前面提到了我们希望用户行为数据是能支持 A/B Test 的，那么如何知道每一条数据是来自哪一组实验呢？此时，我们需要一个 exp_id 字段去记录每一条曝光日志是来自哪组实验。当我们再次分析 A/B Test 效果时，就可以根据一个 exp_id 字段去区分不同实验所带来的曝光和点击。

在曝光日志中我们常常讨论如何设计一些常用字段，而另外一个具体问题就是——我们怎么去采集这些数据？
简单来说，当用户在产品里面发生一些用户行为，怎么把这个数据最终落到服务器的日志中，从而用于模型训练和效果分析呢？
做用户行为的采集，通常有两种方式。第一种就是自助埋点，客户端先把用户的行为记录下来，之后传给服务端，服务端再去传给推荐引擎。另外一个埋点方式是 SDK 埋点，我们直接使用 SDK 去做推荐引擎的埋点。
SDK 埋点有两个方面的优势：
第一，SDK 埋点的接入成本低，它有比较成熟的埋点事件和埋点验证方案。另外 SDK 有埋点接口和文档指导客户埋点，无需关注上报问题。
第二，SDK 埋点的容错性比较高。如果是自助埋点，从客户端到推荐引擎经过了服务端，数据出现问题，难以回溯埋点问题、传输问题、数据质量维护成本高，SDK 埋点就会相对方便。
那么当有了行为数据之后，如何去训练模型？通常会有以下几个步骤：
第一，构造正负例。比如给用户推荐十条商品，有几条发生点击，就有几条正例，其他没有发生点击就是负例。
第二，构造特征工程。稍后会以一个电商场景为例，具体讲解通常情况下，如何构造特征工程。
第三，数据采样。数据采样对整个模型训练的效果影响较大。
下面以电商场景为例，讲解如何做特征工程，主要分为 2 个方面：
第一，商品维度。在商品的维度里，我们可能关注一些商品的品类、品牌、价格、所面向的性别，以及各种用户行为反馈的一些数据，比如点击率、收藏比率等，这些内容一方面体现了商品本身的一些属性，同时还体现商品的质量。
第二，用户层面，通常首先考虑用户的年龄和性别。因为在电商领域中男性所偏重的商品和女性之间存在较大差异。另外还有用户的品类偏好、品牌偏好，以及价格偏好等。
在数据方面，跟大家分享一下我在实际工作中遇到的“坑”：
某一次小的流量上线之后，我和团队成员发现效果不如预期，根据以往的实践经验来说，不应该是这么差的结果，当我们去分析数据时，发现有两个方面的数据异常。
第一，命中行为模型的用户较少。通常情况下，只要不是一个新用户，理论上来说，都应该能够命中我的行为模型。我们当时的新用户比例在 20% 以下，而命中模型的用户大概仅为 30%，说明大量的用户没有命中到模型。
第二，很多请求的 ID 未出现在日志中。当时我们怀疑，是否我们的推荐结果被别人作弊刷掉了。因为用“作弊”能很好地解释这些请求并未落到日志中的原因。
但最终，我们发现并不是作弊的问题，而是因为用户 ID 没有统一。前端在用他们理解的一套用户 ID 体系打日志，但是后端在用另外一套用户 ID 体系发送请求。于是所有的数据无法对上，后端过来的请求总是新用户，而训练出来的模型命中不了任何用户。
最终，我们建立了一系列的方法和工具以及流程去保证整个用户 ID 体系的一致性。
以上就是神策数据算法专家胡士文对推荐系统的实践与思考的前两点“算法”与“数据”的分享，由于篇幅限制，“在线服务”和“效果评估”将在下一篇文章进行介绍，希望对你有帮助！

推荐系统之在线服务

在解决了算法和数据层面的问题之后，我们需要构建一个推荐系统的在线服务，用来响应用户的推荐请求。假设企业初期的 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. 点击人数比

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

1. 人均点击次数

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

1. 留存率和转化率

留存率和转化率实际上来说对于推荐系统来说，可能并不是一个那么直接的指标，比如推荐对留存的影响到底有多大，很大程度上决定于不同的产品形态，但它仍是我们去评估推荐系统的一个指标，至少我们需要知道此次推荐系统的迭代到底对于留存率的影响有多大，如果迭代后的留存率下降，即使点击率和点击人数比都在上升，可能这一次迭代仍不能上线，因为它影响了留存的指标。
还有一些方面，其实在之前的文章中神策数据 VP 张涛：个性化推荐从入门到精通（附推荐产品经理修炼秘籍）已经跟大家提到过。
时效性。如果我们在做一个新闻产品的推荐系统，那么给用户推荐的内容就应该是实时的，而不是上周发生的事情。
多样性。多样性其实是容易被忽视的一个指标，因为如果不追求多样性的话，点击率的数据会好看一点。
不知道大家有没有这样的体验，如果你对体育内容感兴趣，慢慢的你所有的推荐内容都变成了体育相关，似乎很难看到其他内容，推荐的内容越来越窄。短期来说，提升多样性可能会让点击率有一些损失，但是长期来说，多样性是为了提升整个产品用户体验所做的一种优化，这里需要考虑长期和短期的权衡。
稳定性。如果服务器经常挂掉，或者说响应时间总是五秒钟，这样的服务基本上是不可用的，我们一定要站在服务的角度去评估我们的推荐系统。
覆盖率。覆盖率指能够推荐出来足够多的长尾内容，一个 UGC 平台，需要去鼓励一些用户让他们来生成内容，即使是一些很小的用户，即使没有粉丝，我也希望他的内容可以有一些曝光，有曝光就会有人去点赞，久而久之会形成一种良性循环。
如果平台总是分发一些大 V 的内容，平台里小白用户的使用和体验就会变得非常糟糕，慢慢的就没有这些小的内容窗口了，平台将被大 V 占领，所以覆盖率也是一个推荐系统需要考虑的指标。
至于具体需要去考虑哪些指标，以及怎么去制定这些指标，我觉得要根据不同的产品形态以及产品不同的阶段而定。
那么面对这些指标，我们有给力的分析工具去支持我做这件事情吗？比如我想对比推荐系统的转化率和另外一个 banner 的转化率区别的时候，我们的分析工具具备这种能力吗？
在我的日常工作中，是依据神策分析去做整个转化率漏斗分析，以及留存分析等。留存分析其实是一种比较复杂的分析方法，它强调的维度比较多，它可能要从各个时间段以及各个条件去分析用户的留存行为。
如果想要去分析推荐效果对于留存的影响，可以直接在神策分析中去做留存率的分析。

另外，跟大家分享一些关于迭代的思路。
以下图为例，我们分析推荐系统在 12 月 18 号新增用户上的不同表现。

我们想知道，对于新用户和老用户而言，推荐系统的这次迭代表现究竟如何。
从图中可知，新用户在第二天有一个明显的提升，但是老用户并没有。说明这一次模型的上线对于新用户而言效果是较好的，我们要进一步去分析——为什么会对新用户的效果提升明显而对老用户没什么效果。
可能是因为使用的数据采样方式对于新用户更加有利，或者是因为对于新用户的特征反馈比较及时，而对老用户的一些长期特征做了一些不太合适的处理方式等等，都有可能。
所以，实现一个好用的推荐系统，可能面临这几方面的挑战：
第一，数据获取和处理质量，就是我前面提到的如何做数据的采集，以及如何做特征工程。
第二，将算法跟业务结合，我们怎么去深入地理解业务场景，以及去选择合适的算法方案。
第三，构建推荐系统和评价体系，以及如何去解决在线服务这部分的挑战。
第四，成本控制，当我们去从头构建算法、数据、在线服务以及评估方法这几个方面的事情时，人力和时间都会耗费相当大的成本。
最后回答演讲刚开始时大家问我的一个问题——如何搭建一个闭环，让其流程化体系化。其实就是神策智能推荐系统的核心优势——全流程、实时、可快速迭代的推荐闭环。

通过我的分享，大家也可以看到我们在实际构建一个推荐系统时，会遇到各种各样的问题，基于之前的经验，数据质量是非常需要注意的一部分。它包括全端采集数据、数据处理和建模、标签体系和用户画像建立。
接着，当我们有了数据后我们就去构建算法，我们拥有丰富的算法建模经验，并且数据基于神策分析，拥有实时数据反馈和快速的建模能力。
在算法生效之后，我们会对结果进行多维的验证分析，一方面我们要对于本次的推荐效果有一个认知，另外一方面要明白后续将如何改进。同时，在我们提供的解决方案里，还有两个比较重要的环节。
第一，神策数据是一家支持私有化部署的公司，所以神策智能推荐系统同样支持私有化部署，一整套系统都部署在客户自己的服务器层。
第二，具有开放性。各种中间数据和接口客户都可以自己去调用，比如我们帮助客户采集行为数据，在构建整个推荐系统时所生成的各种用户画像和模型结果，以及内容分析的一些结果，还有各个阶段产生的一些模型方法，客户都可以去调动。神策数据的解决方案是一个开放性的白盒，从实验设计，到数据的采集，到中间的特征工程，到模型构建，到最终推荐结果，里面的数据和接口都可供客户访问和查看。
最后，我想强调两点内容：
第一，推荐系统不只是算法，它是一个系统工程，算法只占四个部分中的一部分，通常我们去实现一个推荐系统时，构建算法的时间通常只占 20% 到 30%。
第二，数据先行，数据是一切算法的前提，根据过去的经验总结，很多时候真的不是因为模型的问题，也不是因为服务的问题，而就是因为数据没有做对，导致我们推荐系统的效果没有那么符合预期。
以上就是我从多年的工作经验和实践中总结出的一些关于推荐系统的思考，希望能对大家的工作有所启发。