Weaviate : Guide Complet de la Base de Données Vectorielle Open Source

Qu’est-ce que Weaviate et comment fonctionne-t-il ?

Weaviate est une base de données vectorielle open-source (licence Apache 2.0) conçue par une start-up néerlandaise pour la recherche sémantique à grande échelle. Elle stocke à la fois vos objets de données et leurs vecteurs d’incorporation, permettant des recherches rapides sur des milliards de vecteurs. Son adoption est massive : plus de 20 millions de téléchargements open-source témoignent de sa maturité.

Plutôt qu’une recherche par mots-clés, Weaviate comprend le sens de vos requêtes grâce aux embeddings, un choix qui fait écho aux comparatifs d’embeddings 2026 pour le RAG. Son moteur intègre l’algorithme HNSW par défaut, offrant une complexité de recherche en O(log n) et un rappel typique de 95 à 99 %, avec une latence recommandée sous 100 ms pour une expérience utilisateur fluide. Son architecture supporte le multi-tenancy et le sharding pour une évolutivité horizontale, une approche comparable aux plateformes e-learning open source qui doivent absorber des pics d’affluence.

Concrètement, l’outil excelle dans les cas d’usage comme le RAG, les chatbots et la recherche multimodale en ecommerce. Il se positionne comme une alternative crédible aux solutions propriétaires, avec un modèle auto-hébergeable gratuit qui concurrence directement des services comme Pinecone ou Qdrant, à l’image des alternatives open source à Notion qui séduisent les équipes en quête de souveraineté numérique.

Fonctionnalités clés de Weaviate

Moteur de recherche : vectorielle, hybride et générative

Le cœur de Weaviate repose sur un moteur de recherche à trois vitesses. La recherche vectorielle pure exploite des index HNSW pour retrouver des résultats sémantiquement proches en quelques millisecondes, même sur des collections massives. La recherche hybride combine cette approche avec la recherche par mots-clés (BM25) : elle fusionne les deux classements pour offrir un rappel supérieur, notamment sur des corpus techniques où la terminologie exacte prime. Enfin, la recherche générative intègre directement des modules LLM dans le pipeline : elle rédige des réponses synthétiques à partir des objets récupérés, ce qui est idéal pour construire un moteur de RAG sans bricoler une chaîne d’outils séparée, une souplesse qui rappelle le paramétrage d’un modèle open source par fine-tuning.

Architecture multi-tenant et évolutivité

Pensée pour les applications SaaS, l’architecture multi-tenant de Weaviate garantit une isolation stricte des données. Chaque tenant possède son propre espace de stockage et de calcul, ce qui empêche les fuites d’information entre clients, tout en simplifiant la gestion des quotas. Cette conception s’appuie sur plusieurs mécanismes complémentaires, à l’instar des concepts de base de Kubernetes pour orchestrer des charges distribuées:

• Isolation des données par tenant : les index et les données sont cloisonnés, seuls les administrateurs peuvent les croiser.
• Named vectors : multiples embeddings par collection : une même collection peut stocker plusieurs représentations vectorielles (texte, image, audio) pour des recherches multimodales fines.
• Sharding pour évolutivité horizontale : les données sont réparties automatiquement sur plusieurs nœuds, permettant de passer à l’échelle sans interruption de service.
• Indexation asynchrone disponible en expérimental : pour les charges d’écriture massives, cette option découple l’ingestion de la disponibilité de recherche, réduisant la latence d’écriture.

Cette base s’appuie sur le sharding : les données sont distribuées sur plusieurs nœuds, ce qui permet de gérer des volumes de l’ordre de 4B d’index HNSW en mémoire pour des vecteurs float32, avec une limite par défaut de 1e12 vecteurs par collection. Pour les applications exigeant une latence inférieure à 100 ms, cette architecture horizontale est un gage de stabilité, même lors des pics de trafic.

Cette distribution sur plusieurs nœuds nécessite une coordination fiable entre les serveurs, un rôle souvent assuré par un courtier de messages comme RabbitMQ pour synchroniser les mises à jour et les requêtes.

