멀티턴 RL 실무 가이드 — 무엇이 실제로 작동하는가

A Practitioner’s Guide to Multi-turn Agentic Reinforcement Learning (Wang & Ammanabrolu, UC San Diego, arXiv 2025)

AgentRL: Scaling Agentic Reinforcement Learning with a Multi-Turn, Multi-Task Framework (Zhang & Liu et al., Tsinghua University, arXiv 2025)

Introduction

#1 에이전트 RL은 무엇이 다른가는 왜 멀티턴·장기 지평 에이전트 학습이 단일턴 RLHF의 단순한 확장이 아닌지를 정의했다. #2 공을 어디에 돌릴 것인가는 그 위에서 credit assignment 설계공간의 지도를 그렸다 — 토큰·세그먼트·스텝·턴 중 어느 입도에서 공을 나눌 것인가.

이 글은 그 지도 위에 좌표를 더 찍는 대신, 실제로 코드를 돌려본 사람들이 무엇을 발견했는가를 옮긴다. 이론적으로 그럴듯한 설계가 실전에서 그대로 작동하는 경우는 드물다. 하이퍼파라미터 하나, 마스킹 한 줄을 빠뜨리면 학습 곡선 전체가 무너진다. 그래서 이 편이 인용하는 두 논문은 둘 다 “이론”이 아니라 “실측”을 판다.

두 논문을 겹쳐 읽으면 실무자가 실제로 결정해야 하는 여섯 개의 축이 드러난다.

  1. 궤적을 토큰 시퀀스로 볼 것인가, 스텝의 열로 볼 것인가
  2. 환경이 준 토큰(도구 출력)을 손실에서 어떻게 다룰 것인가
  3. 궤적이 길어질 때 컨텍스트를 어떻게 관리할 것인가
  4. 롤아웃 예산을 길게 적게 쓸 것인가, 짧게 많이 쓸 것인가
  5. 실패한 궤적을 버릴 것인가, 페널티를 줄 것인가
  6. 턴 예산을 얼마나 주고, 루프에 빠진 에이전트를 어떻게 다룰 것인가

이 여섯 축을 하나씩 짚은 뒤, #1#2 → 이 글로 이어진 1부를 닫는다. 2부부터는 credit을 실제로 나누는 방법을 입도별로 하나씩 파고든다.

Background

최소한의 표기법

두 논문이 각자 다른 기호를 쓰지만 뼈대는 같다. 에이전트는 부분관측 마르코프 결정과정(POMDP) 위에서 움직인다.

\[(\mathcal{S}, \mathcal{A}, \mathcal{T}, \mathcal{R}, \Omega, \mathcal{O}, \gamma)\]

\(\mathcal{S}\)는 숨겨진 진짜 상태 공간, \(\mathcal{A}\)는 행동 공간, \(\mathcal{T}\)는 상태 전이 함수, \(\mathcal{R}\)은 보상 함수, \(\Omega\)는 관측 공간, \(\mathcal{O}\)는 관측 함수, \(\gamma\)는 할인율이다. 에이전트는 진짜 상태 \(s_t\)를 보지 못하고 텍스트 관측만 받는다 (Practitioner’s Guide는 표기를 단순화해 관측도 그냥 \(s_t\)로 쓴다).

궤적 히스토리는 다음과 같이 정의된다.

\[h_t = (u, s_0, a_0, s_1, a_1, \ldots, s_t)\]

\(u\)는 태스크 프롬프트, \(s_i\)는 \(i\)번째 턴의 관측, \(a_i\)는 \(i\)번째 턴의 행동이다. LLM 정책 \(\pi_\theta\)는 이 히스토리를 조건으로 행동을 생성한다.

\[a_t \sim \pi_\theta(\cdot \mid h_t)\]

여기서 \(a_t\) 자체가 토큰의 열이라는 게 핵심이다.

\[a_t = (a_t^1, a_t^2, \ldots, a_t^{n_t}, a_t^{\text{eos}})\]

AgentRL은 같은 구조를 “합성 상태(composite state)”라는 이름으로 명시한다. LLM 기반 정책의 상태를

\[s_t = (s_t^{\text{env}}, s_t^{\text{ctx}})\]

로 쪼갠다. \(s_t^{\text{env}}\)는 환경이 들고 있는 진짜 상태, \(s_t^{\text{ctx}} \in \mathcal{V}^*\)는 지금까지의 궤적을 토큰화한 컨텍스트다. 궤적 전체는

\[\tau = (s^{(0)}, a^{(0)}, r^{(1)}, s^{(1)}, a^{(1)}, r^{(2)}, \ldots, s^{(T-1)}, a^{(T-1)}, r^{(T)}, s^{(T)})\]

로 정의된다. 두 논문의 표기가 다를 뿐 말하는 건 같다 — 궤적은 턴의 열이고, 각 턴은 다시 토큰의 열이다. 이 이중 구조가 아래 Method 1절의 핵심이다.

토큰 단위 GAE와 advantage 추정 자체의 유도는 PPO, GRPO 편과 이 시리즈의 #2에서 이미 다뤘으므로 여기서 다시 풀지 않는다.

실험 무대

Practitioner’s Guide는 세 환경에서 통제된 ablation을 돌린다.

  • TextWorld: 절차적으로 생성되는 텍스트 어드벤처. 복잡도를 world 수(\(w\))·object 수(\(o\))·quest 길이(\(q\)) 세 축으로 조절한다. 예를 들어 w2-o3-q4는 방 2개, 객체 3개, 4단계 퀘스트를 뜻한다.
  • ALFWorld: 텍스트 전용 가정용 환경. heat, cool, cook, examine, pick, place 6개 태스크 카테고리로 구성되며 train split으로 학습하고 valid_unseen split으로 평가한다.
  • SWE-Gym: 실제 소프트웨어 엔지니어링 태스크(getmoto, pydantic, mypy, pandas, iterative_dvc). 태스크당 학습 90개, 평가 25개를 무작위로 샘플링했다.

모델은 Qwen2.5-1.5B-Instruct, Qwen2.5-7B-Instruct, Qwen3-8B다. 알고리즘은 PPO, GRPO, RLOO를 비교한다. 학습 인프라는 veRL을 확장해 만들었다.

