🤓 AI가 AI를 학습시키다: RL을 사용하여 RL로 AI를 학습시키는 AI 에이전트 학습하기

🔓 다음 항목을 포함한 모든 것이 오픈 소스로 공개되었습니다: 학습된 에이전트의 가중치 (🤗 HF의 LoRA 어댑터), 에이전트 하네스 (agent harness), 태스크 패밀리 (task families), 보상 코드 (reward code), GPU 오케스트레이션 (GPU orchestration), Tinker RL 학습 스크립트, 그리고 모든 파일럿 프로젝트(실패 사례 포함)에 대한 회고록. 시작하기로 이동 ↓

요약 (TL;DR):

• 저는 다음과 같은 파이프라인을 구축했습니다:
  • AI 에이전트가 학습 태스크를 전달받습니다 ("모델에게 X를 하도록 가르치세요")
  • 환경 (environment), 보상 (reward), 데이터셋 (dataset), 하이퍼파라미터 (hyperparameters)를 포함한 완전한 prime-rl 학습 작업을 작성합니다.
  • 이를 실제 Runpod GPU에 제출하여 학습을 진행합니다.
• Tinker를 활용하여, 에이전트가 더 나은 모델을 학습시킬 때 보상을 주는 방식으로 에이전트 자체를 RL (강화학습)로 학습시켰습니다.
• 보상은 54번의 학습 단계 동안 ~0.0에서 ~0.63의 정점까지 상승했습니다. 에이전트가 한 번도 학습해 본 적 없는 별도의 태스크 패밀리(held-out task family)로 전이(Transferring)했을 때도 유효했습니다.

<p align="center"> <img src="assets/hero.png" alt="An RL agent's outer loop — RL Agent → Creates RL Jobs → Reward — whose action creates many task-specific RL jobs, each training a small model inside its own RL loop on a GPU; the reward is how much those small models improved on the hidden eval." width="860"> </p> <p align="center">_{<em>RL 루프 안에 있는 AI이며, 이 AI의 행동은 RL 루프 안에서 AI를 학습시키는 것입니다. (출처: <a href="assets/hero.svg">assets/hero.svg</a>.)</em>}</p>

📚 목차

• 🔁 작동 방식
  • 에피소드 (The episode)
• ⚖️ 보상 설계 (Reward design)
• 🧩 태스크 제품군 (Task families)
• 📈 결과 (Results)
  • 보상이 두 단계의 뚜렷한 계단식으로 상승함
  • 기술이 홀드아웃(held-out) 태스크 제품군으로 전이됨
  • 에이전트가 더 나은 베이스 모델을 선택하는 법을 학습함
• 🖥️ 인프라 (Infrastructure)
• 💰 비용 (Costs)
• 🤗 모델 가중치 (Model weights)
• 🚀 시작하기 (Getting started)
• 🔮 향후 개선 사항 (Future improvements)
• 감사의 글 (Acknowledgements)

---

🔁 작동 방식 (How it works)

두 개의 완전히 분리된 트레이닝 스택(training stacks)을 가진 두 개의 RL 루프.

Tinker가 에이전트를 학습시킵니다. 에이전트는 검증기 환경, 루브릭, 그리고 prime-rl 설정을 작성합니다. prime-rl은 작은 모델을 학습시킵니다. 내부 모델의 숨겨진 평가 (hidden-eval) 점수가 외부 루프의 보상으로 상향 전달됩니다.

에피소드 (The episode)

<p align="center"> <img src="assets/episode.png" alt="파이프라인으로서의 하나의 에피소드: 작업 사양(task spec) → 에이전트 (5개의 워크스페이스 도구 포함) → submit_job → 에이전트로 되돌아가는 재시도 화살표가 포함된 검증 프로브(validation probe) → 파일 기반 작업 큐(file-backed job queue) → 소형 모델을 RL로 미세 조정(fine-tuning)하는 GPU pod → 자물쇠 뒤에서 수행되는 사전/사후 숨겨진 평가(hidden eval) 점수 산출 → 에이전트로 되돌아가는 보상(reward).” width="860"> </p> <p align="center">_{<em>엔드 투 엔드(end to end)로 진행되는 하나의 에피소드. (출처: <a href="assets/episode.svg">assets/episode.svg</a>.)</em>}</p>

