企业官网建设流程全解析

做推荐系统的人，基本都听过这句话：“算法好不好，得上线AB一下才知道。”可真到自己动手，很多人会发现，AB测试这套东西听着简单，做起来全是坑。从分流不均匀、指标口径打架，到实验跑了两周还不敢下结论，每一步都在考验你的耐心和判断力。这篇文章我想从自己的实操经验出发，把推荐系统里的AB测试完整拆一遍，讲清楚为什么要做、怎么做、怎么判断结果，以及“点击率提升30%”这种目标背后到底意味着什么。

这篇文章适合三类人：一是刚接触推荐系统、想搞明白算法怎么评估效果的算法工程师；二是正在搭建数据实验平台的数据工程师或数据分析师；三是想通过实验思维优化产品的产品经理。文章里不会有太多玄学，都是可以直接落地参考的思路和方法。

1. 先把问题拆清楚：为什么推荐算法优化必须靠AB测试

1.1 离线评估的天然盲区：离线指标涨了，线上却崩了

推荐系统最常见的评估方式是离线评估，也就是拿历史日志数据，把用户过去的行为当作“标准答案”，去衡量模型预测得准不准。常用指标包括AUC、GAUC、NDCG、精确率、召回率等等。离线评估的好处是成本低、速度快、可以反复调试模型，但它的缺点也很致命：离线指标和线上真实效果之间，永远隔着一层窗户纸。

我经历过很多次这样的情况：模型离线AUC提升了两个点，召回率涨了5%，看起来是个大胜利，结果一上线，线上点击率反而跌了。为什么会这样？因为离线评估是基于历史数据做的模拟，而线上环境是实时变化的。用户今天的行为模式、场景的上下文信息、商品池的组成结构，可能和两三天前的数据已经不一样了。更关键的是，推荐系统的离线和在线存在“反馈循环”：线下数据是旧策略下的产物，而新策略的目标是改变用户行为，一旦策略变了，线上用户的行为分布也会跟着变，这个变化在离线数据里是看不出来的。

以点击率预估模型为例，离线评估时，我们假设“曝光了但没有点击”的样本代表用户不喜欢。但线上真实情况可能是：这个位置太靠下用户没看到、卡片加载太慢用户已经划走了、或者用户今天根本没心情购物。这些样本在离线dataset里都被统一打上“负样本”的标签，模型学到的是一个被严重噪声污染的分布。这就是离线指标的局限性——它能告诉我们“模型从历史数据中学到了多少规律”，但很难告诉我们“策略投入真实场景后会产生什么连锁反应”。

AB测试的价值就在这里。它把新旧策略同时部署到真实流量上，用严格的实验分组机制隔离变量，让数据自己说话。分层流量、随机分组、双样本检验……这些听起来复杂的术语，本质上都是在回答一个最简单的问题：用户行为的变化，到底是我们的改动带来的，还是随机波动造成的？

1.2 AB测试在大数据推荐场景里到底在测什么

很多人会觉得AB测试就是“分两组，一组用老算法，一组用新算法，看哪组点击率高就选哪组”。这个思路方向没错，但真到了大数据推荐场景里，事情没那么简单。

第一个要搞清楚的是“测什么”。表面上看测的是算法模型，但实际上测的是“策略组合”。一次推荐系统的改动，往往不只是换一个模型权重，可能同时改了召回逻辑、排序融合方式、多样性控制参数、甚至前端展示样式。如果一次上线同时变了太多东西，实验出来了也说不清楚是哪个改动带来的提升。所以我在实际工程中，强烈建议一次实验中只改动一个核心变量，其他保持完全不变。比如这次只改排序融合的权重，那召回和重排逻辑就都不要动。

第二个要搞清楚的是“用户粒度”。推荐系统的指标模型往往以用户的实时行为为粒度，但是AB测试的分组却通常以用户ID为粒度。这意味着，同一个用户在所有实验中都只能落在同一个桶里，不能今天看见的是新算法，明天又切回旧算法。原因很简单，推荐系统是有记忆的，用户对个性化推荐的反馈是连续累积的。如果用户在同一次请求中混合看到新旧两种算法的结果，我们根本没法区分某个点击是哪个算法带来的。

第三个要搞清楚的是“指标的目标”。点击率确实是推荐系统最核心的交互指标，但它不是唯一指标。一个算法把点击率从2%提升到3%，但如果用户点进去之后发现内容根本不是自己想要的，停留时间大幅下降，那这个点击率提升就是“虚火”。所以推荐系统的AB测试往往需要建立一个“指标树”，既有核心指标，也有护栏指标，这点我后面会专门拆开讲。