AgentRL은 AgentBench를 함수 호출(function-call) 형식으로 확장한 다섯 태스크를 한 정책으로 동시에 학습시킨다.

  • ALFWorld — 텍스트 어드벤처·가정 환경
  • DB — 자연어를 SQL로 바꿔 실제 데이터베이스와 상호작용
  • KG — 지식 그래프(예: Freebase) 위에서 멀티스텝 추론과 정보 검색
  • OS — Ubuntu Docker 컨테이너에서 셸 명령으로 작업 수행
  • WebShop — 웹 쇼핑 시나리오

모델은 Qwen2.5-3B/7B/14B/32B-Instruct와 GLM-4-9B-0414다. 알고리즘은 GRPO를 기반으로 자체 고안한 두 장치 — cross-policy sampling과 task advantage normalization — 을 얹었다.

두 논문의 성격이 다르다는 걸 미리 짚어두는 게 좋다. Practitioner’s Guide는 작은 모델·통제된 단일 태스크로 “이 설계 선택이 성능에 얼마나 영향을 주는가”를 정밀하게 측정한 ablation 논문이고, AgentRL은 여러 태스크를 동시에, 크게 돌리면서 실전에서 부딪힌 인프라·알고리즘 문제를 푼 시스템 논문이다. 그래서 뒤에 나올 여섯 축 중 일부는 한쪽 논문에서만 확인되고 다른 논문은 침묵한다 — 그 침묵도 정직하게 적는다.

Method — 실무 결정 목록

1. 궤적 단위를 무엇으로 볼 것인가

두 논문 모두 궤적을 턴의 열이면서 동시에 각 턴이 토큰의 열인 이중 구조로 다룬다 — 이는 Background에서 이미 확인했다. 여기서 짚을 것은 이 선택이 손실 계산에 실제로 미치는 영향이다.

Practitioner’s Guide는 PPO의 token-level credit assignment를 명시적으로 채택한다. TD 오차를 토큰 단위로 계산한다.

\[\delta_t^i = r_t^i + \gamma V(h_t^{i+1}) - V(h_t^i)\]

\(h_t^i\)는 토큰 \(a_t^i\)까지 포함한 히스토리다. 여기에 GAE를 적용해 토큰별 advantage를 추정한다.

\[\hat{A}_t^i = \sum_{l=0}^{L-i} (\gamma\lambda)^l \, \delta_t^{i+l}\]

\(L\)은 에피소드가 끝날 때까지 남은 토큰 수(horizon)다. 논문이 직접 강조하는 지점이 있다. 보상은 오직 각 턴의 eos 토큰에만 할당되는데도, 그 앞의 모든 토큰이 value bootstrapping을 통해 0이 아닌 advantage를 받는다. 턴 하나짜리 스칼라 보상이 그 턴을 구성하는 모든 토큰으로, 그리고 GAE의 재귀를 타고 이전 턴들로도 거슬러 흘러간다. 이게 “궤적을 토큰 시퀀스로 볼 것인가, 스텝의 열로 볼 것인가”라는 질문에 대한 이 논문의 답이다. 둘 다다. 스텝(턴) 경계에서 보상이 발생하지만, 그 보상을 퍼뜨리는 매개는 토큰 단위 value function이다.

AgentRL도 같은 선택을 한다. 고수준 행동 \(a_t\)를 토큰의 열로 쓰고, 정책 확률을 토큰 단위로 인수분해한다.

\[\pi_\theta(a_t \mid s_t) = \prod_{k=1}^{L_t} P_\theta(y_{t,k} \mid s_t^{\text{ctx}}, y_{t,<k})\]

이 인수분해가 있어야 토큰 단위 log-prob과 advantage(뒤에 나올 task advantage normalization 포함)를 정의할 수 있다.

논문이 실제로 뭐라고 했는가. 두 논문 모두 궤적의 외부 구조는 턴(환경과의 한 번의 상호작용), 내부 구조는 토큰이라는 데 동의한다. credit은 토큰 단위로 계산하되, 실제 보상 신호는 턴(정확히는 각 턴의 마지막 토큰) 단위로 들어온다는 점도 같다.

확인 안 된 부분. 턴을 더 큰 단위(세그먼트)로 묶어 credit을 계산하는 방식, 혹은 반대로 토큰보다 더 잘게 쪼개는 방식은 이 두 논문의 범위 밖이다. 그 설계공간 자체는 #2가 이미 지도로 그렸고, 세부 기법은 2부의 #5 턴 단위로 공을 나눈다, #6 스텝을 단위로 삼는다, #7 토큰과 세그먼트로 더 잘게에서 각각 다룬다.

2. 환경 관측을 손실에서 어떻게 다룰 것인가

이 절이 이번 편에서 가장 중요하다. 빠뜨리면 학습이 아예 다른 방향으로 새기 때문이다.

Practitioner’s Guide는 이 지점을 논문 3절에서 정확히 한 문장으로 못박는다.

“We make sure only action tokens contribute to the loss by masking out all state tokens.” (행동 토큰만 손실에 기여하도록, 상태 토큰은 전부 마스킹한다.)

논문이 든 구체적 예시는 채팅 템플릿 형태다. 아래 표는 그 템플릿을 턴 단위로 풀어, 어느 구간이 손실에 들어가고 어느 구간이 마스킹되는지 정리한 것이다.

구간 화자 내용 (요약) 손실 기여
태스크 프롬프트 + 관측 0 user “Your task is: {task}. state: {state 0} your action:” 아니오 — 마스킹
행동 0 assistant “{action 0}”
관측 1 user “state: {state 1} your action:” 아니오 — 마스킹
행동 1 assistant “{action 1}”

환경은 (다음 상태, 보상, 종료 여부)를 계산해 넘겨준다. 보상은 각 턴의 문장 종료 토큰에 할당된다. user 턴(환경이 준 텍스트)은 입력으로만 쓰이고, 그 토큰에는 그래디언트가 흐르지 않는다.

왜 이게 필수인가. 표준 언어모델 학습에서는 시퀀스 전체에 대해 다음 토큰 예측 손실을 계산하는 게 자연스럽다. 하지만 멀티턴 에이전트의 시퀀스에는 모델이 생성하지 않은 텍스트(환경 관측, 도구 출력)가 섞여 있다. 이 부분까지 손실에 포함시키면 정책 그래디언트가 “이 시퀀스 전체를 더 그럴듯하게 만들라”는 방향으로 움직이는데, 그 시퀀스 안에는 모델이 실제로 결정하지 않은 부분까지 들어 있다. 즉 모델은 자기가 하지 않은 선택에 대해서까지 credit(또는 blame)을 받는다. 이게 왜 위험한지는 뒤의 Experiments 절 토이 예제에서 구체적으로 보인다.

