Milvus : la base vectorielle des gros volumes

#Ce que Milvus vise

La plupart des bases vectorielles visent le projet d'équipe. Milvus vise l'échelle industrielle : séparation du stockage et du calcul, montée en charge horizontale native sur Kubernetes, et un catalogue d'index qui laisse arbitrer finement entre précision, mémoire et vitesse. Le projet revendique la capacité à traiter des dizaines de milliers de requêtes sur des milliards de vecteurs tout en gardant les données à jour via des mises à jour en flux en temps réel. C'est un choix d'architecture, pas un simple ensemble de fonctions.

Cette ambition a un revers direct : sur un corpus de cinquante mille passages, cette puissance ne se voit pas, et la complexité, elle, se voit tout de suite. La question à se poser n'est donc pas « est-ce la meilleure base vectorielle » mais « mon corpus atteindra-t-il la taille où ces choix comptent ».

Le projet se présente comme la base de confiance de développeurs IA pour construire des applications de recherche texte et image, de génération augmentée par récupération et de systèmes de recommandation, et revendique alimenter de nombreuses entreprises pour des usages jugés critiques. Ce positionnement éclaire le public visé : des équipes qui construisent un produit destiné à grandir, pas un script personnel de recherche documentaire sur quelques centaines de fichiers PDF.

#Une architecture en composants

En déploiement complet, Milvus n'est pas un processus mais un ensemble : des nœuds de requête, des nœuds de données, un service de coordination, un stockage objet, un journal de messages. Chaque partie se dimensionne indépendamment — le projet met en avant la possibilité d'augmenter séparément les nœuds de requête pour une charge de lecture intense et les nœuds de données pour une charge d'écriture intense — ce qui est exactement ce qu'on veut à grande échelle et exactement ce dont on se passe sur un poste de travail. Les microservices sans état sur Kubernetes permettent aussi une reprise rapide après incident, et la prise en charge de réplicas améliore encore la tolérance aux pannes en chargeant les segments de données sur plusieurs nœuds de requête. Cette séparation entre calcul et stockage est précisément ce qui distingue une base pensée pour l'échelle industrielle d'une base pensée pour un service unique : elle a un coût d'exploitation permanent, même quand le trafic reste faible, ce que peu de comparatifs mentionnent avant le déploiement.

#Le minimum en Python, avec Milvus Lite

1. 01
   Se connecter

   from pymilvus import MilvusClient puis client = MilvusClient("milvus_demo.db") ouvre une base locale dans un fichier ; remplacer l'argument par une URI de serveur bascule sur un déploiement complet sans changer le reste du code.
2. 02
   Créer une collection

   client.create_collection(collection_name="demo_collection", dimension=1024) — la dimension doit correspondre exactement à celle de votre modèle d'embedding.
3. 03
   Insérer les données

   res = client.insert(collection_name="demo_collection", data=data) où data est une liste de dictionnaires portant chacun un vecteur et ses métadonnées.
4. 04
   Chercher

   res = client.search(collection_name="demo_collection", data=vecteurs_requete, limit=5, output_fields=["text"]) renvoie les cinq passages les plus proches avec les champs demandés.

Le projet met en avant son intégration avec les outils d'IA courants — LangChain, LlamaIndex, OpenAI, Hugging Face — ce qui en fait, selon ses auteurs, un magasin vectoriel adapté à la génération augmentée par récupération. Milvus fonctionne avec des modèles d'embedding aussi bien open source qu'à travers des services d'embedding, sur du texte, de l'image et de la vidéo, et fournit un utilitaire (pymilvus[model]) pour transformer des données non structurées en vecteurs sans écrire soi-même le code d'appel au modèle, ni gérer séparément la bibliothèque cliente de chaque fournisseur.

#Les index, et lequel prendre

Sur un corpus documentaire local, retenir un seul chiffre suffit la plupart du temps : en dessous du million de vecteurs, la différence entre les six familles d'index se mesure en millisecondes, pas en minutes, et l'énergie dépensée à choisir le bon réglage gagnerait presque toujours à être investie ailleurs dans le projet.

