MOPD 다중 교사 증류: 프롬프트 20%가 학습 토큰 2%도 안 되는 이유

여러 전문가의 답을 하나의 모델로 옮긴다는 것

2026년 11월 3일 공개된 TRL 활용 글은 AsyncDistillationTrainer로 여러 교사를 연결하는 예제를 소개했다. 이 글에서 다룰 변화는 모든 모델을 섞는 범용 병합기가 생겼다는 것이 아니다. 이미 준비한 전문 모델들을 이용해 하나의 학생 모델을 추가 학습하는 경로가 구체화됐다는 점이다. 발표일과 이 글의 확인일인 11월 5일을 구분한다. TRL 활용 발표

MOPD는 Multi-Teacher On-Policy Distillation, 즉 여러 교사를 사용하는 온폴리시 증류다. 학생이 직접 답변을 생성하고, 그 질문에 배정된 교사가 학생의 토큰 선택을 평가한다. 학생은 그 신호를 받아 가중치를 갱신한다. 교사가 작성해 둔 모범 답안을 읽는 학습과 달리, 학생이 실제로 만들어 낸 경로를 학습 대상으로 삼는 것이 ‘온폴리시’의 의미다. Open-MOPD 논문 §2.1

예를 들어 계산 질문에는 계산 교사를, 코드 질문에는 코드 교사를 연결한다. 확인한 TRL 구현에서는 각 데이터 행의 teacher_id가 교사 서버 하나를 고른다. 모든 교사의 답을 투표하거나 평균내는 방식이 아니며, 라벨이 없거나 등록되지 않은 교사를 가리키면 오류로 처리한다. 학생이 생성할 때마다 여러 전문 모델을 운영하는 서비스 라우팅과도 목적이 다르다. 이 단계의 산출물은 여러 교사로부터 배운 한 학생의 체크포인트다. 고정 TRL 문서

공식 예제는 수학·코드·지시 준수 교사를 사용한다. 지시 준수는 “문단 두 개로 답하라”, “정해진 형식으로 출력하라”처럼 답의 조건을 지키는 능력이다. 짧은 출력이라도 업무에서는 필수일 수 있다. CSV 열 순서를 틀리거나 허용되지 않은 설명을 붙이면, 내용이 맞아도 다음 시스템이 받지 못하기 때문이다. 고정 예제

질문 비율과 학습 비중 사이에 답변 길이가 있다

학습 손실을 토큰 단위로 합산하면 긴 답변은 더 많은 항을 제공한다. 질문 100개 중 20개를 형식 준수 과제로 배정했다는 사실만으로 그 분야가 전체 토큰의 20%를 차지하지는 않는다. Open-MOPD 연구는 길이 차이, 분야별 수렴 속도, 재사용하는 응답에 붙은 학생 측 보상 정보의 노후화를 나눠 조사했다. 정답 분야 라벨로 교사를 골라 라우팅 오류를 분리한 실험이므로, 현실의 잘못된 라벨이나 혼합 질문까지 해결한 결과는 아니다. 논문 §3·§4

다음은 업무용 모델을 준비하는 팀의 자체 가상 계산이다. 정산 계산, SQL 작성, 정해진 출력 형식 준수를 각각 한 분야로 놓는다. 실제 고객 데이터나 모델 응답을 수집한 사례가 아니다. 길이는 입력 프롬프트를 제외하고, 손실 계산에 유효하게 들어가는 답변 토큰의 평균이라고 가정한다.

분야	질문 수	질문 비율	답변당 유효 토큰 가정	유효 토큰 합계	전체 토큰 비율
정산 계산	40	40%	2,000	80,000	32.79%
SQL 작성	40	40%	4,000	160,000	65.57%
출력 형식	20	20%	200	4,000	1.64%
합계	100	100%	—	244,000	100%

출력 형식의 비율은 4,000 ÷ 244,000, 약 1.64%다. SQL 분야는 질문 수가 정산 계산과 같아도 토큰은 두 배다. 모델이 점점 긴 SQL 해설을 쓰기 시작하면 처음 정한 질문 비율은 그대로인데 학습 구성은 더 바뀔 수 있다.

일반적으로 분야 i의 질문 비율을 pᵢ, 평균 유효 답변 길이를 Lᵢ라고 하면, 토큰 비율은 다음과 같이 예상할 수 있다.

분야 i의 예상 토큰 비율 = pᵢ × Lᵢ / 모든 분야의 (p × L) 합계

이 식은 질문이 여러 번 관측됐을 때의 배분 계산이다. 작은 배치가 매번 같은 비율로 채워진다는 뜻은 아니다. 길이 제한에 잘린 응답, 마스킹된 토큰, 교사 신호가 없는 위치가 있으면 실제 분모부터 확인해야 한다. 현재 TRL 소스에서도 completion mask와 교사 신호 존재 여부를 함께 사용하며, 정규화에 쓰는 토큰 수와 교사별 유효 지표의 분모를 무조건 같은 값으로 취급하면 안 된다. 고정 손실·지표 구현

