Otimização de busca vetorial: índices em RAM vs. disco — quando a memória fica cara demais

O problema do custo da RAM na busca vetorial em escala

Com a explosão dos sistemas agentivos em 2026, a busca vetorial deixou de ser apenas uma ferramenta de RAG para se tornar a espinha dorsal da memória e do contexto de agentes de IA. O resultado? Índices que antes eram de alguns milhões de vetores agora precisam escalar para centenas de milhões — ou bilhões. E manter tudo em RAM está ficando caro demais.

Um índice de 100 milhões de vetores em float32 com 1.024 dimensões, com replicação fator 3 para produção, ocupa cerca de 1,2 TB. Mesmo com quantização escalar (a menos invasiva), ainda são 300 GB. A RAM em nuvem custa aproximadamente US$ 5 por GB/mês — o que coloca a conta em milhares de dólares mensais só para armazenar o índice.

É aí que entram os algoritmos ANN (Approximate Nearest Neighbor) otimizados para disco. Eles não são uma bala de prata, mas representam uma redução de custo de até 50× comparado a manter tudo em RAM. Neste artigo, você vai entender as diferenças, os trade-offs e como escolher a opção certa para o seu caso de uso.

✅ O que você ganha com índices em disco

• Redução massiva de custo: armazenamento em disco (EBS ~US$ 0,08-0,10/GB, NVMe local ~US$ 0,20-0,25/GB) é dezenas de vezes mais barato que RAM.
• Escala horizontal real: índices com bilhões de vetores se tornam viáveis sem multiplicar o custo de infraestrutura.
• Latência aceitável para a maioria dos casos: com o índice quente (em cache), a latência fica na casa de 10-15 ms — perfeitamente adequada para pipelines de RAG com reranker + LLM.
• Menor pressão no orçamento de infra: os recursos de RAM podem ser redirecionados para caching, embedding ou inferência.
• Opções maduras: SPANN (usado pelo Turbopuffer), DiskANN (integrado ao Milvus e PostgreSQL via pg_diskann) e várias outras implementações já estão em produção.

⚠️ O que você NÃO ganha

• Latência de RAM: mesmo no melhor cenário, buscar em disco é mais lento que em RAM. O HNSW em memória entrega < 1 ms; o disco, mesmo quente, fica entre 10-15 ms — e pode chegar a 800+ ms se o índice estiver frio.
• Simplicidade operacional: algoritmos em disco exigem tuning de cache, escolha de storage (NVMe local vs. EBS vs. object storage) e monitoramento de latência mais sofisticado.
• Garantia de latência previsível: a variância é alta — o mesmo índice pode variar 60× em latência dependendo do estado do cache.

Como funcionam os algoritmos ANN

Bancos de dados vetoriais têm três componentes principais: embeddings, índices e algoritmos de busca. O foco aqui são os algoritmos ANN, que substituem a busca exaustiva (kNN) por atalhos inteligentes baseados em grafos.

A busca exata varre todos os vetores, calcula distâncias e retorna os mais próximos. Funciona bem para índices pequenos (até alguns milhares de vetores), mas não escala para produção. Os algoritmos ANN usam uma estrutura de grafo que conecta vetores similares, permitindo chegar ao resultado em poucos “saltos” sem visitar todos os pontos.

HNSW: o padrão da indústria (em memória)

O Hierarchical Navigable Small World (HNSW) é o algoritmo mais adotado — está no Qdrant, Milvus, pgvector, OpenSearch, Weaviate e Redis. Ele constrói um grafo em camadas onde cada vetor se conecta aos seus vizinhos mais próximos. Com o índice inteiro em RAM, a busca é extremamente rápida (sub-milissegundo).

O problema aparece quando o índice cresce além da RAM disponível. Forçar parte do HNSW para disco gera um colapso de desempenho: cada salto no grafo vira uma operação de I/O aleatória no disco, e com tráfego de leitura alto, a latência pode saltar de milissegundos para centenas de milissegundos.

SPANN: clusters no disco com centroides em RAM

O SPANN (Space Partitioning ANN) usa a metodologia de índice invertido (IVF): os vetores são agrupados em clusters, cada um representado por um centroide. A camada de roteamento (centroides) fica em RAM, enquanto os vetores de cada cluster são armazenados sequencialmente em disco.

A diferença crucial para o HNSW em disco é que, como os vetores do mesmo cluster estão contíguos, eles são carregados em blocos — minimizando as operações de I/O. O paper original do SPANN reporta latência de ~1 ms com 90% de recall em escala de bilhões de vetores (em NVMe local).

Exemplos: Turbopuffer (usa SPFresh, sucessor do SPANN) e Chroma DB (cloud).

DiskANN: grafo Vamana com mínimo de saltos

O DiskANN também usa uma estrutura de grafo, mas diferente do HNSW: em vez de múltiplas camadas, o DiskANN usa um grafo de camada única chamado Vamana, que inclui conexões de longo alcance além das conexões de vizinhança imediata. Isso reduz o número de saltos necessários para encontrar os top-k resultados — e, portanto, reduz as operações de I/O.

Os vetores originais ficam em disco, enquanto uma versão altamente quantizada fica em RAM para orientar a busca. O DiskANN escala muito bem em datasets acima de 100 milhões de vetores.

Exemplos: Milvus (suporte nativo) e PostgreSQL (extensão pg_diskann).

Comparação de algoritmos ANN

Custo real: RAM vs. Disco

Os números falam por si. Para um índice de 100 milhões de vetores (1.024 dimensões, float32, fator de replicação 3):

