Homogeneous API recommendation method and device based on artificial intelligence, electronic equipment and storage medium

Abstract

The invention relates to a homogeneous API recommendation method and device based on artificial intelligence, electronic equipment and a storage medium. The method comprises the following steps: according to a service request submitted by a user, obtaining a homogeneous API set containing candidate APIs and corresponding to the service request; obtaining a request quantity prediction value of each candidate API according to the homogeneous API set; obtaining operation state information of each candidate API according to the homogeneous API set; obtaining a basic score of each candidate API according to the homogeneous API set, and updating the score of each candidate API based on the request quantity predicted value and the operation state information of each candidate API to obtain a latest score result list of each candidate API; and determining a target API matched with the service request and recommended to the user according to the latest scoring result list of each candidate API. According to the scheme provided by the invention, the APIs can be recommended timely, automatically and standardly, the overall resource utilization rate is improved, and meanwhile, the AI capability calling requirement of the user is met.

Description

Technical Field

[0001] This application relates to the field of API intelligent recommendation technology, and in particular to a method, apparatus, electronic device and storage medium for recommending homogeneous APIs based on artificial intelligence. Background Technology

[0002] As enterprises deepen their digital transformation, they have generally built unified AI (Artificial Intelligence) capability platforms to centrally manage AI-enabled services for internal and external customers. These AI capability platforms serve as a unified entry and exit point for business empowerment, integrating multiple functional APIs (Application Programming Interfaces) to provide intelligent support for different business scenarios. Under specific business functions, a set of functionally homogeneous but subtly differentiated AIs is also integrated to meet the customized needs of different users.

[0003] These homogeneous AIs may come from different R&D vendors, such as regional companies developing their own, group companies developing their own, or third-party vendors providing them. Due to differences in the technological R&D capabilities of different providers, the service performance of homogeneous AI capabilities in actual business scenarios also shows differentiation. When selecting homogeneous AI capabilities, it is necessary to consider the user's actual business needs, as well as the load conditions and response latency fluctuations of the AI ​​service capabilities. Many related technologies rely on operations and management personnel manually configuring rules based on experience to recommend APIs that match the AI ​​capabilities to users; however, manual configuration requires dynamic adjustments based on request volume and service nodes. The operation and strategy adjustments are difficult to implement, heavily reliant on the experience of operations and management personnel, difficult to replicate and standardize, and difficult to handle large-scale API call requests. Summary of the Invention

[0004] To address or partially address the problems existing in related technologies, this application provides a method, apparatus, electronic device, and storage medium for recommending homogeneous APIs based on artificial intelligence. This method enables timely, automatic, and standardized API recommendations, improving overall resource utilization while meeting users' needs for AI capability invocation.

[0005] The first aspect of this application provides an artificial intelligence-based method for recommending homogeneous APIs, including: Based on the business request submitted by the user, obtain a homogeneous set of candidate APIs corresponding to the business request; The predicted request volume value of each candidate API is obtained from the homogeneous API set. The running status information of each candidate API is obtained from the homogeneous API set. The basic score of each candidate API is obtained from the homogeneous API set, and the score of each candidate API is updated based on the predicted request volume and running status information of each candidate API to obtain the latest score result list of each candidate API. Based on the latest score list of each candidate API, a target API that matches the business request is recommended to the user.

[0006] In some implementations, obtaining the predicted request volume value for each of the candidate APIs from the homogeneous API set includes: The historical request volume of each candidate API in the homogeneous API set is input into the API request volume prediction model. The API request volume prediction model predicts the daily request volume of each candidate API in the homogeneous API set based on the sliding window prediction method, and obtains the request volume prediction value of each candidate API.

[0007] In some implementations, the API request volume prediction model is trained using the Stacking ensemble learning method, based on machine learning models of LightGBM, AdaBoost, and GBDT as base learners.

[0008] In some implementations, obtaining the basic score of each candidate API from the homogeneous API set includes: Each candidate API in the homogeneous API set is input into the API scoring model. The API scoring model scores each candidate API based on its API attribute features and API usage features, thereby obtaining the basic score of each candidate API in the homogeneous API set.

[0009] In some implementations, the API rating model is trained using a Logistic regression model on the API attribute features and API usage features of each API. The API attribute feature data includes the R&D manufacturer, hardware type, maximum QPS value, algorithm type, and algorithm framework; the API usage feature data includes the current QPS value, average request latency, and request success rate.

[0010] In some implementations, updating the scores of each candidate API based on the predicted request volume and runtime status information of each candidate API to obtain a latest score result list for each candidate API includes: Determine whether the predicted request volume of each candidate API has reached the preset warning value; if yes, generate warning information for the corresponding candidate API, and call the first scoring update strategy based on the warning information of the candidate API to update the score of each candidate API, and obtain the latest score result list of each candidate API. Determine whether the running status information of each candidate API is abnormal; if so, call the second scoring update strategy to update the score of each candidate API and obtain the latest score result list of each candidate API. If not, maintain the base score for each candidate API and obtain the latest score list for each candidate API.

