以下内容分三部分：算法的核心；算法有多大用；实际工程中算法怎么工作的

1. 算法的核心是什么

推荐算法的核心是基于历史信息寻找被推荐的东西(可能是人、物、信息)与用户的一种关联性，进而去预测你下一步可能喜欢什么，本质上还是基于统计学的一种推测（谷歌的深度学习除外）。

这里有两个关键点：历史信息；关联性

历史信息也就是大家所说的标准化数据

关联性也就是大家常说的算法，他做的事情就是猜测你可能会喜欢怎样的东西.要搞清楚这个问题，还是得回到人在不同的场景中会喜欢怎样的东西，这个在不同的场景中差别比较大。举两个例子说明一下

对于微信朋友圈：用户最关心的是我跟发布者的亲密度，其次是内容的质量和内容的发布时间，这也就是Facebook智能信息流的雏形，根据跟发布者的亲密度，内容的质量和内容的新鲜程度的一个混排算法。

对于美团外卖：用户最关心的是这家餐厅好不好吃，价格贵不贵，有没有优惠，配送时间长不长。至于我认不认识这家餐厅的老板，这家餐厅开业时间就不是重点，所以算法就可能是完全不一样的思路。

不管Facebook信息流还是美团外卖，核心还是得去理解用户在你的产品中到底喜欢怎样的东西，这个是基础，算法只是工具。

2. 算法真的有那么大效果吗

这几年今日头条的成功，包括业内各种AI、人工智能的吹，让我们以为算法无所不能，实际上算法真的有这么神奇吗？

答案是没有。。。

今日头条的成功我认为主要还是靠对流量的理解，战略和公司的运营、算法、数据化思维形成的执行力。算法在里面只是一环

举一个淘宝的例子，去淘宝的人从需求的强弱程度来看分三种：明确知道我要买啥的，知道我要买啥品类但具体买啥不知道，就是来逛的。

第一类算法没有增长点，我就要买个苹果的iphoneX，你再怎么推荐我也是买个苹果X

第二类算法的增长点一般，我要买个蓝牙耳机，算法处理的好能提高成单率，客单价，利润，但也是有限的，因为用户进来之前已经有了一些基本的预算之类的预设。

第三类是比较大的增量空间，因为第三类属于激发性需求。就像你去商场听导购一顿忽悠，买了本身不需要的东西。但是第三类的成单量本身的占比并没有那么大。

所以综合下来，算法实际的效果也就是在完全没有算法的基础上有1.1，1.2，1.3倍这样的效果，这是由用户的需求总量决定的。

当然我不是说算法没用，因为在同等成本结构的基础上，你的转化率哪怕比竞争对手高5%，那也是巨大的效率碾压。我只是想说算法没有大家吹得那么厉害，并不能直接决定一家公司的成败，算法只是一个辅助。

3. 水果店案例说明算法在实际工程中的工作过程

在实际的商品类的推荐系统中，主要分三大块：收集数据和整理（商品画像、用户画像）；算法推荐；上线实验及回收结果。

收集数据及整理

假设小明开了一个有3家分店的大型水果连锁店，收集数据阶段主要包括：

商品属性信息：小明将店内的每一个水果以及水果的信息都记下来，甜的还是酸的，品质S还是A，有没有损坏，性寒还是热，单价贵不贵，有没有优惠等等。这是商品的基本属性信息。

商品反馈信息：销量咋样，停留率咋样，停留转化率咋样，用户的评价反馈咋样。这个是基本的反馈信息。

人的基本属性：什么人，什么小区，穿着打扮咋样，年龄多大，哪里人

人的行为信息：这次买了啥，下次买了啥，看了啥，咨询过啥，买完之后反馈咋样。

数据阶段收集是一方面，最关键的是收集的数据是结构化的，是在用户的购买决策中是有效的，比如说用户中途出去抽了一根烟这种信息就没啥用。。。

算法推荐

算法阶段关键的还是搞清楚用户在不同的场景中会喜欢怎样的水果。

我个人喜欢把商品推荐主干算法分为4个部分：质量评估，个性化，场景化，人工干预

质量评估：有些标准是存在绝对的好与坏的，水果是不是好的，性价比高不高，销量好不好，优惠力度大不大，用户反馈好不好这些是存在绝对的好与坏的，我相信没人想买个烂苹果。

个性化：有些东西是存在个体差异的，甜的还是酸的，进口的还是国产的，水果的品种是樱桃还是芒果，性凉还是热的，品质分级是S还是A（跟前面的烂没烂两个概念）。

举个例子：一个金融白领可能喜欢的是甜的车厘子，进口的，品质S级的，优惠不敏感，客单价高；而小区的家庭主妇喜欢的可能是杨梅，品质还过得去的国产的就行，很在乎优惠，客单价适中的。那对于前一种用户就可以推一些客单价高的，毛利高的进口产品，相应的也可以少设置优惠；对于后一种就应该推一些性价比高的，有折扣的清仓的商品。

场景化：不同的时间和地点会一定程度上影响用户的消费决策，比如夏天大家喜欢吃西瓜，在医院边上香蕉好卖，中午的时候不带皮可以直接吃的东西好卖因为大部分下午还要上班，晚上则需要处理的也卖的还可以。这个就是不同的场景带来的影响

人工干预：算法本身是不带意志的，但是很多时候人会强加一些意志上去，比如说最近年底冲业绩了，需要强推高毛利的商品了；比如这个樱桃是合作方的，需要强推；比如有些东西快过期了，需要强推。这个时候就需要人工去做一些干预

算法最后做的就是把里面每一个环节打上一个分，最后再把这些因素去加总得到一个最后的结果呈现在用户面前。但是这个分怎么打？这个就涉及到算法的价值观

所谓算法的价值观，就是你希望算法最终的结果是怎样的，我是希望销量最大化还是销售额最大化还是利润最大化。不同的目标带来不同的结果。因为算法只是为目标最大化负责的。

算法在处理每一项得分的时候也挺简单，简单说就是，如果我的目标是销量最大化，那有两个特征：优惠力度，评价，如果随着优惠力度的提高购买转化率急剧提升，那么我认为优惠力度这个特征权重就高，如果随着评价的提升购买转化率提升较慢，那么我认为评价这个特征的权重就一般。

这个过程并不复杂，算法的优势在于他能记录更丰富的信息（工程中特征数量可能达到百万级），处理海量的数据。这是算法比人有优势的地方

这个大概能支撑起一个算法的框架，实际的应用中会在一个主干算法的基础上去迭代很多小的策略。

下面举几个具体的细分迭代策略：

