当前位置：首页 > news >正文

向量数据库过滤搜索：原理、性能与优化实践

news 2026/6/11 11:19:58

1. 向量数据库与过滤搜索基础概念

在当今AI驱动的应用中，向量数据库已经成为处理高维数据相似性搜索的核心基础设施。不同于传统关系型数据库的精确匹配查询，向量数据库专注于解决"近似最近邻"(ANN)问题——即快速找到与查询向量最相似的若干个数据点。这种能力在推荐系统、图像检索、自然语言处理等场景中至关重要。

过滤向量搜索(FANNS)是这一领域的进阶技术，它在相似性搜索的基础上增加了属性过滤条件。想象一下这样的场景：在一个电影推荐系统中，我们不仅要找到与用户喜好相似的影片，还要确保这些影片的评分高于8分且是近五年上映的。这就是典型的过滤向量搜索需求——同时满足向量相似度和结构化属性的双重约束。

1.1 核心性能指标解析

评估过滤向量搜索系统时，两个关键指标需要特别关注：

QPS(Queries Per Second)：衡量系统吞吐量的核心指标，表示每秒能处理的查询数量。在实际业务场景中，高QPS意味着系统能同时服务更多用户请求。从实验数据可以看出，不同系统在相同硬件条件下的QPS差异可达数量级：

FAISS, Movies: 10^2 - 10^3 QPS Milvus, Movies: 10^2 QPS pgvector, Movies: 10^1 - 10^3 QPS

召回率(Recall)：反映搜索结果质量的指标，计算为系统返回的正确结果占全部可能正确结果的比例。在过滤搜索场景下，召回率会受到过滤条件的严重影响。例如，当过滤掉90%的数据时，标准HNSW算法的召回率可能从0.9骤降到0.3。

1.2 过滤策略分类

现代向量数据库主要采用三种过滤策略：

前过滤(Pre-filtering)：先应用属性过滤，再在剩余数据上执行向量搜索。这种方法能保证召回率，但当过滤后数据量很大时计算成本高昂。
后过滤(Post-filtering)：先执行向量搜索，再对结果应用属性过滤。这种方法效率高但可能导致召回率不足，特别是当过滤条件严格时。
运行时过滤(Runtime-filtering)：在向量搜索过程中动态应用过滤条件，平衡效率与召回率。这是最复杂的策略，也是Milvus等系统实现高性能的关键。

2. Milvus的架构与性能奥秘

2.1 Knowhere引擎设计

Milvus的核心优势源于其专为向量搜索优化的Knowhere引擎。与直接封装FAISS的简单方案不同，Knowhere进行了深度定制：

双队列图遍历(Dual-Pool Traversal)：传统HNSW算法在过滤搜索时，无效节点会占用搜索资源，导致召回率下降。Knowhere的NeighborSetDoublePopList机制维护两个独立队列：一个用于有效结果，另一个专用于导航的无效节点。实验数据显示，这种设计使Milvus在5%-10%选择率下仍能保持接近1.0的召回率，而标准HNSW实现会降到0.6以下。
自适应回退机制：当检测到过滤选择率超过93%时(代码中硬编码的阈值)，系统会自动切换到暴力搜索模式。虽然听起来效率不高，但由于过滤后数据量很小，实际延迟仅1-5ms。这种设计解释了为什么Milvus即使用nprobe=1也能在严格过滤条件下获得1.0召回率。

2.2 分段策略的影响

有趣的是，实验数据打破了关于数据分段的传统认知。无论是将数据分散在多个1GB段还是集中在一个16GB单体中，Milvus的召回率都保持稳定(图13)。这表明系统的稳健性主要来自算法层面的创新，而非分布式架构。

2.3 性能特点总结

Milvus展现出独特的性能特征：

召回率稳定性：在各种过滤条件下都能保持高召回率
延迟下限：为保证质量牺牲了部分峰值吞吐量
算法一致性：对HNSW和IVFFlat索引都提供相似的稳健性

这种特性使其特别适合召回率敏感型应用，如法律检索、医疗诊断辅助等场景。

3. pgvector的实现与优化挑战

3.1 与PostgreSQL的深度集成

pgvector作为PostgreSQL的扩展，充分利用了关系数据库的成熟特性：

基于成本的优化器：使用传统RDBMS的代价模型来规划查询执行路径
混合查询支持：无缝结合SQL条件和向量搜索
事务一致性：继承PostgreSQL的ACID特性

3.2 查询执行计划分析

pgvector会产生三种典型的执行计划：

ANNS+后过滤：

Limit -> Index Scan using vector_idx on dataset Order By: (vector <=> $0) Filter: (attribute > 8.5)

这种计划先利用向量索引查找相似项，再过滤结果。当过滤条件不严格时效率高，但严格过滤会导致召回率下降。

前过滤+kNNS：

Limit -> Sort Sort Key: ((dataset.vector <=> $0)) -> Seq Scan on dataset Filter: (attribute > 8.5)

对过滤后的数据执行暴力搜索。召回率完美但计算成本高。

属性索引扫描+kNNS（当属性有B树索引时）：

Limit -> Sort Sort Key: ((dataset.vector <=> $0)) -> Bitmap Heap Scan on dataset Recheck Cond: (attribute > 8.5) -> Bitmap Index Scan on idx_attribute Index Cond: (attribute > 8.5)

这种计划通常能完美平衡效率与召回率，但优化器往往低估其价值。

3.3 优化器局限性与挑战

实验揭示了pgvector优化器的几个关键问题：

代价模型偏差：倾向于选择近似向量搜索而非可能更优的精确搜索
基数估计不准确：低估过滤后的数据量，导致次优计划选择
参数敏感性：相同查询稍改k值(如20→21)可能导致完全不同的执行计划

这些问题使得pgvector在过滤严格时表现不稳定，需要DBA手动干预查询计划。

4. 深入性能对比分析

4.1 不同选择率下的表现

通过分析QPS-Recall曲线(图12)，可以清晰看到两种系统的特性差异：

高选择率(σg > 30%)：
- 两种系统都能达到高QPS(>1000)
- Milvus召回率略高(0.98 vs 0.95)
中选择率(10% < σg < 30%)：
- pgvector的QPS开始下降(约500)
- Milvus保持稳定，但绝对QPS较低(约200)
低选择率(σg < 5%)：
- pgvector召回率可能骤降到0.6
- Milvus通过回退机制保持1.0召回率
- QPS差距缩小(Milvus 50 vs pgvector 80)