10.4.2 为什么没有评测闭环的优化很容易“局部提升、整体退化”？

先给结论：没有评测闭环时，优化很容易只提升某一类问题，却在不知不觉中伤害其他问题。结果看起来“有进步”，但整体稳定性反而变差。

这是 RAG 调优里最常见的“假提升”现象。因为很多优化动作本身就带有取舍，如果没有回归评测，你很难发现：

• 哪一类问题变好了
• 哪一类问题变差了

为什么会出现“局部提升、整体退化”

最常见的原因是：

• 你优化了一个指标，却伤害了另一类问题

例如：

• 扩大 TopK 提高了召回率，但噪声变多，生成质量下降
• 增加 Rerank 提高了准确率，但延迟变大，部分场景体验变差
• 缩短上下文减少成本，却导致复杂问题漏条件

如果没有评测闭环，你很容易只看到：

• 某些案例变好了

却看不到：

• 其他问题已经退化

闭环的关键不是“多测几次”，而是“持续回归”

很多团队的“评测”只发生在优化前后的一次对比上。这样会造成：

• 你只能看到短期变化
• 不能发现结构性退化

真正的评测闭环，需要的是：

• 固定的基线集
• 关键问题的持续跟踪
• 版本之间的系统性回归比较

这和“做一次评测”是完全不同的。

没有闭环时，最常见的三种误判

误判一，看见分数提升，就以为系统更好

分数提升可能只代表：

• 某一类题提升了

而不是：

• 整体更稳了

误判二，只优化高频问题，忽略高风险问题

如果没有专门的评测集覆盖高风险问题，这类问题退化时你很难发现。结果是：

• 高频问题很好
• 关键风险问题变差

误判三，只看离线指标，不看线上反馈

离线评测集如果不持续回流真实问题，很容易变得“越来越理想化”，导致你以为系统稳定，实际用户体验下降。

闭环应该至少包含哪几层

一个最小可用的闭环通常至少需要：

• 固定的基线评测集
• 按错误类型分桶的指标统计
• 每次优化后的回归对比
• 线上失败样本的回流机制

这四层里任何一层缺失，都很容易出现“局部提升、整体退化”的假象。

一个简单的闭环工作流示意

loop = [
    "run_eval_on_baseline_set",
    "check_bucket_distribution_shift",
    "apply_one_change",
    "rerun_eval_and_compare",
    "log_regressions_and_new_failures",
    "add_online_failures_to_eval_set"
]

这个示意的重点是：

• 每一次改动都回到同一套基线去验证
• 重点看结构变化而不是只看总分

为什么要强调“结构变化”

因为总分容易掩盖真实问题。举例：

• 简单题提升了 5 分
• 复杂题下降了 5 分

总分可能没变，但系统已经出现了结构性退化。只有分桶指标才能发现这种问题。

一个很实用的判断信号

如果你发现：

• 离线评测稳步上升
• 线上反馈却没有同步改善

这往往说明：

• 评测闭环缺失
• 或者评测集已经偏离真实问题分布

一句话总结

没有评测闭环时，优化很容易出现“局部提升、整体退化”。闭环的价值在于让你看到结构性变化，而不是只盯着某一次的分数提升。