Jonas Kim

Posted on Nov 8

'머신러닝 시스템 설계' (Chip Huyen) 요약 - 파트 1

#ai #machinelearning #systemdesign #mlops

책 머신러닝 시스템 설계과 그에 대한 요약본 Summary of Designing Machine Learning Systems을 참고하였습니다.

1 - ML 시스템 개요

ML을 사용해야 할 때 (그리고 사용하지 말아야 할 때)

ML 솔루션이 작동하기 위해 필요한 문제의 특징

어떤 문제는 다른 문제보다 ML 솔루션에 더 적합한 경향이 있습니다. 전통적인 소프트웨어 엔지니어링과 ML이 모두 실행 가능한 옵션인 경우에도 ML이 최적의 솔루션이 아닐 수 있습니다.

이 책에는 (지도) ML 시스템이 일반적으로 수행하는 작업에 대한 다음 정의가 포함되어 있습니다. ML로 문제를 해결할 수 있으려면 이 정의에 인코딩된 특정 특징이 필요합니다.

머신 러닝은 (1) 기존 데이터로부터 (2) 복잡한 패턴을 학습하고 이 패턴을 사용하여 (3) 예측을 수행하고 (4) 보이지 않는 데이터에 적용하는 접근 방식입니다.

1. 기존 데이터: 데이터가 이용 가능하거나 수집할 수 있어야 합니다.

충분한 데이터가 없고 이를 수집할 메커니즘이 없다면 ML 접근 방식은 작동하지 않습니다. 지도 학습(supervised learning)의 경우, 충분한 레이블이 지정된 데이터가 필요합니다.

제로샷(Zero-shot) / 퓨샷(few-shot) 학습 기술을 사용하면 특정 작업에 대한 데이터로 모델을 학습시킬 필요 없이 예측을 수행할 수 있습니다. 그러나 이는 일반적으로 사전 학습된 모델(pre-trained models)에 의존합니다.
지속적인 학습(Continuous learning) 기술도 사용할 수 있습니다. 이는 학습되지 않은 모델을 프로덕션에 배포하고, 프로덕션 데이터를 온라인 증분 학습(online incremental training), 강화 학습(reinforcement learning) 또는 향후 오프라인 학습(offline training)에 사용하는 것을 의미합니다. 학습되지 않은 모델을 프로덕션에 배포하는 것은 위험을 수반합니다.
'될 때까지 속여라(Fake it till you make it)' 전략도 기업들 사이에서 인기가 있습니다. 이는 ML 모델 대신 사람이 직접 예측을 수행하는 제품을 출시하고, 이렇게 생성된 데이터를 나중에 ML 모델 학습에 사용하려는 희망을 가지고 진행하는 방식입니다.

2. 복잡한 패턴: 학습할 패턴이 있고, 그 패턴이 복잡해야 합니다.

데이터는 있지만 학습할 패턴이 없다면 ML 접근 방식은 의미가 없습니다. 예를 들어, 공정한 주사위의 결과를 예측하기 위해 ML 시스템을 구축하는 것은 의미가 없습니다.
패턴이 있지만 단순하다면, 해당 문제에 순수한 소프트웨어 엔지니어링 솔루션을 사용하는 것이 더 합리적일 수 있습니다 (예: 주소 기반으로 우편번호를 찾기 위해 ML 시스템을 구축하지 말고, 그냥 조회 테이블(lookup table)을 사용하세요).

3. 문제를 예측 문제로 구성(frame)할 수 있어야 합니다.

지도 ML 모델은 예측을 수행합니다. 문제 전체 (또는 일부)를 예측 문제로 구성할 수 없다면, 지도 ML은 적절한 도구가 아닙니다.
계산 집약적인(computationally intensive) 많은 문제들이 예측 문제로 재구성되고 있습니다. 비디오 게임의 조명 렌더링이 한 예입니다. 조명이 정확히 어떠해야 하는지에 대한 비용이 많이 드는 전체 계산을 수행하는 대신, 회귀(regression) ML 모델을 사용하여 "충분히 좋은" 근사치를 얻을 수 있습니다. 이 경우 모델을 학습시키는 것이 계산을 수행하는 것보다 비용이 적게 듭니다.

4. 보이지 않는 데이터(unseen data)가 학습 데이터(train data)와 패턴을 공유해야 합니다.

모델은 프로덕션 데이터의 패턴이 학습 데이터의 패턴과 동일할 때만 잘 작동합니다.
데이터가 보이지 않는다면, 그것이 어떤 분포에서 왔는지 어떻게 알 수 있을까요? 우리는 알 수 없으며, 단지 그럴 것이라고 합리적인 가정을 할 뿐입니다. 우리는 프로덕션 환경에서 모니터링(8장)하고 테스트(9장)함으로써 우리의 가정이 맞았는지 사후에 확인할 수 있습니다.

ML 솔루션을 특히 유용하게 만드는 문제의 특징들

이것들이 필수적인 특징은 아니지만, 이 중 하나 또는 여러 개를 가지고 있다면 해당 문제에 대해 ML 접근 방식이 성공할 가능성이 훨씬 높아집니다.

반복적인 작업입니다. 작업이 반복적이라면 패턴이 여러 번 나타난다는 의미이므로, ML 모델이 더 잘 학습할 수 있습니다.
잘못된 예측의 비용이 저렴합니다. ML 모델은 필연적으로 잘못된 예측을 합니다. 실수의 비용이 저렴하면 위험 부담이 낮아져 ML 모델을 구축하고 배포하기가 더 쉬워집니다. 잘못된 예측의 결과가 재앙적일지라도, 올바른 예측의 이점이 잘못된 예측의 비용을 평균적으로 상회한다면 모델을 구축할 수 있습니다. 자율 주행 자동차는 자동화된 자동차가 인간이 운전하는 자동차보다 평균적으로 더 안전하다는 점을 고려할 때 이에 대한 좋은 예입니다.
작업이 대규모(at scale)로 발생합니다. ML 모델을 프로덕션에 배포하는 것은 어렵습니다. 모델이 많은 예측을 수행하는 데 사용될 때 이러한 노력이 더 정당화됩니다. 또한, 작업이 대규모로 발생하면 학습할 데이터가 많아집니다.
패턴이 끊임없이 변화합니다. 패턴이 자주 변경되어 하드코딩된 규칙이 너무 빨리 구식이 되어버릴 때, ML은 전통적인 소프트웨어 규칙에 비해 빛을 발합니다. 스팸 트렌드의 변화와 문화 트렌드의 변화가 바로 변화하는 패턴의 예입니다.

일반적인 ML 사용 사례

ML은 소비자(consumer) 대상 애플리케이션과 기업(enterprise) 내부 애플리케이션 모두에 사용되고 있습니다. 소비자 ML 애플리케이션은 성장하고 있지만, 2022년 기준으로 여전히 대다수의 애플리케이션은 기업 영역에 있습니다.

소비자 애플리케이션에서는 정확성(accuracy)보다 지연 시간(latency)이 더 중요한 경향이 있습니다. 지연 시간이 증가하면 사용자가 앱에서 이탈할 수 있습니다. 소비자들은 또한 영화 추천이나 사진의 잘못된 태그 지정과 같이 중요하지 않은 애플리케이션에서는 잘못된 예측에 대해 더 관대한 경향이 있습니다.
기업 애플리케이션에서는 지연 시간보다 정확성이 더 중요한 경향이 있습니다. 정확성이 조금만 향상되어도 연간 수백만 달러를 절약할 수 있습니다. 아래 이미지는 ML 기업 애플리케이션의 세부 내역을 보여줍니다. 다음은 몇 가지 예입니다.
- 고객 획득 비용(CAC)을 줄이기 위해 ML을 사용합니다. 더 나은 타겟 광고를 표시하고, 적절한 순간에 할인을 제공합니다. 2019년 기준, 인앱 구매를 하는 사용자의 평균 CAC는 86.61달러입니다. 높은 CAC는 스타트업에 치명적일 수 있습니다.
- 이탈 예측(Churn prediction): 신규 고객을 획득하는 것은 기존 고객을 유지하는 것보다 5배에서 25배 더 비쌉니다.
- 브랜드 모니터링: 소셜 미디어에서 귀하의 브랜드에 대한 대중의 감정(sentiment)을 모니터링합니다.

연구(Research)와 프로덕션(Production) ML의 차이

연구용 ML과 프로덕션용 ML은 다릅니다. 연구 환경의 사고방식으로 프로덕션 모델에 접근하려 할 때 발생하는 함정을 피하기 위해 그 차이점을 인식하는 것이 중요합니다.

	연구 (Research)	프로덕션 (Production)
요구사항	벤치마크 데이터셋에서의 최첨단(State-of-the-art) 모델 성능 (1)	다양한 이해관계자가 각기 다른 요구사항을 가짐 (2)
계산 우선순위	빠른 학습, 높은 쿼리 처리량(throughput) (3)	낮은 지연 시간(latency)의 빠른 추론(inference) (4) (5) (6)
데이터	정적인 경우가 많음	끊임없이 변화함
공정성(Fairness)	초점이 아닌 경우가 많음	반드시 고려되어야 함 (7)
해석 가능성(Interpretability)	초점이 아닌 경우가 많음, 성능이 북극성(north star) (8)	반드시 고려되어야 함

(1) 모델 배포 및 유지보수에 중점을 두지 않음.

(2) MLE, 영업 팀, 제품 관리자, ML 플랫폼 팀 모두 동일한 시스템에 대해 서로 다른 요구사항을 가짐.

(3) 대부분의 최신 시스템은 추론 시 쿼리를 일괄 처리(batch up)합니다. 연구에서는 전체 테스트 데이터셋에 대한 예측 처리량(throughput)이 수용 가능하다면 단일 쿼리에 응답하는 시간이 길어도 크게 중요하지 않습니다. 프로덕션에서는 단일 쿼리에 응답하는 시간이 중요하므로, 처리량과의 균형을 맞춰야 합니다.

(4) ...모델을 실제 환경에 배포하면 지연 시간(latency)은 매우 중요합니다. 2017년 Akamai 연구에 따르면 100ms의 지연이 전환율(conversion rates)을 7%까지 떨어뜨릴 수 있습니다. 20 2019년 Booking.com은 약 30%의 지연 시간 증가가 전환율을 약 0.5% 감소시켰으며, 이는 "우리 비즈니스에 상당한 비용"이라고 밝혔습니다. 21 2016년 Google은 모바일 사용자의 절반 이상이 페이지 로드에 3초 이상 걸리면 이탈한다는 것을 발견했습니다. 22 오늘날 사용자들은 훨씬 더 참을성이 없습니다.

(5) 지연 시간은 평균이 아닌 백분위수(percentiles)를 사용하여 모니터링해야 합니다. 가장 가치 있는 고객들은 더 많은 데이터를 가지고 있고 더 느린 추론을 경험하는 경향이 있으므로, p90에서 p99와 같은 상위 백분위수를 무시하지 마십시오.

(6) 시스템의 지연 시간 요구사항을 명시할 때 p90과 같은 상위 백분위수를 사용하는 것을 고려하십시오.

(7) ML 시스템은 과거를 인코딩하고 학습 데이터가 가진 편향을 재현하고 고착화합니다. 설상가상으로, ML 시스템은 대규모로 차별을 행하여 잠재적으로 수백만 명의 사람들에게 영향을 미칠 수 있습니다.

(8) 예를 들어, 앙상블 모델(ensemble models)은 연구에서는 흔하지만, 낮은 해석 가능성과 높은 복잡성 때문에 프로덕션에서는 매우 드뭅니다.

ML 시스템 vs 전통적인 소프트웨어

표면적으로는 SWE(소프트웨어 엔지니어링)의 모범 사례를 ML 엔지니어링에 도입하는 것이 좋은 생각처럼 보입니다. 하지만 그렇게 간단하지 않습니다. SWE 시스템은 설계상 데이터와 코드를 분리하며, 버전 관리, 테스트, 배포 및 모니터링의 노력은 코드 산출물(artifacts)에 집중됩니다.

ML 시스템은 코드, 데이터, 그리고 이 둘로부터 생성된 산출물의 조합입니다. 이 모든 것들이 버전 관리, 테스트, 배포, 모니터링되어야 합니다.

과제들:

데이터를 어떻게 버전 관리할 것인가?
데이터 샘플이 시스템에 좋은지 나쁜지 어떻게 테스트할 것인가?
기가바이트의 RAM을 필요로 하는 수백만 개의 매개변수를 가진 학습된 모델을 어떻게 배포할 것인가? 만약 엣지(edge)에 배포해야 한다면 어떻게 할 것인가?
배포된 모델이 해석하기 어려울 수 있다는 점을 고려할 때, 이를 어떻게 모니터링하고 디버깅할 것인가?

2 - 프로젝트 목표, 요구사항 및 프레이밍

(1장에서 설명한 것처럼) 문제에 ML 솔루션이 실행 가능하다고 판단했다면, 이제 비즈니스 목표를 ML 목표와 일치시키고 시스템이 충족해야 하는 운영 요구사항을 정의할 차례입니다.

또한, 이 장에서는 문제 프레이밍(problem framing)이 솔루션 구축 및 유지를 얼마나 쉽거나 어렵게 만들 수 있는지에 대해서도 다룹니다.

비즈니스 목표와 ML 목표의 관계

