Relever le défi du milliard de vecteurs dans Azure AI Search

Par Mirko Peters · 2026-08-26

Bienvenue dans notre plongée au cœur de l’un des défis les plus pressants de l’intelligence artificielle en entreprise : faire passer la recherche vectorielle à l’échelle de milliards d’enregistrements. Si vous…

Traduit automatiquement par IA à partir de l'article original. Lire l'original en anglais

Bienvenue dans notre analyse approfondie de l’un des défis les plus pressants de l’intelligence artificielle d’entreprise moderne : faire passer la recherche vectorielle à l’échelle de milliards d’enregistrements. Si vous travaillez avec des systèmes de génération augmentée par récupération (RAG), des moteurs de recherche sémantique ou des assistants IA, vous avez probablement constaté la vitesse à laquelle les données s’accumulent. Lorsque les organisations ingèrent des millions, parfois des milliards, de documents, d’images et d’interactions utilisateur, les architectures de recherche traditionnelles commencent à céder sous la pression. C’est pourquoi comprendre le fonctionnement de l’indexation vectorielle à l’échelle du milliard n’est plus facultatif pour les architectes et les développeurs : c’est devenu indispensable.

Dans cet article de blog complet, nous détaillerons les obstacles techniques des espaces vectoriels à haute dimension, nous comparerons deux des algorithmes d’indexation basés sur des graphes les plus répandus du secteur, le Hierarchical Navigable Small World (HNSW) et DiskANN de Microsoft, et nous verrons comment Azure AI Search vous permet de gérer ces charges de travail efficacement. Que vous ajustiez des paramètres de mémoire, que vous cherchiez à maîtriser les coûts de l’infrastructure matérielle ou que vous souhaitiez maximiser le rappel de la recherche, ce guide vous fournira la feuille de route technique dont vous avez besoin. Pour une présentation audio de ces concepts, n’hésitez pas à écouter l’épisode de podcast associé HNSW vs DiskANN for Vector Search in Azure AI Search sur M365 FM.

Le problème du milliard de vecteurs dans Azure AI Search

Défis de la recherche vectorielle à l’échelle du milliard

Vous êtes confronté au problème du milliard de vecteurs lorsque vous devez indexer et parcourir d’énormes jeux de données dans le cadre de l’IA d’entreprise. La gestion de milliards de vecteurs soulève des défis techniques particuliers. Vous devez concevoir des systèmes d’indexation efficaces, capables de traiter des données à grande échelle sans ralentissement. Les mises à jour en temps réel sont importantes, car vous voulez que vos résultats de recherche restent à jour et pertinents. La maîtrise des embeddings à haute dimension est également essentielle pour obtenir des résultats de recherche précis.

Lorsque vous travaillez avec des jeux de données à l’échelle du milliard, vous rencontrez plusieurs limites :

• Une dimensionnalité élevée augmente les coûts de calcul et peut ralentir les performances de recherche.
• L’écart sémantique entre les représentations vectorielles et le sens réel des données peut entraîner des imprécisions.
• Le nettoyage des données obsolètes devient difficile, ce qui complique la suppression des informations périmées des index.
• La qualité des vecteurs dépend du modèle d’embedding choisi, ce qui influe sur la précision de la recherche.
• La scalabilité alourdit les besoins en mémoire et peut allonger les temps de recherche.
• Le problème du démarrage à froid rend difficile la recherche de nouveaux éléments en l’absence de représentations vectorielles satisfaisantes.
• L’interprétabilité est faible : il peut donc être difficile de comprendre pourquoi un résultat apparaît.

Ces défis font du problème du milliard de vecteurs l’un des plus complexes de l’IA moderne.

Pourquoi le choix de l’algorithme est important

Le choix de votre algorithme a un impact direct sur la manière dont vous résolvez le problème du milliard de vecteurs. Si vous optez pour un algorithme comme HNSW, vous bénéficiez d’un accès rapide et d’une recherche efficace sur de grands jeux de données. Toutefois, il nécessite beaucoup de RAM, ce qui peut faire grimper les coûts. D’autres algorithmes, comme le KNN exhaustif, offrent une grande précision mais demandent beaucoup plus de calcul et conviennent donc mieux aux jeux de données plus petits. Le bon algorithme vous aide à trouver l’équilibre entre vitesse, précision et consommation de ressources. Vous pouvez optimiser les performances de votre application en adaptant l’algorithme à vos besoins. Ce choix détermine dans quelle mesure vous gérez les jeux de données massifs et ce que vous dépensez en matériel.

Présentation d’Azure AI Search

