Jonas Kim

Posted on Nov 8 • Edited on Nov 10

'머신러닝 시스템 설계' (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)

일명: 데이터 드리프트 (data drift)

소스 분포와 타겟 분포 간에 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), 예측 드리프트(prediction drift)

소스 분포와 타겟 분포 간에 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) 알림만 생성하십시오.
- 알림 조건 위반의 결과가 다음 근무일까지 기다릴 수 없는 경우에만 근무 시간 외에 사람들에게 알림을 보내십시오.

9장 - 지속적인 학습 및 프로덕션 환경에서의 테스트

이 장에서는 지속적인 학습과 프로덕션 환경에서의 모델 테스트라는 두 가지 크고 연관된 주제를 다룹니다. 이 두 주제를 함께 배우는 목표는 자동화되고, 안전하며, 효율적인 방식으로 프로덕션 환경에서 모델을 업데이트하는 방법을 배우는 것입니다.

이 장 전체는 8장에서 간략히 논의된 데이터 분포 변화를 수정하는 가장 일반적인 기법인 주기적인 모델 재학습에 대한 심층 탐구의 연속입니다.

지속적인 학습

지속적인 학습(Continual Learning)은 새로운 데이터가 사용 가능해짐에 따라 모델을 업데이트하는 개념입니다. 이는 모델이 현재의 데이터 분포를 따라잡도록 만듭니다.

모델이 업데이트되면, 맹목적으로 프로덕션에 릴리즈(release)할 수 없습니다. 안전하고 현재 프로덕션 모델보다 낫다는 것을 보장하기 위해 테스트되어야 합니다. 여기서 다음 섹션인 "프로덕션 환경에서의 모델 테스트"가 필요합니다.

지속적인 학습은 종종 오해를 받습니다.

지속적인 학습은 모든 새로운 데이터 포인트가 사용 가능해질 때마다 모델의 증분 업데이트(incremental update)를 허용하는 특별한 종류의 ML 알고리즘을 의미하지 않습니다. 이러한 특별한 알고리즘 클래스의 예로는 순차적 베이지안 업데이트(sequential bayesian updating)와 KNN 분류기가 있습니다. 이 알고리즘 클래스는 작으며 때때로 "온라인 학습 알고리즘"이라고도 합니다.
- 지속적인 학습의 개념은 특별한 클래스뿐만 아니라 모든 지도 ML 알고리즘에 적용될 수 있습니다.
지속적인 학습은 새로운 데이터 샘플이 생길 때마다 재학습 작업을 시작하는 것을 의미하지 않습니다. 사실 이는 위험합니다. 왜냐하면 신경망이 치명적 망각(catastrophic forgetting)에 취약해지기 때문입니다.
- 지속적인 학습을 사용하는 대부분의 회사는 마이크로 배치(micro-batches) (예: 512 또는 1024 샘플마다)로 모델을 업데이트합니다. 최적의 샘플 수는 작업에 따라 다릅니다.

지속적인 학습은 표면적으로는 데이터 사이언티스트의 작업처럼 보일 수 있습니다. 그러나 이를 가능하게 하려면 많은 인프라 작업이 필요한 경우가 많습니다.

왜 지속적인 학습인가?

근본적인 이유는 모델이 데이터 분포 변화를 따라잡도록 돕기 위해서입니다. 변화하는 분포에 빠르게 적응하는 것이 중요한 일부 유스케이스가 있습니다. 다음은 몇 가지 예입니다.

예상치 못하고 빠른 변화가 발생할 수 있는 유스케이스: 차량 공유와 같은 유스케이스가 이에 해당합니다. 예를 들어, 무작위 월요일의 무작위 지역에서 콘서트가 있을 수 있으며, "월요일 가격 책정 ML 모델"이 이를 잘 처리하지 못할 수 있습니다.
특정 이벤트에 대한 학습 데이터를 얻을 수 없는 유스케이스: 이에 대한 예는 블랙 프라이데이나 이전에 시도된 적 없는 다른 세일 이벤트의 이커머스(e-commerce) 모델입니다. 블랙 프라이데이의 사용자 행동을 예측하기 위한 과거 데이터를 수집하기는 매우 어렵기 때문에, 모델은 하루 종일 적응해야 합니다.
콜드 스타트 문제(cold start problem)에 민감한 유스케이스: 이 문제는 모델이 과거 데이터가 없거나 (데이터가 오래된) 신규 (또는 로그아웃한) 사용자에 대해 예측을 해야 할 때 발생합니다. 해당 사용자로부터 일부 데이터를 얻는 즉시 모델을 적응시키지 않으면, 그 사용자에게 관련성 있는 것을 추천할 수 없을 것입니다.

개념: 상태 비저장(Stateless) 재학습 VS 상태 저장(Stateful) 학습

상태 비저장(Stateless) 재학습

매번 무작위로 초기화된 가중치와 더 최신 데이터를 사용하여 모델을 처음부터 재학습합니다.

이전 모델 버전 학습에 사용된 데이터와 일부 겹칠 수 있습니다.
대부분의 회사는 상태 비저장 재학습을 사용하여 지속적인 학습을 시작합니다.

상태 저장(Stateful) 학습 (일명 파인 튜닝, 증분 학습)

이전 학습 라운드의 가중치로 모델을 초기화하고 새로운 미관측(unseen) 데이터를 사용하여 학습을 계속합니다.

훨씬 적은 데이터로 모델을 업데이트할 수 있습니다.
모델이 더 빨리 수렴하고 더 적은 컴퓨팅 파워를 사용하게 합니다.
- 일부 회사는 컴퓨팅 파워 45% 감소를 보고했습니다.
이론적으로는 데이터가 학습에 사용되면 (그리고 약간의 안전 여유 시간을 남겨두고) 데이터를 전혀 저장하지 않아도 되게 만듭니다. 이는 이론적으로 데이터 프라이버시 우려를 제거합니다.
- 실제로는 대부분의 회사가 "모든 것을 추적하자"는 관행을 가지고 있으며 더 이상 필요하지 않은 데이터라도 버리는 것을 꺼립니다.
때때로 모델을 재보정(re-calibrate)하기 위해 대량의 데이터로 상태 비저장 재학습을 실행해야 합니다.
인프라가 올바르게 설정되면, 상태 비저장에서 상태 저장 재학습으로 변경하는 것은 버튼 하나 누르는 것만으로 가능해집니다.
모델 이터레이션(iteration) vs 데이터 이터레이션: 상태 저장 학습은 주로 기존의 고정된 모델 아키텍처에 새로운 데이터를 통합하는 데 사용됩니다(즉, 데이터 이터레이션). 모델의 피처나 아키텍처를 변경하려면, 먼저 상태 비저장 재학습을 수행해야 합니다.
- 한 모델 아키텍처에서 새 아키텍처로 가중치를 이전하는 방법에 대한 몇 가지 연구(Net2Net knowledge transfer, model surgery)가 있었습니다. 아직 업계에서 이러한 기법의 채택은 거의 없습니다.

개념: 로그 앤 웨이트(log and wait)를 통한 피처 재사용

피처는 추론을 위해 계산됩니다. 일부 회사는 모든 데이터 샘플에 대해 계산된 피처를 저장하여, 지속적인 학습 훈련에 재사용함으로써 일부 계산을 절약할 수 있도록 합니다. 이는 로그 앤 웨이트(log and wait)로 알려져 있습니다.

이는 또한 피처 모니터링을 보조하는 데 사용됩니다.
2023년 1월 기준, 로그 앤 웨이트는 아직 대중적이지 않지만 주목받고 있습니다.

지속적인 학습의 과제

지속적인 학습은 업계에서 큰 성공을 거두며 적용되어 왔습니다. 그러나 기업이 극복해야 할 세 가지 주요 과제가 있습니다.

평가 과제

지속적인 학습을 관행으로 채택하는 것은 치명적인 모델 실패의 위험을 수반합니다. 모델 업데이트가 빈번할수록 모델이 실패할 기회도 많아집니다.

또한, 지속적인 학습은 모델을 오염시키기 위한 조직적인 적대적 공격(adversarial attacks)의 문을 엽니다.

이는 모델을 더 넓은 대상에게 롤아웃(roll out)하기 전에 모델을 테스트하는 것이 중요함을 의미합니다.

테스트에는 시간이 걸리므로, 이는 달성할 수 있는 가장 빠른 모델 업데이트 빈도에 또 다른 제한 요인이 될 수 있습니다.
예: 사기 탐지를 위한 새 모델은 신뢰할 수 있는 수준으로 평가되기에 충분한 트래픽을 얻는 데 약 2주가 걸릴 수 있습니다.

데이터 스케일링 과제

피처 계산에는 일반적으로 스케일링이 필요합니다. 스케일링은 min, max, average, variance와 같은 전역 데이터 통계에 접근해야 합니다.

상태 저장 학습을 사용하는 경우, 전역 통계는 모델 학습에 이미 사용된 이전 데이터와 모델을 새로 고치는 데 사용되는 새 데이터를 모두 고려해야 합니다. 이러한 시나리오에서 전역 통계를 추적하는 것은 까다로울 수 있습니다.

이를 수행하는 일반적인 기법은 (학습 시점에 전체 데이터셋을 로드하여 계산하는 대신) 새로운 데이터를 관찰함에 따라 증분적으로(incrementally) 이러한 통계를 계산하거나 근사하는 것입니다.

이 기법의 예는 "스트림에서의 최적 분위수 근사(Optimal Quantile Approximation in Streams)"입니다.
Sklearn의 StandardScaler에는 실행 통계(running statistics)와 함께 피처 스케일러를 사용할 수 있게 하는 partial_fit이 있습니다. 그러나 내장된 메서드는 느리고 광범위한 실행 통계를 지원하지 않습니다.

알고리즘 과제

이 과제는 특정 유형의 알고리즘을 사용하고 정말 빠르게(예: 매시간) 업데이트하려 할 때 나타납니다.

해당 알고리즘은 설계상 학습을 위해 전체 데이터셋에 접근해야 하는 알고리즘입니다. 예를 들어, 행렬 기반, 차원 축소 기반, 트리 기반 모델입니다. 이러한 유형의 모델은 신경망이나 다른 가중치 기반 모델처럼 새로운 데이터로 증분적으로 학습될 수 없습니다.

예: PCA 차원 축소는 증분적으로 수행할 수 없습니다. 전체 데이터셋이 필요합니다.

이 과제는 알고리즘이 전체 데이터셋을 처리할 때까지 기다릴 여유가 없기 때문에 정말 빠르게 업데이트해야 할 때만 발생합니다.

영향을 받는 모델 중 일부는 증분적으로 학습되도록 설계된 변형(variants)이 있지만, 이러한 알고리즘의 채택은 널리 퍼져 있지 않습니다. 한 예로 Hoeffding Trees와 그 하위 변형들이 있습니다.

지속적인 학습의 4단계

회사는 보통 4단계를 거쳐 지속적인 학습으로 이동합니다.

1단계: 수동, 상태 비저장 재학습

모델은 (1) 모델 성능이 너무 저하되어 이득보다 해가 더 많고, (2) 팀이 업데이트할 시간이 있을 때라는 두 가지 조건이 충족될 때만 재학습됩니다.

2단계: 고정된 일정의 자동화된 상태 비저장 재학습

이 단계는 일반적으로 도메인의 주요 모델이 개발되어 더 이상 새 모델을 만드는 것이 우선순위가 아니고, 기존 모델을 유지하고 개선하는 것이 우선순위가 될 때 발생합니다. 1단계에 머무르는 고통이 무시하기엔 너무 커졌습니다.

