← Nieuwste papers
🤖 AI

Loreley: Repository-Scale Program Evolution with Quality-Diversity Search

Dit artikel introduceert Loreley, een systeem voor programmaevolutie op repository-schaal dat gebruikmaakt van Quality-Diversity-zoektocht om diverse repository-toestanden te behouden voor toekomstige sampling, wat in voorlopige tests succesvol stapsteenmechanismen activeerde, maar er niet in slaagde een statistisch significant prestatievoordeel aan te tonen ten opzichte van sequentiële kampiooneditie of onafhankelijke wortelvoorstellen in een gecontroleerd experiment van 48 jobs.

Oorspronkelijke auteurs: Mohan Chen

Gepubliceerd 2026-08-21
📖 6 min leestijd🧠 Diepgaand

Oorspronkelijke auteurs: Mohan Chen

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

In het uitgestrekte, complexe landschap van moderne software zijn prestatieverbeteringen zelden nieuwe uitvindingen. In plaats daarvan zijn het subtiele aanpassingen aan bestaande codebases, waarbij een enkele wijziging perfect moet passen binnen duizenden regels gevestigde logica, strikte build-regels en publieke interfaces. Het vinden van deze verbeteringen is moeilijk omdat de ruimte van mogelijke wijzigingen enorm is, en de meeste pogingen mislukken bij het bouwen of breken van het systeem. Om dit te navigeren, hebben onderzoekers geautomatiseerde agenten ontwikkeld die code kunnen schrijven en testen. Deze agenten werken als ontdekkingsreizigers, maar de strategie die zij gebruiken om te beslissen waar ze als volgende heen gaan, is van groot belang. Sommige strategieën richten zich volledig op het enkel beste pad dat tot nu toe is gevonden, waarbij ze wijzigingen opstapelen op dit pad zoals een klimmer die een enkele bergkam beklimt. Anderen proberen veel verschillende paden tegelijk, maar beginnen elke nieuwe poging vanaf het begin, waardoor alle vooruitgang van eerdere pogingen verloren gaat. Een derde benadering, bekend als quality-diversity search, probeert een kaart van vele verschillende succesvolle staten bij te houden, waarbij variaties worden bewaard die niet noodzakelijkerwijs de huidige "beste" zijn, maar later tot iets beters kunnen leiden.

Dit artikel introduceert een systeem genaamd LORELEY, dat deze quality-diversity benadering toepast op de evolutie van volledige softwarerepositories. De onderzoekers wilden weten of het bijhouden van een divers archief van eerdere codestaten, en het af en toe terugkeren naar deze staten voor inspiratie, daadwerkelijk betere resultaten zou opleveren dan simpelweg wijzigingen op te stapelen op de huidige beste versie of telkens weer opnieuw te beginnen. Ze testten dit door het LORELEY-systeem tegen twee simpelere, meer traditionele strategieën te plaatsen in een gecontroleerd experiment met de Zstandard compressielibrary, een cruciaal stuk software dat wordt gebruikt om databestanden te verkleinen. Het doel was om te zien of de complexere, geheugenrijke benadering een superieure definitieve versie van de code kon vinden binnen een vastgesteld budget van pogingen.

Het experiment was rigoureus en zorgvuldig afgestemd om een eerlijke vergelijking te garanderen. De onderzoekers voerden drie verschillende zoekbeleids uit op hetzelfde bevroren startpunt van de Zstandard-code. Het eerste beleid, genaamd Sequential Champion, gedroeg zich als een onvermoeibare klimmer: het nam de tot nu toe beste versie en vroeg de agent om deze verder te verbeteren, waarbij alle andere takken werden weggegooid. Het tweede, Independent Root, was als een groep wandelaars die telkens vanuit het basiskamp vertrekt; elke poging begon vanuit de originele code, waarbij verbeteringen door anderen werden genegeerd. Het derde, LORELEY, onderhield een archief van vele verschillende geldige codestaten. Wanneer het een nieuw idee moest genereren, kon het een basis kiezen uit dit archief en ook naar andere opgeslagen staten kijken voor inspiratie, in de hoop dat het combineren van een minder voor de hand liggend startpunt met een fris idee tot een doorbraak zou leiden.

De studie werd uitgevoerd met een specifiek budget van achtenveertig pogingen, of "jobs", voor elk beleid. In de wereld van geautomatiseerde codering is een job een volledige cyclus waarbij het systeem een startversie van de code kiest, een agent wijzigingen schrijft in een geïsoleerde omgeving, en een externe tester de code bouwt en meet. De onderzoekers maten de uiteindelijke prestaties van de beste gevonden code door elk beleid te gebruiken met een aparte set gegevens die de agenten tijdens hun zoektocht nooit hadden gezien. Deze "holdout"-test zorgde ervoor dat de resultaten echte verbeteringen waren en geen gelukkige gokken die alleen werkten op de trainingsdata.

