Wednesday, December 7, 2016

Stochastic Gradient Descent 자동 학습속도 조절 알고리즘 정리


이미지와 내용은 http://www.deeplearningbook.org을 참고했습니다. 저도 별로 이해하고있는게 없어서 간단히 요약만 합니다.


  • AdaGrad를 보면, 그라디언트를 1/sqrt(r)에 비례하도록 크기를 조절합니다(노랑색). 그리고 r은 그라디언트^2를 누적해서 더한 값입니다(초록색). 결과적으로 학습이 진행되면서 학습속도(learning rate)가 지속적으로 감소합니다. 
  • 이 방법은 Convex 최적화 관점에서 보면 - 즉 풀고자하는 문제가 컨벡스라면 - 별 문제 없습니다. 하지만 딥러닝 모델의 경우에 어느정도 학습을 진행하다보면 학습 속도가 너무작아진다는 문제가 실험적으로 밝혀졌습니다.
    • 아마도 이는 saddle point때문이 아닌가 생각합니다. 

  • RMSProp은 AdaGrad와 비슷하지만 (노랑색) 차이가 있습니다 (빨강색). ρ (rho)는 보통 0.9를 사용하는데, 쉽게 이야기하면 ρ만큼만 기억하고, (1-ρ)만큼만 업데이트를 합니다. 혹은 이 과정이 계속되면 아주 오래전의 그라디언트는 지속적으로 ρ가 곱해지면서 값이 작아지게 되고, 최근에 추가된 그라디언트가 상대적으로 큰 영향력을 발휘하게됩니다. 결과적으로 학습 속도의 감쇠가 AdaGrad보다 약하게 일어납니다.
  • RMSProp은 힌튼의 Coursera 강의에서 처음 소개되었고 한동안 (사실 지금도) 가장 널리 쓰인 방법입니다. 사람들이 강의노트를 인용하곤했죠.



  • 이 내용은 RMSProp에 (빨강색) Nesterv momentum을 추가한겁니다 (파랑색). Momentum = 관성. 즉 부화뇌동;하지 않고 상대적으로 차분하게 업데이트한다고 생각을 하시면 됩니다.


  • Adam은 최근에 가장 널리 사용되는 방법입니다. 보다시피 1st moment (s), 2nd moment (r)을 구하는 과정에서 관성(momentum)을 적용합니다. 
  • correct bias는 제가 잘 이해하지 못했습니다.

Monday, December 5, 2016

음성/음악신호+머신러닝 초심자를 위한 가이드 [3편]

서문

가이드 3편입니다. 기존 가이드는 1편, 2편을 참고하세요.
모 대학원의 모 분께서 음악 신호와 머신러닝에 대한 질문을 주셨는데 중요한 점을 콕콕콕콕콕콕 집어서 물어보셔서 블로그에 글을 쓰기로 했습니다.

질문-답변 1


음악 인식쪽이 생소하다 보니 일단 먼저 music genre classificaiton(음악,음성신호 입력 --> [전처리] --> [특징값 추출] --> [분류기] --> 결과) 를 주제로 toy porject를 해보려고 합니다. 툴은 librosa를 쓸 예정입니다.

궁금한 점이 몇가지 있는데

1) 혹시 mp3파일이 주어졌을때 전처리를 하고 특징값 추출을 하는 하는 소스코드가 있으시면 공유 가능한가요?

- 상황에 따라 다르지만 대체로 추출과정은 https://github.com/fchollet/keras/blob/master/keras/applications/audio_conv_utils.py#L27 을 참고하시면 됩니다.
여기에서는 mel-spectrogram만 뽑는데, 여기에 다른 추출기를 추가하시면 되겠습니다.