논문이 실제로 뭐라고 했는가. Practitioner’s Guide는 마스킹을 명시적으로 구현하고, 그 근거(행동 토큰만 정책이 실제로 선택한 것)를 짧게 언급한다.

확인 안 된 부분. AgentRL 논문 본문에는 마스킹이라는 표현이 단 한 번도 등장하지 않는다. function-call 기반 API로 행동을 정의하는 만큼 실무적으로는 assistant 턴만 학습 대상으로 삼았을 가능성이 높지만, 논문이 그 사실을 직접 진술하지 않으므로 여기서는 추정하지 않고 비워둔다. 마스킹이 프레임워크 코드 수준에는 구현돼 있을 수 있으나, 이 글은 논문 본문에 쓰인 것만 다룬다.

3. 컨텍스트 관리

궤적이 길어지면 컨텍스트 윈도우를 넘긴다 — 특히 SWE-Gym처럼 파일 내용이나 명령 출력이 통째로 들어오는 태스크에서 그렇다. 두 논문이 이 문제를 어떻게 다루는지 확인했다.

Practitioner’s Guide는 “Maximum iteration steps and token limits scale with task complexity”(최대 반복 스텝 수와 토큰 한도가 태스크 복잡도에 비례해 늘어난다)라고만 언급한다. 즉 예산 자체를 태스크 난이도에 맞춰 조정하는 것이 이 논문이 쓰는 전략의 전부다. 궤적이 예산을 넘길 때 요약하거나, 오래된 턴을 잘라내거나, 계층적으로 압축하는 절차는 논문에 등장하지 않는다.

AgentRL은 한 단계 더 구체적인 장치를 OS 태스크의 시스템 프롬프트에 심어둔다.

“If you think the output is too long, I will truncate it. The truncated output is not complete. You have to deal with the truncating problem by yourself.” (출력이 너무 길면 잘라낼 것이다. 잘린 출력은 불완전하다. 이 문제는 네가 알아서 처리해야 한다.)

이건 궤적 전체의 컨텍스트 관리가 아니라, 개별 관측(예: bash 명령의 표준출력) 하나가 너무 길 때 그 관측 자체를 잘라내는 정책이다. 그 부담(잘린 정보로 어떻게 판단할지)을 모델에게 떠넘긴다 — 절단은 인프라가 하지만, 절단된 정보에 대한 강건성은 학습으로 얻어야 한다는 설계다.

논문이 실제로 뭐라고 했는가. Practitioner’s Guide는 예산 스케일링만, AgentRL은 개별 관측 단위의 절단 정책만 언급한다.

확인 안 된 부분. 궤적 전체를 요약하거나, 오래된 턴을 슬라이딩 윈도우로 잘라내거나, 턴을 계층적으로 압축하는 방식은 두 논문 모두 다루지 않는다. 이는 이 시리즈가 조사한 범위 안에서는 실증되지 않은 열린 설계공간으로 남겨둔다. 요약을 쓰면 요약된 턴에 있던 credit을 어떻게 보존할지가 credit assignment 문제와 곧바로 충돌하므로, 여기서 함부로 채워 넣지 않는다.

4. 롤아웃 예산 배분

“궤적을 길게 적게 굴릴 것인가, 짧게 많이 굴릴 것인가”는 서로 다른 두 예산 축을 가리킨다. 하나는 한 궤적이 몇 턴까지 갈 수 있는가(turn budget), 다른 하나는 한 프롬프트당 몇 개의 궤적을 뽑는가(GRPO의 그룹 크기 \(G\))다.

턴 예산. Practitioner’s Guide는 이걸 직접 스윕한다. w2-o3-q4 태스크(최적 해가 4스텝)에서 최대 스텝 수를 6, 8, 12, 16으로 바꿔가며 PPO 성능을 쟀다.

최대 스텝 수 최적 대비 배수 Qwen-1.5B (base) Qwen-1.5B (PPO)
6 1.5배 0.05 0.55 (+0.50)
8 2배 0.09 0.73 (+0.64)
12 3배 0.15 0.80 (+0.65)
16 4배 0.17 0.88 (+0.71)

논문의 결론은 명확하다. “성능은 8스텝(최적의 2배)을 넘어서면 포화한다.” 6스텝으로 예산을 조이면 PPO가 55%에서 멈추지만, 8스텝만 줘도 73%로 뛴다. 그 뒤 12, 16스텝은 한계 이득이 작다. 탐색 예산이 부족하면 학습이 심하게 제한되지만, 일정 수준(여기선 최적 해 길이의 2배) 이상은 낭비에 가깝다.

그룹 크기 \(G\). 두 논문 모두 값은 밝히지만, \(G\) 자체를 스윕한 ablation은 없다.

  • Practitioner’s Guide: GRPO를 SWE-Gym(Qwen3-8B, 희소 보상)에 쓸 때 “GRPO sampling number of 4” — 즉 \(G=4\).
  • AgentRL: GRPO 롤아웃에서 온도 0.8로 “sampling eight times per rollout” — 즉 \(G=8\).

논문이 실제로 뭐라고 했는가. 턴 예산(궤적 길이)은 Practitioner’s Guide가 직접 ablation으로 답을 냈다 — 최적 해 길이의 약 2배가 손익분기점이다. 그룹 크기는 두 논문 모두 사용한 값(4, 8)만 보고하고, “길게 적게 대 짧게 많이”라는 트레이드오프 자체를 직접 비교하는 실험은 두 논문 어디에도 없다.

확인 안 된 부분. 같은 총 롤아웃 예산(턴 수 곱하기 그룹 크기)을 고정한 채 배분 방식을 직접 비교한 실험은 없다. \(G=4\)와 \(G=8\)이라는 값도 서로 다른 태스크(SWE-Gym 대 AgentBench-fc 5종)에 쓰인 것이라 직접 비교할 근거가 아니다.

5. 실패 궤적을 어떻게 쓸 것인가

멀티턴 에이전트는 종종 완전히 실패한다 — 도구를 잘못 부르거나, 형식을 어기거나, 턴 예산을 다 쓰고도 목표에 도달하지 못한다. 이런 궤적을 배치에서 어떻게 다뤄야 할까.