[0011] A second aspect of this application provides an artificial intelligence-based homogeneous API recommendation system, comprising: The business processing module is used to obtain a homogeneous set of candidate APIs corresponding to the business request submitted by the user. The request volume prediction module is used to obtain the request volume prediction value of each of the candidate APIs in the homogeneous API set. The operation monitoring module is used to obtain the operation status information of each candidate API in the homogeneous API set; The scoring module is used to obtain the basic score of each candidate API in the homogeneous API set, and update the score of each candidate API based on the predicted request volume and running status information of each candidate API, so as to obtain the latest score result list of each candidate API. The recommendation module is used to determine the target API that matches the business request and recommend it to the user based on the latest rating results list of each candidate API.

[0012] A third aspect of this application provides an electronic device, comprising: Processor; and A memory that stores executable code, which, when executed by the processor, causes the processor to perform the method described above.

[0013] A fourth aspect of this application provides a computer-readable storage medium having executable code stored thereon, which, when executed by a processor of an electronic device, causes the processor to perform the method described above.

[0014] The fifth aspect of this application provides a computer program product comprising computer instructions that, when executed by a processor, implement the method described above.

[0015] The technical solution provided in this application can include the following beneficial results: It can obtain a set of homogeneous APIs containing candidate APIs corresponding to a business request submitted by a user; obtain the basic score and the predicted request volume value of each candidate API from the set of homogeneous APIs; obtain a predicted score update strategy based on the predicted request volume value of each candidate API, update the score of each candidate API, and obtain a list of the latest score results for each candidate API; determine the target API that matches the business request and recommend it to the user based on the latest score result list of each candidate API. This achieves automated, timely, and standardized API recommendation in the homogeneous API recommendation scenario, without relying on human experience, meeting the API recommendation needs of large-scale call requests, and enabling high-precision recommendation of homogeneous APIs with specific functionalities.

[0016] The technical solution of this application can also predict future API request volume and provide early warning of possible abnormal behavior; considering the current load and other usage characteristics of the API, it is convenient to adjust the API recommendation strategy in a timely and dynamic manner, and solve the problem of resource allocation imbalance caused by static recommendation.

[0017] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0018] The above and other objects, features and advantages of this application will become more apparent from the more detailed description of exemplary embodiments thereof in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments thereof.

[0019] Figure 1 This is a flowchart illustrating the AI-based API recommendation method shown in Embodiment 1 of this application; Figure 2 This is a flowchart illustrating the AI-based API recommendation method shown in Embodiment 2 of this application; Figure 3 This is a schematic diagram of the API request volume prediction model architecture shown in Embodiment 2 of this application; Figure 4 This is a schematic diagram illustrating the structure of an AI-based homogeneous API recommendation system according to an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application. Detailed Implementation

[0020] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to make this application more thorough and complete, and to fully convey the scope of this application to those skilled in the art.

[0021] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0022] It should be understood that although the terms "first," "second," "third," etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0023] Most API intelligent recommendation strategies in related technologies match user needs with broad API categories at the functional level, lacking strategies for recommending homogeneous APIs within specific functional categories. Currently, recommending homogeneous API capabilities still relies on operations managers manually configuring rules based on experience to recommend APIs matching AI capabilities to users. However, manual configuration requires dynamic adjustments based on request volume and service nodes, making operation and strategy adjustments difficult to implement, heavily reliant on the experience of operations managers, hard to replicate and standardize, and incapable of handling large-scale API call requests.

[0024] To address the aforementioned issues, this application provides an AI-based API recommendation method that effectively meets the requirements of automation, timeliness, and standardization in homogeneous API recommendation scenarios.

[0025] The technical solutions of the embodiments of this application are described in detail below with reference to the accompanying drawings.

[0026] Figure 1 This is a flowchart illustrating an AI-based API recommendation method as shown in Embodiment 1 of this application.

[0027] See Figure 1This AI-based API recommendation method includes: S110. Based on the business request submitted by the user, obtain a homogeneous set of APIs containing candidate APIs corresponding to the business request.

[0028] It's important to note that user-submitted business requests can refer to specific business scenario requests within the AI ​​capability platform. Based on the user's submitted business request, the characteristics of the request are used to obtain its corresponding candidate APIs. These candidate APIs are the corresponding AI capabilities that can satisfy the business request. For example, if the user's submitted business request is for helmet recognition, then a list of APIs containing all algorithm names or descriptions for helmet recognition algorithms can be obtained from the AI ​​capability platform. This API list represents a set of homogeneous APIs within the helmet recognition scenario, which is also the homogeneous API set including the candidate APIs.

[0029] API (Application Programming Interface) refers to a standardized interface for interaction between different software systems, defining the data transmission format, protocol, and function call method. Homogeneous APIs refer to a group of APIs that can achieve the same business function, but due to different vendors, development frameworks, and models used, they may have slight differences in usage characteristics such as accuracy, maximum QPS (Queries Per Second), and request latency.

[0030] S120. Obtain the predicted request volume of each candidate API from the homogeneous API set.

[0031] Among them, the predicted request volume of each candidate API in the homogeneous API set is output by the API request volume prediction model. It can be predicted based on the historical request volume of a certain API as input data, representing the predicted total request volume of the corresponding candidate API within a certain period of time, and serving as a reference parameter for API recommendation.

