alphaspirit - stock.adobe.com
Hazelcast se met (lui aussi) à la recherche vectorielle
Avec Hazelcast Platform 5.5, l’éditeur intègre une fonction de recherche vectorielle adaptée aux besoins de performance de ses clients principaux : les services financiers.
Le rachat de Rockset par OpenAI tend à le prouver. Les bases de données in-memory ont toute leur place dans l’écosystème de l’IA générative. Et c’est pour tenter de se mettre à la page que l’éditeur américain Hazelcast intègre la recherche vectorielle dans sa plateforme In-Memory Data Grid.
La promesse de l’éditeur ? Offrir les « fondations » pour prendre en charge les vecteurs représentant les documents des entreprises.
« L’intégration de la recherche vectorielle dans Hazelcast Platform fournit les fonctionnalités de base et les fondations sur lesquelles les développeurs peuvent moderniser les applications critiques et innover dans l’ère de l’IA », déclare Adrian Soars, CTO d’Hazelcast, dans un communiqué de presse.
Le directeur technique affirme que Hazelcast Platform 5.5 vise à « simplifier les piles technologiques et à réduire le coût total de possession, permettant ainsi aux leaders technologiques de réorienter leur budget vers les initiatives et l’innovation en matière d’IA ».
De fondation, il s’agit bien. La recherche vectorielle n’est pour l’instant accessible qu’en bêta dans la version Enterprise d’Hazelcast Platform 5.5. Elle devrait être disponible en production à partir du quatrième trimestre 2024.
Mais l’éditeur dit avoir développé un moteur spécifique, « optimisé pour le stockage, la recherche et la gestion des embbedings et de métadonnées supplémentaires ».
Comme Hazelcast est avant tout une base de données clé-valeur (NoSQL), elle prend en charge des collections de vecteurs dans des fichiers JSON, incluant ces embeddings et les métadonnées des associées.
« Les métadonnées peuvent inclure des valeurs permettant le filtrage, le traitement ou l’analyse des vecteurs », indique Fawaz Ghali, directeur de l’expérience développeur chez Hazelcast, dans un billet de blog.
Son API Pipeline ingère des données structurées, semi-structurées et non structurées. Elles sont d’abord transformées par un modèle d’embeddings laissé au choix du client. Puis, les vecteurs sont stockés dans les fameuses collections avec leurs index.
Indexation vectorielle : Hazelcast rejoint le camp de Datastax et de Microsoft
Pour rappel, Hazelcast repose en grande partie sur Java et sa JVM (Java Virtual Machine) pour propulser les traitements distribués de son SGBD. La recherche vectorielle n’échappe pas à cette règle. Ainsi, il adapte JVector à ses besoins.
Développé par Datastax, JVector est une librairie open source écrite en Java s’appuyant sur DiskANN, une suite d’algorithmes orientés graphes de recherche des proches voisins et de similarité conçue par Microsoft.
« L’index est basé sur la librairie JVector, qui implémente un algorithme DiskANN pour la recherche de similarité », précise Hazelcast. « Essentiellement, chaque index sert d’espace vectoriel distinct. En matière de stockage, l’index est un graphe dans lequel chaque nœud représente un vecteur et où les arêtes sont organisées de manière à optimiser l’efficacité de la recherche ».
DiskANN s’inscrit dans la même famille d’algorithmes d’indexation vectorielle que HNSW (Hierarchical Navigable Small Worlds), un algorithme associé au projet Apache Lucene.
« Les index basés sur les graphes ont tendance à être plus simples à mettre en œuvre et plus rapides, mais surtout, ils peuvent être construits et mis à jour de manière incrémentale », indique Jonathan Ellis, cofondateur de DataStax dans la description accompagnant le projet JVector. « Ils conviennent donc beaucoup mieux à un index polyvalent que les approches de partitionnement qui ne fonctionnent que sur des jeux de données statiques entièrement spécifiés à l’avance. C’est la raison pour laquelle tous les principaux index vectoriels commerciaux utilisent des graphes ».
Pour autant, HNSW, l’algorithme principal exploité par la plupart des éditeurs de base de données (SingleStore, Neo4j, Redis, Elastic, Pinecone, etc.) pèserait sur les performances d’indexation vectorielle. DataStax et Microsoft et maintenant Hazelcast ont fait le choix de DiskANN pour son optimisation computationnelle. Selon Microsoft, avec Azure CosmosDB, DiskANN réclamerait 95 % de ressources de calcul en moins et 1/60 e de la mémoire vive nécessaire pour indexer les vecteurs avec HNSW.
« Dans des tests de référence internes portant sur 1 million de vecteurs angulaires OpenAI, Hazelcast Platform surpasse ses concurrents, délivrant régulièrement une latence à un chiffre en millisecondes lors du chargement, de l’indexation et de la recherche de vecteurs avec une précision de 98 % », assure Hazelcast, sans préciser toutefois son protocole de tests.
Hazelcast prévient néanmoins que l’indexation de vecteurs est « très intensive en termes de calcul ». L’éditeur pense se donner de meilleures chances en adoptant Java 21 et l’API Vector issu du projet Panama, l’un des programmes phares de la modernisation du célèbre framework de programmation.
JVector, qui joue le rôle d’un moteur de recherche vectorielle, peut être interrogé avec des clients Java ou Python.
Le secteur bancaire en ligne de mire
Outre la mise en place d’architecture RAG (Retrieval Augmented Generation) lié au déploiement de l’IA générative, Hazelcast assure que ses clients principaux, les services financiers et les banques (BNP Paribas, Finastra, Commerzbank, Swedbank, PayPal, Ingenico, etc.) peuvent bénéficier de la recherche vectorielle dans des cas d’usage de connaissance du client (Know your Customer ou KYC), de détection de fraudes et de lutte contre le blanchiment d’argent.
« Grâce à l’analyse sémantique des textes, des images et d’autres sources, la recherche vectorielle améliore et accélère la vérification, rendant plus rapide et précise l’identification des transactions légitimes et frauduleuses », avance-t-il dans un communiqué.
Outre la recherche vectorielle, Hazelcast Platform 5.5 s’intègre avec le feature store open source Feast.
« Un feature store permet de découvrir, de documenter et de réutiliser des features (les paramètres et hyperparamètres des algorithmes, N.D.L.R) tout en garantissant leur exactitude », précise Hazelcast. « Cela signifie que vous pouvez utiliser exactement les mêmes caractéristiques pendant l’entraînement et l’inférence de votre modèle [et donc] d’éviter les prédictions faussées ».
Ici, l’éditeur prend en charge ce feature store en batch et « en ligne », c’est-à-dire pour des usages en temps réel. Feast est régulièrement utilisée pour propulser en partie des systèmes d’IA activées à la transaction. Là encore, cela peut servir à détecter des fraudes au paiement.
Plus de contrôle sur les clusters et les charges de travail
Par ailleurs, Hazelcast poursuit ses efforts en vue de simplifier la gestion des clusters. À ce titre, il introduit la fonctionnalité Jet Job Placement Control. Celle-ci doit permettre la fameuse promesse du cloud : « isoler les opérations de calcul du stockage ». Plus précisément, l’éditeur fait évoluer son système de nœuds au sein de ses clusters. Il y a désormais des nœuds qualifiés « Full Members », qui peuvent traditionnellement servir à traiter et à stocker les données, et les nœuds « Lite Members ». Comme leur nom l’indique, ceux-ci ne peuvent qu'effectuer des calculs. Ils n’entreposent pas de données ni ne conservent de partitions. Ces « Lite Members » peuvent être alloués à des traitements classiques ou du streaming.
« Parmi les exemples de charges de travail susceptibles d’en bénéficier, citons les pipelines qui calculent les embeddings et les pipelines d’inférence ML », avance Hazelcast.
Enfin, l’éditeur introduit un mode de routage multimembre pour les clients Java. L’idée est d’améliorer « le contrôle, les performances et la stabilité » d’applications reposant sur des clusters géographiquement dispersés. Par là, Hazelcast compte combler les défauts de ses deux précédents modes de routage, l’un sécuritaire, mais moins résilient, et l’autre robuste, mais plus risqué en matière d’accès aux données.
Hazelcast Platform 5.5 est en disponibilité générale depuis le 30 juillet et peut être déployée sur site ou dans le cloud. L’éditeur offre un support LTS d’une durée de trois ans. La version 6.0 est d’ores et déjà en cours de préparation comme le laisse apparaître sa documentation, mais aucune date n’est renseignée.