GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning — part 4/4

Cleaned-text code points [46955, 56073). Bibliography omitted here; source.md includes it.

All MIPROv2 optimization runs are performed with the a ​ u ​ t ​ o = h ​ e ​ a ​ v ​ y auto=heavy setting, which corresponds to proposing 18 instruction candidates and 18 bootstrapped few-shot sets. Hence, across benchmarks, the exact number of rollouts varies depending on the number of trials it takes to bootstrap examples (finding 18 successful solution instances), the required number of Bayesian search steps (determined by the number of modules in the system), and size of the valset. Overall, MIPROv2’s rollouts ranged from a minimum of 2270 (for PUPA) to maximum of 6926 (for HoVer).

Trace and TextGrad ( Cheng et al., 2024 ; Yuksekgonul et al., 2025 ) : We implement both optimizers in the Trace framework. All programs under optimization have the exact same architecture compared to the DSPy implementation. To ensure a fair comparison, we port all the DSPy specific signature and parsing prompt to Trace, and use the same initial prompt. In addition, all the test, train, and validation data match exactly the experiment we used for GEPA. The performance of the unoptimized Trace program baseline closely matched our baseline implementation in DSPy (within 0.5% difference). All optimization experiments were under the same rollout budget as MIPROv2 and GEPA. We also provide both optimizer the same metric and feedback functions as GEPA, and, for the per-module feedback function that is not available in Trace (both optimizer do not support per-module feedback), we followed the feedback format in the BigBench-Hard tutorial 2 2 2 https://microsoft.github.io/Trace/examples/nlp/bigbench_hard.html from the Trace authors.

GRPO ( Shao et al., 2024 ) : Group Relative Policy Optimization (GRPO) is a reinforcement learning algorithm that estimates advantages in a group-relative manner. For compound AI systems consisting of multiple modules, we use the GRPO implementation provided and open-sourced by Ziems et al. (2025) to perform our experiments, whereas for single-module systems (e.g., figure 11 ), we use the GRPO implementation provided by SkyRL ( Griggs et al., 2025 ; Liu et al., 2025 ; Cao et al., 2025 ) .

Across all compound system training runs, each training step uses a group size of 12, with 4 training instances per step (total batch size 48, with per device train batch size 1). Training employs LoRA ( Hu et al., 2022 ) with rank dimension 16, α = 64 \alpha=64 , and dropout 0.05, using bf16 precision targeting the projection modules [ q , k , v , o , up , down , gate ] [\mathrm{q},\mathrm{k},\mathrm{v},\mathrm{o},\mathrm{up},\mathrm{down},\mathrm{gate}] . We use a learning rate of 1 × 10 − 5 1\times 10^{-5} , β = 0.01 \beta=0.01 , reward scale normalization, and gradient norm clipping of 0.1. Gradients are accumulated for 20 steps before each update, with a “constant with warmup learning” rate scheduler. Non-reentrant gradient checkpointing is enabled to further reduce memory usage. GRPO optimization run for 500 training steps, amounting to fixed 24,000 rollouts, with validation performed every 20 training steps, which is used to implement early stopping. Compound AI system GRPO training experiments are performed on 1xH100/A100 (80 GB memory) with separate GPUs for inference rollouts.

For single-module GRPO training, we adopt full-parameter finetuning with a group size of 16 16 . Each training step employs a global batch size of 32 32 , realized as per-device micro-batches of 4 4 across 8 8 GPUs. Rollout generation is performed with a per-GPU forward micro-batch size of 12 12 . Training is distributed using FSDP2 , with sampling performed at temperature 1.0 1.0 . We apply KL regularization and set the learning rate to 1 × 10 − 6 1\times 10^{-6} . Validation is conducted every 5 5 training steps. During evaluation, sampling is performed with temperature 0.6 0.6 , top- p = 0.95 p=0.95 , and top- k = 20 k=20 .

We manually explore several values for [LR, beta, norm clipping] hyperparameters for both training runs.

