멀티턴 에이전트 RL, 수렴까지 챙기는 접근



멀티턴 에이전트 RL, 수렴까지 챙기는 접근
멀티턴 에이전트 RL, 수렴까지 챙기는 접근

멀티턴(agentic) 환경에서 LLM-RL이 자주 붕괴하는 이유는 “잘 되는 듯 보이는 조합”이 실제로는 수렴·단조개선 보장을 깨뜨리기 때문입니다. 이 글은 SeeUPO 논문의 주장과 한계를 사용자의 비평을 중심으로 재구성하고, 보장의 적용범위·구현 부담·실험 공정성까지 현실적인 관점에서 확장합니다.

SeeUPO가 잘한 문제정의와 핵심 기여

SeeUPO 논문이 가장 잘한 지점은 “멀티턴에서 왜 기존 백본(PPO/GRPO/GSPO/RLOO 등)이 안정적으로 수렴하지 못하는가”를 감정이나 경험담이 아니라, 두 축으로 분해해 체계화했다는 점입니다. 저자들은 (1) Advantage 추정이 GAE인지 GRAE인지, (2) Update 메커니즘이 REINFORCE인지 PPU(논문에서 PPO와 구분해 proximal policy update로 명명)인지로 나누고, 조합별로 단조개선(monotonic improvement)과 수렴(convergence)이 언제 성립하는지 표로 정리합니다. 특히 Table 1에서 단일 턴과 멀티턴의 보장 여부를 한 장에 담아 “무엇이 되는지/안 되는지”를 빠르게 전달하는데, 커뮤니티 입장에서 이 정리는 이후 논쟁의 공용 언어가 될 정도로 유용합니다.

논문이 제시하는 핵심 진단은 “멀티턴에서 critic-free와 수렴 보장을 동시에 만족시키기 어렵다”는 트레이드오프입니다. GAE-PPU(PPO 계열)는 멀티턴 수렴 보장을 주장할 수 있으나 ‘perfect value function approximation’ 같은 강한 전제를 요구합니다. 반대로 GRAE는 critic-free를 가능하게 하지만, 멀티턴에서는 구조적 편향과 크레딧 할당 문제가 커져 단조개선이 깨질 수 있다고 봅니다. 이 구도를 명확히 깔아둔 뒤, SeeUPO는 멀티턴 상호작용을 “순차 실행되는 가상 멀티에이전트 bandit”으로 모델링하고, HAML(heterogeneous-agent mirror learning) 프레임을 빌려 “턴별 순차 업데이트”로 단조개선 보장을 가져옵니다. 그리고 업데이트 순서를 실행 순서의 역순(T→…→1)으로 두어 backward induction으로 전역 최적(global optimal) 수렴을 확보한다고 주장합니다. 이 아이디어는 직관적으로도 납득이 됩니다. 뒤의 턴이 이미 최적으로 업데이트되어 있으면 앞의 턴은 “진짜 continuation value”에 맞춰 최적화할 수 있으니, 앞턴이 뒷턴의 미완성 정책을 상대로 헤매는 상황을 줄일 수 있기 때문입니다.

또한 논문은 “왜 역순이 낫다”를 실험으로 직접 받칩니다. Qwen3-14B 기준으로 update order를 Natural/Random/Reverse로 바꿔 비교했을 때 Reverse가 AppWorld와 BFCL v4 모두에서 avg@4, pass@4가 가장 높게 나옵니다. Table 4에서 Reverse는 AppWorld 63.60(avg@4)/80.70(pass@4), BFCL v4 58.00/65.00으로 제시되며 Natural보다도 우위입니다. 이 결과는 ‘역순이 단지 구현 트릭이 아니라, 논문이 말하는 논리적 의존 구조를 실제로 반영한다’는 점을 보여줍니다.

여기까지가 “무엇을 잘했나”의 요약이라면, 실무적으로 더 큰 기여는 안정성 실패 모드를 전면에 놓았다는 점입니다. 논문은 AppWorld/BFCL v4에서 GRPO·GSPO가 특정 설정에서 collapse를 보이는 반면, SeeUPO는 훈련 곡선이 안정적이라고 강조합니다. 멀티턴 agent 훈련에서 가장 치명적인 문제는 ‘몇 점 더 올리는 것’보다 ‘어느 순간 학습이 망가지는 것’이기 때문에, 이 선택은 방향이 좋습니다. Table 2에서 SeeUPO는 Qwen3-14B 기준 평균 pass@4 72.85로 보고되며, 베이스라인 대비 상대 개선 폭(43.3%–54.6%)을 함께 제시합니다.

