오늘은 머신러닝 프로젝트의 flow에 대하여 정리하려고 한다.
머신러닝 프로젝트 Flow
문제 정의가 중요한 이유
- 특정 현상을 파악하고
그 현상에 있는 문제를 정의하는 과정이다. - 본질을 파악하는 과정
- 문제를 잘 풀기 위해서는 문제정의가 중요하다.
- 해결해야 하는 문제는 무엇이고,
해결하면 무엇이 좋을까?
어떻게 해결하면 좋을까?
How 보다는 Why!
근본적인 사고 능력과
문제를 충분히 정의하고 고민하는 습관을 만드는 것이 중요하다!
전반적인 Flow
- 현상파악
- 목적, 문제 정의 => 계속 생각하기, 쪼개서 생각하기
- 프로젝트 설계
- Action
- 추가 원인 분석
현상파악
어떤 일이 발생하고 있는지,
어떤 현상이 발견되었는지,
해당 일에서 어려운 점은 무엇인지,
해당 일에서 해결하면 좋은 것은 무엇인지,
추가적으로 무엇을 해볼 수 있는지 등
현재 상황을 파악한다.
구체적인 문제 정의
무엇을 해결하고 싶은지
무엇을 알고 싶은지
앞선 현상을 구체적으로 명확한 용어로 정리해본다.
데이터로 할 수 있는 일을 만들어서 진행하되,
무조건 알고리즘 접근이 최상은 아니라는 방법을 제시할 수도 있어야한다.(간단한 방법부터 점진적인 접근)
Tip
- 문제를 쪼개서 파악해보자
- 문제의 해결방식은 다양하다
- 해결 방식 중에서 데이터로 해결할 수 있는 방법을 고민해보기
- 점진적으로 실행하기
프로젝트 설계
최대한 구체적으로 설계하는 것이 좋다.
-> 미리 많은 것을 대비하자.
흥미가 아닌 제품, 회사의 비즈니스에서 어떤 가치를 줄 수 있는지 고려
- 해결하려고 하는 문제 구체화
- 머신러닝 문제 타당성 확인
- 목표 설정, 지표 결정
- 제약조건( Constraint & Risk )
- 베이스라인, 프로토타입
- 평가 방법 설계
머신러닝이 무조건 좋은 솔루션은 아니다.
다만 사용되면 좋은 경우는 아래와 같다.
- 학습할 수 있는 패턴이 있는 경우
- 학습을 위한 목적함수를 만들 수 있는 경우
- 패턴이 복잡한 경우
- 데이터가 존재하거나 수집할 수 있는 경우
- 사람이 반복적으로 실행하는 경우
목표설정
- Goal : 프로젝트의 일반적인 목적, 큰 목적
- Objectives : 목적을 달성하기 위한 세부 단계의 목표(구체적인 목표)
제약조건
- 일정
- 예산
- 관련된 사람
- Privacy
- 기술적 제약
- 기존 환경
- 윤리적 이슈
- 성능
- Threshold
- Baseline
- Performance Trade-off
- 해석 가능 여부
- Confidence Measurement
베이스라인, 프로토타입
- 모델이 더 좋아졌다고 판단할 수 있는 베이스라인이 필요하다.
- 꼭 모델일 필요는 없다.
- 프로토타입을 만들어서 제공 -> Voila, Streamlit, Gradio
Metric Evaluation
- 어떤 지표가 좋을지 고민한다.
- 모델의 성능 지표일 수도 있고 비즈니스의 지표일 수도 있다.
- 지표를 잘 정의해야 우리의 ACTION이 기존보다 더 성과를 냈는지 아닌지를 파악할 수 있다.
Action(모델 개발 후 배포 & 모니터링)
- 앞서 정의한 지표가 어떻게 변하는지 파악
- 현재 만든 모델이 어떤 결과를 내고 있는지
- 잘못 예측하고 있다면 어떤 부분이 문제일지
- 어떤 부분을 기반으로 예측하고 있을지
- Feature의 어떤 값을 사용할 때 특히 잘못 예측하고 있는지
추가 원인 분석
- 새롭게 발견한 상황을 파악해 앞선 순서 반복
'MLOps' 카테고리의 다른 글
도커란? | 가상화, 컨테이너, 도커 개념, 기능 (0) | 2024.01.12 |
---|---|
Docker Compose | 여러 컨테이너 관리하기 (0) | 2023.12.24 |