또한 토큰 비율은 학습에 참여할 양을 보는 단서다. 각 토큰의 손실 크기와 미분값이 다르므로, 1.64%를 “능력을 1.64% 배웠다”거나 “가중치 변화의 1.64%”로 바꿔 말할 수 없다.

형식 과제의 토큰을 20%로 늘리면 해결될까

앞의 평균 길이를 고정하고 계산·SQL 질문 수를 서로 같게 유지한다고 하자. 형식 분야가 토큰의 20%를 차지하게 하려면 형식 질문 비율 q는 아래 조건을 만족해야 한다.

200q / [3,000(1-q) + 200q] = 0.2
q = 15/19 ≈ 78.95%
계산·SQL 질문은 각각 2/19 ≈ 10.53%

처음의 20%를 조금 늘리는 수준이 아니라, 질문의 약 79%를 짧은 과제로 채워야 한다는 계산이다. 이것을 추천 설정으로 복사하면 안 된다. 준비한 형식 데이터가 적으면 같은 질문을 반복해서 볼 수 있고, 다른 분야의 입력 다양성도 줄어든다. 형식 응답을 쓸데없이 길게 늘려 토큰만 맞추는 것은 실제 업무의 짧은 출력 조건과 충돌한다.

이 계산이 제안하는 첫 행동은 재학습 실행보다 현재 학습에 들어간 유효 토큰을 분야별로 세는 것이다. 그다음 질문 샘플링을 바꿀지, 분야별 손실 가중을 검토할지 정한다. 같은 질문 구성에서 손실 가중을 바꾸는 방법과 질문을 더 자주 뽑는 방법은 데이터 다양성·연산량·최적화에 미치는 영향이 다르다. 이번 계산은 어느 쪽의 품질이 더 좋은지 비교하지 않았다.

Open-MOPD는 토큰 비중을 보정하는 것에 더해, 학생과 교사의 남은 차이에 따라 예산을 조절하고 반복 업데이트에서 학생 측 보상 정보를 새로 계산하는 방식을 결합했다. 특정 연구 설정의 개선을 “모든 분야의 토큰만 균등하게 맞추면 된다”로 줄일 수 없는 이유다. 논문 §4

반대 조건도 계산해 볼 수 있다. 세 분야의 평균 길이가 모두 2,000이라면 질문 비율 40·40·20%가 그대로 토큰 비율이 된다. 반대로 SQL 평균 길이만 8,000으로 늘어나면 형식 비중은 약 0.99%로 더 낮아진다. 초기 길이 표 한 장으로 끝내지 않고 학습 구간별 변화를 남겨야 한다. 자체 입력·계산 결과 JSON에는 이 두 반례와 재배분 계산을 함께 담았다. Python 산술만 실행했으며 TRL 학습이나 GPU 벤치마크는 실행하지 않았다.

대시보드에서 세 가지를 같이 읽는다

현재 TRL은 교사별 토큰 비중 teacher_token_frac/<id>와 학생·교사의 분포 차이를 보는 teacher_jsd/<id>를 기록한다. 이름에 JSD가 들어가더라도 설정한 beta에 따라 비교 목적이 달라진다. 같은 학습 설정 안에서 추이를 보고, 서로 다른 beta·온도·후보 토큰 설정의 숫자를 한 순위표로 합치지 않는 편이 타당하다. 고정 TRL 문서

여기에 실제 업무 평가를 붙여야 한다. 정산 질문의 계산 정답, SQL 실행 결과, 출력 형식 검사처럼 분야별로 실패의 의미를 정한다. 다음 표는 제품의 자동 진단 기능이 아니라, 팀이 관측을 보고 다음에 비교할 조건을 고르는 자체 판독표다.

관측한 조합	다음에 확인할 것	아직 내릴 수 없는 결론
형식 토큰이 적고 교사와의 차이도 줄지 않음	유효 길이·마스크·교사 라벨, 샘플링과 가중 조건을 분리한 비교	낮은 토큰 비율만이 실패 원인이라는 확정
토큰 비중은 늘었지만 업무 형식 검사는 개선되지 않음	교사 자체의 형식 준수, 훈련·평가 과제 불일치, 평가 표본	더 많은 학습을 하면 반드시 해결된다는 기대
교사와 가까워졌는데 실제 업무 점수는 하락	교사가 유도하는 출력과 업무 정답의 차이, 기존 능력 회귀	교사와의 분포 차이 감소가 품질 향상이라는 판정
한 분야 점수는 오르고 다른 분야는 하락	분야별 결과를 분리하고 허용할 회귀 기준 확인	전체 평균이 올랐으니 배포해도 된다는 판정

지표를 옮겨 적을 때도 분모가 중요하다. 구간 A에 유효 토큰 100개 중 형식 50개, 구간 B에 900개 중 형식 0개가 있었다면 두 구간을 합친 형식 비중은 50 ÷ 1,000 = 5%다. 비율 50%와 0%의 단순 평균인 25%가 아니다. 확인한 TRL 구현은 이 문제를 피하려고 교사별 비율을 분자·분모 쌍으로 기록한다. 별도 보고서로 내보낼 때 그 의미를 유지해야 한다. 교사별 지표 집계 코드

