FAISS : la bibliothèque derrière la recherche vectorielle
FAISS est une bibliothèque de recherche par similarité sur des vecteurs denses, issue de la recherche de Meta, utilisée à l'intérieur de quantité d'outils qui ne la citent jamais. Ce n'est pas une base de données : ni serveur, ni filtrage par métadonnées, ni contrôle d'accès, ni persistance. Pour une chaîne documentaire locale mono-processus, c'est ce qu'il y a de plus léger qui fonctionne — et cela cesse d'être le bon outil dès qu'arrivent les droits d'accès ou plusieurs écrivains.
#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 : 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.
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.
#Les index qui comptent
Tes documents, ton IA : un RAG local fiable sur tes PDF, notes et mails — sans rien envoyer dans le cloud.
- Espace en ligne à vie
- PDF + fichiers
- Remboursé 30 j
| Index | Comment il cherche | Quand l'utiliser |
|---|---|---|
| Exact | Compare à tous les vecteurs | Jusqu'à quelques dizaines de milliers : résultats exacts, aucun réglage, réellement assez rapide |
| Partitions inversées | Découpe l'espace, n'explore que quelques partitions | À partir de centaines de milliers ; demande une phase d'apprentissage sur des données représentatives |
| Graphe de voisins | Navigue dans un graphe | Quand la latence prime sur le temps de construction et la mémoire |
| Quantification produit | Stocke des vecteurs compressés | Quand l'index ne tient plus en mémoire : la précision baisse, la mémoire bien davantage |
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.
#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. 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.
#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.
#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.
En dehors de ces cas, le service qu'on évite d'installer coûte en général moins cher que le code de persistance, de filtrage et de concurrence qu'on finit par écrire soi-même.
#FAQ
FAISS est-il une base de données vectorielle ?+
Combien de vecteurs peut-il gérer ?+
Peut-on filtrer les résultats par métadonnées ?+
FAISS ou une base vectorielle ?+
Par quel index commencer ?+
Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.