Topologias do pensamento: o Obsidian no espaço de embeddings

15.800 notas. 49.746 trechos. Cada trecho é um vetor de 256 dimensões.⁷ Rodei o UMAP no conjunto de dados completo, projetei o resultado em três dimensões e fiquei girando aquilo devagar na tela. Meu segundo cérebro tinha um formato, e esse formato revelou algo que as notas em si nunca me contaram: meu trabalho intelectual se agrupa em torno de três núcleos densos (Claude Code, design systems, pesquisa em IA) ligados por pontes finas de notas de interseção, cercados por um halo esparso de sinais órfãos que não se conectam a nada.

O formato do seu conhecimento mostra onde você pensa, onde você evita pensar e onde suas ideias têm espaço para colidir. A mesma arquitetura de contexto que estrutura o comportamento dos agentes estrutura o conhecimento humano.

Em resumo: projetar 15.800 notas do Obsidian em um espaço de embeddings de 256 dimensões revela três topologias de conhecimento — centralizada, descentralizada e distribuída —, cada uma com modos de falha próprios. As notas-ponte entre clusters são o que gera as descobertas mais originais, e a pesquisa sobre transições de fase mostra que uma curadoria descuidada pode derrubar a estrutura do seu conhecimento em um limiar abrupto.

TL;DR

Espaços de embeddings dão às bases de conhecimento uma estrutura espacial que revela a topologia intelectual. Kat (@poetengineer__) demonstrou três topologias para vaults do Obsidian: centralizada (uma ideia central conectando tudo), descentralizada (núcleos temáticos agrupados) e distribuída (arestas entre ideias rotuladas por relações semânticas).¹ Meu vault de 15.800 arquivos, com 49.746 trechos, exibe uma topologia descentralizada com três clusters dominantes. O trabalho de Pesce et al. sobre transições de fase na poda de redes neurais oferece um arcabouço matemático para entender quando a simplificação (curadoria, arquivamento, filtragem) cruza um limiar que quebra o funcionamento da estrutura de conhecimento.² A seguir: o que os embeddings capturam, três topologias de conhecimento com dados reais do vault, como diagnosticar a sua própria topologia e um explorador interativo montado a partir do meu vault de verdade.

O que os embeddings realmente capturam

Um embedding de texto converte um trecho de texto em uma lista de números. O post sobre o visualizador de tokenização mostrou como o texto vira tokens. Os embeddings vão além: os tokens viram coordenadas em um espaço de muitas dimensões onde a distância corresponde ao significado.

Dois trechos sobre “hooks do Claude Code para injeção de contexto” ficam próximos no espaço de embeddings. Um trecho sobre “hooks do Claude Code” e outro sobre “navegação em SwiftUI no iOS” ficam distantes. Essa distância não é sobreposição de palavras-chave. Dois trechos podem não ter nenhuma palavra em comum e ainda assim cair perto um do outro, se tratarem dos mesmos conceitos. Dois trechos podem compartilhar muitas palavras (“o sistema processa os dados”) e cair longe um do outro, se o contexto ao redor for diferente.

Meu vault usa o modelo potion-base-8M do Model2Vec: 7,6 milhões de parâmetros produzindo embeddings de 256 dimensões.³ O modelo é destilado de um sentence transformer maior (bge-base-en-v1.5) e alcança cerca de 90% do desempenho do all-MiniLM-L6-v2 rodando como modelo estático — ordens de magnitude mais rápido tanto em CPU quanto em GPU. Cada um dos 49.746 trechos do meu vault vira um ponto em um espaço de 256 dimensões.

Não dá para visualizar 256 dimensões diretamente. Técnicas de redução de dimensionalidade como o UMAP projetam a estrutura de alta dimensão em 2D ou 3D preservando as vizinhanças locais.⁴ Pontos que estavam próximos em 256 dimensões continuam próximos em 3. A estrutura global é aproximada, mas os clusters são reais.

Três topologias de conhecimento

A exploração de Kat sobre embeddings de notas do Obsidian identificou três topologias de conhecimento distintas.¹ Cada topologia reflete uma estrutura intelectual diferente, e cada uma falha de um jeito diferente.

Centralizada: uma ideia central conectando tudo

Numa topologia centralizada, a maioria das notas se conecta através de um único tema dominante. O espaço de embeddings mostra um cluster denso no centro, com filamentos finos se estendendo para fora. Um desenvolvedor que escreve exclusivamente sobre React veria essa topologia: React é o núcleo, e cada nota sobre testes, gerenciamento de estado, deploy e ferramental passa por ele.

