简单却有效的Bandit算法

我在之前的文章中表达过,推荐系统的使命就是在建立用户和物品之间的连接。建立连接可以理解成:为用户匹配到最佳的物品;但也有另一个理解就是,在某个时间某个位置为用户选择最好的物品。

推荐就是选择

生活中,你我都会遇到很多要做选择的场景。上哪个大学,学什么专业,去哪家公司,中午吃什么等等。这些事情,都让选择困难症的我们头很大。头大在哪呢?主要是不知道每个选择会带来什么后果。你仔细想一下,生活中为什么会害怕选择,究其原因是把每个选项看成独一无二的个体,一旦错过就不再来。推荐系统中一个一个单独的物品也如此,一旦选择呈现给用户,如果不能得到用户的青睐,就失去了一个展示机会。如果跳出来看这个问题,选择时不再聚焦到具体每个选项,而是去选择类别,这样压力是不是就小了很多?比如说,把推荐选择具体物品,上升到选择策略。如果后台算法中有三种策略:按照内容相似推荐,按照相似好友推荐,按照热门推荐。每次选择一种策略,确定了策略后,再选择策略中的物品,这样两个步骤。

那么,是不是有办法来解决这个问题呢?当然有!那就是 Bandit 算法。

MAB 问题

Bandit 算法来源于人民群众喜闻乐见的赌博学,它要解决的问题是这样的。一个赌徒,要去摇老虎机,走进赌场一看,一排老虎机,外表一模一样,但是每个老虎机吐钱的概率可不一样,他不知道每个老虎机吐钱的概率分布是什么,那么想最大化收益该怎么整?

这就是多臂赌博机问题 (Multi-armed bandit problem, K-armed bandit problem, MAB),简称 MAB 问题。有很多相似问题都属于 MAB 问题。

1. 假设一个用户对不同类别的内容感兴趣程度不同,当推荐系统初次见到这个用户时,怎么快速地知道他对每类内容的感兴趣程度?这也是推荐系统常常面对的冷启动问题。

2. 假设系统中有若干广告库存物料,该给每个用户展示哪个广告,才能获得最大的点击收益,是不是每次都挑收益最好那个呢?

3. 算法工程师又设计出了新的策略或者模型,如何既能知道它和旧模型相比谁更靠谱又对风险可控呢?

这些问题全都是关于选择的问题。只要是关于选择的问题,都可以简化成一个 MAB 问题。

我在前面的专栏中提过,推荐系统里面有两个顽疾,一个是冷启动,一个是探索利用问题,后者又称为 EE 问题:Exploit-Explore 问题。针对这两个顽疾,Bandit 算法可以入药。

冷启动问题好说,探索利用问题什么意思?利用意思就是:比较确定的兴趣,当然要用啊。好比说我们已经挣到的钱,当然要花啊。探索的意思就是:不断探索用户新的兴趣才行,不然很快就会出现一模一样的反复推荐。就好比我们虽然有一点钱可以花了,但是还得继续搬砖挣钱啊,要不然,花完了就要喝西北风了。

Bandit 算法

Bandit 算法并不是指一个算法,而是一类算法。现在就来介绍一下 Bandit 算法家族怎么解决这类选择问题的。首先,来定义一下,如何衡量选择的好坏?Bandit 算法的思想是:看看选择会带来多少遗憾,遗憾越少越好。在 MAB 问题里,用来量化选择好坏的指标就是累计遗憾,计算公式如图所示。

简单描述一下这个公式。公式有两部分构成:一个是遗憾,一个是累积。求和符号内部就表示每次选择的遗憾多少。

Wopt 就表示,每次都运气好,选择了最好的选择,该得到多少收益,

WBi 就表示每一次实际选择得到的收益,两者之差就是“遗憾”的量化,在 T 次选择后,就有了累积遗憾。

在这个公式中:为了简化 MAB 问题,每个臂的收益不是 0,就是 1,也就是伯努利收益。这个公式可以用来对比不同 Bandit 算法的效果:对同样的多臂问题,用不同的 Bandit 算法模拟试验相同次数,比比看哪个 Bandit 算法的累积遗憾增长得慢,那就是效果较好的算法。Bandit 算法的套路就是:小心翼翼地试,越确定某个选择好,就多选择它,越确定某个选择差,就越来越少选择它。

如果某个选择实验次数较少,导致不确定好坏,那么就多给一些被选择机会,直到确定了它是金子还是石头。简单说就是,把选择的机会给“确定好的”和“还不确定的”。

Bandit 算法中有几个关键元素:臂,回报,环境。

