We describe an architecture for generating context-aware recommendations along with detailed textual explanations to support the user in the decision-making process. CARE (Context-Aware Recommender with Explanation) incorporates a hierarchical structure, in which independent modules embodying di erent aspects of the context cooperate together to generate recommendations for the user with accompanying rationales. We follow the Interaction Design principles to develop personas, goals and user scenarios, based on which a prototype system is developed. We present here two examples of its performance when processing movieratings data set with contextual information. We argue that our architecture is extensible in that more modules can be added as needed, and the approach can be applied to other domains as well. context-aware recommender system, recommendations explanations, interaction design
An increasing number of available resources, and easy online access to diverse goods has resulted in data overload, making it di cult for many users to decide what items to select, which often slows down their decision-making process. A growing number of choices is leading to an emerging interest in the development of decision-support systems to help users in nding the most interesting or suitable items for their personal needs. Most of the research in this domain is focused on improving the accuracy and precision of recommendations. However, it is equally important to provide the user with some rationale for why a particular item is being recommended to them. Moreover, in some domains such as legal decision-making or moral and ethical reasoning, the justi cations for recommendations are very crucial. Hence, the main focus of our work is to design a system that can explain why the user should select particular items. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
Joint Workshop on Interfaces and Human Decision Making for Recommender Systems, RecSys 2015, Vienna, Austria Copyright 20XX ACM X-XXXXX-XX-X/XX/XX ...$15.00.
As observed in [
As the main focus of our research is to improve user's
experience and understanding during the interaction with
the system, we designed a Context-Aware Recommender
with Explanation (CARE) system, following the Interaction
Design paradigm [
We motivate here our approach in the context of the current state of the art, summarize the interaction design process, and present examples of persona and scenarios. Then we describe the system architecture and present some results generated by our prototype implementation. 2.
As de ned in [
Content-based recommenders try to nd items similar to
what the user previously liked [
A signi cant problem in many recommendation techniques is the cold-start problem, which occurs when a new user or a new item is presented to the system and there is not enough data to perform a reliable prediction - the user has not rated enough products to de ne his or her preferences, or an item has not been rated by a su cient number of users.
Content-based recommenders deal well with situations when a new item is added to the system. It also maintains independence among the users as a particular user's ratings are su cient to perform the recommendation process for that user. For our research, a major advantage of content-based recommenders is their transparency | the features that triggered the recommendation results may be listed along with the output.
However, content-based recommenders su er from overspecialization: i.e. they recommend items similar to those seen in the past, preventing a serendipity of recommendations. Also, when a new user, who does not have a previous history with the system and so lacks any ratings, enters the system, the cold-start problem may occur.
Content-based analysis operates on vectors representing features of each object. Two basic techniques for ltering similar items are similarity calculation (such as cosine similarity) and distance measurement (such as Euclidean distance). 2.2
Collaborative filtering recommender systems
In collaborative ltering (CF), a user's preferences are
predicted based on modelling other users behaviors [
This approach su ers from the data-sparsity and newitem problems. Another disadvantage is that collaborativeltering recommenders mostly work as black-box systems, therefore they lack transparency and cannot explain why certain items are being recommended. However, this approach is proving to be an e ective technique for making recommendations and is widely used in commercial applications. It has an advantage of being able to recommend items with unknown content. CF also supports serendipity in recommendations, for recommended items may di er signi cantly from the previous ones.
Common approaches to CF for recommendations use
neighbourhood-based or model-based methods.
Neighbourhoodbased methods try to nd the most similar items (item-based
approaches) or most similar users (user-based approaches)
when predicting the rating of an item for a particular user.
Basic technique may incorporate correlation measures (such
as Pearson's similarity) when comparing the vector of
ratings for users or items [
As observed in [
Standard approaches for CARS implementation
incorporate contextual pre- ltering (items ltered by context before
recommendation), post- ltering (context applied to
recommendation results) and contextual modeling (context as a
part of ratings prediction). Common approaches based on
standard pre- ltering techniques represent item and
usersplitting algorithms [
Some recommenders are implemented as knowledge-based
systems [
Another approach is to use demographic information about the users to predict their tastes based on their social group. Such recommendations may depend on user's age, gender, nationality, and so on. 2.5
Each of the techniques mentioned above has some
advantages as well as some drawbacks, and each may be e ective
for a certain domain or a certain type of problem [
Weighted: the scores from several recommenders are weighted into one result.
Switching: the most appropriate technique is selected depending on the input data.
Mixed: outputs from diverse algorithms are presented simultaneously.
Feature combination: features of di erent algorithms are combined into a new feature.
Cascade: the recommendation is performed hierarchically and the outputs are re ned by the subsequent recommenders.
Feature augmentation: output from one system is the input to the following one.
Meta-level: the model created by one system is used by another. 2.6
Hybrid recommender systems are often implemented based
on diverse multi-agent system (MAS) architectures.
Distributed approaches to recommendations have been
previously studied in [
Another example of MAS architecture that may be used
for implementing a recommender system is the blackboard
architecture. This architecture may be visualized by the
metaphor [
The blackboard model provides an e cient platform for
problems that require many diverse sources of knowledge.
It allows a range of di erent experts represented as diverse
computational agents, and provides an integration
framework for them. It seems a promising platform for
recommendation tasks, and has already been incorporated in [
CARE (Context-Aware Recommender with Explanation) is built as a hybrid architecture that adapts a mixed approach to recommendations, and incorporates some features of the multi-agent blackboard architecture. We implemented each module as an independent subsystem that uses some particular approach to generating a recommendation by incorporating a particular contextual feature. As some of those factors may be non-deterministic, we present the nal result as an array of alternate choices and allow the user to choose from the recommendations generated by analyzing diverse contextual factors. Hence the diversity of nal recommendation outputs is ensured by presenting the analysis from multiple points of view. This approach also incorporates serendipity, and gives the users a choice of possible actions. The users actions can be noted and used for ordering future recommendations.
Our solution also embodies some aspects of the feature augmentation approach | we perform the recommendations hierarchically on di erent levels of abstraction. We introduce some inter-level recommenders that are responsible for de ning the features of items that are most liked by the users in a given context. Their outputs are used to lter the data with identi ed characteristics, which is then sent as an input to the higher layer of recommendations. 3.2
Most of the solutions for automatic recommendations are focused on development of techniques improving the overall performance and accuracy of ratings prediction. Accordingly, most popular evaluation approaches incorporate precision metrics for the estimations. However, there are other factors that impact the e ectiveness of recommendations and in uence the user experience.
A major limitation of the existing recommendation
systems is overspecialization and a lack of diversity in
recommender outputs [
In our research, we aim to address some of these subjective criteria to improve user experience, and also develop an architecture that is easily adaptable to other domains. We use contextual ltering to model user preferences. Our architecture enables one to implement exible and generic recommender systems that can easily be extended with new independent modules in a hierarchical structure. Our approach promotes diversity and serendipity among the recommendation outputs as each module processes information from a di erent point of view. 3.3
We mentioned above that aspects such as user
satisfaction play an important role in the evaluation of a
recommender system. As noted by [
In CARE, each module is provided with an explanationgenerating function, which produces a description of the features that determined the recommendation. The style of this message is dependent on the module's implementation. The nal explanation may combine di erent styles of messages produced independently by separate modules. We incorporate modules that process information on di erent levels of abstraction, hence the nal description contains rationales at multiple granularity levels. Our goal is to generate a rationale explaining to the user why she or he should nd certain items interesting (contextual reason, e.g. because it is rainy and what features make this particular item a relevant choice (e.g. because you like rock music when it is rainy). 4.
In designing the CARE system, we follow the principles of
Interaction Design [
Following the Interaction Design paradigm, we consulted a lm analysis academic to nd out what factors may in uence the popularity of a movie among the users.
The expert noted that the genre is not the only feature that the users consider when deciding which movie to watch. Other factors which may determine their preferences are narrative description, its tempo, atmosphere and tension.
Moreover, the users often want to watch the same kind of movies that they have already watched. Thus, they select well-known names, plots or recognizable brands. Such a brand may be de ned by the director, movie star or award such as Oscar or some Film Festival.
Considering all these factors, our system design should embody modules that analyze relevant movie features such as genre, cast, director, awards won as well as information about the atmosphere of the movie. The prototype implementation incorporates the genre ltering modules, and we plan to extend it with modules that will analyze other factors as well.
Another major factor that in uences a user's choice is the current trend or fashion. There are some must-see movies that many users desire to watch. Moreover, some people rely on the public opinion more than on their own impressions. In our design, the public opinion is modelled by a collaborative ltering recommendation algorithm. 4.2
We interviewed three potential users to determine their expectations from a recommender system. The volunteers were technical faculty graduates who are familiar with using recommender systems to nd items of their interest. Each of them was interviewed separately, in their natural environment. They were asked to describe their experiences in one of the three domains of recommendations: books, movies and music. First, each person was asked to describe his or her general preferences in the given area and if they could identify some factors that may in uence it. Then they were asked to describe some particular situations in which they use recommendations, considering the context details. The nal question was about the expected recommendation output in these situations. We are planning to extend this research by incorporating interviews with a broader group of users with more diverse backgrounds.
It was observed that every person has some general tastes, but particular preferences change according to the time and the mood. Thus, the system should consider some contextual information in generating the recommendations. However, some of these factors, such as the user's mood, who they are with, and so on, may be di cult to predict. Hence the approach we chose is to give the user a choice of possible actions considering di erent contextual or a ective states so that the user can decide what she or he needs at the moment.
Finally, we found that the users like to know why any particular item is recommended to them. Hence the system should aggregate information from di erent levels of abstraction, and present it to the user in an intuitively understandable way. We plan to present a rationale for each recommendation as an accompanying text message. 4.3
Goals: getting movies recommendations; nding uncommon yet interesting movies when alone; nding lights comedies to watch with his girlfriend
Scenario 1
It is a cold winter Friday and Mark and his girlfriend want to spend the evening with a light movie and a glass of wine. Mark opens CARE and a message pops out:
Hi Mark! Finally, it's the weekend! It's freezing, isn't it? Are you dreaming of little holidays? What about Woody Allen's "Vicky Cristina Barcelona" to warm you up a little? I know you like this director. Or maybe you had a tough week and feel like watching something to cheer you up with a bit of dark humor, like "Grand Budapest Hotel"? Scenario 2
On Monday, Mark's girlfriend is o for a ladies night with her friends so nally he can choose a movie on his own. CARE greets him:
Hi Mark! Maybe something positive for the new week? How about "Intouchables"? Or maybe you're fed up with the city life in Krakow and want to watch the story of a man in the heart of nature, like "Into the wild"? You like non- ction movies! 5. SYSTEM ARCHITECTURE OF CARE
General architecture of the CARE system is presented in Figure 1. Modules in our prototype system work on di erent levels of abstraction.
First group of modules perform contextual features ltering based on the input with current context, user information and ratings history with context. The goal of this processing phase is to determine the most relevant item features for a given context. Each component on this level analyzes the information about a single contextual information. To address the problem of sparsity, we also incorporate a module that considers all users' ratings without any contextual ltering. The output of each lter is a list of items characterized by the identi ed features. This architecture is extensible with di erent types of lters that analyze other aspects of recommendations (such as demographic data). In this paper we focus only on the contextual information processing.
In the next stage of recommendation process, we incorporate recommender algorithms that select items that should be most liked by the user, considering each of the item groups received from the former stage as a separate recommendation problem. The modules on this stage may represent diverse recommendation techniques and algorithms, however our prototype implementation includes collaborative ltering algorithms. The result of recommendation is the best choice of items for each set of items.
Each component generates a short description of its results and the reason of recommendation. The messages are nally composed by the explanation templates module and presented to the user along with the recommended items.
The hierarchical structure of the system and the inter-level ltering of item features enables a more thorough explanation of the process in generated outputs. Hence the output does not only provide the user with the information Item A was recommended because it is summer, but also emphasizes the feature that was crucial for this choice (Item A was recommended because you seem to like this type of items during summer.).
The system is being developed using Django, a Web framework for Python. The system interface will be provided as a web application, however at present the system output is in plain textual form as presented in the results section.
We present phases of the recommendation algorithm along with an illustrative example of recommendations for user John. 6.1
CARE system architecture is applicable to many
recommendation domains where the context may in uence user
preferences. Possible domains of application include books,
music or movies as well as restaurants recommendations
as user's choice may depend on aspects such as changing
weather or time. Here we present the results from testing
our prototype on the LDOS-CoMoDa dataset [
The dataset also contains information about the mood of the movie and it could be interesting to consider this data as well. However, the dataset only provides the dominant and end emotional values, without any information about the user's mood before watching the movie. Since we treat contextual factors as facts known at the moment of recommendation (as the initial data), we cannot make a recommendation considering user's mood after or during watching the movie. In future work, we plan to add a feature to query user's mood at the moment of recommendation, and consider this information as a contextual parameter.
Table 2 contains a part of John's ratings for the analyzed example along with contextual information. 6.2
We present below a brief description of the di erent stages of our algorithm along with illustrative examples. The main steps of algorithm are listed below and described in the subsequent sections: 1. Initialization with contextual input data. 2. Contextual type-splitting - identifying signi cant contextual factors and relevant data types. 3. Collaborative ltering items recommendation for each of the types de ned in 2. 4. Explanation generation for each of the recommended types and a corresponding contextual factor. 6.2.1
Input for the recommendation is the user data and the information about the context in which the recommendation takes place. This data may contain information explicitly provided by the user (such as whether they are alone or with a companion) or implicit information extracted automatically from the date and location data (such as day of week, time of the day, weather, and so on).
Season: Summer Day type: working day Time: evening Weather: sunny Companion: alone 6.2.2
For the context-aware recommendation process, we introduced contextual type-splitting algorithm which is an adaptation of the standard contextual item-splitting approach. We incorporated an additional abstraction level and treated the item features as the recommendation objectives. Table 2 illustrates the di erence between approaches.
In the rst phase of the basic algorithm, each item is associated with the most relevant contextual feature that diversi es its ratings. Then the ratings for this item are split according to this division. The mean rating values for each item are compared for the situation where particular circumstance occurs and otherwise. For example, we could compare ratings for a particular movie that were given during the weekend with ratings from all other days. If they are signi cantly di erent, we can infer that the user preferences for this item are in uenced by the day of the week.
In our approach, we perform analogical computations, but instead of comparing the contexts for each movie, we analyze each context for a group of movies with a common feature (such as a genre). As a result we can, for example, nd out that the user prefers to watch horror movies during the weekends than on other days. This step may be generalized to recommend items grouped by other features, such as the director, country of origin, etc.
This approach allows us to give more transparent and intuitive recommendations for the user by presenting the features that lead to the nal recommendation. It also addresses a major drawback of the context preltering approaches, namely the data sparsity after applying the lter. As the number of recommendations for a particular type of movies is signi cantly higher than for each movie separately, we expect the results to be more accurate. Reducing number of comparisons to groups of items also contributes to decreasing complexity of computations and speeds up the recommendation process. In subsequent steps, the recommendations are performed for selected groups only.
We verify the signi cance of each contextual feature using
the two-tailed Student's t-test, assuming the p-value
threshold of 10%. Additionally, we consider the signi cance of
only those features where the mean rating is higher when
a particular context occurs. The t-test is a basic approach
(as presented in [
The features signi cance testing in a context is performed as follows:
For each type ti of items (eg. for each of the genres) we compare the mean rating for items of this type when each of the input contextual circumstances ci occurs and otherwise (eg. ratings for comedies in summer and other seasons). signif icance(ci; tj ) = ttest(Ratingstjjci ); Ratingstjj:ci ) If the statistical test for both groups of ratings split by the contextual feature ci indicates a signi cant difference in mean ratings, and the mean rating for type when ci occurs (Ratingstjjci ) is higher then otherwise (Ratingstjj:ci ), we conclude that the type ti is a relevant recommendation in given context ci.
Input context: summer, working day, evening, sunny, alone Ratings in summer vs other seasons: mean ratings for comedies are signi cantly higher during summer.
Ratings on working days vs other days: no relation found.
Ratings in the evening vs other time: mean ratings for comedies are signi cantly higher in the evening.
Ratings on sunny days vs other weather: no relation found.
Ratings for movies watched alone and other companion: no relation found. 6.2.3
After identifying the types of movies that are most relevant for a given context, we lter the set of ratings for each type separately. For example, if we consider a recommendation for Saturday morning and we nd out that horror movies are the most preferred genre during the weekend, and comedies get the highest ratings in the mornings, we rst consider recommendations for horror movies and then for comedies separately.
We also calculate general recommendations considering the user preferences of all the items, without any pre- ltering. This addresses the sparsity problem for context recommendations and deals with the situation when no relevant contextual information is provided.
After ltering the items by their types, we perform a standard collaborative- ltering recommendation algorithm to nd the most suitable choices considering a particular user's taste. We calculate the similarity between users using Pearson's correlation measure. Then we consider the ratings of the most similar users with the K-Nearest-Neighbours algorithm. In further research we plan to address the problem of scalability by users clustering.
For each of the identi ed categories we perform a separate recommendation process, hence the nal output contains the recommendation results from diverse perspectives. For the current implementation, we incorporated the standard user-based CF algorithm. However the system may be easily extend by other modules performing di erent recommendation algorithms since the calculations are performed independently.
A major goal of our research is to develop a recommendation system that can present the recommendations along with accompanying explanations. Hence, we incorporated modules responsible for generating textual messages to give rationales for recommendations. Each sentence of the accompanying message consists of the following information: item type; recommended item; context.
The message is generated in the form of a textual template. Future improvements of CARE will consider increasing the serendipity aspect of the recommendations by generating more advanced and surprising commentaries for the outputs.
The messages generated by all the modules that analyzed the situation from di erent perspectives are aggregated in one template and presented to the user as a message.
Producing a textual explanation containing descriptions from all former steps of algorithm:
Hi John! You might like a comedy "Le Concert" as it is something in your taste. You might like a drama like "Shutter Island" because it is evening. Maybe you feel like watching a comedy like "Intouchables" because it is summer?
CONCLUSIONS AND FUTURE WORK We proposed an architecture to generate context-aware recommendations along with accompanying rationales to help the user choose the most interesting item. In CARE (ContextAware Recommender with Explanation), the recommendation process is performed hierarchically, and with transparency at each abstraction level so as to produce detailed explanations for the suggested choices. Our approach promotes a diversity of recommendation results since each piece of contextual information is analyzed separately, and the most appropriate items are recommended with a rationale accompanying each suggestion.
Our architecture enables one to implement a exible and generic recommender systems that can easily be extended with new independent modules in a hierarchical structure. In the current stage of our research, we have tested the performance of the CARE prototype on a movie-ratings dataset. Following the suggestions of a domain expert, we plan to extend the system with modules that incorporate other diverse movie features such as the director, cast, atmosphere and so on. We also plan to follow the Interaction Design principles during the evaluation of our system and will perform user testing with a working system. In future work, we will also address the evaluation of results quality with standard methods such as RMSE or nDCG.
Our approach is applicable to other domains as well. Currently we are working on adapting this architecture for supporting legal decision making, and moral and ethical reasoning. 8.