Share           Pin It
지금으로부터 10년 전인 2006년 10월 2일에 우편으로 DVD를 렌탈하는 미국 업체인 넷플릭스 Netflix에서 많은 이들을 깜짝 놀라게하는 발표를 했다. 2006년도 기준으로 자사가 보유하고 있던 방대한 양의 사용자들의 영화 평점 데이터를 공개하고, 자사의 추천 알고리즘의 정확도보다 10%이상 향상시킨 알고리즘을 개발한 팀에게 상금으로 $1M을 주겠다는 발표한 것이다. 이른바 Netflix Prize 또는 Netflix Contest로 알려진 대회의 시작을 알린 것이다를. 당시만 하더라도 이제 겨우 우편 렌탈에서 온라인 스트리밍다운로드로 넘어가던 초기였다는 것을 감안하면 더욱 놀라운 일이다.

1백만달러 (한화로 약 10억원)의 상금 규모도 놀라웠고, 또 그들이 공개한 평점 데이터의 양도 놀라웠다. 학교에 있으면 신뢰할만한 충분한 양의 데이터를 확보하는 것이 매우 어려운데, 넷플릭스에서 공짜로 아니 상금까지 내걸면서 공개한 것이다. 2006-7년도는 학교에서 추천 알고리즘으로 논문을 한참 적고 있던 시절인데, 당시에 구할 수 있는 추천 데이터는 겨우 수천명의 사용자가 수백개의 아이템을 평가한 것이 전부였다. 일부 불필요한 데이터를 제거하고 나면 겨우 몇 만에서 몇 십만의 평가 데이터만 구할 수 있던 시절에, 1억건이 넘는 평가 데이터를 공짜로 얻는다는 것은 큰 행운이었다. 상금뿐만 아니라 양질의 데이터를 얻을 수 었기 때문에 세계의 많은 학자들이 넷플릭스 프라이즈에 뛰어들었다.

