Avec l’émergence de l’IA générative, Redis revoit ses priorités

« Simplifier » la migration des données et le développement des applications

« Nous avons constaté que les utilisateurs s’efforçaient de construire ces pipelines de streaming par eux-mêmes », justifie Yaron Parasol, responsable produit chez Redis. « Cela nécessitait l’intégration de plusieurs composants (Change Data Capture [CDC], streaming et connecteurs Redis), la programmation des transformations, la gestion des erreurs et de nombreuses autres exigences essentielles pour les entreprises ».

En outre, l’éditeur adopte définitivement le protocole de sérialisation de données client-serveur RESP3 introduit dans Redis 6.0. Celui-ci est capable de traiter un plus grand nombre de type de données de manière asymétrique (mais par les données pub/sub shardées introduites dans Redis 7.0).

Pour les développeurs, Redis prend officiellement en charge cinq librairies clients (Java, Node.js, Python, .Net et Go) développées par la communauté. De plus, il a présenté en préversion des déclencheurs et des fonctions JavaScript améliorés. Cette capacité serait idéale pour les applications event-driven ou de streaming.

Ces déclencheurs « permettent aux développeurs de programmer, de stocker et d’exécuter automatiquement du code JavaScript sur les changements de données directement dans une base de données Redis », décrivent les porte-parole de l’éditeur. « Les développeurs définissent une logique métier qui s’exécute en réponse aux événements ou aux commandes de la base de données. Cela permet d’accélérer le code et les interactions connexes ».

Sur son site Web, l’éditeur évoque des cas d’usage concrets. Dans le monde du e-commerce les fonctions offriraient possibilité de mettre à jour un inventaire dès la réception d’une commande afin de prévoir les stocks. Dans le secteur du voyage, la réservation d’un billet peut déclencher un système de recommandation qui, selon les informations reçues, affichera des propositions pertinentes (location de voitures, hôtels à proximité, etc.). 

L’IA générative et la recherche sémantique, deux voies toutes tracées pour Redis

L’ensemble des fonctions décrites ci-dessus correspondent aux cas d’usage typiques de Redis.

Pour autant, l’éditeur ne définit plus seulement son produit comme un SGBD in-memory. En ce sens, il a amélioré la prise en charge des données géospatiales dans le module RediSearch. La version 2.8 de ce plug-in offre la possibilité d’effectuer des recherches de données géométriques, permettant par exemple de délimiter une zone de recherche sur une carte d’une application.

L’autre voie d’intérêt pour Redis n’est autre que l’IA. En 2021, l’éditeur évoquait la possibilité d’utiliser son SGBD comme un feature store. Aujourd’hui, il présente son produit comme un candidat idéal pour gérer des bases de données vectorielles. Il s’agit d’accueillir les représentations vectorielles (embeddings) nécessaires à l’enrichissement des requêtes vers les modèles d’IA générative.

De fait, les embeddings qui permettent aux grands modèles de langage d’extraire du contexte d’un document ou d’un texte sont d’abord des vecteurs.

Plus généralement, ces vecteurs, dont l'on a réduit la dimensionnalité pour être stockés dans une base de données, servent à représenter les paramètres extraits d’un document, d’un fichier audio ou encore d’une image. En clair, des données non structurées.

« Les entreprises sont à la recherche d’une base de données vectorielle qui a fait ses preuves, avec une géodistribution Active-Active, une multilocalisation, une recherche hybride basée sur les labels, un accès basé sur les rôles, des objets intégrés (c’est-à-dire des fichiers JSON), des fonctions de recherche de texte et un alias d’index », affirme Rowan Trollope, CEO de Redis. « Toutes ces fonctionnalités sont intégrées et testées sur Redis Enterprise », défend-il. Au passage, le dirigeant mentionne le fait qu’OpenAI exploite le SGBD.

La fonction de recherche de similarité entre des vecteurs, inclue dans le module RediSearch 2.8.3, donne accès à deux types d’index : Flat et HNSW. L’index Flat permet une comparaison par force brute du vecteur exprimé en requête avec les vecteurs stockés en blocs dans la base de données. L’index HNSW (Hierarchical Navigable Small World), utilisé pour la recherche approximative des proches voisins, s’appuie également sur des blocs et non plus sur des arrays pour stocker les vecteurs et leurs métadonnées.

La méthode HNSW donne des résultats plus rapides au sacrifice de la précision de la recherche.

Aussi, l’éditeur défend la capacité d’hybrider la recherche en mêlant la mesure de la similarité de vecteurs et des filtres (nombre, texte, label) plus classiques.

