向量检索怎样把元数据过滤放在召回前

向量检索要把元数据过滤放在召回前，核心不是把查询字符串写得更长，而是让过滤字段进入同一个检索边界：先确定“哪些文档有资格被看见”，再在这批候选中按向量相似度取 top_k。这样能避免全局近邻被大量无效结果占满，也能把租户、状态和时间范围等硬约束留在检索层。本文用 Redis Search 的写法说明这条边界，其他向量库也可以按同样思路验证。

官方地址：https://redis.io/docs/latest/develop/ai/search-and-query/

预过滤适合“必须满足”的条件，例如 tenant_id、文档状态和时间范围；它不等于一定更快。真正的结论要看过滤选择率、索引结构、top_k、分片数和 P95 延迟。

一、先区分预过滤与后过滤

假设知识库有十万段文本，用户只允许访问 tenant_id 为 acme、状态为 published 且年份不早于 2024 的内容。后过滤的做法是先从全库取 top_k，再在应用层删除不符合条件的段落。若全局最相似的 10 条里只有 2 条属于 acme，最终结果就只剩 2 条，继续补查还会增加延迟。

预过滤则把合法范围放在 KNN 左侧，向量排序只在合法集合里进行。它更适合权限隔离和硬业务条件；“相关性较高”“希望包含某个词”这类软偏好，仍然可以交给文本检索或二阶段重排。

二、预过滤的关键是先缩小合法候选集

设计索引时，元数据必须是可检索字段，而不是只存进 JSON 后再由应用层判断。分类或租户字段通常适合 TAG，价格、年份和时间戳适合 NUMERIC，正文关键词才使用 TEXT。Redis 的混合查询用 过滤表达式=>[KNN ...] 表达先过滤再做近邻搜索：

# 先限定租户、状态和年份，再在合法集合内取 20 个近邻
FT.SEARCH docs "(@tenant_id:{acme} @status:{published} @year:[2024 +inf])=>[KNN 20 @embedding $query_vec AS distance]" \
  PARAMS 2 query_vec "$BLOB" \
  SORTBY distance ASC \
  RETURN 3 title tenant_id distance \
  DIALECT 2

# 查询向量与索引字段的维度、类型和距离度量必须保持一致
# 生产代码还要校验租户条件来自已认证的请求上下文，而不是用户任意传入

这里的 tenant_id 和 status 是硬边界，distance 只负责在边界内排序。过滤条件越窄，候选集越小；但如果候选太少，top_k 可能经常不足，甚至返回空结果，所以不能只追求“过滤得越多越好”。

三、top_k 不够时先看过滤选择率

可以把过滤选择率定义为“满足元数据条件的记录数 ÷ 全部记录数”。选择率高时，预过滤对召回数量影响不大；选择率低时，固定 top_k 可能出现结果稀疏。此时应记录有效候选数、空结果率和最终上下文条数，再决定是否增加候选数量、放宽非安全条件，或按租户拆分索引。

四、用指标验证过滤是否真的有效

不要拿一次查询的返回结果判断优化成功。准备一组固定问题，分别跑预过滤、后过滤和二阶段重排，至少记录四项指标：过滤选择率、P95 延迟、空结果率和人工标注的召回质量。若预过滤让 P95 下降但相关段落明显减少，说明边界或字段建模需要调整；若后过滤相关性好却经常为空，则应增大第一阶段候选池，而不是简单提高最终 top_k。

# 固定查询集与并发参数，分别记录每种路径的 P95 和空结果率
# 不把示例数字当成线上结论，结果应写入自己的压测记录
for mode in prefilter postfilter rerank; do
  echo "# 运行对照模式: $mode"
  ./retrieval-benchmark --mode "$mode" --queries queries.json --top-k 20 --concurrency 16
done

# 重点观察：合法候选数、最终返回数、P95、召回质量和跨租户拦截数

五、哪些情况不宜强行预过滤

当过滤字段高度动态、几乎没有命中、需要跨分片聚合，或者业务条件本身只是排序偏好时，预过滤可能放大索引维护和查询成本。可以考虑按租户或领域做分区、拆分高频索引，或先用较宽的合法范围召回，再用独立模型做二阶段重排。无论选择哪种方案，权限和租户隔离都不能退到最后一步才判断。

常见问题

预过滤是不是一定比后过滤快？

不是。选择率、索引算法、过滤字段基数和分片布局都会改变结果。预过滤首先保证候选合法，速度要用固定查询集和 P95 实测。

top_k 越大是不是召回越好？

只在候选集足够且重排预算允许时有帮助。top_k 过大可能增加扫描、网络和上下文成本，应同时观察空结果率、相关性和延迟。

把元数据过滤放在召回前，最终要落到三个动作：把硬条件建成索引字段，把条件写进 KNN 边界，再用选择率和 P95 复盘参数。这样优化的对象才是完整的检索链路，而不是只改一个查询片段。