bj.choi - notes

[논문 리뷰] Mid-training 이해하기

Updated:

Mid-training은 Fine-tuning처럼 정답 응답을 맞추는 단계가 아니라, 터미널 모델에 필요한 능력 분포와 데이터 흐름을 다시 조정하는 continued training 단계다.

1. 왜 Mid-training이 헷갈렸나

처음에는 Mid-training이라는 용어 자체가 낯설었습니다. 이미 학습된 모델을 다시 학습시키는 단계라면 Fine-tuning과 무엇이 다른지부터 모호했습니다. 둘 다 학습된 모델에 데이터를 더 넣는 것처럼 보였기 때문입니다.

논문을 읽고 나니 차이는 데이터 출처보다 학습 위치, 목적, 포맷에 가깝게 정리됐습니다. Fine-tuning은 보통 사용자 지시와 이상적 응답을 맞추는 쪽에 가깝습니다. 반면 Mid-training은 pre-training 이후, SFT/post-training 이전에 모델의 능력 분포를 다시 조정하는 continued training 단계에 가깝습니다.

이 글은 그 혼란에서 출발합니다. Mid-training을 Fine-tuning의 다른 이름으로 보지 않고 왜 별도 단계로 봐야 하는지 정리하는 것이 목적입니다. 특히 터미널 모델을 만든다면 어떤 데이터 관점으로 해석할 수 있는지까지 함께 봅니다.

2. 제가 정리한 Mid-training 정의

논문 기준 정의는 이렇습니다.

제가 이해한 정의는 이렇습니다.

Mid-training은 SFT처럼 정답 응답을 직접 맞추는 단계라기보다, 다음 토큰을 예측하는 방식으로 학습하면서 목표 도메인의 데이터에서 반복되는 패턴, 구조, 해석 능력을 강화하는 단계입니다.

터미널 모델 관점에서 패턴, 구조, 해석은 이렇게 풀어볼 수 있습니다.

보강 문장:

데이터 믹스는 범용성을 유지하면서 특화성/해석 능력을 보강하기 위해 조절합니다.

Learning rate scheduling은 언어 모델이 고품질/목표 데이터의 신호를 안정적으로 흡수하고 기존에 배운 범용 능력이 과하게 흔들리지 않도록 조절하는 역할을 합니다.

Long-context mid-training은 긴 로그/문서/작업 episode를 continuation corpus로 학습시켜 모델이 앞선 정보와 뒤의 행동 연결, 여러 파일 사이의 관계 파악, 반복 실패 회피 능력을 강화하게 합니다. 동시에 context length와 position encoding 같은 설정을 조정해 긴 입력을 실제로 처리할 수 있게 만듭니다.

3. Pre-training, Mid-training, SFT/Post-training의 차이

세 단계를 구분할 때 기준은 이미 학습된 모델을 다시 학습하느냐가 아닙니다. 그 기준으로 보면 Mid-training과 Fine-tuning은 둘 다 비슷해 보입니다. 더 봐야 할 기준은 학습 위치, 목적, 데이터 포맷, objective입니다.

SFT, post-training, preference tuning, RLHF/DPO는 엄밀히는 서로 다른 단계입니다. 다만 이 글에서는 Mid-training과 대비하기 위해 사용자 지시와 선호 행동에 맞추는 후반 학습 흐름을 SFT/Post-training으로 묶어 설명하겠습니다.

단계 위치 목적 주된 데이터 형태 터미널 모델 예시
Pre-training 초기 대규모 학습 넓은 언어, 지식, 코드, 문서 패턴 학습 웹, 책, 코드, 위키, 논문 등 대규모 corpus 코드와 문서의 일반 구조를 배움
Mid-training Pre-training 이후, SFT 이전 범용성을 유지하면서 목표 능력의 병목 보강 목표 도메인 continuation corpus, 고품질 데이터 mix, long-context corpus 로그, tool output, patch, 검증 흐름을 학습
SFT/Post-training Mid-training 이후 사용자 지시, 응답 형식, 선호 행동에 맞춤 instruction-response pair, preference data, RL/RLHF/DPO 데이터 사용자 요청에 맞춰 어떻게 답할지 학습

구분은 단순합니다.

4. Data Mix를 어떻게 잡을까

Mid-training은 고품질 데이터를 많이 넣는 단계만은 아닙니다. 목표 능력에 맞춰 데이터 비율을 조절하는 일이 핵심입니다. Mid-training의 목표가 범용 능력을 유지하면서 특화 능력을 올리는 데 있기 때문입니다.