이 단계의 재학습 빈도는 일반적으로 "직감(gut feeling)"에 기반합니다.

1단계와 2단계 사이의 변곡점(inflection point)은 대개 누군가가 상태 비저장 재학습을 주기적으로 실행하는 스크립트를 작성할 때입니다. 이 스크립트를 작성하는 것은 모델 재학습을 위해 조정되어야 하는 의존성이 얼마나 많으냐에 따라 매우 쉽거나 매우 어려울 수 있습니다.

이 스크립트의 상위 수준 단계는 다음과 같습니다.

데이터 가져오기(Pull data).
필요시 데이터 다운샘플링 또는 업샘플링.
피처 추출.
학습 데이터를 생성하기 위해 레이블 처리 및/또는 주석(annotate) 달기.
학습 프로세스 시작.
새 모델 평가.
배포.

이 스크립트를 구현하려면 두 가지 추가 인프라가 필요합니다.

스케줄러.
모델을 재현하는 데 필요한 모든 아티팩트(artefacts)를 자동으로 버전 관리하고 저장하는 모델 스토어. 성숙한 모델 스토어로는 AWS SageMaker와 Databrick's MLFlow가 있습니다.

3단계: 고정된 일정의 자동화된 상태 저장 학습

이를 달성하려면 스크립트를 재구성하고 데이터 및 모델 계보(lineage)를 추적할 방법이 필요합니다. 간단한 모델 계보 버전 관리 예:

V1 vs V2는 동일한 문제에 대한 두 가지 다른 모델 아키텍처입니다.
V1.2 vs V2.3은 모델 아키텍처 V1이 전체 상태 비저장 재학습의 2번째 이터레이션(iteration)에 있고 V2는 3번째 이터레이션에 있음을 의미합니다.
V1.2.12 vs V2.3.43은 V1.2에 대해 12번의 상태 저장 학습이, V2.3에 대해 43번의 상태 저장 학습이 수행되었음을 의미합니다.
모델이 어떻게 발전하고 있는지 전체 그림을 추적하려면 아마도 데이터 버전 관리와 같은 다른 버전 관리 기법과 함께 이를 사용해야 할 것입니다.
저자에 따르면, 그녀는 이런 유형의 모델 계보 기능을 갖춘 모델 스토어를 알지 못하므로, 회사들은 자체적으로(in-house) 구축합니다.
특정 시점에는 프로덕션 환경에서의 모델 테스트에 설명된 구성을 통해 여러 모델이 동시에 프로덕션 환경에서 실행되고 있을 것입니다.

4단계: 지속적인 학습

이 단계에서는 이전 단계의 고정된 일정 부분이 재학습 트리거 메커니즘으로 대체됩니다. 트리거는 다음과 같을 수 있습니다.

시간 기반
성능 기반: 예: 성능이 x% 아래로 떨어졌을 때.
- 프로덕션 환경에서 항상 정확도를 직접 측정할 수는 없으므로, 더 약한 프록시(proxy)를 사용해야 할 수도 있습니다.
볼륨 기반: 레이블이 지정된 총 데이터 양이 5% 증가했을 때.
드리프트(Drift) 기반: 예: "주요" 데이터 분포 변화가 감지되었을 때.
- 드리프트 기반 트리거를 사용하는 것의 어려운 점은, 이전 장에서 언급했듯이, 데이터 분포 변화는 모델 성능을 저하시킬 때만 문제가 된다는 것입니다. 언제 그런 일이 발생하는지 알기 까다로울 수 있습니다.

모델을 얼마나 자주 업데이트해야 하는가

이 질문에 답하려면 먼저 최신 데이터로 모델을 업데이트할 때 얻는 이득이 무엇인지 이해하고 결정해야 합니다. 이득이 클수록 더 자주 재학습해야 합니다.

데이터 신선도의 가치 측정

최신 데이터의 가치를 정량화하는 한 가지 방법은 동일한 모델 아키텍처를 세 가지 다른 기간의 데이터로 학습시킨 다음, 각 모델을 현재의 레이블이 지정된 데이터로 테스트하는 것입니다 (이미지 참조).

3개월 동안 모델을 방치(stale)하면 현재 테스트 데이터 정확도에서 10%의 차이가 발생하고, 10%가 허용 불가능하다면 3개월보다 더 짧은 주기로 재학습해야 합니다.

이미지는 몇 달 단위의 데이터셋 예시를 보여주지만, 유스케이스에 따라 몇 주, 며칠 또는 몇 시간과 같이 더 세분화된 시간 단위(time buckets)가 필요할 수 있습니다.

언제 모델 이터레이션(iteration)을 해야 하는가?

지금까지 이 장의 대부분은 새 데이터로 모델을 업데이트하는 것(즉, 데이터 이터레이션)을 참조했습니다. 그러나 실제로는 때때로 모델의 아키텍처를 변경해야 할 수도 있습니다(즉, 모델 이터레이션). 언제 모델 이터레이션을 고려해야 하고 언제 하지 말아야 하는지에 대한 몇 가지 지침은 다음과 같습니다.

데이터 이터레이션 재학습 트리거를 계속 줄여도 큰 이득이 없다면, 아마도 더 나은 모델을 찾는 데 투자해야 할 때입니다 (물론 비즈니스에 필요하다면).
100배의 컴퓨팅 파워가 필요한 더 큰 모델 아키텍처로 변경하는 것이 1%의 성능 향상을 주지만, 재학습 트리거를 3시간으로 줄이는 것이 1배의 컴퓨팅 파워로 1%의 성능 향상을 준다면, 모델 이터레이션보다 데이터 이터레이션을 선호하십시오.
"언제 모델 이터레이션을 하고 언제 데이터 이터레이션을 하는가"라는 질문은 아직 모든 작업에 대해 연구가 잘 답변하지 못했습니다. 특정 작업에 대해 실험을 실행하여 언제를 선택할지 알아내야 합니다.

프로덕션 환경에서의 모델 테스트

모델을 널리 사용하기 전에 충분히 테스트하려면 사전 배포 오프라인 평가와 프로덕션 환경에서의 테스트가 모두 필요합니다. 오프라인 평가만으로는 충분하지 않습니다.

이상적으로는 각 팀이 모델 평가 방법에 대한 명확한 파이프라인(어떤 테스트를 실행할지, 누가 실행할지, 모델을 다음 단계로 승격시키기 위한 임계값은 무엇인지)을 마련해야 합니다. 이러한 평가 파이프라인은 새로운 모델 업데이트가 있을 때 자동화되고 시작되는 것이 가장 좋습니다. 단계별 승격은 소프트웨어 엔지니어링에서 CI/CD를 평가하는 방식과 유사하게 검토되어야 합니다.

사전 배포 오프라인 평가

6장 → 모델 오프라인 평가에서 모델 선택에 사용할 수 있는 몇 가지 평가 기법을 논의했습니다. 동일한 평가를 사전 배포 오프라인 평가에 재사용할 수 있습니다.
가장 일반적인 두 가지는 (1) 베이스라인과 비교하기 위해 테스트 스플릿(test split)을 사용하는 것과 (2) 백테스트(backtests)를 실행하는 것입니다.
- 테스트 스플릿은 여러 모델을 비교할 수 있는 신뢰할 수 있는 벤치마크를 제공하기 위해 일반적으로 정적(static)입니다. 이는 또한 정적인 오래된 테스트 스플릿에서의 좋은 성능이 프로덕션의 현재 데이터 분포 조건 하에서의 좋은 성능을 보장하지는 않는다는 것을 의미합니다.
- 백테스팅은 모델이 학습 중에 보지 못한 가장 최신의 레이블이 지정된 데이터를 사용하여 성능을 테스트하는 아이디어입니다 (예: 지난 하루의 데이터로 학습했다면, 지난 1시간의 데이터를 사용하여 백테스트).
  - 백테스트를 아직 소개하지 않았습니다. 이 요약에서 처음 언급하는 것입니다.
  - 백테스팅만으로 프로덕션 환경에서의 테스트를 피할 수 있다고 생각하기 쉽지만, 그렇지 않습니다. 프로덕션 성능은 레이블 관련 성능 그 이상입니다. 모델이 광범위하게 롤아웃(rollout)되기에 안전한지 확인하려면 여전히 지연 시간, 모델에 대한 사용자 행동, 시스템 통합 정확성 같은 것들을 관찰해야 합니다.

프로덕션 환경에서의 테스트 전략

섀도우 배포 (Shadow Deployment)

직관: 기존 챔피언 모델과 병렬로 챌린저 모델을 배포합니다. 모든 들어오는 요청을 두 모델 모두에 보내지만, 챔피언 모델의 추론만 사용자에게 제공합니다. 두 모델의 예측을 모두 로그로 남긴 다음 비교합니다.
장점
- 모델을 배포하는 가장 안전한 방법입니다. 새 모델에 버그가 있더라도 예측이 제공되지 않습니다.
- 개념적으로 간단합니다.
- 모든 모델이 전체 트래픽을 받기 때문에, 실험이 통계적 유의성(statistical significance)에 도달하기에 충분한 데이터를 다른 모든 전략보다 빠르게 수집할 것입니다.
단점
- 모델 성능 측정이 사용자가 예측과 어떻게 상호작용하는지 관찰하는 데 의존할 때 이 기법을 사용할 수 없습니다. 예를 들어, 섀도우 추천 모델의 예측은 제공되지 않으므로 사용자가 클릭했을지 여부를 알 수 없습니다.
- 예측 수가 두 배가 되어 필요한 컴퓨팅 수가 두 배로 들기 때문에 실행 비용이 비쌉니다.
- 온라인 예측 모드 중 하나를 사용하여 추론이 발생하는 경우 다음과 같은 엣지 케이스(edge cases)를 처리하는 방법을 찾아야 합니다.
  - 섀도우 모델이 기본 모델보다 예측을 제공하는 데 훨씬 더 오래 걸린다면 어떻게 할 것인가?
  - 섀도우 모델이 실패하면 기본 모델도 실패해야 하는가, 아닌가?

A/B 테스팅

직관: 챔피언 모델(모델 A)과 함께 챌린저 모델을 배포하고 트래픽의 일부 비율을 챌린저(모델 B)로 라우팅합니다. 챌린저의 예측은 사용자에게 보여집니다. 두 모델의 모니터링 및 예측 분석을 사용하여 챌린저의 성능이 챔피언보다 통계적으로 더 나은지 확인합니다.
- 일부 유스케이스는 트래픽을 나누고 동시에 여러 모델을 갖는 아이디어와 잘 맞지 않습니다. 이 경우 A/B 테스팅은 시간적 분할(temporal splits)을 수행하여 수행할 수 있습니다. 하루는 모델 A, 다음 날은 모델 B.
- 트래픽 분할은 진정한 무작위 실험(randomized experiment)이어야 합니다. 데스크톱 사용자는 A를 받고 모바일 사용자는 B를 받는 것처럼 누가 모델 A를 받고 누가 모델 B를 받는지에 선택 편향(selection bias)이 개입되면, 결론은 부정확할 것입니다.
- 실험은 차이에 대한 충분한 통계적 신뢰(statistical confidence)를 달성하기에 충분한 샘플을 수집할 만큼 오래 실행되어야 합니다.
- 통계적 유의성이 모든 것을 보장하지는 않습니다 (그래서 신뢰도(confidence)가 있는 것입니다). A와 B 사이에 통계적 차이가 없다면, 아마도 둘 중 하나를 사용해도 될 것입니다.
- 원한다면 A/B/C/D 테스트를 실행하는 것을 막는 것은 없습니다.
장점:
- 예측이 사용자에게 제공되므로, 이 기법을 사용하면 사용자가 다른 모델에 어떻게 반응하는지 완전히 파악할 수 있습니다.
- A/B 테스팅은 이해하기 간단하며 주변에 많은 라이브러리와 문서가 있습니다.
- 요청당 하나의 예측만 있으므로 실행 비용이 저렴합니다.
- 온라인 예측 모드를 위해 추론 요청을 병렬화할 때 발생하는 엣지 케이스를 고려할 필요가 없습니다 (섀도우 배포의 단점 참조).
단점:
- 섀도우 배포보다 덜 안전합니다. 실제 트래픽을 통과시킬 것이므로 모델이 심각하게 실패하지 않을 것이라는 더 강력한 오프라인 평가 보증을 원할 것입니다.
- 더 많은 위험을 감수(B 모델로 더 많은 트래픽 라우팅)하는 것과 분석을 더 빨리 만들기 위해 충분한 샘플을 얻는 것 사이에서 본질적인 선택을 해야 합니다.

