HOE

요즘에는 클라우드 PC에서 작업을 주로 한다 

저사양의 GPU가 없는 노트북으로 간편하게 돌아다니고 

모든 코드는 클라우드에서 실행시킨다 

그런데 윈도우는 상관이 없지만 리눅스의 경우 클라우드에 접속하여 코드를 하려면 사전 준비를 해야 편하게 코딩을 할 수 있다 

리눅스로 코딩하는 법을 나열하자면 

1. vi 으로 코딩하기 

    - ㅎㅎ vi는 작은거 하나씩 고칠 때 사용하자.... 매우 비효율적이다

2. jupyter notebook을 이용하자 ! 

    - 나쁘지 않다 jupyter notebook은 테스트를 할 때 매우 편하기에 사용하기에 나쁘지 않은것 같다 

      하지만 이쁘고 이쁘고 한눈에 알아볼 수 있게 코딩을 하는게 더 실수를 줄이기 좋다 ㅎㅎ

3. Visual Studio Code를 이용하자 ! 

    - Visual Studio Code - VSC 는 많은 확장프로그램을 지원해주기 때문에 이쁘고 효율적으로 코딩을 할 수 있다 ! 

      쥬피터와 다른점은 변수, 클래스, 함수 등의 색을 다르게 볼 수 있다 ! 

    - 코드상에 오류가 있다면 빨간물결이 나온다 ! 매우 중요하다 ... 

    - 디버깅이 가능하다 ! 

    - Python 뿐만 아니라 JAVA, C, C++ 등등 여러가지 언어로 코딩할 수 있다 ! 

    - Jupyter notebook 도 VSC에서 사용할 수 있다 ! 

    이제 원격 설정을 시작해 보자 !!!

VSC를 실행시키고 왼쪽 확장 탭에 들어간다 

확장탭의 검색창에 SSH 또는 Remote를 검색하면 

Remote - SSH 가 나온다 해당 extension을 설치한다 ! 

키보드에서 F1 키를 누르면 위와같은 창이 나오고 창에 Remote-SSH를 입력하면 

Remote-ssh: Connect to Host 가 나오게 된다 ! 

Connect to Host를 클릭하면 SSH 접속을 할 서버 정보를 입력해야한다 

나는 원격 접속지의 계정 root에 IP는 192.168.50.30에 접속할 것이다 

여기서 원격지의 포트는 SSH 기본 설정 포트인 22번이다 

계정이름 : root

원격지 주소 : 192.168.50.30

원격지 포트 : 22

접속 정보를 다 입력하고 엔터를 누르면 접속을 하게된다 

원격지의 운영체재를 고르라고 한다 내가 접속할 서버는 Linux이기 떄문에 Linux를 선택한다 

만약 이런 연결이 되지 않는다는 창이 나온다면 역시 설정을 잘 했는지 또는 방화벽은 허용이 되어있는지 다시한번 체크해보길 바란다 

Linux를 선택을 하면 위의 사진과 같이 SHA256키를 알려주고 연결을 하겠냐고 다시 물어본다 

Continue를 선택하자 

위의 사진과 같이 비밀번호를 입력하라고 나오면 해당 계정(root)의 비밀번호를 입력한다 ! 

그럼 연결이 완료되고 폴더 열기를 선택하면 위와같이 연결된 서버의 디렉토리 리스트가 나오게 된다 

이제 원하는 디렉터리를 열고 작업을 시작하면 된다 ! 

그런데 여기서 디렉터리를 선택하면 다시 비밀번호를 입력하라는 창이 나오게 된다 

다시 입력하는게 귀찮다면 SSH Key를 생성하여 서버와 로컬에 설정을 해줘야한다 

하지만 매우 귀찮기 때문에 계속 치고 들어가겠다 

계속 비밀번호를 입력하는게 귀찮으신 분은 구글에 

vsc ssh save password 를 검색해서 따라해보시기를 바란다 

코드를 실행시키면서 디버깅도 하지만 솔직히 print를 많이 찍는다 . 

그런데 만약 어떤 코드의 문제가 코드를 실행시키고 어느정도 시간이 지난 다음에 발생한다면? 

코드를 실행 시키고 언제 나올지 모르는 에러를 잡기위해 계속 화면을 처다보고 있을 수는 없다 ! 

또한 어떤 프린트되는 출력에 대해 저장할 필요가 있다면 로깅을이용하여 저장하면 된다 ! 

