머신 러닝을 이용한 제안서 평가 고려사항 (feat. 예측 문제)

실제 업무적인 발주에 따른 제안서 평가든 교육적 프로젝트든 마찬가지다. 머신러닝을 사용해 예측을 하겠다는 내용이 있다며 아래 사항들을 고려하여 평가하여야 한다. 크게 비즈니스, 데이터, 모델링, 평가, 배포의 관점으로 불 수 있겠다.

참고로 아래 내용은 대부분 예측 및 분류에 대한 지도학습 문제에 대한 경우이다. EDA의 경우엔 대부분 해당사항이 없을 수 있다.

 

1. 비즈니스 이해

• 비즈니스 도메인에 대한 기본적인 상식이 결여된 부분은 없는가?
  • 예를 들어, 무료 구독 후 해지하는 비율이 90%인데, 무료 구독 후 해지할 사람을 80%의 정확도로 식별 해보겠다던가. (10명 중 아무나 8명을 골라도 80% 이미 80% 이상의 정확도이다.)
• 설정한 목표 변수가 문제를 해결하는데 적절한 목표 변수가 맞는가?
  • 예를 들어, 해지를 막기 위한 쿠폰을 발송하려고 하는데 쿠폰 없이도 연장을 할 사람들을 고려하지 않는다던가.
  • 또는, 신규 서비스를 이용하도록 유도하기 위해 쿠폰을 주려고 하는데 쿠폰 및 제반비용을 고려하지 않아 오히려 마이너스가 될 고객도 포함해서 예측을 하고 있다던가.

2. 데이터 이해

• 사용하고자 하는 데이터가 실제 존재하고 사용할 수 있는 데이터인가?
• 학습 데이터로 사용하고자 하는 데이터가 목표를 이루는데 적절한 데이터인가?
  • 영업 가능성을 예측하는 모델을 만들려고 하는데 영업에 성공한 데이터만 가지고 이를 하려고 한다던가. (이 경우 영업에 실패하는 경우를 어떻게 포함해서 학습할지에 대한 계획이 필요하다.)
• 목표 변수에 대한 라벨링된 정보가 이미 충분히 있는가? 
  • 없다면 이를 취할 수 있는 방법(수동 라벨링 또는 실험 세션 등)을 제시하고 있는가?

3. 모델링 (모델 개발)

• 분류를 해야 하는 회귀 모델을 가져오거나, 반대인 경우는 아닌지? 지도학습과 비지도학습을 제대로 구분해서 이해하고 있는지?
• 하나의 특정 모델을 제시하면 대부분의 경우엔 논란의 여지가 있다. 
  • 실제로 데이터만 준비 되면 여러 모델을 돌리고 성능을 평가해 보는 건 쉽다. 어떤 모델이 성능이 잘 나올지 모르는데 굳이 제안서 단계부터 모델을 정해놓는 건 불필요하다. 
• 모델 해석 가능성 및 설명 가능성을 고려애햐 한다. 무조건 성능이 좋은 모델을 찾겠다는 건 좋은 접근법이 아닐 수 있다.
  • 프로젝트에 따라 단 몇%의 정확도를 끌어내는 것 보단 직관적인 성능과 지속적인 활용 가능성이 더 중요할 수도 있다.

 

4. 모델 평가 (Model Evaluation)

• Out-of-sample에 대한 평가(N-ford, holdout 등)를 명시하고 있는가?
  • 훈련용 모델을 그대로 테스트에 사용해버릴 가능성을 기존에 충분히 차단해야 한다.
• 다양한 지표를 고려하지 않고 정확도(Accuracy)만 보고 있진 않는가?
  • Accuracy 뿐만 아니라 precision, recall(sensitivity), F1 Score, ROC-AUC, Lift 등을 종합적으로 고려해야 한다.
  •  
  • 어떤 평가 지표를 고려할 것인지는 최소한의 도메인 지식이 가미되어야 한다. 그냥 모든 것을 종합적으로 보겠다는 계획도 좋은 계획은 아니다.

5. 배포 및 전달 (Deployment and Delivery)

• 대상을 선정할 때 적절한 threshold 기준 없이 그냥 0.5를 사용하진 않을지 확인해야 한다.
  • 최소한 F1 Score를 고려하던가, 더 나아가서는 비용 함수가 나와줘야 한다.
• 단순 일회성 사용 모델인지, 지속적으로 사용해야 하는 도구인지가 구분되어야 한다.
  • 일회성 프로젝트라면 보고서만 잘 나오면 되지만, 지속적으로 사용해야 할 도구라면 UI 나 재학습, 데이터 교정 방법 등이 고려되어야 한다.
• 인과관계(Causality)에 대한 설명이 필요하다. A/B 테스트나 Causal Graph 등 원인 분석 및 이에 대한 검증, 설명에 대한 계획이 포함되어야 한다.
  • 해석이 강하게 요구된 제안요청서였다면 모델 선정 과정에서부터 해석 가능성이 크게 고려되었어야 하며, 배포 및 전달 과정에서도 해석 가능성 및 설명 가능성이 고려가 되어야 한다. 블랙 박스 모델이 사용될 수 밖에 없었다면 SHAP 등