Elasticsearch était formidable, mais les bases de données vectorielles sont l’avenir
Cet article a été initialement publié sur The New Stack et est republié ici avec autorisation.
Pendant des décennies, la correspondance par mots-clés, également connue sous le nom de recherche en texte intégral, illustrée par Elasticsearch, a été le choix par défaut pour les systèmes de recherche d’information comme la recherche d’entreprise et les moteurs de recommandation.
À mesure que les technologies de recherche alimentées par l’IA progressent, on observe une transition vers la recherche sémantique, permettant aux systèmes de comprendre à la fois le sens et l’intention derrière les requêtes des utilisateurs. Les modèles d’embedding et les bases de données vectorielles sont devenus centraux dans cette évolution.
La recherche sémantique dépasse la correspondance par mots-clés en représentant les données sous forme d’embeddings vectoriels, offrant une compréhension plus nuancée de l’intention de recherche et transformant des applications allant de la génération augmentée par récupération (RAG) à la recherche multimodale.
En pratique, les systèmes efficaces de recherche d’information ont besoin à la fois d’une compréhension sémantique et d’une correspondance exacte par mots-clés. Par exemple, les utilisateurs s’attendent à ce que les résultats de recherche affichent des concepts liés à leurs requêtes tout en respectant également le texte littéral utilisé dans la requête, comme des termes et des noms spéciaux, et renvoient les résultats correspondant exactement.
Une recherche sémantique alimentée par des vecteurs denses aide à comprendre le sens (comme savoir que ‘car’ et “automobile” sont identiques) et la recherche traditionnelle en texte intégral fournit les résultats précis attendus par les utilisateurs (comme trouver des correspondances exactes pour “Python 3.9”). Par conséquent, de nombreuses organisations adoptent une approche de recherche hybride, combinant les forces des deux méthodes afin d’équilibrer une pertinence sémantique flexible avec une correspondance exacte par mots-clés prévisible.
Le défi de la recherche hybride
Une manière courante de mettre en œuvre la recherche hybride consiste à utiliser une base de données vectorielle conçue à cet effet, comme Milvus open source, pour une recherche sémantique efficace et évolutive, aux côtés de moteurs de recherche traditionnels comme Elasticsearch ou OpenSearch pour la recherche en texte intégral.
Bien que cette approche puisse produire de bons résultats, elle introduit également une nouvelle couche de complexité. Gérer deux systèmes de recherche distincts signifie devoir composer avec des infrastructures, des configurations et des tâches de maintenance séparées, ce qui crée une charge opérationnelle plus lourde et augmente le risque de problèmes d’intégration potentiels.
Elasticsearch vs Milvus on Hybrid search
Figure : Elasticsearch vs Milvus sur la recherche hybride
Une solution unifiée pour la recherche hybride offrirait de nombreux avantages :
Maintenance d’infrastructure réduite : Gérer un seul système plutôt que deux réduit considérablement la complexité opérationnelle, ce qui permet d’économiser du temps et des ressources. Cela signifie également moins de changements de contexte et de charge mentale pour maîtriser deux ensembles d’API différents.
Gestion des données consolidée : Une structure de table unifiée vous permet de stocker à la fois des données denses (basées sur des vecteurs) et creuses (basées sur des mots-clés) aux côtés d’étiquettes de métadonnées partagées. L’utilisation de deux systèmes séparés nécessiterait de stocker deux fois les étiquettes de métadonnées afin que les deux côtés puissent effectuer un filtrage par métadonnées.
Requête simplifiée : Une seule requête peut exécuter à la fois les tâches de recherche sémantique et de recherche en texte intégral, éliminant la nécessité d’effectuer deux appels API vers des systèmes séparés.
Sécurité et contrôle d’accès renforcés : Une approche unifiée permet une gestion de la sécurité plus simple et plus robuste, car tous les contrôles d’accès peuvent être administrés de manière centralisée au sein d’une base de données vectorielle, améliorant ainsi la conformité et la cohérence en matière de sécurité.
Comment une approche vectorielle unifiée simplifie la recherche hybride
Dans la recherche sémantique, les modèles d’apprentissage automatique « intègrent » le texte sous forme de points, appelés vecteurs denses, dans un espace à haute dimension en fonction de sa signification. Les textes ayant une sémantique similaire sont plus proches les uns des autres dans cet espace. Par exemple, « pomme » et « fruit » pourraient être plus proches dans cet espace que « pomme » et « voiture ». Cela nous permet de trouver rapidement du texte sémantiquement lié en calculant simplement la distance entre chaque point à l’aide d’algorithmes de plus proches voisins approximatifs (ANN).
Cette méthode peut également être appliquée à la recherche en texte intégral en encodant les documents et les requêtes sous forme de vecteurs creux. Dans les vecteurs creux, chaque dimension représente un terme et la valeur indique l’importance de chaque terme dans le document.
Les termes absents du document ont une valeur de zéro. Comme un document donné n’utilise généralement qu’une petite partie de tous les termes possibles du vocabulaire, la plupart des termes n’apparaîtront pas dans le document. Cela signifie que les vecteurs obtenus sont creux — la plupart de leurs valeurs sont nulles. Par exemple, dans l’ensemble de données MS-MARCO couramment utilisé pour évaluer les tâches de recherche d’informations, bien qu’il y ait environ 9 millions de documents et un million de termes uniques, un système de recherche divise généralement cette grande collection en segments plus petits pour faciliter la gestion.
Même au niveau du segment, avec des centaines de milliers de termes dans son vocabulaire, chaque document contient généralement moins de 100 termes, ce qui signifie que plus de 99 % des valeurs de chaque vecteur sont nulles. Cette parcimonie extrême a des implications importantes sur la manière dont nous stockons et traitons efficacement ces vecteurs.
Ce schéma de parcimonie peut être exploité pour optimiser les performances de recherche tout en maintenant la précision. Les bases de données vectorielles conçues à l’origine pour les vecteurs denses peuvent être adaptées pour gérer efficacement ces vecteurs creux. Par exemple, la base de données vectorielle open source Milvus vient de publier une prise en charge native de la recherche en texte intégral utilisant Sparse-BM25, une implémentation en vecteurs creux de l’algorithme BM25 utilisé par Elasticsearch et d’autres systèmes de recherche en texte intégral. Sparse-BM25 ouvre la voie à une optimisation basée sur l’approximation pour la recherche en texte intégral avec :
Algorithme de récupération efficace avec élagage des données : En appliquant un élagage basé sur des heuristiques pour écarter les documents présentant les valeurs de vecteurs creux les plus faibles dans l’index de segment et en ignorant les vecteurs creux de faible valeur dans la requête de recherche, une base de données vectorielle peut réduire considérablement la taille de l’index et optimiser les performances avec une perte de qualité minimale.
Déblocage d’optimisations supplémentaires des performances : Représenter la fréquence des termes sous forme de vecteur creux au lieu d’un index inversé permet des optimisations supplémentaires basées sur les vecteurs. Celles-ci incluent :
L’indexation par graphe est utilisée pour une recherche plus efficace que les balayages par force brute.
La quantification de produit (PQ) / quantification scalaire (SQ) afin de réduire davantage l’empreinte mémoire.
En plus de ces optimisations, l’implémentation Sparse-BM25 hérite également de plusieurs avantages au niveau système de la base de données vectorielle haute performance Milvus :
Implémentation bas niveau et gestion de la mémoire efficaces : Le moteur central d’indexation vectorielle de Milvus est implémenté en C++, offrant une gestion de la mémoire plus efficace qu’un système basé sur Java comme Elasticsearch. À elle seule, cette approche réduit l’empreinte mémoire en économisant des gigaoctets par rapport à une approche basée sur la JVM.
Prise en charge de MMap : À l’instar de l’utilisation par Elasticsearch du page-cache pour le stockage des index en mémoire comme sur disque, Milvus prend en charge le memory mapping (MMap) afin d’étendre la capacité mémoire lorsque l’index dépasse la mémoire disponible.
Pourquoi les piles de recherche traditionnelles sont insuffisantes pour la recherche vectorielle
Elasticsearch a été conçu pour les index inversés traditionnels, ce qui rend fondamentalement difficile l’optimisation de toute l’architecture pour la recherche vectorielle dense. L’impact est clair : même avec seulement 1 million de vecteurs, Elasticsearch met 200 millisecondes (tel que testé sur Elastic Cloud entièrement managé) pour renvoyer le résultat de recherche, contre 6 ms sur Milvus (tel que testé sur Zilliz Cloud entièrement managé) — soit une différence de performances de plus de 30x. Le débit mesuré en requêtes par seconde (QPS) présente également une différence de 3x, l’instance la plus performante sur Zilliz Cloud atteignant 6000 QPS tandis qu’Elastic Cloud atteint au maximum 1900 QPS. De plus, Zilliz Cloud est 15x plus rapide qu’Elastic Cloud pour charger les données vectorielles et construire l’index. Cet écart de performances s’élargit à grande échelle, où l’implémentation Java/JVM d’Elasticsearch peine à égaler la scalabilité des bases de données vectorielles basées sur C++/Go. En outre, Elasticsearch ne dispose pas de fonctionnalités essentielles de recherche vectorielle telles que les index basés sur disque (DiskAnn, MMap), le filtrage optimisé des métadonnées et la recherche par plage.
VectorDBBench Benchmarking Results.jpg
Figure : Résultats de benchmark VectorDBBench (source)
Conclusion
Les bases de données vectorielles, illustrées par Milvus, sont en passe de dépasser Elasticsearch en tant que solution unifiée pour la recherche hybride. En intégrant la recherche vectorielle dense à des techniques optimisées de vecteurs clairsemés, les bases de données vectorielles offrent des performances, une scalabilité et une efficacité supérieures. Cette approche unifiée simplifie l’infrastructure, réduit l’empreinte mémoire et améliore les capacités de recherche, ce qui en fait l’avenir des besoins de recherche avancée. Par conséquent, les bases de données vectorielles fournissent une solution complète qui combine de manière transparente la recherche sémantique et la recherche plein texte, surpassant les systèmes de recherche traditionnels comme Elasticsearch.
Continuer à lire
Introducing Zilliz Cloud Global Cluster: Region-Level Resilience for Mission-Critical AI
Zilliz Cloud Global Cluster delivers multi-region resilience, automatic failover, and fast global AI search with built-in security and compliance.
Introducing Zilliz MCP Server: Natural Language Access to Your Vector Database
Developers can easily manage and query vector databases with natural language via Zilliz MCP Server in AI-native environments.
The Great AI Agent Protocol Race: Function Calling vs. MCP vs. A2A
Compare Function Calling, MCP, and A2A protocols for AI agents. Learn which standard best fits your development needs and future-proof your applications.