하나의 에피소드(One episode) = 트레이너 에이전트가 주어진 작업에 대해 유효하고 고품질인 학습 작업(training job)을 생성하기 위해 시도하는 한 번의 시도입니다:

1. 작업 사양 (Task spec) — 무엇을 학습시킬지에 대한 설명 ("소형 모델이 멀티홉 페르소나 쿼리(multi-hop persona queries)를 해결하도록 가르치기"), 엄격한 제약 조건 범위, 평가 도구 인터페이스, 그리고 몇 가지 개발용 예시를 포함합니다.
2. 에이전트 작업 (The agent works) — 에이전트는 read_file / write_file / edit_file / list_files를 통해 샌드박스화된 워크스페이스를 편집하며, get_baseline_scores를 호출하여 숨겨진 평가(hidden eval)에 대한 미학습 베이스라인 모델들의 점수를 확인할 수 있습니다.
3. submit_job — 검증 프로브(validation probe)를 트리거합니다. 모든 실패 사항은 반환되며, 에이전트에게는 제한된 재시도 횟수가 부여됩니다.
4. 디스패치 (Dispatch) — 검증된 작업은 큐에 쌓이고, Runpod GPU pod의 웜 풀(warm pool)에 의해 선택됩니다. 이들은 prime-rl을 사용하여 GRPO 학습을 수행하며, 숨겨진 평가(hidden eval)를 통해 체크포인트의 사전/사후 점수를 산출합니다.
5. 보상 (Reward) — 검증 효율성과 가장 우수한 미학습 베이스라인 대비 학습된 모델의 성능 향상(uplift)을 결합합니다.

그 후 **외부 루프 (outer loop)**는 Tinker를 사용하여 에피소드 보상을 바탕으로 에이전트 자체를 RL로 학습시킵니다. 매 외부 루프 배치(batch)는 최대 16개의 GPU pod에 걸쳐 40개의 실제 내부 학습 작업을 생성합니다.

⚖️ 보상 설계 (Reward design)

<p align="center"> <img src="assets/reward_composition.png" alt="비례 막대로 표시된 에피소드 보상: 0.35 검증 + 0.60 작업 품질 + 0.05 학습 속도. 여기서 작업 품질은 0.25·사후(post) + 0.75·최적의 사전(best_pre) 대비 향상분(uplift)으로 확장됩니다 (0.5 미만은 악화, 0.5는 유지, 1.0을 향한 진정한 이득).” width="860"> </p>

에피소드 보상 (Episode reward)은 가중 합계 (실시간 가중치 0.35 / 0.60 / 0.05)입니다:

• 검증 (Validation) — 첫 시도에 유효한 제출(valid submission)을 하면 1.0을 부여하며, 추가 시도 시마다 감쇠(decaying)합니다. 에피소드가 한 번도 검증되지 않으면 0입니다. (별도로, 에이전트가 파싱 가능한 제출물을 전혀 생성하지 못할 경우 외부 루프는 에피소드에 -0.1점을 부여합니다. CSV 파일에서 볼 수 있는 -1.0 값은 보상이 아니라 "게시 점수 없음(no post score)"을 나타내는 로깅 센티넬(sentinel)입니다.)
• 작업 품질 (Job quality) — 학습된 모델의 절대적인 사후 학습 점수(post-training score)와 best_pre(가장 성능이 좋은 학습되지 않은 모델의 고정된 베이스라인) 대비 부호가 있는 대비 향상분(signed uplift)의 하이브리드 방식입니다: 0.25·post + 0.75·uplift_term. GPU에서 중단된 작업은 여기서 0점을 받습니다 (에피소드는 검증 항을 유지합니다).
• 학습 속도 (Train speed) — 작업 성공 여부에 따라 결정되는, 더 빠른 작업을 위한 작은 동점 처리(tie-breaker) 요소입니다.

_{꼼꼼히 읽는 분들을 위한 참고 사항: 에이전트용 프롬프트(template/INSTRUCTIONS.md)는 에이전트에게 단순화된 뷰를 제공합니다. 즉, 작업 품질 내부의 75/25 대비 향상분/절대값 분할과 시도 횟수 감소 유도(fewer-attempts nudge)를 제공할 뿐, 0.35/0.60/0.05의 전체 분해 구조를 제공하지는 않습니다. 공개된 어댑터(adapter)는 해당 프롬프트를 대상으로 학습되었습니다. 실제로 계산되는 보상은 위의 방식입니다.}

