캐글

[Kaggle Study] 8. About Structuring ML Projects (2) - Error Analysis & Incorrectly labeled / Mismatch data

dongsunseng 2024. 11. 13. 15:37
반응형

This post is a summary of Coursera Andrew Ng's lecture:

 

머신 러닝 프로젝트 구조화

DeepLearning.AI에서 제공합니다. 딥러닝 전문 과정의 세 번째 과정에서는 성공적인 머신러닝 프로젝트를 구축하는 방법을 배우고 머신러닝 프로젝트 리더로서 의사 결정을 연습할 수 있습니다. 이

www.coursera.org

이 포스트는 전 포스트의 내용과 이어집니다:

 

[Kaggle Study] 7. About Structuring ML Projects (1)

This post is a summary of Coursera Andrew Ng's lecture: 머신 러닝 프로젝트 구조화DeepLearning.AI에서 제공합니다. 딥러닝 전문 과정의 세 번째 과정에서는 성공적인 머신러닝 프로젝트를 구축하는 방법을 배

dongsunseng.com

Error Analysis

#1 Carrying Out Error Analysis

  • 인간이 수행할 수 있는 작업에 대한 머신러닝 알고리즘을 구축하려하고 해당 모델의 성능이 Human level performance를 도달하지 못했다면 "manually examining mistakes that your algorithm is making"은 프로젝트의 방향성을 설정하는데에 도움이 됨
    • 해당 작업을 "error analysis"라고 부름

  • 위의 예시에서는 cat classifier를 구축하는 과정에서 팀원이 고양이와 유사하게 생긴 강아지에 대한 이슈를 던졌을 때에 대한 내용임
    • 강아지를 더 잘 분류하기 위한 특별한 노력이 모델의 일반적인 성능에 유의미할지를 판단하는 과정은 다음과 같음
  1. 100개 이하의 mislabeled dev set examples를 수집
  2. 해당 데이터에서 강아지 사진의 비율이 얼마나 되는지 확인
    • 예를 들어 100개를 수집했을 때 그 중 강아지 사진이 5개라면, 강아지를 더 잘 분류하려는 방향으로 모델을 수정해도 5개의 데이터(5%의 mislabeled data)만 옳게 분류되는 것이기 때문에 그정도의 모델 향상이 예상됨
    • 모델의 일반적인 성능이 90% accuracy, 10% error이라면 10% error는 9.5% error로 줄어드는 것임
    • 결론적으로 강아지 분류에 대한 노력을 해도 모델을 효율적으로 향상시키려는 방향은 아님을 합리적으로 판단할 수 있음
    • 해당 과정은 강아지 분류에 대한 노력을 통한 모델 향상의 upper bound(ceiling)을 알 수 있음
    • 만약 해당 데이터의 강아지 비율이 크다면(50% for example), 강아지 분류에 대한 노력을 기울이면 일반적인 모델 성능은 10% error에서 5% error로 줄어들 수 있기 때문에 합리적인 방향이라고 생각됨

  • 위의 예시와 같이 모델 향상에 대한 방향성이 여러 가지 제기되었을 때는 각 방향성에 대한 모델 향상 가능성을 전 예시와 같이 수치로 구한 후 가장 모델 향상에 효과적일거라고 예상되는 부분부터 개선하는게 합리적임

#2 Cleaning Up Incorrectly Labeled Data

  • 첫 번째로 Incorrectly labeled data in training set에 관한 내용임
  • Incorrectly labeled examples가 랜덤에서 크게 벗어나지 않으면 딥러닝 알고리즘들은 training set에서의 random error에 대해서 상당히 강하기 때문에 해당 데이터를 옳게 label 하려고 시간을 쏟지 않아도 됨
  • 'Total dataset의 사이즈가 적당히 크고, Incorrectly labeled 데이터가 엄청나게 많지 않다면'이라는 전제조건이 붙긴함
  • 하지만, 딥러닝 알고리즘들은 'systematic error'에 대해서는 덜 강함
    • 만약 하얀색 강아지들을 모두 고양이로 분류하는 등의 체계적인 오류가 있다면 큰 오류로 이어질 수 있음

  • Incorrectly labeled data가 dev set 혹은 test set에 존재할 때는 error analysis 과정에서 해당 문제에 대한 부분을 추가로 확인하여 틀렸다고 분류했지만(고양이가 아니라고 분류했지만) 사실은 실제 y값이 틀려서 틀렸다고 잘못 분류된 부분들을 확인함
    • 위와 같이 3가지 수치적 지표를 설정한 후, 위에서 여러가지 아이디어를 병렬적으로 검증했던 것 같이 incorrectly labeled data에 대한 이슈를 해결하는 것이 효과적일지 다른 이슈를 해결하는게 효과적일지 판단하면 됨
    • 10% 오차 중 0.6%가 incorrectly labeled data에 대한 오차라면 다른 문제를 해결하는 것이 모델 향상에 더 효과적일 수 있지만 전체 오차가 2%라면 0.6%는 대략 30%가 넘는 높은 수치이므로 해당 이슈를 해결하는 것이 좋아보임
  • Dev set의 목적은 더 나은 모델을 판단하기 위함이 큰데, 만약 classifier A의 dev error가 2.1%, classifier B의 dev error가 1.9%라면 0.6%라는 상당한 부분의 dev error가 incorrectly labeled data에 의한 것이기 때문에 이를 해결하는 것이 좋음

  • Training set은 random error에 있어서 상당히 강하기 때문에 incorrectly labeled data를 어느정도 갖고있어도 괜찮을 수 있다고 앞에서 언급함
  • Dev 혹은 Test set에 있는 incorrectly labeled data를 수정하는 작업을 거치게 되면 train dataset과 dev/test data는 다른 distribution에서 오는 데이터라는 점을 인지하는 것이 중요함

