Multi-module GRPO: Composing Policy Gradients and Prompt Optimization for Language Model Programs Review

0. Introduction

Paper link

OpenReview link

Code link

Multi-module GRPO, MMGRPO는 GRPO를 single LM call이 아니라 modular LM program으로 옮기는 논문이다. 여기서 말하는 “LM program”은 하나의 prompt를 넣고 하나의 completion을 받는 구조가 아니다. Query generation, retriever call, fact summarization, redaction, response generation처럼 여러 LM module과 tool이 control flow 안에서 함께 움직이는 compound AI system에 가깝다.

이 논문의 문제의식은 꽤 실무적이다. Agent, RAG, privacy delegation, document workflow를 실제로 만들다 보면, system은 점점 prompt 하나가 아니라 program이 된다. 그런데 GRPO는 기본적으로 같은 prompt에서 여러 completion을 뽑고, 그 group 안에서 relative reward를 계산하는 구조다. 그렇다면 여러 module이 서로 다른 prompt template, 서로 다른 intermediate input, 서로 다른 invocation count를 갖는 program에는 GRPO를 어떻게 붙일 것인가?

MMGRPO의 답은 단순하지만 중요하다. Program 전체 rollout을 먼저 여러 개 샘플링한 뒤, “module identity와 relative invocation order”를 기준으로 trace를 align한다. 그 다음 각 module-level group에 대해 GRPO loss를 독립적으로 적용한다. 즉 program-level reward를 module-level policy gradient로 되돌리는 방법이다.

한 줄 요약: MMGRPO는 GRPO를 modular LM program으로 확장하기 위해 rollout trace를 module identity와 relative call order로 align하고, MIPROv2 prompt optimization과 결합해 LM program의 prompt와 weight optimization을 함께 다루는 online RL framework다.

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

• GRPO가 reasoning model post-training에서 끝나지 않고, agent/RAG/compound AI system optimization으로 확장될 수 있는지 직접 묻는다.
• LM program의 trace, module, prompt template, reward metric을 optimizer가 다루는 단위로 끌어올린다.
• prompt optimization과 weight optimization을 대체 관계가 아니라 staged composition 관계로 본다.
• DSPy의 dspy.GRPO optimizer로 공개되어 있어, paper idea가 library-level interface와 연결된다.
• 결과가 무조건 RL 우위가 아니라, MIPROv2의 cost advantage와 “BetterTogether”의 조합 효과를 같이 보여준다.

이 논문은 “GRPO 성능을 더 올리는 trick”이라기보다, LM application을 “학습 가능한 program”으로 보는 관점의 확장이다. 실서비스에서 중요한 것은 모델 하나의 benchmark score만이 아니라, 여러 LM call과 tool이 섞인 pipeline 전체를 어떻게 trace하고, 평가하고, 개선할지다. MMGRPO는 이 질문에 대해 꽤 깔끔한 baseline을 제시한다.

1. Problem Setting

1-1. Problem definition

이 논문이 겨냥하는 문제는 multi-module LM program에 online RL을 어떻게 적용할 것인가다.

표준 GRPO의 setting은 비교적 단순하다. 하나의 prompt $q$가 있고, old policy에서 여러 completion $o_i$를 샘플링한다. 각 completion에 reward $r_i$를 주고, group 내부의 relative reward로 advantage를 만든다.

\[G = \{(q, o_i, r_i)\}_{i=1}^{G}\] \[\hat A_i = \frac{r_i - mean(R)}{std(R)}\]

이 구조의 핵심 가정은 group 안의 sample들이 같은 prompt에서 나왔다는 점이다. 그래서 reward를 비교할 때 “같은 input에 대해 어떤 completion이 더 나은가”를 볼 수 있다.

하지만 LM program은 다르다. Program $Phi$는 input $x$를 받아 여러 module call을 실행하고, 그 결과 final output $y$와 trajectory $rho$를 만든다.

\[(y, \rho) \sim \Phi(x), \rho = [\zeta_1, \zeta_2, ..., \zeta_T]\]

각 trace $\zeta_t$는 module id, module-level prompt, module output을 담는다.