기업은 accuracy(정확도), precision(정밀도), recall(재현율), F1 등과 같은 ML 지표 자체에는 큰 관심이 없습니다. 데이터 사이언티스트가 비즈니스 지표는 무시한 채 ML 지표 개선에만 (hacking) 너무 집중하는 ML 프로젝트는 실패하기 쉽습니다. ML 프로젝트가 조직 내에서 장기적으로 성공하려면, ML 시스템의 성능을 수익, 월간 활성 사용자(MAU) 등과 같은 비즈니스 성과 지표(KPI)에 연결하는 것이 중요합니다.
비즈니스 목표를 ML 목표로 매핑하는 작업은 애플리케케이션에 따라 난이도가 다릅니다. 예를 들어, 금융 애플리케이션에서 사기 탐지 시스템의 비즈니스 영향은 매우 명확하고 측정하기 쉽습니다. 반면, 잠재적인 사이버 보안 위협을 탐지하는 ML 시스템에서는 이러한 매핑이 훨씬 불분명합니다. 당연하게도, (사기 탐지처럼) 매핑이 더 쉬운 ML 애플리케이션이 가장 일반적인 유형의 기업 ML 애플리케이션이기도 합니다.
많은 기업이 비즈니스 지표를 ML 지표에 매핑하기 위해 자체적인 지표를 만듭니다. 예를 들어, Netflix는 추천 시스템의 성능을 take-rate(이용률)로 측정합니다. 사용자가 본 추천 수 대비 의미 있는 재생 수(quality plays). take-rate가 높을수록 추천 시스템이 더 우수합니다.

ML 시스템의 요구사항

ML 시스템이 가질 수 있는 요구사항은 많습니다. 그러나 적어도 신뢰성(reliability), 확장성(scalability), 유지보수성(maintainability) 및 적응성(adaptability)에 대해 고민해봐야 합니다. 이 섹션에서는 ML 시스템의 맥락에서 이들 각각이 무엇을 의미하는지 논의합니다.

신뢰성(Reliability)

시스템은 다양한 장애 상황(adversity)에 직면하더라도 원하는 성능 수준에서 올바른 기능을 계속 수행해야 합니다.
ML 시스템에서 "정확성"을 결정하는 것은 소프트웨어 시스템에서보다 더 어렵습니다. ML 시스템은 예를 들어, 계속해서 잘못된 예측을 생성함으로써 조용히 실패할 수 있습니다(fail silently). 우리가 사전에 정답(ground truth)을 모른다면 예측이 틀렸는지 어떻게 알 수 있을까요?

확장성(Scalability)

ML 시스템이 확장해야 하는 다양한 축(axes)을 고려하십시오.
ML 시스템은 모델 크기(예: 더 많은 파라미터 사용)가 커질 수 있으며, 이는 모델 실행에 더 많은 하드웨어 RAM을 필요로 함을 의미합니다.
ML 시스템은 처리하는 트래픽 양이 증가할 수 있습니다. 시스템이 이를 따라잡을 수 있어야 합니다.
ML 시스템은 특정 유스케이스에 대해 모델 수가 증가할 수 있습니다. 예를 들어, 처음에는 트렌딩 토픽을 탐지하는 모델만 있었습니다. 그런 다음 해당 유스케이스에 NSFW(업무상 부적절한) 트렌딩 트윗을 필터링하는 두 번째 모델을 도입합니다.
자원 확장만이 확장성의 유일한 관심사는 아닙니다. 산출물 관리(artefact management)도 마찬가지입니다. 수백 개의 모델이 있을 때는 모델을 모니터링, 재학습 및 배포하는 자동화되고 반복 가능한 방식이 필요합니다. 모델이 몇 개뿐이라면 이 모든 것을 수동으로 할 수도 있을 것입니다.
이 책은 다른 섹션에서 확장성 주제를 더 다룹니다. 분산 학습(Distributed Training), 모델 최적화(Model Optimisation), 자원 관리(Resource Management), 실험 추적 및 버전 관리(Experiment Tracking and Versioning), 개발 환경(Development Environment).

유지보수성(Maintainability)

다양한 배경의 사람들(ML 엔지니어, DevOps 엔지니어, SME(해당 분야 전문가) 등)이 단일 ML 시스템에서 작업합니다. 한 그룹이 모든 사람에게 도구 세트를 강요하는 대신, 모든 그룹이 자신에게 익숙한 도구를 가지고 작업할 수 있도록 워크플로우를 구조화하는 것이 중요합니다.
코드는 문서화되어야 하며, 데이터와 산출물은 버전 관리되어야 합니다.
이 주제에 대한 자세한 내용은 "11장의 팀 구조 섹션"에 있습니다.

적응성(Adaptability)

데이터 분포와 비즈니스 요구사항은 빠르게 변합니다. 시스템은 이러한 자연스러운 변화에 쉽게 적응할 수 있어야 합니다.

ML 문제 프레이밍하기(Framing)

비즈니스 문제는 일반적으로 ML 문제로 직접 변환되지 않습니다. 비즈니스 문제의 어떤 부분을 ML로 해결할 수 있을지 파악하기 위해 고민이 필요합니다. 일단 그 부분을 식별하고 나면, 그 하위 문제를 ML 문제로 프레이밍하는 방식이 작업을 더 쉽게 또는 더 어렵게 만들 수 있으며, 때로는 프로젝트의 성패를 좌우할 수도 있습니다.

문제를 프레이밍할 때 고려해야 할 두 가지 사항이 있습니다. (1) 문제를 모델링하는 데 사용할 ML 작업(task)의 유형, (2) 여러 ML 목표가 있는 문제에서 목적 함수(objective function)를 프레이밍하는 방식.

지도 ML 작업(Task)의 유형

분류(Classification)에서는 클래스(classes)가 적을수록 문제가 단순해집니다. 이진 분류기(Binary classifiers)는 가장 단순한 형태이며 ML 실무자들에 의해 널리 사용됩니다.
다중 클래스(Multi-class): 선택할 레이블이 2개 이상이지만 각 관측치(observation)는 단 하나의 레이블만 할당될 수 있습니다.
- 높은 카디널리티(High cardinality): 선택할 레이블이 매우 많습니다. 예를 들어, 질병 이름. 높은 카디널리티 문제는 어렵습니다.
다중 레이블(Multi-label): 각 관측치가 하나 이상의 레이블을 가질 수 있습니다. 예를 들어, 신문 기사가 과학과 경제 레이블 모두에 속할 수 있습니다. 다중 레이블 분류 문제는 어렵습니다.
높은 카디널리티와 다중 레이블 특성을 모두 갖는 문제는 매우 어렵습니다.

분류(Classification) vs 회귀(Regression) 프레이밍

회귀 모델은 분류 모델로 쉽게 프레이밍될 수 있으며 그 반대도 마찬가지입니다.

연속적인 출력 레이블을 구간화(bucketing)하여 이산형(discrete)으로 바꾸면 회귀 모델을 분류 문제로 프레이밍할 수 있습니다. 예를 들어 <100, 100-200, >200.
출력을 0과 1 사이의 연속 변수로 프레이밍하고 임계값(threshold)을 사용하면 분류 문제를 회귀 문제로 프레이밍할 수 있습니다. 예를 들어 if predicted_spam_score >= threshold: SPAM.

다중 클래스(Multi-class) 분류 프레이밍

높은 카디널리티 문제는 어렵습니다. 다중 클래스 모델을 사용하기로 결정하기 전에 다른 대안이 있는지 확인하십시오.
높은 카디널리티 문제의 데이터 수집은 어렵습니다. ML 모델은 일반적으로 해당 클래스를 분류하는 방법을 배우기 위해 각 클래스마다 최소 100개의 예제가 필요합니다. 따라서 1,000개의 클래스가 있다면 이미 최소 100,000개의 예제가 필요합니다. 데이터 수집은 특히 희귀한 클래스의 경우 어려울 수 있습니다. 수천 개의 클래스가 있을 때, 그 중 일부는 희귀할 가능성이 높습니다.
클래스 수가 많을 때, 계층적 분류(hierarchical classification)가 유용할 수 있습니다. 예를 들어, 개, 고양이 또는 유니콘을 식별하는 1차 분류기를 사용합니다. 그런 다음 이전에 개로 레이블이 지정된 것들을 푸들, 래브라도, 달마시안 등으로 분류하는 또 다른 개 분류기를 사용합니다. 다음 두 아티클이 계층적 분류 주제를 다룹니다.
- The Hitchhiker’s Guide to Hierarchical Classification
- Hierarchical Classification with Local Classifiers: Down the Rabbit Hole
어떤 사람들은 다중 이진 분류기를 사용하여 다중 클래스 문제를 프레이밍한 다음, 최종 예측을 하기 위해 휴리스틱(heuristic)이나 메타 학습기(meta-learner)를 추가하려고 시Ddo합니다. 예를 들어, 가장 높은 이진 분류기의 레이블을 선택합니다.

다중 레이블(Multi-label) 분류 프레이밍

다중 레이블 분류 문제는 각 관측치가 서로 다른 개수의 레이블을 가질 수 있기 때문에 어렵습니다.
- 데이터 수집이 어려워집니다. 서로 다른 레이블 작업자(annotators)가 동일한 관측치에 대해 서로 다른 수의 레이블을 할당할 수 있습니다.
- 원본 확률(raw probabilities)에서 레이블을 추출하는 것이 모호해집니다. 예를 들어, 주어진 관측치에 대한 확률 벡터가 [0.45, 0.2, 0.02, 0.33]과 같다면, 레이블을 할당하기 위해 상위 1개, 상위 2개 또는 상위 N개의 확률을 선택해야 하는지 불분명합니다.
다중 레이블 분류에는 두 가지 주요 접근 방식이 있습니다.
- 학습 데이터에서 관찰되는 각 레이블 조합에 대해 고유한 레이블을 생성하여 문제를 다중 클래스 문제로 취급합니다. 예를 들어, 신문 기사는 기술-금융(하나의 레이블)으로 분류될 수 있고 다른 기사는 기술(다른 레이블)로 분류될 수 있습니다. 카디널리티가 크다면, 이 방식은 카디널리티를 폭발적으로 증가시킬 수 있습니다.
- 주어진 레이블이 주어진 관측치에 할당되어야 하는지 여부를 결정하는, 레이블별 이진 분류기 세트를 사용합니다. 여러 분류기가 "예"라고 말하면, 다중 레이블 관측치를 갖게 됩니다.

프레이밍이 중요한 이유의 예

아래 예는 프레이밍이 어떻게 프로젝트의 성패를 좌우할 수 있는지 보여줍니다. 작업은 사용자가 다음에 열 가능성이 가장 높은 앱을 예측하는 것입니다. 동일한 문제가 분류 작업과 회귀 작업으로 프레이밍됩니다.

분류 프레이밍은 새 앱이 설치될 때 모델을 재학습해야 하므로 처참하게 실패합니다.

0과 1 사이의 임의의 "다음 사용 점수"를 예측하기 위해 앱 피처(app features)를 도입하여 회귀 작업으로 프레이밍하면, 새 앱이 설치될 때 재학습할 필요가 없어집니다. 이 경우 필요한 유일한 작업은 app features 벡터를 추출한 다음 동일한 모델을 사용하는 것입니다.

다중 목표 애플리케이션에서의 목적 함수 프레이밍

공식적으로 말하면, ML 모델을 학습하는 데 사용할 수 있는 다양한 목적 함수가 많으며, 이를 고안하려면 모델 이면의 수학에 대한 깊은 지식이 필요합니다. 그러나 실제로는 단일 모델에 대한 목적 함수 선택은 보통 쉽습니다. 대부분의 ML 엔지니어는 회귀(regression)에 RSME 또는 MAE, 이진 분류(binary classification)에 로그 손실(log loss), 다중 클래스 분류(multi-class classification)에 교차 엔트로피(cross entropy)와 같은 잘 알려진 함수를 사용합니다.

이 섹션의 요점은 모델에 "올바른" 목적 함수를 선택하는 방법이 아닙니다. 그것은 여러 목표가 있는 문제에서 여러 목적 함수를 올바르게 결합하는 방법입니다. 이것은 예제를 통해 설명하는 것이 더 쉽습니다.

사용자의 뉴스 피드에서 아이템 순위를 매기는 ML 시스템을 구축하는 작업이라고 상상해 보십시오. 이를 달성하기 위해 다음과 같은 계획을 세웁니다.

관련 없는 콘텐츠 필터링 (스팸, NSFW 콘텐츠 및 잘못된 정보)
품질별 게시물 순위 매기기 (어떤 수치 척도로 측정됨) → 이는 학습 과정이 품질 손실을 최소화하려 함을 의미
참여도별 게시물 순위 매기기 (게시물 클릭 수로 측정됨) →이는 학습 과정이 참여도 손실을 최소화하려 함을 의미

당신의 문제는 두 개의 상충되는 목표(conflicting objectives)를 가진 다중 목표 문제입니다. 품질은 낮지만 참여도가 높은 게시물의 순위를 어떻게 매길 것인가? 단일 순위 목록을 생성하려면 단일 ranking_score 숫자가 필요합니다.

순진한 프레이밍: 단일 목적 함수 생성

ranking_score 함수를 만든 다음 해당 함수로 모델을 학습시킬 수 있습니다 (즉, ranking_loss 최소화):

ranking_score = alpha * quality_score + beta * engagement_score

그런 다음 다양한 alpha와 beta를 테스트하여 가장 잘 작동하는 조합을 찾습니다.

이 방식의 문제는 alpha나 beta를 변경할 때마다 모델을 완전히 재학습해야 한다는 것입니다.

더 현명한 프레이밍: 목표 분리하기(Decoupling)

대안으로, 두 개의 독립적인 모델을 학습시킬 수 있습니다. 하나는 quality_score를 예측하고 다른 하나는 engagement_score를 예측합니다. 그런 다음 예측을 수행한 후에 두 모델의 출력을 다음과 같이 결합할 수 있습니다. ranking_score = alpha * quality_score + beta * engagement_score. 이번에는 모델을 재학습할 필요 없이 alpha와 beta를 변경할 수 있습니다.

일반적으로 여러 목표가 있을 때, 모델 개발과 유지를 더 쉽게 만들기 때문에 먼저 목표를 분리하는 것이 좋습니다. 첫째, 이전에 설명했듯이 모델 재학습 없이 시스템을 조정하기가 더 쉽습니다. 둘째, 다른 목표는 다른 유지보수 일정이 필요할 수 있으므로 유지보수가 더 쉽습니다.