1. 臂:是每次选择的候选项,好比就是老虎机,有几个选项就有几个臂;

2. 回报:就是选择一个臂之后得到的奖励,好比选择一个老虎机之后吐出来的金币;

3. 环境:就是决定每个臂不同的那些因素,统称为环境。

将这个几个关键元素对应到推荐系统中来。

1. 臂:每次推荐要选择候选池,可能是具体物品,也可能是推荐策略,也可能是物品类别;

2. 回报:用户是否对推荐结果喜欢,喜欢了就是正面的回报,没有买账就是负面回报或者零回报;

3. 环境:推荐系统面临的这个用户就是不可捉摸的环境。

下面直接开始陈列出最常用的几个 Bandit 算法。

1. 汤普森采样算法

第一个是汤普森采样算法。这个算法我个人很喜欢它,因为它只要一行代码就可以实现,并且数学的基础最简单。

简单介绍一下它的原理:假设每个臂是否产生收益,起决定作用的是背后有一个概率分布,产生收益的概率为 p。

每个臂背后绑定了一个概率分布;每次做选择时,让每个臂的概率分布各自独立产生一个随机数,按照这个随机数排序,输出产生最大随机数那个臂对应的物品。听上去很简单,为什么这个随机数这么神奇?

关键在于每个臂背后的概率分布,是一个贝塔分布,先看看贝塔分布的样子:

贝塔分布有 a 和 b 两个参数。这两个参数决定了分布的形状和位置:

1. 当 a+b 值越大,分布曲线就越窄,分布就越集中,这样的结果就是产生的随机数会容易靠近中心位置;

2. 当 a/(a+b) 的值越大,分布的中心位置越靠近 1,反之就越靠近 0,这样产生的随机数也相应第更容易靠近 1 或者 0。

贝塔分布的这两个特点,可以把它分成三种情况:

1. 曲线很窄,而且靠近 1;

2. 曲线很窄,而且靠近 0;

3. 曲线很宽。

这和前面所讲的选择有什么关系呢?你把贝塔分布的 a 参数看成是推荐后得到用户点击的次数,把分布的 b 参数看成是没有得到用户点击的次数。按照这个对应,再来叙述一下汤普森采样的过程。

1. 取出每一个候选对应的参数 a 和 b;

2. 为每个候选用 a 和 b 作为参数,用贝塔分布产生一个随机数;

3. 按照随机数排序,输出最大值对应的候选;

4. 观察用户反馈,如果用户点击则将对应候选的 a 加 1,否则 b 加 1;

注意,实际上在推荐系统中,要为每一个用户都保存一套参数,比如候选有 m 个,用户有 n 个,那么就要保存 2 * m * n 个参数。汤普森采样为什么有效呢?解释一下。

1. 如果一个候选被选中的次数很多,也就是 a+b 很大了,它的分布会很窄,换句话说这个候选的收益已经非常确定了,用它产生随机数,基本上就在中心位置附近,接近平均收益。

2. 如果一个候选不但 a+b 很大,即分布很窄,而且 a/(a+b) 也很大,接近 1,那就确定这是个好的候选项,平均收益很好,每次选择很占优势,就进入利用阶段,反之则几乎再无出头之日。

3. 如果一个候选的 a+b 很小,分布很宽,也就是没有被选择太多次,说明这个候选是好是坏还不太确定,那么用它产生随机数就有可能得到一个较大的随机数,在排序时被优先输出,这就起到了前面说的探索作用。

用 Python 实现汤普森采样就一行:

choice = numpy.argmax(pymc.rbeta(1 + self.wins, 1 + self.trials - self.wins))

2.UCB 算法

第二个常用的 Bandit 算法就是 UCB 算法,UCB 算法全称是 Upper Confidence Bound,即置信区间上界。它也为每个臂评分,每次选择评分最高的候选臂输出,每次输出后观察用户反馈,回来更新候选臂的参数。每个臂的评分公式为.

公式有两部分,加号前面是这个候选臂到目前的平均收益,反应了它的效果,后面的叫做 Bonus,本质上是均值的标准差,反应了候选臂效果的不确定性,就是置信区间的上边界。t 是目前的总选择次数,Tjt 是每个臂被选择次数。

观察这个公式,如果一个候选的被选择次数很少,即 Tjt 很小,那么它的 Bonus 就会较大,在最后排序输出时有优势,这个 Bonus 反映了一个候选的收益置信区间宽度,Bonus 越大,候选的平均收益置信区间越宽,越不确定,越需要更多的选择机会。