比如说买了芒果的用户很大比例都买了樱桃，那相应的会把买芒果的用户列表中的樱桃相应的往前提。这个就是大家常说的购物篮算法

比如说同样是国贸摩根大厦的用户更喜欢进口水果，那对于一个摩根大厦的用户他列表中的进口水果，高客单价水果需要往前提。这个类似协同过滤，通过找到跟你类似的人，再去看他们喜欢啥。

比如说你第一次买了榴莲之后打了差评，以后就需要降低榴莲及相关水果的权重。这个就是负反馈。

比如说你的列表中连续出现了3种葡萄，那这时候大概率是应该把他们打散一下，尽量一页别出太多葡萄。这就是打散

比如当你在浏览的过程中点击了樱桃，那根据购物篮原来喜欢买樱桃的人也喜欢买芒果，那下一页加载的时候需要动态的增加芒果的权重  — 这个是实时反馈

实验及回收效果

个人认为快速的实验迭代和效果回收是算法高效率的关键，也是互联网的核心。修路造桥错了就是错了，而互联网产品这版效果不好下一版还能优化。算法是将这种快速迭代推向了顶峰，同时几十个实验在线上AB测试，不需要发版，好不好马上就能看出来。

AB测试的过程有点类似如果我有5家水果店，我要验证新引进的樱桃设置怎样的价格能收益最大化，我可以5家店同时设置5种价格，卖一周看看结果。

实验主要分两个部分：实验及效果回收

实验就是在其它东西都一样的情况下，留出一个不一样的东西，然后观察最后的结果，这样比较好确定最后的结果差异就是由这个不一样的东西带来的。

效果回收主要是看数据和人去看实际推荐的结果，看数据需要覆盖多一些的指标，因为很可能销量好了毛利降了，或者毛利好了当天剩余率升高了。

人工去看结果主要是一个二次确定的过程，比如在头条里面各种数据都很好，但是推出来的内容很低俗，或者这种数据好人看完之后凭经验知道这不是长久之计，比如周围就一家水果店你恶性提价。。

作者：s_crat

在近日发表的一篇博客文章中，Facebook首次揭开了Explore内部的运行机制。Facebook称，Explore是个由三部分组成分级漏斗，使用自定义查询语言和建模技术，目前已提取了650亿个特征，每秒可以做出9000万次模型预测。而且，这些还只是冰山一角。

在开始构建内容推荐系统之前，开发团队已经使用大量工具进行了大规模实验，并获得关于用户关注兴趣的强烈信号。研究人员使用的首款工具是IGQL，这是一种元语言，能够提供对候选算法进行集中聚合所需的概要信息。

Facebook表示，经C++优化的IGQL可在不牺牲可扩展性的情况下最大程度地降低延迟，减少计算资源的消耗。工程师能够以“类似Python”的方式编写推荐算法，并补充了帐户嵌入组件，可以识别局部高度相似的配置文件，并将其作为帐户级信息的检索流程的一部分。

上图：ig2vec预测账户内容相似性的功能演示

Ig2vec框架将用户与之交互的Instagram帐户视为句子中的单词序列，通知用户可能与之交互的模型预测。（与随机帐户相比，会话中进行交互的一系列帐户在局部上的连贯性更高。）同时，Facebook的AI会搜索最近邻域检索库（FAISS）来查询数百万个帐户进行训练。

Facebook表示，在Explore中基于兴趣对账户进行排名，需要预测与每个账户相关度最高的内容，生成轻量级排名提炼模型，该模型在将候选账户传递给更复杂的排名模型之前，会对账户进行预选。利用较复杂模型的特征和输出的候选输入的知识，较简单的模型会尝试通过直接（和间接）学习来尽可能近似主排名模型。

Explorer运行包括两个阶段：候选内容生成阶段（也称为“采购”阶段）和排名阶段。

在生成阶段，Explore会挖掘用户以前与之交互过的帐户，以识别感兴趣的“种子帐户”。这些账户只是兴趣相同的帐户的一小部分，但与“兴趣相同”账户筛选结合使用，可以更高效地识别局部相似的帐户。

了解可能吸引用户的帐户是哪些，这是确定哪些内容可能会被筛选出来的第一步。IGQL允许将不同的候选内容源表示为不同的子查询，这样Explore就可以在多种类型的内容源中为普通人找到成千上万的合格候选内容。

上图所示为一个典型的Explore推荐内容源

为了确保推荐内容的安全，适合所有年龄段的用户，系统利用信号来过滤可能不符合要求的内容。在为每个用户建立推荐列表之前，会由算法进行检测，过滤垃圾邮件和其他内容。

根据Facebook最新的社区标准执行报告的内容，这套过滤系统非常有效。在2019年第三季度，Facebook删除了涉及自残内容数量达到84.5万条，其中主动检测到79.1％，在过去四个季度中，Facebook删除了超过99％的儿童裸体色情内容和剥削职位。

对于每个“explore”排名请求，系统将从数千个采样样本中选择500个候选，并将结果送至排名阶段（即上文所说的第二阶段）。这个阶段由三部分的基础架构组成，旨在实现内容相关度和计算效率的平衡。

在排名阶段的第一阶段，滤过模型以最少的特征数量模拟其他阶段的组合。它从500个最优质和最相关的候选内容中选出1个，然后，具有完全密集特征集的模型（第二阶段）会选择前50个候选内容。最后，另一个具有全特征的模型将选择25个最佳候选内容，这些候选内容将填充至“explore”网格中。

上图：当前最终通过模型架构的图示

有时，首次滤过模型会按照内容排名顺序模仿其他两个阶段的模型。这是个修补程序，实际是一种多任务，多层算法，可以预测人们可能对相关内容做出的行为。

比如点“喜欢”或“收藏”之类的“积极”行为，以及点“不再查看这类内容”等“消极”行为。算法会使用值模型公式进行预测，以获取行为的集中程度，然后加权和确定用户行为的重要程度，比如“保存”帖子和“喜欢”帖子的重要性孰高孰低。

为了在新内容和现有内容之间保持“丰富的平衡”，Explore团队制定了一条规则，以促进内容多样性：添加惩罚因子，这一规则降低了来自同一作者或种子帐户的帖子的排名，因此用户不会在资源管理器中看到来自同一个人或同一种子帐户的多个帖子。

Facebook表示：“我们以代际方式根据每个排名候选内容的终值模型得分，对相关度最高的内容进行排名。”Explore的最激动人心的部分之一是寻找新的有趣方式来帮助社区发现Instagram上最有趣和最相关的内容。我们还在不断继续开发Instagram Explore。无论是添加新格式的媒体，还是不同主题的帖子（比如购物帖），都是很有趣的体验。”

