RAG 不是先向量检索再回答：Metadata Filter 才是企业知识库的第一道门

不少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解决“这条数据有没有资格参与搜索”。常见过滤维度包括：

这一步如果缺失，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从玩具走向工程系统时最先应该补上的能力。