\[\zeta_t = \langle M_t, q_t, o_t \rangle\]

여기서 문제는 다음과 같다.

1. 같은 program input $x$에서 출발해도 trajectory length가 달라질 수 있다.
2. Control flow가 branch를 타면 어떤 module은 호출되지 않을 수 있다.
3. Parsing failure나 runtime error로 rollout이 일찍 끝날 수 있다.
4. 같은 module이라도 upstream context가 달라져 materialized prompt $q_t$가 달라진다.
5. Reward는 보통 final output에만 붙고, intermediate module에는 직접 supervision이 없다.

즉 standard GRPO가 기대하는 “same prompt, multiple outputs” 구조가 깨진다. 이 논문은 바로 이 gap을 다룬다.

1-2. Why previous approaches are insufficient

기존 방식의 한계는 크게 세 가지다.

Approach	Main idea	Limitation in LM programs
Standard GRPO	같은 prompt에서 여러 completion을 비교	여러 module call과 서로 다른 prompt context를 직접 다루기 어렵다
Prompt optimization	prompt template을 search하거나 compile	LM weights 자체를 program reward에 맞춰 online update하지 않는다
Whole-trajectory RL	trajectory 전체를 하나의 sequence처럼 취급	module isolation, privacy boundary, tool control flow를 잃기 쉽다

특히 whole-trajectory로 풀어버리는 접근은 보기에는 단순하지만, LM program의 장점을 지울 수 있다. 예를 들어 PAPILLON 같은 privacy-conscious delegation에서는 외부 model이 private history 전체를 보면 안 된다. HoVer 같은 multi-hop retrieval에서는 대량의 retrieved passages를 module별로 나누어 처리하는 것이 context 관리에 중요하다. Program의 control flow가 각 module에 보이는 context를 결정한다는 점이 핵심이다.

따라서 이 논문은 multi-turn conversation RL이 아니라, module-level policy input을 기준으로 한 LM program RL을 제안한다. 즉 optimize할 대상은 하나의 giant prompt가 아니라, program 안의 module call들이다.

2. Core Idea

2-1. Main contribution

MMGRPO의 핵심 기여는 GRPO group을 prompt-level이 아니라 module-level로 다시 정의하는 것이다.

Program input $x$에 대해 여러 rollout을 샘플링하면, 각 rollout은 final output $y_i$와 trace list $\rho_i$를 갖는다. MMGRPO는 먼저 program-level reward를 계산한다.

\[r_i = \mu(y_i, \rho_i, m)\]

그 다음 trace 안의 module call들을 module id와 relative invocation index로 묶는다. 예를 들어 어떤 program에 GenerateQuery module이 여러 번 호출된다면, 첫 번째 GenerateQuery 호출끼리, 두 번째 GenerateQuery 호출끼리 따로 group을 만든다.

개념적으로는 아래와 같다.

\[G_{M,k} = \{(q_i, o_i, r_i) : trace\ from\ module\ M\ at\ call\ index\ k\}\]

각 group에 대해 modified GRPO objective를 적용한다.

\[J_{mmGRPO}(\theta_M) = E_{(q_i,o_i,r_i) \in G_{M,k}} \left[ \frac{1}{|o_i|}\sum_t \min(w_t \hat A_i, clip(w_t, 1-\epsilon, 1+\epsilon)\hat A_i) - \beta D_{KL}(p_{\theta_M} || p_{\theta_{M,ref}}) \right]\]

여기서 token ratio는 module-level prompt와 output을 기준으로 계산된다.

\[w_t = \frac{p_{\theta_M}(o_{i,t} | q_i, o_{i,<t})} {p_{\theta_{M,old}}(o_{i,t} | q_i, o_{i,<t})}\]

중요한 차이는 두 가지다.

1. Group은 same prompt가 아니라 same module role과 same relative invocation position으로 구성된다.
2. Loss update는 group을 만든 module의 LM weights에만 적용된다.

단일 module program에서 teacher가 없으면 MMGRPO는 standard GRPO와 같아진다. 그래서 이 방법은 GRPO를 버리는 것이 아니라, GRPO의 grouping rule을 LM program에 맞게 확장하는 쪽에 가깝다.

