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

本篇是 Spring AI 系列第 7 篇。前情第 6 篇把 RAG 的建库到问答全流程跑通了——文档读取、切分、向量化、入库问答时检索增强一套下来知识库就立起来了。但那一篇我们偷了个懒向量库直接用了SimpleVectorStore内存版只为了让你最快跑通。生产环境它可不够打一重启数据全没、量一大检索就慢。这篇就来解决最关键的一步——知识到底存哪、怎么选。先搞懂向量库在 RAG 里干啥第 6 篇讲过RAG 建库时把文档切块、向量化存进VectorStore问答时再把用户问题向量化去库里按意思找最像的几块。所以向量库的本质就是一个能按向量相似度快速检索的存储。它要同时干两件事存把Document文本 向量 元数据持久化别每次重启全没了查给定一个查询向量返回 topK 个最相似的且要快。Spring AI 把这一切抽象成VectorStore接口你换库基本只换 starter 和配置业务代码不变。这正是抽象的价值——第 6 篇写的那段vectorStore.add(chunks)和QuestionAnswerAdvisor换库一行都不用动。选型的几个硬指标别一上来比谁更火先看这几个维度维度一致性你用的 Embedding 模型产出多少维向量如 1536、768、1024向量库的表/索引必须匹配。换模型 重建索引。这个坑第 6 篇提过本篇后面会专门讲。相似度度量cosine余弦/ Euclidean欧氏/ inner product内积。多数文本场景用cosine。注意不同库默认度量可能不同。数据规模几千条还是几亿条规模直接决定该不该上 Milvus。运维成本你团队是不是已经在用 PG / Redis复用现成中间件运维心智和人力都省一大截。元数据过滤第 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 模型维度一致BeanpublicVectorStorevectorStore(JdbcTemplatejdbcTemplate,EmbeddingModelembeddingModel){returnPgVectorStore.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 自然版本门槛需要较新的 Redis7.4 或 Stack老集群要先升级超大规模同样不是它的主战场。配置示例spring:data:redis:host:localhostport:6379spring:ai:vectorstore:redis:index:product-knowledge# 索引名prefix:doc:# key 前缀dimensions:1536# 与 embedding 维度一致BeanpublicVectorStorevectorStore(RedisConnectionFactoryconnectionFactory,EmbeddingModelembeddingModel){returnRedisVectorStore.builder(connectionFactory,embeddingModel).index(product-knowledge).prefix(doc:).dimensions(1536).build();}适合谁已经重度依赖 Redis、且知识库规模中等的团队。别为了向量库专门引入 Redis。三、Milvus真到了海量再来Milvus 是专业的分布式向量数据库Spring AI 提供MilvusVectorStore。优点为向量而生千万到十亿级规模性能强悍支持多种索引HNSW、IVF、DiskANN 等和高级检索分布式架构可水平扩展专业的元数据过滤与混合检索。缺点运维重独立集群、组件多etcd、对象存储、MQDBA 学习成本高资源占用大小项目用它是杀鸡用牛刀部署复杂度明显高于 PG/Redis。配置示例spring:ai:vectorstore:milvus:host:10.0.0.10port:19530database-name:defaultcollection-name:product_knowledgeembedding-dimension:1536index-type:HNSWmetric-type:COSINE适合谁知识规模上千万、对检索吞吐/延迟有专业要求、有专职基础设施团队的场景。新手和小项目别碰。四、对比表一览维度PgVectorRedisMilvus定位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();规避三连写死维度前先确认你 embedding 模型的输出维度OpenAItext-embedding-3-small1536text-embedding-ada-0021536bge-large1024 等维度在VectorStore配置和application.yml里只写一处别两处各写各的换 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 实战1Java 开发者如何优雅接入大模型附完整代码Spring AI 实战2ChatClientPrompt记忆三件套手把手搭 AI 对话附代码Spring AI 实战3Alibaba 三行配置搞定 MySQLRedis 记忆存储Spring AI 实战4结构化输出让大模型返回 Java 对象附完整 DemoSpring AI 实战5Tool Calling 让 AI 自动调用你的 Java 方法附完整代码Spring AI 实战6RAG 从文档切分到向量检索搭建知识库全流程