# A Comprehensive Survey of Recommender Systems Based on Deep Learning
## 3 Overview of the Recommender Systems
### Cross-Domain Recommendation
For instance, a multilayer perceptron (MLP) utilizes the latent features of common users in the source domain as inputs and generates latent rating features for those users in the target domain as outputs during the integration step. Through this process, the network is trained, obtaining a nonlinear mapping function. Optimization is finally achieved via backpropagation, resulting in improved recommendation outcomes. Later, [PERSON], S et al. proposed CD-SemMF [38], which uses the semantic relevance of a project to obtain better results. In the realm of CDR, multiple domains are encountered, each with an information volume denoted as _IN_. Within this framework, Domain A possesses dense data, and a newer Domain B is characterized by data sparsity and suboptimal recommendation performance. The inequality _INA_\(\gg\)_INB_ suggests that the information volume in Domain A significantly surpasses that of Domain B. This discrepancy prompts the consideration of whether information from Domain A can be transferred for utilization in Domain B, a process termed cross-domain transfer. Domain A is designated as the source or auxiliary domain, symbolized as D\({}_{\text{S}}\), whereas Domain B is identified as the target domain, denoted as D\({}_{\text{T}}\). The source domain can comprise multiple distinct domains, which are aimed at supplementing and enriching the information within the target domain D\({}_{\text{T}}\). The respective user sets in domains S and T are \(U_{S}\) and \(U_{T}\), the item sets are \(I_{S}\) and \(I_{T}\), the rating sets are \(RS\) and \(RT\), and the comment sets are \(S\) and \(C_{T}\), respectively. Thus, the objective is to transfer the knowledge embedded in the source domain to enhance the recommendation quality of the target domain. The distinction between cross-domain recommendation and other  
Figure 5: Cross-domain recommendation procedure. methods lies in its feature input, which consolidates multiple domains. Let V represent the user's behavioral features; user embedding for cross-domain recommendation is illustrated in Equation (14). \[u_{i}=[w_{1}\cdot f(u_{i}^{s})+w_{2}\cdot u_{i}^{t},v_{1}^{h},v_{2}^{h},...,v_{n }^{h}] \tag{14}\]  
Cross-domain recommender systems comprise three pivotal modules: a user modelling module, an item modelling module, and a recommendation algorithm module, as illustrated in Figure 6.  
CDR seeks to merge data from various domains by integrating supplementary information from other domains to improve recommendations within the target domain or even across multiple domains. However, it is not a matter of arbitrarily combining any group of domains for cross-domain recommendation purposes; typically, there should be some overlapping information among the different domains. Compared to conventional recommender systems, CDR necessitates meticulously considering which information should be transferred between domains and the methodology used for such transfers. CDR tasks are closely linked to user-related aspects, with two fundamental factors driving this connection: the range of items for recommendations and the diversity of target users, giving rise to a variety of recommendation scenarios. CDR algorithms can be classified according to the target domain into three categories: single-domain CDR, cross-domain CDR, and multi-target CDR.