이 예에서, 분리는 참여도 모델에 영향을 주지 않고도 quality_model을 더 자주 업데이트하거나 재학습할 수 있게 합니다.

3 - 데이터 엔지니어링 기초

이 장은 "데이터 vs 알고리즘, 무엇이 더 중요한가?"라는 철학적 논의를 통해 데이터의 중요성을 강조하며 시작합니다.

그 후, 이 장에서는 "ML 시스템의 데이터"라는 주제의 다양한 차원을 체계적으로 다룹니다. 이러한 다양한 차원을 아는 것은 ML 엔지니어가 시스템을 더 잘 이해하고 더 나은 선택을 하는 데 도움이 될 것입니다.

알고리즘의 품질 vs 데이터의 품질 및 양

ML의 미래가 (지금까지 그래왔듯이) 데이터의 품질과 양에 의해 계속 주도될 것인지, 아니면 학습 알고리즘의 품질에 의해 주도될 것인지에 대한 큰 논쟁이 있습니다. 후자 진영에서는 컴퓨팅 파워의 증가로 더 똑똑하고 강력한 알고리즘이 등장할 것이며, 이것이 더 낮은 품질과 양의 데이터를 보완할 것이라고 생각합니다.
논쟁은 여전히 진행 중입니다. 그러나 현재로서는 데이터의 품질과 양이 필수적이라는 것을 아무도 부인할 수 없습니다. 이것이 머신 러닝의 가장 기본적인 요구 사항이 (모델 학습 자체가 아니라) 모두 데이터와 관련된 이유입니다.

데이터 과학의 요구 계층. 모니카 로가티(Monica Rogati)의 이미지에서 각색함

데이터 소스

ML 시스템을 구동하는 데이터는 일반적으로 다양한 소스에서 나옵니다. 소스는 다음과 같이 분류할 수 있습니다.

사용자 입력 데이터: 텍스트, 이미지, 비디오, 파일 등 형식이 매우 다양합니다. 형식이 맞지 않는(Malformed) 데이터가 매우 흔합니다.
시스템 생성 데이터: 로그 및 시스템 출력(메모리 사용량, CPU 사용량 등), 그리고 클릭, 스크롤링, 확대/축소, 페이지 체류 시간과 같은 사용자 행동에 대한 메타데이터.
- 사용자 데이터보다 형식이 잘못될 가능성이 적습니다.
- ML 시스템 디버깅은 어렵기 때문에, 가능한 모든 것을 로깅하는 것이 일반적인 관행입니다.
- 엄청난 양의 시스템 생성 데이터에는 두 가지 과제가 있습니다. 노이즈 속에서 신호(signal)를 찾아내는 것과 대량의 로그를 저장하는 방법입니다.
내부 데이터베이스: 비즈니스를 운영하기 위해 소프트웨어 서비스에서 사용하는 데이터베이스입니다.
제2자(Second-party) 데이터: 다른 회사가 자사 고객에 대해 수집한 데이터로, 귀하가 사용할 수 있게 제공된 데이터입니다.
제3자(Third-party) 데이터: 기업이 자사 고객이 아닌 대중에 대해 수집한 데이터입니다. 예를 들어, 계정을 개설하지 않았더라도 휴대폰의 모든 행동을 추적하는 앱입니다.

데이터 형식

형식의 선택은 사람이 읽을 수 있는지(human readability), 검색 속도, 전송 속도 및 저장 비용에 영향을 줍니다.
사용할 데이터 형식을 결정할 때, 데이터가 미래에 어떻게 사용될지 생각하고 합리적인 형식을 선택하십시오.

형식	바이너리/텍스트	사람이 읽을 수 있음	사용 예시
JSON	텍스트	예	모든 곳
CSV	텍스트	예	모든 곳
Parquet	바이너리	아니요	Hadoop, Redshift
Avro	바이너리(주)	아니요	Hadoop
Protobuf	바이너리(주)	아니요	Google, TensorFlow
Pickle	바이너리	아니요	Python, PyTorch 직렬화

널리 사용되는 데이터 형식 샘플

JSON

매우 인기가 있습니다. 너무 인기가 많아서 그로 인한 어려움이 모든 곳에서 느껴집니다.
가독성이 좋고 매우 유연합니다.
데이터를 커밋할 때, 데이터를 읽는 측(reader)에서 가정해야 할 스키마도 암묵적으로 커밋하게 됩니다.
이미 저장된 데이터의 스키마를 나중에 변경하는 것은 매우 고통스럽습니다.

텍스트 vs 바이너리 형식

텍스트 형식은 사람이 읽을 수 있지만 크기가 더 큽니다. 이는 전송 및 검색이 더 느리다는 것을 의미합니다.
바이너리 형식은 더 압축적이지만 읽을 수 없습니다. 압축률이 높다는 것은 더 빠른 전송, 더 빠른 검색 및 더 작은 디스크 공간 차지를 의미합니다.

행 우선(Row-major) vs 열 우선(Column-major) 형식

행 우선(Row-major):
- CSV는 행 우선 형식입니다. 특정 샘플(example)의 모든 피처(feature)를 가져오기는 매우 쉽지만, 단일 피처의 모든 값을 가져오기는 매우 어렵습니다.
- 행 우선 형식은 쓰기(write) 작업이 잦을 때 더 좋습니다. 대부분의 소비자 애플리케이션은 많은 쓰기 작업을 필요로 합니다.
열 우선(Column-major):
- 단일 피처에 대한 모든 값이 함께 저장됩니다. 단일 피처의 모든 값을 검색하기는 매우 쉽지만, 단일 샘플에 대한 모든 피처를 검색하기는 어렵습니다.
- 열 우선 형식은 열 단위 읽기(read) 작업을 많이 할 때 더 좋습니다. 단일 피처의 모든 값을 검색하는 것은 ML에서 매우 일반적인 작업입니다.
Pandas vs NumPy
- Pandas는 종종 오해를 받습니다. Pandas는 열 우선 형식을 기반으로 구축되었습니다. Pandas는 행 반복(row iteration)을 위해 만들어지지 않았기 때문에 이 작업은 매우 느립니다.
- NumPy에서는 ndarray에서 메모리 저장 순서(major order)를 지정할 수 있지만 기본적으로는 행 우선입니다.

데이터 모델

SQL vs NoSQL 데이터 모델은 잘 문서화된 주제이므로 깊게 다루지 않겠습니다. 핵심 데이터 모델은 다음과 같습니다.

관계형 데이터 모델(Relational data models): 스키마가 사전에 결정됩니다.
NoSQL 데이터 모델: 사전에 결정된 스키마가 없습니다. 스키마를 가정해야 하는 책임은 데이터를 읽는 애플리케이션으로 넘어갑니다.
- 문서 모델(Document Model)
- 그래프 모델(Graph Models)

스키마가 없는(schema-less) 데이터 모델 같은 것은 없다는 점에 유의하십시오. 누군가는 항상 데이터의 스키마를 가정해야 합니다. 차이점은 쓰기 시점(write time)에 스키마를 인지해야 하는지, 아니면 읽기 시점(read time)에 인지해야 하는지입니다.

정형 데이터(Structured data)	비정형 데이터(Unstructured data)
스키마가 명확하게 정의됨	데이터가 스키마를 따를 필요가 없음
여러 조인(join)이 포함되면 읽기가 느릴 수 있음. 쓰기는 데이터를 스키마에 맞게 변환해야 함. 임의의 검색 및 분석이 쉬움.	쓰기가 간단함. 스키마 준수가 필요 없음. 함께 저장된 데이터(예: 동일한 키 하에)의 읽기는 빠름. 임의의 검색 및 분석이 어려움. 데이터를 저장하는 방법을 결정할 때 액세스 패턴에 대해 생각해야 함.
기존 데이터를 새 스키마로 이관(porting)해야 하므로 스키마 변경이 어려움.	스키마 변경 시 데이터 마이그레이션에 대해 걱정할 필요가 없음. 대신 읽기 시에 이 문제를 걱정해야 함. 왜냐하면 데이터를 읽는 측(reader)이 모든 스키마 버전을 처리할 수 있어야 하기 때문임.
처리되어 바로 사용할 수 있는 형식의 정형 데이터 저장소를 데이터 웨어하우스(data warehouse)라고 함.	원시(raw) 비정형 데이터를 저장하는 데 사용되는 저장소를 데이터 레이크(data lake)라고 함. 이 데이터는 사용 준비가 되기 전에 처리되어야 함.

데이터 웨어하우스 VS 데이터 레이크 주제에 대한 자세한 내용은 ETL 섹션에 있습니다.

데이터베이스 엔진

일반적으로 데이터베이스는 트랜잭션 처리(즉, 온라인 트랜잭션 처리 OLTP) 또는 분석 처리(즉, 온라인 분석 처리 OLAP)에 최적화되어 있습니다.
OLTP 데이터베이스는 일반적으로 데이터 무결성, 신뢰성 및 대용량 트랜잭션 작업에 매우 뛰어난 ACID 데이터베이스입니다. 또한 일반적으로 단일 행과 관련된 작업이 매우 효율적인 행 우선 데이터베이스입니다.
- 전통적인 OLTP 데이터베이스는 여러 행에 걸쳐 열의 데이터를 집계해야 하는 분석적 질문에 답하는 데는 취약합니다. 예: "SF에서 9월의 모든 차량 공유 평균 가격은 얼마인가?"
OLAP 데이터베이스는 위의 문제를 해결하기 위해 설계되었으며 임의의 행 간 집계 쿼리에 매우 효율적입니다.
- 그러나 반대로 OLAP 데이터베이스는 단일 행 작업, 대용량 작업에 취약하므로 소비자 애플리케이션용 DB와 같은 온라인 트랜잭션 작업에는 좋은 솔루션이 아닙니다.
OLTP vs OLAP 구분은 점점 덜 중요해지고 있습니다.
- 1. 기술이 향상되어 이제 분석 쿼리에도 능한 트랜잭션 데이터베이스(예: CockroachDB)가 있고, 그 반대(예: Apache Iceberg 또는 DuckDB)도 마찬가지입니다.
- 2. 전통적인 데이터베이스 엔진 패러다임은 데이터 저장소와 데이터 처리가 결합(coupled)된 구조였습니다. 이는 데이터베이스 엔진이 데이터가 저장되는 방식과 데이터가 읽히고 처리되는 방식 모두를 다룬다는 것을 의미합니다. 만약 다른 유형의 처리가 필요했다면, 해당 유형의 처리에 최적화된 다른 데이터베이스 엔진으로 데이터를 복제해야만 했습니다. 저장소와 처리(즉, 컴퓨팅)를 분리(decouples)하는 새로운 패러다임이 매우 인기를 얻게 되었습니다. 이는 데이터가 다양한 유형의 쿼리에 최적화된 여러 처리 레이어(processing layers)를 위에 둔 채 동일한 장소에 저장될 수 있음을 의미합니다. BigQuery, Snowflake, Teradata는 모두 이러한 분리된 패러다임을 사용할 수 있는 DB의 예입니다. 2022년 6월 기준, 이 제공업체 중 어느 곳도 OLTP용으로 자사 DB를 사용하는 것을 권장하지 않습니다.

데이터 처리 (ETL)

다양한 데이터 소스에서 추출(Extract)하고, 원하는 형식으로 변환(Transform)하며, 변환된 데이터를 원하는 대상(예: 데이터베이스, 파일 또는 데이터 웨어하우스)으로 로드(Load)합니다.

추출(Extracting) 단계

데이터를 검증하고 요구 사항을 충족하지 않는 것은 모두 거부하십시오. 초기에 검증하고 거부하면 후속 단계에서 많은 작업을 절약할 수 있습니다.
많은 데이터가 거부되면 소스에 알려야 할 수도 있습니다.

변환(Transform) 단계

여러 소스의 데이터를 조인(Join)합니다.
값과 범위를 표준화합니다. 예를 들어, "Male"과 "Female" vs "M"과 "F"를 통일합니다.
추가 검증, 전치(transpose), 중복 제거(deduplicate), 정렬, 집계(aggregate), 새로운 피처를 파생합니다(derive new features).

로드(Load) 단계

변환된 데이터를 대상 목적지에 어떻게, 그리고 얼마나 자주 로드할 것인지 결정합니다.

데이터 레이크의 흥망성쇠

데이터를 정형화된 형식으로 유지하는 데 어려움을 겪으면서, 일부 기업들은 다음과 같은 아이디어를 냈습니다: "스키마 변경에 대처할 필요가 없도록 모든 원시 데이터를 그냥 데이터 레이크에 저장하면 어떨까? 데이터가 필요한 애플리케이션은 그냥 거기서 원시 데이터를 꺼내어 처리하면 된다." 이는 때때로 추출, 로드, 변환(ELT)이라고도 불립니다.
이 패러다임은 원하는 데이터를 얻기 위해 방대한 양의 원시 데이터를 검색하는 것이 매우 비효율적이기 때문에 인기를 잃어가고 있습니다. 또한 데이터를 읽는 측(reader)이 다양한 원시 데이터 형식의 암묵적인 스키마를 따라잡기가 매우 어렵습니다.
하이브리드 데이터 레이크 + 데이터 웨어하우스 솔루션이 등장하기 시작했으며, 기업들에게 두 가지 옵션을 모두 제공합니다. Databricks와 Snowflake 모두 하이브리드 솔루션을 제공합니다.

데이터 흐름의 방식

메모리를 공유하지 않는(메모리가 분리된) 서로 다른 프로세스 간에 데이터를 어떻게 전달할까요?

데이터베이스를 통한 데이터 전달

프로세스 A가 데이터베이스에 데이터를 쓰고, 프로세스 B가 동일한 데이터베이스에서 데이터를 읽습니다.
이 방식의 두 가지 문제점:
- 두 프로세스가 동일한 DB에 연결되고 스키마를 공유해야 합니다. 예를 들어 DB가 서로 다른 회사 소유인 경우에는 이것이 불가능합니다.
- 여러 프로세스가 동일한 DB에서 읽고 쓰면 쿼리가 느려질 수 있습니다. 이는 지연 시간에 민감한 앱(즉, 거의 모든 소비자 대상 앱)에는 적합하지 않습니다.

