向量检索 4 种范式怎么选?

30 秒回答

1. 能清晰区分四大范式（树/哈希/量化/图）的核心思想和适用场景
2. 掌握1-2种代表性算法的细节（如HNSW、PQ、LSH）
3. 理解各方法的时空复杂度权衡
4. 能结合实际场景（如RAG中的百万/十亿级检索）给出选型建议

回答与解析

答案要点

• 能清晰区分四大范式（树/哈希/量化/图）的核心思想和适用场景
• 掌握1-2种代表性算法的细节（如HNSW、PQ、LSH）
• 理解各方法的时空复杂度权衡
• 能结合实际场景（如RAG中的百万/十亿级检索）给出选型建议
• 了解工业界的优化手段（如乘积量化+图索引的混合方案）

向量相似度检索的核心矛盾是精确性与效率的权衡。高维空间下精确最近邻复杂度O(n)，必须依赖近似最近邻（ANN）算法。四大范式如下：

一、基于树结构：空间划分思想

• 代表算法：KD-Tree、Ball Tree、Annoy（随机投影树）
• 核心思想：递归划分空间，查询时剪枝遍历
• 局限：高维下"维度灾难"，效果急剧下降（>20维基本失效）
• 现状：纯树结构已较少单独使用，多用于低维或混合索引

二、基于哈希：降维映射思想

• 代表算法：LSH（局部敏感哈希）、SimHash
• 核心思想：相似向量高概率哈希到同一桶，桶内精确比对
• 关键设计：哈希函数族需满足局部敏感性（如p-stable LSH用随机投影）
• 特点：内存友好，但召回率有限，适合对精度要求不高的场景

三、基于量化：压缩编码思想

• 代表算法：PQ（乘积量化）、OPQ、SQ（标量量化）
• 核心思想：子空间分解+聚类中心编码，用短码表示向量
• PQ流程：向量切分m段 → 每段k-means聚类 → 用中心ID编码
• 优势：内存压缩率极高（128维float→16字节），支持非对称距离计算（ADC）
• 工业标配：Faiss的IVF-PQ，十亿级检索的核心组件

四、基于近邻图：图遍历思想

• 代表算法：HNSW、NSG、DiskANN
• 核心思想：构建导航图，查询时贪心遍历找最近邻
• HNSW核心：多层图结构，上层稀疏快速定位，下层稠密精确搜索
• 复杂度：构建O(n log n)，查询O(log n)，精度-速度权衡极佳
• 现状：当前单模态向量检索的SOTA方案

工业实践选型建议

RAG场景的典型配置：Embedding 768/1024维 → 先IVF粗筛 → PQ压缩 → HNSW精排，或直接用开源方案如Milvus的GPU索引。

口语版讲法(约4分钟)

• 一句话定位：向量检索本质是精度与效率的权衡
• 四大范式：树/哈希/量化/图的核心思想
• 业务场景：RAG中的百万/亿级选型
• 落地风险：高维/规模/一致性
• 工程师判断：混合方案是王道

这道题问的是向量相似度检索，其实本质上就是问你怎么在高维空间里平衡精度和效率。精确最近邻复杂度是O(n)，数据量一大根本跑不动，所以工业界几乎清一色用近似最近邻，也就是ANN。下面我按四种主流范式展开，最后再结合业务场景给选型建议。

先说基于树结构的，核心思想是空间划分，代表有KD-Tree、Annoy。你可以把它想象成拿一把刀递归切空间，查询时走剪枝遍历。但这里有个硬伤：高维下维度灾难非常严重，超过20维效果就断崖式下跌。所以现在纯树结构基本不单独用了，顶多用在低维或者混合索引里打辅助。

再一个是基于哈希的方法，典型是LSH。思路是把相似向量高概率映射到同一个桶里，桶内再做精确比对。好处是内存友好，但召回率有限，适合对精度要求不高的场景，比如粗排阶段快速过滤。不过说实话，现在纯粹用LSH的也不多了。

第三种是量化，这是工业级的核心压缩手段。拿乘积量化举例子，把向量切分成m段，每段单独做聚类，用聚类中心的ID来编码。128维的float向量能压缩到十几个字节，内存节省非常夸张。而且它支持非对称距离计算，查询时不用解压完整向量，速度很快。Faiss里的IVF-PQ就是标配，十亿级检索基本都靠它。

最后是近邻图，这是当前单模态检索的SOTA。HNSW是代表，它构建多层图结构，上层稀疏快速定位，下层稠密精确搜索。复杂度是O(log n)的查询，精度和速度的权衡做得特别好。所以百万级以内、内存够用的话，我首选HNSW。

那落到真实业务场景，比如RAG系统里，用户问一个客服退款问题，我们得从百万级知识库里召回相关片段。这时候不会只用一种算法。典型做法是：先用IVF做粗筛，快速排除大部分不相关的向量，然后用PQ压缩节省内存，最后用HNSW精排。说白了，工业落地的核心不是选一个算法，而是混合方案。

这里有个前提：高维Embedding下，比如768维，纯HNSW的构建和查询延迟会明显上升，必须配合量化。如果数据量到了十亿级，单机内存放不下，就得走磁盘方案，比如DiskANN，或者用Faiss GPU索引加速。常见失败场景是只追求召回率，忽略了延迟和内存。上线前我特别关注两件事：一是用固定query回放，对比Recall@K和延迟，确保不崩；二是做冷热分层，热数据放内存，冷数据放磁盘。

另外，现在有个趋势是把图索引和量化结合得更紧，比如Milvus的做法，直接在HNSW的边上做PQ压缩，这样能进一步压缩内存。不过代价是构建时间变长，而且对数据分布敏感。

所以整体上，我更倾向把向量检索看成一套系统工程，而不是挑一个算法。没有银弹，关键是根据数据规模和精度要求做取舍。

关键一句:图索引与量化结合的混合方案（如HNSW+PQ）是主流趋势，但构建时间和数据分布敏感性是潜在风险。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你在做RAG，用户问了一个问题，你需要从百万级文档库里找最相关的几段。你会怎么设计这个检索模块？向量库索引怎么建才能既快又准？

2. 问法 2 · 层层追问

   向量检索你一般怎么搞？直接挨个比太慢了……那如果数据量上百万甚至上亿，你怎么加速？……有没有用过近似最近邻的方法，比如树、哈希、量化这些？

3. 问法 3 · 直球架构

   请系统介绍向量相似度检索的常用方法，包括树、哈希、量化和近邻图这几类。说清楚每种的核心思想、代表算法、适用场景和性能权衡。