Share           Pin It

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

==

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

댓글을 달아 주세요

Share           Pin It

이 주제에 대해서 자세히 다룰 능력이 되지 않지만 이 주제를 뺀다면 글이 완성될 수 없기 때문에 생각했던 그리고 주워들었던 일반적인 내용만이라도 짧게 다룹니다. 프라이버시라고 제목에 적었지만 단지 프라이버시 뿐만 아니라, 여러 법적인 문제들은 늘 서비스 또는 알고리즘을 개발하는데 이슈가 됩니다. 특히 추천은 궁극적으로 개인화로 가기 때문에 개인정보 및 사용에 대한 고민이 많을 수 밖에 없습니다. (이 글은 조금 민감한 주제이므로, 미리 밝히는데 이 글은 오로지 개인의 일탈적 생각일 뿐, 제가 몸담고 있는 조직의 생각/프랙티스는 아닙니다. 어떤 것들은 그냥 가능성 또는 잠재성만을 얘기하는 것일 뿐 저의 신념을 얘기하는 것도 아닙니다.)

이전 글에서 사적인 영역에서 봤던 것을 기준으로 추천된 것이 공적인 영역에서도 노출될 수 있다는 우려의 글을 적은 적이 있습니다. 조금 낯이 뜨겁고 민망한 경우지만 웃으며 넘길 수도 있습니다. 그렇지만 하나의 기기 (대표적으로 스마트폰)로 개인의 모든 정보가 접근 가능해지고, 하나의 식별자 (이메일 등)로 모든 연결된 곳에서의 활동이 저장되고 통합된다는 것을 깊이 생각해보면 아찔하다는 생각이 듭니다. 가볍게 무시될 수도 있지만 또 그냥 넘길 수가 없는 것이 프라이버시 문제입니다.

다른 글에서 (추천 시리즈 외의 글) 개인정보의 개념이 바뀌고 있다는 뉘앙스의 글/말을 한 적이 있습니다. 페이스북의 저크버그는 개인정보/프라이버시의 시대는 끝났다라는 위험한 선언까지도 했지만 어쨌든 프라이버시에 대한 생각이 많이 바뀌었고 둔화되었습니다. 다른 글에서 저는 이제 개인정보는 개인에 대한 정보에 관한 것이 아니라 그 정보에 대한 통제권/제어권의 문제다라고 적었습니다. 이제는 그리고 앞으로는 개인의 정보를 숨길 수가 없습니다. 지난해 문제가 되었던 NSA의 감시 및 첩보활동에서 보듯이, 우리가 아무리 숨기려고 해도 그것을 캐내려는 시도가 많습니다. 그리고 무의식적으로 우리 정보를 흘리고 다니고 있습니다. 이미 내 주민등록 번호는 공용이다라는 우스개 소리도 합니다.

어쩌면 그래서 개인의 이름, 생년월일, 관심사, 다녀왔던 곳 등의 정보는 더 이상 개인정보가 아닐 수도 있습니다. 프라이버시 문제를 다룰 때 이런 정보를 보호해야 한다는 접근법은 어쩌면 맞지 않을 수도 있습니다. 이제는 그런 정보에 대한 통제권이라는 측면에서 프라이버시를 다뤄야한다고 생각합니다. 내가 페이스북에 사진을 공개한다면 내 친구들이나 때로는 불특정인이 저의 개인 페이지에서 그걸 볼 수가 있습니다. 그러나 그 사진을 허락도 없이 — 저작권/초상권 문제와는 별개로 — 다른 곳에서 이용할 수는 없습니다. 나의 정보는 내가 통제하는 범위 내에서 공개되고 사용되어야 합니다. 그런 의미에서 정보 통제권을 말하는 것입니다. 이미 공개된 (때로는 그냥 아무런 숫자조합으로도 만들어지는) 주민번호나 전화번호 자체가 문제가 되는 것이 아니라, 그것을 불법적으로 사용하는 것이 문제입니다. 전화번호나 이메일 주소를 공개했다면 정상적인 연락을 받겠다는 의미이지 스팸 문제나 메일을 받겠다는 의미가 아닙니다. 그런 스팸은 저의 통제권을 벗어난 것입니다. 즉, 프라이버시 침해라고 말할 때 그것이 나의 통제권 안에 있느냐 밖에 있느냐를 따져야합니다.

