MLOps 수준 1 의 목표는 ML 파이프라인을 자동화 하여 모델을 지속적으로 학습시키는 것이다
수준 0 과 비교해서 많은 것이 생긴것 같다 천천히 살펴보자
1. 수준 0 에서 Manual experiment steps 였던 데이터 검증, 전처리, 학습, 평가 등의 항목이 Manual experiment steps에서 Orchestrated experiment로 변경되었다 해당 단계사이의 전환이 자동으로 이루어지므로 실험을 빠르게 반복하고 전체 파이프라인 프로덕션을 더 빠르게 이동할 수 있다.
2. Performance monitoring 항목이 생성되었다. 지속적인 모니터링을 통해 모델의 성능을 평가하고 트리거가 발생될 시 해당 트리거를 발생시킨 데이터를 저장하고 데이터를 분석하여 모델을 재학습 시키는 과정이 자동으로 진행되게 된다
3. 개발 , 실험 환경에서 사용되는 파이프라인이 프로덕션 환경에서 사용된다
4. ML파이프라인 전체에서 구성요소를 재사용, 구성, 공유할 수 있다. - 구성요소를 컨테이너화
- 개발 및 프로덕션 환경간에 코드를 재현 가능하다
- 파이프라인의 각 구성요소를 분리하여 구성요소들은 자체 런타임 환경 버전을 가질 수 있고 다양한 언어 및 라이브러리를 갖는다
- 코드 실행 환경을 분리한다
5. CD : 새로운 데이터로 학습된 새 모델을 프로덕션으로 지속적으로 배포하는 단계가 자동화 된다
6. 파이프라인 배포 : 전체적인 파이프라인이 전부 배포된다
MLOps 수준 1을 구성하기 위해서는 데이터와 모델의 검증이 필요하다
trigger를 통해 자동으로 파이프라인을 실행하기 때문에 자동 학습을 위한 데이터 검증과 모델 검증 프로세스가 필요하다
- 데이터 검증 : 모델 학습 전에 모델이 재학습을 진행할 지 파이프라인의 실행을 중지할지 결정하는데 필요하다 이 결정은 파이프라인에서 다음을 식별하면 자동으로 수행된다 ㄱ. Data Schema Skews(데이터 스카마 편향) : 이러한 Bias는 입력 데이터의 이상으로 간주된다 데이터 처리 및 모델 학습을 포함한 파이프라인의 단계에 해당 데이터가 형식에 맞지 않는지 판단해야한다 . 입력이 되는 데이터가 형식에 맞지 않을 경우 작업자에게 이 사실을 알리고 조사하게 한다. 작업자는 해당 사실을 알아차리고 해당 데이터에 대한 분석을 진행하고 파이프라인을 수정하거나 업데이트한다
ㄴ. Data Value skews(데이터 값 편향) : 이러한 skews는 데이터의 통계적 특성이 변한것이다 이러한 사항을 포착하여 모델을 업데이트 하여야한다.
- 모델 검증 : 트리거 발생으로 인한 모델의 재학습시 모델을 프로덕션으로 제공하기 전에 사용자가 모델을 평가하고 검증해야한다
ㄱ. 모델의 품질을 평가하기 위해 측정항목을 생성한다
ㄴ. 현재 모델과 비교한다 - 더 성능이 좋은지 판단한다
ㄷ. 모델의 성능이 다양한 범위에서 일관성이 있는지 확인한다 - True Nagative , True Positive , False Nagative, False Positive
ㄹ. 인프라와의 호환성 및 일관성을 모함하여 모델 배포 테스트 - 트레픽 대응 A/B 테스트, 카나리아 배포
Feature Store
Feature Store는 선택적 구성요소이다 학습및 서빙을 위한 특성을 정의, 저장, 접근을 표준화하는 저장소
Feature store는 Feature에 대해 높은 처리량과 일괄 처리 및 짧은 지연시간, 실시간 제공을 위한 API를 제공해야 하며 학습 및 서빙 workloads를 지원해야한다
ㄱ. 동일하거나 유사한 feature set을 다시 만들지 않고 feature set을 검색하고 재사용하게 된다
ㄴ. feature 및 관련 메타데이터를 유지하여 정의가 다른 유사한 특성 사용을 방지한다
ㄷ. 최신의 Feature value를 제공한다
ㄹ. Feature store을 지속적 학습, 실험, 서빙을 위한 데이터 소스로 사용하여 training serving skews(학습과 서빙의 성능 차이)를 방지한다
메타데이터 관리
ML파이프라인의 각 실행에 대한 정보는 전부 기록되며 오류와 이상을 디버깅하는데 도움이 된다.
다음과 같은 메타데이터가 기록된다
ㄱ. 실행된 파이프라인 및 구성요소 버전
ㄴ. 시작 및 종료 날짜, 시간, 파이프라인 각 단계를 완료하는데 걸린 시간
ㄷ. 파이프라인 실행자
ㄹ. 파이프라인에 전달된 파라미터 인수
ㅁ. 준비된 데이터 저장 위치, 검증 이상, 계산된 통계, 카테고리형 특성에서 추출된 어휘와 같은 파이프라인의 각 단계에서 생성된 artifacts에 대한 포인터 - 이러한 출력을 추적하면 이미 완료된 단계를 다시 실행하지 않고도 파이프라인이 실패한 단계로 가장 최근의 단계에서 파이프라인을 다시 실행시킬 수 있다
ㅂ. 이전에 학습된 모델에 대한 포인터 - 이전 모델 버전으로 롤백해야 하는 경우 또는 모델 검증 단계에서 파이프라인에 새 테스트 데이터가 제공될 때 이전 모델에 대한 평가항목을 생성해야 하는 경우)
ㅅ. 학습 및 테스트 세트에 대한 모델 평가단계에서 새로운 모델 평가 측정항목 - 새로운 모델과 이전 모델의 성능을 비교하기위해 필요
ML pipeline trigger
파이프라인을 자동으로 재학습 시킬 수 있게 한다
ㄱ. 수동실행
ㄴ. 정기적 실행 - 매일, 매주, 매월 - 재학습 빈도는 패턴 변경빈도 , 재학습 비용에 따라 달라진다
ㄷ. 새 학습 데이터의 가용성 기준 -
ㄹ. 모델 성능 저하 시
ㅁ. 데이터 분포의 중요한 변화시 (concept drift) - 모델이 오래됬다고 판단되어 재학습이 필요할 때
부족한 점
1. 파이프라인의 새로운 구현이 자주 배포되지 않고 몇개의 파이프라인만 관리한다고 가정된다. - 파이프라인과 구성요소를 수동으로 테스트한다
2. 새로운 파이프라인을 수동으로 배포한다
3. 새로운 ML 아이디어를 시도해야하고 ML 구성요소를 빠르게 배포해야 하는 경우 배포를 자동화 하기위한 CI/CD가 필요하다
머신러닝 프로젝트를 지속적으로 통합(CI), 지속적 배포(CD), 지속적 학습(CT)를 구현하고 자동화하는 기술을 설명한다.
- DevOps와 MLOps의 비교
DevOps란 대규모 소프트웨어 시스템을 개발하고 운영하는데 사용된다. 효율적인 DevOps는 개발 주기 단축, 배포 속도 증가, 안정적인 출시 등의 이점을 제공한다. 이러한 이유는 지속적 통합(CI : Continuous Integration)와 지속적 배포(CD : Continuous Deployment) 의 효과이다
MLOps는 DevOps와 비슷하지만 다른점은 이와같다
1. 머신러닝은 주로 수학자와 데이터 사이언티스트, 연구원으로 구성되어 있기 때문에 프로덕션 수준의 서비스 빌드가 가능한 인력이 없을 수 있다.
2. ML은 기본적으로 실험에 기반한 기술이다. 많은 사람들이 하이퍼파라미터의 변경에 어떤 수학적 함수를 따르는지 모른다. 그렇기에 실험을 통해 좋은 하이퍼파라미터를 찾게되는데 이런 과정에서 모델의 성능이 좋았던 것과 안좋았던것 을 잘 정리하고 모델 코드를 잘 분류하여 코드 재사용성을 극대화하고 재현성을 유지해야한다
3. 머신러닝은 다른 소프트웨어보다 더 복잡하다. 단위테스트, 데이터 검증(Data Validation), 학습 모델 평가, 모델 검증(Model Validation)이 필요하다
4. 머신러닝 모델은 지속적으로 업데이트가 되어야한다. 계속하여 서비스되고있는 모델의 성능을 검증하고 평가하고 평가점수가 낮아졌다면 모델의 학습을 다시 진행시켜야 완벽한 서비스가 진행된다. 이를 위해 지속적인 배포를 위한 자동화가 필요하다
5. 사용자의 데이터는 계속하여 진화된다. 이로인해 모델이 학습하지 못한 데이터가 입력으로 들어올 가능성이 크다. 이러한 문제는 모델의 성능 저하로 이어지기 때문에 데이터의 통계를 관찰하고 모델의 성능을 지속적으로 모니터링 하여 trigger를 발생시켜 문제를 인식하여야 한다.
