HNSW
3 秒看懂
一句話定義： HNSW 是一種基於多層跳錶 + 小世界圖的近似最近鄰（ANN）搜尋演算法，以”在海量高維向量中極速找到相似向量”為核心能力，是當前幾乎所有主流向量資料庫的預設索引方案。
類比： 想像一本詞典——最頂層索引只覆蓋極少數字母（“A、M、Z”），快速鎖定大區間；逐層下降到更密的索引，直到最終頁逐詞查詢。HNSW 對向量做的就是這件事，只不過”字母順序”被替換成了高維空間中的圖導航。
一句話投資意義： RAG（檢索增強生成）的底層基礎設施，沒有 HNSW 級別的 ANN 引擎，大型模型就無法高效檢索外部知識。
3 分鐘產業解釋
為什麼 HNSW 突然變重要？
2023 年以來，大語言模型（LLM）從”純引數記憶”走向”檢索增強生成（RAG）“範式：先把文件切成 chunk、編碼為高維向量（通常 768-4096 維），存入向量資料庫；推論時對使用者 query 做向量編碼，在庫中做最近鄰檢索，將 Top-K 結果拼入 prompt 送入 LLM。
向量檢索的效能瓶頸直接決定了 RAG 的延遲和吞吐。 精確最近鄰（暴力掃描）在百萬級以上向量庫中不可接受（O(n) 複雜度），必須用 ANN（近似最近鄰）做剪枝。HNSW 恰好是當前 ANN 領域綜合召回率/延遲/QPS 最優的通用演算法之一。
產業定位
使用者 Query
│
▼
┌──────────────┐
│ Embedding 模型 │ ← 產生高維向量
└──────┬───────┘
│ (query vector, e.g. 1536-d)
▼
┌──────────────┐
│ 向量資料庫 │
│ ┌──────────┐ │
│ │ HNSW 索引 │ │ ← 本頁主角: ANN 檢索
│ └──────────┘ │
└──────┬───────┘
│ (Top-K 相似文件 chunk)
▼
┌──────────────┐
│ LLM 生成器 │ ← RAG 推論
└──────────────┘幾乎所有主流向量資料庫（Milvus、Weaviate、Qdrant、Pinecone、pgvector、Vespa 等）均將 HNSW 作為預設或主力 ANN 索引選項。Meta 的 FAISS 庫實現了 HNSW，而 Google 的 ScaNN 未採用 HNSW，其核心演算法是基於各向異性量化結合 IVFPQ 等方案。在 RAG 成為 LLM 應用主流範式的當下，HNSW 是 AI 基礎設施棧中”資料層”的核心演算法元件。
15 分鐘專家深入
1. 核心思想：跳錶 + 小世界圖
HNSW 由 Yu. A. Malkov 和 D. A. Yashunin 在論文 “Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs”（首次提交於 2016 年 arXiv，正式發表於 IEEE TPAMI 2018）中提出。其核心融合了兩個經典結構：
| 經典結構 | 貢獻 | 在 HNSW 中的角色 |
|---|---|---|
| Skip List（跳錶，Pugh 1990） | 多層連結串列，上層稀疏 → 快速定位區間 | 多層架構：上層節點稀疏，用於快速粗定位 |
| Navigable Small World (NSW) 圖 | 每個節點連向遠距離”高速公路”鄰居 + 近距離鄰居 | 底層圖結構保證區域性精確搜尋 + 全域性快速跳轉 |
2. 結構解析
多層圖（Hierarchical Graph）：
- Layer 0（最底層）： 包含全部 n 個向量節點，每個節點最多有 M 條雙向邊（M 是核心引數，典型值 16-64）。
- Layer 1, 2, … L（逐層向上）： 每個向量被隨機分配到某個最高層
l_{max}。分配機率通常按指數衰減——層數越高，節點越稀疏。l_{max}的選取通常按l_{max} = \lfloor -\ln(text(uniform)(0,1)) \cdot m_L \rfloor，其中m_L = 1 / \ln(M)（論文預設設定）。 - Layer L（最頂層）： 僅包含極少數”高速公路入口”節點。
搜尋過程（Query-Time Greedy Search with Beam）：
- 從最頂層 L 的某個入口點（通常是首次插入的節點，記為
entry_point）開始。 - 在當前層執行 貪心波束搜尋（beam search，寬度 = ef）：從入口點出發，沿圖邊跳到離 query 更近的鄰居，直到區域性最優（所有鄰居都不比當前最近點更近）。
- 將當前層的最近點作為下一層的入口點，下降到下一層。
- 重複步驟 2-3，直到 Layer 0。
- 在 Layer 0 做最終的 beam search（寬度 ef 或 ef_search），返回 Top-K 結果。
建置過程（Insert-Time）：
- 新節點 $q$ 被分配到最高層
l_{max}。 - 從 Layer L 的 entry_point 開始，逐層貪心搜尋到
l_{max}+1層的最近鄰，作為l_{max}層的入口。 - 在
l_{max}層及以下各層，分別做 beam search（寬度 = efConstruction），找到最近的 M 個鄰居（Layer 0 為 2M），建立雙向邊。 - 對每個鄰居，檢查其邊數是否超過 M（或 2M），若超過則做 剪枝（pruning）：保留離鄰居最近的 M 條邊（啟發式剪枝在論文中有詳細描述，核心是保持圖的連通性和多樣性）。
3. 關鍵引數
| 引數 | 含義 | 典型值 | 影響 |
|---|---|---|---|
| M | 每節點最大鄰居數（Layer 0 為 2M） | 16（預設）, 32, 64 | M↑ → 召回↑、記憶體↑、建置慢 |
| efConstruction | 建置時 beam search 寬度 | 200（預設） | efConstruction↑ → 圖質量↑、建置慢 |
| ef / efSearch | 查詢時 beam search 寬度 | 50-500 | ef↑ → 召回↑、延遲↑（執行時可調） |
| maxM / maxM0 | 非底層/底層最大鄰居數 | 與 M 相關 | 控制記憶體和搜尋廣度 |
⚠️ ef 是執行時可調的，這意味著使用者可以在召回率和延遲之間動態權衡，無需重建索引——這是 HNSW 相比 IVF 等靜態索引的顯著優勢。
4. 複雜度分析
| 維度 | 複雜度 | 備註 |
|---|---|---|
| 建置時間 | O(n \cdot M \cdot text(efConstruction) \cdot \log n)（估） | 主要是每個節點插入時的 beam search |
| 查詢時間 | O(\log n)（平均，高召回場景） | 小世界圖性質保證對數跳數 |
| 空間/記憶體 | O(n \cdot M \cdot bar(L))，$bar(L)$ 為平均層數 | 記憶體密集型——圖的鄰接表常駐記憶體是主要瓶頸 |
| $bar(L)$ | \approx \ln(n) / \ln(M) | 層數的期望值 |
核心痛點：記憶體。 對於 1 億條 768 維 float32 向量，僅原始向量約佔 307.2 GB（1e8 × 768 × 4 位元組），加上 HNSW 圖的鄰接表（每條邊 4 位元組 int × 每節點約 2M-4M 條邊 × 1e8 節點），圖結構本身可能額外佔用數十到數百 GB。實際部署中，HNSW 索引的記憶體佔用通常為原始向量的 1.2-2 倍 [行業估算]。
技術原理（最深）
多層圖結構詳解
Layer L (最稀疏): ●─────────●
↑ 高速公路入口
Layer L-1: ●───●─────●───●
↑ 節點密度增加
Layer 1: ●─●─●─●─●─●─●─●─●─●─●─●
↑ 更密
Layer 0 (全集): ●●●●●●●●●●●●●●●●●●●●●●●●●●●●
↑ 所有 n 個向量，每節點 ≤ 2M 邊搜尋過程虛擬碼
def hnsw_search(query, ef, K, entry_point, layers):
# Step 1: 從頂層貪心下降到 Layer 1
curr_nearest = entry_point
for layer in range(max_layer, 0, -1):
curr_nearest = greedy_search(query, curr_nearest, layer)
# 在當前層沿最近鄰邊跳到區域性最優(單點貪心)
# Step 2: 在 Layer 0 做 beam search
candidates = beam_search(query, curr_nearest, layer=0, ef=ef)
# candidates: 一個大小 ≤ ef 的有序集合(按距離排序)
# beam search 過程:
# - 維護 candidates (小根堆) 和 visited set
# - 從 entry_point 出發, 取堆頂(最近未訪問節點)
# - 遍歷其鄰居, 若更近則入堆
# - 直到堆中最近的 ef 個節點都不再更新
return top_k(candidates, K) # 返回最近的 K 個剪枝策略（Heuristic Pruning）
建置時，每個新節點找到 M 個候選鄰居後，不是簡單取最近的 M 個，而是執行啟發式剪枝：
Prune(neighbors, M, new_node):
result = []
sorted_by_dist = sort(neighbors, by=distance_to(new_node))
for candidate in sorted_by_dist:
if |result| >= M: break
# 只有當 candidate 比 result 中已有節點都"更不同"時才保留
# (即 candidate 不被 result 中任何節點"覆蓋")
if dist(candidate, new_node) < dist(candidate, any_in(result)):
result.append(candidate)
return result這一策略的核心目的是 保持圖的多樣性（diversity）——避免所有鄰居都聚集在同一區域，從而保證搜尋的全域性可達性。這是 HNSW 召回率顯著優於樸素 NSW 的關鍵設計之一 [Malkov & Yashunin, IEEE TPAMI 2018]。
小世界性質的保證
HNSW 繼承了小世界圖的長程/短程連線特性：在 Layer 0 的圖中，每個節點既連線”近距離”鄰居（greedy 搜尋的有效區域性導航），又連線”遠距離”鄰居（實現 O(log n) 跳數的”高速公路”）。上層進一步放大了”遠距離跳躍”的效果——這正是 skip list 的核心思想，多層結構共同保證了搜尋的對數擴充套件性。
技術演進史
| 時間 | 事件 | 意義 |
|---|---|---|
| 1990 | Pugh 發明 Skip List | 多層索引思想的奠基 |
| 2002 | Kleinberg 提出 Navigable Small World 網路模型 | 社會網路中的”六度分隔”理論數學化 |
| 2011-2014 | NSW 演算法（Malkov 等） | 將 NSW 理論付諸近似最近鄰搜尋實踐 |
| 2016 | HNSW 論文首版（arXiv 1603.09320） | 融合 skip list + NSW，奠定基礎 |
| 2018 | HNSW 正式發表於 IEEE TPAMI | 被學術界和工業界廣泛採納 |
| 2017+ | hnswlib 開源（Malkov 維護） | C++ 參考實現，成為事實標準 |
| 2019+ | FAISS（Meta）整合 HNSW | 進入主流 ML 基礎設施 |
| 2020+ | Milvus、Weaviate、Qdrant 等向量資料庫湧現 | HNSW 成為預設索引 |
| 2021+ | DiskANN（Microsoft Research）提出 Vamana 圖 | 在 HNSW 基礎上引入 SSD 儲存降低記憶體需求 |
| 2023-2024 | RAG 範式爆發，HNSW 成為 LLM 基礎設施 | 產業價值躍升 |
| 2024+ | GPU 加速 HNSW 探索（如 CAGRA/NVIDIA、VSPANN 等） | 解決 HNSW 的建置/查詢並行化瓶頸 |
技術路線對比
ANN 索引演算法橫向對比
| 維度 | HNSW | IVF-Flat / IVF-PQ | ScaNN (Google) | DiskANN (MSR) | 暴力掃描 (Flat) |
|---|---|---|---|---|---|
| 資料結構 | 多層可導航圖 | 倒排索引 + 聚類 | 各向異性量化 | Vamana 圖 + SSD | 無索引 |
| 召回率 @ 10 | ★★★★★（>95%@ef=200 常見） | ★★★★（需足夠 nprobe） | ★★★★★ | ★★★★ | ★★★★★（100%精確） |
| 查詢延遲 | ★★★★★ | ★★★★ | ★★★★★ | ★★★（SSD 讀取） | ★（最慢） |
| 記憶體佔用 | ★★（高，需存圖） | ★★★★（PQ 壓縮後低） | ★★★★ | ★★★★★（向量在 SSD） | ★★（存原始向量） |
| 建置速度 | ★★★（序列插入是瓶頸） | ★★★★（聚類較快） | ★★★★ | ★★★ | ★★★★★ |
| 可增量更新 | ★★★★★（直接插入） | ★★（需重建聚類） | ★★ | ★★★ | ★★★★★ |
| GPU 友好度 | ★★（貪心搜尋難並行） | ★★★★（批次掃描） | ★★★ | ★★ | ★★★★★ |
| 適用規模 | 1M-100M [行業估算] | 10M-1B+ | 10M-1B+ | 1B+ (SSD 級) | <1M |
| 典型使用者 | Milvus/Weaviate/Qdrant | FAISS 使用者 | Google Cloud | Azure AI Search | 小規模精確場景 |
注： 以上星評基於行業共識和典型 benchmark（ANN-Benchmarks、Big-ANN-Benchmarks）的定性總結，實際表現高度依賴資料集維度、分佈、硬體配置。召回率/延遲的精確數字因測試條件不同差異較大，不在此編造具體數值。
上下游
上游（HNSW 依賴什麼）
┌──────────────────────────────────────────────────────┐
│ 上 遊 │
├───────────────┬──────────────────────────────────────┤
│ Embedding 模型 │ OpenAI text-embedding-3, │
│ │ Cohere embed-v3, │
│ │ BGE/Jina/BAAI 等開源模型 │
│ │ → 產出高維向量(768-4096維) │
├───────────────┼──────────────────────────────────────┤
│ 距離度量 │ Cosine, L2 (歐氏), Inner Product │
│ │ → HNSW 圖中邊的距離計算基礎 │
├───────────────┼──────────────────────────────────────┤
│ 計算基礎設施 │ 大記憶體 CPU 伺服器(DDR5) │
│ │ → HNSW 圖需常駐記憶體 │
├───────────────┼──────────────────────────────────────┤
│ SIMD/向量化指令│ AVX-512, NEON, SVE 等 │
│ │ → 距離計算的硬體加速 │
└───────────────┴──────────────────────────────────────┘下游（誰消費 HNSW 的結果）
┌──────────────────────────────────────────────────────┐
│ 下 遊 │
├───────────────┬──────────────────────────────────────┤
│ 向量資料庫 │ Milvus/Zilliz, Weaviate, Qdrant, │
│ │ Pinecone, pgvector, Vespa, ChromaDB │
├───────────────┼──────────────────────────────────────┤
│ RAG 應用 │ 企業知識庫問答、程式碼檢索、法律/醫療AI │
├───────────────┼──────────────────────────────────────┤
│ 推薦系統 │ 使用者/物品 embedding 的即時匹配 │
├───────────────┼──────────────────────────────────────┤
│ 多模態搜尋 │ 圖文檢索(CLIP embedding)、音影片檢索 │
├───────────────┼──────────────────────────────────────┤
│ 去重/聚類 │ 近重複檢測、語義去重 │
└───────────────┴──────────────────────────────────────┘關鍵指標
效能評估指標體系
| 指標 | 定義 | HNSW 典型表現 |
|---|---|---|
| Recall@K | 返回的 Top-K 中包含真正 Top-K 的比例 | Recall@10 > 95% 當 ef ≥ 100 [典型 benchmark 觀測] |
| QPS | 每秒查詢數（單執行緒） | 數百到數千 QPS（取決於維度和 ef） [行業估算] |
| P99 延遲 | 99 分位查詢延遲 | 通常 < 10ms @ 10M 向量 [行業估算] |
| 建置時間 | 索引建置總耗時 | 10M × 768-d 向量：數十分鐘到數小時 [行業估算] |
| 記憶體佔用 (GB) | 索引全部駐留記憶體 | ≈ 原始向量大小 × 1.2-2.0 [行業估算] |
| 節點度 (平均) | 每節點平均邊數 | 接近但不超過 M (Layer 0 為 2M) |
關鍵權衡三角
召回率 (Recall)
▲
/ \
/ \
/ HNSW \
/ sweet \
/ spot \
/ \
▼───────────────▼
延遲/吞吐 記憶體
(Latency/TP) (Memory)
→ M↑ / ef↑: 召回↑, 延遲↑, 記憶體↑
→ M↓ / ef↓: 召回↓, 延遲↓, 記憶體↓
→ ef 執行時可調, M 需建索引時確定供需與市場資料
需求側驅動力
| 驅動因素 | 量化訊號 | 對 HNSW 的意義 |
|---|---|---|
| RAG 應用爆發 | 主要雲端廠商均推出向量資料庫服務（AWS OpenSearch Serverless、Azure AI Search、GCP Vector Search） | 向量索引需求從”可選”變為”必選” |
| Embedding 模型標準化 | OpenAI、Cohere 等均提供 embedding API，維度趨於穩定在 768-3072 | 向量規模穩定增長 |
| 企業知識庫建設 | 全球企業 RAG 試點專案增長（具體資料各家口徑不一，無統一來源） | 百萬-億級向量庫成為常態 |
供給側格局
| 層級 | 玩家 | 備註 |
|---|---|---|
| 開源庫 | hnswlib（參考實現）、FAISS（Meta）、USearch | 大多數向量資料庫底層呼叫這些庫 |
| 向量資料庫 | Milvus/Zilliz、Weaviate、Qdrant、Pinecone、ChromaDB | HNSW 是預設或主力索引 |
| 雲端廠商內建 | AWS（OpenSearch KNN）、Azure（AI Search）、GCP（ScaNN/Matching Engine） | 部分用自研 ANN 演算法替代或補充 HNSW |
| 硬體加速 | NVIDIA（cuVS/CAGRA）、Intel（oneAPI 級最佳化） | GPU 加速 ANN 搜尋是活躍方向 |
注意： 向量資料庫市場的精確規模資料各家口徑差異大，Gartner/IDC 尚未給出統一的獨立分類報告。市場處於早期高速增長階段，具體 TAM 數字不在此編造。
代表公司與資本對映
公司/專案與 HNSW 的關係
| 公司/專案 | 角色 | 與 HNSW 的關係 | 融資/估值訊號 |
|---|---|---|---|
| Zilliz（Milvus 母公司） | 向量資料庫 | Milvus 核心索引之一即 HNSW | 2022 年 B 輪 6000 萬美元 [公開資訊] |
| Weaviate | 開源向量資料庫 | 預設 HNSW 索引 | 2023 年 B 輪 5000 萬美元 [公開資訊] |
| Qdrant | 開源向量資料庫 | Rust 實現的 HNSW | 2024 年 A 輪 2800 萬美元 [公開資訊] |
| Pinecone | 全託管向量資料庫 | 底層包含 HNSW 類圖索引 [估算] | 2023 年 B 輪 1 億美元，估值 7.5 億 [公開資訊] |
| ChromaDB | 輕量級嵌入資料庫 | 使用 hnswlib 作為後端 | 開源為主，具體融資不詳 |
| Meta (FAISS) | ANN 庫 | 整合 HNSW 實現 | 內部基礎設施 |
| Microsoft (DiskANN) | ANN 研究 | 提出 Vamana 圖（HNSW 的”磁碟友好”演進） | MSR 研究專案 |
| NVIDIA (cuVS/CAGRA) | GPU ANN | 提出 CAGRA 圖索引，思路與 HNSW 相關但針對 GPU 最佳化 | GPU 生態戰略 |
投資視角： HNSW 本身是開源演算法，無法直接”投資 HNSW”。投資路徑是通過搭載 HNSW 的向量資料庫公司、使用向量檢索的 AI 應用公司、以及為 HNSW 提供硬體加速的晶片公司。
投資邏輯
看多邏輯
- RAG 是 LLM 落地的必經之路：純引數記憶的 LLM 存在幻覺和知識過時問題，RAG 通過外部檢索彌補。只要 RAG 繼續是主流範式，向量檢索基礎設施就有剛需。
- HNSW 是事實標準：在 ANN-Benchmarks 等公開評測中，HNSW 在中等規模（1M-100M 向量）場景下的 recall-latency 綜合表現長期位居前列，生態鎖定效應強。
- 向量資料庫是新基礎設施層：類比關係型資料庫之於 Web 應用，向量資料庫之於 AI 應用有”必經之路”屬性。
- 增量更新能力：相比 IVF 需要定期重建聚類，HNSW 天然支援增量插入，適合生產環境中資料持續寫入的場景。
看空/風險邏輯
- 記憶體瓶頸：HNSW 的最大短板是記憶體佔用大。當向量規模達到 10 億級，即使有 PQ 壓縮輔助，記憶體成本也極高。DiskANN 等”磁碟友好”方案可能在超大規模場景蠶食份額。
- GPU 加速難：HNSW 的貪心搜尋本質上是序列的（每步依賴上一步的結果），難以充分利用 GPU 的大規模並行能力。NVIDIA 的 CAGRA 等方案用不同的圖建置/搜尋策略來適配 GPU，可能在高吞吐場景替代 HNSW。
- 長上下文/大視窗 LLM 的衝擊：如果 LLM 的上下文視窗持續擴大（如 1M+ tokens），部分 RAG 場景可能被”塞進上下文”替代，減少向量檢索需求。
- 演算法迭代風險：新 ANN 演算法不斷湧現（如 HNSW2、Vamana、NSSG、CAGRA 等），HNSW 的”事實標準”地位並非不可撼動。
關鍵觀察點
- 向量資料庫公司的真實 ARR 和客戶留存率
- 主要雲端廠商是自研 ANN 還是依賴開源庫
- GPU-native ANN 索引（CAGRA 等）是否在 benchmark 上系統性超越 HNSW
- RAG 範式是否被長上下文 LLM 侵蝕
常見誤讀糾偏
❌ 誤讀 1：“HNSW 是精確搜尋”
糾偏： HNSW 是 近似 最近鄰（ANN）搜尋。它不保證返回真正的 Top-K，而是在 ef 引數足夠大時以高機率接近精確結果。當 ef = n（等於全部向量數）時退化為精確搜尋，但此時無加速效果。實際部署中，Recall@10 在 95%-99.5% 的區間被認為是可接受的。
❌ 誤讀 2：“HNSW 只能在記憶體中工作”
糾偏： 經典 HNSW（如 hnswlib）確實要求全圖駐留記憶體，但後續研究已將 HNSW 擴充套件到磁碟友好場景。典型代表包括：
- DiskANN（Microsoft Research）：使用 Vamana 圖（與 HNSW 思路相似但做了磁碟 I/O 最佳化），向量儲存在 SSD 上，僅將圖結構和導航資訊保留在記憶體中。
- hnswlib 的 mmap 模式：可通過記憶體對映將索引檔案對映到虛擬記憶體，利用 OS 的頁面管理做部分換入換出。
- SPANN（Microsoft Research）：將向量聚類到磁碟上的 posting list 中，僅在記憶體中保留索引結構。
因此更準確的表述是：經典 HNSW 是記憶體優先（memory-centric）的演算法，但已有變體將其擴充套件到磁碟輔助場景。
❌ 誤讀 3：“HNSW 不支援刪除”
糾偏： HNSW 原始論文未詳細討論刪除操作，但實踐中主流實現（如 FAISS、Milvus、Weaviate）都通過 標記刪除（tombstone/deletion flag）+ 定期 compaction 的方式支援刪除。即：邏輯刪除時僅標記節點為已刪除，查詢時跳過；物理刪除在後臺 compaction 時重建受影響的邊。這會帶來一定的空間浪費和召回率波動。
❌ 誤讀 4：“HNSW 不需要調參，開箱即用”
糾偏： HNSW 的效能高度依賴 M、efConstruction 和 ef 三個引數的配置。M 和 efConstruction 在索引建置時確定且不可更改（需要重建索引），ef 可執行時調整。不當的引數選擇會導致：
- M 過小 → 圖連線度不足 → 召回率下降
- efConstruction 過小 → 圖質量差 → 召回率天花板低
- ef 過大 → 延遲過高
生產環境中，引數調優通常是基於業務的資料規模、維度分佈和延遲 SLA 的反覆實驗過程。
學習路徑
推薦學習路徑
Level 0: 概念理解
├── 閱讀本文
├── 理解"為什麼需要 ANN"和"HNSW 的多層圖思想"
│
Level 1: 動手實驗
├── 安裝 hnswlib (pip install hnswlib)
├── 在 10 萬條隨機向量上體驗 M/efConstruction/ef 的效果
├── 用 ann-benchmarks 跑對比測試
│
Level 2: 原理深入
├── 精讀原論文: Malkov & Yashunin, IEEE TPAMI 2018
├── 閱讀 hnswlib 原始碼（C++，約 2000 行，可讀性好）
├── 理解 heuristic pruning 的數學直覺
│
Level 3: 系統整合
├── 在 Milvus/Weaviate/Qdrant 中部署 HNSW 索引
├── 測試不同 M/ef 對召回率/延遲/QPS 的影響
├── 研究標量過濾 + HNSW 搜尋的融合策略（如 pre-filter vs post-filter）
│
Level 4: 前沿研究
├── 對比 DiskANN (Vamana)、CAGRA、HNSW2 等變體
├── 研究 GPU 加速 ANN 的並行化挑戰
├── 關注標量-向量混合索引（hybrid index）的最新進展關鍵論文/資源
| 資源 | 說明 |
|---|---|
| Malkov & Yashunin, IEEE TPAMI 2018 | HNSW 原始論文 |
hnswlib GitHub 倉庫 | C++ 參考實現，廣泛使用 |
ann-benchmarks.com | ANN 演算法線上 benchmark 平台 |
| FAI |