머신러닝 라이프 사이클

문제 정의의 중요성

문제 정의란, 특정 현상을 파악하고 그 현상에 있는 문제(Problem)을 정의하는 과정을 말한다. 문제를 잘 풀기(Solve) 위해선 문제 정의(Problem Definition)이 매우 중요함

풀려고 하는 문제가 명확하지 않으면 그 이후 무엇을 해야할지 결정하기 어려워짐

프로젝트 Flow

• 문제를 해결하기 위한 flow는 다음과 같다.
  • 현상파악
  • 목적, 문제 정의 → 계속 생각하기, 쪼개서 생각하기
  • 프로젝트 설계
  • Action
  • 추가 원인 분석

현상 파악

어떤 현상이 발견되었는가?

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

구체적인 문제 정의

다음의 예시를 보자.

레스토랑의 매출이 3달 연속으로 감소되고 있으며, 전체적인 손님 수가 줄어들고 있다.

전체적인 손님의 수가 줄어든다는 것은 방문하는 손님도 줄어들 뿐만 아니라 기존 손님도 줄어든다는 것을 의미한다.

기존 손님에게 피드백을 받을 필요가 있고 처음 방문하는 손님의 경우 어떤 어려움이 있는지 조사해볼 필요가 있다.

손님의 피드백에 “메뉴가 너무 다양하고 설명이 부족해서 메뉴를 선정하기 어렵다.”라는 문제가 있다고 가정하자.

• 문제상황 : “메뉴가 너무 다양하고 설명이 부족해 선정하기 어렵다”

이를 해결하기 위해 메뉴를 줄이거나 설명을 늘리는 방법을 제시할 수 있다.

• 이때, 메뉴를 줄인다는 방법은 해당 메뉴를 즐기던 손님을 잃어버릴 수 있는 방법이므로 고민해본다.
• 설명을 늘리는 방법은 지금 당장 사용할 수 있는 방법이고 어떤 상황에 이 음식을 먹으면 좋은지 가이드를 줄 수 있다.

당장 진행할 수 있는 설명을 늘리는 방식을 사용하고, 병렬로 손님의 취향에 기반한 음식을 추천할 수 있지 않을까?

• 설명을 늘리는 방식(룰 베이스) → 당장의 문제 해결
• 추천(알고리즘 개발) → 문제 해결의 또 다른 방법

즉, 문제 정의는 결국 현상을 계속 쪼개고, 그 문제를 기반으로 어떤 어려움을 겪고 있는지 파악하는 것을 말한다.

데이터로 할 수 있는 일을 만들어서 진행하되, 무조건 알고리즘적 접근이 최상은 아니라는 방법을 제시할 수도 있어야 함 (간단한 방법부터 점진적 접근!)

왜냐하면, 우리는 시간적 제약을 받기 때문이다.

여기서 인지하면 좋은 내용

• 문제를 쪼개서 파악해보자
• 문제의 해결 방식은 다양하다
• 해결 방식 중에서 데이터로 해결할 수 있는 방법을 고민해보기
• 점진적으로 실행하기(룰베이스로 시작해서 병렬로 모델링 + 룰베이스가 기준점이 될 수 있음)

프로젝트 설계

“문제 정의 후, 프로젝트의 설계를 최대한 구체적으로 하는 것이 좋다!!”

문제 정의에 기반해서 프로젝트 설계

• 해결하려는 문제 구체화
• 머신러닝 문제 타당성 확인
• 목표 설정, 지표 결정
• 제약조건(Constraint & Risk)
• 베이스라인, 프로토타입
• 평가(Evaluation) 방법 설계

프로젝트 설계 - 머신러닝 문제 타당성 평가

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

머신러닝 문제는 결국 데이터로부터 어떤 함수를 학습하는 것이다.

복잡도를 평가하는 방법은 필요한 데이터의 종류와 기존 모델이 있는지 확인한다.

머신러닝이 모든 문제를 해결할 수 있는 도구가 아니고 머신러닝 솔루션이 최적이 아닐 수 있다.

머신러닝이 사용되면 좋은 경우:

• 학습할 수 있는 패턴이 있는가?
  • 생성되는 방식에 패턴이 없다면 학습할 수가 없음
• 학습을 위한 목적함수(loss)를 만들 수 있어야 함
  • 머신러닝 알고리즘은 유용한 패턴을 학습하거나 노이즈를 패턴으로 학습하는 경우도 존재
  • 지도학습은 정답 레이블과 예측 결과의 차이로 정의할 수 있음
