A service recommendation system and its training method

Abstract

This invention provides a service recommendation system, comprising: a data preprocessing module for obtaining a preset multi-order connectivity feature vector corresponding to a target web service application and a preset multi-order connectivity feature vector corresponding to each application programming interface (API); an encoding module comprising: a web service application autoencoder for encoding the connectivity feature vector of the target web service application at a given order, and an API autoencoder for encoding the connectivity feature vector of each API at a given order; a fusion module for fusing the encoding results of the multi-order web service application autoencoder and the multi-order API autoencoder to obtain a fused feature; and a recommendation module for obtaining a recommended list of APIs for the target web service application based on the fused feature. This invention improves the service recommendation effect.

Description

Technical Field

[0001] This invention relates to the field of service recommendation, specifically to the field of service recommendation based on data augmentation-based high-order graph autoencoders, and more specifically to a service recommendation system and its training method. Background Art

[0002] The rapid development of service computing has led to a surge in web service applications and application programming interfaces (APIs) on the Internet. With the advancement of Web 2.0 technology, a new type of web service application, the mashup, has become increasingly popular. A mashup is a lightweight web service application that integrates multiple APIs. The proliferation of various APIs has provided programmers with a wide range of choices for developing web service applications. However, faced with a vast number of web service applications, most users lack sufficient experience or ability to choose suitable services. Therefore, recommending web service applications that meet users' specific needs has become a pressing issue. To address the challenges brought about by the rapid growth in the number of web service applications, service recommendation systems have emerged. These systems can analyze user interests and preferences from data such as historical user behavior and recommend suitable information and content to users, thereby meeting their personalized needs and providing an important way to solve the problem of information overload. However, because users' historical information about web service applications is very sparse, the similarity calculation is not very accurate. Therefore, improving the accuracy of recommendations remains one of the key technologies that needs to be addressed.

[0003] Based on the type of information used in the recommendation process, service recommendation systems can be broadly categorized into three types: content-based service recommendation, collaborative filtering-based service recommendation, and hybrid service recommendation. Collaborative filtering is the most commonly used method in recommendation systems. This method includes user-based collaborative filtering and item-based collaborative filtering strategies, and is widely used in industry and academia. This type of method mines user interests and needs from historical interaction records. Many existing collaborative filtering models use matrix factorization (MF) to represent the latent features of web service applications or application programming interfaces (APIs) as vectors, and then model web service application-API calls as the inner product of their vectors. Matrix factorization typically requires sufficient interaction data between web service applications and APIs for accurate recommendations. However, in practical applications, the interaction data between web service applications and APIs is often sparse, leading to inaccurate recommendation results. Furthermore, matrix factorization performs poorly for new web service applications or APIs because it is difficult to accurately estimate their preferences or features without sufficient interaction data.

[0004] In recent years, with the popularity of Deep Neural Networks (DNNs), there has been increasing attention on applying deep learning techniques to recommendation tasks. Researchers have introduced DNN components into matrix factorization, achieving superior predictive performance. However, most existing collaborative filtering service recommendation methods using DNNs only consider the direct connections between web service applications and application programming interfaces (APIs) (i.e., first-order connectivity), neglecting their intrinsic relationships (i.e., higher-order connectivity). Treating the call pairs between web service applications and APIs as independent data instances—so-called information silos—ignores the inherent relationships between them, leading to data sparsity. Therefore, during analysis and recommendation, data sparsity can cause problems such as missing data and imbalanced sampling, resulting in poor generalization ability, inadequate training effects, and ultimately, biased recommendations.

[0005] In summary, when there is limited data on web service applications and application programming interface (API) interactions, as well as historical data, existing collaborative filtering-based models using matrix factorization (MF) methods produce inaccurate recommendations. Furthermore, existing collaborative filtering service recommendation methods that incorporate DNN components into matrix factorization only consider the direct connections between web service applications and APIs (i.e., first-order connectivity), neglecting their intrinsic relationships (i.e., higher-order connectivity), thus ignoring the inherent relationships between their calls. This leads to data sparsity. Consequently, during analysis and recommendation, data sparsity can cause data gaps and imbalanced sampling, resulting in poor generalization ability, inadequate training performance, and ultimately, biased recommendations. Therefore, there is an urgent need for a service recommendation system that can recommend more suitable services to users. Summary of the Invention

[0006] Therefore, the purpose of this invention is to overcome the shortcomings of the prior art and provide a service recommendation system and its training method.

[0007] The objective of this invention is achieved through the following technical solution:

[0008] According to a first aspect of the present invention, a service recommendation system is provided for recommending application programming interfaces (APIs) for a target web service application based on historical interaction data between a web service application and its API, the system comprising:

[0009] The data preprocessing module is used to obtain a preset multi-level connectivity feature vector corresponding to the target web service application and a preset multi-level connectivity feature vector corresponding to each application programming interface based on the historical interaction data.

[0010] The autoencoder module includes a preset multi-level web service application autoencoder and a preset multi-level application programming interface autoencoder. Each level of web service application autoencoder is used to autoencode the connectivity feature vector of the corresponding level of the target web service application, and each level of application programming interface autoencoder is used to autoencode the connectivity feature vector of the corresponding level of each application programming interface.

[0011] The fusion module is used to fuse the encoding result of the connectivity feature vector corresponding to the target web service application in the autoencoder module through the multi-level web service application autoencoder and the encoding result of the connectivity feature vector corresponding to each application programming interface through the multi-level application programming interface autoencoder to obtain the fusion feature of the target web service application and each application programming interface.

[0012] The recommendation module is used to obtain the interaction score prediction value between the target web service application and each application programming interface based on the fusion features of the target web service application and each application programming interface, and to obtain the application programming interface recommendation list of the target web service application based on all interaction score prediction values ​​according to a preset standard.

[0013] In some embodiments of the present invention, the historical interaction data is an interaction matrix between multiple web service applications and all application programming interfaces. The interaction matrix includes multiple historical interaction relationship lists, and each historical interaction relationship list indicates the historical interaction relationship between its corresponding web service application and all application programming interfaces.

[0014] The data preprocessing module is configured to: use the historical interaction relationship between the target web service application and all application programming interfaces (APIs) as the first-order connectivity feature vector of the target web service application; preprocess the historical interaction relationship between the target web service application and all APIs in the interaction matrix to obtain a preset multi-order connectivity feature vector of the target web service application; and use the historical interaction relationship between each API and all web service applications as the first-order connectivity feature vector of each API; preprocess the historical interaction relationship between each API and all web service applications in the interaction matrix to obtain a preset multi-order connectivity feature vector corresponding to each API.

