向量检索召回结果为什么不稳定：查询归一化、过滤条件与评测样本

向量检索结果忽上忽下，通常不是“模型随机了”这么简单。更常见的原因是查询向量的归一化方式前后不一致、过滤条件改变了候选集合，或者评测样本本身没有固定下来。把这三个边界拆开，召回波动就能从感觉变成可复现的问题。

先固定查询文本、向量生成方式、过滤条件和 top-k，再分别检查向量范数、候选数量与命中样本；不要只盯着最终排序。

先看清：变化发生在向量、候选集，还是排序

排查时可以把一次检索拆成三段：查询文本变成向量，向量索引生成候选，候选再经过过滤和排序。第一段有范数或维度差异，第二段会表现为候选集合变化，第三段则常见于相似度度量或 tie-break 规则不一致。

最小日志至少保留查询指纹、向量维度、查询向量范数、过滤条件、候选数和最终文档 ID。正文不要记录用户原文时，可以用稳定哈希代替；诊断需要的是同一性，不是把隐私带进日志。

归一化约定为什么会改变召回顺序

余弦相似度只关心方向，点积还会受到向量长度影响。若建库时对文档向量做了归一化，而查询时没有做同样处理，点积排序就可能把“长度更大”的向量排到前面。反过来也一样：索引使用余弦距离，业务层却把已归一化向量再次按另一套规则处理，结果会出现难以解释的小幅漂移。

建议把约定写进检索适配层，而不是散落在调用方。一个简单的检查函数应同时验证维度和范数：

func checkQueryVector(v []float32, dimension int) error {
    if len(v) != dimension {
        return fmt.Errorf("dimension mismatch: got=%d want=%d", len(v), dimension)
    }
    var sum float64
    for _, x := range v {
        sum += float64(x) * float64(x)
    }
    if sum == 0 {
        return errors.New("zero query vector")
    }
    return nil
}

这段检查不负责决定用哪种相似度，它只把“输入不符合约定”尽早暴露出来。验证时固定一条查询，连续运行多次，比较向量范数、前十个文档 ID 和分数；若向量已经不同，就不用急着查索引。

过滤条件不是排序参数，而是候选集边界

例如文档带有 tenant、language、published 等元数据。把 language 从“中文”改成“中文或英文”，看起来只是放宽条件，实际可能让候选集合扩大；如果过滤在近邻搜索之后执行，结果变化又会与先过滤再搜索不同。两种实现都可能合理，但必须固定并记录。

排查一条具体查询时，先记录无过滤的候选数，再记录过滤后的候选数，最后才比较排序。若过滤后只剩很少的文档，召回不稳更可能是数据覆盖不足；若候选数稳定而顺序变化，才继续看相似度、索引参数和并列分数的稳定排序规则。

过滤字段也要避免隐式类型转换。把字符串年份和整数年份混在一起，可能造成某些分片命中、某些分片未命中。生产代码里应在入库和查询两端使用同一字段类型，并在日志中记录过滤条件的规范化结果，而不是只记录拼接前的业务对象。

固定评测样本，才知道修复是否真的有效

不要拿一次线上问题的前几条结果当作全部结论。准备一组固定问题，每条问题有期望文档集合或至少一个可接受答案。每次改变归一化、过滤或索引参数，都用同一批问题计算 hit@k、平均候选数和空结果比例。

type Case struct {
    Query      string
    ExpectedID map[string]bool
}

func hitAtK(ids []string, expected map[string]bool) bool {
    for _, id := range ids {
        if expected[id] {
            return true
        }
    }
    return false
}

评测集不要只放“容易搜到”的问题，还要包含同义说法、带过滤条件的问题、没有答案的问题和跨语言问题。这样才能区分“排序变了但仍命中”和“过滤边界把正确文档排除”这两类故障。

一个能收敛的最小验证顺序

1. 冻结输入：固定模型、查询文本、文档快照、top-k、相似度度量和过滤表达式。
2. 测向量：记录维度、范数和向量生成失败数，确认重复请求产生相同输入。
3. 测候选：分别运行无过滤和有过滤版本，保存候选数量及文档 ID 集合。
4. 测排序：对同一候选集比较分数和并列时的二级排序字段。
5. 跑评测：在固定问题集上比较 hit@k、空结果比例和平均延迟，再决定是否调整参数。

这个顺序的好处是每次只移动一个边界。若同时换 embedding 模型、过滤语法和索引参数，哪怕指标变好，也很难知道真正起作用的是什么。

常见问题与边界提醒

同一查询每次分数略有变化，就一定是检索不稳定吗？

不一定。浮点误差可能改变很接近的分数，但只要 top-k 文档和业务命中率稳定，影响未必需要处理。先看文档 ID 集合，再看小数位。

把 top-k 调大能解决过滤导致的漏召回吗？

只能缓解部分“先近邻、后过滤”的实现问题，不能替代正确的候选集设计。若目标文档根本不在过滤后的候选范围内，增大 top-k 也没有帮助。

评测集多久更新一次比较合适？

固定集用于回归，新增问题集用于发现新分布。固定集不应随每次修复立即替换，否则指标会失去可比性；可以按月或按业务变化补充独立版本。

把一次波动变成可回放记录

最终要留下的不是“这次看起来稳定了”，而是一条可回放记录：查询指纹、向量约定、过滤条件、候选规模、top-k 文档、评测版本和修复前后指标。以后再遇到召回变化，先复用这条记录定位变化发生在哪一段，通常比盲目更换模型更快。