Jonas Kim

Posted on Nov 8

'머신러닝 시스템 설계' (Chip Huyen) 요약 - 파트 2

#ai #machinelearning #systemdesign #mlops

책 머신러닝 시스템 설계과 그에 대한 요약본 Summary of Designing Machine Learning Systems을 참고하였습니다.

6 - 모델 개발 및 오프라인 평가

초기 학습 피처 세트가 준비되면, 드디어 모델 개발을 시작할 수 있습니다. 피처 엔지니어링과 모델 개발은 반복적인 과정임을 명심하십시오.

이 장에서는 다음 내용을 다룹니다.

모델 선택, 개발 및 학습
- ML 모델 선택 기준
- 모델 선택의 일부로서의 앙상블(Ensembles)
- 모델 개발 중 실험 추적 및 버전 관리
- ML 모델 디버깅
- 분산 학습 모드: 데이터 병렬성, 모델 병렬성, 파이프라인 병렬성
- AutoML: 자동 하이퍼파라미터 튜닝, 자동 아키텍처 탐색, 학습된 옵티마이저
오프라인 평가: 최상의 모델을 선택하기 위해 모델 대안을 평가하는 방법
- 베이스라인: 모델을 비교할 대상이 필요합니다.
- 전반적인 ML 지표를 넘어서는 오프라인 평가 방법: 프로덕션에 보내기 전에 모델의 견고성(robustness), 공정성(fairness), 건전성(sanity) 평가하기.

모델 선택, 개발 및 학습

ML 모델 선택 기준

모델 선택 결정을 내릴 때는 여러 측면의 균형을 맞춰야 합니다. 모델 선택은 과학이라기보다는 예술에 가깝습니다. 이 장은 고려해야 할 사항에 대한 몇 가지 가이드라인과 팁을 제공합니다.

팁 1: 적재적소에 올바른 도구 사용하기

당면한 문제에 적합한 모델에만 집중하여 모델 선택의 탐색 공간을 좁히십시오. 예를 들어:

사기 탐지 시스템을 구축하려는 경우, 이것이 고전적인 이상 탐지(anomaly detection) 문제이며 이 문제 범주에 일반적으로 사용되는 모델이 KNN, isolation forest, 클러스터링, 신경망 등임을 알아야 합니다.
NLP 텍스트 분류 문제를 맡았다면, 옵션은 일반적으로 나이브 베이즈(naive-Bayes), 로지스틱 회귀, 순환 신경망(recurrent neural networks), 그리고 BERT나 GPT와 같은 트랜스포머 기반 모델입니다.

팁 2: 직면한 문제 유형에 대한 팀의 "성숙도 단계" 인지하기

주어진 문제에 대한 ML 채택에는 4가지 단계가 있습니다. 한 단계의 솔루션은 다음 단계의 솔루션을 평가하기 위한 베이스라인으로 사용될 수 있습니다.

1단계: Pre-ML (ML 이전): 이 유형의 문제를 처음 해결하는 경우입니다. 문제에 대한 첫 번째 시도는 "가장 인기 있는" 항목을 추천하거나 시간순으로 정렬하는 것과 같은 간단한 휴리스틱일 수 있습니다. ML이 아닌 솔루션만으로도 충분하다는 것을 발견할 수도 있습니다.
2단계: 가장 간단한 ML 모델: 이 문제에 대한 첫 번째 ML 모델이 될 것입니다. 팁 6: 가장 간단한 모델로 시작하기를 참조하십시오.
3단계: 간단한 모델 최적화: 목적 함수 최적화, 하이퍼파라미터 탐색, 피처 엔지니어링, 데이터 추가, 앙상블 생성 등을 통해 간단한 모델을 더 좋게 만듭니다.
4단계: 복잡한 모델: 간단한 모델의 한계에 도달했을 때 복잡한 모델로 이동합니다. 이 단계에서는 모델이 어떻게 노후화되는지(decay) (예: 재학습이 얼마나 자주 필요한지) 파악하여 재학습 파이프라인을 구축하고자 합니다.

팁 3: 학습 지표를 넘어서는 모델 속성 고려하기

정확도, F1, 로그 손실(log loss)과 같은 직접적인 학습 관련 성능 지표가 일반적으로 모델 선택에 사용됩니다. 그러나 이것들만이 고려해야 할 유일한 지표는 아닙니다.

필요한 데이터의 양, 모델의 계산 요구 사항, 학습 시간, 추론 지연 시간(inference latency), 모델 해석 가능성(interpretability)과 같은 다른 속성에도 신경 써야 합니다.

결정을 내리기 위해 선택하는 지표 세트는 문제에 따라 다릅니다. 예를 들어, 어떤 유스케이스에서는 정확도를 약간 희생하더라도 지연 시간이 매우 중요합니다.

팁 4: SOTA(State-of-the-art)의 함정 피하기

"SOTA" 성능을 가진 모델은 대개 연구에서 직접 나옵니다. 그러나 연구자들은 종종 기존의 미리 정의된 데이터셋을 사용하여 학술적인 환경에서만 모델을 평가합니다.

연구에서 SOTA 성능을 가졌다는 사실이 여러분이 구현하기에 모델이 충분히 빠르거나, 충분히 저렴하다는 것을 의미하지는 않습니다. 마찬가지로, 그것이 여러분의 데이터에서도 동일한 성능을 가질 것임을 의미하지도 않습니다.

SOTA 모델보다 훨씬 저렴하고 간단하면서도 문제를 해결할 수 있는 솔루션이 있다면, 더 간단한 솔루션을 사용하십시오.

팁 5: "고전 ML은 끝났다"는 함정 피하기

요즘 신경망이 언론의 많은 주목을 받고 있습니다. 하지만 그렇다고 해서 고전적인 ML 모델이 사라지는 것은 아닙니다. 고전적인 모델은 여전히 프로덕션 환경에서, 특히 지연 시간이나 설명 가능성(explainability)이 중요할 때, 광범위하게 사용됩니다.

또한, 고전적인 모델과 신경망 모델이 함께(in tandem) 배포되는 것을 보는 것도 드문 일이 아닙니다. 예를 들어:

신경망 모델과 결정 트리를 사용한 앙상블 구성.
k-means와 같은 고전적인 모델을 사용하여 피처를 추출하고, 이를 NN의 입력으로 사용.
BERT나 GPT-3 같은 사전 학습된 신경망을 사용하여 임베딩을 생성하고, 이를 로지스틱 회귀와 같은 고전적인 모델에 입력.

"신경망"이 아니라는 이유만으로 고전적인 모델을 무시하지 마십시오.

팁 6: 가장 간단한 모델로 시작하기

간단한 모델을 사용하면 프레이밍(framing)과 데이터를 조기에 검증할 수 있습니다.
간단한 모델은 배포하기 더 쉽습니다. 모델을 조기에 배포하면 다음과 같은 것들을 검증할 수 있습니다.
- 피처의 엔드-투-엔드(end-to-end) 동작
- 예측 파이프라인과 학습 파이프라인 간의 일관성
- 시스템의 자연 레이블 탐지 능력 (문제에 해당 사항이 있다면)
- 시스템의 데이터 분포 변화(data distribution shifts) 및 재학습 트리거 탐지 능력
간단하게 시작하여 더 복잡한 구성 요소를 천천히 추가하면 모델을 이해하고 디버깅하기가 더 쉬워집니다.
간단한 모델은 복잡한 모델과 비교할 수 있는 베이스라인이 됩니다.
간단한 모델과 노력이 적게 드는(low-effort) 모델은 다릅니다. 사전 학습된 BERT 모델을 사용하는 것은 (작업이 이미 완료되었기 때문에) 노력이 적게 들지만, 모델이 간단한 것은 아닙니다.
- 때로는 간단한 모델 대신 노력이 적게 들고 복잡한 모델로 시작하는 것이 합리적일 수 있습니다. 그러나 그런 경우에도 간단한 모델을 베이스라인으로 갖는 것은 가치가 있습니다. 왜냐하면 복잡한 모델을 개선하는 것은 매우 어렵기 때문입니다.

팁 7: 모델 선택 시 인간의 편향 피하기

선택하기 전에 다른 아키텍처들에게 비슷한 수준의 노력을 기울였는지 확인하십시오: 특정 아키텍처에 흥미를 느낀 엔지니어는 그것을 실험하는 데 더 많은 시간을 할애할 것입니다. 결과적으로, 덜 흥미를 느끼는 아키텍처에 비해 해당 아키텍처에서 더 나은 성능을 찾을 가능성이 높습니다.

팁 8: 현재의 좋은 성능 VS 미래의 좋은 성능 평가하기

지금 당장 최고의 모델이라고 해서 두 달 후에도 최고의 모델이 될 것이라는 의미는 아닙니다. 예: 지금 데이터가 거의 없다면 결정 트리가 가장 잘 작동할 수 있습니다. 두 달 후 데이터가 더 많아지면 NN이 더 잘 작동할 수 있습니다.
모델에 더 많은 데이터를 제공함에 따라 모델의 성능은 포화(saturate)되는 경향이 있습니다. 간단한 모델은 복잡한 모델보다 더 빨리 포화됩니다. 학습 곡선(learning curves)을 사용하여 모델이 가능한 한 많이 학습했는지(즉, 포화되었는지) 또는 가까운 미래에 개선될 잠재력이 여전히 있는지 평가할 수 있습니다.
- 모델이 포화되었다면, 더 복잡한 모델을 시도해 볼 때일 수 있습니다.

일부 팀은 챔피언-챌린저(champion-challenger) 방식으로 간단한 모델(현재 좋은 성능)과 복잡한 모델(미래에 좋은 성능)을 배포합니다. 더 많은 데이터가 확보됨에 따라 복잡한 모델을 계속 학습시키고, 복잡한 모델의 성능이 더 좋아지면 교체합니다.
모델을 선택할 때, 가까운 미래의 개선 잠재력과 그러한 개선을 달성하기 위한 난이도를 의사 결정에 고려할 수 있습니다.

팁 9: 트레이드오프(Trade-offs) 평가하기

모델 선택은 트레이드오프로 가득 차 있습니다. 특정 유스케이스에 무엇이 중요한지 이해하면 정보에 입각한 결정을 내리는 데 도움이 됩니다. 몇 가지 일반적인 트레이드오프는 다음과 같습니다.

False positives(FP) VS false negatives(FN) 트레이드오프. 예: 모델이 위험한 질병을 진단하는 경우, false negatives를 최소화하는 모델을 선호할 수 있습니다.
계산 집약도 VS 성능 트레이드오프: 더 크고 복잡한 모델이 더 정확할 수 있지만, 실행하는 데 더 강력한 기계와 특수 하드웨어가 필요할 수 있습니다.
지연 시간 VS 성능 트레이드오프: 더 크고 복잡한 모델이 더 정확할 수 있지만, 추론을 생성하는 속도가 더 느릴 것입니다. 일부 유스케이스에는 엄격한 지연 시간 요구 사항이 있습니다.
해석 가능성 VS 성능 트레이드오프: 모델 복잡성이 증가함에 따라 성능은 향상되는 경향이 있지만 모델의 해석 가능성은 감소합니다.

팁 10: 모델의 가정(Assumptions) 이해하기

모든 ML 모델에는 일부 내재된(baked-in) 가정이 있습니다. 이러한 가정을 이해하고 데이터가 이러한 가정을 충족하는지 조사하면 모델 선택에 지침이 될 수 있습니다.

모델에 의해 만들어지는 몇 가지 일반적인 가정의 샘플:

예측 가정: 모델은 X로부터 Y를 예측하는 것이 실제로 가능하다고 가정합니다. 때때로 데이터는 단지 무작위이며 학습할 패턴이 없습니다.
독립적이고 동일하게 분포된(Independent and Identically distributed, IID): 신경망을 포함한 많은 모델이 모든 예제가 IID라고 가정합니다.
평활성(Smoothness): 모든 지도 ML 모델은 입력 X를 추론 Y로 변환하기 위해 학습될 수 있는 평활(smooth) 함수가 있다고 가정합니다. 즉, 매우 유사한 입력 X와 X'는 비례적으로 가까운 출력을 생성해야 합니다.
다루기 쉬움(Tractability): X를 입력, Z를 X의 잠재 표현(latent representation)이라고 할 때, 생성 모델(Generative models)은 P(Z|X)를 계산하는 것이 다루기 쉽다고 가정합니다.
경계(Boundaries): 선형(linear) 방법은 결정 경계(decision boundaries)가 선형이라고 가정합니다. 커널(Kernel) 방법은 결정 경계가 사용된 커널의 모양을 따른다고 가정합니다.
조건부 독립(Conditional independence): 나이브 베이즈 분류기 기반 모델은 클래스가 주어졌을 때 피처 값들이 서로 독립이라고 가정합니다.
정규 분포: 많은 모델이 데이터가 정규 분포를 따른다고 가정합니다.

앙상블 (Ensembles)

앙상블을 사용하는 것은 단일 모델에 비해 지속적으로 성능 향상을 보여준 방법입니다. 앙상블에서는 여러 기본 학습기(base learners)가 학습되고 각각 예측을 출력합니다. 최종 예측은 다수결(majority vote)과 같은 휴리스틱을 사용하여 도출됩니다.

2021년 Kaggle 대회의 22개 우승 솔루션 중 20개가 앙상블을 사용했습니다. SQuAD 2.0의 상위 20개 솔루션은 앙상블입니다.

앙상블 방법은 배포 및 유지 관리가 더 어렵기 때문에 프로덕션 환경에서는 덜 선호됩니다. 그러나 작은 성능 향상이 막대한 재정적 이득으로 이어질 수 있는 작업에서는 여전히 일반적입니다.

앙상블을 만들 때, 기본 학습기 간의 상관관계가 적을수록 앙상블이 더 좋아집니다. 따라서, 앙상블을 위해 매우 다른 유형의 모델을 선택하는 것이 일반적입니다. 예를 들어, 하나의 트랜스포머 모델, 하나의 순환 신경망, 하나의 그래디언트 부스티드 트리(gradient-boosted tree)로 구성된 앙상블을 만들 수 있습니다.

