Accueil › Glossaire › FAISS

FAISS (Facebook AI Similarity Search)

FAISS est une librairie open source (licence MIT) développée par Meta AI Research pour la recherche par similarité et le clustering de vecteurs denses à grande échelle, avec des implémentations CPU et GPU optimisées capables de traiter des milliards de vecteurs.

FAISS n’est pas une base de données vectorielle. C’est une librairie de calcul : un ensemble d’algorithmes d’indexation et de recherche vectorielle que vous intégrez directement dans votre code Python ou C++. Il n’a pas de serveur, pas d’API REST, pas de persistence native, pas de filtrage par métadonnées. Ce qu’il fait, il le fait mieux que presque tous les concurrents : trouver les K vecteurs les plus proches dans un ensemble de milliards de vecteurs, avec des optimisations CPU (SIMD, multithreading) et GPU (CUDA, ROCm) de pointe. Meta l’utilise en interne pour indexer 1,5 billion de vecteurs de 144 dimensions.

FAISS n’est pas un vector store

C’est la distinction la plus importante à comprendre. Un vector store (Pinecone, Qdrant, Weaviate, Milvus) est une base de données complète : elle gère la persistence, les métadonnées, le filtrage, les opérations CRUD (ajout, mise à jour, suppression), la réplication et souvent un serveur HTTP/gRPC.

FAISS est une librairie in-process : elle s’exécute dans votre programme Python, stocke les index en mémoire (RAM ou GPU), et n’offre ni persistence native, ni filtrage par métadonnées, ni serveur. Pour sauvegarder un index, vous le sérialisez sur disque (faiss.write_index()). Pour le recharger, vous le lisez en mémoire (faiss.read_index()).

Cette simplicité est aussi sa force : aucune latence réseau, aucune sérialisation, aucun overhead de serveur. Pour les recherches batch en mémoire (offline, entraînement ML, deduplication de datasets), FAISS est souvent plus rapide que n’importe quel vector store car il élimine toutes les couches intermédiaires.

Les types d’index FAISS

FAISS propose une gamme d’index qui couvrent tout le spectre du compromis vitesse/précision/mémoire :

IndexFlat (recherche exacte)

IndexFlatL2 et IndexFlatIP (Inner Product) calculent la distance entre le vecteur de requête et chaque vecteur de l’index par force brute. C’est la recherche exacte, le gold standard en termes de précision (recall = 100 %), mais la plus lente. Utilisez-le comme référence pour évaluer la qualité des index approximatifs, ou pour des collections de moins de ~50 000 vecteurs où la force brute reste rapide.

IndexIVF (cellules de Voronoi)

IndexIVFFlat partitionne l’espace vectoriel en cellules de Voronoi via k-means. À la recherche, seules les cellules les plus proches de la requête sont explorées (paramètre nprobe). Cela réduit considérablement le nombre de comparaisons. Plus nprobe est élevé, plus le recall est bon mais plus la recherche est lente. L’index doit être entraîné (train()) sur un échantillon de données avant utilisation.

IndexIVFPQ (quantization produit)

IndexIVFPQ combine IVF avec la Product Quantization (PQ) : les vecteurs sont compressés en sous-vecteurs quantifiés, réduisant la mémoire de 4 à 64x. Le calcul de distance se fait sur les codes compressés, ce qui accélère la recherche. C’est l’index le plus utilisé pour les milliards de vecteurs où la mémoire est la contrainte principale.

IndexHNSW (graphe navigable)

IndexHNSWFlat construit un graphe multi-couches HNSW (Hierarchical Navigable Small World). C’est l’algorithme d’indexation le plus populaire en 2026 car il offre le meilleur ratio recall/latence. Les paramètres M (nombre de connexions par nœud) et efConstruction (profondeur de construction) contrôlent le compromis mémoire/qualité. L’index HNSW est aussi disponible sur GPU.

Index composites (factory string)

FAISS permet de combiner des index via une notation « factory string » : "IVF4096,PQ64" crée un IVF avec 4096 cellules et PQ avec 64 sous-quantificateurs. "OPQ64,IVF4096,PQ64" ajoute une rotation optimisée en prétraitement. Cette composabilité permet de construire des index sur mesure pour chaque cas d’usage.

