【向量检索引擎】向量引擎全景：算法、RAG 与专用引擎之间的一层

数据库研究前沿第 8 篇 把 HNSW、DiskANN、IVF-PQ 的算法假设讲清了；大模型基础设施第 17–18 篇 把 RAG 召回与向量库产品选型讲清了；湖仓第 21 篇 则把 Lance 留在「湖侧格式」边界。中间仍缺一层：生产向量引擎里，一条 insert / search 如何穿过 Proxy、Streaming Node、Query Node，Segment 如何从 Growing 变成带索引的 Sealed。

本文是「向量检索引擎」系列第 1 篇。目标不是重复 ANN 推导，也不是再写一遍 RAG 流水线，而是回答三个定位问题：

1. 专用向量引擎相对「带向量列的数据库」、湖上格式、纯 ANN 库，差在哪一层？
2. Milvus 2.6.x 的四层架构如何把写路径（流）与读路径（批）拆开？
3. 本系列 18 篇与相邻系列的分工边界在哪里？

本文是「向量检索引擎」系列第 1 篇（共 18 篇）。→ 系列目录

篇目	核心内容
第 1 篇 · 向量引擎全景	分工地图、Milvus 四层、系列路线
第 2 篇 · ANN 工程接口	Knowhere 插件契约（算法外链 frontier/08）
第 3 篇 · Segment 状态机	Collection / Growing / Sealed / Flush
第 5 篇 · Streaming 与 WAL	Woodpecker、实时可搜

版本锚定：Milvus 2.6.x（官方 Architecture Overview、Data Processing、Streaming Service、Knowhere、Woodpecker 文档）。机制结论以官方文档与 SIGMOD 2021 系统论文为准；本篇不粘贴未在本机执行的吞吐数字。

一、为什么需要「专用向量引擎」这一层

相似度检索的核心操作可以写成：给定查询向量 \(q \in \mathbb{R}^d\)，在集合 \(X = \{x_1,\ldots,x_n\}\) 上返回距离最近的 \(k\) 个点（或距离阈值内的点）。精确解在高维下代价接近 \(O(nd)\)；工程上几乎一律走近似最近邻（Approximate Nearest Neighbor, ANN），在召回率、延迟、内存之间折中——这是 db-frontier/08 的主题。

ANN 算法库（FAISS、Hnswlib、DiskANN）解决的是 索引结构与距离计算。生产系统还要回答算法库通常不包办的问题：

因此「专用向量引擎」不是把 float[] 塞进 PostgreSQL 再挂一个扩展那么简单，也不是把 FAISS 包一层 gRPC。它处在 ANN 算法 与 RAG / 业务检索 之间：下层消费 Knowhere 一类索引内核，上层被 llm-infra 里的召回服务调用。

flowchart LR
  frontier["db-frontier 08/09<br/>ANN 与混合过滤算法"]
  engine["本系列<br/>Milvus 引擎内核"]
  lake["lakehouse/21<br/>Lance 湖侧格式"]
  rag["llm-infra 17/18<br/>RAG 应用"]
  frontier --> engine
  lake --> engine
  engine --> rag

二、四类东西：不要混成一个词

站内与业界常把下列对象统称「向量库」。本系列严格区分：

争论（可核对双方）：一边是「向量应成为通用数据库的一等类型」（pgvector、部分多模数据库叙事）；另一边是「相似度检索的索引生命周期与 OLTP 页模型不兼容，应专用引擎」（Wang et al., SIGMOD 2021；Milvus Architecture）。本系列不宣称其中一方全面胜利——按规模、过滤复杂度、是否已有强 SQL 事务需求选型，决策树放在第 18 篇。

三、学术谱系：从 ANN 到向量数据管理系统

3.1 奠基：ANN 与磁盘假设

算法层的召回–QPS–内存三角、参数语义，见 db-frontier/08。本系列默认读者接受：索引是独立于原始向量的数据结构，构建与查询参数分离。

3.2 系统分叉：Milvus SIGMOD 2021 → 2.x 存算分离 → 2.6 Streaming

工程间隙：SIGMOD 2021 论文的架构切片与节点命名对应的是当时实现；本系列正文以 2.6.x 官方 Architecture / Data Processing 为准。读论文时不要把 2021 的组件图直接当成今天的 Proxy / Streaming / Query / Data 四角色。

3.3 开放问题（系列贯穿）

1. 统一多模引擎 vs 专用向量引擎：过滤与 join 变复杂时，专用引擎的表达式能力是否成为瓶颈？
2. 湖上 ANN 与在线引擎如何共享同一份 embedding 版本：snapshot / 主键对齐，见 lakehouse/21 与第 16 篇。
3. GPU 索引在共享集群上的调度与成本：Knowhere 支持 GPU 路径（官方文档），多租户下的利用率仍是工程开放问题（第 8、18 篇）。

四、Milvus 2.6.x 四层架构（本系列坐标系）