논문이 만든 ‘정리의 가치’ 독자가 얻는 실전적 이득
GAE vs GRAE, REINFORCE vs PPU 축으로 분해 멀티턴 붕괴 원인을 “추정/업데이트” 레버로 진단 가능
Table 1로 단일턴/멀티턴 보장 여부를 한눈에 제시 어떤 조합이 원리상 위험한지 빠르게 필터링 가능
역순 업데이트+backward induction을 이론·실험으로 연결 “왜 이 설계가 낫다”를 재현 가능한 가설로 다룸

GRAE 편향 분석과 ‘보장’ 문구의 실제 적용범위

사용자 비평의 핵심은 “논문이 convergence guarantees를 강하게 내세우지만, 그 보장이 생각보다 좁다”는 점입니다. 이는 과한 트집이 아니라, 논문이 스스로도 반복적으로 조건을 명시하는 대목에서 확인됩니다. 논문은 REINFORCE+GRAE 조합이 전역 최적에 수렴하는 조건을 “undiscounted settings(γ=1)”로 한정합니다. 또한 GRAE-PPU 조합(GRPO류)은 일반적으로 단조개선/수렴을 보장하지 못하며, 예외적으로 contextual bandit(사실상 단일 턴)에서는 가능하다고 정리합니다. 즉, 멀티턴에서 ‘그대로’ 쓰면 구조적 편향이 문제가 됩니다.

이 구조적 편향을 논문은 ∆(s_t)=V(s_t)−V(s_0) 형태로 설명합니다. 직관적으로 해석하면, GRAE가 상태별 베이스라인이 아니라 “초기 상태 s0 수준의 그룹 평균”을 베이스라인으로 쓰기 때문에, 멀티턴 MDP에서 중간 상태의 가치 차이가 남아 advantage가 상태에 따라 구조적으로 치우친다는 주장입니다. 이 편향은 REINFORCE처럼 완전 on-policy 업데이트에서 특정 조건(특히 γ=1, 유한 horizon, bounded reward 등) 아래에서는 다룰 수 있지만, PPU의 clipped objective에서는 제거되지 않아 PPO의 단조개선 논리와 충돌한다고 봅니다. 이 연결은 “왜 PPO류 clipping과 GRAE가 궁합이 깨지는가”를 논리적으로 설명해주며, 사용자가 ‘설득력 있다’고 평가한 부분이 정확히 여기입니다.

그런데 바로 이 지점에서 “보장의 범위” 문제가 생깁니다. SeeUPO가 제시하는 더 강한 결과(역순 업데이트가 전역 최적 수렴을 보장)는 “multi-turn contextual bandit setting”에서 가장 깔끔하다고 명시됩니다. 다시 말해 멀티턴이라도 환경을 bandit으로 환원해 팀 리워드를 한 번의 보상 형태로 다룰 수 있어야, 논문의 증명 구조가 온전히 살아납니다. 논문은 multi-turn interaction을 sequentially-executed multi-agent bandit으로 추상화하고, global advantage를 r(s0,a1:T)−E[r(s0,a’1:T)]처럼 bandit 형태로 두어 critic-free를 얻습니다. 여기서 핵심 전제는 “보상 구조가 bandit 형태로 취급 가능하다”는 점입니다.

현실의 tool-use 환경은 부분관측·비정상성·긴 지연보상·상태전이의 불확실성이 강합니다. 이런 환경에서는 ‘bandit 환원’이 근사로서 성립하더라도, 근사 오차가 단조개선과 수렴을 얼마나 훼손하는지가 별도의 문제로 남습니다. 사용자의 비평처럼, 제목/초록의 강한 문구만 읽으면 “멀티턴 전반에 전역 최적 수렴 보장”으로 오해하기 쉽고, 본문 조건을 자세히 보면 “bandit화가 타당한 범위에서”라는 단서가 따라옵니다. 저는 이 부분을 약점이라기보다 “논문 커뮤니케이션 리스크”로 봅니다. 기여 자체가 약해진다기보다, 독자가 적용 범위를 과대 일반화하면 반발이 커질 수 있기 때문입니다.

이를 글쓴이 관점에서 더 단단히 만들려면, 보장 문구를 약하게 만들라는 뜻이 아니라 “보존성 분석”을 하나 더 얹는 것이 좋습니다. 예를 들어 동일 벤치(AppWorld/BFCL v4)에서 환경을 일부러 더 MDP스럽게 만드는 조작을 할 수 있습니다. 중간 보상(shaping) 비중을 높이거나, 관측에 노이즈를 주거나, tool 응답을 stochastic하게 만들어 bandit 환원 가정을 단계적으로 깨뜨린 뒤, (1) 성능이 얼마나 유지되는지, (2) 안정성 붕괴가 언제 다시 나타나는지를 보면 “보장의 실질 적용범위”가 실험적으로 명확해집니다. 이 실험은 논문의 주장과 충돌하지 않으면서도, 독자가 가장 궁금해하는 “현실에서 어디까지 믿어도 되는가”에 답을 줍니다.

