[ML] 머신러닝 시스템 설계 : 8장 데이터 분포 시프트와 모니터링

gunny·2023년 5월 26일

Designing Machine Learning System 데이터 분포 시프트와 모니터링 머신러닝 시스템 설계 머신러닝 시스템 설계 8장 머신러닝 시스템 설계 8장 데이터 분포 시프트와 모니터링

ML

목록 보기

8/17

해당 게시물은 ML 프로덕션 환경 속에 있는 내가 모델 개발에만 열중하고 전반적인 시스템 설계에 대한 배경지식이 없었던 와중에 옆자리 팀원한테 추천 받아서 읽게된 한빛미디어의 "머신러닝 시스템 설계"를 공부하면서 요약한 게시물로, 저작권은 한빛미디어에게 있겠습니다.

8. 데이터 분포 시프트와 모니터링

모델 성능은 프로덕션 환경에서 시간에 따라 저하됨
모델 배포 후에도 이슈를 탐지하기 위해 성능을 지속적으로 모니터링해야 하며 발생한 이슈를 수정하는 업데이트를 계속 배포해야함
ML 모델이 프로덕션 환경에서 실패하는 이유 중 '데이터 분포 시프트(shift)' 가 있는데, 이는 프로덕션 환경의 데이터 분포가 훈련하는 동안 모델에 노출된 데이터 분포와 다르거나 괴리가 점차 커질 때 발생함
프로덕션 환경에서 동작하는 ML 모델 대부분에 영향을 미칠 만큼 만연함

8. 머신러닝 시스템 장애 원인

장애는 시스템에 대한 기대치가 한가지 이상 어긋날 때 일어남
전통적인 소프트웨어에서는 주로 시스템 운영에 대한 기대치, 즉 시스템 로직이 레이턴시와 스루풋 같은 운영 지표의 기대 범위 안에서 실행되는지가 중요함
ML 시스템에서는 운영 지표와 ML 성능 지표 모두 신경 써야 함
예를 들어 영어-프랑스 기계 번역의 운영 기대치는 영어 문장을 입력하면 시스템이 바로 레이턴시 1초 안에 프랑스어 번역문을 출력해 내는 것이고, ML 성능상 기대치는 출력 중 99%는 주어진 영어 문장을 정확히 번역한 문장이어야 한다는 것임
출력한 번역이 정확하지 않다고 해서 반드시 시스템 장애는 아님, 정확도 기대치는 약간의 오차를 허용함
하지만, 서로 다른 영어 문장을 시스템에 연달아 입력하는데 계속해서 잘못된 번역문이 나온다면 두 번째 기대치를 어기므로 시스템 장애임
운영상 기대치를 어기는 문제는 감지하기가 쉬움
시간 초과, 웹 페이지 404 오류, 메모리 부족, 세그멘테이션 결함 등 운영 중단을 수반하기 때문임. 그러나 ML 성능상 기대치를 어기는 문제는 프로덕션 환경에서 ML 모델 성능을 측정하고 모니터링해야 하므로 감지하기가 보다 어려움
영어 - 프랑스어 기계 번역 시스템 예시에서 올바른 번역문이 무엇인지 모른다면 출력된 번역문 중 99%가 옳은지 그른지 판단하기 어려움
사용자가 구글 번역문이 오역임을 인지하지 못해 오역을 사용하는 사례는 셀 수 없이 많은데 이러한 이유로 ML 시스템은 조용히 실패(fail silently) 한다고 함

<소프트웨어 시스템 장애>
소프트웨어 시스템 장애는 ML에 속하지 않는 시스템에서 발생하는 장애임

[1] 의존성 장애 :
시스템이 의존성을 갖는 소프트웨어 패키지 혹은 코드베이스에 중단이 발생해 시스템이 중단되는 경우임
서드 파티가 의존성을 유지 관리 할 때 흔히 발생하며, 의존성을 유지 관리하는 서드 파티가 더 이상 존재하지 않는 경우 특히 자주 발생

[2] 배포 실패 :
배포 오류로 인한 실패.
모델이 현재 버전 대신 실수로 이전 버전 바이너리를 배포하거나 시스템에 특정 파일을 읽거나 쓰기 권한 없는 경우

[3] 하드웨어 오류 :
CPU나 GPU처럼 모델 배포에 사용하는 하드웨어가 제대로 작동하지 않는 경우
예를 들면 사용하던 CPU가 과열돼 고장남

[4] 다운타임 또는 충돌:
시스템 구성 요소가 다른 곳에 있는 서버, AWS나 호스팅 서비스에서 실행되는 경우 해당 서버가 다운되면 시스템도 따라서 다운됨

소프트웨어 시스템 장애를 해결하려면 ML 기술이 아니라 전통적인 소프트웨어 엔지니어링 기술이 필요함.
ML 시스템 배포에도 전통적인 소프트웨어 엔지니어링 기술이 중요한 만큼 ML 엔지니어링은 보통 ML이 아닌 엔지니어링에 중점을 둠
소프트웨어 시스템 장애가 만연한 이유는 업계에서 ML 도입이 아직 초기 단계이고, 따라서 ML 프로덕션 환경을 위한 도구가 한정적이고 아직 모범 사례가 잘 개발되거나 표준화되지 않았기 때문임

<머신러닝 한정 장애>

ML 한정 장애는 ML 시스템과 관련된 장애임
예를 들어 데이터 수집과 처리에 문제가 있을 때, 하이퍼파라미터에 문제가 있을 때, 추론 파이프라인의 변경 사항이 학습 파이프라인에 제대로 복사되지 않았을 때(혹은 그 반대), 데이터 분포 시프트로 모델 성능이 시간에 따라 저하 될 때, 에지 케이스, 퇴행성 피드백 루프 등이 있음
ML 한정 장애는 전체 장애에서 차지하는 비중은 낮지만 탐지하거나 수정이 어렵고, ML 시스템이 온전히 사용되지 못하게 하므로 ML이 아닌 영역의 장애보다 훨씬 더 위험함
일단 여기서는 모델 배포 후에 발생하는 (1) 프로덕션 데이터가 훈련 데이터와 다른 경우, (2) 에지 케이스(edge case), (3) 퇴행성 피드백 루프(degenerate feedback loop) 등을 나열한다.

(1) 프로덕션 환경 데이터가 훈련 데이터와 다른 경우
- ML 모델을 훈련 데이터로 학습함은 모델이 훈련 데이터에 내재된 분포를 학습한 후에 그 학습된 분포를 통해 훈련 중 본 적 없는 데이터에 대해 정확한 예측값을 만들어냄을 의미함
- '데이터 분포 시프트' 는 수학적으로 의미하는 바가, 모델이 본 적 없는 데이터에 대해 정확한 예측값을 만들어낸다면 이 모델이 '본 적 없는 데이터에도 충분히 일반화' 됐다고 얘기함
- 개발 중 모델 평가에 사용하는 테스트 데이터는 본 적 없는 데이터여야 하며 이에 대한 모델 성능은 모델이 얼마나 잘 일반화될지 가늠하게 해줌

ML 교과 과정에서 먼저 배우는 것 중 하나는 훈련 데이터와 본 적 없는 데이터가 유사한 분포에서 나와야 한다는 것임
즉, 본 적 없는 데이터를 훈련 데이터 분포와 동일한 '정상 분포(stationary distribution)' 에서 추출했다고 가정함. 본 적 없는 데이터를 다른 분포에서 추출하면 모델이 제대로 일반화되지 않을 수 있음

