[AITech][Product Serving] 20220214 - 머신러닝 프로젝트 라이프 사이클

학습 내용

머신러닝 프로젝트 Flow

문제 정의의 중요성

문제를 잘 풀기 위해서는 문제를 잘 정의하는 것이 중요하며, 이 때의 문제 정의란 ‘왜 이 문제를 풀어야 하는지, 이 문제를 풀면 어디어 어떻게 도움이 되는지’와 같은 Why에 집중하는 것을 말합니다.

프로젝트 Flow

프로젝트 Flow는 현상 파악 -> 구체적인 문제 정의 -> 프로젝트 설계 -> Action -> 추가 원인 분석으로 이어집니다.

현상 파악

어떤 현상이 발생하였는지 현재 상황을 파악합니다.

• 어떤 일이 발생하고 있는가?
• 해당 일에서 어려움은 무엇인가?
• 해당 일에서 해결하면 좋은 것은 무엇인가?
• 추가적으로 무엇을 해볼 수 있을까?
• 어떤 가설을 만들어 볼 수 있을까?
• 어떤 데이터가 있을까?

구체적인 문제 정의

그리고 앞선 현상을 조금 더 구체적이고 명확한 용어로써 정리해봅니다.

이 과정에서 현상 속의 어떤 부분 때문에 지금 현상이 발생하는 것인지(원인) 파악하고 구체화합니다.

문제를 일으키는 원인을 구체화하고 나면, 문제를 어떻게 해결할 수 있을 지 How에 집중하여 해결 방안들을 만듭니다. 이 때 주의할 것은, 무조건 머신러닝을 사용한 방법이 최상의 솔루션을 아닐 수 있다는 것입니다. 즉, Rule-based 방법과 같이 간단한 방법부터 점진적으로 접근하는 것이 좋고, 머신러닝 알고리즘적 방법을 사용하려면 적절한 패턴과 데이터가 있어야 함을 명심해야 합니다.

문제 정의는 결국 현상을 계속 쪼개서 각각을 어떻게 해결할 수 있을지 생각하는 것입니다.

프로젝트 설계

이 강의를 진행하신 마스터 분은 실제로 아래와 같은 프로젝트 설계 과정을 거치셨다고 합니다.

• 문제 정의
• 최적화할 Metric 선택
• 데이터 수집, 레이블 확인
• 모델 개발
• 모델 에측 결과를 바탕으로 Error Analysis. 잘못된 예측이 왜 생기는지 분석
• 다시 모델 학습.
• 성능이 나오지 않아 더 많은 데이터 수집
• 다시 모델 학습
• 2달 전 테스트 데이터에서는 성능이 좋았지만 오늘 데이터에는 성능이 좋지 않음
• 모델을 다시 학습
• 모델 배포
• 최적화할 Metric이 실제로 잘 동작하지 않아 Metric을 수정
• 다시 시작…

이와 같이, 실제로 배포할 AI 모델을 설계하는 일에는 많은 일들이 포함되어 있고, 당연히 생각대로 흘러가지 않습니다. 그래서 여기서 강조하는 것은, 문제 정의 후 프로젝트의 설계를 최대한 구체적으로 하는 것이 좋다는 것입니다.

여기서 프로젝트의 설계를 구체적으로 한다는 것은 실제 설계 과정에서 들어가기 전에 대비할 수 있는 것들은 다 대비하고 시작하자는 것입니다. 그리고 다음과 같은 예시들이 있습니다.

머신러닝 문제 타당성 확인

머신러닝 문제를 고려할 때는 얼마나 흥미로운지가 아니라, 제품/회사의 비즈니스에서 어떤 가치를 가져다 줄 수 있는지를 고려해야 합니다.

머신러닝을 이용해 문제를 풀면 좋은 경우는 다음과 같습니다.

• 패턴: 학습할 수 있는 패턴이 있는가?
  • ex) 로또 번호와 같이 생성되는 방식에 패턴이 없다면 학습할 수 없다