Pour mesurer la distance entre plusieurs vecteurs, Redis a intégré trois méthodes de calcul : la similarité cosinus, le produit interne (inner product en VO) et la distance euclidienne. Ces techniques permettent – par exemple – de trouver des documents semblables ou des mots similaires dans un document, de dénombrer les occurrences de mots dans un même document ou encore déduire la similarité sémantique entre des mots. De manière générale, le choix entre l’une ou l’autre méthode « dépend de la façon dont les données ont été vectorisées », résume Brian Sam-Bodden, Senior Developer Advocate chez Redis, dans une vidéo publiée sur YouTube.

Si cette vectorisation demandait auparavant beaucoup d’efforts manuels, l’émergence de modèles de machine learning et de deep learning pour ce faire a grandement accéléré cette tâche. Il faut toutefois trouver le bon modèle pour une tâche spécifique, ce qui n’est pas toujours évident, prévient Brian Sam-Bodden. Pour l’instant, Redis renvoie ses clients vers les places de marché de Hugging Face, PyTorch Hub et TensorFlow Hub.

Ces modèles sont généralement affinés pour une méthode de calcul de la distance entre les vecteurs. Le developer advocate exploite dans son exemple un modèle MSMARCO de Microsoft. Celui-ci a été entraîné à l’aide de 500 000 véritables recherches associées aux réponses les plus appropriées retournées par le moteur de recherche Bing. Dans son cas, le modèle a été affiné pour des tâches de clustering et de recherche sémantique en utilisant la méthode de la similarité cosinus.

En outre, Rowan Trollope évoque des cas d’usage, comme la mise en cache des sorties des modèles d’IA générative pour les réduire le temps de génération de réponse, la recherche de document, ou la mise en place de systèmes de recommandations.

Le CEO de Redis, nommé en décembre 2022, veut s’assurer que les éditeurs spécialisés, dont Pinecone et Weawiate, ne soient pas les seuls à prendre la lumière dans ce moment d’effervescence provoqué par l’IA générative. Il mentionne des intégrations avec plusieurs outils, dont LlamaIndex, Langchain, RelevanceAI, DocArray, MantiumAI, les plug-ins ChatGPT ou les frameworks de Nvidia. Pour répondre aux usages grandissants, l’éditeur travaille par ailleurs sur la préversion d’une méthode de distribution optimale des requêtes de recherche sur plusieurs clusters. « Cela peut améliorer le débit des requêtes jusqu’à 16 fois par rapport à ce qui était possible auparavant avec le moteur de recherche et d’interrogation de Redis Enterprise », promet le dirigeant.

La fin de RedisGraph, une décision économique

Malgré sa volonté de fournir une base de données généraliste, Redis a pris conscience qu’il ne pouvait pas être partout. En juillet dernier, l’éditeur a dévoilé la dépréciation du module RedisGraph, pour le plus grand bonheur de Neo4J et TigerGraph. La fin de vie de RedisGraph est prévue pour la fin du mois de janvier 2025. L’éditeur ne vend plus la licence associée à son module.

Alors que les cabinets d’analystes, dont Gartner, prévoyaient que la démocratisation des bases de données orientées graphes devait être « exponentielle », Redis n’observe pas cette croissance. « La courbe d’apprentissage est abrupte. La validation des PoC peut prendre beaucoup plus de temps que prévu et le taux de réussite peut être faible par rapport à d’autres modèles de bases de données », jugent Lior Kogan et Pieter Cailliau, deux responsables produits chez Redis, dans un billet de blog. « Pour les clients et leurs équipes de développement, cela est souvent synonyme de frustration ».

À l’inverse, les projets impliquant des moteurs de recherche, le traitement de fichiers JSON et les embeddings sont beaucoup plus porteurs. « La plupart des clients développent des solutions à l’échelle avec un support minimal », notent-ils.

Les responsables produits ne cachent toutefois pas la véritable raison de cette défection. Elle est tout simplement économique.

« Pour être tout à fait honnête, bien que notre offre Graphe soit unique et techniquement compétitive à bien des égards, les coûts nécessaires pour développer nos capacités techniques, commerciales et de support afin de répondre à un segment plus important de ce marché sont beaucoup plus élevés que nous ne l’avions prévu », avouent les auteurs. « Compte tenu de la dynamique du marché des bases de données et des opportunités qui s’offrent à nous, nous avons décidé de concentrer nos efforts sur d’autres segments ».

Un discours qui tend à rassurer AWS et Neo4j dans leur position. Le premier préfère développer une multitude de bases de données spécialisées, tandis que le second se concentre sur le développement d’un SGBD orienté graphe.