Share           Pin It

데이터 분석 및 알고리즘 개발을 업으로 하면서 딥러닝 Deep learning은 늘 관심의 대상이었다. 하지만 알고리즘을 실제 구현해보거나 여러 라이브러리를 이용해서 실제 문제에 적용하는 것을 시도하지 않았기에 그런 의미에서 딥러닝에 문외한이라 할 수도 있다. 그럼에도 -- 빅데이터 기술을 어느 순간부터 결국 업에 적용했던 때와 같이 -- 딥러닝 기술도 언젠가는 내가 담당하는 업에 적용해야할 때가 올 것을 알았기에 알고리즘의 기본 지식을 공부하거나 딥러닝 발전의 주요 논문을 빼놓지는 않고 찾아보곤 했다. 딥러닝의 가능성이 일반에 알려지기 시작한 2013년도부터 계속 지켜봐왔기에 딥러닝 전문가는 아니지만 딥러닝의 발전 과정을 어느 정도 꿰뚫고 있다고 생각하기에 어떤 기술들이 현재의 딥러닝을 가능케했는지를 정리해보는 것이 의미가 있을 듯해서 글을 적는다. 일단 MLP 이전의 내용은 생략한다. 그리고 어플리케이션 특화된 기술 -- 예를 들어, Translation의 랭귀지 모델 등 -- 도 생략한다. 

0. 컴퓨팅 파워 (하드웨어)
아래에 여러 알고리즘이나 트릭을 소개하겠지만, 실제 딥러닝을 가능케했던 것은 결국 컴퓨팅 파워의 기하급수적인 증가에 있다고 본다. GPU/TPU로 대변되는 하드웨어의 발전뿐만 아니라, 딥러닝 시대 이전 시대인 빅데이터를 가능케한 그리고/그래서 현재 딥러닝에 무한한 떡밥을 제공하는 클라우드, 즉 값싼 스토리지의 대중화가 결국 딥러닝을 꽃피웠다고 생각한다. 아래에 소개할 다양한 알고리즘이나 대중화된 오픈소스/라이브러리 등의 소프트웨어 이전에 하드웨어 기술을 빼놓고 딥러닝의 성공을 얘기하는 것은 있을 수 없는 일이다.

1. Pre-taining
90년대 말이나 2000년대 초에 나온 오래된 Neural Network 책을 보면 히든 레이어의 수를 늘리면 더 강력해질 거라는 얘기는 계속 해왔다. 하지만 실제 또는 토이 문제를 해결하는 뉴럴넷은 히든레이어가 겨우 1개, 많아봤자 2개를 넘지 않았다. 데이터의 부재와 하드웨어 성능에도 문제가 있었지만 3개 이상의 히든레이어를 가진 네트워크를 제대로 학습시키는 것이 만만치가 않았다. 이론상으로는 완벽해도, 랜덤에서 시작해서 복잡한 네트워크를 최적화시키는 것이 만만치가 않다. 그렇게 뉴럴넷이 잊혀졌지만 프리트레이닝 방식으로 뉴럴넷을 초기화하는 방법이 소개되면서 딥러닝이라는 시대의 조류를 만들어냈다. (데이터와 하드웨어의 발전과 더해서) 대표적으로 정답세트가 필요없는 auto-encoder 방식이 도입되고, RBM이나 DBN을 이론적으로 풀어내면서 뉴럴넷 학습/최적화가 쉬워졌다. 임의의 초기화가 아니라 어느 정도 길들여진 초기화를 통해서 네트워크의 최적화가 엄청 빠르고 쉬워졌다.

2. ReLU (Recified Linear Unit)
전통적인 뉴럴넷은 히든레이어의 액티베이션을 위해서 주로 sigmoid나 tanh 함수를 사용했다. 수학적으로 좋은 성질 (미분 가능)을 갖고 있기 때문이다. 하지만 레이어의 개수가 증가함에 따라서 최종 아웃풋에서 발생한 loss를 앞쪽으로 제대로 전달하지 못하는 gradient vanishing 현상이 발생했다. 네트워크 구조는 엄청 딥하게 만들어놨지만 backprogation에서 가중치의 변동은 최종 1~2개의 레이어에서만 일어나고 앞쪽 레이어는 실질적으로 무용지물이 되는 현상이다. 이를 위해서 마이너스 영역은 0으로, 포지티브 영역은 y=x로 액티베이션하는 ReLU를 적용하면서 이 문제를 해결했다. 최근에는 마이너스 영역으로 무조건 0으로 치환하는 것도 바람직하지 않아서 y = -ax (a << 1.0)하는 것이 낫다는 연구도 있었고, 더 최근에는 y = x * sigmoid(x)로 바꾸면 더 낫다는 논문도 나왔다. (Step 함수의 수학적 불완전성을 보완한 것이 sigmoid 함수이듯이 같은 식으로 ReLU의 미분가능 버전으로 바뀐 것이 x * sigmoid(x)다. continuous & smooth --> 미분가능)

3. Batch Normalization/Re-normalization
뉴럴넷/딥러닝의 성능은 최적화에 좌우된다. 데이터와 알고리즘의 차원이 큰 경우에 최적화는 매우 불안정하다. 그래서 다양한 regularization 방식이 소개됐다. 가장 쉬운 방식으로 가중치의 절대값의 합을 최소화하는 L1이나 제곱의 합을 최소화하는 L2 regularization을 사용한다. 회귀모델에서는 잘 잘동하는데 딥러닝 구조에서는 이 또한 복잡하다. 그래서 초기 딥러닝에서 네트워크를 안정적으로 학습시키기 위해서 drop-out이라는 방식을 이용했다. 즉, 전체 네트워크에서 임의의 일부 노드를 의도적으로 비활성화시켜도 전체 성능이 떨어지지 않게 만드는 방식이다. 그런데 이 방식은 학습속도를 기하급수적으로 늦춘다는 치명적인 단점이 있다. 그러던 중, 히든 레이어의 액티베이션값을 노말라이제이션을 하면 드랑아웃 등의 별도의 레귤라이제이션없이 모델을 안정적으로 학습시킬 수 있다는 실험 결과가 있었고, 현재의 대부분의 네트워크에 이 기법이 기본적으로 적용돼있다. (더 최근에는 작은 규모 또는 non-iid 미니배치에서도 잘 작동하도록 개선한 re-normalization이 소개됨) 딥러닝/뉴럴넷의 기초가 되는 회귀분석 regression에서 모든 독립/종속변수는 Normal 분포를 따른다는 기본 가정이 있는데 (<-- 매우 중요한 속성임), 히든레이어를 노말라이제션하면서 모델을 안정시켜주는 것 같다.
** 사견을 더 하자면 (주제 넘은 얘기지만), 처음 딥러닝을 공부하는 분들은 인터넷에 올라온 동영상 강의 몇 개만 보고 예제 코드 구현/실행해보는 것만으로 마스터할 수 있다고 생각하는 듯한데, 우선 기초적인 것부터 차근차근 공부했으면 합니다. 미적분, 확통, 응선대, 최적화부터 다 공부하라는 것은 아니지만, 적어도 linear regression정도는 마스터하고 딥러닝을 논했으면 합니다. (딥러닝의 첫 강의가 대부분 회귀분석이기는 하지만...) 가끔 커뮤니티에 올라오는 질문을 보고 있자면 이건 딥러닝을 배우겠다는 건지 아니면 그냥 숟가락을 떠서 입에 넣어달라는 건지...

4. LSTM와 ResNet
현재 딥러닝은 데이터의 디멘젼이 무척 큰 (때론 가변적인) 문제에 잘 적용되고 있다. 그런 문제로 자연어/문자열과 이미지 처리가 있다. 처음에는 문자열 데이터에 RNN을 적용하고 이미지 데이터에 CNN을 적용해서 문제를 해결했다. 하지만 문자열이 길어지거나 레이어가 깊어지면서 약점이 발견됐고, 이를 해결하기 위해서 LSTM과 ResNet이 소개됐고 현재는 거의 기본 방식으로 인식된다. (LSTM과 ResNet은 제대로 공부한 것이 아니어서 더 길게 설명하면 틀린 설명만 추가할 듯합니다.ㅠㅠ 알파고 제로 논문에서 ResNet을 사용한 걸 보고 이 글을 적기 시작했는데 역설적이게도 ResNet에 대해서 제일 모름.) 오리지널 인풋이나 이전 과정의 중간결과물을 재활용(?)해서 네트워크를 개선하는 것이 전혀 새로운 아이디어는 아니지만, LSTM과 ResNet은 이 방식으로 딥러닝의 성능 향상 및 여러 애플리케이션에서 성과를 내고 있다.

이상의 알고리즘이나 방법론은 딥러닝을 안정적으로 최적화시키거나 실제 문제에 더 적합한 구조를 만드는 것들에 관한 것인데, 다음은 딥러닝의 대중화에 기여한 것들에 관한 것이다.

