Automatically Benchmarking LLM Code Agents through Agent-Driven Annotation and Evaluation
Dit paper introduceert PRDBench, een schaalbaar en nauwkeurig evaluatiekader voor code-agents dat bestaat uit een agent-gedreven aanpak voor het genereren van realistische projecttaken en een gespecialiseerd, fijngetraind beoordelingsmodel dat een hoge mate van menselijke overeenstemming bereikt.
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 grote, complexe bouwopdracht hebt: je wilt een volledig nieuw kantorencomplex bouwen, niet zomaar één kamer. Je geeft een architect (de AI) een gedetailleerd bouwplan (een Product Requirement Document of PRD) en zegt: "Bouw dit."
De vraag is: Hoe weet je of de architect het goed heeft gedaan?
Dit is het probleem dat deze wetenschappelijke paper aanpakt. Hier is de uitleg in simpele taal, met wat creatieve vergelijkingen.
1. Het Probleem: De "Gouden Hand" en de "Stijve Rol"
Tot nu toe hadden we twee manieren om te checken of een AI goed codeerde, maar beide hadden grote nadelen:
- Manier A: De Menselijke Expert (Te duur en traag)
Om te checken of een complex softwareproject goed is, heb je een senior architect nodig die urenlang naar de plannen kijkt. Dit is als het controleren van een heel kantorencomplex door één persoon die elke steen moet inspecteren. Het kost enorm veel geld, tijd en je vindt maar weinig experts die dit kunnen. - Manier B: De Stijve Test (Te beperkt)
Vaak gebruiken we automatische tests die alleen kijken of de deurklink werkt of dat de lichten aan gaan. Maar wat als de muren scheef staan of de vloer te slap is? Deze tests zijn te stijf. Ze kijken niet naar het geheel, maar alleen naar losse onderdelen.
Daarnaast proberen sommige systemen een andere AI te laten oordelen (een "AI-rechter"). Maar deze AI's zijn vaak te slordig; ze hallucineren of missen subtiele fouten, net als een stagiair die denkt dat hij alles snapt, maar in werkelijkheid de instructies verkeerd leest.
2. De Oplossing: PRDBench (De Nieuwe Bouwopdracht)
De auteurs van dit paper hebben een nieuwe manier bedacht om AI's te testen, genaamd PRDBench.
Hoe werkt het? (De "Agent-gedreven" aanpak)
In plaats van dat mensen urenlang testcases moeten schrijven, laten ze een slimme AI (een "bouwmeester") het werk doen:
- De AI krijgt een opdracht: "Bouw een systeem voor logistiek."
- De AI schrijft zelf het bouwplan (de PRD) en de testregels.
- De menselijke rol: Mensen hoeven alleen nog maar te kijken: "Klinkt dit plan logisch? Past het bij de opdracht?" Ze hoeven niet zelf de code te schrijven of de tests te maken.
- Als er iets mis is, zegt de mens: "Nee, dat klopt niet," en de AI past het aan.
Dit is alsof je een assistent hebt die 50 verschillende bouwplannen voor je maakt, en jij alleen nog maar de "goede keur" geeft. Dit maakt het veel sneller en goedkoper om grote, echte projecten te testen.
3. De Rechter: PRDJudge (De Gespecialiseerde Inspecteur)
Nu hebben we 50 moeilijke bouwopdrachten. Wie gaat ze controleren?
Ze hebben een speciale AI-rechter gebouwd, genaamd PRDJudge.
- Het probleem met gewone AI's: Een gewone AI-rechter (zoals een standaard chatbot) is als een inspecteur die wel kan lezen, maar niet goed kan nadenken over complexe technische details. Hij zegt soms "Goed!" terwijl er een gat in de vloer zit.
- De oplossing: De auteurs hebben een AI getraind die gespecialiseerd is in controleren. Ze hebben hem getraind met duizenden voorbeelden van hoe een mens een project beoordeelt.
- Het resultaat: Deze gespecialiseerde AI is nu 90% zo goed als een mens in het beoordelen van code. Hij kijkt niet alleen of de code werkt, maar ook of het voldoet aan de hele bouwplaat (de PRD). Hij is als een inspecteur die precies weet waar hij moet zoeken en geen fouten over het hoofd ziet.
4. Wat hebben ze ontdekt? (De Resultaten)
Ze hebben verschillende AI's (de "bouwmeesters") laten proberen deze 50 projecten te bouwen. Hier zijn de belangrijkste lessen:
- De "Start" is het moeilijkst: De slimste AI-modellen (zoals de nieuwste versies van GPT of Claude) zijn goed in het begin: ze kunnen snel een skelet van een project neerzetten.
- De "Reparatie" is lastig: Als er fouten zijn, blijken sommige AI's in de war te raken. Ze proberen een muur te repareren, maar breken daardoor de vloer eronder.
- Bedrijfssoftware vs. Losse AI: De AI's die in grote bedrijven worden gebruikt (zoals "Claude Code" of "Gemini CLI") zijn vaak voorzichtiger. Ze bouwen misschien iets langzamer, maar als ze een fout moeten repareren, doen ze dat netter en breken ze minder dingen.
- Geen "Eén Oplossing": Er is geen enkele AI die perfect is in alles. Sommige zijn goed in het bedenken van ideeën, andere zijn beter in het uitvoeren van de details.
Samenvatting in één zin
De auteurs hebben een manier bedacht om AI's die software bouwen te testen door AI's te laten helpen bij het maken van de testopdrachten en een gespecialiseerde AI-rechter te trainen die net zo goed oordeelt als een mens, zodat we sneller en betrouwbaarder kunnen zien welke AI's echt goed kunnen bouwen.
Het is alsof ze een fabriek hebben gebouwd die automatisch 50 nieuwe bouwopdrachten maakt en een super-geleerde inspecteur heeft opgeleid om te zeggen of de gebouwen veilig zijn, zonder dat ze 100 mensen hoeven aan te nemen.
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.