• 패턴이 복잡해야 함
  • 주소 검색 문제 → 우편번호에 기반하여 정렬되어 있으므로 필요하지 않음
  • 집 가격 예측 → 동네의 평균 가격, 공원 유무 등 복잡한 패턴이 필요할 수 있다.
• 데이터가 존재하거나 수집할 수 있어야 함
  • 데이터가 없다면 룰베이스 알고리즘을 만든 후, 데이터 수집 계획부터 수립
• 사람이 반복적으로 실행하는 경우
  • 작업이 반복된다 = 패턴
  • 사람의 노동력을 줄일 수 있는 관점

머신러닝이 사용되면 좋지 않은 경우

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

프로젝트 설계 - 목표 설정, 지표 설정

프로젝트 목표

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

예를들면, 랭킹 시스템에서 고객의 참여(Engage)를 최대화하고 싶은 Goal이 있는 경우

• Objectives
  • NSFW(Not Safe For Work) 컨텐츠 필터링을 통해 사용자에게 불쾌감을 줄임
  • 참여에 따른 게실물 랭킹 선정 : 사용자가 클릭할 가능성이 있는 게시물 추천
• 그러나 참여를 위해 최적화를 하면 윤리적인 의문이 존재할 수 있음
  • 극단적으로 클릭을 유도할 자극적인 컨텐츠를 노출할 수 있음(Netflix 소셜 딜레마)

새로운 Goal : 극단적인 견해와 잘못된 정보의 확산을 최소화하며 사용자의 참여를 극대화하는 목표

• 새로운 Objectives
  • NSFW 컨텐츠 필터링
  • 잘못된 정보 필터링
  • 품질에 따른 게시물 랭킹 선정 : 좋은 품질의 게시물
  • 참여에 따른 게시물 랭킹 선정 : 사용자가 클릭할 가능성이 있는 게시물

목표를 설정하며 데이터를 확인해야 함(지표와 연결되는 내용이기 때문)

• 데이터셋이 레이블링 되지 않은 경우도 존재
• 데이터 소스 찾아보기

정확히 찾으려는 데이터가 없는 경우가 있어서 여러가지 시나리오를 고려하는 것이 좋음

• Label을 가진 데이터 : 바로 사용
• 유사 Label을 가진 데이터 : 음악 스트리밍 서비스에서 노래 재생, 건너뛰기 기록은 선호도를 예측하기 위한 유사 레이블
• Label이 없는 데이터 : 직접 레이블링 or 레이블링이 없는 상태에서 학습하는 방법 찾기
• 데이터가 없는 경우 : 데이터 수집 방법을 고민
  • 데이터셋을 만드는 일은 반복적인 작업 : 이를 위해 Self Supervised Learning 등을 사용해서 유사 레이블을 만드는 방법도 존재

Multiple Objective Optimization

• 최적화하고 싶은 목적함수가 여러가지 있는 경우, 서로 충돌할 수 있음
• 품질에 따른 게시물 랭킹 선정 vs. 참여에 따른 게시물 랭킹 선정
  • 예를들면, 게시물이 매우 매력적이지만 품질이 의심스러운 경우 어떻게?
• 품질에 따른 게시물 : 게시물 품질 예측(게시물 예상 품질 - 실제 품질 : quality_loss)
• 참여에 따른 게시물 : 게시물 클릭수(게시물 예상 클릭수 - 실제 클릭수 : engagement_loss)
• 방법 1
  • 단일 모델, 두 loss를 하나의 loss로 결합하고 해당 loss를 최소화
  • loss = $\alpha$ quality_loss + $\beta$ engagement_loss
  • 알파와 베타를 필요에 따라 조정해야 함
• 방법 2
  • 2개의 모델(각각의 loss를 최소화) → quality_model, engage_model
  • Rank : $\alpha$ quality_model(post) + $\beta$ engage_model(post)
  • 모델을 재학습하지 않아도 조정할 수 있음

Objectives가 여러개인 경우 분리하는 것이 좋음

• 학습하기 쉬워야 함 : 하나의 objectives를 최적화하는 것이 여러 objectives를 최적화하는 것보다 쉬움
• 모델을 재학습하지 않도록 모델을 분리 : objectives는 수정해야 하는 유지보수 일정이 모두 다를 수 있음
  • 예를들어, 스팸 필터링은 품질 순위 시스템보다 더 빠르게 업데이트해야 함

