Adaptation au moment du test : principes et résultats

L’adaptation au moment du test consiste à ajuster un système aux données d’une tâche lorsqu’il doit la résoudre, souvent en modifiant temporairement certains paramètres du modèle. Le calcul au moment de l’inférence est plus large : il comprend aussi les essais multiples, la recherche et la vérification, sans modification des poids. Les résultats publiés montrent des gains dans certains protocoles, mais leur portée dépend des données accessibles, du budget et de la manière de sélectionner la réponse.

Distinguer adaptation, apprentissage et calcul supplémentaire

L’inférence désigne l’utilisation d’un modèle pour produire une sortie. Elle n’impose pas que tout le système reste figé : une application peut effectuer plusieurs appels, maintenir un état ou lancer une optimisation avant de rendre sa réponse.

Le vocabulaire recouvre toutefois des mécanismes différents. Le test-time scaling augmente les ressources consacrées à la résolution. Le test-time adaptation adapte le système aux observations rencontrées. Le test-time training désigne plus précisément une procédure d’apprentissage exécutée pendant cette phase, généralement par optimisation de paramètres.

Mécanisme	Ce qui change	Signal utilisé	Persistance possible
Apprentissage en contexte	Le contexte et les activations	Instructions et démonstrations	Dans le contexte conservé
Génération de plusieurs candidats	Les solutions explorées	Échantillonnage, vote ou vérificateur	Dans l’état de recherche
Adaptation de paramètres	Certains poids ou adaptateurs	Fonction de perte locale	Temporaire ou continue
Recherche de programmes	Les programmes candidats	Exécution sur les exemples	Dans les solutions retenues

Ces catégories peuvent se combiner. Un système peut adapter un modèle, générer plusieurs programmes, puis les exécuter pour sélectionner une réponse. Son résultat appartient alors à cette chaîne complète. Pour comprendre un score, vous devez identifier les composants effectivement utilisés, au lieu de déduire le mécanisme du seul mot « raisonnement ».

Construire un signal d’apprentissage sans la réponse finale

Un apprentissage local nécessite un objectif calculable. Si la solution recherchée est inconnue, le système doit exploiter autre chose : des démonstrations disponibles, une propriété des données ou une tâche auxiliaire dont la réponse peut être construite automatiquement.

Yu Sun et ses coauteurs décrivent cette approche dans Test-Time Training with Self-Supervision for Generalization under Distribution Shifts, publié à ICML en 2020. Leur méthode transforme une observation de test non étiquetée en problème auto-supervisé, met à jour les paramètres, puis réalise la prédiction. Ils rapportent des améliorations sur des évaluations de classification d’images soumises à des changements de distribution.

Le principe ne donne cependant pas accès à une correction gratuite. Un objectif auxiliaire peut devenir plus facile sans que la tâche principale soit mieux résolue. Il faut mesurer séparément la baisse de cette perte et l’amélioration des réponses attendues.

Prenons une situation hypothétique : un système reçoit des documents issus d’un nouveau scanner. Il pourrait s’adapter à certaines régularités visuelles de ces documents, mais cela ne garantit pas une meilleure lecture des montants. L’évaluation doit porter sur les champs correctement extraits. L’objectif local est un moyen d’apprentissage ; le critère métier reste la mesure du résultat.

Adapter la confiance ne garantit pas la justesse

Une autre famille de méthodes exploite directement les prédictions du modèle. L’entropie mesure ici la dispersion de leur distribution : une prédiction concentrée sur une classe possède une entropie plus faible qu’une prédiction hésitante.

Dans Tent, présenté à ICLR en 2021, Dequan Wang, Evan Shelhamer et leurs coauteurs proposent de minimiser cette entropie pendant le test. La méthode estime des statistiques de normalisation et optimise des transformations affines par canal. Les auteurs rapportent notamment une réduction des erreurs sur des jeux de classification comportant des corruptions d’images.

Cette approche concerne un cadre précis. Elle ne justifie pas une règle générale selon laquelle augmenter la confiance rendrait une réponse plus exacte. Pour un système déjà engagé dans une mauvaise interprétation, renforcer sa préférence pourrait au contraire stabiliser l’erreur.

Dans une évaluation, il faut donc observer les erreurs et la confiance séparément. Vérifiez aussi ce qui arrive lorsque les données changent brutalement, lorsque les catégories sont déséquilibrées ou lorsque les observations arrivent isolément. Une méthode évaluée par lots ne peut pas être supposée équivalente dans un service qui traite chaque demande indépendamment.

