티스토리 뷰

 이전에 만든 고양이 앱을 실행하다보면, 고양이를 개로 잘못 분별하는 몇몇 케이스를 확인할 수 있을 것이다. 어떤 개들은 정말 고양이 같이 생기기도 했다.

 개발 인원 중 하나가 개 이미지에 대해서 조금더 잘 찾아낼 수 있게 해주는 외부 SW를 도입할 것을 제안했다. 이걸 적용하려면 한달정도 걸릴 것이고, 그 인원은 매우 열심히 할 것이다. 만약 당신이라면 그에게 진행하라고 할수 있을까?

 이 업무에 대해서 한달이란 시간을 쓰기전에 먼저 해당 작업이 시스템의 정확성을 얼마나 올려줄 수 있는지 먼저 검토해볼 것을 추천한다. 그러고나서 이성적으로 그게 한달의 개발 시간을 쓸 가치가 있는지를 결정하고, 그게 아니면 다른 일에 그 시간을 쓸 수 있어야 한다.

 자세하게 말하자면, 당신이 해야 할 일은 이것이다:

1. 먼저 시스템상에서 잘못 분류된 예제중 100여개 정도의 개발 데이터 샘플을 얻는다. 다시 말해 시스템이 오류가 나고 있다고 생각되는 예제들 말이다.
2. 그 예제들을 일일이 살펴보고, 실제로 그게 개 이미지일 비율을 한번 측정해본다.

이런식으로 잘못 분류된 데이터를 찾는 과정 자체를 오류평가(Error Analysis)라고 한다. 위의 예제에서는 만약 당신이 찾은 잘못 분류한 개의 이미지의 비율이 단순히 5% 정도라면, 개 이미지에 대해서 아무리 알고리즘의 성능을 개선할 지라도, 전체 오류의 5% 이상을 해결할 수 없다. 다르게 표현하면 5%는 해당 인원이 제안한 프로젝트로 개선될 수 있는 일종의 "천장"(최대한 얻을 수 있는 정도)인 것이다. 그렇기 때문에 만약 지금 시스템이 한 90% 정도의 정확성을 가진다면,(다르게 표현하면 10%의 오류) 이런 식의 개선은 최대 90.5% 정도의 정확성을 가지게 될 것이다.(혹은 원래 10%의 오류 보다 5% 낮은 오류 이므로 9.5% 의 오류라고 볼 수 있다.)

 반대로 만약 오류의 50% 정도가 개 이미지라면, 해당 인원이 제안했던 프로젝트는 큰 효과를 가져올 것이라고 확신할 수 있게 된다. 정확성을 90%에서 95%로 올릴 수 있게 된다. (오류로 따진다면 50% 상대적인 감소이므로 10%에서 5%로 떨어진 효과일 것이다.)

 이와 같은 오류 평가에서 간단하게 진행할 수 있는 과정은 개 이미지를 분류하기 위해서 외부 SW를 사용하는 것에 대해서 빠르게 검토할 수 있는 방법을 제공한다. 결국 이 투자를 해야할지 여부에 대해서 결정할 수 있는 정량적인 기반을 제공해주게 되는 것이다.

 오류 평가는 종종 다른 방향이 얼마나 보장되는지를 확인할 수 있게 도와주곤 한다. 본인도 업무를 하는 동안 많은 기술자들이 오류 평가를 하는 것에 대해서 매우 싫어하는 것을 봐왔다. 이걸 하면 뭔가 그 아이디어가 시간을 투자할 만한 것인지에 대한 질문보다는 어떤 아이디어에 바로 뛰어들어서 구현해보는 것이 더 흥미있는 것일 수도 있다. 이런 행동은 흔히 겪을 수 있는 실수이다. 이렇게 하면 해당 아이디어가 별로 이득이 없다는 것을 파악하는데 한달이라는 시간을 쓰게 만드는 것이다.

 이런 예제 100개를 일일이 확인해보는 것은 그렇게 오래 걸리지도 않는다. 비록 이미지 하나를 확인하는데 1분이 소요될 지라도, 2시간 안에 이 일을 마무리할 수 있다. 이렇게 사용한 2시간이 어쩌면 노력이 낭비될 수 있는 한달이라는 시간을 아끼게 해줄 수 있다.

 오류 평가는 시스템에 구현되어 있는 알고리즘이 잘못 분류한 개발 데이터를 확인해봄으로써, 오류의 원인에 대해서 이해할 수 있는 일련의 과정이다. 이런 과정은 이 예제로 한정했을 때는 당신으로 하여금 프로젝트의 우선 순위를 부여할 수 있게 해주고, 새로운 방향을 제시해줄 수도 있다. 이부분은 다음 장에서 다룰 것이다. 이어지는 장에서 오류 평가를 수행하는데 있어 최적의 예제를 소개할 것이다.

< 해당 포스트는 Andrew Ng의 Machine Learning Yearning 중 chapter 14. Error analysis: Look at dev set examples to evaluate ideas을 번역한 내용입니다.>

댓글