배포 프로세스Continuous Deployment프로덕션 테스트 필요, 배포 전략 설정(카나리, Shadow, etc.)모델 추론 서비스 배포된 모델이 실제로 사용자에게 결과를 추론해주는 서비스서비스 방식 - Online serving(API), Batch serving, Streaming어플리케이션 형태로도 제공 가능Pre/Post-processing 로직이 필요한 경우 있음.Kserve, Seldon core, TorchServe, Triton inference server, etc.모니터링프로덕션 테스트 포함(실제 데이터에 대한 성능 분석)데이터 모니터링(Data drift 현상 추적)알람 기능Prometheus, Grafana, Elastic, etc.스케쥴러특정 조건에 의해 머신러닝 파이프라인..

데이터 관리개발 환경에 데이터를 전달하고 추론용 데이터를 배포된 서비스에 전달하는 과정 포함 // 데이터의 질과 가용성이 모델의 성능에 큰 영향을 미침데이터 수집 및 데이터 소스 관리 및 연결필요 시 데이터 파이프라인 도입데이터셋 형상 관리를 통한 데이터 변경사항 추적, 버전 관리, 실험 지연성 보장하기 위한 도구S3, Google Cloud Storage, Hadoop, Dataflow, Kafka, etc.모델 개발데이터 분석부터 모델 학습 및 검증에 이르는 전체 과정(새로운 모델을 만드는 것이 목표)데이터 분석 / 검증/ 전처리(Feature Engineering)모델 training (Hyperparameter Tuning) , validation, evaluation실험 관리 : hyperpar..

ML Pipeline(Source code) 도입 Source Repository에 있는 모델을 활용하여 배포 과정 시작, 반드시 개발 환경을 포함하여 배포할 것(docker를 활용하는 부분일 것이라고 추측) Automatic pipeline(Production 과정에서) 기존의 0 단계에서 지적되었던 데이터 관리 문제를 해결하기 위해 Feature store 도입 Data source와 연동되어 데이터 자동 수집 수집된 데이터에 대한 형상관리 기능 추가 데이터 변환(엔지니어링 과정에서 처리도 가능) 가능 및 버전관리 ML metadata store : log 담당 ML Pipeline 실행 기록 어떤 데이터를 활용하여 어떤 모델이 만들어져서 model registry에 어떻게 저장되었는 지 에 대한 기..

0 단계 : 기본단계 Research 과정과 유사한 프로세스를 가져가는 것으로 보임 1. Offline 데이터 추출 및 분석 데이터를 수동관리하고 필요한 시점마다 특정 위치에 데이터를 옮기는 방식 데이터 유출, 일관성 부족, 접근성 저하 의 문제가 있음 데이터의 변화 적용이 어렵기 때문에 모델에서 문제 발생 시 파악할 때 어려움이 존재 2. 학습된 모델을 모델 레지스트리에 저장 실험적인 단계에서는 상관이 없지만 자동화가 되어있지 않기 때문에 휴먼 에러 발생 가능성 존재 Model Registry : 배포(프로덕션) 가능한 모델인지 확인 불가, 모델에 문제가 있을 경우 재학습이 불가능(대응이 어려움) Model Serving : 모니터링 및 로깅 시스템이 없음, 디버깅이 어려움. 데이터 관리 시스템 구축 ..

그렇다면 이런 이유에는 어떤 것들이 있을까? 1. Data drift - feature drift, population, or covariate shift 데이터가 지속적으로 변경되고, 그에 따라 변수들의 분포가 의미있게 달라지게 된다.(과거 형태의 데이터에는 유효한 모델!) 연구용 ML에서는 같은 데이터(주로 benchmark)를 사용하기 때문에 문제가 되는 부분이 아니지만 프로덕션 ML에서는 중요한 부분이라고 생각된다. 2. Training-serving skew 학습한 데이터가 너무 깔끔해서(artificially constructed or cleaned data) 실제로 모델 사용 과정에서 받는 데이터셋(Production data)과 차이가 발생하는 경우 이럴 경우에는 주로 모델을 실제 데이터를..

모델의 성능이 언제까지나 유효한가? No "Past performance is no guarantee of future results." "No model lives forever, but the speed of decay varies." 실 사용사례에서는 데이터가 계속 달라지기 때문에 모델의 성능이 점점 떨어지는 현상을 발생시킨다. 모델의 quality를 판별하는 데에 사용하는 것은 Accuracy, Mean Error Rate, or some downstream business KPI such as click-through rate (꼭 F1 score 만 사용하는 것은 아님) 다양한 모델의 quality 판별을 통해서 검토를 한 결과 성능이 저하게 된다는 것을 "Model decay" 라고 한다.