그런 측면에서 추천에서도 나의 구매나 조회 기록이 다른 사람들에게 도움을 줄 수 있도록 추천 데이터로 사용되어야 된다는 허락이나, 나에게 맞는 개인화된 추천을 받아보겠다 등과 같은 명시적 허락이 필요합니다. 서비스 제공자의 입장에서는 이런 옵트인 opt-in 방식은 여러모로 꺼려지기 때문에, 적어도 옵트아웃 opt-out 방식으로 사용하지 말것 또는 추천하지 말것 등의 옵션이 제공될 필요가 있습니다. 특정 히스토리만 빼달라와 같은 CS 까지 들어온다면 서비스 제공자 입장에서는 애초에 추천 서비스를 하지 않는 것이 가성비가 더 나을지도 모르겠다는 생각도 문득 듭니다.

프라이버시나 법적인 문제는 저의 전문 영역이 아니라서 이정도에서 끝맺겠습니다.

추천시스템 전체 목록

  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)
  19. 추천 시스템과 어뷰징 (PR시리즈.19)
  20. 추천 시스템과 프라이버시 (PR시리즈.20)

==

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

댓글을 달아 주세요

Share           Pin It

특별히 지능적인 해결책이 있는 것도 아니지만 잠재적인 문제가 될 수 있는 이슈라서 글을 적습니다. 글의 내용 때문에 어뷰저들이 더 지능적으로 바뀌지 않을까?라는 우려를 할 수 있겠으나 그렇게 지능적으로 발전할만한 내용을 담고 있지 않으니 큰 문제는 되지 않을 듯합니다. 현재 지능적인 해결책보다는 그저 휴리스틱으로 사후 대처에 급급한 분야이기 때문에 더 지능적인 어뷰저가 등장한다면 대처 능력도 더 커질 것이니 나쁜 것만은 아닙니다. 병이 있어야 약이 있는 이치입니다. (오늘 slownews.kr에 올라온, 일워 개발 이야기를 참조하세요.)

추천 시스템과 검색 엔진은 실질적으로 같은 것이다라고 적은 적이 있습니다. 인터넷의 많은 서비스들이 어뷰징이나 스팸 공격을 받고 있습니다. 특히 검색 서비스를 악용해서 스팸 문서를 배포하는 행위는 매우 우려스럽습니다. 정상적인 검색엔진을 분석해서 SEO (Search Engine Optimizatio 검색최적화)를 통해서 검색랭킹을 올리는 경우도 있지만, 문서의 내용을 변경한다는 등의 비정상적인 방법으로 어뷰징이 많이 일어난다. 그리고 서제스트, 관련검색어, 실시간 이슈어 등의 검색어를 순위에 올리기 위한 다양한 어뷰징이 존재한다. 검색에서도 그렇듯이 추천에서도 비슷한 어뷰징 사례가 등장할 수 있습니다. 다수의 좀비 PC 등을 사용해서 전혀 무관한 두 상품을 연관상품으로 묶어서 보여줄 수 있습니다. 나이키 운동화를 찾는 사용자에게 카메라를 보여주는 형태입니다. 만약 그 사용자가 카메라를 보고 구입한다면 오히려 땡큐인 상황이지만, 카메라가 아니라 성인용품 등이 노출된다며 문제는 심각해집니다.

