MLOps에 대한 가장 자세한 가이드: 1부

안녕하세요 해커눈입니다! 이번 글에서는 MLOps의 개념에 대해 자세히 설명하겠습니다. 게다가 3가지 방법으로 할게요. 첫째, 이론적으로는 가장 합리적인 MLOps 체계를 사용합니다. 그런 다음 개념적으로 접근 방식에 포함된 아티팩트를 통해. 마지막으로 MLOps를 정보 시스템으로 이해합니다.

자, 시작합시다.

MLOps란 무엇인가요?

이 질문은 오랫동안 많은 ML 시스템 개발팀의 마음을 사로잡았습니다. 이 기사에서는 이러한 시스템을 통해 전체 비즈니스 로직의 일부를 수행하는 훈련된 모델이 포함된 하나 이상의 구성 요소인 정보 시스템을 이해합니다.

시스템의 다른 구성 요소와 마찬가지로 비즈니스 로직의 이 부분도 변화하는 비즈니스 및 고객 기대를 충족하기 위해 업데이트되어야 합니다. MLOps는 이 정기 업데이트에 관한 모든 것입니다.

MLOps 정의 및 설명

아직까지 MLOps에 대해 합의된 단일 정의가 없습니다. 많은 작가들이 이를 제시하려고 노력했지만, 동시에 명확하고 체계적인 설명을 찾는 것이 어려웠습니다.

다음과 같이 간주될 수 있는 것이 있습니다.

MLOps는 ML 시스템 개발(개발)과 ML 시스템 배포(운영)를 통합하여 프로덕션에서 고성능 모델의 지속적인 제공을 표준화하고 간소화하는 것을 목표로 하는 엔지니어링 분야입니다.

MLOps 정의의 중요한 부분을 강조해 보겠습니다.

• 공학 분야
• ML 시스템의 개발 및 배포 프로세스를 통합하는 것을 목표로 합니다.
• 새 버전의 지속적인 제공을 표준화하고 최적화합니다.
• 고성능 모델

따라서 MLOps는 ML 모델을 위한 일종의 DevOps입니다.

MLOps 출현의 역사

이러한 엔지니어링 규율이 대규모 IT 회사에서 유래했다고 믿기 쉽습니다. 따라서 우리는 의미 있는 접근 방식인 MLOps가 Google에서 시작되었다는 이론을 신뢰할 수 있습니다. Google에서는 D. Sculley가 ML 모델을 확장 프로그램으로 출력하는 것과 관련된 일상적인 작업에서 신경과 시간을 절약하려고 노력했습니다. D. Sculley는 이제 "MLOps의 대부"로 널리 알려져 있습니다. 같은 이름의 팟캐스트는 온라인에서 쉽게 찾을 수 있습니다.

D. Sculley는 팀의 기술 부채 관점에서 모델 작업을 고려하기 시작했습니다. 예, 새 버전의 모델을 신속하게 출시할 수는 있지만 결과 시스템을 지원하는 비용은 회사 예산에 상당한 영향을 미칩니다.

그의 작업으로 인해 "머신러닝 시스템의 숨겨진 기술 부채 "는 2015년 NeurIPS 컨퍼런스에서 발표되었습니다. 이 글이 발표된 날짜는 MLOps 존재의 출발점이라고 볼 수 있습니다.

MLOps 성숙도 수준: 가장 잘 알려진 모델

대부분의 IT 프로세스와 마찬가지로 MLOps에도 성숙도 수준이 있습니다. 이는 기업이 현재 어디에 있는지, 다음 단계로 어떻게 이동할 수 있는지(그러한 목표가 있는 경우) 이해하는 데 도움이 됩니다. 또한 일반적으로 인정되는 성숙도 결정 방법을 사용하면 경쟁업체 중에서 귀하의 위치를 결정할 수 있습니다.

GigaOm MLOps 성숙도 모델

가장 철저하게 설명되고 이해하기 쉬운 모델은 분석 회사 GigaOm 의 모델입니다. 모든 모델 중 CMMI(Capability Maturity Model Integration)에 가장 가깝습니다. 이는 조직 프로세스를 개선하기 위한 일련의 방법론으로, 0에서 4까지 5단계로 구성됩니다.

