Une base de connaissances en fichiers texte.
Ce qui rend un corpus exploitable par une IA n'est ni son volume ni le logiciel qui l'héberge. C'est qu'il soit en texte clair, découpé en unités qui se tiennent, et relié explicitement. Mesuré sur le nôtre.
Ce qu'Obsidian est vraiment
Obsidian n'est pas une application de prise de notes qui stocke vos données quelque part. C'est un dossier de fichiers texte sur votre disque, que le logiciel se contente d'afficher. Chaque note est un fichier au format Markdown, lisible dans n'importe quel éditeur, versionnable, copiable, sauvegardable comme n'importe quel document.
Cette propriété paraît anodine et elle change tout. Il n'y a pas de base de données propriétaire à exporter, pas d'interface de programmation à demander, pas de limite de requêtes, pas de format à rétroconcevoir le jour où l'éditeur change de modèle économique. Le jour où vous voulez faire autre chose de vos notes, elles sont déjà dans le seul format que tout sait lire.
Pourquoi c'est le bon substrat pour une IA
Un système qui doit répondre à partir de vos documents commence toujours par le même travail ingrat : aller les chercher, les convertir, en extraire le texte, deviner leur structure. Sur un espace collaboratif d'entreprise, cette étape occupe l'essentiel du projet, et elle produit une copie qui se désynchronise dès le lendemain.
Avec des fichiers texte, cette étape n'existe pas. Le contenu est déjà du texte, la structure est déjà marquée par les titres, et la mise à jour est le fichier lui-même. Un système de recherche documentaire lit le dossier, rien d'autre.
Le versionnage vient en prime. Un dossier de fichiers texte se met sous gestion de versions, ce qui donne deux choses rares : l'historique de qui a écrit quoi et quand, et surtout la possibilité de ne traiter que ce qui a changé. Sur un corpus qui vit, retraiter uniquement les différences plutôt que l'ensemble est la différence entre un traitement quotidien et un traitement mensuel.
Le graphe est posé à la main, pas deviné
C'est la propriété la plus sous-estimée. Dans ces outils, une note en cite une autre par un lien explicite. Sur un coffre de travail correctement tenu, la densité que nous constatons est de l'ordre de cinq liens par note, avec près de neuf notes sur dix reliées à au moins une autre.
Ces liens sont une information que personne n'a besoin de reconstituer. Un système de recherche documentaire classique rapproche les documents par ressemblance statistique, ce qui marche mal dès que deux textes parlent de la même chose avec des mots différents, ou que deux textes emploient les mêmes mots pour des choses différentes. Un lien posé par la personne qui a écrit la note dit quelque chose que la ressemblance ne dira jamais : que ces deux notes ont un rapport, et lequel.
Concrètement, cela autorise une recherche en deux temps : trouver la note la plus pertinente, puis suivre ses liens pour ramener son voisinage. Le résultat est plus juste et nettement moins volumineux qu'une recherche par similarité qui ratisse large pour ne rien manquer.
Le vrai coût n'est pas le stockage, c'est le contexte
C'est la question qui décide de la faisabilité d'un projet, et elle est presque toujours posée à l'envers. Stocker des notes ne coûte rien. Ce qui coûte, c'est ce qu'on envoie au modèle à chaque question.
| Ce qu'on envoie pour répondre à une question | Tokens |
|---|---|
| Une note bien découpée, valeur médiane | ≈ 1 200 |
| Trois notes ciblées par la recherche | ≈ 3 600 |
| Le corpus entier, sur un coffre réel | ×71 |
Soixante et onze fois. Et le point important n'est pas la dépense : c'est que la version chère est aussi la moins fiable. La capacité d'un modèle à exploiter une information se dégrade selon la position de cette information dans un contexte chargé, et ce qui se trouve au milieu d'un très long ensemble est nettement moins bien utilisé que ce qui se trouve aux extrémités. Tout envoyer coûte davantage et répond moins bien.
C'est pour cette raison que l'argument commercial de la très grande fenêtre de contexte doit être reçu avec méfiance. Il vend une caractéristique du fournisseur de modèle comme si c'était une propriété du système, alors que la vraie question est la qualité de la sélection en amont. Nous détaillons ce point dans notre note sur l'IA bridée.
Le format se paie, à contenu identique
Le balisage compte lui aussi. Nous avons pris l'une de nos pages publiées et compté trois fois la même chose : la page telle qu'elle est servie, son article seul avec ses balises, et le texte nu.
| Le même contenu | Tokens |
|---|---|
| La page complète, telle que servie | 4 388 |
| L'article seul, balises comprises | 2 644 |
| Le texte nu | 2 012 |
La page entière coûte plus du double du texte qu'elle porte. Ce surcoût est du balisage, de la navigation et des métadonnées, c'est-à-dire du bruit pour un modèle. Sur un document bureautique ou un export d'espace collaboratif, la proportion est souvent pire, et personne ne la regarde.
Le Markdown se situe à l'autre extrémité : il conserve la structure utile, titres, listes, emphases, avec un balisage réduit à quelques caractères. C'est le format qui transporte le plus de sens par token.
Ce que cela impose à celui qui écrit
Un coffre bien tenu ne se décrète pas. Trois disciplines suffisent, et elles sont celles qui rendent la recherche documentaire efficace ensuite.
Une note traite un sujet et un seul. C'est ce qui permet de la ramener entière sans traîner du hors-sujet, et ce qui évite d'avoir à la découper artificiellement plus tard. Le titre annonce ce que la note contient, pas la catégorie à laquelle elle appartient : c'est souvent le titre qui décide qu'une note sera trouvée. Et les liens se posent en écrivant, pas dans une session de rangement qui n'a jamais lieu.
Une quatrième pratique fait plus de différence que les trois autres réunies : tenir une note d'index qui donne en une ligne le contenu de chacune des autres. C'est elle qui rend le premier tri possible sans rien lire d'autre, pour un coût de quelques centaines de tokens.
Ce que ce choix ne fait pas
Une méthode qui n'affiche aucune limite n'a pas été éprouvée. Celle-ci a quatre inconvénients, et ils comptent.
Un dossier de fichiers n'est pas un système multi-utilisateurs. Il n'y a pas de droits fins par document, pas d'édition simultanée confortable, pas de piste d'audit au sens d'un système de gestion documentaire. Pour un corpus qui doit être partagé par une organisation entière avec des habilitations différenciées, ce n'est pas le bon outil, et il faut assumer une architecture différente.
La qualité du graphe dépend entièrement de la discipline de ceux qui écrivent. Une densité de cinq liens par note n'est pas une propriété du logiciel, c'est une habitude entretenue. Un coffre négligé n'offre aucun des avantages décrits ci-dessus.
Le Markdown rend mal les tableaux complexes et les documents à mise en page contrainte. Une convention, un contrat ou un rapport formaté restent des documents bureautiques, et il faut les traiter comme tels. Enfin les fichiers sur un poste ne sont sauvegardés que si quelqu'un les sauvegarde, ce qui est une évidence jusqu'au jour où le disque s'arrête.
Ces limites délimitent un usage plutôt qu'elles ne le disqualifient : une base de connaissances de travail, tenue par une équipe restreinte, destinée à être interrogée. C'est exactement le cas où la différence de consommation mesurée plus haut décide qu'un projet est faisable ou non.
Sur la dégradation de l'exploitation d'une information selon sa position dans un contexte chargé, voir les travaux publiés sous le nom de « lost in the middle » (Liang et coll.).