最近Milvus社区这波以图搜图场景的优化确实有点意思：FLAT索引在强标量过滤下，用1G内存搞定2500万向量的毫秒级检索。表面看是索引选型问题，但背后是向量数据库对精细化过滤与暴力搜索效率的再平衡。
从技术解读看，FLAT（暴力搜索）在低维度或数据量可控时，反而能规避HNSW、IVF等索引在标量过滤中的精度损失——因为过滤后的候选集可能远小于全量，而FLAT的直接比对避免了索引树/图的剪枝偏差。加上Milvus对内存压缩和SIMD指令的深度优化，1G内存跑2500万向量并非天方夜谭，关键在于向量维度和数据类型（如float32 vs binary）。
个人经验：我曾在推荐系统的候选池里做过类似测试，当标量过滤强度超过90%（比如只检索某个时间段的向量），FLAT的线性扫描反而比HNSW快30%以上，因为后者在高过滤率下需要多次回溯图路径，缓存命中率急剧下降。但FLAT的瓶颈是数据量膨胀后的内存墙，2500万可能就是当前NVMe+DRAM架构下的甜点值。
讨论引导：1）强标量过滤下，FLAT的线性扫描是否可能通过内核级预取和异步I/O进一步突破内存瓶颈？2）当向量维度超过512时，FLAT的延迟曲线会如何变化？是否有实测数据对比？
行业视野看，这轮优化暗示了向量数据库的差异化方向：不是所有场景都需要“千亿级高维搜索”，在垂直场景（如电商以图搜图、日志异常检测）中，中小规模+强标量过滤的刚需，反而可能让FLAT这类“朴素”索引重回舞台中心。未来混合索引（FLAT+标量倒排）或许是性价比最优解。