Em abril de 2026, Andrej Karpathy escreveu um GitHub Gist. Nele, ele descreve um método. Ele chama o método de LLM Wiki.
Quatro equipes construíram a mesma coisa depois disso. A Cognition construiu o DeepWiki. A Factory construiu o AutoWiki. A LangChain lançou o OpenWiki. Garry Tan lançou o GBrain.
O método é o mesmo em todos os quatro sistemas. Um LLM lê seus documentos-fonte uma vez. Ele escreve as informações em páginas markdown. Ele mantém as páginas corretas quando as fontes mudam. O agente lê essas páginas. O agente não lê os documentos-fonte novamente para cada pergunta.
As pessoas chamam esses sistemas de wikis de agente. Este artigo explica o que são. Explica o que cada equipe construiu. Explica os limites do método. Também explica uma diferença importante que muitos ignoram.
A ideia: compilar na ingestão, não na consulta
O método usual para dar a um modelo um grande conjunto de documentos é a recuperação. Você coloca os documentos em um banco de dados. Divide os documentos em partes. Cria embeddings para as partes. Para cada pergunta, o sistema encontra as partes relacionadas.
Esse método funciona. Também tem um problema. O sistema não mantém os resultados. Ele constrói cada resposta a partir das partes brutas novamente. A décima resposta não é melhor que a primeira. Você paga o custo do trabalho dez vezes.
Um wiki de agente move esse custo. O modelo faz o trabalho uma vez, quando lê a fonte. Ele escreve os resultados em páginas. As páginas permanecem.
O modelo executa estas etapas quando uma nova fonte chega. Ele lê a fonte. Altera as páginas relacionadas. Corrige os resumos. Marca as informações que discordam das páginas.
Ambos os métodos estão corretos. Eles diferem em duas coisas. A primeira diferença é quando você paga o custo. A segunda diferença é o que permanece após a pergunta.
Cada sistema tem as mesmas três camadas.
A camada 1 são os documentos-fonte. Estes são seus artigos, artigos acadêmicos e repositórios. O modelo os lê. O modelo não os altera.
A camada 2 é o wiki. O wiki é markdown. O modelo escreve todo o wiki. O wiki contém resumos, páginas para cada assunto e links entre as páginas.
A camada 3 é o arquivo de esquema (schema file). Este arquivo informa ao modelo a estrutura do wiki. Também informa quais tarefas realizar. O arquivo usual é CLAUDE.md ou AGENTS.md. Este arquivo torna o modelo um mantenedor correto do wiki.
O sistema realiza três operações.
Ingestão: o modelo lê uma nova fonte. Em seguida, o modelo escreve os dados em cada página relacionada.
Consulta: você faz uma pergunta ao wiki. Você pode escrever uma boa resposta de volta no wiki como uma nova página.
Lint: o modelo examina o wiki. Encontra informações que discordam. Encontra informações muito antigas. Encontra páginas sem links.
Por que funciona:
Wikis humanos se tornam incorretos com o tempo. A causa é específica. A parte difícil não é ler as fontes. A parte difícil não é ter as ideias. A parte difícil é a manutenção.
A manutenção tem estas tarefas. Você deve corrigir os links entre as páginas. Deve manter os resumos corretos. Deve comparar cada novo documento com as páginas existentes.
Este trabalho não para. O trabalho não dá recompensa. Uma equipe ocupada para este trabalho primeiro. Então o wiki se torna incorreto. Então as pessoas não o usam.
Um modelo faz este trabalho sem problema. O modelo não fica entediado. O modelo não esquece um link. O modelo pode alterar quinze arquivos em uma operação.
A ideia é antiga. Vannevar Bush descreveu o Memex em 1945. O Memex é um armazenamento pessoal de documentos com links entre eles. Bush não tinha resposta para a manutenção. O modelo é a resposta.
De onde vem o nome
Leia o Gist do Karpathy diretamente. É mais preciso que os resumos dele.
Ele escreve isto sobre o método usual: "o LLM está redescobrindo conhecimento do zero em cada pergunta. Não há acúmulo."
O método dele é compilar a informação, e não recuperá-la. Então "o conhecimento é compilado uma vez e depois mantido atualizado, não redescoberto em cada consulta." O resultado é "um artefato persistente e composto."
Você não escreve o wiki. Ele escreve: "Você nunca (ou raramente) escreve o wiki você mesmo, o LLM escreve e mantém tudo." Ele usa o agente e o Obsidian juntos. Ele escreve: "Obsidian é a IDE; o LLM é o programador; o wiki é a base de código."
O Gist dá um limite de tamanho. Muitos resumos não incluem este limite. O método sem embeddings "funciona surpreendentemente bem em escala moderada (~100 fontes, ~centenas de páginas) e evita a necessidade de infraestrutura RAG baseada em embedding."
Para mais fontes, o Gist diz para adicionar pesquisa. Ele dá qmd como exemplo. O Gist descreve qmd como "um mecanismo de busca local para arquivos markdown com pesquisa híbrida BM25/vetorial e re-rank com LLM."
Portanto, a regra é sobre tamanho. A regra não é sobre substituição. Não use infraestrutura de recuperação quando o conjunto de fontes é pequeno. Adicione recuperação quando o conjunto de fontes se tornar grande.
O que os laboratórios realmente construíram
É aqui que o padrão deixa de ser uma ideia e se torna engenharia, e as diferenças entre as implementações são a parte útil.
Cognition: DeepWiki, o wiki como utilidade pública
A Cognition aplicou o método aos repositórios públicos no GitHub. Substitua github.com por deepwiki.com na URL de um repositório público. Você então obtém um wiki para essa base de código. O wiki tem um resumo da arquitetura, um índice de arquivos, um gráfico de dependências e busca. O wiki tem links para a fonte (Cognition).
Mais de 50.000 dos maiores repositórios públicos têm um wiki. A lista inclui MCP e LangChain.
O segundo ponto é mais importante. O wiki não é o produto. O wiki é infraestrutura de recuperação para o agente. O Devin usa o wiki para encontrar o código relacionado em uma base de código. DeepWiki é assim a camada compilada abaixo da busca de código no Devin (Devin Docs).
Factory: AutoWiki, documentação como artefato de build
A Factory aplicou o método à integração contínua. A Factory escreve que a documentação deve ser um artefato de build, e não um projeto separado. A documentação vem da fonte. Tem a estrutura da base de código. Muda quando o repositório muda (Factory).
O método para fazer o wiki tem duas passagens. A Passagem 1 é uma varredura estrutural. Ela lê o arquivo README, os manifestos de pacote, a configuração de CI e os pontos de entrada. A Passagem 2 é uma varredura semântica. Ela lê as rotas, os endpoints de API, as classes de serviço, os esquemas de banco de dados e as flags de funcionalidade.
A Factory divide o trabalho entre agentes especializados. Cada agente recebe uma parte do repositório. Cada agente recebe contexto suficiente para escrever uma boa página. Este método previne um problema conhecido: um único agente sozinho escreve documentação pobre para um repositório grande.
A Factory mantém o wiki correto com infraestrutura, e não com disciplina. O comando /wiki recria o wiki. O comando /install-wiki escreve um workflow de CI. Este workflow recria o wiki a cada push para o branch padrão. Para GitHub, o wiki vai para a aba wiki do repositório (Factory Docs).
LangChain: OpenWiki, e o salto do código para tudo
A LangChain lançou o OpenWiki como software de código aberto. OpenWiki é uma ferramenta CLI. Ela escreve e mantém documentação de agente para uma base de código. A LangChain então lançou o OpenWiki Brains, que tem dois modos. Code Brain é o primeiro modo, para um repositório. Personal Brain é o segundo modo, para suas próprias fontes (LangChain).
Personal Brain é a mudança importante. Ele lê dados do Gmail, Notion, repositórios git, X, Hacker News e busca na web. Ele escreve todos esses dados em um wiki markdown local. O agente lê este wiki. O método mudou de documentação de um repositório para documentação do seu trabalho.
Cada equipe tomou a mesma decisão sobre a saída. A saída não é texto para uma pessoa ler. A saída é markdown estruturado para contexto de LLM. Tem cabeçalhos, links entre páginas e resumos. A estrutura permite que um agente encontre a informação relacionada rapidamente. O leitor do wiki é um modelo.
GBrain: a versão de código aberto em escala pessoal
O GBrain aplica o método a um armazenamento de conhecimento pessoal, e não a uma base de código. O GBrain usa markdown em um repositório git. Tem um arquivo de esquema. Faz automaticamente um gráfico de links entre assuntos.
O GBrain mostra que o método precisa de muito pouca infraestrutura. Não tem banco de dados vetorial. Não tem serviço. Tem arquivos. Um modelo mantém os arquivos. Uma pessoa pode ler os arquivos.
A matriz de técnicas
Os quatro sistemas têm a mesma estrutura. Eles usam markdown em git. Usam um arquivo de esquema. Compilam na ingestão. Recriam o wiki quando as fontes mudam. Escrevem as páginas para um agente ler. Quatro equipes resolveram quatro problemas diferentes e fizeram a mesma estrutura. Este acordo é uma boa evidência de que a estrutura está correta.
Os sistemas diferem na manutenção. A Factory faz a manutenção em CI. Os outros três sistemas fazem a manutenção quando uma pessoa executa um comando. Seus wikis são, portanto, tão corretos quanto o último comando.
Onde para
Limite 1 é o tamanho. Karpathy dá este limite. O método sem embeddings está correto para aproximadamente 100 fontes. Para mais páginas, você deve adicionar um mecanismo de busca. O Gist diz para usar busca BM25 e busca vetorial juntos.
Limite 2 é a precisão. O modelo compila a informação na ingestão. Um resumo inicial pode remover um detalhe da fonte. Cada resposta posterior tem este erro. A recuperação das partes brutas não tem este problema. Você troca o custo do trabalho repetido pelo risco de perda de dados.
Limite 3 é informação desatualizada. Uma página é tão correta quanto a última atualização. Esta é a razão pela qual o método da Factory é importante. Um wiki incorreto é pior que nenhum wiki. A informação incorreta tem o formato de informação correta.
Limite 4 é o custo. Você paga tokens para fazer páginas. Pode fazer páginas que ninguém lê. Também paga tokens para fazer lint de páginas que não mudaram.
Um wiki não é memória
Há uma diferença que você precisa saber. As palavras neste campo ainda não são precisas.
Muitas pessoas chamam esses sistemas de memória. A LangChain chama o OpenWiki de camada de memória wiki para agentes de IA. Outras pessoas dizem que um wiki dá memória a um agente. A palavra memória tem dois significados diferentes aqui.
O primeiro significado é conhecimento de um conjunto de documentos. Um wiki faz isso. Ele compila os dados em seus documentos, seu repositório ou seu Gmail. Ele informa o que os documentos contêm.
O segundo significado é memória de um usuário. Este é um dado diferente. Inclui as preferências de uma pessoa. Inclui as decisões de uma pessoa. Inclui os métodos que uma equipe rejeitou. Inclui o resultado quando um agente tentou um método em um aplicativo diferente.
Memória de um usuário tem uma estrutura diferente. Está relacionada a uma pessoa, e não a um conjunto de documentos. Vem da interação, e não da ingestão. Também deve fazer estas tarefas para cada usuário: corrigir informações que discordam, remover informações muito antigas, manter a fonte de cada item e excluir dados sob demanda.
Um wiki faz a primeira tarefa corretamente. Um wiki não faz a segunda tarefa. Seu wiki do Gmail informa ao agente o que está no seu Gmail. Não informa ao agente que você mudou uma decisão em uma conversa na terça-feira. Não informa ao agente que um método já falhou para você.
Uma camada de memória faz a segunda tarefa. Mem0 é um exemplo. Ela mantém cada memória com um user_id. A memória assim se move com a pessoa entre sessões, aplicativos e agentes. Muda um fato em posição quando o fato muda. Não adiciona um novo registro cada vez.
Os dois sistemas não são alternativas. Use ambos. O erro não é usar um wiki. O erro é pensar que um wiki lhe dá memória de um usuário.
Resumo
A ideia em wikis de agente está correta. Compile o conhecimento uma vez. Depois mantenha-o correto. Não o construa novamente para cada pergunta. A manutenção parou wikis humanos, e um modelo faz a manutenção sem custo. Quatro equipes construíram a mesma estrutura em alguns meses. Esta é uma forte evidência.
Faça estas três coisas. Compile seus documentos em páginas quando o conjunto de documentos é estável e você o lê com frequência. Adicione recuperação quando o conjunto de documentos se tornar grande, como o Gist diz. Mantenha a diferença entre conhecimento de um conjunto de documentos e memória de um usuário. Um wiki lhe dá o primeiro. Um wiki não lhe dá o segundo.
In Context #17
Este blog faz parte do In Context, uma série de blogs do @mem0ai cobrindo memória de agente de IA e engenharia de contexto.
Mem0 é uma camada de memória inteligente e de código aberto projetada para LLMs e agentes de IA fornecer interações personalizadas, de longo prazo e conscientes do contexto entre sessões.
- Obtenha sua chave de API gratuita aqui: app.mem0.ai
- ou hospede mem0 você mesmo a partir do nosso repositório de código aberto no GitHub
Referências
- Andrej Karpathy, LLM Wiki (GitHub Gist, abril de 2026)
- qmd: busca híbrida local BM25/vetorial para markdown
- Cognition, DeepWiki: documentação de IA para qualquer repositório
- Devin Docs, DeepWiki
- Factory, Apresentando AutoWiki
- Documentação da Factory, Visão geral do AutoWiki
- langchain-ai/openwiki (GitHub)
- LangChain, Memória Wiki
- garrytan/gbrain (GitHub)
- Vannevar Bush, As We May Think (The Atlantic, 1945)
- Mem0
