LLM Wiki na prática: o que eu apresentei no Pitch Tech da NTConsult

Reunião de refinamento. Alguém olha para o código, ou para o card, e pergunta: por que a gente decidiu isso?

Alguém responde que foi numa reunião em junho. Outra pessoa pergunta se alguém anotou. Ninguém anotou. Ou anotou num lugar que ninguém acha. A decisão vira opinião, e quem fala mais alto, ou está há mais tempo no time, decide de novo.

Isso aconteceu comigo tantas vezes que eu resolvi o problema para mim. Em 12 de novembro contei como no Pitch Tech da NTConsult, no horário de almoço, para o pessoal da empresa. A palestra foi gravada e vai para a intranet. Este artigo é a versão escrita, com os números conferidos.

Se você quer o histórico do método, ele está nos três artigos anteriores: Capturar notas é fácil. Destilar é a parte que dói, Mil páginas depois e Para que serve uma wiki mantida por LLM no dia a dia. Aqui eu conto o que mudou desde então e o que respondi para uma plateia que nunca tinha ouvido falar disso.

A noite de 7 de outubro

Comecei a palestra por um caso, não por ferramenta.

Em 7 de outubro, às 19h21, chegou um pedido fora do meu horário: um levantamento de tudo o que eu já tinha feito com IA no cliente nos últimos dez meses. Era para levar a uma reunião de diretoria. O prazo era 11h do dia seguinte.

A linha do tempo, medida no registro da sessão com o agente:

1. 19h21: o pedido chega.
2. 19h54: primeiro rascunho completo, com 5 tópicos e 3 mil caracteres. Foram 33 minutos.
3. 9h50 do dia seguinte: envio, 1h10 antes do prazo, depois de revisão e conferência.

Preciso ser rigoroso com o número. Os 33 minutos são do primeiro rascunho. A mensagem final tinha cerca de 11 mil caracteres e passou por conferência no Jira, no Confluence e no git. O tempo efetivo de trabalho eu não medi, então não vou dizer que a IA me deixou dez vezes mais rápido.

O que eu posso dizer: sem a wiki, eu teria respondido de memória, juntando nota solta. Com ela, o levantamento virou consulta e conferência, não reconstrução de memória.

O método foi simples:

1. Três leitores em paralelo. Um agente de leitura para a wiki, um para os repositórios e um para os registros de reunião.
2. Formato fixo. Cada um devolveu o que foi feito, quando, o número e a natureza dele (medido, relato de alguém ou plano), com arquivo e linha da fonte.
3. Regra de corte. Número sem fonte não entrava. Trabalho de colega entrava com o nome do colega.
4. Revisão antes de enviar. Pedi para outro modelo, o Codex, conferir o texto em modo só leitura. Ele ajustou dois números.

Quem respondeu ao pedido foi o acervo que eu vinha construindo havia meses, consultado com método. A IA fez o trabalho braçal de pesquisa.

O que é uma LLM Wiki

O padrão foi proposto por Andrej Karpathy num gist público. Ele deixou o desenho aberto de propósito, e cada pessoa monta a sua. A ideia cabe numa frase: em vez de pedir para a IA buscar e resumir tudo do zero a cada pergunta, você a deixa compilar o conhecimento uma vez, em páginas, e manter essas páginas vivas conforme chegam fontes novas.

A divisão do trabalho é o que faz funcionar:

• Eu escolho a fonte, discuto com o agente o que importa e aprovo antes de gravar.
• A IA lê a fonte inteira, escreve a página no formato combinado e cria os links para as pessoas, os sistemas e os conceitos que já existem.
• Tudo fica em markdown no git. Se amanhã eu trocar de modelo, de fornecedor ou de editor, o conhecimento continua ali, legível, com histórico.

Uso isso todo dia desde 20 de abril de 2026.

Uma comparação que sempre aparece é com o RAG. No RAG puro, a cada pergunta o sistema busca trechos e o modelo redescobre o assunto do zero. Nada se acumula, e a mesma pergunta amanhã refaz o mesmo trabalho. Na LLM Wiki, a fonte é lida uma vez e vira página. Quando chega uma fonte nova sobre o mesmo assunto, a página é reescrita e religada. O conhecimento cresce em vez de ser recalculado.

