ANN 检索（Approximate Nearest Neighbor Search）
3 秒看懂
一句话定义： 在高维向量空间中，以微小精度损失换取数量级速度提升的”找最近邻”技术——它是 RAG、推荐系统、图像搜索等所有”向量化检索”场景的底层引擎。
核心取舍： 不求 100% 精确最近邻，而是在召回率（Recall）与查询延迟（Latency）/内存占用之间做工程化平衡。
3 分钟产业解释
为什么这件事重要？
大语言模型（LLM）时代，几乎所有信息检索正在经历范式迁移：从 关键词匹配（BM25/TF-IDF） 走向 语义向量检索。用户的一句自然语言被编码为高维向量（如 768 维、1024 维、甚至更高），系统需要在数亿甚至数十亿候选向量中快速找到最相似的若干条——这就是 ANN 的用武之地。
没有 ANN，RAG（检索增强生成）将不可用。 当一个企业知识库有 10 亿条文档片段（embedding 向量），暴力计算所有距离（Brute-Force）的计算量是 O(N×D)，对 10 亿条数据完全不可接受。ANN 通过建立索引结构，将搜索复杂度降低到近似 O(log N) 或亚线性水平，使得毫秒级响应成为可能。
产业位置
用户查询
│
▼
Embedding 模型（文本→向量） ← 模型层（OpenAI / BGE / Jina 等）
│
▼
ANN 检索引擎（向量→Top-K 结果） ← 基础设施层（本页核心）
│
▼
LLM 推理（注入上下文生成回答） ← 应用层
ANN 位于整个 AI 应用栈的 基础设施中间层——它既不生产向量，也不消费结果，但它是连接两者的瓶颈。
15 分钟专家深入
核心问题定义
给定一个查询向量 q ∈ ℝᴰ，和一个包含 N 个向量的集合 S = {x₁, x₂, …, x_N}，精确最近邻搜索要求找到：
x* = argmin_{x ∈ S} ||q - x||₂
当 D 很大（≥128）且 N 很大（≥10⁶）时，精确搜索面临 维度灾难（Curse of Dimensionality）：基于空间划分的传统方法（如 KD-Tree）退化为接近暴力搜索的性能。
ANN 的核心思想：放弃精确性，构建近似索引结构，以 (1+ε)-近似或概率性保证换取亚线性搜索时间。
三大算法范式
ANN 算法可归为三大类（实际系统常混合使用）：
1. 基于图的方法（Graph-Based）
代表：HNSW（Hierarchical Navigable Small World）
- 核心思想：构建多层小世界图，上层稀疏用于长距离跳跃，下层稠密用于精确搜索
- 搜索过程类似”高速公路→国道→街道”的逐级导航
- 查询复杂度：O(log N)（近似）
- 内存开销：较高（需要存储图的邻接表）
- 召回率通常最优，但构建时间和内存成本也最高
2. 基于空间划分的方法（Partitioning / Clustering）
代表：IVF（Inverted File Index），及其变体 IVF-PQ、IVF-HNSW
- 核心思想：先用 k-means 将向量空间划分为若干聚类（Voronoi cells），查询时只在最近的若干个聚类中搜索
- 可与量化压缩（PQ）结合，大幅减少内存
- 参数 nprobe（查询时探测的聚类数量）直接控制精度-速度权衡
3. 基于哈希的方法（Locality-Sensitive Hashing, LSH）
代表：LSH、Annoy（Spotify）
- 核心思想：设计特殊哈希函数，使相近向量更可能被哈希到同一桶中
- 理论保证较完善（可证明的近似比），但实践中内存效率和召回率通常不如 HNSW/IVF-PQ
- Annoy 通过随机投影树实现，适合静态数据集、内存映射友好
混合与变体
| 组合策略 | 说明 |
|---|---|
| IVF-PQ | 先聚类再对残差做乘积量化，FAISS 的经典配置 |
| HNSW + PQ | 图导航 + 向量压缩，兼顾速度与内存 |
| ScaNN（Google） | 各向异性量化，在特定数据分布下精度更优 |
| DiskANN（Microsoft） | 基于 SSD 的图索引，支持超大规模但降低内存需求 |
| SPANN | 稀疏聚类头在内存 + 候选在磁盘，类似 DiskANN 思路 |
技术原理（深度机制）
HNSW 工作原理
Layer 2 (最稀疏): A ──── D
│ │
Layer 1 (中间): A ── B ── D ── E
│ │ │ │
Layer 0 (最稠密): A ─ B ─ C ─ D ─ E ─ F ─ G
构建过程：
- 每个新向量随机分配一个最高层 l（通常按指数分布，P(l) ∝ m_L^{-l}）
- 从最高层开始，使用贪心搜索在当前层找到最近邻
- 下降到下一层，继续贪心搜索并建立双向连接
- 每个节点在第 0 层最多连接 M 个邻居，上层最多连接 M/2 个邻居（第 0 层连接数较多，上层连接数较少）
搜索过程：
- 从最上层的入口点开始
- 在当前层贪心搜索，找到局部最优
- 将该点作为下一层的入口，重复
- 在第 0 层使用 beam search（维护 ef 个候选），返回最终 Top-K
关键参数及其影响：
| 参数 | 含义 | 调大效果 | 调小效果 |
|---|---|---|---|
| M | 每层最大连接数 | ↑ 召回率、↑ 内存、↑ 构建时间 | ↓ 召回率、↓ 内存 |
| efConstruction | 构建时 beam width | ↑ 索引质量、↑ 构建时间 | ↓ 索引质量 |
| efSearch | 查询时 beam width | ↑ 召回率、↑ 查询延迟 | ↓ 召回率、↓ 延迟 |
IVF-PQ 工作原理
[原始向量 x ∈ ℝ^D]
│
▼
[IVF: 找最近聚类中心 c_i] ← 粗量化，缩小搜索范围
│
▼
[残差 r = x - c_i] ← 只存储残差
│
▼
[PQ: 将 r 切分为 M 个子向量] ← 乘积量化压缩
│ 每个子向量独立做 k-means (k=256)
▼
[存储: 每个子向量用 1 字节编码] ← D 维向量压缩为 M 字节
乘积量化（Product Quantization）核心：
- 将 D 维向量切分为 M 个子空间（每个子空间 D/M 维）
- 每个子空间独立做 k-means（k=256，用 8 bit 编码）
- 原始向量：D × 4 字节（float32）→ 压缩后：M 字节
- 距离计算：预计算查询向量子空间与各码本的距离表，查表求和
内存占用估算示例：
- 10 亿向量，128 维，float32 → 原始：10⁹ × 128 × 4B ≈ 486 GB
- IVF-PQ (M=64, 8bit) → 10⁹ × 64B ≈ 59.6 GB（含聚类中心和残差编码）
- 加 IVF 索引头约额外 5-10%（取决于聚类数）
距离度量
| 度量 | 公式 | 适用场景 |
|---|---|---|
| L2（欧氏距离） | ||a-b||₂ | 通用，图像特征 |
| 余弦相似度 | (a·b)/(||a||·||b||) | 文本 embedding（归一化后等价于内积） |
| 内积 | a·b | 归一化后与余弦等价 |
| 汉明距离 | 不同比特数 | 二值哈希向量 |
实践提示： 主流 text embedding 模型（如 OpenAI text-embedding-3、BGE、Jina）输出的向量通常已归一化，此时 L2、余弦、内积三者的排序结果等价。但索引构建时仍需正确指定度量类型。
精度-速度权衡量化（概念级）
召回率 (Recall@10)
1.0 ─────────────────────────────── * (Brute Force, 延迟极高)
│ *
0.95 │ * HNSW (ef=256)
│ *
0.90 │ * IVF-PQ (nprobe=64)
│ *
0.85 │ * IVF (nprobe=16)
│ *
0.80 │ * LSH
└──────────────────────────────→ QPS (每秒查询数)
低 高
上图为定性趋势图，具体数值取决于数据集维度、分布和硬件环境。
技术演进史
| 时期 | 里程碑 | 意义 |
|---|---|---|
| 1998 | LSH 理论奠基（Indyk & Motwani, STOC） | 首次给出亚线性时间 ANN 的理论保证 |
| 2000s | KD-Tree / Ball-Tree 用于低维 | 维度灾难限制了在高维的应用 |
| 2006 | Product Quantization 提出（Jégou et al.） | 向量压缩技术突破，使得大规模向量存储可行 |
| 2013 | Annoy 发布（Spotify） | 轻量级随机投影树，适合嵌入式场景 |
| 2014 | Faiss 启动（Facebook/Meta AI） | 工业级 ANN 库，GPU 加速先驱 |
| 2016 | HNSW 论文发表（Malkov & Yashunin） | 图方法在实践中全面超越 LSH 和 IVF |
| 2020 | ScaNN 发布（Google Research） | 各向异性量化，在高维文本场景表现优异 |
| 2019 | Milvus 启动（Zilliz） | 云原生向量数据库，ANN 作为核心引擎 |
| 2020 | DiskANN 发布（Microsoft Research） | SSD-based 图索引，十亿级向量低内存检索 |
| 2021 | FAISS 1.7+ 大规模 GPU 支持 | GPU IVF-PQ 成为大规模生产方案 |
| 2022 | 向量数据库赛道爆发（Pinecone / Weaviate / Qdrant 融资） | ANN 从学术概念变为商业基础设施 |
| 2023 | RAG 爆发，ANN 需求指数增长 | 成为 LLM 应用栈必选组件 |
| 2024 | NVIDIA cuVS / RAPIDS 加速、专用硬件（如 Pinecone 推理芯片探索） | ANN 从软件优化走向硬件定制 |
| 2025 | 多模态 embedding + 长上下文 LLM 竞争下，“是否还需要 ANN” 出现讨论 | 但窗口限制和成本仍使 ANN 不可替代 |
技术路线对比
主流 ANN 算法量化对比
| 维度 | HNSW | IVF-PQ | LSH | ScaNN | DiskANN |
|---|---|---|---|---|---|
| 数据结构 | 多层图 | 倒排+量化 | 哈希表 | 各向异性量化索引 | 图索引 (SSD-backed) |
| 召回率@10 (典型) | 极高（≥0.98） | 高（0.90-0.97） | 中（0.80-0.92） | 高（0.93-0.97） | 高（0.93-0.97） |
| 查询延迟 | 低 | 低-中 | 低 | 低 | 中（SSD IO） |
| 内存占用/向量 | 高（~M×连接数×指针） | 低（M bytes） | 中 | 低-中 | 极低（仅图结构在内存） |
| 构建时间 | 长 | 中 | 短 | 中 | 长 |
| 动态增删 | 支持（有碎片） | 需重建聚类 | 较好 | 需重建 | 支持（惰性删除） |
| GPU 加速 | 有限 | 非常友好 | 友好 | 友好 | 不太友好 |
| 十亿级规模 | 内存成本高 | 可行 | 内存成本高 | 可行 | 友好（SSD） |
| 代表实现 | hnswlib, FAISS | FAISS, Milvus | Annoy | ScaNN 库 | DiskANN |
主流向量数据库/引擎对比
| 维度 | FAISS | Milvus | Pinecone | Qdrant | Weaviate | Chroma |
|---|---|---|---|---|---|---|
| 定位 | 算法库 | 分布式向量DB | 全托管 SaaS | 向量DB | 向量DB | 嵌入式向量DB |
| 开源 | 是（MIT-like） | 是（Apache 2.0） | 否 | 是（Apache 2.0） | 是（BSD-3） | 是（Apache 2.0） |
| ANN 算法 | HNSW/IVF-PQ/ScaNN等 | 多种（HNSW/IVF/DiskANN） | 自研 | HNSW | HNSW | 主要基于 FAISS/Annoy |
| 分布式 | 否（单机库） | 是 | 是（托管） | 是 | 是 | 否 |
| 标量过滤 | 需手动实现 | 原生支持 | 原生支持 | 原生支持 | 原生支持 | 有限 |
| 适用规模 | 研究/嵌入/自定义 | 大规模生产 | 中大规模 | 中等规模 | 中等规模 | 原型/小规模 |
| 语言 | C++/Python | Go/C++ | 托管 | Rust | Go | Python |
上下游
上游（ANN 依赖什么）
| 环节 | 关键依赖 | 说明 |
|---|---|---|
| Embedding 模型 | 文本/图像/多模态编码器 | 输出向量的质量直接决定 ANN 检索效果（垃圾进垃圾出） |
| 算力 | CPU（AVX-512 指令集）、GPU（CUDA）、内存带宽 | ANN 查询是内存带宽密集型，不是计算密集型 |
| 存储 | DRAM（主存）、NVMe SSD（DiskANN 等） | 内存容量决定可索引的向量规模 |
| 向量数据 | 业务系统产出的文档/图片/行为数据 | 数据清洗和分块（chunking）策略影响检索质量 |
下游（ANN 服务什么）
| 场景 | 典型延迟要求 | 向量规模 |
|---|---|---|
| RAG / LLM 辅助检索 | 10-100ms | 10⁶ - 10⁹ |
| 电商/内容推荐 | 1-50ms | 10⁷ - 10¹⁰ |
| 图片/视频搜索 | 50-500ms | 10⁶ - 10⁹ |
| 广告定向 / 人群扩量 | 5-20ms | 10⁸ - 10¹⁰ |
| 多模态搜索 | 10-200ms | 10⁶ - 10⁸ |
| 欺诈检测 / 实时匹配 | 1-10ms | 10⁷ - 10⁹ |
关键指标
| 指标 | 定义 | 生产环境典型要求 |
|---|---|---|
| Recall@K | 在 Top-K 返回结果中，包含真正 K 近邻的比例 | ≥ 0.95（RAG）/ ≥ 0.90（推荐） |
| QPS（Queries Per Second） | 单节点每秒处理查询数 | 1,000 - 100,000+（取决于硬件和索引） |
| P99 延迟 | 99% 请求的响应时间 | < 50ms（实时场景） |
| 内存/向量 | 单个向量在索引中占用的内存 | HNSW: ~400-1000 bytes（取决于向量维度和图连接数，128维float32约为512-800 bytes）; IVF-PQ(M=64): ~64 bytes |
| 构建时间 | 从原始向量到可查询索引的时间 | 10 亿向量：数小时至数天（取决于算法和硬件） |
| 增量更新能力 | 插入/删除单条向量的代价 | HNSW: O(log N) 插入; IVF-PQ: 需批量重建 |
| GPU 利用率 | GPU 上 ANN 查询的计算效率 | FAISS GPU IVF-PQ 在合理 batch size 下可达较高利用率 |
供需与市场数据
需求侧驱动
- RAG 市场： 全球 RAG 相关基础设施市场仍处于早期阶段。多家行业分析机构对向量数据库市场的估算差异较大，主流估算范围为 2025 年约 10-25 亿美元 [行业估算，口径不一]，2030 年可能达 50-100 亿美元级别 [行业估算]。
- 企业采用： 据各向量数据库厂商公开披露，主流产品（Milvus/Zilliz、Pinecone、Qdrant、Weaviate）的注册用户/客户数在 2023-2024 年经历了数倍增长。
- 数据规模： 单个企业知识库的向量规模从百万级向十亿级攀升，驱动对大规模 ANN 方案的需求。
供给侧格局
| 玩家类型 | 代表 | 模式 |
|---|---|---|
| 开源向量数据库 | Milvus, Qdrant, Weaviate, Chroma | 开源+云服务 |
| 全托管 SaaS | Pinecone, Zilliz Cloud | 按用量付费 |
| 传统数据库扩展 | PostgreSQL + pgvector, Elasticsearch + vector search | 现有基础设施嫁接 |
| 云厂商内置 | Azure AI Search, AWS OpenSearch k-NN, GCP Vector Search | 平台生态绑定 |
| 底层算法库 | FAISS (Meta), ScaNN (Google), cuVS (NVIDIA) | 开源库/SDK |
融资与估值参考 [公开信息]
| 公司 | 最新已知轮次 | 估值（如有公开） | 备注 |
|---|---|---|---|
| Pinecone | 2023 年 B 轮 $100M | ~$750M（2023 估值） | 全托管 SaaS 模式 |
| Zilliz (Milvus) | 2022 年 B+ 轮 $60M | 未充分披露 | 开源+云服务 |
| Weaviate | 2023 年 B 轮 $50M | 未充分披露 | 开源+云服务 |
| Qdrant | 2024 年种子/A 轮 | 未充分披露 | Rust 实现，性能导向 |
| Chroma | 2023 年种子轮 $18M | 未充分披露 | 开发者友好，嵌入式 |
注：以上融资信息来自各公司公开宣布，估值数字为当时媒体报道，可能与当前情况有差异。
代表公司与资本映射
概念-产业链-上市公司映射
ANN 检索产业链
│
├── 算法/库层
│ ├── FAISS (Meta / META) ← Meta 内部使用并向开源贡献
│ ├── ScaNN (Google / GOOGL) ← Google Cloud Vector Search 底层
│ └── cuVS/RAPIDS (NVIDIA / NVDA) ← GPU 加速 ANN
│
├── 向量数据库层
│ ├── Milvus / Zilliz (未上市)
│ ├── Pinecone (未上市)
│ ├── Weaviate (未上市)
│ ├── Qdrant (未上市)
│ ├── pgvector → PostgreSQL (微软 Azure Cosmos DB for PostgreSQL 等)
│ └── Elasticsearch vector search (Elastic / ESTC)
│
├── 云平台层（ANN 作为服务提供）
│ ├── Azure AI Search (微软 / MSFT)
│ ├── AWS OpenSearch k-NN (亚马逊 / AMZN)
│ ├── GCP Vector Search (Google / GOOGL)
│ └── 阿里云 AnalyticDB 向量检索 (阿里巴巴 / BABA)
│
├── 硬件/算力层
│ ├── GPU (NVIDIA / NVDA) ← ANN 是内存带宽密集型
│ ├── 高带宽内存 HBM (SK Hynix, Samsung, Micron) ← 影响 ANN 吞吐
│ └── NVMe SSD (Samsung, Western Digital 等) ← DiskANN 依赖
│
└── 应用层（ANN 消费者）
├── RAG 应用（各 LLM 厂商 / SaaS 公司）
├── 推荐系统（字节跳动/美团/Netflix 等）
└── 广告系统（Google/Meta/百度等）
对上市公司的直接影响：
| 公司 | 与 ANN 的关系 | 受益逻辑 |
|---|---|---|
| NVIDIA (NVDA) | GPU 是大规模 ANN 的主要加速器 | AI 推理/数据处理需求 → GPU 销量 |
| Meta (META) | FAISS 维护者，内部大规模使用 | 信息流推荐效率提升 → 广告收入 |
| Google (GOOGL) | ScaNN 开发者，GCP Vector Search 提供者 | 云服务收入 + 搜索质量提升 |
| Microsoft (MSFT) | DiskANN 开发者，Azure AI Search | Azure AI 生态粘性 |
| Amazon (AMZN) | OpenSearch k-NN，Bedrock 知识库 | AWS AI 服务收入 |
| Elastic (ESTC) | Elasticsearch vector search | 搜索引擎向 AI 搜索转型 |
投资逻辑
核心投资主题
1. ANN 是 AI 应用的”水电煤”
- 每次 RAG 查询都需要一次 ANN 检索，ANN 的调用量与 AI 应用量正相关
- AI 应用渗透率提升 → ANN 基础设施需求同步增长
2. 向量数据库是 ANN 的主要载体，但格局未定
- 开源 vs SaaS 的竞争仍在进行中（类似早期的关系数据库市场）
- 传统数据库厂商（PostgreSQL/ES/Oracle）也在快速集成向量检索能力，可能挤压独立向量数据库的生存空间
- 独立向量数据库公司需要在性能、易用性、企业特性上持续拉开差距
3. “数据库内置向量检索”可能是终局
- 长期看，向量检索可能成为数据库的标配能力（如 pgvector、Elasticsearch），而非独立产品
- 类似全文搜索：最初是独立产品（Lucene/Solr），后来被各类数据库内置
- 如果这一判断成立，独立向量数据库公司需要转型为”AI-native 数据平台”才能生存
4. 硬件加速是差异化方向
- ANN 是内存带宽密集型任务，GPU/NPU 加速效果显著
- 定制化硬件（如 HBM 带宽优化、专用 ANN 加速器）可能是下一个差异化点
- NVIDIA cuVS/RAPIDS 是目前最成熟的 GPU ANN 方案
风险因素
| 风险 | 说明 |
|---|---|
| LLM 长上下文替代 | 随着上下文窗口扩大（1M+ tokens），部分场景可能用”全量输入”替代检索 |
| 嵌入质量瓶颈 | ANN 的效果上限取决于 embedding 模型质量，而非 ANN 本身 |
| 开源侵蚀商业价值 | FAISS、Milvus 等开源方案已非常成熟，SaaS 溢价空间有限 |
| 行业整合 | 大云厂商可能通过免费集成压缩独立厂商空间 |
常见误读纠偏
❌ 误读 1：“ANN 总是比暴力搜索差，生产环境应该用精确搜索”
纠偏： 在高维（D ≥ 64）大规模（N ≥ 10⁶）场景下，ANN 的 Recall@10 可以达到 0.95-0.99+，而延迟降低 100-1000 倍。暴力搜索在十亿级数据上需要数秒甚至数分钟，完全不可用于实时服务。绝大多数生产系统使用 ANN，精度损失对下游 LLM 生成质量的影响微乎其微。
❌ 误读 2：“向量数据库 = ANN 索引，有了 FAISS 就不需要向量数据库”
纠偏： ANN 索引只是向量数据库的核心组件之一。生产环境还需要：持久化存储、元数据过滤（如”只在 2024 年后的文档中检索”）、多租户隔离、分布式扩展、CRUD 操作、访问控制等。FAISS 是算法库，不是数据库。用裸 FAISS 搭建生产系统需要大量工程工作。
❌ 误读 3：“HNSW 在所有场景下都是最优的”
纠偏： HNSW 在中等规模（<1 亿向量）、内存充足、追求最高召回率的场景下确实表现优异。但在以下场景，其他方案更优：
- 超大规模 + 内存受限： IVF-PQ 或 DiskANN 更经济
- 需要频繁重建索引： IVF 的构建成本远低于 HNSW
- 纯批量查询（非实时）： IVF-PQ + GPU 在高吞吐场景下可能更有优势
- SSD 为主的基础设施： DiskANN 专为此设计
❌ 误读 4：“余弦距离和 L2 距离在 ANN 中是等价的”
纠偏： 仅当所有向量（包括查询和库中向量）都经过 L2 归一化后，余弦距离排序才与 L2 距离排序等价（且与内积排序等价）。如果向量未归一化，三者结果不同。实际使用中必须确保索引构建时的度量类型与 embedding 模型的设计一致。
学习路径
入门（2-4 小时）
- 阅读 Pinecone 的 “What is ANN?” 系列博客（概念入门）
- 用 FAISS 官方 tutorial 跑通一个最基本的 IVF-PQ / HNSW 示例
- 理解 Recall、QPS、内存三者之间的权衡
进阶（1-2 周）
- 精读 HNSW 原始论文：Malkov & Yashunin, “Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs” (2016/2018 TPAMI)
- 精读 IVF-PQ 相关论文：Jégou et al., “Product Quantization for Nearest Neighbor Search” (2011 TPAMI)
- 用 FAISS benchmark 工具，对不同索引类型在自己的数据集上跑 Recall-Latency 曲线
- 阅读 FAISS 的 Wiki 和 tuning guide
高级（持续跟踪）
- 阅读 DiskANN 论文：Subramanya et al., “DiskANN: Fast Accurate Billion-point Nearest Neighbor Search on a Single Node” (NeurIPS 2019)
- 了解 ScaNN 的各向异性量化原理：Guo et al., “Accelerating Large-Scale Inference with Anisotropic Vector Quantization” (2020)
- 跟踪 ANN-Benchmarks（ann-benchmarks.com）的最新排行榜
- 关注 NVIDIA cuVS / RAPIDS 的 GPU ANN 进展
- 了解混合检索（Hybrid Search）：向量检索 + BM25 的融合排序（RRF / 加权融合）
一句话总结
ANN 检索是 AI 应用从”玩具”走向”生产”的关键基础设施——它用微小的精度折损，让十亿级语义检索从”不可行”变为”毫秒级响应”，是 RAG、推荐、搜索等所有向量化 AI 应用的不可替代的底层引擎。
延伸阅读与来源
学术论文
- Malkov, Y. A., & Yashunin, D. A. (2018). Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs. IEEE TPAMI.
- Jégou, H., Douze, M., & Schmid, C. (2011). Product Quantization for Nearest Neighbor Search. IEEE TPAMI.
- Indyk, P., & Motwani, R. (1998). Approximate Nearest Neighbors: Towards Removing the Curse of Dimensionality. STOC.
- Subramanya, S. J., et al. (2019). DiskANN: Fast Accurate Billion-point Nearest Neighbor Search on a Single Node. NeurIPS.
- Guo, R., et al. (2020). Accelerating Large-Scale Inference with Anisotropic Vector Quantization. ICML.
开源项目与工具
- FAISS: https://github.com/facebookresearch/faiss
- Milvus: https://github.com/milvus-io/milvus
- hnswlib: https://github.com/nmslib/hnswlib
- ScaNN: https://github.com/google-research/google-research/tree/master/scann
- DiskANN: https://github.com/microsoft/DiskANN
- ANN-Benchmarks: https://ann-benchmarks.com