투표에서 동점(tie)을 피하기 위해 홀수 개의 기본 학습기를 사용하는 것도 일반적입니다.

앙상블을 만드는 방법에는 배깅(bagging), 부스팅(boosting), 스태킹(stacking)의 3가지가 있습니다. 이러한 기술들은 결합될 수도 있습니다.

MLWave(전설적인 Kaggle 팀)의 앙상블 가이드에서 앙상블을 만드는 방법에 대한 훌륭한 조언을 찾을 수 있습니다.

배깅 (Bagging)

배깅은 많은 이점을 가집니다. 학습 안정성 향상, 정확도 향상, 분산(variance) 감소, 과적합 방지.
직관: 복원 추출(sample with replacement)을 사용하여 다른 데이터셋을 만듭니다. 각 데이터셋에서 분류 또는 회귀 모델을 학습시킵니다.
- 복원 추출은 각 부트스트랩(bootstrap)이 서로 독립적으로 생성되도록 보장합니다 (즉, 기본 학습기 간의 상관관계가 적어짐).
사용 시기: 불안정한 방법(예: NN, 분류 및 회귀 트리, 선형 회귀)의 안정성을 향상시킬 때.
- k-최근접 이웃(k-nearest neighbours)과 같은 안정적인 방법에서는 성능을 약간 저하시킬 수 있습니다.

부스팅 (Boosting)

직관:
- 1. 원본 데이터셋에서 첫 번째 약한 분류기(weak classifier)를 학습시키는 것으로 시작합니다.
- 2. 샘플들은 첫 번째 모델이 얼마나 잘 분류했는지에 따라 가중치가 재조정(re-weighted)됩니다. 잘못 분류된 예제는 더 높은 가중치를 갖습니다.
- 3. 가중치가 재조정된 샘플로 두 번째 분류기를 학습시킵니다.
- 4. 분류기 2의 출력에 따라 샘플 가중치가 다시 재조정됩니다.
- 5. 분류기 2에서 재조정된 가중치를 사용하여 세 번째 분류기를 학습시킵니다.
- 6. 필요한 만큼 반복합니다.
- 7. 기존의 모든 분류기들의 가중치 조합(weighted combination)으로 최종 강력한 분류기(strong classifier)를 형성합니다. 학습 오류가 작은 분류기가 더 높은 가중치를 갖습니다.
부스팅 알고리즘:
- GBM (Gradient Boosted Machines)
- XGBoost: 많은 ML 대회에서 선택되는 알고리즘.
- LightGBM: 분산 병렬 학습을 허용하는 XGBoost의 대안 (대규모 데이터셋에 좋음).

스태킹 (Stacking)

직관: 서로 다른 기본 학습기(일반적으로 서로 매우 다른 성격의)를 학습시킵니다. 최종 예측을 생성하기 위해, 기본 학습기들의 예측을 어떻게 결합할지 학습하는 메타 학습기(meta-learner)를 사용합니다.

메타 학습기는 다수결(분류) 또는 평균(회귀)과 같은 간단한 휴리스틱일 수 있습니다.
또는 로지스틱 회귀(분류)나 선형 회귀 모델(회귀)과 같은 또 다른 (일반적으로 더 간단한) 모델일 수도 있습니다.
#todo : 메타 학습기가 각 기본 학습기가 어떤 유형의 샘플에 능숙한지 학습할 수 있도록 피처에 대한 접근 권한도 부여하는 것이 일반적인가?

실험 추적 및 버전 관리

실험을 구성하는 설정 파라미터와 해당 실험이 생성하는 산출물(artefacts)을 추적하는 것은 모델 선택을 수행하고 실험 파라미터(데이터, 파라미터, 모델) 변경이 출력 모델의 성능에 어떤 영향을 미치는지 이해하는 데 핵심입니다.

실험 추적(Experiment tracking)과 버전 관리(versioning)는 서로 밀접하게 연관되어 있으며 보통 하나의 개념처럼 이야기되는 2가지 다른 개념입니다.

실험 추적: 실험의 진행 상황과 결과를 추적하는 프로세스.
버전 관리: 실험을 재현(replicate)할 수 있도록 모든 설정 파라미터를 로깅하는 프로세스.
원래 실험 추적을 위해 만들어졌던 많은 도구(예: MLFlow, Weights & Biases)가 이제 버전 관리를 포함하고 있으며, 그 반대(예: DVC)도 마찬가지입니다.

적극적인 실험 추적 및 버전 관리는 재현성(reproducibility)에 도움이 되지만, 이를 보장하지는 않는다(ENSURE IT)는 점을 명심하십시오.

실험 추적

실험 추적을 통해 ML 엔지니어는 학습 과정을 효과적으로 세심하게 관리할 수 있습니다; 이것은 학습의 매우 큰 부분입니다.
추적할 수 있는 몇 가지 예시는 다음과 같습니다.
- 학습 및 각 평가 분할(eval splits)의 손실 곡선(Loss curve).
- 테스트 분할을 제외한 모든 분할에서 관심 있는 모델 성능 지표: 정확도, F1, 퍼플렉시티(perplexity).
- <샘플, 정답, 예측> 로그. 건전성 확인(sanity check)을 위해 수동 분석이 필요한 경우 유용합니다.
- 초당 스텝 수로 평가한 모델 속도. 텍스트 기반 모델을 다루는 경우, 초당 처리된 토큰 수.
- 시스템 성능 지표: 메모리 사용량, CPU/GPU 사용량. 병목 현상을 식별하고 자원 낭비를 피하는 데 도움이 됩니다.
- 모델 성능에 영향을 미치는 모든 파라미터 및 하이퍼파라미터의 시간에 따른 값. 예: 학습률(learning rate), 그래디언트 놈(gradient norms) (전역 및 레이어별), 가중치 놈(weight norm).
이론적으로는, 가능한 모든 것을 추적하는 것이 나쁜 생각은 아닙니다. 실제로는, 모든 것을 추적하면 노이즈에 압도당하고 주의가 산만해질 것입니다.

버전 관리

ML 시스템은 부분적으로 코드이고, 부분적으로 데이터입니다. 둘 다 버전 관리해야 합니다.
데이터 버전 관리는 다음과 같은 이유로 어려운 부분입니다.
- 데이터는 코드보다 훨씬 크기 때문에 코드 버전 관리 도구를 재사용할 수 없습니다. 이전 버전으로 롤백(roll back)하기 위해 데이터셋을 여러 번 복제하는 것은 실현 불가능합니다.
- 데이터 버전 관리 시 정확히 무엇이 diff를 구성하는지에 대해 여전히 혼란이 있습니다.
  - 모든 변경 사항을 추적해야 하는가, 아니면 체크섬(checksum)만 추적해야 하는가?
  - 2021년 기준, DVC와 같은 도구는 전체 디렉토리의 체크섬만 등록합니다.
- 버전 관리되는 데이터에서 병합 충돌(merge conflicts)이 무엇인지 명확하지 않습니다.
- GDPR 또는 유사한 규정의 적용을 받는 사용자 데이터를 사용하는 경우, 데이터 삭제 요청을 준수하는 것이 불가능해집니다.

ML 모델 디버깅

ML 모델 디버깅은 여러 가지 이유로 어렵고 좌절스럽습니다.

ML 모델은 조용히 실패합니다(fail silently). 예측은 계속하지만 예측이 틀립니다. 때때로 모델에 버그가 있다는 것조차 모릅니다.
버그가 수정되었는지 확인하는 것은 답답할 정도로 느립니다. 모델을 재학습한 다음 새 모델로 샘플을 재평가해야 할 수도 있습니다. 때로는 프로덕션에 배포해야만 알 수 있습니다.
ML 모델에는 데이터, 레이블, 피처, ML 알고리즘, 코드, 인프라 등 여러 팀에서 발생할 수 있는 많은 실패 지점(points of failure)이 있습니다.

불행히도, ML 디버깅에 대한 과학적인 접근 방식은 없습니다. 그러나 일반적으로 좋은 관행으로 간주되는 몇 가지 검증된(tried and true) 기술이 있습니다.

단순하게 시작하여 점진적으로 구성 요소 추가: 이렇게 함으로써 현재 하고 있는 일이 성능에 도움이 되는지 해가 되는지 볼 수 있습니다. 이는 또한 예상되는 동작에 대한 직관을 얻는 데 도움이 됩니다.
- 오픈 소스 SOTA 구현을 복제하여 자체 데이터를 연결하는 것은 안티패턴(anti-pattern)입니다. 그것이 작동할 가능성은 매우 낮으며, 작동하지 않을 경우 디버깅하기가 매우 어렵습니다.
단일 배치에 과적합(Overfit)시키기: 모델의 간단한 구현을 마친 후, 작은 데이터 배치에 과적합시킨 다음 동일한 데이터에 대해 평가를 실행하여 가능한 가장 높은 정확도(또는 가장 낮은 손실)를 얻는지 확인합니다. 작은 과적합된 배치에서 매우 높은 정확도를 얻을 수 없다면, 무언가 잘못되었을 수 있습니다.
무작위 시드(random seed) 설정: ML 모델은 무작위성을 사용하는 곳이 많습니다. 무작위성은 성능 변화가 무작위성 때문인지 변경 사항 때문인지 알 수 없게 하여 실험을 비교하고 재현하기 어렵게 만듭니다. 여러 실험에서 일관된 무작위 시드를 사용하면 비교 가능성을 유지하는 데 도움이 됩니다.
더 많은 기술은 Adrej Karpathy의 포스트 "신경망 학습 레시피(A Recipe for Training Neural Networks)"에서 볼 수 있습니다.

분산 학습 (Distributed Training)

메모리에 맞지 않는 데이터로 모델을 학습시키는 것은 흔한 일입니다. 이런 일이 발생하면, 전처리(예: 정규화), 셔플링, 배치 구성 및 학습을 위한 알고리즘이 여러 머신에서 병렬로 수행되어야 합니다.

ML 엔지니어로서, 분산 학습과 ML 확장에 대한 경험을 쌓는 것은 어렵습니다. 왜냐하면 대량의 리소스에 접근해야 하기 때문입니다.

다음으로 몇 가지 분산 학습 모드를 다루겠습니다.

데이터 병렬성 (Data parallelism)

직관: 데이터를 여러 머신에 분할하고, 모든 머신에서 모델을 학습시킨 다음, 그래디언트(gradients)를 축적합니다.

이것은 가장 일반적인 병렬화 방법이지만 몇 가지 문제가 있습니다.

문제 1: 동기식(sync) vs 비동기식(async) 그래디언트 하강

데이터가 매우 클 때 (예: 1,000억 개 샘플), 전체 학습 세트를 여러 머신(예: 10대 머신, 머신당 100억 개 샘플)으로 분할하더라도 전체 학습 세트를 처리하고 그래디언트를 축적할 수 없습니다. 이는 여전히 실현 불가능합니다.

병렬이 아닌 경우와 마찬가지로, 미니배치(mini-batches)를 사용해야 합니다. 병렬이 아닌 경우와 달리, 병렬 학습에서는 미니배치를 사용 가능한 머신 수만큼 더 분할하고 각 머신이 미니-미니배치(mini-mini-batch)를 처리하게 합니다.

문제는 머신이 미니-미니배치 처리를 마친 후 가중치와 편향을 업데이트하는 방법을 결정해야 할 때 발생합니다.

동기식 확률적 경사 하강법 (sync-SGD): 이 접근 방식은 모든 머신이 각자의 미니-미니배치 처리를 마칠 때까지 기다린 다음 그래디언트를 축적합니다. 메인 노드(main node)가 그래디언트를 축적하고 가중치를 업데이트합니다. 모든 보조 노드(assisting nodes)는 메인 노드가 완료되면 새 모델 가중치를 다운로드하고 다음 미니배치 처리를 시작합니다.
- 장점: 더 빨리 수렴합니다.
- 단점: 느린 보조 머신 하나가 전체 시스템을 느리게 만듭니다. 머신이 많을수록 하나가 느릴 가능성이 커집니다. 이 문제를 해결하는 알고리즘들이 있습니다.
비동기식 확률적 경사 하강법 (async-SGD): 머신들은 미니-미니배치 처리를 마치는 즉시 메인 노드로 그래디언트를 보냅니다. 메인 노드는 다른 보조 노드를 기다리지 않고 즉시 가중치를 업데이트합니다. 보조 노드들은 업데이트된 버전의 모델을 즉시 다운로드하고 다음 미니-미니배치 작업을 시작합니다.
- 장점: 느린 노드로 인한 시스템 속도 저하가 없습니다.
- 단점: 이론적으로는 그래디언트 부실(gradient staleness) 때문에 수렴하는 데 더 많은 스텝이 필요합니다.
  - 실제로는, 그래디언트 업데이트가 희소(sparse)하다면, sync-SGD와 async-SGD 간의 수렴 속도에 거의 차이가 없습니다.

문제 2: 많은 수의 보조 노드 = 큰 배치 크기

만약 100개의 보조 GPU 노드에 접근할 수 있고 각 노드가 10,000개의 샘플로 구성된 미니-미니배치를 처리할 수 있다면, 미니배치 크기는 1백만이 될 것입니다. 더 큰 미니배치는 일반적으로 모델을 더 빨리 학습시킵니다. 왜냐하면 GPU는 샘플 수에 그다지 민감하지 않기 때문입니다 (즉, 샘플 수를 2배로 늘려도 계산 시간이 2배가 되지는 않습니다).

이론상 일반적인 경험 법칙은 미니배치 크기를 2배로 늘리면 학습률도 약 2배로 늘려야 한다는 것입니다. 하지만, 실제로는:

학습률을 너무 많이 높이면 수렴이 불안정해질 수 있습니다.
배치 크기를 특정 지점 이상으로 늘리면 효율이 체감(diminishing returns)됩니다.
학습률과 에포크(epoch) 수를 일정하게 유지하면서 배치 크기를 늘리면 정확도가 낮아질 수 있습니다.
배치 크기와 학습률 하이퍼파라미터 선택은 과학이라기보다는 예술입니다. Weights and biases에는 학습률 대 배치 크기의 직관에 대해 설명하는 훌륭한 비디오가 있습니다.

