GAN으로 도트찍기 (2)

이전 글 : http://wonjaekim.com/archives/181

이번 글에서는 658번째 이터레이션에서 훈련이 끝난 InfoGAN Generator를 가지고 2개의 continuous feature(code)와 1개의 discrete feature(code)에 대해서 탐색을 해보겠다.

우선 연속적 피쳐의 영향을 알아보기 위해서 discrete feature를 고정한 채 2차원으로 두개의 feature를 도시하였다.

np.linspace로 각각 -100부터 100까지 16개의 값을 생성하였다. 즉 왼쪽 위가 (-100, -100), 오른쪽 아래가 (100, 100)이다. 훈련 데이터로 사용한 도트들은 얼굴과 머리카락 외에도 다양한 악세서리들을 착용하고 있는데, 이러한 산발적 특징들과 광원을 뭉뚱그려서 학습한 걸로 보인다.

(산발적 특징을 가진 도트들)

다음으로 이산적 피쳐의 영향을 알아보기 위해서 연속적 피처를 (0, 0)으로 고정한 채 64개의 이미지를 생성하였다.

오버피팅으로 인해 다른 것들도 꽤 있지만 대부분 훈련 데이터에 있는 어떤 도트와 거의 일치한다. 이산적 피처는 가장 많이 떨어져있는 64개의 캐릭터 스타일을 학습하였음을 알 수 있다. 노이즈가 많이 있는 생성 이미지들은 위의 연속적 피처의 조정을 통해 노이즈를 통제할 수 있다.

InfoGAN의 discrete feature들은 one-hot vector의 형태로 Generator에 던져지게 된다. 그렇다면 당연히 각각의 vector를 합쳐서 two-hot 또는 n-hot vector의 형태로 만들어 각 스타일을 인터폴레이트 할 수 있다. 위의 이미지는 각자의 one-hot vector와 자신의 오른쪽에 있는 다음 스타일의 one-hot vector를 합쳐서 만든 two-hot vector를 통해 생성된 이미지이다.

(연속된 3개의 코드를 합친 이미지)

(랜덤한 10개의 코드를 합친 이미지)

 

GAN으로 도트찍기 (1)

오늘 오랜만에 크루세이더 퀘스트라는 게임을 하다가 크퀘의 얼굴 도트 이미지가 GAN의 인풋 데이터에 아주 알맞다는 생각이 문득 들어서(크기가 66x66x3이다) 직접 해보기로 했다.

사용한 훈련 데이터는 디시인사이드 크루세이더 퀘스트 갤러리의 드라이브에 있는 652장의 얼굴 도트 이미지를 사용했다.

GAN으로는 해석력이 뛰어난 InfoGAN을 사용했으며, continuous feature 2개, discrete feature 1개(category 64개)를 사용했다. 미니배치 사이즈는 49개를 사용했다.

한시간 정도 훈련 후 600번째 iteration부터 overfitting이 일어나서 훈련 데이터에 있는 얼굴을 그대로 생성하기 시작했기에, 658번째를 마지막으로 훈련을 종료했다.

 

ChartKlas (2)

제목 없음

Demo

(1)편의 분류 모델에 4가지 차트 타입(map, scatter plot, pareto chart, venn diagram)을 추가했다. 정확도는 959개(각 차트 타입당 대략 100개)의 validation set에 대해서 91%이고, 아직 트레이닝이 끝나지 않았으므로 더 올라갈 수도 있다. 현재 95.2%의 정확도를 가지고 있다.

또한, 분류에 대한 restful API를 만들었다. http://wonjaekim.com:30000/classify 로 multipart-encoded file을 http post request로 보내면 json 형식으로 response를 준다.

<예제 python code>

import requests

url = 'http://wonjaekim.com:30000/classify'
files = {'file': open('area_chart/areaprofita.gif', 'rb')}
r = requests.post(url, files=files)
print r.text

<response 형식>

{
    "filename": "areaprofita.gif", 
    "result": [
        [
            "area chart", 
            99.3242
        ], 
        [
            "scatter plot", 
            0.2768
        ], 
        [
            "pie chart", 
            0.1326
        ], 
        [
            "bar chart", 
            0.0886
        ], 
        [
            "map", 
            0.0661
        ]
    ]
}