2. 设计指标体系：点击率不是唯一指标，但它是第一道拦路虎

2.1 点击率（CTR）的口径怎么定才不会被数据骗了

点击率的计算很简单，公式就是“点击数除以曝光数”。但如果不对“曝光”和“点击”做严格定义，这个数字可以轻松被各种因素“污染”。

以一个大促活动场景为例：用户打开APP，首页首屏加载出6个推荐卡片，这个过程叫一次“曝光”。如果他在这个会话里点了一个商品、刷走了、又滑回来点了另一个商品，这两个点击都算在同一个曝光里吗？很多团队的日志系统并不严格区分“一次曝光下的多次点击”，导致点击率可能超过100%，这是数据口径混乱的典型症状。

我在设计推荐系统点击率指标体系时，通常会定义三个层级：

• 曝光点击率（PV CTR）：公式是“总点击PV / 总曝光PV”。这个指标反映了整体流量效率，但容易被曝光深度稀释。比如用户刷得越深，曝光次数越多，CTR往往越低。
• 用户点击率（UV CTR）：公式是“点击用户数 / 曝光用户数”。这个指标体现的是用户渗透率，适合衡量算法对用户兴趣捕捉的广度。
• 会话内点击率（Session CTR）：公式是“有效点击会话数 / 总会话数”。这个指标适合衡量推荐结果对用户需求的即时满足能力。

到底用哪个口径，取决于实验目的。如果做的是首页信息流推荐优化，我通常用PV CTR做主指标，因为信息流推荐最看重的是“流量利用效率”；如果做的是冷启动算法优化，那UV CTR可能更重要，因为冷启动阶段的核心目标是“让更多用户愿意点一下试试”。

但不管你选哪个口径，都要先对数据埋点做一次DP（数据稽核）检查。我踩过一个坑：前端的曝光埋点逻辑是“卡片滑动到可视区50%以上才上报”，但老版本的APP没有这个限制，导致新旧版本的曝光基数不一致，实验结果完全没法对比。后来我们花了整整一周做埋点统一的迁移，才把口径拉齐。在AB实验开始之前，花时间把数据埋点核对清楚，永远是性价比最高的投入。

2.2 除了点击率，这些指标必须一起看

做推荐系统的AB测试，千万不要只看点击率一个数。我建议设计指标体系时参考下面这张表：

拿“有效点击率”来说，这个指标是我后来才重视起来的。很多推荐场景里，用户会误点、测试机反复点击、甚至被羊毛党刷量。如果不做有效点击过滤，实验组点击率可能被虚假点击抬高，真实业务效果却一塌糊涂。有效点击的判定可以结合：点击后在页面停留是否超过1秒、点击是否导致后续浏览行为、设备是否有异常行为模式。

另一个特别容易忽略的是“次均停留时长”。我见过一个改版，把推荐卡片从大图改成了双列小图，曝光点击率飙升了15%，但次均停留时长几乎腰斩。后来用户访谈才知道，小图展示让用户失去了判断信息价值的耐心，基本是看到标题就点，点进去发现内容不对就退。这种“浅层点击”对算法模型的训练反馈也是有害的，因为模型会把“用户点击了”当成“用户喜欢”，继续推送类似内容，形成恶性循环。

所以我在每次AB实验上线前，都会先写一份指标口径文档，明确哪个是主指标、哪几个是护栏指标、每个指标在什么条件下算胜利。没有护栏指标的实验，我一般不建议上线，因为它的结果不可信。

2.3 样本量计算与实验时长估算

这一点是很多推荐系统团队最容易犯错误的地方：实验没跑够样本量和时间，就急急忙忙下了结论。点击率提升1个百分点，到底是真的有效还是随机波动？这个问题必须靠统计学回答。

以点击率这个二值指标为例，我们做AB实验时一般用双样本比例检验（z检验）。样本量估算公式大致如下：

n = (z_{1-α/2} + z_{1-β})^2 × [p1×(1-p1) + p2×(1-p2)] / (p1 - p2)^2

其中p1是基线点击率，p2是预期实验组点击率，α是显著性水平（通常取0.05），1-β是统计功效（通常取0.8）。z_{1-α/2}和z_{1-β}是对应的z分布分位数，α=0.05时z_{1-α/2}=1.96，β=0.2时z_{1-β}=0.84。

