Ce que les utilisateurs de Milvus nous ont appris en 2024

Vue d’ensemble

Alors que Milvus s’épanouissait en 2024 avec des versions majeures et un écosystème open-source florissant, un trésor caché de points de vue d’utilisateurs se formait discrètement dans notre communauté sur Discord. Cette compilation des discussions de la communauté offrait une occasion unique de comprendre directement les défis de nos utilisateurs. Intrigué par cette ressource inexploitée, je me suis lancé dans une analyse complète de chaque fil de discussion de l’année, à la recherche de modèles qui pourraient nous aider à compiler une foire aux questions pour les utilisateurs de Milvus.

Mon analyse a révélé trois domaines principaux dans lesquels les utilisateurs cherchaient constamment des conseils : L'optimisation des performances, les stratégies de déploiement et la gestion des données. Les utilisateurs ont souvent discuté de la manière d'affiner Milvus pour les environnements de production et de suivre efficacement les mesures de performances. En ce qui concerne le déploiement, la communauté s'est efforcée de sélectionner les déploiements appropriés, de choisir les index de recherche optimaux et de résoudre les problèmes dans les configurations distribuées. Les conversations sur la gestion des données ont porté sur les stratégies de migration des données d'un service à l'autre et sur la sélection des modèles d'intégration.

Examinons chacun de ces domaines plus en détail.

Déploiement

Milvus propose des modes de déploiement flexibles pour s'adapter à différents cas d'utilisation. Toutefois, certains utilisateurs ont du mal à trouver le bon choix et veulent être sûrs qu'ils le font "correctement".

Quel type de déploiement dois-je choisir ?

Une question très fréquente est de savoir quel déploiement choisir parmi Milvus Lite, Standalone et Distributed. La réponse dépend principalement de la taille de votre base de données vectorielle et de l'importance du trafic qu'elle supportera :

Milvus Lite

Si vous faites du prototypage sur votre système local avec quelques millions de vecteurs, ou si vous cherchez une base de données vectorielle intégrée pour les tests unitaires et le CI/CD, vous pouvez utiliser Milvus Lite. Notez que certaines fonctionnalités plus avancées comme la recherche plein texte ne sont pas encore disponibles dans Milvus Lite mais le seront bientôt.

Milvus Standalone

Si votre système doit servir le trafic de production et/ou si vous devez stocker entre quelques millions et cent millions de vecteurs, vous devriez utiliser Milvus Standalone, qui compile tous les composants de Milvus dans une seule image Docker. Il existe une variante qui ne prend que ses dépendances de stockage persistant (minio) et de magasin de métadonnées (etcd) en tant qu'images séparées.

Milvus distribué

Pour les déploiements à grande échelle desservant le trafic de production, comme le service de milliards de vecteurs à des milliers de QPS, vous devez utiliser Milvus Distributed. Certains utilisateurs peuvent vouloir effectuer un traitement par lots hors ligne à grande échelle, par exemple pour la déduplication des données ou le couplage des enregistrements, et la future version de Milvus 3.0 fournira un moyen plus efficace de le faire par ce que nous appelons un lac vectoriel.

Service entièrement géré

Pour les développeurs qui souhaitent se concentrer sur le développement d'applications sans se soucier de DevOps, Zilliz Cloud est le service Milvus entièrement géré qui offre un niveau gratuit.

Voir "Vue d'ensemble des déploiements Milvus" pour plus d'informations.

De quelle quantité de mémoire, de stockage et de calcul aurai-je besoin ?

Cette question revient souvent, non seulement pour les utilisateurs existants de Milvus, mais aussi pour ceux qui se demandent si Milvus convient à leur application. La combinaison exacte de la quantité de mémoire, de stockage et de calcul dont un déploiement aura besoin dépend d'une interaction complexe de facteurs.

Les encastrements vectoriels diffèrent en dimensionnalité en raison du modèle utilisé. Certains index de recherche vectorielle sont entièrement stockés en mémoire, tandis que d'autres stockent les données sur disque. En outre, de nombreux index de recherche sont capables de stocker une copie compressée (quantifiée) des enchâssements et nécessitent de la mémoire supplémentaire pour les structures de données graphiques. Il ne s'agit là que de quelques facteurs qui affectent la mémoire et le stockage.

