O Google Cloud atualizou o índice ScaNN do AlloyDB, com um limite oficial de escala acima de 10 bilhões de vetores. Nessa escala, os dados de teste mostram latência P95 de no máximo 51 milissegundos e recall de 95%. O AlloyDB é o serviço de banco de dados gerenciado do Google Cloud, compatível com a interface do PostgreSQL.
A mudança está na estrutura do índice. Antes, o ScaNN organizava os vetores em árvores de duas ou três camadas; agora passa a usar quatro camadas.
Mais uma camada na árvore, duas ordens de grandeza a menos na busca
A busca aproximada do vizinho mais próximo agrupa os vetores por similaridade em clusters organizados em camadas; na consulta, o percurso vai do topo para baixo, e em cada camada apenas os ramos mais próximos são explorados. O número de camadas determina a complexidade da busca: uma árvore de duas camadas é O(N^1/2), com três camadas cai para O(N^1/3), e com quatro camadas é reduzida ainda mais para O(N^1/4).
Esses expoentes diferem bastante em escala de dezenas de bilhões. Fazendo as contas: com N igual a 10 bilhões, a raiz quadrada de N é cerca de 100 mil, a raiz cúbica é cerca de 2.150, e a raiz quarta é cerca de 316. O número de candidatos que uma mesma consulta precisa tocar cai da casa das centenas de milhares para a casa das centenas. É daí que vem o número de 51 milissegundos.
As medidas concretas listadas pelo Google incluem a estratégia de ramificação Top-K, o algoritmo SOAR, ajuste de centroides e construção de árvores balanceadas, além de amostragem dinâmica para contornar limites de memória. O Google aponta dois gargalos da estrutura antiga: quanto maior a árvore, maior o custo computacional tanto na construção do índice quanto na travessia da consulta; e a amostragem em bilhões de vetores tende a esgotar a memória disponível.
Foram os agentes de IA que elevaram o volume de dados
Segundo o Google, a demanda de aplicações de agentes de IA no nível empresarial está empurrando os casos de uso para bilhões de vetores, e os bancos de dados vetoriais subjacentes frequentemente não dão conta.
Essa frase aponta a origem desta rodada de expansão. Em cenários tradicionais de busca aumentada (RAG), uma empresa divide todos os documentos internos em fragmentos, geralmente na casa de dezenas de milhões a centenas de milhões. Com agentes de IA é diferente: a cada passo de execução, eles precisam revisar o histórico, consultar descrições de ferramentas e verificar preferências do usuário — uma única tarefa pode disparar mais de uma dezena de buscas. As fontes de dados também se expandiram de documentos para registros de conversas, logs de operações e resultados intermediários, que se acumulam a cada dia.
Mais uma conta: com P95 de 51 milissegundos, se uma tarefa de agente realizar 15 buscas, só no banco vetorial isso consome cerca de 0,77 segundo. E isso é apenas a parte do banco de dados — inferência do modelo, chamadas de ferramentas e idas e vindas de rede entram à parte. A latência de busca parece pouco relevante em uma única interação, mas, dentro de uma cadeia de múltiplos passos, passa a fazer parte da percepção geral.
Bancos de dados de uso geral estão absorvendo produtos especializados
Colocar a busca vetorial em escala de dezenas de bilhões dentro de um serviço gerenciado compatível com PostgreSQL aponta para o mesmo caminho: vetores deixam de precisar de uma infraestrutura própria e separada.
Para clientes empresariais, essa conta é fácil de fazer. Os dados de negócio já estão em bancos relacionais — tabelas de usuários, pedidos, regras de permissão já estão lá. Manter os vetores em um banco especializado separado significa duas rotinas de backup, dois esquemas de permissão, duas garantias de consistência, além de ter que lidar sozinho com limites de transação entre bancos. Se basta adicionar um índice ao banco existente, a complexidade operacional cai pela metade.
A posição dos bancos de dados vetoriais especializados também mudou nos últimos dois anos. Eles ainda têm vantagem em desempenho extremo e na velocidade de evolução dos algoritmos de busca, mas os bancos de uso geral vêm elevando continuamente o patamar do suficiente — de milhões para centenas de milhões, e agora para dezenas de bilhões. O espaço restante para produtos especializados foi reduzido àquela fatia pequena com as exigências mais rígidas de latência e throughput.
Desta vez, o AlloyDB não divulgou número de partições, dimensão dos vetores, tempo de construção do índice nem limite de QPS. Esses parâmetros costumam ter mais valor prático na escolha real do que a escala máxima, especialmente o tempo de construção do índice — o custo de reconstrução em escala de dezenas de bilhões pode ser desproporcionalmente alto.
Fontes: blog oficial do Google Cloud, documentação do índice ScaNN do AlloyDB, CocoLoop; os números de escala de vetores, latência P95 e recall seguem o anúncio oficial, as conversões de complexidade são estimativas editoriais.