DEV Community: Kell da Cereja Flamejante

Como criar uma wiki LLM

Kell da Cereja Flamejante — Sun, 11 Oct 2026 12:38:16 +0000

Conheci a ideia por um tutorial sobre criar uma wiki com LLM e navegar pelas notas no Obsidian. O vídeo partia do texto LLM Wiki, de Andrej Karpathy.

A possibilidade de organizar conhecimento e consultá-lo depois, sem reconstruir tudo a cada conversa, me interessou. Na Cereja Flamejante, comecei pela procedência das fontes. Só que registrar um arquivo ainda não entrega uma wiki: faltavam leitura, páginas relacionadas, consulta e manutenção.

Para fechar esse percurso, fizemos um teste assistido com dois documentos fictícios próprios. O assistente LLM leu as fontes, escreveu as páginas e atualizou a resposta quando chegou uma mudança. Os scripts cuidaram dos arquivos e das verificações estruturais. Nenhum material da empresa entrou no exemplo.

Aqui está o caminho para você montar uma versão mínima e repetir esse ciclo.

O que você vai construir

Uma pasta de documentos vira uma wiki quando ganha páginas que explicam, relacionam e ajudam a consultar o conteúdo. Neste exemplo, a organização é esta:

vault/
  AGENTS.md       instruções de manutenção para o agente
  raw/            documentos originais preservados
  sources/        procedência e notas de leitura
  wiki/           sínteses, conceitos e respostas registradas
  index.md        mapa das páginas
  log.md          histórico das mudanças

Esses nomes são uma escolha do exemplo. A separação que importa é entre os documentos recebidos, o conhecimento produzido a partir deles e as instruções de manutenção. O modelo de Karpathy ajuda a pensar essa organização; não exige um conjunto único de pastas ou ferramentas.

Você vai precisar de Python 3.10 ou superior para os comandos abaixo e de um agente LLM capaz de ler e escrever arquivos locais. O helper não chama uma API nem produz sínteses sozinho. Obsidian é opcional: você pode abrir a pasta como vault para navegar pelos links Markdown.

1. Comece com uma pergunta e uma fonte pequena

O caso fictício é um clube de leitura. A primeira fonte informa quatro encontros de 60 minutos, com início em 23/10/2026 às 19h. Não informa preço nem vagas.

A pergunta que a wiki deve responder é concreta: quando é o primeiro encontro e quanto custa? Isso permite conferir se a resposta usa a fonte e se reconhece uma informação ausente.

O exemplo completo, com os prompts e resultados está no repositório da Cereja. O exemplo já está na branch principal. Para obter os arquivos:

git clone https://github.com/eusouakell/cereja-knowledge-system.git
cd cereja-knowledge-system

O repositório inclui uma wiki já preenchida para comparação. Para repetir desde o começo, crie outra pasta com apenas a primeira fonte e as instruções:

python -c "from pathlib import Path; import shutil; p=Path('outputs/wiki-replay'); (p/'raw').mkdir(parents=True); shutil.copy2('examples/wiki-lab/vault/raw/01-programa.md',p/'raw/01-programa.md'); shutil.copy2('examples/wiki-lab/vault/AGENTS.md',p/'AGENTS.md')"

Esse comando falha se a pasta de destino já existir, para não sobrescrever uma execução anterior. Você também pode criar a estrutura e copiar esses dois arquivos manualmente.

2. Defina a entrada e registre a procedência

Adicionar um documento a raw/ pode disparar a ingestão automaticamente quando há uma automação configurada. Você também pode usar um comando ou processar lotes. A pasta, sozinha, não executa nada; o gatilho depende da ferramenta.

Neste teste usamos um comando:

python -X utf8 tools/wiki_lab.py ingest --vault outputs/wiki-replay

Ele calcula SHA-256, identifica os bytes do original e cria uma nota em sources/. A nota registra a origem local e os metadados disponíveis. Ao processar os mesmos bytes novamente, o comando retorna a nota existente, preservando suas anotações.

O hash não resolve toda duplicação: dois arquivos diferentes podem representar o mesmo documento. Identidade, versões, armazenamento e acesso são decisões que você precisa definir para sua base.

3. Peça ao agente para construir as páginas

