向量检索里的 metadata 过滤先设计再扩字段

metadata 过滤设计 这件事在 2023 年开始越来越频繁地进入真实项目，但很多团队一开始只看到表面收益，没有先把边界收住。只要 字段命名和过滤粒度不一致，导致向量召回只能靠全文语义硬扛，问题就会很快从“一个小体验瑕疵”变成系统性的维护成本。

我现在更倾向的做法，是先把这类能力当成正式工程问题来看，而不是把它当成一个临时技巧。对我来说，最关键的一步通常是 先明确哪些过滤维度是业务必须的，再决定 metadata 结构，因为只有边界先明确，后面的优化、扩展和排查才不会一直漂。

真正容易被忽略的，往往不是功能能不能做出来，而是以下这些细节：

• 文档来源、更新时间、权限范围通常要优先进入 metadata
• 过滤字段不要一会儿是字符串一会儿是数组，后续查询会很痛苦
• 检索实验要分开看“语义召回”和“条件过滤”是否各自有效

这些细节看起来都不大，但它们决定了系统是在 demo 阶段“能跑”，还是进入业务以后依然稳定。越是和 AI、工作流、构建链路这类复杂能力相关，越不能靠感觉把事情糊过去。

小结

向量检索的可用性，一半在 embedding，一半在 metadata。过滤设计先稳住，RAG 才不会只剩“语义碰运气”。