大家应该都了解最近被讨论的热火朝天甚至有些过气的相亲节目“非诚勿扰”。这个节目让我们看到人性的差别，增加了我们茶余饭后的话题，也让我们了解到现在找对象是多么困难的一件事：24名佳丽争抢一位男嘉宾。经过一段时间的观看，我们甚至可以从技术的角度去分析这个节目成功的原因。
在“非诚勿扰”中，策划们为这个节目做了很多设计，首先定义了若干角色“24名女佳丽，一名男嘉宾，一名主持，还有两个评委”。还设计了一个完整的流程，男嘉宾一开始对印象最好的女生投票，接着通过三段视频资料与女嘉宾们交流，女嘉宾通过按钮进行投票。场下的两位评委用他们专业的知识，影响整个投票的过程。整个节目策划，设计流程及逻辑无可挑剔。其背后的设计思想，竟然和淘宝算法的测试系统（我们称之为BTS系统）有异曲同工之妙。
现在让我们看看淘宝的BTS系统，淘宝的任何一次算法调整都不是拍脑袋决定的，我们把这个决定权交给用户。淘宝的工程师们为此设计了一套算法评估系统帮助用户对我们的算法进行投票，投票的结果帮助我们了解那种算法最有利于改善用户体验。在设计上，通常是取得用户在cookie中的ID，或相关能代表用户唯一标识的数据，进行求余处理，把他们平均分为N份，一般这个值的取值范围需要考虑到流量的需要，保证每份流量的大小足够有统计的意义。每个用户因此被贴上了处理后的标签。不同标签的用户会被分配到不同的算法。用户在算法中产生的不同行为将会被数据平台记录下来，产生用于分析的报表。算法工程师会根据报表的不同表现进一步调整算法。整个体系结构如下图：
上面的系统结构图相当的技术化和枯燥，我们是怎么看出它们的相似之处呢？BTS系统中不同的算法相当于非诚勿扰的24个不同佳丽，用户的选择就像是我们的男嘉宾。而评委呢？他们就是我们的算法工程师，在必要的时候会做出一些调整影响互相之间的表现。流程基本相同，就是不同的男嘉宾（用户）对场上的24个女嘉宾（算法）进行沟通，体验不同女嘉宾之间的差别，经过不同男嘉宾的沟通，让我们了解到场上的女嘉宾那位是最符合目前主流的价值观（也就是我们认为对用户最好的算法）。当然，结果上还是稍微有不同，被认可并带走的每一位女嘉宾，都是凭着心里的感觉。而淘宝算法的每一次改变，背后都需要大量用户数据的支持和对比分析。
实际上，“非诚勿扰”并非完全没有数学分析。这个节目就出现过一位“数据帝”，统计分析了节目开播以来所有出现的内容，以指导他上场择偶的成功率。例如下面两个统计图，统计数据表明该节目的牵手成功率比想象的高64%的成功率，但两情相悦的比例比较低，只有9%。看，数据的分析真的是无处不在，甚至关系到每个人的终身幸福。
由此可见，BTS系统其实和“非常勿扰”的相亲流程是这么的一致。不过BTS能做到的可不只这些。在非诚勿扰中，每个佳丽都有自己的性格，外表和兴趣爱好。这意味着很难找到完全满意天作之合的情侣，这个概率在节目里面只有2%。BTS系统却能完美的解决这些问题，我们可以让算法自由组合，找出一个用户最满意的算法模型。
桶测试的原理看似非常简单,说白了就是目前非常流行的A/B TEST的扩展。然而这个系统要做的好，细节远不止这些。有大量的工作值得我们去研究和完善。
我们需要考虑这个系统的配置效率。每一天淘宝都有大量的算法在线上做测试，配置系统的效率变得非常关键。淘宝的搜索是非常庞大的一套系统，各种形式的算法分散在不同的系统当中。假设每一次的算法测试都需要对不同的系统进行修改，将会导致效率底下，而且极易出错。因此，我们需要对配置进行集中的管理，其目的是为了所有的配置在一个地方修改就能改变整个系统的测试。需要一个多纬度的数据分析支撑系统。每个算法都有可能基于不同目的进行测试，因此数据的分析和统计的能力就变得异常重要。算法的测试往往在几天内就必须完成，对于数据分析系统的要求必须能快速配置而不需要对数据的分析进行二次开发。流量的大小及流量的稳定性。我们必须保证用户被平均分配到每个桶，每个用户群的行为没有太大的差异性。整个系统需要保证每个桶的流量足够大，数据的丰富程度具备统计意义。桶与桶之间的数据表现稳定。对于算法人员需要有足够的数据挖掘经验，能在数据的微小差别中找到算法调整的线索。淘宝在BTS系统上注入了大量的时间和精力去完善，然而A/B Testing的精髓并不在于如何构建一套测试系统，而是如何去获取用户的行为数据，以及对大量的数据进行分析。我们的算法工程师是怎样通过数据的细节找到那个算法更适合用户的需要呢？更吸引人的细节，请听下回分解。