Beer Galaxy

beer-gal

Demo, Github

Beeradvocate에서 수집한 데이터로 맥주의 은하수를 그려보았다.

전처리 과정

1. doc2vec 알고리즘을 사용하여 117705개의 맥주 각각에 달린 리뷰들(1개의 리뷰가 달린 맥주부터 많게는 3701개의 리뷰가 달린 Dogfish Head Brewery의 90 Minute IPA까지 다양한 크기의 리뷰들이 있었다.)을 사용하여 해당 맥주를 300차원의 vector로 나타냈다.

2. 각각의 맥주 벡터를 t-SNE를 사용하여 2차원으로 folding(sparsity는 0.001225, iteration 1000번에 최종 에러는 6.149086)하였다.  리뷰 텍스트 이외의 정보를 이용한(예컨데 어느 나라 맥주인지 같은) 휴리스틱은 일절 사용하지 않았다.

시각화 요소

1. 각 원의 위치(x, y 좌표)는  2차원 평면에서 각 맥주의 리뷰의 평균적인 의미를 나타낸다. 두 맥주가 가깝다면, 두 맥주의 리뷰가 의미상으로 비슷하다는 뜻이다. 상대적인 값으로, 원들간의 거리에만 의미가 있지 절대적인 좌표에 의미는 없다.

2. 각 원의 색은 그 맥주의 스타일을 의미한다. Beeradvocate가 정의하는 104가지나 되는 맥주 스타일을 color coding 할 수는 없었으므로 가장 개체수가 많은 스타일 상위 20개를 추렸다. 이 20개의 스타일에 속하지 않는 맥주는 검은색으로 표시된다.

3. 각 원의 크기는 그 맥주의 리뷰 개수를 의미한다. 또한 크기가 클 수록 원은 투명해진다. 둘 다 선형 함수로 매핑되어있다.

4. 12만개의 노드를 d3로 그리면 느리기 때문에 리뷰 개수가 20개 이상인 12916개의 맥주에 대해서만 원을 그렸다. 추후에 WebGL을 공부해서 다시 그려볼 예정이다.

 

ChartKlas

chartklas

 

Demo

CNN(Convolutional Neural Network)을 사용해서 차트 분류 모델을 만들었다. 이미지를 업로드하면 Bar, Line, Pie, Area, Radar Chart와 Table. 6개의 차트 타입 중 어느 타입에 속하는지 분류해준다.

사용한 네트워크는 2014 이미지넷 우승에 빛나는 GoogLeNet

슬프게도 GPU가 달려있는 서버가 수중에 없는 관계로 60 epoch의 트레이닝을 무려 24시간동안 진행했다. 각 클래스별로 200개의 이미지, 총 1200개의 이미지에 대해서 75% training set, 25% validation set으로 나눠서 트레이닝을 진행했고. validation set에 대한 accuracy는 94.697%로 측정되었다. 클래스 수가 더 적긴 하지만 기존의 차트 타입 분류를 시도한 ReVision의 10-class 분류 정확도인 80%보다 꽤나 높게 나왔다.

Gtx Titan X 정도의 그래픽카드가 장착된 서버를 구할 수 있다면 다시 트레이닝을 시켜보고 싶지만, 현재로서는 위 결과에 만족.

Word2Vec (2)

하지만, 시간이 지남에 따라 세상은 사람조차 스스로 어떻게 하는지 모르는 영역을 요구하기 시작했다.

저번 글에서 언급한대로 나무위키의 데이터베이스를 사용하여 Word2Vec 모델을 세워보았다. 나무위키 말고 다른 말뭉치(Corpus)를 사용하고 싶었으나, 한국어로 된 마땅한 말뭉치가 없어서(세종 코퍼스는 Raw Text가 아닌 XML로 묶여있고, 코퍼스가 파편화 되어있으며, 어휘량도 많지 않아보여서 패스했다.) 결국 나무위키 데이터베이스를 사용하였다.

모델의 아키텍쳐로는 Gensim이 제공하는 cbow와 skipgram중 skipgram을 사용하였다. Feature Vector의 크기는 300이 넘어가면 정확도의 변화량이 미미하다고 해서 300으로 설정하였다. Vocabulary로는 Gensim의 models.phrases로 token들을 한번 묶어서 bigram vocabulary를 사용하였다.


