Our recommendation engine operates as a multi-threaded server using RMI (Remote Method Invocation) as its communication protocol. Within the server, application logic and connection logic are separated. The server has two modes of operation, asynchronous and synchronous. When a synchronous request is received, an RMI connection thread contacts an application thread. If the application thread does not respond within a predetermined time, the RMI connection thread returns a time-out message to the client. With asynchronous requests, each request is queued and is serviced by the next available application thread. Once the request is queued for processing the connection thread returns a message confirming that the request has been scheduled.
In the case of Smart Radio, the client is either the servlet engine, or the database manager. Smart Radio users do not have direct access to the recommendation server. In order to manage the request load we use asynchronous requests for scheduled data management tasks, and recommendation updates. Such requests, although time sensitive, do not require a timely response.
Asynchronous requests
The flowchart in Figure 6.19 illustrates the data management process and the recommendation update process. The data update process, which we described in Section 6.4 is represented on the left of the chart in dark grey. The second column from the left in the flow chart represents the steps in the process that directly affect the recommendation server. As we can see there, the internal data model of the recommendation server is updated for selected user profiles, after the ACF tables are updated. Once this has been completed the recommendation notifies the remote user object of the date and time of the data update. The remote user object is an object, representing users who are currently on-line, whose methods can be remotely invoked by the recommendation server, the servlet engine or the scheduling component. It provides a communication interface between these components.
The second process represented in the flow chart in Figure 6.19 is the recommendation display/update process, shown in light grey to the right of the chart. The recommendation update process uses a combination of lazy invocation and scheduling. The basic idea is that a recommendation update is calculated for each on-line user periodically, but only if he/she has
submitted feedback in the interval. We define the recommendation_period_threshold as
the time interval after which a set of recommendations for an on-line user is recalculated, if the user has submitted data since the last recommendation update.
Thus, when a user requests the recommendations page, the web server firstly passes the request to the servlet engine which invokes the recommendation servlet. The servlet then checks whether new recommendations are required to be generated by the recommendation server. It does this by checking two pieces of information on the remote user object. The rec_date property gives the time of the last recommendation update for the user, and the recent_data_date
property gives the time of the last feedback from this user to have been recompiled into the server’s internal data model. The servlet issues an asynchronous request to the recommendation server, if the two following conditions are met
1. If the time elapsed since the rec_date is greater than the
recommendation_period_threshold.
2. If the recent_data_date is greater than the rec_date.
We use this combination of scheduled and lazy invocation for the recommendation process for two reasons. Firstly, as each recommendation request is relatively computationally expensive, we carry it out only if necessary. For example, even if the threshold period for generating recommendations has been exceeded, a recommendation update will not be requested until the user has submitted feedback and this data has then been compiled into the internal data model of the recommendation server. This ensures a level of consistency in the user’s interaction with the system – users will expect their recommendations to change only after they have submitted feedback.
Using a recommendation strategy that reacts immediately to user feedback leads to the problems we encountered in the first version of Smart Radio where users would enter bogus ratings in order to see what the recommendation engine would produce. We introduced the recommendation_period_threshold to delay the effect that new ratings have on recommendations, which should go some way towards frustrating the intentions of such users. Currently the recommendation_period_threshold is set at 20 minutes.
Figure 6.19: A flow chart demonstrating two asynchronous process flows
Synchronous requests
However, there are events in the system for which we require an immediate update to the recommendations for a particular user, in which case we use synchronous processing. Because of
their timing constraints synchronous requests have priority in the recommendation server. They are placed in a separate queue to the asynchronous requests. When application threads are free, this queue is serviced before the asynchronous request queue.
Bootstrapping new users
The first event for which we call upon synchronous request processing is the bootstrapping of new users. In Section 6.5.3 we describe how new users are asked to rate several artists. It is important that we can promptly provide these users with recommendations after they submit their ratings. In Figure 6.10 we provide evidence that the recommendation server should quickly be able to calculate recommendations using the user–artist data matrix. However, as it is possible for a synchronous request to time-out, our fall back strategy is to present the top ten playlists in the system at the time along with an apology. Synchronous requests that have timed-out will still be processed by the next available application thread, so that a set of new recommendations should be presented when the user refreshes the recommendation page.
Context ranking
The second event for which we employ synchronous requests is the calculation of user-context and the ranking of the recommendation set according to that context. One of the key recommendation strategies employed by Smart Radio is the boosting of recommendations according to the user’s perceived interests at the time. When a user plays a playlist we immediately re-rank his/her recommendations to reflect similarity to the last ten items that the user has not rated negatively. To re-rank users’ recommendations after a playlist event we employ a synchronous approach which is illustrated in Figure 6.20. After the user selects a playlist to play, the servlet engine generates a synchronous ‘context’ request and sends this to the recommendation server. The recommendation server calls the context analyser module which builds a case base representation of the user context. The playlist case base is then primed with the user’s ACF recommendations. The context case is presented as a target case to the case base and the top n ranked cases are determined to be the context-based recommendations that will be presented to the user. These cases are removed from the set of ACF recommendations and pushed to the top of the recommendation set that is presented to the user.
Figure 6.20: A synchronous request updates the recommendation database in response to a playlist being played
Users quickly learn that the recommendation set follows the trends in their listening preferences. In order to avoid any confusion about why the recommendation set has changed, we provide access to an explanation for each recommended playlist. As shown in Figure 6.21 there are two explanations. The first is a context-based explanation, and the second is an ACF-based explanation. We also make reference to the user’s novelty preference which influences the ACF ranking. Swearingen and Sinha (2001) and Herlocker et al. (2000) have found that user trust in the recommendation strategy is bolstered by revealing the reasoning behind each recommendation.
Query by playlist
By clicking on the query by playlist icon Smart Radio users can retrieve a set of playlists similar to the one they are currently viewing (see Figure 6.22). This facility allows listeners to zoom in on portions of the playlist case base of particular interest to them. When processing such a request the servlet engine dispatches a synchronous request to the recommendation engine, and waits for a response. When a response is received, the servlet engine invokes the JSP engine which dynamically builds a web page around a list of playlists received from the recommendation server.
Figure 6.22: The Query by Playlist facility allows users to request playlists similar to the current playlist
6.7 Conclusion
In this chapter we concentrated on the data architecture of the Smart Radio system. This architecture is concerned with the collection and manipulation of data to provide timely recommendations to our users. We use a combination of synchronous and asynchronous services to achieve that end. Our Data Manager converts log data into ACF data, which is then used to update the data model in the Recommendation Server. The Data Manager can derive implicit scores for track and artist data. We show that using implicitly derived artist scores helps us during the bootstrap phase, allowing the recommender to produce better predictions when a reduced amount of data is available. We demonstrate that Smart Radio is reliant upon the industry of a few playlist compilers whose names become well known throughout the user community, and we suggest that the role of community leader is the primary incentive for such users.
Since ACF is a lazy, data intensive recommendation strategy, we look at reducing the memory overhead and query-time computational expense. We suggest that the ACF technique is similar to a technique in CBR called case completion. We show how a memory structure used in
CBR can be applied with ACF. A Case Retrieval Net reduces memory overhead by storing each feature-value pair once as an information entity. Thus several cases may share the same information entity. Retrieval time is speeded up because local similarity calculations are performed once for each IE and distributed to case nodes that share the IE. As an example, we show how the calculation of the Pearson coefficient can be distributed among the IEs of the CRN during retrieval time.