FAISS : la bibliothèque derrière la recherche vectorielle

#Une bibliothèque, pas une base

On compare souvent FAISS aux bases vectorielles comme s'il s'agissait d'alternatives. Ce ne sont pas les mêmes catégories. Une base vectorielle est un service avec une API, du stockage, du filtrage et des droits. FAISS est un composant : écrit en C++ avec des enveloppes complètes pour Python et NumPy, vous lui donnez des vecteurs, il construit un index en mémoire, et il répond à la question « lesquels sont les plus proches de celui-là ». Plusieurs bases vectorielles l'utilisent, ou utilisent quelque chose de semblable, en interne. Le projet est publié sous licence MIT, comptait plus de 41 000 étoiles GitHub fin septembre 2026, et ses auteurs indiquent que certaines de ses méthodes passent à l'échelle de milliards de vecteurs en mémoire principale sur un seul serveur.

La conséquence pratique est que choisir FAISS, c'est accepter de prendre en charge tout le reste : sauvegarder l'index sur disque, le recharger, le garder cohérent avec vos documents, faire le lien entre la position d'un vecteur et le texte dont il provient, et décider ce qui se passe quand deux processus veulent écrire en même temps. Rien de tout cela n'est fourni par défaut ; c'est un choix d'architecture assumé, pas un oubli du projet.

#Les index qui comptent

Le conseil qui fait gagner le plus de temps : commencer par l'exact. Les index approchés existent pour résoudre un problème d'échelle ; les adopter avant d'avoir ce problème revient à acheter des paramètres à régler et un rappel à mesurer, en échange de millisecondes que personne n'a remarquées. À l'échelle d'un corpus local, la récupération n'est presque jamais l'étape lente — c'est la génération par le modèle de langage qui domine le temps de réponse perçu par l'utilisateur final.

#Le minimum pour démarrer en Python

1. 01
   Installer la bibliothèque

   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
   Construire un index exact

   index = faiss.IndexFlatL2(dimension) crée un index de recherche exacte pour des vecteurs de la dimension de votre modèle d'embedding.
3. 03
   Ajouter les vecteurs

   index.add(vecteurs) où vecteurs est un tableau NumPy de forme (n, dimension) en flottants 32 bits.
4. 04
   Interroger

   distances, indices = index.search(requete, k) renvoie les k voisins les plus proches et leurs distances ; à vous de faire correspondre indices aux morceaux de texte d'origine.
5. 05
   Sauvegarder et recharger

   faiss.write_index(index, chemin) puis faiss.read_index(chemin) persistent l'index sur disque entre deux exécutions, puisque FAISS ne le fait pas lui-même.

#Choisir un index selon la taille du corpus

Le wiki officiel du projet publie des repères précis, exprimés comme des chaînes à passer à sa fabrique d'index (index_factory). En dessous d'un million de vecteurs, IVF_K suffit, avec K choisi entre 4×√N et 16×√N selon le nombre de vecteurs N, et un jeu d'apprentissage de 30×K à 256×K vecteurs. Entre 1 et 10 millions, la combinaison recommandée est IVF65536_HNSW32, qui utilise HNSW pour accélérer l'affectation aux clusters. Entre 10 et 100 millions, IVF262144_HNSW32 ; au-delà, jusqu'au milliard, IVF1048576_HNSW32 — à ce stade, l'apprentissage devient nettement plus lent et se fait généralement sur GPU pendant que le reste tourne sur CPU.

Pour un corpus documentaire local — quelques milliers à quelques centaines de milliers de morceaux de texte — ces repères confirment surtout qu'on est loin du seuil où l'index approché devient nécessaire : l'index exact ou, au pire, un simple IVF_K couvrent la quasi-totalité des cas réels, et les configurations à plusieurs centaines de milliers d'entrées d'apprentissage restent hors de portée d'un usage documentaire courant.

#La mémoire, chiffres en main

