저번까지는 어떻게 Unseen data를 잘 예측하는 모델을 만들었는지에 집중했다면,
이번에는 Machine learning System에 대해서 알아볼 것입니다.
0) ML System?
머신러닝 시스템 중에서 모델이 차지하는 비율은 5% 이내
=> 그러면 나머지 95%는??
뭔지는 모르지만 매우 많아보이는데…
이러한 많은 기능들을 하나하나 알아보도록 하겠습니다.
1) What’s in a Production ML System
ML System의 구성요소들 대해서 알아보도록 하겠습니다.
전반적인 소개이기 때문에 잘 이해가 안 가실 수 있지만, 뒷 강의에서 약간씩 더 소개를 합니다.
1-1. Data Ingestion
Data Ingestion은 데이터를 적절하게 가져오는 시스템입니다.
-
BigQuery : Structured Batch Data Ingestion
빅쿼리는 IO 병렬화에 장점을 가지고 있습니다.
- Apache Beams IO module 사용가능
-
Cloud Storage : Unstructured batch data
- csv 대신에 TRFrecord 파일을 사용가능하다고 함.
-
Pub/Sub : streaming data
-
-
연속적으로 생성되는 데이터
ex) 모바일, 웹 어플리케이션을 통한 로그파일, 활동기록
-
-
1-2. Data Analysis and Validation
데이터에 있는 오류를 잡기 위해 Analysis와 Data validation을 하는 시스템입니다.
-
Data analysis : Understanding the distribution of your data
먼저 데이터의 오류를 잡기 위해서는 데이터의 분포를 파악해야합니다.
만약 어떤 계기로 인해서 데이터가 변화되었다면,
(ex, changed product numbering convention)
기존 분포와 현재 분포를 비교해서 데이터의 오류를 파악할 수 있을 것입니다.
-
Data validation : 데이터의 오류를 파악하는 기능
-
데이터 분포를 비교하기
-
center, mode(최빈값), symmetry, skewness
-
likelihood of observing the new distribution given original distribution
-
-
데이터가 적절한지 판단하는 기준
ex) 여러 나라의 물품 가격데이터를 US dollor로 환산하여 취급하려 할 때
- 다른 화폐의 분포는 비슷한데 엔화에서만 분포가 다른 경우 -> (1)
- item parser의 에러때문에 특정 값이 null이 된 경우 -> (2)
-
1-3. Data transformation + Trainer
-
Data transformation : feature wrangling을 하는 컴포넌트
-
row 데이터를 다른 format으로 바꿔주는 함수(mapping)을 만드는 작업
-
이렇게 만든 함수는 serving time에서도 재사용이 가능하면 좋을 것 같음.
이전에 Apache beam과 그것을 실행시켜주는 원동력인 cloud dataflow를 통해서 data transformation 작업을 해왔습니다.
-
-
Trainer : 모델을 학습하기 위한 작업을 지원함
- 데이터 병렬화, 모델 병렬화를 지원
- 스케일링
- 결과 자동 모니터링, 로깅
- 하이퍼파라미터 튜닝
GCP(Google cloud platform)에서는 다음 두 가지를 통해 Trainer 기능을 사용할 수 있습니다.
- ML Engine : provides the managed service for tensorflow
- 텐서플로우의 환경설정을 도와줌
- scale up 도와줌
- 뒤에서 배울 tuner, logging, serving과 같은 컴포넌트
- GKE( in Kubeflow ) : provides a managed environment for hybrid ML models
1-4. Tuner + Model Evaluation + Validation
-
Tuner
하이퍼파라미터 튜닝의 경우에는 딱히 optimal solution이 존재하지 않기 때문에 하이퍼파라미터 튜닝을 지원하는 서비스를 통해서 많은 파라미터를 테스트해봐야 합니다.
- Cloud ML Engine : 하이퍼파라미터 튜닝 알고리즘 제공
-
Model Evaluation & validation
정말 우리 모델이 적절한지 마지막으로 검증하는 단계
-
Model evaluation
- business-relevant metric (ex, AUC, cost-weighted error)을 이용하여 모델성능 계산
-
Model validation
- 검증기준
-
모델이 서빙하기에 얼마나 안전한지
- 메모리 같은 자원을 예상량보다 초과하지 않아야함.
-
model prediction quality
=> 특정 기준을 초과하는 경우가 생기면 실시간으로 알려줍니다.
-
- input을 여러 구간으로 나눠서 각각 테스트 하는 경우도 있습니다.
- 검증기준
-
1-5. Serving + Logging
-
Serving (inference) : 배포된 모델에서 유저의 요청에 따라 예측값(prediction)을 반환해주는 기능
-
서빙 컴포넌트에서 중요한 포인트
-
maximizing throughput
-
minimizing response latency
-
- easy to update to new versions
-
모델을 업데이트할 때 유저 입장에서 자연스럽게(seamlessly) 바뀌어야 하기 때문
-
-
multi-armed bandit 기법을 사용해서 어떤 버전의 모델이 가장 좋은지 테스트함.
-
multi-armed bandit
-
fixed limited set of resources must be allocated between competing (alternative) choices in a way that maximizes their expected gain,
- when each choice’s properties are only partially known at the time of allocation,
- may become better understood as time passes or by allocating resources to the choice.
예를 들면, 확률이 다른 슬롯머신 5개를 돌려보면서 어떤 슬롯머신이 더 괜찮은 머신인지 파악하는 방식을 말합니다.
-
-
-
GCP에서의 Serving Component
- Cloud ML Engine
- TF Serving ( Kubernetes )
-
-
logging : 디버그하는 컴포넌트
1-6. Orchestration + Workflow
문제점 : 데이터가 변하면, 기존에 보았던 모든 컴포넌트(Data ingestion, analysis, … logging)들의 코드가 변해야한다!
=> 그래서 이러한 부분을 해결하기 위해서 Orchestration이라는 컴포넌트가 생겨났습니다.
- Cloud composer를 통해서 Orchestration을 이용할 수 있음
Cloud composer에서는 데이터의 변화에 따른 종속관계를 만들지 않기 위해서 다음 로직을 사용합니다.
-
모델의 Operation들 정의
-
DAG(directed acyclic graph) 만들기
-
DAG를 적절한 순서로 병렬화해서 작동시키기 위해서 데이터의 dependencies를 정의하기
-
DAG 업로드하기
-
DAG를 web ui에서 실행하기