KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

向量数据库工程课：从暴力检索到 Milvus — keel 龙骨

用 faiss 与 pgvector 的真跑数据把向量检索讲成一本账：精确检索的延迟与内存怎么算、L2/内积/余弦的选错代价、IVF 与 HNSW 的结构与调参曲线、PQ 的压缩比与召回损失、建索引耗时与落盘体积、过滤为什么必须下推、pgvector 的迭代扫描边界，以及 Milvus 的分层架构与一致性级别。含完整的 recall@10 与 QPS 对照表。

用 faiss 与 pgvector 的真跑数据把向量检索讲成一本账：精确检索的延迟与内存怎么算、L2/内积/余弦的选错代价、IVF 与 HNSW 的结构与调参曲线、PQ 的压缩比与召回损失、建索引耗时与落盘体积、过滤为什么必须下推、pgvector 的迭代扫描边界，以及 Milvus 的分层架构与一致性级别。含完整的 recall@10 与 QPS 对照表。

章节目录

  1. 00 · 从暴力检索到 ANN — 这一章不引入任何索引，只把「不建索引」的那条基线跑出来。理由很实际：后面每一章都会说某个索引「更快」「更省内存」，如果没有一条自己机器上量出来的基线，这些说法就只是别人文档里的形容词。基线跑完，你还会发现一件反直觉的事——向量检索的延迟不随数据量线性增长，它会在某个点突然掉下一个台阶。
  2. 01 · 向量、距离与度量 — 上一章的 Flat 基线能成立，前提是「距离」定义清楚。这一章用同一批数据把 L2、内积、余弦三种度量放一起跑，你会得到一个不太好接受的结果：在这批数据上，L2 和内积的 top-10 一条都不重合，余弦和内积也只重合 21.8%。度量选错，后面所有索引参数都调不到点子上。
  3. 02 · 索引家族 — 第 01 章把「什么算近」定义清楚了，这一章回答「怎么少算一些」。四个家族——IVF、PQ、HNSW、DiskANN——各自拿掉了检索里的不同环节。你需要建立的判断是：每个参数在拿掉什么、它的失效场景长什么样。参数配错的代价在本章都有实测数字。
  4. 03 · 召回率-延迟曲线 — 这一章是本课证据最厚的一章：三条 nlist × 四个 nprobe 一共 12 组配置、两种 M × 四个 efSearch 一共 8 组配置，全部本机实测。看完你会拿到一个能直接用的判断——IVF 的 nprobe=1 召回只有 2.5%，而想要 100% 召回得把 nprobe 调到等于 nlist，那时它比 Flat 还慢。
  5. 04 · Milvus 架构与一致性 — 前三章都在单机内存里做。这一章换一个量级：把向量检索做成一个分布式服务时，会多出哪些层、依赖哪些外部存储、一致性要付什么代价。 本章的证据性质和其他章不同。 本机实验台没有装上 pymilvus（importlib.util.find_spec('pymilvus') 返回 None），milvus-lite 虽然装了但没有客户端库可用，所以本章没有任何本机跑出来的 Milvus 输出。下面关于架构、一致性、参数的内容全部来自 Milv
  6. 05 · 过滤与混合检索 — 真实检索几乎从不裸搜。你总要带条件：tenantid = 7、status = 'active'、createdat > ...。过滤放在检索的哪一步，决定了 top-k 里还能剩几条。这一章在两个引擎上跑出结论：faiss 里「先检索再过滤」会把 89.8% 的查询打空，pgvector 里同样的问题默认也会发生，得靠 iterative_scan 才修一半。
  7. 06 · 选型与运维 — 前面五章把参数和代价都量过了，这一章收口到两个决策：用什么（pgvector / Milvus / faiss），以及什么时候重建索引。选型的答案不在「谁最先进」，而在你手上有什么、能接受什么代价。重建索引是一次性成本，但时机选错会把一次性成本变成线上事故。

进入 keel 阅读