Web API recommendation method and device

Abstract

The invention discloses a Web API recommendation method and device, which are applied to the technical field of natural language processing, and the method comprises the following steps: obtaining text attribute data and call record data associated with a Web API; performing initialization processing on the calling record data to obtain an explicit adjacency matrix which is used for indicating an explicit cooperation weight between the API nodes; semantic feature modeling and candidate generation processing are conducted on the text attribute data, a semantic feature matrix and a plurality of candidate API nodes are obtained, and the feature matrix is used for indicating semantic feature values of the text attribute data on the implicit semantic dimension; performing graph structure enhancement and extension generation processing on the semantic feature matrix, the explicit adjacency matrix and the plurality of candidate API nodes to obtain a plurality of extended API nodes; and performing recommendation processing on the plurality of extended API nodes and the plurality of candidate API nodes to obtain a plurality of target API nodes. According to the method and the device, the Web API recommendation precision can be improved.

Description

Technical Field

[0001] The present application relates to the field of natural language processing technology, and in particular to a Web API recommendation method and device. Background Art

[0002] With the prevalence of cloud computing and microservices architectures, software development is gradually shifting from traditional component-based construction to service-based integration. Web APIs are application programming interfaces (APIs) that are called over the network. Currently, standardized Web APIs expose core functionality, enabling developers to quickly access remote service resources, reducing development costs and increasing system flexibility. The development of Web APIs has spawned a new type of application development service: the Mashup service. This technology allows developers to combine multiple independent Web APIs on demand to form feature-rich composite applications. For example, a "travel itinerary planning mashup" could access weather APIs, map APIs, and accommodation APIs. This eliminates the need for developers to repeatedly develop basic functionality, allowing them to focus on designing unique business logic. To identify suitable Web APIs for Mashup services from existing Web APIs, deep learning-based approaches have been proposed. These approaches typically combine content-based methods, collaborative filtering, natural language processing, and other related methods to process content information and historical call records, aiming to jointly optimize the semantic understanding capabilities and recommendation pattern mining of recommendation systems. These approaches perform well in scenarios with sufficient interaction records. Their fundamental approach relies on mining co-occurrence patterns between historical mashups and Web APIs. However, in the case of innovative mashup development needs or cold start scenarios of Mashup services (such as when a Mashup service is just created or a new Web API is introduced into a Mashup service), there is often a lack of effective call records between the target service combination and the existing Web APIs. The implementation of related technologies relies on call records, which makes it difficult to effectively capture feature information across Web APIs, causing a long-tail phenomenon and resulting in low accuracy in Web API recommendations in Mashup services. Summary of the Invention

[0003] The embodiments of the present application provide a Web API recommendation method and apparatus for effectively improving the accuracy of Web API recommendations in a Mashup service.

[0004] In one aspect, an embodiment of the present application provides a Web API recommendation method, comprising the following steps:

[0005] Get the text attribute data and call record data associated with the Web API;

[0006] Initializing the call record data to obtain an explicit adjacency matrix; wherein the explicit adjacency matrix is ​​used to indicate explicit collaboration weights between API nodes;

[0007] Performing semantic feature modeling and candidate generation processing on the text attribute data to obtain a semantic feature matrix and a plurality of candidate API nodes; wherein the semantic feature matrix is ​​used to indicate the semantic feature value of the text attribute data in the implicit semantic dimension;

[0008] Performing graph structure enhancement and expansion generation processing on the semantic feature matrix, the explicit adjacency matrix, and the plurality of candidate API nodes to obtain a plurality of extended API nodes;

[0009] Recommendation processing is performed on the multiple extended API nodes and the multiple candidate API nodes to obtain multiple target API nodes.

[0010] On the other hand, an embodiment of the present application provides a Web API recommendation device, including:

[0011] An initialization module, configured to obtain text attribute data and call record data associated with the Web API, and to initialize the call record data to obtain an explicit adjacency matrix; wherein the explicit adjacency matrix is ​​used to indicate explicit collaboration weights between API nodes;

[0012] A semantic fusion module is used to perform semantic feature modeling and candidate generation processing on the text attribute data to obtain a semantic feature matrix and a plurality of candidate API nodes; wherein the semantic feature matrix is ​​used to indicate the semantic feature values ​​of the text attribute data in the implicit semantic dimension;

[0013] A graph structure extraction module, configured to perform graph structure enhancement and expansion generation processing on the semantic feature matrix, the explicit adjacency matrix, and the plurality of candidate API nodes to obtain a plurality of extended API nodes;

[0014] The recommendation module is used to perform recommendation processing on the multiple extended API nodes and the multiple candidate API nodes to obtain multiple target API nodes.

[0015] According to a Web API recommendation method and device provided by an embodiment of the present application, text attribute data and call record data associated with a Web API are obtained; the call record data is initialized to obtain an explicit adjacency matrix, which is used to indicate the explicit collaboration weights between API nodes; semantic feature modeling and candidate generation processing are performed on the text attribute data to obtain a semantic feature matrix and multiple candidate API nodes, the feature matrix being used to indicate the semantic feature values ​​of the text attribute data on the implicit semantic dimension; graph structure enhancement and expansion generation processing are performed on the semantic feature matrix, the explicit adjacency matrix, and the multiple candidate API nodes to obtain multiple extended API nodes; and recommendation processing is performed on the multiple extended API nodes and the multiple candidate API nodes to obtain multiple target API nodes. This application can improve the recommendation accuracy of Web APIs.

[0016] Other features and advantages of the present application will be described in the following description, and in part will become apparent from the description, or will be understood by practicing the present application. The purposes and other advantages of the present application can be achieved and obtained through the structures particularly pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is a flowchart of a recommended Web API method provided by this application;

[0018] Figure 2 is an example graph for constructing an explicit adjacency matrix provided in this application;

[0019] Figure 3A This is an example diagram of constructing a semantic embedding matrix provided by this application;

[0020] Figure 3B This is an example diagram of the matrix projection provided by this application;

[0021] Figure 3C This is an example diagram of the multi-head attention mechanism provided by this application;

[0022] Figure 4 This is an example diagram for obtaining candidate API nodes provided by this application;

[0023] Figure 5A This is an example diagram of the diagram coding process provided by this application;

[0024] Figure 5B This is an example diagram of virtual edge decoding provided by this application;

[0025] Figure 5C This is an example diagram of constructing an enhancement matrix provided by this application;

[0026] Figure 6AThis is a table showing the top K digit accuracy of different variants of the embodiment of the present application when the recommendation list length is 30;

[0027] Figure 6B This is a table showing the recall rates of the top K items of different variants of the embodiment of the present application when the length of the recommendation list is 30;

[0028] Figure 6C This is a table showing the average accuracy of the top K items of different variants of the embodiment of the present application when the recommendation list length is 30. DETAILED DESCRIPTION

[0029] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0030] The present application is further described below in conjunction with the accompanying drawings and specific embodiments. The described embodiments should not be considered as limiting the present application. All other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0031] In the following description, reference is made to “some embodiments,” which describes a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0032] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0033] In response to the problems and defects existing in the related technologies, the embodiments of the present application provide a Web API recommendation method and device with semantic enhancement and topology expansion capabilities, which can not only overcome the data sparsity problem in the service cold start scenario, but also effectively alleviate the long tail phenomenon caused by data missing, thereby effectively improving the recommendation accuracy of Web API in Mashup services.

[0034] The following will describe in detail the implementation steps of a Web API recommendation method provided by an embodiment of the present application with reference to the accompanying drawings.

[0035] The Web API recommendation method provided in the embodiment of the present application can be applied to a terminal, a server, or software running in a terminal or a server. The terminal can be a tablet computer, a laptop computer, a desktop computer, etc., but is not limited thereto. The server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. In addition, the server can also be a node server in a blockchain network, but is not limited thereto. Among them, blockchain is a new application model of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm.

[0036] Reference Figure 1 , the Web API recommendation method may include the following steps S101-S105.

[0037] S101, obtaining text attribute data and call record data associated with the Web API.

[0038] It should be noted that the text attribute data associated with the Web API may include Mashup service requirement text data, Web API description text data, and Mashup design text data. In addition, the call record data may include log data when each WebAPI is called in a real business scenario.

[0039] In this step, the development requirement text of the Mashup application to be deployed is obtained. The development requirement text describes key information such as the functional requirements, performance constraints, and business scenarios of the Mashup service, and can be submitted in advance by the developer through an interactive interface or a standard API. The development requirement text is pre-processed, such as removing special characters, word segmentation, and length truncation (such as limiting it to 128 words), so as to obtain the Mashup service requirement text data. Optionally, the Mashup service requirement text data is temporarily stored in a distributed message queue as a data source for subsequent semantic modeling and cross-modal recommendation processes.