서비스를 통한 동기식 데이터 전달

API 호출(REST 또는 RPC)을 통한 데이터 전달. 마이크로서비스 아키텍처에서 일반적입니다.
서로 다른 회사의 서비스 간에도 데이터 전달을 허용합니다.
이 방식의 문제점:
- 복잡한 호출 그래프(call graph)가 쉽게 만들어져 신뢰성 문제를 야기할 수 있습니다. 서비스 하나가 다운되면, 그와 연결된 많은 서비스가 함께 다운됩니다.
- 네트워크를 통한 데이터 전달은 전체 시스템을 느리게 할 수 있습니다.

서로 의존하는 단 3개의 서비스만으로도 복잡한 호출 그래프가 생성될 수 있습니다.

실시간 전송(이벤트)을 통한 데이터 전달

요청 기반(Request-driven) 아키텍처는 데이터보다 로직에 더 많이 의존하는 시스템에 잘 작동합니다. 이벤트 기반(Event-driven) 아키키처는 데이터 중심적인(data-heavy) 시스템에 더 잘 작동합니다. 이것이 실시간 전송이 프로덕션 환경의 ML에서 매우 일반적인 이유입니다.
실시간 전송의 가장 일반적인 두 하위 유형은 pub-sub(발행-구독)과 메시지 큐(message queues)입니다.
Pub-sub: 서비스가 토픽(topic)에 이벤트를 발행(publish)합니다. 데이터를 생성하는 서비스는 누가 그것을 소비(consume)할지에 대해 신경 쓰지 않습니다. Kafka와 Kinesis가 그 예입니다.
메시지 큐: 메시지(즉, 이벤트)는 종종 의도된 소비자(consumer)를 갖습니다. 메시지 큐는 메시지를 올바른 소비자에게 전달하는 책임을 집니다. RocketMQ와 RabbitMQ가 그 예입니다.

배치 처리(Batch Processing) vs 스트림 처리(Stream Processing)

ML 프로덕션 시스템에서의 데이터 배치 처리는 일반적으로 데이터 웨어하우스나 데이터 레이크에 저장된 비실시간 데이터(즉, 과거 데이터)를 사용하여 피처를 계산하는 데 사용됩니다.
- 이러한 피처는 실시간으로 변경될 필요가 없기 때문에 종종 정적 피처(static features) 또는 배치 피처(batch features)라고 불립니다. 예를 들어, 평균 드라이버 평점을 하루에 한 번 재계산하는 것은 괜찮습니다.
- MapReduce와 Spark는 배치 처리 엔진의 예입니다.
ML 프로덕션 시스템에서의 데이터 스트림 처리는 값이 빠르게 변하거나 실시간으로 필요한 피처를 계산하는 데 사용됩니다. 데이터가 데이터 웨어하우스에 도착하고 배치 작업이 이를 선택하여 계산할 때까지 기다릴 수 없으므로, 실시간 이벤트를 기반으로 계산을 수행해야 합니다.
- 이러한 피처는 종종 스트리밍 피처(streaming features) 또는 동적 피처(dynamic features)라고 불립니다.
- Apache Flink, KSQL, Spark Streaming은 스트림 처리 기술의 예입니다.
프로덕션 환경의 ML 시스템은 두 가지 유형의 데이터 처리를 모두 필요로 할 수 있습니다.

4 - 학습 데이터

이 장에서는 좋은 학습 데이터를 만들기 위한 다양한 기술을 다룹니다.

학습용 데이터 선택을 위한 샘플링 기술
학습 데이터의 일반적인 문제 해결 방법:
- 레이블링(Labelling) 문제
- 클래스 불균형(Class imbalance) 문제
- 데이터 부족 문제 및 데이터 증강(data augmentation)

학습 데이터를 만드는 것은 반복적인 과정입니다. 프로젝트 라이프사이클에 걸쳐 모델이 발전함에 따라, 학습 데이터도 함께 발전할 것입니다.

샘플링(Sampling)

샘플링은 워크플로우의 여러 단계에서 발생합니다. 예를 들면:

좋은 학습 데이터를 만들기 위해 가능한 모든 실제 데이터에서 샘플링합니다.
일관된 학습(train), 테스트(test), 검증(validation) 세트를 만들기 위해 주어진 데이터셋에서 샘플링합니다.
모니터링 목적으로 ML 시스템을 통해 흐르는 모든 가능한 이벤트에서 샘플링합니다.

비확률적 샘플링(Non-probability Sampling)

비확률적 샘플링은 나쁜 아이디어입니다. 선택된 샘플은 실제 데이터를 대표하지 않으므로 선택 편향(selection biases)으로 가득 차 있습니다. 이는 ML 모델의 성능을 저하시키고 불공정하게 만듭니다.

여기서는 여러분이 식별하고 피할 수 있도록 일반적으로 사용되는 몇 가지 비확률적 샘플링 방법을 설명합니다.

편의 샘플링(Convenience Sampling)

데이터의 가용성에 따라 샘플을 선택합니다. 이 샘플링 방법은 이름 그대로 편리하기 때문에 인기가 있습니다.

눈덩이 샘플링(Snowball Sampling)

기존 샘플을 기반으로 미래의 샘플을 선택합니다. 예를 들어, 초기 시드(seed) 계정 세트로 시작하여 그들이 팔로우하는 사람들을 스크래핑함으로써 트위터 계정을 점진적으로 수집합니다.

판단 샘플링(Judgement Sampling)

전문가가 어떤 샘플을 포함할지 결정합니다.

할당 샘플링(Quota Sampling)

무작위화(randomisation) 없이 특정 데이터 조각(slice)에 대한 할당량을 기반으로 샘플을 선택합니다. 예를 들어, 실제 연령 분포와 관계없이 30세 미만, 30세에서 60세 사이, 60세 이상 각 연령 그룹에서 100개의 응답을 강제로 선택합니다.

확률적 샘플링(Probabilistic Sampling)

확률적 샘플링은 좋은 아이디어입니다. 사용할 특정 샘플링 유형은 사용 사례에 따라 다릅니다.

단순 무작위 샘플링(Simple random sampling)

각 샘플에 p%의 선택 확률을 부여하여 모집단의 p%를 선택합니다.

장점:
- 구현이 매우 간단합니다.
- 샘플링된 데이터가 모집단의 분포를 따릅니다.
단점:
- 희귀 클래스(rare classes)가 제외될 확률이 높습니다. 이렇게 샘플링된 데이터로 학습된 모델은 희귀 클래스가 존재하지 않는다고 생각할 수 있습니다.

층화 샘플링(Stratified sampling)

모집단을 관심 있는 그룹으로 나눈 다음 각 그룹의 항목에 p%의 선택 확률을 부여하여 샘플링합니다.

장점:
- 레이블이 아무리 희귀하더라도 해당 샘플이 샘플에 포함되도록 보장합니다.
단점:
- 샘플을 그룹으로 깔끔하게 분리할 수 없는 경우(예: 다중 레이블(multi-label) 작업) 사용할 수 없습니다.

가중 샘플링(Weighted sampling)

각 샘플에 서로 다른 선택 확률을 부여합니다. 예를 들어, 레이블 A를 가진 모든 요소는 50%의 확률을, B는 30%의 확률을, C는 20%의 확률을 갖게 합니다.

Python에서는 random.choice의 weights를 사용할 수 있습니다.

import random 
random.choices(
    population=[1, 2, 3, 4, 100, 1000],
    weights=[0.2, 0.2, 0.2, 0.2, 0.1, 0.1],
    k=2
)

장점:
- 도메인 지식(domain knowledge)을 ML 시스템에 통합하는 데 사용할 수 있습니다. 예를 들어, 더 최신 데이터가 더 가치 있다는 것을 안다면 더 높은 가중치를 부여합니다.
- 사용 가능한 데이터의 잘못된 분포를 수정하고 샘플링된 데이터가 실제 분포와 일치하도록 만드는 데 사용할 수 있습니다. 예를 들어, 사용 가능한 데이터가 여성 75%, 남성 25% 레이블을 가지고 있지만 실제 분포는 50/50%라는 것을 안다고 가정해 봅시다. 이를 수정하기 위해 남성 예제에 더 많은 가중치를 부여하는 가중 샘플링을 사용하여 분포를 바로잡을 수 있습니다.
단점:
- 신중하게 사용하지 않으면 데이터에 편향을 심을 수 있습니다.
참고:
- 가중 샘플링(Weighted sampling)은 샘플 가중치 부여(sample weighting)와 다릅니다. 샘플 가중치는 학습 중에 특정 샘플이 다른 샘플보다 알고리즘의 손실 함수(loss function)에 더 많은 영향을 미치도록 하는 데 사용됩니다. 결정 경계(decision boundary)에 가까운 샘플에 더 높은 학습 가중치를 부여하면 알고리즘이 결정 경계를 더 잘 학습하는 데 도움이 될 수 있습니다.
- #todo : 가중 샘플링이 클래스 불균형과 어떤 관련이 있는가?

스트림 샘플링을 위한 저수지 샘플링(Reservoir sampling)

데이터 스트림에서 연속적인 샘플링 데이터셋을 만드는 데는 다음과 같은 과제가 있습니다.

모집단의 크기를 미리 알 수 없습니다. 하지만 좋은 관행에 따라, 데이터셋의 모든 샘플이 동일한 선택 확률을 갖도록 하고 싶을 것입니다.
샘플 데이터셋에 새 샘플을 영원히 추가할 수 없습니다. 어느 시점에는 메모리가 부족해질 것입니다.
언제든지 연속 샘플링을 중지할 수 있어야 하며, 데이터셋의 각 요소는 올바른 확률로 샘플링되었어야 합니다.

저수지 샘플링 알고리즘은 위에서 언급한 과제들을 극복하면서 k개 요소의 데이터셋을 지속적으로 샘플링할 수 있게 해줍니다. k는 사용 가능한 메모리 양에 의해 제한됩니다.

처음 k개의 요소를 저수지(reservoir)에 넣습니다.
들어오는 각 n번째 요소에 대해 1 ≤ i ≤ n인 난수 i를 생성합니다.
1 ≤ i ≤ k이면: 저수지의 i번째 요소를 n번째 요소로 교체합니다. 그렇지 않으면 아무것도 하지 않습니다.

레이블링(Labelling)

좋은 레이블링은 매우 중요한 부분입니다. 일부 회사(예: Tesla)는 사내에 레이블링 팀을 두기도 합니다.

수동 레이블링은 여러 문제점을 안고 있으며, 그중 다수는 좋은 해결책이 없습니다. 만약 문제가 허락한다면, 자연 레이블을 사용하거나 레이블 부족 처리하기에서 설명하는 기술을 사용하여 이러한 문제를 우회하십시오.

수동 레이블(Hand labels)

문제 1: 수동 레이블링은 비쌉니다. 특히 레이블을 생성하기 위해 해당 분야 전문가(예: X-레이를 분류하는 의사)가 필요한 경우 더욱 그렇습니다.
문제 2: 수동 레이블링은 데이터 프라이버시에 위협이 됩니다. 누군가가 집계되지 않은(non-aggregated) 데이터에 접근해야 합니다. 이로 인해 레이블링을 아웃소싱하기가 더 어려워지고 보안 보증 부담이 추가됩니다.
문제 3: 수동 레이블링은 느립니다. 느린 레이블링은 느린 반복 속도로 이어지고, 이는 다시 모델이 변화하는 환경에 덜 적응하게 만듭니다. 레이블링 프로세스가 오래 걸릴수록 기존 모델 성능은 더 저하됩니다.
문제 4: 레이블 다중성(Label multiplicity): 서로 다른 작업자(annotators)가 서로 다른 데이터 소스의 데이터에 레이블을 지정하게 하면 레이블 모호성(label ambiguity)이 발생할 수 있습니다.
- 작업자 간의 의견 불일치는 매우 흔합니다.
- 요구되는 도메인 전문 지식 수준이 높을수록 의견 불일치 가능성이 커집니다.
- 부분적 해결책: 이를 최소화하는 가장 좋은 방법은 작업자에게 명확한 문제 정의와 지침을 제공하는 데 세심한 주의를 기울이는 것입니다.
문제 5: 데이터 계보(Data lineage)가 잊히는 경향이 있습니다. 예를 들어, 레이블 품질이 좋은 10만 개의 샘플을 사용하여 좋은 모델을 학습시켰다고 가정해 봅시다. 그런 다음 레이블링을 위해 100만 개의 샘플을 추가로 아웃소싱했습니다. 불행히도 아웃소싱된 레이블의 품질은 낮았습니다(하지만 당신은 그것을 모릅니다). 그런 다음 데이터를 혼합하여 110만 개의 샘플로 동일한 모델을 학습시킵니다. 마지막으로, 품질이 낮은 레이블링의 결과로 모델 성능이 저하되었음을 발견합니다. 설상가상으로 데이터를 혼합했기 때문에 이로부터 복구할 수 없습니다.
- 해결책: 데이터 계보 관행을 사용하십시오. 각 데이터 샘플의 출처와 해당 레이블의 출처를 추적하십시오. 이를 추적하면 데이터 문제를 디버깅하는 데 도움이 될 수 있습니다.

자연 레이블(Natural labels)

어떤 문제들은 시스템에 의해 자동으로 파생되거나 근사(approximated)될 수 있는 자연적인 정답 레이블(natural ground truth labels)을 가지고 있습니다.

