向量搜索的元数据过滤：数据增长时如何保持检索精度

Redis 官方博客发表文章（作者 Simran Regmi），系统讲解向量搜索中的元数据过滤（metadata filtering）：它是什么、预过滤与后过滤的区别、数据集增长时在哪里失效、混合查询与统一引擎如何在高精度下扩展。核心观点：向量搜索擅长找语义相似的东西，但相似不等于正确——纯向量查询不知道商品缺货、文档属于不同客户、或政策上季度已被取代。元数据过滤通过把结构化约束（价格、状态、租户、日期）叠加在相似度之上，弥合这个差距。本文基于 Redis 官方文章，解读元数据过滤的技术细节。

什么是元数据过滤

元数据过滤把向量搜索限制为只返回属性匹配条件的向量：状态是"new"、文档日期晚于 2024 年 1 月、租户 ID 匹配当前用户组织。

• 支持数值范围、分类标签、地理半径、时间戳、全文字段
• 常见模式：电商搜索在价格带内找相似商品；学术搜索按发表日期和刊物过滤；RAG 中一个向量库通过元数据过滤服务多个用例，无需每个知识域单独建索引
• 多租户 SaaS：正确执行的租户 ID 过滤让一个客户的文档不会出现在另一个客户的结果里

实际影响很大：一个基准中，元数据过滤把系统准确率从 0.12 提升到 0.61。收窄合格集合给模型更多相关材料、更少干扰——也帮助缓解 agent 构建者所说的"上下文混淆"（context confusion）：上下文窗口中无关块更少，模型抓错块的概率更低。

预过滤 vs 后过滤

过滤时机决定召回率（返回多少相关结果）和延迟：

• 预过滤（先过滤再搜索）：找出匹配过滤器的所有向量，只对这些做相似度搜索。永远不会返回不合格结果；但如果大量向量匹配，几乎要搜索整个数据集，退化为线性扫描
• 后过滤（先搜索再过滤）：先跨全部数据跑快速近似最近邻（ANN）搜索，再丢弃不匹配结果。速度快，但如果只有少量向量匹配，大部分结果被丢弃，返回少于请求的 k 个
• 联合过滤（搜索时过滤）：搜索遍历索引时检查过滤器，跳过不匹配向量。中等的匹配比例下避免两个陷阱：不搜索整个子集、也不在末尾丢弃结果

一个 5% 选择率的过滤测试中，后过滤召回率跌到 0.95 以下，暴力预过滤保持完整召回但牺牲吞吐。串联三者的变量是选择率（selectivity）：数据集中通过过滤器的比例。

数据集增长时过滤在哪里失效

从百万级向量增长到十亿级时，常见失败模式：

• 选择性过滤器下召回崩溃：过滤器只匹配一小片数据时，两种策略都挣扎。后过滤把搜索预算烧在随后丢弃的向量上，返回少于请求数；预过滤和联合图搜索遇到反向问题——数据裁得太少让图稀疏或断开，导致延迟尖峰或漏匹配
• 索引膨胀：每个可过滤属性都耗存储，而且快速累积。属性越多、每个属性取值越多，索引要应对的过滤组合越多，且随每个新属性指数增长
• 多属性查询变难：单属性过滤可管理；同时过滤价格、日期、类别是不同的问题。查询复杂、数据集大或内存紧张时，多数 filtered-ANN 方案开始暴露裂缝

结论：过滤器是一等设计约束，不是选好索引后临时加的东西。

混合查询：过滤 + 关键词 + 向量相似度

过滤处理资格问题，但生产搜索还有第二个缺口：向量相似度和关键词匹配互补失败。

• 关键词搜索漏掉释义："side effects" 和 "adverse reactions" 无共享表面词
• 向量搜索漏掉精确稀有词：错误码、产品 ID、命名实体

混合查询同时跑两种，再合并结果。常见合并方法是倒数排名融合（RRF）：按每个结果列表中的排名位置打分而非原始分数，无需把关键词分数与余弦相似度归一化。融合后召回高于任一单独方法。

• Redis 8.4 新增 FT.HYBRID 命令：单一执行计划内融合全文相关性和向量相似度（RRF 和线性组合评分）
• 共享元数据预过滤应用于两个通道，词汇和向量结果的资格保持一致

过滤与向量放在同一引擎

过滤、文本索引、向量都在一个引擎时，混合搜索更容易。许多团队把它们拆到多个系统：向量数据库存 embedding、关系库存元数据、再加独立文本搜索系统。问题：每次写入都要落到所有系统；同步落后时，过滤器可能读到某系统已更新、另一系统未更新的记录，返回过时或不一致结果——这是正确性问题，不只是慢。

• 全放一个引擎：同步问题消失，元数据和向量一起写入、索引、查询
• 十亿向量基准：Redis 8 报告 90% 精确率、约 200ms 中位延迟
• RedisVL Python 客户端把过滤器构建为 tag、numeric、text、geo 字段的可组合对象
• Redis Iris 把"一个引擎"思路做成 AI agent 的实时上下文引擎

最佳实践

• 限制可过滤索引：仅作参考存储的元数据（如原始文本块）不需要可过滤索引。索引一切膨胀内存、拖慢写入，却不改进任何查询
• 把租户和权限过滤当安全控制：租户 ID 预过滤正确执行时可阻止未授权向量进入评分集合。过滤隔离是逻辑层面而非基础设施层面，构造过滤器的代码应得到与认证代码同等的审查
• 用代表性过滤器做基准：平均延迟会掩盖选择率问题。用反映真实属性分布的过滤器衡量召回和延迟——行为会随工作负载变化，用自己数据验证架构而非依赖通用基准

总结

元数据过滤把向量搜索从"找相似的东西"变成"找相似且实际合格的东西"——这是 RAG、推荐和多租户搜索在生产中可信的关键。写过滤器是容易的部分，难点在于选择率变化时保持召回和延迟稳定，并确保过滤器始终反映数据当前状态。一致性是更隐蔽的问题：过滤器与数据失步时，结果看似正确却悄悄包含过期记录或漏掉有效记录，比明显错误更难发现。把向量、元数据和文本搜索放在一个引擎消除这种风险，因为不存在可漂移失步的独立系统。

来源：https://redis.io/blog/metadata-filtering-vector-search-precision/