Azure AI Search vous offre une plateforme puissante pour relever le défi du milliard de vecteurs. Vous pouvez prétraiter vos données à l’aide d’outils avancés de nettoyage et d’enrichissement, ce qui améliore la qualité de vos vecteurs avant l’indexation. La plateforme organise vos informations dans une base de données vectorielle conçue pour les tâches de récupération et les besoins de recherche modernes. Vous bénéficiez de fonctionnalités de recherche et de récupération robustes, dont le traitement du langage naturel pour la compréhension sémantique. La sécurité est renforcée grâce au chiffrement et aux contrôles d’accès qui protègent vos données.

Azure AI Search s'intègre facilement aux autres services Microsoft Azure et aux plateformes tierces. Vous pouvez utiliser la recherche hybride, qui combine la recherche par mots-clés et la recherche vectorielle pour obtenir les meilleurs résultats. Le réglage du classement et de la pertinence vous permet d’ajuster la manière dont les résultats de recherche s’affichent, les rendant ainsi plus utiles pour vos utilisateurs. La plateforme propose également des expériences de recherche intelligentes, comme la saisie semi-automatique et les résultats suggérés. Reposant sur l’infrastructure mondiale d’Azure, Azure AI Search offre l’échelle et la fiabilité dont vous avez besoin pour de volumineux jeux de données et des projets de données à grande échelle.

Index basés sur un graphe : HNSW et DiskANN

Qu’est-ce que HNSW ?

Vous avez peut-être entendu parler de HNSW, qui signifie « hierarchical navigable small world ». Cet algorithme d’index basé sur un graphe vous aide à trouver rapidement des vecteurs similaires dans de grands jeux de données. HNSW construit une structure de graphe multicouche qui relie les points de données de manière à rendre la recherche rapide et précise. Chaque couche du graphe présente une densité différente : les couches supérieures comptent moins de nœuds, et les couches inférieures en comptent davantage. Cette conception vous permet de commencer votre recherche par le haut, puis de descendre en affinant progressivement vos résultats. HNSW est optimisé pour la recherche vectorielle en mémoire : il conserve l’intégralité du graphe dans la RAM. Cette approche offre des résultats à faible latence, mais elle implique aussi de disposer de beaucoup de mémoire lorsque votre jeu de données augmente.

Qu’est-ce que DiskANN ?

DiskANN est la réponse de Microsoft aux défis de la recherche vectorielle à l’échelle du milliard. Cet index basé sur un graphe repose sur une approche hybride combinant mémoire et stockage SSD. DiskANN vous permet de stocker la majeure partie de votre index sur des SSD, bien moins coûteux que la RAM. Vous ne conservez en mémoire que les données de navigation les plus importantes. Cette conception vous aide à gérer de très grands jeux de données sans coûts matériels élevés. DiskANN utilise l’algorithme de graphe Vamana pour guider votre recherche dans les données. Il applique également une méthode d’élagage spécifique qui maintient le graphe diversifié et efficace. Le DiskANN de Microsoft alimente Azure AI Search et d’autres services, ce qui en fait une innovation majeure pour l’IA en entreprise.

Fonctionnement de HNSW

Construction du graphe

HNSW construit son index basé sur un graphe en créant une hiérarchie de graphes de recherche. Vous partez d’une structure vide. Le premier vecteur ajouté devient le seul nœud de la couche supérieure. Pour chaque nouveau vecteur, HNSW détermine, par un processus aléatoire, le nombre de couches qu’il doit rejoindre. Le nouveau vecteur se connecte à ses voisins les plus proches dans chaque couche, jusqu’au maximum qui lui est attribué. La couche supérieure compte le moins de nœuds, ce qui en fait un bon point de départ pour la recherche. Les couches inférieures en comptent davantage, ce qui permet des recherches plus fines. HNSW peut mettre à jour son graphe sans reconstruction complète, ce qui vous permet d’ajouter de nouvelles données à mesure que vos besoins évoluent.

Processus de recherche

Lorsque vous effectuez une recherche avec HNSW, vous commencez au niveau de la couche supérieure du graphe. Vous utilisez des liens à longue portée pour vous rapprocher rapidement de la zone où se trouve peut-être votre vecteur cible. À mesure que vous descendez de couche en couche, les connexions deviennent plus denses. Cela vous aide à affiner votre recherche et à vous rapprocher de la meilleure correspondance. Sur la couche la plus basse, HNSW utilise une recherche par faisceau (beam search) pour trouver les voisins les plus proches. Ce processus offre des résultats rapides et précis, en particulier lorsque la totalité du graphe tient en mémoire.

• Principes de conception de HNSW :
  • Optimisé pour les opérations en mémoire, offrant une faible latence et un rappel élevé.
  • Utilise une structure de graphe multicouche fondée sur les réseaux à petit monde.
  • Applique une stratégie d’élagage pour supprimer les arêtes redondantes et favoriser la diversité.
  • Le processus de recherche consiste à descendre les couches, en commençant par des liens clairsemés à longue portée et en finissant par une recherche par faisceau sur la couche de base.