[0040] Obtain standardized description documents for all Web APIs. These documents describe metadata such as interface functionality, input parameters, output parameters, and protocol types, and can be loaded from the service registry via a pre-defined data connector. Automatically verify the integrity and formatting of all Web API description documents, removing entries with missing fields or formatting violations to obtain Web API description text data. Optionally, cache the Web API description text data in a pre-defined database to build a highly available multimodal data source for subsequent semantic embedding calculations and graph structure analysis.

[0041] Obtain the design documents of successfully deployed mashup applications. These documents cover key information such as functional objectives, service composition logic, and performance metrics, and can be extracted from the historical log repository. Automatically verify the integrity and formatting of these documents, removing entries with missing fields or formatting violations to obtain the mashup design text data. Optionally, cache the mashup design text data in a pre-defined database to build a highly available multimodal data source for subsequent semantic embedding calculations and graph structure analysis.

[0042] Obtain log data for all Web APIs when they are called in real business scenarios and perform data cleansing on the log data, such as filtering out invalid calls or test data, to obtain call record data.

[0043] S102 , performing initialization processing on the call record data to obtain an explicit adjacency matrix; wherein the explicit adjacency matrix is ​​used to indicate explicit collaboration weights between API nodes.

[0044] In this step, the call record data is initialized to obtain an explicit adjacency matrix. This matrix indicates the explicit collaboration weights between two API nodes, that is, explicit edges, which reflect the actual service composition pattern. This can effectively capture the actual co-occurrence relationship between API nodes in real business scenarios.

[0045] S103, performing semantic feature modeling and candidate generation processing on the text attribute data to obtain a semantic feature matrix and multiple candidate API nodes; wherein the semantic feature matrix is ​​used to indicate the semantic feature values ​​of the text attribute data in the implicit semantic dimension.

[0046] In this step, semantic feature modeling is performed on the text attribute data to obtain a semantic feature matrix. This matrix indicates the semantic feature values ​​of the text attribute data in the implicit semantic dimension. This can capture the implicit relationship between APIs from a shallow perspective and generate a semantic embedding vector with domain adaptation. This not only effectively overcomes the semantic ambiguity of short texts, but also achieves fine-grained alignment of cross-modal functional features. Subsequently, candidate generation processing is performed based on the semantic feature matrix to obtain multiple candidate API nodes. The purpose is to quantify the semantic association strength between mashup service requirements and web APIs. Based on this, web APIs with high correlation with mashup service requirements can be quickly screened out from the massive web APIs, completing the initial screening of web APIs.

[0047] S104, performing graph structure enhancement and extension generation processing on the semantic feature matrix, the explicit adjacency matrix, and the plurality of candidate API nodes to obtain a plurality of extended API nodes.

[0048] In this step, the semantic feature matrix and explicit adjacency matrix are enhanced with a graph structure. This aims to capture implicit relationships between APIs from a deeper perspective, namely implicit edges (virtual edges), based on explicit edges and shallow implicit relationships. This addresses data sparsity, particularly in cold start and long-tail scenarios. Subsequently, based on the enhanced graph structure and multiple candidate API nodes, an extension generation process is performed to obtain multiple extended API nodes. This aims to discover potential collaborative WebAPIs, expand the solution space for Web API recommendations, break through local optimality limitations, and effectively improve the diversity of Web API recommendations.

[0049] S105 , performing recommendation processing on the multiple extended API nodes and the multiple candidate API nodes to obtain multiple target API nodes.

[0050] In this step, the extended API node represents the Web API node in the graph topology space, while the candidate API node represents the Web API node in the semantic feature space. By recommending multiple extended API nodes and multiple candidate API nodes, the distribution differences between the semantic feature space and the graph topology space can be effectively integrated, and the cross-modal feature fusion weights can be dynamically adjusted to generate a recommendation sequence, thereby obtaining multiple target API nodes. The target API node is the final recommended Web API.

[0051] It can be seen that the embodiment of the present application proposes a parallel explicit representation mining framework and an implicit representation learning framework, which can further capture feature information across Web APIs in both explicit and implicit dimensions, and fully mine the explicitly expressed and implicitly expressed Web API features. On the one hand, this makes it possible to mine feature information across Web APIs in cold start scenarios without relying on historical call records. On the other hand, it enriches Web API feature information through explicit mining and implicit mining, providing more Web API feature information that is more targeted at current Mashup service needs. Accordingly, the embodiment of the present application proposes a serial Web API preliminary screening framework and a Web API expansion framework. The serial mechanism first performs a preliminary screening of Web APIs and mines potential collaborative Web APIs based on this, expands the recommended solution space of Web APIs, and combines the above content to obtain the final recommended Web API, which can effectively improve the recommendation accuracy of Web APIs in Mashup services, make the recommended Web APIs more in line with actual Mashup service needs, and alleviate the problem of insufficient coverage of long-tail Web APIs due to data sparsity in cold start scenarios.

[0052] In some embodiments, reference Figure 2 In the above step S102, the call record data is initialized to obtain an explicit adjacency matrix, including:

[0053] Based on the call record data, an initial adjacency matrix is ​​obtained; in which, both rows and columns represent API nodes, and the elements represent the number of explicit collaborations between two API nodes; the initial adjacency matrix is ​​logarithmically scaled and linearly compressed to obtain an explicit adjacency matrix; in which, both rows and columns represent API nodes, and the elements represent the explicit collaboration weights between two API nodes.

[0054] In this implementation, the call graph structure extraction component analyzes the actual co-occurrence relationship between Web APIs from historical call record data and constructs an explicit adjacency matrix based on the co-occurrence frequency and the number of combinations. This process first counts the frequency of joint calls of each pair of WebAPIs in real business scenarios, encodes the connection relationship with a frequency higher than the preset frequency threshold as the edge weight of the adjacency matrix, and finally generates a sparse matrix reflecting the historical service combination rules, namely the explicit adjacency matrix A. ex .

[0055] Specifically, first, the number of explicit collaborations between each pair of API nodes is extracted from the call record data, that is, the number of times each pair of API nodes has collaborated in the same Mashup, and the initial adjacency matrix C is constructed based on this. In the initial adjacency matrix C, both rows and columns represent API nodes (i.e., API i), where the element represents the number of explicit collaborations between two API nodes. For example, the number of explicit collaborations between API1 and API2 is 0, and the number of explicit collaborations between API1 and API3 is 1. Optionally, the maximum value of the elements of the initial adjacency matrix C is limited to no more than 24, that is, the maximum value of the number of explicit collaborations is 24. This can prevent the weight of high-frequency collaboration pairs from being too high, drowning out low-frequency but important collaboration pairs. Next, each element in the initial adjacency matrix C is logarithmically scaled, as shown in the following formula (1):

[0056] A log [i,j]=ln(1+C[i,j]) (1);

[0057] In formula (1), A log [i,j] represents the element value in the i-th row and j-th column of the initial adjacency matrix after logarithmic scaling; C[i,j] represents the element value in the i-th row and j-th column of the initial adjacency matrix C.

[0058] Finally, in order to limit the weights to a fixed range, such as [0, 1.5], to ensure the numerical stability of the downstream graph neural network, it is necessary to further perform linear compression on the initial adjacency matrix after logarithmic scaling, as shown in the following formula (2):

[0059]

[0060] In formula (2), A ex [i,j] represents the explicit adjacency matrix A ex The value of the element in row i and column j; min(A log ) represents the minimum value of the elements in the initial adjacency matrix after logarithmic scaling; max(A log ) represents the maximum value of the elements in the initial adjacency matrix after logarithmic scaling; w max Indicates the upper limit of the value range; w min Indicates the lower limit of the range. The upper and lower limits of the range can be flexibly set according to actual conditions, for example, w min =0, which means the weight is 0 when there is no collaboration, w max =1.5, which means that the weight corresponding to the maximum collaboration is 1.5. Taking the row [24 0 0 1] where API1 is located in the initial adjacency matrix C as an example, the row is converted to [3.2 0 0 0.7] using the above formula (1), and then [3.2 0 0 0.7] is converted to the final explicit adjacency matrix A using the above formula (2). ex [1.5 0 0 0.3] in.

[0061] This operation effectively captures the actual co-occurrence relationship between API nodes in real business scenarios and fully reflects the real service composition pattern.ex It will serve as the input basis of the graph neural network and provide structured prior knowledge for subsequent topological feature extraction and virtual edge generation.