A diferença é linear: conforme o índice cresce, o gap entre RAM e disco só aumenta. Para sistemas agentivos que precisam de bilhões de vetores, o disco deixa de ser uma opção e passa a ser a única opção viável.

Latência não é tudo: o fator cache

O benchmark do Turbopuffer com índice de 10 milhões de vetores ilustra bem: mesma consulta, mesmos dados — 14 ms no p50 quando o índice está quente (cache), mas 874 ms quando frio (precisa buscar do object storage). Uma diferença de 60× causada apenas pelo estado do cache.

Isso significa que, na prática, a latência de disco depende de:

• Hardware: NVMe local vs. EBS vs. S3
• Estado do cache: índice quente (em page cache) vs. frio
• Padrão de acesso: leituras aleatórias vs. varreduras sequenciais
• Dimensionalidade: vetores de alta dimensionalidade saturam a RAM mais rápido

Como escolher: guia prático

• Índice pequeno-médio (< 10M vetores): HNSW em RAM. Simples, rápido, suportado por praticamente todos os bancos vetoriais.
• Índice grande (10M-100M) com orçamento folgado: HNSW com quantização escalar. Reduz o custo em 75% sem impacto significativo na qualidade.
• Índice grande (10M-100M) com orçamento apertado: DiskANN ou SPANN. Latência maior, mas custo cai para fração do HNSW.
• Índice massivo (100M+): SPANN. Projetado especificamente para escala de bilhões com estrutura de roteamento leve em RAM.
• RAG com reranker: O disco serve bem — a latência de 10-100 ms da busca é diluída no tempo total do pipeline (reranker + LLM).
• Memória agentiva com múltiplas consultas por requisição: Prefira RAM — o acúmulo de latência em disco pode se tornar o gargalo.

Casos de uso reais

1. Chatbot de documentação corporativa: índice com milhões de chunks, o reranker já domina a latência total — SPANN ou DiskANN são excelentes opções.
2. Busca semântica em e-commerce: catálogo de produtos com centenas de milhões de itens — SPANN em disco com centroides em RAM.
3. Memória de longo prazo para agentes: histórico de conversas e ações do agente — HNSW em RAM para latência previsível.
4. Detecção de anomalias em tempo real: streaming de eventos comparado com baseline de milhões de vetores — DiskANN equilibra latência e custo.

Troubleshooting: problemas comuns

❌ Sintoma: Latência de busca salta de 5 ms para 200+ ms após deploy.
Causa: Índice HNSW está parcialmente em disco (page faults).
Solução: Garanta que a RAM alocada seja >= tamanho do índice. Ou migre para DiskANN/SPANN.

❌ Sintoma: Recall caiu 15-20% após migrar para disco.
Causa: Parâmetros de quantização muito agressivos ou número insuficiente de clusters.
Solução: Aumente o orçamento de RAM para a camada de roteamento (centroides ou vetores quantizados).

❌ Sintoma: Latência p99 é 50× maior que p50.
Causa: Cache misses frequentes — o índice vai a disco frio regularmente.
Solução: Considere NVMe local em vez de EBS, ou aumente o page cache do sistema.

❌ Sintoma: Custo de storage não caiu como esperado após migrar para disco.
Causa: A réplica de produção ainda está em RAM ou o fator de replicação foi mantido alto.
Solução: Verifique a configuração de replicação — disco permite fatores de replicação mais baixos.

❌ Sintoma: Timeout nas consultas após pico de tráfego.
Causa: I/O do disco saturado — muitos saltos aleatórios simultâneos.
Solução: Aumente a concorrência de I/O ou considere um tier de cache em RAM para vetores quentes.

FAQ

Posso usar HNSW com parte do índice em disco?
Pode, mas não deveria. O HNSW não foi projetado para I/O de disco — cada salto no grafo gera uma leitura aleatória, e o desempenho degrada rapidamente. Use DiskANN ou SPANN.

Qual a diferença entre SPANN e DiskANN na prática?
SPANN agrupa vetores por similaridade e armazena cada grupo contiguamente — ideal para escala massiva (bilhões). DiskANN minimiza o número de saltos no grafo — melhor latência em datasets de até centenas de milhões.

Preciso migrar todo o índice de uma vez?
Não. Muitos bancos (ex: Milvus) suportam múltiplos índices com estratégias diferentes. Você pode manter coleções pequenas em HNSW e coleções grandes em DiskANN no mesmo cluster.

A quantização escalar prejudica muito o recall?
Impacto mínimo — tipicamente menos de 1-2% de perda de recall com redução de 75% no storage. É o melhor custo-benefício antes de ir para disco.

Vale a pena usar NVMe local em vez de EBS?
Para latência, sim — NVMe local é 2-5× mais rápido que EBS. Para custo, o EBS ainda vence (US$ 0,08 vs. US$ 0,20/GB). O ideal é um tier híbrido: cache em NVMe local, armazenamento frio em EBS.

O futuro: para onde vamos

Com a ascensão dos sistemas agentivos e da memória de longo prazo para IAs, a tendência é clara: índices vetoriais vão continuar crescendo em escala muito mais rápido do que a RAM fica mais barata. Os algoritmos de disco — SPANN, DiskANN e seus sucessores — não são uma solução temporária, são o novo padrão de arquitetura para busca vetorial em produção.

Espere ver em 2027: compressão ainda mais agressiva via quantização de 1-bit, hierarquias de storage com S3 como camada fria, e bancos vetoriais nativamente “disk-first” que tratam RAM como cache, não como requisito.