首先看短视频发布后抖音一般会进行的一系列推荐流程

第0步：双重审核

在抖音，每天有数量庞大的新作品上传，纯靠机器审核容易被钻空子，纯靠人工审核又不太现实。因此，双重审核成为抖音算法筛选视频内容的第一道门槛。

机器审核：一般是通过提前设置好的人工智能模型来识别你的视频画面和关键词，它主要有两个关键作用：其一，审核作品、文案中是否存在违规行为，如果疑似存在，就会被机器拦截，通过飘黄、标红等提示人工注意；其二，通过抽取视频中的画面、关键帧，与抖音大数据库中已存在的海量作品进行匹配消重，内容重复的作品进行低流量推荐，或者降权推荐（仅粉丝可见、仅自己可见）。

人工审核：主要集中在3块：视频标题、封面截图和视频关键帧。针对机器审核筛选出疑似违规作品，以及容易出现违规领域的作品，抖音审核人员进行逐个细致审核。如果确定违规，将根据违规账号进行删除视频、降权通告、封禁账号等处罚。

第一步：冷启动

抖音的推荐算法机制是著名的信息流漏斗算法，也是今日头条的核心算法。通过审核后，第一步叫冷启动流量池曝光，比如你今天上传一个视频，通过双重审核的作品，系统将会分配给你一个初始流量池：200-300在线用户（也可能有上千个曝光）。不论你是不是大号，只要你有能力产出优质内容，就有机会跟大号竞争。

第二步：数据加权

抖音会根据这1000次曝光所产出的数据，结合你账号分值来分析是否给你加权，比如完播率、点赞、关注、评论、转发、转粉、游览深度等。

以上这些都会对你的短视频数据造成影响，以及对你的短视频作出是否要加权的判断，然后会挑选前10%的视频，再增加1万次曝光。

第三步：加大推荐

这一步会给数据好的短视频进行更大的加权，并且会在第三步强化人群标签分发，让内容分发的更加精准，这类似猜你喜欢的打标，视频是有标签的，用户也是有标签的，两者之间会做标签匹配。

第四步：进入精品推荐池

进入精品推荐池，大规模曝光，一旦进入精品推荐后，人群标签就被弱化了，就像当年温婉的视频，几乎每个抖音用户都会刷到温婉的视频。

其他概念和现象

延后“引爆”

不少抖音运营者会发现，有些内容发布的当天、一周甚至一个月内都数据平平，但突然有一天就火了，为什么？两种原因：

第一种，被很多老司机戏称为“挖坟”。它是指抖音会重新挖掘数据库里的“优质老内容”，并给它更多的曝光。这些老作品之所以能被“引爆”，首当其冲是它的内容够好，其次，是你的账号已经发布了很多足够垂直的内容，标签变得更清晰，系统能够匹配给你更精准的用户。优质内容+精准用户，老作品重新火爆起来就不意外了。

第二种，我们可以称之为“爆款效应”，它是指，你的某一个作品在获得大量曝光（几百万，甚至千万级）时，会带来巨量用户进入你的个人主页，去翻看你之前的作品。如果你的某一个作品，能够获得足够多的关注（转评赞），系统将会把这些视频重新放入推荐池。很多垂直内容的创作者，往往都是因为某一个视频的“火爆”，直接把其他几个优质视频“点燃”，形成多点开花，全盘爆炸引流的盛况。

流量触顶

抖音作品经过双重审核、初始推荐、叠加推荐层层引爆之后，通常会给账号带来大量的曝光、互动和粉丝。而这种高推荐曝光的时间，一般不会超过一周。之后，爆款视频乃至整个账号会迅速冷却下来，甚至后续之后发布的一些作品也很难有较高的推荐量。为什么？

抖音每天的日活是有限的，也就是说总的推荐量是基本固定的：一方面，跟你内容相关标签的人群基本完成推荐，其他非精准标签人群反馈效果差，所以停止推荐；另一方面，抖音也不希望某个账号迅速火起来，而是通过一轮轮考验，考验你的内容再创新能力，考验你持续输出优质内容的能力。

来源：腾讯QQ大数据

前言

自手Q游戏中心V6.0改版以来，产品形态发生了较大的转变，不再是纯粹通过app列表做游戏分发，而是试图通过内容来带游戏分发，全新的产品形态给推荐算法带来了许多的挑战。截至4月初，算法一期的工作已接近尾声，借此机会写下总结，一方面是将整个游戏中心的推荐逻辑进行梳理，并将其中的一些经验沉淀总结，方便回溯；另一方面也试图在梳理的过程中，整理出遇到的一些挑战，能够更加明确算法二期的一些迭代思路。

手Q游戏中心作为腾讯手游重要的分发渠道之一，既是用户发现感兴趣游戏的重要入口，同时也提供了各手游平台运营的能力。新版游戏中心不再是纯粹地通过传统app列表的方式做游戏分发，而是新增了一系列通过内容（攻略、视频、直播、礼包等）拉下载、拉活跃的场景（如图1所示）。为了更好地提升用户进入游戏中心的体验以及满足平台精细化运营（拉新、拉活、拉付费等）的需求，通过海量用户的行为流水挖掘用户游戏偏好，精准推荐用户感兴趣内容成为了必然趋势。为此，我们设计了全新的个性化推荐框架，给业务带来了显著的转化率提升。

图1：游戏中心个性化推荐场景

       为了更好地制定算法二期的迭代计划，本文主要对算法一期的工作做一个简单的复盘，一方面是将项目开展过程中的一些经验进行总结沉淀，另一方面也是想对游戏中心推荐场景中比较有挑战性的问题进行梳理，以便算法二期迭代过程中更加具有针对性。

本节主要结合游戏中心个性化推荐的算法框架（如图2所示）以及工程框架（如图3所示），对项目过程中遇到的一些问题进行总结归纳。游戏中心所采用的推荐框架是业界常见的三段式推荐逻辑：offline—nearline—online。离线层主要负责存储全量用户在游戏中心的流水数据、计算用户长期的行为属性以及训练用户的游戏偏好模型等；近线层主要是为了解决离线层计算周期长，响应速度慢的缺点，通过实时计算用户的短期兴趣，反馈到线上，从而能够对用户在游戏中心的行为做到实时反馈；在线层可以理解为推荐引擎，主要是对业务请求通过一系列的计算，返回最终的推荐结果列表，在线层可以细分为召回层—精排层—重排层结构。

