머신러닝 시스템 설계 - Chapter 2. 머신러닝 시스템 설계 소개

ML 시스템 설계 시 주요 고려 사항으로 목적, 요구사항, 프로세스, 문제 구조화 등이 있음

• 목적은 시스템이 필요한 이유

  비즈니스용이라면 비즈니스 목적에 맞게 ML 모델의 목적 설정 필요

• 요구사항은 시스템 개발의 이정표

  신뢰성, 확장성, 유지보수성, 적응성 등 다양한 항목을 고려한 요구사항 정의 필요

  또 이를 만족하는 시스템을 설계하기 위한 반복 프로세스가 정의되어야 함

• ML 알고리즘으로 문제를 풀기 위해서는 해당 문제를 ML 문제로 구조화하는 작업 필요

2.1 비즈니스와 머신러닝의 목적

데이터 과학자는 ML 프로젝트를 진행하면서 모델 지표 (MAE, F1-score 등) 를 끌어올리는데 주력

종종 모델의 정확도를 높이기 위해 방대한 자원을 투입하기도 함

하지만 비즈니스 환경에서 이런 ML 지표 자체에는 크게 관심 없음

반면 어떻게 ML 모델을 활용하여 수익을 낼 것인가? 에 집중

따라서 성공적인 ML 프로젝트를 위해서는 ML 시스템의 성과를 비즈니스 성과와 연결해야함

ML 시스템의 성과와 비즈니스 성과를 연결 위해선 새로운 지표 개발이 필요할 수도 있음

모델 성능을 나타내는 (DS에겐 매우 익숙한) 지표는 비즈니스적으로는 아무 쓸모없는 경우가 많음

ML 프로젝트가 비즈니스 목적에 미치는 영향을 추론하기 어려운 경우도 다수 존재

A/B 테스트 등을 하고 ML 지표와 관계없이 비즈니스 지표가 더 좋은 모델을 고르는 경우도 많음

혹은 ML 시스템이 다양한 시스템과 결합되어 그 자체의 영향을 파악하기 어려운 경우도 많음

많은 기업에서 ML의 실제 유용성과는 관계없이 시류에 편승하여 진행하고 있음

또한 정치적인 목적을 달성하기 위해 ML 도입의 효과를 부풀리는 경우도 매우 많음

하지만 ML을 도입하여 뚜렷한 투자 수익은 도입 이후 성숙 단계에 도달해야 눈에 띄기 시작함

그림 1 - 기업이 모델을 프로덕션 환경에 배포하는 데 걸리는 시간은 ML을 사용한 시간에 비례

2.2 머신러닝 시스템 요구 사항

ML 시스템의 요구 사항은 유스케이스마다 다르지만 대부분 신뢰성, 확장성, 유지보수성, 적응성 등 네 가지 특성을 갖춰야 함

신뢰성

시스템은 다양한 문제 상황에서도 목표 성능을 만족하면서 지속적으로 기능을 수행해야 함

ML 시스템은 ‘시스템 동작의 올바름’을 판단하기 쉽지 않음

예측값은 계속 산출하더라도 예측값 자체가 틀렸을 수도 있음

확장성

ML 시스템은 다양한 방식으로 확장될 수 있음

모델의 복잡도가 증가하거나 모델의 개수가 증가하거나 트래픽이 증가할 수도 있음

따라서 다양한 확장에 대응할 수 있는 방법이 필요

자원 스케일링 (Resource scailing) 은 자원 규모를 변경하는 방법

업 스케일링(up-scailing) - 규모를 증가할 때 사용하는 자원 확장

다운 스케일링(down-scailing) - 자원이 더 이상 필요하지 않을 때 자원 축소

오토 스케일링은 이런 스케일링을 사용량에 맞게 자동으로 조정해주는 기능

시스템 규모 증가는 자원뿐만 아니라 아티팩트 관점에서도 고려 필요

모델이 1개라면 수동으로 관리가 가능하지만 100개라면 자동화할 방안이 필요

유지보수성

ML 시스템은 다양한 직군이 얽혀있음

여러 직군이 협업하므로 워크로드를 구조화하고 인프라를 설정하는 일이 중요

