1. 项目概述这不是一个“框架”而是一套被工程化锤炼过的实验决策系统你点开这篇文章大概率是冲着“Uber用的统计实验框架”这个标题来的。但我要先泼一盆冷水Uber官方从未发布过一个叫“OED Framework”的开源框架也没有把它打包成 pip install oed 这样的东西。它本质上不是一套代码库而是一套在超大规模业务场景中反复验证、持续迭代的实验设计方法论 工程实现范式 决策支持流程。它的核心缩写 OED全称是 Optimal Experimental Design最优实验设计这本身就是一个统计学里存在了几十年的老概念——但 Uber 把它从教科书和论文里拽了出来塞进每天要跑上千个 AB 实验的生产环境里硬生生给它焊上了数据管道、模型服务、监控告警和产品看板。关键词里写的“Artificial Intelligence”在这里不是指大模型或深度学习而是指整个实验体系具备了“智能决策”的能力它能自动评估哪个实验设计更可能得出可靠结论能预判样本量是否足够甚至能在实验进行中动态建议是否提前终止。我做过三年 AB 实验平台的后端开发也参与过两个大型推荐系统的实验治理实测下来这套思路最颠覆的地方在于它把“做实验”这件事从产品经理拍脑袋决定“我们试试这个按钮颜色”升级成了数据科学家和工程师共同维护的一条“决策流水线”。它适合三类人第一类是正在搭建公司级实验平台的工程师你需要理解 Uber 为什么放弃传统固定样本量的 t 检验转而拥抱贝叶斯框架第二类是数据科学家尤其是负责增长、推荐、搜索等强实验驱动方向的你需要知道如何把一个业务假设翻译成可计算的 OED 目标函数第三类是技术型产品经理如果你需要向老板解释“为什么这个实验要跑 28 天而不是 7 天”这篇文章里的参数推导过程就是你的弹药库。它不教你写 Pyro 代码但它会告诉你为什么 Uber 的工程师在写 Pyro 模型时第一行永远是定义先验分布而不是写 likelihood。2. 核心设计逻辑为什么 Uber 放弃了“p 值”选择了“信息增益”2.1 传统 AB 实验的三大硬伤Uber 全都撞上了在 Uber 的场景里一次典型的实验可能涉及数千万用户覆盖全球几十个市场指标维度包括订单完成率、司机接单时长、乘客取消率、客单价、甚至司机收入波动率。在这种尺度下传统频率学派的 AB 实验方法比如双样本 t 检验暴露出三个无法回避的致命缺陷而这些缺陷在中小公司可能只是“有点麻烦”在 Uber 就是“每天烧掉上百万美金”。第一个硬伤是样本量预估的严重失真。传统方法依赖一个关键假设效应量effect size是已知且固定的。比如你预计新算法能把转化率从 5% 提升到 5.2%提升 0.2 个百分点。但现实是这个 0.2% 是你基于历史数据的粗略估计真实值可能在 0.05% 到 0.5% 之间剧烈波动。当你用 0.2% 去计算所需样本量结果可能是 100 万用户但如果真实效应只有 0.05%那这 100 万用户跑完统计功效statistical power可能连 30% 都不到——相当于扔了 100 万用户的实验流量却大概率得不出任何有把握的结论。我亲眼见过一个同城货运团队因为沿用旧的样本量计算器连续三个月的“优化算法”实验全部宣告无效最后回溯发现他们预设的效应量比实际高出了整整 4 倍。第二个硬伤是决策时机的僵化与滞后。传统方法要求你“预先设定显著性水平α0.05和统计功效1-β0.8然后一次性收集完所有样本最后看 p 值”。这在 Uber 的节奏里是灾难性的。一个新功能上线市场反馈瞬息万变竞争对手可能下周就推出类似功能。你不可能告诉 CEO“老板这个实验还要再跑 17 天虽然今天数据看起来很好但我们得等到截止日才能下结论。” 更糟的是如果实验中期数据已经显示新方案明显更差比如订单取消率飙升 20%你也不能立刻叫停——因为提前看数据会污染 p 值导致假阳性风险失控。这种“等死式”的决策机制在快节奏的业务环境中等于慢性自杀。第三个硬伤是多目标权衡的彻底失效。一个实验从来不止看一个指标。比如优化乘客端的匹配算法你既希望提升“匹配成功率”又不希望“司机平均等待时长”增加太多更不能让“司机投诉率”上升。传统方法要么强行选一个主指标要么用加权求和这种粗糙方式根本无法量化“牺牲 1% 的匹配成功率换来司机等待时长下降 5%这个 trade-off 是否值得”。它缺乏一个统一的、可计算的“价值函数”。提示这三个问题正是 Uber 构建 OED 系统的原始驱动力。它不是为了炫技而是被业务规模和速度逼出来的生存方案。2.2 OED 的破局点用“信息”替代“显著性”用“贝叶斯”替代“频率学派”OED 的核心思想非常朴素实验的终极目的不是证明一个假设“为真”或“为假”而是最大化我们从这次实验中获得的、关于关键业务参数的“信息量”。这个“信息量”在数学上被精确定义为“后验分布相对于先验分布的熵减”也就是 Kullback-Leibler 散度KL divergence。简单说就是实验结束后我们对“真实效应量”的不确定性比实验开始前减少了多少。这个视角的转换带来了质的飞跃。首先它天然兼容不确定性。你的先验分布比如对转化率提升幅度的信念可以是一个宽泛的 Beta 分布它本身就表达了“我们不确定但大致认为在 0% 到 0.5% 之间”。OED 的优化目标就是选择那个能最大程度“压缩”这个分布的实验设计——比如是给每个用户发 3 个不同版本的推送还是只发 2 个是把 80% 的流量分给 A 组20% 给 B 组还是 50/50这些选择都可以被翻译成一个数学上的优化问题在总流量预算约束下最大化预期 KL 散度。其次它让“提前终止”变得合情合理。在贝叶斯框架下你每看到一批新数据就更新一次后验分布。当后验分布已经足够“尖锐”比如95% 的概率密度都集中在“效应量 0.1%”这个区间而你的业务阈值是 0.05%那你就可以自信地说“这个实验已经提供了足够强的证据新方案优于旧方案。” 这不需要任何“p 值校正”因为每一次更新都是基于当前所有已知信息的最优推断。这正是 Uber 工程师所说的“sequential analysis”序贯分析——决策是流动的不是静止的。最后它完美解决了多目标问题。你可以为每一个关键指标定义一个“效用函数”utility function。比如匹配成功率每提升 0.1%效用 1司机等待时长每增加 1 秒效用 -0.5投诉率每上升 0.01%效用 -2。然后OED 的优化目标就变成了最大化所有指标效用的加权期望值。这个期望值是通过对后验联合分布进行积分计算出来的。它不再是拍脑袋的权重而是基于数据和业务目标的、可计算、可审计的决策依据。2.3 为什么是 Pyro一个被低估的工程选择原文提到“OED enables the scoring and optimization experiments using Pyro’s probabilistic programming model”这很容易让人误解为“Uber 在用 Pyro 写生产代码”。实则不然。Pyro 是 Uber 团队在研究、验证和原型设计阶段的首选工具原因有三且都直指工程落地的核心痛点。第一表达力与可读性的极致平衡。Pyro 的核心是“概率程序”probabilistic program它允许你用近乎自然语言的 Python 代码清晰地描述一个复杂的生成过程。比如定义一个关于“用户点击行为”的模型你可以这样写def model(user_features, treatment_assignment): # 先验基础点击率 base_rate pyro.sample(base_rate, dist.Beta(2.0, 8.0)) # 先验处理效应treatment effect effect pyro.sample(effect, dist.Normal(0.0, 0.1)) # 似然观测到的点击0 或 1 with pyro.plate(data, len(user_features)): prob base_rate effect * treatment_assignment pyro.sample(obs, dist.Bernoulli(prob), obsclicks)这段代码任何一个懂 Python 和基本统计概念的工程师都能看懂它在做什么它假设用户点击率有一个基础值base_rate而实验处理treatment会在这个基础上叠加一个效应effect最终产生观测到的点击结果obs。这种“所见即所得”的建模方式极大地降低了跨职能沟通成本。数据科学家写模型工程师看代码就能理解业务逻辑产品经理也能参与讨论“这个 effect 的先验分布设得是否合理”。第二灵活的推理后端切换能力。Pyro 不是一个绑定死某个算法的黑盒。它背后是一个抽象的“推理引擎”inference engine接口。在研究阶段你可以用 MCMCMarkov Chain Monte Carlo做精确但慢的采样在需要快速迭代时可以无缝切换到 SVIStochastic Variational Inference用变分推断获得一个近似的、但计算极快的后验分布。这种灵活性让 Uber 的团队可以在“追求极致精度”和“满足实时决策需求”之间自由滑动。一个用于长期战略分析的 OED 模型可以用 MCMC 跑一整晚而一个用于实时实验监控的轻量级模型则用 SVI 在几秒内给出结果。第三与 PyTorch 生态的深度集成。这是最关键的工程优势。Uber 的整个数据基础设施从特征工程到模型训练大量使用 PyTorch。Pyro 基于 PyTorch 构建意味着它可以原生利用 PyTorch 的自动微分autograd、GPU 加速和分布式训练能力。当 OED 模型需要处理海量用户特征比如一个包含 1000 维的用户 embedding 向量时Pyro 可以直接调用 PyTorch 的torch.nn模块来构建一个神经网络作为“效应量预测器”然后把这个预测器嵌入到概率模型中。这种“概率模型 深度学习”的混合建模能力是很多传统统计软件如 R 的 rstan望尘莫及的。它让 OED 不再是一个孤立的统计模块而是能深度融入 Uber 整个 AI 工程栈的有机部分。注意在 Uber 的生产环境中最终部署的 OED 服务其核心计算逻辑很可能是用 C 重写的高性能版本或者编译成 ONNX 模型。Pyro 的角色是那个在实验室里反复打磨、验证、并最终输出“黄金标准”的“数字孪生”。3. 核心环节拆解从一个业务问题到一个可执行的 OED 方案3.1 场景还原为“动态定价”策略设计一场高置信度实验让我们把上面所有的理论放进一个真实的 Uber 业务场景里一步步走完从问题定义到方案落地的全过程。假设你是 Uber 动态定价团队的数据科学家老板给你一个任务“我们想测试一种新的 surge pricing高峰期加价算法它能根据更细粒度的供需预测动态调整加价倍数。我们需要知道这个新算法能否在保证司机收入的同时将乘客的‘放弃下单率’abandonment rate降低至少 0.3 个百分点。”这是一个典型的、充满挑战的实验需求。它有明确的业务目标降低放弃下单率 ≥0.3%但也有巨大的不确定性新算法的效果未知且不同城市、不同时段的效果差异巨大。现在我们用 OED 的思路来解构它。第一步定义“决策变量”与“响应变量”决策变量Design Variables这是你能主动控制的实验设置。在本例中它包括treatment_assignment: 用户被分配到新算法1还是旧算法0。geographic_granularity: 实验是在城市级别如“纽约市”还是更细的“区域网格”如“曼哈顿中城”进行这直接影响效果的异质性heterogeneity。temporal_granularity: 实验是全天候运行还是只在特定高峰时段如 17:00-20:00生效这关系到信号的强度。响应变量Response Variables这是你观测到的结果。核心是abandonment_rate放弃下单率但绝不能只看它。必须同时监控driver_earnings_per_trip司机每单收入和average_wait_time平均等待时长因为它们是关键的约束条件constraints。OED 要求你把所有相关变量都纳入同一个联合概率模型。第二步构建先验知识Prior Knowledge这是 OED 区别于传统方法的起点也是最容易被忽视的一步。你不能凭空写一个先验。你需要从历史数据中“萃取”。对于abandonment_rate的基线baseline你可以拉取过去 30 天、相同城市、相同时间段的历史数据拟合一个 Beta 分布。假设你得到Beta(α120, β3880)这意味着基线率的均值是 120/(1203880) ≈ 3.0%这与业务常识吻合。对于新算法的effect即对放弃下单率的影响你没有直接数据。但你可以借鉴类似功能的历史表现。比如去年上线的“ETA 预估优化”功能将放弃下单率降低了 0.15%。你可以据此设定一个相对保守的先验Normal(μ0.0015, σ0.001)即均值 0.15%标准差 0.1%表示你相信效果大概率在 0.05% 到 0.25% 之间。对于driver_earnings_per_trip你可能有更丰富的数据。你可以用一个LogNormal分布来建模因为它天然保证收入为正。第三步定义效用函数Utility Function与约束这才是体现业务智慧的地方。你不能只说“我们要最小化放弃下单率”。你需要量化“代价”。核心效用U_main (abandonment_rate_old - abandonment_rate_new) * 1000。这里乘以 1000 是为了放大数值便于后续优化。目标是最大化U_main。硬约束Hard Constraintdriver_earnings_per_trip_new driver_earnings_per_trip_old * 0.99。即司机收入不能低于旧算法的 99%。这是一个业务红线违反即失败。软约束Soft ConstraintU_wait max(0, average_wait_time_new - average_wait_time_old) * (-500)。如果等待时间变长会产生负效用但不像司机收入那样是硬性红线。最终的总效用U_total U_main U_wait而硬约束则通过在优化过程中对违反约束的实验设计施加一个巨大的惩罚项penalty term来实现。3.2 OED 优化一场在“信息”与“成本”之间的精密权衡现在我们有了一个清晰的数学问题在给定的总流量预算比如每天 100 万次订单请求下如何分配treatment_assignment、geographic_granularity和temporal_granularity使得E[U_total | data]总效用的后验期望值最大化这个问题的求解是整个 OED 系统最核心、也最消耗算力的环节。Uber 的工程师不会手动去解这个优化问题而是将其封装成一个可调用的服务。其内部流程大致如下1. 参数空间采样与模拟Simulation-based Optimization由于解析解几乎不可能OED 系统采用蒙特卡洛模拟。它会在决策变量的空间内随机采样出 N 个候选设计方案例如N1000。每个方案是一个元组(treatment_ratio0.5, geo_granularitycity, time_granularitypeak)。对于每一个候选方案系统会启动一个“虚拟实验”virtual experiment它使用你定义好的概率模型即前面写的 Pyro model结合你的先验分布生成大量模拟的“观测数据”synthetic data。比如模拟 10 万次订单根据模型计算出每次订单的abandonment_rate、driver_earnings等。然后系统会用这些模拟数据运行一次完整的贝叶斯推断比如用 SVI得到该方案下的后验分布P(effect | simulated_data)。最后系统计算这个后验分布下的E[U_total]即对所有可能的效应量进行加权平均。2. 信息增益的量化计算对于每一个候选方案系统不仅计算E[U_total]还计算其“信息增益”Information Gain即 KL 散度IG KL(P(effect | simulated_data) || P(effect))这个值衡量了该方案能让你对“真实效应量”的认知比实验前清晰多少。一个优秀的 OED 方案必须在E[U_total]和IG之间取得平衡。一个方案可能E[U_total]很高但IG很低意味着它虽然看起来收益大但实验后你依然对“为什么收益大”一无所知无法推广到其他场景。3. 多目标帕累托前沿Pareto Frontier最终系统不会只返回一个“最优”方案而是返回一个“帕累托前沿”Pareto frontier——一组互不支配的方案。一个方案 A “支配” 方案 B意味着 A 在E[U_total]上不小于 B且在IG上也不小于 B且至少有一项严格大于。前沿上的每一个点都代表了一种不同的权衡你可以选择一个IG极高、E[U_total]中等的方案用于深度探索也可以选择一个E[U_total]极高、IG中等的方案用于快速验证和上线。实操心得我在实际项目中发现最常被忽略的一步是“先验校准”。很多团队直接用一个Normal(0, 1)作为效应量的先验这在数学上是合法的但在业务上是灾难性的。它意味着你认为效应量有 95% 的概率在 -2 到 2 之间这完全脱离了现实。正确的做法是用历史实验的效应量分布去拟合一个先验。比如过去 100 个定价实验效应量的中位数是 0.12%标准差是 0.08%那么一个Normal(0.0012, 0.0008)的先验就合理得多。这个细节直接决定了 OED 推荐方案的可信度。3.3 生产环境集成OED 如何变成一个“活”的实验平台组件OED 的价值不在于它能算出一个漂亮的数字而在于它能无缝嵌入到 Uber 的实验工作流中。它的生产集成是一个典型的“三层架构”。第一层决策层Decision Layer这是面向产品经理和数据科学家的 UI。它不是一个命令行工具而是一个 Web 应用。当你创建一个新实验时UI 会引导你输入业务目标如“降低放弃下单率”和约束如“司机收入不低于 99%”。上传或选择历史数据用于自动拟合先验。设置总流量预算和实验周期。 然后点击“Generate Optimal Designs”UI 会展示帕累托前沿上的几个推荐方案并用直观的图表对比它们的E[U_total]、IG、预计所需天数和风险等级基于后验分布的不确定性。第二层计算层Computation Layer这是 OED 的心脏通常是一个 Kubernetes 集群上的微服务。它接收来自 UI 的请求调用底层的 Pyro 模型和优化器。为了应对高并发每天可能有数百个实验在同时设计这一层做了大量工程优化缓存Caching对常用的先验分布、模型结构进行缓存。如果两个实验的业务目标和约束高度相似系统可以直接复用之前计算过的部分结果而不是从头开始。异步队列Async Queue复杂的优化任务会被放入 Celery 或 Kafka 队列由后台 worker 执行。UI 端显示“正在计算中”用户可以去做别的事。资源隔离Resource Isolation每个优化任务被分配独立的 CPU/GPU 资源和内存限制防止一个耗尽资源的任务拖垮整个服务。第三层数据层Data Layer这是 OED 的基石它必须与 Uber 的核心数据仓库如 Hive/Presto和实时数据流如 Kafka深度打通。特征服务Feature StoreOED 模型需要的用户特征如用户历史下单频次、所在区域的实时供需比都来自统一的特征服务。这保证了实验设计所用的特征与线上模型所用的特征完全一致消除了“训练-推理不一致”train-serving skew。实验元数据Experiment Metadata每一次实验的配置、OED 推荐的方案、实际运行的流量分配、以及最终的后验分析报告都会被写入一个专门的实验元数据库。这不仅是审计的需要更是为未来的 OED 模型提供“反馈循环”——系统可以学习“哪些类型的先验更准确”从而不断改进自身的推荐能力。注意这个三层架构是 Uber 工程文化的一个缩影。它没有追求“大而全”的单体应用而是用松耦合的微服务将一个复杂的统计问题分解为可独立开发、测试、部署和扩展的组件。这也是为什么 OED 能在 Uber 这样规模的公司里真正落地而不是停留在论文里。4. 实操经验与避坑指南那些文档里永远不会写的真相4.1 常见问题速查表从“为什么算不出来”到“结果看不懂”问题现象可能原因排查与解决思路OED 优化耗时过长1小时1. 决策变量空间过大如同时优化 10 个粒度的地理划分2. 模拟数据量过大如单次模拟 1000 万条3. 先验分布过于宽泛导致后验更新缓慢解决方案- 使用“分层优化”先粗粒度城市级优化再在推荐的城市内对子区域进行精细化优化。- 将模拟数据量从 1000 万降至 10 万OED 的相对排序结果通常不受影响但速度提升百倍。- 用历史实验数据收紧先验例如将Normal(0, 1)改为Normal(0.001, 0.0005)。OED 推荐的方案上线后效果远低于预期1. 先验与现实严重脱节最常见2. 模型忽略了关键混杂因子confounder如天气、节假日、竞品活动3. “流量同质性”假设被打破OED 假设分配到 A/B 组的用户是可比的解决方案- 强制要求所有新实验必须提交一份“先验合理性说明”由资深数据科学家签字确认。- 在 Pyro 模型中显式加入weather_condition、is_holiday等协变量并为其设定合理的先验。- 在实验上线前用历史数据做一次“反事实检验”counterfactual check用旧算法的模型去预测新算法的流量看预测误差是否在可接受范围内。后验分布过于“平坦”信息增益IG极低1. 实验设计本身无法区分效应如A/B 组流量分配比例是 99%/1%信号太弱2. 观测指标噪声过大如放弃下单率受网络延迟等随机因素影响3. 模型设定错误如用了线性模型但真实关系是非线性的解决方案- OED 系统应内置一个“可检测性诊断”detectability diagnostic在推荐方案前先快速评估该方案在理想情况下的最大可能 IG。如果这个值就很低就直接提示“此实验设计不可行”。- 对高噪声指标改用更鲁棒的聚合方式例如不看单次订单的放弃率而看一个用户在 7 天内的放弃次数。多个指标的效用函数冲突优化结果不稳定1. 效用函数的量纲scale不一致如一个用百分比一个用美元2. 硬约束设置过于苛刻导致可行解空间为空解决方案- 所有效用函数必须归一化到 [0, 1] 区间。例如U_main min(1, (0.003 - effect) / 0.003)其中 0.003 是业务目标 0.3%。- 硬约束应设置为“软约束”并赋予一个随违反程度指数增长的惩罚项而不是简单的“0/1”开关。4.2 我踩过的三个深坑以及如何绕开它们坑一把 OED 当成“万能胶”试图用它解决所有实验问题我曾经接手过一个项目团队想用 OED 来优化一个全新的、从未上线过的“语音叫车”功能。他们满怀信心地定义了先验跑了 OED得到了一个看似完美的方案。结果实验上线后数据一片混乱。复盘才发现问题根本不在于统计方法而在于产品本身语音识别的错误率太高导致大量用户根本没发出有效指令abandonment_rate这个指标在此刻完全失去了业务意义。OED 再强大也无法在一个指标本身就不健康的土壤上开出花来。教训OED 是一个“决策增强”decision augmentation工具不是“问题定义”problem definition工具。在启动 OED 之前必须确保你的业务指标是稳定、可靠、且与核心目标强相关的。一个简单的检查清单是这个指标在过去 30 天内是否有超过 5% 的天数出现数据缺失或异常尖峰如果有先解决数据问题再谈实验设计。坑二过度追求“最优”忽略了工程落地的复杂性OED 的数学优化可能会推荐一个极其精妙的方案比如在周一早高峰只对“过去 3 个月下单频次 10 次”的用户启用新算法并且只在“GPS 信号强度 -85dBm”的设备上生效。这个方案在理论上信息增益最高。但在工程上它需要在客户端 SDK、服务端路由、数据打点等多个环节进行改造开发周期长达 6 周。而一个简单的“50/50 城市级分流”方案开发只需 3 天虽然信息增益低 20%但能让你在 1 周内就拿到初步反馈。教训OED 的输出必须经过一个“工程可行性评审”。这个评审不是由数据科学家主导而是由一位资深的后端工程师和一位客户端工程师共同完成。他们要回答的问题只有一个“这个方案我们能在两周内零风险地上线吗” 如果答案是否定的OED 系统就应该自动降级推荐下一个次优但可行的方案。坑三忘记了“人”才是最终的决策者OED 系统上线后我们曾观察到一个有趣的现象产品经理们开始盲目信任 OED 的推荐不再质疑其背后的假设。有一次OED 推荐了一个“高风险、高回报”的方案理由是“信息增益极高”。但一位老产品经理敏锐地指出“这个方案把所有流量都给了新算法万一它有严重的、未被发现的副作用比如导致司机大规模投诉我们的客服系统会瞬间崩溃。” 他坚持要求保留一个 10% 的“安全阀”safety valve流量用于兜底监控。教训OED 的终极目标不是取代人的判断而是拓展人的认知边界。一个健康的设计流程应该是“OED 提供数据驱动的选项 - 人类专家基于业务直觉和风险偏好做出最终选择 - 选择结果反馈给 OED用于模型迭代”。为此我们在 UI 上强制添加了一个“决策理由”Decision Rationale文本框要求每个实验的发起人必须手写一段不少于 50 字的理由解释为什么选择了这个方案而不是其他方案。这个小小的强制措施极大地提升了整个团队的决策质量。5. 总结与延伸OED 不是终点而是实验智能的新起点写到这里我想回到文章开头的那个问题Uber 用的到底是什么它不是一个叫“OED Framework”的代码包而是一种将统计学原理、工程实践和业务洞察熔铸在一起的实验智能范式。它的核心价值不在于它用了 Pyro而在于它用一种可计算、可审计、可复现的方式把“我们该如何做实验”这个原本充满艺术感和经验主义的问题转化成了一个清晰的、有边界的、可以持续优化的工程问题。如果你正在自己的公司推动类似的实践我的建议是不要试图一步到位复制 Uber 的全套架构。那就像一个刚学会骑自行车的人非要造一辆 F1 赛车。你应该从最痛的那个点切入。比如如果你的团队最大的抱怨是“每次实验都要猜样本量猜错了就白干”那就先聚焦在“贝叶斯样本量计算器”上。用 Pyro 写一个极简的模型只输入基线率和你对效应量的粗略估计输出一个带置信区间的样本量范围。这个小工具可能只需要一天就能做出来但它带来的改变是革命性的它第一次让“样本量”这个黑箱变成了一个可以被讨论、被质疑、被验证的透明参数。OED 的未来也远不止于此。随着大语言模型LLM的发展我们已经开始看到一些有趣的融合。比如用 LLM 来自动阅读 PRD产品需求文档和历史实验报告从中提取关键的业务目标、约束条件和先验知识自动生成 OED 的输入配置。再比如用 LLM 来解读 OED 的输出报告把一串冰冷的E[U_total]0.87, IG1.23翻译成一句产品经理能听懂的话“这个方案有 87% 的把握达成业务目标同时能让我们对‘为什么有效’的理解比现在清晰 1.23 倍。” 这种“统计智能”与“语言智能”的结合或许才是下一代实验平台的真正形态。我个人在实际操作中发现最难的从来不是技术本身而是让不同背景的人建立起对同一套逻辑的信任。当数据科学家谈论“KL 散度”工程师听到的是“计算开销”产品经理想到的是“上线时间”。OED 的伟大之处不在于它有多复杂而在于它提供了一个所有人都能参与的、共同的语言——这个语言是“信息”是“效用”是“风险”而不是“p 值”或“显著性”。它让一次实验从一个部门的 KPI变成了一场全公司的、关于“如何更聪明地学习”的集体对话。
Uber的OED实验智能系统：用贝叶斯优化替代p值决策
1. 项目概述这不是一个“框架”而是一套被工程化锤炼过的实验决策系统你点开这篇文章大概率是冲着“Uber用的统计实验框架”这个标题来的。但我要先泼一盆冷水Uber官方从未发布过一个叫“OED Framework”的开源框架也没有把它打包成 pip install oed 这样的东西。它本质上不是一套代码库而是一套在超大规模业务场景中反复验证、持续迭代的实验设计方法论 工程实现范式 决策支持流程。它的核心缩写 OED全称是 Optimal Experimental Design最优实验设计这本身就是一个统计学里存在了几十年的老概念——但 Uber 把它从教科书和论文里拽了出来塞进每天要跑上千个 AB 实验的生产环境里硬生生给它焊上了数据管道、模型服务、监控告警和产品看板。关键词里写的“Artificial Intelligence”在这里不是指大模型或深度学习而是指整个实验体系具备了“智能决策”的能力它能自动评估哪个实验设计更可能得出可靠结论能预判样本量是否足够甚至能在实验进行中动态建议是否提前终止。我做过三年 AB 实验平台的后端开发也参与过两个大型推荐系统的实验治理实测下来这套思路最颠覆的地方在于它把“做实验”这件事从产品经理拍脑袋决定“我们试试这个按钮颜色”升级成了数据科学家和工程师共同维护的一条“决策流水线”。它适合三类人第一类是正在搭建公司级实验平台的工程师你需要理解 Uber 为什么放弃传统固定样本量的 t 检验转而拥抱贝叶斯框架第二类是数据科学家尤其是负责增长、推荐、搜索等强实验驱动方向的你需要知道如何把一个业务假设翻译成可计算的 OED 目标函数第三类是技术型产品经理如果你需要向老板解释“为什么这个实验要跑 28 天而不是 7 天”这篇文章里的参数推导过程就是你的弹药库。它不教你写 Pyro 代码但它会告诉你为什么 Uber 的工程师在写 Pyro 模型时第一行永远是定义先验分布而不是写 likelihood。2. 核心设计逻辑为什么 Uber 放弃了“p 值”选择了“信息增益”2.1 传统 AB 实验的三大硬伤Uber 全都撞上了在 Uber 的场景里一次典型的实验可能涉及数千万用户覆盖全球几十个市场指标维度包括订单完成率、司机接单时长、乘客取消率、客单价、甚至司机收入波动率。在这种尺度下传统频率学派的 AB 实验方法比如双样本 t 检验暴露出三个无法回避的致命缺陷而这些缺陷在中小公司可能只是“有点麻烦”在 Uber 就是“每天烧掉上百万美金”。第一个硬伤是样本量预估的严重失真。传统方法依赖一个关键假设效应量effect size是已知且固定的。比如你预计新算法能把转化率从 5% 提升到 5.2%提升 0.2 个百分点。但现实是这个 0.2% 是你基于历史数据的粗略估计真实值可能在 0.05% 到 0.5% 之间剧烈波动。当你用 0.2% 去计算所需样本量结果可能是 100 万用户但如果真实效应只有 0.05%那这 100 万用户跑完统计功效statistical power可能连 30% 都不到——相当于扔了 100 万用户的实验流量却大概率得不出任何有把握的结论。我亲眼见过一个同城货运团队因为沿用旧的样本量计算器连续三个月的“优化算法”实验全部宣告无效最后回溯发现他们预设的效应量比实际高出了整整 4 倍。第二个硬伤是决策时机的僵化与滞后。传统方法要求你“预先设定显著性水平α0.05和统计功效1-β0.8然后一次性收集完所有样本最后看 p 值”。这在 Uber 的节奏里是灾难性的。一个新功能上线市场反馈瞬息万变竞争对手可能下周就推出类似功能。你不可能告诉 CEO“老板这个实验还要再跑 17 天虽然今天数据看起来很好但我们得等到截止日才能下结论。” 更糟的是如果实验中期数据已经显示新方案明显更差比如订单取消率飙升 20%你也不能立刻叫停——因为提前看数据会污染 p 值导致假阳性风险失控。这种“等死式”的决策机制在快节奏的业务环境中等于慢性自杀。第三个硬伤是多目标权衡的彻底失效。一个实验从来不止看一个指标。比如优化乘客端的匹配算法你既希望提升“匹配成功率”又不希望“司机平均等待时长”增加太多更不能让“司机投诉率”上升。传统方法要么强行选一个主指标要么用加权求和这种粗糙方式根本无法量化“牺牲 1% 的匹配成功率换来司机等待时长下降 5%这个 trade-off 是否值得”。它缺乏一个统一的、可计算的“价值函数”。提示这三个问题正是 Uber 构建 OED 系统的原始驱动力。它不是为了炫技而是被业务规模和速度逼出来的生存方案。2.2 OED 的破局点用“信息”替代“显著性”用“贝叶斯”替代“频率学派”OED 的核心思想非常朴素实验的终极目的不是证明一个假设“为真”或“为假”而是最大化我们从这次实验中获得的、关于关键业务参数的“信息量”。这个“信息量”在数学上被精确定义为“后验分布相对于先验分布的熵减”也就是 Kullback-Leibler 散度KL divergence。简单说就是实验结束后我们对“真实效应量”的不确定性比实验开始前减少了多少。这个视角的转换带来了质的飞跃。首先它天然兼容不确定性。你的先验分布比如对转化率提升幅度的信念可以是一个宽泛的 Beta 分布它本身就表达了“我们不确定但大致认为在 0% 到 0.5% 之间”。OED 的优化目标就是选择那个能最大程度“压缩”这个分布的实验设计——比如是给每个用户发 3 个不同版本的推送还是只发 2 个是把 80% 的流量分给 A 组20% 给 B 组还是 50/50这些选择都可以被翻译成一个数学上的优化问题在总流量预算约束下最大化预期 KL 散度。其次它让“提前终止”变得合情合理。在贝叶斯框架下你每看到一批新数据就更新一次后验分布。当后验分布已经足够“尖锐”比如95% 的概率密度都集中在“效应量 0.1%”这个区间而你的业务阈值是 0.05%那你就可以自信地说“这个实验已经提供了足够强的证据新方案优于旧方案。” 这不需要任何“p 值校正”因为每一次更新都是基于当前所有已知信息的最优推断。这正是 Uber 工程师所说的“sequential analysis”序贯分析——决策是流动的不是静止的。最后它完美解决了多目标问题。你可以为每一个关键指标定义一个“效用函数”utility function。比如匹配成功率每提升 0.1%效用 1司机等待时长每增加 1 秒效用 -0.5投诉率每上升 0.01%效用 -2。然后OED 的优化目标就变成了最大化所有指标效用的加权期望值。这个期望值是通过对后验联合分布进行积分计算出来的。它不再是拍脑袋的权重而是基于数据和业务目标的、可计算、可审计的决策依据。2.3 为什么是 Pyro一个被低估的工程选择原文提到“OED enables the scoring and optimization experiments using Pyro’s probabilistic programming model”这很容易让人误解为“Uber 在用 Pyro 写生产代码”。实则不然。Pyro 是 Uber 团队在研究、验证和原型设计阶段的首选工具原因有三且都直指工程落地的核心痛点。第一表达力与可读性的极致平衡。Pyro 的核心是“概率程序”probabilistic program它允许你用近乎自然语言的 Python 代码清晰地描述一个复杂的生成过程。比如定义一个关于“用户点击行为”的模型你可以这样写def model(user_features, treatment_assignment): # 先验基础点击率 base_rate pyro.sample(base_rate, dist.Beta(2.0, 8.0)) # 先验处理效应treatment effect effect pyro.sample(effect, dist.Normal(0.0, 0.1)) # 似然观测到的点击0 或 1 with pyro.plate(data, len(user_features)): prob base_rate effect * treatment_assignment pyro.sample(obs, dist.Bernoulli(prob), obsclicks)这段代码任何一个懂 Python 和基本统计概念的工程师都能看懂它在做什么它假设用户点击率有一个基础值base_rate而实验处理treatment会在这个基础上叠加一个效应effect最终产生观测到的点击结果obs。这种“所见即所得”的建模方式极大地降低了跨职能沟通成本。数据科学家写模型工程师看代码就能理解业务逻辑产品经理也能参与讨论“这个 effect 的先验分布设得是否合理”。第二灵活的推理后端切换能力。Pyro 不是一个绑定死某个算法的黑盒。它背后是一个抽象的“推理引擎”inference engine接口。在研究阶段你可以用 MCMCMarkov Chain Monte Carlo做精确但慢的采样在需要快速迭代时可以无缝切换到 SVIStochastic Variational Inference用变分推断获得一个近似的、但计算极快的后验分布。这种灵活性让 Uber 的团队可以在“追求极致精度”和“满足实时决策需求”之间自由滑动。一个用于长期战略分析的 OED 模型可以用 MCMC 跑一整晚而一个用于实时实验监控的轻量级模型则用 SVI 在几秒内给出结果。第三与 PyTorch 生态的深度集成。这是最关键的工程优势。Uber 的整个数据基础设施从特征工程到模型训练大量使用 PyTorch。Pyro 基于 PyTorch 构建意味着它可以原生利用 PyTorch 的自动微分autograd、GPU 加速和分布式训练能力。当 OED 模型需要处理海量用户特征比如一个包含 1000 维的用户 embedding 向量时Pyro 可以直接调用 PyTorch 的torch.nn模块来构建一个神经网络作为“效应量预测器”然后把这个预测器嵌入到概率模型中。这种“概率模型 深度学习”的混合建模能力是很多传统统计软件如 R 的 rstan望尘莫及的。它让 OED 不再是一个孤立的统计模块而是能深度融入 Uber 整个 AI 工程栈的有机部分。注意在 Uber 的生产环境中最终部署的 OED 服务其核心计算逻辑很可能是用 C 重写的高性能版本或者编译成 ONNX 模型。Pyro 的角色是那个在实验室里反复打磨、验证、并最终输出“黄金标准”的“数字孪生”。3. 核心环节拆解从一个业务问题到一个可执行的 OED 方案3.1 场景还原为“动态定价”策略设计一场高置信度实验让我们把上面所有的理论放进一个真实的 Uber 业务场景里一步步走完从问题定义到方案落地的全过程。假设你是 Uber 动态定价团队的数据科学家老板给你一个任务“我们想测试一种新的 surge pricing高峰期加价算法它能根据更细粒度的供需预测动态调整加价倍数。我们需要知道这个新算法能否在保证司机收入的同时将乘客的‘放弃下单率’abandonment rate降低至少 0.3 个百分点。”这是一个典型的、充满挑战的实验需求。它有明确的业务目标降低放弃下单率 ≥0.3%但也有巨大的不确定性新算法的效果未知且不同城市、不同时段的效果差异巨大。现在我们用 OED 的思路来解构它。第一步定义“决策变量”与“响应变量”决策变量Design Variables这是你能主动控制的实验设置。在本例中它包括treatment_assignment: 用户被分配到新算法1还是旧算法0。geographic_granularity: 实验是在城市级别如“纽约市”还是更细的“区域网格”如“曼哈顿中城”进行这直接影响效果的异质性heterogeneity。temporal_granularity: 实验是全天候运行还是只在特定高峰时段如 17:00-20:00生效这关系到信号的强度。响应变量Response Variables这是你观测到的结果。核心是abandonment_rate放弃下单率但绝不能只看它。必须同时监控driver_earnings_per_trip司机每单收入和average_wait_time平均等待时长因为它们是关键的约束条件constraints。OED 要求你把所有相关变量都纳入同一个联合概率模型。第二步构建先验知识Prior Knowledge这是 OED 区别于传统方法的起点也是最容易被忽视的一步。你不能凭空写一个先验。你需要从历史数据中“萃取”。对于abandonment_rate的基线baseline你可以拉取过去 30 天、相同城市、相同时间段的历史数据拟合一个 Beta 分布。假设你得到Beta(α120, β3880)这意味着基线率的均值是 120/(1203880) ≈ 3.0%这与业务常识吻合。对于新算法的effect即对放弃下单率的影响你没有直接数据。但你可以借鉴类似功能的历史表现。比如去年上线的“ETA 预估优化”功能将放弃下单率降低了 0.15%。你可以据此设定一个相对保守的先验Normal(μ0.0015, σ0.001)即均值 0.15%标准差 0.1%表示你相信效果大概率在 0.05% 到 0.25% 之间。对于driver_earnings_per_trip你可能有更丰富的数据。你可以用一个LogNormal分布来建模因为它天然保证收入为正。第三步定义效用函数Utility Function与约束这才是体现业务智慧的地方。你不能只说“我们要最小化放弃下单率”。你需要量化“代价”。核心效用U_main (abandonment_rate_old - abandonment_rate_new) * 1000。这里乘以 1000 是为了放大数值便于后续优化。目标是最大化U_main。硬约束Hard Constraintdriver_earnings_per_trip_new driver_earnings_per_trip_old * 0.99。即司机收入不能低于旧算法的 99%。这是一个业务红线违反即失败。软约束Soft ConstraintU_wait max(0, average_wait_time_new - average_wait_time_old) * (-500)。如果等待时间变长会产生负效用但不像司机收入那样是硬性红线。最终的总效用U_total U_main U_wait而硬约束则通过在优化过程中对违反约束的实验设计施加一个巨大的惩罚项penalty term来实现。3.2 OED 优化一场在“信息”与“成本”之间的精密权衡现在我们有了一个清晰的数学问题在给定的总流量预算比如每天 100 万次订单请求下如何分配treatment_assignment、geographic_granularity和temporal_granularity使得E[U_total | data]总效用的后验期望值最大化这个问题的求解是整个 OED 系统最核心、也最消耗算力的环节。Uber 的工程师不会手动去解这个优化问题而是将其封装成一个可调用的服务。其内部流程大致如下1. 参数空间采样与模拟Simulation-based Optimization由于解析解几乎不可能OED 系统采用蒙特卡洛模拟。它会在决策变量的空间内随机采样出 N 个候选设计方案例如N1000。每个方案是一个元组(treatment_ratio0.5, geo_granularitycity, time_granularitypeak)。对于每一个候选方案系统会启动一个“虚拟实验”virtual experiment它使用你定义好的概率模型即前面写的 Pyro model结合你的先验分布生成大量模拟的“观测数据”synthetic data。比如模拟 10 万次订单根据模型计算出每次订单的abandonment_rate、driver_earnings等。然后系统会用这些模拟数据运行一次完整的贝叶斯推断比如用 SVI得到该方案下的后验分布P(effect | simulated_data)。最后系统计算这个后验分布下的E[U_total]即对所有可能的效应量进行加权平均。2. 信息增益的量化计算对于每一个候选方案系统不仅计算E[U_total]还计算其“信息增益”Information Gain即 KL 散度IG KL(P(effect | simulated_data) || P(effect))这个值衡量了该方案能让你对“真实效应量”的认知比实验前清晰多少。一个优秀的 OED 方案必须在E[U_total]和IG之间取得平衡。一个方案可能E[U_total]很高但IG很低意味着它虽然看起来收益大但实验后你依然对“为什么收益大”一无所知无法推广到其他场景。3. 多目标帕累托前沿Pareto Frontier最终系统不会只返回一个“最优”方案而是返回一个“帕累托前沿”Pareto frontier——一组互不支配的方案。一个方案 A “支配” 方案 B意味着 A 在E[U_total]上不小于 B且在IG上也不小于 B且至少有一项严格大于。前沿上的每一个点都代表了一种不同的权衡你可以选择一个IG极高、E[U_total]中等的方案用于深度探索也可以选择一个E[U_total]极高、IG中等的方案用于快速验证和上线。实操心得我在实际项目中发现最常被忽略的一步是“先验校准”。很多团队直接用一个Normal(0, 1)作为效应量的先验这在数学上是合法的但在业务上是灾难性的。它意味着你认为效应量有 95% 的概率在 -2 到 2 之间这完全脱离了现实。正确的做法是用历史实验的效应量分布去拟合一个先验。比如过去 100 个定价实验效应量的中位数是 0.12%标准差是 0.08%那么一个Normal(0.0012, 0.0008)的先验就合理得多。这个细节直接决定了 OED 推荐方案的可信度。3.3 生产环境集成OED 如何变成一个“活”的实验平台组件OED 的价值不在于它能算出一个漂亮的数字而在于它能无缝嵌入到 Uber 的实验工作流中。它的生产集成是一个典型的“三层架构”。第一层决策层Decision Layer这是面向产品经理和数据科学家的 UI。它不是一个命令行工具而是一个 Web 应用。当你创建一个新实验时UI 会引导你输入业务目标如“降低放弃下单率”和约束如“司机收入不低于 99%”。上传或选择历史数据用于自动拟合先验。设置总流量预算和实验周期。 然后点击“Generate Optimal Designs”UI 会展示帕累托前沿上的几个推荐方案并用直观的图表对比它们的E[U_total]、IG、预计所需天数和风险等级基于后验分布的不确定性。第二层计算层Computation Layer这是 OED 的心脏通常是一个 Kubernetes 集群上的微服务。它接收来自 UI 的请求调用底层的 Pyro 模型和优化器。为了应对高并发每天可能有数百个实验在同时设计这一层做了大量工程优化缓存Caching对常用的先验分布、模型结构进行缓存。如果两个实验的业务目标和约束高度相似系统可以直接复用之前计算过的部分结果而不是从头开始。异步队列Async Queue复杂的优化任务会被放入 Celery 或 Kafka 队列由后台 worker 执行。UI 端显示“正在计算中”用户可以去做别的事。资源隔离Resource Isolation每个优化任务被分配独立的 CPU/GPU 资源和内存限制防止一个耗尽资源的任务拖垮整个服务。第三层数据层Data Layer这是 OED 的基石它必须与 Uber 的核心数据仓库如 Hive/Presto和实时数据流如 Kafka深度打通。特征服务Feature StoreOED 模型需要的用户特征如用户历史下单频次、所在区域的实时供需比都来自统一的特征服务。这保证了实验设计所用的特征与线上模型所用的特征完全一致消除了“训练-推理不一致”train-serving skew。实验元数据Experiment Metadata每一次实验的配置、OED 推荐的方案、实际运行的流量分配、以及最终的后验分析报告都会被写入一个专门的实验元数据库。这不仅是审计的需要更是为未来的 OED 模型提供“反馈循环”——系统可以学习“哪些类型的先验更准确”从而不断改进自身的推荐能力。注意这个三层架构是 Uber 工程文化的一个缩影。它没有追求“大而全”的单体应用而是用松耦合的微服务将一个复杂的统计问题分解为可独立开发、测试、部署和扩展的组件。这也是为什么 OED 能在 Uber 这样规模的公司里真正落地而不是停留在论文里。4. 实操经验与避坑指南那些文档里永远不会写的真相4.1 常见问题速查表从“为什么算不出来”到“结果看不懂”问题现象可能原因排查与解决思路OED 优化耗时过长1小时1. 决策变量空间过大如同时优化 10 个粒度的地理划分2. 模拟数据量过大如单次模拟 1000 万条3. 先验分布过于宽泛导致后验更新缓慢解决方案- 使用“分层优化”先粗粒度城市级优化再在推荐的城市内对子区域进行精细化优化。- 将模拟数据量从 1000 万降至 10 万OED 的相对排序结果通常不受影响但速度提升百倍。- 用历史实验数据收紧先验例如将Normal(0, 1)改为Normal(0.001, 0.0005)。OED 推荐的方案上线后效果远低于预期1. 先验与现实严重脱节最常见2. 模型忽略了关键混杂因子confounder如天气、节假日、竞品活动3. “流量同质性”假设被打破OED 假设分配到 A/B 组的用户是可比的解决方案- 强制要求所有新实验必须提交一份“先验合理性说明”由资深数据科学家签字确认。- 在 Pyro 模型中显式加入weather_condition、is_holiday等协变量并为其设定合理的先验。- 在实验上线前用历史数据做一次“反事实检验”counterfactual check用旧算法的模型去预测新算法的流量看预测误差是否在可接受范围内。后验分布过于“平坦”信息增益IG极低1. 实验设计本身无法区分效应如A/B 组流量分配比例是 99%/1%信号太弱2. 观测指标噪声过大如放弃下单率受网络延迟等随机因素影响3. 模型设定错误如用了线性模型但真实关系是非线性的解决方案- OED 系统应内置一个“可检测性诊断”detectability diagnostic在推荐方案前先快速评估该方案在理想情况下的最大可能 IG。如果这个值就很低就直接提示“此实验设计不可行”。- 对高噪声指标改用更鲁棒的聚合方式例如不看单次订单的放弃率而看一个用户在 7 天内的放弃次数。多个指标的效用函数冲突优化结果不稳定1. 效用函数的量纲scale不一致如一个用百分比一个用美元2. 硬约束设置过于苛刻导致可行解空间为空解决方案- 所有效用函数必须归一化到 [0, 1] 区间。例如U_main min(1, (0.003 - effect) / 0.003)其中 0.003 是业务目标 0.3%。- 硬约束应设置为“软约束”并赋予一个随违反程度指数增长的惩罚项而不是简单的“0/1”开关。4.2 我踩过的三个深坑以及如何绕开它们坑一把 OED 当成“万能胶”试图用它解决所有实验问题我曾经接手过一个项目团队想用 OED 来优化一个全新的、从未上线过的“语音叫车”功能。他们满怀信心地定义了先验跑了 OED得到了一个看似完美的方案。结果实验上线后数据一片混乱。复盘才发现问题根本不在于统计方法而在于产品本身语音识别的错误率太高导致大量用户根本没发出有效指令abandonment_rate这个指标在此刻完全失去了业务意义。OED 再强大也无法在一个指标本身就不健康的土壤上开出花来。教训OED 是一个“决策增强”decision augmentation工具不是“问题定义”problem definition工具。在启动 OED 之前必须确保你的业务指标是稳定、可靠、且与核心目标强相关的。一个简单的检查清单是这个指标在过去 30 天内是否有超过 5% 的天数出现数据缺失或异常尖峰如果有先解决数据问题再谈实验设计。坑二过度追求“最优”忽略了工程落地的复杂性OED 的数学优化可能会推荐一个极其精妙的方案比如在周一早高峰只对“过去 3 个月下单频次 10 次”的用户启用新算法并且只在“GPS 信号强度 -85dBm”的设备上生效。这个方案在理论上信息增益最高。但在工程上它需要在客户端 SDK、服务端路由、数据打点等多个环节进行改造开发周期长达 6 周。而一个简单的“50/50 城市级分流”方案开发只需 3 天虽然信息增益低 20%但能让你在 1 周内就拿到初步反馈。教训OED 的输出必须经过一个“工程可行性评审”。这个评审不是由数据科学家主导而是由一位资深的后端工程师和一位客户端工程师共同完成。他们要回答的问题只有一个“这个方案我们能在两周内零风险地上线吗” 如果答案是否定的OED 系统就应该自动降级推荐下一个次优但可行的方案。坑三忘记了“人”才是最终的决策者OED 系统上线后我们曾观察到一个有趣的现象产品经理们开始盲目信任 OED 的推荐不再质疑其背后的假设。有一次OED 推荐了一个“高风险、高回报”的方案理由是“信息增益极高”。但一位老产品经理敏锐地指出“这个方案把所有流量都给了新算法万一它有严重的、未被发现的副作用比如导致司机大规模投诉我们的客服系统会瞬间崩溃。” 他坚持要求保留一个 10% 的“安全阀”safety valve流量用于兜底监控。教训OED 的终极目标不是取代人的判断而是拓展人的认知边界。一个健康的设计流程应该是“OED 提供数据驱动的选项 - 人类专家基于业务直觉和风险偏好做出最终选择 - 选择结果反馈给 OED用于模型迭代”。为此我们在 UI 上强制添加了一个“决策理由”Decision Rationale文本框要求每个实验的发起人必须手写一段不少于 50 字的理由解释为什么选择了这个方案而不是其他方案。这个小小的强制措施极大地提升了整个团队的决策质量。5. 总结与延伸OED 不是终点而是实验智能的新起点写到这里我想回到文章开头的那个问题Uber 用的到底是什么它不是一个叫“OED Framework”的代码包而是一种将统计学原理、工程实践和业务洞察熔铸在一起的实验智能范式。它的核心价值不在于它用了 Pyro而在于它用一种可计算、可审计、可复现的方式把“我们该如何做实验”这个原本充满艺术感和经验主义的问题转化成了一个清晰的、有边界的、可以持续优化的工程问题。如果你正在自己的公司推动类似的实践我的建议是不要试图一步到位复制 Uber 的全套架构。那就像一个刚学会骑自行车的人非要造一辆 F1 赛车。你应该从最痛的那个点切入。比如如果你的团队最大的抱怨是“每次实验都要猜样本量猜错了就白干”那就先聚焦在“贝叶斯样本量计算器”上。用 Pyro 写一个极简的模型只输入基线率和你对效应量的粗略估计输出一个带置信区间的样本量范围。这个小工具可能只需要一天就能做出来但它带来的改变是革命性的它第一次让“样本量”这个黑箱变成了一个可以被讨论、被质疑、被验证的透明参数。OED 的未来也远不止于此。随着大语言模型LLM的发展我们已经开始看到一些有趣的融合。比如用 LLM 来自动阅读 PRD产品需求文档和历史实验报告从中提取关键的业务目标、约束条件和先验知识自动生成 OED 的输入配置。再比如用 LLM 来解读 OED 的输出报告把一串冰冷的E[U_total]0.87, IG1.23翻译成一句产品经理能听懂的话“这个方案有 87% 的把握达成业务目标同时能让我们对‘为什么有效’的理解比现在清晰 1.23 倍。” 这种“统计智能”与“语言智能”的结合或许才是下一代实验平台的真正形态。我个人在实际操作中发现最难的从来不是技术本身而是让不同背景的人建立起对同一套逻辑的信任。当数据科学家谈论“KL 散度”工程师听到的是“计算开销”产品经理想到的是“上线时间”。OED 的伟大之处不在于它有多复杂而在于它提供了一个所有人都能参与的、共同的语言——这个语言是“信息”是“效用”是“风险”而不是“p 值”或“显著性”。它让一次实验从一个部门的 KPI变成了一场全公司的、关于“如何更聪明地学习”的集体对话。