图2：游戏中心个性化推荐算法架构图

图3：游戏中心个性化推荐工程架构图

• 离线层

离线层适用于用户长期兴趣的计算、离线模型的训练、模型参数的实验以及其他对时效性要求不高的任务，因此离线层主要采取HDFS+Spark的工程实现（批处理的计算方式）。业务数据通过DC或者TDBank上报，累计一定的数据量（游戏中心是以每小时为周期）周期性落地到HDFS或者TDW中以库表的形式存在，以Spark为计算引擎，对库表数据进行一系列处理后，将结果数据推送到线上存储，构成线上推荐引擎的重要数据来源。对于游戏中心这个场景，离线层的工作流可以划分为6大步骤：推荐物料的准备、数据处理、样本设计、特征提取、模型训练、数据上线。

1、推荐物料的准备

对于推荐系统来讲，第一个需要确定的就是推荐物料（也就是推荐池子）。游戏中心推荐的物品主要有两大类：第一大类就是游戏app，目前游戏中心接入算法的游戏app主要包括精品游戏、单机游戏，基本上每天变化不大，因此该类物料由业务每天例行上报更新并推送到线上存储即可。第二大类就是游戏内容了，主要包括攻略、视频、直播等，该类物料相对来讲实时性要求会高一些（新游上线当天需要内容同步更新）。目前游戏中心的内容来源数据链路如图4所示，主要来源是一些上游PGC内容的采购，经过自动Tag提取之后进入到标签内容库，算法侧直接从标签内容库获取推荐物料，目前是按小时更新。

图4：内容源数据链路

2、数据处理

熟悉推荐流程的同学可能比较清楚，数据处理过程繁琐枯燥且耗时较长，占据了整个算法开发周期60%以上的时间，贯穿整个开发流程。没入坑之前有些人可能会以为推荐算法工程师是一个高大上的职位，每天舒舒服服地看下paper，研究下算法，做下实验，特别酷。入坑之后就会发现，每天干的最多的活就是处理数据。但这也充分说明了数据处理的重要性，毕竟只有充分了解数据才能更了解业务，才能更加合理地设计你的推荐策略。这儿讲的数据处理主要包括数据验证、脏数据过滤以及数据转换等。下面主要总结一下在数据处理过程中所踩过的坑：

（1）一定要做好数据上报准确性的验证：前端同学有时候可能不是特别了解算法同学对于上报数据的诉求，所以在上报的时候可能会出现目标不一致的情况。常见的情况有：上报逻辑出错（分页feeds曝光只上报了第一条feeds的数据）、上报id错位（曝光的operid报了下载的数据），上报id缺失等。而验证数据上报准确性的常规操作就是打开游戏中心，将每个场景你有可能会用到的用户行为都操作一遍，记下操作时间，一个小时后从流水中捞出你的数据，逐一验证是否合理（噩梦）。

（2）推荐逻辑出现问题时候优先考虑数据的准确性：当推荐结果产生问题或者出现bug的时候，优先检查数据的准确性。模型的鲁棒性以及容错性一般都较高，最可能出现问题的往往是数据环节。通常都是沿着数据链路往上游逐步排查从而定位问题。

（3）对业务流水数据做一层数据中间表做解耦：算法开发过程中，最好不要直接操作operid相关的逻辑，遇上业务改上报id时（比如产品改版换了新的一套operid），改代码改的你头疼。

（4）算法接入后一定要跟产品以及前端同学再三确认算法ID的上报准确性：业务在调用推荐引擎时都会获得一个算法ID，算法ID上报的准确性直接影响效果监控报表的可信度。很多时候上了一个算法策略结果发现线上效果突然下降，排查半天才发现原来部分转化行为的算法ID上报缺失，所以这儿一定要仔细验证清楚。

（5）脏数据过滤是一门玄学：脏数据的定义通常需要根据业务场景来决定，有时候信心满满地将所有脏数据都过滤之后，线上效果反而降了，所以在过滤数据时要留个心眼（什么样才是脏数据？脏数据是不是一定没用？不要想当然，还是用线上效果说话吧！）。

（6）建立完善的报表监控体系：推荐的一个重要环节就是报表监控，不仅仅包括对效果的监控，还包括对池子的监控、核心用户的监控、item场景表现的监控等。只有建立完善的监控体系，才能在推荐结果受到挑战时快速定位问题。

图5：游戏中心报表监控体系

3、样本设计

一般来讲，推荐问题都会转换成二分类问题，也就是判断用户对某个物品是否会产生操作行为（通常一个U-I对就是一个样本），那么要训练出一个看起来合理线上效果又比较理想的二分类模型，正负样本的设计显得极其重要，下面总结一下游戏中心在设计不同场景的样本时的一些经验：

（1）如何正确定义正负样本？在纯icon推荐的场景，咋一看可以理解为用户下载了该app就是正样本，没有下载就是负样本。但仔细一想这样做会产生两个问题，第一个问题就是正负样本极其不均衡（机器学习中经典问题之一），因为用户浏览几十个app可能也就下载1个app，当然，机器学习针对正负样本不均衡问题会有很多解决方法，这儿就不展开描述了；第二个问题就是用户没有下载并不代表就是不喜欢，这儿会有几个值得推敲的地方：1）用户曝光了但是从没有产生过下载行为，可能因为是无效曝光，用户关注的焦点不在这，所以无法判断用户到底是喜欢还是不喜欢；2）用户在游戏icon曝光的场景并没有产生下载行为，但是用户产生了点击行为，从而进入到游戏详情页后产生下载行为，这样是不是可以认为用户其实是喜欢的，产生的也是正样本呢？举这么个例子主要是为了说明，对于每个不同的推荐场景来说，正负样本的设计都应该充分结合业务特性，不然容易产生有偏样本。

（2）设计样本时应保证每个用户样本数的均衡：在app分发或者内容分发场景，容易存在一些刷量用户；该批用户频繁进入游戏中心从而产生多次操作行为，因此在设计样本时应对多次操作的U-I样本对去重，并保证每个用户样本数的均衡，从而避免模型被少数用户所带偏。

（3）样本权重的设计问题：在feeds推荐的场景中，不同推荐槽位所产生的样本权重应该有所不同；比方说首页feeds场景，用户刚进入场景时，注意力会比较集中，产生的负样本应该置信度较高，权重也较高；当用户下滑到后面feeds的时候，对feeds的内容可能会比较乏味了，产生的正样本置信度应该也是较高的，权重应该也设置较高。