5. Word2Vec W2V은 구조가 매우 단순해서 실제 딥러닝과는 거리가 멀지만, (특히) 일반 개발자들 중에서 딥러닝을 처음 접했던 분들이 처음/쉽게 접하면서 딥러닝의 세계로 이끌었다고 해도 관언이 아니다. 몇 년 전에 딥러닝을 한다는 개발자를 만나면 대부분 그저 W2V으로 어떤 문제를 풀고 있는 경우가 많았다. 형태상으로 유사하지만 W2V은 엄밀히 말해서 딥러닝은 아니다. W2V은 잘 알려졌듯이 데이터를 임베딩하는 방식이다. 고차원의 데이터, sparse한 데이터, 또는 비정형 특히 비수치 데이터를 정형의 수치 벡터로 바꿔주는 것을 임베딩이라고 이해하면 된다. 경우에 따라서 효과적인 데이터 차원 축소 방식을 제공하기도 한다. 그리고 이런 임베딩을 통해서 얻어진 수치벡터가 딥러닝의 인풋으로 활용되기 때문에 딥러닝과 무관하다고 말하기도 어렵다. 이후에 Glove 등의 다른 임베딩 방식의 발견에도 기여했다.

6. TensorFlow 2013년에 텐서플로우가 있었다면 제가 직접 다양한 딥러닝 알고리즘을 구현해서 여러 문제에 적용하는 것을 꾸준히 했을 거라는 생각이 든다. 개발에 익숙치 않은 개발자(??)에게 딥러닝의 모든 알고리즘을 직접 구현한다거나 일부 공개된 라이브러리를 제대로 활용하는 것이 쉬운 일이 아니다. 그래서 구현해서 적용해보는 건 포기하고, 그냥 이 동네에 기웃거리면서 어떻게 발전되는지만 지켜보고 있ㄴ...(ㅠㅠ) 텐서플로우 이전에도 Caffe나 Teano, Torch 등의 오픈 딥러닝 라이브러리가 있었지만 이 분야에 익숙한 전문가들을 위한 전유물이었다. 하지만 구글에서 텐서플로우를 오픈하면서 딥러닝이 좀더 일반인(?)에게로 저변이 확대됐다. 결과적으로 인공지능 (딥러닝)이 많은 부분에서 이젠 엔지니어링 분야로 넘어왔다고 봅니다.
(여담) 구글에 텐서플로우를 공개한 것은 하둡이나 하이브 등의 빅데이터 표준에서 밀렸던 과거가 있었기에 가능했다. 실제 맵리듀스나 빅테이블 등의 많은 빅데이터 개념들이 구글에서 나왔지만 그걸 모방한 하둡이 실질적인 표준이 됐다. 씨는 구글이 뿌렸지만 열매는 다른 기업들이 따먹은 것과 같았는데, 같은 실수를 인공지능 분야에서도 반복하지 않기 위해서 텐서플로우를 공개했고, 현재로써는 대중화에 성공했다고 본다.
추가 (2017.10.31) 갑자기 아이디어가 떠올라서 Python + Keras로 텐플을 이용중이다. 케라스 시퀀스 모델에 위에 설명한 개념들을 기계적으로 추가해서 Run하면 그만이다. 속도는 구조와 데이터가 커서 느리지만, 오늘 딥러닝을 처음 접한 사람도 바로 따라할 수 있다. 엔지니어링의 승리다.

7. Reinforcement Learning과 GAN 현재 가장 핫한 분야는 강화학습과 GAN일 거다. 인공지능 기술을 진짜 인공지능이 되도록 만들어주는 기술이라해도 과언이 아니다. 인공지능을 지능이라 부르기 위해서는 알고리즘이 ‘스스로 적응’할 수 있어야할텐데, 강화학습과 GAN이 가능하게 해주고 있다고 본다. 개인 소견으로 딥러닝이 인공지능의 끝은 아니라고 생각하지만, 어쨌든 현재로썬 강화학습과 GAN의 등장으로 딥러닝이 진짜 인공지능답게 만들어지고 있다고 본다.
(여담) 보통 강화학습을 supuervised와 unsupervised와 별개의 새로운 카테고리에 넣어서 설명하는데, 저의 개인적 의견은 강화학습을 supervised 하위에 넣는 게 맞다고 본다. 처음부터 결과를 알고 있는 supervised와는 달리 결과에 따른 리워드 (win/lose, 점수)가 나중에 평가된다는 점이 다소 다르지만 리워드 자체는 일종의 슈퍼바이저라고 보는 게 맞을 듯하다는 생각에서다. (사견이니 무시해도 된다.)

개발자들이 딥러닝을 쉽게 접급하게 해준 것은 Word2Vec, 일반인들이 딥러닝/AI에 관심을 갖게 만든 것은 강화학습을 이용한 AlphaGo (Atari가 먼저지만, 임팩트 면에서), 일반인들이 (그나마) 쉽게 딥러닝을 공부하고 다룰 수 있게 해준 것은 TensorFlow, 우리 실생활의 문제들에 딥러닝이 적용될 수 있게 해준 것은 LSTM (ResNet은 정확도를 높인..), 그리고 딥러닝을 더욱 인공지능처럼 만든 것은 강화학습과 GAN. ... 일런 것을 가능케해준 여러 지속적인 개선들... 뉴턴은 거인의 어깨 위에 섰기 때문에 조금 더 멀리 볼 수 있었다고 말했지만, 거인은 난쟁이들이 쌓아놓은 무수한 모래 성이 있었기에 그 위에 설 수 있었던 것 같다. 최근 10년, 대부분은 최근 3~4년 내에 일어난 사건들... 빠르다. (물론 LSTM과 같이 20년 전에 제안돼서 지금 꽃을 피우는 기술도 있다.)

설명이 부족하거나 일부 틀린 내용이 있을 수도 있습니다. 좀더 면밀히 공부해서 제대로 수정/보강하도록 노력하겠습니다.

이걸 그냥 적당히 슬라이드로 만들어서 전문가인양 모르는 사람들한테 약이나 팔고 다닐까? 하지만 어려운 기술에 대한 연성의 (쉬운이 아닌) 자료는 아무에게도 도움이 되지 않는다는 걸 깨달았습니다. 일부 약장수를 제외하곤...

** 딥러닝이 지금 인공지능을 이끌고 있지만, 인공지능의 미래가 딥러닝에 있다고는 생각지 않습니다.

=== Also in...

F: https://www.facebook.com/unexperienced

댓글을 달아 주세요

Share           Pin It

어쩌다 보니 카카오 AI 리포트 7월호에 카카오의 광고 랭킹 알고리즘을 소개하는 글을 적게 됐습니다. (퇴고 시간이 길었지만 실질적으로 이틀만에 급하게 적음) 원래는 제목처럼 '광고는 서비스의 동반자다'라는 이름으로 글을 적었지만 최종 편집본에는 '더욱 똑똑해진 AI 광고 알고리듬'으로 정해졌습니다. 대부분은 초본과 같았지만, 서론과 결언 부분이 조금 편집되면서 변경됐습니다. 그래서 초안에 적었던 서론과 결언만 다시 적습니다. 개인적으로 한글화가 어색한 영어 용어는 그냥 영어로 적는 편인데 편집되면서 한글화된 점도 미리 밝힙니다.ㅠㅠ

===

답이 정해진 질문으로 시작합니다. 

구글 Alphabet Inc.은 무슨 회사인가?라는 질문에 많은 사람들은 검색 서비스 회사나 안드로이드 OS 를 만드는 회사 정도로 답한다. 이 글을 읽는 분들이라면 TensorFlow를 만든 회사 또는 AlphaGo를 만 든 DeepMind의 모회사 정도로 답할지도 모른다. 같은 질문을 페이스북 Facebook Inc.에 적용한다면 소셜미디어 (SNS) 회사나 Instagram 또는 WhatsApp 서비스를 제공하는 회사라는 답변이 가장 많을 거 다. 어떤 기업을 정의할 때 그들이 무슨 제품을 만들고 어떤 서비스를 제공하는지도 중요한 요소지만, 그기업의자금흐름이어떠한지를보는것도중요하다.즉,기업이어떻게돈을버는지가그기업의 본질을 나타낸다. 공히 구글과 페이스북의 매출에서 광고가 8~90% 이상을 차지한다. 그렇다면 구글 과 페이스북은 광고 회사라고 정의하는 것이 맞다. 구글은 광고를 위해서 검색 서비스를 제공하고 안 드로이드OS를 만들고 있는 것이고, 페이스북도 광고를 위해서 타임라인과 인스타그램 등의 서비스 를 제공하고 있는 셈이다. 국내의 네이버도 광고 회사고, 카카오는 포트폴리오가 좀더 다양하지만 매 출의 50%정도는 광고가 차지하므로2 광고 회사라 불러도 무관하다. 광고의 정의와 범위에 따라 달라 지겠지만 우리가 알고 있는 대부분의 인터넷 기업들을 광고 회사로 봐야 한다. 광고 비즈니스를 알면 인터넷기업의진면모를제대로볼수있지만,아쉽게도많은이들이—심지어IT회사의직원들마저 도—인터넷기업들이어떻게돈을벌고있는지제대로알지못한다.


본문은 브런치 참조... 

https://brunch.co.kr/@kakao-it/84


결언