참고로 약 48만명의 사용자가 1.8만개의 영화에 대해서 5-star 평점 (rating)을 매긴 약 1억건의 데이터를 공개한 것이다. (참고. https://en.wikipedia.org/wiki/Netflix_Prize) 넷플릭스 프라이즈에서 RSME로 10%를 향상시키는 알고리즘을 찾겠다는 평가 방식에 문제가 없는 것은 아니나, 이 글에서는 별로 중요한 이슈는 아니다.

돈의 가치가 많이 떨어졌다고는 하지만 1백만 달러 (약 10억원)은 여전히 큰 돈이다. 넷플릭스 내에도 똑똑한 개발자들이 많이 있을테고, 추천 시스템으로 유명한 몇몇 대학 연구실과 협업을 하면 더 적은 돈으로 충분히 괜찮은 알고리즘을 만들 법도 했지만, 얼핏 보기에 넷플릭스가 무모한 선언을 한 것처럼 보였다. 물론 대회를 선언했기 때문에 그동안 추천 시스템과 무관한 일을 했던 수학자나 데이터 사이언티스트들을 추천 문제에 눈을 돌리도록 했고, 또 3년만인 2009년 6월에 RSME를 10%이상 향상시킨 알고리즘을 얻을 수 있었다. 어느 사기업의 돈으로 인류 전체에 혜택이 돌아가는 연구가 발전한 셈이다.

그래도 최근까지 1백만 달러는 과했다고 생각했었다.

그러나 다른 (마케팅) 관점에서 생각해보면 넷플릭스는 1백만 달러라는 푼돈으로 더 큰 것을 얻었다고 생각한다. 2006년도 이후에 발표되는 수많은 추천 관련 논문이나 인터넷 포스팅들에서 넷플릭스 프라이즈를 필히 언급한다. 단순히 기업의 브랜드 광고를 위해서도 수억원의 광고비를 책정하는데, 수많은 권위있는 논문, 기사, 그리고 블로그 등에서 10년이 넘도록 넷플릭스를 여전히 언급하고 있다. 아마존 등의 기업도 추천 알고리즘으로 유명하지만, '추천 = 넷플릭스'라는 인식을 많은 사람들에게 심어준 것이 넷플릭스 프라이즈라고 본다. (물론 저같이 IT 및 DT 분야에 종사하는 사람들과 일반인들의 인식에는 조금의 차이가 있겠지만...)

만에 하나 넷플릭스 프라이즈 (RSME 10% 향상)가 실패했더라도, 아니 전혀 정확도 개선이 없었더라도 넷플릭스는 남는 장사를 했다고 본다. (실패했다면 $1M을 세이브했을테니, 홍보만 왕창했으니 손도 안 대고 코를 푼 격)

오픈 소스를 공개하고 활용하는 것은 오랜 관행이었지만 데이터를 공개하고 쉽게 접근할 수 있게 해주는 것은 흔치는 않았다. 실리콘밸리의 유수의 기업들이 그들의 핵심 역량을 계속 공개하고 있고 최근에는 국내의 네이버마저 데이터랩을 오픈하는 것을 보면 10년 전에 넷플릭스한 결단은 그저 놀랍다. 보통 방향을 잘 모른다는 것이 문제지만, 방향이 맞다면 얼핏 보기에 조금 과하다 싶을 정도로 지르는 것도 결국은 남는 장사인 것 같다.

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


댓글을 달아 주세요

Share           Pin It
사람들은 5월 초에 있었던 다음 카카오 합병 소식에는 관심을 가지지만, 5월 말에 있었던 어떤 서비스 오픈에는 별로 관심을 보이지 않고 있다. 그도 그럴 것이 그게 현재 다음의 처지를 그대로 보여준다. 완전히 새로운 서비스도 아니고 기존의 페이지에서 한 구좌에 조금 노출되는 수준이니 열혈 사용자가 아니면 (지금은 그런 사용자도 많지 않다) 눈치를 못 챘을 가능성도 높다. 트위터에 해당 서비스명으로 검색해봐도 서비스 개발자는 아니었지만 그 팀에 속한 어떤 분이 간단히 소개하는 정도의 트윗이 올라와있고, 다른 하나는 고맙게도 다음과 같은 글이 올라와있다.


여러 측면에서 이게 무서운 서비스일 수는 있지만, 현재 다음을 생각하면 (그리고 당장의 지표를 보면) 그렇게 두려운 서비스는 아니다.


어쨌든 이 서비스에 메인으로 참가했던 자로써 서비스 1차 오픈 후에 간단한 소회를 밝히는 것이 맞을 것같아서 글을 적는다. 서비스의 시스템 아키텍쳐는 다른 분들이 담당했고 본인은 추천 알고리즘에 주력했다. 그래서 시스템 개발에 사용된 기술이나 방법은 설명할 수가 없고, 그리고 알고리즘은 처음에 구상했던 것이 아직은 완벽하게 적용돼있지도 않고 다른 여러 이유로 자세히 밝힐 수도 없는 처지라서... 그리고 기본적인 추천 알고리즘은 이미 여러 편을 통해서 밝혔고, 그 글에서 다룬 것과 크게 다르지도 않다. 서비스 우상단에 보이는 도움말에도 짧게 설명돼있지만, 그 설명이 전부이면서도 아무 것도 설명해주지 못한다. 자세한 설명은 추후에 여러 가지가 클리어된 후에 다시 적는 것이 나을 듯하다.

시스템이나 알고리즘에 대해서 자세히 설명하지도 않을거면서 뭐하러 이런 글을 적느냐고 반문하겠지만, 이 글은 1차 오픈 후에 느낀점을 정리해서 혹시나 비슷한 환경에서 고군분투하시는 분들에게 참고가 되라고 적는다.

먼저 밝히지만, 서비스를 오픈한 후에 여러 지표들이 기대했던 것에 많이 못 미친다. 폭발적인 UV나 PV가 발생하지 않는다는 얘기다. (내 기대치가 그랬다.) 여러 핑계거리가 있지만 어쨌든 결과가 신통치 않다는 점만 밝힌다. 그래서 며칠동안 계속 우울한 나날을 보내고 있다. 매일 지표를 확인하면 우울해진다. 일간 지표를 확인하면 하루마다 우울해지고, 시간 지표를 확인하면 매시간이 우울해지고, 분단위 지표를 확인하면 실시간으로 우울해진다. 의미있고 가치있는 서비스를 만들었다고 자부하면서도, 수치에 민감해진다.

사내 위키에 적었던 오픈 후의 소감과 심경을 다시 정리한다.

서비스의 오픈이 프로젝트의 시작이다. 대부분의 경우 프로젝트가 시작되면 서비스 오픈을 향해서 달려간다. 그리고 서비스가 성공적으로 (과연 뭐가 성공일까?) 오픈하면 모든 것이 끝난 기분이다. 그리고 실제 많은 경우 모든 것이 끝나버린다. 그런데 실상은 그렇지 않다. 오픈 전에 여러 가지를 가정하고 대비를 하지만 실제 서비스를 오픈하면 그때부터 실제 문제들을 만나게 된다. 이제 본격적으로 레이스가 시작된다. 서비스의 오픈은 프로젝트의 끝이 아니라, 시작을 알리는 신호탄일 뿐이다. 프로젝트를 하면서 끝을 향해 달려가지 마시고 (번아웃에 조심하고), 시작을 위한 마음가짐을 가지세요.

그래서 너무 거창한 생각으로 완벽한 제품을 만들겠다는 욕심보다는 간단하고 조잡하더라도 빠르게 만들어서 사용자들의 평가를 받아보겠다는 생각으로 서비스를 오픈해야 한다. 빠르고 긴밀하고 유연하게... 물론 완벽한 개념과 마스터플랜 (물론 계획은 뒤틀어진다)을 가져야 하지만, 1차 오픈에서 모든 것을 충족시키려는 욕심을 버려야 한다. 개념이나 시기 등에 따라서 빠르게 적용할 것과 완벽하게 적용할 것이 나뉘지만, 일반적으로 빠르게 적용할 수 있는 것이어야 한다.

서비스를 준비할 때 생각하는 가정은 언제든지 무너질 수 있다. 서비스를 오픈하자마자 그런 모든 가정이 무너지는 것을 확인할 수 있다. 다양한 가정과 시나리오를 생각하지만 사용자들은 그런 가정과 시나리오대로 움직이지 않는다. 그래서 다양한 상황에 대한 테스트를 해본다. 그러나 테스트는 또 테스트일 뿐이다. 실제 상황에서 완벽한 가정과 완벽한 테스트는 무용지물이 된다. 최소한의 안전책일 뿐이다.

사공이 많아도 배는 산으로 가지 않는다. 단지 원했던 곳으로 제때 움직이지 않을 뿐이다. 주변의 소리를 최소한으로 해야 한다. 특히 힘이 있는 사람들의 소리에 너무 흔들리면 안 된다. 항상 귀를 열어두데 손과 발이 매번 움직일 필요는 없다. 서비스를 준비하면서 많은 요구사항에 대해서 'NO'를 하지 않았던 것들에 후회가 된다. 말했듯이 빠르게 핵심을 구현한 후에, 주변의 조언에 따라서 다시 빠르게 수정해도 늦지 않다. 처음부터 모든 사람들의 말에 따라서 움직이면 결국 엉뚱한 곳에서 '여기는 어디? 나는 누구인가?'를 외칠 뿐이다.

결과가 모든 문제를 해결한다. 구글의 에릭 슈미츠가 'Revenue solves all known problems'라고 말했던 적이 있다. 수익이 많이 발생하면 방법론이 틀렸건 비용이 많이 들었든 그 모든 문제들이 무시된다는 얘기다. 결과가 좋으면 서비스를 준비하면서 생겼던 모든 문제와 갈등이 해결된다. 그러나 역으로 결과가 신통치 않으면 좋았던 모든 것도 문제가 된다. 완벽한 개념도 결과가 나쁘면 허접쓰레기가 되고, 예쁜 UI도 누더기로 보인다. 지표나 수치에 연연하지 말라고 하지만, 결과가 나쁘면 모든 수고가 허사가 된다.

Universal but Focused. 국정원의 모토가 '음지에서 일하지만 양지를 지향한다'라고 한다. 그렇듯이 모든 서비스는 모든 사용자를 위해야 하지만, 그래도 시작은 좁은 범위에 집중해야 한다. 포털 서비스라는 것이 그렇다. 수백만, 수천만의 사용자를 만족시켜줘야 한다. 모든 개인을 완벽하게 만족시키지 못하더라도, 평균내서 만족이 불만족보다 높아야 한다. 그렇지만 서비스를 준비하면서 타겟을 모든 사용자로 정하면 서비스의 개념이 흐트러진다. 결국 최종 결과물은 이도저도 아닌 이상한 괴물이 만들어져있게 된다. 모두를 위한 서비스를 준비하는 것은 맞지만 적어도 1차 오픈에서는 명확한 타겟을 염두에 두고 오픈하는 것이 맞다. 물론 앞서 모든 가정은 언제든지 무너질 수 있다고 말했듯이, 목표했던 타겟층들이 해당 서비스를 사용하지 않거나 좋아하지 않을 수도 있다.

지표상으로 별로 신통치 않았다고 말했다. 구체적인 수치는 밝힐 수가 없고, 관련자들은 바로 보이는 수치 (PV, UV, CTR)는 특출나지 않지만 서비스의 품질이 나쁘거나 가치가 없는 것은 아니다라고 위로를 한다. 그러나 결과가 모든 것을 말한다. 바로 눈에 보이는 1차 지표가 만족스럽지 못하니, 현 상황을 변명하기 위해서 2차, 3차 지표를 찾기 시작한다. PV가 별로 높지 않으니 인당PV (PV/UV)를 확인하게 되고, 이도 신통치 않으니 체류시간이나 리텐션레이트 등의 복잡한 지표를 만들고 확인하려고 한다. 그렇게 합리화 지표가 만들어진다. ... 타겟 유저를 명확히 해야 한다는 말과 같이, 처음부터 명확한 지표와 목표치를 정해놓고 일을 시작해야 한다는 점이다. 그에 따라 냉정하게 판단하면 된다.

...

서비스 오픈 후에 기분이 별로 좋지 않다. 멘붕이다. 기대치를 밑돌기 때문이다. 너무 높은 기대치였는지도 모른다. 그럴수록 더 지표에 집착하게 된다. 주변에서는 별로 나쁜 결과는 아니다라고 위로하고 지표에 연연하지 말라고 말한다. 그러나 나는 지표에 연연할 수 밖에 없다. 다른 사람들은 단지 새로운 프로젝트에 참여해서 서비스를 오픈하는 것이 그들의 역할이었지만, 나는 이 서비스를 처음부터 설계한 설계자였다. 공은 모두가 나누어 가지는 것이지만, 과는 설계자가 짊어질 수 밖에 없다. 그래야 한다. 그게 일종의 암묵적 사회 계약이다. 그래서 서비스 오픈 후에 매일매일을 죄인의 심정으로 살 수 밖에 없다. 많은 핑계가 있지만, 설계자가 짊어져야할 십자가다.

무엇보다도 강조하고 조언하고 싶은 것은... 권한이 없는 설계자의 자리를 -- 가급적이 아니라 -- 무조건 피하라는 것이다. 설계자에게 권한을 부여하거나 아니면 권한이 있는 사람이 설계자가 돼야 한다. 권한도 없이 결과에 대한 책임만 짊어지는 고단한 삶을 살지 말라고 조언하고 싶다.

그렇지만 게임이 계속 된다면 여전히 사용할 카드패가 남았다는 것은 위안이 된다. 게임이 계속 된다면...

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


댓글을 달아 주세요

Share           Pin It

20편의 PR시리즈를 통해서 추천 시스템에 대한 다양한 이야기를 했습니다. 원래는 슬라이드를 만들 계획이 없었지만 화이트보드와 펜과 함께 하는 강의가 아닌, 스크린과 하는 발표가 생겨서 어쩔 수 없이 간단히 추천 시스템의 구분에 대한 키워드만 뽑아서 발표자료로 정리했습니다. 내부적인 논의가 필요한 항목을 제외하고 공개합니다.

==

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

댓글을 달아 주세요

Share           Pin It

추천 시스템에 대한 세부적인 내용은 대부분 다뤘습니다. 오늘은 실제 추천 시스템을 설계할 때 중요한 포인트만 다시 집고 넘어가겠습니다. 설명을 단순화하기 위해서 메모리 기반의 CF만을 사용한다고 가정하겠습니다.

어떤 데이터를 어떻게 쌓을 것인가?
가장 먼저 고민해야할 문제는 추천에 필요한 데이터 — 유저-아이템 레이팅/피드백 — 을 어떻게 구성할 것인가를 결정해야 합니다. 명시점수를 사용할 것인가 아니며 암묵피드백을 사용할 것인가를 정해야 합니다. 명시점수를 사용하면 미싱값은 어떻게 처리할 것인가도 고려해야 하고, 바이어스되고 불완전한 데이터를 어떻게 정형화할 것인가도 중요한 문제입니다. 암묵점수를 사용하는 경우라면 단순히 0/1로만 할 것인지 아니면 사용자 engagement 정도에 따른 차등점수를 줄 것인지도 고려되어야 합니다. 또는 시간순에 따른 차등점수도 고려될 수 있습니다. 물론 처음에는 가장 기본적인 데이터만 쌓다가 시스템의 진화/필요와 함께 데이터를 보강해가는 것도 좋은 전략입니다.

어떤 유사도를 사용할 것인가?
추천 시스템의 성능을 좌우하는 요소로 유사도라고 말씀드렸습니다. 그러니 당연히 어떤 유사도를 사용할 것인가는 중요한 이슈입니다. 연구논문을 읽어보면 cosine이 가장 좋은 성능을 보여준다고 기술하고 있지만, 논문용 데이터와 실제 서비스용 데이터에는 분명 차이가 있습니다. 데이터마다 더 적합한 유사도가 있기도 하지만, 데이터 스케일에 따른 가용성도 고려되어야 합니다. 다양한 요소가 고려된 유사도는 정확도는 높을지 몰라도 복잡도가 증가해서 계산량이 많거나 복잡해질 우려가 있습니다. 소규모 테스트 데이터에서는 문제가 없을지 몰라도 실서비스에서 쏟아져나오는 대용량 데이터에서는 재앙을 일으킬 수도 있습니다. Ocam’s Razor를 생각하지 않더라도, 실서비스에서는 단순한 co-occurrence나 Jacard index정도만으로도 충분한 성능을 발휘할 수도 있습니다.

어떤 (개인화) 추천 스킴을 사용할 것인가?
추천 개인화에서 — 사실 대부분의 추천이 개인화임 — 유저프로파일을 어떻게 정의하느냐에 따라서 개발방법이 많이 달라집니다. 유저의 프로파일에 유사한 사용자를 넣을 수도 있고, 최근 관심을 가졌던 아이템들을 넣을 수도 있습니다. 즉, 유저 기반의 개인화/추천을 할 것인가 아니면 아이템 기반의 개인화/추천을 할 것인가를 결정해야 합니다. 일반적으로 아이템의 수가 유저의 수보다 적은 경우 아이템 기반의 방식이 더 낫다고 합니다. 그리고 많은 경우 완전 개인화가 아니라면 아이템 기반이 좀더 직관적으로 다양하게 활용이 됩니다. 아마존이나 유튜브에서처럼 단순하게 관련된 아이템만을 보여줌으로써 불필요한 — 프라이버시 등 — 논쟁을 회피할 수도 있습니다. 서비스에 따라서 다른 방식의 프로파일링도 가능합니다. 관심 키워드나 카테고리를 등록해두고 관련된 최신 뉴스를 받아보는 것과 같이 서비스에 적합한 추천/개인화 방식을 정할 필요가 있습니다.

추천 시스템을 어떻게 평가할 것인가?
수익이 모든 문제의 해결책이다라는 말이 있습니다. 어떤 데이터를 사용하든 어떤 유사도를 사용하든 어떤 추천 스킴 및 알고리즘을 사용하든 최종적으로 추천 품질 및 사용자 만족도만 높으면 모든 문제는 해결됩니다. 구현된 추천 시스템의 성능을 어떻게 평가할 것인가?는 단계상으로는 최후의 문제지만, 실질적으로는 프로젝트의 시작과 함께 고려되어야할 문제입니다. 특정 추천 알고리즘이나 요소들은 정확도 개선에 효과가 있지만, 커버리지나 세렌디피티의 증대에는 별다른 영향을 주지 못하는 경우도 있습니다. 정확도를 극도로 높였는데 오히려 사용자 만족도가 낮아지는 경우도 발생할 수 있습니다. 그러니 처음부터 추천의 목표를 명확히하고 평가 방법 및 요소를 구체화시켜서 시스템을 설계할 필요가 있습니다.

적어도 이상의 네가지는 프로젝트를 시작하는 단계에서부터 명확히 정의될 필요가 있고, 또 경과중에도 계속 체크하면서 수정해나가야 합니다. 특히 평가방법/목표와 데이터 수집은 기획자나 개발자 뿐만 아니라, 해당 서비스에 오랜 경험이 있는 실무자들의 도메인 지식이 많이 필요합니다.

추천시스템 전체 목록

  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)
  16. 추천 시스템과 다중인격 (PR시리즈.16)
  17. 추천 시스템의 유사도에 대한 심화이해 (PR시리즈.17)
  18. 추천 시스템의 설계 (PR시리즈.18)

