向量检索过滤条件和 rerank 顺序如何安排

向量检索里，过滤条件和 rerank 的顺序不要反过来：先用租户、权限、状态、有效期等硬条件缩小可访问范围，再召回一批候选，之后才用 rerank 做语义相关性重排，最后应用分数阈值、去重和多样性检查。这样既不会把越权内容送进模型，也不会因为过早截断而丢掉真正相关的片段。

官方地址：https://platform.openai.com/docs/

先把硬过滤和软排序信号分开

我在调 RAG 检索时最容易踩的坑，是把“部门=研发”“文档未过期”与“更接近用户问题”放进同一个分数里。前两项不是偏好，而是访问边界；一旦混成分数，越权片段可能只是分数低一些，仍然有机会进入上下文。

更稳妥的划分如下：

以 OpenAI Vector Store 为例，文件可以保存 attributes，File Search 也提供 filters。工程上可以把租户和权限字段写入 metadata，但字段是否可靠、权限是否需要实时查询，仍应由业务系统决定，不能只因为存在向量索引就默认安全。

rerank 应该放在候选召回之后

推荐的静态分工是“过滤 → 召回 → rerank → 阈值/去重 → 最终上下文”。过滤后的召回数量应略大于最终需要的片段数，例如最终取 6 条时先取 30～50 条；具体数值要用离线问题集和上下文预算调出来，不要把它当成固定最佳值。

# 这是检索编排示意，不代表在本机执行过的结果
# 先剔除租户、权限和状态不匹配的片段，避免 rerank 接触越权候选
candidates = retrieve(
    query,
    top_k=40,
    filters={"tenant_id": tenant_id, "status": "active"}
)

# rerank 只比较合格候选与问题的相关性，不负责补救权限边界
ranked = rerank(query, candidates)

# 阈值放在重排后；低于阈值的结果不进入生成上下文
qualified = [item for item in ranked if item.score >= 0.72]

# 去重后再控制上下文条数，保留来自不同文档或章节的互补信息
context = diversify_and_limit(qualified, limit=6)

这里的关键不是某个具体 rerank 模型，而是候选集边界。若过滤发生在 rerank 之后，模型可能已经看到了本不该被当前用户看到的文本；若一开始只召回 6 条，rerank 没有空间纠正向量相似度的误排。

什么时候需要放宽过滤，什么时候应该拒绝结果

硬过滤不能为了“多返回几条”而随意放宽。租户、用户权限和文档状态属于拒绝条件，缺失字段也不应自动当作公开内容。可以放宽的通常是软条件，例如先不限定主题标签、扩大时间窗口，再让 rerank 判断相关性。

如果过滤后候选为空，建议把原因分层记录：是权限没有匹配、时间范围没有匹配，还是召回索引没有匹配。前两类不能通过 rerank 修复；第三类才适合尝试同义词、混合检索或扩大候选数量。OpenAI 的 File Search 参考中也能看到 filters 与 ranking options 是不同层次的能力，不能用相关性分数代替访问控制。

用四个检查点验证顺序是否合理

1. 边界检查：用同一问题切换两个 tenant_id，确认候选片段不会交叉。
2. 召回检查：记录过滤前后的候选数，观察是否因为硬条件过窄而长期为零。
3. 重排检查：比较 rerank 前后前十名的变化，不要只看最终答案。
4. 输出检查：记录阈值淘汰、重复淘汰和上下文截断数量，才能解释“为什么没有答案”。

如果系统只有一个简单文档集合，可以先用向量召回加少量 metadata filter；当用户问题包含产品名、编号或精确版本时，再加入关键词得分。只有候选边界稳定后，rerank 的收益才值得投入成本。

常见问题

过滤条件应该放在向量搜索前还是后？

租户、权限、状态和有效期等硬过滤应尽量在召回入口生效；如果底层能力只支持召回后过滤，也要把它视为安全风险和容量问题单独处理。

rerank 能不能替代 metadata filter？

不能。rerank 是相关性排序器，不是权限判断器；它不能保证不相关但合法的片段被排除，更不能保证越权片段不会被看到。

为什么最终取 6 条却要先召回 40 条？

较大的候选集给 rerank 留出纠错空间，也能支持去重和多样性选择；数量越大，延迟和成本越高，应通过离线评测找到平衡点。

阈值应该在 rerank 前设置吗？

如果阈值针对 rerank 分数，应放在 rerank 后。召回分数和 rerank 分数不一定同尺度，不能直接混用同一个阈值。