글의 성격상 경어체를 사용하지 못했습니다. 담당하는 업무를 소개하는 글을 부탁받고 신나게 적다 보니어려울수있는내용을좀지루하게적었습니다.지면관계상많은디테일을생략해서다소어렵 거나 재미없을 수도 있지만 광고 랭킹과 관련된 많은 문제들이 존재하고 그것을 데이터 관점에서 그 리고 알고리즘으로 하나씩 해결해가는 과정은 참 재미있습니다. 여러분들의 도전을 기다리는 많은 재미있는 문제들이 있습니다. [그림 2]보다 더 아름다운 우상향 그래프를 그려줄 동료를 찾고 있습니다. 본인의 업무가 데이터 모델링과 알고리즘을 담당하고 있어서 시스템에 관한 지식이 많지 않습니다. 그래서 광고 시스템과 관련된 자세한 내용은 적지 못했습니다.

===

저희 팀에서 우수한 연구자와 개발자를 계속 뽑고 있습니다. 역으로 저를 좀 끌어가셔도...ㅎㅎ


(또) 어쩌다 보니, 학교 후배인 VUNO의 CTO 정규환 박사의 글도 7월호에 함께 실렸습니다.

[카카오AI리포트] AI 의료영상 기술 활용 사례 https://brunch.co.kr/@kakao-it/81

=== Also in...

F: https://www.facebook.com/unexperienced



댓글을 달아 주세요

Share           Pin It
오랫동안 데이터 관련 업무를 해왔지만, 관련된 모든 것을 완벽하게 알고 있는 것은 아니다. 그저 일을 하면서 느낀 의견일 뿐이고, 어쩌면 다른 많은 데이터 분석가들은 동의하지 않을지도 모른다.

많은 일반인들은 데이터는 매우 정확한 것이다라는 인식을 가진 것같다. 특히 일반 개발자들과 일을 하다보면 대략적인 데이터 관련 로직/알고리즘을 스케치해서 알려주면 세세한 부분까지 내가 알려줬던 내용을 그대로 구현하려는 경향이 있다. 데이터 관련 전문성/경험의 부족에 따른 것일 수도 있고, 그냥 시각의 차이일 수도 있다. 데이터 분석의 결과는 매우 정확하고 그것을 반드시 따라야 한다는 생각을 가졌는지도 모른다.

그런데 분석 업무를 하다보면 엄격하게 정확한 데이터에 기반해서 의사를 결정하기도 하지만, 많은 경우 분석가의 감이나 경험에 의존하기도 한다. 해결해야할 문제를 검토하고 관련된 데이터를 수집하다 보면 대강 이렇게 로직을 만들고 이정도의 파라메터를 설정하면 된다는 그런 감 또는 경험치가 있다. 데이터가 보여주는 완벽한 궤적의 함수를 구하기 보다는 그냥 대강 SQRT를 씌우거나 LOG를 취하는 등의 데이터 변형을 시켜서 적용해 본다. 예를들어, scale-free 네트워크에서 빈도는 폭발하기 때문에 그런 종류의 시스템에서 나온 데이터라면 그냥 LOG를 취한다는 거다. 적당히 값을 키우고 싶을 때는 그냥 제곱을 적용해보고 더 급격히 증가하는 걸 원하면 세제곱을 해보기도 한다. 그런 경험치 함수를 적용해서 로직을 개발하는 경우가 많다. 실제 데이터가 그렇게 말해주기 때문에 그런 수식/로직이 나오지 않을 때가 많다는 거다.

대략적인 로직을 정해서 구현할 개발자들에게 알려줄 때, 어떤 변수의 범위가 필요할 때 특정 값을 지정해주는 경우도 있지만 대략 10정도보다 크면 된다라고 말하는 경우가 있다. 사실 11이 좋을지 9가 더 좋을지 나도 모른다. 그냥 안전한 수치를 정하는 것이고, 또 실제 구현해서 테스트하면서 11이 더 좋은 것 같으면 그냥 11로 해도 된다는 의미도 있다. 그런데 최종적으로 구현된 것을 보면 무조건 '10'으로 고정돼있는 걸 본다. 물론 데이터를 보고 값을 정해서 알려주는 것이 내 역할이기는 하지만, 상대방에게 자유도를 주기 위해서 대략적인 걸 말하는데 상대는 그렇지가 않은 것같다. 정확한 스펙과 순서를 요구한다.

아주 미세한 차이가 큰 (역)효과를 내는 분야가 있다. 달에 우주선을 쏘아올리는 경우 0.01도를 잘못 적으면 그 우주선은 우주 미아가 될 수도 있다. 그런데, 현실에서 우리가 만나는 많은 데이터 문제들이 그렇게 세밀하지가 않다. 하루에 '데이터'라는 쿼리가 1000번 들어오는 것과 1001번 들어오는 것은 별로 큰 차이가 없다. 광고 CTR을 0.1%를 올리는 것은 매출에 큰 영향을 준다. 그러나 광고 노출에서 어떤 조건을 10을 두는 것과 10.1 또는 11로 두는 것에 따라서 실제 광고 CTR이 0.1% 이상 차이가 나는 경우가 많지가 않다. (물론 중요한 변수인 경우는 차이를 낼 수도 있고, 여러 변수들이 복합적으로 작용해서 예상치 못한 결과를 줄 수는 있다. 그러나 그렇게 중요한 변수라면 이미 잘 통제되고 있거나 더 정확한 실험 등으로 값을 특정했을 거다.)

그리고 현실에서 정확한 수치가 아닌 것을 원하는 경우가 있다. 예를들어, 최적화 문제/식을 잘 풀었더니 X = 10.56이 나왔다고 치자. 그런데, 원래 문제의 도메인이 정수형이었다면, 즉 Integer program이었다면 10.56은 틀린 답이다. 10이나 11이 돼야 한다. 만약 제고관리나 생산관리 등에서 오늘 하루동안 완성해야하는 자동차의 대수가 100.56대가 나왔다면 100대를 만들고, 나머지 한대는 0.56만큼 미완성품으로 만들어둬야 하는 게 아니다. 이런 경우 하루에 100대를 생산하거나 101대를 생산하라고 명령이 내려져야 한다. (반제품 상태로 나둬도 되는 경우라서 조금 모호하긴 하다.) 최적화 식을 통해서 내일 컴퓨터 8.4대가 필요하다는 값이 나왔다면 당연히 9대를 가져올 거다. 극단적인 예처럼 보이지만, 현실에서는 정확한 수치보다는 그 상황에 맞는 그럴 듯한 수치가 필요한 경우가 많다.

데이터를 다루는 사람들은 늘 직관의 선물을 감사히 받아들여야 한다. (다음 이야기에서 정확한 분야나 숫자는 의미가 없다) 초보 분석가가 며칠동안 고생해서 8.347이라는 해를 구했는데, 상사는 그냥 빈둥거리며 놀다가 한 8.5정도 나오지 않을까?라고 직관적으로 얘기하는데 어렵게 구한 값과 별로 차이가 없었다 등의 풍문이 많다를. 직관/경험이 맞고 데이터가 틀렸다는 얘기가 아니다. 데이터가 주는 정확함에 너무 집착하지 않았으면 한다는 얘기다. 초기의 미세한 차이가 향후에 큰 차이를 만들어낼 수도 있다. 그런 경우라면 중간에 변화의 폭이 커지는 사이에 조정을 해주면 되는 것이지 처음부터 엄격할 필요는 없다. (물론, 중간에 미세 조정이 불가한 경우도 있겠지만...) 그리고 데이터가 정확하다고 믿겠지만, 데이터 내에 부정확함을 내포하기 때문에 데이터가 거짓은 아니지만 진실을 얘기하지 않는 경우도 많다. 어차피 대부분의 분석은 모집단 전체가 아니라 (편향될 수 밖에 없는) 샘플을 사용한다. 빅데이터도 데이터가 많아져서 부정확함을 상쇄시킬 가능성이 높아진 것이지, 데이터 자체의 부정확함은 여전히 존재한다. 그리고 머신러닝에서 사용하는 대부분의 알고리즘도 처음에는 랜덤에서 시작하기도 하고, 같은 데이터로 여러 번 같은 프로그램을 돌려도 다른 결과값을 내주기도 한다. (물론 그런 랜덤성을 최대한 없애고 결과의 일관성을 확보하도록 알고리즘이 발전하고 각종 트릭들이 보완되는 거다.)

부정확함은 어느 곳에든지 존재한다. 그렇기 때문에 데이터는 정확하다는 것은 일종의 미신이다. 처음에는 모호함이 주는 자유를 즐겨라라는 것을 적고 싶었는데, 뒤로 갈수록 뉘앙스가 달라졌다. 개발자들은 데이터 전문가들을 무조건 믿지는 말아야 한다. 엄격한 것이 틀렸을 가능성이 더 높다.

===
B: https://brunch.co.kr/@jejugrapher
M: https://medium.com/jeju-photography
F: https://www.facebook.com/unexperienced

댓글을 달아 주세요

기술과 인간

Gos&Op 2014.08.12 18:09 |
Share           Pin It
"길게 잡아서 2년 내에 당신이 하고 있는 일의 절반 이상을 자동화시킬 수 있어야 한다."