예를 들어 코딩 데이터를 많이 넣으면 코드 작성과 디버깅 능력은 좋아질 수 있습니다. 하지만 일반 독해, 상식, 한국어 이해, 짧은 문맥 응답 안정성이 같이 유지되는지는 따로 봐야 합니다. 그래서 목표 능력 데이터와 보존 능력 데이터를 함께 섞어야 합니다.

터미널 모델을 목표로 한다면 데이터 축은 대략 이렇게 나뉩니다.

이때 Codex 작업 로그는 개인 대화 기록 그 자체가 아닙니다. 제대로 정제하면 사용자 요청, tool call, output 해석, 다음 행동, 검증 보고가 이어지는 작업 흐름 데이터가 될 수 있습니다. 다만 개인 작업 습관과 특정 포맷에 과적합될 수 있으므로 처음부터 큰 비율로 넣는 것은 위험합니다.

첫 실험이라면 Codex 로그를 전체의 20% 이하로 두고 나머지는 외부 코딩/문서/추론/일반 독해 데이터로 채우는 식이 더 안전합니다.

5. Learning Rate Scheduling이 맡는 일

데이터 믹스가 무엇을 배울지의 문제라면, learning rate scheduling은 얼마나 안정적으로 배울지의 문제에 가깝습니다.

Pre-training 초반의 모델은 아직 많은 것을 모릅니다. 그래서 큰 폭으로 빠르게 학습할 필요가 있습니다. Mid-training 시점의 모델은 이미 언어, 코드, 문서 구조, 일반 지식을 어느 정도 배운 상태입니다. 이때 목표 데이터의 비율을 바꾸면서 learning rate까지 너무 크게 유지하면 고품질 데이터의 세밀한 신호를 안정적으로 흡수하지 못하거나 기존에 배운 범용 능력을 흔들 수 있습니다.

그래서 Mid-training에서는 learning rate annealing이나 multi-stage schedule이 중요해집니다. 저는 이렇게 이해했습니다.

Learning rate scheduling은 언어 모델이 고품질/목표 데이터의 신호를 안정적으로 흡수하고 기존에 배운 범용 능력이 과하게 흔들리지 않도록 조절하는 역할을 합니다.

논문에서는 이 현상을 gradient noise scale, information bottleneck, curriculum learning 관점에서 설명합니다. 이 글에서는 수식까지 들어가기보다, 후반 학습에서는 데이터 분포와 학습률을 함께 조정해야 한다는 직관만 가져가겠습니다.

발표나 블로그에 그림을 넣는다면 다음 자료가 적합합니다.

6. Long-context Extension은 데이터만으로 끝나지 않는다

Long-context는 모델이 긴 입력을 처리하도록 구조와 데이터를 함께 조정하는 문제입니다. 긴 데이터를 넣는다고 해결되는 문제가 아닙니다.

데이터 측면에서는 긴 로그, 여러 파일, README, 테스트 출력, diff, 이전 tool output처럼 앞에서 본 정보와 뒤의 행동을 연결해야 하는 샘플이 필요합니다. 모델 설정 측면에서도 context length, position encoding 조정(RoPE/YaRN/LongRoPE 계열), attention 관련 조정이 필요합니다. 긴 데이터를 넣었더라도 모델이 그 길이를 안정적으로 처리할 수 없다면 long-context 능력은 제대로 생기기 어렵습니다.

대표적인 용어는 다음 정도로 이해하면 됩니다.

터미널 모델에서는 이 문제가 더 직접적으로 드러납니다. 하나의 요청을 처리할 때 여러 파일을 읽고 테스트 로그를 본 뒤 패치를 만들고 다시 검증해야 합니다. 이때 모델은 초기 목표를 잃지 않아야 하고 앞선 output과 뒤의 행동을 연결해야 하며 같은 실패를 반복하지 않아야 합니다.

Long-context mid-training은 긴 로그/문서/작업 episode를 continuation corpus로 학습시키는 데이터 문제이자, 긴 입력을 실제로 처리할 수 있게 만드는 학습 설정 문제입니다.

7. Codex 로그를 데이터로 보면

Codex 로그의 가치는 두 가지입니다.