많은 수의 GPU에 접근할 수 있다는 이유만으로 미니배치 크기를 간과하거나 거대한 배치 크기를 사용하는 함정에 빠지지 마십시오.

모델 병렬성 (Model parallelism)

모델 병렬성에서는, 모델의 서로 다른 구성 요소가 서로 다른 머신에서 학습됩니다. 모델 병렬성과 데이터 병렬성은 상호 배타적이지 않습니다. 둘 다 동시에 수행될 수 있지만, 이러한 구성을 설정하려면 상당한 엔지니어링 노력이 필요합니다.

아래 그림은 하이브리드 데이터 및 모델 병렬성 구성을 보여줍니다. 이 구성에서 머신 2와 4는 첫 번째 단계(머신 1과 3)가 완료될 때까지 기다립니다. 유휴(Idle) 머신 시간은 나쁩니다. 파이프라인 병렬성은 이러한 유휴 시간을 줄이는 데 사용될 수 있습니다.

파이프라인 병렬성 (Pipeline parallelism)

이것에는 여러 변형이 있지만, 기본 아이디어는 모델을 여러 머신에서 실행되는 직렬 구성 요소로 분할한 다음 미니-미니배치의 입력을 시차를 두고(stagger) 공급하는 것입니다. 아래 그림이 이 구성을 보여줍니다. 파이프라인 병렬성이 대기 시간을 완전히 제거하지는 않지만, 줄여줍니다.

Auto ML

Auto-ML은 ML 엔지니어와 대학원생들이 하던 일부 반복적이거나 기계적인 작업을 해결하기 위해 더 많은 컴퓨팅 파워를 사용한다는 포괄적인 아이디어입니다.

소프트 Auto ML: 하이퍼파라미터 튜닝

하이퍼파라미터 튜닝은 주어진 모델에 대해 탐색 공간 내에서 최적의 하이퍼파라미터 세트를 찾는 것을 의미합니다.
2022년 기준, 이것은 Auto-ML의 가장 인기 있는 형태입니다.
주어진 모델과 데이터셋에 대해 하이퍼파라미터를 잘 튜닝하는 것은 성능에 극적인 영향을 미칠 수 있습니다.
- 잘 튜닝된 파라미터를 가진 약한 모델이 더 강한 모델보다 성능이 뛰어날 수 있다는 것도 보여졌습니다.
중요성에도 불구하고, 많은 기업이 여전히 하이퍼파라미터 튜닝에 대한 엄격하고 체계적인 접근 방식을 무시하고 수동의, 직관 기반 방법을 사용합니다.
많은 인기 있는 ML 라이브러리에는 자동 하이퍼파라미터 튜닝을 위한 내장 유틸리티가 있거나 서드파티 유틸리티가 있습니다. 예를 들어 sklearn에는 auto-sklearn, TensorFlow에는 Keras Tune, Ray Tune이 있습니다.
자동 하이퍼파라미터 튜닝의 인기 있는 방법으로는 랜덤 서치(random search), 그리드 서치(grid search), 베이지안 최적화(bayesian optimisation)가 있습니다.
모델 성능에 더 큰 영향을 미치는 하이퍼파라미터는 더 신중하게 튜닝해야 합니다.
하이퍼파라미터를 튜닝하는 데 테스트 분할(test split)을 절대 사용하지 마십시오. 검증 세트(validation set)를 기반으로 파라미터를 선택하고, 최종 성능을 평가할 때만 테스트 세트를 사용하십시오.
하이퍼파라미터 튜닝에 대한 심층 가이드는 Auto ML: Methods, Systems, Challenges 책의 1장에서 찾을 수 있습니다.

하드 Auto ML: 아키텍처 탐색 및 학습된 옵티마이저

아키텍처 탐색(Architecture search)과 학습된 옵티마이저(learned optimizers)는 두 가지 독립적인 AutoML 작업입니다 (이론적으로는 함께 사용될 수 있음). 2022년 기준, 이들은 아직 "연구" 단계에 있으며 프로덕션 환경의 기업에서 널리 사용되지는 않습니다.
두 작업 중 하나의 초기 계산 비용(up-front computation cost)이 너무 높아서 전 세계적으로 소수의 기업만이 이 분야의 연구를 추구할 여력이 있습니다.
일반 ML 엔지니어로서 AutoML의 진행 상황을 인지하는 것이 중요합니다. 왜냐하면:
- 아키텍처 탐색 연구에서 나온 아키텍처는 많은 실제 작업에 바로(off-the-shelf) 사용할 수 있을 만큼 충분히 일반적일 수 있으며, 여러분의 문제에 적용할 수 있습니다.
  - 아키텍처 탐색 연구는 더 높은 성능을 보이거나, 학습 및/또는 추론이 더 빠른 아키텍처 등을 생산해냈습니다. 예를 들어, Google AutoML 팀의 EfficientNets는 10배의 효율성으로 SOTA 정확도를 능가합니다.
- 학습된 옵티마이저 연구에서 나온 옵티마이저는 추가적인 사전 학습 없이(즉, 일종의 전이 학습(transfer learning) 형태가 될 수 있음) 다양한 작업에 적용할 수 있을 만큼 충분히 일반적일 수 있습니다. 이는 학습을 더 빠르고 안정적으로 만들 수 있습니다.
- 이러한 연구 분야의 결과물은 기존 아키텍처와 옵티마이저로는 이전에 불가능했던 많은 실제 문제를 해결하는 것을 가능하게 만들 수 있습니다.

아키텍처 탐색 (일명 Neural Architecture Search, NAS)

직관: 알고리즘을 사용하여 신경망의 아키텍처 파라미터(예: 레이어 크기, 스킵 레이어(skip layer) 추가 여부)를 체계적으로 변경하여 문제에 대한 최적의 아키텍처를 찾습니다.

NAS 문제에는 세 가지 구성 요소가 있습니다.

탐색 공간(A search space): 알고리즘이 변경할 수 있는 아키텍처 구성 요소(building blocks), 각각의 제약 조건, 그리고 이를 결합하는 규칙. 구성 요소 세트는 기본 아키텍처(예: CNN, 트랜스포머, FFNN, RNN 등)에 따라 다릅니다.
성능 추정 전략(A performance estimation strategy): 탐색 공간이 클 때, 아키텍처의 성능을 평가하기 위해 각 아키텍처 후보를 수렴할 때까지 학습시키는 것은 엄청나게 비용이 많이 들 수 있습니다. NAS 알고리즘이 결정을 내릴 수 있도록 저렴하게 성능을 추정하는 전략이 필요합니다.
탐색 전략(A search strategy): 탐색 공간을 탐색하는 전략입니다. 일반적인 접근 방식은 강화 학습(성능을 향상시키는 선택에 대해 알고리즘에 보상)과 진화 알고리즘(아키텍처에 돌연변이 추가 → 가장 성능이 좋은 것 선택 → 그것들에 돌연변이 추가)입니다.

학습된 옵티마이저 (Learned optimizers)

경사 하강법 기반 학습 작업은 그래디언트 업데이트가 주어졌을 때 모델의 가중치를 업데이트하는 방법을 지정하는 옵티마이저를 내부적으로(under the hood) 사용합니다. 인기 있는 옵티마이저로는 Adam, Momentum, SGD가 있습니다.

이러한 옵티마이저들은 함수와 일부 옵티마이저 하이퍼파라미터(학습률 등)의 형태를 띱니다. 함수 자체는 사람에 의해 정의되었습니다; 만약 그 함수를 NN으로 대체하고 하이퍼파라미터를 학습할 수 있다면 어떨까요?

이것이 바로 학습된 옵티마이저 연구 분야가 하려는 일입니다. 여러 학습 작업을 "학습 데이터"로 사용하여 NN을 메타-학습(meta-train)시켜, 여러 학습 작업과 여러 NN 아키텍처에 "바로(off-the-shelf)" 사용할 수 있는 일반화 가능한 신경망 기반 옵티마이저 함수를 만들려고 합니다.

이 작업을 수행하는 계산 비용은 막대합니다. 메타-학습 작업을 위한 단일 샘플은 <NIST 데이터셋, 5개 합성곱 레이어를 가진 CNN, 배치 크기 32, 10K 스텝>과 같을 수 있습니다.
일부 옵티마이저는 스스로를 더 학습시킬 수 있는 속성을 가지고 있습니다.
Google의 "더 효과적인 학습된 옵티마이저 학습시키기, 그리고 그것들을 사용하여 스스로를 학습시키기(Training more effective learned optimizers, and using them to train themselves)" 논문에 대한 이 비디오는 이 직관을 매우 잘 설명합니다. (직관 부분만 보려면 15분까지 시청하세요.)

모델 오프라인 평가

이 섹션에서는 배포할 최상의 모델을 선택하기 위해 모델을 평가하는 방법을 다룹니다. 이 섹션은 두 가지 주제를 다룹니다.

베이스라인: 비교할 대상이 필요합니다.
전반적인 ML 지표를 넘어서는 평가 방법.

참고:

ML 기반 지표 외에도, 비즈니스 팀과 협력하여 회사의 비즈니스와 더 관련 있는 지표를 개발할 수 있습니다.
이상적으로는 개발 환경과 프로덕션 환경에서의 평가 방법이 동일하기를 원합니다.
- 운이 좋다면, 프로덕션에서 자연 레이블을 사용하여 성능을 측정할 수 있을 것입니다.
- 프로덕션에서는 레이블에 접근할 수 없을 수도 있기 때문에 개발 환경과 프로덕션 환경의 평가를 일치시키는 것이 때때로 불가능합니다. 이러한 경우에는 프로덕션에서 광범위한 모니터링을 사용해야 합니다 (8장 참조).

베이스라인 (Baselines)

평가 지표 자체는 큰 의미가 없습니다. 비교 대상인 베이스라인을 아는 것이 필수적입니다. 사용하는 베이스라인은 유스케이스에 따라 달라집니다. 그러나 이 섹션에서는 일반적으로 사용되고 유스케이스 전반에 걸쳐 일반화될 수 있는 몇 가지를 다룹니다.

무작위 베이스라인 (Random baseline)

특정 무작위 분포를 따르는 예측을 생성하는 베이스라인 모델을 생성합니다. 균등 분포(uniform distribution)일 수도 있고, 작업의 레이블 분포를 따를 수도 있습니다.

간단한 휴리스틱 (Simple heuristic)

간단한 휴리스틱을 사용하여 예측하는 베이스라인 모델을 생성하고 그 성능을 측정합니다. 휴리스틱의 예로는: 가장 인기 있는 것 예측, 투표 수로 추천하기가 있습니다.

제로 룰 베이스라인 (Zero rule baseline)

항상 가장 흔한 클래스를 예측하는 베이스라인 모델. 만약 이 베이스라인이 70%의 정확도를 낸다면, 여러분의 모델은 추가된 복잡성을 정당화하기 위해 이보다 훨씬 더 나은 성능을 보여야 합니다.

인간 베이스라인 (Human baseline)

인간의 성능/정확도를 베이스라인으로 사용합니다. 모델이 인간에 비해 작업을 얼마나 더 잘/못 하는지 아는 것은 종종 유용합니다.

기존 솔루션 베이스라인 (Existing solution baseline)

if/else 문으로 가득 찬 알고리즘, 이전 모델 또는 벤더가 제공한 모델이 이미 있다면, 그것을 베이스라인으로 사용하십시오. 모델을 선택하기 위해 반드시 베이스라인보다 더 나은 성능을 낼 필요는 없습니다. 때때로 모델의 정확도가 약간 낮더라도 훨씬 저렴하다면, 추진할 가치가 있습니다.

전반적인 ML 지표를 넘어서는 평가 방법

사람들은 F1이나 정확도와 같은 전반적인 성능 지표에 집착하는 경향이 있습니다. 그러나 모델 평가 및 선택에는 전반적인 ML 지표보다 훨씬 더 많은 것이 있습니다. 프로덕션 모델의 경우, 모델이 견고하고(robust), 공정하며(fair), 보정(calibrated)되어 있고, 전반적으로 말이 되는지(makes sense) 확인해야 합니다.

섭동 테스트(perturbation tests)를 통한 견고성 평가

이상적으로는 프로덕션 데이터와 동일한 분포 및 노이즈 수준을 가진 데이터로 모델을 학습시켜야 합니다. 그러나 이것이 항상 가능한 것은 아닙니다.
노이즈가 있는 프로덕션 데이터와 분포 변화 때문에, 노이즈 없는 데이터에서 측정된 최고의 모델이 노이즈가 있는 프로덕션 데이터에 대해 반드시 최고의 모델은 아닙니다.
모델이 노이즈가 있는 데이터에 대해 얼마나 잘 작동할지 파악하려면, 테스트 세트의 샘플에 약간의 노이즈(섭동, perturbations)를 추가하고 그것이 모델 성능에 극적인 영향을 미치는지 확인하십시오.
모델이 노이즈에 더 민감할수록 유지 관리가 더 어려워지고 적대적 공격(adversarial attacks)에 더 취약해집니다.
모델이 노이즈에 너무 민감하다면, 학습 중에 이를 줄이는 방법에 대한 준지도 학습 및 데이터 증강 노트를 확인하십시오.

불변성 테스트(invariance tests)를 통한 공정성 평가

입력의 특정 변경 사항이 예측의 변경으로 이어져서는 안 됩니다. 예를 들어, 샘플의 인종이나 성별 변경이 누군가의 신용 가치(credit worthiness)에 영향을 미쳐서는 안 됩니다.
불변성 테스트 중에, ML 엔지니어는 테스트 샘플의 민감한 정보를 변경하고 예측이 바뀌는지 확인합니다.
이를 근본적으로 제거하는 데 도움이 되도록, 민감한 정보 피처를 모델 학습에서 완전히 제외해야 합니다.

방향성 기대 테스트(directional expectation tests)를 통한 건전성 확인

