Pinecone convertit sa base de données vectorielle au serverless

Les bases de données vectorielles ont le vent en poupe

Produits de niche pendant deux décennies, elles ont rencontré une popularité fulgurante au cours de l’année écoulée. Les géants de la technologie ont reconnu leur valeur au moment d’entraîner de grands modèles de langage et de propulser des applications d’IA générative, dont ChatGPT et Google Bard.

« Depuis la sortie de ChatGPT en décembre 2022, nous avons vu une augmentation massive de notre base d’utilisateurs [...] ».

« Depuis la sortie de ChatGPT en décembre 2022, nous avons vu une augmentation massive de notre base d’utilisateurs, et sans aucun doute, c’est ce cas d’usage qui a alimenté la majorité de nos plus de 10 000 inscriptions quotidiennes », renseigne Ram Sriharsha, VP Engineering chez Pinecone, dans un billet de blog.

Plus précisément, elles sont au cœur de pipelines de génération augmentée par la recherche (Retrieval Augmented Generation ou RAG), rappelle Doug Henschen, analyste chez Constellation Research.

« Les embeddings aident les data scientists qui conçoivent les architectures RAG à améliorer la précision et la pertinence des réponses des LLM en s’appuyant sur les données propres à l’entreprise », explique-t-il. « Les développeurs peuvent ensuite déployer ces capacités de recherche plus précises dans des applications spécifiques afin d’obtenir de meilleurs résultats ».

Pinecone est directement concurrencé par des acteurs tels que Milvus et Chroma. D’autres éditeurs et fournisseurs proposent désormais des bases de données vectorielles, dont, Google Cloud, AWS, MongoDB ou encore Snowflake.

De fait, au cours des dix dernières années, le cloud est devenu l’environnement par défaut pour la plupart des opérations de gestion et d’analyse des données.

Les entreprises ont été attirées par les prix bas : quelques centimes par minute ou quelques dollars pour une unité de puissance de calcul.

Mais compte tenu du volume de données que les organisations collectent et traitent pour prendre des décisions, du nombre croissant d’utilisateurs, du coût d’utilisation de la myriade d’outils composant une « data stack », la facture cloud des entreprises a rapidement explosé.

Une maîtrise des coûts nécessaire

En conséquence, sous la pression de leurs clients, de plus en plus alertes, les fournisseurs tentent de proposer des solutions pour rendre la douloureuse plus acceptable.

« Le serverless est désormais une approche largement exploitée pour simplifier l’administration et l’usage élastique des ressources afin d’économiser de l’argent tout en répondant aux exigences de performance », déclare Doug Henschen.

L’introduction de Pinecone Serverless le 16 janvier a donc le potentiel de bénéficier à la fois aux clients existants qui cherchent à réduire les coûts et d’attirer de nouveaux utilisateurs qui cherchent à les contrôler, considère l’analyste.

Malgré l’effervescence autour de l’IA générative (et ses dires), « Pinecone n’a pas encore une grande base installée », signale M. Henschen. « Cela donnera aux clients existants la possibilité de passer au serverless. Mais l’entreprise espère surtout attirer de nouveaux clients qui auraient pu être réticents à l’idée de devoir configurer, administrer et faire évoluer une base de données manuellement ».

La tarification de la base de données existante de Pinecone est basée sur l’usage de ressources : le stockage ainsi que les unités de lecture et d’écriture. Le fournisseur ne divulgue pas le montant des frais d’utilisation, mais propose un calculateur de coûts sur son site Web.

Le fournisseur affirme que son offre serverless peut permettre de réaliser des économies considérables.

La tarification de Pinecone Serverless est de 0,33 $ par gigaoctet et par mois pour le stockage, de 8,25 $ par million d’unités de lecture et de 2 $ par million d’unités d’écriture.

Si les deux produits sont difficilement comparables, notons que le stockage dans Snowflake est facturé 0,23 dollar par gigaoctet par mois.

Pour autant, Pinecone précise que cette tarification de cette préversion « n’est pas encore optimisée pour les applications à haut débit, telles que les systèmes de recommandation ». « Nous mettrons à jour notre tarification pour répondre à ce cas d’usage à l’avenir », promet Edo Liberty, fondateur et CEO de Pinecone.

