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

> A apresentação de 12 de novembro por escrito: a noite em que a wiki se pagou, o fluxo, os números, quatro erros reais e um kit mínimo para você montar a sua.

- URL: https://iagofrota.com.br/blog/llm-wiki-na-pratica-pitch-tech-ntconsult/
- Data: 2026-11-12
- Tags: llm-wiki, segundo-cerebro, conhecimento-pessoal, qa, palestra, anvilore

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](https://iagofrota.com.br/blog/capturar-notas-e-facil-destilar-e-a-parte-que-doi/), [Mil páginas depois](https://iagofrota.com.br/blog/mil-paginas-depois-o-que-quebrou-na-minha-wiki-mantida-por-llm/) e [Para que serve uma wiki mantida por LLM no dia a dia](https://iagofrota.com.br/blog/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.

| | NotebookLM | LLM Wiki |
|---|---|---|
| Começar | Sobe o PDF e pergunta. Custo de partida zero. | Exige estrutura, regras e curadoria. |
| Limite | 50 fontes por caderno no gratuito; 600 no plano mais alto. | O disco. Hoje, 1.742 fontes num acervo só. |
| Onde fica | Na nuvem do Google. | Markdown no git, na sua máquina. |
| O que não sabe | Responde com o que as fontes dizem. | Lacuna e contradição viram conteúdo. |
| Melhor para | Conjunto fechado e temporário: edital, contrato, documento de fornecedor. | Conhecimento que cresce e precisa ser cruzado entre meses. |

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:

```text
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:

```text
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](https://github.com/iagofrota/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.