Practitioner’s Guide는 이 문제를 다루지 않는다. 논문 어디에서도 궤적을 버리거나 필터링하는 절차가 언급되지 않는다. 모든 롤아웃이 그대로 학습에 쓰이는 것으로 보이지만, 이것도 명시적으로 확인된 사실이 아니라 “언급이 없다”는 사실만 확인된 것이다.

AgentRL은 명시적인 장치를 둔다. 모든 태스크의 보상을 \([0, 1]\)로 정규화하고, 검증 가능한 보상이 없는 태스크는 정답 1, 오답 0으로 이진화한다. 여기에 더해 비정상 종료(최대 상호작용 턴 수 또는 최대 응답 길이 초과)에는 \(-0.2\)의 페널티를 준다.

“Trajectories exceeding the maximum interaction rounds or maximum response length incurred a penalty of -0.2.”

이건 이 시리즈가 이미 다룬 DAPO의 dynamic sampling과 표적이 다르다. DAPO는 그룹 전체가 퇴화한 경우(한 프롬프트에 대해 뽑은 \(G\)개 궤적의 정답률이 정확히 0 또는 1이라 advantage가 전부 0이 되는 경우)를 배치에서 아예 제거한다 — “이 배치에 학습 신호가 있는가”를 프롬프트 단위로 거른다. 반면 AgentRL의 \(-0.2\) 페널티는 개별 궤적 하나하나의 결과에 값을 매기는 보상 설계다. 궤적을 버리는 게 아니라, 나쁜 궤적에 낮은(음수) 점수를 줘서 그대로 학습에 남긴다.

두 방식은 서로 다른 층위에서 작동하므로 배타적이지 않다 — 프롬프트 단위 필터(DAPO)와 궤적 단위 페널티(AgentRL)를 함께 쓸 수도 있다. 하지만 그런 조합을 실제로 검증한 논문은 이 글이 확인한 범위 안에는 없다.

논문이 실제로 뭐라고 했는가. AgentRL은 실패(비정상 종료)를 배치에서 제외하지 않고 \(-0.2\)라는 고정 페널티로 shaping한다. Practitioner’s Guide는 이 주제를 다루지 않는다.

확인 안 된 부분. DAPO 스타일의 그룹 단위 동적 샘플링(정답률 0 또는 1인 프롬프트 제거)을 멀티턴 설정에 적용한 결과는 두 논문 어디에도 없다.

6. turn budget과 조기 종료

턴 예산 자체의 수치는 4절에서 이미 다뤘다 — 최적 해 길이의 2배 근방에서 포화한다는 것, AgentRL이 예산 초과에 \(-0.2\) 페널티를 준다는 것. 여기서는 에이전트가 무한 루프에 빠지는 구체적 실패 양상을 짚는다.

AgentRL의 부록 케이스 스터디는 KG 태스크에서 GLM-4-9B가 겪은 실패를 그대로 보여준다. 모델은 논리적으로는 정답을 맞게 추론하면서도, 검증에 필요한 도구를 한 번도 호출하지 않고 자기가 추론한 결론을 반복해서 출력한다. 논문은 이를 “premature conclusion loop”(성급한 결론 루프)라고 부른다. 정답을 이미 알고 있다고 확신한 모델이, 도구로 검증하라는 프로토콜을 건너뛰고 같은 답을 계속 되뇌는 것이다.

AgentRL이 이 루프를 깨는 방식은 별도의 규칙 기반 조기 종료(반복 패턴 탐지, n-gram 페널티 등)가 아니라 cross-policy sampling이다. 매 스텝마다 행동을 생성하는 모델을 정책 풀에서 무작위로 바꾸는데, 이 사례에서는 Llama-8B로 전환된 순간 (Llama 자신은 도구 이해가 서툴어도) 실제로 도구를 호출하는 시도가 강제되면서 GLM-4의 결론 루프가 깨진다. 두 모델의 약점이 서로 다른 지점에 있었기 때문에, 정책을 섞는 것 자체가 루프 탈출 장치로 작동한 셈이다. 그리고 이 완화책이 실패해도, 최대 상호작용 턴 수를 넘기면 \(-0.2\) 페널티와 함께 강제 종료되므로 학습이 무한정 멈추는 일은 없다. 즉 AgentRL은 “루프를 사전에 탐지해서 끊는” 장치 대신, “예산을 넘기면 페널티로 종료시킨다”는 사후적 안전망과 “애초에 루프에 덜 빠지게 만든다”는 cross-policy sampling을 조합한다.

논문이 실제로 뭐라고 했는가. Practitioner’s Guide는 태스크 복잡도에 비례해 최대 스텝 수를 정하고(w2-o3-q4는 12스텝, w4-o6-q8은 24스텝), 예산을 넘겼을 때 무슨 일이 일어나는지는 명시하지 않는다. AgentRL은 예산 초과 시 \(-0.2\) 페널티를 명시하고, 루프에 빠지는 구체적 실패 사례와 cross-policy sampling으로 이를 완화한 사례를 케이스 스터디로 보고한다.

확인 안 된 부분. 반복 탐지나 n-gram 페널티 같은 규칙 기반 조기 종료 메커니즘은 두 논문 어디에도 없다. 그 부재 자체가, 이 문제가 아직 표준 해법 없이 각 프레임워크가 다르게 땜질하고 있는 영역이라는 뜻이다.

7. 멀티태스크로 갈 때 생기는 문제 — 태스크 간섭과 보상 스케일

지금까지 여섯 축은 태스크 하나를 어떻게 잘 학습시킬지의 문제였다. AgentRL은 다섯 개 태스크(ALFWorld, DB, KG, OS, WebShop)를 한 정책으로 동시에 학습시키면서, 단일 태스크 학습에는 없던 문제와 마주쳤다. 논문이 정리한 표(Table 2)를 옮기면 다음과 같다.

구분 인프라 문제 알고리즘 문제
단일턴 동기적 롤아웃으로 충분 안정적이고 확장 가능한 학습
멀티턴 동기적 롤아웃의 비효율 — 긴 궤적을 기다리며 GPU가 노는 시간이 생겨 비동기 학습이 필요; 상호작용 환경을 대규모로 배치하는 어려움 상태 공간이 커서 더 많은 탐색이 필요하지만, 학습이 진행될수록 탐색이 줄어듦
멀티태스크 이질적인 환경(서로 다른 인터페이스·상태·계산량)을 하나의 인프라로 통합하는 어려움 태스크 간섭으로 인한 성능 저하, 일반화 부족

