关于后端:算法AB实验平台进化历程和挑战

1 AB 平台简介

AB 试验平台这几年在互联网公司失去了越来越宽泛的利用，采纳 AB 试验来评估产品和技术迭代成果也成为支流的业务新性能成果评估形式，数据驱动的文化在这几年失去了不少公司的宽泛的认同，通过数据和指标来阐明产品成果也失去了越来越多的公司的认可和利用。

AB 试验在其中就是一种很常见的产品成果数据评估工具，在各大公司的产品迭代过程中也失去了越来越宽泛的利用。

2 1.0 时代 从无到有

在 AB 试验刚开始的时候，须要解决的问题很简略：

通过某种用户流量分组形式，将不同的用户划分到不同的流量组，在不同的流量组通过控制变量的形式利用不同的产品策略，随后察看两个组的产品成果差异。

这种十分奢侈的试验思路就是最根本的 AB 试验的分流，须要留神的是在过程中须要保障控制变量和稳固的流量比例。

2.1 一个根本 AB 试验实例

一个根本的 AB 试验须要有以下因素：

1. 试验指标和试验假如

a. 试验指标决定到达到什么样的成果试验才算胜利，举个例子，我心愿付款率晋升 5%，这就是指标，其中的试验指标是付款率，做试验之前肯定要有试验指标，没有试验指标没方法确定试验是否胜利，试验指标蕴含指标和变动幅度两个因素。

b. 试验假如是猜测通过管制哪些因素来达到试验指标，比方咱们假如付款按钮的色彩会影响用户的付款志愿进而影响付款率，那这里的试验假如就是付款按钮色彩会影响用户付款志愿。

2. 试验对象
（试验对象是能够用来利用策略的用户或者申请或者其余对象）

a. 试验对象并不是仅仅指用户，用户的每一次申请也能够独自做试验，甚至每一次用户申请的每一个曝光地位都能够看做一个试验流量，这个对象取决于具体的业务。

3. 对照组和实验组
（AB 试验的外围要求是控制变量做成果对照，所以至多有一个或多个对照组策略和试验组策略）

a. 对照组：个别是没有任何策略的组，代表了当初的试验成果。

b. 实验组：个别是利用了新策略的组，代表了新策略的试验成果。

c. 统计效用：在进行实验组和对照组的流量调配的时候要留神，因为咱们的 AB 试验是从整体用户中取一部分进行试验，而后采纳统计学形式进行成果评估，所以无论是实验组还是对照组样本量要满足最根本的统计效用，后续的试验才有意义，而统计效用无奈在试验之后计算，须要咱们在试验进行之前就做短缺的调研。

2.2 算法的 AB1.0 次要性能

1. 通过控制变量的形式进行 AB 分流试验，并通过离线的模仿分流规定提供用户试验分组信息，使得数据分析能够计算试验的指标报表。

2. 买通根本的工程试验链路，能够让算法通过试验配置自主的管制试验流量和试验策略。

2.3 1.0 AB 试验的策略失效流程

在晚期的试验过程有以下链路：

1. 通过配置核心配置约定好的 AB 试验配置信息，线上的服务通过配置核心的变更信息，实时变更试验配置，从下次分流开始利用新的分流策略，同时记录试验日志。

2. 报表计算形式，将试验配置信息同步到 ODPS，第二天用前一天的试验配置对昨天的用户进行从新分流计算，取得昨天的用户试验分流信息（之所以这样是因为试验变更是以天为单位，离线计算能够比拟方面的撑持后续的试验剖析）。

算法和一般业务的 AB 分流因为业务个性起因有较多的需要不同的中央，针对两者区别咱们也进行了一些非凡的算法试验优化设计。具体如下：

晚期的 AB 实验设计解决了根本的试验分流问题也提供了一套配套的试验指标和试验置信度计算计划，撑持了晚期的简略业务能够通过 AB 试验的形式比拟迷信的观测算法模型成果。