Outil de dimensionnement des ressources Milvus

Heureusement, Zilliz (l'équipe qui s'occupe de Milvus) a conçu un outil de dimensionnement des ressources qui répond parfaitement à cette question. Saisissez la dimensionnalité de votre vecteur, le type d'index, les options de déploiement, etc. et l'outil estime les besoins en CPU, en mémoire et en stockage pour les différents types de nœuds Milvus et leurs dépendances. Votre kilométrage peut varier, c'est pourquoi un test de charge réel avec vos données et un échantillon de trafic est toujours une bonne idée.

Quel indice vectoriel ou quelle mesure de distance dois-je choisir ?

De nombreux utilisateurs ne sont pas sûrs de l'index qu'ils doivent choisir et de la manière de définir les hyperparamètres. Tout d'abord, il est toujours possible de reporter le choix du type d'index sur Milvus en sélectionnant AUTOINDEX. Toutefois, si vous souhaitez sélectionner un type d'index spécifique, quelques règles empiriques peuvent vous servir de point de départ.

Index en mémoire

Souhaitez-vous payer le coût de l'intégration de votre index dans la mémoire ? Un index en mémoire est généralement le plus rapide, mais aussi le plus coûteux. Voir "Index en mémoire" pour une liste des index pris en charge par Milvus et les compromis qu'ils font en termes de latence, de mémoire et de rappel.

N'oubliez pas que la taille de votre index n'est pas simplement le nombre de vecteurs multiplié par leur dimensionnalité et leur taille en virgule flottante. La plupart des index quantifient les vecteurs pour réduire l'utilisation de la mémoire, mais nécessitent de la mémoire pour des structures de données supplémentaires. Les autres données non vectorielles (scalaires) et leur index occupent également de l'espace mémoire.

Index sur disque

Lorsque votre index ne tient pas dans la mémoire, vous pouvez utiliser l'un des "index sur disque" fournis par Milvus. DiskANN et MMap sont deux choix qui présentent des compromis très différents en termes de latence et de ressources.

DiskANN stocke une copie hautement compressée des vecteurs en mémoire, et les vecteurs non compressés ainsi que les structures de recherche de graphes sur le disque. Il utilise des idées astucieuses pour rechercher l'espace vectoriel tout en minimisant les lectures sur le disque et tire parti de la vitesse d'accès aléatoire des disques SSD. Pour une latence minimale, le SSD doit être connecté via NVMe plutôt que SATA afin d'obtenir les meilleures performances d'E/S.

Techniquement parlant, MMap n'est pas un type d'index, mais fait référence à l'utilisation de la mémoire virtuelle avec un index en mémoire. Avec la mémoire virtuelle, les pages peuvent être échangées entre le disque et la RAM selon les besoins, ce qui permet d'utiliser efficacement un index beaucoup plus grand si les schémas d'accès sont tels que seule une petite partie des données est utilisée à la fois.

DiskANN présente un temps de latence excellent et constant. MMap a une latence encore meilleure lorsqu'il accède à une page en mémoire, mais les échanges fréquents de pages provoquent des pics de latence. MMap peut donc présenter une plus grande variabilité de latence, en fonction des schémas d'accès à la mémoire.

Index GPU

Une troisième option consiste à construire un index en utilisant la mémoire et le calcul GPU. La prise en charge GPU de Milvus est assurée par l'équipe Nvidia RAPIDS. La recherche vectorielle GPU peut avoir une latence plus faible qu'une recherche CPU correspondante, bien qu'il faille généralement des centaines ou des milliers de QPS de recherche pour exploiter pleinement le parallélisme du GPU. En outre, les GPU disposent généralement de moins de mémoire que la RAM du CPU et leur fonctionnement est plus coûteux.

Mesures de distance

