RubberDuckBench: A Benchmark for AI Coding Assistants
Het artikel introduceert RubberDuckBench, een meertalige benchmark afgeleid van real-world GitHub pull requests om AI-codingassistenten te evalueren, en onthult dat zelfs state-of-the-art-modellen worstelen met consistentie en correctheid terwijl ze vaak hallucineren, zonder waargenomen correlatie tussen kosten en prestaties.
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 een team hebt van zeer slimme, zeer snelle robots die voor jou computercode kunnen schrijven. Je stelt hen vragen zoals: "Waarom gedraagt dit deel van de code zich raar?" of "Wat gebeurt er als ik dit nummer verander?" Je verwacht dat ze naar de specifieke code kijken waar je aan werkt en je een perfect antwoord geven.
Dit artikel, RubberDuckBench, is als een eindexamen voor deze robotassistenten. De auteurs (onderzoekers van Bryn Mawr College, Google en Meta) wilden zien of deze robots echt goed zijn in het beantwoorden van vragen over specifieke code, of dat ze gewoon gokken.
Hier is de uiteenzetting van hun studie met behulp van eenvoudige analogieën:
1. Het Probleem: De "Buiten Context"-Valstrik
Voordat dit onderzoek werd gedaan, waren de meeste tests voor AI-coders als het vragen aan een student om een volledig nieuw essay te schrijven op basis van een opdracht. Maar in het echte leven vragen programmeurs niet alleen om nieuwe code; ze stellen vragen over code die al bestaat in een specifiek project.
- De Oude Tests: Als het een chef vragen is: "Hoe maak je een taart?"
- De Realiteit: Als het een chef is die vraagt: "Waarom is mijn taart verbrand in de oven op het derde rooster?"
De onderzoekers realiseerden zich dat niemand een goede test had gebouwd voor het tweede type vraag.
2. Het Bouwen van het Examen: De "Rubber Eend"-Methode
Programmeurs praten vaak met "rubberen eenden" (of hun collega's) om codeproblemen op te lossen. De onderzoekers keken naar echte gesprekken tussen ontwikkelaars op GitHub (een plek waar mensen code delen).
- De Bron: Ze vonden duizenden opmerkingen waarin ontwikkelaars elkaar specifieke vragen stelden over hun code.
- Het Filter: Veel opmerkingen waren gewoon suggesties zoals "fix deze typefout". De onderzoekers gebruikten AI en mensen om het ruis te filteren en de goede vragen om te zetten in een duidelijke, 15-vragen examen.
- Het Beoordelingssleutel: Omdat er niet slechts één "juiste" manier is om code uit te leggen, creëerden ze gedetailleerde rubrics (beoordelingsformulieren). Denk hierbij aan een docentengids die zegt: "Als de student het trefwoord 'const' noemt, geef ze 2 punten. Als ze liegen over hoe de code werkt, trek 3 punten af."
3. De Test: 20 Robots Doen het Examen
Ze zetten 20 verschillende AI-modellen (de "robots") aan dit examen. Hieronder waren beroemde namen zoals GPT-5, Claude Opus, Grok 4 en anderen. Ze vroegen hen om de 15 vragen te beantwoorden op basis van de specifieke code die werd verstrekt.
4. De Resultaten: De Robots zijn Gebrekkig
De resultaten waren verrassend en een beetje teleurstellend voor de "super-slimme" robots:
- Geen Duidelijke Winnaars: De top-robot, Grok 4, kreeg ongeveer 69% van de vragen goed. De volgende besten haalden rond de 68%. Statistisch gezien zaten ze allemaal in dezelfde "liga". Er was geen duidelijke kampioen.
- De "Perfecte Score" Mythe: Zelfs de beste robots kregen zelden een vraag volledig goed. De top-robots slaagden er slechts in om 2 van de 15 vragen perfect te beantwoorden over al hun pogingen heen. Het grootste deel van hun punten kwam van "gedeeltelijke credit" (een deel van het antwoord goed hebben).
- Het Leugen Probleem (Hallucinaties): Dit was het grootste probleem. Gemiddeld logen de robots of verzonnen ze feiten in 58% van hun antwoorden.
- Analogie: Stel je voor dat je een gids vraagt over een specifieke straat in jouw stad. De helft van de tijd vertellen ze je zelfverzekerd dat de straat een park is, terwijl het eigenlijk een bakkerij is.
- Zelfs de beste modellen, zoals o3, liegen in 67% van hun antwoorden.
- Python Strubbelingen: De robots waren veel beter in het beantwoorden van vragen over Java- en C++-code, maar ze struikelden aanzienlijk wanneer de code in Python was geschreven.
5. Het Prijskaartje versus Prestatie
De onderzoekers controleerden ook of het betalen van meer geld of het gebruik van een "groter brein" (meer parameters) de robots slimmer maakte.
- Geld koopt geen genie: De duurste modellen (zoals Claude Opus) kosten veel om te draaien, maar presteerden niet veel beter dan goedkopere. Sterker nog, Grok 4 was de beste performer, maar kostte 12 keer minder dan de dure Claude-modellen.
- Groter is niet beter: Voor open-source modellen presteerde het grootste model (120 miljard parameters) eigenlijk slechter dan een kleiner model (20 miljard parameters).
De Conclusie
Het artikel concludeert dat AI-codeassistenten, hoewel ze beter worden, nog niet betrouwbaar zijn voor het beantwoorden van complexe vragen over specifieke code. Ze gokken vaak, ze liegen frequent, en de duurste opties zijn niet per se de slimste.
De auteurs hebben RubberDuckBench gebouwd als een doelwit voor toekomstig onderzoek, in de hoop ontwikkelaars te stimuleren om AI-assistenten te bouwen die eerlijk, accuraat zijn en de code die ze gebruiken werkelijk begrijpen, in plaats van gewoon dingen te verzinnen.
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.