A/B Testing 杂谈 (2)

A/B Testing 果然是大家喜欢的话题啊哈哈，今天我们继续聊一聊这个 topic。

上次 A/B Testing 杂谈 (1)里聊到了很多我的经历，主要是自己作为 first ML engineer 为了 build 一个理想中的 ML team，把 A/B testing 的大部分 service 都自己做了，非常完美地 scale up 了 ML team 的 A/B testing (至少在我看来啊哈）。结尾聊到了一点点为什么要做 A/B Testing，今天继续这个话题。

我特别喜欢聊 Why，而不是 How & What。因为大家以后都是要当 Founder 当 Business Owner 的，对做决定的人来说：Awareness » Implementation，要做什么 » 怎么做。而且作为甲方爸爸永远可以找 立正 来服务你啊哈哈。就算要自己手搓一堆系统，边做边学没有什么 technical 的东西是学不到的。

那为什么要做 A/B testing 呢？我常在说，你其实没得选。

先退一步说，很多人来找我做 coffee chat 陈然：Full-time Coffee Chatting ;) ，会对我 LinkedIn 上的一个句子很感兴趣：

The only question is: how to scale?

Scalability 是一个很有趣的词，人生的前一半似乎从来没有思考过这个词。但人生的下半程几乎所有的复杂性来来自于这个词。

对工程师而言，Scalability 大概是从学生毕业的初级工程师，到一个资深工程师转变的时候，遇到核心问题的底层逻辑。鸭哥的文章 北美码农初入职场最好知道的一些事——业界的核心价值观 很多地方就在讲软件工程。随着 coding 能力的加深，解决问题的难度增加，难以避免地要跟更多人一起合作解决技术问题，因此，才能开始理解代码规范，进而加深到理解什么是软件工程 software engineering。这都是为了解决 Scalability 的问题。

而随着你开始走 people manager 的职业道理，开始更跟多的人合作，自己的团队也越来越大，你也会越到同样的问题：how to scale people？于是人和人合作的“代码规范”也出现了，兼容并包，也就是所谓的“people skill”。

我们提出了那么多的范式，都是为了解决 Scalability 的问题，Scalability 是一个非常难的问题。

而作为一个组织，想要 scale，就必须采取某种组织形式，某种 culture，某种 system。

这样的形式千千万万，在我的观察中，有一种比较朴素的分类方式：

• Centralized decision making: Do whatever Elon says

• Distributed decision making: Do whatever A/B Testing says

Elon 的故事我们今天先不讲，但是就一条： extremely aligned 的能量之强大，远超所有人的想象。我们可以不要最聪明的人，我们只要最 aligned 的人，it doesn't matter。Do whatever Elon says 是一个远超所有人想象的组织形式。(这两天 Founder Mode 文章火了啊哈哈，差不多的思路）

绝大多数公司都有没有 Elon，也不会有 Elon，那么就要引入一个 System。A/B testing 是一种 system，是一种非常 practical 的 decision making system。

是不是有点复杂了，我们先岔开个话题，讲点轻松的的事情。

业界的组织形式千千万万，每个公司都有一套自己引以为豪的价值体系，但最常见的是什么呢？虚假的 “do the right thing，empower the people” 的文化。职场的老油条们很快就能意识到这只不过是“Do whatever Elon says” 的掩饰版，很快就都能领悟“向上管理”的秘密。不懂的人会不断地去证明 “do the right thing” 然后发现自己只是小丑🤡.

职场道理讲起来是一套合理的逻辑，但做起来又有千千万万不能讲的故事。就像我听了好多遍雷军的造车分享觉得都很 make sense，但你也知道他多次欲言又止的“友商故事”，“商业环境”才是真正的困难，也讲不了。真的勇士要坚持做正确的事情，正确的事情会带来长远的回报。

讲远了，回到 A/B Testing。我们要在一个“人”为核心的组织结构中引入一个 System 来做 decision making，这何等困难。所以这是一个极大的范式的改变，所有的实践者都需要引入一个新的 mindset：

