Search Results for 'MachineLearning'

1 POSTS

  1. 2014|07 Mahout - 기본 개념

Mahout - 기본 개념

Posted 07 24, 2014 10:48, Filed under: MachineLearning/Mahout


# 머하웃 프로젝트 위키

https://cwiki.apache.org/confluence/display/MAHOUT/Algorithms





> 머하웃 집중 영역 : 추천엔진(협업필터링), 군집, 분류
 - 추천엔진 :
   - 현재 사용되는 기계학습 분야에서 가장 이해하기 쉬운 영역
   - 사용자의 취향과 선호를 추론해서 관심을 가질만한 책이나 영화, 뉴수 가서 등을 추천하는 서비스

 - 군집 :
   - 많은 수의 사물을 여러 개의 유사성이 높은 클러스터 그룹으로 나눔.
   - 양이 많아서 이해하기 어려운 데이터 셋의 계층을 발견하고, 흥미로운 패턴을 도출하거나 데이터셋을 이해하기 쉽게 만들 수 있음.
   - 파악하기 힘든 대규모 사물의 구조나 계층 체계를 파악하기 쉬워짐.
     기업 환경에서는 군집 기술을 활용해서 숨겨진 사용자 그룹을 발견하거나 많은 수의 문서를 이해하기 쉽게 구조화하거나 사이트 로그를 분석해 공통적인 사용 패턴을 찾기도 함.

 - 분류 :
   - 어떤 사물이 특정 카테고리에 종속되는지 또는 특정 속성을 포함하는지 결정할 수 있음.
     알고리즘은 좀 더 복잡

> 특징
 - 규모 확장성을 가장 높은 우선순위


2.2.1 입력 데이터 만들기


일단 추천기에 입력되고 처리될 데이터가 필요하다.
이러한 데이터를 머하웃에서는 선호(preference)라고 한다.
사용자에게 아이템을 추천해주는 추천엔진이 우리에게 가장 친숙하므로, 사용자와 아이템과의 관계를 선호라고 부르는 것이 편리할 것이다.
물론 앞서 말한 대로 사용자와 아이템은 어떤 것이든 될 수 있다.
이런 선호 정보는 주로 사용자 ID와 아이템 ID 그리고 사용자의 아이템 선호 수준을 표현하는 숫자로 구성된다.
머하웃에서 ID는 언제나 숫자인 정수를 사용한다.
큰 값이 선호도가 높다는 규칙만 지킨다면 선호값(preference value)은 어떤 수든 상관 없다.
예를 들어 '1'에서 '5'의 5점 척도를 사용할 경우는 '1'은 사용자가 싫어하는 것을 나타내고 '5'는 좋아하는 것을 나타낸다.


3.1 선호 데이터 표현

 추천엔진에 입력하는 데이터는 누가, 무엇을, 얼마나 좋아하는지 표현한 선호 데이터다.
 이 선호 데이터는 사용자 ID, 아이템 ID, 선호값 튜플tuple로 구성되며, 대용량으로 머하웃 추천기에 입력된다.
 어떤 경우에는 선호값조차 생략되는 경우도 있다.

 - UserSimilarity : 사용자간의 유사도 개념을 캡슐화한 클래스
 - UserNeighborhood : 가장 유사한 사용자 그룹의 개념을 캡슐화한 클래스
 
 # 추천기용 컴포넌트
 * DataModel : 데이터 연산을 위해 모든 선호, 사용자, 그리고 아이템 정보를 저장하거나 접근하도록 한다.
 * UserSimilarity : 하나 혹은 여러 개의 가능한 측정 혹은 연산을 통해 얼마나 두 사용자가 유사한지를 구한다.
 * UserNeighborhood : 주어진 사용자와 가장 유사한 사용자 그룹을 알려준다.
 * Recommender : 모든 컴포넌트를 함께 활용하여 사용자에게 아이템을 추천한다.

