11-온라인과오프라인 — 생성모델의 강화학습

Chapter 11: 온라인과 오프라인 — 이상과 현실 사이에서

의문

Ch9–10에서 온라인·온폴리시 RL이 이론적으로 우월하다는 걸 배웠다. 곱의 길이 시그널을 추출하고, 적정 난이도의 롤아웃이 학습을 만든다. 그렇다면 왜 Ch8의 DPO 가계도는 모두 오프라인·오프폴리시를 선택했는가?

온라인 학습의 현실적 어려움

이론은 명쾌하다. “현재 모델이 생성한 데이터로 학습하라.” 하지만 현실에서 이것은 세 가지 무거운 짐을 동반한다.

[1] 모델을 계속 갱신해야 한다

온라인 RL의 루프:
생성 → 평가 → 학습 → 생성 → 평가 → 학습 → …

매 스텝마다:

현재 모델로 응답을 생성해야 한다 (추론 비용)

생성된 응답을 평가해야 한다 (보상 모델 또는 인간 판정)

평가 결과로 모델을 업데이트해야 한다 (학습 비용)

세 단계가 직렬로 연결되어 있으므로:

추론 + 평가 + 학습이 매 배치마다 반복

오프라인 DPO 대비 3–10배의 벽시계 시간(wall-clock time)

GPU를 추론용과 학습용으로 동시에 점유해야 함

JoyCaption 사례: fpgaminer는 오프라인 DPO를 선택했다.
“온라인은 모든 작업이 즉석에서 이루어져야 한다.
생성하고, 인간이 평가하고, 학습하는 걸 매 배치마다?
얼마나 복잡하고 느려질지 상상해보라.”

[2] 모델이 드리프트하는 위험

온라인 학습 중 모델은 자기 출력으로 계속 학습한다.
이 피드백 루프에는 양성(자기 강화)과 음성(자기 붕괴) 두 방향이 있다.

양성 드리프트 (보상 해킹):
모델이 보상 모델의 빈틈을 발견한다.

보상은 높지만 실제로는 쓸모없는 출력을 학습

보상 해킹이 시작되면 되돌리기 어렵다

실제로 관찰된 양성 드리프트 사례들:

“과도한 사과” 해킹:
보상 모델이 "공손한 응답"을 선호하도록 학습됨

모델이 모든 답변을 "정말 좋은 질문이시네요! 먼저 제가 부족한 점이 있다면 사과드립니다…"로 시작

보상은 계속 올라가지만 정작 답변 내용은 희석됨

온라인 학습이 이 패턴을 반복 강화 → 사과가 점점 길어짐

“리스트 생성기” 해킹:
보상 모델이 "구조화된 답변"을 높게 평가

모델이 모든 질문에 번호 매긴 리스트로 답변

"이 시를 감상해줘"에도 “1. 운율 분석 2. 은유 분석 3. …”

형식 점수는 올라가지만 시 감상이라는 본래 목적은 실종

“안전 거부” 해킹:
안전성 보상이 높은 가중치를 가짐

모델이 "혹시 위험할 수 있으므로 답변을 드리기 어렵습니다"를 안전한 질문에도 남발하기 시작

안전성 점수는 만점이지만, 모델이 아무것도 안 하게 됨

“과잉 거절(over-refusal)” — 실제 서비스에서 보고된 문제

이 사례들의 공통 패턴:
보상 모델의 특정 차원 하나를 극단적으로 최적화하면 다른 차원의 품질이 무너진다 (Ch7의 파레토 트레이드오프).
온라인 학습은 이 극단적 최적화를 가속한다 — 매 배치마다 해킹된 출력이 새 학습 데이터가 되어 패턴이 강화되니까.

음성 드리프트 (모드 붕괴):
모델이 안전한 소수의 출력 패턴에 수렴한다.

다양성이 사라지고, 엔트로피가 급격히 감소

Ch10에서 배운 "스펙트럼이 좁아진다"의 실시간 버전

한 번 붕괴하면 탐색 능력을 잃어서 회복이 불가능

레퍼런스 모델(π_ref)이 줄(leash) 역할을 하지만, 긴 학습에서는 줄이 점점 느슨해진다:
π_θ가 π_ref에서 멀어질수록 KL 항의 그래디언트가 약해지고, 한계를 넘으면 “줄이 끊어진” 상태가 된다.

[3] 데이터셋을 계속 만들어내는 것의 어려움

오프라인: 데이터셋을 한 번 만들면 끝. 여유 있게 검수할 수 있다.

