← Voltar ao blog

Wikis em Markdown Estão Silenciosamente Substituindo o RAG. Veja o Porquê.

· Save Team
ragllmknowledge-basekarpathymcpaisave-vaultmarkdown

Por dois anos, a resposta padrão para “como forneço meu conhecimento a um LLM?” era RAG. Construa um banco de dados vetorial. Divida seus documentos em chunks. Faça embeddings. Execute busca nearest-neighbor no momento da query. Junte os resultados de volta ao prompt.

Funcionava. Mais ou menos. Quem já colocou um sistema RAG em produção conhece as formas de falha: chunks que perdem o contexto, embeddings que recuperam a passagem errada, rankings opacos, sem proveniência, casos extremos estranhos quando o usuário pergunta algo para o qual o índice não foi otimizado.

Em abril de 2026, Andrej Karpathy publicou um workflow que não faz quase nada disso e funciona melhor para conhecimento pessoal. Ele chama de LLM Knowledge Bases. A arquitetura é simplesmente uma pasta de arquivos markdown, um LLM com acesso ao sistema de arquivos e um hábito. O VentureBeat chamou de “uma biblioteca markdown em evolução mantida por IA” — uma descrição que captura o que é realmente novo.

O padrão pós-RAG chegou. Este artigo explica o que é, por que funciona e como o Save Vault o torna acessível sem nenhuma configuração de desenvolvedor.

O Que o RAG Tentava Resolver

O problema original: LLMs têm uma janela de contexto fixa, sua base de conhecimento é maior que a janela, então você precisa de uma forma de recuperar a fatia relevante para cada pergunta.

Em 2023, vetores eram a resposta óbvia. Embeddings em tudo, busca por similaridade, injetar os top-k chunks. Combinava bem com as pequenas janelas de contexto do GPT-3.5 e Claude 1. Todo o padrão de “startup de IA” era “RAG sobre X.”

Três coisas mudaram.

  1. As janelas de contexto explodiram. O Claude lançou contexto de 1M tokens este ano. Gemini e GPT-5 são similares. Um milhão de tokens equivale a aproximadamente 750.000 palavras — suficiente para manter um pequeno wiki inteiramente na memória.
  2. O filesystem MCP foi lançado. LLMs agora podem abrir arquivos no disco diretamente. Não precisam de chunks pré-indexados. Podem navegar, ler e reler como um humano.
  3. LLMs ficaram melhores em leitura. O Claude Opus 4 pode ingerir centenas de arquivos em uma sessão e raciocinar sobre eles de forma coerente. O gargalo passou de “qualidade da recuperação” para “o que o humano realmente precisa.”

Uma vez que essas três coisas eram verdadeiras, o RAG começou a parecer uma solução alternativa para limitações que não existem mais.

Como É o Padrão Wiki em Markdown

A configuração de Karpathy, simplificada:

  1. Pasta raw. Toda página web que quer guardar é salva como arquivo .md em um diretório raw/. Ele usa o Obsidian Web Clipper para isso.
  2. Passo de compilação. Periodicamente, um agente LLM (Claude Code no caso dele) lê tudo em raw/, gera páginas de conceitos, escreve resumos e cria backlinks. Isso produz um wiki estruturado sobre o material bruto.
  3. Loop de query. Quando tem uma pergunta, ele consulta o LLM. Este busca no wiki, abre os arquivos relevantes e responde usando o conteúdo.
  4. Passo de lint. Ocasionalmente o LLM varre o wiki em busca de inconsistências, dados faltantes ou novas conexões que valha registrar.

Seu wiki de pesquisa atual tem ~100 artigos e ~400K palavras. Ele faz perguntas complexas e recebe respostas com fontes.

Nenhum banco de dados vetorial. Nenhum modelo de embedding. Nenhuma estratégia de chunking. Nenhum ranking de recuperação. Apenas arquivos markdown, uma estrutura de pastas e um LLM que pode lê-los.

Por Que Funciona Melhor que o RAG (Para Isso)

O padrão wiki tem vantagens estruturais que o RAG não consegue igualar sem se tornar um wiki.

Proveniência é gratuita. Toda resposta cita um arquivo. Você pode abri-lo, lê-lo, editá-lo, deletá-lo. Sem “o embedding disse isso.”

Edição é trivial. Um arquivo markdown é texto. Abra em qualquer editor. Corrija um erro de digitação. Adicione uma nota. Delete uma seção. A próxima query reflete a mudança imediatamente. Não há etapa de re-embedding.

Estrutura se acumula. Quando o LLM compila o wiki, ele constrói backlinks e páginas de conceitos. O wiki fica melhor quanto mais você salva, porque o LLM tem mais contexto para conectar novas entradas. Um índice vetorial apenas fica maior.

