RAG É a Arquitetura Errada Pro Seu Segundo Cérebro

Humanos desistem de wikis porque manutenção cresce mais rápido que valor.

LLMs não desistem. E essa é a única diferença que importa.

É exatamente essa assimetria — simples, quase banal — que acabou de redesenhar a arquitetura de segundo cérebro que o Vale do Silício estava prestes a empilhar em cima do RAG.

1. O Pattern Que Viralizou — E a Tese Que Ele Carrega

No começo de abril, Andrej Karpathy publicou um gist chamado llm-wiki. Cinquenta linhas de markdown descrevendo como ele constrói a própria knowledge base pessoal.

Não tem Python. Não tem embedding. Não tem vector database.

Tem três pastas — raw/, wiki/, outputs/ — e um CLAUDE.md que ensina o agente a compilar verdade a partir de fontes brutas, manter uma timeline append-only, e revisar o índice todo mês. O humano curadoria. O LLM faz o resto.

O tweet original acumulou 17 milhões de views. O gist passou dos cinco mil estrelas em 48 horas e acumulou mais de 4 mil forks nas semanas seguintes — número que continua subindo. A VentureBeat chamou de "a arquitetura que bypassa RAG".

A tese embutida em 50 linhas de markdown é afiada e pouco dita em voz alta: o gargalo dos segundos cérebros nunca foi retrieval. Foi composição.

Durante vinte anos a promessa do PKM foi a mesma — humano organiza, máquina busca. É o que matou o Roam. É o que matou a maioria dos zettelkasten em Obsidian. A gente nunca desistiu desses sistemas porque a busca era ruim. Desistiu porque adicionar uma fonte nova dá mais trabalho do que o valor que ela gera.

Karpathy inverte a divisão em uma frase:

O que o pattern resolve não é encontrar — é compor. Quando você joga um clipping em raw/, o agente toca dez a quinze páginas do wiki: atualiza o link em context-rot.md, adiciona uma linha em memory-vs-retrieval.md, cria mempalace.md do zero, escreve uma entrada no log.md. Cada fonte compõe com todas as outras, automaticamente, sem humano no loop.

Ninguém vai passar 45 minutos por dia conectando páginas à mão. O agente passa. Por isso funciona.

2. A Evidência Que Enterra o RAG Pessoal

Tem um motivo técnico além da ergonomia pra esse movimento. Duas descobertas recentes enterraram a premissa em que o RAG pessoal se apoia — a ideia de que mais contexto relevante = melhor resposta.

A primeira é o Context Rot, publicado pela Chroma Research em julho de 2025. Eles rodaram 18 modelos frontier — GPT-4.1, Claude 4, Gemini 2.5, Qwen3 — e mediram degradação de acurácia conforme o input crescia. Inclusive em tarefas triviais, tipo replicar texto. Inclusive bem antes do context window encher. A conclusão dos autores é seca:

Não é volume. É apresentação.

A segunda é um paper de 2023 que envelheceu de um jeito constrangedor pra quem empilhou embedding em cima de embedding.

Em Lost in the Middle, Nelson Liu e colegas do Stanford mostraram que mover o documento-resposta da posição 1 pra posição 10 num contexto de 20 documentos derruba a acurácia em mais de 30%.

Em key-value retrieval, alguns modelos caem de quase perfeitos nas extremidades pra menos de 40% no meio. Efeito replicado em GPT-3.5, GPT-4, Claude, LLaMA-2. Não é bug de modelo — é geometria de atenção.

Junta as duas e o que sobra é desconfortável: jogar chunks recuperados por similaridade no prompt é a arquitetura que os papers pedem pra ninguém fazer. Você está pagando embedding, infraestrutura e latência pra produzir exatamente o tipo de input que derruba os modelos.

Garry Tan, CEO da Y Combinator, materializou esse mesmo padrão em abril com o GBrain — open-source, três camadas, pensado pra escala de 10 mil arquivos markdown:

• Storage é markdown — compiled truth, versionada em git, auditável

• Index é Postgres + pgvector — ajuda a achar, não segura verdade

• Agência é o LLM — a camada que nunca cansa de compor, rodando dream cycles que enriquecem o grafo enquanto o humano dorme

RAG coloca agência no index (busca semântica decidindo o que entra no prompt).

O pattern wiki coloca agência no LLM (o agente decide o que atualizar, ligar, consolidar).

No nicho pessoal, a segunda topologia ganha — e os papers explicam por quê.

3. Como Montar o Seu Numa Tarde

O começo é desconfortavelmente simples — porque você passou anos acreditando que ia precisar de embedding store, pipeline e infra só pra ter um segundo cérebro decente. Não vai.

Estrutura de pastas. Três diretórios:

• raw/ — clippings crus, PDFs, transcrições, tweets

• wiki/ — a verdade compilada (markdown com YAML frontmatter e wiki-links)