코드 문서화, 코드, 데이터, 아티팩트 버전 관리 등이 중요

(특히 모델 재현성 매우 중요!!)

적응성

변화하는 데이터 분포와 비즈니스 요구 사항에 적응할 수 있어야 함

성능 향상에 영향을 주는 요소를 찾고 서비스 중단없이 업데이트가 가능해야 함

2.3 반복 프로세스

ML 시스템 개발은 반복적이며 대체로 끝이 없는 프로세스

시스템을 프로덕션 환경에 배포하면 지속적으로 모니터링하고 업데이트하는 과정 필요

워크플로 예시) 사용자가 검색어를 입력할 때 광고를 노출해야 할 지 예측하는 ML 모델 개발

1. 최적화할 지표 선택. 예를 들어 광고를 보여주는 횟수(노출수)를 최적화

2. 데이터 수집 후 레이블 획득

3. 피처 엔지니어링

4. 모델 학습

5. 오류 분석 중 잘못된 레이블 때문에 오류가 발생하므로 데이터를 다시 레이블링

6. 모델 다시 학습

7. 광고를 노출하지 않음 의 데이터가 압도적으로 많아 항상 노출하지 말라는 결과를 도출하므로 새로운 데이터 수집 필요 (클래스 불균형)

8. 모델 다시 학습

9. 모델이 2개월 전 데이터에는 잘 작동하지만 최신 데이터에는 작동하지 않음 새로운 데이터 확보 필요

10. 모델 다시 학습

11. 모델 배포

12. 모델은 작동을 잘하지만 오히려 수익이 감소 수익 감소 문제를 해결하기 위해 노출 횟수 대신 광고 클릭률 최적화로 결정

13. 다시 1단계로..

전 단계에 걸쳐 기도하고 우는 과정은 생략..

위의 단계는 데이터 분석가나 ML 엔지니어 관점

ML 플랫폼 엔지니어나 데브옵스 엔지니어는 인프라 설정을 주로 하므로 또 다른 반복 프로세스로 고통 받을 예정..

그림 2- ML 시스템 개발은 여러 단계를 오가는 순환 과정

1단계: 프로젝트 범위 산정

프로젝트의 범위를 산정하고 목표, 목적과 제약 사항을 설정하는 과정

2단계: 데이터 엔지니어링

데이터 레이블링과 같은 처리부터 분석 목적에 맞게 데이터를 변형하는 과정

3단계: ML 모델 개발

4단계: 배포

5단계: 모니터링과 연속 학습

6단계: 비즈니스 분석

모델 성능을 비즈니스 관점에서 평가 및 분석해 비즈니스 인사이트 도출

인사이트를 바탕으로 비생산적인 프로세스를 중단하거나 새로운 프로젝트 범위 산정

2.4 머신러닝 문제 구조화 하기

일상에서 발생하는 비즈니스 문제를 ML 문제로 풀기 위해서는 ML 문제로의 구조화가 필요

ML 문제는 입력과 출력, 학습 프로세스를 이끌어가는 목적 함수(손실 함수)로 정의

ML 문제 구조화는 비즈니스 문제를 분석하여 적절한 입출력과 목적 함수를 정의하는 일

2.4.1 머신러닝 작업 유형

그림 3- 일반적인 ML 작업 유형

분류 VS 회귀

분류 - 입력을 여러 범주로 분류 (어느 클래스에 속하는 지를 판별)

회귀 - 연속적인 값 출력

회귀 모델과 분류 모델은 서로 쉽게 바꾸어 구조화 가능

이진 분류 VS 다중 클래스 분류

이진 분류 - 분류할 클래스가 두 개 (이상 거래 인지 아닌지)

다중 클래스 분류 - 분류할 클래스가 여러 개 (어느 반에 속할지)

다중 클래스 문제는 이진 분류보다 훨씬 다루기 까다로움

2차원에 표현 가능한 이진 분류와 달리 직관성이 떨어짐

클래스가 많으면 분류 작업의 카디널리티가 고차원이라고 표현

클래스가 여러 개일 경우 필요한 데이터 수가 크게 늘어남

클래스 별 데이터 불균형 문제도 고려 필요

