Deciding on ML

데이터를 본격적으로 다루기 전에, 준비되었는지 확인해보는 과정을 거치도록 하자. 아래에서는 머신 러닝 문제들을 구성하기 전에 생각해야 할 몇가지 사항에 대해 간략하게 설명한다.

명확하고 간단하게 시작하라.

말 그대로, ML 모델이 어떤 일을 했으면 좋겠는가?

현 시점에서, 이에 대해 답하는 것은 다소 정성적인 목표가 될 수 있으나, 간접적인 목표가 아니라, 실제 목표를 지니고 있는지 확인하라.

어떤 결과가 이상적인가?

시스템에 ML 모델을 추가하는 것은 이상적인 결과를 생산해야 한다. 이는 단순히 모델과 그 품질을 평가하는 것과는 다른 의미를 갖는다.

주의: 똑같은 모델로도 다른 이상적인 결과를 목표로 할 수 있다. 이것이 이상적인 결과를 명확하게 두어야 하는 이유다.

이미 최적화를 하고 있는 서비스의 매트릭스에 갇혀있지 마라. 제품 및 서비스의 더 큰 목표에 집중해야 한다.

성공/실패 매트릭스(지표)

정량화하라

시스템이 성공적인지 아닌지 어떻게 판단할 수 있을까?

성공 및 실패 매트릭스는 정밀도, 재현율 또는 AUC와 같은 평가 매트릭스와 독립적으로 표현되어야 합니다. 대신, 예상 결과를 구체화시켜야 합니다. 시작하기 전에 미리 성공 매트릭스를 설정하세요. 이는 매몰 비용으로 우리가 평범한 모델로부터 시작하게끔 하는 것을 막기 위해서 입니다.

측정 가능한 매트릭스인가?

측정가능한 지표는 실제로 적용하였을 때의 평가에 있어 충분한 정보를 제공한다. 예를 들어, 과수원의 건강 상태를 모니터링하는 시스템은 병든 나무들의 비율을 줄이고자 한다. 한편, "어떤 나무가 병든 나무인가?"에 대한 측정이 불가능하다면, 그다지 유용한 지표는 아니다.

아래와 같은 질문들을 스스로 해보자.

• 어떻게 지표를 측정하는가?
• 언제 지표를 측정할 수 있는가?
• 새로운 ML 시스템이 성공적인지 아닌지를 판단하는 데에 얼마나 많은 시간이 걸릴 것인가?

이상적으로는, 빨리 실패하고자 할 것이다. 데이터의 신호(Signal)가 너무 적거나, 예측할 수 없는 데이터가 있는지를 확인하여 가설이 틀릴 수 있는지에 대해 판단하라. 빠른 실패는 프로세스의 초기에 가설을 수정하고 시간 손실을 방지할 수 있다.

보다 장기적인 관점에서 엔지니어링 및 유지 비용을 고려하라.

다른 실패 시나리오

성공 지표와 관련이 없는 실패에 대해서도 확인하라. 예를 들어, 영상 추천 시스템이 항상 "어그로 영상"들을 추천한다면 양질의 서비스를 제공해야한다는 관점에서 성공적이라고 할 수 없을 것이다.

ML 모델이 어떤 형태의 결과를 만들어냈으면 하는가?

아래 테이블을 기반으로, 어떤 형태의 결과를 출력하는 것이 가장 적절할지에 대해 생각해보라.

주의 : 특정 ML 문제는 어떤 타입에서는 실패하지만, 어떤 타입에서는 성공적일 수 있습니다.

좋은 출력의 특징

모델이 만들어낸 출력은 명확한 정의가 가능한 정량적 결과여야 합니다.

이용자에게 직접 물어보지 않는 한, 이용자가 정말로 해당 영상을 즐겼는지에 대해 알 방도가 없다. 만약 이를 판단하려면, 별도의 **프록시 레이블**이 필요할 것이다. 프록시 레이블은 실제를 대신할 대체 레이블을 의미하는데, 이용자의 공유 여부는 좋은 프록시 레이블이 된다. 물론, 공유는 이용자가 영상을 재밌게 보았는지에 대한 완벽한 측정치가 될 수 없다. 그러나, 공유는 정량적이고, 추적 가능하고, 수많은 예측 시그널을 제공한다는 점에서 더 적절하다.

출력은 앞서 정한 이상적인 결과와 관련이 있어야 한다.

모델은 출력을 올바른 방향으로 최적화해 나갈 것이다. 그러므로, 출력은 우리가 신경쓰고자 하는 실질적인 이상적인 목표와 관련이 있어야 한다. 프록시 레이블이 종종 필수적인데, 항상 이상적인 결과를 직접 측정할 수 없기 때문이다. 그러나, 레이블과 실제 결과 간의 연관성이 강할수록, 제대로 된 것을 최적화시켜 나가고 있다는 자신을 갖기도 용이하다.

연습 데이터로 사용할 예시 데이터들을 얻을 수 있는가?

어떻게, 어디서 데이터들을 가져올 것인가?

지도 학습은 레이블 처리된 데이터에 의존한다. 만약 연습에 사용할 데이터를 얻는 것이 어려운 상황이라면, 앞선 단계를 다시 밟으면서 문제와 목표를 재정의하는 것이 필요할 것이다. 앞서 시청 시간을 퍼센트 단위로 변환한 것처럼, 출력 예시는 엔지니어링 되어야 할 수도 있다.

출력 활용

모델은 다음의 두 부분에서 예측을 수행할 수 있다.

