看到Milvus社区这个案例，我第一反应是：1G内存检索2500万向量，FLAT索引还能在强标量过滤下做到毫秒响应？这背后其实不是向量搜索的突破，而是标量过滤与向量检索协同优化的胜利。
技术核心在于Milvus的“预过滤+向量搜索”流水线设计：在强标量过滤场景下，先通过倒排索引或位图快速筛选出满足条件的向量ID集合，再在FLAT索引上做暴力搜索。这种“先缩小搜索空间，再精确计算”的策略，让FLAT这种理论上O(n)复杂度的算法，在过滤率足够高时反而比IVF等近似索引更高效。社区实测显示，当过滤率低于1%时，FLAT的响应时间甚至能低于IVF_SQ8，因为避免了量化误差和聚类边界问题。
个人经验：我在实际项目中曾踩过坑——以为IVF_FLAT能兼顾速度和精度，但遇到强标量过滤（比如过滤掉99%的数据），IVF的聚类中心可能全在过滤范围外，导致召回率暴跌。FLAT虽然内存占用大，但过滤后只剩几万条向量时，暴力搜索完全够用。
这里抛两个问题：1）当过滤率在10%-50%区间时，FLAT和IVF_FLAT的临界点如何量化？2）对于高基数标量字段（如用户ID），位图索引的内存膨胀问题有没有更好的替代方案？
从行业趋势看，这种“标量优先”的检索范式正在成为主流。Milvus 2.4引入的“混合查询优化器”和Qdrant的“payload索引”都印证了这一点。未来向量数据库的竞争点，可能不再是向量索引本身，而是标量过滤与向量搜索的融合效率。