LEANN: Como Um Índice Vetorial De 201 GB Cabe Em 6 GB (Melhor Paper Do MLSys 2026)

Existe uma conta que quase ninguém faz quando decide colocar RAG em produção: quanto espaço o índice vai ocupar em relação ao dado que ele indexa. Na planilha de custo entram o modelo, a GPU, a latência. O disco entra como detalhe, porque armazenamento é barato e a gente aprendeu a não pensar nele. Até o dia em que o índice fica maior que o corpus, e a máquina que deveria rodar aquilo, um notebook ou um servidor pequeno, simplesmente não tem onde guardá-lo.

Foi com esse incômodo na cabeça que parei numa manchete da MarkTechPost, de 27 de outubro, anunciando um índice vetorial de código aberto que reduz um índice RAG de 60 milhões de chunks de 201 GB para 6 GB. Números assim merecem desconfiança de saída, então fui atrás da origem: o LEANN, um paper reconhecido como Best Research Paper no MLSys 2026, com repositório aberto sob licença MIT. A ideia por trás é mais interessante que a manchete, porque não é compressão no sentido habitual. É uma troca deliberada de armazenamento por computação.

Antes de seguir, a transparência de sempre. Não rodei o LEANN. O que sei vem do abstract e do texto do paper no arXiv, da página do MLSys e do README do repositório. A matéria da MarkTechPost eu não consegui ler diretamente; só o título apareceu num resultado de busca, então ela entra aqui como a cobertura que motivou o post, não como fonte de dados. Também não li as tabelas de latência da seção 6 do paper nem a seção de limitações, e vou apontar isso onde importa.

O caminho é este: por que o índice costuma ficar maior que o documento, a ideia central de guardar o grafo e recalcular o vetor, a busca em dois níveis com batching, a poda que protege os nós mais visitados, o que os números do paper e do projeto dizem (separando um do outro) e, por fim, quando essa troca compensa e quando não.

---

Por Que O Índice Fica Maior Que O Documento

Um índice vetorial guarda duas coisas caras. A primeira são os embeddings: cada chunk de texto vira um vetor de alta dimensão, e esse vetor costuma ocupar bem mais bytes do que o próprio texto de onde saiu. A segunda são os metadados da estrutura de busca, como os links de um grafo. O paper do LEANN afirma que as estruturas de busca aproximada (ANN) costumam acrescentar entre 1,5 e 7 vezes o tamanho do dado bruto. Na prática, indexar 100 GB de dados brutos pode exigir de 150 a 700 GB de índice.

Há um detalhe do paper que ajuda a visualizar o problema nos metadados. Um grau típico de 64 num grafo HNSW custa cerca de 256 bytes por nó, e isso já é mais de 25% do tamanho de um chunk de 256 tokens. A conta fecha se você imaginar 64 links de 4 bytes cada, que é como o paper descreve os links (inteiros de 32 bits). Ou seja, antes mesmo de contar o vetor, a estrutura que permite navegar já pesa um quarto do texto que ela aponta.

Esse peso é tolerável num datacenter, onde disco é commodity e o índice vive numa máquina dedicada. Para dispositivos pessoais, o paper é direto: o tamanho torna o uso inviável. Pense em quem quer buscar semanticamente nos próprios e-mails ou no histórico do navegador, tudo local. O corpus é pequeno, mas um índice que o multiplica por vários fatores disputa espaço com todo o resto do dispositivo.

Quem já escolheu banco vetorial sabe que esse custo costuma ser discutido pelo lado da memória e do preço por milhão de vetores. Se você quer a comparação clássica entre as opções, escrevi sobre pgvector, Qdrant, Pinecone e Weaviate. O que o LEANN propõe é outro eixo: em vez de escolher qual banco guarda os vetores de forma mais eficiente, perguntar se é preciso guardá-los.

---

A Ideia: Guardar O Grafo, Recalcular O Vetor

O LEANN usa um índice ANN baseado em grafo, o HNSW, implementado sobre o FAISS. Até aqui, nada exótico. A diferença está no que acontece depois da construção: o LEANN descarta os embeddings armazenados. O que fica no disco é o grafo. Na hora da consulta, quando o algoritmo precisa saber a distância entre a pergunta e um nó, o embedding daquele nó é recalculado com o modelo original, num servidor de embedding local.

Vale desmontar por que isso é razoável e não um absurdo. Uma busca em grafo não precisa comparar a consulta com todos os vetores; ela caminha, a partir de um ponto de entrada, visitando os vizinhos mais promissores. O número de nós realmente visitados numa consulta é minúsculo perto do tamanho do índice. Se só uma fração ínfima dos vetores é lida por consulta, guardar todos eles para sempre é pagar caro por algo que quase nunca é usado. Recalcular só os que a travessia toca troca um custo fixo e enorme (disco) por um custo variável e pequeno (inferência), proporcional ao trabalho da consulta.