3 2.0 时代 从有到全，反对简单业务性能

3.1 新的业务需要

随着公司业务倒退和各个系统迭代优化，用户对于根底的 AB 试验零碎开始衍生出了一些新的，更细化更简单的业务需要，用户也心愿 AB 零碎能够帮忙撑持更高效的试验迭代。

1. 流量饥渴，更丰盛的流量需要：在 1.0 版本的 AB 试验中曾经解决了根本的试验分流和配置的问题，然而因为一个场景中总用户流量无限，可能会有多种业务试验同时进行，理论试验运行时须要在同时运行的试验数量和每个试验的流量大小之间做一个取舍，业务高速倒退期间常常会有用户心愿进步同时运行的试验数量，同时保障每个试验有短缺的流量，于是咱们扩大了原来的试验流量分流模型设计，采纳分层分域的正交的业务试验划分形式来撑持上述的流量需要。

2. 更实时更精确的试验报表：在晚期的试验中通过第二天的配置重算的形式失去前一天的用户试验分组数据，这种办法能够撑持十分微小的用户和试验数量，然而时效性上比拟难以保障。随着业务疾速迭代，算法的实时试验成果监控的需要也逐步减少，离线的试验报表计算反馈须要等到至多 1 天后能力观测，试验反馈周期太长。于是咱们调整了试验分流和报表的计算链路，采纳实时试验日志埋点通过 flink 等实时计算平台实时计算试验成果，这种做法能够实时捕获试验流量的变动状况，对于验证试验分流成果有较大的效率晋升。

3. 简单试验模式：联结实，多集群试验，指定用户试验需要：随着算法工程链路的规范化，业务链路中的一些业务层之间开始进行联结调优试验，催生出了多参数跨层联结试验的需要，须要在分层试验的根底上反对联结参数的失效机制，这在个别的分层实验设计中是很难撑持的。随着工程链路稳定性我的项目的停顿，大部分业务同时都具备多个不同集群，此时又须要 AB 零碎也能够针对不同集群提供同场景不同试验配置的性能撑持。还有随着精细化经营的开展，越来越多的试验只针对更精准的特定用户群能力失效，这给原来的试验分流和试验剖析都带来了不小的需要和挑战。

3.2 更大更通用的分流模型

为了满足更丰盛的流量调配需要，咱们设计了一套比拟灵便通用的试验分流模型，这套模型通过多个公司的业务验证，能够确保在将来较长的一段时间内，充沛撑持咱们所有业务的个各种 AB 试验分流需要。同时依据咱们本人的业务倒退需要，也反对了条件层，自定义分流机制等为更简单业务设计的一些分流机制。

多层正交的试验流量模型

上述的分流模型将一个场景流量分为层和域两种嵌套构造，通过层来隔离不同业务配置，通过域来隔离不同用户群。用户在该模型进行分流的过程采纳从外到内，从上到下的逐渐命中，每一次进入一个业务层都会触发一次选桶逻辑，命中桶当前，读取桶上的配置，如果桶内还有层配置持续顺次命中层，触发外部的选桶逻辑。

该模型能够反对如下次要特点：

1. 分层分域，相互嵌套的流量设计，反对业务域分层的正交流量，每一层都是一个独自的业务，解决流量饥渴问题，同时反对自在的流量域划分，流量域和流量层能够相互嵌套，实现极其灵便的流量划分形式。

2. 每一个流量层采纳 hash 模板 + 流量槽，层内试验通过圈槽的模式决定试验在该层的流量比例，容许算法用户自定义试验分流的规定，反对依据用户的用户特色信息进行分流，同时反对灵便的跨层流量对齐机制。这种形式能够实现极为灵便的分流形式，反对各种对象和分流形式（比方用户分流，申请分流，设施分流，作者分流，按地区分流等）。

3. 反对白名单，容许用户绕开分流机制，指定用户的固定试验链路，用于在线上进行非凡用户的试验验证。