[0032] If the predicted number of API requests is too high, it may exceed the maximum QPS threshold of the API. The QPS threshold refers to the maximum allowed access frequency set by the API server, that is, the upper limit of requests that can be successfully processed per second. If this value is exceeded, the request will be rejected or delayed.

[0033] S130. Obtain the running status information of each candidate API from the homogeneous API set.

[0034] API runtime status information includes running, offline, and faulty. Abnormal runtime status, such as offline or faulty, will affect the normal invocation of the API and will be unable to meet the user's business request processing needs.

[0035] S140. Obtain the basic score of each candidate API from the homogeneous API set, and update the score of each candidate API based on the predicted request volume and running status information of each candidate API to obtain the latest score result list of each candidate API.

[0036] The basic score of each candidate API in the homogeneous API set is output by the API scoring model, representing the current status and quality level of the corresponding candidate API, and serving as a reference parameter for API recommendation. The score ranges from 0 to 100, with higher scores indicating better API status and quality.

[0037] The predicted request volume and operational status information of candidate APIs can be used together to update API scores. These scores, along with the candidate API's base score, are used to evaluate the candidate API's recommendation index. The predicted request volume and operational status information can supplement the candidate API's base score, updating it to obtain the latest score. For example, when the predicted request volume of an API exceeds its maximum QPS threshold; or when an API is offline, its base score can be updated immediately, dynamically adjusting the latest score to avoid or reduce the probability of users' requests being rejected or delayed when choosing that API, thus improving user experience.

[0038] In this embodiment, after the scores of each candidate API are updated to the latest scores, the process may further include sorting the candidate APIs in the homogeneous API set to obtain a list of the latest score results for each candidate API. The score range of the latest score results may also be 1-100 points, with higher scores representing higher API recommendation indices, serving as the basis for selecting the best API for subsequent recommendations.

[0039] S150. Based on the latest score list of each candidate API, determine the target API that matches the business request and recommend it to the user.

[0040] In this way, it can automatically recommend target APIs that match the business scenario based on the business requests submitted by users, realizing the automation of API recommendation without relying on manual configuration by operation and management personnel; moreover, it can dynamically adjust the latest scores of each candidate API in a timely manner based on the API request volume prediction results and running status information, realizing the timeliness and standardization of API recommendation, which can meet the needs of rapid recommendation of each API in large-scale business request scenarios, and avoid the impact of user experience on factors such as request latency and insufficient maximum QPS support.

[0041] Figure 2 This is a flowchart illustrating the AI-based API recommendation method shown in Embodiment 2 of this application.

[0042] See Figure 2 This AI-based API recommendation method includes: S210. Based on the business request submitted by the user, obtain a homogeneous set of APIs containing candidate APIs corresponding to the business request.

[0043] It should be noted that the business requests submitted by users can refer to specific business scenario requests within the AI ​​capability platform. Based on the business requests submitted by users, the characteristics of the business requests are obtained to identify their corresponding candidate APIs. The candidate APIs are a set of homogeneous APIs that can satisfy the AI ​​capabilities corresponding to the business requests.

[0044] In some implementations, the set of homogeneous APIs corresponding to the AI ​​capabilities of a business request may differ in terms of development vendors, frameworks, and models used, but they all achieve the same business function: the corresponding AI capability. Therefore, each candidate API in the set of homogeneous APIs obtained based on the user's submitted business request can meet the requirements of the business scenario.

[0045] S220. Input the historical request volume of each candidate API in the homogeneous API set into the API request volume prediction model. The API request volume prediction model predicts the daily request volume of each candidate API in the homogeneous API set based on the sliding window prediction method, and obtains the request volume prediction value of the candidate API.

[0046] The API request volume prediction model is based on machine learning models of LightGBM, AdaBoost, and GBDT as base learners and is trained using the Stacking ensemble learning method. Figure 3 This is a schematic diagram of the API request volume prediction model architecture shown in Embodiment 2 of this application.

[0047] Combination Figure 3 As shown, the training method for the API request volume prediction model described in this application includes: S221. Obtain training data; the training data includes the actual number of API requests.

[0048] The actual API request volume includes request volume data from day TN to day T-1 and request volume data on day T for each API. A training dataset is generated using the sliding window method. Specifically, the request volume data from day TN to day T-1 is used as the independent variable, and the request volume data on day T is used as the dependent variable to generate one training dataset. The sliding window size is N, and the step size is 1 for sampling. The second training dataset uses the request volume from day T-(N+1) to day T-2 as the independent variable and the request volume on day T-1 as the dependent variable. This process is repeated for all APIs to generate training data, thus obtaining the training data for the API request volume prediction model.

[0049] T and N can be set according to actual usage needs. For example, the current log can be set to day T and N can be set to 20. That is, the request volume of the API from the previous 20 days to the previous day can be used as the independent variable and the request volume of the current day can be used as the dependent variable to generate a training data; the request volume from the previous 21 days to the previous 2 days can be used as the independent variable and the request volume of the previous day can be used as the dependent variable to generate a second training data.

[0050] S222. Clean the training data to obtain standardized training data.

[0051] The data cleaning process mainly includes handling outliers. For example, if the request volume for a certain day is null, then that value will be filled with 0; if a row of training data contains a request volume value less than 0, then the entire row of data will be deleted.

[0052] S223. Divide the standardized training data into a training set and a test set.

