💬 NLP

Evaluating LLMs on Real-World Software Performance Optimization

Cet article présente SWE-Pro, un benchmark rigoureux au niveau du dépôt dérivé de 102 optimisations d'experts qui révèle que les grands modèles de langage actuels échouent de manière significative à égaler la performance humaine dans l'optimisation de logiciels en conditions réelles, en n'obtenant que des gains négligeables par rapport aux accélérations et réductions de mémoire substantielles fournies par les ingénieurs experts.

Auteurs originaux : Ezgi Sarıkayak, Wenchao Gu, Hesham Ghonim, Chunyang Chen

Publié 2026-06-25

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Ezgi Sarıkayak, Wenchao Gu, Hesham Ghonim, Chunyang Chen

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

La vue d'ensemble : Le « Chef Rapide » vs Le « Maître Chef »

Imaginez que vous avez une cuisine de restaurant immense et très occupée (un code source de logiciel du monde réel). Vous engagez une équipe de Chefs IA (Grands Modèles de Langage ou LLM) pour aider les Maîtres Chefs (experts humains) à cuisiner plus vite et à utiliser moins d'énergie.

Les Maîtres Chefs savent exactement comment couper les légumes efficacement, organiser la réserve pour gagner des étapes et ajuster la température du four pour économiser du combustible. Ils ont des années d'expérience.

Les Chefs IA sont incroyablement intelligents. Ils peuvent lire la recette, comprendre les ingrédients et même écrire de nouvelles recettes qui ont l'air parfaites sur le papier. Mais la grande question posée par cet article est la suivante : Ces Chefs IA peuvent-ils réellement faire fonctionner la cuisine plus vite et consommer moins d'énergie dans le monde réel, ou font-ils simplement en sorte que les choses paraissent bonnes sans vraiment améliorer la vitesse ?

Le Problème : Les anciens tests étaient trop simples

Auparavant, les chercheurs testaient les Chefs IA en leur donnant une seule tâche minuscule : « Coupe cette carotte ».

La faille : Dans une vraie cuisine, on ne coupe pas juste une carotte. On en coupe 10, 1 000 ou 100 000. Parfois les carottes sont mouillées ; parfois elles sont congelées.
Le résultat : Les anciens tests consistaient à juger un chef sur sa capacité à couper une seule carotte dans une pièce calme. Ils ne testaient pas si le chef pouvait gérer l'heure de pointe avec 1 000 commandes, ou si le chef utilisait accidentellement trop d'eau (mémoire) en essayant d'être rapide.

L'article soutient que ces anciens tests étaient trop faciles et ne détectaient pas le « bruit » (les fluctuations aléatoires) qui se produit dans les vrais ordinateurs.

La Solution : SWE-Pro (Le simulateur de « Cuisine Réelle »)

Les auteurs ont construit un nouveau test beaucoup plus difficile appelé SWE-Pro. Considérez cela comme une simulation de haute technologie d'une cuisine chaotique et réelle.