=> 이 가정은 대개 올바르지 않을 수 있음.
첫 째로, 실제 데이터에 내재된 분포는 훈련 데이터에 내재된 분포와 같지 않을 수 있어음. 훈련 데이터셋이 모델이 프로덕션 환경에서 접할 데이터를 정확하게 표현하도록 큐레이팅 하기는 어려움
-실제 데이터는 다면적이고 많은 경우에 변형이 무한에 가까운 반면, 훈련 데이터는 유한하고 데이터셋 생성과 처리에 사용할 수 있는 시간/연산/인적 자원에 의해 제한됨
다양한 종류의 선택이나 샘플링 편향이 존재함
현실 데이터가 훈련 데이터와 매우 달라져서, 이러한 데이터 분포의 차이는 다른 유형의 이모티콘 인코딩을 사용하는 현실 데이터처럼 매우 사소한 것에 기인할 수 있음 => 이러한 유형의 차이를 훈련-서빙 편향(trin-serving skew) 이라는 흔한 장애 모드를 야기함
: 모델이 개발 시에는 훌륭하지만 배포 후 성능은 그다지 좋지 않은 현상
둘째로, 현실 세계는 정상성(stationarity)를 갖지 않음
모든 것은 변하며, 데이터 분포는 시프트함
모델이 처음 배포될 때는 훌륭하게 작동하지만 시간에 따라 데이터 분포가 변하면서 성능이 저하됨
데이터 시프트를 유발하는 예시로 코로나19 사례를 들면 사람들은 데이터 시프트 비정상적인 이벤트 때문에 발생한다고 생각하기 쉬워, 자주 발생하지 않는다고 생각함
그러나, 데이터 시프트는 항상, 갑자기, 점진적으로 혹은 계절성을 띠며 발생함

특정 이벤트 때문에 갑자기 발생하는 예시는 기존 경쟁자가 가격 정책을 변경해서 이에 대응하기 위해 가격 예측을 업데이트해야 하는 경우, 새로운 지역에서 제품을 출시하거나 유명인이 제품을 언급해 신규 사용자가 급증하는 경우 등이고

점진적으로 발생하는 예는 사회 규범, 문화, 언어, 트렌드, 산업과 같이 시간에 따라 변화하는 경우와 계절적 변화 때문에 발생하는 예시이다.

모니터링 대시보드에서 데이터 시프트처럼 보이는 것들은 사실 대부분 내부 오류임
ML 시스템의 복잡성과 잘못된 배포 관행 때문인데, 데이터 파이프라인의 버그/잘못 입력된 결측값/훈련과 추론 시 추출한 피처 간의 불일치/잘못된 데이터 하위 집합의 통계를 적용해 표준화한 피처/잘못된 모델 버전 또는 사용자 행동을 바꾸게 강제한 앱 인터페이스상 버그 등이 원인이 될 수 있음

(2) 에지 케이스

ML 모델이 대부분 잘 작동하더라도 낮은 확률로 장애가 발생해 치명적인 결과를 유발한다면 모델 사용 자체가 어려워짐
주요 자율 주행 자동차 회사들은 시스템이 에지 케이스에서 잘 작동하도록 하는 데 최선을 다하고 있음
에지 케이스란 너무 극단적이여서 모델이 치명적인 실수를 하게 되는 데이터 샘플을 말함
에지 케이스는 보통 동일한 분포에서 나온 데이터 샘플이지만, 모델이 잘 작동하지 않는 데이터 샘플 수가 급증했다면 내재된 데이터의 분포가 시프트하지 않았나 의심해봐야 함
에지 케이스가 배포된 ML 시스템을 망가뜨리는 사례로 자율 주행 자동차를 이야기 하는데, 안전이 중요한 모든 애플리케이션이 이러한 사례에 해당한다.
또한, 안전이 중요하지 않은 애플리케이션도 고객 서비스 챗봇이 문의에 대개 합리적으로 응답하지만 인종 차별적이거나 성차별 적인 내용을 뱉는다고 생각하면 브랜드 이미지에 좋지 않아 사용하기 어려워짐

에지 케이스와 이상치

에지 케이스와 이상치에 대한 차이점을 살펴보면, 에지 케이스의 구성 요소에 대한 정의는 분야에 따라 다르다.
ML은 최근에 프로덕션 환경에 도입되기 시작해서, 에지 케이스가 계속 발견되고 있다. 따라서 용어 정의에 논란의 여지가 생기고 있다
여기서의 이상치란 다른 데이터 포인트와 성질이 크게 다른 데이터 포인트 데이터를 의미하는데, 에지 케이스는 성능을 의미한다.
다른 데이터 포인트보다 모델 성능이 크게 뒤떨어지는 데이터 포인트임
이상치 또한 모델 성능이 비정상적으로 저조한 원이 될 수 있어 에지 케이스에 포함되기도 함
다만 모든 이상치가 에지 케이스는 아님
예를 들어 고속 도로를 무단 횡단 하는 사람이 이상치이지만,
자율 주행 자동차가 그 사람을 정확하게 탐지하고 그에 대한 반응을 적절하게 판단할 수 있다면 에지 케이스가 아님
모델 개발 중에 이상치가 모델 성능에 부정적인 영향을 미치기도 하는데, 많은 경우 모델이 더 나은 결정 경계를 학습하고 본 적 없는 데이터에 더 잘 일반화되도록 이상치를 제고하곤 함
그러나, 일반적으로 추론 과정에서 다른 질의문과 성격이 크게 다른 질의문을 제거하거나 무시할 수 없음

(3) 퇴행성 피드백 루프

피드백 루프는 예측값을 제시한 다음 예측값에 대한 피드백이 되돌아올 때까지 걸리는 시간을 의미함
피드백은 자연 레이블을 추출해 모델 성능을 평가하고 다음번 훈련을 반복하는데 사용 가능함
퇴행성 피드백 루프(degenerate feedback loop)는 예측 자체가 피드백에 영향을 미치고, 이 피드백이 모델의 다음번 반복 학습에 영향을 미칠 때 발생함
퇴행성 피드백 루프는 시스템 출력을 시스템의 미래 입력을 생성하는 데 사용할 때 발생하고, 이것은 시스템 미래 출력에 다시 영향을 미침
ML에서 시스템의 예측은 사용자가 시스템과 상호 작용하는 방식에 영향을 미침
시스템과 사용자의 상호 작용은 때때로 같은 시스템에 대한 훈련 데이터로 사용되므로 퇴행성 피드백 루프가 발생하면서 의도하지 않은 결과를 초래할 수 있음
퇴행성 피드백 루프는 추천 시스템과 광고 클릭률 예측 등 사용자에게서 획득한 자연 레이블이 존재하지 않는 작업에서 특히 흔함

예를 들어 사용자가 좋아할 말한 노래를 추천하는 시스템을 개발한다고 가정할 때, 시스템에서 순위가 높은 노래가 사용자에게 먼저 보이게 됨. 가장 먼저 보이면 사용자가 더 많이 클릭하게 되고 시스템은 이 추천 항목이 적절하다고 확신하게 됨.
처음에는 두 곡 A와 B의 순위가 미세하게 달랐고, A가 좀 더 높은 순위에 있어서 추천 목록에 좀 더 상단에 보여지게 되었으나, 사용자가 잘 보이는 곳에 있는 A를 더 많이 클릭하게 되고 시스템에서 A의 순위가 B보다 올라가게 된다.

퇴행성 피드백 루프는 인기 있는 영화, 도서, 음악이 점점 더 인기를 얻는 이유를 설명하는 한 가지 요소이며 프로덕션 환경에서는 이러한 현상이 나타나는 시나리오가 매우 보편적이고 많이 연구되어 왔음

=> 이를 '노출 편향', '인기도 편향', '필터 거품', '에코 체임버' 등으로 불리게 됨
퇴행성 피드백 루프의 위험성은, 이력서 기반 지원자가 특정 직무에 적합한지 예측하기 위한 심사 모델을 개발했을 때와 같이 특정 피처 X에 높은 가중치를 부여하게 되면서 발생할 수 있음.
이는 모델에 대한 각 피처의 중요도를 측정하는 식으로 모델이 예측을 수행하는 방식에 대한 가시성을 확보하여 특정 피처에 대한 편향을 감지한다
사람이 관여하지 않으면 퇴행성 피드백 루프로 인해 모델이 최적 성능에 못 미치는 상태로 계속 동작함
최악의 경우 데이터에 존재하는 편향이 영속화되고 확대됨

<퇴행성 피드백 루프 감지>

