머신러닝 시스템 설계 - Chapter 1. 머신러닝 시스템 개요
‘머신러닝 시스템’ 이라고 하면 다들 알고리즘만 떠올리지만 프로덕션 환경에서 알고리즘은 ML 시스템의 일부
시스템은 프로젝트의 출발점이 된 비즈니스 요구사항, 사용자와 개발자가 시스템과 상호작용하는 인터페이스, 데이터 스택, 모델을 개발 및 모니터링하고 업데이트하기 위한 로직과 이 로직을 전달할 수 있는 인프라까지 포함
1.1 머신러닝을 사용해야 하는 경우
ML 프로젝트를 수행하기 전에 반드시 필요한가? (필요조건인가?) 비용 효율적인가? 를 꼭 따져봐야함
일반적으로 ML 솔루션은 아래와 같은 작업을 수행함
ML 을 도입하기 전 확인해야할 사항들
- 학습 : 시스템에 학습 능력이 존재
ML 은 결국 데이터로부터 학습을 하여 문제를 풀기 때문에 학습할 대상이 필요
- 복잡한 패턴: 학습할 패턴이 존재하며 복잡
패턴이 명확하거나 혹은 복잡해야함
주사위 같이 패턴이 없거나 너무 단순하여 사람으로 충분한 경우는 필요가 없음
인간에게 어려운 패턴이 기계에게 쉽기도 하고 (10의 거듭제곱 계산 등) 인간에게 쉬운 작업이 기계에겐 어렵기도 함 (사진 속에서 고양이 찾기 등)
<그림 2 전통적인 소프트웨어와 머신러닝의 차이>
- 기존 데이터: 사용 가능한 데이터가 있거나 수집이 가능해야 함
- 예측: 미래에 대한 예측 수행
ML 모델은 비용이 낮고 근삿값인 예측을 대규모로 수행해 이득이 있을 때 특히 유용
계산 집약적인 문제를 예측 문제로 재구성하는 경우도 늘고 있음
정확한 계산에 의한 답이 아니라 근삿값을 추정하는 형태 (그래픽 렌더링 등)
- 본 적 없는 데이터: 본 적 없는(unseen) 데이터가 학습 데이터가 동일한 패턴을 가짐
모델이 기존 데이터로 학습한 패턴이 유용하려면 미래 데이터도 동일한 패턴을 가져야함
- 반복적
인간은 few-shot learning에 능하지만 기계는 패턴을 학습하기 위해 많은 양의 데이터가 필요
- 잘못된 예측으로 발생하는 비용이 낮음
모델 성능은 100%가 아니기 때문에 늘 실수가 발생
오분류에 대한 비용보다 맞췄을 때의 비용이 높다면 유용
- 대규모로 수행됨
- 패턴이 지속적으로 변함
ML을 적용하는 분야는 매우 빠르게 증가하지만 아래와 같은 경우는 사용 불가
- 비윤리적인 경우
- 보다 단순한 솔루션이 효과있는 경우
- 비용 효율적이지 않은 경우
ML이 전체 문제를 해결하진 못하더라도 부분 문제를 해결할 수는 있음
예를 들어 모든 고객문의를 처리하는 챗봇은 구축하기 힘들어도 자주 묻는 질문을 처리하는 챗봇을 만들고 여기 해당하지 않는 질문은 상담사를 연결하는 케이스가 가능
1.1.1 머신러닝 유스케이스
- 검색엔진
- 추천시스템
- 타이핑 예측
- 기계번역
- 이상거래탐지(FDS)
- 가격 최적화
- 수요 예측
- 고객 이탈 예측
1.2 머신러닝 시스템 이해하기
1.2.1 연구용 머신러닝 VS 프로덕션용 머신러닝
<표 1 연구용 ML과 프로덕션용 ML의 주요 차이점>
다양한 이해관계자와 요구사항
연구나 리더보드 프로젝트는 보통 벤치마크 데이터셋에서 가장 좋은 성능(state-of-the-art)을 내는 모델을 개발하는 것이 목표
하지만 이를 위해 모델 구조를 너무 복잡하게 만들어 프로덕션 적용을 어렵게 하는 경우가 많음
ML 시스템을 프로덕션에 적용하는 과정에는 많은 이해관계자가 얽혀있음
요구사항들이 서로 충돌하는 경우도 많으므로 모든 요구사항을 충족하는 ML 모델을 설계, 개발하기는 어려운 일
프로젝트 예시) - 사용자에게 음식점을 추천하는 모바일 앱 개발
각 이해관계자의 요구사항
ML 엔지니어
더 많은 데이터가 포함된 복잡한 모델을 사용해 사용자가 주문할 가능성이 가장 높은 음식점을 추천
영업팀
비싼 음식점일수록 수수료가 높으므로 더 비싼 음식점을 추천하는 모델
제품팀
레이턴시가 증가할 때마다 서비스를 통한 주문이 감소하므로 100ms 이내에 추천 음식점을 반환할 수 있는 모델
ML 플랫폼팀
트래픽이 증가함에 따라 기존 시스템을 스케일링하는 문제 때문에 한밤중에 일어나야 하는 경우가 있어, 플랫폼 개선을 우선시하기 위해 모델 업데이트 보류
관리자
마진을 최대화하기 위해 ML 팀을 내보내기 (?)
위 예시처럼 프로덕션용 ML은 다양한 요구사항이 있고 서로 상충하는 경우도 많기 때문에 연구용 ML과는 다름
연구 프로젝트가 성공적이더라도 프로덕션에는 사용되지 않을 수 있음 (앙상블 등등)
모델 성능 개선을 위해 복잡함이 증가한다면 복잡함을 정당화할만큼 훨씬 나은 성능을 보장해야함
계산 우선순위
ML 시스템을 배포한 경험이 없으면 시스템을 설계할 때 모델 개발에만 집중하고 배포와 유지 관리를 소홀히 하는 경우가 많음
모델 개발 프로세스에서는 매우 많은 양의 학습 데이터와 소수의 (훈련 데이터에 비해서는) 검증 데이터를 사용하므로 학습 과정이 병목
모델 배포 이후에는 예측을 생성하는 일이 주가 되므로 추론이 병목이 됨
연구에서는 높은 스루풋(throughput) 을 우선시 프로덕션에서는 낮은 레이턴시(latency)를 우선시
연구에서는 높은 스루풋을 위해 배치 처리를 주로 활용하지만 실시간 추론에서 배치 처리는 레이턴시를 더욱 증가시키는 요인
레이턴시가 길수록 고객 이탈도 많아지므로 매우 중요한 문제
레이턴시는 개별 수치가 아닌 분포
산술 평균과 같은 수치는 아웃라이어의 영향을 많이 받으므로 백분위수를 사용하면 유용
높은 백분위수는 이상치를 탐지하기도 하지만 중요 고객이 누구인지 알려주기도 함
실제로 아마존에서 가장 느린 요청을 받은 고객은 계정에 데이터가 많은 고객 (=중요고객)
따라서 시스템의 성능 요구 사항을 높은 백분위수로 지정하는 것도 일반적
데이터
연구에서 주로 사용하는 벤치마크 데이터는 깨끗하고 형식이 잘 지정되어 있어 모델 개발에만 집중하기 좋음
이미 많은 연구에 사용되었으므로 데이터셋에 대한 단점도 알고 있고 빠른 처리를 위한 오픈소스도 많음
하지만 실제 데이터는 잡음이 많고 비정형일 수도 있고 끊임없이 변화함
데이터에 편향 혹은 클래스 불균형이 있을수도 있지만 어느 지점에서 발생했는지도 모름
개인정보와 같은 민감한 정보가 있다면 이런 정보를 처리할 방법도 강구
공정성
연구 단계에서는 아직 모델이 사용 전이므로 공정성에 대한 논의를 미룰 수 있음
하지만 설계 단계에서 고민하지 않고 배포 단계에서 고민한다면 너무 늦음
모델이 편향된 결과를 내거나 (인종, 성별 등에 차별) 데이터 변화가 있거나 소수의 의견을 무시하는 결과가 나올 수 있으므로 이를 적절히 관리하는 방안이 중요
해석 가능성(Interpretability)
연구에서는 앞서 말했듯이 state-of-the-art 성능을 내는 것이 여전히 주요 목표
모델이 해석 가능하다면 유용하긴 하겠지만 중요한 고려 사항은 아님
비즈니스 영역에서는 해석 가능성이 필수적인 고려 사항
모델의 최종 사용자나 관리자 모두 모델이 왜 그런 결과를 산출 했는지를 알고 싶어함
모델을 개발하는 측면에서도 디버깅과 개선하는 측면에서 중요
논의
학교에서만 머신러닝을 배웠던 사람은 학문적 영역으로도 충분하다고 하지만 회사에서는 비즈니스에 적용할 수 있는 것이 무엇보다 중요
(비즈니스 관점에서) 더 좋은 알고리즘은 성능이 좋은 알고리즘이 아니라 비즈니스에 효율적으로 접목할 수 있는 알고리즘
그럴 수 있는 시스템을 설계하는 것이 중요
1.2.2 머신러닝 시스템 VS 전통적인 소프트웨어
일반적인 소프트웨어 엔지니어링 (SWE) 방법론을 그대로 머신러닝에 적용하는 것은 어려움
SWE 방법론은 가능한 코드와 데이터를 분리하여 모듈화하고 유지하는 것에 관심사
ML 시스템은 코드, 데이터 그리고 이로부터 생성된 아티팩트로 이루어짐
더 좋은 성능은 더 많고 좋은 데이터로 학습한 모델로부터 나오므로 데이터를 개선하려는 노력이 주를 이룸
기존 SWE에서는 코드의 버전만 관리하지만 ML 에서는 데이터 역시 버전관리가 필요함
또한 어떤 데이터가 ‘더 좋은’ 데이터인지 판별하는 작업도 필요
1.3 정리
Uploaded by N2T