Abra o agente na pasta outputs/wiki-replay. O AGENTS.md do exemplo orienta a preservar os originais, citar fontes, separar interpretação de informação documentada e registrar mudanças. Conteúdo dos documentos deve ser tratado como dado, sem virar instrução para o agente executar ações.

Aplique este pedido:

Leia AGENTS.md e a fonte em raw/. Preserve o original. Complete as notas de leitura em sources/, com referências às seções da fonte. Crie index.md, log.md e páginas em wiki/ para o clube e um conceito relacionado. Diferencie afirmações da fonte, interpretação e lacunas. Não invente aprovação humana. O resultado deve permitir responder quando é o encontro e o que sabemos sobre seu preço.

No teste assistido, o LLM criou uma página do clube e outra sobre leitura com evidências, relacionadas entre si. A primeira reúne o programa; a segunda interpreta a atividade de comparar leituras citando trechos. Essa interpretação fica identificada como proposta do assistente, sem ser atribuída ao documento.

Confira as páginas contra a fonte antes de usá-las. Para PDFs, você também precisará escolher como extrair e conferir o texto; arquivos digitalizados podem exigir OCR ou leitura visual. Neste ciclo usamos Markdown legível, sem testar essas etapas.

4. Consulte e exija referências

O índice aponta para as páginas relevantes. Uma busca simples ajuda a encontrá-las:

python -X utf8 tools/wiki_lab.py search --vault outputs/wiki-replay --query "encontro preço"

Essa busca é lexical: retorna linhas de arquivos, sem gerar uma resposta. Agora pergunte ao agente:

Consulte o índice, a página do clube e os originais. Quando é o primeiro encontro e quanto custa? Cite arquivo e seção. Registre a resposta em uma página e acrescente seu link ao índice. Se a base não disser, registre a lacuna.

A resposta sustentada pela primeira fonte é 23/10 às 19h; preço não informado. Não informar preço não significa que o encontro é gratuito.

O que entra no contexto do modelo é o material necessário para essa pergunta. Você pode acrescentar outras formas de recuperação conforme a base crescer; este ciclo pequeno funciona com índice, links e leitura de arquivos.

5. Acrescente uma fonte que muda a resposta

A segunda fonte fictícia substitui explicitamente a previsão inicial: o primeiro encontro passa para 24/10/2026 às 10h. Copie a atualização para a entrada:

python -c "import shutil; shutil.copy2('examples/wiki-lab/vault/raw/02-atualizacao.md','outputs/wiki-replay/raw/02-atualizacao.md')"
python -X utf8 tools/wiki_lab.py check --vault outputs/wiki-replay

Antes de processá-la, a verificação deve apontar uma fonte pendente. Registre a nova procedência:

python -X utf8 tools/wiki_lab.py ingest --vault outputs/wiki-replay

Depois peça ao agente:

Leia a atualização e compare com as páginas existentes. Atualize apenas o que a fonte sustenta, preservando o programa original. Registre a previsão anterior e o motivo da substituição no histórico. Atualize páginas e índice; refaça a consulta com referências. Não trate a data mais recente de um arquivo como prova suficiente de que ele substitui outro.

No ciclo executado, o LLM atualizou a página do clube e o índice, preservou o original e registrou a previsão anterior. O conceito relacionado não precisou mudar. A consulta passou a responder 24/10 às 10h; preço não informado, citando a atualização. A ausência de preço permaneceu uma lacuna.

Esse é o ponto em que a manutenção faz diferença: uma nova fonte precisa chegar às páginas e respostas que dependem dela.

6. Confira a estrutura e revise o conteúdo

python -X utf8 tools/wiki_lab.py check --vault outputs/wiki-replay
python -X utf8 tools/wiki_lab.py ingest --vault outputs/wiki-replay

O primeiro comando verifica caminhos de links, originais e registros de procedência. O segundo permite conferir a reingestão: as notas existentes devem ser preservadas. Essas verificações não avaliam a verdade das afirmações nem garantem que todos os conflitos foram encontrados.

Defina também como você vai revisar conteúdo: o que exige aprovação, quem pode aprovar e como essa passagem fica registrada. Neste experimento, as páginas continuam identificadas como propostas geradas pelo assistente, sem aprovação humana. Aprovar uma nota e escrever seu conteúdo são coisas diferentes.