최근 함께 일하고 있는 친구에게 한 말입니다. 미디어다음에서 뉴스를 편집운영하면서 뉴스추천 프로젝트를 메인으로 기획한 친구입니다. 제대로 된 뉴스 편집 및 운영은 끊임없이 쏟아지는 모든 뉴스를 읽고 미담이나 다음탑에 노출시킬 것인가 말것인가를 계속 판단해야 하는 사람손을 많이 타는 일입니다. 그럼에도 불구하고 이 활동의 절반 이상을 단기간 내에 자동화시키고 그 친구는 다른 더 창의적인 생각에 집중해야 한다는 말입니다.

비단 이 친구에게만 들려주고 싶은 말은 아닙니다. 지난 글(참고. 기획에 대해서)에서처럼 함께 일하고 있는 모든 기획자들에게 같은 조언을 해주고 싶습니다. 물론 개발자라고 해서 예외는 아닙니다. 성격이 조금 다를 뿐 허투루 허비하는 많은 잡다한 일들은 자동 영역에 맡기도 늘 새롭고 창의적인 사고, 실행에 집중해야 합니다. 2년이란 시간도 길게 잡은 것입니다. 그만큼 절박한 생존의 문제입니다.

흔히 자동화를 통해서 기계 또는 컴퓨터가 사람을 완전히 대체해버리는 것을 생각합니다. 지구 상의 누군가는 그런 완전무결한 자동화를 꿈꾸고 실현하기 위해서 연구하고 있을 것입니다. 그들의 노력에 찬사를 보내고 좋은 결실을 맺을 것을 바랍니다. 설령 그렇게 되어 내가 할 수 있는 일이 없어진다고 해도 그런 현실을 받아들일 자세가 되어있습니다. 그러나 이 글에서 자동화란 사람을 완전히 대체하는 로봇을 얘기하는 것은 아닙니다.

데이터 마이닝이라는 파트에서 일하다 보니 사람들은 데이터 마이닝을 좀 경외의 대상으로 생각하는 것같습니다. 뭔가 복잡하고 어려운 분야라고 생각합니다. 그래서 회사에서 데이터마이닝/분석을 한다고 말하면 데이터마이닝에 대해서 조금 더 관심을 보이기 전에 손사레를 치고 외면해버립니다. 그러고선 이제껏 편하게 해왔던 일로 돌아섭니다. 그런 두려움과 미신이 저같은 허름한 분석가를 (분석가의 역할을) 보호해주는 것같아 내심 안도하면서도 조금 씁쓸하기도 합니다.

어떤 측면에서 학계를 중심으로 발전시킨 데이터마이닝은 조금 복잡하기도 합니다. 일상에서 전혀 들어볼 수 없는 어려운 용어들로 가득 차있고, 하나의 개념이나 알고리즘을 이해하기 위해서는 선행해서 알아야 하는 지식이 한가득입니다. 그리고 어떤 측면에서는 연구가들은 일부러 더 어려운 용어를 만들어내고 간단한 설명도 복잡한 수식으로 표현하는 것같습니다. 학교에서 농담삼아 얘기했던 건데, 복잡한 증명문제를 그저 'It's trivial'이라고 말하고 증명을 생략하는 경우도 있습니다. 논문 하나를 이해하기 위해서 엮인 많은 논문을 읽어야 하고, 그 참조 논문들을 이해하기 위해서 또 엮인 것들을 읽어야 합니다.

사무실이 조금 추운 것같아서 건물 밖을 한 바퀴 돌면서 생각했습니다. 어쩌면 정작 사람들에게 필요한 기술은 정교하고 복잡한 알고리즘이 아닐 수 있다는 생각입니다. 서두에 말한 자동화도 그렇습니다. 내가 하고 있는 일을 완전히 대체하는 개념의 자동화가 아니라, 내가 하고 있는 일을 더 빠르고 편하게 도와주고 그렇게 해서 절약한 시간을 다른 곳에 집중할 수 있게 해주는 그런 종류의 자동화입니다. 

데이터 기반의 기획이 그렇습니다. (당장은) 아무리 좋은 알고리즘을 개발하더라도 기획자의 역할을 완전히 대체할 수 없습니다. 그러나 적당한 데이터 가공만으로도 그들의 잡다한 수고를 덜어줄 수가 있습니다. 기획자가 자신의 일의 50%이상을 자동화해야 한다는 의미도 어떤 제품/서비스를 만들어낼 것인가만 고민할 것이 아니라, 어떤 도구나 데이터가 있으면 내가 만들고자 하는 서비스/제품을 미리 검증해보고 상상하는데 도움이 될 수 있을까를 고민하는 것입니다. 그런 고민으로 자신의 일을 경감시켜줄 데이터나 도구를 마련한다면 2년 후에는 한차원 높은 기획자가 돼있으리라 생각합니다.

서비스를 준비하면서 여러 논문을 다시 찾아봅니다. 참 읽기 어렵습니다. 인트로까지는 쉽게 읽게는데 그 이후는 내가 논문을 읽고 있는 것인지 아니면 그냥 시간을 보내는 것인지 분간할 수 없는 때가 종종 있습니다. 이런 경험이 쌓여갈수록 내가 만들어내는 알고리즘도 복잡한 수식으로 이뤄진 거창한 무언가가 돼야 한다는 헛생각에 사로잡히기도 합니다. 그러다 보니 간단하게 해결할 문제를 이것저것 새로운 요소들을 갖다붙여서 복잡한 솔루션으로 만들어 냅니다. 마치 알고리즘/솔루션의 복잡함이 나의 위대함을 나타내는 증거인양... 그렇게 해서 큰 효과가 있다면 다행이지만, 그저 간단한 수식이나 몇몇 요소로 해결했을 때보다 더 나아졌다는 보장이 없는 경우가 많습니다. 그래서 간단한 기술, 쉬운 알고리즘이 더 사람에게 필요한 것일 수 있다는 생각으로 다시 돌아왔습니다.

요즘 빅데이터 기술로 인해서 난해한 문제나 알고리즘을 사용할 수 있게도 됐지만 (예를들어 최근 많은 관심을 받는 딥러닝 Deep Learning같은), 오히려 간단한 더하기, 빼기, 곱하기, 나누기 즉 사칙연산만으로도 많은 문제들이 해결되고 있습니다. 그리고 간단한 알고리즘/연산으로 빠른 시간에 해결하는 것이 조금 더 정확한 예측보다 더 유용할 때가 많습니다. 엔지니어링이란 복잡함을 감추는 과정이지만 그것 자체도 굳이 복잡할 필요는 없습니다.

글을 적으면서 여러 논점이 섞였습니다. 기술은 필요에 따라서 복잡해질 수 있습니다. 그 복잡함을 재고하고 정작 인간에게 필요한 것이 뭘까를 고민하게 됩니다.

기술은 인간을 대체하는 것이 아니라 보완합니다. 미리 겁먹을 필요는 없습니다.

==
페이스북 페이지: https://www.facebook.com/unexperienced


댓글을 달아 주세요

Share           Pin It
과학자는 자신이 가진 솔루션을 적용할 문제를 찾고 엔지니어는 자신의 문제를 해결할 솔루션을 찾는다라는 말로 과학(자)과 엔지니어링을 구분한 글을 본 적이 있다. 적절한 구분인 것같다. 데이터 분석/마이닝도 같은 관점에서 구분할 수 있을까? 문제에 맞는 솔루션을 찾는 사람은 데이터 마이너고, 알고리즘에 맞는 문제를 찾는 사람은 데이터 사이언티스트라고 부를 수 있을까? 별로 좋은 구분인 것같지 않다.

최근 빅데이터나 데이터 사이언스 등에 관심이 조금 쏠리고 데이터 기반의 무엇 (Data-driven X)이라는 표현을 자주 접하게 된다. 선무당이 사람잡는다는 말도 있지만, 데이터와 연결된 용어들이 범람하면서 데이터 선무당들도 많이 늘고 있는 것같다. 간혹 지난 몇 년동안 엄청나게 많은 데이터를 모아놓았는데 이걸로 빅데이터 분석할 수 있지 않을까요?라는 류의 질문을 받곤 한다. 가혹 (데이터 분석의 생리를) 알만한 사람들도 비슷한 요청을 한다.

앞서 엔지니어와 과학자를 구분하면서 문제와 솔루션 중 어느 것에 익숙한가로 정했다. 데이터 마이닝이 과학이냐 엔지니어링이냐를 구분하기는 문제와 솔루션이 적당한 측도는 아니지만, 데이터를 접근하는 방식에 대해서는 좋은 설명이 될 것같다. 데이터 마이닝은 문제와 솔루션 사이에 데이터가 존재한다. 데이터가 문제와 솔루션 사이를 연결한다고 봐도 좋다. 그래서 크게, 문제(서비스)에 맞는 데이터를 수집해서 적당한 솔루션을 찾는 방향과 솔루션이 적용될 문제를 찾아서 데이터 인사이트를 얻는 방향이 있을 수 있다. 서비스에 익숙한 사람이라면 나이브하더라도 그것에 맞는 알고리즘을 찾아서 적용해보고 필요하면 더 나은 알고리즘을 찾거나 기존 것을 개선하면 된다. 반대로 알고리즘에 익숙하다면 서비스를 조금씩 이해하가면서 자신의 솔루션을 끼워넣으면 된다. 일반적으로 그렇다는 얘기다.

