SELA: Tree-Search Enhanced LLM Agents for Automated Machine Learning

## Abstract

Abstract Automated Machine Learning (AutoML) approaches encompass traditional methods that optimize fixed pipelines for model selection and ensembling, as well as newer LLM-based frameworks that autonomously build pipelines. While LLM-based agents have shown promise in automating machine learning tasks, they often generate low-diversity and suboptimal code, even after multiple iterations. To overcome these limitations, we introduce Tree- S earch E nhanced L LM A gents ( \methodname ), an innovative agent-based system that leverages Monte Carlo Tree Search (MCTS) to optimize the AutoML process. By representing pipeline configurations as trees, our framework enables agents to conduct experiments intelligently and iteratively refine their strategies, facilitating a more effective exploration of the machine learning solution space.
This novel approach allows \methodname to discover optimal pathways based on experimental feedback, improving the overall quality of the solutions. In an extensive evaluation across 20 machine learning datasets, we compare the performance of traditional and agent-based AutoML methods, demonstrating that \methodname achieves a win rate of 65% to 80% against each baseline across all datasets. These results underscore the significant potential of agent-based strategies in AutoML, offering a fresh perspective on tackling complex machine learning challenges 1 1 1 The code is available at https://github.com/geekan/MetaGPT .

## 1 Introduction

Automated Machine Learning (AutoML) is a rapidly evolving field that seeks to automate the process of designing reliable machine learning solutions with minimal human intervention. Traditional AutoML frameworks, such as Auto-WEKA (Thornton et al., ), Auto-Sklearn (Feurer et al., ; ), AutoGluon (Tang et al., ), and H2O AutoML (LeDell & Poirier, ), rely on predefined search spaces and routines. These frameworks primarily focus on optimizing hyperparameters and model ensembling to find the best model configuration. However, this fixed and static approach often lacks the adaptability needed to handle diverse and dynamic data scenarios, resulting in suboptimal performance in more complex settings. Additionally, the traditional focus on model training leaves other crucial stages of the machine learning pipeline, such as data preprocessing and feature engineering, underexplored, thereby limiting the overall effectiveness of these systems.

Recently, large language model (LLM)-based agents have emerged as promising tools for automating machine learning tasks by leveraging natural language processing capabilities to generate code. These systems typically begin with a natural language prompt describing the dataset and the problem, after which an LLM generates an end-to-end solution. Early efforts, such as Zhang et al. (), experimented with prompting LLMs to generate machine learning solutions, while Hong et al. () introduced agents equipped with Hierarchical Graph Modeling and Programmable Node Generation to address complex and dynamic workflows. Despite these advances, LLM-based solutions often fall short in generating diverse and highly optimized workflows, as their search process remains limited to a single pass or trial. Without iterative refinement or the ability to explore alternative strategies, these solutions frequently converge on suboptimal results, even when multiple attempts are allowed.

A critical shortcoming of both traditional AutoML and LLM-based frameworks lies in their inability to mimic the nuanced problem-solving approach of human experts. When approaching a machine learning task, an expert does not simply execute a fixed pipeline or rely on a single attempt. Instead, they explore various potential configurations, systematically conduct experiments, analyze results, and iteratively refine their understanding of each component’s effectiveness. This iterative, feedback-driven process allows experts to explore diverse solutions and improve them incrementally until they arrive at the optimal configuration.

Figure: Figure 1: \methodname’s abstraction compared to other agent-based AutoML frameworks. There are two main types of agent-based approaches to AutoML problems. The first approach (Hong et al., ) divides a machine learning task into multiple stages, proposing a plan for each stage, and generating and executing code step by step according to the plan, with no refinement after the solution is completed. The second (Schmidt et al., ) generates the entire solution in one step and iteratively refines it as a whole. \methodname integrates both approaches, enabling stage-wise planning while iteratively exploring better solutions at each stage level.
Refer to caption: x1.png

Inspired by this human-centered approach, we propose Tree-Search Enhanced LLM Agents (\methodname) for automated machine learning, a novel framework that integrates the strengths of LLM agents with a structured search and refinement process modeled on how experts solve machine learning problems. As illustrated in Figure 1, our framework combines the benefits of stage-wise planning, where each stage (e.g., Exploratory Data Analysis, Data Preprocessing, Feature Engineering, and Model Training) is handled sequentially, with an iterative refinement mechanism.

In \methodname, the search space of a machine learning problem is proposed and conceptualized as a tree, where each branch represents a potential solution path. To navigate this search space, we employ Monte Carlo Tree Search (MCTS) (Coulom, ) as the core decision-making engine, leveraging its ability to balance exploration (testing new strategies) and exploitation (improving known good strategies). MCTS allows the agent to efficiently explore large decision spaces, collect and process experimental results, and intelligently select the next promising configuration to test on. By iterating through this cycle of experimentation and refinement, \methodname incrementally improves its solutions, much like an expert who tests and improves its strategy based on continuous feedback.

We rigorously evaluated \methodname using 20 diverse datasets from the AutoML Benchmark (Gijsbers et al., ), comparing its performance against both traditional AutoML systems and agent-based AutoML approaches. The results demonstrate that \methodname consistently delivers superior performance across a wide range of machine learning tasks, validating its effectiveness and adaptability.

To summarize, our research makes the following contributions:

- 1.
We introduce a feedback-driven approach for LLM agents to iteratively explore machine learning configurations, optimizing solutions over multiple experimental rounds.
- 2.
Using Monte Carlo Tree Search, our system navigates a tree-structured search space, adaptively identifying high-performance pipelines through feedback.
- 3.
We compare agent-based and traditional AutoML, highlighting agentic methods’ flexibility and potential for enhanced performance in machine learning.

**Table 1: Comparison of key capabilities across various AutoML methods. Dynamic indicates the system’s ability to adjust workflows based on intermediate outcomes, allowing it to adapt as new information emerges. Diverse refers to employing multiple strategies or methods across tasks, which helps capture varied modeling needs. Instinctive means that the system directly relies on the decisions generated by an LLM and heavily depends on the model’s inclination.**
|  | Dynamic<br>Pipeline | Feature<br>Engineering | Model<br>Training | Model<br>Improvement | Pipeline<br>Optimization |
| --- | --- | --- | --- | --- | --- |
| AutoGluon (Erickson et al., ) | ✗ | ✗ | Fixed models | Multi-layer stacking + bagging | ✗ |
| AutoSklearn (Feurer et al., ) | ✗ | ✗ | Fixed models | Bayes Opt. + meta-learning + ensemble | ✗ |
| Data Interpreter (Hong et al., ) | ✓ | Instinctive | Instinctive | Instinctive | ✗ |
| AIDE (Schmidt et al., ) | ✓ | Instinctive | Dynamic & diverse | Dynamic & diverse | One-step refinement + LLM |
| \methodname (Ours) | ✓ | Dynamic & diverse | Dynamic & diverse | Dynamic & diverse | Stepwise MCTS + LLM |