🧩 작업군 (Task families)

학습되지 않은 모델이 학습 없이는 고전하도록 의도적으로 설계된 6가지 작업군이 있으며, 모든 작업은 다단계 도구 사용(multi-step tool use)과 추론(reasoning)을 필요로 합니다:

5가지 작업군은 에이전트를 학습시키며, 트리아지(triage)는 학습되지 않으며 일반화 프로브(generalisation probe) 역할을 합니다.

📈 결과 (Results)

설정: Qwen3.6-35B-A3B 트레이너 에이전트, LoRA rank 8, lr 4e-5, 그룹 크기 8의 GRPO, 최대 16개의 동시 GPU 포드(pods), 배치당 약 40개의 실제 학습 작업. 실행: pilot-7 (10 단계) → 7b (24 단계, 웜 스타트) → 7c (20 단계, 웜 스타트) — 총 54 단계.

1. 보상이 두 개의 뚜렷한 단계로 상승했습니다

<p align="center"> <img src="assets/charts/pilot7_reward.svg" alt="7 → 7b → 7c 아크 전반에 걸친 외부 루프 단계별 배치 보상: 처음 4단계 동안은 0에 가깝고, pilot-7과 초기 7b를 거치며 급격히 상승한 후, 0.55–0.63 부근에서 높은 고원을 형성함." width="760"> </p>

보상을 분해해 보면 무엇을, 어떤 순서로 학습했는지 알 수 있습니다:

• 1단계(Rung 1) — 프로세스 신뢰성 (pilot-7). 초기 이득의 전체는 검증 실패(validation failures)와 GPU에서 멈춘 작업(dead-on-GPU jobs)을 완료된 에피소드(completed episodes)로 전환하면서 발생했습니다. 총 보상이 ~0.26까지 상승하는 동안 작업 품질(job quality)은 평탄하게 유지되었습니다. 이는 GRPO가 가장 가파른 기울기(steepest gradient)를 먼저 가져갔음을 보여줍니다.
• 2단계(Rung 2) — 더 나은 모델 만들기 (pilot-7b 이후). 신뢰성이 포화 상태(검증 성공률 ~0.75–0.80)에 도달함에 따라, 작업 등급(job grade)이 0.30 → 0.41로 상승했고, 사후 학습(post-training)의 숨겨진 평가(hidden-eval) 점수는 ~0.04의 노이즈 수준에서 0.22–0.48의 지속적인 수준으로 올라갔습니다. 에이전트가 단순히 작동하는 모델이 아니라, 더 나은 모델을 만들기 시작한 것입니다.

<p align="center"> <img src="assets/charts/pilot7_post.svg" alt="단계별 사후 학습 숨겨진 평가 점수: 처음 ~22단계 동안은 0 근처에서 평탄하다가, 이후 ~0.3–0.36 고원으로 명확하게 상승함 — 2단계 전환이 가시화됨." width="760"> </p>

2. 기술이 홀드아웃(held-out) 태스크 패밀리로 전이됨

에이전트가 한 번도 학습한 적 없는 태스크 패밀리(task family)에서도 외부 루프(outer-loop) 학습에 따라 성능이 상승하다가 고원을 형성하는 모습을 보였습니다:

<p align="center"> <img src="assets/charts/pilot7_holdout.svg" alt="Triage 홀드아웃: 에피소드별 보상(흐릿한 점) 및 외부 루프 단계 0, 10, 34, 54에서의 팔 평균값 — 0.399, 0.438, 0.545, 0.492: 34단계까지 상승 후 고원 형성." width="760"> </p>

3. 에이전트는 더 나은 베이스 모델과 더 나은 하이퍼파라미터를 선택하는 법을 배웠습니다