Le conseil qui fait gagner le plus de temps reste le même partout : commencer par l'exact. Les index approchés résolvent un problème d'échelle, et les adopter avant d'avoir ce problème achète des paramètres à régler et un rappel à mesurer, en échange de millisecondes que personne n'a remarquées. Milvus documente explicitement ces six familles — HNSW, IVF, FLAT, SCANN, DiskANN, et des variantes quantifiées — comme optimisées chacune pour un scénario différent, avec un support matériel GPU via CAGRA de NVIDIA pour l'indexation des très gros volumes. Le projet ajoute à ces index un filtrage par métadonnées et une recherche par plage optimisés au même niveau que la recherche vectorielle elle-même, plutôt qu'implémentés comme une couche séparée qui ralentirait le résultat final.

#Ce qui distingue Milvus à grande échelle

Au-delà des index, plusieurs fonctionnalités expliquent pourquoi de grandes organisations choisissent Milvus plutôt qu'une alternative plus simple. Le multi-tenant s'y règle à quatre niveaux d'isolation possibles — base de données, collection, partition, ou clé de partition — ce qui permet à un seul cluster de servir de quelques dizaines à des millions de locataires sans perdre en performance de recherche ni en finesse de contrôle d'accès. Le stockage à chaud et à froid range les données fréquemment consultées en mémoire ou sur SSD, et relègue les données rarement consultées sur un stockage plus lent et moins coûteux, ce qui réduit la facture sans sacrifier la performance des tâches critiques.

Côté recherche, Milvus prend nativement en charge la recherche plein texte avec BM25 ainsi que des embeddings creux appris comme SPLADE et BGE-M3, en plus de la recherche sémantique par vecteurs denses. Vecteurs creux et denses peuvent cohabiter dans une même collection, avec des fonctions de réordonnancement (reranking) pour fusionner les résultats de plusieurs requêtes — une recherche hybride comparable dans l'esprit à ce que propose Qdrant, mais construite ici autour de BM25 plutôt que d'une fusion générique de scores. Sur la sécurité, le projet met en avant l'authentification obligatoire, le chiffrement TLS des communications et un contrôle d'accès par rôle (RBAC), trois éléments attendus dès qu'une base sert plusieurs applications ou plusieurs équipes, et beaucoup moins critiques pour une instance qui n'écoute que sur localhost.

#En local : ce que ça implique

Ressources

Le déploiement complet réclame plusieurs conteneurs et plusieurs gigaoctets de mémoire vive, avant même votre modèle de langage : service de coordination, nœuds de requête, nœuds de données, stockage objet et journal de messages tournent chacun séparément.

Mémoire des vecteurs

Environ 4 Ko par vecteur de 1 024 dimensions en pleine précision, hors index. C'est cette arithmétique qui décide de l'architecture, pas les fonctionnalités — et elle reste vraie que vous passiez par Milvus, Qdrant ou pgvector.

Exploitation

Sauvegardes, montées de version, surveillance : une vraie base de données distribuée demande un vrai exploitant. L'écosystème Milvus inclut Attu, une interface graphique d'administration, et Birdwatcher pour le débogage système, deux outils qui supposent malgré tout de connaître l'architecture sous-jacente.

Le GPU reste au modèle

L'encodage des documents et l'inférence se disputent déjà la carte ; la recherche vectorielle, elle, est surtout affaire de processeur et de mémoire, sauf construction d'index GPU explicitement activée via CAGRA sur les très gros volumes.

#Quand Milvus est le bon choix

La bonne question n'est jamais « quelle base a le plus de fonctionnalités » mais « lesquelles de ces fonctionnalités mon projet exploitera-t-il réellement ». Le multi-tenant à quatre niveaux, le stockage à chaud et à froid, le RBAC et la recherche hybride BM25 existent pour des organisations qui servent des milliers d'utilisateurs avec des exigences de conformité ; sur un poste personnel ou pour l'outillage interne d'une petite équipe, ces mécanismes restent inactifs pendant que leur complexité de configuration, elle, reste bien présente. Milvus se justifie quand la trajectoire du projet — pas son état actuel — pointe vers ces besoins dans un horizon raisonnable.

• Qdrant : le service dédié plus simple à exploiter
• pgvector : rester dans PostgreSQL
• FAISS : la bibliothèque plutôt que le service
• La chaîne RAG complète en Python
• Le kit RAG local QuelLLM
• Source : dépôt officiel Milvus sur GitHub
• Source : documentation officielle de Milvus Lite
• Source : aperçu de l'architecture distribuée Milvus

#FAQ