본문 바로가기
생각

ThinkingBox는 배울 과제를 어떻게 고를까: GRPO 보상 차이와 성공 확률

GRPO의 보상 차이를 8회 실행 예제로 계산하고, ThinkingBox가 성공 확률의 불확실성으로 과제를 고르는 과정을 따라간다. 평균 성공률과 해결 범위가 다르게 움직이는 이유도 살펴본다.

ThinkingBox는 배울 과제를 어떻게 고를까: GRPO 보상 차이와 성공 확률 관련 이미지

같은 업무를 여덟 번 실행했는데 모두 실패했다면 강화학습에 좋은 어려운 문제일까? GRPO에서는 그렇게 단정하기 어렵다. 같은 과제 안에서 실행 결과를 비교하므로, 보상이 전부 같으면 어떤 경로를 더 선호할지 알려 주는 차이가 사라지기 때문이다. 어려움 자체보다 성공과 실패를 구별할 수 있는 묶음이 필요하다.

ThinkingBox는 이 문제를 사전 과제 선택과 학습 중 묶음 교체로 나누어 다룬다. 보상에서 평균을 빼 보는 계산부터 시작해, 왜 성공률 하나가 아니라 그 불확실성까지 살피는지 따라가 보자. 여기에 나오는 작은 수치 예제는 설명용 계산이며 실제 에이전트를 학습하거나 업무 성능을 측정한 결과는 아니다.

보상 평균을 빼면 무엇이 남는가

ThinkingBox 공식 글 (새 창)의 공개 설정은 같은 과제를 실행한 8개 결과를 한 묶음으로 사용하고, 보상이 모두 같은 묶음은 교체한다. 학습 과제 풀은 기본 모델로 사전 평가해 고른 187개로 고정했다. 학습 중 매번 과제 난도를 다시 재서 풀을 바꾸는 동적 커리큘럼과는 다르다.

차이를 확인하기 위해 보상이 [0, 0, 0, 0, 1, 1, 1, 1]인 가상 묶음을 생각해 보자. 평균은 0.5다. 각 보상에서 평균을 빼면 실패 네 개는 −0.5, 성공 네 개는 +0.5가 된다. 이 부호가 어느 실행이 같은 묶음 내에서 더 나았는지를 구분한다. 이는 정규화나 정책 비율·클리핑을 생략하고, 과제 보상의 중심화만 떼어 본 계산이다.

모두 0이라면 평균도 0이어서 차이는 전부 0이 된다. 모두 1이어도 평균이 1이므로 결과는 같다. 실패한 실행이 많다고 무조건 신호가 큰 것도, 성공한 실행이 많다고 무조건 좋은 것도 아니다. 다만 이 결론은 과제 보상의 대비에 관한 것이며, 다른 손실 항까지 포함한 모든 학습이 멈춘다는 뜻은 아니다.

평균을 뺀 값의 합이 0이라고 해서 학습 효과까지 상쇄된다고 볼 수도 없다. 서로 다른 실행은 선택한 토큰과 경로가 다르며, 양수와 음수가 하나의 파라미터 방향에 더해지는 단순 산술이 아니기 때문이다. 보상의 차이는 경로별 선택 확률을 어떻게 바꿀지 판단하는 신호로 쓰인다.

한 번 수행하는 사전 과제 선별과 반복하는 rollout·평가·학습을 분리한 ThinkingBox 흐름.
출처: https://huggingface.co/blog/microsoft/thinkingbox-training. 위쪽은 학습 전에 풀을 고르는 과정, 아래쪽은 고정된 풀에서 반복하는 학습이다. 중간 재평가에 그어진 취소선은 매 단계 난도를 다시 측정하는 동적 커리큘럼이 아님을 나타낸다. 원본 비율을 유지했으며 세부 글씨는 확대해서 볼 수 있다.

성공률 1%인 과제에서 대비가 나올 확률

성공 확률을 p로 고정하고 여덟 번의 결과가 서로 독립이라고 가정해 보자. 전부 성공할 확률은 p^8, 전부 실패할 확률은 (1−p)^8이다. 따라서 성공과 실패가 섞인 묶음이 나올 확률은 1−p^8−(1−p)^8이 된다. 이는 실제 과제의 확률을 추정한 값이 아니라 가정하에서 유도한 식이다.

p=0.5라면 혼합 묶음이 나올 확률은 약 99.22%다. 반면 p=0.01이면 약 7.73%로 떨어지고, p=0.99일 때도 같다. 성공이 너무 드물거나 너무 흔한 과제에서는 여덟 번을 실행하고도 과제 보상의 대비가 없는 묶음을 자주 얻게 된다. 각 실행에 백엔드 준비와 도구 호출이 든다면, 그 비용은 결과가 같다는 이유로 사라지지 않는다.

하지만 이 식만 보고 성공률 50%인 과제만 무조건 고를 수는 없다. 대비가 있다는 것과 보상이 올바르다는 것은 별개다. 검증기가 틀리거나 환경 장애가 결과를 갈랐다면, 보상 차이가 있더라도 원하는 업무 능력을 가르치지 못한다. 실행 결과가 독립적이지 않거나 학습 중 p가 바뀌면 위의 고정 확률 계산도 실제 묶음 빈도와 어긋날 수 있다.

2번 성공과 20번 성공은 같은 50%라도 다르다

데이터 준비 문서 (새 창)는 정상 실행과 시스템 오류를 구분하고, 사전 실행 결과를 모아 과제를 선택한다. 선택 코드 (새 창)의 assess_counts는 성공 횟수와 정상 실행 횟수로 구간별 사후 확률을 구한 뒤, 확률 질량이 가장 큰 난도 구간을 선택한다. 단순히 관측된 성공률 하나를 구간에 대입하는 방식과 다르다.

성공 k번, 정상 실행 n번일 때 Jeffreys 사후분포는 Beta(k+0.5, n−k+0.5)다. 가상 과제 X가 4번 중 2번, Y가 40번 중 20번 성공했다면 관측 성공률은 둘 다 50%다. 하지만 사후분포는 각각 Beta(2.5, 2.5)와 Beta(20.5, 20.5)로 달라진다. 두 분포의 평균은 0.5로 같지만 표준편차는 약 0.204와 0.077이다. 더 많은 정상 실행을 관측한 Y의 확률이 평균 부근에 훨씬 좁게 모인다.

따라서 “50% 성공”이라는 한 줄 요약만으로는 두 과제가 똑같이 확실한 중간 난도라고 할 수 없다. 분포의 넓이는 사전 실행을 추가할지 판단하는 근거가 된다. 아래 그림은 원자료의 분포와 유지 구간을 보여 준다. 전체 매개변수 학습과 LoRA의 선택 범위가 다르므로 이 그림의 경계를 보편적인 기준으로 삼지는 않는다.

정상 실행 네 번과 장애 네 번이 있었을 때 장애를 모두 실패로 처리하면 n과 성공률이 함께 달라진다. 무엇을 시스템 오류로 분류했는지 원본 로그와 함께 남겨야 한다. 반대로 모델의 잘못된 도구 사용을 단지 불리한 결과라는 이유만으로 장애로 빼 버리면 과제를 실제보다 쉽게 보게 된다.

ThinkingBox의 사전 실행 결과별 성공 확률 분포와 LoRA·전체 매개변수 학습의 난도 구간 선택. 양끝 구간은 제외하고 중간 구간을 남긴다.
ThinkingBox 원자료: 왼쪽은 사전 실행에 따른 성공 확률 분포, 오른쪽은 학습에 남긴 난도 구간이다. 자주 성공하는 구간은 전체 매개변수 학습에서만 남겼다. 이 실험의 선택이며 보편적인 난도 기준은 아니다. 모바일에서는 확대해 세부 레이블을 확인한다. 출처: Microsoft·Hugging Face.

평균 성공률은 올라가도 해결 범위는 줄 수 있다

공식 평가 (새 창)는 Qwen3.8-27B를 50단계 학습한 뒤 별도의 507개 과제에서 pass@1이 51.70%에서 60.78%로 높아졌다고 보고한다. 하지만 과제별 20번 시도 중 한 번이라도 성공한 과제 수는 453개에서 446개로 줄었다. 이는 제공자 측 결과이며 이 글에서 재현한 수치는 아니다.

두 지표가 어긋나는 이유를 작은 예제로 살펴보자. 가상 평가 과제가 A와 B 두 개이고 각각 네 번씩 시도한다. 학습 전 A는 2번, B는 1번 성공했다면 전체 성공은 8번 중 3번, 즉 37.5%다. 이때는 두 과제 모두 한 번 이상 해결했다. 학습 후 A만 4번 성공하고 B는 0번 성공했다면 전체 성공률은 50%로 오른다. 매번 성공하는 과제도 하나 생기지만, 한 번이라도 해결한 과제 범위는 두 개에서 하나로 줄어든다.

이 예제는 ThinkingBox 결과의 원인을 입증하지 않는다. 다만 평균 성공과 해결 범위가 논리적으로 같은 지표가 아니라는 점을 보여 준다. 학습하기 좋은 과제를 고르는 규칙을 평가셋에도 그대로 적용하면, 학습에서 놓친 어려운 업무가 평가에서도 사라질 수 있다. 평가는 고정해 두고 시도별 성공, 반복 성공, 해결한 과제 범위를 함께 본다.

과제를 거르는 이유를 학습 기록에 남긴다

가상 사내 업무 에이전트에 이 방식을 적용한다면 먼저 정상적인 실패와 시스템 장애를 분리하고, 같은 초기 상태에서 사전 실행을 모은다. 성공 횟수뿐 아니라 정상 실행 수, 사후분포, 제외 사유를 기록해 두면 특정 과제가 빠진 이유를 나중에 설명할 수 있다. 학습 중에는 고정된 풀에서 뽑은 묶음이 모두 같은 보상인지 확인하는 과정을 별도로 기록한다.

사전 실행을 늘리면 추정의 불확실성은 줄일 수 있지만 그만큼 비용도 든다. 모델이 바뀌면 기존의 난도 추정이 그대로 유효하다고 볼 수도 없다. ThinkingBox의 고정 풀 실험을 동적 난도 조절의 효과로 읽지 않는 이유도 여기에 있다. 좋은 필터는 어려운 업무를 숨기는 장치가 아니라, 현재 모델이 비교하며 배울 수 있는 실행을 확보하는 장치다. 그 선택이 최종 업무 범위를 좁히지 않았는지는 별도의 고정 평가가 답해야 한다.

채용 제안 보내기

생각

함께 해결할 LLM 과제와 기대하는 역할을 알려 주세요.

연락하기