Topologies de la pensée : Obsidian dans l'espace d'embeddings

15 800 notes. 49 746 chunks. Chaque chunk, un vecteur à 256 dimensions. J’ai appliqué UMAP sur l’ensemble du jeu de données, projeté le résultat en trois dimensions, puis fait pivoter lentement la visualisation à l’écran. Mon second cerveau avait une forme, et cette forme révélait quelque chose que les notes elles-mêmes ne m’avaient jamais dit : mon travail intellectuel se concentre autour de trois pôles denses (Claude Code, systèmes de design, recherche en IA) reliés par de fins ponts de notes d’intersection, entourés d’un halo diffus de signaux orphelins qui ne se connectent à rien.

La forme de vos connaissances vous indique où vous pensez, où vous évitez de penser, et où vos idées ont la possibilité d’entrer en collision. La même architecture de contexte qui structure le comportement des agents structure aussi la connaissance humaine.

En résumé : Projeter 15 800 notes Obsidian dans un espace d’embeddings à 256 dimensions révèle trois topologies de connaissance — centralisée, décentralisée et distribuée — chacune avec des modes de défaillance distincts. Les notes-ponts entre les clusters génèrent les idées les plus novatrices, et la recherche sur les transitions de phase montre qu’une curation imprudente peut effondrer votre structure de connaissances à un seuil critique.

TL;DR

Les espaces d’embeddings confèrent aux bases de connaissances une structure spatiale qui révèle leur topologie intellectuelle. Kat (@poetengineer__) a identifié trois topologies pour les coffres Obsidian : centralisée (une idée centrale connectant tout), décentralisée (des pôles thématiques en clusters) et distribuée (des arêtes entre les idées étiquetées par relations sémantiques).¹ Mon coffre de 15 800 fichiers et 49 746 chunks présente une topologie décentralisée avec trois clusters dominants. Les travaux de Pesce et al. sur les transitions de phase dans l’élagage des réseaux de neurones fournissent un cadre mathématique pour comprendre quand la simplification (curation, archivage, filtrage) franchit un seuil qui brise le fonctionnement de la structure de connaissances.² Ci-dessous : ce que les embeddings capturent réellement, trois topologies de connaissance avec des données réelles de coffre, comment diagnostiquer votre propre topologie, et un explorateur interactif construit à partir de mon coffre.

Ce que les embeddings capturent réellement

Un embedding textuel convertit un passage de texte en une liste de nombres. L’article sur le visualiseur de tokenisation expliquait comment le texte devient des tokens. Les embeddings vont plus loin : les tokens deviennent des coordonnées dans un espace de haute dimension où la distance correspond au sens.

Deux passages sur les « hooks Claude Code pour l’injection de contexte » se retrouvent proches dans l’espace d’embeddings. Un passage sur les « hooks Claude Code » et un passage sur la « navigation SwiftUI pour iOS » se retrouvent éloignés. La distance ne repose pas sur le chevauchement de mots-clés. Deux passages peuvent ne partager aucun mot et se retrouver néanmoins proches s’ils traitent des mêmes concepts. Deux passages peuvent partager beaucoup de mots (« le système traite les données ») et se retrouver éloignés si le contexte environnant diffère.

Mon coffre utilise le modèle potion-base-8M de Model2Vec : 7,6 millions de paramètres produisant des embeddings à 256 dimensions.³ Le modèle est distillé à partir d’un plus grand transformer de phrases (bge-base-en-v1.5) et atteint environ 90 % des performances de all-MiniLM-L6-v2 tout en fonctionnant comme un modèle statique — des ordres de grandeur plus rapide sur CPU comme sur GPU. Chacun des 49 746 chunks de mon coffre devient un point dans un espace à 256 dimensions.

256 dimensions sont impossibles à visualiser directement. Les techniques de réduction de dimensionnalité comme UMAP projettent la structure de haute dimension en 2D ou 3D tout en préservant les voisinages locaux.⁴ Les points proches en 256 dimensions restent proches en 3 dimensions. La structure globale est approximative, mais les clusters sont réels.

Trois topologies de la connaissance

L’exploration par Kat des embeddings de notes Obsidian a identifié trois topologies de connaissance distinctes.¹ Chaque topologie reflète une structure intellectuelle différente, et chacune présente des modes de défaillance différents.

Centralisée : une idée centrale connectant tout

Dans une topologie centralisée, la plupart des notes se connectent à travers un seul thème dominant. L’espace d’embeddings montre un cluster dense au centre avec de fins tentacules s’étendant vers l’extérieur. Un développeur qui écrit exclusivement sur React verrait cette topologie : React est le nœud central, et chaque note sur les tests, la gestion d’état, le déploiement et les outils s’y connecte.

