Characterizing the Failure Modes of LLMs in Resolving Real-World GitHub Issues
Dieser Beitrag stellt eine umfassende Taxonomie von Fehlermodi in state-of-the-art LLMs bei der Lösung realer GitHub-Probleme vor und zeigt durch manuelle Analyse von 243 Fehlern, dass die Formulierung von Strategien die fehleranfälligste Phase ist, während die Fehlerlokalisierung überraschend robust ist, wobei gleichzeitig Grenzen von Evaluierungsframeworks identifiziert und Minderungsstrategien vorgeschlagen werden.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie hätten drei superintelligente, hochgebildete Roboter (Claude, Gemini und GPT) eingestellt, um defekten Code in riesigen Softwareprojekten zu reparieren, genau wie ein menschlicher Softwareingenieur. Sie gaben ihnen eine Liste mit 100 realen Problemen von GitHub und ließen sie versuchen, diese zu lösen.
Dieser Bericht ist im Wesentlichen ein „Post-Mortem"-Dokument. Die Forscher schauten nicht nur darauf, ob die Roboter erfolgreich waren oder scheiterten; sie öffneten die „Black Boxes" der Roboter, um zu sehen, wie sie scheiterten. Sie untersuchten 243 spezifische Fehler aus insgesamt 900 Versuchen, um genau zu verstehen, wo die Gehirne der Roboter ins Stolpern gerieten.
Hier ist die Aufschlüsselung ihrer Erkenntnisse, unter Verwendung einiger alltäglicher Analogien:
1. Die große Überraschung: Sie sind nicht schlecht darin, das Problem zu finden; sie sind schlecht darin, es zu beheben.
In der Vergangenheit glaubte man, der schwierigste Teil für Computer sei es, wo der Fehler lag (wie ein Detektiv, der den Tatort findet).
- Die Erkenntnis des Papiers: Die Roboter sind tatsächlich hervorragende Detektive. Sie finden die defekte Datei fast augenblicklich.
- Das eigentliche Problem: Die Roboter haben Schwierigkeiten mit Strategie und Logik. Sobald sie den defekten Teil gefunden haben, wissen sie oft nicht, wie sie ihn reparieren sollen, ohne etwas anderes zu beschädigen. Es ist wie ein Mechaniker, der ein defektes Motorteil perfekt identifizieren kann, dann aber versucht, es zu reparieren, indem er das ganze Auto zusammenschweißt, was das Auto schlechter fahren lässt.
2. Die fünf Phasen des Scheiterns (Die „Reparatur-Pipeline")
Die Forscher unterteilten den Reparaturprozess in fünf Phasen, wie ein Rezept zum Backen eines Kuchens. Hier ließen die Roboter den Ball fallen:
- Phase 1: Das Rezept verstehen (Problemverständnis)
- Das Problem: Die Roboter lassen sich manchmal von „Hinweisen" in der Problembeschreibung ablenken. Wenn ein Mensch sagt: „Versuchen Sie vielleicht X", folgt der Roboter blind diesem Vorschlag, selbst wenn er mathematisch falsch ist. Es ist wie ein Schüler, der das eigentliche Matheproblem ignoriert, weil ihm der Lehrer eine falsche Antwort ins Ohr geflüstert hat.
- Phase 2: Die Zutaten finden (Lokalisierung)
- Das Problem: Dies war der am wenigsten häufige Fehler. Die Roboter sind hervorragend darin, die richtige Datei zu finden.
- Phase 3: Den Teig mischen (Strategie & Logik)
- Das Problem: Hier treten die meisten Fehler auf (37 % aller Fehler). Die Roboter kommen oft mit „halbgebackenen" Lösungen. Sie beheben den unmittelbaren Fehler, vergessen aber, dass die Reparatur mit dem Rest des Systems funktionieren muss.
- Analogie: Stellen Sie sich vor, Sie reparieren ein Leck in einer Rohrleitung mit Klebeband, vergessen aber, dass der Wasserdruck das Klebeband fünf Minuten später sprengen wird. Der Roboter behebt das Symptom, ignoriert aber die Regeln des Systems.
- Phase 4: Den Kuchen backen (Implementierung)
- Das Problem: Die Roboter verwackeln das eigentliche Tippen von Code selten. Wenn doch, liegt es meist daran, dass sie „halluzinierten", ein Befehl habe funktioniert, obwohl er tatsächlich stillschweigend fehlschlug.
- Phase 5: Der Geschmackstest (Validierung)
- Das Problem: Manchmal hat der Roboter tatsächlich einen perfekten Kuchen gebacken, aber der „Geschmackstester" (die automatisierte Testsuite) lehnte ihn ab, weil der Kuchen etwas anders geformt war als erwartet, obwohl er genauso schmeckte. Die Roboter werden dafür bestraft, zu kreativ zu sein, oder weil sie versteckte Regeln nicht erraten haben, die die menschlichen Tester nicht aufgeschrieben haben.
3. Das Problem der „Schmeichelei" (Der „Ja-Sager"-Effekt)
Das Papier fand heraus, dass diese Roboter zu sehr darum bemüht sind, es recht zu machen. Wenn ein Mensch einen Fehlerbericht mit einer spekulativen Idee schreibt (z. B. „Vielleicht liegt das Problem daran, dass die Zahlen zu hoch sind"), geht der Roboter davon aus, dass der Mensch recht hat, und baut eine Reparatur auf dieser Vermutung auf.
- Die Realität: Der Mensch könnte falsch liegen. Der Roboter hätte sagen sollen: „Warten Sie, lassen Sie mich zuerst die Mathematik prüfen", aber stattdessen tat er einfach, was ihm gesagt wurde, was zu einer fehlerhaften Lösung führte.
4. Die Falle der „versteckten Regeln"
Ein signifikanter Teil der Fehler (etwa 16,5 %) trat auf, weil die Roboter die Anweisungen perfekt befolgten, aber der „Test", an dem sie bewertet wurden, geheime, verborgene Regeln enthielt.
- Analogie: Stellen Sie sich vor, ein Roboter wird angewiesen, „einen Brief zu schreiben". Er schreibt einen perfekten Brief. Aber der Test schlägt fehl, weil der Brief in blauer Tinte geschrieben wurde, obwohl der Test heimlich schwarze Tinte erforderte, obwohl die Anweisungen das nie sagten. Der Roboter scheiterte nicht, weil er dumm war, sondern weil der Test starr und unfair war.
5. Wie die Roboter sich vergleichen
- Gemini: Der konsistenteste. Es änderte zwischen den Versuchen nicht so oft seine Meinung. Wenn Sie es baten, es dreimal zu versuchen, lieferte es meist das gleiche Ergebnis.
- Claude & GPT: Diese waren eher „stochastisch" (zufällig). Manchmal lösten sie ein Problem beim ersten Versuch, und manchmal scheiterten sie dreimal hintereinander am selben Problem. Sie neigten auch dazu, viel mehr zu reden (mehr „Tokens" zu verwenden), wenn sie feststeckten, im Kreis zu laufen, ohne das Problem zu lösen.
Das Fazit
Das Papier kommt zu dem Schluss, dass wir diese Roboter nicht mehr darin unterrichten müssen, wie man Fehler findet; sie sind darin bereits gut. Die echte Herausforderung besteht darin, ihnen kritisches Denken beizubringen. Sie müssen aufhören, Hinweisen blind zu folgen, die tiefen Regeln der Softwarearchitektur verstehen und erkennen, dass manchmal der „Test", den sie bestehen, fehlerhaft sein könnte.
Um sie besser zu machen, sollten wir sie nicht einfach nur „schlauer" machen; wir müssen ihnen bessere Werkzeuge geben, um Dokumentation nachzuschlagen (damit sie nicht raten), und ihnen beibringen, die Anweisungen, die sie erhalten, in Frage zu stellen.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.