January 31, 2017

(딥 러닝) 자연어 처리의 4가지 주요 공식: Embed, Encode, Attend, Predict

자연어 처리 관련 딥 러닝 아키텍처를 보면 대게 Embed, Encode, Attend, Predict 4가지로 구성된다. 때문에 이 4가지만 제대로 알아도 이해가 가능하다.

 그러면, 제일 먼저 Embed. 단어를 n차원 실수 공간으로 옮기는 작업을 말한다. Image 따위를 vector로 변환하는건 다른 위상 공간으로 embedding하는 것이 아니므로 그냥 encoding이라는 표현을 쓴다. 여튼 수학표기는 다음과 같지:

\(W: \mathrm{words} \to \mathbb{R}^n\)


 다음은 Encoding 작업인데, "embedded vectors"를 sentence matrix로 계산하는 과정이다. 여기서 s는 (zero-padded) sentence length이고, d는 embedding의 dimensionality를 뜻한다:

sentence matrix \(A \in \mathbb{R}^{s×d}\)


 다음으로 Attend. "attended vector" 라는 표현을 자주 볼 수 있는데, 이는 행렬이 다시 single vector로 차원 축소되었다는 얘기다. max-pooling, sum-pooling 뭐 그런 방법을 사용하는데, MathJax에 익숙치 않아서 대강 적어보면 요정도 되시겠다:

attention vector \(σ\) = SumPool\((A_{i,1})\), ..., SumPool\((A_{i,K})\)


 마지막으로 Predict. 위 단계에서 구한 "attended vector"가 출력층에 전달되는 과정이다. SoftMax 뭐 그런 확률 모델 등이 있는데 너무 많으니 생략. NLP 모델은 대게 feed-forward 구조라서 보통 이 4가지의 단계를 따른다. Training은 back propagation이 있겠는데 최적화 이론은 조금 긴 얘기라 역시 생략. 

 그림으로 표현해서 구독자들께 전달하고 싶긴하나 귀찮고 어려운 작업이라 .. 검색한 이미지를 가져다 붙이면 대략 이런 느낌이다:


 최근 논문 중 paraphrase detection, factoid Q&A, 기타 등등 대부분은 이 4가지로 끝나는걸 볼 수 있다.

January 23, 2017

존! 나 고심끝에 이직해

 네이버, KT, 오라클, 그리고 잠깐의 사업을 거쳐 삼성전자에 입사한지도 2년이 지났습니다. 2016년 병신년을 뒤로하며 이번에는 꽤 색다른 도전에 나섭니다. 무슨 일이야!? 국내 O2O 숙박전문 회사 CTO로 조인합니다!


존! 나 고심끝에 이직해~

 그간 입사 제의를 받더라도 이직 자체가 비용이며 리스크이기 때문에 움직일 생각은 별로 안하고 있었습니다. 그런데, 특별히 이런 결정을 내린 계기가 있느냐 ...

 누군가 나에게 "당신이 생각하는 4차 산업 혁명의 키워드를 대봐라" 하면 AI, IoT internet, On-demand economy, O2O commerce 라 딱 4개 대답합니다.

 앞의 AI와 IoT internet은 주도 기술이며 뒤의 On-demand economy, O2O commerce는 기술 변화에 따른 경제 구조와 소비 양식의 변화를 말합니다.

 영리기업의 인공지능 R&D는 결국 지능적 서비스-이익 체인 시스템을 위한 겁니다. O2O 상거래 순환 구조 안에 그러한 기술이 총망라 될 것으로 보고 있고, 온-오프 사업자, 광고주, 그리고 소비자 간 win-win-win 모델이 형성되며 신종 B2C, B2B 신규 사업 확장의 기회 또한 상당히 클 것이라 내다 보고 있지요.

 이러한 변화는 어느 정도 예견은 되고 있었습니다. 그게 생각보다 상당히 빠르게 다가오고 있는게 현실인데, 역시나 이를 잘 대응하는 것은 대기업이 아니라 startup들입니다.

 모텔/숙박 O2O 또한 그 지점 한켠에 잘 포지션 되어있는데, 가령 기존 소비 패턴인 웹을 통한 숙박정보 조사와 예약 과정의 틈을 사이언스와 정보기술 엔지니어링으로 잘 메울 경우, 소비자는 다양한 편의성과 비용절감 효과가, 비즈니스 소유자는 완전히 추적 가능한 매출 흐름을 창출 할 수 있게 됩니다. 광고주는 지역 비지니스 특성상 필요한 마케팅 지출을 효과적으로 집행하도록 하는 한편 ROI를 온전히 보상받을 수 있게 되죠.

 결론적으로, 기업의 아이덴티티, 그리고 CTO라는 포지션으로 접하게 될 과제가 너무 기대되고, 개인적으로 경험할 것과 배울 것 또한 많다는게 이유입니다.

 앞으로 잘 지켜봐주세요.