데이터의 특정 변경 사항은 예측 가능한 방식으로 예측을 변경해야 합니다. 예를 들어, 주택 면적이 증가하면 부동산의 예측 가치도 증가해야 합니다.
방향성 기대 테스트는 출력이 예상된 방식으로 변경되도록 해야 하는 피처를 변경하고 모델이 예상대로 작동하는지 평가합니다.
방향성 변경이 출력을 반대 방향으로 작동하게 만든다면, 모델이 잘못된 것을 학습하고 있을 수 있습니다.

보정(calibration) 평가

만약 모델이 100개의 이미지에 대해 "이것이 고양이일 확률 60%"라고 레이블을 붙인다면, 그 100개 이미지 중 60개는 실제로 고양이여야 합니다. 만약 그렇다면, 우리는 그 모델이 "잘 보정되었다(well calibrated)"고 말합니다. 반대로, 100개 중 90개의 이미지가 고양이로 판명된다면, 그 모델은 보정되지 않은(uncalibrated) 것입니다.
보정은 0에서 1 사이의 모델 출력을 확률로 자신 있게 다룰 수 있는 핵심입니다. 모델이 보정되면, 출력 확률이 실제 확률과 일치하므로, 기댓값과 같은 추가적인 확률 기반 계산을 자신 있게 수행할 수 있습니다.
보정은 또한 더 나은 모델 모듈성(modularity)을 가능하게 합니다. 모델 모듈성이란 한 모델의 출력을 다운스트림 모델의 피처로 사용하는 것입니다. 만약 업스트림 모델이 변경되었는데 그 모델이 보정되지 않았다면, 모든 다운스트림 모델을 재학습해야 할 수도 있습니다.
모델 보정은 종종 ML 엔지니어들에 의해 간과됩니다.
이 유튜브 비디오는 보정이 무엇인지 간단하고 직관적으로 설명합니다.
회귀 모델도 보정 테스트가 필요합니다.
모델 보정은 종종 모델 이후의 후처리(post-processing) 레이어로 수행됩니다. 이를 위한 몇 가지 리소스는 다음과 같습니다.
- sklearn.calibration.CalibratedClassifierCV의 Platt Scaling
- Temperature scaling을 이용한 신경망 보정
- Google의 보정에 관한 블로그 포스트

신뢰도 측정(confidence measurement)을 통한 건전성 확인

일부 유스케이스의 경우, 모델이 무언가에 대해 확신이 없다면 사용자가 신뢰를 잃을 수 있으므로 추천을 보여주지 않는 것이 나을 수 있습니다.
신뢰도 측정은 다음을 식별하려고 시도합니다.
- 유스케이스에 대한 확실성(certainty)을 어떻게 측정합니까?
- 예측에 대해 확신할 수 있는 임계값(threshold)은 얼마입니까?
- 임계값 미만의 예측으로 무엇을 합니까? (예: 폐기, 사람 개입(loop in humans), 사용자에게 추가 정보 요청)
신뢰도 측정은 샘플별로 이루어집니다. 이는 평균적인 측정이 아닙니다.

슬라이스 기반(slice-based) 평가 테스트를 통한 성능 및 공정성 평가

슬라이싱(Slicing)은 데이터를 중요한 슬라이스(하위 집합)로 분리하고 각 슬라이스에 대해 모델이 어떻게 수행되는지 평가하는 것을 의미합니다.

전역 집계(global aggregation) 지표에 초점을 맞추고 슬라이스 기반 성능을 무시하는 것은 문제가 있습니다.

어떤 문제의 경우, 모델이 모든 슬라이스에 대해 동일하게 작동해야 합니다. 만약 다르게 작동한다면 모델이 편향되고(biased) 불공정할(unfair) 수 있습니다.
- 예를 들어, 모델 A의 전체 정확도는 96%이지만, 여성 슬라이스를 남성 슬라이스와 별도로 평가할 때 정확도가 더 나쁘다는 것을 발견할 수 있습니다. 모델 B는 전체적으로 95%로 약간 성능이 낮지만 남성과 여성 슬라이스에 대해 동일한 정확도를 가집니다. 모델 B가 아마도 더 바람직할 것입니다.
- 동일하게 수행되어야 하는 다른 슬라이스에서 모델이 다르게 수행된다는 것을 발견하는 것은 전체 성능을 향상시킬 기회를 발견했음을 의미합니다.
어떤 문제의 경우, 특정 슬라이스에 대해 모델이 더 잘 수행되기를 기대합니다. 만약 슬라이스들이 동일하게 수행된다면, 그것은 문제입니다.
- 예를 들어, 이탈 예측(churn prediction)에서, 유료 고객 슬라이스가 무료(freemiam) 고객 슬라이스보다 더 중요합니다. 이 경우 유료 고객 슬라이스의 성능이 더 좋기를 기대할 것입니다.

중요한 슬라이스가 무엇인지 정의하는 것은 과학이라기보다는 예술에 가깝습니다. 몇 가지 일반적인 접근 방식은 다음과 같습니다.

휴리스틱 기반: 도메인 지식에 기반하여 데이터를 슬라이스합니다. (예: 성별, 모바일 vs 웹 트래픽, 인종별)
오류 분석(Error analysis): 잘못 분류된 예제들을 수동으로 검토하고 그들 사이의 패턴을 찾습니다. 특정 그룹이 지속적으로 잘못 분류된다면 슬라이스를 발견할 수 있습니다.
슬라이스 파인더(Slice finder): 슬라이스 찾기를 체계화하기 위한 일부 연구가 있었습니다. 보통 후보 슬라이스를 자동 생성한 다음 나쁜 후보를 가지치기(pruning)합니다. 예:
- Slice Finder: Automated Data Slicing for Model Validation
- Subgroup Discovery Algorithms: A Survey and Empirical Evaluation

중요한 슬라이스를 찾으면, 슬라이스 기반 평가 테스트를 수행할 수 있도록 각 슬라이스에 대해 충분하고 정확하게 레이블이 지정된 데이터가 필요합니다.

7 - 모델 배포 및 예측 서비스

이제 ML 모델이 선택, 학습, 평가되었으므로 프로덕션에 배포할 차례입니다. 이 책의 다른 모든 단계와 마찬가지로, 이것은 반복적인 과정이며 이전 단계로 돌아가 일부를 다시 생각해야 할 수도 있습니다. 특히 이 단계에서는 모델이 예측을 서빙하고 계산하는 방식이 모델 설계 방식, 필요한 인프라, 그리고 사용자가 경험하는 동작에 영향을 미치기 때문에 이러한 반복적 특성이 특히 적용됩니다.

이 장에서는 다음 내용을 다룹니다.

ML 프로덕션 배포에 관한 몇 가지 일반적인 오해.
4가지 주요 예측 서빙 모드 설명: 1. 배치 예측, 2. 배치 피처만 사용하는 온라인 예측, 3. 배치 피처와 스트리밍 피처를 모두 사용하는 온라인 예측 (일명 스트리밍 예측), 4. 1과 2의 하이브리드.
배치 예측 VS 온라인 예측을 언제 사용해야 하는지에 대한 직관 제공.
배치 학습 데이터 파이프라인과 스트리밍 예측 파이프라인을 통합할 때의 과제.
ML 모델의 추론 속도를 높이기 위한 모델 압축(model compression) 기술.
모델을 클라우드 VS 엣지에 배포할 때의 고려 사항.

시작하기 전 몇 가지 입문 참고 사항:

프로덕션(Production)은 팀마다 매우 다른 것을 의미합니다. 어떤 팀에게 "프로덕션"은 일부 데이터 분석을 수행하기 위해 노트북에서 모델을 사용하는 것입니다. 다른 팀에게 "프로덕션"은 하루에 수백만 명의 사용자를 위한 예측을 생성하기 위해 모델을 계속 실행하는 것입니다. 이 장은 후자에 더 가까운 유스케이스에 초점을 맞춥니다.
"모델을 프로덕션에 배포하는 것"의 어려운 부분 중 일부는 다음과 같습니다.
- 밀리초(millisecond) 수준의 지연 시간과 99%의 가동 시간(uptime)으로 많은 수의 사용자에게 모델을 사용 가능하게 만들기.
- 프로덕션에서 모델이 실패하는 시점을 인지하고 적절한 사람에게 자동으로 알리기.
- 프로덕션 버그를 수정하기 위해 원활하게(seamlessly) 업데이트를 배포하기.
어떤 회사에서는 모델을 만드는 엔지니어가 배포하고 운영하는 엔지니어와 동일합니다. 다른 회사에서는 모델을 만드는 엔지니어가 모델을 내보내고(export) 배포를 위해 다른 팀에 전달합니다.
- Chip(저자)은 첫 번째 방식 (당신이 만들었으면, 당신이 배포한다)이 더 낫다고 믿습니다.
프로덕션에 배포하려면 "모델 내보내기" (일명 직렬화(serialization))가 필요합니다. 모델에는 내보낼 수 있는 두 가지 부분, 즉 모델 정의(model definition)와 모델 파라미터(model parameters)가 있습니다. 일반적으로 두 아티팩트(artifacts)는 함께 내보내집니다.
- TF 및 PyTorch의 내보내기 함수 예: tf.keras.Model.save 및 torch.onnx.export()

ML 배포에 관한 오해

오해 1: 한 번에 하나 또는 두 개의 ML 모델만 배포한다

이는 사실이 아닙니다. 중대형 기업은 프로덕션 환경에서 동시에(concurrently) 아주 많은 ML 모델을 실행합니다. 애플리케이션 기능당 적어도 하나의 모델을 찾는 것이 일반적입니다. 예: 승차 수요 예측, 드라이버 가용성 예측, 도착 시간 추정, 동적 가격 책정 등.

오해 2: 아무것도 하지 않으면 모델 성능은 동일하게 유지된다

소프트웨어 시스템처럼 ML 시스템도 "소프트웨어 노후화(software rot)"를 겪습니다. 또한, ML 시스템은 시간이 지남에 따라 데이터 분포 변화를 겪으며, 이러한 변화는 성능을 저해할 것입니다. 이것이 ML 모델이 학습 직후에 가장 좋은 성능을 내는 경향이 있는 이유입니다.

오해 3: 모델을 그렇게 자주 업데이트할 필요는 없다

위에서 언급한 성능 저하(performance decay)와 관련하여, 우리는 가능한 한 자주 모델을 업데이트하기를 원합니다. "한 달에 한 번" 또는 "분기에 한 번"의 주기가 일반적입니다. 그러나 필요한 경우 X분마다 업데이트를 수행할 수 있는 회사도 있습니다.

오해 4: 대부분의 ML 엔지니어는 규모(Scale)에 대해 걱정할 필요가 없다

이는 사실이 아닙니다. 대부분의 ML 엔지니어는 중대형 규모의 회사에 고용되어 있습니다. 이 정도 규모의 회사가 초당 수백 건의 추론을 생성하거나 수백만 명의 사용자를 처리해야 하는 모델을 보유하는 것은 상당히 일반적입니다.

예측 서빙의 네 가지 모드

참고: 이 주제에 대한 용어는 커뮤니티 내에서 여전히 모호합니다(murky). 유사한 개념을 지칭하는 다른 용어를 찾을 수도 있습니다.

프로덕션에서 예측을 서빙하는 세 가지 주요 모드와 하나의 하이브리드 모드가 있습니다.

배치 예측(Batch prediction): 배치 피처만 사용하며, 예약되거나 트리거되는 작업을 실행하여 예측을 대량 생산하고 데이터베이스에 저장합니다. 추론 시점에는 DB에서 예측을 조회(looked up)합니다.
1. 장점:
  1. 미리 계산된 예측은 매우 빠르게 검색되어 사용자에게 제공될 수 있습니다.
  2. GPU 벡터화(vectorisation)를 활용하기 위해 여러 추론을 일괄 처리(batching up)하는 것이 자연스러운 단계입니다. 추론 배칭은 높은 예측 처리량(throughput)으로 이어집니다.
  3. 추론이 필요한 데이터를 분할하여 여러 병렬 노드로 전송함으로써 예측 처리량을 더욱 높일 수 있습니다.
2. 단점:
  1. 해당 예측을 사용할 만큼 자주 앱을 사용하지 않는 사용자를 위해 예측을 생성할 수 있습니다.
  2. 예측에 포함하기 위해 "방금" 사용 가능해진 데이터를 고려할 수 없습니다. 예측은 마지막 피처 계산 작업이 실행되었을 때의 세상 상태를 반영합니다.
3. 사용 시기:
  1. 예측의 빠른 검색이 필요하고 최신이 아닐 수도 있는 피처를 사용해도 괜찮을 때. 즉, "배치 피처만 사용하는 온라인 예측 (모드 2)"이 충분히 빠르지 않거나 저렴하지 않을 때입니다. 이 모드가 실행 가능하려면 모든 쿼리(예: 모든 사용자)에 대한 예측을 계산하고 저장하는 것이 수용 가능해야 합니다.
  2. 이 모드의 또 다른 유스케이스는 모집단에 대한 전반적인 집계 통계를 파악하기 위해 모든 가능한 쿼리에 대한 예측이 필요할 때입니다. 예를 들어, 다음 달에 이탈할 가능성이 있는 상위 10%의 고객에게 연락하고 싶을 때입니다.
배치 피처만 사용하는 온라인 예측(Online prediction that uses only batch features): 추론 계산 자체는 즉석에서(on the fly) 그리고 요청 시(on demand) 수행되지만, 필요한 모든 피처는 미리 계산되었으며 스트리밍 피처의 실시간 계산이 필요하지 않습니다.
1. 장점:
  1. 실제로 예측이 필요한 사용자를 위해서만 예측을 생성합니다.
2. 단점:
  1. 피처에 "방금" 사용 가능해진 데이터를 고려할 수 없습니다.
  2. 추론 시 GPU 벡터화를 사용하기 위해 추론 요청을 일괄 처리하는 것은 배칭을 위한 시간 윈도우(time windows)를 처리해야 하므로 약간 더 어렵습니다.
  3. 예측이 사용자에게 제공되기까지 더 느릴 것입니다.
