Summary
This paper is about improving the performance of language agents by refining the action space during the learning phase. Specifically, the authors propose LearnAct, an iterative system that uses LLMs to create new (or edit existing) actions based on past experiences and to act as a policy. In this work, the actions are expressed as Python code which enables the use of conditional statements, loops, and function calls (i.e., composition of actions). Experiments were conducted on robotic planning tasks and ALFWorld (a text-based game version of ALFRED, a 3D embodied environment). Empirically, the authors show that LearnAct achieves better performance on average compared to some relevant baselines (ReAct, Reflexion, CodeAsPolicy, Voyager) on those environments.
Edit: I have increased my score to 7.
Reasons to accept
- Letting the the action space evolve based on past experiences is a nice idea. This is a good way to get actions that operated at different level of abstraction, i.e. hierarchical planning.
- Having higher-level actions (expressed as code) help reducing the compute cost during inference. That is, you don't have to call the LLMs at each timestep.
- Transferability of the learned actions to new tasks from a same domain. I think this is a very important aspect of the work, as many prior works focuses on single-problem solving.
Reasons to reject
- The research on Language Agents is evolving very fast and there is probably several prior works missing from the related work section. On top of my head, two came in mind: [TaskWeaver: A Code-First Agent Framework](https://arxiv.org/abs/2311.17541) and [ReGAL: Refactoring Programs to Discover Generalizable Abstractions](https://arxiv.org/abs/2401.16467). I think it would be beneficial to the reader to have a more comprehensive related work section to better position their work.
- This is a smaller concern. I noticed a small paragraph in A.6.3 about failure mode of the proposed technique regarding excessive iterations (which according to Fig.3 anything above 2 iterations looks worst!). Is this that the only failure? I doubt it, e.g., limit of the context length in ActionLearn to update the full action space at each iteration. I think having a proper discussion of the limitation as part of the main text would strengthen the paper.
Questions to authors
- What is the definition of closed-loop in the context of this work? Is it the action learning process that is closed-loop or the actions (i.e., Python functions) themselves? If you are referring to the actions, have you checked if they are really closed-loop? In my experience Voyager tends to generate actions that are open-loop, i.e., they ignore the state of the environment as they send command to the environment. Granted this might be less problematic in your environments compared to Minecraft where other entities are moving in parallel.
- In section 5.3, it says the **temperature** is 0, but it also mentions sampling number is 4. I'd expect to get very similar samples (if not all the same). Can the authors clarify this?
- Do the authors have any insights on the generalization of the learned actions to unseen domains but that are sharing the same predefined actions?
- I'm curious to know if the authors have considered any open-source models during their experimentation?