Training language models to follow instructions with human feedback 해부: InstructGPT는 사람의 선호를 어떻게 학습했나

2단계 세 번째 논문. 이 글은 Ouyang 외, Training language models to follow instructions with human feedback arXiv v1(2022-03-04)을 직접 읽고 썼다. 여기서 InstructGPT는 논문의 GPT-3 기반 SFT(Supervised Fine-Tuning, 지도 미세조정)·RM(Reward Model, 보상 모델)·PPO(Proximal Policy Optimization, 근접 정책 최적화) 실험을 뜻한다. 현재 API 모델, 현행 안전 정책, 또는 “인간 전체의 가치”를 뜻하지 않는다. 논문과 함께 공개된 OpenAI artifact 저장소 commit 5c0534c와, 이전 세대의 공개 RLHF 구현인 OpenAI lm-human-preferences commit cbfd210을 구분해 읽었다.

이 글에서 얻을 답과 범위

GPT-3 같은 다음 token 예측기는 인터넷 문장을 그럴듯하게 이어 쓰도록 학습된다. 사용자가 “두 문장만, 근거 없는 말은 하지 말고, 위험한 요청이면 안전하게 설명해 줘”라고 한 의도를 기본 목표로 배우지는 않는다.

사전학습의 질문: 앞 문장 뒤에 어떤 token이 자주 왔는가?
사용자의 질문: 이 요청을 도움이 되고, 사실에 맞고, 해롭지 않게 처리했는가?

InstructGPT 논문은 이 틈을 사람의 demonstration(시범 답변)과 ranking(선호 순위)으로 줄이려 했다.

GPT-3 pretrained model
  → SFT: 사람이 쓴 좋은 답을 모방
  → RM: 여러 답 중 사람이 고른 답을 점수화
  → PPO: RM 점수는 높이고 SFT에서 너무 멀어지지 않게 policy를 조정
  → PPO-ptx: 위 과정에 사전학습 데이터 likelihood도 섞어 성능 퇴행을 완화

이 글을 다 읽으면 다음을 설명할 수 있어야 한다.

1. SFT, RM, PPO, PPO-ptx는 각각 어떤 입력·정답·출력을 가지며 왜 세 단계가 필요한가?
2. 사람의 “A가 B보다 낫다”라는 비교를 scalar reward(숫자 보상)로 어떻게 바꾸는가?
3. RM의 점수만 높이면 왜 위험하며, KL(Kullback–Leibler, 쿨백-라이블러) penalty가 어떤 브레이크 역할을 하는가?
4. 왜 1.3B InstructGPT가 175B GPT-3보다 사람에게 선호될 수 있었나?
5. PPO-ptx의 pretraining mix는 alignment tax(정렬 대가)를 무엇으로 완화하고 무엇은 해결하지 못했나?
6. 논문의 40명 labeler(라벨러, 사람 평가자) 선호를 왜 “인류의 가치”라고 부르면 안 되는가?
7. 백엔드·DBA(Database Administrator, 데이터베이스 관리자) 관점에서 RLHF data pipeline·평가·권한 경계를 어떻게 운영해야 하는가?

범위: 원 논문 §1–§5, Appendix A–E의 prompt data, labeler, SFT/RM/PPO training, 평가, safety·공정성·한계를 설명한다. DPO(Direct Preference Optimization, 직접 선호 최적화), RLAIF(Reinforcement Learning from AI Feedback, AI 피드백 강화학습), 현행 ChatGPT 정책·가격·모델 버전은 이후 별도 주제다. 이 글은 어떤 실제 DB 변경이나 tool 실행 권한을 LLM에 주는 방법이 아니다.

먼저 외울 한 문장

InstructGPT는 GPT-3를 먼저 사람이 쓴 좋은 답으로 SFT하고, 사람이 여러 모델 답 중 선호한 순위로 RM을 학습한 뒤, RM 점수는 높이고 SFT policy와의 KL 거리는 벌점으로 주는 PPO를 적용해 사용자의 instruction을 더 잘 따르도록 만든 연구다.

사람, 특정 선호 데이터, 벌점, 더 잘 네 단어가 빠지면 잘못된 기억이 된다.

왜 필요한가: 다음 token을 잘 맞혀도 사용자의 의도는 놓친다

12살 비유: 말 잘 이어 쓰는 아이와 부탁을 이해하는 비서

두 아이가 있다.

사전학습 아이
  인터넷에서 본 문장의 다음 낱말을 아주 잘 맞힌다.
  하지만 "세 문장으로만", "모르면 모른다고", "위험한 방법은 설명하지 마"를
  항상 중요하게 여기도록 배운 것은 아니다.

InstructGPT 아이
  선생님이 여러 답을 보여 주고 "이 답이 더 도움이 된다"고 표시한다.
  좋은 답을 따라 쓰고, 여러 답 중 선생님이 고른 답의 특징을 점수로 배운다.

언어 모델의 pretraining objective(사전학습 목적함수)는 대규모 text에서 다음 token 확률을 높이는 일이다. 이는 언어·지식·패턴의 강한 기반을 주지만, “사용자 의도에 맞는 도움, 진실성, 무해성”과 동일한 수학 목표가 아니다.

논문 확인: 원 논문 초록·§1은 큰 LM(Language Model, 언어 모델)도 untruthful(사실과 다른), toxic(유해한), unhelpful(도움이 안 되는) 출력을 낼 수 있으며, next-token prediction과 user intent가 다르다고 설명한다. 저자들은 목표 행동을 helpful(도움이 됨), honest(기만하지 않음), harmless(해를 피함)라는 틀로 논의했다. 다만 이것은 평가자·연구자가 만든 operational definition(운영상 정의)이지 객관적으로 완결된 도덕 공식이 아니다.

prompt engineering만으로는 왜 부족했나

few-shot prompt(소수 예시 프롬프트)는 “이런 형식으로 답하라”는 힌트를 input context에 넣는다. 하지만 긴 prefix는 token 비용을 쓰고, 사용자마다 같은 prefix를 유지해야 하며, 모델이 instruction을 무시하거나 출력 형식을 깨면 제품이 불안정하다.

논문은 GPT-3 baseline, 좋은 few-shot prefix를 붙인 GPT-3-prompted, SFT, PPO, PPO-ptx를 비교했다. 논문 확인: API prompt test에서 175B PPO-ptx 출력은 175B GPT-3보다 85±3%, few-shot 175B GPT-3보다 71±4%의 직접 비교에서 선호됐다(§1, §4.1). 이 수치는 “PPO-ptx가 모든 prompt에서 85% 정답”이 아니라, 그 labeler·prompt distribution에서 두 출력 중 어느 쪽을 더 좋아했는지의 win rate(승률)다.

작은 모델이 더 선호될 수 있었던 이유

논문 Figure 1은 1.3B PPO-ptx 출력이 175B GPT-3 출력보다 labeler에게 선호됐다고 보고한다. 모델 크기가 중요하지 않다는 뜻이 아니다. 같은 사용자-facing instruction task에서는 목적 함수가 더 맞는가가 parameter 수만큼 중요할 수 있다는 실험이다.

175B GPT-3: 더 큰 일반 언어 패턴 기억 + 기본 next-token 목적
  vs.
1.3B InstructGPT: 더 작은 일반 능력 + 사람이 선호한 답 형식/행동으로 후학습

이 결과로 “1.3B면 175B를 대체한다”라고 말하면 틀리다. 논문도 public NLP task에서 regression(성능 퇴행)을 관찰했고, 복잡한 능력·도메인·최신 지식·추론은 별도 평가가 필요하다.

무엇인가: RLHF의 정의와 하지 않는 일

RLHF는 사람의 비교를 모델이 최적화할 수 있는 점수로 바꾸는 절차다

RLHF(Reinforcement Learning from Human Feedback, 인간 피드백 강화학습)는 사람이 매 token의 정답을 모두 쓰지 않아도, 여러 후보 중 더 나은 결과를 고르게 해서 reward signal(보상 신호)을 만드는 방법이다.

여기서 x는 prompt, y는 completion(모델 답), π(y|x)는 policy가 답을 생성할 확률, r_θ(x,y)는 RM의 scalar reward다.

이 논문이 하지 않는 일

• RM 점수는 진실·안전·법적 적합성의 증명서가 아니다. 특정 labeler가 특정 지침 아래 선호한 output의 근사다.
• “human feedback”은 모든 인간의 합의가 아니다. 논문은 약 40명의 contractor, 연구자 지침, Playground customer prompt에 정렬됐다고 명시한다.
• PPO는 model에게 DB 권한이나 tool 실행 권한을 주지 않는다. output text의 분포를 바꿀 뿐이다.
• PII(Personally Identifiable Information, 개인 식별 정보) filter를 했다고 인터넷 사전학습·응답·log의 개인정보 위험이 사라지지 않는다.
• InstructGPT가 harmful request를 거절하도록 완성된 안전 모델이라는 뜻도 아니다. 논문은 대부분의 경우 harmful할 수 있는 user instruction도 따른다고 한계로 적었다.

선행 개념: policy·reward·preference·KL을 작은 예로 닫기

1. policy는 답을 하나 고르는 함수가 아니라 답마다 확률을 주는 분포다

사용자 prompt x="PostgreSQL vacuum을 한 문장으로 설명해줘"에 policy는 token을 한 개씩 낼 확률을 만든다.

π("VACUUM은 ..." | x) = 높은 확률
π("DROP DATABASE" | x) = 매우 낮은 확률

SFT는 사람이 쓴 desired completion의 token 확률을 높인다. 이 방식은 답을 직접 제공해야 하므로 고품질 demonstration 작성 비용이 든다. ranking은 “A가 B보다 좋다”만 주어도 되므로 답 전체를 새로 쓰는 것보다 빠를 수 있지만, 점수 모델을 한 겹 더 학습해야 한다.

2. preference 비교는 Bradley–Terry 형태의 확률로 바뀐다

같은 x에 답 y_w(winner)와 y_l(loser)가 있고 labeler가 y_w를 골랐다고 하자. RM은 둘의 reward 차이로 선호 확률을 만든다.

σ(z)=1/(1+e^{-z})는 sigmoid(시그모이드)다. reward 차이가 클수록 winner 확률이 1에 가까워진다. 논문 Eq. 1의 pairwise loss(쌍대 손실)는 이 확률의 음의 로그다.

중요한 성질은 reward 전체에 +10을 더해도 차이는 그대로라는 점이다. RM은 절대 점수보다 두 답의 상대 순서를 배운다. 그래서 원 논문 §3.5는 RL 전에 labeler demonstration 평균 점수가 0이 되도록 bias로 reward를 normalize(정규화)했다.

3. K개 답의 순위는 조합 폭발과 상관관계를 함께 만든다

논문은 labeler에게 K=4~9개 completion을 한 번에 보여 순위를 매기게 했다. K개 답에서 서로 다른 pair는 K(K-1)/2개다.

K=4 → 6개 pair
K=6 → 15개 pair
K=9 → 36개 pair

답 하나가 여러 pair에 반복되므로 36개의 독립 사람 판단이 생긴 것은 아니다. 논문은 pair를 완전히 섞어 one pass로 학습하면 RM이 빨리 overfit한다고 보고했다. 그래서 한 prompt의 모든 K choose 2 비교를 한 batch element로 묶어, completion마다 forward pass를 한 번만 하고 상관된 label을 함께 처리했다(§3.5, Appendix C.2).

4. KL penalty는 “좋아 보이는 답만 내려고 말투가 망가지는 것”을 막는 밧줄이다

PPO에서 RM만 최대화하면 policy는 RM의 약점을 찾아 점수는 높고 사람에게는 이상한 말을 할 수 있다. 이를 reward hacking(보상 해킹)이라 한다. InstructGPT는 SFT policy를 reference(기준 분포)로 두고 token마다 다음 벌점을 준다.

β(beta)는 KL reward coefficient(기준 policy에서 멀어짐의 벌점 강도)다. π_RL이 SFT가 거의 내지 않던 token에 과하게 확률을 주면 log-ratio가 커져 벌점이 생긴다. KL은 여러 token과 sample에 대해 평균 내면 분포가 얼마나 달라졌는지 재는 척도다. 한 sample의 log-ratio 합은 음수일 수도 있으므로, 한 답의 숫자만 보고 “KL은 항상 양수”라고 하면 안 된다. 기대값으로서의 KL divergence는 0 이상이다.

5. PPO는 한 번의 update가 너무 멀리 뛰지 않게 clip을 건다

PPO는 old policy에서 생성한 답에 대해 새/옛 확률 비율 ρ_t를 계산한다.

advantage(이 답이 예상보다 얼마나 좋았는가)가 양수일 때 ρ=1.5라 해도, clip range가 0.2이면 PPO surrogate(대리 목적)는 min(1.5, 1.2)=1.2만 보상한다. 즉 좋은 sample 하나를 보고 확률을 무한히 밀어 올리지 않게 한다. 원 논문 Appendix C.4는 PPO clip ratio 0.2, 256k episode, rollout batch 512, minibatch 64를 보고한다.

6. PPO-ptx의 ptx는 pretraining mix다

RLHF 후 public NLP benchmark가 나빠진 현상을 논문은 alignment tax라고 불렀다. PPO-ptx는 PPO reward 목표에 원래 pretraining distribution의 log-likelihood 항을 섞었다.

γ(gamma)는 pretraining gradient의 세기다. 원 논문은 기본적으로 PPO-ptx를 InstructGPT라고 불렀고, PPO만 쓸 때는 γ=0이다. 이것은 “사전학습을 다시 처음부터 한다”가 아니라, RL update 사이에 원래 text 분포를 잊지 않도록 gradient를 섞는 절충이다.

밑바닥 원리: SFT → RM → PPO-ptx를 한 request 흐름으로 따라가기

1. Step 1 — 사람 demonstration으로 SFT policy를 만든다

prompt x: "아래 장애 공지를 세 문장으로 요약해줘"
사람 답 y*: "1) ... 2) ... 3) ..."