시스템이 오프라인일 때는 퇴행성 피드백 루프를 감지하기 어려움
퇴행성 루프는 사용자 피드백으로 인해 발생하는데 시스템이 온라인 상태가 되기 전까지(사용자에게 배포되기 전까지)는 사용자가 존재하지 않기 때문임
추천 시스템에서는 시슽메이 오프라인일 때도 시스템 출력 인기도의 다양성을 측정해 퇴행성 피드백 루프르 감지할 수 있음
항목의 인기도는 과거에 상호 작용(열람/좋아요/구매 등)이 일어난 횟수를 기반으로 측정함
모든 항목의 인기도는 롱테일 분포를 따라서, 소수 항목만 다수 사용자와 상호 작용이 발생하고 대부분 항목은 상호 작용이 거의 발생하지 않음
'롱테일 항목(long-tail item')의 총체적 다양성(aggregate diversity)와 평균 적용 범위(average coverage)의 여러 지표들은 추천 시스템 출력의 다양성을 측정하는데 도움이 될 수 있음
=> 낮은 점수는 시스템 출력이 단조로움을 의미하고, 이는 인기도 편향으로 발생할 수 있음

<퇴행성 피드백 루프 교정>
퇴행성 피드백 루프는 흔한 문제여서 이를 교정하는 방법은 (1) 무작위화 사용 (2) 위치 피처 사용이 있다

(1) 무작위화
퇴행성 피드백 루프로 인해 시간에 따라 시스템 출력이 점차 단조로워질 수 있는데, 예측에 무작위화를 도입하면 단조로움을 줄일 수 있음
추천시스템에서 순위가 높은 항목만 보여주는 대신 무작위 항목을 보여주고
사용자 피드백을 받아서 항목의 실제 경쟁력을 결정함
: 틱톡에서 사용 중
무작위화는 다양성을 개선하지만 사용자 경험을 저하할 수 도 있음
적당한 규모의 무작위화와 인과 추론 기술을 사용해 편향되지 않은, 본래의 가치를 추정하는 방법이 있음
퇴행성 피드백 루프는 예측에 대한 사용자 피드백으로 인해 발생하고, 예측에 대한 피드백은 보이는 위치에 따라 편향된다.

(2) 위치 피처(positional feature)
예측값이 보여지는 위치가 피드백에 어떤 식으로든 영향을 미치는 경우 위치 피처를 사용해 위치 정보를 인코딩 한다.
'위치 임베딩' 과는 다름

예를 들어서, 퇴행성 피드백 루프를 완화하기 위해 훈련 데이터에 위치 피처를 추가할 수 있는데, 노래 추천과 같은 경우 '최상단 추천 여부'를 피처로 추천하여 피처를 통해 모델이 최상단 추천 여부가 클릭 여부에 얼마나 영향을 미치는지 알 수 있다.
추론할 때는 노래가 추천되는 위치에 상관없이 사용자가 노래를 클릭할지 예측하는 것이 목표이므로, 최상단 위치 피처 값을 '아니오'로 설정하고, 사용자가 여러 곡들에 대해 모델 예측값을 보고 각 노래를 보여줄 순서를 결정한다.
보다 정교한 방법은 두 가지 모델으 사용하는 것으로, 첫 번째 모델은 추천이 보이는 위치를 고려해 사용자가 추천을 살펴보고 고려할 확률을 예측하는 것과 두 번째 모델은 사용자가 살펴보고 선택을 고려한 항목을 최종적으로 클릭할 확률을 예측하는 것이다. 두 번째 모델은 위치와는 전혀 관련이 없다

8-3. 데이터 분포 시프트
데이터 분포 시프트는 지도 학습에서 모델이 동작하는 데이터가 시간에 따라 변하는 현상으로, 모델 예측도 시간이 지날수록 덜 정확해짐
모델이 훈련된 데이터의 분포를 원본 분포(source distribution) 이라고 하며, 모델이 추론을 실행하는 데이터의 분포를 대상 분포(target distribution) 이라고 함

<데이터 분포 시프트 유형>
데이터 분포 시프트는 종종 (1) covarinace shift, (2) label shift, (3) concept drift와 동일한 의미로 사용도지만, 이 세 가지 개념은 데이터 시프트의 하위 유형임
다양한 시프트 유형에 대한 논의는 수학적임. 데이터 시프트를 감지하고 효율적인 알고리즘을 개발하기 위해서는 시프트 원인을 이해해야 함
모델에 대한 입력을 X, 출력을 Y 라고 할 때,
지도 학습에서 훈련 데이터는 결합 분포 P(X,Y)의 샘플 집합으로 볼 수 있으며 ML은 일반적으로 P(Y|X)를 모델링함.
이 결합분포 P(X,Y)는 두 가지 방식으로 분해 될 수 있음
(1) P(X,Y) = P(Y|X)P(X)
(2) P(X,Y) = P(X|Y)P(Y)

P(Y|X)는 입력이 주어졌을 때 출력의 조건부 확률을 나타냄
예를 들어, 이메일 내용이 주어졌을 때 이메일이 스팸일 확률로,
P(X)는 입력의 확률 밀도 함수를 나타내며 P(Y)는 출력의 확률 밀도 함수를 나타냄

(1) Covariate shift
P(X)가 변하지만 P(Y|X) 는 동일하게 유지됨

(2) Label shift
P(Y)가 변하지만 P(X|Y)는 동일하게 유지됨

(3) Concept drift
P(Y|X)가 변하지만 P(X)는 동일하게 유지됨

(1) 공변량 시프트(Covariance shift)

통계학에서 공변량은 주어진 통계적 시행 결과에 영향을 미칠 수 있지만 직접적인 관심 대상은 아닌 독립 변수임
예를 들어 지리적인 위치가 주택 가격에 미치는 영향을 확인하기 위해 실험한다고 가정할 때, 직접적인 관심사는 주택 가격이라는 변수이고 넓이라는 변수는 가격에 영향을 미치므로공변량인 셈임
지도 학습에서는 레이블이 직접적인 관심 변수고 입력 피처는 공변량 변수임
공변량 시프트는 P(X)가 변하지만 P(Y|X)는 동일하게 유지되는 경우로,
입력의 분포는 변하지만 입력이 주어졌을 때 출력의 조건부 확률은 동일하게 유지되는 것임

예시로, 유방암을 감지하는 작업에서 여성이 40세 이상이면 유방암에 걸릴 확률이 더 높으므로 입력 변수는 '나이' 임. 추론 데이터보다 훈련 데이터에서 40세 이상 여성이 더 많다면 훈련 및 추론 데이터의 입력 분포가 상이함
하지만, 연령이 정해진 데이터 포인트 예를 들어 40세 이상인 데이터 포인트가 유방암에 걸릴 확률은 일정함
즉 P(Y|X), 즉 40세 이상이 유방암에 걸릴 확률은 같음
모델 개발 시 데이터 선택 프로세스에서 내재된 편향 때문에 공변량 시프트가 발생할 수 있음
이 편향이 생기는 이유는 특정 클래스의 샘플을 수집하기가 어렵기 때문임

예를 들어 유방암을 연구하기 위해 여성들이 주로 유방암 감서라르 받으러 가는 병원에서 데이터를 얻었다고 가정할 때, 40세 이상이면 검진을 권유받으므로 병원 데이터의 대부분은 40세 이상 여성임
=> 이러한 이유로 공변량 시프트는 샘플 선택 편향 문제와 밀접하게 관련됨
공변량 시프트는 모델이 좀 더 쉽게 학습할 수 있도록 훈련 데이터를 인위적으로 변경할 때 발생함
ML 모델 학습은 불균형 데이터셋에서 더 어려움
드물게 발생하는 클래스에 대해 더 많은 샘플을 수집하거나, 모델이 드문 클래스를 더 잘 학습하도록 해당 클래스에 대한 데이터를 오버샘플링함
공변량 시프트는 모델 학습 프로세스, 특히 능동적 학습 프로세스 때문에 생기기도 함

능동적 학습 : 모델을 훈련할 샘플을 무작위로 선택하는 대신 휴리스틱에 따라 해당 모델에 가장 유용한 샘플을 선택하는 방법

훈련 입력 분포가 실제 입력 분포와 다르게 학습 프로세스에 의해 변경되면서 공변량 시프트가 의도치 않게 동반됨
프로뎍션 환경에서 공변량 시프트는 일반적을 환경, 애플리케이션 사용 방식이 크게 변함에 따라 발생함