反之如果平均收益很大,就是说加号左边很大,也会在被选择时有优势。

这个评分公式也和汤普森采样是一样的思想:

1. 以每个候选的平均收益为基准线进行选择;

2. 对于被选择次数不足的给予照顾;

3. 选择倾向的是那些确定收益较好的候选。

3. Epsilon 贪婪算法

这是一个朴素的算法,也很简单有效,思想有点类似模拟退火,做法如下。

1. 先选一个 (0,1) 之间较小的数,叫做 Epsilon,也是这个算法名字来历。

2. 每次以概率 Epsilon 做一件事:所有候选臂中随机选一个,以 1-Epsilon 的概率去选择平均收益最大的那个臂。

是不是简单粗暴?Epsilon 的值可以控制对探索和利用的权衡程度。这个值越接近 0,在探索上就越保守。

和这种做法相似,还有一个更朴素的做法:先试几次,等每个臂都统计到收益之后,就一直选均值最大那个臂。

4. 效果对比

以上几个算法,可以简单用模拟试验的方式对比其效果,如图所示。

横坐标是模拟次数增加,可以看成随着时间推移,纵坐标就是累积遗憾,越高说明搞砸的次数越多。在模拟后期,基本上各种算法优劣一目了然。从上到下分别是下面几种。

1. 完全随机:就是不顾用户反馈的做法。

2. 朴素选择:就是认准一个效果好的,一直推。

3. Epsilon 贪婪算法:每次以小概率尝试新的,大概率选择效果好的。

4. UCB:每次都会给予机会较少的候选一些倾向。

5. 汤普森采样:用贝塔分布管理每一个候选的效果。

UCB 算法和汤普森采样都显著优秀很多。

冷启动

我想,你已经想到了,推荐系统冷启动问题可以用 Bandit 算法来解决一部分。大致思路如下:

1. 用分类或者 Topic 来表示每个用户兴趣,我们可以通过几次试验,来刻画出新用户心目中对每个 Topic 的感兴趣概率。

2. 这里,如果用户对某个 Topic 感兴趣,就表示我们得到了收益,如果推给了它不感兴趣的 Topic,推荐系统就表示很遗憾 (regret) 了。

3. 当一个新用户来了,针对这个用户,我们用汤普森采样为每一个 Topic 采样一个随机数,排序后,输出采样值 Top N 的推荐 Item。注意,这里一次选择了 Top N 个候选臂。

4. 等着获取用户的反馈,没有反馈则更新对应 Topic 的 b 值,点击了则更新对应 Topic 的 a 值。

总结

今天给你介绍了一种走一步看一步的推荐算法,叫做 Bandit 算法。Bandit 算法把每个用户看成一个多变的环境,待推荐的物品就如同赌场里老虎机的摇臂,如果推荐了符合用户心目中喜欢的,就好比是从一台老虎机中摇出了金币一样。今天重点介绍的 Bandit 算法有汤普森采样,UCB 算法,Epsilon 贪婪,并且用模拟的方式对比了它们的效果,汤普森采样以实现简单和效果显著而被人民群众爱戴,你需要时不妨首先试试它。同时,这里留下一个问题给你,今天讲到的 Bandit 算法有哪些不足?

结合上下文信息的Bandit算法

上一篇文章我说到,Bandit 算法用的是一种走一步看一步的思路,这一点看上去非常佛系,似乎一点都不如机器学习深度学习那样厚德载物,但是且慢下结论,先看看我在前面介绍的那几个 Bandit 算法。

UCB 回顾

这些 Bandit 算法,都有一个特点:完全没有使用候选臂的特征信息。特征可是机器学习的核心要素,也是机器学习泛化推广的依赖要素。没有使用特征信息的 Bandit 算法,问题就在于只能对当前已有的这些候选臂进行选择,对于新加入的候选只能从 0 开始积累数据,而不能借助已有的候选泛化作用。举个例子,假如有一个用户是鹿晗的粉丝,通过 Bandit 算法有两个鹿晗的广告得到展示,并得到了较好的收益。那么对于一个新的广告,如果具有鹿晗这个特征,直觉上前两个鹿晗广告的收益信息可以泛化到当前新广告上,新广告就不是完全从 0 开始积累数据,而是有了一定的基础,这样的收敛会更快。UCB 和汤普森采样这两个 Bandit 算法在实际中表现很好。于是,前辈们就决定送 UCB 去深造一下,让它能够从候选臂的特征信息中学到一些知识。UCB 就是置信上边界的简称,所以 UCB 这个名字就反映了它的全部思想。置信区间可以简单直观地理解为不确定性的程度,区间越宽,越不确定,反之就很确定。每个候选的回报均值都有个置信区间,随着试验次数增加,置信区间会变窄,相当于逐渐确定了到底回报丰厚还是可怜。每次选择前,都根据已经试验的结果重新估计每个候选的均值及置信区间。选择置信区间上界最大的那个候选。

