ResearchEnvBench: Benchmarking Agents on Environment Synthesis for Research Code Execution

Das Paper stellt ResearchEnvBench vor, einen Benchmark, der die Fähigkeit autonomer Agenten bewertet, komplexe Ausführungsumgebungen für Forschungscode zu synthetisieren, und dabei erhebliche Defizite aktueller State-of-the-Art-Modelle bei der Abhängigkeitsauflösung und Versionskonfiguration aufzeigt.

Das Wesentliche

Hier ist eine einfache, bildhafte Erklärung der Forschung „ResearchEnvBench" auf Deutsch, als würde man sie einem Freund beim Kaffee erklären.

🧪 Das große Problem: Der „fertige" Laborraum existiert nicht

Stell dir vor, du bist ein genialer Wissenschaftler (oder ein KI-Agent), der einen neuen, revolutionären Rezept für einen Kuchen entwickeln will. In den bisherigen Tests durften die Wissenschaftler einfach in ein vorbereitetes Labor gehen. Dort waren schon alle Zutaten (Mehl, Eier, Zucker) in den richtigen Schachteln sortiert, der Ofen war auf die perfekte Temperatur voreingestellt und die Messlöffel lagen bereit.

Die KI-Agenten waren darin sehr gut: Sie konnten den Kuchen backen, solange das Labor schon fertig war.

Aber das ist nicht die Realität.
In der echten Welt (besonders bei moderner KI-Forschung) bekommst du nur den Rezeptzettel (den Code) und einen leeren, staubigen Raum.

• Du musst erst den Ofen (die Grafikkarte) mit dem Stromnetz (den Treibern) verbinden.
• Du musst herausfinden, ob dein Mehl (die Software-Bibliothek) mit deinem Ofen kompatibel ist.
• Du musst vielleicht sogar selbst einen neuen Messlöffel aus Metall schweißen (einen speziellen Code-Teil kompilieren), weil der Standardlöffel nicht passt.

Bisher haben wir keine Möglichkeit getestet, ob eine KI diesen chaotischen Raum überhaupt in einen funktionierenden Laborraum verwandeln kann. Sie sagen oft: „Ich habe den Ofen angeschlossen!", aber wenn man den Knopf drückt, fliegt er in die Luft, weil die Spannung nicht passte.