2) 제 계획은 librosa가 제공하는 여러개의 특징을 최대한 많이 사용하고 후에 PCA등으로 후처리를 하려고 하는데, librosa가 제공하는 특징 (http://librosa.github.io/librosa/feature.html)중에 음악 분류에 적합한 특징에는 어떤 것이 있을까요?

- MFCC는 필수고, 그 외에 spectral-시리즈와 zero-crossing + tempo (http://librosa.github.io/librosa/generated/librosa.beat.estimate_tempo.html) 등을 쓰시면 됩니다.
그리고 특징값 추출 전에 http://librosa.github.io/librosa/generated/librosa.decompose.hpss.html 을 사용하셔서 두 채널을 따로 하시면 도움이 될겁니다.

질문-답변 2


지난번에 말씀하신데로 간단한 특징 추출 과정을 수행해보고 있는데, 몇가지 궁금한점이 있습니다. 

1) https://github.com/fchollet/keras/blob/master/keras/applications/audio_conv_utils.py#L27 을 참고하라고 하셔서 소스코드를 살펴봤습니다. 보통 음악 파일들은 3분이상이며, 제각기 길이가 다른데 소스코드에서 음악 파일의 가운데 DURA = 29.12 초 구간만을 프로세스 하더라고요. 이렇게 하는 이유는 각 음악 파일 별로 길이(재생 시간)가 다르지만 같은 크기(차원)의 특징 벡터를 얻기 위함인가요? 그리고 가운데 29초만으로도 충분한 정보가 있다고 가정하고 처리하는건가요?  끝으로 이렇게 가운데 구간을 trim 하는 기법이 일반적인 기법인가요?

- 이유: 맞습니다. 시간에 따른 정보를 어떻게 합치느냐에 따라 다르겠지만 링크의 컨브넷은 입력 신호의 길이를 29.12초로 제한하고 있습니다. 이보다 짧은 경우에는 나머지를 0으로 채워서 입력으로 넣어도 무방하지만 긴 경우에는 적당한 구간을 잘라줘야합니다. 그리고 말씀하신대로 가운데 29초가 충분한 정보가 있다고 가정하는 것입니다. 물론 상황에따라 다를테고, 제가 논문에서 사용한 음원은 기본적으로 30-60초의 '미리듣기'용 음원입니다. 이런 경우엔 사실 어디를 사용하더라도 무방하겠죠.
가운데를 사용하는건 아무래도 가장 단순하고 그러면서도 적당히 작동하는 방법입니다. 그 외에도 대중 가요의 경우 60-120초 사이에 하이라이트 (혹은 chorus, 혹은 싸비..)가 있다고 가정할수도 있구요.  이 외에도 가장 중요한 구간을 뽑아주는 방법를 여러가지로 생각해볼 수 있겠죠. 간단한 방법으로는 frame별로 energy를 계산해서 평균 에너지가 제일 높은 30초를 뽑을수 있겠죠. 보다 복잡한 방법으로는 음악 내 다양한 구간을 잘라주는 알고리즘을  사용한 뒤에 어디가 하이라이트인지 뽑을수도 있구요. 이는 원하시는 성능과 연산량에 따라 결정하시면 됩니다.

2)  음성/음악신호+머신러닝 초심자를 위한 가이드 [2편]을 보면,  프레임 마다 특징값을 뽑는 것이 아니라 오디오 신호 전체를 표현할 특징값을 찾기 위해 평균 및 분산 MAX를 뽑는다고 하는데 혹시 관련 논문 아시면 제목 알려주 실 수 있나요?
그리고 1)질문과 연관지었을 때 제가 음악 처리를 할때, 음악 파일 1개의 전체 구간에 대해서 평균 분산을 구하게 되면 아무래도  정보가 많이 뭉개질것 같더라고요. 그래서 1)번의 코드처럼 아예 처음부터 가운데 구간이 충분히 의미 있다고 가정하고 29.12초의 짧은 구간만을 평균, 분산 등을 이용해서 오디오 레벨 특징을 뽑으려고 하는데  reasonable한 방법인가요?

http://dspace.library.uvic.ca:8080/bitstream/handle/1828/1344/tsap02gtzan.pdf?sequence=1 를 보시면 평균과 분산 등을 사용했습니다. 그 외에도 frame-based feature를 clustering하고 이를 기반으로 quantized count를 사용하는 방법(http://dawenl.github.io/publications/LiangZE15-ccm.pdf)도 있습니다.
그리고 가운데 구간만 사용하는것이 곡 전체를 사용하는 것보다 나을것이라는데 동의합니다.  

