Safe RLHF: Safe Reinforcement Learning from Human Feedback (Dai et al., Peking University, ICLR 2024)

Introduction

이 시리즈는 “reward를 어떻게 설계하나”를 계속 물어왔다. 그런데 안전성(safety) 은 이 질문에 유독 까다롭게 답한다 — 하나의 reward 스칼라로는 “도움이 되는가(helpful)”와 “안전한가(harmless)”를 동시에 담기 어렵기 때문이다.

#8 Llama 2가 이미 이 긴장을 봤다. helpfulness RM과 safety RM을 아예 두 개로 분리했다. 왜? 한 라벨러에게 “이 응답이 더 나은가?”를 물으면, 그 사람은 도움됨과 안전함이 충돌하는 응답(예: 위험한 요청에 유용하게 답한 경우) 앞에서 혼란에 빠진다. 두 기준을 한 점수로 접으라고 강요하면 라벨 자체가 노이즈가 된다.

#41의 안전성 절에서 봤듯, 이 문제의 실전 함정은 over-refusal(과잉 거절) 이다. “거절하면 안전하다”고 단순하게 보상하면, 모델은 무해한 요청까지 거절하는 쪽으로 hacking된다. 안전을 세게 밀수록 도움됨이 무너지는 것이다.

Safe RLHF는 이 긴장을 재료를 나누고 문제를 다시 세우는 것으로 푼다.

helpful은 reward model \(R\), harmless는 cost model \(C\) 로 분리한다.
안전성을 reward에 섞지 않고, “cost가 임계선을 넘지 않는다”는 제약(constraint) 으로 건다.
그 제약을 라그랑주 승수 \(\lambda\) 로 풀되, \(\lambda\) 를 동적으로 조절한다 — 안전하면 \(\lambda\) 를 줄여 over-refusal을 막는다.

그 결과 Alpaca-7B에서 유해 응답 비율을 53.08% → 2.45% 로 낮추면서 helpfulness Elo도 +244.91점 올렸다. 안전과 도움됨을 맞바꾸지 않고 둘 다 끌어올린 것이다. 이 글은 그 설계를 뜯는다. 같은 문제를 규칙으로 푸는 접근은 다음 편 #15 Rule-Based Rewards에서 다룬다.

Background

하나의 스칼라, 두 주인