Ela também não tem banco vetorial, plataforma ou licença para comprar. É uma pasta com arquivos markdown e as skills do agente. Justamente por ser tão simples, dá para auditar: qualquer pessoa abre o arquivo e lê o que a IA escreveu, e o git mostra quando e por que uma nota mudou. Eu abro a minha pelo Obsidian.

O fluxo em quatro passos

1. raw/. A fonte bruta entra aqui: registro de reunião, nota que ditei no celular, PDF, print. Ninguém edita essa pasta, nem eu, nem a IA. Ela é a prova.
2. Leitura e discussão. Um agente lê a fonte inteira e traz de três a cinco pontos principais. Antes de gravar qualquer coisa, a gente conversa. Eu concordo, discordo, peço para corrigir ou desambiguar.
3. Escrita. Com o meu OK, outro agente grava a página da fonte, as páginas das pessoas, dos sistemas e dos conceitos, o índice e o log do dia.
4. Validação. Um script fecha a ingestão. Ele reprova frontmatter quebrado, link que aponta para página que não existe e página alterada sem entrada no log. É teste automatizado, só que para documentação, e eu fiz questão de que fosse determinístico, sem inferência de modelo.

Por que dois agentes e não um? Porque entre ler e escrever existe uma parada obrigatória: a conversa comigo. O humano faz a curadoria. O LLM executa.

Os números

Medi em 9 de novembro de 2026:

• 1.452 páginas curadas (sem contar log e _meta)
• 1.742 fontes brutas arquivadas
• 144 dias com registro no log, desde 20 de abril
• 0,01 s para o índice local devolver arquivo e linha ao agente

Duas ressalvas, para ninguém me corrigir depois. A contagem de páginas exclui wiki/log e wiki/_meta; se você contar todos os .md, chega a 1.602. E os 0,01 s são do tempo de busca com o índice quente, medido em 13 de agosto no meu notebook (Ubuntu 24.04, i7-11800H, 32 GB). De ponta a ponta, com o processo, deu entre 0,02 e 0,05 s.

Quem busca é o próprio agente. Ele monta a consulta e chama um índice local, léxico (BM25, o mesmo princípio dos buscadores clássicos) montado em SQLite. O índice procura pela palavra, não pelo sentido, e devolve só o endereço. O agente lê aquela seção e não a wiki inteira, e é isso que segura o custo de contexto.

Também não vou escrever “N páginas a partir de M fontes”. O rastro de proveniência chega a cerca de 700 fontes, não às 1.742 do acervo. A pasta raw/ mede o que eu arquivei. O campo original_file mede o que de fato virou página.

A lacuna também é conteúdo

Esta é a parte em que a wiki deixa de ser mais uma documentação.

Lacuna. Quando a fonte não diz alguma coisa, a página não inventa. Ela marca um [!gap]. Hoje são 647 páginas com pelo menos uma lacuna declarada. Para quem é de QA, é deixar o teste pendente visível em vez de apagá-lo.

Contradição. Quando duas fontes discordam, a página registra as duas, cada uma com a sua fonte, num [!contradiction]. São 262 páginas. A documentação comum escolhe uma versão e esconde a outra.

Procedência. A regra do schema é que cada afirmação aponte para o arquivo e a linha de onde veio. Não existe script que confira todas as páginas, então é regra de ingestão, não garantia. Mesmo assim, é ela que permite dizer, três meses depois, se algo foi decidido ou se o modelo inventou.

Os dois números de cima contam páginas com o callout, não o total de lacunas ou de contradições.

Onde eu uso no dia a dia

1. Reuniões. O registro entra no raw/ e vira página com o que foi decidido, quem ficou com o quê e o que ficou em aberto. Cada afirmação aponta para a fonte. É a resposta para a pergunta do começo.
2. Fechar e abrir o dia. No fim do expediente eu digito em texto corrido o que fiz, e o agente cruza com os commits. De manhã recebo onde parei, o que ficou em aberto e o que vence hoje. Parece pouco, mas numa segunda-feira de manhã ajuda muito.
3. Levantamentos. Foi o caso de 7 de outubro. Também o brag document, o registro das minhas entregas: “o que eu entreguei nos últimos meses?” virou consulta com fonte.
4. Estudo. Aulas de inglês, material da certificação da Anthropic e os artigos que eu leio ficam no mesmo acervo, ligados ao que eu já sei.