3) 특징 추출 시 HPSS를 통해 2채널로 분리한 뒤  특징을 추출하라고 하던데, 예를들면 제가  LIBROSA에서 제공하는 특징들 중   A,B,C 를 추출하려고 한다면, 하나의 음원으로부터 각 채널별로  A,B,C를 추출해서 총 6개(3*2)의 특징을 구하라는 말씀이신가요? 예제들을 잘 보면 어떤 특징은 H채널에서 뽑고, 어떤 특징은 P채널에서 뽑더라고요. (https://github.com/librosa/librosa/blob/master/examples/LibROSA%20demo.ipynb

말씀하신대로 Harmonic + Percussive에서 모든 특징을 다 뽑아도 큰 문제는 없겠지만 가장 relevant한 정보만 뽑는다고 한다면, 각 트랙에 맞춰서 특징값을 골라주는게 좋겠네요. 하모니나 pitch에 관련된 특징값(chroma-어쩌구, ) 은 harmonic 트랙에서 뽑고, rhythm/onset/tempo 등은 percussive 트랙을 이용하시구요. spectral_어쩌구; (spectral centroid, ..)가 좀 애매한데, 얘네들은 분리하기 전 채널을 이용해 추출하는 것이 좋아보입니다.

4) 종종 특징들을 뽑고 아래와 같이  LOG화 시키던데 이렇게 하는것이 일반적인 방법이며, 인식 향상에 도움이 되나요? 
# Convert to log scale (dB). We'll use the peak power as reference.
log_S = librosa.logamplitude(S, ref_power=np.max)
네. 우선 STFT/CQT/Melgram등의 time-frequency representation은 log()를 씌워 데시벨 스케일로 바꿔주는것이 좋습니다. (그 외에도 일반적인 머신러닝에서 하듯 zero-mean unit-variance로 standardisation을 해주는것이 좋을테구요.) 이런 전처리는 인식 향상에 도움이 됩니다. 
5) 음악 인식 분야에서도  CNN을 이용한 기법들이 도입되고 있다고 들었는데, 보통  CNN의  input 은 주로 어떻게 처리해서 주나요? 그리고 혹시 관련 논문을 알려주실 수 있나요?
여러가지 경우가 있습니다.
Pitch와 관련된 정보 추출: CQT를 사용하고 대역폭을 음의 fundamental frequency가 분포할 수 있는 영역으로 제한한다. (대략 30Hz - 3kHz정도가 되겠죠)
리듬관련: STFT나 Mel-spectrogram을 사용한다.  
풀고자 하는 문제가 사람의 musical perception에 관련된 경우 (예: 감정 인식): Mel-spectrogram을 우선적으로 고려하고 STFT도 가능하면 테스트해본다. 주파수 대역은 대략 4kHz - 11K를 고려한다.
잘 모름: 8kHz나 16kHz로 샘플링하고 STFT (n_fft=1024 또는 512)와 Mel-spectrogram (128 bins)를 써본다.
음악이 아니라 음성이 입력이다: Mel-spectrogram을 최우선적으로 고려한다.
음악, 음성이 아니라 '소리'에 관련된 작업이다: STFT를 사용하고 Mel-spectrogram을 고려해본다. 
그리고 이와 관련된 논문은 아직 없습니다. 제가 대략 2-4개월내로 하나 작성하려고 계획중입니다. 

6) 제가 앞으로 해보려는 것은 일단  음원이 주어지면 고정 길이로 음원 구간을  trim  시키고, 이 구간에 대해 여러개의 특징벡터를 추출하려고 해요. 이렇게 하면, 음원에 대해서 (프레임 개수)  X (프레임당 특징 벡터들의 차원의 합)의 행렬이 만들어 질텐데, 음악 장르를 구분하는  task라고 가정하고  CNN 의 input으로서 이 이차원 행렬 그대로 주는게 좋을까요 아니면 2)에서 언급한것처럼 이 2차원 행렬의 프레임별  평균, 분산등을 구해서  1차원 벡터로 차원을 축소 한 뒤 입력으로 주는 것이 좋을까요?

데이터 개수가 충분히 많다면 2차원 데이터를 쓰시고, 그렇지 않으면 1차원 벡터로 입력 데이터의 크기를 줄여야겠죠. 장단점이 있어서 해보기전엔 정하기 어려워보입니다. 



Wednesday, November 2, 2016

판도라 - Thumbprint radio 간단 요약

원문은 https://engineering.pandora.com/the-magic-behind-thumbprint-radio-2c5b8103b71#.ekp74phzd 입니다.



  • 2014년 11월, (?) analyst, product maanager, security engineering manager, data scientist + 6 engineers 총 10명의 팀이 3일간 진행된 2014 하반기 사내 해커톤에서 My Thumb Mix를 만듬. 청취자가 '좋아요'를 누른 곡만 모아놓은 라디오를 제공하자는 아이디어
  • 회사 내부에서 좋은 반응을 받음. Product management, computational programming, data science 3개 팀에서 모두 좋은 반응을 얻어서 2015년 1월에 작은 팀 결성

아이디어

  • 판도라는 각 트랙마다 450가지 음악적 특성을 요약한 데이터를 보유. 이 데이터를 이용해 곡을 추천함. 
  • 사용자의 취향은 각 라디오 스테이션에서 사용자가 누른 좋아요/싫어요를 바탕으로 추출됨
  • Thumbprint radio는 이러한 기존 서비스보다 더욱 개인화된 라디오. (라고 주장함.)

연구 및 초기모델 개발

우선, 처음에 팀에서는 아래와 같은 내용을 연구함.
  • 여러가지 '좋아요' 곡을 어떻게 연결할 것인가
  • 어떤 곡에서 출발할 것인가
  • 새로운 음악을 어떻게 추가해넣을 것인지
총 8가지 초기모델을 만들고 이를 A/B 테스트 한 결과,
  • 완전 무작위로 섞는것은 안됨.
  • 비슷한 음악을 너무 오래 틀어주면 안됨
  • 비교적 최신곡, 흔한 곡으로 출발할 것
  • 약간의 무작위성과 새로운 곡을 섞어서 듣는 재미를 유지할 것
가 중요하다는걸 깨달음. 이 교훈은 판도라의 기본 라디오 기능에도 적용됨.

