Metadata Filtering：RAG 检索里的隐形控制面

设计 RAG 元数据过滤体系，覆盖权限、时间、版本、业务线、文档类型和多租户隔离，让检索结果可控。

很多 RAG 问题不是语义检索不准，而是检索范围不对。把全公司所有文档都丢给向量搜索，再指望 reranker 和 LLM 自动选对，是一种高风险设计。

Metadata filtering 是检索系统的控制面。它决定哪些文档有资格被搜索。

常见过滤字段

字段	用途
tenant_id	多租户隔离。
acl_groups	用户权限裁剪。
doc_status	过滤 draft、deprecated、archived。
updated_at	优先新版本或限定时间窗口。
product	按产品线过滤。
doc_type	policy、api、faq、ticket、code。
locale	多语言检索路由。

安全边界

权限过滤应该在检索前或检索时完成，而不是把无权内容放进 prompt 后再要求模型不要输出。

策略	优点	风险
Pre-filter	安全、候选集干净、成本低	过滤太严会漏召回。
Post-filter	召回更宽	可能召回无权内容，排序也会被污染。
Hybrid	关键权限 pre-filter，软条件 post-rerank	实现复杂。

权限、租户、敏感级别应该 pre-filter。业务标签、时间偏好、文档类型可以根据场景做软过滤或加权。

{
  "query": "报销上限是多少？",
  "filters": {
    "tenant_id": "corp",
    "acl_groups": ["finance", "employee"],
    "doc_status": "active"
  }
}

没有 filters trace，bad case 分析会很困难。你不知道是语义没召回，还是被过滤掉了。

RAG 的相关性不只来自向量相似度，也来自检索范围控制。Metadata filtering 设计得好，后面的 rerank 和 generation 才不会在错误候选集上浪费能力。

讨论

有问题、补充案例或不同观点，可以通过 GitHub Discussions 继续交流。