2-2. Design intuition

설계 직관은 다음과 같다.

LM program에서는 final reward만 있어도 trace는 충분히 많은 구조 정보를 준다. 어떤 module이 어떤 prompt를 받았고, 어떤 output을 냈고, 그 rollout의 final reward가 어땠는지를 기록할 수 있다. 그러면 full trajectory reward를 각 module call에 되돌려 policy gradient signal로 사용할 수 있다.

물론 이 credit assignment는 완벽하지 않다. 논문도 기본적으로 uniform credit assignment를 사용한다. 즉 final reward가 각 module call에 동일하게 붙는다. 하지만 이 단순한 baseline만으로도 standard GRPO를 multi-module setting에 적용할 수 있고, prompt optimization과 결합했을 때 꽤 의미 있는 개선이 나온다.

또 하나의 직관은 prompt optimization과 RL이 서로 다른 것을 고친다는 점이다.

• Prompt optimization은 module의 instruction, demonstration, formatting을 고친다.
• MMGRPO는 고정된 program interface 안에서 LM weights를 reward metric에 맞게 조정한다.
• BetterTogether는 prompt를 먼저 좋게 만든 뒤, 그 위에서 RL을 돌린다.

이 순서는 중요하다. Prompt가 좋아지면 초기 rollout quality가 올라가고, RL이 받는 program-level reward signal도 더 안정적이 된다. 그래서 저자들은 MIPROv2 -> MMGRPO 순서의 staged composition을 평가한다.

3. Architecture / Method

3-1. Overview

Item	Description
Goal	GRPO를 multi-module LM program에 적용하는 online RL optimizer 설계
Unit of optimization	LM program 안의 module-level LM call
Key grouping rule	module identity + relative invocation order
Reward source	final program-level metric
Prompt optimizer	MIPROv2
Composition	BetterTogether(PO, MMGRPO), 즉 prompt optimization 후 MMGRPO
Implementation direction	DSPy program trace를 사용해 module-level GRPO group 생성

MMGRPO는 크게 네 단계로 볼 수 있다.

1. 같은 program input에 대해 여러 full rollout을 샘플링한다.
2. 각 rollout에서 LM module call trace를 수집한다.
3. Trace를 module identity와 relative invocation index 기준으로 align한다.
4. 각 module-level group에 GRPO objective를 적용한다.

3-2. Module breakdown

1) Standard GRPO recap

Standard GRPO는 같은 prompt에서 나온 completion group 안에서 reward를 normalize한다. Reward가 높은 completion은 upweight하고, reward가 낮은 completion은 downweight한다. PPO-style clipping과 KL regularization으로 update를 안정화한다.

이 논문에서 GRPO recap이 중요한 이유는, MMGRPO가 완전히 새로운 RL objective를 만든 것이 아니라 기존 GRPO objective의 input grouping 단위를 바꿨기 때문이다.

2) Full program rollout and trace logging

MMGRPO는 program input $x$에 대해 여러 rollout을 만든다. 각 rollout은 final output뿐 아니라 module call trace를 기록한다.

Trace에는 다음이 들어간다.

• 어떤 module이 호출되었는가.
• 해당 module에 들어간 materialized prompt는 무엇인가.
• 해당 module이 생성한 output은 무엇인가.
• rollout 전체의 final reward는 얼마인가.

이 trace logging이 없으면 MMGRPO는 동작할 수 없다. 그래서 이 논문은 model training 논문이면서 동시에 observability가 있는 LM program framework에 대한 논문이기도 하다.

3) Module-level grouping

가장 중요한 설계는 grouping이다. MMGRPO는 trace를 아래 key로 묶는다.

(module_id, relative_invocation_index)

예를 들어 HoVer program이 4-hop으로 실행되고 GenerateQuery와 AppendNotes를 반복 호출한다면, 첫 번째 query generation, 두 번째 query generation, 첫 번째 notes update 같은 group이 따로 만들어진다.

이 방식의 장점은 structurally comparable한 module call끼리 비교할 수 있다는 점이다. 단순히 trajectory 전체를 섞지 않고, program 안에서 유사한 역할을 하는 call들끼리 reward comparison을 만든다.