• outputs/ — artifacts gerados: briefs, decks, essays

Mais um log.md append-only na raiz — cada ingest vira uma linha. Essa é a timeline.

Um CLAUDE.md que ensina três workflows ao agente:

• INGEST — recebe uma fonte em raw/ e atualiza dez a quinze páginas do wiki

• QUERY — responde uma pergunta usando o wiki como contexto primário

• LINT — roda mensalmente: detecta contradições, links quebrados, páginas órfãs

Os três prompts cabem numa página. O CLAUDE.md é a sua engenharia de contexto. É isso.

Os sinais de que tá funcionando. Uma fonte tocando pouca coisa é sinal ruim — o agente não tá compondo, tá só arquivando.

Uma fonte tocando dez a quinze páginas é saúde. O index.md começa a estabilizar depois de trinta ou quarenta fontes.

O log.md cresce linearmente. Quando você faz uma pergunta, a resposta cita páginas que você não lembrava que existiam. Esse é o momento em que o sistema vira útil.

O custo real, sem romantizar. Um guia prático do pattern abre a conta: uma fonte que toca dez a quinze páginas custa entre dois e cinco dólares em tokens de frontier model. Cinquenta fontes somam cem a duzentos e cinquenta dólares de ingest. "Mais barato que um research assistant. Não é de graça."

Pra calibrar a escala em dois polos do pattern:

• Karpathy relata ter compilado perto de 400 mil palavras num único tópico de pesquisa sem escrever uma linha do wiki ele mesmo — três pastas e um markdown de instruções, o humano só curando e perguntando.

• O GBrain do Garry Tan opera com 10 mil+ arquivos markdown, 3 mil+ páginas de pessoas, 280+ transcrições de reunião, 13 anos de calendário, 20+ cron jobs rodando dream cycles contínuos de enriquecimento.

O mesmo pattern, duas escalas. Funciona porque a arquitetura é flat — o único gargalo é quanto orçamento de token você tem.

4. As Ressalvas Honestas

Rodamos uma variação do pattern há meses: Inbox/ como raw para clippings e brain dumps, Areas/, Resources/ e Projects/ como wiki compilada organizada em P.A.R.A., um CLAUDE.md por área como engenharia de contexto local, e um GBrain paralelo pra brain bruto que ainda não virou conhecimento curado.

O fluxo segue exatamente o que os três movimentos desta edição descrevem — raw → compiled → output — e é essa experiência operada que permite dizer três coisas que o pattern não resolve:

⚠ Error compounding é risco real. Se o modelo escreve uma página com um erro sutil e você realimenta outputs pro wiki, dois meses depois cinco páginas reforçam o mesmo erro.

Lint mensal ajuda. Verificação humana em claims de alto risco é inegociável. Não confie no wiki cego em decisão importante — ele é rascunho afinado, não fonte primária.

⚠ Não escala pra enterprise search. Abaixo de umas poucas centenas de milhares de palavras, wiki ganha. Acima de dezenas de milhares de documentos, o índice não cabe mais no contexto e aí o RAG (ou híbrido) volta a ser necessário.

Essa edição é sobre o seu segundo cérebro — não sobre o produto de enterprise search do seu cliente.

⚠ Single-model blind spots existem. Todo o wiki é a interpretação de um modelo sobre as suas fontes. A mitigação séria é rodar queries críticas em múltiplos modelos e comparar convergência. Custa mais. É honesto citar.

RAG não morreu. Só não é a arquitetura certa pro seu repo pessoal.

Sua missão para os próximos 7 dias

1. Crie o repo hoje — não na sexta. Três pastas (raw/, wiki/, outputs/), um log.md vazio, um CLAUDE.md com um workflow INGEST de uma página. Ingere uma única fonte que você genuinamente quer processar e conta quantas páginas o agente tocou. Se for menos que cinco, o problema é o prompt, não o pattern.

2. Marca o lint pra dez dias depois. É aí que você vai descobrir se o sistema aguenta composição repetida ou se tá virando hall de espelhos. Não pula essa checagem. É a diferença entre segundo cérebro que compõe e segundo cérebro que propaga erro.

Conteúdos Recomendados

• Gist: Karpathy — llm-wiki — Cinquenta linhas de markdown que valem mais que a maioria dos white papers sobre PKM.

• Pesquisa: Context Rot — Chroma Research — A evidência empírica em 18 modelos de que "jogar tudo no contexto" é contraproducente. Leitura obrigatória pra quem constrói agentes.

• Paper: Lost in the Middle — Liu et al. (arXiv 2307.03172) — O paper de 2023 que previu o problema e foi ignorado pelo boom RAG. Envelheceu muito bem.

• Implementação: Rowboat — local-first AI coworker with memory — Não é wiki puro. É o próximo passo: knowledge graph sobre vault Obsidian-compatível que produz artefatos. Mostra pra onde o pattern tá indo.

Forte abraço,

Equipe Olympus