04 中国平台 · AB RESEARCH

4.1 中国实验平台全景#

中国实验平台的公开图景有一个反直觉特征：能力最强的几家公司，对外可见的"产品"反而最少。字节是唯一把内部平台做成对外商品的公司，但对外文档与内部方法论之间有明显落差；腾讯在 VLDB、KDD 上持续输出工业级方法，腾讯云却找不到通用 A/B 产品页；拼多多至今没有一篇可核实的工程博客。这说明中国大厂的实验能力主要不是以"产品"形态沉淀的，而是以组织内的基础设施 + 论文/专利/白皮书三种形态沉淀的。只搜产品名会系统性低估这个市场，只看论文又会系统性高估其产品化程度。

公开可验证的组织形态只有三类，且与公司规模无关，与事业群的数据边界强相关。

路径	代表	共同特征	主要代价
公司级大一统	字节（Libra→DataTester）、快手（指标底座）	一套分流/指标/方法服务全公司，再择机对外	平台排期成为业务瓶颈；内外节奏冲突
BG 级联邦	腾讯（TAB/X/天秤）、阿里（通天塔/Tesla/AirTrack）、美团（图灵/Wedge/BETA）	各 BG 自建，BG 内收拢，公司层弱治理	口径分裂、重复建设、跨平台流量冲突
能力嵌入产品	百度（统计 AB/AI_REC/峙一）、京东（内部体系+增长实验室）	不追求独立平台品牌，实验作为分析或云产品的一个模块	能力浅、难复用；内外两套系统脱节

时间上可分三段。2012–2016 是引入期，主题是"能分流、能出报表"：字节 2012 年引入 A/B 体系，淘天通天塔 2015 年诞生，天猫 AirTrack 与阿里妈妈 Tesla 在 2016 年公开，携程 2017 年还在用"设备号取模 100"做机票实验。2017–2020 是中台化期，主题是"多业务复用同一批流量"：腾讯 PCG 把骡马、阿拉丁、OAS 收敛为 TAB，滴滴 Apollo 支撑每周数千实验，京东开始搭指标与实验的语义层。2021–2026 是计算与因果期：微信在 VLDB 2024 公开 BSI 指标计算，字节公开 ITR 与 DQ，美团连发八篇白皮书，快手把 AB 指标搬到 2000 节点 Doris，小红书公开 PreAA 与反转实验。主题不再是"支持多少实验"，而是"算得准、算得快、算得对"。

这条线索解释了一个易被误读的现象：公开度与公司体量不成正比，而与业务形态强相关。内容与社交公司愿意讲方法（小红书、快手、B站），因为实验对象是"人"，方法可复用、可外宣；交易型公司愿意讲指标口径（京东、美团），因为痛点在口径；广告型公司愿意讲竞价与归因（阿里妈妈、腾讯广告），因为那是收入命脉；拼多多则完全沉默。公开度是传播策略，不是能力排名——这是阅读本章所有材料前必须先建立的校准。

4.2 字节跳动#

字节是中国唯一完成"内部平台→对外商品"闭环的公司，也是"内外双轨"张力最典型的一家。内部叫 Libra，对外叫 DataTester，同源不同步。字节 A/B 测试技术负责人韩云飞在 AICon 上海 2025 的讲者简介里给出最完整的时间线："内部名称 Libra，对外产品 DataTester……脱胎于 2012 年引入的 A/B 测试体系，2016 年实现产品化，2021 年通过火山引擎开放给企业客户。"来源这句话澄清了两个常见混淆：DataTester 的商品史只有五年，不是 2012 年就存在；"十多年"指的是内部实验体系，不是对外版本。

规模数字必须带口径引用。

时间	累计实验	日新增	同时运行	覆盖业务
2021-11	80 万+	1500+	1 万+	500+ 业务线
2023-06	240 万+	4000+	5 万+	数百
2025-05	340 万+	未更新	7 万+	数百

2021-11 到 2023-06 的 19 个月，累计从 80 万到 240 万，月均约 8.4 万；2023-06 到 2025-05 的 23 个月，从 240 万到 340 万，月均约 4.3 万。增速在放缓，但这可能是统计口径变化（去重、只计有效实验），也可能是业务进入存量期，不能简单读作"平台衰退"。另有一处存在不同说法：BytePlus 英文产品页写"累计 150 万+、日增 2000+、同时 3 万+"来源，与 2025 年的 340 万/7 万明显冲突，合理推测是国际化版本的历史快照或只统计 BytePlus 侧，不建议对外引用。

真正值得自建方细看的是四个工程取舍。第一是分流键与统计键分离：分流服务接收 decision_id（只算命中、不上报）、track_id（只做上报归因）、attributes（只参与过滤）三个参数来源。原因是"稳定分流"与"准确统计"对 ID 的要求天然矛盾——分流希望 ID 越稳定越好（设备 ID、ssid），统计希望 ID 能跨端合并（登录 uid）。强制用同一个 ID，用户一登录就可能跳组。代价是 ID 映射表变成关键基础设施，映射错乱会产生"分流在 A、上报在 B"的静默错误。

第二是双层哈希 + 1000 桶：hash(did + ":" + layer_name) mod 1000 定层，hash(did + ":" + experiment_name) mod N 定组，salt 用层名/实验名而非随机数来源。方案实现简单、跨语言可复现、不需要中心化分配服务，但换来三个硬约束：最小粒度 0.1%，小流量业务做 1% 实验只有 10 个桶；层名/实验名一旦上线不能改，改名即换桶；正交性是概率意义上的，字节自己在 2021 年就承认要靠"大量模拟实验 + 系统监控自检，超过阈值就调整"来源。换句话说，正交不是哈希函数的数学保证，而是一项需要持续运营的监控指标。

第三是层—域—实验的三级治理：流量层 → 互斥域组 → 互斥域 → 实验；同域组内不同域互斥，不同域组之间正交，域还能嵌套子域来源。配套规则很琐碎——已被实验绑定的层不能再绑新域，运行中的实验不能切到已有实验的域——但本质是用创建时的约束替代运行时的分布式锁。第四是三级缓存 + MQ 广播 + 定时全量兜底：配置落库同时写消息队列，各节点消费 MQ 更新内存与 Redis，另开协程定期全量刷新防止 MQ 故障。这是明确的"牺牲实时性换可用性"：配置晚生效几分钟没人会死，分流报错会直接影响用户体验；代价是配置非强一致，极端情况下几分钟内读到旧配置。