이 글의 관심사와 맞닿은 건 마지막 행이다. 태스크 간섭(task interference)일반화 부족이 멀티태스크 RL의 알고리즘 문제로 명시돼 있다.

태스크 간섭이 실제로 어떻게 나타나는가. Experiments 절의 표 2(Table 4)가 이 문제의 실측치다. ALFWorld만 학습한 전문가 모델은 자기 태스크에서 89.7점을 받지만, DB나 WebShop만 학습한 전문가 모델을 ALFWorld에 그대로 평가하면 각각 0.2점, 0.0점으로 사실상 완전히 실패한다. 반대로 DB 열은 ALFWorld·KG·OS·WebShop 전문가 모두 49~58점 수준을 유지해, 붕괴가 훨씬 덜하다. 간섭의 크기는 태스크 쌍마다 다르고, ALFWorld처럼 입출력 형식과 요구 능력이 크게 다른 태스크일수록 다른 태스크로의 전문화가 그 태스크의 능력을 거의 지워버린다.

보상 스케일 차이는 어떻게 다루는가. AgentRL은 이 문제를 두 층위에서 막는다.

첫째, 태스크 자체의 보상을 통일된 척도로 맞춘다. 검증 가능한 보상이 없는 태스크는 정답 1, 오답 0으로 이진화하고, 모든 태스크의 보상을 \([0, 1]\) 구간으로 정규화한다. 여기에 5절에서 다룬 비정상 종료 페널티 \(-0.2\)가 더해진다. 이건 “보상 값 자체”를 태스크 간에 비교 가능하게 만드는 장치다.

둘째, 값을 맞춰도 advantage의 분산은 태스크마다 다르게 흐른다 — 어떤 태스크는 학습이 빨리 진행돼 advantage가 빠르게 줄어들고, 어떤 태스크는 지지부진하다. 이를 막기 위해 AgentRL은 task advantage normalization을 도입한다. 태스크 \(i\)에 속한 배치 안의 모든 토큰 단위 advantage 집합을

\[\mathcal{A}_i^{\text{tok}} = \{\hat{A}_{i,s,g,t,k}\}\]

라 할 때(\(s\)는 샘플 인덱스, \(g\)는 그룹(궤적) 인덱스, \(t\)는 환경 스텝, \(k\)는 토큰 위치), 각 토큰의 advantage를 그 태스크 배치 안에서 평균 0, 분산 1로 재정규화한다.

\[\tilde{A}_{i,s,g,t,k} = \frac{\hat{A}_{i,s,g,t,k} - \mu_i}{\sigma_i}\]

\(\mu_i\)와 \(\sigma_i\)는 각각 \(\mathcal{A}_i^{\text{tok}}\)의 평균과 표준편차다. 이렇게 하면 다섯 태스크가 한 배치에 섞여 있어도, 그래디언트 업데이트에 대한 각 태스크의 기여 크기가 그 태스크의 절대적인 보상 스케일이나 난이도와 무관하게 맞춰진다.

이 장치가 실제로 얼마나 기여하는가. Experiments 절의 ablation(Table 6)에서 task advantage normalization을 빼면 5개 태스크 평균이 65.0에서 59.4로 떨어진다(-5.6, 여섯 축 전체를 통틀어 가장 큰 낙폭). 논문은 이 장치를 뺐을 때 “모델이 태스크마다 다른 속도로 학습하며 일부 태스크에서 fluctuation을 보인다”고 기술한다 — 정규화가 없으면 배치 안에서 어떤 태스크의 그래디언트가 다른 태스크를 압도해버리는 것이다.

논문이 실제로 뭐라고 했는가. AgentRL은 태스크 간섭을 Table 4로 직접 정량화했고, 보상 스케일 문제는 (1) 보상 자체의 \([0,1]\) 정규화와 종료 페널티, (2) advantage의 태스크별 재정규화라는 두 단계로 대응한다.

확인 안 된 부분. 왜 하필 ALFWorld에서 간섭이 가장 파국적인지에 대한 원인 분석(입출력 포맷 차이인지, 필요 능력 자체의 차이인지)은 논문이 직접 설명하지 않는다. Practitioner’s Guide는 단일 도메인 안에서의 태스크 다양성(ALFWorld 6개 카테고리, SWE-Gym 5개 유형)만 다루고, AgentRL처럼 성격이 전혀 다른 태스크를 섞는 실험은 하지 않으므로 두 논문을 직접 비교할 근거는 없다.

8. 저자가 제시하는 기본 레시피

Practitioner’s Guide는 8절 전체를 “The Recipe and Conclusion”이라는 이름으로 할애해 실무자를 위한 처방을 정리한다. 환경·정책·보상 세 축 그대로다.

환경. 단순한 환경에서 학습을 시작하라 — 에이전트가 익힌 기술이 복잡한 환경으로도 전이된다(Experiments 절의 환경 간 일반화 결과 참고). 객체 복잡도가 공간 복잡도보다 어려우므로, 커리큘럼을 짤 때 객체 조작 능력을 우선하라. 단일 태스크 학습도 어느 정도 교차 태스크 일반화를 주지만, 혼합 태스크 학습이 더 견고하다.

정책. 좋은 모방학습 프라이어(SFT)는 RL 표본 복잡도를 극적으로 줄인다. 시연 데이터와 RL 데이터 사이에는(고정 예산 하에서) 성능과 일반화를 동시에 최대화하는 최적 배분이 존재한다 — TextWorld 실험에서는 시연 60개 + RL 400 에피소드였다. 편향 알고리즘(PPO, GRPO)이 비편향 알고리즘(RLOO)보다 멀티턴 설정에서 낫고, 그 격차는 환경이 복잡해질수록 커진다.

보상. 밀집 보상이 성능을 크게 끌어올리지만, 최적 밀도는 알고리즘에 따라 다르다 — PPO는 가장 밀집한 보상에서, RLOO는 보상 밀도에 상대적으로 둔감하다.