O paper prevê uma válvula para quem tem disco sobrando. Se há espaço, o sistema pode fazer cache dos embeddings dos nós de alto grau e recalcular apenas os que não estão em cache. Isso é coerente com o resto do desenho, e a seção sobre poda de grafo explica o motivo: os nós de alto grau são visitados com muito mais frequência. Guardar justamente esses é o melhor uso de um orçamento de armazenamento limitado.

Um cenário hipotético ajuda a ancorar o raciocínio. Imagine um desenvolvedor com um assistente local que indexa anos de e-mail. Num índice tradicional, cada mensagem carrega o texto, o vetor e os links do grafo. No desenho do LEANN, o vetor some depois da construção, e a busca por "o que combinamos sobre o contrato" dispara algumas centenas de recomputações de embedding na hora, em vez de ler vetores do disco. A pergunta de engenharia que sobra é se essas recomputações cabem no orçamento de latência. O resto do paper é, em boa medida, a resposta a essa pergunta.

Existe uma consequência que merece ser dita sem rodeio: o modelo de embedding passa a ser parte do caminho de consulta, não só da indexação. Ele precisa estar disponível, carregado e rápido sempre que alguém busca. O LEANN aponta para backends como Ollama, Hugging Face e endpoints compatíveis com OpenAI, segundo o README. Se você já pensa em servir modelos localmente, o texto que escrevi sobre frameworks de inferência como SGLang, vLLM e Ollama é o pano de fundo certo, porque a vazão desse servidor vira o gargalo central do sistema.

---

Busca Em Dois Níveis E Batching

Recalcular todo vizinho de todo nó visitado seria caro demais, e o paper não faz isso. A busca usa uma distância híbrida em dois níveis. A cada expansão, os vizinhos de um nó recebem distâncias aproximadas e baratas, obtidas por product quantization (PQ), e entram numa fila aproximada, a AQ. Daí os melhores a% da AQ que ainda não estão na fila exata (EQ) recebem a distância exata, recomputada a partir dos embeddings. Nós já vistos permanecem na AQ e podem ser revisitados.

O raciocínio é de triagem. A PQ comprime vetores em códigos curtos e dá uma estimativa grosseira de proximidade, suficiente para decidir quem merece atenção. A recomputação exata, que custa uma passada de modelo, fica reservada para os candidatos que a triagem considerou promissores. O paper dá uma ordem de grandeza do que isso economiza: 2 GB de códigos PQ no lugar de 200 GB de dados em precisão total. Note que esses códigos PQ ainda ocupam espaço, mas são duas ordens de grandeza menores que os vetores completos.

O segundo mecanismo é o dynamic batching. Uma GPU rende pouco quando recebe um vetor por vez, então o LEANN agrupa recomputações ao longo de saltos de expansão sucessivos até atingir um tamanho de lote alvo. O exemplo do paper é 64 numa GPU NVIDIA A10, valor encontrado por profiling offline. Isso tem um preço que o paper reconhece: relaxa levemente a ordem estrita best-first da busca, trocando um pouco de fidelidade de ordem por utilização de hardware.

A comparação com o DiskANN, que o paper faz, é instrutiva porque mostra para onde cada sistema aponta o gargalo. O DiskANN usa uma largura de feixe fixa, pensada para o I/O de disco: quantos nós buscar em paralelo para esconder a latência de leitura. O batching do LEANN mira a vazão de GPU: quantos nós juntar para que a inferência seja eficiente. É a mesma intuição de "paralelize o que é lento", aplicada a um recurso diferente, e isso resume bem a mudança de filosofia. O gargalo deixa de ser o disco e passa a ser o servidor de embedding.

O paper ainda formaliza isso num modelo de custo simples. O tempo de uma consulta é aproximadamente a soma dos graus dos nós ao longo da fila de busca ef, dividida pela vazão do servidor de embedding, que funciona como proxy do custo de recomputação. A leitura é direta: cada nó expandido traz seus vizinhos, cada vizinho candidato custa uma recomputação, e a vazão do servidor de embedding diz quão rápido isso anda. Esse modelo é o que justifica a próxima peça do desenho, porque se o custo cresce com o grau dos nós visitados, controlar o grau é controlar a latência.

---

Poda Que Protege Os Hubs

