A functional tag-driven LDA-based cloud API complementary recommendation method
Patent Information
- Application Number
- CN202311231580.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-09-22
- Publication Date
- 2026-09-11
- Estimated Expiration
- 2043-09-22
AI Technical Summary
最后利用训练好的主题模型生成与功能标签互补的云API推荐列表,从云API的功能标签维度出发,解决了当前推荐领域在云API推荐时所面临局限性和挑战,这种方法从云API的功能角度为用户提供了更精准和个性化的云API推荐,有效满足服务化软件开发过程中开发者对功能侧互补云API的客观需要
Smart Images

Figure CN117215677B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of cloud API recommendation technology, and specifically relates to a function tag-driven cloud API complementary recommendation method based on LDA. Background Technology
[0002] With the rapid development of cloud computing and Service-Oriented Architecture (SOA), the flexibility and scalability of software development and deployment have been significantly improved. SOA, with its loosely coupled service organization, provides applications with a highly composable and reusable architectural pattern. Meanwhile, cloud APIs (cloud service interfaces) in cloud computing environments provide developers with convenient access to cloud services, promoting the rapid development and deployment of service-oriented software. However, with the widespread adoption of cloud computing, the number of cloud APIs has exploded, posing challenges for developers. Faced with numerous cloud API choices, developers often experience selection difficulties and information overload. To address this issue, recommending suitable cloud APIs has become an urgent need. An efficient and accurate cloud API recommendation system can help developers quickly find cloud APIs that meet their needs, saving valuable time and effort. Furthermore, appropriate cloud API recommendations can improve application performance and user experience. Currently, there are two main cloud API recommendation methods: Mashup-based recommendation and keyword-based recommendation. Mashup-based recommendation recommends cloud APIs based on known calls within a Mashup. However, the drawback of this method is that the recommendation results may not match the developer's expectations, as the combination of cloud APIs in the Mashup may not fully meet their needs. Another approach is keyword-based recommendation, which matches similar cloud APIs based on user-input keywords or tags. However, keyword-based recommendation methods often only consider the similarity between cloud APIs, failing to comprehensively account for factors such as functionality and complementarity. Sometimes, they can only provide similar or alternative cloud API recommendations. Currently, research and recommendations for complementary cloud APIs are relatively limited. Complementary cloud API recommendations are significant, as they can help developers discover functionally complementary cloud APIs, providing more choices and possibilities. Complementary cloud APIs can complement each other functionally, offering more comprehensive and flexible solutions, while also improving application performance and user experience.
[0003] LDA (Latent Dirichlet Allocation) is a topic modeling technique often used to discover potential topic structures in text data. It views a document as a mixture of multiple topics, each of which is composed of a set of words.
[0004] Therefore, to address the limitations and challenges of existing cloud API recommendation methods, we focus on complementary cloud API recommendation from the perspective of fine-grained feature tags, proposing a feature tag-driven LDA-based complementary cloud API recommendation method. This will provide developers with more choices and possibilities, while also helping to improve application quality and performance. Further research and exploration of complementary cloud API recommendation methods will provide developers with a better development experience and better results in the cloud computing environment. Summary of the Invention
[0005] This invention proposes a function tag-driven, LDA-based method for complementary cloud API recommendations. By employing different construction methods for the document corpus, function tags are treated as documents, and complementary cloud APIs are treated as words within those documents, thus modeling the complementary relationship between cloud APIs and function tags. Finally, a trained topic model is used to generate a recommendation list of cloud APIs complementary to their function tags. Starting from the function tag dimension of cloud APIs, this method addresses the limitations and challenges currently faced in cloud API recommendation. It provides users with more accurate and personalized cloud API recommendations from a functional perspective, effectively meeting the objective needs of developers for complementary cloud APIs in service-oriented software development.
[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:
[0007] A feature-label-driven, LDA-based cloud API complementary recommendation method includes the following steps:
[0008] S1. Data acquisition, including using web crawlers to obtain raw data of the cloud API ecosystem from the cloud API service provider platform, and parsing the cloud API based on the acquired raw data of the cloud API ecosystem, including historical interaction records of Mashup-cloud API and cloud API function tag information.
[0009] S2. Generate a function tag-cloud API mapping matrix F based on the cloud API and its included function tags; generate an API-API co-occurrence matrix C based on the historical interaction records of the Mashup-cloud API;
[0010] S3. Restore the missing values in the API-API co-occurrence matrix C using Nonnegative Matrix Factorization (NMF), and perform negative sampling based on the NMF results to obtain the API-API non-co-occurrence matrix C. * ;
[0011] S4. Combine the function tag-cloud API mapping matrix F and the API-API co-occurrence matrix C to generate a positive corpus set P for function tags; combine the API-API non-co-occurrence matrix C... *The function tag-cloud API mapping matrix F is used to generate a negative corpus set N for function tags;
[0012] S5. Train two LDA models with the same architecture using positive corpus P and negative corpus N respectively to obtain positive model LDA-P and negative model LDA-N. Weight the prediction results of LDA-P and LDA-N to obtain the complementarity between candidate cloud API ca and target function label tf.
[0013] S6. Sort all candidate cloud APIs for the target function tag from high to low according to their complementarity value, and generate a list of cloud APIs with complementary functions.
[0014] A further improvement to this method is that step S2 includes:
[0015] S21. Extract all cloud APIs from the data parsed in step S1 and form them into a set A. Form a set T of different types of function tags contained in all cloud APIs in set A, where t∈T represents a function tag in T.
[0016] S22. Extract the cloud API set F(t) = {a1, a2, ...} containing the function label t, where a i Let F(t) represent the i-th cloud API. We iterate through the function label set T and map the function labels t∈T to obtain the function label-cloud API mapping matrix F.
[0017] S23. Generate an API-API co-occurrence matrix C based on the historical interaction records of the Mashup application and the cloud API.
[0018] A further improvement to this method is that step S4 includes:
[0019] S41. Combining the function tag-cloud API mapping matrix F and the API-API co-occurrence matrix C, generate a set of cloud APIs P(t) that are complementary to the function tag t. Iterate through the function tags t∈T in the function tag set T to calculate the complementary cloud APIs and obtain the positive corpus set P of the function tag set T.
[0020] S42. Combine the function tag-cloud API mapping matrix F and the API-API non-co-occurrence matrix C. * Generate a set of cloud APIs N(t) that are not complementary to the function label t. Iterate through the function labels t∈T in the function label set T to perform non-complementary cloud API calculations, and obtain the negative corpus set N of the function label set T.
[0021] A further improvement to this method is that step S5 includes:
[0022] S51. Input the positive corpus set P and the negative corpus set N into two LDA models with the same architecture for training, and obtain the positive model LDA-P that has a positive impact on complementary prediction and the negative model LDA-N that has a negative impact.
[0023] S52. For the target function label tf, use the positive model LDA-P to perform complementary analysis and prediction on the candidate cloud API ca to obtain the complementarity degree Pred_P(tf,ca) representing the positive impact. At the same time, use the negative model LDA-N to perform complementary analysis and prediction on the candidate cloud API ca to obtain the complementarity degree Pred_N(tf,ca) representing the negative impact.
[0024] S53. Introduce the negative model influence weight w, and use a weighted calculation method Pred(tf,ca)=Pred_P(tf,ca)-Pred_N(tf,ca)*w to obtain the complementarity value of candidate cloud API ca to target function label tf.
[0025] A further improvement to this method is that step S2 includes treating each function tag t∈T in the function tag set T as a document, and treating all co-occurring cloud APIs corresponding to cloud APIs containing function tag t as words in the document, with the number of words obtained by summing the number of co-occurring cloud APIs; the specific implementation is as follows: extract all cloud API sets A from the parsed data, and construct a function tag set T based on the different types of function tags contained in all cloud APIs in A;
[0026] T = {t1, t2, ...}
[0027] Where: t i Let ∈T represent the i-th function label. To generate the function label-cloud API mapping matrix F, first map the function label t∈T in the function label set T to the cloud API set F(t) containing that function label.
[0028] F(t) = {a1, a2, ...}
[0029] Where: a i ∈F(t) represents the i-th cloud API containing the function label t. Next, each function label t∈T in the function label set T is mapped to obtain the function label-cloud API mapping matrix F. Finally, an API-API co-occurrence matrix C is generated based on the historical interaction records of the Mashup application and the cloud API.
[0030] C = {c(i,j)}
[0031] Where: c(i,j) represents cloud API a i and a j Co-occurrence count across all Mashup applications.
[0032] A further improvement to this method is that step S3 includes using nonnegative matrix factorization (NMF) to decompose the API-API co-occurrence matrix C into a feature matrix Q and an association matrix H, where the feature matrix Q represents the importance or weight of each cloud API in different features, and the association matrix H represents the correlation or co-occurrence relationship between cloud APIs; by iteratively updating Q and H, Q*H≈API-API co-occurrence matrix C is made, where the size of Q is |A|×D, the size of H is D×|A|, |A| is the size of the cloud API set, and D is the matrix factorization dimension; the co-occurrence probability of the Q*H cloud API pairs is then used for reconstruction and prediction.
[0033] During the negative sampling process, the co-occurrence probability of cloud API pairs in the API-API co-occurrence matrix C is first predicted by reconstructing the model. Cloud APIs with lower co-occurrence probabilities will be sampled as negative samples with a higher probability. The API-API co-occurrence matrix C is then predicted using the trained feature matrix W and correlation matrix H. Finally, the cloud API a is calculated using the softmax function. i The prior probabilities of being plotted as negative sample cloud APIs are shown below:
[0034]
[0035] Where: c a [i] represents the restored prediction value of cloud API a for the i-th cloud API. The softmax function converts each restored prediction value into a probability value in the range [0,1].
[0036] The number of negative sample cloud APIs is determined by multiplying the number of co-occurring cloud APIs of cloud API a∈A by the sampling ratio τ. Then, negative sampling is performed by combining the prior probabilities of cloud API a and its candidate negative sample cloud APIs to obtain the set of non-co-occurring cloud APIs NA(a) corresponding to cloud API a.
[0037] NA(a)={a1,a2,a3,…,where Pr(a1|a)≤Pr(a2|a)≤Pr(a3|a)…}
[0038] Iterate through each cloud API a in set A i Given ∈A, obtain its set of non-co-occurring cloud APIs, and further construct an API-API non-co-occurrence matrix C based on all non-co-occurring cloud API sets. * .
[0039] A further improvement to this method is that, in step S4, constructing the positive corpus set P includes combining the function tag-cloud API mapping matrix F and the API-API co-occurrence matrix C to generate a complementary cloud API set P(t) for function tag t:
[0040] P(t) = {a1, a2, ...}
[0041] Where: a i ∈P(t) represents the i-th cloud API complementary to the function label t. The complementary cloud API is calculated by traversing the function label set T and performing the function label t∈T, resulting in a positive corpus P of function label set T = {t1, t2, ...}.
[0042] P = {P(t1), P(t2), ...}
[0043] The construction of the negative corpus N in step S4 includes combining the function tag-cloud API mapping matrix F and the API-API non-co-occurrence matrix C. * Generate a set of non-complementary negative sample cloud APIs N(t) with functional label t;
[0044] N(t) = {a1, a2, ...}
[0045] Where: a i ∈N(t) represents the i-th negative cloud API that is not complementary to the function label t. We traverse the function label set T and perform non-complementary cloud API calculations on the function labels t∈T to obtain the negative corpus set N of function label set T = {t1, t2, ...}.
[0046] N = {N(t1), N(t2), ...}
[0047] A further improvement to this method is that the LDA model includes the processes of generating topic distributions and generating cloud APIs. Through this generation process, functional tag documents conforming to the LDA model are obtained, where each functional tag document consists of a topic distribution and a cloud API distribution. Given a set of cloud API functional tags T and a topic queue Z, the generation process of the LDA model is as follows:
[0048] 1. For a function label t∈T, draw a topic distribution θ from the Dirichlet distribution α. t ;
[0049] 2. For each topic z∈Z, extract the topic word cloud API distribution from the Dirichlet distribution β.
[0050] 3. For a function label t∈T and its complementary cloud API set P(t):
[0051] (a) From the topic distribution θ t Choose a topic z ta ~Categorical(θ) t );
[0052] (b) Select a cloud
[0053] A further improvement to this method is that in step S5, the process of performing complementary analysis and prediction using the trained LDA-P positive model and LDA-N negative model involves generating a complementary cloud API recommendation list based on a function label t, provided that the Mashup application developer selects a function label t. This list incentivizes developers to make meaningful combinations. The complementarity between the candidate cloud API ca∈A and the target function label tf is set to Pred_P(tf,ca). The complementary analysis and prediction process based on LDA-P is shown below:
[0054]
[0055] Where tf represents the target function tag, ca represents the cloud API under topic z corresponding to the target function tag tf, Z represents the topic under the function tag, and θ tf,z This represents the topic probability corresponding to the target function label tf under known conditions. This represents the probability of a cloud API for topic z under known conditions;
[0056] Similarly, by using the negative model LDA-N to predict the target function label tf and the candidate cloud API ca∈A, we obtain the negative complementarity value Pred_N(tf,ca). Further, we introduce the negative model influence weight w and calculate the complementary degree Pred(tf,ca) of the candidate cloud API ca∈A to the target function label tf by weighted calculation of the positive and negative model predictions.
[0057] Pred(tf,ca)=Pred_P(tf,ca)-Pred_N(tf,ca)*w.
[0058] A further improvement to this method is that the complementarity prediction values Pred(tf,ca) are sorted from largest to smallest, and candidate cloud APIs with high complementarity are preferentially recommended to developers; the list of cloud APIs recommended based on the target function tag tf can be described as follows:
[0059] Top-N(tf)={ca1,ca2,ca3,…|Pred(tf,ca1)≥Pred(tf,ca2)≥Pred(tf,ca3)…}
[0060] Where: {ca1,ca2,ca3} represents the recommended list of cloud APIs, and Pred(tf,ca1) represents the predicted complementarity between cloud API ca1 and target function label tf.
[0061] Compared with the prior art, the method of the present invention has the following advantages:
[0062] 1. This invention is a function tag-driven, LDA-based cloud API complementary recommendation method. Compared with most methods, this invention focuses more on service recommendation from the functional dimension of cloud APIs. By making full use of the complementary feature information between function tags and cloud APIs, it recommends functionally complementary cloud APIs based on fine-grained function tag dimensions.
[0063] 2. This invention proposes a complementary modeling scheme for cloud API function tags. This scheme differs from traditional schemes and models the complementary relationship between function tags and cloud APIs from a new perspective. It constructs positive and negative corpus sets and trains an LDA model.
[0064] 3. This invention proposes a scheme for weighted prediction using positive and negative dual models. This scheme performs dual prediction for the functional tags of cloud APIs, calculates the complementarity value of the positive and negative model predictions by weighting, and generates a list of complementary cloud APIs based on the complementarity value from high to low. This effectively meets the objective needs of developers for complementary cloud APIs on the functional side during the development of service-oriented software. Attached image description:
[0065] Figure 1 This is a flowchart illustrating the implementation of the method of the present invention;
[0066] Figure 2 This is a schematic diagram of the overall structure of the model of the method of the present invention;
[0067] Figure 3 This is a diagram of the LDA model driven by the function tag of the present invention. Detailed implementation method:
[0068] The present invention will be further described below with reference to the accompanying drawings:
[0069] Figure 1 This is a flowchart illustrating the implementation of the method of the present invention. The complementary recommendation method based on LDA for cloud API function tags includes the following:
[0070] Content 1: This invention uses real datasets from cloud API service providers to process and then apply them to model training and testing. First, cloud APIs are extracted and parsed from the cloud API service provider platform, including historical interaction data between Mashup and cloud APIs, as well as data such as cloud API function tags. After a series of operations, the parsed data is processed, and modeling is performed using the complementarity between cloud API function tags and services. Finally, positive and negative corpus sets are constructed for training LDA topic models.
[0071] Content 1-1: Extract the different types of function tags contained in all cloud APIs from the parsed data, forming a function tag set T, where t represents a specific instance of a function tag. For each cloud API function tag t, extract the cloud APIs containing function tag t, and let F(t) represent the set of cloud APIs mapped to tag t. The specific implementation steps are as follows:
[0072] First, extract the functional label set T:
[0073] T = {t1, t2, ...}
[0074] Where: t i t represents the i-th function label. i ∈T. Then map the cloud API set containing the API function label t:
[0075] F(t) = {a1, a2, ...}
[0076] Where: a i This represents the i-th cloud API that contains the function label t.
[0077] Content 1-2: Based on the historical interaction records of the Mashup-Cloud API, generate the API-API co-occurrence matrix C. The element c(i,j) in the API-API co-occurrence matrix C represents Cloud API a. i and a j The number of co-occurrences in the historical interaction record. The specific implementation is as follows:
[0078] 1. First, collect historical interaction records of the Mashup-Cloud API. These records include information such as which Cloud APIs the Mashup application called and the number of times they were called.
[0079] 2. Create a co-occurrence matrix C of size |A|×|A|, where |A| represents the number of cloud APIs. Initially, all elements are set to 0.
[0080] 3. For each Mashup application, iterate through the list of cloud APIs it calls.
[0081] 4. For each pair of cloud APIs (i,j), if cloud API a i and a j If two elements co-occur once in the historical interaction record, then increment the corresponding element c(i,j) in the co-occurrence matrix C by 1.
[0082] 5. Repeat steps 3 and 4 to process the call records of all Mashup applications and update the elements in the co-occurrence matrix C. After the above steps, the API-API co-occurrence matrix C is obtained.
[0083] Contents 1-3: Combining the function tag-cloud API mapping matrix F and the API-API co-occurrence matrix C, generate a set of complementary cloud APIs P(t) for function tag t. Iterate through each function tag t in the function tag set T to calculate the complementary cloud APIs, thus obtaining the positive corpus set P of the function tag set T.
[0084] 1. For each function label t, identify the cloud API associated with function label t. This can be achieved through the following steps:
[0085] 1.1 Obtain the index of all cloud APIs in the function tag t in the function tag-cloud API mapping matrix F, for example, one of the indexes is index_t.
[0086] 1.2 Traverse the index_t row or index_t column of the API-API co-occurrence matrix C to find the column indices corresponding to all non-zero elements. These column indices represent the cloud APIs associated with the function label t.
[0087] 1.3 The found cloud API indices are grouped into a set P(t), which represents the set of cloud APIs that are complementary to the function label t.
[0088] 2. For each function tag t, further deduplication, sorting or other processing is performed according to the function tag-cloud API mapping matrix F to filter out cloud APIs that are complementary to function tag t, forming a set of complementary cloud APIs P(t) for function tag t.
[0089] 3. For each function label t in set T, repeat steps 1 and 2 to obtain a set P of cloud APIs that are complementary to all function labels.
[0090] The final result is a positive corpus P consisting of a set of functional labels T, where each element represents a set of cloud APIs with complementary functional labels. This positive corpus P can be used for subsequent analysis, recommendation, or other applications, such as building a cloud API recommendation system or providing more refined and personalized cloud APIs.
[0091] Contents 1-4 involve processing the API-API co-occurrence matrix C from step S2. The API-API co-occurrence matrix C is completed using Non-negative Matrix Factorization (NMF). Negative sampling is then performed using a negative sampling ratio τ to obtain the API-API non-co-occurrence matrix C. *
[0092] For the API-API co-occurrence matrix C, a negative sampling ratio τ is set. The negative sampling ratio τ represents the number of negative samples to be generated for each cloud API, i.e., how many negative samples with a co-occurrence count of 1 are to be generated. The API-API co-occurrence matrix C is decomposed into a feature matrix Q and an association matrix H using non-negative matrix factorization. The feature matrix Q represents the importance or weight of each cloud API in different features, while the association matrix H represents the correlation or co-occurrence relationship between cloud APIs, such that Q*H≈C, where the size of Q is |A|×D and the size of H is D×|A|, where |A| is the size of the cloud API set and D is the matrix factorization dimension. Prediction is performed using Q*H, and the softmax function is used to calculate the sampling of non-co-occurring cloud APIs. After obtaining the negative samples, the API-API non-co-occurrence matrix C is generated using the same method. * .
[0093] Contents 1-5 utilize the function tag-cloud API mapping matrix F from step S2, combined with the API-API non-co-occurrence matrix C. * Generate a negative sample cloud API set N(t) for non-complementary functional labels t. Iterate through the functional labels t in the functional label set T and perform non-complementary calculations to obtain the negative corpus set N of functional label set T.
[0094] 1. For each function tag t in the function tag set T, obtain its index set in the function tag-cloud API mapping matrix F.
[0095] 2. From the API-API non-co-occurrence matrix C * The non-co-occurrence information of cloud APIs related to function tag t is obtained. Specifically, this is done by finding the index number of function tag t in the index set of the function tag-cloud API mapping matrix F, and then... * The corresponding row or column.
[0096] 3. Based on the degree of non-co-occurrence information, filter out negative sample cloud APIs that are not functionally complementary.
[0097] 4. The selected non-functionally complementary negative sample cloud API sets are combined into a set N(t).
[0098] 5. Further process the set N(t), such as deduplication, sorting, or other processing as needed.
[0099] 6. Merge the non-complementary negative sample cloud API sets N(t) of all functional labels t in the functional label set T to obtain the final negative corpus set N.
[0100] Content 2: Constructing positive and negative dual models based on LDA and performing weighted prediction of complementarity values, ranking them by TOP-N, and generating a complementary cloud API recommendation list. The content proposed in this invention is as follows: Figure 2 The overall structure of the model is shown in the schematic diagram.
[0101] Content 2-1 involves feeding the obtained positive and negative corpus sets P and N into two LDA models with identical architectures for training, resulting in the LDA-P positive model and the LDA-N negative model. Prediction is then performed using the trained LDA-P positive model and LDA-N negative model. If a Mashup application developer selects a feature label t, a complementary cloud API recommendation list is generated based on that feature label t to incentivize the developer to make meaningful combinations. Let the complementarity between candidate cloud API ca∈A and the target feature label tf be Pred_P(tf,ca). The complementarity analysis and prediction process based on LDA-P is shown below:
[0102]
[0103] Where tf represents the target function tag, ca represents the cloud API under topic z corresponding to the target function tag tf, Z represents the topic under the function tag, and θ tf,z This represents the topic probability corresponding to the target function label tf under known conditions. This represents the probability of a cloud API for topic z under known conditions;
[0104] As shown above, the positive model LDA-P yields the predicted value Pred_P(tf,ca) representing the positive complementarity between the target function label tf and the candidate cloud API ca. Similarly, the negative model LDA-N predicts the negative complementarity between the target function label tf and the candidate cloud API ca using the following formula:
[0105] Pred(tf,ca)=Pred_P(tf,ca)-Pred_N(tf,ca)*w
[0106] The positive and negative model predictions are weighted and calculated to obtain the complementarity value between the candidate cloud API ca and the target function label tf.
[0107] Content 2-2 states that the complementarity prediction values Pred(tf,ca) are sorted from largest to smallest, and candidate cloud APIs with high complementarity are preferentially recommended to developers; the list of cloud APIs recommended based on the target function tag tf can be described as follows:
[0108] Top-N(tf)={ca1,ca2,ca3,…|Pred(tf,ca1)≥Pred(tf,ca2)≥Pred(tf,ca3)…}
[0109] Where {ca1,ca2,ca3} represents the recommended list of cloud APIs, and Pred(tf,ca1) represents the predicted complementarity between cloud API ca1 and the target function label tf. The above formula represents the process of sorting candidate cloud APIs from largest to smallest based on their complementarity values, given the target function label tf.
[0110] Content 3: Traditional LDA topic modeling is a probabilistic generative model used for text analysis and topic modeling. It assumes that a document consists of multiple topics, and each topic is composed of a set of words. (Combined with the appendix...) Figure 3 This invention explains the generation process of the LDA model from a completely new perspective, including the generation of topic distributions and cloud APIs. Through this generation process, functional tag documents conforming to the LDA model are obtained, where each functional tag document consists of a topic distribution and a cloud API distribution. Given a set of cloud API functional tags T and a topic queue Z, the generation process of the LDA model is as follows:
[0111] 1. For a function label t∈T, draw a topic distribution θ from the Dirichlet distribution α. t ;
[0112] 2. For each topic z∈Z, extract the topic word cloud API distribution from the Dirichlet distribution β.
[0113] 3. For a function label t∈T and its complementary cloud API set P(t):
[0114] (a) From the topic distribution θ t Choose a topic z ta ~Categorical(θ) t );
[0115] (b) Select a cloud
[0116] Where: Dirichlet's probability density function is:
[0117]
[0118]
[0119] The graphical model of the smoothed LDA model in Figure 3 The rectangles are labeled as representing duplicates. The left rectangle represents the potential topic, the outer right rectangle represents the cloud API feature tag, and the inner right rectangle represents the repeated selection of the topic queue and cloud API in the complementary interaction relationship of the cloud API feature tag.
Claims
1. A function tag-driven, LDA-based cloud API complementary recommendation method, characterized in that, Includes the following steps: S1. Data acquisition, including using web crawlers to obtain raw data of the cloud API ecosystem from the cloud API service provider platform, and parsing the cloud API based on the acquired raw data of the cloud API ecosystem, including historical interaction records of Mashup-cloud API and cloud API function tag information. S2. Generate a function tag-cloud API mapping matrix F based on the cloud API and its included function tags; generate an API-API co-occurrence matrix C based on the historical interaction records of the Mashup-cloud API; S3. Restore the missing values in the API-API co-occurrence matrix C using Nonnegative Matrix Factorization (NMF), and perform negative sampling based on the NMF results to obtain the API-API non-co-occurrence matrix C. * ; S4. Combine the function tag-cloud API mapping matrix F and the API-API co-occurrence matrix C to generate a positive corpus set P of function tags; Combining the API-API non-co-occurrence matrix C * The function tag-cloud API mapping matrix F is used to generate a negative corpus set N for function tags; S5. Train two LDA models with the same architecture using positive corpus P and negative corpus N respectively to obtain positive model LDA-P and negative model LDA-N. Weight the prediction results of LDA-P and LDA-N to obtain the complementarity between candidate cloud API ca and target function label tf. S6. Sort all candidate cloud APIs for the target function tag tf from high to low according to their complementarity value, and generate a list of complementary cloud APIs.
2. The function tag-driven LDA-based cloud API complementary recommendation method according to claim 1, characterized in that, Step S2 includes: S21. Extract all cloud APIs from the data parsed in step S1 and form them into a set A. Form a set T of different types of function tags contained in all cloud APIs in set A, where t∈T represents a function tag in T. S22. Extract the cloud API set F(t) = {a1, a2, ...} containing the function label t, where a i Let F(t) represent the i-th cloud API. We traverse the function label set T and map the function labels t∈T to obtain the function label-cloud API mapping matrix F. S23. Generate an API-API co-occurrence matrix C based on the historical interaction records of the Mashup application and the cloud API.
3. The function tag-driven LDA-based cloud API complementary recommendation method according to claim 2, characterized in that, Step S4 includes: S41. Combining the function tag-cloud API mapping matrix F and the API-API co-occurrence matrix C, generate a set of cloud APIs P(t) that are complementary to the function tag t. Iterate through the function tags t∈T in the function tag set T to calculate the complementary cloud APIs and obtain the positive corpus set P of the function tag set T. S42. Combine the function tag-cloud API mapping matrix F and the API-API non-co-occurrence matrix C. * Generate a set of cloud APIs N(t) that are not complementary to the function label t. Iterate through the function labels t∈T in the function label set T to perform non-complementary cloud API calculations, and obtain the negative corpus set N of the function label set T.
4. The functional tag-driven LDA-based cloud API complementary recommendation method of claim 1, wherein, Step S5 includes: S51. Input the positive corpus set P and the negative corpus set N into two LDA models with the same architecture for training, and obtain the positive model LDA-P that has a positive impact on complementary prediction and the negative model LDA-N that has a negative impact. S52. For the target function label tf, use the positive model LDA-P to perform complementary analysis and prediction on the candidate cloud API ca to obtain the complementarity degree Pred_P(tf,ca) representing the positive impact. At the same time, use the negative model LDA-N to perform complementary analysis and prediction on the candidate cloud API ca to obtain the complementarity degree Pred_N(tf,ca) representing the negative impact. S53. Introduce the negative model influence weight w, and use a weighted calculation method Pred(tf,ca)=Pred_P(tf,ca)-Pred_N(tf,ca)*w to obtain the complementarity value of candidate cloud API ca to target function label tf.
5. The functional tag-driven LDA-based cloud API complementary recommendation method of claim 2, wherein, Step S2 includes treating each function tag t∈T in the function tag set T as a document, and treating all co-occurring cloud APIs corresponding to cloud APIs containing function tag t as words in the document. The number of words is obtained by summing the number of co-occurring cloud APIs. Specifically, the implementation is as follows: extract all cloud API sets A from the parsed data, and construct the function tag set T according to the different types of function tags contained in all cloud APIs in A. T = {t1, t2, ...} Where: t i Let ∈T represent the i-th function label. To generate the function label-cloud API mapping matrix F, first map the function label t∈T in the function label set T to the cloud API set F(t) containing that function label. F(t) = {a1, a2, ...} Where: a i ∈F(t) represents the i-th cloud API containing the function label t. Next, each function label t∈T in the function label set T is mapped to obtain the function label-cloud API mapping matrix F. Finally, an API-API co-occurrence matrix C is generated based on the historical interaction records of the Mashup application and the cloud API. C = {c(i,j)} Where: c(i,j) represents cloud API a i and a j Co-occurrence count across all Mashup applications.
6. The function tag-driven LDA-based cloud API complementary recommendation method according to claim 5, characterized in that, Step S3 includes using nonnegative matrix factorization (NMF) to decompose the API-API co-occurrence matrix C into a feature matrix Q and an association matrix H, where the feature matrix Q represents the importance or weight of each cloud API in different features, and the association matrix H represents the correlation or co-occurrence relationship between cloud APIs; by iteratively updating Q and H, Q*H≈API-API co-occurrence matrix C, where the size of Q is |A|×D, the size of H is D×|A|, |A| is the size of the cloud API set, and D is the matrix factorization dimension; the co-occurrence probability of the Q*H cloud API pairs is used for reconstruction prediction. During the negative sampling process, the co-occurrence probability of cloud API pairs in the API-API co-occurrence matrix C is first predicted by reconstructing the model. Cloud APIs with lower co-occurrence probabilities will be sampled as negative samples with a higher probability. The API-API co-occurrence matrix C is then predicted using the trained feature matrix W and correlation matrix H. Finally, the cloud API a is calculated using the softmax function. i The prior probabilities of being plotted as negative sample cloud APIs are shown below: Where: c a [i] represents the restored prediction value of cloud API a for the i-th cloud API. The softmax function converts each restored prediction value into a probability value in the range [0,1]. The number of negative sample cloud APIs is determined by multiplying the number of co-occurring cloud APIs of cloud API a∈A by the sampling ratio τ. Then, negative sampling is performed by combining the prior probabilities of cloud API a and its candidate negative sample cloud APIs to obtain the set of non-co-occurring cloud APIs NA(a) corresponding to cloud API a. NA(a)={a1,a2,a3,…,where Pr(a1|a)≤Pr(a2|a)≤Pr(a3|a)…} Iterate through each cloud API a in set A i Given ∈A, we obtain its set of non-co-occurring cloud APIs, and further construct an API-API non-co-occurrence matrix C based on all non-co-occurring cloud API sets. * .
7. The function tag-driven LDA-based cloud API complementary recommendation method according to claim 1, characterized in that, The construction of the positive corpus set P in step S4 includes combining the function tag-cloud API mapping matrix F and the API-API co-occurrence matrix C to generate the complementary cloud API set P(t) of function tag t: P(t) = {a1, a2, ...} Where: a i ∈P(t) represents the i-th cloud API complementary to the function label t. The complementary cloud API is calculated by traversing the function label set T and performing the function label t∈T, resulting in a positive corpus P of function label set T = {t1, t2, ...}. P = {P(t1), P(t2), ...} Step S4 involves constructing the negative corpus N, which includes combining the function tag-cloud API mapping matrix F and the API-API non-co-occurrence matrix C. * Generate a set of non-complementary negative sample cloud APIs N(t) with functional label t; N(t) = {a1, a2, ...} Where: a i ∈N(t) represents the i-th negative cloud API that is not complementary to the function label t. By traversing the function label set T and performing non-complementary cloud API calculations on function labels t∈T, we obtain the negative corpus N of function label set T = {t1, t2, ...}: N = {N(t1), N(t2), ...}.
8. The function tag-driven LDA-based cloud API complementary recommendation method according to claim 1, characterized in that, The LDA model includes the processes of generating topic distributions and generating cloud APIs. Through this generation process, functional tag documents conforming to the LDA model are obtained, where each functional tag document consists of a topic distribution and a cloud API distribution. Given a set of cloud API functional tags T and a topic queue Z, the generation process of the LDA model is as follows:
1. For a function label t∈T, draw a topic distribution θ from the Dirichlet distribution α. t ; 2. For each topic z∈Z, extract the topic word cloud API distribution from the Dirichlet distribution β.
3. For a function label t∈T and its complementary cloud API set P(t): (a) From the topic distribution θ t Choose a topic z ta ~Categorical(θ) t ); (b) Select a cloud 9. The functional tag-driven LDA-based cloud API complementary recommendation method of claim 1, wherein, In step S5, the process of performing complementarity analysis and prediction using the trained LDA-P positive model and LDA-N negative model involves generating a complementary cloud API recommendation list based on a Mashup application developer's choice of a feature label t. This list incentivizes developers to make meaningful combinations. The complementarity value between the candidate cloud API ca∈A and the target feature label tf is Pred_P(tf,ca). The complementary analysis and prediction process based on LDA-P is as follows: Where tf represents the target function tag, ca represents the cloud API under topic z corresponding to the target function tag tf, Z represents the topic under the function tag, and θ tf,z This represents the topic probability corresponding to the target function label tf under known conditions. This represents the probability of a cloud API for topic z under known conditions; Similarly, by using the negative model LDA-N to predict the target function label tf and the candidate cloud API ca∈A, we obtain the negative complementarity value Pred_N(tf,ca). Further, we introduce the negative model influence weight w and calculate the complementary degree Pred(tf,ca) of the candidate cloud API ca∈A to the target function label tf by weighted calculation of the positive and negative model predictions. Pred(tf,ca)=Pred_P(tf,ca)-Pred_N(tf,ca)*w.
10. A function tag-driven, LDA-based cloud API complementary recommendation method according to claim 9, characterized in that, The complementarity prediction values Pred(tf,ca) are sorted from largest to smallest, and candidate cloud APIs with high complementarity are given priority recommendation to developers; the list of cloud APIs recommended based on the target function tag tf can be described as follows: Top-N(tf)={ca1,ca2,ca3,…|Pred(tf,ca1)≥Pred(tf,ca2)≥Pred(tf,ca3)…} Where: {ca1,ca2,ca3} represents the recommended list of cloud APIs, and Pred(tf,ca1) represents the predicted complementarity between cloud API ca1 and target function label tf.
Citation Information
Patent Citations
Service aggregation and functional information-based API recommendation method
CN106250391A
Functional implication relation and clustering-based Mashup recommendation method
CN107423396A