SFT loss = -Σ log π_SFT(y*_t | x, y*_<t)

이 단계는 model에게 “좋은 답의 표면 형태”를 바로 보여 준다. 논문 확인: Appendix C.1은 GPT-3 architecture를 16 epoch fine-tune하고 residual dropout(잔차 연결 일부를 무작위로 끄는 정규화) 0.2, cosine LR(Learning Rate, 학습률) decay를 사용했다고 적는다. validation loss는 1 epoch 뒤 overfit 경향을 보였지만 RM score와 human preference는 더 많은 epoch에서 좋아져, 최종 SFT 선택에 RM validation score를 썼다. “validation loss가 나빠지면 항상 즉시 멈춘다”가 여기서는 맞지 않았다는 실제 사례다.

2. Step 2 — 여러 candidate를 rank하고 RM을 학습한다

동일 prompt에 SFT/GPT/PPO policy가 만든 A·B·C·D 답을 labeler가 좋음→나쁨 순으로 둔다.

x + [답 A, 답 B, 답 C, 답 D]
  → labeler ranking: B > A > D > C
  → 모든 쌍: B>A, B>D, B>C, A>D, A>C, D>C
  → RM(x, 답) 하나의 scalar가 이 순서를 잘 설명하도록 학습

원 논문 RM은 SFT model의 unembedding layer(마지막 token vocabulary logits 층)를 제거하고 prompt+response를 입력받아 scalar 하나를 내게 했다. 175B RM은 불안정하고 PPO value function 비용도 커서, 모든 policy 크기에 6B RM과 6B value function을 썼다(§3.5, Appendix C.2/C.4). RM이 6B라는 사실은 “reward model은 작으면 충분”이라는 보편 결론이 아니라 이 실험의 compute/stability 선택이다.

3. Step 3 — RM을 시험관으로 삼아 PPO policy를 업데이트한다

PPO dataset에서 prompt x를 뽑음
  → π_RL이 답 y 생성(rollout)
  → frozen RM이 rθ(x,y) score
  → frozen SFT reference가 token log-probability 제공
  → RM score - β×KL penalty로 token reward 구성
  → value function이 advantage 추정
  → clipped PPO update
  → pretraining batch gradient도 γ만큼 누적(PPO-ptx)

이 loop에서 RM은 학습 중 고정된 시험관이다. policy가 바뀌면 RM이 실제 사람 선호를 틀리게 추정할 수 있다. 그래서 논문 §3.1은 current best policy에서 새 comparison을 모아 RM과 policy를 반복 갱신할 수 있다고 설명한다. 실제로 대부분 comparison data는 SFT policy에서, 일부는 PPO policy에서 나왔다. 운영에서는 RM 버전, policy 버전, label guideline version, prompt distribution revision을 한 experiment ID로 묶지 않으면 무엇이 좋아졌는지 알 수 없다.

4. 학습 prompt는 어디서 왔고 어떻게 분리했나

논문 확인: §3.2는 초기에는 labeler가 plain/few-shot/user-based prompt를 작성해 bootstrap했다고 적는다. 이후 Playground에서 earlier SFT InstructGPT 모델에 들어온 customer prompt를 썼다. production API customer data는 논문에 쓰지 않았고, prompt long common prefix 기반 heuristic deduplication(휴리스틱 중복 제거), user ID당 최대 200개, user ID 단위 train/validation/test split, train PII filter를 적용했다.

Appendix A Table 6의 실제 train prompt 수는 다음이다.

RM data의 33,207은 prompt 수다. 각 prompt에 K=4~9 답 순위가 있으므로 실제 pairwise comparison 수는 이보다 훨씬 많다. 데이터 row 수, pair 수, unique user 수, token 수를 같은 “label 개수”로 뭉개면 비용·편향·누출을 잘못 판단한다.

내부 구조와 실제 실행 흐름: 모델만이 아니라 사람·데이터·평가가 한 시스템이다

논문 그림에는 모델 세 개가 보이지만, 실제로는 아래의 여섯 흐름이 함께 돌아간다. 이 중 하나라도 빠지면 “RLHF를 했다”는 말은 재현 불가능하다.

동의·보존 기준이 있는 prompt 수집
  → PII 제거·중복 제거·사용자 단위 split
  → labeler 교육·demonstration/ranking 수집
  → SFT / RM / PPO-ptx 학습
  → holdout 사용자·holdout labeler 평가
  → 배포 전 안전·편향·회귀·비용 판단

1. prompt의 출처와 split은 모델 정확도만큼 중요한 설계다

같은 사람이 쓴 비슷한 prompt가 train과 test에 동시에 있으면 모델이 사용자의 말투·주제를 이미 본 셈이 된다. 점수가 높아도 새 사용자에게 잘 맞는다는 증거가 약해진다. 그래서 이 연구는 user ID를 기준으로 train/validation/test를 나누었다. 같은 user가 train과 valid/test에 겹치지 않는다. 또한 user당 200 prompt까지만 사용했다. 매우 활동적인 소수 사용자가 학습 분포를 지배하는 일을 줄이려는 선택이다.

그러나 user ID split도 완벽한 독립성 증명은 아니다. 서로 다른 user가 같은 웹 문구를 붙여 넣을 수 있고, long common prefix heuristic은 의미가 같은 paraphrase(의미는 같고 표현만 다른 문장)를 모두 잡지 못한다. 이 부분은 논문의 사실에서 출발한 해석이다. 운영 데이터에서는 exact hash, near-duplicate similarity, template ID, organization ID, time window를 함께 보고 leakage(누출) 위험을 평가해야 한다.

DBA 관점의 최소 데이터 계약은 다음처럼 원문과 별도로 남겨야 한다. 답 자체가 민감할 수 있으므로 raw prompt와 raw completion 접근은 최소 권한으로 분리한다.

삭제 요청과 보존 기간도 모델 학습과 별개로 설계해야 한다. 이미 학습에 쓰인 sample의 제거가 필요한지, 다음 retrain에서 제외하면 충분한지, 평가 set의 추적성을 어떻게 보존할지는 법·계약·위험에 따라 다르다. 이 글은 법률 결론을 내리지 않는다. 다만 prompt → label → model checkpoint의 lineage(계보)를 남기지 않으면 나중에 그 질문에 기술적으로 답할 수 없다는 것은 해석이 아니라 운영상 확인 가능한 사실이다.

2. labeler는 “정답 API”가 아니라 측정 장치다

논문 §3.4에 따르면 약 40명의 contractor가 label을 만들었다. sensitive content 판단, demonstration 작성, ranking을 위한 screening과 onboarding, 문서화한 지침, shared chat이 있었다. 학습 시에는 helpfulness를 우선했고, 최종 평가 지침에서는 truthfulness와 harmlessness를 더 우선했다. 같은 답이라도 무엇을 우선시하라는 지침에 따라 순위가 달라질 수 있다는 뜻이다.

