Upload chapter 10 recommender system

Author: mikebo93

chapter_recommender_system/Chapter_Summary.md

@@ -0,0 +1,24 @@
+# Chapter Summary
+
+-   A recommender system is underpinned by a complex architecture that
+    incorporates a multitude of system components such as message
+    queues, feature stores, neural networks, embedding tables, parameter
+    servers, training servers, and inference servers.
+
+-   A recommendation decision typically proceeds through a pipeline that
+    includes both the retrieval and ranking stages. The ranking stage
+    can be further dissected into pre-ranking, ranking, and
+    post-ranking.
+
+-   To ensure high-quality recommendations, a recommendation model
+    requires continual updates. Generally, the more frequent the model
+    updates, the higher the quality of the recommendations.
+
+-   Modern recommender systems are delving into the possibilities of
+    real-time machine learning. To make this concept practically
+    feasible, researchers are exploring how to leverage the unique data
+    characteristics of recommender systems to address several critical
+    system challenges. This exploration has led to new system designs
+    that include application-specific synchronization protocols,
+    application-aware network update scheduling, and online model state
+    management.

chapter_recommender_system/Further_Reading.md

@@ -0,0 +1,14 @@
+# Further Reading
+
+-   Recommendation model: Wide & Deep[^1]
+
+-   Message queue introduction: What Is a Message Queue?[^2]
+
+-   Feature store introduction: What Is the Feature Store in Machine
+    Learning?[^3]
+
+[^1]: <https://arxiv.org/abs/1606.07792>
+
+[^2]: https://aws.amazon.com/message-queue/
+
+[^3]: https://www.featurestore.org/what-is-a-feature-store

chapter_recommender_system/Index.md

@@ -0,0 +1,32 @@
+# Recommender System
+
+Recommender systems serve as intelligent agents, offering suggestions
+for items most relevant to a specific user. To do so, they scrutinize
+data items such as user characteristics, item features, and the
+interactions between the two. Over the past few years, powerhouse
+companies like Google, Facebook, and Alibaba have harnessed deep
+learning technologies to enhance the capabilities of recommender models.
+By deploying deep learning methodologies, these systems are endowed with
+the capability to effectively learn from data through gradient-based
+methods. Moreover, these systems are able to exploit large neural
+networks, including transformers and emerging large language models.
+This, in turn, bolsters the system's proficiency in dissecting complex,
+multi-modal data.
+
+In this chapter, we will delve into the foundational elements of deep
+learning recommender systems (DLRSs). We will elucidate key operational
+processes within these systems, primarily focusing on the multi-stage
+generation of recommendations and the updating of model parameters.
+Lastly, we will delve into a real-world recommender system, shedding
+light on strategic approaches used to tackle practical challenges.
+
+This chapter has the following learning objectives:
+
+1.  Understand the architecture of a recommender system and its
+    essential components.
+
+2.  Understand multi-stage recommendation and model update in a
+    recommender system.
+
+3.  Attain insights into the challenges faced by practical recommender
+    systems and discover their corresponding solutions.

chapter_recommender_system/Model_Update.md