统计能力是字节最需要克制表述的部分，因为内部方法论不等于对外产品能力。对外文档能确认的是频率派报告：p 值、95% 置信区间、MDE、核心指标唯一 + 必看指标强制继承、告警支持"仅显著变化触发"来源、实验前重随机化（最多 3 个指标或按 cluster）来源、MAB 智能调优（最短 30 分钟一轮，冷启动每组 >500 人，仅 Ultimate Edition）来源。内部文章披露的则是另一套：CUPED 之上自研 ITR（线性模型、决策树、神经网络分别学习实验前后相关性，再用 stacking 学权重），在一条业务线 10 个指标上均有额外方差缩减，最高接近 20%来源；Parleiden 把 Leiden 并行化，数小时可对约 1 亿节点、300 亿条边的社交图完成社区划分；DQ 估计量用 MDP 式策略评估替代均值差，论文称在抖音把 MSE 降低 99%来源。

这里存在不同说法：内部文章说这些方法已落地，对外文档却几乎不提 CUPED/ITR/SRM。合理解释有两种——尚未产品化到对外版本，或产品化了但没写文档。无论哪种，采购方都不能假设"买了 DataTester 就有 CUPED"。同理，公开文档里的"实验诊断工具"只回溯近 3 个月分流请求、给出 8 类未命中原因，那是分流正确性诊断，不是 SRM 检验；把两者混为一谈是常见的营销误读。

字节的局限也很具体：0.1% 的最小粒度对小业务不友好；服务端"进组不出组"要业务自己实现 UserAbInfoHandler（官方给了 Redis 示例），不实现就会在扩流量时跳组；服务端 SDK 能力不均，匿名分流只有 Java/Go/PHP 支持，互斥域只有 Java/Go 支持；Traffic Shunt Agent 官方定性为"单节点、性能等价于单个服务端 SDK，只建议试用和小流量"；实时性是"当天实时 + 次日起 T-1"的 Lambda 型。这些限制拼起来，画像很清楚：它是一套为超大规模、多业务、强运营场景打磨的工程系统，不是为统计严谨性打磨的分析系统。

4.3 阿里巴巴#

阿里的实验体系不能用"一个平台"描述。公开可验证的至少五套：淘天通天塔（AB 分析数仓）、阿里妈妈 Tesla（分层分流 lib）、天猫 AirTrack（端上实验），加上阿里云面向模型/推荐/搜索的 PAI ABTest、PAI-Rec、OpenSearch A/B。它们分属不同法人、不同业务域，不能拼成一个"阿里实验平台"——这既高估统一程度，也低估各平台的场景约束。

三套内部系统的分流实现差异大到不像同一家公司：Tesla 是 lib 嵌进广告引擎，hash % 100 + 1 得 1–100 桶，用 layerID 作离散因子保证层间正交；AirTrack 是端上 SDK 解析一棵 JSON 条件树，用"设备 ID + 条件名称 + 当前节点深度"哈希到 0–10000 后按区间落子树；通天塔则根本不公开分流层，它是分析平台。Tesla 的 bucketID 值得单独说：一次请求可能命中多层多个实验，返回 100_103 这样的下划线拼接字符串，日志按 _ 拆开就能还原每个实验。这个设计极其轻量，但要求所有下游模块透传 bucketID，长链路里很容易丢字段。另一个被低估的设计是"初始化层"：每个场景第一层存放要全量生效的参数，实验推全时删掉实验、把参数挪进初始化层，避免实验数无限膨胀。需注意一处存在不同说法：部分二手资料把 Tesla 的公开时间记为 2017 年，InfoQ 原文实际发布于 2016-09-19。

通天塔的价值不在分流，而在把 AB 数据做成公共数仓：2015 年诞生，连续十年支撑淘天算法 AB 分析，接入搜索、推荐、内容、用增、营销等 100+ 场景，能力分三层——AB 数据公共层（线上分流、分布对齐、通用特征、场景 label）、科学评估层（长周期跟踪）、自助分析层（多维即席 OLAP）来源。2025 年的 Fluss 改造把实时 AB 的代价讲得很透：原链路 Flink + 集团 TT + Hologres，曝光作业消费 44 个字段却只用 13 个，行存导致约 70% 的 IO 在为不需要的列付钱；成交归因要"排序 + 双流 Join + 24 小时 State"，单任务 State 高达 100TB，Checkpoint 超时、改作业要从 0 点重刷。换 Fluss 列存 + Delta Join 后，State 减免 95TB，CPU/内存实际使用降低 80%+，资源消耗平均降低 30%；2025 年 618 验证流量峰值千万级、平均延迟 1 秒内。这些是工程师自述、无第三方审计，但组件与改造前后对比是硬细节。

阿里真正领先的是广告实验的方法论深度。阿里妈妈 2021 年的数据科学系列把指标分成四类（UV 转化率、人均指标、连续型定量指标、比率指标），并区分"不变量"（两组应相同，用于校验分流/埋点）与"变量"（要观察的效应）——这是护栏指标的雏形：不变量异常，先查 SRM/埋点，而不是看 p 值来源。离线抽样那篇完整给了 CUPED（Z = X - θY，θ = Cov(X,Y)/Var(Y)）、分层抽样、IPW、PSM 的组合来源。这条方法链的意义是承认广告主层面的实验往往不是随机对照：运营活动只对消耗达阈值的客户开放，客户是否使用某产品是自选择，此时不能假装是 A/B。

更关键的是它公开讨论了广告实验的四层特殊性。竞价破坏 SUTVA——实验组提高出价会改变竞价环境，影响对照组曝光与成本；预算是广告主/计划级共享资源，按用户随机会让 A 组消耗挤占 B 组机会，随机单元必须上移；归因不等于增量，归因回答"记给哪个触点"，增量回答"没有这个广告还会不会转化"；长期效应有 carryover 与 saturation，7 天结论不能推全年。对应的学术输出是 CausalMTA（KDD 2022，用因果推断消除多触点归因中的用户混杂偏差，再做 Shapley 分配）来源与 CausalMMM（WSDM 2024，显式建模渠道投入的时序衰减与饱和效应）。但必须划清边界："用分层/域隔离实验"是公开可验证的，"用 switchback 处理竞价干扰"没有公开证据，只能标为行业通用做法与推断。

