## 01、痛点

我是老李，最近在给一家 SaaS 平台做企业知识库问答。上线第一个月，测试组报了个问题：客户 A 问“我们的续约价格是多少”，系统返回了客户 B 的折扣条款。检查一圈，模型没有编造，向量检索确实召回了客户 B 的合同片段。我们当时只做了一层防护：在给模型看的指令里写“不要引用其他企业的数据”。但每次向量相似度先把 B 的片段捞出来，再指望模型自己判断“这段不属于 A”，效果非常不可靠。上下文里已经混入他人数据，生成阶段就很难做到绝对封闭。更糟的是，客户 B 的敏感条款已经进入了模型输入，泄露发生在答案生成之前。

这个问题不是某一个模型不够聪明，而是我们把权限边界放错了阶段。企业级 RAG 场景里，多租户隔离不能靠最后一层自然语言约束。尤其当文档量大、租户多、项目间数据交叉时，向量检索返回的 TopK 里只要混进一条其他租户的内容，后续再怎么做都只是补救。Spring AI 给主流 Vector Database 提供了统一的 VectorStore 抽象，它最大的价值不是少写几行适配代码，而是让 metadata 过滤成为检索入口的强制动作。现在正是要把账算清楚的时候：多租户知识库的第一道隔离，必须发生在 Retrieval，而不是 Generation。

## 02、是什么

Spring AI 把主流向量数据库的写入、删除和相似性检索抽象成一个 VectorStore 接口。官方项目页列出的支持范围包括 PGVector、Redis、Qdrant、Milvus、Pinecone、Weaviate、MongoDB Atlas、Neo4j 等。无论底层是 PostgreSQL 的扩展插件，还是独立的向量服务，调用方只需要面对一组稳定方法：add、delete、similaritySearch，以及元数据过滤表达式。

核心接口可以简化成下面这个形态：

```text
VectorStore
  add(List<Document> documents)
  delete(String filterExpression)
  similaritySearch(SearchRequest request)
```

Document 是文本内容与元数据的包装。元数据可以携带 tenant_id、project_id、doc_type、acl、owner、created_at 等业务字段。SearchRequest 除了问题向量和 topK，还可以设置 filterExpression。filterExpression 并不是每个数据库自己私有的方言，Spring AI 做了一层统一的过滤表达式抽象，底层再翻译成 PGVector 的 WHERE 条件、Redis 的 RediSearch 过滤条件等。

另一个需要分清的职责是 VectorStore 与 VectorStoreRetriever。VectorStore 是读写入口，负责把向量灌进去、按条件删除、按相似度查询。VectorStoreRetriever 是只读检索器，它从配置中拿到一个 VectorStore，对外暴露通用的 retrieve 能力，供后续检索增强链路使用。简单说：VectorStore 管理数据和检索，VectorStoreRetriever 负责把检索动作接入上下文拼装，自己不负责写入、删除。把写入和读取分开，企业系统才能在权限控制、流量治理和可观测性上做得更干净。

## 03、为什么

为什么要用统一抽象？最直接的原因是向量数据库太分散。PGVector 适合已经在用 PostgreSQL 的团队，Redis Vector 适合对实时性要求高、已经用 Redis 做缓存的团队，Qdrant、Milvus、Weaviate 也有各自的优势。以前每接一个库，就要写一套 add、query、delete 的胶水代码，团队维护成本高，切换成本更高。Spring AI 的 VectorStore 抽象把这些差异收敛到一个入口，开发人员关注的是文档、元数据和过滤表达式，而不是某个 SDK 的分页参数或连接池配置。

但统一 API 只是表层。更深一层的原因是：企业 RAG 的隔离问题，必须由检索层解决。多租户系统里，数据能不能被看见，本质上是一个权限判定。权限判定应该发生在数据被读取之前，而不是数据被读取之后。向量检索如果不带 tenant_id、project_id 等过滤条件，本质上等于先全库扫描相似片段，再让模型判断哪些能看。数据库和索引本来可以精确执行等值过滤，却把最关键的边界交给了最不可控的自然语言生成阶段。