예를 들어, 모델이 무료 사용자가 유료 사용자로 전환할 가능성을 예측한다고 가정할 때 사용자의 소득 수준을 피처로 잡는다. 그러나, 최근 회사의 마케팅 부서는 현재보다 더 소득이 높은 사용자를 끌어들이는 캠페인을 시작했으므로, 모델의 입력 분포가 변하지만 ㅅ호득이 동일할 때 사용자의 전환 확률은 여전히 동일함

-실제 입력 분포가 훈련 입력 분포와 어떻게 다를지 미리 알 수 있다면 중요도 가중치 조정(importance weighting)과 같은 기술로 현실 데이터에 잘 작동하도록 모델을 훈련할 수 있음

=> 중요도 가중치 조정은
실제 입력 분포와 학습 입력 분포 간의 밀도 함수 비율을 추정하고,
이 비율에 따라 학습 데이터에 가중치를 부여하고 이 가중치 데이터로 ML 모델을 학습함
그러나 현실에서는 분포가 어떻게 변하는지 미리 알 수 없어서, 모델을 새로운 미지의 분포에 강건하도록 선제적으로 학습시키는 일은 어려움.

(2) 레이블 시프트(Label shift)
레이블 시프트는 P(Y)가 변하지만 P(X|Y)가 동일하게 유지되는 경우를 말하며 사전 시프트, 사전 확률 시프트, 목표 시프트라고 함
출력 분포가 변하지만 주어진 출력에 대한 입력 분포는 동일하게 유지되는 경우로 생각함
위에서 공변량 시프트는 입력 분포가 변하는 경우로, 입력 분포가 변하면 출력 분포도 변해 공변량 시프트와 레이블 시프트가 동시에 발생함
공변량 시프트에 대한 유방암 예씨에서 40세 이상 여성이 추론 데이터보다 훈련 데이터에 더 많아 양성 레이블 비율이 훈련 과정에서 더 높은데,
훈련 데이터에서 유방암에 걸린 사람 A를 무작위로 선택하고, 테스트 데이터에서 유방암에 걸린 사람 B를 무작위로 선택한다면 A와 B가 40세 이상일 확률은 동일함

=> 즉, P(Y), 즉 유방암에 걸린 사람이 40세 이상일 확률은 동일하여, 레이블 시프트에 해당함
그러나 공변량 시프트가 반드시 레이블 시프트를 동반하는 것은 아님
예를 들어 여성이 유방암에 걸릴 확률을 줄여주는 예방약이 있는데,
확률 P(X)는 모든 연령대의 여성에 대해 감소하므로 공변량 시프트에 해당하지 않음
하지만, 유방암에 걸린 사람의 경우 연령 분포가 동일하게 유지되므로 이것은 여전히 레이블 시프트임
레이블 시프트는 공변량 시프트와 밀접하게 관련되므로 모델이 감지하고 레이블 시프트에 맞게 조정하는 방법은 공변량 시프트 시의 조정 방식과 비슷함

(3) 개념 드리프트(Concept drift)
사후 시프트(posterior shift)라고 하는 concept drift는 입력 분포가 동일하게 유지되지만 정해진 입력에 대한 출력의 조건부 분포가 변하는 경우임
동일한 입력, 상이한 출력으로
주책 관련 피처를 기반으로 주택 관련 피처를 기반으로 주택 가격을 예측하는 모델을 가정하면, 샌프란시스코에 있는 아파트가 코로나 19 이전 200달러였지만, 초기에는 많은 사람들이 샌프란시스코를 떠나 150만 달러가 됨
많은 경우 개념 드리프트는 주기적거나 계쩔적임
승차 공유 가격은 주중과 주말 사이 변하고, 항공권 가격은 휴가철에 올라감
기업들은 주기적, 계절적 드리프트를 처리하기 위해 여러 모델을 사용ㅎ마

일반적인 데이터 분포 시프트

현실에서 모델 성능을 저하할 수 있는 몇가지 변화 유형이 있는데,
바로 피처 변화(feature change) 이다.
신규 피처가 추가되거나, 이전 피처가 제거되거나, 피처 값의 가능한 범위가 변한 경우이다.
모델이 '연령' 피처에 연 단위를 사용하다가 이제는 '월' 단위로 사용한다면 해당 피처 값의 범위가 변하게 됨
레이블 스키마 변화(label schema change) 는 Y 값의 가능한 범위가 변하는 경우이다. 레이블 시프트의 경우 P(Y)는 변하지만 P(X|Y)는 그대로 유지된다.
반면 레이블 스키마가 변하면 P(Y)와 P(X|Y)가 모두 변하게 된다. 스키마는 데이터 구조를 설명하므로 특정 작업에 대한 레이블 스키마는 해당 작업의 레이블 구조를 설명하므로, 클래스를 정숫값에 대응시키는 딕셔너리는 스키마이다.
레이블 스키마 변화는 제품이나 문서에 대한 범주화 같은 고차원 카디널리티 작업(클래스가 많은 작업)에서 흔하게 발생함
한 번에 한 가지 유형의 시프트만 발생하는 법은 없고, 모델의 여러 유형의 drift가 한꺼번에 발생할 수 도 있다.

데이터 분포 시프트 감지

데이터 분포 시프트는 모델 성능이 저하될 때만 문제가 됨
첫 째로, 프로덕션 환경에서 모델의 정확도 관련 지표를 모니터링하면서 변화를 확인하는 것이다.
여기서의 변화는 '감소'를 의미하지만, 특별한 까닭 없이 모델의 정확도가 오르고, 크게 변동하는 것도 포함한다
정확도 관련 지표는 모델의 예측값을 그라운드 트루스 레이블과 비교하는 식으로 계산하는데, 모델 개발 중에는 레이블을 이용할 수 있지만 프로덕션 환경에서는 항상 이용 가능한 것이 아니고 이용 가능하더라도 '자연 레이블'에서 이야기했듯 보통 지연 입수된다.
합리적인 시간 안에 레이블을 이용가능 하면 모델 성능에 대한 가시성을 확보할 수 있다.
그라운드 트루스 레이블이 사용 불가하거나 너무 지연돼 유용하지 않다면 대신 관심 있는 다른 분포를 모니터링할 수 있다. 관심 있는 분포는 입력 분포 P(X), 레이블 분포 P(Y), 조건부 확률 분포 P(X|Y)와 P(Y|X) 임
입력 분포를 모니터링하기 위해 그라운드 트루스 레이블 Y를 알필요는 없지만, 레이블 분포와 두 조건부 분포를 모니터링 하려면 Y를 알아야 한다.
연구자들은 대상 분포로부터 레이블 없이 레이블 시프트를 파악하고 감지하려고 노력해 왔고 한가지 사례는 블랙바트 시프트 추정이다.
업계에서는 대부분 드리프트 감지 방법을 입력 분포, 특히 피처 분포의 변화를 감지하는데 중점을 준다.

통계적 방법

많은 회사에서 두 분포가 동일한지 파악하는데 사용하는 방법은 최소/최대/평균/중앙값/분산/다양한 분위수/왜도/첨도 같은 통계량을 비교하는 것임
추론하는 동안 피처의 중앙값과 분산을 계산하고 훈련하는 동안 계산한 지표와 비교한다.
텐서플로 익스텐디드의 내장 데이터 검증 도구 또한 요약 통계량을 이용해 훈련 데이터와 서빙 데이터 간의 괴리 또는 서로 다른 날짜의 훈련 데이터 간 시프트를 감지한다
그러나 평균, 중앙값, 분산은 요약 값으로 유용한 분포에 한에서만 유용해서 지표가 크게 다르면 추론 시 분포가 훈련 시 분포에서 상당히 시프트했을 수 있고, 지표가 유사하더라도 시프트가 없으리라는 보장은 없음
보다 정교한 방법은 2-표본 가설 검정, 2-표본 검정을 사용해 두 모집단(두 데이터셋) 간의 차이가 통계적으로 유의한지 확인하는 방법이다.
통계적으로 유의한 차이의 경우 이것이 샘플링으로 인한 산포 때문에 발생한 무작위 변동일 가능성은 낮음. 이 차이의 원인은 두 모집단이 서로 다른 분포에서 발생했기 때문임