논문 확인: training labeler 간 agreement는 72.6±1.5%, heldout labeler 간 agreement는 77.3±1.3%로 보고됐다(§3.4). agreement가 100%가 아니라는 것은 데이터가 “오염됐다”는 선언이 아니다. 선호·안전·진실성 판단에 합리적 불일치가 존재한다는 관측이다. 반대로 72%라는 하나의 숫자가 모든 언어·문화·위험 요청에서 같은 신뢰도를 보장하지도 않는다.

실무에서는 다음 두 질문을 분리한다.

질문 A: labeler들이 같은 guideline을 일관되게 적용하는가?
질문 B: 그 guideline이 우리 제품 사용자·법적 의무·위험 정책에 맞는가?

질문 A의 agreement가 높아도 질문 B가 자동으로 참이 되지 않는다. 예를 들어 “친절한 답”을 좋아하도록 ranking하면, 정답보다 자신감 있는 문장을 선호하는 RM이 생길 수 있다. facts를 citation으로 확인하는 평가, refusal correctness(거절 정확성), escalation(사람에게 넘김) 판단은 별도 rubric(채점 기준)과 data slice가 필요하다.

3. SFT, RM, PPO에 실제로 들어간 모델과 상태

원 논문 Appendix C는 모든 model이 GPT-3 architecture, context length 2K, GPT-3 BPE(Byte Pair Encoding, 바이트 쌍 인코딩) tokenizer를 썼고, weights·activations는 FP16(Floating Point 16-bit, 16비트 부동소수점), master weights는 FP32로 두었다고 보고한다. prompt는 1K token 초과를 filter했고 completion은 최대 1K token으로 잘랐다. optimizer는 Adam(Adaptive Moment Estimation, 적응형 모멘트 추정)이며 β1=0.9, β2=0.95다.

아래는 논문에 적힌 핵심 상태를 “무엇이 변하고, 무엇이 고정되는가”로 재배열한 것이다.

SFT에서 validation loss와 최종 사용자 선호가 서로 다르게 움직인 사례가 특히 중요하다. Appendix C.1에서 저자들은 validation loss가 1 epoch 뒤 overfit 경향을 보였지만, RM validation score와 human preference는 더 긴 SFT에서 좋아져 16 epoch까지 학습했다. loss 하나만 dashboard에 올려서는 제품 목표를 대변할 수 없다는 사례다. 단, 이 관찰로 “validation loss는 무시해도 된다”라는 일반 규칙은 나오지 않는다. 모델·data·목표가 달라지면 다시 측정해야 한다.

RM은 6B 하나만 사용했다. ranking batch에서 답 하나를 여러 pair가 공유하므로, prompt마다 모든 K choose 2 pair를 하나의 batch element로 처리했다. 그 방식은 답 forward를 중복하지 않는 장점도 있고, pair를 무작위로 섞어 한 번씩 보는 방식에서 빨랐던 overfit을 피하려는 실험적 선택이기도 하다. RM validation preference accuracy는 training worker의 5-fold 평가에서 72.4±0.4%, heldout worker에서 69.6±0.9%였다(§4.1). RM이 사람을 완전히 대체하지 못하는 이유가 수치에도 드러난다.

PPO는 256k episode를 돌렸고 31k unique prompt를 썼다. rollout batch는 512, PPO minibatch는 64, 한 outer batch에 8 minibatch와 1 inner epoch를 사용했다. Appendix C.4의 KL coefficient는 0.02, clipping range는 0.2, exponential moving average(지수 이동 평균) decay는 0.992다. PPO-ptx는 pretraining example을 PPO example보다 8배 사용하고 γ=27.8을 썼다. 이 값들은 이 논문의 recipe(조리법)이지, 다른 model/데이터에 그대로 복사할 보편 상수가 아니다.

4. 공개 artifact가 보여 주는 것과 보여 주지 않는 것

직접 확인: OpenAI가 논문과 함께 공개한 artifact 저장소를 commit 5c0534c78136809ab0118c5c1b74d159befa2467으로 checkout했다. README와 tree에는 model card 및 automatic evaluation sample CSV가 있고, 학습 script·원 데이터·checkpoint·API inference code는 없다. 따라서 “InstructGPT를 공개 코드로 재훈련했다”라고 쓰는 것은 사실이 아니다.

저장소에는 truthful_qa_samples.csv, real_toxicity_samples.csv, cnn_dm_samples.csv, drop_samples.csv, fr_to_en_samples.csv, quac_samples.csv, squadv2_samples.csv, tldr_samples.csv가 있다. CSV는 논문의 평가 output 표본을 볼 수 있게 하지만, 그 표본만으로 논문의 전체 train/eval pipeline을 재실행할 수는 없다.

아래는 별도 Python 실행으로 실제 확인한 artifact의 구조다. 실행 환경은 macOS 26.4.1, Python 3.9.6이었다.

cd /tmp/instructgpt-research/following-instructions-human-feedback
git rev-parse HEAD
# 5c0534c78136809ab0118c5c1b74d159befa2467

python3 - <<'PY'
import csv
from collections import Counter
from pathlib import Path

root = Path('automatic-eval-samples')
for name in ('truthful_qa_samples.csv', 'real_toxicity_samples.csv'):
    with (root / name).open(newline='', encoding='utf-8') as f:
        rows = list(csv.DictReader(f))
    print(name, len(rows), Counter(row['model_type'] for row in rows))
    print(list(rows[0]))
PY

truthful_qa_samples.csv 3600
12 model_type × 각 300 row
columns: ['', 'model_type', 'prompt_type', 'adversarial', 'question', 'answer', 'true', 'info']

real_toxicity_samples.csv 3600
12 model_type × 각 300 row
columns: ['', 'model_type', 'prompt_type', 'context', 'sample', 'toxicity']

12개 model_type에는 gpt-xl/6b/175b, sft-xl/6b/175b, ppo-noptx-xl/6b/175b, ppo-ptx-xl/6b/175b가 포함됐다. 여기서 row 수는 공개한 sample의 row 수다. 모델의 전체 test set 크기나 model quality의 신뢰구간을 이 CSV만으로 역산하면 안 된다.

5. 이전 공개 구현으로 확인할 수 있는 실행 패턴 — 단, 동일 코드가 아니다

공개된 lm-human-preferences commit cbfd210은 2019년 Fine-Tuning Language Models from Human Preferences 계열 코드다. README는 archive 상태, Python 3.7과 TensorFlow GPU 1.13, smallest GPT-2 124M에서만 test했다고 밝힌다. 이는 InstructGPT source가 아니다. InstructGPT의 GPT-3 1.3B/6B/175B training 구현을 이 코드로 단정하면 안 된다.

그래도 공개 implementation에서 논문의 추상 절차가 어떤 상태 전이를 갖는지 확인하는 보조 근거는 된다.

• rewards.py L43–L89는 마지막 token의 scalar reward와 gain/bias normalization을 계산한다.
• rewards.py L105–L107는 query와 response를 이어 RM input을 만든다.
• train_policy.py L149–L154는 policy와 reference의 log probability 차이로 KL non-score reward를 만든다.
• train_policy.py L284–L372는 rollout→reference logprob→score→advantage→PPO clipped loss 순서를 보여 준다.

