A busca vetorial é o imposto silencioso de escalonamento sobre cada sistema RAG e cada agente que lembra. Os embeddings só crescem, e em algum ponto a conta de memória força a quantização — você encolhe os vetores, come uma perda de recall. O Qdrant 1.18, lançado em 11 de maio, adiciona o TurboQuant, e o enquadramento que importa é o que a própria documentação coloca à frente: não "podemos encolher vetores?" mas "podemos encolhê-los sem quebrar sua geometria?". Essa é a pergunta certa, porque recall é geometria — se a quantização distorce as distâncias de forma desigual, seus vizinhos mais próximos param de ser os mais próximos.

O mecanismo do TurboQuant é uma rotação ortogonal aleatória aplicada antes da compressão, e depois um único codebook fixo. Os embeddings são anisotrópicos — um punhado de dimensões carrega a maior parte da variância (o conjunto DBpedia OpenAI que usam de benchmark tem uma razão de 233,5x entre as dimensões mais fortes e as mais fracas). A quantização escalar trata cada dimensão igualmente, então desperdiça bits em dimensões mortas e mata de fome as vivas. A product quantization conserta isso com codebooks por subespaço, mas esses precisam de treino por dataset e ficam obsoletos quando seus dados se deslocam. A rotação do TurboQuant espalha a variância igualmente por todas as dimensões primeiro, então um único codebook uniforme é agora quase ótimo — e como a rotação é aleatória e fixa, a coisa toda é data-oblivious. Sem treino, sem recalibração na ingestão. Os números, sobre DBpedia de 1536 dim: TQ 4-bit atinge ~8x de compressão com recall@10 de 0,965 (0,996 com rescoring), 6,4ms de latência contra os 7,6ms do float32, 72 MB de armazenamento onde a quantização escalar precisa de 144. As ressalvas honestas pesam. O 32x de destaque é o TQ 1-bit, que o autor chama diretamente de "não uma escolha segura" — o recall desaba. O número usável é 8x a 4-bit. O recall de 0,996 se apoia no rescoring, o que significa manter os vetores completos para re-rankear, recuperando parte do ganho de armazenamento. A quantização binária ainda é mais rápida em throughput bruto; o TurboQuant ganha na estabilidade de recall em escala (0,965 onde o binário despenca para 0,78 a 100K), não na velocidade. E é testado em exatamente um dataset — um maximamente anisotrópico, que é o caso mais favorável para um método baseado em rotação. Sobre embeddings mais planos, isotrópicos, a rotação te compra muito menos, e esse caso não é medido.

O que isso faz ao ecossistema é o padrão de banalização em velocidade: um resultado da Google Research do ICLR 2026 vira um flag de config de uma linha num vector DB de código aberto em semanas. Toda a camada RAG e de agent-memory ganha quantização quase ótima, sem calibração, sem que ninguém na equipe precise entender a teoria da quantização. Também pressiona os vendedores de vector DB gerenciados cujo pitch inclui "afinamos a compressão por você" — quando a quant data-oblivious é um parâmetro `bits=4`, esse fosso de afinação afina. A propriedade data-oblivious é a razão específica para usar isso em vez de product quantization: para memória de agente de longa duração onde a distribuição de embeddings se desloca conforme você ingere, os codebooks aprendidos da PQ saem de calibração e você retreina; a rotação do TurboQuant não liga para como seus dados são, então não há nada a reajustar.

Segunda de manhã, se você roda busca vetorial em escala: ligue o TQ 4-bit (não 1-bit) como opt-in no Qdrant 1.18 e meça o recall@k no seu próprio corpus, com e sem rescoring, antes de confiar no 8x. A instrução do próprio autor é a operante — esses números vêm do DBpedia maximamente anisotrópico, e sua distribuição de embeddings é provavelmente mais plana, que é exatamente onde a rotação paga menos. Trate o 8x-a-0,965 como um teto a validar, não um número a presumir. E se sua métrica de distância for L1/Manhattan, pule — o TurboQuant precisa de reconstrução completa ali e a vantagem de velocidade evapora; a quantização escalar continua a opção mais segura.