GigaOm의 모델은 전략, 아키텍처, 모델링, 프로세스 및 거버넌스라는 5가지 범주를 통해 각 성숙도 수준을 풀어냅니다.

ML 시스템 구축 초기 단계에서 이 모델을 활용하면 필수 측면을 미리 생각하고 실패 가능성을 줄일 수 있습니다. 한 성숙도 수준에서 더 높은 성숙도 수준으로 이동하면 팀은 이전에는 존재하지 않았던 새로운 과제에 직면하게 됩니다.

Google MLOps 성숙도 모델

Google에도 MLOps 성숙도 모델이 있다는 점은 주목할 가치가 있습니다. 가장 먼저 등장한 것 중 하나였습니다. 간결하며 3가지 레벨로 구성됩니다.

• 수준 0: 수동 프로세스
• 레벨 1: ML 파이프라인 자동화
• 레벨 2: CI/CD 파이프라인 자동화

이 모델이 부엉이 그림을 그리는 설명서와 비슷하다는 생각을 피하기 어렵습니다. 먼저 모든 작업을 수동으로 수행하고, ML 파이프라인을 조립하고, MLOps를 마무리합니다. 즉, 잘 설명되어 있습니다.

Azure MLOps 성숙도 모델

오늘날 ML을 사용하는 많은 대기업은 성숙도 모델을 정리했습니다. 하늘빛 수준을 구별하기 위해 유사한 접근 방식을 사용하는 가 포함되어 있습니다. 그러나 Google보다 더 많은 것들이 있습니다:

• 수준 0: MLOps 없음
• 수준 1: DevOps는 있지만 MLOps는 없음
• 레벨 2: 자동화된 훈련
• 레벨 3: 자동화된 모델 배포
• 수준 4: 전체 MLOps 자동화된 작업

강조 표시된 모든 모델은 대략 한 가지로 수렴됩니다. 0 수준에서는 ML 관행이 없습니다. 마지막 수준에는 MLOps 프로세스 자동화가 있습니다. 증분 프로세스 자동화와 관련하여 중간에는 항상 다른 것이 있습니다. Azure에는 학습 프로세스와 모델 배포가 자동화되어 있습니다.

MLOps 개념 프레임워크

MLOps 개념과 관련된 모든 프로세스를 어떻게 설명하나요? 놀랍게도 세 명의 독일인 – 기사의 저자 " MLOps(기계 학습 작업): 개요, 정의 및 아키텍처 " - 이를 하나의 다이어그램으로 요약할 수도 있었습니다. 그들은 실제 연구를 수행하고 MLOps의 개념을 매우 자세하게 설명했습니다.

서로 상호 작용하는 요소가 많기 때문에 위협적일 수 있습니다. 그러나 위에서 언급한 성숙도 수준의 특징 중 많은 부분이 여기에도 발견됩니다. 최소한 자동화된 파이프라인, CI/CD, 모니터링, 모델 레지스트리, 워크플로 조정 및 구성 요소 제공.

이 다이어그램을 논의하고 각 다이어그램에 대해 더 자세히 이야기해 보겠습니다.

MLOps 핵심 프로세스

체계의 주요 부분은 MLOps의 절차적 측면이 설명되는 수평 블록입니다(문자 A, B, C 및 D가 할당됨). 각각은 회사의 ML 서비스의 원활한 운영을 보장하는 프레임워크 내에서 특정 작업을 해결하도록 설계되었습니다. 계획을 쉽게 이해하려면 순서대로 시작하는 것이 좋습니다.

실험

회사에 ML 서비스가 있는 경우 직원은 Jupyter에서 일합니다. 많은 회사에서 이는 모든 ML 개발 프로세스의 중심이 되는 도구입니다. MLOps 관행을 구현해야 하는 대부분의 작업이 시작되는 곳입니다.

예를 생각해 봅시다. A사는 머신러닝을 활용하여 일부 프로세스의 일부를 자동화해야 합니다(해당 부서와 전문가가 있다고 가정). 문제를 해결하는 방법이 미리 알려져 있을 가능성은 거의 없습니다. 따라서 실행자는 문제 설명을 연구하고 가능한 실현 방법을 테스트해야 합니다.

