GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning Review

2026-05-11 18 분 소요

0. Introduction

GEPA는 “prompt optimizer가 RL을 이겼다”라는 기조로 읽으면 핵심을 놓친다. 이 논문이 진짜로 던지는 질문은 LLM을 downstream task에 적응시킬 때, 항상 weight update가 가장 좋은 학습 매체인가에 가깝다. GRPO 같은 RLVR 계열은 최종 reward를 scalar signal로 만들고, 많은 rollout을 통해 policy gradient를 추정한다. 반면 GEPA는 LLM이 만들어낸 reasoning trace, tool call, tool output, evaluator feedback 같은 언어 형태의 실행 로그 자체가 훨씬 밀도 높은 학습 신호일 수 있다고 본다.

이 관점은 agent/RAG/workflow 시스템을 다룰 때 특히 중요하다. 실제 production AI system은 단일 model call이 아니라, query rewriting, retrieval, summarization, answer generation, verification, privacy filtering 같은 여러 LLM module과 tool call이 이어진 compound AI system인 경우가 많다. 이때 실패 원인은 “최종 답이 틀렸다”는 scalar reward 하나로 설명되지 않는다. 어느 module이 잘못된 query를 만들었는지, 어떤 constraint를 빠뜨렸는지, 어떤 compiler error나 verifier message가 나왔는지까지 봐야 한다. GEPA는 이 정보를 prompt evolution의 재료로 쓴다.

논문 버전 기준으로는 arXiv v2이며, ICLR 2026 Oral로 accept된 technical paper다. v1 대비 evaluation이 확장되어, abstract에서는 six tasks 기준 GRPO 대비 평균 +6%, 최대 +20%, 최대 35x fewer rollouts를 보고한다. 본문에서는 Qwen3-8B와 GPT-4.1 Mini에서 HotpotQA, IFBench, HoVer, PUPA, AIME-2025, LiveBench-Math를 포함한 실험을 다룬다.

한 줄 요약: GEPA는 compound AI system의 prompt를 weight update 없이 최적화하기 위해, rollout/evaluation trace를 natural-language feedback으로 반사(reflection)하고, Pareto frontier 기반 candidate selection으로 다양한 “부분적으로 잘 먹히는 전략”을 유지하는 sample-efficient prompt evolution 방법이다.

이 논문을 지금 볼 가치가 있는 이유는 다음과 같음.

LLM post-training 담론이 RLVR 중심으로 가는 상황에서, weight-space RL이 항상 필요한가라는 반대축을 꽤 강하게 제시한다.
agent, RAG, tool-use pipeline처럼 여러 prompt와 module이 얽힌 시스템에서는 gradient보다 execution trace 기반 credit assignment가 더 실용적일 수 있다.
단순 prompt search가 아니라, reflective mutation, Pareto selection, system-aware merge를 묶어 prompt optimization을 하나의 optimization algorithm으로 정리한다.
closed-source API model이나 weight update가 어려운 production setting에서도 적용 가능한 방향이다.
성능 수치보다도, “어떤 feedback을 optimizer에 보여줘야 prompt가 실제로 좋아지는가”라는 feedback engineering 관점이 중요하다.

GEPA의 핵심 메시지는 다음과 같다. LLM이 실패한 과정을 언어로 설명할 수 있다면, 그 설명 자체가 gradient보다 sample-efficient한 learning signal이 될 수 있다. 물론 이 말이 RL을 대체한다는 뜻은 아니다. 다만 비용이 큰 rollout, closed model, modular workflow, rich evaluator feedback이 있는 환경에서는 prompt-space optimization이 weight-space optimization보다 훨씬 먼저 시도해볼 만한 레버라는 점을 꽤 설득력 있게 보여준다.

1. Problem Setting

1-1. Problem definition

이 논문이 다루는 대상은 compound AI system optimization이다. 여기서 compound AI system은 하나 이상의 LLM invocation과 external tool call이 조합된 modular system이다. 예를 들어 multi-hop QA system은 첫 번째 query writer, retriever, document summarizer, 두 번째 query writer, final answer generator로 나뉠 수 있다. privacy-aware delegation system은 private query rewriter, untrusted external model call, response rewriter로 구성될 수 있다.

형식적으로 보면 system $\Phi$는 module prompts $\Pi_\Phi$와 module weights $\Theta_\Phi$를 가진다. 일반 optimization problem에서는 prompt와 weight를 모두 learnable parameter로 볼 수 있다. 하지만 GEPA는 이 중 prompt set만 evolve하고, underlying LLM weight는 fixed로 둔다.

문제는 다음과 같이 정리할 수 있다.

