Nel vasto e intricato panorama del software moderno, i miglioramenti delle prestazioni raramente si presentano come nuove invenzioni. Al contrario, sono aggiustamenti sottili a basi di codice esistenti, dove un singolo cambiamento deve incastrarsi perfettamente con migliaia di righe di logica stabilita, rigide regole di compilazione e interfacce pubbliche. Trovare questi miglioramenti è difficile perché lo spazio delle possibili modifiche è enorme, e la maggior parte dei tentativi fallisce la compilazione o rompe il sistema. Per navigare in questo scenario, i ricercatori hanno sviluppato agenti automatizzati in grado di scrivere e testare codice. Questi agenti operano come esploratori, ma la strategia che utilizzano per decidere dove andare dopo conta immensamente. Alcune strategie si concentrano interamente sul singolo percorso migliore trovato finora, accumulando cambiamenti su di esso come un alpinista che sale su una singola cresta. Altre provano molti percorsi diversi contemporaneamente, ma ogni nuovo tentativo parte dal primissimo principio, scartando qualsiasi progresso fatto sugli esperimenti precedenti. Un terzo approccio, noto come ricerca qualità-diversità, tenta di mantenere una mappa di molti stati di successo differenti, preservando variazioni che non sono necessariamente le migliori attuali, ma che potrebbero portare a qualcosa di meglio in seguito.

Questo articolo presenta un sistema chiamato LORELEY, che applica questo approccio qualità-diversità all'evoluzione di interi repository di software. I ricercatori volevano sapere se mantenere un archivio diversificato di passati stati del codice, e tornare occasionalmente su di essi per trarne ispirazione, avrebbe effettivamente prodotto risultati migliori rispetto al semplice accumulo di cambiamenti sulla versione migliore attuale o all'iniziare da zero ogni volta. Hanno testato questo confrontando il sistema LORELEY con due strategie più semplici e tradizionali in un esperimento controllato utilizzando la libreria di compressione Zstandard, un componente software critico utilizzato per rimpicciolire i file di dati. L'obiettivo era vedere se l'approccio più complesso e ricco di memoria potesse trovare una versione finale del codice superiore entro un budget fisso di tentativi.

L'esperimento è stato rigoroso e coordinato con cura per garantire un confronto equo. I ricercatori hanno eseguito tre diverse policy di ricerca sullo stesso punto di partenza congelato del codice Zstandard. La prima policy, chiamata Sequential Champion, agiva come un scalatore implacabile: prendeva la versione migliore trovata finora e chiedeva all'agente di migliorarla ulteriormente, scartando tutti gli altri rami. La seconda, Independent Root, era come un gruppo di escursionisti che partivano ogni volta dal campo base; ogni tentativo iniziava dal codice originale, ignorando i miglioramenti trovati dagli altri. La terza, LORELEY, manteneva un archivio di molti stati di codice validi. Quando doveva generare una nuova idea, poteva scegliere una base da questo archivio e anche guardare altri stati memorizzati per ispirazione, sperando che combinare un punto di partenza meno ovvio con un'idea fresca potesse portare a una svolta.

Lo studio è stato eseguito per un budget specifico di quarantotto tentativi, o "job", per ogni policy. Nel mondo della codifica automatizzata, un job è un ciclo completo in cui il sistema sceglie una versione di partenza del codice, un agente scrive le modifiche in un ambiente isolato, e un tester esterno compila e misura il risultato. I ricercatori hanno misurato la performance finale del miglior codice trovato da ciascuna policy utilizzando un set separato di dati che gli agenti non avevano mai visto durante la ricerca. Questo test "holdout" ha garantito che i risultati fossero miglioramenti genuini e non solo colpi di fortuna che funzionavano solo sui dati di addestramento.

I risultati hanno mostrato che la strategia Sequential Champion, che semplicemente continuava a costruire sulla versione migliore, aveva la media e la mediana di performance osservate più elevate dopo quarantotto job. Il sistema LORELEY, nonostante il suo archivio complesso e la capacità di rivisitare vecchie idee, è finito leggermente dietro il campione. La strategia Independent Root, che non ricordava mai i successi passati, è stata la peggiore. Tuttavia, i dati non hanno stabilito un vantaggio statistico per l'approccio Qualità-Diversità (QD) rispetto a entrambe le policy di controllo; gli intervalli di confidenza includevano lo zero, il che significa che l'esperimento non poteva confermare che la QD migliorasse la performance finale sui dati holdout rispetto alle strategie più semplici, né poteva stabilirne l'equivalenza. Sebbene LORELEY sia riuscito a mantenere un insieme diversificato di stati di codice nel suo archivio e abbia occasionalmente campionato da essi, questo comportamento non si è tradotto in un risultato finale statisticamente migliore. Il sistema non ha dimostrato che mantenere una mappa di molti percorsi sia definitivamente meglio che concentrarsi sul singolo percorso migliore per questo compito specifico.

Tuttavia, la storia non è interamente fatta di fallimenti per l'approccio complesso. I ricercatori hanno osservato che il sistema LORELEY ha effettivamente interagito con il suo meccanismo previsto. È riuscito a conservare stati di codice che non erano i migliori attuali e ha effettivamente campionato questi stati non-campione in seguito per usarli come base o come ispirazione. In quattro casi su sette, il codice vincente finale del sistema Lerialey aveva antenati nella sua storia che non erano i leader al momento in cui venivano aggiunti all'archivio. Ciò ha dimostrato che il sistema poteva mantenere e rivisitare i "pietre d'inciampo"—idee intermedie che potrebbero non essere perfette da sole, ma che potrebbero portare da qualche parte di nuovo. Eppure, in questo specifico esperimento con un numero limitato di tentativi, queste pietre d'inciampo non hanno aiutato il sistema a battere la strategia più semplice e diretta in modo statisticamente significativo.

Il documento ha anche esaminato campagne precedenti e più piccole in cui il sistema è stato utilizzato su diverse librerie software, incluse una libreria Python per la gestione del testo e una revisione separata dello strumento di compressione. In questi casi, il sistema è riuscito a produrre miglioramenti significativi, come un aumento di velocità di quasi il sette per cento in una libreria e un guadagno del venticinque per cento in un'altra. Questi successi dimostrano che il sistema è capace di trovare miglioramenti complessi su più file quando riceve le giuste condizioni. Ma il confronto controllato con le strategie più semplici ha mostrato che, almeno per il compito Zstandard con un budget di quarantotto job, la maggiore complessità di mantenere un archivio diversificato non ha fornito un vantaggio statisticamente accertato rispetto al semplice focus sulla versione migliore attuale.

In definitiva, lo studio offre una visione sfumata dell'evoluzione del software automatizzata. Conferma che un sistema può essere progettato per ricordare e riutilizzare una vasta gamma di stati passati, e che può navigare con successo in un codebase complesso per trovare miglioramenti. Ma suggerisce anche che, per certi compiti e entro determinati limiti di tempo, la strategia più efficace può essere quella diretta: trova la cosa migliore che hai e continua a migliorarla, piuttosto che cercare di gestire una mappa di possibilità in espansione. I ricercatori non hanno scoperto che il metodo complesso fosse inutile, ma hanno scoperto che non ha vinto questa particolare gara con significatività statistica. I risultati rimangono specifici per gli strumenti e i vincoli utilizzati, lasciando aperta la questione se una ricerca più lunga o un tipo di problema diverso possano eventualmente favorire l'approccio diversificato e ricco di memoria.