## 2 Related Works

Tree Search and Its Integration with LLMs
Tree search algorithms have significantly advanced problem-solving in artificial intelligence, with Monte Carlo Tree Search (MCTS) emerging as a leading technique. These algorithms have been successfully applied across various domains, including robotics (Wu et al., ; Clary et al., ; Best et al., ), chemistry (Segler et al., ), and gaming (Silver et al., ; ), where MCTS is used to navigate vast solution spaces and solve complex problems. More recently, research has focused on integrating tree search with Large Language Models (LLMs) to enhance reasoning and decision-making. Studies such as Krishnamurthy et al. () and Dwaracherla et al. () explored LLMs’ capacities for efficient exploration, while Tang et al. () and Hui & Tu () developed strategies for exploiting previously learned knowledge. Zhou et al. () and Chi et al. () applied MCTS for planning with external or self-evaluated feedback, while Feng et al. (); Wang et al. () adapted AlphaZero-style tree search to LLM-based tasks. These advancements underscore the potential of combining tree search methods with LLMs, balancing exploration of new solutions with exploitation of prior knowledge to enhance decision-making.

Advances and Limitations in AutoML Systems
Automated Machine Learning (AutoML) frameworks were introduced to reduce the need for expert knowledge in designing machine learning pipelines. Early AutoML efforts, such as (Thornton et al., ; Olson & Moore, ; Jin et al., ; Feurer et al., ; Erickson et al., ; LeDell & Poirier, ; Wang et al., ), focused primarily on automating key pipeline components like hyperparameter optimization, model selection, stacking, and ensembling. These frameworks achieved notable progress by integrating meta-learning and hyperparameter search strategies to automatically select and tune machine learning models. Furthermore, extensions into multi-modal data settings (Tang et al., ; Jin et al., ) have broadened AutoML’s applicability.

Recently, there has been growing interest in leveraging LLMs within AutoML systems to enhance pipeline flexibility. Studies such as Hollmann et al. (); Li et al. () applied LLMs to automate feature engineering, while Liu et al. () introduced LLMs for hyperparameter tuning. In addition, Luo et al. () proposed embedding LLMs at each stage of the machine learning workflow. Despite these advancements, traditional AutoML systems remain constrained by rigid pipelines and limited flexibility to adapt to unique datasets or specific task requirements.

LLM Agents for Dynamic Machine Learning Pipelines
In contrast to static pipelines, LLM-based agents offer a more dynamic solution for addressing complex machine learning challenges. Hong et al. (; ) introduced an LLM agent with hierarchical graph modeling and programmable node generation, enabling the creation of sophisticated, adaptable pipelines for diverse data scenarios. Similarly, Zhang et al. () demonstrated that LLMs could effectively interpret structured inputs and apply past experiences to solve new machine learning tasks. Guo et al. () expanded on this by introducing a data science agent that leverages case-based reasoning; however, it faces challenges when generating solutions from scratch due to its reliance on existing codebases. Schmidt et al. () proposed an iterative approach, where the entire pipeline is generated in one step and refined iteratively through incremental modifications.

Building on these efforts, \methodname introduces an agent that integrates the strengths of both approaches—stage-wise planning and iterative refinement—allowing it to autonomously explore and generate machine learning solutions from the ground up. This approach offers greater flexibility and control during the search process, enabling the generation of optimized solutions at each stage. Table 1 highlights the functionalities provided by different AutoML systems.

## 3 Method

As illustrated in Figure 2, \methodname consists of three key components: an LLM-based insight proposer, a search module using MCTS, and an LLM agent as the experiment executor. First, the LLM generates insights from the problem description and dataset, defining a search space. The search module then organizes this space into a tree structure and uses MCTS to explore promising paths. During each cycle, the selected path is passed to the LLM agent, which translates the configuration into an executable pipeline. The agent plans, codes, and executes the experiment, feeding the results back to refine future searches. This iterative process continues until the termination criterion is met. The following sections provide a detailed explanation of each component.

Figure: Figure 2: \methodname’s pipeline operates as follows: The system begins by inputting the problem description and dataset information into the LLM, which generates a search space of potential solutions, encompassing data preprocessing, feature engineering, and model training. The search module, powered by Monte Carlo Tree Search (MCTS), explores this space by selecting, expanding, and simulating potential configurations. The LLM agent then simulates the selected configuration by planning, coding, and executing the experiment. Feedback from the simulation is fed back into the search module, where it is used in the backpropagation step to refine future searches. This iterative process continues until a predefined stopping criterion is met, resulting in an optimized experimental pipeline.
Refer to caption: x2.png

### 3.1 Insight Proposal and Search Space Creation

To enable \methodname to explore a wide range of machine learning strategies, we introduce an insight proposer that generates diverse methods tailored to different stages of the machine learning workflow. Each proposed insight suggests either a single technique or a combination of methods aimed at enhancing performance. For instance, a feature engineering insight might recommend creating interaction features from existing variables, while a model training insight could propose a specific algorithm or suggest running a grid search to improve accuracy.

The insight proposer takes as input the problem description $p$ and dataset information $d$, such as metadata and sample records, and generates $m$ insights $\lambda$ for each stage of the machine learning process using a large language model $M$. These insights are stored in an insight pool, forming a search space $\Lambda$ for \methodname to explore. We decompose the machine learning process into five stages: Exploratory Data Analysis ($\tau_{1}$), Data Preprocessing ($\tau_{2}$), Feature Engineering ($\tau_{3}$), Model Training ($\tau_{4}$), and Model Evaluation ($\tau_{5}$). For simplicity, we denote the entire set of stages as $T$ and refer to any specific stage as $\tau$.

$$ $\displaystyle\text{InsightProposer}(p,d,M)\rightarrow\Lambda:=\{\lambda_{i}^{ \tau}\mid\tau\in T,i=1,\dots,m\}$ (1) $$

### 3.2 Pipeline Execution and Code Generation

We employ an LLM agent, referred to as the experiment executor $E$, to conduct each trial by building practical experimental pipelines from natural language requirements. The agent takes two main steps in this process. First, given an experiment configuration $c$, which is a set of insights provided by the search module (introduced in Section 3.3.2), the experiment executor translates these insights into a detailed plan. This plan consists of a sequence of task instructions $I^{\tau\in T}$ corresponding to each stage of the machine learning process. This step is referred to as $E_{\text{plan}}$.

Next, following the plan, the agent writes and executes code $\sigma^{\tau}$ for each task $\tau$ based on the respective instruction $I^{\tau}$, producing the code $\sigma^{\tau\in T}$ for the full pipeline, along with the final execution score $s$. The complete set of code outputs $\sigma^{\tau\in T}$ is concatenated into a full solution $\sigma_{sol}$ to address the problem. This phase is referred to as $E_{\text{code \& execute}}$.

