小毛驴

Adventure may hurt you, but monotony will kill you.

0%

梯度提升(Gradient boosting)是一种用于回归、分类和排序任务的技术,属于Boosting算法族的一部分。Boosting是一族可将弱学习器提升为强学习器的算法,属于集成学习(ensemble learning)的范畴。Boosting方法基于这样一种思想:对于一个复杂任务来说,将多个专家的判断进行适当的综合所得出的判断,要比其中任何一个专家单独的判断要好。通俗地说,就是“三个臭皮匠顶个诸葛亮”的道理。梯度提升同其他boosting方法一样,通过集成(ensemble)多个弱学习器,通常是决策树,来构建最终的预测模型。

Boosting、bagging和stacking是集成学习的三种主要方法。不同于bagging方法,boosting方法通过分步迭代(stage-wise)的方式来构建模型,在迭代的每一步构建的弱学习器都是为了弥补已有模型的不足。Boosting族算法的著名代表是AdaBoost,AdaBoost算法通过给已有模型预测错误的样本更高的权重,使得先前的学习器做错的训练样本在后续受到更多的关注的方式来弥补已有模型的不足。与AdaBoost算法不同,梯度提升方法在迭代的每一步构建一个能够沿着梯度最陡的方向降低损失(steepest-descent)的学习器来弥补已有模型的不足。经典的AdaBoost算法只能处理采用指数损失函数的二分类学习任务,而梯度提升方法通过设置不同的可微损失函数可以处理各类学习任务(多分类、回归、Ranking等),应用范围大大扩展。另一方面,AdaBoost算法对异常点(outlier)比较敏感,而梯度提升算法通过引入bagging思想、加入正则项等方法能够有效地抵御训练数据中的噪音,具有更好的健壮性。这也是为什么梯度提升算法(尤其是采用 决策树 作为弱学习器的GBDT算法)如此流行的原因。之前有种观点认为GBDT是性能最好的 机器学习 算法,这当然有点过于激进又固步自封的味道,但通常各类机器学习算法比赛的赢家们都非常青睐GBDT算法,由此可见该算法的实力不可小觑。

基于梯度提升算法的学习器叫做GBM(Gradient Boosting Machine)。理论上,GBM可以选择各种不同的学习算法作为基学习器。现实中,用得最多的基学习器是决策树。为什么梯度提升方法倾向于选择决策树(通常是CART树)作为基学习器呢?这与决策树算法自身的优点有很大的关系。决策树可以认为是if-then规则的集合,易于理解,可解释性强,预测速度快。同时,决策树算法相比于其他的算法需要更少的特征工程,比如可以不用做特征标准化,可以很好的处理字段缺失的数据,也可以不用关心特征间是否相互依赖等。决策树能够自动组合多个特征,它可以毫无压力地处理特征间的交互关系并且是非参数化的,因此你不必担心异常值或者数据是否线性可分(举个例子,决策树能轻松处理好类别A在某个特征维度x的末端,类别B在中间,然后类别A又出现在特征维度x前端的情况)。不过,单独使用决策树算法时,有容易过拟合的缺点。所幸的是,通过各种方法,抑制决策树的复杂性,降低单颗决策树的拟合能力,再通过梯度提升的方法集成多个决策树,最终能够很好的解决过拟合的问题。由此可见,梯度提升方法和决策树学习算法可以互相取长补短,是一对完美的搭档。至于抑制单颗决策树的复杂度的方法有很多,比如限制树的最大深度、限制叶子节点的最少样本数量、限制节点分裂时的最少样本数量、吸收bagging的思想对训练样本采样(subsample),在学习单颗决策树时只使用一部分训练样本、借鉴随机森林的思路在学习单颗决策树时只采样一部分特征、在目标函数中添加正则项惩罚复杂的树结构等。现在主流的GBDT算法实现中这些方法基本上都有实现,因此GBDT算法的超参数还是比较多的,应用过程中需要精心调参,并用交叉验证的方法选择最佳参数。

本文对GBDT算法原理进行介绍,从机器学习的关键元素出发,一步一步推导出GBDT算法背后的理论基础,读者可以从这个过程中了解到GBDT算法的来龙去脉。对于该算法的工程实现,本文也有较好的指导意义,实际上对 机器学习关键概念元素的区分对应了软件工程中的“开放封闭原则”的思想,基于此思想的实现将会具有很好的模块独立性和扩展性。

阅读全文 »

推荐系统学习用户与物品的交互模式,并据此给用户推荐物品。 然而,用户与物品的交互行为数据是很稀疏的,也就是说,观察到的”用户-物品”交互往往只占可能的互动的5%以下(User-Item矩阵的稀疏度)。缓解数据稀疏的一个有希望的方向是利用辅助信息,这些信息可能编码了关于用户如何与物品交互的额外线索。这类数据(被称为模态)的例子有:社交网络、物品的描述性文本、物品的图像、视频等。那么如何利用这些额外的数据为推荐系统提供更好的性能呢?多模态推荐模型提供了一个有希望的方向。

