[MLY] 개발 데이터가 많은 경우, 두 집합으로 나누고 하나에서만 확인하기

 만약 20%의 오류를 가지는 5000개의 큰 개발 데이터가 있다고 가정해보자. 그러면 지금 사용하고 있는 알고리즘은 1000개 정도의 개발 데이터를 잘못 분류하고 있는 것이다. 이 1000개 이미지를 일일히 확인하려면 시간이 많이 걸리므로, 그 데이터들을 모두 오류 평가시 사용하지 않기로 결정할 것이다.

 이 케이스에서, 나는 보통 개발 데이터를 크게 두개의 집합으로 나누고, 하나는 유심히 보고, 다른 하나는 보지 않는다. 그리고 나서 유심히 볼 집합에 대해서만 조금더 자주 학습을 시키고, 유심히 보지 않는 집합은 내부 parameter를 수정하는데 활용하곤 한다.

 앞에서 다룬 예제를 계속 살펴보면 우리가 쓰고 있는 알고리즘은 전체 5000개의 개발 데이터 중에서 1000개를 잘 못 분류하고 있다. 우리가 오류 평가를 위해서 100개의 오류 데이터(오류 중에서는 10%의 비율)를 일일이 확인해보길 원한다고 치자. 그러면 전체 개발 데이터의 10%를 랜덤하게 취하고, 우리가 눈으로 직접 확인해볼 수 있는 것을 우리 스스로 상기시키는 차원에서 "Eyeball dev set"으로 정의된 집합에 넣는다. (만약 음성 인식 관련 프로젝트에서는 이런 집합을 "Ear dev set"라고 표현할 수 있겠다.) 이제 "Eyeball dev set"은 500개의 데이터를 가지고, 이 중에서 100개가 잘못 분류될 것을 예상할 것이다.

 두번째 집합은 "Blackbox dev set"라고 부를텐데, 여기는 4500개의 데이터들이 남게 될 것이다. 이 Blackbox dev set을 활용해서 오류 비율을 계산하고, 이를 바탕으로 분류기를 자동적으로 평가하는데 이용할 것이다. 또한 이걸 사용해서 알고리즘들 사이에서 하나를 고르거나 Hyperparameter를 수정하는데도 사용할 수 있다. 하지만 이 데이터를 눈으로 확인하는 것은 피해야 한다. "Blackbox"라는 문구를 쓴것과 같이 해당 개발 데이터 집합은 분류기에 대해서 "Blackbox" 평가 방식을 취해야 하기 때문이다.

 왜 이렇게 "Eyeball dev set"과 "Blackbox dev set"으로 나눴을까? "Eyeball dev set" 내에 있는 데이터들을 통해서 우리가 직관을 얻을 수 있기 때문에 아마 해당 집합내에서는 overfitting이 빠르게 진행될 것이다. 만약  Blackbox dev set의 성능보다 Eyeball dev set의 성능이  더빠르게 좋아진다면, Eyeball dev set에 대해서는 overfitting되고 있는 것이다. 이런 상황에서는 그 집합을 빨리 버리고, Blackbox dev set에 있는 데이터들을 Eyeball dev set로 옮기는 방식으로 새로운 Eyeball dev set을 만들던가 아니면 새롭게 라벨링된 데이터를 취해야 한다.

 이렇게 Eyeball dev set과 Blackbox dev set으로 나눈 것을 통해 일일이 오류를 평가하는 절차가 전체 데이터 중 Eyeball dev set에 있는 데이터에 대해 overfitting 되는 시점을 말해줄 수 있다.

< 해당 포스트는 Andrew Ng의 Machine Learning Yearning 중 chapter 17. If you have a large dev set, split it into two subsets, only one of which you look at을 번역한 내용입니다.>