（4）适当丰富样本来源的多样性：一般样本都是基于当前场景所产生的用户行为来选取的，而当前场景用户的行为某种程度是受推荐结果而影响的（“你给我推荐了王者荣耀，那么我只能喜欢王者，但是可能我更喜欢你没给我推的吃鸡呢”），随着算法的迭代，越到后面，算法其实是在迭代自身，越学越窄，这也是推荐系统经典的多样性问题。youtube所采用的一种缓解的方法就是从其他没有算法干扰的场景选取部分样本，来避免这个问题，而在游戏中心的样本设计中，都会单独开设一股没有算法干扰的小流量作为干净样本的补充。

4、特征提取

特征决定机器学习的上限，而模型只是在逼近这个上限。可想而知，特征设计的重要程度是多么的高。关于特征设计的方法论有很多，这儿就不具体讨论。这里主要介绍一下游戏中心各个场景在设计特征时候的通用思路以及为了解决首页feeds特征空间不一致时所采用的多模态embedding特征。

（1）通用特征设计思路：如图6所示。这儿需要提一下的是，游戏中心的推荐场景由于涉及平台利益，所以一般情况下，特征设计时都需要考虑特征的可解释性。

图6：特征设计思路

（2）多模态embedding特征向量：首页feeds流分发场景是一个具有挑战性的场景，其中一个比较有意思的难题就是待推荐的内容类型较多。传统的feeds推荐场景要么都是纯视频流、要么是纯文字feeds等，而游戏中心首页这儿待推荐的内容类型有攻略、视频、直播、活动、礼包等，而且每一种内容类型的二级承载页产品形态也不一致，这样会导致可提取的特征空间维度不一致。比方说视频承载页的观看时长与图文承载页的观看时长量级不一致，视频承载页有icon点击等操作而图文承载页则没有。特征空间的不一致会导致模型在打分的时候会有所偏颇，离线实验过程中发现视频由于特征维度较齐全，打分结果整体偏高。因此，为了减缓特征空间维度不一致问题，游戏中心首页feeds流引入了多模态embedding特征向量，该方法在企鹅电竞视频推荐场景已经取得了较好的效果（如图7所示）。多模态embedding特征向量的设计主要参考youtube的论文，从而获得每个user、item的低维特征向量，一方面解决item的原始特征空间维度不一致问题，另一方面也根据用户的历史行为，学习user、item的隐语义特征维度，起到信息补充的作用。

图7：多模态embedding网络

5、模型训练

好了，终于到了别人所认为的高大上的步骤了——模型训练，其实一点都不高大上，尤其是有了神盾推荐这个平台。目前神盾推荐离线算法平台已经集成了大部分常见的推荐算法，包括LR，Xgboost，FM，CF等，因此离线训练只需要准备好样本跟特征，配置好参数，就可以一键点run喝咖啡了（开玩笑开玩笑，是继续搬下一块砖）。傻瓜式的模型训练（调包侠）其实并没有太大的坑，但是有几点经验也在这稍微写一下哈：

（1）注意调参的正确姿势：目前神盾默认是将数据集划分为train跟test，如果盯着test数据集的指标来调参的话，是很有可能出现线下高线上低的情况。因为盯着test指标进行调参的话容易加入个人先验，本身就是一种过拟合的操作，正规的操作应该是将数据集划分为train-test-validation。

（2）同样的业务场景建议共用一个大模型：新版游戏中心目前有9个场景需要算法接入，如果每一个场景都单独建模的话，一来维护成本高，二来浪费人力。适当对场景问题进行归纳，训练通用模型可以有效地节省开发时间。比如说首页分类列表推荐，游戏Tab的热游列表推荐等，其实都是纯icon的推荐，可以用统一的大模型来建模。通用模型首先要考虑的问题就是样本、特征的选取，样本可能比较好设计，汇总所有场景的样本即可，最多就是根据场景特性设计不同的权重；而特征就需要好好斟酌，是分场景提取特征还是汇总后提取、不同场景特征维度不一致如何处理等。

（3）选择合适的机器学习方案：目前首页feeds是将排序问题转化为二分类问题，评估指标选取的是auc，所以优化的重点在于尽可能地将正负样本区分开（正样本排在负样本前面），但对于正样本之间谁更“正”却不是二分类模型的关注重点。神盾近来已经支持pari-wise的LTR算法，可以解决任意两样本之间置信度问题，后续可以在首页feeds场景上做尝试。

（4）选择合适的优化指标：对于视频瀑布流场景，优化的目标可以有很多，比如人均播放个数、播放率、人均播放时长，具体需要跟产品同学沟通清楚。

（5）避免对分类问题的过度拟合：前面已经提过，在推荐场景，经常将推荐问题转化为分类问题来处理，但是需要注意的是，推荐问题不仅仅只是分类问题。分类问题是基于历史行为来做预测，但推荐问题有时候也需要考虑跳出用户历史行为的限制，推荐一些用户意想不到的item，因此，推荐是一个系统性问题，应当避免过度拟合分类问题。

6、数据上线

数据上线可以说是推荐系统中较为核心的环节，其中会面临很多难题。这儿的数据主要指的是离线计算好的物料数据、特征数据（用户、物品）、模型数据等。目前神盾会周期性地对需要上线的数据出库到hdfs，通过数据导入服务推送到线上存储，主要是grocery（用户特征）跟共享内存ssm（物品特征以及池子数据等查询较为频繁的数据）。目前这儿会有几个小问题：

（1）数据的一致性问题：离线模型在训练的时候，会对样本数据跟特征数据做拼接，通常都是将当前周期的样本跟上一周期的特征做拼接，以天为例，也就是今天的样本会跟昨天的特征数据做拼接。但是离线数据的计算以及上线是会有时间延迟的，尤其是特征数据。有可能今天的凌晨0点到5点，线上所拉到的特征数据其实是前天的特征数据，5点之后，昨天的特征数据才计算完并更新到线上。也就是说凌晨5点之前，所产生的推荐结果其实是用前天的特征数据来计算的，那么离线训练的时候，拼接的特征数据就会与实际的数据不一致。

（2）数据的实时性问题：前面也讲了，业务数据一般会周期（按小时）落地到hdfs或者tdw以库表形式存在，基于spark进行数据处理之后又推送到线上存储，这种复杂的数据处理链路导致数据时效性得不到保证（频繁地数据落地以及数据上线所导致）。因此，离线层仅适用于对数据时效性不高的任务，比如长期兴趣的计算等。

• 近线层