[0015] In some embodiments of the present invention, the data preprocessing module is configured to preprocess the historical interaction relationships between the target web service application and all application programming interfaces in the interaction matrix using a cosine similarity function to obtain a preset multi-order connectivity feature vector of the target web service application, and to preprocess the historical interaction relationships between each application programming interface in the interaction matrix and all web service applications using a cosine similarity function to obtain a preset multi-order connectivity feature vector corresponding to each application programming interface.

[0016] In some embodiments of the present invention, the data preprocessing module is configured to, after obtaining the preset multi-order connectivity feature vector of the target web service application and the preset multi-order connectivity feature vector corresponding to each application programming interface, select a preset number of feature vectors corresponding to each order connectivity feature vector of the target web service application and the application programming interface.

[0017] In some embodiments of the present invention, the preset multi-order includes first-order, second-order and fourth-order; wherein, the preset number of second-order connectivity feature vectors is 2, and the preset number of fourth-order connectivity feature vectors is 4.

[0018] In some embodiments of the present invention, the self-encoding module includes:

[0019] One first-order web service application autoencoder, two second-order web service application autoencoders, and four fourth-order web service application autoencoders; and,

[0020] One first-order application programming interface (API) autoencoder, two second-order API autoencoders, and four fourth-order API autoencoders.

[0021] In some embodiments of the present invention, the fusion module is configured to fuse the encoding result of the connectivity feature vector corresponding to the target web service application in the autoencoder module encoded by the multi-order web service application autoencoder and the encoding result of the connectivity feature vector corresponding to each application programming interface encoded by the multi-order application programming interface autoencoder respectively to obtain the fused feature of the target web service application and each application programming interface:

[0022]

[0023] i∈(1,m), j∈(1,n), z≥1

[0024]

[0025]

[0026] Where m is the number of web service applications, n is the number of application programming interfaces (APIs), z is a control parameter for the highest order to be explored by the web service applications and APIs, and Ω is a weighted average function. Θ represents the result of encoding the first-order, second-order, ..., 2z-order connectivity feature vectors corresponding to the i-th web service application through the corresponding web service autoencoder. i Let be the sequence of connectivity feature vector weights corresponding to the i-th web service application. Let be the weight of the 2z-order connectivity feature vector corresponding to the i-th target web service application. Θ represents the result of encoding the first-order, second-order, ..., 2z-order connectivity feature vectors corresponding to the j-th application programming interface (API) using the corresponding API autoencoder. j Let J be the connectivity feature vector weight sequence corresponding to the j-th application programming interface. The weights of the 2z-order connectivity eigenvectors corresponding to the j-th application programming interface.

[0027] In some embodiments of the present invention, the fusion module is configured to obtain the weights of the 2z-order connectivity feature vector of the i-th web service application and the weights of the 2z-order connectivity feature vector of the j-th application programming interface in the following manner:

[0028]

[0029]

[0030] in, The weights of the 2z-order connectivity feature vectors corresponding to the i-th web service application are represented by |N. i | represents the number of first-order connectivity feature vectors corresponding to the i-th web service application. This represents the number of 2z-order connectivity feature vectors corresponding to the i-th web service application. The weight of the 2z-order connectivity eigenvector corresponding to the j-th application programming interface is |N j | represents the number of first-order connectivity eigenvectors corresponding to the j-th application programming interface. This represents the number of 2z-order connectivity eigenvectors corresponding to the j-th application programming interface.

[0031] In some embodiments of the present invention, the recommendation module is configured to obtain the predicted interaction score between the target web service application and all application programming interfaces based on the fusion features of the target web service application and each application programming interface, in the following manner:

[0032]

[0033] in, The fusion feature is obtained by fusing the encoding results of each level of the web service application autoencoder corresponding to the i-th web service application and the encoding results of each level of the application programming interface autoencoder corresponding to the j-th application programming interface in the autoencoder module. MLP For parameter settings in the recommendation module.

[0034] In some embodiments of the present invention, the web service application is mushup.

[0035] According to a second aspect of the present invention, a training method for a service recommendation system of the above embodiments is provided, the method comprising:

[0036] S1. Obtain historical interaction data between the web service application and the application programming interface, and obtain a preset multi-level connectivity feature vector corresponding to the target web service and a preset multi-level connectivity feature vector corresponding to each application programming interface based on the historical interaction data.

[0037] S2. Take each web service application as the target web service application, and use its corresponding preset multi-level connectivity feature vector and the preset multi-level connectivity feature vector corresponding to each application programming interface as training samples, and use the real value of the interaction score between each web service application and all application programming interfaces as the label.

[0038] S3. Train the service recommendation system using the training samples and labels, and update the parameters of the recommendation system by minimizing the interaction prediction score loss between each web service application and all application programming interfaces.

[0039] In some embodiments of the present invention, in step S3, the interactive prediction score loss is:

[0040]

[0041] Where, r ij Let be the true value of the interaction score between the i-th web service application and the j-th application programming interface. This is the predicted interaction score between the i-th web service application and the j-th application programming interface.

[0042] According to a third aspect of the present invention, an electronic device is provided, comprising: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to perform the steps of the method described in the second aspect.

[0043] Compared with the prior art, the advantages of the present invention are:

[0044] This invention, based on the interaction between the target web service application and all application programming interfaces (APIs), preprocesses the first-order connectivity feature vectors corresponding to the target web service application and the APIs to obtain corresponding preset multi-order connectivity feature vectors. Furthermore, it proposes a high-order collaborative filtering recommendation framework based on an autoencoder, feeding the enhanced data into the autoencoder corresponding to the framework. Combining these two approaches, a data-enhanced high-order graph autoencoder-based service recommendation method is realized. This method overcomes the data sparsity problem in traditional recommendation methods, considers the potential information of the web service application and APIs, explores the intrinsic relationships (higher-order connectivity) between calls, and improves the service recommendation effect. Attached Figure Description

[0045] The embodiments of the present invention will be further described below with reference to the accompanying drawings, wherein:

[0046] Figure 1 This is a schematic diagram of the service recommendation system framework according to an embodiment of the present invention;

[0047] Figure 2 A diagram illustrating the MAG graph used to call the mashup-API;

[0048] Figure 3 This is a schematic diagram illustrating a first example of an order according to an embodiment of the present invention;

[0049] Figure 4 A diagram illustrating the first-order connectivity of a mashup-API call;

[0050] Figure 5 A diagram illustrating the higher-order connectivity for mashup-API calls;

[0051] Figure 6 This is a schematic diagram illustrating a second example of the order according to an embodiment of the present invention;

[0052] Figure 7 This is a schematic diagram illustrating high-order sampling in the second example of the order listed in the embodiments of the present invention;

[0053] Figure 8 This is a schematic diagram of a collaborative filtering framework according to a specific embodiment of the present invention;

