Collaborative hyperparameter tuning

– 논문 링크 : Link  (Collaborative hyperparameter tuning <2013>)
 – 적용 구현 : Link

1.Hyper Parameter Tunning 
HyperParameter Tunning 은 ML 에서 매우 중요한 Step이다. (Pintoet al. 2009, Coates et al. 2011, Bergstra et al. 2011,Snoek et al. 2012, Thornton et al. 2012)
논문에 따르면 새로운 알고리즘 없이 기존의 존재하는 알고리즘의 hyper parameter를 조정하는 것만으로도 성능향상을 가지고 왔다는 연구 결과도 있다.
이러한 Hyper Parameter 의 조정은 보통 사람이 수동으로 수행하고는 하는데, 이러한 과정들을 자동화 할 수 있는 방법들은 많이 연구 되어 왔고 이미 실제 적용이 가능한데 대표적인 방법으로 아래와 같은 것들이 있을 수 있겠다.
–  local-search based methods (ParamILS of Hutter et al. 2009)
– estimation of distribution methods (REVAC of Nannen & Eiben 2007)
– surrogate-based methods (Hutter, 2009)
– surrogate method deep neural network 에 적용 Bergstra et al. (2011)
– WEKA Package 적용 , Thornton et al. (2012)
이러한 자동화된 Hyper Parameter 튜닝 방법이 존재함에도 경험 많은 Engineer 들은 여전히 그들만의 방법으로 튜닝을 진행하는데, 예를 들면 성공적으로 MNIST 데이터를 튜닝한 Hyper Parameter set 을 보유하고 있을때, 약간 변형된 MNIST 에 기존에 성공적으로 MNIST 모델을 생성했던 Hyper Parameter 에서 Insight 를 얻어서 새로운 변형된 MNIST 데이터에 적용을 시작하는 등 방법이 있을 수 있겠다.
이 논문에서 제안하는 바는 surrogate 방법과 사람이 기존의 데이터에 대해 가지고 있는 Hyperparameter 에 대한 Insight 를 적용하는 것을 융합하는 방법이다.

About AI

  • AI 어디까지 왔는가?

도입-

“AI는 1950년대부터 존재하던 학문이다, 다만 최근에 들어 Google Deep Mind 의 효과적인 AlphaGo 마케팅으로 기존에 관심이 없던 많은 사람들도 주목하기 시작했다. 그렇다면 인류역사상 가장 복잡한 게임이라는 바둑마저 정복한 AI는 이미 사람을 넘어선 것인가? 많은 언론이 이야기하는 것처럼 AI 가 인간을 대체하는 날을 걱정해야 하는 수준에 온 것인가? AI 의 현주소와 우리의 대응에 대해서 이야기해보고자 한다. “

  • AI의 역사와 암흑기
    ai timeline에 대한 이미지 검색결과

현대 AI 의 연구는 1950년대부터 시작되었다. 그 당시의 AI 연구자들은 인간수준의 AI를 수십년안에 만들 수 있을 것이라고 생각했으며, 당시 선구자였던 Herbert A.Simon은 1965년에 “앞으로 20년안에 기계는 인간이하는 모든 일을 할 수 있게 될 것” 이라고 말했다. 하지만 1970년대에 들어 AI 연구자들은 인간수준의 AI를 만드는 일이 얼마나 어려운 일인지 과소 평가했다는 것을 깨닫게 된다. 시장은 점점 실용적인 AI 개발에 대한 요구를 하게 되고, AI 에 대한 기업과 사회의 시각이 점점 회의적으로 바뀌면서 AI에 대한 지원도 끊기게 된다. 1980년대 Expert System (Rule Base AI)를 통해 어느 정도의 성공을 거두면서 AI 에 대한 불씨를 살리는가 했으나, 결국 1980년대 AI시장은 완전히 붕괴하고, AI 는 암흑기에 빠지게 된다.

1-2 현대의 AI