January 16, 2017

Java에서 Aparapi를 이용하여 GPU 활용해보기

AMD에서 개발한 Aparapi를 이용하면 Java에서도 굉장히 편하게 GPU를 활용해볼 수 있다. 먼저 AMD APP SDK (AMD OpenCL™ Accelerated Parallel Processing) 를 설치해보자: 다운로드
 % bzip2 -d AMD-APP-SDKInstaller-v3.0.130.136-GA-linux64.tar.bz2 
 % tar xvf AMD-APP-SDKInstaller-v3.0.130.136-GA-linux64.tar 
 % sh ./AMD-APP-SDK-v3.0.130.136-GA-linux64.sh 
 % ls ~/AMDAPPSDK-3.0/include/
기타 설정은 https://wiki.tiker.net/OpenCLHowTo 에서 확인할 수 있고, 최종 설치가 잘 완료 되었는지 확인을 위해서 tools-master를 사용해보면 devices 정보가 나온다. 실험장비에는 Tesla k80이 총 16개 꽂혀있다.
 $ curl https://codeload.github.com/hpc12/tools/tar.gz/master | tar xvfz -
 $ cd tools-master
 $ make OPENCL_INC=/home/edward.yoon/AMDAPPSDK-3.0/include/
 $./print-devices 
./print-devices: /usr/local/cuda-7.5/lib64/libOpenCL.so.1: no version information available (required by ./print-devices)
platform 0: vendor 'NVIDIA Corporation'
  device 0: 'Tesla K80'
  device 1: 'Tesla K80'
  device 2: 'Tesla K80'
  device 3: 'Tesla K80'
  device 4: 'Tesla K80'
  device 5: 'Tesla K80'
  device 6: 'Tesla K80'
  device 7: 'Tesla K80'
  device 8: 'Tesla K80'
  device 9: 'Tesla K80'
  device 10: 'Tesla K80'
  device 11: 'Tesla K80'
  device 12: 'Tesla K80'
  device 13: 'Tesla K80'
  device 14: 'Tesla K80'
  device 15: 'Tesla K80'
이제 Aparapi를 써보자. Aparapi도 바이너리 릴리즈가 없고 직접 github source build 해야한다.
 $ git clone https://github.com/aparapi/aparapi.git
 $ ant -Dapp.sdk.dir=/home/edward.yoon/AMDAPPSDK-3.0/
빌드가 완료되면, 간단한 행렬 곱셈 프로그램을 구현해서 바로 실험해볼 수 있다. 코드가 1차 배열인 이유는 Aparapi는 다차배열 처리를 지원하지 않기 때문.
실험에서는 빠른 테스트를 위해 복붙 from https://vasanthexperiments.wordpress.com/ 100x 정도를 기대했지만, 10x 정도까지는 가속을 해주는 것으로 보인다.
edward.yoon@dl03:~$ javac -g -classpath .:/home/edward.yoon/aparapi.jar Test.java
edward.yoon@dl03:~$ java -classpath ./:/home/edward.yoon/aparapi.jar Test
Time taken for kenel execution in GPU mode is :43320
Time taken for kenel execution in Sequential CPU mode is :342491

December 27, 2016