[0053] The standardized training data is then split. Specifically, all standardized training data can be divided into training and test sets in a 7:3 ratio.

[0054] S224. Using LightGBM, AdaBoost, and GBDT machine learning models as base learners, the API request volume prediction model is obtained by using the Stacking ensemble learning method.

[0055] Stacking is an ensemble learning strategy, also known as stacked generalization. Its basic idea is to train multiple different base models, then use the predictions from these base models as new features to train a meta-model to synthesize these results. Different base models may capture different features and patterns in the data; stacking integrates this information to improve model performance. Different types of base and meta-models can be selected to adapt to different datasets and problems. In this embodiment, stacking integrates the outputs of LightGBM, AdaBoost, and GBDT base learners, solving the problem of unsatisfactory prediction results using a single model and improving the accuracy of API request volume predictions.

[0056] Among the base learners, LightGBM (Light Gradient Boosting Machine) is an open-source, fast, and efficient gradient boosting framework. Based on the decision tree algorithm, it has excellent capabilities for handling large-scale datasets. Employing techniques such as histogram algorithms, it significantly reduces computational cost and accelerates training; the histogram algorithm discretizes feature values, reducing memory usage; it can handle large-scale datasets and is widely used in industry; it can perform feature learning and data segmentation in parallel. AdaBoost (Adaptive Boosting) is an ensemble learning algorithm. Its core idea is to iteratively train a series of weak classifiers and then combine them into a strong classifier. In each training round, AdaBoost adjusts the sample weights based on the previous round's classification results. The weights of misclassified samples increase, while the weights of correctly classified samples decrease. This allows subsequent weak classifiers to focus more on those difficult-to-classify samples. Gbdt (Gradient Boosting Decision Tree) is also an ensemble learning algorithm. It builds a powerful predictive model by iteratively training decision trees; in each iteration, Gbdt fits the negative gradient of the previous model, which is the residual, thereby gradually reducing the model's error; it typically uses regression trees as weak learners and continuously adds new decision trees to improve the model's performance.

[0057] This application's embodiments input the historical request volumes of each candidate API in a homogeneous API set into an API request volume prediction model. The API request volume prediction model then predicts the daily request volume of each candidate API in the homogeneous API set based on a sliding window prediction method. This can be achieved by the API request volume prediction model automatically retrieving the historical request volumes of each candidate API stored in the model, or by making predictions based on re-input historical request volumes. In terms of prediction methods, the time-series data prediction problem is transformed into a machine learning fitting problem. LightGBM, AdaBoost, and GBDT models are used as base learners. The prediction results of the base learner models are input into a Stack meta-learning layer for ensemble learning and fitting, avoiding the disadvantage of poor fitting performance when selecting a single prediction model.

[0058] The above model can also use evaluation indicators MSE (mean squared error), RMSE (root mean squared error), and MAE (mean absolute error) as optimization criteria to systematically adjust the model hyperparameters and finally obtain the model with the highest prediction accuracy.

[0059] The adjustable hyperparameters of the LightGBM base learner include: ① Learning rate: controls the step size of model parameter updates in each iteration, typically between 0.01 and 0.3. Smaller values ​​make training more stable but convergence slower, while larger values ​​may lead to overfitting; ② Number of trees: the total number of trees used in training, ranging from 50 to 10,000, depending on the data size and complexity. Increasing the number usually improves performance but increases computational cost and the risk of overfitting; ③ Maximum tree depth: limits the maximum depth of each tree, ranging from 3 to 10. Larger values ​​allow the model to learn more complex patterns but are prone to overfitting, while smaller values ​​prevent overfitting; ④ Number of leaf nodes in a tree: the maximum number of leaf nodes in each tree, typically set to 2^(max_depth). Within a certain range, the complexity of the tree is controlled; too large a value can easily lead to overfitting. ⑤ Sample sampling ratio: The proportion of samples used when training each tree, ranging from 0.5 to 1.0. Decreasing this value can prevent overfitting and improve training speed. ⑥ Feature sampling ratio: The proportion of features used when training each tree, ranging from 0.5 to 1.0. This is used to reduce dimensionality and prevent overfitting. ⑦ Regularization parameters: L1 and L2 regularization coefficients, ranging from 0 to 10. Increasing these values ​​can reduce the risk of overfitting.

[0060] The adjustable hyperparameters of the Adaboost base learner are: ① Number of iterations: the number of weak classifiers trained, ranging from 50 to 100. Increasing the number usually improves performance but may lead to overfitting; ② Learning rate: the weight reduction factor for each weak classifier, ranging from 0.01 to 1.0. It has a trade-off with n_estimators, with a smaller learning rate requiring more iterations; ③ Weak classifier type: usually decision stumps (tree depth of 1) are used, but other weak classifiers can also be used. Decision stumps are used by default, and different types of base classifiers can be tried.