官方 Architecture Overview 把 Milvus 拆成相互独立扩展的四层（A 级）：

flowchart TB
  access["Layer1 Access<br/>Proxy 无状态接入"]
  coord["Layer2 Coordinator<br/>DDL TSO 拓扑 调度"]
  workers["Layer3 Workers"]
  storage["Layer4 Storage<br/>etcd / Object / WAL"]
  access --> coord
  access --> workers
  coord --> workers
  workers --> storage
  subgraph workersBox ["Worker 三类"]
    sn["Streaming Node<br/>Growing + WAL + 增量查询"]
    qn["Query Node<br/>Sealed 历史查询"]
    dn["Data Node<br/>compaction 与建索引"]
  end
  workers --- workersBox

4.1 API 三类走不同路径

官方按 API 类别给出架构流（Architecture Overview）：

注意：总表里 DQL 写「Batch Worker / Query Nodes」，细粒度查询流写明 Proxy 广播到相关 Streaming Node，由后者搜本地 Growing 并请求 Query Node 的 Sealed 结果，再经多层 reduce 回到 Proxy。本系列以 Data Processing 细粒度流 为准（第 7、9 篇展开）。

4.2 插入与检索的最小故事

插入（官方 Data Processing / Architecture）：

1. Proxy 校验并按 shard 规则拆包，送到对应 Streaming Node。
2. Streaming Node 赋 TSO，写入 WAL；提交后可参与实时查询。
3. Growing Segment 在策略触发下 flush 为不可变 Sealed，数据落对象存储。
4. Data Node 对 Sealed 建索引 / compaction；Coordinator handoff 后由 Query Node 加载。

检索：

1. Proxy 将请求发到相关 shard 的 Streaming Node。
2. Streaming Node 搜 Growing，并向持有 Sealed 的 Query Node 取历史结果，做 shard 内聚合。
3. Proxy 跨 shard reduce，返回客户端。

这就是本系列要钉住的「引擎层」——不是 efSearch=64 该取多少，而是 谁持有可变数据、谁持有不可变索引、何时 handoff。

五、与相邻系列的分工

六、十八篇地图

第一部分（01–03）：生态定位、ANN 接口、Segment 状态机——共同词汇。

第二部分（04–06）：Proxy/Coordinator、Streaming/WAL、对象存储布局——写路径与持久化。

第三部分（07–10）：Segcore/Query Node、Knowhere、分布式归并、Data Node——读路径与离线维护。

第四部分（11–14）：混合过滤、一致性、Delete/Upsert、副本故障——生产语义。

第五部分（15–18）：Qdrant、Lance、排障、选型——对照与收束。

系列贯穿的五个问题见 index；本篇只建立坐标系。

七、实验与证据约定

本系列性能相关实验放在 reproduce/（随第 3、7、11 篇启动）。环境以 Docker 单机 Milvus 2.6.x 为主。

硬约束（与 PLAN.md 一致）：

• 未跑的 benchmark 不写进结论。
• 官方 Woodpecker 对比表（Kafka / Pulsar / S3 等）若引用，必须标明 官方单节点基准、非本机复现，并写清后端假设。
• 十亿级数字只作带出处的外部引用，不作自测伪装。

八、小结

专用向量引擎解决的是 持续写入 + 近似检索 + 过滤 + 分布式生命周期，不是单独一个 ANN 数据结构。Milvus 2.6.x 用 Access / Coordinator / Streaming·Query·Data Worker / 共享存储 四层，把 Growing 实时路径 与 Sealed 历史路径 拆开，再用 handoff 缝合——这是本系列的主线叙事。

下一篇进入数据模型：Collection · Partition · Segment · Channel，把 Growing / Sealed / Flush / Handoff 钉成可在排障时复述的状态机。

参考资料

核心论文

1. Wang, Jianguo et al., Milvus: A Purpose-Built Vector Data Management System, SIGMOD 2021（系统论文；架构以当时实现为准，与 2.6.x 对照阅读）。
2. Malkov, Yu. A. & Yashunin, D. A., Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs, IEEE TPAMI 2018（HNSW；算法细节见 db-frontier/08）。
3. Subramanya, Suhas Jayaram et al., DiskANN: Fast Accurate Billion-point Nearest Neighbor Search on a Single Node, NeurIPS 2019。

规范 / 文档

4. Milvus Documentation v2.6.x, Architecture Overview（四层、API 路径、insert/search 示例流）。
5. Milvus Documentation v2.6.x, Data Processing（Growing/Sealed、flush、index build、query、handoff）。
6. Milvus Documentation v2.6.x, Knowhere / Streaming Service / Woodpecker（后续篇展开）。

站内

7. 本系列 index、PLAN.md。
8. db-frontier/08–09、llm-infra/17–18、lakehouse/21。

返回 系列目录 ｜ 下一篇：ANN 工程接口