推荐系统通常还会面临冷启动问题的挑战,比如新发布的物品该如何推荐给用户。物品的内容信息,尤其是图片、视频这些视觉信息为缓解物品冷启动问题提供了一个可行的思路。关于推荐冷启动问题的更多解决方案请查看《冷启动推荐模型DropoutNet深度解析与改进》。那么该如何利用物品的视觉信息来构建推荐算法模型呢?

文本总结了一些常用的视觉多模态推荐模型的大致思路,在此之前,让我们先来了解一些基础的推荐算法。

阅读全文 »

一、推荐算法为何要精做特征工程

机器学习工作流就好比是一个厨师做菜的过程,简单来说,清洗食材对应了清洗数据,食材的去皮、切片和搭配就对于了特征工程的过程,食物的烹饪对应了模型训练的过程。如果你觉得数据清洗和特征工程不重要,莫非是你想吃一份没有经过清洗、去皮、切片、调料,而直接把原始的带着泥沙的蔬菜瓜果放在大锅里乱炖出来的“菜”? 先不说卫生的问题,能不能弄熟了都是个问题。

在完整的机器学习流水线中,特征工程通常占据了数据科学家很大一部分的精力,是因为特征工程能够显著提升模型性能,高质量的特征能够大大简化模型复杂度,让模型变得高效且易理解、易维护。在机器学习领域,“Garbage In, Garbage Out”是业界的共识,对于一个机器学习问题,数据和特征决定了机器学习的上限,而模型和算法只是逼近这个上限而已。

与计算机视觉、语音、NLP等领域不同,推荐算法模型很大程度上依赖人工特征工程为其提供输入数据,这是因为推荐算法需要处理的通常是结构化的关系型数据,这些原始数据一般需要经过清洗、采样、变换、统计、编码等方式生成最终的特征数据,模型本身无法直接完成所有这些加工逻辑。关于工业级推荐系统中如何做特征工程,请参考这篇文章《工业级推荐系统中的特征工程》。

上面这篇文章从一个较概括和抽象的角度详细介绍了工业级推荐系统中如何做特征工程,但并未提及代码实现方面的内容。本文的目标就是帮助读者理解并掌握这些特征工程方法在真实的生成环境中是如何实现的。本文从一个公开数据集出发,详细讲解一个工业级推荐系统的特征工程代码是如何一步一步开发出来的。开发语言为MaxCompute SQL,非常类似于Hive/Spark SQL。

查看本文完整代码:Github

阅读全文 »

摘要:深度学习时期,与CV、语音、NLP领域不同,搜推广场景下特征工程仍然对业务效果具有很大的影响,并且占据了算法工程师的很多精力。数据决定了效果的上限,算法只能决定逼近上限的程度,而特征工程则是数据与算法之间的桥梁。本文尝试总结一些在推荐场景下做特征工程的常用套路,包括常用的特征变换算子、Bin-Counting技术以及特征查漏补缺的方法。

读者受益

  1. 深入理解常用的特征变换操作。
  2. 了解优质特征工程的判断标准。
  3. 掌握推荐场景下构建高质量特征的一般方法。

一、为什么要精做特征工程

在完整的机器学习流水线中,特征工程通常占据了数据科学家很大一部分的精力,一方面是因为特征工程能够显著提升模型性能,高质量的特征能够大大简化模型复杂度,让模型变得高效且易理解、易维护。在机器学习领域,“Garbage In, Garbage Out”是业界的共识,对于一个机器学习问题,数据和特征决定了机器学习的上限,而模型和算法只是逼近这个上限而已。


阅读全文 »

在推荐算法领域,时常会出现模型离线评测效果好,比如AUC、准召等指标大涨,但上线后业务指标效果不佳,甚至下降的情况,比如线上CTR或CVR下跌。

本文尝试列举一些常见的原因,为大家排查问题提供一点思路。

1. 离线、在线特征不一致

离线、在线特征不一致通常是模型线上效果不好的主要原因,然而,造成离在线特征不一致的原因却千奇百怪,有些还非常隐蔽。

  1. 实现上存在Bug。离线、在线特征的ETL过程通常不是由同一份代码完成的,比如,离线特征的计算过程一般是使用SQL语言在大数据平台上完成,而在线特征的加工通常是由C++、Go这样的语言计算得到。这样就存在相同的逻辑需要实现两次,而且可能是不同的人来实现,如果不仔细测试,出现不一致的可能性还是很高的。要严格保证线上线下的特征一致性,最根本的方法就是同一套代码和数据源抽取特征,业内目前通用的方法就是,在线实时请求打分的时候落地实时特征,训练的时候就没有特征拼接的流程,只需要关联label,生成正负样本即可
  2. 特征更新存在延迟。一些需要实时计算得到的特征,如实时统计特征、序列特征等,离线模拟时不存在问题,然而,上线后由于各种原因,如果不能及时更新,那就造成了离线、在线的特征分布不一致,相当于是模型过拟合了。小时级更新、天级更新的特征,也有可能出现更新延迟的问题。

