Résumé technique : Mieux vaut être ensemble, mais dans le bon ordre

Énoncé du problème

La configuration de l'ingénierie logicielle (SE) est une tâche critique mais de plus en plus difficile. Les mauvaises configurations dans des systèmes tels que MySQL, Apache et Hadoop sont responsables de plus de 40 % des défaillances, une seule mauvaise option pouvant entraîner des dégradations de performance allant jusqu'à 480×. L'espace de recherche de ces configurations a explosé ; par exemple, les options de PostgreSQL ont augmenté de 300 % et celles de MySQL de 600 % en 15 ans. Bien que l'ingénierie logicielle basée sur la recherche (SBSE) utilise depuis longtemps la recherche stochastique et l'optimisation bayésienne, les efforts récents pour intégrer les modèles de langage de grande taille (LLM) ont donné des résultats contradictoires. Certaines études suggèrent que les LLM offrent un avantage limité, ne sont utiles que pour de petits problèmes ou sont trop lents pour une utilisation pratique.

Le problème central identifié est que la recherche actuelle traite souvent les LLM et les optimiseurs classiques de manière isolée ou les combine de façon sous-optimale. Plus précisément, les approches « hybrides » antérieures (nommées opt2) laissent généralement un optimiseur classique piloter la boucle de recherche tandis que le LLM n'assiste que les sous-programmes (par exemple, pour le démarrage à chaud ou la proposition de mutations). Les auteurs soutiennent que la base de preuves est trop mince pour trancher les différends, s'appuyant souvent sur moins de cinq jeux de données où la variance occulte la taille des effets.

Méthodologie

L'étude évalue sept méthodes d'optimisation à travers trois registres distincts en utilisant le dépôt MOOT, une collection de 127 tâches d'optimisation de l'ingénierie logicielle réelles (réduites à 105 pour une comparaison équitable).

Les trois registres

1. opt1 (LLM seul) : Le LLM agit comme l'unique optimiseur, se re-promptant lui-même avec la trajectoire des points testés (par exemple, OPRO, étendu ici en SNAP).
2. opt2 (LLM assisté) : Un optimiseur classique possède la boucle de recherche ; le LLM assiste (par exemple, BS_LLM, SYNTHCORE). Dans ces méthodes, le LLM initialise généralement le processus en premier.
3. opt3 (Classique seul) : Un optimiseur classique fonctionne sans l'intervention d'un LLM (par exemple, EZR, RRP, RANDOM).

La méthode proposée : SNAP2

Le document présente SNAP2, une approche hybride qui inverse l'ordre traditionnel des opérations trouvé dans les méthodes opt2.

• Mécanisme : SNAP2 exécute d'abord un apprenant actif classique peu coûteux (EZR) pour une partie du budget d'étiquetage (la première moitié). EZR sélectionne des lignes informatives à étiqueter, construisant ainsi une trajectoire de haute qualité initiale.
• Passage de témoin : Les résultats de cette phase classique sont ensuite utilisés pour un « démarrage à chaud » (warm-start) du LLM.
• Optimisation : Le LLM (utilisant l'algorithme SNAP, une extension d'OPRO) prend le relais pour le budget restant afin d'affiner la recherche et de terminer l'optimisation.
• Distinction clé : Contrairement aux hybrides précédents où le LLM initialise et l'optimiseur classique termine, SNAP2 laisse l'apprenant classique effectuer le travail initial peu coûteux et le LLM réaliser l'optimisation finale.

Configuration expérimentale

• Jeux de données : 105 tâches issues de MOOT couvrant la configuration logicielle, le réglage des performances, la santé des projets et la prédiction de défauts.
• Budget : Un budget d'étiquetage fixe de B=20 échantillons par exécution pour garantir l'équité et les contraintes de coût.
• Métriques : La performance est mesurée par la distance vers le paradis (d2h), normalisée en un pourcentage d'amélioration ($\Delta$). La signification statistique est déterminée via les tests de Delta de Cliff et de Kolmogorov-Smirnov pour définir un niveau « haut de gamme » de méthodes indiscernables.
• Coût : L'utilisation des tokens, le temps d'exécution (wall-clock time) et le coût monétaire ont été suivis.

