AIDE ML: Baum­suche über Python-Skripte statt YAML-Grid

Das Problem: Metrik vorgeben, Pipeline bauen lassen

Die README beschreibt den Ablauf in einem Satz: Das Agent bekommt ein Datenverzeichnis, ein Ziel in natürlicher Sprache und eine Evaluationsmetrik, und arbeitet dann selbstständig daran, diese Metrik zu maximieren oder zu minimieren. Das ersetzt die übliche Kette aus Feature-Engineering, Modellwahl und Hyperparametersuche durch eine Schleife, in der ein LLM jeweils den nächsten Codeentwurf liefert. Die Zielgruppe benennt das Repo selbst: Agent-Architektur-Forschende, die Suchheuristiken, Evaluatoren oder LLM-Backends austauschen wollen, und ML-Praktiker, die aus einem Datensatz schnell eine Pipeline bauen möchten. Der Aufruf in der README zeigt die Schnittstelle: aide data_dir=… goal="Predict churn" eval="AUROC". Kein YAML-Raster, keine Wrapper-Klassen. Wer schon einmal Hyperparameter-Sweeps über Konfigurationsdateien organisiert hat, erkennt den Unterschied sofort: Die Suchdimension ist hier nicht ein Zahlenraum, sondern der Raum möglicher Python-Programme.

Jedes Skript ein Knoten: wie die Baumsuche läuft

Der Mechanismus ist im Repo als agentic tree search bezeichnet. Jedes erzeugte Python-Skript wird zu einem Knoten in einem Lösungsbaum. Das LLM erzeugt Patches, die Kindknoten erzeugen, und die Metrik-Rückmeldung beschneidet den Baum und lenkt die weitere Suche. Die README nennt dafür den Parameter agent.search.num_drafts mit dem Standardwert 5, also fünf Entwürfe pro Schritt, und agent.steps mit dem Standardwert 20 für die Anzahl der Verbesserungsiterationen. Das ist der wesentliche Unterschied zu einem linearen Agenten: Ein linearer Agent verbessert eine einzelne Kette von Entwürfen, während hier mehrere Zweige parallel existieren und schlechte Zweige verworfen werden. Die README verweist für die Details auf das Paper arXiv:2502.13138 und führt als externen Beleg an, dass OpenAIs MLE-Bench mit 75 Kaggle-Wettbewerben festgestellt habe, die Baumsuche von AIDE gewinne viermal mehr Medaillen als der beste lineare Agent (OpenHands). Diese Zahl stammt aus der zitierten Fremdauswertung, nicht aus eigenen Messungen des Repos, und sollte als solches gelesen werden.

Installation und der erste Lauf mit drei Argumenten

Der Einstieg ist kurz. pip install -U aideml, dann ein API-Schlüssel über die Umgebungsvariable OPENAI_API_KEY, danach der Aufruf aide data_dir="example_tasks/house_prices" goal="Predict the sales price for each house" eval="RMSE between log-prices". Nach dem Lauf liegen zwei Artefakte im Verzeichnis logs/<id>/: best_solution.py mit dem besten gefundenen Code und tree_plot.html, eine HTML-Visualisierung, mit der sich der gesamte Lösungsbaum samt angehängtem Code inspizieren lässt. Die Metrik wird als Freitext übergeben, im Beispiel als "RMSE between log-prices". Das ist bequem, verschiebt aber die Verantwortung für die korrekte Implementierung der Metrik in den generierten Code. Wer eine Metrik braucht, die sich nicht in einem Satz beschreiben lässt, sollte prüfen, ob der Agent sie konsistent umsetzt.

Modellwahl, Schrittzahl und der Python-Einstieg

Das Coding-Modell ist austauschbar. Die README zeigt aide agent.code.model="claude-4-sonnet" agent.steps=50 data_dir=… goal=… eval=… als Beispiel für einen längeren Lauf mit anderem Backend. Der Standardwert für agent.code.model ist gpt-4-turbo. Als modellneutral wird die Anbindung insofern beschrieben, als neben OpenAI, Anthropic und Gemini auch jedes lokale LLM genutzt werden kann, das die OpenAI-API spricht. Für Skripte gibt es einen Python-Einstieg: aide.Experiment(data_dir=…, goal=…, eval=…) mit anschließendem exp.run(steps=2). Der Rückgabewert best_solution trägt die Attribute valid_metric und code, sodass sich Metrik und Quelltext direkt weiterverarbeiten lassen. Wer das in eine eigene Pipeline einbetten will, muss beachten, dass die Experiment-Klasse ein Datenverzeichnis erwartet, also eine vorbereitete Struktur auf der Platte, nicht ein DataFrame im Speicher.

Die Streamlit-Oberfläche und was sie voraussetzt

Neben der CLI gibt es eine Weboberfläche, die allerdings einen lokalen Klon verlangt. Die README nennt die Schritte: git clone https://github.com/WecoAI/aideml.git, cd aideml, pip install -e . (die Installation ergänzt streamlit), dann cd aide/webui und streamlit run app.py. In der Seitenleiste werden API-Schlüssel, Daten, Goal und Metrik gesetzt, danach startet der Lauf über Run AIDE. Die Oberfläche zeigt Live-Logs, den Lösungsbaum und den besten Code. Der Unterschied zur CLI ist damit vor allem die Rückmeldung während des Laufs: Bei 20 Schritten und fünf Entwürfen pro Schritt entstehen viele Zwischenstände, und die HTML- beziehungsweise Streamlit-Ansicht ist der vorgesehene Weg, diese zu sichten. Ein Paketinstallationsweg für die UI allein wird in der README nicht genannt; sie hängt am geklonten Repository.

