DiskANN Explorer : recherche vectorielle à l’échelle du milliard à partir de SSD
DiskANN Conserve une copie minuscule de chaque vecteur , compressée au format «PQ », sur RAM, ainsi que les vecteurs complets et le graphe sur SSD. La recherche parcourt le graphe à l’aide de comparaisons peu coûteuses RAM, puis reclasse les meilleurs candidats à l’aide d’une poignée de lectures de disque coûteuses.
Pourquoi « DiskANN » existe : le mur de la mémoire
Un simple « SSD » de base tient facilement sur le disque. La partie « RAM » tient dans n’importe quel ordinateur portable. Sans l’astuce de l’« PQ », il faudrait un serveur doté de centaines de Go d’ RAM s pour simplement charger l’ensemble de données.
Coût cumulé
PQ ≈ 1 µs, SSD ≈ 100 µs. Les nombres réels dépendent du matériel.Statistiques de recherche
Fonctionnement d’ DiskANN
- Construire le graphe « Vamana » : un graphe kNN à une seule couche (degré
R) optimisé pour un agencement séquentiel sur disque. Pas de hiérarchie — juste un grand graphe. - PQ Stockage quantifié et fractionné : chaque vecteur se voit attribuer un code d’ PQ ion minuscule (par exemple, 32 octets). Les codes d’ ion se trouvent sur RAM. Les vecteurs complets et les arêtes de graphe se trouvent sur SSD.
- Effectuez une recherche par faisceaux (Beam-walk) avec des distances de type « PQ » : à partir d’un point d’entrée fixe (le médœide), conservez un ensemble de candidats de taille
L. Sélectionnez le meilleur, étendez ses voisins, et estimez les distances en utilisant uniquement les codes «in-RAM » PQ. Aucune E/S disque n’est autorisée pendant la recherche. - Réclasser les finalistes à partir du disque : les distances des meilleurs éléments du « pool de candidats » ont été estimées à l’aide de l’ PQ. Lire leurs vecteurs complets à partir du disque et recalculer les distances exactes pour établir le classement définitif.
- top-K s de retour. Total des E/S disque = un petit nombre de lectures aléatoires, généralement moins de 20.
Le métier
- Pourquoi ce système est évolutif : RAM ne contient que des codes compressés. Un ensemble de données de 1 milliard de vecteurs avec une « PQ » de 32 octets nécessite environ 32 Go RAM — ce qui tient sur un seul poste de travail.
- Pourquoi est-ce plus lent que HNSW: SSD? Les lectures aléatoires sont environ 100 fois plus lentes que RAM. Même avec seulement une dizaine de lectures, la latence des requêtes est principalement due au disque.
- Pourquoi cette méthode reste plus performante que « IVF_PQ » en termes de rappel : l’étape de reclassement corrige les erreurs de quantification que les méthodes basées uniquement sur l’ PQ e ne peuvent pas corriger.
Le modèle mental : « PQ » (est-ce que ce voisinage est prometteur ?) est le test peu coûteux. Les lectures sur disque constituent la vérification coûteuse « laissez-moi vérifier concrètement ». « DiskANN » (est-ce que ce vecteur est un candidat ?) effectue l’essentiel de son travail grâce à ce test peu coûteux.
Qu’est-ce que « DiskANN » ?
DiskANN est un index approximatif du plus proche voisin basé sur un graphe, conçu pour les ensembles de données qui ne tiennent pas dans RAM. Il construit un graphe de type «Vamana » à une seule couche, organisé pour un accès efficace au disque, conserve en mémoire un code minuscule quantifié par produit (PQ) pour chaque vecteur, et stocke les vecteurs en précision pleine ainsi que les arêtes du graphe sur SSD. Les recherches parcourent le graphe à l’aide de comparaisons peu coûteuses de type « in-RAM » ( PQ ) et n’accèdent au disque que pour reclasser une poignée de finalistes.
Dans « Milvus », « DiskANN » optimise l’option d’indexation sur disque : les collections de l’ordre du milliard deviennent consultables sur des machines disposant de dizaines — et non de centaines — de gigaoctets d’ RAM, tandis que l’étape de reclassement sur disque maintient le rappel à un niveau proche de celui des index de graphes en mémoire.
Ce que contrôlent les boutons
R(degré du graphe, temps de construction) : nombre maximal d’arêtes par nœud dans le graphe « Vamana ». Un R plus élevé offre une meilleure connectivité et un meilleur rappel, au prix d’un graphe plus volumineux sur le disque et de constructions plus lentes.L/search_list(temps de requête) : l’ensemble de candidats conservé pendant la recherche par faisceau — le principal paramètre de rappel/latence, équivalent à HNSW's ef. Il doit être au moins égal à votre top-K.- Budget de reclassement : nombre de finalistes dont les vecteurs complets sont récupérés depuis SSD pour un calcul exact du score. Chaque opération correspond à une lecture aléatoire sur disque ; c’est donc là que réside la latence de la requête — et c’est également là que les erreurs d’approximation de l’ PQ e sont corrigées.
DiskANN vs HNSW vs IVF
Optez pour « DiskANN » lorsque le jeu de données (ou la consommation de mémoire) dépasse les capacités de « RAM » : cette option traite les requêtes à haut rappel avec une fraction de la mémoire, en échange d’une latence de l’ordre de la milliseconde, dominée par les lectures « SSD ». Si tout tient facilement en mémoire, « HNSW » répond plus rapidement. Si vous avez besoin d’une construction rapide d’index ou d’économies de mémoire modérées sans recourir au disque, les variantes « IVF » constituent un compromis.
Foire aux questions
Quand dois-je utiliser « DiskANN » plutôt que « HNSW » ?
Lorsque vos vecteurs ne tiennent plus dans la mémoire RAM — ou que l’ RAM nécessaire pour les contenir coûte plus cher que ce que vous êtes prêt à payer. Un milliard de vecteurs flottants à 768 dimensions nécessite environ 3 To de mémoire pour HNSW, mais seulement quelques dizaines de Go de RAM ainsi qu’un SSD avec DiskANN. Si l’ensemble de données tient facilement en mémoire, HNSW reste le choix offrant la plus faible latence.
De quel matériel « DiskANN » a-t-il besoin ?
Une « fast NVMe » ( SSD ) est une exigence essentielle, car la latence de la requête est principalement due à une poignée de lectures aléatoires sur disque (chacune d’environ 100 µs). Les besoins en « RAM » sont modestes : environ les codes « PQ » (par exemple, 32 à 64 octets par vecteur) plus les tampons de travail.
L’ DiskANN est-il plus lent que les index en mémoire tels que HNSW?
Par requête, oui — généralement quelques millisecondes, contre moins d’une milliseconde pour l’ HNSW en mémoire, car chaque reclassement sur disque est environ 100 fois plus lent qu’un accès RAM. Le compromis réside dans le coût : DiskANN traite le même ensemble de données avec un temps de traitement ( RAM ) inférieur d’un ordre de grandeur, tout en conservant un rappel supérieur à 90–95 %.
Comment « DiskANN » parvient-il à maintenir un rappel élevé malgré la compression « PQ » ?
PQ Les codes ne servent qu’à orienter la traversée du graphe, et non à produire des scores finaux. Avant de renvoyer les résultats, DiskANN lit les vecteurs en précision totale des meilleurs candidats à partir de SSD et les reclasse avec exactitude, en corrigeant l’erreur de quantification que les index basés uniquement sur l’ PQ, tels que IVF_PQ, ne peuvent pas corriger.
Pour aller plus loin : consultez la documentation «DiskANN » pour connaître la configuration requise, ou consultez «Index Explained» pour obtenir le guide de décision complet.
Continuez à explorer
Explorateur HNSW
Suivez étape par étape la recherche sur un graphe multicouche — des sauts d’autoroute aux parcours locaux.
FLAT vs IVF
Comparaison côte à côte entre la recherche par force brute et la recherche par grappes. Ajustez l’ nprobe s en temps réel.
Laboratoire des mesures de similarité
Faites glisser un point de requête et basculez entre « L2 », « Cosine » et « IP » pour observer comment la notion de « plus proche » évolue.