REvolve: Reward Evolution with Large Language Models using Human Feedback

## Abstract

Abstract Designing effective reward functions is crucial to training reinforcement learning (RL) algorithms. However, this design is non-trivial, even for domain experts, due to the subjective nature of certain tasks that are hard to quantify explicitly. In recent works, large language models (LLMs) have been used for reward generation from natural language task descriptions, leveraging their extensive instruction tuning and commonsense understanding of human behavior. In this work, we hypothesize that LLMs, guided by human feedback, can be used to formulate reward functions that reflect human implicit knowledge. We study this in three challenging settings – autonomous driving, humanoid locomotion, and dexterous manipulation – wherein notions of “good” behavior are tacit and hard to quantify. To this end, we introduce REvolve, a truly evolutionary framework that uses LLMs for reward design in RL. REvolve generates and refines reward functions by utilizing human feedback to guide the evolution process, effectively translating implicit human knowledge into explicit reward functions for training (deep) RL agents. Experimentally, we demonstrate that agents trained on REvolve-designed rewards outperform other state-of-the-art baselines.

## 1 Introduction

Recent successes in applying reinforcement learning (RL) have been concentrated around areas with clearly defined reward functions (Silver et al., ; Vinyals et al., ). However, tasks with ambiguously defined rewards, such as autonomous driving, still present challenges due to their complex and difficult-to-specify goals (Knox et al., ). This echoes Polanyi’s paradox, which states that *we know more than we can tell* (Polanyi, ). The notions of \saygood behavior (i.e., aligned with human standards) are inherently subjective – involving a level of tacit knowledge that is hard to quantify and encode into reward functions. This is also referred to as the reward design problem and often leads to sub-optimal behaviors that exploit shortcuts in the reward function and that do not truly reflect human preferences (Kerr, ; Hadfield-Menell et al., ; Booth et al., ). This issue is underscored by the growing concerns about the misalignment between human values and the objectives pursued by agents (Turner et al., ; Omohundro, ; Russell, ).

Recently, LLMs have shown impressive abilities in instruction following (Longpre et al., ; Peng et al., ), search and black-box optimization (Yang et al., ; Zhang et al., ; Liu et al., ), self-reflection (Madaan et al., ; Shinn et al., ), and code generation (Chen et al., ; Roziere et al., ). Owing to their vast training and world knowledge (Wang et al., ; Hao et al., ; Hazra et al., ), they can readily incorporate commonsense priors of human behavior. Together, these abilities make LLMs an ideal candidate for generating rewards from natural language (NL) task descriptions and refining them using language-based feedback loops. Indeed, recent works like Language to Rewards (Yu et al., ) and Text2Reward (Xie et al., ) have utilized LLMs for this purpose. More significantly, Eureka (Ma et al., ) utilizes LLMs to design dense and interpretable reward functions, achieving improved performance in dexterous manipulation tasks. It does so by generating multiple reward functions and *greedily* mutating the best candidate over multiple iterations.
As such, Eureka resembles more of a *greedy iterative* search than an evolutionary search, as described in Ma et al. ().

We identify this greedy approach as a significant limitation that
risks premature convergence and leads to a waste of resources (by preemptively discarding *weaker* reward functions). Moreover, Eureka relies on having access to fitness functions to assess the quality of learned behaviors and decide the best reward function. This leads to a chicken-and-egg dilemma – if designing a good fitness measure was feasible, one could arguably design an effective reward function just as easily. This is particularly challenging for complex tasks, such as autonomous driving or dexterous manipulation.

To this end, we introduce Reward Evolve (REvolve), a novel evolutionary framework using LLMs, specifically GPT-4, to output reward functions (as executable Python codes) and evolve them based on human feedback. This allows humans to serve as fitness functions by mapping their preferences and feedback into fitness scores.

In particular, REvolve offers the following novelties:

(1) Using Evolutionary Algorithms (EAs) for Reward Design.
Traditional gradient-based optimization is unsuitable for reward design due to the lack of a differentiable cost function. Instead, REvolve utilizes meta-heuristic optimization through EAs (De Jong, ) to search for the best candidates. This is done by evolving a population of reward functions using genetic operators like mutation, crossover, and selection – employing LLMs as intelligent operators instead of traditional handcrafted methods. We empirically show that our evolutionary framework considerably outperforms iterative frameworks like Eureka – all *without incurring additional computational costs compared to Eureka*. Through REvolve, we also demonstrate that EAs, combined with the full range of operations like mutation, crossover, selection, and migration, can be successfully implemented with LLMs.

(2) Utilizing Human Feedback to Guide the Search. Mapping human notions directly into explicit reward functions is challenging; however, humans can still evaluate learned behaviors, effectively acting as fitness functions. Through REvolve, human preferences are directly mapped into fitness scores. Additionally, REvolve incorporates qualitative natural language feedback, offering GPT-4 high-level insights into which aspects to prioritize while refining the reward functions. Together, this ensures that the reward functions – and thus the learned policies – more closely reflect human notions.

(3) Eliminating the Need for Additional Reward Model Training. Unlike reinforcement learning with human feedback (RLHF) (Christiano et al., ), which relies on a black-box reward model – trained on massive amounts of curated human preference data – to align LLMs with goals like safety and reliability (OpenAI, ), REvolve requires no extra models. *REvolve-designed reward functions are interpretable* (as executable Python code) compared to RLHF rewards, making it more suitable for safety-critical applications, such as autonomous driving (Christian, ). We also include an estimated data requirement comparison in Appendix D.

Figure: Figure 1: An overview of REvolve. Given the task (here, autonomous driving) and abstracted environment variables, a reward designer $G$ (LLM) outputs a population of reward functions $R\in\mathcal{R}$, each used to train a policy $\pi(R)$ in simulation. Then, we collect human preferences and natural language (NL) feedback on pairs of policy rollouts $\theta\sim\Theta_{\pi(R)}$ through a user feedback interface. Policy (and thus, corresponding reward function) fitness $\sigma$ is calculated, and the fittest individuals, along with their NL feedback $\lambda$, are refined by $G$. In addition, the process leverages genetic programming for evolution.
Refer to caption: extracted/5963846/images/rewolve-overview.png

Figure 1, provides an overview of REvolve for autonomous driving within a simulated environment.

## 2 Problem Formalization

Let us first formally introduce the reward design problem (RDP) (Singh et al., ), given by the tuple $\langle M,\mathcal{R},\pi,F\rangle$, where $M=(S,A,T)$ is the world model consisting of state space $S$, action space $A$, and transition function $T$. $\mathcal{R}$ is the set of all reward functions where each $R\in\mathcal{R}$ is a reward function that maps a state-action pair to a real-valued scalar $R:S\times A\rightarrow\mathbb{R}$. The tuple $(M,R)$ constitutes a Markov decision process (Sutton & Barto, ).
Furthermore, $\pi:S\rightarrow\Delta A$ is a policy that maps a state to a distribution over actions, which is learned using a reward function $R$.

Moreover, the RDP includes a function $F$ that evaluates the fitness (i.e., quality) of the trained policies. Traditionally, $F$ maps policy rollouts, i.e., rollouts of agent-environment interactions, to real-valued scalars. Formally, we denote this by $F:\Omega(\Theta_{\pi})\rightarrow\mathbb{R}$, where $\Theta_{\pi}$ is the random variable modeling the probability distribution of rollouts induced by $\pi$ and $\Omega(\Theta_{\pi})$ is its sample space.

For REvolve, we generalize this to also include natural language feedback.
Specifically, we redefine $F:\Omega(\Theta_{\pi})\rightarrow\mathbb{R}\times\mathcal{L}$, where $\mathcal{L}$ is the set of all strings (including natural language feedback).
Note that the fitness function is derived from human evaluations of the trained policies, thereby rendering it non-differentiable.

In order to instantiate the RDP tuple for REvolve, we assume that we are given a reward designer $G:\mathcal{L}\rightarrow\mathcal{R}$ that maps from the set of all strings to the set of all reward functions $\mathcal{R}$.
The objective now is to find a reward function $R\in\mathcal{R}$ that maximizes the expected fitness score of the policy $\pi$ trained on $R$, which we denote by $\pi(R)$. Formally, we express the optimization problem as follows:

$$ $\displaystyle R^{*}\coloneqq\operatorname*{arg\,max}_{R\in\mathcal{R}}\Bigl{[} \mathbb{E}_{\theta\sim\Theta_{\pi(R)}}\left[F(\theta)\right]\Bigr{]}$ (1) $$

Here, $\theta$ is a trajectory sampled from $\Theta_{\pi(R)}$. We also define the optimal policy $\pi^{*}$ as the policy trained with reward function $R^{*}$ given as $\pi^{*}\coloneqq\pi(R^{*})$.