Il est plus facile de répondre à la question de savoir quelle mesure de distance choisir pour mesurer la similarité entre les vecteurs. Il est recommandé de choisir la même mesure de distance que celle avec laquelle votre modèle d'intégration a été entraîné, qui est généralement COSINE (ou IP lorsque les entrées sont normalisées). La source de votre modèle (par exemple, la page du modèle sur HuggingFace) fournira des précisions sur la métrique de distance utilisée. Zilliz a également mis au point un tableau pratique qui permet de le vérifier.

Pour résumer, je pense qu'une grande partie de l'incertitude concernant le choix de l'index tourne autour de l'incertitude sur la façon dont ces choix affectent le compromis latence/utilisation des ressources/rappel de votre déploiement. Je recommande d'utiliser les règles empiriques ci-dessus pour décider entre les index en mémoire, sur disque ou GPU, puis d'utiliser les directives de compromis données dans la documentation Milvus pour choisir un index particulier.

Pouvez-vous réparer mon déploiement Milvus Distributed défectueux ?

De nombreuses questions tournent autour des problèmes de mise en place et de fonctionnement d'un déploiement de Milvus Distributed, avec des questions relatives à la configuration, à l'outillage et aux journaux de débogage. Il est difficile de donner une solution unique car chaque question semble différente de la précédente, mais heureusement Milvus dispose d'un Discord dynamique où vous pouvez demander de l'aide, et nous proposons également des heures de bureau en tête-à-tête avec un expert.

Comment déployer Milvus sur Windows ?

Une question qui est revenue à plusieurs reprises concerne la manière de déployer Milvus sur les machines Windows. Sur la base de vos commentaires, nous avons réécrit la documentation à ce sujet : voir Exécuter Milvus dans Docker (Windows) pour savoir comment procéder, en utilisant Windows Subsystem for Linux 2 (WSL2).

Performances et profilage

Après avoir choisi un type de déploiement et l'avoir fait fonctionner, les utilisateurs veulent être sûrs d'avoir pris des décisions optimales et souhaitent établir un profil des performances et de l'état de leur déploiement. De nombreuses questions se posent sur la manière d'établir le profil des performances, d'observer l'état et d'obtenir un aperçu de ce qui se passe et pourquoi.

Comment mesurer les performances ?

Les utilisateurs souhaitent vérifier les paramètres liés aux performances de leur déploiement afin de comprendre les goulets d'étranglement et d'y remédier. Les mesures mentionnées comprennent la latence moyenne des requêtes, la distribution des latences, le volume des requêtes, l'utilisation de la mémoire, le stockage sur disque, etc. Ces mesures peuvent être observées à partir du système de surveillance. En outre, Milvus 2.5 introduit un nouvel outil appelé WebUI (les commentaires sont les bienvenus !), qui vous permet d'accéder à davantage d'informations internes au système, telles que l'état de compactage des segments, à partir d'une interface Web conviviale.

Que se passe-t-il dans Milvus en ce moment (c'est-à-dire observer l'état) ?

Dans le même ordre d'idées, les utilisateurs souhaitent observer l'état interne de leur déploiement. Il s'agit notamment de comprendre pourquoi un index de recherche est si long à construire, de déterminer si le cluster est sain et de comprendre comment une requête est exécutée entre les nœuds. Il est possible de répondre à bon nombre de ces questions grâce à la nouvelle interface WebUI, qui permet de savoir ce que fait le système en interne.

Comment fonctionne un aspect (complexe) de la structure interne ?

Les utilisateurs avancés souhaitent souvent avoir une certaine compréhension des éléments internes de Milvus, par exemple en ce qui concerne le scellement des segments ou la gestion de la mémoire. L'objectif sous-jacent est généralement d'améliorer les performances et parfois de déboguer des problèmes. La documentation, en particulier dans les sections "Concepts" et "Guide d'administration", est utile à cet égard. Voir par exemple les pages "Vue d'ensemble de l'architecture Milvus" et "Compaction du clustering". Nous continuerons à améliorer la documentation sur les éléments internes de Milvus, à la rendre plus facile à comprendre, et nous accueillerons avec plaisir tout retour d'information ou toute demande via Discord.

Quel modèle d'intégration dois-je choisir ?

