Spring AI 实战（7）：向量库怎么选？PgVector/Redis/Milvus 横向对比

本篇是 Spring AI 系列第 7 篇。前情：第 6 篇把 RAG 的建库到问答全流程跑通了------文档读取、切分、向量化、入库，问答时检索增强，一套下来知识库就立起来了。但那一篇我们偷了个懒，向量库直接用了 SimpleVectorStore（内存版），只为了让你最快跑通。生产环境它可不够打：一重启数据全没、量一大检索就慢。这篇就来解决最关键的一步------知识到底存哪、怎么选。

先搞懂：向量库在 RAG 里干啥

第 6 篇讲过，RAG 建库时把文档切块、向量化，存进 VectorStore；问答时再把用户问题向量化，去库里"按意思找最像的几块"。所以向量库的本质就是一个 能按向量相似度快速检索的存储。

它要同时干两件事：

1. 存 ：把 Document（文本 + 向量 + 元数据）持久化，别每次重启全没了；
2. 查：给定一个查询向量，返回 topK 个最相似的，且要快。

Spring AI 把这一切抽象成 VectorStore 接口，你换库基本只换 starter 和配置，业务代码不变 。这正是抽象的价值------第 6 篇写的那段 vectorStore.add(chunks) 和 QuestionAnswerAdvisor，换库一行都不用动。

选型的几个硬指标

别一上来比"谁更火"，先看这几个维度：

1. 维度一致性：你用的 Embedding 模型产出多少维向量（如 1536、768、1024），向量库的表/索引必须匹配。换模型 = 重建索引。（这个坑第 6 篇提过，本篇后面会专门讲。）
2. 相似度度量 ：cosine（余弦）/ Euclidean（欧氏）/ inner product（内积）。多数文本场景用 cosine。注意不同库默认度量可能不同。
3. 数据规模：几千条还是几亿条？规模直接决定该不该上 Milvus。
4. 运维成本：你团队是不是已经在用 PG / Redis？复用现成中间件，运维心智和人力都省一大截。
5. 元数据过滤 ：第 6 篇的 filterExpression("docType == 'api'") 要靠向量库的 metadata 能力支撑，选型时确认它支持。

记住一条总原则：先复用你已有的，再谈专门化。 团队已经在用 PostgreSQL 或 Redis，优先它们；只有真的到了千万级、要专业检索时，才上 Milvus。

一、PgVector：最稳的"顺便就用"

PgVector 是 PostgreSQL 的一个扩展，让 PG 直接支持向量列和相似度检索。Spring AI 提供 PgVectorStore。

优点

• 你大概率已经有 PG，零新增组件，DBA 也熟；
• 事务、备份、权限、主从，全套 PG 能力白送；
• 支持 cosine / L2 / inner product，支持 metadata 过滤；
• 几十万到几百万级文档稳稳够用。

缺点

• 超大规模（千万级以上）检索性能不如专用向量库；
• 需要 PG 装扩展（云厂商如阿里云 RDS、AWS RDS 都已内置，自建需 CREATE EXTENSION vector）。

配置示例

spring:
  ai:
    vectorstore:
      pgvector:
        index-type: HNSW        # HNSW 近似索引，查询快
        distance-type: COSINE   # 余弦相似度
        dimensions: 1536        # 必须和你的 embedding 模型维度一致！

@Bean
public VectorStore vectorStore(JdbcTemplate jdbcTemplate, EmbeddingModel embeddingModel) {
    return PgVectorStore.builder(jdbcTemplate, embeddingModel)
            .dimensions(1536)
            .indexType(IndexType.HNSW)
            .distanceType(PgVectorStore.PgDistanceType.COSINE)
            .build();
}

适合谁：绝大多数业务系统、中小规模知识库、想少运维的团队。这是我的默认推荐。

二、Redis：已经在用就顺手接

Redis 通过向量检索能力（Redis 7.4+ 内置 / 早期 Redis Stack）提供向量索引，Spring AI 对应 RedisVectorStore。

优点

• 团队若已用 Redis 做缓存/会话，加分复用好；
• 内存级读写，延迟极低；
• 支持 cosine / L2 / inner product 与 metadata 过滤。

缺点

• 向量全在内存，数据量大时内存成本陡增；
• 持久化依赖 RDB/AOF，重启恢复大量向量不如 PG 自然；
• 版本门槛：需要较新的 Redis（7.4+ 或 Stack），老集群要先升级；
• 超大规模同样不是它的主战场。

配置示例

spring:
  data:
    redis:
      host: localhost
      port: 6379
spring:
  ai:
    vectorstore:
      redis:
        index: product-knowledge   # 索引名
        prefix: doc:               # key 前缀
        dimensions: 1536           # 与 embedding 维度一致

@Bean
public VectorStore vectorStore(RedisConnectionFactory connectionFactory, EmbeddingModel embeddingModel) {
    return RedisVectorStore.builder(connectionFactory, embeddingModel)
            .index("product-knowledge")
            .prefix("doc:")
            .dimensions(1536)
            .build();
}

适合谁：已经重度依赖 Redis、且知识库规模中等的团队。别为了向量库专门引入 Redis。