다만 같은 group 안의 prompt가 완전히 같지는 않다. Upstream context가 다르기 때문이다. 이 부분이 standard GRPO와의 차이다. Standard GRPO는 같은 prompt에서 completion만 달라지지만, MMGRPO의 module-level group은 module role은 같아도 materialized prompt는 다를 수 있다.

4) Variable trajectory handling

LM program은 항상 같은 구조로 실행되지 않는다. 어떤 rollout은 module parsing error로 끊길 수 있고, 어떤 branch는 특정 module을 호출하지 않을 수 있다.

논문은 이를 위해 post-processing을 둔다.

• PadGroups: group size를 맞추기 위한 padding 또는 truncation 처리
• SelectKDiverseElements: target group size에 맞게 element를 선택하거나 duplicate하면서 reward variance가 살아 있도록 diversity를 고려

Appendix 기준으로 reported experiment에서는 fill setting을 사용한다. 이 detail은 작지만 중요하다. Program RL에서는 reward objective만큼이나 failed rollout, incomplete trace, group size mismatch를 처리하는 engineering이 성능과 안정성에 영향을 준다.

5) Teacher programs

MMGRPO는 student program만으로 rollout을 만들 수도 있지만, optional teacher program list도 받을 수 있다. Teacher program은 같은 structural interface를 공유해야 한다. 즉 module-level input/output field는 맞아야 하지만, prompt template이나 LM weights는 다를 수 있다.

이 기능은 두 가지 가능성을 연다.

1. prompt-optimized program에서 rollout을 만들어 warm-start할 수 있다.
2. 더 강한 LM이나 curated prompt를 teacher로 두고 partially off-policy training signal을 만들 수 있다.

다만 teacher를 쓰는 경우 student와 teacher의 module key mapping이 중요하다. 같은 structure를 공유하지 않으면 module-level grouping이 의미를 잃기 쉽다.

6) BetterTogether composition

논문의 실험에서 가장 중요한 variant는 BetterTogether(PO, MMGRPO)다.

절차는 단순하다.

1. Vanilla CoT program에서 시작한다.
2. MIPROv2로 prompt template을 optimize한다.
3. Optimize된 prompt를 고정한다.
4. MMGRPO로 LM weights를 fine-tune한다.

논문은 prompt optimization 이후 weight optimization을 적용하는 순서에 집중한다. 이게 중요한 이유는 prompt optimization이 stronger rollout을 만들고, stronger rollout이 early RL signal을 더 안정화할 수 있기 때문이다.

4. Training / Data / Recipe

4-1. Data and tasks

논문은 세 가지 LM program task를 사용한다.

Task	Program type	Metric	Train / dev	Notes
Banking77	Single CoT module	Exact match	250 / 500	77 intent classification task
PAPILLON	Two-module privacy delegation	Composite quality/leakage score	111 / 221	Redact private query, call external LM, then answer
HoVer4-HOP	Multi-hop retrieval program	Recall@100	500 / 500	Query generation + fact summarization over 4 hops

Banking77은 single-module program이다. 그래서 이 task에서는 MMGRPO가 standard GRPO와 같은 형태가 된다. 이 task를 넣은 이유는 single-stage baseline과 multi-stage program을 같이 비교하기 위해서로 보인다.

PAPILLON은 privacy-conscious delegation task다. Program은 private user query를 redacted request로 바꾸고, 이를 untrusted but stronger external LM에 보낸 다음, external response를 참고해 final response를 생성한다. 논문에서는 external LM으로 openai/gpt-4.1-mini-2025-04-14를 사용한다. Metric은 response content quality와 private information leakage를 함께 보는 composite score다.

HoVer4-HOP은 multi-hop claim verification을 retrieval program으로 구성한 task다. Query generation module과 fact summarization module이 4-hop으로 반복되고, ColBERTv2 retriever가 Wikipedia 2017 snippet index에서 passage를 가져온다. Program은 최종적으로 최대 100개 passage를 반환하고, gold passage가 포함되는지를 Recall@100으로 평가한다.

4-2. Models and baselines