Utilisation concrète

import faiss
import numpy as np

# 1. Générer des données (1M vecteurs de 128 dimensions)
d = 128  # Dimensionnalité
nb = 1_000_000  # Nombre de vecteurs
nq = 100  # Nombre de requêtes

np.random.seed(42)
xb = np.random.random((nb, d)).astype('float32')  # Base de données
xq = np.random.random((nq, d)).astype('float32')  # Requêtes

# 2. Index exact (force brute) : recall = 100%
index_flat = faiss.IndexFlatL2(d)
index_flat.add(xb)
D, I = index_flat.search(xq, k=5)  # 5 plus proches voisins
# D = distances, I = indices des voisins

# 3. Index IVF : recherche approchée, plus rapide
nlist = 1024  # Nombre de cellules
quantizer = faiss.IndexFlatL2(d)
index_ivf = faiss.IndexIVFFlat(quantizer, d, nlist)
index_ivf.train(xb)  # Entraîner le quantizer
index_ivf.add(xb)
index_ivf.nprobe = 16  # Explorer 16 cellules (compromis vitesse/recall)
D, I = index_ivf.search(xq, k=5)

# 4. Index HNSW : meilleur ratio recall/latence
index_hnsw = faiss.IndexHNSWFlat(d, 32)  # M=32 connexions par nœud
index_hnsw.add(xb)
D, I = index_hnsw.search(xq, k=5)

# 5. Sauvegarder et recharger un index
faiss.write_index(index_hnsw, "my_index.faiss")
index_loaded = faiss.read_index("my_index.faiss")

# Utilisation GPU (CUDA) pour une accélération 5-10x
import faiss

# Transférer un index CPU vers GPU
gpu_res = faiss.StandardGpuResources()
index_cpu = faiss.IndexFlatL2(128)
index_cpu.add(xb)

# Single GPU
index_gpu = faiss.index_cpu_to_gpu(gpu_res, 0, index_cpu)  # GPU 0
D, I = index_gpu.search(xq, k=5)  # Recherche sur GPU

# Multi-GPU (tous les GPU disponibles)
index_multi_gpu = faiss.index_cpu_to_all_gpus(index_cpu)
D, I = index_multi_gpu.search(xq, k=5)

# Index composé via factory string
# IVF avec 4096 cellules + PQ 64 sous-quantificateurs
index = faiss.index_factory(128, "IVF4096,PQ64")
index.train(xb)
index.add(xb)
D, I = index.search(xq, k=5)

# Avec rotation OPQ pour améliorer la qualité PQ
index = faiss.index_factory(128, "OPQ64,IVF4096,PQ64")
index.train(xb)
index.add(xb)

Accélération GPU

FAISS offre des implémentations GPU de pointe via NVIDIA CUDA (et optionnellement AMD ROCm et NVIDIA cuVS). Sur un seul GPU, les recherches sont 5 à 10 fois plus rapides que sur CPU. Le support multi-GPU permet de distribuer un index sur plusieurs cartes pour scaler linéairement.

L’API GPU est un « drop-in replacement » : vous remplacez IndexFlatL2 par GpuIndexFlatL2, ou vous utilisez index_cpu_to_gpu() pour transférer un index CPU existant. Les transferts mémoire CPU/GPU sont gérés automatiquement. Pour les performances maximales, gardez les données et les requêtes en mémoire GPU.

Les opérations GPU disponibles incluent : la recherche exacte (brute-force), IVF, PQ, HNSW (via cuVS CAGRA), et le clustering k-means. La construction d’un index IVF sur 67 millions de vecteurs de 120 dimensions avec 262 144 centroïdes prend 44 minutes sur 8 GPU P100.

Cas d’usage de FAISS

Recherche batch offline

C’est le cas d’usage naturel de FAISS. Vous avez un dataset de millions de vecteurs et vous devez trouver les K plus proches voisins pour chaque vecteur (k-NN graph), deduplicater un dataset, ou calculer des features de similarité pour un modèle ML. FAISS traite ces opérations en batch, en mémoire, sans overhead réseau, ce qui en fait l’outil le plus rapide pour ces tâches.

Moteur interne de vector stores