3. 사용 시기: 전체 고객 기반에 대한 예측을 얻는 컴퓨팅 노력을 낭비할 여유가 없고 검색 속도를 희생할 의향이 있을 때. 또한 미리 계산된 피처를 사용해도 괜찮아야 합니다.
배치 피처와 스트리밍 피처를 모두 사용하는 온라인 예측 (일명 스트리밍 예측): 추론 계산은 즉석에서 그리고 요청 시 수행됩니다. 모델을 위한 일부 피처는 미리 계산되지만 일부는 "최신(fresh)"이어야 하므로 스트리밍 피처를 사용하여 즉석에서 계산되어야 합니다. 이 모드가 작동하려면 시스템에 거의 실시간(near real-time) 전송 및 데이터 스트림 계산이 필요합니다. 아래 다이어그램 참조.
1. 장점:
  1. 실제로 예측이 필요한 사용자를 위해서만 예측을 생성합니다.
  2. 피처 계산을 위해 "방금" 사용 가능해진 데이터를 고려할 수 있습니다.
2. 단점:
  1. 추론 시 GPU 벡터화를 사용하기 위해 추론 요청을 일괄 처리하는 것은 배칭을 위한 시간 윈도우를 처리해야 하므로 약간 더 어렵습니다.
  2. 스트리밍 피처가 계산된 다음 추론될 때까지 기다려야 하므로, 예측은 "배치 피처만 사용하는 온라인 예측"보다 훨씬 더 느릴 것입니다.
3. 사용 시기: 방금 생성된 데이터를 예측에 반영하는 것이 매우 중요할 때. 거래 및 로그인 사기 탐지가 일반적인 예입니다.
모드 1과 2의 하이브리드 (배치 및 배치 피처를 사용한 온라인): 인기 있는 쿼리(예: 자주 로그인하는 사용자)에 대해서는 예측을 미리 계산하고, 덜 인기 있는 쿼리에 대해서는 모드 2를 사용하여 온라인 예측을 생성합니다.
1. 장점:
  1. 빈번하지 않은 쿼리에 대한 추론을 계산하고 저장하는 자원 낭비 문제가 해결됩니다.
2. 단점:
  1. "빈번한 쿼리"가 무엇을 의미하는지 파악해야 합니다.
  2. 배치 시스템과 온라인 시스템을 모두 처리해야 하므로 복잡성이 증가합니다.
  3. 이 모드는 여전히 피처에 "방금" 사용 가능해진 데이터를 고려할 수 없습니다.
3. 사용 시기: 일반적인 쿼리(모드 1처럼)에 대해 매우 빠른 예측 검색을 제공해야 하지만, 모든 쿼리에 대한 예측을 미리 계산할 여유가 없을 때. 더 빠른 예측 검색의 이점이 증가된 복잡성보다 커야 합니다.

"온라인 예측"과 "배치 예측"이라는 용어는 혼란스러울 수 있습니다. 이 문맥에서 이 용어들은 예측이 언제 이루어지는지를 나타냅니다. 두 방식 모두 GPU 벡터화 최적화를 활용하기 위해 여러 샘플에 대한 예측을 동시에 수행(즉, 추론 요청을 배치로 그룹화)할 수 있습니다. 또한 두 방식 모두 한 번에 하나의 샘플을 처리할 수도 있습니다.

스트리밍 예측 → 배치 학습 파이프라인과 스트리밍 서빙 파이프라인 통합하기

이 섹션은 주로 서빙 모드 3: "배치 피처와 스트리밍 피처를 모두 사용하는 온라인 예측"과 관련이 있습니다.

학습용 피처를 구축하는 데 사용되는 배치 데이터 파이프라인과, 추론 시점에 즉석에서 피처를 계산하기 위한 별도의 데이터 파이프라인을 가진 회사를 찾는 것은 드문 일이 아닙니다.

두 개의 서로 다른 파이프라인을 갖는 것은 한 파이프라인의 변경 사항이 다른 파이프라인에 전파되지 않아 피처 드리프트(feature drift)를 유발하기 때문에 ML에서 버그의 일반적인 원인이 됩니다.

배치 파이프라인과 스트리밍 파이프라인을 통합하기 위한 인프라 구축은 매우 인기 있는 주제가 되었습니다. 기업들은 일반적으로 피처 스토어(feature stores)를 사용하거나 Apache Flink와 같은 스트림 컴퓨팅 기술을 기반으로 자체 개발(in-house) 도구를 구축하여 문제를 해결하려고 합니다.

모델 압축을 통한 더 빠른 추론

필요한 경우 추론 지연 시간을 줄일 수 있는 3가지 방법이 있습니다.

모델 압축(Model compression): 모델을 더 작게 만듭니다. 이 섹션의 초점입니다.
추론 최적화(Inference Optimization): 추론 지연 시간을 줄이기 위해 계산 및 컴파일 파라미터를 조정합니다. 이에 대한 자세한 내용은 아래의 "모델 최적화" 섹션에서 다룹니다.
더 빠른 하드웨어(Faster hardware): 더 좋은 하드웨어를 구매하거나 가지고 있는 하드웨어를 더 빠르게 실행시킵니다.

원래 모델 압축은 모델을 더 작게 만들어 엣지 디바이스(edge devices)에 탑재할 수 있도록 돕기 위해 개발되었습니다. 그러나 모델을 더 작게 만들면 일반적으로 더 빨리 실행되므로, 이제 압축은 엣지가 아닌 시나리오에서도 추론 속도를 높이는 데 사용되고 있습니다.

압축은 또한 공정성(fairness) 영역에도 파급 효과(ripple effects)를 미친다는 점에 유의하십시오. 자세한 정보는 11장을 참조하십시오.

모델 압축에는 4가지 일반적인 기술이 있습니다.

저계수 분해 (Low-rank factorization)
지식 증류 (Knowledge distillation)
가지치기 (Pruning)
양자화 (Quantization)

저계수 분해 (Low-rank factorization)

직관: 고차원 텐서(tensor)를 더 낮은 차원의 텐서로 대체합니다.
예: CNN을 위한 컴팩트 컨볼루셔널 필터(compact convolutional filters).
단점: 저계수 방법은 특정 유형의 모델에 한정되는 경향이 있으며 기본 아키텍처에 대한 깊은 이해를 필요로 합니다. 이 때문에 아직 광범위한 유스케이스에서 사용되지 않고 있습니다.

지식 증류 (Knowledge Distillation)

직관: 작은 모델(학생)이 더 큰 모델 또는 모델 앙상블(교사)을 모방하도록 학습됩니다. 배포하는 것은 이 더 작은 모델입니다.
예: DistilBERT(학생)는 BERT 모델(교사)의 크기를 40% 줄이면서 언어 이해 능력의 97%를 유지하고 60% 더 빠릅니다.
장점: 교사와 학생 간의 아키텍처 차이에 관계없이 작동합니다. 예를 들어, 랜덤 포레스트 학생과 트랜스포머 NN 교사를 가질 수 있습니다.
단점: 사용 가능한 교사 모델이 있어야 합니다.

가지치기 (Pruning)

직관: 결정 트리의 가지치기(불필요하거나 중복되는 트리 가지 제거)에서 영감을 받았습니다. 신경망의 맥락에서, 가지치기는 2가지 형태를 띱니다.
- 전체 노드(node)를 제거하여 파라미터 수를 줄입니다. 이 형태는 덜 일반적입니다.
- 더 일반적인 방법: 예측에 거의 기여하지 않는 파라미터를 찾아 0으로 설정합니다. 아키텍처는 동일하게 유지되지만 0이 아닌 파라미터의 수를 극적으로 줄일 수 있습니다. 희소(Sparse) 모델은 더 적은 저장 공간을 필요로 하고 더 높은 계산 성능을 갖는 경향이 있습니다. 실험에 따르면 전체 정확도를 유지하면서 크기를 최대 90%까지 줄일 수 있습니다.
장점: NN의 아키텍처에 관계없이 작동합니다.
단점: 가지치기는 모델에 편향(bias)을 도입할 수 있습니다. 자세한 내용은 11장에서 다룹니다.
- #todo : 올바른 섹션 링크하기
참고: 가지치기는 또한 어떤 노드가 중요한지 결정하고, 모델을 재설계(re-architecting)하며, 재학습하는 아키텍처 탐색 도구로도 사용되어 왔습니다. 그러나 일부 연구에서는 크고 희소한 모델이 재설계되고 재학습된 모델보다 성능이 우수함을 보여주었습니다.

양자화 (Quantization)

직관: 파라미터를 저장하기 위해 32비트 정밀도 부동 소수점(floats)을 사용하는 대신, 더 적은 비트를 사용합니다.
- 파라미터당 비트 수가 적다는 것은 모델의 메모리 점유 공간(footprint)이 더 작아짐을 의미합니다.
- 메모리가 적다는 것은 (학습 중 양자화를 사용한다면) 원할 경우 더 큰 모델을 학습시킬 수 있음을 의미합니다.
- 메모리가 적다는 것은 또한 배치 크기를 늘려 학습 계산 속도를 높일 수 있음(학습 중 양자화를 사용한다면)을 의미합니다.
- 부동 소수점의 정밀도가 낮다는 것은 원하는 정밀도를 달성하는 데 필요한 계산이 적다는 것을 의미하며, 이는 학습과 추론 속도를 모두 높여줍니다.
유형:
- 목표 정밀도별 유형:
  - 16비트 (일명 "저정밀도(low-precision)")
  - 8비트 (일명 정수 양자화(integer quantization) 또는 "고정 소수점(fixed-point)")
    - 고정 소수점 추론은 엣지에서의 추론을 위한 업계 표준이 되었습니다.
    - Google의 TensorFlow Lite, Facebook의 PyTorch Mobile, NVIDIA의 TensorRT는 모두 몇 줄의 코드로 학습 후 고정 소수점(post-training fixed-point) 양자화를 제공합니다.
  - 1비트 (일명 이진 가중치 네트워크(binary weight networks))
- 양자화 적용 시점별 유형:
  - 학습 중 양자화(Quantization during training): 처음부터 저정밀도로 학습합니다.
  - 학습 후 양자화(Quantization post-training): 완전 정밀도(full precision)로 학습한 다음, 추론을 위해서만 학습된 모델을 양자화합니다.
장점:
- 모든 형태의 양자화는 기존 라이브러리를 사용하여 수행하기 간단하며 여러 모델 유형에 잘 일반화됩니다.
- 저정밀도 학습은 매우 인기를 얻었으며 학습 하드웨어(예: NVIDIA GPU 및 Google TPU)가 이에 대한 직접적인 하드웨어 지원을 제공하기 시작했습니다.
- 2022년 기준 고정 소수점 학습은 아직 매우 대중적이진 않지만 유망한 결과를 보여주었습니다.
단점:
- 정밀도가 낮다는 것은 표현될 수 있는 숫자가 적다는 것을 의미합니다. 이는 정밀도 반올림 오류(precision rounding errors) 및 숫자 경계 오버플로우(number boundary overflow)의 위험을 도입합니다. 작은 반올림 오류가 성능의 극적인 변화로 이어질 수 있습니다.
  - 효율적인 반올림 및 스케일링은 간단하지 않습니다(non-trivial). 하지만 다행히도 주요 프레임워크에는 이것이 내장되어 있습니다.

더 많은 압축 리소스

“The Top 168 Model Compression Open Source Projects”
“Survey of Model Compression and Acceleration for Deep Neural Networks" Cheng et al, 2020.

클라우드와 엣지의 ML

추론 계산의 주요 부분을 어디에서 수행할지 결정해야 합니다. 계산은 클라우드 또는 엣지에서 일어날 수 있습니다.

클라우드 (The cloud)

장점

모델을 배포하는 가장 쉬운 방법입니다. 모델과 모델이 실행되는 하드웨어의 호환성에 대해 거의 걱정할 필요가 없습니다.

단점

ML 추론 클라우드 비용은 상당할 수 있습니다. 중소기업의 비용은 연간 5만 달러에서 2백만 달러 사이가 될 수 있습니다. 엣지로 더 많은 계산을 옮길수록, 비용을 더 적게 지불합니다.
클라우드는 추론에 네트워크 지연 시간(network latency)을 도입합니다. 많은 경우 네트워크 지연 시간은 추론 지연 시간보다 더 큰 병목 현상이 될 수 있습니다.
해당 기능은 고객의 인터넷 접속에 의존하게 됩니다.

엣지 (The edge)

브라우저, 휴대폰, 노트북, 스마트워치, 자동차, 보안 카메라, 로봇, 임베디드 디바이스, FPGA(필드 프로그래머블 게이트 어레이), ASIC(주문형 반도체).

그 인기로 인해, 기업들은 다양한 ML 유스케이스에 최적화된 엣지 디바이스를 개발하기 위해 경쟁하고 있습니다. Google, Apple, Tesla를 포함한 기존 기업들은 모두 자체 ML 최적화 칩을 만들 계획을 발표했습니다.

장점

인터넷 없이 작동합니다.
유스케이스에 엄격한 "인터넷 사용 불가" 정책이 있는 경우 유일한 방법일 수 있습니다.
네트워크 지연 시간이 없기 때문에 전반적인 지연 시간이 줄어들 수 있습니다.
민감한 데이터를 다루고 있어 네트워크로 전송하고 싶지 않은 경우(예: 지문, FaceID) 유용합니다.
엣지 계산은 GDPR과 같은 개인정보 보호 규정을 준수하기 더 쉽게 만듭니다.

단점

