在 RAG 检索链路中，向量数据库的元数据过滤能力常被低估。许多团队选型时只关注召回率、延迟和成本，直到上线多租户或权限控制需求，才发现过滤实现方式直接决定检索质量与架构复杂度。
过滤发生在向量检索的哪个阶段
向量数据库的过滤策略可归为三类：
预过滤：先根据元数据条件筛选出候选集，再在候选集内做向量相似度计算。优点是结果精确，不会漏掉满足条件的向量；缺点是如果候选集过小，近似最近邻（ANN）索引可能退化为暴力扫描，延迟上升。
后过滤：先做向量检索得到 Top-K 结果，再根据元数据条件过滤。优点是向量检索效率高；缺点是如果过滤条件筛掉大量结果，最终返回数量可能远小于 K，甚至为空。例如多租户场景下，全局 Top-100 可能全部属于其他租户。
混合过滤：在 ANN 搜索过程中动态应用过滤条件，兼顾效率与召回。实现方式因数据库而异，有的在 HNSW 图遍历时跳过不满足条件的节点，有的在倒排索引与向量索引间做联合查询。
为什么过滤能力直接影响 RAG 质量
RAG 的检索质量不仅取决于向量相似度，还取决于能否在正确范围内检索。典型场景包括：
- 多租户隔离：每个租户只能检索自己的文档。若后过滤导致召回不足，回答会缺失关键上下文。
- 权限控制：用户只能访问有权限的文档。过滤不精确会引入越权内容或漏掉合法内容。
- 时效性约束：只检索最近 N 天的文档。预过滤可缩小范围，后过滤可能因旧文档占据 Top-K 而失效。
- 多条件组合：同时按部门、文档类型、语言过滤。组合条件对过滤引擎的表达式能力要求更高。
过滤能力不足时，开发者常被迫在应用层做补偿：先扩大 K 值再过滤，或维护多个集合。这增加了架构复杂度和延迟。
评估过滤能力的测试方法
选型时不能只看文档宣称支持过滤，而应构造可量化的测试。
1. 构造带条件约束的查询
准备一个数据集，其中 90% 向量属于租户 A，10% 属于租户 B。查询向量与租户 B 的某个向量高度相似。分别测试：
- 无过滤：Top-10 应包含该向量。
- 过滤租户 B：Top-10 应全部来自租户 B，且包含该向量。
- 过滤租户 C（不存在）：应返回空或明确错误。
观察返回数量、延迟和召回率变化。
2. 观察召回变化
逐步收紧过滤条件，记录召回率。如果召回率断崖式下降，说明过滤实现可能退化为后过滤或候选集过小。
3. 验证多条件组合
测试 AND、OR、NOT 以及范围查询（如时间戳大于某值）。检查是否支持嵌套条件、是否对字段类型有要求。部分数据库对高基数字段的过滤性能较差，需重点测试。
4. 测试写入与过滤的相互影响
在持续写入的同时执行过滤查询，观察延迟抖动。某些数据库在段合并或索引重建期间过滤性能会下降。
将过滤能力转化为选型决策
测试结果需结合以下维度判断：
- 数据规模：千万级以下，后过滤加扩大 K 值可能可接受；亿级以上，预过滤或混合过滤更稳妥。
- 写入模式：高频写入场景下，过滤字段的索引维护成本需纳入考量。
- 部署环境：自托管需评估过滤功能的配置复杂度；云服务需确认过滤是否额外计费。
- 多租户需求：若租户数量多且数据隔离严格，优先选择原生支持分区或命名空间过滤的数据库。
工程取舍
没有一种过滤策略适合所有场景。预过滤保证召回但可能牺牲延迟；后过滤延迟低但召回不稳定；混合过滤平衡两者，但实现质量参差不齐。建议在选型早期就用真实数据分布做过滤测试，而不是等上线后才发现召回不足。
最终，向量数据库的过滤能力不是附加功能，而是 RAG 检索链路的基础设施。把它作为选型的一级指标，能避免后期架构返工。