[0062] In some embodiments, reference Figures 3A to 3C In the above step S103, semantic feature modeling and candidate generation processing are performed on the text attribute data to obtain a semantic feature matrix and multiple candidate API nodes, including:

[0063] The text attribute data is subjected to text embedding processing to obtain a semantic embedding matrix; wherein, in the semantic embedding matrix, rows represent text attribute data, columns represent implicit semantic dimensions, and elements represent intensity values ​​of the text attribute data on the implicit semantic dimensions; the semantic embedding matrix is ​​dimensionally compressed to obtain a compressed semantic embedding matrix; a multi-head attention operation is performed on the compressed semantic embedding matrix to obtain a semantic feature matrix; wherein, in the semantic feature matrix, rows represent text attribute data, columns represent implicit semantic dimensions, and elements represent semantic feature values ​​of the text attribute data on the implicit semantic dimensions.

[0064] In this embodiment, first, Figure 3A As shown, the pre-trained SBERT model is loaded and the Mashup service demand text data D is calculated in parallel. d , Web API describes text data D a and Mashup Design Text Data D m The text embedding of Mashup service demand text data D d , Web API describes text data D a and Mashup Design Text Data D m The preprocessed text sets are divided into three groups according to their sources and are input into the encoding layer of the SBERT model in sequence through the dynamic batch processing mechanism. d , Web API describes text data D a and Mashup Design Text Data D m The three corresponding sub-matrices are concatenated to obtain the semantic embedding matrix h. The core calculation process of this model is shown in the following formula (3):

[0065] Y=MeanPooling(Transformer(Embed(X))) (3);

[0066] In formula (3), X represents a text index with a batch size of B and a sequence length of L, such as the Mashup service demand text data D d, Web API describes text data D a or Mashup design text data D m Y represents the submatrix corresponding to the text index. Here, the word embedding layer (i.e., Embed) maps it to a dense tensor, which is then passed through the Transformer encoder to capture the contextual semantics. Finally, the hidden state of the sequence is mean-pooled (i.e., MeanPooling) to obtain the sentence vector, i.e., the submatrix.

[0067] Here, the initial semantic embedding, i.e., the semantic embedding matrix h, is constructed through the 768-dimensional semantic space pre-trained by the SBERT model. It represents the basic semantic information of Mashup service requirements, Web APIs, and Mashup services, which provides basic semantic signals for subsequent operations such as projection and graph construction. Figure 3A As shown, the dimension of the semantic embedding matrix h is (1+n+m)×768, where 1 represents the current Mashup service demand node, n is the number of API nodes, and m represents the number of historical Mashup service nodes, where:

[0068] Each line corresponds to a text sample (i.e., text attribute data), and the line construction follows strict node order rules: Line 0 represents the embedding of the current Mashup service requirement node, corresponding to the Mashup service requirement text data encoding; Lines 1 to n represent the embedding of API nodes, corresponding to the Web API description text data encoding; Lines n+1 to n+m represent the embedding of historical Mashup service nodes, corresponding to the Mashup design text data (i.e., existing service combination patterns) encoding.

[0069] Each column represents a dimension of the semantic embedding vector output by the SBERT model, which is called the implicit semantic dimension. The number of dimensions is fixed to 768 (consistent with the hidden layer dimension of the SBERT-base model) and is the fixed output dimension of the pre-trained model.

[0070] Each element represents the intensity value of a text sample (requirements / APIs / Mashups) on an implicit semantic dimension. These dimensions are abstract semantic features learned by the SBERT model through pre-training, including: local features, which indicate the contextual relevance of specific keywords; global features, which indicate the implicit classification of functional scenarios; syntactic features, which indicate the sentence structure pattern of short texts. The value of a single dimension has no clear semantic interpretation, but the overall vector can represent the semantics of the text. In addition, because the SBERT model uses mean pooling and layer normalization, the element values ​​of the semantic embedding matrix h are distributed between [-1,1].

[0071] Then, if Figure 3BAs shown in the figure, the semantic embedding matrix h is dimensional compressed by a learnable projection layer, and the compressed semantic embedding matrix h′ is output. This can map the high-dimensional semantic embedding vector 768 dimensions to a low-dimensional space 256 dimensions compatible with the graph neural network, and unify the dimensions with the embedding space of the downstream graph neural network, thereby solving the problem of feature scale and distribution differences between modalities, as shown in the following formula (4):

[0072] h′=ReLU(hW p +b p ) (4);

[0073] In formula (4), W p is the weight matrix, b p Represents the bias vector, both of which are trainable parameters; the ReLU activation function is used to introduce nonlinearity to enhance feature expression capabilities.

[0074] Finally, a multi-head self-attention mechanism performs deep semantic interaction on the projected adaptation features (i.e., the compressed semantic embedding matrix h′), modeling the potential associations between different service entities from multiple perspectives. Specifically, N self-attention heads are provided, each responsible for modeling functional associations of different semantic dimensions (such as functional compatibility, protocol matching, QoS constraints, data format consistency, etc.) and capturing local features (such as 64-dimensional encodable single functional attributes). The number of self-attention heads can be flexibly set based on actual conditions. For example, the number of self-attention heads can be four. Graphics Processing Units (GPUs) are more efficient in optimizing matrix operations on dimensions that are multiples of four (such as 64 and 128), which helps improve training speed. Furthermore, considering that the average length of descriptions of Web APIs and mashup services can be considered short text in traditional text tasks, four self-attention heads help focus on key features in a limited context and reduce the risk of overfitting. For another example, the number of self-attention heads can be eight, which is more suitable for high-resource scenarios but requires dynamic head pruning or other related techniques to prevent overfitting. For another example, the number of self-attention heads can be 2, which can sacrifice some performance to reduce latency when deployed on edge devices (such as mobile phones).

[0075] Take 4 self-attention heads as an example, Figure 3CAs shown, the compressed 256-dimensional semantic embedding matrix h′ is split into four 64-dimensional subspaces by column, each corresponding to a self-attention head. The goal is to use independent subspaces to model association patterns of different dimensions, such as functional compatibility, protocol matching, QoS constraints, and data format consistency, thereby capturing the functional dependencies between different subspaces. It should be noted that the association pattern and the independent subspaces are not strictly one-to-one, but rather an implicit many-to-many association. However, in design, each subspace focuses on a specific pattern, and it autonomously captures different association patterns through random initialization of the parameter matrix and gradient updates during training. For example, one self-attention head may focus more on functional compatibility, such as "payment" and "SMS verification," while another self-attention head focuses on protocol matching, such as SOAP (Simple Object Access Protocol) and REST (Representational State Transfer). For each attention head, the feature matrix of the subspace corresponding to the self-attention head is multiplied by the trainable query weight matrix, key weight matrix, and value weight matrix respectively to generate the query vector Q, key vector K, and value vector V corresponding to the self-attention head, and the attention feature matrix of the self-attention head is calculated by the following formula (5):

[0076]

[0077] In formula (5), Attention(Q,K,V) represents the subspace feature matrix corresponding to the self-attention head; d k Represents the preset feature dimension. Here, after calculating the dot product of the first row of query vector Q and all key vectors K, the weight distribution α is normalized using Softmax. For example, in an attention head, the first element of its weight distribution α represents the strength of the association between the current mashup service demand node and the first API node in the functional compatibility subspace. Subsequent elements correspond to other API nodes and historical mashup service nodes, respectively. After weighted aggregation of the value vector V, a 64-dimensional attention feature matrix is ​​obtained.

[0078] Subsequently, the attention feature matrices of all self-attention heads are concatenated and then linearly transformed to obtain the semantic feature matrix H. In the semantic feature matrix H, each row corresponds to a text sample (i.e., text attribute data, which has the same meaning as the vector rows of the semantic embedding matrix h), and each column represents the implicit semantic dimension after multi-head attention fusion. The number of dimensions is 256. Each dimension is a weighted combination of multiple subspaces, used to represent the comprehensive semantic information across association modes, and each element represents the semantic feature value of the text sample (demand / API / Mashup) on the implicit semantic dimension after multi-head attention fusion. Here, through multi-subspace association modeling, the fine-grained semantic interaction between Mashup service requirements and Web APIs is explicitly enhanced, resulting in an optimized semantic embedding. The 256-dimensional semantic space provided by this cross-modal interaction association provides highly discriminative fused semantic signals for downstream tasks (such as recommendation and graph construction).

[0079] In some embodiments, reference Figure 4 In the above step S103, semantic feature modeling and candidate generation processing are performed on the text attribute data to obtain a semantic feature matrix and multiple candidate API nodes, including:

[0080] Obtain the semantic similarity between the first row vector in the semantic feature matrix and other row vectors in the semantic feature matrix associated with the API node except the first row vector; determine the API node whose semantic similarity is greater than a preset similarity threshold as a candidate API node.

[0081] In this implementation, similarity calculation is used to quantify the semantic correlation strength between Mashup service requirements and Web APIs, and Web APIs with high correlation are quickly screened out from a large number of Web APIs to form a candidate set. Specifically, given a semantic feature matrix H, first, the first row vector h is extracted. d=H0 as the Mashup service demand embedding. Here, as described in the previous embodiment, the row construction of the semantic embedding matrix h follows a strict node order rule, and the semantic feature matrix H adopts the same row definition as the semantic embedding matrix h, so the row construction of the semantic feature matrix H also follows a strict node order rule. This row construction enables the first row vector (index 0) to uniquely and clearly correspond to the current Mashup service demand node, rather than the API node or the historical Mashup service node. In addition, in the multi-head attention calculation, the current Mashup service demand node serves as the global query center, and its embedding needs to be independently identified to guide feature fusion. If the position of the current Mashup service demand node is not fixed, such as randomly assigning row indexes, it is impossible to stably learn how to identify the Mashup service demand subject from the mixed nodes, resulting in uncontrollable recommendation results. Taking the above factors into consideration, this embodiment selects the first row element of the semantic feature matrix H as the Mashup service demand embedding. Then, for the other row vectors associated with the API node except the first row vector H0 in the semantic feature matrix H, that is, the vectors in the 1st to nth rows in the semantic feature matrix H, the cosine similarity between the other row vectors and the first row vector H0 is calculated as the semantic similarity, as shown in the following formula (6):

[0082]

[0083] In formula (6), cos sim (a,b) represents the cosine similarity between other row vectors and the first row vector; a represents the Mashup service requirement embedding, that is, the first row vector H0; b represents other row vectors, that is, the API features of the 1st to nth rows in the semantic feature matrix H.

[0084] In this way, the semantic similarity between the first row vector H0 and each other row vector associated with the API node can be obtained, and they are integrated into the semantic similarity matrix S, which is a matrix containing the specific numerical values ​​of the semantic similarity between the Mashup service requirement embedding H0 and all API features. Finally, the API nodes with semantic similarity greater than the preset similarity threshold are determined as candidate API nodes. Here, it can be understood that after sorting the semantic similarity matrix S in descending order of similarity, the first K API nodes are selected as candidate API nodes, and the initial solution set R is formed accordingly. init The K value can be flexibly set according to actual conditions, and this embodiment does not impose any specific limitation on this.

[0085] In some embodiments, in step S104, the semantic feature matrix, the explicit adjacency matrix, and the plurality of candidate API nodes are subjected to graph structure enhancement and expansion generation processing to obtain a plurality of extended API nodes, including:

[0086] The semantic feature matrix and the explicit adjacency matrix are graph encoded to obtain a graph embedding vector. The graph embedding vector is then subjected to virtual edge decoding to obtain a virtual edge matrix, which is then superimposed and fused with the explicit adjacency matrix to obtain an enhanced matrix. In the virtual edge matrix, both rows and columns represent API nodes, and elements represent the implicit collaboration probability between two API nodes. Based on the enhanced matrix, a multi-hop graph structure is extended for multiple candidate API nodes to obtain multiple extended API nodes.

[0087] In this embodiment, first, the semantic feature matrix and the explicit adjacency matrix are subjected to graph encoding processing to generate the mean and logarithmic variance of the potential distribution parameters, and the graph embedding vector is sampled based on the reparameterization technique. This process can retain the explicit rules of the Mashup service combination and capture the possibility of implicit collaboration through probabilistic modeling, thereby providing a representation basis for the subsequent generation of implicit edges and multi-hop expansion. Then, the graph embedding vector is subjected to virtual edge decoding processing to obtain a virtual edge matrix, in which both rows and columns represent API nodes (i.e., API nodes). i ), the element represents the implicit collaboration probability between two API nodes. This process can add multiple implicit edges, thereby expanding the scope of candidate recommendations and improving the support for innovative service combinations. Afterwards, the virtual edge matrix and the explicit adjacency matrix are superimposed and fused to obtain an enhanced matrix. This process fuses the virtual edge matrix of implicit semantic associations with the explicit adjacency matrix that represents explicit call patterns, so that explicit connections and newly added virtual edges coexist in the same topological space, thereby capturing the implicit relationship between APIs from a deep perspective based on explicit edges and shallow implicit relationships, solving the problem of data sparsity, especially in cold start and long tail situations. Finally, based on the results of graph structure enhancement and multiple candidate API nodes, an extension generation process is performed to obtain multiple extended API nodes, aiming to explore potential collaborative Web APIs, expand the solution space of Web API recommendations, break through local optimal limitations, and effectively improve the recommendation diversity of Web APIs.

[0088] In some embodiments, reference Figure 5A , the above-mentioned graph encoding processing is performed on the semantic feature matrix and the explicit adjacency matrix to obtain a graph embedding vector; the graph embedding vector is subjected to virtual edge decoding processing to obtain a virtual edge matrix, including:

[0089] The semantic feature matrix and the explicit adjacency matrix are fused to obtain the global service topology graph; the global service topology graph is encoded using a graph variational autoencoder to obtain the latent space mean and latent space variance; the latent space mean and latent space variance are reparameterized to obtain the graph embedding vector.

[0090] In this embodiment, the initial solution set Rinit The API node in is used as the starting point, based on the semantic feature matrix H and the explicit adjacency matrix A ex Construct a global service topology graph and fuse structural information and semantic features through graph variational autoencoders. Specifically, the explicit adjacency matrix A constructed based on call record data ex The actual call relationship between Web APIs is defined, and the semantic feature matrix H optimized by the multi-head attention mechanism captures the deep semantic association between Mashup service requirements, Web APIs and historical Mashups. Therefore, the explicit adjacency matrix A ex and semantic feature matrix H to construct the global service topology graph H (0) Able to effectively integrate global information (including explicit call relationships and implicit semantic associations). Global service topology diagram H (0) The construction can start from the explicit adjacency matrix A ex The collaborative processing of the semantic feature matrix H will make the explicit adjacency matrix A ex Adding it to the semantic feature matrix H can get the global service topology map H (0) Then, in the graph variational autoencoder (GCN encoder), each node feature in the semantic feature matrix H is transformed along the explicit adjacency matrix A. ex The topological structure defined by the node is multi-level neighbor aggregation: the first-level GCN sums the semantic features of the node itself and the features of its direct neighbors according to the edge weight, and generates an intermediate representation H through the activation function (1) , as shown in the following formula (7):

[0091]

[0092] In formula (7), Represented by the explicit adjacency matrix A ex The adjacency matrix after symmetric normalization; W (0) Represents the preset weight matrix.

[0093] The second layer GCN further integrates the output of the first layer GCN to extend the information of the second-order neighbors to form a node embedding H that integrates local and global structures. (2) , as shown in the following formula (8):

[0094]

[0095] In formula (8), W (1) Represents the preset weight matrix.

[0096] Afterwards, the intermediate representation H output by the first layer GCN (1) And the node embedding H output by the second layer GCN (2)They are mapped to the latent space mean μ and the latent space variance logσ respectively through the corresponding multi-layer perceptron (MLP) 2 , the latent space mean μ dominates the deterministic semantics, and the latent space variance logσ 2 Regulate random exploration as shown in the following formula (9):

[0097] μ=MLP(H (1) ), logσ 2 =MLP(H (2) ) (9).

[0098] Finally, based on the reparameterization technique from the Gaussian distribution We sample the graph and get the graph embedding vector Z as shown in the following formula (10):

[0099] Z=μ+∈⊙exp(logσ 2 / 2) (10);

[0100] In formula (10), Z represents the graph embedding vector; represents random noise.

[0101] This process allows cold-start services (e.g., services with zero historical calls) to inject noise perturbations through topological propagation, even when lacking historical call data, to explore potential association patterns. For example, the semantic feature values ​​of a candidate API node might be [0.11, 0.23, -0.07…]. After two layers of GCN encoding, its mean vector might evolve to [0.18, -0.02, 0.31…], and its log-variance vector to [-1.2, 0.5, -0.8…]. The resulting sampled graph embedding combines deterministic semantics (driven by μ) with stochastic exploration (controlled by σ), and its dimensionality is compressed to 128 to accommodate downstream computations. The output graph embedding from this process preserves the explicit regularities of mashup service composition, such as the strong correlation between payment and SMS verification, while also capturing the potential for implicit collaboration through probabilistic modeling, such as the potential complementarity between a geolocation web API and a weather service. This provides a representational foundation for subsequent implicit edge generation and multi-hop expansion.