어떤 문제들은 다른 문제들보다 더 강력한 자연 레이블을 가집니다.
레이블 근사는 명시적(explicit) 또는 암묵적(implicit) 레이블링을 사용하여 수행될 수 있습니다. 명시적 레이블링은 사용자에게 어떤 방식으로든 레이블을 제공하도록 요청한다는 것을 의미합니다.
강력한 자연 레이블의 예:
- 구글 맵의 도착 예정 시간(ETA)은 실제 이동 시간으로 검증될 수 있습니다.
- 주가 예측은 검증될 수 있습니다.
약한 자연 레이블의 예 (일반적으로 근사가 필요함):
- 추천 시스템은 일반적으로 제안이 받아들여졌는지(긍정적 레이블) 또는 정의된 시간 창 내에 받아들여지지 않았는지(암묵적 부정적 레이블)를 기록함으로써 자연 레이블이 근사되도록 허용합니다.
- 뉴스피드 랭킹 문제에서, 자연 레이블은 '좋아요'와 '싫어요' 버튼을 추가함으로써 근사될 수 있습니다. 이는 명시적 근사의 경우입니다.
기업들은 ML을 시작할 때 자연 레이블이 있는 문제에 대해 작업하는 것을 선택하는 경향이 있습니다. 왜냐하면 이러한 문제가 더 다루기 쉽고 비용이 적게 드는 경향이 있기 때문입니다.

피드백 루프 길이(Feedback loop length)

자연 레이블이 있는 문제에서, 피드백 루프는 예측이 제공된 시점부터 해당 샘플의 정답 레이블을 파생하거나 근사할 수 있을 때까지의 시간입니다.

정답 레이블이 몇 분 내에 사용 가능하다면, 이는 짧은 피드백 루프으로 간주됩니다.
피드백 루프가 짧은 문제는 작업하기가 더 쉽고, 변화하는 요구사항과 데이터 분포에 더 잘 적응하는 시스템을 생성합니다.
- 이는 모든 문제에 해당됩니다. 레이블을 더 빨리 얻을 수 있다면, 당신의 삶은 더 쉬워질 것입니다.

강력한 레이블이 있는 문제

강력한 자연 레이블이 있는 문제를 다룰 때, 이 루프의 길이는 대개 문제의 본질에 의해 결정됩니다. 예를 들면:

주식 예측은 몇 분 내에 검증될 수 있습니다.
구글 맵의 ETA 예측은 시간 단위로 검증될 수 있습니다.
사기 탐지(Fraud detection)는 거래가 발생한 지 몇 달 후에 분쟁 프로세스가 완전히 종료되기 때문에 긴 자연 피드백 루프를 가집니다.

레이블 근사가 필요한 문제

레이블을 근사하려는 시도는 일반적으로 몇 가지 트레이드오프를 고려한 결정이 필요합니다.

근사를 위한 사용자 피드백 유형 선택

사용자 여정(user journey)의 여러 지점에서 다양한 신호를 사용하여 레이블을 근사할 수 있습니다. 신호마다 양(volume), 강도(strength) 및 루프 길이(loop length)가 다릅니다.

예를 들어, 제품 추천 시스템에서 레이블을 생성하기 위해 "제품을 클릭함"을 사용할 수 있습니다. 대안으로 "제품을 구매함" 신호를 사용할 수 있습니다. 클릭은 더 자주 발생하고(즉, 더 많은 데이터) 더 짧은 피드백 루프를 갖지만, 구매는 훨씬 더 가치 있는 신호입니다.

여기에는 정답이 없습니다. 트레이드오프를 따져보고 결정을 내려야 합니다.

암묵적 근사를 위한 시간 창(time window) 선택

어떤 일이 일어나지 않았기 때문에 암묵적으로 레이블을 추론해야 하는 문제는 매우 흔합니다. 이러한 경우, 우리는 보통 부정적인 레이블이 할당되는 시간 창을 선택해야 합니다(예: 사용자가 추천된 영화를 보지 않음).

더 짧은 시간 창 = 더 짧은 피드백 루프 + 목표 행동이 임의의 시간 창 제한 이후에 발생했기 때문에 더 높은 오분류(mislabeling) 가능성.

레이블 부족 처리하기(Handling the Lack of Labels)

이 섹션에서는 충분한 고품질 레이블을 얻는 어려움을 해결하기 위해 개발된 4가지 범주의 기술을 다룹니다. 이들 중 하나 또는 여러 개를 동시에 사용할 수 있습니다.

개요:

약 지도(Weak Supervision) 레이블링

이 유튜브 비디오는 매우 흥미로운 일부 반복적인 방식을 포함하여 약 지도를 위한 여러 가지 방식(arrangements)을 설명합니다.

https://www.youtube.com/watch?v=SS9fvo8mR9Y

TL/DR(요약)은 다음과 같습니다.

약 지도의 아이디어는, 비록 학습에 사용하는 레이블이 다소 노이즈가 있더라도, 대량의 데이터를 사용하여 학습된 시스템이 작지만 완벽한 데이터셋을 가진 모델보다 성능이 더 좋은 경향이 있다는 가정에 의해 동기 부여됩니다. 이는 특히 모델이 동일한 모델의 이전 반복이나 전이 학습 모델(예: 언어 모델)과 같은 사전 학습된 모델에서 재학습되거나 파인 튜닝(fine-tune)되는 경우에 더욱 그렇습니다.

개략적인 단계는 다음과 같습니다.

당신(또는 해당 분야 전문가)이 몇 가지 단순화를 사용하여 자동으로 데이터에 레이블을 지정하는 일련의 휴리스틱(heuristics)을 개발합니다. 이러한 각 휴리스틱을 labelling_function (LF) 내부에 래핑합니다. 서로 다른 휴리스틱이 서로 모순될 수 있으며, 일부는 특정 샘플에 레이블을 지정하는 데 다른 것보다 더 나을 수 있습니다. 이 모든 것은 괜찮습니다.
```
def labelling_function(example_note):
    if "pneumonia" in example_note:
  return true
```
레이블을 지정하려는 데이터에 레이블링 함수 세트를 적용합니다.

몇 가지 유형의 레이블링 함수:
- 키워드 휴리스틱: 샘플에 키워드가 있는가?
- 정규 표현식: 샘플이 정규식과 일치하는가?
- 데이터베이스 조회: 문자열에 위험한 질병 목록과 일치하는 문자열이 포함되어 있는가?
- 이전에 학습된 모델의 출력. 이것은 소수의 수동 레이블 데이터로 학습된 간단한 모델이거나 이전 반복 모델의 출력일 수 있습니다.

Snorkel과 같은 도구는 레이블링 함수에 의해 생성된 모든 다른 "레이블 투표"를 받아들여 그들 사이의 상관 관계를 학습하고 레이블의 확률 벡터(예: [80% 검은색, 10% 녹색, 10% 흰색])를 출력할 수 있습니다. 본질적으로 Snorkel이 하는 일은 레이블 가능성(label likelihoods)을 얻기 위해 모든 LF의 투표를 결합하고, 노이즈를 제거하고, 가중치를 재조정하는 것입니다.
그런 다음 출력된 확률 벡터를 사용하여 큰 모델을 학습시킵니다.

장점:
- 수동 레이블 불필요: 이론적으로는 약 지도에 수동 레이블이 필요하지 않습니다. 그러나 LF의 정확도를 확인하기 위해 소량의 수동 레이블 샘플을 갖는 것이 권장됩니다.
- 프라이버시: 약 지도는 데이터에 엄격한 프라이버시 요구 사항이 있을 때 매우 유용합니다. LF를 생성하기 위해 몇 개의 샘플만 보면 되며, 나머지는 자동으로 수행될 수 있습니다.
- 속도: LF로 많은 데이터에 레이블을 지정하는 것은 (수동 레이블링에 비해) 매우 빠릅니다.
- 적응성: 변경 사항이 발생하면, LF를 변경하고 모든 데이터에 다시 적용하기만 하면 됩니다. 수동 레이블링을 했다면 전체 재레이블링이 필요할 것입니다.
- LF를 사용하면 해당 분야의 전문 지식을 통합하고 그것을 버전 관리하고, 재사용하고, 공유할 수 있습니다.
단점:
- 너무 노이즈가 많은 레이블: 때때로 레이블이 너무 노이즈가 많아 유용하지 않을 수 있습니다. 설상가상으로, 수동으로 레이블이 지정된 작은 데이터 세트가 없다면, 노이즈가 있는 레이블이 얼마나 나쁜지 알 수 없습니다.

준지도 학습(Semi-Supervision)

개념적으로, 준지도 학습은 초기 레이블 세트를 시드(seed)로 사용하여 어떤 방법을 통해 레이블이 없는 더 많은 데이터에 레이블을 지정하는 것입니다.

다음은 준지도 학습 구현의 3가지 예입니다.

자가 학습(Self-training): 레이블이 지정된 데이터 시드를 사용하여 모델을 학습시킵니다 → 해당 모델을 사용하여 레이블이 없는 일부 데이터에 대한 레이블을 생성합니다 → 원본 확률(raw probability)이 높은 샘플을 학습 세트에 추가합니다 → 모델 성능에 만족할 때까지 이를 반복합니다.
클러스터링을 통한 레이블링: 레이블이 지정된 데이터 포인트와 가깝게 클러스터링되는 레이블이 없는 데이터 포인트는 동일한 레이블을 공유한다고 가정합니다.
교란(Perturbation): 샘플에 대한 작은 교란(perturbation)이 레이블을 변경해서는 안 된다고 가정합니다. 따라서 학습 인스턴스에 작은 교란을 적용하여 새로운 학습 인스턴스를 생성합니다. 이것은 데이터 증강의 한 형태로도 간주될 수 있습니다.

전이 학습(Transfer learning)

한 작업을 위해 개발된 모델이 두 번째 작업의 모델을 위한 시작점으로 재사용됩니다. 첫 번째 작업은 대개 저렴하고 풍부한 학습 데이터를 가지고 있습니다.

전이 학습은 대규모 신경망 모델이 작업 변경에 매우 견고(robust)한 경향이 있다는 아이디어에 기반합니다. 예를 들어, 위키피디아에서 학습된 영어 언어 모델은 NLP 작업이 위키피디아와 아무 관련이 없더라도 유용할 것입니다.
대규모 말뭉치(corpus)로 구축된 언어 모델(예: BERT)은 전이 학습의 일반적인 예입니다.
작업에 맞게 기본 모델을 파인 튜닝(fine-tuning)하는 것은, 예를 들어 자신의 작업을 위한 자신의 데이터로 모델의 전체 또는 일부를 계속 학습시키는 것과 같이 기본 모델을 약간 변경하는 것을 의미할 수 있습니다.
전이 학습은 학습하는 데 수천만 달러가 들었을 수도 있는 모델을 무료로 사용할 수 있게 해주기 때문에 많은 관심을 받았습니다.
일반적으로 사전 학습된 기본 모델이 클수록 다운스트림 작업에서의 성능이 더 좋습니다.

능동 학습(Active learning)

능동 학습은 다른 샘플보다 레이블을 지정하는 데 더 가치 있는 샘플이 있다는 아이디어에 기반합니다. 예를 들어, 결정 경계(decision boundary)에 더 가까운 샘플은 모델이 경계를 더 잘 학습할 수 있게 해주기 때문에 더 가치가 있습니다.

능동 학습에서는 모델이 레이블을 지정해야 할 샘플을 자동으로 알려줍니다. 능동 학습 구현의 몇 가지 예는 다음과 같습니다.

레이블이 없는 데이터 세트에 모델을 적용하고, 모델이 확실성이 가장 낮은(예: 원본 확률이 낮은) 샘플을 선택하여 레이블을 지정하고 학습 데이터에 추가하도록 합니다.
레이블이 없는 데이터 세트에 앙상블 모델을 적용하고, 합의(consensus)가 가장 적은 샘플을 선택하여 레이블을 지정합니다. 앙상블은 서로 다른 데이터 조각으로 학습된 모델, 또는 서로 다른 하이퍼파라미터로 학습된 모델, 또는 완전히 다른 모델로 구성될 수 있습니다.
일부 능동 학습 기술은 모델이 불확실성 영역에 있는 샘플을 합성(synthesise)하도록 허용합니다.
일부 회사는 프로덕션에서 평가되는 데이터로 능동 학습을 적용합니다. 프로덕션에서 실행 중인 모델이 방금 본 샘플에 대해 그다지 확신하지 못하는 경우, 해당 샘플은 레이블링 대상으로 플래그 지정됩니다.

클래스 불균형(Class Imbalance)

분류 작업에서의 클래스 불균형: 학습 데이터의 각 클래스에 있는 샘플 수에 상당한 차이가 있을 때 발생합니다.
회귀 작업에서의 클래스 불균형: 예: 병원비 비용을 추정하는 작업의 경우, 수집된 데이터의 대부분이 100달러에서 1000달러 범위에 속하고 1만 달러가 넘는 천문학적인 청구서에 대한 데이터는 거의 없습니다. 아무것도 하지 않으면, 모델은 높은 청구서 범위에서 매우 틀리는 것을 감수하더라도 데이터가 더 많은 범위를 더 잘 맞추는 경향이 있을 것입니다.

클래스 불균형의 원인

자연적으로 불균형한 문제: 자연적으로 심하게 불균형한 문제는 실제 세계에서 매우 흔합니다(예: 암 탐지, 사기 탐지, 모든 이상 징후 탐지 문제). 문제를 더 어렵게 만드는 것은, 이러한 많은 문제에서 소수 클래스를 올바르게 예측하는 것이 다수 클래스를 예측하는 것보다 훨씬 더 중요하다는 것입니다(예: 암 탐지). 이것이 클래스 불균형의 가장 흔한 원인입니다.
편향된 샘플링으로 인한 불균형: 문제가 자연적으로 심하게 불균형하지 않을 수도 있지만, 데이터를 샘플링하는 방식이 데이터를 불균형하게 보이게 만들 수 있습니다. 예를 들어, 트윗이 스팸인지 식별하는 모델을 만들고 싶다고 상상해 보십시오. 직접 데이터셋을 구축하기 위해 공개 트위터를 스크래핑하면 아주 적은 비율의 트윗만이 스팸임을 발견할 수 있습니다. 이것은 실제 분포가 아닐 수도 있습니다. 대부분의 스팸 트윗은 트위터 자체 알고리즘에 의해 공개되기 전에 삭제되기 때문에 데이터가 불균형하게 보이는 것입니다. 샘플링 섹션에는 샘플링의 함정을 피하는 방법에 대한 더 많은 정보가 있습니다.
레이블링 오류로 인한 불균형: 작업자가 지침을 잘못 읽고 한 클래스를 다른 클래스보다 훨씬 적게 사용할 수 있습니다. 이것은 가장 드문 원인입니다.