프로젝트 설계 - 제약 조건

• 일정 : 프로젝트에 사용할 수 있는 시간
• 예산 : 사용할 수 있는 최대 예산?
• 관련된 사람 : 이 프로젝트로 인해 영향을 받는 사람은?
  • 수동으로 하던 사람들에게 어떤것이 자동화되는 것이 좋은가요?라고 물어볼 수 있음

Privacy : Storage, 외부 솔루션, 클라우드 서비스 등에 대한 개인정보 보호 요구

• 기술적 제약 : 레거시 환경(인프라)가 머신러닝을 적용할 때 큰 제약일 수 있다.
• 윤리적 이슈 : 윤리적으로 어긋난 결과

성능

• Baseline : 새로 만든 모델을 무엇과 비교할 것인가? 기존에 사람이 진행하던 성능 or 간단한 회귀?
• Threshold : 확률값이 0.5 이상일 경우 강아지라고 할 것인지, 0.7 이상일 경우 강아지라고 할 것인지?
• Performance Trade-off : 속도가 빠른데 Acc 0.95 vs. 속도는 느린데 Acc 0.93
• 해석 가능 여부 : 결과가 왜 발생했는지 해석이 필요할까? 해석이 필요한 사람은?
  • 해석이 필요한 대상 : 머신러닝을 아는 사람 vs. 머신러닝을 모르는 사람
• Confidence Measurement : False Negative가 있어도 괜찮은지? 오탐이 있으면 안되는지?

프로젝트 설계 - 베이스라인, 프로토타입

모델이 더 좋아졌다고 판단할 수 있는 Baseline이 필요하다.

간단한 모델부터 시작하는 이유?

• 어떻게든 모델의 위험을 낮추는 것이 목표가 되어야 함
• 가장 좋은 방법은 최악의 성능을 알기 위해 허수아비 모델로 시작하는 것
• 초기엔 단순하게 사용자가 이전에 선택한 행동을 제안할 수도 있고, 추천 시스템에선 제일 많이 구매한 것을 추천할 수도 있음
• 유사한 문제를 해결하고 있는 SOTA 논문 파악해보기 → 우리의 문제에선 어떤 시도를 해볼 수 있는가?

베이스라인 이후에 간단한 모델을 만들고 피드백을 들어보면 도움됨(동료에게 모델을 활용할 수 있는 환경을 준비하자) → 프로토타입을 만들어서 제공

• Input을 입력하면 Output을 반환하는 웹페이지
• 여기선 모델의 동장이 중요 → 프론트엔드 버리고 모델에 집중
• Volia, Streamlit, Gradio 등을 활용

Metric Evaluation

앞에서 Objectives를 구해서 모델의 성능 지표는 확인했다. 그러나 모델의 성능 지표와 별개로 비즈니스 목표에 영향을 파악하는 것도 중요하다.

앞선 문제를 해결할 경우 어떤 지표가 좋아질까?를 고민해야 한다.

이 부분은 작게는 모델의 성능지표(RMSE)일 수도 있고, 크게는 비즈니스 지표일 수 있다.(고객의 재방문율, 매출 등)

지표를 잘 정의해야 우리의 Action이 기존보다 더 성과를 냈는지 아닌지를 파악할 수있다.(이를 위해 A/B Test를 진행하기도 한다.)

만든 모델이 비즈니스에 어떤 임팩트를 미쳤을지 고려하자

개발 및 배포중에 시스템의 성능은 어떻게 판단할 수 있을까?

• 정답 레이블이 필요한 경우 사용자 반응에서 어떻게 레이블을 추론할 수 있을까?
• 모델 성능 비즈니스 Goal과 Objectives를 어떻게 연결할 수 있을까?

위의 질문들을 고려하자.

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

앞서 정의한 지표가 어떻게 변하는지 파악한다.

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

추가 원인 분석

새롭게 발견한 상황을 파악해 어떤 방식으로 문제를 해결할지 모색한다.

그 과정에서 앞서 진행한 과정을 반복한다.

비즈니스 모델

회사는 비즈니스 모델을 만들고, 비즈니스 모델을 통해 매출이 발생한다.

해당 비즈니스 모델에서 어떤 데이터가 존재하고 그 데이터를 기반으로 어떤 것을 만들 수 있을지 생각하자.

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