Multi-Stages Recommender System
Published: 2022-12-21 17:43:18

In the industrial setup for recommender system design, there are usually two stages involved for a recommendation request: retrieval and ranking. Speed is the reason why this multi-stage architecture is widely adopted instead of using one single giant model to rank everything. The system could balance the request latency and recommendation accuracy with this multi-stage structure. In the retrieval stage, a list of items that the user could be interested in are returned quickly from a massive pool of candidates with the help of a very simple model and user/item side features. Usually, simpler models are used in the retrieval stage for speed. Recall/AUC is usually more important in the retrieval stage since we want items that users are interested in could be passed to the next stage as much as possible. However, what is the exact conversion rate each item would have is not that important in the retrieval stage. Accuracy is something we would like the system to address in the next stage. Once the items returned by the retrieval stage are passed to the ranking stage, the model can leverage more complicated features(user-item interaction features or sparse features for example) and more complex machine learning models to do the most accurate personalised recommendation that the system can afford. Thus, the retrieval stage emphasises more on computing speed while the ranking stage focuses more on accuracy.

To be more specific, the recommender system can be decomposed into four different stages: retrieval, rough ranking, fine ranking, and reranking.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zwf9dxh6657eshyalsyc.png)
As discussed above, the retrieval stage is to quickly return a list of items that interest the user from a massive pool. However, sometimes, because this returned list of items from the retrieval stage is still too many to be ranked within a certain amount of time for the fine ranking stage. This is not necessarily true for every case since this is closely related to the latency tolerance and computing power. But a rough ranking stage can be added between the retrieval stage and the fine ranking stage, where a model simpler than the fine ranking stage model can be used along with some user features and item features to do some rough rankings for the result returned from the retrieval stage. We can consider this rough ranking stage as a compromise between speed and accuracy compared to retrieval and fine ranking. As a result, the number of items passed to the fine ranking stage can be further decreased while the recommendation accuracy is kept as well. Most of the time, even though we carefully prepare, for example, the top 500 recommended contents, the user cannot consume all of them, since we don't expect the user to keep scrolling down for new contents for a long time until all 500 contents are consumed. Usually, the user would only check the top 10 results, making the remaining results a waste. 
Then, it is the fine ranking stage, where we can use whatever features we have and the most expensive model we have, aiming for the most accurate personalised ranking result the system can deliver. The result from the fine ranking stage is passed to the reranking stage, which is highly dependent on the business need. Different strategies can be applied based on the requirement, such as deduplication, exploration, and variety.