一、为什么需要向量数据库在前面的 Spring AI 生产级实战中我们已经讲到了 RAG也就是检索增强生成。RAG 的核心思路是先检索相关资料再让大模型基于资料回答。但这里有一个关键问题用户提出的问题通常不是和知识库文档一模一样的文字。那系统怎么知道哪几段文档和用户问题“语义相关”呢例如用户问胸部 CT 报告里肺结节应该怎么描述知识库里可能写的是肺结节报告应包括位置、大小、密度、边界、数量及随访建议。这两句话并不完全相同。如果用传统数据库的like查询可能效果并不好。这时就需要向量数据库。向量数据库解决的不是“字段值是否相等”而是两个文本在语义上是否相似。所以向量数据库是 RAG 系统的核心基础设施之一。没有向量数据库RAG 就很难完成高质量的语义检索。二、什么是向量数据库向量数据库英文是 Vector Database。它可以存储向量并支持基于向量的相似度搜索。简单理解文本、图片、音频等内容 ↓ Embedding Model 转换 ↓ 变成一组数字向量 ↓ 存入向量数据库 ↓ 根据相似度检索相关内容例如一段文本右肺上叶可见小结节影。经过 Embedding 模型处理后可能会变成类似这样的向量[0.12, -0.38, 0.76, 0.04, ...]向量本身不是给人看的而是给机器做相似度计算用的。当用户提问时系统也会把用户问题转换成向量然后到向量数据库中查找最相似的文档片段。这就是语义检索的基本原理。三、向量数据库和传统数据库有什么区别传统数据库更擅长精确查询。例如select*frompatientwherepatient_id1001;这类查询要求字段值明确、条件清楚。而向量数据库更擅长相似查询。例如查找和“胸部 CT 肺结节报告规范”语义最接近的文档片段。二者的区别可以简单理解为类型查询方式典型问题传统数据库精确匹配、条件过滤patient_id 等于多少订单状态是什么全文检索关键词匹配文档中是否包含“肺结节”向量数据库语义相似度搜索哪些文档和这个问题语义最相关在生产系统中它们不是替代关系而是互补关系。例如医学影像质控系统中关系型数据库 保存患者、检查、报告、任务状态。 全文检索 根据关键词查找报告模板、术语。 向量数据库 根据语义检索质控规则、专家经验、相似案例。所以不要把向量数据库理解成“替代 MySQL 的数据库”。它更像是 AI 应用中的语义检索引擎。四、向量数据库在 RAG 中的位置一个典型 RAG 系统通常包括两条链路。1. 文档入库链路原始文档 ↓ 文档解析 ↓ 文本切分 ↓ Embedding 向量化 ↓ 写入向量数据库例如PDF、Word、网页、规则文档、报告模板 ↓ 切分成多个 Document ↓ 生成向量 ↓ 保存到 Vector Store2. 用户问答链路用户问题 ↓ Embedding 向量化 ↓ 向量数据库相似度检索 ↓ 返回相关文档 ↓ 拼接进 Prompt ↓ 大模型生成回答所以向量数据库的作用是在模型回答之前先帮模型找到可能有用的资料。它不是负责生成答案的。真正生成答案的仍然是 Chat Model。可以这样分工Embedding Model把文本变成向量。 Vector Store保存向量并执行相似度检索。 Chat Model基于检索结果生成回答。五、Spring AI 中的 VectorStore 抽象Spring AI 提供了统一的VectorStore接口用来屏蔽不同向量数据库之间的差异。从开发者角度看我们不需要一开始就深入每个数据库的底层 API。Spring AI 已经抽象出了常用能力添加文档 删除文档 相似度检索 按元数据过滤 获取底层原生客户端。典型概念如下publicinterfaceVectorStoreextendsDocumentWriter,VectorStoreRetriever{voidadd(ListDocumentdocuments);voiddelete(ListStringidList);voiddelete(Filter.ExpressionfilterExpression);ListDocumentsimilaritySearch(SearchRequestrequest);}这个接口的价值在于业务代码可以尽量依赖 Spring AI 的 VectorStore 抽象 而不是一开始就绑定某一个具体向量数据库。比如你今天用 PGvector后续想换成 Milvus、Qdrant 或 Elasticsearch虽然仍然会涉及配置和数据迁移但业务层代码可以保持相对稳定。六、VectorStoreRetriever只读检索接口Spring AI 还提供了一个更轻量的只读接口publicinterfaceVectorStoreRetriever{ListDocumentsimilaritySearch(SearchRequestrequest);}它只暴露检索能力不提供新增和删除能力。这在生产系统中很有意义。例如普通问答服务只需要检索知识库 文档管理服务才负责写入和删除知识库 线上推理服务不应该随便修改向量库。这符合最小权限原则。也就是说能只读就不要给写权限。对于生产系统建议将“文档入库”和“文档检索”拆开设计。七、Document向量库中存的不是单纯字符串在 Spring AI 中写入向量数据库的数据通常封装为Document。一个Document一般包含两部分content文本内容 metadata元数据。例如DocumentdocumentnewDocument(肺结节报告应描述位置、大小、密度、边界和随访建议。,Map.of(tenantId,hospital-a,modality,CT,bodyPart,CHEST,ruleType,REPORT_STANDARD,version,1.0));这里真正参与语义检索的是文本内容。而 metadata 用于过滤和管理。在生产系统中metadata 非常重要。因为你不能让所有用户都检索所有文档。例如医学影像场景中metadata 可以设计为tenantId租户或医院 department科室 modalityCT / MR / DR / US bodyPart检查部位 ruleType规则类型 version规则版本 status是否启用 source文档来源 effectiveDate生效日期。如果 metadata 设计不好后续就很难做权限过滤、版本管理和范围控制。八、SearchRequest控制怎么检索SearchRequest是 Spring AI 中控制向量检索行为的重要对象。常见参数包括query用户查询内容 topK返回最相似的前 K 条文档 similarityThreshold相似度阈值 filterExpression元数据过滤条件。示例SearchRequestrequestSearchRequest.builder().query(胸部 CT 肺结节报告规范).topK(5).similarityThreshold(0.75).filterExpression(modality CT bodyPart CHEST).build();ListDocumentdocumentsvectorStore.similaritySearch(request);这段代码的含义是检索与“胸部 CT 肺结节报告规范”语义相关的文档 最多返回 5 条 相似度需要达到一定阈值 并且只检索 CT、胸部相关文档。生产系统中topK和similarityThreshold需要反复调试。不是返回越多越好。返回太少模型可能缺少上下文返回太多模型可能被噪声干扰也会增加 Token 成本。九、元数据过滤生产级 RAG 的关键能力如果只是做一个 Demo可以把所有文档都放进向量库然后直接检索。但生产系统不能这样做。原因很简单不同用户有不同权限 不同租户有不同数据 不同业务场景需要不同知识 不同版本规则不能混用 禁用或过期文档不能被检索出来。所以元数据过滤是生产级 RAG 的关键能力。例如tenantId 当前租户 status ENABLED modality CT bodyPart CHEST ruleType REPORT_QC对于医学影像报告质控可以这样理解用户正在分析胸部 CT 报告 就不应该检索到腹部 MR 的报告规则 A 医院的用户 也不应该检索到 B 医院的私有规则。这就是向量数据库和业务权限系统结合的地方。十、向量数据库本身不生成向量这是一个常见误区。很多人以为向量数据库会自动理解文本。实际上向量数据库主要负责保存向量 建立索引 执行相似度搜索 返回相似文档。生成向量的是 Embedding Model。也就是说Embedding Model 负责“理解文本并转成向量” Vector Store 负责“存储向量并查相似内容”。所以在做向量数据库选型时不能只看数据库还要一起考虑 Embedding 模型。尤其要注意入库时使用的 Embedding 模型 检索时使用的 Embedding 模型 向量维度是否一致 更换 Embedding 模型后是否需要重建索引。一般来说文档入库和用户检索应使用同一个 Embedding 模型。如果更换模型通常需要重新向量化和重建索引。十一、向量数据库适合解决什么问题向量数据库适合语义相似度相关的任务。典型场景包括知识库问答 RAG 检索 相似文档搜索 相似病例检索 相似商品推荐 文本去重 语义聚类 智能客服知识召回 报告模板匹配 专家经验规则召回。例如医学影像场景中可以用于根据报告内容检索相关质控规则 根据影像描述检索相似病例 根据医生问题检索报告模板 根据错误描述检索专家经验 根据报告结论检索历史相似报告。但它不适合所有问题。例如根据 reportId 查询报告 根据 patientId 查询患者 统计某天检查数量 更新质控任务状态。这些仍然应该交给传统数据库或业务接口处理。十二、如何选择合适的向量数据库这篇文章不逐个展开每一种数据库。因为 Spring AI 官方文档已经提供了不同 Vector Store 的配置入口实际项目应根据团队技术栈和业务要求去查对应章节。但在选型时可以从以下几个维度思考。1. 现有技术栈如果团队已经大量使用 PostgreSQL可以优先了解 PGvector。如果团队已经有 Elasticsearch 或 OpenSearch可以了解它们的向量检索能力。如果团队已经使用 MongoDB Atlas可以了解 MongoDB Atlas Vector Store。选型不一定追求最“先进”而要考虑团队能不能稳定运维。2. 数据规模小规模知识库和大规模向量检索对数据库要求完全不同。例如几千条文档片段 几十万条文档片段 几千万条向量 多租户高并发检索。数据规模越大越要关注索引性能、扩展能力、分片能力、查询延迟和运维复杂度。3. 元数据过滤能力生产级 RAG 通常离不开元数据过滤。要重点确认是否支持 metadata filter 过滤性能如何 是否支持复杂条件 是否支持租户隔离 是否支持版本管理 是否支持按业务字段删除或更新。如果向量库的过滤能力不足后续权限控制和业务范围控制会很麻烦。4. 运维成本向量数据库不是只要能跑起来就行。还要考虑部署方式 备份恢复 监控告警 扩容能力 数据迁移 版本升级 故障处理 团队熟悉程度。对于企业项目来说运维成本往往比单次性能测试更重要。5. 与 Spring AI 的集成程度Spring AI 已经支持多种 Vector Store 实现。实际使用时建议直接查看官方文档中对应数据库的章节重点关注starter 依赖 application.yml 配置 是否需要初始化 schema 是否支持自动配置 是否支持 metadata filter 是否支持删除 是否支持批量写入 是否支持 Testcontainers 测试。不要只看数据库官网也要看 Spring AI 对该数据库的适配成熟度。十三、读者应该去官网哪里看对于本文读者来说建议按这个顺序查看官方文档。1. 先看 Vector Databases 总览先理解VectorStore 是什么 VectorStoreRetriever 是什么 SearchRequest 怎么用 Document 和 metadata 怎么设计 topK 和 similarityThreshold 有什么作用 filterExpression 如何使用。这部分是所有向量库共通的基础。2. 再看具体 Vector Store 实现Spring AI 官方文档中列出了多个实现。读者可以根据自己的环境重点查看PGvector Milvus Qdrant Elasticsearch OpenSearch Redis MongoDB Atlas Neo4j Cassandra Azure Vector Search Pinecone Weaviate Chroma。不用每一种都学。选 23 个和自己技术栈最相关的即可。例如Spring Boot PostgreSQL 项目优先看 PGvector 已有 Elasticsearch优先看 Elasticsearch Vector Store 需要专业向量检索服务可以看 Milvus、Qdrant 云上托管场景可以看 Pinecone、Azure、MongoDB Atlas 等。3. 最后结合 RAG 文档一起看向量数据库不是孤立使用的。它通常服务于 RAG。所以建议同时阅读Retrieval Augmented Generation ETL Pipeline Embedding Models Vector Databases ChatClient Advisor。这样才能把完整流程串起来文档怎么入库 文本怎么切分 Embedding 怎么生成 向量怎么保存 问题怎么检索 上下文怎么拼接 模型怎么回答。十四、生产级使用注意事项1. 文档切分比数据库选型更重要很多 RAG 效果不好不是向量库问题而是文档切分问题。例如切分太大一个片段里包含太多无关内容 切分太小上下文不完整 切分没有业务语义规则被切碎模型难以理解。医学影像质控规则最好按质控项、检查部位、规则类型切分而不是机械按字数切分。2. metadata 要提前设计不要等知识库上线后才发现无法按租户、科室、文档类型过滤。建议一开始就设计好tenantId businessType documentType source version status createdAt updatedAt permissionScope。metadata 是后续权限控制、版本管理和审计追踪的基础。3. 向量库不是事实库向量数据库适合语义检索不适合作为权威业务数据库。例如患者姓名 报告状态 订单金额 权限角色 审核状态。这些数据应该从业务数据库或业务接口获取。向量库中可以保存用于检索的知识片段但不要把它当作唯一事实来源。4. 检索结果必须可追溯生产级 RAG 最好保存用户问题 检索语句 检索到的文档 ID 文档版本 相似度分数 metadata 过滤条件 最终回答 用户反馈。这样当回答出错时才能追踪是知识库内容错了 是检索结果错了 是模型理解错了 还是 Prompt 约束不够5. 不要盲目追求最热门的向量库选型要回到业务实际。如果知识库规模不大、团队熟悉 PostgreSQLPGvector 可能已经足够。如果向量规模很大、检索性能要求高可以考虑专业向量数据库。如果企业已有搜索平台可以评估 Elasticsearch 或 OpenSearch 的向量能力。合适比热门更重要。十五、结合医学影像质控的示例假设我们正在开发一个医学影像报告质控系统。可以把以下内容放入向量数据库报告书写规范 胸部 CT 模板 肺结节描述规则 性别逻辑质控规则 检查部位规范 专家经验总结 常见错误案例 随访建议规则。文档元数据可以设计为tenantId医院或租户 modalityCT / MR / DR bodyPartCHEST / HEAD / ABDOMEN ruleTypeREPORT_STANDARD / GENDER_LOGIC / FOLLOW_UP version规则版本 statusENABLED / DISABLED source规则来源。当医生提交一份胸部 CT 报告进行质控时系统可以这样检索query报告中发现的问题或医生问题 filtertenantId 当前医院 AND modality CT AND bodyPart CHEST AND status ENABLED topK返回最相关的几条规则 threshold过滤掉相似度太低的内容。然后将检索到的规则交给 Chat Model 分析报告。最终返回结构化质控结果是否通过 风险等级 命中的规则 问题描述 修改建议 是否需要人工复核。这个流程中向量数据库不是直接给出质控结论而是帮助模型找到依据。十六、总结向量数据库是 Spring AI 生产级应用中的重要基础组件尤其在 RAG 场景中非常关键。它解决的是如何根据语义检索相关知识 如何把企业私有知识接入大模型 如何让模型基于资料回答问题 如何实现相似文档、相似规则、相似案例检索。在 Spring AI 中开发者可以通过VectorStore和VectorStoreRetriever统一使用不同向量数据库通过SearchRequest控制检索条件通过 metadata filter 实现业务范围控制。但要注意向量数据库不是万能数据库 Embedding Model 才负责生成向量 metadata 设计决定生产可控性 文档切分决定检索质量 具体数据库选型要结合业务规模、技术栈和运维能力。本文不展开每一种向量数据库的配置细节。实际项目中建议读者先理解 Spring AI 的 Vector Store 抽象再根据自己的技术栈到官方文档中查看对应数据库的配置章节选择最适合自己系统的向量库。