다른 접근법이 있기는 하다. 주변에서 흔히 접하는 것인데, 가장 이해하기 힘들고 피했으면 하는 접근법이다. 앞서 말했듯이, 우리한테 데이터가 많이 있으니 괜찮은 서비스 하나 만들어볼까요?라는 접근이다. 데이터만 (많이) 있으면 서비스가 하늘에서 뚝 떨어진다는 생각이다. 그래서 많은 경우 데이터 접근법이 실패한다. 모든 것은 컨텍스트 내에서 정의된다. 데이터의 컨텍스트는 서비스다. 유능한 사람은 데이터 더미에서 인사이트를 얻을 수 있겠지만, 나같은 범인은 그러지 못한다. 데이터가 많다고 데이터 기반의 실행이 이뤄지는 것이 아니다.

그리고 이런 경우 데이터가 많기는 한데 데이터 분석에 바로 사용할 수 있는 것도 아니다. 그냥 언젠가 필요할 것같으니 다 모아두자는 식으로 데이터를 쌓아둔 경우가 대부분이다. 물론 많은 회사에서 그런 데이터조차도 관리하고 있지 않지만... 불필요하게 공간만 차지하는 필드들도 많고, 정작 필요한 데이터는 애초에 없는 경우가 많다. 데이터를 분석하고 적용하려면 처음부터 다시 데이터를 모으거나 필요한 형태로 가공해야 한다. 데이터가 잘 정립된 곳에서도 데이터를 가지고 새로운 분석을 하거나 서비스를 만들 때 5할은 데이터 정의/변환에 소요되는데, 그냥 데이터만 쌓아둔 경우라면 9할을 여기에 허비하게 된다. 그러면서 서비스를 이해하게 되는 경우도 발생하지만, 깔끔하지는 않다. 어디에 어떻게 활용할지에 대한 목적없이 데이터를 수집해서 분석가들을 힘들게 만들지 않았으면...

데이터에 맞는 문제, 데이터에 맞는 솔루션은 없다. 데이터가 왕이 아니라, 왕이 될 데이터는 따로 있다.

==
페이스북 페이지: https://www.facebook.com/unexperienced


댓글을 달아 주세요

Share           Pin It
최근 페이스북 뉴스피드를 보면 몇 가지 변한 점을 발견할 수 있다. 나쁜 점도 있고 좋은 점도 있다.

먼저 나쁜 점부터 집어 보면 (물론 개인의 사용 패턴 그리고 관점/철학의 차이에 따른 불편함이다.) 페이스북이 1월에 뉴스피드 노출 알고리즘을 개선했다. (참고. 페북 뉴스피드, 페이지보단 친구 소식 잘 띄게) 블로터 기사처럼 현재 뉴스피드는 친구의 글/사진과 페이지 (팔로잉하는 사람의 글/사진 포함)를 함께 보여줬는데, Most Recent 옵션을 사용하면 모든 글을 시간 역순으로 보여줬다. 그런데 뉴스피드 알고리즘을 변경한 후에는 뉴스피드만으로는 모든 글을 확인할 수 없다. 물론 이전에도 Top Stories를 선택하면 Edge Rank로 알려진 알고리즘에 의해서 많은 라이크나 댓글이 달린 기사를 우선 보여주기는 했지만, 지금처럼 제한하지는 않았다. 즉, (예전에는) Most Recent 옵션으로 모든 글을 시간순으로 확인할 수 있었다. 

그러나 지금은 Most Recent를 통해서 모든 글을 볼 수 없다. 해외 언론에서도 "Facebook's fatal weakness: Why the social network if losing to Amazon, Apple & Google"이라는 글을 통해서 나와 비슷한 불편을 토로했다. (위의 기사는 유저 컨트롤 그 이상을 다루고 있고 충분히 읽을 가치가 있음) 글의 저자 Andrew Leonard처럼 나도 페이스북 앱에 접속할 때마다 매번 상단의 랭킹 옵션을 Most Recent로 변경하고 있다. 그런데 앞서 말했듯이 이렇게 변경하더라도 모든 글을 볼 수가 없다. (어쩌면 모바일 앱에서는 조금 다를 수도 있다.) 그래서, 적어도 PC에서는, 모든 (친구가 적은 것이 아닌 페이지/팔로잉에 올라온) 최신 글을 확인하기 위해서 왼쪽 메뉴 패널에 있는 Pages Feed를 다시 확인해야 한다. 이 Pages Feed의 한가지 문제점은 내가 보고 싶은 것 이상을 보여준다는 단점이 있다. 즉, 나는 그냥 새로 올라온 글만 읽고 싶은데, 팔로잉하는 사람이 라이크를 누르거나 댓글을 단 모든 행동/글들을 함께 보여준다는 점이다. 나는 그들의 글을 보고 싶지 그들이 라이크/댓글을 단 글을 보고 싶은 것이 아니다.

어쨌든 이렇게 뉴스피드 알고리즘을 변경한 후로 내가 원하는 형태로 뉴스/글을 소비하지도 못하고, 불편하게 추가 액션을 취해야 하고, 또 그렇게 들어간 곳에서는 불필요한/보고 싶지 않은 쓸데없는 글들까지 모두 걸러서 봐야 한다. 물론 간혹 라이크나 댓글이 달린 글이 충분히 가치가 있는 경우도 있지만, 대부분은 나와 무관한 그냥 쓰레기인 경우가 많다. 자동화된 필터링은 좋지만 내 의지/의사와 반해서 마구잡이 필터링은 문제가 있다.

불편한 단점이 있다면 다른 측면에서 장점도 있다. 아래의 캡쳐 화면과 같이 관심이 가는 글/링크를 클릭하면 아래쪽에 관련된 글이 추가되어 추천해준다. 내용이 유사한 경우도 있지만, 적어도 아래 화면의 경우에는 글이 인용한 원문을 추천해주는 것은 참 반가운 일이다. 어제 밤에는 어느 애니메이션 감독의 짧은 동영상을 클릭했을 때, 그 감독의 다른 동영상을 추천해줘서 함께 볼 수 있어서 좋은 경험이었다. 



특히 업무적 특성, 그리고 지금 진행하고 있는 뉴스 추천과 묘하게 연결되는 것이라서 관심이 간다. 자연스레 알고리즘을 유추하게 된다. 정확한 알고리즘은 알 수 없으나 대강 유추해본다면 (다른 대부분의 알고리즘들의 메카니즘과 닮았으리라 판단함) 글에 사용된 키워드나 메타데이터/컨텍스트 (작성자, 글의 타입 등)의 유사도, 글에서 인용/참조한 링크의 원문, 사용자들의 행동 분석 (Collaborative Filtering) 등으로 관련도를 찾아내고, 그 추천된 글의 관련도에 더해서 인기도 (얼마나 공유되고 라이크받았는지)나 시간 (최신순도 있지만, 적어도 원문의 경우에는 더 오래된 글) 등의 랭킹팩터를 이용한 것같다.

그리고 모든 글에 추천 컨텐츠를 보여주는 것이 아니라, 내가 클릭한 글에 자동으로/즉시에 추천되는 형태 (반응형 추천)인 점도 중요한 포인트다. 즉, 내가 클릭해서 읽는다는 것은 내가 관심이 있다는 것이고, 그런 관심을 바탕으로 추천해주기 때문이다. 화면구성이나 UI/UX 때문에 어쩔 수 없이 추천 컨텐츠를 쏟아내서 보여줘야하는 경우가 많은데, 나의 행동에 반응해서 보여준다는 점은 마음에 든다. 그런데 이런 식으로 나중에는 광고도 은근슬쩍 노출해줄 것같다는 생각도 든다.

==
페이스북 페이지: https://www.facebook.com/unexperienced


댓글을 달아 주세요

Share           Pin It

14편의 글로 추천시스템을 마무리하려고 했었는데, 하나가 더 생각나서 글을 적습니다. 깊게 들어가면 어려워지는 문제지만, 이 그레서는 아주 피상적으로만 적겠습니다.

데이터마이닝하면 머신러닝이 같이 떠오른데 그러면 머신러닝은 추천 시스템에서 어떤 역할을 하느냐?라는 질문을 할 수 있습니다. 그래서 준비했습니다. 그러나 모든 디테일은 생략합니다. 구체적으로 어떤 머신러닝 알고리즘들이 추천시스템에 활용되고 있는지는 Netflix에서 나온 Mining Large Streams of User Data for Personalized Recommendations을 참조하세요.

Collaborative Filtering 알고리즘을 설명하면서 모델기반 CF를 잠깐 언급한 적이 있습니다. 여기서 모델이란 머신러닝을 통해서 학습된 모델을 의미합니다. 그러니 당연히 모델기반 CF에는 머신러닝이 사용됩니다. 그러면 메모리기반 CF나 다른 CBF 등에는 머신러닝이 사용되지 않았느냐?고 묻는다면, 위에 소개한 넷플릭스 케이스를 읽어보면 무시히 많은 알고리즘들이 사용되었다는 것을 알 수 있습니다. 구체적인 알고리즘을 명시하지는 못하겠지만, 추천 시스템 곳곳에 머신러닝 알고리즘들이 사용되고 있음을 설명해드리겠습니다.