클래스 불균형이 문제가 되는 이유

아무런 조정도 하지 않으면, ML 알고리즘은 균형 잡힌 데이터셋에서만큼 심하게 불균형한 데이터셋에서는 잘 작동하지 않습니다. 왜 그럴까요?

알고리즘이 소수 클래스에 대해 작동하는 파라미터를 학습하기에 불충분한 신호를 가질 수 있습니다. 소수 클래스에 대한 학습은 퓨샷 학습(few-shot learning) 문제가 됩니다.
알고리즘이 학습 중에 항상 다수 클래스를 반환하는 것과 같은 간단한 휴리스틱을 이용하는 최적이 아닌 솔루션에 머무를(stuck) 수 있습니다.
ML 알고리즘의 기본 동작은 모든 클래스의 오분류를 동일하게 취급하며 학습 중에 클래스 중요도를 인코딩할 방법이 없습니다. 이는 소수 클래스의 오분류가 치명적인 결과를 초래할 수 있는 작업(예: 흉부 X-레이에서의 암 진단)에 문제가 됩니다.

일부 작업은 다른 작업보다 클래스 불균형에 더 민감합니다. 일반적으로 모델이 복잡할수록 불균형에 더 민감합니다. 그 반대도 마찬가지입니다. 단순하고 선형적으로 분리 가능한 문제는 클래스 불균형에 민감하지 않습니다.

클래스 불균형 처리하기

어떤 사람들은 그것이 실제 데이터의 모습이라면 클래스 불균형을 "고치려고" 해서는 안 된다고 주장할 수 있습니다. 그들은 모델이 그 불균형을 처리하는 법을 배워야 한다고 주장합니다. 그러나 이러한 조건에서 좋은 성능을 내는 모델을 개발하는 것은 어려울 수 있으므로, 우리는 여전히 특별한 학습 기술에 의존해야 합니다.

클래스 불균형을 다루는 3가지 상위 수준 접근 방식이 있습니다. (1) 올바른 지표 선택하기, (2) 데이터 수준 방법, (3) 알고리즘 수준 방법.

올바른 지표 선택하기

클래스 불균형이 있을 때 모든 클래스를 동일하게 취급하는 지표를 사용하는 것은 나쁜 생각입니다. 왜냐하면 지표가 다수 클래스에 의해 주도될 것이기 때문입니다. 이것은 다수 클래스가 우리가 신경 쓰는 클래스가 아닐 때 특히 나쁩니다. 나쁜 지표의 전형적인 경우는 전체 정확도(accuracy)를 사용하는 것입니다. 예를 들어, X-레이의 90%를 올바르게 분류할 수 있는 암(CANCER) 탐지 모델은 대부분의 샘플이 암이 아니기(NON-CANCER) 때문에, 암 탐지 능력에 대해 거의 알려주지 못합니다.

이에 대한 해결책은 우리가 신경 쓰는 클래스에 초점을 맞춘 클래스별 지표를 사용하는 것입니다. 정밀도(Precision), 재현율(Recall), F1 점수는 모두 사용할 수 있는 클래스별 지표입니다.

임계값 설정(Thresholding)

분류 모델의 출력이 확률과 같은 연속 변수인 경우, 임계값(threshold)을 사용하여 알고리즘의 정밀도와 재현율을 선택할 수 있습니다. 이 선택은 실제로 우리가 중요한 클래스에 얼마나 신경을 쓰는지, 그리고 다른 클래스의 오분류에 대해 얼마나 관대할 수 있는지에 따라 결정됩니다.

이 임계값 선택에 사용되는 두 가지 일반적인 도구는 ROC 곡선과 정밀도-재현율(precision-recall) 곡선입니다.

참고로, 임계값을 사용할 수 있도록 분류 문제를 회귀 문제로 쉽게 프레이밍할 수 있습니다.

데이터 수준 방법: 리샘플링(resampling)

데이터 수준 방법은 불균형을 줄이기 위해 데이터의 원래 분포를 수정합니다. 리샘플링은 이를 위해 사용되는 가장 일반적인 기술 계열입니다. 여기에는 오버샘플링(소수 클래스의 인스턴스 추가)과 언더샘플링(다수 클래스의 인스턴스 제거)이 포함됩니다.

무작위 언더샘플링(Random undersampling): 원하는 균형을 이룰 때까지 다수 클래스에서 무작위로 인스턴스를 제거합니다.
무작위 오버샘플링(Random oversampling): 만족스러운 비율을 얻을 때까지 소수 클래스의 복사본을 무작위로 만듭니다.
토멕 링크(Tomek links): 저차원 데이터의 언더샘플링을 위한 기술입니다. 서로 다른 클래스를 가지면서 서로 가까이 있는 데이터 포인트 쌍을 찾아 다수 클래스의 샘플을 제거합니다.
- 알고리즘이 더 명확한 결정 경계를 학습하는 데 도움이 됩니다.
- 모델이 결정 경계의 미묘한 차이를 배울 기회를 얻지 못하므로 모델의 견고성(robustness)이 떨어집니다.
SMOTE (Synthetic minority oversampling technique): 소수 클래스 샘플들의 볼록(convex, ~선형) 조합을 수행하여 새로운 소수 클래스 샘플을 생성합니다.
토멕 링크, SMOTE 및 더 복잡한 리샘플링 기술은 저차원 데이터에서만 효과적인 경향이 있습니다. 거리 계산에 의존하는 기술은 차원이 높아질수록 계산 비용이 비싸집니다.

리샘플링의 위험

리샘플링된 데이터로 모델을 평가하지 마십시오. 수정된 데이터 분포로 모델을 학습시켰더라도, 모델의 실제 성능을 파악하려면 실제 분포를 따르는 데이터로 모델을 평가해야 합니다.
언더샘플링은 중요한 데이터를 버릴 위험이 있습니다.
오버샘플링은 데이터에 대한 과적합(overfitting)을 조장할 위험이 있습니다. 오버샘플링된 샘플이 복사본일 경우 특히 그렇습니다.

이러한 위험을 완화하는 기술

2단계 학습(Two-phase learning): 먼저 언더샘플링된 균형 잡힌 데이터로 모델을 학습시킵니다. 그런 다음 원본 데이터를 사용하여 학습을 파인 튜닝합니다.
동적 샘플링(Dynamic Sampling): 성능이 낮은 클래스는 오버샘플링하고 성능이 높은 클래스는 언더샘플링합니다. 이는 모델이 이미 알고 있는 것은 덜 보여주고 더 잘 배워야 하는 것은 더 많이 보여주려는 목적을 가집니다.

알고리즘 수준 방법

직관: 손실 함수는 학습 과정을 안내합니다. 우리는 모델이 학습 중에 자동으로 불균형을 처리하도록 돕기 위해 손실 함수를 수정할 수 있습니다.

비용 민감 학습(Cost-sensitive learning)

각 항목 Cij가 클래스 i가 클래스 j로 분류되는 비용인 비용 행렬(cost matrix)을 정의합니다. i=j이면 분류가 올바른 것이며 보통 0의 비용이 사용됩니다. 학습은 손실 최소화를 추구하므로, 학습 과정은 더 비싼 클래스의 오분류에 더 중점을 둘 것입니다.

이러한 프레이밍을 통해 "암(CANCER)을 정상(NORMAL)으로 오분류하는 것이 그 반대보다 20배 더 비용이 많이 든다"와 같은 도메인 지식을 자연스럽게 통합할 수 있습니다.

클래스 균형 손실(Class-balanced loss)

비용 민감 손실과 유사하지만, 오분류의 가중치(또는 비용)가 각 클래스의 샘플 수에 의해 결정됩니다.

가장 기본적인 형태에서, Wi(클래스 i에 대한 가중치)는 1 / N_samples_of_class_i입니다. 더 정교한 접근 방식은 기존 샘플 간의 중복을 고려하고 유효 샘플 수(effective number of samples)에 기반하여 계산할 수 있습니다.

포커스 손실(Focal loss)

직관: 올바른 클래스로의 분류 확률이 낮은 샘플에 더 많은 가중치를 부여하여, 모델이 여전히 분류하기 어려워하는 샘플에 집중하도록 장려합니다. 포커스 손실 방정식은 책을 참조하십시오.

데이터 증강(Data Augmentation)

데이터 증강은 학습 데이터의 양을 늘리는 데 사용되는 기술 계열입니다. 증강된 데이터는 종종 모델을 노이즈와 적대적 공격(adversarial attacks)에 더 견고하게 만드는 데 유용합니다.

적대적 공격은 누군가가 ML 모델을 속여 무언가를 잘못 분류하도록 만들기 위해 프로덕션 샘플을 조작하는 것입니다. 예를 들어, 이미지를 다르게 분류하게 하려고 이미지의 픽셀 몇 개를 변경하는 것입니다. 신경망은 특히 노이즈에 민감합니다.

데이터 증강은 컴퓨터 비전 작업의 표준이며 NLP 작업에서도 인기를 얻고 있습니다. 데이터 증강에는 (1) 레이블을 보존하는 간단한 변환, (2) 교란(perturbation), (3) 데이터 합성(data synthesis)의 세 가지 주요 유형이 있습니다. 각 유형에서 컴퓨터 비전과 NLP의 예를 모두 살펴볼 것입니다.

레이블을 보존하는 간단한 변환(Simple label-preserving transformations)

컴퓨터 비전에서: 레이블을 보존하면서 이미지를 무작위로 수정합니다. 회전, 자르기, 뒤집기, 반전, 이미지 일부 지우기 등을 생각해보십시오.
NLP에서: 문장의 의미를 바꾸지 않는 유사한 단어로 문장의 단어를 교체합니다. 유의어 사전, 워드넷(word net) 또는 유사한 워드 임베딩(word embedding)을 가진 다른 단어를 사용하여 "유사한" 단어를 선택할 수 있습니다.

교란(Perturbation)

컴퓨터 비전에서: 노이즈가 있는 샘플은 무작위 노이즈를 추가하거나 탐색 전략(예: 적대적 증강, Adversarial Augmentation)을 통해 생성될 수 있습니다. 적대적 증강에서는, 알고리즘이 레이블을 변경하기 위해 샘플에 수행해야 하는 최소한의 변경 횟수를 찾습니다. 그런 다음 모델을 더 견고하게 만들기 위해 변경된 샘플을 학습 데이터에 추가합니다.
NLP에서: 단어를 변경하거나 노이즈를 추가하면 문장의 의미가 바뀔 가능성이 높기 때문에 NLP에서는 교란이 덜 일반적입니다.

교란은 준지도 학습 맥락과 오프라인 평가 맥락에서도 사용될 수 있습니다.

데이터 합성(Data synthesis)

컴퓨터 비전에서 일반적인 기술은 서로 다른 레이블을 가진 두 이미지를 결합하여 새 이미지를 생성하는 것입니다. 이를 믹스업(mixup)이라고 합니다. 예를 들어, DOG 레이블이 0이고 CAT 레이블이 1인 경우, 반반씩 섞이고 레이블이 0.5인 믹스업 이미지를 만들 수 있습니다.
NLP에서 문자열 템플릿은 많은 양의 데이터를 저렴하게 생성할 수 있는 훌륭한 방법입니다. 예를 들어, "[LOCATION]에서 [NUMBER] 마일 이내의 [CUISINE] 레스토랑 찾아줘" 템플릿과 CUISINES 데이터베이스, 그리고 NUMBER와 LOCATION에 대한 적절한 파라미터를 사용하면 수천 개의 샘플을 생성할 수 있습니다.
신경망을 사용하여 데이터를 합성하는 것은 현재 흥미로운 연구 분야이지만, 아직 프로덕션 환경에서 인기가 있지는 않습니다.

5 - 피처 엔지니어링 (Feature Engineering)

일단 작동하는 ML 모델을 확보하고 나면, 피처 엔지니어링은 하이퍼파라미터 튜닝이나 영리한 알고리즘 기법을 사용하는 것보다 성능 향상에 가장 크게 기여하는 경향이 있습니다.

이 장에서는 다음 내용을 다룹니다.

피처 엔지니어링을 수행하는 동안 사용할 일반적인 작업 (예: 스케일링, 이산화, 결측치 처리 등).
데이터 누수(data leakage)의 함정을 피하는 방법.
피처 엔지니어링 모범 사례.

피처 엔지니어링은 한 번에 끝나는 작업이 아닙니다. 모델이 프로덕션 환경에 있는 한 피처 엔지니어링 작업은 계속됩니다. 9장에서는 새로 들어오는 데이터를 사용하여 모델을 지속적으로 개선하는 방법을 설명합니다.

피처 스토어(Feature stores)는 10장: MLOps를 위한 인프라 및 도구에서 다룰 것입니다.

학습된 피처(Learned Feature) VS 수동 피처(Engineered Features)

왜 피처 엔지니어링에 신경 써야 할까요? 딥 러닝은 더 이상 피처를 수동으로 만들 필요가 없다고 약속하지 않았나요?

네, 딥 러닝은 원시 데이터(raw data)에서 자동으로 피처를 추출할 수 있습니다. 하지만 2022년 현재, 우리는 모든 피처가 자동으로 학습될 수 있는 시점과는 아직 거리가 멉니다. 더욱이, 2022년 현재 프로덕션 환경의 ML 대다수는 딥 러닝이 아닙니다. 이러한 점을 감안할 때, 신중하게 수동으로 만들어진(handcrafted) 피처 엔지니어링은 여전히 프로덕션 ML에서 매우 중요합니다.

