La compression des index vectoriels réduit la RAM en stockant des représentations de précision inférieure, mais la distorsion des distances qui en résulte peut diminuer le rappel des plus proches voisins.
Un index RAG domestique peut facilement contenir cent mille segments et devenir limité par la mémoire après plusieurs années de documents, de photos et de transcriptions. La quantification permet de conserver davantage de vecteurs en mémoire, mais la qualité de recherche dépend de la capacité des distances compressées à préserver le même classement des candidats qu’en pleine précision. Le résultat varie selon la distribution des embeddings, le taux de compression, le type d’index, l’ampleur de la sélection des candidats et la disponibilité ou non des vecteurs d’origine pour le réordonnancement.
La compression réduit la charge utile des vecteurs, mais pas tous les coûts de l’index
Un index vectoriel utilise de la mémoire pour les valeurs des embeddings, les structures de graphe ou de partitionnement, les identifiants, les métadonnées, la surcharge de l’allocateur et les tampons de requête temporaires. La compression réduit principalement la représentation des embeddings. Les liens HNSW et les métadonnées peuvent rester similaires, si bien que les économies totales de RAM peuvent être inférieures à ce que laisse penser le taux de compression des vecteurs.
Les vecteurs de grande dimension sont coûteux, car chaque dimension stockée comme valeur en pleine précision contribue aux coûts de mémoire et de calcul des distances. Remplacer ces valeurs par des codes compacts réduit la charge utile résidente et peut améliorer l’efficacité du cache.
L’économie réelle dépend donc de la composition de l’index. Les vecteurs flottants de grande dimension offrent généralement une cible importante ; les petits vecteurs associés à une forte connectivité du graphe permettent des économies proportionnellement plus faibles. Mesurez la mémoire résidente du processus et la taille des fichiers d’index avant et après la compression, plutôt que de multiplier le nombre brut d’octets par vecteur par le nombre de documents.
La quantification introduit une distorsion des distances
La quantification scalaire mappe chaque dimension vers une plage numérique plus restreinte, tandis que la quantification par produit divise un vecteur en sous-espaces et stocke les choix de codebook. Dans les deux cas, les coordonnées exactes sont remplacées par des approximations. La distance à la requête est alors calculée à partir de valeurs reconstruites ou de distances entre codebooks, plutôt qu’à partir du vecteur flottant d’origine.
Les expériences avec la quantification par produit évaluent la compression en mesurant la distorsion des distances reconstruites et le rappel. Des codes plus compacts peuvent réduire la latence ou l’utilisation mémoire, mais ils rendent aussi plus difficile le classement correct des candidats proches lorsque leurs distances réelles sont similaires.
Le rappel diminue lorsqu’un voisin pertinent passe sous le seuil de sélection des candidats, et pas simplement parce que chaque distance est légèrement incorrecte. Les requêtes présentant une marge nette entre les segments pertinents et non pertinents peuvent résister à une compression importante ; les voisinages sémantiques denses, avec de nombreux quasi-ex æquo, sont plus sensibles.
L’élargissement des candidats et le réordonnancement peuvent restaurer le rappel
Une recherche en deux étapes utilise des vecteurs compressés pour trouver une liste restreinte étendue, puis recalcule les distances avec des vecteurs de précision supérieure pour ces candidats. Le suréchantillonnage donne aux éléments pertinents davantage de chances de franchir la première étape approximative ; le réordonnancement rétablit l’ordre lorsque les codes compacts ont brouillé de faibles différences de distance.
Des niveaux de compression supérieurs réduisent généralement le rappel, tandis que le suréchantillonnage et le réordonnancement peuvent améliorer la précision. Cette récupération consomme davantage de lectures, de mémoire et de ressources de calcul par requête : la compression déplace donc le coût en ressources au lieu de supprimer le coût lié à la qualité.
Conserver les vecteurs complets sur disque peut maintenir une faible empreinte RAM, mais ajoute de la latence de stockage lors du réordonnancement. Les conserver en RAM améliore la latence, mais réduit le bénéfice mémoire. La configuration utile dépend de la contrainte principale du serveur domestique : capacité mémoire, IOPS du stockage ou objectifs de temps de réponse.
Le rappel doit être mesuré sur la tâche de recherche locale
Constituez un jeu de référence en exécutant une recherche exacte ou en haute précision pour des requêtes représentatives, puis comparez si la recherche compressée renvoie les mêmes voisins pertinents dans le top-k. Incluez des paraphrases, des noms propres, des documents quasi dupliqués, des termes rares et des requêtes dont la réponse dépend d’une distinction fine entre plusieurs éléments de preuve.
Cela complète la confiance dans l’ancrage de la recherche : la similarité entre voisins et la prise en charge de la réponse sont liées, mais ne sont pas identiques. Mesurez le Recall@k par rapport à la recherche de référence et vérifiez également si les segments perdus ou réordonnés modifient les éléments de preuve disponibles pour le générateur.
Il n’existe pas de vainqueur universel entre compression maximale et précision maximale. Augmentez la compression jusqu’à atteindre l’équilibre souhaité entre RAM, latence et rappel sur la tâche, puis refaites les tests après toute modification du modèle d’embedding ou du corpus. Une configuration adaptée à la recherche de similarité générale entre photos peut être trop destructrice pour la recherche dans des documents techniques comportant de nombreux passages sémantiquement proches.
Centre Tech & IA
Plus à lire

Pourquoi l’architecture d’un serveur personnel Jellyfin évolue à mesure que vous ajoutez des services
Un boîtier Jellyfin devient une pile de services à mesure que l’on ajoute des applications : la gestion du processeur, du stockage, du réseau,...

Comment mesurer les performances de Jellyfin sans confondre cache et capacité
Un benchmark Jellyfin fiable distingue les états à froid et à chaud afin que les métadonnées mises en cache ou les pages du système...

De quelle marge de manœuvre l’iGPU de Jellyfin multi-utilisateur a-t-il besoin ?
La marge disponible de l’iGPU pour Jellyfin dépend de la charge de travail : prévoyez une marge au-delà du scénario de transcodage simultané reproductible...