입력 instance $(x, m)$이 있다.
$x$는 system input이고, $m$은 gold answer, rubric, unit test, privacy metadata 같은 evaluator metadata다.
system output $y = \Phi(x; \langle \Pi, \Theta \rangle_\Phi)$가 생성된다.
metric $\mu(y, m)$가 output quality를 0~1 score 등으로 평가한다.
rollout은 system execution + evaluation으로 구성되며, 비용이 크다.
제한된 rollout budget $B$ 안에서 held-out performance를 최대화하는 prompt configuration을 찾아야 한다.

즉 GEPA가 겨냥하는 문제는 “좋은 prompt를 자동으로 찾자”가 아니라, 비싼 rollout 하나하나에서 최대한 많은 학습 신호를 뽑아 compound AI system 전체를 개선하자에 가깝다.

1-2. Why previous approaches are insufficient

기존 접근은 크게 세 가지 축으로 볼 수 있다.

첫째, weight-space reinforcement learning이다. GRPO 같은 RLVR 방법은 final score를 scalar reward로 보고 policy update를 수행한다. 이 방식은 model weight를 직접 바꿀 수 있고 대량 rollout을 감당할 수 있을 때 강력하다. 하지만 agent/RAG pipeline에서는 rollout 하나가 API call, retrieval, verifier, tool execution, human feedback 등을 포함할 수 있어 비용이 높다. 또한 closed-source model을 쓰는 경우에는 weight update 자체가 불가능하다.

둘째, prompt optimizer 계열이다. MIPROv2처럼 instruction과 few-shot demonstration을 Bayesian optimization으로 찾는 방법은 prompt-level optimization을 체계화했다. 하지만 많은 경우 최종 global reward를 중심으로 search한다. 즉 “어떤 module이 왜 실패했는가”라는 rich trace를 충분히 활용하지 못할 수 있다.

셋째, textual feedback / reflection 계열이다. Reflexion, TextGrad, OptoPrime 같은 방향은 언어 feedback을 optimization signal로 쓰려 한다. GEPA도 이 계열에 가깝지만, 단순히 prompt를 반복 수정하는 데서 끝나지 않는다. 핵심은 candidate pool을 유지하고, instance-wise Pareto frontier를 사용해 local optimum에 빠지지 않도록 만드는 search strategy다.

기존 접근의 한계는 다음처럼 요약할 수 있다.

scalar reward만 쓰면 failure mode의 구조가 사라진다.
greedy하게 현재 best prompt만 고치면 prompt search가 한 lineage에 갇히기 쉽다.
few-shot demonstration을 많이 붙이면 성능은 좋아질 수 있지만 input token cost와 latency가 커진다.
module별 책임이 다른 compound system에서는 single global score만으로 credit assignment가 어렵다.
closed model / API model / constrained budget 환경에서는 weight-space RL이 실용적이지 않을 수 있다.

GEPA는 이 문제를 “학습 알고리즘”보다 학습 신호의 표현 형식 문제로 본다. 즉 reward를 숫자로만 압축하지 말고, evaluator가 이미 갖고 있는 natural-language diagnostic signal을 optimizer에게 그대로 보여주자는 것이다.

2. Core Idea

2-1. Main contribution

GEPA의 핵심 기여는 세 가지로 정리할 수 있다.

Reflective prompt mutation
GEPA는 system rollout에서 나온 execution trace와 evaluation trace를 모은다. 여기에 score와 feedback text를 붙여 reflection LM에게 보여주고, 특정 module prompt를 업데이트하게 한다. 이때 LLM은 단순 paraphrase가 아니라, 실패 원인을 해석하고 prompt 안에 high-level rule을 누적한다.
Pareto-based candidate selection
GEPA는 항상 global best candidate만 mutate하지 않는다. 대신 각 training instance에서 최고 score를 낸 candidate들을 모아 Pareto frontier를 만들고, dominated candidate를 제거한 뒤, 여러 instance에서 “이긴” candidate일수록 높은 확률로 sample한다. 이 구조는 local optimum을 피하고 다양한 strategy lineage를 유지하기 위한 장치다.
Genetic / system-aware evolution
prompt update는 ancestry를 가진 candidate tree로 쌓인다. 또한 GEPA+Merge에서는 서로 다른 module을 개선한 complementary lineage를 찾아 system-aware crossover를 수행한다. 즉 GEPA는 단일 prompt rewrite가 아니라, prompt set 전체를 evolving population으로 다룬다.

이 세 가지를 묶으면 GEPA는 다음과 같은 algorithm이다.