Plusieurs vector stores utilisent FAISS comme moteur de recherche interne. OpenSearch intègre FAISS pour ses capacités de k-NN search. Milvus et Vearch utilisent des algorithmes dérivés de FAISS. Quand vous utilisez ces systèmes, vous bénéficiez indirectement des optimisations de FAISS.

Prototypage RAG

Pour un prototype RAG rapide sans infrastructure supplémentaire, FAISS avec LangChain est une option simple. LangChain propose un wrapper FAISS natif qui ajoute une couche de persistence et de filtrage par dessus la librairie. Cependant, pour la production, un vrai vector store (pgvector, Qdrant, ChromaDB) est plus adapté car il gère la persistence, les mises à jour et le multi-client nativement.

Clustering à grande échelle

FAISS inclut des implémentations de k-means optimisées pour le GPU, capables de clusterer des milliards de vecteurs. C’est utilisé pour la quantization d’embeddings, la construction de vocabulaires visuels, et la segmentation de datasets massifs.

Deduplication de données

En construisant un k-NN graph avec FAISS, vous identifiez les vecteurs quasi-identiques dans un dataset (near-duplicates). C’est utilisé pour nettoyer les datasets d’entraînement ML (supprimer les images dupliquées, les textes quasi-identiques) et pour la modération de contenu (détecter les reposts).

Forces et limites

Points forts

Performance brute maximale. Pas de serveur, pas de réseau, pas de sérialisation. La recherche s’exécute directement en mémoire dans votre processus. Pour les opérations batch, rien n’est plus rapide.

Accélération GPU de pointe. 5 à 10x plus rapide qu’en CPU, avec support multi-GPU natif. C’est l’implémentation GPU la plus mature et la plus optimisée du marché.

Composabilité des index. La notation factory string permet de construire des index sur mesure en combinant quantization, partitionnement et rotation. Cette flexibilité est unique.

Maturité et adoption. Développé par Meta AI depuis 2015, FAISS est utilisé en production à l’échelle de 1,5 billion de vecteurs en interne chez Meta. C’est la référence en matière de benchmarks de recherche vectorielle.

Licence MIT. La licence la plus permissive possible. Aucune restriction d’usage, même commercial.

Limites

Pas un système de stockage. Pas de persistence intégrée, pas de métadonnées, pas de filtrage, pas de CRUD complet. Pour une application interactive qui a besoin de mises à jour et de filtrage, utilisez un vector store.

Pas de serveur. FAISS s’exécute dans votre processus. Pour un accès multi-client ou un déploiement distribué, vous devez construire un service autour (ce que font Milvus, OpenSearch, etc.).

Mémoire. Les index FAISS vivent en RAM (ou GPU RAM). Pour les très gros volumes qui dépassent la RAM, vous devez utiliser des index on-disk (IVF avec mmap) ou des vector stores qui gèrent le tiering automatiquement.

Courbe d’apprentissage. Le choix et le tuning des index (IVF vs HNSW vs PQ, paramètres nlist/nprobe/M/efSearch) nécessitent une compréhension des algorithmes sous-jacents. FAISS est un outil pour les ingénieurs, pas un produit clé-en-main.

FAISS vs alternatives

Verdict

FAISS est la librairie de recherche vectorielle la plus performante et la plus mature du marché. Sa combinaison d’algorithmes d’indexation avancés (IVF, PQ, HNSW), d’optimisations CPU (SIMD, multithreading) et GPU (CUDA multi-GPU), et de composabilité (factory strings) en fait l’outil de référence pour la recherche vectorielle à grande échelle.

Mais FAISS n’est pas un produit utilisable en production tel quel pour une application web. C’est un moteur de calcul que vous devez intégrer dans votre propre infrastructure. Pour la plupart des développeurs qui construisent des applications RAG ou de recherche sémantique, un vector store comme Qdrant, pgvector ou Pinecone est un meilleur choix car il gère la persistence, les métadonnées, le filtrage et le service HTTP nativement.

Utilisez FAISS pour les cas où la performance brute en mémoire est la priorité : recherche batch, clustering GPU, deduplication, ou comme moteur interne d’un système de recherche custom. Pour tout le reste, utilisez un vector store qui a déjà résolu les problèmes d’infrastructure pour vous.