최종적으로는 아래의 두 가지 방법을 고려함.
  • 트랙간 무작위 재생 (track-level random walks): 이는 '좋아요'가 뜬 각종 트랙을 전부 랜덤으로 재생하는 것. 이 방법의 단점은 - 
    • 곡 선정 방식을 구체적으로 튜닝하기 어려우며,
    • 특정 곡만 계속 반복해서 재생하게 될 수가 있음.
  • 스테이션 단위로 무작위 재생:
    • 장점
      • 각 곡의 유형(장르 등)을 명확하게 설명할 수 있음
    • 단점
      • 각 클러스터(=스테이션 내의 트랙들)를 이용자가 얼마나 좋아하는지 알기 어렵다는 것 (즉, 스테이션 내의 트랙 중에 좋아요를 누른 것이 있다고 해서 그 스테이션에 있는 다른 트랙까지 좋아하는것 아님)
      • 트랙 간에 전환이 갑작스러울 수 있음
(역자 주: 이 부분에서 결과적으로 어떻게 문제를 해결했는진 생략되어있군요.)

최종적으로는, "음악적으로 말이 되는 무작위 재생"을 목표로 삼음.

제품 출시

최대 1억명의 이용자에게 이 서비스를 제공할 수 있도록 열심히 함.
(역자 주: 대폭 생략합니다.)

결과

상위 500개 스테이션보다 높은 유저 몰입(listening session engagement)을 보여줌
등등 자랑.







Tuesday, September 6, 2016

논문 요약 - Deep Neural Networks for YouTube Recommendations

원문은 구글 리서치 블로그 (논문 pdf)입니다. 조만간 보스턴에서 열리는 2016 RecSys 논문인데 최근에 구글 리서치 홈페이지에 올라오고 나서 학계에서 주목을 많이 받았습니다.

1. 서문


  • 세 가지 중요한 잣대: Scale, Freshness, Noise
    • Scale: 데이터가 매우 많으므로 scalability가 중요하다.
    • Freshness: 새로운 비디오가 추가되었을때 추천에 바로바로 반영되어야 한다.
    • Noise: 데이터의 sparsity, ground truth의 부재, 거의 항상 implicit feedback만 갖고있다, meta data가 엉망인 점 등을 고려해야함.
  • 구현
    • Tensorflow를 사용함
    • 전체 시스템은 10억개정도의 파라미터 존재
    • 트레이닝 데이터는 수천억개정도.

2. 시스템 개요

  • 전체 구조는 (파란 블럭)
    • 단계 1: 추천할 후보 비디오를 몇 백개 내외로 뽑아내고
    • 단계 2: 다시 그 중에서 자세하게 순위를 매겨서 추천
  • 이 과정에서 사용자의 이용 내역과 맥락을 감안합니다.
  • 개발 과정은
    • precision/recall/ranking loss등 offline에서 측정 가능한 것들을 일단 측정해서 어느정도 범위를 줄이고
    • watch time, click-through rate은 A/B test를 거친다.
    • A/B test 결과 (실시간 피드백)가 항상 offline 실험 (전체 히스토리를 retrospective하게 보고 평가하는것)과 일치하진 않는다.


3. 단계 1: Candidate generation


  • 기존에는 Ranking loss를 이용한 Matrix factorisation [23]을 사용
  • MF를 대체하기 위해 간단한 뉴럴넷을 사용한적 있었으며 이때는 사용자가 과거에 본 비디오 내역만 이용했었다.

3.1 Recommendation as classification

  • 문제 정의
    • 추천: 엄청나게 클래스가 많은 multiclass 분류 문제로 재정의 (Extreme multiclass classification)
    • user, context가 주어지면 특정 시간에 이 비디오를 볼 확률을 구함. 즉, 
      • v_j : context embedding
      • u: user embedding
      • 이 학습 과정에서 사용자가 누른 '좋아요' 같은 정보는 사용하지 않고 비디오를 끝까지 봤는지/아닌지만 사용.
    • Extreme multiclass classification 효율적으로 어떻게 구현?
      • Offline에서는 (즉, 미리 계산)
        • negative class를 샘플링 (i.e., skip-gram negative sampling)
        • loss function으로는 각 class (비디오)마다 (binary) cross-entropy를 사용
        • 대략 수천개정도의 negative sample 이용
        • hierarchical softmax는 (이런저런 이유로) 사용하지 않음.
      • at serving time (추천을 실시간으로 할때는)
        • 드디어 사용자에게 추천을 N개의 비디오를 고르는 시간
        • 기존에는 [24]처럼 hashing을 사용했고 이번에도 마찬가지.
        • 최종적으로는 (위의 식처럼) dot-product space에서 가장 가까운 아이템 (nearest neighbour)를 찾는 과정.
        • A/B test 결과 nearest neighbour 알고리즘간에 추천성능 차이는 없음