Weaviate vs Pinecone, Qdrant et Milvus

Choisir selon l’échelle et le niveau de contrôle

Le choix entre ces quatre bases dépend principalement de deux facteurs : l’échelle de vos données et votre besoin de contrôle. Weaviate et Qdrant couvrent une échelle moyenne idéale de 1 à 100 millions de vecteurs, avec des performances similaires en production auto-hébergée.

Pour des volumes massifs dépassant 100 millions de vecteurs, Milvus est souvent privilégié. Pinecone se distingue comme solution 100 % gérée, sans infrastructure à maintenir, mais son coût peut devenir élevé à grande échelle. À l’inverse, Weaviate et Qdrant offrent une flexibilité totale avec leur licence open source, tout en proposant un cloud managé dès 25 $/mois pour ceux qui préfèrent déléguer l’opération.

Pour la plupart des projets SaaS et des cas d’usage RAG, Weaviate constitue une alternative crédible aux bases propriétaires, combinant la richesse fonctionnelle d’une solution gérée avec la liberté d’un déploiement open source gratuit.

L’avantage hybride de Weaviate

Un point de différenciation majeur réside dans la recherche hybride. Weaviate permet de combiner la recherche vectorielle avec des filtres et la recherche par mots-clés (BM25) dans une seule requête. Cette approche hybride offre un meilleur contrôle des résultats et améliore la pertinence, là où certaines alternatives se limitent à la similarité vectorielle pure.

De plus, Weaviate intègre nativement des modules pour la génération augmentée (RAG), ce qui simplifie l’architecture de vos applications d’IA. L’écosystème et les 28 510 commits sur le dépôt GitHub témoignent d’un projet actif et soutenu par une communauté dynamique.

Cas d’usage concrets : RAG, chatbots et ecommerce

Le RAG (Retrieval-Augmented Generation) est l’usage roi de Weaviate : la base retrouve les documents pertinents en moins de 100ms, puis un LLM génère une réponse sourcée. Cette mécanique élimine les hallucinations et transforme une base de connaissances interne en assistant IA fiable, sans réentraîner de modèle.

Pour les chatbots, la recherche hybride de Weaviate combine la similarité vectorielle et la correspondance par mots-clés. Résultat : des réponses précises même sur des requêtes ambiguës, avec une latence adaptée au dialogue temps réel. Les équipes produits déploient aussi des boucles de rétroaction génératives (GFL) où les réponses du bot enrichissent automatiquement la base.

Côté ecommerce, Weaviate propulse la recherche multimodale : un client cherche « baskets rouges montantes » et obtient des résultats visuels et textuels pertinents en une requête. Les systèmes de recommandations exploitent les vecteurs produits pour suggérer des articles similaires, tandis que les startups SaaS l’utilisent comme backend vectoriel pour analyser les interactions utilisateurs et automatiser leurs campagnes marketing.

Indexation vectorielle : comprendre HNSW et les alternatives

Pour garantir des recherches rapides et pertinentes, Weaviate s’appuie sur des algorithmes d’indexation vectorielle. Le choix de l’index est crucial : il détermine directement la latence, la mémoire utilisée et la qualité des résultats.

– HNSW : algorithme par défaut C’est l’index de référence sur les gros volumes. Il est basé sur un graphe multi-couches, avec une complexité de recherche en O(log n).
– Index Flat Une recherche exhaustive (complexité O(n×d)) qui convient aux petits ensembles isolés, par exemple une collection par tenant avec moins de 10K vecteurs.
– HFresh Un index cluster-based de type SPFresh, pensé pour équilibrer les écritures et les lectures à grande échelle.
– Index dynamiques Disponibles en version expérimentale depuis v1.25, ils permettent une indexation asynchrone avec la variable ASYNC_INDEXING.

Paramètres clés de l’index HNSW

La qualité et la vitesse de l’index HNSW se règlent via trois paramètres accessibles dans la configuration du schéma. Leur ajustement est un compromis entre latence et rappel (précision).