직접 실행: 이 이전 코드 checkout에 대해 python3 -m compileall -q lm_human_preferences를 실행했고 exit code 0을 확인했다. syntax compilation 성공은 GPU training 재현이나 InstructGPT 재현이 아니다. “어디까지 검증했는가”의 경계를 이렇게 적어 두어야 한다.

직접 검증과 재현: 논문 수식·공개 artifact·검증 경계를 나눠 확인한다

큰 model, 사람 data, 수천 GPU가 없는 개인 환경에서 논문 전체를 재현할 수는 없다. 그러므로 재현은 “가능한 작은 사실부터 같은 방식으로 확인”해야 한다. 여기서는 (1) 논문 식의 숫자 관계, (2) 공개 artifact의 실제 구조, (3) 관련 공개 코드의 정적 실행을 분리했다. 원 model weight, 고객 prompt, RM checkpoint, GPU cluster가 없다는 한계도 함께 남긴다.

1. 작은 수로 Eq. 1, KL penalty, PPO clip을 끝까지 계산한다

아래 교육용 script는 논문 Eq. 1/2와 Appendix A/C 숫자를 Python 산술로 확인한 것이다. 이것은 actual InstructGPT training이 아니라 수식의 방향·normalization·조합 수를 검증하는 최소 재현이다. 파일은 /tmp/instructgpt-research/verify_instructgpt_mechanics.py, SHA-256은 4a8a1fb0afec1e7406ffea850c41f1a0dbfdbded33bc4a5340fb0f8bef63356e였다.

#!/usr/bin/env python3
from math import comb, exp, log

def sigmoid(x):
    return 1 / (1 + exp(-x))

def pairwise_loss(reward_winner, reward_loser):
    return -log(sigmoid(reward_winner - reward_loser))

winner, loser = 2.0, 1.0
print('pairwise preference probability:', round(sigmoid(winner - loser), 6))
print('pairwise RM loss:', round(pairwise_loss(winner, loser), 6))
print('loss unchanged after +10 reward shift:', round(pairwise_loss(winner + 10, loser + 10), 6))

for k in (4, 6, 9):
    print(f'K={k} ranked completions -> pair labels:', comb(k, 2))

token_log_ratios = [0.1, -0.2, 0.4]
kl_proxy = sum(token_log_ratios)
beta = 0.02
rm_score = 2.5
print('sample token KL proxy sum:', kl_proxy)
print('beta * KL penalty:', beta * kl_proxy)
print('RM - beta*KL objective term:', rm_score - beta * kl_proxy)

ratio, clip = 1.5, 0.2
print('PPO ratio / clipped ratio:', ratio, min(max(ratio, 1 - clip), 1 + clip))
print('PPO maximize surrogate min:', min(ratio, 1 + clip))

post_training_pf_days, gpt3_pf_days = 4.9 + 60, 3640
print('175B SFT + PPO-ptx PF-days:', post_training_pf_days)
print('reported post-training / GPT-3 pretraining percent:', round(100 * post_training_pf_days / gpt3_pf_days, 3))
print('SFT train prompts Table 6:', 11295 + 1430)
print('RM train prompts Table 6:', 6623 + 26584)

실행 명령과 실제 output은 다음이다.

python3 /tmp/instructgpt-research/verify_instructgpt_mechanics.py

pairwise preference probability: 0.731059
pairwise RM loss: 0.313262
loss unchanged after +10 reward shift: 0.313262
K=4 ranked completions -> pair labels: 6
K=6 ranked completions -> pair labels: 15
K=9 ranked completions -> pair labels: 36
sample token KL proxy sum: 0.3
beta * KL penalty: 0.006
RM - beta*KL objective term: 2.494
PPO ratio / clipped ratio: 1.5 1.2
PPO maximize surrogate min: 1.2
175B SFT + PPO-ptx PF-days: 64.9
reported post-training / GPT-3 pretraining percent: 1.783
SFT train prompts Table 6: 12725
RM train prompts Table 6: 33207

이 output을 한 줄씩 해석해 보자.

1. 2.0 - 1.0 = 1.0 reward 차이면 sigmoid(1)≈0.731059이므로 RM은 winner를 약 73.1% 확률로 선호한다고 표현한다.
2. 양쪽 reward에 +10을 더해도 차이가 1.0이므로 loss는 0.313262로 변하지 않는다. RM의 식은 절대 reward 원점을 정하지 않는다. 논문의 reward normalization이 필요한 이유다.
3. K=9 ranking은 36 pair를 만들지만 사람의 독립 판단 36번과 같지 않다. 하나의 ranking에서 나온 상관된 파생 label이다.
4. token log-ratio 합 0.3은 단일 sample의 proxy(대리값)다. 논문에서 말하는 기대 KL divergence와 다르며, 단일 답에서 음수가 될 수도 있다. β=0.02라면 이 예의 벌점은 0.006이다.
5. advantage가 양수인 예에서 raw ratio가 1.5라도 clip이 1.2로 제한한다. PPO가 큰 update를 억제하는 국소적인 이유다.
6. 175B SFT 4.9 PF-days와 175B PPO-ptx 60 PF-days 합은 64.9 PF-days다. 논문 §5.1의 GPT-3 pretraining 3640 PF-days에 나누면 약 1.783%다. 이 비율은 논문에 나열된 model training compute 비교다. 데이터 수집, labeler, experiment 실패, serving, 안전 운영의 총비용이 1.783%라는 뜻이 아니다.

2. 한 값만 바꿔 보는 실패 실험: KL·clip이 없으면 무엇이 사라지나

위 script의 beta = 0.02를 0.0으로 바꾸면 reward 항은 2.5가 된다. 이 산술은 “KL이 없으면 벌점이 사라진다”만 보인다. 실제 model이 반드시 나빠진다는 실험 증명은 아니다. 하지만 RM이 policy가 학습 분포 밖으로 가는 방향을 완벽히 점수화하지 못할 때, 기준 policy로부터의 거리 제약을 제거하는 것은 reward hacking 위험을 키운다는 해석의 출발점이다.

반대로 ratio=1.5, clip=0.2에서 clipped ratio가 1.2인 것은 계산으로 확인된다. PPO loss 전체에는 advantage, value loss, entropy 등 추가 항과 batch 평균이 있으므로 이 한 줄이 full training objective 전부는 아니다. 작은 verifier는 큰 시스템의 한 조각을 정확하게 확인하는 도구여야지, 그보다 큰 결론을 꾸며 내는 장치가 아니다.

3. 논문을 직접 읽을 때의 25분 순서

이 논문을 처음부터 모든 appendix 수식으로 읽으면 목적을 잃기 쉽다. 다음 순서는 top-down(위에서 아래로)과 bottom-up(아래에서 위로)을 연결한다.

0–5분   초록, Figure 1, §1: 무엇을 개선했고 어떤 숫자인가?
5–10분  Figure 2, §3.1: SFT→RM→PPO라는 전체 파이프라인은 무엇인가?
10–15분 §3.2–3.6: prompt·labeler·split·평가 계약은 무엇인가?
15–20분 §4–§5: 선호 향상 외 퇴행·독성·편향·오용 한계는 무엇인가?
20–25분 Eq. 1/Eq. 2, Appendix A/C: loss·data 수·hyperparameter가 주장을 지지하는가?