어제 데이터를 원천 모집단으로, 오늘 데이터를 대상 모집단으로 뒀을 때 통게적으로 다르다면 내재된 데이터 분포가 어제와 오늘 사이 시프트 했을 가능성이 높음
주의할 점은 차이가 통계적으로 우의하더라도 실용적으로 의미가 크지 않을 수 도있음.
상대적으로 적은 샘플에서 차이가 감지됐따면 아마 심각한 차이일 것이라고 새악하는 것도 괜찮은 휴리스틱이고, 반대로 감지하는데 샘플이 엄청나게 많이 필요하다면 그 차이는 크게 걱정할 가치가 없다고 판단할 수 있음
기본 2-표본 검정은 KS 또는 KS검정이라고 하는 콜모고로프-스미르노프 검정이며, 비모수 통계 검정으로 내재 분포에 대한 어떠한 매개변수도 필요하지 않는다
내재 분포에 대한 가정을 두지 않아 모든 분포에 적용 가능하지만,
KS 테스트는 1차원 데이터에만 적용할 수 있어, 모델의 에측과 레이블이 1차원(스칼라 숫자)이면 KS 검정은 레이블 또는 예측 시프트를 감지하는 유용하다.

그러나, 고차원 데이터에는 작동하지 않는다. 주로 피처는 고차원이기 때문에 KS 검정은 연산 비용이 높고 오탐지 경고를 너무 많이 생성할 수 있다.
또 다른 검정은 최소 제곱 밀도 함수 차이 추정 방법 기반의 알고리즘인 최소 제곱 밀도 차이 (least-squares density difference) 검정과, 최대 평균 불일치(MMD, maximum mean discrepancy), 다변량 2-표본 검정을 위한 커널 기반 기법과 그 변종인 학습된 커널(MMD, Learned Kernel MMD)가 있음

MMD는 연구자들 사이에서는 인기가 있지만 업계에서 MMD를 사용하는 회사는 드묾
2표본 검정은 고차원 데이터보다 저차원 데이터에서 더 잘 작동할 때가 많아 2-표번 검정을 수행 전 데이터의 차원을 줄이는 편이 좋음

<시프트를 감지하기 위한 시간 척도 윈도>

모든 시프트 유형이 돌일하지 않아서 어떤 것은 찾아내기 어려움
변화는 서로 다른 속도로 발생하고 갑작스러운 변화는 점진적인 변화보다 감지하기 쉬움.
시프트는 공간과 시간이라는 두 차원에서도 발생할 수 있 는데, 공간적 시프트는 접속 지점이 달라짐에 따라 발생하는 시프트로, 애플리케이션에 새로운 사용자 집단이 생기거나 애플리케이션이 다른 유형의 디바이스에 제공되는 경우다.
시간적 시프트는 시간이 지남에 따라 발생하는 시프트임
시간적 시프트를 감지하는 일반적인 접근 법은 ML 애플리케이션에 대한 입력 데이터를 시계열 데이터로 처리하는 것임
시간 척도 윈도는 시간적 시프트를 다룰 때 데이터를 살펴보는 기준으로, 우리가 감지할 수 있는 시프트 수준에 영향을 미침
데이터에 주 단위 주기가 있으면 일주일 미만의 시간 척도는 해당 주기를 감지 하지 못함.
9일부터 14일 까지의 데이터를 원본 분포로 사용하면 15일 자는 마치 시프트 한 것 처럼 보이지만, 1일부터 14일 데이터를 원본 분포로 사용하면 15일차의모든 데이터 포인트는 원본가 동일한 분포에서 생성된 것처럼 보임

=> 계절적인 변화로 인해 시프트가 교란되면 시간적 시프트를 감지하기 어려움
시간에 따른 실행 통계를 계산 할 때 누적 통계(cumulative statistics) 와 슬라이딩 통계(sliding statistics) 을 구별해야 함
'슬라이딩 통계'는 단일 시간 척도 윈도(예: 한 시간) 내에서 계산, '누적 통계'는 더 많은 데이터로 지속 업데이트 함
-각 시간 척도 윈도의 시작 시점마다 슬라이딩 정확도는 재설정되지만 누적 슬라이딩 정확도는 재설정되지 않음
- 누적 통계는 이정 창 정보가 포함되어 특정 기간에 발생한 사건을 파악하기 어려울 수 있음. 16-18시에 갑자기 정확도가 떨어지는 현상은 누적 정확도에서는 잘 드러나지 않을 수 있음
시간 영역의 데이터를 다루는 일은 복잡하고, 시계열 분해 등 시계열 분석 기술에 대한 지식이 필요함
현재 많은 회사에서 훈련 데이터 분포를 기본 분포로 사용해 특정 세분화 수준, 시간 별/일별로 프로덕션 데이터 분포를 모니터링함
시간 척도 윈도가 작을수록 데이터 분포의 변화를 더 빨리 감지할 수 있음
윈도가 너무 작으면 시프트에 대한 오탐지 경보로 이어질 수 있음
일부 플랫폼, 모니터링 같이 실시간 데이터 분석을 처리하는 플랫폼은 병합 연산을 제공해 크기가 작은 시간 척도 윈도에 대한 통계를 병합해 크기가 큰 시간 척도 윈도에 대한 통계를 생성할 수 있음
관심 대상 데이터 통계를 시간 별로 계산한 다음 시간별 통계 값 모음을 일별 보기 기준으로 병합함
보다 발전한 모니터링 플랫폼은 전체 통계를 자동으로 분석하는 근본 원인 분석(root cause analysis ; RCA) 기능을 시도함 => 시간 시프트의 크기를 다양하게 적용해 데이터 변화가 발생한 시간 윈도를 정확히 감지함

데이터 분포 시프트 해결

기업이 데이터 시프트를 해결하는 방식은 해당 기업의 ML 인프라가 얼마나 잘 구성되어 있는지에 달려 있음
모델을 재훈련하는 최적 빈도는 중요한 결정 사항이지만 많은 기업에서는 실험 데이터 대신 직감을 바탕으로 결정함
모델이 프로덕션 환경의 새로운 분포에서 잘 작동하도록 하는 세 가지 주요 접근법이 있음
(1) 대규모 데이터셋으로 훈련하는 방법
훈련 데이터셋이 충분히 크다면 통합적인 분포, 프로덕션 환경에서 모델이 마주할 모든 데이터 포인트를 가진 분포를 학습할 수 있을 것으로 기대함

(2) 새로운 레이블을 요구하지 않으면서 훈련된 모델을 대상 분포에 적응시키는 방법
대상 분포의 레이블을 사용하지 않고 공변량 시프트와 레이블 시프트 모두에 대한 모델 예측값을 수정하기 위해 조건부와 주변 분포의 커널 임베딩과 함께 인과적 해석을 사용함
또한 도메인 불면의 표현 학습, 즉 변하는 분포에서 변하지 않는 데이터 표현을 학습하는 비지도 도메인 적응 기법도 제안했으나 연구가 많이 이루어지지 않고, 업계에서도 도입되지 않았음

(3) 대상 분포에서 레이블이 지정된 데이터를 가져와 모델을 재훈련하는 방법
업계에서 흔히 수행되는 방법이나 모델을 재훈련하는 일은 간단하지 않음
재훈련은 이전 데이터와 신규 데이터 모두를 합쳐 모델을 처음부터 다시 훈련하거나 신규 데이터로 기존 모델 훈련을 이어나가는 일을 의미한다.
후자는 미세 조정이다.

모델을 재훈련할 때 두가지를 결정해야 하는데,
[1] 모델을 처음부터 훈련할지(무상태 재훈련) 혹은 마지막 체크포인트에서 이어서 훈련할지(상태 유지 훈련)을 결정하고
[2] 사용할 데이터, 지난 24시간/지난 주/지난 6개월 또는 데이터가 드리프트를 시작한 시점의 데이터 중 선택한다.

