RAG 检索结果为什么会被上下文窗口截断：召回排序与提示词预算怎么分配

知识库问答突然从“能引用原文”变成“只回答半句话”，很多时候不是向量检索失效，而是召回内容在进入模型前已经超过了可用预算。RAG 的输入还要容纳系统指令、用户问题、历史消息和输出预留，最后留给文档片段的空间比想象中小。

把 RAG 的上下文看成固定预算：先为问题、指令和输出留位，再让 retrieve 与 rerank 共同决定哪些片段进入 prompt；不要用固定 topK 代替预算控制。

先把“截断”定位到 RAG 的哪一层

一次请求通常经过 retrieve、rerank、budget 和 prompt 四个环节。retrieve 从向量库拿候选片段，rerank 按问题相关性重新排序，budget 计算可用额度，最后 prompt 才把片段、指令和问题拼成模型输入。

因此，“召回了 8 段”不等于“模型看到了 8 段”。长片段可能在预算裁剪时被淘汰；重复片段也会占掉空间；如果为输出预留得太少，服务端还可能在请求前主动压缩或拒绝输入。

先算可用额度，再决定召回多少

一个可复查的预算公式是：

budget = context_limit - system_tokens - history_tokens - question_tokens - output_reserve
if budget 

这里的 context_limit 是所选模型的输入上限，不能把产品宣传页中的最大上下文直接当成每次请求都能使用的文档额度。output_reserve 也不能省略：回答越长，输入可用空间越小。生产环境应把这几个数写入请求日志，至少记录候选数量、排序后数量、最终片段数量和估算 token。

如果历史消息已经很长，优先压缩历史或限制轮数，再减少知识片段。直接把 topK 从 8 改到 3，可能暂时不报错，却会把真正相关的片段一起删掉。

retrieve 放宽，rerank 负责收紧

向量检索适合先找“可能相关”的候选，但它对同义词、数字条件和跨段落关系并不总是敏感。更稳妥的做法是让 retrieve 返回一批候选，再由 rerank 综合问题词、标题、时间和片段长度排序。

排序时不要只看相关性分数。可以给重复文档降权，给包含关键实体的片段加权，并对超长片段先切分。最终选择应是“相关性达到阈值且没有超出 budget”，而不是“永远取前 5 个”。

三种最容易误判的截断现象

日志里的候选数很高，模型回答却缺证据

这通常说明候选在 retrieve 阶段存在，但没有通过 rerank 或后续预算裁剪。检查每个阶段的数量，不要只打印向量库返回的 topK。

短问题正常，长问题突然答非所问

长问题会同时吃掉问题预算和输出预算。可先限制历史消息，再把问题中的重复背景移到结构化字段，避免让同一段上下文出现两次。

片段数量没变，内容却变短

这常见于按 token 上限截取单个片段：片段仍然保留在列表里，但正文只剩前半段。日志要记录每个片段的原始长度与进入 prompt 后的长度，并在切分处保留段落或代码块边界。

上线前用一组可重复的检查收口

准备一条包含专有名词、数字和反例的测试问题，分别记录 retrieve 候选、rerank 顺序、budget 剩余值和最终 prompt 长度。把输出预留从小到大调整一次，观察证据片段是否按预期变化。

当预算不足时，降级顺序可以是：先删重复历史，再压缩低优先级片段，最后明确返回“证据不足”。不要悄悄把最相关片段裁掉后仍输出确定语气，这会让检索问题看起来像模型幻觉。

相关问题

RAG 的 topK 越大越准确吗？

不一定。topK 只决定候选规模，真正影响回答的是相关片段是否经过排序、去重和预算裁剪。

应该先截断历史还是先减少文档？

如果历史只是闲聊，先压缩历史；如果历史包含用户约束或上轮结论，就保留它并减少低分文档。关键是把取舍记录在日志中。

怎么确认是模型上下文限制而不是检索失败？

对比向量库候选、排序结果和最终 prompt：候选中有证据、排序后仍在、但组装后消失，基本就是预算或拼接策略的问题。

RAG 的稳定性来自可观察的预算，而不是堆更多片段。只要把 retrieve、rerank、budget、prompt 四个节点的输入输出记清楚，截断就能从“偶发玄学”变成可定位的工程问题。