[Ⅲ. Structuring Machine Learning Projects] Error Analysis (2)
Structuring Machine Learning Projects
Error Analysis
Cleaning Up Incorrectly Labeled Data
지도 학습 문제의 데이터는 입력값 X와 결과값 라벨 Y로 이루어져 있습니다. 만약 데이터를 확인하는 중에 이러한 Y의 결과값이 다르다는 것을 확인해서 데이터가 결과적으로 잘못되었음을 발견한다면 어떻게 될까요? 이런 라벨을 수정할 가치가 있을까요? 한번 살펴봅시다.
고양이 인식 문제에서는 이미지가 고양이인 경우 Y=1 고양이가 아닌 경우 0입니다. 여러분이 데이터를 보면서 이건 고양이고 이건 고양이가 아니고, 잠깐 이건 사실 고양이가 아니네요 라고 하는 경우 이는 라벨이 틀린 경우입니다. 저는 이런 경우에 잘못 라벨링된 예시라는 용어를 사용했는데요. 학습 알고리즘이 틀린 Y의 값을 줄 때 쓰는 용어입니다.
하지만 이번에 저는 잘못 라벨링된 예시라는 용어를 훈련 세트나 개발 세트 시험 세트에 있는 데이터 세트에 지정된 인간 라벨이 사실 틀린 경우에 사용하겠습니다. 그리고 저건 사실 강아지이기 때문에 Y는 애초에 0이였어야 합니다. 라벨 작업자가 틀린 것일수 있겠죠.
만약 데이터에 잘못 라벨링된 예시가 있다면 어떻게 해야 할까요?
먼저 훈련 세트를 고려해 봅시다. 딥 러닝 알고리즘이 훈련 세트에서 랜덤한 오류에 강하다는 것이 밝혀졌습니다. 그러니 오류나 잘못 라벨링된 예시들이 이 오류들이 완전 무작위 수치가 아닌 이상 라벨 작업자가 전혀 신경을 안 썼거나 키보드 작업에서 실수했을 수 있겠죠.
만약 오류가 합리적으로 랜덤하다고 하면 이 오류들을 그대로 놔 둬도 괜찮을 것입니다. 고치는데 너무 많은 시간을 쏟을 필요 없이 말이죠. 물론 훈련 세트로 가서 라벨을 검사하고 고쳐도 문제 없습니다. 가끔씩은 그럴 가치가 있지만 수정하지 않아도 결과값이 괜찮을 수 있습니다. 전체 데이터 세트와 실제 오류 비율이 너무 크지 않으면 말이죠.
저는 훈련 세트 라벨에서 X개의 실수가 조금 있음에도 정상적으로 작동하는 머신러닝 알고리즘을 많이 봅니다. 한가지 조건이 있기는 합니다. 딥 러닝 알고리즘이 랜덤한 오류에 강하다는 조건이죠. 딥 러닝 알고리즘은 시스템적 오류에는 보다 취약합니다.
예를 들어, 라벨 작업자가 지속적으로 흰 강아지를 고양이로 라벨링했다면 이는 문제가 됩니다. 분류기가 모든 흰 강아지를 고양이로 분류하도록 배웠기 때문이죠. 하지만 랜덤한 오류 또는 거의 랜덤한 오류들은 대부분의 딥 러닝 알고리즘에 그리 나쁘지 않습니다.
이번은 훈련 세트에서 잘못 라벨링된 예시를 집중적으로 다뤘는데요. 개발 세트나 시험 세트에서는 어떨까요?
만약 개발 세트나 시험 세트에서 잘못 라벨링된 예시가 걱정되실 경우 오류 분석 중에 추가 열을 하나 넣어 예시 개수를 세는 것을 추천드립니다. 라벨 Y가 틀린 부분의 총 개수를 말이죠.
예를 들어, 100개의 잘못 라벨링된 개발 세트 예시를 세는 경우 즉 분류기의 결과값이 개발 세트의 라벨과 다른 100개의 예시가 발견되는 경우죠. 가끔씩 이런 예시 중에서 단순히 라벨이 틀리기 때문에 분류기가 그 라벨에 반대하는 경우가 있습니다. 분류기가 틀려서가 아니라요.
이번 예시에서 여러분이 라벨 작업자가 배경에 있는 고양이를 못 본 걸 발견합니다. 그러면 여기 체크해 예시 98번이 잘못 라벨링 됐다고 표시합니다. 또 이 사진은 실제 고양이가 아니라 고양이 그림입니다. 여러분은 라벨 작업자가 Y=1 대신 Y=0으로 표기하길 바랐을 수 있죠. 그래서 여기에도 체크 표시를 합니다.
이전에 본 다른 카테고리로 발생한 오류 비율을 세면서 틀린 라벨로 발생한 오류 비율을 또 셉니다. 개발 세트에서 Y값이 틀린 곳은 학습 알고리즘이 다른 예측을 한 이유를 설명합니다. 그러면 여기서 문제는 여기 6% 틀리게 표기된 샘플을 고치는 것이 과연 가치있는 것일까 입니다.
제 조언은 만약 여러분의 알고리즘이 개발 세트에서 그 평가능력이 현저히 개선되어 바뀔 수 있다면 시간을 들여 틀린 라벨을 고치라고 말씀드릴 것입니다. 하지만 개발 세트의 평가능력이 의미 있는 변화가 없다면, 시간을 쓸 가치가 없을 수 있습니다. 정확히 무슨 뜻인지 예시를 통해 말씀드리겠습니다.
잘못 라벨링된 예시를 줄일지 여부를 결정할 때 다음 세 가지 수치를 참고하시는 걸 추천드립니다. 먼저 전체적인 개발 세트 오류를 살펴보세요. 이전에 나온 예시를 보면 시스템이 90%의 정확도를 가지고 있다고 했는데요. 그러면 10% 오류겠죠. 그리고 오류 개수나 잘못된 라벨링으로 인한 오류 비율을 봐야 합니다.
이번 케이스와 같은 경우 6%의 오류가 잘못된 라벨로 인한 오류입니다. 그러면 10%의 6%는 0.6%입니다. 그런 다음에는 다른 원인으로 인한 오류도 봐야 합니다. 만약 10% 오류가 개발 세트에서 발생했고 그 중 0.6%는 잘못된 라벨 때문이라면, 나머지 9.4%는 강아지를 고양이로 잘못 인식한 경우 등의 이유일 것입니다. 큰 고양이와 흐릿한 이미지 같은 경우죠.
그러므로 이 경우 9.4%의 오류를 수정할 가치가 있습니다. 잘못된 라벨로 인한 오류는 전체 오류 세트에서 적은 비중을 차지합니다. 원하신다면 잘못된 라벨 오류를 고치셔도 되지만 시급한 일은 아닙니다.
다른 예시를 살펴보겠습니다 학습 문제에서 상당부분 진전이 있었다고 해 봅시다. 그래서 10% 오류를 줄여 2%로 만들었다고 해 보겠습니다. 하지만 아직 전체 오류의 0.6%는 잘못된 라벨로 인한 것입니다. 그래서 이제 잘못 라벨링된 개발 세트 이미지를 검사하고 싶다면 이제 전체 오류가 2%가 된 상황에서는 라벨 표기 오류가 상당한 비중을 차지하는 비율이 됩니다. 0.6 나누기 2%로 사실 6%아 아니라 30%가 되는 것입니다. 틀린 예시들은 사실 틀린 라벨 예시로 인한 것으로 다른 원인으로 인한 오류는 이제 1.4%가 됩니다.
개발 세트 내에서 틀린 라벨로 인한 오류의 비중이 이렇게 크면 이제는 개발 세트에서 틀린 라벨을 수정하는 작업이 훨씬 가치있게 됩니다. 기억하실지 모르겠지만 개발 세트의 주된 목적은 분류기 A와 B 사이에서 어떤 것을 고를지 선택할 수 있도록 도움을 주는 것입니다. 그러면 분류기 A와 B가 있고, 개발 세트에서 하나는 2.1% 오류 다른 하나는 1.9% 오류를 낸다고 해 봅시다.
그러나 이러한 실수의 0.6%가 잘못된 라벨로 인해 발생하므로 개발 세트의 분류기 추천을 더 이상 믿기 어려워집니다. 그러면 이제 직접 개발 세트에서 잘못된 라벨을 고칠 좋은 이유가 생긴 것이죠. 여기 오른쪽 예시를 보시면 전반적인 알고리즘 평가에 이것이 큰 영향을 끼치는 반면 왼쪽은 알고리즘에 끼치는 영향 비율이 더 작습니다
이제, 개발 세트로 가서 라벨을 수동으로 검사하고 이를 직접 고치려 할 경우 여기 참고하실 만한 가이드라인과 원리가 있습니다. 먼저 어떤 방식의 프로세스를 적용하던 이를 개발 세트와 시험 세트에 동시에 적용시키면 좋습니다. 앞서 왜 개발 세트와 시험 세트가 같은 분포에서 와야 하는지를 배웠습니다. 개발 세트는 어디를 타겟으로 잡아야 할지 알려주며, 이것이 시험 세트에서도 일반화가 되게 해 줘야 합니다.
그래서 개발과 시험 세트가 같은 분포에서 온 경우 더 효율적으로 일할 수 있습니다 만약 개발 세트에서 뭔가를 고치려 한다면 시험 세트에서도 똑같은 절차를 적용하는 것이 좋습니다. 이들이 같은 분포에서 오도록 말이죠. 가령 라벨을 더 신중하게 검사하도록 누군가를 고용할 경우 개발과 시험 세트 모두에 이를 적용하세요.
둘째, 알고리즘이 맞췄던 것과 틀렸던 것의 예시를 잘 살펴보는 것이 좋습니다. 알고리즘이 잘못한 예시를 보고 이것이 고쳐져야 한다 판단하는 것은 쉽습니다. 한편 여러분이 제대로 맞추지 못한 것들을 수정해야 할 수도 있습니다. 알고리즘이 잘못했던 것만 고치게 되면 알고리즘에 더 많은 편향 추정값과 오류가 남게 됩니다. 알고리즘에 불공평한 이점을 부여하는 셈이죠.
무엇을 틀렸는지만 확인하고 무엇을 잘 맞췄는지 다시 확인하지는 않습니다. 단지 운이 좋아 맞춘 경우 라벨만 고치게 되면 맞췄던 게 틀리게 될 수 있습니다. 이 두번째 부분은 쉽지 않아서 항상 실행되지는 않습니다.
그 이유는 만약 분류기가 아주 정확하다면 틀리는 경우보다 맞추는 경우가 더 많게 됩니다. 만약 분류기가 98% 정확도를 가진 경우 2% 틀리고, 98% 맞추는 것입니다. 그러므로 2%의 데이터 라벨을 검사하고 입증하는 것이 훨씬 쉽고, 98%의 데이터를 입증하는 것은 훨씬 더 오래 걸립니다. 그렇기 때문에 두 번째 조언이 잘 실행되지는 않는 것이죠. 그냥 염두에 두시면 좋을 사항입니다.
마지막으로 저 라벨들을 개발과 시험 세트에서 고칠 경우 동일한 절차를 훈련 세트에 적용할 수도 하지 않을 수도 있습니다. 초반에 얘기한 것을 기억합시다. 훈련 세트에서 라벨을 수정하는 것은 덜 중요한 편입니다. 또한 개발과 시험 세트의 라벨이 훈련 세트 대비 적은 경우가 많으므로 훨씬 더 큰 훈련 세트에서 라벨 수정에 추가적으로 힘을 들이지 않을 수 있습니다.
학습 알고리즘은 이런 것에 꽤 탄력적인 편인데요 개발과 시험 세트가 같은 분포를 갖는 것이 아주 중요합니다. 하지만 훈련 세트가 살짝 다른 분포를 갖는 것도 비교적 합리적일 수 있습니다. 이를 어떻게 처리하는지 더 이야기하도록 하겠습니다
그럼 몇 가지 조언을 드리고 마치겠습니다.
첫째, 딥 러닝 연구원들은 이렇게 말하는 것을 좋아합니다. “방금 데이터를 알고리즘에 넣었어 훈련을 시켰는데 잘 작동해” 이는 딥 러닝 오류에 관해서는 사실입니다. 알고리즘에 데이터를 넣어 훈련 시키는 것이 수동 엔지니어링 작업이나 인간의 통찰력 개입보다 더 많은 편이죠. 하지만 실용적 시스템 구축에 있어 딥 러닝 연구원들이 인정하는 것보다 더 많은 수작업 오류 분석과 인간적 통찰이 시스템에 들어간다고 생각합니다.
둘째, 저는 일부 엔지니어나 연구원들이 왜인지 예시 수동 검사를 싫어하는 걸 보았습니다. 아마 그리 재미있는 작업은 아닐 테지요. 오류 수를 세기 위해 가만히 앉아 예시 몇백 개를 살펴보는 일이요. 하지만 이것은 저도 직접 하고 있는 일입니다. 제가 머신러닝 팀을 리드하는 경우 머신러닝이 어떤 실수를 하고 있는지 이해하고 싶을 것입니다. 저는 개인적으로 데이터를 직접 볼 것 같습니다. 오류 비율을 세기 위해서 말이죠. 이렇게 데이터를 세는 몇 분, 몇 시간이 다음 우선순위를 결정하는 데 도움이 된다고 생각합니다. 이는 아주 가치있는 일이라고 생각됩니다.
여러분도 해보기를 추천드립니다 만약 시스템에 이러한 머신이 있고 우선순위를 매기기 위해 어떤 방향을 택해야 할지 고민된다면요. 이것으로 오류 분석 절차에 대한 내용을 마치겠습니다. 다음 에서는 오류 분석이 새로운 머신러닝 프로젝트 시작 방법에 어떻게 적용되는지를 얘기해 보겠습니다.
댓글남기기