[0054] Figure 9 This is a schematic diagram of the collaborative filtering framework according to the present invention;

[0055] Figure 10 This is a schematic diagram of the mashup and API autoencoder structure according to an embodiment of the present invention;

[0056] Figure 11 This is a schematic diagram of the mashup and API autoencoder operation flow according to an embodiment of the present invention;

[0057] Figure 12 A diagram illustrating the original dataset used in the mashup-API call;

[0058] Figure 13 A diagram illustrating the rating, blank removal, and negative sampling of the dataset after calling the mashup-API;

[0059] Figure 14 This is a schematic diagram of the experimental process for training the collaborative filtering framework according to the present invention;

[0060] The reference numerals in the detailed embodiments are as follows:

[0061] 100 - Service recommendation system; 110 - Data preprocessing module; 120 - Self-encoding module; 130 - Fusion module; 140 - Recommendation module. Detailed Implementation

[0062] To make the objectives, technical solutions, and advantages of this invention clearer, the invention is further described in detail below through specific embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0063] As described in the background section, when there is limited data on web service applications and application programming interface (API) interaction behavior and historical behavior, existing collaborative filtering-based models using matrix factorization (MF) methods produce inaccurate recommendation results. Furthermore, existing collaborative filtering service recommendation methods that incorporate DNN components into matrix factorization only consider the direct connections between web service applications and APIs (i.e., first-order connectivity), neglecting their intrinsic relationships (i.e., higher-order connectivity), thus ignoring the inherent relationships between their calls. This leads to data sparsity. Consequently, during analysis and recommendation, data sparsity can cause data loss, imbalanced sampling, and other problems, resulting in poor generalization ability, inadequate training performance, and ultimately, biased recommendations. Therefore, there is an urgent need for a service recommendation system that can recommend more suitable services to users.

[0064] To address this, the present invention proposes a novel recommendation system scheme. Specifically, the service recommendation problem to be solved in this invention is defined as: given a mashup-API call graph, how to utilize enhanced data with higher-order connectivity to reveal the intrinsic relationships between data instances and recommend the most suitable API for each mashup.

[0065] To address the aforementioned issues, this invention proposes a data-augmented high-order graph autoencoder-based service recommendation scheme. In this scheme, each web service application-application programming interface (API) pair (i.e., the interaction relationship between a web service application and an API) is augmented with high-order domain data, specifically high-order connectivity feature vectors corresponding to the web service application and the API. This data is input into two sets of autoencoders: one set of web service application autoencoders, used to encode each order of connectivity feature vectors for the web service application; and another set of API sets, used to encode each order of connectivity feature vectors for the API. The encoding results from all web service application autoencoders and the encoding results from all API autoencoders for each API are then fused to obtain the fused features of the target web service application and each API. Service recommendation is then performed based on these fused features.

[0066] To provide a more intuitive understanding of the present invention, a mashup (a novel web service application) is used as an example in the embodiments of the present invention to illustrate the solution in detail. It should be noted that the mashup is merely one example in the embodiments of the present invention; as web service applications develop, the mashup can be replaced with other web service applications, and no specific limitations are made here.

[0067] According to one embodiment of the present invention, such as Figure 1 As shown, this invention proposes a service recommendation system 100 for recommending APIs to a target mashup based on historical interaction data between the mashup and the API. The system 100 includes: a data preprocessing module 110, used to obtain a preset multi-order connectivity feature vector corresponding to the target mashup and a preset multi-order connectivity feature vector corresponding to each API based on the historical interaction data; and an autoencoder module 120, which includes a preset multi-order mashup autoencoder and a preset multi-order API autoencoder, wherein each order of the mashup autoencoder is used to autoencode the connectivity feature vector of the order corresponding to the target mashup, and each order of the API autoencoder is used to autoencode each API... The connectivity feature vectors of corresponding orders are autoencoded; the fusion module 130 is used to fuse the encoding result of the connectivity feature vector corresponding to the target mashup in the autoencoding module 120 encoded by the multi-order mashup autoencoder and the encoding result of the connectivity feature vector corresponding to each API encoded by the multi-order API autoencoder respectively to obtain the fusion feature of the target mashup and each API; the recommendation module 140 is used to obtain the interaction score prediction value of the target mashup and the API based on the fusion feature of the target mashup and each API, and obtain the API recommendation list of the target mashup based on all interaction score prediction values ​​according to a preset standard.

[0068] The functions of each module in the service recommendation system 100 of the present invention are described in detail below.

[0069] I. Data Preprocessing Module

[0070] The data preprocessing module 110 is used to obtain a preset multi-level connectivity feature vector corresponding to the target mashup and a preset multi-level connectivity feature vector corresponding to each API based on the historical interaction data.

[0071] To better understand the function of the data preprocessing module 110 in this embodiment of the invention, the following describes in detail several basic concepts involved in the data preprocessing module 110 in this embodiment of the invention.

[0072] (1) MAG

[0073] Since the original dataset of historical interaction data in this invention is in the form of a MAG graph, MAG is defined as a mashup-API call graph, where G = (U, V, E) is a bipartite graph, where U is the set of mashups, V is the set of APIs, E = U × V, and e ij ∈E is U i (mashup i ) and V j (API j An edge between ) and each edge e ij Each has a weight w ij ≥0, while for U not connected by an edge i and V j w ij =0, i∈(1,m), j∈(1,n). For example, as Figure 2 As shown in the figure, i∈(1,3) and j∈(1,3) are represented as MAG diagrams of U1-U3 and V2-V3.

[0074] (2) Connectivity

[0075] The basic concept of first-order connectivity is: first-order connectivity refers to U i and V j The direct calling relationship between them, in this invention will be w ij Seen as U i and V j The basic concept of second-order connectivity is: second-order connectivity refers to a pair of mashups connected by the same API, or a pair of APIs connected by the same mashup, which represents the similarity of this pair of neighboring structures. For example: let U1 and U2 be... m Connected to the same V j e 1j and e mj These are two connecting edges, s1 being the edge containing U1 and all V in MAG. j The connectivity feature vector corresponding to the interaction relationship (i.e., s1 is the first-order connectivity feature vector of U1), s m It contains U in MAG m With all V j The connectivity feature vector (i.e., s) corresponding to the interaction relationship m For U m (first-order connectivity eigenvectors), when U1 and U m The second-order connectivity is given by vectors s1 and s2. m The cosine similarity definition applies to a pair of APIs. The basic concept of higher-order connectivity (2z, z≥1) is: if U1 can reach U in 2z hops... m , or Um If U1 is a 2z-order neighbor of U1, then U1 and U m It has higher-order connectivity, which is determined by s1 and s m The cosine similarity definition applies to a pair of APIs.