Vous pouvez constater que HNSW et DiskANN reposent tous deux sur un index basé sur un graphe, mais que leurs conceptions répondent à des besoins différents. HNSW convient le mieux lorsque vous pouvez tout conserver en mémoire. DiskANN vous permet de passer à l’échelle du milliard de vecteurs grâce aux SSD, ce qui en fait une solution idéale pour les charges de travail d’entreprise dans Azure AI Search.

Fonctionnement de DiskANN

Architecture hybride mémoire et SSD

Vous rencontrez une approche singulière lorsque vous utilisez DiskANN pour la recherche de milliards de vecteurs. DiskANN combine la mémoire et le stockage SSD pour créer une architecture hybride. Cette conception vous permet de stocker la majeure partie de votre index vectoriel sur des SSD, qui coûtent moins cher que la RAM. Vous ne conservez en mémoire que les données de navigation essentielles. Cette méthode vous permet d’étendre votre recherche à des milliards de vecteurs sans recourir à du matériel coûteux.

DiskANN repose sur deux techniques principales pour optimiser le stockage et la vitesse :

• Graphe Vamana : vous utilisez cette structure pour naviguer efficacement dans l’index.
• Quantification de produit (PQ) : vous compressez les vecteurs en mémoire, ce qui réduit l’utilisation de la RAM.

Vous bénéficiez d’un processus d’exécution des requêtes en deux phases. Dans la première phase, DiskANN utilise les vecteurs compressés par PQ en RAM pour identifier rapidement un ensemble de candidats. Vous n’avez pas besoin de lire le disque durant cette étape. Dans la seconde phase, DiskANN récupère les vecteurs en pleine précision depuis le SSD pour l’ensemble de candidats. Vous calculez ensuite les distances exactes afin de trouver les meilleures correspondances. Ce processus vous offre un rappel élevé et une faible latence, tout en maintenant des besoins en mémoire réduits.

Astuce : l’architecture hybride mémoire et SSD de DiskANN permet une recherche à l’échelle du web sur du matériel standard. Vous pouvez stocker les index vectoriels sur des SSD plutôt que dans la RAM, ce qui rend les applications à grande échelle plus abordables.

Processus de recherche

Vous lancez une recherche dans DiskANN en parcourant le graphe Vamana à l’aide de vecteurs compressés en mémoire. Cette étape vous aide à identifier rapidement des candidats prometteurs. Vous évitez les lectures disque à ce stade, ce qui accélère le processus. Une fois l’ensemble de candidats constitué, DiskANN passe à la phase suivante.

Vous récupérez les vecteurs en pleine précision depuis le SSD pour chaque candidat. Vous calculez les distances exactes entre votre requête et ces candidats. Ce processus en deux phases garantit des résultats précis sans ralentir votre recherche. Vous obtenez un rappel élevé, car DiskANN examine les meilleurs candidats en détail. Vous conservez également une faible latence, car la majeure partie du travail s’effectue en mémoire.

Le processus de recherche de DiskANN convient parfaitement aux jeux de données massifs. Vous pouvez traiter des milliards de vecteurs sans disposer de quantités énormes de RAM. Vous obtenez des résultats rapides et fiables, même lorsque vos données augmentent. Cela fait de DiskANN un choix judicieux pour les charges de travail d’IA en entreprise dans Azure AI Search.

Vous constatez que l’architecture hybride et le processus de recherche de DiskANN vous aident à résoudre efficacement le problème des milliards de vecteurs. Vous pouvez étendre votre recherche, réduire les coûts et maintenir les performances à mesure que vos données s’accroissent.

Forces et faiblesses

Avantages et inconvénients de HNSW

Vous choisissez souvent HNSW pour la récupération de vecteurs, car il offre une vitesse de recherche à l’état de l’art et un rappel élevé. Lorsque vous ajustez correctement HNSW, vous obtenez des résultats rapides et des correspondances précises. Vous gérez bien les données vectorielles à haute dimension, ce qui est essentiel pour les charges de travail d’IA modernes. Vous profitez également des ajouts incrémentiels, ce qui vous permet de mettre à jour votre index sans tout reconstruire.

Voici un aperçu rapide des forces et des faiblesses de HNSW :

HNSW passe bien à l’échelle, car sa construction d’index a une complexité en O(N log N). La construction parallèle vous permet d’exploiter les processeurs multicœurs, ce qui accélère le processus. L’utilisation de la mémoire croît linéairement avec la taille du jeu de données, ce qui vous permet de prévoir vos besoins de stockage. Cependant, vous devez conserver l’intégralité du graphe en RAM, ce qui limite la mise à l’échelle pour les jeux de données de milliards de vecteurs.

