推荐系统三十六式
刑无刀
“贝壳找房”资深算法专家,8年推荐系统工程师
立即订阅
11389 人已学习
课程目录
已完结 39 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 用知识去对抗技术不平等
免费
第1章 概念篇 (3讲)
【概念篇】你真的需要个性化推荐系统吗?
【概念篇】个性化推荐系统那些绕不开的经典问题
【概念篇】这些你必须应该具备的思维模式
第2章 原理篇 (20讲)
【内容推荐】画鬼容易画人难:用户画像的“能”和“不能”
【内容推荐】从文本到用户画像有多远
【内容推荐】超越标签的内容推荐系统
【近邻推荐】人以群分,你是什么人就看到什么世界
【近邻推荐】解密“看了又看”和“买了又买”
【近邻推荐】协同过滤中的相似度计算方法有哪些
【矩阵分解】那些在Netflix Prize中大放异彩的推荐算法
【矩阵分解】Facebook是怎么为十亿人互相推荐好友的
【矩阵分解】如果关注排序效果,那么这个模型可以帮到你
【模型融合】经典模型融合办法:线性模型和树模型的组合拳
【模型融合】一网打尽协同过滤、矩阵分解和线性模型
【模型融合】深度和宽度兼具的融合模型 Wide and Deep
【MAB问题】简单却有效的Bandit算法
【MAB问题】结合上下文信息的Bandit算法
【MAB问题】如何将Bandit算法与协同过滤结合使用
【深度学习】深度学习在推荐系统中的应用有哪些?
【深度学习】用RNN构建个性化音乐播单
【其他应用算法】构建一个科学的排行榜体系
【其他应用算法】实用的加权采样算法
【其他应用算法】推荐候选池的去重策略
第3章 工程篇 (10讲)
【常见架构】典型的信息流架构是什么样的
【常见架构】Netflix个性化推荐架构
【常见架构】总览推荐架构和搜索、广告的关系
【关键模块】巧妇难为无米之炊:数据采集关键要素
【关键模块】让你的推荐系统反应更快:实时推荐
【关键模块】让数据驱动落地,你需要一个实验平台
【关键模块】 推荐系统服务化、存储选型及API设计
【效果保证】推荐系统的测试方法及常用指标介绍
【效果保证】道高一尺魔高一丈:推荐系统的攻防
【开源工具】和推荐系统有关的开源工具及框架介绍
第4章 产品篇 (3讲)
【产品篇】推荐系统在互联网产品商业链条中的地位
【产品篇】说说信息流的前世今生
【团队篇】组建推荐团队及工程师的学习路径
尾声与参考阅读 (2讲)
推荐系统的参考阅读
【尾声】遇“荐”之后,江湖再见
推荐系统三十六式
登录|注册

【关键模块】让数据驱动落地,你需要一个实验平台

刑无刀 2018-05-09
数据驱动这个口号喊了很多年了,这个口号也几乎成为了行业共识,但是数据驱动又像鬼一样,人人都在说,但几乎没人见过它长什么样子。

数据驱动和实验平台