추천 시스템에 사용된 유사도나 평가방법에 사용된 metric들이 모두 머신러닝의 기법/결실이라는 것은 굳이 따로 설명하지 않아도 될 듯합니다.

유저기반 CF 방식에서 가장 유사한 사용자 k명을 뽑아서 그들이 좋아하는 아이템들을 추천해줍니다. 여기서 k명을 선정하는 방식이 데이터마이닝 또는 머신러닝을 배울 때 가장 먼저 등장하는 k-NN (k-Nearest Neighborhood) 방식입니다. kNN이 특정 데이터 포인트에서 가장 가까운 k개의 데이터 포인트를 선별해서 그것들의 공통/다수 클래스를 타겟 데이터포인트레 라벨링하는 방식입니다. 당연히 가장 유사한 아이템을 뽑는 것도 kNN입니다.

LDA를 사용하면 유저와 아이템을 동시에 클러스터링 clustering 할 수 있다고 했습니다. 굳이 LDA를 사용하지 않더라도 유저의 아이템 점수들을 벡터로 클러스터링 방식으로 유저 세그먼테이션이 가능합니다. 비슷하게 아이템 세그먼테이션도 가능합니다. 이렇게 1차로 세그먼트를 나눈 후에, 개별 세그먼트별로 추천 알고리즘을 적용할 수 있습니다. 데이터를 어떻게 표현하느냐의 문제일 뿐, 모든 클러스터링 알고리즘들이 추천 시스템에 그대로 이용될 수 있습니다.

단순히 보면 추천 시스템은 유저의 아이템에 대한 선호도를 측정하는 것이고, 그래서 레이팅을 예측하거나 선호확률을 구합니다. 조금 다르게 생각해보면 특정 아이템을 좋아한다 또는 아니다, 즉 1과 0으로 분류하는 클래시피케이션 classification 문제입니다. 조금 더 세밀하게 쪼개면 좋아한다 그저그렇다 아니다 등으로 분류/예측합니다. 문제를 어떻게 모델링하느냐에 따라서 다양한 클래시피케이션 알고리즘들을 활용할 수 있습니다. 모델기반CF가 다양하게 등장하는 이유도 그렇습니다. 지금 추천 문제는 클래시피케이션 문제라고 말하고 있는 겁니다.

클러스터링과 클래피케이션 다음으로는 당연히 회귀분석 regression도 생각해볼 수 있습니다. 여러 곳에 회귀분석이 필요하겠지만, 가장 간단히 사용되는 곳은 바로 다양한 추천 알고리즘들의 결과를 하나로 합쳐서 하이브리드로 만들 때 필요합니다. CF와 CBF를 각각 하나씩 사용했다면 최종 예측값은 R = w0 + w1*CF + w2*CBF (w1+w2=1)와 같은 선형식을 만들 수 있고, 적절한 웨이트값 w1/w2를 찾는 방식은 회귀분석의 least square 등을 사용해서 구할 수 있습니다.

랭킹에서 사용되는 다양한 알고리즘들도 그대로 추천에 활용됩니다. 이전 글에서 검색엔진의 인풋은 키워드지만, 추천 시스템의 인풋은 유저 또는 아이템이라는 점만 다를 뿐 추천시스템도 검색엔진과 다를 바가 없다고 말했습니다. 검색랭킹의 알고리즘과 추천 랭킹 알고리즘이 다를 바가 없다는 말입니다. 검색엔진에서 페이지랭크의 개념은 유저와 아이템으로 묶인 네트워크에서 유사하게 적용될 수 있습니다. 페이지랭크의 연결성과 추천에서의 연결성이 본질적으로 같습니다.

문제와 해법이라는 이분법적 프레임에서 보면, 추천 시스템에서는 다양한 추천 알고리즘이 해법이 되고 책, 상품, 뉴스 등의 피추천 아이템/서비스 분야는 문제가 됩니다. 그러나 더 아래 단계를 생각해보면 다양한 머신러닝 알고리즘들이 해법이 되고 추천 시스템 (알고리즘)은 그것들의 문제입니다. 즉, 수학/머신러닝 알고리즘이 추천 시스템에 해법을 제공해주고, 그 추천 시스템이 다른 서비스의 해법을 제공해주는 재귀적 과정입니다. 서비스를 다루는 사람이 단순히 그것의 해결책에만 몰두할 것이 아니라, 그 해결책을 해결해주는 해결책에도 관심을 가져야 한다는 이상한 논리를 펼치고 있습니다. 어쨌든 기본은 중요하니까요.

모든 문제는 여전히 더 나은 해결책을 원합니다.


추천시스템 전체 목록

  1. 추천 시스템과의 조우 (PR시리즈.1)
  2. 추천 시스템을 위한 데이터 준비 (PR시리즈.2)
  3. 추천대상에 따른 추천 시스템의 분류 (PR시리즈.3)
  4. 알고리즘에 따른 추천 시스템의 분류 (PR시리즈.4)
  5. 추천 시스템을 위한 유사도 측정 방법 (PR시리즈.5)
  6. 추천 시스템의 성능 평가방법 및 고려사항 (PR시리즈.6)
  7. 추천 시스템에서의 랭킹과 필터링 문제 (PR시리즈.7)
  8. 추천 시스템의 쇼핑하우 적용예 (PR시리즈.8)
  9. 개인화 추천 시스템에 대하여 (PR시리즈.9)
  10. 추천 시스템의 부작용 - 필터버블 (PR시리즈.10)
  11. 추천 시스템의 레퍼런스 (PR시리즈.11)
  12. 추천 시스템에 대한 잡다한 생각들 (PR시리즈.12)
  13. 추천 시스템을 위한 하둡 마훗 사용하기 (PR시리즈.13)
  14. 추천 시스템에 대해서 여전히 남은 이야기들 (PR시리즈.14)
  15. 추천 시스템과 머신러닝 (PR시리즈.15)

==

페이스북 페이지: https://www.facebook.com/unexperienced

댓글을 달아 주세요

Share           Pin It

이번 글에서 추천 알고리즘에 따른 분류는 아닙니다. CF, 유저기반, 아이템기반 등의 일반적인 알고리즘의 설명은 다음 글에서 자세히 다룰 예정입니다. 이 글에서는 -- 적당한 표현이 떠오르지 않는데 -- 추천대상 또는 형태상의 분류를 다루고 있습니다. (아래는 그냥 '하다'체로 적겠습니다. 처음에 그렇게 적어놨었었네요.)

추천 시스템을 크게 나누면 전체추천, 그룹추천, 개인추천 (개인화), 및 연관아이템추천으로 나눌 수 있을 것같다.

전체추천은 말 그대로 불특정 다수에게 추천하는 형태다. 일반적으로 다음이나 네이버에 접속했을 때 첫화면에 보여지는 무수한 글/이미지/상품들이 전체추천이다. 일반적으로 에디터 또는 운영자들이 그날의 이슈에 따라서 선별해서 보여준다 (보통 featuring한다고 표현함). 조금 발전된 형태가 조회수나 댓글수 등을 확인해서 인기가 높은 글이나 아이템을 보여주는 형태다. 검색에서 실시간이슈도 불특정 다수에게 같은 내용을 제시하기 때문에 전체추천이다. 검색창에 글을 입력하면 나타나는 suggest도 전체추천에 해당한다.

그룹추천은 사용자들을 특정 그룹 (세그먼트)로 나눠서 각 그룹에 특화된 컨텐츠를 추천해주는 형태다. 다음탑 또는 쇼핑하우에 들어가면 내또래라는 영역이 존재하는데, 이는 성연령대를 기준으로 특정 그룹에서 좋아하는 키워드나 상품을 추천해주는 형태다. 미담 내에도 개별 기사들의 조회한 성, 연령, 접속지역을 분석해서 각 세대의 인기 기사를 보여주는데, 이것도 그룹추천이다. 네이버에는 청소년, 재태크족, 주부 등으로 그룹을 나눠서 인기키워드를 보여주는 서비스가 있다. 그룹별추천에는 앞서 내또래처럼 사용자의 데모그래픽 등의 메타데이터를 기반으로 그룹열 신택틱하게 세분화할 수도 있고, 네이버 인기키워드처럼 사용자와 키워드 페어를 그룹핑/클러스터링해서 의미단위로 그룹핑할 수도 있다. (참고로 네이버 그룹별 키워드는 LDA라는 알고리즘을 사용했다. LDA는 추후에 다시 다루게 될까?)

개인추천은 말그대로 개인별로 맞춤추천, 즉 (추천)개인화다. 개인의 과거 이력을 바탕으로 그/그녀의 관심사를 특정하고, 그것에 맞는 아이템을 보여주는 형태다. 일반적으로 CF 알고리즘이 사용된다. 나중에 다시 자세히 다루겠지만, 사용자를 어떻게 모델링할 것인가? (프로파일링)이 개인화추천의 핵심이다. 검색했던 키워드, 읽었던 기사 또는 기사내의 주요 단어, 구독하거나 유사한 행동 패턴을 보인 다른 사용자/친구 등이 모두 개인 프로파일에 포함될 수 있다. (자세한 것은 추후에 따로 다룰 예정이다.)