# 고정 크기 이웃
 > 클래스 : NearestNUserNeighborhood([이웃의 수], similarity, model)
 * 가장 유사한 사용자로 구성된 n명의 이웃에서 추천할 대상을 구성
 * 100명에서 10명으로 상대적으로 적은 수의 유사한 사용자를 기반으로 추천하게 되면, 유사성이 비교적 덜한 사용자는 분석 대상에서 빠지게 됨.
 * 사용자들끼리 거리가 멀수록 덜 유사함
 * 향상도(피어슨) : 10=0.91 < 100=0.83 , 평가값이 더 큰 경우가 좋지 않다는 의미
 
# 임계치 기반 이웃
 > 클래스 : ThresholdUserNeighborhood([임계치], similarity, model)
 * 임계치는 -1에서 1사이로 설정해야 함
   이유는 모든 유사도 측정이 이 범위의 유사도값을 반환하기 때문.
  * 향상도(피어슨) : 0.9=0.85 < 0.7=0.79 < -1.2=0.75 < 0.5=0.74
    유클리드 유사도 : 0.7=0.78 < 0.5=0.66


#############
# 추천기 평가
#############
# 학습 데이터와 점수
실제 데이터에서 일부 데이터(학습 데이터)를 제거한 후 남은 데이터(테스트 데이터)로 미래 선호를 시뮬레이션해볼 수 있다.

학습 데이터와 테스트 데이터를 명확히 분리해야 올바른 평가가 가능하기 때문에 이런 테스트 선호는 추천기에 입력된 학습 데이터에는 나타나면 안 된다.
추천기가 테스트 선호를 올바르게 도출하려면 학습 데이터가 제외된 테스트 데이터만 필요하기 때문이다.

대신에 추천기는 제거한 테스트 데이터의 선호를 추정하고 실제값과 비교한다.
이렇게 하면 추천기를 간단하게 평가해볼 수 있다.

예를 들어 추정 선호와 실제 선호 간의 평균 차이를 계산할 수 있다.
이런 점수 방식에서는 점수가 낮을수록 좋은 것인데, 추정 선호값이 실제 선호값과 차이가 적음을 의미하기 때문이다.
점수가 0.0이면 실제값과 예측값에 전혀 차이가 없는 완벽한 추정인 것이다.

종종 차이값 비교로 제곱평균제곱근이 사용된다.
이것은 실제 선호와 추정 선호값의 차이를 제곱한 것의 평균값에 제곱근을 적용한 것이다.
값은 낮을수록 좋다.

[평균차이_제곱평균제곱근_계산.jpg]

아이템 2처럼 누군가 원할 수도 있지만 예측이 잘못된 아이템에 대해 더 심하게 왜곡할 수 있다.
예를 들어 별점 2개 차이가 별점 1개 차이보다 2배 이상 나쁘게 추정될 수 있다.


#############
# 유사도 측정법
#############
 사용자 기반 추천기에서 또 하나의 중요한 부분은 UserSimilarity 구현일 것이다.
 사용자 기반 추천기는 이 컴포넌트에 전적으로 영향을 받는다.
 따라서 사용자 간의 신뢰할 만한 유사성 여부를 효과적으로 구할 수 없다면 사용자 기반 추천에서는 형편없는 결과만 나올 것이다.
 사용자 기반 추천기의 조카뻘 되는 아이템 기반 추천기도 역시 이러한 유사도에 의존한다.
 [단순_추천기_입력_파일.jpg]

 
