L'argument de vente d'une base de connaissances entretenue par l'IA est assez bon pour que la plupart des gens arrêtent d'écouter dès l'argumentaire. Pointez un modèle vers vos notes, laissez-le rédiger les résumés et tenir les renvois à jour, et le travail d'entretien que les humains finissent toujours par abandonner se fait pour à peu près rien. Cette partie-là est réelle. Ce que personne ne met dans l'argumentaire, c'est la facture récurrente : chaque question à laquelle votre agent répond à partir de ce corpus coûte des jetons pour trouver la bonne page, et trouver est un problème différent de celui d'écrire. Nous en faisons tourner une à l'interne. En juillet, nous avons arrêté de deviner sur la moitié « trouver » et nous l'avons mesurée.
Deux termes, simplement. Un second cerveau LLM, c'est un dossier de notes qu'un modèle rédige et entretient pour vous, de sorte que la synthèse se fait une fois plutôt qu'à chaque question. La recherche par index, ou l'index d'abord, veut dire que l'agent note un catalogue d'une ligne par sujet et choisit un fichier avant d'avoir le droit d'en ouvrir un, au lieu de chercher directement dans le corpus.
Le patron, en trois couches.
Andrej Karpathy a publié cette forme en avril 2026, et elle s'est répandue rapidement.[1] Plutôt que d'utiliser un modèle surtout pour écrire du code, pointez-le vers un dossier de notes markdown et laissez-le entretenir un wiki persistant et interrelié qui s'améliore à mesure que de nouvelles sources arrivent. Il rapporte faire tourner le sien à plus de 100 articles et plus de 400 000 mots. Le document reste délibérément abstrait sur la mécanique, ce qu'il vaut la peine de savoir avant d'essayer d'en bâtir quelque chose : il communique un patron, pas une spécification.
Les parties qui comptent sont simples à en être ennuyantes, et cette simplicité porte la structure.
Tout ce qui précède est la moitié facile. Un modèle générera avec plaisir quatre cent mille mots de markdown interrelié, et dès qu'il l'a fait, vous possédez un corpus trop volumineux pour être lu et trop petit pour justifier une pile de recherche. C'est la position dans laquelle se trouvent réellement la plupart des gens quand ils nous demandent si ça valait la peine.
Ce que le retrieval coûte réellement.
Notre corpus, au moment de l'exécution, comptait environ 330 fichiers thématiques avec quelque 300 entrées d'index d'une ligne pointant vers eux. C'est loin de la taille qui nécessite une base de données vectorielle, ce qui est exactement ce qui rend la question intéressante : à cette taille, qu'est-ce que l'agent dépense réellement pour répondre à une question, et est-ce que la structure bat le simple fait de le laisser chercher ?
Nous avons fait tourner deux volets sur six questions réelles de l'espace de travail, avec des réponses vérifiables par fichier. Le volet de référence avait carte blanche : grep, glob, read, tout ce qu'il voulait. Le volet index d'abord exécutait un chemin déterministe avant toute chose, un script de 314 lignes sans embeddings et sans aucun appel de modèle nulle part dedans. Réduire la question à des mots-clés, noter chaque ligne d'index par fréquence inverse de document sans ouvrir un seul fichier, ouvrir le meilleur fichier, en extraire la meilleure section, suivre au plus un renvoi. Puis répondre à partir de ça. Les jetons marginaux sont mesurés contre un agent témoin qui ne fait rien, donc ce que vous voyez ci-dessous est le coût du retrieval, pas le coût d'exister.
Lisez la forme, pas le total. L'économie de 9,5 % est le chiffre le moins intéressant du graphique, et côté temps d'horloge, le chemin structuré était légèrement plus lent. Ce que le graphique montre réellement, ce sont deux distributions différentes. La recherche libre est bimodale : économique sur les quatre questions où l'en-tête d'index chargé automatiquement nommait par hasard le bon fichier, puis 33k et quatre appels d'outils sur les deux où il fallait chasser. L'index d'abord n'a montré aucun second mode sur ces six questions. Chaque question, qu'elle soit de classe chasse ou non, s'est logée entre 24 371 et 25 923 jetons et presque toujours en un seul appel d'outil. Sur les deux questions de classe chasse, et deux questions, c'est tout ce que nous avons, l'économie dépassait 25 %.
Cette distinction compte plus qu'il n'y paraît, parce que l'échec coûteux dans le travail d'agent n'est presque jamais le cas moyen. C'est l'exécution qui erre, ouvre onze fichiers, remplit son contexte de quasi-correspondances, puis répond à partir d'une fenêtre dégradée. Un plafond sur le coût du retrieval vaut quelques centaines de jetons sur les questions faciles, ce qui est à peu près ce que ça a coûté ici : l'index d'abord a consommé quelques centaines de jetons de plus sur trois des six, et sa médiane s'est quand même logée légèrement sous la recherche libre.
L'index est l'actif. Le script est une lentille.
Voici la partie qu'on a d'abord ratée, et c'est la partie qui vaut la peine d'être volée. Les rondes un et deux de ce banc d'essai ont produit des ratés de retrieval. Chacun d'eux remontait à trois lignes d'index, et aucun n'était un bogue de notation. Les lignes étaient écrites dans le vocabulaire de la solution, et les questions arrivent dans le vocabulaire du symptôme. Un humain glisse par-dessus ce décalage sans le remarquer. Un moteur de notation lexical ne le peut pas.
La découverte de second ordre est celle qu'on n'attendait pas. Le volet de référence était déjà compétitif, et la raison, c'est qu'il avait le catalogue d'une ligne reconstruit chargé automatiquement dans son contexte. Après la réécriture, les deux volets ont arrêté de rater. Nous ne pouvons pas y mettre de chiffre : l'index d'avant réécriture avait déjà disparu du disque, donc comparer les rondes 1 et 2 à la ronde 3, c'est un avant-après entre rondes, pas une comparaison contrôlée. Le script est une lentille bon marché pour la longue traîne au-delà de ce que votre budget de contexte charge automatiquement. Si vous ne devez retenir qu'une seule chose de cette note, écrivez de meilleures lignes d'index. Vous pouvez ajouter la notation plus tard. Nous n'avons pas mesuré comment la valeur se répartit entre la réécriture de l'index et la couche de notation, et depuis que nous avons perdu l'index d'avant réécriture, nous ne pouvons plus le faire, alors considérez cet ordre comme notre jugement plutôt que comme un résultat.
Une limite de tout moteur de notation lexical vaut la peine d'être dite franchement, parce que c'est le cas que notre propre lectorat va rencontrer en premier. La notation IDF fait correspondre des mots, pas des sens. Une question posée en français ne fera pas remonter une ligne d'index écrite en anglais, et une question construite sur un synonyme du terme clé de la ligne d'index ne la fera pas remonter non plus. Si votre corpus ou votre équipe est bilingue, écrivez la ligne d'index dans les deux langues, ou acceptez qu'une partie de vos questions partent d'un raté. C'est le premier vrai argument en faveur des embeddings, et il arrive bien avant que la taille du corpus en devienne un.
Il faut résister à une lecture des chiffres. Nous ne prétendons pas à une amélioration de 9,5 % par rapport à un dispositif naïf. Notre propre mise en garde au moment de la mesure était que la vraie référence d'avant réécriture n'existait plus sur disque, parce que l'ancien index de 99 Ko avait déjà été remplacé. L'écart mesuré sous-estime ce que valait la réécriture et ne dit rien de ce qu'on observerait en partant d'un tas de notes non structuré.
Trois corpus, trois ensembles de problèmes.
Ce qui se retrouve dans les trois, c'est la partie intéressante.
Le système de production tout en haut de cette échelle, c'est le gbrain de Garry Tan, et sa propre note à ce sujet est la phrase la plus utile du dépôt : aucune des idées n'est nouvelle, la contribution, c'est de les livrer toutes ensemble.[4] Quatre de ses conventions ne coûtent rien à copier, et nous l'avons fait. Un seuil de notabilité, où une entité obtient une page à sa deuxième mention et non à la première, parce qu'une page inutile gaspille l'attention et dégrade la recherche pour tout le reste. Une séparation entre la synthèse réécrite en haut d'une page et les preuves datées en ajout seul en dessous, ce qui rend la désuétude mécanique plutôt qu'un jugement au cas par cas. La fusion de chronologie, où un événement touchant trois entités atterrit sur les trois pages. Et l'analyse des lacunes comme partie obligatoire de chaque réponse, pour que le système énonce ce qu'il ne sait pas au lieu de le camoufler.
Dans le fil d'adopteurs du gist original, deux témoignages méritent d'être repris avec leur palier de fiabilité accolé. Les deux sont autorapportés et aucun n'est vérifiable.[2] L'adopteur le plus cité, qui fait tourner environ 4 000 pages depuis six mois, dit que la dérive causée par des renvois mal mis à jour est le mode de défaillance principal, et que la passe de lint, dans ses propres mots, n'est pas optionnelle et tourne sur une minuterie. L'autre est la seule comparaison contrôlée que quiconque dans le fil affirme avoir menée : les pages estampillées « dérivé, à vérifier contre la source » ont rendu leur wiki déficitaire, parce que l'agent lit alors le wiki et la source, et paie deux fois. Leur conclusion, qu'on pense juste et qui va à l'encontre de la nuance que la plupart des gens mettraient : ou bien le wiki fait autorité au moment de la requête, ou bien il ne devrait pas exister.
Il y a un corollaire qui fait économiser du vrai argent. Si une page n'est que le miroir d'un petit fichier que l'agent pourrait déjà ouvrir, elle vaut moins que rien. Le patron rapporte exactement quand une page compresse des faits dispersés dans plusieurs sources en un seul endroit. Nous avons trouvé la même chose par l'autre bout : les agents lisent les documents en rafales et suivent rarement les renvois, donc une page autonome bat une page bien reliée.
Comment en démarrer une sans gaspiller un trimestre.
- Écrivez l'index avant d'écrire les pages.
Une ligne par sujet, dans les mots qu'utilisera une question future. Symptômes, texte d'erreur, la chose qui a brisé, le nom que quelqu'un va réellement taper. Pas le nom du correctif. C'est ça l'actif, et c'est la seule partie qu'une fonction de notation peut voir.
à faire · une ligne par sujet, dans le vocabulaire du symptôme - Commencez sans aucune infrastructure de retrieval.
À quelques centaines de pages, le catalogue chargé automatiquement plus la lecture directe des fichiers est une référence sérieuse, et la nôtre était difficile à battre. Ajoutez la notation lexicale quand le corpus dépasse ce que vous pouvez vous permettre de garder en contexte, et envisagez une base vectorielle quand il dépasse le moteur lexical. Nous nous attendrions à ce que la plupart des corpus d'entreprise n'atteignent jamais cette troisième étape, mais c'est une prédiction, pas quelque chose que nous avons mesuré sur un échantillon.
à faire · mériter chaque couche par une mesure - Décidez, par écrit, que le wiki fait autorité au moment de la requête.
Une page que l'agent doit revérifier contre une source est pire que pas de page du tout. La preuve de ça, c'est un témoignage d'adopteur invérifiable plus notre propre lecture de la mécanique, alors pondérez-la en conséquence. Si vous l'acceptez, ça implique une vraie norme éditoriale sur ce qui s'écrit et une vraie cadence de lint, pas une réserve estampillée dans le frontmatter.
à faire · aucune porte de sortie du type « à vérifier contre la source » - Mettez le lint sur un horaire, pas sur de bonnes intentions.
Liens brisés, pages orphelines, contradictions entre pages, affirmations devenues désuètes. C'est l'entretien que les humains abandonnent, ce qui est exactement la raison pour laquelle le patron fonctionne quand un modèle s'en charge. L'abandonner par une autre voie vous ramène au point de départ.
à faire · lint planifié, résultats révisés par une personne - Ne versez pas chaque bonne réponse dans le corpus.
Le patron original le suggère, et les praticiens qui en font tourner un depuis le plus longtemps s'y opposent. Les pages dérivées qui n'ajoutent aucune information nouvelle envasent le corpus et compliquent chaque recherche future. Appliquez un seuil de notabilité à la synthèse, de la même façon que vous en appliquez une aux entités.
à faire · une page doit compresser quelque chose, sinon elle n'existe pas - Mesurez votre propre pire cas avant de lui faire confiance.
Six questions avec des réponses vérifiables, deux volets, comptez les jetons et les appels d'outils. C'est l'affaire d'un après-midi. Vous cherchez une seule chose : si la traîne coûteuse existe, tout court.
à faire · mesurer la traîne, pas la médiane
Ce que ceci n'autorise pas.
Six questions, c'est six questions. Un corpus, un harnais, une exécution par volet, et les gens qui ont bâti la chose testée sont les gens qui l'ont mesurée. Nos cellules de jetons sont solides et nos cellules de chronométrage sont indicatives au mieux, avec plusieurs secondes de bruit par exécution, ce qui explique pourquoi nous ne revendiquons le résultat de vitesse dans aucune direction. Quiconque présente ceci comme une conclusion générale sur les architectures de retrieval le surinterprète largement. Ce que ça appuie est plus étroit et quand même utile : sur cette classe de corpus, un chemin déterministe d'index d'abord a éliminé la traîne coûteuse sans coûter en exactitude.
Deux choses nous font prendre cette forme plus au sérieux qu'une seule exécution interne ne le mériterait à elle seule. Une équipe de Tencent et de plusieurs universités a rapporté un résultat en juillet avec la même géométrie sur un substrat complètement différent, que nous n'avons pas reproduit : un index entretenu et centré sur le comportement, parcouru avant une exploration libre du dépôt, a amélioré la localisation des sites de modification tout en réduisant les jetons du planificateur, avec les plus gros gains sur les cas hostiles à la recherche.[3] C'est l'équivalent, en base de code, de nos questions de classe chasse. Et il y a une corroboration plus directe venant d'un outil livré : repomix existe pour empaqueter un dépôt entier dans un seul fichier destiné à un LLM, et sa propre documentation dit aux agents de ne pas charger ce fichier, mais d'y aller chercher de façon incrémentale à la place.[6] C'est une recommandation de documentation plutôt qu'une mesure, et nous ne l'avons pas mise au banc d'essai nous-mêmes. Nous y voyons un auteur d'outil qui arrive à la même conclusion par l'autre bout.
Le corollaire nous touche aussi, et ça vaut la peine de le dire tout haut. Si votre agent a déjà accès à read, grep et glob sur un dossier local, empaqueter ce dossier dans un artefact qui remplit le contexte, avant toute chose, c'est le volet que ce banc d'essai dit perdant. Le retrieval bon marché n'est pas une fonctionnalité qu'on ajoute. C'est une chose qu'on arrête d'empêcher.
Si vous êtes assis sur une pile de documents internes et que vous vous demandez si une base de connaissances entretenue par l'IA se rentabiliserait, la première étape honnête est une mesure. Construisez après, si la mesure le dit. Vous pouvez nous joindre par le formulaire de contact, et nous vous renverrons gratuitement un avis écrit sur ce qu'il en coûterait réellement de chercher dans votre corpus. Nous n'avons pas besoin de vos documents pour le faire : un nombre de fichiers, une taille, et un échantillon des questions que les gens posent réellement suffisent. Si une évaluation doit éventuellement toucher à votre contenu, c'est une conversation Loi 25 avant d'être une conversation technique.