어떤 피처를 학습할 수 있고, 어떤 피처를 여전히 수동으로 만들어야 하는가?

원시 텍스트와 원시 이미지의 벡터화(Vectorization)는 학습될 수 있는 피처의 매우 일반적인 두 가지 예입니다. 그러나 프로덕션 애플리케이션에서 벡터화된 원시 데이터가 필요한 유일한 피처인 경우는 거의 없습니다. 이러한 벡터는 일반적으로 자동으로 추출할 수 없는 상당수의 피처(예: '좋아요' 수, 계정 연령, 답글 수 등)로 보강됩니다. 이 모든 다른 피처들은 여전히 수동으로 만들어야 합니다.

은행 사기 탐지와 같이 많은 도메인 전문 지식이 필요한 애플리케이션 역시 수동 피처가 여전히 필요한 일반적인 경우입니다. 이러한 경우, ML 엔지니어는 일반적으로 도메인 전문가와 긴밀히 협력하여 피처를 결정합니다.

일반적인 피처 엔지니어링 작업

이 섹션에서는 데이터로부터 피처를 엔지니어링하는 동안 고려할 수 있는 가장 중요한 몇 가지 작업을 논의합니다. 여기에 나열된 기술이 전부는 아닙니다. 하지만 좋은 출발점이 될 것입니다.

결측치(missing values) 처리

피처에 결측치가 있는 것은 매우 흔한 일입니다. 그러나 모든 결측치가 동일하지는 않으며, 결측치의 유형은 처리 방법에 영향을 미칩니다.

다음 예시를 통해 결측치의 유형과 결측치 처리 기술을 설명하겠습니다.

결측치의 유형

MNAR (Missing Not At Random)

값이 누락된 이유가 값 자체와 관련이 있는 경우입니다. 예를 들어, 고소득자는 자신의 소득을 공개하는 것을 좋아하지 않습니다. 또 다른 일반적인 예는 특정 질병을 앓고 있는 사람들이 그 정보를 공개하기를 꺼리는 경우입니다.

MAR (Missing At Random)

값이 누락된 이유가 값 자체가 아니라 관측된 다른 변수 때문인 경우입니다.

위 예에서, 우리는 성별 A를 가진 사람들이 자신의 나이를 공개하는 것을 좋아하지 않는다는 것을 알 수 있습니다.

MCAR (Missing Completely At Random)

결측치가 어떤 패턴도 따르지 않는 경우입니다. 예를 들어, 사람들이 특별한 이유 없이 때때로 그 값을 채우는 것을 잊어버리는 경우입니다. 그러나 이런 유형의 결측은 매우 드뭅니다. 특정 값이 누락되는 데에는 보통 이유가 있으며, 이를 조사해야 합니다.

결측치 처리 기술

결측치를 처리하는 가장 일반적인 두 가지 기술은 삭제(deletion)와 대치(imputation)입니다.

결측치를 처리하는 완벽한 방법은 없다는 것을 명심하십시오. 모든 기술에는 장단점(tradeoffs)이 있으며 위험을 초래합니다.

삭제(Deletion)

열(Column) 삭제

변수에 결측치가 너무 많으면 해당 변수를 제거합니다 (즉, 열을 삭제).
장점: 수행하기 쉽습니다.
단점: 중요한 피처를 제거하여 모델의 정확도를 떨어뜨릴 수 있습니다.

행(Row) 삭제

샘플에 결측치가 있으면 해당 샘플을 제거합니다 (즉, 행을 삭제).
이 기술은 결측치가 MCAR이고 제거할 샘플 수가 적을 때 (예: 0.1% 미만) 작동합니다.
장점: 수행하기 쉽습니다.
단점:
- MNAR인 결측치의 행을 삭제하면 모델에 중요한 정보가 제거됩니다. 위 예에서, 연간 소득이 없는 샘플을 제거한다는 것은 아마도 고소득자이기 때문에 소득 공개를 원하지 않았던 사람들의 샘플을 제거한다는 의미입니다.
- MAR인 결측치의 행을 삭제하면 모델에 편향(bias)이 생길 수 있습니다. 위 예에서, 나이가 누락된 모든 샘플을 제거하면 성별 A를 가진 모든 샘플도 제거됩니다. 이는 모델이 성별 A를 가진 사람들에 대해 좋은 예측을 만들지 못한다는 것을 의미합니다.

대치(Imputation)

결측 데이터를 특정 값으로 채웁니다. 어떤 값을 사용할지 결정하는 것이 어려운 부분입니다.
단점: 데이터에 편향을 주입하거나, 노이즈를 추가하거나, 데이터 누수를 만들 수 있습니다.

기본값으로 대치

누락된 문자열에 빈 문자열을 사용하는 것처럼 합리적인 기본값으로 결측 데이터를 채웁니다.
실제로 유효한 값으로 결측치를 채우는 것을 피하십시오. 예를 들어, 누락된 "자녀 수" 값을 0으로 채우지 마십시오. 0은 "자녀 수"에 대해 가능하고 (심지어) 흔한 값입니다.

평균(mean), 중앙값(median) 또는 최빈값(mode)으로 대치

열의 평균, 중앙값 또는 최빈값으로 결측 데이터를 채웁니다.
다른 관련 변수를 고려하여 평균을 계산하는 등 더 정교한 작업을 수행할 수도 있습니다. 예를 들어, 누락된 온도를 해당 기록의 월 평균 온도로 채웁니다.

ML을 통한 대치

다른 행을 피처로 사용하여 간단한 분류기(classifier)나 회귀 모델(regressor)을 만들어 결측 데이터에 대한 가장 가능성 있는 값을 예측할 수 있습니다.

스케일링(Scaling)

일반적으로, 우리는 모든 피처가 비슷한 크기 정도(order of magnitude)를 갖기를 원합니다. 이는 (급여처럼) 선천적으로 숫자가 큰 피처가 (나이처럼) 숫자가 작은 피처를 수치적으로 압도하는 것을 방지하기 위해 수행합니다.

스케일링은 종종 성능 향상을 가져올 수 있으며, 이를 수행하지 않으면 의미 없는(gibberish) 예측을 초래할 수 있습니다.

일반적인 스케일링 기술은 다음과 같습니다.

임의의 범위로 스케일링 (예: [0, 1] 또는 [-1, 1]). 저자(Chip)는 경험적으로 후자가 더 잘 작동한다는 것을 발견했습니다.
정규 분포로 스케일링 (평균 0, 분산 1). 변수가 정규 분포를 따르는 경우 이 방법을 사용하십시오.
로그 변환(Log transformations)은 변수의 분포가 심하게 치우쳐(skewed) 있을 때 유용합니다. ML 모델은 일반적으로 치우친 분포를 다루기 어려워합니다.

스케일링에 대해 유의해야 할 중요한 사항:

스케일링은 데이터 누수의 일반적인 원인입니다.
스케일링은 min과 max를 찾는 것과 같이 데이터셋의 전역 통계(global statistics)를 필요로 합니다. 대규모 데이터셋에서는 전역 통계를 계산하기가 항상 쉽지는 않습니다.
스케일러는 학습 데이터(training data)를 사용하여 구축되어야 하며 예측 데이터(prediction data)에는 "있는 그대로" 적용되어야 합니다. 예측 시점의 피처 분포가 학습 시점과 다르면, 스케일러는 의미 없는 데이터를 출력할 수 있습니다. 이는 스케일러와 모델을 재학습해야 한다는 신호입니다.

연속형 피처의 이산화(Discretization)

이산화는 "저소득: 연 3만 5천 미만"과 같은 "버킷(buckets)"을 만들어 연속형 피처를 이산형(discrete) 피처로 바꾸는 과정입니다.

이론적으로, 이렇게 하는 동기는 알고리즘이 "무한한" 연속적인 소득 가능성을 다루는 것보다 적은 수의 범주(예: 저소득, 중소득, 고소득)를 다루는 것이 더 쉽기 때문입니다. 이 이점은 학습 데이터가 제한적일 때 더 클 것으로 예상됩니다.

단점:

저자는 실제로 이산화가 큰 도움이 되는 것을 보지 못했다고 말합니다.
이산화는 범주 경계에서 불연속성(discontinuities)을 도입하여, 경계에 가까운 연속 변수의 작은 변화가 매우 다르게 처리되도록 만듭니다.
버킷을 선택하는 것은 간단하지 않습니다(not trivial). 히스토그램에서 도출하거나, 기본 사분위수(quantiles)를 사용하거나, 해당 분야 전문 지식(subject matter expertise)을 사용할 수 있습니다.

범주형 피처 인코딩 (Encoding Categorical Features)

범주형 피처 인코딩에는 쉬운 경우와 어려운 경우가 있습니다.

학습 중에 존재했던 범주의 수가 프로덕션에서도 동일하다고 보장될 때는 쉽습니다.
피처가 프로덕션에서 학습 때보다 더 많거나 다른 범주를 가질 수 있을 때 훨씬 더 어려워집니다. 이는 브랜드 이름, 사용자 이름, 제품 유형 등을 피처로 사용할 때 매우 흔합니다. 일반적으로, 프로덕션에서 범주에 새 항목이 동적으로 생성될 수 있을 때 발생합니다.

쉬운 경우: 정적 범주 (Static categories)

범주 수가 시간이 지나도 변하지 않을 때는 인코딩 처리가 쉽습니다. 일반적인 방법은 각 범주 값에 고유한 번호를 할당하고, 필요시 원-핫 인코딩(one-hot encoding)을 수행하는 것입니다.

어려운 경우: 동적 범주 (Dynamic categories)

동적 범주의 인코딩을 잘못 처리하는 일반적인 두 가지 방법이 있습니다.

정적 방식과 동일하게 처리하는 것: 정적 인코더를 구축하고, 프로덕션에서 사용하며, 잘 되기를 바랍니다. 이는 이전에 보지 못했던 범주 값(예: 새 브랜드)을 만나자마자 프로덕션에서 모델이 충돌(crash)하게 만들 가능성이 높습니다.
UNKNOWN(알 수 없음) 범주를 추가하는 것: 이렇게 하면 모델이 충돌하는 것을 막을 수 있습니다.
- 모델을 UNKNOWN 샘플로도 학습시켜야 합니다. 그렇지 않으면 모델이 충돌하지는 않겠지만, 학습 중에 UNKNOWN 피처 값을 본 적이 없으므로 해당 관측치에 대한 예측은 쓸모없게 됩니다.
- 위와 같이 하더라도, UNKNOWN 브랜드를 가진 관측치에 대한 모델 성능은 저조하고 빠르게 저하될 것입니다. 예를 들어, 학습 후에 프로덕션에서 30개의 새 브랜드가 등록될 수 있습니다. 일부는 잘 알려진 브랜드이고 일부는 모조품(knockoff) 브랜드일 수 있습니다. 이들 모두가 UNKNOWN 버킷 내에서 동일하게 처리되어 예측 품질이 저하될 것입니다.

해결책: 해싱 트릭 (The hashing trick)

직관: 알려진 해시 공간(예: 18비트 = 262,144개의 가능한 매핑 값)을 가진 해싱 함수(hashing function)를 사용하여 범주를 값에 매핑합니다.

해싱 트릭은 일종의 '트릭'이기 때문에 일반적으로 대학에서 가르치지 않습니다. 그러나 프로덕션 ML에 매우 유용한 것으로 입증되었으며 Vowpal Wabbit, SKLearn, TensorFlow, Gensim과 같은 도구에 포함되어 있습니다.

모든 해싱 함수와 마찬가지로, 서로 다른 두 범주가 동일한 값으로 인코딩될 수 있습니다 (즉, 충돌(collision)). 문제가 될 것처럼 들리지만, 연구에 따르면 충돌이 모델 성능에 미치는 영향은 생각보다 나쁘지 않습니다. Booking.com의 연구에 따르면 50%의 충돌률은 로그 손실(log-loss)을 0.5% 증가시키는 데 그쳤습니다 (책에는 연구 결과를 보여주는 그래프가 있습니다).

충돌을 줄이기에 충분히 큰 해시 공간을 선택할 수 있습니다. 또한 유사한 범주(예: 이름이 비슷한 웹사이트)가 서로 가까운 값으로 해시되는 LSH(locality-sensitive hashing) 함수와 같이 원하는 속성을 가진 해시 함수를 선택할 수도 있습니다.

해싱 트릭은 지속적인 학습(continual learning) 환경에서 특히 유용할 수 있습니다.

피처 교차 (Feature Crossing)

두 개 이상의 피처를 결합하여 새로운 피처를 생성합니다.
피처를 결합하면 피처 간에 존재하는 비선형성(non-linearities)을 줄이는 데 도움이 될 수 있습니다. 이는 결과적으로 선형 회귀(linear regression), 로지스틱 회귀(logistic regression), 트리 기반(tree-based) 모델과 같이 비선형 관계 학습에 취약한 모델에 큰 도움이 됩니다.
신경망(neural networks)에서는 비선형성을 제거하는 것이 덜 중요하지만, 명시적인 피처 교차는 신경망이 비선형성을 더 빨리 학습하는 데 도움이 될 수 있습니다.

피처 교차의 위험

피처 교차는 피처 공간을 폭발적으로 증가시킬 수 있습니다. 예: 100개의 가능한 값을 가진 피처와 100개의 가능한 값을 가진 다른 피처를 교차하면 10,000개의 교차 피처 공간이 생성됩니다.
교차 후에는, 교차된 각 값에 대응하는 샘플 수가 훨씬 적어집니다. 이 모든 가능한 값에 대해 유용한 것을 학습하려면 훨씬 더 많은 데이터가 필요합니다.
피처 교차는 모델이 학습 데이터에 과적합(overfit)하는 데 기여할 수 있습니다.

이산형(Discrete) 및 연속형(Continuous) 위치 임베딩

위치 임베딩(Positional Embeddings)은 이제 컴퓨터 비전과 NLP 작업의 표준입니다. NLP 예제를 사용하여 이 주제를 논의할 것입니다.