==

페이스북 페이지: 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

추천 시스템에 대한 웬만한 내용은 다 다룬 듯합니다. 그래도 남은 짜투리 생각들을 정리합니다.

추천의 형태/대상별 분류에서 그룹추천을 설명했습니다. 그룹추천은 그룹을 대상으로 공통된 아이템을 추천해주는 의미도 있지만, 더 상세한 개인추천/개인화의 중간단계 역할도 합니다. 여러 측면에서 고려될 수 있지만, 우선 떠오르는 생각은 추천 대상이 너무 많고 광범위해서 1차로 segmentation하고, 각 세그먼테이션 내에서 개인화를 진행할 수 있습니다. 성연령이나 문화권에 따라서 소비자들의 행동패턴은 분명히 다를 것입니다. 그렇기에 인위적으로 성별이나 연령대, 국가별로 나눠서 각 그룹 내의 행동패턴을 상세 분석하는 것은 의미가 있습니다. 미국의 소비자와 한국의 소비자를 하나의 데이터에 넣고 추천 알고리즘을 돌린다고 가정하면, 첫째는 데이터의 사이즈가 커서 불필요한 리소스 낭비만 초래할 수 있고, 또 다른 문화권에 의한 다른 행동패턴이 서로에게 노이즈로 작용할 수도 있습니다. 전체 데이터를 아우르는 일반적인 패턴을 찾아내는 것도 필요하지만, 그룹별로 상세/미세 패턴을 찾아내는 것도 중요합니다.