Wo das Werkzeug an seine Grenzen stößt

Die README positioniert das Repo ausdrücklich als research-friendly Referenzbau für Experimente und Erweiterungen, nicht als Produktionsplattform. Der entsprechende Hinweis steht direkt im Kopf: Wer AIDE in Produktion nutzen wolle, solle den verlinkten Weco-Dienst prüfen, der die Fähigkeiten auf breitere Code-Optimierungsszenarien verallgemeinert und Experiment-Tracking sowie erweiterte Nutzerkontrolle bietet. Daraus folgt die erste Einschränkung: Dieses Repo bringt kein Tracking über Läufe hinweg mit, nur das Log-Verzeichnis pro Lauf. Zweitens kostet jeder Lauf Modellaufrufe; bei agent.steps=20 und agent.search.num_drafts=5 sind es viele Entwürfe, und die README nennt kein Kostenmodell. Drittens ist die Suche auf Code beschränkt, der ausgeführt werden kann. Aufgaben, deren Ergebnis sich nicht als Metrik aus einem Skript berechnen lässt, etwa Datenqualität, Latenz im Zielsystem oder regulatorische Anforderungen, lassen sich mit goal und eval nicht sinnvoll abbilden. Und wer reproduzierbare Ergebnisse über Läufe hinweg braucht, findet in der README keinen Hinweis auf Seed-Steuerung; ob und wie die Suche deterministisch gemacht werden kann, lässt sich aus dem Material nicht belegen.

Der Vergleich: AIDE ML gegen einen linearen Agenten

Die naheliegende Alternative ist ein linearer Agent, wie ihn die zitierte MLE-Bench-Auswertung mit OpenHands vergleicht. Der Unterschied liegt im Suchraum: Ein linearer Agent erzeugt eine Kette von Verbesserungen auf einem einzigen Entwurf und kann nicht zu einem früheren, vielversprechenderen Ansatz zurückkehren, wenn ein späterer Schritt die Metrik verschlechtert. AIDE ML hält stattdessen mehrere Zweige gleichzeitig und nutzt die Metrik-Rückmeldung zum Beschneiden. Das kostet mehr Modellaufrufe pro Verbesserungsschritt, weil mehrere Entwürfe parallel erzeugt und bewertet werden. Die README führt für diesen Ansatz die genannte MLE-Bench-Zahl an, nach der die Baumsuche viermal mehr Medaillen gewinnt als der beste lineare Agent. Wer eine einzelne, klar umrissene Codeänderung sucht, ist mit einem linearen Ansatz besser bedient; die Baumsuche zahlt sich dort aus, wo der Lösungsraum offen ist und mehrere Architekturen konkurrieren.

Wartung, Lizenz und was vor dem Einsatz zu klären ist

Das Paket steht unter MIT-Lizenz, was die Einbettung in eigene Projekte und Modifikationen erlaubt. Rechtlich verbindlich ist der Lizenztext selbst; aus der Lizenzkennung allein lassen sich keine Aussagen über Haftung oder Patentfragen ableiten. Die Versionshistorie zeigt: v0.1.4 im April 2024, v0.2.0 im Januar 2025, v0.2.2 im November 2025. Der letzte Push ins Repository datiert auf September 2026, das Projekt ist nicht archiviert. Aus diesen Daten lässt sich keine Aussage über die Häufigkeit künftiger Releases ableiten. Wer das Paket produktiv einbettet, sollte die Upgrades zwischen Minor-Versionen selbst prüfen, weil die CLI-Flags und die Experiment-Schnittstelle Teil der öffentlichen Oberfläche sind und sich zwischen v0.1.4 und v0.2.0 geändert haben können. Konkret zu verifizieren sind vor dem ersten Lauf drei Dinge: ob das gewählte agent.code.model mit dem eigenen API-Zugang funktioniert, ob die Metrik aus eval im generierten best_solution.py so implementiert wird, wie sie gemeint war, und ob der Lauf auf dem eigenen Datensatz ohne manuelle Nacharbeit reproduzierbar ist. Wer diese drei Punkte nicht prüfen kann oder will, sollte den Lauf nicht als Entscheidungsgrundlage verwenden.

Redaktionelles Fazit

Wer die AIDE-Methode reproduzieren, eigene Suchheuristiken oder Evaluatoren einhängen oder einen lokalen LLM-Backend testen will, findet in aideml den passenden Ausgangspunkt: pip install -U aideml, dann ein Lauf mit data_dir, goal und eval. Wer ein betreutes Produkt mit Experiment-Tracking und Nutzerkontrolle braucht, sollte nicht dieses Repo adoptieren, sondern den in der README verlinkten Weco-Dienst prüfen. Vor dem ersten echten Lauf zu klären: welche Modellkennung agent.code.model akzeptiert, wie viele Schritte agent.steps und wie viele Entwürfe agent.search.num_drafts pro Schritt das Budget tragen, und ob logs/<id>/best_solution.py auf dem eigenen Datensatz ohne manuelle Nacharbeit reproduzierbar ist.

Offizielle Quellen

1. License: MIT
2. Project website
3. README
4. Releases
5. WecoAI/aideml on GitHub