10.2.2 TopK、Rerank、上下文长度之间如何平衡？

先给结论：TopK、Rerank、上下文长度不是三组独立参数，而是一套联动系统。TopK 决定候选池有多宽，Rerank 决定谁能留下，上下文长度决定最终能装多少信息。三者如果分开调，很容易出现“召回更多却答得更差”的问题。

很多人调 RAG 时，会把这三个问题拆开看：

• 先调 TopK
• 再看要不要加 Rerank
• 最后再看上下文长度够不够

但真实系统里，这三个旋钮通常是一起作用的。

先理解三者分别在做什么

TopK 决定候选池宽度

它回答的是：

• 初次召回后，准备拿多少结果进入后续阶段

TopK 太小，可能漏掉关键证据；太大，则可能把太多噪声带进来。

Rerank 决定保留顺序

它回答的是：

• 候选池里的结果，谁更应该排前面

如果没有 Rerank，你通常会更依赖初排相似度；但初排相似度并不一定最适合最终问答。

上下文长度决定最终装载上限

它回答的是：

• 最终到底能把多少证据送给模型

长度太短，可能装不下关键材料；长度太长，又可能引入：

• 长上下文噪声
• 证据顺序问题
• 成本和延迟上升

为什么三者必须一起看

因为它们实际上在共同决定一个问题：

• 最终哪些证据能以什么顺序进入模型

举个很典型的例子：

• TopK 调大了
• 候选池变宽了
• 但没有 Rerank
• 上下文长度又有限

结果可能是：

• 候选更多
• 但真正关键的证据没有被稳定排进最终上下文

这时你表面上做了“更努力的召回”，结果却未必更好。

三种常见失衡情况

第一种，TopK 太小

常见表现：

• 简单题还行，复杂题经常漏证据
• 多文档问题经常缺一个关键来源
• 同类问题偶尔能答对，稳定性很差

这通常说明候选池太窄，关键结果没有稳定进入后续阶段。

第二种，TopK 很大，但没有足够强的选择机制

常见表现：

• 候选很多，但噪声也很多
• 最终上下文里经常塞满重复或边缘相关内容
• 生成层忠实性和聚焦能力下降

这通常说明：

• 你放宽了入口
• 但没有管好出口

第三种，上下文长度被当成万能补救手段

有些团队一发现答案不完整，就倾向于：

• 直接把上下文塞得更长

但这经常会带来：

• 成本升高
• 延迟增加
• 长上下文排序问题更明显
• 模型对关键证据的注意力反而下降

所以“装得下”不等于“用得好”。

更稳的平衡思路

一个更现实的思路通常是下面这样：

第一步，先让 TopK 足够覆盖关键证据

这里的目标不是无上限扩大，而是：

• 让正确证据有合理概率进入候选池

第二步，用 Rerank 或结果选择把噪声压下去

如果候选池已经足够宽，下一步更重要的是：

• 让真正重要的证据更稳定地进入前列

第三步，控制最终上下文只保留“足够用”的证据

最终送给模型的上下文不应该追求最大，而应该追求：

• 相关
• 完整
• 少重复
• 顺序合理

什么情况下优先动 TopK

当你发现：

• 正确结果经常根本不在候选里
• 多文档问题经常漏来源
• 小 K 下 recall 明显不足

这时更适合先放宽候选池。

什么情况下优先动 Rerank

当你发现：

• 正确结果其实已经在候选里
• 但排序不稳、位置偏后
• 噪声和重复结果占掉大量前排位置

这时更适合优先加强 Rerank 或最终选择逻辑。

什么情况下优先控制上下文长度

当你发现：

• 最终 prompt 非常长
• 回答开始漏关键条件
• 延迟和成本快速上升
• 长上下文下模型稳定性下降

这时更适合收紧最终上下文，而不是继续塞更多。

一个最小联动判断示意

def tune_retrieval_budget(case):
    if not case["gold_evidence_in_candidates"]:
        return "increase_topk_or_improve_recall"
    if case["gold_evidence_ranked_low"]:
        return "improve_rerank"
    if case["final_context_too_long_and_noisy"]:
        return "reduce_context_and_improve_selection"
    return "keep_current_balance"

这个示意想强调的是：

• 三者不是独立按钮
• 而是一条预算分配链

一句话总结

TopK 决定你愿意先拿多少，Rerank 决定你最终留谁，上下文长度决定你到底装多少。三者必须一起平衡，否则很容易出现“候选更多、成本更高、答案反而更差”的情况。