3.2 구조

      • 사용자가 본 영상 내역을 embedding vector (좌측하단 파란색)로 바꿈
        • 여러 영상의 embedding vectors를 평균내서 사용. (sum, component-wise max 등 사용해봤으나 평균이 제일 좋음)
        • Fully-connected layer + ReLU 사용

3.3 Heterogeneous signals

    • 개요
      • 검색 내역 (그림의 하단 초록색)도 영상처럼 embedding을 구함
      • 그 외에 사용자의 지역정보/기기 등 간단한 정보도 embedding을 구하고 이 값을 concatenate함.
        • 성별, 나이 등 값은 [0, 1]로 바꿔서 넣음.
    • "비디오의 나이" (example age)
      • 새로 나온 비디오를 잘 보여주는것이 중요하다.
      • 사용자가 얼마나 새로운 비디오를 선호하는지도 중요
      • 트레이닝 데이터 특성상 머신러닝을 단순하게 적용하면 오래된 아이템들이 더 추천을 많이 받게 된다.
      • 이를 해결하기위해 아이템(비디오)의 "나이"를 입력으로 넣어준다.
      • 위의 그래프를 보면 아이템의 나이를 넣어주면 (빨강색) 업로드 직후에 사람들이 많이 감상하는 경향을 예측하고 있다. 

3.4 Label and context selection

  • 추천은 전형적인 "Surrogate problem"이다. -- 다른 문제를 통해 추천 문제를 해결할 수 있다. 
    • 예를 들어 영화 평점 예측 알고리즘은 영화 추천에 사용 가능.
    • 그러면 유튜브에선 어떤 문제를 이용해야하는가? 
  • 학습 데이터: 잘못 만들면 추천엔진이 exploit >> explore 하게 된다. 
    • 유튜브 웹사이트를 통해 본 내역 말고도 온갖 소스를 통해 본 이용 내역을 전부 활용한다. 왜냐하면 유튜브에서 이미 추천 시스템이 있으므로 유튜브 웹사이트에서 감상한 비디오는 이미 추천 시스템의 결과에 치우친 데이터를 만들어내기 때문에. 
    • 데이터에서는 이용자별 영상 감상 횟수를 제한한다. 엄청나게 많이 보는 사람들의 영향을 빼기위해.
    • 또, 추천 결과나 검색 결과를 즉시 활용하지 않는다
      • 검색 키워드는 일부러 순서를 날린 bag-of-tokens을 이용한다. 
      • 안그러면 방금 검색한 내용이 계속 메인 페이지에 떠서 짜증남.
  • 유튜브 영상 감상 패턴: 매우 비대칭적이다.
    • 비대칭적인 co-occurrence (or co-watch)
    • 즉, 영상 감상은 순서가 정해져있음.
    • 에피소드가 1-2-3-4.. 진행되는 경우는 물론이고,
    • 음악의 경우에도 유명한 노래 --> 마이너한 노래로 가는 경향.
    • 이 비대칭을 모델링하려면 offline 실험에서도 "과거"의 자료만 사용해야함 (그림 5-b)
  • 실험결과 - feature and depth
      • Offline에서 MAP 측정
      • baseline: 감상 내역만 이용
      • 파랑색: 감상내역 + 검색
      • 빨강색: 감상내역 + 검색 +  영상의 나이
      • 초록색: 전부 다 이용
    • 실험은 영상 100만개, 검색어 100만개를 256차원의 embedding으로 변환. bag_size는 최근 50개 영상/검색
    • depth 깊어질수록 성능 좋아짐. 

4. 단계 2: 랭킹 

여기에서는 더 많은 feature를 이용해 영상과 이용자의 관계를 구한다.
역시 deep neural network를 이용.

그리고 이 구조는 A/B test를 통해 계속 업데이트됨. 평가 잣대는 추천된 횟수 (=화면에 뜬 횟수) 대비 평균 감상 시간.

4.1 Feature representation

  • 여기에서는 딥러닝을 통해 학습된 feature뿐만 아니라 hand-written feature를 사용. 
    • 대략 수백개정도의 feature 사용.
    • 사용자의 이용패턴 - 특히 여러 종류의 정보가 어떻게 관계를 맺고있는지가 중요. 예를 들어,
      • 이 채널에서 이 이용자가 몇 개나 되는 영상을 봤는지
      • 마지막으로 이 주제의 영상을 본게 언제인지..
    • 또, 왜 이 영상이 추천되었는지 정보도 활용한다.
    • 또또또, 추천했는데 안보는 영상은 조금씩 순위를 깎는다.
  • categorical features
    • Top-N 영상 및 검색어를 embedding한다.
    • 그 외의 것들은 0으로 놓는다.
    • 영상 id, 사용자가 마지막으로 본 영상 id, 이 추천에 사용된 seed 영상 id 등을 전부 사용한다.
      • 얘네들은 평균을 구하거나 하는게 아니라 별도로 network에 들어간다. [왜냐하면 다른 역할을 해야하니까!]
  • continuous features 처리방법
    • 값 x를 [0, 1]에 들어오도록 scaling해주고,
    • x, x**2, sqrt(x) 를 다 넣어준다. 
      • 왜냐면 딥러닝은 입력 데이터의 pre-processing에 매우 민감한데 어떤 값이 가장 좋은지 알기 어려우므로. [이렇게 넣어주면 별도의 layer를 통해 제곱, sqrt()등의 비선형성을 학습하지 않아도 단일 레이어에서 가중치만 잘 주면 됨.]