Avantages et inconvénients de DiskANN

Vous vous tournez vers DiskANN lorsque vous devez étendre la récupération de vecteurs au-delà de ce que la RAM peut supporter. DiskANN optimise l’utilisation des SSD, ce qui réduit les coûts matériels et vous permet de gérer des jeux de données massifs. Vous obtenez une grande précision et une faible latence en combinant des recherches en mémoire et des lectures SSD par lots. DiskANN prend en charge les mises à jour en temps réel et la recherche hybride, ce qui vous permet de filtrer et de récupérer efficacement les vecteurs.

Tenez compte de ces points concernant DiskANN :

• Évolutivité économique grâce à l’utilisation de SSD au lieu de la RAM.
• Précision élevée et faible latence à grande échelle grâce aux recherches en mémoire et aux lectures SSD.
• Mise à jour en temps réel et recherche hybride combinant vecteurs et filtrage.
• Temps de construction long, car la construction du graphe Vamana est très coûteuse en calcul.
• Les performances dépendent du débit et de la latence des SSD.
• Les mises à jour coûtent plus cher que dans les structures en mémoire comme HNSW.
• L’implémentation et le réglage demandent une optimisation minutieuse.

DiskANN tire parti de sa capacité à gérer les vecteurs quantifiés, qui compressent les données et améliorent la recherche économe en mémoire. Vous pouvez utiliser DiskANN pour des charges de travail portant sur un milliard de vecteurs sans vous soucier des limites de RAM.

Efficacité en mémoire et en stockage

Vous devez tenir compte de l’efficacité en mémoire et en stockage lorsque vous choisissez entre HNSW et DiskANN pour la recherche vectorielle. HNSW convient aux jeux de données qui tiennent dans la RAM de votre serveur. Vous bénéficiez d’un accès rapide et de hautes performances, mais vous ne pouvez pas dépasser les limites de votre mémoire. DiskANN vous permet d’étendre la taille de vos jeux de données jusqu’à la capacité du disque, au prix d’une certaine perte de vitesse. Vous stockez la majeure partie de votre index sur des SSD, ce qui fait de DiskANN une solution idéale pour les jeux de données vectoriels volumineux.

Vous utilisez des vecteurs quantifiés avec HNSW comme avec DiskANN pour réduire les besoins de stockage et améliorer la vitesse de recherche. L’architecture hybride de DiskANN vous permet de faire évoluer votre recherche vectorielle tout en maîtrisant les coûts. Vous obtenez une recherche économe en mémoire pour les tâches de recherche à grande échelle, en particulier lorsque vous travaillez avec des vecteurs quantifiés et un stockage sur SSD.

Comparaison des algorithmes de recherche vectorielle

Performances à grande échelle

Vous devez mesurer les performances d’un algorithme de recherche vectorielle à mesure que votre jeu de données grandit. HNSW et DiskANN visent tous deux un rappel et une vitesse élevés, mais leurs stratégies diffèrent. HNSW repose sur des graphes en mémoire : la recherche du plus proche voisin est rapide tant que vos vecteurs tiennent en RAM. DiskANN adopte une approche hybride mémoire et SSD, ce qui vous permet de faire évoluer les performances de recherche sans vous heurter aux limites de la mémoire.

Lorsque vous effectuez une recherche du plus proche voisin sur des millions de vecteurs, HNSW offre une récupération très rapide et une faible latence. Vous pouvez régler les paramètres pour privilégier le rappel ou la vitesse. DiskANN maintient un rappel et une vitesse élevés même lorsque votre jeu de données s’agrandit. Vous stockez la majeure partie de votre index sur des SSD, ce qui vous permet de traiter des milliards de vecteurs. Vous utilisez une recherche en deux étapes pour équilibrer vitesse et précision : la première étape identifie les candidats en mémoire, la seconde affine les résultats à l’aide des SSD.

Vous obtenez un rappel et une vitesse élevés avec les deux algorithmes, mais DiskANN vous permet de faire évoluer les performances de recherche au-delà des limites de la RAM.

Passage à l’échelle pour des milliards de vecteurs

Vous faites face à de nouveaux défis lorsque votre jeu de données passe de quelques millions à des milliards de vecteurs. HNSW fonctionne bien jusqu’à 50 millions de vecteurs. Vous utilisez HNSW comme algorithme de recherche vectorielle par défaut et réglez les paramètres pour privilégier le rappel. Au-delà de 50 à 500 millions de vecteurs, vous mettez en œuvre le sharding et la quantification scalaire. Vous pouvez recourir à une récupération en deux phases pour gagner en efficacité. Pour les jeux de données de plus de 500 millions de vecteurs, vous avez besoin d’une récupération hiérarchique et d’architectures multi-niveaux. Vous appliquez une quantification agressive aux données froides.

