An Evaluation Framework for Interactive Recommender System

TL;DR

This paper introduces a simulation-based evaluation framework for interactive recommender systems, enabling researchers to assess and tune their algorithms efficiently before conducting extensive user studies.

Contribution

The authors propose a novel simulation framework with metrics to evaluate interactive recommenders, reducing reliance on time-consuming user studies and improving algorithm tuning.

Findings

Framework allows simulation of user interactions

Metrics evaluate recommendation quality post-simulation

Facilitates pre-user study tuning of algorithms

Abstract

Traditional recommender systems present a relatively static list of recommendations to a user where the feedback is typically limited to an accept/reject or a rating model. However, these simple modes of feedback may only provide limited insights as to why a user likes or dislikes an item and what aspects of the item the user has considered. Interactive recommender systems present an opportunity to engage the user in the process by allowing them to interact with the recommendations, provide feedback and impact the results in real-time. Evaluation of the impact of the user interaction typically requires an extensive user study which is time consuming and gives researchers limited opportunities to tune their solutions without having to conduct multiple rounds of user feedback. Additionally, user experience and design aspects can have a significant impact on the user feedback which may result in not necessarily assessing the quality of some of the underlying algorithmic decisions in the overall solution. As a result, we present an evaluation framework which aims to simulate the users interacting with the recommender. We formulate metrics to evaluate the quality of the interactive recommenders which are outputted by the framework once simulation is completed. While simulation along is not sufficient to evaluate a complete solution, the results can be useful to help researchers tune their solution before moving to the user study stage.

Full text

K****eywords Recommendation System  $\cdot$ Preference Elicitation  $\cdot$ Dialogue Systems

1 Introduction

Most real-world recommender systems support very limited interaction where feedback and preferences are based on user item history and ratings or additional context information provided by the user which can become outdated [1]. In order to overcome this challenge interactive recommender systems have gained attention by allowing users to have more control and making them more actively involved in the process of their recommendations. One challenge that has made it difficult for researchers to progress in this field is that, there exists no standard evaluation mechanism for such a framework. As a result, we have developed a sound evaluation framework to simulate users as if they are interacting with the recommender. The interaction we designed assumed to be performed via conversation. The system can work with any recommender algorithm that supports recommendations based on a user profile and adapting the recommendations based on the learnt preferences. In addition, we formulated metrics that combine measures from two related areas of research, recommendation systems and dialogue management, in order to evaluate the interactive recommender from both recommender accuracy and dialogue quality perspectives.

The interactions considered during designing the framework are as follows:

• •

Item feedback. A user can accept or reject an item.

• •

Item exploration, explanations and correcting incorrect assumptions. A user can examine item details or ask for explanation for why an item is recommended. Once a user understands the motivation behind a recommendation, then the user has the opportunity to correct any incorrect assumptions. For example, the recommender may provide an explanation such as "I recommend this movie, because you prefer to watch Action and Fantasy". If the user does not actually like Fantasy, then the user may correct this via telling "But I do not prefer Fantasy".

• •

Providing explicit preference. A user can provide preferences (negative/positive/complex) towards features of items at any point of conversation. The preference can be provided as a positive (e.g. I like horror movies.) or negative (e.g. I do not like romantic comedies.) preference towards a single feature, or a compound feature including both a positive and a negative preference, (e.g. I want to watch a movie of Keanu Reeves, but not a romantic one.)

• •

Preference elicitation. The system can provide the user with a choice of features to provide feedback on, to enrich the user preference profile ( e.g. Do you prefer comedy movies?). The preference elicitation implemented uses a feature selection method based on Information Gain [2] to select the features that can split the recommendation space better and allow the recommender to filter out candidates. The output of the preference elicitation process is therefore the feature whose value will be asked to the user.

Although the framework currently only supports the above interaction mechanisms, the solution is generic enough to support extensions to other interaction mechanisms as needed.

2 Proposed Evaluation Framework

2.1 Overview

In order to run the evaluation framework, any recommendation dataset that includes user-item ratings together with the item related data can be used. The data for each user is split into training and test, where the training items are used to generate the first set of recommendations and the test items, which is called as the look-ahead data, is used to simulate the interaction.