从工程角度看，检索层过滤有三个不可替代的优势。第一，可验证。过滤条件写进查询请求，每次检索都能在日志里看到；模型输出则难以证明它是否遵守了指令。第二，可审计。PGVector 的 WHERE、Redis 的索引过滤规则可以被数据库执行计划确认。第三，可回滚。过滤条件写错可以立即修复并重跑；生成阶段指令失效时，只能等模型下次“尽量注意”。因此，多租户 RAG 的隔离应该前置到 Retrieval，在向量相似度计算之前或同时完成租户过滤，确保候选集合本身不包含无权访问的内容。

## 04、架构

一个典型的企业知识库检索架构可以分成三层：写入层、检索层、生成层。写入层把文档切分、向量化后，连同元数据一起写入 VectorStore。检索层接收问题，先根据登录态得到租户和项目范围，再生成过滤表达式，最后请求 TopK 相似度搜索。生成层只拿到检索层已经过滤好的片段，负责组织答案。

关键设计在检索层。请求不能由前端直接传 tenant_id，必须由服务端从当前登录态中解析。比如当前用户属于 tenant-01、有权访问 project-42，那么过滤表达式固定为：

```text
tenant_id == 'tenant-01' && project_id == 'project-42'
```

如果用户有权访问多个项目，可以使用 IN 表达式：

```text
tenant_id == 'tenant-01' && project_id in ['project-42', 'project-43']
```

过滤表达式会先于或伴随向量相似度计算执行。以 PGVector 为例，底层 SQL 可能是：

```sql
SELECT id, content, metadata
FROM vector_document
WHERE tenant_id = 'tenant-01'
  AND project_id = 'project-42'
ORDER BY embedding <=> :question_embedding
LIMIT 5;
```

这一步完成后，向量相似度只计算过滤后的行。其他租户的文档根本不进入候选集。Redis Vector 方案同理，写入时把 tenant_id、project_id 放进元数据索引，查询时通过 RediSearch 过滤规则限制结果范围。

对比一下两种做法。只靠指令隔离：向量检索先返回全库 TopK，再让模型判断哪些能看，模型可能看错、忽略或被诱导。检索层过滤：数据库先过滤租户和项目，再计算相似度，模型看到的是已经干净的上下文。二者不是优化幅度的差别，而是边界位置的差别。前者把安全边界放在最不可控的位置，后者把安全边界放在最可控制的位置。

## 05、实战

这一节以 PGVector 为主，给一个可运行的知识库最小闭环。假设我们有两个租户：tenant-01 和 tenant-02，各自有一个项目。目标是把合同文档写入 PGVector，然后验证带 tenant_id/project_id 过滤的 TopK 检索。

第一步，引入依赖并配置连接。Spring Boot 工程中加入 PGVector Store 的启动器，然后在 application.yml 里配置：

```yaml
spring:
  ai:
    vectorstore:
      pgvector:
        host: 127.0.0.1
        port: 5432
        database: rag_demo
        username: postgres
        password: 123456
        table-name: vector_document
        dimensions: 1536
```

这里 dimensions 要和嵌入模型输出维度一致。实际项目中可以用 768、1024、1536 等，取决于所选模型。

第二步，注入 VectorStore，写入两个租户的文档。写入时必须显式填充元数据：

```text
Document docA = new Document(
    “甲方与乙方约定，续约价格为每年十二万元，自次年一月一日起生效。”,
    Map.of(“tenant_id”, “tenant-01”, “project_id”, “project-42”, “doc_type”, “contract”)
);
Document docB = new Document(
    “甲方与乙方约定，续约价格为每年八万元，含两次免费现场支持。”,
    Map.of(“tenant_id”, “tenant-02”, “project_id”, “project-88”, “doc_type”, “contract”)
);
vectorStore.add(List.of(docA, docB));
```

这里用了两个相似但价格不同的合同片段。相似度搜索很容易把 B 召回给 A，如果不过滤，很难靠模型判断区分。

第三步，做一次不带过滤和带过滤的对比。先不带过滤条件：

```text
SearchRequest noFilter = SearchRequest.query(“续约价格是多少”)
    .withTopK(3);
List<Document> noFilterResult = vectorStore.similaritySearch(noFilter);
```

因为两个合同片段非常相似，结果里很可能同时包含 tenant-01 和 tenant-02。再看带过滤条件：

