线上改动如何通过 A/B 测试或灰度指标验证真实效果？

核心回答

A/B 测试用随机分组比较改动的因果效果；灰度发布通过逐步扩大新版本流量控制风险，灰度本身不保证能归因。我会先定义改动假设、主要业务指标和安全、错误、延迟、成本等护栏，再确定分桶单位、样本量、观察周期和停止规则。

实验期间稳定分组并记录实际曝光与版本，先检查分流和埋点是否可信，再看效果大小、不确定性与分层差异。护栏恶化及时停止放量或回滚；只有收益达到业务意义、风险可接受，才继续扩大流量。

展开解析

1. 先分清“有效”和“安全上线”

例如调整客服 Agent 的检索策略，假设是“提高有依据的问题解决率”。离线先验证事实与权限，再做灰度检查故障；需要证明收益时，在同一目标人群中随机分到基线与新策略组，保持同期可比。

若只是把内部用户切到新版本、外部用户留在旧版本，或比较上线前后两天的指标，用户差异、流量变化和季节性都可能解释结果。这能辅助发布观察，但不能直接当随机实验的因果证据。

2. 分桶单位与统计单位要一致

单轮无记忆任务可以按任务设计实验；多轮对话通常需要按用户或会话稳定分桶，避免前一轮使用旧版本、后一轮换新版本污染状态。企业用户共享资料、协作流程或配额时，还应考虑按租户分组，减少组间影响。

记录分组、曝光、触发条件、模板/模型/检索/工具版本及业务结果。分析时不能把同一用户的每次重试当独立样本；应按随机化单位聚合，或采用能处理相关性的分析方法。共享缓存、共享记忆和容量竞争也可能造成跨组干扰，需要在设计和解释中处理。

3. 指标需要有清楚的分母与回收窗口

类型	例子	需要说明的口径
主要业务指标	问题解决率、任务完成率	哪些请求进入分母、观察多久、如何确认完成
质量指标	事实错误、引用支持、人工修订	人工或自动评分标准与抽样方式
安全护栏	越权、泄露、错误写入	实际效果与模型尝试分开记录
系统护栏	错误率、尾延迟、超时和队列积压	端到端与各阶段分别观察
成本护栏	每任务及每成功任务成本	包含重试和失败费用

上线前确定最小有业务价值的差异，结合基线方差、目标检验能力和可用流量估算样本量。预先选择固定时点分析，或使用适合持续监测的统计方法，不能每天看一次直到偶然显著就宣布成功；同时比较很多指标也要控制多重比较带来的误判。

4. 先验数据质量，再解释实验收益

检查实际分组人数是否显著偏离预期分配比例，即样本比例失配（SRM）；随机波动不要求比例精确相等。再核对曝光漏报、事件重复、机器人过滤、结果延迟和数据关联。若只在新版本成功时上报曝光，实验组的失败用户会从分析中消失，结果会偏高。

实验应尽量保持其他条件一致；同期改动、用户自选分组或定向只放简单请求都会影响归因。必要时先跑 A/A 验证分流和指标链路，再按预定分层检查新老用户、任务类型等差异。分层用于诊断，不应事后挑出唯一增长的人群当作整体结论。

5. 决策与回滚要落到版本和状态

报告绝对变化、相对变化与区间，并同时检查业务意义和护栏。差异不显著可能是没有足够证据，也可能是样本量不足，不能直接等同于两个方案一样。

灰度阶段设置停止放量和回滚条件，保留可用基线及版本开关。回滚要覆盖提示词、模型路由、工具契约和检索配置，并检查已有会话和任务状态能否兼容。外部退款、发信等已完成动作不会因代码回滚自动撤销，需要单独确认影响并走业务补偿。

追问

小流量数据好看，为什么全量后可能变差？

小流量可能来自内部用户或简单任务；全量后的任务分布、并发、配额和缓存命中也会不同。需要分层对照、负载验证和逐步放量，不能线性外推收益。

能否把真实请求同时交给新旧 Agent 比较？

影子流量可以比较结果和耗时，但新版本不得重复执行真实写操作。只读回放、隔离工具或模拟副作用更合适；它也不能直接替代真实用户行为的随机实验。

参考资料