Karpathy matou a wiki humana e ressuscitou Vannevar Bush

Em novembro de 2024, Andrej Karpathy publicou um gist de 1.200 palavras sem uma linha de código, batizado de LLM Wiki. O texto propõe um padrão de três camadas e três operações que resolve duas dores simultâneas: a wiki corporativa que morre por falta de curadoria e o RAG amnésico que reprocessa tudo a cada query. Em seis meses surgiram quarenta implementações públicas.

O motivo do interesse não é técnico. É arquitetônico.

Karpathy nomeou um problema que todo executivo conhece e nenhum havia conseguido resolver. A wiki corporativa morre. O RAG esquece. As duas dores convivem dentro da mesma empresa, alimentadas pelo mesmo conteúdo, e ninguém une os pedaços.

O McKinsey Global Institute, no estudo The Social Economy publicado em julho de 2012, calculou que profissionais do conhecimento gastam aproximadamente 19% do tempo de trabalho semanal apenas procurando e juntando informação. Quase um dia por semana evaporando em arqueologia interna. Em 2026, com cada conversa de equipe rodando em LLM, o número não caiu. Mudou de lugar.

Este artigo explica por que Vannevar Bush, em 1945, já havia descrito o requisito, e por que o padrão de Karpathy é a primeira resposta viável oitenta anos depois.

RAG amnésico e wiki humana que evapora são dois problemas conhecidos sem solução única. O RAG de Patrick Lewis — publicado em NeurIPS 2020 (arXiv:2005.11401) — recupera e responde, mas descarta o trabalho a cada query. A wiki acumula na largada, mas morre por falta de curadoria. A LLM Wiki de Karpathy é a primeira arquitetura que resolve as duas dores ao mesmo tempo: acumula como wiki, recupera como RAG e reescreve como agente.

O problema do RAG não é a recuperação. É a memória. Cada query é amnésica. A boa resposta construída na primeira tentativa some no log. O próximo usuário começa do zero. Para um corpus técnico com duzentas fontes que se cruzam, a empresa paga inferência infinita para reconstruir o mesmo conhecimento.

A wiki humana tem o problema simétrico. Acumula bem na largada, evapora no médio prazo. Alguém precisa abrir a página, ler, conferir se ainda é verdade, reescrever, aprovar. Esse alguém tem outras prioridades. A wiki vira camada arqueológica em menos de um ano em quase toda empresa que cruza mil colaboradores.

O custo que matou a wiki humana vai a zero quando o bibliotecário é uma máquina paciente. Esse é o ponto que Karpathy identificou e ninguém havia formulado com tanta clareza.

Karpathy não está propondo uma ferramenta. Está propondo um padrão de pasta: três camadas de arquivos, três operações canônicas, dois arquivos especiais com função estrutural. O resto é commodity.

Vannevar Bush descreveu em 1945, no ensaio As We May Think (The Atlantic), a máquina hipotética que chamou de Memex. O Memex permitiria ligar documentos por associative trails, trilhas associativas permanentes e compartilháveis. Toda a estrutura do hipertexto, da Wikipédia e do Obsidian estava ali descrita em prosa, antes do primeiro computador eletrônico comercial existir. O que faltava era o bibliotecário.

O Memex nunca virou produto. A razão técnica é que microfilme não chegou perto. A razão profunda é que alguém precisava manter as trilhas: ler o documento novo, decidir onde ele se conecta com o que já existe, criar o link, atualizar a entrada anterior. Bush imaginou que o pesquisador faria isso por si mesmo. Não fez. Ninguém faz. O custo de curadoria sempre comeu a promessa.

Bush registrou no ensaio a ambição sem rodeio: "O instrumento, se desenvolvido adequadamente, dará ao seu usuário acesso e comando sobre a memória herdada da raça humana." A obstrução era igualmente clara: a curadoria é cara demais para qualquer pesquisador humano sustentar sozinho.

Um modelo de linguagem grande, em 2024, é a primeira entidade barata o suficiente para topar ser o bibliotecário. Não porque é mais inteligente que o pesquisador. Porque é paciente. Não cansa, não esquece de atualizar, não tem outra prioridade na semana que vem.