[0076] To better understand the concept of connectivity mentioned above, several examples are given below to illustrate connectivity.

[0077] Example 1: such as Figure 3 As shown in the diagram, U1 calls both V1 and V2, therefore U1 has first-order connectivity with both V1 and V2. Furthermore, since U2 also calls V1, U1 and U2 have second-order connectivity. The potential characteristic of second-order connectivity is that both U1 and U2 call V1, and U2 also calls V3, so U1 may call V3 in the future. Similarly, U1 reaches U5 after four hops, therefore U1 and U5 have fourth-order connectivity. U5 also calls V3, so U1 and U5 may share some similar characteristics. However, because the distance between U1 and U4 is greater than the distance between U1 and U2, these similar characteristics are not as numerous as those between U1 and U2. In this example, U1 may call V3 in the future.

[0078] Example 2: Still refer to Figure 2 Its corresponding first-order connectivity is as follows Figure 4 As shown in the figure, it illustrates the calling relationships between U1-U3 and V1-V3 respectively. From the figure, it can be seen that 1 st This indicates a direct call relationship between the mashup and the API, meaning the mashup and API have first-order connectivity. The corresponding multi-order connectivity is as follows: Figure 5 As shown, from left to right, the diagram illustrates the 1st and 3rd order connectivity between mashups and APIs, the 2nd and 4th order connectivity between mashups, and the 2nd and 4th order connectivity between APIs. The diagram also shows the 2nd and 4th order connectivity between APIs. nd This indicates that there is second-order connectivity between mashups and between APIs, 3 rd This indicates that there is third-order connectivity between the mashup and the API, 4 th This indicates that there is fourth-order connectivity between mashups and between APIs.

[0079] According to one embodiment of the present invention, the historical interaction data is an interaction matrix of multiple mashups and all APIs, the interaction matrix including multiple historical interaction relationship lists, each historical interaction relationship list indicating the historical interaction relationship between its corresponding mashup and all APIs; wherein, the data preprocessing module 110 is configured to: use the historical interaction relationship between the target mashup and all APIs as the first-order connectivity feature vector of the target mashup, preprocess the historical interaction relationship between the target mashup and all APIs in the interaction matrix to obtain a preset multi-order connectivity feature vector of the target mashup, and use the historical interaction relationship between each API and all mashups as the first-order connectivity feature vector of each API, preprocess the historical interaction relationship between each API and all mashups in the interaction matrix to obtain a preset multi-order connectivity feature vector corresponding to each API. According to one embodiment of the present invention, the data preprocessing module 110 is configured to preprocess the historical interaction relationships between the target mashup and all APIs in the interaction matrix using a cosine similarity function to obtain a preset multi-order connectivity feature vector of the target mashup, and to preprocess the historical interaction relationships between each API and all mashups in the interaction matrix using a cosine similarity function to obtain a preset multi-order connectivity feature vector corresponding to each API. According to one embodiment of the present invention, the data preprocessing module 110 is configured to, after obtaining the preset multi-order connectivity feature vector of the target mashup and the preset multi-order connectivity feature vector corresponding to each API, select a preset number of feature vectors corresponding to each order of connectivity feature vector of the target mashup and the API. According to one embodiment of the present invention, the preset multi-order includes first-order, second-order, and fourth-order; wherein the preset number of second-order connectivity feature vectors is 2, and the preset number of fourth-order connectivity feature vectors is 4. It should be noted that the number of connectivity feature vectors of each order in the target mashup corresponds to the number of mashup autoencoders, and the number of connectivity feature vectors of each order in the API corresponds to the number of API autoencoders.

[0080] To more intuitively understand the preset multi-order connectivity feature vectors in the above embodiments, and after obtaining the preset multi-order (highest order is represented by 2z) connectivity feature vectors of the target mashup and the preset multi-order connectivity feature vectors corresponding to each API, a preset number (represented by k) of feature vectors corresponding to each order connectivity feature vector of the target mashup and API are selected.

[0081] This invention explores higher-order connectivity in MAGs to simultaneously consider direct calls and their inherent relationships, which exist within the augmented data. Direct call data only considers positive interactions, while augmented data includes direct calls and potential calls explored from higher-order connections between mashup-API pairs. Therefore, augmented data also includes higher-order relationships between mashup-mashup pairs and API-API pairs. At all higher-order levels, a mashup or API can have zero, one, or more higher-order connections. Starting from the first-order mashup-API interaction matrix, we further observe their higher-order connectivity. This invention does not consider all connections but randomly samples a fixed number of k connections (i.e., randomly selecting a preset number of feature vectors corresponding to each order of connectivity feature vector of the target mashup and API), called k-nearest neighbor sampling. The number of data augmentation instances in this invention is controlled by two parameters, 2z and k, so the total number of instances is calculated as f(2z, k) = 1 + k. 1 +k 2 +...+k z Where 2z represents the highest order to be explored in this invention. For example, as... Figure 6 As shown in the figure, 2z = 4, indicating that the fourth-order connectivity of U1 has been explored. It should be noted that the value of parameter z can be changed; this invention can adjust the value of z to change the depth to which the service recommendation system 100 wants to explore. k represents randomly selecting k similar mashups for the next higher-order connectivity of the target mashup, or randomly selecting k similar APIs for the next higher-order connectivity of each API, such as... Figure 7 As shown, its parameter setting is (4,2), meaning the highest order of exploration is fourth-order connectivity. For U1, since the value of k is set to 2, the cosine similarity function (cosine_similarity()) will sample U6 and U7, which have second-order connectivity with U1, and U8, U9, and U1, which have fourth-order connectivity with U1. 10 U 11 In this example, f(4, 2) = 1 + 2 1 +2 2 The sampling process for APIs follows the same principle. It should be noted that the value of parameter k can be changed. This invention allows adjustment of the value of k to change the number of data instances to be sampled (i.e., the number of multi-order connectivity feature vectors corresponding to the target mashup and the number of multi-order connectivity feature vectors corresponding to each API).

[0082] As described above, this invention employs z and k parameters for data augmentation, where z represents the hyperparameter of the order to be explored, and k represents the number of similar neighbors to sample within a certain order of the target mashup and each API. The augmented data contains much richer information compared to a simple direct call sparse matrix. In other words, it additionally utilizes the relationships between higher-order mashup-API calls and mashup / API pairs, which are considered inherent relationships within MAGs. Therefore, using this augmented data to train a service recommendation system 100 has the potential to improve recommendation performance.

[0083] II. Auto-encoding module

[0084] The autoencoder module 120 includes a preset multi-order mashup autoencoder and a preset multi-order API autoencoder. Each order mashup autoencoder is used to autoencode the connectivity feature vector of the order corresponding to the target mashup, and each order API autoencoder is used to autoencode the connectivity feature vector of the order corresponding to each API.

