论文

[论文梗概]在线服务的实验评估面临的挑战

论文原文: https://exp-platform.com/Documents/2019-FirstPracticalOnlineControlledExperimentsSummit_SIGKDDExplorations.pdf

概念

OEC: Overall Evaluation Criterion/总体评价标准
OCEs: Online controlled experiments/在线受控实验=A/B Tests

挑战汇总

  1. 如何评估长期效应;
  2. 如何解决社交网络对实验的影响;
  3. 如何解决多次实验间的影响;
  4. 如何寻找OEC指标;
  5. 如何进行细分人群的实验(HTE模型);
  6. 如何确保数据质量、进行数据治理;
  7. 如何建立实验文化;
  8. 如何处理配置文件膨胀问题;

如何评估长期效应

问题

  1. 大部分abtest持续两周内；
  2. 我们真正关心的是比两周更长的长期效应；

如何确保上述两者吻合？

长期效应：常见解决方案

长期实验；

Twitter: 实验通常持续4周，从最后两周的数据开始统计。

保留反向桶；(holdout)

代理指标

Netflix: 使用logistic回归，寻找反映留存指标的代理指标。
LinkedIn: lifetime value模型；
Uber : macro-economic模型;
facebook: 分位数回归、GBDT

缺点: 相关性!=因果关系
可能的歧路：代理指标涨、长期指标不动。

bing/google: 心理学模型,从因果关系出发

对用户学习效应进行建模

google: 用长期实验，观察用户学习的效应(参见原文论文[38])
实验流程:

  1. 第一组：立刻使用B配置;
  2. 第二组：滞后一段时间后使用B配置;
  3. 第N组：依次类推。
  4. 随机组: 随机滞后。

比较不同学习阶段的用户。

结果: 得出指数曲线，预测长期的情况。

如何解决社交网络对实验的影响

问题

传统A/B test的假设： 实验间不相互影响；

假设不成立：

  1. 社交网络影响；
  2. 多次反复实验残留效应影响。
    对照组的用户可能与实验组认识/有交互，因此也受实验影响。

问题：

  1. 如何避免这个问题？（无法避免）
  2. 如何检测这个问题？（评估影响）

常见解决方案

生产者消费者模型

LinkedIn： 生产者消费者模型
实验：
生产者：允许在帖子上打标签;
消费者：允许看到帖子的标签;

当95%的生产者可以打标签：可以测试50%的消费者是否允许看到标签的影响；
当95%的消费者可以看到标签: 可以测试50%的生产者是否打标签的影响。

类似的模型可以用于@功能。

已知影响力模型

Link/facebook/谷歌： 用户影响力已知，将用户聚类成子网络。
实验在各个子网络进行。

相关论文： [20, 26, 9].
[20]:
http://www.unofficialgoogledatascience.com/2018/01/designing-ab-tests-in-collaboration.html

一对一通信

对于1对1通信相关的feature:
Linkin: 数据统计时分为4类:
1.实验组=>实验组;
2.对照组=>对照组;
3.实验组=>对照组;
4.对照组=>实验组;

Skype: 以会话为维度实验。每个用户都可能随机位于实验、对照组。

市场影响

实验结果受供求关系影响。(如打车)
忽视供求关系随机分组，可能会导致一些Bias。
Lyft： 构造小规模近似供求关系的市场，进行实验。

广告领域：预算窃取
实验组：窃取对照组预算(对照组的广告预算也花在了实验组)
当放量时，整体收入并没有达到预期幅度。
解决方案：按预算比例投放到实验组。

挑战：多个实验之间的影响

问题

如果两个实验之间不是完全独立。
(例1个实验改变背景，1个实验改变字体颜色)

解决方案

微软、谷歌：相互影响(互斥)的实验放在同一层内，这一个层由一个团队负责(相关特性)；
微软：每天跑任务检测层间影响；

挑战：如何寻找OEC指标

问题

HiPPO: 工资最高的人说了算。
OEC: 数据驱动，核心指标说了算。

指标=OEC指标+其他护栏、诊断指标;
OEC指标: 决策;(KPI)
诊断指标: OEC指标为啥变化。

解决方案

OEC指标满足的条件

  1. 反映KPI;
  2. 难以作弊;
  3. 必须敏感;
  4. 计算的成本不能太高(可行性)、每天都要给至少上百个实验计算;(不能是只能打电话确认的指标)
  5. 考虑到影响KPI的各种场景;
  6. 能顾及到新的场景。

自己发现OEC

