索引内核：在取舍三角里选一个点

这一章承接 01 §1.6 留下的「索引内部怎么工作」。每种索引按同一套结构讲：一句话本质 → 为什么要它 → 比文档深一层的机制 → 必要处配图或 callout。代码片段只用来让旋钮落地，未在本机运行，按概念读。读者已懂 ANN 的召回↔速度权衡，3.1 只快速把第三个轴（内存）补进来，不重述基础。

3.1取舍三角：召回 / 延迟·QPS / 内存

向量索引在三个互相拉扯的维度间取舍——高召回、低延迟·高 QPS、低内存——没有任何一种索引能同时占满三个角。

比文档深一层的机制：三个角彼此牵制，背后是同一组物理约束。要高召回就得检查更多候选点，候选越多越慢——召回顶着延迟。要低延迟·高 QPS就得把数据结构和向量留在内存、用更精巧的图减少跳数——速度顶着内存。要低内存就得量化压缩（float32 → uint8 甚至 1-bit）或把数据下沉到 SSD——省内存又顶着召回（量化有损）和延迟（SSD 慢于 RAM）。索引类型决定你坐在三角的哪一区，参数（nprobe、ef）再在小范围里微调。

与索引粒度的关系：回指 01 §1.6——索引不是整张 collection 一份，而是每个 sealed segment 各建一份。所以下文每一种索引，描述的都是「一个 segment 内部那份结构」长什么样；一次检索是各 segment 各跑一遍再合并 top-k（读路径在 04 章展开）。这也意味着索引选型的内存账要乘以 segment 数。

3.2FLAT：暴力精确，召回的基准线

FLAT 不建任何近似结构，把查询向量和每一条向量逐一算距离——召回率恒为 100%，但每次检索是一次全量扫描。

比文档深一层的机制：FLAT 在三角里坐死在「高召回」顶点——召回拉满，代价是延迟随数据量线性增长（O(N) 距离计算），且内存等于原始向量全量（不压缩、不加结构）。它没有任何建索引旋钮，也没有召回↔速度的拨盘可调——召回永远是 1，唯一能动的是 metric。这正是它和后面所有索引的分界：其他索引都在用召回换速度或内存，FLAT 一样都不换。Milvus 还有个 GPU_BRUTE_FORCE，是 FLAT 的 GPU 版，靠显存带宽把全扫做快，召回同样是 1。

3.3IVF 家族：聚类倒排，召回↔速度有个拨盘

IVF（inverted file，倒排文件）先用 k-means 把所有向量聚成 nlist 个簇，查询时只扫离查询向量最近的 nprobe 个簇——nprobe 就是召回换速度的连续拨盘。

比文档深一层的机制：建索引时跑一次 k-means 得到 nlist 个簇心，每条向量按最近簇心归入对应倒排桶——nlist 是建索引旋钮，定了簇的数量（粒度），改它要重建。查询时算查询向量到各簇心的距离，取最近 nprobe 个簇、只在这几个桶里做精算——nprobe 是查询旋钮，每次检索可调：nprobe 调大 → 扫更多簇 → 召回升、变慢；调小 → 反之。同一份建好的 IVF，靠 nprobe 就能在召回↔速度间滑动，无需重建——这是 3.8 那条线的第一个实例。

三个变体：在「内存 / 召回」上再分叉

IVF 的桶里存什么向量，决定了它在三角里往「低内存」角滑多远：

SQ 与 PQ 的取舍方向相反：SQ8（scalar quantization，标量量化）把每一维独立从 4 字节压到 1 字节，简单、解码快，所以更快；PQ（product quantization，乘积量化）把向量切成若干子向量、每段用一个小码本（codebook）的索引来代替，压缩率更狠，所以在同等压缩比下召回优于 SQ，但码本查表使它在解码上让出一点速度。一句话：要省内存优先 PQ（同压缩召回更高），要快优先 SQ。

3.4HNSW：分层导航小世界图，高召回区的 QPS 王者

HNSW（hierarchical navigable small world，分层可导航小世界）建一个多层图：顶层稀疏、底层稠密，查询从顶层入口贪心下降，逐层精化到底层目标——结构上几乎就是向量版的跳表（skip list）。

比文档深一层的机制：图分多层。顶层只有极少数节点、连接稀疏，边「跨度大」，用来快速粗定位到目标区域；越往下层节点越多、连接越密，用来精细逼近。查询从顶层一个入口点出发，在当前层贪心地走向离查询向量更近的邻居，走不动了就下沉一层、继续走，直到底层（L0，含全部节点）锁定 top-k。三个旋钮：M（每个节点的最大连接数）和 efConstruction（建图时每步维护的候选集广度）是建索引旋钮——M 越大图越密、召回越高但内存和建图耗时越涨；ef（查询时候选集广度）是查询旋钮，ef 越大召回越高、越慢。和 IVF 同构：建好的图靠 ef 滑动召回↔速度，无需重建。

3.5DiskANN：把图放到 SSD，数据超过内存时的选择

DiskANN 把图（Vamana 图）和完整向量放在 SSD，只在 RAM 里留一份 PQ 压缩向量做近似距离筛选，用 beam search（束搜索）分批从磁盘取数——用于单机内存装不下全部向量的规模。

