Spring AI 生产级实战：向量数据库-平芜编程栈

一、为什么需要向量数据库？

在前面的 Spring AI 生产级实战中，我们已经讲到了 RAG，也就是检索增强生成。

RAG 的核心思路是：

先检索相关资料，再让大模型基于资料回答。

但这里有一个关键问题：

用户提出的问题，通常不是和知识库文档一模一样的文字。
那系统怎么知道哪几段文档和用户问题“语义相关”呢？

例如，用户问：

胸部 CT 报告里，肺结节应该怎么描述？

知识库里可能写的是：

肺结节报告应包括位置、大小、密度、边界、数量及随访建议。

这两句话并不完全相同。

如果用传统数据库的like查询，可能效果并不好。

这时就需要向量数据库。

向量数据库解决的不是“字段值是否相等”，而是：

两个文本在语义上是否相似。

所以，向量数据库是 RAG 系统的核心基础设施之一。

没有向量数据库，RAG 就很难完成高质量的语义检索。

二、什么是向量数据库？

向量数据库，英文是 Vector Database。

它可以存储向量，并支持基于向量的相似度搜索。

简单理解：

文本、图片、音频等内容 ↓ Embedding Model 转换 ↓ 变成一组数字向量 ↓ 存入向量数据库 ↓ 根据相似度检索相关内容

例如一段文本：

右肺上叶可见小结节影。

经过 Embedding 模型处理后，可能会变成类似这样的向量：

[0.12, -0.38, 0.76, 0.04, ...]

向量本身不是给人看的，而是给机器做相似度计算用的。

当用户提问时，系统也会把用户问题转换成向量，然后到向量数据库中查找最相似的文档片段。

这就是语义检索的基本原理。

三、向量数据库和传统数据库有什么区别？

传统数据库更擅长精确查询。

例如：

select*frompatientwherepatient_id='1001';

这类查询要求字段值明确、条件清楚。

而向量数据库更擅长相似查询。

例如：

查找和“胸部 CT 肺结节报告规范”语义最接近的文档片段。

二者的区别可以简单理解为：

类型	查询方式	典型问题
传统数据库	精确匹配、条件过滤	patient_id 等于多少？订单状态是什么？
全文检索	关键词匹配	文档中是否包含“肺结节”？
向量数据库	语义相似度搜索	哪些文档和这个问题语义最相关？

在生产系统中，它们不是替代关系，而是互补关系。

例如医学影像质控系统中：

关系型数据库： 保存患者、检查、报告、任务状态。 全文检索： 根据关键词查找报告模板、术语。 向量数据库： 根据语义检索质控规则、专家经验、相似案例。

所以，不要把向量数据库理解成“替代 MySQL 的数据库”。

它更像是 AI 应用中的语义检索引擎。

四、向量数据库在 RAG 中的位置

一个典型 RAG 系统通常包括两条链路。

1. 文档入库链路

原始文档 ↓ 文档解析 ↓ 文本切分 ↓ Embedding 向量化 ↓ 写入向量数据库

例如：

PDF、Word、网页、规则文档、报告模板 ↓ 切分成多个 Document ↓ 生成向量 ↓ 保存到 Vector Store

2. 用户问答链路

用户问题 ↓ Embedding 向量化 ↓ 向量数据库相似度检索 ↓ 返回相关文档 ↓ 拼接进 Prompt ↓ 大模型生成回答

所以，向量数据库的作用是：

在模型回答之前，先帮模型找到可能有用的资料。

它不是负责生成答案的。

真正生成答案的仍然是 Chat Model。

可以这样分工：

Embedding Model：把文本变成向量。 Vector Store：保存向量并执行相似度检索。 Chat Model：基于检索结果生成回答。

五、Spring AI 中的 VectorStore 抽象

Spring AI 提供了统一的VectorStore接口，用来屏蔽不同向量数据库之间的差异。

从开发者角度看，我们不需要一开始就深入每个数据库的底层 API。

Spring AI 已经抽象出了常用能力：

添加文档； 删除文档； 相似度检索； 按元数据过滤； 获取底层原生客户端。

典型概念如下：