前面已经提到，离线层在数据时效性以及数据一致性的问题上面临较大的挑战。本质上是由于数据频繁落地以及上线导致的延迟所引起的，给游戏中心推荐带来较大的困扰。企鹅电竞也面临同样的问题，因此，两个业务联合设计了近线层（如图8所示）。目前整个数据链路已经打通，并且也在企鹅电竞业务上试点成功。整个框架是基于kafka+spark streaming来搭建的，目前主要实现两个功能点：实时特征的提取以及实时样本特征的拼接。由于近线层不需要落地以及线上导数据服务，而是直接对业务流水进行操作后写入线上存储，因此耗时较少，基本可以做到秒级别的特征反馈，解决了离线层计算周期长的缺点，适用于用户短时兴趣的捕捉。

实时样本特征的拼接主要是为了解决数据一致性问题。离线层对样本、特征进行拼接的时候一般都是默认当前周期样本拼接上一周期的特征，当由于特征上线的延迟，有部分当前周期样本的产生其实是由t-2周期的特征所导致，因此为了保证训练数据的准确性，我们在近线层设计了实时的样本特征拼接。当用户请求时，会带上读取的特征数据，拼接到用户的操作流数据上，构成离线层的训练数据。

图8：近线层功能逻辑

• 在线层

在线层是推荐系统的关键环节，直接影响最终的推荐结果。一般分为召回层，精排层、重排层（或者是matching、ranking、rerank）。召回层一般是起到粗筛的作用，对于内容推荐来说，推荐的池子一般都是上万级别，如果直接进行模型打分的话，线上服务压力会比较大，因此，通常都会采用各种召回的策略来进行候选集的粗筛。目前游戏中心所采用的召回策略主要有标签、热度、新鲜度、CF等。精排层所干的事情就比较纯粹了，一般就是模型加载以及模型打分，对召回的物品进行一个打分排序。最后就是重排层，主要是对模型打分结果进行一个策略的调整。游戏中心的重排排层主要有以下几个逻辑：1）分类打散：首页feeds在推荐的时候，如果只由模型进行打分控制的话，容易出现游戏扎堆的现象，也就是连续几条feeds都是同款游戏，因此需要重排层来调整展示的顺序；2）流量分配：游戏的分发涉及平台的利益，每款游戏的曝光量会影响平台的收入，因此需要合理分配每款游戏的展示量；3）bandint策略：主要是用于兴趣试探，feeds场景会涉及多种内容类型，如何在推荐用户历史喜欢的内容类型以及尝试曝光新的内容类型之间做平衡是推荐系统典型的E&E问题，这儿我们设计了一个简单的bandint策略，下面会详细讲一下。4）运营策略：一些偏业务性质的运营策略也会在重排层体现。

推荐系统中会遇到一个经典的问题就是Exploitation（开发） VS Exploration（探索）问题，其中的Exploitation是基于已知最好策略，开发利用已知具有较高回报的item（贪婪、短期回报），而对于Exploration则不考虑曾经的经验，勘探潜在可能高回报的item（非贪婪、长期回报），最后的目标就是要找到Exploitation & Exploration的trade-off，以达到累计回报最大化。对于游戏中心首页feeds而言，一味推荐用户历史喜欢的内容类型或者大量尝试曝光新的内容类型都是不可行的；首先用户的兴趣可能会有所波动，过去可能喜欢视频类型，但是下一刻就可能不喜欢了；其次一味推荐用户历史喜欢的内容类型，可能会让用户产生厌倦。为了平衡两者之间的关系，我们在重排层设计了一个简单的策略，具体如图9、图10所示。

图9：游戏中心bandit策略算法逻辑

图10：游戏中心bandit策略具体实现

        目前游戏中心个性化推荐所遇到的难点以及下一步的迭代计划主要如下：

1、外部数据的引入：1）结合第三方数据做推荐：目前游戏中心个性化推荐的依据主要是用户的场景表现、游戏内表现以及一些基础的画像数据，数据来源较为单一。引入更多的第三方业务数据（比如企鹅电竞），一方面可以丰富用户的特征维度，另一方面可以给用户带来体验上的提升（用户刚在企鹅电竞看了个吃鸡的直播，来到游戏中心就给推荐了“刺激战场”）。2）丰富推荐物料：目前游戏中心的内容来源部分存在“同质化”现象，素材类型还不是特别丰富，需要引入更多优质的外部内容。

2、多模态特征提取：游戏中心的推荐内容类型较为丰富，包括了视频、图文、活动、礼包等，如何在同一个特征向量空间对各个item进行信息抽取是目前遇到的难题之一。现有的解决方案是基于youtube的embedding网络进行user、item的embedding向量学习。该网络的输入是无序的，也就是没有考虑用户历史行为的轨迹，那么是否可以用图来表示行为的轨迹，基于graph embedding的方法获得信息更加丰富的item向量？目前业界也有若干基于graph embedding的推荐案例（手淘首页 、阿里凑单 ）。

3、内容元信息的提取：目前游戏中心对于item的特征提取要么是基于统计的特征，要么就是基于item历史行为的embedding特征或者tag提取，对于内容本体信息的提取还较为薄弱，如何有效地提取非结构化内容的信息是下一步迭代需要考虑的问题。

4、模型的快速更新：对于用户兴趣的实时捕捉，不仅依赖于数据的实时更新，同样依赖于模型的实时更新。目前线上的模型是按天例行更新，如何快速地训练模型以及部署模型是后续不可避免的问题。

5、优化指标考虑收入相关因子：当前的优化指标基本是转化率、时长等推荐系统常见的指标，但游戏中心涉及平台收入，需要综合考虑每个游戏的收益（类似广告系统中的竞价）。如何设计合理的优化指标（考虑游戏arpu、ltv等）以及在用户体验跟平台收入之间做平衡也是下一步迭代的关键。

6、流量分配问题：首页feeds场景既涉及游戏流量的分配，也涉及内容类型流量的分配，如何有效地设计流量分配方案，从而减轻重排逻辑的负担也是需要考虑的优化点。

7、拉活还是拉新：如何根据用户在游戏生命周期的不同阶段推荐合适的内容是首页feeds场景需要考虑的问题。

8、新品试探：目前我们只是在内容类型上做了一些简单的策略，后续还需要调研更加成熟的解决方案来解决E&E问题。

       本文主要是对游戏中心在算法一期的接入过程所遇到的问题做一些总结，以及梳理下一步迭代的计划。由于算法一期的重心在于算法的快速接入，因此整个个性化推荐框架中所涉及到的策略可能都略显“着急”，希望各位同行大佬多多包涵。关于游戏中心推荐问题，欢迎随时交流。

来源：腾讯QQ大数据

