6.1 RAG 架构中 Milvus 的定位

Milvus 不是 pgvector 的替代品——它们是互补的，各有所长

这一节在讲什么？

前面五章我们学了 Milvus 的架构、数据模型、CRUD、索引和高级特性，现在要把这些知识放到 RAG 系统中来看——Milvus 在 RAG 架构中扮演什么角色？它跟 pgvector 和 Chroma 的定位有什么不同？什么时候该选 Milvus、什么时候该选 pgvector？这一节我们要建立清晰的技术选型框架。

三种向量数据库在 RAG 中的定位

RAG 系统的规模演进：

  阶段1：原型验证（1~10 万文档）
  ┌────────────────────────────────┐
  │  Chroma                        │
  │  零配置、Python 原生            │
  │  快速验证 RAG pipeline          │
  └────────────────────────────────┘
           ↓ 数据量增长

  阶段2：生产上线（10~100 万文档）
  ┌────────────────────────────────┐
  │  pgvector                      │
  │  SQL 原生、事务一致性           │
  │  结构化数据 + 向量混合查询      │
  └────────────────────────────────┘
           ↓ 数据量继续增长

  阶段3：大规模生产（100 万~10 亿文档）
  ┌────────────────────────────────┐
  │  Milvus                        │
  │  分布式、量化、多向量搜索       │
  │  十亿级向量毫秒级检索           │
  └────────────────────────────────┘

这不是"谁更好"的问题——而是"什么阶段用什么工具"的问题。Chroma 适合快速验证想法，pgvector 适合需要 SQL 和事务的生产系统，Milvus 适合数据量超大的场景。

Milvus 在 RAG 中的独特优势

优势1：分布式架构 → 水平扩展

当你的文档数量从 100 万增长到 1 亿，pgvector 的单机架构会成为瓶颈——内存不够、搜索变慢。Milvus 的分布式架构让你可以通过增加 QueryNode 来水平扩展搜索能力，数据量无上限。

优势2：量化索引 → 同等内存下存储更多向量

pgvector 不支持向量量化——1000 万条 768 维向量的 HNSW 索引需要约 32 GB 内存。Milvus 的 IVF_PQ 索引只需要约 0.5 GB——同样的内存可以存储 60 倍的向量。这对于内存预算有限但数据量大的场景至关重要。

优势3：Partition → 多租户天然隔离

如果你的 RAG 系统需要服务多个租户（比如 SaaS 产品），Milvus 的 Partition 可以实现物理级别的数据隔离——每个租户的数据在独立的分区中，搜索时只扫描自己的分区。pgvector 需要在应用层通过 WHERE 条件实现逻辑隔离，性能不如物理隔离。

优势4：多向量搜索 → 多模态 RAG

如果你的 RAG 系统需要同时搜索文本和图像（比如图文混合的文档库），Milvus 的多向量搜索和 RRF 合并可以一次完成多路检索。pgvector 和 Chroma 需要建两个表/Collection，在应用层合并结果。

Milvus 的劣势

劣势1：无 SQL → 不能做 JOIN 和复杂查询

pgvector 的核心优势是 SQL——你可以用 JOIN 关联文档表和用户表、用子查询做复杂过滤、用窗口函数做分组统计。Milvus 没有这些能力——所有复杂查询都需要在应用层拼接。

劣势2：无事务 → 不能保证跨 Collection 的一致性

pgvector 的 ACID 事务保证了文档入库和向量索引更新的原子性。Milvus 没有事务——如果你在 Milvus 中插入向量数据的同时需要在 PostgreSQL 中插入业务数据，这两个操作无法在同一个事务中完成。

劣势3：运维复杂 → 需要管理多个组件

pgvector 的运维就是 PostgreSQL 的运维——你已经很熟悉了。Milvus 的运维需要管理 etcd、MinIO/S3、Pulsar/Kafka 以及 Milvus 自身的多个组件——排障门槛高得多。

技术选型决策框架

场景	推荐方案	理由
快速验证 RAG 原型	Chroma	零配置，最快上手
生产系统需要 SQL 和事务	pgvector	SQL 原生，事务一致性
数据量 < 1000 万，需要混合查询	pgvector	单机够用，SQL 灵活
数据量 > 1000 万，持续增长	Milvus	分布式，可水平扩展
内存有限但数据量大	Milvus	量化索引节省内存
多租户 SaaS	Milvus	Partition 物理隔离
多模态 RAG	Milvus	多向量搜索 + RRF

混合架构：pgvector + Milvus 共存

在实际生产中，最常见的不是"只用 Milvus"或"只用 pgvector"，而是两者共存——pgvector 处理结构化数据和中等规模向量搜索，Milvus 处理超大规模纯向量搜索：

混合架构：

  用户请求
     │
     ▼
  ┌──────────────────────────────────────────┐
  │              应用层                       │
  │                                          │
  │  if 需要结构化过滤 + 向量搜索:            │
  │      → pgvector（WHERE + 向量搜索）       │
  │  elif 超大规模纯向量搜索:                 │
  │      → Milvus（分布式 + 量化）            │
  └──────────────────────────────────────────┘
     │                    │
     ▼                    ▼
  ┌──────────┐    ┌──────────┐
  │ pgvector │    │  Milvus  │
  │ 用户表    │    │ 全量向量  │
  │ 订单表    │    │ PQ 索引  │
  │ 热门文档  │    │          │
  │ (100万)  │    │ (1亿+)   │
  └──────────┘    └──────────┘

小结

这一节我们聊了 Milvus 在 RAG 架构中的定位：Chroma 适合原型验证，pgvector 适合需要 SQL 和事务的生产系统，Milvus 适合数据量超大的场景。Milvus 的独特优势是分布式架构、量化索引、Partition 多租户和多向量搜索，劣势是无 SQL、无事务、运维复杂。在实际生产中，pgvector + Milvus 混合架构是最常见的选择。下一节我们用 Milvus 搭建一个完整的 RAG Demo。

6.1 RAG 架构中 Milvus 的定位 ​

这一节在讲什么？ ​

三种向量数据库在 RAG 中的定位 ​

Milvus 在 RAG 中的独特优势 ​

优势1：分布式架构 → 水平扩展 ​

优势2：量化索引 → 同等内存下存储更多向量 ​

优势3：Partition → 多租户天然隔离 ​

优势4：多向量搜索 → 多模态 RAG ​

Milvus 的劣势 ​

劣势1：无 SQL → 不能做 JOIN 和复杂查询 ​

劣势2：无事务 → 不能保证跨 Collection 的一致性 ​

劣势3：运维复杂 → 需要管理多个组件 ​

技术选型决策框架 ​

混合架构：pgvector + Milvus 共存 ​

小结 ​