向量数据库召回分数怎么设阈值：Go 中用候选分层避免低相关答案

RAG 服务最难排查的一类问题，不是接口报错，而是答案看起来很完整，却悄悄引用了另一份文档。常见诱因是召回阶段只取 topK，没有判断候选是否真的够相关。向量数据库的分数阈值可以挡住低相关片段，但阈值必须和模型、距离度量以及业务容错一起确定，不能把网上的 0.7 直接复制到生产环境。

先确认分数是“越大越相似”还是“越小越相似”，再用一组已标注的问题调出候选阈值；线上还要保留候选不足的兜底分支，避免把“没有可靠依据”误写成正常答案。

先把“分数高”这句话说清楚

不同向量距离的分数方向并不统一。Qdrant 文档说明，score_threshold 会排除比阈值更差的结果，但“更差”取决于使用的 metric：相似度类度量通常是分数越高越好，距离类度量则可能相反。调参前先在一条真实查询上打印候选的 id、score 和正文摘要，确认排序方向。

以 cosine 相似度为例，下面的阈值只表示一个待验证的起点。它不是模型的通用常数，也不应在文章、模型或切片策略改变后继续沿用。

让候选从召回到答案经过三道门

把检索链拆成三个清晰的节点：SearchCandidates 负责向量库查询，filterCandidates 负责执行 score_threshold 与业务过滤，GenerateAnswer 只接收通过检查的片段。这样日志能回答“是没有召回，还是召回后被过滤掉了”。

type Candidate struct {
	ID      string
	Score   float64
	Content string
}

func answerWithEvidence(query string, threshold float64) (string, error) {
	candidates, err := SearchCandidates(query, 8)
	if err != nil {
		return "", err
	}

	accepted := filterCandidates(candidates, threshold)
	if len(accepted) == 0 {
		return "", ErrNoReliableEvidence
	}
	return GenerateAnswer(query, accepted)
}

func filterCandidates(items []Candidate, threshold float64) []Candidate {
	accepted := make([]Candidate, 0, len(items))
	for _, item := range items {
		if item.Score >= threshold {
			accepted = append(accepted, item)
		}
	}
	return accepted
}

这张图对应的重点不是“AI”四个字，而是调用边界：SearchCandidates 先产生候选，filterCandidates 过滤低分项，只有剩余片段才进入 GenerateAnswer。生产日志也建议按这三个节点分别记录数量，不要只记录最终回答耗时。

阈值、topK 和上下文预算要一起调

阈值过低，串题片段容易混进上下文；阈值过高，正确片段可能全部被挡掉。topK 解决的是“最多看多少候选”，阈值解决的是“最低接受到什么程度”，两者不是替代关系。

可以先准备一小组带有期望文档的测试问题，记录每个问题的第一条正确片段分数、最高错误片段分数和过滤后的数量。然后按业务偏好选择阈值：如果错答代价高，优先让错误片段少进来；如果漏答代价更高，再降低阈值并增加后续的重排或人工确认。

• 先固定 embedding 模型和切片规则，再比较阈值。
• 每次只改一个变量，保留问题集、候选分数和最终命中情况。
• 混合检索时，语义分数与词法分数不要直接当成同一把尺子比较。

候选不足时不要强行生成

过滤后的列表为空或只有一条时，应用层需要一个明确策略。对知识库问答，可以返回“当前资料不足，请补充关键词”；对客服场景，可以转人工或改走关键词检索。下面的 fallback 是状态分支，不是把低分片段偷偷塞回上下文。

func answerOrFallback(query string, threshold float64) (string, string, error) {
	candidates, err := SearchCandidates(query, 8)
	if err != nil {
		return "", "search_error", err
	}
	accepted := filterCandidates(candidates, threshold)
	if len(accepted) 

这里把 fallback 和 GenerateAnswer 分成两条可见路径，排查时可以直接统计各自的比例。如果阈值一升高，fallback 突然占满，说明召回质量或切片方式需要重新检查，而不是继续调大模型提示词。

上线前用一组固定问题复核

不要用单个“看起来回答正确”的问题决定阈值。至少覆盖术语明确、问题含糊、跨文档和确实无答案四类样本，并同时检查原始候选与过滤后候选。Qdrant 官方示例也把 0.5 标作示例值，强调应针对自己的数据和模型调试。

1. 确认距离度量与排序方向，抽查最高分和最低分候选的语义。
2. 逐步改变阈值，记录正确命中、错误混入和 fallback 的变化。
3. 固定 topK 后再调上下文长度，避免把“上下文太长”误认为“阈值太低”。
4. 把阈值写入配置并记录 embedding 模型、切片版本和评测集版本。

相关问题

阈值是不是越高越好？

不是。阈值越高通常越严格，也可能把唯一正确片段过滤掉；应根据错误引用和漏答的代价共同评估。

topK 能代替 score_threshold 吗？

不能。topK 只限制返回数量，低相关结果仍可能进入上下文；阈值才表达最低接受标准。

过滤后只剩一条候选还能回答吗？

取决于任务风险。低风险事实查询可以回答并标出来源，高风险场景更适合走 fallback 或要求用户补充条件。

把分数变成可解释的证据门

向量分数适合做候选门槛，不适合单独充当答案正确性的证明。Go 服务把召回、过滤、兜底和生成拆开后，才能知道一次低质量回答究竟发生在数据、阈值还是生成阶段。先用固定问题集找到可接受区间，再随着模型和切片版本变化重新核对，这比记住一个“万能阈值”可靠得多。