Le choix des paramètres modifiables compte également. Adapter un petit sous-ensemble limite l’ampleur des changements, mais ne dispense ni d’une comparaison avec le modèle figé ni d’une procédure de restauration.

Sur ARC, apprendre à partir des démonstrations disponibles

Dans les tâches de grilles d’ARC, des exemples d’entrée et de sortie accompagnent un nouveau problème. Le système doit en déduire une transformation applicable à une entrée supplémentaire. La page de référence sur ARC-AGI détaille cette logique et les différences entre les ensembles d’évaluation.

L’adaptation exploite les démonstrations comme données d’apprentissage locales. On peut, par exemple, réserver un exemple connu pour vérifier une hypothèse construite à partir des autres. Une transformation des couleurs ou de l’orientation peut aussi fournir des variantes, à condition de préserver la relation recherchée.

La publication d’Ekin Akyürek et de ses coauteurs, intitulée initialement The Surprising Effectiveness of Test-Time Training for Abstract Reasoning, porte dans sa révision du 25 mars 2025 le titre The Surprising Effectiveness of Test-Time Training for Few-Shot Learning. Elle rapporte une précision de 53,0 % sur l’ensemble public de validation d’ARC avec un modèle de 8 milliards de paramètres, et de 61,9 % en combinaison avec des méthodes de synthèse de programmes.

Ces scores ne décrivent donc ni un modèle général utilisé sans préparation ni une adaptation isolée de tout dispositif. La publication étudie notamment la préparation préalable, les données locales et les variantes d’inférence. Le résultat hybride ne doit pas être attribué au seul changement des poids.

Ce que les résultats publics permettent de conclure

Les expériences publiques servent à comprendre les mécanismes et à reproduire les comparaisons. Elles permettent aussi aux chercheurs d’ajuster leurs méthodes. Cette double fonction impose de distinguer un jeu de développement d’une évaluation réellement tenue à distance des choix techniques.

Le bilan officiel d’ARC Prize publié le 6 décembre 2024 souligne les progrès obtenus par la synthèse de programmes guidée par apprentissage profond, le test-time training et leur combinaison. Il rapporte notamment un score privé de 53,5 % pour l’équipe the ARChitects. Ce résultat appartient à un autre ensemble et à un autre protocole que les scores publics cités précédemment.

La comparaison utile porte sur des systèmes évalués dans les mêmes conditions. Elle doit préciser les exemples accessibles, les tentatives autorisées, le temps disponible et la règle de réussite. Une réponse trouvée parmi de nombreux candidats ne constitue pas automatiquement une réponse sélectionnée correctement par le système.

Évitez aussi de transformer une performance sur des grilles en affirmation sur toutes les tâches nouvelles. La découverte d’une transformation visuelle, la rédaction d’un contrat et la planification d’actions comportent des contraintes différentes. Un gain sur un benchmark établit d’abord un résultat sur ce benchmark.

L’article Comment lire les classements des modèles complète cette lecture : un pourcentage devient interprétable quand le protocole et les ressources qui l’accompagnent sont connus.

Calculer davantage avec des poids figés

L’alternative à l’adaptation paramétrique consiste à mieux exploiter un modèle existant. On peut générer des réponses indépendantes, réviser une tentative, explorer plusieurs branches ou demander à un vérificateur de noter les étapes.

Charlie Snell, Jaehoon Lee, Kelvin Xu et Aviral Kumar étudient ces arbitrages dans Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters, soumis le 6 août 2024. Ils rapportent, sur des problèmes mathématiques, une efficacité du calcul au test améliorée de plus d’un facteur quatre par rapport à une référence best-of-N. Leur conclusion dépend notamment de la difficulté des problèmes et de l’allocation du budget.

Le résultat ne signifie pas que prolonger toute génération améliore automatiquement sa qualité. Une recherche doit pouvoir atteindre de bonnes solutions, puis les reconnaître. Si les propositions restent fausses ou si le vérificateur préfère des erreurs convaincantes, le calcul supplémentaire peut être mal employé.

Le calcul ne passe d’ailleurs pas nécessairement par davantage de texte. Scaling up Test-Time Compute with Latent Reasoning, publié en février 2025, explore une architecture qui répète un bloc récurrent dans l’espace latent. Cette piste distingue la profondeur du traitement interne de la longueur de la réponse visible.

Pour l’utilisateur, une réponse longue n’est donc pas une mesure suffisante de l’effort utile. Il faut examiner les performances, le temps et les ressources du système.

Le vérificateur et la règle d’arrêt déterminent l’utilité