하이퍼파라미터. 부록 A는 Qwen-1.5B / TextWorld w2-o3-q4 / PPO 조합으로 스윕한 결과를 표로 남겼다. 상위 설정은 KL 계수 0.01, 롤아웃 온도 0.7, actor 학습률 1e-6, critic 학습률 1e-5, 할인율 \(\gamma=1.0\)이며, 이 조합이 epoch 30에서 90%의 성공률로 가장 높았다. 다만 부록 C에 적힌 “모든 실험에 쓰인 기본값”은 이와 다르다 — actor 학습률 5e-7, critic 학습률 5e-6, KL 계수 0.001, clip ratio 0.2, 배치 크기 256. 두 값이 다른 이유는 논문에 설명돼 있지 않다. 확인 안 된 부분이므로 추측하지 않고 그대로 병기한다 — 스윕에서 찾은 최적값과 실제 대규모 실험에 쓰인 기본값이 다르다는 사실 자체가, 하이퍼파라미터 튜닝 결과를 실전 규모로 그대로 옮기는 게 생각보다 간단하지 않다는 걸 보여준다.

AgentRL 쪽 레시피는 형태가 다르다 — 하이퍼파라미터 표가 아니라 아키텍처 결정들이다. GRPO를 기본 알고리즘으로 쓰고(그룹 크기 8, 온도 0.8), 비동기 롤아웃-학습 파이프라인으로 GPU 유휴 시간을 없애고, function-call 기반 통일 인터페이스로 이질적 환경을 통합하고, 이 글의 2, 6, 7절에서 다룬 cross-policy sampling과 task advantage normalization을 얹는다. 레시피의 단위가 하이퍼파라미터 숫자가 아니라 시스템 설계 그 자체라는 점이, 두 논문의 결이 다르다는 걸 다시 보여준다.

Experiments

두 논문의 핵심 수치

표 1 — Practitioner’s Guide 핵심 결과

실험 설정 결과 비교 기준
환경 복잡도 (Table 1) TextWorld, Qwen-1.5B, 최대 12스텝 w2-o3-q4: 0.17→0.88 (+0.71); w8-o12-q4: 0.03→0.51 (+0.48) base model 대 PPO
비례 확장 + 모델 크기 (Table 2) w4-o6-q8, 최대 24스텝 Qwen-1.5B 0.01→0.59 (+0.58); Qwen-7B 0.28→0.72 (+0.44) base model 대 PPO, 모델 크기별
탐색 예산 (Table 3) w2-o3-q4, 최대 스텝 6/8/12/16 6스텝→0.55, 8스텝→0.73, 12스텝→0.80, 16스텝→0.88 8스텝(최적의 2배) 이후 포화
SFT 대 RL 배분 (Table 7) 고정 예산 1000, SFT 비용은 RL의 10배 60 SFT + 400 RL 롤아웃 → w2-o3-q4 0.85, w4-o6-q8 0.59 (최적 배분) 순수 SFT(100개, 0.95 / 0.55) 대 순수 RL(5000 episode, 0.88 / 0.12)
알고리즘 비교 (Table 8) w4-o6-q8, Qwen-1.5B PPO 0.59 대 RLOO 0.00 편향(PPO) 대 비편향(RLOO)
보상 밀도 (Table 9) tw-simple, Qwen-7B PPO: sparse 0.41 → dense2 0.58; RLOO: 세 밀도 모두 0.35~0.55로 안정 밀도별 PPO 대 RLOO

표 2 — AgentRL 핵심 결과

실험 설정 결과 비교 기준
메인 성능 (Table 3) 5개 AgentBench-fc 태스크 평균 성공률 AgentRL-32B 70.4 Claude-Sonnet-4 Thinking 58.2, GPT-5 52.2, DeepSeek-R1 49.3, AgentLM-70B 51.4
멀티태스크 대 싱글태스크 (Table 4) Qwen2.5-14B, ALFWorld 열 기준 멀티태스크 모델 91.5 대 ALFWorld 외 태스크 전문가 0.0~5.7 ALFWorld 단일 태스크 전문가 89.7
멀티태스크 종합 (Table 4) 5개 태스크 동시 학습 대 5개 전문가 모델 멀티태스크 모델 평균 67.7 대 best-of-five 67.8 사실상 동일 — 간섭 없이 특화 성능에 도달
Ablation (Table 6) Qwen2.5-14B, 5개 태스크 평균 전체 65.0 → cross-policy sampling 제거 60.7 (-4.3) → task adv. norm 제거 59.4 (-5.6) 두 장치 모두 성능에 유의미하게 기여
BFCL-v3 일반화 (Table 5) Qwen2.5-32B, 학습에 쓰지 않은 벤치마크 AgentRL 61.4 (+1.5) 대 base 59.9 multi-turn live 항목에서 +3.0으로 가장 크게 개선

평균만 보면 AgentRL이 모든 면에서 앞서는 것처럼 보이지만, 태스크별로 뜯어보면 그렇지 않다.

표 2-1 — AgentRL-32B 대 상위 베이스라인, 태스크별 분해 (Table 3)

모델 ALFWorld DB KG OS WebShop 평균
AgentRL (Qwen2.5-32B) 94.5 70.4 77.0 51.7 58.6 70.4
Claude-Sonnet-4 Thinking 69.0 68.4 64.4 51.0 38.3 58.2
GPT-5 65.4 63.2 64.1 34.5 33.7 52.2
AgentLM-70B 86.0 37.7 47.0 21.5 64.9* 51.4

별표(*) 표시가 붙은 AgentLM-70B의 WebShop 점수(64.9)는 AgentRL 논문이 직접 재현한 값이 아니라 원 논문에서 그대로 인용한 수치라고 논문이 밝히고 있다. 이 값 하나를 빼면 AgentRL-32B가 다섯 태스크 전부에서 표에 있는 모든 베이스라인을 앞선다. 다만 이 WebShop 항목만은 AgentLM-70B가 여전히 AgentRL-32B(58.6)보다 높다 — 같은 조건에서 재현된 수치가 아니라는 단서를 달고서라도, AgentRL이 모든 축에서 무조건 우위인 건 아니라는 점은 정직하게 남겨둔다.

두 표를 나란히 보면 확인되는 게 하나 더 있다. 멀티태스크 학습이 항상 서로를 갉아먹는 건 아니다. Table 4에서 ALFWorld 열은 다른 태스크 전문가가 진입하면 0.0~5.7까지 붕괴하는 반면(과제 포맷 자체가 크게 다르기 때문으로 보인다), DB나 KG 같은 열은 다른 태스크 전문가도 40~58 수준을 유지한다. 그럼에도 멀티태스크로 함께 학습한 모델은 전 태스크에서 각 분야 전문가에 필적하는 성능(평균 67.7 대 67.8)을 낸다 — task advantage normalization과 cross-policy sampling이 이 결과를 만드는 핵심 장치라는 게 Table 6의 ablation이 보여주는 것이다.