[0085] According to one embodiment of the present invention, such as Figure 8 The diagram illustrates a collaborative filtering framework according to an embodiment of the present invention (i.e., composed of the autoencoder module 120, fusion module 130, and recommendation module 140 in the service recommendation system 100). As shown in the diagram, the autoencoder module 120 includes: one first-order mashup autoencoder, two second-order mashup autoencoders, and four fourth-order mashup autoencoders; and one first-order API autoencoder, two second-order API autoencoders, and four fourth-order API autoencoders. It should be noted that when the number of connectivity feature vectors corresponding to the mashup and the number of connectivity feature vectors corresponding to the API are different, corresponding mashup autoencoders and API autoencoders can be constructed based on the number of connectivity feature vectors corresponding to the mashup and the number of connectivity feature vectors corresponding to the API. No specific limitations are imposed here.

[0086] The following section details the structure of mashup autoencoders and API autoencoders.

[0087] For a given mashup-API call graph (MAG graph), this invention utilizes data augmentation techniques to capture the direct and higher-order connectivity information of the mashup and API, respectively, and inputs this information into the embeddings of the mashup autoencoder and the API autoencoder. It should be noted that for each type of graph node belonging to the same type of bipartite graph, we use an autoencoder-based embedding method, employing Laplacian feature maps to preserve first-order connectivity, and using an autoencoder to reconstruct the neighborhood vectors of two interacting nodes to capture higher-order connectivity.

[0088] Generally, for each mashup-API call, this invention considers the target mashup's set of autoencoders and its accessible higher-order mashup neighbors to explore higher-order mashup connectivity. All mashup autoencoders share the same set of parameters to reflect that all mashup autoencoders in a set share the same embedding space; therefore, increasing the number of mashup autoencoders does not increase the size of the service recommendation system's 100 parameters. The same setting applies to the API autoencoder set. Two separate sets of autoencoders are used to accommodate the dichotomy of the MAG. Furthermore, to facilitate capturing higher-order connectivity signals in the MAG, the embeddings of the mashup or API are first initialized using neighborhood / call vectors (rows or columns in the MAG). The initial embedding of the mashup contains only the API it calls, while the initial embedding of the API contains only the mashup it calls. i or API j Using the latent vector U i or V j This means they have different dimensions and semantics. They are then augmented using higher-order neighbor instances of the mashup-API call pairs—that is, higher-order neighbor instances of the mashup-mashup pairs and the API-API pairs—and then fed into the corresponding two sets of autoencoders (the mashup autoencoder set and the API autoencoder set). Figure 9As shown, it illustrates the collaborative filtering framework diagram of the present invention (composed of the autoencoder module 120, fusion module 130, and recommendation module 140 in the service recommendation system 100). The diagram shows that for the mashup autoencoder set, it includes a target mashup autoencoder and a set of 2z-order mashup autoencoders (z = 1, 2, ...). This setup also applies to the API. Latent vectors are learned through an autoencoder-based graph embedding method, which maps data to a highly nonlinear latent space to preserve graph structure, thereby capturing the structural information of the graph. The mashup autoencoder and the API autoencoder are both feedforward neural networks, such as... Figure 10 As shown, this illustrates the structure of a mashup autoencoder and an API autoencoder. This structure consists of two parts: an encoder and a decoder, each with multiple non-linear functions. The encoder feeds the input interaction matrix back into the representation space, while the decoder recovers its representation back to the original network structure. Both mashups and APIs have their own autoencoders to satisfy the binary property of MAG. The operational flow of the mashup autoencoder and API autoencoder is described in detail below. Figure 11 As shown, x i It can be represented as U i or V j For the input U i V j The hidden representation of each layer is defined as follows:

[0089] (1) The hidden representation of each layer of the mashup autoencoder is defined as follows:

[0090] Encoder section: ......

[0092]

[0093] Among them, U i Let W1 be the connectivity feature vector of the mashup, W1 be the weights of the first layer of the encoder, and b1 be the biases of the first layer of the encoder. For input data U i The output after the first layer of the encoder, W h Let h be the weights of the encoder layer h. For the output of the encoder at layer h-1, b h u is the bias of the encoder at layer h. i (h) This is the output of the encoder at layer h.

[0094] Decoder section: ......

[0096]

[0097] Among them, W′ h Let b′ be the weight of the h-th layer of the decoder. h The bias of the decoder at layer h is... Let W'1 be the output of the h-th layer of the decoder, W'1 be the weights of the first layer of the decoder, and b'1 be the bias of the first layer of the decoder. For input data U i The output after being encoded by a mashup autoencoder.

[0098] During the encoding process of the mashup autoencoder, the encoding loss after encoding the mashup's connectivity feature vector is minimized to update the parameters in the mashup autoencoder:

[0099]

[0100] (2) The hidden representation of each layer of the API autoencoder is defined as follows:

[0101] Encoder section: v j (1) =σ(Q1V) j +d1) ......

[0103]

[0104] Among them, V j Let Q1 be the connectivity feature vector of the API, Q1 be the weights of the first layer of the encoder, d1 be the bias of the first layer of the encoder, and v be the... j (1) Input data V j The output after the first layer of the encoder, Q h Let h be the weights of the encoder layer h. For the output of the encoder at layer h-1, d h v is the bias of the encoder at layer h. j (h) This is the output of the encoder at layer h.

[0105] Decoder section: ......

[0107]

[0108] Among them, Q′ h Let d′ be the weight of the h-th layer of the decoder. hThe bias of the decoder at layer h is... Let d'1 be the output of the h-th layer of the decoder, Q'1 be the weights of the first layer of the decoder, and d'1 be the bias of the first layer of the decoder. Input data V j The output after being encoded by the API autoencoder.

[0109] During the encoding process of the API autoencoder, the parameters in the API autoencoder are updated by minimizing the encoding loss after encoding the API connectivity feature vector:

[0110]

[0111] III. Integration Module

[0112] The fusion module 130 is used to fuse the encoding result of the connectivity feature vector corresponding to the target mashup in the autoencoder module through the multi-order mashup autoencoder and the encoding result of the connectivity feature vector corresponding to each API through the multi-order API autoencoder to obtain the fusion feature of the target mashup and each API.

[0113] According to one embodiment of the present invention, the fusion module 130 is configured to fuse the encoding result of the connectivity feature vector corresponding to the target mashup in the autoencoder module 120 encoded by the multi-order mashup autoencoder and the encoding result of the connectivity feature vector corresponding to each API encoded by the multi-order API autoencoder respectively to obtain the fusion feature of the target mashup and each API:

[0114]

[0115] i∈(1,m), j∈(1,n), z≥1,

[0116]

[0117]

[0118] Where m is the number of web service applications, n is the number of application programming interfaces (APIs), z is a control parameter for the highest order to be explored by the web service applications and APIs, and Ω is a weighted average function. Θ represents the result of encoding the first-order, second-order, ..., 2z-order connectivity feature vectors corresponding to the i-th web service application through the corresponding web service autoencoder. i Let be the sequence of connectivity feature vector weights corresponding to the i-th web service application. Let be the weight of the 2z-order connectivity feature vector corresponding to the i-th target web service application. Θ represents the result of encoding the first-order, second-order, ..., 2z-order connectivity feature vectors corresponding to the j-th application programming interface (API) using the corresponding API autoencoder. j Let J be the connectivity feature vector weight sequence corresponding to the j-th application programming interface. The weights are the 2z-order connectivity feature vectors corresponding to the j-th application programming interface. According to one embodiment of the present invention, the fusion module 130 is configured to obtain the weights of the 2z-order connectivity feature vectors of the i-th web service application and the j-th application programming interface in the following manner:

[0119]

[0120]

[0121] in, The weights of the 2z-order connectivity feature vectors corresponding to the i-th web service application are represented by |N. i | represents the number of first-order connectivity feature vectors corresponding to the i-th web service application. This represents the number of 2z-order connectivity feature vectors corresponding to the i-th web service application. The weight of the 2z-order connectivity eigenvector corresponding to the j-th application programming interface is |N j | represents the number of first-order connectivity eigenvectors corresponding to the j-th application programming interface. This represents the number of 2z-order connectivity feature vectors corresponding to the j-th application programming interface. For example, when z=2, the weight sequence corresponding to each order connectivity feature vector of the i-th mashup and the weight sequence corresponding to each order connectivity feature vector of the j-th API are:

[0122]

[0123] in, Let be the weights of the first-order connectivity feature vector of the i-th mashup. Let be the weights of the second-order connectivity eigenvectors of the i-th mashup. Let be the weights of the fourth-order connectivity eigenvectors of the i-th mashup. Let the weights be the first-order connectivity eigenvectors of the j-th API. Let J be the weight of the second-order connectivity eigenvector of the j-th API. Let be the weight of the fourth-order connectivity eigenvector of the j-th API.

[0124] It should be noted that multiple mashup autoencoders in the mashup autoencoder set share parameters, as do multiple API autoencoders in the API autoencoder set. Therefore, increasing the number of autoencoders will not increase the size of the service recommendation system parameters.

[0125] IV. Recommendation Module

[0126] The recommendation module 140 is used to obtain the interaction score prediction value between the target mashup and each API based on the fusion features of the target mashup and each API, and to obtain the API recommendation list of the target mashup based on all the interaction score prediction values ​​according to a preset standard.

[0127] According to one embodiment of the present invention, the recommendation module 140 is configured to obtain the predicted interaction score between the target mashup and all APIs based on the fusion features of the target mashup and each API in the following manner:

[0128]

[0129] in, The fused feature is obtained by fusing the encoding results of each order of the mashup autoencoder corresponding to the i-th mashup in the autoencoder module 120 and the encoding results of each order of the API autoencoder corresponding to the j-th API. MLP The parameters in the recommendation module are set. It should be noted that the recommendation module 140 can use a multilayer perceptron (MLP) to obtain the interaction score prediction value, and use the interaction score prediction value to generate the API recommendation list.

[0130] In summary, this invention, based on the interaction relationship between the target mashup and all APIs, preprocesses the first-order connectivity feature vectors corresponding to the target mashup and the APIs to obtain corresponding preset multi-order connectivity feature vectors. Furthermore, it proposes a high-order collaborative filtering recommendation framework based on an autoencoder, feeding the enhanced data into the autoencoder corresponding to the framework. Combining these two approaches, a data-enhanced high-order graph autoencoder-based service recommendation method is realized. This method overcomes the data sparsity problem in traditional recommendation methods, considers the potential information of the mashup and APIs, explores the intrinsic relationship (higher-order connectivity) between calls, and improves the service recommendation effect.

[0131] To improve the recommendation performance of the service recommendation system 100 described above, according to an embodiment of the present invention, a training method for the service recommendation system 100 described above is proposed. The method includes: S1, acquiring historical interaction data between a mashup and an API, and obtaining a preset multi-order connectivity feature vector of the target mashup and a preset multi-order connectivity feature vector corresponding to each API based on the historical interaction data; S2, taking each mashup as the target mashup, using its corresponding preset multi-order connectivity feature vector and the preset multi-order connectivity feature vector corresponding to each API as training samples, and using the true value of the interaction score between each mashup and all APIs as the label; S3, training the service recommendation system using the training samples and labels, and updating the parameters of the recommendation system by minimizing the interaction prediction score loss between each web service application and all application programming interfaces. According to an embodiment of the present invention, in step S3, the interaction prediction score loss is:

[0132]

[0133] Where, r ij Let be the true value of the interaction score between the i-th web service application and the j-th application programming interface. This is the predicted interaction score between the i-th web service application and the j-th application programming interface.

[0134] To verify the effectiveness of the training method for the service recommendation system 100 proposed in the above embodiments, the inventors conducted the following experiments.

[0135] (1) Obtain the original dataset

[0136] like Figure 12 As shown, this invention obtained interaction data corresponding to 5691 mashups and 1170 APIs as the original dataset, and performed processing operations such as rating, whitespace removal, and negative sampling on it to obtain the following results. Figure 13 The dataset shown is processed to obtain a dataset with 21,525 rows × 3 columns. The principle of each processing operation is explained in detail below.

[0137] (a) Rating

[0138] The effectiveness of the system was validated using the ProgrammableWeb dataset. This dataset contains textual descriptions of APIs and mashups, along with their historical call data. Since this dataset does not have a rating system for mashups and APIs, we used their call data as the rating. For example, if U1 calls V5, their call data would be 1 (i.e., as shown below). Figure 12The value of invocation shown is 1), and we use this value as the value corresponding to the call matrix between mashup-API pairs.

[0139] (b) Remove blanks

[0140] After rating the dataset, it is reprocessed to remove blank APIs and Mashups. In this embodiment, blank APIs and Mashups were removed, resulting in 5691 mashups and 1170 APIs. Removing blank APIs and Mashups is a standard preprocessing operation that reduces noise, removes invalid mashups and APIs, and improves the quality of the dataset. Thus, in the recommendation method, only valid APIs and Mashups are considered, improving the quality of the recommendation results.

[0141] (c) Negative sampling

