Although the actual state-of-the-art on Recommender Systems is good enough to allow recommendations and personalization along many application elds, developing a general purpose multi-algorithm recommender system is a tough task. In this paper we present the main challenges involved on developing such system and a system's architecture that allows us to face this challenges.
There is a lot of literature on Recommender Systems for
speci c online domains like social software items [
We wanted to integrate a recommender system in Wipley1,
our social network for videogamers launched by the end of
2009. With this purpose, we worked on a recommender
system for videogames using a collaborative ltering approach
with multidimensional and contextual features to t this
particular domain. After that, we wanted to improve the
recommender with a content-based recommender system for
those games with none or few ratings and a social-based
recommender system [
Although there exist several commercial approaches to general SaaS recommender systems, like Strands3 or DirectedEdge4 there exist no literature focusing on the system's aspects of general recommender systems. In this paper we describe our experience developing our general purpose multialgorithm recommender system, which is currently being used to personalize our products and services at BrainSins and will be used as experimental platform to compare and evaluate our further research on recommender systems. In the next section we describe the main challenges we found in order to develop a general purpose multi-algorithm recommender system. In section 3 we describe the general architecture of the system focusing on the elements that allowed us to solve the main issues, and in section 4 we focus on our recommender system API, which enables all our products and services to interoperate with the recommender system. Section 5 describes the next research works we will face, and section 6 concludes the paper.
When designing a general purpose multi-algorithm recommender system, we found several challenges that had to be addressed in order to develop a useful system.
Interoperability: Recommender systems are usually created to access a speci c database that uses a wellknown data structure. However, since our system had to o er the possibility of being integrated into several di erent existing platforms, we had to deal with the problem of accessing sources with di erent data structures. 2http://www. ickrbabel.com 3http://recommender.strands.com 4http://www.directededge.com Con gurability and easy of use: As one of the main goals of this recommender system was to be able to manage several recommender algorithms to provide a particular recommendation, the system had to be highly con gurable. In these cases usability may become a problem di cult to solve.
Performance: Recommendations must be served in real time, but users do not tolerate an increase in page downloading time. However, when a system is designed with a high degree of con gurability, there are always some issues that slow down performance. In our particular case, the new system had to be as e ective as the recommender we already had on production. Disk usage: A highly con gurable system also presents disk space problems, due to the fact that data representation cannot be optimized.
Scalability: When applied to the web, the number of items to be recommended and the number of users to receive those recommendations often grow exponentially. Therefore, a recommender system needs to be scalable in order to grow at the same rate. However, being scalable also means that the system should somehow hide the way it scales, so there should be no need to code or rewrite con guration parameters in the products and services that access the recommender system.
After analyzing possible solutions for those challenges and start designing and developing the system, we thought that a key fact to achieve most of them was to conveniently separate recommendation process from the interface with the clients, so interoperability became our rst focus. Our goal was to design a way to easily integrate the recommender system while keeping recommender complexity hidden from its clients, so we designed a REST API. REST APIs are easy to use and to integrate in any product and service on the web, and many developers are familiar to it. Furthermore, REST API helps to hide the complexity of the recommender system, and allows to transform the REST petitions into more complex data structures needed to maintain the performance and scalability of the recommender system.
To face con guration and performance issues we designed a back-end architecture that enables us to de ne recommendation algorithms as software modules that can be adapted to any domain required by clients. The REST API also allowed us to introduce con gurability elements as optional parameters in the petition.
The input to our system are API requests, which can be classi ed as online or batch:
Online requests, which must be handled in real time. Their processing can't be delayed, because users are waiting for a response. They are also utilized to update the pro le for new users and begin to provide them with recommendations.
Batch requests, which may be stored and processed only at given time periods. Now requests processing can be delayed and attended when the system is not at full capacity. These requests are used to upload the initial data from a client and also to update information concerning users with a wide user pro le.
Requests can also be classi ed as update or retrieval: Retrieval requests just ask the system to return some kind of information, such as a recommendation. Update requests have the objective to update the prole of the source user.
When an update request begins to be processed there are two steps that must be taken to produce recommendations for the user. As we wanted to be able to process several types of recommendations (collaborative ltering, content based, social recommendations), the system had to be general enough to process data in several ways. So we de ned those steps in a way that enabled the use of any possible recommender algorithm (see Fig. 2):
Update user pro le. This can be done by re-calculating simmilarity with other users, re-calculating trust or updating a content-based pro le.
Update user recommendations. This step uses the values obtained from the previous task as input for the recommendation algorithm and produces a new rank of recommendations for the user.
As a rst approach we coded 3 di erent recommender algorithms: Collaborative ltering. A standard method that produces collaborative recommendations when using a collaborative similarity measure, or social recommendations when using trust.
Information retrieval based recommender used for content based recommendations.
Machine learning based recommender also used for content based recommendations.
From the data point of view, the system only stores entities and relationships among entities. Each possible data point (user, group, content or product), is represented by an entity (see Fig. 3). Relationships (see Fig. 4) among entities represent actions (ratings, comments, reviews) or behaviors (buy a product, pageview, joining a group). This data representation allows enough degree of data abstraction for the interoperability, and it also stands near enough to data representation used by the di erent recommender algorithms.
A Representational State Transfer (REST) API [
A client request is described by an HTTP request to a certain resource. For instance, for one of our domains, we may want videogames recommendations for a certain user (user id=2). With our REST API, the client must make an HTTP request to a certain URI5. The rst part of the URI describes the endpoint where our API server is running6. Next part shows that a recommendation (and the recommendation's type) is requested ('/recomm') for a certain entity type ('/player') considering a relation of ownership with another entity type ('/has/videogame'). The user id is '2' and the response format is '.xml'. The server must return an XML le containing the recommendations. In Wipley we have con gured our system to serve di erent types of recommendations for a user, such as products, users and groups. They can be requested just modifying the URI. In order to update the information that the recommender system manages internally, we have designed a XML based speci cation, which allows to update information about any entity (data points, see Fig. 6) or action (relationships among entities, see Fig. 7). 5http://webservices.brainsins.com/api/recomm/player/has/ videogame/2.xml 6http://webservices.brainsins.com/api
We have developed this general purpose multi-algorithm recommender system and we have integrated it into Wipley with great results, given that videogames recommendations are considered by our users as one of the top features. Our future work is de ned in several lines:
Test the performance of the general recommender system in terms of running time and disk usage. Our rst impressions make us think that generalizing the recommender system does not introduces computational overhead, since processing the REST requests represents only a 3-4% of the total running time of a recommendation, but we need to run a larger set of experiments to evaluate the nal performance.
Scalability. As the REST API give us a lot of independence of the clients from the implementation, we are actually re-coding the recommender algorithms through a map-reduce perspective using Apache Mahout7, which will allow the platform to be really scalable.
Experimental platform. One of our main goals is to obtain an experimental platform to test the performance of our recommender systems implementations. We are starting to measure several metrics related to web analytics such as CTR. We expect to obtain real feedback about what recommender algorithms and settings works better for di erent domains. We are also developing a web based backend which will allow us to de ne the experiments and measure several aspects related to the e ectivity of the recommendations. There are no references in the recommender systems literature describing a general purpose recommender system being used to test several recommender algorithms within several domains with the aim to produce an extensive experimental comparison of recommender algorithms. We have developed a general recommender system which encapsulates several recommender algorithms (collaborative ltering, content based recommender, and social recommender) with the main purpose of producing an extensive comparison of recommender algorithms in a real environment. We have also integrated this general recommender system in a real social network that represents an experimental setup with real users in real conditions.
The research described in this paper has been partially supported by the Madrid autonomous region, IV PRICIT, S0505/TIC/0267.