Malgré ce rodage nécessaire, Donald Farmer, fondateur et directeur de TreeHive Strategy, souligne, pour sa part, le rôle important que jouent les bases de données vectorielles dans le développement de l’IA générative.

« L’offre Serverless est une annonce importante », avance-t-il. « J’ai entendu beaucoup de demandes à ce sujet au cours de l’année dernière. Il s’agit d’une architecture de base de données vectorielle serverless qui devrait permettre de traiter d’énormes quantités de données vectorielles à moindres frais ».

Et Donald Farmer d’ajouter que « l’architecture de Pinecone Serverless… semble innovante dans le secteur des bases de données vectorielles ».

Si les entreprises doivent vérifier les gains promis par Pinecone par elles-mêmes, l’éditeur explique que cette architecture repose sur la séparation des opérations de calcul et du stockage, sur une approche multitenant et sur le rafraîchissement accru des index.

Plus particulièrement, Pinecone tente de concevoir une architecture spécifique aux bases de données vectorielles.

Des enjeux techniques aussi vieux que les moteurs de recherche

« Traditionnellement, les bases de données vectorielles utilisent une architecture de moteur de recherche dans laquelle les données sont réparties entre de nombreux index individuels plus petits et les requêtes sont envoyées à tous les index », indique Ram Sriharsha. « Ce mécanisme d’interrogation est appelé “scatter-gather”, car nous dispersons une interrogation dans les répertoires avant de rassembler les réponses pour produire un résultat final. Notre architecture reposant sur des Pods utilise exactement ce mécanisme ».

Selon ce principe existant, ce type de SGBD NoSQL doit conserver l’index entier localement sur les shards. C’est particulièrement le cas pour les bases de données qui exploitent les algorithmes de similarité HNSW (Hierarchical Navigable Small Worlds) ou FAISS (Facebook AI Similarity Search), signale l’ingénieur en chef, soit la majorité des produits sur le marché.

Avec une telle architecture, il ne serait pas possible de paginer des parties de l’index en mémoire, ni même de savoir quelles parties ont doivent l’être avant qu’une requête ait touché tous les shards.

Selon Ram Sriharsha, comme les SGBD consacrés à la recherche ont été pensés pour traiter des quantités massives de documents, ils s’avèrent peu adaptés aux cas d’usage ciblant une portion d’un corpus à un rythme plus lent, par exemple lors de l’étiquetage de données.

Dans le cas d’une architecture RAG, l’index doit être hautement disponible. Or, le stocker sur un espace de stockage local au serveur, en mémoire vive ou sur un SSD, s’avère particulièrement coûteux.

De plus, le fait de charger l’entièreté d’un index en mémoire n’est pas rentable dans une approche serverless « traditionnelle ». Ce n’est pas non plus performant au moment d’effectuer des requêtes, « car les temps de latence du stockage en bloc seraient trop importants pour le chargement de ces grands ensembles de données dans leur intégralité », poursuit Ram Sriharsha.

Par-dessus le marché, la mise à jour incrémentale d’un index d’une base de données vectorielle n’est pas une mince affaire, qu’il réside sur un espace de stockage persistant ou en mémoire.

La solution de Pinecone avec son produit Serverless consiste, en premier lieu, à considérer les instances de stockage en bloc « comme la source de vérité pour tous les index ».

Les nouvelles données sont écrites dans cet espace de stockage par des writers qui enregistrent simultanément toutes les modifications des index dans un manifeste de logs.

Deux types d’index pour une seule base de données

Ce manifeste de logs est lui-même exploité par deux briques distinctes : le constructeur d’index (Index Builder) et la couche de « fraîcheur » des données (Freshness Layer).

Le constructeur s’occupe du partitionnement géométrique de l’index. « Le partitionnement géométrique peut être considéré comme la division de l’espace des vecteurs en régions », explique Ram Sriharsha.

Ces régions sont représentées par des vecteurs centroïdes. En clair, après que le constructeur a lu les nouvelles données, chaque nouveau vecteur est assigné à une partition, contenant le centroïde le plus proche, avant d’être stocké dans un bloc.