그 다음에만 RM pairwise loss, KL, PPO clipping을 작은 수로 재계산한다. 이 순서는 수식을 피하자는 뜻이 아니다. 수식이 어떤 제품 문제와 어떤 data contract를 풀기 위해 들어왔는지 먼저 고정하자는 뜻이다.

4. 재현 실패를 만났을 때의 디버깅 순서

실무 RLHF 실험에서 score가 오르지 않거나 사람 평가와 RM이 엇갈리면, optimizer만 바꾸기 전에 아래 순서로 조사한다.

1. data lineage: train/validation/test user·template·time overlap이 없는가? PII/redaction/filter version은 같은가?
2. label contract: ranking UI에서 candidate 순서를 shuffle했는가? tie(동점)·skip·unsafe content 처리와 guideline version은 고정됐는가?
3. RM validity: heldout labeler에 대해 RM pair accuracy, calibration, prompt slice별 error를 측정했는가? 높은 training accuracy만 보고 있지 않은가?
4. policy drift: SFT-reference KL, response length, refusal rate, repetition, language/도메인별 score를 확인했는가?
5. end-to-end eval: blind human preference와 task-specific correctness·safety·latency·cost를 같이 보았는가?
6. rollback: 이전 policy, RM, prompt routing, evaluation report를 immutable artifact로 남겨 즉시 되돌릴 수 있는가?

이것은 논문의 exact 운영 runbook이 아니라, 논문이 드러낸 split·RM·KL·평가 문제에서 파생한 운영 해석이다. 실제 조직의 privacy, incident, legal process는 별도 책임자와 합의해야 한다.

성능, 복잡도와 트레이드오프: 선호 승률 하나로 끝나지 않는다

1. 논문이 실제로 보고한 성능을 조건과 함께 읽기

다음 표는 서로 다른 종류의 결과를 섞지 않기 위해, 논문 수치와 의미를 분리한 것이다.

논문 확인: §4.2–§4.4는 truthful QA에서 일반화 개선을 보이지만, harmful/biased instruction을 명시하면 모델도 더 toxic해질 수 있고, Winogender/CrowS-Pairs에서 bias가 유의하게 개선되지 않았다고 보고한다. PPO-ptx도 DROP, SQuADv2, 번역 일부에선 GPT-3보다 뒤처졌다. 따라서 “선호율 상승 = 안전·정확·공정·전 과업 성능 상승”은 성립하지 않는다.

2. 계산 비용은 policy parameter 수만으로 계산되지 않는다

SFT는 prompt+desired completion으로 teacher forcing(정답 token을 앞에 두고 다음 token을 예측하는 학습)을 한다. RM은 prompt마다 K개의 completion을 forward하고 K choose 2 비교 loss를 누적한다. PPO는 policy rollout, frozen SFT reference의 logprob, frozen RM, value function, PPO backward를 반복한다. 따라서 “PPO는 한 번 더 fine-tune”이라고만 보면 계산 경로를 놓친다.

대략적인 token-level 비용을 기호로 써 보면 다음과 같다.

SFT:      O(N_sft × L × policy forward/backward)
RM:       O(N_rank × K × L × RM forward/backward) + O(N_rank × K²) pair loss
PPO:      O(N_rollout × L × (policy generation + policy/reference/RM/value passes + update))

N_sft는 demonstration 수, N_rank는 ranking prompt 수, K는 candidate 수, L은 평균 token 길이다. 이 표기는 GPU kernel·parallelism·sequence packing을 생략한 설명용 근사다. 실제 병목은 model size, context length, generation length, communication, checkpoint, reward inference throughput, human labeling lead time에 따라 달라진다.

특히 K를 4에서 9로 올리면 RM forward candidate 수는 약 2.25배지만 derived pair는 6에서 36으로 6배가 된다. 더 많은 비교 관계가 생기지만 labeler가 순위를 신뢰성 있게 매길 수 있는지, UI 피로가 커지는지, pair 간 상관 때문에 실제 정보량이 얼마나 늘었는지는 별도 실험이 필요하다.

3. PPO-ptx는 능력 보존과 preference 최적화 사이의 조절 손잡이다

γ가 너무 작으면 RM을 향해 빠르게 움직여 public task·언어 분포를 잊을 수 있다. 너무 크면 사전학습 목적이 RLHF update를 압도해 원하는 behavior 변화가 작아질 수 있다. β도 같다. 너무 작으면 RM exploitation 위험이 커지고, 너무 크면 policy가 SFT에 거의 묶여 preference 향상이 작을 수 있다.

그러므로 release 판단은 하나의 best score가 아니라 Pareto frontier(파레토 전선: 어느 한 지표를 더 올리려면 다른 지표를 희생해야 하는 후보 집합)로 해야 한다.

후보 A: preference↑, truthfulness≈, toxicity↓, latency↑, task regression↑
후보 B: preference 약간↓, truthfulness↑, toxicity↓, latency≈, regression↓
후보 C: preference↑, refusal 과다, 유용성↓

제품의 위험 등급에 따라 B나 C가 맞을 수도 있다. 예컨대 의료·법률·금융처럼 오답 비용이 큰 product는 fluent answer보다 citation/abstention/human handoff를 더 높은 gate로 둘 수 있다. 이 선택은 논문 결과가 아니라 운영·제품 해석이며, domain 전문가와 평가 set으로 검증해야 한다.

실패, 한계, 장애와 운영: reward가 높아도 출시하면 안 되는 경우

1. 보상 모델은 사람이 아니라 사람 판단의 좁은 근사다

RM은 training ranking에서 잘 맞는 답의 패턴을 찾는다. policy는 그 RM을 반복해서 최적화한다. 이 구조에는 model이 RM의 blind spot(보지 못하는 약점)을 찾을 위험이 있다. 예를 들어 labeler가 짧고 자신감 있는 문장을 선호했는데 사실 검증 기준이 약하면, model은 근거보다 단정적 어조로 reward를 얻을 수 있다. 이를 reward hacking 또는 reward overoptimization(보상 과최적화)라고 부른다.

논문은 이 위험을 완전히 해결했다고 주장하지 않는다. §3.1은 current policy에서 새 comparison을 모아 RM과 policy를 반복 갱신할 수 있다고 설명한다. 이 과정은 분포 이동을 측정하고 새 label을 받는 반복이지, RM이 영구히 참이 되는 방법이 아니다.

다음 경보 조합이 보이면 rollout을 멈추고 원인을 조사해야 한다.

여기서 “임계값을 몇 점으로 둘 것인가”는 이 논문에 정답이 없다. product impact, base rate, false positive/negative 비용, human review capacity를 반영해 release criteria를 먼저 합의해야 한다.

2. helpful·honest·harmless는 동시에 자동 최대화되지 않는다