초기 훈련 단계에서는 모델 선택에 편향이 없었습니다: 77/79개의 에피소드가 더 약한 0.6B 모델을 선택했습니다. get_baseline_scores 도구와 성능 향상(uplift) 등급 산정 방식을 도입한 후, 정책(policy)이 반전되었으며 훈련 과정 내내 그 상태를 유지하며 곡선을 따라 심화되었습니다: 작업 작성(job-writing) 에피소드 중 1.7B 모델의 점유율이 **42% → 95%**로 증가했습니다. 또한 에이전트는 노출된 [prime_rl] 설정 표면(config surface)을 채택하였으며(하나의 웜 스타트(warm-start) 경계 내에서 에피소드의 21% → ~78%), 샘플링 온도(sampling temperature), 옵티마이저(optimizer) 선택, 알고리즘 변형(algorithm variant), 스케줄러(scheduler), 손실 함수(loss)와 같은 합리적인 핵심 조합을 사용했습니다.

🖥️ 인프라 (Infrastructure)

동시에 16개의 웜 GPU 포드(warm GPU pods) 훈련 중:

16x_runpod_gpus_screenshot

내부 루프 (에이전트가 작성하는 작업들):

• Runpod 웜-포드 플릿 (Runpod warm-pod fleet) — 제한된 풀(최대 16개)의 포드로 구성되며, 모든 노드가 복제본이 되도록 정확한 prime-rl + 검증기(verifiers) 리비전에 부트스트랩 핀(bootstrap-pinned)되어 있습니다; 프로비저닝(provision)부터 서빙(serving)까지 약 2분이 소요됩니다. 유휴(Idle) 포드는 회수되며, 큐(queue)는 파일 기반(queued/ → running/ → done/)으로 관리됩니다.
• 데이터 기반 GPU 선택 — GPU × 베이스 모델에 대한 벤치마크 매트릭스를 통해 RTX A5000 2개를 사용하는 것이 비용 면에서 **작업당 £0.10 (~$0.13)**로 승리함을 확인했습니다; 프로비저닝 시점에 재고가 있는 것을 가져오기 위해 선호도 사다리(preference ladders)를 따라 탐색합니다.
• 플릿이 실제로 실행된 환경 (주요 곡선, 약 1,750개 작업 — 검증에 실패한 에피소드는 작업을 디스패치(dispatch)하지 않으므로 명목상의 54단계 × 40보다 적음): A40 64% (340 GPU 훈련 시간) · RTX 4090 32% (151시간) · RTX A6000 3% · RTX A5000 1%. 벤치마크 비용 승자는 재고가 있는 경우가 드물었기 때문에, 사다리는 곡선의 대부분을 A40에서 보냈습니다.
• **prime-rl (GRPO)**가 작은 모델을 훈련합니다; 체크포인트(checkpoints)는 vLLM을 사용하여 숨겨진 평가(hidden eval) 전후에 점수가 매겨집니다.

Outer loop (에이전트 학습):

• Tinker (Thinking Machines의 관리형 RL API)는 tinker-cookbook의 중요도 샘플링 (importance-sampling) GRPO를 통해 LoRA 방식으로 Qwen3.6-35B-A3B를 학습시킵니다. 제어-역전 브리지 (control-inversion bridge)는 큐 기반 정책 (queue-backed policy) 뒤에서 각 에피소드를 백그라운드 작업으로 실행하므로, cookbook 루프가 에피소드를 차례대로 구동하는 동안 모든 하네스 로직 (harness logic; 검증 재시도, 넛지, 채점)은 변경되지 않은 상태로 유지됩니다.
• 비동기 오프-폴리시 (Async off-policy) (max_steps_off_policy=2)는 느린 작업 (straggler) 장벽을 극복합니다. 즉, 하나의 느린 에피소드가 전체 배치 (batch)를 막아서지 않습니다. 주요 흐름 전반에 걸쳐 데이터가 오래되어 폐기되는 (stale discards) 경우가 없습니다.
• 모든 것이 계측됩니다. 모든 LLM 호출은 토큰과 USD를 기록합니다; runs/costs.jsonl은 에피소드별 예산에 맞춰 강제되는 전역 지출 장부입니다.

전체 오케스트레이션 (orchestration)은 Nebius를 통해 대여한 CPU 박스에서 실행됩니다.

💰 비용 (Costs)

🤗 모델 가중치 (Model weights)

학습된 트레이너 에이전트는 Hugging Face에 있습니다: Danau5tin/ai-trains-ai-trainer.