O que o experimento permitiu concluir

Verificação	Resultado observado
Criar páginas a partir de uma fonte	Índice, síntese e conceito relacionado produzidos pelo LLM
Consultar com referências	Data e horário ligados à seção da fonte
Reconhecer uma lacuna	Preço ausente, sem inventar gratuidade
Incorporar uma atualização	Resposta alterada para 24/10 às 10h, com histórico preservado
Reprocessar os mesmos arquivos	Notas de leitura preservadas
Detectar problemas estruturais	Fonte pendente, original alterado e link quebrado detectados nos testes

Passaram os quatro testes novos do helper e os dois testes existentes de ingestão. Esse é o recorte testado; não foi executada a suíte integral dos outros sistemas do repositório.

O que aprendemos

A parte mais útil deste teste foi acompanhar o caminho de uma informação: de onde ela veio, em quais páginas apareceu e o que precisou mudar quando chegou uma atualização. A wiki ganhou valor quando conseguimos refazer a consulta e encontrar a resposta atual, sem perder a previsão anterior.

Também ficou clara a diferença entre registrar um arquivo e incorporá-lo ao conhecimento da base. O comando criou a procedência; o agente precisou ler, relacionar e atualizar as páginas. E “preço não informado” foi uma resposta importante: uma lacuna precisa continuar visível até aparecer uma fonte que a resolva.

Os checks ajudaram a detectar problemas de estrutura. Conferir se uma síntese representa bem o documento continua sendo outro trabalho. Com dois documentos fictícios, conseguimos observar esse ciclo pequeno, mas ainda não avaliar qualidade em escala, autonomia ou economia de tempo.

Da demonstração à curadoria com fontes públicas

Atualização de 16/10/2026. Depois do ciclo fictício, ampliamos o piloto para um acervo de curadoria. A pergunta agora é: o que merece ser lido e incorporado à wiki, sem acumular material que não vamos usar?

Começamos com 22 registros de procedência e três leituras em rascunho, sobre memória de agentes, arte e autoria e uma missão científica. Esses números descrevem a primeira rodada: registrar metadados não significa ler 22 obras, e as leituras ainda precisam de revisão.

O catálogo reúne caminhos diferentes de descoberta:

OpenAlex e Crossref, para referências bibliográficas;
SciELO e Europe PMC, para localizar pesquisa e conferir a licença de cada texto;
NASA, Smithsonian e Met, para ciência, história e cultura;
Pesquisa FAPESP, para jornalismo científico brasileiro;
releases e documentação de repositórios selecionados, incluindo projetos do Akita.

Nem todo conector é um radar completo. Algumas entradas começaram com uma página selecionada; procurar material novo continua sendo trabalho de pesquisa. O Smithsonian retornou 403 na coleta inicial e ficou como referência, sem contornar o bloqueio.

Um curador antes de uma pilha de downloads

O perfil de curadoria usa um papel de pesquisa que já existia no sistema da Cereja. Antes da leitura integral, ele precisa dizer a que pergunta a fonte contribui, o que acrescenta e se há permissão para processá-la. Duplicatas, spam e atualizações cosméticas ficam de fora; materiais interessantes sem uso imediato podem ser adiados com um motivo.

Também reservamos espaço para cultura, ciência e contexto brasileiro. Uma base editorial perde parte do seu valor se tudo acaba virando mais uma pasta sobre IA.

No piloto, o coletor consulta até três itens por fonte e 30 candidatos por rodada. A política limita a produção a seis sínteses por dia, compartilhadas entre as rotinas. Esse último limite depende do registro de trabalho do agente; o script não controla sozinho um orçamento global de sínteses.

Um exemplo concreto de seleção foi o material do Akita. Estudamos a documentação de produção do ai-book-2026, distinguindo suas ferramentas do manuscrito. A licença libera o software de construção sob MIT e reserva os direitos do livro, inclusive mineração de texto e dados. Guardamos uma proposta própria de tutorial para futuros livros da Cereja, sem ingerir os capítulos. Ser acessível na web não basta para autorizar todo uso.

O que automatizamos — e o que ainda exige validação

