La recherche vectorielle, c'est la taxe silencieuse de scaling sur chaque système RAG pis chaque agent qui se souvient. Les embeddings font juste grossir, pis à un moment la facture mémoire force la quantization — tu rapetisses les vecteurs, tu manges une perte de recall. Qdrant 1.18, sorti le 11 mai, ajoute TurboQuant, pis le cadrage qui compte, c'est celui que sa propre doc met en avant : pas « peut-on rapetisser les vecteurs » mais « peut-on les rapetisser sans casser leur géométrie ». C'est la bonne question, parce que le recall c'est de la géométrie — si la quantization déforme les distances inégalement, tes plus proches voisins arrêtent d'être les plus proches.

Le mécanisme de TurboQuant, c'est une rotation orthogonale aléatoire appliquée avant la compression, pis ensuite un seul codebook fixe. Les embeddings sont anisotropes — une poignée de dimensions portent la plupart de la variance (le set DBpedia OpenAI qu'ils benchmarkent a un ratio de 233,5x entre les dimensions les plus fortes pis les plus faibles). La quantization scalaire traite chaque dimension également, fait qu'elle gaspille des bits sur les dimensions mortes pis affame les vivantes. La product quantization règle ça avec des codebooks par sous-espace, mais ça demande un entraînement par dataset pis ça devient périmé quand tes données dérivent. La rotation de TurboQuant étale la variance également sur toutes les dimensions d'abord, fait qu'un seul codebook uniforme est maintenant quasi-optimal — pis comme la rotation est aléatoire pis fixe, toute l'affaire est data-oblivious. Pas d'entraînement, pas de recalibration à l'ingestion. Les chiffres, sur du DBpedia 1536-dim : TQ 4-bit atteint ~8x de compression à un recall@10 de 0,965 (0,996 avec rescoring), 6,4ms de latence contre 7,6ms pour le float32, 72 Mo de stockage là où la quantization scalaire en demande 144. Les bémols honnêtes portent du poids. Le 32x vedette, c'est TQ 1-bit, que l'auteur appelle carrément « pas un choix sûr » — le recall s'effondre. Le chiffre utilisable, c'est 8x à 4-bit. Le recall de 0,996 s'appuie sur le rescoring, ce qui veut dire garder les vecteurs complets pour re-ranker, récupérant une partie du gain de stockage. La quantization binaire est encore plus rapide en débit brut ; TurboQuant gagne sur la stabilité du recall à l'échelle (0,965 là où le binaire plonge à 0,78 à 100K), pas sur la vitesse. Pis c'est testé sur exactement un dataset — un maximalement anisotrope, qui est le cas le plus favorable pour une méthode à base de rotation. Sur des embeddings plus plats, isotropes, la rotation t'achète bien moins, pis ce cas-là n'est pas mesuré.

Ce que ça fait à l'écosystème, c'est le pattern de banalisation à grande vitesse : un résultat de Google Research d'ICLR 2026 devient un flag de config d'une ligne dans un vector DB open-source en quelques semaines. Toute la couche RAG pis agent-memory obtient de la quantization quasi-optimale, sans calibration, sans que personne dans l'équipe ait besoin de comprendre la théorie de la quantization. Ça pèse aussi sur les vendeurs de vector DB gérés dont le pitch inclut « on tune la compression pour vous » — quand la quant data-oblivious est un paramètre `bits=4`, ce moat de tuning s'amincit. La propriété data-oblivious, c'est la raison spécifique de prendre ça plutôt que la product quantization : pour une mémoire d'agent longue durée où la distribution des embeddings se déplace à mesure que t'ingères, les codebooks appris de PQ dérivent hors calibration pis tu ré-entraînes ; la rotation de TurboQuant se fout de quoi tes données ont l'air, fait qu'y a rien à re-tuner.

Lundi matin, si tu roules de la recherche vectorielle à l'échelle : active TQ 4-bit (pas 1-bit) en opt-in dans Qdrant 1.18 pis mesure le recall@k sur ton propre corpus, avec pis sans rescoring, avant de faire confiance au 8x. L'instruction de l'auteur lui-même est l'opérante — ces chiffres viennent du DBpedia maximalement anisotrope, pis ta distribution d'embeddings est probablement plus plate, ce qui est exactement là où la rotation paye le moins. Traite le 8x-à-0,965 comme un plafond à valider, pas un chiffre à présumer. Pis si ta métrique de distance c'est L1/Manhattan, oublie ça — TurboQuant a besoin d'une reconstruction complète là, pis l'avantage de vitesse s'évapore ; la quantization scalaire reste le choix plus sûr.