특정 서비스를 과도하게 많이 사용한다고 해서 어뷰징이 아닙니다. 오히려 그들은 그 서비스의 헤비유저이므로 매우 감사해야할 사용자입니다. 어뷰저는 특정한 목적과 사적인 이득을 편취하기 위해서 서비스를 오남용하는 사용자입니다. 때로는 어뷰저이지만 매우 합리적인 어뷰저도 존재할 수 있습니다. 정상적인 연관상품을 매핑시켜줘서 커버리지를 넓혀준다면 그 사용자가 서비스를 남용하더라도 큰 문제는 아닙니다. 물론 경쟁 상품의 업주 입장에서는 한탄할 상황이지만 말입니다. 그런데 보통 어뷰징을 통해서 비정상적인 관계가 형성되기 때문에 문제가 됩니다. 앞서 말했던 성인용품이 많은 상품에 공통적으로 추천되는 경우입니다.

그리고 특정인이 서비스를 남용하더라도 큰 문제가 되지 않을 소지가 큽니다. 연관 상품이라는 것이 여러 사람들이 공통적으로 함께 조회/구입한 상품들을 연결하기 때문에 특정인의 남용으로 큰 변화를 주지 않습니다. 물론 비인기 상품의 경우 한두명이 같은 상품을 조회하면 엉뚱한 연결이 발생할 수도 있습니다. 구매를 기준으로 한다면 어뷰징이 오히려 비용을 만들어 내기 때문에 서비스 제공자 입장에서는 상관은 없습니다. 그런데 많은 경우 구매같은 엄격한 액션보다는 단순히 조회나 댓글을 남긴 것 등의 기록을 가지고 분석하기 때문에 (Data sparsity 등의 이슈로문제가 될 수 있습니다. 그리고 특정 인이 과도하게 사용하는 것도 충분히 막을 수 있습니다. 비정상적인 사용자의 행동 패턴은 그냥 원시 데이터에서 제외시켜도 되고, 데이터 중에서 아주 일부만 사용하면 그만입니다. 실제 계산량을 줄이기 위해서 사용자별로 최신 몇 개의 조회기록만으로 연관성을 계산하는 것이 더 합리적인 방법이기도 합니다. 문제는 요즘처럼 좀비PC를 이용한 대규모 공격이 들어왔을 때입니다. 물론 다수의 컴퓨터에서 너무 비슷한 패턴으로 행동이 이뤄지면 해당 컴퓨터의 모든 기록을 제외시킬 수도 있다. 실시간 분석에 민감하지 않은 서비스에서는 이렇게 걸러내면 어느 정도 해결된다. 물론 그래서 핵심 페어를 제외하고는 다른 세트의 조합으로 어뷰징을 시도하기도 합니다.

최근 영화 '변호인'이 개봉하기 전에 벌레들의 별점 테러라는 것이 자행되었습니다. 한 사람에 의한 좀비PC 공격은 아니지만 다수의 벌레들에 의해 발생한 어뷰징의 좋은 사례입니다. 이런 경우 기존의 행동 패턴과 맞지 않은 기록은 제외시킬 수도 있습니다. 이제껏 1점을 한 번도 준 적이 없는 사용자가 어느날 갑자기 1점을 줬다면 (아웃라이어로) 분명 의심해볼 수 있습니다. 다르게 생각해보면, 만약 점수를 준 행동만으로 그냥 암묵 피드백을 이용한다면 오히려 변호인을 봤던 사람들이 봤던 비슷한 다른 영화들 -- 당연히 벌레들이 싫어할 만한 --을 추천을 해주는 이상현상이 발생할 수 있습니다. 특수한 경우지만, 어뷰징을 했다가 오히려 뒷통수를 맞은 상황입니다.

그리고 만약 어뷰징이 발생하고 있다면 누군가가 그 서비스를 중요한 서비스로 인식하고 있다는 증거이기도 합니다. 나쁜 피드백이 무응답/무관심보다 낫다라는 말이 있습니다. 노이즈는 잘 걸러내면 됩니다.

준비가 없이 즉흥적으로 글을 적어서 조금 횡설수설했습니다.

추천시스템 전체 목록

  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)
  19. 추천 시스템과 어뷰징 (PR시리즈.19)