#3 Build your first system quickly, then iterate

Mismatched Training and Dev/Test Set

#1 Training and Testing on Different Distributions

  • 위의 예시에서는 training set으로 이용하기 위해 웹에서 크롤링해온 데이터와 유저가 업로드해서 사용할 데이터의 생김새가 다름
  • 유저가 업로드한 데이터로만 모델을 훈련시키기에는 데이터가 작기 때문에 다른 distribution에서 가져온 데이터로 학습시키게 됨
  • 해당 문제를 해결하기 위해 다음과 같은 시도를 해볼 수 있음:
    1. 200,000 개의 크롤링 데이터와 유저가 업로드한 10,000 개의 데이터를 랜덤으로 섞은 후 train, dev, test set으로 나눠서 사용
      • 장점: train, dev, test set이 모두 같은 distribution의 데이터로부터 파생됨
      • 단점: 대부분의 데이터는 크롤링 데이터이므로 dev set의 데이터도 대부분 크롤링 데이터일 것임 + 하지만 우리가 원하는 것은 유저가 업로드한 사진에 대해서 잘 동작하는 모델임
      • 따라서, 좋은 방법은 아닌 것 같다는 결론을 낼 수 있음
    2. dev와 test set을 모두 유저 데이터로 설정함(5000개)
      • 장점: 모델이 잘 동작해야 하는 대상(유저 업로드 사진)과 dev, test set 데이터가 일치함
      • 단점: training set 과 dev & test set이 다른 distribution으로부터 나옴 
      • 이 단점은 극복할 수 있는 방법이 있음 + 장점이 프로젝트의 목적성과 맞음 -> 해당 방법을 선택하는 것이 좋다는 결론

#2 Bias and Variance with Mismatched Data Distributions

  • Bias와 Variance를 분석하는 방식은 training set과 dev and test set이 다른 distribution으로부터 파생되는지 아닌지에 따라 달라짐
    • 둘이 같은 distribution에서 파생되었다면 human level prediction이 대략 0%, training error 1%, dev error 10%인 상황에서는 variance를 줄여야겠다는 결론을 낼 수 있겠지만, 둘이 같은 distribution에서 파생되지 않은 상황에서는 이런 결론을 쉽게 도출해낼 수 없음
    • dev set에서 10%면 충분히 좋은 성능일 수도 있다는 뜻임: 그저 dev set이 정확하게 분류하기 더 어려운 데이터로 이루어져있을 수도 있음
  • 이런 경우에는 Training-dev set을 설정하여 해결할 수 있음
    • 랜덤하게 training set을 shuffle 하고 그 중 일부를 training-dev set으로 지정함
    • dev와 test set이 같은 distribution에서 온 것 처럼 training set과 training-dev set도 같은 distribution에서 파생됨
    • Training-dev set은 모델 훈련에 사용되지 않음
    • 모델을 training set으로 훈련한 후 training-dev set에서의 정확도도 측정해서 비교함
  • training error 1%, training-dev error 9%, dev error 10%의 경우, variance 문제가 있다고 판단할 수 있음
    • training set과 training-dev set은 같은 distribution에서 왔지만 그 차이가 크기 때문(not generalizing well)
  • training error 1%, training-dev error 1.5%, dev error 10%의 경우, data mismatch 문제임
    • 다시 말해, 모델이 우리가 원하는 대상에 대해 성능이 안 좋기 때문에 모델이 잘못된 방향으로 훈련되고 있다는 것임
  • training error 10%, training-dev error 11%, dev error 12%의 경우, 당연하게 human level performance가 대략 0%임에 따라 Avoidable bias 문제가 있음을 알 수 있음
  • training error 10%, training-dev error 11%, dev error 20%의 경우, Avoidable bias 문제와 data mismatch 문제가 둘 다 존재함

  • 추가적으로 dev error와 test error의 차이는 "degree of overfitting to the dev set"을 나타냄
  • Training-dev error보다 dev error가 나은 경우도 발생 가능함

  • 전에 봤던 수치들을 비교하는 것뿐만 아니라 첫 번째 row의 두 수치의 비교를 통해 general speech recognition이 rearview mirror speech recognition 보다 쉽다는 insight를 얻을 수도 있음
  • 따라서 이런 수치 비교들을 통해 insight를 얻으면 프로젝트의 방향성을 정하는데에 도움이 됨

#3 Addressing Data Mismatch

  • Artificial Data Synthesis 기법을 통해 dev/test set에 있는 데이터를 simulate 할 수 있음

  • 위의 예시에서 The quick ~ 문장에 대한 오디오 데이터가 10,000 시간 분량이 있고 car noise는 1시간 분량밖에 없다면?
    • 1시간의 car noise를 10,000번 반복해서 오디오 데이터에 더해줄 수 있음
    • 하지만 모델이 1시간의 car noise에 overfit 할 가능성이 있음
    • 10,000 시간의 car noise를 구해서 unique한 데이터로 학습하는 것이 효과적일지 아닐지 판단해야함

Look out for those who look out for you. Loyalty is everything.
- Conor Mcgregor -
반응형