Vou começar com a confissão que provavelmente vai irritar metade do LinkedIn de IA: eu rodo dois sistemas de recuperação em produção, todo dia, há meses, e nenhum dos dois tem vector DB. Sem chunking. Sem embedding. Sem Pinecone. O retrieval é grep mais leitura de arquivo estruturado mais um modelo com janela longa fazendo a filtragem fina. E funciona melhor do que o RAG clássico funcionaria para esses casos.
A tese que virou dogma por volta de 2023 era simples: o leitor (a LLM) é pequeno e caro, então o retriever precisa ser esperto. Embedding tudo, indexar, buscar por similaridade, mandar só o top-K. Era a arquitetura certa para aquele momento. O problema é que muita gente continua pagando o preço dessa arquitetura sem perceber que o gargalo já inverteu.
O gargalo inverteu (e quase ninguém atualizou a mente)
Em 2026 o leitor é o componente mais inteligente da mesa, e a janela cabe um livro inteiro. Quando o leitor ficou genial e barato com prompt caching, o retriever pode voltar a ser burro. E o retriever mais burro e mais transparente que existe é grep.
Não é teoria. As ferramentas de agente mais avançadas de hoje foram exatamente nessa direção: em vez de um índice vetorial, memória baseada em arquivo de texto, um arquivo-índice de ponteiros, arquivos de tópico com os fatos, e busca textual direta para consolidar. A memória de um agente no estado da arte é, com frequência, um subagente fazendo grep em arquivo de texto. Isso deveria reorganizar a sua intuição sobre o que é “state of the art”.
O que eu medi no meu próprio setup
Aqui entram os números que importam, porque eu medi, não chutei. Meu segundo cérebro (um vault Obsidian) tem 3.323 notas curadas entre literatura e notas atômicas. Um agente meu de conhecimento roda sobre 1.192 arquivos de base estruturada. Em ambos, a recuperação é grep mais leitura de arquivo inteiro mais contexto longo. Zero embeddings. Zero vector DB. Em produção diária.
Por que isso ganha do RAG clássico nesses casos? Três motivos práticos.
Primeiro, falha transparente. Quando o grep não acha, ele me diz “a palavra não está aqui”. Quando o vector DB erra, ele devolve com confiança o vizinho errado, e você descobre tarde. Depurar um falso vizinho em produção custa mais caro que qualquer servidor.
Segundo, sem índice envelhecendo. Editei uma nota agora? Ela já está na busca, porque a busca lê o disco. Não existe reindexação, não existe drift entre o que está no banco e o que está no arquivo.
Terceiro, a conta de custo é uma armadilha. “RAG economiza tokens” ignora que engenheiro custa caro e bug em produção custa mais. Para uma base pequena ou média, o setup e a manutenção de um Pinecone consomem mais do que você economiza. No contexto BR isso pesa o dobro: time enxuto, orçamento de cloud apertado, e cada peça de infra a mais é uma peça a mais para alguém ficar de plantão.
Quando o vector DB AINDA ganha (sendo honesta)
Agora a parte que os arautos do “RAG morreu” omitem. Vector DB não morreu. Ele só deixou de ser o default obrigatório.
O LaRA, benchmark do ICML 2025, foi direto: não existe bala de prata, a escolha depende de modelo, tamanho do corpus e tipo de tarefa. E o veredito quantitativo é claro. RAG domina quando o corpus passa de alguns milhões de tokens, quando a busca semântica fuzzy importa de verdade (o usuário descreve por sinônimo, não pela palavra exata), quando você precisa de freshness em escala e atribuição de fonte. Contexto longo nesses cenários chega a ser 8 a 82 vezes mais caro do que recuperar só o relevante (Li et al., 2024, arXiv:2407.16833).
Some a isso o velho “Lost in the Middle” (Liu, 2023): a precisão do modelo desenha um U, alta no começo e no fim do contexto, e cai mais de 30% no meio. Os modelos de 2026 melhoraram muito nisso, mas a régua continua valendo: enfiar 1M de tokens não é grátis em qualidade. Para corpus gigante e busca semântica de verdade, recuperar bem ainda bate despejar tudo.
A pergunta-teste que eu uso: a resposta certa cabe em poucos arquivos que eu acho por palavra, ou está espalhada em milhares de documentos que eu só acho por significado? Primeiro caso, grep mais contexto longo. Segundo caso, é hora do vector DB (ou de GraphRAG, se a pergunta for global sobre o corpus inteiro).
O veredito
Comece simples. Documentos brutos no disco, filtro lexical rápido, carregue o arquivo inteiro, deixe o modelo filtrar. Adicione embedding só quando sentir falta, com dado real mostrando onde o lexical falhou. Eu testei a versão complexa primeiro na carreira e me arrependi. Hoje minha régua é o contrário: a stack sofisticada precisa justificar a própria existência, não o inverso.
Vector DB é uma ferramenta excelente para o problema certo. O erro é tratar “RAG” e “vector DB” como sinônimos e instalar Pinecone reflexamente antes de tentar grep.