🚀 Técnicas Avançadas

Taxonomias organizam em hierarquias (Animal > Mamífero > Cão). Ontologias definem relações ricas e tipadas (cão PERTENCE-A mamífero, cão É-USADO-PARA caça). Wikis avançados usam ambas.

Entender a diferença permite projetar grafos que capturam semântica real — não apenas categorias, mas as relações que tornam o conhecimento acionável e navegável.

Taxonomia, ontologia, relações tipadas, hierarquia vs. rede, knowledge graph semântico.

Implementação prática de relações tipadas: YAML com campos semânticos (precede:, contradiz:, instância-de:) e seções nomeadas na nota. Dataview consulta essas relações como um banco de dados.

Relações tipadas transformam o wiki de grafo simples em knowledge graph semântico — capaz de responder "quais conceitos contradizem X?" com uma query Dataview.

YAML tipado, campos semânticos, seções nomeadas, Dataview como query engine, triplas no Obsidian.

Um wiki avançado tem 4 camadas sobrepostas: conceptual (o que é), operacional (como fazer), temporal (quando aconteceu) e relacional (quem está envolvido). Cada camada responde a um tipo de pergunta diferente.

Grafos multi-camada capturam a complexidade real do conhecimento — uma decisão pode ser entendida como conceito, operação, evento histórico e relação entre pessoas simultaneamente.

Camadas conceitual, operacional, temporal, relacional, grafo multi-layer, navegação por camada.

O LLM traversa caminhos no grafo para raciocinar: A → B → C → D. "Dado que X precede Y e Y causou Z, quais são as implicações de mudar X?" — inferências impossíveis com busca direta.

O raciocínio por caminho é o que transforma o wiki de repositório em motor de inferência — produz insights que não estão explicitamente armazenados em nenhuma nota.

Graph traversal, raciocínio inferencial, caminhos multi-hop, propagação de restrições, insight por caminho.

Grafos que evoluem: notas são atualizadas, relações mudam, nós obsoletos são arquivados. O LLM detecta evolução temporal — "o que mudou neste conceito desde janeiro?" — a partir do histórico de notas.

Conhecimento não é estático. Um grafo que captura evolução permite rastrear como sua compreensão de um domínio mudou ao longo do tempo — insight metacognitivo valioso.

Evolução temporal, versioning de notas, grafos dinâmicos, detecção de mudança, timeline de conhecimento.

Métricas avançadas com networkx: centralidade (nós mais conectados), betweenness (pontes críticas), clustering coefficient (densidade local), e identificação de comunidades temáticas emergentes.

As métricas revelam a arquitetura real do seu conhecimento — quais conceitos são hubs, quais são pontes entre domínios, onde há gaps e onde há redundâncias.

Centralidade, betweenness centrality, clustering coefficient, networkx, community detection, gap analysis.

Com 100+ notas, o index.md começa a consumir tokens demais. Com 500+, o vault inteiro excede a context window. O problema de escala é real e previsível — e tem soluções.

Sistemas que escalam mal são abandonados. Entender quando e como o problema aparece permite planejar a migração para arquiteturas escaláveis antes que o sistema se torne inutilizável.

Context window limit, tokens por nota, index crescimento linear, ponto de ruptura, estratégias de escala.

index.md aponta para ml-index.md, finance-index.md, philosophy-index.md — cada sub-índice contém apenas as páginas do seu domínio. O LLM carrega somente o(s) sub-índice(s) relevante(s) por consulta.

A indexação hierárquica mantém o custo de tokens constante independente do tamanho do wiki — é o que permite wikis de anos de ingestão continuarem eficientes.

Index hierárquico, sub-índices por domínio, lazy loading de contexto, custo constante de tokens, hierarchical navigation.

O padrão abstract: cada nota tem uma seção "## Abstract" de 2-3 frases — o LLM lê os abstracts primeiro e só expande as notas completas quando necessário. Reduz tokens em 80%.

Compressão de contexto é a diferença entre consultar 50 notas viável e impossível. Abstracts bem escritos capturam o essencial para decisão de relevância sem o custo da nota completa.

Abstract pattern, leitura em dois estágios, redução de 80% de tokens, relevance filtering, lazy loading de notas.

Quando um único vault fica grande demais, divide-se em vaults separados por domínio (trabalho/, pessoal/, projetos/) com CLAUDE.md e índices próprios — interligados por referências externas.

Sharding é a solução definitiva para escala — cada vault permanece pequeno e ágil, enquanto os links externos preservam a conectividade cross-domínio quando necessário.

Sharding por domínio, múltiplos vaults, referências externas, vaults independentes, cross-vault queries.

Salvar respostas de consultas frequentes como notas wiki próprias (cache/status-projeto-alpha.md) — atualizadas periodicamente. O LLM lê o cache em vez de reprocessar o wiki completo.

Para perguntas que você faz toda semana ("qual o status de X?"), o cache reduz tokens de 5.000 para 200 por consulta — ROI imediato em uso intenso.

Cache de respostas, notas cache/, invalidação periódica, consultas recorrentes, custo marginal mínimo.

Metas concretas: consulta típica abaixo de 2.000 tokens, ingestão de nota simples abaixo de 1.500 tokens, index.md abaixo de 500 linhas. Scripts de benchmark automatizados para monitorar regressões.

Sem benchmarks, a degradação de performance é invisível até virar um problema grave. Metas numéricas transformam otimização em disciplina mensurável, não em sensação subjetiva.

