Dans le vaste et complexe paysage du logiciel moderne, les améliorations de performance ressemblent rarement à des inventions nouvelles. Au lieu de cela, elles sont des ajustements subtils apportés à des bases de code existantes, où un changement unique doit s'insérer parfaitement dans des milliers de lignes de logique établie, de règles de compilation strictes et d'interfaces publiques. Trouver ces améliorations est difficile car l'espace des changements possibles est énorme, et la plupart des tentatives échouent à compiler ou brisent le système. Pour naviguer dans ce milieu, des chercheurs ont développé des agents automatisés capables d'écrire et de tester du code. Ces agents opèrent comme des explorateurs, mais la stratégie qu'ils utilisent pour décider de leur prochaine direction importe énormément. Certaines stratégies se concentrent entièrement sur le meilleur chemin trouvé jusqu'à présent, accumulant les changements sur celui-ci comme un grimpeur ascendant une seule crête. D'autres tentent de nombreux chemins différents à la fois, mais repartent de chaque nouvelle tentative depuis le tout début, abandonnant tout progrès réalisé lors des tentatives précédentes. Une troisième approche, connue sous le nom de recherche de qualité-diversité, tente de conserver une carte de nombreux états réussis, préservant des variations qui ne sont pas nécessairement les meilleures actuelles, mais qui pourraient mener à quelque chose de mieux plus tard.

Ce document présente un système appelé LORELEY, qui applique cette approche de qualité-diversité à l'évolution de répertoires logiciels entiers. Les chercheurs voulaient savoir si le fait de conserver une archive diversifiée d'états de code passés, et d'y revenir occasionnellement pour s'en inspirer, produirait réellement de meilleurs résultats qu'en accumulant simplement des changements sur la version la plus récente ou en repartant de zéro à chaque fois. Ils ont testé cela en opposant le système LORELEY à deux stratégies plus simples et plus traditionnelles lors d'une expérience contrôlée utilisant la bibliothèque de compression Zstandard, un élément logiciel critique utilisé pour réduire la taille des fichiers de données. Le but était de voir si l'approche plus complexe et riche en mémoire pouvait trouver une version finale du code supérieure au sein d'un budget fixe de tentatives.

L'expérience était rigoureuse et soigneusement appariée pour garantir une comparaison équitable. Les chercheurs ont fait fonctionner trois politiques de recherche différentes sur le même point de départ figé du code de Zstandard. La première politique, appelée « Sequential Champion » (Champion Séquentiel), agissait comme un grimpeur acharné : elle prenait la meilleure version trouvée jusqu'à présent et demandait à l'agent de l'améliorer davantage, écartant toutes les autres branches. La seconde, « Independent Root » (Racine Indépendante), était comme un groupe de randonneurs partant du camp de base à chaque fois ; chaque tentative commençait à partir du code original, ignorant les améliorations trouvées par les autres. La troisième, LORELEY, maintenait une archive de nombreux états de code valides. Lorsqu'elle devait générer une nouvelle idée, elle pouvait choisir une base dans cette archive et aussi regarder d'autres états stockés pour s'en inspirer, espérant que la combinaison d'un point de départ moins évident avec une idée fraîche produirait une percée.

L'étude s'est déroulée pour un budget spécifique de quarante-huit tentatives, ou « jobs », pour chaque politique. Dans le monde du codage automatisé, un job est un cycle complet où le système choisit une version de code de départ, un agent écrit des changements dans un environnement isolé, et un testeur externe compile et mesure le résultat. Les chercheurs ont mesuré la performance finale du meilleur code trouvé par chaque politique en utilisant un ensemble de données distinct que les agents n'avaient jamais vus durant leur recherche. Ce test « holdout » (de contrôle) garantissait que les résultats étaient des améliorations authentiques et non de simples coups de chance qui ne fonctionnaient que sur les données d'entraînement.