Codex 로그를 그대로 블로그에 넣을 필요는 없습니다. 원문보다 구조가 중요합니다. 예를 들어 실제 로그에서 확인되는 흐름은 아래처럼 익명화할 수 있습니다. 아래 예시는 “잘못된 경로 가정 -> 실패 출력 -> 실패 원인 해석 -> 보정된 다음 행동” 흐름을 일반화한 것입니다.

<user_request>
보고서 추출 기능이 제거된 것 같은데, 현재 저장소와 기존 백엔드를 비교해서 확인해줘.
</user_request>

<assistant_update>
현재 저장소와 기존 백엔드에서 보고서/docx 관련 엔드포인트, 서비스, 의존성을 비교해보겠다.
</assistant_update>

<tool_call>
name: exec_command
arguments:
  cmd: "rg -n 'docx|report|download|export' backend frontend"
  workdir: "<CURRENT_REPO>"
</tool_call>

<tool_output>
exit_code: 2
stderr:
  "rg: backend: No such file or directory"
  "rg: frontend: No such file or directory"
</tool_output>

<interpretation>
현재 저장소의 실제 디렉터리명이 backend/frontend가 아니라 번호가 붙은 이름이라 첫 검색이 실패했다.
</interpretation>

<next_action>
실제 디렉터리명을 확인한 뒤, 보정된 경로로 다시 검색한다.
</next_action>

이런 데이터는 instruction-response pair라기보다 continuation corpus에 가깝습니다. 모델이 최종 답변 하나만 보는 것이 아니라, 요청을 읽고 도구를 호출하고 실패 출력을 해석한 뒤 다음 행동을 고르는 흐름을 보기 때문입니다.

정제 원칙은 간단합니다.

블로그나 학습 데이터 예시에는 원문을 그대로 넣기보다, 위처럼 구조만 살린 mini segment를 사용하는 편이 안전합니다.

8. 실패와 멈춤도 학습 데이터다

실패 데이터는 무조건 나쁜 데이터가 아닙니다. 터미널 모델은 실패를 피하는 것뿐 아니라 실패를 해석하고 회복하는 법도 배워야 합니다. 다만 실패 기록을 그대로 많이 넣으면 위험합니다. 모델이 잘못된 추론이나 무관한 명령 반복까지 따라 할 수 있기 때문입니다.

좋은 실패 데이터는 다음 흐름을 가져야 합니다.

실패 관찰 -> 실패 해석 -> 회복/복구 행동 -> 재검증 성공

짧은 예시는 아래와 같습니다.

<tool_call>
cmd: "python -c '...'"
</tool_call>

<tool_output>
exit_code: 127
stderr: "command not found: python"
</tool_output>

<interpretation>
현재 환경에는 python 명령이 없고 python3를 사용해야 한다.
</interpretation>

<recovery_action>
cmd: "python3 -c '...'"
</recovery_action>

<verification_output>
exit_code: 0
stdout: "expected result ..."
</verification_output>

이 흐름은 실패 자체보다, 실패를 어떻게 읽고 다음 행동으로 복구하는지 보여주는 데 의미가 있습니다.

좋은 멈춤 데이터는 다음 흐름을 가져야 합니다.

사용자 요청 -> 위험 신호 발견 -> 위험 이유 설명 -> 사용자 확인 요청 또는 안전한 대안 제시

예시는 아래와 같습니다.

<user_request>
빌드 산출물이 꼬인 것 같으니 프로젝트 폴더에서 불필요한 파일을 전부 지워줘.
</user_request>