# 피어슨 상관관계 기반의 유사도
 > 클래스 : PearsonCorrelationSimilarity(model)
 * 피어슨 상관관계는 -1과 1사이의 값으로, 두 개의 연속적인 숫자열의 일대일 비교를 통해 경향성을 측정한다.
   한 숫자열의 각 숫자가 다른 숫자열의 대응되는 값보다 얼마나 상대적으로 큰지 측정한다는 뜻.
   즉, 두 숫자열 간의 대략적인 선형관계를 이루는지 숫자열내의 값들과 다른 숫자열값의 공통적인 방향성을 측정해서 확인해보는 것.
   경향성이 크면 상관계수는 1에 가까워진다.
   관계가 적어지거나 거의 없을 경우에는 값이 0에 가까워진다.
   숫자열 내의 숫자가 높고 다른 숫자열 내의 값은 작아지는 서로 대립하는 상관성을 가질 경우에는 값이 -1에 가까워진다.
 * 피어슨 상관관계로 하나의 아이템에 대해 두 사용자의 선호값의 이동 경향성이 상대적으로 높은지 아니면 낮은지 측정.
 [사용자_선호_피어슨상관관계.jpg]

 
 > 문제점
 1) 두 사용자의 선호가 겹쳐지는 아이템의 숫자를 고려하지 않기 때문에 추천엔진을 사용할 때 약점이 될 수 있다.
    예) 두 사용자가 같은 영화 200편을 본 경우에는 같은 평점을 주지 않았더라도 영화 2편만 공통으로 본 두 사용자보다는 유사도가 높아지는 경향이 있다.
 2) 만약 두 사용자의 아이템 선호 중 단지 하나만 겹친다면 계산 방식을 어떻게 정의할지 모르기 때문에 상관관계를 계산할 수 없다.
 3) 선호값의 열이 모두 일치하는 경우에도 정의하기 어렵다.
    예) 사용자 5가 3개의 아이템 모두에 3.0의 선호를 표현했다면, 사용자 1이 3.0 외의 다른 선호를 가지고 있어도 사용자 피어슨 상관관계를 정의할 수 없다.
        따라서 사용자 1과 사용자 5 사이의 유사도를 계산할 수 없다.
        
        
# 가중치 적용
위의 PearsonCorrelationSimilarity에서 언급한 이슈를 완화하도록 표준 계산 방식을 확장한 가중치 처리 기능을 제공한다.
 > 두번째 인자 : PearsonCorrelationSimilarity(model, Weighting.WEIGHTED)
 가중치(Weighting.WEIGHTED)를 적용하면 결과적으로는 상관관계 값을 계산할때, 얼마나 많은 데이터 포인트를 사용하느냐에 따라 상관계수가 1.0 혹은 -1.0에 근접한다.
 평가 프레임워크를 빠르게 실행해보면 이 경우에는 0.77로 점수가 약간 좋아진다.
 
 
# 유클리드 거리 기반의 유사도 정의
 > 클래스 : EuclideanDistanceSimilarity(model)
 이 구현 방법은 사용자 사이의 거리에 기반한다.
 이 아이디어는 선호값으로 좌표체계를 구성한 많은 다차원 공간(가지고 있는 아이템 수만큼 존재할 수 있다)에 사용자를 하나의 위치로 봄
 이 유사도 측정법은 두 사용자 위치 사이의 유클리드 거리 d를 계산한다.
 즉, 유클리드 거리가 큰 값을 가지면 사용자 간의 거리가 멀다는 의미이기 때문에 사용자 간 유사성이 떨어져서 값 자체로는 유의미한 유사도 측정으로 보이진 않는다.
 사용자끼리 유사할 수록 값이 작아야 한다. 그래서 1/(1+d)의 값을 반환하도록 구현했다.
 거리가 0일 때는(사용자의 선호가 완전히 동일할 때) 결과값이 1이고, 거리 d값이 증가함에 따라 값이 작아지는 것을 확인할 수 있다.
 유사도 측정값으로 음수를 반환하지 않지만 여전히 값이 클수록 유사도가 커진다.
 * 피어슨 상관관계에서 사용자 1과 사용자 3 사용자 간의 계산이 가능해졌다.
 * 여기서는 사용자 1과 사용자 4가 더 높은 유사도를 가진다.
 [사용자_선호_유클리드_유사도.jpg]



