Fork me on GitHub

火山引擎 A/B 测试平台设计思路与技术实现

导读: 大家思考一下,想要获得一个 A/B 实验系统,需要做些什么事情?火山引擎团队会把这些事情分成四个部分。A/B 实验需要通过人群采样,分出对照组和实验组并且下发不同的配置,让用户体会到不同的策略。因此从实践角度来看,四个部分中首先得有一个可靠的实验系统。通过这个实验系统,我们可以采集数据,从而观测用户在不同的策略下的反应。考虑到业务的迭代过程需要保持高效性,因此系统在第二步需要高效的数据建设。当采集到数据之后,我们还需要借助统计学知识,对各组的结果进行分析,以得到正确的实验结论,这第三步被称为科学的统计分析。有了以上三步,我们离一个完整的实验系统还有最后一步。我们考虑实验平台具有一定的成本,测试人员有可能会犯错误,平台运行也可能会出现异常……这些问题都需要系统通过最后一步——精细的治理和运维,来保证实验始终正常运行。

今天的介绍会围绕下面五点展开:

  • A/B 实验系统平台概览
  • 灵活的执行组件
  • 高效的数据建设
  • 科学的统计分析
  • 精细的治理运维

分享嘉宾| 王珂 火山引擎 A/B测试研发工程师
编辑整理|陆观
出品社区|DataFun


01 A/B 实验系统平台概览

在本文中,我们将详细讲解火山引擎 A/B 实验系统平台背后的四个部分。

首先,我们对平台进行一个整体介绍。俗话说,“皮之不存,毛将焉附”,可靠的实验系统是整个平台最基础的一个部分。图1-1展示的是火山引擎实验平台所具备的能力图谱。 一个实验平台的最核心点是对于业务场景的支持。 在字节跳动这家公司里,我们在对内对外都拥有比较广泛的业务场景,比如:推荐、搜索、广告、电商、直播、运营以及推送等一系列业务。不同的场景对产品提出了不同的功能要求,这也推动着实验平台去解决业务场景上所带来的新问题,并且不断地往前迭代。

图片

图1-1火山引擎实验平台的能力图谱

围绕着这个核心问题,我们 需要三个基础环节的帮助 ,也就是黄色框中的三个长方形。

  • 第一个是执行组件,一个实验进行时,首先需要将准确的配置定向下发给准确的用户,也就是做好流量的配置发布。
  • 第二个环节是数据建设,通俗来讲就是我们得将数据采集上来。
  • 第三个是显著性计算环节,当采集完数据之后,实验组与对照组之间产生的差距是否代表新策略会带来收益,会依赖于相关统计指标的计算。

以上三点是平台最基础的能力,围绕着这个实验平台,我们还需要四个紫色框中的辅助功能。

  • 首先,实验平台本身就具有定向的配置发布能力。在完成一个实验之后,下一步的抉择一般就是将策略废弃或者上线,对接一个完整的配置发布平台,是一个实验必要的后向延续。
  • 下一个部分,探索实验室是针对实验无法处理的评估场景,研究怎么样辅助去做一些决策。在探索实验室里面,我们往往会尝试一些非 AB 实验的东西,比如人工合成对照组,对于一些只能将用户分在实验组中的策略,我们可以通过人工合成的方式,给构建出一个对照组进行实验,比较策略的效果。在决策分析部分,我们之前提到的显著性计算,只是分析过程中的一部分。
  • 除此之外,我们可能还要分析更多东西,比如策略的功效是否足够,是否需要继续提升;比如实验有没有比较严重的首因效应,用户是真正喜欢这个策略,还是因为策略看起来比较新鲜,所以大家多点击了一下。这样一些分析虽然不在显著性分析的范畴里面,但是对于实验的角色分析而言同样非常重要,是决策分析的一个部分。决策分析可以用数据和事实去说话,为业务提供决策的辅助。
  • 最后一个重要的功能是智慧决策。例如,我们在一个典型的推荐场景里面,想通过调整参数来获得收益,可能需要不断尝试新一轮实验来获得比较好的参数。这种方式虽然可行,但是非常耗时。于是,我们想要通过自动调参的方式,根据每次实验所拿到的数据进行一些分析,去选择下一次的实验点位,从而大幅度提升决策的效率。