환경 일반화와 태스크 다양성

Method 절이 다루지 않은 각도가 하나 더 있다. 단순한 환경에서 배운 게 복잡한 환경으로 옮겨가는가, 그리고 여러 태스크를 섞어 배우면 서로 도움이 되는가다. Practitioner’s Guide가 TextWorld와 ALFWorld, SWE-Gym에서 답한 결과를 정리한다.

표 3 — 환경 간 일반화 (TextWorld, Qwen-1.5B, PPO)

학습 환경 w2-o12-q4 평가 w8-o3-q4 평가 w8-o12-q4 평가 w4-o6-q8 평가
w2-o3-q4 (기본, 가장 단순) 0.40 (+0.32) 0.51 (+0.44) 0.27 (+0.24) 0.12 (+0.11)
w8-o3-q4 (공간만 확장) 0.50 (+0.42) 0.68 (+0.61) 0.51 (+0.48) 0.21 (+0.20)
w2-o12-q4 (객체만 확장) 0.54 (+0.46) 0.27 (+0.20) 0.27 (+0.24) 0.13 (+0.12)

행은 학습에 쓴 환경, 열은 평가에 쓴 더 복잡한 환경이다. w8-o3-q4(공간 복잡도만 높인 환경)에서 학습한 모델을 w8-o12-q4에 평가하면 0.51까지 오르는데, 이는 w8-o12-q4를 직접 학습했을 때의 성능(0.51, Method 4절 참고)과 같다. 더 쉬운 환경에서 배운 기술이 더 어려운 환경으로 그대로 전이된다는 뜻이다.

표 4 — 태스크 다양성 (ALFWorld: PPO / SWE-Gym: GRPO)

학습 구성 단일 태스크 평가 전체 태스크 평가
ALFWorld, 단일 유형만 (pick & place) 0.63 (+0.19) 0.59 (+0.12)
ALFWorld, 4개 유형 혼합 (heat/cool/cook/examine) 0.82 (+0.38) 0.80 (+0.33)
ALFWorld, 6개 유형 전체 0.76 (+0.32) 0.74 (+0.27)
SWE-Gym, getmoto만 0.28 (+0.19) 0.11 (+0.07)
SWE-Gym, 5개 유형 혼합 0.37 (+0.28) 0.22 (+0.18)

두 도메인 모두 태스크를 섞어 학습한 쪽이 단일 태스크 특화보다 낫다 — ALFWorld는 4개 유형 혼합이 단일 유형보다 자기 태스크에서도 19점, 전체 평가에서도 21점 높다. 흥미로운 건 ALFWorld에서 6개 유형(전체)을 섞은 쪽이 4개 유형 혼합보다 오히려 낮다는 점이다(0.76 대 0.82, 전체 평가에서도 0.74 대 0.80). 태스크를 무조건 많이 섞는다고 계속 좋아지는 건 아니라는 뜻이다. 다만 논문은 이 역전 현상의 원인을 별도로 분석하지 않으므로, 왜 6개 유형에서 성능이 살짝 꺾이는지는 확인 안 된 채로 남겨둔다.

토이 예제: 마스킹을 빠뜨리면 무슨 일이 생기는가

Method 2절에서 확인한 마스킹 규칙 — “환경이 준 토큰(user 턴)에는 그래디언트를 흘리지 않는다” — 을 어겼을 때 실제로 무슨 일이 벌어지는지, 짧은 가상 궤적으로 따라가 보자. Practitioner’s Guide가 제시한 채팅 템플릿 형식을 그대로 쓴다.

정상 궤적 (마스킹 적용).

순서 화자 텍스트 손실 기여
1 user “task: 빨간 열쇠를 찾아라. state: 당신은 방 안에 있다. your action:” 아니오
2 assistant “go north” 예 (보상 \(r_0\)이 이 턴의 eos에 할당)
3 user “state: 테이블 위에 빨간 열쇠가 보인다. your action:” 아니오 — 환경이 실제로 관측한 결과
4 assistant “take red key” 예 (보상 \(r_1\))

이 경우 정책이 실제로 학습하는 건 딱 두 곳뿐이다. “go north”를 생성할 확률과 “take red key”를 생성할 확률. 3번 줄(“테이블 위에 빨간 열쇠가 보인다”)은 환경이 실제로 상태 전이를 실행해서 얻은 결과이지, 모델이 만들어낸 문장이 아니다. 정책은 이 문장을 그대로 입력으로 받아 다음 행동을 고를 뿐이다.

마스킹을 빠뜨린 경우. 손실 마스크를 켜지 않고 시퀀스 전체(1~4번 줄)에 advantage를 그대로 곱해 역전파하면 어떻게 될까. Method 1절에서 확인했듯 GAE의 value bootstrapping은 eos 토큰의 보상을 그 앞의 모든 토큰으로 퍼뜨린다. 마스킹이 없으면 이 “앞의 모든 토큰”에는 3번 줄, 즉 환경이 준 관측 문장의 토큰들도 포함된다. 좋은 결과로 이어진 궤적(양의 advantage)이라면, 정책은 “테이블 위에 빨간 열쇠가 보인다”라는 문장 자체를 더 그럴듯하게 생성하는 방향으로도 업데이트된다 — 그 문장을 실제로 만든 게 자신이 아닌데도.

이게 왜 위험한지는 학습이 몇 스텝만 더 진행되면 드러난다. 정책은 “행동을 내놓고 좋은 관측 문장이 뒤따르는” 패턴 자체에 보상이 걸려 있다는 걸 (마스킹이 없으므로) 간접적으로 학습한다. 그런데 정책이 만들 수 있는 건 자기 자신의 다음 토큰뿐이다. 그러니 가장 손쉬운 지름길은 실제로 도구를 호출하고 환경의 응답을 기다리는 대신, 자기 턴 안에서 환경 관측 형식을 그대로 흉내 내 이어 쓰는 것이다. 예를 들어 “take red key” 다음에 스스로 “state: 열쇠를 손에 넣었다. your action: open door”까지 한 번에 생성해버리는 식이다. 실제로는 상태 전이가 한 번도 일어나지 않았는데, 정책은 자신이 지어낸 성공 서사를 스스로 만들어 그 안에서 보상을 챙긴다. 이게 hallucinated tool output — 도구를 부르지 않고 결과를 지어내는 것 — 이다.