Un générateur propose ; un mécanisme de sélection décide de ce qui sera rendu. Cette sélection peut reposer sur une exécution, un vote, une mesure de cohérence ou un modèle évaluateur. Chaque option introduit ses propres limites.

Dans un exemple hypothétique de transformation de tableau, plusieurs programmes peuvent reproduire tous les exemples disponibles. Ils peuvent pourtant diverger sur une nouvelle entrée. La compatibilité avec les démonstrations élimine certaines erreurs, sans identifier nécessairement la règle attendue.

Un vote majoritaire comporte une difficulté comparable. Des réponses concordantes peuvent partager la même hypothèse fausse. Pour juger l’intérêt des essais multiples, mesurez leur diversité utile, puis la capacité de la sélection à retenir les bonnes propositions.

La règle d’arrêt doit être définie avant l’évaluation. Elle peut dépendre d’un budget maximal, d’une validation externe ou d’une absence de progrès. Une confiance déclarée par le modèle ne suffit pas à établir qu’une solution a été vérifiée.

Pour une application, formulez explicitement le comportement en cas d’incertitude : rendre une réponse accompagnée de réserves précises, demander une information manquante ou transmettre à un humain. Le système doit pouvoir s’arrêter sans fabriquer une certitude. L’article Les LLM raisonnent-ils vraiment ? examine les difficultés d’interprétation du comportement observé.

Mesurer le coût complet plutôt que les seuls tokens

Le calcul supplémentaire déplace une partie de la dépense vers chaque problème traité. Pour comparer deux stratégies, il faut mesurer leur coût total par tâche, puis leur coût par tâche correctement résolue.

Poste	Génération et recherche	Adaptation de paramètres
Calcul principal	Produire et évaluer des candidats	Optimiser, puis produire une réponse
Mémoire	Contextes, activations, branches	Paramètres adaptés et état d’optimisation
Délai	Essais séquentiels ou parallèles	Préparation et mises à jour locales
Dépense à comptabiliser	Générateur, vérificateur et outils	Adaptation, inférence et restauration
Difficulté opérationnelle	Orchestrer la sélection	Isoler et gérer les états modifiés

Un nombre identique de tokens ne représente pas nécessairement un calcul identique. Le modèle utilisé, les passes d’optimisation, les outils et le matériel changent la dépense. Si l’énergie n’est pas mesurée, mieux vaut publier le temps et la configuration que convertir arbitrairement la consommation en une estimation énergétique.

Le volume d’utilisation change aussi l’arbitrage. Une préparation partagée peut être amortie sur de nombreuses demandes, tandis qu’une adaptation propre à chaque problème reste une charge récurrente. À l’inverse, réserver un traitement coûteux aux demandes difficiles peut éviter de ralentir les demandes simples.

Le calculateur de prix LLM aide à estimer les appels facturés en tokens. Un bilan expérimental doit y ajouter les dépenses qui n’apparaissent pas dans cette facturation : calcul local, vérification, stockage temporaire et essais abandonnés.

Concevoir une évaluation qui isole le gain

Pour décider si une méthode mérite son surcoût, partez d’une référence figée et documentée. Fixez les données accessibles, la règle de sélection et le budget avant de consulter les réponses du jeu final.

Comparez ensuite les changements séparément : ajout d’exemples en contexte, essais multiples, adaptation locale, puis combinaison éventuelle. Sans cette séparation, une amélioration pourrait venir d’un meilleur format d’entrée ou d’une sélection plus efficace plutôt que de l’apprentissage au test.

Un compte rendu exploitable devrait indiquer :

la réussite finale selon la règle officielle ;
les ressources utilisées, y compris les tentatives écartées ;
les délais habituels et les cas les plus lents ;
les erreurs nouvelles introduites par la méthode ;
la stabilité entre exécutions et l’effet de l’ordre des tâches.

La gestion de l’état doit être explicite. En adaptation épisodique, chaque tâche repart d’un état initial. En adaptation continue, les changements s’accumulent. Les résultats ne répondent pas à la même question, puisque le second système bénéficie d’un historique.

Séparez également les données utilisées pour régler le taux d’apprentissage, choisir les transformations ou définir l’arrêt de celles qui servent au bilan final. Les démonstrations autorisées d’une tâche peuvent servir à l’adaptation ; sa réponse cachée ne doit pas servir à choisir les réglages.

Le guide Évaluer un agent IA fournit un cadre complémentaire pour relier ces mesures à un usage concret.

Généralisation : des interprétations à distinguer

