RAG 检索结果为什么会被长文档淹没：分块元数据、重排阈值与上下文裁剪

知识库问答出现“明明搜到了，回答却抓不住重点”时，问题往往不在生成模型，而在送进上下文的候选太长、太杂。一个 2 万字的制度文档如果只切成几块，命中一块就等于把大量无关条款一起搬进提示词；反过来，切得很碎却没有保留章节和版本信息，重排也很难判断段落属于哪个业务范围。更稳妥的做法是让分块元数据参与召回，再用两阶段候选和上下文裁剪把最终输入收窄。

RAG 的关键不是把 top_k 调大，而是先用分块元数据保证候选可解释，再用 dense 与 sparse 召回扩大覆盖，重排后只保留能支撑答案的片段，并按令牌预算裁剪。

长文档是怎样把正确片段挤出上下文的

一次客服检索可能同时命中“退款规则”“企业客户例外”和“旧版协议”。如果 chunk 没有 section、version，应用层只能看到三段相似文字，无法在回答前过滤过期版本。切块长度也不是越大越稳：大块提高了单次命中的覆盖面，却把无关条款一起带入；小块降低噪声，却可能把条件和例外拆开。

先把每块资料约束成可追踪对象，后续每一层都能解释“这段为什么被选中”。本例的输入结构只保留和回答有关的字段：

type Chunk struct {
    Document string
    Section  string
    Version  string
    Order    int
    Text     string
    Tokens   int
}

func eligible(c Chunk, version string) bool {
    return c.Version == version && c.Text != ""
}

这里的 Document、Section、Version、Order 和 Tokens 都会进入后续的筛选、排序或预算计算，不能只在写入向量库时临时丢掉。

先用两路召回扩大覆盖，再避免分数硬拼

用户问“合同里允许提前解约吗”，语义检索容易找到“解除协议”，关键词检索则更容易抓住“提前解约”这四个字。两路都能召回，但 dense 分数和 sparse 分数不一定处在同一尺度，直接做固定权重相加会让其中一路长期压过另一条路。

工程上可以让 dense 和 sparse 各取一批候选，再把去重后的结果交给重排器。Qdrant 官方的混合与多阶段查询文档也采用了先 prefetch、后主查询的路径；重排模型只处理较小候选集，成本和延迟更容易控制。本例把流程写成明确的阶段，而不是把所有结果直接塞给模型：

type Candidate struct {
    Chunk Chunk
    Score float64
    Rank  int
}

func mergeCandidates(dense, sparse []Candidate) []Candidate {
    seen := make(map[string]bool)
    merged := make([]Candidate, 0, len(dense)+len(sparse))
    for _, list := range [][]Candidate{dense, sparse} {
        for _, c := range list {
            key := c.Chunk.Document + ":" + c.Chunk.Version + ":" + string(rune(c.Chunk.Order))
            if !seen[key] {
                seen[key] = true
                merged = append(merged, c)
            }
        }
    }
    return merged
}

实际调用可以约定 dense top 20 和 sparse top 20，合并后交给重排器，最终只取 重排 top 10。这三个数字不是通用答案，而是一个可观测的起点：需要用真实问题集检查召回覆盖率、重复率和最终答案引用是否完整。

重排之后还要做一次上下文裁剪

重排解决的是“哪些片段更相关”，没有自动解决“这些片段加起来是否装得下”。应用层应该把模型输入留出系统提示、用户问题和回答余量，剩下的才是 token_budget。片段按分数从高到低检查，超过预算时跳过低优先级项；如果业务要求答案覆盖同一条款的条件和例外，还要用 Section 或 Order 做成组保留，而不是只看单段分数。

func cropContext(items []Candidate, tokenBudget int) []Chunk {
    used := 0
    kept := make([]Chunk, 0, len(items))
    for _, item := range items {
        if used+item.Chunk.Tokens > tokenBudget {
            continue
        }
        kept = append(kept, item.Chunk)
        used += item.Chunk.Tokens
    }
    return kept
}

这段代码故意保持简单：它展示的是“重排结果进入预算门”的控制流，不是完整的 token 计算器。生产代码还应记录被裁掉的 Document、Section、Order，这样回答缺少依据时能复盘到底是没召回，还是被预算淘汰。

把一次检索变成可回放的验收记录

每次回答至少记录四组事实：问题文本、过滤条件、两路候选的数量、最终保留的片段及其版本。不要只记录最终 prompt；否则出现旧版条款混入时，只能重新猜测是哪一层出了问题。

如果低分片段被裁掉后，答案质量明显下降，先看它是否承载了一个例外条件，而不是盲目增大 token_budget。更好的修复可能是调整切块边界、保留同章节相邻片段，或者在元数据过滤阶段排除旧版本。

相关问题

为什么 top_k 越大，答案反而更乱？

候选变多会带来更多相似但不适用的段落，模型需要在有限上下文里自行区分版本、章节和例外。先改善元数据过滤与重排，通常比单独增大 top_k 更有效。

dense 和 sparse 的分数可以直接相加吗？

不建议默认这样做。两种检索分数的尺度可能不同；可以按排名融合，或先用真实评测集做归一化和权重调参。

上下文裁剪应该发生在重排前还是后？

两处都可以有边界控制，但最终裁剪应发生在重排后。先缩小重排输入控制成本，再按最终相关性和 token_budget 选择送给模型的片段。

如何判断是召回漏了，还是裁剪丢了？

同时保存两路候选、重排结果和裁剪结果。目标片段出现在候选却不在最终上下文，说明预算或组装规则有问题；候选里根本没有，才回到切块、过滤和召回参数排查。

让 RAG 的每一段上下文都能说明来处

长文档场景的稳定性来自可解释的流水线：分块时保留元数据，两路召回分别记录，重排只处理去重后的候选，最后用预算裁剪并留下被舍弃项。这样调参时能明确知道是在扩大覆盖、提升排序，还是保护模型输入长度，而不是把所有问题都归咎于生成模型。