举个具体的例子。假设推荐位当前点击率是2%，我们希望检测出“点击率相对提升10%”（也就是从2%提升到2.2%）的效果，那么p1=0.02，p2=0.022。代入公式估算：

• 分子部分：(1.96+0.84)^2 ≈ 7.84
• 分母部分：0.02×0.98 + 0.022×0.978 ≈ 0.0196 + 0.0215 ≈ 0.0411
• 样本量：7.84 × 0.0411 / (0.002)^2 ≈ 80,600

也就是说，每组至少需要约8万个曝光样本，两组合计约16万个曝光。如果你的产品日活跃用户只有10万，每个人每天平均刷20次推荐，一天就能产生200万曝光，跑一天其实就够量了。但注意，这里计算的是“曝光样本量”，不是“用户量量”。如果产品流量很小，曝光总量不够，实验时长就得拉长。

还有一个很多人忽略的点：实验时长最少要覆盖一个完整的业务周期。如果你做的是电商推荐，至少要覆盖一周，因为周末和工作日的用户行为差异巨大；如果做的是内容推荐，至少要覆盖一个完整的刷屏时段。我见过一个团队只跑了6小时的实验就宣布新算法胜出，结果第二天发现上午时段推荐的是新闻资讯，下午用户变成了刷短视频的行为模式，结论完全反转了。

另外，样本量计算还要考虑一个因素：实验组和对照组的流量是否完全独立。在复杂的重叠实验架构里，如果两层实验之间有交互效应，有效样本量会打折扣。不过这个我们下一节展开讲。

3. 实验分流架构：不搞清分层与隔离，AB测了也白测

3.1 基于Hash的分流策略与层内正交

推荐系统场景里，最常用的分流策略是基于用户ID的哈希分桶。你可以把用户ID用某种哈希函数映射到一个整数空间，比如0到9999，然后按余数或区间划分到不同的实验组。这样做的好处是：同一个用户的ID永远落在同一个桶里，不需要额外的分流状态存储，几乎不增加线上延迟。

但这里有一个关键概念：层（Layer）与正交（Orthogonal）。成熟的推荐系统一天可能会同时跑几十个AB实验，有的改召回策略，有的改排序策略，有的改UI展示。如果每个实验都独立分一次桶，可能会出现同一个请求同时命中多个实验组的情况，实验之间互相污染。Google的实践经验是：将实验分成若干层，每层内的流量正交划分，即同一个用户ID在每层的哈希盐值不同，这样同一用户会以独立的随机方式进入各层的实验组，互不影响。

在我负责的推荐系统平台里，实验分层的设计大致长这样：

• 第1层：召回策略层。这里改动的是候选集生成逻辑，流量分桶后，实验组用新召回路，对照组用老召回路。
• 第2层：排序策略层。这里改动的是CTR预估模型或排序融合逻辑，与召回层独立正交。
• 第3层：展示策略层。这里改动的是卡面元素、标题长度、图片比例，测试的是前端展示对点击率的影响。

每层之间的哈希盐值设计为不同的常量，比如召回层用“recall_v1”作为hash盐，排序层用“rank_v2”作为hash盐。因为哈希函数的雪崩效应，同一个用户ID在不同盐值下会均匀散落到不同分桶，这样就实现了各层正交。简单理解就是：用户在召回层的分组，和他排序层、展示层的分组没有相关性，这样可以同时跑几个实验而互不干扰。

3.2 实验数据管道与埋点一致性

分流解决了“用户怎么分”的问题，接下来要解决“实验结果怎么数”的问题。很多团队重金搭建了实验平台，结果每次实验的结果都是分析同学用SQL手动数出来的，不同人不同口径，每次数完还要对半天数。在我的团队里，我们做了一套相对规范的实验数据管道：

第一层是埋点数据接入。客户端上报的曝光、点击、停留等行为数据，通过消息队列进入数据仓库。这里有一个注意点：消息队列的topic要按行为类型分开，曝光、点击、滑动、负反馈各自独立，不要混在一个topic里。混在一起会导致下游消费者逻辑复杂，还容易丢数据。

第二层是实验分流日志接入。线上分流服务在每次请求时，除了返回实验策略配置，还要把用户ID、请求时间、实验ID、分组信息写入一条分流日志。实验分析时，用这条分流日志去关联用户行为，才能准确知道“哪些用户属于哪个实验组”。这里最容易出现的问题是分流日志和行为日志的时区不一致。比如分流日志记录的是UTC+8时间，行为日志记录的可能是UTC时间，导致关联时出现一天偏移。

