RAG 检索结果太多时怎么用元数据过滤缩小上下文

RAG 检索结果太多时，先别急着把 top_k 从 5 调到 50。更稳妥的做法是把租户、文档类型、有效状态和更新时间等元数据放进检索条件，让向量相似度只在“有资格被返回”的文档里排序。这样进入上下文的片段更少，模型也不必自己判断哪些内容已经过期或属于别的用户。

核心判断：元数据过滤负责定义候选边界，向量检索负责比较语义接近程度；两者顺序反过来，往往会用更大的召回成本换来更少的有效结果。

先把可过滤的元数据定义成检索边界

一条知识片段通常同时有两类信息：正文经过 embedding 得到的向量，以及写入时附带的结构化字段。前者回答“语义上像不像”，后者回答“这条内容现在能不能参加检索”。例如企业知识库的请求至少要带上当前租户；发布状态、文档类型和更新时间则决定内容是否仍然适用。

这一步的边界要尽量贴近业务规则。不要把每个展示字段都建成可过滤索引，否则写入成本、内存占用和组合查询复杂度会一起上升。权限字段尤其不能只靠前端传入；服务端应从已认证的请求上下文得到租户条件，再参与查询构造。

在向量搜索前应用过滤，而不是事后丢结果

如果先做全库近邻搜索，再在应用层筛掉不符合条件的片段，返回的 5 条里可能只剩 1 条；为了凑够上下文，又得把 top_k 调得更大。过滤条件放在向量查询的主表达式中，排序范围从一开始就被限制，语义相似度不会浪费在明确无资格的文档上。

以支持 KNN 和元数据查询的索引为例，查询结构可以写成下面这样。示例中的二进制向量由实际 embedding 模型生成，字段名和范围要与自己的索引 schema 一致：

# 只在当前租户、已发布 FAQ 和时间窗口内做 KNN 排序
FT.SEARCH kb_idx "(@tenant_id:{acme} @status:{published} @doc_type:{faq} @updated_at:[1704067200 +inf])=>[KNN 8 @embedding $query_vec AS distance]" \
  PARAMS 2 query_vec "$VECTOR_BYTES" \
  SORTBY distance ASC \
  RETURN 4 chunk_id text distance \
  DIALECT 2

这里的 8 是候选数量，不是“最终一定塞给模型的 8 段”。生产链路还可以在应用层做去重、按文档聚合、重排和上下文预算裁剪。重要的是 tenant_id 等条件来自受控参数，而不是把用户原文直接拼进查询字符串。

用过滤选择性调节 top_k 和混合检索

元数据过滤没有一个永远正确的宽度。过滤条件命中全库 60% 的文档时，向量搜索仍有足够候选；只命中 0.1% 时，事后过滤很容易拿不到足够结果，图索引在极窄集合上也可能出现召回和延迟波动。工程上应把“通过过滤的文档占比”作为选择性指标，按宽、中、窄三档回放真实请求。

如果问题里含有错误码、产品型号或专有名词，单纯向量搜索可能遗漏精确词；这时可以在同一元数据边界内叠加关键词检索，再做重排或 RRF 融合。过滤解决“哪些内容有资格”，向量和关键词分别解决“语义像不像”和“字面是否命中”，职责不要混在一个分数里猜。

把权限、时效和索引成本一起纳入检查

上线前可以按下面的清单检查，而不是只测一条平均查询：

• 同一问题分别使用宽、中、窄租户或时间过滤，记录有效结果数、Recall@k 和 P95 延迟。
• 构造“只有一条有效片段”和“没有有效片段”的请求，确认系统会降级或返回空结果，不会拿别的租户内容凑数。
• 文档更新、撤回和重新切片后，确认元数据与向量索引一起变更，避免过滤条件读到旧状态。
• 只索引真正参与查询的字段；把展示用但不参与筛选的原始内容留作返回字段，不要默认全部可过滤。

最终可以把策略写成一句工程约定：先按权限和有效性做候选边界，再在边界内做向量或混合检索，最后按上下文预算重排和裁剪。这样调 top_k 才有意义，因为它是在一组已经合格的候选中调节覆盖面，而不是用更大的数字掩盖过滤缺失。

相关问题

过滤条件越多，RAG 结果就越准吗？

不一定。条件过少会带来噪声，条件过多则可能把本来相关的文档全部排除。应以业务资格为边界，只保留能改变“是否允许进入候选集”的字段，再用回放数据观察选择性。

为什么不直接先取 100 条再过滤？

这种做法实现简单，但过滤很窄时，大部分候选都会被丢掉，最终结果数量、召回率和延迟都不稳定。能在索引查询阶段表达的条件，优先放到向量检索前。

元数据过滤能替代权限系统吗？

不能。它是检索层的必要约束，不是完整的身份认证和授权系统。租户条件应由服务端可信上下文生成，并配合数据访问层、审计和异常回放。

参考资料

• Redis Vector search：KNN 与主过滤表达式
• Redis Search with vectors：过滤类型与查询组合
• Redis：Metadata filtering 与向量检索选择性