RAG entra quando você consegue apontar o que o grep está perdendo

Tenho cerca de 200 lições aprendidas espalhadas entre dez projetos. São trechos de markdown, cada um com scope, project e data, escritos ao longo de meses de trabalho real — coisas que custaram caro para descobrir e que eu não quero redescobrir. O grep parou de encontrá-las.

Não foi de uma vez. Foi um aprendizado de cada vez que, num projeto novo, eu sabia que já tinha aprendido aquilo antes — e não conseguia trazer a lição de volta. Um exemplo concreto: a mesma ideia aparecia escrita em três vocabulários diferentes. Em um repositório eu chamava de "translation pipeline". Nas anotações em português, "tradução automática". Em um outro projeto, o serviço se chamava "Mt-service" e a lição ficou indexada por esse nome. Buscar por qualquer um dos três perdia os outros dois. O conhecimento estava lá, escrito, versionado, acessível — e invisível.

Foi medindo essa falha que decidi montar o MemSearch: um banco de lições aprendidas indexado vetorialmente, distribuído entre todos os projetos. Quando faço uma pergunta em qualquer sessão, um hook recupera as três lições mais relevantes e injeta no contexto. É um sistema RAG. E o ponto deste artigo não é a busca semântica em si — é como ela entrou em pauta. Só entrou depois que a busca burra perdeu algo identificável.

Quando faz sentido pagar o preço

Essa é a parte que quase ninguém diz quando vende RAG: é uma engrenagem a mais para manter. Você embeda o corpus, guarda os vetores, re-embeda quando troca de modelo, lida com os casos em que o trecho recuperado está fora de contexto. Não é gratuito. O que justifica o custo é uma falha concreta da busca por palavra-chave — uma falha que você consegue apontar, mostrar, repetir.

No MemSearch a falha era variação de vocabulário sobre um corpus pequeno. Em outros projetos a falha é diferente: contratos jurídicos que falam em "rescisão" e "encerramento" sobre o mesmo evento; documentação técnica em que o mesmo conceito tem nome diferente no time de produto e no time de engenharia; perguntas de cliente que descrevem o sintoma quando o manual indexa por causa. Em todos esses casos, RAG resolve o problema do sinônimo. Em nenhum deles RAG resolve o problema de o corpus estar errado ou desatualizado — se o documento está obsoleto, recuperá-lo melhor só entrega a resposta errada com mais confiança.

A pergunta honesta, antes de qualquer escolha de arquitetura, é: a busca por palavra-chave já está entregando o que você precisa? Se sim, RAG é peso morto. Se não, você consegue mostrar três exemplos do que está sendo perdido? Se não consegue mostrar, ainda não está pronto.

A arquitetura, e por que ela ficou pequena

Para o MemSearch escolhi SQLite com a extensão sqlite-vec. Cada lição vira uma linha com seu vetor e seus metadados. Antes da busca semântica, filtro por scope — projeto, domínio, ou universal — e só depois faço o re-ranking vetorial sobre o subconjunto. O hook que dispara a cada prompt tem orçamento de menos de 300ms para devolver as três lições. É pouco tempo, e é pouco tempo de propósito: se eu não consigo recuperar rápido, o hook quebra o ritmo de quem está usando o sistema, e aí o hook morre por desuso.

Pinecone, Weaviate, Qdrant ficaram de fora pela mesma razão. Para 200 entradas, a chamada de rede para um serviço externo já gasta o orçamento de latência sozinha, antes de a busca acontecer. Pagar lock-in de fornecedor, custo mensal e dependência de uptime para indexar um corpus que cabe em memória é a definição de overkill. A decisão não foi "escolher SQLite por elegância" — foi "justificar uma chamada de rede no caminho crítico, e não conseguir". Quando a restrição é local e o corpus é pequeno, o banco vetorial certo é o que roda no mesmo processo.

Há um custo escondido que vale mencionar, porque ele aparece tarde: lock-in no modelo de embedding. Trocar de modelo significa re-embedar o corpus inteiro. Para 200 lições isso é uma execução de poucos minutos; para um corpus corporativo de centenas de milhares de documentos é um projeto com cronograma. E o re-ranking semântico injeta latência mesmo num corpus pequeno — para o MemSearch os 300ms cabem porque o hook dispara em momentos discretos, com folga; num chatbot em tempo real, com usuário esperando token por token, esse mesmo orçamento pode ser caro demais. RAG resolve o problema de sinônimo no presente, te amarra ao espaço vetorial que você escolheu hoje, e cobra latência mesmo nos cenários em que parece de graça. Existem técnicas para mitigar cada um desses custos — busca híbrida, re-ranking em duas etapas, cache de queries — mas elas são otimização de uma decisão que já foi tomada, não substituem a decisão.

O critério, não a sigla

RAG não é uma decisão de arquitetura. É a admissão de que sua busca por palavra-chave perdeu algo específico que importa, e que o custo de continuar perdendo passou a ser maior do que o custo de embedar tudo. Se você não consegue apontar o que está sendo perdido — em três exemplos concretos, com o vocabulário em que está perdendo —, a próxima coisa que você precisa não é um banco vetorial. É medir melhor a sua busca atual.