신경망(NN)과 합성곱 신경망(CNN)이 입력을 처리하는 방식은 시퀀스(예: 단어)의 순서가 신경망에 암묵적으로 알려진다는 것을 의미합니다. 그러나 트랜스포머(transformers)와 같은 모델에서는 모든 단어가 병렬로 처리되므로 단어의 위치가 명시적으로 입력되어야 합니다.

시퀀스 내 요소의 위치는 이산형(예: 첫 번째 토큰, 두 번째 토큰)일 수도 있고 연속형(예: 위치 1.35의 요소)일 수도 있습니다.

순진한(Naive) 이산형 위치 임베딩: 인덱스 사용

순진한 접근 방식은 인덱스(예: 0, 1... k)를 사용하여 토큰의 위치를 설명한 다음, 신경망에서 사용할 수 있도록 [-1, 1]과 같은 범위로 스케일링하는 것입니다.

이 접근 방식에는 몇 가지 문제가 있습니다.

긴 시퀀스의 경우, 위치 간의 수치적 차이가 너무 작아집니다. 이로 인해 NN이 한 위치와 다른 위치의 차이를 구별하기 어렵습니다.
스케일링은 시퀀스 길이에 따라 달라지는 함수입니다. 이는 주어진 위치(예: 위치 2)에 대한 인코딩이 길이가 5인 시퀀스와 길이가 100인 시퀀스에서 다를 것임을 의미합니다.

고정(Fixed) 이산형 임베딩

고정 이산형 임베딩에서는 각 요소의 위치가 벡터로 표현됩니다. 이 벡터는 일반적으로 단어 임베딩 벡터와 동일한 길이(예: 512개 요소)이며, 어떤 시퀀스 길이에 대해서도 완전히 사전 계산(precomputed)될 수 있습니다.

NN에서 이를 사용하려면, 단어 임베딩에 해당 위치 임베딩이 더해집니다. 이 연산의 출력이 나머지 네트워크의 입력으로 사용됩니다.

고정 위치 임베딩의 계산은 sine 및 cosine 함수를 사용하므로 벡터의 각 요소는 [-1, 1] 사이입니다. 아래 이미지는 이것이 어떻게 계산되는지에 대한 간략한 개요를 보여줍니다. 자세한 설명은 이 훌륭한 포스트에서 찾을 수 있습니다.

학습된(Learned) 이산형 임베딩

이들은 고정 이산형 임베딩과 동일한 방식(즉, 단어 임베딩과 위치 임베딩을 함께 더함)으로 사용됩니다. 그러나 위치 임베딩을 사전 계산하는 대신, 임베딩이 학습 중 역전파(back propagation)를 통해 학습됩니다.

이것이 Hugging Face의 BERT에서 위치 임베딩이 구현되는 방식입니다.

연속형(Continuous) 임베딩

위치가 연속형일 때 임베딩을 학습하는 것은 매우 어렵습니다. 그러나 고정된(사전 계산된) sine 및 cosine 기반 임베딩은 여전히 작동합니다. 이는 푸리에 피처(Fourier Features)라고도 알려져 있으며, 고정 이산형 임베딩은 일반적인 연속형 사례의 특별한 경우일 뿐입니다.

데이터 누수 (Data Leakage)

데이터 누수(Data leakage)는 모델이 데이터의 실제 레이블을 "누설하는" 정보를 악용하도록 학습함으로써 학습(training), 검증(validation) 및 테스트(testing) 중에 불공정한 성능 이점을 얻는 경우입니다. 이 이점은 일반적으로 데이터가 수집, 처리 또는 분할된 방식으로 인한 부산물(artefact)입니다.

이 이점은 추론 시점(inference time)에는 사용할 수 없으므로, 프로덕션에서 모델이 예측 불가능하고 심각한 방식으로 실패하게 만듭니다. 이러한 누수는 검증 및 테스트 데이터셋이 문제의 일부일 수 있기 때문에, 검증 및 테스트 중에는 감지하기 어렵습니다.

데이터 누수의 일반적인 원인

시간 상관관계가 있는 데이터를 시간순이 아닌 무작위로 분할

지나치게 단순화된 예: 이전 6일간의 다른 모든 주식의 움직임을 기반으로 구글 주가를 예측한다고 상상해 보십시오. 데이터를 (시간순이 아닌) 무작위로 분할하면, 7일째의 다른 회사 주가까지 포함하게 되어 모델에게 미래 정보를 미리 알려주는 불공정한 이점을 주게 됩니다.

일반적으로, 레이블 값이 시간과 상관관계가 있다면, 데이터를 학습, 검증, 테스트 데이터셋으로 분할할 때 무작위가 아닌 시간순으로 분할하는 것이 좋습니다.

분할 전 스케일링

학습, 검증, 테스트로 분할하기 전에 피처를 스케일링하면, 스케일러는 모델에게 완전히 보이지 않아야 할 검증 및 테스트 세트의 데이터로부터 max, min, average 등과 같은 정보를 인코딩하게 됩니다.

이를 피하려면, 먼저 데이터를 분할하고 학습 데이터에 대해서만 스케일러를 구축하십시오. 그런 다음 학습 스케일러를 사용하여 다른 두 분할(검증, 테스트)을 스케일링하십시오. 어떤 사람들은 심지어 가정(assumptions)이 학습 과정에 누수되는 것을 피하기 위해 검증 및 테스트 세트에 대해 탐색적 데이터 분석(EDA)조차 수행해서는 안 된다고 주장합니다.

검증 또는 테스트 분할의 통계로 결측치 채우기

이는 위와 유사합니다. 대치(imputation) 프로세스에 검증 및 테스트 세트의 정보가 포함되기를 원하지 않습니다.

분할 전 데이터 중복 처리 미흡

데이터를 학습, 검증, 테스트 세트로 분할하기 전에 중복 또는 거의 중복되는 데이터를 제거하지 못하면, 모델이 학습 시와 검증/테스트 시에 동일한 샘플을 관찰하게 됩니다.

중복은 산업 및 연구 데이터셋에서 매우 흔합니다. CIFAR-100과 같은 일부 인기 있는 데이터셋에는 10%의 중복이 있었습니다.
데이터 중복은 수집 시점, 다른 데이터 소스 병합 시점 또는 처리 시점(예: 오버샘플링 시)에 발생할 수 있습니다.
분할하기 전과 분할한 후에(확인 차원에서) 항상 데이터 중복을 확인하십시오.
오버샘플링을 한다면, 데이터 분할 후에 수행하십시오.

그룹 누수 (Group leakage)

이는 예시를 통해 더 잘 설명됩니다. 한 환자가 일주일 간격으로 두 번의 폐 CT 스캔을 찍었을 수 있습니다. 두 CT 스캔 모두 데이터에 포함되며 아마도 동일한 레이블을 포함할 것입니다 (사실상 동일한 샘플입니다). 무작위로 분할하면, 하나의 CT 스캔은 학습 데이터에, 다른 하나는 검증/테스트 세트에 들어갈 수 있습니다.

이를 피할 수 있는 유일한 방법은 데이터가 어떻게 생성되었는지 이해하는 것입니다.

데이터 생성 과정에서의 누수

폐암 레이블링을 돕는 모델을 구축한다고 상상해 보십시오. 고도로 전문화된 종양 병원이 다른 덜 전문화된 병원들처럼 데이터를 공유합니다. 이 전문 병원의 CT 스캔 기계는 특별한 형식으로 CT 스캔을 생성합니다. 데이터가 올바르게 처리되지 않으면, 모델이 CT 스캔의 형식을 악용하여 레이블을 할당할 수 있습니다. 전문 병원의 CT 스캔이 양성 레이블을 포함할 가능성이 더 높기 때문입니다. 물론, 형식은 진단과 아무 관련이 없어야 합니다.

이를 피하려면, 학습에 영향을 주어서는 안 되는, 데이터 수집 방식에 대한 가짜 피처(pseudo-features)를 모델이 악용할 가능성을 줄이도록 데이터를 정규화(normalize)할 방법을 생각하십시오.

테스트 분할의 오용

모델의 최종 성능을 보고하는 것 외에, 새로운 피처에 대한 아이디어를 얻거나 하이퍼파라미터를 튜닝하는 등 다른 방식으로 테스트 분할을 사용한다면, 테스트 세트의 정보가 학습 과정으로 누수될 위험이 있습니다.

데이터 누수 탐지

타겟 변수(레이블)에 대한 각 피처 또는 피처 세트의 예측력을 측정하십시오. 만약 피처 또는 피처 세트가 레이블과 비정상적으로 높은 상관관계를 보인다면, 이 피처가 어떻게 생성되는지, 그리고 그 상관관계가 말이 되는지 조사하십시오.

이 예측력을 측정하는 한 가지 방법은 피처(또는 피처 세트)에 대한 절제 연구(ablation studies)를 수행하는 것입니다. 피처를 제거하고 모델 성능이 크게 저하되는지 확인합니다. 이에 대한 자세한 내용은 아래 피처 중요도 섹션에 있습니다.
모델에 새로운 피처가 추가될 때를 주의 깊게 살펴보십시오. 피처 추가로 인해 성능이 크게 향상된다면, 그것이 타당한지 조사하십시오.

좋은 피처 엔지니어링하기

일반적으로 피처를 추가하면 모델 성능이 향상됩니다. 그러나 피처가 너무 많으면 모델에 나쁠 수도 있습니다.

더 많은 피처 = 데이터 누수 가능성 증가
더 많은 피처 = 과적합(overfitting) 가능성 증가
더 많은 피처 = 모델 서빙에 더 많은 메모리 필요 = 더 많은 인프라 비용
더 많은 피처 = 실시간 피처(live features) 계산에 더 많은 계산 필요 = 더 많은 지연 시간(latency)
쓸모없는 피처는 기술 부채(technical debt)가 됩니다. 데이터 파이프라인에서 무언가 변경되면(예: 필드 누락), 해당 피처가 쓸모없음에도 불구하고 피처 계산 코드를 업데이트해야 할 수도 있습니다.

정규화(Regularization) (예: L1 정규화)는 쓸모없는 피처의 가중치를 0으로 줄일 수 있습니다. 그러나 실제로는 처음부터 포함하지 않는 것이 훨씬 좋습니다.

피처가 모델에 좋은지 평가할 때 고려해야 할 두 가지 요소는 피처 중요도(feature importance)와 보이지 않는 데이터에 대한 일반화(generalization)입니다.

피처 중요도 (Feature Importance)

피처 중요도를 측정하는 방법은 많습니다. 그러나 일반적으로 이들이 하려는 것은 피처 또는 피처 세트가 제거되었을 때 모델의 성능이 얼마나 저하되는지 측정하는 것입니다.

부스티드 트리(boosted trees)와 같은 고전적인 ML 알고리즘을 사용한다면, 이러한 알고리즘은 피처 중요도를 측정하는 내장 메커니즘을 가지고 있는 경향이 있습니다 (예: XGBoost).
모델에 구애받지 않는(model-agnostic) 방법으로는 SHAP (SHapley Additive exPlanations)을 사용할 수 있습니다.
- SHAP은 전반적인 피처 중요도뿐만 아니라 특정 예측에 대한 각 피처의 기여도도 알려줄 수 있습니다. 이는 모델이 왜 실수를 하는지 이해하는 데 매우 유용합니다.
Interpret ML은 SHAP 및 기타 설명 가능한 ML(Explainable ML) 기술을 구현한 오픈 소스 패키지입니다.
피처 중요도 기술은 데이터 누수 탐지 및 해석 가능성(interpretability)에도 유용합니다.
참고로, Facebook 광고 팀은 10개의 피처가 모델 피처 중요도의 50%를 차지하고, 마지막 300개의 피처는 전체 중요도에 1% 미만을 기여한다는 것을 발견했습니다.

피처 일반화 (Feature Generalization)

ML은 보이지 않는 데이터에 대한 예측이 전부이므로, 일반화가 잘 되는 피처가 바람직합니다. 그러나 모든 피처가 동일하게 일반화되지는 않습니다.

피처는 다른 모델에서도 사용될 수 있을 정도로 일반화될 수 있습니다. 그러나 피처가 얼마나 일반화 가능한지(generalizable)와 문제에 얼마나 특화되어 있는지(specific) 사이에는 본질적인 트레이드오프(trade-off)가 있습니다.

피처 일반화를 측정하는 것은 피처 중요도보다 훨씬 덜 과학적입니다. 직관과 해당 분야 전문 지식이 필요합니다.

전반적으로, 일반화와 관련하여 고려해야 할 2가지 측면이 있습니다. 피처 커버리지(feature coverage)와 피처 값의 분포(distribution of feature values)입니다.

피처 커버리지 (Feature coverage)

커버리지는 주어진 피처에 대해 값을 가진 샘플의 비율입니다. 피처에 null 값이 적을수록 커버리지는 높아집니다.

커버리지가 매우 낮으면 해당 피처는 일반화 가능성이 높지 않다는 것이 대략적인 경험 법칙입니다. 이 규칙에는 많은 예외가 있습니다. 아마도 가장 중요한 예외는 결측값이 무언가를 의미하는 경우(즉, 값이 MNAR인 경우)입니다. 이 경우, 값의 부재(absence)가 실제로 모델에 귀중한 의미를 전달합니다.
특정 피처에 대한 피처 커버리지가 학습 분할과 테스트 분할 간에 크게 다르다면, 이는 데이터가 동일한 분포에서 오지 않았음을 강력하게 나타내며, 아마도 데이터 분할을 다시 생각해야 할 필요가 있음을 의미합니다.

피처 값의 분포

피처의 null이 아닌 값들의 분포를 살펴보십시오. 학습 분할에서 본 분포가 테스트 분할의 분포와 거의 또는 전혀 겹치지 않는다면, 이 피처는 모델에 해를 끼칠 수도 있습니다.

이는 데이터를 시간순으로 분할해야 하는 모델에서 흔히 발생하는 문제입니다.