• 실제 사례, 이용자 활동에 따른 반응 (online)
• 배치 또는 캐시로써 사용

서비스에서 어떻게 예측을 활용할 것인가? 명심하라, ML은 단순히 예측을 하는 것이 아니라, 그것에 기반해 결정을 수행해야 한다. 어떻게 모델의 예측 결과를 의사 결정으로 바꿀 수 있을까?

아래 예시처럼, 이용자의 클릭율을 예측하여 이를 통해 이용자에게 알림을 전달할 수도 있다.

click_probability = call_model(user)
if click_probability > 0.05:
    send_notification(user)

다음으로, 아키텍처의 어디에 이러한 의사 결정 코드들이 위치할 지에 대해 판단하라. 아래의 질문들이 중요한 도움이 될 것이다.

• 모델을 호출할 때 어떤 데이터들이 필요한가?
• 대기시간(latency) 요구사항이 있는가? UX를 위해 빠르게 실행해야 하는가, 아니면 이용자가 기다리지 않아도 되는 경우인가?

위의 질문들은 모델의 실제 feature를 구성하는 데에도 영향을 준다. 모델을 호출할 때 사용할 수 있는 데이터들에 대해서만 feature를 결정하고 훈련시킬 수 있기 떄문이다. 요구 대기시간 역시 feature 구성에 영향을 줄 수 있는데, 이를테면 카메라 앱에서 현재 날씨 데이터를 feature로 사용하고자 하는 경우, 해당 데이터를 다른 api 등을 통해 가져오는 데 비용이 너무 크게 소모되기 때문이다.

마지막으로, 너무 오래된 데이터를 사용하지 않도록 해야한다. 훈련 데이터가 며칠이 지난 경우가 있을 수 있다. 실시간 트래픽에서 동작하는 경우, 최신 데이터에 대해 당장에 접근할 수 없는 경우가 발생할 수도 있다.

좋지 않은 목표

적절하게 설정되기만 한다면, ML 시스템은 목표를 추구하기에 정말 유용하다. 반대로, 적절하지 않은 목표에 기반을 둔다면, ML 시스템은 의도치 않은 결과를 생산해낼 것이다. 그러므로, 어떤 문제를 해결하기 위하여 해당 시스템의 목표에 대해서 주의깊게 고려할 필요가 있다.

유튜브에서 어떤 이용자가 다음에 볼 영상을 예측하는 모델의 경우를 생각해보자. 아래는 모두 적절하지 않은 목표에 대한 예시이다.

클릭율을 최대한 높이기

• 이용자가 어떤 것을 클릭할 순 있어도 그렇게 오래 머물러있지 않는 경우가 발생할 수 있다.
• 이는 낚시 기사 내지는 어그로성 게시물들에 최적화될 것이며, 그렇기 때문에 다른 목표가 필요하다.

시청 시간 최대한 늘리기

• 이용자가 오래동안 시청을 하더라도, 금방 세션에서 벗어날 수 있다.
• 예를 들어, 마인크래프트의 0.1% 시청자만이 3시간 동안 영상을 보고, 8%는 5분 동안 영상을 본다. 그 외의 나머지는 시청을 완전히 중단한다. 시스템은 시청 시간을 최대화할 것이므로, 다음 시청 목록은 긴 마인크래프트 비디오로만 구성될 것이다.
• 단순히 영상을 오래 보는 것 보다, 여러 짧은 동영상들을 많이 보게끔 하는 것이 더 중요하며, 전반적인 세션을 길게 유지하는 것 역시 중요하다.

세션 시청 시간을 최대한 늘리기

• 앞선 예시처럼, 여전히 긴 영상을 선호하게 되는데, 이는 여전히 문제가 된다.
• 이 경우, 특정 관심사에 대해서만 편향되기 매우 쉽다.
• 예를 들어, 한 이용자가 르브론 제임스의 덩크 영상을 봤따면, 시스템은 해당 이용자에게 르브론 제임스의 모든 덩크 영상을 보여줄 것이다.
• 영상 추천 시스템은 이를 정말 잘 수행하겠지만, 이용자 경험은 그다지 좋지 않을 것이다.
• 이 경우 많은 이들이 유튜브를 단순히 특정 영상만 가득한 곳으로 판단할 것이며, 다양성이 사라지게 된다.

다양성 증가 & 세션 시청 시간을 최대한 늘리기

• 해당 목표에서는 어떤 문제가 발생할까?
• 여기서는 굿하트의 법칙을 떠올리자. "측정이 곧 목표가 된다면, 올바른 측정은 불가능하다."

휴리스틱

어떻게 하면 ML 없이도 문제를 해결할 수 있을까?

어떤 서비스를 당장 내일 제공해야 한다고 가정하자. 그렇다면 ML 보다는 당장에 비즈니스 로직을 하드코딩할 시간 정도밖에 없을 것이다. 이 때는 아래 예시처럼 ML 없이 휴리스틱을 시도하고자 할 수 있다.

이러한 예시는 세상에서 제일 완벽한 휴리스틱은 아니겠지만, 토대를 마련하기에는 충분할 것이다. 굳이 팬시한 ML 모델에 집착할 필요 없습니다. 굳이 휴리스틱을 이기지 못하는 ML 모델을 서비스로 제공할 필요가 없습니다. 휴리스틱을 만드는 연습은 ML 모델에서 좋은 신호를 판단하는 데에 도움이 됩니다.

ML이 아닌 해답은 대부분 ML을 통한 해답보다 유지보수가 더 쉽습니다.