[0142] This invention focuses on implicit feedback, which indirectly reflects preferences through behavioral responses. Compared to explicit feedback (ratings and reviews), implicit feedback can be automatically tracked and is easier to collect. However, using it is more challenging because satisfaction is not observed, and negative feedback is naturally lacking. The original dataset is as follows... Figure 12 As shown in the diagram, an `invocation` value of 1 indicates that a call has occurred between the mashup and the API. A `invocation` value of 0 does not necessarily mean the mashup will not call the API; it could simply mean the mashup is unaware of the API. This presents a challenge for learning from implicit data, as unobserved entries may simply be missing data, thus lacking negative feedback. Therefore, a negative sampling operation is performed: each mashup randomly selects an API it has not called as a negative instance of that mashup, sets its `invocation` value to 0, and selects negative instances at a ratio of 1:1.

[0143] After processing the obtained raw data as described above, it will be as follows: Figure 13 The calls between multiple mashups and APIs shown are transformed into historical interaction data between mashups and APIs, resulting in an interaction matrix between multiple mashups and all APIs, which is then used as a dataset.

[0144] (2) Augment the dataset

[0145] First, the acquired dataset is batch-processed, with 256 data entries processed per batch. This means that data augmentation is performed on 256 mashups (processing (256, 1170)) and 256 APIs (processing (256, 5691)) per batch. First, the representation of each mashup or API is retrieved from the interaction matrix using its ID, i.e., the rows and columns of the interaction matrix. Second, the cosine similarity function is used to find the IDs of similar neighbors of corresponding orders for these mashups or APIs. The experiment uses parameters (4, 2) as an example. For each mashup and API, six similar neighbors need to be found: two second-order and four fourth-order. The representations of these similar neighbors are retrieved from the interaction matrix using their IDs, and then stacked to obtain the neighbor representations for the mashup as (6, 256, 1170) and the API as (6, 256, 5691). Finally, [mashup representation, mashup neighbor representation, API representation, API neighbor representation] is used as a new dataset.

[0146] (3) Training on the new dataset

[0147] The new dataset is divided into a training set and a test set, with proportions of 80% and 20%, respectively. Since the autoencoder module 120, fusion module 130, and recommendation module 140 in the service recommendation system 100 designed in this invention constitute a collaborative filtering framework, the training set is input into the system designed in this invention... Figure 8 The training is performed within the collaborative filtering framework shown. The entire framework is built using TensorFlow. The augmented data is processed by the corresponding autoencoders, with the processing automatically handled by the framework. Loss functions are set within the collaborative filtering framework: mean squared error loss is applied to each autoencoder (7 mashup autoencoders and 7 API autoencoders), and binary cross-entropy loss is applied to the MLP. These loss functions are optimized simultaneously. The training run is set to 100 epochs, with the collaborative filtering framework automatically optimizing each epoch to minimize all three loss functions. Evaluation metrics are also included to assess the effectiveness of the collaborative filtering framework, with binary accuracy used as the evaluation metric. Higher accuracy indicates a better collaborative filtering framework, and more accurate predictions of the interaction scores between the mashup and the API are. In summary, as... Figure 14As shown, this illustrates the general process of training the collaborative filtering framework of this invention: T1, Obtain the data-augmented dataset; T2, Autoencoders corresponding to the mashup and API are used to encode the connectivity feature vectors between the mashup-API pairs, i.e., the connectivity vectors corresponding to the data-augmented dataset are input into the mashup autoencoder and the API autoencoder for autoencoding; T3, Connections are used to fuse the higher-order embeddings of mashup and APIj and perform prediction, i.e., the encoding results after mashup autoencoder encoding and API autoencoder encoding are fused using connection operations to obtain fused features, and the interaction score prediction value is obtained based on the fused features; T4, Model learning optimization, i.e., updating the parameters of the recommendation system to minimize the interaction prediction score loss between each mashup autoencoder and all APIs.

[0148] (4) Experimental Results

[0149] The experimental results are shown in Table 1, which demonstrates the accuracy of the service recommendation system 100 designed in this invention in predicting the interaction relationship between a mashup and an API, compared to the accuracy of existing models in predicting the same relationship (i.e., the accuracy of the model designed in this invention is 0.8319%, while the accuracy of the existing MF model is 0.6395%, the NeuMF model is 0.6467%, the NGCF model is 0.6521%, the VAE-CF model is 0.6829%, the CI-CF model is 0.7012%, and the MISR model is 0.8021%). The experimental data shows that the accuracy of the embodiment of this invention is higher than that of the existing technology. Therefore, the service recommendation system 100 designed in this invention has better generalization ability and better training effect, ultimately leading to more accurate service recommendation results.

[0150] Table 1

[0151] Model Accuracy (%) MF 0.6395 NeuMF 0.6467 NGCF 0.6521 VAE-CF 0.6829 CI-CF 0.7012 MISR 0.8021 This invention 0.8319

[0152] As described above, this invention trains the mashup autoencoder, API autoencoder, and MLP loss function together, comprehensively considering multiple factors to obtain a more comprehensive and accurate collaborative filtering framework. Combining multiple loss functions allows the collaborative filtering framework to achieve a balance among different loss functions, thus avoiding this problem, improving the quality of the collaborative filtering framework, and consequently enhancing the service recommendation effect.

[0153] It should be noted that the sizes of each hidden layer in the encoder of the aforementioned mashup autoencoder and API autoencoder, in descending order, are 32, 16, and 8, while the sizes of each hidden layer in the decoder are 8, 16, and 32. The sizes of each hidden layer in the encoder and decoder described above are merely one embodiment of this invention and are not specifically limited here. The MLP can be a three-layer pyramid structure with dimensions of 64, 32, and 16. With the development of neural networks, the structure of the MLP can be replaced with other structural forms, and no specific limitations are made here.

[0154] It should be noted that although the steps are described in a specific order above, it does not mean that the steps must be executed in the above specific order. In fact, some of these steps can be executed concurrently, or even in a different order, as long as the required function can be achieved.

[0155] The present invention may be a system, a method and / or a computer program product. The computer program product may include a computer-readable storage medium carrying computer-readable program instructions for causing a processor to implement various aspects of the present invention.

[0156] Computer-readable storage media can be tangible devices that hold and store instructions for use by an instruction execution device. Computer-readable storage media can be, for example, including but not limited to, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination thereof.

