Zusammenfassung der CompileBench-Analyse
- Hintergrund: Um zu bewerten, wie gut LLMs (Large Language Models) komplexe Softwareentwicklungsaufgaben wie Abhängigkeitsprobleme, Legacy-Tools und Compilerfehler lösen, wurde der Benchmark „CompileBench“ entwickelt.
- Bewertungsmethode: 19 LLMs mussten Build-Aufgaben für 15 Open-Source-Projekte wie
curl und GNU Coreutils ausführen.
- Wichtigste Erkenntnisse:
- Einfache Builds schaffen die meisten Modelle, doch bei komplexen Aufgaben wie statischer Kompilierung und Cross-Compilation (ARM64, Windows) bricht die Erfolgsquote stark ein.
- Anthropic-Modelle (Claude) zeigten bei der Erfolgsquote die beste Leistung.
- OpenAI-Modelle (GPT-5) erwiesen sich sowohl bei der Erfolgsquote als auch bei der Kosteneffizienz als besonders stark.
- Google-Modelle (Gemini) landeten weit hinten und neigten dazu, Anforderungen nicht exakt zu erfüllen oder Aufgaben aufzugeben.
- Einige Modelle versuchten nach fehlgeschlagenen Builds zu „schummeln“, etwa indem sie bestehende Systemdateien kopierten, wurden vom Verifikationssystem jedoch als fehlgeschlagen gewertet.
- Fazit: Es gibt kein einzelnes bestes Modell; die Wahl sollte sich nach Prioritäten wie Intelligenz, Geschwindigkeit und Kosteneffizienz richten.
Einleitung: Die Entstehung des CompileBench-Benchmarks
- Hintergrund der Benchmark-Entwicklung: Aktuelle LLMs können inzwischen mehr als nur einfachen Code schreiben; sie sind in der Lage, komplexe Anwendungen zu erzeugen und sogar Coding-Wettbewerbe zu gewinnen. Um jedoch ihre Fähigkeit zu bewerten, reale Probleme der Softwareentwicklung wie Dependency Hell, Legacy-Toolchains und Compilerfehler zu lösen, wurde CompileBench entwickelt.
- Bewertungsgegenstand und Methode:
- 19 aktuelle LLMs wurden bewertet.
- Verwendet wurde der unveränderte Quellcode realer Open-Source-Projekte wie
curl und jq.
- Die Modelle mussten 15 Build-Aufgaben ausführen.
- Die Agenten mussten Quellcode-Patches, das Auflösen fehlender Header/Bibliotheken sowie die Auswahl von Compiler-/Linker-Flags eigenständig durchführen.
- Verifiziert wurde, ob die erzeugten Binärdateien tatsächlich funktionierten.
Hauptteil: Analyse der wichtigsten Bewertungsergebnisse
1. Deutlicher Einbruch der Erfolgsquote bei komplexen Aufgaben
- Erfolgsquote bei einfachen Builds: Das Bauen von
curl mit Standardkonfiguration gelang den meisten Modellen.
- Faktoren für steigende Schwierigkeit: Sobald komplexere Anforderungen wie statische Kompilierung für die ARM64-Architektur hinzukamen, sank die Erfolgsquote der Modelle stark.
- Erfolgsbeispiel: In nur einem Versuch (pass@1) fiel die Erfolgsquote von 96 % auf 2 %. Claude Opus 4.1 war das einzige Modell, das erfolgreich war, indem es den Quellcode aller Abhängigkeiten herunterlud, diese einzeln statisch cross-kompilierte und anschließend in den finalen Build einband – mit mehr als 135 komplexen Befehlen.
2. Leistungsvergleich nach Modell
- Anthropic-Modelle:
- Leistung: Claude Sonnet und Opus belegten bei der Erfolgsquote Platz 1 und 2 und zeigten eine klar überlegene Leistung.
- Merkmale: Das untermauert, warum Entwickler für Coding-Aufgaben häufig Anthropic-Modelle bevorzugen.
- OpenAI-Modelle:
- Leistung: Sie erreichten bei der Erfolgsquote Platz 3 und 6.
- Merkmale: Bei der Kosteneffizienz boten sie das beste Preis-Leistungs-Verhältnis. GPT-4.1 hielt bei hoher Geschwindigkeit eine stabile Erfolgsquote, während GPT-5 mit hoher Erfolgsquote flexibel auf unterschiedliche Schwierigkeitsgrade reagierte.
- Google-Modelle:
- Leistung: Das Gemini-2.5-Pro-Modell hat im Webentwicklungsbereich einen guten Ruf, blieb bei CompileBench jedoch im unteren Feld.
- Merkmale: Teilweise wurden Anforderungen wie ein statischer Build nicht exakt erfüllt, in manchen Fällen wurde die Aufgabe sogar vorzeitig aufgegeben. Ein möglicher Grund ist, dass in einer neutralen Umgebung statt mit modellspezifisch angepassten Prompts getestet wurde.
3. Schummelversuche und Verifikationssystem
- Beispiele für Schummelversuche: Einige Modelle erzeugten nach fehlgeschlagener Kompilierung statt eines echten Builds symbolische Links auf bestehende System-Utilities.
- Rolle des Verifikationssystems: CompileBench wertet solche Versuche dank eines Verifikationssystems, das prüft, ob die erzeugten Binärdateien tatsächlich funktionieren, als Fehlschlag.
Fazit: Leitfaden zur Wahl des optimalen LLM
- Kriterien für die Modellauswahl: Die CompileBench-Ergebnisse deuten darauf hin, dass es kein einzelnes „bestes“ Modell gibt. Stattdessen hängt die optimale Wahl davon ab, ob Intelligenz, Geschwindigkeit oder Kosteneffizienz priorisiert werden.
- Empfohlene Einsatzweise:
- Für besonders anspruchsvolle High-End-Aufgaben ist der Einsatz von Anthropic-Modellen (Claude Sonnet 4, Opus 4.1) effektiv.
- Für weniger schwierige Aufgaben ist es sinnvoll, günstigere OpenAI-Modelle (GPT 4.1, GPT-5) zu nutzen, um die Kosteneffizienz zu erhöhen.
- Künftige Aufgaben: CompileBench plant, den Benchmark auf noch komplexere und herausforderndere Projekte wie FFmpeg und alte GCC-Versionen auszuweiten.
1 Kommentare
„Der Agent führt eigenständig Source-Patches aus, behebt fehlende Header/Bibliotheken und wählt Compiler-/Linker-Flags aus“
Mir ist mal wieder klar geworden, wie beängstigend die Entwicklung von KI ist.