[0102] In some embodiments, reference Figure 5B and Figure 5C , the above virtual edge decoding process is performed on the graph embedding vector to obtain a virtual edge matrix, and the virtual edge matrix and the explicit adjacency matrix are superimposed and fused to obtain an enhanced matrix, including:

[0103] An inner product operation is performed on the graph embedding vector and the transposed graph embedding vector to obtain an inner product similarity matrix. The inner product similarity matrix and the semantic similarity matrix are fused to obtain a virtual edge matrix. The semantic similarity matrix is ​​used to indicate the semantic similarity between the first row vector in the semantic feature matrix and other row vectors in the semantic feature matrix associated with the API node except the first row vector. The virtual edge matrix is ​​binarized to obtain a binarized virtual edge matrix. The binarized virtual edge matrix is ​​superimposed on the explicit adjacency matrix to obtain an enhanced matrix.

[0104] In this implementation, a probability matrix between pairs of API nodes is generated based on the graph embedding vector, and the generated virtual edges are filtered out through a probability threshold to obtain a virtual edge matrix. Subsequently, an enhanced matrix containing virtual edges is constructed based on the explicit adjacency matrix. This process is based on the graph embedding vector and models the implicit association probability between API nodes through an inner product decoder, and then integrates semantic similarity constraints to balance structural dependency and semantic consistency.

[0105] Specifically, first, the inner product similarity matrix P of the latent embedding is calculated latent , the inner product similarity matrix P latent Indicates the potential collaboration probability between different API nodes. Here, the inner product similarity matrix P can be obtained by performing an inner product operation on the graph embedding vector Z and the transposed graph embedding vector latent , that is, P latent =Z·Z T At the same time, the corresponding relationship is extracted from the semantic similarity matrix S, and the two signals are dynamically fused through the learnable weight parameter λ to obtain the final virtual edge matrix P virtual , in the virtual edge matrix P virtual In the example, rows and columns represent API nodes (i.e., API i ), the element represents the implicit collaboration probability between two API nodes, Figure 5B middle The fusion process is represented as follows:

[0106] P virtual =σ(λP latent +(1-λ)S) (11);

[0107] In formula (11), σ represents the Sigmiod function that normalizes the value to the interval [0,1].

[0108] For example, if the potential collaboration probability between a logistics web API and an inventory management web API is 0.82, and their semantic similarity is 0.65, the fusion result when λ = 0.6 is 0.6 × 0.82 + 0.4 × 0.65 = 0.752. After Sigmoid activation, the probability increases to 0.87, reflecting the dual driving forces of structural association and semantic complementarity. This process pays special attention to the enhancement logic of long-tail nodes: if their semantic similarity with mainstream services is high (S = 0.78) but their historical co-occurrence is sparse (P = 0.15), semantic guidance is strengthened by reducing λ (for example, to 0.3) to avoid missing associations due to insufficient topological data.

[0109] Afterwards, the virtual edge matrix P representing the implicit semantic association is superimposed on the matrix. virtual and an explicit adjacency matrix A reflecting the explicit calling pattern ex The fusion is performed to construct a global enhanced adjacency matrix, namely the enhanced matrix, to support the deep reasoning of the downstream graph neural network. Specifically, Figure 5C As shown, the explicit adjacency matrix A ex The co-occurrence frequency or explicit call relationship between Web APIs in the encoding history Mashup, and the virtual edge matrix P virtual Through the threshold function P virtual ≥τ is binarized to obtain the binarized virtual edge matrix I. This process only retains virtual edges above the threshold τ, as shown in the following formula (12):

[0110]

[0111] In formula (12), I (i,j) Represents the element value of the i-th row and j-th column in the binary virtual edge matrix I; Represents the virtual edge matrix P virtual The element value of the i-th row and j-th column in ; τ represents a preset binarization threshold, which can be flexibly set according to actual conditions, for example, τ = 0.6, but is not limited thereto.

[0112] Next, the binary virtual edge matrix I and the explicit adjacency matrix A ex Perform element addition processing to obtain the enhanced matrix A enhanced , that is, A enhanced =A ex+I allows explicit connections (such as the strong historical co-occurrence edge between the Payment Web API and the Authentication Web API) and newly added virtual edges (such as the edge created by semantic coupling between the Map Web API and the Traffic Flow Web API) to coexist in the same topological space. For example, a newly added virtual edge might connect the Location Web API and the Traffic Services Web API. Even though the two have never appeared together in the historical mashup service, the strong similarity of their semantic features drives the discovery of potential collaborative relationships, thereby expanding the scope of Web API recommendations and improving support for innovative service combinations.

[0113] In some implementations, the multi-hop graph structure expansion of multiple candidate API nodes based on the enhancement matrix to obtain multiple extended API nodes includes:

[0114] For each candidate API node, determine the one-hop reachable API node and the two-hop reachable API node of the candidate API node on the enhancement matrix, retain the one-hop reachable API nodes whose element values ​​in the enhancement matrix are greater than a preset element threshold, retain the two-hop reachable API nodes that have cross-connections with at least two candidate API nodes, and determine the retained one-hop reachable API nodes and the retained two-hop reachable API nodes as extended nodes of the candidate API node; and obtain multiple extended API nodes based on the multiple candidate API nodes and the extended nodes of the multiple candidate API nodes.

[0115] In this embodiment, based on the enhanced matrix A enhanced For the initial solution set R init The multi-hop graph structure is extended to explore potential collaborative Web APIs and break through local optimal limitations. Specifically, first, through matrix multiplication Determine the initial solution set R init Each candidate API node in the enhanced matrix A enhanced The set of nodes reachable by k hops on , k∈{1,2}.

[0116] For one-hop neighbors (direct neighbors), directly by the enhanced matrix A enhanced The row vector of is extracted, that is, for the initial solution set R init For each candidate API node in the enhanced matrix A, obtain the candidate API node in the enhanced matrix A enhanced The row vector on is used as the target row vector, and the API nodes whose element values ​​in the target row vector are not zero are selected as one-hop reachable API nodes. For example, Figure 5C The enhanced matrix shown, assuming that API3 is the initial solution set R init A candidate API node in the enhanced matrix A enhancedThe row vector on is [0 0.3 1.0 0]. It can be seen that API1 and API2 are directly associated with API3, and API1 and API2 are one-hop reachable API nodes of API3.

[0117] For two-hop neighbors (indirect neighbors), through matrix multiplication Extract, that is, calculate the enhancement matrix A enhanced With the enhanced matrix A enhanced The product of is taken as the target matrix, for the initial solution set R init For each candidate API node in , obtain the row vector of the candidate API node on the target matrix as the target row vector, and select the API node whose element value in the target row vector is not zero and is not a one-hop reachable API node as the two-hop reachable API node. For example, Figure 5C The enhanced matrix shown, assuming that API3 is the initial solution set R init A candidate API node in the enhanced matrix A enhanced The row vector on is [0 0.31.0 0], which is A after matrix multiplication. enhanced ×A enhanced , the target row vector is [1.25 1 0.3 1.09]. The nodes whose values ​​in the target row vector are not 0 are the other three nodes that can be reached from API3 after two hops, namely API0, API1, and API2. By comparing the directly associated API nodes, it can be found that API3 is only indirectly associated with API0, which is the API node that can be reached by two hops from API3.

[0118] After that, we can calculate the cross-hop semantic similarity through the graph embedding vector Z to filter out the k-hop reachable API nodes with low correlation. More specifically, we calculate the initial solution set R init The semantic similarity between the graph embedding vector of each candidate API node and the graph embedding vector of its k-hop reachable API node is calculated, and a preset filtering threshold is set to filter out low-correlation direct or indirect neighbors below the filtering threshold. The filtering threshold can be 0.6, but is not limited to this. The process is shown in the following formula (13):

[0119]

[0120] In formula (13), sim z (i′,u) represents the initial solution set R init The semantic similarity between the graph embedding vector of the i′th candidate API node and the graph embedding vector of the uth k-hop reachable API node in Z; i′ Represents the initial solution set R init The graph embedding vector Z of the i′th candidate API node in Z u Represents the initial solution set Rinit The graph embedding vector of the u-th k-hop reachable API node corresponding to the i′-th candidate API node in .

