Analyse de Berkeley GEPA : l’IA peut apprendre de nouvelles tâches sans mettre à jour les poids, avec 35 fois moins de coûts d’entraînement que le RL

L’équipe de recherche de l’université de Californie à Berkeley propose une nouvelle méthode d’entraînement pour l’IA : GEPA, déjà acceptée par l’ICLR 2026 en tant qu’article Oral. GEPA ne met pas à jour les poids du modèle, ne nécessite pas d’entraînement sur GPU : il suffit d’utiliser un LLM qui « lit un journal d’entraînement » et réécrit à répétition les invites du système d’IA. Résultat : sur 6 tâches, GEPA surpasse en moyenne les méthodes d’apprentissage par renforcement dominantes de 6 %, avec un meilleur score jusqu’à 20 %, et avec un nombre d’essais d’entraînement (rollouts) inférieur de 35 fois. Après avoir été synthétisée par la communauté d’ingénierie IA, la méthode a suscité des discussions sur la plateforme X ; elle a désormais été intégrée à DSPy en tant qu’optimiseur de premier rang.

Ce que fait GEPA : utiliser les journaux d’entraînement comme support, au lieu de ne regarder que les scores

Le workflow des méthodes d’apprentissage par renforcement traditionnelles (comme GRPO) est le suivant : faire exécuter une fois une tâche à l’IA, obtenir un score « +1 ou -1 » en fonction du résultat, puis ajuster en boucle les poids du modèle à partir de ce score. Le problème, c’est que le déroulé de cette exécution d’une tâche comporte souvent des étapes de raisonnement de plusieurs milliers de tokens, des appels d’outils, des messages d’erreur : ces détails riches sont compressés en un seul score, et l’information du processus est perdue. Ainsi, le RL doit être lancé des dizaines de milliers, voire des dizaines de milliers de fois, pour converger.

La démarche de GEPA est l’inverse : une fois la tâche terminée, l’IA transmet l’intégralité du processus (reasoning, appels d’outils, historique d’erreurs) à un autre « LLM de réflexion » qui le lit tel quel. Le LLM de réflexion agit comme un ingénieur chevronné lisant un log de programme : il repère l’étape où ça s’est mal passé, pourquoi cela a échoué, et comment modifier l’invite, puis réécrit directement l’invite du module concerné. À exécution identique de la tâche, la quantité de signaux extraite par GEPA est bien plus grande que celle fournie par le seul score de RL.

Pourquoi ça marche : transformer le « score » en « lecture de tout le processus »

Sur 6 tâches, GEPA obtient en moyenne un avantage de 6 % sur GRPO, avec un maximum de 20 % ; face à un autre optimiseur d’invites dominant, MIPROv2, il dépasse aussi de plus de 10 % (avec une progression de 12 % sur le benchmark de maths AIME-2025). Le point le plus crucial est le coût d’entraînement : pour atteindre des performances comparables, GEPA a besoin de rollouts (un passage complet sur une tâche) inférieurs de 35 fois.

Une autre donnée : après l’intégration de GEPA avec DSPy, le « Full Program Adapter » permet d’optimiser l’ensemble du programme DSPy (y compris les signatures, les modules, la structure de contrôle). Sur le benchmark MATH, GEPA atteint 93 % de précision, bien au-delà de la méthode ChainOfThought initiale de DSPy (67 %). GEPA excelle aussi particulièrement sur des workflows multi-modules (agents IA chaînés sur plusieurs modules) : il peut cibler précisément un module qui échoue et réécrire son invite, plutôt que d’ajuster tout le système.

Qui va s’en servir en premier : un citoyen de première classe dans DSPy, code déjà open source sur GitHub

Le code de GEPA a été publié sur GitHub. Il est intégré au framework DSPy sous la forme de dspy.GEPA, et publié aussi de manière indépendante en tant que bibliothèque Python. L’équipe de recherche regroupe des institutions comme UC Berkeley, Stanford, Notre Dame et Anthropic. Les auteurs du papier comprennent Matei Zaharia (cofondateur de Databricks, auteur principal de DSPy) et Omar Khattab (auteur principal de DSPy).

Pour la communauté des développeurs, GEPA apporte une nouvelle solution à un problème courant : avoir énormément de rollouts mais ne pas savoir comment les exploiter. Beaucoup d’équipes ont déjà accumulé des milliers, voire des dizaines de milliers, de journaux d’exécution d’agents, mais au-delà de quelques vérifications quand ça bug, elles n’ont pas de méthode systématique pour transformer ces journaux en amélioration du modèle. Le prochain point à observer est l’adoption concrète de GEPA dans les workflows agentiques en entreprise (comme l’automatisation du support client et la réparation automatique de code), et de savoir si des implémentations de GEPA apparaîtront en dehors du cadre DSPy.

Cet article « Berkeley GEPA » : sans mise à jour des poids, l’IA apprend de nouvelles tâches, et avec 35 fois moins de coût d’entraînement, devance le RL—la première apparition de l’article remonte à Chaîne News ABMedia.