LEANN: 201 GB contra 6 GB?! Instalei este banco vetorial INSANO

Autoria: Prompt Engineer 48 · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: LEANN: 201 GB vs 6 GB?! I Installed This INSANE Vector DB · Canal: Prompt Engineer 48 · 03:36 · Assistir no YouTube

Tópicos: Claude Code, Dados, bancos de dados e embeddings, Modelos locais e open source, Privacidade e proteção de dados, RAG, busca e recuperação de informação

Resumo

O vídeo apresenta o LEANN, uma ferramenta que promete reduzir o espaço usado por índices vetoriais ao recomputar embeddings durante a busca, em vez de armazená-los todos. O criador instala a ferramenta e testa a indexação e a busca em Pride and Prejudice, observando um índice menor, mas buscas lentas em seu laptop com CPU. Em um teste offline com um modelo Qwen de 4 bilhões de parâmetros, a recuperação encontra passagens úteis, mas o modelo interpreta algumas delas incorretamente. O autor ressalta que o teste foi pequeno e não valida as alegações em grande escala, mas considera o LEANN interessante para quem prioriza espaço em disco e privacidade.

Pontos-chave

O README do LEANN afirma que pode indexar 60 milhões de trechos de texto usando 6 GB, em comparação com 201 GB para um banco vetorial convencional; o autor não testou essa escala.
O LEANN armazena um grafo de relações entre trechos e recomputa embeddings apenas para os nós consultados durante a busca.
A troca é reduzir o espaço em disco à custa de mais computação durante a busca.
No teste com Pride and Prejudice, o arquivo do grafo ocupou 482.000 bytes para 1.776 trechos; a pasta inteira ocupou 5,3 MB.
Uma busca levou 48 segundos no laptop com CPU, e outras chegaram a 76 segundos.
O modo offline continuou funcionando depois que a conexão com a internet caiu, sem enviar os dados do teste para fora do laptop.
O modelo Qwen de 4 bilhões de parâmetros falhou em algumas respostas, apesar de a busca recuperar passagens relevantes.
O teste foi limitado a um livro e três perguntas, portanto não é um benchmark.
O README relata recall inicial 2,1 vezes melhor que BM25 em 30 tarefas com integração ao Claude Code; o autor não verificou esse resultado.

Capítulos

Início	Capítulo	Resumo
00:00	O problema do armazenamento de embeddings	O vídeo apresenta a promessa de economia de espaço do LEANN e explica por que armazenar embeddings pode ocupar mais espaço que os próprios textos.
00:31	Como o LEANN reduz o índice	A ferramenta mantém um grafo de trechos relacionados e recomputa embeddings durante a busca, trocando espaço em disco por tempo de computação.
01:31	Instalação e teste com um romance	Após corrigir um erro de Unicode no Windows, o autor indexa Pride and Prejudice e compara o tamanho do grafo com o dos embeddings armazenados convencionalmente.
02:33	Teste de respostas com Qwen	O autor usa um modelo local de 4 bilhões de parâmetros e encontra erros de interpretação mesmo quando a busca recupera passagens relevantes.
03:05	Conclusão e ressalvas	O autor considera o LEANN promissor para privacidade e economia de disco, mas ressalta a lentidão observada e o escopo limitado do teste.

Citações

O LEANN diz que são 6 GB. Essa é a tabela do README, não minha. — 00:00

Você economiza espaço em disco, mas paga com computação na hora da busca. — 01:01

Um único romance não consegue demonstrar isso, então não vou fingir que consegue. — 02:02

São três perguntas, um livro; isso não é um benchmark. — 03:05

Conceitos e entidades

LEANN (ferramenta): Ferramenta de indexação e busca que reduz o armazenamento de embeddings ao recomputá-los durante a consulta.
RAG (conceito): Abordagem que permite fazer perguntas sobre documentos recuperando trechos relevantes para fornecer contexto às respostas.
embedding (conceito): Representação numérica de um trecho de texto usada para comparar sua semelhança com outros conteúdos.
BM25 (conceito): Método de busca textual usado como referência na comparação mencionada pelo README.
UV (ferramenta): Ferramenta usada no vídeo para instalar o LEANN com dois comandos.
PyTorch (ferramenta): Biblioteca cuja instalação foi a maior parte do tempo de instalação relatado.
Pride and Prejudice (conceito): Romance usado como conjunto de textos para testar a indexação e a busca.
Qwen (modelo): Família de modelos; no teste, o autor usou um modelo com 4 bilhões de parâmetros.
Ollama (ferramenta): Ferramenta usada para executar localmente o modelo Qwen no teste.
Claude Code (ferramenta): Produto citado como integração do LEANN em um resultado relatado no README.