除了以上提到的几项以外,我们还需要一些别的功能。白色圆圈中指出了迭代控制、需求管理、健康监控、精准熔断四项。所有的组件聚合在一起,就构成了一个可以比较完整的实验平台。

02 灵活的执行组件

平台的第一部分,我们来详细讲解一下执行组件。说到执行组件,我们经常会提及到一个词——分流。所谓分流就是随机采样一部分用户来做实验,然后随机分配一半的用户进对照组,一半的用户进实验组。之后,平台将会对照组的用户下发配置A,实验组的用户下发配置B。这一整套流程实际上就是所谓的分流组件,业界通常会有四种不同的接入方式,对应图2-1中的四个框。

图片

图2-1 业界分流的四种接入方式

最常见的两种分流方式是 RPC 和 SDK 。字节跳动在对内的场景里面比较多地使用 RPC。这种方式的好处是接入简单,并且足够灵活,而且对于平台来说比较可控。我们只需要发一个 RPC 调用,就可以知道用户命中的实验以及发布的配置等信息。每当分流组件需要有功能的升级时,只需要升级该功能自己的服务即可。那与之相对应的还有另外一种方式——SDK。考虑到了调用RPC的服务时的效率问题,SDK 接入直接提供了一个库文件在本地做分流。这种接入方式可以发挥机器的极限性能,经过比较好的优化,SDK 的接入效率一定是最高的。但是与 RPC 相比,SDK很难去避免几个问题。第一,当功能升级的时候,由于升级成本的存在,因此控制性可能会略微弱一点,也就是说我们很难保证所有使用 SDK 接入的业务方,都能够做到很好的升级。另外,业务方可能会使用不同的服务端语言,综合考虑不同服务端的 SDK 时,就需要进行多语言覆盖,这个本质上也是一个限制。

举例来说 ,在推荐系统的一个场景里面,如果需要在三万篇文章里进行召回实验,比如一次性召回五千篇文章。那么 RPC 肯定跑不动这个实验,全部的资源都会去进行 RPC 调用。但是如果用 SDK ,只需要一个 for 循环,就可以完成这个实验。那么,怎么可以结合 RPC 与 SDK 之间的优势呢?这里我们会讲到第三种方式——伴生进程。这种技术方案就是在业务进程的节点上,再添加一个伴生进程,用 C ++ 做封装,然后去做一个 Unix 的 Domain Socket。通过这种方式,网络传输只是在本地本机本节点上去做进程间的一个调用,可以使性能做到很大程度上的提升。同时,我们也可以保证对伴生进程的控制性,当有升级需求的时候,可以一定程度上对他们直接进行升级,而不会影响到业务方的迭代。最后一种是 UDF 分流。这是针对大数据的离线场景下,我们需要用实验去做一些分析和处理,所以会用到离线和流式处理。

这边简单总结一下 火山引擎会更愿意去用 RPC 进行分流的几个理由

  • 第一是从未停止的高速迭代,我们要求对服务有比较强的控制,需要随时去更新它,去迭代它。
  • 第二,多样化的接入场景、功能拼图和服务端技术栈,这些需求会导致在 SDK 这个场景下,成本会略高一些。
  • 第三,我们也有苛刻的性能要求,即使是在 RPC 这样的方式下,我们也会进行大量非常强度的性能优化,以应对苛刻的性能要求。这里提一下,当前我们 RPC 的性能大约优化到了毫秒级的状态。

既然讲到了从未停止的高速迭代,那么,我们的分流到底都在迭代些什么东西呢?图2-2展示了分流的迭代就是围绕着灵活多变的流量复用与隔离展开的。通俗来讲,它是在解决实验与实验之间关系的问题。

图片