4.2 Modelling expected watch time

  • 감상시간: 안보면 0으로, 보면 본 시간대로 값을 넣어준다.
  • (새로 정의한) weighted logistic regression을 사용한다. 
    • 감상한 영상을 감상 시간으로 가중치를 주는 것.
  • 실험 결과

    • (당연히) 더 크고 깊은 신경망이 작동을 더 잘함. 실제 상황에서는 서비스의 반응 시간이 느려질 수 있다는점 주의.

5. 결론

  • 요 방법이 Matrix factorisation보다 좋다.
  • 전체 시스템을 디자인하는건 거의 과학이 아니라 예술임.
  • "영상의 나이"가 잘 작동한다.
  • 단계 2의 세부 튜닝은 딥러닝보다는 전통적인 ML에 더 비슷하다.
    • 특히 사용자의 과거 행동 패턴을 잘 설명하는 feature가 중요
  • weighted logistic regression을 쓴것이 click-through rate을 쓴것보다 결과가 좋다.







Tuesday, August 23, 2016

음악 플레이리스트 생성에 대한 조사 번역

From manual to assisted playlist creation: a survey라는 논문을 간단히 정리했습니다.
덤으로 각 섹션별로 점점 요약이 과격해지는 과정을 즐기시길 바랍니다.



1. 서문
음악을 찾는 것은 번거로운 일이다. 스트리밍 업체에서는 플레이리스트라는 수단을 써서 이용자들에게 곡을 추천하기 시작했다. 플레이리스트는 단순히 아티스트나 장르같은 주제로 곡을 모으는것을 넘어서 음악 카탈로그를 탐색하는 수단이 되었다. 
최근 약 10년간 플레이리스트를 자동으로 생성하는 연구가 많이 있었다. 어느 시점부터 완전 자동 생성이 아니라 그 과정에 사람이 개입하는 연구가 많이 나왔다 [23, 53, 78]. 이용자의 피드백이 들어가는것이 중요하고, 또 그 피드백을 이용해 이용자가 좀 더 활발하게 서비스를 이용하도록 하기도 한다. 플레이리스트를 만드는걸 좋아하는 이용자들이 있기 때문이다. 또, 사람이 만들었다는 점이 이용자들에게 더 어필하기도 한다 [6, 9, 59]. 이런 현상은 다분히 감성적인 측면이 있다.  좋은 성공 사례는 8tracks가 있다. 사람들은 인간적인 측면을 좋아한다!
이 논문은 플레이리스트의 자동생성/수동생성/생성을 도와주는 기술 이렇게 3가지를 리뷰한다.

2. 배경
2.1 플레이리스트의 역사
(초략..) 라디오 프로그램은 진행자의 성격이 반영된 플레이리스트를 제공했다. DJ라는 개념이 생기면서 곡을 끊기지 않고 듣는 믹스라는 개념이 생겼다.최근에는 웹기반의 플레이리스트 공유라는 개념이 생겼다. (Spotify, Rdio, 8tracks, 애플뮤직 등).
결과적으로 플레이리스트라는 개념은 계속 바뀌어왔다. 대략 중요한 특징은 i) 공통점이 있는 곡을 모으고 ii) 만족 극대화를 위해 순서를 잘 조절하고 iii) 개인적인 취향이 그 과정에서 개입하고 iv) 곡과 곡 사이의 전환을 부드럽게 하고싶어하는 점이다.

2.2 플레이리스트의 정의
중요한 점: 여러 곡의 집합, 명확한 순서가 있다, 같이 듣도록 선택된다.
믹스테입과의 공통점:
- 믹스테입: 순서가 중요하다, 명확한 주제가 있다, 길이가 정해져있다, 공유를 위해 만들어졌다. 
- 플레이리스트: 구성이 더 자유롭고 길이가 바뀌기도 한다.
저자의 정의: A playlist is an arbitrary sequence of songs meant to be listened to as a group and that fit a certain theme or purpose either for individual reproduction or sharing.

2.3 플레이리스트의 분류
* 창작자와 이용자의 관계에 따라 - 전문 제작가/청취자/아마추어 제작자/플레이리스트 네가지 개념의 관계로 정의
혹은, 제작자와 제작 의도에 따라
* 방송용 라디오 플레이리스트 *개인화된 라디오 플레이리스트 *아마추어 플레이리스트 *클럽 플레이리스트 *앨범 트랙 *컴필레이션 트랙.

