머신 러닝 프로젝트를 단계별로 개선하는 방법 #1

이 글은 Structuring Machine Learning Projects 라는 강의 내용을 바탕으로, 필자의 경험과 의견을 덧붙인 글입니다.

 

(1) 머신러닝 모델의 예측 정확도를 더 높이고 싶은 경우의 다양한 선택지

(2) Chain Assumptions in ML

(3) 기타 경험적인 Tips

 

에 대한 내용을 담고 있습니다.

* 원 강의 : Structuring Machine Learning Projects

---

"머신러닝 모델이 잘 동작하지 않을 때, 우리는 어떻게 문제를 해결할 수 있을까?"

 

   1. 머신러닝 프로젝트는, 정형화된 단계들로 나눌 수 있다.

   2. 내 프로젝트가 어느 단계에서 문제가 발생했는지 파악한다.

   3. 해당 단계에 적합한 방법론을 시도하여 성능을 개선한다.

 

Image of AARN GIRI

프로덕션 레벨에서 머신러닝 모델을 만들 때, 예상보다 모델 성능이 잘 나오지 않는 상황을 종종 경험하게 됩니다.

"모델 성능이 좋지 않음" 이라는 하나의 결과에 대해 수많은 원인이 있을 수 있는데요, 이런 상황에서 진짜 원인을 찾아내는 데 상당한 노력이 필요합니다.

 

이에 대해 Coursera와 Landing AI 창업자로 유명한 Andrew Ng 교수님이 구조적인 접근 방법을 제안한 내용이 있어 소개 드리고자 합니다. (CS229와 같은 유명한 강의들에 비해 이 강의는 덜 알려진 듯 하네요.) 어렵지 않은 내용이지만, 머신러닝 프로젝트를 구조적으로 접근한다면 문제 원인을 파악하기 위한 시간을 상당히 절약할 수 있습니다.

 

 

1. 머신러닝 모델의 예측 정확도를 더 높이고 싶은 경우의 다양한 선택지

1. 문제 세팅을 바꿔본다.
   1. 저의 경우, 실제로 가장 많이 문제가 되었던 케이스 입니다.
   2. 각 행을 구성하는 데이터와 정답지를 바꿔 봅니다.
   3. 특히 Train-valid-predict 에서 동일한 데이터 형태로 문제를 구성하는 것이 중요합니다.
      1. 예를 들어 "고객 key - 해당 고객이 오늘 상품 key - 클릭 여부" 을 기준으로 각 행을 구성하면, predict 시에 문제가 됩니다.
      2. 왜냐하면 결국 하고자 하는 것은 내일 해당 고객이 어떤 상품을 클릭할 확률이 높은지 알고 싶은 것인데, "본 상품 중에서 무엇을 클릭할지" 를 맞추는 문제로 세팅하면, 해당 고객이 "내일 어떤 상품을 볼 지" 를 알기가 어렵기 때문입니다.
         1. 물론 내일 어떤 상품들이 노출될지를 예측하거나 제어할 수 있다면, 이렇게 문제를 세팅해도 무관합니다.
      3. 이 경우, "고객 key - 해당 고객에게 추천 모델이 오늘 추천한 상품 key - 클릭 여부" 로 문제를 구성하면 train-predict 시에 동일한 문제를 풀게 되므로 모델이 원하는대로 동작하게 됩니다.
2. 더 많은 데이터를 수집한다.
   
   1. 물론 실제 프로덕션 환경에서 데이터를 추가로 더 수집할 수 있는 경우는 많지 않습니다. 시간/인건비 등이 추가로 소요되는 경우가 대부분이기 때문이죠.
      1. 데이터 수집에는 대부분 비용이 발생하고, 이러한 이유로 데이터만 잘 쌓아 둔 스타트업이라도 높은 가치를 인정 받은 경우들이 있었습니다.
   2. 대신 데이터 활용 기간(예> 2주일에서 1달로..)을 늘리는 등의 시도가 가능합니다.
   3. 또는 사내의 더 많은 데이터를 활용할 수 있는 형태로 문제 세팅을 바꿔 볼 수도 있습니다. (행 구성, 정답지)
3. 더 다양한 학습 데이터를 수집한다. 
   
   1. 학습 데이터 구성에 편향이 발생한 경우, 알고리즘의 예측력이 떨어질 수 있습니다.
   2. 예를 들어 어떤 동물이 고양이인지 분류해 내는 모델을 만들었는데 학습 데이터에 노르웨이숲 고양이밖에 없다면, 코숏 고양이에 대해서는 예측 정확도가 떨어지게 됩니다.
   3. Data augmentation 과 같은 기법을 사용하기도 합니다.