An implicit assumption for reward design is the knowledge of observation and action variables in the environment. For real-world problems, like autonomous driving, the assumption is supported by access to sensor data (such as speed from speedometers and distance covered from odometers) or by employing advanced vision-based models (Kirillov et al., ; Cheng et al., ; Yuan et al., ).

## 3 Reward Evolution

As the fitness function $F$ is based on implicit human understanding, it cannot be explicitly formulated and is, therefore, not amenable to gradient-based optimization.
Hence, we solve the RDP using a meta-heuristic approach through genetic programming (GP) (Langdon & Poli, ).
Concretely, REvolve uses GP to output and iteratively refine a population of reward functions (individuals) by applying genetic operations such as mutation, crossover, and migration. In each iteration, we obtain new individuals, which are added to the population based on their fitness. This fitness is assessed through human evaluations of the policies trained with these reward functions – thus guiding the evolutionary search.

Evolutionary algorithms, in general, are considered to be weak methods that perform blind searches and do not exploit domain-specific knowledge (De Jong, ). The initialization and perturbations are random, leading to scalability issues (O’Neill et al., ). In contrast, LLMs can leverage their commonsense priors to suggest changes that are intelligent and better aligned with the feedback (Gugerty & Olson, ). Therefore, we combine the evolutionary search of REvolve with LLMs by using them as reward designers $G$ in the RDP – thus avoiding blindly searching in the solution space.

We follow the island model of evolution (Cantú-Paz et al., ), where we maintain multiple ($I$) sub-populations (or islands) in a reward database $D$. Island populations evolve by locally reproducing (mutation and crossover). Periodically, individuals migrate from one island to another. The island model helps enhance genetic diversity across the population and prevent premature convergence in complex search spaces (Cantú-Paz et al., ). Following existing works in reward design with LLMs (Xie et al., ; Ma et al., ), we represent the reward functions as Python programs that seamlessly integrate with the GP framework.
In what follows, we describe the four stages (initialization, reproduction, selection, termination) of our evolutionary framework. We give the formal description in Algorithm 1 – for brevity, we use $\pi$ instead of $\pi(R)$.

Figure: Algorithm 1 REvolve

### 3.1 Initialization

We start by creating a population of $K$ reward function individuals using GPT-4. This leverages GPT-4’s world knowledge (Hao et al., ) and its zero-shot instruction following abilities (Peng et al., ). For each individual, we train a policy $\pi$, compute a fitness score $\sigma$, and obtain natural language feedback $\lambda\in\mathcal{L}$. The fitness score calculation and feedback collection are detailed in Section 3.3. Each individual and their respective policy, fitness score, and natural language feedback $(R,\pi,\sigma,\lambda)$ is then randomly assigned to a sub-population and stored in the reward database $D$.

### 3.2 Reproduction

Each successive generation of $K$ individuals is created by applying genetic operators (crossover and mutation), on the existing reward database individuals. We use GPT-4 as mutation and crossover operators with appropriate prompts. Due to space constraints, we provide prompt examples for mutation and crossover in Appendix E.

We begin by randomly selecting an operation – mutation with probability $p_{m}$ or crossover with probability $p_{c}=1-p_{m}$. Next, we sample a sub-population $P$ via weighted selection based on the average fitness scores $\sigma^{P}$ of each of the $I$ sub-populations. Subsequently, we sample parents (one for mutation, two for crossover) from $D[P]$ using weighted sampling based on individual fitness scores. These sampled individuals, along with their natural language feedback $\lambda$, are used to prompt GPT-4 to create new individuals. These prompts direct GPT-4 to either modify a single reward component of the parent ($\texttt{Mutate}(G,D[P])$) or combine best performing reward components from two parents ($\texttt{Crossover}(G,D[P])$). Periodically, we enable the migration of individuals between sub-populations to enhance genetic diversity. Reproduction operations are illustrated in Figure 2.

Figure: Figure 2: Illustration of how GPT-4 applies mutation and crossover to reward functions. Mutation (left): shows the modification of the ”smoothness reward” component. A red ‘-’ sign indicates the line removed from the parent reward function, while a green ‘+’ sign indicates the line added to the new reward function. Crossover (right): demonstrates how parent reward functions are combined to create a child reward function, incorporating the most effective reward components from each parent.
Refer to caption: x1.png

### 3.3 Selection

Newly reproduced individuals (from the reproduction stage) are retained based on fitness scores, following a *survival of the fittest* approach. A fitness function $F$, tailored to the specific problem, evaluates the quality of each individual. The process involves (1) training a policy $\pi(R)$ until convergence, (2) sampling rollouts $\theta\sim\Theta_{\pi(R)}$, and (3) using the fitness function to obtain a tuple of (real-valued) fitness score and (string) NL feedback $(\sigma,\lambda)\coloneqq F(\theta)$. Individuals are retained if they contribute to an increase in the average fitness of their respective sub-populations $\sigma\geq\sigma^{P}$, where $P$ denotes the sub-population to which the individual is added(^1^11To ensure genetic diversity, we add individuals based on surpassing the average and not maximum scores.). This ensures that the average fitness of the sub-population is monotonically increasing. In what follows, we detail the process of obtaining the tuple $(\sigma,\lambda)$ from the fitness function.

To compute the fitness score $\sigma$, we ask human evaluators to judge policy rollouts $\theta$ from different policies in a pairwise fashion. As illustrated in the user feedback interface in Figure 1, these rollouts are presented as video segments $\approx$ 30-40 seconds long. The evaluators choose their preferred segment (ties are also possible). We then apply an Elo rating system (Elo, ), which transforms pairwise assessments into fitness scores $\sigma$. This avoids the need to learn a separate reward model, cf. RLHF (Christiano et al., ). Asking human evaluators to provide preferences instead of quantitative scores for each video has the advantage of mitigating individual bias (Christiano et al., ). Details of the human feedback collection and Elo scoring are documented in Appendix B.1.

The NL feedback $\lambda$ about each pair of video segments is, likewise, collected through the same feedback interface. Evaluators comment (select checkboxes) on aspects of the driving they find satisfactory or need improvements. This feedback is subsequently integrated into the prompt for GPT-4 when reward function individuals are sampled for reproduction.

### 3.4 Termination

The evolutionary process repeats until it reaches a predetermined number of generations $N$, or when an individual attains a fitness score equivalent to human-level driving performance, as detailed in Section 5.3. The final output is the fittest policy $\pi^{\ast}$ corresponding to the highest $\sigma$ in the database $D$. Note that $\pi^{\ast}$ is the best policy in the reward database according to human-assigned fitness scores $\sigma$, but it is not necessarily the optimal policy.

A minimal input-output example of the working of REvolve is shown in Appendix F.

## 4 Related Work

Reward Design with LLMs.
Recent works have explored LLMs for complex search and black-box optimization problems like hyperparameter optimization (Yang et al., ; Zhang et al., ; Liu et al., ), reward design for RL (Kwon et al., ; Xie et al., ; Ma et al., ), or robotic control (Yu et al., ). Kwon et al. () use LLMs to directly output binary rewards by inferring user intentions in negotiation games, but this requires numerous queries to LLMs and limits the rewards to sparse binary values. Conversely, Language to Rewards (L2R) (Yu et al., ) and Text2Reward (T2R) (Xie et al., ) utilize LLMs to create dense and interpretable reward functions, improving them with human feedback. L2R, however, restricts its adaptability by employing manually crafted reward templates tailored to specific robot morphologies. In contrast, T2R outputs versatile reward functions in Python code. It generates a *single* reward function per iteration, checks for improvement from the previous one, and repeats this process, hence performing a greedy search over iterations.

Eureka (Ma et al., ) further extends T2R by generating *multiple* reward functions and *greedily* iterating with the best reward function and discarding the rest. This means that by definition (Lehman et al., ), Eureka does not qualify as an EA since it lacks crucial features. Namely, maintaining and evolving a population of candidates and employing genetic operators like mutation, crossover, and selection. Eureka only mutates the best candidate and discards the rest. In contrast, REvolve is truly evolutionary, i.e., population-based and using the full range of genetic operators. By preserving genetic diversity, REvolve avoids the pitfalls of premature convergence without incurring additional costs (since both frameworks generate the same number of candidates per generation). Empirically, we show that utilizing the full range of evolutionary operators yields reward functions that lead to better performing agents. Consequently, REvolve significantly outperforms greedy search methods like Eureka and T2R.

