티스토리 뷰
고양이 감지기의 성능을 향상시키기 위해 몇가지 아이디어를 내놨다.
- 개를 고양이로 인식하는 것에 대한 알고리즘 문제 해결
- 사자나 표범과 같이 거대한 고양이과 동물을 집고양이라고 인식하는 것에 대한 알고리즘 문제 해결
- 흐릿한 이미지에 대한 시스템 성능 개선
이런 아이디어들을 병렬로 효율적으로 평가를 할 수 있다. 종종 본인은 엑셀과 같은 스프레드시트를 만들고 100여개의 잘못 분류된 개발 데이터 이미지를 보면서 그걸 채운다. 또한 몇몇 예제에 관해서 기억하기 쉽게끔 코멘트를 기입한다. 이 과정에 대해 묘사하기 위해서 아래와 같이 4개의 개발 데이터에 대한 스프레드시트를 한번 보자.
Image |
Dog |
Great Cat |
Blurry |
Comments |
1 |
O |
|
|
흔하지 않은 색깔을 가진 핏볼 |
2 |
|
|
O |
|
3 |
|
O |
O |
비오는 날, 동물원에서 찍었던 |
4 |
|
O |
|
나무 뒤에 있는 표범 |
% of total |
25% |
50% |
50% |
|
3번 이미지 같은 경우는 Great Cat과 Blurry에 둘다 체크되어 있다. 게다가 이런식으로 하나의 이미지가 여러 개의 카테고리와 연관되어 있을 수 있기 때문에 하단에 있는 퍼센트는 다 더해도 100%가 안될 수 있다.
아마 처음에는 Dog, Great Cat, Blurry와 같이 분류 항목을 정하고, 수동으로 해당 데이터들을 분류했을텐데, 실제로 이 예제들을 보기 시작하면 새로운 오차 카테코리에 대해서 고려해볼 수 있을 것이다. 예를 들어 여러 개의 이미지를 확인해보니 해당 이미지에 Instagram이 가한 필터가 적용된 이미지에서 발생한다는 것을 확인할 수 있다. 이렇게 되면 스프레드시트상에 새롭게 "Instagram"이라고 새 항목을 추가할 수 있다. 위와 같이 알고리즘이 잘못 분류한 데이터들을 한번 일일이 확인해보고, 사람이 이를 바르게 분류하였는지 확인할 수 있다면, 이런 과정은 새로운 오차 분야와 해당 오차에 대한 솔루션을 제공할 수 있을 것이다.
오류 카테고리 중 가장 도움이 될 수 있는 오류 카테고리가 있다는 것은 뭔가 개선할 수 있는 부분이 있는 것이다. 예를 들어, 앞에서 새로 만든 "Instagram" 카테고리는 만약 해당 이미지에서 인스타그램 필터를 제거하고, 원래 이미지로 되돌려줄 생각이 있으면 가장 도움이 될만 한 것이다. 하지만 꼭 오류 카테고리를 통해서 뭔가를 향상시켜야 한다고 스스로를 제한시킬 필요는 없다. 이런 과정을 수행하는 목적은 초점을 맞출 수 있는 가장 확실한 영역에 대한 직관을 키우는 것이다.
오류 평가는 일종의 반복적인 과정이다. 처음에 아마 카테고리도 없는 상태로 시작한다고 걱정하지 마라. 몇몇 이미지들을 살펴보다 보면, 오류 카테고리에 대해서 아이디어가 좀 생길 것이다. 그리고 몇몇 이미지들을 수동적으로 분류하다보면, 새로운 카테고리에 대해서 아이디어를 가지게 될 것이고, 기존 이미지들을 새로운 카테고리에 맞춰 다시 분류해볼 것이다.
만약 100개의 잘못 분류된 개발 데이터에 대해서 오류 평가를 수행하고 나서 다음과 같은 결과를 얻었다고 가정해보자.
Image | Dog | Great Cat | Blurry | Comments |
1 | O |
|
| 흔하지 않은 색깔을 가진 핏볼 |
2 |
|
| O |
|
3 |
| O | O | 비오는 날, 동물원에서 찍었던 |
4 |
| O |
| 나무 뒤에 있는 표범 |
... | ... | ... | ... | ... |
% of total | 8% | 43% | 61% |
|
이제 맨처음에 소개했던 개를 잘못 분류하는 실수를 수정하게 되면, 최대 8% 정도의 오류를 제거할 수 있다. 만약 고양이과 동물이나 흐릿한 이미지에 대한 오류를 수정하면 조금더 많은 오류를 수정할 수 있게 된다. 그러므로 이를 통해 두개의 카테고리 중 하나를 선택하면 된다. 만약 팀내에 이런 여러 방향을 동시에 진행할만큼 충분한 사람이 있다면, 몇몇 사람은 고양이과 동물에 대한 문제를 풀게 하고, 나머지는 흐릿한 이미지에 대한 문제를 해결하게 하면 된다.
오류 평가는 반드시 해야 할 일의 우선 순위를 말해주는 명확한 수학적 공식이나 그런 것을 만들어주지 않는다. 그렇기 때문에 각각의 다른 카테고리에 대해서 얼마나 개선시킬 수 있는지와 각각의 일을 할 경우 필요한 일의 양 같은 것을 계산해봐야 한다.
< 해당 포스트는 Andrew Ng의 Machine Learning Yearning 중 chapter 15. Evaluating multiple ideas in parallel during error analysis을 번역한 내용입니다.>
'Study > AI' 카테고리의 다른 글
[MLY] Eyeball 데이터와 Blackbox 데이터는 얼마나 커야 할까? (0) | 2018.09.09 |
---|---|
[MLY] 개발 데이터가 많은 경우, 두 집합으로 나누고 하나에서만 확인하기 (0) | 2018.09.08 |
[MLY] 개발 데이터상에 잘못 라벨링된 것 정리하기 (0) | 2018.09.08 |
[MLY] 오류 평가: 아이디어 검증을 위한 개발 데이터 예제 탐색 (0) | 2018.09.06 |
[MLY] 빠르게 구현하고 나서 반복하기 (0) | 2018.09.05 |
[MLY] 개발 환경과 테스트 데이터를 설정하는 데 있어 고려해야 할 사항들 (0) | 2018.09.05 |
[MLY] 개발/테스트 데이터와 평가 지표를 바꿔야 하는 경우 (0) | 2018.09.05 |
- Total
- Today
- Yesterday
- ai
- Kinect for windows
- Off-policy
- Distribution
- 강화학습
- ColorStream
- RL
- dynamic programming
- Policy Gradient
- bias
- 딥러닝
- 한빛미디어
- TensorFlow Lite
- Kinect SDK
- PowerPoint
- Windows Phone 7
- 파이썬
- arduino
- windows 8
- Offline RL
- Expression Blend 4
- DepthStream
- Kinect
- End-To-End
- processing
- Pipeline
- Gan
- Variance
- SketchFlow
- reward
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |