TRM (Tiny Recursive Models) et ARC-AGI-2 : quand le raisonnement devient une boucle de correction
- Guillaume MATILLA
- 16 déc. 2025
- 8 min de lecture
Il y a deux façons de “vendre” le raisonnement en IA.
La première (la plus confortable) consiste à empiler des milliards de paramètres et à espérer qu’à force de tout voir, le modèle “devine” correctement la règle. La seconde (plus intéressante, et beaucoup plus exigeante) consiste à prendre au sérieux une idée presque banale : on se trompe, puis on corrige.
Les TRM (Tiny Recursive Models) appartiennent clairement à la seconde catégorie. Ce sont des modèles récursifs qui ne cherchent pas à être brillants en une passe. Ils cherchent à être stables en plusieurs passes. Et c’est exactement ce que ARC-AGI-2 vient tester, parce qu’ici, on n’évalue pas seulement si tu trouves la bonne grille : on évalue si tu peux y arriver avec deux essais, et surtout sans exploser ton budget.
Ce qui me frappe, depuis ARC Prize 2025, c’est que la discussion n’est plus “quel modèle est le plus intelligent ?”. La discussion devient : quelle procédure converge le mieux, et à quel prix. La fondation ARC l’assume très explicitement : 2025 est l’année de la refinement loop, la boucle de raffinage.
TRM : “moins de modèle”, plus de dynamique
Le papier Less is More: Recursive Reasoning with Tiny Networks propose TRM comme une version simplifiée d’approches récursives précédentes, avec une promesse assez brutale :
un réseau minuscule (environ 7M paramètres),
une architecture très courte (un seul petit réseau, 2 couches),
et pourtant des résultats mesurables sur ARC.
Les chiffres annoncés sont clairs : environ 45% sur ARC-AGI-1 et environ 8% sur ARC-AGI-2, dans leur protocole.
Ce n’est pas “la solution”. Mais c’est un signal important : ça montre qu’on peut obtenir un comportement de résolution non trivial en mettant l’intelligence dans la procédure (la boucle), pas seulement dans la taille (les paramètres).
Et ARC Prize 2025 ne s’est pas contenté de citer TRM : il a donné au papier le 1er prix paper award, et résume le modèle comme un système avec état réponse et état latent qui apprend via deep supervised refinement (raffinement supervisé profond).
Une intuition simple : TRM comme “correcteur de brouillons”

