← Nieuwste papers
🤖 AI

Towards Comprehensive Benchmarking Infrastructure for LLMs In Software Engineering

Dit artikel identificeert kritieke tekortkomingen in de huidige evaluatie van Large Language Models voor software engineering en introduceert BEHELM, een holistische benchmarking-infrastructuur die is ontworpen om software-scenario-specificaties te verenigen met multi-metrische beoordelingen om eerlijke, realistische en reproduceerbare evaluaties mogelijk te maken.

Oorspronkelijke auteurs: Daniel Rodriguez-Cardenas, Xiaochang Li, Marcos Macedo, Antonio Mastropaolo, Dipin Khati, Yuan Tian, Huajie Shao, Denys Poshyvanyk

Gepubliceerd 2026-01-30
📖 5 min leestijd🧠 Diepgaand

Oorspronkelijke auteurs: Daniel Rodriguez-Cardenas, Xiaochang Li, Marcos Macedo, Antonio Mastropaolo, Dipin Khati, Yuan Tian, Huajie Shao, Denys Poshyvanyk

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

Stel je voor dat je probeert te beoordelen hoe goed een nieuwe generatie "robotchefs" (Large Language Models voor code) is in koken. Op dit moment is de manier waarop we ze testen een beetje alsof je ze vraagt om een enkele ui te snijden en dan te kijken of ze dat snel doen. Als ze de ui snijden, geven we ze een gouden ster.

Maar in de echte wereld snijdt een chef niet alleen uien; een chef beheert een hele keuken, volgt complexe recepten op, gaat om met pittige ingrediënten zonder het huis af te branden, en werkt met een team. Het artikel betoogt dat onze huidige "ui-snij-tests" te simpel zijn. Ze missen het grote plaatje, en daardoor weten we eigenlijk niet of deze robotchefs een echte diner-service kunnen draaien.

Hier is een uitsplitsing van de belangrijkste punten uit het artikel met behulp van eenvoudige analogieën:

1. Het Probleem: De "Rijexamen" is Te Makkelijk

Momenteel testen we deze AI-modellen met kleine, geïsoleerde taken (zoals het schrijven van een kort codefragment).

  • De Analogie: Het is alsof je een bestuurder een test geeft waarbij hij alleen in een lege parkeerplaats hoeft te rijden met 5 mph. Hij slaagt met vlag en wimpel. Maar dat vertelt ons niet of hij de spits aan kan, slecht weer, of een plotselinge remfout op de snelweg.
  • De Realiteit: Het artikel zegt dat huidige tests "verzadigd" zijn. De robots hebben de antwoorden op deze makkelijke parkeerplaats-tests uit het hoofd geleerd. Wanneer je ze een echt wereldprobleem geeft (zoals het oplossen van een bug in een enorm, rommelig softwareproject), falen ze vaak omdat ze alleen patronen hebben gememoriseerd, in plaats van echt te leren "denken" als een software engineer.

2. De Drie Grote Gaten in Onze Testinfrastructuur

De auteurs ontdekten drie belangrijke redenen waarom onze huidige testinfrastructuur kapot is:

  • Gat #1: De "Context" Ontbreken (Het Receptenboek)
    • Het Probleem: Huidige tests kijken alleen naar de code zelf. Ze negeren de rest van het softwareproject.
    • De Analogie: Stel je voor dat je een chef vraagt om een soep te maken, maar je geeft hem alleen de lijst met ingrediënten. Je geeft hem niet de pan, het fornuis, het receptenboek of de instructies over hoe de soep in de rest van de maaltijd past. Echt software engineering is rommelig; het gaat over geschiedenis, teamcommentaren en specifieke regels. Onze tests negeren al die "keukenrommel", waardoor de robots niet worden getest op hoe ze met echte chaos omgaan.
  • Gat #2: Het Verkeerde Scorebord (De "Pass/Fail" Valstrik)
    • Het Probleem: We gebruiken voornamelijk "Nauwkeurigheid" (Werkt het? Ja/Nee) of "Tekstgelijkenis" (Lijkt het op het antwoord?).
    • De Analogie: Stel je voor dat je een essay van een student beoordeelt. Als de student een paragraaf schrijft die grammaticaal perfect is maar iets volkomen onjuists zegt, of als hij een briljante oplossing schrijft die er anders uitziet dan het antwoordmodel van de docent, kunnen onze huidige tests hem als foutief markeren. We moeten ze beoordelen op waarom ze het schreven (interpreteerbaarheid), hoe snel ze het deden (efficiëntie), en of ze eerlijk waren tegenover iedereen (bias), en niet alleen of de uiteindelijke woordtelling overeenkomt.
  • Gat #3: Iedereen Bouwt Zijn Eigen Testbaan (Het "Geen Standaard" Probleem)
    • Het Probleem: Elk onderzoeksteam bouwt zijn eigen test vanaf nul. Eén team gebruikt een modderig parcours, een ander een geasfalteerde weg, en een derde een loopband.
    • De Analogie: Het is alsof je racewagenrijders vergelijkt waarbij de één op een onverhard circuit rijdt, een ander op ijs en een derde op een snelweg. Je kunt niet zeggen wie de beste bestuurder is omdat de omstandigheden totaal verschillend zijn. Het artikel zegt dat we enorme hoeveelheden tijd en geld verspillen aan het telkens opnieuw opbouwen van deze banen in plaats van één gestandaardiseerde, hoogwaardige baan te gebruiken waar iedereen gebruik van maakt.

3. De Oplossing: BEHELM (Het "Alles-in-één" Testcentrum)

Om dit op te lossen, stellen de auteurs een nieuwe infrastructuur voor genaamd BEHELM. Zie dit als het bouwen van een enorme, hypermoderne Rijopleiding die alle aspecten van de vaardigheden van een bestuurder tegelijkertijd test.

In plaats van slechts één test, creëert BEHELM een raster dat controleert:

  • Het Scenario: Testen we codegeneratie? Bugfixing? Vertaling?
  • De Taal: Is het Python, Java of C++?
  • Het Detailniveau: Kijken we naar één woord, een heel bestand, of een heel project?
  • De Metrics: In plaats van alleen "Pass/Fail", beoordeelt het model op:
    • Nauwkeurigheid: Werkt het?
    • Efficiëntie: Gebruikte het te veel computerkracht?
    • Interpreteerbaarheid: Kunnen we begrijpen waarom het die keuze maakte?
    • Eerlijkheid & Bias: Behandelde het alle gebruikers gelijk?
    • Robuustheid: Crashte het bij het krijgen van vreemde inputs?

De Kernboodschap

Het artikel concludeert dat we moeten stoppen met het behandelen van AI-codemodellen als simpele "autocomplete"-tools die eenvoudige quizjes nodig hebben. We moeten ze behandelen als professionele software engineers.

BEHELM is het voorstel om een gestandaardiseerde, uitgebreide testfaciliteit te bouwen die controleert of deze modellen daadwerkelijk kunnen overleven in de rommelige, complexe, echte wereld van de softwarekeuken, in plaats van alleen maar te slagen voor een parkeerplaats-test. Het doel is om ervoor te zorgen dat wanneer we deze robots vertrouwen met echte taken, ze ook echt klaar zijn voor het werk.

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 →