실험 model은 두 개다.

• llama3.1-8b-instruct
• qwen3-8b

MMGRPO는 module마다 별도 LM copy를 둘 수 있지만, 실험에서는 lightweight training과 deployment를 위해 같은 underlying LM weights를 각 module에서 공유한다.

비교 strategy는 네 가지다.

Strategy	Meaning
Vanilla CoT	각 module이 reasoning field를 먼저 생성한 뒤 final answer를 내도록 하는 base prompt
MIPROv2 (PO)	prompt optimization baseline
MMGRPO	module-level GRPO weight optimization
BetterTogether(PO, MMGRPO)	MIPROv2 후 MMGRPO

중요한 점은 모든 method가 program-level evaluation metric을 사용하지만, external oracle dataset에 직접 의존하지 않는다는 것이다. Training data는 program을 실행하고, model output과 program-level metric에서 bootstrap된다.

4-3. Training strategy

MIPROv2 설정은 다음과 같다.

• auto=medium
• 12 trials
• 12 few-shot candidates
• 6 instruction candidates
• train set의 80%를 validation에 자동 사용

MMGRPO 설정은 다음과 같다.

Item	Value
Trainer	HuggingFace GRPOTrainer
Max context length for training	8192 tokens
Training temperature	0.6
Learning rate	1e-5
Gradient accumulation steps	20
Per-device train batch size	1
qwen3-8b beta / grad clip	0.01 / 0.1
llama3.1-8b beta / grad clip	0.04 / 0.5
Training steps	750
Examples per step	4
Rollouts per example	12
LoRA rank	16
LoRA alpha	64
LoRA dropout	0.05
LoRA target modules	q, k, v, o, up, down, gate

Inference setting도 꽤 실무적이다.

• vLLM engine 사용
• max context length 32768 tokens
• max tokens 1032
• module parsing error가 있을 때 query당 최대 3회 retry
• qwen3-8b: temperature 0.6, top_p 0.95, top_k 20
• llama3.1-8b-instruct: temperature 0.6, top_p 0.9

이 recipe에서 가장 중요한 포인트는 12 rollouts per example이다. MMGRPO는 group relative policy optimization이므로, 같은 program input에서 충분히 다양한 rollout을 만들어야 module-level reward variance가 생긴다. 그리고 variable trajectory 때문에 group size post-processing이 반드시 필요하다.

4-4. Engineering notes

이 논문을 구현 관점에서 보면 핵심은 objective보다 trace infrastructure에 있다.

1. Program execution trace를 남겨야 한다.
2. 각 trace가 module id, materialized prompt, output을 가져야 한다.
3. Failed rollout에 fallback reward를 줄 수 있어야 한다.
4. Module call의 relative invocation order를 계산해야 한다.
5. Group size mismatch를 padding, truncation, selection으로 처리해야 한다.
6. Prompt optimizer와 weight optimizer를 stage-wise로 연결해야 한다.

그래서 MMGRPO는 일반적인 fine-tuning recipe라기보다, DSPy처럼 program abstraction과 trace abstraction이 있는 framework에서 자연스럽게 구현되는 optimizer다. 순수한 chat completion API만으로는 이 level의 trace grouping을 만들기 어렵다.

5. Evaluation

5-1. Main results

Table 1의 주요 결과는 아래와 같다. Dev set accuracy이며, 각 cell은 3 seeds 평균이다.

Strategy	Banking77 llama3.1	Banking77 qwen3	PAPILLON llama3.1	PAPILLON qwen3	HoVer4-HOP llama3.1	HoVer4-HOP qwen3	Avg llama3.1	Avg qwen3	All
Vanilla CoT	58.4	64.6	76.2	78.3	59.5	60.6	64.7	67.8	66.3
MIPROv2 (PO)	59.4	65.9	83.9	78.1	63.4	69.3	68.9	71.1	70.0
MMGRPO	63.7	64.9	83.9	83.3	60.2	71.0	69.3	73.1	71.2
BetterTogether(PO, MMGRPO)	63.7	69.1	86.5	81.1	68.3	71.5	72.8	73.9	73.4

