Weaviate lance la recherche hybride 2.0 avec 60% de performances de requête plus rapides

Annonce

Weaviate a publié Hybrid Search 2.0, une réécriture complète de leur moteur de recherche hybride qui offre des performances et une précision significativement meilleures tout en simplifiant la configuration.

Améliorations clés

Gains de performance

Comparé à Hybrid Search 1.0 :

Index unifié

v2.0 utilise un seul index unifié pour la recherche vectorielle et par mots-clés :

Ancien (v1.0) :

Index vectoriel (HNSW) + Index mots-clés (BM25) = 2 index
→ Rechercher les deux, fusionner les résultats

Nouveau (v2.0) :

Index hybride unifié = 1 index
→ Traversée unique, scoring fusionné

Bénéfices :

• 40% moins de stockage
• Requêtes plus rapides (pas de surcharge de fusion)
• Meilleure localité du cache

Fusion apprise

Remplace l'ajustement manuel d'alpha par une fusion apprise :

Ancienne approche :

DEVELOPERpython
# Manual tuning required
results = client.query.get("Document")
  .with_hybrid(query, alpha=0.7)  # Trial and error
  .do()

Nouvelle approche :

DEVELOPERpython
# Automatic learned fusion
results = client.query.get("Document")
  .with_hybrid(query, fusion_type="learned")  # No alpha needed
  .do()

Le modèle de fusion apprise s'entraîne sur les patterns de requêtes pour optimiser le scoring.

Benchmark :

• Alpha manuel : 52.3% nDCG@10
• Fusion apprise : 57.8% nDCG@10 (+10.5%)

Nouvelles fonctionnalités

Recherche hybride consciente des filtres

La recherche hybride respecte maintenant les filtres efficacement :

DEVELOPERpython
results = (
    client.query.get("Product")
    .with_hybrid("wireless headphones", fusion_type="learned")
    .with_where({
        "path": ["price"],
        "operator": "LessThan",
        "valueNumber": 200
    })
    .with_limit(10)
    .do()
)

Performance :

• v1.0 : Post-filtrage (lent)
• v2.0 : Traversée d'index consciente des filtres (60% plus rapide)

Hybride multi-vecteurs

Support pour plusieurs représentations vectorielles :

DEVELOPERpython
# Index with multiple embeddings
client.data_object.create({
    "text": "Product description...",
    "vectors": {
        "semantic": [...],  # General embedding
        "domain": [...],    # Domain-specific embedding
        "multilingual": [...] # Cross-lingual embedding
    }
})

# Query with automatic vector selection
results = client.query.get("Product")
  .with_hybrid(query, vector_name="auto")  # Selects best vector
  .do()

Explication hybride

Déboguer le scoring de recherche hybride :

DEVELOPERpython
results = (
    client.query.get("Document")
    .with_hybrid(query, explain=True)
    .do()
)

for result in results:
    print(f"Combined score: {result['_additional']['score']}")
    print(f"  BM25 score: {result['_additional']['explainScore']['bm25']}")
    print(f"  Vector score: {result['_additional']['explainScore']['vector']}")
    print(f"  Fusion weight: {result['_additional']['explainScore']['fusion']}")

Aide à comprendre pourquoi les documents se sont classés où ils l'ont fait.

Changements d'architecture

Index de fusion HNSW-BM25

Nouvelle structure d'index :

Nœuds du graphe HNSW :
  - Embedding vectoriel
  - Fréquences de termes BM25
  - Métadonnées
  - Filtres

Traversée unique :
  - Naviguer dans le graphe HNSW
  - Calculer la similarité vectorielle
  - Calculer le score BM25
  - Appliquer la fusion apprise
  - Vérifier les filtres (terminaison anticipée)

Innovation clé : Données BM25 colocalisées avec les nœuds HNSW.

Fusion dynamique

Les poids de fusion s'adaptent par requête :

DEVELOPERpython
# Query analysis
query_type = analyze(query)  # keyword-heavy vs. semantic

if query_type == "keyword-heavy":
    fusion_weights = {"bm25": 0.7, "vector": 0.3}
elif query_type == "semantic":
    fusion_weights = {"bm25": 0.3, "vector": 0.7}