==

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

이 글은 이전에 다뤘던 글들에 비해서 조금 더 관념적이면서 기술적인 글을 담고 있습니다. 그렇다고 해서 수식이나 프로그래밍 코드가 포함된 것은 아닙니다.

추천 시스템 (CF방식)에서 어떤 유사도 similarity measure를 사용하느냐에 따라서 추천 시스템의 성능에 큰 영향을 준다고 설명했습니다. 일반적으로 Euclidean distance, jacard index, correlation coefficient, cosine 등의 유사도를 많이 사용하고 있다고 말했습니다. 그리고, 추천 시스템에 따른 예측값과 실측값의 Error term이나 이들의 correlation의 정도로 추천 시스템의 정확도를 평가한다고 말씀 드렸습니다. (하단 링크 참조)

이 글에서는 유사도 또는 성능평가 측도에 대해서 좀더 깊게 생각해볼까 합니다.

유사도 또는 성능평가 측도는 간격 Gap 또는 경향성 Tendency 두가지 term으로 구성되어있습니다. 현재 대부분의 측도들은 한가지 term으로만 유사도를 측정하고 있습니다. Euclidean distance, cosine, 또는 Error 합 (MAE, RSME)은 두 샘플값 (e.g., 실측값과 예측값) 사이의 간격을 수치화한 것이고, correlation coefficient는 경향성의 동조 정도를 수치화했습니다. 결론적으로 말하면 간격과 경향성은 모두 나름의 (존재) 이유가 있지만, 결국 이 둘을 하나로 합친 measure가 필요하다는 것입니다.

많은 경우 실측값과 예측값의 유사정도를 측정하기 위해서 이들의 에러값 Error 또는 잔차 residual를 구하는 것은 합리적입니다. 많은 샘플에서 실측값과 예측값 사이의 간격이 평균적으로 좁다는 것은 이 두 값이 거의 같다는 얘기가 됩니다. 그러나 실제 이 두 값들을 산포도를 그려보면 생각보다 분산/산포도가 심하다는 것을 확인할 수 있습니다. 평균적으로는 시스템이 잘 예측하는데, 각각의 샘플을 보면 전혀 엉뚱한 값으로 예측했다는 의미가 됩니다. 아래 그림은 학교에서 논문을 적으면서 CF방식의 정확도를 측정한 것입니다. 붉은 선이 실측값이고 푸른점들이 예측값인데, 평균적으로 MAE가 괜찮게 나왔지만 그림만을 얼핏 보면 엉터리 시스템인 듯 보입니다. 그래서 분산도를 고려해서 시스템을 평가해야 된다는 논문을 적은 적이 있습니다. 참고로 아래 그림은 샘플들의 레이팅값이 고르게 퍼져있지 않기 때문에 정확한 예측 시스템을 만들고 평가하는데 문제가 있다는 점도 함께 보여주는 그래프입니다.


두번째로 경향성 즉 correlation을 측정하는 것도 매우 합리적입니다. 위의 간격을 측정한 것에서 보여줬던 평균은 비슷하지만 분산이 심한 경우는 나쁜 시스템이다라고 말할 수 있습니다. 그런데 순전히 경향성만을 판단하면 둘 사이의 간격을 고려하지 못합니다. 예를들어, A = { 1 2 3}, B = { 4 5 6 }, C = { 5 5 5}, D = { 4 4 6}으로 세개의 샘플을 측정했다고 가정해봅니다. 이 중에서 B가 실측값이라고 봤을 때, 경향성만 따지면 A가 B와 가장 가깝게 측정됩니다. 그런데 A와 B의 평균 간격이 3으로 매우 넓기 때문에 정확한 값을 예측하지 못했다고 볼 수 있습니다. D의 경우 A보다는 경향성은 약하지만, 간격을 생각해보면 D가 A보다 더 정확한 예측값입니다. (간격만을 고려한다면 위의 그림에서도 보여지듯이 C와 비슷한 예측값이 나올 가능성이 높습니다.)

