企业RAG项目常因检索范围过宽导致回答混乱，Metadata Filter才是确保精准召回的关键。
核心内容：
1. 企业RAG的核心痛点：检索范围过宽
2. Metadata Filter的作用与常见过滤维度
3. 在Spring AI等框架中的落地实践

很多 Java 开发者第一次做 RAG，最容易把重点放在向量数据库选型上：到底用 Milvus、pgvector、Elasticsearch 还是 Redis？Embedding 模型怎么选？topK 设多少？这些都重要，但在企业知识库项目里，另一个问题往往更早暴露：用户问的是同一个问题，系统却把别的部门、别的租户、过期版本、未发布文档一起召回了。这不是模型能力问题，也不完全是向量数据库问题，而是 RAG 检索链路缺少了一个工程上非常关键的约束：Metadata Filter。

真正的问题不是“搜不到”，而是“搜得太宽”

假设你在公司内部做一个制度问答系统。文档里有：

• 研发部绩效规则

• 销售部提成规则

• 2024 版报销制度

• 2025 版报销制度

• 草稿状态的流程说明

• 已发布的正式制度

用户问：“出差住宿标准是多少？”如果只做向量相似度检索，系统很可能把“相似”的内容全部召回。它不关心文档属于哪个部门，也不关心版本是否有效，更不关心用户有没有权限看。这时即使大模型本身很强，也会陷入一个尴尬局面：上下文里混进了不该出现的材料，回答自然就不稳定。所以企业 RAG 的第一层能力，不应该是“尽可能多召回”，而是“先把不该参与检索的内容挡在外面”。

Metadata Filter 到底过滤什么

RAG 里的 Metadata，通常是文档切块时附带的一组结构化字段。比如：

{ "tenantId": "t_001", "department": "finance", "docType": "policy", "version": "2025", "status": "published", "visibility": "internal"}

Embedding 负责表达文本语义，Metadata 负责表达业务边界。两者的分工很像 Java 后端里的“全文搜索 + SQL 条件”。相似度检索解决“内容像不像”，Metadata Filter 解决“这条数据有没有资格参与搜索”。常见过滤维度包括：

过滤维度	作用
tenantId	多租户隔离，避免串数据
department	部门级知识隔离
docType	只检索制度、FAQ、接口文档等特定类型
status	排除草稿、废弃、待审核内容
version	限定最新版本或指定版本
permission	根据用户权限控制可见范围
effectiveDate	控制制度生效时间

这一步如果缺失，RAG 很容易看起来“能跑”，但一上线就出现权限、口径和可信度问题。

Spring AI 里可以怎么落地

Spring AI 的 VectorStore 抽象支持相似度检索，也支持通过 SearchRequest 传入检索参数。不同向量数据库对过滤表达式的支持会有差异，实际项目要以当前版本官方文档和具体存储实现为准。下面示例只展示关键思路：用户问题进入 RAG 服务后，先根据登录用户构造 metadata 条件，再执行向量检索。

@Servicepublic class KnowledgeSearchService {
 private final VectorStore vectorStore;
 public KnowledgeSearchService(VectorStore vectorStore) { this.vectorStore = vectorStore; }
 public List search(String question, LoginUser user) { String filter = """ tenantId == '%s' && status == 'published' && department in ['%s', 'public'] """.formatted(user.tenantId(), user.department());
 SearchRequest request = SearchRequest.builder() .query(question) .topK(6) .similarityThreshold(0.72) .filterExpression(filter) .build();
 return vectorStore.similaritySearch(request); }}

这个例子里有三个关键点。第一，tenantId 不应该由前端传入，而应该来自后端登录态或鉴权上下文。第二，status == 'published' 这种条件要尽量固化在服务端，不能让用户通过 Prompt 改写。第三，topK 和 similarityThreshold 不是越大越好。过滤之后的候选集更干净，通常可以用更小的上下文换来更稳定的回答。如果你使用 Spring AI 的 Advisor 机制，也可以把过滤条件作为检索增强的一部分挂到 ChatClient 调用链里。但我更建议第一版先把“检索服务”单独封装出来，方便记录日志、调试召回结果、做评估集。

文档入库时就要设计 Metadata

很多 RAG 项目做不好，不是因为查询阶段代码写错，而是文档入库阶段太随意。比如把 PDF 切成 chunk 后，只保存了文本和 embedding，没有保存文档来源、业务类型、发布时间、权限范围。等到后面想做权限隔离时，才发现所有数据都混在一个向量空间里，只能重新清洗和入库。更合理的做法是：文档解析、切块、Embedding、写入向量库时，就把业务字段一起写进去。

Map metadata = Map.of( "tenantId", tenantId, "department", department, "docType", "policy", "status", "published", "version", version, "source", fileName);
Document document = new Document(chunkText, metadata);vectorStore.add(List.of(document));

这里的 Metadata 不要设计得太随意。它不是给人看的备注，而是后续检索、权限、评估、审计都会依赖的索引字段。尤其是多租户系统，tenantId 必须是强约束。不要指望大模型理解“不要回答其他公司的内容”，这种边界应该由后端检索层保证。

一个容易踩的坑：过滤条件不是 Prompt

有些团队会在 Prompt 里写：

你只能根据当前用户有权限的文档回答。

这句话可以作为补充约束，但不能替代 Metadata Filter。原因很简单：如果没有权限的文档已经被召回并塞进上下文，大模型就已经看到了它。此时再要求模型“不要使用”，本质上是在把权限控制交给概率模型。在 Java 后端视角里，这就像接口已经查出了全量订单，再让前端“不要展示别人的订单”。这不是权限控制，而是事故预备。正确顺序应该是：

1. 后端根据用户身份构造过滤条件
2. 向量库只在有权限的数据范围内检索
3. 大模型只看到过滤后的上下文
4. 日志记录本次检索条件和命中文档
5. 对异常回答做追溯和评估

RAG 工程化的关键，不是把所有能力都交给模型，而是把确定性边界留在传统后端系统里。

真实项目里还要补三件事

第一，要给 Metadata 建模规范。哪些字段必填，哪些字段可选，哪些字段允许作为过滤条件，需要在入库前确定下来。否则后面会出现同一个字段有 dept、department、orgName 三种写法。第二，要做召回日志。至少记录 query、filter、topK、相似度阈值、命中文档 ID、命中文档 metadata。没有这些日志，RAG 出问题只能靠猜。第三，要准备一批评估问题。比如“财务部报销标准”“研发部请假流程”“已废弃制度是否还会召回”。每次调整切块、Embedding、过滤条件、topK，都用这批问题跑一遍。如果只做 Demo，RAG 的重点是“能不能回答”。但如果要进企业系统，RAG 的重点会变成“该看的能看到，不该看的看不到；该用的版本被召回，不该用的版本被排除”。Metadata Filter 不显眼，却是 RAG 从玩具走向工程系统时最先应该补上的能力。