4. 모델을 더 오래 학습 시킨다. 
   1. Gradient Descent 알고리즘을 기반으로 학습시킬 경우, 학습 시간/epoch가 부족한 경우에 발생할 수 있습니다.
   2. 학습을 더 오래 시킬수록 Validation Loss (검증 데이터 셋에 대한)가 감소하는 경우에만 의미가 있습니다. (Training Loss가 아니라 Validation Loss가 기준)
5. Adam 등 다양한 Optimizer를 사용해 본다.
   1. Optimizer 종류에 따라 최적화를 하는 방식이 조금씩 다르기 때문에 다른 optimizer를 시도해 볼 수 있습니다.
   2. Naver Deview 에 따르면 논문의 SOTA 성능을 얻어 내는 데 SGD가 더 잘되는 케이스가 더 많았다고 하네요.
6.  더 큰 Neural network를 사용해 본다. / Hidden Unit의 개수를 늘려 본다.
   1. 풀고자 하는 문제의 복잡성에 비해 모델의 구조가 단순하여 component 간의 충분한 관계를 표현하지 못하는 경우
7. 더 작은 Neural network를 사용해 본다.
   1. 데이터가 가진 정보량에 비해 지나치게 복잡한 모델을 사용할 경우, 오히려 모델 퍼포먼스가 낮아지는 경우가 있기 때문
8. Dropout을 시도해 본다. / L_2 Regularization을 추가한다.
   1. Overfitting을 방지하기 위함입니다.
9. 모델의 구조를 바꿔 본다.
   1. 순서를 가진 데이터라면 Transformer 계열의 딥러닝 모델을 쓰는 것이 효과적일 수 있습니다.
10. Activation 함수를 바꿔 본다.

 

위의 다양한 선택지 중, 무엇이 적절한 선택지인지 빠르게 알 수는 없을까?

• ML 시스템 구축 시에 어려운 점 : 하나의 문제를 풀기 위해 적용해 볼 수 있는 방법론이 다양하고, 바꿔볼 수 있는 항목 (모델 구조, 초모수 등..)이 무수히 많다.
• ML의 대가들은, A라는 수치를 변화시키기 위해 B라는 항목을 튜닝해야 하는 것을 알고 있기 때문에 잘 할 수 있다.
  • Andrew Ng 교수님은 위 내용을 orthogonalization (행렬 이론에서의 orthogonalization 과는 다르다.) 이라는 개념으로 표현합니다.

 

2. Chain of Assumptions in ML

• 머신러닝 프로젝트는 여러 단계로 구성되며, 해당 단계마다 튜닝이 필요한 항목들이 어느정도 정해져 있습니다.

 

1. 학습 데이터에 잘 fitting 되어야 한다. (=Fit training set well on cost function)
   1. 잘 fitting 시킨다의 기준? 사람이 잘 하는 분야 (예> 이미지 분류)에서는 사람과 유사한 수준을 의미합니다.
   2. 만약 Training 과정에서 metric (F1-score, RMSE 등..)이 원하는 수준만큼 잘 안나온다면 아래 방법론들을 시도해 볼 수 있습니다.
      
      

      1. 데이터에 맞게 모델 구조를 바꿔본다. (gbm, transformer, ...)

      2. SGD 등 다양한 Optimizer를 사용해 본다.

2. 검증 데이터에 잘 fitting 되어야 한다. (=Fit Validation set well on cost function)
   
   1. 만약 Validation 과정에서 metric이 잘 나오지 않는다면, 아래 방법론들을 시도해 볼 수 있습니다.
   2. Training set에 대해서만 잘 fitting된 경우, 새로운 데이터에 대해 잘 예측하지 못하는 overfitting 문제가 발생했을 가능성이 있기 때문입니다. 따라서 overfitting을 줄여줄 수 있는 L_2 regularization, Cross Validation (일종의 학습 데이터를 늘리는 효과도 있음), Dropout 등을 시도해 볼 수 있습니다.
      
      

      1. Regularization

      2. 더 큰 학습 데이터셋을 활용해 본다.

      3. class imbalance 문제가 있는지 확인하고, undersampling 이나 oversampling을 시도해 본다.

