Finalmente peguei no gist do LLM Wiki do Karpathy (sim, cheguei atrasado pra festa XD).
E honestamente, a ideia toda se resume em algo bem simples: "RAG atualizável".
1. O problema
Quando LLMs trabalham com documentos, nada se acumula. A cada consulta - o modelo recupera pedaços, 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 no índice uma vez e depois 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 sozinho. 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 de wiki disciplinado.
Suficiente para centenas de páginas sem ajuste extra algum:
3. Operações
Três operações - você quer desenhá-las como funções de API imediatamente:
- Ingest -> add(fonte: arquivo | lista[arquivo]). Largue uma fonte -> agente lê -> discute com você -> escreve resumo -> atualiza índice -> edita páginas de entidades relacionadas -> adiciona ao log. Uma fonte toca 10-15 páginas.
- Query -> search(prompt: str). A operação mais importante. Responde sua pergunta + (A PARTE CHAVE) 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(fonte=diálogo).
- Lint -> lint(). Sem argumentos. Periodicamente varre o wiki: contradições, páginas órfãs, fatos desatualizados, referências cruzadas faltando. Gatilho - 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 linha de descrição. 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 de adição. Se as linhas seguirem uma forma consistente (ex.: \
## [AAAA-MM-DD] ingest | título\), o log é pesquisável com ferramentas unix simples - útil para auditoria.
O index.md pode escalar ainda mais (índice vetorial, BM25, GraphDB, ...) - vou cobrir isso em um post separado.
5. Conclusões
Aqui está como eu enquadraria: isso não é uma escolha entre RAG e LLM Wiki - são dois pontos no mesmo eixo de "memória cumulativa".
RAG não precisa ser um banco de dados vetorial - uma pasta de arquivos markdown também é RAG.
Então você pode reformular o LLM Wiki como um RAG com três coisas adicionadas:
- Uma camada de sumarização.
- Criação (quase) livre da estrutura nesse nível de resumo.
- Auditoria estrutural periódica + autoaperfeiçoamento (CRON).