else:
    fusion_weights = {"bm25": 0.5, "vector": 0.5}

# Apply dynamically
score = (
    fusion_weights["bm25"] * bm25_score +
    fusion_weights["vector"] * vector_score
)

Élimine le besoin d'ajustement manuel d'alpha.

Guide de migration

Mise à niveau depuis v1.0

DEVELOPERpython
# Old (v1.0)
results = (
    client.query.get("Document")
    .with_hybrid(query="search query", alpha=0.75)
    .with_limit(10)
    .do()
)

# New (v2.0) - minimal changes
results = (
    client.query.get("Document")
    .with_hybrid(
        query="search query",
        fusion_type="learned"  # Replace alpha
    )
    .with_limit(10)
    .do()
)

Réindexation

v2.0 nécessite une réindexation :

DEVELOPERbash
# Export data
weaviate export --collection Documents --output backup.json

# Upgrade Weaviate
docker pull semitechnologies/weaviate:1.25.0

# Reimport (automatically uses new index)
weaviate import --collection Documents --input backup.json

Temps d'arrêt : ~2 heures pour 10M de documents

Benchmarks

Benchmark BEIR

Testé sur le benchmark de récupération BEIR :

Amélioration moyenne : +6.8% par rapport à v1.0

Performance réelle

Rapport client (10M de documents) :

Latence :

• p50 : 34ms (était 85ms)
• p95 : 78ms (était 240ms)
• p99 : 145ms (était 580ms)

Débit :

• Nœud unique : 3,500 q/s (était 1,200 q/s)
• Cluster 3 nœuds : 9,800 q/s (était 3,100 q/s)

Coût :

• Même infrastructure gère 3x le trafic
• Réduction de coût de 66% par requête

Bonnes pratiques

Sélection du type de fusion

DEVELOPERpython
# Use learned fusion (default)
.with_hybrid(query, fusion_type="learned")

# Use relative score (for specific use cases)
.with_hybrid(query, fusion_type="relative_score", alpha=0.7)

# Use RRF (rank-based fusion)
.with_hybrid(query, fusion_type="rrf")

Recommandation : Commencer avec la fusion apprise.

Optimisation des filtres

DEVELOPERpython
# Good: Selective filters first
.with_where({
    "operator": "And",
    "operands": [
        {"path": ["category"], "operator": "Equal", "valueString": "electronics"},
        {"path": ["price"], "operator": "LessThan", "valueNumber": 200}
    ]
})

# Bad: Non-selective filters first (slower)

Sélection de vecteur

DEVELOPERpython
# Let Weaviate choose
.with_hybrid(query, vector_name="auto")

# Or specify explicitly
.with_hybrid(query, vector_name="semantic")

Disponibilité

• Weaviate 1.25+ (publié en octobre 2025)
• Weaviate Cloud Services (WCS) - mis à niveau automatiquement
• Auto-hébergé - mise à niveau disponible

Limitations

Réindexation requise

• Impossible de mettre à niveau sur place
• Doit reconstruire les index
• Prévoir un temps d'arrêt

Utilisation mémoire

• L'index unifié utilise 15% de RAM en plus (mais moins de disque)
• Les bénéfices l'emportent sur les coûts pour la plupart des cas d'usage

Période d'apprentissage

• La fusion apprise nécessite ~1000 requêtes pour s'optimiser
• Se rabat sur des heuristiques jusqu'à l'entraînement

Feuille de route future

Prévu pour 2026 :

• Recherche hybride multi-modale (texte + images)
• BM25 sémantique (pondération contextuelle des termes)
• Recherche hybride augmentée par graphe
• Mises à jour du modèle de fusion en temps réel

Ressources

• Documentation : weaviate.io/developers/hybrid-search-v2
• Guide de migration : weaviate.io/developers/migration/v2
• Benchmarks : weaviate.io/benchmarks/hybrid-search

Conclusion

Hybrid Search 2.0 de Weaviate représente un bond significatif dans la technologie de récupération, combinant des améliorations de performance avec une meilleure précision grâce à la fusion apprise. L'architecture d'index unifié établit une nouvelle norme pour la recherche hybride dans les bases de données vectorielles, en faisant un excellent choix pour les applications RAG en production.