DiskANN change la donne pour la recherche vectorielle à l’échelle du milliard. Vous stockez la majeure partie de votre index sur des SSD, si bien que vous n’avez pas à vous soucier des limites de RAM. Vous utilisez la quantification de produit pour compresser les vecteurs et conservez les données de navigation en mémoire. Vous faites évoluer votre recherche du plus proche voisin jusqu’à des milliards de vecteurs sans sacrifier les performances. DiskANN prend en charge la recherche approximative fondée sur le clustering et la récupération hybride, ce qui vous aide à gérer des jeux de données massifs.

DiskANN vous permet de faire évoluer votre algorithme de recherche vectorielle pour des milliards de vecteurs, ce qui en fait une solution idéale pour les charges de travail d’entreprise.

Latence des requêtes et débit

Vous devez prêter attention à la latence des requêtes et au débit lorsque vous exécutez une recherche vectorielle à grande échelle. HNSW offre une faible latence pour la recherche du plus proche voisin, car il conserve l’intégralité du graphe en mémoire. Vous obtenez des réponses rapides et un débit élevé pour les jeux de données qui tiennent dans la RAM. Lorsque votre jeu de données grandit, la latence augmente, car vous devez alors recourir au sharding ou à des architectures multiniveaux.

DiskANN repose sur un processus de recherche en deux étapes. Vous recherchez d’abord les vecteurs compressés en mémoire, ce qui permet une sélection rapide des candidats. Vous affinez ensuite votre requête en récupérant les vecteurs en pleine précision depuis les SSD. Cette approche maintient une latence faible et un débit élevé, même pour des jeux de données à l’échelle du milliard. Vous optimisez votre récupération en regroupant les lectures sur SSD et en utilisant des structures de navigation efficaces.

Vous obtenez un rappel élevé et une grande rapidité avec DiskANN, même lorsque le volume de vos requêtes augmente. Vous n’avez pas à vous soucier des limites de mémoire, ce qui vous permet de faire évoluer les performances de recherche pour vos applications d’entreprise.

Vous bénéficiez d’une latence et d’un débit de requêtes fiables avec DiskANN, ce qui en fait un choix pertinent pour la recherche du plus proche voisin à grande échelle.

Impact sur les coûts et les ressources

Vous devez tenir compte de l’impact sur les coûts et les ressources lorsque vous choisissez un algorithme de recherche vectorielle pour Azure AI Search. La manière dont chaque algorithme utilise la mémoire et le stockage influe sur votre budget et sur votre capacité à monter en charge.

DiskANN se distingue pour les charges de travail portant sur des milliards de vecteurs. Vous pouvez stocker la majeure partie de votre index sur des SSD, dont le coût est inférieur à celui de la RAM. Cette conception vous permet de passer de milliers à des milliards de vecteurs sans augmentation importante des coûts de mémoire. DiskANN convient bien aux charges de travail d’IA en production, car il exploite efficacement les SSD et ne conserve en mémoire que les données les plus importantes.

HNSW convient mieux aux jeux de données de taille moyenne. Vous devez conserver l’intégralité de l’index en RAM, ce qui limite votre capacité à monter en charge. Si votre jeu de données devient trop volumineux, vos coûts d’exploitation peuvent devenir élevés. HNSW est en outre limité à 2 000 dimensions, ce qui peut restreindre vos cas d’usage.

Astuce : si vous souhaitez maîtriser vos coûts et faire évoluer votre recherche jusqu’à des milliards de vecteurs, DiskANN vous offre un avantage net. Vous pouvez utiliser des SSD abordables et limiter vos besoins en mémoire.

Cas d’usage concrets

Vous pouvez mesurer l’intérêt de ces algorithmes dans des applications réelles. De nombreuses organisations utilisent DiskANN et HNSW pour différents types de problèmes de recherche vectorielle.

• Vous pouvez recourir à une méthode hybride économique pour la recherche approximative du plus proche voisin. Cette approche combine le stockage sur SSD avec des structures de graphe en mémoire.
• Vous pouvez déployer DiskANN pour des jeux de données statiques, comme des corpus de recherche, dont les données changent peu souvent.
• Vous pouvez choisir DiskANN pour des déploiements sensibles aux coûts. Il convient bien aux applications à l’échelle du milliard, lorsque vous devez maîtriser les dépenses.
• Vous pouvez utiliser DiskANN pour des requêtes qui tolèrent une latence inférieure à 10 millisecondes. Cette rapidité suffit pour de nombreuses tâches de recherche en entreprise.
• Vous pouvez combiner HNSW avec des fichiers inversés sur disque (HNSW-IF) pour la recherche hybride. Cette méthode permet d’atteindre un rappel élevé tout en maintenant une latence faible.