지표가 비어 있는 경우도 구별한다. 해당 교사에 유효 토큰이 없으면 토큰 비율 0은 의미 있는 값이지만, 그 교사와의 평균 차이는 관측할 수 없다. 차이를 0으로 채우면 “완벽하게 일치했다”는 잘못된 그림이 만들어진다.

TRL 예제와 논문 재현을 구분할 지점

실제로 도입할 팀은 다음 차이를 먼저 기록할 필요가 있다. 11월 5일 확인한 TRL은 main 문서와 experimental.async_distillation 경로다. 이 글은 커밋 bcfb115a5fcc6f367a9a77c65617e747fff8c28d를 기준으로 문서·예제·손실 구현을 대조했다. 설치된 안정 버전이 같은 기능을 가진다고 추정하지 않는다.

확인 대상	자료에서 확인한 범위	도입 시 남는 확인
교사 준비	TRL의 이 경로는 준비된 전문 교사를 합치는 단계	교사 학습과 업무 적합성 평가는 별도
토큰 호환	교사와 학생이 같은 토크나이저를 사용해야 함	토큰 ID·특수 토큰·템플릿과 체크포인트 고정
학습 목적	공식 예제는 beta=1.0, teacher_top_k=1	논문의 top-16 방식과 같은 실험으로 부르지 않음
비동기 실행	생성·교사 평가·학습이 겹쳐 진행됨	생성 시 학생 버전과 업데이트 시점 차이 관찰
결과 해석	발표는 짧은 실행을 소개함	자사 분야별 평가와 회귀 검사 없이 품질 보장으로 전용하지 않음

고정 예제 · 고정 문서 · 논문 목적함수

토크나이저 조건은 단순한 설치 편의가 아니다. 학생이 보낸 토큰 ID를 교사가 같은 단어 조각으로 읽어야 위치별 확률을 비교할 수 있다. 서로 다른 회사의 임의 모델들을 URL만 나열해 연결할 수 있다는 의미로 받아들이면 학습 신호 자체가 어긋날 수 있다.

또한 토큰 예산은 GPU 비용의 견적서가 아니다. 교사는 학생의 전체 문맥을 읽어야 하고, 학생 생성·학습·가중치 동기화도 자원을 쓴다. 위 244,000이라는 수는 가정한 유효 답변 토큰의 합계일 뿐이다. GPU 시간이나 원화 비용으로 바꾸려면 해당 실행 구성의 별도 측정이 필요하다.

첫 시험에서 남길 기록

실무 적용을 시작한다면 분야별 질문 목록과 교사 라벨부터 확정한다. “계산한 결과를 JSON으로 내라”처럼 두 능력이 겹친 질문은 한 라벨이 무엇을 대표하는지 합의하고, 별도의 혼합 과제 평가에도 남긴다. 분야 라벨이 정확하다고 가정한 연구 결과를 실제 분류기의 성능으로 가져오지 않는다.

그다음 동일한 입력 묶음과 실행 조건에서 질문 수, 유효 토큰 수, 교사와의 차이, 업무 정답을 함께 기록한다. 예를 들어 형식 토큰이 적다는 사실을 확인했다면, 한 번에 샘플링과 손실 가중과 길이 제한을 모두 바꾸지 않는다. 변경 하나를 선택하고 기존 분야의 결과도 나란히 남겨야 다음 선택의 근거가 생긴다.

학생·교사 체크포인트 / 토크나이저·템플릿 / TRL 커밋:
분야 라벨 기준 / 혼합 과제 처리 / 평가 입력 버전:
관측 구간 / 분야별 실제 질문 수 / 유효 답변 토큰 수:
길이 제한·잘림 / 마스크·교사 신호 누락 / 생성 당시 학생 버전:
분야별 teacher_token_frac / teacher_jsd와 목적함수 설정:
업무 정답 / 형식 실패 / 다른 분야의 회귀:
이번에 바꾼 조건 하나 / 유지한 조건 / 다음 비교:

모든 팀이 MOPD를 시작할 필요는 없다. 필요한 교사가 아직 없거나, 몇 가지 출력 형식을 검증·재시도하는 것만으로 업무가 해결된다면 그 경로부터 비교할 수 있다. 여러 전문가의 능력을 단일 배포 모델로 모을 필요가 분명할 때, 질문 배분표에 토큰과 품질이라는 두 열을 더하는 것이 이 글의 출발점이다.

여러 기능을 합치는 다른 구조와 비교하려면 Granite Switch의 모듈별 업데이트를, 평가 판정이 입력 조건에 따라 흔들리는 문제는 AI 신규성 심사 연구를 이어 읽을 수 있다. 재실험 때 이 표를 찾으려면 상단 저장 기능을, 후속 분석은 AI 시스템 모음과 RSS를 이용할 수 있다.