[0061] The adjustable hyperparameters of the GBDT base learner include: ① Learning rate: The weight reduction factor for each weak classifier, ranging from 0.01 to 0.2. Smaller values ​​make training more stable but converge slowly, while larger values ​​may lead to overfitting. ② Number of trees: The total number of trees used for training, ranging from 50 to 10,000, depending on the data size and complexity. Increasing the number usually improves performance but increases computational cost and the risk of overfitting. ③ Maximum tree depth: Limits the maximum depth of each tree, ranging from 3 to 10. Larger values ​​allow the model to learn more complex patterns but are prone to overfitting, while smaller values ​​prevent overfitting. ④ Minimum number of splits: The minimum number of samples required to split internal nodes, ranging from 2 to 20. Larger values ​​prevent overfitting. ⑤ Minimum number of leaf node samples: The minimum number of samples required for leaf nodes, ranging from 1 to 10. Larger values ​​prevent overfitting. ⑥ Subsampling ratio: The proportion of samples used when training each tree, ranging from 0.5 to 1.

[0062] Furthermore, this API request volume prediction model also includes hyperparameter tuning using GridSearchCV to obtain the optimally fitted API request volume prediction model. Specifically, this includes: ① Defining base learners and parameter grids; creating independent parameter grids for each base learner (such as AdaBoost, LightGBM, etc.), adjusting parameters such as the number of trees, learning rate, and maximum depth; ② Optimizing each base learner individually; performing cross-validation on the training data using GridSearchCV for each base learner to search for the optimal parameter combination and recording the best parameters for each base learner; ③ Generating meta-features; using the optimized base learners to predict on the training data to generate meta-features (predicted probabilities); ④ Optimizing meta-learners; defining parameter grids (such as regularization strength C, penalty term type, etc.) for meta-learners (such as logistic regression), using meta-features as input, and searching for the optimal parameters of the meta-learner using GridSearchCV.

[0063] Using the aforementioned machine learning model as a base learner and employing the Stacking ensemble learning method to construct an API request volume prediction model, historical API request volume data can be input into the model for sliding window prediction, thereby predicting future request volumes. Simultaneously, the actual daily request volume data for each API can be stored in a database as input data for the next day's sliding window prediction.

[0064] For example, the current log can be designated as day T. At 0:00 AM on each day T, the API request volume prediction model is called to predict the total request volume of each API on day T after day T ends. The input of the model uses the historical request volume data of each API. The sliding window prediction method is used to input the historical request volume data from the past T-20 to T-1 into the model for prediction, so as to obtain the predicted value of the request volume on day T.

[0065] The reference formula is as follows: Y = H ([ F adaboost ( X T-20 : X T-1 ), F gbdt ( X T-20 : X T-1 ), F lightgbm ( X T-20 : X T-1 )]); Where H is the stacking learner, F is each base learner, X is the input at each past time point, and Y is the predicted value.

[0066] It should be noted that the daily request volume mentioned in this application can be measured in units of one day, i.e., obtaining the predicted value of the API request volume for the current day; or it can be measured in units of a set time limit, such as obtaining the predicted value of the API request volume for the current day and the second day, etc. This application does not limit it in this way.

[0067] This API request volume prediction model forecasts potential abnormal behavior in the request volume of various APIs, enabling dynamic adjustments to API recommendation strategies in advance. Furthermore, this prediction method transforms the time-series data prediction problem into a machine learning fitting problem and employs ensemble learning to combine the effects of various prediction models, thus addressing the issue of unsatisfactory prediction results when using a single model.

[0068] In addition, embodiments of this application may also include periodically supplementing the training data pool with the actual request volume of each API, using it as training data to iterate the API request volume prediction model, so that the accuracy of the model prediction remains at a high level.

[0069] S230. Obtain the running status information of each candidate API from the homogeneous API set.

[0070] API runtime status information includes running, offline, and fault. Abnormal runtime status, such as offline or fault, will affect the normal invocation of the API and prevent it from meeting users' business request processing needs.

[0071] The runtime status information of each API can be retrieved periodically and stored in the database regularly to facilitate timely updates to the API's rating. For example, it can be retrieved hourly; this application does not limit this.

[0072] S240. Input each candidate API in the homogeneous API set into the API scoring model. The API scoring model scores each candidate API based on API attribute feature information and API usage feature information, and obtains the basic score of each candidate API in the homogeneous API set.

[0073] The API scoring model can automatically retrieve API attribute feature information and API usage feature information of each candidate API and score them, or it can automatically retrieve the latest score of each API in the scoring model as the base score of each candidate API among homogeneous APIs.

[0074] The API rating model can rate a set of homogeneous APIs, serving as an important basis for subsequent API recommendations. Specifically, the API rating model is trained using a Logistic regression model to gather API attribute and usage features from each API.

[0075] Specifically, the training methods for the API scoring model include: S241. Obtain training data; the training data includes API attribute feature information and API usage feature information.

[0076] API attribute characteristics include the developer, hardware type, maximum QPS value, algorithm type, and algorithm framework. The developer is the name of the company that developed the API; the hardware type includes the type of hardware on which the API is deployed; the maximum QPS value refers to the maximum number of concurrent QPS that the API can support; the algorithm type includes image algorithms, text algorithms, and whether FlashAttention is enabled; the algorithm framework includes PyTorch, TensorFlow, whether an inference acceleration framework is used, and the type of inference acceleration framework such as VLLM or Xinference.

[0077] API usage characteristics include the current QPS (Queries Per Second), average request latency, and request success rate. The current QPS is the current concurrent QPS; the average request latency is the average of the current request latencies; and the request success rate is the number of successful requests divided by the total number of requests. Because these usage characteristics, such as the API's current load, are taken into account, APIs with excessively high recommendation rates will have their ratings dynamically adjusted to lower due to high load, achieving a dynamic load balancing effect.