比文档深一层的机制：分两层存。RAM 里只放每条向量的 PQ 压缩版（很小），用来快速算近似距离、决定图上往哪走；SSD 里放完整精确向量 + 图的邻接表。查询用 beam search：根据 RAM 里的近似距离选一批候选节点，批量从 SSD 读它们的完整向量和邻居（批量是为了摊薄 SSD 的随机读延迟），算精确距离、再扩展——如此迭代。所以「on-disk」是个半真半假的说法：它仍占 RAM（那份 PQ 不小），只是把大头（完整向量 + 图）挪到了 SSD。

3.6GPU / CAGRA：显存换数十倍吞吐

Milvus 的 GPU 索引族（GPU_BRUTE_FORCE / GPU_IVF_FLAT / GPU_IVF_PQ / GPU_CAGRA）把检索搬到显卡；CAGRA 是 NVIDIA RAFT/cuVS 做的 GPU 原生邻近图，在大批量、高并发查询下吞吐可达 CPU 的数十倍。

比文档深一层的机制：前三个 GPU_* 是 CPU 同名索引的显卡移植（暴力 / IVF_FLAT / IVF_PQ），把扫描和距离计算放到 GPU。GPU_CAGRA 不一样——它是专为 GPU 设计的近邻图（来自 NVIDIA 的 RAFT/cuVS 库），图的构造和遍历都按 GPU 的并行访存模式优化，所以在高并发批量查询下最能榨干显卡。内存账：CAGRA 约占原始数据的 1.8 倍显存（图结构的额外开销），规划显存时要按这个系数估。

3.7稀疏索引：给稀疏向量与全文检索的倒排

SPARSE_INVERTED_INDEX 是为稀疏向量（每条只有少量非零维）和 BM25 全文检索准备的倒排索引，度量只能是 IP 或 BM25。

比文档深一层的机制：检索算法用 DAAT（document-at-a-time，逐文档推进）家族。当前默认是 DAAT_MAXSCORE，可选 DAAT_WAND——两者都靠上界剪枝（提前跳过进不了 top-k 的文档）加速，MAXSCORE 在多数分布下剪枝更稳。旧的 SPARSE_WAND 索引类型自 2.5.4 起已弃用，新代码统一用 SPARSE_INVERTED_INDEX 并通过参数选 DAAT 算法。度量上它只认 IP（稀疏点积）和 BM25（全文打分），稠密那套 L2/COSINE 在这里没有意义。

3.8建索引旋钮 vs 查询旋钮（这一节单独记）

参数分两类：建索引时写进结构、改了必须重建的（nlist、M、efConstruction），和查询时每次现传、随时可调的（nprobe、ef、search_list）——这条区分是面试高频考点。

比文档深一层的机制：核心一句话——同一份建好的索引，靠查询旋钮就能在「低延迟 ↔ 高召回」之间连续滑动，完全不用重建。IVF 调 nprobe（扫几个簇）、HNSW 调 ef（候选集多宽）、DiskANN 调 search_list（beam 宽度）——调大都是「多看一些 → 召回升、变慢」，调小反之。这就是为什么线上 A/B 召回、按时段切换召回/延迟侧重，都不需要重建索引，只改检索请求里的参数。反过来，nlist/M/efConstruction 任何一个想改，都得推倒重建——它们决定了簇划分或图拓扑，是「冷」参数。

3.9选型决策树 + 度量相容矩阵

选索引先按「数据是否超内存 / 要不要 GPU / 要最高召回还是省内存」走一棵决策树定家族，再用相容矩阵确认向量类型与度量对齐。

决策的主干是几个互斥的硬约束，按顺序问下来基本就定了家族（图 3.3）。注意这棵树只解决稠密、常规规模的主路径，两个旁支单列：稀疏向量 / 全文 → SPARSE_INVERTED_INDEX；要 100% 精确且数据小 → FLAT。

度量相容矩阵：选嵌入模型训练用的那个

定了索引家族，还要确认向量类型 × 度量对齐——更关键的是，度量必须选嵌入模型训练时用的那个，否则距离的语义都不对，召回无从谈起。

一份把旋钮写明白的建索引示例

# HNSW：高召回 + 高 QPS 的默认稠密索引；M / efConstruction 是建索引旋钮
from pymilvus import MilvusClient

client = MilvusClient(uri="http://localhost:19530")

index_params = client.prepare_index_params()
index_params.add_index(
    field_name="vector",
    index_type="HNSW",                 # 换 "IVF_SQ8" 即走省内存路径；"DiskANN" 走超内存路径
    metric_type="COSINE",              # GPU 索引时这里不能填 COSINE：改 IP + 先归一化
    params={"M": 16, "efConstruction": 200},   # 建索引旋钮：改了要重建
)
client.create_index("docs", index_params=index_params)   # 每个 sealed segment 各建一份(01 §1.6)

# 检索时才传查询旋钮 ef —— 同一份索引靠它在 召回↔延迟 间滑动，无需重建
res = client.search(
    collection_name="docs", data=[query_vector], limit=10,
    search_params={"metric_type": "COSINE", "params": {"ef": 64}},  # 查询旋钮(04 章再现)
)