Technische Samenvatting: SWE-MERA

Probleemstelling

De snelle vooruitgang van Large Language Models (LLM's) in software engineering heeft kritieke beperkingen blootgelegd in bestaande evaluatiebenchmarks, met name SWE-bench. De auteurs identificeren twee primaire faalmodi in statische benchmarks:

1. Data Contaminatie: Een aanzienlijk deel van de succesvolle patches in SWE-bench betreft directe oplossing-lekken (32,67%) of slaagt door inadequate testgevallen (31,08%). Omdat modellen herhaaldelijk worden getest op vaste datasets, memoriseren ze onbedoeld oplossingen of passen ze zich te veel aan verouderde voorbeelden aan (overfitting).
2. Benchmark Verzadiging: Statische datasets verliezen hun effectiviteit naarmate state-of-the-art modellen bijna perfecte scores behalen, wat het moeilijk maakt om betekenisvolle vooruitgang te onderscheiden.

Bovendien richten bestaande dynamische benchmarks zoals LiveCodeBench zich primair op algoritmische problemen en slagen ze er niet in de repository-niveau complexiteit te vangen die essentieel is voor realistische beoordeling van software engineering.

Methodologie

SWE-MERA introduceert een dynamische, continu bijgewerkte benchmark die is ontworpen om contaminatie te mitigeren en relevantie te waarborgen. De kern van de methodologie is een zevenstaps geautomatiseerde pipeline die real-world GitHub issues en pull requests (PR's) verzamelt, valideert en cureert.

De Verzameling-pipeline

De pipeline wordt maandelijks (gepland per kwartaal) uitgevoerd om ervoor te zorgen dat de dataset de nieuwste software engineering uitdagingen reflecteert. Het proces omvat:

1. Repository Selectie: Filtert GitHub-repositories op basis van criteria waaronder een minimum van 10 stars/forks, recente activiteit (huidig jaar), Python als primaire taal en een open-source licentie.
2. PR-Issue Mapping Constructie: Stelt strikte één-op-één koppelingen vast tussen gesloten issues en gemergde PR's. De datum van het mergen van de PR moet later zijn dan de eerste dag van de vorige maand om temporele versheid te garanderen.
3. Metadata Extractie en Filtering: Downloadt en parseert issue/PR metadata. Paren worden verworpen als de gecombineerde lengte van titel en body minder dan 25 tekens is.
4. Patch Extractie en Validatie: Genereert git diffs. Alleen PR's die zowel broncode als testbestanden wijzigen, worden behouden. PR's die meer dan 15 bronbestanden wijzigen, worden uitgesloten om complexiteit te beheersen.
5. Repository Build Validatie: Taken worden uitgevoerd in een Docker-container. Een taak wordt alleen als geldig beschouwd als pytest ten minste één geslaagde test retourneert nadat de repository is teruggezet naar de staat vóór de fix en de toekomstige testgevallen zijn toegepast.
6. End-to-End Taak Uitvoering: Verifieert reproduceerbaarheid en correctheid in een gecontroleerde omgeving.
7. LLM-gebaseerde Pipeline Evaluatie: Gebruikt het Qwen3-32B model om kandidaat-taken te evalueren op vier criteria: taakcorrectheid, testcorrectheid, testvolledigheid en complexiteit. Taken die in de onderste 25% van de scores voor correctheid of volledigheid vallen, worden gefilterd. Complexiteit wordt niet gebruikt voor filtering om een mix van moeilijkheidsgraden te behouden.

Evaluatiekader

Om de prestaties van modellen te beoordelen, gebruiken de auteurs het Aider coding agent framework.

• Mechanisme: Aider biedt LLM's tot zes onafhankelijke pogingen ("tries") om een issue op te lossen. Elke poging staat maximaal vier reflecties toe om lint- of testoutput te verwerken.
• Metrieken: De evaluatie rapporteert pass@1 (succes op de eerste poging) en pass@6 (succes binnen zes pogingen).
• Infrastructuur: Experimenten werden uitgevoerd op NVIDIA H100 GPU's, waarbij het tokengebruik varieerde van 60–140M prompt tokens en 3–20M completion tokens per modelevaluatie.

Belangrijkste Bijdragen

1. Dynamische Benchmarking Pipeline: Een robuuste, zevenstaps pipeline die in staat is ongeveer 10.000 potentiële taken te verzamelen, waarvan er momenteel 728 samples beschikbaar zijn voor de 2025 subset. Deze pipeline minimaliseert contaminatierisico's door middel van rigoureuze geautomatiseerde validatie en temporele filtering.
2. Geautomatiseerde Scoring en Leaderboard: Implementatie van een geautomatiseerd scoringsysteem gebaseerd op de Aider agent en een dynamische gebruikers-leaderboard die maandelijks wordt bijgewerkt.
3. Open Infrastructuur: De volledige pipeline wordt uitgebracht als een Python-package, en de dataset is beschikbaar via Hugging Face, wat reproduceerbaarheid en extensibiliteit voor toekomstig onderzoek vergemakkelijkt.
4. Uitgebreide Evaluatie: Een gedetailleerde prestatieanalyse van meer dan een dozijn recente LLM's (inclusief Qwen3, DeepSeek-R1, en Devstral) op taken verzameld tussen september 2024 en juni 2025.

Resultaten

De evaluatie van state-of-the-art modellen op de SWE-MERA 2025 subset leverde de volgende inzichten op:

• Discriminatief Vermogen: SWE-MERA rangschikt modellen effectief volgens hun capaciteiten. Zo ordent het bijvoorbeeld de Qwen2.5-Coder serie correct op basis van parameteraantal (7B < 14B < 32B).
• Modelprestaties:
  • DeepSeek-R1-0528 behaalde de hoogste pass@6 (40,2%) en pass@1 (27,8%).
  • Devstral-Small-2505 demonstreerde superieure prestaties relatief aan zijn grootte, waarbij het grotere modellen zoals Qwen2.5-Coder-32B overtrof.
  • Qwen3-32B presteerde iets beter dan QwQ-32B, wat consistent is met hun specificaties.
• Temporele Anomalieën: Een interessante observatie was dat DeepSeek-R1 varianten beter presteerden op 2024-taken vergeleken met 2025-taken, een gedrag dat niet werd waargenomen bij andere onderzochte modellen.
• Faalmodi: De studie volgde specifieke faalpunten, zoals "localize files" (het identificeren van de juiste bestanden), "generate patch" (het creëren van geldige patches), en "regression tests" (het passeren van de originele repository tests). Het bereiken van de tokenlimiet was minimaal (0,0%–5,7%).

Betekenis en Claims

Het artikel stelt dat SWE-MERA de fundamentele uitdagingen van data contaminatie en benchmark verzadiging aanpakt die traditionele statische evaluaties teisteren. Door het introduceren van dynamische updates en rigoureuze kwaliteitsvalidatie zorgt de benchmark voor:

1. Real-world Relevantie: Taken weerspiegelen de nieuwste uitdagingen in softwareontwikkeling.
2. Eerlijke Evaluatie: Modellen worden getest op verse problemen, wat het risico op memorisatie minimaliseert.
3. Continue Verbetering: De benchmark evolueert mee met AI en software engineering praktijken.

De auteurs beweren dat SWE-MERA betrouwbare prestatie-baselines vestigt die vrij zijn van de contaminatieproblemen die in traditionele statische benchmarks voorkomen. Zij erkennen beperkingen, waaronder het potentieel dat dynamisch verzamelde taken een gebrek aan nuance kunnen hebben vergeleken met door mensen gecureerde problemen, de uitdagingen bij het beoordelen van open-ended oplossingen, en het feit dat het huidige framework zich primair richt op programmeercorrectheid in plaats van code leesbaarheid, onderhoudbaarheid of veiligheid.

Het framework is ontworpen om uitbreidbaar te zijn naar andere talen (Java, JavaScript, TypeScript, Go, C++) en dient als een door de community gedreven bron om AI-onderzoek in software engineering te bevorderen.