• 목적 함수: 학습을 위한 목적 함수를 만들 수 있는가?
• 복잡성: 패턴이 충분히 복잡한가?
  • 패턴이 복잡하지 않을 경우 머신러닝 방법을 사용할 필요가 없다
  • 비슷한 task를 머신러닝을 이용해 해결한 선례가 있는가?
    • 있다면, 머신러닝 문제로서 타당하다
    • 없다면, 이 문제는 혁신적인 문제이거나 머신러닝을 이용하기 적합하지 않은 문제이다
• 데이터 존재 여부: 적절한 데이터가 존재하거나, 수집/제작할 수 있는가?
  • 적절한 데이터가 없다면, 학습할 데이터를 어떻게 만들지부터 결정해야 함
• 반복: 반복적인 task인가?
  • 어떤 task가 반복적이라는 것은 패턴이 있다는 것이다

반면 머신러닝을 사용하면 좋지 않은 경우들도 있습니다.

• 비윤리적인 문제
• 간단히 해결할 수 있는 경우
• 좋은 데이터를 얻기 어려운 경우
• 한 번의 에측 오류가 치명적인 결과를 발생시킬 경우
• 시스템이 내리는 모든 결정이 설명 가능해야 할 경우
• 비용 효율적이지 않은 경우

목표 설정, 지표 결정

프로젝트의 목표에는 Goal과 Objectives가 있습니다.

• Goal: 프로젝트의 일반적인 목적, 큰 목적
• Objectives: 목적을 달성하기 위한 세부 단계의 목표

Goal과 Objective도 마찬가지로 프로젝트 설계 과정에서 계속해서 구체화됩니다.

지표의 경우, 모델의 성능을 평가할 핑가 지표가 필요합니다. 보통 objective마다 하나의 loss function을 정의하며, 그 loss function들을 결합하여 전체 모델의 cost function을 정의합니다. Cost function을 정의하는 방법으로 다음의 2가지 방법이 주로 사용됩니다.

• 방법 1

  • 단일 모델 사용
  • 두 loss를 하나의 loss로 결합하고, 해당 loss를 최소화하기 위해 모델을 학습

  

• 방법 2

  • 2개 이상의 모델 사용
  • 각각의 모델을 상정하고, 각각의 loss를 최소화

  

  • 여러 개의 모델을 사용할 경우, 전체 모델을 재학습하지 않아도 조정할 수 있음

정리하면, Objective가 여러 개인 경우 분리하는 것이 좋고, 전체 모델을 재학습하지 않도록 모델을 분리하는 것이 좋습니다. Objective는 수정해야 하는 유지보수 일정이 모두 다를 수 있기 때문에, 각각을 나누는 것이 이런 점에서도 좋습니다.

제약 조건

프로젝트 설계 과정에서의 제약 조건에는 다음의 사항들이 있습니다.

• 일정: 프로젝트에 사용할 수 있는 시간
• 예산: 사용할 수 있는 최대 예산
• 관련된 사람: 이 프로젝트로 인해 영향을 받는 사람
• Privacy: Storage, 외부 솔루션, 클라우드 서비스 등에 대한 개인정보 보호 요구
• 기술적 제약: 기술을 적용하는 환경에서의 기술적 제약
• 윤리적 이슈: 윤리적으로 어긋난 결과
• 성능
  • Baseline : 새로 만든 모델을 무엇과 비교할 것인가? 기존에 사람이 진행하던 성능 or 간단한 회귀
  • Threshold : 확률값이 0.5 이상일 경우 강아지라고 할 것인지, 0.7 이상일 경우 강아지라고 할 것인지?
  • Performance Trade-off : 속도가 빠른데 Acc 0.93 vs 속도는 조금 더 느린데 Acc 0.95
  • 해석 가능 여부 : 결과가 왜 발생했는지 해석이 필요할까? 해석이 필요한 사람은?
  • Confidence Measurement : False Negative가 있어도 괜찮은지? 오탐이 있으면 안되는지?

베이스라인, 프로토타입

모델이 더 좋아졌다고 판단할 수 있는 베이스 라인이 필요합니다. 설계를 시작할 때는 가장 간단한 모델부터 시작하는데요, 이유는 다음과 같습니다.

