인공지능의 기본인 Norm 이다 .

처음 Norm을 공부할 때는 L1, L2 Norm에 대해서만 알고있었다. 

그런데 Gradient Descent를 공부하니 L1,L2 Loss 가 나와서 둘이 같은것인줄 알았지만 달랐다. 

또 다른 말이 있다. L1 L2 regularization 이다. 

이렇게 앞에 L1 L2 는 같지만 뒤에 붙는 말이 다른 경우가 많다 그래서 Norm이란 무엇이고 각각이 어떻게 다른지에 대하여 정리하였다.

 

Norm 이란? 

백터의 크기 또는 길이를 측정하는 방법 

한 점에서 어떤 벡터까지의 거리를 구할 때 사용할 수 있다 

Linear regression을 예로 들면 어떤 Hypothesis H(x)와 실제 정답데이터까지의 거리를 측정하여 다음 Gradient Descent의 강도를 조절 할 수 있다. 

 

Norm 수식
출처 : http://taewan.kim/post/norm/

L1 Norm 

Manhattan Distance, Taxicab geometry라고도 불린다. 

L1 은 절댓값과 연관되어있다. 

위의 Norm 수식에 p=1 을 대입하여 보면     L1 = x의 모든 절댓값들의 합 이 된다 

 

L2 Norm 

Euclidean Norm 이라고도 불린다. 

L2 는 제곱과 연관되어있다. 

위의 Norm 수식에 p=2 를 대입하여 보면 L2 = x제곱의 모든 합에 제곱근 이된다. 

 

Maxium Norm (최대 놈)

Maxium Norm 은 위의 Norm 수식에 p --> 무한대 를 대입하여 보면 

L _inf = max(|x1|,|x2|,|x3|....|xn|)   백터 성분의 최대값을 구하게 된다 

 

 

 

Loss

loss 는 Hypothesis(가설)와 실제 데이터사이의 차이를 구하여 방정식에 적용하여 최대한 데이터와 가설과의 차이를 줄이기 위하여 사용된다.

 

L1 Loss 

실제 데이터와 가설과의 차이를 절대값을 통해 더한다  Least Absolute Deviations 라고도 한다 

데이터의 이상치가 있을 경우 L1은 L2보다 이상치에 영향이 적다 - 제곱근 때문 

 

 

L2 Loss 

실제 데이터와 가설과의 차이를 제곱을 이용하여 더한다 Least Square Error라고도 한다 

L2 Norm 과 다른점은 loss는 벡터 사이의 에러를 효과적으로 구하기 위한것이지 절대적으로 값을 구하자는게 아니다. 

그러므로 루트(제곱근)이 빠졌다. 

위의 그림은 L1 loss 와 L2 loss 로 생성될 수 있는 loss function의 모양중 하나이다.

L1은 절댓값을 이용하다 보니 특정 지점에서 선형적이지 않고 약간 뾰족한 모양이 만들어진다  비선형에는 미분을 적용할 수 없다  

L2는 제곱을 이용하다 보니 계속하여 선형적이다. 

그러므로 경사하강에서 미분을 적용해야할 때 L2가 더 효과적일 수 있다. (고유벡터 조심) 

 

 

L1, L2 regularization 

정규화는 overffiting을 방지하기 위한 중요한 기법이다. 

각 cost function에 정규화 항을 추가하여 더해준다 

각 loss function의 결과에 hyperparameter lambda를 곱해준 정규화 항을 더하였다 

 

 

 

a = [ 0.25, 0.25, 0.25, 0.25]

b = [ 0.5 0.5 , 0 ,0 ] 

일 때 두 벡터의 L1 norm 은 모두 1이 나온다. 

하지만 L2의 경우는 두 벡터의 결과값이 다르다 . 

 

제곱을 이용하는 L2 Norm의 경우 L2는 각 벡터에 대하여 unique한 값이 나오는 반면 L1은 경우에 따라 어떤 항이 없어도 같은 결과가 나올 수 있다. 

그렇게 L1 Norm 은 Feature selection의 효과가 있다 

만약 j(a) = 4a1 + 5a2 + a3  가 나왔을 때 L1 Regularization을 추가하면 a2 또는 a3 가 없어도 j(a)의 결과가 같은 값을 찾을 수 있다. 결과적으로 L1 Regularization 항이 1a1 - 5a2 - a3 가 되어도 j(a)의 결과가 같다면 결과적으로 j(a) = 5a1 이 될 수 있다. ( a2 와 a3 는 feature selection에 의해 사라질 수 있다)

 

 

 

 

 

 

 

 

 

 