fixed LLM weights 위에 여러 prompt candidate를 둔다.
rollout을 돌려 score와 feedback text를 얻는다.
reflection으로 특정 module prompt를 mutate한다.
minibatch에서 개선되면 candidate pool에 추가한다.
validation/Pareto set에서 instance-wise 성능을 추적한다.
Pareto frontier 기반으로 다음 mutation candidate를 고른다.
필요하면 complementary lineage를 merge한다.

2-2. Design intuition

GEPA의 설계 직관은 꽤 명확하다. LLM system은 실패할 때 이미 많은 언어적 증거를 남긴다. reasoning trace가 있고, retrieved document가 있고, tool call 결과가 있고, compiler error가 있고, instruction-following benchmark에서는 어떤 constraint를 지켰고 어떤 constraint를 어겼는지 feedback이 있다. 이런 정보는 scalar reward보다 훨씬 풍부하다.

예를 들어 multi-hop retrieval에서 최종 답이 틀렸다는 reward 0만 보면 optimizer는 무엇을 고쳐야 할지 모른다. 하지만 evaluator가 “second-hop query가 first-hop summary의 entity를 반영하지 않았다”는 feedback을 주면, prompt에는 “second-hop query는 original question을 반복하지 말고 first-hop summary에서 새로 밝혀진 entity를 중심으로 작성하라”는 rule을 추가할 수 있다.

이것이 GEPA가 말하는 reflective prompt evolution의 핵심이다. LLM은 언어로 된 실패 설명을 읽고, 이를 다음 prompt에 declarative instruction으로 축적한다. 이 과정은 weight gradient처럼 미세한 parameter update가 아니라, task-specific rule을 prompt text에 직접 쓰는 큰 step update에 가깝다.

Pareto selection도 같은 맥락이다. 하나의 global best prompt는 전체 평균 점수는 좋을 수 있지만, 특정 instance 유형에서만 좋은 전략을 놓칠 수 있다. GEPA는 각 instance에서 잘한 candidate를 frontier에 남겨둔다. 그러면 “privacy leakage를 잘 줄이는 prompt”, “multi-hop retrieval query를 잘 만드는 prompt”, “output constraint를 잘 지키는 prompt” 같은 부분 전략이 search tree 안에서 사라지지 않는다.

내 해석은 이렇다. GEPA는 prompt optimization을 “문장 몇 개를 잘 고치는 작업”이 아니라, 언어화된 실패 분석을 population search에 누적하는 optimization problem으로 재정의한다.

3. Architecture / Method

3-1. Overview

Item	Description
Goal	제한된 rollout budget에서 compound AI system의 prompt set을 최적화
Core method	Genetic-Pareto prompt evolution
Updated parameter	Prompt set $\Pi_\Phi$; LLM weights $\Theta_\Phi$는 fixed
Main learning signal	score + execution trace + evaluation trace + feedback text
Candidate strategy	instance-wise Pareto frontier 기반 stochastic sampling
Mutation unit	compound system 안의 개별 LLM module prompt
Optional crossover	system-aware merge: complementary lineage의 module prompt를 조합
Main comparison	GRPO, MIPROv2, MIPROv2-No-Demos, Trace/OptoPrime, TextGrad, baseline
Evaluation tasks	HotpotQA, IFBench, HoVer, PUPA, AIME-2025, LiveBench-Math
Main models	Qwen3-8B, GPT-4.1 Mini

3-2. Module breakdown

1) Candidate pool and ancestry

GEPA는 base prompt set을 가진 initial candidate $P_0$에서 시작한다. 이후 각 iteration마다 기존 candidate 하나를 선택하고, 그 candidate에서 특정 module prompt를 업데이트해 새로운 candidate를 만든다. 새 candidate가 local minibatch에서 parent보다 좋아지면 candidate pool에 추가된다.

이때 GEPA는 단순히 prompt text만 저장하지 않는다. candidate의 ancestry도 추적한다. 어떤 parent에서 어떤 module이 어떻게 바뀌었는지를 tree 구조로 남긴다. 이 ancestry는 나중에 Merge를 할 때 중요해진다. 서로 다른 branch가 서로 다른 module을 개선했다면, 두 branch의 prompt를 조합할 수 있기 때문이다.

이 구조는 evolutionary search의 형태를 갖는다.

candidate = compound system의 prompt configuration
mutation = module-specific prompt rewrite
selection = Pareto frontier 기반 sampling
crossover = complementary lineage merge
fitness = task metric / validation score

단, 일반적인 genetic algorithm과 다른 점은 mutation operator가 random text edit이 아니라 LLM reflection 기반 prompt rewrite라는 점이다.

2) Reflective Prompt Mutation

GEPA의 mutation 과정은 다음처럼 동작한다.