결과를 단순하게 읽으면 다음과 같다.

• MMGRPO는 Vanilla CoT보다 모든 task/model pair에서 높다.
• 평균적으로 MMGRPO는 Vanilla CoT 대비 7% 개선으로 보고된다.
• MIPROv2도 강하다. 평균적으로 Vanilla CoT 대비 5% 개선으로 보고된다.
• BetterTogether(PO, MMGRPO)는 전체 평균 73.4로 가장 높다.
• BetterTogether는 Vanilla CoT 대비 11%, MIPROv2 대비 5%, MMGRPO 대비 3% 개선으로 보고된다.

하지만 여기서 중요한 것은 “RL이 prompt optimization을 항상 이긴다”가 아니다. Table 1을 보면 MIPROv2와 MMGRPO는 서로 다른 cell에서 강하다.

예를 들어 PAPILLON llama3.1에서는 MIPROv2와 MMGRPO가 모두 83.9이고, PAPILLON qwen3에서는 MMGRPO가 83.3으로 BetterTogether 81.1보다 높다. 반대로 HoVer4-HOP llama3.1에서는 BetterTogether가 68.3으로 크게 좋아진다. 즉 어떤 method 하나가 절대적으로 지배하기보다, prompt optimization과 RL이 다른 failure mode를 고친다고 보는 편이 맞다.

5-2. Compute cost interpretation

이 논문에서 실무적으로 중요한 결과는 cost다.

MIPROv2는 평균 1.4 hours, 1 H100 GPU로 결과를 얻은 반면, vanilla MMGRPO는 평균 18.7 hours, 2 H100 GPUs를 사용했다고 보고된다. 평균 개선은 MMGRPO가 7%, MIPROv2가 5%지만, compute budget 관점에서는 MIPROv2가 훨씬 가볍다.

따라서 이 결과를 deployment 관점에서 보면 다음 순서가 자연스럽다.

1. 먼저 prompt optimization으로 싸고 빠른 개선을 얻는다.
2. 충분히 좋은 metric과 rollout infra가 있을 때 MMGRPO를 적용한다.
3. 최종적으로는 BetterTogether처럼 prompt와 weight를 staged로 결합한다.

이건 꽤 현실적인 message다. 많은 production team에게 처음부터 online RL을 돌리는 것은 부담스럽다. 하지만 prompt optimization으로 program interface를 먼저 정리하고, 그 이후 보상 metric이 안정적인 module에만 RL을 붙이는 전략은 실용적이다.

5-3. What really matters in the experiments

이 논문에서 가장 중요한 실험 포인트는 세 가지다.

첫째, MMGRPO는 multi-module setting에서 작동한다. HoVer4-HOP과 PAPILLON처럼 single prompt completion이 아닌 program에서도 module-level grouping으로 policy update가 가능하다는 것을 보여준다.

둘째, MMGRPO와 MIPROv2는 complementary하다. MIPROv2는 낮은 compute로 prompt를 개선하고, MMGRPO는 program reward에 맞춰 weights를 조정한다. BetterTogether의 성능이 높은 것은 이 둘이 같은 문제를 중복해서 푸는 것이 아니라 서로 다른 층을 고친다는 신호다.

셋째, 결과 해석은 cautious해야 한다. Dev set accuracy 평균이 핵심 결과이고, task 수와 model scale이 제한적이다. 또한 PAPILLON은 LLM judge 기반 composite metric을 사용한다. 따라서 final claim은 “compound AI program에 대한 strong first baseline” 정도로 읽는 것이 안전하다.

6. Limitations

1. 실험 model scale이 8B에 제한된다. 더 큰 model이나 더 작은 model에서 같은 behavior가 나올지는 추가 확인이 필요하다.

2. Fine-tuning은 LoRA에 의존한다. LoRA는 효율적이지만 full-parameter update 대비 capacity가 제한될 수 있다.

3. MMGRPO 구현은 하나만 평가했다. Module grouping, reward propagation, padding, teacher mixture에는 여러 alternative design이 가능하다.