성연령이나 지역 등과 같이 인위적으로 구분할 수도 있지만, 클러스터링을 통해서 1차로 필터링하고 각 클러스터별러 2차 추천을 하는 방식도 가능합니다. 유저 클러스터링이라면 각 아이템들의 레이팅/피드백을 벡터로 보고 잘 알려진 클러스터링 알고리즘을 실행하면 됩니다. 같은 방식으로 아이템 클러스터링도 가능합니다. 그런데 이렇게 유저, 아이템을 따로 놓고 클러스터링하는 것보다는 유저&아이템을 동시에 클러스터링할 수 있으면 더 좋을 것입니다. 그래서 연구되던 것이 co-clustering 또는 bi-clustering입니다. 학위를 마치고 한동안 이 문제에 많은 고민을 했었는데, 아주 나이스한 방법을 찾지 못한 상태에서 취업을 했습니다. 몇몇 논문들도 나와있었지만 당시에도 그렇게 깔끔하다고 생각하지 못했습니다.

그렇게 시간이 몇 년 흐른 뒤에 회사에 신입사원이 들어와서 LDA라는 것을 소개해줬습니다. 이미 학계 및 산업계에서 늘리 사용되고 있는 방법이었습니다. LDA를 처음 들었을 때는 학교에서 배웠던 Linear Discriminative Analysis인가 싶었는데, 발음하기도 조금 어려운 Latent Dirichlet Allocation이었습니다. 전자는 데이터 분포에서 선형함수를 이용해서 특성이 다른 두 그룹으로 분리하는 클래시피케이션 방법이고, 후자는 토픽모델링이라고 불리는 클러스터링 방법입니다. 실 서비스에 적용되는 대부분의 수학 알고리즘들이 그렇듯이 LDA도 잘 클러스터링하는 데이터가 있고, 그렇지 못한 것들도 있습니다. 같은 데이터를 사용하더라도 어떤 클러스터들이 비슷한 성질의 것들로 잘 그루핑되지만, 다른 것들은 노이즈가 심한 그룹을 형성하는 것을 확인했습니다. 그래도 LDA가 좋았은 점은 제가 오래 전부터 고민하던 co-clustering 문제를 해결해줬다는 점이고, fuzzy 클러스터링처럼 특정 엔터티가 여러 개의 클러스터에 동시에 속할 수도 있다는 점입니다. (LDA에 대한 자세한 설명은 언제나 그렇듯이 위키피디어를 참고하세요. LDA는 제가 자세히 설명드릴 도리가 없습니다.)

LDA는 학계 및 산업계에서 많이 연구되었고 사용되기 때문에 다양한 오픈소스들이 존재합니다. 대표적인 것이 Yahoo에서 배포한 Yahoo LDA가 있고 (Yahoo LDA GitHub), 지난 글에서 소개했던 Mahout에도 LDA가 구현되어 있습니다. (Mahout LDA 위키페이지) 뿐만 아니라, Java를 사용하는 사용자라면 stand-alone으로 JGibbLDA라는 오픈소스도 존재하고, UMASS에서 배포하는 Mallet (MAchine Learning for LanguagE Tookit)에도 LDA가 구현되어 배포되고 있으니 LDA를 직접 사용해보는 것에는 별 어려움이 없을 것입니다. 빅데이터를 분석한다면 그냥 야후LDA나 마훗LDA를 사용하시면 됩니다. LDA에 최적화를 위한 다양한 구현방식이나 옵션에 대한 설명은 제 능력밖이라 생략합니다.

또 생각해봐야할 주제는 레이팅이 없는 것에 대한 (missing value에 대한) 초기값/기본값을 어떻게 정하느냐 문제가 있습니다. 그냥 CF에서는 초기값이 필요없는데, MF방식을 취한다면 초기값이 필요합니다. 그냥 관념적으로 생각해보면, 여러 번 iteration이 돌아간다면 초기값이 굳이 필요없을지도 모르겠는 생각이 듭니다. (이상은 그냥 개인적 생각일뿐, 검증된 내용은 아닙니다.) 초기값은 그냥 스케일 내에서 랜덤하게 정할 수도 있고, 최소 레이팅값을 주거나 아니면 최대값을 줄 수도 있습니다. 그러나 일반적으로는 전체의 평균값이나, 유저의 평균값, 또는 아이템의 평균값을 주면 됩니다. 조금 더 복잡하게 초기값을 정한다면 전체 평균에 유저 바이어스값을 더하고, 아이템 바이어스값을 더해서 결정할 수도 있습니다. 그냥 요즘 테스트해보고 싶은 것인데... SVD로 분해하고, 상위 고유값만으로 레이팅 매트릭스를 재구성하고, 주어진 레이팅값이 있는 경우에는 원래값으로 치환해서, 다시 SVD로 분해하고, 재구성하고, 치환하고, 분해하고... 를 반복하면 초기값에 관계없이 거의 비슷한 예측 레이팅이 나오지 않을까?라고 의심하고 있습니다.

CBF로 추천아이템 커버리지를 넓히는 방법에서 제가 사용한 한 가지 꼼수를 소개합니다. Top 10개의 아이템을 추천해주더라도, (연관 아이템 기준으로 설명하면) 한 아이템당 2~30개 아이템만 추천후보로 충분합니다. 그런데 같은 속성을 가지는 많은 아이템들이 존재할 때, 임의로 N + alpha 개를 뽑아내는 것이 쉽지 않을 수도 있습니다. 같은 속성을 가지는 10개의 아이템이 있다면 연결수는 10^2, 즉 100이 되고, 100개가 되면 10,000개, 1000개이면 1M개로 기하급수적으로 늘어납니다. 데이터 사이즈가 작을 때는 무시해도 되겠지만, 1000개가 포함된 속성그룹이 수백, 수천개씩 존재한다면 메모리 사용량도 급증하고 함께 증가합니다. 그리고 서두에 말했듯이, 10개의 피추천 아이템이 필요하다면 10 ~ 20개 정도만 추천대상에 올려놓으면 됩니다. 그래서, 한 속성그룹 내의 아이템들을 개수 cardinality 에 비례해서 각 아이템을 랜덤그룹에 인위적으로 배분을 하고, 매핑은 랜덤 그룹 내에서만 이뤄지도록 배정을 합니다. 완벽한 솔루션은 아니지만, data explosion도 막으면서 다양한 아이템들을 추천해주는데 효과가 있었습니다. (나이브하게 적었지만, 이 문제를 직접 경험해본 분이라면 대강 이해가 갈듯합니다.)

그래도 커버리지가 낮다고 생각되면 Transitive Rule을 적용해서 확보하는 방안도 가능하고, 롱테일 아이템들은 더 오랜 기간의 데이터를 모아서 부가적으로 분석/추가하는 것도 가능합니다. 전날의 매핑 데이터를 다음 날 일정비율 반영하는 것도 당연히 가능하고, Reverse 관계 즉 B가 A의 연관아이템이면 A도 B의 연관아이템으로 본다 등의 규칙도 적용이 가능합니다. 무턱대로 커버리지를 확대하기 위해서 이런 저런 방법을 도입하다 보면 자기강화현상이 발생할 수도 있고, 최종적으로 추천된 아이템이 어떻게 해서 추천되었는지 설명할 수 없는 상태에 빠질 수도 있으니 늘 경계해야 합니다. 그리고 유저, 사용자, 메타정보/속성정보들의 다양한 조합/관계를 통해서 무수히 많은 방식으로 추천을 확대할 수 있습니다. 문제만 잘 정의되면 해결책은 따릅니다. 베스트에만 집착하지 말고 가능성에 우선을 두셨으면 합니다. Viability or feasibility is first than optimality.