이 실패 양상은 우연이 아니다. Method 6절에서 본 AgentRL의 “premature conclusion loop”, 즉 도구를 부르지 않고 자기 결론을 반복하는 실패와 결이 같다. 둘 다 환경과의 실제 상호작용을 생략하고 그 결과만 흉내 내는 쪽이 더 싸다는 걸 정책이 학습한 결과다. 마스킹은 이걸 원천에서 막는 장치이고, 이 패턴이 마스킹을 갖춘 뒤에도 다른 경로로 발생하는 것이 #15 에이전트의 reward hacking에서 다룰 주제다 — 도구 호출 형식은 지키면서 검증되지 않은 성공을 보고하는, 더 교묘한 버전이다.

Conclusion

#1이 “왜 에이전트 RL은 단일턴 RLHF와 다른가”를 정의하고, #2가 credit assignment의 설계공간을 지도로 그렸다면, 이 글은 그 지도 위에서 실제로 검증된 좌표만 골라 표시했다. 정리하면 다음과 같다.

  1. 궤적은 턴의 열이자 토큰의 열이다. 보상은 턴 경계(eos)에서 발생하지만, 토큰 단위 GAE가 그 신호를 앞뒤로 퍼뜨린다.
  2. 환경 토큰 마스킹은 협상 불가다. 빠뜨리면 정책이 환경 관측을 흉내 내는 방향으로 새고, 이는 hallucinated tool output이라는 구체적 실패로 이어진다.
  3. 컨텍스트 관리는 아직 임시방편이다. 예산 스케일링(Practitioner’s Guide)과 개별 관측 절단(AgentRL)만 확인됐고, 궤적 전체를 요약·압축하는 방법은 실증되지 않았다.
  4. 롤아웃 예산은 최적 해 길이의 약 2배에서 포화한다 — 최소한 TextWorld류 환경에서는. 그룹 크기 \(G\)는 4와 8이 각각 보고됐을 뿐, 직접 비교는 없다.
  5. 실패 궤적 처리에는 최소 두 개의 층위가 있다. 프롬프트(그룹) 단위로 거르는 DAPO식 필터와, 궤적 단위로 페널티를 매기는 AgentRL식 shaping. 둘의 조합은 검증되지 않았다.
  6. 턴 예산 초과와 루프는 다른 문제다. 전자는 페널티로 강제 종료할 수 있지만, 후자(같은 실수를 반복하는 것)는 예산을 늘린다고 풀리지 않는다 — AgentRL은 정책을 섞는 것으로 우회했다.

여기에 더해 AgentRL은 멀티태스크로 갈 때의 함정도 확인해줬다. 태스크 간섭의 크기는 태스크 쌍마다 다르고(ALFWorld는 파국적, DB는 완만), 보상 스케일 차이는 보상 자체의 정규화만으로는 부족해 advantage를 태스크별로 다시 정규화해야 했다. 그리고 두 논문 모두 “이렇게 하면 된다”는 처방(Recipe)을 남겼는데, Practitioner’s Guide는 하이퍼파라미터 숫자로, AgentRL은 시스템 설계로 답했다는 점이 두 논문의 성격 차이를 그대로 보여준다.

이 여섯 축을 관통하는 메시지는 하나다. 멀티턴 RL이 단일턴과 다른 이유는 알고리즘이 아니라 엔지니어링에 있다. PPO의 클리핑도, GRPO의 그룹 정규화도 단일턴에서 그대로 가져왔다. 달라지는 건 그 알고리즘에 무엇을 먹일 것인가다 — 어디까지가 내 행동이고 어디부터가 환경의 응답인지, 언제 컨텍스트를 자르고 언제 포기할지 같은, 논문의 각주와 부록에 파묻혀 있는 결정들이다.

이것으로 1부(왜 에이전트는 다른가)를 닫는다. #1이 문제를, #2가 지도를, 이 글이 실무 제약을 확인했으니, 2부부터는 credit을 실제로 나누는 방법을 입도별로 파고든다. #4 결과만으로는 부족하다, #5 턴 단위로 공을 나눈다, #6 스텝을 단위로 삼는다, #7 토큰과 세그먼트로 더 잘게, #8 shaping은 약인가 독인가 순서다.

참고 문헌


Agentic RL 설계 시리즈

이 글은 Agentic RL 설계 시리즈의 세 번째 글이다.

1부. 왜 에이전트는 다른가

  1. 에이전트 RL은 무엇이 다른가 — 장기 지평·희소 보상·긴 궤적
  2. 공을 어디에 돌릴 것인가 — credit assignment 47개 방법의 지도
  3. (현재 글) 멀티턴 RL 실무 가이드 — 무엇이 실제로 작동하는가

2부. credit assignment — 공을 어디에 돌릴 것인가

  1. 결과만으로는 부족하다 — 장기 지평에서 증폭되는 RLVR의 한계
  2. 턴 단위로 공을 나눈다 — turn-level reward 설계
  3. 스텝을 단위로 삼는다 — 행동 단위 궤적 표현과 credit
  4. 토큰과 세그먼트로 더 잘게 — 세밀한 입도의 득과 실
  5. shaping은 약인가 독인가 — 중간 보상의 효율과 위험

3부. reward를 어디서 얻나

  1. 환경이 곧 reward다 — 샌드박스·테스트·상태 검증
  2. 도구 호출을 어떻게 채점하나 — ToolRL·ToolRM
  3. 궤적을 judge가 채점한다 — rubric 생성형 reward의 확장

4부. 도메인별 설계

  1. 검색 에이전트 — Search-R1에서 DeepDive까지
  2. 코드 에이전트 — SWE-RL과 테스트라는 reward
  3. 웹·GUI 에이전트 — end-to-end 멀티턴 RL

5부. 실패와 방어

  1. 에이전트의 reward hacking — 판정기가 뚫린다, 그리고 조합의 실패

6부. 실전 종합

  1. 프론티어 모델은 실제로 어떻게 하나 — 최신 모델들의 agentic RL 설계

본 시리즈는 16편으로 구성된다.




Enjoy Reading This Article?

Here are some more articles you might like to read next:

  • 프론티어 모델은 실제로 어떻게 하나
  • 에이전트의 reward hacking — 판정기가 뚫린다, 그리고 조합의 실패
  • 웹·GUI 에이전트 — end-to-end 멀티턴 RL
  • 코드 에이전트 — SWE-RL과 테스트라는 reward
  • 검색 에이전트 — Search-R1에서 DeepDive까지