ABTest实验系统在搜索简单实践

背景：
1、当我们要上一个排序策略，只有这个排序的优化方向，离线指标都是正向的，那么我们有勇气替换掉目前的排序吗？
2、同一个功能点 有两种召回策略 离线评估都不错 上哪个留哪个？
3、调整产品广告位或不同活动位在搜索列表中出现的位置，用对哪种方式是无感可接受的？
等一系列线下只有方向但不能确定的事，我们可以把这类问题交给用户来让他们帮我们做正向的引导，前提是小流量不伤害用户为前提，实现 衡量 - 发现 - 迭代 - 验证 的过程，那么就有了ABTest。

1、ABTest架构
1）ABTest服务，用于读取实验配置信息，如 搜索接口获取搜索层的实验信息。
2）实验配置平台，配置 域/层/实验组 信息。
域：域可能理解为一个流量控制范围，我把域分成大域小域，大域是全局的，大域下面是层，小域是在层下面，例如我要做关于A活动的实验，那么建立一个大域限制条件活动为A，那么所有A活动的流量都会走这个大域，小域可以建立在层中，如想要做搜索层中北京城市的流量做实验，建立小域在层中条件城市为北京，然后在这个域下建立实验分流量。
层：所谓层 实际对接的是你的某个服务接口，如搜索接口或推荐接口，假如要在 搜索接口上会实验需要建立一个搜索层，这个搜索层是全域唯一的，如果一个接口入口有多个层那流量就没法控制了，所以一个接口对接一个层。
实验：实验分为实验组和对照组，一般多个实验组配合一个对照组，也可以成对配置，但感觉比较浪费流量，他们需要在一个层和域下相同条件的组合，在我们的实验配置中也可以配置过滤条件，这个是用户针对某个方向优化或查找问题比较方便。
3）埋点：实验跑起来了需要埋点上报查看实验的结果，埋点信息越详细越好以免后面分析问题时在埋点可能需要前端发版，这个需要等待一段时间，埋点信息最好能覆盖搜索日志，这样避免搜索日志要和埋点数据join了，记得把模型策略ID都带上。

2、分流策略
1）使用MurmurHash做为分桶算法，MurmurHash 是业内 ABTest 常用的一个算法，它可以应用到很多开源项目上。MurmurHash 有两个明显的特点：
1. 快，比安全散列算法快几十倍.
2. 变化足够激烈，对于相似字符串，比如说「abc」和「 abd 」能够均匀散布在哈希环上，主要是用来实现正交和互斥实验的分流。

2）分流策略使用用户设备ID和随机，未登陆用户只有通过设备ID所以统一都用设备ID来做Hash种子，在每层根据Hash算法分为多个桶，使用时按桶分析流量，到下一层后在打散重启分桶，这块就是AB的核心了，不同层流量可公用正交。

3、实验流程
我们的流程比较简单
1、先确定基础指标是否够用，如果不够与产品沟通确认一些优化指标，可能开发埋点和统计报表。
2、做AA实验3-7天，如果无抖动转成要做的实验。

4、指标报表
每天统计实验报表，这个数据在做实验之前就会有的，没有的需要开发补上来，就是统计你做的实验组与对照组的表示是否有提升，提升多少为可上线标准，对大盘指标是否有负向影响。

搜索指标包括：搜索无结果率、搜索曝光率、搜索点击率、TopN点击率、搜索订单转化率、uv关键词频率等。

5、简单ABTest
没有ABTest的朋友想做这些怎么办，说说我们刚开始也是没有AB的，只能用设备ID的尾号来做，用尾号后两做，那么你就有100这渠道可以做实验了，只要管理维护好好分公司唯一，大家用时申请用完换回，还是可以简单做的，但这也会有太多太的问题，尾号生成没有散列开等等问题。

以上只是我们根据google的论文和结合自己的业务开发的，如果有那里概念有奇异的地方讲大家指正，这篇写的有点划水了，多谢大家！

如果喜欢搜索技术请关注我的公众号吧
每天会持续更新搜索相关技术