Chapter 6. 모델 개발과 오프라인 평가

6.1 모델 개발과 훈련

6.1.1 머신러닝 모델 평가

모델 선택 시 활용할 수 있는 팁

최첨단만 추종하는 함정이 빠지지 않기
가장 단순한 모델부터 시작하기
1. 단순함이 유용한 세 가지 측면
  1. 단순한 모델은 배포하기 쉽다. 모델을 빨리 배포할수록 예측 파이프라인이 훈련 파이프라인과 일치하는지 보다 빨리 확인할 수 있다.
  2. 단순한 것에서 시작해 복잡한 구성 요소를 단계별로 추가하는 편이 모델을 이해하고 디버깅하기 더 쉽다.
  3. 가장 단순한 모델은 보다 복잡한 모델의 비교 대상으로서 베이스라인 역할을 수행한다.
2. 단순한 모델로 시작하면 모델을 손쉽게 개선해볼 여지가 많다.
모델을 선택할 때 사람의 편향을 주의하기
1. 모델 평가 과정에는 사람의 편향이 들어갈 수 밖에 없다. ML 아키텍처를 평가하는 프로세스 중 일부는 아키텍처에 대한 최적 모델을 찾기 위해 다양한 피처와 하이퍼파라미터 집합을 실험해본다. 엔지니어가 특정 아키텍처에 관심이 크다면 실험하는 데 훨씬 많은 시간을 들일 테고 그 아키텍처에 대해 더 성능이 좋은 모델을 만들어낼 가능성이 높다.
2. 모델 아키텍처 성능은 평가 맥락, 예컨대 작업, 훈련 데이터, 테스트 데이터, 하이퍼파리미터 등에 크게 좌우되므로 특정 모델 아케틱처가 다른 아키텍처보다 낫다고 단언하기는 어렵다.
현재 성과와 미래 성과를 비교 평가하기
트레이드오프를 평가하기
1. ML 시스템의 성능을 결정하는 요소 중 무엇이 더 중요한지 이해하면 가장 적합한 모델을 선택하는 데 도움이 된다.

모델의 가정을 이해하기

모든 단일 모델은 자신만의 가정이 있다. 모델이 무엇을 가정하며 데이터가 그 가정을 실제로 충족하는지 이해한다면 유스 케이스에 가장 적합한 모델이 무엇인지 평가할 수 있다.

흔히 사용하는 가정 중 일부

| 예측 가정