[0078] S242. Clean and transform the training data to obtain standardized training data.

[0079] Data cleaning mainly includes supplementing, confirming, correcting, and deleting missing, outlier, and erroneous data. For example, for missing values, methods such as deleting records containing missing values, filling in the mean or median can be chosen depending on the specific situation. For outliers, it is necessary to determine whether they are real data; if they are real data, they are included in the training dataset; if they are erroneous data, they are corrected or deleted.

[0080] The data transformation steps mainly include encoding and transforming some non-numerical variables and standardizing or normalizing some numerical variables to eliminate the influence of different dimensions between variables and improve the convergence speed and accuracy of the model. For example, the "whether to use an inference acceleration framework" can be converted into 0-1 variables (0 represents yes, 1 represents no).

[0081] S243. Divide the standardized training data into a training set and a test set.

[0082] The standardized training data is then split. Specifically, all standardized training data can be divided into training and test sets in a 7:3 ratio.

[0083] S244. The model is fitted and evaluated using a Logistic regression model to obtain the API score model.

[0084] The basic form of the logistics regression model is p = 1 / (1 + e) -z ),in: z = β0 + β1x1 + β2x2 + … + β n x n ; x here i (x1, x2…x) n ) is the processed independent variable, β i (β0, β1, β2…β) n ) represents the regression coefficient to be estimated, and p is the predicted probability value. Model hyperparameters are adjusted using evaluation metrics such as accuracy, recall, F1 score, and area under the ROC curve (AUC) to obtain the model with the best fit.

[0085] When scoring in the API scoring model, the p-value is scaled to obtain the score, which is then between 0 and 100: Score = P × 100.

[0086] In this embodiment, the API scoring model scores the performance of each candidate API in a homogeneous API set. In addition to the attribute characteristics of each API, it also considers the usage performance indicators such as API load and request latency. This not only adapts the user's business request requirements to the API type at the functional level, but also dynamically adjusts the service capabilities of homogeneous APIs under specific functional subcategories. It enables intelligent recommendation of high-concurrency multi-source APIs without requiring operation and management personnel to manually configure rules based on experience.

[0087] In addition, embodiments of this application may also include periodically supplementing the training data pool with the attribute feature data of newly generated APIs and iteratively optimized APIs, as well as the API use feature data, to iterate the API scoring model, so that the scoring accuracy output by the model remains at a high level.

[0088] S250. Update the scores of each candidate API based on the predicted request volume and running status information of each candidate API to obtain the latest score list of each candidate API.

[0089] After predicting the potential request volume using an API request volume prediction model, some early warning points can be set to facilitate the scoring update of each candidate API and obtain the latest score result for each candidate API. Specifically, it determines whether the predicted request volume value of each candidate API has reached the preset early warning value; if so, it generates early warning information for the corresponding candidate API, and calls the first scoring update strategy based on the early warning information of the candidate API to update the score of each candidate API and obtain the latest score for each candidate API.

[0090] In some implementations, it can be determined whether the predicted request volume of each candidate API is higher than the maximum QPS value of the corresponding candidate API. If so, it means that the expected request volume of the API is higher than the maximum QPS threshold, which will cause the API to be overloaded and thus its performance will degrade. In this case, the basic score of the API can be updated.

[0091] In some implementations, it can also involve checking if the predicted request volume for each candidate API is 0. If so, it means that the API is faulty. In this case, an alert can be generated, and the API's base score can be adjusted and updated based on the alert.

[0092] Specifically, assuming the maximum QPS supported by the first API in the homogeneous API set is Q, the received warning message is as follows:

[0093] Otherwise, maintain the base score of each candidate API according to the established strategy to obtain the latest score of each candidate API.

[0094] When the API runtime status information indicates that an API is abnormal, the second scoring update strategy is invoked to update the current API's score, thus obtaining the latest scores for all candidate APIs among homogeneous APIs. An abnormal API status could be due to the API being offline or experiencing a malfunction, in which case the API's corresponding score can be updated immediately, such as setting its score to 0.

[0095] Therefore, by using API request volume prediction models and API runtime status information, early warnings can be issued for potential API anomalies. This allows for timely updates to API scores, which are then sorted from highest to lowest to obtain a score result list. Based on the latest score results of candidate APIs in a homogeneous API set, target APIs that meet users' business needs and can be called promptly and effectively are recommended, improving user experience.

[0096] The latest score of each candidate API in the same API set 1 hatScore 2 hat Score 3 hat ...Get the list of scoring results Score=Max(Score 1 hat Score 2 hat Score 3 hat ...). A higher score indicates a higher API recommendation index, which serves as the basis for selecting the best API recommendation strategy in the future.

[0097] In addition to updating the basic scores of some APIs in the API scoring model based on the feedback from the API request volume prediction model that some API request volume prediction values ​​are abnormal or that some APIs are running abnormally, this application embodiment may also include periodically updating the scores of all APIs in the API scoring model in order to maintain the information of each API.

