A Web API Functionality Complementary Recommendation Method Based on a Learning Model
Patent Information
- Application Number
- CN202410617641.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-05-17
- Publication Date
- 2026-10-09
- Estimated Expiration
- 2044-05-17
AI Technical Summary
然而,关于功能互补推荐的研究却很少,且在这些有限的研究方法的推荐结果局限于热门的Web API,忽视了长尾Web API和从未被调用过的API
[0044]This invention proposes a Web API complementary feature recommendation method based on a learning model. First, a Web API complementary feature tag dataset is generated based on historical Web API combination relationships. Then, this dataset is input into a BERT model for descriptive document representation processing to obtain Web API feature representation vectors. These vectors are then input into a pre-defined Web API complementary feature recommendation model to predict the complementary probability between candidate APIs and selected APIs. Finally, the predicted complementary probabilities are ranked to obtain a Web API recommendation list. This invention considers the significant long-tail effect and usage sparsity in the Mashup-API ecosystem, treating all candidate Web APIs as first-class citizens to promote fair development of the ecosystem and improve Web API recommendation performance. Finally, a comprehensive case study on a real dataset demonstrates that, compared to other models, this invention exhibits superior performance in recall and mean reciprocal ranking (MRR).
Smart Images

Figure CN118349746B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of Web API recommendation technology, and particularly relates to a Web API functional complementarity recommendation method based on a learning model. Background Technology
[0002] Web APIs (i.e., RESTful Web services) provide a range of functionalities that can be orchestrated to create value-added services, often referred to as Mashups. The widespread availability of online Mashups and Web APIs demonstrates the multiple benefits and economic advantages of Mashup technology. However, amidst the abundance of Web API resources, users face the challenge of selecting the ideal Web API for Mashup creation. Various Web API recommendation methods have been proposed to alleviate the difficulty of service selection; however, research on API feature complementarity recommendation is limited. Given that users often use multiple Web APIs during Mashup development, recommending feature-complementary Web APIs based on user-selected Web APIs becomes crucial. This not only helps users cope with the complexity of Mashup development but also improves development efficiency. Unlike typical Web API recommendation scenarios based on specific service requirements provided by the user, in feature complementarity recommendation scenarios, the user's input requirements may be unknown, and the recommendation is based on one or more Web APIs already selected by the user.
[0003] In recent years, increasing research has focused on Web API recommendation, and several recommendation methods have been proposed. Analysis of existing Web API recommendation work reveals that these methods can be broadly categorized into three types: content-based methods, collaborative filtering-based methods, and graph-based methods. Content-based methods primarily focus on the user's specified current needs. Some studies also consider additional auxiliary information to enhance the semantics of descriptive documents. Despite the potential for more information, simple topic modeling for matching remains insufficient. Collaborative filtering-based methods attempt to make recommendations by considering Web APIs already selected by similar users. Graph-based methods extract service semantics from service networks to improve service matching. These works mainly rely on user demand input or sufficient historical data to find similar users in general Web API recommendation scenarios. However, research on complementary feature recommendations is scarce, and the recommendations from these limited methods are confined to popular Web APIs, neglecting long-tail Web APIs and APIs that are never called. In reality, only a small number of Web APIs are used, while the majority remain idle. For example, the ProgrammableWeb platform has 12,919 Web APIs, but only 1,718 (13.29%) have been called. Of the Web APIs used, a total of 13,523 calls were generated. Of these, 14.6% of the Web APIs (250 in total) accounted for 80% of the calls, while 85.4% of the Web APIs (1468 = 1718 - 250) accounted for the remaining 20%. Figure 1 As shown. Therefore, in order to maintain a fair and sustainable service ecosystem, it is essential to consider all Web APIs (including long-tail and unused APIs) equally in API complementary recommendation scenarios. Summary of the Invention
[0004] The purpose of this invention is to propose a Web API complementary function recommendation method based on a learning model, so as to effectively improve the performance of Web API complementary function recommendation.
[0005] To achieve the above objectives, this invention provides a Web API feature complementarity recommendation method based on a learning model, comprising:
[0006] Generate a dataset of complementary tags for Web API functions based on historical Web API composition relationships;
[0007] Input the Web API function description documents from the dataset into the BERT model, perform description document representation processing, and obtain Web API function representation vectors;
[0008] The Web API function representation vector is input into a preset Web API function complementarity recommendation model to predict the probability of function complementarity between the candidate API and the selected API; wherein, the Web API function complementarity recommendation model adopts the SANFM model;
[0009] The predicted probabilities of functional complementarity are sorted to obtain a recommended list of Web APIs.
[0010] Optionally, a dataset of complementary Web API functionalities generated based on historical Web API composition relationships includes:
[0011] Based on the pre-defined functional complementarity relationship between Web APIs and a set of Web APIs, obtain positive sample label data of complementary Web API functions;
[0012] Based on the pre-defined non-complementary functional relationships between Web APIs and a set of Web APIs, obtain negative sample label data for complementary Web API functions;
[0013] The Web API complementary label dataset is constructed based on the positive sample label data and the negative sample label data of the Web API complementary functions.
[0014] Optionally, the complementary relationship of the functions is as follows:
[0015] Given a Mashup set M = {M1, M2, ..., M} N} and API set A = {A1, A2, ..., A n}, where M i For the i-th Mashup, A i Let A be the i-th API. For any A... i ∈A and non-empty proper subsets If A i ∈(M k -M s If so, then we assume API A i With API set M s They have complementary functions; each Mashup is a collection of several APIs.
[0016] Optionally, the non-complementary functional relationship is as follows:
[0017] Given a Mashup set M = {M1, M2, ..., M} N} and API set A = {A1, A2, ..., A n}, for M k ∈M, any M p ∈M, Mk ≠M p any nonempty proper subset And A i ∈A, if A i ∈{AM k )and If it is true, then A is called A. i and M s They have a non-complementary functional relationship; among them, M p Let p be the p-th Mashup in set M.
[0018] Optionally, before inputting the complementary label dataset of the Web API functionality into the BERT model, the following steps are also included:
[0019] The functional description documents in the Web API complementary tag dataset are preprocessed using natural language preprocessing methods; wherein the preprocessing includes: normalization, stemming, tokenization, and stop word removal.
[0020] Optionally, the Web API function representation vector is input into a preset Web API function complementarity recommendation model to predict the probability of function complementarity between the candidate API and the selected API, including:
[0021] Based on a pre-defined set of trainable latent vectors as a lookup table, the Web API function representation vectors are processed to obtain feature embedding vectors.
[0022] Interactive feature extraction is performed on the feature embedding vector to obtain the extracted feature vector;
[0023] Self-attention calculation is performed on the extracted feature vectors to obtain pairwise interaction vectors that apply the self-attention mechanism;
[0024] The low-order and high-order features in the paired interaction vectors are modeled using a multilayer perceptron;
[0025] The last layer of the multilayer perceptron is transformed into a prediction layer to obtain the prediction probability.
[0026] Optionally, the extracted feature vector is:
[0027]
[0028] in, x is the extracted feature vector. i For the i-th eigenvalue, v i Let be the embedding vector of the i-th feature, ⊙ be the element-wise product of the two vectors, and n be the number of features.
[0029] Optionally, the pairwise interaction vectors for which the self-attention mechanism is applied are:
[0030]
[0031] in, For the pairwise interaction vectors applying the self-attention mechanism, Q, K, and V are the query matrix, key matrix, and value matrix of the self-attention parameters, respectively, and d k K is the matrix dimension. T Let K be the transpose of matrix K.
[0032] Optionally, the method for modeling the low-order and high-order features in the paired interaction vectors using a multilayer perceptron is as follows:
[0033]
[0034] Where L represents the number of layers in the multilayer perceptron; W L b L σ and σ represent the weights, biases, and activation functions of the l-th layer, respectively. L It is the output of the l-th layer.
[0035] Optionally, converting the last layer of the multilayer perceptron into a prediction layer to obtain the prediction probability includes:
[0036] Cross-entropy loss is used to estimate model parameters, and L2 regularization is applied to prevent overfitting.
[0037] The cross-entropy loss is:
[0038]
[0039] Where L(Θ) is the cross-entropy loss, N is the number of training samples, and y (i) For the true value, Here, λ is the predicted value, m is the hyperparameter, and θ is the number of model parameters. j Let j be the j-th training parameter of the model;
[0040] The predicted probability is:
[0041]
[0042] in, To predict the probability, w0 is the bias value. For the linear computation part, w i x represents the weight of the linear part. i Let be the value of the i-th feature, and h(x) be the nonlinear part of the model.
[0043] The present invention has the following beneficial effects:
[0044] This invention proposes a Web API complementary feature recommendation method based on a learning model. First, a Web API complementary feature tag dataset is generated based on historical Web API combination relationships. Then, this dataset is input into a BERT model for descriptive document representation processing to obtain Web API feature representation vectors. These vectors are then input into a pre-defined Web API complementary feature recommendation model to predict the complementary probability between candidate APIs and selected APIs. Finally, the predicted complementary probabilities are ranked to obtain a Web API recommendation list. This invention considers the significant long-tail effect and usage sparsity in the Mashup-API ecosystem, treating all candidate Web APIs as first-class citizens to promote fair development of the ecosystem and improve Web API recommendation performance. Finally, a comprehensive case study on a real dataset demonstrates that, compared to other models, this invention exhibits superior performance in recall and mean reciprocal ranking (MRR). Attached Figure Description
[0045] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:
[0046] Figure 1 This is a schematic diagram of the long-tail head service in an embodiment of the present invention;
[0047] Figure 2 This is a schematic diagram of the overall framework of the complementary Web API recommendation method according to an embodiment of the present invention;
[0048] Figure 3 This is a schematic diagram of the BERT model according to an embodiment of the present invention;
[0049] Figure 4 This is a schematic diagram of the overall framework of the deep learning-based SANFM model according to an embodiment of the present invention;
[0050] Figure 5 This is a schematic diagram comparing the embedding dimension hyperparameters of an embodiment of the present invention.
[0051] Figure 6 This is a schematic diagram comparing the hyperparameters of the self-attention layer dimension in an embodiment of the present invention.
[0052] Figure 7 This is a schematic diagram comparing the hyperparameters of the number of layers in a deep neural network according to an embodiment of the present invention.
[0053] Figure 8 This is a schematic diagram showing the experimental comparison of the learning rate hyperparameter in an embodiment of the present invention;
[0054] Figure 9 This is a schematic diagram of the data tagging algorithm according to an embodiment of the present invention. Detailed Implementation
[0055] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present application will now be described in detail with reference to the accompanying drawings and embodiments.
[0056] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.
[0057] With the advancement of service computing technology, improving the relevance and accuracy of Web API recommendations in Mashup creation has become an important task. However, the Mashup-API ecosystem suffers from long-tail effects and usage sparsity. Therefore, considering long-tail and unused Web APIs in service recommendation methods is crucial. Addressing the shortcomings of existing work on complementary API recommendation, this invention proposes a learning model-based Web API complementary recommendation framework, CoWAR. Specifically, it utilizes a proposed data labeling algorithm to generate a dataset of complementary API labels and employs a BERT model to obtain the representation vectors of the Web APIs. Finally, SANFM is used as the recommendation model to predict the probability of complementary functions between candidate APIs and selected APIs. This framework treats all API candidates as first-class citizens, promoting fairness in service usage.
[0058] This embodiment proposes a Web API feature complementarity recommendation method based on a learning model, such as... Figure 2 As shown, it includes:
[0059] Generate a dataset of complementary tags for Web API functions based on historical Web API composition relationships;
[0060] Input the Web API function description documents from the dataset into the BERT model, perform description document representation processing, and obtain Web API function representation vectors;
[0061] The Web API function representation vector is input into a pre-defined Web API function complementarity recommendation model to predict the probability of function complementarity between candidate APIs and selected APIs; the Web API function complementarity recommendation model adopts the SANFM model.
[0062] The predicted probabilities of functional complementarity are sorted to obtain a recommended list of Web APIs.
[0063] Furthermore, the dataset of complementary Web API functionalities generated based on historical Web API composition relationships includes:
[0064] Based on the pre-defined functional complementarity relationship between Web APIs and a set of Web APIs, obtain positive sample label data of complementary Web API functions;
[0065] Based on the pre-defined non-complementary functional relationships between Web APIs and a set of Web APIs, obtain negative sample label data for complementary Web API functions;
[0066] A Web API complementary label dataset is constructed based on positive sample label data and negative sample label data of complementary Web API functions.
[0067] Furthermore, before inputting the complementary label dataset from the Web API into the BERT model, the following steps are also included:
[0068] Natural language processing methods are used to preprocess the functional description documents in the Web API complementary tag dataset; the preprocessing includes normalization, stemming, tokenization, and stop word removal.
[0069] Furthermore, by inputting the Web API function representation vector into a pre-defined Web API function complementarity recommendation model, the predicted probability of function complementarity between candidate APIs and selected APIs includes:
[0070] Based on a pre-defined set of trainable latent vectors as a lookup table, the Web API function representation vectors are processed to obtain feature embedding vectors.
[0071] Interactive feature extraction is performed on the feature embedding vector to obtain the extracted feature vector;
[0072] Self-attention computation is performed on the extracted feature vectors to obtain pairwise interaction vectors that apply the self-attention mechanism;
[0073] Multilayer perceptrons are used to model low-order and high-order features in paired interaction vectors;
[0074] The last layer of the multilayer perceptron is transformed into a prediction layer to obtain the prediction probability.
[0075] More specifically, the overall framework of the Web API complementary recommendation method proposed in this embodiment is as follows: Figure 2As shown, it includes three parts: (1) Data tagging based on API composition relationship: Based on the proposed data tagging algorithm, a dataset of complementary API functions is generated according to the historical API composition relationship. (2) Web API representation based on BERT model: In the Web API representation component, the preprocessed documents are used as input to the BERT model to obtain the functional representation vector of the Web API. (3) Web API functional complementarity recommendation based on self-attention factorization machine (SANFM): In the SANFM component, SANFM based on deep learning is used as the Web API functional complementarity recommendation model to predict the functional complementarity probability between candidate APIs and selected APIs. Finally, the predicted functional complementarity probability is sorted to generate a Top-K Web API recommendation list for the user. Before the above parts begin, Web service description text, call history between Mashup and Web API and other relevant information are crawled and stored from the ProgrammableWeb website. During the data tagging process, Mashup data containing only 1 API is removed. The following is a detailed description of the data tagging based on API composition relationship, the Web API representation based on BERT model and the Web API functional complementarity recommendation based on self-attention factorization machine in this embodiment.
[0076] Data tagging based on API composition relationships:
[0077] Multiple APIs can be combined into a Mashup to create value-added applications. Let the Mashup set be M = {M1, M2, ..., M}. N The API set is A = {A1, A2, ..., A}. n Each Mashup is a collection of several APIs. For example: M k ={A o A p A q} represents Mashup M k It consists of 3 APIs: A o A p and A q .therefore, And A o A p and A q There is a compositional relationship. Based on the concepts of elements and subsets, this invention defines a functionally complementary relationship between a Web API and a set of Web APIs, as shown in Definition 1.
[0078] Definition 1 (Complementary Functional Relationship): Given a Mashup set M = {M1, M2, ..., M...} N} and API set A = {A1, A2, ..., An}, for any A i ∈A and non-empty proper subsets If A i ∈(M k -M s If so, then we assume API A i With API set M s They have a complementary relationship.
[0079] Positive samples can be obtained according to Definition 1. For M k ={A o A p A q If the user has already selected A o and A p Then A q It should appear in the recommendation list, or rather, {A} o A p} and A q A case with a complementary functional relationship is considered a positive sample, i.e., ({A o A p}, A q , 1), is a triple. Similarly, the other 8 positive samples can be obtained in the same way, as shown in Table 1.
[0080] Table 1 Examples of positive samples with labeled data
[0081]
[0082] The selection of negative samples should be based on positive samples, considering not only local non-complementarity but also global non-complementarity. If either is neglected, the selection of negative samples may be inaccurate, affecting the training and prediction of the recommendation model. Local non-complementarity: If... Then A x With {A o A p}, {A o A q} or {A p A q They do not have a complementary functional relationship, therefore they are non-complementary Webs. Available from the remaining Web APIs (i.e., MM) k Randomly selected from ), globally non-complementarity: Assume the Mashup dataset consists of only 4 Mashups, namely M k ={A o A p A q}, M A ={A o A p Am}, M B ={A p A q A n} and M C ={A o A q A h If in M k In the data tagging process, only local non-complementarity is considered. When the selected API is {A} o A p} and a randomly selected non-complementary Web API as A m When this happens, the API only satisfies local non-complementarity, because M A By {A o A p A m The data should be labeled with {A}. o A p A m} are considered as positive and negative samples. In summary, the selection of negative samples must simultaneously satisfy both local and global non-complementarity. Based on the above analysis, functional non-complementarity is defined as shown in Definition 2.
[0083] Definition 2 (Non-complementary functional relationship): Given a Mashup set M = {M1, M2, ..., M...} N} and API set A = {A1, A2, ..., A n}, for M k ∈M, any M p ∈M, M k ≠M p any nonempty proper subset And A i ∈A, if A i ∈(AM k )and If it is true, then A is called A. i and M s They have a non-complementary functional relationship.
[0084] According to Definition 2, negative samples can be generated. For M k ={A o A p A q Nine negative samples were randomly generated, as shown in Table 2. Based on the above observations, if a Mashup contains n Web APIs, then it is possible to generate associated negative samples. Each positive sample is followed by a corresponding negative sample during model training, and in each iteration, non-complementary Web APIs are randomly selected from the remaining Web APIs. This allows for greater diversity of negative samples, resulting in a more accurate trained model.
[0085] Table 2 Examples of negative samples with labeled data
[0086]
[0087]
[0088] Based on the definitions of complementary and non-complementary functional relationships, positive and negative samples can be generated respectively. Data labeling algorithms include... Figure 9 As shown, its computational complexity is O(|M|). 2 PQ), where P is M i Q is the average number of subsets of , where Q is the average number of elements in these subsets.
[0089] Web API representation based on the BERT model:
[0090] BERT, proposed by Google in 2018, is a pre-trained natural language processing (NLP) model built on top of the Transformer network architecture. Its wide range of applications in NLP include text classification, lexical representation learning, relation extraction, semantic similarity, and question answering systems. Beyond these fundamental applications, BERT plays a crucial role in contextual understanding, capturing complex linguistic nuances and semantic details. Therefore, BERT excels in traditional NLP tasks, providing the model with a deep understanding of the context. The BERT model takes a sentence as input and, by combining three embedding features—tag embedding, segment embedding, and position embedding—meticulously captures the meaning of each word, such as... Figure 3 As shown in the diagram. Tag embeddings create a unique sequence of tags for each word. Segment embeddings reveal the sentence context to which a word belongs, contributing to a comprehensive understanding of the input. Position embeddings encode the precise location of words into a set of vectors, enhancing BERT's understanding capabilities and enabling it to identify sentence order and hierarchical structure.
[0091] The BERT model is a pre-trained language model that uses context-dependent vectors to encode long text sentences, allowing for optimal performance through fine-tuning. During pre-training, BERT utilizes a large amount of unlabeled text for language representation, involving two parallel tasks: Masked Language Modeling (MLM) and Next Sentence Prediction (NSP). Task #1: MLM. Before inputting word sequences into BERT, a unique feature is presented as [MASK] tags, strategically replacing 15% of the words in each sequence. During MLM, the [MASK] tags introduce an element of uncertainty as words are temporarily hidden in the sequence. This task requires the model to utilize contextual cues provided by surrounding, unmodified, unmasked words. Task #2: NSP. In BERT's complex training program, the model's input is presented as sentence pairs, showcasing the complexity of language. Here, the model attempts to improve its ability to predict whether a second sentence seamlessly follows subsequent sentences in the original document. After pre-training, BERT has learned representations of words and sentences, as well as the underlying semantic relationships connecting them. BERT can be further fine-tuned on smaller datasets for specific tasks. The fine-tuning phase improves BERT's adaptability and performance across various scenarios.
[0092] In summary, the essence of BERT is to obtain raw representations through pre-training. The pre-trained model can be adapted to different tasks through fine-tuning with the target dataset. In this invention, the BERT model is used to represent Web API description documents to obtain functional representation vectors of the Web APIs. The representation vectors of the selected Web APIs are aggregated into a single representation vector through pooling operations. Selectable pooling operations include average pooling, max pooling, and min pooling. Subsequently, the aggregated representation vector is concatenated with the representation vectors of candidate complementary Web APIs, serving as input for the downstream API functional complementarity recommendation task.
[0093] Complementary recommendations for Web API functionalities based on self-attention factorization machines:
[0094] like Figure 4 As shown, the recommendation model SANFM used in this embodiment consists of five parts: 1) feature embedding; 2) interactive feature extraction; 3) self-attention calculation; 4) deep neural network; and 5) result prediction.
[0095] I. Feature Embedding
[0096] This embodiment uses a set of trainable hidden vectors. As a lookup table, for the initial feature vector x = {x1, x2, ..., x...} nThe feature embedding vector is obtained by processing the vector. As input to the interaction feature extraction step.
[0097] II. Interaction Feature Extraction
[0098] Considering the interaction relationships between different features, the feature embedding vectors need to be passed to the interaction layer to model the interactive features. The specific calculation formula is as follows, where ⊙ represents the element-wise product of two vectors, v j This represents the embedding vector containing feature j.
[0099]
[0100] III. Self-Attention Calculation
[0101] The purpose of attention mechanisms is to distinguish the importance of different components and aggregate them into a single vector. Self-attention mechanisms avoid the generation of explicit weight coefficients and capture the internal correlations of features. In Web API recommendation scenarios, different feature interactions have different importance to prediction; therefore, this invention employs a self-attention mechanism for weight calculation. The specific formula is as follows, where... Let Q, K, and V represent the pairwise interaction vectors applying the self-attention mechanism, where Q, K, and V are the self-attention parameter matrices, and d k is the matrix dimension.
[0102]
[0103] IV. Deep Neural Networks
[0104] A Multilayer Perceptron (MLP) is a hierarchical artificial neural network used to map a set of input vectors to a set of output vectors. An MLP consists of multiple layers of nodes, each fully connected to the layer below it. Each node, except for the input layer, contains a non-linear activation function. MLPs typically use backpropagation for supervised learning. In Web API recommendation methods, MLPs are often used to model both low-order and high-order features. The specific formula for modeling a Multilayer Perceptron is as follows, where L represents the number of layers in the Multilayer Perceptron; W... l b l σ and σ represent the weights, biases, and activation functions of the l-th layer, respectively. l It is the output of the l-th layer.
[0105]
[0106] V. Result Prediction
[0107] Finally, this embodiment requires converting the last layer of the multilayer perceptron into a prediction layer to obtain the prediction probability. Therefore, o nCombined with the parameter h of the prediction layer neural network, the specific calculation formula is shown in formula (4), and the parts can be expanded and integrated into formula (5). Therefore, the self-attention factor decomposition machine SANFM can be formalized into formula (6), where w0 represents the bias value. This indicates the linear computation part.
[0108] h(x)=h T o n (4)
[0109]
[0110]
[0111] The Web API complementary recommendation problem is treated as a binary classification problem, i.e., complementary and non-complementary. Therefore, a sigmoid function is used in the output layer to predict the probabilities. Obtain complementary label results from the Web API. Therefore, cross-entropy loss can be used to estimate model parameters, and L2 regularization can be applied to prevent overfitting, as shown in Equation (7), where Θ is the set of model parameters, N is the sample size, m=|Θ| is the number of parameters to be trained, and λ is the weight of L2 regularization.
[0112]
[0113] The following section describes the experimental verification of the classification method provided in this embodiment, and provides a detailed description of the dataset, experimental setup, evaluation metrics, comparison methods, and experimental results.
[0114] Dataset and Experiment Setup:
[0115] This embodiment uses a real dataset for experiments, and reliable evaluation results have been obtained. The dataset was crawled from the ProgrammableWeb website in January 2022. Table 3 provides a statistical overview of the selected dataset. The dataset includes 6457 Mashups and 1718 Web APIs. To improve the quality of data processing, a rigorous preprocessing stage was performed. Specifically, Mashups containing only one API were excluded, resulting in a dataset effective for model training, including 2230 Mashups and 881 Web APIs. However, some Mashups contained a large number of APIs, leading to excessively large subsets. To address this issue, Mashups were screened during the data labeling process. Specifically, Mashups containing three or fewer APIs were selected for the experiments, and their subsets had to contain two or more APIs. The data labeling process generated a total of 6615 positive samples. The dataset was divided into training and testing datasets in an 8:2 ratio. A random negative sample was generated relative to the positive samples every two training epochs.
[0116] Table 3 Dataset Characteristics
[0117]
[0118] Evaluation indicators:
[0119] To evaluate model performance, the following metrics are used: R@K and MRR (mean reciprocal rank). R@K evaluates whether the API complementary recommendation model can return the correct answer in the top K recommendation results; a higher R@K value indicates better performance. MRR is the average of the reciprocal ranks of the correct answers; a higher MRR value indicates better performance. R@K and MRR are calculated as shown in formulas (8) and (9), where N + It is the number of positive test samples, Rank i This is the ranking of the actual answer in the recommended list. δ(Rank) i ≤k)∈{0,1}, if the ranking of the true answer is among the top K recommended results, then it is 1, otherwise it is 0.
[0120]
[0121]
[0122] Comparison method:
[0123] This embodiment compares the learning model SANFM with other learning models, including machine learning-based models and some deep learning-based models, to verify the effectiveness of the proposed method:
[0124] 1) LR: Logistic Regression (LR) is a statistical model used for binary classification problems, designed to predict the probability of a binary variable. This model utilizes the properties of linear combinations to transform the values of these combinations into probability values with an sigmoid function. The output value ranges from [0, 1] and can be considered as the probability of belonging to a particular class.
[0125] 2) SVM: SVM (Support Vector Machine) is a powerful supervised learning algorithm used for classification tasks. It classifies data instances into their respective categories by finding the optimal decision boundary (which can be a hyperplane or a surface) in a high-dimensional feature space.
[0126] 3) GBDT: GBDT (Gradient Boosting Decision Tree) is a machine learning technique that optimizes model predictions through successive steps in the learning process. Each iteration of a decision tree involves adjusting the values of coefficients, weights, or biases to predict a target value.
[0127] 4) MLP: MLP (Multilayer Perceptron) is an artificial neural network. It consists of multiple neurons distributed in one or more hidden layers, which are interconnected by weighted connections. Each neuron adds a weighted sum to its input and then applies a non-linear activation function to produce the output.
[0128] 5) BasicFM: BasicFM (Basic Factorization Machine) uses factorization machines to capture complex interactions between features, showing good results when the relationships between variables are non-linear. The key principle of BasicFM is to transform the linear combination of feature values into a probability estimate through the sigmoid function.
[0129] 6) DeepFM: DeepFM (Deep Factorization Machine) combines the advantages of factorization machines with the expressive power of neural networks to capture complex dependencies in high-dimensional data. By integrating shallow and deep components, DeepFM achieves superior performance, which is key to handling complex feature interactions.
[0130] 7) AFM: AFM (Attention Factorization Machine) integrates the attention mechanism into the traditional factorization machine, thereby enhancing the model's ability to focus on key features and assigning different degrees of importance to different feature interactions, making AFM uniquely advantageous in processing sparse and high-dimensional data.
[0131] 8) NAFM: NAFM (Neural Attention Factorization Machine) is a hybrid factorization machine model that integrates deep neural networks to capture complex and nonlinear structures and fuses attention mechanisms to capture the varying importance of feature interactions. NAFM models are used to predict the probability of a Mashup calling a particular service.
[0132] Performance evaluation:
[0133] This invention evaluates the performance of the method experimentally, using R@K and MRR as evaluation metrics for the test dataset. All experimental results are the average of five rounds of experiments to ensure the stability of the results. The default hyperparameter values for SANFM and its control group are shown in Table 4.
[0134] Table 4 Default values for hyperparameters
[0135]
[0136] Performance comparison:
[0137] The experiment set the K value in the R@K metric to {2, 4, 6, 8, 10}. Three aggregation operations were used for comparison of the learning models in the Web API complementary recommendation framework. Table 5 shows the performance comparison of SANFM with other benchmark models under the CoWAR framework, with experimental results arranged in ascending order of MRR. Starting with traditional models, LR, GBDT, and SVM showed similar performance, reflecting their common limitations in capturing complex feature interactions. MLP introduced stronger modeling capabilities, demonstrating superior performance, especially compared to LR and SVM. BasicFM showed competitive results thanks to its ability to model complex relationships through factorization. DeepFM, combining deep learning with factorization machines, surpassed the previous benchmark models. AFM improved upon this by utilizing attention mechanisms, particularly by capturing important feature interactions through attention-based modeling, demonstrating superior performance. By further combining neural networks and attention mechanisms, NAFM showed superior performance compared to many benchmark models. SANFM outperformed other models, demonstrating its superior ability in Web API complementary recommendation. This can be attributed to the integration of deep learning techniques with self-attention mechanisms, and the resolution of the long-tail effect in the Mashup-API ecosystem. Self-attention mechanisms enable SANFM to effectively capture low-order and high-order feature interactions, thereby improving performance. Among the three aggregation operations, average pooling outperforms max pooling and min pooling. Therefore, average pooling is recommended for aggregation operations.
[0138] Table 5 Overall Performance Comparison
[0139]
[0140] Hyperparameter impact analysis:
[0141] This embodiment delves into the impact of four key hyperparameters in the SANFM model: embedding dimension, self-attention dimension, number of deep neural network layers, and learning rate. When studying the impact of one parameter, the remaining parameters are set to their default values in Table 4. This analysis provides a comprehensive understanding of how each hyperparameter affects the overall performance of the SANFM model within the proposed framework.
[0142] 1) The impact of embedding dimension
[0143] The embedding layer plays a crucial role in dimensionality reduction and obtaining effective feature representations. To investigate the impact of embedding dimension, the experiment varied this parameter within the range of {8, 16, 32, 64, 128}. Figure 5 As shown, the impact of the embedding dimension exhibits a clear trend. Both R@10 and MRR increase as the embedding dimension increases from 8 to 32. However, when the embedding dimension increases from 32 to 128, both R@10 and MRR decrease. When the size is set to 32, both R@10 and MRR reach their peak, achieving the optimal balance. Therefore, in the experiments, 32 was established as the default value for the embedding dimension.
[0144] 2) The impact of the self-attention dimension
[0145] Self-attention mechanisms enable models to assign different weights to comprehensively capture feature interactions. By studying the impact of different self-attention dimensions within the range {16, 32, 64, 128, 256}, we can see that... Figure 6 Increasing the self-attention dimension from 16 to 64 leads to an increase in R@10 and MRR. However, further increasing the self-attention dimension from 64 to 256 results in a decrease in both R@10 and MRR. SANFM achieves optimal performance when the self-attention size is 64. Therefore, in the experiments, the default value for the self-attention layer dimension was set to 64; choosing an appropriate dimension size can achieve effective model performance.
[0146] 3) The impact of the number of layers in a deep neural network
[0147] The purpose of increasing the number of layers in a deep neural network is to uncover higher-order interaction features. The number of layers in a deep neural network ranges from 2 to 6. For example... Figure 7 As shown, R@10 and MRR exhibit some fluctuations when the number of deep neural network layers changes from 2 to 4. The model reaches its optimal performance when the number of deep neural network layers reaches 5. Afterward, both R@10 and MRR show a decreasing trend. This observation suggests that a deep neural network with 5 layers produces the best results. The slight fluctuation observed between 2 and 4 layers may be attributed to the model adjusting its internal representation during training, reflecting the learning and adaptation process. Therefore, for this experimental dataset, choosing a deep neural network with 5 layers achieves a good balance between model complexity and generalization ability.
[0148] 4) The impact of learning rate
[0149] The learning rate is a crucial hyperparameter in deep learning models. It controls the step size of parameter updates during training, affecting the model's convergence speed and performance. For example... Figure 8 As shown, both MRR and R@10 increase when the learning rate decreases from 1e-01 to 1e-03. Performance fluctuates slightly from 1e-03 to 1e-05. The model exhibits optimal performance with a learning rate of 1e-03, therefore 1e-03 is used as the default value for the learning rate.
[0150] To promote Mashup development, this embodiment proposes a Web API complementary recommendation framework based on a learning model, fully considering long-tail and unused Web APIs. Using the proposed data tagging algorithm, a complementary API label dataset is generated based on combinatorial relationships for model training. Simultaneously, a BERT model is used to generate functional representation vectors for the Web APIs based on functional description documents. Furthermore, a deep learning-based self-attention factorization machine is employed for training. Using the label dataset and API representation vectors, the final Web API complementary recommendation model can be learned. Comprehensive experiments were conducted on real-world datasets, demonstrating the effectiveness of the proposed Web API complementary recommendation framework, with the SANFM model outperforming benchmark models in both R@K and MRR metrics.
[0151] This embodiment proposes a complementary Web API recommendation framework based on a learning model, named CoWAR. Considering the significant long-tail effect and usage sparsity in the Mashup-API ecosystem, all candidate Web APIs are treated as first-class citizens, promoting fair development within the ecosystem and improving Web API recommendation performance. Finally, comprehensive case studies are conducted on real-world datasets. Experimental results show that, compared to other state-of-the-art models, this embodiment exhibits superior performance in recall and mean reciprocal ranking (MRR) metrics.
[0152] The above are merely preferred embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A Web API complementary recommendation method based on a learning model, characterized in that, include: Generate a dataset of complementary tags for Web API functions based on historical Web API composition relationships; Input the Web API function description documents from the dataset into the BERT model, perform description document representation processing, and obtain Web API function representation vectors; The Web API function representation vector is input into a preset Web API function complementarity recommendation model to predict the probability of function complementarity between the candidate API and the selected API; wherein, the Web API function complementarity recommendation model adopts the SANFM model; The predicted probabilities of functional complementarity are sorted to obtain a Web API recommendation list; A dataset of complementary Web API functionalities generated based on historical Web API composition relationships includes: Based on the pre-defined functional complementarity relationship between Web APIs and a set of Web APIs, obtain positive sample label data of complementary Web API functions; Based on the pre-defined non-complementary functional relationships between Web APIs and a set of Web APIs, obtain negative sample label data for complementary Web API functions; The Web API complementary label dataset is constructed based on the positive sample label data and the negative sample label data of the Web API complementary functions. The complementary relationship of the functions is as follows: Given a Mashup set and API collection ,in For the first A Mashup, For the first One API; for any Web API and nonempty proper subsets ,if So, we assume that the API With API collection They have complementary functions; each Mashup is a collection of several APIs. The non-complementary functional relationship is as follows: Given a Mashup set and API collection ,for , arbitrary , any nonempty proper subset ,as well as ,if and If established, it is called and They have a non-complementary functional relationship; among them, For set The first in A Mashup.
2. The Web API complementary function recommendation method based on a learning model according to claim 1, characterized in that, Before inputting the complementary label dataset from the Web API into the BERT model, the following steps are also included: The functional description documents in the Web API complementary tag dataset are preprocessed using natural language preprocessing methods; wherein the preprocessing includes: normalization, stemming, tokenization, and stop word removal.
3. The Web API complementary function recommendation method based on a learning model according to claim 1, characterized in that, The Web API function representation vector is input into a preset Web API function complementarity recommendation model to predict the probability of function complementarity between candidate APIs and selected APIs, including: Based on a pre-defined set of trainable latent vectors as a lookup table, the Web API function representation vectors are processed to obtain feature embedding vectors. Interactive feature extraction is performed on the feature embedding vector to obtain the extracted feature vector; Self-attention calculation is performed on the extracted feature vectors to obtain pairwise interaction vectors that apply the self-attention mechanism; The low-order and high-order features in the paired interaction vectors are modeled using a multilayer perceptron; The last layer of the multilayer perceptron is transformed into a prediction layer to obtain the prediction probability.
4. The Web API complementary function recommendation method based on a learning model according to claim 3, characterized in that, The extracted feature vector is: in, The extracted feature vector, For the first 1 eigenvalue, For the first Embedding vectors of each feature It is the element-wise product of two vectors. The number of features.
5. The Web API complementary function recommendation method based on a learning model according to claim 3, characterized in that, The pairwise interaction vectors for applying the self-attention mechanism are: in, For pairwise interaction vectors that apply the self-attention mechanism, 、 and These are the query matrix, key matrix, and value matrix for the self-attention parameters, respectively. For matrix dimensions, For matrix The transpose of .
6. The Web API complementary function recommendation method based on a learning model according to claim 3, characterized in that, The method for modeling the low-order and high-order features in the paired interaction vectors using a multilayer perceptron is as follows: in, Indicates the number of layers in a multilayer perceptron; , and They represent the first Layer weights, biases, and activation functions, It is the first The output of the layer.
7. The Web API complementary function recommendation method based on a learning model according to claim 3, characterized in that, The last layer of the multilayer perceptron is transformed into a prediction layer to obtain the prediction probability, including: Cross-entropy loss is used to estimate the parameters of the SANFM model, and then applied. Regularization is used to prevent overfitting; The cross-entropy loss is: in, For cross-entropy loss, The number of training samples, For the true value, For predicted values, For hyperparameters, The number of model parameters, For the model's first One training parameter; The predicted probability is: in, To predict probabilities, This is the bias value. For the linear calculation part, The weights for the linear part, For the first The value of each feature, This represents the nonlinear part of the model.
Citation Information
Patent Citations
Multi-language entity relationship extraction method and system based on adversarial training mechanism
CN110852066A
Function label driven LDA-based cloud API complementary recommendation method
CN117215677A