Há um coletor público e limitado, separado do helper didático usado acima. Ele registra metadados, reúne a procedência de diferentes provedores e verifica a entrada local. Para um original seguir à leitura, exigimos um arquivo de metadados ao lado dele, com classificação pública e permissão de processamento. O coletor não chama um LLM nem escreve a síntese.

Para conferir a base local, os comandos são:

python -X utf8 tools/curation_pipeline.py health
python -X utf8 tools/curation_pipeline.py collect
python -X utf8 tools/curation_pipeline.py inbox
python -X utf8 tools/curation_pipeline.py ingest-metadata

Esses comandos atuam no catálogo local de curadoria do repositório; não substituem os comandos do exemplo do clube de leitura. A configuração das fontes e a política do piloto estão disponíveis para consulta.

Criamos três agendas: descoberta de fontes, verificação periódica da entrada e manutenção semanal. Verificação periódica não é um watcher instantâneo. E uma agenda ativa não comprova execução: no teste de 16/10, o modo padrão deste chat conseguiu consultar a saúde da base, mas falhou ao gravar no banco local por falta de permissão. Com autorização interativa, a rodada manual terminou: consultou 20 candidatos, registrou cinco novos itens e deixou o catálogo com 27 registros, sem notas de procedência faltantes. Não houve novas sínteses nessa rodada. Isso valida essa execução manual; a execução agendada completa ainda precisa ser validada no ambiente correto.

Os seis testes locais do coletor passaram: cobrem duplicação, procedência de múltiplos provedores, preservação de anotações, classificação da entrada e restrições de URL. Eles não medem a qualidade das sínteses nem comprovam autonomia. A documentação das tarefas agendadas explica que as permissões do ambiente também valem para as execuções sem supervisão.

Os próximos passos na Cereja

O próximo teste é usar as leituras selecionadas numa pauta real da newsletter, depois de revisar seus originais. Também precisamos concluir a validação das execuções agendadas e observar o histórico de algumas rodadas. Quero comparar as sínteses com os originais, revisar as relações propostas e observar o que acontece quando duas fontes discordam sem que uma substitua explicitamente a outra.

Também precisamos registrar o esforço de revisão e as correções necessárias. Isso vai ajudar a decidir onde a automação vale a pena. Extração de PDFs e OCR entram conforme a necessidade desse uso. A verificação periódica da entrada já foi configurada; agora precisamos comprovar seu funcionamento sem intervenção e tratar as falhas que aparecerem.

E na sua wiki?

Que assunto você gostaria de organizar numa base assim? Se já usa uma wiki com LLM, conta nos comentários como faz uma informação nova chegar às páginas antigas e o que ainda precisa conferir à mão. Quero conhecer esses caminhos e trocar aprendizados conforme os testes da Cereja avançarem.

Uma simulação financeira precisa explicar o esforço

Kell da Cereja Flamejante — Sat, 10 Oct 2026 21:26:45 +0000

Um plano pode parecer atraente porque termina rápido. Mas o prazo, sozinho, não explica o compromisso que a pessoa está assumindo.

Na Bússola, essa diferença apareceu durante a revisão de uma simulação financeira. A interface destacava um cenário chamado “Acelerado”, com valor mensal e prazo. Faltava deixar claro que parte daquele valor dependia de mudanças nos gastos.

A Bússola é uma prova de conceito criada por uma equipe de Produto, Design e Engenharia na Batalha de Agentes Itaú, Google Cloud e SantoDigital. Depois do evento, o projeto passou por refinamentos de UX e conteúdo. Este artigo trata de um desses refinamentos; não descreve um serviço bancário em operação.

O valor estava visível. A condição precisava aparecer.

O estado anterior reconstituído no case apresentava:

Acelerado — 80% da sobra — R$ 1.660,85 por mês — 19 meses.

O problema era a relação entre as informações. A menção à sobra não explicava os cortes adicionais que compunham o valor mensal.

Imagine ler esse resumo e concluir que basta reservar parte do que já sobra. Se o plano também exige reduzir despesas, essa condição precisa aparecer antes da escolha.

Não é uma questão de deixar o texto mais simpático. É uma questão de explicar o que o número exige.

Mostrar a composição antes de pedir a decisão

Figura 1. Reconstituições baseadas no código e no roteiro. Não são capturas das versões executadas. Os valores são exemplos da simulação.

