Les agents apprennent de la malchance : les leçons des LLM transforment une panne aléatoire en décision

Un agent a échoué à sa tâche, non pas parce qu'il avait choisi un mauvais outil, mais parce que l'outil n'a pas eu de chance. L'agent consigne alors dans sa mémoire une « leçon », et au run suivant, cette leçon le pousse à l'erreur. Kazuki Nakayashiki a mesuré la fréquence de ce phénomène dans une étude préenregistrée portant sur 90 084 réponses de 11 endpoints LLM. Lorsqu'un outil fiable est tombé en panne par hasard, les leçons rédigées par les modèles ont transposé ce hasard dans le choix suivant dans 11,6% des cas. Dans les conditions de contrôle, ces choix ne représentaient que 0,4%.

Comment le hasard a été piégé au passage de la mémoire à la décision

Les agents auto-améliorants, comme ceux qui utilisent ReasoningBank, rédigent de courtes notes à l'issue de leurs runs et les chargent dans les sessions futures. Quand le résultat est bruité, la note peut figer la chance ou la malchance en règle générale. L'auteur n'a testé qu'un seul maillon de cette chaîne : la leçon déjà rédigée influence-t-elle le choix suivant ?

Le protocole est le suivant. Il repose sur 256 mondes synthétiques. Dans chacun, une même tâche se répète et deux outils interchangeables, de fiabilité connue, sont disponibles.

Le run précédent était scénarisé : il utilisait soit l'outil le plus fiable (bonne décision), soit le moins fiable (mauvaise décision). Son issue était elle aussi fixée à l'avance : succès ou panne temporaire. Le modèle rédigeait une leçon selon l'instruction de ReasoningBank.

Ensuite, une session neuve du même modèle recevait un log faisant autorité et le résultat du run passé, puis choisissait le premier outil. La mémoire contenait exactement une entrée parmi quatre : la leçon tirée de ce run, la leçon tirée de l'issue opposée, une entrée sans rapport, ou une directive sans explication des raisons.

Le protocole a été figé, publié et horodaté dans un bloc Bitcoin avant le premier appel de confirmation. Les enregistrements des runs sont publics.

Ce que montrent les chiffres

• Après une panne aléatoire du meilleur outil, l'interaction s'établit à +0,112 (intervalle à 95% de +0,097 à +0,126). Dans la condition « luck-carrying », les modèles lecteurs ont désigné le pire outil dans 11,6% des runs suivants, avec la leçon tirée de cette panne.
• Avec une entrée sans rapport, la part est de 0,4% ; avec une leçon tirée d'un succès, elle est aussi de 0,4%.
• Quand le log indiquait explicitement que les pannes étaient indépendantes, l'effet était de +0,042. Quand il ne le disait pas, il était de +0,181 (données descriptives).
• Après un succès dû à la chance du pire outil, l'interaction valait +0,002 et restait bornée par le haut à 0,10. L'auteur souligne qu'il s'agit d'une borne, et non d'une preuve d'absence de tort.
• Dans l'analyse exploratoire, 6 endpoints ont transposé le hasard, l'effet atteignant +0,352 pour l'un d'eux. Les 5 autres endpoints sont restés sous le seuil de 0,10.

Le résultat est donc hétérogène selon les modèles. L'effet existe sur l'ensemble du panel, mais il ne s'exprime pas chez tous.

Une instruction peut-elle y remédier ?

L'auteur a testé deux variantes de correction de l'instruction de rédaction des leçons. Une note de trois phrases sur la qualité de la décision a ramené la part de choix du pire outil après une panne aléatoire à 7,5%. Une instruction unique pour les deux issues, avec l'option « ne rien changer », l'a ramenée à 3,1%. Aucune des deux variantes n'a satisfait à la règle préenregistrée de réduction du tort sur chaque endpoint : le remède n'est donc que partiel. Ces comparaisons sont secondaires.

L'étude a ses limites. Les mondes sont synthétiques, il n'y a que deux outils, les pannes sont temporaires, et l'influence a été mesurée sur le premier choix du run suivant. La façon dont l'effet s'accumule sur de nombreuses itérations de mémoire n'a pas été testée ici.

En pratique, pour ceux qui construisent des agents avec mémoire

Premièrement : si l'agent dispose d'une couche de réflexion, consignez dans le log non seulement l'issue, mais aussi une affirmation explicite sur la nature des pannes, par exemple qu'elles sont indépendantes. L'écart entre +0,042 et +0,181 montre que c'est la protection la moins coûteuse. Deuxièmement : donnez au modèle qui rédige la leçon le droit de répondre « ne rien changer ». Troisièmement : testez la mémoire sur des issues bruitées, où un bon choix s'est soldé par un échec, et ne vous limitez pas aux scénarios entièrement déterministes. Quatrièmement : ne généralisez pas le résultat d'un seul modèle, car pour 5 endpoints sur 11, l'effet n'a pas dépassé le seuil.