또한 어떤 서버의 문제 때문에 해당 서버에 로그를 저장할 수 없는경우 원격으로 접속하여 로깅을 하면 좋다 ! 

시작해보자 ! 

일단 Xshell로 원격 서버에 접속한다 

해당 서버에 지속적으로 프린트 문이 출력되는 코드를 실행시켰다 

별 문제는 없지만 만약 에러가 발생되고 에러의 발생으로 해당 코드의 실행은 멈추지 않고 에러가 계속하여 전파된다면 어떨까 

문제를 고치기 위해 문제가 어디서 일어났고 어떤것 때문에 에러가 발생되었는지를 찾아야한다 
하지만 아무것도 기록이 되어있지 않다면 

극단적으로 말하면 다시 에러가 발생되는 상황을 만들고 에러가 다시 발생할 때까지 기다려야 한다 

이때 로깅을 해놓았다면 하나하나 짚어가며 에러의 첫 발생지를 찾을 수 있고 

원인도 분석이 가능하다 

로깅을 해보자 

정말 간단하다 

실행되고있는 창에 마우스 오른쪽을 클릭하면 로그가 있다 

로그라는 선택박스를 클릭하면 시작과 로그 폴더 열기가 있다 

로깅을 하기위해 시작을 클릭하자 

시작을 누르면 해당 세션의 로그를 저장할 경로를 선택하고 파일이름을 설정할 수 있다 

로그파일을 저장할 폴더를 선택하고 파일이름을 test_log 로 하겠다. 

저장을 누르면 그 때 부터 로그가 저장되기 시작한다 .

로그가 시작되고 다시 세션 화면에서 마우스 우클릭으로 로그 선택상자를 클릭하면 

전에 클릭할 수 없었던 중지와 로그파일 열기가 활성화 되었다 

로그 파일 열기를 클릭하면 현재 세션의 로그가 저장된 파일이 열린다 

위의 사진처럼 로그파일( .log) 의 윈도우 기본 확장자는 메모장이라 메모장으로 해당 파일이 열리게 되고 세션 커멘드라인에 출력되는 내용들이 전부 저장됨을 볼 수 있다 ! 

로그를 중지하고 싶다면 세션 화면에서 우클릭 후 로그 선택상자에서 중지를 누르면 로깅을 중지하게 된다! 

서버 운영에 로그는 매우 중요하니 잘 알아두자 ! 

내가 주로 사용하는 Xshell 에 대하여 사용법을 정리하자 ! 

나는 주로 Xshell을 원격 클라우드나 Switch 설정등 외부 기기와 연결할 때 사용한다 

Xshell을 사용하면 좋은 점은 일단 

1. 창을 여러개 띄워서 여러 로그들을 같이 볼 수 있다. 

2. 각 창별 로그 저장도 간단하게 마우스 클릭으로 할 수 있다 ! 

3. Xshell을 키면 세션저장 목록이 왼쪽에 바로 나와 더블클릭으로 바로 연결 할 수 있는 외부기기에 접속할 수 있다

4. 일단 한국 기업 제품이라 글씨 크기를 바꾸거나 폰트를 변경할 때 편하다 ! 

이 글에서는 제품을 다운받고 연결설정과 글씨 크기 변경, 로그 기록을 해보겠다.

첫번째 인터넷에 Xshell을 검색한다 

xshell을 검색하면 가장 위에 나오는 Xshell 다운로드를 클릭한다 

다운로드 페이지로 이동하면 위 사진 처럼 정품사용자 30일 평가판을 다운받을 수 있다고 나온다 

하지만 학습용으로 사용할 것이기 때문에 평가판도 싫고 돈도 없다 ㅠㅠ. 

오른쪽에 보이는 "가정 및 학교 내 사용자를 위한 무료 라이선스" 탭에 무료 라이선스 페이지로 이동한다 

페이지를 이동하면 이름과 이메일을 적고 Xshell을 다운받을 것인지 Xftp도 다운받을것인지 선택할 수 있다. 

이름과 이메일을 입력한 후 나는 Xshell 만 이용할 것이기 떄문에 Xshell만을 선택한다 

여기서 이메일을 잘 써야한다 이메일로 다운로드 링크가 오기 떄문에 

입력한 이메일로 접속하여 메일을 확인해 보면 넷사랑에서 Xshell 다운로드 메일을 보냈다 

