Mesurer la capacité de l’IA à mener des tâches de longue durée

• Une nouvelle métrique est proposée pour mesurer les performances à partir de la « longueur » des tâches qu’un modèle d’IA peut accomplir intégralement
• L’analyse montre que, sur les 6 dernières années, la durée des tâches que l’IA peut achever de manière autonome a doublé environ tous les 7 mois
• Les tâches qu’un expert humain termine en moins de 4 minutes réussissent presque à 100 %, mais celles qui demandent plus de 4 heures affichent un taux de réussite inférieur à 10 %
• Si cette tendance se maintient, on prévoit que l’IA pourra exécuter de façon autonome des projets s’étalant sur plusieurs semaines dans les prochaines années
• L’étude a des implications importantes pour les benchmarks d’IA, la prévision des capacités futures et la gestion des risques

---

Présentation de l’étude

• METR propose une nouvelle méthode pour mesurer la durée des tâches que l’IA est capable de mener à bien
  • Le critère de mesure est le temps nécessaire à un expert humain pour accomplir la tâche
  • La relation entre la probabilité de réussite du modèle et le temps de travail humain est modélisée par une courbe logistique
• Cette approche est présentée comme un indicateur utile pour évaluer l’utilité réelle de l’IA
  • Elle compense les limites des benchmarks existants, souvent centrés sur la résolution de problèmes isolés

Principaux résultats

• Limites de performance des modèles actuels
  • Les tâches qu’un humain réalise en moins de 4 minutes réussissent presque à 100 %
  • Les tâches qui prennent plus de 4 heures ont un taux de réussite inférieur à 10 %
  • Exemple : Claude 3.7 Sonnet atteint environ 50 % de réussite sur des tâches d’une durée d’environ 1 heure
• Tendance d’amélioration des performances
  • Au cours des 6 dernières années, la longueur des tâches pouvant être accomplies avec un niveau de confiance de 50 % a doublé environ tous les 7 mois
  • L’analyse en échelle logarithmique confirme une croissance exponentielle continue
  • Si la tendance se maintient, des tâches sur une base hebdomadaire pourraient devenir réalisables d’ici 2 à 4 ans

Méthodologie et validation

• Validation fondée sur des jeux de données
  • Le temps d’exécution humain a été relevé pour divers groupes de tâches (logiciel, raisonnement, etc.)
  • Une augmentation exponentielle similaire a aussi été observée dans le jeu de données SWE-Bench Verified
  • Dans ces données, on observe une vitesse de doublement inférieure à 3 mois
• Analyse de sensibilité
  • Vérification de la robustesse face à divers facteurs, comme le choix des modèles et des tâches ou le bruit
  • Dans les simulations prédisant le moment où des tâches d’un mois deviendraient réalisables, la tendance se maintient même avec une forte erreur de mesure

Interprétation et limites

• L’étude explique l’écart entre les performances de l’IA sur les benchmarks et son utilité réelle
  • Elle peut surpasser l’humain sur des questions d’examen, mais reste insuffisante pour des projets réels de longue durée
• L’incertitude liée à l’extrapolation de la tendance est reconnue
  • En n’utilisant que les données 2024~2025, le moment où l’IA pourrait réaliser des tâches mensuelles est avancé d’environ 2,5 ans
  • Il est mentionné que la tendance récente pourrait mieux prédire les performances futures que les données plus anciennes

Conclusion et portée

• L’approche consistant à mesurer les performances de l’IA par la « longueur des tâches » permet
  • de quantifier l’amélioration des performances sur différents niveaux de difficulté et domaines
  • de proposer une interprétation absolue des performances, directement reliée à l’impact dans le monde réel
• Si la croissance exponentielle continue se poursuit,
  • des projets autonomes s’étalant sur un mois pourraient devenir possibles d’ici 10 ans
  • cela s’accompagnerait à la fois de bénéfices potentiels considérables et de risques majeurs
• Les données de l’étude et le code d’analyse sont publiés sur GitHub, afin d’encourager les travaux de suivi et les expériences de reproduction
  • Infrastructure associée : vivaria, eval-analysis-public

