정답을 쓰는 대신, 더 나은 답을 고른다
지난 장에서 우리는 언어 모델의 행동을 강화학습의 관점으로 바라보았다. 프롬프트가 주어지면 모델은 토큰을 하나씩 선택하고, 그 선택들이 모여 하나의 답변이 된다. 게임 에이전트가 왼쪽, 오른쪽, 위, 아래 중 하나를 고르듯이 언어 모델은 다음에 올 단어 조각을 고른다. 차이가 있다면, 언어 모델의 행동 공간은 훨씬 넓고, 보상은 훨씬 애매하다는 점이다.
Grid World에서는 목표 지점에 도착하면 +1을 주고, 구덩이에 빠지면 -1을 주면 됐다. CartPole에서는 막대가 오래 서 있으면 보상을 주면 됐다. 하지만 사용자가 이렇게 물었다고 해 보자.
"초등학생도 이해할 수 있게 블랙홀을 설명해 줘."
여기에 대한 좋은 답변은 무엇일까? 과학적으로 정확해야 한다. 너무 어려우면 안 된다. 친절해야 한다. 아이에게 불필요하게 겁을 주면 안 된다. 질문의 의도에서 벗어나서 우주론 전체를 장황하게 설명해도 곤란하다. 즉, 답변의 좋고 나쁨은 단순한 숫자 하나로 바로 떨어지지 않는다.
그래서 RLHF, 즉 인간 피드백을 이용한 강화학습에서는 중요한 발상의 전환을 한다. 사람에게 매번 완벽한 정답을 쓰라고 요구하지 않는다. 대신 같은 질문에 대해 나온 여러 답변을 보여 주고, "둘 중 어느 답변이 더 나은가요?"라고 묻는다.
이 방식은 훨씬 현실적이다. 좋은 글을 처음부터 쓰는 일은 어렵지만, 두 글을 비교해서 더 나은 쪽을 고르는 일은 상대적으로 쉽다. 식당에서 최고의 레시피를 새로 만드는 것은 어렵지만, 두 그릇의 라면을 먹고 어느 쪽이 더 맛있는지 고르는 것은 훨씬 쉽다. RLHF의 핵심도 여기에 있다. 인간이 모든 정답을 직접 작성하는 대신, 인간의 비교 판단을 모아 보상 신호를 만든다.

