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 de origem 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 de origem novamente para cada pergunta.
As pessoas chamam esses sistemas de wikis de agentes. Este artigo explica o que são. Ele mostra o que cada equipe construiu. Ele fala sobre os limites do método. Ele também destaca 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. Você divide os documentos em partes. Você cria embeddings para as partes. Para cada pergunta, o sistema encontra as partes relacionadas.
Esse método funciona. Mas 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. Ele altera as páginas relacionadas. Ele corrige os resumos. Ele marca as informações que contradizem as páginas.
Ambos os métodos estão corretos. Eles são diferentes em dois aspectos. 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 de origem. Estes são seus artigos, trabalhos e repositórios. O modelo os lê. O modelo não os altera.
A Camada 2 é o wiki. O wiki é em 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. Este arquivo informa ao modelo a estrutura do wiki. Ele também diz ao modelo quais tarefas realizar. O arquivo usual é CLAUDE.md ou AGENTS.md. Este arquivo faz do 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. Ele encontra informações que se contradizem. Ele encontra informações muito antigas. Ele encontra páginas sem links.
Por que funciona:
Wikis humanos tornam-se 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. Você deve manter os resumos corretos. Você 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 problemas. O modelo não fica entediado. O modelo não esquece um link. O modelo pode alterar quinze arquivos em uma única 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 do que os resumos dele.
Ele escreve o seguinte 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 rederivado a cada consulta." O resultado é "um artefato persistente e que se acumula."
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 é o IDE; o LLM é o programador; o wiki é o codebase."
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 você adicionar pesquisa. Ele dá o qmd como exemplo. O gist descreve o qmd como "um mecanismo de busca local para arquivos markdown com pesquisa híbrida BM25/vetorial e reclassificação por 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 for 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 uma 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 aquele código. O wiki tem um resumo da arquitetura, um índice de arquivos, um gráfico de dependências e pesquisa. 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 é a 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 é, portanto, a camada compilada abaixo da pesquisa de código no Devin (Devin Docs).
Factory: AutoWiki, documentação como um 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. Ela tem a estrutura do código. Ela 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 pacotes, a configuração de CI e os pontos de entrada. A Passagem 2 é uma varredura semântica. Ela lê as rotas, os endpoints da 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 fica com 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 pesquisa 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. Ela 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 open-source em escala pessoal
O GBrain aplica o método a um armazenamento de conhecimento pessoal, e não a uma base de código. GBrain usa markdown em um repositório git. Ele tem um arquivo de esquema. Ele faz um gráfico de links entre assuntos automaticamente.
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. Eles usam um arquivo de esquema. Eles compilam na ingestão. Eles recriam o wiki quando as fontes mudam. Eles 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 são diferentes na manutenção. A Factory faz a manutenção no 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 é correto para aproximadamente 100 fontes. Para mais páginas, você deve adicionar um mecanismo de busca. O gist diz para você usar pesquisa BM25 e pesquisa vetorial juntas.
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 do 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. Você pode fazer páginas que ninguém lê. Você 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 nesta área ainda não são precisas.
Muitas pessoas chamam esses sistemas de memória. 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 se contradizem, remover informações muito antigas, manter a fonte de cada item e excluir dados sob solicitação.
Um wiki faz a primeira tarefa corretamente. Um wiki não faz a segunda tarefa. Seu wiki do Gmail diz ao agente o que está no seu Gmail. Não diz ao agente que você mudou uma decisão em uma conversa na terça-feira. Não diz 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 então se move com a pessoa entre sessões, aplicativos e agentes. Ela altera um fato na posição quando o fato muda. Ela 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 agentes 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 evidência forte.
Faça estas três coisas. Compile seus documentos em páginas quando o conjunto de documentos for estável e você o ler 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 agentes 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 o mem0 você mesmo a partir do nosso repositório github de código aberto
Referências
- Andrej Karpathy, LLM Wiki (GitHub Gist, Abril 2026)
- qmd: pesquisa híbrida local BM25/vetorial para markdown
- Cognition, DeepWiki: Documentação de IA para qualquer repositório
- Devin Docs, DeepWiki
- Factory, Apresentando o AutoWiki
- Documentação da Factory, Visão geral do AutoWiki
- langchain-ai/openwiki (GitHub)
- LangChain, Wiki Memory
- garrytan/gbrain (GitHub)
- Vannevar Bush, As We May Think (The Atlantic, 1945)
- Mem0