카나리 릴리즈 (Canary Release)

직관: 챌린저와 챔피언을 나란히 배포하되, 챌린저가 트래픽을 받지 않는 상태에서 시작합니다. 챔피언에서 챌린저(일명 카나리(canary))로 천천히 트래픽을 이동시킵니다. 챌린저의 성능 지표를 모니터링하고, 좋아 보이면 챌린저가 모든 트래픽을 받을 때까지 계속 진행합니다.
- 카나리 릴리즈는 성능 차이를 엄격하게 측정하기 위해 A/B 테스팅과 함께 사용될 수 있습니다.
- 카나리 릴리즈는 성능 차이를 눈대중으로(eyeball) 확인하는 "YOLO 모드"로 실행될 수도 있습니다.
- 카나리 릴리즈의 다른 버전은 챌린저 모델을 먼저 더 작은 시장에 릴리즈한 다음, 모든 것이 좋아 보이면 모든 시장으로 승격시키는 것일 수 있습니다.
- 챌린저 모델에 문제가 생기기 시작하면 트래픽을 다시 챔피언으로 라우팅합니다.
장점:
- 이해하기 쉽습니다.
- 회사에 이미 일부 피처 플래깅(feature flagging) 인프라가 있다면 구현하기 가장 간단한 전략입니다.
- 챌린저 예측이 제공되므로, 성능을 파악하기 위해 사용자 상호작용이 필요한 모델과 함께 사용할 수 있습니다.
- 섀도우 배포에 비해 실행 비용이 저렴합니다. 요청당 하나의 추론.
- A/B 테스팅과 함께 사용하면, 각 모델이 받는 트래픽 양을 동적으로 변경할 수 있습니다.
단점:
- 성능 차이를 결정하는 데 엄격하지 않을 가능성을 엽니다.
- 릴리즈가 신중하게 감독되지 않으면 사고가 발생할 수 있습니다. 이는 틀림없이 가장 덜 안전한 옵션이지만 롤백(rollback)하기는 매우 쉽습니다.

인터리빙 실험 (Interleaving Experiments)

직관: A/B 테스팅에서는 단일 사용자가 모델 A 또는 모델 B의 예측을 받습니다. 인터리빙에서는 단일 사용자가 모델 A와 모델 B의 예측을 혼합하여(interleaved) 받습니다. 그런 다음 각 모델의 예측에 대한 사용자 선호도(예: 사용자가 모델 B의 추천을 더 많이 클릭함)를 측정하여 각 모델이 어떻게 수행되는지 추적합니다.
- 추천 작업은 인터리빙의 일반적인 유스케이스입니다. 모든 작업이 이 전략에 적합한 것은 아닙니다.
- 모델 A의 예측을 항상 상단에 두는 것처럼 모델에게 불공평한 사용자 선호도 이점을 주는 것을 피해야 합니다. 첫 번째 슬롯이 모델 A에서 나올 확률과 모델 B에서 나올 확률은 동일해야 합니다. 나머지 위치는 팀 드래프팅 방법(team-drafting method)을 사용하여 채울 수 있습니다 (이미지 참조).
장점:
- Netflix는 실험적으로 인터리빙이 전통적인 A/B 테스팅에 비해 상당히 적은 샘플 크기로 최고의 모델을 신뢰성 있게 식별한다는 것을 발견했습니다.
  - 이는 주로 두 모델이 모두 전체 트래픽을 받기 때문입니다.
- 섀도우 배포와 달리, 이 전략은 (예측이 제공되기 때문에) 사용자가 예측에 어떻게 반응하는지 파악할 수 있게 합니다.
단점:
- 구현이 A/B 테스팅보다 더 복잡합니다.
  - 인터리빙된 모델 중 하나가 응답하는 데 너무 오래 걸리거나 실패할 경우 어떻게 할지에 대한 엣지 케이스를 걱정해야 합니다.
- 모든 요청이 여러 모델로부터 예측을 받기 때문에 필요한 컴퓨팅 파워가 두 배가 됩니다.
- 모든 유형의 작업에 사용될 수 없습니다. 예를 들어, 랭킹/추천 작업에는 작동하지만 회귀 작업에는 의미가 없습니다.
- 많은 수의 챌린저 모델로 쉽게 확장되지 않습니다. 2-3개의 인터리빙된 모델이 최적점(sweet spot)인 것 같습니다.

밴딧 (Bandits)

직관: 밴딧은 각 모델 변형(variant)의 현재 성능을 추적하고, 모든 요청에 대해 지금까지 가장 성능이 좋은 모델을 사용할지 (즉, 현재 지식 활용(exploit)) 또는 다른 모델 중 하나를 시도하여 그들에 대한 더 많은 정보를 얻을지 (즉, 다른 모델 중 하나가 실제로는 더 나은지 탐색(explore)) 동적으로 결정하는 알고리즘입니다.
- 밴딧은 어떤 모델을 사용할지 결정하는 데 기회비용(opportunity cost)이라는 또 다른 개념을 추가합니다.
- 밴딧은 모든 경우에 적용될 수 없습니다. 밴딧이 적용 가능하려면 유스케이스에 다음이 필요합니다.
  - 온라인 예측을 수행해야 합니다. 배치 오프라인 예측은 밴딧과 호환되지 않습니다.
  - 예측이 좋았는지 나빴는지 판단하기 위한 짧은 피드백 루프와, 그 피드백을 밴딧 알고리즘에 전파하여 각 모델의 보상(payoff)을 업데이트하는 메커니즘이 필요합니다.
- 많은 밴딧 알고리즘이 있습니다. 가장 간단한 것은 입실론-그리디(epsilon-greedy)라고 불립니다. 가장 강력하고 인기 있는 두 가지는 톰슨 샘플링(Thompson Sampling)과 신뢰 상한(Upper Confidence Bound, UCB)입니다.
장점:
- 밴딧은 어떤 모델이 더 나은지 결정하는 데 A/B 테스팅보다 훨씬 적은 데이터가 필요합니다. 책에 나온 한 예는 A/B 테스팅으로 95% 신뢰도를 얻는 데 63만 샘플이 필요한 반면, 밴딧은 1만 2천 샘플이 필요했습니다.
- 밴딧은 데이터를 더 효율적으로 사용하면서 동시에 기회비용을 최소화합니다. 많은 경우 밴딧은 최적(optimal)으로 간주됩니다.
- A/B 테스팅에 비해 밴딧은 더 안전합니다. 왜냐하면 모델이 정말 나쁘다면 알고리즘이 해당 모델을 덜 자주 선택할 것이기 때문입니다. 또한 수렴이 더 빠르므로 나쁜 챌린저를 빨리 제거할 수 있습니다.
단점:
- 다른 모든 전략에 비해, 밴딧은 피드백을 알고리즘에 지속적으로 전파해야 하므로 구현하기가 훨씬 더 어렵습니다.
- 밴딧은 특정 유스케이스에만 사용될 수 있습니다 (위 참조).
- 챌린저가 실제 트래픽을 받기 때문에 섀도우 배포만큼 안전하지는 않습니다.

참고: 추천 알고리즘 개선을 위한 컨텍스추얼 밴딧 사용

이 하위 섹션은 프로덕션 환경에서의 모델 테스트와 관련이 없지만, 밴딧에 대해 이야기하고 있으므로 언급하겠습니다.

컨텍스추얼 밴딧(contextual bandits)이라는 밴딧 알고리즘의 하위 범주가 있습니다. 컨텍스추얼 밴딧은 "활용 vs 탐색" 결정을 내릴 때 각 옵션의 과거 "보상"만 고려하는 것이 아니라, 추가 정보 (즉, 컨텍스트(context))도 고려합니다. 이 컨텍스트는 사용자에 대한 정보, 시간/연도에 대한 정보, 제품에 대한 정보일 수 있습니다. 보상과 컨텍스트를 모두 사용하여, 컨텍스추얼 밴딧은 "개인화된" 탐색 vs 활용 결정을 내릴 수 있습니다.

컨텍스추얼 밴딧은 추천 작업에서 큰 성공을 거두며 성능을 크게 향상시켰습니다. 예를 들어, 이커머스 환경에서 당신이 구매할 가능성이 높은 제품(활용)을 보여줄지, 아니면 당신이 과거에 본 적 없는 다른 제품(탐색)을 보여줄지 결정하는 데 사용될 수 있습니다. 이 결정은 당신에 대한 정보와 잠재적 제품에 대한 정보를 컨텍스트로 고려하여 당신을 위해 내려집니다.

컨텍스추얼 밴딧은 학습 데이터가 필요 없는 추천 알고리즘으로 "단독(solo)" 사용될 수 있습니다. 컨텍스트와 보상 없이 시작하여, 무엇을 추천할지 추측하고 진행하면서 학습합니다.

또한 딥 러닝과 결합하여 추천 성능을 향상시킬 수도 있습니다. 관심이 있다면 Twitter 엔지니어링의 이 논문을 참조하십시오.

컨텍스추얼 밴딧은 퇴행성 피드백 루프와 싸우는 데 사용될 수 있습니다.

컨텍스추얼 밴딧의 주요 단점은 "일반" 밴딧보다 구현하기가 훨씬 더 어렵다는 것입니다. 구현이 기본 ML 모델의 아키텍처(예: 트리 vs 신경망)에 의존하므로 일반화 가능성이 떨어집니다.

10장 - ML Ops를 위한 인프라와 도구

ML 시스템을 위해 무엇을 해야 하는지 정확히 알지만, 인프라가 지원하지 않아서 실행하지 못하는 데이터 사이언티스트를 만나는 것은 드문 일이 아닙니다.

인프라가 올바르게 설정되면 프로세스를 자동화하여 전문 지식과 엔지니어링 시간의 필요성을 줄이는 데 도움이 될 수 있습니다.
잘못 설정된 인프라는 우리에게 고통을 주며 교체 비용이 많이 듭니다.

ML 인프라는 4개의 레이어로 그룹화할 수 있습니다. 이 장에서는 각 레이어를 다룰 것입니다. 이 장은 이해를 돕기 위해 "평균적인 개발자에게 익숙한" 순서대로 레이어를 제시합니다.

이 장은 "직접 구축(build) vs 구매(buy)" 결정을 탐색하는 방법에 대한 논의로 마무리됩니다.

인프라 요구 사항은 회사 규모를 따른다

팀에 필요한 인프라는 애플리케이션이 얼마나 전문화되어 있는지에 따라 다릅니다.

