在 RAG 检索链路中，向量数据库选型常被简化为对比 QPS、延迟和索引类型。但真正决定线上效果和迭代成本的，往往是元数据过滤与向量召回的配合方式。同一个数据库，在不同过滤策略下可能表现出完全不同的召回稳定性。
从查询模式反推过滤需求
选型前先梳理查询模式，而不是先看产品参数。典型 RAG 查询包含三类约束：
- 硬性范围：租户 ID、权限标签、文档状态、时间窗口。这类字段必须精确匹配，漏掉会引发数据越权或结果不可用。
- 软性偏好：语言、来源类型、业务分类。它们影响排序，但不应把候选集砍到过小。
- 动态条件：用户会话中临时勾选的筛选器，组合数量不可预知。
把这三类约束映射到数据库能力上，核心问题是：过滤发生在向量索引遍历之前、之后，还是与遍历交织进行。
三种过滤策略的工程影响
预过滤先按元数据条件筛出候选集，再在候选集内做向量近邻搜索。优点是结果一定满足过滤条件，不会出现“先召回再丢弃”导致的 top-k 不足。代价是当过滤条件选择性很高时，候选集可能远小于索引分片，ANN 索引的图结构或倒排列表无法被充分利用，延迟反而上升。
后过滤先做向量检索，再对结果应用元数据条件。实现简单，向量索引效率高。但风险明确：如果过滤条件命中率低，top-k 中大量结果被丢弃，最终返回数量不足。开发者常通过放大 top-k 缓解，但这会推高计算和网络开销，且放大倍数难以稳定估计。
混合过滤在向量索引遍历过程中结合元数据条件，例如按过滤字段分区后再检索，或在图遍历时跳过不满足条件的节点。它试图兼顾召回完整性和索引效率，但工程复杂度最高：需要数据库原生支持过滤下推，且过滤字段的索引结构要与向量索引协同设计。
评估维度：不要只看单次延迟
选型测试应围绕“带过滤条件下的召回稳定性”设计，而非只测无过滤的纯向量检索。建议关注以下维度：
- 过滤字段设计：区分高基数与低基数字段。租户 ID 这类高基数字段适合作为分区键或独立索引；状态、语言等低基数字段适合位图或标签索引。字段类型和组合方式直接影响过滤下推效率。
- 索引类型选择：HNSW、IVF、DiskANN 等对过滤的友好度不同。IVF 类索引可按过滤字段分桶，但桶数量与召回率需要调参；HNSW 图遍历中过滤容易破坏连通性，需确认数据库是否支持过滤感知的遍历策略。
- 分页与去重：带过滤的分页不能简单依赖 offset，因为过滤后候选集动态变化。应使用基于游标的分页，并在应用层对多路召回结果去重，避免同一文档因分块重叠重复出现。
- top-k 一致性：同一查询在不同过滤条件下，返回结果数量应稳定。测试时记录“请求 top-k”与“实际返回数”的比值，比值波动大说明过滤策略与索引配合不佳。
用同一套测试集验证召回稳定性
准备一个覆盖真实查询分布的测试集，包含：无过滤查询、高选择性过滤查询、多字段组合过滤查询。对每个数据库执行相同查询，记录：
- 实际返回数量与请求 top-k 的偏差；
- 过滤条件命中率与延迟的关系曲线；
- 相同查询重复执行的结果一致性；
- 过滤字段值分布变化时的召回波动。
重点不是找“最快”的数据库，而是找在过滤条件变化时召回数量不塌陷、延迟可预测的方案。如果某数据库在后过滤下需要把 top-k 放大 10 倍才能稳定返回，那么它的有效吞吐和成本模型都要重新计算。
可执行建议
- 先明确哪些过滤字段是硬约束，哪些是排序偏好，硬约束必须走预过滤或混合过滤。
- 在选型早期就用带过滤的查询压测，不要等上线后再补。
- 对高选择性过滤字段，确认数据库是否支持分区裁剪或过滤下推，而不是仅靠应用层后过滤。
- 分页和去重逻辑在应用层统一封装，避免不同数据库行为差异渗透到业务代码。
- 把“请求 top-k 与实际返回数比值”作为核心监控指标，持续观察过滤条件变化时的稳定性。
向量数据库选型没有通用最优解，只有与查询模式匹配的过滤策略。把过滤和召回放在同一个测试框架里评估，才能避免上线后出现“搜得到但不够数”或“够数但延迟失控”的问题。