Targeted On-Policy Self-Distillation: 실패 지점만 학습시키는 RL 신호

• Dwarkesh Patel이 Sasha Rush에게 들은 targeted on-policy self-distillation 설명을 X에 올림. Sasha는 on-policy distillation이 LLM RL에서 가장 활발한 새 연구 방향 중 하나라고 답함.
• 핵심은 최종 reward 하나로 전체 trajectory를 벌주는 대신, 실패가 난 정확한 step이나 token 근처만 찾아서 그 실수를 낮은 확률로 만들도록 학습시키는 것임.
• 예를 들어 agent가 존재하지 않는 tool을 호출했다면, 전체 rollout을 새로 만들지 않고 그 실수 직전에 hint token을 끼워 넣은 뒤 forward pass만 돌림.
• hint가 들어간 상태에서는 모델이 잘못된 tool token에 더 낮은 확률을 줄 가능성이 큼. 원래 모델은 이 hint-conditioned distribution을 따라 배우면서 같은 상태에서 그 실수를 덜 하게 됨.
• HINT-SD, OPSD, Self-Distilled RLVR, SDAR 같은 최근 논문 흐름도 같은 문제를 다룸. sparse reward가 long-horizon agent의 실패 원인을 충분히 알려주지 못한다는 문제임.

왜 최종 reward만으로는 부족한가?

• long-horizon task는 긴 심부름에 가까움. 중간에 주소를 잘못 입력했는데 마지막에 “배달 실패”만 알려주면, 어떤 단계가 문제였는지 알기 어려움.
• RLVR(reinforcement learning with verifiable rewards)는 정답이 맞았는지, task가 성공했는지 같은 최종 신호를 주는 데 강함.
• 하지만 CUA(computer-use agent)나 tool-use agent는 수십 step을 지나 실패할 수 있음. 마지막 reward 0 하나만으로는 7번째 클릭이 문제였는지, 19번째 API argument가 문제였는지 구분하기 어려움.
• 이걸 credit assignment problem이라고 부름. 실패의 책임을 trajectory 안의 어느 action이나 token에 배분할지의 문제임.
• HINT-SD 논문도 sparse outcome reward는 성공 여부는 알려주지만, 어떤 intermediate action이 실패를 만들었는지는 알려주지 않는다고 설명함.

targeted self-distillation은 어떻게 작동하나?

• 먼저 현재 모델이 직접 rollout을 만듦. 이게 on-policy임. 모델이 실제 inference 때 만들 법한 자기 자신의 상태 분포 위에서 학습한다는 뜻임.
• 그 rollout이 실패하면 다른 모델, critic, verifier, 혹은 같은 모델의 더 많은 context 버전이 trajectory를 읽고 실패 지점을 찾음.
• 실패 지점 바로 위에 hint token을 넣음. 예를 들어 “이 tool은 존재하지 않음”, “현재 page에는 그 버튼 없음”, “schema를 다시 확인해야 함” 같은 식임.
• 그 상태로 같은 모델에 forward pass를 돌림. 중요한 점은 새 decode가 없다는 것임. 새 trajectory를 다시 생성하는 게 아니라 이미 있는 token/action sequence 위에서 확률만 다시 계산함.
• hint가 있으면 모델은 원래 실수 token의 확률을 낮추고, 더 그럴듯한 action의 확률을 올릴 수 있음.
• 마지막으로 원래 모델을 이 새로운 확률분포에 맞춰 학습시킴. 즉 “이 상황에서는 그 잘못된 token을 덜 선택하라”는 조밀한 학습 신호를 주는 것임.

단계	기존 RLVR	targeted on-policy self-distillation
입력 데이터	성공 또는 실패한 rollout	모델이 직접 만든 실패 rollout
신호 위치	trajectory 전체	실패 근처 token/action span
피드백 형태	최종 reward	hint-conditioned probability
비용	새 rollout이 필요할 수 있음	기존 rollout 위 forward pass로 가능
강점	환경 기준의 방향성이 안정적	어떤 실수를 줄일지 더 세밀함

self-distillation에서 teacher는 누구인가?

• 일반 distillation은 더 큰 teacher 모델이 작은 student 모델을 가르치는 그림이 많음.
• On-policy self-distillation(OPSD)은 같은 모델이 teacher와 student 역할을 나눠 가질 수 있음.
• student는 원래 관측만 봄. 예를 들어 instruction, screenshot, history만 보는 CUA agent임.
• teacher-like branch는 privileged information을 추가로 봄. 예를 들어 verifier result, hidden DOM, 정답 trace, 실패 이유, hint를 볼 수 있음.
• 같은 모델이라도 더 좋은 정보를 받으면 더 나은 확률분포를 만들 수 있음. student는 그 분포를 따라가면서, inference 때는 privileged information 없이도 조금 더 나은 선택을 하도록 학습됨.
• Self-Distilled Reasoner 논문은 이 구조를 “한 LLM이 서로 다른 context에서 teacher와 student 역할을 한다”는 방식으로 설명함.

