La plupart des gens utilisent l'IA comme un distributeur automatique de réponses.
Téléchargez un document. Posez une question. Obtenez une réponse. Fermez l'onglet. Le lendemain, téléchargez le même document. Posez une question légèrement différente. Regardez le modèle repartir de zéro, comme si la veille n'avait jamais existé.
C'est le schéma par défaut de la « productivité IA » aujourd'hui. C'est magique les premières fois, car le système peut résumer, expliquer et extraire des informations de presque tout ce que vous lui donnez. Mais après quelques semaines, la magie commence à sembler étrangement jetable. Vous ne construisez pas de connaissances. Vous louez de brefs éclats d'intelligence.
Le problème n'est pas que les modèles sont trop faibles. Le problème est que le flux de travail n'a pas de mémoire qui s'accumule.
Andrej Karpathy a décrit un meilleur schéma : utiliser les LLM pour construire et maintenir des bases de connaissances personnelles. Pas seulement un dossier de PDF téléchargés. Pas seulement un chatbot sur des documents. Un wiki persistant, structuré et interconnecté qu'un LLM met à jour au fil du temps.
La partie importante n'est pas le wiki. Nous avons des wikis depuis des décennies.
La partie importante est la maintenance.
C'est la pièce manquante qui a tué presque tous les systèmes de « deuxième cerveau » avant l'IA. Les gens aiment l'idée d'une base de connaissances personnelle. Ils aiment les graphes Obsidian, les diagrammes Zettelkasten, les dossiers PARA, les notes taguées, les backlinks, les notes persistantes, les tableaux de bord et tout le reste. Mais après l'enthousiasme initial, la même chose se produit généralement : le système devient un autre système à maintenir.
Vous découpez des articles mais ne les résumez pas. Vous créez des notes mais ne les reliez pas. Vous taguez les choses de manière incohérente. Vous oubliez de mettre à jour les anciennes affirmations lorsque de nouvelles informations arrivent. Vous créez une belle structure, puis l'évitez lentement parce que chaque interaction crée plus de comptabilité.
Le deuxième cerveau échoue parce qu'il a encore besoin d'un premier cerveau pour nettoyer après lui.
Le schéma du wiki LLM de Karpathy change la donne. Il traite la base de connaissances moins comme un carnet personnel et plus comme une base de code. Les sources brutes entrent. Le LLM les lit, en extrait les parties importantes, crée ou met à jour des pages markdown, maintient des références croisées, suit les contradictions et tient les index à jour. L'humain n'écrit pas le wiki à la main. L'humain organise les sources, pose des questions, examine les résultats et décide de ce qui compte.
Publication d'Andrej Karpathy
https://x.com/karpathy/status/2039805659525644595
C'est une division du travail bien plus intéressante.
De la récupération à la connaissance cumulative
La plupart des flux de travail de documents IA aujourd'hui sont basés sur la récupération. Vous téléchargez des fichiers, le système les découpe, intègre les morceaux et recherche les passages pertinents lorsque vous posez une question. C'est l'idée de base derrière de nombreux systèmes RAG, et c'est utile. Cela permet au modèle de répondre à des questions sur du matériel qui n'est pas dans ses données d'entraînement.
Mais la récupération a un plafond.
Lorsque vous posez une question, le système recherche, extrait une poignée de fragments dans le contexte et génère une réponse. La réponse peut être bonne, mais le travail disparaît généralement lorsque la conversation se termine. La synthèse ne fait pas automatiquement partie d'une structure durable. La question suivante démarre un autre cycle de récupération.
C'est bien pour des questions ponctuelles. C'est faible pour l'apprentissage, la recherche, l'écriture et la stratégie, où l'objectif est que la compréhension s'accumule.
Un wiki maintenu par LLM fonctionne différemment. Il n'attend pas le moment de la requête pour tout synthétiser à partir de zéro. Il compile les connaissances à l'avance.
Lorsque vous ajoutez une nouvelle source, le LLM la lit et l'intègre dans le système existant. Un article peut mettre à jour une page de concept. Un profil d'entreprise peut réviser une page de concurrent. Une transcription peut ajouter des preuves à un point douloureux client. Un nouvel article peut contredire un résumé plus ancien, donc le wiki signale la tension au lieu de l'enterrer silencieusement dans une pile de documents.
La question passe de « Puis-je récupérer le bon paragraphe ? » à « Ma base de connaissances est-elle devenue plus intelligente parce que j'ai ajouté cette source ? »
C'est le vrai changement : la connaissance devient cumulative.
Les trois couches
L'architecture est si simple que sa simplicité est facile à manquer.
La première couche est celle des sources brutes. Ce sont les matériaux originaux : articles, PDF, notes, transcriptions, articles, clips web, images, dépôts, ensembles de données et tout ce que vous voulez que le système connaisse. Cette couche doit être traitée comme immuable. L'IA peut la lire, la citer et la résumer, mais elle ne doit pas réécrire les preuves.
La deuxième couche est le wiki. C'est un répertoire de fichiers markdown maintenu par le LLM. Il peut inclure des résumés de sources, des pages de concepts, des pages d'entités, des chronologies, des comparaisons, des questions ouvertes, des index et des briefs de recherche. C'est la couche compilée. C'est là que le matériel brut devient une connaissance utilisable.
La troisième couche est le schéma. C'est l'ensemble d'instructions qui indique au LLM comment se comporter en tant que mainteneur. Quels dossiers existent ? Qu'est-ce qui compte comme un résumé de source ? Comment les citations doivent-elles fonctionner ? Quand doit-il créer une nouvelle page de concept plutôt que d'en mettre à jour une ancienne ? Comment les contradictions doivent-elles être enregistrées ? À quoi ressemble un contrôle de santé ?
Le schéma est ce qui transforme un chatbot en opérateur.
Sans lui, vous avez un modèle qui improvise. Avec lui, vous avez quelque chose de plus proche d'un chercheur junior qui connaît le style de la maison, le système de classement et les rituels de maintenance.
Obsidian s'intègre naturellement dans ce flux de travail car c'est déjà un environnement markdown local avec des backlinks, des vues graphiques et une navigation rapide. Le cadre de Karpathy est utile : Obsidian est l'IDE, le LLM est le programmeur et le wiki est la base de code.
Cette métaphore compte. Les bases de code ne sont pas précieuses parce qu'elles contiennent des fichiers. Elles sont précieuses parce que les fichiers suivent des conventions, se référencent les uns les autres, peuvent être refactorisés, peuvent être lintés et peuvent être améliorés sans recommencer à zéro. Une base de connaissances sérieuse devrait fonctionner de la même manière.
L'humain ne devrait pas être le commis
L'ancien modèle de gestion des connaissances personnelles supposait silencieusement que l'humain ferait tout.
Vous lisez la source. Vous surlignez. Vous résumez. Vous choisissez le dossier. Vous ajoutez des tags. Vous créez des liens. Vous vous souvenez qu'une note plus ancienne doit maintenant être mise à jour. Vous remarquez que deux sources ne sont pas d'accord. Vous gardez les index propres. Vous décidez si une note orpheline doit être supprimée, fusionnée ou connectée.
C'est exactement le genre de travail qui semble productif la première semaine et insupportable au troisième mois.
C'est aussi exactement le genre de travail pour lequel les LLM sont bons.
Ils ne se lassent pas des structures répétitives. Ils n'ont pas peur de mettre à jour quinze fichiers en une seule passe. Ils peuvent rechercher des affirmations obsolètes, des backlinks manquants, des concepts dupliqués, des noms incohérents et des contradictions non résolues. Ils peuvent transformer une source désordonnée en cinq artefacts utiles : un résumé, une liste d'affirmations, une mise à jour de page d'entité, une mise à jour de page de concept et une question qui mérite d'être étudiée plus tard.
L'humain devrait rester plus proche du jugement.
Quelles sources appartiennent au système ? Quelles affirmations sont réellement importantes ? Quelle question vaut-il la peine de poser ensuite ? Quelle synthèse semble vraie, utile, surprenante ou erronée ? Que faut-il transformer en article, mémo, présentation, décision, idée de produit ou direction de recherche ?
C'est la partie où le goût compte.
Le LLM devrait faire le travail de commis de la connaissance. L'humain devrait faire le travail éditorial du sens.
À quoi cela ressemble en pratique
Imaginez que vous faites des recherches sur un marché. Vous commencez avec quelques rapports d'analystes, des articles de blog de concurrents, des entretiens clients, des pages produits et des transcriptions d'appels commerciaux. Dans l'ancien flux de travail, cela deviendrait une pile de documents. Peut-être poseriez-vous des questions à un chatbot à leur sujet. Peut-être garderiez-vous un tableur. Peut-être finiriez-vous par écrire un mémo qui devient obsolète dès que de nouvelles informations arrivent.
Dans le flux de travail du wiki LLM, chaque nouvelle source met à jour la carte vivante.
Une annonce d'un concurrent met à jour la page du concurrent. Un appel client met à jour une page sur les objections, les points douloureux, les déclencheurs d'achat et le langage que les clients utilisent réellement. Un rapport de marché met à jour les pages de concept autour des prix, de la réglementation, de l'adoption ou de la distribution. Une nouvelle contradiction est enregistrée au lieu d'être ignorée. Une requête utile peut devenir un brief sauvegardé sur lequel les futures requêtes peuvent s'appuyer.
Après quelques semaines, le système n'est plus seulement un magasin de documents. C'est un environnement de recherche.
Le même schéma fonctionne pour les écrivains. Ingérez vos essais passés, notes, interviews, articles sauvegardés et brouillons. Le wiki peut suivre vos arguments récurrents, exemples, affirmations, références et idées inachevées. Lorsque vous vous asseyez pour écrire, vous pouvez demander ce que vous avez déjà dit sur un sujet, quels exemples sont les plus forts, où votre pensée a changé et quel angle vous n'avez pas encore exploré.
Cela fonctionne pour l'auto-éducation. Ingérez des cours, des lectures, des exercices et des articles. Le wiki peut maintenir des pages de concept qui évoluent à mesure que le cours devient plus difficile. Il peut expliquer comment la semaine sept révise la semaine deux. Il peut générer des fiches de révision, identifier les points faibles et transformer la confusion en un plan d'étude.
Cela fonctionne pour les équipes. Nourrissez-le de notes de réunion, de fils Slack, d'appels clients, de documents de planification, de mémos stratégiques, de tickets de support et de post-mortems. Le wiki peut maintenir des pages de projet, des pages client, des journaux de décisions produits, des pages concurrent et des thèmes de risque récurrents. L'avantage n'est pas seulement la recherche. L'avantage est que l'organisation cesse de perdre le contexte dans les interstices entre les outils.
Dans chaque cas, le schéma est le même : les sources sont collectées, les connaissances sont compilées, les questions produisent des résultats et les résultats utiles sont réintégrés dans le système.
L'exploration s'additionne.
Le contrôle de santé est le produit
L'une des parties les plus sous-estimées du schéma de Karpathy est le linting.
Un système de notes normal se dégrade silencieusement. Les liens se cassent. Les pages se dupliquent. Les résumés deviennent obsolètes. Les affirmations se contredisent. Les sources importantes restent non traitées. Vous ne remarquez la dégradation que lorsque vous avez besoin du système pour un vrai travail et que vous ne lui faites plus confiance.
Un wiki maintenu par LLM peut être vérifié.
Vous pouvez lui demander de trouver des pages orphelines. Vous pouvez lui demander d'identifier des concepts dupliqués. Vous pouvez lui demander quelles affirmations ont besoin de citations. Vous pouvez lui demander où les sources plus récentes entrent en conflit avec les plus anciennes. Vous pouvez lui demander quelles pages sont trop vagues, trop longues, trop minces ou manquent de références croisées évidentes.
Cela semble mineur, mais c'est la différence entre une pile de notes et une base de connaissances opérationnelle.
Le contrôle de santé n'est pas une fonctionnalité secondaire. C'est le mécanisme qui maintient la confiance en vie.
Une base de connaissances à laquelle vous ne faites pas confiance n'est qu'une autre archive. Une base de connaissances qui peut s'inspecter elle-même, expliquer ses faiblesses et proposer des réparations commence à ressembler à une infrastructure.
Pourquoi le Markdown est important
Le choix modeste du markdown est plus important qu'il n'y paraît.
Les fichiers Markdown sont portables. Ils peuvent vivre dans un dossier normal. Ils peuvent être ouverts dans Obsidian, édités par n'importe quel éditeur de texte, versionnés avec git, recherchés avec des outils en ligne de commande, rendus en sites web, transformés en présentations ou traités par des scripts.
Cela empêche le système de devenir une boîte noire.
De nombreux produits IA veulent absorber vos connaissances dans une interface propriétaire. Cela peut être pratique, mais cela rend également votre compréhension dépendante de la base de données, de la tarification, de la feuille de route et du bouton d'exportation de quelqu'un d'autre.
Un wiki markdown local est ennuyeux de la meilleure façon possible. Il est inspectable. Il est durable. Il peut être sauvegardé. Il peut être comparé. Vous pouvez voir ce que le modèle a changé. Vous pouvez annuler les mauvaises modifications. Vous pouvez construire de petits outils autour de lui.
Pour un travail de connaissance sérieux, une infrastructure ennuyeuse gagne.
Le produit qui veut exister
Karpathy a décrit cela comme une collection de scripts bricolés, mais cela pointe vers une catégorie de produits beaucoup plus large.
Le prochain grand outil de connaissance ne ressemblera probablement pas à un chatbot avec un bouton de téléchargement. Il ressemblera davantage à un environnement de recherche natif IA : stockage local en premier, ingestion structurée, synthèse consciente des citations, maintenance automatique, sorties visuelles, contrôles de santé, historique des versions et flux de travail agentiques capables d'opérer sur l'ensemble de la base de connaissances.
Il ne se contentera pas de répondre aux questions. Il maintiendra le contexte qui rend de meilleures questions possibles.
Cette distinction compte. Un chatbot est réactif. Une base de connaissances maintenue est cumulative. Un chatbot vous donne une réponse. Un wiki donne à votre futur vous un meilleur point de départ.
C'est aussi pourquoi l'expression « deuxième cerveau » pourrait enfin devenir moins embarrassante. Pendant des années, elle signifiait souvent un classeur aspirant : un endroit où vous mettez des choses dans l'espoir que votre futur vous les organisera. Mais un vrai deuxième cerveau ne devrait pas seulement stocker des souvenirs. Il devrait préserver la structure, mettre à jour les croyances, faire surface des connexions et rendre la pensée accumulée plus facile à réutiliser.
Jusqu'à présent, cela nécessitait trop de discipline humaine.
Maintenant, la maintenance peut être déléguée.
Le vrai flux de travail
Le flux de travail pratique est presque décevamment simple.
Collectez les sources brutes. Laissez le LLM les compiler en un wiki markdown structuré. Utilisez Obsidian ou une autre interface markdown pour parcourir le résultat. Posez des questions au wiki. Sauvegardez les réponses substantielles dans le wiki. Effectuez des contrôles de santé périodiques. Répétez.
Le volant d'inertie est ce qui compte.
Chaque source améliore le wiki. Chaque bonne question crée un artefact. Chaque artefact devient un contexte futur. Chaque contrôle de santé améliore la fiabilité. Au fil du temps, le système développe une forme qui reflète ce que vous étudiez, écrivez, construisez et décidez réellement.
C'est très différent de demander à une IA de résumer un PDF.
C'est plus proche d'avoir un assistant de recherche dont le travail principal n'est pas de produire des réponses finales, mais de maintenir votre espace de travail intellectuel cohérent.
C'est peut-être l'une des utilisations les plus efficaces des LLM actuels. Ne pas remplacer votre pensée. Ne pas prétendre tout savoir. Ne pas générer du texte jetable à l'infini. Juste faire le travail de maintenance qui permet à la pensée sérieuse de s'accumuler.
Le point à retenir
L'ancien deuxième cerveau était un système de stockage avec un problème de discipline. Il vous donnait un endroit pour tout mettre, mais il dépendait toujours de votre futur vous pour organiser, connecter, mettre à jour et nettoyer. C'est pourquoi tant de systèmes de prise de notes commencent comme de belles cartes et finissent comme des archives silencieuses.
Le wiki LLM inverse le modèle. Les sources brutes restent la couche de preuves. Le wiki markdown devient la couche compilée. Le schéma donne à l'IA des règles pour savoir comment le maintenir. Les contrôles de santé maintiennent le système digne de confiance. Obsidian ou toute autre interface markdown devient l'endroit où vous inspectez, questionnez et réutilisez le travail.
RAG peut vous aider à répondre à une question à partir d'une pile de documents. Un wiki maintenu par LLM change le point de départ pour chaque question future.
C'est l'idée centrale. La valeur n'est pas seulement des résumés plus rapides, des notes plus propres ou des graphiques plus jolis. La valeur est le contexte accumulé. Chaque source, chaque requête, chaque contradiction et chaque résultat utile peut renforcer le système au lieu de disparaître dans un autre fil de discussion.
Le rôle humain devient plus étroit et plus précieux : choisir de meilleures entrées, poser des questions plus précises, contester les synthèses faibles et décider de ce qui compte. Le rôle de l'IA devient répétitif et structurel : résumer, lier, réviser, citer, linter et maintenir.
C'est ainsi que le travail de connaissance commence à s'accumuler.
Votre deuxième cerveau n'a pas besoin de plus de dossiers.
Il a besoin de quelqu'un pour le maintenir.
Et pour la première fois, ce quelqu'un n'a pas besoin d'être vous.
Si vous avez aimé cet article, laissez-moi un follow pour plus de conseils sur l'IA et Obsidian : @Degen_calls_sol