[0098] Therefore, the specific steps for updating the scores of each API may include: ① Regularly update the base scores of each API using the API scoring model; for example, update the scores of each API in the API scoring model weekly: Let the API scoring model be L, then the input variables for a certain API are X1, X2…X n Referring to the formula Score=L(X1, X2…X… n Update )×100.

[0099] ② Periodically update the score of each API in the API scoring model with the warning information corresponding to the predicted request volume output by the API request volume prediction model and stored in the database: If a warning is received from the API request volume prediction model about the QPS exceeding the limit on day T, then update the score of that API in the API scoring model at 24:00 on day T.

[0100] ③ Periodically obtain the runtime status information of each API, and update the API scoring model's score for that API based on the runtime status information: For example, information on the running status of each API can be obtained every hour. If an API is taken offline or malfunctions, its score can be updated to 0 immediately. If an alarm is received that the API's request volume is 0 on day T, the API status monitoring frequency can be increased to once every ten minutes.

[0101] For example, if a new API is launched, or an API undergoes a version iteration update, and there is a lack of usage feature data, the initial score of that API can be set to 50.

[0102] This application embodiment ensures that the API rating accuracy remains at a high level by combining the iterative update method and cycle used in API rating updates with regular and timely iterations. This reflects the latest value of the current API status and can also cope with unexpected situations such as API removal / removal and failures. The recommendation accuracy is high, and the user experience is significantly improved.

[0103] The latest score of each candidate API in the homogeneous API set represents the current status and quality level of the corresponding candidate API, serving as an important reference parameter for API recommendation. The score ranges from 0 to 100, with higher scores indicating better API status and quality.

[0104] S260. Based on the latest score list of each candidate API, determine the target API that matches the business request and recommend it to the user.

[0105] In this way, it can automatically recommend target APIs that match the business scenario based on the business requests submitted by users, thus automating API recommendation. Moreover, it takes into account the current load and running status of the APIs. APIs with excessively high recommendation rates will have their scores readjusted due to excessive load, achieving a dynamic and complex balance. This allows for dynamic adjustment of the latest scores of each candidate API, improving the timeliness and standardization of API recommendations, meeting the call requirements of recommended APIs in large-scale business request scenarios, and avoiding the impact of factors such as request latency and insufficient maximum QPS support on user experience.

[0106] Corresponding to the aforementioned application function implementation method embodiments, this application also provides an artificial intelligence-based homogeneous API recommendation system, an electronic device, and corresponding embodiments.

[0107] Figure 4 This is a schematic diagram illustrating the structure of a homogeneous API recommendation system based on artificial intelligence, as shown in an embodiment of this application.

[0108] See Figure 4 The AI-based homogeneous API recommendation system includes a business processing module 410, a request volume prediction module 420, an operation monitoring module 430, a scoring module 440, and a recommendation module 450.

[0109] The business processing module 410 is used to obtain a set of homogeneous APIs containing candidate APIs corresponding to the business request submitted by the user.

[0110] The request volume prediction module 420 is used to obtain the request volume prediction value of each candidate API in the homogeneous API set; input the historical request volume of each candidate API in the homogeneous API set into the API request volume prediction model, and the API request volume prediction model predicts the daily request volume of each candidate API in the homogeneous API set based on the sliding window prediction method to obtain the request volume prediction value of each candidate API. The API request volume prediction model is trained using the machine learning models of LightGBM, AdaBoost, and GBDT as base learners and the Stacking ensemble learning method.

[0111] The operation monitoring module 430 is used to obtain the operation status information of each candidate API in the homogeneous API set.

[0112] The scoring module 440 is used to obtain the basic score of each candidate API from the homogeneous API set, and update the score of each candidate API based on the predicted request volume and running status information of each candidate API to obtain the latest score result list of each candidate API. The API scoring model is input with each candidate API from the homogeneous API set. The API scoring model scores each candidate API based on API attribute feature information and API usage feature information to obtain the basic score of each candidate API in the homogeneous API set. The API scoring model is trained using a Logistic regression model on the API attribute feature information and API usage feature information of each API. The API attribute feature data includes the developer, hardware type, maximum QPS value, algorithm type, and algorithm framework. The API usage feature data includes the current QPS value, average request latency, and request success rate.

[0113] The scoring module 440 is also used to determine whether the predicted request volume of each candidate API has reached the preset warning value; if yes, it generates the warning information for the corresponding candidate API, and calls the first scoring update strategy to update the score of each candidate API based on the warning information of the candidate API, so as to obtain the latest score result list of each candidate API; it also determines whether the running status information of each candidate API is abnormal; if yes, it calls the second scoring update strategy to update the score of each candidate API, so as to obtain the latest score result list of each candidate API; otherwise, it maintains the basic score of each candidate API, so as to obtain the latest score result list of each candidate API.

[0114] The recommendation module 450 is used to determine the target API that matches the business request and recommend it to the user based on the latest score results list of each candidate API.

[0115] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated further here.

[0116] Figure 5 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application.

[0117] See Figure 5 The electronic device 500 includes a memory 510 and a processor 520.

