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.
Vi ali um caminho para uma dificuldade do meu trabalho: entender como diferentes tecnologias e fornecedores se relacionavam. Eu precisava organizar esse conhecimento e conseguir consultá-lo depois, sem reconstruir tudo a cada conversa.
Criei a wiki para essa finalidade. Mais tarde, decidi adaptar o modelo à Cereja Flamejante, numa escala menor, para coletar estudos e apoiar a curadoria da newsletter.
Nesse percurso, também apareceu um vídeo sobre o Open Knowledge Format. Ele acrescentou uma pergunta: como compartilhar essa organização de conhecimento entre ferramentas e agentes?
Vou mostrar como essas peças se conectam e o que já implementei na Cereja. Os exemplos são próprios. Os documentos e as imagens do trabalho ficam lá.
Uma wiki para ler, relacionar e consultar
Uma wiki LLM reúne fontes, notas, conceitos e sínteses em páginas relacionadas. Pessoas e agentes podem consultar essa base e participar da manutenção, seguindo regras sobre revisão e atualização.
Uso o Obsidian sincronizado na máquina para ler as notas e navegar pelos links. E o grafo é um show à parte: dá para explorar o conjunto por outro caminho. Só não dá para confundir uma conexão bonita com uma afirmação bem sustentada. Para conferir a informação, volto à fonte.
Karpathy descreve três peças no seu modelo: fontes preservadas, páginas relacionadas e um documento que orienta o agente a manter a wiki. Adaptei a proposta às minhas necessidades.
A wiki guarda conhecimento persistente. Já o contexto do agente é o conjunto de informações e instruções que o modelo recebe durante uma tarefa. Uma base pode ter centenas de notas; uma tarefa pode precisar de poucas.
Também posso usar RAG, ou geração aumentada por recuperação, para buscar trechos dessa base e apresentá-los ao modelo. A organização do conhecimento e sua recuperação cumprem funções diferentes.
Onde a wiki entra no trabalho dos agentes
Na Cereja, o Núcleo registra conhecimento, evidências, interpretações e teses. O Editorial Engine prepara as publicações. O Agentic Factory mantém os papéis dos agentes e os controles compartilhados entre os sistemas.
A wiki participa dessa arquitetura ao tornar o conhecimento consultável. Os guides orientam o trabalho: descrevem o procedimento, a sequência e as informações que uma tarefa exige.
Por exemplo: para preparar um texto sobre um estudo, o agente precisa da fonte, das limitações e das instruções editoriais. Ele pode propor uma síntese. Aprovar a síntese como posição da Cereja e autorizar sua publicação são decisões separadas.
Esse é o papel da camada agêntica: organizar a consulta e o uso de ferramentas durante a execução. Ela precisa saber tanto onde buscar conhecimento quanto quais ações pode executar.
Esquema didático da Cereja. Algumas etapas ainda são manuais.
A ingestão começa por comando
Na wiki do trabalho, colocar um documento em raw/ não dispara a ingestão. Alguém pede para processá-lo, ou eu aproveito o fim de uma tarefa.
Um check, uma verificação feita pelo sistema, aponta os arquivos que nenhuma nota referencia. Quando descarto uma fonte de propósito, registro o motivo. Assim, o arquivo deixa de aparecer como pendência sem desaparecer da história.
Não há watcher nem tarefa agendada. Como a pasta não muda a cada minuto, esse fluxo bastou no meu uso.
Na Cereja, comecei pelo mesmo gatilho: um comando. Implementei primeiro o registro de procedência, antes da extração e da síntese.
raw/ # arquivos originais locais
sources/ # procedência e notas de leitura
tools/ingest_source.py # comando de ingestão
examples/wiki-ingestion/ # exemplo próprio da Cereja
O comando calcula o SHA-256 do arquivo. Esse hash identifica seus bytes e entra no nome da nota. Se a nota já existe, o comando retorna seu caminho e preserva as anotações.
digest = hashlib.sha256(path.read_bytes()).hexdigest()
destination = target_dir / f"source-{digest}.md"
if destination.exists():
return destination, False
A wiki do trabalho usa a origem normalizada, registrada em resource, como identidade. Na Cereja, separei as funções: o hash identifica o conteúdo; a referência registra de onde ele veio.
Isso permite detectar bytes diferentes, mas não resolve toda duplicação. Dois PDFs podem representar o mesmo estudo. Também preciso relacionar suas versões quando houver uma atualização.
Uma nota precisa dizer de onde veio
A nota da Cereja nasce em draft. Ela registra título, autoria informada, caminho do original, hash, URL quando disponível, direitos declarados e data de ingestão. O comando marca campos desconhecidos como unknown.
Você pode executar o exemplo próprio da implementação com:
python tools/ingest_source.py examples/wiki-ingestion/source-demo.md \
--title "Exemplo de coleta da Cereja" \
--author "Cereja Flamejante" \
--rights "Material demonstrativo próprio" \
--public-note
O comando também pode ser escrito em uma linha. A opção --public-note confirma que o nome e os metadados do arquivo podem aparecer publicamente. Ela não concede direitos sobre o documento.
Os originais de raw/ ficam fora do Git por padrão. Antes de publicar um PDF, preciso verificar sua licença. Quando a redistribuição não é permitida, posso manter a referência e minha análise original, respeitando os direitos da fonte.
Primeira etapa implementada com um Markdown demonstrativo próprio. Extração e síntese ainda não fazem parte do comando.
A síntese vem depois
No trabalho, extraio texto dos PDFs com pdftotext, do Poppler. A wiki não tem OCR. Quando o documento contém páginas como imagens, o modelo pode lê-las nessa forma.
O LLM escreve a síntese e referencia as páginas. A nota separa as afirmações do documento da nossa interpretação e das ressalvas. Também registra o modelo gerador e seu consumo de tokens. Notas de conceitos e entidades apontam para as notas das fontes.
Na Cereja, o comando atual cria apenas o registro de procedência. Estes campos deixam isso visível:
type: "source"
status: "draft"
certainty: "unverified"
published: "unknown"
extraction_status: "not_attempted"
Ainda não extraímos nem resumimos o documento nesse fluxo. Depois da leitura, precisamos registrar método, população ou escopo, limitações e os trechos que sustentam cada afirmação. O schema de evidências da Cereja orienta essa revisão.
Uma síntese gerada só passa a ser conhecimento canônico, a referência aprovada do sistema, depois da promoção humana. E “aprovado por Kell” não significa “escrito por Kell”. A procedência da autoria permanece.
Quem confere o que ficou para trás?
Na wiki do trabalho, os checks verificam metadados, links, tamanho das notas e presença no índice. Também apontam fontes sem tratamento e conferem se as notas derivadas mantêm as restrições das fontes.
A nota começa em draft. Uma pessoa registra a leitura em review_stage. A promoção para stable exige um responsável humano; um check rejeita uma nota estável atribuída a um modelo. Quem abre o PR não aprova o próprio PR.
Essas verificações ajudam a manter a base, mas não leem o estudo por nós. Um link pode funcionar e levar a uma fonte inadequada. Uma pessoa ainda precisa avaliar o que sustenta a afirmação.
Na Cereja, os checks de cobertura, direitos e promoção ainda precisam ser adaptados e testados. Também precisamos respeitar os estados que o Núcleo já usa. Copiar nomes sem conferir o significado criaria outra confusão.
Consultar a base sem despejar tudo no modelo
No Núcleo, parto da tarefa, localizo as regras aplicáveis e consulto os materiais necessários. Esse conjunto entra no contexto do agente. O restante da wiki continua disponível para consulta.
A Anthropic descreve essa consulta sob demanda como uma estratégia de organização do contexto. Ela também aponta um custo: o agente precisa explorar a base durante a execução.
Para a newsletter, uma tarefa pode pedir a comparação entre dois estudos. O agente recebe as fontes e suas limitações, além das orientações de escrita. A conclusão que ele propõe continua sujeita à revisão.
Mais documentação não resolve qualquer falha. Às vezes falta uma informação; em outras, falta um limite aplicado pela ferramenta ou uma verificação do resultado. Preciso descobrir qual peça está faltando antes de acrescentar outra pasta.
O OKF acrescenta a questão da portabilidade
O Open Knowledge Format, apresentado pelo Google Cloud, propõe convenções para representar conhecimento em Markdown, com metadados YAML e links entre conceitos.
Isso me interessa porque separa o formato do conhecimento das ferramentas que o produzem e consultam. A base pode ser compartilhada sem depender de uma única interface.
O OKF v0.1 ainda é uma proposta inicial. Usar Markdown e metadados não torna nossa wiki automaticamente compatível com ele; precisamos conferir a especificação.
O primeiro teste na Cereja
Executei o comando com um arquivo Markdown demonstrativo próprio. A primeira chamada criou a nota. A segunda retornou a mesma nota, sem sobrescrevê-la.
Os testes verificaram preservação dos bytes e das anotações humanas, reingestão, conteúdo alterado, limites dos caminhos e confirmação de metadados públicos.
A implementação está no PR #34. Os dois testes novos passaram. A suíte completa apresentou uma falha existente de Flame ligada aos separadores de caminho no Windows.
Esses resultados confirmam comportamentos específicos do comando. Ainda não medimos ganhos de tempo ou qualidade da curadoria. Extração de PDFs, sínteses revisáveis e checks de cobertura são os próximos passos. OCR e monitoramento da pasta ficam para quando o uso mostrar essa necessidade.
Quero usar essa base para reunir estudos, acompanhar perguntas e preparar a curadoria da Cereja. Comecei pela procedência porque preciso conseguir voltar ao documento e entender o que já foi conferido. A próxima prova será usar essas notas em uma pauta real da newsletter.
Na sua base de conhecimento, como você distingue uma nota gerada de uma informação já revisada? Conta nos comentários como você organiza essa passagem.
Top comments (1)
Official Platform Update
Security protocols have been updated for all developer accounts.