스펙트럼의 한쪽 끝에는 분기별 보고서나 내년 예측과 같은 임시 비즈니스 분석(ad-hoc business analytics)을 위해 ML을 사용하는 회사가 있습니다.
- 이들의 작업 결과는 보통 보고서나 슬라이드 쇼로 들어갑니다.
- 이 회사들은 Jupyter Notebook만 있으면 되므로 인프라에 투자할 필요가 없습니다.
다른 쪽 끝에는 ML 사용 규모의 한계를 밀어붙이는 회사들이 있습니다.
- 이들은 극도로 낮은 지연 시간 요구 사항을 가지거나, 하루에 페타바이트(petabytes)의 새로운 데이터를 처리하거나, 시간당 수백만 건의 예측을 수행해야 합니다.
- 이들은 Tesla, Google, Facebook과 같은 회사들입니다.
- 이 회사들은 보통 자체 전문 인프라를 개발해야 합니다. 이 전문 인프라의 일부는 나중에 공개적으로 사용 가능하게 될 수 있습니다 (Google이 GCP를 통해 그랬던 것처럼).
대다수의 회사는 스펙트럼의 중간에 있습니다. 이들은 "합리적인 규모"로 "일반적인 애플리케이션"에 ML을 사용하는 회사들입니다.
- "일반적인 애플리케이션": 사기 탐지, 이탈 예측, 추천 시스템 등.
- "합리적인 규모":
  - 페타바이트가 아닌 기가바이트(gigabytes) 및 테라바이트(terabytes) 단위의 데이터로 작업합니다.
  - 데이터 사이언스 팀이 수천 명이 아닌 10명에서 수백 명의 엔지니어를 보유하고 있습니다.
- 이 회사들은 점점 더 표준화되고 상용화된 일반화된 ML 인프라를 사용하여 이점을 얻을 것입니다.
- 이 장은 이와 같은 회사들의 인프라 요구 사항에 초점을 맞춥니다.

레이어 1: 스토리지와 컴퓨트

스토리지 레이어

데이터 저장 비용이 매우 저렴해져서 대부분의 회사는 보유한 모든 데이터를 그냥 저장합니다. 스토리지 레이어에 대한 모든 세부 사항은 3장 - 데이터 엔지니어링 기초에서 논의했으므로 여기서 반복하지 않겠습니다.

이 섹션의 나머지 부분은 컴퓨트 레이어에 초점을 맞출 것입니다.

컴퓨트 레이어

컴퓨트 레이어의 두 가지 일반적인 용도가 있습니다.
- 작업(jobs) 실행. 이 경우, 컴퓨트 유닛은 작업 기간 동안만 존재할 수 있습니다.
- Jupyter 노트북 또는 기타 탐색적 작업 실행. 이 경우, 컴퓨트 유닛은 오래 지속되는(long-lived) 경향이 있습니다. 이는 보통 가상 머신(virtual machines) 또는 인스턴스(instances)라고 불립니다.
가장 일반적으로, 회사의 컴퓨트 레이어는 AWS Elastic Cloud나 GCP와 같은 관리형 클라우드 서비스입니다.
가장 최소한의 컴퓨트 레이어는 모든 계산을 실행하는 단일 CPU 또는 단일 GPU일 것입니다.
- 일부 컴퓨트 레이어 프레임워크는 코어(cores)의 개념을 추상화하고 다른 계산 단위를 사용합니다. 예를 들어 Spark 및 Ray와 같은 엔진은 "작업(job)"을 단위로 사용합니다. Kubernetes는 "파드(pod)"를 가장 작은 배포 가능 단위로 사용합니다.
컴퓨트 유닛은 일반적으로 메모리와 연산 속도라는 두 가지 지표로 특징지어집니다.
- 메모리: 작업을 실행하려면, 유닛은 먼저 필요한 데이터를 메모리에 로드해야 합니다. 총 메모리는 유닛이 처리할 수 있는 데이터 양을 결정합니다. 데이터를 메모리로 로드하고 언로드하는 속도 또한 총 작업 시간에 상당한 영향을 미칠 수 있습니다. 이것이 클라우드 제공업체가 "고대역폭 메모리(high bandwidth memory)"를 갖춘 특별한 인스턴스를 제공하는 이유입니다.
- 연산 속도: 이를 측정하는 정확한 방법은 논쟁의 여지가 있으며 클라우드 제공업체 간에 통일되어 있지 않습니다.
  - 가장 일반적인 지표는 FLOPS (초당 부동 소수점 연산)입니다.
    - 단일 "부동 소수점 연산"으로 간주되어야 하는 것이 모호하기 때문에 논쟁의 여지가 있습니다.
    - 또한, 유닛의 정격 FLOPs의 100% 활용률(utilisation rate)을 달성하는 것은 거의 불가능합니다. 50%도 좋다고 간주될 수 있습니다. 활용률은 데이터를 메모리로 로드하는 속도에 따라 달라집니다.
  - MLPerf는 하드웨어 성능을 측정하는 인기 있는 벤치마크입니다. 이는 하드웨어가 일반적인 ML 작업을 학습하는 데 걸리는 시간을 측정합니다.

퍼블릭 클라우드 VS 사설 데이터 센터

ML 유스케이스는 ML 워크로드가 폭발적(bursty)이기 때문에 퍼블릭 클라우드를 사용하는 경향이 있습니다. 즉, 작업 폭증 기간에만 컴퓨트 비용을 지불하고 리소스를 해제할 수 있습니다.
- 클라우드 컴퓨트는 탄력적이지만 마법은 아닙니다. 실제로는 무한한 컴퓨팅 파워를 가지고 있지 않으며 대부분의 클라우드 제공업체는 계정에 제한을 둡니다. 종종 그들에게 연락하여 이러한 제한을 늘릴 수 있습니다.
초기에는 퍼블릭 클라우드를 사용하는 것이 자체 스토리지 및 컴퓨트 레이어를 구매하는 것보다 회사에 더 높은 수익을 주는 경향이 있습니다. 그러나 회사가 성장함에 따라 이는 덜 정당화됩니다.
- a16z 연구에 따르면 클라우드 지출은 대기업의 수익 비용(cost of revenue)의 약 50%를 차지합니다.
- 높은 클라우드 비용으로 인해 대기업들은 워크로드를 자체 데이터 센터로 다시 옮기기 시작했습니다. 이를 클라우드 본국 회귀(cloud repatriation)라고 합니다.
  - 클라우드로 들어가는 것은 쉽지만 벗어나는 것은 매우 어렵습니다. 클라우드 본국 회귀는 하드웨어와 엔지니어링 노력 모두에 상당한 초기 투자가 필요합니다.

멀티 클라우드 전략

멀티 클라우드는 각 제공업체의 최고 및 가장 비용 효율적인 기술을 활용하고 벤더 종속(vendor lock-in)을 피하기 위해 여러 클라우드 제공업체를 사용하도록 시스템을 설계하는 것을 의미합니다.
- ML 워크로드의 일반적인 패턴은 GCP나 Azure에서 학습을 수행한 다음 AWS에서 배포하는 것입니다. 이것이 반드시 좋은 패턴은 아닙니다.
멀티 클라우드 전략에서 온전함(sanity)을 유지하는 것은 매우 매우 어렵습니다.
- 클라우드 간에 데이터를 이동하고 워크로드를 오케스트레이션(orchestrate)하는 것은 매우 어렵습니다.
종종 조직의 다른 부분이 독립적으로 운영되고 다른 선택을 하기 때문에 멀티 클라우드는 우연히 발생합니다.
- 또한 ML 회사가 특정 클라우드에 이해관계가 있는 당사자로부터 투자를 받고 해당 다른 클라우드를 채택하도록 "강요"받아 멀티 클라우드 구성이 되는 것도 드문 일이 아닙니다.

레이어 4: 개발 환경

개발 환경(dev environment)은 업계에서 심각하게 과소평가되고 투자가 부족합니다. 일부 전문가는 인프라의 한 부분만 잘 설정할 시간이 있다면, DEV 환경을 선택해야 한다고 제안합니다. 여기서 이루어진 모든 개선 사항은 직접적으로 생산성 향상으로 이어지기 때문입니다.

DEV 환경 전체는 IDE, 노트북, 버전 관리 및 실험 추적 도구, CI/CD 도구로 구성됩니다. 2023년 현재, 회사들은 여전히 강력한 업계 표준 없이 이러한 각각에 대해 임시방편(ad-hoc)의 도구 세트를 사용하고 있습니다.

이 섹션에서는 개발 환경의 3가지 측면을 다룹니다.

개발 환경의 표준화.
DEV 환경에서의 노트북 지원
개발과 프로덕션 간의 격차를 줄이기 위한 컨테이너 기술 사용.

개발 환경의 표준화

개발 환경은 전사적이 아니라도 최소한 팀 전체적으로 표준화되어야 합니다. 비표준화(Non-standardisation)는 여러 이점이 있습니다.

서로 다른 사람들이 자신의 머신에 다른 의존성(dependencies)을 설치함으로써 발생하는 문제를 디버깅하는 데 시간을 낭비하고 싶지 않을 것입니다.
서로 다른 설정을 가진 사람들이 환경에 무엇이 잘못되었는지 파악하는 것을 돕는 IT 지원 업무를 떠맡고 싶지 않을 것입니다.
신규 직원에게 표준 개발 환경으로 가능한 한 "플러그 앤 플레이(plug and play)" 경험을 제공하고 싶을 것입니다.

도구와 패키지는 표준화되어야 한다는 데 일반적으로 동의합니다. 그러나 많은 회사가 IDE 자체를 표준화하는 것을 주저합니다. IDE 설정은 매우 개인적인 경향이 있으며 엔지니어는 자신의 작업 스타일에 맞게 IDE를 커스터마이징(customising)하는 데 많은 노력을 기울입니다.

이러한 상충되는 생각에 대한 가장 인기 있는 해결책은 도구와 패키지 표준화를 처리하기 위해 클라우드 개발 환경을 사용하고, 개발자가 클라우드 개발 환경에 연결되어 있는 한 선호하는 IDE를 무엇이든 사용하도록 허용하는 것입니다.

로컬에서 클라우드 개발 환경으로 이동하기

클라우드 개발 환경의 일반적인 제공업체는 Github Codespaces, AWS EC2 인스턴스, GCP 인스턴스입니다.
로컬 개발 환경과 비교할 때, 클라우드 개발 환경은 다음과 같은 이점이 있습니다.
1. 비용 관리: 개발자가 비싼 VM을 계속 실행해 두면 어쩌나 걱정할 수 있습니다. 일부 VM은 매우 저렴하며 대부분의 클라우드 제공업체는 VM이 30분 동안 사용되지 않으면 "자동 꺼짐" 옵션을 허용합니다. 또한 일부 제공업체는 예산 상한선 및 비용 모니터링을 허용합니다.
2. 적절한 작업에 적절한 크기의 VM 확보: 클라우드 인스턴스를 개발용으로만 사용하고 코드를 다른 컴퓨팅 리소스로 "작업화된(jobified)" 방식으로 실행할 것이라면, 코딩을 지원하기 위한 아주 작은 인스턴스만 사용할 수 있습니다. 무거운 탐색적 분석을 수행하는 경우 더 강력한 머신을 스핀업(spin up)할 수 있습니다. 자세한 내용은 "컴퓨트 레이어"를 참조하십시오.
3. IT 지원이 쉬워집니다. 문제 해결(troubleshoot)을 위한 개발 환경 설정이 하나뿐입니다.
4. 클라우드 개발은 원격 근무에 편리합니다.
5. 클라우드 환경은 보안에 도움이 됩니다. 직원 노트북을 도난당하면 접근 권한을 취소하면 됩니다.
6. 이미 프로덕션을 위해 클라우드를 사용하고 있다면, 개발을 위해 클라우드를 사용하는 것이 자연스럽게 다가올 것이며 개발과 프로덕션 간의 격차를 줄이는 데 도움이 될 것입니다.
클라우드 개발 환경으로 이동하려면 약간의 초기 투자가 필요하며, 클라우드에 대한 보안 연결 설정, 보안 규정 준수 또는 낭비적인 클라우드 사용 방지를 포함하여 데이터 사이언티스트에게 클라우드 위생(hygiene)에 대해 교육해야 할 수도 있습니다. 그러나 장기적으로는 비용을 절약할 수 있습니다.
위에서 언급한 비용 문제나 클라우드 제공업체로 데이터를 이동하는 것에 대한 제한 때문에 모든 회사가 클라우드 개발 환경으로 이동할 수 있는 것은 아닙니다.

