RAG top-k 怎样结合 rerank 控制上下文长度

RAG 的 top-k 与 rerank 应分工控制：先用召回 top-k 提供候选，再让 rerank 排序，最后按生成模型的 token 预算装入片段。最终取几段只能作为数量上限，不能代替上下文长度检查。片段长短不一，即使都只取三段，最终请求也可能差很多。

官方地址：https://www.sbert.net/examples/sentence_transformer/applications/retrieve_rerank/README.html

把召回数量与上下文上限分开

建议给参数起不混淆的名称：retrieve_k 是召回候选数量，rerank_keep 是重排结果中最多考虑的条数，context_limit 是本次部署允许的上下文总额。文档片段、系统指令、问题、历史消息和回答预留共同竞争这个总额，而不是把全部额度都给检索文档。

重排候选集包含片段标识与正文，rerank 分数用于排序，最终片段集只是其中符合本轮预算的子集。重排不能找回召回阶段遗漏的文档，也不能保证高分片段一定包含完整答案。

确认重排输入与生成模型各自的限制

选型时分别阅读检索器、重排模型和生成模型的接口约定。常见 Cross-Encoder 会对问题与候选片段联合打分，适合处理一个受控候选集合；它自身能接收多长的输入，不能直接套用生成模型的窗口。

生成侧要用实际模型对应的 tokenizer 和聊天模板。Hugging Face 的聊天模板把角色消息变成含控制 token 的序列；只把正文 token 相加会漏掉包装。若服务端还注入额外消息、工具定义或其他字段，本地计数也必须包含这些内容，无法完全一致时应保留余量并采用服务提供的权威计数方式。

本例限于单模态文本、已配置好聊天模板的本地 tokenizer，不选择具体模型，也不承诺某个固定窗口、价格或 rerank 阈值。context_limit 必须取部署实际支持值，不从一个不明来源的巨大 tokenizer 默认数值直接推断。

按完整消息试装候选片段

下面是预算打包函数，不执行召回、重排或模型推理。调用方传入已排序且已满足自身相关性要求的候选，每项包含稳定的 id 和 text。代码在加入每个片段后重新计算完整消息，包括片段编号和引用标识。

def pack_context(tokenizer, question, ranked,
                 context_limit, output_reserve, safety_margin,
                 rerank_keep=8):
    # 总额与回答预留由部署配置提供，不能按字符数估算
    if min(context_limit, output_reserve)  input_limit:
        raise ValueError("问题和固定消息已超预算")

    selected, seen = [], set()
    skipped = []
    for chunk in ranked[:rerank_keep]:
        if chunk["id"] in seen:
            continue
        seen.add(chunk["id"])
        if not chunk["text"].strip():
            continue
        trial = selected + [chunk]
        if count(trial) 

这是一种按重排顺序贪心试装的简单策略，不是最优组合求解。evidence_sufficient 在这里仅表示“至少有一段装入”，不是对答案充分性的判断；接入层仍需做自己的证据适用性判断。选中结果为空时，不应把空资料当成检索成功；可返回资料不足或要求用户缩小问题。

例如候选中有一篇较长说明书和几段短条款，长文放不下会被记录并跳过，后续短条款仍有机会入选。不能为了填满额度而把多个近重复片段同时塞入；代码只按 ID 去重，重叠内容的识别需在调用前另行处理。本文未运行模型，示例没有虚构命中率或延迟数据。

在超长片段与重排失败时保留退路

超长片段可以回到索引或候选准备阶段按段落、标题等边界重新切分，但要保留出处和必要上下文。若重新切分或摘要改变了候选内容，原来的重排分数未必还能直接代表新内容。不要在最终请求处静默截掉末尾，导致来源编号还在、支撑结论的文字却没了。

重排服务超时与没有相关文档是两种状态。是否退回原召回排序，应由业务事先约定并标注降级；即便降级也仍要执行同一输入预算。模板不兼容、tokenizer 不匹配或计数失败时，不能把失败值当作零，也不应用字符长度替代后继续发送。

分别记录重排成本与最终上下文

调参时把成本拆开记录：候选数、实际参与重排数、重排耗时、装入片段数、完整输入 token、输出预留和被预算排除的片段标识。扩大 retrieve_k 可能增加重排工作量，却不必增加最终输入；提高 rerank_keep 也不必让最终片段数增加，因为预算约束仍在。

调参试验应固定语料版本、切分方式和问题集，分别观察证据覆盖与预算排除原因，不能把“更短”直接当成“更好”。日志优先保存文档 ID、配置版本和计数，避免默认记录完整私有文档。检索内容仍是不可信数据，不能让其中的指令覆盖系统要求；预算打包不解决提示注入或数据授权问题。

rerank 保留三条就不会超上下文吗？

不会自动保证。三条的长度、引用包装及历史消息都可能变化，必须按最终消息计数。

top-k 应该设成多少？

没有适用于所有语料和模型的固定答案。依据候选覆盖、重排资源与延迟要求选择，并与最终输入预算分开设置。

余量越大越安全吗？

余量能覆盖部分计数差异，但会减少证据空间。它不能修复错误模板或错误的部署窗口配置。

参考：Sentence Transformers 检索与重排、Hugging Face 聊天模板。