Tradução completa (pt-BR)

00:00 60 milhões de trechos de texto. Um banco de dados vetorial normal precisa de 201 GB para isso. O LEANN diz que precisa de seis. Essa é a tabela do README, não minha. E eu não testei nessa escala, mas instalei no meu laptop hoje. E algumas coisas me surpreenderam. [música] Aqui vai a história. Você tem anos de anotações, PDFs, chats e código. Quer fazer perguntas sobre eles. Então, tenta usar RAG. Etapa um: transformar cada trecho em um embedding, uma lista de centenas de números. Etapa dois: armazenar todos eles.

00:31 Essa segunda etapa é o problema. Os vetores costumam ser maiores que o próprio texto. A tabela do próprio README mostra um banco de dados normal ocupando 3,8 GB para um conjunto de dados que o LEANN armazena em 324 megabytes. Então, você tem duas opções. Encher seu disco ou enviar seus dados privados para um serviço na nuvem e pagar por consulta. Nenhuma das opções é boa se os dados forem seus e-mails. Então, a pergunta de verdade é: precisamos mesmo armazenar todos os embeddings? A resposta do LEANN, segundo o artigo, é não. Ele mantém um grafo que conecta trechos semelhantes, poda esse grafo agressivamente e, quando você faz uma busca, só calcula embeddings para os poucos

01:01 nós no caminho da busca. Pense em um mapa sem fotos de cada rua. Você percorre o mapa e tira uma foto só do lugar para onde está indo. Isso é recomputação seletiva. A troca é óbvia. Você economiza espaço em disco, mas paga em computação na hora da busca. Lembre-se disso, porque isso aparece no meu teste. Instale. Dois comandos com UV. Levou 4 minutos e 48 segundos na minha máquina, principalmente por causa do PyTorch. Então, minha primeira criação travou com um erro de Unicode. O LEANN exibe emojis e meu console do Windows não consegue mostrá-los. A solução é uma configuração: PYTHONUTF8=1.

01:31 Depois disso, ele criou Orgulho e Preconceito: 770 kilobytes, 1.776 trechos, 3 minutos na CPU. Agora, a alegação sobre armazenamento: o arquivo do grafo tem 482.000 bytes. Armazenar cada embedding da maneira normal — 1.776 trechos vezes 384 números — daria cerca de 2,7 megabytes. Então, nesse livro pequeno, o grafo é 82% menor, não 97%, e a pasta inteira tem 5,3 megabytes porque também mantém o texto e um índice de palavras-chave. Os 97% são para coleções enormes.

02:02 Um único romance não consegue demonstrar isso, então não vou fingir que consegue. Busca: “Quem foge com Wickham?”. Ela retorna o trecho sobre Lydia e Wickham serem encontrados em Londres. É o lugar certo. Mas olhe o relógio. 48 segundos, e os outros levaram até 76. Isso é na CPU, em cada comando. Tentei o daemon de aquecimento e ele não acelerou as coisas no Windows. Esse é o preço da recomputação. Depois, algo legal. Minha internet caiu no meio da sessão e o Hugging Face não conseguiu resolver o endereço. Ativei o modo offline e tudo continuou funcionando. Busca por embeddings, até a resposta. Nada saiu do meu laptop. Agora, fazer perguntas com um Qwen de 4 bilhões

02:33 de parâmetros rodando localmente. Mais dois contratempos. Meu host do Ollama não tem HTTP na frente. Então, passei o host explicitamente, e o aquecimento deixou um processo Python obsoleto ocupando a porta. Então, encerrei o processo. Aí vieram as respostas. Primeira pergunta: por que Elizabeth recusa Darcy? A recuperação não encontrou o pedido de casamento, e o modelo disse que não havia pedido de casamento. Errado. Na segunda, a recuperação encontrou a fala verdadeira de Darcy, mas o modelo pequeno decidiu que ela o aceita. Na terceira, encontrou a frase sobre Collins trocar Jane por Elizabeth e, mesmo assim, interpretou errado. Então, no meu teste, a busca encontrou trechos úteis na maior parte das vezes, e o modelo de 4 bilhões

