深入解析向量搜索中的过滤问题:ACORN与Qdrant如何协同提升搜索质量

监管和法律更新 去中心化金融 (DeFi) 新闻 元宇宙与虚拟现实

在现代搜索系统中,向量搜索技术正逐渐成为提升用户体验的核心引擎。然而,当搜索查询需要结合元数据过滤条件时,传统的最近邻搜索算法(如HNSW)往往会面临严峻挑战。想象一下这样的场景:当你在一个包含百万级图片的数据库中搜索"红色背景下的猫咪"时,系统不仅需要找到视觉上相似的图片,还必须确保这些图片的元数据中包含"红色背景"这一标签。这种多维度的搜索需求,让传统的向量搜索算法不堪重负。传统HNSW算法在构建最近邻图时,默认参数m=16意味着每个节点平均有16个连接。然而,当元数据过滤条件将96%的数据点排除后,剩余的4%数据点在图结构中可能变得四分五裂,平均每个节点的有效连接数甚至可能降至1以下。

这意味着搜索算法在遍历图结构时,很容易陷入"孤岛",无法找到真正的最近邻结果。这种现象在数据科学中被称为"过滤后图分离"问题,直接导致搜索召回率的急剧下降。为了解决这一难题,Qdrant搜索引擎引入了两种互补的修复机制:可过滤HNSW图结构和ACORN算法。前者在索引构建阶段通过为共享相同元数据值的节点添加额外连接,确保过滤后的图结构保持连通性;后者则在搜索阶段通过遍历邻居的邻居来弥补直接邻居无法满足过滤条件的缺陷。这两种技术的巧妙结合,为向量搜索中的过滤问题提供了全面的解决方案。可过滤HNSW图结构的核心思想在于,通过在索引构建阶段主动构建跨元数据值的连接,确保任何过滤条件下的子图都保持连通。

具体实现中,Qdrant会为每个被索引的元数据字段构建额外的HNSW边。例如,当用户为"颜色"字段构建索引时,所有包含相同颜色值的图片节点之间会被显式连接。这种设计确保了即使应用了"红色背景"的过滤条件,搜索算法仍然能够在连通的图结构中遍历,而不会陷入孤立的数据岛屿。然而,这种索引阶段的修复并非完美无缺。首先,为每个元数据字段添加额外连接会显著增加索引构建时间和内存占用。在Qdrant的基准测试中,构建包含100万个128维向量的索引时,标准HNSW构建时间为116秒,而添加了额外连接后构建时间激增至507-652秒,增长了4.4到5.6倍。

其次,Qdrant采用了一种智能的容量控制机制:当某个元数据值对应的数据点数量超过特定阈值时,系统会自动跳过为该值添加额外连接。这个阈值基于当前图结构的平均连接数动态计算,公式为"数据点总数/平均连接数×4"。例如,在一个平均每个节点有21个连接的图结构中,当某个颜色值对应的图片超过19万张时,系统将不再为该颜色值添加额外连接。这种容量控制虽然节省了构建资源,但也带来了新的挑战。当用户查询涉及多个元数据字段的组合过滤(如"红色背景"AND"猫咪")时,如果各个字段的额外连接都被跳过,搜索算法将无法通过图遍历找到足够的候选结果。ACORN算法正是为解决这一特定问题而生的。

ACORN(Adaptive Connected Overlap Repair Network)算法分为两个版本:ACORN-1和ACORN-gamma。ACORN-1作为轻量级版本,在搜索阶段通过遍历邻居的邻居来弥补直接邻居无法满足过滤条件的缺陷。具体实现中,当搜索算法发现当前节点不满足过滤条件时,会自动扩展到该节点的邻居节点,并继续检查这些邻居的邻居,直到找到足够数量的满足条件的候选结果。这种"二度邻居遍历"策略确保了搜索算法不会在过滤后的图结构中迷失方向。相比之下,ACORN-gamma采用了更激进的策略,在索引构建阶段就通过扩展邻居列表来增强图结构的连通性。根据SIGMOD 2024论文的数据,ACORN-gamma在保持相同召回率的情况下,能够将吞吐量提升2到1000倍,但代价是构建时间增加8.8到33.1倍。