Ponto forte: expertise profunda no domínio central. A busca funciona bem porque a maior parte das consultas cai na mesma vizinhança.

Como falha: fragilidade. Se o tema central perde relevância (uma mudança de carreira, uma tecnologia descontinuada), a estrutura inteira de conhecimento perde seu princípio organizador. Notas que só fazem sentido em relação ao centro ficam órfãs.

Descentralizada: núcleos temáticos agrupados

Numa topologia descentralizada, as notas formam vários clusters distintos conectados por notas-ponte. Meu vault exibe essa topologia, com três núcleos dominantes:

Os 22% restantes se distribuem entre Inspiração, Produtividade, Ciência e categorias menores.

Ponto forte: resiliência. Perder um cluster não destrói os outros. As conexões interdisciplinares se formam nas fronteiras entre clusters, e é daí que saem as descobertas mais originais.

Como falha: fragmentação. Se as notas-ponte entre clusters forem finas demais, os clusters viram silos intelectuais. Meu vault tem uma ponte fina entre Design e Claude Code (notas sobre desenhar interfaces de agentes, padrões de interface de prompt), mas quase nenhuma ponte entre Design e Desenvolvimento puro (notas de arquitetura de backend raramente se conectam a design visual). Essa lacuna é um ponto cego: eu penso em design e penso em engenharia de backend, mas raramente penso nos dois juntos.

Distribuída: arestas rotuladas por relações

Numa topologia distribuída, as conexões entre notas carregam rótulos semânticos descrevendo como as ideias se relacionam. A implementação de Kat usou um LLM para gerar rótulos de aresta entre notas vizinhas.¹ Em vez de proximidade anônima, cada conexão tem uma descrição: “contradiz”, “estende”, “fornece evidência para”, “aplica em outro domínio”.

Ponto forte: navegabilidade. Uma topologia distribuída responde não só “o que é relacionado?”, mas “de que forma é relacionado?”. Os rótulos permitem raciocínios de ordem superior: encontrar notas que contradizem uma tese, não apenas notas que a mencionam.

Como falha: custo. Gerar rótulos de aresta para todo par de conexões escala de forma quadrática. Para os 49.746 trechos do meu vault, rotular exaustivamente as arestas exigiria aproximadamente 1,2 bilhão de chamadas ao LLM. Implementações práticas rotulam apenas as arestas dentro de um limiar de similaridade.

Transições de fase: quando simplificar quebra a estrutura

Pesce, He e Caldarelli estudaram transições de fase na poda de redes neurais e encontraram um limiar abrupto: as redes exibem “uma transição de uma fase cooperativa e funcional para uma fase desordenada, com desempenho em colapso”.² Abaixo do limiar, remover conexões quase não afeta o funcionamento. No limiar, o funcionamento entra em colapso de forma abrupta. A transição segue leis de escala compatíveis com comportamento crítico de segunda ordem — a mesma matemática que descreve o gelo derretendo em água.

O paralelo com a curadoria de conhecimento é direto. Meu pipeline de pontuação de sinais⁶ reduziu a Inbox de 14.771 para 5.886 notas por meio de um limiar de relevância. A mesma dinâmica de contexto composto que faz a memória dos agentes acumular valor também vale aqui: o que cada nota vale depende das suas conexões, não só do seu conteúdo. A redução melhorou a qualidade da busca: menos resultados de baixa relevância, clusters mais coesos, recuperação mais rápida. Mas houve perda de sinal? A simplificação cruzou um limiar de transição de fase?

A pesquisa sobre poda sugere que a resposta depende da conectividade, não da quantidade. Remover nós isolados (notas sem vizinhos semânticos) tem impacto desprezível sobre o funcionamento da rede. Remover nós-ponte (notas que ligam clusters que de outro modo ficariam separados) pode derrubar a estrutura mesmo que, individualmente, essas notas pareçam pouco importantes.

Meu pipeline de triagem elevou o limiar de relevância de 0,30 para 0,40. A redução de 60% no tamanho da inbox foi medida por contagem. Não medi o impacto sobre a topologia. Uma estratégia de curadoria consciente das transições de fase faria o seguinte:

1. Identificar as notas-ponte antes de filtrar (notas com alta centralidade de intermediação no grafo de similaridade)
2. Isentar as notas-ponte da filtragem por relevância, independentemente da pontuação individual
3. Monitorar métricas de conectividade entre clusters após cada passagem de curadoria
4. Alertar quando uma etapa de curadoria reduzir a densidade de pontes entre clusters abaixo de um limiar

