0.RLHF

인간의 피드백을 반영하는 강화학습(Reinforcement Learning from Human Feedback, RLHF)을 적용하여 최적의 프롬포트를 탐색하고자 했습니다.

유저의 DB를 이용하여 유저에게 최적화된 프롬포트를 생성하여 실시간 맞춤형 일기 서비스를 제공하고자 시도했습니다.

1. Abstract

• 문제 상황
  • 더 나은 일기 서비스를 실시간으로 제공하기 위해 GPT API의 성능을 한층 더 이끌어낼 방안이 필요했습니다.
• 문제 정의
  • GPT API를 활용할 경우, 모델 자체를 서버에서 실시간으로 학습할 수 없다는 한계가 있습니다.
  • 이에 따라, 모델 학습이 아닌 **'프롬포트(Prompt)를 개선'**하는 방향으로 문제를 재정의했습니다.
  • 후보 프롬포트 A, B, C, D를 설정하고, 이 중 가장 우수한 성능을 보이는 프롬포트를 찾는 문제 구조로 설계했습니다.
• 접근 방식
  • 이 문제를 강화학습(Reinforcement Learning)의 **다중 선택 문제(Multi-Armed Bandit, MAB)**로 정의하여 접근했습니다. 각 프롬포트(A, B, C, D)를 슬롯머신의 'Arm'으로 간주하고, 인간의 피드백을 '보상(Reward)'으로 사용하여 최적의 프롬포트(Arm)를 찾는 것을 목표로 했습니다.

2. Experiment

• 실험 설계
  • 일기 생성의 품질을 다르게 유도하는 4개의 후보 프롬포트(A, B, C, D)를 정의했습니다.
• 탐색 과정
  • MAB 알고리즘(예: Epsilon-greedy, UCB 등)을 기반으로 프롬포트를 선택하여 사용자에게 일기 결과물을 제시합니다.
  • 사용자의 피드백(예: "좋아요", "다시 생성")을 보상 신호로 변환하여 각 프롬포트의 가치를 업데이트합니다.
  • 이 과정을 반복하여 누적 보상을 최대화하는, 즉 가장 나은 사용자 경험을 제공하는 프롬포트를 탐색합니다.

2-1. Architecture

• 실험 설계:

  1. 이전에 우리가 최선이라고 생각하고 작성한 프롬포트를 "A"로 지정합니다.
  2. 프롬포트 A를 이용하여 GPT API가 일기(text)를 생성합니다.
  3. GPT API가 생성한 text들에 대해 -1(매우 나쁨), -0.5(나쁨), 0(보통), +0.5(약간 좋음), +1(매우 좋음)으로 사람이 직접 평가(rate)를 진행합니다. (사람의 피드백 반영)
  4. 사람의 피드백이 반영된 (text, rate) 쌍으로 구성된 데이터들을 이용하여, text가 입력되었을 때 -1~+1 값으로 일기를 평가하여 reward를 부여하는 **보상 모델(Reward Model)**을 학습시킵니다.
  5. 1~+1에 해당하는 text들을 참고하여 GPT가 기존의 프롬포트 A를 개선시킨 새로운 프롬포트 B, C, D를 생성합니다.
  6. 프롬포트 A, B, C, D와 학습된 보상 모델을 이용하여 다중 선택 문제(MAB)를 수행합니다.
  7. 최적의 프롬포트를 채택합니다.

• 문제 아키텍처 시각화:

2-2. Data

• 데이터 생성:

  • 보상 모델을 학습시키기 위해 총 500개의 일기 내용을 GPT API로 생성합니다.
  • 생성 방법: 100장의 이미지와 랜덤한 장소, 인물, 기분을 샘플링하여 조합한 문맥을 생성하여 GPT API의 입력 값으로 사용합니다.
  

• 데이터 평가 (Human Feedback):

  • 생성된 500개의 일기 데이터에 대해 사람이 직접 평가를 반영합니다.

  • 평가 기준:

    +1 : 표현이 풍부하고, 문장이 자연스럽고 어색하지 않으며, 길이가 풍부한 일기. 0.5 : 표현이 부족하지 않고, 문장이 어색하지 않으며, 적당한 길이의 일기. 0 : 문법상 문제 없고, 무난하지만 특별히 풍부하지도 않은 일기. -0.5 : 문맥이 어색하거나 문법에 약간 문제가 있으며, 길이가 짧은 일기. -1 : 일기 형식에서 벗어나거나 수정할 부분이 많은 일기. 너무 짧은 일기.

  • 위 기준에 따라 500개 일기에 대한 평가를 진행합니다.

  

