Un agent plutôt qu’un optimiseur dédié : un cadre unifié qui évolue simultanément sur plusieurs tâches
Les auteurs montrent qu’un modèle figé, exécuté avec une version inchangée de son environnement, commence par résoudre des tâches, puis modifie lui-même son propre code en s’appuyant sur les journaux complets des exécutions. L’évolution multitâche d’un squelette de 49 lignes a amélioré les résultats sur les tâches de la distribution et sur des benchmarks tenus à l’écart, et a permis de surpasser Codex sur certains d’entre eux.
Qu’est-ce qu’un harness et pourquoi l’optimiser
Un harness est le code qui entoure un agent fondé sur un modèle de langage. Il organise les prompts, les appels aux outils, la gestion du contexte et l’exécution. La façon dont ce code est conçu détermine la manière dont l’agent résout les tâches.
Dans la plupart des méthodes existantes, le harness est créé par un humain. Un proposer distinct modifie le harness du solveur. Un harness distinct évolue pour chaque benchmark. Cette approche lie les améliorations à une seule tâche.
Critère pratique : un cadre unique évolue simultanément sur plusieurs tâches, plutôt que pour chaque benchmark séparément.
Un cadre unique : l’agent comme son propre optimiseur
L’article de Qiankai Xu a été soumis le 29 septembre 2026. Il s’intitule « Self-Evolving Harness on Multiple Tasks with the Agent as Its Own Optimizer ». L’approche repose sur un seul modèle figé et une seule version du harness.
Le modèle commence par résoudre les tâches en tant que solveur. Il joue ensuite lui-même le rôle de proposer. Il lit les journaux complets des exécutions et modifie directement le harness qui le fait fonctionner. Aucun proposer distinct n’est nécessaire.
| Paramètre | Méthode type | Approche de l’article |
|---|---|---|
| Qui modifie le harness | Un proposer distinct | Le même modèle figé |
| Harness initial | Créé par un humain | Une seule version du harness |
| Portée | Un harness distinct pour chaque benchmark | Tâches issues de cinq benchmarks de domaines différents |
| Rôles | Proposer et solveur séparés | Le modèle est d’abord solveur, puis proposer |
Critère pratique : un agent qui lit les résultats de ses exécutions et modifie son propre harness remplace un optimiseur distinct.
Cinq benchmarks et séparation des données
Chaque cycle d’évolution comprend des tâches issues de cinq benchmarks de domaines différents. Les tâches d’entraînement et celles mises en réserve sont strictement séparées.
Des évaluations supplémentaires sont menées sur cinq benchmarks hors distribution. Ces benchmarks ne sont pas utilisés au cours de l’évolution.
Critère pratique : les évaluations hors distribution testent le transfert, et pas seulement l’adaptation à des tâches familières.
Deux étapes d’évolution
Le processus d’évolution est présenté comme l’entraînement d’un modèle profond en deux étapes :
- Préentraînement multitâche.
- Entraînement continu.
La version initiale du harness comptait 49 lignes. À l’issue de la première étape, le score moyen a augmenté de 4,48 points sur les benchmarks dans la distribution. Sur les benchmarks hors distribution, la hausse a atteint 12,64 points. Sur les premiers, le résultat a dépassé celui de Codex ; sur les seconds, il l’a égalé.
À la deuxième étape, la poursuite de l’évolution sur Claw-Eval a fait passer le score de 66,17 à 68,06. Sur ce benchmark, l’approche a dépassé Codex.
Critère pratique : le préentraînement élargit le transfert, tandis que l’entraînement continu affine le résultat sur un benchmark donné.
Mécanismes apparus au cours de l’évolution
Les auteurs analysent trois mécanismes :
- la troncature de la sortie ;
- la compression de l’historique ;
- la vérification indépendante.
La troncature de la sortie limite le volume de la réponse. La compression de l’historique réduit le contexte. La vérification indépendante ajoute un contrôle du résultat. Ces mécanismes sont apparus à la suite des modifications du harness et n’ont pas été définis par un humain.
Critère pratique : les mécanismes apparus au cours de l’évolution servent de repères pour évaluer son propre cadre.
Foire aux questions
Matériaux connexes
Tous matériaux
Évaluation des agents de programmation pour le développement XR interactif : résultats de GenXR-Bench
GenXR-Bench est publié : un ensemble de 112 tâches expertes pour évaluer de bout en bout les agents de programmation dans le développement XR interactif, de l’amélioration de fonctionnalités et de la correction de défauts à la création d’applications dont le comportement est testé sur du matériel grand public. Parmi les dix modèles testés, le meilleur résultat a été de 50,9 % en Pass@1 ; les défaillances récurrentes concernent notamment la gestion des événements asynchrones des capteurs, l’ancrage des objets dans l’espace réel et la compréhension des interactions dans un contexte physique.
5 novembre 2026
Annotation hybride des images : l’automatisation accélère l’entraînement des modèles de vision par ordinateur
L’article décrit comment le pré-étiquetage par des algorithmes réduit le travail manuel et améliore la qualité des jeux de données d’entraînement, ainsi que les raisons pour lesquelles une vérification humaine par échantillonnage reste nécessaire. Il examine les limites de cette méthode dans des conditions de prise de vue difficiles et pour les types d’objets rarement rencontrés.
5 novembre 2026
De la récompense scalaire au front de Pareto : synthèse RTL par LLM avec apprentissage par renforcement multicritère
Une méthode est proposée pour entraîner un modèle de langage à générer non pas un seul schéma, mais un ensemble de candidats RTL offrant différents compromis entre surface, latence et consommation d’énergie ; la récompense est calculée en fonction de la contribution de chaque variante à l’hypervolume du front de Pareto. Sur RTLLM v2, l’hypervolume relatif a augmenté de 13,3 points de pourcentage par rapport à la version de base sans optimisation PPA et de 14,4 points de pourcentage par rapport à l’apprentissage par renforcement mono-objectif.
5 novembre 2026