RAG 召回结果为什么总被长文淹没：Go 用分桶候选集和 rerank 阶段控制上下文预算

知识库上线后，最先暴露的往往不是模型不会回答，而是召回列表被一篇超长手册占满：前 8 个 chunk 来自同一个文档，真正有用的故障记录反而没有进入上下文。一个稳妥的改法是先扩大候选集，再按来源分桶限制配额，最后才做 rerank 和 token 预算裁剪。

分桶解决“谁有资格进入候选集”，rerank 解决“候选里谁更相关”，上下文预算则决定“最终交给模型多少内容”；三层职责不要混在一个分数里。

长文为什么会挤掉真正有用的证据

向量检索按相似度返回结果时，长手册里的多个相邻切片可能都与问题相似。若直接取 topK，结果会出现“相似度很高，但来源单一”的假繁荣。Qdrant 的检索资料把召回与精排拆成两阶段：先用便宜的检索方法扩大候选，再把较小的候选集交给 reranker；这也是本文的架构边界。

这里的分桶不是把分数抹平，而是给同一来源设置代表名额。假设一次检索返回 24 个候选，每个来源最多留下 3 个，8 个名额就不会被同一份手册吃光。

先把候选集变成可控的分桶结构

示例只保留真实会参与后续流程的几个节点：retrieveCandidates 取回候选，bucketBySource 按来源分组，rerank 重新排序，buildContext 按预算拼接文本。生产代码可以把检索器和模型客户端换成真实实现，结构不需要跟着改变。

type Candidate struct {
    ID     string
    Source string
    Text   string
    Score  float64
}

func selectCandidates(ctx context.Context, query string) ([]Candidate, error) {
    raw, err := retrieveCandidates(ctx, query, 24)
    if err != nil { return nil, err }
    buckets := bucketBySource(raw)
    limited := make([]Candidate, 0, 8)
    for _, items := range buckets {
        sort.Slice(items, func(i, j int) bool { return items[i].Score > items[j].Score })
        if len(items) > 3 { items = items[:3] }
        limited = append(limited, items...)
    }
    return limited, nil
}

这个控制流的关键不是数字 24 和 3 本身，而是两个边界：检索失败直接返回，来源配额发生在 rerank 之前。图片中的 retrieveCandidates、bucketBySource 和 rerank 必须按这条真实调用链理解。

把 rerank 放在分桶之后

分桶后的候选数量更小，rerank 才不会把计算预算花在同一来源的重复切片上。rerank 分数只负责排序，不应成为“是否允许进入候选集”的唯一门槛；否则一个来源的高分段落仍可能重新垄断结果。

func answerContext(ctx context.Context, query string) (string, error) {
    candidates, err := selectCandidates(ctx, query)
    if err != nil { return "", err }
    ranked, err := rerank(ctx, query, candidates)
    if err != nil { return "", err }
    return buildContext(ranked, 1600), nil
}

当 rerank 返回后，buildContext 还要再次检查 1600 tokens 预算。排序靠前不等于文本一定能放下，长段落需要截断或跳过，并记录被预算淘汰的候选，便于复查答案为什么缺少某个来源。

上线时看三类信号，而不是只看模型回答

第一类是召回信号：固定一组问题和标注证据，观察 Recall@k；第二类是多样性信号：统计最终上下文的 source 数量及单一来源占比；第三类是预算信号：记录被 buildContext 丢弃的候选数量。Qdrant 的评估文档也建议让指标的 k 与实际送入模型的 chunk 数一致。

• 来源分布仍然极端：先调低每桶配额，不要先换 rerank 模型。
• Recall@k 下降：检查候选总量是否太小，以及分桶是否误删了唯一证据。
• 预算淘汰很多：优先缩短 chunk 或提取摘要，不要盲目把上下文上限翻倍。

常见问题

分桶会不会损失最高相似度结果？

会有可能，所以应先用固定评测集比较 Recall@k，再决定每桶配额。分桶的目标是降低单一来源垄断，不是保证每个最高分片都保留。

为什么不能直接把 topK 调大？

扩大 topK 可能增加重复来源和 rerank 成本，最终还会在上下文预算处被裁掉。先控制来源分布，再增加候选量更容易解释。

rerank 能找回未召回的证据吗？

不能。rerank 只能重新排列已有候选；问题需要的证据没有进入候选集时，应检查切片、查询改写或召回路径。

Go 示例里的 context.Context 该传到哪里？

从 answerContext 传入 selectCandidates，再传到 retrieveCandidates 和 rerank，让上游超时或取消能沿调用链生效。

落地前的最小检查

先用 20 到 30 条真实问题建立小型 golden set，分别记录候选来源分布、Recall@k、rerank 错误和上下文淘汰数。只有当分桶后的证据覆盖没有明显下降，再把配额和预算放进线上配置；保留旧配置作为回滚点，避免把一次模型换代和召回策略改动混成一个难以定位的问题。