产品化是阿里的短板。PAI ABTest 文档更新于 2026-09-09，仍是邀测发布、功能免费，仅北京/上海/杭州/深圳四地域，不支持角色 SSO，只能用 RAM 子账号；底层 EAS、MaxCompute、Hologres 单独计费来源。OpenSearch A/B 限制更硬：每组最多 20 个实验、最多 10 个同时在线、流量最小粒度 1%、报表 T+1来源。而 AHAS 的 Feature Toggle 模块在 2024-01-05 停止新购、2025-03-31 正式停服，官方明确说"目前没有无缝替代产品"来源。这条比任何功能列表都重要：它说明阿里云在"实验相邻品类"上曾有过独立产品，却在 2024–2025 年主动退场。

一句话总结阿里：它证明了"分析面可以比控制面先成熟"，也证明了"控制面不统一，最后每个 BU 一套 bucketID、一套指标口径"。对自建平台来说，先把实验/指标/分流的元数据模型定下来，比先写 SDK 更重要。

4.4 腾讯#

腾讯是"能力最强、产品最散"的典型。截至 2026-10-18，腾讯云官网没有一个独立售卖的通用 A/B 实验平台产品页；能公开检索到的是 BG 级中台、海外 SaaS 和若干场景化能力。

名称	归属	定位	公开状态
TAB 实验中台	PCG	公司级/PCG 级一站式 A/B	2022 年文章点名；2026 年仍在招相关岗位
X 实验平台	WXG	微信全业务：AB/MAB/BO/Interleaving/客户端/社交/双边	2023-10 官方技术文章披露
天秤实验平台	CDG	CDG 侧实验平台	仅 2022 年点名，细节未公开
ABetterChoice	PCG；海外主体 Proxima Beta	面向游戏出海的仓库原生 SaaS	官网/文档可访问，在售状态待核实
广告拆分对比	腾讯广告	广告主自助 A/B：创意/定向/出价	2019 年上线，页面仍在线
IM Push A/B	腾讯云	推送标题/内容两组等比例	文档 2026-04-24 更新

最重要的一行是 2022 年腾讯大讲堂的原话："PCG 有 TAB 实验平台，WXG 有 X 实验平台，CDG 有天秤实验平台。在 PCG 内部，早期有骡马、阿拉丁、OAS 等实验平台，现在主要是使用 TAB 实验中台。"来源它揭示的路径是"先有烟囱、再有中台、BG 内统一、公司层联邦"，与字节"一个平台服务全公司再对外"完全相反。这里存在不同说法：2026 年的招聘 JD 写"支持腾讯一站式的 A/B 实验平台建设"，但"一站式"是 JD 话术，是否覆盖 WXG/IEG，公开材料无法证实。

腾讯的护城河不在实验管理 UI，而在指标计算与干扰推断。指标计算看微信 2023 年的湖仓改造与 2024 年的 VLDB 论文。公开规模是：有效指标 6 万+、大数据计算资源 19 万+ core、存储 25PB+、OLAP 2 万+ core/5.5PB、Iceberg 增量存储 20PB+来源。论文要解决的问题是"数万指标 × 数万策略，每个实验算数百指标，每天数百万 CPU 小时、数百 PB 网络流量"，传统 OLAP 的"扫描—聚合"扛不住。解法分四步：日志统一成曝光/指标/维度三张表（分析单元是指标分母，随机化单元是分流单位，后者必须不低于前者）；用与分流无关的哈希把分析单元切 1024 个 segment 并行，再用独立哈希把随机化单元切 1024 个 bucket，每桶算一个指标值，等价于 1024 次独立重复，用于估方差/协方差；把 analysis-unit-id 编码到 segment 内固定位置，指标值用 Bit-Sliced Index + Roaring Bitmap 表示，加法/比较变成 bitmap 的 XOR/AND/OR，零值被压缩；scorecard 与 CUPED 用 Spark 预计算，即席下钻用 ClickHouse来源。论文抽样 5890 个指标，其中 3979 个值域基数 ≤100，这正是 BSI 成立的前提。

代价同样清楚：BSI 只适合非负数值、固定查询范式；1024 桶对极小流量实验不够稳；Spark 预计算意味着"今天看昨天"；湖仓本身还有元数据与小文件成本——腾讯自己列过 2 万实验 ID、180 万分区、HDFS 8 亿 metadata 上限、Merge Into 写倾斜这些坑。湖仓改造的收益是：20PB 历史数据迁移，计算核时优化 69.4%、节省约 20 万核时/天，存储优化约 100PB，年化降本约 3800 万元，p99 耗时降 70%。这些是官方自述，未见第三方复核，但方向与论文一致。

分流侧最硬的证据是 2019 年申请、2021 年授权的专利 CN110830234B：每个实验有各自的哈希种子，对用户标识哈希后归一化映射到全流量区间，每个对照实验按"流量比例 + 起点"划分子区间，流量比例可以随时间变化来源。它解释了一个常被忽略的工程点："按比例分流"不是简单取模，而是"归一化 + 区间命中 + 独立盐值"——独立盐值保证正交，归一化保证均匀，区间起点保证扩量时老用户不跳组。ABetterChoice 把上层结构写得更清楚：Global Domain → Domain → Multi-Layer Domain / Exclusive Layer；多层域共享流量池、层间用独立种子正交，互斥层内每个实验占不同桶段。

统计栈以 ABC 文档为样本：频率派双侧 CI + Delta Method 算相对变化，p 值 α 默认 5%，功效默认 80%；CUPED 默认开启，文档举例"原本 12 天，可能 5 天得出结论"；同时看 3 个以上指标时建议开 FDR；另有贝叶斯后验、SRM + AB Backtrack、HTE来源。更前沿的是 CIKM 2024 的 Soptima：把序贯检验与"淘汰型 MAB"结合，支持多臂与通用奖励类型，在保持 Type-I/II 错误率与最优臂识别保证的同时动态调流量。作者与腾讯流量调整专利的发明人重合，基本可判断是平台的技术输出，但论文未明写"腾讯生产环境"，只能标"作者关联腾讯，部署范围待核实"。