모델이 대상 하드웨어에서 실행되도록 호환되지 않거나 효율적으로 실행되지 않을 수 있습니다.
- 하드웨어 제조업체와 프레임워크 제작자는 새로운 하드웨어 또는 기존 하드웨어의 새로운 프레임워크에 대한 지원을 추가하는 데 일반적으로 오랜 시간이 걸립니다. 이는 매우 어려운 작업이기 때문입니다.
모델을 다른 대상 하드웨어에서 실행되도록 컴파일(compilation)하는 것은 많은 수동 노력이 필요한 어렵고 시간이 많이 걸리는 작업입니다.
다양한 하드웨어 아키텍처에 맞게 모델을 최적화하는 것은 매우 어렵습니다. 응용 ML 엔지니어라면 일반적으로 이 작업을 수행할 필요가 없습니다. 이는 보통 ML 프레임워크 개발자가 수행합니다. 연구자라면 이 작업을 수행해야 할 수도 있습니다.
엣지 디바이스는 모델을 실행할 수 있을 만큼 충분히 강력하고, 충분한 메모리와 배터리를 갖추고 있어야 합니다. 이 모든 것이 솔루션에 제어하기 어려운 변수를 추가합니다.

엣지 디바이스를 위한 모델 컴파일 및 최적화

컴파일은 ML 모델을 대상 하드웨어에서 실행될 수 있는 아티팩트로 변환하는 과정입니다. 최적화는 대상 하드웨어의 속성을 활용하여 모델이나 아티팩트를 조정하고 더 빨리 실행되도록 만드는 과정입니다.

컴파일

응용 ML 엔지니어로서, 여러분은 일반적으로 이미 생성된 모델 컴파일러를 사용할 것입니다.

일부 컴파일러는 중간 표현(Intermediate Representations, IRs)이라는 개념에 의존합니다. IR은 프레임워크 제작자와 하드웨어 제조업체가 컴파일러 생성을 용이하게 하고 하드웨어 지원 문제를 완화하기 위해 모두 채택한 표준화된 중간 형식입니다.

최적화

모델이 대상 아키텍처에서 실행된다는 사실이 효율적으로 그렇게 할 수 있음을 의미하지는 않습니다.

응용 ML 엔지니어로서, 여러분은 일반적으로 컴파일러 또는 하드웨어 최적화에 의존할 것이며, 하드웨어 작업을 직접 최적화하지는 않을 것입니다.

ML 프레임워크 개발자와 하드웨어 제조업체는 ML과 하드웨어 아키텍처 모두에 대해 아는 전문 최적화 엔지니어를 고용하는 데 막대한 돈을 씁니다.

최적화 엔지니어가 아니더라도 코드를 최적화할 수는 있다는 점에 유의하십시오.

수동 모델 최적화

최적화 엔지니어는 모델을 더 빨리 실행시킬 방법을 찾기 위해 휴리스틱(heuristics)을 사용합니다. 수동으로 만든 휴리스틱은 최적이 아니며 기본 ML 프레임워크나 하드웨어 아키텍처가 변경될 때 유연하지 못하다는 문제가 있습니다.

모델 최적화에 ML 사용

휴리스틱에 의존하는 대신 ML을 사용하여 최적의 연산 순서 탐색을 좁힙니다. 이는 최적에 더 가깝고 ML 프레임워크 및 하드웨어 변경에 유연하게 적응할 수 있다는 장점이 있습니다.

ML 기반 컴파일러의 결과는 인상적입니다. 응용 ML 엔지니어로서 여러분은 하나의 하드웨어 백엔드에 대해 모델을 한 번 최적화한 다음, 동일한 하드웨어 유형의 여러 디바이스에서 실행합니다. ML 기반 옵티마이저는 실행하는 데 몇 시간, 때로는 며칠이 걸릴 수 있다는 점을 고려하십시오.

브라우저에서의 ML

원칙적으로, 모델을 브라우저에서 효율적으로 실행할 수 있게 한다면, 더 이상 대상 하드웨어, 컴파일, 최적화에 대해 걱정할 필요가 없습니다.

사람들은 보통 브라우저에 대해 이야기할 때 자바스크립트(Javascript)를 생각합니다. 모델을 자바스크립트 브라우저 실행 가능 아티팩트로 변환하는 라이브러리가 있습니다. 그러나 JS는 근본적으로 ML에 적합하지 않으므로 사용을 권장하지 않습니다.

유망한 대안은 WebAssembly(WASM)로 컴파일되는 모델입니다. WASM은 JS보다 훨씬 빠르며 2021년 기준 브라우저의 93%가 이를 지원했습니다.

WASM은 iOS 또는 Android 앱을 통해 네이티브 하드웨어에서 모델을 실행하는 것에 비하면 여전히 느립니다.

8 - 프로덕션 환경에서의 데이터 분포 변화와 모니터링

모델을 프로덕션에 배포하는 것이 이야기의 끝이 아닙니다. 프로덕션 환경의 모델은 시간이 지남에 따라 모든 모델이 겪는 자연스러운 성능 저하를 감지하기 위해 지속적으로 모니터링되어야 합니다.

이 장에서는 다음 내용을 다룹니다.

ML 모델이 실패하는 두 가지 다른 방식: 소프트웨어 시스템 실패 VS ML 고유의 실패.
그런 다음 이 장에서는 특히 까다로운 ML 고유의 실패인 데이터 분포 변화(data distribution shifts)에 대해 심층적으로 다룹니다. 데이터 분포 변화의 유형과 이를 감지하고 해결하는 방법을 다룹니다.
이 장은 모니터링과 관측 가능성(monitoring and observability)으로 마무리됩니다.
- 모든 소프트웨어 시스템이 가져야 할 운영 지표 (예: 지연 시간, CPU 사용률)
- ML 고유의 지표

다음 장에서는 문제가 감지되었을 때 모델을 수정하는 방법을 다룹니다.

ML 시스템 실패의 원인

ML 시스템은 크게 두 가지 방식, 즉 소프트웨어 시스템으로서의 실패와 ML 고유의 실패로 오작동할 수 있습니다.

소프트웨어 시스템 실패

ML 시스템 역시 소프트웨어 분산 시스템이므로 모든 소프트웨어 실패 모드가 적용됩니다. 몇 가지 일반적인 예는 다음과 같습니다.

의존성 실패(Dependency failure): 의존하는 구성 요소가 손상되거나 중단되고 그 결과로 프로그램이 오작동합니다.
배포 실패(Deployment failure): 예를 들어, 잘못된 버전의 ML 아티팩트(artefact)를 배포하거나 ML 모델을 둘러싼 코드에 버그를 배포하는 경우입니다.
하드웨어 실패(Hardware failure): 모델을 실행하는 인프라가 실패하고 시스템도 함께 실패합니다.

Google은 지난 15년간의 ML 시스템 실패에 대한 내부 설문 조사를 수행했으며, 96건 중 60건이 ML 고유의 실패가 아닌 소프트웨어 실패임을 발견했습니다. 더욱이, 60건 중 대부분은 분산 시스템 실패 모드와 관련된 실패임을 발견했습니다.

2022년 현재, ML 시스템의 소프트웨어 시스템 실패는 여전히 매우 만연합니다. 왜냐하면 이러한 시스템을 관리하기 위한 관행, 표준 및 도구가 전통적인 소프트웨어에 비해 아직 초기 단계이기 때문입니다. 이 분야가 성숙해짐에 따라 시간이 지남에 따라 이것이 줄어들 것으로 예상할 수 있습니다.

추가 자료:

이 주제에 대해 더 알고 싶다면 Chip(저자)은 "Reliable Machine Learning" by Todd Underwood를 추천합니다.

ML 고유의 실패

예는 다음과 같습니다.

데이터 수집 및 처리 문제
잘못된 하이퍼파라미터
학습 / 추론 파이프라인 간의 변경 사항이 다른 쪽에 복제되지 않음
데이터 분포 변화 (아래에서 자세히 다룸)
엣지 케이스 (Edge cases)
퇴행성 피드백 루프 (Degenerate feedback loops)

이 섹션에서는 이 중 두 가지를 다루고, 다음 섹션에서는 데이터 분포 변화에만 집중할 것입니다.

극단적인 데이터 샘플 엣지 케이스

엣지 케이스는 너무 극단적이어서 모델이 치명적인 실수를 하도록 만드는 데이터 샘플입니다.

일부 애플리케이션에서는, 잘못된 예측의 결과가 치명적일 경우 엣지 케이스가 모델 배포 자체를 막을 수 있습니다. 일반적인 예는 자율 주행 자동차입니다.

엣지 케이스와 이상치(outliers)는 관련이 있지만 서로 다른 것입니다. 이상치는 극단적인 데이터 샘플이지만 모델이 (어느 정도) 처리할 수 있는 것입니다.

학습 중에 이상치를 제외하는 것과 엣지 케이스에 대한 모델 견고성(robustness) 사이에는 트레이드오프(trade-off)가 있습니다. 이상치는 일반적으로 모델이 결정 경계(decision boundaries)를 더 잘 학습하도록 돕기 위해 학습 중에 제거됩니다. 그러나 이상치를 제거하면 추론 시점에 (이상치를 제거할 수 없는) 극단적인 데이터 샘플을 만났을 때 예상치 못한 결과를 초래할 수도 있습니다.

퇴행성 피드백 루프 (Degenerate feedback loops)

퇴행성 피드백 루프는 예측 자체(예: 추천된 노래)가 피드백(예: 선택된 노래)에 영향을 미치고, 이것이 다시 모델의 다음 이터레이션(iteration)에 영향을 미칠 때 발생할 수 있습니다.

예를 들어, "Acme Inc에서 근무함"이라는 피처가 성과의 좋은 예측 변수임을 학습한 이력서 스크리닝 모델이 프로덕션 환경에서 실행 중이라고 상상해 보십시오. 이 모델은 다른 어떤 회사보다 Acme Inc 출신 이력서를 리크루터에게 불균형적으로 많이 노출시키고, 따라서 다른 어떤 회사보다 Acme Inc 출신 사람들이 더 많이 고용됩니다. 이는 모델의 향후 이터레이션이 "Acme Inc에서 근무함" 피처에 훨씬 더 많은 가중치를 부여하게 만들 것입니다. 이를 제어하지 않고 방치하면, 모델은 스스로 편향될 것이고 실제 비즈니스 성과는 저하될 것입니다.

퇴행성 피드백 루프는 모델이 프로덕션 환경에 있고 사용자가 이와 상호작용할 때만 발생합니다. 퇴행성 피드백 루프는 추천 시스템 및 광고 클릭률 예측과 같이 사용자로부터의 자연스러운 레이블(natural labels)이 있는 작업에서 특히 일반적입니다.

이것은 많이 연구되는 분야입니다. “노출 편향(exposure bias)”, “인기 편향(popularity bias)”, “필터 버블(filter bubbles)”, 때로는 “반향실 효과(echo chambers)”와 같은 이름으로 찾을 수 있습니다.

퇴행성 피드백 루프 탐지

모델이 퇴행성 피드백 루프를 겪고 있는지 탐지하려면 모델 출력의 다양성(diversity)을 측정합니다. 다양성과 관련된 여러 지표가 있습니다.

총 다양성(Aggregate diversity) 및 롱테일(long-tail) 아이템의 평균 커버리지
- Brynjolfsson et al. (2011), Fleder and Hosanagar (2009), and Abdollahpouri et al. (2019)
인기 대비 적중률(Hit rate against popularity): 다양한 인기 버킷(popularity buckets)에 대한 시스템의 예측 정확도를 측정합니다. 만약 추천 시스템이 덜 인기 있는 아이템을 추천하는 것보다 인기 있는 아이템을 추천하는 데 훨씬 더 능숙하다면, 이는 인기 편향을 겪고 있을 가능성이 높습니다.
- Chiea et al. (2021)
(5장에서 설명한) 피처 중요도 연구를 수행하면 모델이 특정 피처에 점점 더 많은 가중치를 부여함으로써 스스로 편향되고 있는지 시간 경과에 따라 탐지하는 데 도움이 될 수 있습니다.

퇴행성 피드백 루프 수정

방법 1: 무작위화(randomization) 사용

모델 출력에 무작위화를 도입하여 동질성(homogeneity)을 줄입니다. 예를 들어, 사용자에게 모델이 추천하는 아이템만 보여주는 대신, 무작위 아이템도 함께 보여주고 그들의 피드백을 사용하여 아이템의 진정한 품질을 결정합니다.

TikTok이 이 접근 방식을 따릅니다. 각 새로운 비디오는 무작위로 초기 트래픽 풀(pool)에 할당됩니다. 이 트래픽은 해당 비디오가 더 큰 트래픽 풀을 받아야 할지 또는 관련 없음으로 표시되어야 할지 결정하기 위해 비디오의 편향되지 않은 품질을 평가하는 데 사용됩니다.

무작위화는 사용자 경험을 희생시키면서 다양성을 향상시킵니다. 더 정교한 전략은 컨텍스추얼 밴딧(contextual bandits)을 사용하여 언제 탐색(explore)할지 대 언제 활용(exploit)할지 결정하고 예측 가능한 정확도 손실 내에서 다양성을 증가시키는 것입니다.

방법 2: 위치 피처(positional features) 사용

예측의 위치가 클릭될 가능성에 영향을 미친다면, 위치 피처를 사용하여 모델에게 위치의 영향을 가르칠 수 있습니다.

위치 피처는 5장에서 설명한 "위치 임베딩(positional embeddings)"과는 다릅니다.

위치 피처는 숫자형 (1, 2, 3, ...)이거나 불리언(boolean) (예: 이 아이템이 첫 번째 예측이었는가?)일 수 있습니다.

이해를 돕기 위한 간단한 예:

아래와 같이 학습 데이터에 불리언 위치 피처를 추가합니다.
추론 시, 노래가 1번째 위치에 추천되었는지 여부에 관계없이 사용자가 노래를 클릭할지 예측하고 싶습니다. 이를 위해 모든 후보에 대해 1st-position 피처를 false로 설정합니다.

이 간단한 예는 퇴행성 피드백 루프와 싸우기에 충분하지 않을 수 있습니다. 더 정교한 다중 모델 시스템이 사용될 수 있지만 기본 아이디어는 동일합니다.

방법 3: 컨텍스추얼 밴딧(Contextual bandits) 사용

밴딧과 컨텍스추얼 밴딧에 대한 자세한 내용은 9장에서 읽어보십시오.

데이터 분포 변화 (Data Distribution Shifts)

이것은 ML 고유의 실패 유형 중 하나로, 감지하고 조치하기가 매우 어렵기 때문에 별도의 섹션으로 다룰 가치가 있습니다.

