MLOps

참고 블로그

[MLOps 정의] MLOps가 무엇인고?

MLOps 개론

모델 개발 프로세스 - Research

보통 자신의 컴퓨터, 서버 인스턴스 등에서 실행하며, 고정된 데이터를 통해 학습

문제 정의
EDA
Feature Engineering
Train
Predict

모델 개발 프로세스 - Production

학습된 모델을 앱, 웹 서비스에서 사용할 수 있도록 만드는 과정이며 Real World, Production 환경에 모델을 배포한다고 표현

문제 정의
EDA
Feature Engineering
Train
Predict
Deploy

모델이 배포되었다고 가정할 때, 모델의 결과값이 이상한 경우가 존재

Input 데이터가 범위를 벗어나는 이상한 경우가 존재하는 등 원인 파악 요구
Research 단계에선 Outlier로 제외할 수 있지만, 실제 서비스에선 제외가 힘들며, 별도 처리를 요구

모델 성능이 계속 변경

예측 값과 실제 레이블을 요구
정형(Tabular) 데이터에서는 정확히 알 수 있지만, 비정형 데이터는 모호한 경우가 다수

새로운 모델이 더 안좋다면

과거의 모델을 다시 사용할 지에 대한 판단 고려
Research 환경에서 좋던 모델이 Production 환경에선 미흡할 수 있음
이전 모델을 다시 사용하기 위한 작업을 요구

MLOps: ML(Machine Learning) + Ops(Operations)

머신러닝 모델을 운영하면서 반복적으로 필요한 업무를 자동화하는 과정
머신러닝 엔지니어링 + 데이터 엔지니어링 + 클라우드 + 인프라
머신러닝 모델 개발(ML Dev)과 머신러닝 모델 운영(Ops)에서 사용되는 문제와 반복을 최소화하고, 비즈니스 가치를 창출하는 것이 목표
모델링에 집중할 수 있도록 관련된 인프라를 만들고, 자동으로 운영되도록 만드는 일

머신러닝 모델링 코드는 머신러닝 시스템 중 일부에 불과

MLOps의 목표는 빠른시간 내에 가장 적은 위험을 부담하며 아이디어 단계부터 Production단계까지 ML프로젝트를 진행할 수 있도록 기술적 마찰을 줄이는 것

	Research ML	Production ML
데이터	고정	계속 변함(Dynamic-Shifting)
중요 요소	모델 성능(Accuracy, Loss 등)	모델 성능, 빠른 Inference 속도, 해석
도전 과제	더 좋은 성능을 내는 모델(SOTA), 새로운 구조의 모델	안정적인 운영, 전체 시스템 구조
학습	데이터를 고정한 채 모델 구조, 파라미터 기반 재학습	시간 흐름에 따라 데이터가 변경되어 재학습
목적	논문 출판	서비스에서 문제 해결
표현	Offline	Online

MLOps Component

MLOps의 구성 요소에 따라 역할 분리

Infra

배포하기 위한 성능 지표

클라우드
- AWS, GCP, Azure, NCP 등
온프레미스
- 회사나 대학원의 전산실에 서버를 직접 설치

Server Infra

예상하는 트래픽
서버의 CPU, Memory 성능
스케일 업, 스케일 아웃의 가능성
자체 서버 vs 클라우드

GPU Infra

Local GPU vs Cloud GPU

Serving

Batch serving
- 많은 양의 데이터를 일정 주기에 따라 예측
Online serving
- 한 번에 하나씩(실시간으로) 예측
- 병목이 없으며, 확장 가능하도록 준비

Experiment, Model Management

파라미터, 모델 구조 등의 조합에 따른 성능 지표를 관리
모델 Artifact, 이미지 등의 부산물 관리
모델 생성일, 성능, 모델의 메타 정보 등을 기록
여러 모델을 통일된 규격에 따라 운영

Feature Store

학습과 serving에 사용되는 모든 feature들을 모아둔 저장소
대용량 배치 처리와 low latency의 실시간 서빙을 모두 지원하여야 함

Data Validation

Feature의 분포 확인
데이터 검증에 실패하면 신규 모델의 배포를 중지하며, 해당 의사결정 역시 자동화로 진행
Data/Model/Concept drift
- 모델을 새로운 데이터에 맞게 꾸준히 학습하거나 목적 등을 전환하는 행위

Continuous Training

Retrain 과정
새로운 데이터를 사용하여 프로덕션 모델이 자동으로 학습
성능을 확인하여 학습 여부를 따지는 Pipeline이 Data Processing/Model training/Model evaluation engine에 영향을 미쳐 학습 진행

Monitoring

모델의 지표, 인프라 성능 지표 등을 기록

AutoML

데이터에 맞는 모델을 자동으로 제작

ML 프로젝트 Lifecycle

문제 정의

특정 현상을 파악하고 그 현상에 있는 문제를 정의하는 과정

문제를 잘 풀기 위해서 문제 정의가 매우 중요
문제가 명확하지 않을 시 추후 과정에 장애 발생
- 예시: 저는 사람들을 행복하게 만들고 싶어요
  - 모호한 문장
  - 대상 사람의 기준
  - 행복의 정의
머신러닝, AI, 데이터 사이언스, 개발 등 대부분 업무에서 항상 문제 정의가 선행되어야 함
How보다 Why에 집중

1. 현상파악

현상을 발견하여 상황을 파악하는 단계

어떤 일이 발생하는가?
해당 일에서 어려움은 무엇인가?
해당 일에서 해결하면 좋은 것은 무엇인가?
추가적으로 무엇을 해볼 수 있는가?
어떤 가설을 만들어 볼 수 있는가?
어떤 데이터가 있는가?