O ponto é que isso funciona como um hábito, o de anotar, e serve para vários usos. Eu me baseei muito no segundo cérebro do Tiago Forte, que é um método simples de anotação e me deu ótimo resultado.

Um caso real: refinamento vira mapa de teste

Em 28 de outubro participei de um refinamento de quase duas horas sobre a reforma tributária de 2027, com cinco histórias novas. Do registro saiu uma página com três coisas que me interessam como QA, conferida no mesmo dia contra os cards:

1. A decisão, com o motivo. O time optou por um vínculo explícito entre as notas fiscais, e não por uma regra implícita. A frase dita foi “prefiro explícito do que implícito”. Daqui a seis meses, a resposta para “por que a gente decidiu assim?” está lá, com data.
2. A regra que vira teste. A nota de utilização só pode sair depois que a antecipação for confirmada. Se sair antes, o imposto é pago duas vezes. Isso é um oráculo de teste.
3. A lacuna. O plano de testes não tinha sido definido na reunião, e as histórias estavam sem responsável e sem estimativa. Ficou marcado como lacuna visível, em vez de esquecido.

Saí do refinamento sabendo o que testar e sabendo o que ainda não estava decidido.

O luxo do conhecimento acumulado

Depois de alguns meses, a wiki vira matéria-prima. Eu uso o Hermes, um agente de código aberto da Nous Research, num perfil pessoal que lê a minha wiki. Ele me dá bom dia (onde parei, o que ficou aberto, o que vence hoje), monta a minha semana na agenda e, durante a semana, compara o que fiz com o que planejei e sugere ajuste.

Na segunda-feira da palestra, por exemplo, ditei as metas por voz: academia pelo menos quatro vezes, inglês três, três horas de estudo para a certificação, e a própria palestra como prioridade máxima. Ele montou a grade. Corrigi: inglês e certificação só de manhã, e a tarde do fim de semana é minha. Ele refez.

Isso não faz parte da LLM Wiki. Ela só permite. Sem a wiki, o assistente planeja a semana de um desconhecido.

Quatro coisas que aprendi errando

Cada item abaixo veio de um erro real, registrado no repositório da minha wiki.

1. Resumo gerado por IA não é fonte. A ferramenta de busca devolvia, junto com os trechos, um resumo que ela mesma gerou. Se eu cito o resumo, estou citando a IA. Para citar, volto ao trecho literal.
2. A IA completa o plausível, não o certo. Uma sigla de produto foi expandida com um nome que fazia todo sentido e estava errado. Ficou assim em 7 páginas por três meses e meio, porque ninguém abriu a fonte. Hoje, sigla sem fonte fica crua, marcada como lacuna.
3. Quando o agente erra, corrija a regra, não só a resposta. O mesmo erro se repetiu em 12 sessões. O agente avisava, corrigia na hora e seguia, e a instrução errada continuava lá. Aviso no chat morre com a sessão.
4. Regra que não pode falhar vai para o código, não para o prompt. Escrevi “nunca sobrescreva” na instrução e um minuto depois o agente sobrescreveu. A instrução é o segundo controle. O primeiro é o código.

Se um agente desobedece uma regra sua, antes de pôr “SEMPRE” em negrito, procure outra instrução no contexto dizendo o contrário. Ênfase não resolve instrução concorrente.

O que não vale ingerir

Você não precisa jogar tudo na wiki, e eu aprendi isso errando. Ingerir custa: o agente lê tudo, discute comigo e escreve várias páginas. Meu critério hoje:

• Ingerir: decisões e quem decidiu, aprendizados, erros, e o que eu vou cruzar com outras coisas ao longo dos meses.
• Só indexar: livros inteiros (grandes e com direito autoral), registros de reunião na íntegra e lotes de aulas que eu só vou consultar. Uma vez mandei um lote de aulas para a wiki e parei no meio, porque ia gastar muito token para algo que era só consulta.
• Nem guardar: credencial, token, link de autenticação e dado pessoal que não é seu. Na dúvida, redija antes de versionar, porque o git lembra para sempre.

Tudo isso cabe numa pergunta que eu me faço antes de ingerir: vou cruzar isso com outra coisa ou só consultar? Se for só consultar, indexa. Página é para o que vai se ligar a outras páginas.

E o NotebookLM?

A pergunta aparece em toda apresentação. O NotebookLM, que o Google agora chama de Gemini Notebook nas páginas oficiais de ajuda, eu pago e continuo usando. Ele responde outra pergunta.