Des recettes réelles : Ils n'ont pas inventé de tâches fictives. Ils ont examiné 102 exemples réels où des experts humains avaient optimisé avec succès du code dans des projets open-source célèbres (comme pandas, scikit-learn et xarray). Ce sont les « Standards d'Or » des recettes.
Le test de résistance : Au lieu de tester l'IA sur une seule entrée, SWE-Pro les teste sur de nombreux scénarios différents.
- Analogie : Ce n'est pas seulement « coupe 10 carottes ». C'est « coupe 10 carottes », puis « coupe 100 », puis « coupe 10 000 », et fais-le avec des carottes mouillées, des carottes congelées et des carottes de différentes tailles.
Le filtre à bruit : Les ordinateurs sont désordonnés. Parfois, un programme tourne lentement simplement parce que l'ordinateur pensait à autre chose (comme un serveur qui fait tomber un plateau). SWE-Pro exécute les tests encore et encore, en utilisant un « filtre à bruit » statistique spécial pour s'assurer que si l'IA dit « Je suis plus rapide », c'est réellement vrai et non pas juste un coup de chance.
Deux mesures : Ils mesurent deux choses :
- Vitesse : La rapidité avec laquelle la nourriture est servie (Temps d'exécution).
- Mémoire : L'espace de comptoir et de stockage utilisé par le chef (Mémoire de pointe et utilisation de la mémoire pondérée par le temps).

Les Résultats : Les Chefs IA sont en difficulté

Lorsqu'ils ont soumis les meilleurs modèles d'IA (comme GPT-5.2, Claude Sonnet 4.6, etc.) à ce test rigoureux de la « Cuisine Réelle », les résultats ont été surprenants et décevants.

Les Experts Humains (Standard d'Or) : Lorsque les humains ont optimisé le code, ils ont obtenu des améliorations massives.
- Analogie : Le Maître Chef a réduit le temps de cuisson de 15 fois et a réduit l'espace de comptoir nécessaire de 171 fois. Ils ont trouvé des moyens ingénieux de réorganiser la cuisine pour économiser d'énormes quantités de ressources.
Les Chefs IA :
- Vitesse : Les modèles d'IA n'ont fait que très peu de différence. Dans la plupart des cas, leurs « améliorations » étaient si petites qu'elles ne pouvaient pas être distinguées du bruit aléatoire.
- Mémoire : Les modèles d'IA n'ont presque jamais réussi à économiser de la mémoire. Ils étaient quasi inexistants dans ce domaine.
- Le problème du « Pas de Signal » : Même lorsque l'IA écrivait du code qui passait les tests de base (la nourriture avait bon goût), elle produisait rarement un gain de vitesse mesurable. C'était comme un chef qui coupait les carottes proprement mais mettait exactement le même temps qu'avant.
- La Régression : Parfois, l'IA rendait les choses plus lentes. Un modèle (GPT-5.2) a même rendu le code 30 % plus lent en moyenne !

La conclusion clé

L'article conclut que si l'IA est excellente pour écrire du code qui semble correct et respecte les règles, elle est actuellement très mauvaise dans l'ingénierie profonde et complexe requise pour rendre un logiciel nettement plus rapide ou moins gourmand en mémoire dans des scénarios du monde réel.

L'écart : Il existe un fossé énorme entre ce que l'IA peut faire aujourd'hui et ce que les ingénieurs humains experts peuvent accomplir.
Le goulot d'étranglement : Le problème n'est pas que l'IA ne peut pas faire une grande amélioration si elle a de la chance (elle le peut, dans de rares cas). Le problème est que l'IA ne peut pas trouver de manière fiable les opportunités de réaliser ces améliorations en premier lieu.

En bref : Si vous demandez à une IA de « rendre ce logiciel plus rapide », elle écrira peut-être un correctif qui a l'air bien, mais n'attendez pas qu'elle accélère réellement votre ordinateur ou qu'elle économise votre mémoire. Pour l'instant, ce travail appartient toujours aux experts humains.

Résumé Technique : SWE-Pro – Évaluer les LLM sur l'optimisation des performances logicielles en conditions réelles

1. Énoncé du Problème

L'optimisation des performances logicielles est une tâche d'ingénierie complexe et manuelle, caractérisée par des compromis multidimensionnels (par exemple, temps d'exécution vs mémoire) et une grande sensibilité aux environnements d'exécution et aux données d'entrée. Bien que les modèles de langage de grande taille (LLM) aient démontré des compétences en génération de code et en correction de bugs, leur capacité à effectuer une optimisation des performances au niveau du dépôt (repository-level) reste sous-évaluée.

Les benchmarks existants souffrent de limitations critiques :

Simplification excessive : Beaucoup se concentrent sur des fonctions isolées (ex. : EffiBench) ou des charges de travail uniques et fixes, échouant ainsi à capturer la complexité des dépôts réels.
Déficiences métriques : Les cadres actuels évaluent souvent uniquement le temps d'exécution, négligeant l'utilisation de la mémoire et les compromis critiques temps-mémoire inhérents à l'optimisation.
Bruit de mesure : Les benchmarks reposent fréquemment sur un profilage à nombre fixe ou une agrégation grossière, ce qui occulte les fluctuations de performance spécifiques aux entrées et ne parvient pas à distinguer les gains réels du bruit environnemental (ex. : gigue de l'ordonnanceur, effets de cache).
Manque de rigueur statistique : Il existe un déficit de benchmarks employant une mesure adaptative et une convergence statistique pour garantir que les améliorations observées sont reproductibles et significatives.

Par conséquent, il reste incertain si les LLM actuels peuvent naviguer dans les complexités des performances logicielles réelles pour fournir des optimisations robustes de niveau expert.

2. Méthodologie : Le Benchmark SWE-Pro

Pour combler ces lacunes, les auteurs introduisent SWE-Pro, un benchmark au niveau du dépôt dérivé de 102 optimisations écrites par des experts à travers trois grandes bibliothèques Python de données : pandas, scikit-learn et xarray.

2.1 Construction du Jeu de Données

Source : Fusion de Pull Requests (PR) explicitement étiquetées comme liées à la performance, avec reconnaissance par les développeurs dans les journaux de modifications (changelogs) ou la documentation.
Validation : Une inspection manuelle garantit que les tâches sont reproductibles, impliquent des modifications du code source Python et représentent de véritables opportuns d'optimisation.
Standard de Référence (Gold Standard) : Chaque tâche inclut le code source original, le patch rédigé par l'expert (Solution Or) et un ensemble de tests de performance paramétrés.

2.2 Tests de Performance Paramétrés

Contra à les benchmarks utilisant des entrées fixes, SWE-Pro emploie des balayages de paramètres structurés pour évaluer les performances à travers diverses charges de travail.

Dimensions : Les tests font varier la taille des entrées, la distribution des données (parcimonie, duplication), le type de données et les configurations au niveau de la fonction.
Génération de Charge de Travail : Les paramètres sont combinés via des produits cartésiens pour générer des configurations d'exécution (médiane de 6 par tâche, jusqu'à 24), garantissant que l'évaluation capture comment les optimisations se généralisent ou se dégradent sous différentes conditions.

2.3 Cadre de Mesure Fiable

SWE-Pro implémente un pipeline de mesure hiérarchique et sensible au bruit pour assurer la signification statistique :

Itérations Adaptatives : Au lieu de comptes fixes, le système détermine dynamiquement le nombre d'itérations de mesure en fonction de la convergence de la largeur de l'intervalle de confiance relatif (RCIW) à 90 %.
Modélisation Hiérarchique du Bruit : Le cadre prend en compte à la fois le bruit intra-conteneur (gigue de l'ordonnanceur, comportement de l'interprète) et le bruit inter-conteneur (état du CPU, disposition de la mémoire) en exécutant les charges de travail dans des instances Docker fraîches.
Rapport Signal sur Bruit (SNR) : Seuls les effets de performance dépassant un seuil sensible au bruit (SNR ≥ 2) sont acceptés comme des améliorations valides.
Évaluation Multi-Métriques : Le benchmark suit trois métriques distinctes :
- Temps d'exécution (Runtime) : Temps d'exécution.
- Mémoire de Pointe (Peak Memory) : Empreinte mémoire maximale au-dessus de la ligne de base.
- Utilisation de la Mémoire Pondérée par le Temps (TWMU) : Une métrique normalisée intégrant la pression mémoire au fil du temps, calculée comme $\bar{m}_{twmu} = \frac{1}{T} \int_0^T \max(0, m(t) - m_{base}) dt$ .

2.4 Configuration Expérimentale

Modèles : Six LLM de pointe ont été évalués (GPT-5.2, Claude Sonnet 4.6, Kimi K2.5, Gemini 3.1 Flash-Lite, GLM-5.1, MiniMax M2.7).
Stratégies de Contexte : Les modèles ont été testés sous deux conditions de récupération :
- Oracle : Fichiers pertinents de vérité terrain fournis directement.
- BM25 : Contexte récupéré via la similitude lexicale à partir de l'état du dépôt.
Métriques d'Évaluation : Succès du patch (applicabilité), Correctitude Fonctionnelle (taux de réussite des tests) et Facteur d'Amélioration de la Performance (IF) calculé via la moyenne harmonique sur les charges de travail.

3. Résultats Clés

L'évaluation révèle un écart substantiel entre les capacités actuelles des LLM et l'ingénierie de niveau expert.

3.1 Génération de Patch et Correctitude

Applicabilité : Sous récupération Oracle, les taux d'application de patch variaient de 30,4 % à 97,1 %.
Correctitude : Même lorsque les patchs s'appliquaient avec succès, les taux de correctitude fonctionnelle étaient nettement inférieurs (de 18,6 % à 79,4 %), indiquant que les LLM produisent fréquemment du code syntaxiquement valide mais sémantiquement incorrect.
Impact de la Récupération : La performance chute davantage sous la récupération BM25, soulignant la sensibilité des tâches d'optimisation à la qualité du contexte.

3.2 Capacités d'Optimisation des Performances

Temps d'exécution : Les LLM peinent à produire des gains de temps d'exécution mesurables.
- Seule une petite fraction des tâches a passé le filtre SNR (ex. : Gemini 3.1 Flash a atteint un taux de réussite de 12,7 % sous Oracle).
- L'ampleur de l'amélioration était négligeable (ex. : IF de 1,27× pour le meilleur modèle) comparée à l'accélération de la Solution Or de 15,48×.
- Certains modèles (ex. : GPT-5.2) ont produit des patchs qui dégradaient les performances (IF < 1).
Optimisation de la Mémoire : Les LLM ont démontré des capacités quasi inexistantes en matière d'optimisation de la mémoire.
- Les améliorations de la mémoire de pointe et de la TWMU étaient largement absentes pour tous les modèles.
- La seule exception notable était Claude Sonnet 4.6 sur une instance unique (PR #7578), qui a atteint des IF élevés (16,61× pour la mémoire de pointe, 28,82× pour la TWMU sous Oracle ; 3556× pour la TWMU sous BM25). Cependant, ces gains ne se sont pas généralisés aux tâches.
- En revanche, les Solutions Or ont atteint une réduction de la mémoire de pointe de 171,31× et une réduction de la TWMU de 619,22× sur 55,9 %–70,6 % des tâches.

3.3 Sensibilité à la Charge de Travail

L'étude souligne que l'efficacité de l'optimisation est fortement dépendante des entrées. Par exemple, dans la PR #7578, les améliorations de temps d'exécution ont augmenté de manière significative avec la taille des entrées (jusqu'à 100× pour les charges de travail importantes), tandis que les améliorations de mémoire restaient stables. Cela souligne la nécessité des tests paramétrés, car les benchmarks à entrée unique manqueraient ces comportements critiques.

4. Signification et Contributions

Le papier revendique les contributions suivantes :

Benchmark SWE-Pro : Un benchmark complet au niveau du dépôt comprenant 102 tâches validées par des experts avec des tests paramétrés, conçu pour déplacer l'évaluation vers une analyse robuste et sensible à la charge de travail.
Cadre Sensible au Bruit : Un nouveau pipeline de mesure utilisant l'échantillonnage adaptatif, la modélisation hiérarchique du bruit et le filtrage SNR pour distinguer l'optimisation réelle de la variance environnementale.
Aperçu Multi-Métrique : La première étude systématique évaluant conjointement le temps d'exécution, la mémoire de pointe et la TWMU, révélant que les LLM actuels ne parviennent pas à naviguer efficacement dans les compromis temps-mémoire.
Preuve Empirique des Limitations : Les résultats exposent un « écart substantiel » où les LLM actuels, bien qu'excellant dans les raffinements logiques locaux, échouent à fournir des gains d'efficacité mesurables dans des scénarios réels. Le principal goulot d'étranglement identifié n'est pas l'ampleur des améliorations potentielles, mais l'identification fiable des opportunités d'optimisation elles-mêmes.

Les auteurs concluent que si les LLM montrent des promesses dans des cas spécifiques et isolés, ils manquent actuellement du raisonnement systématique requis pour l'ingénierie de performance de niveau expert, nécessitant des recherches futures sur des modèles capables de naviguer dans des paysages d'optimisation complexes et multi-métriques. Le jeu de données et le pipeline d'évaluation de SWE-Pro sont mis en open-source pour soutenir les futures recherches de la communauté.