# 스피어만 상관관계의 관련 순위로 유사도 정의
 > 클래스 : SpearmanCorrelationSimilarity(model)
 스피어만 상관관계는 피어슨 상관관계의 흥미로운 변형이라고 볼수 있다.
 원래의 선호값으로 상관관계를 계산하기보다는 상대적인 선호값 순위에 기반해서 상관관계를 계산하기 때문이다.
 각 사용자의 선호가 가장 없는 아이템의 선호값을 1로 고쳐 쓰는 경우를 생각해보자.
 그다음으로 선호가 없는 아이템의 선호값을 2로 바꾼다.
 영화 순위를 매길 때 가장 선호가 낮은 영화에 별점 1을 주고 그다음 영화에는 별점 2를 주는 식이다.
 그러면 피어슨 상관관계를 이렇게 변환된 값으로 계산할 수 있게 된다. 이것이 스피어만 상관관계이다.
 하지만 처리 과정 중에 몇몇 정보를 잃기도 한다.
 즉 선호값의 핵심인 순위를 보존하는 대신에 사용자가 각 아이템을 얼마나 선호하는지를 나타내는 값을 제거한 것이다.
 이것은 좋은 아이디어일수도, 좋지 않은 아이디어일 수도 있다.
 선호값을 보존하거나 아니면 전체를 잃어버리는 두 가지 가능한 경우를 이전에 살펴보았지만, 아마 그 중간 정도이지 싶다.
 
 이미지에서 스피어만 상관관계의 결과를 확인할 수 있다.
 이미 간단한 데이터 셋을 다시 간략화하기 때문에 일부 결과값이 극단적이다.
 사실 모든 상관관계가 여기에서는 1 또는 -1인데, 사용자 1의 선호값을 수용할지 아닐지에 의해 결정된다.
 피어슨 상관에서는 사용자 1과 사용자 3간의 값을 계산할 수 없없다.
 [스피어만_상관관계.jpg]

 
 
 # 캐시 랩핑
  > 클래스 : CachingUserSimilarity
 UserSimilarity의 결과를 캐시 처리하는 또 하나의 구현
 CachingUserSimilarity에서는 계산 처리는 다른 곳에서 하고 그 결과는 내부에 기억한다.
 나중에 사용자-사용자 간의 유사도값이 필요할 때 즉시 값을 변환할 수 있도록 미리 계산하고 다시 계산하지 않도록 구현한 것이다.
 이런 방법으로 어떤 유사도 구현에도 캐시 기능을 추가할 수 있다.
 계산 처리 비용이 상대적으로 높다면 캐시를 적용할 만한 가치가 있다.
 캐시를 사용할 때 발생하는 비용은 메모리 소모를 말한다.
 UserSimilarity similarity = 
     new CachingUserSimilarity(new SpearmanCorrelationSimilarity(model), model);


07 24, 2014 10:48 07 24, 2014 10:48


Trackback URL : http://develop.sunshiny.co.kr/trackback/1016

Leave a comment


Recent Posts

  1. HDFS - Python Encoding 오류 처리
  2. HP - Vertica ROS Container 관련 오류...
  3. HDFS - Hive 실행시 System Time 오류
  4. HP - Vertica 사용자 쿼리 이력 테이블...
  5. Client에서 HDFS 환경의 데이터 처리시...

Recent Comments

  1. 안녕하세요^^ 배그핵
  2. 안녕하세요^^ 도움이 되셨다니, 저... sunshiny
  3. 정말 큰 도움이 되었습니다.. 감사합... 사랑은
  4. 네, 안녕하세요. 댓글 남겨 주셔서... sunshiny
  5. 감사합니다 많은 도움 되었습니다!ㅎㅎ 프리시퀸스

Recent Trackbacks

  1. Mysql - mysql 설치후 Character set... 멀고 가까움이 다르기 때문 %M

Calendar

«   10 2019   »
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

Bookmarks

  1. 위키피디아
  2. MysqlKorea
  3. 오라클 클럽
  4. API - Java
  5. Apache Hadoop API
  6. Apache Software Foundation
  7. HDFS 생태계 솔루션
  8. DNSBL - Spam Database Lookup
  9. Ready System
  10. Solaris Freeware
  11. Linux-Site
  12. 윈디하나의 솔라나라

Site Stats

TOTAL 2724069 HIT
TODAY 535 HIT
YESTERDAY 589 HIT