Pareto frontier에서 candidate를 하나 sample한다.
업데이트할 module을 선택한다. 논문 기준으로는 round-robin policy가 사용된다.
feedback dataset에서 minibatch를 sample한다.
해당 candidate로 system rollout을 실행한다.
module input/output, reasoning trace, tool output, evaluator message를 수집한다.
feedback function $\mu_f$가 numeric score와 feedback_text를 반환한다.
reflection LM이 현재 prompt, trajectory, score, feedback을 보고 module prompt를 업데이트한다.
바뀐 prompt set으로 minibatch를 다시 평가한다.
local score가 개선되면 candidate pool에 추가하고, Pareto set 전체에서 score를 기록한다.

여기서 중요한 점은 feedback function이다. GEPA는 기존 metric $\mu$를 단순 score function으로만 쓰지 않고, score를 만드는 과정에서 생기는 textual trace를 함께 반환하는 함수 $\mu_f$ 로 확장한다. 예를 들어 code evaluation에서는 compiler error, failed unit test, profiling result가 feedback text가 된다. instruction-following task에서는 어떤 constraint를 만족했고 어떤 constraint를 위반했는지가 feedback이 된다. privacy task에서는 response quality와 PII leakage breakdown이 feedback이 된다.

이 feedback은 prompt rewrite에서 implicit credit assignment로 사용된다. LLM은 “어떤 module이 어떤 방식으로 실패했는가”를 언어적으로 추론하고, 그 module prompt에 구체적 rule을 추가한다.

3) Pareto-based Candidate Selection

GEPA가 특히 흥미로운 지점은 candidate selection이다. 가장 쉬운 전략은 현재 평균 점수가 가장 높은 candidate만 계속 mutate하는 것이다. 하지만 논문은 이 방식이 쉽게 local optimum에 빠진다고 본다. 한 번 좋은 strategy를 찾으면 optimizer가 그 branch만 계속 고치다가 rollout budget을 소모할 수 있다.

GEPA는 이를 피하기 위해 instance-wise Pareto frontier를 사용한다.

과정은 다음과 같다.

Pareto set의 각 task instance $i$에 대해, 지금까지 나온 candidate 중 최고 score를 찾는다.
각 instance에서 최고 score를 낸 candidate들을 모은다.
다른 candidate에 의해 strictly dominated되는 candidate를 제거한다.
남은 candidate 중 여러 instance에서 best로 등장한 candidate일수록 더 높은 확률로 sample한다.

이 전략의 의도는 명확하다. 평균 최고 candidate 하나만 보는 대신, 각 data point에서 발견된 winning strategy를 보존한다. 그러면 전체 평균은 아직 낮지만 특정 failure mode를 잘 해결한 candidate도 다음 mutation의 출발점이 될 수 있다.

내가 보기엔 이 부분이 GEPA의 가장 중요한 알고리즘적 장치다. Reflection만 있으면 “LLM이 자기 prompt를 고친다”는 이야기로 끝날 수 있다. Pareto selection이 들어오면서 GEPA는 실제로 exploration/exploitation trade-off를 다루는 optimizer가 된다.

4) Evaluation trace as diagnostic signal

GEPA는 execution trace뿐 아니라 evaluation trace도 중요하게 본다. 예를 들어 code generation task에서 최종 reward는 0일 수 있지만, compiler error message에는 어떤 type mismatch가 났는지, 어떤 API가 잘못 쓰였는지, 어떤 kernel constraint를 어겼는지가 들어 있다. 이 정보는 prompt update에 직접적으로 유용하다.

논문은 이를 feedback_text로 정식화한다. score가 계산되기 전에 evaluator가 생성하는 자연어/텍스트 로그를 버리지 않고, reflection LM에게 제공한다. 이 관점은 실무적으로 매우 중요하다. 많은 evaluation pipeline은 이미 rich diagnostic을 만들어내지만, 최종 metric만 logging하고 optimizer에는 넘기지 않는 경우가 많다. GEPA는 “metric을 잘 만들자”보다 한 단계 더 나아가, metric이 만들어지는 과정 자체를 optimizer input으로 쓰자고 말한다.

5) System-aware Merge

GEPA+Merge는 complementary lineage를 합치는 crossover 전략이다. 직관은 간단하다. compound system에는 여러 module이 있고, 서로 다른 candidate lineage가 서로 다른 module에서 좋은 prompt를 찾았을 수 있다. 예를 들어 한 lineage는 query writer를 잘 고쳤고, 다른 lineage는 final answer generator를 잘 고쳤다면, 두 prompt를 조합하는 것이 가능하다.

다만 Merge는 항상 좋은 것은 아니다. 논문은 GEPA+Merge가 GPT-4.1 Mini에서는 특히 잘 동작했지만, Qwen3-8B에서는 오히려 성능이 떨어지는 경우도 있었다고 보고한다. 저자들은 이를 mutation과 crossover 사이의 rollout budget allocation, merge invocation timing 문제로 해석한다.