导语 在内容推荐系统里，一个常用的方法是通过理解内容（挖掘内容属性）去挖掘用户的兴趣点来构建推荐模型。从大多数业务的效果来看，这样的模型是有效的，也就是说用户行为与内容是相关的。不过有一点常被忽略的是：相关性是对称的！这意味着如果可以从内容属性去理解用户行为，预测用户行为，那么也可以通过理解用户行为去理解内容，预测内容属性。

在内容推荐系统里，一个常用的方法是通过理解内容（挖掘内容属性）去挖掘用户的兴趣点来构建推荐模型。从大多数业务的效果来看，这样的模型是有效的，也就是说用户行为与内容是相关的。不过有一点常被忽略的是：相关性是对称的！这意味着如果可以从内容属性去理解用户行为，预测用户行为，那么也可以通过理解用户行为去理解内容，预测内容属性。

推荐系统里我们一直有基于用户行为去理解内容，典型的例子是基于用户行为构造内容特征，例如内容的点击率、内容的性别倾向，内容的年龄倾向等。这样的理解是浅层的，仅仅是一些简单的统计。我们其实有更好的办法可以构建内容特征，它的第一步是利用用户行为将内容转化为向量，下面会以应用宝业务为例讲解利用用户行为将app转化为向量的思路。
从直觉上来看，用户下载app的先后关系是相关的，以图1的行为数据为例，一个用户之前下载过街头篮球，那么他接下来会下载体育类app的概率会比他接下来下载时尚类app的概率更大。也就是说 P(腾讯体育|街头篮球)>P(唯品会|街头篮球)

到这里我们已经大致介绍了利用用户行为将内容转化为向量的方法，这里将这种技术称作item2vec。以应用宝为例，它的item是app，它的实际应用也可以称作app2vec。

基于应用宝已有的类别体系观察，可以明显区分开角色扮演类游戏app和理财app。

也可以发现一些没有加入类别体系的特殊app群体。

now直播业务也基于该方法进行了生成了主播向量并对主播进行了聚类，初步结果来看是聚类是可以明显区分开男女主播的，并且也发现了几个有趣的主播类型，例如直播玩王者的主播，直播电影电视剧的主播，直播农村生活的主播。

应用宝的app分类（打标签）场景长期以来都存在这样的痛点：

1. 分类体系经常会面临变动
2. app的人工标注成本高，复杂标签体系下app的标注数据很少
3. app属于复杂数据结构的内容，它的内在难以用已有算法进行挖掘，过去只能通过它的描述和图片来挖掘其信息

这里我们可以先思考一个问题：为什么要给app做分类和打标签？
答：给app做分类和打标签实际上是为了让用户可以更方便的找到自己想要的app，为了让我们可以更容易地结合用户兴趣给用户推送app。

从问题和答案我们可以得出一个结论：给app做分类和打标签有意义的前提是用户的行为是和app的类别、标签相关的！例如下面的这个例子里，第一位用户喜欢下载纸牌类游戏，第二位用户喜欢下载跑酷类和儿童类游戏，第三位用户喜欢下载休闲类游戏。

上面的分析我们知道用户行为应该可以用于判断app的类别标签。因此在给应用宝的app进行分类和打标签时，我们引入了基于用户行为生成的app向量。具体框架可看下图：

通过增加app向量作为分类模型的特征，可以很大程度上提高app分类的准确度（可以参考聚类中的例子），在实际业务中，部分标签的分类准确率和覆盖度都有大幅度提升。

直观的例子是相关推荐，因为这一场景通常不会对召回结果做太多的加工。常见的召回结果生成方法是先计算item与item之间的相似度（一般使用cosine相似度），再取其中的top n相似item。

在应用宝的两个场景中基于app向量做了app的推荐召回进行了测试，相对于原模型效果有明显的提升。

在app搜索场景基于行为数据生成的搜索词向量优化了语义召回，明显增强了词的模糊匹配能力。例如搜索“潮流”，出来的结果是从用户行为角度跟“潮流”相关的app，而不是单纯基于语义匹配。

或者举一个更直观的例子，吃鸡游戏出来的时候，搜索吃鸡出来的都不是吃鸡游戏。但是对此感兴趣的用户后续还是会去找到正确的搜索词，例如之后搜索“绝地求生”，或是下载了“绝地求生”，基于这些词，基于这些行为，可以将“吃鸡”和“绝地求生”关联起来。

基于内容向量的应用场景还有很多，加入我们，我们一起来玩转机器学习！

来源：腾讯QQ大数据

众所周知，YouTube能根据热门视频、历史观看记录以及其他信号向用户推荐他们可能会喜欢的视频。谷歌的一位工程主管克里斯托斯•古德洛（Cristos Goodrow）表示：YouTube观众最常反应的一个问题，是不知道究竟该看些什么，而YouTube视频发现团队的职责正是解决这一问题。

谷歌一直想把YouTube变成更像电视的平台，不但斥巨资打造专业水准的频道节目，还努力增加用户订阅的频道数量——这都是为了将用户的逗留时间从以“分钟”计延长到以“小时”计，从而促进网站广告收入向电视看齐。不过，YouTube现在还没有制作出像Netflix的《纸牌屋》（House of Cards）和《女子监狱》（Orange is the New Black）那样的高人气“神作”。

然而，YouTube首次获得技术艾美奖，却是因为与电视大相径庭的东西——能从海量内容中“沙里淘金”、打造深度个性化体验以延长用户注意力的算法。虽然目前在YouTube上最火的是各种频道，但任何曾经陷在一串串相关视频里无法自拔的人都会说，推荐算法或许才是YouTube的最有价值资产。

用户最爱不相关的“相关视频”

YouTube开始大力向用户推荐相关视频是在2008年，那时它已经问世3年并被谷歌收购了2年。而在YouTube主页以及视频页面右侧推荐其他视频的做法很快就收到了成效——到2008年底，该算法每天都会让用户的观看时长增加数十万小时，而古德洛表示这一数字如今已经以“亿”为单位了。

与此同时，YouTube也学到了一些出人意料的窍门，例如：向用户推荐与他们当前观看内容最密切相关的视频，其实反而会让用户生厌。参与YouTube推荐算法构建的软件工程师海克特•易（Hector Yee）指出：“用户喜欢丰富多样的题材。”

有时候，用户最有可能点击的“相关”视频其实与当前观看内容根本不相关。YouTube视频发现团队在实验中了解到，我们常常在个人兴趣范围内从一个主题跳到另一个主题。

机器学习算法好比“会计记账”

