FAISS：为检索提供支持的库 vectorielle

#一个库，而非一个数据库

人们常将 FAISS 与向量数据库相提并论，仿佛它们是替代品。但它们不属于同一类别。向量数据库是一项服务，具备 API、存储、过滤和权限管理功能。FAISS 则是一个组件：用 C++ 编写，并配有完整的 Python 和 NumPy 封装。你给它输入向量，它在内存中构建索引，并回答“哪些向量与这个向量最接近”这一问题。许多向量数据库在内部使用 FAISS 或类似技术。该项目采用 MIT 许可证发布，截至 2026 年 9 月底，GitHub 星标数超过 41 000，其作者指出，其部分方法可在单台服务器上扩展至主内存中数十亿个向量的规模。

实际而言，选择 FAISS 就意味着接受自行负责其余所有工作：将索引保存到磁盘、重新加载索引、确保索引与您的文档保持一致、建立向量位置与其来源文本之间的关联，以及决定两个进程同时尝试写入时该如何处理。这些功能都不是默认提供的；这是项目有意作出的架构选择，而非疏漏。

#具有实际价值的索引

最能节省时间的建议是：先从精确搜索开始。近似索引是为解决规模问题而设计的；在还没有遇到这个问题时就采用它们，相当于用增加参数调优和召回率测量工作的代价，换取谁都没有察觉的几毫秒提升。对于本地语料库的规模而言，检索几乎从来不是耗时的环节——最终用户感受到的响应时间，主要由语言模型的生成过程决定。

#使用 Python 起步所需的基本内容

1. 01
   安装库

   pip install faiss-cpu installe le paquet officiel PyPI (version 1.15.1 fin septembre 2026). Pour la variante GPU, le projet documente une installation via conda : conda install -c pytorch -c nvidia -c conda-forge faiss-gpu=1.15.1.
2. 02
   构建精确索引

   index = faiss.IndexFlatL2(dimension) 创建一个用于向量检索的精确索引，向量维度与您嵌入模型的维度一致。
3. 03
   添加向量

   index.add(vecteurs)，其中 vecteurs 是形状为 (n, dimension) 的 NumPy 数组，数据类型为 32 位浮点数。
4. 04
   查询

   distances, indices = index.search(requete, k) 返回距离最近的 k 个邻居及其距离；您需要自行将 indices 与原始文本片段对应起来。
5. 05
   保存并重新加载

   先使用 faiss.write_index(index, chemin)，再使用 faiss.read_index(chemin)，可将索引持久化到磁盘，在两次运行之间保存并重新加载，因为 FAISS 不会自行完成这一操作。

#根据语料库大小选择索引

该项目的官方 Wiki 发布了精确的参考值，表述为需传入其索引工厂（index_factory）的字符串。当向量数量少于一百万时，IVF_K 即可满足需求，其中 K 根据向量数 N 在 4×√N 至 16×√N 之间选取，训练集大小为 30×K 至 256×K 个向量。在一百万至一千万之间，推荐的组合是 IVF65536_HNSW32，它利用 HNSW 加速簇分配。在一千万至一亿之间，使用 IVF262144_HNSW32；超过一亿直至十亿，则使用 IVF1048576_HNSW32——在此阶段，训练速度明显变慢，通常需在 GPU 上进行，而其余部分在 CPU 上运行。

对于本地文档语料库——几千到几十万个文本片段——这些参考指标主要证实，我们距离必须使用近似索引的门槛还很远：精确索引，或者退而求其次的简单 IVF_K，就能覆盖几乎所有实际情况，而需要几十万条训练数据的配置仍超出了常规文档应用的范围。

#用数据看内存占用

一个采用 32 位浮点数的 1 024 维向量大约占用 4 KB。因此，一百万个向量大约占用 4 GB，这还没有计入索引结构本身。具体到 HNSW 索引，官方 wiki 给出的公式是每个向量占用 (d×4 + M×2×4) 字节，其中 d 是维度，M 是每个向量的链接数（介于 4 和 64 之间：链接越多，精度越高，内存占用也越大）。这笔内存账决定了大多数架构的选择：这就是需要压缩的原因，也解释了为什么同时承载语言模型的机器，其剩余内存空间比人们想象的更少。

在压缩方面，乘积量化（PQ）将每个向量编码为 M 个字节，通常最多为 64 字节——超过此值时，标量量化（SQ）通常同样精确且更快。当压缩质量至关重要时，官方指南建议在量化前添加 OPQ 变换：它首先通过线性变换降低向量的维度，使其更易于压缩，然后对结果应用乘积量化。这会在建立索引时增加一个计算步骤，但相比直接进行乘积量化，在相同编码长度下能减少精度损失。RaBitQ 是压缩程度最高的选项，仅保留每个维度的一个比特，可将每个向量的编码大小降至约 (d/8 + 8) 字节；代价是需要进行随机旋转，以保持较好的精度。也有每个维度保留多个比特的变体，可以用稍多的存储空间换回一些精度。

#那个缺失却起决定性作用的功能

实际问题往往带有条件：只查询这个客户的文档、只查询这个日期之后的内容、只查询这个人有权阅读的信息。FAISS 没有元数据的概念。常见的变通办法是先获取比所需数量更多的结果，再用 Python 过滤，但这种做法存在一个具体问题：如果排名前五十的结果全部属于另一个部门，过滤后就什么也不剩，您的助手便会声称没有找到任何信息，而不是说没有找到您有权查看的信息。

尤其要注意，权限过滤不应在检索完成之后才进行。这是选择在搜索过程中就进行过滤的系统的最有力的实际理由：可以使用向量数据库，也可以将向量存储在 PostgreSQL 中，通过 WHERE 子句实现过滤。

• pgvector：在SQL中进行搜索时过滤
• Qdrant：专用服务
• Milvus：面向大数据量的向量数据库
• 完整的 RAG 流程
• QuelLLM 本地 RAG 工具包
• 来源：GitHub 上的 FAISS 官方仓库
• 来源：官方索引选择指南
• 来源：Python 中 FAISS 快速入门示例

#何时选择 FAISS

单进程应用程序

启动时加载索引并对其进行查询，例如桌面工具、批处理程序或计算笔记本。

固定语料库

按照时间表重建，而非持续更新。

不按用户进行筛选

或者，筛选粒度足够粗，按类别分别建立索引仍是合理的做法。

对延迟要求严格的场景

当您要消除的恰好就是通过网络访问数据库所产生的往返开销时，例如在无法保证网络连接的嵌入式工具中。

除这些情况外，从长期来看，那个您原本想省去安装的服务，通常比随着项目发展而最终不得不自行重写的持久化、过滤和并发处理代码成本更低。

做决定前，还有最后一点值得了解：您在其他地方遇到的若干向量数据库，并不是凭空就能取代 FAISS；它们要么封装 FAISS，要么借鉴同类索引（IVF、HNSW、乘积量化），再通过网络 API、托管的持久化系统和过滤引擎提供服务。因此，理解 FAISS，也就理解了向量数据库自身内部运作机制的很大一部分——即使最终项目使用的是 Qdrant 或 Milvus，而不是直接使用 FAISS，花时间了解它仍然有益，因为相同的内存与精度权衡也存在于这些系统中，只是参数名称不同。

#FAQ