ML pipeline 이란?

머신러닝과 딥러닝에서 가장 중요한 지표는 "성능"이라는 것은 누구도 반박할 수 없을 것이다.

그렇다면 모델의 성능만 높이면 머신러닝 프로젝트는 끝났다고 할 수 있을 것인가?

그렇지 않다.

머신러닝 프로젝트에서 "성능"은 필수 구성품중 하나이지 모든 것을 커버하지 않는다. 이 말은 머신러닝 프로젝트에는 Data load, Preprocessing, EDA, Data Split, Model training, Model validation, Model serving, API service, Monitoring, etc .. 등 굉장히 많은 작업들이 필요하다. 심지어 시스템의 보안, 안전성, lag 처리, 빅데이터 관리 등 수 많은 요소들이 존재한다.

즉, 모델을 학습시키는 일련의 과정(pipeline)의 중요성이 대두되고 있다.

MLOps 업무를 표현하는 아주 유명한 그림은 아래와 같다.

paper: Hidden Technical Debt in Machine Learning Systems

어떠한가, 굉장히 많지 않은가? 기존 연구실의 경우 이러한 모든 것을 여태껏 직접 코딩하면서 분석을 해왔을 것이다. 하지만, 이는 똑똑한 연구원들에게 "지루함"을 가져다 줄 것이다. MLOps의 목적은 그림에 나타난 기능들을 일련의 파이프라인으로 만드는 것이다. 새로운 데이터가 들어와도 아주 간편하게 재학습을 돌릴 수 있다. 그리하여 모델을 보다 쉽게 관리하고 학습하며 동시에 데이터 관리 그리고 모니터링도 가능해진다.

파이프라인의 예시는 아래 그림과 같다.

파이프라인 예시

위 파이프라인 예시 그림은 아주 간단한 과정만 설명한 것이다. 즉, 기초중에 기초를 보여준 것이다.

만약 실제 서비스단계로 가게 된다면, 고려해야할 사항들이 엄청나게 많아진다. 예시로, orchestration, lag 처리, data schema, serving, .. etcs.

조금 더 deep 하게 2가지에 대해서만 설명을 해보겠다.

1. event lag 처리를 하기 위해서는 기본적으로 The dataflow model (https://research.google/pubs/pub43864/) 논문을 먼저 이해해야할 것이다. 해당 논문을 정리한 내용은 https://jjcouple.tistory.com/5 여기를 참고하면 된다. 논문을 이해하게 된다면, 우리는 어떤 툴을 이용할지도 고려를 해야한다. 다시 말하면 수 많은 툴중에서 어떤 툴이 우리 서비스에 적합한지도 명확히 판단해야 한다는 뜻이다.

2. Serving 과정에서도 여러가지 툴이 있다. fastapi, Torchserve, Tensorflow extended, bentoml .. 이 또한 우리는 어떠한 툴이 우리 서비스에 적합한지 판단을 내려야 할 것이다. 만약 모델의 코드가 Pytorch로 구성되어 있다면 torchserve를 사용하면 될 것 같지만 이는 쉽지 않을 수가 있다. Torchserve의 serving과정의 documentation이 부족하다. 그렇다면 요즘 많이 사용하고 있는 Fastapi를 쓰면 되지 않을까? 맞다. 대세를 따라가는게 안전하다. 하지만, 현재 2022.04.19 기준으로 Fastapi는 버전이 0.75.2가 가장 최신이다. 아직 버전 1을 찍지 못했다. 기업 입장에서는 이러한 불완전한 api를 사용해도 될지에 대해서도 고민을 해야할 것이다.

자, 얼마나 복잡한지 이제 감이 올 것이다. 앞서 말한 것은 아주 조그마한 문제들만 말한 것이다.. (급 피곤해지기 시작했다....) 하지만, 이러한 파이프라인이 구성이 된다면 "효용 가치"는 어마어마 할 것은 의심의 여지가 없다.

다시 정리하자면, 인공지능 기능을 실 서비스화 하기 위해서는 데이터 관리 및 시스템 관리가 필요하다. 이를 위해서 MLOps라는 분야가 탄생하게 되었다. AI 산업을 발전시키기 위해서는 pipeline을 구축은 필수 불가결 해졌다.







출처
https://lsjsj92.tistory.com/579