[LLM Fine-tuning] Day 5: 평가와 배포 - 파인튜닝 모델 검증과 운영 전략
서론: 학습이 끝나도 절반밖에 안 왔다
파인튜닝 완료는 시작이다. 모델이 실제로 목표를 달성했는지, 기반 모델의 일반 능력을 잃지 않았는지, 프로덕션 환경에서 안전하게 동작하는지 순서대로 검증해야 한다.
1. 파인튜닝 모델 평가 단계
1.1 태스크 특화 평가
파인튜닝 목표에 직접 대응하는 지표를 측정한다.
- 출력 형식 준수율
- 도메인 태스크 정확도 (F1, 정확일치율 등)
- LLM-as-Judge 점수 (기반 모델 vs 파인튜닝 모델 비교)
1.2 일반 능력 회귀 검사
파인튜닝은 catastrophic forgetting 위험이 있다. 표준 벤치마크로 기반 모델과 비교한다.
| 벤치마크 | 측정 대상 |
|---|---|
| MMLU | 일반 지식 |
| GSM8K | 수학 추론 |
| HumanEval | 코드 생성 |
| MT-Bench | 멀티턴 대화 |
목표 태스크 성능이 올라도 다른 능력이 크게 떨어지면 배포 적합성을 재검토해야 한다.
1.3 안전성 평가
- 기존 가드레일 우회 여부
- 유해 콘텐츠 생성 변화
- 프롬프트 인젝션 취약성 변화
파인튜닝이 안전 정렬을 약화시키는 경우가 있으므로, 안전성 평가를 생략하지 않는다.
2. LoRA 어댑터 병합
추론 시 어댑터를 분리 적재하면 지연이 추가된다. 배포 전에 기반 모델에 병합하면 추론 오버헤드가 없다.
1
2
3
4
5
6
from peft import PeftModel
base_model = AutoModelForCausalLM.from_pretrained(base_model_id)
model = PeftModel.from_pretrained(base_model, adapter_path)
merged_model = model.merge_and_unload()
merged_model.save_pretrained(output_path)
병합 후에는 어댑터를 분리해 기반 모델로 되돌릴 수 없다. 원본 어댑터를 별도 보관한다.
3. 배포 전략
3.1 Shadow 배포
기존 모델과 파인튜닝 모델을 병렬 운영한다. 파인튜닝 모델 응답은 저장만 하고 사용자에게 반환하지 않는다.
1
2
3
User Request
├─ Current Model → 사용자 응답
└─ Fine-tuned Model → 로그만 기록
품질 지표를 안전하게 비교할 수 있다.
3.2 카나리 배포
소수 트래픽(5~10%)을 파인튜닝 모델로 라우팅한다. 이상 감지 시 즉시 롤백한다.
3.3 버전 관리
| 구성 요소 | 버전 관리 필요 항목 |
|---|---|
| 모델 가중치 | 병합 전 어댑터 + 병합 후 모델 |
| 학습 데이터셋 | 버전 태그 + 변경 이력 |
| 프롬프트 템플릿 | 모델 버전과 연결 |
| 평가 결과 | 배포 결정 근거 기록 |
4. 지속적 파인튜닝 운영
파인튜닝은 1회성이 아니다.
1
2
3
4
5
프로덕션 피드백 수집
└─ 실패 케이스 추출
└─ 데이터셋 갱신 (골든셋 포함)
└─ 재학습 트리거
└─ 평가 통과 → 배포
이 사이클을 자동화하면 지속적으로 모델을 개선할 수 있다. 단, 데이터 품질 검토는 자동화에서 제외하는 것이 안전하다.
5. 시리즈 종합 체크리스트
- 프롬프트/RAG로 해결 불가능한 문제임을 확인한 뒤 파인튜닝을 선택했다.
- LoRA rank와 target modules를 실험을 통해 결정했다.
- 중복 제거와 품질 필터를 거친 큐레이션된 데이터셋을 사용했다.
- gradient checkpointing, 혼합 정밀도, 체크포인트 전략을 설정했다.
- 태스크 성능과 일반 능력 회귀 검사를 모두 완료한 뒤 배포했다.
시리즈 마무리
LLM 파인튜닝의 결론은 명확하다. 파인튜닝은 강력한 도구지만 올바른 문제에 사용될 때만 효과적이다.
데이터가 모델보다 먼저이고, 학습 파이프라인이 결과의 재현성을 결정하며, 배포 후 관측성이 없으면 파인튜닝이 도움이 됐는지조차 알 수 없다. 파인튜닝은 MLOps 전체 사이클의 한 단계이지, 독립된 해결책이 아니다.