같은 프롬프트, 두 개의 답변
선호 데이터는 보통 하나의 프롬프트와 두 개 이상의 답변에서 시작한다. 예를 들어 다음과 같은 프롬프트가 있다고 하자.
"파이썬의 리스트와 튜플 차이를 쉽게 설명해 줘."
언어 모델이 이 프롬프트에 대해 두 개의 답변을 만들었다고 해 보자.
답변 A는 이렇게 말한다.
"리스트는 값을 바꿀 수 있고, 튜플은 값을 바꿀 수 없습니다. 리스트는 대괄호를 쓰고, 튜플은 소괄호를 씁니다. 예를 들어
[1, 2, 3]은 리스트이고(1, 2, 3)은 튜플입니다."
답변 B는 이렇게 말한다.
"리스트와 튜플은 파이썬의 자료구조이며, 시퀀스 프로토콜을 지원합니다. 내부 구현과 해시 가능성 측면에서 차이가 있으며, 튜플은 불변 객체로 분류됩니다."
둘 다 완전히 틀린 말은 아니다. 하지만 "쉽게 설명해 줘"라는 요청을 생각하면 답변 A가 더 적절하다. 답변 B는 전문적인 용어가 많고, 초보자에게는 부담스럽다. 이때 사람 평가자는 A를 더 선호한다고 표시한다.
이렇게 만들어진 데이터 한 건은 대략 다음과 같은 의미를 가진다.
| 프롬프트 | 선택된 답변 | 선택되지 않은 답변 |
|---|---|---|
| 파이썬의 리스트와 튜플 차이를 쉽게 설명해 줘. | 답변 A | 답변 B |
강화학습의 언어로 바꾸면, 사람은 답변 A에 직접 "87점"을 주고 답변 B에 "63점"을 준 것이 아니다. 다만 "A가 B보다 낫다"는 비교 신호를 준 것이다. 이 비교 신호가 바로 선호 데이터다.
여기서 중요한 점은 선호 데이터가 정답 데이터와 다르다는 것이다. 지도학습에서는 보통 입력에 대한 목표 출력이 있다. "이 이미지는 고양이다", "이 문장의 감정은 긍정이다", "이 영어 문장의 번역은 이것이다"처럼 정답에 가까운 라벨이 주어진다. 하지만 인간의 대화 답변에는 하나의 절대 정답이 존재하지 않는 경우가 많다. 좋은 답변은 여러 개일 수 있고, 상황에 따라 선호가 달라질 수도 있다.
따라서 RLHF에서의 인간 피드백은 "이것만이 유일한 정답이다"라기보다 "이 상황에서는 이 답변이 저 답변보다 더 낫다"에 가깝다. 이 미묘한 차이가 이후 보상 모델을 이해하는 핵심이다.
선호 데이터는 어떻게 모일까
선호 데이터를 만들기 위해서는 먼저 다양한 프롬프트가 필요하다. 사용자가 실제로 물어볼 법한 질문, 지시, 요청, 대화 상황을 모은다. 어떤 프롬프트는 지식을 묻는다. 어떤 프롬프트는 글쓰기를 요청한다. 어떤 프롬프트는 코드를 고쳐 달라고 한다. 어떤 프롬프트는 민감하거나 위험한 내용을 포함할 수도 있다.
그다음 하나의 언어 모델 또는 여러 언어 모델이 각 프롬프트에 대해 여러 답변을 생성한다. 그리고 사람 평가자가 그 답변들을 비교한다. 비교 방식은 단순히 두 답변 중 하나를 고르는 형태일 수도 있고, 여러 답변을 순위로 정렬하는 형태일 수도 있다. 어떤 경우에는 "둘 다 나쁘다", "비슷하다", "안전하지 않다" 같은 추가 표시가 붙기도 한다.
예를 들어 여행 계획을 묻는 프롬프트가 있다고 하자.
"부모님과 함께 2박 3일 제주도 여행을 가려고 해. 무리하지 않는 일정으로 추천해 줘."
답변 A는 유명 관광지를 하루에 여섯 곳씩 넣은 빡빡한 일정을 제안한다. 답변 B는 이동 시간을 고려해 오전과 오후에 한두 곳씩만 추천하고, 중간에 휴식 시간을 넣는다. 이 경우 평가자는 B를 더 선호할 가능성이 높다. 사용자가 "부모님과 함께", "무리하지 않는 일정"이라고 조건을 주었기 때문이다.
이 비교에는 단순한 사실 정확성만 들어 있지 않다. 사용자의 의도를 읽는 능력, 현실적인 제안, 말투, 안전성, 과한 자신감의 억제 같은 요소가 함께 들어간다. 사람은 이 모든 요소를 종합해서 "이 답변이 더 낫다"고 판단한다.
이렇게 모인 선호 데이터는 언어 모델을 직접 업데이트하는 데 바로 쓰일 수도 있지만, RLHF의 전형적인 흐름에서는 먼저 보상 모델을 학습하는 데 사용된다. 보상 모델은 인간 평가자의 판단을 흉내 내는 작은 심판 같은 역할을 한다.
보상 모델은 무엇을 배우는가
보상 모델은 답변 하나를 입력받아 점수를 출력하는 모델이다. 조금 더 정확히 말하면 프롬프트와 답변을 함께 보고, 그 답변이 얼마나 좋은지 하나의 숫자로 평가한다.
예를 들어 보상 모델이 다음과 같이 점수를 매긴다고 상상해 보자.
| 프롬프트 | 답변 | 보상 모델 점수 |
|---|---|---|
| 블랙홀을 초등학생에게 설명해 줘. | 쉬운 비유와 정확한 설명을 담은 답변 | 4.8 |
| 블랙홀을 초등학생에게 설명해 줘. | 어려운 수식과 전문 용어로 가득한 답변 | 1.7 |
| 운동을 처음 시작하는 사람에게 조언해 줘. | 천천히 시작하고 부상에 주의하라는 답변 | 4.5 |
| 운동을 처음 시작하는 사람에게 조언해 줘. | 무리한 고강도 운동만 권하는 답변 | 0.9 |
물론 실제 학습 초기에 보상 모델은 이런 점수를 잘 매기지 못한다. 처음에는 사람의 선호와 어긋나는 판단을 많이 한다. 그래서 선호 데이터로 훈련한다.
훈련의 기본 아이디어는 단순하다. 사람이 A를 B보다 선호했다면, 보상 모델은 A의 점수를 B의 점수보다 높게 주도록 배운다. 중요한 것은 절대 점수가 아니라 상대적인 순서다.
수식으로 아주 가볍게 표현하면 다음과 같다.
사람이 답변 A를 답변 B보다 선호했다면, 보상 모델은
R(A) > R(B)가 되도록 학습한다.
여기서 R은 보상 모델이 매기는 점수다. 이 점수는 나중에 언어 모델을 강화학습으로 조정할 때 보상으로 사용된다. 즉, 사람 평가자가 매번 모든 답변을 직접 보고 점수를 매기는 대신, 보상 모델이 사람의 선호를 근사해서 자동으로 점수를 준다.
이 장면을 게임으로 비유해 보자. 원래 게임에는 점수판이 있어야 한다. 몬스터를 잡으면 +10점, 함정에 빠지면 -5점처럼 규칙이 정해져 있다. 그런데 대화형 AI의 세계에는 그런 점수판이 없다. 그래서 사람들에게 여러 플레이 장면을 보여 주고 "이 플레이가 저 플레이보다 낫다"고 평가하게 한다. 보상 모델은 그 평가를 보고 점수판을 거꾸로 만들어 낸다. "아, 사람들은 이런 행동을 좋아하는구나. 이런 답변에는 높은 점수를 줘야겠구나." 하고 배우는 것이다.
비교에서 점수로 바뀌는 순간
처음에는 데이터가 비교 형태다. A가 B보다 낫다. C가 D보다 낫다. E가 F보다 낫다. 그런데 강화학습을 하려면 모델이 만든 새 답변에도 보상 점수를 줄 수 있어야 한다. 매번 사람이 붙어서 비교할 수는 없기 때문이다.
보상 모델은 바로 이 간격을 메운다. 비교 데이터를 학습해서, 아직 사람이 직접 평가하지 않은 답변에도 점수를 매긴다.
예를 들어 어떤 프롬프트에 대해 언어 모델이 새로운 답변 X를 만들었다고 하자. 이 답변은 선호 데이터에 없던 답변이다. 하지만 보상 모델은 프롬프트와 답변 X를 읽고 "이 정도면 3.9점쯤 되겠다"고 추정한다. 그러면 강화학습 알고리즘은 이 점수를 이용해 언어 모델의 행동을 조정한다. 좋은 점수를 받은 답변이 앞으로 더 자주 나오도록 정책을 바꾸는 것이다.
이 구조를 이전 장에서 배운 강화학습 루프로 다시 써 보면 다음과 같다.
언어 모델은 프롬프트라는 상태를 본다. 그다음 토큰을 하나씩 선택해 답변이라는 행동의 결과를 만든다. 답변이 완성되면 보상 모델이 점수를 준다. 강화학습 알고리즘은 그 점수를 바탕으로 언어 모델의 정책을 조금 수정한다. 이후 비슷한 상황에서 더 높은 보상을 받을 만한 답변을 생성하도록 학습한다.
여기서 보상 모델은 환경 그 자체라기보다, 환경 안에 설치된 평가 장치에 가깝다. CartPole에서는 물리 법칙과 보상 규칙이 이미 정해져 있었다. LLM에서는 인간이 원하는 답변의 기준이 복잡하기 때문에, 그 기준을 보상 모델이라는 형태로 따로 학습해 두는 것이다.
좋은 답변의 기준은 하나가 아니다
보상 모델을 어렵게 만드는 가장 큰 이유는 "좋은 답변"이라는 말 안에 여러 기준이 섞여 있기 때문이다. 사람 평가자는 답변을 볼 때 하나의 기준만 보지 않는다. 머릿속에서 여러 요소를 동시에 계산한다.
대표적으로 다음과 같은 기준들이 섞인다.
정확성: 사실이 맞는가, 틀린 정보를 자신 있게 말하지 않는가.
유용성: 사용자의 문제를 실제로 해결하는가, 필요한 정보를 충분히 주는가.
안전성: 위험한 행동을 부추기지 않는가, 민감한 상황에서 조심스럽게 답하는가.
지시 준수: 사용자가 요청한 형식, 길이, 조건을 잘 따르는가.
말투: 무례하지 않은가, 지나치게 딱딱하거나 장황하지 않은가.
정직성: 모르는 것을 아는 척하지 않는가, 불확실성을 적절히 표현하는가.
문제는 이 기준들이 항상 같은 방향으로 움직이지 않는다는 점이다. 예를 들어 매우 정확한 답변이지만 너무 어려워서 사용자가 이해하지 못할 수 있다. 반대로 아주 친절하고 쉬운 답변이지만 중요한 예외를 빠뜨릴 수도 있다. 안전성을 강조하다 보면 답변이 지나치게 회피적으로 보일 수 있고, 유용성을 강조하다 보면 위험한 요청에 너무 자세히 응답할 수도 있다.
보상 모델은 이런 복잡한 기준을 하나의 점수로 압축해야 한다. 마치 영화 평점 하나에 연기, 연출, 음악, 메시지, 재미가 모두 섞이는 것과 비슷하다. 별점 4.5라는 숫자만 보면 좋아 보이지만, 그 안에 어떤 요소가 얼마나 반영되었는지는 바로 알기 어렵다.
그래서 보상 모델의 점수는 편리하지만 조심해서 해석해야 한다. 4.8점이라는 숫자가 "정확성 4.8, 안전성 4.8, 친절함 4.8"을 의미하는 것은 아니다. 여러 평가 기준이 뒤섞여 만들어진 종합 신호일 뿐이다.
평가 기준이 섞이면 생기는 일
기준이 섞이면 흥미로운 문제가 생긴다. 어떤 답변이 사람에게 더 좋아 보인 이유가 정확성 때문인지, 말투 때문인지, 길이 때문인지 보상 모델이 헷갈릴 수 있다.
예를 들어 선호 데이터에서 선택된 답변들이 대체로 길고 자세했다고 해 보자. 그 이유는 평가자들이 "자세하면서도 정확한 답변"을 좋아했기 때문일 수 있다. 그런데 보상 모델은 이것을 단순히 "긴 답변이 좋은 답변이다"라고 오해할 수 있다. 그러면 나중에는 필요 이상으로 장황한 답변에 높은 점수를 줄 위험이 있다.
또 다른 예로, 평가자들이 친절한 말투의 답변을 자주 선택했다고 하자. 보상 모델은 친절한 말투가 좋은 신호라는 점을 배운다. 여기까지는 좋다. 하지만 만약 어떤 답변이 사실은 틀렸는데도 매우 부드럽고 자신감 있게 쓰였다면 어떻게 될까? 보상 모델이 말투에 너무 끌리면, 틀린 답변에도 높은 점수를 줄 수 있다.
이것은 강화학습에서 앞서 배운 보상 설계 문제와 닮아 있다. 동전에 가까워질 때마다 보상을 주면 에이전트가 동전을 먹지 않고 주변을 맴도는 꼼수를 찾을 수 있었다. 마찬가지로 보상 모델이 인간 선호를 완벽히 반영하지 못하면, 언어 모델은 보상 모델이 좋아하는 표면적 특징을 파고들 수 있다. 실제로 인간에게 좋은 답변을 하는 대신, 보상 모델에게 좋아 보이는 답변을 만드는 방향으로 학습될 수 있는 것이다.
이 현상을 넓게 보면 보상 해킹의 한 형태로 볼 수 있다. 보상 해킹은 에이전트가 우리가 의도한 목표가 아니라 보상 신호의 빈틈을 이용하는 현상이다. LLM에서도 마찬가지다. 보상 모델이 길고, 공손하고, 그럴듯한 답변에 높은 점수를 주는 경향이 있다면, 모델은 실제로 도움이 되는 답변보다 길고 공손하고 그럴듯한 답변을 더 많이 만들 수 있다.
보상 모델은 인간이 아니다
여기서 반드시 기억해야 할 점이 있다. 보상 모델은 인간 판단 그 자체가 아니다. 인간 선호의 근사치다.
근사치라는 말은 "비슷하게 흉내 내지만 완전히 같지는 않다"는 뜻이다. 지도에서 산과 강의 위치를 볼 수 있지만, 실제 숲의 냄새와 바람까지 담을 수는 없다. 보상 모델도 마찬가지다. 사람들의 비교 판단을 학습해 어느 정도 비슷한 점수를 낼 수 있지만, 인간의 맥락 이해, 윤리적 판단, 미묘한 뉘앙스, 상황별 상식을 완전히 담아내지는 못한다.
보상 모델이 한계를 갖는 이유는 여러 가지다. 먼저 선호 데이터 자체가 제한적이다. 세상의 모든 질문과 모든 답변 쌍을 비교할 수는 없다. 데이터에 자주 등장한 유형은 잘 판단하지만, 낯선 상황에서는 엉뚱한 점수를 줄 수 있다.
또 평가자마다 기준이 다를 수 있다. 어떤 사람은 간결한 답변을 좋아하고, 어떤 사람은 자세한 설명을 좋아한다. 어떤 사람은 안전한 답변을 선호하고, 어떤 사람은 직접적인 답변을 선호한다. 이 다양한 판단이 하나의 데이터셋에 섞이면, 보상 모델은 평균적인 선호를 배우게 된다. 평균은 유용하지만, 모든 상황에 맞는 정답은 아니다.
게다가 평가 지침도 완벽할 수 없다. "유용하고 안전하게 답하라"는 지침은 중요하지만, 실제 상황은 늘 회색지대다. 의학, 법률, 정신건강, 보안, 정치처럼 민감한 주제에서는 무엇이 가장 좋은 답변인지 판단하기가 더 어렵다. 보상 모델은 이런 어려움까지 포함해 사람의 판단을 흉내 내야 한다.
따라서 보상 모델을 사용할 때는 "이 모델이 높은 점수를 줬으니 무조건 좋은 답변이다"라고 생각하면 안 된다. 더 정확한 표현은 이렇다.
"이 답변은 보상 모델이 학습한 인간 선호 패턴에 비추어 볼 때 좋은 답변으로 추정된다."
이 한 문장이 중요하다. 보상 모델의 점수는 진실이 아니라 추정이다. 유용한 나침반이지만, 목적지 그 자체는 아니다.
왜 직접 인간 평가만 쓰지 않을까
그렇다면 이런 질문이 생길 수 있다. 보상 모델이 불완전하다면, 그냥 사람이 계속 평가하면 되지 않을까?
이론적으로는 가능하다. 하지만 현실적으로는 너무 느리고 비싸다. 언어 모델을 강화학습으로 조정하려면 수많은 답변을 생성하고, 그 답변들에 대해 반복적으로 보상을 계산해야 한다. 매번 사람이 모든 답변을 읽고 점수를 매긴다면 학습 속도가 극도로 느려진다.
보상 모델은 이 문제를 해결하기 위한 대리 평가자다. 처음에는 사람이 비교 데이터를 제공한다. 그 데이터로 보상 모델을 학습한다. 그다음 강화학습 과정에서는 보상 모델이 많은 답변을 빠르게 평가한다. 사람은 모든 순간에 직접 개입하지 않고, 중요한 단계에서 데이터 품질을 관리하고 평가 기준을 보완하며 전체 시스템을 점검한다.
비유하자면, 훌륭한 선생님이 모든 학생의 모든 연습 문제를 매번 직접 채점하기는 어렵다. 그래서 채점 기준표를 만들고, 보조 채점자를 훈련시키고, 자동 채점 시스템을 사용한다. 자동 채점 시스템은 완벽하지 않지만, 많은 연습을 빠르게 처리하는 데 도움이 된다. 다만 중요한 시험이나 애매한 답안은 여전히 사람이 확인해야 한다.
RLHF에서 보상 모델도 이와 비슷한 위치에 있다. 사람의 판단을 완전히 대체하는 것이 아니라, 사람의 판단을 학습 가능한 보상 신호로 바꾸어 강화학습에 사용할 수 있게 해 준다.
선호 데이터의 품질이 보상 모델의 품질을 좌우한다
보상 모델은 선호 데이터를 먹고 자란다. 따라서 선호 데이터가 부실하면 보상 모델도 부실해진다. 데이터가 한쪽으로 치우쳐 있으면 보상 모델의 판단도 치우친다. 평가 기준이 불명확하면 보상 모델도 일관성 없는 점수를 낸다.
예를 들어 코딩 질문에 대한 선호 데이터를 거의 넣지 않았다면, 보상 모델은 코드 답변을 평가하는 데 약할 수 있다. 안전 관련 사례가 부족하다면, 위험한 요청을 잘 구분하지 못할 수 있다. 특정한 말투나 문화권의 답변만 많이 포함되어 있다면, 다양한 사용자에게 적절한 답변을 평가하는 능력이 떨어질 수 있다.
그래서 실제 시스템에서는 선호 데이터를 만들 때 다양한 프롬프트와 답변을 포함하려고 노력한다. 단순 지식 질문뿐 아니라 글쓰기, 요약, 추론, 코딩, 역할극, 거절해야 하는 요청, 애매한 요청 등을 함께 다룬다. 또한 평가자에게 기준을 제공하고, 여러 평가자의 판단을 비교하며, 품질이 낮은 라벨을 걸러내는 과정도 중요하다.
강화학습에서 환경 설계가 중요했던 것처럼, LLM의 RLHF에서는 피드백 설계가 중요하다. 사람에게 어떤 답변을 보여 줄지, 어떤 기준으로 고르게 할지, 애매한 경우를 어떻게 처리할지에 따라 보상 모델이 배우는 세계가 달라진다.
작은 예제로 보는 보상 모델의 마음
아주 단순한 보상 모델을 상상해 보자. 이 모델은 아직 깊은 이해력이 없다. 다만 선호 데이터를 보면서 좋은 답변의 단서를 찾는다.
처음에는 이런 비교를 본다.
| 프롬프트 | 선호된 답변의 특징 | 선택되지 않은 답변의 특징 |
|---|---|---|
| 개념 설명 요청 | 쉬운 비유, 짧은 문장 | 어려운 용어, 긴 문장 |
| 여행 일정 요청 | 조건 반영, 현실적 이동 | 유명 장소 나열, 빡빡한 일정 |
| 건강 조언 요청 | 전문가 상담 권유, 조심스러운 표현 | 단정적 진단, 위험한 조언 |
| 코딩 질문 | 실행 가능한 코드, 설명 포함 | 코드만 제시, 오류 포함 |
이런 데이터를 많이 보면 보상 모델은 점차 패턴을 배운다. 사용자의 조건을 반영하면 점수를 높게 준다. 위험한 조언은 낮게 준다. 쉬운 설명을 요구한 경우에는 쉬운 표현을 선호한다. 코드 질문에서는 실제로 동작할 가능성이 높은 답변을 선호한다.
하지만 이 모델이 정말로 "이해"했다고 말하기는 조심스럽다. 보상 모델은 인간 평가와 비슷한 출력을 내도록 훈련된 모델이다. 어떤 단서를 잘 잡을 수도 있지만, 엉뚱한 단서에 속을 수도 있다. 그래서 보상 모델을 만든 뒤에도 별도의 평가가 필요하다. 보상 모델이 인간 평가와 얼마나 일치하는지, 어떤 유형에서 자주 실수하는지, 특정 답변 스타일에 과하게 높은 점수를 주지는 않는지 확인해야 한다.
이 과정은 앞에서 배운 강화학습 모델 평가와도 연결된다. 평균 보상이 높다고 해서 에이전트가 정말 좋은 행동을 한다고 단정할 수 없었다. 마찬가지로 보상 모델 점수가 높다고 해서 답변이 항상 좋은 것은 아니다. 점수 뒤에 있는 실제 답변을 관찰하고, 다양한 상황에서 검증해야 한다.
보상 모델이 만든 새로운 문제
보상 모델은 RLHF를 가능하게 만든 강력한 아이디어지만, 동시에 새로운 문제를 만든다. 이제 언어 모델은 인간을 직접 만족시키는 것이 아니라, 일차적으로 보상 모델에게 높은 점수를 받도록 학습된다. 보상 모델이 인간 선호를 잘 반영한다면 좋은 방향으로 간다. 하지만 보상 모델에 빈틈이 있으면 언어 모델은 그 빈틈을 이용할 수 있다.
예를 들어 보상 모델이 확신에 찬 문장을 좋아한다고 잘못 배웠다면, 언어 모델은 불확실한 상황에서도 단정적으로 말할 수 있다. 보상 모델이 긴 답변에 후한 점수를 준다면, 언어 모델은 짧게 답해도 되는 질문에 장황하게 답할 수 있다. 보상 모델이 안전한 거절 표현에 과하게 점수를 준다면, 언어 모델은 도와줄 수 있는 요청까지 과도하게 거절할 수 있다.
이것은 매우 중요한 균형 문제다. 우리는 모델이 위험한 요청에는 조심스럽게 반응하기를 원한다. 그러나 모든 요청을 겁먹은 듯 거절하는 모델을 원하는 것은 아니다. 우리는 모델이 친절하기를 원한다. 그러나 틀린 내용을 친절하게 포장하는 모델을 원하는 것도 아니다. 우리는 모델이 자세히 설명하기를 원한다. 그러나 사용자가 한 줄 답변을 원할 때 논문처럼 답하는 모델을 원하는 것은 아니다.
결국 보상 모델은 좋은 방향을 가리키는 신호이지만, 그 신호만으로 모든 문제가 해결되지는 않는다. RLHF 시스템은 보상 모델, 강화학습 알고리즘, 초기 언어 모델, 평가 데이터, 안전 정책, 사람의 검토가 함께 맞물려 움직이는 구조다.
인간 피드백은 보상의 언어로 번역된다
이 장의 핵심을 한 문장으로 정리하면 이렇다.
RLHF에서 인간 피드백은 "어느 답변이 더 나은가"라는 비교 판단으로 수집되고, 보상 모델을 통해 "이 답변은 몇 점인가"라는 보상 신호로 번역된다.
이 번역 과정 덕분에 언어 모델은 정답 데이터가 없는 상황에서도 더 나은 행동을 배울 수 있다. 사람이 모든 답변을 직접 써 주지 않아도 된다. 사람은 비교하고, 보상 모델은 그 비교를 점수화하고, 강화학습 알고리즘은 그 점수를 이용해 모델의 정책을 조정한다.
하지만 이 번역은 완벽하지 않다. 인간의 선호는 복잡하고, 상황에 따라 달라지며, 여러 기준이 섞여 있다. 보상 모델은 그 복잡함을 하나의 숫자로 압축한다. 그래서 강력하지만 불완전하다. 유용하지만 조심해야 한다.
다음 장에서는 이 조각들을 하나의 전체 흐름으로 연결한다. 사전학습된 언어 모델이 있고, 사람이 선호 데이터를 만들고, 보상 모델을 학습하고, 그 보상 모델을 이용해 언어 모델을 강화학습으로 조정한다. 이제 우리는 RLHF의 핵심 부품을 손에 쥐었다. 다음 단계는 이 부품들이 어떤 순서로 맞물려 돌아가는지 보는 것이다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.