```text
SearchRequest filtered = SearchRequest.query(“续约价格是多少”)
    .withTopK(3)
    .withFilterExpression(“tenant_id == 'tenant-01' && project_id == 'project-42'”);
List<Document> filteredResult = vectorStore.similaritySearch(filtered);
```

这次结果里只会有 tenant-01 的文档，租户 B 的文档在 SQL 层就被过滤掉，不会进入相似度计算和上下文组装。

第四步，处理删除。企业文档会更新或失效，删除也要带过滤条件，避免误删：

```text
vectorStore.delete(“tenant_id == 'tenant-01' && doc_type == 'contract'”);
```

删除同样不能只凭文档 ID，因为 ID 不代表权限范围。服务端根据租户范围生成删除表达式，是维护数据一致性的基本操作。

如果想用 Redis Vector，整体思路一样。写入时把 tenant_id、project_id 放进文档元数据，启用 RediSearch 索引。查询时使用相同的过滤表达式，例如：

```text
tenant_id == 'tenant-01' && project_id == 'project-42'
```

Redis 方案在数据量不大但要求低延迟的场景下很合适。要特别注意的是，Redis 的过滤能力依赖索引创建是否覆盖了这些元数据字段，否则过滤可能退化为客户端过滤，隔离效果会打折扣。无论选 PGVector 还是 Redis，核心不是数据库本身，而是过滤条件是否真正下推到存储层执行。

## 06、洞见

多租户 RAG 有一个常见误解：只要在给模型的指令里写“不要看其他企业数据”，模型就会乖乖遵守。实际效果是，模型有时会遵守，有时不会。模型不是权限系统，它不执行访问控制，也不维护租户边界。它做的是根据输入预测最可能的输出。当上下文里同时出现 A、B 两家公司的相似条款时，模型可能为了语义完整而混用 B 的内容；即使用户问题没有要求 B，它也可能在推理时参考 B 的片段。这个风险在生成之前就已经发生了：B 的数据已经进入模型输入，已经构成跨租户读取。

指令约束还有另一个问题：它可以被覆盖。如果检索结果中混入其他租户的文档，模型很难判断哪一条是当前租户的，尤其当文档中没有明显租户标识时。即使有标识，长上下文中模型也可能忽略。更现实的是，租户隔离应该满足“无法读取”而不是“读到但装作没看到”。前者是权限边界，后者是行为建议。二者在安全等级上有本质区别。

所以企业 RAG 的第一道隔离应该发生在 Retrieval，而不是 Generation。检索层可以用数据库索引、过滤表达式、ACL 把无权访问的文档排除在候选集之外。模型最终看到的上下文，从源头就是属于当前租户和项目的。这样生成阶段可以专注于理解与回答，不需要承担它本不该承担的访问控制责任。换句话说，元数据过滤不是优化搜索精度的技巧，而是企业知识库的权限底座。

## 07、行动

如果现在要给企业知识检索做改造，建议按下面顺序推进。

先设计 metadata 和 ACL。至少要包含 tenant_id、project_id、doc_type、acl、owner、created_at。tenant_id 用于租户隔离，project_id 用于项目级隔离，acl 可扩展为更细粒度的白名单。比如一份合同只允许 tenant-01 下的财务角色访问，acl 可以写成 role:finance 或 group:finance，查询时按当前用户角色生成过滤。不要等文档已经入库再补元数据，补录成本高，且历史数据容易缺失。

再强制服务端生成过滤条件。登录态是唯一可信来源，前端传来的 tenant_id、project_id 一律不可信。即使前端被改包，过滤条件仍然由服务端根据会话生成。比如当前用户属于 tenant-01，有权访问 project-42 和 project-43，查询时就生成 tenant_id == 'tenant-01' && project_id in ['project-42', 'project-43']。

第三，把过滤条件下推到数据库。PGVector 使用 WHERE 子句，Redis 使用 RediSearch 索引过滤。不要先把候选都查回来再在内存里过滤，那样隔离效果只是假象。可以用执行计划或慢日志确认过滤条件确实生效。

第四，监控检索日志。记录每次检索的过滤表达式、返回条数、耗时。重点监控是否出现空过滤表达式或 tenant_id 缺失的查询。空过滤等于全库搜索，应该直接阻断或告警。对于高安全场景，可以在服务端加一个断言：检索请求必须包含 tenant_id，否则拒绝执行。

