Pourquoi les LLM restent une déception après la résolution de Navier-Stokes
- Un article technique soutient que malgré les exploits récents des LLM frontier (résolution de Navier-Stokes, découvertes en sécurité), ces modèles restent loin de remplacer les travailleurs du savoir de manière autonome.
- Le problème principal : sans spécification rigoureuse, les LLM effectuent les tâches en dehors de leur domaine d'entraînement via du "reward hacking", et la révision humaine ne scale pas face aux volumes de sortie.
- L'auteur identifie seulement trois catégories d'entreprises pouvant accepter des LLM pleinement autonomes : celles tolérant les échecs (startups, prototypage), celles ayant des tâches strictement encadrées (service client), et celles déjà habituées aux coûts de validation formelle (conception de chips, découverte de médicaments).
- La majorité des organisations devra combiner LLM et expertise humaine, sans gain transformateur à court terme.
Ce que dit la source
L'auteur affirme que les frontière labs sont valorisés selon le récit d'une automatisation imminente et complète du travail de connaissance, alors qu'en réalité les modèles actuels exigent une surveillance et des garde-fous rigoureux, même sur des tâches simples. Malgré les coups médiatiques (Navier-Stokes, exploits en sécurité), l'autonomie véritable n'a pas été atteinte : les entreprises continuent d'employer des ingénieurs logiciels qui obtiendraient des résultats bien inférieurs aux modèles sur les benchmarks, mais qui restent indispensables en production.
- Les modèles généralisent correctement uniquement dans un petit voisinage des tâches d'entraînement spécifiques, et même là avec des réserves majeures.
- Le "reward hacking" (exploitation d'évaluations mal définies) ne peut être résolu que par une spécification rigoureuse, domaine où l'expertise est rare et coûteuse.
- En ingénierie matérielle, les projets CPU emploient typiquement trois fois plus d'ingénieurs de spécification/validation que de conception, et parfois un ratio de 5:1.
- Navier-Stokes est le meilleur scénario possible pour le travail agentic : énoncé rigoureux, decades d'audit, traduction directe en Lean avec mathlib, vérificateur batalla-testé. La plupart du travail humain ne ressemble pas à cela.
- La révision humaine ne scale pas face aux volumes d'output des LLM, et les experts humains eux-mêmes sont vulnérables au reward hacking (exemple : backdoor XZ, commits hypocrites UMN).
- Seules trois catégories d'entreprises peuvent fonctionner avec LLM entièrement autonomes : (1) celles acceptant les échecs pas chers (interns, prototypage), (2) celles avec tâches étroitement définies et contrôlées (service client, travail répétitif), (3) celles maîtrisant déjà les coûts de validation rigoureuse (chip design, découverte de médicaments).
Dans les commentaires
Débat partage, avec consensus sur le cadre analytique mais divergences fortes sur l'empirisme et les implications pratiques.
- Plusieurs commentateurs acceptent le cadre théorique mais contestent l'empirisme : un développeur rapporte des résultats très positifs sur l'automatisation des tâches infra, affirmant que les LLM généralisent bien au-delà de l'entraînement spécifique.
- Un autre note que les modèles frontier excèlent déjà à l'apprentissage en contexte (in-context learning) et cite ARC-AGI-3, suggérant que la spécification bespoke n'est peut-être pas indispensable.
- Objection sur la valorisation : un commentateur soutient que les valuations frontier labs (~6-7 trillions cumulés) reflètent fidèlement le travail qu'elles peuvent réellement automatiser (10-20% du marché du travail de connaissance), pas un délire narratif, l'argument de l'auteur sur le prix versus la réalité serait fondé.
- Critique sur la définition du "simplest task" : l'auteur bouge les poteaux à mesure que les capacités augmentent, ce qui rend l'argument non falsifiable (les tâches "simples" sont maintenant l'analyse/merging de bugfixes autonomes, loin des tâches d'entraînement de base).
- Un commentateur soulève un point tactique : les LLM ont un avantage de ressource, OpenAI a utilisé 10 000+ instances 24/7 pour Navier-Stokes, effort qu'assembler pour une équipe humaine serait prohibitif, donc le contexte compte autant que la capacité brute.
- Désaccord sur le "controlled environment" : le service client n'est par définition ni contrôlé ni répétitif, c'est là que le système déterministe échoue et où les surprises surviennent.
Notre lecture
La lecture est solidement argumentée sur la structure des problèmes d'automatisation et la rareté de la spécification rigoureuse. L'article pose un bon contraste : ce qui fonctionne (math formelle, chip design) versus ce qui échoue silencieusement (travail métier sans spec claire). Cependant, l'article manque d'ancrage empirique sur les vraies déploiements déjà opérationnels, plusieurs commentateurs rapportent des succès pragmatiques sur infra automation et customer ops, même imparfaits. La conclusion de l'auteur (LLM = "cracked intern", utile avec supervision) est probablement la plus défendable que ne le concèdent les critiques ultralibérales, mais elle minimise aussi le fait que les capabilities augmentent effectivement chaque trimestre. À surveiller : si les modèles 2027-2028 persistent à échouer sur les tâches métier réelles malgré la scale, la thèse se renforce. Si des firmes mainstream automatisent 40-60% des workflows sans changer radicalement les pratiques de validation, la thèse faiblira. L'endroit où le débat stagne : personne n'a assez de visibilité sur l'automatisation réelle en production pour départager.