top-k 要分两级看
top-k 在管线里其实有两个：检索阶段的候选池，通常取 20 到 100 条，供重排挑选；重排或截断后真正进入提示词的上下文条数，通常取 3 到 10 条。候选池过小会让重排没有选择余地，上下文条数过大则稀释信息并抬高成本，两者需要分别调优。
基本信息
| 候选池（retrieve k） | 20 到 100 条，决定重排的上限 |
|---|---|
| 上下文条数（top_n） | 3 到 10 条，决定生成输入的长度 |
| 调参依据 | 召回命中位置分布与答案完整性 |
| 联动关系 | 候选池与最终条数要一起调，不能只动一个 |
两级 top-k 配置示例
两级 top-k 配置示例
RETRIEVE_K = 50 # 向量/混合检索候选池
RERANK_N = 8 # 重排后进入上下文的片段数
candidates = vector_store.search(q_vec, top_k=RETRIEVE_K)
top_docs = rerank(q, candidates, top_n=RERANK_N)
context = build_context(top_docs)使用要点
- 先统计正确答案在召回结果里的排名分布，据此定候选池深度
- 候选池覆盖 90% 以上正确答案的排名即为合理下限
- 加入重排后再逐步压缩上下文条数，观察答案完整性变化
- 按问题类型分别调：多跳与概括类问题往往需要更深的候选池
- 把两级参数与评测结果一起记录，方便回溯是哪次调整带来的变化
两级参数对照
| 参数 | 调大的收益 | 调大的代价 |
|---|---|---|
| 候选池 | 正确答案进入重排的机会变大 | 粗排与重排耗时上升 |
| 上下文条数 | 信息更全、跨段问题更易答 | 输入变长、成本上升、中间内容被忽略 |
常见问题
- 检索只取 3 条再接重排：重排只是在三条里排序，收益有限
- 只加候选池不看上下文预算：生成端输入超限被截断
- 所有问题用同一套参数：简单问题浪费预算，复杂问题召回不足
- 改参数后未重跑评测：无法判断是变好还是变差
升级到重排管线时，候选池要单独重新调；候选池与最终条数同步放大，往往就是上下文超长与成本上升的来源。