Full Stack Deep Learning — Setting up Machine Learning Projects

이 글은 Full Stack Deep Learning의 첫번째 코스인 Setting up Machine Learning Projects를 보고 내용을 정리한 글입니다. 내용의 사진은 모두 발표 슬라이드를 가져왔습니다. 잘못 이해했거나, 의역이나 오타가 있을 수 있습니다. 제보해주시면 감사하겠습니다 🙏

Overview

2019년 한 보고서에 따르면, ML 프로젝트의 85%가 비즈니스에 활용되지 못하고 실패했다. 왜 그럴까?

  • ML은 아직 연구중인 분야이다. 그래서 100%의 성공률을 목표로하는건 굉장히 어려운 일이다.
  • 많은 ML프로젝트가 기술적으로 실현 불가능하거나 범위가 잘못 지정되었다.
  • 많은 ML프로젝트가 프로덕션으로 도약하지 않는다.
  • 많은 ML프로젝트가 불분명한 성공기준을 갖고있다.
  • 많은 ML프로젝트가 제대로 관리되지 않는다.

Lifecycle

ML 프로젝트의 생명주기는 무엇인가? 크게 4단계로 나뉜다.

Image for post
Image for post
  1. Project Planning and Project Setup: 해결할 문제를 결정하고 목표와 요구사항을 판단한다. 또한 어떻게 적절한 리소스를 모을지 판단한다.
  2. Data Collection and Data Labeling: 학습 데이터를 모으고 데이터의 출처에 따른 ground-truth하게 annotate한다.
  3. Model Training and Model Debugging: 빠르게 Baseline Model을 만들고, SOTA 방법들을 찾고 Problem Domain에 맞춰 reproduce한다. 만든 것들을 debug하면서 특정 task 성능을 향상시킨다.
  4. Model Deployment and Model Testing: 제한된 환경에서 모델을 pilot하고, 회귀 방지를 위한 테스트를 작성하고, 모델을 프로덕션으로 롤링한다.

만약 연구가 목적이라면 4단계의 배포와 pilot은 필요하지 않을 수 있다. 이 4가지 단계는 Linear하지 않으며, 중간에 다시 되돌아갈 수 있다. 예를 들면 모델 학습 중 데이터가 부족하거나 데이터 라벨링이 잘못됬다는 것을 깨달았다면 다디 2단계로 되돌아가야한다.

또 이 Task가 너무 어려운 것이라는걸 깨달을 수도 있다. 그럴때는 다시 1단계로 돌아가서 요구사항을 수정하거나 중요한 것이 뭔지를 다시 고려해봐야한다.

Test는 실제 배포단계에서 발생할 문제를 최소화하기 위해 꼼꼼한 테스트를 작성해야한다. Deploy후에 Data Distribution이 실제와는 다른 Data Mismatch 등의 문제를 발견한다면 더 많은 데이터를 수집하거나 hard case를 찾아서 모델을 개선해야한다.

모델을 학습할 때 사용한 metric이 실제 user behavior과는 안맞아서 metric을 재설정해야 할 수도 있고, 실제 성능이 만족스럽지 않아서 모델의 요구사항을 재설정해야 할 수도 있다. — 모델이 더 빨라야 하거나, 더 정확해야 할 때 등

추가로 알아야 할 것

  • domain의 SOTA를 이해한다
  • 무엇이 가능한지 이해한다
  • 다음에 뭘 할지 알고있다

우선순위 정하기(Prioritizing)

어떤 ML 프로젝트를 하기로 결정해야할까?

Image for post
Image for post

프로젝트 우선순위를 정하기 위한 키 포인트

  • 비즈니스 프로세스의 복잡한 부분에서 cheap prediction으로 큰 효과를 내는 가치있는 프로젝트
  • 데이터 가용성, 정확도 요구사항, 문제 난이도를 바탕으로 높은 타당성을 가진 프로젝트

아래는 어려운 ML 문제들의 3가지 종류

  • output이 복잡하다
  • 신뢰성이 요구된다
  • 일반화가 기대된다

Cheap Prediction

  • Prediction will be everywhere — 여러 곳에서 사용될 수 있다는 의미인듯…?
  • ML 도입 이전까지 비용이 많이 들었던 문제를 해결

Software 2.0(Andrej Karpathy)

Software 1.0은 instruction으로 짜여진 전통적 프로그램들, 2.0은 사람이 목표를 제시하면 알고리즘이 동작하는 프로그램을 검색함. Software 2.0에서 프로그래머는 최적화를 통해 컴파일된 데이터셋으로 작업한다.

ML 프로젝트의 타당성 평가

Image for post
Image for post
아래에 있을수록 중요함
Image for post
Image for post
요구되는 accuracy가 높을수록 cost가 기하급수적으로 증가

과거에는 어려운 작업이라고 여겨지는 일들이 지금은 가능해졌다. 예를 들면 알파고가 이세돌을 이겼던 일이나, 음성인식, 번역같은 일들이다. 하지만 아직도 어려운 작업들이 남아있다.

Image for post
Image for post
Andrew Ng은 사람이 1초 안에 할 수 있는 것들이 이제는 AI가 자동화할수 있다고 말했다.

어려운 작업은 주로

  • Unsupervised Learning
  • Reinforcement Learning
  • 엄청난 data와 computing이 요구되는 제한된 분야