这种权衡在实时搜索场景中可能并不适用,但在批量处理或离线分析场景中具有显著优势。在Qdrant的实际实现中,ACORN-1被设计为可选的查询参数,开发者可以在每个请求中显式启用。系统会根据查询的过滤条件复杂度,自动决定是否使用ACORN算法。例如,当过滤条件匹配的数据点数量低于特定阈值(默认40%)时,系统会自动启用ACORN算法;而当过滤条件匹配的数据点数量极低(如0.012%)时,系统会直接切换到全扫描模式,通过元数据索引直接获取结果。为了更直观地理解这两种修复机制的效果,让我们看一个具体的基准测试案例。在Qdrant的官方测试中,研究人员使用了包含100万个96维图像嵌入向量的数据集,并模拟了不同选择性的元数据过滤条件。

测试对比了四种搜索策略:标准HNSW图、启用ACORN的标准HNSW图、可过滤HNSW图和Qdrant的查询规划器(能够自动选择最优策略)。在单一过滤条件测试中,当过滤条件匹配20%的数据点时,标准HNSW图的召回率仅为62.9%,而启用ACORN后召回率提升至98.9%,可过滤HNSW图则达到94.8%。随着过滤条件变得更加严格(匹配10%或1%的数据点),标准HNSW图的召回率急剧下降至20.6%和0.1%,而启用ACORN后仍能保持67.7%的召回率。然而,ACORN在极端情况下(匹配1%的数据点)的召回率也出现了下降,这正是后续RACORN-1算法试图解决的问题。在组合过滤条件测试中,当用户查询需要同时满足两个元数据条件(如"红色背景"AND"猫咪")时,情况变得更加复杂。当组合条件匹配4%的数据点时,标准HNSW图的召回率仅为0.1%,启用ACORN后提升至95.2%,可过滤HNSW图为63.7%,而Qdrant的查询规划器能够达到99.9%的召回率。

这种组合过滤条件下的性能差异,充分展示了两种修复机制的互补性。值得一提的是,Qdrant的查询规划器在实际应用中扮演了关键角色。它会根据过滤条件的选择性和复杂度,自动决定最优的搜索策略。例如,当过滤条件匹配的数据点数量极低(如0.012%)时,规划器会直接切换到元数据索引的全扫描模式,而无需遍历图结构。这种智能路由机制确保了系统在各种查询场景下都能保持最佳性能。从实际应用的角度来看,选择何种修复机制取决于具体的使用场景和性能要求。

对于需要实时响应的搜索应用,可过滤HNSW图结构可能更为合适,因为它将修复成本转移到了索引构建阶段,而在查询阶段保持了较低的延迟。而对于那些对召回率要求极高的应用,结合使用可过滤HNSW图和ACORN算法可能是更好的选择。在实施过程中,开发者需要特别关注元数据字段的选择性。那些包含少量高频值的字段(如颜色、类别等)往往需要更多的关注。通过分析字段的基数(distinct values)和每个值对应的数据点数量,可以预判哪些字段可能需要额外的连接修复。Qdrant的官方文档建议,在构建索引时应为所有需要过滤的字段创建元数据索引,并通过基准测试评估不同修复策略的效果。

对于那些希望进一步优化搜索性能的团队,建议按照以下步骤进行系统性的测试:首先识别出最可能导致搜索失败的过滤条件(如匹配20%以上数据点的条件或组合过滤条件),然后为这些条件创建专门的测试集。通过比较启用和禁用ACORN算法时的召回率和延迟变化,可以准确评估其效果。在实际部署时,可以选择性地为特定查询路径启用ACORN算法,从而实现性能与资源的最优平衡。需要注意的是,ACORN算法虽然能够显著提升召回率,但也会带来额外的计算开销。在Qdrant的测试中,启用ACORN算法可能导致查询延迟增加2.8到6.7倍。因此,开发者应在召回率提升和延迟增加之间找到合适的平衡点。

幸运的是,Qdrant的查询规划器会自动限制ACORN算法的使用范围,仅在过滤条件选择性低于40%时启用,从而最大限度地减少不必要的开销。从长远来看,向量搜索技术的发展将继续受到过滤需求的推动。随着人工智能应用的普及,用户对多维度搜索体验的要求将越来越高。未来的研究可能会集中在更智能的图结构构建算法、更高效的过滤条件评估机制,以及更精准的查询规划策略上。ACORN算法和可过滤HNSW图结构的出现,已经为这一领域树立了新的标杆,而更多创新性的解决方案无疑将继续涌现。对于开发者而言,理解这些底层机制不仅有助于优化现有系统,更能为未来的技术选型提供有价值的参考。

无论是选择Qdrant这样的成熟搜索引擎,还是自行构建向量搜索系统,深入理解过滤机制的挑战与解决方案,都将成为构建高质量搜索体验的关键。 。