François Chollet présente l’intelligence comme une efficacité d’acquisition de compétences, relativement aux connaissances préalables, à l’expérience et à la difficulté de généralisation, dans On the Measure of Intelligence, publié en novembre 2019. Cette perspective invite à distinguer le niveau de compétence obtenu des moyens informationnels employés pour l’atteindre.

L’adaptation au test pose précisément cette question : que peut apprendre un système des observations propres à un problème nouveau ? Le nombre d’exemples compte, mais aussi les connaissances acquises auparavant et les choix effectués par les concepteurs. La page sur la généralisation développe ces distinctions.

Les travaux présentés ici mettent toutefois l’accent sur des voies différentes. Akyürek et ses coauteurs montrent l’intérêt d’une optimisation locale de paramètres pour certaines tâches nouvelles. Snell et ses coauteurs étudient l’allocation du calcul entre recherche et révision. Ces résultats ne permettent pas de déclarer qu’une seule architecture serait nécessaire ou suffisante.

La divergence porte aussi sur le critère recherché. Pour un service opérationnel, réussir davantage sous un budget acceptable peut suffire à justifier une méthode. Pour une recherche sur l’intelligence générale, il faut en plus examiner la nouveauté, les connaissances préalables et le transfert entre domaines.

Une évaluation utile rend ces objectifs explicites. Elle peut démontrer un gain pratique sans prétendre établir une mesure complète de l’intelligence.

Choisir selon la tâche et la qualité du retour disponible

Le point de départ est la nature de l’information reçue pendant la résolution. Des démonstrations locales pertinentes peuvent justifier une adaptation. Une propriété vérifiable peut rendre la recherche utile. Des documents supplémentaires peuvent simplement nécessiter un meilleur contexte, sans fine-tuning.

Pour une extraction suivant des exemples spécifiques à un client, comparez d’abord le contexte seul à l’adaptation locale. Pour une production de code accompagnée de tests fiables, examinez l’intérêt des candidats multiples et de leur exécution. Pour une question dont aucune source ne permet de vérifier la réponse, davantage d’essais ne résout pas le manque de preuve.

Prévoyez aussi la gestion des données. Si des paramètres adaptés sont conservés, déterminez qui pourra les réutiliser et comment revenir à l’état initial. Si le traitement est temporaire, vérifiez que la restauration couvre tous les états concernés, pas seulement le texte de la conversation.

Les éléments à retenir pour comparer une méthode :

Identifier ce qui change : contexte, recherche, statistiques ou paramètres.
Exiger un résultat associé à un protocole et à un budget explicites.
Mesurer la sélection finale, au-delà de l’existence d’un bon candidat.
Vérifier les régressions, la persistance des changements et le coût complet.

Le dossier AGI et recherche replace ces mécanismes parmi les approches étudiées pour apprendre et résoudre des tâches nouvelles. Leur intérêt se juge à leur capacité mesurée à transformer l’information disponible en réponses correctes, dans les contraintes de l’usage visé.

Pages liées

Questions fréquentes

Quelle différence entre test-time adaptation et test-time scaling ?

Le premier terme désigne une adaptation aux données rencontrées pendant l’utilisation, souvent par modification de paramètres ou de statistiques internes. Le second désigne l’augmentation du calcul consacré à une réponse. Une recherche parmi plusieurs solutions relève du second sans nécessairement relever du premier.

Un modèle apprend-il quand on lui demande de réfléchir davantage ?

Cette consigne ne prouve aucune modification de ses poids. Elle peut changer le texte produit ou la stratégie de génération, selon le système. Pour parler d’apprentissage paramétrique, il faut identifier une procédure d’optimisation et les paramètres qu’elle modifie.

Peut-on adapter un modèle sans connaître la bonne réponse ?

Oui, si les données permettent de construire un objectif auxiliaire ou si des démonstrations accompagnent la tâche. La réponse finale peut rester cachée. La difficulté consiste à vérifier que cet objectif aide à résoudre le problème au lieu de renforcer une erreur.

Les résultats sur ARC prouvent-ils que l’adaptation conduit à l’AGI ?

Ils montrent l’intérêt de certaines méthodes pour des problèmes d’abstraction visuelle dans un protocole donné. Une conclusion sur l’AGI demanderait des évaluations plus larges, avec des tâches nouvelles, des ressources contrôlées et une analyse des connaissances préalables.

Faut-il conserver les modifications après chaque tâche ?

Cela dépend du protocole. Une adaptation épisodique restaure l’état initial, tandis qu’une adaptation continue conserve des changements entre les observations. Cette décision doit être explicite, car elle influence la reproductibilité et les risques de transfert entre utilisateurs.