第五，写好测试用例。准备两个租户的相似文档，验证不带过滤时确实会串，带过滤时结果只包含当前租户。再加一个权限变更测试：文档从 project-42 移动到 project-43 后，旧过滤条件查不到，新过滤条件查得到，删除操作也只影响目标租户。

最后，才是在生成阶段增加兜底提示。注意，它只是兜底，不是主防线。即使模型偶尔出错，只要检索层已经过滤干净，最坏情况也只会是回答不完整，而不是跨租户泄露。顺序不能反过来：先设计 metadata 和 ACL，再谈生成阶段的提示语。

## 08、小结

Spring AI 的统一 VectorStore 抽象，表面看是降低了向量数据库接入成本，实际更大的价值在于把 metadata filtering 放到了检索主路径上。企业多租户 RAG 的难点不是模型不会答，而是模型看到的数据范围没有被可靠控制。PGVector 和 Redis 都具备把过滤条件下推到存储层的能力，关键是写入时补齐元数据，查询时由服务端强制生成过滤表达式。

多租户隔离的第一道防线必须是 Retrieval。检索结果干净了，生成阶段才能安全地发挥语言能力。如果把隔离责任推给模型，等于让一个没有权限概念的组件做访问控制，既不可验证也不可审计。先设计 metadata 和 ACL，再谈提示语，这是企业知识库问答少踩坑的基本顺序。

## 09、链接与概念说明

VectorStore：Spring AI 中对向量数据库读写与检索操作的统一抽象，提供 add、delete、similaritySearch 等核心方法。

VectorStoreRetriever：只读检索器，基于 VectorStore 提供检索能力，负责把查询结果交给后续上下文拼装，不承担写入和删除职责。

Metadata Filtering：元数据过滤，根据文档附带的结构化字段限制检索范围。典型字段包括 tenant_id、project_id、doc_type、acl 等。

TopK：相似度检索返回的最近邻数量。K 越大，上下文越丰富，但噪声和延迟也越高。

PGVector：PostgreSQL 的向量扩展，适合已有 PostgreSQL 基础设施的团队，支持 SQL WHERE 过滤与向量相似度排序。

Redis Vector：基于 Redis 的向量检索能力，通常结合 RediSearch 使用，适合低延迟、高并发场景。

多租户 RAG：多个租户共享同一套检索增强生成系统，但每个租户只能检索和看到自己的数据。多租户隔离是企业场景的前提条件。

ACL：访问控制列表，用于描述哪些用户、角色或分组可以访问某一份文档。ACL 应写入文档元数据，并在检索时作为过滤条件执行。

参考：Spring AI 官方 Vector Store 相关文档，以及 PGVector、Redis 官方文档。

我是老李，最近在给一家 SaaS 平台做企业知识库问答。上线第一个月，测试组报了个问题：客户 A 问“我们的续约价格是多少”，系统返回了客户 B 的折扣条款。检查一圈，模型没有编造，向量检索确实召回了客户 B 的合同片段。我们当时只做了一层防护：在给模型看的指令里写“不要引用其他企业的数据”。但每次向量相似度先把 B 的片段捞出来，再指望模型自己判断“这段不属于 A”，效果非常不可靠。上下文里已经混入他人数据，生成阶段就很难做到绝对封闭。更糟的是，客户 B 的敏感条款已经进入了模型输入，泄露发生在答案生成之前。

《Spring AI 2.0实战》第7招 VectorStore别乱选

以 PGVector 和 Redis 为例，详解 Spring AI VectorStore 的写入、删除、TopK 检索与元数据过滤，并回答为什么多租户隔离不

架构师

人工智能

后端

开发工具

多租户RAG第一道隔离必须在Retrieval阶段执行元数据过滤，而非依赖Generation指令约束。通过SpringAI统一VectorStore抽象，强制tenant_id/project_id条件下推到PGVector或Redis存储层，确保无权限文档不进入候选集，实现可验证、可审计的权限隔离。

访问控制列表

数据一致性

向量数据库

代码解释

数据索引

PostgreSQL

数据库

Redis

SaaS

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Spring AI 2.0实战》第7招 VectorStore别乱选-腾讯云开发者社区-腾讯云

《Spring AI 2.0实战》第7招 VectorStore别乱选

《Spring AI 2.0实战》第7招 VectorStore别乱选

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