Appearance
10.2.1 如何优化召回率，如何优化准确率，它们为什么经常冲突？
先给结论：召回率和准确率经常冲突，因为它们在解决的不是同一件事。召回率更关注“该找回来的证据有没有回来”，准确率更关注“最终给模型和用户的内容是不是足够相关、足够干净、足够可靠”。当你想让候选集更宽时，噪声通常会增加；当你想让结果更干净时，覆盖面又可能收窄。
很多团队在调优时会自然地想：
- 把召回率拉高，效果应该就更好
这句话只说对了一半。因为在 RAG 里，更多召回既可能带来：
- 更完整的证据覆盖
也可能带来：
- 更多表面相关但无用的噪声
而这些噪声会继续影响：
Rerank- 上下文构造
- 生成忠实性
所以这两个指标在真实系统里经常不是同向变化。
先把两者分别理解清楚
召回率更关心“漏没漏”
从直觉上看，召回率要回答的是：
- 该回来的关键证据，有没有被候选集覆盖到
它更像在防止：
- 漏召回
- 找不到真正关键的材料
准确率更关心“净不净”
准确率更像在回答：
- 你最终保留下来的结果里，有多少是真正相关而且有用的
它更像在防止：
- 噪声太多
- 偏题内容混入
- 表面相关但无助于回答的内容占位
为什么它们经常互相拉扯
最常见的冲突来自一句话：
- 为了不漏，你会倾向多拿一些；为了更准，你会倾向少拿一些
例如：
- 增大
top k，更可能把关键证据捞进来，但也会引入更多边缘相关结果 - 放宽 query expansion，可能覆盖更多问法，但也更容易把语义范围放大
- 混合召回增加覆盖面，但如果后续选择不稳，噪声会快速进入最终上下文
所以很多优化动作会出现这种现象：
- 召回率上升了
- 但最终回答并没有变好，甚至更差
什么情况下应该优先保召回率
当你的系统问题更像下面这些情况时，优先保召回率通常更合理：
- 明明知识库里有答案，但系统像完全不知道
- 同类问题只要换个说法就召不回来
- 多文档问题经常漏掉关键来源
- 困难题表现远差于简单题
这些信号说明，你当前更大的风险是：
- 漏掉关键证据
这时更适合先做的通常是：
- 改善 query rewrite / expansion
- 调整 chunk 策略
- 优化混合召回
- 放宽候选池，再靠后续步骤做筛选
什么情况下应该优先保准确率
当你的系统问题更像下面这些情况时，优先保准确率更重要：
- 候选集里总有很多噪声
- 高分结果经常偏题
- 回答里经常混入无关信息
- 长上下文下模型越来越不稳
这说明你当前更大的风险是：
- 候选集太脏，后续链路被噪声污染
这时更适合先做的通常是：
- 增加或优化
Rerank - 改善 metadata filter
- 收紧
top k - 优化去重、聚合和最终上下文选择
一个更现实的平衡思路
很多时候，更稳的目标不是单独把召回率或准确率拉满，而是把系统做成两层：
第一层，候选集可以适度宽一些
目的是：
- 尽量不漏关键证据
第二层，最终上下文必须更干净
目的是：
- 不把大量噪声送进模型
这也是为什么很多生产系统会采用：
- 初次召回相对宽
- 后续
Rerank和选择相对严
不要把冲突理解成“二选一”
召回率和准确率虽然常常拉扯，但不代表它们永远只能此消彼长。更好的理解是：
- 不同阶段在优化不同目标
例如：
- 候选集阶段，适度偏召回率
- 最终上下文阶段，更偏准确率和可用性
这样你看到的就不是单一指标，而是一条分层链路。
一个很实用的判断信号
如果调大 top k 后，你发现：
- 检索层指标上去了
- 但生成层忠实性和端到端质量反而下降
这往往说明：
- 召回收益已经开始被噪声抵消
这时候继续一味追求更高召回，通常不是最优方向。
一句话总结
召回率和准确率经常冲突，因为前者更关心别漏，后者更关心别脏。更稳的做法不是单独把某一个指标拉满，而是在候选集和最终上下文两个阶段分别做平衡。