向量检索为什么召回很多无关片段：相似度阈值、元数据过滤与重排判断

知识库上线后的第一个投诉往往不是“模型不会回答”，而是“明明搜的是退款规则，结果里混进了发票、配送和旧版本说明”。这类无关片段多，通常不是把 embedding 模型换掉就能解决：候选范围太宽、相似度分数没有按数据集校准、元数据没有前置过滤，都会把噪声一路送进上下文。

更稳的处理顺序是：先用元数据缩小可搜索集合，再用相似度阈值挡住明显不合格的候选，最后只对一个可控数量的候选做重排；每一层都要保留命中数和分数分布，才能知道噪声到底从哪里进来。

先看症状：无关片段是在召回层混进来的吗

先固定一个问题，例如“企业版订单如何申请退款”，把检索链路拆成四个观测点：原始查询、过滤条件、向量候选、送入模型的最终片段。每个候选至少记录 chunk_id、document_id、version、相似度分数和最终是否入选。

如果 topK 前十里有六个片段来自“配送时效”，说明召回阶段已经偏了；如果前十基本相关，但送进模型的上下文里又混入旧版本，问题更可能出在去重、拼接或版本过滤。先分层，别一上来修改提示词。

query = "企业版订单如何申请退款"
filters = {
    "tenant_id": "acme",
    "product_line": "enterprise",
    "status": "published"
}

for hit in retrieve(query, filters=filters, limit=20):
    print(hit.chunk_id, hit.score, hit.payload["version"])

第一道收敛：把确定性条件放进元数据过滤

租户、产品线、语言和发布状态不是语义相似度能可靠表达的条件。查询“退款”可能同时接近中文和英文文档，也可能接近草稿与正式规则；如果这些条件已经存在于 payload，就应该在向量检索时一起过滤。

以 Qdrant 的查询思路为例，向量负责打分，过滤负责缩小集合。字符串字段还要区分精确匹配和全文匹配：tenant_id、status 这类字段适合精确的 keyword 条件，不能把它们当成一段正文去做语义相似。

filter = {
  "must": [
    {"key": "tenant_id", "match": {"value": "acme"}},
    {"key": "product_line", "match": {"value": "enterprise"}},
    {"key": "status", "match": {"value": "published"}}
  ]
}

hits = client.query_points(
    collection_name="help-center",
    query=query_vector,
    query_filter=filter,
    limit=20,
    with_payload=True
)

过滤后候选数突然从 20 变成 3，不一定是坏事。先确认过滤索引和字段写入是否正确，再判断知识库是否真的缺内容。把条件放到应用层事后丢弃，既浪费检索预算，也可能让本来相关的片段在 topK 截断前就被无关数据挤掉。

第二道收敛：阈值要从分数分布里校准

score_threshold 适合挡掉明显低于接受线的结果，但“0.5 一定相关”不是通用结论。余弦相似度、点积和欧氏距离的数值方向可能不同，同一模型换一批文档后分布也会变化。尤其是欧氏距离，数值更小通常更接近，阈值方向不能照搬相似度的经验。

更实际的做法是准备一小组人工标注问题：每个问题标出至少一个可回答片段和几个容易混淆的片段，记录 top20 的分数。先看相关与不相关样本的重叠区，再选择一个让“明显不相关”大多被挡掉、又不会把唯一正确片段一起挡掉的阈值。

# 阈值只是示例，必须按当前模型和数据集校准
result = client.query_points(
    collection_name="help-center",
    query=query_vector,
    query_filter=filter,
    limit=20,
    score_threshold=0.62,
    with_payload=True
)

if not result.points:
    # 空结果应进入“扩大候选或转人工”的分支，不能伪造上下文
    return {"status": "no_grounded_context"}

阈值带来的空结果要有明确产品策略：可以在同一过滤范围内放宽阈值、改用关键词补搜，或者提示用户换一种问法。不要把空结果默默替换成全库 topK，否则系统看起来“总能回答”，但事实边界已经消失。