2015-07-27 17:40:12,095 : INFO : training model with 8 workers on 782573 vocabulary and 300 features, using 'skipgram'=1 'hierarchical softmax'=1 'subsample'=0 and 'negative sampling'=0
2015-07-27 17:40:18,615 : INFO : PROGRESS: at 0.03% words, alpha 0.02500, 17977 words/s
...
2015-07-27 20:05:44,042 : INFO : PROGRESS: at 93.31% words, alpha 0.00171, 40912 words/s
2015-07-27 20:05:44,046 : INFO : training on 357238956 words took 8732.0s, 40912 words/s

↑ 로그파일 일부

트레이닝하는데 약 2시간 20분이 소요되었고,  bigram vocabulary를 만드는데는 약 1시간 40분이 소요되었다. (총 4시간)

데모는 링크에서 확인할 수 있다.

몇몇 쿼리들에 대한 저번 글에서 인용한 나무위키 + 한국어 위키백과 기반 모델과의 비교표를 작성하면서 마친다.

 데모http://w.elnn.kr/
버락_오바마-미국+러시아블라디미르/Noun_푸틴/Noun-
버락_오바마-미국+스타워즈아나킨/Noun_스카이워커/Noun-
아카라카-연세대학교+고려대학교입실렌티/Noun입실렌티/Noun
아이폰-휴대폰+노트북아이패드/Noun아이패드/Noun
컴퓨터공학-자연과학+인문학법학/Noun게임학/Noun
플레이스테이션-소니+마이크로소프트엑스박스/Noun_360/NumberMSX/Alpha
한국-서울+파리프랑스/Noun프랑스/Noun
컴퓨터-기계+인간운영체제/Noun일반인/Noun
게임+공부프로그래밍/Noun덕질/Noun
박보영-배우+가수애프터스쿨/Noun허각/Noun
밥+했는지끓였/Verb저녁밥/Noun
사랑+이별그리움/Noun추억/Noun
삼성-한화노트북/Noun후지필름/Noun
소녀시대-소녀+아줌마아이유/Noun에이핑크/Noun
수학-증명경영학/Noun이산수학/Noun
스파게티-소시지+김치칼국수/Noun비빔국수/Noun
아버지-남자+여자어머니/Noun어머니/Noun
아이유-노래+연기송중기/Noun송중기/Noun
안드로이드-자유iOS/Alpha아이폰/Noun
우주-빛태양계/Noun_밖/NounNASA/Alpha
인간-직업짐승/Noun볼뉴르크/Noun
최현석_셰프-허세+셰프이연/Noun_복/Noun-
패스트푸드-체인점영국/Noun_요리/Noun철물/Noun

밥+했는지의 경우 는지/Eomi가 붙는 밥에 관련된 용언(끓였/Verb, 볶았/Verb, 구웠/Verb)들이 제시되었다.

(버락_오바마-미국)의 feature vector가 [지도자 벡터]를 잘 표현하는듯 하다. [지도자 벡터] + 국가를 하면 해당 국가의 지도자(일본=>아베 신조, 한국=>이명박, 중국=>시진핑)가 높은 정확도로 등장했다.

삼성-한화의 경우 나무위키에 야구 관련 document가 많아서 삼성에서 [야구팀 벡터]를 제거한 결과가 나온듯 하다.

컴퓨터-기계+인간의 경우 운영체제가 인간이 결정하는 여러 Policy들에 의해서 만들어진것을 감안했을때 만족스러운 대답이었다.

Word2Vec

word2vec은 Efficient Estimation of Word Representations in Vector Space에서 제안된 알고리즘을 구현한 구현체다.

Corpus를 Recurrent Neural Network(RNN)를 통해 train해 각 type의 feature vector를 뽑아낸다. 즉, type의 문맥적 특성을 정량화해서 연산이 가능하게 만든 것이다.

지금 주로 사용하는 Conoha VPS로는 내가 들고있는 corpus를 train하는데 Computing Power가 부족해서 동아리 서버에 환경을 마련한 뒤 트레인 해 볼 생각이다

