Skip to main content
Preference 데이터는 하나의 질문에 대해 두 응답을 비교하고, 어느 쪽이 더 좋은지 라벨링한 데이터입니다.

​
기본 스키마

{
  "id": "pref_0001",
  "prompt": "장애 공지문 초안을 작성해줘",
  "chosen": "서비스 영향 범위와 복구 ETA를 포함한 명확한 공지",
  "rejected": "근거 없이 낙관적인 문장 위주 공지",
  "criteria": ["정확성", "명확성", "행동 가능성"],
  "metadata": {"domain": "ops", "language": "ko"}
}

​
라벨링 기준 예시

기준설명
정확성사실과 수치가 맞는가
충실성요청한 형식과 제약을 지켰는가
안전성금지된 조언/민감정보 유출이 없는가
실용성사용자가 바로 행동 가능한가

​
라벨링 프로세스

1

기준 정의

평가 기준과 우선순위를 문서화합니다. 기준 간 충돌 시 우선순위도 명시합니다.
2

파일럿 라벨링

소량 샘플로 라벨러 간 일치도를 먼저 확인합니다.
3

본 라벨링

난이도/도메인/언어를 균형 있게 배치해 편향을 줄입니다.
4

합의와 정제

불일치 샘플을 별도 검토해 최종 라벨로 확정합니다.

​
편향을 줄이는 방법

  • 항상 같은 생성 모델 조합으로 후보를 만들지 않습니다
  • 한 라벨러가 특정 도메인만 계속 맡지 않도록 순환합니다
  • 너무 쉬운 비교쌍(명백한 정답/오답) 비율을 제한합니다
Preference 데이터는 라벨러 선호를 강하게 반영합니다. 라벨링 가이드가 불명확하면 모델도 일관성을 잃습니다.

​
실무 적용 체크리스트

  • 이 문서의 규칙을 실제 서비스 플로우에 매핑했습니다.
  • 측정 지표와 실패 임계값을 숫자로 정의했습니다.
  • 변경 전/후를 비교할 기준 데이터셋 또는 로그를 준비했습니다.
  • 팀 내 공유 문서(런북/가이드)에 반영했습니다.

​
자주 나는 실수

  1. 기준 지표 없이 개선을 선언합니다.
  2. 한 번에 여러 변수를 바꿔 원인 추적이 불가능해집니다.
  3. 롤백 조건 없이 배포해 장애 복구가 늦어집니다.

​
다음 문서

다음: 데이터 품질 점검

학습 흐름을 이어서 진행합니다.