[crawler]

Ça a l’air d’être un très bon benchmark.
Quand on regarde les outils de coding IA ces derniers temps, beaucoup font établir un plan à l’avance et les font agir en mode Agent, donc je me demande aussi si cela a réellement un impact significatif sur le taux de réussite à long terme.

[GN⁺]

Avis Hacker News

• Récemment, sur un de mes projets hobby, j’ai juste demandé « ajouter la recherche vectorielle », et Opus a configuré manticore, récupéré un modèle d’embeddings, créé un outil pour migrer l’index de mots-clés existant, et même mis en place le frontend
  C’était un prompt d’une ligne digne d’un tweet, et tout a été terminé en 15 minutes pendant que moi je jouais à Kirby Air Riders
  En revanche, ce qui m’a déçu, c’est que je n’ai absolument rien appris sur la mise en place d’une recherche vectorielle au cours du processus. Au final, c’était la fonctionnalité qui comptait, l’apprentissage était secondaire
  • Je ne pense pas que construire les choses de manière délibérément plus lente soit forcément une meilleure façon d’apprendre
    Au lieu d’y passer 4 heures soi-même, il est bien plus efficace de laisser un agent le faire en 15 minutes pendant qu’on fait autre chose, puis de consacrer 30 minutes à lire le code, le modifier et poser des questions
    30 minutes d’apprentissage concentré peuvent valoir mieux que 4 heures d’essais-erreurs
  • Mais en procédant ainsi, on finit par obtenir un énorme bloc de code impossible à maintenir
    L’IA elle aussi finit par perdre la structure du code, et on devient au final un client dépendant d’Opus
  • Opus et Anthropic sont clairement au plus haut niveau, mais à chaque utilisation, ça me fait l’effet d’une restauration rapide intellectuelle
    Avant, j’aimais résoudre des problèmes en Scala en écoutant de la musique ; maintenant, obtenir juste le résultat trop facilement laisse au contraire une sensation de vide
  • Je suis totalement d’accord avec la phrase : « Je voulais la fonctionnalité, pas apprendre à la construire »
    Moi aussi, quand je crée des modèles de trading, je préfère que le LLM écrive le code plutôt que d’avoir à apprendre moi-même les graphiques
    Grâce à ça, je ne perds pas de temps sur des détails d’API sans importance et je peux me concentrer uniquement sur les parties qui demandent de vraies décisions
  • Au fait, ce code de recherche vectorielle, tu pourrais éventuellement le partager ?
• Avant de le vivre directement, je ne comprenais pas vraiment la notion de « long task »
  En portant un parseur Python HTML5 vers JavaScript, j’ai lancé Codex CLI sur 9 200 html5lib-tests, et c’était impressionnant de le voir tourner en boucle pendant plus de 4 heures à résoudre les problèmes
  J’ai résumé ça ici
  • Les « 4 heures de travail » de METR ne signifient pas que l’IA met réellement 4 heures, mais correspondent à une difficulté qui prendrait 4 heures à un humain
    Dire qu’Opus 4.5 peut gérer ce type de tâche avec 50 % de fiabilité signifie que le temps d’exécution réel est bien plus court
    Quand on franchira des seuils comme 8 heures ou 40 heures, ça deviendra encore plus intéressant
  • Cette métrique ne mesure pas la vitesse réelle de l’IA, mais la difficulté à l’échelle humaine
    Cela montre bien que, même si les benchmarks tombent vite, l’automatisation du travail réel reste difficile
  • Dans le « human hours equivalent » de METR, ce qui compte, c’est quel humain on prend comme référence
    Quelqu’un de familier avec l’écosystème jq ou PyPI, ou avec les annotations TypeScript, pourrait finir bien plus vite
    Au fond, l’attrait de l’IA, c’est de pouvoir obtenir immédiatement une aide de niveau expert
  • En revanche, quand on lance de longues tâches avec Codex ou Claude code, il y a beaucoup trop de demandes d’autorisation, et ça s’arrête souvent en cours de route
    La plupart des modèles disent « passons à l’étape suivante » puis s’interrompent d’eux-mêmes
  • GPT5.2 en particulier demande beaucoup trop souvent l’intervention de l’utilisateur, au point qu’il est difficile de lui faire enchaîner plus de 2 minutes de travail
    Je me demande si quelqu’un a trouvé un moyen de régler ce problème
