标准回答
Top-K 的含义
RAG 检索时会把用户 query 编码成向量，在向量库中计算与所有片段的相似度，然后按得分从高到低取出前 K 个片段，拼接进 prompt 作为上下文。这里的 K 就是「召回多少个候选片段」。
K 值的权衡
- K 太小：覆盖面不够，真正相关的片段可能排在第 K+1 名而被丢弃，导致答案不全或被迫编造。
- K 太大：把很多低相关片段也塞进上下文，既浪费 token、增加成本与延迟，又因「中间遗忘」（lost in the middle）稀释模型对关键信息的注意力，反而降低质量。
如何确定 K
- 算上下文预算：用窗口可用 token 除以平均片段大小，得到 K 的物理上限，给生成留足空间。
- 用验证集调优：在标注好的问答集上扫不同 K，看 Recall@K 与噪声/精度的权衡曲线，取拐点。
- 大召回 + rerank：先召回较大的 K（如 20
50），再用交叉编码 reranker 重排，取精排后的 top-n（如 35）进上下文。 - 动态 K：按问题复杂度自适应——简单事实题小 K，需要综合多来源的复杂题适当加大。
常见误区
⚠️ 常见踩坑
认为 K 越大召回越全、答案越好。实际上盲目调大 K 会引入噪声、抬高成本，并触发长上下文的注意力稀释，常常先升后降；K 不是越大越好，而要和片段大小、rerank 策略一起调。
追问
追问 1：Top-K 召回和 rerank 取 top-n 是什么关系？
两者是「粗排 + 精排」的级联。向量召回（Top-K）用双塔/近似最近邻，速度快但精度有限，所以放大 K 保证召回率；再用交叉编码 reranker 对这 K 个片段与 query 做逐对打分，取最相关的 top-n 进上下文。这样既不漏召回，又能把真正相关的片段排到前面、控制最终进 prompt 的数量。
追问 2：上下文窗口很大（比如几十万 token）时，是不是就可以把 K 设得很大？
不建议。窗口大只是放宽了物理上限，但更多片段意味着更多噪声和更高的「中间遗忘」风险，关键信息淹没在无关内容里，准确率反而下降，同时成本和延迟线性上升。大窗口下更应该靠 rerank 精排出少量高相关片段，而不是无脑塞满。
🔗 相似问题
同一考点的不同问法，面试官可能换着问，一起刷更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习