연관아이템추천은 사용자를 그루핑하거나 개인별 맞춤추천을 해주는 것이 아니다. 개별 아이템별로 관련 아이템을 보여주는 형태다. 미디어다음에서 기사를 보면 오른쪽 날개 영역에 관련기사/이슈를 보여주기도 하고, 언론사들은 기사 하단에 관련기사를 피쳐링해서 보여주기도 한다. 다음의 쇼핑하우에서 상품을 검색해보면 아래쪽에 추천 영역이 노출되는데, 그곳에서 '최근본상품' 탭이 아이템추천이다. 아마존과 유튜브의 관련동영상이 바로 CF기반의 연관아이템추천이디. 일반적으로 메타데이터를 이용해서 (일반화시켜서) 클러스터링해서 관련아이템을 뽑아내거나 CF방식으로 관련아이템을 뽑을 수 있다. 추천시스템에서는 일반적으로 CF방식을 사용하지만, 커버리지문제 때문에 CBF와 하이브리드 형태로 조합되거나 너무 쌩뚱맞은 추천을 막기 위해서 메타데이터를 이용한 재가공/필터링이 이뤄지기도 한다. 그리고, 함께 구입한 물건을 연결하는 장바구니 분석은 아주 협소한 형태의 CF 분석방법이다. (기술적으로, Association Rule 기법이라 부름) 그리고 만약 개인의 프로파일이 최근 본 아이템들이면, 연관아이템과 결합되면 바로 개인화추천이 된다. (아마존 탑 페이지 참조)

다음 글에서는 CF를 중심으로 알고리즘 측면에서의 추천 시스템을 분류할 예정이다.

추천시스템 전체 목록

  1. 추천 시스템과의 조우 (PR시리즈.1)
  2. 추천 시스템을 위한 데이터 준비 (PR시리즈.2)
  3. 추천대상에 따른 추천 시스템의 분류 (PR시리즈.3)
  4. 알고리즘에 따른 추천 시스템의 분류 (PR시리즈.4)
  5. 추천 시스템을 위한 유사도 측정 방법 (PR시리즈.5)
  6. 추천 시스템의 성능 평가방법 및 고려사항 (PR시리즈.6)
  7. 추천 시스템에서의 랭킹과 필터링 문제 (PR시리즈.7)
  8. 추천 시스템의 쇼핑하우 적용예 (PR시리즈.8)
  9. 개인화 추천 시스템에 대하여 (PR시리즈.9)
  10. 추천 시스템의 부작용 - 필터버블 (PR시리즈.10)
  11. 추천 시스템의 레퍼런스 (PR시리즈.11)
  12. 추천 시스템에 대한 잡다한 생각들 (PR시리즈.12)
  13. 추천 시스템을 위한 하둡 마훗 사용하기 (PR시리즈.13)
  14. 추천 시스템에 대해서 여전히 남은 이야기들 (PR시리즈.14)

==

페이스북 페이지: https://www.facebook.com/unexperienced

댓글을 달아 주세요

Share           Pin It

두번째로 추천에 사용되는 데이터에 대해서 간단히 설명하겠습니다. 추천방식에 따라서 필요한 데이터가 달라지지만, 가장 일반적인 내용을 설명하고 추후에 특정 알고리즘이나 방식에 맞는 데이터는 별도로 설명하겠습니다. (특정 용어가 특정/다른 상황에서 적절하지 않을 수도 있습니다.)

추천의 기본 원리는 과거는 곧 미래다입니다. 그렇기에 추천을 위해서 필요한 데이터는 유저들의 행위 behavior 기록입니다. 상품 구매 이력, 이벤트 참석 이력, 기사를 공유했거나 like를 한 이력, 영화나 드라마를 보거나 평점을 남긴 이력 등의 모든 것들이 추천시스템에서 활용합니다. 그런 모든 이력들이 제품이나 컨텐츠에 대한 사용자의 선호/관심을 나타내는 지표로 사용합니다.

좀 더 구체적으로 쇼핑 추천을 예로 들겠습니다. A라는 사람이 특정 나이키 운동화를 웹에서 조회해본 것도 그 사람이 그 제품에 대한 선호를 보여주는 것이고, 더 나아가 그 제품을 구입했다면 더 확실하게 표시한 것입니다. 더우기 평점을 5점 (5점 스케일에서)으로 매겼다면 그 사람의 제품에 대한 만족도/선호도를 명시적으로 보여주는 것입니다. 댓글을 남긴다거나 추가로 더 구입한다거나 등의 모든 행위들이 사용자의 선호도 지표로 활용됩니다. 조금 복잡한 얘기가 될 수도 있지만, 쇼핑검색에서 특정 제품이 검색결과에 노출되었지만 그 사용자가 그 제품을 조회해보지 않는다면 이는 마이너스 (-) 선호도로 측정되기도 합니다. 선호도의 정도는 경우에 따라서 다양하게 해석이 됩니다.

이런 사용자의 아이템 선호도를 레이팅이라고 말합니다. 레이팅은 말 그대로 평점/별점을 매긴 것을 뜻합니다. 앞서 쇼핑에서 5점 스케일로 평점을 줬다면 이는 명시적 레이팅 explicit rating이라고 부릅니다. 그런데 특정 제품을 조회해봤다거나 구매했다 등의 행위에서는 조회여부 (0/1), 구매여부 (0/1)로 나뉘어질 뿐 명시적으로 점수화시킬 수 없습니다. 이런 경우는 암묵적 점수 implicit feedback이라고 부릅니다. 초기의 연구들이 명시점수에 기반해서 진행되었습니다. 그러나 명시점수와 암묵점수 사이에는 서로 장단점이 있기 때문에 요즘에는 둘을 동시에 사용하는 것이 일반적입니다. 물론, 명시점수가 존재치않는 경우가 더 많습니다.

명시점수의 경우에는 사용자의 선호도가 명시적으로 나타나기 때문에 추천하는 것이 조금더 직관적입니다. 그런데 암묵점수에 비해서 데이터 빈약도 data sparsity가 훨씬 큽니다. 즉, 유저들이 특정 제품을 구입하더라도 평점을 매기지 않는 경우가 허다합니다. Data sparsity는 바로 추천 알고리즘의 정확도와 연결되기 때문에 중요한 이슈입니다. 그래서 더 dense한 암묵점수를 명시점수의 보조역할로 사용하는 경우가 많습니다. (때로는 암묵점수만을 사용하는 경우가 더 많음) 물론 그렇다고 해서 암묵점수가 data sparsity가 없다는 얘기는 아닙니다. 명시점수가 암묵점수보다 더 심하다는 얘기입니다.

Data sparsity 이외에도 명시점수의 단점이 많이 있습니다. 대표적으로 점수의 편향이 있다는 점입니다. 사용자들이 소비한 모든 컨텐츠/상품에 대해서 평점을 남기는 것도 아니고, 남겨진 평점에 대한 신뢰도 문제가 있습니다. 저는 책을 많이 읽는데, 좋은 책을 읽었을 때는 시스템에 접속해서 4 또는 5점을 줍니다. 그런데, 마음에 들지 않는 책을 읽었을 때는 굳이 리뷰를 쓰지 않습니다. 모든 사람들이 저와 같이 점수를 준다면 4/5점대는 많은 데이터가 있는데, 1/2점대는 적은 데이터만 쌓여서 사용자의 선호를 명확히 구분하지 못해서 제대로된 추천이 불가능합니다. 뿐만 아니라, 사용자마다 점수 스케일이 다르다는 점입니다. 누구는 '그저그럼'이 3점이 될 수 있고, 다른 이는 4점이 될 수도 있습니다. 그리고 같은 유저더라도 상황에 따라서 다른 점수 스케일을 사용하는 점도 문제가 될 수 있습니다. 기분이 좋을 때는 4/5점을 남발하다가 기분이 나쁠 때는 1/2점을 줄 수도 있습니다. 이런 사용자 바이어스를 줄이고, 일관성에 맞도록 조정하는 방법도 연구의 한 축입니다.

명시점수에 노이즈가 많기 때문에, 최근에는 그냥 암묵점수를 사용하는 경우도 많아졌습니다. 명시점수에 비해서 더 많은 데이터를 확보할 수 있다는 것이 가장 큰 장점입니다. 명시점수에 비해서 선호도를 제대로 표현할 수 없다는 단점이 있지만, 이는 암묵점수를 어떻게 해석하느냐에 따라서 어느 정도 극복도 가능합니다. 특정 제품을 조회했으면 1, 아니면 0으로 구분하는 것이 아니라, 특정제품이 노출되었지만 조회하지 않았다면 -1, 노출되지 않았다면 0점, 조회했으면 1점, 그리고 구입까지 했다면 2점을 주는 식으로 레이팅을 달리할 수 있습니다.