참조

https://seongkyun.github.io/study/2019/04/18/l1_l2/"

http://taewan.kim/

 

'Machine Learning > AI를 위한 수학' 카테고리의 다른 글

(1) 딥러닝 구현 기초 - 데이터  (0) 2022.01.15

 

mkdir - 디렉토리 생성

   mkdir -p /home/ubuntu/share  해당 경로에 폴더 생성 - 경로가 없으면 경로도 생성 

   mk -m 644 DIRPATH         644 권한 폴더 생성 

 

mv - 이동 

mv FILE_NAME MOVE_FILE_PATH_AND_NAME   == FILE_NAME을 설정한 경로와 이름으로 움긴다 

mv -f FILE_NAME MOVE_FILE_PATH_AND_NAME == 만약 움길 경로에 해당 파일이 이미 존재하면 덮어쓴다 

mv -b FILE_NAME MOVE_FILE_PATH_AND_NAME  == 만약 움길 경로에 해당 파일이 이미 존재하면 백업한 뒤 이동 

 

cp - 카피

cp EXICT_FILE COPY_FILE_PATH

cp -f EXICT_FILE COPY_FILE_PATH   == 만약 해당 복사경로에 같은 이름의 파일이 있다면 덮어쓰기 한다

cp -R EXICT_DIRECTORY COPY_DIR_PATH   == 폴더안의 모든 하위경로와 파일들을 모두 복사 

 

rm - 삭제 

rm FILE_NAME  == FILE_NAME 삭제

rm -f FILE_NAME == 묻지도 따지지도 않고 삭제 

rm -r DIRECTORY == 디렉토리 삭제 

 

zip - zip으로 압축 unzip - 압축해제

apt-get install zip unzip 

zip ZIP_FILE_PATH.zip [압축할 파일 또는 폴더1] [압축할 파일 또는 폴더2] ....

