Jusqu’à 50 fois d’économies pour créer des applications GenAI avec Zilliz Cloud Serverless
Introduction
Avec les avancées récentes de l’IA générative, le cas d’utilisation des bases de données vectorielles connaît une croissance exponentielle. Par exemple, la Retrieval Augmented Generation (RAG), une technique populaire d’amélioration des grands modèles de langage (LLM), exploite des bases de données vectorielles telles que Milvus et Zilliz Cloud (le Milvus géré) pour stocker, indexer et récupérer des informations pertinentes afin d’aider les LLM à générer des résultats plus précis.
Lors d’un récent Unstructured Data Meetup à San Francisco, James Luan, VP of Engineering chez Zilliz, a expliqué comment les développeurs peuvent exploiter Zilliz Cloud Serverless, une nouvelle offre de Zilliz, dans leurs applications d’IA générative. En résumé, ce nouveau service de Zilliz permet aux utilisateurs de stocker, d’indexer et d’interroger d’énormes volumes d’embeddings vectoriels pour seulement une fraction du coût. La bonne nouvelle est que les performances de Zilliz Cloud Serverless sont également très compétitives par rapport aux bases de données vectorielles en mémoire.
Dans cet article, nous récapitulerons les points clés de James et explorerons Zilliz Cloud Serverless plus en profondeur. Vous pouvez également regarder son intervention sur YouTube pour plus de détails.
Pourquoi les bases de données vectorielles sont importantes à l’ère de l’IA
Les applications et techniques modernes d’IA telles que la Retrieval Augmented Generation (RAG), les systèmes de recommandation, les chatbots alimentés par l’IA et les moteurs de recherche sémantique nécessitent un système fiable pour gérer efficacement d’énormes volumes de données non structurées. Les bases de données vectorielles sont des systèmes de stockage qui nous permettent de stocker, d’indexer et de récupérer ces données efficacement.
Les bases de données vectorielles comme Milvus et Zilliz Cloud sont équipées de méthodes d’indexation avancées parmi lesquelles les utilisateurs peuvent choisir pour une récupération des données efficace et rapide. Nombre d’entre elles, en particulier Milvus et Zilliz Cloud, proposent également des intégrations faciles avec des frameworks et plateformes d’IA populaires comme LangChain, Spark, Snowflake et Hugging Face, ce qui permet aux développeurs d’IA générative de créer plus facilement des applications d’IA sophistiquées. Grâce à différentes approches de recherche sémantique, telles que la recherche vectorielle dense et la recherche hybride de vecteurs denses et clairsemés, les développeurs peuvent obtenir les résultats les plus pertinents pour n’importe quel cas d’utilisation.
Une récente enquête menée en 2024 auprès de 1 000 développeurs en IA générative dans la communauté Milvus a identifié sept aspects qu’ils recherchent dans une base de données vectorielle avant d’envisager son utilisation dans leurs applications d’IA :
Qualité de la recherche : Quelle est la pertinence des résultats récupérés pour une requête donnée ?
Efficacité des coûts : Dans quelle mesure la base de données est-elle économique en termes de dépenses d’exploitation et de maintenance ?
Facilité d’utilisation : Dans quelle mesure la base de données est-elle conviviale et intuitive pour que les développeurs puissent l’implémenter et la gérer ?
Performance : À quelle vitesse et avec quelle efficacité la base de données peut-elle traiter les requêtes et renvoyer les résultats ?
Scalabilité : Dans quelle mesure la base de données peut-elle gérer l’augmentation des données et des locataires sans compromettre les performances ?
Haute disponibilité : Dans quelle mesure la base de données peut-elle maintenir de manière fiable sa disponibilité et prévenir la perte de données en cas de défaillances ?
Sécurité : Dans quelle mesure la base de données protège-t-elle les données sensibles et empêche-t-elle les accès non autorisés ?
Figure 1 : Principales considérations pour sélectionner une base de données vectorielle recueillies auprès de 1000 développeurs Gen AI
Milvus est très bien évalué pour la qualité de sa recherche. Il permet aux utilisateurs de choisir différentes méthodes d’indexation et de recherche vectorielle afin d’équilibrer les performances et le rappel, et de récupérer des informations pertinentes à la fois en profondeur et en contexte.
Les utilisateurs peuvent choisir parmi Flat, IVFFlat, HNSW, et bien d’autres méthodes d’indexation. Chaque méthode d’indexation présente des avantages et des inconvénients, et vous pouvez consulter une explication détaillée de ces méthodes dans cet article sur le choix d’un index vectoriel.
Pour les opérations de recherche vectorielle, la recherche dense, sparse, ou hybride peut être utilisée pour obtenir des résultats pertinents pour une requête. Nous pouvons également utiliser le filtrage scalaire avec l’approche par opération booléenne lors d’une opération de recherche afin d’affiner davantage le résultat.
L’introduction de Zilliz Cloud Serverless améliore considérablement les deuxième et troisième aspects les plus recherchés d’une base de données vectorielle mentionnés ci-dessus : l’efficacité des coûts et la facilité d’utilisation. Les sections suivantes montreront comment Zilliz Cloud Serverless améliore Milvus sur ces deux aspects.
Problèmes courants dans le développement d’applications d’IA
Lors du développement d’une application d’IA, la création d’un prototype est l’étape suivante après avoir décidé quelle base de données vectorielle utiliser. À cette étape, nous stockons généralement tout ou une partie de nos données dans la base de données vectorielle, puis nous choisissons un grand modèle de langage (LLM) et développons les prompts. Ensuite, nous sélectionnons un LLM et un ensemble de prompts qui répondent aux objectifs de qualité de notre cas d’utilisation. Enfin, nous déployons notre application d’IA en production.
Cependant, à mesure que la base d’utilisateurs de notre application d’IA augmente, la complexité de la maintenance et de la mise à l’échelle de notre infrastructure devient plus marquée. Nous devons prendre en compte des aspects tels que le coût par utilisateur, la surveillance des performances de l’application en production, la gestion de la multilocation, la gestion des pics de trafic, la correction des bogues logiciels, et plus encore.
Plus notre base d’utilisateurs est importante, plus il devient coûteux de répondre aux besoins des utilisateurs tout en maintenant des indicateurs de performance clés tels que la qualité de recherche, la latence et la disponibilité. Par conséquent, choisir la bonne infrastructure et la bonne architecture logicielle est crucial lors du déploiement de votre application d’IA dans un environnement de production.
Une solution pour faire évoluer votre application d’IA consiste à utiliser des clusters dédiés dans Zilliz Cloud.
Figure 2 : L’architecture des clusters dédiés Zilliz
Les clusters dédiés offrent un environnement et des ressources dédiés pour votre application d’IA, vous permettant de traiter des ensembles de données plus volumineux avec de meilleures performances. Ils fournissent des fonctionnalités avancées telles que :
Séparation entre le stockage et le calcul.
Pool de ressources élastique pour les charges de travail par lots.
Sauvegarde des données vers des systèmes de stockage d’objets comme S3.
Mise en cache des données pour des vitesses de récupération encore plus rapides.
Ces clusters sont hébergés dans le cloud, éliminant ainsi la nécessité de gérer une infrastructure locale.
Cependant, un inconvénient majeur des clusters dédiés est leur coût initial et récurrent élevé. Même lorsque le cluster est inactif, sans activité de recherche, il pourrait potentiellement coûter plus de 100 $ par mois. De plus, les performances peuvent se dégrader à mesure que la base d’utilisateurs des données stockées et le volume augmentent. Par conséquent, une meilleure solution est nécessaire pour construire une architecture qui soit non seulement rentable, mais qui puisse également évoluer à mesure que notre application d’IA atteint une base d’utilisateurs plus importante.
Zilliz Cloud Serverless, jusqu’à 50x d’économies
Zilliz Cloud Serverless représente les dernières avancées architecturales proposées par Zilliz afin de minimiser les coûts d’infrastructure pour faire fonctionner vos applications d’IA sans heurts en production. Il offre jusqu’à 50x d’économies par rapport aux bases de données vectorielles en mémoire grâce à des fonctionnalités telles que la tarification à l’usage et l’auto-scaling qui s’adaptent à diverses charges de travail. L’offre serverless est disponible chez les principaux fournisseurs cloud, notamment AWS et GCP, et sera bientôt disponible sur Azure.
Figure 3- Principaux avantages de Zilliz Cloud Serverless
Zilliz Cloud Serverless met en œuvre quatre technologies clés pour optimiser le coût de vos applications d’IA :
Clusters logiques et auto-scaling
Désagrégation des données de streaming et des données historiques
Stockage hiérarchisé adapté aux différents besoins de stockage des données
Multi-tenance et séparation des données chaudes et froides
Explorons maintenant chacune de ces technologies plus en détail.
Clusters logiques et auto-scaling
Zilliz Cloud Serverless introduit le concept de clusters logiques et d’auto-scaling. Un cluster logique correspond à une base de données dans un cluster physique. Un cluster physique se compose de plusieurs types de nœuds, chacun ayant sa propre fonctionnalité :
Nœuds proxy : acheminent le trafic, limitent les requêtes en fonction des quotas et évoluent selon le CPU et la bande passante réseau.
Nœuds de streaming : servent la recherche de données de streaming et évoluent en fonction du temps d’attente de la file d’écriture et de l’utilisation du CPU/de la mémoire.
Nœuds de requête : gèrent les requêtes de recherche de données historiques et évoluent en fonction du temps d’attente de la file de recherche et du CPU/de la mémoire.
Nœuds d’indexation : construisent des index sur les données blob stockées dans le stockage objet.
Figure 4 : Le schéma des clusters logiques
Le cluster logique fonctionne à l’aide d’un mécanisme d’authentification pour chaque tenant via une clé API. Chaque tenant dispose d’une clé API unique, que le système utilise pour acheminer les requêtes et s’assurer que les bonnes données sont récupérées lors des opérations de requête.
Lors des opérations d’écriture de données, toutes les données générées à la volée sont stockées pendant un intervalle de temps spécifique dans les nœuds de streaming. Cela garantit que les données récentes peuvent être récupérées avec une faible latence. Après un certain temps, ces données de streaming sont vidées dans un stockage blob (par exemple S3), où le nœud d’indexation construit un index de toutes les données.
Lors des opérations de requête, toutes les données indexées sont mises en cache sur les disques locaux des nœuds de requête. Cette méthode réduit considérablement les coûts de stockage par rapport à l’indexation en mémoire.
Désagrégation des données de streaming et des données historiques
Comme indiqué dans la section précédente, Zilliz Cloud Serverless sépare efficacement les données de streaming des données historiques en mettant en œuvre différents types de nœuds dans son architecture.
Les données de streaming désignent les données en temps réel, générées en continu et traitées à la volée, tandis que les données historiques désignent les données précédemment collectées et stockées. Les données de streaming contiennent des informations récentes et à jour, qui sont stockées dans les nœuds de streaming pendant une période spécifique, garantissant une récupération rapide lors des opérations de requête.
Après une période prédéterminée, les données à l’intérieur des nœuds de streaming sont vidées dans un stockage blob, devenant ainsi effectivement une partie des données historiques. Cette transition est cruciale, car le stockage blob est généralement une solution plus rentable pour de grands volumes de données qui ne nécessitent pas le même niveau d’accès immédiat que les données en temps réel ou fraîches.
Figure 5- Le workflow des différents nœuds dans un cluster logique
Lors des opérations de recherche, toutes les données historiques sont mises en cache dans les nœuds de requête. Le système fusionne ensuite les résultats de recherche provenant des nœuds de streaming et de requête afin de fournir des résultats complets.
Stockage hiérarchisé
L’une des principales raisons des coûts opérationnels élevés des bases de données vectorielles est que toutes les données sont stockées en RAM. Pour résoudre ce problème, Zilliz Cloud Serverless introduit une technologie de stockage de données hiérarchisé dans son architecture.
Le stockage de données hiérarchisé est simple : les données sont organisées en différents niveaux en fonction des exigences de performance, du coût et de la fréquence d’accès. La règle générale est que les données fréquemment consultées sont stockées dans un stockage plus coûteux et plus performant, tandis que les données moins fréquemment consultées sont stockées dans un stockage moins cher et plus lent. En mettant en œuvre différents niveaux de stockage pour chaque catégorie de données, nous pouvons optimiser le coût global du stockage des données.
Figure 6- Schéma du stockage hiérarchisé
Les données fréquemment consultées qui doivent être récupérées avec une faible latence sont stockées en RAM. Comme illustré ci-dessus, le stockage des données en RAM coûte environ 5 $ par Go de stockage. Cependant, en contrepartie, nous obtenons des résultats en environ 100 nanosecondes, ce qui est le plus rapide par rapport aux autres niveaux.
En revanche, les données moins fréquemment consultées sont stockées dans un stockage blob, tel qu’Amazon S3. Cela coûte environ 0,023 $ par Go de stockage, mais il faut plus de 10 millisecondes pour récupérer les résultats.
Multi-tenant et séparation chaud-froid
Zilliz Cloud Serverless introduit une mise en cache des données multicouche, en particulier pour les cas d’utilisation multi-tenant. Il distingue le stockage des données pour les tenants « chauds » et « froids ».
Un tenant chaud est un utilisateur très actif qui effectue fréquemment des recherches ou des requêtes de données. À l’inverse, un tenant froid est moins actif et effectue des recherches de données peu fréquemment.
Lorsque les tenants sont catégorisés comme chauds, leurs données sont stockées en mémoire locale, garantissant une récupération à faible latence. En revanche, si un tenant est catégorisé comme froid et souhaite effectuer une recherche de données, toutes les données doivent d’abord être chargées depuis le stockage blob (par exemple, S3), ce qui entraîne des temps de récupération plus longs que pour les tenants chauds.
Figure 7 : Séparation chaud-froid dans un cas d’utilisation multi-tenant
Une application peut être préchauffée afin d’améliorer la latence en chargeant toutes les données du stockage blob dans la mémoire locale. Ensuite, lorsque les utilisateurs accèdent à leur application d’IA, le processus de récupération peut être effectué avec une faible latence.
Zilliz Cloud Serverless met également en œuvre un clustering des données par clés de partition en arrière-plan afin d’accélérer davantage le processus de recherche de données. Lors de la récupération des données, le système recherche uniquement les données dans les partitions prometteuses plutôt que dans toutes les données disponibles.
Voici une comparaison des coûts entre les recherches chaudes, tièdes et froides :
| Recherche froide | Recherche tiède | Recherche chaude | |
| 1M, 768Dim | 2,3s | 80ms | 4ms |
| 10M, 768Dim | 7s | 150ms | 7ms |
Tableau : Comparaison de la latence entre recherche froide et recherche chaude chez un tenant unique.
Comme illustré, une recherche à froid (où toutes les données résident dans le stockage blob) nécessite plus de temps pour la récupération des données lors des opérations de recherche. Pour 10 millions d’embeddings, chacun constitué d’un vecteur à 768 dimensions, le système a besoin d’environ 7 secondes pour effectuer une opération de recherche. Cette vitesse reste acceptable pour les cas d’usage courants de l’IA générative comme le RAG. En revanche, le même scénario ne nécessite que 7 millisecondes si toutes les données résident dans la mémoire locale.
Cependant, effectuer une recherche à froid permet de réaliser d’importantes économies. Une base de données pour la recherche à froid coûte environ 16 pour une recherche à chaud. Cela représente une économie de coûts de 50x grâce à l’architecture Zilliz Cloud Serverless.
Quoi de neuf pour Zilliz Cloud ?
En plus de l’offre serverless, Zilliz a récemment annoncé de nouvelles fonctionnalités dans Zilliz Cloud afin de renforcer la prise en charge de l’exécution de workloads d’IA dans des environnements de production. Voici un aperçu rapide de ces nouveautés et améliorations :
Disponibilité générale (GA) de Serverless.
Service de migration ****pour transférer de manière transparente des données vectorielles entre des bases de données et d’autres systèmes de données
Fivetran Connector : une nouvelle intégration avec Fivetran qui étend considérablement les capacités d’ingestion de données non structurées depuis plus de 500 sources
Multi-réplicas : permet la réplication au niveau du cluster, améliorant considérablement les performances des requêtes et la disponibilité du système.
Auto-scaling (private preview) : Zilliz Cloud déploie une fonctionnalité d’auto-scaling en private preview qui répond à un défi courant dans les environnements de production : gérer la capacité des clusters en réponse à des demandes fluctuantes.
Une nouvelle région Zilliz Cloud en ligne : AWS Tokyo (ap-northeast-1), ce qui signifie une latence plus faible, de meilleures performances et une plus grande souveraineté des données pour les utilisateurs en Asie-Pacifique et dans les régions voisines.
Et plus encore ! Pour des informations plus détaillées, veuillez lire le dernier blog de lancement de Zilliz Cloud.
Conclusion
Zilliz Cloud Serverless représente la dernière avancée mise en œuvre par Zilliz pour optimiser le fonctionnement et le coût des systèmes d’applications d’IA. En tirant parti de quatre technologies clés, les utilisateurs peuvent potentiellement exploiter leurs applications d’IA à un coût jusqu’à 50 fois inférieur à celui des bases de données vectorielles en mémoire. Ces technologies comprennent les clusters logiques, la désagrégation des données en streaming et historiques, le stockage hiérarchisé et la séparation chaud-froid multi-tenant.
Si vous souhaitez commencer avec Zilliz Cloud Serverless, vous pouvez l’essayer gratuitement. Consultez cette page pour en savoir plus!
Continuer à lire
Why Teams Are Migrating from Weaviate to Zilliz Cloud — and How to Do It Seamlessly
Explore how Milvus scales for large datasets and complex queries with advanced features, and discover how to migrate from Weaviate to Zilliz Cloud.
Zilliz Cloud Enterprise Vector Search Powers High-Performance AI on AWS
Zilliz Cloud on AWS powers secure, scalable, ultra-fast vector search for enterprise AI apps, with BYOC, sub-10ms latency, and zero-DevOps simplicity.
Similarity Metrics for Vector Search
Exploring five similarity metrics for vector search: L2 or Euclidean distance, cosine distance, inner product, and hamming distance.