따라서 Merge는 GEPA의 핵심 아이디어라기보다, candidate ancestry를 활용한 추가 search operator로 보는 편이 안전하다. 실무에서 가져간다면 먼저 reflective mutation + Pareto selection을 기본으로 두고, 충분히 다양한 lineage가 생긴 뒤에만 merge를 시도하는 식의 adaptive policy가 필요해 보인다.

4. Training / Data / Recipe

4-1. Data

GEPA에서 “training”은 neural network training이라기보다 optimizer가 접근할 수 있는 task instances와 feedback을 의미한다. 논문은 표준적인 train / validation / test split을 사용한다.

train split은 optimizer가 접근할 수 있다. prompt tuning을 위해 text와 label/metadata를 사용할 수 있다.
validation/Pareto set은 candidate selection과 tracking에 사용된다. 직접 content access는 제한된다.
test set은 optimization 중 접근하지 않고, 최종 evaluation에만 사용된다.

v2 기준 주요 benchmark는 여섯 가지다.

Benchmark	Task type	System / feedback 관점
HotpotQA	multi-hop QA	multi-hop retrieval/query generation과 final answer generation
IFBench	instruction following	output constraint 만족/불만족 feedback
HoVer	multi-hop fact verification	retrieved gold documents / missing documents feedback
PUPA	privacy-aware delegation	response quality와 PII leakage score breakdown
AIME-2025	math reasoning	prior-year AIME로 train/val, 2025 set test
LiveBench-Math	math reasoning	LiveBench math subset split

이 task 구성이 중요한 이유는 GEPA가 특정 benchmark 하나에 맞춘 prompt trick이 아니라, 서로 다른 feedback structure를 가진 compound system 전반에서 동작하는지를 보려 하기 때문이다.

4-2. Optimization strategy

GEPA는 model weight를 업데이트하지 않는다. 업데이트 대상은 prompt set이다. 그러나 optimizer 자체는 꽤 구체적인 recipe를 가진다.

D_feedback과 D_pareto를 나눈다.
D_feedback에서 minibatch를 뽑아 reflection mutation의 학습 신호를 만든다.
D_pareto는 candidate selection과 final candidate choice에 사용한다.
GEPA optimization run은 minibatch size 3을 사용한다.
Merge를 켠 경우, optimization run 중 최대 5번까지 invoke한다.
MIPROv2와 비교할 때는 rollout budget을 benchmark별로 맞춘다.
GRPO baseline은 compound system setting에서 24,000 rollouts를 사용한다.

모델은 크게 두 가지다.

Model	Role	Inference setting
Qwen3-8B	open-source model / GRPO 포함	temperature 0.6, top-p 0.95, top-k 20
GPT-4.1 Mini	closed commercial model	OpenAI API, temperature 1.0

Qwen3-8B에서는 GRPO와 비교가 가능하다. GPT-4.1 Mini는 weight update가 불가능한 closed-source API model에 가까우므로 prompt optimizer와의 비교가 핵심이다.

4-3. Engineering notes

이 논문에서 실무적으로 가져갈 만한 engineering note는 다음과 같다.

Feedback function을 metric과 분리하지 말 것
metric은 최종 score만 반환하지 말고, 실패 이유와 intermediate diagnostic을 함께 반환해야 한다. GEPA에서 가장 중요한 input은 score보다 feedback_text에 가깝다.
Candidate validation cost를 따로 추적할 것
GEPA의 rollout budget 상당 부분은 candidate validation에 쓰인다. 논문도 이를 sample efficiency 개선 여지로 지적한다. 실무에서는 full validation set이 아니라 dynamic subset, stratified subset, failure-heavy subset을 쓰는 식의 예산 관리가 필요하다.
Prompt diff와 ancestry를 저장할 것
GEPA는 prompt evolution tree를 만든다. 따라서 단순히 최종 prompt만 저장하면 안 된다. 어떤 feedback에서 어떤 rule이 추가됐고, 어떤 candidate가 어떤 instance에서 이겼는지 추적해야 나중에 debugging과 merge가 가능하다.
Module-level feedback schema를 설계할 것
compound system에서는 module별 책임이 다르다. query writer, summarizer, verifier, answer generator에 같은 feedback을 주면 credit assignment가 흐려진다. 가능하면 feedback을 module-specific하게 만들 필요가 있다.
Prompt length도 metric으로 볼 것
GEPA의 결과 중 흥미로운 점은 성능뿐 아니라 prompt compactness다. 논문은 GEPA/GEPA+Merge prompt가 MIPROv2 prompt보다 최대 9.2x 짧다고 보고한다. API cost와 latency를 고려하면 prompt optimizer의 output length도 중요한 system metric이다.