Portabilidade é total. Uma pasta de arquivos .md funciona no Obsidian, VS Code, GitHub, Logseq, vim ou cat. Um banco de dados vetorial é uma caixa preta que você precisa de um runtime específico para ler.

Você pode lê-lo. Parece óbvio, mas é a maior vantagem. Às vezes você vai querer saber o que está na sua base de conhecimento. Com RAG, isso é uma query de relatório. Com markdown, é ls.

O trade-off honesto: o RAG ainda vence quando você tem milhões de documentos, acesso multi-tenant ou restrições rígidas de latência (pense em chatbots de suporte ao cliente sobre um corpus de milhões de artigos de ajuda). Para conhecimento pessoal — sua leitura, sua pesquisa, seu domínio — o padrão wiki agora é estritamente melhor.

A Peça Faltante: Ingestão

O padrão de Karpathy tem uma suposição silenciosa: que colocar markdown limpo na pasta raw/ é fácil. Para desenvolvedores que já usam o Obsidian Web Clipper, de certa forma é. Para todo mundo, esta é a etapa onde o workflow morre.

O Web Clipper pode ter dificuldades com páginas com paywall, sites com muito JavaScript, conteúdo de vídeo, threads do X e qualquer coisa dinâmica. As pessoas salvam HTML bagunçado, desistem e concluem que “a coisa do wiki não é para mim.”

A extensão Save existe especificamente para resolver essa etapa. Ela usa Gemini para extrair conteúdo limpo de páginas arbitrárias, incluindo:

  • Artigos atrás de paywalls aos quais você tem acesso
  • Vídeos do YouTube (transcrição completa + resumo de IA)
  • Threads do X/Twitter
  • Reels do Instagram e legendas do TikTok (transcritos)
  • Discussões do Reddit
  • Documentação com blocos de código intactos
  • SPAs dinâmicas que clippers tradicionais não conseguem processar

Um clique. Markdown limpo do outro lado. Coloque na pasta.

A Outra Peça Faltante: A Configuração do MCP

O padrão de Karpathy também assume que você pode configurar um servidor MCP. Para usuários do Claude Code, isso é um cd de uma linha. Para todos usando o Claude Desktop, significa editar um arquivo de configuração JSON e reiniciar o app — e acertar o caminho, e lembrar de refazer quando você mover as pastas.

O Save Vault condensa ambas as peças faltantes em um único app:

  • A extensão Save alimenta markdown limpo no Save Vault automaticamente
  • O Save Vault escreve em ~/Documents/Save Vault/ organizado em bases de conhecimento (subpastas)
  • Um servidor MCP integrado expõe list_knowledge_bases, list_files, read_file e search ao Claude
  • O toggle “Connect to Claude” na barra de menu conecta o servidor MCP ao Claude Desktop e Claude Code, sem editar JSON

O resultado é o padrão Karpathy com as arestas ásperas lixadas. Salve uma página → ela chega no seu vault → Claude pode responder perguntas sobre ela. Sem banco de dados vetorial, sem chunking, sem embeddings.

Como Parece na Prática

Imagine que você está pesquisando um concorrente.

Dia 1. Você salva a página de preços deles, três posts de blog e um thread do Hacker News sobre o round seed deles. Cinco arquivos na sua KB Concorrentes.

Dia 5. Você pergunta ao Claude: “Que mudanças de preço essa empresa fez no último ano, e como os clientes reagiram?” O Claude busca na sua KB Concorrentes, lê os arquivos relevantes, cita a página de preços, traz à tona o sentimento do thread HN e responde — tudo com fontes.

Dia 30. Você tem 40 arquivos entre Concorrentes, Clientes e Pesquisa de IA. Você pede ao Claude para compilar cada KB em um wiki. Ele escreve páginas de conceitos, as vincula, sinaliza contradições. Você agora tem três wikis vivos que pode consultar como motores de busca, mas melhor — porque eles contêm apenas o que você curou.

Dia 90. Seus wikis são maiores que qualquer relatório de analista que você compraria, mais atuais que qualquer deck de consultor, e inteiramente seus. Toda afirmação é rastreada até um arquivo que você salvou.

É assim que uma base de conhecimento pessoal realmente se sente quando o atrito some. O RAG deveria entregar isso e não entregou. O padrão Karpathy entrega — uma vez que as peças de ingestão e MCP estejam conectadas para você.

Experimente

  1. Instale a extensão Chrome do Save
  2. Instale o Save Vault em savemarkdown.co
  3. Ative Connect to Claude na barra de menu
  4. Salve 10 coisas que você pretendia ler
  5. Abra o Claude e faça uma pergunta que as conecte

Esse é o workflow pós-RAG. Já está substituindo bancos de dados vetoriais para conhecimento pessoal. A única coisa que falta é começar a construir o seu.


O Save Vault é gratuito. A extensão Save é gratuita para 3 salvamentos por mês, $3,99/mês ilimitado. savemarkdown.co.