어떤 재훈련 전략이 가장 적합한지는 실험을 수행해야 할 수 도 있음
데이터 시프트 관련 논문에서는 도메인 적응과 전이 학습이 데이터 시프트와 언급되는 것을 종종 볼 수 있는데, 분포를 도메인으로 간주하면 모델을 새로운 분포에 어떻게 적응 시킬 것인지에 대한 고민은 모델을 상이한 도메인에 어떻게 적응시킬지에 대한 고민과 유사하다
결합 분포 P(X,Y) 학습을 수행해야 할 작업으로 간주하면, 모델이 훈련이 이뤄진 한쪽 결합 분포에서 다른 쪽 결합 분포로 적응시키는 것은 전이 학습의 한 형태로 구조화 할 수 있음
전이 학습은 특정 작업을 위해 개발한 모델을 두 번째 작업의 모델에 대한 시작점으로 재사용 하는 방법을 말한다. 차이점은 전이 학습을 사용 할 때 두 번째 작업을 위해 기본 모델을 처음부터 재훈련 하지는 않는 다는 점이다.
반면에 모델을 새로운 분포에 적응시키려면 모델을 처음부터 다시 훈련해야 할 때도 있다.
데이터 분포 시프트 문제를 꼭 시프트가 발생하고 나서 해결하라는 법은 없고, 시스템 자체를 시프트에 더욱 강건하게 설계할 수 도 있다.
시스템은 다양한 피처를 사용하고 각 피처는 서로 다른 속도로 시프트 한다.
모델 피처를 선택할 때 피처 성능과 안정성 사이의 균형을 고려해야 한다.
시스템이 시프트에 더 쉽게 적응하도록 설계할 수 있는데, 시장마다 별개의 모델을 사용한다면 필요시에만 개별 모델을 업데이트 한다.
프로덕션 환경의 모델에 발생하는 성능 저하 문제에 반드시 ML 솔루션이 필요하지는 않는데, 오늘날 많은 ML 장애는 여전히 사람의 실수로 인해 발생한다. 모델 장애가 사람의 실수로 인해 발생했다면 해당 오류를 찾아 수정해야 한다.
데이터 시프트는 감지하기도 어렵지만 원인을 파악하는 것이 더 어려울 수도 있다.

8-3. 모니터링과 관찰 가능성

회사에서 ML 시스템에 여러 문제가 발생할 수 있다는 사실을 깨닫고 프로덕션 환경 ML 시스템에 대한 모니터링과 관찰 가능성(observability)에 투자하기 시작했음
모니터링과 관찰 가능성은 같은 의미로 사용되지만 엄연히 다름
모니터링은 문제가 발생했을 때 판단에 도움이 될 수 있는 다양한 지표를 추적, 측정, 기록하는 작업이고 관찰가능성은 시스템에 대한 가시성을 제공하는 방식으로 시스템을 설정하는 것을 의미한다.
이때 가시성은 무엇이 잘못됐는지 조사하는데 도움이 된다
이런식으로 시스템을 설정하는 프로세스를 인스루먼테이션 이라고 하는데,
인스루먼테이션은 함수에 타이머 추가하기, 피처의 NaN 개수 세기, 시스템을 통해 입력이 변환되는 방식 추적하기, 비정상적으로 긴 입력과 같이 비정상적인 이벤트 로깅하기 등이 있다.
관찰 가능성은 모니터링의 일부를 구성하는데, 일정 수준의 관찰 가능성 없이는 모니터링이 불가능하다.
모니터링에서 가장 중요한 것은 지표인데, ML 시스템도 소프트웨어 시스템이므로 모니터링 해야 하는 최우선 지표는 '운영 지표' 이다.
운영 지표는 시스템 상태를 전달하도록 설계 됐고, 일반적으로 시스템이 실행되는 네트워크, 시스템이 실행되는 머신, 시스템이 실행하는 애플리케이션 등 세 수준으로 나뉜다.
운영 지표의 예로는 레이턴시, 스루풋, 모델이 지난 1분/1시간/1일 동안 수신한 예측 요청수, 200대의 오류 코드로 반환되는 요청의 비율, CPU/GPU 사용률, 메모리 활용률등이 있다.

예를 들어 프로덕션 환경 소프트웨어 시스템의 매우 중요한 특성으로 가용성 이 있는데, 가용성은 사용자에게 합리적인 성능을 제공하는 시스템의 사용 가능한 시간이 얼마인지를 의미한다. 이 특성은 Uptime(업타임)으로, 시스템이 가동된 시간에 대한 백분율로 측정된다.
시스템 가동 여부를 결정하는 것은 서비스 수준 목표(service level objective; SLO) 또는 서비스 수준 계약(service level agreement; SLA)에 정의돼 있다.
예를 들어 SLA에 레이턴시 중앙값이 200밀리초 미만이고 99번째 백분위수가 2초 미만이 될 때 서비스가 가동되는 것으로 간주하게끔 정리할 수 있다.

서비스 제공자는 보장 가동 시간(전체 시간 중 99.99%)을 미리 정한 SLA로 제공할 수 있고, 이것이 충족되지 않으면 고객에게 환불을 제공한다.
한편 ML 시스템에서 시스템 상태란 시스템 가동 시간 이상의 의미로 확장되는데, ML 시스템이 작동하지만 예측값이 엉망이라면 사용자는 만족스럽지 않기 때문에 ML 모델의 상태를 알려주는 ML 관련 지표가 있다.

<머신러닝 관련 지표>
ML 관련 지표 중 모니터링 해야 하는 네 가지 아티팩트로 모델 정확도 관련 지표, 예측값, 피처, 원시 입력값이 있다.
ML 시스템 파이프라인의 서로 다른 네 단계에서 생성되는데, 아티팩트가 파이프라인의 각 단계를 더 많이 통과했을수록 변환이 더 많이 일어진 것이며, 해당 아티팩트 변화는 그러한 변환 중 하나 이상의 오류로 발생했을 가능성이 높다.
아티팩트가 더 많이 변환될수록 더 구조화되고 실제 관심 대상인 지표에 더 가까우므로 모니터링이 더 쉬워진다.

[1] 정확도 관련 지표 모니터링

시스템이 예측에 대한 사용자 피드백을 수신하면 이를 기록하고 추적해야한다.
일부 피드백으로 자연 레이블을 추론하고 이것을 모델의 정확도 관련 지표를 계산할 수 있다.
정확도 관련 지표는 모델 성능 저하 여부를 확인하는데 가장 직접적으로 도움이 되는 지표다.
피드백은 자연 레이블을 직접 추론하는 데 사용하기 어렵더라도 ML 모델 성능의 변화를 감지하는 데는 사용할 수 있다.
사용자 피드백을 수집하도록 시스템을 설계할 수도 있다.

[2] 예측값 모니터링

예측값 아티팩트는 가장 일반적인 모니터링 대상임
회귀 작업에서 각 예측값은 연속 값이며, 분류 작업에서 각 예측은 예측된 범주에 해당하는 이산 값이다.
각 예측값은 보통 숫자(저차원)에 불과해 시각화하기 쉬워 요약 통계량을 계산하거나 해석하기도 쉽다.
분포 시프트 감지를 위해 예측값을 모니터링하기도 하는데, 예측값은 차원이 낮아 2-표본 검증을 수행하기도 보다 쉽다.
예측 분포 시프트는 입력 분포 시프트에 대한 프락시이기도 하다.
입력과 출력을 연결하는 함수가 변하지 않는다고 가정한다면, 즉 모델 가중치와 편향 값이 변하지 않는다면 예측 분포의 변화는 일반적으로 내재된 입력 분포의 변화를 의미한다.
예측 값으로 '아니요'가 비정상적으로 계속 나오는 등 이상한 일이 발생하는지도 모니터링 하기도 함

[3] 피처 모니터링

-업계의 ML 모니터링 솔루션은 모델 입력으로 사용하는 피처와 원시 입력값에서 최종 피처로의 중간 변환이라는 두 측면에서 피처 변화를 추적하는데 주안점을 둠

피처는 원시 입력 데이터와 비교하면 사전에 정의한 스키마에 따라 잘 구조화돼있음
피처 모니터링의 첫 번쨰 단계는 피처 검증(featrue validation)임
=> 피처가 기대하는 스키마를 잘 따르는지 확인함
: 스키마는 일반적으로 훈련 데이터 및 상식 선에서 생성됨
프로덕션 환경에서 이러한 기대치가 어긋나면 내재 분포에 이동이 발생했을 수 있음

<특정 피처에 대해 확인해볼 수 있는 몇 가지 사항>

 - 피처의 최솟값, 최댓값 혹은 중앙값이 허용 가능한 범위 내 인가?
 - 피처 값이 정규 표현식 형식을 만족하는지?
 - 모든 피처 값이 미리 정의된 집합에 속하는지?
 - 두 피처 값 간에 상정한 대소 관계를 만족하는지?

