Context-Aware Recommendation

• 대부분의 Recommender System (RS) 는 contextual information을 고려하지 않음

  • user와 item만 가지고 추천을 하기엔 부족함

• 소비자의 선택은 contigent of context decision making

  • 예를 들어 뉴스 기사를 추천한다 했을 때 시간 context를 고려하면
    • 아침 : world news
    • 저녁 : 주식 시장 뉴스
    • 주말 : 영화 리뷰나 쇼핑 ( 주말엔 보통 집에 많이 있기 때문

• Search Systems

  • Query가 가장 중요한(Overrriding) context
  • information need를 표현하는 가장 중심적인 entity가 Query

• RS

  • User가 가장 중요한(Overrriding) context → 이미 반영됨
  • User외에 다른 entity를 사용할 수 있을까?

Context in RS

• Characterize the situation of entities, 즉 RS에서 user와 item 이외에 entity의 상황을 설명할 수 있는 어떠한 정보들, 해당 entity는 유저와 어플리케이션 사이의 interaction과 관련되어 있음

Context Aware Systems

• Context를 사용해서 유저에게 관련된 정보나 서비스를 제공하는 시스템 → 유저의 행동에 기반하여

Event

• 내가 어떤 item을 소비한 것을 event라고 하면, 그 이벤트를 구성하는 여러 속성 (시간, 장소 등등)을 통해, 즉 과거 이벤트의 속성을 통해 지금 상황의 속성들과 유사한 아이템을 추천해줌
• Event를 노드로 표현하면, 과거의 이벤트 노드에 involve되는 사람, 상황, 아이템들이 있음. 지금 상황을 설명할 수 있는 value들이 있을 때, 관련된 이벤트 노드들을 통해서 관련 아이템으로 그래프를 지나가다 보면 적절한 아이템을 추천할 수 있음
  • but 그래프 알고리즘이 scalable하지 않기에 우선 matrix 형태로 먼저 보도록 하자

Context-Aware RS (CARS)

R : User x Item x Context → Rating

즉, Context라는 새로운 dimension을 추가

• ex) Movie Recommender System에서

  • Movie
    • MovieId, Title, Length, Release year, Director, Genre ….
  • User
    • UserID, Name, Address, Age, Genre, Profession …
  • Context : 과거 어떤 유저가 어떤 영화를 봤을때, 해당 이벤트의 속성을 다음과 같이 나타낼 수 있음
    • Theater : 어느 극장에서 봤는지 (Theater Name, Address, Capacity, City…)
    • Time : 언제 봤는지 (Date, Day of week, month, year …)
    • Companion : 누구와 봤는지 (companioin sex, companion type ….)

• 위를 통해 최종 Rating은 multi dimensional cube로 나타내어짐

• 각 contextual type는 hierarchical 구조를 가짐

  • Theater : TheaterID → City → State → Country
  • Time : Day → Week → Month → Quarter → Year

Determining Relevant Attributes

• 처음에는 Domain Knowledge를 이용해서 넓은 범위에서 Contextual Attribute들을 선택함
  • 영화같은 경우, 극장, 시간, 같이본사람, 날씨 등등
• 다양한 statical test를 통해 검증을 함
  • sunny days VS rainy days for weather attribute
• 즉 먼저 가설을 세우고 그 다음 맞는지 검증을 함
  • 정말로 weather attribute에 따라서 영화의 rating이 달라지는지 등등….
• Contextual Information을 얻는 것은 어려움
  • explicitly : 유저에게 그냥 물어봄
  • implicitly : sensor and/or other sources
    • location of mobile phone, weather info, time of transaction (rating event)

Incorporating Context to RS

Contextual Pre-filtering

U x I x C x R으로 이루어진 matrix에서 먼저 contextual 정보를 추출 (예를 들어 지금이 여름이면, 여름에 해당하는 아이템만을 특화해서)

뽑아낸 후에는 기존 RS 알고리즘을 적용 → 새로운 알고리즘이 필요하지 않다는 장점

ex) 유저가 일요일에 볼 영화를 추천받고 싶다면

1. 일요일에 해당하는U x I matrix를 construct
2. 2D RS 알고리즘 적용

하지만 sparsity problem이 존재 (일요일에 해당하는 데이터가 많이 없을 수 있음)

더 general한 context specification이 필요 → context generalization

Context Generalization

• Context 구간이나 범위를 filter out (일요일 대신, 휴일, 주말 등등으로 filter out)
• (Girlfriend, Theater, Saturday) → (Friend, AnyPlace, Weekend)

Item Splitting

filter해서 데이터를 제거하는게 아니라, 특정 context에 따라서 매우 다르게 rating이 되는 context로 filter가 된다면, 아이템을 다른 아이템으로 간주해서 weighting을 하도록

→ 덜 sparse해짐

Issue of Contextual Pre-Filtering

• 올바른 pre-filter나 item-split을 하는 것은 어려움 (featuer engineering)
• 높은 contextual granularity로 인해 computational cost 증가
• 데이터가 적어지기 때문에 sparsity 문제가 발생 → 우리가 train 해야 하는 parameter보다 데이터가 적으면 오버피팅 발생, 이로 인해 성능 저하

Contextual Post-filtering

처음에는 contextual information을 무시

우선 전체 데이터에 대해 기존 2D RS 알고리즘 적용

그 이후에 추천된 아이템들에 contextual filter를 적용 (휴리스틱하게)

• Contextual preference data를 분석하는 것이 가장 핵심이 됨
  • 주어진 유저와 주어진 context 내에서 특정 아이템 소비 패턴을 찾는 것
  • Heuristic 또는 어떤 모델의 classified 된 결과를 이용

Contextual Modeling

• Context 정보 자체를 모델링에 활용 (directly)
  • user, item, Contextual information 모두를 사용하여 모델링(= 데이터 전체를 모델에 주입시켜 학습하게 하는 것)
• 기존 2D RS 알고리즘은 못 씀

Tensor Factorization

• pre / post filtering 필요 없음
• N-dim 데이터도 handle 가능
• sparseness and overfitting
• O(K^3)이라서 실제로는 잘 안씀

Pairwise Interaction Tensor Factorization

• 앞서 3 dim(u, i, t)를 pair로 뭉쳐서 나타냄
• much fast runtime
• less prone to sparsity issue → 일반 Tensor factorization보다 덜 sparse해짐