"MLOps"라는 용어의 등장

머신 러닝 라이프사이클에 대한 이해는 끊임없이 진화하고 있다. 몇 년 전 이 “주기”를 보여주는 그래픽을 처음 보았을 때, 일반적인 문제(데이터 준비 및 청소, EDA, 모델링 등)에 중점을 두었습니다. 종종 “배치”, “제공” 또는 어떤 경우에는 “예측”이라고 불리는 더 이해하기 어렵고 덜 유형적인 최종 상태에 대해서는 통지가 덜해졌다.

그 당시에는 많은 데이터 과학자가 그 마지막 용어의 완전한 범위를 고려하지는 않았다고 생각합니다. “예측”은 단순히 .predict()를 의미하는 것이 아니라 실제 규모, 프로덕션 레벨 구현, 모니터링 및 업데이트, 즉 진정한 사이클을 의미합니다. 이 모호한 개념을 현실로 만드는 데 필요한 엔지니어링 기술이 없다면 데이터 과학자는 노트북에 갇히게 됩니다. 모델은 데이터 과학자의 로컬 머신에서 .picke 파일로 작동했고, 파워포인트로 성능이 보고되었으며 ML 라이프사이클이 깨졌다.

엔드 투 엔드 ML 라이프사이클은 항상 실제 “사이클”로 간주되어 왔지만, 지금까지 이러한 엔드 투 엔드 프로세스를 엔터프라이즈 레벨 규모로 실제로 관리하는 데는 다음과 같은 이유가 있습니다.

데이터 과학자는 종종 훈련된 엔지니어가 아니기 때문에 항상 우수한 DevOps 관행을 따르는 것은 아닙니다.
데이터 엔지니어, 데이터 과학자 및 제공 담당 엔지니어가 사일로에서 운영되므로 팀 간에 마찰이 발생합니다.
수많은 기계 학습 도구 및 프레임워크는 업계 전반에서 표준화 부족을 조장합니다.
특정 언어, 프레임워크, 공급자 등에 의해 제한되지 않고 엔지니어와 데이터 과학자의 요구 사항을 충족하는 관리형 솔루션은 아직 없습니다.
일반적으로, 엔터프라이즈 머신 러닝은 아직 미숙합니다.

여기에는 더 많은 이유와 많은 하위 이유가 있을 것입니다. 하지만 이러한 높은 수준의 문제는 불행한 결과를 초래합니다. 엔터프라이즈의 머신 러닝은 느리고 확장하기가 어려우며, 자동화되는 것이 많지 않으며, 협업이 어렵고, 비즈니스 가치를 제공하는 실제 운영 모델은 거의 없습니다.

따라서 프로덕션에서 머신 러닝의 라이프사이클을 표준화하고 합리화하기 위한 머신 러닝 운영 관행인 우수한 “MLOps”가 필요합니다. 하지만 풍경이나 다른 정의로 넘어가기 전에, 왜 우리가 더 나은 MLOps가 필요한지에 대해 조금 더 이야기하고 싶습니다.

머신 러닝은 어느 정도 성숙했지만 구축 관행 및 비즈니스에 미치는 영향은 미미함

학술적 공간에서 기계 학습은 진보된 도약과 한계를 가지고 있다. 알고리즘은 NLP와 같은 어려운 작업에서 이전 작업에 비해 크게 개선되었으며(그것이 구글이 더 많은 데이터+컴퓨터를 던지더라도), arXiv의 기계 학습 논문 수는 18개월마다 두 배씩 증가하고 있다고 한다.

이러한 흥분으로 인해 성과물에 대한 집중력, 즉 가시적인 영향에 대한 집중력을 잃기 쉽습니다. 2018년부터 진행된 이번 데이터브릭스 조사는 대다수의 기업들이 AI를 채택하거나 투자하고 있지만, ‘AI’ 프로젝트가 완료되기까지 평균 6개월이 걸리는 등 보편적으로 솔루션의 어려움을 꼽고 있는 것으로 나타났다.

조심하지 않으면 데이터 과학자가 말 그대로 Python 노트북 및 모델을 엔지니어에게 e-메일로 보내 프로덕션 구현 및 코드 재작성 작업을 수행할 수 있습니다. 아마도 이 잘 문서화되어 있지 않은 파이썬 코드는 도커에게 너무 비효율적이거나 불완전하지만, 자바어로 번역하는 데도 많은 시간이 걸릴 것이다. 광범위한 문서 없이 엔지니어는 .pickle 파일에 wtf가 있는 것을 알지 못합니다. 모델, 메트릭 및 매개변수에 대한 0 버전 제어 기능이 있습니다. 그리고 모든 사람들은 혼란스럽고 화가 납니다. 왜냐하면 이제 그들은 몇 개월이 아니라 며칠이 걸릴 어떤 것에 맞춰야 하는 고통스러운 회의에 갇혀 있기 때문입니다.