[0121] Here, first, the graph embedding vector Z comes from the graph variational autoencoder, whose input is the semantic feature matrix H, which itself encodes the deep semantics of the functional description text of the Web API and Mashup services; secondly, when generating the graph embedding vector Z, the graph variational autoencoder is based on the explicit adjacency matrix A ex By integrating multi-hop neighbor information, the graph embedding vector Z captures both local structure and global semantics. Local structure refers to direct co-occurrence relationships in historical call records, while global semantics refers to functional associations across API nodes, such as the potential complementarity between geolocation APIs and weather services. Therefore, based on the similarity of the graph embedding vector Z, we can further filter out low-correlation direct or indirect neighbors, thereby improving the accuracy of k-hop reachable API nodes.

[0122] During the expansion process, a dynamic pruning mechanism is used to balance the exploration breadth and computational efficiency: for the initial solution set R init For each candidate API node in , the one-hop reachable API nodes whose element values ​​in the enhancement matrix are greater than the preset element threshold are retained. This can be understood as retaining the top m one-hop reachable API nodes with the highest probability weights among the one-hop reachable API nodes, while retaining the two-hop reachable API nodes that have cross-connections with at least two candidate API nodes.

[0123] More specifically, for one-hop neighbors, we directly select the top m one-hop reachable API nodes based on the edge weights, for example, Figure 5C As shown in the enhanced matrix, set m=1. Then, for API3, only the first-ranked direct neighbor API2 is retained. This direct neighbor is the selected neighbor. For two-hop neighbors, only the common nodes that have cross-connections with at least two candidate API nodes are retained, for example, Figure 5C As shown in the enhanced matrix, API3 has an indirect neighbor API0. If at this time in the initial solution set R init If there are other candidate API nodes with an indirect neighbor API0, retain the indirect neighbor API0, and this indirect neighbor is the crossover node. This allows more representative one-hop reachable and two-hop reachable API nodes to be selected. The retained direct and indirect neighbors are defined as extended nodes.

[0124] Finally, the initial solution set R init Each candidate API node and its extended nodes in the __name__ are integrated into multiple extended API nodes to construct the candidate set R candidate For example, the initial solution set R initThis includes the Payment Web API and the Logistics Web API. Further expansion may include additional nodes such as the SMS Web API, Geocoding Web API, and Inventory Web API. The clustering radius of these semantic features in the latent space verifies the semantic consistency of the topological expansion. This process, through the synergy of structural expansion and semantic filtering, significantly increases the exposure of long-tail services while suppressing the erroneous introduction of noisy nodes, providing a high-quality and diverse candidate pool for subsequent cross-modal attention sorting.

[0125] In some implementations, in step S105, generating a recommendation process for the multiple extended API nodes and the multiple candidate API nodes to obtain multiple target API nodes includes:

[0126] For each extended API node, determine the cross-modal attention weight of the extended API node, perform weighted processing and dimensionality reduction operations on multiple cross-modal attention weights to obtain the aggregated features of the extended API node, and perform multi-layer perceptron operations on the aggregated features to obtain the recommendation score of the extended API node; wherein, the cross-modal attention weight includes the attention weight of the extended API node relative to each candidate API node; according to the semantic similarity matrix, determine the recommendation scores of multiple candidate API nodes; wherein, the semantic similarity matrix is ​​used to indicate the semantic similarity between the first row vector in the semantic feature matrix and other row vectors in the semantic feature matrix associated with the API node except the first row vector; according to the recommendation scores of multiple extended API nodes and the recommendation scores of multiple candidate API nodes, obtain multiple target API nodes.

[0127] In this implementation, the candidate set R is candidate The API nodes in the CNN are assigned fine-grained weights, and the multi-dimensional information of the semantic feature matrix H and the graph embedding vector Z is integrated to finally generate a recommendation sequence that takes into account both semantic relevance and structural rationality. Specifically, first, from the initial solution set R init and the candidate set R candidate From all API nodes, the corresponding semantic feature values ​​and graph embedding vectors are extracted, and the heterogeneous semantic feature values ​​are mapped from 256 dimensions to a 128-dimensional shared space so that the semantic feature values ​​and the graph embedding vectors maintain the same dimension. For example, the product of the semantic feature value and the preset trainable parameter matrix is ​​calculated, and the sum of the product and the preset bias vector is determined as the semantic feature value after dimensionality reduction. Then, the attention weights between different modalities are calculated through the attention mechanism, and the features of the semantic component and the graph component are weightedly fused to generate a joint feature representation, which is then used to represent the candidate set R. candidate The extended API nodes in are used for scoring and sorting.

[0128] More specifically, for the candidate set R candidateEach extended API node in has the following process:

[0129] First calculate the extended API node relative to the initial solution set R init The attention weight of each candidate API node in is as shown in the following formula (14):

[0130]

[0131] In formula (14), α i′,j′ represents the attention weight between the i′th candidate API node and the j′th extended API node; Q i′ represents the query vector of the i′th candidate API node, i.e., the semantic feature value after the above dimensionality reduction; K j′ represents the key vector of the j′th extended API node, which comes from the cross-modal concatenation feature of the j′th extended API node, that is, the concatenation result of the semantic feature value after dimensionality reduction and the graph embedding vector. The concatenation result is 256 dimensions, which combines semantic and topological information; d is the preset scaling factor, which is used to prevent gradient explosion or disappearance caused by higher dimensions during the scaling dot product process; A enhanced [i′,j′] represents the comprehensive connection weight between the i′th candidate API node and the j′th extended API node, that is, in the enhanced matrix A enhanced The element value of the i′th candidate API node relative to the j′th extended API node in , which contains explicit historical call edges and virtual semantic association edges, is used to quantify the explicit collaboration strength and implicit semantic association between nodes. The purpose of taking the logarithm is to enhance the matrix A enhanced The element values ​​in are converted to logarithmic space to match the dimension of the attention score (addition instead of multiplication), while compressing the numerical range to avoid extreme values ​​dominating the Softmax result; the Softmax function converts the unnormalized attention score (containing semantic and topological information) into a probability distribution to ensure that the sum of the weights is 1, which is convenient for weighted aggregation.

[0132] Relative expansion of the API node to the initial solution set R init The attention weights of all candidate API nodes in are weighted to obtain the weighted features of the extended API node, as shown in the following formula (15):

[0133]

[0134] In formula (15), θ j′ represents the weighted features of the j′th extended API node; [H′ j′ ||Z j′] represents the cross-modal concatenation features of the j′th extended API node. Here, if the j′th extended API node is highly correlated with multiple candidate API nodes, that is, the j′th extended API node has interacted with multiple candidate API nodes during the aforementioned expansion process, then the features of the j′th extended API node will be weighted and strengthened multiple times.

[0135] The weighted features of the extended API node are compressed from 256 dimensions to 128 dimensions through a linear layer. That is, the product of the weighted features of the extended API node and the preset weight matrix is ​​calculated, and the sum of this product and the preset bias value is determined as the weighted feature after dimensionality reduction. The weighted feature after dimensionality reduction is the aggregated feature of the extended API node, which is used to adapt to the input of the multi-layer perceptron. Subsequently, the multi-layer perceptron operation is performed on the aggregated feature to obtain the recommendation score of the extended API node. The hidden layer of the multi-layer perceptron here can mine the nonlinear relationship between cross-modal features, and its output layer maps the representation of the hidden layer to the final score, reflecting the comprehensive recommendation value of the extended API node. The transformation method is shown in the following formula (16):

[0136] Score j′ =MLP(θ′ j′ )=W2·Relu(W1·θ′ j′ +b1)+b2,j′∈R candidate (16);

[0137] In formula (16), Score j′ represents the recommendation score of the j′th extended API node; θ′ j′ represents the aggregated features of the j′th extended API node; W1 and W2 are both preset weight matrices; b1 and b2 are both preset bias values.

[0138] The candidate set R can be obtained by the above method. candidate The recommendation score of each extended API node in . After that, the initial solution set R init Each candidate API node in is assigned a semantic similarity in the semantic similarity matrix as its recommendation score, as described in the following formula (17):

[0139] Score i′ =sim (0,i′) ,i′∈R init (17);

[0140] In formula (17), Score i′ represents the recommendation score of the i′th candidate API node.

[0141] Finally, the initial solution set R init and the candidate set R candidateAll API nodes are sorted in descending order to generate a final recommendation list. API nodes with recommendation scores greater than a preset threshold are selected as target API nodes. This can be understood as selecting the top M API nodes as target API nodes, thus implementing Web API recommendation operations within the Mashup service. The underlying data flow in this process fully connects the collaborative reasoning chain from semantic understanding and topology exploration to multimodal decision-making, forming a closed-loop, explainable Web API recommendation logic.