– M (8-64) Nombre de connexions maximal par nœud du graphe. Une valeur plus élevée améliore la qualité mais augmente la consommation mémoire.
– ef_construction (64-512) Taille de la liste dynamique lors de la construction de l’index. Il influe sur la qualité de l’index final et le temps de création.
– ef (32-512) Taille de la liste de candidats lors de la recherche. Augmenter ce paramètre améliore le rappel (généralement entre 95-99%) mais augmente la latence.

Un rappel typique de 95-99% est attendu avec ces réglages, avec une latence de requête recommandée sous 100ms pour une bonne expérience utilisateur. Pour des bases très denses au-delà de 1M de vecteurs, certains déploient des bases dédiées pour atteindre une latence sous 10ms. À noter : la limite par défaut est de 1e12 vecteurs en mémoire par collection, avec une taille d’index HNSW pouvant atteindre 4B pour des vecteurs float32.

Installation et démarrage rapide avec Docker

Installation via Docker Compose en 5 minutes

La méthode la plus simple pour tester Weaviate consiste à utiliser Docker Compose. Un fichier de configuration minimal suffit pour lancer une instance locale complète, sans installation préalable d’un langage ou d’un serveur dédié.

• docker-compose.yml : définit le service weaviate avec l’image officielle et les variables d’environnement essentielles (ports, authentification désactivée).
• docker compose up -d : lance le conteneur et télécharge l’image si nécessaire, en moins de 5 minutes.
• Statut Ready : le serveur signale son état via l’endpoint /v1/.well-known/ready; attendez la réponse HTTP 200 avant toute requête.
• API REST locale : accessible sur http://localhost:8080; une interface GraphQL est également disponible sur le même port.

Une fois le conteneur opérationnel, vous disposez d’une base vectorielle prête à recevoir des données. L’API REST permet de créer des collections, d’insérer des objets et d’interroger les vecteurs, tandis que le support de GraphQL offre une alternative expressive pour les recherches complexes. La configuration via Docker est identique en production, ce qui facilite la transition de l’environnement de test vers un déploiement auto-hébergé.

Premier projet Python : créer un schéma et indexer des vecteurs

Pour interagir avec Weaviate depuis Python, le client officiel (weaviate-client) encapsule les appels REST et gère les connexions. L’installation se fait via pip, puis la connexion à l’instance locale s’établit en une seule ligne. Le schéma définit la structure des collections, avec le nom, les propriétés (texte, numérique) et le module de vectorisation à utiliser. Après la création du schéma, l’indexation des vecteurs s’effectue par lots, chaque objet étant associé à son embedding.

L’exemple ci-dessous illustre les étapes fondamentales : création d’une collection Document, insertion de deux objets avec leurs vecteurs, puis une recherche par similarité avec la méthode query.near_vector. Les réponses incluent les scores de distance, utilisables pour évaluer la pertinence. Le seuil de 1 million de vecteurs est un repère courant pour basculer d’une solution généraliste à une base vectorielle dédiée; Weaviate gère au-delà de 100 millions de vecteurs avec une latence inférieure à 100 ms, ce qui en fait un choix adapté dès les premiers millions d’objets.

Déploiement : Cloud Weaviate vs auto-hébergement open source

Le choix entre Weaviate Cloud (WCS) et l’auto-hébergement dépend de vos ressources. Le SaaS démarre à 25 $/mois et inclut une instance gérée, préconfigurée avec la dernière version. L’auto-hébergement, lui, reste gratuit via Docker ou Kubernetes, sur AWS, GCP ou un VPC dédié.

Les fonctionnalités sont strictement identiques entre les deux options. Seules la configuration, l’hébergement et la maintenance diffèrent. Pour un prototype ou un volume inférieur à 1 million de vecteurs, l’open source suffit largement. Pour une production critique avec des exigences de latence <10ms, le cloud managé simplifie la gestion et la scalabilité.

Cette coordination est d’autant plus cruciale lorsque les modèles d’embedding sont entraînés avec peu de données, une approche qui gagne en popularité pour les cas d’usage spécialisés.

Cette coordination s’appuie sur une observabilité fine des échanges, ce que permet une définition claire d’opentelemetry pour standardiser la collecte de métriques et de traces.