Investigating Test Overfitting on SWE-bench

Probleemstelling: Test Overfitting bij Issue Resolution

Het paper onderzoekt het fenomeen van test overfitting in het kader van het automatisch oplossen van softwareproblemen (issue resolution) in code-repositories, specifiek met behulp van Large Language Models (LLMs).

• De Context: Moderne systemen voor issue resolution gebruiken vaak tests om geselecteerde code-patches te valideren of om iteratief code te verfijnen. Omdat de meeste open source issues geen uitvoerbare tests meebrengen, genereren deze systemen vaak "surrogaat-tests" ($t_{gen}$) op basis van de issue-beschrijving.
• Het Probleem: Er bestaat een risico dat gegenereerde code ($c_{new}$) specifiek wordt geoptimaliseerd om deze gegenereerde tests te passeren, terwijl de code andere belangrijke functionaliteit breekt of niet voldoet aan de werkelijke intentie van de issue. Dit wordt test overfitting genoemd.
• De Realiteit: In benchmarks zoals SWE-bench wordt de uiteindelijke succesmeting gedaan met "gouden tests" ($t_{gold}$), die zijn afgeleid van menselijke pull requests. Deze tests zijn echter niet beschikbaar tijdens het generatieproces. Het paper stelt dat systemen die te sterk vertrouwen op $t_{gen}$, code produceren die $t_{gen}$ passeert maar faalt op $t_{gold}$.

Methodologie

De auteurs hebben een empirische studie uitgevoerd op de TDD-bench Verified benchmark (een subset van SWE-bench met 449 Python-issues). Ze gebruikten een drie-staps pipeline:

1. Initiële Generatie:
   • Code: Gebruik van het systeem Agentless om initiële code-patches ($c_{new}$) te genereren op basis van de issue en de originele code ($c_{old}$).
   • Tests: Gebruik van e-Otter++ om surrogaat-tests ($t_{gen}$) te genereren.
2. Test-gebaseerde Code Refinement (Iteratief):
   • Een lus waarbij de gegenereerde code en tests worden uitgevoerd.
   • Als de test faalt, wordt een LLM-criticus ingeschakeld om te bepalen of de focus-code (de bug) of de test zelf moet worden aangepast.
   • Een beloningsfunctie (reward function) wordt gebruikt om te beslissen of een nieuwe versie van code/test behouden blijft. Deze functie combineert:
     • Of de test faalt op de originele code.
     • Of de test slaagt op de nieuwe code.
     • Coverage: Hoeveelheid van de toegevoegde/verwijderde regels die door de test worden gedekt.
   • De lus draait maximaal 15 iteraties of totdat de test slaagt.
3. Validatie:
   • De uiteindelijke patches worden getest tegen de verborgen gouden tests ($t_{gold}$) en bestaande regressietests ($t_{old}$) om overfitting te detecteren.

Gebruikte Modellen: Claude-3.7 Sonnet en GPT-4o.

Kernvragen (Research Questions)

1. RQ1: Overfiten LLM-genereren code-patches op de tests die door dezelfde LLM zijn gegenereerd?
2. RQ2: Hoe beïnvloedt het verfijnen van code op basis van waargenomen tests de mate van overfitting?
3. RQ3: Als de gouden tests ($t_{gold}$) wel beschikbaar waren, zou het verfijnen van code op basis daarvan dan andere functionaliteit breken?

Belangrijkste Resultaten

De resultaten tonen aan dat test overfitting een significant en ondergewaardeerd probleem is:

• Hoeveelheid Overfitting (RQ1):
  • Zelfs zonder verfijning overfiten veel patches. Bij Claude-3.7 was de overfitting-ratio 21,8% (50 van de 229 patches die $t_{gen}$ passeerden, faalden op $t_{gold}$).
  • Bij GPT-4o was dit nog hoger: 33,0%.
• Impact van Refinement (RQ2):
  • Het gebruik van een test-gebaseerde verfijningslus verergert het probleem. Hoewel het systeem soms extra patches laat slagen op $t_{gen}$, faalt een groot deel daarvan op $t_{gold}$.
  • De overfitting-ratio steeg bij Claude-3.7 van 21,8% naar 25,5% na verfijning.
  • Het verbergen van de test-details voor de LLM (alleen een pass/fail vlag tonen) verminderde de overfitting enigszins, maar loste het probleem niet op.
• Het "Oracle" Experiment (RQ3):
  • Als de systemen toegang hadden tot de perfecte gouden tests ($t_{gold}$) tijdens het proces, was de overfitting-ratio lager (5,8% voor Claude, 11,3% voor GPT-4o).
  • Echter, zelfs met toegang tot $t_{gold}$, bleef er een risico bestaan dat het oplossen van de ene issue andere regressietests ($t_{old}$) deed falen.
  • De winst in het oplossen van issues door gouden tests te gebruiken was bescheiden (ongeveer 3% toename), wat suggereert dat huidige systemen vaak het "grotere plaatje" missen.

Aanvullende Bevindingen:

• Voorkeur van LLMs: LLMs geven bij het verfijnen sterk de voorkeur aan het aanpassen van de focus-code (de bug) in plaats van de test. Ze gaan er blijkbaar van uit dat de gegenereerde tests correct zijn.
• Coverage: Overfitting patches hebben een lagere code-coverage (mediaan < 0,8) vergeleken met niet-overfitting patches (mediaan 1,0). Dit suggereert dat coverage-metingen kunnen dienen als een vroege waarschuwing.

Bijdragen en Significantie

Dit paper levert de volgende bijdragen aan het onderzoeksveld:

1. Eerste Empirisch Bewijs: Het is het eerste onderzoek dat test overfitting systematisch meet in de context van repository-level issue resolution met LLMs.
2. Kritische Waarschuwing: Het paper waarschuwt tegen een blind vertrouwen op gegenereerde tests voor het valideren en verfijnen van code. Het toont aan dat "passing tests" niet gelijkstaat aan "correcte oplossing".
3. Technieken en Beperkingen: Het beschrijft technieken om overfitting te mitigeren (zoals het verbergen van test-details), maar toont aan dat deze vaak ten koste gaan van de algehele effectiviteit van het oplossen van issues.
4. Toekomstperspectief: Het suggereert dat toekomstige systemen moeten kijken naar alternatieve validatiemethoden (zoals coverage-analyse) en dat er meer aandacht nodig is voor het voorkomen van reward hacking in test-gebaseerde loops.

Conclusie:
Hoewel test-gebaseerde verfijning nuttig kan zijn voor het oplossen van specifieke issues, introduceert het een aanzienlijk risico op test overfitting. Zelfs met toegang tot perfecte tests kan het proces andere functionaliteit breken. De auteurs concluderen dat de huidige afhankelijkheid van gegenereerde tests voor issue resolution kritisch moet worden heroverwogen.