머신러닝 프로젝트 Flow
▮문제 정의의 중요성
- 문제를 잘 Solve 하기 위해서는 문제 정의가 매우 중요하다.
- 문제 정의란? 특정 현상의 본질을 파악하고 그 현상에 있는 문제를 정의하는 과정이다.
- 풀려고 하는 문제가 명확하지 않으면 그 이후에 무엇을 어떻게 해야할지 결정하기 어렵다.
ex) 저는 사람들을 즐겁게 만들고 싶어요
⇒ 어떤 사람들을 대상으로?
⇒ 즐거움의 정의는 무엇인가? 즐거움의 정의에 따라 무엇을 할 수 있을지가 달라진다.
- Why? 에 대해 고민하는 습관을 만드는 것이 중요하다.
▮프로젝트 FLow
- 현상 파악
- 목적, 문제 정의 ⇒ 쪼개서 생각하기
- 프로젝트 설계
- Action
- 추가 원인 분석
▮ 현상 파악
- 어떤 일이 발생하고 있는가?
- 해당 일에서 어려움은 무엇인가?
- 해결되면 좋은 것은 무엇인가?
- 추가적으로 무엇을 해볼 수 있을까?
- 어떤 가설을 만들어볼 수 있을까?
- 어떤 데이터가 있을까?
▮ 구체적인 문제 정의
- 무엇을 해결하고 싶은가?
- 무엇을 알고 싶은가?
데이터로 할 수 있는 일을 만들어서 진행하되, 시간의 제약이 존재하기 때문에 무조건 ML 접근이 최상은 아니라는 방법을 제시할 수 도 있어야한다.
▮ 프로젝트 설계
프로젝트 현실
- 문제 정의
- 최적화할 Metric을 선택
- 데이터 수집, 레이블 확인
- 모델 개발
- 모델 예측 결과를 토대로 Error Analysis. 잘못된 라벨이 왜 생기는지 확인
- 다시 모델 학습
- 더 많은 데이터 수집
- 다시 모델 학습
- 2달 전 테스트 데이터에서는 성능이 좋지만 어제 데이터에서는 성능이 좋지 않음
- 원인을 다시 분석하고 모델을 학습
- 모델 배포
- 최적화할 Metric이 실제로 잘 동작하지 않아 Metric이 수정
- 앞의 과정 다시 반복
⇒ 앞의 반복적인 과정을 줄이기 위해서는 문제 정의 후, 프로젝트 설계를 최대한 구체적으로 해야 한다!
고려해봐야 할 것들을 최대한 다 작성해보고 고민해봐야한다.
문제 정의에 기반한 프로젝트 설계
- 해결하려고 하는 문제 구체화
- 머신러닝 문제 타당성 확인
- 얼마나 흥미로운지가 아니라 어떤 가치를 줄 수 있는지를 고려해야한다.
- 머신러닝 문제는 데이터로부터 어떤 함수를 학습하는 것
- 필요한 데이터의 종류와 기존 모델이 있는지 살펴보기
- 머신러닝은 모든 문제를 해결할 수 있는 마법의 도구가 아님, 머신러닝으로 해결할 수 있는 문제지만 머신러닝 솔루션이 최적이 아닐 수도 있음
머신러닝이 사용되면 좋은 경우
- 학습할 수 있는 패턴이 있는가?
- 학습을 위한 목적 함수를 만들 수 있는가?
- 복잡성 : 패턴이 복잡해야함
- 데이터 존재 여부: 데이터가 존재하거나 수집할 수 있어야 함
- 반복: 사람이 반복적으로 실행해야 하는 경우
머신러닝이 사용되면 좋지 않은 경우
- 비윤리적인 문제
- 간단히 해결할 수 있는 경우
- 좋은 데이터를 얻기 어려운 경우
- 한번의 예측 오류가 치명적인 결과를 발생할 경우
- 시스템이 내리는 모든 결정이 설명 가능해야 할 경우
- 비용 효율적이지 않은 경우
- 목표 설정, 지표 결정
- Goal: 프로젝트의 일반적인 목적, 큰 목적
ex) 극단적인 견해와 잘못된 정보의 확산을 최소화하며 사용자의 참여를 극대화하는 것이 목표
- Objectives: 목적을 달성하기 위한 세부 단계의 목표(구체적인 목적)
ex) NSFW 컨텐츠 필터링, 잘못된 정보 필터링, 품질에 따른 게시물 선정 등
- 목표를 설정하며 데이터를 확인해야 한다. 지표와 연결되는 내용이기 때문에
- 데이터셋을 만드는 일은 반복적인 작업
Multiple Objective Optimization
- 최적화하고 싶은 목적함수가 여러가지 있는 경우, 서로 충돌할 수 있음
- 품질에 따른 게시물 랭킹 선정(게시물 품질 예측) vs 참여에 따른 게시물 랭킹 선정(게시물 클릭 수 예측)
방법 1
- 단일 모델
- 두 loss를 하나의 loss로 결합 → 알파와 베타를 필요에 따라 조정 필요
loss = $\alpha$ quality_loss + $\beta$ engagement_loss
방법 2
- 2개의 모델을 만들어서 각각의 loss를 최소화
Rank : $\alpha$ quality_model(post) + $\beta$ engagement_model(post)
Objective가 여러개인 경우는 분리하는 것이 좋음
- 모델을 재학습하지 않도록 모델을 분리
- 제약 조건
- 일정/예산/사람
- 개인정보 보호
- 기술적 제약
- 윤리적 이슈
- 성능
- Baseline : 새로 만든 모델을 무엇과 비교할 것인가?
- Threshold : 확률값이 0.5 이상일 경우 강아지라고 할 것인지, 0.7 이상일 경우로 할 것인지?
- Performance Trade-off : 속도가 빠른데 Acc 0.95 vs 속도가 조금 더 느린데 Acc 0.97
- 해석 가능 여부 : 결과가 왜 발생했는지 해석이 필요할까
- 베이스라인, 프로토타입
- 모델이 더 좋아졌다고 판단할 수 있는 Baseline 필요(꼭 모델일 필요는 없음, Rule Base 규칙이 될 수도 있음)
- 간단한 모델부터 시작하는 이유
- 어떻게든 모델의 위험을 낮추는 것이 목표
- 유사한 문제를 해결하고 있는 SOTA 논문 파악
- 평가 방법 설계
- 작게는 모델의 성능 지표(RMSE)일 수도 있고, 크게는 비즈니스의 지표(고객의 재방문율, 매출 등)일 수도 있음
▮ Action (모델 개발 후 배포 & 모니터링)
앞서 정의한 지표가 어떻게 변하는 파악하기
- 현재 만든 모델이 어떤 결과를 내고 있는가?
- 잘못 예측하고 있다면 어떤 부분이 문제일까?
- 어떤 부분을 기반으로 예측하고 있을까?
- Feature의 어떤 값을 사용할 때 특히 잘못 예측하고 있는가?
▮ 추가 원인 분석
새롭게 발견한 상황을 파악해 어떤 방식으로 문제를 해결할지 모색
비즈니스 모델
회사에서 중요한 것 == 비즈니스
비즈니스에 대한 이해도가 높을수록 문제 정의를 잘 할 가능성이 존재
1) 회사의 비즈니스 파악
2) 데이터를 활용할 수 있는 부분은 어디인가?
3) 모델을 활용한다고 하면 예측의 결과가 어떻게 활용되는가?