4. 反对条件层，容许合乎某种条件的用户独自进行特定试验，比方只针对新用户进行的试验。

从该模型上线以来，2 年多的工夫内曾经完满撑持了算法 300 多个场景的 AB 流量调配需要，通过了充沛的业务验证，从分流层面解决了许多有非凡需要的分流业务遇到的问题。

具体层中的分流规定如下：

每一个流量层依据层中的分流配置信息和用户信息计算命中的流量槽，而后依据流量槽命中圈选了流量槽的试验，试验通过领有的流量槽数量决定试验流量比例。

3.3 规范试验的工程链路

通过 AB 试验的后盾革新，咱们从新思考并调整了整个试验链路的工程设计，在新的工程设计中，绝对于上一个版本次要有以下几个方面须要改良：

1. 采纳试验分流日志而不是离线的试验配置来计算用户的试验分组信息。

a. 试验日志能够捕捉每一个时刻的用户的试验分流状况，能够较为敏感的捕捉到试验变更的状况。

b. 试验日志可观测性强，用户配置完试验当前能够立即通过日志观测试验的命中状况。

c. 能够在日志中附加更多的试验环境相干信息，做更丰盛的试验剖析，能够简化离线的试验分组计算逻辑。

2. 线上利用减少试验信息的具体埋点信息，埋点分为两局部:

a. 一部分透传给客户端，其中蕴含用户命中的试验信息，称之为 ACM 埋点，客户端在用户进行点击曝光等操作时上报信息中回传服务端下发的 ACM 字段，这样咱们能够通过神策上报的行为日志，分明的晓得每个试验曝光几次，被点击几次, 能够及时失去试验的线上体现，这部分行为日志还能够帮忙咱们实时的计算试验策略成果报表。

b. 另一部分作为利用的后盾日志记录，记录了每一次申请中用户命中的试验相干信息，用于计算试验分组信息。

3. 设计了 AB 试验的后盾操作治理界面，不必再通过手动批改配置核心的配置来进行试验配置。并将试验公布，试验批改，试验配置回滚等性能做成具体的按钮性能，极大地提高了用户的试验操作应用体验。

4. 拆分了试验参数和代码执行链路，形象出了 AB 参数和代码链路运行计划两种概念，将 AB 变成一个弱依赖，升高试验参数配置谬误对线上业务的影响。

Ps: 为什么要同时采纳两种试验信息反馈链路，起因是第一种 ACM 上报的用户试验信息依赖于用户上报, 如果用户遇到利用 crash 或者提早上报，或者网络状况忽然不好，咱们没方法取得未上报的这部分信息，第二种很显著，没方法晓得发放下来的带有试验信息的内容的后续反馈状况。两种链路都没方法齐全的笼罩全副用户，只有互相配合能力残缺的笼罩全量用户，至于为什么采纳离线日志来做试验报表，ACM 来做实时报表纯正是工程效率方面的思考。

ACM 通用埋点规范
为了解决试验的实时成果观测问题，咱们须要想方法将后盾的试验命中标识信息传递给客户端。思考到其余业务场景也会有相似的埋点需要，为了埋点通用性思考，咱们布局了一个算法的埋点规范，次要想简化算法埋点流程和对算法的埋点信息进行对立的治理。

ACM 埋点次要是通过算法与客户端约定一个固定的埋点内容字段 ACM，后端算法在开发时候，通过提供的 SDK 工具，将须要埋点的信息和内容通过 SDK 采纳特定的标准造成一串可辨认的字符串内容，客户端同学对 ACM 这个约定好的字段进行事件（曝光，点击等）上报，后端就能够依据上报的用户行为日志通过实时计算工具疾速的取得某个试验的后续用户反馈信息。

ACM 埋点标准例子：

版本. 业务域. 内容资源类型. 资源位. 试验. 自定义值