真正让腾讯区别于其他中国公司的是干扰推断。微信是全世界最适合研究网络干扰的场景之一：10 亿+ 用户、数千亿条边，每天数千个实验，其中数百个涉及网络干扰。当一个新功能只在部分用户生效，效果会通过分享、评论、共同好友扩散到对照组，传统 difference-in-means 估的是"部分暴露效应"，不是"全量上线效应"。腾讯的解法不是造完美社交图，而是承认只能拿到替代网络：保留过去 28 天有特定社交互动的边，把 10 亿节点、千亿边的图稀疏化，再用 pseudo-inverse 估计 TTE，并在 5000 万+ 用户的真实微信实验中把 pseudo-inverse 与均值差结合，用来检测干扰是否存在来源。KDD 2025 的后续工作进一步利用用户对之间的二元数据构造 dyadic-robust t 统计量，并给出子采样、实验前分层随机化、实验后用户级+二元级控制变量等工程手段来源。取舍很清楚：Bernoulli 简单、实验多、流量复用高，但强干扰下偏；Cluster 减偏，但簇内相关放大方差；饱和设计能估溢出，但要专门流量结构。微信选的是"日常 Bernoulli + 事后检测/校正，重点实验用 cluster/双边"，比 Meta 的"cluster + network exposure"更偏低成本、可规模化。

最后一句判断：腾讯不是没有能力，而是能力被组织边界切碎了。论文/专利水平不低，但腾讯云找不到通用 A/B SKU——这不是技术问题，是"谁为跨 BG 的统一买单"的组织问题。

4.5 美团 / 滴滴 / 百度#

把这三家放在一起，不是因为相似，而是因为它们演示了同一条规律：平台形态由实验单元与干扰结构决定，而不是由技术栈决定。美团的单元最杂（用户、订单、商家、AOI、城市、骑手），所以必须做配置模型与方法库；滴滴的单元最粗（城市、区域、30 分钟时间片），所以必须做时空设计与干扰建模；百度的单元最轻（设备、流量），所以工具可以做得简单。

美团公开的是"图灵（到家履约）+ Wedge（到店广告）+ BETA（分析引擎）"的联邦，没有覆盖全公司的统一平台名。最值得研究的是 BETA 的定位：它把实验设计、配置、流量分配、数据生产与实验分析解耦，分析引擎只依赖标准化实验数据集（含单元、分组方法、周期、指标元数据）来源。流水线固定为：数据可靠性验证（同质性、SRM、样本量）→ 预处理（3σ/IQR 异常值）→ 效应估计（差值、DID、回归）→ 方差估计（Delta/Bootstrap/聚类调整 + CUPED）→ P 值 → 报告。治理上有一条极硬的规则：每种显著性检验方法必须经过 AA 模拟验证才能上线，分组支持"不同质时系统重分组，最多 5 次"。

几个数字值得记住。CAR（协变量自适应分组）在样本少于 40 时，完全随机的不同质比例可超 6%，CAR 可稳定控制在 5% 以下，官方称至少 10 个样本也能取得有效同质性。CUPED 在合适场景下方差可降约 50%，并针对比率型指标（如人均完成单量 = 订单量/完单用户数）提出二元同系数 CUPED。Switchback 的典型设计是"14 天里随机 7 天实验、7 天对照"，彻底消除同城两组间的空间溢出；配对轮转把城市切成两个相似半城，每天随机一个做实验、另一个做对照，用"半城交界处轻微溢出"换"消除天与天差异"；随机饱和设计则给每簇随机分配不同实验组比例，利用"高饱和簇对对照组溢出更强"识别真实效应与溢出效应。

美团公开的最有价值的不是方法，而是一个反例：分析单元比分流单元更细、却用错方差公式时，真实无提升的实验被误判"显著有效"的概率接近 50%。这句话应该贴在每个自建平台的评审室里——它不是统计学的边角问题，而是会直接导致错误上线的工程问题。

滴滴的 Apollo 平台公开规模是 6000+ 并行实验/周（2020 年口径），支持在线与离线实验，分组有随机与时间片，分析覆盖基础/率/均值/留存指标，手段含均值检验、VCM、Bootstrap来源。它的特色是分组算法从 CR 到 RR 再到 Adaptive（CAR）的演进：

分组方法	组间最大差异	机制
CR（完全随机）	可达 14% 以上	一次哈希取模，小样本不稳定
RR（重随机）	可控制在 2.7% 以下	反复重跑取最优，用算力换质量
Adaptive（CAR）	95% 情况下 0.8% 以下	逐样本分配，兼顾配额与指标分布

这组数字来自 1 万司机、7 日 GMV/在线时长/全兼职、每种方法跑 400 次，不能外推，但量级足以说明"交易型平台的小样本分组不能只靠哈希"。代价是 CAR 破坏简单随机性，后续方差估计不能直接套两样本 t 检验；而且已按 CR 分流完的实验无法重新均衡——分组算法必须在分流前介入。

滴滴真正的方法论贡献是时空实验。其 AI Lab 参与、2024 年刊于 JRSS-B 的论文给出两种设计：时间交替（实验 14 天，策略每 30 分钟交替）与时空交替（把城市切成 r 个不重叠区域，每区独立随机初始策略，再在时间上交替；论文在 C5 把城市分成 17 个区域，同样 14 天、30 分钟一个时间单元）来源。方法论核心是 VCDP：允许潜在结果依赖本区策略历史、状态变量和邻居区策略，把 ATE 分解为直接效应（DE）与间接效应（IE）。论文的洞察很尖锐：双边市场里"策略通过改变司机分布间接影响邻近区"本身就是决策的一部分，只看总体效应，会把"抢了邻居的订单"误判为增长。

百度的公开材料最薄，但恰好演示了"能力嵌入产品"的形态。对外有三条线：峙一（2018-11-15 上线，官方称每年完成上千个上线评估、累计影响 PV 约 10 亿，可科学抽样、流量在线调整即时生效、按城市/性别/年龄生效）来源；百度统计 AB（同层互斥、跨层正交，但层数上限 5 个，分流主体只有设备 ID）；智能云 AI_REC AB（2024-05 上线，核心指标决策、辅助指标判断其他影响、功效默认 80%、显著性默认 95%，流量计算器"仅供参考"）来源。AI_REC 是这组里少见的公开定价：SaaS 基础套餐按 QPS 包年包月，5–20 QPS 为 1000 元/QPS/月，21–80 超出部分 700 元/QPS/月，官方示例 50 QPS ≈ 4.1 万元/月。