[0142] The following describes the principle of a Web API recommendation method provided by an embodiment of this application using an application scenario. Assume that the service registry includes n APIs and m historical mashup services, the maximum length of the recommendation list is 30, the number of GCN encoder layers is 2, the number of neighborhood expansion hops is 2, and the output dimension of the pre-trained SBERT model is 768. In this scenario, the process of finding a suitable Web API for the mashup service requirement from existing Web APIs is as follows:

[0143] (1) Obtain Mashup service demand text data D d , Web API describes text data D a and Mashup Design Text Data D m . At the same time, obtain call record data.

[0144] (2) Figure 2 As shown, based on the call record data, an explicit adjacency matrix A is constructed ex In the explicit adjacency matrix, both rows and columns represent API nodes, and elements represent the explicit collaboration weights between two API nodes.

[0145] (3) Figure 3A As shown, the pre-trained SBERT model is loaded and the Mashup service demand text data D is calculated in parallel. d , Web API describes text data D a and Mashup Design Text Data D m The text embedding of is used to obtain the semantic embedding matrix h. In the semantic embedding matrix, row 0 represents the current Mashup service demand node, rows 1 to n represent API nodes, rows n+1 to n+m represent historical Mashup service nodes, columns represent implicit semantic dimensions, and elements represent the intensity values ​​of text attribute data on implicit semantic dimensions.

[0146] (4) Figure 3B As shown in the figure, the semantic embedding matrix h is dimensionally compressed through a learnable projection layer, and the compressed semantic embedding matrix h′ is output to unify its dimension with the embedding space of the downstream graph neural network.

[0147] (5) Figure 3C As shown in the figure, the compressed semantic embedding matrix h′ is processed by the multi-head self-attention mechanism to obtain the semantic feature matrix H. In the semantic feature matrix H, the rows have the same meaning as the vector rows of the semantic embedding matrix h, the columns represent the implicit semantic dimensions after multi-head attention fusion, and the elements represent the semantic feature values ​​of the text samples (demands / APIs / Mashup) on the implicit semantic dimensions after multi-head attention fusion.

[0148] (6) Figure 4 As shown, the first row vector in the semantic feature matrix H is determined as the Mashup service requirement embedding, and the cosine similarity between the Mashup service requirement embedding and the entire Web API description is calculated to obtain the semantic similarity matrix S. After sorting the semantic similarity matrix S in descending order of similarity, the first K API nodes are selected as candidate API nodes to form the initial solution set R init .

[0149] (7) Figure 5A As shown, the GCN encoder is based on the semantic feature matrix H and the explicit adjacency matrix A ex Generate potential distribution parameters mean μ and log variance σ 2 , based on the reparameterization trick to sample the graph embedding vector Z.

[0150] (8) Figure 5B As shown, the inner product similarity matrix P between API node pairs is generated based on the graph embedding vector Z through the virtual edge decoder latent , and fuse it with the semantic similarity matrix S mentioned in step (6) above to obtain the virtual edge matrix P virtual In the virtual edge matrix P virtual In , both rows and columns represent API nodes, and elements represent the implicit collaboration probability between two API nodes.

[0151] (9) Figure 5C As shown, in the explicit adjacency matrix A ex Based on the enhanced matrix A containing virtual edges enhanced In the enhanced matrix A enhanced In , both rows and columns represent API nodes, and elements represent the final collaboration probability between two API nodes.

[0152] (10) By obtaining the initial solution set R init In the enhanced matrix A enhanced The k-hop neighbor nodes in the API node are used to expand the API node, and multiple extended API nodes are obtained. init Each candidate API node and its extended nodes in the __name__ are integrated into multiple extended API nodes to construct the candidate set Rcandidate . Where k∈{1,2}.

[0153] (11) From the initial solution set R init and the candidate set R candidate From all API nodes, the corresponding semantic feature values ​​and graph embedding vectors are extracted, and the heterogeneous semantic feature values ​​are mapped from 256 dimensions to a 128-dimensional shared space so that the semantic feature values ​​and graph embedding vectors maintain the same dimension.

[0154] (12) The recommendation score of each extended API node is calculated through the attention mechanism, and the recommendation score of each candidate API node is determined according to the semantic similarity matrix S mentioned in the above step (6). init and the candidate set R candidate All API nodes are sorted in descending order to generate a final recommendation list, from which the top 30 API nodes are selected as the final recommended API nodes.

[0155] In addition, an embodiment of the present application provides a Web API recommendation device, which may include:

[0156] An initialization module is used to obtain text attribute data and call record data associated with the Web API, and initialize the call record data to obtain an explicit adjacency matrix; wherein the explicit adjacency matrix is ​​used to indicate the explicit collaboration weights between API nodes;

[0157] The semantic fusion module is used to perform semantic feature modeling and candidate generation processing on the text attribute data to obtain a semantic feature matrix and multiple candidate API nodes; wherein the semantic feature matrix is ​​used to indicate the semantic feature value of the text attribute data in the implicit semantic dimension;

[0158] A graph structure extraction module is used to perform graph structure enhancement and expansion generation processing on the semantic feature matrix, the explicit adjacency matrix, and multiple candidate API nodes to obtain multiple extended API nodes;

[0159] The recommendation module is used to perform recommendation processing on multiple extended API nodes and multiple candidate API nodes to obtain multiple target API nodes.

[0160] The contents of the above method embodiments are all applicable to the present device embodiments. The functions specifically implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0161] In summary, the embodiments of the present application propose a parallel explicit representation mining framework and an implicit representation learning framework. The explicit representation mining framework can mine the actual co-occurrence relationship between Web APIs in real business scenarios only through historical call records. The implicit representation learning framework is a dual-channel framework for cross-modal dynamic alignment, which integrates the deep semantic understanding ability of the pre-trained language model and the graph structure propagation mechanism (also known as the implicit topology extension mechanism based on variational reasoning). The pre-trained language model can capture the implicit relationship between APIs from a shallow perspective, such as abstract semantic features, effectively overcome the problem of semantic ambiguity of short texts, and realize fine-grained alignment of cross-modal functional features; while the graph structure propagation mechanism captures the joint probability distribution of Web API function descriptions and historical call patterns through the GCN encoder, and generates virtual interaction edges that conform to semantic constraints through the virtual edge decoder, thereby capturing the implicit relationship between APIs from a deep perspective, alleviating the problem of insufficient coverage of long-tail Web APIs due to data sparsity in cold start scenarios. On the one hand, this allows for the mining of cross-Web API feature information in cold start scenarios without relying on historical call records. On the other hand, through explicit and implicit mining, it enriches Web API feature information, providing more Web API feature information that is more targeted to current mashup service requirements. Compared to traditional single-modal representation methods, this effectively resolves the representational offset between the general semantic space and vertical domain knowledge, and can accurately identify implicit functional connections between emerging Web APIs and innovative needs in zero-shot scenarios.

[0162] On the basis of the above, the embodiment of the present application also proposes a serial Web API preliminary screening framework and a Web API extension framework. In the Web API preliminary screening framework, the output of the pre-trained language model is used as a benchmark, and by quantifying the semantic correlation strength between the Mashup service requirements and the Web API, the Web APIs with high correlation with the Mashup service requirements are quickly screened out from the massive Web APIs to complete the preliminary screening of the Web APIs. In the Web API extension framework, the output of the graph structure propagation mechanism and the output of the Web API preliminary screening framework are used as benchmarks to explore more potential collaborative Web APIs and expand the solution space for Web API recommendations. This can provide more recommendation possibilities for Web APIs.

[0163] On the basis of the above, the embodiment of the present application also proposes to determine the final recommended Web API based on the above serial framework. The initial screening results of the Web API initial screening framework represent the semantic feature space, while the expansion results of the Web API expansion framework represent the graph topology space. By effectively integrating the distribution differences between the semantic feature space and the graph topology space and dynamically adjusting the cross-modal feature fusion weights, the final recommended Web API is generated. In this way, the Web API actually required by the Mashup service to be deployed can be accurately determined, and the adaptability of the recommended Web API to the Mashup service requirements can be improved, thereby improving the recommendation accuracy of the Web API in the Mashup service. Moreover, compared with the traditional feature splicing method, it realizes the coordinated optimization of functional semantic matching and structural compatibility in complex service combination scenarios, thereby improving the logical consistency of cross-domain service recommendations.

[0164] The following will use some experimental results to verify the effects of the embodiments of the present application.

[0165] (1) The embodiment of the present application (SEGA) is compared with other methods (CF, POP, SRMG, BGG) on the same real data set, as shown in Table 1 below. Table 1 shows the recommendation accuracy, recall rate and average accuracy of different methods on the same standard data set. It can be seen from Table 1 that the method of the embodiment of the present application has higher accuracy and compatibility.