Remarque : de nombreuses organisations atteignent un rappel de 90 % avec une latence de 10 ms grâce à des méthodes hybrides. Ces performances répondent aux besoins de la plupart des applications de recherche IA en entreprise.

Vous pouvez adapter le choix de votre algorithme à votre charge de travail. Si vous devez faire évoluer votre recherche, maîtriser les coûts et garder une latence faible, DiskANN vous offre la souplesse et l’efficacité nécessaires.

Quand utiliser HNSW ou DiskANN

Choisir le bon algorithme pour votre charge de travail Azure AI Search peut faire une grande différence en matière de rapidité, de coût et de précision. Vous devez examiner vos données, votre matériel et la fréquence de modification de vos données. Voyons ensemble les principaux critères de décision, afin que vous puissiez choisir l’outil le mieux adapté à vos besoins de recherche vectorielle.

Critères de décision

Taille du jeu de données

Commencez toujours par évaluer la taille de votre jeu de données. Si vous travaillez avec des millions de vecteurs, HNSW offre des résultats de recherche rapides et précis. Il fonctionne au mieux lorsque vos données tiennent en mémoire. Lorsque votre jeu de données atteint des milliards de vecteurs, DiskANN devient le meilleur choix. Il utilise des SSD pour stocker la majeure partie de l'index, ce qui vous évite de craindre de manquer de RAM.

Vous constaterez que HNSW convient aux charges de travail plus modestes, tandis que DiskANN gère des jeux de données massifs sans ralentir.

Matériel et coût

Votre matériel et votre budget jouent également un rôle essentiel. HNSW nécessite beaucoup de RAM, car il conserve l'intégralité du graphe en mémoire. Cela peut devenir coûteux à mesure que votre base de données vectorielle grandit. DiskANN vous permet de réduire vos dépenses en stockant la majeure partie de l'index sur des SSD, dont le coût est inférieur à celui de la RAM. Vous n'avez besoin que de suffisamment de mémoire pour la partie de navigation de l'index.

Si vous souhaitez maîtriser vos coûts tout en effectuant des recherches parmi des milliards de vecteurs, DiskANN vous offre un avantage net.

Besoins en latence

Réfléchissez à la rapidité avec laquelle vous avez besoin d'obtenir vos résultats de recherche. HNSW offre une latence très faible, car la recherche s'effectue en mémoire. Vous pouvez obtenir des résultats en quelques millisecondes si vos données tiennent en RAM. DiskANN trouve un équilibre entre rapidité et volume. Il utilise un processus de recherche en deux étapes, ce qui vous garantit des résultats rapides même avec des jeux de données très volumineux. Pour la plupart des applications d'entreprise, DiskANN maintient les temps de requête sous 10 millisecondes.

• HNSW convient particulièrement aux charges de travail où chaque milliseconde compte.
• DiskANN convient bien lorsque vous devez rechercher rapidement dans de grands jeux de données et que vous pouvez accepter une légère augmentation de la latence.

Schémas de mise à jour

La fréquence de modification de vos données influence votre choix. HNSW convient bien aux données statiques ou évoluant lentement. Si vous mettez fréquemment à jour vos vecteurs, vous devrez peut-être reconstruire l'index, ce qui prend du temps. DiskANN s'adapte mieux aux mises à jour fréquentes. Il conserve une précision et un rappel stables, même lorsque vous ajoutez ou modifiez fréquemment des vecteurs.

Si votre application doit gérer de nombreuses mises à jour, DiskANN vous offre davantage de souplesse.

Exemples de scénarios

Vous pouvez vous appuyer sur des scénarios concrets pour déterminer quel algorithme correspond à vos besoins.

• HNSW offre un rappel élevé et un débit de requêtes rapide. Sur des jeux de données comme SIFT1M, vous pouvez atteindre un rappel d'environ 95 % à 10 en seulement 1 à 2 millisecondes par requête sur un CPU.
• DiskANN affiche un rappel moyen plus élevé, ce qui signifie qu'il trouve davantage de correspondances réelles dans les grands jeux de données. Il maintient une précision élevée à mesure que vos données augmentent.
• HNSW convient particulièrement aux systèmes de recommandation ou aux moteurs de recherche où vous avez besoin d'une précision maximale et d'une grande rapidité.
• DiskANN convient à la recherche à grande échelle, par exemple parmi des milliards d'images produits ou de documents, lorsque vous devez concilier rapidité, coût et volume.