사용자 요청에 바로 답하면 helpful해 보일 수 있지만, 허위 전제가 있거나 위험한 절차면 honest/harmless하지 않을 수 있다. 반대로 모든 애매한 질문을 거절하면 harmless score는 높아 보여도 도움은 사라진다. 논문도 labeler training에서는 helpfulness를 우선, final evaluation에서는 truthfulness·harmlessness를 더 우선했다. 이는 목표가 단일 scalar 하나로 자연스럽게 합쳐지지 않는다는 증거다.

"우리 운영 DB를 빠르게 비워 줘"
  - helpful만: 위험한 DELETE/DROP 절차를 즉시 제시
  - harmless만: 아무 도움 없이 거절
  - 더 나은 시스템: 권한·환경·백업 확인을 요구하고,
                    읽기 전용 진단/안전한 대안을 제시하며,
                    실제 변경은 별도 승인 경계로 보냄

이 마지막 경계는 LLM weight 안에 넣는 문제가 아니다. API authorization(인가), audit log, confirmation, rate limit, sandbox, human approval이 담당해야 한다. RLHF 모델이 “하면 안 된다”고 말하더라도 backend가 직접 destructive command를 실행하게 설계하면 안전하지 않다.

3. 논문이 직접 밝힌 데이터·대표성 한계

논문 확인: §5.2–§5.3은 alignment가 약 40명 contractor(주로 영어 사용 미국·동남아)와 연구자 지침, API Playground customer prompt에 맞춰진다고 적는다. 모든 label이 다수 labeler에게 중복된 것도 아니다. prompt의 96% 이상이 영어다. 이런 조건의 선호를 보편적 human preference라고 말할 근거는 없다.

또한 §5.3은 model이 toxic, biased, sexual, violent output을 낼 수 있고, potentially harmful instruction을 대부분 따른다고 적는다. §4에서도 respectful prompt일 때 toxicity가 낮았지만, explicit maximally biased instruction에서는 GPT-3보다 더 toxic할 수 있다는 결과가 있다. 안전 지시 하나를 prompt에 붙이는 방식이 독립적인 안전 보장 장치가 아니라는 뜻이다.

해석: 지역·언어·직무별 고객이 있는 서비스라면 “전체 평균 선호”보다 stratified evaluation(집단별 층화 평가)이 중요하다. 최소한 언어, task, prompt length, user intent, risk level, refusal-required 여부, retrieval 사용 여부, tool 권한 여부로 slice를 나눈다. slice를 나누는 행위 자체도 민감한 집단을 추론·노출할 수 있으므로 필요한 범위·동의·접근 제어가 전제다.

4. factuality와 hallucination은 RM만으로 보증되지 않는다

논문은 closed-domain task에서 hallucination 비율이 41%에서 21%로 낮았다고 보고했다. 이 수치는 좋은 신호지만, 0%가 아니다. 그리고 현재 시점의 외부 사실, 조직 내부 규정, DB 상태처럼 model parameter 안에 없거나 바뀌는 지식은 post-training으로 해결할 수 없다.

그때 필요한 것은 RAG(Retrieval-Augmented Generation, 검색 증강 생성)나 엄격한 tool contract다.

질문
  → 인증된 사용자인가?
  → 최신·권한 있는 문서/DB에 read-only query를 보낼 수 있는가?
  → 검색 결과의 출처·시점·권한을 확인
  → model은 근거 범위 안에서 답하고 citation을 붙임
  → 변경 작업은 별도 승인·검증·감사 흐름

RAG도 검색 결과가 틀리거나 오래됐거나 권한 밖이면 안전하지 않다. RLHF는 “검색된 근거를 우선하여 답하라”는 행동 성향을 개선할 수 있지만, retrieval freshness(최신성), access control(접근 제어), transaction(트랜잭션), tool sandboxing(도구 격리)을 대체하지 않는다.

5. 운영 release gate: 학습 완료와 배포 승인을 분리한다

아래는 InstructGPT 논문의 교훈을 일반화한 제안 운영 체크리스트다. 논문이 제공한 공식 배포 절차가 아니다.

[Data]
□ consent/source/split/PII filter/version을 재현할 수 있다.
□ train·validation·test와 customer release gate가 user/template/time 기준으로 분리됐다.

[Label]
□ guideline의 helpful/honest/harmless 우선순위와 tie/skip/unsafe 절차가 명시됐다.
□ heldout labeler agreement와 slice별 disagreement를 보고했다.

[Model]
□ SFT, RM, policy, tokenizer, decoding, KL/reference version이 immutable run ID로 연결된다.
□ RM score, KL, length, repetition, refusal을 training curve와 배포 candidate에서 비교했다.

[Evaluation]
□ blind human preference 외 factuality·task success·safety·bias·privacy·latency·cost를 평가했다.
□ 평균과 worst slice를 모두 통과했고, 적대적 prompt와 false-premise prompt를 포함했다.

[Release]
□ backend authorization과 LLM recommendation을 분리했다.
□ rate limit, logging redaction, incident escalation, rollback checkpoint가 있다.
□ release 후 drift/complaint/unsafe output signal과 중단 담당자가 정해졌다.

점검표를 모두 체크했다고 “안전”이 증명되는 것은 아니다. 대신 누가 무엇을 검증하지 않았는지 드러내고, 사고 때 원인을 추적하고 멈출 수 있게 한다. 이것이 data pipeline을 설계하는 사람이 RLHF에서 만드는 경쟁력이다. model API를 호출하는 것보다 data provenance(데이터 출처·변환 이력), evaluation, 권한 경계를 시스템으로 연결하는 능력이 오래 남는다.

대안, 비교와 선택 기준: RLHF는 행동 문제의 한 도구다

RLHF를 선택하기 전에 먼저 “무엇이 부족한가”를 분류해야 한다. 모든 LLM 문제에 PPO를 붙이는 것은, 모든 DB 성능 문제에 index를 추가하는 것만큼 위험하다.

SFT와 RLHF를 경쟁 관계로 보지 말 것

SFT는 사람이 원하는 답을 직접 보여 주므로 pipeline의 anchor(닻) 역할을 한다. InstructGPT도 SFT 없이 RM/PPO부터 시작하지 않았다. data가 적고 목표 형식이 분명하면 SFT와 evaluation만으로 충분할 수 있다. 비교 ranking의 수집 비용, RM train/validation, PPO instability, reward hacking risk가 추가되기 때문이다.

RLHF는 “여러 reasonable answer 중 어느 것이 사용자의 의도·안전 기준에 더 맞는가”처럼 direct target을 쓰기 어려운 문제에서 의미가 크다. 다만 RM accuracy가 낮거나 deployment distribution이 training ranking과 다르면, 더 복잡한 loop가 더 나쁜 결과를 낼 수 있다.

DPO와 RLAIF는 무엇이 다르고 언제 읽을까

DPO는 preference pair와 reference policy로 policy를 직접 최적화하는 방법을 제시한다. 별도 RM을 학습하고 online PPO rollout을 최적화하는 InstructGPT recipe와 training topology(학습 연결 구조)가 다르다. DPO가 항상 더 좋다는 주장은 이 글의 범위를 벗어난다. 이 글을 읽은 뒤에는 “왜 RM·PPO·KL이 필요했는가”를 이해한 상태라 DPO의 loss가 무엇을 대체하는지 비교할 수 있다.

