TL;DR : si vous avez besoin de chercher dans des millions d’embeddings sans louer un service, installez-le. En une commande, vous divisez la mémoire par près de huit et vous gardez la quasi-totalité de la qualité de recherche.
Au printemps, TurboQuant a fait beaucoup de bruit. L’algorithme de quantification publié par Google Research promettait de diviser par six l’empreinte mémoire des modèles, et la presse française l’a largement couvert : Korben, Next, Developpez, Clubic, le Journal du Geek. Certains y ont même vu la cause d’un mouvement sur les actions des fabricants de mémoire.
Le problème, c’est que tout le monde a parlé de l’idée, et personne de la chose : le code officiel de Google était annoncé pour le second trimestre, et on ne pouvait rien essayer.
turbovec comble ce trou : un index vectoriel écrit en Rust avec des liaisons Python, sous licence MIT, 16 481 étoiles, dernier envoi le 21 août. Il s’installe comme ceci, avec numpy pour seule dépendance :
pip install turbovecUne mise au point tout de suite : ce n’est pas le code de Google. Il est publié par RyanCodrai, qui met en oeuvre l’algorithme décrit par Google Research. Les mérites de la méthode reviennent à Google, ceux de cette implémentation à son auteur, et personne ne vous doit de support.
Ce que ça donne chez nous
Nous ne recopions pas les chiffres du dépôt, nous les refaisons. Banc d’essai : 100 000 vecteurs de dimension 768, la taille typique d’un modèle d’embeddings, sur un Mac à processeur ARM.
Le corpus brut pèse 307,2 Mo en float32. Une fois indexé, il tient dans 39,6 Mo, soit 7,7 fois moins, à 4 bits par coordonnée. Le dépôt annonce 31 Go ramenés à 4 Go sur dix millions de documents, soit un facteur 7,75 : nos mesures confirment les siennes, ce qui n’est pas si fréquent.
L’indexation prend 0,21 seconde, sans entraînement préalable : on ajoute, c’est indexé. Et la recherche répond en 0,12 milliseconde par requête, contre 1,05 milliseconde en force brute exacte avec numpy. Huit fois plus rapide, en occupant huit fois moins de place.
Ce que ça coûte, parce que ça coûte quelque chose
Une recherche approchée se paie en qualité, et c’est là que notre essai a donné le résultat le plus intéressant.
Sur des vecteurs dispersés, turbovec retrouve 84,7 % des dix vrais plus proches voisins, et 100 % du plus proche. Mais de vrais embeddings ne sont pas dispersés, ils se groupent par thème. Refait sur 100 000 vecteurs répartis en 500 groupes, le rappel descend à 77,2 % sur les dix voisins, et à 95 % sur le plus proche.
C’est logique, et c’est rarement dit : plus les documents se ressemblent, plus il est difficile de les départager une fois comprimés à 4 bits. Le cas facile des démonstrations est celui où l’outil brille le plus, et vos données réelles seront plus dures que le banc d’essai de n’importe qui, le nôtre compris.
Le piège à connaître
La recherche accepte un masque booléen pour ne chercher que dans un sous-ensemble. La documentation prévient d’un traquenard que nous n’aurions pas deviné : toute modification de l’index invalide un masque existant, et le contrôle de longueur ne vous protège pas. Une suppression suivie d’un ajout laisse la même longueur tout en plaçant un autre vecteur dans l’emplacement libéré. Le masque passe la validation et sélectionne les mauvais documents, en silence.
Notre avis
C’est le genre d’outil qu’on aime ici : une commande, aucune dépendance à un service, tout reste sur la machine, et les chiffres annoncés tiennent quand on les vérifie. Que l’auteur documente lui-même le piège du masque plutôt que de le laisser dans un coin en dit long sur le sérieux du projet.
La bonne question n’est pas « est-ce que c’est rapide », mais « est-ce que 77 % de rappel me suffisent ». Si oui, vous venez de diviser votre facture mémoire par huit. Sinon, gardez vos vecteurs d’origine à côté pour rescorer, et vous aurez les deux.
