Elasticsearch est mort, vive la recherche lexicale !
Tout le monde sait désormais que la recherche hybride a amélioré la qualité de la recherche RAG (Retrieval-Augmented Generation). Bien que la recherche par intégration dense ait montré des capacités impressionnantes à capturer des relations sémantiques profondes entre les requêtes et les documents, elle présente encore des limites notables. Il s'agit notamment d'un manque d'explicabilité et d'une performance sous-optimale pour les requêtes à longue traîne et les termes rares.
De nombreuses applications RAG se heurtent au fait que les modèles pré-entraînés manquent souvent de connaissances spécifiques au domaine. Dans certains scénarios, la simple correspondance de mots-clés BM25 est plus performante que ces modèles sophistiqués. C'est là que la recherche hybride comble le fossé, en combinant la compréhension sémantique de la recherche vectorielle dense avec la précision de la recherche par mot-clé.
Pourquoi la recherche hybride est complexe en production
Si des frameworks comme LangChain ou LlamaIndex facilitent la construction d'un récupérateur hybride de démonstration, le passage à la production avec des ensembles de données massifs est un défi. Les architectures traditionnelles nécessitent des bases de données vectorielles et des moteurs de recherche distincts, ce qui pose plusieurs problèmes majeurs :
Coûts élevés de maintenance de l'infrastructure et complexité opérationnelle
Redondance des données entre plusieurs systèmes
Gestion difficile de la cohérence des données
Sécurité et contrôle d'accès complexes entre les systèmes
Le marché a besoin d'une solution unifiée qui prenne en charge la recherche lexicale et sémantique tout en réduisant la complexité et le coût du système.
Les points sensibles d'Elasticsearch
Elasticsearch est l'un des projets de recherche open-source les plus influents de la dernière décennie. Basé sur Apache Lucene, il a gagné en popularité grâce à ses hautes performances, son évolutivité et son architecture distribuée. Bien qu'il ait ajouté la recherche vectorielle ANN dans la version 8.0, les déploiements en production sont confrontés à plusieurs défis majeurs :
Coûts élevés de mise à jour et d'indexation : L'architecture d'Elasticsearch ne découple pas totalement les opérations d'écriture, la construction d'index et les requêtes. Cela entraîne une surcharge importante du processeur et des E/S lors des opérations d'écriture, en particulier lors des mises à jour en masse. Les conflits de ressources entre l'indexation et l'interrogation ont un impact sur les performances, créant un goulot d'étranglement majeur pour les scénarios de mise à jour à haute fréquence.
Mauvaises performances en temps réel : En tant que moteur de recherche "quasi temps réel", Elasticsearch introduit une latence notable dans la visibilité des données. Cette latence devient particulièrement problématique pour les applications d'IA, telles que les systèmes d'agents, où les interactions à haute fréquence et la prise de décision dynamique nécessitent un accès immédiat aux données.
Une gestion difficile des nuages de points (Shard Management) : Bien qu'Elasticsearch utilise le sharding pour l'architecture distribuée, la gestion des shards pose des problèmes importants. L'absence de prise en charge du sharding dynamique crée un dilemme : un trop grand nombre de shards dans de petits ensembles de données entraîne des performances médiocres, tandis qu'un nombre insuffisant de shards dans de grands ensembles de données limite l'évolutivité et entraîne une distribution inégale des données.
Architecture non cloud-native : Développée avant la généralisation des architectures cloud-natives, la conception d'Elasticsearch associe étroitement le stockage et le calcul, ce qui limite son intégration avec les infrastructures modernes telles que les clouds publics et Kubernetes. La mise à l'échelle des ressources nécessite des augmentations simultanées du stockage et du calcul, ce qui réduit la flexibilité. Dans les scénarios multirépliqués, chaque shard doit construire son index indépendamment, ce qui augmente les coûts de calcul et réduit l'efficacité des ressources.
Mauvaises performances de la recherche vectorielle : Bien qu'Elasticsearch 8.0 ait introduit la recherche vectorielle ANN, ses performances sont nettement inférieures à celles des moteurs vectoriels dédiés comme Milvus. Basée sur le noyau Lucene, sa structure d'index s'avère inefficace pour les données à haute dimension, et se heurte à des exigences de recherche vectorielle à grande échelle. Les performances deviennent particulièrement instables dans les scénarios complexes impliquant le filtrage scalaire et la multi-location, ce qui rend difficile la prise en charge d'une charge élevée ou de besoins commerciaux diversifiés.
Consommation excessive de ressources : Elasticsearch sollicite énormément la mémoire et l'unité centrale, en particulier lors du traitement de données à grande échelle. Sa dépendance vis-à -vis de la JVM nécessite de fréquents ajustements de la taille du tas et des réglages du ramassage des ordures, ce qui a un impact considérable sur l'efficacité de la mémoire. Les opérations de recherche vectorielle nécessitent des calculs intensifs optimisés SIMD, pour lesquels l'environnement JVM est loin d'être idéal.
Ces limitations fondamentales deviennent de plus en plus problématiques au fur et à mesure que les entreprises font évoluer leur infrastructure d'intelligence artificielle, ce qui rend Elasticsearch particulièrement difficile pour les applications d'intelligence artificielle modernes nécessitant des performances et une fiabilité élevées.
Introduction de Sparse-BM25 : RĂ©imagination de la recherche lexicale
Milvus 2.5 introduit la prise en charge native de la recherche lexicale via Sparse-BM25, en s'appuyant sur les capacités de recherche hybride introduites dans la version 2.4. Cette approche innovante comprend les composants clés suivants :
Une tokénisation et un prétraitement avancés via Tantivy
Gestion distribuée du vocabulaire et de la fréquence des termes
Génération de vecteurs épars à l'aide du TF du corpus et du TF-IDF de la requête
Prise en charge de l'index inversé avec l'algorithme WAND (Block-Max WAND et prise en charge de l'index graphique en cours de développement).
Par rapport à Elasticsearch, Milvus offre des avantages significatifs en termes de flexibilité algorithmique. Son calcul de similarité basé sur la distance vectorielle permet une mise en correspondance plus sophistiquée, y compris la mise en œuvre de TW-BERT (Term Weighting BERT) basée sur la recherche "End-to-End Query Term Weighting" (pondération des termes de la requête de bout en bout). Cette approche a démontré des performances supérieures dans les tests in-domain et out-domain.
Un autre avantage crucial est le rapport coût-efficacité. En tirant parti de la compression de l'index inversé et de l'intégration dense, Milvus multiplie par cinq les performances avec une dégradation du rappel inférieure à 1 %. Grâce à l'élagage des termes de queue et à la quantification des vecteurs, l'utilisation de la mémoire a été réduite de plus de 50 %.
L'optimisation des requêtes longues est un point fort. Alors que les algorithmes WAND traditionnels ont du mal à traiter les requêtes longues, Milvus excelle en combinant des encastrements épars avec des indices de graphe, ce qui permet de multiplier par dix les performances dans les scénarios de recherche de vecteurs épars en haute dimension.
Milvus : la base de données vectorielles ultime pour RAG
Milvus est le premier choix pour les applications RAG grâce à son ensemble complet de fonctionnalités. Ses principaux avantages sont les suivants
Prise en charge de métadonnées riches avec des capacités de schémas dynamiques et des options de filtrage puissantes.
Une multi-location de niveau entreprise avec une isolation flexible par le biais de collections, de partitions et de clés de partition.
Prise en charge de l'index vectoriel sur disque, une première dans l'industrie, avec un stockage à plusieurs niveaux, de la mémoire à S3
Évolutivité native dans le nuage permettant une mise à l'échelle transparente de 10 millions à plus de 1 milliard de vecteurs
Capacités de recherche complètes, y compris le regroupement, l'étendue et la recherche hybride
Intégration approfondie de l'écosystème avec LangChain, LlamaIndex, Dify et d'autres outils d'intelligence artificielle.
Les diverses capacités de recherche du système englobent les méthodologies de regroupement, d'étendue et de recherche hybride. L'intégration approfondie avec des outils tels que LangChain, LlamaIndex et Dify, ainsi que la prise en charge de nombreux produits d'IA, placent Milvus au centre de l'écosystème de l'infrastructure d'IA moderne.
Perspectives d'avenir
Alors que l'IA passe du POC à la production, Milvus continue d'évoluer. Nous nous efforçons de rendre la recherche vectorielle plus accessible et plus rentable tout en améliorant la qualité de la recherche. Que vous soyez une startup ou une entreprise, Milvus réduit les obstacles techniques au développement d'applications d'IA.
Cet engagement en faveur de l'accessibilité et de l'innovation nous a permis de franchir une nouvelle étape importante. Alors que notre solution open-source continue de servir de base à des milliers d'applications dans le monde entier, nous reconnaissons que de nombreuses organisations ont besoin d'une solution entièrement gérée qui élimine les frais généraux d'exploitation.
Zilliz Cloud : La solution gérée
Au cours des trois dernières années, nous avons développé Zilliz Cloud, un service de base de données vectorielles entièrement géré basé sur Milvus. Grâce à une réimplémentation cloud du protocole Milvus, ce service offre une convivialité, une rentabilité et une sécurité accrues.
S'appuyant sur notre expérience de la maintenance des plus grands clusters de recherche vectorielle au monde et du soutien de milliers de développeurs d'applications d'IA, Zilliz Cloud réduit considérablement les frais généraux et les coûts d'exploitation par rapport aux solutions auto-hébergées.
Prêt à découvrir le futur de la recherche vectorielle ? Commencez votre essai gratuit dès aujourd'hui avec jusqu'à 200 $ de crédits, sans carte de crédit.
- Pourquoi la recherche hybride est complexe en production
- Les points sensibles d'Elasticsearch
- Introduction de Sparse-BM25 : RĂ©imagination de la recherche lexicale
- Milvus : la base de données vectorielles ultime pour RAG
- Perspectives d'avenir
- Zilliz Cloud : La solution gérée
On This Page
Try Managed Milvus for Free
Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.
Get StartedLike the article? Spread the word