Weaviate : recherche hybride et multi-location

#Ce qui distingue Weaviate des autres bases vectorielles

Weaviate est une base de données vectorielle open source, dont le code est publié sur GitHub. Contrairement à des bibliothèques comme FAISS, c'est un serveur : il stocke les objets (texte et propriétés), les vecteurs, et l'index de recherche, et répond à des requêtes par API. Trois fonctions le distinguent d'un simple magasin de vecteurs. La première est l'encodage intégré : vous insérez des objets, un module configuré transforme le texte en vecteurs, et les requêtes s'écrivent en langage naturel plutôt qu'en tableaux de flottants. Ce choix élimine une classe de bogues (dimensions incompatibles, question encodée avec un autre modèle que le corpus), puisque le même module traite les deux côtés.

La deuxième est la recherche hybride, qui combine mots-clés et vecteurs dans une seule requête. La troisième est la multi-location : un même déploiement peut héberger plusieurs jeux de données isolés, un par client, service ou utilisateur. Le prix de ces fonctions est un composant à faire tourner, avec sa mémoire, ses sauvegardes et ses mises à jour, là où ChromaDB en mode fichier n'est qu'une bibliothèque Python.

#Garder tout en local : trois réglages à vérifier

Un module d'encodage est une dépendance qui a une localisation. Choisir un vectoriseur hébergé chez un tiers revient à expédier chacun de vos documents et chacune de vos questions ailleurs ; choisir le module Ollama garde le calcul sur votre matériel. Deux autres réglages sont moins visibles et méritent la même attention.

Le vectoriseur

Utilisez text2vec-ollama, qui appelle votre instance Ollama locale ; la documentation indique qu'il ne demande aucune clé d'API dans ce cas. Attention à l'adresse : si Weaviate tourne dans un conteneur et Ollama sur la machine hôte, la documentation recommande host.docker.internal pour que le conteneur atteigne l'hôte.

La télémétrie

La documentation de Weaviate indique qu'il collecte des données de télémétrie par défaut : version du serveur, système d'exploitation, modules utilisés, nombre d'objets et de collections, envoyés toutes les 24 heures ; elle précise qu'aucun contenu de vos données n'est collecté. Pour la désactiver, la variable est DISABLE_TELEMETRY à true. Dans une installation qui doit rester hermétique, mettez-la.

L'accès anonyme

La commande docker run de démarrage rapide règle AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED à true, et la documentation déconseille fortement l'accès anonyme hors développement ou évaluation. Dès que le port 8080 est joignable depuis autre chose que votre poste, activez l'authentification par clé d'API.

#Installer Weaviate avec Docker et Ollama

1. 01
   Avoir Ollama et un modèle d'embeddings

   Installez Ollama et récupérez le modèle avec ollama pull bge-m3.
2. 02
   Écrire le fichier docker-compose.yml

   Il déclare le conteneur Weaviate, son volume de données, l'activation du module Ollama, la télémétrie coupée et l'accès à l'hôte.
3. 03
   Démarrer et vérifier

   Lancez docker compose up -d, puis testez l'adresse http://localhost:8080/v1/meta : la réponse liste les modules actifs.
4. 04
   Créer une collection reliée au module

   La collection indique quel modèle Ollama vectorise quelles propriétés.

services:
  weaviate:
    image: cr.weaviate.io/semitechnologies/weaviate:1.39.7
    ports:
      - "8080:8080"
      - "50051:50051"
    volumes:
      - weaviate_data:/var/lib/weaviate
    restart: on-failure:0
    extra_hosts:
      - "host.docker.internal:host-gateway"   # utile sous Linux pour joindre Ollama sur l'hôte
    environment:
      QUERY_DEFAULTS_LIMIT: 25
      AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED: 'true'   # à fermer si le port est exposé
      PERSISTENCE_DATA_PATH: '/var/lib/weaviate'
      ENABLE_MODULES: 'text2vec-ollama'
      DISABLE_TELEMETRY: 'true'
      CLUSTER_HOSTNAME: 'node1'
volumes:
  weaviate_data:

Le numéro de version 1.39.7 est celui de la documentation officielle de Weaviate à la date de rédaction ; prenez la version courante indiquée sur la page d'installation. Les ports 8080 (HTTP) et 50051 (gRPC) sont ceux du démarrage rapide de la documentation.

#Le schéma : collections, propriétés, vectoriseur, tenants

import weaviate
from weaviate.classes.config import Configure, Property, DataType

client = weaviate.connect_to_local()

client.collections.create(
    "Document",
    vector_config=[
        Configure.Vectors.text2vec_ollama(
            name="contenu_vecteur",
            source_properties=["contenu"],
            api_endpoint="http://host.docker.internal:11434",
            model="bge-m3",
        )
    ],
    properties=[
        Property(name="contenu", data_type=DataType.TEXT),
        Property(name="source", data_type=DataType.TEXT),
    ],
)

coll = client.collections.use("Document")
coll.data.insert_many([
    {"contenu": "Le délai de préavis est de trois mois.", "source": "contrat.pdf"},
    {"contenu": "Le loyer est révisé chaque année au 1er janvier.", "source": "bail.pdf"},
])
client.close()

La structure suit la documentation officielle : vector_config, un vectoriseur nommé, des propriétés sources et un point d'accès Ollama. Weaviate vectorise par défaut les propriétés de type texte, triées par ordre alphabétique puis concaténées ; source_properties permet de restreindre le calcul à la propriété utile, et de laisser le nom du fichier hors du vecteur.

#La recherche hybride dans Weaviate

La recherche sémantique retrouve des passages de sens proche, et échoue sur les chaînes exactes : un numéro de facture, une référence de pièce, un code d'erreur, un nom propre. La recherche hybride de Weaviate combine les résultats d'une recherche vectorielle et d'une recherche par mots-clés BM25F en fusionnant les deux jeux de résultats, avec des poids et une méthode de fusion configurables. Le paramètre alpha règle l'équilibre : d'après la documentation, 1 correspond à une recherche vectorielle pure et 0 à une recherche par mots-clés pure. Sans alpha, le poids effectif dépend de votre client : fixez-le toujours explicitement.

coll = client.collections.use("Document")
res = coll.query.hybrid(query="préavis contrat CDI", alpha=0.5, limit=5)
for o in res.objects:
    print(o.properties["source"], o.properties["contenu"][:80])

Depuis la version 1.24, la méthode de fusion par défaut est la fusion par scores relatifs ; l'alternative est la fusion par rangs. Le principe et le choix entre les deux sont expliqués dans le guide sur la recherche hybride. Sur un corpus technique, c'est souvent la différence entre un système auquel on fait confiance et un système qu'on abandonne : les échecs du vectoriel pur portent justement sur les recherches que les utilisateurs jugent triviales.

#Multi-location : un tenant par groupe d'utilisateurs

La multi-location partitionne une collection en fragments, un par tenant. La documentation la décrit ainsi : chaque tenant est stocké dans un fragment séparé, et les données d'un tenant ne sont pas visibles d'un autre. Elle est désactivée par défaut et s'active dans la définition de la collection avec multi_tenancy_config. Si plusieurs groupes interrogent un même système (clients d'une PME, services d'une entreprise, membres d'une famille), c'est une réponse structurelle à la question « cette personne peut-elle récupérer ce document ? », bien plus sûre qu'un filtre appliqué après coup, et infiniment plus sûre qu'une consigne dans le prompt.

from weaviate.classes.config import Configure
from weaviate.classes.tenants import Tenant

client.collections.create(
    "DocumentClient",
    multi_tenancy_config=Configure.multi_tenancy(enabled=True),
)
coll = client.collections.use("DocumentClient")
coll.tenants.create([Tenant(name="client_a"), Tenant(name="client_b")])

# Toute requête passe par un tenant : les autres restent invisibles
res = coll.with_tenant("client_a").query.hybrid(query="préavis", limit=3)