The simulation framework supports different conversation states where the look-ahead data is used to determine the simulated users responses for each conversational state. Each interaction is captured by a conversation state denoted by the nodes in Figure 1. The look-ahead data is used in order to determine the simulated users’ choices at each state. The child nodes of each parent node reflect the possible next states that are chosen either by randomly or by leveraging the look-ahead data. For example, when items are recommended, users may reject all of them or they may want to explore one of the recommended items to observe the properties of it and seek an explanation for why that item was recommended. Alternatively, the user may accept items, or they may provide explicit preferences based on the features of the recommended items. Without loss of generality and considering all the possible interactions users may experience with any conversational recommender, we created simulated users by following the interactions outlined in Figure 1 and the underlying algorithm is summarized in Algorithms 1, 2, 3.

2.2 Conversation States

The goal is to simulate user interaction until the user breaks the conversation. Figure 1 shows the currently supported conversational states.

Interaction initialization state (state 0): At this point there are 4 possible interactions; recommendations’ presentation (state 1), system asking a preference elicitation question (state 2), user providing explicit preference (state 3), and user breaking the conversation which ends the whole evaluation dialogue with a test user (state 4). Next state is chosen in a weighted random manner.

Recommendations’ presentation (state 1): The look-ahead data is used to assess the user’s reaction to the recommendations. If the user has negatively rated the presented items, then state 9 is selected. If the future items in the look-ahead data have no rating for the presented items, then we infer that the user has no interest for the suggestions (state 10), whereas if the user has positively rated at least one recommended item, state 11 is selected.

Preference elicitation (state 2): The system generates a preference elicitation option for the user, and the option selected is determined based on the look-ahead data, where the features associated with future items are used to infer the preferences of the user. Recommender can ask questions to elicit user preferences from dialogue which is illustrated by state 2. The feature being asked for eliciting preference is selected by choosing the feature with the maximum information gain among the recommendation items.

User providing preference (state 3): In a similar manner to above, the look-ahead data is used to examine the features of the future items, where we can generate a preference the user chooses to give to the system. e.g. I dont like romantic movies..

For the state of providing complex preferences (state 6), if no negative features are found in the lookahead data, to simulate user providing complex features, the simulation proceeds as follows: It checks whether there is any positively weighted feature in the current learnt profile that does not exist in the positively rated items of the look ahead data. This corresponds to the scenario where users changed their mind for previously liked features.

2.3 Algorithmic Details

The underlying algorithms used to evaluation framework are summarized in Algorithms 1, 2, 3.

Algorithm 1 details the main algorithm behind the running the simulation framework. The goal of simulated user is to chat with the system until a point when the user wants to break the conversation. The boxes in Figure 1 corresponds to different conversation states that the system can be at during any point of the dialogue. The boxes are further numbered for the sake of easy referral within the paper. The box labelled as Conversation State, which is state 0, stands for the state where the evaluation framework selects between four possible interactions, namely, generating recommendations, system asking a preference elicitation question, user providing explicit preference, and user breaking the conversation which ends the whole evaluation dialogue with a test user, in a weighted random manner. This is illustrated with ProbRand() function at line 33 of Algorithm 1. For the evaluation, from each dataset 80% of the users are randomly selected to be used in training the recommender, and remaining 20% are used to evaluate the solution. For each test user in 20%, first 80% of the movies are used to generate recommendations and remaining 20% is used to simulate the interaction, where this 20% stands for a look-ahead data for the evaluation framework, such that, we pretend as if users future choices are in these 20%.

For each test user, the conversation starts with the system generating the recommendations (line 1 of Algorithm 1). For each next turn of the conversation, one of the four states are chosen on a weighted random manner, such that, each state is assigned a probability value, where a probability value of 0 ensures that, corresponding state never gets selected and probability value of 1 ensures that, it is always being selected. Sum of the probabilities of four states adds upto 1. If the system generates recommendations (line 3 of Algorithm 1), the possible interactions of the user are accepting at least one of them (lines 7-8 of Algorithm 1), rejecting all of them (line 10-15 of Algorithm 1), or showing no reaction which simulates the fact that user does not show any interest at all (line 17 of Algorithm 1) to any of the suggestions. In order to simulate this, the evaluation framework checks the look-ahead data, which is the remaining test set of the test user, and observes whether there exist any intersection between the test set and the generated suggestions. Each accept or reject results in shrinking the test set with the corresponding items and adding them to the training set for that test user, which is performed by UpdateProfile() calls in Algorithm 1.