• 데이터 분리:

  • 500개의 (일기, 평가) 데이터를 랜덤하게 섞은 후, Train data 450개와 Test data 50개로 분리합니다.

• 데이터 분석:

  • Train data의 분포를 시각화합니다.
  
  • 분석 결과:
    • 사전에 최적이라고 판단된 프롬포트(A)를 사용하여 일기를 생성했기 때문에, 대부분의 데이터가 0점 이상을 받았습니다.
    • 간혹 발생하는 문법 오류나 확률적으로 생성된 엉뚱한 일기에 대해 -0.5, -1점이 부여되어 음수 평가(rate)의 비율이 매우 적습니다.
    • 결론적으로, **데이터가 긍정적인 평가에 편향(biased)**되어 있습니다.
  • 해결 방안 (Oversampling):
    • 모델 학습 시 데이터 불균형 문제를 완화하기 위해 Oversampling 기법을 도입했습니다.
    • 데이터 수가 적은 rate의 데이터들을 **단순 복제(duplication)**하는 기법을 적용했습니다.
    • (이유: 부족한 rate에 대해 데이터 변이(augmentation)를 일으켜 증식하는 기법은 원본의 문맥이 파괴될 가능성이 있다고 판단하여 단순 복제 방식을 선택했습니다.)

2-3. Reward Model

보상 모델은 GPT API가 생성한 일기를 입력으로 받아 -1~+1 사이의 점수를 출력하는 회귀(Regression) 문제로 설정되었습니다.

• 임베딩: 일기는 한국어를 지원하는 임베딩 모델(distiluse-base-multilingual-cased-v2)을 이용하여 임베딩했습니다. 이 임베딩 모델은 학습 과정에서 freeze시켰습니다.
• 모델 선정: 학습 데이터가 450개로 적기 때문에 딥러닝 모델은 좋은 성능을 보이지 못했습니다. 대신 다양한 머신러닝(ML) 모델을 적용하여 성능을 비교했습니다.
• 학습: 데이터 편향 문제를 해결하기 위해 2-2에서 언급한 오버샘플링(Oversampling)된 데이터를 학습에 사용했습니다.

1. 머신러닝(ML)을 이용한 결과

• 다양한 ML 모델을 비교한 결과, RandomForestRegressor가 가장 좋은 성능을 보였습니다.

• RandomForestRegressor는 Valid dataset에 대해 MSE=0.2288, MAE=0.4002의 오차를 기록했습니다.
• (구조: 일기 텍스트 → 임베딩 → Layer → RandomForestRegressor)
• Valid dataset 예측 시각화:

• Test dataset 성능:
  • Test dataset에 대해 MSE=0.2711, MAE=0.4126을 기록했습니다.
  • Test dataset 예측 시각화:
    

• ML 모델의 한계:
  1. Test MSE 0.2711, MAE 0.4126은 -1~+1 사이의 점수를 예측하는 문제에서 성능이 매우 저조함을 의미합니다.
  2. 모델이 임베딩된 문장을 입력받았을 때, 실제 평가 기준(표현의 풍부함, 문맥 등)을 반영해 점수를 매기는지 해석하거나 신뢰하기 어려웠습니다.
  3. 이는 단순히 입력값에 따라 정해진 출력값을 뱉어내는 수준의 **"중국어 방 문제(Chinese Room Problem)"**와 같은 한계를 보였습니다.
• 결정: 신경망 및 머신러닝 기반 보상 모델 구축을 포기하고, GPT API 자체를 보상 모델로 사용하기로 결정했습니다.

2. GPT API를 이용한 결과 (최종 채택)

• 실험 설계:

  • GPT API를 보상 모델로 사용하여 일기 평가를 수행했습니다.
  • Prompting: 평가 기준을 프롬프트에 명시하고, Few-shot 방식으로 각 기준(Rate)에 부합하는 일기 예시를 함께 제공했습니다.
  • 출력 설정: 출력값은 1, -0.5, 0, +0.5, +1의 **이산 값(Discrete values)**으로 설정했습니다. (초기에 연속적인 실수 값을 출력하도록 시도했으나, 오히려 성능이 저하되어 이산 값 방식으로 회귀 문제를 설정했습니다.)

• 성능:

  • 이 방식으로 평가한 GPT API의 Test dataset에 대한 오차는 다음과 같습니다.
  • MSE=0.2650, MAE=0.3500을 기록했습니다.
  • Test dataset 예측 시각화:
  

• 결론:

  • ML 모델(RandomForest)보다 MSE가 소폭 감소했지만, 여전히 성능이 충분히 확보되지는 않았습니다. (이 부분은 "한계 분석" 섹션에서 자세히 다룹니다.)
  • 우선, 최종적으로 일기를 평가하는 GPT API를 보상 모델로 채택하였습니다.