IDE와 클라우드 개발 환경

이에 접근하는 세 가지 일반적인 방법이 있습니다.

VIM과 같은 터미널 기반 IDE를 클라우드 머신에 직접 설치합니다.
1. 장점: 모든 것이 클라우드 머신에 있어 네트워킹과 SSH 연결을 다룰 필요가 없습니다.
2. 단점: 터미널 기반 IDE는 강력하게 만들려면 많은 커스터마이징이 필요합니다. 이 커스터마이징은 개발자가 파악해야 할 몫이며 한 VM에서 다른 VM으로 이전하기(port) 어려울 수 있습니다.
클라우드 머신에 연결된 브라우저 기반 IDE를 사용합니다. 일부 인기 있는 옵션은 AWS의 Cloud9과 브라우저의 VSCode입니다.
1. 장점:
  1. 옵션 1에 비해 브라우저 기반 IDE는 더 강력하고 사용자 친화적이며 기본적으로(out of the box) 더 적은 커스터마이징이 필요합니다.
  2. AWS Cloud 9이나 Github Codespaces와 같이 클라우드 제공업체가 제공하는 브라우저 기반 옵션은 "그냥 작동합니다".
2. 단점:
  1. 브라우저 IDE는 네이티브 IDE보다 덜 강력한 경향이 있습니다.
  2. 느리고 지연되는(laggy) 느낌이 드는 경향이 있습니다.
  3. 커스터마이징할 경우, 한 VM에서 다른 VM으로의 이전성(portability)도 문제입니다.
로컬 IDE를 사용하고 SSH를 사용하여 클라우드 VM에 연결합니다. 이 하이브리드 구성에서 로컬 IDE는 "에디터 UI"만 제공하지만 코드는 여전히 VM에서 실행됩니다. 로컬 VSCode는 원격 머신 연결 기능이 내장되어 있어 이 옵션으로 매우 인기가 있습니다.
1. 장점:
  1. 코드 스캔 및 디버깅을 포함하여 IntelliJ와 같은 IDE의 모든 기능을 얻을 수 있습니다.
  2. IDE 커스터마이징이 로컬 컴퓨터에 남아 있으며 "컴퓨트" VM을 교체해도 잃어버리지 않습니다.
2. 단점:
  1. 설정하기 까다로울 수 있습니다. 특히 VM 네트워크가 매우 잠겨(locked down) 있는 경우 더욱 그렇습니다.
  2. 원격 개발 기능이 내장된 IDE로 제한됩니다.

DEV 환경에서의 노트북 지원

ML 엔지니어링은 소프트웨어 엔지니어링의 일반적인 "프로덕션에서 실행할 코드 빌드" 운영 모드 외에, 데이터 및 학습 결과의 탐색적 분석이라는 추가적인 "운영 모드"를 가집니다. 이 분석은 일반적으로 프로덕션에서 실행될 의도가 아닌 일회성 노트북(once-off notebooks)을 사용하여 임시방편(ad-hoc)으로 수행되는 경향이 있습니다.

참고: 노트북을 프로덕션 코드의 주요 수단(vessel)으로 사용하는 회사가 많습니다. 이 관행은 빠르게 시작하게 해줄 것이며 비즈니스 분석을 위해 ML을 사용한다면 필요한 전부일 수 있습니다. 그러나 이 관행은 유스케이스가 더 복잡해짐에 따라 확장되지(scale) 않습니다.

이러한 추가적인 "운영 모드"를 감안할 때, 개발 환경에서 원활한 노트북 지원은 필수입니다. 특히 다음 사항을 고려할 수 있습니다.

개발 환경에서 작업을 수행하기에 충분한 인프라 리소스와 필요한 모든 의존성에 접근할 수 있는 원격 머신에서 노트북을 쉽게 시작할 수 있어야 합니다.
개발 환경에서 데이터 사이언티스트가 이미 실행된 노트북을 쉽게 공유하고 협업할 수 있어야 합니다.
- 노트북 버전 관리는 여전히 번거로운(clunky) 프로세스입니다. 노트북을 Git에 체크인할 수 있지만, 얻게 될 diff는 따라가기 어려운 모호한 JSON입니다.

노트북 개발 경험을 더 좋게 만들기 위해 사용할 수 있는 몇 가지 도구는 다음과 같습니다.

Papermill: 다른 파라미터 세트로 여러 노트북을 스폰(spawn)할 때 사용합니다. 예를 들어, 다른 파라미터 세트로 다른 실험을 실행하고 동시에 실행하려 할 때입니다.
Commuter: 조직 내에서 노트북을 보고, 찾고, 공유하기 위한 노트북 허브입니다.
Nbdev: 소프트웨어 패키지와 기술 문서를 모두 노트북 한 곳에서 작성, 테스트, 문서화 및 배포합니다.

개발에서 프로덕션으로: 컨테이너

여러 엔지니어를 위해 개발 환경을 복제하고 여러 작업 워커(worker)나 VM을 위해 프로덕션 환경을 복제하는 것은 근본적으로 동일한 과제를 안고 있습니다. 새 인스턴스를 설정할 때마다 코드를 실행할 수 있도록 해당 인스턴스에 모든 의존성, 도구 및 구성을 설정해야 합니다.

컨테이너 기술은 이 문제를 자동화된 방식으로 해결하는 열쇠입니다. 현재 가장 인기 있는 컨테이너 기술은 Docker입니다. 다음은 익숙해져야 할 핵심 Docker 개념 중 일부입니다.

Dockerfile: 코드가 실행될 수 있는 환경을 재생성하는 방법에 대한 단계별 파일입니다. 이 패키지를 설치하고, 이 사전 학습된 모델을 다운로드하고, 이 환경 변수를 설정하고, 이 폴더로 이동하십시오. Dockerfile을 빌드(Building)하면 Docker 이미지가 생성됩니다. Dockerfile을 틀(mold)을 구성하는 레시피로, Docker 이미지를 그 틀 자체로 생각할 수 있습니다.
1. Dockerfile 지침을 처음부터 시작할 필요는 없습니다. 다른 Docker 이미지와 동일한 지점에서 시작하도록 지정한 다음, 그 위에 몇 가지 사용자 지정 지침만 추가할 수 있습니다. 예를 들어, NVIDIA는 GPU에서 Tensorflow를 실행하도록 이미 구성된 Docker 이미지를 제공합니다. Dockerfile에서 해당 이미지로 시작하도록 지정한 다음, 사용자 지정 Tensorflow 코드를 설정할 수 있습니다.
2. Dockerfile을 Docker 이미지로 바꾸는 핵심 명령어는 docker build입니다.
Docker 이미지: Docker 컨테이너의 실행 준비가 된 전구체(precursor)입니다. 이 아티팩트(artefact)는 실행에 필요한 모든 것을 내부에 패키징합니다 (예: 모든 의존성과 코드를 이미 다운로드하고 설치함). Docker 이미지는 Dockerfile build의 스냅샷입니다. Docker 이미지는 여러 Docker 컨테이너를 스핀업(spin up)하기 위한 "틀"로 사용됩니다.
Docker 컨테이너: Docker 이미지의 "실행 중인 인스턴스"입니다.
1. 이미지를 수동으로 실행하는 명령어는 docker run입니다.
2. 머신에서 실행 중인 컨테이너를 확인하려면 docker ps를 사용합니다.
컨테이너 레지스트리(Container registry): Docker 이미지를 위한 Github와 같습니다. 컨테이너 레지스트리는 Docker 이미지를 다른 사람들과 공유하는 데 사용됩니다. 레지스트리는 (Docker Hub처럼) 공개적이거나, (GCP 또는 AWS 컨테이너 레지스트리처럼) 조직 내부 사람들만 사용할 수 있도록 비공개(private)일 수 있습니다.
1. 레지스트리에서 컴퓨터로 이미지를 가져오려면(pull) docker pull을 사용합니다.
Docker Compose는 다중 컨테이너 Docker 애플리케이션을 정의하고 실행하기 위한 도구입니다. docker-compose.yml이라는 단일 파일에 애플리케이션을 구성하는 서비스를 정의한 다음, 단일 명령어로 모든 서비스를 시작, 모니터링 및 중지할 수 있습니다. Docker Compose는 단일 호스트(SINGLE HOST)에서 컨테이너를 관리할 수 있는 경량 컨테이너 오케스트레이터입니다.
Kubernetes / K8s: 여러 호스트(MULTIPLE HOSTS)에서 실행되는 다중 컨테이너 애플리케이션을 관리하기 위한 또 다른 오케스트레이터입니다. K8s는 또한 그들 사이의 네트워킹 관리도 처리합니다.
1. K8s는 가장 데이터 사이언스 친화적인 도구는 아니며, 데이터 사이언스 워크로드를 K8s에서 벗어나게 하는 방법에 대한 논의가 진행 중입니다.

단일 ML 프로젝트에 여러 유형의 Docker 이미지가 필요한 것은 일반적입니다. 예를 들어, 학습 데이터에서 피처를 추출하는 것과 같은 CPU 전용 작업을 위해 빌드된 이미지 하나와, 학습을 위한 모든 GPU 구성을 갖춘 두 번째 이미지가 있을 수 있습니다.

레이어: 2 리소스 관리

몇 가지 용어: Cron, 스케줄러, 오케스트레이터

Cron: 고정된 시간에 반복적인 작업을 실행합니다. Cron은 하나의 작업만 처리할 수 있으므로 서로 의존하는 작업 시퀀스를 처리할 수 없습니다.
스케줄러(Schedulers): 의존성을 처리할 수 있습니다.
- 실행할 단계의 DAG 워크플로우를 입력으로 받습니다. 일부 단계는 조건부일 수 있습니다.
- 예약된 간격으로 워크플로우를 시작하거나 이벤트가 발생할 때 워크플로우를 트리거할 수 있습니다.
- 스케줄러를 사용하면 단계가 실패하거나 성공할 때 수행할 작업을 지정할 수 있습니다. 예를 들어, 포기하기 전에 5번 재시도합니다.
- 스케줄러 스크립트는 종종 워크플로우 실행에 필요한 인프라에 대한 파라미터를 입력으로 받습니다. 이들은 워크플로우에 어떤 리소스가 필요한지는 알지만, 어디서 가져와야 하는지는 모릅니다.
- 거의 모든 수의 동시 머신과 워크플로우를 관리할 수 있어야 하므로, 범용 스케줄러를 직접 설계하는 것은 어렵습니다.
- 스케줄러는 일반적으로 작업(jobs)과 단계(steps)를 주요 추상화(abstractions)로 다룹니다.
오케스트레이터(Orchestrators): 워크플로우를 실행하기 위해 리소스를 어디서 가져올지에 관심이 있습니다. 이들은 머신, 인스턴스, 클러스터, 복제(replication)와 같이 "작업" 수준보다 낮은 추상화를 다룹니다.
- 오케스트레이터는 스케줄러가 풀(pool)에 사용 가능한 인스턴스보다 더 많은 작업을 가지고 있음을 감지하면, 풀의 인스턴스 수를 늘릴 수 있습니다.
- 가장 잘 알려진 오케스트레이터는 Kubernetes입니다.
- 스케줄러는 일반적으로 오케스트레이터 위에서 실행됩니다.
워크플로우 관리자(Workflow managers): 일반적으로 스케줄러 + 오케스트레이터를 포함하는 더 높은 수준의 도구입니다. 데이터 사이언티스트는 보통 이들과 상호작용합니다.
- 이들도 작업의 DAG를 입력으로 받습니다.