$$ $\displaystyle E_{\text{plan}}(p,d,c,M)$ $\displaystyle\rightarrow I^{\tau\in T}$ (2) $\displaystyle E_{\text{code \& execute}}(I^{\tau\in T},D,M)$ $\displaystyle\rightarrow(\sigma^{\tau\in T},s)$ (3) $$

### 3.3 Tree Search in Machine Learning Experiments

In order to systematically explore the different configurations in machine learning experiments, we model the search space as a hierarchical tree. This structure allows us to apply tree search algorithms, where each path through the tree represents a different experiment configuration. Algorithm 1 also provides an overview of this searching process.

#### 3.3.1 Experiment Node

To facilitate the exploration of various strategies, we model the proposed search space as a hierarchical tree that is well-suited for applying search algorithms. Each node in the tree, denoted as $x$, represents one insight $\lambda$ in the search space $\Lambda$ and contains the following attributes:

- •
Insight $\lambda(x)$: Represents the specific insight $\lambda_{i}^{\tau}\in\Lambda$ associated with this node, where $\tau$ denotes the stage of the machine learning pipeline.
- •
Depth $\delta(x)$: Indicates the stage of the machine learning process the node corresponds to (e.g., depth 1 might represent data preprocessing, depth 2 for feature engineering, and depth 3 for model training).
- •
Value $v(x)$: The cumulative score from simulations for this node and all its descendants.
- •
Number of Visits $n_{\text{visits}}(x)$: The total number of simulations conducted for this node and its descendants.
- •
Simulation Score $s(x)$: The score for simulating this node.
- •
Solution Code $\sigma_{\text{sol}}(x)$ The final code produced after the node simulation.
- •
Stage Code $\sigma_{\text{stage}}(x)$: The code generated up to the node’s current stage, a part of the solution code

By modeling the search space as a tree, each path from the root to a node $x$ represents an experiment configuration $c(x)=\{\lambda(x_{1}),\lambda(x_{2}),\dots,\lambda(x)\}\subset\Lambda$, where $x_{1},x_{2},\dots,x$ are nodes along the path. The task of finding the optimal solution can therefore be viewed as a path search within the tree, where each path corresponds to a potential configuration of the experiment.

#### 3.3.2 Tree Search for ML Experiments

We apply Monte Carlo Tree Search (MCTS) to systematically explore and identify optimal machine learning solutions within our framework. MCTS allows us to efficiently navigate the search space across multiple stages of the machine learning pipeline—from data preprocessing to model selection—by balancing exploration and exploitation.

Figure: Algorithm 1 \methodname using MCTS

Figure: Algorithm 2 Simulate

The search process involves performing multiple rollouts, which include the steps of selection, expansion, simulation, and backpropagation. We conduct $k$ rollouts to explore various paths, aiming to identify the best solution.

Selection
At each iteration, we use a modified version of the UCT (Upper Confidence Bound for Trees) algorithm (Kocsis & Szepesvári, ), referred to as UCT-DP (depth-preferred), to select a node from the search tree. Unlike traditional MCTS, where simulations are often performed quickly due to a fixed action space and negligible action time, the context of machine learning tasks presents a different challenge. Processes such as model training introduce significant computational time, making efficient node exploration crucial. Since model selection can heavily influence the overall machine learning performance, we prioritize exploring nodes at greater depths early on.

This modification reduces the need to explore every unvisited node, allowing deeper nodes to be reached in fewer iterations—making the approach better suited for large-scale machine learning experiments. The modified selection algorithm is expressed as:

$$ $\displaystyle\text{UCT-DP}(x)=\frac{v(x)}{n(x)}+\alpha_{\text{explore}}\sqrt{ \frac{\ln n_{\text{visits}}(x_{\text{parent}})}{n(x)}}$ (4) $$

$$ $\displaystyle n(x)=\begin{cases}\alpha_{\text{unvisted}}&\text{if }n_{\text{ visits}}(x)=0\\ n_{\text{visits}}(x)&\text{otherwise.}\end{cases}$ (5) $$

Here, $\alpha_{\text{unvisted}}$ is a constant between 0 and 1 controlling the selection preference for unvisited nodes, balancing between full exploration and computational efficiency. This adjustment allows us to focus more on deeper parts of the tree that are likely to yield better solutions.

Expansion
During the expansion phase, a set of child nodes $X_{\text{child}}$ are instantiated from the selected node $x$ for potential simulation. Note that a child node $x_{\text{child}}$ from the node $x$ at depth $\delta$ inherits the attributes of $x$ and possesses $\lambda(x_{\text{child}})\rightarrow\lambda^{\tau_{\delta+1}}$, an insight of stage $\tau_{\delta+1}$ from the search space.

Simulation
Once expanded, a node $x_{\text{sample}}$ is randomly sampled from $X_{\text{child}}$ for simulation. The path from root to the sampled node forms a set of insights $c(x_{\text{sample}})=\{\lambda(x_{1}),\lambda(x_{2}),...,\lambda(x_{\text{
sample}})\}\subset\Lambda$, representing the experiment configuration to be simulated, where $x_{1},x_{2},..,x_{\text{sample}}$ are the nodes along the path. The configuration $c(x_{\text{sample}})$ is then fed to the experimenter $E$ for execution following $E_{\text{plan}}$ and $E_{\text{code \& execute}}$, which produces a simulation score $s$, as illustrated in Section 3.3.1. The score serves as the feedback for back propagation. Algorithm 2 outlines the simulation process.

Backpropagation
After the simulation concludes, the performance score (e.g., based on the development set) is retrieved and backpropagated through the tree. The score is propagated from the simulated node up to the root, updating each parent node’s value and visit count. This allows nodes representing more promising solutions to be prioritized in future rollouts. In addition, the solution code is also backpropagated up to the tree, and it can be processed and saved as stage code depending on the parent node during the update.

Backpropagation ensures that the algorithm learns which paths yield better results, guiding the search toward higher-performing nodes as more rollouts are conducted.

#### 3.3.3 Experiment State Saving and Loading

To boost experimentation efficiency and reduce token usage, \methodname implements fine-grained code reuse by caching code at the stage level for each attempted configuration $c$. This allows the framework to reuse as much saved code as possible when a new configuration $c_{\text{new}}$ shares components with existing ones. Additionally, this technique addresses the challenge of LLM non-determinism, where identical instructions can produce different code, increasing variance in final performance. Specifically, whenever a node is chosen for execution, the experimenter loads and reruns the saved stage code, if available, ensuring consistency before progressing to the next stage. This approach effectively conserves resources while maintaining robust performance across stages. In Appendix D, we examine the cost efficiency of this state-saving and loading mechanism.

