ML Strategy(2)
- Error Analysis
- Mismatched Training and Dev/Test set
1.Error Analysis
Carrying Out Error Analysis
우리가 모델로 하여금 인간처럼 동작하게 하고 싶거나, 또는 그러한 성능에 못미칠 때 수동적으로 시스템을 점검하고 어떤 실수를 하고 있는지 찾아내는 것이 Error analysis이다.
이러한 절차는 우리가 다음 작업으로 무엇을 해야하는지에 대한 통찰을 줄 수 있다.
만약 Cat classifier 의 성능을 테스트 했는데 Dev set에 대해 10%의 Error rate가 나왔고, 강아지를 고양이로 잘못 분류하는 문제점을 발견했다고 가정해보자.
이 문제를 발견했다는 것만으로 강아지를 더 정확히 False로 분류하는 작업에 많은 시간을 투자할수도 있다. 하지만 그럼에도 불구하고 결국 Error rate에 큰 변화가 없다면 그건 팀의 생산성을 낭비한 것이다.
그렇다면 이 오류가 정말 시간을 투자할 만 한것인지 어떻게 판단할 수 있을까?
- 100개 혹은 그 이상의 Mislabeled된 example을 추출한다.
- 그중에서 강아지의 사진이 몇개인지 Count 한다.
Machine learning task 에서 이러한 작업을 수동적으로 한다는것에 거부감을 느낄 수도 있지만, 실제로 이러한 방법은 효율적이다.
만약 100장의 사진 중 5장만이 강아지의 사진이었다고 생각해보자. 그럼 결국 강아지를 완벽히 분류해 내도 전체의 Error rate에는 0.5%만의 변화만 있을것이고, 이는 그다지 효율적이지 못하다.
반대로 100장의 사진 중 50장이 강아지의 사진이었다고 생각해보자. 그럼 강아지를 완벽히 분류해내면 10%의 Error rate가 5%까지 50%센트나 내려간다. 이는 충분히 시간을 투자할 만한 개선사항이다.
이처럼 몇분 혹은 몇시간만 투자해서 count해보는 것 만으로 Error에 대해서 분석이 가능하다. 또한 여러개의 아이디어에 대해서 Parallel하게도 적용할 수 있다.
예를들어 강아지를 잘못분류하는 문제, 사자,치타등의 great cat을 잘못분류하는문제, 흐릿한 이미지에 대한 에러 등의 여러가지 아이디어가 있다고 하자.
그렇다면 그림처럼 표로 만들어서 각각의 잘못 분류된 example을 살펴보며 해당사항에 체크하고, 최종적으로 해당 항목이 전체 중 몇%인지 비교하면 어느 문제를 고치는게 좋을가에 대한 Insight를 얻을 수 있다. (물론 도중에 새로 항목을 추가해도 된다.)
Clearing Up Incorrectly Labeled Data
문제점을 탐색하던 중 Train set에서 example X에대한 Y의 label이 잘못되어 있다는 것을 발견하면 어떻게 해야 할까?
Training set에서 mislabeled된 data를 발견했다면 당연히 올바르게 고치고 싶을 것이다. 하지만 그 오류가 단순한 miss에 의해 발생한 것이고, 비중이 크지 않다면 그대로 둬도 신경망은 대체로 잘 작동한다.
이는 곧 Deep learning은 training set 안의 random error에 꽤 강하다는 것이다.
그렇다면 Dev/Test set에서의 mislabeled data는 어떻게 해야 할까?
Error analysis를 하며 mislabeled 항목을 column에 추가해 체크하고, 최종적으로 total %를 보고 수정을 할것인지 말것인지에 대한 판단을 할 수 있다.
우선 전체의 dev set error를 살펴본다. 위의 예에서는 10%였다. 그 다음은 mislabeled에 의한 error를 본다. error중에서 6%이므로 0.6%일것이다. 마지막으로 다른 케이스의 에러를 보면 9.4%를 차지한다.
이러한 상황일 경우, 우리는 mislabeled된 data보다 다른 에러들을 고치는 것이 훨씬 효율적이라고 직관적으로 파악이 가능하다. 반대로, mislabeled된 비중이 전체 error의 큰 부분을 차지한다면 고치는것이 타당할 것이다.
한가지 주의해야할 점은 Dev/Test중 한가지에 수정작업을 했다면 나머지에도 똑같이 해주어야한다. 이전 글에서도 많이 설명했듯이 Dev와 Test set은 같은 Distribution을 갖게 해야하기 때문이다.
이렇듯 아직까지 Deep learning에는 수동적인 Error analysis나 사람의 Insight가 개입되는 부분이 많다고 볼 수 있다.
Build your First system Quickly, then iterate
만약 새롭고 경험이 없는 분야의 Machine Learning system을 만든다고 했을때, 그 모델이 잘 작동하기 위해 고려해야할 사항은 너무나도 많다. 그리고 대부분은 학습을 하고 직접 결과를 봐야 개선에 대한 아이디어를 얻을 수 있을 것이다.
따라서 일단 첫번째 시스템(prototype)을 빨리 만들고 반복적인 학습과 테스트를 진행하는 것이 좋다.
- 우선 앞선 글에서 소개했던 '목표' 를 정해야하는데 이는 곧 Dev/Test set를 정하는 것이다.
- 첫번째 System을 빠르게 구축한다.
- Bias/Variance analysis와 Error analysis를 이용해 모델을 평가하고, 다음 우선순위를 정한다.
프로젝트를 시작할 때, 대부분의 경우 너무 많은것을 복잡하게 생각하고 작업을 시작하려는 경향이 있다고 한다. 하지만 지저분하게라도 일단 만들어보고, 그 후 일련의 과정을 반복하면서 모델을 개선해 나가는 것이 더 효율적일 수 있다.
2.Mismatched Training and Dev/Test set
Training and Testing on Different Distributions
예전에도 나왔던 어플리케이션인 '유저가 사진을 업로드 하면 고양이인지 아닌지 판별해주는 시스템' 이 있다고 하자.
우리가 모델을 학습시킬때는 인터넷의 고해상도이고 전문적인 이미지를 통해 학습을 시켰다. 하지만 유저들은 덜 전문적이고, 품질이 떨어지는 사진을 올릴 것이다.
자연스럽게 모델의 정확도는 떨어질 것이고, 우리의 목표는 유저들의 사진을 잘 인식하는 것이기 때문에 모델을 개선해야 한다.
하지만 유저로부터 업로드된 사진은 1만장에 불과하기 때문에 이것을 데이터로 모델을 학습시키기에는 너무 적다. 이처럼 Train data와 Test data가 다른 Distribution을 가질 때 어떻게 해야할까?
당장 생각나는 방법으로는 원래 있던 Train Data에 User 로부터 얻은 Data를 합치고 랜덤하게 shuffle하여 Train, Dev/Test set을 구성하는 것이다.
이 방법을 사용하면, Train, Dev/Test set모두 같은 Distribution으로부터 온다는 것은 보장할 수 있다.
하지만 가장 치명적인 단점은, 정작 Dev/Test set을 들여다 보면 당신이 목표로하는 User 가 upload한 data는 매우 적을것이다.
따라서 생각해볼 수 있는 다른 방법은 10,000개의 user data중 5000개를 Train set에 포함시키고, 나머지 5000개로 Dev/Test set을 설정하는 것이다.
이렇게하면 Train set와 Dev/Test의 Distribution이 달라진다는 단점은 있겠지만, 최종적으로 Dev/Test set의 구성이 우리가 진짜 원하는 목표로 설정되기 때문에 실제 application에서 잘 작동하는 모델이 될 것이다.
Bias and Variance with Mismatched Data Distribution
Training set와 Dev/Test set가 다른 Distribution에서 오는 경우에는 기존의 Bias/Variance 를 분석하는 방법이 달라진다.
거의 0%의 Bayes error를 가진다고 할 때,
Train error가 1%의 error, Dev가 10% error를 가지면 기존처럼 Train/Dev가 같은 Distribution에서 나온 데이터라면 의심하지 않고 Variance error가 크다고 결론지을 수 있다.
하지만 Train set와 Dev set가 다른 Distribution에서 왔다면 우리는 실제로 Variance가 커서 나온 결과인지, 아니면 다른 Data의 특성을 가지고 있기 때문에 나온 결과인지 파악할 수 없다.
이 경우에는 Training-dev set 를 따로 만들어서 해결할 수 있다.
Training-dev set는 Training set를 일정부분 떼어놓은 set이지만, Training 할때는 사용하지 않는 set이다.
우리는 Training-dev set가 Training set와 같은 Distribution에서 온 것을 명확히 알고있기 때문에
학습을 마친 후 Training-dev set을 사용해 평가를 해보면 그것이 Variance에 의한 Error인지, 혹은 데이터가 달라서 나오는 에러인지 파악할 수 있을 것이다.
예를들어 Training error가 1%, Training-dev set error가 1.5%, Dev set error가 10%면 이는 Variance error 가 아니라 Data mismatch에 대한 에러일 것이다.
(추가적으로, Dev set과 Test set에서 차이가 난다는것은 Dev set에 overfitting되어있을 수 밖에 없다. Dev/Test는 같은 Distribution이기 때문이다. => Dev set 크기를 크게해야함)
Addressing Data Mismatch
Data mismatch error를 해결할 수 있는 방법에는 완벽하게 체계화 되어있는 방법론은 존재하지 않는다. 하지만 몇가지 시도는 해볼 수 있다.
- 우선 수동적으로 error example 들을 분석하며 Training set와 Dev/Test의 차이점을 이해해보려고 노력할 수 있다. 그럼 구체적으로 어떠한 차이점 때문에 error가 생기는지 파악이 가능하다.
- 위에서 알아낸 차이점들을 이용하여 Training data를 Dev/Test set과 동일하게 만들어볼 수 있다. 혹은 Dev/Test set과 비슷한 Data를 더 수집해 Training set에 추가해 볼 수도 있다.
Data를 추가적으로 만들 수 있는 방법 중 하나는 Artificial data synthesis(인공합성) 이다.
예를 들어 음성 인식에 사용된 Training data에다가 차량 내부 소리 등의 잡음을 합성하여 다양한 상황에서의 음성 파일을 만들 수 있을 것이고, 이는 모델의 성능을 향상시켜 줄 것이다.
하지만 Artificial data synthesis에서 가장 주의해야할 점은 자신도 모르게 전체 대비 작은 일부의 하위 집합 속에서 데이터를 생성하고 있지 않은지 잘 살펴봐야한다. 그렇지 않으면 그 하위집합에 overfitting 될 것이다.