publicinterfaceVectorStoreextendsDocumentWriter,VectorStoreRetriever{voidadd(List<Document>documents);voiddelete(List<String>idList);voiddelete(Filter.ExpressionfilterExpression);List<Document>similaritySearch(SearchRequestrequest);}

这个接口的价值在于：

业务代码可以尽量依赖 Spring AI 的 VectorStore 抽象， 而不是一开始就绑定某一个具体向量数据库。

比如你今天用 PGvector，后续想换成 Milvus、Qdrant 或 Elasticsearch，虽然仍然会涉及配置和数据迁移，但业务层代码可以保持相对稳定。

六、VectorStoreRetriever：只读检索接口

Spring AI 还提供了一个更轻量的只读接口：

publicinterfaceVectorStoreRetriever{List<Document>similaritySearch(SearchRequestrequest);}

它只暴露检索能力，不提供新增和删除能力。

这在生产系统中很有意义。

例如：

普通问答服务只需要检索知识库； 文档管理服务才负责写入和删除知识库； 线上推理服务不应该随便修改向量库。

这符合最小权限原则。

也就是说：

能只读，就不要给写权限。

对于生产系统，建议将“文档入库”和“文档检索”拆开设计。

七、Document：向量库中存的不是单纯字符串

在 Spring AI 中，写入向量数据库的数据通常封装为Document。

一个Document一般包含两部分：

content：文本内容； metadata：元数据。

例如：

Documentdocument=newDocument("肺结节报告应描述位置、大小、密度、边界和随访建议。",Map.of("tenantId","hospital-a","modality","CT","bodyPart","CHEST","ruleType","REPORT_STANDARD","version","1.0"));

这里真正参与语义检索的是文本内容。

而 metadata 用于过滤和管理。

在生产系统中，metadata 非常重要。

因为你不能让所有用户都检索所有文档。

例如医学影像场景中，metadata 可以设计为：

tenantId：租户或医院； department：科室； modality：CT / MR / DR / US； bodyPart：检查部位； ruleType：规则类型； version：规则版本； status：是否启用； source：文档来源； effectiveDate：生效日期。

如果 metadata 设计不好，后续就很难做权限过滤、版本管理和范围控制。

八、SearchRequest：控制怎么检索

SearchRequest是 Spring AI 中控制向量检索行为的重要对象。

常见参数包括：

query：用户查询内容； topK：返回最相似的前 K 条文档； similarityThreshold：相似度阈值； filterExpression：元数据过滤条件。

示例：

SearchRequestrequest=SearchRequest.builder().query("胸部 CT 肺结节报告规范").topK(5).similarityThreshold(0.75).filterExpression("modality == 'CT' && bodyPart == 'CHEST'").build();List<Document>documents=vectorStore.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。

不用每一种都学。

选 2～3 个和自己技术栈最相关的即可。

例如：

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. 不要盲目追求最热门的向量库

选型要回到业务实际。

如果知识库规模不大、团队熟悉 PostgreSQL，PGvector 可能已经足够。

如果向量规模很大、检索性能要求高，可以考虑专业向量数据库。

如果企业已有搜索平台，可以评估 Elasticsearch 或 OpenSearch 的向量能力。

合适比热门更重要。

十五、结合医学影像质控的示例

假设我们正在开发一个医学影像报告质控系统。

可以把以下内容放入向量数据库：

报告书写规范； 胸部 CT 模板； 肺结节描述规则； 性别逻辑质控规则； 检查部位规范； 专家经验总结； 常见错误案例； 随访建议规则。

文档元数据可以设计为：

tenantId：医院或租户； modality：CT / MR / DR； bodyPart：CHEST / HEAD / ABDOMEN； ruleType：REPORT_STANDARD / GENDER_LOGIC / FOLLOW_UP； version：规则版本； status：ENABLED / DISABLED； source：规则来源。

当医生提交一份胸部 CT 报告进行质控时，系统可以这样检索：

query：报告中发现的问题或医生问题； filter：tenantId == 当前医院 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 抽象，再根据自己的技术栈到官方文档中查看对应数据库的配置章节，选择最适合自己系统的向量库。

Spring AI 生产级实战：向量数据库