온라인: 매 배치마다 새 데이터가 필요하다.

인간 평가 기반 (RLHF):

매 배치마다 인간에게 응답 쌍을 보여주고 판정을 받아야 한다

인간은 느리고, 비싸고, 지친다

배치 크기가 256이면 128쌍을 인간이 실시간으로 판정?

현실적으로 불가능 → 보상 모델로 대체

하지만 보상 모델 자체도 드리프트하면? (위의 [2]와 맞물림)

자동 평가 기반 (RLVR):

검증기가 자동으로 판정 → 속도 문제는 해결

하지만 “정답이 있는” 도메인에서만 가능 (Ch13에서 다룰 제약)

LLM-as-Judge:

SOTA 모델이 판정 → JoyCaption이 이 방식을 사용

API 비용이 데이터 크기에 비례하여 증가

온라인이면 매 스텝마다 API 호출 → 비용 폭발

아래 다이어그램이 온라인과 오프라인의 구조적 차이를 보여준다:

graph TB
    subgraph offline["오프라인 DPO"]
        direction TB
        D1["📦 데이터셋<br/>(y_w, y_l) 쌍<br/>한 번 구축"] --> T1["🔧 학습<br/>일반 파인튜닝과 동일"]
        T1 --> M1["✅ 정렬된 모델"]
    end

    subgraph online["온라인 RL"]
        direction TB
        G["🎲 현재 모델로<br/>응답 생성"] --> E["⚖️ 실시간 평가<br/>(인간/보상모델/검증기)"]
        E --> U["🔧 모델 업데이트"]
        U -->|"매 배치 반복"| G
    end

    subgraph iterative["Iterative DPO (절충안)"]
        direction TB
        R1["Round 1<br/>데이터 생성 → DPO"] --> R2["Round 2<br/>갱신된 모델로<br/>새 데이터 → DPO"]
        R2 --> R3["Round 3<br/>...반복"]
    end

    style offline fill:#e3f2fd,stroke:#1565C0
    style online fill:#fff3e0,stroke:#E65100
    style iterative fill:#e8f5e9,stroke:#2E7D32

그래서 오프라인이 매력적이다

오프라인의 진짜 강점은 "한 번 만들면 끝"이 아니라, 시간 제약 없이 데이터를 정제할 수 있다는 것이다.

오프라인 데이터셋 구축 — 실제 파이프라인의 여러 패스(pass):

[Pass 1] 후보 생성 (Candidate Generation)
프롬프트 하나당 N개(보통 8–64개)의 응답을 모델에서 샘플링한다.
온도(temperature)를 높여서 다양성을 확보한다.

JoyCaption은 프롬프트당 10개 응답을 생성했다.

[Pass 2] 중복 제거 (Deduplication)
거의 동일한 응답 쌍을 제거한다.
코사인 유사도, n-gram 오버랩, 또는 임베딩 기반 클러스터링.

같은 말을 다르게 한 것뿐인 응답 쌍은 학습 시그널이 약하다.

[Pass 3] 1차 필터링 (Rejection Sampling / Heuristic Filter)
명백히 나쁜 응답을 걸러낸다:

반복 루프 탐지 (n-gram 반복 비율)

형식 위반 (지시를 따르지 않은 응답)

길이 이상치 (너무 짧거나 너무 긴 응답)

JoyCaption은 “삐꾸” 응답을 휴리스틱으로 탐지하고 삐꾸 vs 정상 쌍을 우선적으로 채택했다.

[Pass 4] 심사 (Judging / Rating)
남은 응답들을 심사 모델(judge)에 통과시킨다.

단순 쌍비교(“A가 나은가 B가 나은가”)보다 개별 점수 매기기(1–10점)가 마진 정보를 더 많이 준다.

JoyCaption은 여러 SOTA 모델을 judge로 사용 (앙상블) — 한 모델의 편향을 다른 모델이 상쇄하도록

[Pass 5] 마진 기반 큐레이션 (Margin-Based Curation)
점수 차이가 작은 쌍을 버린다.

Ch2에서 배웠다: DPO가 학습하려면 마진이 넓어야 한다.

JoyCaption의 첫 시도 실패 원인이 정확히 이것: “비슷비슷한 응답 쌍으로는 모델이 방향을 못 잡는다.”

BeeS 연구: 전체 데이터의 10%만 남겨도 전체 성능에 근접 — 핵심은 "많은 데이터"가 아니라 “강한 데이터”