Sur le papier, on pourrait dire : “ok, c’est juste un modèle récurrent”. Dans les faits, la façon utile de le penser est différente.
TRM fonctionne comme un processus qui maintient deux choses en parallèle :
une réponse courante (la grille proposée, le brouillon),
un état latent (une mémoire interne qui encode ce qui cloche, ce qui est stable, et ce qui doit être corrigé).
À chaque itération, tu ne repars pas de zéro : tu améliores un candidat existant.
On peut le résumer avec trois variables (c’est volontairement minimaliste) :
x : l’entrée (les grilles input et les exemples train),
yt : la solution courante à l’itération t,
zt : l’état latent à l’itération t.
Le schéma mental le plus propre est :
diagnostiquer : mettre à jour z en regardant x et yt,
corriger : produire yt+1 à partir de yt et zt+1.
Ce qui compte, ce n’est pas l’équation exacte. Ce qui compte, c’est la dynamique : TRM n’essaie pas d’être juste “un générateur de sortie”. Il essaie d’être un moteur de correction.
Pourquoi “deux tentatives” favorise mécaniquement les boucles de raffinage
Je trouve utile de poser un mini-socle probabiliste, parce que ça évite de parler en impression.
Si une méthode one-shot a une probabilité ppp de résoudre une tâche en un essai, alors une version “deux essais” (pass@2) aurait, dans un monde naïf et indépendant :
Mais le détail important est : les deux tentatives ne sont pas indépendantes. Et c’est là que les refinement loops deviennent puissantes : l’essai 2 peut être conçu comme une correction conditionnelle de l’essai 1, donc statistiquement beaucoup plus informative que “tirer un second ticket au hasard”. ARC-AGI-2 est construit sur ce contrat : deux tentatives, comme l’humain, et une pression sur l’efficacité.
Mini-exemple (stylisé) : ce que “corriger” veut vraiment dire sur ARC
Je prends un cas volontairement simplifié, parce que l’objectif ici n’est pas de reproduire une tâche réelle, mais d’illustrer la mécanique.
Imagine une grille où l’input contient un “cadre” rectangulaire et un petit motif intérieur. La règle réelle est : remplir l’intérieur du cadre avec une couleur dérivée du motif, sans toucher au bord. Une approche one-shot a trois façons classiques de se planter :
elle remplit aussi le bord (violation de contrainte),
elle prend le mauvais rectangle (erreur d’objet),
elle copie la mauvaise couleur (erreur de correspondance).
Une boucle de raffinage te permet une trajectoire plus réaliste :
itération 0 : bon rectangle, bon remplissage intérieur, mais le bord a été altéré,
itération 1 : l’état latent encode “contrainte violée : le cadre a changé”, et la correction restaure le bord tout en gardant l’intérieur,
itération 2 : la sortie se stabilise : plus de contradiction globale.
Dit autrement : le raffinement n’est pas “faire mieux”. C’est réduire les contradictions.
Résultats et comparaisons : la règle d’or (ne pas comparer des scores hors contexte)
Le papier TRM annonce ses scores, et ils sont utiles comme signal.
Mais sur ARC, la comparaison brute est un piège, pour une raison simple : les pipelines diffèrent énormément.
Selon les systèmes, tu peux avoir :
des stratégies d’augmentation plus ou moins agressives,
de la sélection/évaluation de candidats (scoring),
des formes de recherche,
et parfois de l’adaptation au test (post-training, test-time training).
Bref : deux approches peuvent afficher “8%” en surface, et être en réalité deux objets entièrement différents en coût, en protocole et en généralisation.
Ce que j’aime dans ARC Prize 2025, c’est que l’organisation pousse justement à ce réalisme : les résultats officiels mettent en avant des couples “score + coût”.
Par exemple, l’analyse officielle rapporte :
un meilleur score Kaggle sur le private ARC-AGI-2 autour de 24% pour $0.20 / tâche,
un modèle commercial vérifié à 37.6% pour $2.20 / tâche,
et une solution de raffinement vérifiée à 54% pour $30 / tâche.
Le message sous-jacent est violent, mais sain : il n’existe pas un “score”, il existe un frontier score/coût.
“Tiny” ne veut pas dire “cheap” : le vrai mur, c’est le mur du compute
TRM est petit en paramètres. Mais une boucle récursive te fait payer autrement : tu paies en itérations, en candidats, et parfois en gradient steps au moment du test.
Une formule mentale (pas une loi physique) ressemble à :
La conséquence est simple : tu peux avoir un modèle “minuscule” qui coûte cher si tu le fais tourner comme une toupie.
Et ARC, via son leaderboard, met justement l’accent sur cette relation performance / coût par tâche et sur des contraintes de compute en contexte compétition.
Augmentation et invariances : le carburant discret, et pourquoi il faut rester humble
Sur ARC, l’augmentation n’est pas un bonus esthétique. C’est souvent ce qui transforme “3 exemples train” en “un espace de structure exploitable”.
Mais il faut être rigoureux sur un point : les invariances sont des heuristiques, pas des axiomes.
Je trouve utile de les classer en trois niveaux (encore une fois : cadre mental, pas vérité universelle) :
Niveau 1 — souvent assez sûr : permutations de couleurs (quand la règle ne dépend pas d’une couleur absolue), certaines symétries quand la règle est purement géométrique.
Niveau 2 — plausible mais risqué : rotations et miroirs, parce que certaines tâches encodent une orientation (gauche/droite, haut/bas, direction d’un déplacement).
Niveau 3 — presque toujours dangereux : transformations qui changent la topologie des objets, les tailles relatives, ou le “sens” des motifs (recadrage agressif, déformations).
Pourquoi ce détour compte pour TRM ? Parce que TRM apprend à corriger, oui, mais il apprend aussi ce qui doit rester invariant. Tu n’augmentes pas seulement des données. Tu augmentes une théorie implicite de la tâche.
Un critère d’arrêt minimal : une heuristique de cohérence (pas une règle magique)
Une refinement loop a un problème très concret : savoir quand s’arrêter.
Si tu continues trop tôt, tu rates une correction utile. Si tu continues trop longtemps, tu payes du compute pour rien (ou pire : tu dégrades).
Il n’existe pas un critère universel, mais il existe une idée simple : définir un score de cohérence S(y) qui mesure si la solution courante “ressemble” à une solution valide.
Ce score dépend du pipeline, mais il peut s’appuyer sur des signaux génériques :
auto-consistance sur les paires train (ta règle supposée doit reproduire les outputs train),
stabilité d’objets (éviter des fragmentations absurdes),
contraintes détectées (ne pas modifier un cadre, préserver certaines régions, etc.).
La définition exacte de S varie selon la représentation (pixels vs objets vs graphes). Mais l’idée est d’avoir un signal “mieux/pire” pour contrôler le budget.
Un critère d’arrêt minimal (heuristique, assumée comme telle) consiste à stopper quand le gain devient négligeable :
Dans beaucoup de systèmes, ce genre de détail “bête” fait une différence énorme sur le coût total.
Test-time adaptation : quand “raisonner” ressemble à “apprendre sur place”
Un autre point que je trouve fascinant : sur ARC, certaines approches deviennent performantes précisément parce qu’elles font une forme d’adaptation au test.
Le papier Test-time Adaptation of Tiny Recursive Models raconte un cas très concret. Avant la fin d’ARC Prize 2025, l’approche TRM open source dominante atteignait environ 7.8% sur l’évaluation publique ARC-AGI-2, mais demandait trop de compute pour être viable dans les contraintes compétition.
Le papier décrit alors un compromis :
pré-entraînement sur 1,280 tâches publiques,
700k+ pas d’optimisation,
48h sur 4× H100 SXM,
pour atteindre ~10% sur l’évaluation publique,
puis 12,500 pas de post-training pendant la compétition pour atteindre 6.67% sur la semi-private.
Et un détail important : le papier rapporte que cette performance de post-training vient d’un full fine-tuning, et non de LoRA ou d’un ajustement d’embeddings seulement.
Dit autrement : une partie du “raisonnement” sur ARC ressemble à une forme d’apprentissage ultra-local sous contrainte, avec un budget strict et une pression maximale sur l’efficacité.
Le lien naturel avec les graphes : quand une grille devient un problème de contraintes relationnelles
On peut résoudre ARC en pixels. Mais beaucoup de tâches deviennent plus claires dès que tu les lis comme un problème “objets + relations”.
Une grille contient implicitement :
des objets (composantes connexes, motifs, cadres, points),
des relations (adjacence, inclusion, alignement, symétries, correspondances).
Une fois que tu as des objets et des relations, tu as un graphe.
Et à partir de là, la boucle TRM prend une lecture presque naturelle : l’état latent z ressemble à un espace de “messages” qui résument des contraintes, des incohérences, des correspondances. À chaque itération, tu raffines non seulement la sortie, mais aussi la structure interne qui te dit où et pourquoi ça ne colle pas.
Je ne dis pas que TRM “est” une GNN (graph neural network). Je dis que la même intuition apparaît : le raisonnement devient une propagation d’information et une réduction itérative de contradictions.
Ce que TRM démontre vraiment (et ce qu’il ne démontre pas)
TRM ne prouve pas l’AGI. Mais TRM montre quelque chose de plus rare que “un score en plus” :
on peut obtenir un signal de raisonnement sur ARC avec un modèle minuscule,
en mettant l’essentiel dans une dynamique de raffinage,
et en assumant que l’intelligence utile est souvent une procédure de correction.
Le papier est explicite sur la simplicité de l’architecture (2 couches, 7M) et sur les scores annoncés.
ARC Prize 2025, de son côté, contextualise le paysage : la refinement loop est devenue le thème central, et la compétition/leaderboard force à parler budget autant que performance.
La vraie leçon, à mes yeux, est presque philosophique : un raisonnement robuste ressemble plus à une convergence qu’à une prédiction.
Conclusion
Sur le papier, TRM peut se résumer à “un petit modèle récurrent”. Dans les faits, TRM est surtout un manifeste : l’intelligence ne se mesure pas uniquement à la quantité de paramètres, mais à la qualité d’une boucle de correction.
ARC-AGI-2 est le terrain idéal pour ça, parce qu’il impose un contrat humain (deux tentatives) et un contrat d’ingénieur (efficacité).
Et si on regarde la trajectoire 2025, le message est cohérent : ce qui progresse, ce ne sont pas seulement des modèles, ce sont des systèmes qui apprennent à proposer, tester, réviser, et s’arrêter au bon moment.
Références principales
A. Jolicoeur-Martineau — Less is More: Recursive Reasoning with Tiny Networks (TRM, 7M params, 2 couches, scores ARC).
R. K. McGovern — Test-time Adaptation of Tiny Recursive Models (pré-training + post-training, compute).
ARC Prize — ARC Prize 2025 Results & Analysis (24% à $0.20/tâche, 37.6% à $2.20/tâche, 54% à $30/tâche, “Year of the Refinement Loop”).
ARC Prize — Announcing ARC-AGI-2 and ARC Prize 2025 (règle des deux tentatives).
ARC Prize — Leaderboard (relation coût/score, contraintes type Kaggle budget).
Commentaires