[Ⅲ. Structuring Machine Learning Projects] Setting Up your Goal (3)
Structuring Machine Learning Projects
Setting Up your Goal
Train/Dev/Test Distributions
어떻게 개발 세트와 평가 지표를 설정하는지 보셨을 텐데요. 팀이 겨냥할 수 있는 곳에 대상을 배치하는 것 등입니다. 하지만 프로젝트 진행 도중에 목표를 잘못 설정했다는 것을 뒤늦게 깨달을 수도 있는데요. 이 때는 목표를 변경해야 합니다. 함께 예시를 보겠습니다.
예를 들어 고양이 분류기를 만들면서 고양이 애호가를 위한 사진을 찾기 위해 사용하기로 한 지표가 분류 오차일 수 있습니다. 알고리즘 A와 B는 각각 3%, 5% 오차를 가지기에 겉으로 보기엔 A 알고리즘이 더 낫다고 평가할 수 있죠.
하지만 직접 시현해봤을 때 어떤 이유에서인지 A 알고리즘이 포르노 이미지를 많이 허용하는 것입니다. 그렇게 해서 A 알고리즘을 사용하면 물론 유저들은 3%의 낮은 인식오류로 더 많은 고양이 사진을 볼 수 있지만. 이와 함께 포르노 이미지를 보게 될 수도 있는 것인데 이것은 회사와 유저 모두 용납할 수 없는 오류입니다.
반면 5% 오차율을 가진 알고리즘 B는 더 적은 사진을 분류하지만 포르노 이미지는 보여주지 않습니다. 기업의 입장과 유저들의 용납 가능성 측면에서 보면 B 알고리즘이 더 훌륭한 알고리즘이라고 볼 수 있겠죠. 포르노 이미지를 걸러내기 때문입니다.
이번 사례로 보면 A 알고리즘은 평가 지표에서는 3% 오차로 더 뛰어났지만 사실 더 좋다고 할 수 없습니다. 이 경우 평가 지표와 개발 세트는 알고리즘 A를 선호합니다. 알고리즘 A의 오차율이 더 낮으니까요. 하지만 여러분과 유저들은 포르노 이미지를 보여주지 않는 알고리즘 B를 선호합니다. 이렇게 평가 지표가 더 이상 선호되는 알고리즘의 순위를 제대로 반영하지 못한다면 이 경우 알고리즘 A가 더 낫다고 잘못 판단하는 것이 되겠는데요. 이는 평가 지표나 개발/시험 세트를 바꿔야 한다는 신호일 수 있습니다.
이 경우 여러분이 사용하는 분류 오차 지표는 파란색 식과 같이 표기될 수 있습니다. 개발 세트의 예시 i의 예측값이 실제 표기 i와 같은지 여부를 나타냅니다. 여기서는 예측값 표시를 위해 이 표기법을 사용합니다. 이 값은 0입니다. 이건 함수 표기법인데요. 안에 들어 있는 내용이 사실인 경우의 수를 셉니다. 그러므로 이 공식은 총 미분류 예시의 개수가 됩니다.
이 평가 지표의 문제점은 포르노 이미지와 일반 이미지를 똑같이 취급한다는 것입니다. 하지만 분류기가 포르노 사진을 잘못 표기하는 일은 절대 없어야겠죠. 포르노 이미지를 고양이 이미지로 인식할 수 있습니다. 이를 유저에게 갑자기 보여주게 되면 생각지 못하게 포르노를 보게 되어 아주 불쾌해할 것입니다.
이런 평가 지표를 바꾸는 한 가지 방법은 여기에 가중치 변수를 넣는 것입니다. 이것을 w(i)라고 하고, x(i)가 일반 이미지인 경우는 w(i)=1이고 x(i)가 포르노 이미지인 경우 10이나 100 등으로 식을 만드는 것입니다. 이와 같이 사진이 포르노 이미지인 경우 더 큰 가중치를 부여해 오류 값이 올라가도록 하는 것입니다. 이렇게 하면 포르노 이미지를 고양이 이미지로 잘못 분류하는 경우 오류 값이 훨씬 더 많이 올라가게 됩니다. 이번 사례에서는 포르노 이미지를 정확하게 분류하기 위해 포르노 이미지를 정확하게 분류하였을 시 가중치를 열 배로 높게 주었습니다.
이 정규화를 상수로 만들고 싶으면 이는 1/∑w(i)가 됩니다. 이렇게 하면 이 오류 값은 0에서 1사이의 값을 갖게 됩니다. 이 가중치의 디테일은 그리 중요하지 않으며 실제 가중치 도입을 위해서는 개발과 시험 세트를 거쳐야 합니다. 포르노 이미지를 개발과 시험 세트에 표기해 이 가중치 함수를 도입할 수 있습니다.
여기서 가장 중요한 것은 평가 지표가 실제로 알고리즘에 도움이 되는 순서대로 선호도를 알려주지 않는다고 하면 새로운 평가 지표 도입을 고려해야 한다는 것입니다. 앞서 말한 것은 평가 지표를 정의할 수 있는 한 가지 방법일 뿐입니다. 평가 지표의 목표는 포르노 스트리밍을 다양한 수준에서 응용 프로그램에서 더 잘 작동할지 정확하게 말해주는 것입니다.
본 목적상 새로운 오차 지표를 정의하는 세부적인 방법에 대해서는 너무 신경쓰지 마세요. 중요한 것은 이전 오류 지표가 만족스럽지 못한 경우 그 지표를 계속 유지하지 말고 어떤 것이 더 뛰어난 알고리즘인지에 대한 선호도를 잘 포착하는 새로운 지표 정의를 시도해 보세요.
눈치채셨겠지만 이제까지는 분류기 평가를 위한 그런데 이번 사례에서는 이렇게 고르는 것이 부적합한 것으로 드러났습니다. 포르노 스트리밍에서 순위 분류기가 다양한 수준으로 수행될 때 수행하고 있음을 정확하게 알려주는 것입니다. 이는 실제로 직교화의 한 예입니다. 머신 러닝 문제를 단계별로 나눠야 합니다. 첫번째는 수행하려는 작업을 캡처하는 메트릭을 어떻게 정의할지 파악하는 것입니다. 이 메트릭을 실제로 어떻게 수행할지는 따로 고민해 봐야 합니다.
머신 러닝 작업을 두 가지 다른 단계로 생각해 보세요. 대상 유추를 사용하기 위한 첫 단계는 대상 배치입니다. 목표 지점을 정의한 뒤 대상을 배치하는데 이것은 튜닝할 수 있는데요. 따로 조정할 수 있습니다. 이 알고리즘에서 좋은 결과를 내기위한 별개의 조정 단계라고 생각하세요. 어떻게 대상을 정확하게 겨냥할 것인지 어떻게 실행할 것인지 등이요.
지표 정의가 1단계이고 2단계는 또 따로 있는데 목표 실행 단계에서는 학습 알고리즘이 이런 비용 함수를 최적화하고 있을 수 있습니다. 훈련 세트의 손실을 최소화하면서요. 한 가지 할 수 있는 것은 이를 수정해 이런 가중치를 반영하는 것입니다. 잘 하면 이 정규화 상수도 바꿀 수 있겠죠. 1/w(i)의 합이죠. J를 어떻게 정의하는지에대한 상세 내용은 중요하지 않습니다.
중요한 것은 직교화의 철학을 바탕으로 대상 배치를 첫 번째로 생각하고 조준 및 목표 실행을 또 다른 단계로 떼어 생각하세요. 즉 지표 정의를 첫 단계로 생각하고 지표를 정의한 다음에야 그 지표에서 어떻게 좋은 성과를 낼지 생각해 보세요. 신경망이 최적화하고 있는 비용 함수J를 바꾸는 방법이 될 수도 있겠죠.
다음으로 넘어가기 전에 하나만 더 살펴보겠습니다. 고양이 분류기 A와 B가 있다고 해 봅시다. 개발 세트에서 각각 3%, 5% 오차가 나왔습니다. 아니면 다운받은 이미지들인 시험 세트의 오차일 수도 있지요. 고품질의 이미지들 말입니다. 그런데 알고리즘 제품을 투입하면 B 알고리즘이 더 뛰어난 성능을 발휘하는 것처럼 보이는 것입니다. 개발 세트에서는 더 잘 하고 있는데도 말이죠. 그리고 훈련은 인터넷에서 다운로드한 아주 좋은 고품질 이미지로 해 왔는데 막상 모바일 앱 유저들은 각양각색의 사진을 올립니다. 프레이밍이 훨씬 낮고 고양이만 담겨 있지도 않고 고양이 표정이 우스꽝스럽거나 이미지가 훨씬 흐릿할 수 있고 알고리즘을 테스트해 보면 알고리즘 B가 실제로 더 나은 결과를 낸다는 것을 발견하게 됩니다.
이는 지표와 개발 세트의 또 다른 실패 사례가 될 것입니다. 문제는 개발 및 시험 세트에서 아주 잘나오고 고화질의 고프레임 사진을 프레임이 높은 것이라는 점입니다. 하지만 유저들이 정말 원하는 것은 앱이 실제 올라가는 이미지를 잘 인식하는 것으로 이런 사진들은 엉성하거나, 흐릿하거나 프레임이 낮은 사진일 수도 있습니다.
따라서 지표나 현 개발 세트 또는 개발 및 시험 세트 배포에서 좋은 결과가 나오더라도 앱이 실제로 잘 작동하지 않는다면 지표와 개발 시험 세트를 바꿔야 합니다. 다시 말해, 개발 시험 세트는 고품질 이미지를 다뤘는데 앱은 저품질 이미지를 다뤄야 해서 실제 평가 결과가 앱 성능을 제대로 예측하지 못한다면 실제 대상 데이터가 잘 반영될 수 있도록 개발 시험 세트를 바꿀 때입니다.
그래서 실제 상황의 데이터가 더 잘 반영되도록 해야 합니다. 하지만 전반적으로 따라야 할 방향은 만약 현재 평가 중인 지표와 데이터가 실제 상황의 데이터에 대응되지 않는다면 지표 및/또는 개발/시험 세트를 바꿔 알고리즘을 실제 상황에 잘 대응시키는 것입니다. A 알고리즘과 B 알고리즘 중에 어떤것이 더 나은지 빨리 결정할 수 있습니다.
여러분과 팀의 빠른 반복 수행에 도움이 될 것입니다. 제가 추천 드리는 방법은 완벽한 평가 지표와 개발 세트를 정의할 수 없더라도 이를 대강이라도 빠르게 설정해 팀의 반복 수행 속도를 높이는 것입니다. 나중에 더 나은 옵션이 있다면 그 때 가서 바꿔도 전혀 늦지 않습니다. 하지만 대부분의 팀에게 드리는 조언은 평가 지표나 개발 셋업 없이 너무 오래 진행하지 마시라는 겁니다. 이렇게 하면 속도가 늦춰지고 팀 생산성에 문제가 생기고 알고리즘 개선 기회가 저해될 수 있습니다.
댓글남기기