또 하나의 논점은 PPO 쪽 보장 전제입니다. 논문은 GAE-PPU(PPO)가 멀티턴에서 수렴 보장을 논할 수 있지만, ‘perfect value function approximation’ 조건을 둡니다. 이는 고전 이론에서도 자주 쓰는 가정이지만, LLM 멀티턴에서 critic이 어려운 이유를 논문이 인정하는 만큼, “그렇다면 SeeUPO가 그 빈자리를 실질적으로 얼마나 메우는가”를 더 엄밀히 보여주면 설득이 커집니다. 현재는 “critic-free+보장”의 프레이밍이 강한데, 독자는 자연히 “현실 critic이 imperfect하니 SeeUPO가 정답”이라고 읽기 쉽습니다. 하지만 실제론 “보장=bandit화 범위”라는 또 다른 제한이 있으니, 두 제한을 같은 무게로 비교해주는 분석이 있으면 과장 논란이 줄어듭니다.

역순 업데이트의 비용과 실험 설계의 ‘납득 가능한 추가 증거’

알고리즘 측면에서 역순 업데이트는 강력하지만, 사용자가 지적한 것처럼 구현·스케일링 부담이 분명합니다. SeeUPO는 매 iteration마다 턴 수 T에 대해 turn-by-turn sequential update를 수행합니다. 이는 병렬화가 어렵고 step time이 증가하기 쉽습니다. 논문은 이 점을 숨기지 않고 Table 3에서 step time 오버헤드를 정량으로 제시합니다. 예컨대 Qwen3-14B에서 AppWorld의 training step time이 PPO 대비 ×1.82, GRPO 대비 ×1.86, GSPO 대비 ×1.78로 표시되며, 평균적으로 약 1.5배 내외라고 설명합니다.

하지만 실무 관점에서는 “1.5×”라는 단일 숫자보다 “T가 커질수록 선형으로만 늘어나는가”가 더 중요합니다. 멀티턴 agent는 길이 분포가 넓고, 실제 배치에는 짧은 에피소드와 긴 에피소드가 섞입니다. SeeUPO는 placeholder sample을 넣어 turn별 샘플 풀을 구성한다고 설명하는데, 이 방식은 구현을 단순하게 만들지만, 긴 T를 상정할수록 (1) 빈 샘플이 많아질수록 효율이 떨어지는지, (2) 유효 샘플 수가 적은 후반 턴에서 업데이트가 불안정해지지는 않는지 같은 질문이 남습니다. 또한 “샘플 재사용이 누적되며 on-policy성이 얼마나 깨지는가”도 중요합니다. 논문은 PPU 스타일(클리핑, importance ratio)을 사용해 부분적으로 이를 다루지만, 역순 업데이트 과정에서 정책이 턴마다 변하기 때문에, 동일 rollout이 여러 번 다른 비율로 재가중될 수 있습니다. 이 효과가 안정성을 해치지 않는다는 추가 근거가 있으면 좋습니다.

두 번째로 큰 간극은 HAML의 이질성 가정과 LLM의 파라미터 공유입니다. 논문은 한계로 이를 명시합니다. HAML은 원리상 “에이전트가 이질적 정책(비공유 파라미터)”을 가진다고 보는 것이 자연스러운데, LLM agent 훈련에서는 보통 모든 턴이 같은 파라미터 θ를 공유합니다. 논문은 “큰 모델은 턴별로 기능적으로 달라질 수 있다”는 직관, 그리고 MoE 같은 구조에서는 전문가가 분화될 수 있다는 전망으로 완화합니다. 이는 plausible하지만, 비평에서 말했듯 증명 가능한 가정이라기보다 경험적 가정입니다.

그래서 저는 사용자의 제안인 “명시적 이질성 부여”가 이 논문을 가장 빠르게 강하게 만드는 실험이라고 봅니다. 예를 들어 turn-specific adapter/LoRA, 또는 turn embedding을 넣어 “표현 공간에서라도” 턴별 정책이 분리되도록 만들면, 이론 프레임과 구현 간 간극이 줄어듭니다. 동시에 이 실험은 실무적으로도 의미가 있습니다. 왜냐하면 많은 agent 시스템이 이미 역할별 프롬프트, 툴 호출 모드, 메모리 모드 등을 분리해 쓰기 때문에, 턴별 모듈화를 약간 더 구조화하는 것은 현실적이기 때문입니다.

