본문 바로가기

DM ML AD

딥 개인화에서 해결해야할 문제들...

지난 글에서 워드임베딩에 대한 생각을 정리하고 딥러닝과 결합해서 개인화 추천에 어떻게 적용할 것인가에 대한 간단한 스케치를 올렸습니다. (참고. 워드임베딩: http://bahnsville.tistory.com/1139, 개인화 추천: http://bahnsville.tistory.com/1141) 오늘은 그런 기술을 딥 개인화 시스템에 적용할 때 예상되는 문제점들에 대해서 생각나는대로 정리하려 합니다.

지난 글에 제시한 딥 개인화 아키텍쳐를 간단히 설명하면 다음과 같습니다.
  1. 텍스트, 이미지, 또는 웹로그 등의 유저 및 아이템 정보/이력에 포함된 개별 항목들을 워드임베딩 기술로 벡터화한다.
  2.  유저/아이템의 정보를 RNN이나 CNN 등으로 정형화된 벡터로 압축한다.
  3. 정형화된 유저벡터와 아이템벡터의 관계를 유저-아이템 interaction log로 학습한다.
  4. 학습된 Latent Vector로 유저-유저, 아이템-아이템, 유저-아이템의 연관도/유사도를 측정한다.
유저-아이템 행렬을 팩토라이즈하는 것이 가능하지만 그것보다 풍부한 유저/아이템 정보를 이용해서 바로 유저/아이템 벡터를 만들 수 있다면 1과 2는 하나의 과정으로 봐도 무관합니다.

위의 과정에서 3과 4는 통상의 ANN 학습방법이나 유사도 연산으로 쉽게 해결되는 부분입니다. 특히 3의 학습에 대한 아이디어는 지난 글에 간략히 언급했습니다. 하지만 1과 2의 Knowledge Representation은 오랫동안 고민했지만 쉽게 답이 나오지 않았습니다. 예전부터 워드임베딩 기술을 사용하면 될 것 같다는 막연한 생각을 가지고 있었지만 따로 공부하지 않아서 더이상 진도가 안 나갔는데, 최근 관련 분야를 공부하면서 가능성을 확인했습니다. 하지만 실제 문제에 적용하는 데는 여전히 해결해야할 장애물들이 많이 있습니다. 공부하면서 여러 힌트는 얻었지만 유저/아이템 벡터로 컨볼루셔한하는 실용적인 방법을 찾지 못했습니다. 워드임베딩 부분과 컨볼루션 부분을 나눠서 예상되는 문제를 정리합니다. 짧은 식견으로 떠오른 어려운 점들이지만 저보다 띄어난 분들은 별로 문제될 것이 없다고 보실 수도 있고 또 많은 연구자들이 관련된 해결책을 이미 내놓은 경우도 많습니다.

워드임베딩
기계학습이라는 것이 최초의 학습데이터로 모델을 만들어두면 영구적으로 사용할 수 있는 것이 아닙니다. 실제 운영하면서 새로 추가되는 데이터로 주기적으로 모델을 업데이트해줘야 합니다. 새로운 데이터가 추가될 때 모델의 구조가 바뀌지 않으면 단순히 (hyper-)파라메터들만 업데이트해주면 되겠지만, 워드임베딩의 경우 모델의 구조가 함께 바뀌기 때문에 전체 모델을 새롭게 빌딩하고 관련된 시스템 전체를 바꿔줘야 합니다. 새로운 텍스트에는 기존 학습 데이터에는 없던 신조어가 있습니다. 보통 OOV (out-of-vocabulary)라는 특수한 태그로 처리하지만, 데이터 양이 많아지면서 모든 신조어를 OOV로 처리할 수도 없고 중요한 신조어는 새롭게 사전에 추가해야 합니다. 기존 사전에 10,000개의 단어가 있었는데, 여기에 한개의 단어를 더 추가하는 것은 별 문제가 안 될 것 같지만, one-hot encoding에서 데이터 차원을 1만큼 증가시켜야 하고 그에 따라서 전체 가중치 W를 재계산해야 합니다.

일반적인 텍스트 문서 분석의 경우 몇달, 몇년치의 데이터를 모으더라도 추가되는 신조어의 수가 기존 사전 사이즈에 비해서 별로 크지 않아서 오랜 기간동안 OOV로 처리해도 시스템의 예측력에 큰 해를 주지 않습니다. 하지만 대형 쇼핑몰에서 상품을 추천해주는 경우라면 매년 추가되는 신상품의 수도 많을 뿐더러, 핫한 추천 대상이 돼야할 신상품을 사전에 추가하지 않을 수가 없습니다. 일반적인 텍스트 컨텐츠로 확대해서 유저의 검색쿼리나 방문했던 사이트를 기반으로 추천하겠다고 가정한다면, 매일 기존에 없던 수많은 새로운 패턴의 검색어가 등장하고 뉴스 기사만 하더라도 매일 수천건 이상이 새로 생깁니다. (새로운 문서 = 새로운 URL) 해외의 뉴스도 포함하고 블로그 등의 소셜미디어를 고려한다면 매일 추가되는 신종 아이템이 넘쳐납니다. 즉 사전 사이즈가 감당할 수 없을만큼 커지고, 그에 따라서 매번 모델을 새로 구축해야 합니다.

컴퓨팅 파워가 받쳐주더라도 학습 데이터를 무작정 누적해서 사용할 수도 없습니다. 오래된 것은 버리고 새로운 데이터로만 학습할 필요가 생깁니다. 신조어가 생기듯이 필요없어지는 단어가 생깁니다. 즉, 사전에서 빼주는 작업이 발생합니다. 사전의 구조가 바뀌면 당연히 모델을 새로 학습해야 합니다. 그리고 미리 정의된 사전이 아니라 매번 학습 데이터 (텍스트)에서 사전을 동적으로 구축하는 경우라면 모델 재구축은 필수입니다. 모델을 학습하는 것은 모델을 기반으로 예측하는 것에 비해서 리소스가 많이 들어가는 작업입니다. 그래서 재구축 주기를 너무 짧게 가져갈 수도 없습니다. 또 주기가 길어지면 OOV가 증가합니다. 상품이나 컨텐츠 추천에서는 OOV에 해당하는 신상이나 최신글이 가장 중요할텐데, 업데이트 주기를 기다리는 동안에는 유저의 프로필 (관심사)에 반영하지 못하는 어처구니없는 상황이 발생합니다.

그리고 이건 실제 작업해봐야 알겠지만, 사전 사이즈를 어느 수준까지 크게 가져가도 컴퓨팅이나 전체 시스템 성능에 영향을 주지 않을 것인가도 고민이 됩니다. 옥스포드 영어 사진에 약 17만건의 영단어가 등록돼있다고 합니다. 인터넷에서의 유저가 한 행동 이력으로 유저 프로파일을 만든다면 다양한 조합의 검색어, 접속했던 문서 (URL), 웹에서의 다양한 활동 등을 모두 사전에 추가한다면 세상의 모든 언어가 가진 단어의 수보다는 가늠할 수 없을만큼 훨씬 많아질텐데, 과연 그런 규모의 사전을 워드임베딩하는데 저비용으로 가능할까에 대한 의문도 듭니다. 여지껏 전체 웹 단위에서 상상을 펼쳤기 때문에 무모한 논쟁이기도 합니다. 각자 서비스 내에서의 추천/개인화를 위해서 데이터의 종류와 양을 잘 제한하면 이건 그저 기우일 뿐입니다. (학교에 있을 때는 웹 전체의 문서를 클러스터링해보고 싶다는 막연한 생각을 했었는데, 여전히 그런 버릇에서 못 벗어난 듯...)

사전에 색인된 단어 순서가 바뀌지 않고 상대적으로 적은 양의 신조어가 추가만 된다면 (또는 일부 불필요한 단어가 색인 순서는 그대로 둔 채 제외한다면) 가능한 기존의 워드임베딩 결과를 유지하면서 새로운 사전을 학습시킬 수 없을까에 대한 고민도 있습니다. 예를 들어, 원래 사전이 {A, B, C, D, E, F, G, H, I, J}로 총 10개의 단어로 구성됐는데, 신조어 K가 추가돼서 {A, B, ..., J, K}로 11개로 변경됐다고 가정합니다. 원래 사전에서 A는 [1 0 0 0 0 0 0 0 0 0]' (0이 9개)로 one-hot 인코딩으로 표현할 수 있고, 이를 워드임베딩했을 때 결과가 [0.7 0.5 0.9]가 된다면, 새로운 사전에서 A는 [1 0 0 0 0 0 0 0 0 0 0]' (0이 10개)로 표현하고 그 워드임베딩 결과가 기존의 [0.7 0.5 0.9]와 크게 다르지 않게 학습시킨다면 어느 정도의 신조어가 사전에 추가되더라고 굳이 기존의 모든 단어들을 재계산할 필요가 없어지고, 기존 단어들로만 구성된 유저/아이템 벡터는 별도 업데이트가 필요치 않을 수도 있겠다는 생각도 듭니다. 하지만, 어차피 신조어의 벡터를 구하기 위해서 전체 단어의 재학습 및 결과는 함께 진행되기 때문에 조금 불필요한 고민이었던 것 같습니다. 하지만 외부 환경이 조금 변경됐을 때 굳이 전체 시스템에 영향을 주지 않는 robust한 방법에 대한 고민은 여전히 필요합니다.

컨볼루션
지난 글에서 소개했던 Collobert의 논문을 보면서 처음에는 컨볼루션으로 유저 및 아이템 벡터를 쉽게 만들 수 있겠다는 생각을 했습니다. (참고 논문: http://www.jmlr.org/papers/volume12/collobert11a/collobert11a.pdf하지만 텍스트 문장에 적용했던 기술을 유저 및 아이템 프로파일에 그대로 적용하는 데는 문제가 있음을 바로 깨달았습니다. 텍스트 문장 (문서가 아님)은 보통 1~20단어로 구성돼있고, 많아봤자 100단어를 넘지 않습니다. 일단 단어의 개수가 많지 않고 개수의 분포도 (상대적으로) 일정하다고 볼 수 있습니다. 추천할 아이템 (컨텐츠)의 프로파일은 다소 길겠지만 길이에 제한이 있습니다. 하지만 유저 프로파일의 경우 쉽게 가늠이 되지 않습니다. (사용자가 입력한 검색쿼리, 접속한 URL 등을 모두 한 단어로 가정함) 두가지 포인트를 지적했는데, 프로파일의 길이가 길다는 것과 길이의 편차가 크다는 것입니다. 길이가 길더라도 편차가 적다면 복잡하더라도 하나의 scheme으로 압축할 수 있을텐데, 길이가 천차만별이면 고민이 깊어집니다. 큰 이미지라면 강제로 사이즈를 줄이고 원하는 비율로 crop해서 사용하면 되는데, 텍스트 문서는 이런 방식이 불가합니다.

앞의 논문에서는 인접한 단어 벡터 (워드임베딩)들을 컨볼루션하고, 컨볼루션된 것들 중에서 각 열의 최대값 (max-pooling)을 취합니다. 단어의 수가 별로 많지 않기 때문에 max-pooling을 하더라도 다양한 결과값이 만들어집니다. 하지만 단어가 많아지면 각 행의 max값들이 모두 비슷해질 가능성이 높아집니다. 예를 들어, [0 1] 사이의 랜덤 넘버 10개 중에서 max값은 1.0이 될 수도 있지만 0.7이나 0.8, 심지어 0.1도 될 가능성도 꽤 있습니다. 하지만, 10,000개의 랜덤 넘버 중에서 max값을 취하면 대부분 0.9 ~ 1.0이 될 것입니다. 문장 단위에서 convolution+max-pooling이 잘 동작하더라도 문서 (유저의 행동 이력) 단위에서는 불가능하다는 것입니다. 즉, 결과 유저 벡터들이 모두 유사해지고, 추천의 variance가 없어진다는 의미입니다. 문서의 길이가 길더라도 길이가 일정하면 동일한 조건으로 큰 컴볼루션 window 사이즈를 취하거나 여러 겹의 컴볼루션 레이어를 두는 식으로 해결책이 존재하겠지만, 길이가 일정하지 않으면... 어떤 논문을 보면 varying-size convolution filter를 사용하는 경우가 있어서 컨볼루션을 잘 설계하면 돌파구가 있을 듯도 합니다. (참고. https://arxiv.org/pdf/1604.06338.pdf) 부트스트랩하듯이 그냥 임의의 벡터를 선택해서 컨보루션 & 풀링하는 것도 생각해봤지만 이건 그냥 애초에 입력 데이터를 랜덤하게 선택해서 진행하는 것이 더 나을 것이고, 알고리즘의 일관성을 확보할 수가 없습니다. (역으로 짧은 입력 데이터를 임의로 확장하는 것도 별로...) Pooling층에서 같은 위치의 벡터 엘리먼트 sequence를 time series로 가정하고 wavelet (Fourier Transformation)으로 pooling하는 것도 가능하지 않을까?라는 생각도 듭니다.

유저의 행동 이력을 시간순으로 나열해서 RNN을 이용하는 방법도 생각해봤습니다. RNN이 CNN보다는 길이의 가변성에 더 유연합니다. 하지만 RNN도 문장이 아닌 문서 단위에서도 제대로 동작할지 의문이 듭니다. RNN은 개념적으로 이전까지의 결과 (이전의 모든 단어의 sum)과 현재 단어를 일종의 weighted sum하는 것입니다. (개념적으로 설명하면 그렇다는 것임) 이런 추론에 따르면 최신 행동 이력에 가중치를 부여하는 방식이라는 장점이 있지만, 역으로 과거 이력을 무시해버릴 가능성도 있어 보입니다. 예를 들어, 어떤 유저가 '제주도, 제주도 맛집, 제주도 펜션, ...., 제주도 항공권' 등의 키워드로 95회 검색하고 가장 마지막에 '포켓몬 고' 관련해서 5회 검색했다면 이 유저의 관심사가 제주도 여행보다 포켓몬 고로 표현될 가능성이 있습니다. 실제 RNN이 이런 식으로 작동하지 않겠지만, 통상의 RNN의 구조로 유추하면 그렇다는 것입니다. 최근 RNN에서 많이 사용하는 LSTM을 사용하면 또 다른 가능성이 있지 않을까라는 또 기대를 걸어봅니다. (LSTM을 설명한 번역글: http://whydsp.org/280) LSTM를 포함한 텍스트 또는 시퀀스 데이터를 위한 딥러닝 기술을 좀더 공부해봐야겠습니다. 아직 읽어보지는 않았지만 word2vec을 만든 Mikolov가 공저자로 참여한 논문 (http://cs.stanford.edu/~quocle/paragraph_vector.pdf)은 문장/문서의 paragraph vector를 만드는 걸 제안했고, Weinberger et al.은 feature를 hashing하는 방법도 소개했습니다 (https://arxiv.org/pdf/0902.2206.pdf). 여러 논문들을 훑어봤지만 아직 만족스럽지가 않습니다. 만족할 솔루션을 찾았다면 이런 글을 적지도 않았겠지만...

길이가 다소 일정한/제한적인 아이템 벡터보다는 가변적이고 긴 유저 벡터를 만드는 것이 고민이라고 적었습니다. 그런데 문제가 되는 유저는 전체 중에서 극히 일부 (10%미만?)에 해당하는 헤비 유저들 가능성이 큽니다. 이들 일부 유저 데이터만 제한하면 전체 시스템 측면에서는 이점이 있을 수 있습니다. 가장 쉬운 방법으로는 최근의 T기간 또는 N개의 최근 데이터만 사용할 수 있습니다. 추천에서는 최신 데이터에 대한 민감도가 중요하기에 쉽지만 괜찮은 방법입니다. 하지만 헤비유저의 과거 이력에 나타난 오래된 관심사를 반영하지 못할 수도 있다는 우려도 있지만, 오래된 관심사라면 최근 행동에도 반영됐을 가능성도 높고 또 고정 관심사와 연관된 새로운 행동을 통해서 빠르게 업데이트된다면 freshness를 고려하면 헤비유저의 반감이 적을 수도 있겠다는 생각이 듭니다. 그리고 만약 고정된/오래된 관심사라면 이 글에서 제시한 방법에 더해서 별도의 필터링을 위한 유저 관심사 (또는 성별, 연령과 같은 고정된 정보)를 구축해서 하이브리드/퓨젼으로 추천 및 필터링하는 것도 가능합니다.

랜덤 샘플링을 통해서 제한된 정보만 사용하는 것도 고려할 수 있습니다. 모든 물고기를 잡을 수 없다면 큰 물고기라도 잡아야 한다. (어차피 다양한 오프라인 테스트와 온라인 A/B 테스트를 통해서 generalization error가 적은 방식을 택하면 됩니다.) 앞서 소개한 Phan et al.의 논문에서 varying-size 컨볼루션 필터 방식 등을 더 고민해보면 좋은 해결책이 나오리라고 봅니다. 그리고, session이나 period (day-by-day)를 나눠서 별도의 컨볼루션을 만들고 그것들을 다시 컨볼루션해서 최종 벡터를 만들어내는 방식 (또는 세션 단위로 recurrent하는 방식)도 가능성이 있습니다. 또는 임베딩 벡터로 유사도 계산, 클러스터링, 및 topic modeling 등을 통해서 데이터를 축소하는 것도 좋은 접근법입니다. 작은 문제에서 은닉층을 2개 이상 가져가는 것도 버거웠던 시절이 있었지만 지금은 입력 데이터의 차원도 훨씬 커졌고 은닉층의 개수도 훨씬 많아져도 딥러닝을 성공하게 만든 breakthrough가 있었듯이, 이 문제/해결책도 좀 복잡해졌지만 조만간 깔끔하게 해결되리라 봅니다.

그리고, 저는 광고랭킹을 염두에 두고 가능한 유저의 모든 정보와 이력을 모아서 활용하겠다는 관점에서 생각하고 있지만, 특수한 서비스를 위한 추천이라면 데이터의 종류와 양이 충분히 다룰 수 있을만할 거라 봅니다. 광고에서는 유저가 어떤 서비스에서 어떤 활동을 했고 또 어떤 컨텐츠를 조회했는지 등의 모든 정보를 바탕으로 유저 프로파일을 만들어 활용하겠지만, 일반 쇼핑몰에서 상품을 추천하는 경우라면 기존의 CF 등에서 활용하는 수준의 유저별로 조회한 상품 목록만으로도 충분합니다. 자신이 속한 비즈니스 도메인 및 가용 데이터에 따라서 손쉬운 해결책이 존재하고, 이상의 고민이 불필요할 수도 있으니 새로운 접근법을 지나치게 거부할 필요가 없습니다. 서비스/비즈니스 도멘인을 한정하듯이 유저 정보의 종류를 한정하는 것도 방법이 될 수 있습니다. 유저가 검색한 쿼리만으로 유저벡터를 만들겠다거나, 개별서비스에서 정의한 카테고리 (공통의 카테고리일 필요는 없음)의 리스트만 활용하겠다거나, 긴글을 조회한 경우나 댓글 등의 조회 이상을 한 액션이뤄진 URL만을 대상으로 삼는다거나 등의 여러 제약 조건을 데이터를 한정할 수도 있습니다. 제가 이 글에 적었다고 해서 모든 방법이 유효하다는 것은 아닙니다. 단지 생각나는 것을 나열한 것입니다.

지금 바로 내 눈 앞에 보이지 않을 뿐이지 나와 비슷한 문제로 고민했던 수많은 연구/개발자들이 존재하고 있으니 일부는 이미 깔끔한 해결책을 찾아서 알려주고 있습니다. 미래는 이미 우리 곁에 와있지만 인식하지 못할 뿐이다라는 문구와 같이 많은 경우에 우리가 가진 문제의 해결책도 이미 누군가가 풀어놨는데 제대로 인지하지 못하고 있을 뿐입니다. 아직 검증하지도 않은 이런 아이디어를 글로 적는 것도 누군가에게 해결의 실마리를 줄 수 있지 않을까?라는 기대 때문이고, 이를 바탕으로 더 좋은 아이디어로 문제를 해결하고 그 과정과 결과를 논문이나 코드 등으로 공개한다면 조금은 더 좋은 세상이 되리라 기대합니다. 제 생각은 완벽한 해결책도 아니고 논의의 시작점도 아닙니다. 그저 이런 논의의 과정으로 더 많은 문제들의 해결책이 나왔으면 하는 바람일 뿐입니다. 그래서 때론 어리석은 생각도 적고 또 공개/공유하는 것입니다.

===


반응형