3. 테스트 데이터에 잘 fitting 되어야 한다. (=Fit Test set well on cost function)
   1. 테스트 데이터는 보통 D+1 데이터와 같이, 실제 프로덕션에서 예측이 의미가 있는 데이터로 구성합니다.
   2. 만약 test 과정에서 metric이 잘 나오지 않는다면, 아래 방법론을 시도해 볼 수 있습니다.
   3. 특정 Validation Set에 대해서만 Overfitting이 이루어졌을 수 있기 때문에, 검증 데이터셋을 더 크게 하여 테스트 셋과 유사하게 구성하려는 목적입니다.
      
      

      1. 더 큰 검증 데이터셋을 활용해 본다.

4. 모델 구성 이후 생성되는 현실 세계의 데이터셋에 대해 잘 fitting이 되어야 한다. (=Fit well on real world problem)
   1. 모델 배포 후, 성능이 잘 나오지 않는다면 검증 데이터와 테스트 데이터가 프로덕션 레벨에서의 데이터를 충분히 반영하지 못한 이유가 있을 수 있습니다.
   2. 혹은 문제 세팅이 처음부터 잘못 되지는 않았는지 다시 한 번 확인합니다.
      
      

      1. 검증 데이터/ 테스트 데이터 셋이 현실 세계 데이터와 유사하도록, 재구성 한다.

      2. Cost function을 바꿔 본다. (문제 정의가 잘못된 경우)

 

 

3. 기타 경험적인 Tips

1. class imbalance 문제 해결
   1. 피처가 많을수록 oversampling 방법론은 연산량이 매우 많이 필요하기 때문에, undersampling이 유리합니다.
   2. undersampling은 소수인 클래스의 데이터는 모두 남기고, 다수인 클래스의 데이터는 일부만 샘플링 하는 것을 의미합니다.
   3. 테스트 데이터에서의 퍼포먼스를 기준으로 undersampling 비율을 조정합니다.
2. binary classification에서 F1-score과 관련된 이슈
   1. Precision과 Recall은 trade-off 관계에 있는데요, P나 R 중 하나가 지나치게 높은 것은 좋지 않습니다. 두 값과 F1 score까지 비슷한 값을 갖는 경우에 일반적으로 성능이 좋습니다.
      1. 물론 "공장에서 불량품을 내면 안 되는 경우" 와 같이 Recall이 압도적으로 중요한 모델들도 있고, 이는 비즈니스 상황에 맞게 결정해야 합니다. 이 경우 단순 F1-score가 아니라 P 혹은 R에 가중치를 부여한 F-beta score를 사용해 보셔도 좋을 것 같네요.
      2. 예를 들어 beta 가 2인 경우, recall을 precision보다 2배 중요하게 여기는 케이스 입니다.
   2. Precision과 Recall 값의 비중은 주로 class weight를 활용해서 조절할 수 있습니다. 0/1 중 1이 소수 카테고리인 경우, 1에 대한 class weight를 높일수록 Recall이 높아지고, 낮출수록 Precision이 높아집니다.
      1. "다수 클래스 샘플 수 / 소수 클래스 샘플 수" 로 보통 최적의 class weight를 이야기 하는데요, 저의 경험 상 이 값에 1/n 을 곱해서 P-R 균형을 맞췄을 때 가장 퍼포먼스가 좋았습니다.
3. Evaluation metric을 잘 설정하는 것도 매우 중요합니다. 위에서는 주로 F1-score를 예시로 들었지만, 만약 F1-score 보다 더 비즈니스적인 니즈를 잘 반영하는 metric이 있다면 (예> ndcg) 해당 metric을 사용해야 합니다. 구매 또는 전환율과의 상관계수를 계산해 보는 것도 좋습니다.
4. 실제 서비스에 적용할 경우, 학습 뿐만 아니라 inference에 소요되는 시간 등 제약 조건이 고려되어야 하는 경우들도 있습니다.
   1. 이 때는 모델의 성능을 약간 희생하면서 응답 속도가 빠른 모델을 선택할 수 있습니다.
   2. 필요한 피처를 줄이거나, 모델을 여러 겹으로 쌓거나, 모델 결과를 미리 적재해 두거나, 모델을 메모리에 올리는 등의 시도가 가능합니다.

 

다음 글에서는 Error analysis, data mismatch 등을 다루도록 하겠습니다.

읽어 주셔서 감사합니다!