2. 구체적인 문제 정의

앞선 현상을 더 구체적이고 명확한 용어로 정리

무엇을 해결하고 싶은가?
무엇을 알고 싶은가?
현상을 계속 쪼개서 그 문제를 기반으로 어떤 어려움을 겪는지 파악
데이터로 할 수 있는 일을 만들어서 진행하되, 알고리즘 접근이 최선은 아니므로 간단한 방법부터 점진적으로 접근하여 시간의 제약 완화
- 원인을 계속 파고들면 해결 방법이 구체적으로 나올 수 있음

3. 프로젝트 설계

문제 정의에 기반하여 프로젝트 설계

해결하고자 하는 문제 구체화
머신러닝 문제 타당성 확인
목표 설정, 지표 결정
- 제약 조건
- 베이스라인, 프로토타입
- 평가(Evaluation) 방법 설계

3-1. 머신러닝 문제 타당성 확인

머신러닝 문제를 고려하기 위해선 흥미가 아닌, 제품, 회사의 비즈니스에서 어떤 가치를 줄 수 있는지를 고려

머신러닝 문제
- 결국 데이터로 부터 어떤 함수를 학습하는 것
- 머신러닝 문제 타당성 평가
  - 복잡도를 평가하는 방법은 필요한 데이터의 종류와 기존 모델이 있는지 탐색
- 모든 문제를 해결할 수 있는 도구가 아닌 것을 이해
- 머신러닝으로 해결할 수 있는 문제지만 머신러닝 솔루션이 최적이 아닐 수도 있음
머신러닝을 이용하는 경우
- 학습할 수 있는 패턴이 있는가?
- 패턴이 복잡한가?
- 학습을 위한 유용한 목적 함수가 정의될 수 있는가?
- 학습을 위한 데이터가 존재하는가?
- 사람이 반복적으로 실행하여야 하는가?
머신러닝을 이용하지 않는 경우
- 비윤리적인 문제
- 간단히 해결할 수 잇는 경우
- 좋은 데이터를 얻기 어려운 경우
- 한 번의 예측 오류가 치명적인 결과를 야기하는 경우
- 시스템이 내리는 모든 결정이 설명 가능해야 할 경우
- 비용이 효율적이지 않은 경우

3-2. 목표 설정, 지표 결정

프로젝트의 목표
- Goal: 프로젝트의 일반적으로 큰 목적
- Objectives: 목적을 달성하기 위한 세부 목표
지표
- 목표를 설정하며 데이터를 확인
- 데이터 소스 탐색
- 정확히 찾으려는 데이터가 없는 경우, 여러가지 시나리오를 고려
  - Label을 가진 데이터: 바로 사용
  - 유사 Label을 가진 데이터: 분석
  - Label이 없는 데이터: 직접 레이블링 하거나 레이블링 없는 상태에서 학습하는 방법 모색
  - 데이터가 아예 없는 경우: 데이터 수집 방법부터 고민
  - 데이터셋을 만드는 일은 반복적인 작업이므로, 이를 위해 Self-Supervised Learning 등을 사용하여 유사 레이블을 생성

3-3 제약조건

일정: 프로젝트에 사용할 수 있는 시간
예산: 사용할 수 있는 최대 예산
관련된 사람: 이 프로젝트로 인해 영향을 받는 사람
Privacy: Storage, 외부 솔루션, 클라우드 서비스 등에 대한 개인정보 보호 요구
기술적 제약: 기존에 운영하고 있던 환경, 레거시 환경(인프라)
윤리적 이슈: 윤리적으로 어긋난 결과
성능
- Baseline: 새로 만든 모델의 비교 대상
- Threshold: 확률 값의 기준
- Performance Trade-off: 속도 vs 정확도
- 해석 가능 여부: 결과 발생에 대한 해석 여부
- Confidence Measurement: False Negative나 오탐에 대한 가능성

3-4 베이스라인, 프로토타입

Baseline
- 자신이 모델이라고 생각하여 어떻게 분류할지 Rule base 규칙 설계
- 간단한 모델부터 시작
  - 어떻게든 모델의 위험을 낮추는 것이 목표
  - 최악의 성능을 알기 위해 허수아비 모델로 시작
  - 점진적으로 향상
- 유사한 문제를 해결하고 있는 SOTA 논문 파악
프로토타입
- 베이스라인 이후, 간단한 모델에 대한 피드백
- 동료들이 모델을 활용할 수 있는 환경 마련
- 프로토타입 제공
  - Input을 입력하면 Output을 반환하는 페이지
  - 이왕이면 좋은 디자인을 가지면 좋지만, 모델의 동작이 더욱 중요
  - HTML 보다 모델에 집중
  - Voila, Streamlit, Gradio 등 활용

3-5 Metric Evaluation

모델의 성능 지표와 별개로 비즈니스 목표에 영향을 파악

RMSE와 같은 모델의 성능 지표
고객의 재방문율, 매출 등 비즈니스에 대한 지표
Action이 기존보다 더 성과를 냈는지 파악

4. Action: 배포 & 모니터링

지표의 변화 파악

현재 만든 모델이 어떤 결과를 내고 있는가?
잘못 예측한다면 어떤 부분이 문제인가?
어떤 부분을 기반으로 예측하고 있는가?
Feature의 어떤 값을 사용할 때 특히 잘못 예측하는가?

5. 추가 원인 분석

새롭게 발견한 상황을 파악해 어떤 방식으로 문제를 해결할 지 모색

앞서 진행한 과정을 반복

[MLOps]MLOps란