[MLY] 개발 데이터상에 잘못 라벨링된 것 정리하기

 오류 평가를 하는 동안, 아마 개발 데이터 상에서 잘못 라벨링(mislabeled)된 것들이 몇몇 있는 것을 확인할 수 있을 것이다. 여기서 잘못 "라벨링"이 되었다는 것은, 이미 알고리즘을 적용하기 전부터 사람에 의해서 이미 잘못 라벨링이 된 이미지들을 말하는 것이다. 예를 들어 (x, y)라는 데이터가 있을 때 y에 대해서 잘못된 값을 가지고 있는 것이다. 다른 예를 들자면, 고양이가 아닌 사진들이 고양이가 포함되어 있는 것처럼 잘못 라벨링이 되어 있는 케이스가 있을 것이다. 잘못 라벨링된 이미지의 비율이 중요하다고 여겨지면, 해당 데이터의 비율에 대한 카테고리를 만들고 한번 살펴봐라:

Image	Dog	Great Cat	Blurry	Mislabeled	Comments
...
98				O	배경에 있는 고양이에 라벨링이 되어 있지 않음
99		O
100				O	고양이 그림, 실제 고양이가 아님
% of total	8%	43%	61%	6%

 여기서 개발 데이터에 있는 라벨들을 바로 고칠 필요가 있을까? 일단 개발 데이터의 존재 목적은 알고리즘의 성능을 빠르게 판단해서 알고리즘 A와 B 중 어떤 것이 좋은 지를 말해주는 것이라는 것을 명심해야 한다. 만약 개발 데이터 상에서 잘못 분류된 데이터의 비율이 뭔가 판단하는데 있어 방해한다면, 해당 개발 데이터 상에서 잘못된 라벨을 수정하는데 시간을 쓰는 것이 가치가 있다.

 예를 들어, 만든 분류기의 성능이 아래와 같다고 가정해보자:

- 개발 데이터에서 측정된 전체 성능 - 90% (10%의 오류)
- 잘못 라벨링된 데이터로 인해 생긴 오류 - 0.6% (개발 데이터 오류 중 약 6%)
- 다른 이유로 인해 생긴 오류 - 9.4% (개발 데이터 오류 중 94%) 

 여기서 잘못 라벨링된 데이터로 인해 생긴 0.6%의 부정확성은 다른 부분으로 개선 시킬 수 있는 9.4%의 오류에 비해 상대적으로 중요하지 않다. 개발 데이터 상에서 잘못 라벨링된 데이터를 손으로 고치는 것은 아마 지장이 없겠지만, 그렇다고 그 작업이 반드시 해야할 만큼 절대적이지 않다. 굳이 시스템의 전체 오류가 10%인지 9.4%인지를 알 필요도 없다.

이제 고양이 분류기를 개선시켜서 다음과 같은 성능을 얻었다고 가정해보자:

- 개발 데이터에서 측정된 전체 성능 - 98% (2.0%의 오류)
- 잘못 라벨링된 데이터로 인해 생긴 오류 - 0.6% (개발 데이터 오류 중 30%)
- 다른 이유로 인해 생긴 오류 - 1.4% (개발 데이터 오류 중 70%) 

 30%의 오류가 개발 데이터 상에서 잘못 라벨링된 데이터때문에 생긴 것이기 때문에 이제는 정확성을 측정하는 척도로 중요한 변수가 된다. 이제는 개발 데이터의 라벨에 대한 질을 개선시키는 것이 의미가 있게 된다. 잘못 라벨링된 데이터를 고치는 것을 통해서 분류기의 오차를 1.4%에 가깝거나 2% 인지를 결정할 수 있을텐데, 이 차이는 상대적으로 중요하다고 볼 수 있다.

 시작부터 잘못 라벨링된 개발/테스트 데이터들을 받아들이는 것 자체가 흔하기도 하고, 나중에 시스템의 성능을 개선시킬 수 있는 정도로만 인지되고 이로 인해 이런 데이터들이 전체 오류 상에서 상대적으로 많은 비율을 차지하게 된다.

 지난 포스트에서 다뤘던 개, 고양이과 동물, 그리고 흐릿한 이미지를 알고리즘적인 개선을 통해서 오류 카테고리를 개선시키는 것에 대해 설명했었다. 이번 장에서도 동일한 방법으로 잘못 라벨링된 카테고리에 대해서 데이터의 라벨을 개선시킴으로써 적용시킬 수 있다는 것을 알게 된다.

 개발 데이터 라벨을 수정하는데 있어 어떤 과정을 취했던 간에, 그런 과정을 테스트 데이터에도 동일하게 적용해서, 지금 가지고 있는 개발 데이터와 테스트 데이터가 계속 같은 분포를 유지할 수 있도록 해야 한다. 이렇게 개발 데이터와 테스트 데이터를 함께 수정하는 것이 우리가 6장에서 다뤘던, 개발 데이터를 활용해서 수정한 방법은 나중에 다른 테스트 데이터 기반의 다른 기준에 의해서 평가할 때 발생할수 있는 문제를 막을 수 있다. 

 만약 라벨의 질을 개선하고자 하면, 시스템이 잘못 분류한 데이터의 라벨도 잘 분류한 데이터의 라벨과 동일하게 여러번 확인해봐야 한다. 원래 있던 라벨과 학습 알고리즘이 특정 데이터 상에서 잘못 동작할 가능성도 있기 때문이다. 만약 시스템상에서 잘못 분류된 데이터에 대해서만 라벨을 고치게 된다면, 검증시 편견(bias)이 작용하게 된다. 예를 들어 1000개의 개발 데이터가 있고, 분류기가 98.0%의 정확성을 가지고 있다면, 980개의 정확히 분류된 데이터를 검사하는 것보다는 20개의 잘못 분류된 데이터를 검사하는 것이 조금더 쉬울 것이다. 이렇게 잘못 분류된 데이터에 대해서만 확인하는게 쉽기 때문에, 편견이 일부 개발 데이터 상에 스며들게 된다. 이런 편견은 딱 상품이나 제품을 개발에만 집중할 때는 어느정도 받아들일 수 있는 수준이지만, 만약 논문을 사용할 결과를 만들어 내거나 테스트 데이터의 정확성을 재기 위해 완전히 편견이 없는 측정을 하길 원한다면 문제가 될 수 있다.

< 해당 포스트는 Andrew Ng의 Machine Learning Yearning 중 chapter 16. Cleaning up mislabeled dev and test set examples을 번역한 내용입니다.>