## 4 Experiments

### 4.1 Experimental Setup

##### Datasets

We evaluate \methodname alongside several baselines on 20 datasets, which include 13 classification tasks and 7 regression tasks from the AutoML Benchmark (AMLB) (Gijsbers et al., ) and Kaggle Competitions.

Table 4 provides detailed information on the datasets used. All datasets are split into training, validation, and test sets with a 6:2:2 ratio. Each framework utilizes the training and validation sets to train models and makes predictions on the test set labels.

##### Evaluation Metrics

For the AMLB datasets, we use the default target column provided by OpenML. For Kaggle competition datasets, we rely on the target column specified in the competition description. Performance is measured using root mean squared error (RMSE) for regression tasks, F1 score for binary classification, and F1-weighted score for multi-class classification. To ensure comparability across datasets with varying metrics, we introduce a Normalized Score (NS), which maps RMSE into the range from 0 to 1.

$$ $\displaystyle\text{NS}(s_{\text{raw}})=\begin{cases}\frac{1}{1+\log{(1+s_{ \text{raw}})}}&\text{if the metric is RMSE.}\\ s_{\text{raw}}&\text{otherwise.}\end{cases}$ (6) $$

Here, $s_{raw}$ represents the raw score before normalization.
To evaluate \methodname against other frameworks, we employ three key metrics: average Normalized Score (NS), average rank, and average best rank. The average rank is calculated by considering all rankings of a method across datasets, while the average best rank focuses on the method’s best performance in each dataset.
We also want to quantify how other baselines perform relative to \methodname. The “Rescaled NS” is defined as:

$$ $\displaystyle\text{Rescaled NS}(f)=\frac{\text{NS}_{f}}{\text{NS}_{\methodname {}}}$ (7) $$

where $f$ represents the baseline method being compared to \methodname.

##### Method and Baselines Setup

We compare \methodname with several baseline methods, including Data Interpreter (Hong et al., ), AIDE (Schmidt et al., ), AutoGluon (Erickson et al., ), and AutoSklearn (Feurer et al., ; ).

For our LLM-based approaches (\methodname, Data Interpreter, and AIDE), we employ a consistent initial task prompt across all methods. This prompt encompasses the dataset name, target column, and evaluation metric. We choose DeepSeek v2.5 (DeepSeek-AI, ) as our foundation LLM due to its open-source nature, strong coding capabilities, and cost-effective token usage.
To encourage output diversity, we set the temperature parameter to 0.5 for all LLM-based methods. AIDE conducts 10 iterations per execution, while \methodname performs 10 rollouts.

For \methodname, we employ Data Interpreter as the experimenter, leveraging its multi-step generation capability. We configured the hyperparameters of UCT-DP as follows: $\alpha_{\text{unvisited}}$ is set to 0.8 and $\alpha_{\text{explore}}$ is set to 1.4. These settings aim to balance exploration and exploitation in the method’s search strategy.

Each method, except for AutoGluon, is run three times for each dataset. AutoGluon, being deterministic, is run only once with its default settings. AutoSklearn is also run with default settings, limited to 600 seconds per task.

**Table 2: Results of each AutoML framework on 20 tabular datasets. The “Wins” column indicates the number of datasets where the method outperforms \methodname, while “Losses” shows the number of datasets where the method underperforms. The “Top 1” column represents the number of datasets where the method produces the best predictions across methods.**
| Method | Wins | Losses | Top 1 | Avg. NS % $\uparrow$ | Avg. Best NS % $\uparrow$ | Avg. Rank $\downarrow$ | Avg. Best Rank $\downarrow$ |
| --- | --- | --- | --- | --- | --- | --- | --- |
| AutoGluon | 7 | 13 | 4 | 53.2 | 53.2 | 4.4 | 4.4 |
| AutoSklearn | 5 | 15 | 5 | 46.1 | 47.5 | 7.6 | 6.1 |
| AIDE | 5 | 15 | 2 | 47.1 | 51.8 | 7.8 | 5.3 |
| Data Interpreter | 4 | 16 | 2 | 47.4 | 50.2 | 8.8 | 6.4 |
| \methodname | - | - | 7 | 53.3 | 54.7 | 4.8 | 2.7 |

### 4.2 Results

Figure: Figure 3: Rescaled NS of AutoML frameworks relative to \methodname on tabular datasets. Points to the left of the vertical line indicate poorer predictions compared to \methodname. Notably, \methodname often occupies a leading position across the datasets.
Refer to caption: x3.png

As shown in Table 2, \methodname achieves the highest average Normalized Score (NS) and average best rank among all frameworks. Notably, \methodname excels in producing the highest number of top predictions, as indicated in the “Top 1” column across all datasets. Furthermore, the “Losses” column reveals that each competing method falls short against \methodname, losing in 65-80% of the datasets.

Interestingly, AutoGluon exhibits a marginally higher average rank than \methodname. This slight discrepancy may be attributed to the inherent randomness in LLMs and model training processes, which can influence the exploration of machine learning solutions. However, \methodname’s higher average NS suggests that it performs strongly in the datasets where it excels, while its losses in other datasets are relatively minor. This means that even when \methodname produces lower-ranked solutions, the performance gap is small, allowing it to fully compensate in the datasets where it performs well.

The two other agent-based methods exhibit relatively lower performance. The first method, Data Interpreter, struggles to enhance its score with multiple attempts due to its inability to refine its solution after completing a machine learning task. The second method, AIDE, does not have a stage-specific planning module, limiting its capacity to improve results after a series of greedy exploitation, which makes it prone to falling into local optima. These limitations likely account for their weaker performance.

Figure 3 further corroborates \methodname’s effectiveness, revealing that its best solutions frequently occupy leading positions across various datasets. This visual representation exhibits the method’s consistent high performance and adaptability across different ML datasets. We also include a detailed results of each method in Appendix C.

### 4.3 Ablation Study

For the rest of the study, we employ a subset of datasets to evaluate \methodname under various settings. Our selection process involves choosing the first two datasets alphabetically for each machine learning task. Specifically, we use boston, colleges, credit-g, Click_prediction_small, GesturePhaseSegmentationProcessed, and mfeat-factors to conduct the ablation study.

**Table 3: Performance results for each search setting on the chosen datasets. \methodname with MCTS consistently surpasses \methodname with Random Search.**
|  | Data Interpreter | \methodname (Random Search) | \methodname (MCTS) |
| --- | --- | --- | --- |
| Avg. NS $\uparrow$ | 56.4 | 58.6 | 60.9 |
| Avg. Best NS $\uparrow$ | 59.0 | 61.4 | 62.4 |
| Avg. Rank $\downarrow$ | 6.9 | 4.8 | 3.3 |
| Avg. Best Rank $\downarrow$ | 4.8 | 2.8 | 1.5 |

##### Effectiveness of Search