2.4 플레이리스트가 갖춰야할 특징
인기도, 신선함, 통일성, 다양성, 음악적 특징, 곡의 전환과 어우러짐

3. 플레이리스트 제작 기술
3.1 수동 제작
3.1.1 스타일
공통적으로는 여러 곡을 고른뒤에 그 곡을 배치하는 방식으로 이루어진다. 

3.1.2 사람들이 플레이리스트를 만드는 방법
*목적, *곡을 고르는 기준, *어떤 특징을 갖춘 플레이리스트를 만들지 결정
[30]에 의하면 플레이리스트를 만드는 이유는 *공부, 등산, 운동 등 활동의 배경음악으로 쓰기 위해 *감정 표현이나 전달을 위해 *파티 등 이벤트에 사용하기 위해.
또, [30]에 의하면 플레이리스트에서 곡의 순서는 대체로 중요하지만 곡을 정렬하는 명확한 기준을 발견하기는 어려움. 매우 거칠게 이야기하면 *특별한 이유가 없다면 같은 아티스트의 곡을 연달아 틀지 않음 *서로 상호 보완하는 곡을 이어서 튼다 *첫곡은 전체 곡중에서도 좋은 곡이어야하지만 제일 좋은 곡은 아님 *마지막곡은 매우 중요. 왜냐하면 다 듣고난 뒤의 인상을 좌우하므로. 
사람들마다 곡을 다르게 받아들이고 표현하지만 공통적으로는 1)곡 자체의 특징과 2)음악을 듣는 상황 이라는 두가지 특징으로 나뉨. 이 경우엔 음악을 듣는것이 제일 중요한 일이 아니라 배경음악으로 쓰임. 상황의 경우에 템포나 장르보다는 감정이 중요하다거나, 또 어떤 모임이냐/곡의 인기도/이용자의 나이가 중요하게 상호작용. 

3.1.3 장단점
수동으로 곡을 만드는건 시간이 많이 든다는 단점이 있다. 또 수많은 카타로그에서 곡을 고르는건 매우 어려운 일. 

3.2 자동 생성
3.2.1 문제 정의
seed가 되는 정보를 받아서 플레이리스트를 만들어주는 것.

3.2.2 생성 기술
[14], [83]의 서베이 참조해서 정리하면 (**주: 범주가 좀 이상하군요)
1) 유사성 기반
2) CF기반
3) rule을 정의하고 이를 이용
4) 통계모델: HMM등
5) 사례 분석: 
5) 
6) 

3.2.3 장단점
자동 생성이라 상세 조절이 어렵고 작동 원리 파악이 힘듬.

3.3 생성을 도와주는 기술
사람들은 플레이리스트 만드는걸 좋아하지만 이게 쉬운일이 아니므로 이걸 도와주는 기술이 나왔다.

3.3.1 상호작용
시각화 등을 이용해 이용자와 상호작용하므로 사람들의 참여가 늘어나고 애정듬뿍

3.3.2 Control
사람들이 플레이리스트 제작 과정을 통제하거나 적어도 통제한다고 느끼는것이 중요.

3.3.3 시스템 투명성
결과적으로 어떤 과정을 통해 플레이리스트가 만들어지는지 이해하게 됨

3.3.4 이용자 개입 (Engagement)
이용자는 특별히 어떤 곡을 찾기보다는 뭐가 있나 둘러보는 경우가 많다

3.3.5 기술
Maps: 곡을 (2D 평면에) 시각화하고는 것
Graphs: 곡과 곡의 관계를 그래프 구조로 정의

3.3.6 장단점
곡 시각화를 통해 플레이리스트 제작하는 것은 자동과 수동의 장점을 합칠 수 있다. 

3.4 정리
생략

4. 분석 및 토의
4.1 수동 플레이리스트 생성
- 제일 간단.
- 여전히 플레이리스트 제작 과정은 연구 대상
- 제작자 자체에 대한 연구도 필요 (그래?)

4.2 자동 생성
- 제작자가 필요없음
- ‘통제’가 전혀 없다는 특징

4.3 Assisted 플레이리스트 생성
역시 앞의 내용 반복

4.4 실험 및 평가
평가:매우 중요하다.
주관 평가로 사용자의 만족도 측정 가능 (당연하지..)
객관평가로 다양성/통일성/신규성/신선함/친숙함/곡 전환 등 평가 가능 [67]
생성 툴의 경우엔 -생성 툴이 얼마나 좋고 편한지 -그 결과로 만든 플레이리스트가 얼마나 좋은지 평가 가능

4.5 세가지 방법 비교


5. 결론
앞에 나온 말 반복. 끝.

제프리 힌튼 - 드롭아웃을 깨닫게 된 3번의 '아하'

