布吉岛 Agent

Appearance

10.4.3 如何通过实验设计验证某个优化是否真的有效？ ​

先给结论：没有实验设计，优化结果很容易是“感觉有效”。实验设计的核心不是复杂统计，而是确保每次改动都有明确目标、对照基线和可重复验证的结果。

很多团队在调优时会出现这种情况：

  • 改了三四个参数
  • 结果看起来好像好了

但一追问：

  • 到底是哪一步带来提升？
  • 有没有副作用？

就很难回答。原因是：

  • 缺少实验设计

为什么 RAG 优化更需要实验设计 ​

因为 RAG 的链路很长，一个改动可能带来：

  • 好处
  • 副作用

而且副作用往往不是立刻显现，比如：

  • TopK 变大，短期召回更好，但噪声增加，长期生成忠实性下降
  • 增加 Rerank，复杂题变好，但延迟变慢，某些场景体验下降

如果你没有实验设计，这些变化很容易被忽略。

一个最小可用的实验设计流程 ​

你不需要一开始就做复杂 A/B 测试。更现实的起步流程通常是：

  1. 明确本次优化的目标问题
  2. 固定评测集和基线
  3. 每次只改一个主要变量
  4. 记录改动前后的分桶指标变化
  5. 观察是否出现新的退化

做到这五步，已经能避免很多“感觉提升”的假象。

关键点一：实验目标必须足够具体 ​

不要用“整体效果更好”作为目标。更稳的目标应该是：

  • 降低某一类错误桶的占比
  • 提升某一类问题的召回质量
  • 改善某一类复杂问题的稳定性

目标越具体，实验越可解释。

关键点二：一次只动一个主要变量 ​

这是最容易被忽略的一点。因为现实里总会忍不住：

  • 这也顺便调一下
  • 那也一起改了

但这样做会让实验不可解释。如果你想知道哪一步真的有效，就必须：

  • 一次只动一个主变量

关键点三：必须有固定基线集 ​

如果每次评测用的样本都不一样，就很难判断：

  • 是系统变了
  • 还是样本变了

所以至少要有：

  • 一套固定的基线评测集

同时可以有：

  • 新增的线上回流样本集

但基线集必须保持稳定。

关键点四：要看分桶变化，而不只看总分 ​

总分变化很容易掩盖结构性退化。更稳的做法是：

  • 看每个错误桶的变化
  • 看目标问题类型是否真正改善

这样你才能判断：

  • 这次优化是否真正命中目标

关键点五：记录副作用 ​

很多优化动作的副作用是不可避免的。例如：

  • 召回更宽但噪声更大
  • 生成更稳但延迟更高

所以实验记录里一定要保留：

  • 主收益
  • 副作用

否则你会不断重复踩同一个坑。

一个最小实验记录示意 ​

python
experiment = {
    "change": "increase_topk_from_10_to_30",
    "target_bucket": "retrieval_recall_error",
    "baseline_set": "eval_v3",
    "result": {
        "target_bucket_drop": 0.12,
        "faithfulness_regression": 0.05,
        "latency_increase_ms": 320
    },
    "decision": "keep_with_rerank_tuning"
}

这个示意的价值在于：

  • 每次改动都有明确目标
  • 有结构化的结果记录
  • 能为下一步优化提供依据

什么时候需要更严格的实验设计 ​

当你进入这些场景时，更严格的实验设计就很必要：

  • 线上流量已经很大
  • 多团队同时在改系统
  • 成本和延迟目标非常敏感
  • 需要对业务侧给出稳定承诺

这时可以考虑更正式的：

  • A/B 测试
  • 阶段性发布
  • 灰度验证

一句话总结 ​

RAG 优化要验证是否有效，核心不在于复杂统计，而在于明确目标、保持基线一致、一次只动一个主要变量，并把结果落到可回溯的记录上。