Une question liée aux performances qui a été soulevée à plusieurs reprises lors de réunions, d'heures de bureau et sur Discord est de savoir comment choisir un modèle d'intégration. Il est difficile de donner une réponse définitive à cette question, mais nous recommandons de commencer par des modèles par défaut comme all-MiniLM-L6-v2.

Comme pour le choix de l'index de recherche, il existe des compromis entre le calcul, le stockage et le rappel. Un modèle d'intégration avec une plus grande dimension de sortie nécessitera plus de stockage, toutes choses égales par ailleurs, mais entraînera probablement un meilleur rappel des éléments pertinents. Les modèles d'intégration plus grands, pour une dimension fixe, sont généralement plus performants que les plus petits en termes de rappel, mais au prix d'une augmentation des calculs et du temps. Les tableaux de bord qui classent les performances des modèles d'intégration, tels que MTEB, sont basés sur des références qui peuvent ne pas correspondre à vos données et à votre tâche spécifiques.

Il n'est donc pas judicieux de penser à un "meilleur" modèle d'intégration. Commencez par un modèle qui a un rappel acceptable et qui respecte votre budget de calcul et de temps pour le calcul des embeddings. D'autres optimisations, comme le réglage fin sur vos données ou l'exploration empirique du compromis calcul/rappel, peuvent être reportées à une fois que vous aurez un système fonctionnel en production.

Gestion des données

La manière de déplacer les données dans et hors d'un déploiement Milvus est un autre thème principal des discussions sur Discord, ce qui n'est pas surprenant étant donné l'importance de cette tâche pour la mise en production d'une application.

Comment migrer des données de X vers Milvus ? Comment migrer les données d'un système autonome vers un système distribué ? Comment migrer de 2.4.x à 2.5.x ?

Un nouvel utilisateur souhaite généralement intégrer des données existantes dans Milvus à partir d'une autre plate-forme, y compris des moteurs de recherche traditionnels comme Elasticsearch et d'autres bases de données vectorielles comme Pinecone ou Qdrant. Les utilisateurs existants peuvent également vouloir migrer leurs données d'un déploiement Milvus à un autre, ou de Milvus auto-hébergé à Zilliz Cloud entièrement géré.

Le Vector Transport Service (VTS) et le service de migration géré sur Zilliz Cloud sont conçus à cet effet.

Comment enregistrer et charger des sauvegardes de données ? Comment exporter des données depuis Milvus ?

Milvus dispose d'un outil dédié, milvus-backup, pour prendre des instantanés sur un stockage permanent et les restaurer.

Prochaines étapes

J'espère que cet article vous a donné quelques indications sur la manière de relever les défis courants rencontrés lors de la construction d'une base de données vectorielles. Cela nous a définitivement aidés à jeter un nouveau coup d'œil à notre documentation et à notre feuille de route des fonctionnalités afin de continuer à travailler sur des éléments qui peuvent aider notre communauté à mieux réussir avec Milvus. J'aimerais insister sur le fait que vos choix vous placent à différents points d'un espace de compromis entre le calcul, le stockage, la latence et le rappel. Vous ne pouvez pas maximiser tous ces critères de performance simultanément - il n'y a pas de déploiement "optimal". Cependant, en comprenant mieux le fonctionnement de la recherche vectorielle et des systèmes de bases de données distribuées, vous pouvez prendre une décision en connaissance de cause.

Après avoir parcouru le grand nombre de messages de 2024, je me suis demandé pourquoi un humain devrait faire cela. L'IA générative n'a-t-elle pas promis de résoudre une telle tâche consistant à traiter de grandes quantités de texte et à en extraire des informations ? Rejoignez-moi dans la deuxième partie de ce billet (à venir), où j'étudierai la conception et la mise en œuvre d'un système multi-agents permettant d'extraire des informations des forums de discussion.

Merci encore et j'espère vous voir dans le Discord de la communauté et lors de nos prochains meetups sur les données non structurées. Pour une assistance plus pratique, nous vous invitons à réserver une heure de bureau individuelle. Vos commentaires sont essentiels à l'amélioration de Milvus !