To evaluate the effectiveness of Monte Carlo Tree Search (MCTS) in improving the solution search process, we conducted an ablation study. In this study, we compared the performance of our method using MCTS against a variant that randomly samples insights from each stage’s insight pool.
As shown in Table 3, the MCTS version achieves a higher average normalized score across datasets and a better overall ranking compared to the random sampling approach. Moreover, even the random sampling variant of our method outperforms Data Interpreter, the base experimenter. This suggests the presence of an appropriate search space and an experiment agenda is vital for improving a machine learning agent. Our insight proposer generates relevant and useful insights, facilitating such improvement, regardless of the selection method.

##### Number of Rollouts

Figure 5 illustrates that the average performance of \methodname improves as the number of permitted rollouts increases. The trend demonstrates the strong scalability of \methodname, as it efficiently leverages additional opportunities to explore the search space, improving the normalized score by 4.7% after 10 rollouts and 6.4% after 20, compared to the initial rollout.

Figure: Figure 4: The average performance of \methodname on six selected datasets with an increasing number of rollouts.
Refer to caption: x4.png

##### LLM Adaptability

To evaluate the robustness of our framework, we conduct experiments using different Large Language Models (LLMs). Specifically, we compare the performance of \methodname with Claude-3.5-Sonnet (Anthropic, ) and GPT-4o (OpenAI, ) against DeepSeek V2.5 which we primarily use for evaluation. This comparison enables us to assess how the choice of LLM affects the overall effectiveness of our approach.

As Figure 5 shown, \methodname delivers similar results across different LLMs, indicating its flexibility with various models depending on user preference and availability. We also report the numeric results in Appendix C.2.

## 5 Conclusion

In this paper, we introduced \methodname, a novel framework that integrates LLM-based agents with Monte Carlo Tree Search (MCTS) to automate machine learning workflows. Our experimental results, conducted on 20 machine learning datasets, demonstrate \methodname’s effectiveness and highlight its distinct advantages over both traditional AutoML frameworks and existing LLM-based approaches. The proposed methodology is not limited to machine learning but could be adapted to a wide range of sequential decision-making problems, provided they can be represented as tree structures with scalar rewards derived from their leaf nodes.
Looking ahead, future work could explore extending this framework to other domains, including software engineering, scientific discovery, game playing, and robotics. Furthermore, improving the efficiency and scalability of the tree search process for larger solution spaces remains an important area for investigation. Another promising direction is developing techniques to provide interpretable explanations of the search process and solution rationale, enhancing the transparency and trustworthiness of the system. \methodname represents a significant advancement in automated machine learning, demonstrating the potential of combining traditional search algorithms with the flexibility of LLMs.

## Appendix A Datasets

Table 4 outlines the detailed information of the datasets used for evaluation.

**Table 4: Summary of the machine learning datasets used in the experiments. OpenML datasets can be accessed using their respective dataset IDs. The Kaggle datasets are available at https://www.kaggle.com/competitions/{source}.**
| Dataset name | # Features | # Rows | # Classes | Task Type | Metric | Source |
| --- | --- | --- | --- | --- | --- | --- |
| boston | 14 | 506 | N/A | Regression | RMSE | OpenML (Dataset ID: 531) |
| colleges | 48 | 7063 | N/A | Regression | RMSE | OpenML (Dataset ID: 42727) |
| concrete-strength | 9 | 4866 | N/A | Regression | RMSE | Kaggle (playground-series-s3e9) |
| diamonds | 10 | 53940 | N/A | Regression | RMSE | OpenML (Dataset ID: 42225) |
| house-prices | 81 | 1460 | N/A | Regression | RMSE | Kaggle (house-prices-advanced-regression-techniques) |
| Moneyball | 15 | 1232 | N/A | Regression | RMSE | OpenML (Dataset ID: 41021) |
| SAT11-HAND-runtime-regression | 118 | 4440 | N/A | Regression | RMSE | OpenML (Dataset ID: 41980) |
| credit-g | 21 | 1000 | 2 | Classification | F1 | OpenML (Dataset ID: 31) |
| Click_prediction_small | 12 | 39948 | 2 | Classification | F1 | OpenML (Dataset ID: 42733) |
| icr | 58 | 617 | 2 | Classification | F1 | Kaggle (icr-identify-age-related-conditions) |
| jasmine | 145 | 2984 | 2 | Classification | F1 | OpenML (Dataset ID: 41143) |
| kc1 | 21 | 2109 | 2 | Classification | F1 | OpenML (Dataset ID: 1067) |
| kick | 33 | 72983 | 2 | Classification | F1 | OpenML (Dataset ID: 41162) |
| smoker-status | 23 | 143330 | 2 | Classification | F1 | Kaggle (playground-series-s3e24) |
| software-defects | 22 | 91586 | 2 | Classification | F1 | Kaggle (playground-series-s3e23) |
| titanic | 12 | 891 | 2 | Classification | F1 | Kaggle (titanic) |
| GesturePhaseSegmentationProcessed | 33 | 9873 | 5 | Multiclass | F1-weighted | OpenML (Dataset ID: 4538) |
| mfeat-factors | 217 | 2000 | 10 | Multiclass | F1-weighted | OpenML (Dataset ID: 12) |
| segment | 20 | 2310 | 7 | Multiclass | F1-weighted | OpenML (Dataset ID: 40984) |
| wine-quality-white | 12 | 4898 | 7 | Multiclass | F1-weighted | OpenML (Dataset ID: 40498) |

## Appendix B Prompts

### B.1 Task Prompt

All LLM-based methods start by receiving the same base requirement prompt at the beginning of the task. The prompt specifies the dataset’s name, the target label column, the evaluation metric to be used, and the dataset’s file path. Furthermore, the prompt include a path to a text file containing the dataset’s metadata.

Since AIDE automatically splits the training data into a new train set and a validation set, we combine the original train and validation sets and provide them as input to AIDE. We set k_fold_validation to 1 in its configuration file to enforce a single train-val split for closer alignment with our setup. In both setups, the frameworks have access to the labels for both the train and validation sets.

### B.2 Instruction Prompt

The instruction prompt would direct the framework to save the final prediction file for evaluation.

### B.3 Insight Proposal Prompt

Insight Proposer uses this prompt to generate a search space of insights for different stages of the machine learning task.

## Appendix C Results

### C.1 Main Results

