推荐系统AB实验平台
A/B实验平台的目的
提供一个实验平台，可以方便的使用控制变量的手段同时进行多种功能改进的效果对比实验
对比一个功能上线后的效果如何需要做用户对比实验， 在此过程中需要严格的控制变量。但是有时候我们可能希望同时实验多种不同维度的功能改进的效果，以此快速验证功能效果，提高产品迭代效率，这个时候就需要一个能提供多功能对比实验的AB实验平台。
ab实验实际场景举例
假设我们现在有一个支付服务， 我们设计了红/蓝两种付款按钮，并且支持信用卡和支付宝两种支付方式。我们想通过实验看看哪种颜色的付款按钮付款率更高，还想看看哪种付款方式的付款率更高。
此时我们就构成了2个实验，实验1: 针对付款按钮颜色的实验。实验2:针对付款方式的实验。
其中的红按钮，蓝按钮就是实验策略。针对颜色的实验和针对付款方式的实验就是实验层。最终所有用户会分不到四个实验结果中。分别是【红按钮信用卡，红按钮支付宝，蓝按钮信用卡，蓝按钮支付宝】。其中的 “红按钮信用卡”就是某一种实验号。
将来我们验证不同版本实验的效果， 就需要通过实验号流量进行统计。
实验平台的接口设计
分层实验流量模型
ab实验平台接入
相关概念
实验：实验是指对某一个具体功能的一整套对比方案。对于一般的功能只有两个可选项，就是开启功能，关闭功能。部分功能可能具有多种不同的状态。
实验策略：用于表示实验中的某一个具体的选择。同一层实验策略之间互斥。
实验层：这个用于实现不同层的实验叠加，目的是充分利用用户流量来进行功能实验。
实验号：用户最终拿到的最终的实验策略的集合
接口设计和代码
ab实验本质上是需要实现一个接口
1 | def get_user_abtest(userid: User) -> HitPath |
用户实验
我们会根据当前需要进行的实验进行实验分层和隔离，层数和每层的正在执行的实验组会为每个用户分配一个实验号。实验需要有版本设计，每个版本的实验，同一个用户只能获得一个实验号，实验版本更新，用户的实验号随之重新分配。
实验号的本质是获取一个多维的当前实验配置集合
例如图中的 A1-B3-C2 就代表一个同时参与了A1，B3，C2三个实验的用户
多实验部署
当我们想进行一个新的实验时，只需在对应的实验层增加一种配置。同时发布更新实验版本即可。系统会自动对所有用户进行重新的实验号分配，分配完成后，用户的下次请求即可应用新的实验配置。
ps: 用户的实验号分配原则可以采用根据用户请求实时计算的方法也可以提前分配好实验流量，两者各有好处
多实验效果回收和评估
用户使用的实验号和版本信息会随着请求返回客户端，由客户端进行收集埋点。
如果需要对比某实验的结果，我们只需要根据用户的实验号，做控制变量的反馈效果对比即可。
比如上图中我们对比策略层的实验效果，就需要对比所有xx-xx-C1和xx-xx-C2两类实验号中的数据效果。 为了防止其他变量的影响我们可以更详细的对比A2-B1-C1和 A2-B2-C2这两个实验号中的用户的实验结果
再如例子中，我们想对比不同颜色按钮的效果就可以拿 所有红色按钮的实验号结果集 和所有的蓝色实验号结果集进行对比
嵌套分层模型
其实从ab系统本身来说，还有一种更通用更强大但是也更复杂的实验流量分流模型，可以满足几乎所有的分流实验需求。就是具有嵌套结构的分流模型
不过这种形式的ab系统往往因为配置复杂，流量太过分散，实际生产中使用较少。读者可以仅作了解
ps:虽然看上去复杂但是实际上嵌套的分流模型在工程和代码实现上反而更为简单
分流模型设计
模型设计要求
嵌套模型中只有层和桶两种流量块形式，桶用来做用户流量的隔离(垂直切割)，层用来做业务逻辑隔离(水平隔离)。 需要对比的，流量互斥的具体实验应该放到同一层下不同的桶中
组织流量模型的时候，层与桶要合理设计并且交替出现，不能出现层里面有层，或者桶里面有桶的情况
不允许跨层进行实验，跨层实验需求可以变相的通过增加分桶来满足
ab实验架构设计
- 整套ab实验的最终目的是使用量化的手段来分析不同策略的效果，所以实验的最终效果分析十分重要
- ab系统本身应该包含完整的实验发放，实验执行，实验效果回收等一些列流程
- 整套ab实验系统涉及到服务端，前端，数据仓库，后台等多个系统
总结
用户的ab实验本质上是一个分层的动态配置平台， 用户根据不同的配置执行不同的策略。然后对数据进行收集分析。比较值得注意的是，ab实验平台应作为一个纯粹的实验配置分发平台，不应该耦合任何的业务逻辑，所有业务逻辑应该能通过实验配置进行自定义控制