第三层是指标聚合层。我们一般会使用Spark或者Flink对实验数据做按天粒度的预聚合，形成“用户日粒度行为汇总表”。这样做的好处是：日常分析不需要每次都扫描原始日志，大大节约计算成本。聚合表主要包含：用户ID、实验ID、分组标识、曝光数、点击数、有效点击数、停留时长总和、负反馈次数等。

3.3 从离线评估到线上AB，漏了这一环策略上线就悬

很多团队在做完离线评估后，就直接把模型部署上线，连AB实验都不做。我觉得这绝对不行。离线评估最大的问题在于它没法验证“实时性”和“反馈闭环”。但如果你做的是深度推荐模型，我建议至少走一趟“影子模式”或者“放量观察模式”。

影子模式的具体做法是：线上请求进来后，同时用老模型和新模型做预测，但线上展示的仍然以老模型结果为准。新模型的预测结果只记录下来，不真正影响用户。这样可以在真实流量上积累新模型的“虚拟预测日志”，然后离线对比“如果当时用了新模型，用户行为会有什么不同”。

影子模式的好处是没有任何试错成本，但缺点也很明显：它低估了真实反馈闭环的价值。因为用户没有真实看到新模型的结果，他的点击行为不会被新模型影响，所以影子模式下评估的指标更像是一个“半在线”的评估。它适合做模型上线前的安全检测，不适合替代AB测试。

真正可靠的上线路径还是：离线评估 → 影子模式或小流量灰度 → AB实验 → 全量上线。每走一步，数据验证的严格程度都在提高，风险逐步降低。

4. 实操案例：一次把推荐点击率提升22%的完整迭代

4.1 基线问题定位：为什么老策略太平庸

有一年我被安排去做信息流推荐场景的优化，当时负责的推荐位点击率已经连续几个月徘徊在1.8%左右，几乎没有任何起色。我们在做离线分析时发现，点击率低的很大原因不是模型不够好，而是推荐内容的同质化太严重。

怎么发现这个问题的？我们把用户点击过的Item再拿去做语义聚类，发现用户点击的内容集中在少数几个主题的头部。也就是说，用户对推荐位的第一屏内容还比较感兴趣，但刷到第二屏、第三屏时，算法推送的还是类似的头部内容，重复度极高，用户很快就腻了。

那会儿我们用的排序模型是一个双塔模型加上一些融合规则。双塔模型负责产出点击率预估分数，融合规则负责把新鲜的、但分数没那么高的内容抬上来。问题就出在融合权重太保守，新鲜内容几乎很少有机会进入前20名。

我们从日志中抽取了一个样本：用户反复看了8个同一IP题材的电影推荐，但都没有点击，然后离开了推荐位。这就说明，即使预估分数都不低，但如果多样性控制做得不好，用户同样会流失。

4.2 策略改动方案：加实时行为特征，调整融合权重

定位到问题之后，我们制定了两个改动策略。第一个是加入实时行为特征：把用户过去5分钟内的实时点击序列编码成向量，拼接到推荐模型的输入特征里。这样做的好处是，用户的短期兴趣偏移能被即时捕捉，增强了推荐结果的时效性。举个例子，用户刚点击了一篇关于减脂的健身文章，系统马上就能在下面几帧推荐更多健身相关内容，而不是继续推他两小时前看过的时政新闻。

第二个改动是调整融合权重：在排序阶段，我们给“内容新鲜度得分”和“同质惩罚系数”各加了一部分权重。内容新鲜度得分来源于稿件的发布时间和实时热度；同质惩罚系数则基于当前推荐列表里已经展示过的Item主题分布，对与已展示内容过于相似的候选进行降权。这个权重我们用离线历史数据扫了一遍参数，选用“新鲜度相对权重提高3倍时离线NDCG还能保持不降”的阈值作为实验参数。

听起来不难对吧？但真正做起来要小心一个静态特征陷阱：如果我们只是简单地把实时行为特征拼接进双塔模型，会发现训练和推理阶段不一致。训练时用的是用户过去5分钟的“真实历史行为”，推理时如果线上获取不到实时的行为序列（比如用户在服务端有缓存延迟），模型拿到的特征就是空值或过期的。我们在上线前做了一个特征对齐检查，发现实时行为特征在推理链路上的P99延迟高达800ms，如果不优化会导致排序请求超时。于是我们把这个特征的实时路径改成“特征服务异步更新、读时合并”的方式，确保推理时拿到的是尽可能新鲜的数据。