**Table 5: Methods’ ranking for each tabular dataset**
|  | AutoGluon | AutoSklearn | AIDE | DI | \methodname |  |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Dataset | Avg. | Best | Avg. | Best | Avg. | Best | Avg. | Best | Avg. | Best |
| Click_prediction_small | 7 | 7 | 2 | 1 | 7.3 | 4 | 11 | 10 | 7.7 | 6 |
| GesturePhaseSegmentationProcessed | 1 | 1 | 6.3 | 3 | 7.3 | 4 | 11 | 10 | 5.3 | 2 |
| Moneyball | 4 | 4 | 10 | 9 | 4 | 1 | 9 | 2 | 6 | 3 |
| SAT11-HAND-runtime-regression | 1 | 1 | 12 | 11 | 5.3 | 3 | 9 | 8 | 3.7 | 2 |
| boston | 5 | 5 | 12 | 11 | 3.7 | 2 | 9 | 8 | 4 | 1 |
| colleges | 1 | 1 | 12 | 11 | 6 | 2 | 8 | 7 | 4 | 3 |
| concrete-strength | 5 | 5 | 12 | 11 | 6.3 | 4 | 2 | 1 | 8.3 | 6 |
| credit-g | 4 | 4 | 10 | 9 | 10 | 5 | 5.3 | 1 | 3.7 | 2 |
| diamonds | 2 | 2 | 12 | 11 | 6 | 4 | 8.7 | 7 | 3 | 1 |
| house-prices | 1 | 1 | 12 | 11 | 6.7 | 5 | 7.3 | 3 | 4 | 2 |
| icr | 5 | 5 | 5.3 | 3 | 12 | 11 | 9 | 8 | 2.3 | 1 |
| jasmine | 7 | 7 | 6 | 4 | 8.7 | 5 | 11.3 | 9 | 2 | 1 |
| kc1 | 10 | 10 | 2.7 | 1 | 8 | 5 | 11.3 | 9 | 5 | 2 |
| kick | 4 | 4 | 2 | 1 | 9.3 | 6 | 11 | 10 | 6.7 | 5 |
| mfeat-factors | 4 | 4 | 2 | 1 | 10 | 9 | 10.3 | 6 | 6.7 | 5 |
| segment | 3 | 3 | 6.3 | 5 | 11 | 10 | 9.7 | 7 | 2.3 | 1 |
| smoker-status | 7 | 7 | 4.7 | 3 | 11.3 | 9 | 7.7 | 2 | 4.3 | 1 |
| software-defects | 8 | 8 | 2 | 1 | 12 | 11 | 6 | 4 | 7.7 | 6 |
| titanic | 7 | 7 | 9.7 | 6 | 2.7 | 1 | 10.3 | 8 | 5.3 | 3 |
| wine-quality-white | 2 | 2 | 10 | 8 | 7.3 | 4 | 9 | 7 | 3.3 | 1 |
| Overall Rank $\downarrow$ | 4.4 | 4.4 | 7.6 | 6.1 | 7.8 | 5.3 | 8.8 | 6.4 | 4.8 | 2.7 |

**Table 6: Methods’ NS % for each tabular dataset**
|  | AutoGluon | AutoSklearn | AIDE | DI | \methodname |  |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Dataset | Avg. | Best | Avg. | Best | Avg. | Best | Avg. | Best | Avg. | Best |
| Click_prediction_small | 26.6 | 26.6 | 40.2 | 40.3 | 26.1 | 39.4 | 12.9 | 13.9 | 23.2 | 27.4 |
| GesturePhaseSegmentationProcessed | 69.3 | 69.3 | 67.2 | 68.4 | 56.3 | 68.1 | 60.1 | 64.4 | 67.9 | 69.2 |
| Moneyball | 24.3 | 24.3 | 13.1 | 13.8 | 23.8 | 24.6 | 9.5 | 24.5 | 21.9 | 24.5 |
| SAT11-HAND-runtime-regression | 12.6 | 12.6 | 10.3 | 10.3 | 12.0 | 12.1 | 11.4 | 11.9 | 12.2 | 12.5 |
| boston | 39.8 | 39.8 | 19.5 | 19.6 | 40.5 | 41.3 | 37.0 | 38.6 | 40.1 | 41.4 |
| colleges | 88.3 | 88.3 | 2.1 | 2.1 | 86.0 | 87.8 | 87.5 | 87.7 | 87.8 | 87.8 |
| concrete-strength | 28.3 | 28.3 | 17.4 | 17.9 | 28.3 | 28.3 | 28.8 | 29.6 | 28.2 | 28.2 |
| credit-g | 50.5 | 50.5 | 35.1 | 44.0 | 21.6 | 48.4 | 48.1 | 53.2 | 50.9 | 52.7 |
| diamonds | 13.8 | 13.8 | 8.7 | 8.7 | 13.7 | 13.7 | 13.5 | 13.6 | 13.7 | 13.8 |
| house-prices | 9.0 | 9.0 | 2.0 | 2.0 | 8.9 | 8.9 | 8.5 | 9.0 | 8.9 | 9.0 |
| icr | 76.2 | 76.2 | 70.4 | 79.2 | 31.7 | 35.9 | 57.8 | 60.6 | 78.7 | 79.2 |
| jasmine | 84.3 | 84.3 | 84.4 | 84.7 | 83.6 | 84.6 | 77.8 | 83.5 | 85.4 | 86.2 |
| kc1 | 38.3 | 38.3 | 43.5 | 45.0 | 40.8 | 42.6 | 38.1 | 41.2 | 42.2 | 43.1 |
| kick | 39.6 | 39.6 | 41.8 | 42.1 | 14.9 | 38.6 | 2.8 | 4.2 | 35.9 | 38.7 |
| mfeat-factors | 96.7 | 96.7 | 97.1 | 97.5 | 94.4 | 94.5 | 93.0 | 96.0 | 95.7 | 96.2 |
| segment | 93.5 | 93.5 | 92.7 | 93.1 | 91.7 | 92.2 | 91.7 | 92.6 | 93.8 | 94.4 |
| smoker-status | 78.0 | 78.0 | 78.6 | 78.9 | 74.8 | 76.3 | 77.3 | 81.5 | 82.4 | 91.5 |
| software-defects | 51.5 | 51.5 | 61.1 | 61.7 | 49.7 | 49.8 | 54.5 | 57.3 | 52.2 | 53.3 |
| titanic | 78.9 | 78.9 | 76.2 | 78.9 | 81.2 | 83.7 | 76.0 | 78.5 | 78.8 | 79.7 |
| wine-quality-white | 65.4 | 65.4 | 60.7 | 61.4 | 62.9 | 65.1 | 61.2 | 61.6 | 65.3 | 66.0 |
| Overall NS % $\uparrow$ | 53.2 | 53.2 | 46.1 | 47.5 | 45.5 | 51.8 | 47.4 | 50.2 | 53.3 | 54.7 |

### C.2 Performance using different LLMs

**Table 7: Results of \methodname with different base LLMs on the selected tabular datasets.**
|  | GPT-4o | Claude 3.5 Sonnet | DeepSeek V2.5 |
| --- | --- | --- | --- |
| Avg. NS $\uparrow$ | 62.3 | 57.9 | 60.9 |
| Avg. Best NS $\uparrow$ | 65.5 | 59.2 | 62.4 |
| Avg. Rank $\downarrow$ | 3.7 | 6.3 | 5.0 |
| Avg. Best Rank $\downarrow$ | 1.5 | 4.8 | 3.2 |