[0118] The processor 520 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. Memory 510 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage devices. ROM may store static data or instructions required by the processor 520 or other modules of the computer. Permanent storage devices may be read-write storage devices. Permanent storage devices may be non-volatile storage devices that retain stored instructions and data even when the computer is powered off. In some embodiments, permanent storage devices use mass storage devices (e.g., magnetic or optical disks, flash memory) as permanent storage devices. In other embodiments, permanent storage devices may be removable storage devices (e.g., floppy disks, optical drives). System memory may be a read-write storage device or a volatile read-write storage device, such as dynamic random access memory. System memory may store some or all of the instructions and data required by the processor during operation. Furthermore, memory 510 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (e.g., DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), and disks and / or optical disks may also be used. In some embodiments, memory 510 may include a removable storage device that is readable and / or writable, such as a laser disc (CD), a read-only digital multifunction optical disc (e.g., DVD-ROM, dual-layer DVD-ROM), a read-only Blu-ray disc, an ultra-high density optical disc, a flash memory card (e.g., SD card, mini SD card, Micro-SD card, etc.), a magnetic floppy disk, etc. Computer-readable storage media do not contain carrier waves or transient electronic signals transmitted wirelessly or via wired connections.

[0119] The memory 510 stores executable code, which, when processed by the processor 520, can cause the processor 520 to execute part or all of the methods described above.

[0120] Furthermore, the method according to this application can also be implemented as a computer program or computer program product, which includes computer program code instructions for performing some or all of the steps in the method described above.

[0121] Alternatively, this application may be implemented as a computer-readable storage medium (or a non-transitory machine-readable storage medium or a machine-readable storage medium) storing executable code (or computer program or computer instruction code) that, when executed by a processor of an electronic device (or server, etc.), causes the processor to perform part or all of the steps of the methods described above according to this application.

[0122] This application also provides a computer program product, which includes computer instructions that, when executed by a processor, implement the method described above.

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

Claims

1. A homogeneous API recommendation method based on artificial intelligence, characterized in that, include: Based on the business request submitted by the user, obtain a homogeneous set of candidate APIs corresponding to the business request; The predicted request volume value of each candidate API is obtained from the homogeneous API set. The running status information of each candidate API is obtained from the homogeneous API set. The basic score of each candidate API is obtained from the homogeneous API set, and the score of each candidate API is updated based on the predicted request volume and running status information of each candidate API to obtain the latest score result list of each candidate API. Based on the latest score list of each candidate API, a target API that matches the business request is recommended to the user.

2. The recommended method according to claim 1, characterized in that, The step of obtaining the predicted request volume value for each candidate API from the homogeneous API set includes: The historical request volume of each candidate API in the homogeneous API set is input into the API request volume prediction model. The API request volume prediction model predicts the daily request volume of each candidate API in the homogeneous API set based on the sliding window prediction method, and obtains the request volume prediction value of each candidate API.

3. The recommended method according to claim 2, characterized in that, The API request volume prediction model is trained using machine learning models of LightGBM, AdaBoost, and GBDT as base learners and trained using the Stacking ensemble learning method.

4. The recommended method according to claim 1, characterized in that, The step of obtaining the basic score of each candidate API from the homogeneous API set includes: Each candidate API in the homogeneous API set is input into the API scoring model. The API scoring model scores each candidate API based on its API attribute features and API usage features, thereby obtaining the basic score of each candidate API in the homogeneous API set.

5. The recommended method according to claim 4, characterized in that, The API scoring model is trained using a Logistic regression model on the API attribute features and API usage features of each API. The API attribute feature data includes the R&D manufacturer, hardware type, maximum QPS value, algorithm type, and algorithm framework; the API usage feature data includes the current QPS value, average request latency, and request success rate.

6. The recommendation method according to claim 1, characterized in that, The process involves updating the scores of each candidate API based on its predicted request volume and runtime status information, resulting in a list of the latest score results for each candidate API, including: Determine whether the predicted request volume of each candidate API has reached the preset warning value; if yes, generate warning information for the corresponding candidate API, and call the first scoring update strategy based on the warning information of the candidate API to update the score of each candidate API, and obtain the latest score result list of each candidate API. Determine whether the running status information of each candidate API is abnormal; if so, call the second scoring update strategy to update the score of each candidate API and obtain the latest score result list of each candidate API. If not, maintain the base score for each candidate API and obtain the latest score list for each candidate API.

7. A homogeneous API recommendation system based on artificial intelligence, characterized in that, include: The business processing module is used to obtain a homogeneous set of candidate APIs corresponding to the business request submitted by the user. The request volume prediction module is used to obtain the request volume prediction value of each of the candidate APIs in the homogeneous API set. The operation monitoring module is used to obtain the operation status information of each candidate API in the homogeneous API set; The scoring module is used to obtain the basic score of each candidate API in the homogeneous API set, and update the score of each candidate API based on the predicted request volume and running status information of each candidate API, so as to obtain the latest score result list of each candidate API. The recommendation module is used to determine the target API that matches the business request and recommend it to the user based on the latest rating results list of each candidate API.

8. An electronic device, characterized in that, include: processor; as well as A memory having executable code stored thereon, which, when executed by the processor, causes the processor to perform the method as described in any one of claims 1-6.

9. A computer-readable storage medium having executable code stored thereon, which, when executed by a processor of an electronic device, causes the processor to perform the method as claimed in any one of claims 1-6.

10. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed by a processor, implement the method described in any one of claims 1-6.

Images