【向量检索引擎】向量引擎全景：算法、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 篇（共 19 篇）。→ 系列目录

篇目	核心内容
第 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 系统论文为准；本篇不粘贴未在本机执行的吞吐数字。

一、最小故事：同一条向量，四个「库」会怎么放

假设你有 \(n=10^6\) 条文档向量，\(d=768\)，业务还要求：

• 白天持续写入新文档；
• 查询带标量过滤（例如 tenant_id = 42）；
• 夜间希望历史数据上有高质量 ANN 索引。

若只调用 FAISS / Hnswlib，你自己要写：增量缓冲、崩溃恢复、过滤、分片与索引重建。若塞进 PostgreSQL + pgvector，你得到 SQL 与事务，但索引生命周期、十亿级对象存储与专用 ANN 调度通常不是 OLTP 页模型的一等公民。若把向量只放在 Lance 文件里，湖侧随机 take 很快（见 lakehouse/21），但「刚写入立刻可搜 + 集群级 handoff」仍要另接服务。

专用向量引擎（本系列以 Milvus 为主线）要同时回答：持续写入、近似检索、过滤、分布式生命周期。后面四层架构与 Growing/Sealed 二分，都是为这条故事服务的。

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

相似度检索的核心操作可以写成：给定查询向量 \(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 and hybrid filter"]
  engine["This series<br/>Milvus engine kernel"]
  lake["lakehouse/21<br/>Lance lake format"]
  rag["llm-infra 17/18<br/>RAG application"]
  frontier --> engine
  lake --> engine
  engine --> rag

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

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

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

3.1 常见误解

1. 「向量库 = 一个大 HNSW」。生产里索引贴着 Segment，一次 search 是多段候选归并（第 3、9 篇），不是单图一次调用。
2. 「接了 pgvector 就等于有了专用引擎」。同进程 SQL 很强，但不等价于 Streaming/Query/Data 分流与对象存储上的索引生命周期。
3. 「湖上有向量列就不必上在线引擎」。湖擅长版本与随机访问；「刚写入即可搜」依赖 WAL + Growing 路径（第 5、16 篇）。

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

4.1 奠基：ANN 与磁盘假设

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

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

同一条 insert 在两代叙事里：SIGMOD 2021 论文强调动态更新与异构执行；2.6 文档则把「可变增量」钉在 Streaming Node 的 Growing 上，把「不可变历史 + 重索引」钉在 Query/Data Node。工程间隙：论文组件名与今天的 Proxy / Streaming / Query / Data 不完全同构——本系列正文以 2.6.x 官方 Architecture / Data Processing 为准。

4.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 级）。下图用独立 SVG 强调二维分层；后文 Mermaid 再拆 insert / Growing–Sealed 分工。

flowchart TB
  access["Layer1 Access<br/>Proxy"]
  coord["Layer2 Coordinator<br/>DDL TSO topology"]
  workers["Layer3 Workers"]
  storage["Layer4 Storage<br/>etcd / Object / WAL"]
  access --> coord
  access --> workers
  coord --> workers
  workers --> storage
  subgraph workersBox ["Three worker roles"]
    sn["Streaming Node<br/>Growing + WAL"]
    qn["Query Node<br/>Sealed history"]
    dn["Data Node<br/>compaction + index"]
  end
  workers --- workersBox

5.1 API 三类走不同路径

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

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

5.2 插入端到端时序

sequenceDiagram
  participant C as Client
  participant P as Proxy
  participant SN as StreamingNode
  participant OS as ObjectStore
  participant DN as DataNode
  participant QN as QueryNode
  C->>P: insert
  P->>SN: route by shard
  SN->>SN: assign TSO, append WAL
  Note over SN: Growing searchable
  SN->>OS: flush Sealed
  DN->>OS: build index / compact
  Note over QN: handoff then load
  QN->>OS: load Sealed + index

步骤与官方 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 加载。

5.3 Growing 与 Sealed 的分工

flowchart LR
  subgraph realtime ["Realtime path"]
    wal["WAL commit"]
    grow["Growing segment<br/>on Streaming Node"]
    wal --> grow
  end
  subgraph history ["History path"]
    sealed["Sealed on object store"]
    idx["Index via Data Node"]
    qn["Query Node load"]
    sealed --> idx --> qn
  end
  grow -->|"flush + handoff"| sealed

检索最小故事：Proxy → 相关 shard 的 Streaming Node → 本地 Growing + 远程 Query Node 的 Sealed → shard 内聚合 → 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 等）若引用，必须标明 官方单节点基准、非本机复现，并写清后端假设。
• 十亿级数字只作带出处的外部引用，不作自测伪装。

九、小结

三句话小结

1. 专用向量引擎补的是 ANN 库与 RAG 之间的 写入、过滤、分布式生命周期，不是又一个距离函数。
2. Milvus 2.6.x 用四层把 Growing 实时 与 Sealed 历史 拆开，再用 flush / handoff 缝合。
3. 读本系列时先记住「谁持有可变数据、谁持有不可变索引」，再去调 ef / nprobe。

下一篇进入接口层：ANN 算法工程接口；数据模型见 Segment 状态机。

参考资料

核心论文

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 2020 (vol. 42, no. 4)（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 工程接口