데이터 사이언스를 위한 워크플로우 관리

2023년 2월 기준, 데이터 사이언스를 위한 5가지 가장 일반적인 워크플로우 관리자는 Airflow, Argo, Prefect, Kubeflow, Metaflow입니다. 이 섹션에서는 각각을 간략하게 살펴보겠습니다.

Airflow

가장 초기의 워크플로우 관리자 중 하나입니다.

장점
- 다양한 클라우드 제공업체, 데이터베이스, 스토리지 옵션 등과 작업할 수 있는 광범위한 오퍼레이터(operators) 라이브러리를 보유하고 있습니다.
- YAML이나 다른 선언적 언어를 사용하는 대신 Python을 사용하여 워크플로우를 구성합니다.
단점
- Airflow는 모놀리식(Monolithic)이어서 전체 워크플로우를 하나의 컨테이너에 패키징합니다. 워크플로우의 2가지 다른 단계가 다른 인프라 요구 사항을 가질 경우, 이들을 위한 별도의 컨테이너를 만드는 것이 간단하지(non-trivial) 않습니다.
- Airflow에서는 DAG에 파라미터를 전달할 수 없습니다.
- Airflow의 DAG는 필요에 따라 런타임에 새 단계를 자동으로 생성할 수 없습니다. 정적(static)입니다.

Prefect

Airflow의 단점에 대한 대응으로 나왔습니다.

장점
- Prefect의 워크플로우에 파라미터를 전달할 수 있습니다.
- 런타임에 동적으로 단계를 생성할 수 있습니다.
- 또한 DAG를 생성하기 위해 Python을 사용합니다.
단점
- Prefect에서 다른 컨테이너를 사용하여 다른 단계를 실행하는 것은 쉽지 않습니다. 할 수는 있지만, 약간의 번거로움이 따릅니다.

Argo

또한 Airflow의 단점에 대한 대응으로 나왔습니다.

장점
- Argo 워크플로우의 모든 단계는 자체 컨테이너에서 실행될 수 있습니다.
단점
- 워크플로우가 YAML로 정의되어 지저분해집니다.
- Argo는 일반적으로 프로덕션에서만 사용 가능한 Kubernetes에서만 실행됩니다. 워크플로우를 로컬에서 테스트하려면 랩톱에 minikube를 설정해야 하는데, 이는 어렵습니다.

Kubeflow와 Metaflow

둘 다 개발 환경과 프로덕션 환경 모두에서 워크플로우를 실행하는 데 도움을 주는 것을 목표로 합니다. 책에서는 더 이상 언급되지 않습니다.

레이어 3: ML 플랫폼

"ML 플랫폼" 공간은 상당히 최근에 생겼으며 2020년대 초반부터 빠르게 성장해 왔습니다. ML 플랫폼을 구성하는 요소의 정의는 회사마다 크게 다릅니다. 그러나 넓게 말하면, ML 플랫폼은 여러 팀이 프로덕션 환경에서 ML 모델을 배포하고 실행하는 데 사용할 수 있는 공유 도구 세트입니다.

이 장에서는 ML 플랫폼의 가장 일반적인 3가지 구성 요소인 모델 호스팅 서비스, 모델 스토어, 피처 스토어를 포함합니다.

모델 호스팅 서비스

모델 호스팅 서비스는 모델과 의존성을 프로덕션으로 푸시(push)하고 모델을 엔드포인트(endpoints)로 노출합니다.
- 이를 지칭하는 다른 방식: 모델 배포 서비스, 모델 서빙 서비스.
이는 ML 플랫폼 구성 요소 중 가장 성숙한 것입니다.
모든 주요 클라우드 제공업체는 모델 호스팅 서비스를 제공합니다. 이를 제공하는 많은 스타트업도 있습니다.
- 예: AWS Sagemaker, GCP Vertex AI, Azure ML, MLflow Models, Seldon, Cortex, Ray Serve
모델 호스팅 서비스를 선택할 때, 온라인 예측과 배치 예측 모두를 수행하기 쉬운지 고려하십시오.
- 모든 도구가 온라인 예측은 수행할 것입니다. 배치 예측이 까다로운 부분입니다.
- 배치 예측은 하드웨어 가속을 사용하여 더 많은 처리량(throughput)을 얻기 위해 온라인 요청을 함께 배치(batching)하는 것과 같지 않습니다.
  - 이상적으로는 모델 호스팅 서비스가 배치 예측과 배치 처리된 온라인 요청(batched online requests)을 모두 수행할 수 있어야 합니다.
- 일부 회사는 온라인 예측과 배치 예측을 위해 서로 다른 모델 호스팅 서비스를 사용합니다. 예를 들어, 온라인에는 Seldon, 배치에는 Databricks를 사용합니다.
모델 호스팅 서비스를 선택할 때, 해당 서비스가 관심 있는 유형의 프로덕션 테스트를 쉽게 실행할 수 있게 하는지 고려하십시오. 프로덕션 테스트에 대한 자세한 내용은 9장을 참조하십시오.

모델 스토어

모델 스토어는 표면적으로 간단해 보이기 때문에 종종 간과됩니다. 모델 블롭(blob)을 S3에 업로드하면 끝입니다.

실제로는, 모델을 운영, 디버깅, 유지보수하는 데 도움이 되도록 블롭과 함께 더 많은 정보를 저장해야 할 것입니다. 다음은 저장할 수 있는 몇 가지 요소입니다. 더 포괄적인 목록은 모델 카드 섹션에서 찾을 수 있습니다.

모델 정의: 레이어 및 손실 함수와 같은 모델 아키텍처에 대한 세부 정보.
모델 파라미터: 모델의 실제 가중치. 대부분의 프레임워크는 모델 정의와 가중치를 함께 저장할 수 있게 합니다.
피처화 및 예측 함수: 예측을 위한 피처를 추출하고 예측을 처리하는 함수.
의존성: 모델 실행에 필요한 의존성 목록. 이는 보통 이미지에 패키징됩니다.
데이터: 모델 학습에 사용된 데이터에 대한 포인터. DVC를 사용한다면, 데이터를 생성한 커밋(commit)에 대한 포인터.
모델 생성 코드: 사용된 하이퍼파라미터를 포함하여 모델 생성에 사용된 체크인된 코드에 대한 포인터. 일부 회사는 체크인되지 않은 노트북을 사용하여 모델을 학습시킵니다. 이는 좋은 관행이 아닙니다.
실험 아티팩트: 실험 추적 및 버전 관리 참조.
태그: 모델 검색에 도움이 되는 태그. 예: 모델을 소유한 팀 또는 사람, 해결하는 비즈니스 문제.

대부분의 회사는 이러한 아티팩트의 하위 집합을 저장하지만 전부는 아니며, 다른 장소에 저장할 수 있습니다.

2023년 기준 MLFlow가 가장 인기 있는 모델 스토어이지만, 표준이 되기까지는 아직 갈 길이 멉니다. 이러한 표준의 부재로 인해, 많은 회사가 자체적으로 구축합니다.

피처 스토어

"피처 스토어"는 사람마다 다른 것을 의미하는 함축적인(loaded) 용어입니다. 핵심적으로, 피처 스토어가 해결을 돕는 3가지 주요 문제가 있습니다. 1) 피처 관리, 2) 피처 계산, 3) 피처 일관성.

피처 관리

피처가 여러 모델에 유용한 경우가 많습니다.
피처 스토어는 팀이 피처를 공유하고 발견하며, 해당 피처를 볼 수 있는 사람의 역할과 공유 설정을 관리하는 데 도움이 될 수 있습니다.

피처 계산

일부 피처는 계산 비용이 비쌀 수 있으므로, 한 번 계산하고 일정 기간 캐시(cache)하는 것이 합리적입니다. 이는 단일 피처가 여러 모델에서 사용될 때 특히 유용합니다.
피처 스토어는 피처 계산 수행과 이 계산 결과 저장을 모두 도울 수 있습니다. 이런 점에서 피처 스토어는 피처를 위한 데이터 웨어하우스처럼 작동합니다.

피처 일관성

학습을 위해 과거 데이터에서 피처를 계산하는 파이프라인과 추론을 위해 피처를 추출하는 파이프라인이 서로 다른 것은 버그의 일반적인 원인입니다 (자세한 내용은 7장 참조).
최신 피처 스토어를 사용하면 배치 피처와 스트리밍 피처 모두에 대한 로직을 통합하여, 학습 시점과 추론 시점의 피처 간 일관성을 보장할 수 있습니다.

벤더 예시

피처 스토어는 2020년에 주목받기 시작했으므로, 여러 벤더가 제공하는 것에는 상당한 차이가 있습니다.

2022년 7월 기준, 가장 인기 있는 오픈 소스 피처 스토어는 Feast입니다. 그러나 Feast는 스트리밍 피처가 아닌 배치 피처에 중점을 둡니다.
Tecton은 배치 및 스트리밍 피처를 모두 처리한다고 약속하는 완전 관리형 피처 스토어이지만, 현재 사용자 확보(traction)가 느리고 깊은 통합(deep integration)을 필요로 합니다.
Sagemaker와 Databricks도 피처 스토어에 대한 자체적인 해석을 제공합니다.

빌드(Build) vs 바이(Buy) 결정

빌드 vs 바이 파노라마의 두 가지 극단은 다음과 같습니다.

모든 ML 유스케이스를 엔드투엔드(end-to-end)로 ML 애플리케이션을 제공하는 제공업체에 아웃소싱하는 회사. 이 경우, 그들이 필요로 하는 유일한 인프라는 애플리케이션에서 벤더로 데이터를 이동하고 그 반대로 이동하는 것입니다.
다른 극단에는 어떤 유형의 관리형 서비스도 사용할 수 없게 하는 매우 민감한 데이터를 다루는 회사가 있습니다. 이런 회사에서는 모든 인프라를 사내(in-house)에 구축하고 유지보수하며, 심지어 자체 데이터 센터를 가지고 있을 수도 있습니다.

대부분의 회사는 이 두 극단 사이에 위치하며, 일부 구성 요소는 관리형이고 일부는 사내에 있습니다.

CTO의 가장 중요한 임무 중 하나는 벤더/제품 선택입니다. "빌드 vs 바이" 결정은 복잡하고 상황에 따라 크게 달라집니다. 아래에는 그러한 결정을 내릴 때 명심해야 할 몇 가지 요소가 있습니다.

어떤 사람들은 구축하는 것이 구매하는 것보다 저렴하다고 생각하지만, 반드시 그런 것은 아닙니다.