추천 시스템에서 데이터와 관련해서 해결해야할 가장 큰 문제점은 데이터의 크기 data dimensionality 문제입니다. 넷플릭스의 유저 레이팅도 몇십억건이 넘는다고 합니다. 그런데 앞서 말했듯이 다양한 메타데이터를 사용해서 새로운 축이 생기면 더 큰 문제를 야기할 것입니다. SVD 기반의 Matrix Factorization에서는 로컬 데이터를 업데이트하는 방식으로 데이터의 스케일문제를 해결하기도 합니다. 최근에 많은 주목을 받고 있는 Big Data 기반으로 문제를 해결하기도 합니다. 그런데, 하둡 Mahout에 들어있는 CF를 사용해서 테스트를 진행해봤는데, 데이터 사이즈가 별로 크지도 않았는데 사용된 유사도에 따라서 메모리 문제가 발생하기도 했습니다.

이상의 유저레이팅은 보통 협업필터링 Collaborative Filtering에서 기본적인 데이터입니다. 여기에 더해서 Content-based Filtering (CBF)를 위해서 다양한 메타데이터도 사용이 가능합니다. 영화를 예로들면 특정 영화의 장르, 스태프나 출연진, 내용/줄거리 (에 사용된 키워드 등)이 메타데이터로 사용되고, 이들을 기준으로 관련 영화 (아이템)을 묶어서 추천해줄 수도 있습니다. 그리고 사용자에 대한 데이터도 사용됩니다. 사용자의 특성 (성별, 나이, 지역, 직업 등)에 따라서 제품에 대한 선호가 다른 경우가 많기 때문에 사용자 데모그래픽에 따른 그룹화 및 그룹별 추천도 가능합니다.

트위터나 페이스북의 성공으로 소셜관계 데이터는 최근에 가장 흔하게 사용되는 데이터 중에 하나입니다. 친구 또는 내가 선호하는 (팔로잉) 사람의 글이나 의견을 보여주는 형태입니다. 소셜 데이터가 추천에서 별 효과가 없다는 연구결과도 많지만, 적어도 추천의 신뢰도를 높여주는데는 효과가 있다고 합니다. 즉, '네 친구 XX가 추천한 글이야' 식으로 추천의 이유를 설명해주면, 추천된 글/제품이 별로더라도 결과를 이해하고 넘긴다는 것입니다. '너와 비슷한 누군가의 추천이야'보다는 '네가 알고 있는 누구의 추천이야'가 더 설득력이 있다는 얘기입니다.

간단하게 설명될 것같았는데, 의외로 글이 길어졌습니다. 여전히 추천에 필요한 데이터를 충분히 설명하지 못했습니다. 후속 글들에서 필요한 설명은 추가하겠습니다.

추천시스템 전체 목록

  1. 추천 시스템과의 조우 (PR시리즈.1)
  2. 추천 시스템을 위한 데이터 준비 (PR시리즈.2)
  3. 추천대상에 따른 추천 시스템의 분류 (PR시리즈.3)
  4. 알고리즘에 따른 추천 시스템의 분류 (PR시리즈.4)
  5. 추천 시스템을 위한 유사도 측정 방법 (PR시리즈.5)
  6. 추천 시스템의 성능 평가방법 및 고려사항 (PR시리즈.6)
  7. 추천 시스템에서의 랭킹과 필터링 문제 (PR시리즈.7)
  8. 추천 시스템의 쇼핑하우 적용예 (PR시리즈.8)
  9. 개인화 추천 시스템에 대하여 (PR시리즈.9)
  10. 추천 시스템의 부작용 - 필터버블 (PR시리즈.10)
  11. 추천 시스템의 레퍼런스 (PR시리즈.11)
  12. 추천 시스템에 대한 잡다한 생각들 (PR시리즈.12)
  13. 추천 시스템을 위한 하둡 마훗 사용하기 (PR시리즈.13)
  14. 추천 시스템에 대해서 여전히 남은 이야기들 (PR시리즈.14)

==

페이스북 페이지: https://www.facebook.com/unexperienced

댓글을 달아 주세요

문제와 해법

Gos&Op 2013.11.25 19:29 |
Share           Pin It

페이스북에 짧게 적었던 글을 좀 길게 적습니다.

---

지난 밤에 읽은 책에서 (전체 내용과 관계가 적으므로 책 제목은 생략합니다) "과학자는 해법을 찾은 뒤에 그것을 적용할 문제를 고민하는데 반해, 엔지니어는 문제를 규정한 이후에 해법을 찾는다는 차이가 있다"라고 적혀있었다. 순수학문과 응용학문의 차이를 잘 설명해준다.

똑같지는 않지만 비슷한 고민을 오랫동안 해왔다. 나는 또는 내가 속한 팀은 기술 스택에 집중해서 다양한 기술을 연마하거나 알고리즘을 개발해서 서비스 분야에 접목을 시켜야 할지 아니면 서비스 스택에 더 집중해서 도메인/비즈니스 지식을 쌓은 후에 다양한 기술/알고리즘을 차용해서 현재의 문제를 해결해야 할지를 결정해야 했다. 현재 이도저도 아닌 어중간한 상태에 머물러 있어서 갈피를 못잡고 표류하고 있는 듯하다.

인터넷 서비스 회사를 다니는 사람들이라면 비슷한 고민을 하고 있을 것이다. 매일 새로운 기술이 쏟아지고 트렌드는 급변하는 상황에서 기술적 완성도도 어정쩡하고 서비스의 디테일도 어정쩡한 상태에 이른 경우가 많을 것이다. 기술에 집중하자니 발등에 떨어진 불이 너무 커고, 그렇다고 발등의 불부터 꺼자니 시대에 뒤떨어지는 악순환이 이어진다. 작은 조직에서는 이 둘을 동시에 해결해야하기 때문에 어렵다. 그러나 웬만큼 큰 조직에서는 팀별로 성격을 나눠서 전문성을 가질 수 있고, 또 가져야 한다. 그래야지 기술 스택과 서비스 스택이 명확히 세워지고, 필요에 따라서 서로 결합해서 새로운 것을 창조할 수가 있다.

우리 팀의 핵심이 뭘까?를 항상 고민한다. 윗선에서 제대로 된 비전을 보여준다면 그것을 믿고 따르면 되겠지만, 최근 분위기가 녹록치가 않다. 그렇기에 혼자서 고민하는 것같다. 팀의 정체성은 팀이 맡고 있는 서비스일까 아니면 팀이 가지고 있는 기술/지식일까? 팀의 core competence가 뭘까를 고민하게 된다. 팀의 핵심 역량을 정하고 그것을 극대화시킨 이후에, 다른 영역에 적용을 하거나 아니면 다른 영역의 기술을 차용해야 방향이 잡힌다. 그러나 그러지 못하는 경우가 허다하다. 실질적으로 대부분이 그럴 것이다.

확실한 기술을 가지고 있으면 웬만한 문제에는 적용이 가능하고, 또 괜찮은 서비스/문제를 쥐고 있으면 또 다양한 기술들을 적용해볼 수가 있다. 그렇기에 (큰) 조직에서는 기술스택과 서비스스택을 명확히 구분해서 서브유닛별로 명확히 할 필요가 있다. 그리고 특화된 유닛끼리는 문제/상황에 맞도록 적절히 조화를 이뤄서 새로운 서비스를 만들어내거나 당면한 문제를 해결할 수가 있어야 한다.

(개인적으로) 스페셜리스트보다는 제너럴리스트를 더 선호하지만, 한두가지의 스페셜한 기술이 없는 제너럴리스트는 결국 허상을 쫓게 되고, 역으로 일반적인 시각이 없는 스페셜리스트도 그 길이 잘못되었다고 (늦게) 판명이 나면 필망에 이른다.

올바른 해답은 올바른 문제/질문에서 시작된다. 물론 문제가 옳다고 해서 옳은 해답을 찾는다는 보장은 없다. 그러나 잘못된 문제에서 옳은 해답을 찾을 수는 결코 없다. 그렇다면 올바른 문제부터 찾아야 하는 걸까? (기술에 특화된 조직이 아닌 또는 원천기술이 없는) 작은 조직이라면 문제를 먼저 찾아야 한다. 투명하게 정보 (지식)가 공유되는 요즘 시대에, 문제가 잘 정의되면 적당한 답을 찾는 것은 별로 어렵지가 않다. 그러나 그런 경우 자기만의 해답을 찾지 못할지도 모른다.

저의 개인적인 성향은 서비스 오리엔테이션입니다. 그리고 요즘은 데이터 사이언스라고 부르기도 하지만, 현실에서 데이터마이닝은 데이터 엔지니어링에 더 가깝고, 그래서 비즈니스/도메인 지식과 데이터 자체에서 오는 인사이트가 많이 필요합니다. 그러나 좀더 사이언스적인 접근을 해보고 싶다는 욕구도 있습니다. 팀 자체의 아이덴터티가 예전과 많이 바뀐 상황에서 여전히 한두개의 서비스에만 매여있으면 안 될 것같습니다.

글을 적다보니 논점이 자꾸 흐려진다. ... 어쨌든 현재 나 또는 우리 팀은 해법을 찾는 것에 집중해야 한다고 생각한다. 그러나 분위기가 그렇지 못 하다.

페이스북 페이지: https://www.facebook.com/unexperienced

댓글을 달아 주세요