피처는 종종 테이블 형태로 구성되어 (각 열은 피처, 각 행은 데이터 샘플) 피처 검증을 테이블 테스트 혹은 테이블 검증이라고 하며, 데이터에 대한 단위 테스트라 부르는 사람도 있음
기본 피처 검증을 수행하는 데 도움이 되는 다양한 오픈 소스 라이브러리가 있으며 가장 많이 사용하는 두 가지는 그레이트 익스펙테이션즈와 AWS 에서 제공하는 Deequ (디큐)
기본 피처 검증 외에도 2-표본 검정을 사용해 피처 혹은 피처 집합의 내ㅣ재 분포가 시프트 했는지 감지할 수 있음
피처 혹은 피처 집합은 보통 고차원이라 검정을 수행하기 전 차원을 줄여야함. 그렇지 않으면 검정 효율성이 떨어짐

<피처 모니터링을 수행할 때 네 가지 주요 문제>
(1) 회사에서 운영하는 프로덕션 환경 모델이 수백 일 수 있으며 각 모델은 보통 피처를 수백개 사용함
: 요약 통계량을 계산하는 등 간단한 작업이더라도 매시간 모든 피처에 대해 수행한다면 필요 연산양뿐 아니라 메모리 사용 측면에서도 비용이 높음
너무 많은 지표를 추적, 지속적으로 계산하면 시스템 속도가 느려지고 사용자가 경험하는 레이턴시가 증가 및 시스템 이상 감지 시간이 늘어남

(2) 추적 기능은 디버깅에는 유용하지만 모델 성능 저하를 감지하는 데 그다지 유용하지 않음
: 크기가 작은 분포 시프트는 치명적인 장애를 야기할 수 있지만 실제로 개별 피처의 사소한 변화는 모델 성능에 전혀 영향을 미치지 않음
피처 분포는 항상 변하며 변화의 대부분은 대체로 무해함
피처가 드리프트된 것처럼 보일 때마다 경고를 받는면 경고의 양에 압도되고, '경고 피로' 인, 경고가 너무 자주 발생해 주의를 기울이지 않게 되는 현상을 겪을 수 있음
피처 모니터링에서 중요한 문제는 어떤 피처 시프트가 중요하고 중요하지 않는지를 결정하는 것임

(3) 피처 추출은 종종 다양한 서비스(빅쿼리, 스노우플레이크)에서 다양한 라이브러리(판다스, 스파크)를 사용해 다양한 단계(결측값 채우기, 표준화)에서 이뤄짐
: 피처 추출 프로세스에 대한 입력으로 관계형 데이터베이스가 출력으로 넘파이 배열이 있을 수 있음
피처에서 유해한 변화를 감지하더라도 이 변화가 내재하는 입력 분포의 변화로 인한 것인지, 혹은 여러 처리 단계 중 다양한 하나 이상의 오류로 인한 것인지 감지 자체가 불가능 할 수 있음

(4) 피처가 따르는 스키마가 시간에 따라 바뀔 수 있음
: 스키마 버전을 지정하고 각 피처를 기대 스키마에 매핑할 방법이 없다면,
보고된 경고의 원인은 데이터 변화가 아니라 스키마에 불일치해서일 수 있음

이러한 우려에도 피처 모니터링은 중요한데, 피처 공간의 변화는 ML 시스템 상태를 이해하는데 매우 유용한 신호가 됨

<원시 입력 모니터링>

피처 변화는 데이터 변화가 아니라 처리 단계의 문제로 인해 발생하기도 함
원시 입력이 처리되기 전에 모니터링을 한다면, 원시 입력 데이터는 소스/구조/형식이 다양해 모니터링하기 쉽지 않음
오늘날 많은 ML 워크플로 설정 방식상 ML 엔지니어는 원시 입력 데이터에 직접 접근할 수 없음
원시 입력 데이터는 데이터를 처리해 데이터 웨어하우스 같은 곳으로 이동하는 데이터 플랫폼 팀이 관리하는 경우가 많음
ML 엔지니어는 데이터가 이미 부분적으로 처리된 데이터 웨어하우스에서만 데이터를 질의할 수 있음
원 시입력 모니터링은 데이터 과학 팀이나 ML 팀이 아닌 데이터 플랫폼 팀이 담당하는 경우가 많음

모니터링 도구

복잡한 시스템에 대한 지표를 측정, 추적, 해석하기는 쉽지 않고 엔지니어는 모니터링에 다양한 도구를 활용함
업계에서는 지표, 로그, 추적 등 세 가지를 모니터링의 큰 기둥으로 여기지만 셋을 구별하기는 어려움
추적은 로그의 한 형태이고 지표는 로그에서 계산할 수 있음.
모니터링 시스템 '사용자' 관점으로 도구 집합을 살펴보면 도구 집합에는 로그, 대시보드, 경고 가 있음

<로그>

전통적인 소프트웨어 시스템은 로그를 사용해 런타임에 발생한 이벤트를 기록함
이벤트랑 발생한 시점 혹은 그 이후에 디버깅과 분석 목적으로 시스템 개발자가 관심을 가질 만한 모든 것임
예를 들어 컨테이너 구동이 시작된 시점, 필요한 메모리 양, 함수가 호출된 시점, 함수가 실행을 완료한 시점, 함수가 호출하는 다른 함수, 함수 입출력 등이 있음
충돌, 스택 추적, 오류 코드 또한 로깅함
로그 양이 매우 빠르게, 매우 크게 커질 수 있는데, 문제가 발생하면 원인으로 추정되는 이벤트에 대해 로그를 검색해야 함
오늘날의 시스템은 컨테이너, 스케줄러, 마이크로서비스, 다중 언어 지속성, 메시 라우팅, 임시 오토 스케일링 인스턴스, 서버리스 람다 기능 등 다양한 구성 요소로 이뤄짐
요청은 전송된 후 응답이 수신될 때까지 20-30회 서로 통신을 수행할 수 있고, 사건 발생을 감지하는 일보다 문제가 어느 지점인지 찾아내는 일이 더 어려움

따라서 이벤트를 로깅할 때는 가능한 한 나중에 찾아내기 쉽도록 해야함
마이크로 서비스 아키텍처를 사용하는 방식을 분산 추적(distributed tracing) 이라고 함
: 각 프로세스에 고유한 ID를 부여해 문제가 발생했을 때 오류 메시지에 해당 ID가 포함되도록 함
이를 통해, 관련 로그 메시지를 검색하고 이벤트마다 나중에 필요할 수 있는 모든 메타데이터(발생 시간, 발생 서비스 ,호출된 함수, 프로세스 관련 사용자 등)을 기록해둠
ML 유스 케이스 중 시스템에서 비정상적인 이벤트를 탐지하는 이상 탐지가 있는데, 보다 정교한 모델은 각 이벤트를 일반/비정상/예외/오류/치명적 오류 등을 우선순위 측면에서 분류함
많은 기업에서 로그를 배치 처리하는데, 로그를 대량 수집한 다음 주기적으로 SQL을 징의해 특정 이벤트를 찾거나 스파크, 하듑 또는 하이브 클러스터 내의 배치 프로세스를 사용해 로그를 처리함
: 분산 맵리듀스 프로세스를 활용해 스루풋을 늘릴 수 있어 로그가 효율적임
=> 로그를 정기적으로 처리하는 형태라 로그에서 이상 현상이 발생하는 즉시 발견하려면 이벤트가 로깅되는 동시에 처리될 수 있어야 하므로 로그 처리가 스트림 처리 문제가 됨
이 때, 카프카나 아마존 키네시스 같은 실시간 전송을 사용해 이벤트가 로깅되는 즉시 전송함
특정한 특성을 지닌 이벤트를 실시간으로 검색하려면 KSQL이나 플링크 SQL 같은 스트리밍 SQL 엔진을 활용함

<대시보드>