“选择置信区间上界最大的那个候选”,这句话反映了几个意思:如果候选的收益置信区间很宽,相当于被选次数很少,还不确定,那么它会倾向于被多次选择,这个是算法冒风险的部分;如果候选的置信区间很窄,相当于被选次数很多,比较确定其好坏了,那么均值大的倾向于被多次选择,这个是算法保守稳妥的部分;UCB 是一种乐观冒险的算法,它每次选择前根据置信区间上界排序,反之如果是悲观保守的做法,可以选择置信区间下界排序。

LinUCB

“Yahoo!”的科学家们在 2010 年基于 UCB 提出了 LinUCB 算法,它和传统的 UCB 算法相比,最大的改进就是加入了特征信息,每次估算每个候选的置信区间,不再仅仅是根据实验,而是根据特征信息来估算,这一点就非常的“机器学习”了。在广告推荐领域,每一个选择的样本,由用户和物品一起构成,用户特征,物品特征,其他上下文特征共同表示出这个选择,把这些特征用来估计这个选择的预期收益和预期收益的置信区间,就是 LinUCB 要做的事情。LinUCB 算法做了一个假设:一个物品被选择后推送给一个用户,其收益和特征之间呈线性关系。在具体原理上,LinUCB 有一个简单版本以及一个高级版本。简单版本其实就是让每一个候选臂之间完全互相无关,参数不共享。高级版本就是候选臂之间共享一部分参数。先从简单版本讲起。还是举个例子,假设现在两个用户,用户有一个特征就是性别,性别特征有两个维度,男,女。现在有四个商品要推荐给这两个用户,示意如下。

两个用户就是 Bandit 算法要面对的上下文,表示成特征就是下面的样子。

每一次推荐时,用特征和每一个候选臂的参数去预估它的预期收益和置信区间。xi​×θj​,这就是给男性用户推荐剃须刀,给女性用户推荐口红,即使是新用户,也可以作出比随机猜测好的推荐,再观察用户是否会点击,用点击信息去更新那个被推荐了的候选臂的参数。这里的例子还简化了一个地方,就是没有计算置信区间,这是 UCB 的精髓。下面来补上。假如 D 是候选臂是候选臂在 m 次被选择中积累的特征,相当于就是 m 条样本,特征维度是 d,所以 D 是一个矩阵,维度是 m x d。这 m 次被选择,每次得到用户的点击或者没点击,把这个反馈信息记录为一个 m x 1 的向量,叫做 C。所以这个候选臂对应的参数就是 d x 1 的向量,d 就是特征维度数,记录为一个戴帽子的西塔,θ^。按照 LinUCB 认为,参数和特征之间线性相乘就应该得到收益:

你看 D 也知道,C 也知道,要求 θ ,这就很简单了。

但是由于数据稀疏,实际上求参数西塔时不会这样简单粗暴,而是采用岭回归的方法,给原始特征矩阵加上一个单位对角矩阵后再参与计算:

每一个候选臂都像这样去更新它的参数,同时,得到参数后,在真正做选择时,用面对上下文的特征和候选臂的参数一起。除了估算期望收益,还要计算置信区间的上边界,如果 x 是上下文特征,则期望收益和置信上边界的计算方法分别是下面的样子。期望收益:

置信区间上边界:

这两个计算结果都是标量数值。置信区间计算公式虽然看起来复杂,实际上反应的思想也很直观,随着被选择次数的增加,也就是 m 增加,这个置信上边界是越来越小的。每一次选择时给每一个候选臂都计算这两个值,相加之后选择最大那个候选臂输出,就是 LinUCB 了。刚才说到了岭回归(ridge regression),这里多说一句,岭回归主要用于当样本数小于特征数时,对回归参数进行修正。对于加了特征的 Bandit 问题,正好符合这个特点:试验次数(样本)少于特征数。信息量有点大,我在这里再一次列出 LinUCB 的重点。LinUCB 不再是上下文无关地,像盲人摸象一样从候选臂中去选择了,而是要考虑上下文因素,比如是用户特征、物品特征和场景特征一起考虑。每一个候选臂针对这些特征各自维护一个参数向量,各自更新,互不干扰。每次选择时用各自的参数去计算期望收益和置信区间,然后按照置信区间上边界最大的输出结果。观察用户的反馈,简单说就是“是否点击”,将观察的结果返回,结合对应的特征,按照刚才给出的公式,去重新计算这个候选臂的参数。当 LinUCB 的特征向量始终取 1,每个候选臂的参数是收益均值的时候,LinUCB 就是 UCB。说完简单版的 LinUCB,再看看高级版的 LinUCB。与简单版的相比,就是认为有一部分特征对应的参数是在所有候选臂之间共享的,所谓共享,也就是无论是哪个候选臂被选中,都会去更新这部分参数。