# Sketch: bridge note detection before curation
def identify_bridge_notes(embeddings, threshold=0.7):
    """Find notes that connect otherwise-separate clusters."""
    from sklearn.neighbors import NearestNeighbors
    nn = NearestNeighbors(n_neighbors=10, metric='cosine')
    nn.fit(embeddings)
    distances, indices = nn.kneighbors(embeddings)

    # Bridge score: how many of a note's neighbors are from
    # different clusters than the note itself
    bridge_scores = []
    for i, neighbors in enumerate(indices):
        own_cluster = labels[i]
        cross_cluster = sum(1 for n in neighbors if labels[n] != own_cluster)
        bridge_scores.append(cross_cluster / len(neighbors))

    return bridge_scores

Como diagnosticar a topologia do seu conhecimento

Você não precisa de 15.000 notas para analisar a topologia do seu conhecimento. Qualquer coleção com mais de 100 notas e embeddings já revela estrutura. Se você usa Obsidian como infraestrutura de IA, a matéria-prima já está aí — os dezessete mil sinais do meu vault começaram como simples capturas diárias. Três perguntas de diagnóstico:

1. Quantos clusters existem?

Rode k-means ou DBSCAN nos seus embeddings e conte os clusters distintos. Menos de 3 sugere topologia centralizada. Entre 3 e 8, descentralizada. Mais de 8 pode indicar tanto uma topologia genuinamente distribuída quanto falta de curadoria (muitos clusters significam muitos assuntos, o que pode significar nenhuma profundidade em nenhum deles).

2. Quão densas são as pontes?

Para cada par de clusters, conte as notas que têm vizinhos mais próximos em ambos os clusters. Uma densidade de pontes abaixo de 2% do tamanho do cluster menor indica um possível silo. Minha ponte entre Design e Desenvolvimento está em cerca de 1,4% — abaixo do limiar, o que confirma o ponto cego que eu já tinha percebido.

3. Qual é o percentual de órfãs?

Uma nota órfã não tem nenhum vizinho dentro de um limiar de similaridade de cosseno (tipicamente 0,7). Notas órfãs não são necessariamente ruins — podem representar ideias genuinamente novas. Mas uma taxa de órfãs acima de 15% sugere ou captura inconsistente (notas que não combinam com o seu domínio de conhecimento) ou problemas na qualidade dos embeddings.

Taxa de órfãs do meu vault: cerca de 8%. A maioria das órfãs são capturas brutas da Inbox que ainda não foram transformadas em notas estruturadas. A taxa cai para 3% quando a Inbox é excluída, o que indica que as notas processadas se integram bem à topologia existente.

O que os clusters revelam

A visualização acima usa 500 trechos amostrados aleatoriamente do meu vault. Os clusters correspondem a vizinhanças intelectuais reais.

O núcleo de IA e ML (26% dos trechos) é o cluster mais denso. Arquitetura do Claude Code, padrões de design de agentes, papers de pesquisa em LLM e técnicas de prompt engineering formam uma vizinhança compacta. A densidade reflete volume: eu leio e capturo mais conteúdo de IA/ML do que de qualquer outra categoria. A densidade também traz vantagem na qualidade da busca — consultas nesse domínio retornam resultados muito relevantes porque o espaço de embeddings ali é bem povoado.

O núcleo de Design (14%) fica a certa distância de IA e ML. Sistemas tipográficos, ciência das cores, padrões de componentes de UI e referências de design visual formam seu próprio cluster. A separação faz sentido: design e engenharia de IA usam vocabulários diferentes, arcabouços de raciocínio diferentes e critérios de avaliação diferentes. Mas a separação também significa que consultas como “como a saída de um agente deveria ser formatada para revisão por um desenvolvedor” caem na lacuna entre os dois clusters, retornando resultados de um lado ou do outro, mas raramente da interseção.

O núcleo de Desenvolvimento (10%) se sobrepõe mais a IA e ML do que a Design. Padrões de FastAPI, modelagem de bancos de dados e arquitetura SwiftUI compartilham vocabulário conceitual com as notas de engenharia de IA (os dois lados falam de código, arquitetura, testes). Essa sobreposição de vocabulário produz uma zona mista, onde vivem as notas de DevOps-para-agentes e infraestrutura-para-IA.

O halo da Inbox (28%) cerca tudo. Capturas brutas, sinais sem classificação e bookmarks não processados formam uma nuvem esparsa com conexões fracas com os clusters estabelecidos. O pipeline de pontuação de sinais que reduziu a Inbox de 14.771 para 5.886 notas eliminou sobretudo material desse halo: notas com baixa similaridade com qualquer cluster estabelecido.