• 版本：标记本条 ACM 的遵循的标准版本，不同版本具备不同的解析规定，不便 udf 解析。
• 业务域：业务零碎代称，尽量简短，比方 搜寻 srh。
• 内容资源类型：内容类型或资源，比方 user_10098, cspu_1020,spu_771 等。
• 资源位：广告位，榜单位。
• 试验：资源本次采纳的 AB 试验策略，多个试验用 - 隔开。

• 自定义值：

  • 容许利用方进行扩大的字段，比方 chan_latest-pos_3 代表 channel 为 latest，pos 为 3。
  • 特殊要求：自定义字段中不能呈现 “.”,”-“,”_” 等字段，其余局部无此要求。

埋点示例：

acm: 1.srh.spu_1009.sh.kka3b.10089-1929-100.channel_hot-position_2
acm: 2.srh.spu:1009.sh.kka3b.10089;1929;100.channel:hot;position:2

埋点场景：

request 维度，笼罩所有搜寻和举荐场景

埋点动作：

request 维度

上面是一个带有 acm 信息的后端返回示例：

{
    "code": 200,
    "data": {
        "total": 3730,
        "start": 0,
        "hits": 10,
        "searchId": "161113175619737242413163",
        "searchTime": 0.024447,
        "items":[
            {
                "spuId":"xxx",
                "acm": "1.ms.prd-10092.v1ss.exp-1.kka.12",
            }
        ],
        "facet":[],
        "cache": false
    },
    "requestId": "f2ca7c08693acd54",
    "cost": 0,
    "time": 1611131759
}

3.4 实时的试验指标监控

实时试验指标的计算流程

1. 后盾服务日志试验分流信息须要透传给客户端；

2. 客户端用户行为及时上报；

3. 行为日志被 flink 等实时计算平台及时处理；

4. 制订明确且可计算的实时指标标准。

有了下面四个根底流程，就能够计算实时的试验反馈指标，然而要留神实时的指标计算往往只能反映一段时间的试验趋势变动，在局部简单指标上很难实现准确的试验指标计算，所以个别用来察看试验指标变化趋势，不作为最终决策依据。

实时数据处理链路
买通了数据链路并且在用户的行为日志中蕴含了 ACM 埋点当前，算法就能够基于行为日志，通过 flink 等工具实时算计算用户的各种指标信息。

具体的监控链路流程如下图绿色链路所示：

具体实时试验监控成果
最终能够达到秒级的试验成果反馈，极大的放慢了算法对试验策略的反馈效率，具体成果如下图，用户能够本人抉择关注的试验信息比照不同试验在同一时间区间内的指标变动状况。能够十分迅速的失去线上的新试验的成果反馈信息，极大地缩短了算法对试验指标的策略调整反馈周期。

4 3.0 时代 从全到优，晋升用户体验和试验效率

2.0 时代次要是从各种机制和性能方面尽量满足业务须要，业务性能满足当前，咱们进行了业务与扩大，将算法的举荐业务场景也囊括进来，举荐业务接入当前，尽管在基本功能上也能够满足需要，然而举荐和搜寻的业务特点还是有点不同，于是咱们针对试验平台的试验操作用户体验和稳定性方面进行了较多的优化。

4.1 试验操作易用性的建设

业务场景铺开当前，应用的业务团队和人员也变得更为简单，于是咱们在针对特定场景的应用和业务人员应用习惯方面做了不少的性能改良和优化。依据咱们收集的算法人员的参数配置，白名单配置，流量调整等性能应用痛点，咱们进行了针对性的优化。

试验参数的易用性工具
试验参数配置是 AB 试验的最次要的性能，为了优化用户体验在试验参数应用方面的体验，咱们收集了一些常见的用户在应用参数配置时候常常遇到的问题，并针对性做了性能和体验的优化。

