딥 러닝의 블랙 박스 열어보기

Opening the black box of Deep Neural Networks via Information
- https://arxiv.org/pdf/1703.00810.pdf

지금까지 딥 러닝은 어떻게 동작하는지 이해할 수 없다고 믿어져왔다. 그러나, 천재들은 그 근본 원리를 이해하려고 노력하고 있지.

이 논문은 SGD가 무슨 역할을 하는지에 대한 해석으로, 이들은 SGD가 drift와 diffusion단계로 구분된다고 설명한다.

첫 drift 단계에서는 multidimensional space를 탐험하고, 수렴을 시작하면 diffusion 단계로 접어들어 (첨부 그림에서 점선 오른쪽에 해당) 굉장히 느려지기 시작하며 chaotic 한 단계로 들어가는데 이게 바로 네트워크가 압축하는 법을 배우는 과정이라는 것이다.

SGD의 무질서도는 local minima에 빠지지 않고 더 나은 방향으로 수렴 할 가능성을 제공 할 뿐만 아니라, diffusion 단계에서 매우 효과적인 internal representations(?)를 생성하는데 자기가 볼쩍에 다소 과한것으로 보이며, 자기들의 IB iterations with stochastic relaxation methods로 DNN 학습 방법을 개선할 수 있을거라고 얘기한다.

제프리 힌트 교수가 지대한 관심과 찬사를 보냈기에 많은 관심을 받고 있는 내용인데, 딥 러닝 대가들의 근본 원리와 최적화 이론에 대한 얘기라, 나는 훔쳐만 봤지 뭔소리인지는 정확히는 이해하기 어렵다.

THE HUNT (JAGTEN)

추측으로 만들어진 억측 또는 소문을 ‘카더라 통신’이라고 한다. ‘누가 언제 어쨌다 카더라.’로 시작되는 이야기. 믿거나 말거나 장난처럼 흘린 말이 시간이 지나면서 엉뚱한 방향으로 튀어 종잡을 수 없게 된다. 급기야 열기구처럼 둥둥 떠다니며 온갖 티를 묻히기도 하는데, 그 볼썽사나움이란 형언하기조차 어렵다.

요즈음에는 ‘넷카시즘’이 횡행한다. 인터넷이나 SNS 공간에서 누리꾼 다수가 특정 개인을 공격하는 것 말이다. 마녀사냥이라고 해야 할지. 광속도로 자행되는 돌팔매질 앞에서 당하는 사람은 속수무책이다.

둘의 공통점은 불특정 다수가 특정 개인을 잡도리한다는 것이다. 자신과 이해관계가 없음에도, 심지어 상대를 잘 알지 못함에도 덩달아 가담하여 사태를 악화시킨다. 

‘거짓 동의 효과’라는 게 있다. ‘다른 사람이 나와 같을 것으로 생각하는 경향으로 그들에게 자신을 투영하는 현상.’을 말하는 것인데, 집단적 왜곡으로 치달을 때 그 파괴력은 상상을 초월한다. 속된 표현으로 사람 잡을 일이다. 

잠시 우리 직장으로 고개를 돌려보자. 지금 우리는 어느 동료직원에게 돌을 던지고 있지 않은가. 어떤가. 부지불식중에 확인되지 않은 남 이야기를 하고 있지 않느냐 말이다.

이러한 상황에 내몰린다면 어떻게 처신해야할까? 편히 앉아 영화 한편 때리셔라. The Hunt.

페이스북, AI의 직관적 물리학 체계 실험

아들을 데리고 탄천을 산책 하면서 우연히 돌계단을 오르며 생각했다. 표면이 고르지 않은 돌계단에 나는 내딛을 위치를 어떻게 결정하고 있는가?

우리의 뇌는 직관적 지름길과 어림법^heuristic을 많이 가지고 있다. 예를 들면, 움직이는 물체의 궤적을 예측할 수 있는 "직관적 물리학 체계"를 타고 난다. 연구에 따르면, 신생아도 자신에게 다가오는 물체가 충돌 궤적을 따르느냐 아니냐에 따라 상이한 반응을 보인다.

우리는 '던져진 물체와 '낙하하는' 물체를 직관적으로 구분한다. 던져진 물체에 대해서는 물체에 가해진 힘과 중력 두 가지를 고려하지만 낙하하는 물체에 대해서는 중력만 고려되기 때문에 그 물체는 곧게 하강할 것이라 예측하는 것이다.

완전한 3차원 재구성을 하지 않아도 단순한 사진 장면에 대해 우리는 물리적으로 이해할 수 있고, 이것을 직관적 물리학 체계라고 할 수 있다.

최근 INRIA와 Facebook AI 팀의 연구원들은 AI가 이러한 직관적 물리학을 얼마나 이해하는지 진단하는 평가 프레임 워크를 개발했다. (참고: IntPhys: A Framework and Benchmark for Visual Intuitive Physics Reasoning)