要做到数据驱动,就要做到两点:第一点是数据,第二点是驱动。这听上去似乎像是废话,实际上不是。
这第一点的意思是,要采集数据,全方位,数据像是石油一样,没有它就谈不上驱动;第二点的意思是要让大家看数据,光采集了没有用,还需要让所有人盯着数据看。
而要做到驱动,需要一个 AB 实验平台。数据驱动的重点是做对比实验,通过对比,让模型、策略、设计等不同创意和智慧结晶新陈代谢,不断迭代更新。
对比实验也常常被大家叫做 ABTest,这个意思就是一个 A 实验,一个 B 实验,这样说可能有些模糊,所以我需要先和你说说什么叫做对比实验,然后再说说一个对比实验平台应该长什么样子。
你都可以把任何一家个性化推荐产品想象成一个函数,这个函数有很多参数影响它工作,函数的输出就是推荐物品列表。这些函数参数可以有各种组合,通过其中一种参数组合去面对一小股用户的考验,这就是一个实验。
要做实验,要做很多实验,要很快做很多实验,要很多人同时很快做很多实验,就需要实验平台。
要讨论实验平台,先要认识实验本身。互联网实验,需要三个要素。
流量:流量就是用户的访问,也是实验的样本来源。
参数:参数就是各种组合,也是用户访问后,从触发互联网产品这个大函数,到最后返回结果给用户,中间所走的路径。
结果:实验的全过程都有日志记录,通过这些日志才能分析出实验结果,是否成功,是否显著。
把互联网产品想象一个有向无环图,每个节点是一个参数,不同的分支是参数的不同取值,直到走到终点,这一条路径上所有经过的参数取值,构成了服务的调用路径。
具体在推荐系统中,可能这些参数就是不同的模型与策略名称。每当一个用户经过这一系列的调用路径后,就为每一个分支产生了一条实验样本。
于是问题来了,每一个用户到来时,如何为他们决定要走哪条路径呢?这就要先经过实验对照来看。
实验要观察的结果就是一个随机变量,这个变量有一个期望值,要积累很多样本才能说观察到的实验结果比较接近期望值了,或者要观察一定时期才能说对照实验之间有区别或者没区别。
因为只有明显有区别并且区别项好,才能被进一步推上全线。
在设计一个实验之初,实验设计人员总是需要考虑下面这些问题。
实验的起止时间。这涉及到样本的数量,关系到统计效果的显著性,也涉及能否取出时间因素的影响。
实验的流量大小。这也涉及了样本的数量,关系到统计效果的显著性。
流量的分配方式。每一个流量在为其选择参数分支时,希望是不带任何偏见的,也就是均匀采样,通常按照 UUID 或者 Cookie 随机取样。
流量的分配条件。还有一些实验需要针对某个流量的子集,例如只对重庆地区的用户测试,推荐时要不要把火锅做额外的提升加权。
流量如何无偏置。这是流量分配最大的问题,也是最难的问题。同时只做一个实验时,这个问题不明显,但是要同时做多个实验,那么如何避免前面的实验给后面的实验带来影响,这个影响就是流量偏置,意思是在前面实验的流量分配中,有一种潜在的因素在影响流量分配,这个潜在的因素不易被人察觉,潜在的因素如果会影响实验结果,那么处在这个实验后面获得流量的实验,就很难得到客观的结论。这个无偏置要求,也叫做“正交”。
这些问题也是实验平台在设计之初要考虑的。试想一下,推荐系统中,算法工程师总是在尝试很多模型,或者在线下给出很多的模型调参,线下评测时,各种指标都是一片锣鼓喧天、红旗招展,恨不得立即上线去验验真实效果。
每一个算法工程师都这么想,但是线上流量有限,因此需要重叠实验,废水循环,最好能够做到洗脸的水冲马桶,这样灵活的实验平台长什么样子。
Google 公司的实验平台已经成为行业争相学习的对象,所以今天我会以 Google 的实验平台为主要对象,深入浅出地介绍一个重叠实验平台的方方面面。

重叠实验架构