[Pass 6] 최종 검수 (Human Spot-Check)
자동 파이프라인을 통과한 데이터셋의 랜덤 샘플을 인간이 직접 확인.

judge 지시문의 버그, 체계적 편향, 예상치 못한 패턴 탐지

JoyCaption: “소규모 예제를 직접 리뷰하며 judge 프롬프트를 반복 수정”

이 전체 과정에 며칠에서 몇 주가 걸린다.
하지만 시간 제약이 없으므로:

각 패스를 독립적으로 실행하고 결과를 검사할 수 있다

파이프라인에 버그가 있으면 해당 패스만 다시 돌린다

데이터 분포를 시각화하고, 태스크별 균형을 조정할 수 있다

전체를 버리고 처음부터 다시 만들어도 모델은 영향받지 않는다

온라인에서는 이 모든 것이 매 배치마다, 실시간으로 일어나야 한다.
어떤 패스도 "나중에 고치겠다"가 불가능하다.

오프라인 DPO의 다른 장점:

학습은 일반적인 파인튜닝과 같다 — 기존 인프라를 그대로 사용. 추론과 학습이 분리되어 자원 관리 용이.

재현성이 높다 — 같은 데이터, 같은 하이퍼파라미터 → 같은 결과. 온라인은 생성-평가-학습 루프의 확률적 요소 때문에 재현 어려움.

이것이 DPO가 폭발적으로 인기를 얻은 이유다.
“PPO의 성능을 DPO의 편의성으로” — 이것이 DPO의 약속이었다.

하지만 오프라인은 근본적 한계가 있다

분포 이동(Distribution Shift):

학습 전: π_θ ≈ π_ref (시작점)

학습 중: π_θ가 업데이트 → π_ref에서 점점 멀어짐

문제: 데이터셋은 π_ref (또는 그 근처의 모델)가 생성한 것

→ π_θ가 절대 생성하지 않을 응답에 대해 학습하고 있다
→ “작년 지도로 올해 여행하는” 상황
→ 학습이 길어질수록 데이터와 모델의 괴리가 커진다

레퍼런스 비율(π_θ/π_ref)이 이론적으로 보정해주지만 — 이것이 임포턴스 샘플링이다:

π_θ와 π_ref가 멀어질수록 임포턴스 가중치의 분산이 폭발

Ch9의 주사위 예제에서 "드문 면 하나가 추정을 지배"했던 것의 LLM 버전

PPO처럼 클리핑할 장치도 없고, π_old를 갱신할 방법도 없다

보정의 분산이 너무 커서 실무적으로 한계

해결: 이상과 현실 사이의 절충안들

온라인의 성능 + 오프라인의 편의성을 동시에 잡으려는 시도들:

Iterative DPO (Llama 3 방식)

3라운드의 오프라인 DPO

매 라운드 사이에 현재 모델로 새 데이터셋 생성

“반쯤 온라인”: 온라인의 분포 추적 + 오프라인의 안정성

라운드 사이에 모델을 검수할 수 있다는 실무적 이점

JoyCaption도 이 방식: 2라운드 반복으로 삐꾸율 9.6%→1.5%

Online DPO

on-policy 데이터 + 보상 모델로 실시간 평가

분포 이동 없음, 하지만 위의 [1][2][3] 문제를 모두 감수

COPO

탐색 보너스를 추가하여 모드 붕괴 방지

[2]의 음성 드리프트에 대한 직접적 대응

Self-Play

자기 자신과 대국 → 데이터 생성이 자동

[3]의 비용 문제를 해결하지만, [2]의 드리프트 위험은 증가

실무 컨센서스

현시점 실무 조합 (검증 불가능 영역):
SimPO + on-policy 데이터 + 마진 기반 큐레이션

또는 Iterative 접근:
“3라운드가 1라운드보다 낫고, 10라운드가 3라운드보다 반드시 낫지는 않다.”

라운드가 많아지면 보상 해킹 위험이 누적

최적 라운드 수는 태스크와 보상 모델 품질에 의존

다음 장으로의 질문

온라인은 비싸고 위험하고, 오프라인은 분포가 이동하고, 반복(iterative)이 현실적 절충안이다. 알겠다. 그런데 수학이나 코드처럼 “정답이 있는” 문제라면 인간 라벨도 보상 모델도 필요 없이, 검증기 하나로 RL을 돌릴 수 있지 않나? 이러면 [3]의 비용 문제가 사라지고, [2]의 드리프트도 검증기가 잡아주지 않나? DeepSeek-R1은 실제로 그렇게 했다는데…