O cluster de Inspiração (6%) ocupa uma posição entre Design e Inbox. Referências de tipografia cinética, estudos de motion design e capturas de arte visual formam uma vizinhança frouxa. O cluster existe porque eu capturo inspiração visual com constância, mas raramente transformo essas capturas em notas estruturadas. O cluster revela um padrão: eu consumo inspiração visual de forma ampla, mas produzo trabalho de design de forma estreita. A distância entre consumo e produção fica visível na topologia como um cluster com alta densidade de entrada (capturas) e poucas conexões de saída (notas que constroem algo em cima da inspiração).

As pontes entre clusters são o traço mais interessante. A ponte mais fina liga Design e Desenvolvimento: cerca de 1,4% das notas do cluster menor têm vizinhos mais próximos nos dois clusters. Compare com a ponte de IA para Desenvolvimento, em 8,3%, que reflete o quanto do meu trabalho de desenvolvimento envolve infraestrutura de IA. A densidade das pontes prevê onde o trabalho original aparece. Meu post de boids para agentes nasceu de uma nota-ponte que ligou pesquisa sobre comportamento emergente (cluster de IA e ML) com a implementação de algoritmos de bando (cluster de Desenvolvimento). Sem a ponte, esses dois conjuntos de notas nunca teriam colidido.

A topologia também molda a qualidade da recuperação. O recuperador híbrido que alimenta a busca do meu vault usa tanto correspondência de palavras-chave por BM25 quanto similaridade vetorial — mas sua eficácia depende da estrutura de clusters por baixo. Consultas que caem em clusters densos retornam resultados precisos; consultas que caem entre clusters precisam do BM25 como reserva para atravessar a lacuna.

Existe um segundo banco de embeddings ao lado do vault: o banco de busca da toolchain, com 4.518 trechos em 653 arquivos.⁵ A topologia da toolchain é radicalmente diferente: um único cluster denso (configuração do Claude Code) com pequenos clusters satélites para testes, hooks e skills. Essa topologia de monocultura funciona para uma toolchain, porque uma toolchain tem um propósito único. Um vault de conhecimento com topologia de monocultura seria um sinal de alerta.

Como remodelar a sua topologia

A topologia não é fixa. Quatro ações deliberadas remodelam a estrutura do conhecimento.

Escreva notas-ponte. Se dois clusters não têm conexão, escreva notas que liguem explicitamente conceitos entre eles. Minha ponte de Design para IA é fina porque raramente escrevo sobre desenhar interfaces de agentes. Uma nota chamada “Padrões de UX para saída de agentes”, citando tanto princípios de design quanto pesquisa em arquitetura de agentes, criaria um ponto de ponte.

Detecte as órfãs. Rode uma varredura mensal de órfãs e decida: integrar, arquivar ou apagar. Notas órfãs que representem ideias nascentes devem ser ligadas aos clusters existentes por notas-ponte. Notas órfãs que sejam referências pontuais podem ser arquivadas.

Monitore depois da curadoria. Antes e depois de qualquer curadoria em massa (apagar, arquivar, filtrar), meça a conectividade entre clusters. Se a densidade de pontes cair, a curadoria removeu notas-ponte que deveriam ter sido preservadas.

Leia nas fronteiras. As leituras mais valiosas não estão mais fundo no seu cluster mais denso. Estão nas bordas entre clusters. Um paper que faz ponte entre engenharia de IA e design visual vai gerar mais conexões originais do que outro paper que aprofunda o cluster de IA já denso.

Pontos principais

• Espaços de embeddings dão forma às bases de conhecimento. Essa forma revela a topologia intelectual: onde você concentra atenção, onde você a evita e onde as ideias se conectam entre domínios.
• As três topologias falham de formas diferentes. A centralizada é frágil. A descentralizada se fragmenta sem notas-ponte. A distribuída é cara de manter, mas é a mais rica para navegar.
• As transições de fase tornam a curadoria não linear. Remover notas abaixo de um limiar quase não afeta a estrutura. No limiar, o funcionamento entra em colapso. As notas-ponte precisam ser identificadas e protegidas antes de qualquer curadoria em massa.
• O halo da Inbox é a fronteira da curadoria. As capturas brutas formam uma nuvem esparsa em volta dos clusters estabelecidos. A pontuação de sinais filtra o halo, mas é a topologia que revela se a filtragem preservou ou destruiu as conexões-ponte.
• Leia nas fronteiras. As notas de maior valor conectam clusters em vez de aprofundá-los. A detecção de órfãs e as métricas de densidade de pontes orientam as prioridades de leitura.

FAQ

Referências