Response to Reviewer CapU (Part 1/2)
We sincerely thank the reviewer for the thorough and constructive comments. Please find the response to your questions below.
> The authors have conducted experiments solely in the Karel the Robot domain. Testing the LLM-GS algorithm in another domain, such as MicroRTS, would enhance confidence in its effectiveness across different problem domains and DSLs. Addressing this issue could lead me to reconsider my score.
Due to the limited time we have during the rebuttal period, we could not conduct experiments in the MicroRTS domain since running each method against CoacAI on map basesWorkers8x8A, one of the simplest tasks in MicroRTS, could take up to 16 hours per seed for search-based methods like HC so it’s more than 10 days in total and it takes even longer for RL based method like HPRL.
Therefore, to include an additional domain, we adopt **the Minigrid domain** [1]. We designed the DSL for Minigrid to be similar to the MicroRTS DSL used by Moraes et al. [2]. Specifically, both the perception functions in our Minigrid DSL and the MicroRTS DSL are parameterized, i.e., require an input parameter such as an object, since there are multiple object types in the two domains, unlike the case in Karel.
We present the results of three Minigrid tasks in Section 5.5 in the revised paper. As shown in Figure 9, **LLM-GS demonstrates better sample efficiency compared to HC, the best-performing baseline in the Karel domain**. For further details of the Minigrid experiments, please refer to Section 5.5 and Appendix L.
> The ablation study comparing search algorithms is quite limited, especially given the close results shown in Figure 6. It appears that the LLM provides such a strong starting point that the specific search algorithm has minimal impact. All search algorithms perform reasonably well on CleanHouse, and the results are very similar among the top 2-3 algorithms on DoorKey. Including results from additional domains would help establish the significance of the search algorithm.
In Figure 6, it is evident that HC-32 and HC-2048 excel only in specific tasks: HC-32 performs exceptionally well in CleanHouse, while HC-2048 stands out in DoorKey. In contrast, our proposed scheduled HC ranks among the best-performing methods in both DoorKey and CleanHouse, showcasing its robustness and efficiency. **That said, given a novel task of interest, we can confidently run our method LLM-GS instead of trying HC with different hyperparameters**.
> Furthermore, the scheduled hill climbing algorithm involves several design choices, such as the sinusoidal schedule and logarithmic interpolation; conducting separate ablation studies on the importance of each of these choices could be beneficial.
We thank the reviewer for the suggestion. There are three components in the proposed scheduled hill climbing (SHC): logarithmic interpolation, sinusoidal schedule, and logarithmic ratio. As suggested by the reviewer, **we have conducted additional experiments ablating each component**. We substitute them with their linear counterpart and testify all 8 variants in DoorKey and CleanHouse. The results shown in Appendix E in the revised paper indicate no significant differences between all the SHC variants, showcasing its robustness in design.
> Do the equations for the scheduled hill climbing algorithm derive from prior work, or is there additional intuition apart from the decision to increase the search budget as the algorithm progresses? There are several key choices here—such as the logarithmic interpolation and sinusoidal schedule—that don’t seem entirely intuitive and are introduced without sufficient justification. Could you provide more details on these decisions?
Our intuition to logarithmic interpolation and logarithmic ratio aims to allocate the most appropriate neighborhood size, k, to tasks of varying difficulties. The logarithm of the number of executed programs provides an indication of task difficulty, with the intuition that the optimal k should increase exponentially according to the structure of AST. For the sinusoidal schedule, we prioritize maintaining a stable neighborhood size k during both the early and final stages of the training process. We thank the reviewer for raising this question, and we have revised the paper to include these design intuitions in Appendix E.
> Are the program embeddings used for latent space search generated by the LLM?
No. We do not use LLMs to generate the program embeddings; instead, **the program embeddings are derived from Trivedi et al. [3]**. Their method trains a Variational Autoencoder (VAE) to produce a program embedding space from programs and their execution traces.