몇 가지 용어:

소스 분포(Source distribution): 학습 데이터의 분포
타겟 분포(Target distribution): 프로덕션 환경의 추론 데이터 분포

데이터 분포 변화는 소스 분포와 타겟 분포 간의 차이를 의미합니다.

중요: 데이터 분포 변화는 모델의 성능 저하를 유발할 때만 문제가 됩니다. 변화가 있다는 사실이 반드시 조치를 취해야 함을 의미하지는 않습니다.

데이터 분포 변화의 유형

이론적으로, 모든 데이터 분포 변화가 동일하지는 않습니다. 그러나 실제로는:

어떤 유형의 변화가 발생했는지 판단하는 것은 매우 어려울 수 있습니다.
업계 엔지니어들이 분포 변화를 다루는 방식은 근본적인 변화 유형에 관계없이 동일한 경향이 있습니다.

모델은 동시에 여러 유형의 드리프트(drift)를 겪을 수 있습니다.

공변량 변화 (Covariate Shift)

소스 분포와 타겟 분포 간에 P(X)는 다르지만 P(Y|X)는 동일하게 유지됩니다. 즉, 입력의 분포는 변하지만 특정 입력이 주어졌을 때의 레이블 확률은 동일하게 유지됩니다.

예: 암 병원의 데이터를 사용하여 유방암 탐지 모델을 구축합니다. 이 병원 데이터는 40세 이상의 여성들이 정기 검진으로 이 검사를 받도록 권장되기 때문에, 일반 인구에서 볼 수 있는 것보다 40세 이상 여성의 데이터를 더 많이 포함합니다. 즉, P(X=40세 이상 여성)가 소스 분포와 타겟 분포에서 다릅니다. 그러나, P(Y=유방암|X=40세 이상 여성)은 그 여성이 학습 데이터에 속하는지 여부에 관계없이 동일합니다.

공변량 변화는 여러 가지 이유로 발생할 수 있습니다.

학습 시점 (소스 분포에 영향):
- 샘플 선택 편향(Sample selection bias): 위 예시와 같습니다.
- (4장 → 클래스 불균형을 다루는 데이터 레벨 방법에서 논의된 바와 같이) 모델 학습을 돕기 위해 학습 데이터가 인위적으로 조정됩니다.
- 액티브 러닝(active learning)을 통해 학습 과정이 변경되어, 모델이 분류하기 어려운 샘플에 더 많이 노출됩니다. 이는 모델이 학습하는 기본 소스 분포를 변경합니다.
프로덕션 환경 (타겟 분포에 영향):
- 일반적으로 애플리케이션이 사용되는 환경의 주요 변경 결과입니다. 예를 들어: 새로운 인구 통계의 사용자가 추가되거나, 새로운 국가에 출시하는 경우입니다.

레이블 변화 (Label Shift)

일명: 사전 변화(prior shift), 사전 확률 변화(prior probability shift), 타겟 변화(target shift).

소스 분포와 타겟 분포 간에 P(Y)는 다르지만 P(X|Y)는 동일하게 유지됩니다. 위 예시를 따르면, P(Y=유방암 보유)는 소스 분포와 타겟 분포에서 다르지만, P(X=40세 이상|Y=유방암 보유)는 두 분포에서 동일합니다.

공변량 변화는 (위 예시처럼) 레이블 변화를 유발할 수도 있지만, 모든 레이블 변화가 공변량 변화에 의해 유발되는 것은 아닙니다. 후자의 예는 책을 참조하십시오.

개념 변화 (Concept Drift)

일명: 사후 변화(posterior shift), "동일 입력, 다른 출력"

P(Y|X)는 변하지만 P(X)는 동일하게 유지됩니다. 예를 들어, 코로나 이전(pre-Covid) 데이터를 사용하여 아파트 가격 추정기를 학습시켰습니다. 만약 코로나 이후(post-Covid)에 동일한 모델을 사용한다면, 아파트는 동일하지만(즉, P(X=아파트 피처)는 코로나 전후 동일), 평가되는 가격은 극적으로 변했기 때문에 심각한 개념 변화를 겪을 것입니다.

많은 경우 개념 변화는 주기적이거나 계절적입니다. 예를 들어, 차량 공유 가격은 주중 대 주말에 변동합니다. 기업들은 개념 변화를 줄이기 위해 서로 다른 계절성 데이터로 학습된 다른 모델(예: 주말용 모델 vs 주중용 모델)을 가질 수 있습니다.

레이블 스키마 변경

분류 작업에서, 모델이 N개의 클래스를 출력하도록 학습되었는데 비즈니스 요구 사항이 변경되어 이제 N+m개의 클래스를 예측해야 할 때 발생합니다. 이는 높은 카디널리티(high-cardinality) 분류 문제에서 흔히 발생합니다.

회귀 작업에서, 출력 변수의 범위가 변경될 때 발생합니다.

데이터 분포 변화 탐지

데이터 분포 변화는 모델의 성능 저하를 유발할 때만 문제가 됩니다.

정확도 관련 지표를 사용한 탐지

데이터 분포 변화를 탐지하는 가장 좋은 메커니즘은 프로덕션 환경에서 모델의 정확도 관련 지표 (예: accuracy, F1, recall, AUC-ROC 등)를 모니터링하는 것입니다.

학습 시 테스트 세트를 사용하여 계산된 정확도와 관찰된 프로덕션 정확도 간에 큰 차이가 있다면, 데이터 변화 문제가 있을 수 있습니다.
관찰된 프로덕션 정확도가 시간이 지남에 따라 변한다면, 과거에는 없었던 데이터 드리프트 문제(예: 계절적 개념 변화, 사용자 기반 변경)가 나타났을 수 있습니다.

자연 레이블에 접근할 수 있다면, 정확도 관련 지표를 사용하여 변화를 탐지하는 것이 이상적입니다. 불행히도, 프로덕션 환경에서 항상 레이블에 접근할 수 있는 것은 아닙니다. 접근할 수 있더라도, 정확도 모니터링에 유용할 만큼 충분히 빠르지 않게 레이블이 지연될 수 있습니다. 그런 경우에도, 통계적 방법을 사용하여 데이터 분포 변화를 탐지할 수 있습니다.

통계적 방법을 사용한 탐지

엄밀히 말하면, 입력 분포 P(X), 실제 레이블 분포 P(Y), 그리고 조건부 분포 P(X|Y) 및 P(Y|X)를 모니터링하는 데 관심이 있어야 합니다.

어려운 점은, P(Y), P(X|Y), P(Y|X)를 모니터링하려면 실제(ground truth) 프로덕션 레이블이 필요하다는 것입니다. 더욱이, 실제 레이블에 접근할 수 있었다면, 정확도 관련 지표를 사용하여 탐지하는 것이 아마도 더 나을 것입니다.

이것이 실제(ground truth) 레이블에 접근할 수 없는 경우, 업계 대부분이 예측 분포 P(Y_hat) 및 입력 분포 P(X)의 변화를 모니터링하고 탐지하는 데 집중하는 이유입니다.

간단한 기술 통계를 통한 변화 탐지

이것은 간단하고 좋은 시작입니다.

소스 분포와 타겟 분포가 변했는지 파악하기 위해, 학습 세트와 관찰된 프로덕션 데이터에 대한 기술 통계(min, max, median, variance, 다양한 사분위수, 왜도(skewness), 첨도(kurtosis) 등)를 계산합니다.

기술 통계가 매우 다르다면, 분포 변화가 있었을 가능성이 높습니다. 그러나 그 반대는 사실이 아닙니다. 통계가 비슷하다고 해서 변화가 없었음을 보장하지는 않습니다.

가설 검정을 통한 변화 탐지

더 정교한 해결책은 두 모집단 간의 차이가 통계적으로 유의미한지 테스트하도록 설계된 통계적 검정을 사용하는 것입니다.

이를 수행할 때 몇 가지 참고 사항:

검정에서 통계적 차이가 있다는 것이 실제로 그 차이가 중요하다는 것을 의미하지는 않습니다. 다시 말하지만, 변화는 성능을 저해할 때 문제가 됩니다.
적은 샘플을 사용한 검정을 통해 통계적 차이를 감지할 수 있다면, 이는 아마도 그 차이가 심각하다는 것을 의미합니다. 반면에, 통계적 차이를 감지하는 데 엄청난 양의 데이터가 필요하다면, 그 차이는 아마도 매우 작아서 걱정할 필요가 없을 것입니다.
2-표본 검정(Two-sample tests)은 종종 저차원 데이터에서 더 잘 작동합니다. 검정을 실행하기 전에 데이터의 차원을 줄이는 것이 강력히 권장됩니다.
Alibi Detect는 많은 드리프트 탐지 알고리즘의 파이썬 구현을 포함하는 훌륭한 오픈 소스 패키지입니다.

이를 위해 사용될 수 있는 몇 가지 검정 (Alibi Detect에서 가져온 표):

콜모고로프-스미르노프 검정(Kolmogorov-Smirnov test):
- 작동하기 위해 기본 분포의 어떤 파라미터도 필요로 하지 않고, 기본 분포에 대해 어떤 가정도 하지 않기 때문에 (그래서 어떤 분포에도 작동함) 좋습니다.
- 불행히도 종종 그런 경우인, 고차원 데이터에서는 작동하지 않습니다.

변화 탐지를 위한 타임 윈도우 고려 사항

학습 데이터 분포 (일명 소스 분포)를 프로덕션 데이터 분포 (일명 타겟 분포)와 비교할 때, 테스트를 실행하기 위해 프로덕션 데이터를 가져오는 데 사용할 타임 윈도우(time window)를 선택해야 합니다. 이 섹션에는 해당 타임 윈도우를 선택할 때 고려해야 할 몇 가지 사항이 포함되어 있습니다.

데이터의 계절성을 고려하십시오. 데이터에 자연스러운 주간 주기가 있고, 학습 데이터에 여러 주가 포함되어 있다면, 일주일 미만의 프로덕션 타임 윈도우를 선택하면 이상한 결과가 나올 수 있습니다.
탐지 속도 vs 테스트의 신뢰성 트레이드오프를 고려하십시오. 더 짧은 타임 윈도우는 변화를 더 빨리 탐지하는 데 도움이 될 수 있습니다. 그러나, 더 많은 오탐(false alarms)을 유발할 수도 있습니다. 더 긴 타임 윈도우는 반대의 특성을 가집니다.
누적 타임 윈도우(accumulating time windows)와 슬라이딩 타임 윈도우(sliding time windows)의 차이점을 명심하십시오. 누적 타임 윈도우는 시간이 지남에 따라 반대쪽 끝의 오래된 데이터를 "폐기"하지 않고 프로덕션 데이터 세트에 데이터를 계속 추가합니다. 슬라이딩 타임 윈도우는 타임 윈도우를 벗어난 데이터를 폐기합니다.
- 누적 타임 윈도우는 훨씬 더 많은 데이터를 가질 수 있으므로 테스트가 더 신뢰할 수 있습니다. 그러나 이는 또한 이미 존재하는 데이터가 최근의 변경 사항을 가릴 수 있기 때문에, 이에 대해 실행되는 테스트가 갑작스러운 변화에 덜 반응적임을 의미합니다.
- 슬라이딩 타임 윈도우는 반대의 특성을 가집니다.

데이터 분포 변화 대응

변화에 대한 모델 민감도 최소화

지금까지, 우리는 데이터 분포 변화가 불가피하다고 논의했습니다. 그러나, 모델을 변화에 덜 민감하게 만들기 위해 할 수 있는 특정 작업이 있는 것도 사실입니다.

기법 1: 대규모 데이터셋을 사용하여 모델 학습

여기서의 희망은 대규모 데이터셋을 사용함으로써, 모델이 매우 포괄적인 분포를 학습하여 프로덕션에서 마주치는 어떤 데이터 포인트든 이 분포에서 올 가능성이 높게 만드는 것입니다.

이것은 연구에서 더 일반적이며 업계에서 항상 가능한 것은 아닙니다. 그럼에도 불구하고, 언급할 가치가 있습니다.

기법 2: 피처 선택 시 성능과 안정성 간의 트레이드오프 고려

어떤 피처는 다른 피처보다 분포 변화에 더 취약합니다. 예를 들어, 앱 스토어 평점은 모든 앱 및 OS 버전 출시마다 재설정됩니다. 대신 더 포괄적인(coarser) 백분위 평점을 사용하는 것을 고려할 수 있습니다. 피처의 정교함은 떨어지겠지만, 변화에 대해 더 안정적이고 견고할 것입니다.

기법 3: 빠르게 움직이는 시장과 느리게 움직이는 시장을 위해 별도 모델 생성 고려

미국의 주택 가격에 대한 회귀 모델을 구축하는 임무를 맡았다고 상상해 보십시오. 데이터를 탐색함으로써, 샌프란시스코와 뉴욕의 가격 변동이 미국 나머지 지역보다 훨씬 더 빠르다는 것을 알게 됩니다. 메인 모델과 별도로 해당 도시에 대한 독립적인 모델을 생성함으로써, 메인 모델을 지속적으로 재학습해야 할 필요성을 줄입니다. 또한, 빠르게 움직이는 시장 모델은 더 빈번한 재학습으로 최신 상태를 유지할 수 있습니다.

모델 배포 후 변화 수정

모델이 배포되면, 데이터 분포 변화를 다루는 두 가지 주요 접근 방식이 있습니다.

주기적으로 모델 재학습

이것은 단연코, 업계에서 볼 수 있는 가장 일반적인 전략입니다. 사실, 이것은 매우 중요해서 "9장: 지속적인 학습 및 프로덕션 환경에서의 테스트"가 전적으로 이 주제에 할애되어 있습니다.

이 접근 방식에서는 모델이 주기적으로(예: 한 달에 한 번, 일주일에 한 번, 하루에 한 번) 재학습됩니다. 고려해야 할 3가지 사항이 있습니다.

