您好、欢迎来到现金彩票网!
当前位置:双彩网 > 向量化 >

数据算法:推荐系统的实践与思考(上)

发布时间:2019-06-19 21:12 来源:未知 编辑:admin

  本文内容来自神策数据《智能推荐——应用场景与技术难点剖析》闭门会分享内容整理,分享者将我们介绍:如何从四个方面做一个推荐系统。

  在工作中,大家遇到的与推荐系统相关的问题是:“数据太稀疏、数据没有形成闭环、数据没办法跟其他系统结合”等等。

  这些内容是摆在我们面前的实际问题,那么当我们真正要开始做一个推荐系统时,需要从几方面考虑问题呢?

  1. 算法:到底应该选择什么样的算法?无论是协同过滤还是其他算法,都要基于自己的业务产品。

  2. 数据:当确定了算法时,应该选择什么样的数据?怎样加工数据?用什么样方法采集数据?

  有句话叫做“机器学习=模型+数据”,即便拥有了一个很复杂的模型,在数据出现问题的情况下,也无法在推荐系统里面发挥很好的效果。

  3. 在线服务:当模型训练完毕,数据准备充分之后,就会面对接收用户请求返回推荐结果的事项,这其中包含两个问题:

  (1)返回响应要足够迅速,如果当一个用户请求后的一秒钟才返回推荐结果,用户很可能因丧失耐心而流失;

  (2)如何让推荐系统具有高可扩展性。当 DAU 从最初的十万涨到一二百万时,推荐系统还能像最初那样很好地挡住大体量的请求吗?这都是在线服务方面需要考虑和面临的问题。

  一方面,我们要持续迭代推荐算法模型与结构;另一方面要去构建一套比较完整、系统的评价体系和评估方法,去分析推荐效果的现状以及后续的发展。

  我会从以上四个方面,跟大家分享一下我们在实际情况中遇到的一些问题以及总结出的解决方法。

  假设我们拥有一部分用户标签,知道每一个用户的年龄、性别等信息,当某类年龄和某种性别的用户喜欢过某一个物品时,我们就可以把该物品推荐给具有同样年龄、性别等用户标签的其他用户。

  与用户标签的思路相似,如果用户喜欢过带有内容标签的物品,我们就可以为他推荐具有同样标签的内容。

  但很明显,这种基于标签的方法有一个重要的缺点——它需要足够丰富的标签。也许在多产品中,可能并没有标签或者标签数量非常稀疏,所以标签的方法显然不足以应对。

  另外,协同过滤也是一种非常经典、被较多人提及的一种方法,是一种常见且有效的思路。

  随着技术的不断发展,基本从 2012 年以后,深度学习几乎被整个机器学习界进行反复的讨论和研究。

  谷歌在 2016 年提出一套基于深度学习的推荐模型,用深度学习去解决推荐的问题,利用用户的行为数据去构建推荐算法。

  看似很难的推荐系统,其实也有简单的思路——做人和物的匹配,把该用户可能感兴趣的物品推荐给他(她)。

  在推荐领域,深度学习的目的之一就是尝试将人和物向量化,即把某个人和某个物品学习成一种统一的表示方式,随后在这个统一的表示方式中计算这个人和物品的相似度,当人和物都映射到同一个可比较的空间中时,就能够基于计算结果去执行相关的内容推荐。

  把最终的结果映射到这张二维的平面图表里,用户认为相似的内容就会映射在向量上。当拥有内容向量之后,之后再将用户映射进来即可。

  比如:用户到达了上图某个地方,根据他所处的位置,可以向其推送教育、娱乐、科学、地理等内容。

  讲到这里,有些朋友就会提出疑问:既然深度学习如此复杂,那在实践中究竟有没有作用?

  其实,站在实战经验的角度来看,当具备一定的数据量时,会带来比较明显的效果提升。但当你要去搭建一个深度学习模型的时候,可能真的会遇到很多问题。

  比如:用多少数据量去训练模型是可以的?训练数据该用什么格式?多“深”才算深度模型?训练模型太慢了怎么办等。

  资讯场景的需求往往是将发布的新内容(如 10 分钟内发布的内容),以实时且个性化的方式分发到用户的推荐结果中去。

  上图这篇文章在 17:41 发出,那么就需要在极短的时间内根据这篇文章的内容去做一些个性化的相关推荐。

  此文内容围绕美食展开,用户点开这篇文章之后,文章的相关推荐里面就要有跟美食相关的一些内容。

  当我们要在如此实时的环境中实现推荐效果的话,其实没办法去依赖用户的行为。这时,我们尝试提供一种思路,一种基于深度学习的语义理解模型。这个模型跟我们前面分享的内容有一个很大的区别就是——不需要用户行为,只需要分析用户文本,基于用户的内容去给每一篇文章生成一个向量。

  比如说:今日头条的 Feed 流,淘宝的“猜你喜欢”等,都拥有一个非常复杂的推荐系统,这个推荐系统中的各个模块可能会涉及到很多的实验算法。在一个系统中,出现 10 个或者 20 个模型都很常见。

  召回,即从海量的内容里去召回每一个用户他可能感兴趣的内容。前提是——拥有海量的内容,因为当内容不足时,也就不需要去搭建复杂的推荐系统。

  所以,当有海量 Item 时,需要用召回的算法,从不同类别的内容里为用户生成可能感兴趣的内容。

  比如:某位用户既喜欢体育内容,也喜欢军事内容。那么在第一步,无论用哪些模型,都希望达到为该用户生成一些体育、军事相关内容的效果。

  另一个用户可能喜欢美食和游戏,在召回阶段,我们就希望通过模型去为他生成一些美食和游戏相关的内容。

  在召回阶段可能就会存在许多个模型。而经过召回阶段之后,尽管生成的是该用户可能感兴趣的内容,但这些内容实际并没有融合到一起,是一种乱序的状态。

  排序过程其实就是给每部分内容打分的过程,预测每一个用户对每一部分内容的感兴趣程度,从而获知每一个用户对每部分内容的偏好程度。

  推荐系统常常跟产品或者业务场景紧密相连,而在产品中一定有一些需求是无法用模型来解决的——因为模型只能从用户行为或者文本内容中去发掘用户和物品之间的关系,所以有些常见的业务需求要通过规则去实现。

  部分推荐场景中会出现一些运营精选的内容,运营同事的需求是:保证每十条内容中都有一条编辑精选内容,而这个需求,只能通过规则实现,而不是通过算法。

  首先召回用户感兴趣的内容,第二为用户生成一个排序列表,第三用规则解决一些产品、运营方面提出的需求。

  总是会听到一个这样的说法,“推荐算法的效果是由模型与数据所决定的”;即模型只占推荐效果中的一部分,另外一个非常重要的部分就是数据。

  那么我们究竟需要哪些数据?在一个实际的推荐系统中,哪些数据是有可能发挥作用的?我们又能拿到哪些数据?

  用户行为数据最为重要,几乎没有哪一个推荐系统可以直接表示不需要用户行为数据。

  一方面,用户行为数据是训练模型中的一个重要数据来源;另外一方面,需要通过用户的行为反馈,技术同事才能知道推荐系统到底做得如何。

  搭建推荐系统的一个秘籍就是积累用户行为数据,如果没有将重要的用户行为做采集,例如在电商场景中,如果只是记录最终的下单数据,那么离推荐系统的数据要求还是有一定的距离。

  以电商场景为例:在录入一件具体物品时,录入商品的品牌、价格、品类、上架时间等就是我们要收集的物品信息。

  假设在电商场景中,如果并不清楚每个商品的品牌,也就无法从一些物体的描述信息中去提取某个商品到底属于何种品牌,那么推荐效果自然受到限制。

  但在很多实际场景中标签数量少、维度粗,可能根本不具备去给用户打标签的能力,这种传统的“标签式”想法,就会限制搭建推荐系统的思路。

  而从深度学习的角度出发:用户画像中储存的并不是通常理解的“标签”,他可能存储的是这个人的向量。

  深度学习是把人和物品做向量化,但这个向量是不可被理解的,即我们可能并不知道这个向量表示的是什么意思。

  当我们看到某个用户对应的向量,我们也不知道他是对体育、音乐或是娱乐感兴趣,但我们仍能够通过向量去为他推荐其感兴趣的内容。

  有的人会迷信外部数据,觉得自己的数据量不够,所以一定要去购买阿里或者是腾讯的外部数据来充实用户画像,从而提高推荐系统的效果;甚至有人认为推荐系统效果不好,是因为没有外部数据。

  但其实,外部数据对于推荐系统的效果,个人认为还需要一个极为谨慎的推理和验证。

  首先,要先验证自己的这批用户群跟所购买的外部数据能发生多少交集。假如一个游戏平台,购买了阿里的外部数据,而这样的外部数据可能只能告诉你用户到底是喜欢买衣服、买车还是买电子产品,这样的信息对游戏平台有用吗?

  假设购买的外部数据恰好命中了业务场景,可能会发挥一定的作用,但实际上,能够同时命中用户群体和标签的情况也并不常见。

  其实我和我们神策团队在去构建一个实际的推荐系统时,消耗我们人力的地方往往不是算法,反而是怎么去得到正确的数据。接下来我们以用户行为数据为例,与大家分享应该如何获取我们所需要的用户行为数据?

  这时候我们就要思考,当我们想去获取用户行为数据时,到底希望用户行为数据能给我们带来什么样的作用?

  比如:我给某个用户推荐十件商品,其中有两件商品发生了点击行为,模型中就会觉得这两条数据是正例,其他是负例。所以,我们需要用户行为数据作为模型的训练数据。

  比如:点击率上升说明效果变好,点击率下降、负反馈变多、用户流失,说明推荐系统可能出现了问题。

  模型上线一定要基于 A/B Test,我们需要知道此次上线到底比之前的推荐算法、推荐系统等效果如何。

  这样,我们才能判断这一次的迭代是否有效,如果有效就将其全量;如果无效,则进一步迭代。

  比如:点击率并没有发生变化,甚至效果变差,毕竟不可能每一次迭代的效果都是上升的,所以我们希望行为数据能够定位到此次推荐系统上线后效果不理想的原因;如果上线后效果不错,此时我们希望行为数据能够分析到底是哪些因素使效果变好。

  以曝光日志中的第一个字段 exp_id 为例,exp_id 的中文的意思是实验 ID。

  前面提到了我们希望用户行为数据是能支持 A/B Test 的,那么如何知道每一条数据是来自哪一组实验呢?

  此时,我们需要一个 exp_id 字段去记录每一条曝光日志是来自哪组实验。

  当我们再次分析 A/B Test 效果时,就可以根据一个 exp_id 字段去区分不同实验所带来的曝光和点击。

  在曝光日志中我们常常讨论如何设计一些常用字段,而另外一个具体问题就是——我们怎么去采集这些数据?

  简单来说,当用户在产品里面发生一些用户行为,怎么把这个数据最终落到服务器的日志中,从而用于模型训练和效果分析呢?

  SDK 埋点的接入成本低,它有比较成熟的埋点事件和埋点验证方案。另外 SDK 有埋点接口和文档指导客户埋点,无需关注上报问题。

  SDK 埋点的容错性比较高。如果是自助埋点,从客户端到推荐引擎经过了服务端,数据出现问题,难以回溯埋点问题、传输问题、数据质量维护成本高,SDK 埋点就会相对方便。

  商品维度。在商品的维度里,我们可能关注一些商品的品类、品牌、价格、所面向的性别,以及各种用户行为反馈的一些数据,比如:点击率、收藏比率等。这些内容一方面体现了商品本身的一些属性,同时还体现商品的质量。

  用户层面,通常首先考虑用户的年龄和性别。因为在电商领域中男性所偏重的商品和女性之间存在较大差异。另外还有用户的品类偏好、品牌偏好,以及价格偏好等。

  某一次小的流量上线之后,我和团队成员发现效果不如预期,根据以往的实践经验来说,不应该是这么差的结果,当我们去分析数据时,发现有两个方面的数据异常:

  1. 命中行为模型的用户较少。通常情况下,只要不是一个新用户,理论上来说,都应该能够命中我的行为模型。我们当时的新用户比例在 20% 以下,而命中模型的用户大概仅为 30%,说明大量的用户没有命中到模型。

  2. 很多请求的 ID 未出现在日志中。当时我们怀疑,是否我们的推荐结果被别人作弊刷掉了。因为用“作弊”能很好地解释这些请求并未落到日志中的原因。

  但最终,我们发现并不是作弊的问题,而是因为用户 ID 没有统一:前端在用他们理解的一套用户 ID 体系打日志,但是后端在用另外一套用户 ID 体系发送请求。

  于是所有的数据无法对上,后端过来的请求总是新用户,而训练出来的模型命中不了任何用户。

  最终,我们建立了一系列的方法和工具以及流程去保证整个用户 ID 体系的一致性。

  以上就是神策数据算法专家对推荐系统的实践与思考的前两点“算法”与“数据”的分享,由于篇幅限制,“在线服务”和“效果评估”将在下一篇文章进行介绍,希望对你有帮助!

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立8年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。

http://chinoamobi.com/xianglianghua/174.html
锟斤拷锟斤拷锟斤拷QQ微锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷微锟斤拷
关于我们|联系我们|版权声明|网站地图|
Copyright © 2002-2019 现金彩票 版权所有