A/B 테스트
- 온라인 서비스에서 새 기능의 임팩트를 객관적으로 측정하는 방법
- 의료쪽에서 무작위 대조 시험(Randomized Controlled Trial) - 새로운 기능을 론치함으로 생기는 위험부담을 줄이는 방법
- 100%의 사용자에게 론치하는 것이 아니라 작게 시작하고 관찰 후 결정
- 실제 예제 : 추천을 기계학습기반으로 바꾼 경우
◦ 먼저 5%의 사용자에게 론치 후 나머지 95%의 사용자와 매출액 등 중요 지표 기반 비교
◦ 5%, 10%, 20% 이런 식으로 점진적으로 높이고 최종적으로 100%로 론치 - 보통 사용자들을 2개의 그룹으로 나누고 시간을 두고 관련 지표를 비교
- 한 그룹은 기존 기능에 그대로 노출 (control)
- 다른 그룹은 새로운 기능에 노출 (test) - 가설에서 영향받는 지표를 미리 정하고 시작하는 것이 일반적
- 지표의 경우 성공/실패 기준까지 생각해보는 것이 필요
DevOps, MLOps
마찰이 생기는 지점 - 개발된 모델의 이양 관련
- 많은 수의 데이터 과학자들은 R을 비롯한 다양한 툴로 모델 개발
- 하지만 실제 프로덕션 환경은 다양한 모델들을 지원하지 못함
- 개발/검증된 모델의 프로덕션 환경 론치시 시간이 걸리고 오류 가능성이 존재
- 심한 경우 모델 관련 개발을 다시 해야함 (피쳐 계산과 모델 실행 관련)
Data Drift로 인한 모델 성능 저하
- ML 모델에서 가장 중요한 것은 훈련 데이터
- 시간이 지나면서 훈련에 사용한 데이터와 실제 환경의 데이터가 다르게 변화함
- 이를 Data drift라고 부르며 이를 모니터링하는 것이 중요 - 즉 주기적으로 ML 모델을 다시 빌딩해주는 일이 필요
DevOps vs. MLOps
DevOps가 하는 일
- Deliver software faster and more reliably in automated fashion
- 개발자가 만든 코드를 시스템에 반영하는 프로세스 (CI/CD)
- 시스템 모니터링 그리고 이슈 감지시 escalation 프로세스 수행 (On-call 프로세스)
MLOps가 하는 일
- Deliver ML models faster and more reliably in automated fashion
- 앞의 DevOps가 하는 일과 동일. 차이점은 개발자 코드가 아니라 ML 모델이 대상이 된다는 점
- 모델을 계속적으로 빌딩하고 배포하고 성능을 모니터링
- ML모델 빌딩과 프로덕션 배포를 자동화할 수 있을까? 계속적인 모델 빌딩(CT)과 배포 - 모델 서빙 환경과 모델의 성능 저하를 모니터링하고 필요시 escalation 프로세스 진행
- Latency의 중요성
- Data drift 측정
.