Meta FAIR présente les modèles de préférences en matière de recherche sur l'IA (RPM) : classer les expériences d'apprentissage automatique avant d'allouer des heures de GPU

Le paysage de l’intelligence artificielle s’enrichit d’une nouveauté significative.

Meta FAIR présente les modèles de préférences en matière de recherche sur l’IA (RPM) : classer les expériences d’apprentissage automatique avant d’allouer des heures de GPU

Les agents de travaux de recherche en IA sont déjà capables de proposer, de mettre en œuvre et d’évaluer leurs propres expériences d’apprentissage automatique. La génération d’idées ne coûte pas cher ; leur vérification, en revanche, oui. L’entraînement d’un candidat peut nécessiter plusieurs heures, voire différents jours, de temps de calcul sur GPU ; un agent propose donc bien plus de candidats qu’il ne peut se permettre d’exécuter. Le choix des candidats à exécuter constitue le véritable levier des progrès de la exploration.

Sur ce point, une équipe de recherche de FAIR chez Meta, de l’université d’Oxford et de l’University College London formalise ce levier sous le nom de « préférence de travaux de recherche » et présente les modèles de préférence de recherche en IA (RPM). Un RPM classe les candidats non exécutés et en sélectionne un à exécuter. Il ne prévoit jamais de score absolu, l’équipe ayant constaté que les modèles linguistiques n’étaient pas fiables pour prédire les métriques ou les résultats d’exécution.

Est-ce déployable ? En partie. Les RPM utilisent des modèles de langage de grande taille (LLM) pré-entraînés et figés, sans ajustement ; le framework AIRA-dojo et le benchmark AIRS-Bench sont open source, et les poids du modèle de base Qwen3.6-27Bis sont en libre accès.

AIRA-dojo est une méthode de recherche dans un arbre évolutif : sélection gloutonne des parents, opérateurs « Draft / Improve / Debug », et renvoi du nœud présentant le score de validation le plus élevé à la fin. Le RPM n’intervient qu’au moment de la création des enfants. Au lieu de générer un seul enfant et de l’exécuter, l’agent applique l’opérateur 15 fois en parallèle pour obtenir 15 candidats non exécutés, puis les compare deux à deux dans un tournoi à élimination directe. Seul le gagnant est exécuté. Chaque comparaison s’appuie sur des nœuds de contexte recueillis lors d’un parcours BFS de l’arbre exploré, chacun étant affiché avec le score de validation qu’il a obtenu.

Point notable, rPM « à inférence seule » : un modèle d’IA de langage de grande envergure (LLM) jouant le rôle de juge pour évaluer les plans candidats, le code et l’historique de recherche. Son prompt a été optimisé à l’aide de MIPROv2 de DSPy, convergeant vers une grille d’évaluation de chercheur principal qui tolère les bogues corrigibles, récompense l’extensibilité et pénalise les instructions redondantes, avec une précision hors ligne comprise entre 57,7 % et 59,0 %.

RPM agentique : le même juge et un bac à sable qui clone l’environnement de l’agent, y compris un seul H200. Les outils utilisés sont python, bash et submit_solution. Le système exécute des expériences pilotes à petite échelle, puis un modèle de rétroaction propose soit la prochaine expérience la plus instructive, soit met fin à la boucle. Deux choix de conception ont une incidence importante : le budget restant est délibérément surévalué (2 700s indiqués contre 300s en réalité) afin que l’agent ne s’arrête pas trop tôt, et le nombre de pilotes est plafonné à 30 avec un seuil de 60 secondes. Le temps du pilote entre en concurrence avec l’horloge interne de l’agent ; par conséquent, le sélecteur agentique ne s’exécute que lors des étapes « Draft » et « Improve » ; lors de l’étape « Debug », on revient à un choix aléatoire.

Pour faire simple :

Le RPM n’intervient qu’au moment de la création des enfants.
RPM agentique : le même juge et un bac à sable qui clone l’environnement de l’agent, y compris un seul H200.

Une affaire qui méritera assurément d’être suivie de près.

À lire également :

Reportage initial : MarkTechPost : MarkTechPost