主题
7.3 FAISS 的局限性与未来
FAISS 不会消失——即使你用 Milvus，底层也在用 FAISS
这一节在讲什么？
这是本教程的最后一节，我们要诚实地聊一聊 FAISS 的局限性，以及它在向量搜索生态中的未来位置。FAISS 不是万能的——它不支持标量过滤、不支持分布式、不支持持久化、Python API 不够友好、文档相对匮乏。但 FAISS 有一个不可替代的位置——它是向量索引的"基础设施"，Milvus 和很多向量数据库的底层引擎就是 FAISS。
FAISS 的已知局限
局限1：不支持标量过滤
FAISS 只做向量搜索——你不能在搜索时同时做 WHERE 条件过滤。如果你需要"分类为 tech 且价格低于 1000 的最相似文档"，FAISS 做不到——你需要先在应用层过滤，或者用 FAISS + pgvector 混合方案。
局限2：不支持分布式
FAISS 是单机库——所有数据必须在一台机器的内存中。如果你有 10 亿条向量需要 300 GB 内存，你必须买一台 300 GB 内存的服务器，而不能像 Milvus 那样把数据分片到多台机器上。
局限3：不支持数据持久化
FAISS 的数据全在内存中——进程退出数据就没了。你需要自己实现序列化/反序列化，自己管理索引文件的保存和加载。
局限4：Python API 不够友好
FAISS 的 Python API 是 C++ 的直接映射——很多参数需要手动配置，错误信息不够清晰，没有类型提示。比如 IndexHNSWFlat(d, M) 的第二个参数 M 是什么？如果你没看文档，你不会知道它是"每层最大连接数"。
局限5：文档相对匮乏
FAISS 的官方文档比较简略——很多高级功能（如 OPQ、IndexPreTransform、多 GPU）需要看源码或 GitHub Issues 才能理解。相比之下，Milvus 和 pgvector 的文档要完善得多。
FAISS 的不可替代性
尽管有这些局限，FAISS 在向量搜索生态中的位置是不可替代的：
- 向量索引的基础设施：Milvus 的 IVFFlat/IVF_PQ/HNSW 底层就是 FAISS，很多向量数据库的索引构建也依赖 FAISS
- GPU 加速的唯一选择：目前只有 FAISS 提供成熟的 GPU 向量搜索实现
- 最丰富的索引类型：20+ 种索引类型，覆盖从暴力搜索到量化索引到复合索引的全部场景
- 学术研究的标准工具：向量搜索算法研究的基准实现
未来趋势
向量数据库的索引层越来越标准化——Milvus 2.5+ 的 INVERTED 索引、Qdrant 的量化支持、Weaviate 的 BQ 索引，这些功能都在缩小与 FAISS 的差距。但 FAISS 作为底层引擎的地位不会动摇——因为向量数据库需要的是"稳定易用的 API"，而 FAISS 提供的是"极致性能的 C++ 实现"，这两者的需求是互补的。
教程总结
七个章节走下来，我们从 FAISS 的定位一路走到了与向量数据库的协作。让我用几句话回顾整个教程的核心脉络：
第 1~2 章我们理解了 FAISS 的定位——它不是数据库，是向量搜索库，只做内存中的向量搜索。Index 是 FAISS 的核心抽象，距离度量通过 IndexFlatL2/IndexFlatIP/normalize_L2+IP 实现。
第 3~4 章我们掌握了 FAISS 的索引类型——Flat（暴力基准）、IVF（倒排+train）、HNSW（图搜索）、PQ/OPQ/SQ（量化压缩）。其中 IVF 的 train 概念和 HNSW 的低默认 efSearch 是最容易踩的坑。
第 5 章我们探索了高级特性——GPU 加速（5~20 倍性能提升）、积木式索引组合（IndexPreTransform/IndexRefineFlat/IndexIDMap）、批量搜索、序列化持久化。
第 6~7 章我们把 FAISS 放到了 RAG 系统和向量数据库生态中——FAISS 是 RAG pipeline 中的"检索引擎"组件，FAISS+pgvector 混合方案兼顾性能和功能，FAISS 是 Milvus 的底层引擎。
如果你要记住这个教程的一句话，那就是：FAISS 的核心价值不在于替代向量数据库——而在于它是向量搜索的底层引擎，理解 FAISS 就是理解向量索引的底层原理。当你用 Milvus 创建 IVF_PQ 索引时，底层调用的就是 FAISS；当你需要 GPU 加速或自定义索引组合时，FAISS 是唯一的选择。