用向量数据库做RAG，为什么加了过滤条件后召回效果反而变差了？

这问题我当初也踩过，而且踩得比你深。我那时候用Milvus，加了部门过滤后top-10里直接混进来两三条完全没关系的文档，后来查了下，其实不是过滤本身的问题，而是向量检索的机制——HNSW这种图索引在过滤时是先把候选集拉出来再筛，如果过滤条件把高相似度的节点都挡在门外，剩下的低相似度向量就会“矮子里面拔将军”，你看着自然觉得相关度崩了。

另一个坑是过滤字段的基数，像部门这种可能就几个值，但你加时间范围的话，如果时间字段没建好索引，预过滤会把大量不相关的向量也扫一遍，反而干扰了距离排序。我当时试过先按时间粗筛再向量检索，但效果也不稳定，后来干脆改成两阶段——先用过滤条件把候选ID列表查出来，再拿这些ID去查向量，虽然慢点，但召回质量靠谱多了。

你提到被过滤掉的高相似度向量会影响距离分布，我觉得这个思路是对的，但更关键的是pgvector的索引策略。如果用的是IVFFlat，过滤后probe列表里的中心点可能本身就偏了，导致你检索的空间根本不在正确区域。建议你试试把过滤条件加到索引的构建里，比如按部门分区建索引，或者干脆用暴力扫描验证下到底是不是索引的问题。

还有个细节，你重新embedding的时候，是不是把过滤字段也拼进文本里了？我试过把部门名字加到向量文本里，反而让向量空间更混乱，因为模型会学到那些语义噪声。最好保持向量纯净，过滤交给数据库，别混合进embedding源头。你现在top-k降到多少了？如果只是掉两三个点，可能跟过滤后的候选集大小有关，可以试试调大ef_search参数。

这问题我也踩过坑，pgvector的HNSW索引在带过滤条件时，如果filter选择性太强，索引会退化到暴力扫描甚至漏检，导致距离分布被截断。可以试试在过滤后的子集上重建索引，或者用Milvus的PartitionKey按部门分区，能绕开这个坑。另外你top-k取多少？过滤后候选集太小的话，k值建议动态调大，不然硬凑相关度低的样本反而拉低整体质量。

过滤后向量空间被硬切了一刀，距离分布肯定变了，试试先粗召回再过滤，别让pgvector硬扛。

过滤后候选集变小，高相似度向量被挤出去了，剩下矮子里拔将军，质量自然拉胯。试试先粗召回再按条件精排，或者把过滤条件也编码进向量里。

过滤后候选集变小了，距离分布自然就偏了，试试先粗筛再精排，或者把过滤条件加权进向量里。

这个问题太典型了，我当初用Milvus也踩过一模一样的坑。你观察到的“过滤后召回变差”其实不是错觉，核心在于向量检索的ANN索引（比如HNSW）本身就依赖于全局距离分布来构建图结构，一旦加了硬过滤，相当于在搜索时强行切掉了索引图里一大块区域，这样遍历到的邻居节点在结构上就不完整了，top-k结果自然容易跑偏。我之前做过一个实验，同样的数据，过滤后如果直接降低top-k的k值，比如从100降到20，反而能稍微缓解，但本质上还是治标不治本。

我觉得更靠谱的思路是别在向量检索阶段做硬过滤，而是把过滤条件拆出来，用倒排索引或者关系型数据库先圈定候选集，然后再对候选集做向量相似度计算。不过这样有个问题，5万条文档如果过滤后候选集还是很大，比如几万条，那向量检索的优势就没了，可能得用暴力扫描或量化索引。另外你提到的“被过滤掉的高相似度向量影响距离分布”，这个方向我琢磨过，感觉在HNSW里确实存在，因为图结构是全局的，但过滤后你只在子图里搜索，距离分布必然被截断，所以那些“勉强相关”的结果就混进来了。

还有个细节，pgvector和Milvus的过滤实现机制不太一样，pgvector是顺序扫描加过滤再排序，Milvus是索引内过滤，但两者都绕不开这个结构性问题。我现在更倾向于用混合检索方案，比如把metadata过滤条件编码进向量本身，或者用带分区索引的向量库，前提是你愿意接受训练成本。不知道你有没有对比过不同过滤比例下的召回率曲线？比如过滤掉50%和过滤掉90%时的差异，这个数据能帮你判断是不是索引结构的问题。

过滤后候选集太小，本来能靠相似度拉回来的相关片段直接被切没了，试试先粗召回再过滤。

空间被压缩后，距离分布确实会扭曲，尤其过滤条件太窄的时候，不如把过滤条件放宽点。