실험 공정성에 대한 지적도 중요합니다. 논문은 “모든 알고리즘이 같은 training configuration을 사용한다”고 말하며 공정성을 강조합니다. 하지만 GRPO/GSPO 류는 정규화 방식, KL, 클리핑, rollout 수, advantage 처리 등에 매우 민감합니다. 동일 설정이 ‘공정’일 수는 있어도, 각 알고리즘의 best-of 튜닝과 비교하지 않으면 “방법이 더 좋아서가 아니라 설정이 덜 맞아서”라는 반박이 나올 수 있습니다. 이 반박을 줄이는 가장 실용적인 방법은 두 가지입니다. 첫째, 각 baseline에 대해 (가능하면 원 논문 레시피 그대로) 한 번 더 best-of 튜닝 결과를 추가로 보고 “동일 설정” 결과와 나란히 보여주는 방식입니다. 둘째, 최소한 핵심 민감 파라미터(advantage 정규화, KL coefficient, clipping epsilon, rollout 그룹 크기)를 작은 그리드로 스윕해 baseline의 상한선을 제시하는 방식입니다. 이 작업은 논문의 주장(이론적 결함이 있다)을 부정하지 않으면서도, 독자가 받아들이는 심리적 저항을 크게 줄입니다.

또한 논문이 이미 보여준 “정규화는 drift functional을 건드리면 안 된다”는 논리 전개는 매우 좋은 재료입니다. 논문은 batch-level normalization이 µB, σB가 후보 정책과 무관한 상수이므로 argmax를 바꾸지 않아 drift functional을 해치지 않는다고 설명합니다. 반대로 group-level normalization은 상태 의존 스케일링이 들어가 보장을 깰 수 있다고 말합니다. 그리고 Table 5에서 batch-level이 성능도 가장 좋다고 보고합니다. 이 대목은 “이론-실험을 연결하려는 태도”로 높은 점수를 받을 만합니다.

마지막으로, 사용자의 추가 제안 중 “턴별 ablation”은 역순 업데이트의 메커니즘 설득력을 높이는 데 결정적입니다. SeeUPO의 이야기 구조는 “후반 턴을 먼저 최적화하면 앞턴이 더 잘 학습한다”는 것입니다. 그렇다면 실제로 어느 턴에서 이득이 가장 큰지, 후반 턴의 개선이 전반 정책을 어떻게 끌어올렸는지(예: turn별 성공률, turn별 reward contribution, turn별 advantage 분포 변화)를 보여줘야 ‘backward induction이 작동한다’는 주장이 단순한 성능 보고를 넘어 메커니즘 설명이 됩니다. 이 분석은 T와 rollout 길이 분포가 넓어질수록 더 가치가 큽니다. 실무자는 “내 시스템은 대화가 길다”라는 이유로 도입을 고민할 텐데, 턴별 이득이 어디서 발생하는지 알면 최적화(예: 후반 턴만 더 자주 업데이트, 특정 구간만 sequential update 적용)가 가능해지기 때문입니다.


SeeUPO는 멀티턴 LLM-RL의 불안정을 “advantage·update 조합의 이론적 결함”으로 정리하고, 역순 순차 업데이트로 안정성과 성능을 함께 노립니다. 다만 보장의 실질 범위가 bandit 환원에 의존하고, HAML 이질성·스케일링 비용·튜닝 공정성은 추가 실험으로 더 선명히 보여줄 필요가 있습니다.

자주 묻는 질문 (FAQ)

Q. SeeUPO의 “수렴 보장”은 멀티턴 MDP 전반에 그대로 적용되나요? A. 논문은 특히 multi-turn contextual bandit setting에서의 전역 최적 수렴을 강하게 제시하며, bandit 형태의 글로벌 어드밴티지 추정과 역순 업데이트(backward induction)에 기대고 있습니다. 따라서 환경의 MDP성이 강해질수록 bandit 환원의 보존성이 핵심 변수가 됩니다.

Q. GRAE가 PPO(정확히는 PPU)와 섞일 때 왜 문제가 되나요?
A. 논문은 GRAE가 s0 레벨 베이스라인을 쓰면서 멀티턴 MDP에서 ∆(s_t)=V(s_t)−V(s0) 구조적 편향이 남고, 이 편향이 PPU의 clipped objective에서 제거되지 않아 PPO의 단조개선 논리와 충돌한다고 설명합니다.

Q. 역순 업데이트의 비용이 부담인데, 실무에서 완화할 방법이 있나요?
A. 논문은 step time이 대략 1.5× 내외로 늘 수 있음을 보고합니다. 실무적으로는 턴별 ablation으로 “이득이 큰 턴 구간”을 찾은 뒤, 그 구간만 순차 업데이트를 적용하거나, turn-specific adapter로 이질성을 명시해 업데이트 충돌을 줄이는 방식이 현실적인 완화 전략이 될 수 있습니다.

[출처]
https://arxiv.org/html/2602.06554v1

댓글 쓰기

0 댓글

이 블로그 검색

신고하기

프로필