Se o grafo for armazenado de forma ingênua, seus metadados voltam a ser o problema do início. O LEANN guarda o grafo em formato CSR, com links em inteiros de 32 bits, de modo que o tamanho é proporcional ao número de arestas. Para encolher isso, é preciso podar arestas, e aqui o paper faz uma escolha que me parece a mais elegante do trabalho: não podar de maneira uniforme.

A observação de partida é o acesso assimétrico. Numa travessia de grafo, alguns nós, os hubs de alto grau, aparecem em muito mais caminhos que os demais. Podar igualmente todos os nós sacrificaria justamente os pontos que mais ajudam a navegar. A poda do LEANN limita a maioria dos nós a um grau m e permite que os top a% por grau, cerca de 2% segundo o paper, mantenham um grau maior, até M. Os hubs continuam bem conectados, o resto fica enxuto.

Os valores de m e M não são fixos. Dado um orçamento de armazenamento C, eles são ajustados por profiling offline. Isso torna o parâmetro de armazenamento uma entrada do sistema, algo que o operador define, e o sistema procura a melhor configuração dentro dele. É um desenho que me agrada porque deixa a troca explícita: você diz quanto disco aceita gastar, e a latência é o que se ajusta em resposta.

Pelo modelo de custo da seção anterior, o tempo de consulta depende dos graus dos nós visitados, e os hubs são os mais visitados; manter M alto nos poucos hubs e m baixo no resto concentra o gasto onde ele rende mais. Eu gostaria de ver, no PDF, como o paper mostra a sensibilidade da latência a esses parâmetros, mas essa parte eu não li.

Um detalhe de uso: o repositório oferece dois backends, o HNSW como padrão, que entrega a maior economia de espaço, e o DiskANN, com travessia usando PQ e reranking.

---

O Que Os Números Dizem

Aqui é preciso separar duas fontes, porque são coisas diferentes. Os números do paper são resultados de pesquisa, medidos nos benchmarks NQ, HotpotQA, TriviaQA e GPQA, em duas plataformas: uma workstation com NVIDIA A10 e um Mac com chip M1. O paper reporta mais de 50 vezes de redução de armazenamento em relação a índices estado da arte, 90% de recall top-3 e busca ponta a ponta em menos de 2 segundos nos quatro benchmarks e nas duas plataformas. O abstract fala em índice abaixo de 5% do tamanho do dado bruto e em acurácia de estado da arte com latência comparável em aplicações RAG, além de construção e atualização eficientes em armazenamento.

Os números do README são do próprio projeto, em cinco conjuntos de dados, e é deles que vem a manchete dos 201 GB. A tabela abaixo reproduz o que o repositório informa, sem nenhuma medição minha.

Conjunto (README)	Itens	Antes	Depois	Economia
DPR	2,1 M	3,8 GB	324 MB	91%
Wiki	60 M	201 GB	6 GB	97%
Chat	400 K	1,8 GB	64 MB	97%
Email	780 K	2,4 GB	79 MB	97%
Browser	38 K	130 MB	6,4 MB	95%

Uma observação de aritmética: 201 GB para 6 GB dá algo perto de 33 vezes, não 50. Não há contradição, porque o "mais de 50 vezes" do paper compara com índices estado da arte em seus experimentos, enquanto o README compara o tamanho antes e depois no próprio conjunto. São medidas com bases diferentes, e convém não misturá-las numa frase só. O próprio README diz não haver perda de acurácia em relação a soluções mais pesadas, mas não traz um benchmark geral de acurácia além do teste com agente de código, e também não traz números de latência.

Esse teste com agente de código merece leitura cuidadosa. O README descreve 30 tarefas do SWE-Bench Pro, comparando o LEANN com BM25: o recall inicial de código relevante foi 2,1 vezes maior (24,2% contra 11,4%) e o uso de tokens caiu 8,4%. Os próprios autores avisam que acessar melhor o contexto não garante resolver a issue, e a amostra é pequena. Eu trataria como indício de que a busca semântica ajuda onde o BM25 sozinho falha, não como prova de ganho em produtividade. Se o assunto de recuperação em código lhe interessa, vale conferir o que escrevi sobre repository intelligence e contexto de codebase.

Agora, o que eu não li, e que faria diferença para decidir: as tabelas exatas de latência contra HNSW, IVF-Disk e DiskANN, na seção 6 do paper; a seção de limitações, a 8.2; e o comportamento de atualização incremental, isto é, o que acontece quando o corpus muda depois da construção. O abstract promete atualização eficiente em armazenamento, mas não sei como isso se comporta em escrita pesada. São exatamente os três pontos que eu abriria no PDF dos proceedings antes de levar a ideia para uma decisão de arquitetura.

