15.Milvus是什么?为什么RAG系统经常使用它?

Milvus 是什么？为什么 RAG 系统经常使用它？

码海寻道 · 大模型、智能体与 RAG 工程组件系列第 15 篇

当企业知识库从几千个文档增长到数百万个文本片段，RAG 系统面临的问题就不再只是"能不能查到"，而是：向量如何存储、索引如何构建、查询如何扩展，以及检索服务是否会拖慢业务数据库。

Milvus 就是为这类向量检索场景设计的开源向量数据库。它不负责生成答案，也不是 Embedding 模型，而是接收向量、建立索引，并根据查询向量找出最相似的数据。

一、Milvus 在 RAG 中负责哪一段？

一次典型的知识库问答可以拆成以下链路：

用户问题
   ↓
Embedding 模型：问题 → 查询向量
   ↓
Milvus：向量相似度检索
   ↓
返回 chunk_id、文本标识和相似度
   ↓
PostgreSQL：查询权限、版本和业务元数据
   ↓
大模型：根据召回内容生成回答

Milvus 的核心职责是"高效找相似向量"。原始文件通常放在 MinIO、S3 或 OSS，用户、文档、权限和任务状态通常放在 PostgreSQL，Milvus 中保存向量以及用于检索关联的字段。

二、Milvus 为什么会带着 etcd、MinIO 和 Standalone？

第一次用 Docker Compose 启动 Milvus 时，常常会看到三个容器：milvus-etcd、milvus-minio 和 milvus-standalone。这不是把三个向量数据库启动起来，而是一个 Milvus 实例依赖的几个角色：

组件	主要职责	不负责什么
etcd	保存 Collection、Schema、Segment、索引等元数据，并参与服务注册和健康检查	不保存完整文本，也不执行向量相似度搜索
MinIO / S3	保存 Milvus 的持久化对象，例如数据文件、索引文件和部分日志/WAL相关对象	不负责租户权限，也不是 Milvus 的查询 API
Milvus Standalone	在单机进程中运行 Milvus 的主要服务，对外提供 19530 等访问入口	不是高可用集群，也不是业务应用层

可以用下面这张图理解它们的关系：

应用 / PyMilvus
       │ 19530
       ▼
Milvus Standalone
   ├── 读取 etcd：知道有哪些集合、分区、索引和服务
   ├── 读取 MinIO：加载数据文件和索引文件
   └── 执行插入、加载、过滤和向量检索

PostgreSQL：业务元数据、权限、任务状态
应用自己的 MinIO：PDF、Word、图片等原始文件（可与 Milvus 存储分开）

这里有一个容易被忽略的边界：Milvus 使用的 MinIO 与 RAG 应用保存原始文件的 MinIO 可以是同一个 MinIO 服务，但最好使用不同的 Bucket 或前缀，并分别管理权限、生命周期和备份。不要因为"都叫 MinIO"就把两类数据混在一起。

Standalone 是什么部署模式？

Standalone 表示单机部署形态，不是一个独立的功能模块。它把多个 Milvus 服务角色收拢到一个 Milvus 进程或容器中，适合本地开发、功能验证和中小规模内部服务。官方 Docker Compose 模板通常会同时启动 Milvus、etcd 和 MinIO；某些安装脚本还会把 etcd 嵌入 Milvus 容器中，具体组合会随 Milvus 版本变化。

因此，Standalone 可以理解为"方便启动的单机版 Milvus"，而不是"生产集群的高可用替代品"。当查询、写入、索引构建和故障恢复需要独立扩展时，应评估 Distributed 或 Kubernetes 部署。

三、它和普通数据库有什么不同？

传统数据库擅长精确查询：

SELECT * FROM documents WHERE document_id = 'doc-001';

向量数据库擅长近似查询：

给定查询向量 q，找出距离 q 最近的 Top K 个向量。

二者的查询目标不同。用户问"报销差旅住宿标准是什么"，系统通常不会拿这句话做完全相等匹配，而是将问题和文档片段都转换成向量，再根据语义距离寻找相关内容。

四、Milvus 的主要能力

1. 保存多种向量和标量字段

一个实体可以包含主键、文本片段、租户编号、文档编号和向量字段。向量可以是稠密向量，也可以根据版本和场景使用稀疏向量、二进制向量等类型。

2. 通过索引降低搜索成本

最直接的 FLAT 会逐个比较向量，结果精确但数据量大时成本高。IVF、HNSW 等索引通过减少候选范围，换取更低的查询延迟。

3. 支持向量检索与标量过滤

例如只检索某个租户、某个部门或已发布文档：