5. Evaluation

5-1. Main results

v2 기준 Qwen3-8B Table 1의 핵심 결과는 다음과 같다.

Optimizer	Aggregate	Improvement	Notes
Baseline	45.23	–	no optimization
GRPO	48.91	+3.68	24,000 rollouts
MIPROv2	47.84	+2.61	prompt optimizer
GEPA	54.85	+9.62	평균 3,936 rollout budget
GEPA+Merge	52.40	+7.17	Merge가 Qwen3-8B에서는 항상 이득은 아님

개별 task를 보면 GEPA는 HotpotQA, IFBench, HoVer, PUPA, LiveBench-Math에서 GRPO를 넘지만, AIME-2025에서는 GRPO가 더 높다. 이 점은 중요하다. “GEPA가 RL을 항상 이긴다”가 아니라, rich feedback을 활용할 수 있는 compound system에서는 매우 sample-efficient하고, 일부 math reasoning setting에서는 GRPO가 여전히 강할 수 있다로 읽는 편이 맞다.

GPT-4.1 Mini Table 2에서는 GEPA의 장점이 더 뚜렷하다.

Optimizer	Aggregate	Improvement	Notes
Baseline	53.03	–	no optimization
Trace / OptoPrime	56.30	+3.27	textual optimizer 계열
MIPROv2-No-Demos	57.14	+4.11	instruction-only
MIPROv2	58.67	+5.64	instruction + few-shot
TextGrad	59.14	+6.11	textual feedback optimization
GEPA	65.22	+12.19	strong prompt optimization
GEPA+Merge	66.36	+13.33	GPT-4.1 Mini에서는 Merge가 추가 이득
GEPA-Qwen-Opt	62.03	+9.00	Qwen3-8B에서 최적화한 prompt를 GPT-4.1 Mini에 transfer

특히 GEPA-Qwen-Opt 결과는 흥미롭다. Qwen3-8B로 최적화한 prompt가 GPT-4.1 Mini로 transfer되어 +9.00 aggregate improvement를 보였다. 이 결과는 GEPA가 단순히 특정 model의 quirks를 exploit하는 것이 아니라, 어느 정도 task-level declarative rule을 학습하고 있음을 시사한다.

Sample efficiency 관점에서는 다음 결과가 중요하다.

GEPA는 GRPO 24,000 rollouts 대비 최대 35x fewer rollouts를 사용한다.
6개 task 중 5개에서 GRPO를 넘고, 그 margin은 19.0%, 2.73%, 13.66%, 5.19%, 0.7%로 보고된다.
GRPO의 best validation score에 도달하는 데 필요한 rollout은 243, 402, 330, 1143, 1179, 306으로 보고되며, 최대 78x sample efficiency를 보인다.
다만 GEPA rollout budget 상당 부분은 learning signal 생성이 아니라 candidate validation에 쓰인다.

Ablation도 중요하다. Qwen3-8B의 네 task 기준 Table 3에서 candidate selection만 비교하면 다음과 같다.

Strategy	Aggregate	Improvement
Baseline	48.84	–
SelectBestCandidate	54.89	+6.05
BeamSearch	53.95	+5.11
GEPA / Pareto-based	61.28	+12.44

이 결과는 GEPA의 성능이 단순히 reflection LM으로 prompt를 고쳤기 때문만은 아니라는 점을 보여준다. 현재 best만 고르는 greedy strategy나 beam search보다, instance-wise Pareto frontier가 optimization trajectory를 더 잘 열어준다.

또 하나 눈에 띄는 결과는 prompt length다. 논문은 GEPA/GEPA+Merge의 prompt가 MIPROv2보다 최대 9.2x 짧다고 보고한다. 이건 단순 미학이 아니다. API provider는 input token에 비용을 매기고, 긴 few-shot prompt는 latency와 context budget을 먹는다. 따라서 “성능이 좋은데 prompt도 짧다”는 것은 serving cost 측면에서 의미가 크다.

마지막으로 GEPA는 inference-time search에도 적용된다. code optimization setting에서 NPUEval과 KernelBench를 사용한다. NPUEval에서는 GPT-4o Sequential10이 mean vector utilization 4.25%를 기록하고, RAG를 붙이면 16.33%, RAG+MIPROv2는 19.03%까지 올라간다. GEPA를 적용하면 mean 30.52%까지 올라가고, 최종 prompt 하나만 사용해도 26.85%를 얻었다고 보고한다. KernelBench에서는 35개 representative task 중 20% 이상에서 PyTorch-eager보다 빠른 CUDA kernel을 생성했다고 보고한다. 다만 논문도 이 결과는 preliminary result로 보고, systematic study가 더 필요하다고 말한다.