• 어떻게든 모델의 위험을 낮추는 것이 목표가 되어야 함
• 가장 좋은 방법은 최악의 성능을 알기 위해 허수아비 모델로 시작하는 것
• 초기에는 아주 단순한 알고리즘으로 동작하는 모델을 사용

유사한 문제를 해결하고 있는 SOTA 논문을 파악하여 우리의 문제에는 어떤 시도를 해볼 수 있을지 고민하는 것도 아주 중요합니다.

베이스라인 이후에 간단한 모델을 만들면 피드백을 들어보는 것이 좋고, 이 때 모델을 사용할 수 있는 환경을 미리 준비해놓아야 합니다. 이를 프로토 타입이라 합니다.

• Input을 입력하면 Output을 반환하는 모델 형태
• 디자인보다는, 모델의 동작에 집중하는 것이 필요

평가 방법 설계

앞서서 Objectives를 구해 모델의 성능 지표는 확인할 수 있었습니다. 여기서 말하는 평가 방법이란, 비즈니스 차원의 목표에 영향을 미치는 정도를 파악하는 용도입니다.

앞선 문제를 해결할 경우 어떤 지표가 좋아질 지 고민하는 것이 중요하며, 지표를 잘 정의해야 우리의 Action이 기존보다 더 성과를 냈는지 아닌지를 파악할 수 있습니다.

평가 방법 설계 과정에서 할 수 있는 고민으로는 다음의 것들이 있습니다.

• 개발 및 배포 중에 시스템의 성능은 어떻게 판단할 수 있을까?
• 정답 레이블이 필요한 경우 사용자 반응에서 어떻게 레이블을 추론할 수 있을까?
• 모델 성능을 비즈니스 Goal과 Objectives를 어떻게 연결할 수 있을까?

Action (모델 개발 후 배포&모니터링)

프로젝트 설계를 마치고 나면, 이를 실제 서비스로 배포하고 지속적으로 모니터링해야 합니다. 이 때 앞서 정의한 지표가 어떻게 변하는지를 파악합니다.

• 현재 만든 모델이 어떤 결과를 내고 있는가?
• 잘못 예측하고 있다면 어떤 부분이 문제일까?
• 어떤 부분을 기반으로 예측하고 있을까?
• Feature의 어떤 값을 사용할 때 특히 잘못 예측하고 있는가?

추가 원인 분석

Action 후에는 새롭게 발견한 상황을 파악해 어떤 방식으로 문제를 해결할 지 모색하고, 그 과정에서 앞서 진행한 과정을 반복합니다.

비즈니스 모델

비즈니스란 회사에서 중요하게 생각하는 것이며, 비즈니스에 대한 이해도가 높을수록 문제 정의를 잘 할 수 있습니다.

• 회사의 비즈니스 파악하기
• 데이터를 활용할 수 있는 부분은 어디인가? (Input)
  • 데이터가 존재한다면 어떤 데이터가 존재하는가?
  • 데이터로 무엇을 할 수 있을까?
  • 해당 데이터는 신뢰할만한가? 데이터 정합성은 맞는가? 레이블이 잘 되어있는가? 계속 받을 수 있는가?
  • 다양한 팀에 있는 분들과 직접 인터뷰하는 것도 좋은 방법
• 모델을 활용한다고 하면 예측의 결과가 어떻게 활용되는가? (Output)
  • 고객에게 바로 노출(추천, 얼굴 필터 등) => 더 좋은 가치 제공 / 매출 증대
  • 내부 인원이 수동으로 진행해야 하는 업무를 자동화할 수 있음

이 과정에서 누군가 산업에 대해 정리해둔 Paper가 있는지 찾아보는 것이 큰 도움이 됩니다. awesome - 분야명(기술명) - github와 같이 입력하면 해당 분야에서 사용하는 기술들에 대해 찾아볼 수 있습니다.

참고 자료

• Uber 비즈니스 모델
• https://github.com/zzsza/Awesome-Mobility-Machine-Learning-Contents