Vannevar Bush escreveu o requisito em 1945. Faltava encontrar quem topasse ser o bibliotecário. Oitenta anos depois, a vaga foi preenchida.

A arquitetura da LLM Wiki cabe em uma pasta de Git com três camadas, três operações e dois arquivos especiais. A deliberada simplicidade é o ponto: qualquer time consegue implementar sem dependência de infraestrutura externa, e a estrutura é auditável por humanos e por agentes na mesma leitura.

Camada raw — documentos brutos, imutáveis, com metadados de proveniência. PDFs, transcrições, e-mails, capturas de página. Nada é editado depois de entrar. Quem alimenta a camada raw assina e data.

Wiki sintético — a camada intermediária. Arquivos Markdown reescritos por um modelo de linguagem a partir das fontes raw. Cada página tem links de saída para outras páginas e referências para os documentos raw que a originaram. É aqui que mora a densidade citável e de onde o leitor humano vai ler.

Schema — a camada superior, materializada em um arquivo CLAUDE.md ou equivalente. O schema descreve como o sistema deve operar sobre as outras duas camadas: o que é uma boa entrada na wiki, como decidir se um documento raw merece virar página, quando atualizar versus criar nova entrada, e o tom de voz do wiki sintético.

Sobre essas três camadas rodam três operações. Ingest recebe um documento novo, decide se ele entra no raw e qual página do wiki sintético precisa ser criada ou atualizada. Query responde uma pergunta lendo prioritariamente o wiki sintético e descendo para o raw quando o wiki não basta. Lint roda periodicamente verificando consistência, links quebrados, contradições entre páginas e datas desatualizadas.

Dois arquivos especiais carregam o peso estrutural. index.md é content-oriented — não meramente um sumário. Reescrito a cada ingest relevante, descreve o estado atual do conhecimento com links para os pontos vivos. log.md é append-only, cronológico, e registra cada ingest e cada decisão de lint. Auditoria pura.

A diferença entre a LLM Wiki, o RAG clássico e a wiki humana fica clara na tabela abaixo.

A LLM Wiki não é uma versão melhor das duas anteriores. É uma categoria diferente. GraphRAG, publicado pela Microsoft em 2024 (arXiv:2404.16130), e MemGPT de Packer et al. 2023 (arXiv:2310.08560), são complementares, não substitutos. Cada um resolve um pedaço do problema. A LLM Wiki organiza o pedaço da síntese persistente.

Em RAG clássico, query é consumo. Em LLM Wiki, query é produção. Toda resposta que valeu a pena gerar deveria virar uma página nova ou um patch em página existente. Essa inversão é o mecanismo central que diferencia as duas arquiteturas: na LLM Wiki, o ato de perguntar deixa a base mais inteligente.

RAG não acumula. Wiki humana evapora. A LLM Wiki é a única arquitetura em que o ato de perguntar deixa a base mais inteligente.

Pranjal Aggarwal e colegas de Princeton publicaram em KDD 2024 (arXiv:2311.09735) o primeiro estudo controlado sobre o que aumenta a probabilidade de uma página ser citada por um modelo generativo. As táticas mais eficazes foram de densificação canônica:

• Citação de fontes autoritativas elevou visibilidade em 115%.
• Inclusão de estatísticas datadas elevou em 41%.
• Citações diretas atribuídas elevaram em 28%.

Os números estão na Tabela 3 do paper. Essas táticas não descrevem técnicas de copy. Descrevem páginas de wiki bem mantidas. Uma página com fonte explícita, número datado e quote atribuída é exatamente o que sai de uma operação de wiki sintético rodando sobre raw bem curado.

O projeto AutoGEO de Wu, Zhong, Kim e Xiong na CMU, com código aberto público, automatizou o playbook de Princeton e reportou lift agregado de 50,99% em visibilidade em LLMs comerciais. A literatura está convergindo: o conteúdo que LLM gosta de citar é o conteúdo que LLM Wiki produz por padrão.