21세기에 들어 AI 는 GPU가속을 이용한 연산속도의 비약적 발전, Big Data 처리 기술의 발달에 따른 Deep Learning(Deep Learning (Machine Learning <기계학습>의 한 분야로 2부에서 설명예정) 알고리즘의 재조명을 통하여 이미지 인식, 자연어 인식, 음성인식 등 기존에 잘 해결하지 못하던 문제를 해결하며, 제 2의 전성기를 누리고 있다.

[음성인식에서의 성능 향상]

deep learning voice recognition에 대한 이미지 검색결과

기존의 음성인식 알고리즘으로 애러율이 13% ~ 15% 에 달하던 성능을 Deep Learning 을 도입하면서 5% 미만으로 극적으로 개선하면서 그 우수성을 증명하였으며, 최근에는 Amazon Alex 와 같은 인공지능 스피커를 통해서도 AI를 실생활에서 느껴볼 수 있다.
이미지 인식에 있어서는 Deep Learning은 2016년 기준 사람의 수준에 근접한 인식률을 보여줄 정도로 발전되었다.

[AI 의 이미지 인식 정확도]

ILSVRC2016에 대한 이미지 검색결과출처 : ILSVRC2016 (http://image-net.org/challenges/LSVRC/2016/results)

또, 컴퓨터가 인간을 이길 수 없다고 알려진 바둑에서 세계 정상급 프로 선수인 이세돌 9단을 4:1로 이긴 AlphaGO 또한 MCTC(Monte Carlo Tree Search) 와 Deep Learning 을 복합적으로 활용하여 Game 에서의 AI 의 가능성을 증명하였다.

1-2현재 AI 의 수준은?

그렇다면 현재 AI 는 정말 인간을 대체할 만큼 발전한 것인가? 우리는 우리의 일자리를 두고 기계와 경쟁을 해야 하는가? 이 질문에 대답하기에 앞서서 AI 의 단계 구분에 대해서 설명하고자 한다.

(1) Narrow Artificial Intelligence
(2) General Artificial Intelligence
(3) Super Artificial Intelligence

Narrow Artificial Intelligence 는 특정한 분야에 주어진 일만 처리할 수 있으며, 그 일을 처리할 수 있는 똑똑한 AI 가 되기 위하여 많은 데이터 전문가, AI 전문가, 비즈니스 전문가가 많은 시간을 투자하여 좋은 AI를 만들어야만 하는 단계로 우리가 영화에서 보는 것과 같은 수준의 AI 와는 많은 거리가 있는 단계라고 볼 수 있다.

General Artificial Intelligence 는 컴퓨터가 인간처럼 스스로 학습하고, 생각하는 수준을 이야기하는 것으로 평균적인 인간수준의 지능을 갖춘 AI 단계라고 볼 수 있다. 기계의 사고 유무를 판단하기 위한 기준으로 1950년대 앨런튜링은 “컴퓨터로부터의 반응을 인간과 구별할 수 없다면 컴퓨터는 생각할 수 있는 것” 이라는 정의를 하고 Turing Test 라는 것을 고안하였으나, 현대에 와서는 기계의 사고유무를 판단하는 방법으로 부족하다는 의견이 대두되고 있다.

Super Artificial Intelligence는 영화 Avengers에서 아이언맨이 인공지능 비서인 자비스와 같은 수준을 생각하면 될 듯 하다. 가장 훌륭한 인간의 뇌보다도 더 뛰어난 수준으로 인간이 초월하는 수준의 인공지능으로 실질적으로 사람이 AI 에 지배 받는 것을 걱정해야 하는 수준이 바로 이 수준이 될 것이다turing test에 대한 이미지 검색결과

그렇다면 현재 AI 는 Narrow, General, Super AI 중 어떤 단계에 있는 것일까?
우선 General Artificial Intelligence를 판단하기 위한 테스트 방법으로 가장 유명한 Turing Test 의 결과를 한번 살펴보자

[그림. Turing Test 란?]

Turing Test 사람들 사이에 기계를 넣어 놓고, 온라인 통신 Chatting system을 통해 심판들이 5분간의 대화를 진행하여 30% 이상의 심판을 속일 수 있는가 없는 가를 테스트하는 것으로, 2014년 최초로 Eugene(우크라이나 13세 소년 역할 부여)가 Turing Test를 통과하였다. 그렇다면, 우리의 AI 기술은 사람처럼 생각하는 General AI 의 수준에 도달한 것인가?

아래는 2014년 테스트 당시의 대화 내용의 일부이다. 대화 내용을 보면 정말 Eugene 이 사람처럼 느껴지는가?

사실은 영어가 익숙하지 않은 13세 소년의 역할부여, 지속적으로 특정 주제로 유도하는 트릭 사용 및 어떠한 상황에도 사용할 수 있는 두리뭉실한 표현들을 주로 사용하는 등 테스트 자체를 통과하기 위한 수 많은 Trick 이 주요하였으며, 기술적으로 생각하는 AI를 만들어 Test를 통과한 것과는 거리가 멀다는 것이 대부분 관계자들의 생각이다.

[2014 Turing Test를 통과한 Eugene]turing test eugene conversation에 대한 이미지 검색결과

출처 : Times (http://time.com/2847900/eugene-goostman-turing-test/)

몇 가지 이야기를 더 해보자, General AI 정의에서 가장 큰 특징은 스스로 학습하고(사람이 데이터 수집, 모델링 등 개입 하지 않음), 상황에 맞는 다양한 일들을 수행할 수 있는 범용성에 있다. 그렇다면 최근에 가장 크게 화두가 된 AlphaGO 는 바둑을 스스로 배웠는가? 아니면 수많은 프로그래들의 노력이 투입되어 바둑을 학습 시켰는가? AlphaGO 는 바둑에서는 세계수준의 Player 인 이세돌을 격파할 정도로 뛰어난 능력을 가지고 있는 것은 분명하지만, 바둑 이외의 일도 할 수 있는가? AlphaGO는 Narrow Artificial Intelligence 의 전형이라고 볼 수 있으며, 결론적으로 현재 우리가 사용하고 있는 AI 는 모두 우리가 생각하는 General AI 와는 거리가 먼 Narrow AI라고 생각하면 된다.

1-3 Path to General AI

스스로 학습하고 생각하는 사람 수준의 AI가 언제쯤 어떠한 형태로 개발될 것인지 묻는다면, 정답을 말 할 수 있는 사람은 없을 것이다.
하지만, Weak AI 에서 Strong AI로 진화하기 위해 필요한 요소들을 도출해 보면 그 난이도와 소요 시간은 짐작할 수 있을 것이다.

(1)Computing Power

Artificial Intelligence 란 기본적으로 인간의 뇌가 사고하는 방식을 모방하는 것이기 때문에 인간만큼 복잡한 생각을 하기 위해서는 인간의 뇌만큼 복잡한 인공 신경망을 연산할 만큼의 Processing power 는 기본적으로 필요할 것이다. 인간의 뇌는 10^11의 뉴런을 가지고 있으며, 아기의 경우 10^15 의 뉴런을 가지고 있다고 한다.
인간의 뇌를 시뮬레이션 할 정도의 컴퓨팅 파워를 갖게 된다고 General AI를 달성할 수 있는 것은 아니지만 그 정도의 Computing Power는 필수 요건이라고 생각되며, 비용 및 H/W 최소화를 고려하지 않을 경우 원하는 Processing Power 를 달성하기까지 10년 정도의 시간이 소요될 것으로 예측하지만, 이 또한 소형화 전력소모 등을 고려하면 양자컴퓨터와 같은 다음 세대의 기술이 필요할 가능 성을 배제할 수 없다. Estimates of how much processing power is needed to emulate a human brain에 대한 이미지 검색결과

[Estimates of how much processing power is needed to emulate a human brain at various levels (from Ray Kurzweil, and Anders Sandberg and Nick Bostrom)]

(2) Self Learning & Reasoning

General AI로 가기 위한 방법은 크게 Top Down 방식과 Bottom Up 방식이 있을 수 있겠다. Top Down 방식이란 지금까지 AI를 틀을 완전히 깨고 새로운 시각에서 General AI를 바라보고 연구하는 것이고, Bottom Up 은 지금까지 우리가 해결해 왔던 수많은 문제의 해법들을 모아서 궁극적으로 General AI를 달성하는 방안이다.
AI 에 제 2의 전성기를 열어준 Deep Learning 이 General AI로 가는 문 또한 쉽게 열어줄 것인가? 아니면 또 다른 패러다임의 변화가 필요할 것인가
어떤 방향이던지 1950년대 인공지능 학자들이 20년이면 General AI 에 도달 할 수 있을 것이라 확신하였던 오판을 되돌아보면, 그리 쉽지 않을 길이 될 것이라는 것이 명확하다.

(3) Robot technology
진정한 General AI 의 완성은 외부 환경과 상호작용 가능한 물리적인 Robotic Body 와 Software 적인 AI 의 결합이라고 볼 수 있다.
결국 궁극적인 General AI는 Software Algorithm 의 발전만으로 달성할 수 있는 것이 아니며, 산업전반의 모든 연관 기술들이 전반적으로 발전되었을 때 달성 가능한 목표인 것이다.

1-4 우리의 대응은 ?  

진정한 AI로 가기 위해서는 산업 전반의 모든 기술들이 전반적으로 발전해야 하며, 너무 많은 기술적인 난관들이 존재하기 때문에 General AI 는 당장에 우리에게 다가올 현실은 아닐 것이다.
때문에 향후 몇 년은 누가 더 Narrow AI 를 잘 활용할 수 있는 CASE를 발굴하고 먼저 적용하는지가 관건일 것이다.

[우리가 준비해야 할 것들]

  • Infrastructure : 클라우드 서비스 등
  • Data Management : Big Data 관리 기술
  • AI Frame Work : 업무 특화 F/W 개발
  • Business Apply : 비지니스 적용을 위한 Insight

하지만, 얼마나 많은 노력과 시간이 소요되더라도, General AI를 향한 인간의 탐구는 멈추지 않을 것이며, 결국에는 도달할 미래라고 생각된다.
장기적으로는 당장은 AI 와 관련이 없는 것 같은 기술도 궁극적인 General AI 를 생각하면 결국에는 관련이 있다는 점을 염두하고 향후 General AI 도달에 중요하다고 생각되는 분야를 사전에 예측하고 투자할 필요가 있다.

Pair Programing in Pivotal Labs

# Pair Programing

– Programming 능력의 상향 평준화, 개발인력 변동시 에도 Project 영향도 적음
– Driver 역할의 개발자가 Test Code를 개발하고  이어서 다른 개발자 Implementation Code 개발
– 시스템 Error 감소 및 테스트 문서 최소화 가능

## 장점
– Test 문서대신 Script Code 로 대체가능
– Script 코드 품질향상 도모
– 시스템 변경 시 Test 코드로 이상여부를 Check 함으로써 Manual Test 필요없어 시스템의 유지보수 가능
– User Story에 집중하여 Outside-In 방식으로 개발
– 사용자 관점으로 개발, 테스트함으로써 시스템 수정을 줄임(BDD – Behavior Driven Development)
– 선진 Software 회사들은 대부분 TDD/BDD 방식 적용 (Test코드는 선택이 아닌 필수)

## 역량
– 집중력 향상
– 개인 역량 향상
– 능력의 상향 평균화
– 팀워크 향상
– 개인의 능력 투명(동료평가가 이루어짐)
– 핵심요원의 지식이 자연스럽게 전수

## 생산성
– 개발 집중력 향상
– 컴포넌트 형 개발(TDD Based)
– 소스 Re-factoring이 쉬움
– Test Automation
– 재작업 빈도 감소
– 결함 감소, 품질 향상

## 단점
– 초기 생산성 낮음(테스트 코드등 기본 뼈대 구축)
– 개발자 피로도 증가
– 갈등 회피 불가
– 적응 불가능 개발자 존재 시 원활한 진행 불가

deep learning cluster with aws -1-

Deep Learning Cluster를 구성하기

AWS GPU는 비싸다. 평소에는 CPU로 훈련하다가, GPU 자원을 활용하고 싶을때 어떻게 하면 좋을까?  GPU 인스턴스가 올라오면 자동으로 클러스터에 포함되고, 명령을 내리면 GPU에서 훈련하고,  훈련이 끝나면 모델은 공유디스크에 저장되고, GPU를 반납한다. Predict는 싼 CPU 인스턴스에서 하고, 필요할때만 GPU인스턴스를 사용하면 비용도 절감되고, 일석 이조이다.

개요는 디스크를 nfs로 공유하고(NAS나 Storage를 쓰면 좋겠지만 돈 없음), Job을 배분해주기 위하여 RabbitMQ와 Celery를 올리고, Rest를 통해 실행 명령을 내리면 Train  Job이 기동되는 형태로 구성할 예정이다.

TensorMSA Docker에는 기본으로 위 서비스들이 설치 되어 있기 때문에 TensorMSA Docker를 활용하여 구축하도록 한다.

<구성도 추가예정>

  • 목표와 작업순서
    Aws Instance 생성 cpu2개, gpu 2개
    Master Server에서 nfs 서비스 설치 및 Slave Server Directory Mount
    Cpu 인스턴스에 docker 설치, GPU 인스턴스에 Docker + Ndivia Docker 설치
    Cluster 연결을 위한 TensorMSA Docker 설정
    Cluster Test
  • AWS Instance 생성
    cluster를 구성하기 위하여 AWS에서 Instance를 생성한다.
    m2.xlarge  2대, P2.large 2대를 생성한다. 생성방법은 인터넷에 많이 있어요.
  • Nfs 서비스 생성
    우리는 훈련을 GPU Train서버에서 하고, Predict은 CPU서버에서 해야 하기 때문에 공유디스크를 설정해야 하는데 NAS나 SAN Storage를 쓰면 좋을텐데 돈이 없으므로 nfs서비스로 연결하도록 한다.
  • nfs 서비스 설치! 간단하게 설치 된다
sudo apt-get install nfs-kernel-server
  • /hoya_src_root /hoya_model_root /hoyai_playground 3개를 공유디렉토리로 설정한다. 디렉토리를 만들고, 소유권한을 바꾼다.
sudo mkdir /var/nfs/hoya_src_root -p
sudo mkdir /var/nfs/hoya_model_root -p
sudo mkdir /var/nfs/hoya_str_root -p
sudo mkdir /var/nfs/hoyai_playground -p


sudo chown nobody:nogroup /var/nfs/hoya_src_root
sudo chown nobody:nogroup /var/nfs/hoya_model_root 
sudo chown nobody:nogroup /var/nfs/hoya_str_root
  • /etc/exports 파일에 nfs 설정을 한다. RW(읽고 쓰고), sync(다 썼을때 회신)
    아무나 접속하는것을 막기 위해서 IP를 넣어서 지정된 IP만 접속하도록 설정한다.
    aws에서는 private ip는 고정 되므로 private ip를 사용하면 된다.
    public ip는 고정이 안될뿐더러 e-ip로 고정한다 할지언정 데이터를 쓰다가 트래픽이 인터넷구간으로 나가면 aws에서 network비용을 청구하므로 조심해야 합니다.
    예전 하둡 클러스터를 잘못 설정해서 network 비용이 100만원이 나온 기억이 나네요 ㅠㅠ
vi /etc/exports


/var/nfs/hoya_src_root   xx.xx.xx.xx(rw,sync,no_subtree_check)   xx.xx.xx.xx(rw,sync,no_subtree_check)
/var/nfs/hoya_model_root  xx.xx.xx.xx(rw,sync,no_subtree_check)   xx.xx.xx.xx(rw,sync,no_subtree_check)
/var/nfs/hoya_str_root   xx.xx.xx.xx(rw,sync,no_subtree_check)   
xx.xx.xx.xx(rw,sync,no_subtree_check)

  • nfs server설정이 끝났습니다. 다음에는 nfs를 gpu인스턴스에 연결하고 nvidia-docker를 설치해서 gpu instance를 올려보도록 하겠습니다 ^^service nfs-kernel-server reloadnfs service를 Reload한다.

Deep Learning Cluster with AWS for CPU

 

한국 지역 설정하기

sudo locale-gen ko_KR.UTF-8

tzselect

sudo apt-get install language-pack-ko

 

docker CE올리기

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

sudo apt-key fingerprint 0EBFCD88
sudo add-apt-repository \
  "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) \
  stable"


sudo apt-get update
sudo apt-get install docker-ce

도커를 ubuntu계정에서 실행하게 변경(리붓해야지 반영됨)

sudo groupadd docker
sudo gpasswd -a ubuntu docker

 

우리 도커를 다운 받는다.

docker pull hoyai/hoyai_dev_docker:squashed

 

1번 서버는 nfs server를 올린다.

sudo apt-get install nfs-kernel-server

 

nfs 마운트 포인트를 만든다

sudo mkdir /var/nfs/hoya_src_root -p
sudo mkdir /var/nfs/hoya_model_root -p
sudo mkdir /var/nfs/hoya_str_root -p
sudo mkdir /var/nfs/hoyai_playground -p


sudo chown nobody:nogroup /var/nfs/hoya_src_root
sudo chown nobody:nogroup /var/nfs/hoya_model_root 
sudo chown nobody:nogroup /var/nfs/hoya_str_root

nfs conf

vi /etc/exports


/var/nfs/hoya_src_root   xx.xx.xx.xx(rw,sync,no_subtree_check)   xx.xx.xx.xx(rw,sync,no_subtree_check)
/var/nfs/hoya_model_root  xx.xx.xx.xx(rw,sync,no_subtree_check)   xx.xx.xx.xx(rw,sync,no_subtree_check)
/var/nfs/hoya_str_root   xx.xx.xx.xx(rw,sync,no_subtree_check)   xx.xx.xx.xx(rw,sync,no_subtree_check)

nfs reload 한다

service nfs-kernel-server reload

 

AWS에서 nfs용 Security group을 설정한다.

 

TCPPort (Service) Source 111 0.0.0.0/0  2049 0.0.0.0/0  32768 0.0.0.0/0  44182 0.0.0.0/0  54508 0.0.0.0/0

UDPPort (Service) Source 111 0.0.0.0/0  2049 0.0.0.0/0  32768 0.0.0.0/0  32770-32800 0.0.0.0/0

 

  • gpu에서 ap1번으로 붙는지 테스트 해봄

 

Hoya Docker cluster용(AP용) seciruty group 설정

Port (Service) Source Port (Service) Source 4369 0.0.0.0/0  25672 0.0.0.0/0  5672 0.0.0.0/0  2266 0.0.0.0/0  5432 0.0.0.0/0  8000 0.0.0.0/0  6006 0.0.0.0/0  8888 0.0.0.0/0  5901 0.0.0.0/0  5555 0.0.0.0/0

도커를 실행하면서, nfs 포인트로 올리고, 부팅시 자동으로 올라가게 하고, vnc확인하고, host도 확인하고,

도커를 재부팅시 자동으로 올라가게 설정 도커 이름은 hoyai_dev로 설정한다

docker run -itd --env="VNC_RESOLUTION=1920x1080" --env="DISPLAY" --env="QT_X11_NO_MITSHM=1" --volume="/tmp/.X11-unix:/tmp/.X11-unix:rw" --volume="/var/nfs/hoya_src_root:/hoya_src_root" --volume="/var/nfs/hoya_model_root:/hoya_model_root" --volume="/var/nfs/hoya_str_root:/hoya_str_root" --name hoyai_dev -p 4369:4369 -p 25672:25672 -p 5672:5672 -p 2266:2266 -p 5432:5432 -p 8000:8000 -p 6006:6006 -p 8888:8888 -p 5901:5901 -p 5555:5555 hoyai/hoyai_dev_docker:squashed

 

도커가 자동으로 올라가게 설정한다.

cd /etc/systemd/system/
 vi docker_hoyai.service
[Unit]
Description=hoyai container
Requires=docker.service
After=docker.service

[Service]
Restart=always
ExecStart=/usr/bin/docker start -a hoyai_dev
ExecStop=/usr/bin/docker stop -t 2 hoyai_dev

[Install]
WantedBy=default.target

도커 스타트업 스크립트

sudo systemctl enable docker_hoyai.service
   
   sudo systemctl start docker_hoyai.service

도커 서비스 삭제 스크립트

sudo systemctl disable docker_hoyai.service
  
  sudo systemctl stop docker_hoyai.service
sudo apt-get install nfs-common

 

도커 속에서 cluster 설정하기

hoyai/settings.py에서 DB를 AP1번을 보도록 설정

git에서 settings.py 추적 안하게 변경

git update-index --assume-unchanged hoyai/settings.py

 

각서버별로 장고가 뜨는지 확인

hosts파일을 만들어서 ap1, ap2, gpu1, gpu2에 배포

ssh를 활용해서 각각 서버에 붙는지 확인한다.

 

rabitmq cluster 연결을 위한 erlang cookie 맞추기

 

master에서 cooker를 보고, slave에 복사해준다

vi /var/lib/rabbitmq/.erlang.cookie

 

slave는 끄고

service rabbitmq-server stop

erlang cookie 복사하고

다시 스타트

service rabbitmq-server start

 

 

rabbitmq cluster를 확인한다.

rabbitmqctl cluster_status

 

hoya settings.py의 celery 설정 부분을 변경한다.

host는 master의 Docker id로 변경

CELERY_BROKER_URL = 'amqp://tensormsa:tensormsa@'+host+'//'

result_backend = 'db+postgresql://xxxxxxxxxxxxx'

 

entrypoint에 hosts파일 add하는것을 추가

echo "xxx.xxx.xxx" >> /etc/hosts

 

gpu1번을 ap1에 조인

rabbitmqctl stop_app

rabbitmqctl join_cluster --ram rabbit@16224139bcee


rabbitmqctl start_app

gpt2번을 ap1에 조인

rabbitmqctl stop_app

rabbitmqctl join_cluster --ram rabbit@16224139bcee

rabbitmqctl start_app

 

클러스터에서 빠지기

rabbitmqctl reset

 

 

 

 

 

 

 

client nfs 설치한다

sudo apt-get install nfs-common

 

부팅했을때 nfs가 자동으로 붙도록 설정

hoya_src_root, hoya_model_root, hoya_str_root 3개 디렉토리 설정

sudo mkdir /hoya_src_root -p
sudo mkdir /hoya_model_root -p
sudo mkdir /hoya_str_root -p

 

vi /etc/fstab
xx.xx.xx.xx:/var/nfs/hoya_src_root /hoya_src_root nfs hard 0 0
xx.xx.xx.xx:/var/nfs/hoya_model_root /hoya_model_root nfs hard 0 0
xx.xx.xx.xx:/var/nfs/hoya_str_root /hoya_str_root nfs hard 0 0

 

reboot 해서 df -h로 nfs가 잘 붙는지 확인한다

df -h

 

gpu Tensormsa Docker를 받는다

docker pull docker pull hoyai/hoyai_gpu_dev_docker:v1.0

 

gpu docker 를 실행한다.

nvidia-docker run -itd --env="VNC_RESOLUTION=1920x1080" --volume="/hoya_src_root:/hoya_src_root" --volume="/hoya_model_root:/hoya_model_root" --volume="/hoya_str_root:/hoya_str_root" --name hoyai_dev -p 4369:4369 -p 25672:25672 -p 5672:5672 -p 2266:2266 -p 5432:5432 -p 8000:8000 -p 6006:6006 -p 8888:8888 -p 5901:5901 -p 5555:5555 hoyai/hoyai_gpu_dev_docker:v1.0

docker 서비스를 올린다.

sudo gpasswd -a ubuntu docker

 

 

cd /etc/systemd/system/
 vi docker_hoyai.service

 

[Unit]
Description=hoyai container
Requires=docker.service
After=docker.service

[Service]
Restart=always
ExecStart=/usr/bin/nvidia-docker start -a hoyai_dev
ExecStop=/usr/bin/nvidia-docker stop -t 2 hoyai_dev

[Install]
WantedBy=default.target

 

sudo systemctl enable docker_hoyai.service

sudo systemctl start docker_hoyai.service

 

sudo systemctl disable docker_hoyai.service

sudo systemctl stop docker_hoyai.service

 

AP1, GPU2, GPU2의 docker id와 IP를 찾는다.

Docker Custom Repository

우리가 Docker 로 실무 환경을 구성하다 보면  보안 등의 문제로 Docker Hub 를 사용할 수 없는 경우가 있다. 이러한 경우 별도의 Repository 를 등록하여 사용할 필요가 있는데 핵심만 정리하면 몇줄만으로 요약될 정도로 간단하다.
더 복잡한 설정이 필요하신 분들은 아래의 링크를 참조하시면 된다.

Docker 설치 : 링크
Docker Repository :  링크
Docker Pull/Push : 링크

1. Docker 설치 : 생략
Docker 설치는 Repository 서버로 사용할 서버와 Push/Pull 할 서버 양쪽에 설치

2. Repository : Docker Repository Docker Image Run
아래는 단순히 Local Disk 를 사용하도록 실행하는 Command 이다.  (S3등은 별도 설정 必)
아래 한줄 실행해 주면 Repository 설정은 끝났다. .. 끝..

docker run --name personal-registry -d -p 5000:5000 -v /tmp/registry:/tmp/registry  registry

3. Client : HTTP 허용 설정
Custom Repository 는 Http 통신을 사용하는데, 기본 Docker 는 Https 만 허용하고 있기 때문에 아래와 같이 http 를 허용하도록 설정 할 필요가 있다.

/etc/docker/daemon.json
{"insecure-registries":["myregistry.example.com:5000"] } 
sudo service docker restart

4. Client : pull & push
– Docker Push

docker tag myregistry.example.com:5000/myregistry
docker push myregistry.example.com:5000/myregistry

– Docker Pull

docker pull myregistry.example.com:5000/myregistry

 

 

Chat Bot with Deep Learning on Real Field

  • 참조 Source GitHub : https://github.com/TensorMSA/tensormsa1. 개요
    Story Board 기반의 ChatBot 을 Deep Learning 을 활용하여 만든 경험을 공유하고자 한다. 기본적으로 프로젝트 Scope 은 사람을 찾는 업무로 한정되었다.
    Deep Learning Base 로 NLP 처리를 하기 위해서는 첫 번째로 문제가 되는 것이 데이터를 만드는 일이다. 사람 찾기의 경우 사람마다 질문하는 패턴이 매우 상이하다는 점은 다른 비지니스와 다를 바가 없었으나,  “사람이름”, “부서”, “업무” 등 각각 하나의 계열사만 해도 수천건 전체 수만건 이상의 데이터를 갖는 부분들 때문에 데이터를 어떻게 생성해야 할지 고민이 되었다.

    2. 데이터 생성
    데이터 생성에서 가장 먼저 생각한 것은 사람의 노동력을 최소화 하는 것이었다. Brat 과 같은 iob Tagging 을 위한 Tool 의 사용도 고려하였지만 그 또한 편의성을 제공할 뿐이지 엄청난 노동력을 필요로 하였기 때문에 고려 대상에서 제외하였다.
    사람의 노동력을 최소화 하기 위해서 Entity Name 으로 구성된 문장 패턴과 각 Entity 의 List 두 가지를 사람이 생성하고 NER 처리, Word Embedding 처리, Intent Anal 처리에 필요한 데이터를 자동으로 생성하여 사용하였다.
    위와 같은 형태로 사람은 기존의 업무 시스템에서 추출 가능한 기준성 정보 + 비교적 적은 노력이 필요한 패턴 데이터만 입력하면 실제 훈련이 필요한 3가지 타입의 데이터를 자동을 생성하도록 하였다.
    실제 5가지 정도의 Entity, 각 Entity 기준 정보 1만 ~ 5만건과 다양한 패턴 문장 100여가지 를 조합하여 데이터를 생성한 결과 500G 이상의 데이터가 생성 되었으며 iob, plain, intent 형태로 따로 생성하면 X3 1.5Tb 정도의 데이터가 생성되었다.

3. 모델 훈련 및 튜닝 
Deep Learning 에 물론 많은 데이터가 있으면 좋지만, 무작정 많은 데이터를 사용할 수는 없다고 생각하였다. 다른 업무까지의 확장을 생각하면 사람찾기 업무 하나에 1.5TB 는
조금 많다고 생각하였다. 결국 전체 데이터가 아닌 일부 데이터를 활용하여 전체 Case 를 만족할 수 있도록 만들기 위하여 기존에 단어 단위로만 Embedding 하던 것을 음소 단위까지 Vector 화하여 합쳐서 사용하는 방향으로 모델들을 변경하였다.

NER 의 경우 부서와 업부의 경우 워낙 유사한 패턴이 많아서 약간의 혼동이 있는 결과가 나왔지만, 전체적으로 92.4% 정도의 정확도를 보여주었다.
Word Embedding 의 경우 동일한 데이터로 훈련을 하였기 때문에 NER 에서 사용할 때 Face Book 에서 제공하는 한글 Vector 를 사용하는 것도다 더 좋은 결과가 있었다.
Intent 분석의 경우 Char CNN 을 사용하여 의도를 구분하는데 90% 이상의 분류율을 보여주었다.

4. 서비스 개발 
이렇게 생성된 NER, Word Embedding,  Intent, 답변 가능여부 신경망을 내부적으로 사용하여 모바일 및 브라우져를 통해서 입력되는 문장을 이해하고 서비스하기 위해서 내부적으로 Story Board 를 선택하고 Slot 을 채워서 서비스를 하기 위한 별도의 Scoring 로직을 개발하여 Deep Learning 만으로 해결되지 않는 Case 들을 처리 할 수 있도록 하였다. 이 부분에 대해서는 별도의 포스팅을 통해 자세히 설명할 수 있도록 하겠다.

Deep Insight

Deep Learning Project에서 Deep Insight를 얻기 까지는 많은 시간이 소요된다.

주어진 과제에 급급하여 Project를 하다보면, 우리가 얻는 것은 신기루 뿐이다.

Data를 바라보고 수집하고 Parameter들을 Estimation하면서 그들의 Tendency를 유추해 나가고 그들의 표면적인 모습들이 아닌 Deep Relation의 Attribute까지 밝혀낼 수 있으려면 우리는 우리의 목표와 기준 잣대로 평가하기 보다는

Hyper Parameter들의 수많은 궤적들을 Business측면의 Reassign된 Vector평면 속에서 의미를 추론해 나가야 한다.

AutoML이 대두되고 있지만 이는 현재는 논문 Scope을 벗어나지 못하고 있다.

예를 들자면 자연어 처리의 경우 인간은 상대방이 한 말을 벡터차원에 뿌리고 그들의 유사도와 긴밀성을 추론하여 판단하지 않는다.

즉 우리는 수많은 가정속에 그것들을 녹이고 그것의 경향성을 판단할 뿐이지 그것이 맞다고는 볼수 없다

즉 Mechanic, Bio, Industry 등 모든 Input과 Output이 될 수 있는 지점을 바로보고 그들을 유추할 수 있는 것은 바로 Input과 Output Data들을 수 없이 바라보고 애정을 갖고 있는 사람들이다.

그들과 긴밀하게 커뮤니케이션 하지 않고서는 AutoML에 대한 구현은 쉽지 않을 것이다.

인간과 Deep Learning 그들은 Deep Tendency를 갖고 있기 때문이다.

사람과 기계 마찬가지로 그들의 깊숙한 고민까지 털어놓을 수 있게 까지는 많은 시간이 소요될 것으로 본다.

AutoML – Hyper Parameter Optimization

  • 참조 논문 :  링크
  • 참조 구현물 : 링크
  • Tensorflow 적용 Test : 링크
  • AutoML 참조 : http://www.automl.org/hpolib.html
  • AutoML GitHub :  https://github.com/SheffieldML/GPyOpt
  1. 개요
    최근 Google 에서 Deep Learning Engineer 부족에 대한 해결방안으로 AutoML 이라는 프로젝트를 Release 하였다.  Google 이 이번에 발표한 AutoML 은 단순히 Hyper Prameter 튜닝만을 제공하는 것이 아닌 데이터에 따른 최적의 알고리즘까지 찾아주는 역할을 한다고 한다.
    하지만 현실적으로 알고리즘 선정과 데이터에 대한 Insight 까지 AI 가 대체하기는 아직은 시기상조라고 개인적으로 생각하며, 데이터와 AI 모델에 대한 부분은 Deep Learning Engineer 에 맡겨 두는 것이 효과적이고 사람의 Insight 로 쉽게 해결이 되지 않는 다른 부분들을 자동화하는 것이 의미가 있다고 생각했다.
    현재 Deep Learning 프로젝트를 진행하면서 투입되는 Process 별 노력을 생각하여 보면 새로운 알고리즘을 논문을 통해 파악하고 코드로 재현하는 과정도 있지만, 사실 대부분의 시간은 데이터 수집, 전처리, 신경망 최적화 반복 작업에 소비하게 된다.
    본 Blog 포스트는 신경망 최적화 부분을 (Hyper Prameter 튜닝) 을 효과적으로 하는 방법을 실제 Tensorflow 프로젝트에 적용한 사례를 정리하고자 하는 목적을 가지고 작성되었다.
  2. 접근 방법
    참조한 논문은 Speeding up Automatic Hyperparameter Optimization of Deep Neural Networks by Extrapolation of Learning Curves 로 Hyper Parameter를 Ransom 하게 Search 하는 과정에서 결과가 안좋을 것으로 예상되는 Hyper Parmeter 조합에 대해서는 사전에 이를 예측하고 해당 Train 작업을 Teminate 하여 전체적인 탐색 시간을 줄이는 것에 있다.
    이를 위해서 Parametric Learning Curve Models 을 사용하는데 이러한 모델들의 목적은 Train Iteration 진행에 따른 Accuracy 변화를 예측하는 Learning Curve 모델을 제공하는데에 있다.
    예를 들어 최종결과에 대한 평가를 5000 Iter 에서 한다고 하면 500 iter 까지의 추이를 보고 5000 Iter 에서 Accuracy 가 어떻게 될지를 예상하는 형태라고 보면된다. 여기서 X 축은 정해진 Interval 에 +1 씩 증가하는 형태로 구성되며, 각각의 모델은 실제 훈련시 발생하는 1 ~ 500 (데이터 수집범위) 데이터를 가지고 아래에 명시된 11개의Parametric Learning Curve Models 모델의 Weight 값들을 훈련하고 이 모델을 사용하여 예측하고자 하는 5000 Iter 지점의 Accurcy 값을 예측한다.
    이렇게 여러가지 모델을 사용하는 이유는 어떤 모델 하나가 정확한 결과를 예측한다고 신뢰할 수 없기 때문이며, 실제 사용시에는 이렇게 훈련된 각각의 모델을 아래와 같이 합쳐서 하나의 더 강력한 식으로 만들어서 사용한다.

    fcomb(t|ξ) = X K k=1 wkfk(t|θk), 
    ξ = (w1, . . . , wK, θ1, . . . , θK, σ2 )

    이렇게 하나로 합쳐진 식에서 Weight 값을 구하기 위해 가장 단순하게 접근할 수 있는 방법은 아마도 주어진 X,Y 데이터로 Maximun Likelihood 를 만족하는Weight Value 들를 찾아버리는 것이 될 수 있겠지만, 이렇게 접근하면 모델의 불확실성을 커버할 수가 없게 된다.  결국 우리가 하고 싶은 것은 초기의 데이터를 가지고 한참 뒤의 y 값을 Bayesian 의 관점에서 MCMC 를 활용하여 예측하고 이를 바탕으로 현재 가지고 있는 최선의 Accuracy 보다 그 예측 값이 낮다면 끝까지 Train 을 진행하지 않고 미리 Termination하는 것이다. 이러한 종류의 확률적 추론을 가능하게 하기 위해서는 Prior (Bayesian : P(X|Y)P(Y|X)P(X) ) 의 사전정보 P(X) 는 주어지지 않았기 때문에 각각의 파라메터에 대해서 Set 해야하는데 간단하게 p(ξ) ∝ 1. 로 정의해 버리면 Weight 값이 음수가 되어서 특정시점 이후로 하락하는 종류의 모델이 만들어 진다던지 하는 문제가 있을 수가 있다.
    이러한 문제를 해결하기 위해서 좋은 Learning Curve 모델은 증가하는 형태의 모델이다라는 사전지식을 반영하여 Weight 값을 양수값으로 제한하고 결과적으로 아래와 같은 새로운 Prior 를 정의한다.

    p(ξ)∝ Y K k=1 p(wk)p(θk) ! p(σ 2 )1(fcomb(1|ξ)
    
    p(wk) ∝  1 if wk > 0 0 otherwise . 
     
    

    이제  E[X]=XXP(X|Y)dX 와 같이 적분을 통해서 그래서 예측하고자하는 Accuracy y^ 이 어떻게 될지 찾아야 하는데, 적분 대신에  MCMC (Markov Chain Mote Carlo) 을 사용하여 XXP(X|Y)dXi=1NP(Xi|Y)∫XXP(X|Y)dX∼∑i=1NP(Xi|Y)  를 사용하여 최종적으로 우리가 알고자하는 Y (Accuracy 를 추론한다)
    참조 :  http://enginius.tistory.com/514
    참조 : http://www.4four.us/article/2014/11/markov-chain-monte-carlo

3. 적용
이 논문의 내용은 Hyper Paremter를 어떻게 탐색하는가에 대한 것이 아닌 끝까지 Train 을 진행하지 않고 사전에 결과를 예측하여 전체적인 탐색 속도를 향상사키는 것에 있으며, 실제 적용시에는 Hyper Parameter 의 Range 를 지정하고 탐색 Matirx 를 구성하고 실제로 Train 을 반복적으로 실행하는 환경은 구성을 해야 한다.  그 후에 특정 Iter 가지 진행한 Accuracy Learning Curve 정보를 가지고 위에 설명한 데이터를 예측하여 나온 Accuracy 가 지금까지 우리가 가지고 있는 최대 Accuracy 와 비교하여 그 이하라면 중단하는 형태로 구현을 하면된다.  실제 간단한 DNN 에 적용하여 테스트해본 결과 위의 논문과 같이 모델을 구성하여 예측하는 과정이 CPU 기준으로 10분정도 소요되어 아주 작은 데이터에 대해서 테스트 시에는 크게 효용이 없을 것으로 보이며 진자 bigData 에 대해서만 의미가 있을 것 같다. 또, GPU 서버와 CPU 서버를 분리하여 예측 작업을 분리하여 처리하여 GPU 서버에서의 작업은 계속해서 진행하면 Over Head 를 줄 일 수 있을 것 같다. 또 가장 궁금한 실제 예측 모델에서 예측한 Accuracy 와 실제로 훈련을 계속 했을때의 정확도가 얼마나 오차가 있는지는 Sample 데이터로 수행을 했을때는 큰 차이가 없었다. 다만, 실무에서는 깔끔하게 Learning Curve 가 구성되지 않고 발산하면서 감소하거나, Mini Batch 등을 실행 하였을때의 Learning Curve 를 예측 할 수 있는지는 잘 모르겠다..