이제 정말로 이걸로 끝일까요???

추천시스템 전체 목록

  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

빅데이터를 위한 하둡 Hadoop이나 머신러닝 라이브러리인 마훗 Mahout의 디테일한 것을 설명하려는 것이 아닙니다. 그냥 마훗의 추천 알고리즘을 실행해본 수준에서 경험했던 프랙티스에 대한 간단한 리마크만 하겠습니다. 하둡이나 마훗에 대한 상세 설명이나 설치/설정 방법에 대해서는 다른 문서들을 찾아보시기 바랍니다. 특히 마훗의 아이템기반CF의 상세한 사용방법은 위키페이지를 참조하세요.

먼저 마훗CF를 사용하기 위한 입력데이터는 {UserID, ItemID, Rating} 페어로 된 CSV 파일이 필요합니다. 마지막 값인 Rating은 암묵점수에서는 넣을 필요없이 하둡/마훗을 실행할 때 옵션 --booleanData를 활성화시키면 됩니다. 여기서 중요한 점은 UserID와 ItemID가 모두 Long integer 형태여야 합니다. 스트링타입을 Long타입으로 변경하려면 마훗 라이브러리에 포함된 MemoryIDMigrator() 클래스를 이용해서 매핑 & 역매핑하시면 됩니다. 그냥 스트링타입의 데이터를 입력하면 java.lang.NumberFormatException.forInputString 익셉션이 발생합니다.

준비된 유저-아이템 레이팅 CSV 파일을 HDFS에 올려놓고 실행시키면 됩니다. 실행하는 방법은 크게 세가지가 있습니다. 아래는 아이템기반CF를 중심으로 명시했습니다. 

  • 마훗 라이브러리를 이용해서 Java 등의 프로그램으로 직접 구현해서 실행하는 방법 (인터넷에 찾아보면 예제파일 있음)
  • 하둡을 이용해서 마훗을 실행하는 방법 (hadoop jar /../mahout-core-0.7-job.jar org.apache.mahout.cf.taste.hadoop.similarity.item.ItemSimilarityJob --OPTION)
  • 마훗을 바로 실행하는 방법 (/../mahout/bin/mahout itemsimilarity --OPTION)

사용되는 옵션은 위키페이지에 자세히 명시되어있습니다. 하둡을 이용해서 마훗을 실행하면 좋은 점이 하둡 옵션을 지정해서 맵리듀스 사이즈를 별도로 정할 수 있다는 점입니다. (-D mapred.reduce.tasks=X)

대용량 데이터를 처리하기 위해서 하둡 및 마훗을 사용했는데, 유사도 (Similarity Measure)를 어떤 것을 사용하느냐에 따라서 Java Heap Size 문제가 발생하기도 했습니다. 다음검색에서 블로그글의 한달치 클릭로그로 테스트해봤는데, 간단한 Tanimoto를 사용했을 때는 별다른 문제가 발생하지 않았는데, 다른 measure로 변경했을 때는 메모리 에러가 났습니다. 실서비스를 위해서 안정적인 계산이 필요한 경우에는 데이터 사이즈 및 유사도를 미리 잘 테스트해 볼 필요가 있습니다. (유사도는 --similarityClassname 옵션을 사용해서, 위키에 지정된 것들을 사용하면 됩니다.)

인풋파일은 따로 명시되지 않고 지정된 하둡 디렉토리 (--input /../input)의 모든 CSV 파일들을 그대로 사용하는 듯하고 (확인필요), 아웃풋파일은 지정된 하둡 디렉토리에 (--output /../output)에 생성됩니다. 파일 이름의 컨벤션은 정확히 기억나지 않습니다. 직접 확인해보세요. 옵션 중에 maxSimilaritiesPerItem이 있는데, 처음에는 아이템별로 유사 아이템 개수를 지정해주는 것으로 이해했지만, 테스트해보니 아웃개수 (아이템수)를 지정하는 옵션이 아닌 듯합니다.

하둡/마훗을 사용하기에 잘 정리하지는 못했지만, 이 정도의 설명도 없어서 처음에는 조금 당황했던 기억이 납니다. 잘 사용하셔서 좋은 성과 얻으시기 바랍니다.

추천시스템 전체 목록

  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

총 10개의 글을 통해서 추천 시스템의 일반적인 내용을 대부분 다룬 것같습니다. 더 자세히 다뤄야할 세부적인 것들이 여전히 많이 있지만, 기존의 다른 논문들을 읽어보시면 쉽게 이해가 될 것입니다. PR시리즈를 통한 추천 시스템의 소개 및 설명은 이것으로 마치겠지만, 다른 관련 이슈가 발견되면 그때마다 내용을 추가하도록 하겠습니다. 모든 연구논문들이 그렇듯이, 추천 시스템의 글을 마치면서 추천 알고리즘 관련 참고 논문들을 아래와 같이 명시합니다. 검색서비스에서 '추천 시스템' 'recommender system[각주:1]' 'collaborative filtering' 등과 같은 키워드로 검색해보시면 다양한 논문들이 나옵니다. 아래에는 추천 시스템의 State of the art를 다룬 리뷰논문들을 주로 나열합니다. (개인/팀 위키페이지에 작성한 것을 그대로 가져옵니다.) 제대로 읽어보지 못한 논문들도 포함되어있지만, 이정도만 마스터해도 추천 시스템에 전문가는 될 수 있습니다. 그 다음의 단계를 여러분들이 직접 서비스에 맞는 추천 시스템을 구현해보고 확인하는 것입니다. 오픈소스 프로그램들도 많으니 그것들을 활용하는 것도 좋고, 알고리즘이 간단하기 때문에 직접 구현해보는 것도 좋습니다.

추천 관련 자료들

추천시스템 전체 목록

  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

  1. 일반적으로 recommendation system이 아닌, recommender system이라고 부릅니다. [본문으로]

댓글을 달아 주세요

Share           Pin It