De resultaten lieten zien dat de Sequential Champion-strategie, die simpelweg bleef voortbouwen op de beste versie, de hoogste waargenomen gemiddelde en mediane prestatie vertoonde na achtenveertig jobs. Het LORELEY-systeem, ondanks zijn complexe archief en vermogen om oude ideeën te herzoeken, eindigde iets achter de kampioen. De Independent Root-strategie, die nooit eerdere successen onthield, presteerde het slechtst. De gegevens stelden echter geen statistisch voordeel vast voor de Quality-Diversity (QD) benadering ten opzichte van de controle-groepen; de betrouwbaarheidsintervallen bevatten nul, wat betekende dat het experiment niet kon bevestigen dat QD de uiteindelijke hold-out prestaties verbeterde ten opzichte van de eenvoudigere strategieën, noch kon het gelijkwaardigheid vaststellen. Hoewel LORELEY er erin slaagde een diverse set codestaten in zijn archief bij te houden en er ook af en toe uit deze staten te bemonsteren, vertaalde dit gedrag zich niet in een statistisch bewezen beter eindresultaat binnen de tijdslimiet van het experiment. Het systeem toonde niet aan dat het bijhouden van een kaart van vele paden definitief beter is dan het focussen op het enkel beste pad voor deze specifie

Het verhaal is echter niet uitsluitend een verhaal van falen voor de complexe benadering. De onderzoekers observeerden dat het LORELEY-systeem zich inderdaad toebeegaf aan zijn beoogde mechanisme. Het slaagde erin om codestaten te behouden die niet de huidige beste waren, en het bemonsterde deze niet-kampioensstaten later om ze als basis of als inspiratie te gebruiken. In vier van de zeven testruns had de uiteindelijke winnende code van het LORELEY-systeem voorouders in zijn geschiedenis die op het moment van toevoeging aan het archief niet de huidige leiders waren. Dit bewees dat het systeem in staat was om "tussenstapjes" vast te houden en te herzoeken — tussenliggende ideeën die op zichzelf misschien niet perfect zijn, maar tot iets nieuws kunnen leiden. Toch hielpen deze tussenstapjes in dit specifieke experiment met een beperkt aantal pogingen het systeem niet om de eenvoudigere, directere strategie op een statistisch significante manier te verslaan.

Het onderzoek keek ook naar eerdere, kleinere campagnes waarbij het systeem werd gebruikt op andere softwarebibliotheken, waaronder een Python-bibliotheek voor tekstverwerking en een aparte revisie van de compressietool. In die gevallen slaagde het systeem erin om significante verbeteringen te produceren, zoals een snelheidswinst van bijna zeven procent in één bibliotheek en een winst van vijfentwintig procent in een andere. Deze successen laten zien dat het systeem in staat is om complexe, multi-file verbeteringen te vinden wanneer de juiste omstandigheden aanwezig zijn. Maar de gecontroleerde vergelijking met de eenvoudigere strategieën toonde aan dat, althans voor de Zstandard-taak met een budget van achtenveertig jobs, de extra complexiteit van het onderhouden van een divers archief geen statistisch vastgestelde voordelen bood ten opzichte van het simpelweg focussen op de huidige beste versie.

Uiteindelijk biedt de studie een genuanceerd beeld van geautomatiseerde softwareevolutie. Het bevestigt dat een systeem kan worden ontworpen om een grote verscheidenheid aan eerdere staten te onthouden en te hergebruiken, en dat het succesvol een complexe codebase kan navigeren om verbeteringen te vinden. Maar het suggereert ook dat voor bepaalde taken en binnen specifieke tijdslimieten de meest effectieve strategie de rechtstreekse kan zijn: vind het beste dat je hebt, en maak het steeds beter, in plaats van te proberen een uitgestrekte kaart van mogelijkheden te beheren. De onderzoekers vonden niet dat de complexe methode nutteloos was, maar ze vonden wel dat het deze specifieke race niet won met statistische significantie. De resultaten blijven specifief voor de gebruikte instrumenten en beperkingen, wat de vraag open laat of een langere zoektocht of een ander type probleem uiteindelijk de diverse, geheugenrijke benadering gunstig zou stemmen.

Verdrinkt u in papers in uw vakgebied?

Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.

Probeer Digest →