Les tenants sont légers : la documentation indique qu'on peut avoir 50 000 fragments actifs ou plus par nœud. Ils ont un état (ACTIVE, INACTIVE, OFFLOADED) : un tenant inactif est sur disque et n'occupe pas de mémoire, ce qui permet d'héberger beaucoup de petits jeux de données en ne gardant actifs que ceux qui servent. Le nom d'un tenant n'accepte que des caractères alphanumériques, le tiret bas et le tiret.

#Ce que Weaviate coûte à faire tourner

Weaviate est un vrai service : un conteneur, du stockage persistant, de la mémoire proportionnelle à vos vecteurs. La documentation de dimensionnement est claire sur la contrainte : l'index HNSW doit être stocké en mémoire, la mémoire détermine la taille maximale du jeu de données, et elle n'influence pas directement la vitesse des requêtes. La règle empirique de la documentation est de compter deux fois l'empreinte mémoire de tous les vecteurs.

empreinte d'un vecteur = dimensions × 4 octets (float32)
mémoire estimée   = 2 × nombre de vecteurs × empreinte d'un vecteur

Exemple, bge-m3 (1 024 dimensions) :
  1 024 × 4 = 4 096 octets par vecteur
  100 000 passages → 2 × 100 000 × 4 096 ≈ 0,8 Go
  1 000 000 passages → 2 × 1 000 000 × 4 096 ≈ 8,2 Go

Les 1 024 dimensions de bge-m3 sont ici une hypothèse à vérifier auprès de la fiche de votre modèle. Pour un corpus personnel ou de PME (quelques dizaines de milliers de passages), la mémoire de l'index est faible ; elle devient un sujet à partir de plusieurs millions de passages. Weaviate propose la compression des vecteurs : la documentation recommande la quantification rotationnelle (RQ) et cite aussi la quantification par produit (PQ), binaire (BQ) et scalaire (SQ), au prix d'une légère perte d'information. Ajoutez le module d'encodage local : Ollama fait tourner un modèle d'embeddings sur la même machine que votre modèle de langage. Sur une machine unique, décidez lequel des deux occupe la carte graphique, ou acceptez que l'indexation et l'inférence se gênent.

#Fournir ses propres vecteurs, ou migrer depuis ChromaDB

Le module d'encodage n'est pas obligatoire. La documentation de Weaviate décrit l'approche « bring your own vectors » : au lieu de laisser la base calculer les embeddings, vous fournissez ceux que vous avez déjà, qu'ils soient personnalisés ou pré-générés. Dans le client Python, on déclare alors un vecteur nommé avec Configure.Vectors.self_provided. C'est la voie de migration la plus économique depuis ChromaDB : vous relisez les documents et les vecteurs déjà calculés (Chroma sait les renvoyer avec l'option include), puis vous les envoyez à Weaviate, sans rappeler le modèle d'embeddings. Deux vérifications évitent les mauvaises surprises : la dimension des vecteurs doit être la même sur toute la collection, et les questions doivent être encodées avec le modèle d'origine, puisque Weaviate ne le fera pas à votre place.

Quand faut-il préférer l'encodage intégré ? Si vous voulez que les requêtes s'écrivent directement en texte, que l'ajout de documents ne demande aucun code de calcul, et que la cohérence du modèle soit garantie par la configuration. Quand préférer vos propres vecteurs ? Si vous avez déjà un pipeline d'embeddings, si vous devez utiliser un modèle qu'aucun module ne propose, ou si vous voulez pouvoir changer de base vectorielle sans tout recalculer.

#Weaviate ou une autre base vectorielle

Si vous hésitez, commencez par la solution la plus simple : ChromaDB pour un prototype, puis migrez vers un service quand un besoin précis apparaît (isolation, hybride natif, volumétrie). Le choix est réversible tant que vous gardez les documents sources et le script d'indexation.

#Questions fréquentes sur Weaviate

• Recherche hybride : BM25 + vectoriel
• Qdrant : la base vectorielle d'un RAG local
• pgvector : la recherche vectorielle dans PostgreSQL
• FAISS : la bibliothèque derrière la recherche vectorielle
• RAG en local avec ChromaDB et Ollama

• Source : Weaviate, recherche hybride
• Source : Weaviate, module Ollama
• Source : Weaviate, télémétrie
• Source : Weaviate, ressources et mémoire