Analyse von 14 zentralen LLM-Benchmarks: Funktionsweise, Stärken und Grenzen
Claude Opus 4.5 erreicht 80,6 % bei SWE-bench Verified, GPT-5.2 kommt auf 80,0 % und Gemini 3 Pro auf 76,2 %. Diese Werte spiegeln keine universelle Programmierkompetenz wider – sie messen den Erfolg bei spezifischen Aufgaben aus öffentlichen Python-Repositories. Eine vertiefte Analyse von 14 weit verbreiteten Benchmarks enthüllt deren Schwerpunkte, Testmethoden und blinde Flecken – besonders für Entwickler:innen mit mittlerer bis hoher Erfahrung, die Modelle für den Einsatz in der Praxis bewerten.
SWE-bench Verified: Fehlerbehebung in vertrautem Code
Dieser Benchmark testet kleine Bugfixes in 12 Open-Source-Python-Projekten – darunter Django. Von den ursprünglichen 2.294 Aufgaben wurden 500 nach Bedenken von OpenAI bezüglich mehrdeutiger Formulierungen manuell durch menschliche Reviewer validiert.
Testprozess:
- Tests laufen in einer Docker-Umgebung, um die Reproduzierbarkeit des Fehlers zu bestätigen.
- Die Modelle erhalten das GitHub-Issue, den Repository-Kontext und müssen einen Ein-Pass-Diff generieren.
- Der Diff wird angewendet; alle Tests müssen ohne Brechen der Baseline-Test-Suite erfolgreich sein.
Beispiel aus Django (ID django__django-16485):
from decimal import Decimal
from django.template.defaultfilters import floatformat
floatformat('0.00', 0)
floatformat(Decimal('0.00'), 0)Beide Aufrufe lösen ValueError: valid range for prec is [1, MAX_PREC] aus. Die Metrik gibt den Anteil der Aufgaben an, bei denen alle Tests nach dem Fix erfolgreich durchlaufen.
Kritik: 161 Aufgaben erfordern nur 1–2 Codezeilen; viele Beispiele aus den Repositories tauchen wahrscheinlich bereits im Trainingsdatensatz der Modelle auf. Bessere Alternativen sind SWE-bench Multilingual und der bevorstehende, private SWE-bench Pro.
Terminal-Bench 2.0: Reale Linux-Terminal-Workflows
Testet 89 terminalbasierte Aufgaben – von Videotranskription bis zur Kompilierung des Linux-Kernels. Manuell erstellt vom Laude Institute und Stanford mit strenger pytest-Validierung.
Wesentliche Merkmale:
- Umgebung bereitgestellt über Dockerfile und tmux im Rahmen des Terminus-2-Frameworks.
- Modelle haben Internetzugriff – doch die Autoren prüften nicht systematisch auf unbeabsichtigte Datenlecks.
Beispiel: Transkribiere das Zork-Video und gib die Spielaktionen als n oder get bag in /app/solution.txt aus.
Spitzenreiter: GPT-5.2 (64,9 %), Claude Opus 4.5 (63,1 %). Die Kritik bleibt gering – nicht zuletzt wegen der Neuheit des Benchmarks; zudem ist er hochgradig relevant für DevOps und Infrastruktur-Automatisierung.
τ² (tau-bench): Simulation von Live-Customer-Support
Fokussiert auf Live-Chat-Szenarien aus Einzelhandel, Luftfahrt und Telekommunikation. Sierra Research entwickelte realistische Datenbankschemata und Tools – validiert durch menschliche Expert:innen.
Metrik: pass^k – Erfolg über k aufeinanderfolgende Durchläufe (bis zu pass^4).
- Agent und Nutzer werden jeweils vom selben LLM simuliert.
- Tool-Aufrufe umfassen u. a. Nutzer-Suche und Buchungsabruf.
Luftfahrt-Beispiel: Goldkundin Mei Brown (ID mei_brown_7075) beschwert sich über Verspätung HAT045 PHX→SEA. Die Bewertung hängt von korrektem Aufruf von get_user_details und einer eigenständigen, vom LLM getroffenen Entscheidung ab.
Kritik: Vereinfachte Datenbankschemata; Schwachstellen auf Prompt-Ebene; OpenAI hat den Luftfahrt-Bereich komplett ausgeschlossen, da die Ground-Truth-Daten inkonsistent waren.
MCP Atlas: Multi-Step-Tool-Calling im großen Maßstab
Benchmarks von Scale AI: 1.000 Abfragen, die koordinierten Einsatz mehrerer MCP-Tools erfordern (z. B. Open Library, arXiv). Die Hälfte ist öffentlich zugänglich, die andere Hälfte privat.
Bewertung: Mehr als 75 % der Aussagen müssen als wahr validiert werden (durch ein LLM beurteilt; Teilpunkte = 0,5).
Beispiel: „Welches ist das älteste Buch über Vulkane – und wann wurde die zugehörige Cover-Domain registriert?“
Kritik: Willkürliche 75 %-Schwelle; ausschließlich lesezugriffsorientierte Tools; es bleibt unklar, ob Scale AI als Ersteller und Bewertungsinstanz neutral bleibt.
OSWorld: GUI-Automatisierung via PyAutoGUI
369 Desktop-Anwendungsaufgaben (Ubuntu/Windows). 30 % umfassen Multi-App-Workflows; rund 30 sind aktuell unlösbar.
Testverfahren: VM-Umgebung mit Screenshots; Tastatur- und Maussteuerung über PyAutoGUI. Bewertet wird der Endzustand – nicht Zwischenschritte.
VSCode-Beispiel: Aktiviere Soft Wrap bei 50 Zeichen.
Kritik: Chrome-bezogene Aufgaben scheitern häufig; einige Lösungen umgehen die GUI vollständig (z. B. mittels sed) – was das Kernziel untergräbt.
ARC-AGI: Test der grundlegenden Intelligenz
Visuelle Denkaufgaben auf Basis elementaren Wissens (z. B. Pixelraster). ARC-AGI 2 (2025) enthält 1.360 Anti-Brute-Force-Probleme, die Generalisierungsfähigkeit – nicht Auswendiglernen – prüfen sollen.
Spitzenreiter: GPT-5.2 (54,2 %). Im Gegensatz zu fachlich fokussierten Benchmarks misst ARC-AGI reine Mustererkennung und Abstraktionsfähigkeit.
| Benchmark | Spitzenmodell | % | Fokus |
|----------|------------|----|-------|
| SWE-bench Verified | Claude Opus 4.5 | 80,6 | Python-Bugfix |
| Terminal-Bench 2.0 | GPT-5.2 | 64,9 | Linux-Shell |
| τ² | GPT-5.2 | 90,4 | Tool-Calling im Chat |
| MCP Atlas | Claude Opus 4.5 | 62,3 | Multi-Tool-Abfragen |
| OSWorld | Claude Opus 4.5 | 66,2 | GUI-Automatisierung |
| ARC-AGI | GPT-5.2 | 54,2 | Visuelles Schlussfolgern |
Wichtige Erkenntnisse
- SWE-bench Verified ist durch Trainingsdaten-Kontamination veraltet – warten Sie auf SWE-bench Pro.
- Terminal-Bench 2.0 spiegelt am besten reale Entwickler-Workloads wider, die Shell-Skripting und Systeminteraktion erfordern.
- τ² und MCP Atlas zeigen Reife beim Tool-Calling – leiden aber unter LLM-basierten Bewertern und zu stark vereinfachten Umgebungen.
- OSWorld und ARC-AGI treiben die Grenzen: GUI-Automatisierung bzw. grundlegende Schlussfolgerungskompetenz.
- Die Wahl des Benchmarks muss stets Ihrem konkreten Anwendungsfall entsprechen – ergänzen Sie ihn daher immer durch private, produktionsnahe Evaluierungen.
Der Artikel behandelt die verbleibenden Benchmarks – darunter GPQA und MMLU-Pro – mit derselben Tiefe und fokussiert sich konsequent auf die Bewertungsmechanismen für den Einsatz von LLMs in der praktischen Softwareentwicklung.
— Editorial Team
Noch keine Kommentare.