峙一的现状必须打问号：公告页 2026 年仍可访问，但搜索资源平台现行导航已看不到"峙一/功能实验室"入口，也没有停服公告。因此只能写"2018 年上线，2026 年是否仍在售/已下线待核实"，不能写"已停服"。百度还有一件专利值得注意：CN115391184B 把 A/B 流量各拆成至少两个子组、交叉配对出至少四对子组，做多次对比检验并做 P 值校正。这说明百度在"小样本、多比较"的统计设计上有积累，只是没有产品化到对外文档里。

4.6 快手 / 小红书 / B站 / 京东 / 网易 / 拼多多 / 携程 / 知乎#

这一组公司的公开材料呈现出清晰分工：内容社区讲方法，电商讲口径，实体交易讲分流算法，而拼多多什么都不讲。

快手把实验平台做成了"公司级指标计算底座"。公开材料几乎不讲实验设计 UI，全在讲怎么把 AB 报告算快：分流表 × 指标宽表按 UID 做 Colocate Join，单 Bucket 扫千万级数据先过滤约 95% 无效数据；Local Distinct Grouping Sets 把去重下推本地，代价是约 6 秒 Barrier；分流判定 UDF 从 Java 改 C++ Native 后，模板整体再快约 3 倍。规模是 5 FE + 2000 BE、10 万 CU、12 个逻辑计算组、单日扫描 40TB/千亿行、日均几十万任务，核心指标模板从 21 分钟压到最大 145 倍提速、资源消耗下降 72%来源。要提醒：145 倍是特定模板、特定优化组合下的最大值，不是任意查询的普遍提速；且这套优化成立的前提是"AB 模板长期稳定"，模板不稳定的公司抄不了。快手的分流是"按日志回放实验命中"的离线判定模式，好处是补数/回溯方便、分流逻辑可版本化，代价是分流结果要落表、配置变更后历史表要重算。统计方法几乎未公开。2026 年 8 月的 A/B Agent 是更值得关注的信号：分层经验树 + 实验树 + 护栏惩罚效用函数，论文称短视频电商推荐场景五轮演化后购物车 GMV +4.829%、GPM +4.677%、所有护栏为正来源。这是论文宣称、单一场景，但它指出下一个瓶颈是"实验解读与下一轮策略生成"，而不是再快 10 倍。

小红书是八家里公开方法论最完整的。分流上，实验 SDK 内置在推荐服务里，定期拉配置、本地判定、本地打点，不是每请求调远程服务；代价是配置 staleness 与多版本 SDK 兼容。治理上，它把实验变更当线上变更管理：高峰期变更要审批，灰度支持服务维度与不同机房按比例，变更后用质量指标"打灯"——红灯强制卡点、绿灯自动生效、黄灯人工介入来源。这套机制的意义是把实验平台接进了发布系统，这是成熟度的重要标志。

小红书最有价值的分享是对"AA 不齐"的处理与自我警告。朴素做法是跑真实 AA 挑差异小的组，但要等 2–3 天、能试的组数有限；他们做回溯 AA（PreAA），用历史数据多次遍历分流、尝试不同哈希种子，生成多套虚拟分组让实验同学挑最均衡的一套。但分享者明确讲了三个坑：选组会带来样本偏倚（总是挑"好看"的分组，下周指标可能仍"好看"，但那是选择偏差）；PreAA 选组后不能用普通 t 检验，正确的显著性计算非常贵、工程上难落地；"平"太难，指标越多成功率从千分之一降到万分之一。他们的结论是"有了 CUPED 就不需要额外选组"。还有一个非常诚实的数字：留存类指标 LT28（28 天内来访天数）假阳率一度超过 50%，消费类指标通常只有 10% 左右，难提升的指标甚至可能接近 70%。

解法不是把单个实验做大，而是"打包结算"：层域模型隔离约 10% 纯净流量，在其中圈垂直打通层，让这批用户吃到每一个推荐策略，另有"推全层"可无视预留流量；父子实验支持二层打包；再用 LR + Reverse 保留一小股反转流量，大盘异动时遍历反转实验定位"是谁拖累的"，同时用正向/反向两个观察点是否一致来测算假阳率。代价是流量切碎、单策略样本变少、打包周期长（双月）、策略累积可能把小误判叠成大偏差。数据侧则是千亿日志、每天上千活跃实验、5 分钟 + user_id 粒度的 DWS、P90 < 10 秒、资源为旧实时方案的 36%、实时/离线差异 <1%。

B站是"零件齐全、整机不可见"。2023 年 12 月公开的专利给出"层—组—任务"三级模型：预先配置实验层与每层实验组，配置若干 AB 测试任务并记录任务与实验组的关联，把用户分流到实验分组后按关联找目标任务执行。这解决的是多业务复用同一批流量，任务不直接绑流量而绑"层里的组"。GitHub 上确有 bilibili/abtest 仓库（Apache-2.0，描述为 C++/Java/Go 的分层实验框架），但创建与最后 push 都是 2019-11-13、约 14 stars、README 只有一行标题来源，基本可判定是早期骨架而非生产平台开源。数据底座"北极星"倒是很实：北极星、标签画像、AB 实验人群包都基于 ClickHouse 的 RoaringBitMap，日行为数据数千亿行、日增约 10TB，事件分析平均 2.77 秒、漏斗 0.58 秒、整体平均 3.4 秒；属性字典服务压测支持 50 万 QPS来源。这意味着 B站实验平台不是孤岛，但上游依赖很重。

京东的强项是"实验数据工程"，不是统计创新。京东零售当天在线实验量可达万级，主要矛盾是数据链路生产效率与口径一致性。它把数据要素拆成四块：分流维表（用维表关联事实表而非只靠埋点，且不能用 Inner Join，否则破坏两组同质可比）、单实验单算、累计统计（既累计行为也累计进组，因为实验组转化更好会导致次日进组用户因复购差异偏移）、指标继承（事实表、过滤逻辑、聚合方式必须同源）来源。工程上用"数据编织"把指标平台和实验平台接起来，实验订阅指标后系统自动完成关联、变宽/变高、当天/累计策略分裂、统计量计算，多个实验路由到同一逻辑表时用"实验 ID 列表"把 N 个任务合并成 1 个。公开进展是 60% 的指标可以通过实验订阅驱动自动计算，交付效率从周级提升到天级。这个 60% 比"支持多少种实验类型"更有含金量。