场景 1：随着业务倒退，算法配置的业务层越来越多，因为约定的参数标准是同一层的可配置试验参数应该统一，同一个试验参数配置也应该呈现在同一层，然而随着层数增多和局部参数应用不标准，估算某个试验参数的理论失效流量就变得很艰难（参数有后笼罩后面的规定）。有可能呈现你给 a 试验配置了 10% 流量的 recallSize = 20 然而后续该参数被他人的同名参数笼罩导致理论参数失效流量不合乎预期的状况。

参数流量着色剖析：应用参数流量的着色剖析能够分明的晓得某个试验参数都在哪些试验中有配置，这些试验如果同属于一个业务层则无流量笼罩，如果有些试验不属于同一个业务层，有可能呈现参数笼罩的状况。流量着色就是通过程序，一键计算某个参数最终的流量后果散布状况，能够不便的看到某个参数最终的线上实在流量比例。

蕴含某参数配置的所有试验查问：

某参数的理论失效流量散布：

场景 2：试验参数越来越简单，同一个参数往往有多个不同的版本须要同时观测试验的成果，这种时候可能因为工夫长远或者试验变更频繁，或者参数过多，很多时候在进行试验观测和调整的时候须要确认试验中的参数配置信息，顺便为这些须要比照参数的场景制作了便捷的试验参数比照的性能。

试验参数比照：能够比拟清晰的比照同一个试验参数在同一层其余试验中别离是什么值，能够大幅度提高试验流量调整期间须要进行的试验信息核查工作效率。

试验布局的操作和展现优化

为了满足灵便的试验流量划分，咱们设计了一套通用的试验流量模型，然而该流量模型的可视化方面始终是一个不小的难题，最根本的咱们心愿能直观的展现层与层，层与桶（用户域）之间的布局构造和用户流量的命中程序关系。

咱们进行了一些更能直观体现试验布局的摸索，目前咱们采纳一个规范的树状构造来示意个试验分流模型。试验模型中的业务层和用户桶咱们都会用图标进行辨别，因为层桶构造能够嵌套屡次，咱们通过将构造关系进行拆分，将桶页面主视图和层页面主视图进行了别离设计。

• 层页面主视图：能够便捷的察看到以后层内的不同流量桶和子桶内的其余子业务层，次要是用于寻找本人的业务层位于某一个用户桶内，察看某些桶的流量比例和参数等。子业务层内的流量桶信息不予显示。
• 桶页面主视图：桶页面的主视图能够同时察看到该桶内的各个子业务层和业务层外部的子试验桶信息，能够用来直观的对照具体的试验命中链路从上往下核查试验命中门路。

界面显示如下（测试数据）：

通过将层桶构造进行次要的性能拆分，能够在简单场景的视图布局清晰度和易用性上达到一个比拟好的均衡。

试验信息的欠缺

算法的试验在进行试验剖析报表的时候往往须要比照多个指标综合察看试验成果，之前都是算法人员跟剖析人工对齐某个试验什么时候开始什么时候完结，须要察看哪些指标等信息。为了不便后续自动化的进行试验成果剖析，咱们欠缺了试验的试验时长，外围指标，辅助指标等性能，不便用户进行试验的剖析信息管理，后续通过自动化性能依赖这种信息能够实现试验报表指标流程的自动化计算。

4.2 服务稳定性的改良

1. 动静白名单性能优化

白名单操作是一个应用频次较高的 AB 试验操作性能，试验参数配置好当前往往须要通过白名单来小范畴的验证策略成果。然而晚期的白名单设计时候思考到白名单会影响用户的分流，所以白名单信息和试验布局配置信息一起被用户感知，这也导致每一次的白名单变更都须要从新公布试验配置，给线上的配置稳定性造成了威逼。

解决方案：

基于白名单的设计和失效流程，咱们尝试通过流程和配置格局改良优化，使得白名单的配置能够实时失效同时又不影响原来的试验配置，如下图所示：