Force : Expertise approfondie dans le domaine central. La recherche fonctionne bien car la plupart des requêtes atterrissent dans le même voisinage.

Mode de défaillance : Fragilité. Si le thème central devient obsolète (changement de carrière, disparition d’une technologie), toute la structure de connaissances perd son principe organisateur. Les notes qui n’ont de sens qu’en relation avec le centre deviennent orphelines.

Décentralisée : des pôles thématiques en clusters

Dans une topologie décentralisée, les notes forment plusieurs clusters distincts reliés par des notes-ponts. Mon coffre présente cette topologie avec trois pôles dominants :

Les 22 % restants se répartissent entre Inspiration, Productivité, Science et catégories plus restreintes.

Force : Résilience. La perte d’un cluster ne détruit pas les autres. Les connexions interdisciplinaires se forment aux frontières entre clusters, générant les idées les plus novatrices.

Mode de défaillance : Fragmentation. Si les notes-ponts entre clusters sont trop minces, les clusters deviennent des silos intellectuels. Mon coffre possède un pont ténu entre Design et Claude Code (notes sur la conception d’interfaces d’agents, patterns d’interfaces de prompts) mais presque aucun pont entre Design et Développement brut (les notes sur l’architecture backend se connectent rarement au design visuel). Ce vide est un angle mort : je pense au design et je pense à l’ingénierie backend, mais je pense rarement aux deux ensemble.

Distribuée : des arêtes étiquetées par relations

Dans une topologie distribuée, les connexions entre notes portent des étiquettes sémantiques décrivant comment les idées sont liées. L’implémentation de Kat utilisait un LLM pour générer des étiquettes d’arêtes entre notes voisines.¹ Au lieu d’une simple proximité anonyme, chaque connexion porte une description : « contredit », « prolonge », « fournit une preuve pour », « s’applique dans un domaine différent ».

Force : Navigabilité. Une topologie distribuée répond non seulement à « qu’est-ce qui est lié ? » mais aussi à « comment est-ce lié ? ». L’étiquetage permet un raisonnement d’ordre supérieur : trouver des notes qui contredisent une thèse, pas seulement des notes qui la mentionnent.

Mode de défaillance : Coût. La génération d’étiquettes d’arêtes pour chaque paire de connexions croît de façon quadratique. Pour les 49 746 chunks de mon coffre, un étiquetage exhaustif nécessiterait environ 1,2 milliard d’appels LLM. Les implémentations pratiques n’étiquettent que les arêtes au sein d’un seuil de similarité.

Transitions de phase : quand la simplification brise la structure

Pesce, He et Caldarelli ont étudié les transitions de phase dans l’élagage des réseaux de neurones et ont découvert un seuil critique : les réseaux présentent « une transition d’une phase coopérative et fonctionnelle vers une phase désordonnée avec un effondrement des performances ».² En dessous du seuil, la suppression de connexions affecte à peine le fonctionnement. Au seuil, le fonctionnement s’effondre brutalement. La transition suit des lois d’échelle cohérentes avec un comportement critique de second ordre — les mêmes mathématiques qui décrivent la fonte de la glace en eau.

Le parallèle avec la curation des connaissances est direct. Mon pipeline de scoring de signaux a réduit l’Inbox de 14 771 à 5 886 notes grâce à un seuil de pertinence. Les mêmes dynamiques de contexte composé qui font que la mémoire des agents accumule de la valeur s’appliquent ici : la valeur de chaque note dépend de ses connexions, pas uniquement de son contenu. La réduction a amélioré la qualité de recherche : moins de résultats peu pertinents, des clusters plus resserrés, une récupération plus rapide. Mais des signaux ont-ils été perdus ? La simplification a-t-elle franchi un seuil de transition de phase ?

La recherche sur l’élagage suggère que la réponse dépend de la connectivité, pas de la quantité. Supprimer des nœuds isolés (notes sans voisins sémantiques) a un impact négligeable sur le fonctionnement du réseau. Supprimer des nœuds-ponts (notes qui connectent des clusters autrement séparés) peut effondrer la structure même si les notes supprimées semblent individuellement peu importantes.

Mon pipeline de triage a relevé le seuil de pertinence de 0,30 à 0,40. La réduction de 60 % de la taille de l’Inbox a été mesurée en nombre. Je n’ai pas mesuré l’impact sur la topologie. Une stratégie de curation consciente des transitions de phase devrait :

