RAG 检索怎样选择 top-k 并避免上下文过长

RAG 里把 top-k 设成 5、10 或 20，都不能直接当成通用答案。真正要先确定的是：本次请求给检索证据留多少 token，每个片段最多占多少空间，以及相似片段是否会重复表达同一事实。我的做法是“较宽召回、严格组装”：先用候选 top-k 捞出可能相关的片段，再经过过滤、重排和 token 预算裁剪，最后才交给生成模型。

官方文档：https://huggingface.co/docs/transformers/en/model_doc/rag

一、先把 top-k 和上下文预算分成两层

Hugging Face 的 RAG 接口把每个查询要检索的文档数量作为 n_docs，并把检索到的文档进一步组合成模型输入。这个接口关系说明了一个关键边界：检索数量和生成输入不是同一个变量。工程上可以把总上下文预算写成：

可用证据预算 = 模型上下文上限 - 问题 token - 系统指令 token - 历史消息 token - 回答预留 token。

例如模型允许 8192 token，本次问题和指令占 700，回答预留 1200，历史消息占 900，证据预算只有 5392。此时即使召回 20 个片段，也不能把 20 个片段原样拼进去。更稳妥的策略是先留出 10%～15% 的余量，避免 tokenizer 估算误差和模板字段突然增长。

二、候选 top-k 先宽一点，再按证据价值收敛

候选数过小，最容易出现“第一条相似但答非所问”的情况；候选数过大，则会增加重排、token 计算和上下文噪声。可以先把候选 top-k 设为最终证据数的 2～4 倍，再用元数据过滤和重排器缩小范围。这里的倍数只是起始实验值，不能脱离查询集直接固化。

过滤顺序建议保持可解释：先去掉租户、权限、文档状态不匹配的片段，再按相似度和新鲜度重排，最后处理同一文档或同一段落的重复内容。不要让低分片段仅因为数量够而进入 prompt。

def choose_context(candidates, budget, min_score=0.62, per_chunk_limit=700):
    # 先按分数过滤，避免低相关片段占用上下文
    ranked = [item for item in candidates if item["score"] >= min_score]
    ranked.sort(key=lambda item: item["score"], reverse=True)
    selected, used = [], 0
    seen_docs = set()
    for item in ranked:
        # 同一文档只保留一个代表片段，减少重复证据
        if item["doc_id"] in seen_docs:
            continue
        chunk_tokens = min(item["tokens"], per_chunk_limit)
        if used + chunk_tokens > budget:
            continue
        selected.append({"text": item["text"], "doc_id": item["doc_id"]})
        seen_docs.add(item["doc_id"])
        used += chunk_tokens
    return selected

示例中的 budget 是扣除其他输入后的证据预算，不是模型的总上下文上限。真实项目还应把权限过滤、同义片段去重和引用元数据放在同一个组装阶段里，避免检索层和 prompt 层各自重复处理。

三、用片段上限和去重防止长文档挤占上下文

top-k 只按“片段个数”计数时，长短片段的成本完全不同。一篇很长的命中内容可能单独吃掉大部分预算，让后面的独立证据没有位置。因此要同时设置单片段 token 上限和总预算上限。截断时优先保留标题、定义、条件、结论附近的完整句子，避免从中间切断参数或例外条件。

重复问题还会造成“相似度看起来很高，但证据覆盖面很窄”。可按文档 ID、章节 ID 或内容指纹做第一层去重；需要更高召回时，再用 MMR 一类的多样性重排，让结果覆盖不同来源或不同章节。生成模型最终看到的是“少量互补证据”，而不是相似片段排行榜。

四、把 top-k 调参变成可复现的检查清单

不要只看最终答案是否“像是对的”。准备一组带标准证据的查询，至少记录召回命中、引用覆盖、证据 token、平均延迟和超预算比例。先固定切分、embedding 模型、重排器和 prompt，再只改变候选 top-k 与最终证据上限，这样才能知道变化来自哪里。

最终可以把参数写成配置，而不是散落在代码里：candidate_k 控制召回池，evidence_budget 控制总 token，per_chunk_limit 控制单片段成本，min_score 控制最低相关度。这样每次评测都有清晰的变更记录。

相关问题

top-k 越大，RAG 一定越准吗？

不一定。它可能提高召回机会，也可能引入相似噪声、增加延迟并挤占生成预算，必须结合查询集评估。

最终证据数可以直接等于 top-k 吗？

只有在片段长度稳定、无重排和预算充足时才可能接近。更常见的做法是候选数大于最终证据数。

上下文预算不够时先删什么？

先删低相关、重复和超出单片段上限的内容，保留问题约束、关键条件、结论和来源标识；不要只按返回顺序硬截断。