Top-K 表示从排序结果中取前 K 项，但系统里可能存在三个不同的 K：初次检索的候选数、交给重排器的数量，以及最终放进提示词的证据数。面试回答只说“取前五条”，很容易漏掉这一层区分。
假设正确答案排在向量检索第 12 位。初召回只取 5 条，后面的重排再好也救不回来；把最终 20 条全部塞进提示词，又可能增加噪声、延迟和费用。较大的候选池配合较小的最终证据集，通常更值得实验，但不是通用配置。
用两组指标定位问题
第一组是候选阶段的 Recall@K：已知有答案的问题，正确证据是否进入候选池。第二组是最终阶段的引用命中率和回答准确性：模型实际用到的片段是否支持结论。前者低，优先查查询改写、索引、过滤和初召回；前者高而后者低，再查重排、去重及上下文组装。
给 K 加预算约束也很重要。记录每次查询的候选数、最终证据数、token、延迟和失败样本，才能知道多取几条究竟带来了多少有效召回。K 是工程取舍，不是越大越安全的旋钮。
一次漏召回如何定位
假设标注集里某个问题的正确条款在向量结果第 18 位、关键词结果第 3 位，而融合后的候选第 6 位。若初召回各取 5 条，正确条款只能依赖关键词路径；若融合后只保留 5 条，它又会被截掉。此时改变生成模型温度没有意义。应先看每一级截断的日志，明确证据在哪一关消失。
还要区分“正确文档”和“正确片段”。命中了同一个 PDF 但只取到目录页，文档级 Recall 看似合格，回答仍然没有可用证据。对于多跳问题，单一正确片段也不够，候选集需要覆盖全部必要条件。这就是为什么评估样本最好标注支持结论的一组片段，而不只标一个文件名。
不同查询不一定共用一个 K
精确编号查询通常少量高质量候选就够；模糊、跨文档的问题可能需要更宽的初召回。可以先按查询类型做简单分流，但分流本身也会错，所以默认路径和回退策略必须可观察。不要因为平均延迟下降就忽略长尾问题的召回损失。
我会用一张对照表记录配置：候选 K、重排 K、最终证据 K、Recall@K、引用准确率、P95 延迟和 token 成本。只有在质量与成本一起看时，才能说明为什么某个 K 值值得上线。
一种可复现的调参顺序
先固定文档版本、查询集和重排器，只增加初召回 K，观察正确证据出现的比例何时趋于平缓。如果从 20 提到 40 只多救回一条低优先级问题，却让重排耗时明显上升，就没有必要继续放大。随后固定候选池，调整进入最终上下文的证据数量，观察答案与引用是否更准确。
两阶段实验必须分开，否则同时改初召回和最终上下文，难以解释性能变化。尤其要看“伪相关”片段：它们可能包含相同词，却省略了关键条件。最终证据数增加时，这类片段更容易干扰模型。对有严格延迟要求的应用，可以规定一个最高预算，超过预算就返回部分证据并要求用户缩小问题，而不是无限扩张检索链路。
多跳问题还需要另一种视角：若答案必须同时用到价格规则与审批规则，Recall@K 不能只问“命中了至少一段吗”，而要问“两类证据是否都进入了候选和最终上下文”。单个 K 值对两类问题表现可能截然不同，因此测试集要同时包含单证据和多证据样本。