5-2. What really matters in the experiments

이 논문의 평가에서 진짜 봐야 할 것은 final score 하나가 아니다. 내 기준에서는 다음 네 가지가 더 중요하다.

첫째, rollout efficiency다. GEPA는 reward 하나를 얻고 끝내는 것이 아니라, rollout trace와 evaluator feedback을 prompt rewrite의 직접 재료로 쓴다. 그래서 rollout 하나의 정보량이 커진다.

둘째, candidate diversity다. Pareto-based selection은 평균 best 하나에 과도하게 exploit하지 않는다. 여러 instance에서 부분적으로 성공한 strategy를 보존한다. 이 구조가 없으면 reflective mutation도 빠르게 local optimum에 갇힐 수 있다.

셋째, prompt compactness다. MIPROv2 같은 few-shot optimizer가 prompt를 길게 만드는 경향이 있다면, GEPA는 declarative instruction 형태로 rule을 압축한다. 이 차이는 실제 API serving에서는 cost와 latency로 직결된다.

넷째, cross-model transfer다. Qwen에서 최적화한 prompt가 GPT-4.1 Mini에서 꽤 잘 transfer된다는 점은, GEPA가 특정 model output pattern만 맞춘 것이 아니라 task semantics를 어느 정도 prompt에 담았다는 증거로 볼 수 있다.

반대로 주의해야 할 지점도 있다. AIME-2025에서는 GRPO가 GEPA보다 강하다. 이는 수학 reasoning처럼 solution distribution 자체를 weight-space에서 바꾸는 것이 중요한 task에서는 prompt optimization만으로 부족할 수 있음을 보여준다. 따라서 GEPA는 “RL 대체재”라기보다, feedback-rich compound system에서 RL보다 먼저 고려할 sample-efficient optimizer로 보는 것이 맞다.

6. Limitations

GRPO 비교 조건을 과하게 일반화하면 안 된다.
compound system GRPO baseline은 비용 문제로 LoRA를 사용한다. 논문은 full-parameter finetuning 비교도 추가로 보여주지만, 모든 task와 모든 model에서 full-scale RL과 비교한 것은 아니다. 따라서 “prompt evolution이 weight-space RL보다 항상 우수하다”는 결론은 과하다.
AIME-2025에서는 GEPA가 GRPO를 넘지 못한다.
Qwen3-8B Table 1에서 AIME-2025는 GRPO가 GEPA보다 높은 score를 보인다. 이는 verifiable math reasoning처럼 reward가 명확하고 weight update가 잘 먹히는 task에서는 RL이 여전히 강한 선택지라는 점을 보여준다.
Feedback function 품질에 크게 의존한다.
GEPA는 feedback_text가 풍부할수록 강해진다. 하지만 모든 task가 좋은 natural-language diagnostic을 주는 것은 아니다. evaluator가 “틀림/맞음”만 반환하면 GEPA의 reflection은 훨씬 약해질 수 있다.
Validation/Pareto budget이 크다.
논문도 GEPA rollout budget의 상당 부분이 candidate validation에 쓰인다고 지적한다. 실제 production에서는 validation subset selection, dynamic evaluation, budget-aware candidate pruning이 필요하다.
Merge는 hyperparameter-sensitive하다.
GEPA+Merge는 GPT-4.1 Mini에서는 성능을 올리지만, Qwen3-8B에서는 aggregate가 GEPA보다 낮다. 즉 crossover는 무조건 좋은 operator가 아니라, 충분히 분화된 lineage가 있을 때 적절한 timing에 호출되어야 한다.
Prompt optimization은 governance 문제가 남는다.
GEPA가 만든 prompt는 길고 구체적인 policy artifact가 될 수 있다. production에서 이를 쓰려면 prompt diff review, security review, prompt injection robustness, privacy policy consistency를 별도로 확인해야 한다.
Prompt-space와 weight-space learning의 경계는 아직 열린 문제다.
GEPA는 prompt-only optimization이다. abundant data, cheap rollouts, open weights, task-specific distribution shift가 큰 상황에서는 weight update가 더 적절할 수 있다. 반대로 prompt lessons를 RL rollout이나 SFT data로 전환하는 hybrid approach가 후속 연구로 중요해 보인다.

7. My Take

7-1. Why this matters for my work

