Une mémoire qui peut se tromper

AdminLocal tient dans un dépôt Git.

Pas seulement son code : les prix, les procédures, les décisions, les règles de fonctionnement, les chantiers en cours, les erreurs déjà rencontrées. Tout ce qui doit rester vrai pour que le travail puisse continuer y vit également. Avant chaque session, l’IA lit une partie de ce dépôt et s’en sert pour travailler.

Cela change assez profondément la manière dont il faut tenir cette documentation. Dans un projet classique, une phrase devenue fausse peut rester là quelque temps sans provoquer grand-chose. Quelqu’un finira probablement par la corriger. Ici, une phrase devenue fausse peut devenir une instruction donnée à l’IA.

Fin août, j’ai donc fait auditer le dépôt. 83 agents ont parcouru ses différentes parties et chaque constat a ensuite été vérifié deux fois. 406 problèmes ont été retenus : 289 affirmations devenues fausses avec le temps, 35 contradictions et 82 informations répétées à plusieurs endroits sans être tout à fait identiques.

Le diagnostic n’avait rien de particulièrement surprenant. Ce qui l’était davantage, c’est que le problème ne disparaissait pas en demandant simplement à l’IA de mieux tenir compte de la documentation. Une consigne comme « réécris cette section lorsqu’elle devient obsolète » paraît suffisamment claire. En pratique, le modèle ajoute. Il conserve l’ancien texte et l’entoure d’une explication sur pourquoi il n’est plus vrai. Les lignes augmentent, elles ne diminuent jamais. Une section qui devait décrire l’état actuel finit par devenir une archive.

J’ai donc commencé à traiter ces fichiers comme des objets ayant des propriétés différentes. Certains décrivent l’état actuel du système : ils doivent être vrais aujourd’hui et sont réécrits lorsqu’ils changent. D’autres sont des journaux : ils enregistrent ce qui s’est passé, peuvent grandir indéfiniment et ne sont pas censés être lus comme la vérité actuelle.

La distinction est simple pour un humain. Elle devient beaucoup plus importante lorsque le lecteur est une machine qui doit décider quel texte utiliser comme instruction.

Même problème avec les informations répétées. Un prix doit avoir une source. Une décision doit avoir une source. Une règle doit avoir une source. Si la même information apparaît dans trois fichiers, les trois copies finiront tôt ou tard par diverger. Ce n’est pas très différent d’une base de données mal normalisée, sauf qu’ici le moteur qui exploite les données est capable de raisonner sur les contradictions qu’on lui donne.

J’ai aussi dû mettre des contraintes sur la taille de certaines règles. Un modèle à qui l’on demande de réécrire un texte plutôt que de l’allonger va très facilement faire l’inverse. J’ai mesuré le problème sur mes propres journaux : une section qui devait se clore est passée de 38 à 1483 mots, une autre de 161 à 5843.

J’ai alors ajouté un contrôle qui compare certains fichiers à leur version précédente. Ils peuvent rétrécir, mais pas grossir.

Le premier contrôle était mauvais. Le nombre de lignes diminuait, mais le nombre de caractères augmentait : les phrases avaient simplement été raccourcies pour respecter la règle tout en conservant davantage de contenu. Le garde était vert, le fichier avait grossi de 5306 à 5809 caractères. Il comptait la mauvaise chose.

Je l’ai corrigé.

C’est à peu près à ce moment que la nature du problème a commencé à m’apparaître plus clairement. Je ne suis pas simplement en train d’essayer de mieux écrire des instructions pour une IA. Je suis en train de construire un environnement dans lequel une IA peut travailler sans que cet environnement ne dérive trop vite.

Faire travailler une IA avec une mémoire persistante ressemble moins à « écrire de bons prompts » qu’à faire de l’ingénierie de système autour d’un moteur probabiliste.

Le dépôt est maintenant organisé par territoires : le site, l’infrastructure, le produit, l’administratif. Chaque territoire possède sa propre carte de règles et une carte à la racine permet de trouver la bonne. Elle ne recopie pas les règles des territoires. Les chantiers suivent la même logique : un état court et structuré pour ce qui est vrai maintenant, accompagné d’un journal daté qui conserve ce qui s’est passé.

Cela permet aussi de faire quelque chose que je trouve important : se tromper sans perdre l’histoire de l’erreur.

Le 13 septembre, j’ai ajouté une règle qui disait qu’un fichier ne devait contenir qu’une seule langue. L’idée était assez intuitive. Si les instructions destinées à l’IA sont en français, pourquoi laisser de l’anglais au milieu ?

Le lendemain, une relecture m’a amené vers deux travaux qui mesuraient justement le suivi d’instructions dans différentes langues. Ils ne confirmaient pas mon intuition. Dans les modèles testés, le français ne donnait pas systématiquement de moins bons résultats que l’anglais et, selon les modèles et les configurations, pouvait même faire mieux. Le mélange des langues produisait lui aussi des effets différents selon le sens du mélange.

La règle n’avait donc plus de raison d’être. Je l’ai supprimée le lendemain.

Le dépôt conserve le vote du 13 septembre, son retrait du 14 et la raison du changement.

C’est probablement la partie qui m’intéresse le plus dans ce système. Je ne cherche pas à construire une documentation qui aurait toujours raison. Ce serait impossible. Je cherche à construire une documentation dans laquelle une décision peut être vraie aujourd’hui, fausse demain, et où le passage de l’une à l’autre reste observable.

C’est une différence importante quand la documentation n’est plus seulement destinée aux humains. Elle devient une partie de l’environnement dans lequel travaille l’IA. Mes règles sont donc à la fois des instructions et des hypothèses sur ce qui fonctionne.

Je peux en écrire une lundi, la mettre en production mardi, découvrir mercredi qu’elle était mauvaise et la retirer sans faire disparaître le fait qu’elle a existé. Pour un bureau d’une personne, cette mémoire est particulièrement utile : il n’y a personne au-dessus de moi pour relire mes décisions, ni équipe qui se souvient six mois plus tard de la raison pour laquelle une règle avait été créée.

Le dépôt ne m’empêche pas de me tromper. Il me permet surtout de voir que je me suis trompé, de corriger ce qui doit l’être et de conserver suffisamment de contexte pour comprendre pourquoi.

C’est peut-être ça, finalement, le travail intéressant : pas apprendre à une IA à tout savoir, mais construire autour d’elle un système dans lequel ce qu’elle croit savoir peut être vérifié, contredit et remplacé sans que l’histoire disparaisse.