O grafo que não pensa
Usar Obsidian como contexto para IA revela o quanto você ainda não entende como contexto funciona. Uma crítica sem diplomacia ao 'segundo cérebro'.
Indice
Semanas atrás, num grupo de engenharia de IA, alguém compartilhou um screenshot do vault do Obsidian e escreveu: “meu contexto para os agentes”. Tinha o grafo colorido, as notas interconectadas, o mapa bonito de pensamentos. Recebi três mensagens privadas de pessoas diferentes perguntando como responder sem constranger a pessoa.
Não existe resposta educada. Existe apenas a realidade: aquele screenshot me disse exatamente onde essa pessoa está no entendimento de como contexto funciona em LLMs. É um tell. Como no poker.
Não é sobre Obsidian ser bom ou ruim. Obsidian é uma ferramenta honesta e faz bem o que se propõe. O problema é outro: quando você aponta um vault do Obsidian como sua “camada de contexto para IA”, você está revelando que as palavras “contexto”, “grafo” e “conhecimento” ainda têm para você o mesmo significado que têm no marketing de produtividade, não o significado técnico que importa quando você está construindo sistemas com LLMs.
Esse post é para quem quer cruzar essa linha.
O sinal que você não percebe que está dando
O vocabulário do PKM (Personal Knowledge Management) se popularizou junto com o vocabulário de IA, e as palavras coincidiram de formas que criam confusão séria.
“Grafo de conhecimento.” No Obsidian, isso é uma visualização dos seus wikilinks. No mundo de IA, um knowledge graph é uma estrutura com entidades tipadas, relações tipadas, inferência lógica, e consultas em SPARQL ou Cypher. São dois objetos completamente diferentes usando o mesmo nome.
“Contexto.” No Obsidian, contexto é a sensação de que suas notas estão conectadas. No mundo de LLMs, contexto é o conteúdo que entra na janela de tokens do modelo. O que não está na janela não existe para o modelo. O que está na janela mas é irrelevante degrada a qualidade da resposta.
“Segundo cérebro.” No PKM, é metáfora motivacional. No mundo de AI agents, se você quer algo que funcione como memória de longo prazo para um agente, você precisa de retrieval semântico, persistência vetorial e alguma estratégia de esquecimento controlado.
Quando alguém usa essas palavras como se fossem equivalentes, fica visível que está navegando pelo marketing das ferramentas, não pela engenharia por baixo. Isso é o tell.
O grafo é decorativo
Para entender por que, vale separar os tipos de grafo que existem no campo de informação. A semelhança visual entre eles é enganosa.
Grafo de hyperlinks (Obsidian, Roam, Logseq): cada conexão é uma decisão manual. Você digita [[outra nota]] e a linha aparece. Sintaxe, sem semântica. O sistema não sabe que “produtividade” e “foco” estão relacionados a menos que você crie esse link com suas próprias mãos.
Mapa conceitual: também manual, mas com predicados nomeados. “X causa Y”, “X é tipo de Y”. Há semântica explícita, ainda que estática e com cobertura limitada ao que você formalizou.
Knowledge graph (Wikidata, DBpedia, Neo4j com schema): entidades tipadas, relações tipadas, consultas estruturadas. Inferência possível dentro do schema definido. Isso sim é o que engenheiros chamam de grafo de conhecimento.
Espaço de embeddings (RAG, busca semântica): nenhum link explícito. As relações emergem da proximidade vetorial entre representações de significado. O sistema descobre que “produtividade” e “foco” são próximos sem que você tenha criado esse link em nenhum lugar.
Comparando as capacidades reais de cada arquitetura:
| Arquitetura | Conexões automáticas | Significado semântico | Inferência |
|---|---|---|---|
| Obsidian (hyperlinks) | 0/10 | 0/10 | 0/10 |
| Mapa conceitual | 0/10 | 6/10 | 1/10 |
| Knowledge graph | 4/10 | 8/10 | 7/10 |
| Embeddings / RAG | 9/10 | 9/10 | 5/10 |
O Obsidian puro fica em zero em quase tudo que se associa a “inteligência” do sistema. Isso não é crítica à ferramenta. É uma propriedade da arquitetura. Markdown plano com wikilinks não tem como fazer inferência. O grafo bonito é um efeito colateral da contagem de links que você mesmo criou, não uma capacidade cognitiva emergente.
Princípio. Um grafo de hyperlinks responde à pergunta “o que você conectou?”. Um sistema de embeddings responde à pergunta “o que é semanticamente próximo?”. São perguntas fundamentalmente diferentes.
O paradoxo do colecionador
Em 2014, Christian Tietze descreveu o que chamou de “collector’s fallacy” num ensaio sobre Zettelkasten. A ideia é precisa: capturar informação dá uma sensação imediata de progresso intelectual que se confunde com efetivamente aprendê-la, processá-la, ou integrá-la ao que você já sabe.
Salvar um artigo é fácil. Lê-lo, integrá-lo, refutá-lo, citá-lo num texto próprio é difícil. O sistema recompensa o primeiro comportamento e raramente o segundo.
O resultado é previsível: notas criadas crescem de forma quase linear com o tempo. Notas que você realmente volta a usar achatam em poucos meses e nunca mais sobem. O que o usuário tem ao fim de dois anos não é um cérebro estendido. É um cemitério organizado de leituras pela metade.
Esse padrão existe em qualquer ferramenta de notas, mas se intensifica no Obsidian porque a interface visual recompensa o acúmulo. Aquele grafo colorido ficando mais denso parece progresso. Não é. É acumulação. São coisas diferentes.
Quando alguém diz “tenho mil notas no Obsidian sobre machine learning”, a pergunta relevante não é “quantas notas você tem?”. É: “em quantas delas você consegue fazer recuperação semântica automática a partir de uma query em linguagem natural?” A resposta, no Obsidian puro, é zero.
O que “contexto para IA” realmente significa
Quando um engenheiro fala em “contexto” no sentido técnico, está falando de algo específico: o conteúdo que entra na janela de contexto do modelo. Essa janela tem limite (tokens). O que está nela, o modelo vê. O que não está, não existe para ele.
A arte de trabalhar com LLMs é, em grande medida, a arte de decidir o que colocar na janela. As dimensões que importam:
1. Recuperação semântica. Encontrar conteúdo relevante mesmo quando as palavras exatas não batem. Se o usuário perguntar sobre “latência em sistemas distribuídos” e você tem uma nota sobre “tempo de resposta em microserviços”, um sistema de recuperação semântica encontra essa nota. Uma busca por substring no Obsidian não encontra.
2. Precisão do retrieval. Jogar mil tokens irrelevantes no contexto de um LLM não ajuda. Piora. O modelo tem mais ruído para filtrar. Estudos sobre “lost in the middle” (Liu et al., 2023) mostram que LLMs degradam quando o contexto é longo e o conteúdo relevante está enterrado no meio. Retrieval preciso é melhor do que retrieval generoso.
3. Atualização contínua. Um sistema de memória útil para agentes precisa incorporar nova informação sem reorganização manual. Embeddings num banco vetorial permitem isso. Um vault no Obsidian não.
4. Síntese. O sistema ideal não apenas encontra fragmentos relevantes. Combina-os para produzir algo que não estava explicitamente escrito em lugar nenhum.
Comparando capacidades cognitivas:
| Capacidade | Obsidian (puro) | Sistema RAG | Cérebro humano |
|---|---|---|---|
| Captura rápida | 9/10 | 7/10 | 8/10 |
| Recuperação semântica | 1/10 | 9/10 | 10/10 |
| Inferência | 0/10 | 4/10 | 10/10 |
| Síntese | 0/10 | 6/10 | 10/10 |
| Atualização contínua | 2/10 | 7/10 | 10/10 |
O Obsidian é excelente em captura. Péssimo em tudo que um sistema de contexto para IA precisa fazer.
Ferramenta não é contexto
A confusão tem raiz epistêmica. O método (CODE, PARA, Zettelkasten) e a ferramenta (Obsidian) foram colados no imaginário público como se fossem a mesma coisa. Não são. O método é cognitivamente real e testado. A ferramenta é apenas um dos muitos suportes para o método.
Luhmann produziu 90 mil fichas de papel e uma das obras mais sofisticadas de teoria social do século XX. Nenhum grafo, nenhum backlink, nenhum plugin. O método produziu o resultado. O suporte foi apenas papel e caixas.
Agora, quando o método migra para o contexto de IA, a ferramenta importa de forma diferente. Não porque Obsidian seja inadequado como ferramenta de escrita. Mas porque as operações que um agente de IA precisa realizar sobre uma base de conhecimento, recuperação semântica, reranking por relevância, chunking inteligente, persistência vetorial, não estão disponíveis em arquivos Markdown planos com wikilinks.
Jogar seu vault inteiro no prompt de um LLM não é usar seu vault como contexto. É usar seu vault como ruído.
O que separa amadores de practitioners na prática
Deixa eu ser direto sobre o que vejo nos projetos em que trabalho.
O amador tem uma coleção de notas no Obsidian e quando decide “usar IA”, pensa em como conectar esse vault ao Claude ou ao GPT. Às vezes exporta tudo como texto e cola no prompt. Às vezes encontra um plugin que promete fazer isso. O resultado é lento, caro em tokens, e impreciso.
O practitioner constrói um pipeline. Os passos básicos:
- Ingestão: cada documento é quebrado em chunks de tamanho controlado (tipicamente 512 a 1024 tokens, com overlap para não perder contexto entre chunks).
- Embedding: cada chunk é transformado em vetor por um modelo de embedding (text-embedding-3-small da OpenAI, ou modelos open-source como nomic-embed-text).
- Armazenamento: vetores ficam num banco vetorial. pgvector no Postgres, Qdrant, Weaviate, ou Chroma. A escolha depende da escala e dos requisitos operacionais.
- Retrieval: na hora de responder, a query do usuário também vira vetor. Busca-se os N chunks mais próximos semanticamente (cosine similarity). Tipicamente 5 a 20 chunks.
- Reranking: opcionalmente, um modelo de reranking reordena os chunks por relevância antes de mandá-los ao LLM.
- Geração: só então os chunks selecionados entram no contexto do LLM junto com a query.
O resultado: o modelo recebe somente o que é relevante. A janela de contexto é usada com eficiência. A qualidade da resposta é superior porque o sinal está limpo.
Isso não é complicado de implementar. LangChain, LlamaIndex, e o próprio SDK da Anthropic têm abstrações para isso. Um pipeline funcional leva menos de um dia de trabalho para alguém com experiência. O que separa quem faz de quem não faz não é capacidade técnica. É saber que o problema existe.
Onde o Obsidian não prejudica
Justiça seja feita: Obsidian é excelente no que realmente faz.
Arquivos Markdown locais significam que você não fica refém de nenhuma empresa. Daqui a dez anos seus arquivos ainda vão abrir em qualquer editor de texto. A extensibilidade via plugins é robusta e a comunidade é ativa. A interface de escrita é silenciosa, sem distrações, e respeita o fluxo de quem escreve.
Para captura, rascunho, e organização pessoal de ideias, Obsidian é uma escolha sólida. Eu uso para rascunhar posts, anotar referências, manter logs de experimentos. Funciona bem nisso.
O problema não é usar o Obsidian. É confundir o Obsidian com uma camada de contexto para sistemas de IA.
Na arquitetura de um agente bem construído, o Obsidian pode ser o front-end de captura: onde você escreve notas que depois são ingeridas pelo pipeline de embeddings. As notas do Obsidian alimentam o banco vetorial. O banco vetorial alimenta o agente. O Obsidian não faz retrieval. Faz captura. São papéis diferentes na mesma cadeia.
Os plugins mudam o jogo, mas o crédito vai para outro lugar
Plugins como Smart Connections e Obsidian Copilot adicionam busca semântica ao vault. Quando esses plugins funcionam bem, a experiência muda: você pergunta em linguagem natural e encontra notas relevantes que não teria encontrado por substring.
Isso é genuinamente útil. Mas é importante entender de onde vem a utilidade.
O Smart Connections usa um modelo de embedding, geralmente da OpenAI, para vetorizar suas notas. A busca semântica que ele oferece é o serviço de embeddings da OpenAI rodando sobre seus arquivos, exposto numa interface dentro do Obsidian. O Obsidian é o container. O trabalho semântico é feito pelo modelo de embedding externo.
Quando você percebe isso, a hierarquia fica clara. O Obsidian é a camada de armazenamento e interface. Os modelos de embedding e linguagem são a camada cognitiva. Misturar os dois é o que cria a ilusão de que o grafo pensa.
O grafo não pensa. O modelo pensa. O grafo é a visualização do que você digitou.
O próximo passo
Se você está construindo com IA e ainda usa Obsidian como sua camada de contexto, não é julgamento. É diagnóstico. E o diagnóstico tem tratamento curto.
Embeddings. Chunking. Retrieval. Reranking. Esses quatro conceitos, bem entendidos, separam a experiência de “jogar texto no prompt e torcer” da experiência de “o agente encontra exatamente o que precisa e responde com precisão”.
O vault do Obsidian pode continuar existindo. Mas ele para de ser o destino final do seu conhecimento e passa a ser o ponto de entrada de um pipeline que realmente recupera, de forma semântica e relevante, o que você precisa no momento em que precisa.
Aí o grafo para de ser decoração. E começa a trabalhar.
Referências
Forte, T. (2022). Building a Second Brain. Atria Books.
Tietze, C. (2014). “The Collector’s Fallacy”. zettelkasten.de. zettelkasten.de/posts/collectors-fallacy
Ahrens, S. (2017). How to Take Smart Notes. Create Space.
Luhmann, N. (1992). “Kommunikation mit Zettelkästen”. Em Universität als Milieu. Haux.
Liu, N. F. et al. (2023). “Lost in the Middle: How Language Models Use Long Contexts”. arXiv:2307.03172.
As tabelas são ilustrações qualitativas dos argumentos, não dados empíricos. As pontuações refletem capacidades arquiteturais documentadas na literatura sobre PKM e sistemas de recuperação de informação.