构建特征

LinUCB 算法有一个很重要的步骤,就是给用户和物品构建特征,也就是刻画上下文。在“Yahoo!”的应用中,物品是文章。它对特征做了一些工程化的处理,这里稍微讲一下,可供实际应用时参考借鉴。首先,原始用户特征有下面几个。人口统计学:性别特征(2 类),年龄特征(离散成 10 个区间)。地域信息:遍布全球的大都市,美国各个州。行为类别:代表用户历史行为的 1000 个类别取值。其次,原始文章特征有:URL 类别:根据文章来源分成了几十个类别。编辑打标签:编辑人工给内容从几十个话题标签中挑选出来的。原始特征向量先经过归一化,变成单位向量。再对原始用户特征做第一次降维,降维的方法就是利用用户特征和物品特征以及用户的点击行为去拟合一个矩阵 W。

就用逻辑回归拟合用户对文章的点击历史,得到的 W 直觉上理解就是:能够把用户特征映射到物品特征上,相当于对用户特征降维了,映射方法是下面这样。

这一步可以将原始的 1000 多维用户特征投射到文章的 80 多维的特征空间。然后,用投射后的 80 多维特征对用户聚类,得到 5 个类,文章页同样聚类成 5 个类,再加上常数 1,用户和文章各自被表示成 6 维向量。接下来就应用前面的 LinUCB 算法就是了,特征工程依然还是很有效的。

总结

今天我和你分享了一种上下文有关的 Bandit 算法,叫做 LinUCB,它有这么几个优点:由于加入了特征,所以收敛比 UCB 更快,也就是比 UCB 更快见效;各个候选臂之间参数是独立的,可以互相不影响地更新参数;由于参与计算的是特征,所以可以处理动态的推荐候选池,编辑可以增删文章;当然,LinUCB 以及所有的 Bandit 算法都有个缺点:同时处理的候选臂数量不能太多,不超过几百个最佳。因为每一次要计算每一个候选臂的期望收益和置信区间,一旦候选太多,计算代价将不可接受。LinUCB 只是一个推荐框架,可以将这个框架应用在很多地方,比如投放广告,为用户选择兴趣标签,你还可以发挥聪明才智,看看它还能用来解决什么问题

如何将Bandit算法与协同过滤结合使用

推荐系统中最经典的算法是什么?对,是协同过滤,你已经学会抢答了。是的,协同过滤是推荐系统发展史上浓墨重彩的一笔,其背后的思想简单深刻,在万物互联的今天,协同过滤的威力更加强大。与其说协同过滤是一门技术,不如说是一种方法论,不是机器在为你推荐,而是“集体智慧”在为你推荐。协同过滤生动地诠释了什么是“物以类聚,人以群分”,你的圈子决定了你能见到的物品,这一点在前面的专栏中已经详细讲过了。但是这背后隐藏了一个重要的问题:是不是会存在信息茧房的问题?

信息茧房

其实作为一名对推荐系统略懂一二的普通海淀群众,我个人就会时常担心,是不是还能看到新的东西,是不是有惊喜。时不时乱点一通,是不是叉掉所有的推荐,让物品的推荐系统崩溃一下,这一切就是为了避免进入信息茧房,在眼前的圈子里苟且。那么作为推荐系统的开发者,是不是应该做点什么呢?是的,在技术上,Bandit 算法就是一个权衡探索和利用的好方法。如果把它结合传统的协同过滤来做推荐,那么在一定程度上就可以延缓信息茧房的到来,偶遇诗和远方。我已经和你聊了两篇关于 Bandit 算法的内容,我介绍过普通的 Bandit 算法,也介绍过加入特征信息的 LinUCB 算法,今天,我要介绍的是一个新方法,如何结合协同过滤的群体智慧,与 Bandit 的走一步看一步一起,让两种思想碰撞,也许可以让你的推荐系统与众不同。

这就是 2016 年有人提出的 COFIBA 算法,下面我就开始与你聊聊这种算法。

COFIBA 算法

