기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 학습
<a name="training"></a>

MLOps는 ML 수명 주기의 운영과 관련이 있습니다. 따라서 데이터 과학자와 데이터 엔지니어의 작업을 촉진하여 기술 부채 없이 비즈니스 요구 사항을 달성하고 장기적으로 잘 작동하는 실용적인 모델을 만들어야 합니다.

이 섹션의 모범 사례를 따라 모델 훈련 문제를 해결하세요.

**Topics**
+ [기준 모델 생성](#baseline-model)
+ [데이터 중심 접근 방식 및 오류 분석 사용](#error-analysis)
+ [빠른 반복을 위한 모델 설계](#fast-iteration)
+ [ML 실험 추적](#tracking)
+ [훈련 작업 문제 해결](#troubleshooting)

## 기준 모델 생성
<a name="baseline-model"></a>

실무자가 ML 솔루션에서 비즈니스 문제에 직면하는 경우 일반적으로 첫 번째 성향은 state-of-the-art 알고리즘을 사용하는 것입니다. 이 방법은 state-of-the-art 알고리즘이 시간 테스트를 거치지 않았을 가능성이 높기 때문에 위험합니다. 또한 state-of-the-art 알고리즘은 더 복잡하고 잘 이해되지 않는 경우가 많으므로 더 간단한 대체 모델에 비해 약간의 개선만 있을 수 있습니다. 더 좋은 방법은 검증 및 배포가 비교적 빠르고 프로젝트 이해관계자의 신뢰를 얻을 수 있는 기준 모델을 만드는 것입니다.

기준을 생성할 때는 가능하면 지표 성능을 평가하는 것이 좋습니다. 기준 모델의 성능을 다른 자동 또는 수동 시스템과 비교하여 성공을 보장하고 모델 구현 또는 프로젝트를 중장기적으로 제공할 수 있도록 합니다.

ML 엔지니어와 함께 기준 모델을 추가로 검증하여 모델이 추론 시간, 데이터 이동 빈도, 이러한 경우에 모델을 쉽게 재학습할 수 있는지 여부, 솔루션 비용에 영향을 미치는 배포 방법 등 프로젝트에 대해 설정된 비기능적 요구 사항을 제공할 수 있는지 확인해야 합니다. 이러한 질문에 대한 다학제적 관점을 얻어 성공적이고 오래 실행되는 모델을 개발할 가능성을 높입니다.

데이터 사이언티스트는 기준 모델에 가능한 한 많은 기능을 추가할 가능성이 있습니다. 이렇게 하면 원하는 결과를 예측하는 모델의 기능이 향상되지만 이러한 기능 중 일부는 증분 지표 개선만 생성할 수 있습니다. 많은 기능, 특히 상관관계가 높은 기능은 중복될 수 있습니다. 너무 많은 기능을 추가하면 더 많은 컴퓨팅 리소스와 튜닝이 필요하므로 비용이 증가합니다. 데이터 드리프트가 발생할 가능성이 높아지거나 더 빨리 발생하기 때문에 너무 많은 기능은 모델의 day-to-day 작업에도 영향을 미칩니다.

두 입력 특징의 상관관계가 높지만 한 특징만 인과관계가 있는 모델을 생각해 보세요. 예를 들어 대출 기본값이 고객 연령 및 소득과 같은 입력 기능을 가질 수 있는지 예측하는 모델은 상관관계가 높을 수 있지만 대출을 제공하거나 거부하는 데는 소득만 사용해야 합니다. 이 두 기능에 대해 훈련된 모델은 연령과 같은 인과관계가 없는 기능을 사용하여 예측 출력을 생성할 수 있습니다. 프로덕션으로 이동한 후 모델이 훈련 세트에 포함된 평균 연령보다 높거나 낮은 고객에 대한 추론 요청을 수신하면 성능이 저하되기 시작할 수 있습니다.

또한 각 개별 기능은 프로덕션 환경에서 배포 전환을 겪고 모델이 예기치 않게 동작할 수 있습니다. 이러한 이유로 모델이 가진 기능이 많을수록 드리프트 및 노후성과 관련하여 더 취약합니다.

데이터 과학자는 상관관계 측정치와 [Shapley 값을](https://docs.aws.amazon.com/sagemaker/latest/dg/clarify-shapley-values.html) 사용하여 예측에 충분한 값을 추가하는 특성을 측정해야 하며 이를 유지해야 합니다. 이러한 복잡한 모델을 사용하면 모델이 모델링된 환경을 변경하는 피드백 루프의 가능성이 높아집니다. 모델의 권장 사항으로 인해 소비자 동작이 변경될 수 있는 권장 시스템입니다. 모델 간에 작동하는 피드백 루프는 덜 일반적입니다. 예를 들어 영화를 추천하는 추천 시스템과 책을 추천하는 다른 시스템을 고려해 보세요. 두 모델이 동일한 소비자 집합을 대상으로 하는 경우 서로 영향을 미칩니다.

개발하는 각 모델에 대해 이러한 역학에 기여할 수 있는 요인을 고려하여 프로덕션 환경에서 모니터링할 지표를 파악합니다.

## 데이터 중심 접근 방식 및 오류 분석 사용
<a name="error-analysis"></a>

간단한 모델을 사용하는 경우 ML 팀은 데이터 자체를 개선하고 모델 중심 접근 방식 대신 데이터 중심 접근 방식을 취하는 데 집중할 수 있습니다. 프로젝트가 이미지, 텍스트, 오디오 및 사람이 평가할 수 있는 기타 형식과 같은 비정형 데이터를 사용하는 경우(라벨에 효율적으로 매핑하기가 더 어려울 수 있는 정형 데이터와 비교하여) 모델 성능을 개선하는 것이 좋습니다.

오류 분석에는 검증 세트에서 모델을 평가하고 가장 일반적인 오류를 확인하는 작업이 포함됩니다. 이렇게 하면 모델이 제대로 하기 어려울 수 있는 유사한 데이터 샘플의 잠재적 그룹을 식별하는 데 도움이 됩니다. 오류 분석을 수행하려면 예측 오류가 더 높은 추론을 나열하거나, 예를 들어 한 클래스의 샘플이 다른 클래스의 샘플로 예측된 오류를 나열할 수 있습니다.

## 빠른 반복을 위한 모델 설계
<a name="fast-iteration"></a>

데이터 사이언티스트는 모범 사례를 따르면 개념 증명 또는 재학습 중에도 새 알고리즘을 실험하거나 다양한 기능을 쉽고 빠르게 혼합하여 일치시킬 수 있습니다. 이 실험은 프로덕션의 성공에 기여합니다. 모범 사례는 기준 모델을 기반으로 구축하여 약간 더 복잡한 알고리즘을 사용하고 훈련 및 검증 세트의 성능을 모니터링하면서 새로운 기능을 반복적으로 추가하여 실제 동작을 예상 동작과 비교하는 것입니다. 이 훈련 프레임워크는 예측력에서 최적의 균형을 제공하고 기술 부채 발자국이 적으면서 모델을 최대한 단순하게 유지하는 데 도움이 될 수 있습니다.

빠른 반복을 위해 데이터 과학자는 특정 데이터에 사용할 최적의 모델을 결정하기 위해 다양한 모델 구현을 바꿔야 합니다. 대규모 팀, 짧은 기한 및 기타 프로젝트 관리 관련 물류가 있는 경우 메서드가 없으면 빠른 반복이 어려울 수 있습니다.

소프트웨어 엔지니어링에서 [Liskov 대체 원칙](https://en.wikipedia.org/wiki/Liskov_substitution_principle)은 소프트웨어 구성 요소 간의 상호 작용을 설계하기 위한 메커니즘입니다. 이 원칙에는 클라이언트 애플리케이션 또는 구현을 중단하지 않고 인터페이스의 한 구현을 다른 구현으로 바꿀 수 있어야 한다고 명시되어 있습니다. ML 시스템에 대한 훈련 코드를 작성할 때이 원칙을 사용하여 경계를 설정하고 코드를 캡슐화할 수 있으므로 알고리즘을 쉽게 대체하고 새 알고리즘을 더 효과적으로 시도할 수 있습니다.

예를 들어 다음 코드에서는 새 클래스 구현을 추가하여 새 실험을 추가할 수 있습니다.

```
from abc import ABC, abstractmethod

from pandas import DataFrame


class ExperimentRunner(object):

    def __init__(self, *experiments):
        self.experiments = experiments

    def run(self, df: DataFrame) -> None:
        for experiment in self.experiments:
            result = experiment.run(df)
            print(f'Experiment "{experiment.name}" gave result {result}')


class Experiment(ABC):

    @abstractmethod
    def run(self, df: DataFrame) -> float:
        pass

    @property
    @abstractmethod
    def name(self) -> str:
        pass


class Experiment1(Experiment):

    def run(self, df: DataFrame) -> float:
        print('performing experiment 1')
        return 0

    def name(self) -> str:
        return 'experiment 1'


class Experiment2(Experiment):

    def run(self, df: DataFrame) -> float:
        print('performing experiment 2')
        return 0

    def name(self) -> str:
        return 'experiment 2'


class Experiment3(Experiment):

    def run(self, df: DataFrame) -> float:
        print('performing experiment 3')
        return 0

    def name(self) -> str:
        return 'experiment 3'


if __name__ == '__main__':
    runner = ExperimentRunner(*[
        Experiment1(),
        Experiment2(),
        Experiment3()
    ])
    df = ...
    runner.run(df)
```

## ML 실험 추적
<a name="tracking"></a>

많은 실험을 수행할 때는 개선 사항이 구현된 변경 사항의 결과인지 아니면 가능성인지 판단하는 것이 중요합니다. [Amazon SageMaker AI Experiments](https://aws.amazon.com/blogs/aws/amazon-sagemaker-experiments-organize-track-and-compare-your-machine-learning-trainings/)를 사용하여 실험을 쉽게 생성하고 메타데이터를 추적, 비교 및 평가하기 위해 실험과 연결할 수 있습니다.

모델 빌드 프로세스의 무작위성을 줄이는 것은 동일한 코드와 데이터를 고려하여 보다 확실하게 출력 모델 추론을 예측할 수 있으므로 거버넌스를 디버깅, 문제 해결 및 개선하는 데 유용합니다.

무작위 가중치 초기화, 병렬 컴퓨팅 동기화, 내부 GPU 복잡성 및 유사한 비결정적 요인으로 인해 훈련 코드를 완전히 재현할 수 없는 경우가 많습니다. 그러나 무작위 시드를 올바르게 설정하여 각 훈련 실행이 동일한 지점에서 시작되고 유사하게 작동하도록 하면 결과 예측 가능성이 크게 향상됩니다.

## 훈련 작업 문제 해결
<a name="troubleshooting"></a>

경우에 따라 데이터 사이언티스트가 매우 간단한 기준 모델에도 맞추기가 어려울 수 있습니다. 이 경우 복잡한 함수에 더 잘 맞는 알고리즘이 필요하다고 결정할 수 있습니다. 좋은 테스트는 데이터세트의 매우 작은 부분(예: 약 10개의 샘플)의 기준을 사용하여 알고리즘이이 샘플에 과적합하도록 하는 것입니다. 이렇게 하면 데이터 또는 코드 문제를 배제하는 데 도움이 됩니다.

복잡한 시나리오를 디버깅하는 데 유용한 또 다른 도구는 [Amazon SageMaker AI 디버거](https://docs.aws.amazon.com/sagemaker/latest/dg/train-debugger.html)입니다.이 도구는 최적의 컴퓨팅 사용량과 같은 알고리즘 정확성 및 인프라와 관련된 문제를 캡처할 수 있습니다.