@@ -0,0 +1,121 @@
+# Model Update
+
+In a real-world setting, it is crucial for these systems to routinely
+update their model parameters. However, maintaining seamless user
+experience while concurrently updating ultra-large-scale recommendation
+models becomes a daunting task, especially when catering to a large
+number of online users. This section primarily addresses why continuous
+updates to model parameters are necessary for recommender systems,
+before delving into the offline update methodology and a recommender
+system capable of online updates.
+
+## Necessity for Model Updates
+
+Recommendation models employed in online services encounter highly
+dynamic factors in their datasets:
+
+1.  **New users and items**: Both the users targeted by a recommendation
+    model and the items encompassed within the model are in constant
+    flux. New users and items can emerge at any given time. As depicted
+    in Figure [1](#fig:embedding missing){reference-type="ref"
+    reference="fig:embedding missing"}, the recommender model will be
+    unable to cater to a new user if the embedding table lacks the
+    corresponding embedding item. Similarly, if a newly added item is
+    absent from the model's embedding table, it will not surface in the
+    recommendation pipeline, rendering it impossible to recommend to the
+    intended users.
+
+2.  **Shifting user interests**: Recommendation models must adapt to
+    continually shifting user interests. Should a model fail to swiftly
+    adjust its weights to mirror evolving user interests, the quality of
+    its recommendations may suffer. As an example, in a news
+    recommendation application, trending news topics alter daily. If the
+    model consistently suggests outdated trends, the click-through rate
+    (CTR) of users will progressively decline.
+
+<figure id="fig:embedding missing">
+<p> </p>
+<figcaption>Examples of Missing Embedding Items</figcaption>
+</figure>
+
+While empirical rule formulation (such as directly incorporating new or
+statistically popular items into the recommendation results) can
+potentially address the above dynamic factors, it only provides a
+temporary and partial solution. Such empirical methods cannot entirely
+rectify the problems, mainly due to the substantial performance gap
+between learning-based recommendation models and experience-based
+recommendation rules.
+
+## Offline Process of Model Update
+
+To keep up with the evolving dynamics of datasets, recommender systems
+need to consistently accumulate new training data and harness this
+information to refine their models. This process, known as model
+updating, is integral to improving the efficacy of these systems.
+Typically, the trained model is saved as a checkpoint, which is then put
+through an offline validation process. This updated model is only
+deployed onto the inference servers if it can effectively enhance the
+quality of recommendation. A depiction of this offline model update
+process can be seen in Figure
+[2](#fig:offline update){reference-type="ref"
+reference="fig:offline update"}.
+
+![Offline Process of UpdatingModels](../img/ch_recommender/offline_update.png)
+:label:`offline`
+
+To break it down, when a model completes a training period, the
+subsequent steps unfold:
+
+1.  **Checkpoint step**: The model checkpoint is retrieved from the
+    parameter server in the training data center and stored on the disk.
+
+2.  **Validation step**: This checkpoint undergoes validation against an
+    offline dataset. If it does not pass this validation, the model
+    continues its training.
+
+3.  **Dissemination step**: If the model checkpoint passes the offline
+    validation, it is then disseminated to the parameter servers which
+    host the replicas of this model in different inference data centers.
+
+## Needs for Low-latency Model Updates
+
+Using an offline process of updating models described above can vary in
+duration, ranging from several minutes to hours. Nevertheless, some
+systems have streamlined the procedures for storing and propagating
+checkpoints, which allows updates to occur on a minute-by-minute basis.
+Despite this, the existing minute-level latency in model updates still
+falls short of the requirements for several key scenarios that involve
+recommender systems.
+
+### Incorporating Fresh Content
+
+There are needs in which applications prioritize the delivery of fresh
+content. For example, in the context of short video recommendations, a
+content creator might generate videos relevant to the latest trending
+topics. If these videos are not recommended in a timely manner, the
+topics may become obsolete, resulting in a lower-than-anticipated number
+of views.
+
+### Servicing Anonymous Users
+
+There are often needs where user features are either unavailable or
+scarce. Users are increasingly opting for anonymous usage of
+applications and sharing minimal data due to heightened privacy concerns
+(e.g., Internet browsers prohibit recommender systems from collecting
+user cookies) and stricter data protection regulations (e.g., the
+General Data Protection Regulation -- GDPR -- in Europe). As a result,
+recommender systems are compelled to learn user interests online within
+a very narrow timeframe.
+
+### Adopting Online Machine Learning Techniques
+
+There are needs that call for the application of online machine learning
+techniques. Traditional recommender systems often employ offline
+training where data gathered over a specified timeframe (e.g., one day)
+is used to train a model, which is subsequently deployed online during
+off-peak periods (e.g., early morning). However, recent research and
+practice suggest that increasing the training frequency can notably
+improve the quality of recommendations. The logical endpoint of
+increasing training frequency is online training, where data is
+processed in a streaming fashion and fed to the model. The model then
+continually fine-tunes its parameters based on these online samples.

chapter_recommender_system/Overview.md

@@ -0,0 +1,31 @@
+# Overview
+
+The central component of a recommender system is the recommendation
+model, which generates prospective items of interest for users based on
+given input data. For a large-scale recommender system to function
+seamlessly and deliver high-quality results, it needs additional
+supporting modules built around this central model.
+
+Figure [1](#fig:recommender systems){reference-type="ref"
+reference="fig:recommender systems"} illustrates the essential modules
+of a typical recommender system. A messaging queue accepts logs uploaded
+from the client-side of the recommendation service. These logs capture
+user feedback on previously recommended items, such as a record of
+whether users clicked on the suggested items. A separate data processing
+module handles the raw data from these logs, generating new training
+samples that are subsequently added to another message queue.
+
+Training servers extract these training samples from the message queue
+and use them to update model parameters. A typical recommendation model
+comprises two components: embedding tables and neural networks. During
+the training phase, each training server retrieves the model parameters
+from parameter servers, calculates gradients, and then uploads these
+gradients back to parameter servers. Parameter servers integrate the
+results from each training server and update the parameters accordingly.
+
+Inference servers handle user requests, procure the necessary model
+parameters from parameter servers based on these requests, and calculate
+the recommendation outcomes.
+
+![Architecture of a recommendersystem](../img/ch_recommender/recommender_system.png)
+:label:`recommender`