1 思想

很多的推荐场景中都有两个规律。

1. 相似的用户对同一个物品的反馈可能是一样的。也就是对一个聚类用户群体推荐同一个 item,他们可能都会喜欢,也可能都不喜欢,同样的,同一个用户会对相似的物品反馈也会相同。这实际上就是基于用户的协同过滤基本思想。

2. 在使用推荐系统过程中,用户的决策是动态进行的,尤其是新用户。这就导致无法提前为用户准备好推荐候选,只能“走一步看一步”,是一个动态的推荐过程。这是 Bandit 的算法基本思想。

每一个推荐候选物品,都可以根据用户对其偏好的不同,将用户分成不同的群体。

然后下一次,由用户所在的群体集体帮他预估可能的收益及置信区间,这个集体就有了协同的效果,然后再实时观察真实反馈,回来更新用户的个人参数用于下次调整收益和置信区间,这就有了 Bandit 的思想在里面。举个例子,如果你的父母给你安排了很多相亲对象,要不要见面去相一下?那需要提前看看每一个相亲对象的资料,每次大家都分成好几派,有说好的,有说再看看的,也有说不行的。

你自己也会是其中一派的一员,每次都是你所属的那一派给你集体打分,因为他们是和你“三观一致的人”“诚不欺我”;这样从一堆资料中挑出分数最高的那个人,你出去见 TA,回来后把实际感觉说给大家听,同时自己心里的标准也有些调整,重新再给剩下的其它对象打分,打完分再去见,如果要推荐的候选物品较多,需要对物品聚类,就不用按照每一个物品对用户聚类,而是按照每一个物品所属的类簇对用户聚类,如此一来,物品的类簇数目相对于物品数就要大大减少。

2. 细节

基于上述的思想,COFIBA 算法要点摘要如下。

1. 在时刻 t,有一个用户来访问推荐系统,推荐系统需要从已有的候选池子中挑一个最佳的物品推荐给他,然后观察他的反馈,用观察到的反馈来更新挑选策略。

2. 这里的每个物品都有一个特征向量,所以这里的 Bandit 算法是 context 相关的,只不过这里虽然是给每个用户维护一套参数,但实际上是由用户所在的聚类类簇一起决定结果的。

3. 这里依然是用岭回归去拟合用户的权重向量,用于预测用户对每个物品的可能反馈(payoff),这一点和我们上一次介绍的 LinUCB 算法是一样的。

对比上一次介绍的 LinUCB 算法,COFIBA 的不同有两个:

1. 基于用户聚类挑选最佳的物品,即相似用户集体动态决策;

2. 基于用户的反馈情况调整用户和物品的聚类结果。

整体算法过程如下:

在针对某个用户 i,在每一次推荐时做以下事情:

1. 首先计算用户 i 的 Bandit 参数 W,做法和 LinUCB 算法相同,但是这个参数并不直接参与到选择决策中,注意这和 LinUCB 不同,只是用来更新用户聚类。

2. 遍历候选物品,每一个物品已经表示成一个向量 x 了。

3. 每一个物品都对应一个物品聚类类簇,每一个物品类簇对应一个全量用户聚类结果,所以遍历到每一个物品时,就可以判断出当前用户在当前物品面前,自己属于哪个用户聚类类簇,然后把对应类簇中每个用户的 M 矩阵 (对应 LinUCB 里面的 A 矩阵),b 向量(表示收益向量,对应 LinUCB 里面的 b 向量)加起来,从而针对这个类簇求解一个岭回归参数(类似 LinUCB 里面单独针对每个用户所做),同时计算其收益预测值和置信区间上边界。

4.  每个待推荐的物品都得到一个预测值及置信区间上界,挑出那个上边界最大的物品作为推荐结果。

5. 观察用户的真实反馈,然后更新用户自己的 M 矩阵和 b 向量,只更新每个用户,对应类簇里其他的不更新。

以上是 COFIBA 算法的一次决策过程。在收到用户真实反馈之后,还有两个计算过程:

1. 更新 user 聚类;

2. 更新 item 聚类。

如何更新 user 和 item 的聚类呢?我在这里给出了一个示意图。

解释一下这个图。

(a) 示意图中有 6 个用户,8 个物品,初始化时,用户和物品的类簇个数都是 1。

(b)在某一轮推荐时,推荐系统面对的用户是 4。推荐过程就是遍历 1~8 每个物品,然后在面对每个物品时,用户 4 在哪个类簇中,把对应类簇中的用户聚合起来为这个物品集体预测收益值置信上边界。这里假设最终物品 5 胜出,被推荐出去了。