results = client.search(
    collection_name="knowledge_chunks",
    data=[query_vector],
    limit=5,
    filter='tenant_id == "tenant-a" and status == "published"',
    output_fields=["document_id", "chunk_id", "text"],
)

过滤条件不是权限系统的替代品。生产环境仍应在应用层和业务数据库中完成权限判断，并将安全范围作为检索条件的一部分。

4. 支持独立扩展

Milvus 采用计算与存储分离的架构，查询节点、数据节点和索引节点可以根据负载进行扩展。这使它更适合向量检索已经成为核心负载的系统。

五、一个最小的 Milvus 检索示例

安装 Python SDK：

pip install pymilvus

连接 Milvus Lite、Standalone 或远程服务时，连接地址不同，但客户端调用方式可以保持相近：

from pymilvus import MilvusClient

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

query_vector = [0.01, 0.12, 0.34]  # 实际维度必须和集合定义一致

results = client.search(
    collection_name="knowledge_chunks",
    data=[query_vector],
    anns_field="embedding",
    limit=3,
    output_fields=["document_id", "chunk_id"],
)

for hits in results:
    for hit in hits:
        print(hit["id"], hit["distance"], hit["entity"])

注意：示例中的向量维度只是演示。真实项目必须由 Embedding 模型确定维度，并保证写入向量和查询向量使用同一模型、同一归一化规则和同一距离指标。

六、Milvus 不会自动解决哪些问题？

Milvus 不能替你完成以下工作：

• PDF、Word、Excel 的解析和 OCR；
• 文本切分、Embedding 生成和模型版本管理；
• 文档权限、租户隔离和数据脱敏；
• 召回结果是否真正回答了用户问题；
• 业务数据库与向量数据的同步；
• RAG 最终答案的评估和引用生成。

因此，Milvus 只是 RAG 检索链路中的一个基础设施组件。把它部署起来，不等于知识库就会自动变准确。

七、什么时候值得使用 Milvus？

优先考虑以下情况：

1. 向量数量和查询并发持续增长；
2. 向量检索已经明显影响 PostgreSQL 等业务数据库；
3. 需要专门的索引、分片和查询节点扩展能力；
4. 需要同时处理多种向量或混合检索场景；
5. 团队能够承担额外的部署、监控、备份和升级成本。

如果项目仍处于原型阶段，且业务数据与向量数据关联紧密，PostgreSQL 加 pgvector 可能更简单。选型应以压测和运维能力为依据，而不是只看产品名气。

八、从本地启动到连接验证

如果只是验证 Milvus 的集合、插入和检索能力，优先使用官方提供的 Docker Compose 文件，不要手动拼接一套未经验证的 etcd、MinIO 和 Milvus 版本组合：

# 以官方文档当前提供的版本文件为准
wget https://github.com/milvus-io/milvus/releases/download/v3.0.0/milvus-standalone-docker-compose.yml -O docker-compose.yml
docker compose up -d
docker compose ps

启动后，应用通常只连接 Milvus 的 19530 端口；etcd 和 MinIO 是 Milvus 的内部依赖，不应直接暴露给公网。检查时重点看三个服务是否健康、数据卷是否持久化，以及 Milvus 日志中是否出现连接 etcd 或对象存储失败。

docker compose logs --tail 100 standalone
docker compose logs --tail 100 etcd
docker compose logs --tail 100 minio

如果使用的是嵌入式 Standalone 脚本，服务名和日志命令可能不同；文章中的命令用于说明排查思路，实际以下载到的 Compose 文件为准。停止容器和删除数据卷是两件事，测试环境也不要把 down 与删除 volumes 混为一谈。

九、上线前的基本检查

• 明确向量维度和距离指标；
• 为每条 Chunk 设计稳定的业务 ID；
• 设计文档更新、删除和权限变更的同步机制；
• 使用真实问题集测试 Recall@K 和 P95 延迟；
• 区分 Milvus 检索结果与最终答案质量；
• 准备备份、重建索引和失败重试方案。

结语

Milvus 可以理解为 RAG 系统中的"专用向量检索层"：它让向量存储、索引和大规模相似度搜索拥有独立的工程能力，但它并不替代模型、业务数据库和知识库处理流程。

下一篇将继续拆解 Milvus 的数据模型：Collection、Partition 和向量字段分别是什么，以及它们应该如何映射到知识库业务。

参考资料

1. Milvus 官方文档：What is Milvus
2. Milvus 官方文档：Architecture Overview
3. Milvus 官方文档：Run Milvus with Docker Compose
4. Milvus 官方文档：Vector Search

本文为"码海寻道"原创技术文章。Milvus、PyMilvus 和部署方式会随版本演进，正式上线前请以目标版本官方文档为准。