4차산업 혁명, 직장인에게 퇴사란(?)

 * 사는 것보다 파는 것이 더 중요하다 -- 주식 고수들
 * 등산보다 하산이 더 중요하다 -- 등산하는 사람들
 * 빨리 올라가는 것보다 잘 내려오는 것이 더 중요하다 -- 정치인들
 * 이륙하는 것보다 착륙하는 것이 더 중요하다 -- 파일럿들
 이렇듯 회사 또한 입사하는 것보다 언제 어떻게 퇴사하는지가 중요하다. 우리는 도대체 언제 퇴사해야 할까? 잘 내려오지 못하면 이전보다 더 높이 올라 갈수가 없거든. 

 먼저 실리콘 밸리의 IT 업계를 얘기 한번 들어보자. 태평양을 건너 구글에 입사한 친구 왈, 1년차 퇴사율이 50%에 육박한다고 한다. 여기서 대부분의 한국 직장인들은 의아해 한다. "그리 좋은 회사를 와이!?". 우리는 퇴사라는 단어를 너무 부정적인 의미로 바라보기 때문이다. 내가 이해하는 (좋은 회사를 박차고 1년 이내 퇴사한) 그들의 이유는 의외로 대단히 간단명료하다. 좋은 회사에 취업하는 것이 그들의 목표가 아니기 때문이야.

 왜 한국 인재들은 대기업에 취업하는 것을 고집할까? 첫째도 둘째도 안전했으니까 그렇다. 과거의 한국 제조 산업을 보자. 고용 보장으로 애사심과 근면한 장인 정신을 고취하고 이를 통해 경쟁력을 세계 수준으로 끌어올려왔다. 우리는 모두 그러한 사회에서 근면성실을 최고의 덕목으로 '개근상'이라는 것이 있었고, 부득이한 조퇴 조차 눈치 보며 학교를 다녔지. 우리가 어른이 된 이후 직장 생활에서는 다를까? 연차 휴가를 회사 눈치보지 않고 사용하는 직장인이 과연 몇명이나 될까? 요즘도 농업적 근면성이 갑이다 (비웃음).

 각설하고 문제는 요즘의 회사가 경제구조가 빠르게 변하는 데에 있다. 근속 연수는 계속 짧아지고 일자리는 계속 사라지고 있다. 튼튼한 자동차, 반도체 등 제조 산업은 위기를 당면하고 있으며, On-demand 경제라는게 물 밀듯이 밀려온다. 이러한 상황에서 고용 보장, 대기업 같은 구시대적인 것만 붙잡고 늘어진다면 고민과 시름은 한없이 깊어진다.

 우리는 이때문에 앞으로 퇴사를 실패의 부정적 의미가 아니라 성장하기 위한 과정으로 이해해야하며, 직장인은 항상 퇴사를 진지하게 고민해야할 필요가 있다. 직장생활이 더러워서가 아니라 그게 닥쳐오는 현실과 미래이며, 좋은 회사를 찾는게 아니라 내가 성장하기 위한 회사를 찾아야 하며, 궁극적으로는 자신의 일과 자생력을 만들어 나아가야 한다고 본다.

 사실 이 글을 작성한 계기는 챠니윤의 "개발자 경력 관리 조언" 글을 읽은 것인데, 경력 관리를 통한 "취업전"보다는 자신에 대한 성찰이 먼저여야 하며, (이 글을 접하는 이에게 나마) 화려한 과거 경력이 미래의 일자리를 보장하지 않는다는 점을 말하고 싶었다.

December 5, 2016

Serverless Computing will be game changer

The core of the emerging Serverless Computing is the programming model paradigm, not container infra technology. One example is the existing event processing programming, which takes the stream data produced in the real world and emits it to the backend,
   frontend: App program -> emit streaming data to backend
   backend: kafka -> storm / spark / dataflow -> data store -> reuse
Inefficiency and disadvantages arising from the structure of the frontend and the backend are complex and slow (eg, distributed queuing, distributed streaming processing, etc.) and difficulty in constructing the server-side system. In particular, the task topology management problems of DAG-style or minibatch-style job are difficult. These are the Storm, Spark, which is now going to legacy.

So how does this change in Serverless?
  App program: pipeline of lightweight functions
To achieve this, runtime provisioning of lightweight function services is required, and that is Serverless Computing.

As another example, imagine the prediction model of Google Flights introduced in the previous post. The traditional approach would be to implement the prediction service by deploying the learned model with the existing dataset:


Machine Learning can also be implemented with the Serverless Computing Architecture in the fashionable DevOps style. The following is the Serverless Architecture of the event-driven prediction algorithm:


The advantage of this is that the complexity of the implementation and system is dramatically reduced, and it is possible to design the system with a decentralized architecture.