Supervised Learning에서 아직도 어려운 분야는

  • Question Answering
  • Summarizing Text
  • Predicting Video(10초의 동영상을 보여주고 다음 장면 맞추기)
  • Building 3D MOdel
  • Real-word speech recognition
  • 적대적 예제에 저항하기
  • Doing math
  • Solving word puzzles
  • Bongard problems 등등

아키타입

ML프로젝트의 아키타입은 크게 세가지가 있다.

  1. 존재하는 프로세스를 개선하기(Improve an existing process)
  2. 수동 프로세스 보강(Augment a manual process)
  3. 수동 프로세스 자동화(Automate a manual process)

아키타입별 중요한 질문

존재하는 프로세스를 개선하기

  • 정말 성능이 개선되는가?
  • 개선된 성능은 비즈니스 가치를 갖는가?
  • 성능향상이 data flywheel로 이끄는가?

data flywheel은 아래 그림처럼 more data -> better model -> more users의 선순환이 반복되는 구조를 의미

Image for post
Image for post

수동 프로세스 보강

  • 시스템이 얼마나 유용해야 하는가?
  • 괜찮은 모델을 만들 정도의 충분한 데이터를 모을 수 있는가?

수동 프로세스 자동화

  • 시스템의 실패율이 감당할만 한가?
  • 특정 실패율을 넘기지 않는걸 보장할 수 있나?
Image for post
Image for post

타당성과 영향도는 trade-off 이다

정확도에 대한 요구를 줄일 수 있는 제품 디자인

Image for post
Image for post

페이스북은 얼굴에 사람을 자동으로 태깅하지만 유저에게 한번 확인을 거친다. Grammarly 역시 자동으로 문법 오류를 고치지 않고 유저에게 확인을 거친다. 넷플릭스나 아마존의 추천시스템 역시 왜 이 제품이 추천됬는지 알려주고 유저에게 피드백을 받는다. (단순 “다른 추천제품”이 아닌, “이 제품을 산 고객이 산 다른 제품” 과 같이 표시)

Metrics

기계 학습 프로젝트를 최적화하기 위한 metric은 어떻게 선택하는가?

  1. 현실 세계는 복잡하다. 다양한 metrics를 신경써야한다.
  2. 하지만 ML System은 하나의 숫자에 최적화해야 잘 동작한다.
  3. 그 결과, 당신은 여러 metrics를 조합해서 써야한다.
  4. 이 공식은 바뀔 수 있고, 바뀔 것이다.

Review of accuracy, precision, recall

  • accuracy = correct / total
  • precision = true positives / (true positives +false positives)
  • recall = true positives / actual Yes

아래처럼 (precision + recall) / 2를 metric으로 사용할 수도 있고, recall이 0.6 이상인 값 중 precision이 높은 것을 metric으로 지정할 수 있다.

Image for post
Image for post

어떤 metric을 임계값으로 정할까

  • domain에 따라 어떤 metric을 얻을 수 있나?
  • 어떤 metric이 모델 선택에 가장 덜 민감한가
  • 어떤 metric이 목표로 하는 가치에 가장 가까운가?

임계값을 어떻게 정할까

  • domain에 따라 어느정도 성능을 이뤄낼 수 있고, 얼마나 감내할 수 있나?
  • 베이스라인 모델은 얼마나 잘 해내나?
  • 이 metric이 지금 얼마나 중요한가?

Domain에 따라 복잡한 식을 써야할 수 있다. 예를 들어 pose estimation의 경우, 모든 angle의 오차의 합이 60도 이하여야 하거나, 위치의 오차가 1cm를 넘어서는 안되는 등의 규칙을 지정할 수 있다.

Baselines

Baseline은 준비하기 간단하고 적절한 결과를 제공할 합리적인 기회를 갖고있는 모델이다. Baseline 모델이 잘 동작하는지 안하는지를 판단할만한 좋은 베이스라인은 어떻게 고를 수 있을까?

  • Baselines는 모델 성능의 최저기준을 알려준다.
  • 최저기준이 빠듯할수록 유용해진다(논문에서 나온 결과, 신경써서 조율된 파이프라인이나 사람의 baselines가 더 좋다).
Image for post
Image for post

예시를 보자, 파란색 baseline이 사람의 능력이라고 봤을 때, baseline이 어디냐에 따라 내 모델을 향상시키기 위해 해야하는 일이 달라진다. baseline은 크게 둘로 나뉜다

External Baselines

  • 비즈니스/엔지니어링 요구사항들
  • 출판된 결과물들(논문 등) — 비교환경이 동등한걸 반드시 확인해야함.

Internal Baselines

  • Scripted baselines(OpenCV나 Rule-based로 만들어진 것)
  • 간단한 ML baselines(BoW, Linear Regression)
  • Human Performance
Image for post
Image for post

Human-performance Baseline을 어렵게 할수록 데이터를 모으는 난이도가 어려워진다. 예를 들어 무작위 사람들을 대상으로 모은 데이터보다는 전문가들로부터 모은 데이터가 훨씬 질이 높겠지만 수집 난이도는 훨씬 높을 것이다.

고품질 데이터는 더 많은 데이터를 라벨링하기 편리하다. 특화된 분야일수록 기술력있는 라벨러를 요구한다. 모델이 더 나쁘게 수행되는 사례를 찾고 거기에 데이터 수집을 집중해야한다. 자세한건 이후 data 섹션에서

정리하니 양이 어마어마하다… 아직 코스 5개 남았다 ㅠㅠ

Written by

2020.12.8 ~ 2022.6.9 군복무중 Serving in the South Korean Military Service

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store