Comparaison des quantifications vectorielles : Int8 contre binaire – taux de rappel et espace de stockage
Mesurer en quoi la quantification int8 et binaire modifient le taux de rappel et l’espace de stockage des embeddings, pourquoi la quantification binaire peut entraîner une perte d’information, et comment choisir un niveau de compression sûr.
La réduction des embeddings semble être une solution gratuite, et de nombreux guides s’arrêtent là. Un test rapide montre que la compression « sûre » et celle « imprudente » sont bien plus éloignées l’une de l’autre que ne le reconnaissent ces guides.
Voici le point clé : la quantification Int8 permet généralement de conserver 95 % ou plus de la précision de recherche tout en réduisant l’espace de stockage de 4 fois. La quantification binaire offre une réduction spectaculaire de 32 fois, mais à moins que le modèle d’embeddings n’ait été entraîné pour cela, vous risquez de voir disparaître un tiers ou plus de la précision de recherche. Ces deux méthodes ne correspondent pas à des points sur une même échelle graduée ; leur comportement diffère suffisamment pour que le choix erroné puisse nuire silencieusement à la qualité des recherches.
La quantification fonctionne en stockant chaque dimension avec une précision réduite. On passe de nombres flottants à 32 bits à des entiers à 8 bits (quantification scalaire), ou même à un bit par dimension (quantification binaire). Les économies sont réelles : l’utilisation de la RAM diminue jusqu’à 24 fois avec la quantification binaire et 3,75 fois avec la quantification scalaire ; cet effet s’amplifie lorsque le corpus compte des millions de vecteurs, ce qui devient de plus en plus courant pour la mémoire des agents et les systèmes RAG d’entreprise en 2026.
À quoi ressemblent les chiffres
Le corpus de test était synthétique : 2 000 vecteurs ayant 768 dimensions, regroupés en 20 clusters approximatifs pour imiter une structure sémantique réelle. La précision de la récupération a été mesurée en termes de recall@10 par rapport à la référence float32 non compressé, après application de chacun des deux quantificateurs. Tout d’abord, int8, qui échelle en fonction de la plus grande valeur absolue et arrondit dans la plage int8 :
def quantize_int8(vecs):
scale = np.max(np.abs(vecs))
q = np.round(vecs / scale * 127).astype(np.int8)
return q.astype(np.float32) / 127 * scale
Puis le quantificateur binaire, qui ne conserve que le signe de chaque valeur :
def quantize_binary(vecs):
return (vecs > 0).astype(np.float32) * 2 - 1
Les résultats sont les suivants :
Format | Recall@10 vs float32 | Storage (MB) | Reduction
----------------------------------------------------------------------
float32 | 1.000 (baseline) | 6.144 | 1x
int8 | 0.961 | 1.536 | 4.0x
binary | 0.326 | 0.192 | 32.0x
Int8 conserve 96 % de la précision de récupération même avec une réduction de l’espace de stockage de 4 fois, ce qui est très bon pour la plupart des systèmes de production. Le format binaire, dans cette simulation d’incorporation générique conçue sans tenir compte de la quantification, voit son taux de rappel chuter à 32,6 % malgré une compression spectaculaire de 32 fois. Il ne s’agit pas d’une erreur d’arrondi : environ deux sur trois des résultats pertinents que l’index flottant aurait restitués ont disparu.
Pourquoi le format binaire est bien plus difficile à utiliser
Tout dépend de la quantité d’informations conservées. Int8 garde une valeur précise pour chaque dimension, ce qui offre suffisamment de résolution pour préserver la plupart des relations géométriques entre les vecteurs. Le format binaire, quant à lui, ne conserve que le signe et élimine complètement la magnitude, ce qui représente une simplification bien plus radicale de l’espace d’incorporation.
Ce n’est cependant pas une loi de la nature : cela dépend du modèle. Des tests indépendants ont montré que certaines architectures d’encodage ne subissent presque aucun impact de la quantification binaire et conservent environ 98 % de la qualité du format float, tandis que d’autres familles en subissent davantage et atteignent seulement 87 à 92 % de cette qualité, en fonction de la taille du modèle. Ce qui les distingue, c’est que le modèle a été entraîné pour résister à la quantification.
Lequel choisir
- Préférez int8 par défaut. Vous perdez un peu de précision de manière facilement prévisible, mais l’économie d’espace est suffisante pour avoir un impact significatif sur un index de grande taille.
- N’utilisez la quantification binaire qu’avec un modèle conçu pour cela. Les fournisseurs proposent désormais des variantes d’encodage sensibles à la quantification, car les encodages génériques se dégradent fortement sous compression binaire. Vérifiez que votre modèle spécifique a été validé pour cette technique avant de le déployer, et ne supposez pas que cette méthode est fiable partout.
Questions fréquentes
Quel est le coût en termes de précision de l’int8 ? Généralement très faible, avec une perte de rappel inférieure à 5 % par rapport au format float32 complet, en échange d’environ 4 fois moins d’espace de stockage.
La quantification binaire est-elle sûre ? Seulement avec des modèles d’incorporation entraînés pour la supporter. Les modèles génériques peuvent perdre un tiers ou plus de leur précision de recherche, tandis que ceux conçus pour la quantification conservent 98 % ou plus de la qualité au niveau des nombres flottants.
Quelle économie d’espace obtenez-vous ? Environ 4 fois avec int8. La quantification binaire peut atteindre 24 à 32 fois cette économie, mais avec des pertes de précision bien plus importantes et difficiles à prévoir.
Faut-il réincorporer tout le contenu ? Pas nécessairement. Vous pouvez quantifier les embeddings float32 existants ultérieurement, comme le montre le code ci-dessus. Cependant, les modèles entraînés en tenant compte de la compression surpasseront généralement ceux dont l’incorporation a été quantifiée ultérieurement.
Une dernière précaution : le corpus présenté ici est synthétique et structuré en clusters, uniquement à des fins illustratives. Le taux de rappel réel dépend de votre modèle d’embedding, de la structure de vos données et de vos schémas de requête ; il est donc nécessaire de réaliser des tests sur vos propres données avant de choisir un niveau de compression.