对于搜索引擎: 查询量不是好的OEC，查询量大可能是因为不准。
好的OEC: 每个用户的会话数。（不准的话，单次会话查询量很大、会话数少。）

一般来说：
OEC指标属性:
HEART:

Happiness, Engagement, Adoption, Retention, and Task success

护栏指标：pv、vv、时长、延迟、七日用户数。

对于浏览类场景，找到HEART指标仍是挑战。
挑战：识别用户的目的。
目的1：快速找到特定东西；
目的2：不想找特定东西，只是想探索新东西；

对于目的1：点击次数越多越不好；
对于目的2：点击次数越多越好。
两者矛盾，因此存在挑战。

权衡产品目标

我们潜意识假定产品目标是确定不变的、统一的。
然而这不是小问题。因此假定不一定总是成立。

  1. 团队可能调整战略(例如每个阶段的盈利策略)；
  2. 每个局部的实际方向可能和总体不符。
  3. 多目标(指标)冲突。(收入与体验)

机器学习建立OEC

  1. 基于用户行为，打分预测满意度；
  2. 组合多个指标，创造敏感又准确的OEC指标；

缺点: 不可解释、难以发现误判。

如何进行细分人群的实验

细分人群可能可以有更多洞察。

常见的分类方法

  1. 国家、使用语言；
  2. 活跃度;
  3. 设备和平台；
  4. 周中周末、新奇效应；
  5. 产品特定分类：
    (1)linked: 招聘者、应聘者；
    (2)Netflix: 不同网速；
    (3)Airbnb: 是否曾经预定、渠道来源；

相关挑战和解决方案

  1. 计算规模变大; =>按需分析: 某些需求可以用更高成本的分析方法；
  2. 样本变少; => 使用稀疏模型
  3. 分层的正交性依赖大样本;
  4. 实验者不是统计学专家,实验结果必须明确易懂； =>用回归和聚类来简化结果。(Fused Lasso、Total Variation Regularization)
  5. 相关性!=因果关系: 细分人群的结果不同，但相应分类属性可能不是导致结果不同的原因，可能只是共线。
    解决方案：可以从历史数据中寻求更多信息。

数据质量与数据治理

问题

实验可信度依赖数据质量。如何确保数据质量?

解决方案

工业界测试

工业界测试： Ratio Mismatch test (见原文引用[13, 22, 23, 45])
抽样校验告警。

数据规范

Netflix\MSN\Bing：json
优点：拓展性好；
缺点: 格式变化很快；

Airbnb/facebook：每个实验自己设定格式、打点。(bring-your-own-data)
Microsoft Office: 事件日志；
其他: 固定部分列，预留json列。

及时可靠的指标

不断新增指标对实验平台的挑战。

LinkedIn/Facebook/Airbnb: 实验平台与指标框架分离，各个业务对自己的指标负责。实验平台仅负责从统计结果进行评估。
Microsoft/Google/Booking.com/Lyft:指标由实验团队从日志中统计。

LinkedIn:
指标委员会：批准新增、修改指标，确保指标质量；
某些公司：
指标必须经过验证敏感性、精确性，确定和实验结果有有意义的区别。
Booking.com：
自动检测比较两组独立数据。

指标的ownership

指标通常有特定的关注者和归属者。
微软：特定指标下降=>通知指标归属者(含相关实验信息)。

其他公司：提供工具搜索：影响特定指标的实验。

新分析方法

需要考虑:

  1. 新方法适用场景;
  2. 新方法的计算、复杂性成本 < 收益;
  3. 不同方法冲突时，相信哪一种；
  4. 保证正确解释结果；

如何建立实验文化

日志、实验、实验记录、实验评估的文化。
原则:
谦逊: 直觉判断是贫瘠的(HIPPO)；
微软：只有1/3的创意在数据上有显著结果。

能接受实验效果不好。

解决方案: 建立规范的实验平台。

Booking.com： 将实验平台变得像游戏。

Yandex： 中央实验小组：由各个组的专家组成
Amazon： 类似，酒吧专家；（酒吧是Amazon的实验平台）
Twitter：实验牧羊人：50个牧羊人，一个星期值班时间，
Booking.com： 实验大使制度、同行评议制度（按钮：随机选择一个实验来评议）
微软：1~2个数据科学家跟着一个业务团队。随着业务团队接受培训、能力提高，数据科学家回到中心、转跟另一个业务团队。定期分享。
谷歌： checklist。每次实验填写：假设、指标、变化幅度。

配置文件膨胀的挑战

问题

随着实验越来越多，客户端要拉的配置文件越来越大。

解决方案

定期合代码，固化一些feature;

推荐文章