빌드 vs 바이를 위한 고려 요소

회사가 처한 단계

초기에는 벤더 솔루션을 활용하여 더 빨리 움직이고 제한된 리소스를 핵심 제품(core offering) 구축에 집중하고 싶을 수 있습니다.
유스케이스가 성장함에 따라 벤더 비용이 엄청나게(exorbitant) 비싸질 수 있으며, 자체 솔루션을 구축하는 것이 더 나을 수 있습니다.

회사의 초점 또는 경쟁 우위라고 믿는 것

고려 중인 플랫폼 구성 요소가 경쟁 우위의 일부이기 때문에 회사가 정말 잘해야 하는 것이라면, 구축하는 쪽으로 기울이십시오. 그렇지 않다면, 구매하는 쪽으로 기울이십시오.
기술 부문 이외의 대다수 회사(소매, 은행, 제조)는 기술 자체가 핵심 제품이 아니므로 구매하는 쪽으로 기우는 경향이 있습니다.
기술 회사의 경쟁 우위는 기술 자체인 경향이 있으므로, 구축하는 쪽으로 기웁니다.

사용 가능한 도구의 성숙도

사용 가능한 벤더가 필요에 비해 충분히 성숙하지 않다면, 직접 구축해야 할 수도 있습니다.
- 여기서 좋은 옵션은 오픈 소스 솔루션을 기반으로 구축하는 것입니다.
여러분이 ML 플랫폼 구성 요소를 판매하는 벤더라면, "통합 지옥(integration hell)"에 빠질 수 있으므로 빅테크 기업에 판매하는 것을 피하십시오. 그들의 요구는 여러분의 솔루션에 비해 너무 성숙할 수 있으며, 결국 무한한 따라잡기 게임을 하게 될 것입니다.

도구가 클라우드 제공업체와 작동하는가?

선호하는 벤더가 클라우드 제공업체와 작동하는지 또는 자체 데이터 센터에서 서비스를 사용할 수 있는지 확인하십시오. 선택한 도구가 클라우드 제공업체와의 통합을 제공하기를 바랄 것입니다. 도구를 얻기 위해 새로운 클라우드 제공업체를 채택해야 하는 것을 좋아하는 사람은 없습니다.

오픈 소스가 당신에게 옵션인가?

오픈 소스는 처음부터 구축하지 않아도 되며 직접 호스팅(host)할 것임을 의미합니다 (보안 및 개인 정보 보호에 대해 덜 우려함). 그러나 여전히 유지보수해야 합니다.

관리형 서비스라면 유지보수 부담이 줄어듭니다. 그러나 보안 및 개인 정보 보호 문제가 있을 수 있는 제공업체에 일부 데이터를 보내야 할 수도 있습니다.

일부 관리형 서비스는 가상 사설 클라우드(virtual private clouds)에서 호스팅할 수 있게 하여 보안 우려를 덜어줍니다.

11장 - 머신 러닝의 인적 측면

ML에서의 사용자 경험 (UX)

소프트웨어 시스템과 ML 시스템이 어떻게 다른지 길게 논의했습니다. 이는 ML 시스템에는 고려해야 할 추가적인 UX 과제가 있음을 의미합니다. 이 섹션은 이러한 과제 중 3가지를 다룹니다.

과제 1: 사용자 경험 일관성 보장

ML 시스템은 서로 다른 시점에 동일한 사용자에게 다른 예측을 제공할 수 있습니다. 예측의 변경은 사용자에게 시스템의 UX가 망가진(broken) 것처럼 느끼게 할 수 있습니다.
예측이 때때로 변경될 수 있는 몇 가지 이유가 있습니다.
- ML 시스템은 본질적으로 확률적(probabilistic)입니다. 이는 주어진 사용자가 매번 동일한 예측을 받을 것이라는 보장이 없음을 의미합니다.
- 시스템이 서로 다른 시점에 사용자에 대한 다른 정보를 가질 수 있으며, 이로 인해 다른 예측이 발생할 수 있습니다.
ML 시스템을 위한 UX를 설계할 때 일관성-정확도 트레이드오프(consistency-accuracy trade-off)를 고려해야 합니다.
- 사용자에게 일관되지 않은 동작을 감수하고 가장 정확한 / 업데이트된 예측을 제공하도록 결정할 수도 있고, 또는 일관성을 보장하기 위해 어떤 규칙을 사용하여 예측이 무엇이었는지 "기억하고 고정"하도록 결정할 수도 있습니다.

과제 2: "대부분 올바른" 예측 대응

"대부분 올바른(mostly correct)" 예측은 ML 시스템이 "대부분 올바르거나" "올바르게 보이지만" 올바르다고 보장할 수는 없는 예측을 생성할 때입니다.
해당 도메인의 전문 사용자는 예측의 어느 부분이 잘못되었는지 식별하고 수정할 수 있습니다. 비전문 사용자는 식별할 충분한 지식이 없을 수 있으며 주어진 예측을 올바른 것으로 잘못 받아들일 수 있습니다.
이는 대규모 언어 모델(LLM)에서 매우 일반적입니다. 예를 들어, LLM에게 문제 해결을 위한 Java 코드를 생성하도록 요청하면, 그럴듯한(plausible) Java처럼 보이는 코드를 출력할 것입니다.
- 숙련된 프로그래머는 예측된 코드를 빠르게 읽고, 작동하도록 몇 가지를 수정하여 사용할 수 있습니다.
- 경험이 없는 프로그래머는 코드가 잘못되었더라도 "있는 그대로" 사용하려고 시도할 수 있습니다.
"대부분 올바른" 예측을 생성하는 시스템은 전문 사용자에게는 엄청난 시간 절약기(time saver)가 될 수 있습니다. 사용자가 이런 유형이라면 UX 고민은 단순해집니다.
더 어려운 UX 과제는 예측이 여전히 유용하면서도 액면 그대로(at face value) 받아들여지지 않도록 비전문 사용자에게 "대부분 올바른" 예측을 올바르게 제시하는 방법입니다.
일반적인 접근 방식은 사용자에게 동일한 입력으로부터 여러 예측을 보여주어 그중 적어도 하나가 올바를 가능성을 높이는 것입니다.
- 비전문 사용자를 다루는 경우, 예측은 그들이 변형(variants)을 평가할 수 있는 방식으로 렌더링(render)되어야 합니다. 예를 들어, 모델의 출력이 HTML 대안이라면 각각을 렌더링하십시오.
- 이 접근 방식은 때때로 "휴먼 인 더 루프(human-in-the-loop)"라고도 합니다. Chip은 이 주제에 대한 더 많은 정보를 위해 "Rethinking Human-AI interaction" By Jessy Lin을 읽어볼 것을 권장합니다.

과제 3: 매끄러운 실패 (Smooth Failing)

모델이 아무리 속도를 위해 튜닝되었더라도, (큰 입력과 같은) 특정 조건에서는 모델이 예측을 하는 데 허용할 수 없는 시간이 걸릴 수 있다는 냉정한 진실에 부딪힐 수 있습니다.
- 이는 NLP나 시계열 모델에서 전형적입니다. 텍스트 입력이 클수록 시간이 더 오래 걸립니다.
- 높은 예측 지연 시간은 시스템에 많은 데이터를 가진 고객에게도 발생할 수 있습니다. 그들이 최고의 고객일 수 있으므로 무시하지 마십시오.
이를 해결하기 위해 다음을 수행할 수 있습니다.
- 덜 정확하지만 더 빠른 백업 모델(backup model)을 만듭니다. 이 백업 모델은 1) 휴리스틱 규칙, 2) 더 간단한 모델 또는 3) 더 오래된 데이터로 캐시된 예측일 수 있습니다.
- 백업 모델을 트리거(trigger)하는 방법에 대한 전략을 결정합니다. 이 트리거는 다음일 수 있습니다.
  - 1) 메인 모델에 타임아웃(timeout)을 추가하고 타임아웃에 도달하면 백업으로 폴백(fallback)합니다.
  - 2) 예측을 라우팅하는 휴리스틱 규칙을 추가합니다.
  - 3) 메인 모델에서 계산이 얼마나 걸릴지 예측하는 보조 회귀 모델을 구축합니다. 이렇게 한다면, 회귀 예측의 추론을 고려해야 합니다.
매끄러운 실패는 속도-정확도 트레이드오프(speed-accuracy trade-off)와 관련이 있습니다. 때로는 지연 시간이 중요하기 때문에 더 빠르지만 덜 최적인 모델을 사용하는 것을 선호합니다.
- 기본 + 백업 구성을 사용하면 속도와 정확도를 (어느 정도) 모두 선택할 수 있습니다.

팀 구조

이 섹션에서는 ML 팀을 구성할 때 고려해야 할 팀 구조의 측면을 다룹니다.

SME를 무시하지 마라

SME(Subject Matter Experts, 해당 분야 전문가: 의사, 변호사, 농부, 스타일리스트)는 종종 ML 시스템 설계에서 간과되거나 데이터 레이블링 단계에서만 고려됩니다.

SME를 팀의 일원으로 두거나 최소한 레이블링 단계를 넘어선 모든 단계(문제 공식화, 피처 엔지니어링, 오류 분석, 모델 평가, 사용자 인터페이스 등)에 참여시키는 것을 고려해야 합니다. 그들의 의견은 시스템의 성패를 좌우할 수 있습니다.

SME가 모든 것을 엔지니어링을 통하지 않고도 프로젝트에 기여할 수 있도록 허용하는 것이 중요합니다. 예를 들어, 많은 회사가 SME가 레이블링, 품질 보증(QA), 피드백과 같은 작업을 변경할 수 있도록 노코드(no-code)/로우코드(low-code) 플랫폼을 구축하고 있습니다. 데이터셋 생성 및 문제 조사와 같은 다른 단계를 위한 더 많은 플랫폼이 개발되고 있습니다.

데이터 사이언티스트의 소유권 경계

회사는 데이터 사이언티스트의 "소유권 경계"를 결정할 때 다음 두 가지 접근 방식 중 하나를 따르는 경향이 있습니다.

접근 방식 1: 프로덕션을 관리하는 별도 팀 두기

데이터 사이언티스트 / ML 팀은 개발 환경에서 모델을 개발합니다. 그런 다음 모델은 프로덕션에 적용하고 실행하기 위해 별도 팀(예: Ops/플랫폼 ML 엔지니어링 팀)에 전달됩니다.

장점
- 동시에 여러 기술을 아는 사람을 고용하는 것보다 한 가지 기술을 가진 사람을 고용하는 것이 더 쉽습니다.
- 체인의 자기 부분에만 집중하면 되므로 모든 개인의 삶이 더 쉬워집니다.
단점
- 팀 간의 커뮤니케이션 및 조정 오버헤드.
- 문제가 발생했을 때 누구에게 가야 할지 명확하지 않고 사람들이 서로의 코드에 익숙하지 않기 때문에 디버깅이 어려워집니다. 문제를 디버깅하기 위해 여러 팀을 끌어와야 합니다.
- 문제가 잘못되었을 때 손가락질(finger-pointing)을 조장합니다.
- 모든 사람이 좁은 맥락을 가지고 있으며 아무도 전체 엔드투엔드 프로세스에 대한 가시성을 갖지 못합니다. 이는 아무도 그것을 개선하는 방법에 대한 영향력 있는 제안을 보지 못한다는 것을 의미합니다.

접근 방식 2: 데이터 사이언티스트가 전체 엔드투엔드 프로세스 소유

데이터 사이언티스트 / ML 팀이 모델을 프로덕션화(productionizing)하는 것까지 걱정해야 합니다.

