Lecture 11: Deployment & Monitoring / Monitoring

https://fullstackdeeplearning.com/spring2021/lecture-11/

Full Stack Deep Learning

 

이미 다 배운거 아님? 아님.

 

입력이 훈련할 때랑 달라질 수 있고, 모델이 낸 결과가 사용자를 바꿀 수 있고, 훈련할 때 있었던 극히 일부의 데이터가 실행되는 등의 문제가 있을 수 있다. 입력이 다른건 악성 유저나 사용 지역이 달라서 색감이 달라진다던지, 모델 출력으로 사람이 바뀌는건 추천시스템. 그 사람은 우리가 추천한 것을 볼거고 그럼 다음 예측이 달라져야 함. 그 다음은 훈련 시에 백만번의 하나 데이터였던 것이라 무시되었었는데 파이프라인에 들어가서 문제 생기면 줄줄히 문제생길 수 있음.

 

데이터가 있다고 치자. 이게 정상임.

 

데이터 분포도가 갑자기 바뀌는 경우. 새로운 도메인이 생겼거나 트렌드가 바뀌었거나

 

서서히 바뀌는 경우. 사용자가 나이들거나 새로운게 꾸준히 증가.

 

주기적으로 바뀌는 경우. 시즌별이거나 시간대별로 사용하는 사람이 바뀌는 경우

 

일시적으로 바뀌는 경우. 제일 어려운 경우라던데 악성유저가 공격하거나 자기 뜻때로 안나온 유저가 휘저어놓거나 시스템이 의도한 대로 행동하지 않았을 경우.

 

근데 이런 경우들은 일부 아니냐?

 

아님. 매우 많음. 악성유저가 휘저어넣고 도망가면 수 많은 일반유저는 달라지니까 나가게되고 엄청난 금전적 손실이.

 

그래서 모니터링 하는데 계획을 세워야 한다. 이건 그 아웃라인.

 

해석이 잘 안됐는데 이해한 만큼만 적겠음. 위로 갈수록 정보는 많지만 측정하기 어려운 구간, 아래로 갈 수록 정보는 적지만 측정하기 쉬운 구간.

내가 돌리고 있는 모델이 정확한지 보려면 모델 정확도를 보는게 좋다. 근데 이 정확도를 보려면 label이 있어도 어려운데 패션 시즌이나 추천시스템 같은 label이 없어서 바로 prediction에 돌리지 못하는 경우도 있다. 자동운전같은 경우 운전자가 개입하면 틀린 예측을 했다고 하는 꼼수도 있겠지만 ??? 하기 때문에 신뢰할 수는 없다.

business metric은 못알아들었고, model inputs and prediction은 내가 짐작하고 있는 예측과 분산 범위 내에 있는지 확인하는거고, System performance는 cpu와 gpu는 얼마나 먹는지 확인하거나 모델이 잘 돌아가는지 버그 확인 가능.

 

모델 배포 시작한 지 얼마 되지 않은 것과 좀 된 후를 비교하자. 첫 윈도우 정하는거는 모델이 아직 멀쩡하겠지.. 라는 구간이나 그냥 슬라이딩 윈도우. 그리고 보통 이정도면 내가 훈련시킨 데이터가 남아있을 테니. 나중에 정하는건 문제에 따라 아니면 한 주든 한 달이든 일정 떨어져서.

그래서 저 둘 거리를 비교하는 distance metrics. 룰 베이스 추천하고 KL divergence는 하지말고 Kolmogorov-Simirnov는 하라고 하더라.

 

도메인 기반해서 이미 알고 있는거를 활용하는거. 좋기도 하니 이것부터 시작해보라 함.

 

머신러닝 하는 사람들은 KL divergence에 익숙하겠지만 모니터링 할 때는 별로다. tail case들에 의해 너무 좌우된다고 함.

위의 방법들은 1d에서 쓸 수 있는 방법이었고 그 이상은 다른거 쓰는 듯.

원래 1차원이 아닌걸 encoder를 통해 차원을 줄이는 방법을 사용함.

 

이해못함..

 

 

 

룰 베이스 규칙 직접 적는것도 제공함.

 

고전적인 소프트웨어 모니터링은 latency 같은건 포함 안 했는데 그것도 포함한다던지, 버그 포착도 힘들고 등.. 앞에서 많이 얘기했던

 

머리에 안들어옴..

 

뒤에거 다 안들렸는데 앞에껀 들림. 모델을 배포했다고 끝! 이 아님. 특별한 경우가 아니면 문제는 무조건 생길꺼고 내가 만든 모델이 잘 작동하고 있는지 까지 책임있게 확인하는 것 까지가 나의 일이다.