• Je reste prudent dans mon évaluation des modèles, mais la différence entre Opus 4.5 et Sonnet 4.5 s’est clairement fait sentir
  L’écart de prix a aussi diminué par rapport à avant, ce qui renforce leur intérêt en usage réel, et Haiku 4.5 est lui aussi assez utile quand on active le reasoning
  Il est particulièrement adapté aux petits outils ou à l’édition d’une seule page
• Je pense que l’apprentissage du logiciel se divise en deux phases : exploration et exploitation
  Grâce aux LLM, ces deux phases se combinent naturellement
  Par exemple, quand je crée une animation AnimeJS, j’apprends en regardant CCAgent écrire le code, puis je restructure et refactorise moi-même ensuite
  De cette façon, on gagne à la fois du temps et du contrôle créatif
• Opus ressemble à un bond plus important que GPT 5.1, mais sur un critère de 80 % de fiabilité, GPT 5.1 garde l’avantage
  Autrement dit, GPT 5.1 convient mieux aux tâches courtes, tandis qu’Opus est plus adapté aux tâches longues
  • Avec un taux de réussite de 50 %, le gaspillage de tokens coûteux est important, mais j’espère que les modèles open source atteindront ce niveau d’ici l’an prochain
• Le point clé de METR, c’est qu’il mesure la complexité en termes de « temps humain équivalent »
  Confier une tâche de 4 heures avec un taux de réussite de 50 %, c’est pratiquement un pari ; si l’on ajoute ensuite le débogage en cas d’échec, le coût devient élevé
  Je pense donc qu’il vaut mieux mettre en place des checkpoints de revue humaine toutes les 30 minutes
  Cela dit, la capacité de l’IA à se rétablir seule quand elle se bloque en cours de route est aussi importante
  • Mais en 30 minutes, l’IA produit tellement de choses que la revue devient un cauchemar
    En apparence tout semble correct, mais il y a souvent des bugs subtils qui ne se révèlent que plus tard
    C’est pour ça que je n’utilise toujours pas d’agents pour les tâches importantes ; en plus, ils enlèvent une partie du plaisir du travail
  • Même si 4 heures ont été « perdues », si on a fait autre chose pendant ce temps, ce n’est pas vraiment une perte
    Si on obtient un résultat une fois sur deux, cela peut quand même être un pari rentable en temps
  • Même en cas d’échec, ce qu’on perd réellement, ce ne sont que quelques minutes de travail de l’IA, donc c’est excellent pour explorer des prototypes
    On peut tester rapidement plusieurs approches, et même l’échec permet d’apprendre
• Il faudrait aussi des graphiques aux seuils de fiabilité de 95 % ou 99 %
  On verrait alors plus clairement pourquoi les LLM échouent encore si souvent sur des tâches pourtant faciles pour les humains
• Je pense que l’optimisation des performances constitue un très bon benchmark pour mesurer l’intelligence réelle d’une IA
  On peut vérifier les résultats de façon chiffrée, plus le code est court mieux c’est, et cela demande une pensée systémique plutôt qu’une simple combinaison
  Jusqu’ici, Gemini Pro 3 a été le plus performant sur l’optimisation de code SIMD
• Le problème avec un taux de réussite de 50 %, c’est que la probabilité chute brutalement quand on doit réessayer
  Si on répète plusieurs fois une tâche de 4 heures, la probabilité de réussite peut tomber à 6,25 %
  • Cela dit, plutôt que de parler de « malchance », on peut aussi considérer qu’après un premier échec, la probabilité de succès de la tentative suivante peut changer
    Tout dépend de la nature de la tâche