이를 위해 ML 엔지니어/ML 개발자는 다양한 작업 구현을 위한 코드를 작성하고 대상 측정항목으로 얻은 결과를 평가합니다. 이 모든 작업은 거의 항상 Jupyter Lab에서 수행됩니다. 이러한 형태에서는 많은 중요한 정보를 수동으로 캡처한 다음 구현을 서로 비교해야 합니다.

이러한 활동을 실험이라고 합니다. 이는 관련 문제를 해결하는 데 추가로 사용할 수 있는 작동하는 ML 모델을 얻는 것을 의미합니다.

다이어그램에 표시된 블록 C는 ML 실험을 수행하는 과정을 설명합니다.

업무 범위 내에서 이용 가능한 데이터 분석

ML 개발의 많은 결정은 회사에서 사용 가능한 데이터 분석을 기반으로 이루어집니다. 품질이 낮은 데이터나 존재하지 않는 데이터에 대한 목표 품질 측정항목을 사용하여 모델을 학습하는 것은 불가능합니다.

따라서 우리가 얻은 데이터가 무엇인지, 그리고 그 데이터로 무엇을 할 수 있는지 파악하는 것이 중요합니다. 이를 위해 예를 들어 다음과 같이 할 수 있습니다.

• Jupyter 또는 Superset을 사용하여 ADHoc 연구 수행
• 표준 EDA(탐색적 데이터 분석)

데이터에 대한 더 나은 이해는 의미론적 및 구조적 분석과 결합될 때만 얻을 수 있습니다.

그러나 데이터 준비가 프로젝트 팀의 통제 범위 내에 있는 경우도 있습니다. 이 경우 추가적인 어려움이 보장됩니다. 때로는 이 단계에서 데이터가 업무에 적합하지 않기 때문에 프로젝트를 더 발전시킬 필요가 없다는 것이 분명해집니다.

품질 데이터세트의 형성

사용 가능한 데이터에 확신이 있으면 전처리 규칙에 대해 생각해 볼 필요가 있습니다. 적합한 데이터 세트가 많다고 해도 누락, 왜곡된 값 등이 포함되지 않는다는 보장은 없습니다. "입력 데이터 품질"이라는 용어와 잘 알려진 "Garbage in - Garbage out"이라는 문구를 언급해야 합니다. 여기.

아무리 좋은 모델을 사용해도 품질이 낮은 데이터에서는 좋지 않은 결과가 나올 수 있습니다. 실제로 고품질 데이터 세트를 생성하는 데 많은 프로젝트 리소스가 사용됩니다.

ML 모델 학습 및 검증

이전 단계 이후에는 실험을 수행할 때 훈련된 모델의 측정항목을 고려하는 것이 합리적입니다. 고려 중인 블록의 프레임워크 내에서 실험은 ML 모델의 훈련과 검증을 연결하는 것으로 구성됩니다.

실험은 준비된 데이터세트에서 선택된 하이퍼파라미터 세트를 사용하여 원하는 버전의 모델을 훈련하는 고전적인 방식으로 구성됩니다. 이를 위해 데이터 세트 자체는 훈련, 테스트 및 검증 샘플로 구분됩니다.

• 처음 두 개는 최적의 하이퍼파라미터 세트를 선택하는 데 사용됩니다.
• 세 번째는 선택된 하이퍼파라미터 세트에 대해 훈련된 모델이 하이퍼파라미터 선택 및 훈련 과정에 참여하지 않은 알려지지 않은 데이터에 대해서도 적절하게 동작하는지 최종 검증하고 확인하는 것입니다.

검증 샘플에 대한 자세한 내용은 다음에서 확인할 수 있습니다. 이 기사 .

저장소에 코드 및 하이퍼파라미터 저장

모델 학습 지표가 양호하면 모델 코드와 선택한 매개변수가 기업 저장소에 저장됩니다.

실험 프로세스의 기본 목표는 모델 엔지니어링이며, 이는 최상의 알고리즘 선택과 최상의 하이퍼파라미터 튜닝 선택을 의미합니다.