그뿐만 아니라 솔루션이 생산되면 개선 및 업데이트를 위한 고유한 피드백 시스템이 없습니다. 특정 시스템의 경우, 시간이 지남에 따라 모델 성능이 저하될 수 있으며 모니터링이 항상 표준적인 관행은 아닙니다. 데이터 과학자는 또한 우수한 테스트 사례를 작성하는 것과 같은 작업을 수행하도록 교육받지 않았으므로, 주피터부터 프로덕션까지 모델 업데이트가 때때로 애플리케이션을 손상시키거나 잘못된 예측을 제공하더라도 놀라지 않을 것입니다.

이러한 문제는 보편적이지 않으며 많은 맞춤형 솔루션이 존재한다는 점을 분명히 말씀드리고 싶습니다. 그러나 데이터 과학자, 엔지니어 및 비즈니스의 요구 사항을 충족시키고 충족시키는 단일 사례 및 엔드 투 엔드 솔루션 세트가 아직 구현되지 않았습니다.

기계 학습 작업 입력(MLOps)

나는 가장 순수한 형태의 MLOps를 자동화된 ML 라이프사이클의 진정한 인스턴스화라고 정의할 것이다. MLOps를 위한 위키피디아 페이지의 첫 번째 단락도 모든 것을 말해줍니다. MLOps는 기업이 머신 러닝을 생산에 투입하는 데 현재 직면하고 있는 어려움에 대한 논리적 대응입니다. 소프트웨어 엔지니어링에는 DevOps가 있습니다. 그렇다면 MLOps는 어떨까요? Good DevOps는 소프트웨어 개발 라이프사이클이 효율적이고, 잘 문서화되어 있으며, 문제 해결이 용이하도록 보장합니다. 이제는 기계 학습을 위한 유사한 표준을 개발할 때입니다.

산업은 한계점에 도달하기 시작했고 기술은 수요를 충족시키고 생산에서 ML의 현재 표준을 변경하기 위해 빠르게 진화하고 있습니다. mlflow와 kubeflow와 같은 오픈 소스 프레임워크는 오픈 소스 환경의 표준이 되기 위해 경쟁하는 반면, 새로운 스타트업들은 “독자적인” MLOps 제품을 시장에 내놓기 위해 이러한 솔루션에 UI를 적용한다.

MLOps의 상태

물론, MLOps는 아직 다소 초기 단계에 있다. 데이터 과학에서 “MLOps”를 검색하면 (쓰기 시) 겨우 2개의 결과가 나옵니다. 엄밀히 말하면, mlflow 또는 kubeflow와 같은 도구를 사용하여 완벽하게 관리되는 솔루션은 여전히 실제로 사용하기 위해 상당한 양의 개발 및/또는 직원 교육이 필요합니다.

이제, 여러분은 제가 MLOps 원리의 정확한 목록을 제시하지 않았다는 것을 알게 될 것입니다. 왜냐하면 저는 아직 보편적 집합이 존재하는지 확신할 수 없기 때문입니다. 이 생각은 여전히 유동적이며, 진정한 원칙은 새로운 프레임워크와 실제 교훈의 결실로 공식화될 것이다. DevOps와 마찬가지로 MLOps도 좋을 수도 있고 나쁠 수도 있으며, 시간이 지남에 따라 둘 사이의 경계선이 명확해질 수도 있습니다.

지금은 좋은 DevOps 관행을 따르는 것이 최선이라고 생각합니다. 물론 이 작업을 더 쉽게 하는 툴도 있지만, 프레임워크에 구애받지 않는 POV에서 볼 때, 좋은 MLOps는 좋은 DevOps와 매우 비슷할 것이라고 생각합니다. MLOps의 목표는 여전히 명확하며, 좋은 MLOps는 다음을 가능한 한 효율적으로 수행할 수 있습니다.

모델을 생산에 투입하는 시간과 어려움 감소
팀 간 마찰 감소 및 협업 강화
모델 추적, 버전 관리, 모니터링 및 관리 개선
최신 ML 모델의 진정한 주기적 라이프사이클 생성
기계 학습 프로세스를 표준화하여 규제 및 정책 증가에 대비

결론과 주의사항

저는 여러분이 업계에서 어느 위치에 있냐에 따라 여러분은 제가 풍경에 대해 추측한 것에 동의하거나 동의하지 않을 수도 있다고 확신합니다. 이러한 관점은 나의 제한된 경험의 결과이며, 따라서 오해의 소지가 있다. 오비-완이 아나킨에게 말했듯이, “시스는 절대적인 것을 다룬다.” 그리고 나는 그것이 모든 것에 대한 나의 주관적인 분석에서 진실이라고 믿는다.