HNSW se distingue pour les charges de travail qui exigent la recherche la plus rapide possible sur des jeux de données plus petits. DiskANN brille lorsque vous devez explorer d'immenses volumes de données sans dépasser votre budget.

Migration et approches hybrides

Vous n'êtes pas obligé de choisir un seul algorithme pour toutes les situations. De nombreuses organisations commencent par HNSW pour les jeux de données de taille modeste. À mesure que leur base de données vectorielle grandit, elles migrent vers DiskANN pour gérer davantage de données tout en maîtrisant leurs coûts. Vous pouvez également adopter une approche hybride. Par exemple, vous pouvez conserver en mémoire, avec HNSW, les vecteurs les plus consultés ou les plus récents, tout en stockant les vecteurs plus anciens ou moins utilisés sur des SSD avec DiskANN.

• Commencez par HNSW pour le prototypage rapide et les charges de travail modestes.
• Migrez vers DiskANN lorsque votre jeu de données dépasse les limites de la mémoire.
• Combinez les deux méthodes pour obtenir le meilleur équilibre entre rapidité et volume.

Astuce : examinez régulièrement votre charge de travail. À mesure que vos données et vos besoins évoluent, vous pouvez ajuster votre approche pour obtenir les meilleures performances et la meilleure valeur.

En tenant compte de la taille de votre jeu de données, de votre matériel, de vos besoins en latence et de vos schémas de mise à jour, vous pouvez faire un choix éclairé entre HNSW et DiskANN. Vous serez ainsi en mesure de bâtir un système de recherche vectorielle qui répond à vos objectifs et évolue avec votre activité.

Bonnes pratiques pour la recherche vectorielle dans Azure

Conseils de configuration de l'index

Vous pouvez obtenir de hautes performances dans Azure AI Search en appliquant quelques conseils de configuration essentiels. Commencez par vérifier que la taille de votre index tient dans une seule unité de recherche vectorielle. Cela vous aide à garder une recherche rapide et fiable. Essayez de réduire au maximum la taille de vos embeddings : des embeddings plus petits améliorent les temps de requête et augmentent le nombre de requêtes par seconde. Utilisez les requêtes Approximate Nearest Neighbor pour gagner en efficacité, car elles accélèrent la recherche sans sacrifier beaucoup de précision.

Limitez le nombre de résultats par requête à une valeur comprise entre 10 et 100. Cette plage réduit la latence et préserve la réactivité de votre recherche. Évitez d'utiliser en production des points de terminaison de modèle qui se mettent à l'échelle à zéro. Les démarrages à froid peuvent ralentir votre recherche et frustrer vos utilisateurs. Anticipez les pics de requêtes afin que votre système puisse absorber les hausses soudaines du trafic de recherche. Utilisez des principaux de service avec des jetons OAuth pour une authentification sécurisée et efficace. Utilisez toujours la dernière version du SDK Python afin de bénéficier des améliorations de performances. Si vous avez besoin d'un débit plus élevé, augmentez la capacité de votre point de terminaison ou répartissez la charge sur plusieurs points de terminaison.

Astuce : un index bien configuré est la base d'une recherche vectorielle optimisée dans Azure.

Surveillance et optimisation

Vous devez surveiller et optimiser votre système de recherche pour maintenir de hautes performances, en particulier avec des charges de travail portant sur des milliards de vecteurs. Le tableau ci-dessous présente quelques techniques efficaces :

Remarque : une surveillance régulière vous permet de détecter les problèmes tôt et de maintenir le bon fonctionnement de votre recherche.

Pièges courants

Vous pouvez rencontrer quelques pièges courants lors de la mise en place ou de la montée en charge de votre système de recherche dans Azure. Une erreur fréquente consiste à laisser votre index grossir au-delà de ce qu'une seule unité de recherche peut gérer. Cela peut ralentir vos requêtes et rendre votre recherche moins fiable. L'utilisation d'embeddings volumineux peut également nuire aux performances. Gardez toujours vos embeddings aussi compacts que possible pour votre cas d'usage.

Un autre piège consiste à ignorer les pics de requêtes. Si vous ne anticipez pas les hausses soudaines du trafic de recherche, votre système risque de défaillir sous la pression. S'appuyer sur des points de terminaison qui se mettent à l'échelle à zéro peut entraîner des délais de démarrage à froid, qui ralentissent votre recherche. Ne pas mettre à jour votre SDK ou ne pas utiliser de jetons OAuth peut créer des risques de sécurité et vous faire manquer des gains de performances.

À retenir : évitez ces pièges pour que votre recherche reste rapide, sécurisée et fiable.

En appliquant ces bonnes pratiques, vous pouvez bâtir une expérience de recherche robuste et efficace dans Azure. Vous gérerez facilement de grands volumes de données et fournirez à vos utilisateurs des résultats rapides et précis.