You don't run the team anymore. You run the system, and let the system run your team.

You are not a leader in many ways. You are a part of the system. You keep duplicating yourself so everyone can follow the system.

所以这是一个极端 top down 的 decision，因为它带来了太多改变，让很多人失去了很多东西。

而且这个里面引入了那么多的新概念，我们今天只聊一个：duplication。

一个系统要能被推广，必须是可以被 duplicatable的。为了被 duplicate，你必须有所取舍，一定要舍弃很多正确但复杂的事情，因为复杂的系统不可能被 duplicate。它必须：simple, clear, fast, doable。

A/B Testing 是不是 simple, clear, fast, doable? 可以是，但绝大多时候我们都把它弄的不是了。

为了让它足够的可以被 duplicate，我在 Tubi 的实践是：

• MLE 入职的 onboarding 顺序: checkout codebase, first analysis, first implementation (a few lines of code)，然后就是 first A/B Testing。一般一两周内就可以上，要快。只有快才能正常化。要快快快快，每个人都要快。

• ML team 上线 A/B Test 不需要任何人的 coordination，只需要两件事：改动自己的ML代码，添加 A/B Testing Config。A/B Testing Config 的流量、时间长度基本是模版化的，只需要添加自己的 model name。所有其他 pipeline 全是自动的，包括 ranking server，data pipeline，offline evaluation，A/B test dashboard，etc。必须要简单。

• Primary Metrics 是固定的，不需要讨论。必须 clear。

• Dashboard 必须简化，绿色（显著） + primary metrics lift 足够了。必须 clear。

• 必须要有 hypothesis，但 hypothesis 可以非常 simple，符合逻辑即可。坚决抵制 “I don’t know how it would perform, let’s just do an A/B test, see the results and then analyze.”

• 最最最重要的是：在实验开始前写好 Action Plan。定义好 primary metrics，只要时间到了颜色绿了，就要 graduate，不需要任何 debate。当实验上线的那一刻，未来就已经决定了。所有的讨论必须在实验上线前完成。我在 2020年的文章中专门提到了这个点：I am the first Machine Learning Engineer, now what?

• Insight 和 Action 要完全分开。Analysis causes confusion, discussion causes confusion, communication causes confusion。这些都是 optional 的，它跟我们的 Action 无关。Insights 是 A/B Testing 的副产品，就算没有 A/B Testing 我们也有无数方法获得 insights。我们要把 Insight 的流程和 A/B Testing 的流程解耦合。

A/B Testing 里面有太多复杂的概念了，我不爱讲。虽然我给过很多 internal 的 training：Bonferroni correction、interaction effect、CUPED metrics、early stop、bayesian testing、sequence testing、etc，其实大家都不在乎的，这些都应该被整合到系统里，自动化。

**大家都只在乎那个小格子最后绿没绿！**当你习惯了这个流程，这是一个极端上瘾的游戏。

Duplication 是一个巨大的 mindset shift：作为一个 builder 我最津津乐道的永远是那么多的 design detail，那么多的 technical detail，那么多有意思的 tricks。那么多真确而且有帮助的事情可以分享。

但是你说的越复杂，就越 scare people away，他们看着你，觉得 that’s good for you, but it’s not for me.

一个工具那么好，但大家都不用，实在是没有什么值得自豪的。一个东西又好，又能被 duplicate，又能 align 每个人的 incentive，让大家自发去 duplicate，那才是真的魔力。

一不留神写了这么多，最后简化一下吧：

• scale 很难，要能 scale，必须有某种 system

• 如果你们公司没有 Elon，那么就得靠 A/B Testing 来 scale，top down

• A/B testing 的系统和流程设计必须要 duplicatable，简化一切

• 简化、简化、简化

希望对大家有一些些启发。下一篇讲讲故事的吧，大家都爱听故事🤪