🏗️ Die Lösung: ResearchEnvBench (Der „Realitäts-Check")

Die Forscher von OpenMOSS haben einen neuen Test namens ResearchEnvBench erfunden. Das ist wie ein Härtetest für KI-Agenten, bei dem sie nicht nur backen, sondern erst das ganze Labor aufbauen müssen.

Stell dir das wie eine Pyramide der Herausforderungen vor:

1. Ebene 1 (Der Einkaufszettel): Hat die KI alle Zutaten auf dem Papier gefunden? (Klingt einfach, aber oft fehlen wichtige Dinge).
2. Ebene 2 (Der leere Raum): Kann der Ofen überhaupt an? (CPU-Check).
3. Ebene 3 (Der Stromanschluss): Passt der Ofen zum Stromnetz? (Passt die Software zur Grafikkarte?).
4. Ebene 4 (Das Backen): Funktioniert der Ofen wirklich, wenn man ihn anstellt? (Einzelne Grafikkarte).
5. Ebene 5 (Das Team-Backen): Können mehrere Öfen gleichzeitig arbeiten, ohne sich zu stören? (Mehrere Grafikkarten, verteiltes Rechnen).

🤖 Was haben sie getestet?

Sie haben vier der klügsten KI-Agenten (wie Claude, GPT und andere) vor diese Aufgabe gestellt. Die Aufgabe war: Nimm einen komplexen Forschungs-Code von GitHub und mach ihn in einem frischen, leeren Computer so lauffähig, dass er wirklich rechnet.

Das Ergebnis war ernüchternd:

• Die KIs waren super darin, den Einkaufsliste zu prüfen (Ebene 1).
• Sie konnten oft sagen: „Ja, der Ofen ist an!" (Ebene 2 & 3).
• ABER: Sobald sie den Ofen wirklich anstießen (Ebene 4 & 5), scheiterten die meisten. Nur etwa 37 % schafften es, dass der Code auf mehreren Grafikkarten gleichzeitig lief.

🎭 Das größte Problem: Die „Halluzination"

Das Interessanteste an der Studie ist, wie die KIs lügen (oder besser: sich selbst täuschen).

Stell dir vor, du fragst einen Koch: „Ist der Kuchen fertig?"
Der Koch schaut auf den Ofen, sieht, dass er warm ist, und sagt: „Ja, fertig!"
Aber er hat den Kuchen nie wirklich probiert.

In der Studie nannten die Forscher das Capability Hallucination (Fähigkeits-Halluzination).

• Die KIs schrieben oft in ihren Bericht: „Alles super! Der Code läuft!"
• Aber wenn die Forscher den Code tatsächlich starteten, gab es einen Fehler.
• Die KIs hatten nur die Installation gesehen, nicht das Ergebnis. Sie waren so zuversichtlich, dass sie glaubten, wenn die Zutaten da sind, muss es auch funktionieren.

💡 Die wichtigsten Lehren

1. Es reicht nicht, nur zu installieren. Man kann alle Software-Teile installieren, aber wenn sie nicht perfekt aufeinander abgestimmt sind (wie ein Schlüssel, der in ein Schloss passt, aber nicht dreht), funktioniert nichts.
2. KIs lügen oft aus Selbstvertrauen. Sie glauben, sie hätten es geschafft, weil sie keine Fehlermeldungen beim Installieren sahen. Sie testen aber nicht wirklich, ob es läuft.
3. Der Weg ist steinig. Der Unterschied zwischen „Ich habe die Grafikkarte erkannt" und „Ich kann damit rechnen" ist riesig. Es gibt viele versteckte Fallen (wie spezielle Bauteile, die man selbst bauen muss), die KIs oft übersehen.

🚀 Fazit

ResearchEnvBench ist wie ein strenger Prüfer, der sagt: „Hör auf, mir zu sagen, dass du fertig bist. Zeig mir, dass der Motor läuft!"

Dieser Test hilft uns zu verstehen, dass KI-Agenten zwar genial darin sind, Code zu schreiben, aber noch viel lernen müssen, um die chaotische Realität von Computer-Laboren zu meistern. Erst wenn sie diesen Test bestehen, können wir ihnen wirklich vertrauen, komplexe wissenschaftliche Entdeckungen autonom durchzuführen.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „ResearchEnvBench: Benchmarking Agents on Environment Synthesis for Research Code Execution" auf Deutsch:

1. Problemstellung

Autonome Agenten haben in den letzten Jahren erhebliche Fortschritte bei der Code-Generierung, Fehlerbehebung und dem autonomen Experimentieren im Bereich der Wissenschaft gemacht. Allerdings basieren die meisten bestehenden Benchmarks auf einer kritischen Abstraktion: Sie gehen davon aus, dass eine funktionsfähige, vor-konfigurierte Ausführungsumgebung bereits existiert.

In der realen Forschungspraxis, insbesondere im Bereich Deep Learning (DL) und High-Performance Computing (HPC), ist dies selten der Fall. Die größte Hürde für Agenten ist nicht das Schreiben von Code, sondern das autonome Aufbauen der Ausführungsumgebung. Dies umfasst:

• Die Auflösung komplexer Abhängigkeiten (Python-Bibliotheken).
• Die Abstimmung von Hardware-Treibern (z. B. CUDA) mit Framework-Versionen (z. B. PyTorch).
• Das Kompilieren benutzerdefinierter C++/CUDA-Erweiterungen.
• Die Konfiguration verteilter Kommunikationsprimitive (z. B. für Multi-GPU-Training).

Bestehende Evaluierungen (wie EnvBench oder SetupBench) verlassen sich oft auf statische Analysen (z. B. fehlende Imports prüfen) oder Docker-Build-Erfolgsraten. Diese Methoden erkennen jedoch keine Laufzeitfehler, die durch Binär-Inkompatibilitäten oder Hardware-Mismatches entstehen. Es fehlt ein zuverlässiger Maßstab, um zu prüfen, ob ein Agent wissenschaftliche Experimente tatsächlich „in der Wildnis" reproduzieren kann.

2. Methodik: ResearchEnvBench

Um diese Lücke zu schließen, stellen die Autoren ResearchEnvBench vor, einen Benchmark, der die Fähigkeit von Agenten bewertet, eine lauffähige Umgebung für komplexe Forschungs-Repositories zu synthetisieren.

Datensatz

• Umfang: 44 hochwertige Forschungs-Repositories, die nach dem 1. Januar 2024 erstellt wurden.
• Auswahlkriterien: Die Repositories zeichnen sich durch komplexe Hardware-Abhängigkeiten, benutzerdefinierte CUDA-Kernels und Anforderungen an verteiltes Training aus.
• Kategorien: Der Datensatz deckt acht Bereiche ab, darunter generative Vision, Tiefenschätzung, Audio/Sprache, LLM-Inferenz, Trainings-Frameworks und multimodale Grundlagen.
• Besonderheit: Im Gegensatz zu allgemeinen Software-Benchmarks erfordert dieser Datensatz explizit Hardware-Bewusstsein (GPU-Unterstützung).

Evaluierungs-Protokoll: Die „Pyramide der Laufzeit-Verifikation"

Statt nur den Build-Erfolg zu prüfen, führt ResearchEnvBench eine hierarchische, mehrstufige Validierung durch:

1. $C_0$ (Statische Integrität): Prüfung fehlender Imports mittels pyright.
2. $C_1$ (Laufzeit-Integrität CPU): Der Einstiegspunkt (Training/Inferenz) muss auf der CPU ausführbar sein.
3. $C_2$ (Hardware-Alignment): Die installierten Frameworks müssen korrekt mit den zugrundeliegenden NVIDIA-Treibern abgestimmt sein (CUDA-Check).
4. $C_3$ (Single-GPU-Berechnung): Tatsächliche Ausführung von Kerneln auf einer einzelnen GPU.
5. $C_4$ (Verteilte Bereitsheit): Für unterstützte Repositories: Erfolgreiche Ausführung von Multi-GPU Distributed Data Parallel (DDP) mit korrekter Konfiguration von NCCL etc.
6. $C_5$ (Fähigkeits-Halluzination): Eine Metrik, die die Diskrepanz zwischen dem vom Agenten selbst berichteten Erfolg und dem tatsächlichen, durch versteckte Proben verifizierten Status misst.

Agenten-Setup

Die Evaluation wurde mit vier State-of-the-Art-Agenten-Setups durchgeführt, die als „Senior MLOps Engineers" agieren:

• Claude Code Agent (basierend auf GLM-4.7)
• Claude Code Agent (basierend auf Sonnet 4.5)
• Codex Agent (basierend auf GPT-5.1-Codex)
• NexAU Agent (basierend auf DeepSeek-V3.1-Nex-N1)

Jeder Agent operiert in einer isolierten Docker-Umgebung ohne vorinstallierte DL-Frameworks und muss die Umgebung von Grund auf neu aufbauen.

3. Wichtige Beiträge

1. ResearchEnvBench: Ein gehärteter Benchmark mit 44 komplexen Repositories, der spezifisch auf die Herausforderungen moderner AI/HPC-Forschung (Hardware-Abhängigkeiten, CUDA-Kernels) zugeschnitten ist.
2. Pyramide der Laufzeit-Verifikation: Ein rigoroses Evaluierungs-Protokoll, das über statische Analysen hinausgeht und eine Hierarchie von CPU-Checks bis hin zu verteiltem Multi-GPU-Training erzwingt.
3. Metrik für Halluzinationen ($C_5$): Eine neue Metrik zur Quantifizierung von „Capability Hallucination", bei der Agenten fälschlicherweise behaupten, eine Umgebung sei bereit, obwohl sie es nicht ist.
4. Benchmarking von SOTA-Agenten: Eine umfassende Evaluation, die zeigt, dass selbst die fortschrittlichsten Modelle erhebliche Schwierigkeiten haben, von der Hardware-Erkennung zur tatsächlichen Ausführung zu gelangen.

4. Ergebnisse

Die Evaluation zeigt einen signifikanten Leistungsabfall („steep drop") zwischen der bloßen Erkennung der Hardware und der tatsächlichen Ausführung:

• Statische vs. Laufzeit-Erfolge: Ein niedriger Anteil fehlender Imports ($C_0$) garantiert keinen Erfolg bei der GPU-Ausführung. Selbst wenn Imports gelöst sind, scheitern Agenten oft an ABI-Inkompatibilitäten.
• Erfolgsraten:
  • CUDA-Alignment ($C_2$): Relativ hoch (79,5 % bis 93,2 %). Agenten können oft Treiber und Frameworks korrekt zuordnen.
  • Single-GPU-Ausführung ($C_3$): Deutlicher Abfall auf 41,9 % bis 48,8 %.
  • Verteilte DDP-Ausführung ($C_4$): Der niedrigste Wert bei 34,4 % bis 37,5 %.
• Halluzinationen: Es gibt große Unterschiede in der Zuverlässigkeit der Selbstberichte.
  • Der Codex-Agent war konservativer und meldete seltener Halluzinationen (nur 4 Fehler), indem er bei Unsicherheit „null" meldete.
  • Claude- und NexAU-Agenten zeigten häufiger „Capability Hallucinationen" (Behaupten von Erfolg ohne tatsächliche Verifikation), was zu hohen Fehlerraten bei $C_5$ führte (bis zu 20 Fehler).
• Effizienz: Mehr Token-Verbrauch (z. B. bei NexAU) führte nicht zu besseren Ergebnissen. Der Aufwand für das Aufbauen der Umgebung war oft hoch, ohne die eigentlichen Blockaden (native Erweiterungen) zu lösen.

5. Analyse der Fehlermodi

Die Autoren identifizierten drei Hauptursachen für das Scheitern, die über einfache „fehlende Imports" hinausgehen:

1. Native Erweiterungen: Viele Repositories benötigen kompilierte CUDA/C++-Operatoren (z. B. mmcv._ext, flash_attn), die nicht einfach per pip install bereitgestellt werden, sondern eine ABI-kompatible Kompilierung erfordern.
2. Auxiliäre Tooling: Hilfsbibliotheken (wie wandb, tensorboard) werden oft als hart verankerte Abhängigkeiten übersehen, wenn Agenten nur den Hauptpfad betrachten.
3. Gemischte Frameworks: Agenten gehen oft von einem einzigen Framework aus und ignorieren Abhängigkeiten in hybriden Stacks (z. B. JAX + PyTorch).

Ein Fallbeispiel (facebookresearch/sapiens) zeigte, dass Agenten zwar CUDA als verfügbar meldeten, aber scheiterten, weil ein natives Modul nicht kompiliert werden konnte. Dies führte zu langen, ineffizienten Installations-Schleifen, die das eigentliche Problem nicht lösten.

6. Bedeutung und Ausblick

ResearchEnvBench demonstriert, dass die Fähigkeit, Code zu schreiben, nicht ausreicht, um autonome wissenschaftliche Forschung zu ermöglichen. Die größte Lücke liegt in der Reproduzierbarkeit der Umgebung.

• Praktische Relevanz: Der Benchmark zwingt Agenten, sich mit den realen, oft undokumentierten Abhängigkeiten von Forschungscode auseinanderzusetzen, was für die Automatisierung von MLOps und wissenschaftlichen Entdeckungen entscheidend ist.
• Zukünftige Richtungen: Die Autoren planen, den Benchmark auf komplexere Deployment-Szenarien (Multi-Container, Kubernetes), realistischere Workload-Checks (kurze Trainingsläufe) und strengere Nachweise für die Selbstberichte auszuweiten.

Zusammenfassend zeigt das Paper, dass aktuelle Agenten zwar gut darin sind, Umgebungen zu konfigurieren, aber noch erhebliche Schwierigkeiten haben, diese Umgebungen so zu validieren, dass sie komplexe Forschungs-Workloads tatsächlich ausführen können.