4. Banking77은 supervised intent classification으로는 이미 강한 encoder model이 잘하는 task다. 논문은 limited-feedback reward setting에서 GRPO/MIPRO가 어느 정도 가능한지 보는 것이며, supervised labels를 직접 쓰는 방식과 같은 문제로 보면 안 된다.

5. “Uniform credit assignment”는 여전히 coarse하다. Final program reward가 모든 module call에 붙기 때문에, 실제로 실패 원인이 아닌 module도 reward 또는 penalty를 받을 수 있다.

6. Module identity + relative invocation order grouping은 simple baseline으로 좋지만, control flow가 복잡한 agent에서는 같은 index의 module call이 항상 같은 semantic role을 갖는다고 보장하기 어렵다.

7. MMGRPO는 prompt optimization보다 compute cost가 크다. Metric이 불안정하거나 rollout budget이 작은 환경에서는 MIPROv2 같은 prompt optimizer가 더 practical할 수 있다.

8. PAPILLON metric처럼 LLM judge를 포함하는 reward는 judge bias와 leakage-quality tradeoff 해석을 주의해야 한다.

7. My Take

7-1. Why this matters for my work

이 논문은 LLM을 하나의 model로만 보지 않고, program 안의 callable module로 보는 관점에서 중요하다. 실제 production pipeline에서는 model call이 하나가 아니다. OCR 후 document reasoning, retrieval 후 answer generation, private field redaction 후 external API call, multi-hop search 후 summarization처럼 여러 module이 이어진다.

이런 system에서 optimization target은 final answer metric이지만, update target은 module마다 다를 수 있다. MMGRPO는 이 간극을 trace grouping으로 연결한다. 즉 execution log가 곧 training data structure가 된다.

특히 좋게 보는 점은 논문이 과장하지 않는다는 것이다. MMGRPO가 MIPROv2를 항상 이긴다고 주장하지 않는다. 오히려 MIPROv2가 훨씬 싸고 빠르다는 사실을 보여주고, 둘을 결합했을 때 가장 좋은 결과를 낸다고 말한다. 이건 실무적인 system design 관점에서 더 설득력 있다.

7-2. Reuse potential

재사용한다면 아래 조건을 먼저 확인해야 한다.

1. Program-level metric이 있는가.
2. 각 module call의 prompt, output, module id를 trace할 수 있는가.
3. Failed rollout에 penalty나 fallback reward를 줄 수 있는가.
4. 같은 input에서 충분한 rollout diversity를 만들 수 있는가.
5. Prompt optimization으로 먼저 interface를 개선할 수 있는가.
6. Online RL을 돌릴 compute budget이 있는가.

내 workflow라면 바로 MMGRPO부터 돌리지는 않을 것 같다. 먼저 MIPROv2나 SPO류 prompt optimization으로 module prompt를 개선하고, validation metric이 안정적인 module program에 대해서만 MMGRPO를 적용할 것이다. 특히 privacy delegation, multi-hop retrieval, tool routing처럼 final metric은 있지만 intermediate label이 부족한 task에 잘 맞는다.

7-3. Follow-up papers

• Group Relative Policy Optimization / DeepSeekMath: GRPO의 original motivation과 value-model-free RL 구조 확인.
• DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines: LM program abstraction과 optimizer interface 이해.
• MIPROv2: prompt optimization baseline을 제대로 이해하기 위한 후속.
• BetterTogether: prompt optimization과 weight optimization을 staged로 결합하는 관점.
• PAPILLON: privacy-conscious delegation task와 leakage-quality metric 이해.
• HoVer: multi-hop claim verification과 retrieval evaluation setting 이해.

8. Summary

• MMGRPO는 GRPO를 single LM call에서 multi-module LM program으로 확장한다.
• 핵심은 rollout trace를 module identity와 relative invocation order로 align해 module-level GRPO group을 만드는 것이다.
• Program-level final reward를 각 module-level triple에 붙여 online policy gradient update를 수행한다.
• MIPROv2 prompt optimization과 MMGRPO를 BetterTogether 방식으로 결합했을 때 전체 평균 성능이 가장 높다.
• 다만 compute cost, coarse credit assignment, 8B+LoRA 제한, one-implementation evaluation은 반드시 같이 봐야 한다.