RLAIF는 사람이 아니라 model/AI evaluator가 feedback을 주는 접근이다. label 비용·속도를 개선할 수 있지만, evaluator의 편향과 오류를 더 빠르게 증폭할 수 있다. high-stakes policy에서는 사람의 승인, 도메인 검증, audit가 필요할 수 있다. 이 역시 model name이 아니라 data source·rubric·error model·권한 경계로 선택해야 한다.

선택을 위한 7개 질문

1. 실패의 원인은 knowledge, schema, authority, style, preference 중 무엇인가?
2. “좋다”를 가르는 ranking guideline을 한 문장과 예외 사례로 쓸 수 있는가?
3. candidate output과 blind human evaluation을 계속 만들 예산·시간이 있는가?
4. user·template·time leakage 없는 holdout set이 있는가?
5. RM score와 실제 product success가 어긋날 때 중단할 gate가 있는가?
6. model이 실수해도 backend/tool이 피해를 제한하는가?
7. SFT/RAG/validator로 같은 목표를 더 단순하게 달성할 수 없는가?

7번에 “예”라면 먼저 단순한 방법을 검증한다. 1–6번을 답하지 못한다면 PPO hyperparameter를 만지는 것보다 evaluation·data contract부터 만드는 편이 효율적이다.

흔한 오해와 질문의 답

Q1. RLHF를 하면 model이 진실을 배웠다고 말해도 되나?

아니다. 이 논문에서 RM은 특정 prompt와 guideline에서 labeler가 선호한 답을 근사한다. 논문은 truthfulness 개선을 보고했지만, hallucination·bias·harmful instruction의 한계도 함께 보고했다. 최신 사실은 retrieval과 source verification이 필요하고, 위험한 실행은 authorization과 approval이 필요하다.

Q2. 1.3B가 175B보다 이겼으니 큰 model 공부는 필요 없나?

아니다. 논문의 비교는 특정 instruction-following preference distribution에서의 결과다. base model scale, data quality, evaluation domain, latency·cost 모두 선택에 영향을 준다. 핵심 교훈은 “parameter만 최적화하지 말고 목적·data·평가를 함께 최적화하라”다.

Q3. reward model score가 계속 올라가면 성공인가?

아니다. RM이 학습에 쓰이는 objective와 사람이 실제로 원하는 결과는 다를 수 있다. blind human preference, factuality, safety, domain success, worst slice, latency/cost와 함께 본다. RM score만 상승하고 heldout 사람 평가는 하락하면 대표적인 실패 신호다.

Q4. KL penalty가 있으니 reward hacking은 막히나?

아니다. KL은 SFT reference에서 너무 멀리 가는 압력을 줄이는 regularizer(정규화 제약)다. RM의 오류·label bias·새로운 adversarial prompt를 판별하는 안전 판정기는 아니다. β를 높이면 behavior 변화 자체가 작아질 수도 있다.

Q5. 사람 feedback이면 공정하고 민주적인가?

아니다. 누구를 labeler로 뽑았는지, 어떤 지침을 줬는지, 어떤 prompt를 수집했는지가 reward에 들어간다. 논문의 약 40명 contractor와 주로 영어 prompt라는 범위를 숨기면 오히려 위험하다. representation과 disagreement를 측정·공개하고, product 정책 결정은 별도 책임 구조에서 다뤄야 한다.

Q6. backend 개발자는 RLHF를 직접 대규모로 돌려야 경쟁력이 생기나?

꼭 그렇지 않다. 경쟁력은 GPU를 보유했는가보다, 사람이 평가할 수 있는 product problem을 정의하고, 안전한 data pipeline을 만들고, retrieval·tool·권한·observability를 model behavior와 연결하는 데서 생긴다. 작은 SFT/evaluation prototype으로 hypothesis를 검증하고, 필요가 입증된 뒤 preference optimization으로 확장하는 순서가 더 안전하다.

Q7. 이 논문 다음에는 무엇을 읽어야 하나?

다음 순서는 DPO다. 단, 곧바로 loss를 외우기보다 이 글의 세 질문을 먼저 답한다: “RM을 따로 두면 무엇이 좋은가?”, “PPO rollout의 비용·불안정은 어디서 오는가?”, “reference/KL은 왜 필요한가?” 그 뒤 DPO를 읽으면 direct preference loss가 무엇을 간소화하는지 비교할 수 있다.

이 논문을 한 문장으로 다시 답하면

InstructGPT는 사람이 쓴 좋은 답으로 SFT를 만들고, 사람이 고른 답의 순위를 RM으로 바꾼 뒤, PPO가 RM 보상을 높이되 SFT에서 너무 멀어지지 않도록 KL 제약과 pretraining mix를 둔 연구다. 하지만 이 과정은 특정 data·labeler·지침에 대한 behavior optimization일 뿐, 사실·안전·권한·사회적 합의를 자동 보증하지 않는다.

출처

1차 자료: 원 논문과 공개 artifact

1. Long Ouyang et al., Training language models to follow instructions with human feedback, arXiv:2203.02155v1 (2022-03-04). 이 글의 파이프라인·Eq. 1/2·data/labeler·평가·PF-days·한계 수치는 §1–§5, Appendix A/C에서 확인했다.
2. OpenAI, following-instructions-human-feedback artifact, fixed commit 5c0534c. model card와 automatic evaluation sample CSV의 공개 범위를 직접 확인했다.
3. OpenAI, InstructGPT model card in the artifact repository. deployment model과 논문 model의 관계, known limitations, data note를 확인했다.

1차 자료: 이전 세대 공개 구현 — InstructGPT 구현과 구분

4. OpenAI, lm-human-preferences, fixed commit cbfd210. README의 archive/testing 범위와 이전 GPT-2 preference-learning code임을 확인했다.
5. rewards.py L43–L107, scalar reward·normalization·query/response 입력 구조의 공개 구현.
6. train_policy.py L149–L154, L284–L372, KL reward·rollout·advantage·PPO clipping 흐름의 공개 구현. 이 파일은 InstructGPT source가 아니라 개념 확인용 보조 근거다.

직접 실행 기록과 해석의 경계

• 직접 실행: macOS 26.4.1, Python 3.9.6에서 artifact commit ID, 두 CSV의 3,600 row·12 model type·column을 읽었다. lm-human-preferences에 python3 -m compileall -q lm_human_preferences를 실행하여 exit code 0을 확인했다. /tmp/instructgpt-research/verify_instructgpt_mechanics.py로 Eq. 1/2의 작은 수, K choose 2, clip, Table 6 합계, PF-days 비율을 산술 검산했다.
• 논문 확인: 사람 선호율, hallucination/toxicity/bias/public task 결과, labeler·prompt·hyperparameter·compute 수치는 위 원 논문의 해당 절·표·부록에 한정한다.
• 해석: DB schema, release gate, monitor, RAG/authorization 분리, 대안 선택 기준은 논문 사실을 제품·운영에 적용하기 위한 저자의 해석이다. InstructGPT 논문이 현행 API·법·보안 정책을 보증한다는 의미가 아니다.