최적의 재학습 빈도(retraining frequency)에 대한 결정이 중요합니다. 그러나, 많은 기업이 여전히 실험 데이터 대신 직감(gut feeling)을 사용하여 이를 결정합니다. 재학습 빈도에 대한 자세한 내용은 "9장 → 모델을 얼마나 자주 업데이트해야 하는가"에 있습니다.
모델을 처음부터(from scratch) 재학습하기 (일명 상태 비저장(stateless) 재학습) VS 마지막 체크포인트에서 학습 계속하기 (일명 상태 저장(stateful) 재학습, 미세 조정(fine-tuning)). 이에 대한 자세한 내용은 9장 → 상태 비저장 vs 상태 저장 학습에 있습니다.
재학습에 어떤 데이터를 포함해야 합니까? 예: 지난 24시간, 지난주, 지난 6개월, 변화가 시작된 시점부터의 데이터?

이 3가지 사항을 결정하기 위해 실험을 실행해야 합니다.

새로운 레이블 없이 학습된 모델을 대상 분포에 적응시키기

이 접근 방식의 기법들은 본질과 연구 및 업계에서의 채택 정도가 다양합니다. 책에서 간략하게 언급된 두 가지 예:

Zhang et al (2013): 타겟 분포의 레이블을 사용하지 않고 공변량 변화와 레이블 변화 모두에 대해 모델의 예측을 수정하기 위해 커널 임베딩(kernel embedding) 및 조건부/주변부 분포와 함께 인과적 해석(causal interpretations)을 사용합니다.
Zhao et al (2020): 변화하는 분포에 불변(invariant)하는 데이터 표현을 학습할 수 있는 비지도 도메인 적응(unsupervised domain adaption) 기법입니다.

모니터링과 관측 가능성 (Monitoring and Observability)

모니터링과 관측 가능성은 밀접하게 연관되어 있지만 엄밀히 말하면 약간 다릅니다.

모니터링(Monitoring): 무언가 잘못되었을 때 언제 잘못되었는지 판단하는 데 도움이 되도록 추적기, 로그, 지표 등을 배치하는 것입니다.
관측 가능성(Observability): 무엇이 잘못되었는지 파악할 수 있게 해주는 도구 및 설정(즉, 시스템의 내부 작동을 관찰)을 의미합니다.

소프트웨어 관련 지표

ML 시스템 역시 소프트웨어 시스템이므로, 모든 소프트웨어 관측 가능성 관행이 적용됩니다. 추적하고자 하는 것들의 유형은 다음과 같습니다.

운영 지표:
- 시스템이 실행 중인 네트워크의 지표: 네트워크 지연 시간, 네트워크 부하.
- 머신 상태 지표: CPU/GPU 사용률, 메모리 사용률.
- 애플리케이션 지표: 엔드포인트 부하, 요청 성공률, 엔드포인트 지연 시간.

소프트웨어 시스템은 또한 가용성을 보장하기 위해 서비스 수준 목표(SLOs) 또는 서비스 수준 계약(SLAs)을 자주 사용합니다. SLO 및 SLA를 만들 때, "시스템은 99.99%의 시간 동안 '가동(up)'되어야 한다"에서 "가동"이 무엇을 의미하는지 파악해야 합니다.

예를 들어, "가동"을 중앙값(median) 지연 시간 ≤ 200ms 및 p99 ≤ 2초로 정의할 수 있습니다. 그런 다음 한 달 동안 시스템이 이 제한을 준수하지 않은 시간을 측정하여 가동 시간 백분율을 계산합니다.

ML 고유 지표

시스템이 가동 중이고 작동 중일 수 있지만, 예측이 엉망이라면 문제가 있는 것입니다. 이것이 ML 고유 지표가 필요한 부분입니다.

일반적으로 모니터링하고자 하는 네 가지 사항이 있습니다. 1. 정확도, 2. 예측, 3. 피처, 4. 원시 입력.

이 4가지 수준 각각에서 모니터링하는 데에는 본질적인 트레이드오프가 있습니다.

정확도 관련 지표와 같은 더 높은 수준의 지표는 이해하기 쉽고 비즈니스 수준 지표와 관련짓기 쉽습니다. 그러나, 이는 복잡한 변환 사슬의 출력을 나타내므로, 무언가 잘못되었다는 것을 알더라도 왜 그런지 반드시 알지는 못합니다.
원시 입력 모니터링과 같은 더 낮은 수준의 지표는 비즈니스와 거리가 멀고 설정하기 더 어렵습니다. 그러나, 특정 원시 입력 지표가 잘못되었다면, 즉시 문제가 무엇인지 알 수 있습니다.

ML 관측 가능성의 또 다른 핵심적이고 종종 간과되는 부분은 모델 해석 가능성(model interpretability)입니다. 모델의 정확도가 저하되거나 예측에 이상(anomaly)이 나타날 때, 모델이 어떻게 작동하고 어떤 피처가 예측에 가장 많이 기여하는지 알면 무엇이 잘못되었는지 식별하고 수정하는 데 많은 도움이 됩니다.

이는 모델 선택 시 해석 가능성 vs 성능 트레이드오프로 돌아가게 합니다. 더 해석하기 쉬운 모델이 모니터링하기 더 쉽습니다.

정확도 관련 지표 모니터링

정확도 관련 지표 설정은 문제에 자연 레이블 (또는 자연 레이블의 더 약한 프록시(proxy))이 있는지에 의존하기 때문에 항상 가능한 것은 아닙니다.

시스템이 예측에 대해 어떤 유형의 사용자 피드백이든(클릭, 숨기기, 구매, 좋아요(upvote), 싫어요(downvote), 즐겨찾기, 북마크, 공유 등) 받는다면, 반드시 그것을 추적해야 합니다. 피드백이 자연 레이블을 직접 추론하는 데 사용될 수 없더라도, ML 모델 성능의 변화를 감지하는 데 사용될 수 있습니다. 또한 2차 효과(second order effects)도 명심하고 추적하십시오. 예를 들어, 추천의 클릭률(click-through rate)은 동일하게 유지되지만 완료율(completion rate)이 떨어진다면, 이는 문제가 있다는 신호일 수 있습니다.

가능하다면, 사용자의 피드백을 수집하도록 시스템을 엔지니어링하십시오. 예를 들어, "좋아요 / 싫어요" 또는 "도움 안 됨" 버튼을 추가하십시오. 이는 정확도 관련 지표 이상으로 사용될 수 있습니다. 예를 들어, 향후 이터레이션을 위해 어떤 샘플을 사람의 레이블링(human annotation)을 위해 보내야 하는지 알리는 데 사용될 수 있습니다.

알림: 정확도 모니터링은 데이터 분포 변화를 모니터링하는 가장 강력하고 실용적인 방법입니다.

예측(Predictions) 모니터링

예측은 기업이 모니터링하는 가장 일반적인 산출물입니다. 왜냐하면 캡처하기 쉽고, 시각화하기 쉬우며, 저차원(low-dimensionality)이기 때문입니다. 이 마지막 속성은 요약 통계를 계산하고 해석하기 쉽게 만듭니다.

분포 변화에 대해 예측을 모니터링하십시오. 모델의 가중치가 변하지 않았는데 예측 분포가 변했다면, 이는 일반적으로 기본 입력 분포의 변화를 나타냅니다.

예측은 저차원이므로, 분포 변화를 평가하기 위해 2-표본 검정(two-sample tests)을 계산하기 쉽습니다.

이상(anomalies)에 대해 예측을 모니터링하십시오. 예측이 갑자기 10분 동안 계속 False를 예측하는 것과 같이 급격한 행동 변화를 보인다면, ML 사고(incident)가 발생했을 수 있습니다. 이상에 대한 예측 모니터링은 "자연 레이블"이 사용 가능해지기까지 며칠이 걸릴 수 있으므로, 이상에 대한 정확도 모니터링보다 훨씬 즉각적입니다.

피처(Features) 모니터링

원시 입력 데이터 모니터링과 비교할 때, 피처 모니터링은 피처에 미리 정의된 스키마가 있고 정보가 일반적으로 더 "작업하기 쉬운 상태" (예: 이미지의 실제 픽셀 VS 이미지에서 파생된 피처)에 있기 때문에 매력적입니다.

피처에서 모니터링할 수 있는 것들:

피처가 예상된 스키마를 따르는지.
- 피처 값이 정규 표현식(regular expression)을 만족하는지.
- 피처 값이 미리 정의된 집합에 속하는지.
피처의 min, max 또는 median이 허용 가능한 범위 내에 있는지.
피처 A의 값이 항상 피처 B보다 큰지.

이러한 유형의 피처 모니터링을 수행하는 두 가지 일반적인 라이브러리는 Great Expectations와 Deequ입니다.

피처 모니터링을 사용하여 입력 데이터 드리프트 P(X)를 탐지할 수도 있습니다. 통계적 검정을 사용할 계획이라면, 피처는 고차원인 경향이 있으므로 차원 축소(dimensionality reduction)를 수행해야 합니다. 그러나 차원 축소는 통계적 검정의 효과를 감소시킵니다.

피처 모니터링의 과제

피처 모니터링은 가능하지만 어렵기도 합니다. 다음은 마주칠 수 있는 몇 가지 과제입니다. 자신에게 맞는 피처 모니터링 수준을 선택할 수 있도록 이를 고려하십시오.

각각 수백 개의 피처를 가진 수백 개의 모델이 있을 수 있습니다. 이는 파악해야 할 지표가 매우 많다는 뜻입니다.
실제로, 피처 모니터링은 성능 저하 탐지보다는 디버깅 목적에 더 유용한 경향이 있습니다. 모든 피처에 자동화된 드리프트 알림을 추가하면 많은 오탐(false positives)이 발생할 것입니다.
피처 추출은 다단계 및 다중 도구 프로세스(예: Snowflake → Pandas → Numpy)일 수 있습니다. 이는 무엇을 모니터링할지 선택하기 더 어렵게 만듭니다.
피처 스키마는 시간이 지남에 따라 변경될 수 있으며, 기대치 모니터(expectation monitors)도 최신 상태로 유지해야 합니다.

원시 입력(Raw inputs) 모니터링

이론적으로, 원시 입력을 모니터링하면 입력의 "가장 순수한" 버전을 모니터링하는 이점을 얻을 수 있으며, 따라서 입력 분포가 정말로 변했는지 또는 다운스트림에 버그가 도입되었는지 알 수 있습니다.

실제로, 원시 입력을 모니터링하는 것은 정말 어렵고 때로는 불가능합니다.

원시 입력은 작업하기 매우 어려운 형식일 수 있습니다. 예: 대용량 자산, 다양한 형식의 이미지 / 비디오 / 오디오 파일, 암호화된 PII(개인 식별 정보) 데이터.
ML 엔지니어는 개인 정보 보호상의 이유로 원시 입력에 접근조차 못할 수 있으며, 데이터가 이미 부분적으로 처리된 데이터 웨어하우스에서 데이터를 쿼리하도록 요청받을 수 있습니다.

위의 이유로, 원시 입력 모니터링은 일반적으로 데이터 플랫폼 팀의 책임인 경우가 많습니다.

모니터링 도구 상자

구현 관점에서, 모니터링의 기둥은 지표, 로그, 추적(traces)입니다. 그러나, "시스템을 모니터링하는 사용자" 관점에서 모니터링의 실제 기둥은 로그, 대시보드, 알림입니다.

로그 및 분산 추적 (distributed tracing)

분산 시스템(distributed system)을 가지고 있다면 (아마도 그럴 것입니다), 로그에 분산 추적이 있는지 확인하십시오.
모든 이벤트 메타데이터를 로그와 함께 기록하십시오: 언제 발생하는지, 어떤 서비스에서 발생하는지, 호출된 함수, 관련된 사용자 등. 로그 태깅(Log tagging)을 활용하는 것이 좋습니다.
로그를 분석하고 싶다면, 수십억 개의 로그를 분석하는 것은 무익합니다. 기업들은 대규모 로그 분석을 수행하기 위해 ML을 사용합니다.
로그 기술의 소비자로서 다음 사항을 명심하십시오:
- 로그 제공업체(Log providers)는 특정 속성에 대해 주기적으로 로그를 처리할 수 있습니다. 이는 특정 문제를 주기적으로만 발견할 수 있음을 의미합니다.
- 문제가 발생하는 즉시 발견하려면, 로그 제공업체가 Flink와 같은 스트림 처리 기술을 사용해야 합니다.

대시보드

대시보드는 모니터링에 중요한 지표의 유용한 시각화를 보여줍니다.
대시보드는 엔지니어가 아닌 사람들도 모니터링에 접근할 수 있게 합니다. 모니터링은 개발자만을 위한 것이 아닙니다. 엔지니어가 아닌 이해관계자들도 프로덕션 환경에 ML 제품을 둠으로써 발생하는 영향 중 자신의 몫을 모니터링해야 합니다.
대시보드에 지표가 과도하게 많은 것은 비생산적입니다. 이는 대시보드 노후화(dashboard rot)로 알려져 있습니다.
- 대시보드에 포함할 지표를 까다롭게 선택하고, 더 높은 수준의 지표를 계산하여 더 낮은 수준의 지표를 추상화하십시오.

알림 (Alerts)

알림은 특정 알림 정책(alert policy)이 위반될 때 알림 채널(notification channel)로 전송되는 자동 경고입니다.
알림 정책: 알림을 트리거하기 위해 위반되어야 하는 조건과 해당 위반과 관련된 심각도(severity).
알림 채널: 누가 알림을 받아야 하는가? 이는 일반적으로 이메일, Slack 채널 및/또는 온콜(on-call) 명단입니다.
알림 설명: 알림을 받는 사람에게 무엇을 해야 하는지 포함된 런북(runbook)을 연결해두는 것이 좋습니다.
알림 피로(Alert fatigue)는 실질적인 문제입니다.
- 알림이 너무 많으면 사람들이 둔감해지고 중요한 알림이 무시될 것입니다.
- 조치 가능한(actionable) 알림만 생성하십시오.
- 알림 조건 위반의 결과가 다음 근무일까지 기다릴 수 없는 경우에만 근무 시간 외에 사람들에게 알림을 보내십시오.