개발 데이터와 테스트 데이터가 같은 분포를 가지는 상태에서 학습을 시키고 있다고 가정하자. 그러면 단순히 성능을 향상 시키기 위해서 항상 많은 학습 데이터를 수집하려고 할 것이다. 그렇지 않나? 데이터를 많이 가지는 것 자체가 물론 나쁜건 아니지만, 그렇다고 바라는 만큼 항상이 도움이 되지는 않는다. 어쩌면 데이터를 추가로 수집하는 작업 자체가 시간 낭비가 될 수 있다. 그러면 언제 데이터를 수집하고, 언제 수집하지 말고를 어떻게 결정해야 할까? 머신러닝 작업에서 오류를 발생시키는 요인이 두개가 있는데, 그게 bias와 variance 이다. 이 두 요인에 대해서 이해하는 것이 아마 데이터를 수집해야 할지 말지 결정하는 것을 도와 줄 것이고, 이게 성능을 향상시켜주는 다른 작업과 같이 시간을 적절하게 쓰..
- 새로운 프로젝트를 시작할 때, 특히 해당 분야에 대해서 전문가가 아니라면, 뭔가 가장 확신을 줄 수 있는 방향을 올바르게 선정하기는 어렵다. - 그렇기 때문에 시작할 때부터 완벽한 시스템을 설계하고 만들 생각을 하지마라. 대신 가장 기본적인 시스템부터 될수 있으면 빠르게 만들어라(대략 며칠동안 만들수 있는 정도?) 그리고 오류 평가를 활용해서 가장 확신을 줄수 있는 방향을 선정하고, 거기서부터 알고리즘을 반복적으로 개선할 수 있도록 해보자. - 100여개의 잘못 분류된 데이터를 일일이 확인해보고 주요 오류가 발생하는 카테고리를 파악하는 것과 같은 방식으로 오류 평가를 수행해라. 그리고 이 정보를 활용해서 수정해야 할 오류의 종류별로 우선순위를 정하자. - 개발 데이터를 수동적으로 확인해볼 Eyebal..
만든 알고리즘에서 발생하는 주요 오류 카테고리를 파악하기 위해서는 Eyeball dev set이 충분히 커야 한다. 만약 (이미지에서 고양이를 인식하는 것과 같이) 사람이 잘하는 것에 대해서 신경쓰려면, 몇가지 대략적인 가이드라인을 들 수 있다. - 분류기가 10개 정도의 실수를 하는 eyeball dev set은 매우 작은 크기라고 고려할 수 있다. 보통 10개의 오류라고 하면, 이게 다른 오류 카테고리라고 정확하게 평가하기 어렵다. 하지만 만약 가지고 있는 데이터가 매우 작고, eyeball dev set에 더 넣을 데이터가 없다면, 해당 dev set은 없는 것보다 낫고, 프로젝트 내에서 우선순위를 정할때 도움이 된다. - 분류기가 20개 정도의 실수를 하는 eyeball dev set이라면, 대략..
만약 20%의 오류를 가지는 5000개의 큰 개발 데이터가 있다고 가정해보자. 그러면 지금 사용하고 있는 알고리즘은 1000개 정도의 개발 데이터를 잘못 분류하고 있는 것이다. 이 1000개 이미지를 일일히 확인하려면 시간이 많이 걸리므로, 그 데이터들을 모두 오류 평가시 사용하지 않기로 결정할 것이다. 이 케이스에서, 나는 보통 개발 데이터를 크게 두개의 집합으로 나누고, 하나는 유심히 보고, 다른 하나는 보지 않는다. 그리고 나서 유심히 볼 집합에 대해서만 조금더 자주 학습을 시키고, 유심히 보지 않는 집합은 내부 parameter를 수정하는데 활용하곤 한다. 앞에서 다룬 예제를 계속 살펴보면 우리가 쓰고 있는 알고리즘은 전체 5000개의 개발 데이터 중에서 1000개를 잘 못 분류하고 있다. 우리가..
오류 평가를 하는 동안, 아마 개발 데이터 상에서 잘못 라벨링(mislabeled)된 것들이 몇몇 있는 것을 확인할 수 있을 것이다. 여기서 잘못 "라벨링"이 되었다는 것은, 이미 알고리즘을 적용하기 전부터 사람에 의해서 이미 잘못 라벨링이 된 이미지들을 말하는 것이다. 예를 들어 (x, y)라는 데이터가 있을 때 y에 대해서 잘못된 값을 가지고 있는 것이다. 다른 예를 들자면, 고양이가 아닌 사진들이 고양이가 포함되어 있는 것처럼 잘못 라벨링이 되어 있는 케이스가 있을 것이다. 잘못 라벨링된 이미지의 비율이 중요하다고 여겨지면, 해당 데이터의 비율에 대한 카테고리를 만들고 한번 살펴봐라:Image Dog Great Cat Blurry Mislabeled Comments ... 98 O 배경에 있는 고양..
고양이 감지기의 성능을 향상시키기 위해 몇가지 아이디어를 내놨다.- 개를 고양이로 인식하는 것에 대한 알고리즘 문제 해결 - 사자나 표범과 같이 거대한 고양이과 동물을 집고양이라고 인식하는 것에 대한 알고리즘 문제 해결 - 흐릿한 이미지에 대한 시스템 성능 개선이런 아이디어들을 병렬로 효율적으로 평가를 할 수 있다. 종종 본인은 엑셀과 같은 스프레드시트를 만들고 100여개의 잘못 분류된 개발 데이터 이미지를 보면서 그걸 채운다. 또한 몇몇 예제에 관해서 기억하기 쉽게끔 코멘트를 기입한다. 이 과정에 대해 묘사하기 위해서 아래와 같이 4개의 개발 데이터에 대한 스프레드시트를 한번 보자.Image Dog Great Cat Blurry Comments 1 O 흔하지 않은 색깔을 가진 핏볼 2 O 3 O O 비..
이전에 만든 고양이 앱을 실행하다보면, 고양이를 개로 잘못 분별하는 몇몇 케이스를 확인할 수 있을 것이다. 어떤 개들은 정말 고양이 같이 생기기도 했다. 개발 인원 중 하나가 개 이미지에 대해서 조금더 잘 찾아낼 수 있게 해주는 외부 SW를 도입할 것을 제안했다. 이걸 적용하려면 한달정도 걸릴 것이고, 그 인원은 매우 열심히 할 것이다. 만약 당신이라면 그에게 진행하라고 할수 있을까? 이 업무에 대해서 한달이란 시간을 쓰기전에 먼저 해당 작업이 시스템의 정확성을 얼마나 올려줄 수 있는지 먼저 검토해볼 것을 추천한다. 그러고나서 이성적으로 그게 한달의 개발 시간을 쓸 가치가 있는지를 결정하고, 그게 아니면 다른 일에 그 시간을 쓸 수 있어야 한다. 자세하게 말하자면, 당신이 해야 할 일은 이것이다:1. 먼..
만약 새로운 스팸메일 탐지 시스템을 만들고 싶다면, 몇가지 아이디어를 떠올릴 수 있을 것이다.- 엄청난 량의 학습시킬 스팸 메일을 수집한다. 예를 들어 "꿀단지" 같은 것을 만드는 것인데, 흔히 알려져 있는 스팸 출처에 가짜 이메일 계정을 보내면, 자동적으로 출처가 그 계정으로 보낸 스팸 메일들을 수집할 수 있을 것이다. - 메일안에 있는 문맥을 이해할 수 있는 기능을 개발한다. - 이메일의 헤더를 인식시킬 수 있는 기능을 만들어 스팸 메일들이 어떤 서버를 거쳐서 오는지를 보여준다. - 기타 등등... 나도 스팸 메일 탐지와 관련해서 많이 일해봤지만 여전히 위의 방법 중 어떤 방법을 선택하는지 어려움을 겪고 있다. 아마 당신도 해당 영역의 전문가가 아니라면 더 어려울 것이다. 그렇기 때문에 시작부터 완벽..
- 당신이 미래에 얻길 원하고, 잘 동작하기를 원하는 성향을 잘 반영한 분포를 가지는 개발 데이터와 테스트 데이터를 취해라. 어쩌면 그 데이터들은 학습 데이터의 분포와 같지 않을 수도 있다.- 되도록이면 개발 데이터가 테스트 데이터와 분포가 같은 것들을 취하라.- 최적화할 수 있는 단수 형태의 평가 지표를 선정하라. 만약 신경써야할 goal이 여러 개라면, 그 값들을 하나의 공식을 통해서 결합하던가(예를 들어 여러 개의 오차 지표의 평균을 낸다던가) 혹은 만족 지표와 최적화 지표를 정의하던지의 방식을 적용해라.- 머신러닝 자체는 매우 반복적인 작업이기 때문에 어떤 적당한 알고리즘을 찾기 전에는 수많은 알고리즘들을 시도해볼 수 있을 것이다.- 개발/테스트 데이터를 가지고, 뭔가 단수 형태의 평가 지표를 가..
보통 새로운 프로젝트를 시작할 때, 나는 빠르게 개발 데이터/테스트 데이터를 선정한다. 이를 통해서 우리가 추구하는 잘 정의된 목표를 찾을 수 있기 때문이다. 나도 보통 우리팀한테 초기의 개발/테스트 데이터와 초기 평가 지표를 찾아내는데 1주일을 넘지 않게 준다. 한가지 주제에 대해서 과도하게 생각하기 보다는 뭔가 완벽하지는 않지만 빠르게 얻어내는게 조금더 낫기 때문이다. 하지만 이 1주일이라는 시간은 우리가 만들고 있는 것을 발전시키는데 반영되지는 않는다. 예를 들어 스팸차단 시스템은 이미 발전된 형태의 딥러닝 시스템이다. 이렇게 발전된 형태의 시스템도 더 좋은 개발/테스트 데이터를 얻기 위해서 몇달을 쓰곤한다. 만약 나중에라도 초기에 잡은 개발/테스트 데이터나 평가 지표가 뭔가 초점에서 어긋났다는 것..
새로운 문제를 딱 접했을 때, 어떤 접근 방식이 가장 잘 동작하는지 미리 아는 것은 매우 어려운 일이다. 많은 경험이 쌓인 머신러닝 엔지니어라도 만족스러운 결과를 얻을 때까지 다양한 아이디어들을 시도해본다. 머신러닝을 적용한 시스템을 만들때, 나는 보통 이렇게 한다.1. 시스템을 어떻게 만들 수 있는지 몇가지 아이디어를 내본다. 2. 그런 아이디어들을 코드로 구현해본다. 3. 어떤 아이디어가 동작하는지 실험을 해본다.(종종 몇몇 아이디어들은 잘 동작하지 않는다.) 이런 학습을 통해서 다시 아이디어를 내보고, 반복해본다. 이건 일종의 반복 작업이다. 이런 반복 과정을 빠르게 수행할수록, 일의 진척이 빨라진다. 이게 바로 개발 데이터/테스트 데이터를 가져야 하고, 평가 지표가 중요한 이유이다. 매번 새로운 ..
여러 개의 평가 지표(Evaluation Metrics)를 결합하는 또다른 방법이 있다.Classifier Accuracy RunningTime A 90% 80ms B 92% 95ms C 95% 1500ms Accuracy와 Running Time 을 아래와 같이 Accuracy - 0.5 * RunningTime 라는 식을 통해 accuracy와 RunningTime을 하나의 식에 넣음으로써 하나의 평가 척도로 정의하는 것 자체가 부자연스럽게 보일 수 있다. 여기서 이렇게 식을 넣는거 대신에 할 수 있는 것이 있다. 첫번째로 "받아들일 수 있을 만한" RunningTime이 무엇인지를 정의해볼 수 있다. 예를 들어 100ms안에 동작하는 것은 어떤것이든 받아들일 수 있을만한 것이라고 가정해보자. 그러면..
분류 정확성은 단수(single number)로 표현할 수 있는 평가 척도 중 하나이다. 당신이 만든 분류기에 개발 데이터(혹은 테스트 데이터)를 넣고, 해당 데이터가 정확하게 분류를 했는지에 대한 비율을 단수로 평가해주는 것이다. 이 평가 척도에 따르면, 만약 A 분류기가 97%의 정확성을 가지고, B 분류기가 90%의 정확성을 가진다면, 보통 우리는 A 분류기의 성능이 더 좋다고 판별할 수 있다. 이와 대조적으로, 정밀도(Precision)과 재현율(Recall)은 단수로 표현할 수 있는 평가 척도가 아니다. (참고로 정밀도는 분류기가 참이라고 분류한 결과물 중 실제로도 참일 확률을 말하고, 재현율은 분류기가 정상적으로 분류한 것들 중에서 실제로도 참일 확률을 말한다. 수식으로 표현하면 다음과 같다...
개발에 적용할 알고리즘들 간의 차이를 확인하기 위해서는 개발 데이터가 충분히 많아야 한다. 예를 들어 A 분별기가 90.0%의 정확성을 가지고, B 분별기가 90.1%의 정확성을 가진다고 가정한다면, 100개의 개발 데이터를 가지고는 0.1%의 차이를 확인하기 어려울 것이다. 본인이 접한 다른 머신러닝을 활용한 문제들을 놓고 보았을 때, 100개의 개발 데이터는 매우 적은 량이다. 일반적으로 개발 데이터는 1000개에서 10000개 사이의 데이터를 가진다. 10000개의 데이터를 통해서라면 앞에서 언급했던 0.1%의 성능 향상을 확인하기 쉬울 것이다. (이론상으로는 개발 데이터 상에서 알고리즘들 간의 차이가 통계적으로 큰 차이를 가지는지를 확인해볼 수 있다. 하지만 현업상에서는 이런 관점을 (굳이 논문으..
이전에 다뤘던 내용에 덧붙여서 개발 데이터와 테스트 데이터를 정의하고 난 이후에, 이제 개발 데이터의 성능을 향상시키는 방법에 초점을 맞출 것이다. 결론적으로 개발 데이터는 가장 최우선적으로 당신이 향상시키고자 하는 학습을 반영할 수 있어야 한다. 여기에 개발 데이터와 테스트 데이터의 분포가 다름으로써 발생할 수 있는 문제가 있다. 바로 개발 데이터 상에서는 잘 동작하는데, 실제로 테스트 데이터에서는 매우 안좋게 돌아가는 것이다. 이런 경우 큰 좌절감이 생기고, 노력이 낭비되는 것을 봐왔는데, 이런 현상이 발생하는 것을 막아야 한다. 예를 들어 현재 개발되는 시스템이 개발 데이터에서는 잘 돌아가고 테스트 데이터에서는 잘 돌아가지 않는 현상이 발생한다고 가정하자. 만약 개발 데이터와 테스트 데이터가 같은 ..
- Total
- Today
- Yesterday
- 강화학습
- 딥러닝
- 파이썬
- Distribution
- Kinect SDK
- Off-policy
- PowerPoint
- TensorFlow Lite
- ColorStream
- bias
- Expression Blend 4
- arduino
- Policy Gradient
- Kinect for windows
- processing
- Offline RL
- Gan
- Pipeline
- reward
- Python
- Variance
- End-To-End
- DepthStream
- Kinect
- 한빛미디어
- dynamic programming
- RL
- windows 8
- Windows Phone 7
- SketchFlow
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |