Un agent qui s'auto-améliore : est-ce vraiment réaliste ?

On parle beaucoup d'agents en ce moment. Sincèrement, n'importe qui peut en créer un en trois clics aujourd'hui. Le vrai sujet n'est pas là. 

La vraie question : à quel point cet agent est efficace ? Et surtout : à quel point évolue-t-il dans son environnement ? 

Si je m'intéresse autant à ce sujet, c'est en partie pour contrer un vieux traumatisme data : le drift, quand la distribution des données change et que ton modèle commence à raconter n'importe quoi. Quiconque a déployé un modèle en prod connaît cette angoisse. 

Du coup, je me suis penché sur les techniques qui existent pour se rapprocher d'un agent capable de s'auto-améliorer. Mais d'abord, de quoi parle-t-on exactement ? 

‍

Qu'entend-on par "auto-amélioration" ? 

Un agent "self-improving" répond à trois critères : 

1. Il modifie son comportement au fil du temps ‍

2. Le changement vient de sa propre expérience, pas uniquement d'annotations humaines

3. Le mécanisme est intégré dans sa boucle d'exécution, pas un fine-tuning ponctuel tous les six mois 

Mon point de vue : je reste convaincu que le self-improvement ne marchera vraiment que si une partie des feedbacks est monitorée par l'humain. 

Pourquoi ? Le risque majeur, c'est le biais auto-renforcé. Un agent laissé seul peut s'enfermer dans des minima locaux et optimiser... dans la mauvaise direction. L'humain, même en surface, évite que l'agent se bloque et débloque des niveaux d'efficacité record. 

Le 100% self-made agent n'est pas pour demain.

L'agent évolue dans un environnement, reçoit du feedback, et un optimiseur vient raffiner ses composants (prompts, outils, paramètres, architecture). Notez que le "Refine" en entrée suppose une curation des données, c'est là que l'humain intervient.

‍

1. Réflexion en temps réel 

La forme la plus simple. Reflexion: 

• L'agent tente une tâche
• Il échoue
• Il rédige une critique de sa propre tentative en langage naturel
• Il réessaie en tenant compte de ce feedback 

Léger, rapide, compatible avec n'importe quel LLM. Mais les améliorations sont éphémères, c'est une optimisation runtime, pas de l'apprentissage long-terme. 

C'est un excellent point de départ, mais ce n'est pas de l'apprentissage long-terme, plutôt une optimisation runtime. 

2. Optimisation de prompts (DSPy) 

Exit le Prompt Engineering Manuel. C'est l'une des tâches les plus ennuyantes que je fuis au maximum. Mais on peut l'automatiser avec DSPy. et ça nous permet d'avoir une étape intermédiaire dans la boucle d'auto-amélioration avant de toucher aux poids. 

L'idée : 

• Tu définis ta tâche comme une signature (input → output)
• Tu fournis quelques exemples ou une métrique d'évaluation 
• DSPy explore l'espace des prompts possibles et trouve ceux qui performent le mieux 

Limites 

• Nécessite un bon dataset d'évaluation pour guider l'optimisation
• Peut sur-optimiser sur des cas spécifiques et mal généraliser 
• Le search space explose vite — coût en compute non négligeable 

3. Améliorer la data qui entraîne l'agent 

Le levier le plus puissant à long terme. 

3.a. La boucle classique 

1. Récolter la data de prod: les vraies interactions 

2. Annoter: d'abord par des humains 

3. Réentraîner sur ces traces 

Ça peut commencer simplement : un joli dataset d'évaluation qu'on enrichit petit à petit. Des humains annotent, on accumule. Et progressivement, on fait en sorte que l'agent lui-même note et évalue ses traces, en se basant sur les feedbacks humains précédents. 

C'est là que les traces (ou trajectoires) deviennent centrales : une trace, c'est l'historique complet d'une interaction — les actions de l'agent, les réponses de l'environnement, le résultat final. C'est de l'or pour l'apprentissage. 

Progressivement, l'agent peut lui-même noter ses traces en se basant sur les feedbacks humains précédents.

3.b. Self-Generated In-Context Examples: la mémoire des succès 

Chaque succès est stocké, puis réutilisé comme exemple in-context pour les futures tâches. 

Chaque fois que l'agent résout une tâche avec succès, il stocke la trajectoire complète. Pour les tâches futures, il s'envoie quelques trajectoires réussies passées comme exemples in-context. 

C'est de l'experience replay pour le prompting. 

Limites 

• Contexte limité : on ne peut pas tout mettre dans un prompt, il faut curate 
• Sans curation, risque de rejouer des patterns sous-optimaux 

3.c. Multi-Agent Learning : apprendre des échecs

Pour le multi-agent, j'ai trouvé une solution très intéressante dans l'article de Self-Improving Multi-Agent Systems : 

• Dans des tâches collaboratives (raisonnement, négociation), SiriuS log les traces d'interactions réussies dans une bibliothèque partagée
• Les trajectoires échouées sont réparées a posteriori (par un autre agent ou un processus offline) et ajoutées comme exemples positifs 
• Les agents sont ensuite fine-tunés ou promptés avec cette bibliothèque 

Limites ‍

• Contexte limité : on ne peut pas tout mettre dans un prompt, il faut curate 
• Risque de replay sous-optimal : sans curation, l'agent rejoue ses mauvais patterns 
• Drift environnemental : si les objectifs changent, les vieilles traces deviennent trompeuses
• Overhead système : maintenir une bibliothèque d'expériences ajoute de la complexité 

4. Les outils qui marchent 

Testés et approuvés : 

• DSPy : optimisation auto de prompts, bonne doc, communauté active
• AgentLightning : efficacité et itération rapide en prod 

‍

Conclusion 

Un agent qui s'auto-améliore, réaliste ? Oui. Les techniques existent et fonctionnent. 

Mais pas en autonomie totale. L'humain reste dans la boucle pour éviter les dérives. 

Ma recette sans forcément de fine-tuning poussé: 

1. Réflexion en temps réel — gains rapides 

2. Optimisation de prompts (DSPy) 

3. Boucle data vertueuse — récolter, annoter, réentraîner 

4. Traces comme mémoire — experience replay 

5. Humain dans la boucle — toujours 

Le self-improvement n'est plus de la science-fiction. C'est un ensemble de patterns d'ingénierie qu'on peut assembler dès aujourd'hui. La question n'est plus "est-ce possible ?" mais "comment le faire de manière robuste et contrôlée ?". 

Et ça, c'est un problème d'ingénierie. Mon domaine préféré.

‍

Article par B.ERRAJI, consultant data OSSIA - SONATE