京东对外还有过一个"增长实验室"，技术文章把分流讲得很细：uuid + 实验种子 → 强一致哈希 → 取模 100 → 0–99 桶位，1 桶 = 1% 流量；调整版本比例时先识别"比例减少"的版本，从其桶位区间最右侧拆出需要让出的桶，再从左到右分配给"比例新增"的版本。文章举的反例很典型：VA=10%、VB=10%、VC=80% 扩到 20/20/60 时，若简单重划，原本在 VB 的 11–20 号桶用户会被挪到 VA，发生跳组来源。但截至 2026-10-18，京东云产品页 /cn/products/growth-lab 已无法访问，站内也没有明确在售页面，因此既不能断言停服，也不能断言在售，只能写"公开入口与报价不可得，生命周期待核实"。

网易同时公开了电商与内容两套平台，方法互补。严选把 AB 拆成六阶段，解法是"实验前—实验中—实验后"三段式：实验前给最小样本量预估，实验中把分流逻辑从业务代码接管到平台、埋点自动化、指标口径统一，实验后报表自动化并给显著性/置信区间。统计细节很实在：最小样本量用 Z 分布公式，1%→2% 约需 2000+ 样本，1.1%→1.2% 约需 17 万样本；显著性标准是 p<0.05 且功效 ≥80%；分流借鉴 Google 流量模型，同层互斥、跨层正交。业务结果是支撑数千次实验、有效决策比例超 40%、平均周期缩短到 3–7 天来源。云音乐"天秤"则是 SRM 治理的教科书：SRM 归因分五类（分流算法不随机、流量分配不科学、实验前用户状态偏差、策略/漏洞影响留存、日志漏报错报、风控误伤），对比 murmurhash、md5、bkd 后选 murmurhash，把单次分流不均匀概率控制在 5% 以内；推荐等比例分配与等比例扩缩量，因为两组比例相等时指标方差最小；提供天级/小时级样本监控，任一维度卡方检验不通过就高亮告警。统计上还有 Bonferroni（检测次数少时）与 BH（检测次数多时）、CUPED、共享对照组来源。这套材料的价值在于它把很多平台只写在文档里的东西讲到了实现细节和踩坑。

拼多多是纯黑箱。截至 2026-10-18，没有找到官方工程博客、技术公众号、大会演讲、产品名、开源项目或可核实的架构与规模数字。唯一能做的推断是：其业务以商品、价格、活动、推荐为核心，实验单元很可能不只用户，还包括商品/店铺/活动，组织风格偏"强运营 + 快速迭代"。但这是从业务形态反推，没有任何公开材料能证明。在竞品分析里，拼多多应标为"黑箱"而不是"落后"。

携程的材料跨度很大，恰好展示了一代人的演进。2017 年机票 ABT 是"端上拉配置 + 设备号取模 100 + ABCD 做 AA"：App 启动时公共框架拉取所有线上试验号和版本存本地，进入频道触发本地实验号并打 trace 埋点；分流用"设备号 + 试验号 + 随机数"组成 N 位数对 100 取模，按 10:70:10:10 分 ABCD，A 为兜底；AA 设四版，ACD 为旧版、B 为新版，C/D 各为 B 的一半，先比 C/D 再比 B 与 ACD；经验法则是单页面同时在线实验不超过 7 个（Magic Number 7）；分析靠 CR、收益与趋势图，p 值"一年也没怎么用"来源。这段材料今天看很"土"，但真实反映了当时的水平，问题也清楚：随机数参与哈希可能破坏同设备稳定进组、端上拉全量配置有体积与版本兼容隐患、没有 SRM 与 CUPED。

2025 年火车票团队面对的是完全不同的问题：实验单元不是用户，而是酒店商户。酒店数量不超过 100 万，销量/曝光马太效应明显，同地区酒店用户流量交叉严重。直接哈希有三个问题：高单价酒店可能集中到实验组导致 GMV 结论错误；非用户实体数量少，实验期间分组要固定且实验前后要相似；同一用户可能同时看到实验组和对照组商户。解法是三个可插拔模块：分区随机抽样（按类目/价格段交叉分层，层内按指标排序等距分桶）、贪心交换（只在同一交换桶内枚举样本对，计算"最大相对差异"下降量）、图贪心分流（用历史"用户—商户"曝光构建加权图，Louvain 做社区发现，把高频共现商户打包成新分流单位，再对新单位贪心交换，最后还原到原始商户）。实证结果：分流通过率从先验随机的"需重试 200+ 次"提升到图贪心的 90%+，模块度从约 0 提升到约 0.3，UV 交叉率从 60% 降到 40%来源。注意 40% 仍然不低——图算法只是"降低"不是"消除"。

知乎的公开材料在数据层：AB2.0 早期基于 ClickHouse 预计算，痛点是预计算资源消耗大、多表 Join 能力有限、已有指标无法复用；新架构让 Hive 只负责进组用户落表与指标加工，通过 Broker/Stream Load 写入 Doris，平台直接对 Doris 做即席查询；表设计用前缀索引、zstd 压缩、Colocate Join、AGG 模型；功能上用 bitmap 做滑动窗口、指标拆解、SQL 合并、缓存加速。效果是查询耗时降低 35%、P99 降幅 60%，进组用户表达百亿级来源。分流与统计仍然模糊。

八家的公开成熟度可以排一张表，但必须强调：这是"公开可验证信息"的成熟度，不是能力排名。

公司	公开平台名	架构公开	统计公开	规模证据	公开成熟度
小红书	小红书实验平台	SDK 分流 + 数据链路详细	PreAA/CUPED/反转/假阳率	千亿日志/千级实验	★★★★★
快手	未公开专名	指标计算层很详细	少	2000 节点/10 万核	★★★★☆
京东	内部未公开；增长实验室状态待核实	数据编织 + 桶位/流量保护	统计量计算，缺检验细节	万级实验/日	★★★★☆
网易	严选平台；云音乐天秤	两套都较详细	p 值/功效/CUPED/多重检验/SRM	严选数千实验	★★★★☆
携程	ABT/UBT；统一平台名未公开	端上分流 + 图分流	t 检验/AA/最大相对差异	机票每周数十实验	★★★☆☆
知乎	AB2.0	数据层详细	少	百亿级进组表	★★★☆☆
B站	未公开	分层专利 + 北极星底座	少	千亿行/日	★★☆☆☆
拼多多	未公开	无	无	无	★☆☆☆☆