In the case of reject, which is state 9 in Figure 1 user may either explore or seek explanation for an item, or may not provide any further feedback. If explores or observes the explanation, user may inspect an incorrect assumption that the recommender has made, so user may provide feedback which can be a single feature or a complex one. This reflects a use case scenario where the recommender may provide an explanation with the features it used to recommend that item, however, the user may inspect that, features being used positively by the recommender are not the ones user likes. For example, recommender may explain recommending movie November Rain by saying "I recommend you November Rain because you like Keenu Reeves, Charlize Theoron, movies from US and Romantic movies". User may correct the recommender by responding with a complex answer involving a positive and negative feature, such as, "I like Keenu Reeves but I dont like Romantic movies". To simulate this, the evaluation framework follows the methodology outlined in Algorithm 2. It first extracts all the negative and positive features based on movies in test set (lines 2-5 in Algorithm 2), and loops over recommendations to find out whether there exists a movie that has one of those negative features (lines 6-17 in Algorithm 2). If so, it checks whether the movie contains a feature from users positive features from test set as well (lines 10-14 in Algorithm 2). If both negative and positive feature exists, it assumes the user responds with both positive and negative features, which leads to state 17. Otherwise it assumes user responds with just correcting the incorrectly assumed positive feature, which leads dialogue to enter state 16.

User can provide explicit preference, as represented by state 3 in Figure 1. The provided preference can be a single positive feature (state 7), a single negative feature (state 8) or a complex feature which involves both a positive and a negative feature (state 6). In order to simulate this, the evaluation framework uses the look-ahead data, and selects the most positive and negative feature, which is outlined in Algorithm 3. For each user, while the user profile is being built by the recommender, maximum, minimum and average feature weights are being kept as part of user profile. All features having weight less than the average feature weight are assumed to be negative (line 2 of Algorithm 3). Similar hold for the positive case. Most negative and positive features are being returned by the ProvideFeature() call of line 20 of Algorithm 1. These features are set to either to minimum or maximum feature weights kept in user profile for the negative and positive states accordingly by the UpdateProfile() call at lines 22, 24, and 26 of Algorithm 1.

Recommender can ask questions to elicit user preferences from dialogue. This is illustrated by state 2 of Figure 1. The feature being asked for eliciting preference is performed by selecting the most informative feature among the recommendation items as explained in section 3.1 of the paper.

The Rand() calls at lines 11,12, and 19 of Algorithm 1 randomly selects between the states, however, ProbRandom() at line 33 selects based on weights assigned to states 1-4 within the evaluation framework.

3 Metrics

Typical recommender system metrics focus on the accuracy of a presented list, however, considering interactions with the user, we want to be able to capture what the overhead is on the user. For example, simply rating movies might take quite a number of recommendations to hit a successfull recommendation, whereas asking the user if they prefer drama or horror might lead to success with a smaller number of interactions. As a result, we designed a number of metrics to evaluate not only the accuracy of the recommendations but also the amount of additional interactions between the user and the recommender needed, which reflects the quality of the interactions.

• •

**DialogTurn (DT): ** #dialogue turns, where each utterance of the user and the recommender is counted as one turn. In other words, each individual turn per user and recommender is counted separately and added to DT. ex: user presenting a preference, recommender generating suggestions, etc.

• •

DialogSuccessRate (DSR): avg #successfull recommendations presented to the user during per dialogue turn.

• •

**RecommendationTurn (RT): ** #times recommendations are presented to user. DT increases even if user presents a preference and

• •

RecommendationSuccessRate (RSR): avg #successful recommendations generated per one recommendation turn.

• •

**AP@k: ** average precision of top k recommendations [2], used in calculation of AP@kDT. AP@k is calculated by looking at the ground truth, which reflects whether the user likes each item in reality as opposed to generated suggestions at specified ranks. Based on this, AP@k is calculated by taking the average of precisions computed at each liked position in the top ık items of the user’s ranked list.

• •

AP@kDT: avg normalized AP@k by the #dialogue turns.

• •

AP@kRT: avg normalized AP@k by recommendation turn.

We use RT as a different metric from DT, as we believe RT reflects the success of interactive recommenders better than DT, which is used to evaluate dialogue systems in general. We integrated these metrics within the framework, and at the end of the evaluation with each test user, the average of the calculated metrics over test users is presented. The evaluation framework outputs the values calculated for these metrics once the evaluation for each test user is completed.

4 Examples of Conversations

Sample execution logs of the evaluation framework are presented in the following Figure 2 for two sample test users, where for the first one, user breaks the conversation sooner than the second one.