看到Milvus社区这个案例，我第一反应是：1G内存检索2500万向量，还要在强标量过滤下做到毫秒响应，这确实是个硬骨头。技术解读上，FLAT索引本质上是暴力搜索，但在这个场景中，它反而因为避免了倒排索引的预过滤开销而胜出。关键点在于，当标量过滤条件极强（比如只留0.1%的向量）时，IVF_FLAT的聚类中心预筛选可能会引入大量无效距离计算，而FLAT直接对所有候选向量做精确计算，反而更高效。

从个人经验看，我之前在类似场景中踩过坑：以为IVF_FLAT总是更快，结果在标量过滤比例低于1%时，FLAT的响应时间反而更稳定。这提醒我们，向量数据库的索引选择不能只看向量维度或数据量，标量过滤的 selectivity 才是真正的变量。

我想请教两个问题：1）在强标量过滤下，FLAT的内存占用虽然小，但CPU计算压力是否会在高并发时成为瓶颈？2）Milvus是否考虑过结合标量索引（如倒排）和向量索引的混合策略，在过滤后动态选择索引路径？

从行业视野看，这个案例说明向量检索的优化正在从“纯向量性能”转向“标量+向量联合优化”。未来，类似Milvus这样的系统可能会更强调查询感知的索引自适应，比如根据过滤条件自动切换FLAT和IVF。这对那些需要实时过滤的海量检索场景（如电商以图搜图）会有很大影响。