GEPA: GEPA is our optimizer, based on the algorithm described in Section 3 . We evaluate 2 variants of our main optimizer GEPA: GEPA and GEPA+Merge , along with 2 ablations created by replacing the Pareto-based sampling strategy with a naive, SelectBestCandidate strategy (SelectBestCandidate and SelectBestCandidate+Merge). All GEPA optimization runs use a minibatch size of 3, and merge is invoked a maximum of 5 times during the optimization run, when enabled. To ensure a fair comparison with MIPROv2, we align the computational budget between GEPA and MIPROv2 on a per-benchmark basis. The training set from each benchmark is used as D f ​ e ​ e ​ d ​ b ​ a ​ c ​ k D_{feedback} (which is used to derive the training signals, as discussed in Section 3 ) and the validation set is used as D p ​ a ​ r ​ e ​ t ​ o D_{pareto} . Specifically, since MIPROv2’s total rollout budget depends on factors such as validation set size and the number of modules, we first record the number of rollouts expended by MIPROv2 for each benchmark, and then cap GEPA’s optimization to match this rollout budget. While differences in proposal and validation procedures cause the exact budget usage by the systems to be slightly different, the discrepancy is always within 10.15%. This protocol ensures that any performance differences arise from the optimization algorithms themselves, rather than from differences in search budget. The exact rollout counts for each optimizer is visualized in Appendix G .

## Appendix F Results and Analysis (Contd.)

Figure 10 visualizes the final test set performance for aggregate and individual benchmarks across both models.

## Appendix G Performance vs. Budget (Rollouts) Curves

Figures 12 , 13 , 14 , 15 show the full Performance-vs-Rollout curves for all the optimizers across all benchmarks.

## Appendix H Generalization Gap

Figure 16 visualizes the generalization gap for different optimization methods.

## Appendix I Cost vs. Performance Analysis for optimized systems

The prompt size of the optimized system plays an important role in determining the downstream cost of using the optimized system. Figure 17 visualizes the aggregate prompt lengths of the final optimized system (as cost proxy) for each optimizer, against the performance achieved. Notably, GEPA’s prompts are around 33% shorter than MIPROv2’s prompts, while achieving higher performance.

## Appendix J GEPA Search Trees

Figures 19 , 20 , 21 , 22 , 23 , 24 , 25 , and 26 present the genetic search trees created by various configurations of GEPA (and ablation SelectBestCandidate).

## Appendix K Visualizing the Iterative Refinement achieved by GEPA

Figure 5 presented a summary of the prompt refinements performed by GEPA during the optimization for PUPA. In this section, we present the full prompts produced during the optimization.

### K.1 Prompts at intermediate stages for PUPA

## Appendix L Examples of best prompts for every benchmark

In this section, we present the best optimized prompt obtained for every (benchmark, model) configuration. Each subsection below pertains to one (benchmark, model) configuration. Since every compound AI system consists of multiple modules, each subsection consists of multiple boxes, listing the prompts for each module. MIPROv2 optimized prompts contain upto 4 few-shot examples for each task. We provide just the first demo here for brevity. GEPA’s prompts only consist of the optimized instruction, which is provided in full.

### L.1 HotpotQA, GPT-4.1 Mini

### L.2 HotpotQA, Qwen3 8B

### L.3 IFBench, GPT-4.1 Mini

### L.4 IFBench, Qwen3 8B

### L.5 HoVer, GPT-4.1 Mini

### L.6 HoVer, Qwen3 8B

### L.7 PUPA, GPT-4.1 Mini

### L.8 PUPA, Qwen3 8B

## Appendix M GEPA generated prompts for kernel generation

### M.1 NPUEval: Kernel Code Generation for new hardware architecture

Figure 27 shows the prompt generated by GEPA with GPT-4o for NPU Keernel Generation, that achieves 26.85% score with the same same GPT-4o agent, that achieved just 4.25% with a simple prompt.

### M.2 KernelBench: CUDA Kernel Code Generation for NVIDIA GPUs

## Appendix N Number of reflection LM calls made by GEPA during optimization

## Instructions for reporting errors

We are continuing to improve HTML versions of papers, and your feedback helps enhance accessibility and mobile support. To report errors in the HTML that will help us improve conversion and rendering, choose any of the methods listed below:

Click the "Report Issue" ( ) button, located in the page header.

Tip: You can select the relevant text first, to include it in your report.

Our team has already identified the following issues . We appreciate your time reviewing and reporting rendering errors we may not have found yet. Your efforts will help us improve the HTML versions for all readers, because disability should not be a barrier to accessing research. Thank you for your continued support in championing open access for all.

Have a free development cycle? Help support accessibility at arXiv! Our collaborators at LaTeXML maintain a list of packages that need conversion , and welcome developer contributions .