A wiki canônica é dupla infraestrutura. Serve o time por dentro e serve o algoritmo por fora. Quem entendeu isso para de discutir SEO versus GEO e começa a discutir governança de conhecimento.

A LLM Wiki é a primeira arquitetura de conhecimento em que a operação interna e o posicionamento externo se alimentam do mesmo ativo. Os casos onde a alavanca é imediata já estão mapeados — e os quatro abaixo cobrem a maior parte das operações de conhecimento em empresas de médio e grande porte.

Time de marketing B2B que reconstrói briefing a cada campanha. Toda quinta-feira, alguém abre um Google Doc em branco e refaz o trabalho de definir ICP, dor, mensagem, prova social. Com LLM Wiki, o index.md descreve o ICP canônico, com link para a página de cada segmento e o raw das entrevistas de cliente que sustentam a definição. A query de quinta-feira lê o wiki, devolve o briefing pronto e arquiva como anexo da campanha. A próxima campanha começa do conhecimento acumulado, não da memória do redator de plantão.

Conselho consultivo recebendo deck novo a cada reunião. Substitua por memo Decision Day com log.md cronológico. Cada conselheiro chega na próxima sessão tendo lido o que mudou desde a última, com a auditoria de cada decisão registrada em append-only. O CEO para de explicar o passado e começa a debater o futuro. O ciclo de reunião encurta.

Due diligence de empresa investida ou alvo. A pasta típica de operação é um cemitério de PDFs com nomes longos e seis versões. Com LLM Wiki, o raw é imutável com proveniência, o wiki sintético é cross-linkado e o lint quinzenal detecta contradição entre laudo financeiro e narrativa do CEO. O time de M&A para de procurar informação e começa a interpretar inconsistência.

Wiki canônica como infraestrutura de visibilidade em LLM. Para quem opera marca em mercado onde modelo generativo intermedia descoberta, a base interna bem mantida é o ativo que vira citação externa. Métricas como citation rate e mention rate, rastreadas por ferramentas como Profound — que divulgou em maio de 2026 ter monitorado vinte e sete milhões de citações em LLM, com apenas 4,3% delas captadas por marcas que tratam o conteúdo como ativo proprietário — correlacionam diretamente com a densidade da base de origem.

Quem tratar operação interna e posicionamento externo como dois projetos separados vai pagar duas vezes pelo mesmo trabalho.

O padrão é grande, a entrada é pequena. Três passos concretos cabem em uma semana de trabalho focado e constroem a base sobre a qual o resto da LLM Wiki se sustenta.

Primeiro, crie um index.md content-oriented no repositório de conhecimento da sua operação. Não um sumário. Uma página que descreve, em prosa densa, o estado atual do que importa, com links para os pontos vivos. Reescreva esse arquivo toda vez que algo material mudar.

Segundo, crie um log.md append-only e registre cada ingest pelos próximos trinta dias. Documento novo, decisão tomada, conversa relevante. Append, com data e autor. A disciplina de trinta dias é o que constrói o hábito que sustenta o resto.

Terceiro, formalize a operação de query. Defina o prompt canônico que lê o wiki, devolve a resposta e arquiva o resultado como página candidata para o próximo ingest. Query é a operação com maior alavanca rotineira e a mais fácil de demonstrar valor para o time.

O resto vem depois: lint, schema mais elaborado, integração com agentes. Esses são detalhes de implementação. A decisão estratégica é tratar conhecimento como infraestrutura versionada que o modelo de linguagem mantém, em vez de tratá-lo como produto secundário de outras atividades.

Karpathy publicou o gist em novembro de 2024. A janela de quem ainda pode ser pioneiro no padrão se fecha em 2026. Quem decide na segunda-feira passa na frente de quem decide em julho.

Uma versão editorial complementar deste artigo, com ênfase na democratização do bibliotecário pessoal para empresas brasileiras de qualquer porte, foi publicada na AI Brasil em 26 de maio de 2026, sob o título "LLM Wiki: o bibliotecário que sua empresa não conseguiu contratar acaba de ficar de graça". Mesma autoria, ângulo editorial diferente.