Google Cloud a mis à jour l'index ScaNN d'AlloyDB, avec un plafond officiel désormais fixé à plus de 10 milliards de vecteurs. À cette échelle, les mesures réelles donnent une latence P95 ne dépassant pas 51 millisecondes, pour un rappel (recall) de 95 %. AlloyDB est le service de base de données géré de Google Cloud, compatible avec l'interface PostgreSQL.
Le changement porte sur la structure de l'index. Auparavant, ScaNN organisait les vecteurs avec des arbres à deux ou trois niveaux ; cette fois, un quatrième niveau a été ajouté.
Un niveau d'arbre en plus, deux ordres de grandeur en moins à parcourir
La recherche approximative du plus proche voisin regroupe d'abord les vecteurs par similarité en clusters organisés par niveaux ; lors d'une requête, on descend depuis le sommet, et à chaque niveau seules les branches les plus proches sont explorées. Le nombre de niveaux détermine la complexité de la recherche : un arbre à deux niveaux est en O(N^1/2), à trois niveaux cela descend à O(N^1/3), et à quatre niveaux cela se réduit encore à O(N^1/4).
Ces exposants divergent fortement à l'échelle de dizaines de milliards. Calcul rapide : pour N égal à 10 milliards, la racine carrée de N vaut environ 100 000, la racine cubique environ 2 150, et la racine quatrième environ 316. Le nombre de candidats qu'une même requête doit toucher passe ainsi de l'ordre de la centaine de milliers à l'ordre de quelques centaines. C'est de là que vient le chiffre de 51 millisecondes.
Parmi les mesures concrètes citées par Google figurent la stratégie de branchement Top-K, l'algorithme SOAR, l'ajustement des centroïdes et la construction d'arbres équilibrés, ainsi qu'un échantillonnage dynamique pour contourner les limites de mémoire. Google pointe deux goulots d'étranglement de l'ancienne structure : plus l'arbre grossit, plus le coût de calcul augmente à la fois pour construire l'index et pour parcourir les requêtes ; et l'échantillonnage sur des dizaines de milliards de vecteurs a tendance à épuiser la mémoire disponible.
Ce sont les agents IA qui ont fait grimper le volume de données
Selon Google, la demande des applications d'agents IA en entreprise pousse les cas d'usage vers des milliards de vecteurs, et les bases de données vectorielles sous-jacentes tiennent souvent difficilement le rythme.
Cette phrase pointe l'origine de cette vague d'extension. Dans les scénarios classiques de recherche augmentée (RAG), une entreprise découpe l'ensemble de ses documents internes en fragments, généralement de l'ordre de dizaines à centaines de millions. Avec les agents IA, c'est différent : à chaque étape d'exécution, ils doivent revenir sur l'historique, consulter les descriptions d'outils, vérifier les préférences utilisateur — une seule tâche peut déclencher plus d'une dizaine de recherches. Les sources de données se sont aussi étendues des documents aux journaux de conversation, aux logs d'actions et aux résultats intermédiaires, qui s'accumulent chaque jour.
Autre calcul : avec une P95 de 51 millisecondes, si une tâche d'agent effectue 15 recherches, la seule base vectorielle consomme environ 0,77 seconde. Et ce n'est que la partie base de données — l'inférence du modèle, les appels d'outils et les allers-retours réseau s'ajoutent à part. La latence de recherche paraît négligeable dans une seule interaction, mais dans une chaîne à plusieurs étapes, elle finit par se faire sentir.
Les bases de données généralistes absorbent peu à peu les produits spécialisés
Intégrer la recherche vectorielle à l'échelle de dizaines de milliards dans un service géré compatible PostgreSQL va dans le même sens : les vecteurs n'ont plus besoin d'une infrastructure séparée.
Pour les clients entreprise, le calcul est simple. Les données métier se trouvent déjà dans des bases relationnelles — tables utilisateurs, tables de commandes, règles de permissions y sont déjà. Isoler les vecteurs dans une base spécialisée séparée implique deux systèmes de sauvegarde, deux schémas de permissions, deux garanties de cohérence, et la gestion à part des limites transactionnelles entre les deux bases. Si un simple index ajouté à la base existante suffit, la complexité opérationnelle est divisée par deux.
La position des bases de données vectorielles spécialisées a elle aussi évolué ces deux dernières années. Elles gardent un avantage en performance extrême et en rapidité d'itération des algorithmes de recherche, mais les bases généralistes ne cessent de relever le seuil du suffisant — du million à la centaine de millions, et maintenant à la dizaine de milliards. L'espace qui reste aux produits spécialisés se réduit à ce petit segment aux exigences de latence et de débit les plus strictes.
Cette fois, AlloyDB n'a pas communiqué le nombre de partitions, la dimension des vecteurs, le temps de construction de l'index ni la limite de QPS. Ces paramètres ont souvent plus de valeur pratique dans un choix technologique réel que l'échelle maximale, en particulier la durée de construction de l'index — le coût de reconstruction à l'échelle de dizaines de milliards peut s'avérer démesurément élevé.
Sources : blog officiel de Google Cloud, documentation de l'index ScaNN d'AlloyDB, CocoLoop ; les chiffres d'échelle vectorielle, de latence P95 et de rappel suivent l'annonce officielle, les conversions de complexité sont des estimations éditoriales.