Os limites vêm da página oficial de planos, consultada em 9 de novembro de 2026, e podem mudar. O meu custo também é real: curadoria dá trabalho, e o pipeline é meu para manter.

Quando crescer

Comecei com rg direto na pasta. Hoje uso busca léxica com índice. Estudei quatro caminhos para o passo seguinte, e vou dizer o quanto testei de cada um:

• Busca semântica. Acha pelo sentido, não pela palavra. Hoje “cobrança” e “cobranças” são palavras diferentes para a minha busca. Já uso nos registros de reunião, e na wiki é o meu próximo passo. Mas medi antes: uma busca com vetor empatou com a simples nas mesmas 24 perguntas. As duas acharam o arquivo certo entre os 5 primeiros em 58% delas.
• Grafo de conhecimento. O Understand-Anything gera um grafo navegável e tem um modo para wikis no padrão Karpathy. Este eu instalei e rodei.
• Ontologia. O Open Ontologies (MIT) usa RDF, SPARQL e MCP para planejar uma mudança no modelo e provar o impacto antes de aplicar. Estudei só pelo README.
• Roteamento. O llm-wiki-v2 (beta) usa um classificador pequeno para decidir onde cada nota vai, e o LLM só escreve. Estudei pelo código.

Minha recomendação: comece pela pasta, suba de nível quando a dor aparecer e meça antes.

Comece a sua

O kit mínimo que funciona:

raw/               fonte bruta; ninguém edita
wiki/sources/      uma página por fonte
wiki/entities/     pessoas, sistemas, times
wiki/concepts/     ideias e decisões que se repetem
wiki/log.md        o que entrou e quando
AGENTS.md          as três regras (ou CLAUDE.md)

As três regras:

1. Toda afirmação cita a fonte.
2. O agente mostra de 3 a 5 pontos e só grava depois do seu OK.
3. O que ninguém sabe vira lacuna, e o que diverge vira contradição.

Funciona com qualquer agente que leia arquivos (Claude Code, Codex, Gemini, Copilot). Abra o que você já usa numa pasta vazia e cole este prompt:

Crie uma LLM Wiki nesta pasta, com a estrutura e as três regras acima.
Depois me peça a primeira fonte: leia inteira, mostre de 3 a 5 pontos,
espere meu OK e escreva citando a fonte.

Coloque no git desde o primeiro dia. E não se preocupe com busca no começo: até umas 100 páginas, o próprio agente acha o que precisa. Índice é problema de quem já tem acervo.

Se você não quiser montar do zero, empacotei o método como o Anvilore: raw/, wiki/, schema e as skills de ingestão, consulta e lint. É livre, com licença MIT, e issue e pull request são bem-vindos. Toda página gerada nasce como rascunho e só vale depois que você aprova. A instalação e o uso por uma tela web ainda estão em construção.

O que eu não medi

Quatro limites, ditos com todas as letras:

• Não medi produtividade. Não vou dizer que a IA me deixou dez vezes mais rápido, nem inventar um número depois só para a frase ficar melhor. Também não medi quanto tempo de curadoria eu gasto por dia.
• Não testei com um time. A minha wiki é privada, roda na minha máquina e quem consulta sou eu. Uma pesquisa que fiz em 23 de outubro aponta governança e aprovação humana como o ponto aberto em empresa. Pede piloto.
• O sigilo depende de você. A wiki fica na minha máquina, mas o que o agente lê, na ingestão ou na consulta, vai para o provedor do modelo. O que entra segue a política do seu cliente. O Anvilore também não resolve vazamento de documento interno.
• Custo. Pasta, markdown e git custam zero. O custo é o do agente que você já usa.

Por fim

Terminei a palestra com a pergunta que deixo para você: onde está guardado o que você aprendeu nos últimos seis meses?

Se a resposta é “na minha cabeça”, é exatamente aí que vai se perder. O que eu mostrei é um hábito: registrar com fonte, deixar a IA fazer o trabalho chato e manter o humano na curadoria. É uma pasta com markdown.

Sou grato à Luísa e ao pessoal da NTConsult pelo convite e pelo horário de almoço. Sempre quis apresentar um pitch por lá, e apresentei algo que uso todo dia e que me dá resultado.

Espero que este artigo tenha sido útil.