실험을 수행할 때 어려운 점은 개발자가 ML 모델 작동 매개변수의 다양한 조합을 확인해야 한다는 것입니다. 그리고 우리는 사용된 수학적 장치의 다양한 변형에 대해 말하는 것이 아닙니다.

일반적으로 작업이 필요합니다. 그리고 모델 매개변수 조합 프레임워크 내에서 원하는 측정항목이 달성되지 않으면 어떻게 해야 합니까?

기능 엔지니어링

ML 모델 작업의 원하는 측정항목을 달성할 수 없는 경우 새로운 기능으로 데이터세트 개체의 기능 설명을 확장해 볼 수 있습니다. 이로 인해 모델의 컨텍스트가 확장되어 원하는 측정항목이 향상될 수 있습니다.

새로운 기능은 다음과 같습니다:

• 표 형식 데이터의 경우: 이미 존재하는 개체 속성의 임의 변환(예: X^2, SQRT(X), Log(x), X1*X2 등)
• 과목별 : 체질량지수, 연간 대출금 연체횟수 등

기능 엔지니어링과 관련된 다이어그램 부분을 살펴보겠습니다.

블록 B1은 사용 가능한 소스 데이터를 변환하고 그로부터 기능을 얻기 위한 일련의 요구 사항을 형성하는 것을 목표로 합니다. 구성 요소 자체의 계산은 ML 개발자가 입력한 "공식"에 따라 매우 전처리되고 정리된 데이터에서 수행됩니다.

기능 작업은 반복적이라는 점이 중요합니다. 한 가지 기능 세트를 적용하면 새로운 아이디어가 떠오를 수 있고, 다른 기능 세트로 구현되는 등 무한히 계속될 수 있습니다. 이는 다이어그램에서 피드백 루프로 명시적으로 표시됩니다.

블록 B2는 데이터에 새로운 기능을 추가하는 즉각적인 프로세스를 설명합니다.

데이터 소스에 연결하고 검색하는 것은 상당히 복잡할 수 있는 기술적인 작업입니다. 설명을 단순화하기 위해 팀이 액세스할 수 있는 여러 소스와 이러한 소스에서 데이터를 언로드할 수 있는 도구(적어도 Python 스크립트)가 있다고 가정하겠습니다.

데이터 정리 및 변환. 이 단계는 실험 블록(C)의 유사한 단계인 데이터 준비와 거의 유사합니다. 이미 첫 번째 실험 세트에서 ML 모델 학습에 필요한 데이터와 형식이 무엇인지 이해하고 있습니다. 남은 것은 새로운 기능을 올바르게 생성하고 테스트하는 것뿐입니다. 그러나 이 목적을 위한 데이터 준비 프로세스는 최대한 자동화되어야 합니다.

새로운 특징의 계산. 위에서 언급한 것처럼 이러한 작업은 단순히 데이터 튜플의 몇 가지 요소를 변환하는 것으로 구성될 수 있습니다. 또 다른 옵션은 별도의 대규모 처리 파이프라인을 실행하여 동일한 데이터 튜플에 단일 기능을 추가하는 것입니다. 어느 쪽이든 순차적으로 실행되는 일련의 작업이 있습니다.

결과를 추가합니다. 이전 작업의 결과가 데이터세트에 추가됩니다. 대부분의 경우 데이터베이스 부하를 줄이기 위해 기능이 데이터세트에 일괄적으로 추가됩니다. 그러나 때로는 비즈니스 작업 실행 속도를 높이기 위해 즉시(스트리밍) 수행해야 하는 경우도 있습니다.

획득한 기능을 최대한 효율적으로 사용하는 것이 중요합니다. 이를 저장하고 회사의 다른 ML 개발자의 작업에 재사용합니다. 이 계획에는 이러한 목적을 위한 Feature Store가 있습니다. 회사 내부에서 사용할 수 있어야 하고, 별도로 관리되어야 하며, 여기에 포함된 모든 기능의 버전이 지정되어야 합니다. Feature Store는 온라인(스트리밍 스크립트용)과 오프라인(배치 스크립트용)의 두 부분으로 구성됩니다.