처음에는 계획하지 않았던 글이지만, MIT 테크리뷰에 올라온 글 (참고, How to Burst the Filter Bubble that Protects Us from Opposing Views)를 읽은 후에 추천시스템 글에 함께 제시할 필요가 있다고 생각해서 적습니다.

위의 글에서 소개되었듯이 필터버블 Filter Bubble은 2011년도에 인터넷 활동가인 Eli Pariser가 처음 사용한 용어로, 강력한 추천 시스템이 사람들을 실세계의 특정 측면을 인지하는 것을 가로막는 현상을 뜻합니다. 검색 서비스를 만들면서 종종 Java를 검색했을 때 어떤 결과를 보여주면 좋을까?라는 질문을 합니다. Java는 잘 알려졌듯이 Sun에서 만들어서 현재는 (거의, 적어도 한국에서는) 인터넷 표준이 된 프로그래밍 언어입니다. 그러나 비IT인들은 자바 커피나 인도네시아 자바섬을 떠올립니다. 그래서 IT프로그래머들에게 프로그램 관련 결과를 보여주고, 비IT인들에게는 자바 커피나 인도네시아 여행 관련 결과를 보여주면 좋을 거다라는 얘기를 합니다. 이렇듯 특정인의 배경이나 관심사에 맞게 결과를 필터링해서 보여주게 되면, 그 사람은 늘 자바에 대한 모든 것 (프로그래밍, 커피, 인도네시아)을 볼 수 있는 것이 아니라, 특정 부분만을 보게 됩니다. 즉, 다른 측면을 볼 수 없습니다. 이런 현상을 필터버블이라고 부릅니다.

추천 시스템을 만들고 알고리즘을 개발할 때, 처음에는 단순히 정확하고 성능이 좋은 걸 개발하겠다고 덤벼들지만, 더 깊숙이 파고들수록 추천에 따른 피로도 증가와 자기강화현상이라는 문제와 맞닿게 되고, 우연에 의한 발견이나 다양성에 관심을 가지게 됩니다. 추천 피로도는 비슷한 아이템들이 계속 제시됨에 따라서 새로운 것이 없다고 느끼게 되는 것이고, 자기강화는 기존에 믿고 있던 관점과 비슷한 증거들이 쌓이면서 자기 확신에 이르는 현상입니다. 특히 정치 사회적으로 대립되는 이슈에 대해서 자기강화현상이 일어나면 잘못된 생각이 확신/신념이 되거나 옳바른 상대의 생각을 무턱대고 배척하고 배제하는 현상이 벌어집니다. 외부의 바른/다른 생각이 차단됨에 따라서 사이비 종교집단에 빠지거나 일베와 같은 비사회적 집단으로 발전할 수도 있습니다.

유유상종이라는 말이 있듯이, 비슷한 생각을 가진 사람들끼리 모이고 커뮤니티를 형성하고, 또 그 속에서 비슷한 생각을 더 강화시키는 현상은 일반적입니다. 특정 관점에 따라서 특정 집단/커뮤니티에 가입하는 것뿐만 아니라, 트위터의 팔로잉의 경우에도 자신과 비슷한 입장의 사람들만 팔로잉합니다. 만약 자신의 생각과 다른 입장의 트윗이 보이면 바로 언팔로잉합니다. (저도 예외는 아닙니다.) 그런데 이것은 개인의 자발적 의사에 의해서 빠져드는 경우이기 때문에 개인의 일탈 행위로 치부할 수 있고, (사회가 어느 정도 책임은 있겠지만) 전적으로 개인의 책임으로 물을 수 있습니다.

그런데 중립적이어야할 검색엔진이나 추천시스템과 같은 기계에 의해서 자기강화현상이 발생한다면 문제는 달라집니다. 예를들어, 특정인의 과거 이력을 분석해보고 그 사람이 우파/보수적인 성향을 가졌다는 것이 파악되었다면 그 사람이 검색할 때마다 그 사람이 좋아할만한 친정부적이거나 친기업적인 보수색체의 뉴스만을 제공해주거나, 역으로 좌파/진보 인사들에게는 진보적인 견해만을 제공해줌으로써 그들의 생각을 공고히 강화시키는 현상이 발생할 수 있습니다. 애플팬들에게는 애플을 찬양하고 경쟁사인 삼성을 까는 기사만 보여주고, 반대로 삼성에 우호적인 사람들에게는 애플의 나쁜 점과 삼성에 호의적인 기사만 보여준다면 이들은 애플이나 삼성의 장단점을 객관적으로 비교할 수가 없습니다. 물론, 기본 성향에 따라서 자신이 선호하는 견해를 받아들이고 반대 견해를 배척합니다. 그러나 그것이 기계에 의해서 보이지 않는 장벽이 처지는 것과는 다릅니다.

그래서 검색엔진이나 추천시스템을 만들면서 단기적으로 사용자들의 만족도를 높이기 위해서 그들에게 우호적인 기사만을 제공해줄 것인가? 아니면 장기적인 관점에서 반대 견해도 함께 제공해줄 것인가?를 늘 고민하게 됩니다. 언론사들이 기본적으로 보수견해, 진보견해가 나눠지지만, 포털과 같이 검색 또는 메타언론사들이 어떻게 중립을 취하고 가치편향을 최소화할 것인가?에 대해서 늘 고민입니다. 중립적인 기사를 배치하거나 균형을 맞추기 위해서 다양한 기사를 배치하지만, 일부에서는 좌파/종북 다음이라는 비난을 받기도 하고 또 반대편에서는 다음도 이제 장악되었다라는 반응을 보이기도 합니다.

네.. 어쨌든 MIT테크리뷰에 소개된 논문 (참고. Data Portraits: Connecting People of Opposing Views)를 읽어보면, 사람들에게 자신의 견해와 다른 기사/데이터를 제공해주면 단기적으로는 불만을 표할지 몰라도 장기적으로는 상대의 견해를 받아들이기도 하고 자기 수정이 이뤄진다는 것이 발견되었다고 합니다. 물론 이슈의 내용이나 개인의 견해의 강도에 따라서 달라지기도 하겠지만... 가치중립적인 조직에서는 욕을 먹더라도 다양한 견해를 취합해서 편햔되지 않은 정보를 사용자들에게 제공해줄 의무가 있습니다.