환경은 마련했고, 조촐한 Demo 사이트를 열어놓았다.

현재는 나무위키 모델이 올라가있다. 다음 글 참조

구글이 pre-trained model을 제공하는지라(python gensim이 memory-friendly하다고 해도 3GB의 모델을 1GB램에 올릴 수는 없는 듯 하다.) 로컬 데스크탑에서 gensim의 api를 테스트해 볼 수 있었다.

best-good+sad = saddest : 0.6223942637443542


더 읽을거리

Google Deep Dream

Dreaming HCIL

dream_hcil_original

dream_hcil_0045

 

GoogLeNet 모델을 이용하여 HCIL 로고를 주제로 구글의 Deep Dream을 꿔봤다.

네트워크 종단점은 inception_4c/output, 옥타브는 4번 * 1.4배, 각 이터레이션은 10번이다.

이미지는 각각 원본, 45번째 프레임

1번째 프레임부터 45번째 프레임까지의 gif는 아래에서 확인할 수 있다.

dream_hcil_no_zooming_resize

 

CHI 2015 Lab Review

Papers: Task Interruption & Resumption

What Makes Interruptions Disruptive? A Process-Model Account of the Effects of the Problem State Bottleneck on Task Interruption and Resumption

기존의 인터럽션 렉을 체크하는 세가지 팩터: 인터럽션 지속(Interruption duration), 인터럽팅-테스크 복잡도(Interrupting-task complexity), 인터럽션을 당한 때(Moment of interruption)는 여러 연구에서 지속적으로 관찰되어 왔으나, 이 펙터들을 하나로 묶을 모델은 아직 제시되지 않았다. 따라서 이 논문에서는 Problem States(이하 PS)라는 개념을 빌어서 Memory for Problem States(이하 MPS)라는 모델을 제시한다.

이 모델은 기존의 알트먼(Altmann)과 트래프턴(Trafton)이 제안한 Memory for Goals(이하 MG) 이론에 바탕을 두고, 그 이론의 Goal을 PS로 대체한 것이다. MG 이론에서는 모든 task에 goal이 존재하여, 인터럽트 당했을 때 goal이 procedural memory(이하 PM)에서 declarative memory(이하 DM)로 goal이 이동하기 때문에 DM에서 goal의 activation level(다시 PM으로 불러오기 위해서 필요한 에너지 수준)이 감소해, resumption lag이 발생한다고 말한다. 이 이론은 Interruption duration과 moment-of-interruption의 resumption lag 상관관계를 설명할 수는 있지만 Interrupting-task complexity와 resumption lag의 상관관계를 설명할 수는 없다.

이를 수정한 MPS 모델에서는 일부 테스크에만 PS가 존재하고, 또 테스크 별로 PS가 memory에서 차지하는 용량이 달라서 PM의 PS 용량이 다 차기 전까지는 인터럽션이 발생해도 DM으로 PS가 넘어가지 않아서 activation level의 감소가 적용되지 않아 resumption lag이 발생하지 않는다고 말한다. 이 모델에서는 MG이론이 설명하지 못한 Interrupting-task complexity에 따른 resumption lag의 변화를 PS의 용량 차이로 설명할 수가 있다.

The Effects of Chronic Multitasking on Analytical Writing

이 논문은 만성적인 멀티테스킹 성향(Chronic Multitasking)이 분석적 글쓰기(Analytical Writing)에 어떤 영향을 미치는지에 대한 논문이다. 실험 대상을 Ophir의 Media Multitasking Index(MMI)에 따라서 Heavy Media Multitasker(HMM)과 Light Media Multitasker(LMM)으로 분류했으며, 두 집단이 어떤 다른 경향을 띄는지를 알아보고자 실험을 수행했다. 결과는 HMM은 distractor의 영향을 많이 받아서 distractor가 현재 쓰고있는 글과 관련이 높다면 글쓰기의 퀄리티가 올라갔고, 반대로 관련이 없다면 퀄리티가 낮아지는 경향을 띄었다. 반면 LMM은 distractor의 영향을 받지 않아서 distractor의 관련성과 상관없이 일관된 퀄리티를 보여주었다.