Le fichier de logs est mis à jour en conséquence pour renseigner les segments d’index valides et le numéro de version maximum des enregistrements déjà indexés.

En plus de stocker les segments d’index en mode bloc, cette approche permettrait de charger uniquement les segments nécessaires à l’accomplissement d’une requête. Ces segments immuables peuvent être par ailleurs « chargés, mis en cache et gérés par des exécuteurs de requêtes ».

L’immutabilité des partitions est fonction de namespaces, des éléments hérités de l’architecture en Pod mis en place préalablement par Pinecone. Les namespaces assurent l’isolation des données, en agissant comme des partitions en dur. C’est aussi la fonction motrice des aspects multitenant de Pinecone Serverless.

Or, en principe, le partitionnement géométrique d’un index n’est efficace que lorsque les données sont statiques.

Pinecone a fait en sorte que le constructeur d’index maintienne une hiérarchie des partitions au fur et à mesure que l’index reçoit des données, ce qui permet de reconstruire l’index de manière incrémentale. Résultat, seuls les segments nouvellement ajoutés et pertinents sont chargés au moment d’effectuer une requête, selon Ram Sriharsha.

« Il est frais mon index ! »

La couche de fraîcheur, elle, est responsable d’un second type d’index « compact », qui rassemble les données les plus récentes, celles qui n’ont pas encore été traitées par l’index builder. Depuis le manifeste de logs, cette couche lit le numéro de version maximum d’un ou des index pour identifier les vecteurs qui n’y figurent pas.

« La couche de fraîcheur permet aux clients de modifier, d’ajouter ou d’expurger des documents et de les rendre disponibles pour la recherche en quelques secondes », écrit Ram Sriharsha.

Les exécuteurs de requêtes peuvent cibler les index et la couche de fraîcheur pour charger et mettre en cache les segments nécessaires. « C’est la mise en cache qui apporte tous les avantages économiques du serverless sans sacrifier les exigences de faible latence de certaines applications ». 

Outre le fait que son architecture n’est pas encore optimisée pour les applications qui requièrent de très hauts niveaux de performance, Pinecone doit encore développer les éléments de sécurité afin de convaincre les entreprises d’y stocker leurs vecteurs (lien privé, piste d’audit des logs, gestion des clés de chiffrement par les clients).

Base de données spécialisée ou multimodèle ? Pinecone réhydrate le débat.

Pour autant, Pinecone Serverless serait bien plus adapté que n’importe quel SGBD capable de prendre en charge des vecteurs. Oracle et Snowflake n’ont pas développé d’architectures spécifiques pour ce qu’ils considèrent des types de données. C’est une erreur, selon le VP Engineering.

« C’est une erreur de considérer une base de données vectorielle comme un type de données supplémentaire couplé à un index supplémentaire dans une base de données SQL/NoSQL ».

« C’est une erreur de considérer une base de données vectorielle comme un type de données supplémentaire couplé à un index supplémentaire dans une base de données SQL/NoSQL. C’est précisément pour cette raison que toute tentative d’intégration naïve des vecteurs dans les bases de données traditionnelles est vouée à l’échec à grande échelle », prêche-t-il.

AWS et Google Cloud, eux, ont choisi le camp de la rentabilité et du « pratico-pratique » : ils proposent les deux options.

En octobre dernier, des data scientists de Red Hat ayant testé plusieurs solutions disponibles sur le marché faisaient le constat auprès du MagIT que les bases de données vectorielles spécialisées s’en sortaient mieux que les modules, comme PGVector.

La balle est dans le camp des entreprises, selon Doug Henschen de Constellation Research.

« Pinecone et d’autres éditeurs de bases de données vectorielles dédiées font valoir que leurs produits sont mieux adaptés aux équipes de data science et offrent davantage de fonctionnalités pour leurs besoins spécifiques », résume Doug Henschen. « L’avenir nous dira si ces clients verront la nécessité d’adopter et de s’adapter à une solution distincte, plutôt que de payer un service supplémentaire dédié à l’IA pour une technologie qu’ils exploitent par ailleurs ».