결론적으로 정확한 유사도 또는 성능평가측도는 실측값과 예측값 사이의 간격과 경향성/동조성을 동시에 최적화하는 것이 필요합니다. 저의 논문에서는 Sim 또는 Err = '간격 * 분산'으로 구해야 한다고 적었습니다. 잠시 생각해보니, 간격보정 bias correction이 확실하게 이뤄진다면 간격보다는 경향성이 비슷한 것이 더 나을 수도 있다는 생각이 듭니다.

추천시스템 전체 목록

  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)

==

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

총 11번에 걸쳐서 추천 시스템과 관련된 다양한 알고리즘, measure, 고려사항 등을 다뤘습니다. 이 글에서는 미쳐 다루지 못했던 내용이나 그외 추천 시스템에 대한 잡다한 생각들을 두서없이 적으려고 합니다.

외국의 경우 아마존이나 넷플릭스, 구글유튜브 등이 추천으로 유명한 회사/서비스들이지만, 국내에는 여전히 추천 또는 데이터기반이 여전히 미약합니다. 최근에 영화 추천 서비스인 왓차, 그리고 그것을 만든 프로그래밍스가 조금 유명세를 타고 있습니다. 이전의 모든 글의 공통된 밑바탕은 추천 알고리즘 및 서비스는 별개 아니다 입니다. 현존하는 데이터마이닝 방법 중에서 추천보다 더 쉬운 것은 없다는 것이 저의 기본 가정입니다. (물론 엄청 잘하는 것은 매우 어렵습니다.)

왓차 서비스도 전혀 새로운 것이 없는데, 언론에서 과도하게 주목하는 것같다는 생각입니다. 추천 알고리즘뿐만 아니라, 왓차에서 사용하는 다양한 오픈소스들은 코딩에 조금만 재능이 있으면 누구나 사용이 가능한 아주 기본적인 것들입니다. 그럼에도 불구하고, 프로그래밍스를 높이 평가하는 것은 그런 것들을 직접 활용하고 실행에 옮겼다는 점입니다. 구슬이 서말이라도 꿰어야 보배다라는 속담처럼 주어진 재료를 이용해서 의미있는 서비스를 만들고 사용자들에게 의미를 부여해주는 바로 그 '실행'에 높은 점수를 주고 싶습니다. 국내에서도 다양한 서비스에 자동화된 추천 및 개인화 서비스가 정착했으면 좋겠습니다.

구글의 성공 이후로, 그리고 최근 빅데이터라는 버즈워드와 함께 데이터 기반 의사 결정 및 실행 Data-driven Decision making & Execution 이라는 것에 많은 관심을 쏟고 있습니다. 예전에는 아파치, MySQL 등이 제공되었고, 최근에는 하둡을 시작으로 한 다양한 분산처리 솔루션들이 제공됨으로써 소프트웨어/서비스 전문 회사가 아니더라도 쉽게 (빅)데이터를 관리, 분석할 수 있는 여건이 마련되었습니다. 사회적 관심도 높아졌고 다양한 기반 솔루션들도 존재하지만, 국내에서는 여전히 데이터 기반의 그것 something이 부족하다는 것을 느낍니다.