动静白名单性能改变相当于将白名单的配置信息独立进去，在白名单有批改的时候独立加载，同时不触发配置信息自身的更新。然而思考到兼容性问题，咱们每次配置信息改变也会额定触发白名单的从新更新，形容配置更新相当于一次全量更新，配置和白名单都会更新。白名单更新相当于实时只更新新增的白名单信息。

2. 并发操作 Ark 公布试验的优化

因为 AB 试验的配置下发形式是通过 Ark 配置核心提供的配置告诉性能实现的，目前后盾操作 Ark 进行配置公布的时候是通过 http 接口进行了，应用接口同时操作同一个 Ark 配置集的时候，大量操作容易产生并发，并发问题会导致 Ark 操作间接失败，这种状况极大地妨碍了试验配置公布过程的流畅性。

解决的方法有如下计划：

通过认真评估和计划抉择，咱们决定计划 2,3,4 同步进行，最终齐全解决了试验操作时候的并发问题。

4.3 试验成果剖析的摸索和优化

在过来 2 年的 AB 试验的实际和改良过程中，咱们也非常重视试验成果方面的剖析和问题归因，依据遇到的理论试验剖析问题和状况，总结了一部分常见的试验剖析相干教训文档，其中波及试验流程标准化，试验指标选取，试验指标的统计效用剖析，试验指标的 p 值和置信度剖析，以及常见的试验中遇到的问题等。

常见的试验剖析问题
咱们总结了一些试验成果剖析中常见的问题和可能的起因，能够帮忙排查 AB 试验中遇到的常见问题。具体如下表：

试验中的辛普森悖论
辛普森悖论（英语：Simpson’s paradox），是概率和统计中的一种景象，其中趋势呈现在几组数据中，但当这些组被合并后趋势隐没或反转。这个后果在社会科学和医学迷信统计中常常遇到，当频率数据被不恰当地给出因果解释时尤其成问题。当烦扰变量和因果关系在统计建模中失去适当解决时，这个悖论就能够失去解决。辛普森悖论已被用来阐明统计误用可能产生的误导性后果。
落实到咱们的 AB 试验中就是 如果一个试验 A 在一个较长的试验周期内每天指标都高于试验 B，试验 A 的整体周期指标未必高于试验 B。

本图想阐明一个问题，如果一个试验周期跨很多天，每天观测试验成果的状况下，如果某个实验组用户数量（或者某个指标）长期每天稳固高于另一个实验组，不能阐明分流不平均。

第一天 因为刚刚从新分流，所以所有用户对试验来说都是新用户，a 组 505 万，b 组 495 万，1% 的失常误差。

第二天 因为老用户要放弃分流统一，组内用户 = 新用户 + 次留老用户，新用户会从新分组，老用户沿用之前的分组，此时有两种状况：

状况 1（正当）老用户按原来的分流，新用户分流误差 1%。

状况 2（不合理）老用户按原来的分流，新用户必须要保障误差 2%，能力逆转第二天的分组误差状况，然而此种状况下第二天的新老用户比例会重大不平均，同时没方法放弃分流策略的一致性，实践上不可能实现。

5 将来改良的方向

将来咱们会心愿借助数仓部门的 AB 平台的指标计算和可视化通用能力，心愿能够逐渐加强 AB 平台的数据可视化能力，在试验分流状况的可视化剖析，试验的用户特色的散布可视化剖析，试验的指标变动起因排查等方面与剖析同学一起单干，晋升 AB 试验的指标报表问题剖析效率。

在 AB 试验平台自身的试验信息操作和性能，稳定性方面咱们也有一些新的想法，心愿未来能够买通开发环境，测试环境，生产环境，实现一个界面能够跨环境操作，升高算法同学应用不同环境 AB 须要在不同零碎切换的问题，同时在未来还心愿借助 sidecard 的模式加强 AB 试验的分流能力和分流稳定性，兼顾分流性能和分流平台性能迭代效率。

* 文 / 开阳

本文属得物技术原创，更多精彩文章请看：得物技术官网

未经得物技术许可严禁转载，否则依法追究法律责任！