만일 AI가 이러한 직관적 물리학 체계를 얻게 된다면 바둑 두는 정도가 아니라 생각된다. 씹~소오름.

Introducing Rebase: a Firebase like backend service based on Node.js, Redis, and HBase

삼성전자 재직시절 (아마도 2 ~ 3년 전) 대외 기고 승인까지 다 받아놓고 게재하지 않았던 글을 이제서야 올려본다. 지금 다시 보니 감회가 새롭네.

Introducing Rebase: a Firebase like backend service based on Node.js, Redis, and HBase 

Guest post written by Edward J. Yoon and Sungwon Han, Senior Software Engineers, Samsung Electronics.

 Event-driven applications that handle user actions, sensor outputs, or messages from other applications have become increasingly popular in recent years, in part as a result of the proliferation of smart devices and the Internet of Things. With this, the real-time databases (like Google's Firebase [1] and RethinkDB [2]) are considered as important technologies for supporting these non-traditional applications and workloads. In this guest post, we introduce Rebase, a Firebase-like backend service that allows you to store and synchronize data in online/offline modes, push notifications and provides analytics (in near future) for mobile platforms. Rebase was first deployed to run on Amazon AWS. However due to performance and cost reasons, we soon migrated it to run on Joyent’s Triton Cloud. We share performance benchmarks for Rebase on Joyent Triton vs. Amazon AWS, which served as our key decision metric.

Rebase 

Recently, we developed a container-based real-time database for Samsung IoT applications, called Rebase. It uses event-driven model to notify changes among clients, stores data as JSON objects in a K/V databases. It also provides easy-to-use RESTful APIs and client libraries that accessible to cross-platforms such as iOS and Android in form of SDKs. With Rebase, developers can focus on core functionality and not have to worry about the infrastructure running the backend services.

Below is a reference architecture for Rebase. It has the following key components:

 Rebase backend container stack 

NGINX, Node.js, and Standalone Redis 

We adopted NginX, Node.js, and Redis as a backend servers. Node.js is a JavaScript runtime environment that processes incoming requests asynchronously in a loop, called event loop. It has an event-driven and non-blocking I/O model, thus it allows handling large throughput of data and building scalable applications. NginX is used as a load balancer, and the standalone Redis is used for message queueing and asynchronous messaging.

Redis and HBase Cluster 

For the persistent storage, we reviewed NoSQLs and K/V stores such as Redis, HBase, and MongoDB. MongoDB isn't suitable for the time-series workloads. Redis is very fast but it has limited scalability and persistency capabilities. HBase is column-oriented K/V store that allows horizontal scalability, and allows to store not only JSON object itself but also parsed columns for fast columnar scan. So, we decided to use the sharded Redis cluster as cache storage, and the HBase as persistent storage.

Programming Interface 

Rebase's client SDK is very similar to the Google's Firebase. It provides basic CRUD operations and stream subscriptions APIs. For example, chatting app synchronization can be written like the following:

var setMessage = function(data) {
    var val = data.val();
    this.displayMessage(data.key, val.name, val.text);
  }.bind(this);

// Loads the last 3 messages and listen for new ones.
this.messages.limitToLast(3).on('child_added', setMessage);

Joyent Triton vs. AWS 

Cost

In the early days of Rebase, we mainly used Amazon EC2 instances and ECS service as a container pools for Rebase backend service. AWS served our needs well, when our users and traffic workloads were small. However as we started scaling out, it quickly turned into a very expensive option for our long term needs.

Server Density

Additionally, AWS runs containers on VMs, which adds unnecessary overhead to the compute nodes. Also if you end up running Kubernetes to manage containers, on VMs running on EC2, the layers of abstraction keep adding flab and reduce efficiency of the compute resources. We tried Joyent and were impressed with it’s containers on bare-metal service. No VMs or abstraction layers to go through.

Performance

Moving to bare metal with Joyent's Triton service [3], we were able to get significant performance improvements as following throughput graph illustrates. For Read operations, we were able to increase throughput by 3~5% while keeping latency under 1 second. For Write operations, we were able to increase throughput by 63% at the same latency of under 1 second. 

Deployment Time

We were able to reduce the deployment time drastically (5 minutes to 1 minute) for new cluster of rebase backend service using Triton’s optimized container provisioning.

State of the Project 

We are still in the early stages and the code isn't meant for production usage yet. The auto-scaling with minimal downtime is challenging. An elastic solution that allows auto scaling up and down or non-stop migrating service is our next goal. Container Pilot and the auto pilot pattern look like some of the right tools to try.

We also plan to open source this project once we've made a few more refinements to it, so that we could tailor it and contribute back to the wider community. We will also be looking to add contributors, so keep a lookout on here for updates! 

References

1. "Google Firebase". https://firebase.google.com/
2. "RethinkDB". http://www.rethinkdb.com/
3. "Joyent Triton". https://www.joyent.com/triton