추천시스템 전체 목록

  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

불특정 다수를 위한 추천을 제외하면, 대부분의 추천은 개인화에 바탕을 두고 있습니다. 개인의 선호도를 바탕으로 명시점수를 예측하거나 특정 아이템을 선호할 확률을 계산해서 보여주기 때문입니다. 그리고 나와 유사한 사용자들이 좋아하는 제품들이나 내가 좋아하는 제품의 관련 제품들도 개인의 선호에 바탕으로 맺어지는 것입니다. 그렇기에 추천 개인화라는 타이틀이 조금 어색하지만, 최근에 제가 고민하는 플랫폼/프로세스에 대한 간략한 스케치만 다루겠습니다. 그리고, 추천 개인화에 관심이 있으신 분들은 Netflix에서 나온 Mining Large Streams of User Data for Personalized Recommendations를 읽어보시기 바랍니다.

제가 생각하는 추천 시스템 또는 추천 개인화는 1. 개인의 과거 이력을 바탕으로 관심사를 찾아내고 모델링하는 User Profiling, 2. 유저프로파일에 연관된 모든 아이템을 찾아내는 Matching, 3. 매칭된 아이템들을 특정 기준에 따라 점수화/순위화하는 Ranking, 그리고 4. 랭크된 아이템들 중에서 유저의 이력이나 선호도에 따라서 불필요한 것들을 제외시키는 Filtering으로 구성됩니다. 이전 글에서도 명시했듯이 랭킹과 필터링은 따로 구분해서 순차적으로 적용되는 것은 아닙니다. 필터링이 매칭단계에서 적용될 수도 있고, 랭킹 함수의 한 요소로 사용될 수도 있습니다.

유저 프로파일링은 문자 그대로 사용자의 프로파일을 만드는 과정입니다. 사용자가 명시한 것들이나 과거 이력, 또는 데모그래픽 정보 등을 모두 이용해서 해당 사용자의 관심사를 파악하고, 그것을 기계가 이해할 수 있는 데이터 구조 및 형태로 표현하는 것입니다. CF방식에서 사용되는 유사사용자도 프로파일이 될 수도 있고, 최근에 조회했던 아이템들도 프로필이 될 수 있습니다. 검색을 많이 하는 사용자의 경우 최근 검색히스토리, 최근 본 기사에서 주로/많이 사용된 키워드 및 기사의 카테고리, 트위터나 페이스북의 친구 등도 모두 사용자 프로파일이 추가될 수 있습니다. 사용자가 직접 등록/지정하는 키워드/토픽/카테고리도 빠질 수가 없습니다.

유저 프로파일이 만들어졌다면, 그것과 관련/연결된 모든 아이템들을 찾아내는 과정이 매칭입니다. (참고로, 매칭에서 '아이템'은 경우에 따라서 다른 의미를 가집니다. 페이스북이나 트위터에서 친구를 추천해주는 경우에는 다른 '유저'가 아이템이 됩니다.) 유사 사용자들이 최근에 관심을 가졌던 아이템들, 최근 본 아이템들의 연관 아이템들, 내가 지정한 또는 암묵적으로 관심을 가졌던 키워드를 포함하는 아이템들 (뉴스기사나 제품설명서 등), 내가 팔로잉하는 사람들이 최근에 적은/추천한 기사 등... 프로파일에 명시된 것들과 연결된 모든 아이템들을 찾아내는 것이 매칭 단계입니다.

매칭을 통해서 수많은 아이템들이 찾아지면, 그것들을 그냥 유저들에게 보여줄 수가 없습니다. 특정한 기준에 따라서 정열을 하고 상위의 Top N개만 선별해서 보여줘야 합니다. 랭킹글에서도 적었듯이 연관성이 높은 아이템들, (일반/특정그룹의) 인기도가 높은 아이템들, 최신 아이템들, 희귀한 아이템들, 오리지널 아이템들 (원본글), 품질이 높은 아이템들 (권위있는 사용자가 적은 글이나 유명 브랜드의 제품 등), 쇼핑에서는 가격이 싼 또는 비싼 아이템들... 등과 같은 다양한 기준에 따라서 아이템들을 정열합니다. 특정 기준에 따라서만 정열할 수도 있고, 여러 요소들을 선형/비선형으로 통합할 수도 있습니다. 그리고 추천랭킹에서 컨텍스트 정보도 중요합니다. 특정 요일이나 시간대, 지역, 성별/연령이 좋아하는 아이템들이 있다면 그런 컨텍스트에 맞게 랭킹이 조정될 필요도 있습니다. 예를들어, 남녀의 선호도가 명확한 상품의 경우 여성에게는 여성 선호 상품을 우선적으로 보여주는 것입니다.

랭킹점수가 높다고 해서 유저들이 그것들을 모두 좋아하는 것은 아닙니다. 이제 사용자들이 싫어할만한 것들 속아내는 과정이 필요합니다. (기본적으로 랭킹이 선호와 비선호를 나눴다고 가정하지만) 유저가 최근에 조회했던 아이템을 중복해서 제시되면 피로도가 쌓이기 때문에, 최근에 본 아이템을 제외하는 것은 가장 기본입니다. 그 외에도 오래된 아이템을 제외할 수도 있습니다. 뉴스 추천에서 최근 일주일, 최근 하루, 또는 최근 1시간정도로 현재 이슈가 되는 것을 위주로 보여줘야 합니다. 그리고 유저가 지정한 (또는 기계적으로 파악된) 비선호 카테고리 정보를 이용해서 비선호 아이템을 제거하는 것도 필요합니다. 정치뉴스를 절대로 안 읽는 사용자에게 정치뉴스만을 추천해주면 추천 시스템이 무용해집니다. (이 이슈는 다음의 필터버블 글에서 다시 다루겠습니다.)

간략히 정리해서 "개인화 추천 (PR) = 유저프로파일링 (P) + 아이템 매칭 (M) + 아이템 랭킹 (R) + 아이템 필터링 (F)"입니다.

추천시스템 전체 목록

  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

댓글을 달아 주세요