Un vecteur de 1 024 dimensions en flottants 32 bits occupe environ 4 Ko. Un million de vecteurs, c'est donc à peu près 4 Go, avant la structure d'index elle-même. Pour un index HNSW précisément, le wiki officiel donne la formule (d×4 + M×2×4) octets par vecteur, où d est la dimension et M le nombre de liens par vecteur (entre 4 et 64 : plus de liens, plus de précision, plus de mémoire). Cette arithmétique décide de la plupart des architectures : c'est pour cela que la compression existe, et c'est pour cela qu'une machine qui héberge aussi un modèle de langage dispose de moins de marge qu'on ne le suppose.

Côté compression, la quantification produit (PQ) code chaque vecteur sur M octets, typiquement 64 au maximum — au-delà, une quantification scalaire (SQ) est en général aussi précise et plus rapide. Quand la qualité de la compression compte vraiment, le guide officiel recommande d'ajouter une transformation OPQ avant la quantification : elle réduit d'abord la dimension du vecteur par une transformation linéaire qui le rend plus facile à compresser, puis applique la quantification produit sur le résultat. C'est une étape de plus à calculer à l'indexation, mais elle réduit la perte de précision par rapport à une quantification produit directe, à taille de code égale. RaBitQ, l'option de compression maximale, descend à environ (d/8 + 8) octets par vecteur en ne gardant qu'un bit par dimension, au prix d'une étape de rotation aléatoire nécessaire pour conserver une précision correcte ; des variantes à plusieurs bits par dimension existent pour retrouver un peu de précision contre un peu plus de stockage.

#La fonction absente qui décide de tout

Les questions réelles portent des conditions : seulement les documents de ce client, seulement après cette date, seulement ce que cette personne a le droit de lire. FAISS n'a aucune notion de métadonnées. Le contournement habituel — récupérer plus de résultats que nécessaire puis filtrer en Python — est faux d'une manière précise : si les cinquante meilleurs appartiennent tous à un autre service, le filtrage ne laisse rien, et votre assistant déclare n'avoir trouvé aucune information au lieu de dire qu'il n'en a trouvé aucune que vous puissiez voir.

Le filtrage par droits, en particulier, ne doit pas être implémenté en aval de la récupération. C'est l'argument pratique le plus fort en faveur d'un système qui filtre pendant la recherche : une base vectorielle, ou des vecteurs dans PostgreSQL où c'est une clause WHERE.

• pgvector : filtrer pendant la recherche, en SQL
• Qdrant : le service dédié
• Milvus : la base vectorielle des gros volumes
• La chaîne RAG complète
• Le kit RAG local QuelLLM
• Source : dépôt officiel FAISS sur GitHub
• Source : guide officiel de choix d'index
• Source : démarrage rapide FAISS en Python

#Quand FAISS est le bon choix

Une application mono-processus

Qui charge un index au démarrage et l'interroge : un outil de bureau, un traitement par lots, un carnet de notes.

Un corpus figé

Reconstruit selon un calendrier plutôt que mis à jour en continu.

Aucun filtrage par utilisateur

Ou un filtrage si grossier qu'un index par catégorie reste raisonnable.

Une latence critique

Quand le coût d'un aller-retour réseau vers une base est précisément ce que vous cherchez à supprimer, par exemple dans un outil embarqué sans connexion garantie.

En dehors de ces cas, le service qu'on évite d'installer coûte en général moins cher, sur la durée, que le code de persistance, de filtrage et de concurrence qu'on finit par réécrire soi-même à mesure que le projet grandit.

Un dernier repère utile avant de trancher : plusieurs bases vectorielles que vous croiserez par ailleurs ne remplacent pas FAISS par magie, elles l'enveloppent, ou s'inspirent des mêmes familles d'index (IVF, HNSW, quantification produit) derrière une API réseau, un système de persistance géré et un moteur de filtrage. Comprendre FAISS revient donc à comprendre une bonne partie du fonctionnement interne des bases vectorielles elles-mêmes — un détour utile même si le projet final utilise Qdrant ou Milvus plutôt que FAISS directement, parce que les mêmes compromis mémoire et précision s'y retrouvent sous d'autres noms de paramètres.

#FAQ