해당 메일에는 다운로드 링크와 링크 만료 날짜가 적혀있다 

가정/학교 무료 사용 버전도 상용 버전과 같은 기능을 제공해 준다고 한다 ! 매우 마음에 드는 회사이다 

페이스북 페이지에 좋아요를 눌러줘야겠다 

다운로드 링크를 클릭하고 다운을 완료한후 실행한다 

다운로드를 완료하고 실행을 해본다! 

위와 같은 창이 뜬다  

이제 새로 연결할 클라우드에 대한 접속 설정을 해보자 

왼쪽 상단에 위치하는 작은 아이콘을 누른다 

새 세션 등록 정보 창이 나온다 

이 창이 매우 중요하다 ! 

모든 설정을 세션별로 할 수 있다 

또 다른 Xshell의 장점? 이다 

일단 연결을 해보자 

이름 : 란은 해당 세션을 어떤 이름으로 할지이다 나는 Cloud - Server 라고 하겠다 

프로토콜 

란은 해당 세션과 연결할 프로토콜을 정한다 

1. Linux 같은 서버에 접속할 때는 주로 SSH 22번 포트를 이용하고 

2. LOCAL은 지금 내 컴퓨터를 말한다 로컬은 현재 나의 PC이기 때문에 다른 설정이 필요없이 바로 접속 되지만 나는 CMD를 이용하겠다 

3. 스위치 콘솔에 직접 접속하거나할 경우 SERIAL선을 연결한 뒤  SERIAL을 이용한다 

4. FTP, SFTP는 주로 파일질라 같은 다른 툴을 이용하여 접속한다 

5. RLOGIN 은 잘 사용하지 않는다 접속하려는 서버에도 연결에 관련된 설정을 해줘야하고 제한적이다

6. TELNET 은 예전에는 사용을 했지만 보안이 취약한 점이 있어 잘 사용하지 않는다 주로 23번 포트를 사용한다 

말이 길어졌다 ..... 일단 Linux 서버에 SSH 로 접속을 하자 

물론 SSH를 연결하기 위해서는 서버에 SSH 관련 설정을 해야하지만 AWS EC2의 경우 왠만하면 대부분의 이미지들이 SSH가 되어있다 

SSH설정이 되어있다고 가정을 하고 

호스트 부분에는 자신이 접속하고자 하는 원격지의 IP를 입력한다 

IPv6 연결이 되는지 궁금하긴 하다 

대부분의 PC, server, cloud 의 경우 IPv4를 사용하지만 

일반 스마트폰 LTE, 5G 의 경우 IPv4의 한정적인 수량때문에 IPv6를 사용하고 있다. 

어쨌든 위의 설정을 다 쓰고 연결을 눌러보자 ! 

연결을 클릭하면 해당 서버에 계정과 비밀번호를 입력해야한다 

내가 들어갈 계정은 root이다 

root 를 입력하고 다음을 누르면 비밀번호를 치게되고 접속이 완료된다 

만약 위와 같이 Connection failed 가 나온다면 

접속 설정을 다시 확인하고 설정이 완벽하다면 

접속하려는 서버에 방화벽이나 SSH 설정이 되어있는지, 

현재 PC의 방화벽이 외부로 보내는 신호를 막았는지 현재 PC의 방화벽도 체크해보길 바란다 

위와같이 연결이 되면 완벽하다! 

그런데 노트북 같은경우 화면이 작다보니 처음 접속시 글씨 크기가 너무 작다 

왼쪽 그림같이 설정한 세션에 마우스 우클릭으로 등록정보 에 들어간다 

처음 접속설정을 하던 창이 나오면 

저~ 아래있는 "모양" 탭을 클릭한다 - 창, 하이라이트 말고 "모양"을 클릭해야한다 

모양탭의 모양은 이렇게 생겼다 

딱 봐도 알겠지만 글꼴, 크기, 두껍게, 얇게 다 설정이 가능하고 글의 색과 커서의 색도 설정할 수 있다 ! 

이쁘게 꾸며보자 ! 

한글이 아주 궁서체이다 만족스럽다. 

다음 글에서는 Xshell에서 자주 사용하고 있는 Logging에 대해서 정리하겠다 

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

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

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

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

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

Norm 이란? 

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

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

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

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/

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초마다 갱신

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에 테그되어있는 모든 이미지를 등록한다 

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

또한 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

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