장점
- 위의 단점과 반대.
단점
- 데이터 사이언티스트가 프로덕션에 모델을 적용하는 데 필요한 로우 레벨(low-level) 인프라 기술을 알 것으로 기대하는 것은 불합리합니다.
- 모든 기술을 갖춘 사람을 고용하는 데 정말 어려움을 겪을 수 있습니다.
- 데이터 사이언티스트가 ML 코드보다 인프라 코드를 작성하는 데 더 많은 시간을 할애할 수 있습니다.

잠깐, 두 접근 방식 모두 형편없다면, 어떻게 해야 하는가?

ML 팀이나 데이터 사이언티스트가 전체 프로세스를 엔드투엔드로 소유하는 것이 더 잘 작동합니다. 그러나 이렇게 하려면, 그들이 전문가가 아닌 영역을 다룰 수 있는 좋은 하이 레벨(high-level) 추상화를 제공해야 합니다.

컨테이너화(containerisation), 분산 처리, 자동 장애 조치(failover) 등과 같은 복잡성을 추상화하십시오.

"Netflix 작업 모델"에서는 인프라, 빌드 도구, 배포 파이프라인, 지표 및 대시보딩 (등)과 같은 영역의 전문가가 먼저 프로젝트에 합류하여 자신들의 부분을 자동화하는 도구를 만듭니다. 그런 다음 데이터 사이언티스트 / ML 팀이 해당 도구를 사용하여 프로젝트를 엔드투엔드로 소유합니다.

즉, 프로젝트를 엔드투엔드로 개발할 수 있는 도구를 구축한 다음, 데이터 사이언티스트 / ML 팀이 해당 도구를 사용하여 이터레이션(iterate)하게 하십시오.

책임감 있는 AI를 위한 프레임워크

이 섹션에는 모델이 책임감을 갖도록 보장하기 위해 회사가 채택할 수 있는 프레임워크가 포함되어 있습니다.

다음을 명심하십시오:

이 프레임워크는 모든 유스케이스에 충분하지 않을 수 있습니다. 판단력을 사용하십시오.
사용하는 프레임워크에 관계없이 비윤리적인 AI 애플리케이션이 있습니다 (예: 범죄 형량 결정, 예측 치안(predictive policing)).

모델 편향의 원천 발견

모델을 개발할 때, 모델 편향의 여러 원천을 연구하십시오.

편향은 모델 생성 프로세스의 모든 단계에서 스며들(creep up) 수 있습니다. 다음은 확인해야 할 장소의 일부 목록입니다.

학습 데이터: 데이터가 실제 세계를 대표하지 않는다면, 특정 그룹에 대한 데이터의 존재 또는 부재가 모델이 해당 그룹에 대해 편향되도록 만들 수 있습니다. 비확률적 샘플링을 참조하십시오.
레이블링: 인간 주석가(annotators)가 주석을 달기 위해 주관성에 더 많이 의존할수록, 더 많은 편향이 생길 것입니다. 주석가가 표준 가이드라인을 따르도록 보장하고 생성된 레이블의 품질을 측정하는 방법을 생각해보십시오.
피처 엔지니어링: 모델이 편향을 학습하도록 만들 수 있는 피처를 사용하고 있습니까? 민족, 성별, 인종, 성적 지향, 종교 등과 관련된 피처를 사용하는 것은 편향의 위험이 높기 때문에 일반적으로 권장되지 않습니다. 모델이 이를 간접적으로 추론할 수 있게 하는 피처를 사용하는 것도 위험합니다. 불변성 테스트 및 슬라이스 기반 테스트를 참조하십시오.
모델의 목적(Objective): 목적이 모든 사용자에 대한 공정성을 허용합니까, 아니면 다수 그룹이나 다수 클래스를 선호하는 편향을 도입합니까?
1. 다수 클래스 처리에 대해서는 클래스 불균형을 참조하십시오.
2. 불변성 테스트와 슬라이스 기반 테스트가 다른 그룹에 대해 다른 결과를 표시한다면, 모델 프레이밍이나 목적을 재고할 수 있습니다.
평가: 평가 프로세스가 편향을 도입하고 있습니까?
1. 인간 평가를 사용하여 평가가 수행된다면, 모델은 인간을 통해 편향을 받을 수 있습니다 (위의 레이블링 참조).
2. 평가가 자동으로 수행될 수 있다면, 불변성 테스트 및 슬라이스 기반 테스트를 수행하지 않거나 테스트 중에 특정 그룹을 무시하면 모델이 편향될 수 있습니다.

데이터 기반 접근 방식의 한계 이해

공정성과 책임감 있는 AI에 대한 데이터 기반 접근 방식은 필요하지만 충분하지는 않습니다.

모델 개발자는 예측의 다른 쪽에 있는 사용자의 삶이 예측에 의해 어떻게 영향을 받을지 인간적인 수준에서 이해해야 합니다. 이렇게 함으로써 데이터에 너무 많이 의존함으로써 발생하는 사각지대(blind spots)의 위험을 줄일 수 있습니다.

여러 속성에 대해 모델을 최적화할 때 발생하는 공정성 트레이드오프 이해

종종 ML 문헌은 속성을 최적화하기 위해 모델을 변경할 때 다른 모든 속성은 정적(static)으로 유지된다고 가정합니다. 이는 사실이 아닙니다.

이 가정은 많은 트레이드오프가 아직 발견되지 않았기 때문에 책임감 있는 AI 공간에서 특히 위험합니다.

여기서는 문헌에 기록된 두 가지 예시 트레이드오프를 다룹니다.

프라이버시 vs 정확도 트레이드오프
압축 vs 공정성 트레이드오프

차등적 프라이버시(differentially private)가 적용된 데이터셋이나 압축되고 있는 모델로 작업하는 경우, 의도하지 않은 피해를 피하기 위해 이러한 트레이드오프를 연구하는 데 리소스를 투자해야 합니다.

프라이버시 vs 정확도 트레이드오프

모델이 제공하는 프라이버시 수준이 높을수록, 일반적으로 모델 정확도는 낮아집니다.
차등 프라이버시 모델의 정확도는 과소 표현된(underrepresented) 클래스와 하위 그룹(subgroups)에 대해 훨씬 더 많이 떨어집니다.

압축 vs 정확도 공정성 트레이드오프

모델 압축의 아이디어는 최소한의 정확도 비용으로 모델 크기를 줄이는 것입니다. 이 주제는 7장에서 설명합니다.
압축이 모든 클래스와 하위 그룹에 걸쳐 정확도 손실을 균일하게 "분산"시킬 것이라고 보장할 수 없습니다. 압축은 데이터셋에서 과소 표현된 하위 그룹에 불균형적으로(disproportionally) 영향을 미칠 수 있습니다.
모든 압축 기법이 동일한 수준의 불균형 영향(disparate impact)을 갖는 것은 아닙니다. 가지치기(Pruning)는 양자화(quantisation)보다 훨씬 더 높은 불균형 영향을 초래합니다.
다시 한번, 슬라이스 기반 테스트는 압축의 영향을 연구하는 훌륭한 도구입니다.

조기 행동

ML 시스템 개발 주기 초기에 이 시스템이 사용자 삶에 어떤 영향을 미칠지, 시스템이 어떤 편향을 가질 수 있는지 생각하기 시작할수록, 이러한 편향을 해결하는 비용이 더 저렴해집니다.

모델 카드 만들기

모델 카드는 학습된 모델에 동반되는 짧은 문서로, 어떻게 학습되고 평가되었는지에 대한 정보가 포함됩니다. 또한 의도된 사용 및 알려진 한계와 같은 맥락도 포함합니다. 모델 카드 템플릿은 아래와 같습니다.
모델 카드의 목표는 윤리적 관행을 표준화하고 이해관계자가 성능의 렌즈뿐만 아니라 책임감 있는 AI의 렌즈에서도 후보 모델에 대해 추론할 수 있게 하는 것입니다.
모델 카드는 모델을 배포하고 사용하는 사람과 개발한 사람이 같지 않은 경우에 특히 중요합니다.
모델 카드를 수동으로 만들고 업데이트하는 것은 꽤 지루할(tedious) 수 있습니다. 모델 카드의 가능한 많은 부분을 자동으로 생성할 수 있는 도구에 투자하는 것이 중요합니다. Tensorflow, Metaflow, scikit-learn은 모두 모델 카드를 위한 기능을 가지고 있습니다. 일부 회사는 자체 모델 카드 소프트웨어를 구축합니다.
- Chip은 모델 스토어가 곧 모델 카드를 기본적으로(natively) 지원하고 생성하도록 진화할 것이라고 생각합니다.

모델 카드 예시

모델 세부 정보: 기본 정보
- 모델을 개발하는 사람, 팀 또는 조직
- 모델 날짜
- 모델 버전
- 모델 유형
- 학습 알고리즘, 파라미터, 공정성 제약 조건 및 피처에 대한 정보
- 추가 정보 리소스 (예: 논문, 블로그 게시물)
- 인용 세부 정보
- 라이선스
- 모델에 대한 질문이나 의견을 보낼 곳
의도된 사용
- 주요 의도된 사용자
- 범위 외(Out-of-scope) 유스케이스
요소(Factors): 요소는 인구 통계학적 또는 표현형 그룹, 환경 조건, 기술적 속성 또는 기타를 포함할 수 있습니다.
- #todo: 이것이 무엇인지 명확하지 않음.
- 관련 요소 및 평가 요소
지표(Metrics): 모델의 잠재적인 실제 영향을 반영하도록 선택되어야 합니다.
- 모델 성능 측정
- 결정 임계값(Decision thresholds)
- 변동 접근 방식(Variation approaches)
평가 데이터: 카드에 보고된 정량적 분석에 사용된 데이터셋에 대한 세부 정보.
- 데이터셋
- 동기(Motivation)
- 전처리
학습 데이터: 가능하다면, 위의 평가 데이터 섹션을 미러링(mirror)하십시오.
- 실제로, 학습 데이터를 모델 카드에 포함하는 것이 항상 가능한 것은 아닙니다.
- 데이터 포함이 불가능하다면, 최소한 학습 데이터셋의 다양한 요소에 대한 분포를 포함하십시오.
정량적 분석
- 단일(Unitary) 결과
- 교차(Intersectional) / 슬라이스 기반 결과
윤리적 고려 사항
주의 사항 및 권장 사항

편향 완화를 위한 회사 프로세스 수립

책임감 있는 AI를 구축하는 것은 복잡한 프로세스입니다. 임시방편(Ad-hoc) 프로세스는 오류의 여지를 많이 남깁니다. 회사가 ML 모델을 책임감 있게 만들기 위한 체계적인 프로세스를 수립하는 것이 중요합니다.
일부 회사는 제3자 감사(third-party audits)를 수행합니다.
리소스:
- Google의 책임감 있는 AI 관행
- AI Fairness 360: 모델 및 데이터셋의 편향을 완화하는 데 도움이 되는 알고리즘, 지표, 설명을 포함한 오픈 소스 라이브러리.

책임감 있는 AI에 대한 최신 정보 유지

책임감 있는 AI는 새로운 편향 원천이 지속적으로 발견되고 새로운 기법이 개발되는 빠르게 움직이는 분야입니다.
최신 정보를 유지하는 데 도움이 되는 몇 가지 리소스:

ACM FAccT Conference
Partnership on AI ( 참고: 원문에 링크가 비어있어 기본 주소로 연결 )
Alan Turing Institute's Fairness, Transparency and Privacy Group
AI Now Institute