这张表最重要的结论不是排名，而是内容社区与电商的实验平台不是同一套产品改个皮肤。内容社区的对象是"人"，样本大、哈希分流够用，难点在指标不敏感（留存、时长）与实验间干扰，所以要 CUPED、打包、反转、长期 holdout；电商的对象经常是"商品/商户/酒店"，样本小、特征集中、实体关联强，哈希会不均衡、会流量交叉，难点在预分流、实体打包、口径一致，所以要分层抽样、贪心交换、图社区发现、数据编织。把小红书的"打包 + 反转"直接搬到交易型业务，大概率水土不服。

4.7 横向对比：组织、架构、统计、场景#

把前面所有材料压到四个维度上，能看到单看任何一家都看不到的规律。

组织：三种"统一"，多数公司只做到第一种。 统一可以发生在入口层（一个控制台）、元数据层（一套实验/指标/分流定义）、口径层（指标分子分母与去重逻辑一致）。字节做到了元数据层，所以能内外融合、按 DDD 拆 8 个子域；腾讯停在入口层之下、BG 层之上，TAB/X/天秤各自实现分流、指标、权限，跨平台实验的全局互斥与流量预算很难做；阿里连入口层都没统一；美团最接近"方法统一、入口分散"，BETA 作为方法中心被多平台调用。一个可检验的判断是：当公司出现第二个实验平台时，真正的分水岭不是"要不要合并"，而是"指标定义归谁"。指标定义不统一，合并只会得到"统一登录页 + 各自后台"。

架构：分流求值位置分四类，各有不可替代的场景。 端上本地求值（字节客户端 SDK、小红书、天猫 AirTrack）解决开屏/弱网/时延，代价是配置 staleness 与多版本兼容；服务端 SDK 本地求值（字节、PAI ABTest、PAI-Rec）解决低延迟与一致性，代价是元数据刷新延迟与"进组不出组"要外部存储；lib 嵌入（阿里妈妈 Tesla）接入简单、不增加运维，代价是升级跟业务发版、跨语言差、故障隔离弱；仓库/离线回表（快手、ABC、京东、知乎）指标口径与分组解耦、补数方便，代价是存储与重算成本。桶数也不统一：Tesla 100、DataTester 1000、AirTrack 10000、微信 1024、PAI-Rec 100、京东 100。桶数不是越多越好——它要和最小可实验流量、样本量、计算成本一起定，且一旦定下不能改。

统计：底座高度收敛，加码方向分叉。 收敛的是随机化 + 假设检验 + 置信区间 + MDE/功效 + SRM/AA + 多重比较，几乎所有公开平台都有。分叉在方差缩减与干扰处理：

能力	公开确认在用的公司	备注
CUPED	字节（内部）、美团、腾讯、滴滴（论文侧）、网易云音乐、小红书	已近事实标准；比率指标需 Delta 或二元 CUPED
模型化方差缩减	字节 ITR、快手 CUPAC、美团二元 CUPED	均缺完整 A/A 校准，应默认关闭后按指标开放
序贯检验	腾讯 Soptima（论文）、ABC（文档）；其余多数未公开	中国平台公开度显著低于欧美
贝叶斯	腾讯 ABC（可选）、字节 MAB（贝叶斯优化，非 A/B 推断）	"支持贝叶斯"必须限定模块与默认值
SRM 产品化	网易云音乐、腾讯 ABC、美团	多数平台只有"命中诊断"，不是 SRM
多重比较	网易（Bonferroni/BH）、美团（自动）、百度（专利子组交叉校正）	公开实现细节的只有网易
干扰/聚类	字节、腾讯、美团、滴滴、快手	中国公司在此明显领先欧美公开材料

最后一行值得展开：中国公司对干涉效应的投入，明显高于欧美公开材料。原因不神秘——微信/抖音是社交网络，美团/滴滴是双边市场，快手是社交+内容，这些业务形态逼着平台处理 SUTVA 失效。字节把干涉分成"直接干涉（社交溢出，低估效应）"与"间接干涉（资源竞争，高估效应）"，分别用社群聚类与 DQ 处理；抖音私信案例中用户级分流的跨组私信占 50%，社群分流后降到 1%；高清视频案例中真实效应 -0.5%，朴素估计 +2.95%，DQ 估计 -0.49%。这些数字比任何"支持聚类分流"的功能描述都更有说服力。

场景：随机化单元是一张必须提前填的表。 把六类场景压成矩阵，基本可以作为自建平台的需求输入。

场景	典型单元	主要干扰	首选设计	常见错误
内容推荐	用户/设备	推荐链路层层叠加、策略互相稀释	用户级 + CUPED + 打包/反转	用单实验 p 值判断低灵敏度指标
社交	用户/社群	分享、共同好友、内容扩散	社群聚类 + 父子实验 + 事后检测	用户级随机后直接外推全量
双边市场	城市/区域/时间片	供给重分配、跨区溢出	switchback / 时空交替 / VCDP	按用户随机做派单或定价
交易/履约	城市/AOI/站点/订单	骑手跨区、库存共享、公平性	CAR + 半城配对 + 饱和设计	分析单元细于分流单元却用 t 检验
广告竞价	广告主/计划/时间片	竞价均衡、预算耦合	广告主级抽样 + 分层 + PSM/CUPED	用户级 A/B 做出价实验
游戏经济	服务器/赛季/匹配池	交易行、公会、通胀	cluster / switchback + 长期护栏	用户级随机 + 只看 7 日留存

这张表也解释了为什么"买一个通用 SaaS"很难满足交易型公司：商业产品的默认假设是"用户级随机 + 独立个体 + 固定 horizon"，而这张表里超过一半的场景不满足这个假设。

4.8 对中国企业的启示与信息缺口#

把中国经验压缩成可执行的原则，大约是八条。它们不是口号，每一条都对应一个会被踩到的坑。

