A/B 测试正在消亡，而我为此而生。对一小组干预措施（有时只有一种干预措施）进行离散的、有时限的评估并不能始终如一地产生持久可行的结果。 在任何现实世界的业务情况下，要测试的事物的数量会很快变得不堪重负——如果您使用的是 A/B 测试框架。不堪重负是测试方法的局限性，而不是测试环境的特性。 您可以测试的东西太多了。 。您必须小心，不同的测试不会在它们影响的用户中重叠。您必须避开企业不愿意参与测试的日期和地点。它垄断了大量资源来运行 A/B 测试。 运行一个测试可能需要很长时间，运行大量测试可能需要很长时间 ——如果你将 A 与 B 进行一个月的比较，发现 A 的表现要好得多，这意味着你向一半的用户展示了整整一个月的低性能变体。你失去了所有的价值。没有人对此感到高兴。 一项测试可能会牺牲对失败变体的很多影响 你做出的任何选择的影响都可能受到一天中的时间、星期几、一个月中的时间、一年中的时间、世界事件、市场变化的影响——仅仅因为在你测试它的那个月 A 比 B 好，并不意味着它会永远更好。并且没有任何 A/B 测试可以告诉您其结果的保质期。 测试的长期有效性永远不确定。 如果您想更深入地讨论 A/B 测试的问题，[Babbel]（https://Run tons of experiments at the same time using an adaptive control group）的人有一个很好的介绍这个主题，以及 是来自几个行业领导者的一个很好的观点。 这个关于 bandit 反馈的教程 https://www.youtube.com/watch?v=NevkPmpkEyw&embedable=true 多臂土匪是未来，未来就是现在，现在我们有新的问题。 在传统的 A/B 测试设置中，您有变体 A 和变体 B。在大多数现实世界的情况下，A 或 B 仅在统计意义上“更好”。 如果您进行测试并且 A 获得 20% 的成功率而 B 获得 10% 的成功率，那么 A 显然“获胜”……但是响应 B 的人呢？他们会接受获得 A 吗？ A/B 测试和强盗算法都会迫使您为了大多数人而牺牲少数人的偏好。不一定 那样——这就是那些特定乐器的工作方式。更好的策略是将选项 A 提供给喜欢选项 A 的人，将选项 B 提供给响应选项 B 的人。因此： 非要 将选项 A 发送给 100 人，将选项 B 发送给 100 人。 选项 A 的 20% 成功率意味着你获得了 20 次成功。 选项 B 的 10% 成功率意味着你获得了 10 次成功。 让我们大方一点，假设在回答选项 B 的人中有一半实际上会回答选项 A，如果他们看到的话。 这意味着： 测试完成后仅显示选项 A 的成功率为 12.5%（回答 A 的 20 人，加上回答 B 但本应回答 A 的 5 人，除以两组的总人数 200 人）。 将选项 A 发送给想要 A 的人，将 B 发送给想要 B 的人，成功率为 15%。 因此，通过根据基础结果调整部署每种治疗的方式，您可以减少桌面上的价值。这就是老虎机算法所做的一切——它对冲赌注：B 的成功率是 A 的一半，所以你实际上有一半的时间显示 B。您可以同时使用许多不同的选项（不仅仅是 A 和 B）来执行此操作，自动部署和重新调整可以降低运行测试的成本，您不会因为丢失变体而牺牲太多价值，并且系统可以适应用户偏好的变化或更大的决策环境。 A/B测试的所有问题都解决了！ 但这可能适得其反。 你打算多久向喜欢 A 的人展示 B，或向喜欢 B 的人展示 A，因为你的决定是基于总体统计数据而不是个人偏好？实际上，在这些情况下，强盗算法的性能可能比 A/B 测试差。而且，当然，所有这些事情都会随着时间而改变。也许喜欢 B 的人中有一半实际上会随着时间的推移而转为喜欢 A。而喜欢 A 的人中有四分之一会随着时间的推移而转为喜欢 B。 , 将保持完全相同。那不是最优的。 常规强盗 会带来隐藏成本——或者更确切地说，它们会将 A/B 测试的成本转移到不同的地方，因此您不会轻易注意到它。您设置了算法并开始发送，一切看起来都很棒……直到您开始意识到我在前几段中提到的一些问题。也许 A 和 B 的偏好平衡对于新用户和老用户来说是不同的。也许这些偏好对于不同的地理位置是不同的。也许即使是有经验的用户也可以分为超级用户和普通用户。这就是为什么人们发明了 ，这实际上只是 bandits 加上分割的一个花哨的词。 算法 contextual bandits 现在你必须做更多的报告来了解你的用户群的哪些部分可能有不同的偏好配置文件。因此，您减少了分析实验所需的报告，但增加了确定老虎机范围所需的报告。而且您已经增加了将报告转化为实际范围界定所需的工作量。一旦你有了这些不同的部分，你就会意识到你可能需要更多的创意来考虑这些背景，所以这需要更多的工作。然后是构建管道的工程工作，这些管道将使正确的用户进入正确的 bandit。您需要在消息传递系统中做一些工作，以确保它支持在后台进行的所有这些工作。 所以 bandits 解决了 A/B 测试的很多问题，但真正有效的 bandits 会产生新的分析需求和新的后勤障碍，这些都不容易解决。这就是 A/B 测试仍然如此受欢迎的原因之一：这个过程很常见，有很多工具可以帮助完成繁重的工作。 动态测试需要动态评价，动态评价需要动态控制组。 因此，我帮助设计和构建了一个产品，该产品使复杂的上下文强盗测试变得简单——非常简单，以至于它可以为您网站或应用程序上的每个用户创建单独的上下文。您可以 找到有关该产品的更多详细信息，这不是本文的重点，所以我不会再谈了。这里我想说的是，我们是如何解决每天几十万个个性化自适应测试的评估问题的。 在此处 详细信息可以在 中找到。 我们关于 arXiv 的论文 我 关于构建坚持小组以评估实验所固有的实际、分析，有时甚至是伦理方面的挑战。我仍然坚持这一点。我们使用 来评估我们的适应性实验，因为这不涉及剥夺任何用户可能有益的干预措施。然而，传统的综合控制方法可能充满分析缺陷，因为您实际上是在为您进行实验的环境建模基线数据生成过程。投入大量平行实验，其中许多实验发生在重叠环境中，控制问题的分析解决方案变得……令人生畏。 之前写过 综合控制 这就是我们没有走那条路的原因。 几年前，加里·金 (Gary King) 和他在哈佛的同事提出了一种非常简单的方法，可以从观察数据中得出因果推论。它称为粗化精确匹配 (CEM)。您可以 找到开创性论文， 找到理论基础。 在此处 在此处 这个想法很简单： 收集您对正在进行的干预（测试）的所有观察。 收集一堆没有发生但可能发生干预的观察结果。 选择可以衡量两组中任何特定观察对之间相似性的属性。 “粗化”属性为分类变量。因此，如果“年龄”是一个属性，您可以将其分类为年龄类别。 基于粗化属性的精确匹配，将每个干预观察与非干预观察相匹配。这意味着您将只选择非干预观察的一个子集，并且通常您最终也会放弃一些干预观察，但您剩下的将被匹配。 对两个优化组之间的差异进行建模。 CEM 将因果推理的复杂性从分析方法中移开——您可以使用您喜欢的任何方法——并将其置于数据集创建方法中。从概念上讲，它类似于在分类问题中对不平衡数据集进行过采样或欠采样。 我们意识到，我们可以使用相同类型的逻辑通过将时间作为要匹配的特征之一来为我们的强盗实验找到合适的控制上下文。我们已经匹配了某些干预属性——用户收到的干预类型和用户在干预时在应用程序上表现出的活动水平。但随后我们还定义了一个观察窗口，并确保任何匹配的用户都将在接近我们正在寻求控制的干预的时间段内接受干预，但不在干预本身的观察期内。 这使我们能够为我们运行的大多数测试在用户级别匹配控件。 Bandit 算法摆脱了大规模 A/B 测试的一些复杂性，但隐藏了该复杂性的其他部分。我们的控制方法采用了隐藏的复杂性并对其进行了解决，因此我们可以获得强盗分配的自适应优势，以及 A/B 测试的清晰推理和归因。 所以这是你的待办事项清单： 对于你所做的每一次干预，确定一个前瞻性和后视窗口。前瞻窗口是您用来查看用户如何响应干预的窗口，后视窗口是您寻找控制案例的地方。 对于每个干预措施，确定一组其他干预措施，这些措施 (1) 发生在后视窗口内，并且 (2) 没有与您正在寻找的干预措施的前瞻窗口重叠的前瞻窗口一个控件。 将接受这些潜在控制干预的用户与接受您正在寻求控制的干预的用户相匹配。您可以根据您想要的任何标准进行匹配 - 活动水平、收到的干预的相似性等。 从通过匹配过程的用户中随机选择一名用户。 假设您不仅将原始干预发送给实际收到它的用户，而且还发送给了您选择作为控件的用户。 在您感兴趣的任何时间段内，测量测试用户和控制用户之间的响应差异。 同样，您可以在有关 论文中找到更多信息。 arXiv 的