4.3 实验配置与上线过程

我们上线了一个排序策略层的AB实验。实验组用的是“加实时行为特征+新融合权重”的新策略，对照组是老的双塔模型加老融合权重。分组方式是用户ID哈希到100个桶，实验组占50个桶，对照组占50个桶，互斥隔离，不做重叠实验。

实验开始前我们先做了一轮AA检验。AA检验的意思是：不改变任何策略，只是把用户随机分成两组，验证这两组的点击率、曝光量等指标在统计上无显著差异。如果AA检验都不通过，说明分流逻辑本身就存在问题，后面的实验都不可信。我们的AA检验结果是：点击率差异0.03个百分点，显著性p值为0.62，说明分流是均匀的。

正式实验跑了5天，前3天我们按兵不动，只做数据监控，防止出现突发的数据异常或者线上报错。第3天的时候看着实验组的实时点击率比对照组高了大概18%，我心里已经有点激动了，但忍住没有下结论，因为要等样本量跑足。

第5天准备结束实验前，我们用双样本比例检验算了p值。基线点击率1.8%，实验组点击率2.2%，整整提升了22%。因为流量足够大（两组日均曝光都过百万），p值小于0.001，95%置信区间也明显不跨越0。同时，护栏指标里次均停留时长不降反升了5%，负反馈率也下降了，说明这个点击率提升不是靠“标题党”带来的虚火。

整个实验从确认方案到拿到可下结论的结果，一共花了两周半。包括特征开发、离线调参、线上灰度、AA检验、正式实验和数据分析。

4.4 结果分析方法与显著性判定

实验结束后的数据分析，我建议至少分三步走：

第一步是总体验证。看主指标点击率在实验组和对照组之间有没有显著差异。这里不能只看简单的“差的百分比”，要用假设检验和置信区间。点击率这种比例型指标可以使用z检验，也可以用boostrap等重采样方法估算置信区间。在数据量足够大的时候，两者的结论一般一致。

第二步是分维度拆解。只看整体往往看不清问题。按用户新增/存量、设备平台、地域、流量位等维度分别看实验效应，经常能看到“实验组整体显著提升，但新用户群体呈现下降”这种复杂情况。举个例子，我们当时拆解就发现，实时行为特征对冷启动的新用户几乎没有帮助，因为新用户没有足够的历史行为数据，模型里这个特征接近于空。但对于存量用户，提升非常显著。

第三步是时间趋势看稳定性。把实验期间的指标按天绘制趋势，观察提升幅度是否每天都在稳定出现。如果某一天的提升主要靠一个大促活动拉起来，其他天都是持平甚至微降，那就说明这个策略带有较大的偶然性，不足以支撑全量上线。我们当时注意到实验组和对照组的指标差距在整个实验周期里是持续且稳定的，没有出现“头两天大涨，后面就衰”的现象。

提示：在实验结果判断时，除了看p值和置信区间，一定要同时检查“提升幅度的实际业务意义”。统计学显著不等于业务上值得上线，有些改动虽然统计显著但提升幅度过小，比如只提升0.1%的正向效果，但带来了明显更高的计算成本或延迟，那就需要算一算性价比。

5. 常见问题与排查技巧实录

5.1 AA检验不通过：分流不均匀

碰到这个问题不要急着重新跑实验，先查三件事：第一，分流依据的用户ID是否稳定，有的客户端上报的ID会变，比如未登录用户的临时ID会因设备重启而改变，导致同一个用户被分到不同组，污染实验；第二，分桶的哈希盐值是否冲突，前面说过每层实验要用不同的盐值，避免层间实验串流；第三，样本量是否足够稀疏，如果某些分桶的样本量很少，AA检验出现了肉眼可见的差异其实不奇怪。

有一次我们做AA检验不通过，查了一整天发现是一个线上缓存害的：分流服务在本地缓存了用户ID到组别的映射，但缓存过期时间不一致，导致同一个用户进来时有时分到A组有时分到B组。清理掉缓存，重新做了一遍AA，马上通过了。

5.2 实验组点击率涨了，但整个业务大盘没涨

