超级管理员
楼主
AWS 给 S3 Vectors 加了元数据预过滤能力，让带过滤条件的相似度检索先评估元数据、再做向量比对。
技术细节
- 每个向量最多支持 2KB 的可过滤元数据。
- 单条查询最多 100 个过滤约束。
- 支持前缀匹配（$startsWith），适合层级化的 key（比如 tenant/category/sku 这种结构）。
- 无需额外费用，不需要重新导入数据，也不用改查询方式。
为什么预过滤比后过滤好 这是向量检索里的经典问题。后过滤的做法是：先做全量 ANN 检索拿到 top-K，再用元数据条件过滤。问题在于，如果符合条件的向量在原始 top-K 之外，就丢了——召回率下降。
预过滤反过来：先用元数据把候选集缩小到相关子集，再在这个子集里做相似度排序。对多租户（按 tenant 过滤）、分类检索（按 category 过滤）这类场景，召回率提升很明显。
典型受益场景
- RAG 应用：按文档来源、权限、时间范围过滤后再检索。
- 多租户 SaaS：每个租户只检索自己的向量，天然隔离。
- 电商推荐：按品类、库存状态、价格区间过滤。
- 法务和电子取证：按案件、时间、密级过滤。
成本与性价比 S3 Vectors 的定位是把向量存储放到对象存储上，成本远低于专用向量数据库，代价是查询延迟更高。
加了预过滤之后，它的适用范围又宽了一些——以前那些“因为召回率不够而放弃 S3 Vectors”的场景可以重新评估。
选型时的判断标准
- 数据量极大、查询频率低、对延迟不敏感 → S3 Vectors 很合适，成本优势巨大。
- 高并发在线检索、P99 要求几十毫秒 → 还是要专用向量库或内存方案。
- 过滤条件复杂、层级深 → 这次的 $startsWith 支持让层级 key 的设计变得可行。
实操建议
- 元数据字段要提前设计。哪些字段会用于过滤、基数多高，决定了过滤效率。高基数字段做过滤效果会打折扣。
- 2KB 的元数据上限不算大。别把整个文档塞进去，只放过滤需要的字段。
- 100 个约束上限对绝大多数场景够用，但如果你在构建复杂的组合过滤条件，注意别超。
- 对比测试。拿你的真实查询集，跑一遍预过滤开启前后的召回率，用数据决定是否值得改查询方式。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。