图2-2 灵活多变的流量复用与隔离

  • 最简单的实验关系其实就两个:流量的互斥和流量的正交。由于平台侧比较难以在实验开启之前,去界定这两个实验是不是有冲突、需要互斥。如果两个实验会有一些冲突,通常来说业务方在事件设计的时候,就需要知道这两个实验是有冲突的。如果两个实验是互斥的,我们就需要将实验开在同一个实验层上;如果没有互斥,那么实验将开在不同的实验层上,以保持流量的正交。
  • 除此之外,还有互斥域的概念,除了开实验和分实验层这两次基础的哈希,我们会做第三层哈希,以此形成流量层之间的强制隔离。
  • 下一个话题是父子实验。一般来说两个实验之间要么互斥,要么正交,应该没有什么特殊关系。但是,有一类实验会有比较强的血缘关系。比如在进行多轮迭代时,第一轮迭代后,我们发现这个实验组确实挺好,可以对着这个实验组再开一个子实验,这个子实验也有自己的对照组和实验组,然后在这个实验组可以在原实验的基础上,我继续进行迭代。这样,两个实验之间就出现了联系,子实验的流量必须来源于父实验的某一个实验组。
  • 共享对照组这个概念中提到了一个词,叫勤俭节约。有一些场景下,样本实体是用户请求,而每来一个新的请求都是一个新的样本,这个时候做两次哈希是没有太多意义的,我们可以完全让它退化至一次哈希。退化回去之后,我们可以让实验复用同一个对照组,然后让每一个实验都只有实验组。通过这样的方式,在同样的 100% 的流量下可以开启更多的实验。但是,这样的一种实验方式也是有一定的问题的,大家在使用的时候要谨慎。
  • 流量轮转。有一些实验,我们不是想看这个实验的收益,而是确定它就是有害的,只是想看这个实验多有害。但是我们要老针对一群用户进行试验,这对他们的使用体验是有影响的。因此,我们会定期去更新哈希种子,让进实验组的用户定期地进行切换。这样的对用户体验上来说还不错,同时我们又可以看到策略到底有多差的影响。

03 高效的数据建设

第二部分,我们来讲一讲数据建设。“天下武功,唯快不破”,平台的数据建设一定要是够快的。如图3-1所示是数据建设的整个链路图。大家可以看到,整个图分成了两个部分,这是因为数据建设实际上是要解决两个主要问题:

  • 第一个是离线计算,目的是要通过报告判断策略是否能够上线。
  • 第二个是即席查询,这个部分更倾向于对实验多维度即时分析。

图片



图3-1 数据建设的链路图

离线计算的结果是一个看板或者报告,相对比较固化。业务的核心指标在长时间内大概率是不容易发生变化的。但即席查询需要做多个维度的分析,例如链路分析和漏斗分析等。这些分析经常只针对一个实验有效,甚至是实验分析师临时想到的,即时性会比较强。对于这两个问题,我们会用不同的链路去做执行,但基本逻辑都是做累计指标运算。

其实在数据建设中还有第三个需要解决的问题——流失处理 。通常我们需要监控上线的新实验,比如看看三个小时之内,线上的指标的异常情况。如果异常很严重,我们要赶紧关掉实验,并且让相关人员排查不符合预期的原因。

图片

图3-2高效的数据建设

如上所示,图3-2展示了数据建设是如何保证高效性能的:

  • 首先,我们要去做数据管道的建设,来保证指标建设的自动化。
  • 其次,SQL 调优当指标组太多、业务线复杂的时候,不能都让人工去做,也需要自动化进行。
  • 在需求管理方面,专人去对接业务方的效率太低了,自助建设的平台是不可或缺的。
  • 数据管理可以保证数据服务,当我们想查询指标之间的关系时,需要通过数据服务来做灵活查询。
  • 最后,打造一个开放的平台和生态系统,可以让一个试验平台的能力成指数型的增长。

通过上述的自动化和第三方共建,可以在人力、有限的资源的条件下,保证我们的数据建设在高效的状态。

04 科学的统计分析