1. Identifier les notes-ponts avant le filtrage (notes avec une centralité d’intermédiarité élevée dans le graphe de similarité)
2. Exempter les notes-ponts du filtrage par pertinence, quel que soit leur score individuel
3. Surveiller les métriques de connectivité des clusters après chaque passe de curation
4. Alerter lorsqu’une étape de curation réduit la densité des ponts inter-clusters en dessous d’un seuil

# 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

Diagnostiquer votre topologie de connaissance

Nul besoin de 15 000 notes pour analyser votre topologie de connaissance. Toute collection de 100 notes ou plus avec des embeddings révélera une structure. Si vous utilisez Obsidian comme infrastructure IA, vous disposez déjà de la matière première — les dix-sept mille signaux de mon coffre ont commencé comme de simples captures quotidiennes. Trois questions diagnostiques :

1. Combien de clusters existent ?

Exécutez k-means ou DBSCAN sur vos embeddings et comptez les clusters distincts. Moins de 3 suggère une topologie centralisée. Entre 3 et 8 suggère une topologie décentralisée. Plus de 8 peut indiquer soit une topologie véritablement distribuée, soit une curation insuffisante (beaucoup de clusters signifie beaucoup de sujets, ce qui peut signifier aucune profondeur dans aucun d’entre eux).

2. Quelle est la densité des ponts ?

Pour chaque paire de clusters, comptez les notes dont les plus proches voisins se trouvent dans les deux clusters. Une densité de pont inférieure à 2 % de la taille du plus petit cluster indique un silo potentiel. Mon pont Design-vers-Développement est d’environ 1,4 % — en dessous du seuil, ce qui confirme l’angle mort observé.

3. Quel pourcentage est orphelin ?

Une note orpheline n’a aucun voisin dans un seuil de similarité cosinus (typiquement 0,7). Les notes orphelines ne sont pas nécessairement mauvaises — elles peuvent représenter des idées véritablement nouvelles. Toutefois, un taux d’orphelins supérieur à 15 % suggère soit des captures incohérentes (notes qui ne correspondent pas à votre domaine de connaissance), soit des problèmes de qualité des embeddings.

Taux d’orphelins de mon coffre : environ 8 %. La plupart des orphelins sont des captures brutes de l’Inbox qui n’ont pas été transformées en notes structurées. Le taux d’orphelins descend à 3 % en excluant l’Inbox, ce qui indique que les notes traitées s’intègrent bien dans la topologie existante.

Ce que les clusters révèlent

La visualisation ci-dessus utilise 500 chunks échantillonnés aléatoirement depuis mon coffre. Les clusters correspondent à de véritables quartiers intellectuels.

Le pôle IA & ML (26 % des chunks) est le cluster le plus dense. Architecture Claude Code, patterns de conception d’agents, articles de recherche LLM et techniques de prompt engineering forment un voisinage compact. La densité reflète le volume : je lis et capture plus de contenu IA/ML que dans toute autre catégorie. La densité crée aussi un avantage en qualité de recherche — les requêtes dans ce domaine renvoient des résultats très pertinents car l’espace d’embeddings est bien peuplé.

Le pôle Design (14 %) se situe à distance de l’IA & ML. Systèmes typographiques, science de la couleur, patterns de composants UI et références de design visuel forment leur propre cluster. La séparation est appropriée : le design et l’ingénierie IA utilisent des vocabulaires différents, des cadres de raisonnement différents et des critères d’évaluation différents. Néanmoins, la séparation signifie aussi que des requêtes comme « comment formater la sortie d’un agent pour une revue développeur » tombent dans le vide entre les deux clusters, renvoyant des résultats d’un côté ou de l’autre mais rarement de l’intersection.

Le pôle Développement (10 %) chevauche davantage l’IA & ML que le Design. Les patterns FastAPI, la conception de bases de données et l’architecture SwiftUI partagent un vocabulaire conceptuel avec les notes d’ingénierie IA (les deux traitent de code, d’architecture, de tests). Ce chevauchement de vocabulaire produit une zone de mélange où cohabitent les notes DevOps-pour-agents et infrastructure-pour-IA.

Le halo Inbox (28 %) entoure le tout. Captures brutes, signaux non triés et favoris non traités forment un nuage diffus avec de faibles connexions aux clusters établis. Le pipeline de scoring de signaux qui a réduit l’Inbox de 14 771 à 5 886 notes a éliminé principalement de ce halo : des notes avec une faible similarité avec tout cluster établi.