자동화된 ML 워크플로

기사 시작 부분에서 나는 ML 시스템이 전체 비즈니스 로직의 일부를 수행하는 훈련된 모델을 포함하는 하나 이상의 구성 요소인 정보 시스템을 의미한다고 표시했습니다. 개발을 통해 얻은 ML 모델이 좋을수록 운영 효과도 커집니다. 훈련된 모델은 들어오는 요청 스트림을 처리하고 이에 대한 일부 예측을 제공하여 분석 또는 의사 결정 프로세스의 일부를 자동화합니다.

예측을 생성하기 위해 모델을 사용하는 프로세스를 추론이라고 하며, 모델을 훈련하는 것을 훈련이라고 합니다. 둘 사이의 차이점에 대한 명확한 설명은 Gartner에서 빌릴 수 있습니다. 여기서는 고양이에 대해 연습하겠습니다.

프로덕션 ML 시스템의 효율적인 운영을 위해서는 모델의 추론 측정항목을 계속 주시하는 것이 중요합니다. 삭제가 시작되자마자 모델을 다시 학습하거나 새 모델로 교체해야 합니다. 대부분의 경우 입력 데이터의 변경(데이터 드리프트)으로 인해 발생합니다. 예를 들어, 모델이 사진 속 컵케이크를 인식할 수 있고 이를 입력으로 제공하는 비즈니스 문제가 있습니다. 예제의 치와와 개는 균형을 유지하기 위한 것입니다.

원본 데이터 세트의 모델은 치와와 개에 대해 아무것도 모르므로 잘못 예측합니다. 따라서 데이터 세트를 변경하고 새로운 실험을 수행할 필요가 있습니다. 새 모델은 가능한 한 빨리 생산에 들어가야 합니다. 사용자가 치와와 강아지 이미지를 업로드하는 것을 금지하는 사람은 없지만 잘못된 결과를 얻게 됩니다.

이제 더 많은 실제 사례를 살펴보겠습니다. 시장을 위한 추천 시스템 개발을 고려해 보겠습니다.

사용자의 구매 내역, 유사한 사용자의 구매 및 기타 매개변수를 기반으로 모델 또는 모델 앙상블은 권장 사항이 포함된 블록을 생성합니다. 여기에는 구매 수익이 정기적으로 계산되고 추적되는 제품이 포함됩니다.

어떤 일이 일어나고 고객의 요구 사항이 변합니다. 결과적으로 그들의 권장 사항은 더 이상 관련이 없습니다. 추천 제품에 대한 수요가 감소합니다. 이 모든 것이 수익 감소로 이어집니다.

다음 관리자는 비명을 지르며 내일까지 모든 것을 복원하라고 요구하지만 아무 소용이 없습니다. 왜? 새로운 고객 선호도에 대한 데이터가 부족해서 새로운 모델을 만들 수도 없습니다. 추천 생성(항목 기반 협업 필터링)의 몇 가지 기본 알고리즘을 사용하여 프로덕션에 추가할 수 있습니다. 이런 방식으로 권장 사항이 어떻게든 작동하지만 이는 일시적인 해결 방법일 뿐입니다.

이상적으로는 관리자가 지시하지 않고도 측정항목을 기반으로 다양한 모델을 재교육하거나 실험하는 프로세스가 시작되도록 프로세스를 설정해야 합니다. 그리고 가장 좋은 제품은 결국 생산 중인 현재 제품을 대체하게 됩니다. 다이어그램에서 이는 일부 오케스트레이션 도구의 트리거에 의해 시작되는 자동화된 ML 워크플로 파이프라인(블록 D)입니다.

이것은 구성표에서 가장 부하가 많은 부분입니다. 블록 D의 작동에는 몇 가지 주요 타사 구성 요소가 포함됩니다.

• 지정된 일정이나 이벤트에 따라 파이프라인을 시작하는 작업 흐름 조정자 구성 요소
• 모델에 필요한 특성에 대한 데이터를 가져오는 Feature Store
• 출시된 파이프라인 작업 후 얻은 모델과 해당 메트릭이 배치되는 모델 레지스트리 및 ML 메타데이터 저장소