古德洛表示：YouTube构建推荐算法的最大优势，在于掌握了与用户个人喜好相关的海量数据。YouTube既能抓取诸如用户“赞”了哪段视频之类的明确信号，还能抓取诸如用户把哪段视频从头看到尾之类的隐含信号——将所有这些数据综合起来，YouTube就对用户可能会点击什么内容有谱了。

在谈到YouTube使用的机器学习技术时，古德洛将其比作“会计记账”：YouTube的算法会记录用户们观看视频的次序，而当某位用户观看某段视频时，算法会以其他用户看过这段视频后紧接着看了哪些视频为依据，认为该用户可能也会对这些视频感兴趣，从而让它们出现在右侧。

古德洛还表示，YouTube的推荐算法仍有巨大改进空间，而当前一大目标是让用户无需到处点击就能舒舒服服地一段接一段观看他们喜爱的视频、一口气看上30分钟或一小时。

当然，古德洛也承认YouTube除了需要出色的推荐算法之外，也需要出色的视频内容。

现有的一些推荐算法，特别是协同过滤推荐算法，它们容易受到外界认为攻击的影响，例如在Amazon上，有些用户刻意地对自己的商品评高分，而对竞争对手的商品评低分，这样一来，Amazon的推荐系统就更容易推荐这些人的商品，而其他人的商品就很难被推荐。这就有点像在google搜索引擎里面，有些用户通过特定的方式来提高自己网站的pagerank值。到目前为止，这种攻击有很多种，针对不同的算法有不同的攻击，本章节就是主要讨论攻击的种类，评价指标以及推荐算法在受到这些攻击时候的表现情况。

问题描述：

图1 攻击框架

1. 攻击框架

首先我们来看一下传统的推荐系统攻击的框架，如图1所示。图1中展示了两种攻击类型，一种是高效的攻击，另一种是非高效的攻击。这两种攻击都有一个可检测区域，即图中的阴影部分。一般来说，非高效的攻击不容易被检测出来，但是它们对推荐系统的影响往往比较小，因此我们的主要精力应该放在如何检测和防范高效的攻击。

1. 名词描述

Attack profile：攻击者伪造的用户

Product push：提高某些商品的推荐概率

Product nuke：降低某些商品的推荐概率

High-acknowledge attack：这种攻击要求攻击者了解系统的信息，例如系统使用的算法，评分的分布情况，商品的平均分。这种攻击方法成本较高。

Low-acknowledge attack：这种攻击方法就不需要太多的系统信息。

Inform attack：这种方式就更高级了，攻击者不但知道了许多系统的信息，而且对系统使用的算法非常了解，这样他们就针对系统的推荐算法采取特定的攻击。

1. 示例：

图2 攻击示例

图2展示了一个攻击示例，假设我们现在要决定是否向用户h推荐商品7。如果系统中只有那些合法用户，即用户a-g，通过上表我们发现用户a和f与用户h的品味比较相似，由于用户a和f都喜欢商品7，那么系统应该把商品7推荐给用户h。以上情况是我们没有考虑那些攻击者的行为，如果我们考虑他们的行为，我们发现，大多数攻击者（用户i-m）的品味都与用户h相似，并且他们对商品7都给了负面的评价，那么在这种情况下，系统就不会把商品7推荐给用户h，这样一来，就达到了那些攻击者的目的，即product nuke。

1. 攻击类型

Basic attack

1)      随机攻击

在这个模型中，那些伪造的用户对特定的商品评最高分（push）或者最低分（nuke），而对其他的商品随机的评分。这种攻击方式要求的信息量比较少，但是攻击效果也不是很好。

2） 平均值攻击

与随机攻击类似，伪造用户对特定的商品评最高分或者最低分，不同的是，这些伪造用户对其他的商品评分值等于该商品的其他用户对这个商品的平均评分值。

Low-acknowledge attack

3）Bandwagon攻击

这种攻击的主要原理是将目标商品与那些少量的热销商品绑定在一起，由于那些热销的商品具有大量的用户群体，那么这些目标商品也就很容易被推荐出去。

4）Segment攻击

这种攻击的主要原理是将目标商品推荐给那些特定的用户群体。一般情况下，攻击者都比较了解这些用户群体，另外通过一些特定的方式，推荐系统也容易将那些目标商品推荐给这些用户。例如，攻击者可以将那些恐怖片推荐给喜欢恐怖片的用户，而这些用户的信息都是被攻击者所掌控的，攻击者往往将目标商品与这些用户都喜欢的热销商品绑定在一起，因此推荐算法就很容易把目标商品推荐给这些用户群体。

Nuke attack

5）love/hate攻击

这种攻击方式很简单，就是给那些目标商品评最高分，而给那些需要过滤的商品评最低分。这种攻击方式需要的信息量非常少，但是这种攻击对于基于用户的协同过滤算法来说，非常有效。

6）Reverse Bandwagon攻击

这种攻击方式是Bandwagon攻击的一个变种，与Bandwagon攻击不同的是，那些目标商品往往与系统中很不受欢迎的商品绑定在一起，在这种情况下，系统就不容易推荐那些目标商品。

Informed attack

7）popular攻击

这种攻击方式需要更多的信息，包括推荐算法，商品的平均分，用户的平均分。假设系统使用的基于用户的推荐算法，用户间的相似度指标为皮尔森系数。我们知道，两个用户共同评分是商品数目越多，并不意味着这两个用户越相似，还要看他们的评分方式，有时候两个的共同评分商品很多，但是他们的皮尔森系数可能为负的。在bandwagon攻击中，那些过滤商品是随机选择的，这样一来，那些伪造的用户与系统中的合法用户的相似性就比较随机，最后就有可能使得那些目标商品计算得到的预测评分值不高。Popular攻击利用了所有商品的平均分，同样的，根据商品的得分是否高于平均分，来给这些商品评r_min+1和r_min，r_min代表最低分。通过这种方式，伪造用户与合法用户的皮尔森相似度就容易是正的，这样就可以更容易控制目标商品的推荐。

8)  Probe Attack Strategy

尽管没有相关的研究表明popular攻击容易被发现，但是直观的看，这种攻击很容易被察觉，因为在这种攻击模式下，伪造用户的评分大多都是r_min+1和r_min，所以很容易被系统检测到。Probe Attack Strategy相对来说，就比较隐蔽，这种方法首先伪造一个用户，这样系统就会向这个用户推荐一些商品，根据这些推荐商品的情况，我们就可以知道这个伪造用户的邻居（相似用户）选择商品的情况，在得到这些邻居的信息之后，就可以对他们选择的商品进行攻击，例如用到前面提高的popular攻击。