这种“局部胜利、全局失利”的情况，通常有三种解释。第一种是新鲜感效应：新策略刚上线时，用户感到新奇，点击率短暂上升，但过一段时间效果衰减。针对这种解释，最好把实验拉长，或者提前设计好重复观测的办法。第二种是流量挤兑效应：实验组用户点击率确实升了，但他们的点击是在页面其他位置上“抢”来的，整体APP的时长和转化并没有改变。第三种是辛普森悖论：整体数据看起来没涨，但拆分各层用户后，实验组在各种用户群里都显著上涨，只是实验组的流量分配了更多低活跃用户，拖低了总体数据。

解决这类问题的方法是：建立一个统一的“实验效果归因表”，把实验的关键指标和其他业务指标放在同一个维度下去对比，不要只看单指标。我曾经在一次实验中遇到点击率显著上涨但GMV几乎无变化的情况，最后发现是推荐算法把用户导到了低价商品上，点击率自然高，但客单价低了。我们把指标从CTR切换成“点击GMV价值”后，结论反转为实验策略不佳。

5.3 新用户与老用户的效果分化

推荐系统的实验经常出现“老用户效果显著提升，新用户效果反而变差”。这个问题的根源在于新用户没有历史行为，个性化特征形同虚设。解决思路之一是给新用户单独设置一个冷启动策略层，实验组的改动只影响老用户，新用户仍然走保守策略。当然，如果你就是想验证冷启动算法，那就应该把实验流量集中到新用户上，指标拆分也要按用户群分开看。

我之前做过一次实时特征实验，数据拆解后看到新用户组的AUC下降了0.3%，细查原因发现实时特征模块在缺少历史行为时会用热门Item的全局embedding代替，这在部分低活跃用户身上反而拉低了偏好匹配度。后来我们把冷启动用户归入全库热门兜底策略，实验组提升才稳定下来。

5.4 实验收敛慢、显著性不足

实验跑了一周，p值一直在0.05上下波动，就是过不了置信线。这种情况建议先做一个“观察功效”分析：按当前的样本量，我们能够检测出的最小效应量是多少。如果最小可检测效应是30%，而实际提升只有10%，说明样本量不够，继续跑下去大概率也得不到显著结果，不如加量。

另一种情况是指标方差太大。点击率这个指标在用户粒度上方差极大，因为有的用户一天刷100次，有的用户只曝光一次。解决办法是将指标从“曝光点击率”改为“用户点击率”，或者对实验组按用户活跃度做分层（stratifification），降低方差。我见过一个团队以前做实验总是测不出显著结果，改成按活跃度分层后，同样的实验提升幅度从“不明显”变成了“显著为正”。

5.5 实验之间的相互污染

当公司的业务线很多、推荐位很多时，实验之间最容易被忽略的问题就是“效应串门”。A实验组改进了首页信息流的点击率，B实验组在详情页测新的推荐算法，结果A实验带来的“点击增长”改变了用户进入详情页的行为分布，从而间接影响了B实验组的结果。

针对这个问题，靠“注意”是不够的，要建立实验的互斥或者正交机制。在同一用户会话内，不同层级实验可以正交；但如果是同一个页面同时参与多个实验，必须做到互斥。另外，实验平台最好维护一个“生效实验清单”，当新的实验申请上线时，平台自动检查它涉及的流量范围是否与其他实验冲突，如果有冲突就强制拒绝。这一步看似是流程问题，其实对实验结论可信度非常关键。

最后再分享一个小技巧

在我做推荐系统AB测试的这几年里，最深的体会就是：AB测试真正要验证的不是“改动是否有效”，而是“我们对用户行为的理解是否正确”。你要对你推荐策略背后的假设足够敏锐，然后用严谨的AB实验去证实或者推翻它。

最后给一个非常实用的小建议：每次实验结束后，不管胜出还是失败，都写一份简短的实验复盘报告。报告里不仅写结果，更要写下当时的假设、数据观察、踩过的坑、下一轮的想法。很多团队做实验都是“出了结果就扔”，完全不积累知识资产，这样即使做了十次实验，成长速度也非常慢。而那些持续在做推荐系统优化的团队，往往就是靠着一份份实验复盘报告，把对用户、对算法的理解一点点沉淀下来的。这一点，我个人强烈建议你上手去做。因为等你实验做得多了会发现，AB测试最有价值的产出，往往不是“提升了某几个百分点”，而是“我知道了哪个方向不应该再浪费时间去尝试”。