2016년 8월 초에 레딧 머신러닝에서 있었던 구글브레인 팀과의 AMA(Ask Me Anything: 무엇이든 물어보세요!)에서 드롭아웃을 발견하는 과정을 누가 질문했습니다. 원문은 여기입니다.

[–]figplucker 23 points  
How was 'Dropout' conceived? Was there an 'aha' moment?
[–]geoffhintonGoogle Brain 67 points  
There were actually three aha moments. One was in about 2004 when Radford Neal suggested to me that the brain might be big because it was learning a large ensemble of models. I thought this would be a very inefficient use of hardware since the same features would need to be invented separately by different models. Then I realized that the "models" could just be the subset of active neurons. This would allow combinatorially many models and might explain why randomness in spiking was helpful. 
Soon after that I went to my bank. The tellers kept changing and I asked one of them why. He said he didn't know but they got moved around a lot. I figured it must be because it would require cooperation between employees to successfully defraud the bank. This made me realize that randomly removing a different subset of neurons on each example would prevent conspiracies and thus reduce overfitting.
I tried this out rather sloppily (I didn't have an adviser) in 2004 and it didn't seem to work any better than keeping the squared weights small so I forgot about it.
Then in 2011, Christos Papadimitriou gave a talk at Toronto in which he said that the whole point of sexual reproduction was to break up complex co-adaptations. He may not have said it quite like that, but that's what I heard. It was clearly the same abstract idea as randomly removing subsets of the neurons. So I went back and tried harder and in collaboration with my grad students we showed that it worked really well.

제프리 힌튼: 드롭아웃은 총 세 번에 걸쳐 깨닫게 되었습니다. 우선 2004년에 레드포드 닐이 저한테 이야기해준 내용입니다. 인간의 뇌의 용량이 이렇게 큰 이유는 어쩌면 뇌 안에 여러 모델이 있고 그 모델을 합치는 (ensemble) 것 때문일지도 모른다는 내용이었죠. 그 당시에는 그 이론이 현실적으로 너무 많은 하드웨어를 필요로 하기 때문에 비효율적이라고 생각했습니다. 그러다가 어느 순간 그 모델이 꼭 큰 모델이 아니라 전체 뉴런의 일부가 될 수도 있겠다는 생각을 했습니다. 그렇게 생각하면 신경 세포가 임의로 반응(spike)하는 것도 설명을 할 수가 있겠다구요.
그러고 얼마 지나지 않아서 은행을 갈 일이 있었습니다. 그런데 은행을 갈때마다 창구 직원이 매번 바뀌더라구요. 직원에게 왜 그런지 물어보니 본인도 잘 모르지만 그런 순환이 자주 일어난다고 대답했습니다. 저는 아마도 은행에서 횡령같은 범죄를 일으키려면 여러 직원의 협동이 필요해서 그것을 막기 위한것이 아닌가하는 생각을 생각을 했습니다. 그리고 같은 논리로 계속 다른 뉴런의 부분집합을 제거하면 뉴런들의 음모 - 즉 과적합(overfitting)을 막을 수 있지 않을까 하는 생각을 했어요. 그래서 2004년에 이걸 대강 구현해봤습니다 (당시에 저를 지도해줄 사람이 없었죠). 당시엔 그렇게 잘 돌아가지가 않아서 l2-reguralisation이 더 나은것으로 결론을 내리고 잊고 있었습니다.
그런데 2011년에 크리스토스 파파디미트리우가 토론토에서 강의하는걸 들었습니다. 강의 내용중에 생물의 2세 생산이 (두 유전자를 임의로 합치는 과정에서) co-adaptation을 막는 의미를 갖는다는 내용이 있었습니다. 어쩌면 강의의 촛점은 약간 다른 것 이었을 수도 있어요. 아무튼 저는 그렇게 받아들였습니다. 그리고 뉴런의 일부를 제거하는 것과 본질적으로 같은 내용이었죠. 그래서 이번엔 대학원생들과 함께 좀 더 열심히 구현을 해봤고 결과적으로 이 이론이 잘 작동한다는 것을 밝혀냈습니다.

----------
아이디어의 착상, 구현 실패, 재도전으로 구현 성공. 
대부분의 아이디어가 이런 과정으로 빛을 발하는 것이 아닌가 합니다. 
그리고 제프리 힌튼같은 사람도 지도해줄 사람이 없어서 구현을 실패했었다는게 재밌군요. 

Saturday, August 20, 2016

음악 자동 태거 (auto-tagger): 학습된 컨브넷 공개

깃헙 저장소에 제가 학습시킨 음악 자동 태거를 공개했습니다.
참고하시길 바랍니다.

예제 파일과 음원을 포함하고 있어서 코드만 보셔도 쉽게 이해하실 수 있습니다.

https://github.com/keunwoochoi/music-auto_tagging-keras