Finalmente parei para ler o gist do LLM Wiki do Karpathy (é, cheguei tarde no hype train XD).
E honestamente, a ideia toda se resume a algo bem simples: "RAG atualizável".
1. O problema
Quando LLMs trabalham com documentos, nada se acumula. A cada consulta – o modelo recupera chunks, sintetiza do zero, esquece. O conhecimento nunca se compila. E na minha opinião, o que importa ainda mais: quase nenhuma informação útil é extraída dos próprios diálogos.
RAG ajuda parcialmente (no sentido amplo – uma pasta de arquivos .md também é RAG), mas o pipeline padrão (que todo mundo usa) não tem atualização, destilação ou autolimpeza embutidas. O conhecimento chega ao índice uma vez e fica lá parado. Essa lacuna é exatamente o que o LLM Wiki fecha.
A inversão do Karpathy: entre as fontes brutas e você, existe um wiki em markdown que o agente escreve e mantém incrementalmente. Compila uma vez, mantém atualizado.
2. Arquitetura: 3 camadas
- raw/ – fontes, imutáveis. O agente não escreve aqui.
- wiki/ – o coração do sistema; páginas markdown (entidades, conceitos) que o LLM escreve e interliga automaticamente. Essencialmente, conhecimento em formato de grafo.
- CLAUDE.md – apenas o manual de como executar o LLM Wiki. Contém: formato de página, convenções de links, fluxo de ingestão, regras de lint. A coisa que transforma o Claude de um chatbot em um mantenedor disciplinado de wiki.
Suficiente para centenas de páginas sem ajuste adicional:
3. Operações
Três operações – você imediatamente quer desenhá-las como funções de API:
- Ingest -> add(source: file | list[file]). Solte uma fonte -> agente lê -> discute com você -> escreve resumo -> atualiza índice -> edita páginas de entidades relacionadas -> adiciona ao log. Uma fonte toca de 10 a 15 páginas.
- Query -> search(prompt: str). A operação mais importante. Responde sua pergunta + (A PARTE PRINCIPAL) arquiva automaticamente a síntese de volta no wiki como novas páginas. A exploração se acumula em vez de morrer no histórico do chat. Por baixo dos panos, é basicamente add(source=dialogue).
- Lint -> lint(). Sem argumentos. Periodicamente percorre o wiki: contradições, páginas órfãs, fatos desatualizados, referências cruzadas ausentes. Acionamento – a cada N mensagens do usuário ou um contador de linhas alteradas. Fácil de anexar ao /schedule.
Me lembra fortemente o Claude Dreaming – acho que o Dreaming é parcialmente inspirado nesse padrão (embora seu conjunto de funções seja um pouco diferente).
4. Indexação
Dois arquivos especiais tornam o wiki navegável:
- index.md – estado atual. Catálogo de cada página com uma descrição de uma linha. O agente o lê primeiro em qualquer consulta – é o contexto mínimo "o que tem neste wiki".
- log.md – registro de todos os eventos, formato livre. Linha do tempo somente adição. Se as linhas seguirem uma forma consistente (ex.: \
## [YYYY-MM-DD] ingest | título\), o log pode ser filtrado limpo com ferramentas unix simples – útil para auditoria.
index.md pode escalar ainda mais (índice vetorial, BM25, GraphDB...) – vou cobrir isso em um post separado.
5. Conclusões
Assim que eu enquadraria isso: não é uma escolha entre RAG e LLM Wiki – são dois pontos no mesmo eixo de "memória que se acumula".
RAG não precisa ser um banco de dados vetorial – uma pasta de arquivos markdown também é RAG.
Então você pode reformular LLM Wiki como RAG com três coisas acopladas:
- Uma camada de sumarização.
- Criação (quase) livre da estrutura nesse nível de resumo.
- Auditoria estrutural periódica + autoaprimoramento (CRON).