---

Quando Compensa E Quando Não

O que segue é raciocínio meu, não resultado do paper. O mecanismo troca disco por GPU ou CPU a cada consulta, o que significa que o custo não desapareceu, só mudou de lugar. Ele saiu do armazenamento e foi para a latência e para o hardware de inferência. Se a sua restrição é espaço, essa troca é ótima. Se a sua restrição é latência ou custo de computação por consulta, ela pode ser péssima.

Compensa, em princípio, quando o dado é grande para o dispositivo que o abriga e as consultas são poucas e tolerantes a alguns segundos. O caso de uso das buscas pessoais, e-mail, conversas, navegador, encaixa nisso, e o paper de fato mira dispositivos pessoais, com resultado abaixo de 2 segundos de ponta a ponta no Mac com M1. Também me parece promissor para quem precisa de um índice grande num ambiente em que o disco é o recurso escasso e a inferência está disponível de qualquer jeito, porque o modelo já roda ali para outra finalidade.

Não compensa, também em princípio, quando o índice é pequeno e cabe confortavelmente na RAM, porque então não há o que economizar e você só adicionou inferência ao caminho da consulta. Tampouco quando o servidor tem memória de sobra: se guardar os vetores não incomoda, recomputá-los é trabalho extra sem contrapartida. E se o serviço atende muitas consultas por segundo, a recomputação por consulta multiplica a carga no servidor de embedding, enquanto ler vetores já guardados escala de forma mais barata. Esse último ponto é o que mais me deixaria cauteloso, e é onde as tabelas de latência da seção 6 fariam falta.

Um cenário hipotético para fixar a ideia. Imagine dois times. O primeiro mantém uma base de conhecimento interna de 2 GB de texto, em um servidor com memória de sobra, consultada por centenas de pessoas ao longo do dia. Aqui o LEANN dificilmente se paga: o índice cabe na máquina, e cada consulta passaria a pagar inferência desnecessária. O segundo constrói um assistente local que indexa o conteúdo de um notebook, com a restrição de que nada sai da máquina e de que o índice não pode ocupar mais que algumas centenas de megabytes. Aqui a troca faz sentido, porque o espaço é o que falta e a latência de uma busca ocasional é tolerável.

Para quem trabalha com RAG em geral, o LEANN não substitui as discussões de qualidade de recuperação. Ele mexe no custo de armazenamento do índice, não na qualidade dos candidatos que a busca encontra. Técnicas como busca híbrida, HyDE e reranking, que tratei em um post sobre RAG avançado, continuam relevantes, e a pergunta de quando RAG vale a pena em vez de contexto longo, que discuti em outro texto sobre RAG versus janela de contexto longa, vem antes de qualquer escolha de índice.

---

Conclusão

O que mais me interessa no LEANN não é o número da manchete, e sim o princípio: um embedding é derivável, então guardá-lo é uma escolha, não uma necessidade. Esse tipo de inversão costuma ser produtiva em engenharia, porque aponta para um custo que ninguém questionava. Trocar armazenamento por recomputação só é boa troca quando o recurso que sobra é computação, e o paper tem o mérito de tornar essa troca explícita e parametrizável, com um orçamento de armazenamento como entrada e a latência como saída.

Também preciso repetir os limites do que li. Descrevo um paper, um README e uma manchete que não consegui abrir, não um uso real. Os números do projeto são do projeto, os do paper são de pesquisa em dois ambientes de hardware específicos, e nenhum deles é uma medição independente. As tabelas de latência contra HNSW, IVF-Disk e DiskANN, a seção de limitações e o comportamento de atualização incremental ficaram fora da minha leitura, e são justamente o que eu verificaria no PDF dos proceedings antes de recomendar a um time.

Minha posição é de interesse com cautela. Para busca pessoal e local, e para qualquer cenário em que o disco seja o recurso mais escasso, a ideia parece sólida e o ganho de espaço é grande demais para ignorar. Para serviços com muita consulta e memória disponível, desconfio que a vantagem encolhe ou some, mas isso é suspeita, não resultado. Se alguém do seu time pensa em adotar, a pergunta útil não é "quanto espaço economiza", e sim "quanto a nossa latência aguenta pagar por isso".

Fontes:

• arXiv — LEANN: A Low-Storage Vector Index
• arXiv (HTML) — LEANN, versão 1
• MLSys 2026 — LEANN (apresentação oral)
• GitHub — StarTrail-org/LEANN
• MarkTechPost — Meet LEANN (cobertura que motivou o post; não lida diretamente)
• MLSys 2026 — PDF do paper nos proceedings