블록 자체의 구조는 실험 단계와 기능 개발(B2) 블록을 결합합니다. 자동화가 필요한 프로세스라는 점을 고려하면 이는 놀라운 일이 아닙니다. 주요 차이점은 마지막 2단계에 있습니다.

• 모델 내보내기
• 모델 레지스트리로 푸시

나머지 단계는 위에서 설명한 단계와 동일합니다.

별도로, 오케스트레이터가 모델 재교육 파이프라인을 실행하는 데 필요한 서비스 아티팩트에 대해 언급하고 싶습니다. 이는 저장소에 저장되고 선택된 서버에서 실행되는 코드입니다. 소프트웨어 개발의 모든 규칙에 따라 버전이 지정되고 업그레이드됩니다. 이 코드는 모델 재훈련 파이프라인을 구현하며 결과는 정확성에 따라 달라집니다.

대개 파이프라인 단계가 실행되는 코드 내에서 다양한 ML 도구가 실행됩니다. 예를 들면 다음과 같습니다.

• 공기 흐름 오케스트레이터는 코드를 실행하여 파이프라인 단계를 실행합니다.
• Feast는 명령을 통해 데이터 세트의 기능에 대한 데이터를 언로드합니다.
• 그런 다음 ClearML은 새 데이터세트를 생성하고 자체 저장소에서 가져오는 필요한 모델 성능 측정항목 세트를 사용하여 실험을 실행합니다.
• 조사가 완료되면 ClearML은 모델과 해당 성능 지표를 스토리지에 저장합니다.

여기서는 일반적으로 실험을 자동화하는 것이 불가능하다는 점을 주목할 가치가 있습니다. 물론 프로세스에 AutoML 개념을 추가하는 것도 가능합니다. 그러나 현재 실험의 모든 주제에 대해 동일한 결과를 사용할 수 있는 알려진 솔루션은 없습니다.

일반적인 경우 AutoML은 다음과 같이 작동합니다.

1. 어떻게든 모델 작동 매개변수의 다양한 조합 세트를 생성합니다.
2. 각 결과 조합에 대해 실험을 실행합니다. 최상의 모델이 선택되는 각 실험에 대한 측정항목을 수정합니다.
3. AutoML은 주니어/중간 데이터 과학자가 다소 표준적인 작업 범위에서 수행하는 모든 조작을 수행합니다.

자동화가 약간 처리되었습니다. 다음으로, 새 버전의 모델을 프로덕션 환경에 전달하도록 구성해야 합니다.

모델 제공 및 모니터링

예측을 생성하려면 ML 모델이 필요합니다. 하지만 ML 모델 자체는 파일이기 때문에 그렇게 빨리 생성할 수는 없습니다. 이러한 솔루션은 인터넷에서 종종 찾을 수 있습니다. 팀에서는 FastAPI를 사용하여 모델 주위에 Python 래퍼를 작성하므로 "술어를 따를" 수 있습니다.

ML 모델 파일이 수신되는 순간부터 여러 가지 방법으로 상황이 전개될 수 있습니다. 팀은 다음을 수행할 수 있습니다.

• RESTfull 서비스를 구축하기 위한 모든 코드 작성
• 주변의 모든 래핑을 구현합니다.
• Docker 이미지로 모두 빌드
• 그런 다음 해당 이미지의 어딘가에서 컨테이너를 만들 수 있습니다.
• 어떻게든 확장하세요
• 측정항목 컬렉션 구성
• 알림 설정
• 모델의 새 버전 출시를 위한 규칙 설정
• 다른 많은 것들

모든 모델에 대해 이를 수행하고 향후 전체 코드 기반을 유지 관리하는 것은 노동 집약적인 작업입니다. 더 쉽게 하기 위해 3가지 새로운 항목을 도입한 특별한 제공 도구가 나타났습니다.

• 추론 인스턴스/서비스
• 추론 서버
• 서빙 엔진

추론 인스턴스 또는 추론 서비스는 쿼리를 수신하고 응답 예측을 생성하도록 준비된 특정 ML 모델입니다. 이러한 엔터티는 필요한 ML 모델과 이를 실행하는 기술 도구가 포함된 컨테이너가 포함된 Kubernetes 클러스터의 하위를 나타낼 수 있습니다.