## Appendix D Cost-effectiveness Analysis

We conduct multiple trials of execution of each method to estimate the average running cost for the LLM-based baselines. As shown in Table 8, all methods incur relatively low costs to complete a single machine learning task. Among these, AIDE exhibits the lowest execution cost, due to the lack of stage-wise planning, resulting in fewer token generations compared to the other approaches. Additionally, \methodname, which employs Data Interpreter as its base experimenter, is less costly than Data Interpreter itself. This efficiency is largely due to \methodname’s state-saving and loading mechanism, which reduces the generation of repeated tasks and code.

**Table 8: Estimated costs of agent-based frameworks utilizing DeepSeekV2.5 on a single machine learning dataset over $k$ iterations/rollouts.**
|  | Cost per ML task ($) |  |  |
| --- | --- | --- | --- |
| Data Interpreter ($k$=10) | 0.07 |  |  |
| AIDE ($k$=10) | 0.01 |  |  |
| \methodname ($k$=10) | 0.05 |  |  |

## Appendix E Case Study

### E.1 Overview of SELA’s search process

In this case study, we demonstrate how SELA conducts a search cycle using MCTS:

Pre-search Step: Initialization
SELA begins by defining high-level stages, such as exploratory data analysis, data preprocessing, feature engineering, and model training, which structure the overall machine learning workflow. During the search, SELA populates these stages with specific insights, which act as experimental configurations for simulation.

Step 1 & 2: Selection and Expansion
SELA leverages MCTS to explore specific stages like feature engineering and model training. For example, in one iteration, SELA selects Node 0-1. This node corresponds to a stage insight that generates time-based features, expanding into five child nodes representing various model specifications and training strategies, such as Random Forests, Support Vector Machines, Neural Networks, Gradient Boosting, or Grid Search.

Step 3: Simulation
Next, SELA samples one of the expanded child nodes for simulation. For instance, when Node 0-1-1 is chosen, SELA runs a complete experiment where time-based feature engineering (Node 0-1) is followed by training a Support Vector Machine (SVM) with a kernel specified by Node 0-1-1. The simulation yields an evaluation score.

Step 4: Backpropagation
After the simulation, the resulting performance score is propagated back through the tree. For example, after simulating Node 0-1-1, MCTS updates the numeric feedback for its parent nodes, such as Node 0-1 and Node 0. The search cycle repeats from Steps 1 to 4 until a stopping condition is reached.

Post-search Step: Best Node Selection
In the final phase, SELA selects the node representing the best-performing solution. In this example, Node 0-1-1, using an SVM with an RBF kernel, achieved the highest score in the current dataset by combining effective feature engineering with advanced model training. SELA then presents the code associated with this node as the optimal solution.

## Peer Reviews

confidence: 3
contribution: 2
initial_rating: 3
presentation: 3
questions: Could the authors elaborate on some key challenges faced when integrating LLM agents with tree search for AutoML tasks, and how SELA addresses them? All in all, I am trying to understand if the application is straightforward.
soundness: 3
strengths: - The paper conveys the main ideas and results clearly.
- Handling the NP-hardness of the problem by incorporating LLM agents with a search procedure is intuitive and makes a lot of sense.
summary: The paper proposes a method (SELA) that combines LLMs with MCTS to solve AutoML tasks. More concretely, SELA uses LLMs to generate a search space of solutions (essentially generating different possibilities across different stages in the ML pipeline), which is then explored using MCTS. Through experiments on tasks from the AutoML benchmark and Kaggle competitions, the paper demonstrates SELA's efficacy against baseline methods.
weaknesses: My main concern with this paper is regarding the novelty of the proposed method. The authors note that prior work has already explored combining LLMs with tree search methods. This makes it unclear if the technical contribution of this paper is novel enough for ICLR. The primary contribution of applying LLMs with tree search to AutoML could be an interesting contribution had the paper shown that tree search cannot be trivially combined with LLMs to solve AutoML problems, and highlighted the key challenges faced.

---

confidence: 3
contribution: 3
initial_rating: 5
presentation: 2
questions: 1. Regarding the `simulate` phase of MCTS, I understand that your tree has a depth of 6 levels (including the root node). Consequently, $x_{\text{sample}}$ does not necessarily correspond to the final Model Evaluation node, so $c(x_\text{sample})$ does not represent a complete configuration file. How, then, can this be provided to the experimenter $E$ to obtain a score-evaluable code?

2. Regarding lines 205 and 323, when I expand a node at time $\tau_i$, I provide the problem description $p$, dataset information $d$, and $\lambda(x_i)$ (where $\lambda(x_i)$ might concatenate with $\lambda(x_{i-1})$) as the LLM’s prompt, generating $m$ values of $\lambda(x_{i+1})$, from which one is randomly sampled for simulation—is this correct?

3. Given that even the most SOTA models struggle to generate immediately executable code, especially for complex ML tasks, how do you handle cases where the code provided by the LLM fails to execute? Do you assign it a minimum score or apply a different approach?

4. In lines 242–258, could you clarify the distinction between Value and Simulation Score, as well as between Solution Code and Stage Code? My understanding is that Stage Code corresponds to the current node’s code, but is Solution Code a set of codes of child branches? Since the node may have multiple branches. 

5. In line 363, "Each framework utilizes the training and validation sets to train models," but I do not see any component in SELA that can be trained.

6. Regarding line 443, as a comparison, how exactly does SELA refine its Solution? I only understand that it finds the optimal solution through MCTS Search, but if a node's result is not good, it seems they won't refine it either, they just won't select it.

7. Line 393 mentions each AutoML rollout is conducted 10 times. Isn’t this count too low for a tree search, potentially resulting in a sparse tree structure?

8. Line 1160 states that each node corresponds to a single feature; however, combining multiple feature engineering techniques is standard practice. Does SELA not support such feature combinations?
soundness: 2
strengths: The paper presents an interesting pipeline for AutoML based on LLM agents, where the functional attributes of each node layer are intuitively and innovatively defined.
summary: This paper introduces SELA (Tree-Search Enhanced LLM Agents), a novel approach that combines Large Language Model (LLM) agents with Monte Carlo Tree Search (MCTS) for automated machine learning (AutoML). The primary contribution is defining an AutoML pipeline using a tree structure and experimentally demonstrating its effectiveness.
weaknesses: 1. The paper lacks sufficient detail and resources for reproducibility.
2. The study involves multiple modules and details; however, the results in Table 2 appear to show only marginal improvements.
3. Additional issues are mentioned in the "Questions" section.

---