Token benchmarks, metas de performance, scripts de medição, detecção de regressão, otimização contínua.

A arquitetura tem três camadas: coletores (scripts que puxam dados de cada fonte), processadores (convertem para Markdown em raw/) e o orquestrador (agenda e coordena os coletores).

Entender a arquitetura modular permite adicionar novas fontes sem reescrever o sistema — cada coletor é independente e conectado ao pipeline via interface comum.

Coletores, processadores, orquestrador, arquitetura modular, interface de integração, raw/ como buffer.

github_collector.py usa a GitHub API para coletar PRs, issues e commits relevantes — salva como Markdown em raw/github/ para ingestão automática pelo agente do vault.

PRs e issues contêm decisões técnicas críticas que geralmente se perdem. Com a integração GitHub, o vault captura automaticamente o histórico técnico do projeto.

GitHub API, github_collector.py, raw/github/, filtros por label/milestone, ingestão de decisões técnicas.

slack_collector.py monitora canais configurados e exporta threads com reações ⭐ ou palavras-chave como decisão/aprovado/definido — capturando o conhecimento tácito das conversas.

A maior parte das decisões de equipe acontece no Slack e desaparece no histórico. A integração Slack salva o conhecimento crítico antes que seja esquecido.

Slack API, slack_collector.py, filtros por reação/keyword, raw/slack/, captura de decisões tácitas.

calendar_collector.py usa a Google Calendar API para criar automaticamente templates de reunião em raw/meetings/ antes de cada evento — prontos para anotação e ingestão pós-reunião.

Templates pré-gerados eliminam a fricção de captura — você encontra a nota pronta antes da reunião começar e só precisa preencher o que aconteceu.

Google Calendar API, calendar_collector.py, templates de reunião, raw/meetings/, ingestão pós-reunião.

Estratégias de segurança: PII anonymizer antes de ingerir dados de usuários, cofre separado para credenciais (nunca em raw/), filtros de conteúdo confidencial, .gitignore para dados sensíveis.

Integrar com sistemas externos aumenta o risco de vazar dados sensíveis acidentalmente. Definir as proteções antes de conectar os coletores previne incidentes de segurança.

PII anonymization, credenciais em .env, .gitignore, vault seguro, filtros de conteúdo confidencial.

orchestrator.py agenda todos os coletores (GitHub hourly, Slack daily, Calendar pre-meeting) e coordena as ingestões — um único processo que mantém o vault sempre atualizado de todas as fontes.

Sem orquestração, você gerencia N processos manualmente. O hub centraliza o agendamento, logging e tratamento de erros de todas as integrações em um único ponto de controle.

orchestrator.py, schedule(), múltiplos coletores, logging centralizado, single point of control.

Um único agente que faz tudo (ingestão + síntese + auditoria + consulta) fica sobrecarregado e inconsistente. Arquitetura multi-agente divide responsabilidades para máxima especialização.

Entender os limites do agente único motiva a transição para multi-agentes — cada agente tem prompts otimizados, context window calibrada e lógica de erro dedicada.

Limitações do agente único, especialização, divisão de responsabilidades, Agentic AI, sistema multi-agente.

Cada agente tem seu próprio arquivo de instruções: CLAUDE-ingester.md (regras de ingestão e atomização), CLAUDE-auditor.md (critérios de qualidade e lint). Prompts hiper-focados na tarefa específica.

Agentes com responsabilidades claras produzem resultados consistentemente melhores que agentes genéricos — a especialização é o mesmo princípio que torna equipes humanas mais produtivas.

CLAUDE-ingester.md, CLAUDE-auditor.md, responsabilidade única, prompts especializados, agentes independentes.

orchestrator.py usa threads para rodar agentes em paralelo: o ingester processa raw/ enquanto o auditor verifica o wiki existente. Fila de trabalho, timeout handling e relatório de resultados.

O orquestrador é o coração do sistema — sem ele, os agentes especializados são apenas scripts independentes. Com ele, formam um pipeline coordenado e resiliente.

orchestrator.py, threading, fila de trabalho, paralelismo, timeout, relatório centralizado.

A solução mais simples: cada agente opera em domínios exclusivos e não sobrepostos. O ingester só escreve em wiki/new/, o auditor só lê wiki/. Arquivos de lock para operações críticas.

Conflitos de escrita corrompem silenciosamente o wiki. A separação de domínios é a prevenção mais elegante — evita o problema em vez de resolver depois que acontece.

Domínios exclusivos, separação de responsabilidades, lock files, prevenção de conflitos, write isolation.

Agentes comunicam-se via fila de mensagens (arquivos JSON em queue/) e estado compartilhado (status.json). O ingester publica "nova nota criada" e o auditor consome para verificar imediatamente.

Comunicação estruturada entre agentes permite sistemas reativos — o auditor age imediatamente em cada nova ingestão, sem polling periódico desnecessário.

Message queue, event-driven, queue/ JSON files, status.json, pub/sub pattern, sistema reativo.

Tendências emergentes: memória de longo prazo nativa nos LLMs, grafos de conhecimento compartilhados entre equipes globalmente, e sistemas que aprendem sobre seus próprios padrões de uso.

Entender a direção da tecnologia permite arquitetar seu sistema hoje de forma evolutiva — o que você constrói agora deve ser fácil de migrar para as capacidades emergentes.

LLM native memory, shared knowledge graphs, meta-learning, AGI-ready PKM, arquitetura evolutiva.