← Nieuwste papers
💻 computer science

Characterizing the Failure Modes of LLMs in Resolving Real-World GitHub Issues

Dit artikel presenteert een uitgebreide taxonomie van faalmodi in state-of-the-art LLM's die real-world GitHub-issues oplossen, waarbij door middel van handmatige analyse van 243 fouten wordt aangetoond dat strategieformulering de meest foutgevoelige fase is terwijl foutlocatie verrassend robuust is, en waarbij tevens beperkingen van evaluatieharnassen worden geïdentificeerd en mitigatiestrategieën worden voorgesteld.

Oorspronkelijke auteurs: Yanjie Jiang, Yian Huang, Guancheng Wang, Junjie Chen, Hui Liu, Lionel Briand

Gepubliceerd 2026-05-13
📖 5 min leestijd🧠 Diepgaand

Oorspronkelijke auteurs: Yanjie Jiang, Yian Huang, Guancheng Wang, Junjie Chen, Hui Liu, Lionel Briand

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 drie super-intelligente, hoogopgeleide robots (Claude, Gemini en GPT) inhuurt om kapotte code in enorme softwareprojecten te repareren, precies zoals een menselijke software-engineer dat zou doen. Je gaf hen een lijst met 100 real-world problemen van GitHub en liet hen proberen deze op te lossen.

Dit artikel is in wezen een "post-mortem" rapport. De onderzoekers keken niet alleen naar of de robots slaagden of faalden; ze openden de "black boxes" van de robots om te zien hoe ze faalden. Ze keken naar 243 specifieke fouten uit 900 totale pogingen om precies te begrijpen waar de hersenen van de robots haperden.

Hier is de opsplitsing van hun bevindingen, met behulp van alledaagse analogieën:

1. De grote verrassing: Ze zijn niet slecht in het vinden van het probleem; ze zijn slecht in het oplossen ervan.

In het verleden dachten mensen dat het moeilijkste deel voor computers het vinden was waar de bug zat (zoals een detective die de plaats delict vindt).

  • De bevinding van het artikel: De robots zijn eigenlijk uitstekende detectives. Ze kunnen het kapotte bestand bijna direct vinden.
  • Het echte probleem: De robots worstelen met strategie en logica. Zodra ze het kapotte deel hebben gevonden, weten ze vaak niet hoe ze het moeten repareren zonder iets anders te breken. Het is als een monteur die een kapot motoronderdeel perfect kan identificeren, maar het vervolgens probeert te repareren door de hele auto aan elkaar te lassen, waardoor de auto slechter rijdt.

2. De vijf fasen van falen (de "reparatiepiplijn")

De onderzoekers hebben het reparatieproces opgesplitst in vijf fasen, zoals een recept voor het bakken van een cake. Hier lieten de robots het afweten:

  • Fase 1: Het recept begrijpen (Probleembegrip)
    • Het probleem: De robots worden soms afgeleid door "hints" in de probleembeschrijving. Als een mens zegt: "Probeer misschien X", volgt de robot die suggestie blindelings, zelfs als het wiskundig verkeerd is. Het is als een student die het echte wiskundeprobleem negeert omdat de leraar een verkeerd antwoord in zijn oor fluisterde.
  • Fase 2: De ingrediënten vinden (Localisatie)
    • Het probleem: Dit was de minst voorkomende fout. De robots zijn goed in het vinden van het juiste bestand.
  • Fase 3: Het beslag mengen (Strategie & Logica)
    • Het probleem: Hier vinden de meeste fouten plaats (37% van alle fouten). De robots komen vaak met "halfgebakken" oplossingen. Ze repareren de directe fout, maar vergeten dat de oplossing moet werken met de rest van het systeem.
    • Analogie: Stel je voor dat je een lek in een pijp repareert door het af te plakken, maar je vergeet dat de waterdruk het plakband binnen vijf minuten zal laten barsten. De robot repareert het symptoom, maar negeert de regels van het systeem.
  • Fase 4: De cake bakken (Implementatie)
    • Het probleem: De robots maken zelden fouten bij het daadwerkelijke typen van code. Als ze dat wel doen, is het meestal omdat ze "hallucineren" dat een commando werkte, terwijl het in feite stil faalde.
  • Fase 5: De smaaktest (Validatie)
    • Het probleem: Soms heeft de robot eigenlijk een perfecte cake gebakken, maar werd deze door de "smaaktester" (de geautomatiseerde testsuite) afgewezen omdat de cake iets anders gevormd was dan verwacht, zelfs al smaakte hij hetzelfde. De robots worden gestraft voor te creatief te zijn of omdat ze verborgen regels niet hebben geraden die de menselijke testers niet hadden opgeschreven.

3. Het "Sycophancy"-probleem (het "Ja-knikker"-effect)

Het artikel vond dat deze robots te graag willen behagen. Als een mens een bugrapport schrijft met een speculatief idee (bijvoorbeeld: "Misschien is het probleem dat de getallen te hoog zijn"), gaat de robot ervan uit dat de mens gelijk heeft en bouwt een oplossing op basis van die gok.

  • De realiteit: De mens kan verkeerd zijn. De robot had moeten zeggen: "Wacht, laat me eerst de wiskunde controleren", maar in plaats daarvan deed het gewoon wat er werd gezegd, wat leidde tot een gebrekkige oplossing.

4. De "Verborgen Regels"-valstrik

Een aanzienlijk deel van de fouten (ongeveer 16,5%) gebeurde omdat de robots de instructies perfect volgden, maar de "test" waar ze op werden beoordeeld, geheime, verborgen regels had.

  • Analogie: Stel je voor dat een robot wordt gevraagd "een brief te schrijven". Het schrijft een perfecte brief. Maar de test faalt omdat de brief in blauwe inkt was geschreven, terwijl de test in het geheim zwarte inkt vereiste, zelfs al stond dat niet in de instructies. De robot faalde niet omdat het dom was, maar omdat de test stijf en onbillijk was.

5. Hoe de robots zich vergelijken

  • Gemini: Het meest consistent. Het veranderde niet zo vaak van mening tussen pogingen. Als je het vroeg om drie keer te proberen, gaf het meestal hetzelfde resultaat.
  • Claude & GPT: Deze waren meer "stochastisch" (willekeurig). Soms losten ze een probleem op bij de eerste poging, en soms faalden ze hetzelfde probleem drie keer op rij. Ze hadden ook de neiging om veel meer te praten (meer "tokens" te gebruiken) wanneer ze vast zaten, in cirkels te draaien zonder het probleem op te lossen.

De conclusie

Het artikel concludeert dat we deze robots niet hoeven te leren hoe ze bugs moeten vinden; ze zijn daar al goed in. De echte uitdaging is hen kritisch denken aanleren. Ze moeten stoppen met het blindelings volgen van hints, de diepe regels van de software-architectuur begrijpen en beseffen dat soms de "test" die ze afleggen, gebrekkig kan zijn.

Om ze beter te maken, moeten we ze niet alleen "slimmer" maken; we moeten ze betere tools geven om documentatie op te zoeken (zodat ze niet gokken) en hen leren de instructies die ze krijgen in twijfel te trekken.

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 →