이런 경우 계층적 분류가 유용할 수도 있음

대분류를 먼저 예측한 후 하위 분류를 예측해가는 방식

다중 클래스 VS 다중 레이블 분류

데이터 인스턴스가 여러 클래스에 동시에 속할 수 있다면 다중 레이블 분류 문제

예를 들어 기사의 주제를 분류한다면 기술, 정치 클래스에 동시에 속할 수 있음

다중 레이블 문제 접근법

1. 다중 클래스 문제와 동일하게 처리

2. 이진 분류 문제의 집합으로 바꾸어 처리

다중 레이블 문제는 현실에서 자주 발생하는 문제이지만 처리하기 힘듦

데이터 인스턴스마다 속하는 클래스 수가 다를 수 있어 레이블링이 까다로움

또한 모델에서 클래스 별 확률을 처리하기 어려워짐

⇒ 정확한 클래스 개수를 모르므로 상위 몇 개에 속한다고 예측할 지 애매

문제를 구조화하는 다양한 방법

문제를 구조화하는 방법을 바꾸면 문제가 훨씬 어려워지거나 쉬워짐

비즈니스 목적과 문제의 특성에 맞는 구조화 방법 고민 필요한 이유

2.4.2 목적함수

ML 알고리즘의 핵심은 학습을 진행시킬 목적 함수를 선택하는 일

주어진 문제에 맞게 알맞은 목적 함수를 선택해야 원하는 결과를 도출하는 모델 생성 가능

현실에서 발생하는 다양한 문제는 여러 개의 목적 함수를 가지고 있는 경우가 많음

특히 서로 상충하는 목적을 가진 함수들을 최적화하는 경우도 많음

(사용자가 클릭할 확률이 높은 자극적인 컨텐츠와 추천 컨텐츠의 품질을 높이는 일 등)

이 경우 단일 모델에서 두 가지 목적 함수를 적절히 조합하는 방법을 생각해볼 수 있음

$$loss = \alpha\;quality\_loss \;+\;\beta\;engagement\_loss$$

이 때 $\alpha, \beta$는 여러 실험을 거치면서 실험적으로 선택

$\alpha, \beta$를 조정하고 싶다면 처음부터 학습을 다시 진행해야 한다는 단점이 있음

다른 방법은 목적 함수를 분리하는 방법

각각 모델을 생성한 후 출력값을 $\alpha, \beta$로 조정하는 방법 (모델을 다시 훈련하지 않고도 조정 가능!)

목적 함수가 여러 개일 때는 모델 개발과 유지보수 측면에서 분리하는 편이 좋음

모델을 다시 학습하지 않아도 조정이 가능하므로 시스템 조정에 유리

목적 함수(=모델)별로 유지 관리 일정이 다를 경우에도 적용 가능

2.5 지성 VS 데이터

현재까지 ML 시스템의 성공 유무는 주로 데이터가 결정

기업들은 알고리즘 개선보다는 주로 데이터 관리와 개선에 집중함

하지만 과연 데이터가 충분조건인가? 는 고민해볼 문제

ML 시스템을 바라보는 관점은 지성과 데이터로 나뉨

지성(mind)은 모델 구조와 시스템 아키텍처 개선 등을 지칭

데이터는 데이터 자체의 품질과 함께 대용량 처리를 가능케 하는 연산 능력을 포함

ML을 바라보는 관점에 따라 어느 쪽이 더 중요한 지에 대한 논쟁이 일어나고 있음

시간이 지날수록 모델들이 사용하는 데이터셋의 크기는 증가하고 있음

하지만 데이터만 많다고 좋은 것이 아니라 품질이 낮은 데이터가 들어오면 오히려 성능이 저하될 수도 있음

2.6 정리

💡

비즈니용 ML 시스템을 개발한다면 비즈니스 목적에서 출발해야 함 비즈니스 목적을 ML 목적 형태로 변환 필요

💡

개발할 ML 시스템에 대한 명확한 요구 사항 정의 필요 요구사항은 유스케이스 별로 다르지만 신뢰성, 확장성, 유지보수성, 적응성을 주로 고려

<참고자료 - 머신러닝 시스템 설계>

Uploaded by N2T