Elastic promet d’abaisser le coût de la recherche vectorielle

DiskBBQ : baisser le coût d’indexation des vecteurs

DiskBBQ, en préversion technique depuis Elasticsearch Serverless, promet avant tout de réduire le temps d’indexation. Au lieu de résider en RAM, les vecteurs sont entreposés dans un espace de stockage objet (ici S3) propulsé par des SSD NVMe.

DiskBBQ n’est donc pas à proprement parler un format de stockage. L’appellation réunit plutôt un type d’index et un algorithme de vectorisation.  

Outre la compression des vecteurs, DiskBBQ utilise des k-moyennes hiérarchiques pour partitionner les vecteurs en plus petits clusters. Des centroïdes dits « représentatifs » sont sélectionnés au moment de la requête, afin de se rapprocher des vecteurs les plus pertinents pour y répondre. Seulement deux couches de centroïdes sont « traversées » au sein du graphe de vecteurs afin de limiter « l’espace exploré ». Le calcul de distance entre le vecteur de requête et ceux du cluster sélectionné est effectué en lot (bulk).

Le vecteur servant à lancer une recherche peut être assigné à plusieurs clusters à partir de la déclinaison d’une technique développée par Google. Cette assignation multicluster serait intéressante quand l’espace vectoriel à fouiller chevauche deux clusters.

« Cette approche ciblée réduit le nombre d’opérations en mémoire, ce qui la rend idéale pour les environnements à grande échelle ou à mémoire limitée », indique la documentation de l’éditeur.

Avec 1 million de vecteurs (le nombre de dimensions n’est pas précisé), le temps d’indexation d’HNSW avec BBQ est de plus de 17 minutes, quand DiskBBQ traite ce même volume en moins de deux minutes. La latence est légèrement plus élevée, mais elle décline pendant le traitement.

L’usage de DiskBBQ ne serait « pas recommandé » pour les vecteurs de faibles dimensions. Elastic considère que les vecteurs denses contiennent 128 à 4 096 dimensions. Par défaut, Elastic place ce seuil à 384 dimensions.

Ces gains ne sont pas sans compromis. DiskBBQ n’atteint pas des taux de rappel aussi élevé que HNSW. La latence pourrait être meilleure. En revanche, la méthode réduirait les coûts quand une précision de la recherche de 95 % « ou moins » est acceptable. Sinon, il faut préférer la combinaison HNSW-BBQ. Cette option semble intéressante quand elle est couplée à une approche d’ingénierie contextuelle.

Elastic n’est pas le premier ni le dernier à remplacer HNSW, souvent jugé trop gourmand en ressource de calcul.

En octobre, Couchbase a également dévoilé une alternative propriétaire à HNSW qui conjugue traitement en RAM et partitionnement sur disque. Les performances seraient, sur le papier, meilleures que celles soumises par Elastic. Seulement, Couchbase affiche des tests avec 100 millions de vecteurs.

Elastic promet déjà d’optimiser sa solution et de présenter davantage de benchmarks.

Avant Couchbase, Microsoft, DataStax, Google, HazelCast et d’autres ont fourni des remplacements ou des compléments à HNSW.

En parlant de HNSW, Elastic profite de la mise à jour d’Apache Lucene 10.3.0. Elle assure des requêtes vectorielles plus performantes, l’ajout du calcul de distance en lot et de « multiples » améliorations de la traversée du graphe et du stockage des vecteurs.

Notons que le modèle propriétaire ELSER (Elastic Learned Sparse Encoder), qui permet d’indexer et de rechercher des vecteurs épars (idéal pour la recherche hybride), est disponible depuis les instances GPU d’Elastic Cloud.

Agent Builder : Elastic se lance à son tour dans l’IA agentique

Évidemment, l’éditeur ne s’arrête pas à la recherche vectorielle. Comme la majorité des acteurs du marché IT, Elastic a présenté en préversion Agent Builder.

L’outil permet, depuis une interface ou une API, de développer des agents IA s’appuyant sur les outils de recherche vectorielle et sur ES|QL, le DSL/moteur de requêtes typé SQL. Il est également possible d’ajouter des serveurs MCP, A2A (Agent2Agent) et d’accéder aux API de Kibana.

Elastic ne soumet pas de cas d’usage type. Il ne semble pas se démarquer des frameworks open source et propriétaires sur le marché. Reste à voir si l’éditeur proposera des templates de déploiement pour ses différents types de clients (SOC, SRE, Workplace Search).

Enfin, Elastic applique l’IA à l’observabilité. Streams, en disponibilité générale, permet de partitionner et de parser les logs afin de trouver les informations pertinentes (« Significant Events »). Il entend automatiser une partie du travail effectué par les développeurs et les SRE à travers les expressions Grok. Streams peut être combiné à OpenTelemetry. Le tout doit simplifier l’ingestion de données tout en réduisant les coûts. En clair, Elastic propose une solution similaire à celle de Datadog. L’approche semble plus adaptée aux nouveaux clients qui n’ont pas fortement investi dans la personnalisation des filtres Grok.