03:05 foi o elo fraco. Foram três perguntas, um livro, não um benchmark. Então, vale a pena se o seu problema for espaço em disco e privacidade? Sim. Um índice pequeno, totalmente offline, com licença MIT. O README também mostra o LEANN integrado ao Claude Code, com uma recuperação inicial 2,1 vezes melhor que BM25 em 30 tarefas. Não testei isso. Se você precisa de respostas rápidas hoje, espere cerca de um minuto por busca em um laptop com CPU e use um modelo maior que o meu. O link do repo está na descrição. Se quiser que eu teste uma configuração com Claude Code na nuvem em seguida, ou o índice de e-mails, conte nos comentários. E se

03:36 você gosta de vídeos em que eu instalo coisas, mostro os travamentos e os números reais, inscreva-se no meu canal, Prompt Engineer. Até a próxima.

Transcrição original

[00:00] 60 million text chunks. A normal vector database needs 201 GB for that. Lean says six. That’s the readme’s table, not mine. And I have not tested that scale, but I did install it on my laptop today. And some of it surprised me. [music] Here’s the story. You have years of notes, PDFs, chats, code. You want to ask questions over them. So, you try Rag. Step one, turn every chunk into an embedding, a list of hundreds of numbers. Step two, store all of them.

[00:31] That second step is the problem. The vectors are often bigger than the text itself. The readme’s own table shows a normal database at 3.8 GB for a data set where lean needs 324 megabytes. So you have two choices. Fill your drive or send your private data to a cloud service and pay per query. Neither is great if the data is your email. So the real question is, do we need to store every embedding at all? Lean’s answer from the paper is no. It keeps a graph that connects similar chunks, prunes that graph hard, and when you search, it only computes embeddings for the few

[01:01] nodes on the search path. Think of a map without photos of every street. You walk the map and take a photo only where you’re going. That’s selective recomputation. The trade is obvious. You save disk, but you pay compute at search time. Keep that in mind because it shows up in my test. Install it. Two commands with UV. It took 4 minutes 48 seconds on my machine, mostly PyTorch. Then my first build crashed with a unic code error. Lean prints emoji and my Windows console can’t show them. The fix is one setting t is t

[01:31] you equals one. After that it built pride and prejudice 770 kilobyt 1776 chunks 3 minutes on the CPU. Now the storage claim the graph file is 482,000 bytes storing every embedding the normal way. 1776 chunks times 384 numbers would be about 2.7 megabytes. So on this small book, the graph is 82% smaller, not 97 and the whole folder is 5.3 megabytes because it also keeps the text and a keyboard index. The 97% is for huge

[02:02] collections. A single novel can’t show that so I won’t pretend it does. Search who runs away with Wickham. It returns the passage about Lydia and Wickcham being found in London. That’s the right place. But look at the clock. 48 seconds and the others took up to 76. This is on CPU each command code. I tried the warm-up demon and it did not speed things up on Windows. That’s the price of recomputing. Then something nice. My internet dropped midsession and hugging face couldn’t resolve. I set offline mode and it all kept working. Embedding search even the answer. Nothing left my laptop. Now ask with a 4 billion

[02:33] parameter Quen running in. Two more snacks. My Olama host has no HTTP in front. So I passed the host explicitly and the warm-up left a stale Python process holding the port. So I killed it. Then the answers. First question, why does Elizabeth refuse Darcy? Retrievo missed the proposal and a model set no proposal exists. Wrong. Second, retrieval did find Darcy’s real line, but the small model decided she accepts him. Third, it found the sentence about Collins switching from Jane to Elizabeth, then still misread it. So in my test, search found useful passages most of the time, and the 4 billion

[03:05] model was the weak link. That’s three questions, one book, not a benchmark. So is it worth it if your problem is disk and privacy? Yes. a small index fully offline MIT license. The readme also shows it plugged into claude code reporting 2.1 times better early recall than BM25 on 30 tasks. I haven’t tested that. If you need fast answers today, expect about a minute per search on a CPU laptop and use a bigger model than mine. The repo link is in the description. If you want me to test a cloud code setup next or the email index, tell me in the comments. And if

[03:36] you like videos where I install things, show you the crashes and the real numbers, subscribe to my channel, Prompt Engineer. See you in the next one.