快手双边市场的复杂实验设计问题

人工智能 算法
本文将介绍在双边市场下激励策略的实验设计。

一、问题背景

1、双边市场实验介绍

双边市场,即平台,包含生产者与消费者两方参与者,双方相互促进。比如快手有视频的生产者,视频的消费者,两种身份可能存在一定程度重合。

双边实验是在生产者和消费者端组合分组的实验方式。

双边实验具有以下优点:

(1)可以同时检测新策略对两方面的影响,例如产品 DAU 和上传作品人数变化。双边平台往往有跨边网络效应,读者越多,作者越活跃,作者越活跃,读者也会跟着增加。

(2)可以检测效果溢出和转移。

(3)帮助我们更好得理解作用的机制,AB实验本身不能告诉我们原因和结果之间的关系,只能告诉我们所作事情会得出什么样的影响以及数据变化。但是生产端与消费端之间的作用机制,就需要更加复杂的实验设计和更多的实验指标才能把这些问题看清楚。

2、双边实验的例子

图片

里通过一个直播美颜的例子,帮助大家进一步理解双边实验。

假设在直播场景中加上美颜的效果。从表格中横着看,两行的实验的观众组,控制观众是否可以看到直播美颜前后的差异。表格中的列表示主播有没有美颜对实际的影响。将以上两方面结合,当且仅当实验组主播对照实验组观众时,才给视频开美颜功能。实际另外三个组无法看到美颜功能。但是 BC 看不到美颜,和 D 看不到美颜存在区别。AD 的区别是常规的 AB 实验的常见场景。本场景通过双边设计可以观察到观众侧是否存在溢出。

针对主播美没有美颜功能,若不存在观众溢出,则 BD 应该数据表现一致,但实际上,数据 BD 若存在差异,如果主播没有美颜功能,观众在其他主播侧看到美颜功能,则实际效果就存在了正影响或者负影响。同理,主播侧的溢出也可以通过此种双边实验,更好理解实验中的作用机制,和实验双方是否存在溢出。

二、激励策略的挑战

图片

供给侧-消费侧生态体系内部,业务时长有政策性流量扶持的需求,这就是激励策略,主要包括以下三种场景:

(1)运营引入优质作者,但不确定作者在平台上的数据表现;

(2)某些业务需要挖掘特定类型作者,给一些宏观调控上的流量扶持,予以更强的流量分发力度;

(3)平台意志场景下,按照某种特定方向发展,认为改变流量分配方式强化某些对应内容供给。

在以上场景下往往并非网络学习的方式,而是通过人为的角度对平台流量做宏观的调控。针对关注相对长期的,需要观察学习效应(促生产等),时间片轮转之类的方法不太试用。例如如下场景:给一类定向流量的作者流量的支持,来研究这样的流量在长期场景下,互动以及生产是否可以长久。

图片

首先是作者侧的挤占:大多数此类实验,平台的总曝光数量有限,平台扶持的场景下,实验组作者曝光增加,不被扶持的对照组曝光量减少。若作者侧冷启动曝光提升幅度比读者侧冷启动曝光幅度更大,就证明存在挤占情况。

根据上图根据实验组对照组关系以及开展各组曝光相对基线 diff,可以看出,随着实验开始对作者 boost 最后会通过推荐系统不仅传递给用户组 B 也会传递给用户组 A,并且作者 B 用户 B,作者 B 用户 A 的曝光 diff 是基本趋于一致的。传统实验一直致力于对此种策略扭曲的流量情况矫正。

图片

SUTVA 假设,个体 i 在实验过程中只与自身被分配在实验组或者对照组相关,与实验体系下其他节点在哪个分组无关,不论其他节点是合作关系还是竞争关系。SUTVA 是 AB 实验得到有效结论最基础的假设。

实际双边网络违背了 SUTVA 假设。

图片

在短视频场景下,如果把每一种记录策略看作一种排序算法。不同的激励策略代表短视频的不同排序结果。上图 RC 代表对照组,RT_25% 实验组流量是 25% 时的算法排序组合,RT 代表实验组实验推全 100% 算法排序组合。BCDE 为实验目标用户类型,即被选中的激励作者作品。而 D 为当实验推量 25% 时,正好落在实验组中。假设通过推荐加权的方式实验,D 的排序直接排到前面位置。若策略增加至 100%,BCDE 均被加权,这种情况,D 作品却排序反而下降。这种场景就是实验组挤占,以及出现挤占的原因。

三、可选解决方案

1、方案1:逐步扩量

图片

实验组排序 gap 会随着实验组数据比例扩大而逐渐接近,挤占的效应随着对照组流量减少而减少。

【先发优势】实验过程中发现,针对流量扶持的场景下,相等扶持力度,先扶持作者会始终保持流量优势。更早的扶持和加速发掘过程本身逻辑是前后一致的。

​分阶段扩量的实验详情:上图展示了分阶段扩量,纵坐标为相对 base 组涨粉数据差异。实验初期,20% 实验组的情况,只扶持了实验组 1,实验组一数据指标开始上升;当实验放量 60%,实验组 123 均开始扶持,另外两组实验指标也开始上升,但始终没有超过实验组 1;后面将实验组改成了 124,发现 4 也开始提升,但是 4 仍然无法超过实验组 3。