Evolutionary Algorithms with LLMs. Implementing EAs with LLMs has been explored in recent works in the context of neural architecture search (Nasir et al., ), program search (Romera-Paredes et al., ), prompt engineering (Guo et al., ; Fernando et al., ), as well as morphology design (Lehman et al., ). In this work, we propose a novel evolutionary framework for reward design with LLMs as intelligent genetic operators. Compared to the above-mentioned works, which feature limited evolutionary settings, REvolve incorporates a wide range of operations like mutation, crossover, selection, and migration.

## 5 Experiments

### 5.1 Experimental Setup

We performed experiments across three different environments: autonomous driving, humanoid locomotion, and adroit hand manipulation. For autonomous driving, we used the high-fidelity AirSim simulator (Shah et al., ). For humanoid locomotion (Tassa et al., ) and adroit hand manipulation (Rajeswaran et al., ), we used the MuJoCo simulator (Todorov et al., ). As a reward designer $G$, we used GPT-4 Turbo (1106-preview) model, which was provided (a subset of) observation and action variables originating from the simulators(^2^22To prevent potential plagiarism through context memory (Carlini et al., ), we use unique environment variable names and deliberately avoid mentioning the simulator in inputs to GPT-4.), as illustrated in Figure 1.
The reward designer is prompted to provide a reward taking the functional form $r=\sum_{i}r_{i}$. We call the $r_{i}$’s reward components and the reward designer decides on their individual functional form, as well as the number of reward components. This follows the protocol established by Ma et al. ().

### 5.2 Training Setup

**Table 1: Summary of observation and action spaces, along with objectives and termination criteria for the different RL training tasks.**
| Task | Observation Space | Action Space | Objective & Termination |
| --- | --- | --- | --- |
| Autonomous Driving | $\mathbb{R}^{307206}$ | discrete, $|A|=66$ | Navigate for 1000 steps |
| Humanoid Locomotion | $\mathbb{R}^{376}$ | continuous, $A\in\mathbb{R}^{17}$ | Run upright for 1000 steps |
| Adroit Hand Manipulation | $\mathbb{R}^{39}$ | continuous, $A\in\mathbb{R}^{30}$ | Open the door in 400 steps |

For the evolutionary search, we set the number of generations to $N=5$ and individuals per generation to $K=16$. This mimics the training setup of (Ma et al., ). The number of sub-populations was set to $I=13$, and the mutation probability was set to $p_{m}=0.5$.

For each generation, $16$ policies were trained (one per reward function).
In the AirSim environment, we trained Clipped Double Deep Q-Learning  (Fujimoto et al., ) agents for $5\times 10^{5}$ training steps per generation per agent. For the MuJoCo environments, we trained Soft Actor-Critic (Haarnoja et al., ) agents with $5\times 10^{6}$ steps per generation per agent.
We summarize the different RL tasks in Table 1 and provide detailed descriptions of the environments and RL setups in Appendix A.

Parallel training of a single generation on 16 NVIDIA A100 GPUs (40GB) consumed approximately 50 hours for the AirSim environment and 24 hours for the MuJoCo environments.
Due to these extensive computational demands, we report results using two random seeds.

In addition to REvolve (with human feedback), we also include a version in the experimental evaluation that we dub REvolve Auto.
Here, the human feedback is replaced with automatically generated feedback comprised of statistics on the reward components tracked during RL training.
Moreover, the fitness score, evaluating the individual agents, is computed using a manually designed fitness function. This fitness function measures an agent’s successful completion of the task at hand.
For instance, the fitness score for the humanoid locomotion task encodes that the agent should not fall over and that it should attain a high average velocity. We formally describe the fitness scores for the three different environments in Appendix B.2.
This automated feedback mechanism is adopted from (Ma et al., ).

### 5.3 Baselines