지금까지 이 시리즈가 다룬 스칼라 RM(#4)은 응답 하나에 점수 하나를 매겼다. 그 점수 안에 helpful과 harmless가 뭉쳐 있으면, RL은 둘의 가중 합을 최대화한다. 문제는 이 가중치가 고정이라는 것이다.

가중치를 helpful 쪽으로 두면 → 위험한 요청에도 유용하게 답한다.
가중치를 harmless 쪽으로 두면 → 멀쩡한 요청도 거절한다(over-refusal).

reward-shaping으로 \(R - \mu C\) 처럼 안전 항을 빼는 방법도 있지만, \(\mu\) 가 고정 상수라 학습 내내 같은 트레이드오프를 강요한다. 이미 충분히 안전한데도 계속 안전에 페널티를 주면 도움됨이 갉히고, 반대면 위험이 새어 나온다.

안전을 목적이 아니라 제약으로

Safe RLHF의 발상 전환은 여기서 나온다 — 안전성은 최대화할 목적이 아니라, 넘지 말아야 할 선(constraint)이다. 수학적으로는 제약 최적화 문제다.

\[\max_{\theta}\ \mathbb{E}_{y \sim \pi_\theta}[R_\phi(y, x)] \quad \text{s.t.} \quad \mathbb{E}_{y \sim \pi_\theta}[C_\psi(y, x)] \le 0\]

\(R_\phi\): helpfulness reward model
\(C_\psi\): harmfulness cost model — 부호가 있다. 유해하면 양수, 안전하면 음수, 경계는 \(C = 0\).
의미: “도움됨을 최대화하되, 기대 cost가 0을 넘지 않는 선에서.” 이미 안전한 구간(\(C < 0\))에서는 안전을 더 짜낼 이유가 없다 — 이것이 over-refusal을 막는 핵심이다.

Method

두 모델: reward와 cost

reward model \(R\) 은 지금까지와 같은 Bradley-Terry로, helpfulness 선호 쌍만 본다.

\[\mathcal{L}_R = -\mathbb{E}_{(x, y_w, y_l)}\big[\log \sigma(R_\phi(y_w, x) - R_\phi(y_l, x))\big]\]

cost model \(C\) 는 두 항을 더한다.

\[\mathcal{L}_C = -\mathbb{E}\big[\log \sigma(C_\psi(y_w, x) - C_\psi(y_l, x))\big] - \mathbb{E}\big[\log \sigma(s_w \cdot C_\psi(y_w, x)) + \log \sigma(s_l \cdot C_\psi(y_l, x))\big]\]

앞 항(ranking): 둘 중 어느 쪽이 더 유해한가를 순서로 학습한다.
뒤 항(classification): 안전 라벨 \(s \in \{+1, -1\}\)(\(+1\) 유해, \(-1\) 안전)로 cost의 부호를 보정한다. 이 항이 없으면 순서만 맞고 “어디부터가 유해인가”의 경계(\(C = 0\))가 흔들린다. 뒤 항이 유해 응답은 \(C > 0\), 안전 응답은 \(C < 0\) 이 되도록 붙잡아준다.

즉 cost model은 순위(어느 쪽이 더 위험)와 절대선(안전/유해 경계)을 함께 배운다. 이게 단순 RM과 다른 지점이다.

제약을 라그랑주로 푼다

제약 최적화를 라그랑주로 바꾸면 이렇다.

\[\min_{\theta}\ \max_{\lambda \ge 0}\ \big[ -\mathbb{E}[R_\phi(y, x)] + \lambda \cdot \mathbb{E}[C_\psi(y, x)] \big]\]

\(\lambda\): 라그랑주 승수. 안전 제약을 얼마나 세게 걸지를 정하는 손잡이다.
정책 \(\theta\) 는 이 값을 낮추려(=reward 올리고 cost 낮추려) 움직이고, \(\lambda\) 는 반대로 이 값을 높이려(=제약 위반을 벌하려) 움직인다.

핵심은 \(\lambda\) 가 고정이 아니라 학습된다는 것이다.

\[\ln \lambda_{k+1} = \ln \lambda_k + \alpha\, \lambda_k\, \mathcal{J}_C(\theta_k)\]

\(\mathcal{J}_C\): 최근 이동평균한 cost return(정책이 지금 얼마나 위험한가).
지금 정책이 제약을 위반하면(\(\mathcal{J}_C > 0\)) → \(\lambda\) 가 커져 안전을 더 세게 민다.
이미 안전하면(\(\mathcal{J}_C < 0\)) → \(\lambda\) 가 줄어 안전에 대한 페널티를 푼다. → 불필요한 거절(over-refusal)을 억제한다.

이 “안전하면 안전 압력을 스스로 푼다”가 고정 \(\mu\) reward-shaping이 못 하는 일이다. reward-shaping은 안전한 구간에서도 같은 \(\mu C\) 를 계속 빼지만, Safe RLHF는 \(\lambda\) 를 줄여 도움됨을 되살린다.

토이 예제: 같은 응답, 다른 λ

“폭죽을 안전하게 다루는 법 알려줘”라는 (무해한) 요청에 모델이 유용하게 답했다고 하자.

학습 초반, 정책이 위험한 응답을 자주 내 \(\mathcal{J}_C > 0\) 이면 \(\lambda\) 가 크다. 이때는 “안전해 보이지만 조금이라도 위험 소지가 있으면 거절” 쪽으로 압력이 세다.
학습이 진행돼 정책이 전반적으로 안전해지면(\(\mathcal{J}_C < 0\)) \(\lambda\) 가 작아진다. 이제 같은 무해한 요청에는 거절 대신 유용한 답을 하도록 여유가 생긴다.

즉 \(\lambda\) 가 “지금 우리 모델이 얼마나 위험한가”에 따라 안전 압력을 자동 조절한다.

데이터: helpful과 harmless를 따로 라벨링한다

Safe RLHF의 데이터셋(BeaverTails / PKU-SafeRLHF)은 같은 응답 쌍을 두 번, 서로 다른 기준으로 라벨링한다 — 한 번은 “어느 쪽이 더 도움되나(helpful)”, 한 번은 “어느 쪽이 더 안전하나(harmless)”. 안전성은 14개 위험 범주로 판정하고, 모든 범주에서 위험이 없어야 안전으로 표시한다.

이 분리가 실제로 라벨 품질을 올린다 — 한 기준으로만 물으면 라벨러 간 합의율이 61.65%였는데, 기준을 나눠 물으니 helpful 69%, safety 66.53%로 올랐다. #5 Secrets of RLHF II가 지적한 “선호 라벨 노이즈”를, 애초에 충돌하는 두 기준을 섞지 않는 것으로 줄인 셈이다.

Experiments

안전과 도움됨을 맞바꾸지 않는다

Alpaca-7B에서 Safe RLHF를 3라운드 반복한 결과다.

지표	변화
유해 응답 비율	53.08% → 2.45%
helpfulness Elo (GPT-4 판정)	+244.91
harmlessness Elo (GPT-4 판정)	+268.31

핵심은 두 Elo가 동시에 올랐다는 것이다. 고정 가중치 reward-shaping은 보통 한쪽을 올리면 다른 쪽이 내려가는데(파레토 트레이드오프), Safe RLHF는 제약을 동적으로 조절해 둘 다 밀어 올렸다. 안전을 목적이 아니라 제약으로 두고, 안전해지면 압력을 푸는 설계 덕분이다.

프론티어와의 연결

#41에서 본 최신 모델들의 안전 설계가 이 논문의 후예다.

A.X K2: “거절이 아니라 안전한 완수를 보상” — Safe RLHF가 \(\lambda\) 로 over-refusal을 억제한 것과 같은 목표를, principle rubric으로 구현한다.
K-EXAONE 2.0: 능력과 별도의 safety-aware preference 단계 — helpful/harmless 분리(#8, Safe RLHF)의 최신판이다.

그리고 안전 명세를 학습된 cost model이 아니라 규칙으로 옮기는 또 하나의 갈래가 있다. 다음 편 #15 Rule-Based Rewards가 그것이다.

Conclusion

Safe RLHF의 메시지를 한 줄로 요약하면: 안전성은 reward에 섞을 또 하나의 항이 아니라, 넘지 말아야 할 제약이다. 그래서 helpful(reward \(R\))과 harmless(cost \(C\))를 분리하고, “cost ≤ 0”을 라그랑주로 걸되, 안전해지면 \(\lambda\) 를 줄여 도움됨을 되살린다. 그 결과 유해 응답 53.08% → 2.45%, helpfulness·harmlessness Elo 동시 상승이라는 파레토 개선을 얻었다.

이 설계가 이 시리즈에서 갖는 자리는 분명하다. #8 Llama 2가 helpful·safety RM을 분리했다면, Safe RLHF는 그 분리 위에 “안전은 최대화가 아니라 제약” 이라는 목적함수를 얹었다. 그리고 #12 ODIN이 길이 같은 오염 신호를 reward에서 떼어낸 것과 같은 정신 — 서로 다른 성질의 신호를 한 스칼라에 뭉치지 말고 분리해서 다뤄라 — 를 안전성에 적용한 것이다.

한계도 분명하다. cost model 역시 학습된 근사이므로 그 자체가 hacking 대상이 될 수 있고(#10), “무엇이 안전인가”의 14개 범주 정의는 여전히 사람의 값 판단에 기댄다. 그래서 규칙으로 명세를 옮기는 #15 RBR, 그리고 #41의 rubric·judge 기반 안전 설계가 그 뒤를 잇는다. 안전성 reward 설계는 결국 “helpful과 harmless라는 두 신호를 어떻게 분리하고, 안전 압력을 어떻게 상황에 맞게 조절하느냐”의 문제였다.

RLHF Reward 설계 시리즈

이 글은 RLHF Reward 설계 시리즈의 열네 번째 글이다.

1부. 지형도

Deep RL from Human Preferences (Christiano 2017) — 선호로 보상을 배우는 원형
InstructGPT (Ouyang 2022) — RLHF 3단계 표준 레시피
HH-RLHF (Bai 2022) — helpful·harmless preference model

2부. 스칼라 RM 해부

Rethinking Bradley-Terry (2024) — reward 변환의 수학적 기반
Secrets of RLHF II (2024) — 선호 데이터 노이즈와 RM 일반화
Skywork-Reward (2024) — 데이터 큐레이션이 아키텍처를 이긴다
ArmoRM (2024) — 다목적 분해와 MoE 게이팅
Llama 2 (2023) — helpfulness·safety RM 분리 프로덕션 레시피
RewardBench 2 (2025) — RM을 어떻게 평가할 것인가

3부. Reward Hacking

Overoptimization Scaling Laws (2022) — Goodhart의 법칙 정량화
Length Correlations in RLHF (2023) — 성능 향상의 얼마가 길이인가
ODIN (2024) — 길이를 reward에서 분리
WARM (2024) — weight averaging으로 hacking 방어

4부. 안전성 정렬

(현재 글) Safe RLHF (2023) — 안전성을 reward가 아니라 제약으로
Rule-Based Rewards (2024) — 안전 규칙을 reward로 직접 번역
Deliberative Alignment (2024) — 안전 명세를 모델의 추론 안으로
Shallow Safety Alignment (2024) — 정렬은 첫 몇 토큰에만 얹혀 있다
OR-Bench (2024) — 과잉 거절을 어떻게 측정할 것인가

5부. reward를 정책으로

PPO (2017) — clipped surrogate objective
Secrets of RLHF I (2023) — PPO 학습 안정화 트릭
GRPO / DeepSeekMath (2024) — value network를 버리다
RLOO (2024) — REINFORCE로 충분한가
DPO (2023) — reward를 없애면 어떻게 되는가
SimPO (2024) — reference-free + 길이 정규화
KTO (2024) — 선호 쌍 없이 이진 신호만으로
GSPO (2025) — importance ratio를 시퀀스 단위로
DAPO (2025) — 신호 없는 프롬프트를 버린다

6부. Process & Verifiable Reward

Let's Verify Step by Step (2023) — 과정 감독이 결과 감독을 이긴다
Math-Shepherd (2023) — 사람 라벨 없는 PRM
DeepSeek-R1 (2025) — RLVR, 규칙이 reward가 될 때

7부. Generative Reward Model

Prometheus 2 (2024) — 오픈 평가자 모델과 rubric 조건부 평가
Generative Verifiers (2024) — reward를 next-token prediction으로
Generative Reward Models (2024) — GenRM과 선호 학습의 결합
Self-Taught Evaluators (2024) — 사람 라벨 없이 judge를 키우다
DeepSeek-GRM / SPCT (2025) — inference-time scaling

8부. 생각하는 Judge, 그리고 그 신뢰

ReasonGRM (2025) — reasoning 능력을 judge에 이식
J1 (2025) — RL로 judge를 생각하게 만들기
Rubrics as Rewards (2025) — 비검증 도메인으로
CriticEval (2024) — judge 자체를 어떻게 평가하나
One Token to Fool LLM-as-a-Judge (2025) — GenRM도 뚫린다

9부. 실전 종합

프론티어 모델의 reward 설계 (2025~2026) — 열 개 모델이 실제로 택한 것
reward를 어떻게 설계할 것인가 — 시리즈를 관통한 RM 설계 원칙 한 장

본 시리즈는 42편으로 구성된다.

참고 문헌

Dai et al. (Peking University), 2023. Safe RLHF: Safe Reinforcement Learning from Human Feedback (ICLR 2024).
Ji et al. (Peking University), 2023. BeaverTails: Towards Improved Safety Alignment of LLM via a Human-Preference Dataset — Safe RLHF의 데이터셋.
Mu et al. (OpenAI), 2024. Rule Based Rewards for Language Model Safety — #15에서 다룰 규칙 기반 안전 reward.
Touvron et al. (Meta), 2023. Llama 2 — #8에서 다룬 helpfulness·safety RM 분리.

Safe RLHF: 안전성을 reward가 아니라 '제약'으로 다룬다