내 관점에서 GEPA는 prompt engineering 논문이라기보다, LLM system optimization 논문에 가깝다. 요즘 실제 AI product는 단일 model score보다 workflow quality가 중요하다. retrieval query를 어떻게 만들지, verifier가 어떤 실패를 잡을지, privacy rewriter가 어떤 정보를 숨길지, tool error를 어떻게 복구할지 같은 문제는 모두 prompt와 system boundary에 걸쳐 있다.

이런 시스템에서 weight-space RL만 바라보면 너무 무거워진다. 매번 model을 fine-tune해야 하고, rollout cost가 커지고, closed API model에는 적용할 수 없다. 반면 GEPA는 이미 존재하는 evaluation logs를 활용해 prompt를 개선한다. 즉 evaluation pipeline을 잘 만들수록 optimizer가 강해지는 구조다.

특히 RAG나 agent pipeline에서는 이 아이디어가 바로 재사용 가능해 보인다. 예를 들어 retrieval 실패 시 missing gold document, query drift, entity omission, temporal constraint violation 같은 feedback을 structured text로 남기면, GEPA류 optimizer가 query rewriting prompt를 체계적으로 개선할 수 있다.

7-2. Reuse potential

실무에서 GEPA를 그대로 쓰지 않더라도, 다음 아이디어는 바로 가져갈 만하다.

metric을 feedback function으로 확장하기
score만 반환하지 말고, feedback_text, failed_constraints, module_name, trace_summary를 함께 반환하도록 evaluator를 설계한다.
module별 prompt diff 관리하기
compound system prompt를 하나의 큰 prompt로 뭉개지 말고, query writer / verifier / answer writer / privacy filter처럼 module 단위로 분리한다.
per-instance winner를 저장하기
평균 score만 보지 말고, 각 validation instance에서 어떤 candidate가 이겼는지를 저장한다. 이 정보가 Pareto selection의 핵심이다.
현재 best만 고치지 않기
prompt search가 local optimum에 빠지는 것을 막으려면, 일부 failure mode에 강한 candidate도 다음 mutation 대상으로 유지해야 한다.
prompt length를 evaluation metric에 넣기
성능이 같다면 짧은 prompt가 더 좋다. 특히 API model에서는 input token cost와 latency가 바로 비용이다.
cross-model transfer를 실험하기
cheap/open model에서 prompt를 evolve한 뒤 expensive/closed model에 transfer하는 방식은 비용 절감 가능성이 있다.

내가 만약 이 논문을 기반으로 실험한다면, 먼저 RAG query rewriting pipeline에 적용해볼 것 같다. retrieved_docs, missing_gold_docs, query_terms, entity_coverage, answer_support를 feedback text로 만들고, multi-hop query writer prompt를 evolve하는 식이다. 이 경우 GEPA의 장점인 trace-based reflection과 Pareto selection이 꽤 잘 맞을 가능성이 있다.

7-3. Follow-up papers

MIPROv2: Optimizing Instructions and Demonstrations for Multi-Stage Language Model Programs
GEPA가 비교하는 대표적인 prompt optimizer다. instruction + few-shot optimization과 GEPA의 instruction-only reflective evolution을 비교해서 읽기 좋다.
TextGrad: Automatic Differentiation via Text
textual feedback을 gradient처럼 쓰는 방향의 대표 논문이다. GEPA의 reflection / feedback usage와 비교하면 “textual optimization”의 여러 형태를 구분하기 좋다.
DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines
compound AI system을 programmatic하게 정의하고 optimizer를 붙이는 관점의 기반이다. GEPA도 이런 modular LLM program 관점 위에 있다.
Reflexion: Language Agents with Verbal Reinforcement Learning
language feedback을 memory로 사용해 agent behavior를 개선하는 초기 계열이다. GEPA의 reflective prompt evolution과 비교하면 “reflection을 어디에 저장하는가”가 다르다.
Promptbreeder: Self-Referential Self-Improvement via Prompt Evolution
evolutionary prompt optimization 관점에서 GEPA의 Pareto-based selection이 왜 필요한지 비교축이 된다.

8. Summary

GEPA는 prompt optimizer라기보다, compound AI system의 prompt set을 sample-efficient하게 evolve하는 optimization algorithm이다.
핵심은 rollout/evaluation trace를 natural-language feedback으로 활용해 module-specific prompt를 reflective mutation하는 것이다.
Pareto-based candidate selection은 현재 best 하나만 고치는 local optimum 문제를 줄이고, instance-wise winning strategy를 보존한다.
v2 기준 six tasks에서 GRPO/MIPROv2/TextGrad 대비 강한 결과를 보이지만, AIME-2025처럼 weight-space RL이 더 강한 task도 있다.
실무적으로는 feedback function 설계, candidate ancestry tracking, per-instance validation, prompt length metric이 가장 재사용 가치가 높다.

Twitter Facebook LinkedIn