第三道收敛：候选集放大，再交给重排模型判断

向量检索擅长快速找一批候选，却不一定擅长区分“退款条件”和“退款入口”这种细粒度差异。可以先取 20 到 50 个候选，再用更精细的重排模型或确定性的业务加权重新排序，最后只把前 5 个片段拼进上下文。

候选集不能无限放大。重排本身更贵，候选过多还会把同一文档的相邻片段重复送入模型。实际运行中要同时记录 retrieval_top_k、rerank_top_n、平均分和最终上下文 token 数，找到质量与延迟的平衡点。

candidates = dense_search(
    query_vector,
    filters=filter,
    limit=30,
    score_threshold=0.55
)

reranked = reranker.rank(
    query="企业版订单如何申请退款",
    documents=[item.text for item in candidates]
)

context = deduplicate_by_document(reranked)[:5]

重排不是事实校验器。它只能改善候选顺序，不能补齐知识库里不存在的退款条件，也不能替代版本、租户和权限过滤。确定性规则先做，模型判断后做，故障时才有清晰的回退路径。

一次上线取舍：质量、延迟和空结果如何平衡

一个可落地的初始配置可以是：元数据先过滤，向量候选取 30 条，阈值从离线标注集校准，重排保留 5 条，再按 document_id 去重。这个数字只是起点，真正需要观察的是命中质量和尾延迟。

• 无关片段多：先检查过滤条件是否缺失，再检查阈值是否过宽。
• 正确片段经常进不了前五：扩大初始候选，查看重排前的排名和分数。
• 延迟明显上升：缩小重排候选，减少重复 chunk，并把昂贵的重排限制在需要的查询上。
• 空结果变多：核对 payload 写入、过滤字段类型和阈值方向，不要直接回退到全库搜索。

上线验收：四个数字要能解释

每次检索至少留下一份可关联的调试记录：过滤前候选规模、过滤后候选规模、阈值截断数量、重排后保留数量。再从人工问题集中抽查“正确片段是否出现”“最终前五是否包含旧版本”“无答案问题是否真的返回空”。

{
  "query_id": "q-20260826-001",
  "filter_hits": 1842,
  "vector_hits": 30,
  "threshold_dropped": 11,
  "rerank_kept": 5,
  "grounded": true
}

如果过滤后命中数为零，先看数据；如果阈值丢掉的比例突然升高，先看 embedding 模型或数据分布；如果重排后经常换掉第一名，先确认重排模型是否与语种、领域匹配。这样排查比盯着最终回答猜原因快得多。

常见问题

相似度分数越高就一定越相关吗？

不一定。分数依赖模型和距离度量，只能在相同检索配置与相近数据分布内比较。业务上应通过标注问题集校准阈值，并保留分数分布。

元数据过滤会不会让召回率下降？

会，如果字段值写错、索引缺失或过滤条件过严，就可能把正确文档排除。它的价值在于提前排除确定不可能入选的对象，因此需要把过滤命中数作为监控指标。

有了重排模型还需要相似度阈值吗？

通常仍需要。阈值先挡住明显无关候选，重排再处理边界候选；若把所有低质量片段交给重排，成本和误选风险都会上升。

为什么 topK 调大后回答反而变差？

更多候选可能带来重复、旧版本和相邻但不回答问题的片段，模型的上下文注意力也会被稀释。应把候选集大小、重排数量和最终 token 数一起调，不要只扩大 topK。

落地清单：让每次“召回变脏”都能定位

把租户、产品线、语言、版本和发布状态等确定性条件放在过滤层；把阈值当成需要校准的参数；把重排限定在有限候选集；把过滤、截断、重排和最终上下文都写入可关联日志。下一次无关片段增多时，团队就能指出是数据、过滤、阈值还是排序出了问题，而不是继续盲目更换模型。