2. 存在数据泄露

数据泄露(data leakage),有时也叫做泄露、穿越等。它说的是用于训练机器学习算法的数据集中包含了一些将要预测的事务的东西(when the data you are using to train a machine learning algorithm happens to have the information you are trying to predict),也就是说测试数据中的一些信息泄露到了训练集中。这里说的信息是指关于目标标签或者在训练数据中可用但在真实世界中却不可用、不合法的数据。

阅读全文 »

有时候我们会遇到推荐算法上线之后,效果不如预期的情况。这种情况下,该如何改进呢?

下面就尝试列出一些检查清单,按照重要性的顺序,建议从上往下依次检查。当然,这些清单还不全面,欢迎大家一起来补充!

1. 用来统计效果指标的行为日志是否正确

  • [ ] 是否准确、完整地收集了影响统计指标的行为日志?
  • [ ] 埋点是否正确、完整?新的埋点逻辑是否有足够覆盖率的APP的版本更新?

错误Case:

  • 之前有一个客户把实验桶标识存储在Web页面的cookie里,在不同推荐场景的页面之间跳转时,收集到日志服务器的实验桶标识发生了错乱。
  • 还是这个客户,只在当前推荐场景的第一页收集了实验埋点,从推荐结果的第二页开始就没有收集埋点信息,导致效果统计时第二页之后的流量都算到基准桶里了。
  • 当推荐服务超时或异常时,APP端会出一个兜底的默认推荐列表;这个时候实验桶标记既不应该记录为算法桶标记,也不应该记录为基准桶标记,而应该记录为一个特殊的’other’标记,否则在统计效果的时候就会发现有些用户既存在于算法桶内又存在于基准桶内的矛盾。

2. 流量切分是否稳定、随机和足量

  • [ ] 流量切分是否是稳定的,即同一个用户在实验期间是否只能落在同一个桶内?
  • [ ] 流量切分是否足够随机,会不会存在某些行为异常的用户集中在同一个桶内?对调实验桶的用户集合是否能够观察到对应的效果指标的翻转?
  • [ ] AA测试的效果是否是比较接近的?当链路上出现系统性错误时,通常会通知AA测试的效果差异很大。
  • [ ] 在统计周期内,实验桶的流量是否足够得出置信的统计结果?这里推荐一个流量多少(样本数量)与指标置信度之间换算的计算器:https://www.evanmiller.org/ab-testing/sample-size.html。如果实验桶流量不够,则需要拉长统计周期。

阅读全文 »

为什么需要冷启动

通常推荐系统通过协同过滤、矩阵分解或是深度学习模型来生成推荐候选集,这些召回算法一般都依赖于用户-物品行为矩阵。在真实的推荐系统中,会有源源不断的新用户、新物品加入,这些新加入系统的用户和物品由于缺乏足够丰富的历史交互行为数据,常常不能获得准确的推荐内容,或被准确推荐给合适的用户。这就是所谓的推荐冷启动问题。冷启动对推荐系统来说是一个挑战,究其原因是因为现有的推荐算法,无论是召回、粗排还是精排模块,都对新用户、新物品不友好,它们往往过度依赖系统收集到的用户行为数据,而新用户和新物品的行为数据是很少的。这就导致新物品能够获得的展现机会是偏少的;新用户的兴趣也无法被准确建模。

对于某些业务来说,及时推荐新物品,让新物品获得足够的曝光量对于平台的生态建设和长期受益来说都是很重要的。比如,在新闻资讯的时效性很强,如不能及时获得展现机会其新闻价值就会大大降低;自媒体UGC平台如果不能让新发布的内容及时获得足够数量的展现就会影响内容创作者的积极性,从而影响平台在未来能够收纳的高质量内容的数量;相亲交友平台如果不能让新加入的用户获得足够多的关注,那么就可能不会有源源不断的新用户加入,从而让平台失去活跃性。

综上,冷启动问题在推荐系统中至关重要,那么如何解决冷启动问题呢?

如何解决冷启动问题

解决推荐系统的冷启动问题的算法(或策略)我总结为:“泛、快、迁、少” 四字口诀。


阅读全文 »