Sean Cai식으로 보면 어떤 데이터가 비싸지는가?

• 낮은 가치 데이터는 성공 demo만 있는 데이터임. 사람이 workflow를 잘 수행했다는 정보는 있지만, 모델이 실패했을 때 어디를 고쳐야 하는지는 알려주지 않음.
• 중간 가치 데이터는 trajectory와 final verifier가 붙은 데이터임. 성공/실패는 알 수 있지만, long-horizon에서는 실패 원인이 여전히 흐릿함.
• 높은 가치 데이터는 failure localization이 붙은 데이터임. “이 trajectory는 실패했고, 원인은 17번째 action이다”까지 알려줌.
• 더 높은 가치 데이터는 correction hint까지 포함함. “17번째 action이 문제이고, 이유는 tool schema mismatch다. available tool list를 다시 봐야 한다”처럼 학습 가능한 문맥을 제공함.
• 즉 data buyer가 원하는 것은 점점 trajectory dataset이 아니라 verifier-backed, error-localized, hint-conditioned trajectory data에 가까워질 수 있음.

CUA 데이터 포맷은 어떻게 바뀔 수 있나?

CUA에서는 단순 screen recording보다 다음 같은 record가 더 가치 있을 수 있음.

{
  "task_id": "crm_invoice_042",
  "instruction": "Find the unpaid invoice for Customer A and send a follow-up email.",
  "trajectory": [
    { "step": 1, "observation": "screenshot/dom", "action": "click_search" },
    { "step": 2, "observation": "screenshot/dom", "action": "type_customer_name" },
    { "step": 3, "observation": "screenshot/dom", "action": "open_wrong_customer" }
  ],
  "final_reward": 0,
  "verifier_result": {
    "success": false,
    "reason": "Opened wrong customer profile"
  },
  "failure_span": {
    "start_step": 3,
    "end_step": 3
  },
  "hint": "The customer email/domain does not match the target customer. Use the invoice ID to disambiguate before opening a profile.",
  "correct_action_type": "search_by_invoice_id"
}

• 이런 record는 “어떤 화면을 봤고 무엇을 눌렀나”에서 끝나지 않음.
• 실패 이유, 실패 위치, correction hint, verifier 결과가 함께 있으므로 post-training pipeline에 바로 들어가기 쉬움.
• 특히 browser-use, desktop-use, enterprise workflow는 긴 sequence에서 한 번의 잘못된 선택이 뒤 전체 상태를 망칠 수 있음.
• 따라서 CUA env 회사나 data infra 회사의 핵심 자산은 성공 trajectory보다 실패 rollout을 학습 가능한 신호로 바꾸는 파이프라인일 수 있음.

RL을 대체하는가, 보완하는가?

• 완전 대체라기보다 RLVR과 self-distillation이 섞이는 방향에 가까움.
• Self-Distilled RLVR 논문은 self-distillation이 token-level policy difference를 주고, RLVR은 environment feedback으로 update direction을 안정적으로 잡는 방식이 더 낫다고 봄.
• SDAR 논문도 multi-turn agent에서 순진하게 GRPO와 OPSD를 합치면 불안정할 수 있어서, RL을 primary backbone으로 두고 OPSD를 gated auxiliary objective로 쓰는 방식을 제안함.
• 쉽게 말하면 verifier/RLVR은 “이 trajectory가 맞았나 틀렸나”를 알려주고, targeted distillation은 “틀렸다면 정확히 어디를 덜 하게 만들 것인가”를 알려주는 역할임.
• 그래서 앞으로 중요한 데이터는 성공 정답만이 아니라, 실패 지점과 correction hint까지 포함한 training fuel이 될 가능성이 큼.

FAQ

on-policy distillation은 무엇인가?

student 모델이 자기 policy로 직접 만든 trajectory 위에서 teacher나 teacher-like branch의 feedback을 받는 distillation 방식임. 정적인 teacher dataset만 따라 하는 off-policy distillation보다 inference 때 실제로 마주칠 자기 실수 상태를 더 잘 다룰 수 있음.

hint token은 왜 중요한가?

hint token은 모델에게 실패 지점 근처의 추가 정보를 줌. 이 정보가 들어가면 모델은 원래 실수 token에 더 낮은 확률을 줄 수 있고, 그 확률 차이를 원래 모델에게 distill하면 localized correction signal이 됨.

CUA에서 왜 특히 중요한가?

CUA task는 화면 상태, tool call, 클릭 순서가 모두 이어지는 long-horizon 문제임. 마지막 성공/실패만 보면 어떤 클릭이나 tool call이 문제였는지 알기 어렵기 때문에, verifier, failure span, correction hint가 붙은 trajectory가 훨씬 더 강한 학습 데이터가 될 수 있음.