Model Experiment Pipeline
MLOps 혹은 ML Ops는 Machine Learning과 DevOps(소프트웨어를 지속적으로 개발하는 운영관행)의 합성어로 머신러닝을 만드는 환경에서 기계학습모델을 안정적이고 효율적으로 배포 및 유지 관리하는 것을 목표로 하는 일련의 관행이다.
MLOps의 단계는 크게 머신러닝 기반의 프로젝트를 디자인하는 단계, 머신러닝 모델을 실험하고 개발하는 단계, 모델을 서비스(상품)으로 배포하고 운영하는 단계가 있다.
머신러닝을 운영하는 것은 머신러닝을 개발하는 것과 더불어 중요한 단계 중 하나이다. 많은 기업들이 머신러닝 시스템을 구축하고 운영하는 데에 어려움을 겪고 있다고 한다. 약 88%의 머신러닝 프로젝트들은 POC단계에서 가치는 검증되었지만 운영상의 어려움으로 인해 서비스로 발전하지 못한다고 한다.
데이터 사이언티스트가 데이터를 학습 가능한 데이터로 정제하여 모델을 만들었다면 이러한 예측 모델을 서비스로 운영하기 위해 API 서버, Batch job과 같이 개발된 모델을 위한 endpoint가 제공되어야 한다. 이러한 endpoint를 개발하기 위해서는 infrastructure를 설계하고 개발, CI/CD 등 여러 요소들이 고려되어야 하는데 데이터를 관리하는 것과 서비스를 개발하는 것은 결이 다르다. 그렇기 때문에 좋은 모델을 만들었다고 해도 서비스가 가능한 수준의 제품으로 만들기 까지는 우여곡절이 많다.
모델을 사용하면서 실제 데이터가 변해 학습데이터에 이를 반영해야하는 경우도 있다. 데이터의 변화와 모델 성능의 변화를 인지해야 모델의 성능을 일정 수준 이상으로 유지할 수 있을 것이다. 모델은 입력된 과거의 데이터로 보통 학습시키기 때문에 일정 수준 이상의 적절한 예측을 하기 위해서는 주기적인 점검과 평가가 필요한 것이다.
또한 과거 모델이 학습한 데이터와 예측했던 데이터, 실제 데이터 등을 알아야 모델을 개선하고 서비스를 적절하게 유지할 수 있을 것이다. 반복된 데이터 정제 코드의 수정과 모델 학습 코드의 변경이 일어나면 과거에 어떤 모델을 사용했는지 파악하기 어렵고 이로인해 분석이 더 어려워진다. 이는 협업의 문제로도 이어져 서비스를 유지, 운영, 개선, 개발 등이 어렵게 되기 때문에 운영에 대한 중요성은 대두되어왔다.
머신러닝은 문제를 해결하는 좋은 도구이지만 머신러닝을 운영하는 것은 머신러닝을 이해하는 것만큼의, 혹은 그 이상의 노력이 필요하다. DevOps가 주목받은 이유는 이러한 맥락에서 나온 것인데 서비스를 빠르게 전달하여 실제 사용자들(혹은 고객들)을 더 잘 지원하고 경쟁력을 갖출 수 있게 했다는 것이다. MLOps도 이처럼 머신러닝 시스템을 사용자에게 바르게 전달하고 경쟁력을 갖추는 것을 목표로 한다고 한다.
DevOps에서는 코드 통합 -> 테스트 -> 배포 -> 테스트 -> 모니터링이라는 파이프라인을 자동화하여 이 목표를 달성한다. 용어는 같지만 MLOps에서 쓰이는 용어는 의미가 다르기 때문에 이를 정리해보고자 한다.
위는 일반적인 머신러닝 파이프라고 한다.
코드 통합
머신러닝은 정제되지 않은 데이터를 유의미한 학습데이터로 만들고, 알고리즘을 구현하고, 여러 설정값들을 조정하며 테스트를 거쳐 나온 결과물이다. 유의미한 수준의 모델을 만들기 위해 다양한 시도들을 하게 되고 이러한 시도는 프로그래밍이므로 코드로 작성된다. 실험과 검증에 사용된 코드는 운영 가능한 형태가 아니다.
운영을 위해서는 프로덕션 데이터의 ETL, 분산처리, 불필요한 로직제거, 예측 추런 시간을 서비스 수준에 맞게 학습 단계를 단순화하는 작업 등이 필요하다.
MLOps에서의 통합은 실험환경에서 결정된 데이터를 변형하고 학습, 평가, 재학습 주기, 모니터링 지표 설정 하는 과정들이 실제 서비스 운영환경에 통합되는 것을 의미한다.
테스트
모델의 성능을 평가하는 Accuracy, precision, recall, confusin matrix 등의 평가지표로 모델을 테스트하고 평가하여 내부에서 동작한 결과가 유효한시 실험해 보는 것을 의미한다.
모니터링
실제 서비스는 리소스 상태, 응답 시간 등을 통해 서비스가 정상적으로 이루어지고 있는지 확인할 수 있다. 모델이 잘 작동하는지 테스트할 때 다양한 지표들이 사용되는 것처럼 모니터링을 통해 모델의 성능을 판단하는 다양하고 복잡한 방법들이 많다고 한다. 예를 들면 모델 endpoint에 요청된 데이터와 예측했던 값들을 수집하고 이것들이 학습된 데이터와 statistical distance를 계산하는 것 등이 있는데 서비스의 목적, 모델의 목적이나 특성 등 여러 요인에 따라 판단 방법은 달라질 수 있기 때문에 모니터링을 어떠한 지표를 기준으로 할 것인지 결정하는 것도 중요하다고 한다.
배포
모델은 API에서 제공하는 것도 배포라고 하지만 MLOps에서 말하는 배포는 코드 통합, 새로운 데이터의 학습, 서비스로 모델 전달, 모니터링 방식 적용까지의 일련의 과정(파이프라인)을 배포하는 것을 의미한다.
MLOps의 파이프라인은 일회용이 아니다. 배포 이후 다시 모델 개발단계로 신속하게 전환되어야하는데 이전 모델과 운영된 데이터의 분석 이후 다시 통합, 학습, 전달, 모니터링이 이루어져야한다.
MLOps에 대해 매우 자세히 설명한, 참고 블로그로 내용과 이미지는 이 블로그의 링크가 원본이다.
WandB
WandB란 Weights & Baises의 약자로 더 나은 모델을 빨리 만들 수 있도록 도와주는 머신러닝 Experiment Tracking Tool이다. UX 측면에서 상당히 흥미로운데, 머신러닝 설계자 및 사용자의 생산성과 효율성, 편리성을 높여주었을 것 같다.
아무튼, 더 나은 모델을 효율적으로 만들고 비교하고 머신러닝 모델 설계자가 여러 사용자지정값들을 변경하며 실험을 할 경우 이를 비교하고 분석하기 까다로운데 이를 해결할 수 있는 좋은 tool이 WandB인 것이다.
WandB를 사용하는 방법에 대해서 잘 정리한 블로그를 참조하며 이 단계를 따라해보면서 익히면 좋을 것 같다.
WandB란? - 강력한 MLOps Tool
Weight & Biases(wandb) 사용법(wandb 설치 및 설명)