<proposed_command>
rm -rf <PROJECT_DIR>/*
</proposed_command>

<risk_signal>
데이터 삭제 범위가 넓고, 소스 파일까지 삭제될 수 있다.
</risk_signal>

<safe_decision>
바로 삭제하지 않는다. 먼저 삭제 후보를 list/dry-run으로 확인하고, 실제 삭제 전 사용자 확인을 요청한다.
</safe_decision>

좋은 멈춤 데이터는 모델이 무조건 거절하도록 만드는 데이터가 아닙니다. 진행해야 할 때와 멈춰야 할 때를 구분하도록 만드는 데이터입니다.

9. 첫 실험용 데이터 믹스 가설

여기서의 비율은 정답 레시피가 아니라 첫 실험을 위한 가설입니다. 목적은 “터미널 모델이 사용자 요청을 작은 단위로 안전하게 수행하고 실패를 해석하며 필요한 경우 멈출 수 있는가”를 보는 데 있습니다.

초기 가설에서는 Codex 로그를 20% 이하로 둡니다. Codex 로그는 목표 도메인에 매우 가깝지만 개인 작업 습관과 특정 도구 포맷에 과적합될 수 있습니다. 나머지는 외부 데이터로 일반화, 코딩, 문서, 추론 능력을 보완합니다.

예시 mix는 이렇게 잡습니다.

데이터 축 비율 가설 역할
외부 코딩/디버깅/CLI 데이터 15% 코드 수정, 명령 실행, 디버깅의 일반 능력 보강
외부 기술 문서/README/API/log 데이터 13% 문서와 로그를 읽고 작업 맥락을 파악하는 능력 보강
한국어 작업 지시 이해용 continuation 데이터 13% 한국어 요청을 작업 단위로 해석하는 능력 보강
수학/논리 추론 데이터 11% 단계적 추론, 조건 처리, 검산 습관을 전이 가능한 방식으로 보강
일반 고품질 웹/상식/독해 보존 데이터 13% 일반 독해, 상식, 언어 능력 보존
정제된 Codex 작업 로그 continuation 20% 사용자 요청, tool call, output 해석, 다음 행동, 검증 보고 흐름 학습
외부 long-context 로그/문서 데이터 13% 긴 로그와 여러 파일 사이의 관계를 유지하는 능력 보강

Codex 로그 20% 내부도 다시 나눕니다.

Codex 로그 내부 유형 전체 mix 기준 역할
짧은 segment 14% 다음 행동과 output 해석을 반복 학습
긴 episode 2% 목표 유지와 장기 context 연결
좋은 멈춤 segment 4% 위험하거나 불명확한 상황에서 사용자 확인

이 비율의 의도는 긴 작업을 한 번에 끝까지 밀어붙이는 모델이 아니라, 작은 단위로 진행하고 사용자와 상호작용하며 목표를 달성하는 모델을 먼저 보려는 데 있습니다.

10. 평가는 작은 터미널 작업부터

논문에서는 Mid-training 효과를 평가할 때 일반 지식, reasoning, 수학, 코딩, 다국어, long-context benchmark를 함께 봅니다. “Mid-training 전용 단일 benchmark”가 따로 있다기보다, Mid-training의 목표 능력에 맞춰 여러 benchmark를 묶어 봅니다.

Mid-training은 특정 능력만 올리는 것이 아니라, 목표 능력을 올리면서 범용 능력이 크게 무너지지 않는지도 봐야 하기 때문입니다.

대표 benchmark는 범주별로 이렇게 볼 수 있습니다.

다른 Mid-training survey는 여기에 agent/tool-use와 code fixing 계열도 포함합니다. 참고용으로만 짧게 보면 이렇습니다.

이 계열은 터미널 모델 사례와 더 직접적으로 맞물립니다. 다만 이 글의 첫 실험 설계에서는 이 benchmark를 바로 쓰기보다, 작은 터미널 작업 평가를 먼저 구성하는 쪽이 더 현실적입니다.

터미널 모델 실험에서는 논문 benchmark만으로 충분하지 않습니다. 우리가 보고 싶은 것은 “작은 터미널 작업을 안전하게 수행하는가”이기 때문입니다. 큰 프로젝트 하나를 오래 맡기는 평가보다, 작은 작업을 여러 개 구성하는 쪽이 더 맞습니다.

목표 능력 평가는 다음 항목으로 구성합니다.

예시 태스크:

보존 능력 평가는 다음을 봅니다.

안전/멈춤 능력 평가는 다음을 봅니다.

예시 태스크:

11. 결론

Mid-training은 Fine-tuning의 다른 이름이 아닙니다. SFT처럼 정답 응답을 직접 맞추는 단계도 아닙니다.

이 글에서 정리한 Mid-training은 이미 넓은 능력을 가진 모델을 목표 도메인에 맞게 다시 조정하는 continued training 단계입니다. 핵심은 데이터 믹스, learning rate scheduling, long-context extension입니다.

터미널 모델 관점에서는 사용자 요청, tool call, output 해석, 다음 행동, 검증 보고의 흐름을 continuation corpus로 구성할 수 있습니다. 여기에 실패 복구와 좋은 멈춤 데이터를 포함하면 단순히 많이 실행하는 모델이 아니라 안전하게 진행하고 필요할 때 멈출 수 있는 모델을 목표로 삼을 수 있습니다.

References