0. 들어가기에 앞서
변성윤님의 서비스 개발 기초 강의를 들으며 MLOps에 대해 처음 알 수 있었다.
처음 듣는 내용이 많았고, 대회를 하며 어려움이 있었던 부분의 해결책들도 들을 수 있었던 것 같아 흥미롭게 들었다.
강의가 끝날때 쯤 아래 항목들에 대해 정리해보라고 과제를 내주셨는데, 이 흐름에 맞춰서 MLOps를 배워야하는 이유를 적어보겠다.
- MLOps가 필요한 이유 이해하기
- MLOps의 각 Component에 대해 이해하기(왜 이런 Component가 생겼는가?)
- MLOps 관련된 자료, 논문 읽어보며 강의 내용 외에 어떤 부분이 있는지 파악해보기
- MLOps Component 중 내가 매력적으로 생각하는 TOP3을 정해보고 왜 그렇게 생각했는지 작성해보기
1. MLOps란
MLOps = ML (Machine Learning) + Ops (Operations)
MLOps란 머신러닝(딥러닝) 모델을 학습시키고, 배포하는 과정에서 필요한 반복적인 업무를 자동화시키는 과정을 의미한다.
MLOps component에는 아래와 같은 것들이 있다.
- Infra(Server, GPU)
- Serving
- Experiment, Model Management
- Feature Store
- Data Validation
- Continuous Training
- Monitoring
- AutoML
2. MLOps가 필요한 이유 이해하기
지난 level1 프로젝트(STS 대회)는 물론이고, 여태까지 했던 데이콘 대회 및 학부연구생 프로그램에서 항상 실험 기록 및 모델 관리가 굉장히 어려웠다. 또한 Docker + Ubuntu(wsl2) + Pytorch를 이용해 로컬 환경에서 구축하는 것은 정말 쉽지 않은 작업이였다. (아직도 해결 못했다.)
머신러닝, 딥러닝 모델을 공부하고 만들어보고 싶은데 정작 다른 것들에 신경쓰느라 시간과 노력이 굉장히 많이 든다.
MLOps가 요즘 뜨고 있는 이유 역시 바로 이 때문이라고 생각하는데, MLOps는 이러한 "다른 것들"을 자동화시켜 편리하게 관리할 수 있도록 도와준다.
현실 세계의 문제를 머신러닝/딥러닝을 이요해서 해결하려 하면, 예상치 못한 어려움이나 위험 등이 있을 수 있다.
MLOps의 목표는 이러한 어려움, 위험 등을 최소화시켜 문제 인식부터 문제 해결까지 ML 프로젝트를 기술적 마찰 없이 진행 될 수 있도록 돕는 것이다.
3. MLOps의 각 Component에 대해 이해하기
MLOps의 각 component에 대해 이해하기 위해서는 왜 이런 Component가 생겼는지를 생각해보면 된다.
각 component가 생긴 이유는 각각 아래와 같은 문제들을 해결하기 위해서이다.
3-1. Infra(Server, GPU)
몇 명의 유저가 사용할 서비스인가? (트래픽이 어느정도 인가?)
GPU, Memory의 성능은 얼마나 필요한가?
Scale-Up(수직 확장), Scale-Out(수평 확장)이 가능한가?
클라우드 서비스를 활용할 것인가? 자체 서버를 구축할 것인가?
대표적인 툴 : AWS, GCP, Azure 등
3-2. Serving
- Batch Serving
- 다량의 데이터를 일정 주기별로 한번에 예측
- Online Serving
- 실시간으로 들어오는 데이터에 대해 바로바로 예측
대표적인 툴 : cortex, BentoML 등
3-3. Experiment, Model Management
이 부분은 대회에서 WandB를 쓰며 그 중요성을 느낄 수 있었는데, 다양한 실험을 할 때 이를 체계적으로 관리할 시스템이 없다면 굉장히 불편했을 것이다. 모델 생성일, 성능, 하이퍼파라미터 등의 정보를 효율적으로 기록하고 팀원들과 공유할 수 있다면 많은 시간이 단축될 것이다.
대표적인 툴 : mlflow, wandb 등
3-4. Feature Store
머신러닝/딥러닝 feature를 미리 추출해서 feature store에 저장해둔다.
(그리고 필요할때마다 꺼내서 사용)
대표적인 툴 : FEAST, hopsworks 등
3-5. Data Validation
- Research와 Production의 Feature 분포가 비슷한지 확인하는 과정
- Research에서는 좋은 성능이 나왔는데, Production에서 그렇지 않을 경우 분포가 다르기 때문일 수 있다.
- Concept Drift
- Data Drift
Concept Drift?
정답 라벨의 개념이 변하는 경우 (스팸 분류기에서 스팸의 개념이 변하는 경우)
Data Drift?
데이터의 분포가 변하는 경우
대표적인 툴 : TFDV(Tensorflow Data Validation), AWS Deequ 등
3-6. Continuous Training
아래와 같은 이유 등으로 주기적으로 혹은 요청에 따라 모델을 재학습 시키는 것을 의미한다.
- 새로운 데이터가 추가된 경우
- 모델이 예측을 잘 못하는 경우 (Concept Drift, Data Drift 등)
- 일정 주기로
3-7. Monitoring
배포한 모델이 real world에서 좋은 성능을 내고 있는지 잘 확인하고 기록해야한다.
성능을 잘 낸다면 어떤 데이터에 대해서 얼마만큼 잘 내고, 잘 내지 못한다면 또 어떤 데이터에 대해서 얼마만큼 잘 내지 못하는지 분석해 추가적인 아이디어를 얻을 수 있다.
또한 Model drift 역시 Monitoring을 통해 감지해야하는데 이 부분에 대해서는 아래에서 조금 더 자세하게 다루겠다.
💡 Monitoring을 보며 생각 난 것인데, 모델링할 때도 validation data를 기준으로 잘 예측하지 못하는 데이터는 반드시 살펴볼 필요가 있는 것 같다. 이런 데이터들의 특징을 찾고 이에 적합한 학습 방식을 적용한다면 성능이 훨씬 올라갈 수 있을 것이다.
3-8. AutoML
- 말 그대로 AutoML
대표적인 툴 : Microsoft NNi 등
4. MLOps 관련된 자료, 논문 읽어보며 강의 내용 외에 어떤 부분이 있는지 파악해보기
More about Drift .. (링크 참고)
위에서 3-7에서 Monitoring 단계에서 model drift를 감지해야 한다고 했다.
조금 더 구체적으로 어떻게 감지할 수 있을까?
우선 machine learning에서 drift의 종류부터 살펴볼 필요가 있다.
- Concept drift
- Prediction drift
- Label drift
- Feature drift
Drift가 일어나는 원인은 다음과 같다.
- 외부 효과로 인한 자료 분포의 실질적 변화 (코로나 등의 사회적 이슈로 인한 고객 선호도 변화 등)
- 데이터 엔지니어링 등에서 일어난 데이터의 문제
Data drift는 1. 통계 기반, 2. 모델 기반으로 측정할 수 있다.
1. 통계 기반은 Kullback-Leibler(쿨백 라이블러 발산), Jensen-Shannon divergence, Kolmogorov-Smirnow 검정 등을 이용해 계산
2. 모델 기반은 모델을 사용하여 어떤 기준에 대해 두 그룹의 유사성을 결정
두 방법 모두 어떤 분포 혹은 데이터 그룹의 유사도(차이)를 구하는 형태이다.
5. MLOps Component 중 내가 매력적으로 생각하는 TOP3을 정해보고 왜 그렇게 생각했는지 작성해보기
5-1. Serving
Research와 Production 모두 AI 프로젝트에서 중요한 부분이지만, 결국 우리가 AI를 공부하는 이유는 AI로 더 나은 세상을 만들기 위해서다. AI를 현실 세계에 적용시키는 첫 단계가 Serving이기 때문에 Serving은 굉장히 중요한(매력적) component라고 생각한다.
5-2. Data Validation
만든 모델은 배포하면 끝난 것이 아니라 지속적으로 성능이 잘 나와야 의미가 있다.
Research에서 혹은 과거에 성능이 잘 나왔다고 현재 real world에서 성능이 잘 나온다는 보장은 없다.
Data validation에서 이러한 data 검정을 지속적으로 잘 해줘야 한다.
5-3. Continuous learning
5-2와 이어지는 것으로 data validation에서 문제점을 발견 한 경우 새로운 데이터를 이용해 재학습 시켜줘야 한다.
초기 한 번의 학습 후 배포하는 것이 아닌 성능이 안 좋을 경우 꾸준히 학습을 계속 시켜줘서 성능을 업데이트 해줘야한다.
댓글