HeirCommit écarte jusqu'à 83% des mises à jour nuisibles dans les LLM auto-évolutifs

Des chercheurs ont mis en évidence une faiblesse des modèles de langage auto-évolutifs : le choix de la version du modèle transmise au tour suivant. Sur des tâches vérifiées, la plupart des mises à jour n'augmentent pas la probabilité de bonnes réponses, mais les boucles R-Zero, Agent0 et Skill Self-Play les héritent toutes. Le framework HeirCommit réduit de 68 à 83% la part de mises à jour nuisibles acceptées par rapport à un héritage aléatoire, à taux d'acceptation identique. La surcouche EvoHeir affiche, sur quatre modèles de base, les meilleurs résultats moyens en mathématiques et en raisonnement général. Son score moyen en mathématiques dépasse de 5,3% celui d'Agent0, la baseline la plus solide.

Où l'auto-évolution déraille

Le schéma d'auto-évolution est le suivant : le modèle génère lui-même des tâches, s'entraîne dessus et aborde le tour suivant dans sa version mise à jour. À chaque tour, il faut décider quelle version du modèle devient l'héritière. Dans les boucles existantes, cette décision passe par la tâche. Si une tâche semble apprenable, elle est admise à l'entraînement, et la mise à jour qui en résulte est acceptée en bloc.

Les auteurs appellent ce problème l'écart entre sélection et mise à jour (selection-to-update gap). Une tâche qui semble apprenable ne produit pas forcément un déplacement utile des poids. D'après leur estimation, la plupart des mises à jour sur des tâches vérifiées ne rendent pas les bonnes réponses plus probables. La boucle en hérite pourtant, et les erreurs s'accumulent de tour en tour.

Comment fonctionnent HeirCommit et EvoHeir

HeirCommit déplace la décision de la tâche vers le modèle lui-même. La version mise à jour est gelée, puis testée sur de nouvelles questions d'évaluation. Le résultat détermine si l'on hérite du nouveau modèle ou si l'on garde l'actuel. Les questions inédites comptent, car sur celles qui ont servi à la sélection, le score est surestimé. Les auteurs nomment cet effet l'optimisme induit par la sélection (selection-induced optimism) et le décrivent de façon analytique.

EvoHeir va plus loin et sépare deux canaux d'héritage : les paramètres et l'expérience. Un modèle peut échouer au test, tandis que les tâches et les trajectoires sur lesquelles il s'est entraîné restent utiles. L'expérience courante et archivée sert à corriger les erreurs et à conserver les solutions réussies. La confirmation finale n'intervient qu'après cette étape. Selon la formule des auteurs, l'expérience utile est conservée même lorsque le modèle qui l'a produite n'est pas hérité.

La partie théorique décompose le regret en trois composantes :

• l'erreur de sélection, lorsqu'une mauvaise mise à jour est acceptée ou une bonne rejetée ;
• l'erreur d'absorption, lorsque le modèle assimile mal ce qu'on lui a présenté ;
• l'erreur de confirmation, lorsque la vérification finale introduit son propre bruit.

Les chiffres

• La part de mises à jour nuisibles parmi celles acceptées est inférieure de 68 à 83% avec HeirCommit par rapport à un héritage aléatoire, à taux d'acceptation identique.
• EvoHeir a été testé sur quatre modèles de base.
• Meilleurs résultats moyens en mathématiques et en raisonnement général parmi les méthodes comparées.
• Gain sur la moyenne en mathématiques : 5,3% par rapport à Agent0, la baseline la plus solide.

La comparaison avec un héritage aléatoire à part d'acceptation fixe rend le résultat plus honnête. Le gain ne s'explique pas par une méthode simplement devenue plus stricte. La question porte uniquement sur les mises à jour qui passent. Le gain de 5,3% est indiqué comme relatif, et la description disponible ne permet pas de savoir quels benchmarks et quels modèles entrent dans la moyenne.

Ce qu'il faut en retenir

Si vous construisez une boucle d'auto-apprentissage pour votre modèle ou votre agent, ce travail débouche sur trois conclusions pratiques. Premièrement, ne considérez pas l'admission d'une tâche comme la garantie d'une mise à jour utile : vérifiez le modèle final, et pas seulement le matériau sur lequel il s'est entraîné. Deuxièmement, gardez un jeu distinct de questions inédites pour décider de l'héritage. Si vous réutilisez les questions qui ont servi à la sélection, le score sera surestimé. Troisièmement, ne jetez pas l'expérience des versions rejetées. L'archive de trajectoires permet de corriger les erreurs et de consolider les réussites, sans qu'il soit nécessaire d'accepter les poids candidats.

Les limites sont tout aussi évidentes. Les nouvelles questions d'évaluation coûtent du calcul et des données, et il vaut mieux consulter l'article lui-même pour les détails d'implémentation et la liste complète des benchmarks. Mais l'idée de dissocier le choix du futur modèle de celui de la tâche d'entraînement s'applique à n'importe quelle boucle auto-évolutive.