Ajustement des index HNSW et mise à l’échelle de la recherche vectorielle pour RAG en production
Apprenez comment les paramètres M et ef de HNSW équilibrent la précision, le temps de réponse et la mémoire, comment les configurer dans Chroma, ainsi que quand il convient d’échaler une base de données vectorielle verticalement ou par shardage.
Sources: **15.**HNSW & Vector Database Tuning for Production RAG
Les deux paramètres HNSW qui contrôlent presque tout
Vous n’avez pas besoin de toute la théorie des graphes HNSW (Hierarchical Navigable Small World) pour les ajuster. L’index relie chaque vecteur à des vecteurs proches sur plusieurs niveaux, et une requête parcourt ce graphique en direction de ses voisins les plus proches. Deux paramètres déterminent la structure de ce graphique ainsi que le parcours effectué. Pour en savoir plus, consultez notre explication sur le fonctionnement des bases de données vectorielles, des embeddings à la recherche hybride.
M : nombre maximal de connexions par nœud
M définit le nombre maximal de liens vers des voisins que chaque nœud conserve dans le graphique.
- M faible : moins de liens, un index plus petit, moins de mémoire et une navigation plus rapide, mais un taux de rappel inférieur car la recherche dispose de moins de chemins menant à de bons candidats.
M est fixé lors de la création de l’index, donc le modifier ultérieurement signifie reconstruire l’index.
ef : effort déployé par chaque recherche
ef contrôle le nombre de candidats que l’index prend en compte lorsqu’il cherche les voisins les plus proches d’une requête.
- Baixe valeur de ef : moins de candidats sont examinés, ce qui rend la récupération rapide, mais des documents pertinents peuvent être manqués et la précision diminue.
- Haute valeur de ef : plus de candidats sont examinés, ce qui ralentit la récupération, mais l’ensemble des résultats est beaucoup plus proche des véritables voisins les plus proches.
De nombreux moteurs divisent cela en une valeur définie lors de la construction, qui contrôle le soin apporté à l’élaboration du graphe, et une valeur définie pendant la recherche que l’on peut généralement modifier sans devoir reconstruire le graphe, ce qui en fait la variable la moins coûteuse à expérimenter.
Équilibrer précision, vitesse et mémoire
La mise en tune de HNSW repose sur un compromis à trois niveaux entre précision, vitesse et mémoire. Ces combinaisons constituent des points de départ raisonnables pour les différentes étapes d’un projet, où ef désigne la valeur relative au temps de recherche :
+----------------+----+-----+----------+
| Use Case | M | ef | Priority |
+----------------+----+-----+----------+
| Prototype | 16 | 40 | Speed |
| Production | 16 | 100 | Balanced |
| High accuracy | 32 | 200 | Accuracy |
+----------------+----+-----+----------+
Considérez-les comme des points de référence pour effectuer des benchmarks : mesurez le taux de rappel et la latence pour des requêtes représentatives avant et après chaque modification.
Définition des paramètres HNSW dans Chroma
Chaque base de données vectorielle expose ces paramètres différemment. Dans Chroma, ils peuvent être transmis en tant que métadonnées de collection lors de sa création. L’exemple ci-dessous définit M à 16, ef en temps de construction à 100 et ef en temps de recherche à 50 :
#Chroma-HNSW Settings
collection=client.create_collection(
name='new_collection',
metadata={
'hnsw:M':16,
'hnsw:construction_ef': 100,
'hnsw:search_ef': 50
}
)
Ce style basé sur des clés de métadonnées peut varier dans les versions plus récentes de Chroma, qui proposent également un objet de configuration dédié ; veuillez donc consulter la documentation actuelle correspondant à votre version. Définissez M et ef en temps de construction avant d’ingérer des données, car ils sont intégrés au graphe.
Lorsque l’ajustement ne suffit plus
Même un index bien optimisé atteint finalement ses limites. Lorsque le temps de récupération dépasse régulièrement 100 ms, une cause fréquente est que l’index ne tient plus confortablement en mémoire, et des ajustements supplémentaires des paramètres ne résoudront pas ce problème. Une estimation approximative peut aider : le stockage brut des vecteurs correspond au nombre de vecteurs multiplié par leurs dimensions, puis augmenté de 4 octets pour les nombres flottants à 32 bits ; le graphe HNSW ajoute en outre des surcoûts qui augmentent avec M. À ce stade, la solution réside dans l’échellement, qui se présente sous deux formes.
Échellement vertical
Pour des collections comptant environ de 5 à 10 millions de vecteurs, ajouter de la RAM ou du CPU à la machine existante est généralement la première étape. Avec suffisamment de mémoire, tout l’index tient en RAM, ce qui permet une récupération rapide et améliore l’efficacité globale.
La mise à l’échelle verticale ne nécessite aucune modification architecturale ni de code, mais une seule machine a une limite en termes de mémoire, et les instances plus grandes deviennent rapidement coûteuses.
Mise à l’échelle horizontale
Après environ 10 millions de vecteurs, la mise à l’échelle horizontale devient l’option pratique. La collection est fragmentée, ce qui signifie que les données sont réparties sur plusieurs instances, et chaque fragment stocke et recherche sa propre partie.
Cela élimine la limite imposée par une seule machine. Le prix à payer est la complexité : chaque requête est distribuée aux fragments, et leurs résultats partiels doivent être fusionnés en une seule liste classée, ce qui augmente la latence et les efforts opérationnels.
Points clés
Minfluence la structure du graphe : des valeurs plus élevées améliorent le taux de rappel et l’utilisation de la mémoire, et en modifier la valeur nécessite une reconstruction.efinfluence la recherche : augmenter la valeur correspondant au temps de recherche est le moyen le moins coûteux pour échanger de la latence contre un meilleur taux de rappel.
M 16 avec une recherche ef de 100, puis effectuez des tests sur vos propres requêtes.