추론 서버는 추론 인스턴스/서비스의 생성자입니다. 추론 서버의 구현은 다양합니다. 각각은 특정 ML 프레임워크와 함께 작동하여 훈련된 모델을 입력 쿼리 처리 및 예측 생성을 위해 즉시 사용 가능한 모델로 변환할 수 있습니다.

서빙 엔진은 기본 관리 기능을 수행합니다. 사용할 추론 서버, 시작해야 하는 추론 인스턴스의 복사본 수, 확장 방법을 결정합니다.

고려 중인 계획에는 모델 제공 구성 요소에 대한 세부적인 내용은 없지만 유사한 측면이 설명되어 있습니다.

• 프로덕션에서 즉시 실행할 수 있는 모델을 배포하는 CI/CD 구성 요소(서빙 엔진 버전 중 하나로 간주될 수 있음)
• 모델 제공은 사용 가능한 인프라 내에서 스트리밍 및 배치 시나리오 모두에 대해 ML 모델에 대한 예측 생성 체계를 구성합니다(추론 서버 버전 중 하나로 간주될 수 있음).

서빙을 위한 전체 스택의 예를 보려면 Seldon의 스택을 참조할 수 있습니다.

• Seldon Core는 서비스 엔진입니다.
• Seldon ML Server는 REST 또는 gRPC를 통해 모델에 대한 액세스를 준비하는 추론 서버입니다.
• Seldon MLServer Custom Runtime은 예측을 생성하기 위해 예제를 실행해야 하는 모든 ML 모델에 대한 셸 인스턴스인 추론 인스턴스입니다.

심지어 서비스 구현을 위한 표준화된 프로토콜도 있는데, 이는 모든 도구에서 사실상 필수 지원입니다. 이는 V2 추론 프로토콜이라고 하며 KServe, Seldon 및 Nvidia Triton과 같은 몇몇 저명한 시장 참가자에 의해 개발되었습니다.

제공 및 배포

다양한 문서에서 단일 엔터티로 제공 및 배포하기 위한 도구에 대한 참조를 찾을 수 있습니다. 그러나 두 가지 목적의 차이점을 이해하는 것이 중요합니다. 이는 논쟁의 여지가 있는 문제이지만 이 기사에서는 다음과 같이 설명합니다.

• 서빙 - API 모델 생성 및 이를 통해 예측을 얻을 수 있는 가능성입니다. 결국 내부에 모델이 포함된 단일 서비스 인스턴스를 얻게 됩니다.
• 배포 - 들어오는 요청을 처리하는 데 필요한 수량만큼 서비스 인스턴스를 배포합니다(Kubernetes 배포에서 복제본 세트로 표시될 수 있음).

모델 배포에는 다양한 전략을 사용할 수 있지만 이는 ML에만 국한되지 않습니다. 그건 그렇고, Seldon의 유료 버전은 여러 가지 전략을 지원하므로 이 스택을 선택하고 모든 것이 어떻게 작동하는지 즐길 수 있습니다.

모델 성능 지표를 추적해야 한다는 점을 기억하세요. 그렇지 않으면 제 시간에 문제를 해결할 수 없습니다. 측정항목을 정확히 추적하는 방법이 가장 큰 문제입니다. Arize AI는 이를 기반으로 전체 비즈니스를 구축했지만 Grafana와 VictoriaMetrics를 취소한 사람은 아무도 없습니다.

프로젝트 개시

위에 작성된 모든 내용을 고려하면 ML 명령은 다음과 같습니다.

• 데이터 세트 생성
• ML 모델에서 실험을 수행합니다.
• 데이터 세트를 확장하고 모델 품질을 향상시키는 새로운 기능을 개발합니다.
• 향후 재사용을 위해 모델 레지스트리에 최상의 모델을 저장합니다.
• 모델 제공 및 배포 맞춤설정
• 생산 중인 모델의 모니터링과 현재 모델의 자동 재교육 또는 새 모델 생성을 사용자 정의합니다.