숫자만 보면 의미를 파악하기 어렵지만 그래프로 시각화하면 숫자 사이의 관계를 알게 되는 경우가 있음
지표를 시각화하는 대시보드는 모니터링에 필수임
대시보드의 또 다른 용도는 엔지니어가 아닌 사람도 모니터링하게 해줌
모니터링은 시스템 개발자뿐 아니라 제품 관리자, 비즈니스 개발자를 비롯해 엔지니어링 직군이 아닌 이해관계자에게 필요함
대시보드상 지표가 과도하게 많으면 부패한 대시보드(dashboard rot)이라는 현상으로 역효과가 날 수 있음
특정 작업에 필요한 상위 수준의 정보를 보여주기 위해서는 올바른 지표를 선택하거나 하위 수준 지표를 추상화하는 작업이 중요함

<경고>

모니터링 시스템에서 의심스러운 무언가를 감지했다면 적절한 대상에게 경고를 보내야 함
경고는 [1] 경고 정책 [2] 알림 채널 [경고 설명] 이 있음

[1] 경고 정책

경고가 발생할 조건 지정
지표가 임곘값을 넘어설 때 경고를 생성할 수 있으며, 이때 특정 기간을 설정할 수 도 있음
모델 정확도가 90% 미만이거나 HPPT 응답 레이턴시가 10분이상이면 알림을 받음

[2] 알림 채널

조건이 충족되면 알림을 받을 사람을 지정함
알림은 모니터링 서비스인 아마존 클라우드워치나 GCP 클라우드 모니터링 등에 표시되지만 모니터링 서비스를 사용하지 않아도 책임자에게 연락할 필요가 있음

[3] 경고 설명

경고를 받은 사람이 무슨 일이 일어나고 있는지 이해하는 데 도움을 줌
경고를 받을 대상에 따라 경고 처리에 도움이 될 만한 반복 수행 절차와 작업 모임인 완화 지침 또는 런북을 제공할 필요가 있음
경보 피로(alert fatigue)는 실제로 발생하는 현상으로, 중요한 경고만 될 수 있도록 조건을 의미 있게 설정하는 것이 좋음

관찰 가능성

2010년 중반부터 업계에서 '오니터링' 대신 '관찰 가능성' 이라는 용어를 사용하기 시작함
모니터링은 시스템 내부 상태와 출력 간의 관계에 특별한 가정을 두지 않음
시스템 외부 출력을 모니터링해서 시스템 내부에 '언제' 발생했는지 파악하고, 외부 출력의 문제가 '무엇'인지 파악하는 데 도움이 된다는 보장은 없음
관찰 가능성은 제어 이론에서 파생된 개념으로 '런타임에 시스템에 수집한 [출력]을 사용해 소프트웨어의 복잡한 동작을 이해하는 데 더 나은 가시성을 제공'함을 의미함

원격 측정

런타임에 수집한 시스템 출력을 원격 측정(telemetry) 라고 함
원격 측정이라는 용어 또한 지난 10년 사이 소프트웨어 모니터링 업계에 등장했는데,
'멀리 떨어져서 상태를 재는 일'을 의미해, 모니터링 맥락에서는 클라우드 서비스나 고객 디바이스에서 실행되는 애플리케이션처럼 원격 구성 요소에서 수집된 로그와 지표를 뜻함

관찰 가능성은 기존 모니터링보다 더 강력한 가정에 기반함
시스템 내부 상태는 외부 출력에 대한 지식으로 추론할 수 있다고 상정함
내부 상태는 '현재GPU 사용률' 과 같은 현재 상태일 수도 있고 '전일 GPU 평균 사용률' 과 같은 과거 상태일 수도 있음
관찰 가능한 시스템에 문제가 발생하면 시스템 로그와 지표만 보고도 무엇이 잘못됐는지 파악할 수 있음
관찰 가능성이란 시스템 런타임에 대한 충분한 정보를 수집하고 분석하는 방식으로 시스템을 계측함
모니터링의 중심은 지표이며, 지표는 일반적으로 집계(aggregation)을 통해 산출됨
관찰 가능성을 통해 보다 세분화된 지표를 사용할 수 있어, 모델 성능이 언제 저하되는지 뿐 아니라 입력 중 어떤 유형에서 어느 사용자 하위 그룹에서, 어느 시간에 저하되는지도 알 수 있음

예를 들어, 다음 요구 조건을 해결하기 위해 로그에 질의할 수 있어야 하는데
지난 1시간 동안 모델 A가 잘못된 예측값을 반환한 사용자를 모두 우편 번호별로 그룹화해 나타내라 / 지난 10붕 동안 발생한 요청의 이상치를 나타내라 / 주어진 입력에 대한 중간 출력값을 모두 나타내라 등과 같이, 시스템 출력을 태그와 기타 식별 키워드로 사용해 로깅하면 나중에 출력을 데이터의 서로 다른 차원에 따라 슬라이싱 하거나 격자로 추출해낼 수 있음
ML 에서 관찰 가능성은 해석 가능성을 포함함
해석 가능성은 ML이 작동하는 법을 이해하는 데 도움이 되며, 관찰 가능성은 ML 모델을 비롯한 전체 ML 시스템이 작동하는 방식을 이해하는데 도움이 됨
지난 1시간 동안 모델 성능이 저하도니 경우 1시간 동안 이뤄진 모든 잘못된 예측값에 가장 크게 기여한 피처를 해석할 수 있으면, 시스템에서 문제가 발생한 부분과 수정 방법을 파악하는 데 유형함
모니터링은 강력한 개념이지만 본질적으로 수동적인 작업이므로, 감지하기 위해서는 변화가 발생하기를 기다려야 함
모니터링은 문제를 찾아내는 데 도움이 되지만 그것을 수정해주지는 않음

정리
장애를 소프트웨어 시스템 장애(ML과 관련되지 않은 시스템에서 발생하는 장애), ML 관련 장애라는 두 가지 유형으로 구분했는데, 오늘날 ML 장애는 대부분 ML과 관련이 없지만 MLOps 중심으로 한 도구와 인프라가 발전함에 따라 상황은 바뀔 수 있음
ML 관련 장애의 세 가지 주요 원인인 즉 훈련 데이터와 상이한 프로덕션 환경 데이터, 에지 케이스, 퇴행성 피드백 루프가 있음
훈련 데이터와 상이한 프로덕션 환경 데이터와 에지 케이스는 데이터와 관련되있고, 퇴행성 피드백 루프는 시스템 출력 시스템 입력에 영향을 줄 때 발생하므로 시스템 설계와 관련이 있음
데이터 분포 시프트는 공변량 시프트, 레이블 시프트, 개념 드리프트라는 세 가지 시프트 유형이 있음
분포 시프트에 대한 연구는 ML 연구의 하위 분야로 성장하고 있지만 아직 표준화된 내러티브가 정해지지 않았음
변화를 감지하려면 배포된 시스템을 모니터링 해야 하는데, 모니터링은 ML뿐 아니라 프로덕션 환경에 있는 모든 소프트웨어 엔지니어링 시스템에 중요함
모니터링에서 가장 중요한 것은 지표로, 모니터링 지표시 레이턴시/스루풋/CPU 사용률 등 모든 소프트웨어 시스템에서 모니터링해야 하는 운영 지표와 ML 관련 지표 등이 있음
모니터링은 정확도 관련 지표, 예측값, 피처 및 원시 입력값에 적용 가능함
모니터링이 어려운 이유는 지표 연산 비용이 저렴하더라도 지표를 이해하기가 간단하지 않음. 대시보드를 구축해 그래프를 표시하기는 쉽지만 그래프가 드리프트 징후를 나타내는 지, 드리프트가 있다면 그 원인이 내재된 데이터의 분포의 변화인지, 파이프라인의 오류인지 이해하는 일은 훨씬 어려움
숫자와 그래프를 이해하려면 통계를 이해해야 함
프로덕션환경에서는 모델 성능 저하를 감지하는 일이 첫 번째이고, 다음은 시스템을 변하는 환경에 적응시키는 것임

gunny

꿈꾸는 것도 개발처럼 깊게

이전 포스트

[ML] 머신러닝 시스템 설계 : 8장 데이터 분포 시프트와 모니터링

ML

8. 데이터 분포 시프트와 모니터링

8. 머신러닝 시스템 장애 원인

<소프트웨어 시스템 장애>

<머신러닝 한정 장애>

<퇴행성 피드백 루프 감지>

<퇴행성 피드백 루프 교정>

8-3. 데이터 분포 시프트

<데이터 분포 시프트 유형>