[0157] The various embodiments of the present invention have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or technical improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A service recommendation system for recommending application programming interfaces (APIs) to a target web service application based on historical interaction data between a web service application and its API, characterized in that, The system includes: The data preprocessing module is used to obtain a preset multi-level connectivity feature vector corresponding to the target web service application and a preset multi-level connectivity feature vector corresponding to each application programming interface based on the historical interaction data. The autoencoder module includes a preset multi-level web service application autoencoder and a preset multi-level application programming interface autoencoder. Each level of web service application autoencoder is used to autoencode the connectivity feature vector of the corresponding level of the target web service application, and each level of application programming interface autoencoder is used to autoencode the connectivity feature vector of the corresponding level of each application programming interface. A fusion module is used to fuse the encoding results of the connectivity feature vector corresponding to the target web service application in the autoencoder module (encoded by the multi-level web service application autoencoder) and the encoding results of the connectivity feature vector corresponding to each application programming interface (API) encoded by the multi-level API autoencoder, respectively, to obtain the fused feature of the target web service application and each API; wherein, the fusion module is configured to fuse the encoding results of the connectivity feature vector corresponding to the target web service application in the autoencoder module (encoded by the multi-level web service application autoencoder) and the encoding results of the connectivity feature vector corresponding to each API (API) encoded by the multi-level API autoencoder, respectively, to obtain the fused feature of the target web service application and each API (API) in the following manner: ， ， ， Where m is the number of web service applications, n is the number of application programming interfaces (APIs), and z is a control parameter for the highest order to be explored by the web service applications and APIs. It is a weighted average function. This represents the first-order, second-order, and third-order web service applications when the target service application is the i-th web service application. The result of encoding the 2z-order connectivity feature vectors by the corresponding web service autoencoder. Let be the sequence of connectivity feature vector weights corresponding to the i-th web service application. Let be the weight of the 2z-order connectivity feature vector corresponding to the i-th target web service application. Represents the first-order, second-order, and third-order of the application programming interface corresponding to the j-th application programming interface. The result of encoding the 2z-order connectivity eigenvectors using the corresponding application programming interface autoencoder. Let J be the connectivity feature vector weight sequence corresponding to the j-th application programming interface. The weights of the 2z-order connectivity feature vector corresponding to the j-th application programming interface; Furthermore, the fusion module is configured to obtain the weights of the 2z-order connectivity feature vector of the i-th web service application and the weights of the 2z-order connectivity feature vector of the j-th application programming interface in the following manner: in, Let represent the weight of the 2z-order connectivity feature vector corresponding to the i-th web service application. This represents the number of first-order connectivity feature vectors corresponding to the i-th web service application. This represents the number of 2z-order connectivity feature vectors corresponding to the i-th web service application. This represents the weight of the 2z-order connectivity eigenvector corresponding to the j-th application programming interface. This represents the number of first-order connectivity eigenvectors corresponding to the j-th application programming interface. This represents the number of 2z-order connectivity eigenvectors corresponding to the j-th application programming interface; The recommendation module is used to obtain the predicted interaction score between the target web service application and each application programming interface (API) based on the fusion features of the target web service application and each API, and to obtain a recommended list of APIs of the target web service application based on all the predicted interaction scores according to a preset standard. The recommendation module is configured to obtain the predicted interaction score between the target web service application and all APIs based on the fusion features of the target web service application and each API in the following manner: ) in, The fusion feature is obtained by fusing the encoding results of each level of the web service application autoencoder corresponding to the i-th web service application in the autoencoder module and the encoding results of each level of the application programming interface autoencoder corresponding to the j-th application programming interface. For parameter settings in the recommendation module.

2. The system according to claim 1, characterized in that, The historical interaction data is an interaction matrix between multiple web service applications and all application programming interfaces. The interaction matrix includes multiple historical interaction relationship lists, and each historical interaction relationship list indicates the historical interaction relationship between its corresponding web service application and all application programming interfaces. The data preprocessing module is configured to: use the historical interaction relationship between the target web service application and all application programming interfaces (APIs) as the first-order connectivity feature vector of the target web service application; preprocess the historical interaction relationship between the target web service application and all APIs in the interaction matrix to obtain a preset multi-order connectivity feature vector of the target web service application; and use the historical interaction relationship between each API and all web service applications as the first-order connectivity feature vector of each API; preprocess the historical interaction relationship between each API and all web service applications in the interaction matrix to obtain a preset multi-order connectivity feature vector corresponding to each API.

3. The system according to claim 2, characterized in that, The data preprocessing module is configured to use a cosine similarity function to preprocess the historical interaction relationships between the target web service application and all application programming interfaces in the interaction matrix to obtain a preset multi-order connectivity feature vector of the target web service application, and to use a cosine similarity function to preprocess the historical interaction relationships between each application programming interface in the interaction matrix and all web service applications to obtain a preset multi-order connectivity feature vector corresponding to each application programming interface.

4. The system according to claim 1, characterized in that, The data preprocessing module is configured to, after obtaining the preset multi-order connectivity feature vector of the target web service application and the preset multi-order connectivity feature vector corresponding to each application programming interface, select a preset number of feature vectors corresponding to each order connectivity feature vector of the target web service application and the application programming interface.

5. The system according to claim 4, characterized in that, The preset multi-order includes first-order, second-order, and fourth-order; wherein, the preset number of second-order connectivity feature vectors is 2, and the preset number of fourth-order connectivity feature vectors is 4.

6. The system according to claim 5, characterized in that, The self-encoding module includes: One first-order web service application autoencoder, two second-order web service application autoencoders, and four fourth-order web service application autoencoders; and, One first-order application programming interface (API) autoencoder, two second-order API autoencoders, and four fourth-order API autoencoders.

7. The system according to claim 1, characterized in that, The web service application is mushup.

8. A training method for the system as described in any one of claims 1-7, characterized in that, The method includes: S1. Obtain historical interaction data between the web service application and the application programming interface, and obtain a preset multi-level connectivity feature vector corresponding to the target web service and a preset multi-level connectivity feature vector corresponding to each application programming interface based on the historical interaction data. S2. Take each web service application as the target web service application, and use its corresponding preset multi-level connectivity feature vector and the preset multi-level connectivity feature vector corresponding to each application programming interface as training samples, and use the real value of the interaction score between each web service application and all application programming interfaces as the label. S3. Train the service recommendation system using the training samples and labels, and update the parameters of the recommendation system by minimizing the interaction prediction score loss between each web service application and all application programming interfaces.

9. The method according to claim 8, characterized in that, In step S3, the interactive prediction score loss is: in, Let be the true value of the interaction score between the i-th web service application and the j-th application programming interface. This is the predicted interaction score between the i-th web service application and the j-th application programming interface.

10. A computer-readable storage medium, characterized in that, It stores a computer program that can be executed by a processor to implement the steps of the method of any one of claims 8-9.

11. An electronic device, characterized in that, include: one or more processors; A storage device for storing one or more programs that, when executed by one or more processors, cause the electronic device to perform the steps of the method as described in any one of claims 8-9.

Images