所谓重叠实验,就是一个流量从进入产品服务,到最后返回结果呈现给用户,中间设置了好几个检查站,每个检查站都在测试某些东西,这样同时做多组实验就是重叠实验。
前面说了,重叠实验最大的问题是怎么避免流量偏置。为此,需要引入三个概念。
域:是流量的一个大的划分,最上层的流量进来时首先是划分域。
层:是系统参数的一个子集,一层实验是对一个参数子集的测试。
桶:实验组和对照组就在这些桶中。
层和域可以互相嵌套。意思是对流量划分,例如划分出 50%,这 50% 的流量是一个域,这个域里面有多个实验层,每一个实验层里面还可以继续嵌套域,也就是可以进步划分这 50% 的流量。下面这两个图示意了有域划分和没有域划分的两种情况。
图中左边是一个三层实验,但是并没有没有划分域。第一层实验要测试 UI 相关,第二层要测试推荐结果,第三层要测试在推荐结果插入广告的结果。
三层互不影响。图中的右边则添加了域划分,也就是不再是全部流量都参与实验中,而是被分走了一部分到左边域中。剩下的流量和左边的实验一样。
这里要理解一点,为什么多层实验能做到重叠而不带来流量偏置呢?
这就需要说桶的概念。还是上面示意图中的左图,假如这个实验平台每一层都是均匀随机分成 5 个桶,在实际的实验平台上,可能是上千个桶,这里只是为了举例。
示意图如下:
这是一个划分域的三层实验。每一层分成 5 个桶,一个流量来了,在第一层,有统一的随机分流算法,将 Cookie 或者 UUID 加上第一层 ID,均匀散列成一个整数,再把这个整数对 5 取模,于是一个流量就随机地进入了 5 个桶之一。
每一个桶均匀得到 20% 的流量。每一个桶里面已经决定好了为你展示什么样的 UI,流量继续往下走。每一个桶的流量接着依然面对随机进入下一层实验的 5 个桶之一,原来每个桶的 20% 流量都被均分成 5 份,每个桶都有 4% 的流量进入到第二层的每个桶。
这样一来,第二层每个桶实际上得到的依然是总流量的 20%,而且上一层实验带来的影响被均匀地分散在了这一层的每一个桶中,也就是可以认为上一层实验对这一层没有影响。同样的,第三层实验也是这样。
这就是分层实验最最基本的原理。在这个基础上,增加了域的概念,只是为了更加灵活地配置更多实验。
关于分层实验,有几点需要注意:
每一层分桶时,不是只对 Cookie 或者 UUID 散列取模,而是加上了层 ID,是为了让层和层之间分桶相互独立;
Cookie 或者 UUID 散列成整数时,考虑用均匀的散列算法,如 MD5。
取模要一致,为了用户体验,虽然是分桶实验,但是同一个用户在同一个位置每次感受不一致,会有损用户体验。
Google 的重叠实验架构还有一个特殊的实验层,叫做发布层,优先于所有其他的实验层,它拥有全部流量。这个层中的实验,通常是已经通过了 ABtest 准备全量发布了。示意图如下:
前面举例所说的对用户身份 ID 做散列的流量分配方式,只是其中一种,还有三种流量分配方式,一共四种:
Cookie+ 层 ID 取模;
完全随机;
用户 ID+ 层 ID 取模;
Cookie+ 日期取模。
在实验中,得到流量后还可以增加流量条件,比如按照流量地域,决定要不要对其实验,如果不符合条件,则这个流量不会再参与后面的实验,这样避免引入偏置,那么这个流量会被回收,也就是使用默认参数返回结果。
在 Google 的架构中,由于层和域还可以嵌套,所以在进入某个层时,可能会遇到一个嵌套域,这时候需要按照域划分方式继续下沉,直到遇到实验或者被作为回收流量返回。整个实验平台,工作的示意图如下所示:
说明如下:
图中涉及了判断的地方,虚线表示判断为假,实线表示判断为真。
从最顶端开始,不断遍历域、层、桶,最终输出一个队列 Re,其中记录对每一个系统参数子集如何处理,取实验配置的参数还是使用默认参数,其中无偏流量表示使用默认参数,也就是在那一层不参与实验,流量被回收。
拿到 Re 就得到了全部的实验,在去调用对应的服务。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《推荐系统三十六式》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(11)

  • 行行行
    https://storage.googleapis.com/pub-tools-public-publication-data/pdf/36500.pdf 原文链接
    2018-05-10
    10
  • 聂文峰-峰哥
    因为每一层的没个桶的数据都均匀随机的受到上层实验的影响,所以在该层实验之前有差异就是同一层各桶实验引起的
    2018-11-22
    2
  • orc
    有时候层和层之间有关联关系怎么解决?


    比如召回和排序,这两个是独立的层。但是某些情况下,参数有关联关系,需要同时在一个桶
    2019-07-04
    2
  • shangqiu86
    目前我接触的我们的平台,并没有域层桶的概念,就是以pin划分,随机划分10%,或者5%的流量(pin)走入需要对比效果的算法实验里,一旦划分这个pin的都是走这个算法实验
    2019-05-08
  • shangqiu86
    老师,这里有多少个桶是不是我们就可以上多少个实验同时进行效果观察

    作者回复: 对。

    2019-05-08
  • shangqiu86
    下一层得到了上一层每个桶内的流量,这样若上层有个桶内有偏置,下层的每个桶内均匀分得了这部分偏置数据,也就不偏置了
    2019-05-08
  • 帅帅
    小团队的推荐系统,玩这个太大了;
    初期我还是用userId%2来区分好了
    2018-09-25
  • 林彦
    每一个流量标识只会属于一个桶,每一个桶只会属于一个层,它只会属于一个特定层的实验,直到这个实验结束。
    2018-05-13
  • 曹林华
    层与层之间有 id 区分
    hash 取模的时候加入层 id 来避免不同层层影响
    我们做实验采取的是每层通过加salt 的方式,效果其实和层 id 类似
    2018-05-10
  • 仲杰
    请问老师,资料的原文链接有吗

    作者回复: 有,我最后会单独整理一篇整个专栏的参考文献列表,请注意查收。

    2018-05-09
  • 极客星星
    老师你好 请问google的平台有没有对应的论文介绍 如果有的话 能否提供下链接 谢谢

    作者回复: 有,最后会整理一篇我所有的参考文献列表,请注意按需阅读。

    2018-05-09
收起评论
11
返回
顶部