由此可以得出以下结论:逐步扩量是有用的,指标会根据扩量提升,提升会不会随着流量扩大而变小则无法确认。目前实验结果可以得出,先获得流量扶持的实验组数据表现会比后获得流量扶持的实验组更好。​

2、方案2:划分小世界

图片

如上图所示方法,将实验组和对照组完全隔离,实验组读者只能看到实验组作品,控制组读者只能看到控制组作品。由此避免出现作者和读者之间的挤压情况。

类似的做法有,将作者和读者的流量分发当成一个网络图,这个网络图并不是处处联通,部分读者只爱看部分几类作品,基于这样的网络图可以做实验组对照组的切分。以上做法与划分小世界方式思路一致,实践效果更好,但与此同时也具有更大的计算成本。

图片

划分小世界主要存在的问题为:

(1)算法推荐系统需要一定的规模量级才能冷启动,当切分池子一定小的时候,影响实际个性化分发空间。不同业务不同平台保留推荐弹性效果前提下,对切分结构最细粒度要求各不相同。大多数情况,推荐边际效应递减。

(2)明确的流量隔离,会对样本进行的实验数量和检验方式有一定限制。针对并行实验场景需要不断得将隔离开的用户重新打散重新拆分。

图片

从分析方法中矫正而不是实验设计的方式矫正:

  • 根据实际网络效应做矫正分析;
  • 根据实验结果做一些线性假设以及其他的一些条件假设。

采用实验方式矫正的原因:

首先实际的分析矫正方法中假设很难验证,对于差异较大的实验,网络效应的溢出挤占情况各不相同,很难在短时间内总结规律,无法得到通用方法。而实际我们的解决方案希望可以解决一大类问题。

四、构建综合方案

图片

基于排序融合的方案构建——本质上我们希望可以保证实验组 RT_a% 的排序和实验组RT_100% 的实际排序可以保持一致结果。

实现方式:首先同时用 RT/RC 两套排序算法进行排序,记录对应的作品顺序;将作者分为实验组和对照组,对于实验组给读者展示的为两个算法的排序融合顺序。

图片

将 RC 为当前所有作者均没有扶持的线上排序方案,RT 中将所有知识类作者提权。将RC 于 RT 的排序结果融合,先将实验组 RT 对应的作者(T1T2)放在 final 分组的对应排序位置上,将对照组的作者根据原先实验无关的次序继续保留。保守起见,小流量时期建议除了实验作品以外,其他作品均按照原先次序填充。若实验已经推全,则全量使用 RT 的结果。

图片

如果实验组和对照组竞争同一个位置怎么办?

根据以上实验设计,如果出现实验组作品和对照组作品竞争同一个位置,最简单的方式是随机选择。这种情况出现的概率很低。

如果实验组和对照组都是 a% 的总流量,假设 a=2,

假设一次推 10 个作品,top10 同时出现实验组和对照组作品的概率计算如上图,约为 3.3%。如果两个算法完全独立,前 10 相同位置出现冲突的概率更低。

​往往改进具有一定的渐进式的,RC 和 RT 关联性很高,冲突性更小。于此同时也可以通过离线测试的方式提前预估冲突的概率。

以上双边实验主要的指标评估可分为以下三类:​

  • 作者侧指标:作品数量,生产作者数,直接从作者侧检验;
  • 报告观看量指标:CTR,EVTR,作者作品曝光提升=读者观看次数提升进行推算;
  • 读者侧指标:读者侧单边实验验证。

图片

方案可能存在其他一些问题:

首先任何的方案都会存在问题。双边市场强的溢出效应很难通过一个解决方案解决所有问题。

目前实验设计的主要问题包括以下几个方面:

(1)首先,保留两套排序从工程侧存在一定成本,若政策激励会更好推进,算法的角度不容易一直保持两套不做融合;

(2)其次,从算法数据的隔离的角度,部分改进来自于数据本身,模型本身存在较大变化,结果排序算法逻辑不再成立。

(3)第三,计算假设 a=2%,如果更多的流量检验小的效果是否可以增加 a 值?随机选择比例混排,使得更大流量冲突可能性更小。最后,双边问题退换为单边来解决,是否可以通过双边可以解决,待后续继续探究。

责任编辑:姜华 来源: DataFunTalk
相关推荐

2015-02-28 10:09:16

JMP汽车制造

2023-12-18 08:44:54

Dragonfly基座引擎引擎框架

2023-01-04 10:24:42

2022-12-27 08:43:18

系统思维设计思维创新

2009-03-18 10:01:15

OracleIASNoClassDefF

2012-04-06 09:45:41

开发

2013-05-29 12:18:42

响应式响应式设计响应式设计流程

2022-12-12 09:46:49

Kubernetes容器

2010-01-13 18:49:54

C++的复杂性

2009-10-30 09:54:52

Internet接入

2009-09-28 10:22:00

CCNA实验考试CCNA

2016-12-02 17:37:51

快手

2010-01-13 15:41:02

C++的复杂

2023-07-17 18:39:27

业务系统架构

2009-12-18 09:18:40

软件开发敏捷开发

2019-01-02 05:55:30

领域驱动软件复杂度

2009-10-19 10:52:48

综合布线市场

2010-03-11 14:35:18

高端交换机

2010-01-27 15:50:23

C++复杂性

2023-06-28 06:33:37

点赞
收藏

51CTO技术栈公众号