在时刻 t,物品一共有 3 个聚类类簇,需要更新的用户聚类是物品 5 对应的用户 4 所在类簇。

更新方式:看看该类簇里面除了用户 4 之外的用户,对物品 5 的预期收益是不是和用户 4 相近,如果是,则保持原来的连接边,否则删除原来的连接边。删除边之后相当于就重新构建了聚类结果。

这里假设新的聚类结果由原来用户 4 所在的类簇分裂成了两个类簇:4 和 5 成一类,6 单独自成一类。

(c)更新完用户类簇后,被推荐出去的物品 5,它对应的类簇也要更新。更新方式是:对于每一个和物品 5 还存在连接边的物品,假如叫做物品 j,都有一个对这个物品 j 有相近收益预估值的近邻用户集合,然后看看近邻用户集合是不是和刚刚更新后的用户 4 所在的类簇相同。是的话,保留物品 5 和物品 j 之间的连接边,否则删除。这里示意图中是物品 3 和物品 5 之间的连接边被删除。物品 3 变成了孤家寡人一个,不再和任何物品有链接,独立后就给他初始化了一个全新的用户聚类结果:所有用户是一个类簇。

简单来说就是这样:

1. 用协同过滤来少选可以参与决策的用户代表,用 LinUCB 算法来实际执行选择;

2. 根据用户的反馈,调整基于用户和基于物品的聚类结果,即对物品和用户的群体代表做换届选举;

3. 基于物品的聚类如果变化,又进一步改变了用户的聚类结果;

4. 不断根据用户实时动态的反馈来调整用户决策参数,从而重新划分聚类结果矩阵。

COFIBA 算法也很容易实现,GitHub 上就有。原始论文也从理论和实验两方面都证明了它的有效性。

再谈 EE 问题

整个专栏的 Bandit 算法系列,主要是解决推荐系统中的冷启动和 EE 问题。探索和利用这一对矛盾一直客观存在,而 Bandit 算法是公认的一种比较好的解决 EE 问题的方案。除了 Bandit 算法之外,还有一些其他的探索兴趣的办法,比如在推荐时,随机地去掉一些用户历史行为(特征)。解决兴趣探索,势必要冒险,势必要面对用户的未知,而这显然就是可能会伤害当前用户价值的:明知道用户肯定喜欢 A,你还偏偏以某个小概率给推荐非 A。

实际上,很少有公司会采用这些理性的办法做探索,反而更愿意用一些盲目主观的方式。究其原因,可能是因为:

1. 互联网产品生命周期短,而探索又是为了提升长期利益的,所以没有动力做;

2. 用户使用互联网产品时间越来越碎片化,探索的时间长,难以体现出探索的价值;

3. 同质化互联网产品多,用户选择多,稍有不慎,用户用脚投票,分分钟弃你于不顾;

4. 已经成规模的平台,红利杠杠的,其实是没有动力做探索的。

基于这些,我们如果想在自己的推荐系统中引入探索机制,需要注意以下几点:

1. 用于探索兴趣的物品,要保证其本身质量,纵使用户不感兴趣,也不至于引起其反感,损失平台品牌价值;

2. 探索兴趣的地方需要产品精心设计,让用户有耐心陪你玩儿;

3. 深度思考,这样才不会做出脑残的产品,产品不会早早夭折,才有可能让探索机制有用武之地。

总结

今天,我介绍完成了 MAB 问题和推荐系统之间的千丝万缕联系。Bandit 算法是一种不太常用在推荐系统的算法,究其原因,是它能同时处理的物品数量不能太多。但是,在冷启动和处理 EE 问题时,Bandit 算法简单好用,值得一试。当然,这个专栏介绍的所有推荐算法都不是单打独斗最好,而是与其他算法结合使用才能相映生辉,Bandit 算法亦是如此。今天介绍的 COFIOBA 算法,原理很简单,就是把协同过滤思想引入到了 Bandit 算法中,不再是用户独立决策,而是用户所在的群体共同决策推荐结果。这样比较问题,也可以加速收敛。