비용이 많이 들고 때로는 정당화되는 경우도 있습니다. 따라서 다이어그램에는 합리적인 목표 설정을 담당하는 별도의 MLOps 프로젝트 시작(A) 블록이 있습니다.

IT 책임자의 추론 사례는 여기서 사고 방식을 보여줄 수 있습니다. 영감을 받은 프로젝트 관리자가 그에게 와서 ML 시스템 구축을 위한 새로운 플랫폼 설치를 요청합니다. 둘 다 회사의 최선의 이익을 위해 행동하는 경우 IT 책임자는 다음과 같은 명확한 질문을 받게 됩니다.

• 새로운 ML 시스템으로 어떤 비즈니스 문제를 해결하시겠습니까?
• 새로운 ML 시스템이 이 문제를 해결해야 한다고 결정한 이유는 무엇입니까?
• 프로세스를 변경하거나 기술 지원 인력을 더 고용하는 것이 더 쉽고 저렴할까요?
• 현재 선택의 기반이 된 ML 시스템 구성 요소에 대한 비교 분석은 어디에서 확인할 수 있습니까?
• 선택한 ML 시스템 아키텍처는 비즈니스 문제를 해결하는 데 어떻게 도움이 됩니까?
• ML이 식별된 문제를 해결하는 데 필요한 수학적 장치를 갖추고 있다고 확신하시나요?
• 솔루션에 대한 문제 설명은 무엇입니까?
• 모델을 훈련하기 위한 데이터는 어디서 얻을 수 있나요? 모델을 준비하는 데 어떤 데이터가 필요한지 알고 있나요?
• 이미 사용 가능한 데이터를 검토하셨나요?
• 데이터의 품질이 모델을 해결하기에 충분합니까?

IT 책임자는 대학의 교사 자리에서 물러나지만 회사의 비용은 절약될 것입니다. 모든 질문에 답했다면 ML 시스템이 실제로 필요하다는 뜻입니다.

다음 질문: MLOps를 수행해야 합니까?

문제에 따라 다릅니다. 예를 들어 PoC(개념 증명)와 같은 일회성 솔루션을 찾아야 하는 경우 MLOps가 필요하지 않습니다. 많은 수신 요청을 처리해야 하는 경우 MLOps가 필요합니다. 본질적으로 이 접근 방식은 기업 프로세스를 최적화하는 것과 유사합니다.

관리에 대한 MLOps의 필요성을 정당화하려면 다음 질문에 대한 답변을 준비해야 합니다.

• 무엇이 좋아질까요?
• 얼마나 많은 돈을 절약할 수 있나요?
• 직원을 늘려야 할까요?
• 우리는 무엇을 사야 합니까?
• 전문 지식을 어디서 얻을 수 있나요?

다음으로 할 일은 IT 디렉터 시험에 다시 응시하는 것이다.

팀은 작업 프로세스와 기술 스택을 변경해야 할 필요성도 확신해야 하기 때문에 과제는 계속됩니다. 때때로 이는 경영진에게 예산을 요청하는 것보다 더 어렵습니다.

팀을 설득하려면 다음 질문에 대한 답변을 준비하는 것이 좋습니다.

• 기존의 작업 방식이 더 이상 가능하지 않은 이유는 무엇입니까?
• 변화의 목적은 무엇입니까?
• 기술 스택은 어떻게 될까요?
• 무엇을, 누구에게서 배울 것인가?
• 회사는 변경 사항을 구현하는 데 어떻게 도움을 줄까요?
• 변경하는 데 얼마나 걸리나요?
• 성공하지 못한 사람들은 어떻게 되나요?

보시다시피 이 과정은 간단하지 않습니다.

작은 결론

MLOps 구성표에 대한 자세한 연구는 여기서 끝났습니다. 그러나 이는 이론적인 측면일 뿐입니다. 실제 구현에서는 항상 많은 것을 변경할 수 있는 추가 세부 사항이 드러납니다.

다음 기사에서는 다음 내용을 다룰 것입니다.

• MLOps 아티팩트
• 정보 시스템으로서의 MLOps
• MLOps용 오픈 소스: Kubeflow, MLflow, Pachyderm

관심을 가져주셔서 감사합니다!