Les résultats ont montré que la stratégie Sequential Champion, qui se contentait de construire sur la meilleure version, présentait la moyenne et la médiane de performance observées les plus élevées après quarante-huit jobs. Le système LORELEY, malgré son archive complexe et sa capacité à revisiter de vieilles idées, terminait légèrement derrière le champion. La stratégie Independent Root, qui ne se souvenait d'aucune réussite passée, a obtenu les moins bons résultats. Cependant, les données n'ont pas établi d'avantage statistique pour l'approche de Qualité-Diversité (QD) par rapport aux deux contrôles ; les intervalles de confiance incluaient zéro, ce qui signifie que l'expérience n'a pas pu confirmer que la QD améliore la performance finale sur les données de test par rapport aux stratégies plus simples, ni établir une équivalence. Bien que LORELEY ait réussi à maintenir un ensemble diversifié d'états de code dans son archive et qu'il ait occasionnellement échantillonné ces états, ce comportement ne s'est pas traduit par un meilleur résultat final statistiquement prouvé sur les données de test. Le système n'a pas démontré que garder une carte de nombreux chemins est définitivement meilleur que de se concentrer sur un seul chemin pour cette tâche spécifique.

Cependant, l'histoire n'est pas totalement celle d'un échec pour l'approche complexe. Les chercheurs ont observé que le système LORELEY s'est effectivement engagé dans son mécanisme prévu. Il a réussi à conserver des états de code qui n'étaient pas les meilleurs actuels, et il a échantillonné ces états non-champions plus tard pour les utiliser comme base ou comme inspiration. Dans quatre cas sur sept tests, le code gagnant final du système LORELEY avait des ancêtres dans son historique qui n'étaient pas les leaders au moment où ils ont été ajoutés à l'archive. Cela a prouvé que le système pouvait conserver et revisiter des « pierres de passage » — des idées intermédiaires qui ne sont peut-être pas parfaites en soi, mais qui pourraient mener ailleurs. Pourtant, dans cette expérience spécifique avec un nombre limité de tentatives, ces pierres de passage n'ont pas aidé le système à battre la stratégie plus simple et directe de manière statistiquement significative.

L'article a également examiné des campagnes antérieures plus petites où le système a été utilisé sur différentes bibliothèques logicielles, incluant une bibliothèque Python pour la gestion de texte et une révision distincte de l'outil de compression. Dans ces cas, le système a réussi à produire des améliorations significatives, telles qu'une accélération de près de sept pour cent dans une bibliothèque et un gain de vingt-cinq pour cent dans une autre. Ces succès démontent que le système est capable de trouver des améliorations complexes impliquant plusieurs fichiers lorsqu'il est soumis aux bonnes conditions. Mais la comparaison contrôlée avec les stratégies plus simples a montré que, du moins pour la tâche Zstandard avec un budget de quarante-huit jobs, la complexité supplémentaire consistant à maintenir une archive diversifiée n'a pas apporté d'avantage statistiquement établi par rapport au simple fait de se concentrer sur la meilleure version actuelle.

En fin de compte, l'étude offre une vision nuancée de l'évolution logicielle automatisée. Elle confirme qu'un système peut être conçu pour se souvenir et réutiliser une grande variété d'états passés, et qu'il peut naviguer avec succès dans une base de code complexe pour trouver des améliorations. Mais elle suggère aussi que pour certaines tâches et dans des limites de temps spécifiques, la stratégie la plus efficace peut être la plus directe : trouver la meilleure chose que vous possédez, et continuer à l'améliorer, plutôt que d'essayer de gérer une carte tentaculaire de possibilités. Les chercheurs n'ont pas trouvé que la méthode complexe était inutile, mais ils ont constaté qu'elle n'a pas gagné cette course particulière avec une signification statistique. Les résultats restent spécifiques aux outils et aux contraintes utilisés, laissant ouverte la question de savoir si une recherche plus longue ou un type de problème différent pourrait finalement favoriser l'approche diversifiée et riche en mémoire.