2-4. MAB 수행

• Arms (프롬프트):

  • 프롬프트 A: 기존에 사용하던 베이스라인 프롬프트
  • 프롬프트 B, C, D: 기존 일기와 평가 점수(Reward)를 기반으로, GPT가 '더 나은 일기'를 생성하도록 개선하여 생성한 신규 프롬프트들

• 알고리즘:

  • 4개의 프롬프트(A, B, C, D) 중 어떤 것이 보상 모델(GPT API)로부터 평균적으로 가장 높은 점수(Reward)를 받는지 확인하기 위해 **MAB(다중 선택 문제)**를 수행했습니다.
  • 탐색(Exploration)과 활용(Exploitation)의 균형을 맞추기 위해 UCB(Upper Confidence Bound) 알고리즘을 적용했습니다.

• 실행 및 결과:

  • Iteration = 200으로 설정 후 MAB를 수행한 최종 결과는 아래와 같습니다.
  
  • 각 프롬프트의 Reward 분포 시각화:
  

3. Result & Limitation

3-1. Result

• 보상 모델 성능 비교:
  • RandomForest 기반 보상 모델 (Test): MSE=0.2711, MAE=0.4126
  • GPT API 기반 보상 모델 (Test): MSE=0.2650, MAE=0.3500
• 최적 프롬프트:
  • MAB 수행 결과(Iteration 200), 프롬프트 C가 평균 보상 0.81을 획득하여 최적의 프롬포트로 결정되었습니다.
• 결과 해석:
  • 수치상으로는 프롬프트 C가 가장 우수했으나, 보상 모델 자체의 성능(MSE 0.2650)에 한계가 명확했습니다. 따라서 이 프롬프트가 정말로 최적의 프롬포트인지에 대해서는 신뢰하기 어렵습니다.

3-2. Limitation

• 모델의 한계 (보상 모델)
  1. 보상 모델은 인간의 피드백(문맥, 문법, 표현의 풍부함)을 반영해 평가를 내려야 하지만, 실제로는 복잡한 맥락을 충분히 고려하지 못하고 단순히 입력(Input)에 대해 숫자 값(Output)을 뱉는 수준에 그쳤습니다.
  2. 인간의 평가는 기계처럼 일관되지 않습니다. 평가 기준이 존재하더라도, 때로는 직관이나 감각에 따라 평가가 달라질 수 있습니다. 보상 모델은 이러한 **인간의 변칙성(inconsistency)**까지는 학습하지 못했습니다.
  3. 결론적으로, 일기 평가에 반영되어야 할 복잡한 맥락, 미묘한 문법 오류, 그리고 인간의 직관을 학습하기에 현 방식은 너무 단순했습니다.
• 데이터 수집 및 비용 한계
  1. 데이터 생성 비용: 보상 모델 학습을 위한 초기 일기 500개 생성에 GPT API 사용으로 인해 1~2달러의 비용이 발생했습니다.
  2. 인간 피드백 비용 (Labor cost): 500개의 일기 하나하나에 수동으로 rate를 부여하는 과정은 많은 시간과 노력이 드는 작업이었습니다.
  3. MAB 수행 비용: MAB 과정에서 각 프롬포트를 평가하는 보상 모델로 GPT API를 사용했기 때문에, Iteration이 증가할수록 API 호출 비용이 지속적으로 발생했습니다.
  4. 더 많은 데이터를 확보하면 보상 모델의 성능을 향상시킬 수 있었겠지만, 위와 같은 시간적, 금전적 문제로 인해 데이터 확장에 한계가 있었습니다.

3-3. 개선 방향 (Future Work)

데이터 수집 및 피드백 과정을 자동화하는 방향으로 개선을 고려하고 있습니다.

1. 데이터 수집 자동화:
   • GPT API가 생성한 초기 일기(Draft)와 유저가 최종적으로 수정한 뒤 저장한 일기(Final) 간의 유사도를 분석합니다.
2. 자동 피드백(Rate) 부여:
   • 이 유사도 점수를 기반으로 자동적으로 rate를 부여하는 로직을 개발합니다. (예: 유사도 90% 이상 = +1, 유사도 50% 미만 = -0.5)
   • 이 (text, auto-rate) 쌍을 지속적으로 DB에 저장하여 학습 데이터를 확보합니다.
3. 재시도:
   • 위와 같은 자동화 파이프라인을 통해 수 천 개 이상의 데이터가 확보된다면, 더 복잡하고 정교한 보상 모델(예: API가 아닌 LLM 모델)을 학습시켜 이 프로젝트를 다시 시도해볼 수 있습니다.