다른 곳들보다 -- 특히 비IT 기반의 제조업체 등 -- 다음이라는 회사가 여러 면에서 데이터 기반의 실행이 가능한 곳이지만, 외부에서 짐작하는 것에 비하면 여건이나 프랙티스가 미약합니다. 별것도 아닌 추천 서비스들도 최근에 일부 적용되고 있고, 대부분의 서비스들은 여전히 수작업을 거치는 것이 현실입니다. 가볍게 실행해보고 효과를 파악한 후에 그만두거나 더 드라이브를 걸거나 하는 그런 실행조직으로써의 문화가 많이 부족하다고 생각합니다. 물론 아니면 말지 식의 사고는 위험합니다. 그러나 오늘날은/현실에서는 그것보다 더 효과적인 전략도 없는 듯합니다. (애플이 될 수 없다면, 실행에 더 방점을 찍어야 합니다.) 다음이 이렇다면 다른 회사들은 어떨까?라는 생각을 하게 됩니다.

추천 시스템의 역사가 20년이 넘었기 때문에 단순한 직관/휴리스틱만으로는 추천 알고리즘의 발전이 거의 없습니다. 그래서 데이터마이닝 또는 머신러닝 분야에서 개발된 다양한 알고리즘들이 추천 시스템에도 접목되고 있습니다. 소개해드린 넷플릭스 논문에서도 소개되었지만, 웬만한 알고리즘들이 추천이라는 우산 아래 모여있는 것을 볼 수 있고, 또 여러 알고리즘들이 결합되어 새로운 알고리즘을 만들어내고 있습니다. 넷플릭스 프라이즈에서도 새로운 알고리즘의 승리라기 보다는 기존 아이디어들의 재발견 (또는 아상블 emsemble의 승리)에 가까웠습니다. 초기에는 추천이라는 문제를 바탕으로 다양한 방법론/휴리스틱들이 개발되었지만, 최근에는 다양한 연구 커뮤니티의 기술들이 추천이라는 문제를 풀기 위해서 이합집산하는 느낌이 강합니다.

추천 알고리즘에서 미처 설명하지 않고 넘어갔던 것이 하나 있습니다. 흔히 '장바구니 분석'이라는 기술이 있습니다. 책이나 블로그 등에서 자주 언급되는 아기 아빠들이 기저귀를 사면서 맥주를 함께 사더라라는 역사적인 연구에 등장하는 것이 장바구니 분석입니다. 함께 구매한 상품을 찾아내는 장바구니 분석은 CF의 아주 협소한 영역입니다. CF에서 한 사람의 이력 기간을 세션 (장바구니) 단위로 끊어서 분석하면 장바구니 분석과 비슷한 효과가 나옵니다. 그런데 CF는 아이템 페어 Pair-wise로 추천이 이뤄지지만, 장바구니 분석은 여러 아이템들이 함께 묶이는 형태로 결과가 나옵니다. 기술적으로 더 궁금하신 분은 Association Rule 또는 Frequent Pattern Mining으로 검색해보시면 됩니다.

PR시리즈 첫 글에서 제가 어떻게 해서 추천 시스템을 시작했는지 정확한 기억이 없다고 말씀드렸습니다. 지금 생각해보면 추천 시스템을 공부하기 직전까지 문서와 키워드의 관계 Vector Space Model (VSM)를 이용한 텍스트 마이닝을 연구/고민하고 있었고, 스트링커널 String Kernel을 이용해서 다양한 형태의 XML Schema 문서들 간의 유사도를 구하는 연구를 진행했습니다. 텍스트마이닝에 사용한 VSM이 추천 알고리즘에서의 유저-아이템 레이팅 행열과 똑같은 형태를 이루고 있습니다. VSM은 보통 TF-IDF로 문서와 키워드 관계를 설명하고, 이를 바탕으로 LSA/I (Latent Semantic Analysis/Indexing) 또는 PLSI (Probabilistic LSI)로 클러스터링 등을 수행하는데, 여기에 사용되는 LSA/LSI가 MF방식의 SVD와 같은 개념이 적용됩니다. 문서, 키워드, 유저의 관계/그루핑을 연구하던 것을 자연스레 유저-아이템 관계를 분석/예측하는 것으로 전환시켰던 것같습니다.

(계속...?)

추천시스템 전체 목록

  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이라고 부릅니다. [본문으로]

댓글을 달아 주세요