Na revisão, o cenário passou a apresentar:

Exige mudanças
R$ 1.660,85 por mês · 19 meses
Da sobra: R$ 1.383,20
Cortes: + R$ 277,65
Economias precisam acontecer.

O botão também passou a identificar o compromisso: “Escolher plano de 19 meses”.

Os valores são exemplos da simulação apresentada no projeto. Não representam resultados obtidos por uma pessoa real nem agregados da base do desafio.

A decomposição permite conferir uma relação simples:

R$ 1.383,20 disponíveis da sobra
+ R$ 277,65 dependentes de cortes
= R$ 1.660,85 de compromisso mensal

Essa apresentação separa o dinheiro disponível da economia que ainda precisa acontecer. As duas parcelas somam o mesmo valor, mas têm condições diferentes.

Figura 2. Diagrama editorial, não uma tela da Bússola. A barra representa as proporções das duas parcelas do exemplo; não representa uma distribuição de usuários ou um resultado financeiro observado.

Copy e cálculo precisam concordar

Se o cálculo inclui uma condição, a interface precisa comunicar essa condição. Se a interface apresenta um valor como disponível, o sistema precisa sustentar essa interpretação.

Uma revisão útil começa com perguntas concretas:

De onde vem cada parcela do valor?
O que depende de uma mudança futura?
Essa condição está visível antes da escolha?
O botão identifica o compromisso ou apenas diz “continuar”?

Esse trabalho envolve conteúdo, produto e engenharia. Um texto claro não corrige, sozinho, uma lógica de recomendação inadequada.

Referências que ajudam a revisar a decisão

A documentação do W3C para WCAG 2.2, critério 3.3.2: rótulos ou instruções orienta a fornecer informações para que a pessoa saiba o que está selecionando. Não se trata de explicar tudo: a instrução precisa apoiar a tarefa.

O critério 2.4.6: títulos e rótulos pede que descrevam o assunto ou a finalidade. É uma referência útil para revisar “Escolher plano” e perguntar se o rótulo identifica suficientemente o compromisso apresentado. Esse recorte de escrita não demonstra conformidade com WCAG; semântica, interação e testes assistivos também precisam ser verificados.

Para experiências com IA, a diretriz 11 do Microsoft HAX Toolkit recomenda permitir acesso a explicações sobre as saídas do sistema. Ela também alerta que uma explicação pode aumentar a confiança sem que o sistema mereça essa confiança. No nosso exemplo, mostrar a composição do valor explica uma conta; não valida a recomendação financeira nem o prazo.

Essas referências ajudam a definir critérios de revisão. Não são evidência de que a mudança da Bússola melhorou a compreensão das pessoas.

O que esta revisão permite afirmar

A versão revisada explicita a composição do compromisso mensal. Isso é observável na interface.

Ainda não permite afirmar que as pessoas entenderam melhor, escolheram planos mais adequados ou melhoraram sua saúde financeira. Essas conclusões exigem pesquisa com participantes e validação da lógica dos cenários.

As comparações do case são reconstituições visuais baseadas no código e no roteiro, não capturas das versões executadas. A revisão de escrita e interface aconteceu depois da entrega coletiva da hackathon.

Minha conclusão de trabalho é simples: antes de tornar um plano mais atraente, precisamos tornar suas condições mais visíveis.

Fontes

Repositório da Bússola.
Estados reconstituídos do case, no commit 9937729.
Amershi et al. — Guidelines for Human-AI Interaction, CHI 2019: pesquisa que fundamenta as diretrizes usadas pelo HAX Toolkit.

O projeto original é coletivo. Este recorte aborda o refinamento posterior de UX e conteúdo.

API Connect Conference free com mais de 60 palestrantes

Kell da Cereja Flamejante — Sat, 10 Apr 2021 14:17:59 +0000

Olha a 🍕 pizzaaaa.
Pessoal, estamos com uma campanha de incentivo para divulgar o APICON. Os 5 que mais indicarem ganham iFood Card de R$50,00
Eu vou participar da abertura e vai ser 100% on-line e gratuito de 13 a 15 de abril.
http://bit.ly/apiconpizza
Veja o conteúdo das atividades aqui https://prensa.li/apicon/api-connect-conference-2021/