Contexte du pré‑entraînement et du commons de données

Les modèles de grande taille ont profité d’un corpus public massif, principalement fourni par Common Crawl, qui archive depuis 2007 environ 10 pétaoctets de pages web. GPT‑3 a utilisé 60 % de ces données, et la version initiale de Llama s’est appuyée presque entièrement sur le même réservoir. Cette abondance provient d’initiatives comme Wikipedia, Project Gutenberg, ArXiv ou Stack Exchange, qui ont transformé le Web en un knowledge commons exploitable après un filtrage intensif (spam, duplication, OCR, etc.).

Nature du post‑entraînement et exigences en données

Le post‑entraînement, notamment via l’apprentissage par renforcement (RL), ne consomme plus des documents mais des tâches. Une tâche se compose d’un monde (environnement simulé), d’une intention (objectif) et d’un ensemble d’outils pour interagir, plus d’un grader qui évalue la réussite. Contrairement aux documents, les tâches sont éphémères : une fois exécutée, l’expérience ne se reproduit pas naturellement, ce qui empêche la création d’un réservoir de « tasks » comparable au commons textuel.

Logiciels open‑source comme source de tâches

Le seul réservoir existant de tâches structurées réside dans le commons logiciel. Un dépôt GitHub à un instant donné fournit le monde (code, dépendances, conteneur), les outils (shell, compilateur), l’intention (issues, pull‑requests) et le grader (tests unitaires). Cette approche a été testée par SWE‑bench, qui a extrait des tâches de 12 dépôts Python en crawlant leurs issues et pull‑requests. Le processus révèle deux difficultés majeures : (i) la nécessité de reproduire exactement l’environnement (versions, paquets, horloge système) et (ii) l’absence de métadonnées complètes pour certaines actions, ce qui oblige à « fabriquer » des tâches plutôt qu’à les curer.

Limites et perspectives

Malgré les avancées du contrôle de version, de l’intégration continue et des builds reproductibles (ex. Debian depuis 2013), le software commons reste incomplet : les dépendances disparaissent, les systèmes d’exploitation évoluent, et les builds ne sont pas toujours reproductibles à 100 %. De plus, la conversion d’un dépôt en tâche RL nécessite un effort de « manufacturing » : définir le grader, encapsuler le monde dans un conteneur, et garantir que l’intention soit correctement extraite. Sans une infrastructure standardisée pour ces étapes, le post‑entraînement restera limité à des expériences de petite échelle, freinant la création d’LLM réellement ouverts. Une solution viable impliquerait la création d’un task commons où chaque tâche serait publiée avec son environnement, son objectif et son critère d’évaluation, à l’image du modèle de données du web mais adapté aux exigences de la RL.