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