Vous résolvez le problème du milliard de vecteurs dans Azure AI Search en choisissant l'algorithme adapté à vos besoins. DiskANN offre une évolutivité économique pour des jeux de données massifs, tandis que HNSW fournit des résultats rapides pour des charges de travail plus modestes. Vous adaptez votre algorithme à votre charge de travail, à votre échelle et à votre budget. Le tableau ci-dessous vous aide à choisir le meilleur point de terminaison :

• Estimez vos besoins de stockage en testant quelques documents.
• Prévoyez les mises à jour et le volume total de contenu.

Azure AI Search vous offre de la flexibilité et prend en charge les innovations de Microsoft pour l'IA en entreprise. Pour relier toutes ces informations techniques à une architecture cloud concrète, écoutez l'épisode de podcast associé « HNSW vs DiskANN for Vector Search in Azure AI Search ».

Questions fréquentes

Quelle est la principale différence entre HNSW et DiskANN ?

Vous utilisez HNSW pour la recherche vectorielle en mémoire. DiskANN vous permet de stocker la majeure partie de votre index sur des SSD. Cela fait de DiskANN une meilleure option pour gérer des milliards de vecteurs sans coûts de mémoire élevés.

Peut-on utiliser DiskANN pour des applications en temps réel ?

Oui. DiskANN offre une recherche à faible latence, souvent inférieure à 10 millisecondes. Vous pouvez l'utiliser pour des tâches de recherche IA en temps réel, même avec des jeux de données très volumineux.

Comment choisir l'algorithme à utiliser dans Azure AI Search ?

Choisissez HNSW pour les jeux de données plus petits qui tiennent en RAM. Optez pour DiskANN pour les jeux de données massifs qui nécessitent une montée en charge économique. Tenez compte de la taille de vos données, de votre matériel et de vos besoins en latence.

DiskANN nécessite-t-il un matériel spécifique ?

Non. Vous pouvez exécuter DiskANN sur des serveurs standard équipés de SSD. Vous n'avez pas besoin de machines coûteuses dotées de beaucoup de mémoire. Cela facilite la montée en charge et la rend plus abordable.

Comment Azure AI Search protège-t-il vos données ?

Azure AI Search s'appuie sur le chiffrement et des contrôles d'accès. Vous décidez qui peut accéder à vos données. Les fonctionnalités de sécurité de Microsoft vous aident à protéger les informations sensibles.

Peut-on mettre à jour votre index vectoriel sans interruption de service ?

Vous pouvez mettre à jour les index HNSW et DiskANN. DiskANN prend en charge des mises à jour efficaces pour les grands jeux de données. Vos résultats de recherche restent à jour sans mettre votre système hors ligne.

Quelles sont les bonnes pratiques pour optimiser les performances de la recherche vectorielle ?

Utilisez des embeddings de plus petite taille, conservez votre index dans une même unité de recherche et surveillez la latence des requêtes. Mettez toujours à jour votre SDK et anticipez les pics de requêtes pour maintenir des performances élevées.

🎧 Écoutez cet épisode

Vous souhaitez une explication concrète de HNSW et DiskANN pour la recherche vectorielle dans Azure AI Search ? Cet épisode décortique le sujet en termes clairs et montre pourquoi il compte pour Microsoft 365, Azure, Power Platform, la sécurité, l'IA et le travail moderne.

Écoutez cet épisode si vous souhaitez :

• Comprendre les concepts clés de HNSW et DiskANN pour la recherche vectorielle dans Azure AI Search
• Voir comment cela s'inscrit dans l'écosystème technologique plus large de Microsoft
• Découvrir où cela peut apporter une valeur concrète à votre organisation

Vous aimerez peut-être aussi ces épisodes connexes de M365 FM :

• Améliorer la précision de Microsoft Copilot au-delà de la recherche vectorielle
• Azure AI Search – Expliqué simplement
• Bases de données vectorielles – Expliqué simplement
• Microsoft Graph API Discovery pour la recherche sémantique en entreprise
• Faire afficher en premier les bons fichiers par la recherche SharePoint

Découvrez davantage de discussions pratiques sur Microsoft sur M365 FM.

Dernière révision : juillet 2026.

Public visé

Cet épisode s'adresse aux administrateurs, architectes, développeurs, spécialistes de la sécurité et responsables métier de Microsoft qui ont besoin de bases concrètes avant de prendre des décisions de mise en œuvre, d'exploitation ou de gouvernance.

🎧 Écoutez aussi

• Azure Resource Manager — Une étape suivante très liée pour approfondir ce sujet.
• Infrastructure as Code — Une étape suivante très liée pour approfondir ce sujet.
• Azure Policy — Une étape suivante très liée pour approfondir ce sujet.