Prediction assumption	입력 X에서 출력 Y를 예측하는 것이 목표인 모델은 X를 기반으로 Y를 예측할 수 있다고 가정한다.
IID (Independent and Identically Distributed)	신경망은 각각의 데이터 포인트가 독립적이고 분포가 동일하다고 가정한다. 이는 모든 데이터 포인트가 동일한 결합 분포에서 독립적으로 추출됐다는 의미이다.
매끄러움 (Smoothness)	모든 머신러닝 지도 학습 방법은 입력을 출력으로 변환하는 함수 집합을 가정한다. 이때 유사한 입력값은 유사한 출력값으로 변환된다. 입력 X가 출력 Y를 생성한다면 X에 가까운 입력값은 비례적으로 Y에 가까운 출력값을 생성한다.
계산 가능성 (Tractability)	X는 입력이고 Z는 X의 잠재 표현이라고 할 때 생성 모델은 확률 P(Z
경계 (Boudaries)	선형 분류기는 결정 경계가 선형이라고 가정한다.
조건부 독립 (Conditional independence)	나이브 베이즈 분류기는 정해진 클래스에 대해 속성값들이 상호 독립이라고 가정한다.
정규 분포
(Normally distributed)	많은 통계적 방법론은 데이터가 정규 분포를 따른다고 가정한다.

6.1.2 앙상블

단일 모델을 개발한 뒤에 성능을 지속적으로 향상하기 위한 한가지 방법은 개별 모델이 아니라 여러 모델의 앙상블을 사용해 예측하는 것이다. 앙상블 내의 각 모델을 기본 학습기basic learner라고 한다.
앙상블을 만드는 방법은 배깅, 무스팅, 스태킹 등 세 가지이다. 여러 조사 연구 논문에 따르면 리샘플링과 부스팅, 배깅 같은 앙상블 기법은 성능 향상 외에도 불균형 데이터셋 문제 완화에 크게 도움이 된다.
배깅
- 배깅은 부트스트랩 집계Bootstrap Aggregating의 줄임말로, ML 알고리즘의 훈련 안정성과 정확도를 모두 개선하도록 설계되었다. 분산을 줄이고 과적합을 방지하는 데 효과적이다. 데이터셋이 주어지면 전체 데이터셋으로 하나의 분류기를 훈련하는 대신 복원 추출을 수행해 여러 데이터셋을 생성한다. 각 데이터셋을 부트스트랩이라고 하며, 각 부트스트랩으로 분류 또는 회귀 모델을 훈련한다. 복원 추출이므로 각 부트스트랩은 서로 독립적으로 생성된다.
- 배깅은 일반적으로 불안정성이 높은 기법의 성능을 개선한다. 예를 들어, 신경망, 분류 및 회귀 트리나 선형 회귀의 변수 하위 집합 선택이 있다. 반면에 k-최근접 이웃처럼 안정적인 기법의 성능은 다소 저하될 수 있다.
- 랜덤 포레스트는 배깅의 일종이다. 배깅에 피처의 무작위성을 더해 구성한 의사 결정 트리의 모음으로, 각 트리는 무작위로 정한 피처 하위 집합에서 사용할 피처를 선택하게 된다.
부스팅
- 부스팅은 약한 학습기를 강한 학습기로 바꾸는 반복 학습 앙상블 알고리즘의 일종이다. 앙상블을 구성하는 각 학습기는 동일한 샘플 집합으로 학습하지만 반복마다 각 샘플에 가중치를 다르게 준다. 결과적으로 나중에 더해지는 약한 학습기는 이전의 약한 학습기들이 잘못 분류한 데이터 포인트에 더욱 집중하게 된다.
- 부스팅의 각 단계
  1. 원래 데이터셋으로 첫번째 약한 분류기를 훈련한다.
  2. 샘플마다 첫 번째 분류기에서 얼마나 잘 분류되는지에 따라 가중치가 부여된다. 예컨대 잘못 분류된 샘플에는 더 높은 가중치가 부여된다.
  3. 가중치가 부여된 데이터셋으로 두 번째 분류기를 훈련한다. 앙상블은 첫 번째와 두 번째 분류기로 구성한다.
  4. 샘플마다 앙상블에서 얼마나 잘 분류되는지에 따라 가중치가 재부여된다.
  5. 가중치가 재부여된 데이터셋으로 세 번째 분류기를 훈련한다. 앙상블에 세 번째 분류기를 추가한다.
  6. 필요한 만큼 반복한다.
  7. 최종적으로 기존 분류기의 가중치 조합으로 강한 분류기를 구성한다. 분류기의 훈련 오차가 적을수록 가중치가 높다.
스태킹
- 스태킹은 훈련 데이터로 기본 학습기를 훈련하고, 기본 학습기의 출력을 결합해 최종 예측을 수행하는 메타 학습기를 만든다. 메타 학습기는 단순한 휴리스틱일 수 있다. 즉, 모든 기본 학습기에 대해 다수결 투표(ex. 분류 작업) 혹은 평균 투표(ex. 회귀 작업)를 수행한다. 기본 학습기로는 로지스틱 회귀 모델이나 선형 회귀 모델 등 서로 다른 정류의 모델 집합을 사용할 수 있다.

6.1.3 실험 추적과 버전 관리

모델 개발 프로세스에서, 문제에 가장 적합한 모델을 선택하려면 다양한 아키텍처와 모델을 실험해봐야 한다. 어떤 모델들은 서로 비슷해 보여도 성능이 극단적으로 다르다. 실험 및 관련 아티팩트를 재현하는 데 필요한 정의를 모두 추적하는 것이 중요하다. 아티팩트는 실험 중에 생성되는 파일을 말한다. 아티팩트의 예로 손실 곡선, 평가 손실 그래프, 로그, 훈련 프로세스 전반에 걸쳐 생성되는 모델 중간 결과 파일 등이 있다. 이는 다양한 실험을 비교하고 필요에 따라 가장 적합한 실험을 선택하는 데 도움이 된다. 다양한 실험을 비교하면 작은 변화가 모델 성능에 얼마나 영향을 미치는지 파악할 수 있으며, 결과적으로 모델 작동 방식에 대한 가시성이 높아진다.
실험 진행 상황과 결과를 추적하는 과정을 실험 추적이라고 하며, 나중에 재현하거나 다른 실험을 비교할 목적으로 실험의 모든 세부 정보를 기록하는 프로세스를 버전 관리라고 한다. 이 둘은 밀접하게 연관돼 있다. ML플로 MLflow와 웨이츠 앤 바이어스 Weights&Bias라는 도구는 실험 추적 용도로 만들어졌다가 버전 관리 기능이 통합됐으며, 반대로 DVC는 버전 관리 용도로 만들어졌다가 실험 추적 기능이 통합됐다.

실험 추적

ML 모델을 훈련할 때 학습 프로세스를 살펴보는 일은 큰 비중을 차지한다. 훈련 과정에는 다양한 문제가 발생하는데 이러한 문제를 감지해 해결하고 모델이 유용한 정보를 제대로 학습하고 있는지 평가하려면 훈련 중 발생하는 상황을 계속 추적하는 일이 중요하다.

훈련 과정에서 각 실험에 대해 고려할만한 추적 지표

손실 곡선	훈련 데이터셋과 각 평가 데이터셋에서 측정한 손실 곡선
모델 성능 지표	정확도, F1, 퍼플렉서티 등 테스트를 제외한 데이터셋에서 주로 측정하는 모델 성능 지표
샘플, 예측값, Ground Truth 쌍에 대한 로그	임시로 빠르게 살펴보는 분석과 새너티 체크sanity check에 유용하다.
모델 훈련 속도	초당 처리되는 단계수로 평가하거나, 데이터가 텍스트일 때는 초당처리되는 토큰 수로 평가한다.
시스템 성능 지표	메모리 사용량, CPU/GPU 사용률 등으로, 병목 현상을 식별하고 시스템 자원 낭비를 방지하는 데 매우 중요하다.
매개변수와 하이퍼파라미터	변경 시 모델 성능에 영향을 미치는 모든 매개변수와 하이퍼파리미터의 시간에 따른 값

실험 추적을 통해 다수의 실험에 대한 비교가 가능하다. 구성 요소가 변하면 모델 성능에 어떤 영향을 미치는지 관찰해 그 요소의 역할을 어느 정도 이해할 수 있다.

버전 관리
- ML 시스템은 일부는 코드이고 일부는 데이터이므로 코드뿐 아니라 데이터도 버전을 지정해야 한다.
- 데이터 버전 관리가 어려운 몇 가지 이유
  - 데이터가 종종 코드보다 훨씬 크기 때문에 보통은 코드 버전 관리 전략을 데이터 버전 관리에 동일하게 사용하기가 어렵다.
  - diff를 어떻게 정의할지 명확하지 않고 의견이 분분하기 때문이다.
  - 사용자 데이터 모델을 훈련한다면 일반 데이터 보호 규정(GDPR) 등으로 해당 데이터의 버전 관리가 복잡해진다.
최선의 모델을 찾기 위해 수많은 실험을 해야 하는 것은 ML을 블랙박스로 취급한 결과이다. 어떤 구성이 가장 잘 작동할지 예측할 수 없으므로 여러 구성을 직접 실험해봐야한다.

ML 모델 디버깅

디버깅은 소프트웨어 개발의 본질적인 요소이다. ML 모델도 예외는 아니다. 디버깅은 결코 즐겁지 않지만 ML 모델 디버깅은 특히나 고통스러울 수 있다.
1. ML 모델 실행은 명시적인 중단이나 출력 없이 조용히 실패하곤 한다. 코드가 컴파일되고, 손실은 예상대로 감소하고, 올바른 함수가 호출된다. 예측은 이뤄졌지만 예측값은 사실 잘못됐다. 개발자는 오류를 알아차리지 못한다. 최악은 사용자 또한 알아채지 못한 채 애플리케이션이 제대로 작동하는 줄 알고 예측값을 사용할 때이다.
2. 버그를 찾았다고 생각하더라도 버그가 수정됐는지 확인하는 작업은 답답할 만큼 느리다. 전통적인 소프트웨어 프로그램을 디버깅할 때는 버그가 있는 코드를 변경하고 결과를 즉시 확인할 수 있지만 ML 모델을 변경할 때는 그렇지 않다. 모델을 다시 학습시키고 버그가 수정됐는지 확인하기 위해 모델이 수렴할 때까지 기다려야 하며, 이는 몇 시간이 걸릴 수도 있다. 심지어 모델이 사용자에게 배포될 때까지 버그가 수정됐는지 확신할 수 없는 경우도 있다.
3. ML 모델 디버깅은 기능 간 복잡도로 인해 매우 까다롭다. ML 시스템에는 데이터, 레이블, 피처, ML 알고리즘, 코드 인프라 등 다양한 구성 요소가 있으며, 구성 요소마다 서로 다른 팀에서 관장하곤 한다. 오류가 발생하면 그 원인이 한 가지 구성 요소 혹은 여러 구성 요소의 조합 때문일 수 있어 어디를 살펴봐야 하며 누가 조사해야 할지 결정하기가 어렵다.

모델 실패 원인

이론상의 제약조건	모델이 학습하는 데이터가 그 가정에 부합하지 않아서 모델이 실패할 수 있다.
잘못된 모델 구현	모델에 구성 요소가 많을수록 문제가 생길 가능성이 높고 어디에 문제가 생겼는지 파악하기가 어렵다.
잘못된 하이퍼파리미터 선택	모델이 데이터에 매우 적합하고 구현이 정확해도 하이퍼파라미터 집하빙 잘못되면 해당 모델은 쓸모없어질 수 있다.
데이터 문제	데이터 수집과 전처리 단의 다양한 문제로 모델 성능이 저하될 수 있다.
잘못된 피처 선택	모델 학습에 피처를 너무 많이 사용하면 모델이 후련 데이터에 과적합되거나 데이터 누수가 발생할 수 있다. 반대로 피처를 너무 적게 사용하면 모델이 예측을 제대로 못 하는 예측력 부족 현상이 발생한다.

몇 가지 디버깅 기법

| 단순하게 시작하고 점진적으로 구성 요소를 추가하기 | 가장 단순한 모델에서 시작해 구성 요소를 천천히 추가하면서 성능이 향상되는지 혹은 하락하는지 확인한다. 많은 사람이 최신 모델의 오픈 소스 구현물을 복제한 다음 자신의 데이터를 연결하는 식으로 작업을 시작한다. 잘만 작동한다면 탁월한 선택이지만 그렇지 않다면 모델의 수많은 구성 요소로 인해 문제가 발생할 수 있으며 시스템을 디버깅하기 몹시 어려워진다. | | --- | --- | | 단일 배치에 과적합시키기 | 모델을 단순하게 구현해 소량의 훈련 데이터로 과적합시키고, 동일한 데이터를 평가해서 도달 가능한 최소 손실을 달성하는지 확인한다. 데이터가 적은데도 과적합이 안 된다면 구현에 문제가 있을 수 있다. | | 무작위 시드 값을 고정하기 | 가중치 초기화, 드롭아웃, 데이터 셔플링 등 모델이 무작위성을 가져오는 요인은 너무 많다. 무작위성은 다양한 실험 결과를 비교하기 어렵게 한다. 성능 변화가 모델 때문인지 달라진 무작위 시드 값 때문인지 알기 어렵다. 무작위 시드 값을 고정하면 서로 다른 실행 간에 일관성이 보장되며 오류 상황이나 다른 사람의 결과를 재현해낼 수 있다. |