第三部分我们聊一下科学的统计分析。“今天你显著了吗?”,显著对于一个实验来说还是蛮重要的指标。首先来说一下实验指标微涨时,到底是波动还是策略收益?我们需要通过假设检验来进行验证。图4-1的两个方框展示了对不同业务场景的假设检验方案。

图片

图4-1 不同业务场景的假设检验方案

这里给大家举一个例子:显著性水平在业界通常会定到 5%,实际上与业务场景相关时,大家可以自己进行调整,例如 1% 或者是 10% 其实都是可以的。而对于 5% 的显著性水平,在 100 个实验里面会存在 5 个假阳性情况,当实验变多的时候情况还是蛮严重的。那么,这个时候我们应该怎么办呢?有聪明的人想到了这样一个话题,实验前的数据能不能在假阳性的问题上带来一定收益?在业界来看,实验前的数据应用方式分三种:

  • 第一种是 SeedFinder 以及变体的 PreAA 校验。原理是在采样用户并且分 AB 组的时候,尽量地让 A 组和 B 组之间的误差减小。方法通过衡量两组用户之间的差异,找到差异最小的两组用户进行实际实验。
  • 另一种方法是双重差分。在实验之前,两个组之间本身会存在差异,此时我们选择做一个 A 实验,不应用任何策略,这时用户的指标天然就会有一些差异。我们采用双层插空的方法,可以尽量真实地评估策略带来的收益。
  • 在字节跳动这边,我们采用第三种方法 CUPED。这种方法通过一些统计方法对实验前的数据进行修正,使修正之后的结果依然可以作为实验数据的无偏估计。同时,我们可以对实验前的数据缩减方差。同样的样本量缩减方差之后,原来因为流量不够而检测不出来的收益就可能被检测出来,实验的假阳性率也可以进一步降低。

05 精细的运维制度

最后讲讲第四部分,精细的运维制度。对于实验平台,我们可能要“像对待孩子细心照料”。如果一个实验平台能够在一家公司里面很好地应用起来,必须自上而下让整个公司都拥有数据驱动的理念,如图5-1所示。

图片

图5-1 数据驱动理念

此外,由于平台不是简简单单就可以使用的,我们还 需要丰富的用户教育和文档建设 。同时,我们需要有积极的用户响应,只有这样才能够保证业务可以做到高效迭代。

其次,为了保证系统的可靠性,我们 需要在平台上做监控。 例如,通过 AALayer 的方式,我们可以监控系统的安全和健康情况。同时,平台需要透明的数据口径,让所有人都能看到每一个指标的口径、数据的来源以及链路是什么样子的。

异常检查部分 ,在我们内部有一个代号叫 A/BDoctor 的模块 ,主要负责异常实验检查和异常流量检查。

  • 第一种是 SeedFinder 以及变体的 PreAA 校验。原理是在采样用户并且分 AB 组的时候,尽量地让 A 组和 B 组之间的误差减小。方法通过衡量两组用户之间的差异,找到差异最小的两组用户进行实际实验。
  • 另一种方法是双重差分。在实验之前,两个组之间本身会存在差异,此时我们选择做一个 A 实验,不应用任何策略,这时用户的指标天然就会有一些差异。我们采用双层插空的方法,可以尽量真实地评估策略带来的收益。
  • 在字节跳动这边,我们采用第三种方法 CUPED。这种方法通过一些统计方法对实验前的数据进行修正,使修正之后的结果依然可以作为实验数据的无偏估计。同时,我们可以对实验前的数据缩减方差。同样的样本量缩减方差之后,原来因为流量不够而检测不出来的收益就可能被检测出来,实验的假阳性率也可以进一步降低。

|分享嘉宾|

图片

王珂

火山引擎 A/B测试研发工程师

目前就职于字节跳动数据平台,负责内部 AB 实验平台的研发,支撑内部各个业务线的 AB 实验需求。


本文地址:https://www.6aiq.com/article/1669353680591
本文版权归作者和AIQ共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出