第一，先建"实验单元注册表"，再谈分流。 平台必须能声明：分流单元是什么、分析单元是什么、两者是否一致、不一致时用什么方差（Delta/聚类/Bootstrap）、干扰边界在哪（同城？同商圈？同商家？）。美团"分析单元细于分流单元、假阳性接近 50%"的反例说明，这不是学术问题，而是会直接导致错误上线的工程问题。注册表还应固定"分流键一旦选定，实验中途不能换"。

第二，身份图是超级 App 的地基。 一个用户可能从 Feed、搜索、直播间、小程序、Push 五个入口进入同一实验，设备 ID、账号 ID、手机号、OpenID 的映射还不一致。字节的 decision_id/track_id 分离是这个问题的一个优雅解，但代价是映射服务本身要成为高可用基础设施。对 DAU 千万级的公司，最划算的投资不是"支持更多实验类型"，而是把身份图与单元层级做成平台级元数据。

第三，指标语义层要先于实验平台。 微信的 BSI、快手的 Doris 模板、京东的数据编织、美团的 BETA，本质上都在解决同一件事：让"指标口径、聚合层级、方差计算"成为平台能力，而不是每个实验者写 SQL。京东 60% 指标自动计算、网易严选的指标注册、小红书的指标结构化，都是这条路上的里程碑。没有指标语义层，实验报告就是一次性 SQL 的堆叠。

第四，分流必须是纯函数、可复现、带版本。 hash(unit_id + experiment_salt + layer_salt) % buckets 应作为契约，salt 与配置版本一起存档。小红书的 UDF 复算、京东的"uuid + 种子 + 取模 100"都是这个思路。衍生要求是：扩量时只从缩量组/对照组拿桶，绝不碰其他实验组已占用的桶——京东的"流量保护"是低成本高收益的设计，代价是区间碎片化，需要控制单实验调整次数。

第五，统计门禁要产品化，而不是写进规范。 具体是四件事：新方法上线前必须跑 AA 模拟验证（美团）；SRM 自动检测并按维度告警（网易云音乐）；多指标/多组自动多重比较修正（美团、网易）；护栏指标默认继承、显著变化才告警（字节"必看指标"）。这四件事的收益远大于"再做一个酷炫的报表页"，因为它们把统计素养的要求从"每个实验者"转移到了"平台默认值"。

第六，干扰工具箱按业务形态选，不要一律聚类。 社交网络优先"社群聚类 + 父子实验"；双边市场优先"cluster/switchback + DQ 或 DID"；地理业务优先"区域聚类 + 半城 DID/合成控制"；广告优先"竞争隔离 + 广告主级抽样"。聚类不免费：有效样本变少、簇内相关放大方差、残余溢出仍在。务实顺序是先小流量做"用户级 vs 社群级"父子实验，比较两套估计，差异不显著就继续用户级。

第七，实时性要分层。 合理分层是 L0 曝光/分流毫秒级（SDK 本地求值）、L1 核心指标秒–分钟级（Flink/Fluss/Doris 微批）、L2 归因指标小时级（湖流一体、离线回刷）、L3 实验结论天级。淘天通天塔的教训是实时 AB 的瓶颈在"排序 + 双流 Join + 24 小时归因"的 100TB State，不在 SQL 算得慢；快手的教训是千亿行级别的自建平台，真正的工作量在数据库内核与元数据治理，不在实验 UI。中小团队优先"分钟级微批 + 离线回刷"。

第八，合规要前置到实验设计。 个保法第 24 条禁止对个人在交易价格等交易条件上实行不合理差别待遇，算法推荐管理规定第 21 条同样禁止价格歧视；个性化定价、差别权益、敏感人群实验应先做 PIPIA 与法务评审，价格实验要留"非不合理差别待遇"证据，推荐实验保留非个性化对照组。合规不只改文案，它会改变随机化单元与识别策略。

另有一条组织经验值得单独写：平台 KPI 不应只是实验数量，而应是"可信实验占比"与"问题到结论的周期"。美团的"三方分工"（数科定方法与模板、数仓保指标口径、工程建管道）之所以可复制，是因为它明确了"谁对实验可信度负责"；腾讯的联邦式之所以代价高，是因为每个 BG 都要自己回答这个问题。没有嵌入式数据科学家，平台会退化成"分桶工具"。

信息缺口需要被当成结论的一部分，而不是脚注。

缺口	具体缺什么	影响	建议核实方式
拼多多	平台名、架构、分流、统计、规模，全部	无法做有效对标	行业访谈、招聘 JD、专利检索
字节对外统计	CUPED/ITR、SRM、多重比较、Holdout 是否交付	直接影响采购估值与 POC	厂商演示 + 合同功能清单
阿里 Tesla/AirTrack	2016 年后是否改名、是否仍用 lib	无法判断广告实验当前形态	阿里妈妈技术号、专利续期、JD
腾讯天秤/TAB 边界	天秤是否仍存在；TAB 是否真"一站式"	影响对"联邦程度"的判断	腾讯招聘 JD、内部技术号
美团规模	实验数量、DAU 覆盖、平台用户数	只能判断方法强弱	白皮书后续篇目、QCon
百度内部平台	平台名、分流、统计方法	只能确认"有实践"	搜索团队论文、专利、校招 JD
B站/知乎/携程	分流服务、统计引擎、实验规模	只看到"零件"	专利全文、技术号、Doris 案例
京东增长实验室	是否在售/停服/改名	对外状态不确定，不能写报价	京东云销售确认、页面快照
快手统计	检验类型、CUPED/序贯、SRM	只能判断"指标计算强"	后续分享、A/B Agent 论文附录

如果要把这些缺口转成一次尽调，最有效的八个问题大概是：CUPED 是默认开启还是可选？比率指标怎么处理？SRM 是自动检测还是只做命中诊断？多重比较用什么方法、什么条件触发？序贯检验的 alpha 如何分配？Holdout 的流量口径与统计方法是什么？私有化与 SaaS 的功能差异清单在哪？分流服务的 SLA 与降级策略是什么？这八个问题，比任何功能对比表都更能区分"有平台"和"有 PPT"。

最后回到一个判断：中国经验里最值得抄的，不是某个架构（BSI、Doris、Fluss 都强依赖各自的业务形态与团队规模），而是把统计可信度做成产品默认值的制度——必看指标自动继承、AA 不通过不许上线、SRM 异常自动标红、扩量只动自己的桶。这些设计不炫技，但它们决定了一个实验平台在第三年还能不能被业务信任。

参考来源