[attachment=10879]
INTRODUCTION
 Developed by Yahoo!
 Used in many applications like Yahoo shopping, travel e.t.c.
 Records constumer history and reviews
 Hides any customer personal information from any other users.
 Provides wide variety of facilities for users as well as marketers.
 On a single click, that perticular click is recorded on that person’s hostory.
 The products are rated accordingly.
TYPICAL VIBES USE CASE
 Unlike the well-known problem of trying to construct a (user, item) → rating function given a set of numerical user ratings, Vibes is usually deployed in the following cases:
1. Provide an inter-item similarity or relatedness function: (item1, item2) → similarity ∈ [0, 1]. There are a couple of ways to do this.
2. Provide a user-to-item recommendation function (user, item) → recommended ∈ {0, 1}. The output of this function is a boolean which decides whether to suggest item to user or not.
 E.g.: on Yahoo! Shopping.
An Apple iPod (http://shopping.yahoop:Apple%20iPod%20touch%208GB%20MP3%20Player:1994935518). Vibes item-to-item recommendations are shown in the section titled: Yahoo! Shoppers Who viewed this Item also viewed:. All the data we need to supply these recommendations can be obtained from a web log of all the product pages viewed by visitors to Y! Shopping. If enough users visit a common set of items within, say a 90-day time period, those items can be the basis of generating recommendation rules.
Platform requirements
 harder, primarily because of the sparsity of the data.
 It is fairly straight-forward to generate recommendations for users who have a history in Y! Shopping, but it is more challenging to cater to users who land-up directly from another search engine
 The model then has to augmented with other behavioral data from the Yahoo! Network
 Yahoo users details must be kept secure and must not seen by a third agent
Loose coupling :
1) Changes in the recommendation platform, its algorithms and its infrastructure should be transparent to the consumers of the recommendations.
2) This means that Vibes would run on anysystems running possibly different operating systems and language runtimes.
3) A standard way of doing this is by usingWeb Services, in particular using REST principles.
Quality checks :
1) We should anticipate operational issues such as missing or truncated input data, or perhaps changes in data distribution.
2) Models should be evaluated based on metrics such as precision, recall and coverage.
3) Every time a new model is built, it should be compared with a set of historical models and pushed into production only if the deviation is within tolerance limits.
Scalability:
1) The recommendation serving infrastructure hosting the web service should scale horizontally.
2) That means that the total number of requests that can be served per second should be linearly proportional to the number of serving systems.
3) In addition, 99.8% of responses need to be within 20 ms.
4) On the model building front, the platform also needs to exploit data parallelism and should be able to take advantage of multi-CPU machines and grid clusters.
Reporting:
1) A recommender system is only as good as the visibility it provides into the effectiveness of its recommendations.
2) Instrumentation needs to be embedded into the recommendations so that we can track the number of views and clicks made by users.
3) The effectiveness of a recommendation module is measured using the click-through-rate (CTR) on the recommended items.
Extensibility :
1) The Vibes platform should be able to easily accommodate new modeling methodologies and particular requirements for each customer deployment.
2) Themodeling block should be able to incorporate new code (written in any programming language) while the customer interface should have logic to activate business rules to merge, filter, compare and combine the recommendation results as required.
Easy integration:
1) The customer should have to take minimum effort both to provide data that feeds into the modeling engine as well as to consume the recommendation outputs.
2) The data input could happen through standardized channels for instrumenting view and click events that flow into the warehouse.
3) The recommendation output would be served through a web service that will be easy to parse and consume
Quick deployment :
1) The platform needs to minimize the man power and incremental effort required for each new deployment.
2) This could be done by having a standard configuration template that could be tailored to each customer’s requirement by making localized changes for the input data source and output data format.
3) No new code should have to be written in the common case, thereby alleviating the need for a long QA test cycle.
4) The scheduling of model refreshes should happen automatically.
Configurability:
1) It should be possible to easily tailor recommendations for each customer in terms of model parameters, data sources, and APIs.
2) This could be done via a level of meta-programming where each instance of Vibes has a set of configuration parameters in the form of XML files that specify the methods of data generation, model building and the signatures of the RESTful web service.
A tour of new features
Data modelling
The Vibes Affinity Engine
 workhorse of Vibes data modeling
 used to build item-to-item affinity models.
 Items could be almost anything in the Yahoo! universe,
 User interaction with items is discretized into groups.
 A group is a set of events relating items.
 Here, we only count item pair frequency
 At a high level, this involves creating aggregate hash tables in memory mapping item-pairs to current counts and then flushing these tables to disk when memory overflows.
 Finally a second pass is made to merge and sum up all the item pair counts.
 Here,encoding all the item id strings to integers processing and comparing strings is the biggest consumer of cpu time
 This integer encoding method to be the biggest contributor to scalability
The Vibes Attribute Similarity Engine
 Affinity based modeling seems to have only two weaknesses.
1) There is not enough data, i.e. the number of items to number of groups is high. This can happen if a particular web store-front does not have enough visitors or transactions.
2) There are new items that have not accumulated enough history (in views, buys etc.). This is also known as the cold start problem.
 Taking an example, in case of real estate business
 Here, many datas including high volume house or car listing are there.
 These are heving a finite lifetime and it would not be able to find recommendation rules by that time.
 In these cases, we uses structured metadata instead of textual description.
 Here, structured metadata includes attributes like price, area, number of bedrooms e.t.c.