三、Milvus：真到了海量再来

Milvus 是专业的分布式向量数据库，Spring AI 提供 MilvusVectorStore。

优点

• 为向量而生，千万到十亿级规模性能强悍；
• 支持多种索引（HNSW、IVF、DiskANN 等）和高级检索；
• 分布式架构，可水平扩展；
• 专业的元数据过滤与混合检索。

缺点

• 运维重：独立集群、组件多（etcd、对象存储、MQ），DBA 学习成本高；
• 资源占用大，小项目用它是杀鸡用牛刀；
• 部署复杂度明显高于 PG/Redis。

配置示例

spring:
  ai:
    vectorstore:
      milvus:
        host: 10.0.0.10
        port: 19530
        database-name: default
        collection-name: product_knowledge
        embedding-dimension: 1536
        index-type: HNSW
        metric-type: COSINE

适合谁：知识规模上千万、对检索吞吐/延迟有专业要求、有专职基础设施团队的场景。新手和小项目别碰。

四、对比表一览

维度	PgVector	Redis	Milvus
定位	PG 扩展，通用	内存 KV + 向量	专业向量数据库
运维成本	低（复用 PG）	低（复用 Redis）	高（独立集群）
适合规模	十万~百万级	十万~百万级	千万~十亿级
持久化	强（DB 本身）	依赖 RDB/AOF	强（对象存储）
延迟	中	极低（内存）	低（专业索引）
元数据过滤	支持	支持	强
上手难度	低	低	高
我的建议	首选	已有则复用	海量再上

还有 Chroma、Qdrant、Elasticsearch 的 dense_vector 等可选，Spring AI 大多有对应 starter。但 90% 的 Java 业务场景，PgVector 足够打，Redis 作为复用选项，Milvus 留给海量。

五、一个最容易被坑的死穴：维度不一致

无论选哪个库，第一现场翻车的几乎都是同一件事------建表/建索引的维度和你 Embedding 模型输出的维度对不上。

// 模型输出 1536 维，但你库里建的是 768 维 → 写入直接报错或被截断
PgVectorStore.builder(jdbcTemplate, embeddingModel)
        .dimensions(768)   // ❌ 和 text-embedding-3-small(1536) 不匹配
        .build();

规避三连：

1. 写死维度前，先确认你 embedding 模型的输出维度（OpenAI text-embedding-3-small =1536，text-embedding-ada-002 =1536，bge-large =1024 等）；
2. 维度在 VectorStore 配置和 application.yml 里 只写一处，别两处各写各的；
3. 换 embedding 模型前，先想清楚"旧索引全废、要重建"。把 embedding 模型和向量库当作绑定体管理。

六、选型决策树（直接照着走）

• 团队 已在用 PostgreSQL → PgVectorStore（默认首选，别犹豫）
• 团队 已在用 Redis 且规模中等 → RedisVectorStore（复用）
• 全新项目、规模不大 → 仍选 PgVectorStore（运维最省）
• 知识 上千万条 / 专业检索需求 → MilvusVectorStore
• 只想本地跑通 demo、不谈生产 → SimpleVectorStore（内存，第 6 篇用的那个）

一句话总结：能复用就复用，默认 PgVector，海量再 Milvus，别为了"听起来厉害"提前上重武器。

小结

本篇把 RAG 里"知识存哪、怎么查"的载体------向量库------讲透了：

• 抽象价值 ：VectorStore 接口让换库只换 starter 和配置，业务代码不动。
• 选型总原则：先复用已有的，再谈专门化。团队已在用 PG / Redis 优先它们，只有到千万级才上 Milvus。
• 默认推荐 ：PgVectorStore------复用 PostgreSQL、运维最省、几十万到几百万级够用。
• 复用选项 ：RedisVectorStore------仅当团队已重度依赖 Redis 且规模中等时顺手接，别为向量库专门引入。
• 海量专属 ：MilvusVectorStore------千万到十亿级、有专职基础设施团队再用，小项目杀鸡用牛刀。
• 第一死穴：向量维度必须和 Embedding 模型一致，换模型等于重建索引，把二者当绑定体管理。

一句话带走：能复用就复用，默认 PgVector，海量再 Milvus，别为"听起来厉害"提前上重武器。

---

如果这篇对你有帮助，点个关注 👀 我会持续更新 Spring AI 实战系列，从聊天、RAG 到原理篇篇带完整代码，关注不迷路。

博主：10 年 Java 全栈开发，优质创作者。专注 Spring 源码、架构设计与 Spring AI 实战。

前文回顾：

• Spring AI 实战（1）：Java 开发者如何优雅接入大模型（附完整代码）
• Spring AI 实战（2）：ChatClient+Prompt+记忆三件套，手把手搭 AI 对话（附代码）
• Spring AI 实战（3）：Alibaba 三行配置搞定 MySQL+Redis 记忆存储
• Spring AI 实战（4）：结构化输出让大模型返回 Java 对象（附完整 Demo）
• Spring AI 实战（5）：Tool Calling 让 AI 自动调用你的 Java 方法（附完整代码）
• Spring AI 实战（6）：RAG 从文档切分到向量检索搭建知识库（全流程）