RAG 元数据过滤模式清单：在检索前收窄候选文档
向量检索很强，但全库乱搜会把过期制度与他国产品说明一并召回。元数据过滤是在相似度计算前先按字段收窄候选集。
常见过滤模式
- 时间窗：只检索近 N 个月，或显式允许历史版
- 产品线/租户：多产品知识库必备
- 权限标签：用户不可见文档永不进候选
- 类型：手册 / FAQ / 工单分开
- 语言与地区：避免串语言答案
设计步骤
- 入库强制写元数据，缺字段拒收或进隔离区
- 查询侧抽取过滤意图或表单选择
- 先 filter 再 top-k；空结果要有放宽顺序
- 回答里展示引用元数据便于抽查
查询改写提示词
从用户问题提取检索过滤字段（不确定则 null）：
product / doc_type / time_range / region
只输出 JSON，不要回答问题。
用户问题：…
常见坑
- 过滤过严导致零命中：准备放宽顺序
- 元数据脏比调 embedding 更能毁系统
- 权限过滤必须在服务端强制，不能只靠提示词
与分块、重排的关系
元数据过滤解决的是「搜哪儿」；分块解决「切多细」；重排解决「前几名是否真相关」。三者不要互相替代。很多「检索不准」其实是过滤条件缺失，而不是 embedding 不够新。
权限场景特别提醒
若文档带保密级别，过滤必须在服务端强制执行。把「请只使用我有权看的文档」写进提示词，不能当作安全控制。审计时要能证明某次回答的候选集未越权。
落地检查
- 入库校验：缺 product 或 ACL 标签则拒绝
- 查询侧：无法解析过滤时，是拒绝回答还是全库降级？要产品决策
- 监控：过滤后零命中比例、人工点踩理由
观测指标建议
关注过滤后零命中率、放宽后命中率、以及用户点踩中「过期内容」占比。若过期内容仍高，优先查时间元数据是否写入成功，而不是先换大模型。元数据治理是 RAG 的脏活，却决定上限。
小结
元数据过滤是检索系统的座椅安全带：平时无感，出事时救命。投入在入库校验与权限模型上的时间，往往比换更大嵌入模型更划算。把它写进设计评审清单，避免上线后才补。
多租户场景下，自动化测试应包含「用户 A 的查询不得命中租户 B 文档」的硬断言。
补充实践
对政策类文档，除了时间窗，还可加「效力状态」字段：现行/废止/征求意见。废止文档默认不进候选，除非用户明确要历史。