zip -r zip_test.zip ./*     == 해당 폴더의 모든 파일과 폴더 압축 

unzip ZIP_FILE_PATH.zip  == cwd 에 해당 zip 파일을 압축 해제한다 

unzip ZIP_FILE_PATH.zip -d /home/ubuntu/share     == /home/ubuntu/share 에 압축을 해제한다 

 

tar - tar.gz 파일 압축, 해제

tar 압축하기 : tar -cvf [파일명.tar] [압축할 파일 또는 폴더]

tar 압축풀기 : tar -xvf [파일명.tar] 

tar.gz 압축하기 : tar -zcvf [파일명.tar] [압축할 파일 또는 폴더]

tar.gz 압축풀기 : tar -zxvf [파일명.tar.gz] 

압축 풀기 경로 설정 : tar -xvf [파일명.tar] -C [원하는경로]          

 

cat - 파일 내용 출력 

cat FILE_NAME   == FILE_NAME 출력

 

find - 검색 

find . -name [파일명] == 현재 디렉토리 하위 모든 파일들에서 파일을 검색

find / -name [파일명] == 루트 디렉토리 하위 모든 파일들에서 파일을 검색 

find . -name "파일명*" == 현재 디렉토리 하위 모든 파일에서 해당 파일로 시작하는 파일 검색

find . -name "*파일명*" == 현재 디렉토리 하위 모든 파일에서 해당 파일명이 포함된 모든 파일 검색

find . empty              == 빈 디렉토리 또는 크기가 0인 파일 검색 

chmod - 파일 권한 변경 

chmod 777 test.txt   == test.txt 파일의 권한을 모두 허용한다 

chmod -R 777 test   == test 폴더의 모든 하위폴더를 포함하여 권한을 변경한다 

 

top - 프로세스 정보 확인 (CPU, Memory, Process 사용량 확인)

top  -n 10   = 10초마다 반복 

 

ps  - 프로세스 확인 

CUDA_VISIBLE_DEVICES   - GPU 사용 설정 

CUDA_VISIBLE_DEVICES = 0,2 python test.py    == GPU 0, 2 번 사용하여 test.py python 실행 

 

nvidia-smi  - GPU 확인 

nvidia-smi -l 10    10초마다 갱신

 

 

 

'Machine Learning > ML Tool' 카테고리의 다른 글

docker 자주 사용하는 명령어  (0) 2021.05.31

docker ps     (docker ps [OPTIONS])

로컬 도커 컨테이너 리스트를 보여준다

 --all          : 모든 컨테이너를 보여준다

 --filter       : 입력 값에 따른 필터링된 결과를 보여준다

 --format    : 

 --last   N   : 최근에 생긴지 N번쨰 컨테이너를 보여준다 default = -1 (모두)

 --no-trunc : 

 --quiet      : 컨테이너의 ID만 보여준다

 --size        : 컨테이너의 총 사용 용량을 보여준다 

 

docker images   (docker images [OPTIONS] [REPOSITORY[:TAG]])

로컬 도커 이미지 리스트를 보여준다 

 --all   : 모든 이미지를 보여준다 

 --digests : digests도 보여준다 

 --filter : 입력 값에 따른 필터링된 결과를 보여준다

 --format

 --no-trunc

 --quiet : 이미지의 ID만 보여준다 

 

docker pull (docker pull [OPTIONS] NAME[:TAG|@DIGEST])

도커 허브에 올라가 있는 이미지를 로컬 도커에 다운받는다 

 --all  : 해당 레포지토리의 모든 tagged 이미지를 다운받는다

 --disable-content-trust  : 이미지를 인증받지 않고 다운받는다 

 --platform : 서버가 다중 플렛폼을 지원하는 경우 플렛폼을 설정한다

 --quiet : 출력내용을 조금 보여준다 

 

docker run    (docker run [OPTIONS] IMAGE [COMMAND] [ARG...])

docker run -itd --gpus '"device=1"' --name yangro --volume /home/ubuntu/share:/home/tf --publish 8888:8888 -p 6666:6666 my_image bash

도커 이미지를 가지고 컨테이너를 생성한다 

 --cpus : 할당할 CPU 개수를 정한다 

 --gpus : 할당할 GPU 개수를 정한다   --gpus all 모두할당

 --memory  : 메모리 제한을 설정한다 

 --name : 만들어질 컨테이너의 이름을 설정한다

 --pull : 컨테이너를 생성하기 전 설정 이미지를 도커허브에 업로드한다 

 --rm  : 컨테이너를 나오면 자동으로 종료한다 

 --publish : 로컬포트와 컨테이너의 포트를 연결한다 -p 8888:8888/tcp

 --volume  : 로컬폴더와 컨테이너의 폴더를 연결한다 -v /home/ubuntu : /home/ubuntu

 --tty  : 가상 tty를 연결한다 -t

 --interactive : attach 상태가 아니여도 STDIN 을 유지한다 -i

 --detach  : 컨테이너를 백그라운드에서 실행하고 컨테이너 아이디를 프린트한다 -d

 --ipc=host : 컨테이너 내부에서 pytorch를 실행시키면 메모리 할당 에러가 나기 때문에 컨테이너가 host와 같은 ipc namespace를 사용하도록 설정해야한다. IPC (POSIX / SysV IPC) 네임 스페이스는 명명 된 공유 메모리 세그먼트, 세마포어 및 메시지 큐를 분리한다.

 

docker exec  (docker exec [OPTIONS] CONTAINER COMMAND [ARG...])

실행중인 컨테이너에 새로운 명령어를 실행한다 

-itd : interactive tty detach

 

docker attach   (docker attach [OPTIONS] CONTAINER)

실행중인 도커 컨테이너에 표준 입출력으로 연결한다

 

docker  bulid ( docker build [OPTIONS] PATH | URL | -)

도커파일로부터 이미지를 생성한다 

 

docker stop   (docker stop [OPTIONS] CONTAINER [CONTAINER...])

실행중인 컨테이너를 정지한다 

--time  : 정해진 수만큼 뒤에 컨테이너를 정지한다  -t (default 10)

 

 

docker commit   (docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]])

docker commit -author yangro 컨테이너이름 저장할이미지이름

도커 컨테이너를 새로운 이미지로 생성한다 

--author  : 제작자 이름을 넣는다 (ex : asdasd@asd.com)

--change  : 생성되는 이미지에 도커파일 명령어를 적용한다 

--message : 커밋 메세지를 설정한다 

--pause  : 커밋중에 컨테이너를 정지시킬지 설정한다 (default True)

 

docker push (docker push [OPTIONS] NAME[:TAG])

도커이미지 또는 repository를 도커 hub에 등록한다 

--all-tags   : repository에 테그되어있는 모든 이미지를 등록한다 

 

'Machine Learning > ML Tool' 카테고리의 다른 글

Linux 자주 사용하는 명령어  (0) 2021.06.12

Object detection에 많은 영향을 끼친 대표적인 논문이다. 

 

Joseph Redmon 이라는 수학자? 엔지니어? 가 쓴 논문으로써 기존에 쓰이던 Two-stage가 아닌 One-stage 방식으로  detection을 한다 

 

One-stage Two-stage에 대한 설명은 다음 블로그에 설명해 놓았다.

https://house-of-e.tistory.com/entry/1-Image-detection-One-stage-Two-stage

 

(1) Image detection - One-stage, Two-stage

1. One-stage Detector Regional proposal(영역 제안)과 classification(분류)을 동시에 수행한다 대표적으로 YOLO(You Only Look Once)가 있다 - 당신은 한번만 본다 라는 이름 자체의 뜻처럼 이미지를 한번만..

house-of-e.tistory.com

또한 Anchor based detection 방식으로 기존에 설정해 놓은 anchor 크기 만큼의 물체를 검출한다.

 

기존의 Two-stage 방식은 이미지 분류와 크기 예상의 과정이 나눠저 있엇 복잡도가 증가하고 (느리고) 최적화가 어려웠다. 

 

training, test에서 YOLO는 한장의 이미지를 부분 부분 나눠서 검출하는 방식이 아닌 한 이미지 전체를 보고 객체를 검출하는 방법에서 실제 사람이 물체를 보는 방식과 닮아있다

 

YOLO에서는 기본적으로 하나의 이미지를 S 개의 grid cell로 나눈다 

그리고 나서 해당 grid cell마다 어떤 클래스가 해당하는지, 어떤 크기의 객체가 존재하는지 검출한다.

각 grid cell 마다 정해놓은 하이퍼파라미터 만큼의 bounding box를 예측하게 되고 - 논문에서는 2개

그리고 나서 어떤 임계값을 기준으로 임계값보다 낮은 anchor boxes 를 지운다.

예를 들어 416x416의 이미지가 인풋으로 들어가면 conv layer와 FCL(Fully Connected Layer)을 거친 후 7x7의 grid cell이 나오게 되고 하나의 grid cell마다 각각 어떤 클래스가 있을지 하는 class probability 와 객체가 있는지 없는지에 대한 confidence와 anchor box의 좌표값을 grid cell에 비례하여 0~1 사잇값으로  나오게 된다 

 

YOLOv1 의 layer는 다음과 같이 쌓았으며 해당 layer는 GoogLeNet 모델을 따랐다

 

학습에는 ImageNet 1000-class competitiom dataset을 이용하였고  

처음 20개의 conv layer는 pretraining된 weight를 사용하였고 

모든 학습 과정에는 Darknet이라는 Joseph Redmon 본인이 만든 framework를 이용하였다

 

마지막 output layer에서는 linear actication function 를 이용하였고 다른 모든 layer에서는 leaky relu를 이용하였다 

Leaky relu의 0 이하의 값에 대해서는 0.1을 곱한 값을 사용했다

또한 기존에 쉽게 사용할 수 있는 sum-squared error를 이용할 때 
전체 이미지에서 grid cell에 객체가 없을 확률이 높아 해당 cell들의 confidence가 대부분 0이 되어버리면 학습이 불안정해지는 문제가 있다 - 수렴하지않고 발산할 위험이 있다. 

객체가 없는 grid cell에 대하여 추가적인 하이퍼파라미터를 추가하여 발산 문제를 줄였다 - 람다 noobj = x0.5

또한 큰 bounding box와 작은 bounding box에 대하여 같은 error를 적용하면 작은 bounding box는 더 작은 error가 적용될 수밖에 없다. 그래서 bounding box 의 크기에 대한 loss를 계산할 때는 root 를 추가하여 서로 비슷한 loss를 가질 수 있도록 하였다 - 람다 coord = x5 

정답데이터와 가장 높은 IoU를 가진 bounding box에 대해서만 loss를 적용하였다 - 1 obj ij

 

 

https://arxiv.org/abs/1506.02640

 

You Only Look Once: Unified, Real-Time Object Detection

We present YOLO, a new approach to object detection. Prior work on object detection repurposes classifiers to perform detection. Instead, we frame object detection as a regression problem to spatially separated bounding boxes and associated class probabili

arxiv.org

 

MLOps 수준 2
자동화된 ML 파이프라인의 단계

CI/CD를 통해 모든 파이프라인의 구성요소가 자동화 된다

 

CI

 

이 설정에서 파이프라인과 구성요소는 새 코드가 커밋되거나 소스 코드 저장소로 푸시될 때 빌드, 테스트, 패키징 된고 다음 테스트가 포함될 수 있다

 ㄱ. 특성 추출 로직을 단위테스트한다 

 ㄴ. 모델에 구현된 다양한 메소드를 단위테스트한다 - 예를들면 원-핫 인코딩이라던지 

 ㄷ. 모델 학습이 수렴하는지 테스트 - early stopping, overffiting

 ㄹ. 모델 학습에서 0으로 나누지 않는지 NaN 값을 생성하지 않는지 테스트 

 ㅁ. 파이프라인의 각 구성요소가 예상되는 값들을 생성하는지 테스트

 ㅂ. 각 파이프라인 구성요소간의 통합을 테스트

 

CD 

 

새 파이프라인 구현을 대상 환경에서 지속적으로 배포한다 안정적이고 지속적인 배포를 위해서 다음과 같은 사항을 고려해야한다. 

 ㄱ. 모델을 배포하기 전에 대상 인프라와의 호환성을 확인한다

 ㄴ. 예상되는 입력으로 서비스 API를 호출하고 예상하는 응답을 가져오는지 테스트한다 - 모델이 업데이트 되었을 때 다른 입력을 대상으로 발생할 수 있는 문제를 포착한다 

 ㄷ. QPS( Queries per second) 및 모델 지연시간과 같은 서비스 부하 테스트

 ㄹ. 재학습 , 일괄 예측을 위한 데이터 유효성 검사

 ㅁ. 모델이 배포되기 전 모델의 성능 목표를 충족하는지 확인

 ㅂ. 테스트 환경에 대한 자동 배포 - 개발 분기에 코드를 푸쉬하여 트리거된 배포

 ㅅ. 사전 프로덕션 환경에 대한 반자동 배포 - 검토자가 변경사항을 승인한 후 기본 분기에 코드를 병합하여 트리거된 배포) 

 ㅇ. 사전 테스트 환경에서 여러번의 파이프라인 성공 후에 프로덕션 환경에 대한 수동 배포 

 

CI와 CD는 프로덕션 환경에서 매우 중요하다. 

변화가 많은 ML 시장에서 고객의 수요에 대한 빠른 대응과 새로운 모델을 적용시키는 일이 많다 

이러한 자동화 파이프라인으로 빠른 변화에 대처할 수 있다. 

 

하지만 이러한 MLOps 수준2의 경우는 대규모 ML 환경(모델 5개 이상)에 적합하다. 모델을 한두개 서비스하는 입장에서는 이정도까지는 과소비라고 생각된다. 

 

https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning

 

MLOps: 머신러닝의 지속적 배포 및 자동화 파이프라인  |  Google Cloud

이 문서에서는 머신러닝(ML) 시스템을 위한 지속적 통합(CI), 지속적 배포(CD), 지속적 학습(CT)을 구현하고 자동화하는 기술을 설명합니다. 데이터 과학 및 ML은 복잡한 실제 문제를 해결하고, 업계

cloud.google.com

 

MLOps 수준1 : ML 파이프라인 자동화

MLOps 수준 1

MLOps 수준 1 의 목표는 ML 파이프라인을 자동화 하여 모델을 지속적으로 학습시키는 것이다

 

수준 0 과 비교해서 많은 것이 생긴것 같다 천천히 살펴보자

 

1. 수준 0 에서 Manual experiment steps 였던 데이터 검증, 전처리, 학습, 평가 등의 항목이 Manual experiment steps에서 Orchestrated experiment로 변경되었다 해당 단계사이의 전환이 자동으로 이루어지므로 실험을 빠르게 반복하고 전체 파이프라인 프로덕션을 더 빠르게 이동할 수 있다.

 

2. Performance monitoring 항목이 생성되었다. 지속적인 모니터링을 통해 모델의 성능을 평가하고 트리거가 발생될 시 해당 트리거를 발생시킨 데이터를 저장하고 데이터를 분석하여 모델을 재학습 시키는 과정이 자동으로 진행되게 된다

 

3. 개발 , 실험 환경에서 사용되는 파이프라인이 프로덕션 환경에서 사용된다 

 

4. ML파이프라인 전체에서 구성요소를 재사용, 구성, 공유할 수 있다. - 구성요소를 컨테이너화 

 - 개발 및 프로덕션 환경간에 코드를 재현 가능하다

 - 파이프라인의 각 구성요소를 분리하여 구성요소들은 자체 런타임 환경 버전을 가질 수 있고 다양한 언어 및 라이브러리를 갖는다

 - 코드 실행 환경을 분리한다

5. CD : 새로운 데이터로 학습된 새 모델을 프로덕션으로 지속적으로 배포하는 단계가 자동화 된다

 

6. 파이프라인 배포 : 전체적인 파이프라인이 전부 배포된다 

 

 

MLOps 수준 1을 구성하기 위해서는 데이터와 모델의 검증이 필요하다 

trigger를 통해 자동으로 파이프라인을 실행하기 때문에 자동 학습을 위한 데이터 검증과 모델 검증 프로세스가 필요하다 

 - 데이터 검증 : 모델 학습 전에 모델이 재학습을 진행할 지 파이프라인의 실행을 중지할지 결정하는데 필요하다 이 결정은 파이프라인에서 다음을 식별하면 자동으로 수행된다 
 ㄱ. Data Schema Skews(데이터 스카마 편향) : 이러한 Bias는 입력 데이터의 이상으로 간주된다 데이터 처리 및 모델 학습을 포함한 파이프라인의 단계에 해당 데이터가 형식에 맞지 않는지 판단해야한다 . 입력이 되는 데이터가 형식에 맞지 않을 경우 작업자에게 이 사실을 알리고 조사하게 한다. 작업자는 해당 사실을 알아차리고 해당 데이터에 대한 분석을 진행하고 파이프라인을 수정하거나 업데이트한다

 

 ㄴ. Data Value skews(데이터 값 편향) : 이러한 skews는 데이터의 통계적 특성이 변한것이다 이러한 사항을 포착하여 모델을 업데이트 하여야한다. 

 

 - 모델 검증 : 트리거 발생으로 인한 모델의 재학습시 모델을 프로덕션으로 제공하기 전에 사용자가 모델을 평가하고 검증해야한다 

 ㄱ. 모델의 품질을 평가하기 위해 측정항목을 생성한다

 ㄴ. 현재 모델과 비교한다 - 더 성능이 좋은지 판단한다

 ㄷ. 모델의 성능이 다양한 범위에서 일관성이 있는지 확인한다 - True Nagative , True Positive , False Nagative, False Positive

 ㄹ. 인프라와의 호환성 및 일관성을 모함하여 모델 배포 테스트 - 트레픽 대응 A/B 테스트, 카나리아 배포

 

 

Feature Store

 

 Feature Store는 선택적 구성요소이다 학습및 서빙을 위한 특성을 정의, 저장, 접근을 표준화하는 저장소 

Feature store는 Feature에 대해 높은 처리량과 일괄 처리 및 짧은 지연시간, 실시간 제공을 위한 API를 제공해야 하며 학습 및 서빙 workloads를 지원해야한다 

 ㄱ. 동일하거나 유사한 feature set을 다시 만들지 않고 feature set을 검색하고 재사용하게 된다

 ㄴ. feature 및 관련 메타데이터를 유지하여 정의가 다른 유사한 특성 사용을 방지한다

 ㄷ. 최신의 Feature value를 제공한다

 ㄹ. Feature store을 지속적 학습, 실험, 서빙을 위한 데이터 소스로 사용하여 training serving skews(학습과 서빙의 성능 차이)를 방지한다 

 

메타데이터 관리

 

ML파이프라인의 각 실행에 대한 정보는 전부 기록되며 오류와 이상을 디버깅하는데 도움이 된다. 

다음과 같은 메타데이터가 기록된다

 ㄱ. 실행된 파이프라인 및 구성요소 버전

 ㄴ. 시작 및 종료 날짜, 시간, 파이프라인 각 단계를 완료하는데 걸린 시간

 ㄷ. 파이프라인 실행자

 ㄹ. 파이프라인에 전달된 파라미터 인수

 ㅁ. 준비된 데이터 저장 위치, 검증 이상, 계산된 통계, 카테고리형 특성에서 추출된 어휘와 같은 파이프라인의 각 단계에서 생성된 artifacts에 대한 포인터 - 이러한 출력을 추적하면 이미 완료된 단계를 다시 실행하지 않고도 파이프라인이 실패한 단계로 가장 최근의 단계에서 파이프라인을 다시 실행시킬 수 있다

ㅂ. 이전에 학습된 모델에 대한 포인터 - 이전 모델 버전으로 롤백해야 하는 경우 또는 모델 검증 단계에서 파이프라인에 새 테스트 데이터가 제공될 때 이전 모델에 대한 평가항목을 생성해야 하는 경우)

ㅅ. 학습 및 테스트 세트에 대한 모델 평가단계에서 새로운 모델 평가 측정항목 - 새로운 모델과 이전 모델의 성능을 비교하기위해 필요

 

ML pipeline trigger 

 

파이프라인을 자동으로 재학습 시킬 수 있게 한다 

 ㄱ. 수동실행

 ㄴ. 정기적 실행 - 매일, 매주, 매월 - 재학습 빈도는 패턴 변경빈도 , 재학습 비용에 따라 달라진다

 ㄷ. 새 학습 데이터의 가용성 기준 - 

 ㄹ. 모델 성능 저하 시

 ㅁ. 데이터 분포의 중요한 변화시 (concept drift) - 모델이 오래됬다고 판단되어 재학습이 필요할 때

 

부족한 점 

 

1. 파이프라인의 새로운 구현이 자주 배포되지 않고 몇개의 파이프라인만 관리한다고 가정된다. - 파이프라인과 구성요소를 수동으로 테스트한다 

2. 새로운 파이프라인을 수동으로 배포한다 

3. 새로운 ML 아이디어를 시도해야하고 ML 구성요소를 빠르게 배포해야 하는 경우 배포를 자동화 하기위한 CI/CD가 필요하다

 

https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning

 

MLOps: 머신러닝의 지속적 배포 및 자동화 파이프라인  |  Google Cloud

이 문서에서는 머신러닝(ML) 시스템을 위한 지속적 통합(CI), 지속적 배포(CD), 지속적 학습(CT)을 구현하고 자동화하는 기술을 설명합니다. 데이터 과학 및 ML은 복잡한 실제 문제를 해결하고, 업계

cloud.google.com

 

MLOps 수준 0 : 수동 프로세스 

MLOps 수준 0

1. 학습용 데이터를 추출하고 분석한다

2. 데이터 전처리

3. 모델 학습

4. 모델 평가 및 검증

5. 모델 저장소에 등록

6. 모델 서빙

7. 서비스 진행

 

문제점

1. 해당 과정이 전부 수동, 스크립트 기반으로 동작하게 된다 

모든 단계는 수동으로 실행하고 한 단계에서 다른 단계로 전부 일일이 작업자가 타이핑 또는 빌드로 진행하게 된다. 작업자가 개인의 툴에서 실행해보고 됬다 싶으면 다음 단계로 넘어간다 

 

2. ML을 하는 데이터 사이언티스트와 엔지니어링 팀이 분리되어있다 데이터 사이언티스트가 모델을 학습시키고 엔지니어링 팀에 넘긴다 - 넘길때는 모델의 가중치만 있는 파일 또는 레이어가 담긴 파일을 회사 저장소에 저장하는 방식이다

 

3. 이렇게 하다보면 학습할 떄의 성능보다 서빙할때의 성능이 떨어지는 모델이 생길 가능성이 있다

 

4. 지속적이지 않은 모델 업데이트 - 1년에 한두번 할 까 말까 한 정도의 재학습이 진행되어 모델의 성능이 떨어지는건 생각지 않는다

 

5. CI 없음 - 구현 변경사항이 거의 없으므로 CI란게 없다 코드테스트가 관리되지 않고 개인의 툴에 저장되어 있기 때문에 각각의 작업자의 개인 PC에 코드들이 저장되어있다

 

6. CD 없음 - 모델의 버전이 자주 변경되지 않으니 CD는 고려되지 않는다

 

7. MLOps 수준 0는 전체 ML 시스템을 배포하는게 아닌 학습된 모델을 배포하는것이다

 

8. 모니터링 없음 - 모델의 성능이 저하됐는지 모른다 모델 동작 드리프트를 감지하는데 필요한 trigger를 설정하지 않았다

 

 

내가 지금까지 했던 프로세스가 MLOps 수준 0 에 해당했다 

개인 작업PC에서 모델을 학습시키고 Github같은 협업툴을 사용하지 않고 혼자 작업했다 

물론 혼자 작업하면 편한점은 있다 편하다 

하지만 나중에 후회했다 지속적으로 코드를 정리하지 않다보니 전에 좋았던 하이퍼파라미터가 무엇이였는지 어디에 저장해놓았는지 까먹을 때가 있었고 실수로 파일을 지워버리면 복구하기까지 시간이 오래걸렸다 

또한 실제로 모델을 학습시켜서 서비스를 하려했지만 학습 PC와 서비스 PC의 사양이나 구성요소등이 달라 구축환경을 맞추기도 힘들었다

특히 학습 데이터를 관리를 잘 하지 못해 학습을 시키고 보니 더 성능이 떨어졌던 기억이 있다.

또한 학습 데이터셋을 버전관리를 하지 않아 모델간의 성능 비교 효과가 떨어졌다

 

https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning

 

MLOps: 머신러닝의 지속적 배포 및 자동화 파이프라인  |  Google Cloud

이 문서에서는 머신러닝(ML) 시스템을 위한 지속적 통합(CI), 지속적 배포(CD), 지속적 학습(CT)을 구현하고 자동화하는 기술을 설명합니다. 데이터 과학 및 ML은 복잡한 실제 문제를 해결하고, 업계

cloud.google.com

 

머신러닝 프로젝트를 지속적으로 통합(CI), 지속적 배포(CD), 지속적 학습(CT)를 구현하고 자동화하는 기술을 설명한다.

 

 - DevOps와 MLOps의 비교

DevOps란 대규모 소프트웨어 시스템을 개발하고 운영하는데 사용된다. 효율적인 DevOps는 개발 주기 단축, 배포 속도 증가, 안정적인 출시 등의 이점을 제공한다. 이러한 이유는 지속적 통합(CI : Continuous Integration)와 지속적 배포(CD : Continuous Deployment) 의 효과이다

 

MLOps는 DevOps와 비슷하지만 다른점은 이와같다

1. 머신러닝은 주로 수학자와 데이터 사이언티스트, 연구원으로 구성되어 있기 때문에 프로덕션 수준의 서비스 빌드가 가능한 인력이 없을 수 있다.

2. ML은 기본적으로 실험에 기반한 기술이다. 많은 사람들이 하이퍼파라미터의 변경에 어떤 수학적 함수를 따르는지 모른다. 그렇기에 실험을 통해 좋은 하이퍼파라미터를 찾게되는데 이런 과정에서 모델의 성능이 좋았던 것과 안좋았던것 을 잘 정리하고 모델 코드를 잘 분류하여 코드 재사용성을 극대화하고 재현성을 유지해야한다

3. 머신러닝은 다른 소프트웨어보다 더 복잡하다. 단위테스트, 데이터 검증(Data Validation), 학습 모델 평가, 모델 검증(Model Validation)이 필요하다

4. 머신러닝 모델은 지속적으로 업데이트가 되어야한다. 계속하여 서비스되고있는 모델의 성능을 검증하고 평가하고 평가점수가 낮아졌다면 모델의 학습을 다시 진행시켜야 완벽한 서비스가 진행된다. 이를 위해 지속적인 배포를 위한 자동화가 필요하다

5. 사용자의 데이터는 계속하여 진화된다. 이로인해 모델이 학습하지 못한 데이터가 입력으로 들어올 가능성이 크다. 이러한 문제는 모델의 성능 저하로 이어지기 때문에 데이터의 통계를 관찰하고 모델의 성능을 지속적으로 모니터링 하여 trigger를 발생시켜 문제를 인식하여야 한다.

 

  DevOps MLOps
CI(Continuous Integration) 코드와 구성요소 테스트 및 검증 DevOps + 데이터, 데이터 스키마, 모델
테스트 및 검증
CD(Continuous Deployment) 단일 소프트웨어 서비스 배포 DevOps + 모델 서비스 자동 배포
CT(Continuous Training) X 모델 자동 재학습

 

https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning

 

MLOps: 머신러닝의 지속적 배포 및 자동화 파이프라인  |  Google Cloud

이 문서에서는 머신러닝(ML) 시스템을 위한 지속적 통합(CI), 지속적 배포(CD), 지속적 학습(CT)을 구현하고 자동화하는 기술을 설명합니다. 데이터 과학 및 ML은 복잡한 실제 문제를 해결하고, 업계

cloud.google.com

 

+ Recent posts