[부스트캠프 AI Tech 5기] 머신러닝 프로젝트 라이프 사이클

머신러닝 프로젝트 Flow

문제 정의

• 여러분이 겪을 모든 일은 Problem
• 문제 정의 : 특정 현상을 파악하고 문제를 정의하는 과정
• 문제를 잘 풀기 위해선, 문제를 명확히 해야 함
• Who, What, Definition 등을 모두 고려하자
• How보다는 Why에 집중

프로젝트 Flow

• 현상 파악 - 목적, 문제 정의 - 프로젝트 설계 - Action

현상 파악

• 어떤 일이 발생하고 있는가?
• 해당 일에서 어려움은 무엇인가?
• 해당 일에서 해결하면 좋을 것은 무엇인가?
• 어떤 가설을 세울까?
• 어떤 데이터를 사용할까

구체적인 문제 정의

• 원인과 해결 방안을 많은 회의를 통해 고민해보기
• 일시적인 해결책보다는, 궁극적인 해결책을 찾아야 함
• 현상을 계속 쪼개고, 그 문제를 기반으로 어떤 어려움을 겪고 있는지를 파악함
• 우리는 시간의 제약이 있기에, 간단한 방법부터 점진적인 접근이 유용
• 처음은 Rule-Base로 만드는 것을 추천

프로젝트 설계

• 문제 정의 - 최적화할 metric 선택 - 데이터 수집, 레이블 확인 - 모델 개발 - 모델 예측 결과를 토대로 Error Analysis (잘못된 라벨이 왜 생기는지 확인) - 다시 모델 학습 - 더 많은 데이터 수집 - 다시 모델 학습 - 두달 전에는 좋았는데, 최근 데이터에는 성능이 좋지 않음 - 에러 분석 - ...
• 데이터가 존재하더라도, 존재하지 않을 수 있음 (레이블이 없으면 직접 만들어줘야 함)
• 모델을 배포해서 끝이 아닌, 에러 분석을 지속적으로 해야함
• 결국 문제 정의를 잘 해야 프로젝트가 매끄러워 짐

머신러닝 문제 타당성 확인

• 흥미로운지 보다는, 제품 및 회사의 비즈니스에서 어떤 가치를 줄 수 있는지를 고려해야 함
• 머신러닝 문제는 데이터로부터 함수를 학습하는 것
• 해결하려는 문제가 과거에 존재하지 않으면 두 가지
  • 진짜로 혁신적임
  • 머신러닝으로 해결할 수 없음 or 머신러닝 솔루션이 최적이 아님
• 머신러닝은 마법의 도구가 아니다
• 머신러닝이 사용되면 좋은 경우
  • 학습할 수 있는 패턴이 있음
    • 주식 가격에서 가격이 완전히 무작위라면, 모델을 만들 수 없음
      다만 데이터를 탐색해서 패턴이 존재하면 진행
  • 학습을 위한 목적 함수를 만들 수 있어야 함
  • 복잡성 : 패턴이 복잡해야 함
    • 주소 검색 문제 - 우편 번호에 기반되어 있어서, 머신러닝이 필요하지 않음
  • 데이터 존재 여부
    • 데이터가 없으면 룰베이스 알고리즘을 만든 후, 데이터 수집 계획부터 수립
  • 사람들이 반복적으로 실행하는 경우
    • 사람은 반복에 능숙함 (패턴이 존재함)
      • 그러면 학습할 가능성이 있음
• 사용되면 좋지 않은 경우
  • 비윤리적인 문제
  • 간단히 해결할 수 있는 경우
  • 한번의 예측 오류가 치명적인 경우
  • 비용이 효율적이지 않은 경우
    - 시스템이 내리는 모든 결정이 설명 가능해야 하는 경우

목표 설정, 지표 설정

• Goal : 프로젝트의 일반적인 목적, 큰 목적
• Objectives : 목적을 달성하기 위한 세부 단계의 목표 (구체적인 목적)
• 참여를 위해 최적화를 하면 윤리적인 의문이 존재할 수 있음
  • 극단적인 클릭을 유도하려면 자극적인 컨텐츠를 노출하면 됨
  • Netflix 소셜 딜레마 시청 권유
• 목표를 설정하며 데이터를 확인해야 함
• 데이터 소스를 찾아보기
  
• 여러가지 Objective가 존재한다면? (ex: 추천 성능과 품질 등)
  
  
• Objective는 수정해야 하는 유지보수 일정이 다를 수 있으니, 분리해두는 것이 좋음

제약 조건

• 일정 : 프로젝트에 사용할 수 있는 시간
• 예산 : 사용할 수 있는 최대 예산
• 관련된 사람 : 프로젝트로 인해 영향을 받는 사람
• Privacy : Storage, 외부 솔루션, 클라우드 서비스 등에 대한 개인정보 보호 요구
• 기술적 제약
• 윤리적 이슈
• 성능
  • Baseline : 새로 만든 모델을 무엇과 비굫라 것인가
  • Threshold
  • Performance Trade-Off : 속도와 accuracy 중 어떤 것을 선택할 것인가
  • 해석 가능 여부 : 결과 발생 해석이 필요한 가?
  • 오탐이 있어도 괜찮은가?

베이스라인, 프로토타입

• 모델이 더 좋아졌다고 판단할 수 있는 baseline 필요
• 꼭 모델일 필요는 없음
• Rule Base 규칙 설계도 가능
• 최악의 성능을 알기 위해 허수아비 모델로 시작
• 추천 시스템 같은 경우에는 인기가 많은 걸 추천하는 Rule Base 등이 유용
• Volia, Streamlit, Gradio 등을 통해 Input Output을 반환하는 간단한 웹 페이지를 만드는 것도 유용

Metric Evaluation

• 작게는 모델의 성능에서, 비즈니스 지표 까지 고려해야 함
• 지표를 잘 정의해야 Action의 성과를 구할 수 있음
• AB테스트를 진행하기도 함
• 만든 모델이 비즈니스에 어떤 영향을 미쳤는지 꼭 생각해보자
• 개발 및 배포 중 시스템의 성능은 어떻게 판단할 수 있을까?
• 사용자 반응에서 어떤 반응을 정답 레이블로 판단할까?

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

• 추가적으로 에러가 생기면, 앞서 진행한 과정을 반복

비즈니스 모델

• 회사에서 중요한 건 비즈니스!
• 실제 회사에서는 비즈니스 모델을 파악해야 함

파악할 3가지

• 회사의 비즈니스 파악
• 데이터를 활용할 수 있는 부분은 무엇인가? (Input)
• 모델을 활용한다면 예측의 결과가 어떻게 활용되는 가? (Output)

팁

• Awesome 산업 machine learning papers 검색
• 기술 블로그 검색
• 한 장으로 끝내는 비즈니스 모델 100 도서 읽어보기
• 취업한다면 다양한 사람들과 직접 인터뷰 해보기
• 부캠에서의 프로젝트도 비즈니스적인 관점으로 정리해보자