💬 NLP

SCOPE: Self-Play via Co-Evolving Policies for Open-Ended Tasks

SCOPE est un cadre d'auto-apprentissage sans données qui fait coévoluer un Challenger et un Solver avec un auto-juge figé pour générer et noter des tâches fondées sur des documents, améliorant considérablement les performances de l'IA en questions-réponses ouvertes et à forme courte sur plusieurs modèles sans dépendre d'une supervision externe ou de prompts curatés.

Auteurs originaux : Wai-Chung Kwan, Aryo Pradipta Gema, Joshua Ong Jun Leang, Pasquale Minervini

Publié 2026-06-01

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Wai-Chung Kwan, Aryo Pradipta Gema, Joshua Ong Jun Leang, Pasquale Minervini

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous vouliez apprendre à un étudiant comment rédiger un excellent article de recherche, mais que vous n'avez ni professeur, ni manuel, ni même une liste de questions à poser. Vous ne possédez que l'immense bibliothèque de livres (Internet) et le propre cerveau de l'étudiant.

C'est le problème que l'article SCOPE tente de résoudre. Habituellement, pour entraîner une IA à accomplir des tâches complexes et ouvertes (comme la recherche approfondie ou l'écriture créative), les humains doivent rédiger les questions et noter les réponses. Mais les humains sont lents, coûteux et limités.

SCOPE est une nouvelle façon d'entraîner l'IA sans aucune aide humaine. Il utilise une méthode d'« auto-jeu » (self-play), similaire à la façon dont deux joueurs d'échecs pourraient jouer l'un contre l'autre pour s'améliorer, mais avec une nuance : ils jouent à un jeu de Cache-cache avec l'Information.

Voici comment cela fonctionne, décomposé en rôles simples :

1. Les trois personnages

Le système crée trois versions du même modèle d'IA pour jouer différents rôles :

Le Challenger (Le Maître du Quiz) : Le travail de cette IA est de créer une question complexe basée sur un document spécifique qu'elle vient de lire. Elle doit formuler une question suffisamment difficile pour que l'autre IA ne puisse pas simplement deviner la réponse par sa mémoire, mais pas si difficile qu'elle en soit impossible.
Le Solver (Le Détective) : Le travail de cette IA est de répondre à la question du Challenger. Pour ce faire, elle doit retourner dans la bibliothèque, chercher des indices, lire des documents et assembler la réponse. Elle ne peut pas simplement se fier à ce qu'elle sait déjà ; elle doit trouver de nouvelles preuves.
Le Judge (Le Correcteur Strict) : C'est une copie figée et immuable de l'IA originale. Elle ne change pas et n'apprend pas. Son seul rôle est de regarder le document source et la question, puis de rédiger une « grille d'évaluation » spécifique (une liste de contrôle de ce qui constitue une bonne réponse). Elle évalue ensuite la réponse du Solver en fonction de cette liste.

2. La boucle de jeu : Comment ils s'améliorent

La magie opère lors d'un cycle de trois étapes :

Le Défi : Le Challenger lit un document et invente une question. Il essaie de trouver le « point d'équilibre » : une question qui est juste assez difficile pour déstabiliser l'actuel Solver. Si la question est trop facile, le Solver obtient un A instantanément ; si elle est trop difficile, le Solver échoue complètement. Le Challenger veut que le Solver éprouve des difficultés pour qu'il puisse apprendre.
L'Investigation : Le Solver reçoit la question. Il ne connaît pas la réponse. Il doit chercher dans la bibliothèque, lire plusieurs documents et synthétiser l'information pour rédiger une réponse.
La Notation : Le Judge regarde le document source et la question, puis rédige une liste de contrôle spécifique (la grille). Par exemple, si la question porte sur un naufrage, la grille pourrait dire : « La réponse doit mentionner la décision du capitaine de naviguer dans la tempête » et « La réponse doit mentionner les défaillances de gestion de la sécurité. » Le Judge évalue ensuite le Solver.

Le moment « Eurêka ! » :
L'astuce clé est que le Challenger et le Judge voient le document source, mais le Solver, lui, ne le voit pas. Le Solver ne voit que la question. Cela force le Solver à apprendre à rechercher efficacement pour trouver l'information manquante.

Si le Solver devient meilleur dans ses recherches, le Challenger doit devenir plus intelligent pour poser des questions plus difficiles. Si le Challenger devient meilleur pour poser des questions difficiles, le Solver doit devenir meilleur dans ses recherches. Ils « co-évoluent », se poussant mutuellement vers des niveaux de compétence supérieurs, tout comme deux athlètes qui s'entraînent ensemble.

3. Pourquoi est-ce une avancée majeure ?

Pas besoin de professeurs humains : La plupart des entraînements d'IA reposent sur des humains qui écrivent des milliers de questions et de réponses. SCOPE génère ses propres données d'entraînement à partir de documents bruts.
Compétent pour les tâches « floues » : Les méthodes d'auto-jeu précédentes ne fonctionnaient que pour les mathématiques ou le code, où il existe une seule bonne réponse (comme 2+2=4). Les tâches ouvertes (comme « Écrire une histoire » ou « Analyser un événement historique ») n'ont pas de réponse unique. SCOPE utilise la grille du Judge pour évaluer ces tâches floues, permettant à l'IA de s'améliorer dans le travail de recherche et de création.
Cela fonctionne : L'article a testé cela sur trois modèles d'IA différents. Même s'ils n'ont été entraînés que sur ces tâches ouvertes auto-générées, ils se sont considérablement améliorés en :
- Recherche approfondie : Trouver et combiner des informations provenant de multiples sources.
- Écriture créative : Écrire de meilleures histoires et essais.
- Questions courtes : De manière surprenante, ils se sont aussi améliorés sur des questions simples de vérification de faits (fact-checking) pour lesquelles ils n'avaient jamais été explicitement entraînés.

La « Recette Secrète »

L'article a découvert que pour que cela fonctionne, le Challenger doit constamment changer. Si vous figez le Challenger et ne laissez que le Solver apprendre, le Solver comprend rapidement les questions faciles et cesse de progresser. Le Challenger doit constamment inventer de nouveaux puzzles, légèrement plus difficiles, pour maintenir le Solver en alerte.

De plus, le Judge doit être assez intelligent pour rédiger une bonne liste de contrôle (grille). Si la liste est vague, le Solver n'apprend rien. Si la liste est spécifique et ancrée dans les faits du document, le Solver apprend exactement ce qu'il doit trouver.

En résumé

SCOPE est comme une salle de sport automatisée pour l'IA. Au lieu qu'un entraîneur humain dise à l'IA quoi faire, l'IA crée son propre entraînement (le Challenger), effectue l'entraînement (le Solver) et évalue sa propre forme (le Judge). En se défiant constamment avec un niveau de difficulté juste, l'IA apprend à rechercher, raisonner et écrire mieux qu'elle ne le ferait avec de simples données curatées par l'homme.

Résumé Technique : SCOPE – Self-Play via Co-Evolving Policies for Open-Ended Tasks

Énoncé du Problème

Les approches actuelles d'apprentissage par renforcement (RL) pour l'entraînement des grands modèles de langage (LLM) sur des tâches ouvertes (ex: recherche approfondie, QA complexe, écriture créative) font face à un goulot d'étranglement fondamental : elles dépendent d'une supervision externe. Cette supervision prend la forme de prompts curatés par l'humain, de réponses de référence ou de juges issus de "modèles frontières" (des LLM plus puissants utilisés pour évaluer les sorties). Ces dépendances lient la performance du modèle à la qualité des données humaines et limitent la scalabilité.

Les méthodes de self-play existantes pour les LLM tentent de contourner cela en faisant co-évoluer des générateurs de tâches et des solveurs. Cependant, ces approches antérieures (ex: SPICE, Dr. Zero, R-Zero) sont restreintes aux domaines possédant des réponses vérifiables (correspondance de chaînes de caractères, égalité numérique, exécution de code). Les tâches ouvertes ne possèdent pas de réponse unique correcte, rendant la vérification basée sur des règles impossible. Bien que l'évaluation par rubriques offre une voie possible, les méthodes de RL basées sur des rubriques précédentes (ex: RaR, DR Tulu, RPG) dépendent toujours de prompts curatés ou de juges externes (modèles frontières), échouant ainsi à atteindre une boucle d'auto-supervision véritablement sans données.

Méthodologie : SCOPE

Les auteurs introduisent SCOPE (Self-play via Co-evolving Policies for Open-Ended tasks), le premier cadre étendant le self-play sans données aux tâches ouvertes. Le système fonctionne sans données curatées ni juges externes, s'appuyant plutôt sur un "auto-juge" dérivé du modèle de base lui-même.

Architecture Centrale

SCOPE fait co-évoluer deux politiques initialisées à partir du même modèle de base $M_0$ , aux côtés d'un troisième rôle fixe :

Le Challenger ( $C_t$ ) : Une politique en évolution entraînée pour générer des tâches ouvertes et ancrées dans des documents. Il effectue une recherche multi-tours sur un corpus non étiqueté pour construire des tâches qui se situent près de la frontière de capacité actuelle du Solver.
Le Solver ( $S_t$ ) : Une politique en évolution entraînée pour répondre aux tâches du Challenger. Il utilise la génération augmentée par récupération (RAG) multi-tours pour rassembler des preuves et synthétiser des réponses.
Le Juge ( $J = M_0$ ) : Une copie gelée du modèle de base initial. Il remplit deux fonctions critiques :
- Génération de Rubriques : Pour chaque tâche $q$ et document source $d$ , le Juge génère des rubriques d'évaluation (critères) spécifiques à la tâche, ancrées dans le document source.
- Notation : Le Juge évalue les réponses du Solver par rapport à ces rubriques.

Boucle d'Entraînement

Le processus d'entraînement alterne entre deux étapes, optimisées via l'Optimisation de Politique Relative de Groupe (GRPO) :

Étape 1 : Entraînement du Challenger

Le Challenger génère une tâche $q$ basée sur un document source $d$ .
Portes de Qualité (Quality Gates) : Le Juge applique des vérifications binaires pour s'assurer que la tâche fait référence à des entités identifiables et qu'elle est ancrée dans le document source. Les tâches échouant à ces portes sont rejetées pour empêcher le Challenger de générer des prompts génériques exploitant la récompense (reward-hacking).
Récompense de Difficulté : Le Solver précédent ( $S_{t-1}$ ) tente la tâche. Le Juge note les réponses. Le Challenger est récompensé pour la génération de tâches où le score moyen du Solver est proche d'une difficulté cible $\tau = 0.5$ . Cela garantit que les tâches restent difficiles mais solubles, maximisant la variance du feedback.

Étape 2 : Entraînement du Solver

Le Challenger génère un pool de tâches.
Filtrage : Les tâches sont filtrées selon les portes de qualité et la difficulté (ne conservant que celles où le score moyen du Solver se situe dans l'intervalle $[0.2, 0.8]$ ).
Récompense du Solver : Le Solver est entraîné sur ces tâches filtrées. La fonction de récompense combine :
- Score de Rubrique : Moyenne pondérée de verdicts binaires sur des critères spécifiques.
- Récompenses de Format et de Recherche : Encourager l'utilisation appropriée des outils et la structure.
- Pénalité de Longueur : Une pénalité basée sur la similitude cosinus empêche le Solver d'exploiter la tendance du Juge à favoriser les sorties longues en générant des réponses excessivement verbeuses.

Justification Théorique

L'article soutient qu'un auto-amélioration durable nécessite une information apprenable. SCOPE y parvient grâce à :

Ancrage de la Tâche : Le Challenger et le Juge observent le document source $d$ , tandis que le Solver ne voit que la tâche $q$ . Le Solver doit récupérer $d$ pour répondre, créant ainsi un écart d'information.
Écart de la Rubrique Cachée : Les rubriques $G$ contiennent des critères spécifiques au document qui ne sont pas pleinement révélés par la tâche $q$ . Le Solver doit récupérer les détails spécifiques dans $d$ pour satisfaire la rubrique.
À mesure que le Solver s'améliore, il réduit l'écart sur les tâches actuelles. Le Challenger doit alors co-évoluer pour proposer de nouvelles tâches où l'écart reste ouvert, empêchant le signal d'apprentissage de saturer.

Contributions Clés

Premier Self-Play sans Données pour les Tâches Ouvertes : SCOPE est le premier cadre appliquant avec succès le self-play aux tâches ouvertes sans dépendre de prompts curatés ou de juges modèles frontières.
Auto-Jugement par Rubriques : Il démontre qu'une copie gelée du modèle de base peut efficacement générer des rubriques spécifiques aux tâches et noter les réponses, remplaçant ainsi la supervision externe.
Nécessité de la Co-évolution : L'article fournit une preuve empirique qu'un Challenger statique échoue à maintenir une amélioration durable ; le Challenger doit co-évoluer avec le Solver pour maintenir la "frontière de difficulté".
Généralisation : Malgré un entraînement exclusif sur des tâches ouvertes ancrées dans des documents, la méthode améliore les performances sur le QA à format court et l'écriture créative, suggérant des gains transférables en matière de synthèse et de récupération.

Résultats Expérimentaux

Les auteurs ont évalué SCOPE sur trois modèles instruits (Qwen2.5-7B, Qwen3-8B, OLMo-3-7B) à travers huit benchmarks ouverts et sept benchmarks de QA à format court.

Performance en Tâches Ouvertes : SCOPE a amélioré la performance en tâches ouvertes de +5.4 à +10.4 points sur les modèles. Notamment, sur Qwen2.5-7B, le score moyen est passé de 24.4 à 34.8 (+10.4).
Comparaison aux Données Curatées : SCOPE a égalé ou dépassé GRPOdata, un baseline entraîné sur environ 9 000 prompts curatés par l'humain avec des rubriques de modèles frontières. Par exemple, sur Qwen3-8B, SCOpe a atteint 43.1 contre 41.5 pour GRPOdata.
Transfert vers le QA Court : Bien qu'entraîné uniquement sur des tâches ouvertes, SCOPE a amélioré les scores de QA court de +7.8 à +13.8 points, surpassant GRPOdata sur les trois modèles.
Écriture Créative : SCOPE a montré des gains significatifs en écriture créative (jusqu'à +7.4), un domaine où GRPOdata a souvent régressé par rapport au modèle de base, indiquant que le self-play ancré dans un corpus construit des capacités de synthèse robustes.
Études d'Ablation :
- Co-évolution : Geler le Challenger a entraîné des gains négligeables (+0.8 contre +3.4 pour le SCOPE complet), car les tâches devenaient trop faciles.
- Conception de la Récompense : Supprimer les portes de qualité ou les pénalités de longueur a conduit à un "reward hacking" (tâches génériques ou textes gonflés), provoquant un effondrement de la performance sous le niveau du modèle de base.
- Qualité de la Rubrique : La qualité de la génération de la rubrique (et non la capacité de notation) a été identifiée comme le goulot d'étranglement. Les rubriques issues de modèles plus petits (4B) manquaient souvent de faits documentaires spécifiques, tandis que les modèles 8B+ produisaient des critères ancrés et discriminants.

Signification et Revendications

L'article affirme que SCOPE représente une étape importante vers un auto-amélioration scalable et sans données pour les LLM. En remplaçant la dépendance aux données curatées par l'humain et aux juges frontières par une boucle autonome de politiques co-évolutives et d'auto-jugement par rubriques, SCOPE étend la portée du self-play au-delà des domaines vérifiables (mathématiques, code) vers des tâches de raisonnement ouvertes et complexes.

Les auteurs notent modestement que le pipeline multi-étapes nécessite plus de calcul que le GRPO à étape unique, limitant leurs expériences actuelles aux modèles de 7-8B. Cependant, ils soutiennent que dans le "régime post-données" où la supervision curatée est épuisée, échanger du calcul contre une auto-amélioration continue est une voie justifiée et nécessaire. Les résultats suggèrent que les tâches ouvertes peuvent être maîtrisées via des signaux auto-générés, à condition que le système maintienne une asymétrie d'information dynamique entre le générateur de tâches et le solveur.