Le cluster Inspiration (6 %) occupe une position entre Design et Inbox. Références de typographie cinétique, études de motion design et captures d’art visuel forment un voisinage lâche. Le cluster existe parce que je capture de l’inspiration visuelle de manière régulière mais transforme rarement ces captures en notes structurées. Le cluster révèle un pattern : je consomme de l’inspiration visuelle largement mais produis du travail de design de manière restreinte. L’écart entre consommation et production est visible dans la topologie sous la forme d’un cluster avec une forte densité entrante (captures) mais de faibles connexions sortantes (notes qui s’appuient sur l’inspiration).

Les ponts inter-clusters sont les caractéristiques les plus intéressantes. Le pont le plus fin relie Design et Développement : environ 1,4 % des notes du plus petit cluster ont des plus proches voisins dans les deux clusters. À comparer avec le pont IA-vers-Développement à 8,3 %, qui reflète la part de mon travail de développement impliquant l’infrastructure IA. La densité des ponts prédit où émerge le travail novateur. Mon article boids-to-agents est né d’une note-pont qui connectait la recherche sur le comportement émergent (cluster IA & ML) avec l’implémentation d’algorithmes de flocking (cluster Développement). Sans ce pont, ces deux corpus de notes n’auraient jamais pu entrer en collision.

La topologie façonne aussi la qualité de récupération. Le récupérateur hybride qui alimente la recherche de mon coffre utilise à la fois BM25 (correspondance par mots-clés) et la similarité vectorielle — mais son efficacité dépend de la structure sous-jacente des clusters. Les requêtes qui atterrissent dans des clusters denses renvoient des résultats précis ; les requêtes qui tombent entre les clusters ont besoin du recours BM25 pour combler le fossé.

Une seconde base d’embeddings coexiste avec le coffre : la base de recherche de la toolchain, avec 4 518 chunks répartis sur 653 fichiers.⁵ La topologie de la toolchain est radicalement différente : un unique cluster dense (configuration Claude Code) avec de petits clusters satellites pour les tests, les hooks et les skills. La topologie monoculture fonctionne pour une toolchain parce qu’une toolchain a un objectif unique. Un coffre de connaissances avec une topologie monoculture serait un signal d’alerte.

Remodeler votre topologie

La topologie n’est pas figée. Quatre actions délibérées remodèlent la structure de connaissances.

Écrivez des notes-ponts. Si deux clusters manquent de connexions, rédigez des notes qui relient explicitement les concepts entre eux. Mon pont Design-vers-IA est ténu parce que j’écris rarement sur la conception d’interfaces d’agents. Une note intitulée « Patterns UX pour la sortie d’agents » qui cite à la fois des principes de design et de la recherche en architecture d’agents créerait un point de pont.

Détectez les orphelins. Lancez un scan mensuel des orphelins et décidez : intégrer, archiver ou supprimer. Les notes orphelines qui représentent des idées naissantes devraient être connectées par des notes-ponts aux clusters existants. Les notes orphelines qui représentent des références ponctuelles peuvent être archivées.

Surveillez après la curation. Avant et après toute curation en masse (suppression, archivage, filtrage), mesurez la connectivité des clusters. Si la densité des ponts inter-clusters diminue, la curation a supprimé des notes-ponts qui auraient dû être préservées.

Lisez aux frontières. Les lectures les plus précieuses ne se trouvent pas au cœur de votre cluster le plus dense. Elles se trouvent aux lisières entre clusters. Un article qui fait le pont entre ingénierie IA et design visuel générera davantage de connexions novatrices qu’un énième article approfondissant le cluster IA déjà dense.

Points clés

• Les espaces d’embeddings donnent une forme aux bases de connaissances. Cette forme révèle la topologie intellectuelle : où vous concentrez votre attention, où vous l’évitez, et où les idées se connectent entre domaines.
• Trois topologies ont des modes de défaillance différents. La centralisée est fragile. La décentralisée se fragmente sans notes-ponts. La distribuée est coûteuse à maintenir mais offre la navigation la plus riche.
• Les transitions de phase rendent la curation non linéaire. Supprimer des notes en dessous d’un seuil affecte à peine la structure. Au seuil, le fonctionnement s’effondre. Les notes-ponts doivent être identifiées et protégées avant toute curation en masse.
• Le halo Inbox est la frontière de curation. Les captures brutes forment un nuage diffus autour des clusters établis. Le scoring de signaux filtre le halo, mais la topologie révèle si le filtrage a préservé ou détruit les connexions-ponts.
• Lisez aux frontières. Les notes à plus forte valeur ajoutée connectent les clusters, elles ne les approfondissent pas. La détection d’orphelins et les métriques de densité de ponts guident les priorités de lecture.

FAQ

Références