Expert Designed.
For autonomous driving, we used an expert reward function based on best practices established in the literature (Spryn et al., ). The total reward is calculated through a weighted aggregation of all the components, with the weights optimized via an exhaustive grid search conducted within the environments to find the reward function that produces the best policy. For humanoid locomotion and adroit hand manipulation, we used expert rewards provided by Gymnasium and Gymnasium-Robotics(^3^33[https://gymnasium.farama.org](https://gymnasium.farama.org),[https://robotics.farama.org](https://robotics.farama.org)), respectively. Details on the expert-designed reward functions can be found in Appendix C.

Eureka. We also compare REvolve to Eureka, cf. Section 4. Akin to REvolve, we employed the human fitness function to refine the best individual with natural language feedback. Henceforth, we denote it as Eureka.
We also include the original version of Eureka with automated feedback, which we denote by Eureka Auto. Training times are identical to the ones for REvolve.

Figure: Figure 3: We plot the fitness score – over 2 random seeds – of the best-performing policy per generation for autonomous driving (left), humanoid locomotion (middle), and adroit hand manipulation (right), cf. Table 1. Each plot also contains the fitness score obtained using an expert-designed reward function. The fitness score for the human driving in the autonomous driving setting (left) was obtained by observing the driving behavior of an expert human conducting driving sessions in a combined setting of AirSim and the high-fidelity Logitech driving simulator. We treat this as the upper limit of performance. We give the formal definitions of the fitness functions for each of the three environments in Equations 2, 3, and 4, respectively (in Appendix B.2).
Refer to caption: x2.png

### 5.4 Experimental Questions & Results

As shown in Figure 3, REvolve exhibits continuous improvement over successive generations, ultimately achieving a higher fitness score on the manually designed fitness scale. Furthermore, both REvolve and REvolve Auto outperform their Eureka counterparts, indicating that evolutionary search strategies yield better results than greedy search methods(^4^44Note that these results are not displayed on the human fitness scale because the Elo ranking system evaluates individuals relative to one another. Therefore, comparisons between individuals from different baselines are only feasible if we directly pair them against one another.). We also show that all methods outperform the Expert Designed reward function. Furthermore, we observe the benefit of providing human feedback, as both REvolve and Eureka with provided human feedback outperform their automatic feedback counterparts.

How does REvolve fair against the baselines?
We compare REvolve to the baselines using the task-specific fitness score described in Appendix B.2 and report the results in Figure 3.
We observe that REvolve (with human feedback) consistently outperforms the other methods across all three environments and is only beaten by the expert human driver in Autonomous Driving, cf. Figure 3 (left).
For the interested reader, we give the best (i.e., fittest) REvolve-designed reward functions $R^{\ast}$ in Appendix G.

We also note that in the Humanoid Locomotion and Adroit Hand tasks REvolve Auto (i.e., with automated feedback) performs on par with Eureka (with human feedback), despite the former’s evolutionary setting. This could be attributed to the limited and sparse nature of automated feedback (velocity for humanoid, steps to succeed for adroit hand) in contrast to the more detailed human feedback in Eureka. In contrast, automated feedback in Autonomous Driving is dense and incorporates multiple factors like collision, speed, and distance (Appendix B.2) – leading to bigger improvements during the evolutionary search. This also highlights that the combination of evolutionary search and human feedback is crucial for optimizing reward functions.

**Table 2: The table shows the best policies $\pi^{\ast}$ from each framework ranked based on human preferences for each environment. Specifically, we use rollouts from the best policies of each framework and gather human preferences on the paired rollouts, as described in Section 3.3. Then, we use the Elo rating system to map preferences to scores. All policies are initially assigned an Elo score of 1500.**
| Environment | Rank | Baseline | Elo Score |
| --- | --- | --- | --- |
| Autonomous Driving | 1 | Human Driving | 1586 |
|  | 2 | REvolve | 1575 |
|  | 3 | REvolve Auto | 1529 |
|  | 4 | Eureka | 1499 |
|  | 5 | Eureka Auto | 1411 |
|  | 6 | Expert Designed | 1397 |
| Humanoid Locomotion | 1 | REvolve | 1586 |
|  | 2 | Eureka | 1557 |
|  | 3 | REvolve Auto | 1514 |
|  | 4 | Eureka Auto | 1434 |
|  | 5 | Expert Designed | 1407 |
| Adroit Hand Manipulation | 1 | REvolve | 1594 |
|  | 2 | REvolve Auto | 1524 |
|  | 3 | Eureka | 1522 |
|  | 4 | Eureka Auto | 1443 |
|  | 5 | Expert Designed | 1415 |

How do humans judge REvolve policies?
We further compared REvolve and Eureka on human evaluations. To this end, we generated roll-outs from the best performing policies ($\pi^{\ast}$) from REvolve and Eureka. We paired them against each other and used the user feedback interface (Figure 1) for collecting preference data. This data was subsequently passed through an Elo rating system to rank each behavior, cf. Appendix B.1. As shown in Table 2, REvolve policies again outperform Eureka policies across all three tasks, and it is only the human expert driver beating REvolve in Autonomous Driving.

We have submitted example rollout videos as part of the supplementary material.

### 5.5 Ablation Studies

Figure: Figure 4: Comparison of REvolve’s performance on Autonomous Driving using mutation only, crossover only, and both combined.

**Table 3: Table shows the generalization scores in unseen AirSim environments. Fitness denotes manually designed fitness scores (mean ± std). Env 1 & Env 2 have 1500 & 1000 episodic steps, respectively.**
| Env | Baseline | Fitness | Episodic Steps |
| --- | --- | --- | --- |
| 1 | Expert Designed | 0.71 ± 0.03 | 710 ± 199 |
| Human Driving | 0.95 ± 0.02 | 1500 ± 0 |  |
| REvolve | 0.86 ± 0.03 | 1146 ± 297 |  |
|  | Eureka | 0.73 ± 0.04 | 759 ± 167 |
| 2 | Expert Designed | 0.48 ± 0.02 | 71 ± 22 |
| Human Driving | 0.75 ± 0.04 | 1000 ± 0 |  |
| REvolve | 0.68 ± 0.04 | 135 ± 31 |  |
|  | Eureka | 0.57 ± 0.05 | 99 ± 28 |

?

?

?

How do different genetic operators impact overall performance?
We evaluated REvolve’s performance in Autonomous Driving by running evolution search with three setups: using only mutation, only crossover, and the combination of both. As shown in Figure 4, REvolve with mutation & crossover outperforms REvolve with only crossover, which in turn outperforms REvolve with just mutation.

Do REvolve-designed reward functions generalize to new environments?
Aside from our standard Autonomous Driving environment (seen in Figure 5), we assessed the generalizability of the best REvolve-designed reward functions $R^{\ast}$ in two new (AirSim) environments. Specifically, we trained policies from scratch using $R^{\ast}$ in two new scenarios: (Env 1) featuring lanes and a completely altered landscape while maintaining similar traffic conditions as our standard environment, and (Env 2) characterized by increased traffic with multiple cars actively maneuvering.
From Table 3, we observe that in both environments, REvolve outperforms Eureka and expert-designed rewards. However, the generalizability was lower for Env 2. This issue may stem from the temporal processing limitations of the RL policy’s visual module, which sometimes fails to detect oncoming cars. Implementing more advanced models could enhance detection capabilities Hazra et al. (). Figure 6 provides visual representations of these environments, while Figure 13 provides episodic steps on the Y-axis over total steps on the X-axis during training for both generalization environments. We did not conduct similar experiments on the MuJoCo simulator, as the Humanoid and Adroit Hand environments are limited to only a single variant.

### 5.6 Limitations

As stated in Section 5.2, due to its (deep) RL nature, training multiple policies is rather computationally expensive and time-consuming.
That said, the computational cost of REvolve is the same as for Eureka – with no resources wasted on discarding individuals – REvolve does incur a slightly higher storage cost due to the maintenance of the reward database (see Appendix D). Another limitation of REvolve is its reliance on the closed source GPT-4 model. This was a necessary choice as existing works have shown that a considerable gap exists in reward design abilities between GPT-4 and open-source LLMs (Xie et al., ; Ma et al., ). With rapid advancements made by the open-source community, we believe this gap will be bridged in the near future.

## 6 Conclusion & Future Work

We formulated the RDP as a search problem using evolutionary algorithms for searching through the space of reward functions (Section 2). With REvolve, we proposed a novel evolutionary framework that leverages human preferences as fitness scores to guide the search process and integrates LLMs as intelligent operators to refine outputs through natural language feedback (Section 3). Our results show that this evolutionary search-based framework considerably outperforms the state of the art across three different simulation environments.

A key future question for REvolve is its real-world applicability. One promising approach involves integrating REvolve with Sim2Real algorithms Allamaa et al. (); Hu et al. () by first learning a policy in simulation, using REvolve-designed rewards, and then transferring it to the real world. Recently, Ma et al. () have demonstrated that such an approach is viable for Eureka by tackling a quadruped balancing task on a physical robot. Moreover, our framework opens up opportunities for future research in Human-AI interaction. In particular, exploring the impact of more open-ended feedback from various perspectives, such as egocentric or third-person views.

## Ethics statement

During human feedback experiments, we engaged 10 human evaluators per generation, each assessing 20 pairs of videos. Participants were recruited on a volunteer basis and the preference learning task was clearly explained to them. We note that no personal data was collected, and participants were compensated fairly per institutional guidelines. Our study adhered to ethical standards, followed institutional guidelines, and did not involve any potential risks related to privacy, security, or discrimination.

## Reproducibility

In the Appendix, we provide extensive details on our experimental protocol. Specific details can be found in the respective sub-appendices as detailed below.
The reinforcement learning framework, including the algorithm, inputs, outputs, and hyperparameters, is outlined in Appendix A. The fitness functions are thoroughly discussed in Appendix B. The expert-designed rewards are explained in Appendix C. Detailed prompt examples for GPT-4 can be found in Appendix E. Finally, we list the best reward functions generated from REvolve in Appendix G. We will open-source our code shortly.

## Appendix

## Appendix A Reinforcement Learning Preliminaries

### A.1 Environments

#### A.1.1 Autonomous Driving

Autonomous Driving experiments were conducted in the Neighborhood and Coastline environments of the AirSim simulator, a high-fidelity simulator developed for autonomous vehicle research (Shah et al., ). This urban simulation includes static features such as parked cars and dynamic obstacles like cars and moving animals, enabling a thorough evaluation of the RL agent in varied scenarios.

Figure: Figure 5: AirSim simulator environment used for our autonomous driving experiments. The egocentric camera view displayed on the bottom left serves as the observations for the autonomous driving agent.
Refer to caption: extracted/5963846/images/env1.png

Figure: Figure 6: AirSim generalization environments used for assessing the generalizability of REvolve-designed reward functions. The left and right pictures visualize Env 1 and Env 2, respectively.
Refer to caption: extracted/5963846/images/generalization-envs.png

**Table 4: DDQN Hyperparameters used during training for all AirSim environments for the Autonomous Driving task.**
| Parameter | Value |
| --- | --- |
| Learning Rate | 0.00025 |
| Optimizer | Adam |
| Gamma | 0.99 |
| Epsilon Initial | 1 |
| Epsilon Min | 0.01 |
| Epsilon Decay | $1\times 10^{-3}$ |
| Batch Size | 32 |
| Tau | 0.0075 |
| Replay Buffer Size | 50000 |
| Alpha (PER) | 0.9 |
| Frequency Steps Update | 5 |
| Beta | 0.4 |
| Action Space Steering (Simulator) | [-0.8, 0.8] |
| Action Space Throttle (Simulator) | [0,1] |
| Action Space (Real steering) | [-32°, 32°] |
| Image Res. | $100\times 256\times 12$ |
| Conv Layers | 5 (16-256 Filters) |
| Dense Units after Flatten | $256->[128\times 2]->66$ |
| Sensor Input Dimensions | 6 (Yaw, Pitch, $V_{x}$, $V_{y}$, Speed, Steering) |

Observations. The observation space for the policy includes a combination of visual and sensor data. The visual input consists of images concatenated along the channel axis, resulting in dimensions of $100\times 256\times 12$. The sensor data includes readings from yaw, pitch, linear velocity in the x and y directions, speed, and steering angle. This structure allows the network to perceive temporal dynamics by integrating sequential frames into a single input tensor.

The input shape is $(100,256,12)$, and it outputs $66$ discrete Q-values. To capture temporal dynamics, frame stacking aggregates four consecutive frames $[fr_{1},fr_{2},fr_{3},fr_{4}]$ along the channel dimension into a single state. For subsequent states, the oldest frame is replaced by a new one, resulting in an updated stack $[fr_{2},fr_{3},fr_{4},fr_{\text{new}}]$.

Action Space. The action space for the autonomous car is a 2D vector – the first dimension represents the discrete steering angles in the range $[-32^{\circ},32^{\circ}]$ in $2^{\circ}$ increments, the second dimension is a throttling option $\{0,1\}$. This results in $66$ possible actions.

Objective. The agent’s task is to navigate an urban environment for 1000 consecutive time steps, maintaining safe driving behavior by balancing speed and avoiding collisions.

Termination. The episode successfully terminates when the agent achieves the objective. Alternatively, collisions or exceeding speed limits will also prematurely end the episode.

Training Algorithm. Due to the high dimensional observation space and convergence time, we adopted the Clipped Double Deep Q-Learning approach (Fujimoto et al., ), a refined version of Double Q-Learning (Van Hasselt et al., ). This method uses two separate neural networks to reduce overestimation bias by calculating the minimum of the two estimated Q-values, thus providing more reliable and stable training outcomes.

In addition to Clipped Double Deep Q-Learning, our framework integrates the Dueling Architecture (Wang et al., ), which improves the estimation of state values by decomposing the Q-function into two streams: one that estimates the state value and another that calculates the advantages of each action. Such structure allows the model to learn which states are valuable without the need to learn each action effect for each state.

Furthermore, we utilize Prioritized Experience Replay (PER) (Schaul et al., ) to focus on significant learning experiences. PER prioritizes transitions with higher Temporal Difference errors for replay, which accelerates learning and increases the efficiency of the memory used during training. Table 4 lists the RL model hyperparameters. Finally, inspired by foundational research, we have adapted our architecture to incorporate vision-based methods and the Dueling Architecture from Mnih et al. () and Wang et al. (), enhancing temporal dynamics and action-value precision.

Figure: Figure 7: Humanoid Locomotion: A bipedal locomotion task where a simulated humanoid robot must maintain balance and walk as fast as possible (along the x-axis).
Refer to caption: extracted/5963846/images/humanoid.png

#### A.1.2 Humanoid Locomotion

The Humanoid Locomotion environment is a complex bipedal locomotion task within the MuJoCo simulator (Todorov et al., ).

Observations. The observation space for the humanoid environment includes joint positions, joint velocities, and other information such as the center of mass and contact forces. The data is crucial for controlling balance and forward locomotion. The observation shape is a $376$D vector, representing the state of the humanoid at each timestep (Tassa et al., ).

Action Space. The action space is a $17$D continuous vector representing the torques applied to the humanoid’s joints, including those in the abdomen, hips, knees, shoulders, and elbows. This allows finer control of walking or running movements.

Objective. The goal is to walk or run forward without falling.

Termination. The episode ends either when the humanoid falls or $1000$ consecutive time steps have passed without falling (success).

Training Algorithm. We employed the Soft Actor-Critic (SAC) algorithm (Haarnoja et al., ), utilizing the implementation provided by the Stable Baselines3 (SB3) library (Raffin et al., ). SAC is an off-policy actor-critic method that optimizes a stochastic policy in an entropy-regularized reinforcement learning framework. By maximizing a trade-off between expected return and policy entropy, SAC encourages exploration and prevents premature convergence to suboptimal policies, making it well-suited for high-dimensional continuous action spaces characteristic of MuJoCo tasks.

We leveraged the default hyperparameters provided by SB3 for SAC, which have been empirically validated across various environments. Key hyperparameters included a learning rate of $3\times 10^{-4}$, a batch size of $256$, a discount factor ($\gamma$) of $0.99$, and an entropy coefficient ($\alpha$) automatically adjusted during training. The policy network employed the MlpPolicy architecture from SB3, consisting of multilayer perceptrons designed to process the high-dimensional state observations in MuJoCo environments effectively.

#### A.1.3 Adroit Hand

The Adroit Hand environment is another MuJoCo simulation task, which concerns dexterous robotic manipulation (Rajeswaran et al., ).

Observations. The observation space in the adroit hand environment consists of a $97$D vector. It includes joint positions for the hand, latch position, door position (hinge rotation), palm position, handle position, and the relative position between the palm and the handle. Additionally, the space contains joint velocities and forces acting on the hand. The binary door open indicator is also included to signify whether the door is fully opened or closed.

Action Space. The action space is a $30$D continuous vector that controls the absolute angular positions of the joints in the hand and arm. This enables dexterous manipulation tasks like unlatching and swinging open a door.

Objective. The agent’s goal is to manipulate the door latch and open the door, overcoming friction and bias torque forces.

Termination. The episode ends when the door is successfully opened or $400$ consecutive time steps have passed without opening (fail).

Training Algorithm. Same as humanoid locomotion.

## Appendix B Fitness Functions

In this section, we provide details of (1) REvolve fitness function based on human evaluations, and (2) the automatic feedback (Auto) approach proposed in Eureka.

### B.1 REvolve Fitness

As stated in Section 3.3, REvolve employs a user interface to gather human feedback on behavior $t$ sampled from a trained policy. Human evaluators review pairs of videos, submitting their preferences. A fitness function then maps this data to a real-valued fitness score and a natural language feedback i.e. $(\sigma,\lambda)\coloneqq F(t)$. We start by introducing the Elo rating system that maps the preference data to a fitness score. For two reward function individuals $A$ and $B$ with fitness scores $\sigma_{A}$ and $\sigma_{B}$ respectively, the expected scores $E_{A}$ and $E_{B}$ are calculated using the logistic function:

$$ $E_{A}=\frac{1}{1+10^{(\sigma_{B}-\sigma_{A})/400}}\;\;\;\;\;\;\;\;E_{B}=\frac{ 1}{1+10^{(\sigma_{A}-\sigma_{B})/400}}$ $$

We then update the individual fitness based on the expected scores.

$$ $\sigma_{A}=\sigma_{A}+K\cdot(f(A,B)-E_{A})$ $$

$f(\text{X, Y})$ be defined as:

$$ $f(\text{X, Y})=\begin{cases}1&\text{if the X wins against Y},\\ 0&\text{if the X loses to Y},\\ 0.5&\text{if the match results in a tie}.\end{cases}$ $$

Here, $K=32$ determines the magnitude of fitness change. Intuitively, if higher-ranked individuals lose to those with lower rankings, they incur a more significant penalty, while the reverse scenario leads to a greater increase for the lower-ranked individual. Conversely, when two similarly ranked individuals compete, the change in fitness scores resulting from a win or loss is smaller. All individuals start with an initial rating of $1500$.

For the natural language feedback $\lambda$, the checkboxes selected by evaluators – indicating aspects of the behavior that are satisfactory or require improvement – are stitched together using a natural language (NL) template. This final string serves as input for GPT-4.

The process greatly simplifies the feedback interface, as participants only need to choose their preferred video from a pair rather than providing an absolute rating. Additionally, this method reduces individual biases that could emerge from various factors, such as the need to adjust ratings at different stages of evolution – from the initial phase, where many policies underperform, to later stages, when performances improve. To overcome this, we compare individuals not only within the same generation but also across different generations, updating the fitness scores of all individuals at the end of each generation(^5^55This approach is akin to comparing chess grandmasters Gary Kasparov and Magnus Carlsen, each a dominant player in his respective era. However, a direct comparison would require them to be matched in their primes; otherwise, the basis of comparison would be skewed and unjustified.). In direct rating-based systems, participants must repeatedly rate all generations, adjusting their scales each time. In contrast, our preference-based rating system allows us to efficiently utilize all existing preference data across generations to assign new fitness scores, thus requiring minimal data collection for the current generation.

### B.2 Automatic Feedback

##### Autonomous Driving.

The fitness function is primarily designed to evaluate the performance of an autonomous vehicle by assessing its behavior in speed regulation, path following, and collision occurrences. It assesses how well the vehicle adheres to speed regulations and how accurately it follows its designated waypoints while penalizing collisions and any deviations from critical operational thresholds.
The function is structured as follows:

$$ $\displaystyle\sigma=\begin{cases}\text{collision penalty},&\text{if collision occurs}\\ \text{speed penalty},&\text{if }v<v_{\text{min_limit}}\text{ or }v>v_{\text{ max_limit}}\\ \text{distance penalty},&\text{if }d>d_{\text{fail}}\\ \text{score}(v,d),&\text{otherwise,}\end{cases}$ (2) $$

where $v_{\text{adj_min}}=v_{\text{min}}-v_{\text{threshold}},\quad v_{\text{adj_
max}}=v_{\text{max}}+v_{\text{th}}$, with $v_{\text{th}}$ small threshold speed allowing for small deviations from the target speed range.

Here, penalties are assigned for: collision penalty$=-1$ for collisions; speed penalty is calculated based on the deviation from the adjusted range $[v_{\text{adjusted_min}},v_{\text{adjusted_max}}]$, decreasing as the speed moves further away from this range, with the speed score set to 0 if the speed is less than $v_{\text{min_limit}}$ or greater than $v_{\text{max_limit}}$; and distance penalty decreases as the vehicle moves further from the intended waypoint, with the distance score set to 0 if the deviation is above $d_{\text{fail}}$. Otherwise, the agent receives a $\text{score}(v,d)=\frac{\text{speed score}(v)+\text{distance score}(d)}{2}$.

The speed score is calculated as:

$$ $\text{speed score}(v)=\begin{cases}1,&\text{if }v_{\text{adj_min}}\leq v\leq v _{\text{max}}\\ \max(0,1-\frac{\min(|v-v_{\text{adj_min}}|,|v-v_{\text{adj_max}}|)}{v_{\text {adj_max}}-v_{\text{adj_min}}}),&\text{otherwise}\end{cases}$ $$

The speed range is $[8.0,11.5]$ m/s. The distance score is calculated as:

$$ $\text{distance score}(d)=\begin{cases}1,&\text{if }d\leq d_{\text{max}}\\ \max(0,1-\frac{d-d_{\text{max}}}{d_{\text{max}}}),&\text{otherwise}\end{cases}$ $$

with $d_{max}=0.5$m being the maximum tolerance for deviation from the waypoint. Both functions are shown in Figure 9. In Table 5, we summarize the fitness function components used for evaluating RL models.

**Table 5: Fitness Function Hyperparameters used for calculating the fitness score for AirSim environment for Autonomous Driving task.**
| Hyperparameter | Description | Value |
| --- | --- | --- |
| collision_penalty | Collision penalty | -1 |
| $v_{\text{min}}$ | Minimum speed target | 9.0 m/s |
| $v_{\text{max}}$ | Maximum speed target | 10.5 m/s |
| $v_{\text{min_limit}}$ | Minimum penalty limit | 2.5 m/s |
| $v_{\text{max_limit}}$ | Maximum penalty limit | 15 m/s |
| $v_{\text{adjusted_min}}$ | Adjusted minimum speed | 8 m/s |
| $v_{\text{adjusted_max}}$ | Adjusted maximum speed | 11.5 m/s |
| $v_{{}_{th}}$ | Threshold Speed | 1 m/s |
| $d_{\text{max}}$ | Waypoint deviation tolerance | 0.5 m |
| $d_{\text{fail}}$ | Maximum tolerance for deviation from the waypoint | 4 m |

Figure: Figure 9: Visual representation of speed and distance fitness scores for autonomous driving in the AirSim environment.
Refer to caption: extracted/5963846/images/Speed_Fitness_Plot.png

##### Humanoid Locomotion.

The fitness function for the Humanoid environment evaluates the agent based on its ability to maintain forward locomotion without falling over an episode of $T_{\text{max}}=1000$ steps.

$$ $\displaystyle\sigma=\begin{cases}\frac{1}{T_{\text{max}}}\sum_{t=1}^{T_{\text{ max}}}v_{t}^{x},&\text{if }T=T_{\text{max}}\\ 0,&\text{if }T<T_{\text{max}}\end{cases}$ (3) $$

where, $v_{t}^{x}$ is the forward velocity along the x-axis at time step $t$. $T$ is the total number of steps the agent remained upright. This function rewards agents that achieve higher forward velocities while also surviving the entire episode.

##### Adroit Hand.

The fitness function for the Adroit Hand environment rewards agents based on the number of steps taken to successful task completion. As shown in Figure 10, completing the task in fewer steps results in a higher fitness score $\in[0.5,1.0]$. If the task is not completed, the fitness score is 0 0.

Let $steps$ be the number of steps taken to complete the task ($50\leq steps\leq 400$), $T_{\text{min}}=50$ be the minimum possible steps, $T_{\text{max}}=400$ be the maximum allowed steps, $a=-\dfrac{1}{700}$, $b=\dfrac{75}{70}$ are constants defining the linear relationship. The fitness score $\sigma$ is defined as:

$$ $\displaystyle\sigma=\begin{cases}a\times steps+b,&\text{if the task is successfully completed}\\ 0,&\text{if the task is not completed}\end{cases}$ (4) $$

This score measures the efficiency of the Adroit Hand in completing the task, awarding a perfect score of 1 for completing it in 50 steps or fewer, with a linear decrease to 0.5 for completing the task in the maximum allowable 400 steps, and a score of 0 if the task is not completed.

Figure: Figure 10: Visual representation of fitness score for Adroit Hand when completing the task.
Refer to caption: x4.png

##### Feedback.

Following Eureka, we track the statistics of all reward components at intermediate policy checkpoints throughout training. We refer the interested reader to the original paper (Ma et al., ).

## Appendix C Expert Designed Rewards

### C.1 Autonomous Driving

Following the methodologies advocated in Spryn et al. (), the total reward at each time step, $R_{\text{total}}$, is constructed from a weighted sum of speed consistency, smooth navigation, and collision avoidance behavior of the agent. In what follows, we describe how the weights were calculated.

**Table 6: Grid Search Weights: Values and Corresponding Fitness Scores. The quadruple of weights yielding the highest fitness score is highlighted in bold.**
| c_pos | c_sm | c_speed | c_sensor | Fitness Score |
| --- | --- | --- | --- | --- |
| 0.85 | 0.46 | 0.5 | 0.53 | 0.496 |
| 0.25 | 0.25 | 0.25 | 0.25 | 0.603 |
| 0.81 | 0.83 | 0.33 | 0.13 | 0.606 |
| 0.35 | 0.67 | 0.7 | 0.67 | 0.576 |
| 0.57 | 0.26 | 0.57 | 0.27 | 0.396 |
| 0.22 | 0.16 | 0.24 | 0.85 | 0.556 |
| 0.67 | 0.3 | 0.78 | 0.77 | 0.549 |
| 0.45 | 0.11 | 0.27 | 0.24 | 0.256 |
| 0.72 | 0.93 | 0.74 | 0.65 | 0.415 |
| 0.63 | 0.4 | 0.39 | 0.78 | 0.284 |
| 0.44 | 0.76 | 0.98 | 0.48 | 0.653 |
| 0.28 | 0.64 | 0.2 | 0.92 | 0.602 |
| 0.12 | 0.52 | 0.91 | 0.41 | 0.592 |
| 0.94 | 0.86 | 0.85 | 0.2 | 0.571 |
| 0.51 | 1.0 | 0.64 | 0.34 | 0.630 |
| 0.98 | 0.56 | 0.12 | 0.95 | 0.600 |
| 0.88 | 0.38 | 0.46 | 0.59 | 0.591 |

**Table 7: Hyperparameters used in all reward components designed by Expert in AirSim in Autonomous Driving task.**
| Hyperparameter | Description | Value |
| --- | --- | --- |
| $\delta$ | Position reward decay factor | 0.2 |
| $\beta$ | Position reward bias | 0.25 |
| $v_{\text{min}}$ | Minimum target speed | 9 m/s |
| $v_{\text{max}}$ | Maximum target speed | 10.5 m/s |
| $dis_{safe}$ | Safe distance threshold | 6 m |
| $\gamma$ | Smoothness penalty coefficient | 0.5 |

##### Human Expert Designed (HED):

Utilizes a combination of position, speed, sensor, and smoothness rewards.

$$ $r_{\text{total}}^{\text{HED}}=c_{\text{pos}}\times r_{\text{pos}}+c_{\text{sm} }\times r_{\text{sm}}+c_{\text{speed}}\times r_{\text{speed}}+c_{\text{sensor} }\times r_{\text{sensor}}$ $$

###### Position Reward:

Encourages the vehicle to stay close to the target position, rewarding proximity to the desired path or waypoint.

$$ $r_{\text{pos}}=e^{-\delta\times((\text{min_pos})^{2}-\beta)}$ $$

###### Speed Reward:

Promotes maintaining an optimal speed. It penalizes the vehicle if it moves too slowly or too quickly, encouraging it to stay within a specified speed range.

$$ $r_{\text{speed}}=\begin{cases}-\frac{|\text{speed}-v_{\text{min}}|}{v_{\text{ min}}}&\text{if speed}<v_{\text{min}}\\ -\frac{|\text{speed}-v_{\text{max}}|}{\text{speed}}&\text{if speed}>v_{\text{ max}}\\ 1&\text{otherwise}\end{cases}$ $$

###### Sensor Reward:

Encourages the vehicle to maintain a safe distance from obstacles using sensor data. If the distance measured by the sensor is less than a safe threshold, it applies a penalty. The sensor measures the distance from the vehicle to nearby front objects.

$$ $r_{\text{sensor}}=\begin{cases}-\frac{(dis_{\text{safe}}-\text{distance})}{dis _{\text{safe}}}&\text{if distance}<dis_{\text{safe}}\\ 0.5&\text{otherwise}\end{cases}$ $$

###### Smoothness Reward:

Penalizes abrupt changes in steering to encourage smooth driving. It uses the standard deviation of the last four steering actions to measure smoothness.

$$ $r_{\text{sm}}=-\gamma\times\text{std(action_list)}$ $$

##### Human Expert Designed Tuned (HEDT):

We used grid search to optimize the values of the hyperparameters $c_{\text{pos}},c_{\text{sm}},c_{\text{speed}},c_{\text{sensor}}$.

$$ $r_{\text{total}}^{\text{HEDT}}=c_{\text{pos}}^{opt}\times r_{\text{pos}}+c_{ \text{sm}}^{opt}\times r_{\text{sm}}+c_{\text{speed}}^{opt}\times r_{\text{ speed}}+c_{\text{sensor}}^{opt}\times r_{\text{sensor}}$ $$

These configurations allow for tailored training of autonomous driving agents, emphasizing different aspects of driving performance based on specific needs and expected driving conditions. All configurations use weights of $c_{\text{pos}},c_{\text{sm}},c_{\text{speed}},c_{\text{sensor}}=0.25$, except for the optimized version which uses customized weights.

### C.2 Humanoid Locomotion

In the humanoid environment, the agent is tasked with moving forward while maintaining a healthy state. The reward function is designed to encourage forward movement, staying upright, and minimizing control effort. The total reward $R$ is computed as:

$$ $R=R_{\text{forward}}+R_{\text{healthy}}-R_{\text{control}}$ $$

Where:

- •
$R_{\text{forward}}=2.5\times w_{fwd}\times x_velocity$
This term provides a reward proportional to the agent’s forward velocity, incentivizing fast forward movement, with $w_{fwd}=1.25$.
- •
$R_{\text{healthy}}$ is a reward for maintaining a healthy state, where the agent’s height is within a predefined range:
$R_{\text{healthy}}=\begin{cases}15&\text{if the agent is healthy}\\
0&\text{if the agent is unhealthy}\end{cases}$
- •
$R_{\text{control}}=0.5\times w_{\text{ctrl}}\times\|\mathbf{\text{action}}\|_{
2}^{2}$
A penalty is applied based on the magnitude of the agent’s actions, discouraging excessive or inefficient control efforts with $w_{\text{ctrl}}=0.1$.

The total reward encourages the agent to move forward efficiently while staying upright and minimizing unnecessary control actions. The episode terminates if the agent becomes unhealthy (e.g., by falling) or after a maximum number of steps.

### C.3 Adroit Hand

In the Adroit Hand Environment, the agent’s task is to manipulate a door handle and open a door. The reward function is designed to incentivize both reaching the handle and successfully opening the door. The total reward $R$ is a combination of multiple components:

$$ $R=R_{\text{handle}}+R_{\text{door}}+R_{\text{velocity}}+R_{\text{bonus}}$ $$

Where:

- •
$R_{\text{handle}}=0.1\times\|\text{palm_pos}-\text{handle_pos}\|$
This term rewards the agent for minimizing the distance between its palm and the door handle.
- •
$R_{\text{door}}=-0.1\times(\text{goal_distance}-1.57)^{2}$
This component provides a reward for moving the door hinge closer to the desired goal position (typically when the door is open).
- •
$R_{\text{velocity}}=-1\times 10^{-5}\times\sum\text{qvel}^{2}$
A penalty is applied for excessive joint velocities (qvel), encouraging smooth and efficient movements.
- •
$R_{\text{bonus}}$ is a set of bonus rewards based on how much the door has been opened:
$R_{\text{bonus}}=\begin{cases}+2&\text{if }\text{goal_distance}>0.2\\
+8&\text{if }\text{goal_distance}>1.0\\
+10&\text{if }\text{goal_distance}>1.35\ (\text{goal achieved})\end{cases}$

The episode terminates when the door is successfully opened (i.e., $\text{goal_distance}>1.35$) or after 400 steps. A sparse reward version of the environment provides a reward of $+10$ for achieving the goal and $-0.1$ otherwise.

## Appendix D REvolve Cost Analysis & Comparisons

Figure: Figure 11: Comparison of REvolve with existing frameworks used to train autonomous driving agents. (a.) Expert Designed reward function $R$ to train the autonomous driving agent; (b.) learning from demonstrations (LfD) and learning from interventions (LfI), where the agent is trained to imitate the human; (c.) humans acting as reward functions within the training loop, by assessing policy rollouts and providing scalar rewards, which requires significant manual effort; (d.) Reinforcement learning from human feedback (RLHF), where human preference data is used to train an additional (black-box) reward model. This reward model is used as a proxy for human rewards to train the autonomous driving policy; (e) Proposed REvolve, which uses GPT-4 as a reward function generator $G$ and evolves them based on (minimal) human feedback on the rollouts sampled from the trained models. This feedback is directly incorporated into the reward design process. REvolve outputs interpretable reward functions, thereby avoiding learning an additional reward model. Here, $\pi\in\Pi$ is a trainable policy in the set of policies $\Pi$. The trainable blocks are denoted by the symbol of the flame.
Refer to caption: x5.png

Computation cost:
REvolve = Eureka. Both REvolve and Eureka output 16 reward functions and train 16 policies in each generation.

Data requirement:
RLHF $>>$ REvolve: RLHF requires massive amounts of curated data to train a reward model. Note that the input to a reward model is a video (rollout of a policy), and the output is a preference score, requiring a heavy neural model. As a reference, the common video classification model I3D trains on the Kinetics dataset, which has 650,000 video clips (Carreira & Zisserman, ).
IRL $>>$ REvolve: Similarly, Inverse Reinforcement Learning requires human demonstrations and interventions. In contrast, REvolve uses 10 human evaluators per generation, each assessing 20 data samples (video pairs) – hence, for 5 generations $10\times 20\times 5=1000$ curated samples only. Compare this to the Lyft self-driving dataset (Houston et al., ) used for motion prediction which has more than 1000 hours of data collected over 4 months by 20 cars.

Storage Cost:
REvolve $>$ Eureka. The slightly higher cost is due to maintaining a population of best candidates rather than one candidate like Eureka. However, compared to the LLM memory cost (e.g., the biggest open-source LLM Llama 3.1 takes up 810 GB of memory), the storage cost is negligible – for every generation, the storage increases by  2.5GB (which includes stored policy weights and other metadata) – 12.5 GB after 5 generations. Also, REvolve does not require expert feedback.

Comparison with existing approaches in Reinforcement Learning and Human Feedback Due to its complex and hard-to-specify goals (Knox et al., ), autonomous driving presents a challenging problem for reinforcement learning. Autonomous vehicles must maneuver through complex environments and interact with other road users, all the while strictly adhering to traffic regulations. Common techniques to overcome these challenges include learning from demonstrations (LfD) (Schaal, ) or learning from intervention (LfI) (Saunders et al., ). However, they do not always ensure that the learned behaviors align with human values such as safety, robustness, and efficiency (Hadfield-Menell et al., ). An alternative is integrating human feedback by using humans as the reward function in the learning process directly (Thomaz & Breazeal, ; Knox & Stone, ). However, this is rather resource-intensive as each rollout needs to be evaluated by a human. REvolve directly integrates human feedback (on the trained policy) into the reward design process. Instead of using humans as reward functions directly, human values, preferences, and knowledge can also be incorporated via so-called human-in-the-loop (HITL) RL. Several techniques exist, for instance, human assessment (Thomaz & Breazeal, ; Christiano et al., ; Knox & Stone, ), human demonstration (Schaal, ), and human intervention (Saunders et al., ; Wang et al., ).
They are particularly beneficial in scenarios like autonomous driving, where the reward function is challenging, and the nature of the desired outcome is complex. More recently, reinforcement learning from human feedback (RLHF) (Christiano et al., ; Rafailov et al., ) has been used successfully in training models like ChatGPT (OpenAI, ), providing guidance and alignment from user preferences. A further comparison of autonomous driving approaches with and human feedback is presented in Figure 11, which illustrates how REvolve uses human feedback to align learned policies with human driving standards without requirements for extra reward models, such as in the case of RLHF.

## Appendix E Prompts

Here, we present the different prompts used for GPT-4. It includes the following:

System Prompt Boxes E, E, E outline the system prompts (i.e. task description and expected input from the environment, complete with formatting tips to help guide GPT-4) for generating suitable reward functions for Autonomous Driving, Humanoid Locomotion, and Adroit Hand, respectively.

Abstracted Environment Variables Boxes E, E, E provides a list of (abstracted) observation and action variables in the environment, formatted as a Python class, for all three environments. This informs GPT-4 of variables it can use in reward design.

Operator Prompts like crossover (Box E) and mutation (Box E). Additionally, we provide prompts for REvolve Auto baseline (Boxes E, E).

## Appendix F Human Feedback Examples

## Appendix G Additional Results

### G.1 Best performing rewards

#### G.1.1 Autonomous Driving

In Box G.1.1, we present the best-performing reward from REvolve with a fitness score of $0.84$ for the AirSim environment. Similarly, Box G.1.1 displays the best-performing reward from REvolve Auto with a fitness score of $0.81$ for the same environment.

#### G.1.2 Humanoid Locomotion

In Box G.1.2, we present the best-performing reward from REvolve with an average velocity of $5.67$. In Box G.1.2, the best-performing reward from REvolve Auto has an average velocity of $4.71$.

#### G.1.3 Adroit Hand

”In Box G.1.3, we present the best-performing reward from REvolve with a fitness score of $0.81$. In Box G.1.3, the best-performing reward from REvolve Auto has a fitness score of $0.64$.”

Figure: Figure 12: Compares policy training with REvolve, REvolve Auto and expert-designed reward functions on episodic steps from the start of the training for the Autonomous Driving [Left] and Adroit Hand [Right]. Note, that episodic steps in Autonomous Driving denote how long an agent drives (i.e. higher is better). In contrast, episodic steps in Adroit Hand denote the number of steps the agent takes to solve the tasks (lower is better).
Refer to caption: x6.png

Figure: Figure 13: Episodic Steps during training for Env 1 [Left] and Env 2 scenario [Right].
Refer to caption: extracted/5963846/images/generation_2nd_exp_updated.png

Do REvolve reward functions lead to higher success rates?
In Figure 12, we see that REvolve-designed rewards converge to a higher number of episodic steps compared to expert-designed rewards, signifying a better success rate per episode – higher is better for Autonomous Driving and vice versa.

## Peer Reviews

confidence: 3
contribution: 2
initial_rating: 3
presentation: 4
questions: - The first sentence of the paper mentions "Recent success...", but the cited articles are from 2018 and 2019. Is that really considered recent?
- How long does the entire pipeline process take? Are there cases where the reward function does not converge due to difficulties in summarizing it from human-provided language feedback? I think this is an important issue because the pipeline proposed in this paper seems overly complex and involves a lot of uncertainties.
soundness: 3
strengths: - Well written, the technical approach is very clear, especially Figure 1 and Algorithm 1, which can help readers quickly understand the technical route of the paper.
- The experiments involve a wide range of task types, covering multiple dimensions of continuous and discrete action spaces and observation spaces for RL agents in virtual simulation environments.
- The authors have compared their work with a variety of baseline algorithms.
summary: This paper presents a framework that combines human feedback with genetic algorithms to guide LLMs in designing complex reward functions for agents. The authors conducted experiments on three tasks: Autonomous Driving, Humanoid Locomotion, and Adroit Hand Manipulation, and performed a comprehensive ablation study analysis.
weaknesses: The paper does not clearly describe the foundational setup of the experiments and the comparison metrics. In fact, I do not understand the role of the "fitness score" mentioned in the text. In sections 2 and 3, it is used as a supervisory signal to guide the genetic algorithm in generating the reward function. However, in section 4, it becomes an evaluation metric for the experimental results of the paper. I am unsure whether this practice is appropriate because it raises the following concerns:
- (1) If the fitness score can effectively measure the performance of agents in the current task, then why not use it directly as the reward function to train the agents?
- (2) If the fitness score serves as a signal to guide the generation of the reward function, is it fair to use it as an evaluation metric for the experiments? This is because the REsolve method receives fitness supervision during training, whereas other baseline methods do not.
The insights provided by the paper are limited. When the RLHF paradigm was introduced, people saw that using human feedback could enable agents to perform challenging actions like backflips, which are certainly beyond the capabilities of rule-based reward functions. However, in the tasks and experimental setup implemented in the paper, all I understand is that the authors have used very costly human feedback to achieve a performance superior to the baselines, without offering additional insights or analyses to justify the necessity of this approach.

---

confidence: 4
contribution: 3
initial_rating: 6
presentation: 4
questions: 1. What proportion of the LLM-generated reward functions were executable? Eureka mentioned many generated reward functions could not be executed.

2. Each human provides feedback consisting of a pairwise preference assessment and natural language feedback (extracted from a selection of checkboxes). This seems somewhat demanding. How important is each of these two components, relatively? Ablating either of the two components would have been informative.

3. Did authors try allowing humans to provide open-form natural language feedback, not constrained to a checklist?

4. Were the human evaluators for the policy’s final performance in Table 2 the same as the human evaluators that provided feedback during training? If so, I would take issue with that, because then the non-auto methods are given an unfair advantage over the auto methods since they were evaluated on the same distribution of human evaluators as during training.

5. During crossover, how are the “most effective” reward components determined? Through human natural language feedback?

6. Perhaps show an evaluation comparison as training proceeds through the N=5 generations. This would tell us whether REvolve consistently outperforms Eureka, or whether REvolve learns faster with increasing generation index.

7. What is the feasibility of REvolve on real robot tasks? Authors mentioned sim2real as a promising approach, but given the difficulty in simulating high DOF robots (such as humanoids), training on simulation data may not necessarily yield satisfactory results. However, only training with real data would be expensive with REvolve especially with the high demand on human feedback.
soundness: 3
strengths: 1. Paper is written very clearly and is easy to understand.

2. Results included good ablations that tested the effect of human ratings as fitness functions for both REvolve and Eureka.

3. Human evaluations were conducted and full Elo scores reported between REvolve, Eureka, and their respective ablations.

4. Appendix contained detailed experimental setup information.
summary: REvolve is an evolutionary algorithm for LLM reward function generation for RL tasks in robotics. Authors first point out that Eureka is not in fact an evolutionary algorithm (despite claiming to be so), because it does not preserve populations and do mutation and crossovers. REvolve takes Eureka and implements two main changes: make it an actual evolutionary algorithm, and use human labelers as a fitness function (instead of a manually-specified one as is done by Eureka). Authors demonstrate REvolve surpasses Eureka on 3 sim tasks: autonomous driving, humanoid locomotion, and adroit hand door opening.
weaknesses: 1. Natural language feedback to the LLM is extracted from a series of checkboxes that the user ticks. This requires a human to predefine the specific characteristics that the agent must exhibit, which may bias the prompting of the model by constraining the natural language feedback to this small discrete list of checkboxes. So while the authors argue that no manual engineering is required for providing the fitness function, there is manual engineering required to provide a good list of attributes for the human labelers to choose from, and it seems like these attributes must be tailored for each task.

2. A more in-depth analysis that would be helpful to the paper would try to quantify the total amount of human effort needed in REvolve vs Eureka auto: amount of time to define the natural language feedback checklist, provide all pairwise ratings and natural language feedback throughout training in REvolve, vs time to define a fitness function in Eureka. Since it requires hundreds of human labels over N=5 generations, I suspect REvolve involves much more human effort than Eureka auto, but the promising part of this work is that REvolve auto outperforms Eureka auto on all three tasks.

3. Presumably there is additional effort involved in REvolve vs Eureka, from a ML practitioner standpoint, in needing to tune additional parameters related to the mutation and crossover operations (such as p_m, or number of islands).

---

confidence: 3
contribution: 3
initial_rating: 6
presentation: 4
questions: (1) In Figure 3 (left), it seems auto grows faster than human feedback. In Figure 3 (right), auto grows exponentially but others grow linearly. What will happen given more generations? Will the auto surpass human feedback? I would suggest to run more generations to see a clear trend. 

(2) A follow up question for (1). If the auto surpass human feedback, or even human driving, would human evaluators still prefer human feedback to auto?

(3) To solve reward design problem, REvolve is a good solution for explicit reward function generation, but how does this method compare with implicit reward models, i.e., RLHF, in terms of performance, interpretability, computational requirements?
soundness: 3
strengths: REvolve uses the evolutionary algorithm with genetic operators like mutation, crossover, and selection to overcome the disadvantage in greedy search in Eureka and present good performance. 
REvolve leverages LLMs to generate reward function explicitly and employ human preference to guide the reward function generation implicitly, which enhances the interpretability and aligns with humans.
summary: This paper introduces a reward design framework. It proposes a fitness function that involves human feedback and natural language. It applies evolutionary algorithms to evolve a population of reward functions by LLMs, where the prompt is the output of the fitness function.
weaknesses: No major weaknesses under the topic of explicit reward function generation, but it lacks the discussion of the comparison to an implicit reward design, for example, a reward model from human preference.

Meta-review: This paper proposes a novel algorithm for tuning RL policies to optimize human preferences. Their framework uses an LLM to generate reward functions from natural language descriptions, and then uses genetic algorithms to mutate these functions to iteratively improve performance. Compared to the closest prior work, Eureka, there are two main contributions: (i) the "true" reward requires soliciting human feedback rather than running a simulator, and (ii) using genetic algorithms instead of a simpler greedy iterative refinement approach. While the novelty is somewhat limited, the contribution still appears sufficiently interesting to merit acceptance.

Decision: Accept (Poster)