RAG 检索结果去重与上下文长度控制

RAG 检索结果去重，重点不是把列表简单截短，而是先分清“同一份证据的重复出现”和“不同证据恰好讨论同一个概念”。实用做法是三层收敛：先按稳定的 doc_id 去掉同源重复，再按规范化文本处理近似重复，最后用相关性与多样性共同决定哪些片段进入上下文。上下文长度也要单独预算，不能把召回的 top_k 当成最终输入数量。

官方资料：https://huggingface.co/docs/transformers/main/pad_truncation

语义检索参考：https://sbert.net/examples/sentence_transformer/applications/semantic-search/README.html

先定义去重键，别一上来就调相似度

一次召回里，最可靠的信号通常来自元数据。若两个片段的 doc_id 和版本相同，只保留分数更高或覆盖范围更完整的那一条；若只是标题相同但来源、版本或发布日期不同，应保留并在上下文里标出来源。没有稳定 ID 时，才退回到去空白、统一大小写和折叠连续标点后的文本指纹。

两层筛选比单一阈值更稳

第一层是确定性的过滤：按 doc_id 分组，再在组内保留召回分数最高的片段；随后对规范化文本做精确去重。第二层才处理语义重复。Sentence Transformers 的语义检索接口会返回按余弦相似度排序的候选及其分数，这个分数适合做相对排序，不宜直接当成跨模型通用的绝对阈值。

如果问题是“同一答案的多个改写不要同时出现”，可以用相似度阈值；如果问题是“相关结果太集中”，应使用 MMR。MMR 同时考虑查询相关性和候选之间的差异，lambda 越偏向相关性，结果越容易相似；越偏向多样性，越可能引入边缘证据。

上下文长度要按槽位分配

上下文预算不是“模型支持多少就塞多少”。实际输入至少包含系统指令、用户问题、证据片段和回答余量，还要留出消息格式与特殊 token 的空间。Hugging Face Transformers 文档明确区分了 truncation、max_length 和 padding；把截断交给默认行为，可能在最不希望丢失的尾部证据处发生裁剪。

可以先固定总预算，再扣除系统指令和问题，最后用剩余预算装入去重后的证据。每个证据进入前估算 token 数，超过余量就停止；不要把一段证据硬切成半句，必要时回到上游重新切块。

用一个库无关函数完成筛选和装箱

下面的代码不绑定向量数据库或模型，score 由上游召回器提供，token_count 应替换为目标模型对应的 tokenizer。示例先做稳定去重，再按预先计算的相似关系剔除近重复，最后按 token 预算装箱。

from dataclasses import dataclass
import re

@dataclass
class Hit:
    doc_id: str
    text: str
    score: float
    token_count: int

def normalize(text: str) -> str:
    # 只消除格式噪声，不把不同来源的正文强行改写成相同内容。
    return re.sub(r"\\s+", " ", text).strip().casefold()

def pack_context(hits, budget, near_dup=0.92):
    selected, seen_ids, seen_texts, used = [], set(), set(), 0
    for hit in sorted(hits, key=lambda item: item.score, reverse=True):
        # doc_id 相同表示同源证据，优先保留得分更高的片段。
        key = (hit.doc_id, normalize(hit.text))
        if hit.doc_id in seen_ids or key in seen_texts:
            continue
        # 这里的近重复分数需由实际 embedding 组件预先计算。
        if any(similarity(key[1], old) >= near_dup for old in seen_texts):
            continue
        if used + hit.token_count > budget:
            # 不截半段证据，把剩余空间留给回答而不是硬塞文本。
            continue
        selected.append(hit)
        seen_ids.add(hit.doc_id)
        seen_texts.add(key[1])
        used += hit.token_count
    return selected, used

生产实现中，similarity 不能用字符串比较代替；它应接入与召回阶段一致的向量模型。若候选来自多个来源，还应把来源、版本和发布日期拼进展示模板，让模型知道两段相似内容是否真的可以互相替代。

用四个指标调参数

不要只看回答是否“感觉变好了”。至少记录召回候选数、去重后保留数、上下文使用 token、近重复丢弃数和最终截断次数。保留率过低，先检查 doc_id 是否错误复用；重复率仍高，调高 MMR 的多样性权重或降低近重复阈值；截断次数大于零，优先减少召回深度或缩短单块，而不是继续扩大 prompt。

一个可操作的验收线是：同一文档的重复片段不再占据前几名，不同来源的关键证据仍能同时出现，context 使用量稳定低于模型上限，并且答案引用的事实能回指到保留片段。阈值应按模型、语料和切块策略单独校准。

相关问题

去重应该发生在向量召回前还是后？

两处都可以做，但职责不同。入库前去重降低索引噪声，召回后去重负责处理版本、切片和查询相关性，不能只依赖其中一处。

相似度阈值能直接跨模型复用吗？

不能。不同 embedding 模型、归一化方式和语料分布会改变分数范围，应使用标注样本或离线查询集重新校准。

上下文不够时先删哪类内容？

先删低相关且与已保留片段高度相似的内容，再缩短冗余元数据；不要先删用户问题、系统约束或唯一的关键证据。