Principales contributions

1. Algorithme SNAP2 : Un optimiseur qui amorce un LLM avec la sortie d'un apprenant classique peu coûteux, inversant la direction standard du démarrage à chaud.
2. Évaluation à grande échelle : Un benchmark complet à travers les trois registres (opt1, opt2, opt3) sur 105 tâches réelles de l'ingénierie logicielle, répondant au manque de preuves larges dans la littérature antérieure.
3. Preuves sur l'ordre : Démonstration que l'ordre de combinaison importe. Combiner un apprenant classique et un LLM bat soit l'un, soit l'autre, mais spécifiquement, l'ordonnancement « classique d'abord, LLM ensuite » (SNAP2) surpasse significativement l'ordonnancement « LLM d'abord, classique ensuite » utilisé dans les travaux précédents.
4. Reproductibilité : Tout le code, les prompts et les données sont publiés sous une licence open-source.

Résultats

L'étude a évalué 20 répétitions par méthode sur 105 jeux de données.

• Performance de haut niveau (Top-Tier) :
  • SNAP2 a atteint le haut de gamme sur 85 % des tâches (89/105).
  • SNAP (LLM seul) a atteint 75 %.
  • EZR (Classique seul) a atteint 71 %.
  • BS_LLM et SYNTHCORE (hybrides privilégiant le LLM) ont atteint respectivement 74 % et 70 %.
• Signification : SNAP2 est la seule méthode à briser le groupe statistique de 70–75 % de performance, obtenant une avance de 11 points sur le meilleur hybride privilégiant le LLM.
• Efficacité des coûts :
  • Comparé à la méthode LLM seule (SNAP), SNAP2 utilise environ 30 % de tokens en moins et est 1,4× plus rapide.
  • EZR (Classique seul) est pratiquement gratuit (zéro token) et est trois ordres de grandeur plus rapide que SNAP2, bien qu'il soit statistiquement légèrement inférieur en fréquence de performance de haut niveau.

Signification et affirmations

Le document conclut qu'il est imprudent d'étudier les apprenants classiques ou les LLM de manière isolée. La principale signification réside dans le fait que l'ordre compte.

• Inversion du paradigme : Les travaux hybrides précédents supposaient que le LLM devait mener (amorcer) et que l'optimiseur classique devait terminer. Les auteurs démontrent que l'inverse — laisser un apprenant classique peu coûteux faire le « travail initial peu coûteux » et transmettre la trajectoire au LLM pour « finir own » — produit des résultats supérieurs.
• Conseils pratiques :
  • Pour les travaux critiques (mission/sécurité) : Utilisez SNAP2. Il offre la plus haute qualité (85 % de taux de haut de gamme) tout en étant plus efficace que l'utilisation d'un LLM seul.
  • Pour les environnements à ressources limitées : Utilisez EZR. Il fournit des résultats quasi optimaux (71 % de taux de haut de gamme) à un coût quasi nul et une vitesse extrême, ce qui le rend idéal pour l'informatique en périphérie (edge computing) ou les budgets d'API serrés.
  • À éviter : L'optimisation pure par LLM seul (SNAP) n'est jamais le bon choix car elle est dominée par SNAP2 tant en qualité qu'en coût.

Les auteurs soulignent que leurs résultats s'appliquent aux problèmes de sélection tabulaire où les configurations sont projetées sur des lignes connues. Ils reconnaissent que l'extension de cela à des contextes génératifs (où les configurations ne sont pas pré-notées) reste une question ouverte. L'étude suggère que pour de nombreuses tâches d'optimisation de l'ingénierie logicielle, un petit budget (B=20) est suffisant lorsqu'il est guidé par la bonne combinaison de raisonnement classique et de LLM.