[0166] Table 1:

[0167]

[0168] (2) The effectiveness of the embodiment of the present application (SEGA) was demonstrated by comparing different variants. Figure 6A The figure shows the top K digit accuracy (Precision@K) of different variants of the embodiment of the present application when the recommendation list length is 30. Figure 6B The figure shows the recall rate of the top K items (Recall@K) of different variants of the embodiment of the present application when the length of the recommendation list is 30. Figure 6C The figure shows the average precision of the top K items (MAP@K) of different variants of the embodiment of the present application when the length of the recommendation list is 30. SEGA-SBERT represents a variant of SEGA, which replaces the pre-trained SBERT model in SEGA with an untuned SBERT model; SEGA-GraphVAE represents another variant of SEGA, which removes the graph structure extraction module and only makes recommendations based on semantic relationships. Figures 6A to 6C It can be seen that the modules and their connection relationships in the embodiments of the present application are effective and advanced.

[0169] Although the embodiments of the present application have been shown and described, those skilled in the art will appreciate that various changes, modifications, substitutions, and variations may be made to the embodiments without departing from the principles and intent of the present application, and that the scope of the present application is defined by the claims and their equivalents.

[0170] The above is a specific description of the preferred implementation of the present application, but the present application is not limited to the embodiments. Those skilled in the art may make various equivalent modifications or substitutions without violating the spirit of the present application. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present application.

Claims

1. A Web API recommendation method, characterized in that: The following steps are involved: Get the text attribute data and call record data associated with the Web API; Initializing the call record data to obtain an explicit adjacency matrix; wherein the explicit adjacency matrix is ​​used to indicate explicit collaboration weights between API nodes; Performing semantic feature modeling and candidate generation processing on the text attribute data to obtain a semantic feature matrix and a plurality of candidate API nodes; wherein the semantic feature matrix is ​​used to indicate the semantic feature value of the text attribute data in the implicit semantic dimension; Performing graph structure enhancement and expansion generation processing on the semantic feature matrix, the explicit adjacency matrix, and the plurality of candidate API nodes to obtain a plurality of extended API nodes; Recommendation processing is performed on the multiple extended API nodes and the multiple candidate API nodes to obtain multiple target API nodes.

2. The method according to claim 1, characterized in that The initialization processing of the call record data to obtain an explicit adjacency matrix includes: Obtaining an initial adjacency matrix based on the call record data; wherein, in the initial adjacency matrix, both rows and columns represent the API nodes, and elements represent the number of explicit collaborations between two API nodes; The initial adjacency matrix is ​​logarithmically scaled and linearly compressed to obtain the explicit adjacency matrix; wherein, in the explicit adjacency matrix, both rows and columns represent the API nodes, and elements represent explicit collaboration weights between two API nodes.

3. The method according to claim 1, characterized in that The semantic feature modeling and candidate generation processing of the text attribute data to obtain a semantic feature matrix and multiple candidate API nodes includes: Performing text embedding processing on the text attribute data to obtain a semantic embedding matrix; wherein, in the semantic embedding matrix, rows represent the text attribute data, columns represent implicit semantic dimensions, and elements represent intensity values ​​of the text attribute data on the implicit semantic dimensions; Performing dimension compression on the semantic embedding matrix to obtain the compressed semantic embedding matrix; A multi-head attention operation is performed on the compressed semantic embedding matrix to obtain the semantic feature matrix; wherein, in the semantic feature matrix, the rows represent the text attribute data, the columns represent the implicit semantic dimensions, and the elements represent the semantic feature values ​​of the text attribute data on the implicit semantic dimensions.

4. The method according to claim 1, wherein The semantic feature modeling and candidate generation processing of the text attribute data to obtain a semantic feature matrix and multiple candidate API nodes includes: Obtaining semantic similarity between a first row vector in the semantic feature matrix and other row vectors in the semantic feature matrix other than the first row vector and associated with the API node; The API nodes whose semantic similarity is greater than a preset similarity threshold are determined as the candidate API nodes.

5. The method according to claim 1, wherein The graph structure enhancement and expansion generation processing is performed on the semantic feature matrix, the explicit adjacency matrix, and the plurality of candidate API nodes to obtain a plurality of extended API nodes, including: Performing graph encoding processing on the semantic feature matrix and the explicit adjacency matrix to obtain a graph embedding vector; Performing virtual edge decoding on the graph embedding vector to obtain a virtual edge matrix, and superimposing and fusing the virtual edge matrix with the explicit adjacency matrix to obtain an enhanced matrix; wherein, in the virtual edge matrix, rows and columns both represent the API nodes, and elements represent the implicit collaboration probability between two API nodes; A multi-hop graph structure expansion is performed on the plurality of candidate API nodes based on the enhancement matrix to obtain a plurality of extended API nodes.

6. The method according to claim 5, characterized in that The performing graph encoding processing on the semantic feature matrix and the explicit adjacency matrix to obtain a graph embedding vector includes: Fusing the semantic feature matrix and the explicit adjacency matrix to obtain a global service topology graph; Encoding the global service topology graph through a graph variational autoencoder to obtain a latent space mean and a latent space variance; Reparameterization is performed on the latent space mean and the latent space variance to obtain the graph embedding vector.

7. The method according to claim 5, characterized in that The virtual edge decoding process is performed on the graph embedding vector to obtain a virtual edge matrix, and the virtual edge matrix and the explicit adjacency matrix are superimposed and fused to obtain an enhanced matrix, including: Performing an inner product operation on the graph embedding vector and the transposed graph embedding vector to obtain an inner product similarity matrix; The inner product similarity matrix and the semantic similarity matrix are merged to obtain the virtual edge matrix; wherein the semantic similarity matrix is ​​used to indicate the semantic similarity between the first row vector in the semantic feature matrix and other row vectors in the semantic feature matrix associated with the API node except the first row vector; Binarizing the virtual edge matrix to obtain the binarized virtual edge matrix; The binarized virtual edge matrix is ​​superimposed on the explicit adjacency matrix to obtain the enhanced matrix.

8. The method according to claim 5, characterized in that The step of performing multi-hop graph structure expansion on the plurality of candidate API nodes based on the enhancement matrix to obtain the plurality of extended API nodes includes: For each candidate API node, determine a one-hop reachable API node and a two-hop reachable API node of the candidate API node on the enhanced matrix, retain the one-hop reachable API node whose element value in the enhanced matrix is ​​greater than a preset element threshold, retain the two-hop reachable API node that has a cross connection with at least two candidate API nodes, and determine the retained one-hop reachable API node and the retained two-hop reachable API node as extended nodes of the candidate API node; A plurality of extended API nodes are obtained according to the plurality of candidate API nodes and the plurality of extended nodes of the candidate API nodes.

9. The method according to claim 1, characterized in that The generating and recommending processing of the plurality of extended API nodes and the plurality of candidate API nodes to obtain a plurality of target API nodes includes: For each of the extended API nodes, determining a cross-modal attention weight of the extended API node, performing weighted processing and dimensionality reduction operations on multiple cross-modal attention weights to obtain an aggregated feature of the extended API node, and performing a multi-layer perceptron operation on the aggregated feature to obtain a recommendation score for the extended API node; wherein the cross-modal attention weight includes the attention weight of the extended API node relative to each of the candidate API nodes; Determining recommendation scores for the plurality of candidate API nodes according to a semantic similarity matrix; wherein the semantic similarity matrix is ​​used to indicate semantic similarities between a first row vector in the semantic feature matrix and other row vectors in the semantic feature matrix associated with the API node except the first row vector; A plurality of target API nodes are obtained according to the recommendation scores of the plurality of extended API nodes and the recommendation scores of the plurality of candidate API nodes.

10. A Web API recommendation device, characterized in that: include: An initialization module, configured to obtain text attribute data and call record data associated with the Web API, and to initialize the call record data to obtain an explicit adjacency matrix; wherein the explicit adjacency matrix is ​​used to indicate explicit collaboration weights between API nodes; A semantic fusion module is used to perform semantic feature modeling and candidate generation processing on the text attribute data to obtain a semantic feature matrix and a plurality of candidate API nodes; wherein the semantic feature matrix is ​​used to indicate the semantic feature values ​​of the text attribute data in the implicit semantic dimension; A graph structure extraction module, configured to perform graph structure enhancement and expansion generation processing on the semantic feature matrix, the explicit adjacency matrix, and the plurality of candidate API nodes to obtain a plurality of extended API nodes; The recommendation module is used to perform recommendation processing on the multiple extended API nodes and the multiple candidate API nodes to obtain multiple target API nodes.

Images