Skip to main content
Instruction 데이터는 “지시 -> 응답” 구조입니다. 좋은 데이터는 모델이 따라야 할 행동을 명확히 보여줍니다.

​
기본 스키마

{
  "id": "task_0001",
  "messages": [
    {"role": "system", "content": "너는 기술 문서를 구조화해 작성하는 어시스턴트다."},
    {"role": "user", "content": "다음 로그에서 장애 원인을 3줄로 요약해줘."},
    {"role": "assistant", "content": "원인: ...\n영향: ...\n즉시 조치: ..."}
  ],
  "metadata": {
    "domain": "incident-response",
    "difficulty": "medium",
    "language": "ko"
  }
}

​
작성 원칙

  1. 입력 조건을 구체적으로 적습니다
  2. 출력 형식(JSON, 표, bullet)을 명시합니다
  3. 금지 규칙(추측 금지, 근거 없는 단정 금지)을 포함합니다
  4. 정답 응답은 과장 없는 정답 스타일을 유지합니다

​
안 좋은 예 vs 좋은 예

구분안 좋은 예좋은 예
지시문”좋게 써줘""200자 이내, 핵심 원인 2개와 재발 방지책 1개를 bullet로 작성”
응답장황하고 포맷 불일치요구한 길이와 형식을 정확히 충족
난이도한쪽으로 치우침쉬움/보통/어려움을 분산

​
데이터 검증 체크리스트

  • 역할(role) 순서가 올바른가
  • 필수 필드 누락이 없는가
  • 출력 형식 규칙을 자동 검증할 수 있는가
  • 동일 요청의 중복 샘플이 과도하지 않은가
Instruction 데이터는 “모델에게 시범을 보이는 데이터”입니다. 라벨 품질이 낮으면 모델은 정확히 그 품질을 학습합니다.

​
실무 적용 체크리스트

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

​
자주 나는 실수

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

​
다음 문서

다음: Preference 데이터 설계

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