推荐系统详解(六)MAB问题相关推荐

  1. 六轴机器人直角坐标系建立_详解|六轴机器人,SCARA机器人,直角坐标机器人和 Delta机器人...

    原标题:详解|六轴机器人,SCARA机器人,直角坐标机器人和 Delta机器人 一.六轴工业机器人 六轴工业机器人的最大的工作空间类似一个球体,它可以将机械手臂末端工具以几乎任意角度放置在接近无限数量 ...

  2. Java源码详解六:ConcurrentHashMap源码分析--openjdk java 11源码

    文章目录 注释 类的继承与实现 数据的存储 构造函数 哈希 put get 扩容 本系列是Java详解,专栏地址:Java源码分析 ConcurrentHashMap 官方文档:ConcurrentH ...

  3. mysql 流复制_MySQL系列详解六:MySQL主从复制/半同步演示-技术流ken

    前言 随着技术的发展,在实际的生产环境中,由单台MySQL数据库服务器不能满足实际的需求.此时数据库集群就很好的解决了这个问题了.采用MySQL分布式集群,能够搭建一个高并发.负载均衡的集群服务器.在 ...

  4. MySQL系列详解六:MySQL主从复制/半同步演示-技术流ken

    前言 随着技术的发展,在实际的生产环境中,由单台MySQL数据库服务器不能满足实际的需求.此时数据库集群就很好的解决了这个问题了.采用MySQL分布式集群,能够搭建一个高并发.负载均衡的集群服务器.在 ...

  5. Android 动态分区详解(六) 动态分区的底层机制

    文章目录 1. Android 动态分区的两重含义 2. device mapper 的原理 3. linear 映射的原理 3.1 多个设备映射示例 3.2 `dmsetup create` 命令参 ...

  6. OpenLayers官方示例详解六之线串箭头样式(LineString Arrows)

    目录 一.示例简介 二.代码详解 三.总结 一.示例简介 为每一个线串(LineString)的子线段绘制箭头. 二.代码详解 <!DOCTYPE html> <html lang= ...

  7. 推荐系统详解(三)近邻推荐

    协同过滤的重点在于"协同",所谓协同,也就是群体互帮互助,互相支持是集体智慧的体现,协同过滤也是这般简单直接,历久弥新. 协同过滤 当你的推荐系统度过了只能使用基于内容的推荐阶段后 ...

  8. 吴喆:全民K歌直播推荐系统详解

    分享嘉宾:吴喆 腾讯音乐 高级研究员 编辑整理:吴祺尧 加州大学圣地亚哥分校 出品平台:DataFunTalk 导读:推荐技术在迭代思路上已经形成一套成熟的范式,通过对经典算法的解构与重组,通常能够产 ...

  9. 基于协同过滤算法的在线鲜花店推荐系统详解及GitHub下载

    [[TOC]] 基于协同过滤的在线鲜花店推荐系统 项目需求: 基于店铺的客户订单记录,实现店铺的推荐需求: 基于RFM模型,得到客户的价值分类,对高价值客户进行重点跟踪,推荐其潜在的商品列表,即实现: ...

最新文章

  1. php获取屏幕的宽高,JS获取屏幕宽高
  2. 这8个专业对“数学”要求很高,考生不要误选!
  3. 网易云信入选《2021 年浙江省首版次软件产品应用推广指导目录》
  4. 解决9.png malformed以及libpng warning: iCCP
  5. Office PPT如何切换到返回幻灯片
  6. 2019-05-21 Java学习日记之String类型Demo
  7. windows 10下搭建pyspark与遇到的一些问题的解决方法
  8. 读书 | 一切红利最终都是趋势红利
  9. Redis-cluster集群【第一篇】:redis安装及redis数据类型
  10. [HNOI2009]有趣的数列
  11. 如何用google ads赚钱
  12. CSRF跨站请求伪造攻击
  13. Kali Linux Network Scanning Cookbook读书笔记之nmap
  14. 在建工地扬尘在线监控系统推荐_综执 | 针对工地扬尘、噪音监控系统问题对各在建工地开展集中约谈...
  15. IDL 建立影像金字塔
  16. ajax 详解(GET,POST方式传输以其封装)
  17. 12_通过上下文操作私有目录模式说明
  18. Web前端可视化绘图软件编辑器-汇总
  19. C++ stl库 手写 源码分析
  20. 打开qq相册回收站一直显示服务器忙,qq照片回收站怎么打不开 手机qq回收站进不去怎么办...

热门文章

  1. 深度解析云智慧监控宝新版API监控
  2. 踩坑了、踩到一个特别无语的常识坑
  3. vue-cli2.0打包去掉console
  4. cocos creater H5游戏优化
  5. 有点坎坷,却又有点感动。
  6. 有关于日志的分类和使用
  7. SilverLight教程
  8. Android手机提示“内部存储空间不足”产生原因及解决方案
  9. Java基础(进制转换-)
  10. 巴士暖通空调系统的全球与中国市场2022-2028年:技术、参与者、趋势、市场规模及占有率研究报告