核心要点
给每个 chunk 打元数据：来源、时间、作者、类别、权限等
Pre-filter：先按结构化条件筛掉不符合的片段，再在子集内做向量检索
Post-filter：先向量检索再按元数据过滤，实现简单但可能召回不足
支撑「最新 / 某部门 / 某文档」约束与权限隔离，常配合 Self-Query 自动抽条件
标准回答
为什么需要元数据过滤
纯向量相似度只看语义接近度，无法表达「只要 2025 年之后的」「只要财务部的」「只看用户有权限的文档」这类结构化约束。给每个 chunk 打上元数据（来源、文档 ID、时间、作者、部门、类别、权限标签等），就能在语义检索之外叠加精确的条件过滤，大幅缩小候选范围、提升精度。
两种过滤时机
- Pre-filter（检索前过滤）：先用结构化条件把向量库限定到一个子集，再在子集内做近似最近邻检索。范围小、精度高，但要求向量库支持带条件的 ANN（如 Milvus、Qdrant、pgvector 的混合查询）。
- Post-filter（检索后过滤）：先按相似度召回，再丢弃不满足元数据条件的片段。实现简单，但若过滤掉太多，最终进上下文的片段可能不够，需要相应放大初始 Top-K。
典型用途
常见误区
⚠️ 常见踩坑
过滤条件设得过严，把相关片段也一并筛掉，造成召回不足甚至空召回。元数据过滤是为了「缩小到对的范围」，不是越窄越好；要保证元数据本身标注准确、口径统一，并对过滤后的召回量做监控，必要时放宽条件或回退。
追问
追问 1：Pre-filter 和 Post-filter 各有什么取舍，怎么选？
Pre-filter 先缩范围再检索，精度高、召回可控，但依赖向量库对「带条件 ANN」的原生支持，否则在大子集上做精确过滤代价高。Post-filter 实现简单、对引擎无要求，但过滤可能把召回打穿，需放大初始 K 兜底。选择上：库支持混合查询且过滤选择性强（命中比例低）时优先 Pre-filter；引擎能力有限或过滤条件较宽松时用 Post-filter。
追问 2：Self-Query 是怎么工作的，有什么风险？
Self-Query 用 LLM 把自然语言问题解析成「语义查询 + 结构化过滤条件」两部分，比如把「上个月北京区域的退货政策」拆成 category=退货政策、region=北京、time=上月，再交给向量库做带过滤的检索。风险在于 LLM 可能抽错字段、给出不存在的取值或格式不合法，因此要约束可用字段 schema、做取值校验与容错，抽取失败时回退到无过滤检索。
追问 3：在企业 RAG 里如何用元数据做权限隔离，要注意什么？
给每个 chunk 打上权限标签（如可见角色、部门、密级），检索时强制把当前用户的权限作为 pre-filter 条件注入，确保越权内容根本不进候选集。注意几点：权限过滤必须在服务端强制执行、不能依赖前端；要随源文档权限变更同步更新索引中的标签；避免在日志/缓存里泄露越权片段；并对「过滤后空召回」给出合规的拒答提示，而不是放宽权限。
🔗 相似问题
同一考点的不同问法，面试官可能换着问，一起刷更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习