在 RAG 系统的检索环节中，“过滤”是一个必不可少的步骤——无论是按权限控制（只让特定用户看到授权文档）、按时间范围（只查近一年的政策）、还是按文档类型（只看技术手册不看市场周报），都需要在检索时对候选文档进行筛选。根据过滤发生在检索的哪个阶段，可以分为前置过滤和后置过滤两种策略，二者在原理、性能和适用场景上有明显区别。
1. 前置过滤：先筛后检
原理
在向量检索之前，先用明确的过滤条件（如标签、权限字段、时间戳等）筛选出符合条件的文档子集，然后只在这个子集中做语义相似度检索。这就像去图书馆找书，先通过分类号锁定某个书架，再在这个书架上细找内容相关的那一本。
实现方式
主流向量数据库（如 Milvus、Pinecone、Weaviate 等）都支持在检索时传入过滤表达式，例如 {"doc_type": "policy", "publish_date": {"$gt": "2024-01-01"}}。检索时，数据库会先应用过滤条件，然后在通过过滤的向量集合中执行最近邻搜索。
性能特点
- 检索范围可控：只在小范围内做向量计算，检索速度更快。
- 索引利用充分：如果过滤字段建有标量索引（如倒排索引），过滤本身开销极低。
- 结果精准：保证返回的每一条记录都满足过滤条件，不会出现“召回不错但被过滤掉”的浪费。
潜在风险
如果过滤条件过于严格，导致符合条件的文档数量极少（例如权限过滤后只剩个位数文档），此时语义检索的 top-k 可能填不满，或者相似度计算退化，召回质量下降。这就是所谓的“过滤过度”——筛子太密，把本来可能相关但标签略有偏差的内容也排除在外。
适用场景
- 过滤条件明确且能稳定命中一定规模的文档集合；
- 权限隔离严格，绝不允许跨租户检索的场景；
- 知识库按维度天然分区（如部门、项目），且每个分区内文档量充足。
2. 后置过滤：先检后筛
原理
先在全局向量空间中做语义检索，返回 top-k 个最相似的文档片段，然后在这些结果上应用过滤条件，剔除不满足条件的条目，最后用剩下的结果（或重新补召）送给生成模型。相当于先在整个图书馆找内容最相关的十本书，再从这十本里丢掉不属于“技术类”的那几本。
实现方式
检索时不做过滤，或仅做宽松的预过滤，拿到更大候选集（如 top-k 较大，或直接一次召回后补召），然后在应用层根据元数据字段进行过滤。部分向量数据库支持对检索结果做后置过滤的语法，但更多是在业务代码中自行处理。
性能特点
- 召回范围广，语义匹配更充分：不会因为过滤条件限制而丢失可能相关但元数据略有偏差的片段。
- 可能引入不必要的检索开销：全局检索会扫描整个索引，计算量可能大于前置过滤。
- 结果可能存在浪费：召回 k 条，过滤后可能只剩不到 k 条，需要设置略大的 top-k 或启用增量召回来补足。
潜在风险
- 性能波动：如果知识库总量巨大，全局检索的延迟会高于前置过滤。
- 过滤后结果不足：极端情况下，召回的前几十条可能都不满足过滤条件，需要回退逻辑（如扩大 top-k、切换为前置过滤）。
- 信息泄露风险：在检索阶段，不满足权限的文档的向量参与了相似度计算，虽然最终没有返回给用户，但在某些高安全等级的场景下这可能不被允许。
适用场景
- 过滤条件较为复杂，难以在向量检索前精确表达（如基于内容的某些语义规则）；
- 知识库总量不大，全局检索开销可接受；
- 对召回结果的覆盖率要求极高，宁愿多召回一些再筛，也不愿遗漏。
3. 性能差异对比
| 维度 | 前置过滤 | 后置过滤 |
|------|----------|----------|
| 检索范围 | 仅限过滤后子集 | 全库检索 |
| 检索速度 | 快（子集小） | 相对慢（全库扫描） |
| 召回质量 | 可能因过滤过严而漏掉相关结果 | 语义覆盖更全，但可能混入无关结果 |
| 结果确定性 | 每条结果都满足过滤条件 | 可能出现过滤后结果不足，需补召逻辑 |
| 元数据要求 | 必须有高效索引的过滤字段 | 可做更灵活的过滤，甚至基于内容判断 |
| 安全性 | 天然隔离，未授权文档的向量完全不参与 | 检索阶段可能触及所有文档（需评估合规性） |
| 实现复杂度 | 依赖向量数据库的过滤能力 | 较易在应用层实现，但需处理回退 |
4. 实际应用中的混合策略
为了避免两种过滤方式的极端缺陷，很多生产系统采用混合过滤或动态选择的模式：
- 粗筛+细检：先用较宽泛的前置过滤（如按租户 ID 或大类目）缩小范围，再做语义检索，最后在结果上做更精细的后置过滤（如检查权限标签）。
- 阈值动态切换：当系统检测到前置过滤后候选集小于一定数量（如低于 500 个向量），自动切换为全局检索+后置过滤，并相应调大 top-k，防止召回不足。
- 多路召回合并：同时发起前置过滤检索和后置过滤检索，将两路结果去重合并，兼顾覆盖面与效率，再统一排序输出。
真实经验
某企业知识库按部门划分了十几个独立索引，初期全部采用前置过滤（只查本部门的文档）。后来发现跨部门的项目成员经常搜不到有效结果，于是改为按项目标签做后置过滤，允许全局检索但最终只保留带项目权限标签的片段。调整后，平均检索延迟增加了约 15%，但问题有效解答率提升了近 30%。这种折衷最终被业务方接受，因为“找到答案”比“快零点几秒”更重要。
前置过滤和后置过滤并非互斥，理解其原理和差异，能帮助在实际系统设计中根据数据规模、权限要求、性能水位做出恰当的取舍和组合。