confidence: 5
contribution: 1
initial_rating: 1
presentation: 1
questions: What is the configuration budget allocated to all methods? Since you mentioned AutoSKlearns 600seconds wall-clock time of budget, did you limit SELA to the same small budget?
soundness: 1
strengths: The ablation study showing the strenghts of different base LLMs is interesting.
summary: The work introduces an LLM based AutoML tool that uses MCTS to search for better performing configurations.
weaknesses: The work largely seems to be unfamiliar with AutoML tools and the broader literature. This is particularly evident with the work repeatedly claiming falsehoods about AutoML. For example, early on it is said that AutoML tools typically only focus on the model training aspect, while ignoring feature engineering stages and so on. This claim is easily refuted as many of the cited tools do include data preprocessing and feature preprocessing into account and generally tend to the whole machine learning pipeline. It is often left to the user however what to include in the search space, thus a user might only want to focus on the model training element. Further, the work claims as a contribution that the search is inspired by how humans would conduct hyperparameter search/configuration. I.e., repeated experimentation while refining the search. This is exactly what nearly all AutoML tools do. Many are based on bayesian optimization which typically executes an initial design to probe the search space, then queries the most promising configuration(s) based on an internal model, based on the observation of the actual performance the model is refined and the search continues until a configuration budget is exhausted. Again, this is the standard approach in AutoML, making the claim in "contribution 1" not a contribution of this work. Further, contribution 2 hinges on the use of MCTS for AutoML (with an LLM base). However, MCTS has been already used and studied in the realm of AutoML (see the work by Rakotoarison https://inria.hal.science/hal-01966957/file/MOSAIC-wkpICML2018.pdf) strongly diminishing this claimed contribution. Further, the experiments do not consider an AutoML approach that uses MCTS for comparison.

I was already skeptical towards the experiments due to the untruths written about AutoML. I am further convinced that the evaluation of the aproaches is completely unfair. For AutoGluon and AutoSKLearn it is stated that they are simply used in their default configurations. However, it is not clear how much compute budget each method was allocated and that SELA very likely had a much larger configuration budget available than all other methods. Despite these weird setup issues, AutoGluon shows very strong performance, which is waved aside by the work. An important baseline that needs to be compared against in the AutoML realm is also missing. TabPFN uses a foundation model trained on synthetic data to learn to solve ML tasks and has shown highly competitive or even outperforming classical AutoML systems. This method thus has to be considered in a work as it is presented here. Overall the work can absolutely not be published. The work has to be largely rewritten to remove the false claims and the experiments likely need to be completely redone. I do not see immediate action items that would increase my trust in the work and would make me reconsider my scoring.

---

confidence: 4
contribution: 2
initial_rating: 5
presentation: 3
questions: - The experimental evaluation could be more comprehensive. Further exploration and justification of the chosen datasets, along with a deeper analysis of the results, would enhance the paper's impact and contribution to the field.
- Can you provide details on the size of the search pool for the MCTS procedure? Additionally, how many iterations does MCTS typically require to achieve good performance?

My score may be revised upon reviewing the authors' response to these limitations.
soundness: 3
strengths: - The integration of MCTS with LLM agents is a creative approach to address the limitations of existing AutoML frameworks. By using MCTS, SELA aims to mimic the iterative and feedback-driven problem-solving approach of human experts, which is a commendable attempt to enhance the adaptability and effectiveness of AutoML systems.
- The experimental results indicate that SELA outperforms several baseline methods across a range of datasets. This suggests that the proposed method has potential advantages in terms of flexibility and performance, offering a fresh perspective on tackling complex machine learning challenges.
- The paper provides a detailed description of the SELA framework, including its components such as the insight proposer, experiment executor, and the MCTS-based search module. This thorough explanation helps in understanding the workflow and the role of each component in the overall system.
summary: The paper introduces SELA, a novel framework that integrates Monte Carlo Tree Search (MCTS) with Large Language Model (LLM) agents to enhance the process of Automated Machine Learning (AutoML). The authors claim that SELA improves the exploration and optimization of machine learning pipelines by leveraging MCTS to systematically explore potential configurations. The framework is evaluated on 20 datasets, demonstrating a win rate of 65% to 80% against traditional and agent-based AutoML methods.
weaknesses: - While the integration of MCTS with LLM agents is an interesting approach, the innovation appears limited. The application of MCTS in this context is relatively straightforward and does not introduce significant novel techniques beyond existing LLM-agent frameworks like Data Interpreter. The paper could benefit from a deeper exploration of how MCTS specifically enhances the LLM agent's capabilities in a unique way.
- The experimental evaluation, although showing promising results, is somewhat inadequate. The authors do not provide a clear rationale for the selection of the 20 datasets from the AutoML Benchmark (AMLB). Given the diversity of tasks available in AMLB, it would be beneficial to understand the principles behind the choice of these specific tasks to ensure a comprehensive assessment of SELA's capabilities.
- The paper lacks a detailed analysis of the results and the specific contributions of MCTS to the observed performance improvements. A more in-depth discussion on how MCTS influences the exploration and optimization process, compared to other search strategies (beyond random ones), would strengthen the paper's contributions. In particular, UCB typically requires a significant number of exploitation steps to accurately evaluate the value of each node. However, this would incur a huge workload in an AutoML scenario. It would be beneficial to discuss how the authors achieve a good trade-off between efficiency and effectiveness, and why limited exploitation of UCB suffices to gain a performance improvement.

Meta-review: This paper proposes to do a specific variant of MCTS for AutoML tasks, where the possible actions consist of standard data-science actions, e.g. data processing, feature engineering, proposing models, etc.

Comparisons are made against standard AutoML packages such as AutoGluon, AutoSklearn, with generally competitive results.

## Strengths: 
* The main message of the paper, from my perspective, is showing that LLMs can perform agentic approaches for AutoML problems, which has the potential for future work in e.g. data science, scientific discoveries, AI for AI, etc.
* If we assume that the experiments were rigorously done, then results seem comparable to SOTA AutoML platforms (AutoGluon, etc.)

## Weaknesses:
* There was an overall sentiment of "It's just another LLM can do XYZ" paper.
* In my opinion, the writing style is pretty opaque - Section 3 I think has a poor combination of notation and wordiness, that made it difficult to read.

Unfortunately, none of the reviewers wishes to champion this paper, as the highest score as a 5. The overall message "LLM Agents can do AutoML" wasn't well-received, as most of the negative feedback came from novelty and experimental rigorousness.

In general, this paper might not be suitable for ICLR, and I actually recommend the authors send this paper to a LLM-focused conference, provided that they rewrite the paper to focus more on the overall agentic message. Otherwise, I can forsee it having the same feedback issues if submitted to NeurIPS/ICML (lack of novelty, etc.). This is unless, somehow the proposed method would lead to significantly better experimental outcomes.

Decision: Reject