粗略来看,推荐算法可以简单地分为召回和排序两个阶段。召回模块负责从海量的物品库里挑选出用户可能感兴趣的物品子集,过滤之后通常返回几百个物品。排序模块负责对召回阶段返回的物品集个性化排序,通常返回几十个物品组成的有序列表。

总结起来,召回和排序有如下特点:

  • 召回层:候选集规模大、模型和特征简单、速度快,尽量保证用户感兴趣数据多召回。
  • 排序层:候选集不大,目标是保证排序的精准,一般使用复杂和模型和特征。

simple_rec_sys_framework

使用排序模块的三个原因:

  1. 多路召回的候选集缺乏统一的相关性度量,不同类型的召回物品不可比;
  2. 召回阶段通常只计算候选物品的相关性,对业务指标(如转化率、dwell time、GMV等)缺乏直接有效的度量;
  3. 当有多个业务关心的指标时,召回模块通常无能为力。

比如,在电商场景业务通常比较关心总成交额(GMV)这一指标,通过目标拆解:GMV = 流量 × CTR × CVR × price,我们发现流量和price通常不是算法能够控制的,那么算法需要干预的是CTR和CVR,也就是点击率和转化率。我们可以分别训练一个点击率预估模型和一个转化率预估模型,或者只训练一个多目标模型同时建模点击率预估和转化率预估。有了预估的CTRCVR之后,我们就可以按照如下公式来对候选商品排序:

这里对price项做log和指数变换的原因是通常price的值比较大,跟ctr和cvr不在一个量级上,如果不做变换会在排序公式中占据统治地位。

训练一个排序模型通常分为 模型选择、样本构建、特征工程、模型开发、训练&评估 等几个阶段。下面我们就以电商平台商品详情页的推荐场景为例,介绍一下排序模型建模的详细流程和方法。

阅读全文 »

推荐系统已经成为互联网应用提升点击率、转化率、留存率和用户体验的必备手段,然而,随着流量和数据量的爆发式增长,以及企业竞争环境日新月异的变化,快速搭建一套易用、精准、可灵活扩展的个性化推荐系统已成为每一家互联网企业必备的生存技能。

推荐系统一方面需要能够及时处理海量的用户行为日志,从中挖掘出用户的画像信息及行为偏好;另一方面又要对海量的物料数据(推荐候选集)进行精准的分析,预测每个候选物料未来一段时间内的转化概率;同时还需要对推荐的上下文进行分析,精准预测出在应该在什么时间、什么地点、给什么用户推荐什么内容。推荐内容的精准度、时效性、多样性、短长期受益平衡等各方面都对推荐系统提出了很高的要求。从零开始搭建一套合格的推荐系统绝非易事。所幸,随着云计算平台的兴起,搭建推荐系统所需要的各种基础技术、工具、产品和平台越来越成熟,相信搭建云上的智能推荐系统对中小企业来说是一个比较好的选择。

本文主要介绍如何基于阿里云平台,从0到1搭建一套高效、精准、易用、可扩展的智能推荐系统。

阅读全文 »

一、推荐冷启动问题

当新用户或新物品进入内容平台时,就会出现冷启动(Cold Start)问题。比如,内容平台新发布的短视频、电商平台新上架的商品、媒体平台新发布的新闻等等,这些新的内容之前从未获得过曝光,从未有用户对它们表示过感兴趣或不感兴趣。推荐系统该如何决定这些内容是否需要被推荐,以及推荐给哪些合适的用户?这就是推荐冷启动问题。

相对于冷启动的物品(泛指商品、新闻、作品等需要被推荐的内容),非冷启动物品因为以及获得了大量的曝光,推荐系统收集了用户对它们的一些交互行为,这些行为显式或隐式反馈了用户对这些物品的兴趣。基于这些行为日志,推荐系统可以用比较成熟的推荐算法来对这些物品进行个性化的推荐,让合适的物品被呈现给合适的用户。

为什么需要冷启动方案,原因如下:

  • 目前的召回、粗排、精排算法对新物品、新用户不友好
  • 新物品很大程度上,会被模型”低估”
  • 冷启动问题不可逃避
    • 处理不好会影响内容创造者的积极性,进而影响平台生态的健康发展

冷启动物品由于缺乏或暂未获得足够丰富的用户交互行为日志,给推荐算法带来了不小的挑战。目前冷启动推荐大致有以下几种思路:

  • 基于物品的属性数据(side information),比如利用商品的类目、品牌等信息;文章的作者、类别、关键词、摘要等。
  • 基于其他领域的知识,比如领域知识图谱等
  • 使用元学习(meta learning)的方法
  • 基于试错的Contextual Bandit的方法

本文主要关注基于Contextual Bandit的方法,具体地,我们会介绍LinUcb算法的原理、生产环境部署的基础设施架构、算法框架、工程实现时的注意事项、特征设计的陷阱、算法超参数的选择等内容。

阅读全文 »