Code generation method and device and computer program product

Abstract

The invention provides a code generation method and device and a computer program product, relates to the technical field of software development, and can improve the accuracy of generating an SDK calling code of an API. The method comprises the following steps: acquiring a first vector obtained by converting a natural language text input by a user; determining the similarity between each second vector in the plurality of second vectors and the first vector by utilizing a preset API (Application Program Interface) retrieval model; wherein the plurality of second vectors are vector representations of features of different preset APIs respectively. And according to the similarity between the first vector and each second vector, determining N candidate APIs with higher similarity from the preset APIs. And according to the N candidate APIs and the natural language text, utilizing a preset request generation model to obtain API request information. The API request information is used for requesting the code conversion engine to generate the SDK calling code of the target API.

Description

Technical Field

[0001] This application relates to the field of software development technology, and in particular to a code generation method, apparatus and computer program product. Background Technology

[0002] APIs serve as a bridge between services and users. While reliability and availability are prerequisites for users choosing an API, the ease of use of the corresponding tools during development and debugging is even more crucial. API usability generally refers to aspects such as documentation and tool support: whether it has accurate and detailed usage instructions, abundant scenario examples, and convenient debugging methods. SDKs, on the other hand, typically come with detailed documentation and sample code, helping developers get started and use the API correctly more quickly. Therefore, to improve API usability, it's necessary to obtain SDK calling code for APIs that match the intended use cases.

[0003] However, the SDK calling code obtained through related technologies is prone to errors and has low accuracy. Summary of the Invention

[0004] This application discloses a code generation method, apparatus, and computer program product, which improves the accuracy of obtaining SDK calling code.

[0005] In a first aspect, this application provides a code generation method, comprising: obtaining a first vector obtained by converting natural language text input by a user; determining the similarity between each of a plurality of second vectors and the first vector using a preset API retrieval model; wherein the plurality of second vectors are vector representations of features of different preset APIs; determining N candidate APIs with the highest similarity from the preset APIs based on the similarity between the first vector and each of the second vectors; N being an integer greater than or equal to 1; obtaining API request information using a preset request generation model based on the N candidate APIs and the natural language text; the API request information being used to request a code conversion engine to generate SDK call code for the target API.

[0006] By determining the similarity between each of the multiple second vectors and the first vector, the second vector that best matches the natural language text is retrieved. Since the second vectors are vector representations of the features of different preset APIs, the natural language text is associated and matched with the preset APIs. Thus, by using the similarity between the first vector and each of the second vectors, N candidate APIs that better meet the user's intent and better match the natural language text are identified from the preset APIs, thereby generating more accurate API request information and, consequently, more accurate SDK call code, improving the accuracy of obtaining the SDK call code.

[0007] In one possible implementation, determining the top N candidate APIs based on the similarity between the first vector and each of the second vectors from the preset APIs includes: selecting the top M candidate APIs based on the similarity between the first vector and each of the second vectors; M is an integer greater than N; if there are at least two APIs among the M candidate APIs whose functions meet the preset similarity conditions, then the APIs that do not meet the first filtering conditions among the at least two APIs are removed from the M candidate APIs, resulting in N1 candidate APIs; N1 is an integer greater than or equal to N and less than M.

[0008] By first selecting M candidate APIs from a preset pool of APIs, the decision-making difficulty for selecting N candidate APIs is reduced, and the screening efficiency is improved. From the M candidate APIs, at least two APIs whose functions meet preset similarity criteria are prioritized. APIs that do not meet the first filtering criteria are then removed from these two pools, while those that do meet the first filtering criteria are retained. This ensures that the resulting N1 candidate APIs satisfy both the functional similarity requirement and the first filtering criteria, thus making the selected N candidate APIs more accurate.

[0009] In one possible implementation, if there are at least two APIs among the M candidate APIs whose functions meet the preset similarity conditions, then removing the APIs that do not meet the first filtering condition from the M candidate APIs includes: determining the differentiation information between the at least two APIs; if the natural language text includes association information with the differentiation information, then retaining the APIs corresponding to the association information among the at least two APIs and removing the remaining APIs; if the natural language text does not include association information with the differentiation information, then retaining the corresponding API with the highest preset priority and removing the remaining APIs.

[0010] By reasonably selecting N1 candidate APIs from at least two APIs that meet preset similar conditions, those that precisely match the natural language text or have a wider range of functions and higher API call frequency, the accuracy of the generated API request information can be improved, thereby reducing the problem feedback caused by improper API selection.

[0011] In one possible implementation, determining the top N candidate APIs based on the similarity between the first vector and each of the second vectors from the preset APIs further includes: when the M candidate APIs are sorted according to their respective similarities, determining the similarity difference between two adjacent candidate APIs in the M candidate APIs; for two candidate APIs whose similarity difference is greater than the preset difference, removing the corresponding API with the smaller similarity from the M candidate APIs to obtain N2 candidate APIs; N2 is an integer greater than or equal to N and less than M.

[0012] By setting a preset difference, two adjacent APIs with a large similarity difference are filtered to further reduce the number of candidate APIs, retain the APIs with higher similarity among two adjacent APIs, and remove the APIs with lower similarity, thereby improving the rationality of filtering candidate APIs.

[0013] In one possible implementation, determining the top N candidate APIs based on the similarity between the first vector and each of the second vectors from the preset APIs further includes: determining the number of target configuration entities corresponding to each of the M candidate APIs, where the target configuration entities corresponding to the candidate APIs are configuration entities in the preset API knowledge graph that are related to the candidate APIs and successfully matched with natural language text; selecting the top N3 candidate APIs from the M candidate APIs based on the number of their corresponding target configuration entities; where N3 is an integer greater than or equal to N and less than M; wherein, the API knowledge graph includes API entities and configuration entities corresponding to the API entities, and the configuration entities are used to represent the parameter information required when the API is called.

[0014] By selecting N3 candidate APIs from M candidate APIs, and sorting and filtering them according to the number of matching target configuration entities, the number of M candidate APIs is further reduced. This ensures that the remaining N3 candidate APIs are highly matched with the keywords corresponding to the configuration categories mentioned in the natural language text, thereby improving the accuracy of the final N candidate APIs.

[0015] In one possible implementation, obtaining the first vector from the user-input natural language text after conversion includes: if the character length of the natural language text is greater than a preset length, determining the keywords in the natural language text that correspond to preset entity categories; the preset entity categories include operation categories and resource categories; concatenating the keywords in the natural language text that correspond to the preset entity categories, and converting them into the first vector.

[0016] By pruning excessively long natural language text, the necessary information can be obtained. This information is then concatenated and converted into a first vector, improving the efficiency of subsequent retrieval.

[0017] In one possible implementation, before determining the similarity between each of the multiple second vectors and the first vector using a pre-defined API retrieval model, the process includes: identifying the target name in natural language text, where the target name is one or more of the following: API entity name, API entity alias, resource name, and resource alias included in a pre-defined API knowledge graph; determining the API corresponding to the API entity associated with the target name in the API knowledge graph as the pre-defined API; wherein, the API knowledge graph includes API entities and resource entities corresponding to the API entities; the resource entities are used to represent the objects or resources that the API entities act on.

[0018] By identifying target names in natural language text, user intent can be understood more accurately. Based on this, a preliminary screening is performed from the API knowledge graph to filter out pre-defined APIs that are more relevant to the natural language text. This improves the accuracy of pre-defined API selection and optimizes subsequent retrieval efficiency.

[0019] In one possible implementation, the API retrieval model is obtained by training an initial model using a preset sample set; the preset sample set includes multiple training samples and labels corresponding to each training sample; the training samples include a first text and a second text; the first text in a training sample includes an API entity in a preset API knowledge graph and a configuration entity corresponding to that API entity, the configuration entity being used to represent the parameter information required when the API is called; the second text is a natural language text sample; the labels corresponding to the training samples represent the similarity between the first text and the second text in the training samples.

[0020] The initial model is trained until it converges or reaches a predetermined stopping condition. In this way, the API retrieval model obtained by training the initial model using a pre-defined sample set can accurately calculate the similarity between each of the multiple second vectors and the first vector, improving the accuracy of retrieving N candidate APIs.

[0021] In one possible implementation, the entities in the API knowledge graph include API entities, operation entities, resource entities, configuration group entities, and configuration entities. API entities are used to describe APIs, resource entities are used to represent the objects or resources that the API entities act on, and operation entities are used to represent the actions performed by the API entities or operations on the target resource entities. Configuration group entities include multiple configuration entities, which are used to represent the parameter information required when the API is called. The API knowledge graph is constructed based on API multi-source heterogeneous data sources, which include multiple items in API description files, API historical call information, and API help documents.

[0022] By constructing an API knowledge graph, the relationships between entities are clarified, which improves the accuracy and efficiency of matching the natural language text input by users with the APIs, thereby increasing the accuracy and efficiency of retrieving N candidate APIs. Furthermore, since this API knowledge graph is dynamically evolving, parameters may be added, deleted, or modified as API service functions evolve (e.g., adding new APIs or updating existing ones). This allows for real-time updates to the generated SDK calling code, ensuring the generation of the required version of SDK calling code and resolving the issue of related technologies not supporting dynamic updates of SDK calling code.

[0023] In one possible implementation, before obtaining API request information based on N candidate APIs and natural language text using a preset request generation model, the process includes: for a first candidate API with more than a preset number of API parameters, matching the natural language text with a preset API knowledge graph to obtain the matching degree between the natural language text and each configuration entity in the API knowledge graph; taking the API parameters described by the configuration entities in the API knowledge graph that correspond to the first candidate API and whose matching degree with the natural language text meets the preset matching degree condition as the target parameters of the first candidate API; and taking the target parameters and required parameters of the first candidate API as the API parameters of the first candidate API, where the required parameters represent the parameters necessary for generating API request information.

[0024] By pruning the API parameters of the first candidate API, the number of parameters input to the request generation model is reduced, resulting in less irrelevant information in the N candidate APIs input to the request generation model. This reduces the possibility of errors in the output of the request generation model, making it more efficient and accurate in generating API request information.

[0025] In one possible implementation, the API parameters described by the configuration entity in the API knowledge graph that corresponds to the first candidate API and whose matching degree with the natural language text meets the preset matching degree condition are used as the target parameters of the first candidate API. This includes: using the API parameters described by the configuration entity in the API knowledge graph that corresponds to the first candidate API, whose matching degree with the natural language text meets the preset matching degree condition, and whose parameter call frequency meets the preset frequency condition as the target parameters of the first candidate API.

[0026] By increasing the parameter call frequency, the target parameters of the first candidate API are further pruned, further reducing the parameters input to the request generation model, making the request generation model generate API request information more efficiently and accurately.

[0027] In one possible implementation, the method also includes: using a code transformation engine to generate SDK call code for candidate APIs based on API request information.

[0028] By utilizing the request generation model, the conversion from natural language text to API request information was achieved, improving the accuracy, convenience, and efficiency of generating API request information.

[0029] Secondly, this application provides a code generation apparatus, comprising: a first acquisition module, configured to acquire a first vector obtained by converting natural language text input by a user; a first determination module, configured to determine the similarity between each of a plurality of second vectors and the first vector using a preset API retrieval model; wherein the plurality of second vectors are vector representations of features of different preset APIs; a second determination module, configured to determine N candidate APIs with the highest similarity from the preset APIs based on the similarity between the first vector and each of the second vectors; where N is an integer greater than or equal to 1; and a second acquisition module, configured to obtain API request information based on the N candidate APIs and the natural language text using a preset request generation model; the API request information is used to request a code conversion engine to generate SDK call code for the target API.

[0030] This device calculates the similarity between the first vector and each of the second vectors, identifies N candidate APIs from the preset APIs that better meet the user's intent and match the natural language text, thereby generating more accurate API request information and thus generating more accurate SDK call code, improving the accuracy of obtaining SDK call code.

[0031] Thirdly, this application provides a code generation apparatus, including: a processor and a memory storing program instructions, wherein the processor is configured to execute the code generation method described above when running the program instructions.

[0032] Fourthly, this application provides a computer program product, including a computer-readable storage medium storing a computer program, which, when at least one processor executes the computer program, causes at least one processor to execute the above-described code generation method. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the structure of an SDK call code generation device provided in an embodiment of this application;

[0034] Figure 2 This is a schematic diagram of another SDK call code generation device provided in an embodiment of this application;

[0035] Figure 3This is a schematic diagram illustrating the construction of a preset API knowledge graph provided in an embodiment of this application;

[0036] Figure 4 This is a schematic diagram of an API knowledge model provided in an embodiment of this application;

[0037] Figure 5 This is a flowchart illustrating a code generation method provided in an embodiment of this application;

[0038] Figure 6 This is a schematic diagram of the structure of a code generation device provided in an embodiment of this application;

[0039] Figure 7 This is a schematic diagram of another code generation device provided in an embodiment of this application. Detailed Implementation

[0040] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. "And / or" in this document is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone.

[0041] In the following description of the embodiments of this application, unless otherwise stated, "a plurality of" means two or more.

[0042] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0043] The following is a brief introduction to the relevant terms used in the embodiments of this application.

[0044] Software Development Kit (SDK) calling code: This is sample code that developers use to understand and implement specific concepts or functions. For example, SDK calling code for an API indicates how to use SDK components such as libraries and application programming interfaces (APIs) to build an application.

[0045] The following provides an exemplary description of the application scenarios of the embodiments of this application.

[0046] API usability generally refers to documentation and tool support, reflected in the availability of accurate and detailed usage instructions, abundant scenario examples, and the ability to find and display relevant content based on the developer's needs. Using the API's SDK to call the code can improve API usability.

[0047] Taking the example of a developer needing to call an API to perform a specific task, such as creating a cloud server instance or managing a database, the developer obtains the SDK calling code and uses it in their development environment to achieve more efficient API calls. When obtaining the SDK calling code, the following methods are typically used: acquiring relevant knowledge related to natural language text; where the natural language text is user input expressing the user's intent to generate the SDK calling code for the target API; relevant knowledge refers to background information, contextual information, domain knowledge, and other auxiliary information related to the natural language text, which enhances the large model's understanding of the natural language text. Then, the relevant knowledge and natural language text are input into the large model, which outputs the SDK calling code for the target API. However, the SDK calling code generated by this method is not accurate. This is because the large model may lack relevant data during training, leading to the so-called "illusion" problem. Especially when dealing with long-tail knowledge and vertical domain knowledge, the large model is prone to generating and outputting seemingly reasonable but actually incorrect results.

[0048] In view of this, embodiments of this application provide a code generation method that uses a preset API retrieval model to retrieve N candidate APIs that match natural language text. Then, based on the N candidate APIs, corresponding API request information is generated, thereby generating SDK call code corresponding to the target API. Here, the target API refers to the API that the SDK call code can call.

[0049] In some embodiments, firstly, a first vector is obtained by converting the natural language text input by the user. Secondly, using a preset API retrieval model, the similarity between each of a plurality of second vectors and the first vector is determined. The plurality of second vectors are vector representations of features of different preset APIs. Next, based on the similarity between the first vector and each of the second vectors, N candidate APIs with the highest similarity are determined from the preset APIs. N is an integer greater than or equal to 1. Finally, based on the N candidate APIs and the natural language text, an API request information is obtained using a preset request generation model. The API request information is used by the request code conversion engine to generate SDK call code for the target API.

[0050] In this embodiment, by determining the similarity between each of the multiple second vectors and the first vector, a second vector that closely matches the natural language text is retrieved. Since the second vectors are vector representations of the features of different preset APIs, the natural language text is associated and matched with the preset APIs. Thus, by using the similarity between the first vector and each of the second vectors, N candidate APIs that better meet the user's intent and better match the natural language text are determined from the preset APIs, thereby generating more accurate API request information and, consequently, more accurate SDK call code, improving the accuracy of obtaining the SDK call code.

[0051] The system architecture of the embodiments of this application will be described exemplarily below.

[0052] Combination Figure 1 and Figure 2 As shown in the figure, this application provides an SDK call code generation apparatus, which includes an API recognizer and a code conversion engine. Wherein:

[0053] The API recognizer includes a pre-defined API retrieval model and a pre-defined request generation model. The API recognizer obtains a first vector from the user-input natural language text after conversion. The API retrieval model, constructed based on a pre-defined API knowledge graph, determines the similarity between each of multiple second vectors and the first vector, where the multiple second vectors are vector representations of features of different pre-defined APIs. The API recognizer also identifies the top N candidate APIs from the pre-defined APIs based on the similarity between the first vector and each of the second vectors. N is an integer greater than or equal to 1. The request generation model generates API request information based on the N candidate APIs and the natural language text.

[0054] The code conversion engine is used to generate SDK call code for the target API based on API request information.

[0055] Optionally, the API recognizer also includes an input module. The input module is used to input natural language text from the user.

[0056] Optionally, the API recognizer also includes a text processing module. This module processes the natural language text to obtain processed natural language text. This allows for accurate capture of logical and semantic relationships within the text, better understanding of user needs or goals, and improved comprehension and accuracy of natural language text.

[0057] Optionally, the API recognizer also includes a conversion module. The conversion module is used to convert the input natural language text into a first vector. This natural language text can be processed natural language text.

[0058] Optionally, the generating device can be applied to an electronic device. This electronic device can be a mobile phone, tablet computer, handheld computer, personal computer (PC), cellular phone, personal digital assistant (PDA), wearable device (such as smartwatch, smart bracelet, etc.), smart home device (such as television), in-vehicle system (such as in-vehicle computer), smart screen, laptop computer, desktop computer, or all-in-one computer, etc. The electronic device can also be a server.

[0059] Optionally, the generation device can be integrated as a third-party plugin or service. For example, the generation device can be integrated as a function of an artificial intelligence (AI) assistant. Specifically, the generation device can be applied to an integrated development environment (IDE) code generation assistant to help generate SDK call code for cloud product APIs. In this way, the generation device can be provided to developers as an AI assistant function license, facilitating SDK development based on cloud product APIs within the IDE.

[0060] Optionally, the generation device can be integrated into the cloud vendor's online API debugging tools and API orchestration tools to assist in API debugging and orchestration. It can generate API request information based on natural language text, thereby generating accurate SDK call code, enhancing the capabilities of debugging and orchestration tools, and avoiding multiple steps for users (such as entering request information, viewing and filling in parameters, etc.).

[0061] Combination Figure 3 As shown, in some embodiments, the preset API knowledge graph is constructed as follows:

[0062] First, we construct the API knowledge model, also known as domain knowledge modeling. Domain knowledge modeling refers to knowledge modeling within a specific domain (such as API knowledge modeling within the API domain), and is also called domain ontology construction.

[0063] A knowledge graph consists of an ontology layer and an instance layer. The ontology layer of the API knowledge graph describes the knowledge system of the API domain, including defining concept classifications, attributes, and relationships between concepts. The instance layer describes entities, attributes, and relationships between entities, storing triples such as {entity, relation, entity} and {entity, attribute, attribute value}. An entity is an instantiation of a concept, and entities can inherit the attributes and relationships of a concept. For example, "tiger" is an instance of "animal".

[0064] like Figure 4 As shown, in some embodiments, an API knowledge model is constructed, including defining categories of concepts at the ontology layer, such as "API," "Operation," "Resource," "Configuration Group," and "Configuration." At the instance layer, the concepts of the above categories are instantiated: "API" corresponds to an API entity, "Operation" corresponds to an operation entity, "Resource" corresponds to a resource entity, "Configuration Group" corresponds to a configuration group entity, and "Configuration" corresponds to a configuration entity. For example, "Create Cloud Server (ECS-createservers)" is an API entity of the category "API," "Create Virtual Private Cloud (VPC-createvpc)" is another API entity of the category "API," and "Create Cloud Server (On-Demand) (ECS-createpostpaidservers)" is another API entity of the category "API." "Elastic Compute Service (ECS)" is a resource entity of the category "Resource," "Network Interface Card" is another resource entity of the category "Resource," and "Virtual Private Cloud (VPC)" is another resource entity of the category "Resource." "Create" is an operation entity within the category "Operation," "Delete" is another operation entity within the category "Operation," "Query" is another operation entity within the category "Operation," and "Add" is another operation entity within the category "Operation." "Security Group" is a configuration group entity within the category "Configuration Group," and "System" is another configuration group entity within the category "Configuration Group." "System Specification ID" is a configuration entity within the category "Configuration," and "VPC ID" is another configuration entity within the category "Configuration." For example, the triples associated with the above entities could be: {ECS-createservers, Target Resource, ECS}, {ECS-createservers, Operation Category, Create}, etc.

[0065] In some embodiments, the API knowledge graph is constructed based on a multi-source heterogeneous data source for APIs. Optionally, the multi-source heterogeneous data source for APIs comes from a pre-defined knowledge base in the API domain.

[0066] Knowledge extraction is performed on the multi-source heterogeneous data sources of APIs to obtain basic API information, the call frequency of each API, the call frequency of each API's request parameters, natural language text examples, API request information examples, and the synonym relationships between the natural language text examples and API request information examples. The multi-source heterogeneous data sources of APIs include multiple items from each API's API description file, API historical call information, and API help documentation.

[0067] Optionally, a multi-source heterogeneous knowledge extraction strategy can be adopted, using different extraction methods for different types of data sources from the API's multi-source heterogeneous data sources.

[0068] The API description file is a JSON file that conforms to the Open API specification and describes the API's data model, request and response structure, parameters, and functionality. For example, a portion of the API description file might look like this:

[0069] ...

[0070] id"436d078e47624c57b9d37365855f0df2"

[0071] name"CreateServers"

[0072] Summary of "Creating a Cloud Server"

[0073] tags "lifecycle management"

[0074] product_short"ECS"

[0075] region_id"ae-ad-1"

[0076] group_id"d611df003cfb405888cbfc77715d7c80"

[0077] ...

[0078] info_version"v2"

[0079] description null

[0080] method"post

[0081] uri null

[0082] ...

[0083] In this embodiment, basic API information can be extracted from the API description file. This basic API information includes multiple items from the following: API name (api_name), product short name (product_short), feature summary (summary), tags (tags), description (description), information version (info_version), and parameters (parameters). This basic API information is used to subsequently construct entities for the API knowledge graph.

[0084] For example, a structured extractor is used to extract basic API information from the API description file. For instance, some basic API information might look like this:

[0085] ...

[0086] api_name"CreateServers"

[0087] product_short"ECS"

[0088] Summary of "Creating a Cloud Server"

[0089] The description states "Create one or more cloud servers.\n\nThis means the interface is compatible with the 'Create Cloud Server v1' functionality in the 'Elastic Cloud Server Interface Reference', and also incorporates new features to support the creation of [annual / monthly] elastic cloud servers.\n\nElastic cloud server login authentication methods include two types: key pairs and passwords. For security reasons, the key pair method is recommended.\n\n-Key Pair\n\nThis indicates that a key pair is used as the authentication method for the elastic cloud server.\n\nInterface call method: Use the key_name field to specify the key file used for logging into the elastic cloud server.\n\n-Password\n\nThis indicates that the initial password setting method is used as the authentication method for the elastic cloud server. In this case, you can log in to the elastic cloud server using your username and password. On Linux operating systems..." This is the initial password for the root user; on Windows operating systems, it's the initial password for the Administrator user. API call method: Use the `adminPass` field to specify the initial login password for the administrator account. For Linux cloud servers with Cloud-init installed on the image, if an encrypted password is required, the `user_data` field can be used for password injection. For Linux cloud servers with the Cloud-init image installed, if the `user_data` field is specified, the `adminPass` field is invalid. Purchase operation example: - [Common problems and solutions when purchasing ECS ​​using the API] - [Obtaining a Token and verifying its validity]

[0090] tags "lifecycle management"

[0091] info_version "v2"

[0092] arguments

[0093] project_id"string: Project ID"

[0094] dry_run (boolean): Whether to preflight only this request.

[0095] server

[0096] "auto_terminate_time" string: Automatic release time for Elastic Cloud Servers

[0097] imageRef"string:System Image ID"

[0098] flavorRef"string:System Specification ID"

[0099] name"string: Cloud Server Name"

[0100] "user_data" string: User data injected during the creation of the cloud server.

[0101] adminPass"string: Initial login password for the administrator account"

[0102] key_name"string: SSH key name"

[0103] vpcid"string: The Virtual Private Cloud ID (VPC ID) to which the virtual private cloud belongs"

[0104] nics

[0105] ...

[0106] API call history information includes the call frequency of each API and the call frequency of each API's request parameters. The call frequency of each API and the call frequency of each API's request parameters are extracted from the API call history information. For example, a portion of the API call history information is as follows:

[0107] ...

[0108] {"productshort":"CCE","name":"ListNodes","region":"cn-east-3","parameter":"{\"path\":{\"project_id\":\"***\",\"c luster_id\":\"***\"},\"query\":{},\"header\":{\"X-Sdk-Content-Sha256\":\"UNSIGNED-PAYLOAD\",\"User-Agent\":\"API Explorer\",\"Host\":\"cce.cn-east-3.myhuaweicloud.com\",\"X-Language\":\"zh-cn\",\"X-Pro ject-Id\":\"***\",\"X-Sdk-Date\":\"20231018T111905Z\",\"Content-Type\":\"application / json \"},\"body\":\"\"}","info_version":"v3","is_delete":"0","is_shared":"0","status_code":"2 00","result":"1","request_remark":null,"user_id":"***","created_at":"2023-10-1811:19:05"}

[0109] ...

[0110] The API help documentation includes information such as API application examples. These examples include natural language text samples and corresponding API request information examples. Furthermore, the API help documentation allows for the extraction of synonym relationships between the natural language text samples and the API request information examples. Therefore, the natural language text samples, their corresponding API request information examples, and synonym relationships can be extracted from the API help documentation.

[0111] Specifically, based on synonym relationships, aliases of entities are added to the corresponding entities in the API knowledge graph. Natural language text examples and corresponding API request information examples are added to the corresponding entities as API request datasets. For example, from certain sections of the following API help documentation, it is possible to identify that "prepaid" and "yearly / monthly subscription" are synonyms, and the correspondence between natural language text examples and API request information examples can be determined.

[0112] ...

[0113] To purchase a yearly / monthly ECS instance, you can use the Create Elastic Cloud Service API. Compared to creating an on-demand ECS instance, you only need to specify the `extendparam.chargingMode` parameter as "prePaid" in the request body, indicating a yearly / monthly subscription and specifying the subscription period. For a detailed explanation of the `extendparam` parameters, please refer to the data structure description of the `extendparam` field when creating a cloud server.

[0114] As shown below, purchase a yearly / monthly ECS instance in the cn-north-1 region for one month. Payment and subscription will be automatic upon order placement.

[0115]

[0116] Next, entities of the API knowledge graph are constructed based on the extraction results of knowledge extraction and the API knowledge model.

[0117] In some embodiments, entities of the API knowledge graph are constructed based on the extracted API basic information, the call frequency of each API, the call frequency of each API request parameter, natural language text examples, API request information examples, and synonym relationships, as well as the API knowledge model. The entities of the API knowledge graph include API entities, operation entities, resource entities, configuration group entities, and configuration entities.

[0118] The attributes of an API entity are used to describe the API. Optionally, the attributes of an API entity include basic API information, API entity name, and API entity alias.

[0119] For example, the API entity name is obtained based on the API's basic information. Specifically, the API entity name is the product short name + API name. For example, ECS-createservers, where ECS is the product short name and createservers is the API name. In this way, the API entity name can identify a specific API and clearly associate the API with its corresponding product or service, which facilitates the management and organization of APIs and improves the orderliness of APIs in the API knowledge graph.

[0120] For example, API entity aliases are obtained based on one or more of the following: synonym relationships, a pre-defined business thesaurus, and heterogeneous data sources from multiple sources for entity recognition APIs. The pre-defined business thesaurus includes key terms in the API domain and their corresponding aliases. The heterogeneous data sources for entity recognition APIs are implemented through an entity recognition model.

[0121] Optionally, the API entity's attributes may also include API call frequency. For example, the API call frequency is obtained based on API historical call information. Specifically, the API call frequency includes the call frequency of each API in the API historical call information.

[0122] Optionally, the API entity's attributes may also include the API request dataset. For example, the API request dataset is obtained from the API help documentation. Specifically, the API request dataset includes natural language text examples and corresponding API request information examples from the API help documentation.

[0123] A resource entity is used to represent the object or resource that the API entity operates on. Optionally, the attributes of a resource entity include a resource name and a resource alias, such as {"Resource Name": "ECS", "Resource Alias": ["Cloud Server", "Elastic Cloud Server" or "elastic cloud server"]}.

[0124] For example, the resource name is obtained from the product short name in the API base information.

[0125] For example, resource aliases can be obtained through one or more of the following: synonym relationships, a pre-defined business thesaurus, and entity recognition API basic information. Specifically, a pre-defined entity recognition model is used to identify resource entities from the API basic information or the functional summary of the API basic information, thereby obtaining the resource aliases corresponding to the resource entities. For example, the functional summary in the API basic information is input into the entity recognition model, such as "Create Cloud Server". The entity recognition model outputs "Cloud Server" -> "Resource", recognizing "Cloud Server" as an alias for the resource name "ECS", and adding alias information to the corresponding resource entity.

[0126] In some embodiments, the entity recognition model includes the Bert-BiLSTM-CRF entity recognition model. The Bert-BiLSTM-CRF entity recognition model is obtained by training the original model on API domain-annotated data. The API domain-annotated data represents a dataset annotated with corresponding entities in the API domain (such as resource entities, API entities, and operation entities) to identify the corresponding entities.

[0127] An operation entity is used to represent an action performed by an API entity or an operation on a target resource entity. Optionally, the attributes of an operation entity include an operation name and an operation alias.

[0128] For example, the operation name is extracted from the API basic information. Specifically, a preset entity recognition model is used to identify the operation entity from the API basic information or the function summary of the API basic information, thereby obtaining the operation name corresponding to the operation entity. For example, the function summary in the API basic information is input into the entity recognition model, such as "Create Cloud Server", and the entity recognition model outputs {"Create" -> "Operation"}, thus obtaining the operation name as "Create".

[0129] For example, operation aliases are obtained based on synonym relationships or natural language text examples. Specifically, an entity recognition model is used to identify natural language text examples to obtain operation aliases. Operation names semantically similar to the operation aliases are determined through semantic similarity matching and / or manual review. The operation alias information is then added to the operation entity corresponding to the operation name. For example, if the natural language text example is "I want to add a cloud server," the entity recognition model identifies "add" as an operation. Through semantic similarity matching, the semantically similar operation name for "add" is "create." After confirmation, "add" is added to the operation alias list of the operation entity corresponding to the operation name "create."

[0130] A configuration group entity comprises multiple configuration entities. A configuration group includes parameter information for its sub-configuration entities. Optionally, the attributes of a configuration group entity include the configuration group name, configuration group alias, and description.

[0131] For example, the configuration group name and configuration group alias are obtained from the API basic information. The configuration group alias can also be obtained based on synonyms, where the configuration group name and configuration group alias have a semantic similarity. The description is extracted from the API description file or from the description in the API basic information. For example: {Configuration group name: server, Description: Create cloud server message body, Configuration group alias: system}.

[0132] The configuration entity is used to represent the parameter information required when the API is invoked. Optionally, the attributes of the configuration entity include parameter name, parameter alias, description, parameter type, required field, and parameter value. For example, {parameter name: project_id, parameter alias: ["Project ID"], description: "Project ID", parameter type: "String", required field: Yes, parameter value: Not applicable}; {parameter name: ipv6_enable, parameter alias: ["IPv6"], description: "Whether IPv6 is supported", parameter type: "boolean", required field: No, parameter value: Not applicable}.

[0133] For example, parameter names and descriptions are extracted from the API description file or from the parameters and descriptions in the API basic information.

[0134] For example, some information from the configuration entity in the API basic information is as follows:

[0135] “arguments”: {

[0136] "project_id": "string: Project ID",

[0137] "dry_run": "boolean: Whether to preflight only this request",

[0138] "server": {

[0139] "auto_terminate_time": "string: Automatic release time of Elastic Cloud Server"

[0140] “imageRef”: “string: System image ID”

[0141] "flavorRef": "string: System Specification ID",

[0142] "name": "string: cloud server name"

[0143] "user_data": "string: User data injected during the creation of the cloud server",

[0144] “adminPass”: “string: Initial login password for the administrator account”

[0145] "key_name": "string: SSH key name",

[0146] "vpcid": "string: Virtual Private Cloud ID, VPC ID"

[0147] “nics”: [

[0148] {

[0149] "subnet_id": "string: Subnet information, vpcid corresponds to the subnet ID under the VPC",

[0150] "id_address": "string: IP address of the network card, in IPv4 format"

[0151] "ipv6_enable": "boolean: Whether IPv6 is supported"

[0152] “ipv6_bandwidth”: {

[0153] "id: "string: The ID of the shared bandwidth to be bound."

[0154] }

[0155] }

[0156] For example, parameter aliases are obtained through synonym relationships, large model generation, or keyword extraction.

[0157] For example, parameter types include string type, boolean type, numeric type, enumeration type, or table enumeration type.

[0158] For example, numeric and enumeration type parameter values ​​are extracted from the API description file. Table enumeration type parameter values ​​are extracted from the API parameter specification webpage using a table extraction method. For instance, for table enumeration type parameters, such as the flavorRef parameter for cloud servers, the parameter value needs to be selected from multiple dimensions. For example, for the s7.xlarge.2 specification, users would typically ask for 4U8G. Synonyms for the parameter value are extracted from the table based on common expressions, such as s7.xlarge.2 <-> 4U8G, s7.large.2 <-> 2U4G, s7.small.1 <-> 1U1G, etc.

[0159] Optionally, the configuration entity's attributes may also include parameter call frequency, where the parameter call frequency indicates the frequency of API request parameters being called. For example, the parameter call frequency is obtained through API historical call information.

[0160] Finally, the knowledge extraction results are fused to obtain the final API knowledge graph.

[0161] In some embodiments, semantic-based entity alignment and / or entity fusion algorithms are used to perform knowledge fusion on the extraction results of knowledge extraction.

[0162] Optionally, a semantic-based alignment algorithm can be used to identify and match entities that are the same or similar. For example, the semantic similarity of entity descriptions can be calculated to determine whether they represent the same concept.

[0163] For example, the BGE model, fine-tuned by domain knowledge, maps the functional summaries and descriptions of API entities in a pre-defined knowledge base into word vectors, and then calculates the similarity between any two APIs (e.g., using cosine similarity). If the similarity is greater than a pre-defined similarity threshold, the two APIs are considered to be highly similar in function, and a "similar" relationship is established between them. For example, the APIs "Create Cloud Server (ECS-createservers)", "Create Cloud Server (On Demand) (ECS-createpostpaidservers)", and "Create Cloud Server (ECS-novacreateservers)" have a similarity relationship.

[0164] For example, for the similar interfaces ECS-novacreateservers, ECS-createpostpaidservers, and ECS-createservers, the bge model outputs: "ECS-novacreateservers is a native interface, used only in the command-line client (OpenStack client, OSC). Its use is not recommended. It does not support annual / monthly billing modes, does not support binding elastic public IPs during creation, and does not support bidding. ECS-createpostpaidservers is used for pay-as-you-go pricing. ECS-createservers V1.1 is compatible with the functionality of ECS-createpostpaidservers, while incorporating new features, supporting the creation of annual / monthly elastic cloud servers. Based on the scope of functionality, ECS-createservers > ECS-createpostpaidservers > ECS-novacreateservers."

[0165] In this embodiment, by constructing an API knowledge graph, the relationships between the aforementioned entities are clarified, which improves the accuracy and efficiency of subsequently matching the association between the user's input natural language text and the API, thereby improving the accuracy and efficiency of retrieving N candidate APIs. Furthermore, since this API knowledge graph is dynamically changing, parameters may be added, deleted, or modified (e.g., adding new APIs or updating existing APIs) as API service functions evolve. This allows for real-time updates of the generated SDK call code, ensuring the generation of the required version of the SDK call code and resolving the issue of related technologies not supporting dynamic updates of SDK call code.

[0166] In some embodiments, a code generation method is provided, such as Figure 5 As shown, the code generation method is applied to the aforementioned generation apparatus, and the method includes:

[0167] S501, the generating device obtains the first vector obtained by converting the natural language text input by the user.

[0168] In some embodiments, the natural language text is input by the user through the input module of the API recognizer.

[0169] In other embodiments, the natural language text is input by the user through the input module of the API recognizer, and then processed by the text processing module through intent recognition and / or preprocessing operations. Optionally, the preprocessing operations include text segmentation and / or semantic relationship recognition. In this way, the processed natural language text has better intent expression and semantic connections, thereby more accurately mapping to specific APIs and their parameters, generating more accurate API request parameters.

[0170] In some embodiments, the first vector represents a vector representation of the text in natural language text concatenated with keywords corresponding to preset entity categories. The preset entity categories include operation categories and resource categories.

[0171] In some embodiments, obtaining a first vector from user-input natural language text after conversion includes: if the character length of the natural language text is greater than a preset length, determining keywords in the natural language text that correspond to preset entity categories; concatenating the keywords in the natural language text that correspond to the preset entity categories; and converting them into a first vector.

[0172] Optionally, the preset length is greater than or equal to 80 characters. Specifically, the preset length is equal to 100 characters. By comparing the character length of the natural language text with the preset length, it is determined whether the natural language text is too long, and different conversion methods are applied to obtain the first vector.

[0173] Optionally, determining the keywords in the natural language text corresponding to the preset entity categories includes: performing named entity recognition on the natural language text to obtain the keywords in the natural language text corresponding to the preset entity categories. For example, the natural language text input to the entity recognition model is: "Call the ECS interface to create two cloud servers named newserver1, ..., bandwidth is 10M, ...". The entity recognition model outputs the entity recognition result: "Call / operate ECS / resource interface / other, create / operate two / quantity cloud servers / resources, ... cloud server / resource creation / operation ... 10M / resources, ...". In the output entity recognition result, the keywords corresponding to the operation category and resource category are: call, ECS, create, and cloud server, etc.

[0174] In this embodiment of the application, since the vector retrieval effect of long natural language text is poor, when the natural language text is too long, named entity recognition and corresponding keyword extraction are performed on the natural language text to obtain the necessary information required in the natural language text. The necessary information is then concatenated and converted into a first vector to improve the efficiency of subsequent retrieval.

[0175] In other embodiments, the first vector is a vector representation of natural language text.

[0176] In other embodiments, obtaining the first vector obtained by converting the natural language text input by the user includes: if the character length of the natural language text is less than or equal to a preset length, converting the natural language text into the first vector.

[0177] For example, the text or natural language text that is connected with keywords corresponding to preset entity categories can be converted into a first vector through techniques such as word embedding or text vectorization.

[0178] For example, the natural language text would be: "Call the ECS interface to create two cloud servers, named newserver1, billed on demand, with Ubuntu 22.0.4 operating system, 2U 4G specifications, system disk type GPSSD, size 50G, data disk type SSD, size 100G. Create an elastic public IP for the cloud server, with a bandwidth of 10M, dedicated, elastic public IP type 5_bgp, i.e., fully dynamic BGP."

[0179] S502, the generating device uses a preset API retrieval model to determine the similarity between each of the multiple second vectors and the first vector. The multiple second vectors are vector representations of features from different preset APIs.

[0180] In some embodiments, the API retrieval model is trained on an initial model using a preset sample set. The preset sample set includes multiple training samples and a label corresponding to each training sample. Each training sample includes a first text and a second text. The first text in a training sample includes an API entity from a preset API knowledge graph and its corresponding configuration entity. The second text is a natural language text sample. The label corresponding to each training sample indicates the similarity between the first and second texts in the training sample.

[0181] Optionally, in the first text, which includes an API entity from the API knowledge graph and its corresponding configuration entity, the API entity is an API entity whose API call frequency is greater than a first preset call frequency; the configuration entity corresponding to the API entity is a configuration entity whose parameter call frequency is greater than a second preset call frequency. The first and second preset call frequencies can be equal or unequal, depending on the user's actual needs.

[0182] Optionally, the second text is generated based on the first text. Specifically, the first text is input into a large model, and the large model simulates an annotator providing prompts regarding the generation of the second text corresponding to the first text, resulting in the large model outputting the second text corresponding to the first text. In this way, training samples including both the first and second texts can be obtained.

[0183] The following provides an example illustration of the first and second texts: For instance, the first text input into the large model is as follows:

[0184]

[0185]

[0186] For example, the second text output by the large model is as follows: "Call the ECS interface to create two cloud servers named newserver1, billed on demand, with the operating system being Ubuntu 22.0.4, a 2U 4G specification, a system disk type of GPSSD with a size of 50G, and a data disk type of SSD with a size of 100G. Create an elastic public IP for the cloud server with a bandwidth of 10M, dedicated, and the elastic public IP type is 5_bgp, i.e., fully dynamic BGP."

[0187] Optionally, the label corresponding to the training sample represents the similarity between the first text and the second text in the training sample, including: the label corresponding to the training sample represents the similarity between the vector representations of the first text and the vector representations of the second text in the training sample. Further, the vector representation of the first text is a vector representation of the API name and function summary in the first text.

[0188] Optionally, the initial model is trained using a preset sample set to obtain the API retrieval model, which includes: inputting a first text and a second text into the initial model; calculating the similarity between the vector representations of the second text and the first text, and outputting a current label including the similarity; adjusting the parameters of the current version of the model based on the current label and the initial label; upgrading the current version of the model after training; then inputting the first text and the second text into the upgraded retrieval model, where the first text includes a first positive text corresponding to the second text, and one or more first negative texts, where the first negative text represents a first text with high similarity to the second text but not corresponding to it; and continuing to train the upgraded retrieval model based on this, calculating the similarity between the vector representation of the second text and the vector representations of the first positive text and the first negative text, respectively, and outputting a current label including multiple similarities; adjusting the parameters of the upgraded retrieval model based on the current label and the label before the upgrade; repeating the process of adjusting the retrieval model parameters until the retrieval model converges or reaches a predetermined stopping condition, and using the latest version of the retrieval model as the API retrieval model.

[0189] In some embodiments, the initial model can be the bge model.

[0190] Optionally, the first negative text is obtained from the currently searched erroneous cases. For example, the similarity between the vector representations of the first and second texts is calculated using the retrieval model before the upgrade. First texts that are highly similar to the second text but are not its corresponding examples are searched and identified as erroneous cases. The top n erroneous cases with the highest similarity to the second text are selected as the first negative text. n is an integer greater than or equal to 1 and less than 5. Thus, the first negative text input to the upgraded retrieval model each time is the top-ranked erroneous case found by the retrieval model before the upgrade.

[0191] In this embodiment, the initial model is trained using the above-described training method until the model converges or reaches a predetermined stopping condition. Thus, the API retrieval model obtained by training the initial model using a preset sample set can accurately calculate the similarity between each of the multiple second vectors and the first vector, improving the accuracy of retrieving N candidate APIs.

[0192] In some embodiments, features are used to represent API names and feature summaries.

[0193] S503, the generating device determines the N candidate APIs with the highest similarity from the preset APIs based on the similarity between the first vector and each of the second vectors.

[0194] Optionally, N is an integer greater than or equal to 1. For example, N is an integer greater than or equal to 1 and less than or equal to 5. Specifically, N equals 1, 3, or 5. More specifically, N equals 5. In this way, by reasonably selecting N candidate APIs, accurate API request information is generated.

[0195] In some embodiments, determining the top N candidate APIs based on the similarity between the first vector and each of the second vectors from a preset set of APIs includes: selecting the top M candidate APIs based on the similarity between the first vector and each of the second vectors from the preset set of APIs. If at least two APIs among the M candidate APIs have functions that meet the preset similarity criteria, then the APIs that do not meet the first filtering criteria among the at least two APIs are removed from the M candidate APIs, resulting in N1 candidate APIs.

[0196] Optionally, M is an integer greater than N. For example, M is an integer greater than N and less than or equal to 10. Specifically, M equals 6, 8, or 10. More specifically, M equals 10.

[0197] Optionally, N1 is an integer greater than or equal to N and less than M.

[0198] Optionally, the preset similarity conditions include: the similarity is greater than a preset similarity threshold. The preset similarity threshold is greater than 0.6.

[0199] For example, determining whether two APIs meet preset similarity conditions is achieved by calculating the similarity between them using a domain-knowledge-fine-tuned bge model.

[0200] Optionally, the first filtering condition includes: if the natural language text includes correlation information between at least two APIs, it corresponds to the correlation information; if the natural language text does not include correlation information between at least two APIs, the corresponding preset priority is the highest among at least two APIs.

[0201] In this embodiment, firstly, M candidate APIs are selected from a preset pool of APIs. This reduces the decision-making difficulty and improves the screening efficiency for the subsequent selection of N candidate APIs. Secondly, among the M candidate APIs, at least two APIs whose functions meet preset similarity conditions are prioritized. APIs that do not meet the first filtering condition are then removed from these two APIs. In this way, APIs that meet the first filtering condition are retained, ensuring that the resulting N1 candidate APIs satisfy both the functional similarity requirement and the first filtering condition, thereby making the selected N candidate APIs more accurate.

[0202] In some embodiments, if at least two APIs among the M candidate APIs have functions that meet preset similarity conditions, removing the APIs that do not meet the first filtering condition from the M candidate APIs includes: determining the differentiation information between the at least two APIs. If the natural language text includes association information with the differentiation information, then the APIs corresponding to the association information among the at least two APIs are retained, and the remaining APIs are removed. If the natural language text does not include association information with the differentiation information, then the corresponding API with the highest preset priority is retained, and the remaining APIs are removed.

[0203] Optionally, based on the functional summaries, descriptions, and API call frequencies of at least two APIs, the differences between at least two APIs are summarized, and these differences are used as differential information. Related information indicates information associated with the differential information.

[0204] Differentiation information can be parameter information or parameter names, and it must be able to distinguish at least two APIs. In this way, differentiation information can be used to clearly indicate which API is more suitable for natural language text, even if at least two APIs are very similar in function. For example, there are three APIs that meet the preset similarity criteria in terms of function: ECS-createservers (create cloud servers), ECS-createpostpaidservers (create on-demand cloud servers), and ECS-createprepaidservers (create prepaid cloud servers). These three APIs are similar in function, all creating cloud servers, but they differ in their billing models. Therefore, the differentiation information for these three APIs is the billing model. Based on this, the following example illustrates whether or not the natural language text includes information related to the differentiated information: For instance, if the natural language text includes information corresponding to billing model parameters such as "pay-as-you-go" or "annual / monthly subscription," then it is determined that the natural language text includes information related to the billing model. In this case, the API corresponding to the billing model information is selected from the three APIs mentioned above. For example, if the natural language text is "create a pay-as-you-go cloud server," then ECS-createpostpaidservers is selected as the candidate API because it matches the related information in the natural language text. If the natural language text does not mention information related to the billing model parameters, then it is determined that the natural language text does not include information related to the billing model. In this case, instead of continuing to filter M candidate APIs based on the differentiated information, the filtering continues based on the corresponding preset priority.

[0205] In some embodiments, the preset priority is determined based on the scope of the functionality covered and the frequency of API calls. For example, the larger the scope of the API's functionality and the higher the frequency of API calls, the higher the priority of the API is determined. In this way, the priority order among multiple APIs can be determined.

[0206] In other embodiments, the preset priority is determined based on the construction order when building the API knowledge graph. For example, as... Figure 4 As shown, ECS-createservers and ECS-createpostpaidservers are two APIs that meet the preset similarity conditions. If ECS-createservers is built first, then the priority of ECS-createservers is higher than the priority of ECS-createpostpaidservers.

[0207] In this embodiment of the application, among at least two APIs that meet the preset similarity conditions, N1 candidate APIs that are precisely matched with the natural language text, or have a wider range of functions and higher API call frequency are reasonably selected. These APIs are more in line with the intent or needs of the natural language text, thereby improving the accuracy of the generated API request information and reducing the problem feedback caused by improper API selection.

[0208] In some embodiments, determining the top N candidate APIs based on the similarity between the first vector and each of the second vectors further includes: if the M candidate APIs are sorted according to their respective similarities, determining the similarity difference between two adjacent candidate APIs among the M candidate APIs. For two candidate APIs whose similarity difference is greater than a preset difference, the corresponding API with the smaller similarity is removed from the M candidate APIs, resulting in N² candidate APIs.

[0209] Optionally, N2 is an integer greater than or equal to N and less than M.

[0210] Optionally, the preset difference is greater than or equal to 0.05 and less than or equal to 0.15. Specifically, the preset difference is equal to 0.05, 0.1, or 0.15. More specifically, the preset difference is equal to 0.1.

[0211] For example, two candidate APIs that are adjacent in order among M candidate APIs are labeled as topN-1 and topN, respectively. If the similarity of topN-1 is 0.1 greater than that of topN, then only the candidate API corresponding to topN-1 is selected. That is, the API with higher similarity is retained, and the API with lower similarity is removed from the M candidate APIs.

[0212] In this embodiment of the application, by setting a preset difference (such as 0.1), two adjacent APIs with large similarity differences are filtered to further reduce the number of candidate APIs, retain the APIs with higher similarity among two adjacent APIs, and remove the APIs with lower similarity, thereby improving the rationality of filtering candidate APIs.

[0213] In some embodiments, determining the top N candidate APIs from a preset pool of APIs based on the similarity between the first vector and each of the second vectors further includes: determining the number of target configuration entities corresponding to each of the M candidate APIs, where the target configuration entities corresponding to the candidate APIs are configuration entities in a preset API knowledge graph that are related to the candidate APIs and successfully matched with natural language text. The top N3 candidate APIs are selected from the M candidate APIs based on the number of their corresponding target configuration entities. The API knowledge graph includes API entities and the configuration entities corresponding to those API entities.

[0214] Optionally, N3 is an integer greater than or equal to N and less than M.

[0215] Optionally, the target configuration entity corresponding to the candidate API is determined as follows: The configuration entities in the API knowledge graph are matched with natural language text to obtain the configuration entities that successfully match the natural language text. Candidate APIs that are related to the configuration entities that successfully match the natural language text are identified. The configuration entities in the API knowledge graph that are related to the candidate APIs and successfully match the natural language text are taken as the target configuration entities corresponding to the candidate APIs.

[0216] For example, matching configuration entities in an API knowledge graph with natural language text includes: performing named entity recognition on the natural language text to obtain keywords corresponding to configuration categories in the natural language text; and matching the keywords corresponding to configuration categories with configuration entities in the API knowledge graph. Specifically, matching the keywords corresponding to configuration categories with parameter names and parameter aliases in the configuration entities of the API knowledge graph.

[0217] Specifically, named entity recognition of natural language text includes using an entity recognition model to perform named entity recognition on the natural language text. For example, inputting the natural language text into the entity recognition model might be: "Call the ECS interface to create two cloud servers, named newserver1, billed on demand, with Ubuntu 22.0.4 operating system, 2U 4G specifications, system disk type GPSSD, size 50G, data disk type SSD, size 100G. Create an elastic public IP address for the cloud server, with a bandwidth of 10M, dedicated, and elastic public IP type 5_bgp, i.e., fully dynamic BGP." The entity recognition model outputs the following entity recognition result: "Calling / operating on ECS / resource interface / other, creating / operating on two / quantity cloud servers / resources, name / parameter name is / equal newserver1 / parameter value, on-demand billing / parameter value, operating system / parameter is / equal Ubuntu22.0.4 / parameter value, specifications / parameter is / equal 2U4G / parameter value, system disk type / parameter is / equal GPSSD / parameter value, size / parameter is / equal 50G / parameter value, data disk type / parameter is / equal SSD / parameter value, size / parameter is / equal 100G / parameter value. Creating / operating on one / quantity elastic public IP / parameter for / other cloud server / resources, bandwidth / parameter is / equal 10M / resource, dedicated / parameter value, elastic public IP type / parameter is / equal 5bgp / parameter value, i.e. / other fully dynamic BGP / parameter value." In the output entity recognition results, the keywords corresponding to the configuration categories are name, equal newserver1, on-demand billing, and operating system, etc.

[0218] The following example illustrates the selection of N3 candidate APIs from M candidate APIs, ranked by the number of corresponding target configuration entities: When M equals 6, the 6 candidate APIs are labeled M1, M2, M3, M4, M5, and M6, with 8, 5, 2, 7, 6, and 3 configuration entities matching the natural language text, respectively. The 6 candidate APIs are then reordered based on these matching counts, resulting in M1, M4, M5, M2, M6, and M3. When N3 equals 3, 3 candidate APIs are selected from the reordered list, namely the top 3 ranked candidate APIs, M1, M4, and M5, while M2, M3, and M6 are removed.

[0219] In this embodiment of the application, N3 candidate APIs are selected from M candidate APIs in the above manner. They are sorted and filtered according to the number of matching target configuration entities, which further reduces the number of M candidate APIs. This makes the N3 candidate APIs that are retained highly matched with the keywords corresponding to the configuration categories mentioned in the natural language text, thereby improving the accuracy of the N candidate APIs that are finally selected.

[0220] In some embodiments, the three filtering methods of obtaining N1 candidate APIs, obtaining N2 candidate APIs, and obtaining N3 candidate APIs can be one or more of the following.

[0221] In other embodiments, N1 candidate APIs, N2 candidate APIs, and N3 candidate APIs are obtained. These three filtering methods have different priorities, and the corresponding filtering methods are used in descending order of priority.

[0222] For example, the priority order of the three filtering methods, from highest to lowest, is as follows: obtaining N1 candidate APIs, obtaining N2 candidate APIs, and obtaining N3 candidate APIs. The following example illustrates how to determine the top N candidate APIs with the highest similarity from a preset pool of APIs, given this priority order: First, the filtering method corresponding to obtaining N1 candidate APIs is used to filter N1 candidate APIs from M candidate APIs. If N1 is greater than N, the filtering method corresponding to obtaining N2 candidate APIs is used to obtain N2 candidate APIs from the N1 candidate APIs. If N2 is greater than N, the filtering method corresponding to obtaining N3 candidate APIs is used to obtain N3 candidate APIs from the N2 candidate APIs, and so on, until N3 equals N.

[0223] In this embodiment, N candidate APIs are obtained through different filtering methods, which can be applied to different filtering scenarios. For example, in scenarios where natural language text explicitly indicates association with differentiated information, or when the similarity difference between two adjacent candidate APIs is greater than a preset difference. Through the above multi-level filtering strategy, N candidate APIs that meet user needs can be filtered more accurately, improving the accuracy and efficiency of selecting N candidate APIs.

[0224] S504, the generation device obtains API request information based on N candidate APIs and natural language text using a preset request generation model. The API request information is used by the request code conversion engine to generate SDK call code for the target API.

[0225] In some embodiments, obtaining API request information based on N candidate APIs and natural language text using a preset request generation model includes: inputting the information of the N candidate APIs and natural language text into the request generation model to obtain the API request information output by the request generation model.

[0226] Optionally, the API information includes the API name, product short name, feature summary, description, and API parameters. API parameters are used to indicate the parameters required when the API is invoked.

[0227] For example, the request generation model is a large model. This large model is used to generate API request information from the input N candidate APIs and natural language text. For instance, the API request information output by the request generation model might be: "By understanding the information of the candidate APIs, CreatePostPaidServers can fulfill your needs. The API parameters are: \n```json\n{\"api_name\":\"CreatePostPaidServers\",\"product_short\":\"ECS\",\"arguments\":{}}\n```\n"

[0228] In this embodiment, the request generation model is used to convert natural language text into API request information, thereby improving the accuracy, convenience and efficiency of generating API request information.

[0229] In some embodiments, before determining the similarity between each of the multiple second vectors and the first vector using a preset API retrieval model, the method further includes: identifying a target name in natural language text, wherein the target name is one or more of the following included in a preset API knowledge graph: API entity name, API entity alias, resource name, and resource alias. The API corresponding to the API entity associated with the target name in the API knowledge graph is determined as the preset API. The API knowledge graph includes API entities and the resource entities corresponding to the API entities.

[0230] Optionally, identifying target names in natural language text includes: using a pre-defined AC (Aho-Corasick) automaton to identify target names in natural language text.

[0231] For example, the AC automaton is constructed using resource names, resource aliases, API entity names, and API entity aliases from the API knowledge graph. Thus, when using the AC automaton to recognize natural language text, it can identify target names in the natural language text that are related to the resource names, resource aliases, API entity names, and API entity aliases in the API knowledge graph. For instance, using the AC automaton, target names identified in natural language text include: ECS, cloud server, and ECS-createservers. Preset APIs might be ECS-createservers (create cloud servers), ECS-createpostpaidservers (create on-demand cloud servers), ECS-createprepaidservers (create prepaid cloud servers), and so on.

[0232] In this embodiment, by identifying target names in natural language text, user intent is understood more accurately. Based on this, a preliminary screening is performed from the API knowledge graph to filter out preset APIs that are more relevant to the natural language text. Furthermore, since the AC automaton is an efficient data structure that can quickly identify multiple keywords in text, by constructing an AC automaton that includes resource names, resource aliases, API entity names, and API entity aliases, target names in natural language text related to the API knowledge graph can be quickly identified. This reduces unnecessary computational steps, improves the accuracy of preset API selection, and optimizes subsequent retrieval efficiency.

[0233] In some embodiments, before obtaining API request information based on N candidate APIs and natural language text using a preset request generation model, the process further includes: for a first candidate API with more than a preset number of API parameters, matching the natural language text with a preset API knowledge graph to obtain the matching degree between the natural language text and each configuration entity in the API knowledge graph. The API parameters described by the configuration entities in the API knowledge graph that correspond to the first candidate API and whose matching degree with the natural language text meets a preset matching degree condition are used as the target parameters of the first candidate API. The target parameters and required parameters of the first candidate API are used as the API parameters of the first candidate API. Required parameters represent parameters necessary for generating API request information.

[0234] The first candidate API is used to indicate the API among N candidate APIs whose number of API parameters is greater than a preset number.

[0235] Optionally, the preset quantity is an integer greater than or equal to 10. Specifically, the preset quantity is equal to 10.

[0236] The following is an example of matching natural language text with a pre-defined API knowledge graph to obtain the matching degree between the natural language text and each configuration entity in the API knowledge graph: Named entity recognition is performed on the natural language text to obtain the keywords corresponding to the configuration categories in the natural language text. The keywords corresponding to the configuration categories are then matched with each configuration entity in the API knowledge graph to obtain the matching degree of each configuration entity.

[0237] Optionally, the preset matching degree condition includes: a matching degree greater than or equal to a preset matching degree, and the matching degree corresponding to the top m matching degrees in the matching degree ranking. For example, the preset matching degree is greater than or equal to 0.6. For example, m is an integer less than or equal to 3. For instance, if the matching degree between the configuration entity and the natural language text is greater than 0.6 (such as 0.9, 0.8, 0.78, 0.66, or 0.65), and it is one of the top 3 matching degrees in the matching degree ranking, then it is determined that the matching degree between the configuration entity and the natural language text meets the preset matching degree condition.

[0238] For example, the matching degree can be a similarity degree, which can be calculated using methods such as cosine similarity or Jaccard similarity.

[0239] The following example illustrates how API parameters described by configuration entities in the API knowledge graph that correspond to the first candidate API and whose matching degree with natural language text meets the preset matching degree conditions can be used as target parameters of the first candidate API: For example, when m equals 3, the matching degrees of multiple configuration entities are 0.9, 0.8, 0.78, 0.66, 0.65, 0.54 and 0.4, respectively. Among them, the configuration entities corresponding to matching degrees of 0.9, 0.8, 0.78 and 0.4 correspond to the first candidate API. Then, the target parameters of the first candidate API are the API parameters described in the configuration entities with matching degrees of 0.9, 0.8 and 0.78.

[0240] Optionally, the sum of the number of required parameters and the target parameters is less than 10.

[0241] Optionally, the number of target parameters is less than or equal to 3.

[0242] In this embodiment, the number of API parameters for the first candidate API exceeds a preset number, indicating that the first candidate API has a large number of parameters that can be filled in. If all the API parameters of the first candidate API are input into the request generation model, on the one hand, the request generation model may have a short input window and be unable to recognize all APIs; on the other hand, the longer the input characters, the longer the calculation time of the request generation model, and the more irrelevant information is input into the request generation model, the more likely the request generation model is to output errors. In addition, from the perspective of the natural language text input by the user, it usually only involves a small number of parameters. Therefore, before inputting the information of N candidate APIs into the request generation model, it is necessary to prune the API parameters of the first candidate API to reduce the parameters input into the request generation model, so that the request generation model can generate API request information more efficiently and accurately.

[0243] In some embodiments, using API parameters described by configuration entities in the API knowledge graph that correspond to the first candidate API and whose matching degree with natural language text meets a preset matching degree condition as target parameters of the first candidate API includes: using API parameters described by configuration entities in the API knowledge graph that correspond to the first candidate API, whose matching degree with natural language text meets a preset matching degree condition, and whose parameter call frequency meets a preset frequency condition as target parameters of the first candidate API.

[0244] Optionally, the preset frequency conditions are determined based on the user's actual needs and the parameter call frequency data in the API historical call information.

[0245] The following example illustrates how API parameters described by configuration entities in the API knowledge graph that correspond to the first candidate API, meet preset matching degree conditions with natural language text, and whose parameter call frequency meets preset frequency conditions are used as target parameters for the first candidate API. For instance, if a parameter call frequency greater than 20 times meets the preset frequency condition, with m equal to 3, the matching degrees of multiple configuration entities are 0.9, 0.8, 0.78, 0.66, 0.65, 0.54, and 0.4, and the corresponding parameter call frequencies are 20, 40, 30, 60, 80, 10, and 15, respectively. The configuration entities with matching degrees of 0.9, 0.8, 0.78, and 0.4 correspond to the first candidate API, so the target parameters of the first candidate API are the API parameters described in the configuration entities with matching degrees of 0.8 and 0.78.

[0246] In this embodiment, the target parameters of the first candidate API are further pruned. By increasing the parameter call frequency, the parameters input to the request generation model are further reduced, making the request generation model generate API request information more efficiently and accurately.

[0247] In some embodiments, after obtaining the API request information, the method further includes: the generating device correcting the API request information. Because some APIs with complex parameter types or deep nesting may produce errors when generating API request information, correcting the API request information generates more accurate SDK call code for the target API.

[0248] Optionally, correcting API request information includes: determining the error type of the API request information; and correcting the API request information based on the error type.

[0249] For example, error types in API request information include one or more of the following: enumeration value recognition error, parameter hierarchy recognition error, numerical parameter unit conversion error, and minor parameter name error. Before generating API request information, the request generation model needs to recognize the input N candidate APIs and natural language text to obtain the recognition results, and then generate API request information based on these results. These recognition results are prone to the above-mentioned types of errors, leading to errors in the generated API request information. Examples of each error type are given below: "Enumeration value recognition error: During recognition, 'flavorRef' is recognized as '1U1G,' but the standard parameter corresponding to the interface is 's2.smaill.1,' creating a gap between the user description and the standard parameter value." "Parameter hierarchy recognition error: The 'iptype' parameter is below the 'eip' hierarchy, but during recognition, it is recognized as being below the 'bandwidth' hierarchy." "Numerical parameter unit conversion: 'size' requires unit extraction and calculation for unit conversion due to different units, but this conversion was not performed during recognition." "Minor parameter name error: The parameter 'sharetype' is recognized as 'share_type.'"

[0250] For example, correcting API request information for incorrect enumeration value identification includes: determining whether the enumeration value in the identification result of the request generation model is within the range of standard enumeration values. If it is not within the range of standard enumeration values, then it is determined whether there is a standard enumeration value that is synonymous with the enumeration value in the identification result; if so, then a standard enumeration value that is synonymous with the enumeration value is determined based on the synonymy relationship, and the enumeration value in the identification result is replaced with that standard enumeration value. If not, then the semantic similarity between the enumeration value in the identification result and each standard enumeration value is calculated, and the enumeration value in the identification result is replaced with the standard enumeration value with the highest similarity.

[0251] For example, correcting API request information with incorrect parameter hierarchy identification includes: correcting the parameter hierarchy structure by examining the parameter paths. Specifically, it compares whether the parameter hierarchy in the identification result of the request generation model is consistent with the parameter hierarchy in the API knowledge graph. If they are inconsistent, the parameter hierarchy in the identification result of the request generation model is modified according to the annotation hierarchy of the API knowledge graph. The parameter hierarchy represents the structural level of the parameters.

[0252] For example, error correction for API request information involving unit conversion of numerical parameters includes: for numerical parameters with units, determining whether the units mentioned in the natural language text are consistent with the API knowledge graph. If they are inconsistent, using a unit conversion tool to convert and calculate the units mentioned in the natural language text so that the units mentioned in the natural language text are consistent with the API knowledge graph.

[0253] For example, correcting minor errors in API request information regarding parameter names includes correcting erroneous parameter names using edit distance. Specifically, the parameter names in the recognition results of the request generation model are matched with the standard parameter names of the corresponding API in the API knowledge graph. If a match is found, the closest parameter name is replaced based on the edit distance.

[0254] In some embodiments, the method further includes: the generation device using a code conversion engine to generate SDK call code for the target API based on API request information. For example, the code conversion engine may be an officially provided code conversion engine, and the SDK code output by the code conversion engine is consistent with the SDK on the official API portal website, and clicking on the API will redirect to the official API portal website.

[0255] For example, the API request information input into the code conversion engine is: API request: {"api_name":"CreatePostPaidServers","product_short":"ECS","arguments":{}}; Programming language: java.

[0256] The SDK calling code output by the code conversion engine is as follows:

[0257] package com.huaweicloud.sdk.test;

[0258] import com.huaweicloud.sdk.core.auth.ICredential;

[0259] import com.huaweicloud.sdk.core.auth.BasicCredentials;

[0260] import com.huaweicloud.sdk.core.exception.ConnectionException;

[0261] import com.huaweicloud.sdk.core.exception.RequestTimeoutException;

[0262] import com.huaweicloud.sdk.core.exception.ServiceResponseException;

[0263] import com.huaweicloud.sdk.ecs.v2.region.EcsRegion;

[0264] import com.huaweicloud.sdk.ecs.v2.*;

[0265] import com.huaweicloud.sdk.ecs.v2.model.*;

[0266] public class CreatePostPaidServersSolution{

[0267] public static void main(String[]args){

[0268] / / The AK and SK used for authentication are hard-coded or stored inplaintext,which has great security risks.It is recommended that the AK and SKbe stored in ciphertext in configuration files or environment variables anddecrypted during use to ensure security.

[0269] / / In this example,AK and SK are stored in environment variables forauthentication.Before running this example,set environment variables CLOUD_SDK_AK and CLOUD_SDK_SK in the local environment

[0270] String ak=System.getenv("CLOUD_SDK_AK");

[0271] String sk=System.getenv("CLOUD_SDK_SK");

[0272] ICredential auth=new BasicCredentials()

[0273] .withAk(ak)

[0274] .withSk(sk);

[0275] EcsClient client=EcsClient.newBuilder()

[0276] .withCredential(auth)

[0277] .withRegion(EcsRegion.valueOf("cn-north-4"))

[0278] .build();

[0279] CreatePostPaidServersRequest request=newCreatePostPaidServersRequest();

[0280] CreatePostPaidServersRequestBody body=new CreatePostPaidServersRequestBody();

[0281] request.withBody(body);

[0282] try{

[0283] CreatePostPaidServersResponse response=client.createPostPaidServers(request);

[0284] System.out.println(response.toString());

[0285] }catch(ConnectionException e){

[0286] e.printStackTrace();

[0287] }catch(RequestTimeoutException e){

[0288] e.printStackTrace();

[0289] }catch(ServiceResponseException e){

[0290] e.printStackTrace();

[0291] System.out.println(e.getHttpStatusCode());

[0292] System.out.println(e.getRequestId());

[0293] System.out.println(e.getErrorCode());

[0294] System.out.println(e.getErrorMsg());

[0295] }

[0296] }

[0297] }

[0298] In this embodiment of the application, the API request information is converted into the corresponding SDK call code by a code conversion engine. This is efficient and accurate, and the generated SDK call code is consistent with the official website, ensuring that the code is correct and verifiable.

[0299] like Figure 6As shown in the figure, this application embodiment provides a code generation device 200, which includes: a first acquisition module 21, a first determination module 22, a second determination module 23, and a second acquisition module 24. The first acquisition module 21 is used to acquire a first vector obtained by converting natural language text input by a user. The first determination module 22 is used to determine the similarity between each of a plurality of second vectors and the first vector using a preset API retrieval model; wherein the plurality of second vectors are vector representations of features of different preset APIs. The second determination module 23 is used to determine N candidate APIs with the highest similarity from the preset APIs based on the similarity between the first vector and each of the second vectors; N is an integer greater than or equal to 1. The second acquisition module 24 is used to obtain API request information based on the N candidate APIs and the natural language text using a preset request generation model; the API request information is used to request the code conversion engine to generate SDK call code for the target API.

[0300] like Figure 7 As shown, this application embodiment provides another code generation apparatus 500. The code generation apparatus 500 includes a processor 510 and a memory 520 storing program instructions. The processor 510 is configured to execute the code generation method described above when running the program instructions.

[0301] The code generation device 500 is manifested in the form of a general-purpose computing device. The components of the code generation device 500 may include, but are not limited to: one or more processors 510, memory 520, communication bus 540 connecting different system components (including memory 520 and processor 510), and communication interface 530.

[0302] The communication bus 540 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. Examples of these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0303] The code generation device 500 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by electronic devices, including volatile and non-volatile media, and removable and non-removable media.

[0304] Memory 520 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory. Code generation apparatus 500 may further include other removable / non-removable, volatile / non-volatile computer system storage media. Although Figure 7 As not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disc drive for reading and writing to a removable non-volatile optical disc (e.g., a compact disc read-only memory (CD-ROM), a digital video disc read-only memory (DVD-ROM), or other optical media) may be provided. In these cases, each drive may be connected to the communication bus 540 via one or more data media interfaces. The memory 520 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application.

[0305] A program / utility having a set (at least one) of program modules can be stored in memory 520. Such program modules include—but are not limited to—an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. The program modules typically perform the functions and / or methods described in the embodiments of this application.

[0306] The code generation device 500 can also communicate with one or more external devices (e.g., keyboard, pointing device, display, etc.), one or more devices that enable a user to interact with the electronic device, and / or any device that enables the electronic device to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed through the communication interface 530. Furthermore, the code generation device 500 can also communicate through a network adapter (…). Figure 7(Not shown) communicates with one or more networks (e.g., Local Area Network (LAN), Wide Area Network (WAN), and / or public networks, such as the Internet). The aforementioned network adapter can communicate with other modules of the electronic device via the communication bus 540. It should be understood that, although... Figure 7 As not shown, other hardware and / or software modules can be used in conjunction with the code generation device 500, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, Redundant Arrays of Independent Drives (RAID) systems, tape drives, and data backup storage systems.

[0307] The processor 510 executes various functional applications and data processing by running programs stored in the memory 520, such as implementing the remote access method provided in the embodiments of this application.

[0308] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the code generation device 500. In other embodiments of this application, the code generation device 500 may also employ different interface connection methods or a combination of multiple interface connection methods as described in the above embodiments.

[0309] This application also provides a computer program product, which includes a computer-readable storage medium storing a computer program, and when at least one processor executes the computer program, the at least one processor executes the above-described code generation method.

[0310] The code generation apparatus or computer program product provided in this application embodiment is used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0311] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0312] In the embodiments of this application, the functional units can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0313] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as flash memory, portable hard disk, read-only memory, random access memory, magnetic disk, or optical disk.

[0314] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A code generation method characterized by, The method comprises: obtaining a first vector converted from natural language text input by a user; determining a similarity between each of a plurality of second vectors and the first vector by using a preset API retrieval model, wherein each of the plurality of second vectors is a vector representation of features of a different preset API; determining N candidate APIs with a higher similarity from the preset APIs according to the similarity between the first vector and each of the second vectors, wherein N is an integer greater than or equal to 1; generating API request information by using a preset request generation model according to the N candidate APIs and the natural language text, wherein the API request information is used to request a code conversion engine to generate SDK calling code of a target API.

2. The code generation method of claim 1, wherein, The method further comprises: selecting M candidate APIs with a higher similarity from the preset APIs according to the similarity between the first vector and each of the second vectors, wherein M is an integer greater than N; if there are at least two APIs with a function meeting a preset similarity condition in the M candidate APIs, removing an API that does not meet a first filtering condition from the M candidate APIs to obtain N1 candidate APIs, wherein N1 is an integer greater than or equal to N and less than M.

3. The code generation method of claim 2, wherein, The method further comprises: determining differentiated information between the at least two APIs; if the natural language text includes associated information of the differentiated information, retaining an API corresponding to the associated information from the at least two APIs and removing the remaining APIs; if the natural language text does not include the associated information of the differentiated information, retaining an API with a highest preset priority from the at least two APIs and removing the remaining APIs.

4. The code generation method according to claim 2 or 3, characterized by, The method further comprises: determining a similarity difference between two candidate APIs with a neighboring position in the M candidate APIs according to the similarity of each of the M candidate APIs; if the similarity difference between the two candidate APIs is greater than a preset difference value, removing an API with a smaller similarity from the M candidate APIs to obtain N2 candidate APIs, wherein N2 is an integer greater than or equal to N and less than M.

5. The code generation method according to any one of claims 2-4, characterized by, The method further comprises: determining a number of target configuration entities corresponding to each of the M candidate APIs, the target configuration entity corresponding to the candidate API being a configuration entity in a preset API knowledge graph that has a relationship with the candidate API and that matches the natural language text successfully; selecting N3 candidate APIs corresponding to the top-ranked target configuration entities from the M candidate APIs; N3 being an integer greater than or equal to N and less than M; The API knowledge graph includes API entities and configuration entities corresponding to the API entities, and the configuration entities are used to represent parameter information required when the API is called.

6. The code generation method of any one of claims 1-5, wherein, The first vector obtained by converting the natural language text input by the user includes: If the character length of the natural language text is greater than a preset length, determine the keywords in the natural language text corresponding to a preset entity category; the preset entity category includes an operation category and a resource category; Connect the keywords in the natural language text corresponding to the preset entity category, and convert them into the first vector.

7. The code generation method according to any one of claims 1 to 6, characterized in that, Before determining the similarity between each of the second vectors and the first vector using the preset API retrieval model, the method includes: Identify the target name in the natural language text, the target name being one or more of the API entity names, API entity aliases, resource names, and resource aliases included in the preset API knowledge graph; Determine the API corresponding to the API entity associated with the target name in the API knowledge graph as the preset API. The API knowledge graph includes API entities and resource entities corresponding to the API entities; the resource entities are used to represent objects or resources acted on by the API entities.

8. The code generation method of any one of claims 1-7, wherein, The API retrieval model is obtained by training an initial model using a preset sample set; the preset sample set includes multiple training samples and labels corresponding to each training sample; the training sample includes a first text and a second text; the first text in one training sample includes an API entity in a preset API knowledge graph and a configuration entity corresponding to the API entity, and the configuration entity is used to represent parameter information required when the API is called; the second text is a natural language text sample; the label corresponding to the training sample represents the similarity between the first text and the second text in the training sample.

9. The code generation method according to any one of claims 5, 7 and 8, characterized by, The entities in the API knowledge graph include API entities, operation entities, resource entities, configuration group entities, and configuration entities; the API entities are used to describe APIs, the resource entities are used to represent objects or resources acted on by the API entities, the operation entities are used to represent actions performed by the API entities or operations on target resource entities; the configuration group entity includes multiple configuration entities, and the configuration entity is used to represent parameter information required when the API is called. The API knowledge graph is constructed according to API multi-source heterogeneous data sources, and the API multi-source heterogeneous data sources include multiple items in API description files, API historical call information, and API help documents.

10. The code generation method of any one of claims 1-9, wherein, Before the API request information is obtained according to the N candidate APIs and the natural language text by using a preset request generation model, the method comprises the following steps of: For a first candidate API whose number of API parameters is greater than a preset number, the natural language text is matched with a preset API knowledge graph to obtain a matching degree of the natural language text and each configuration entity in the API knowledge graph; An API parameter described by a configuration entity corresponding to the first candidate API in the API knowledge graph and satisfying a preset matching degree condition with the natural language text is taken as a target parameter of the first candidate API; The target parameter and a mandatory parameter of the first candidate API are taken as API parameters of the first candidate API, and the mandatory parameter is used to represent a parameter necessary for generating the API request information.

11. The code generation method of claim 10, wherein, The API parameter described by the configuration entity corresponding to the first candidate API in the API knowledge graph and satisfying the preset matching degree condition with the natural language text is taken as the target parameter of the first candidate API, and the method comprises the following steps of: An API parameter described by a configuration entity corresponding to the first candidate API in the API knowledge graph, satisfying the preset matching degree condition with the natural language text, and satisfying a preset frequency condition in terms of parameter calling frequency is taken as the target parameter of the first candidate API.

12. The code generation method of any one of claims 1-11, wherein, The method further comprises the following steps of: An SDK calling code of the candidate API is generated by using a code conversion engine according to the API request information.

13. A code generation apparatus characterized by comprising: The method comprises the following steps of: A first obtaining module is configured to obtain a first vector obtained by converting a natural language text input by a user; A first determining module is configured to determine a similarity between each second vector and the first vector by using a preset API retrieval model; wherein the second vectors are respectively vector representations of features of different preset APIs; A second determining module is configured to determine N candidate APIs in front of the similarity from the preset APIs according to the similarity between the first vector and each second vector; N is an integer greater than or equal to 1; A second obtaining module is configured to obtain API request information by using a preset request generation model according to the N candidate APIs and the natural language text; the API request information is used to request an SDK calling code of a target API generated by a code conversion engine.

14. A code generation apparatus characterized by comprising: The method comprises the following steps of: A processor and a memory storing program instructions, the processor is configured to execute the code generation method as claimed in any one of claims 1-12 when running the program instructions.

15. A computer program product, characterised in that, A computer readable storage medium storing a computer program, when at least one processor executes the computer program, the at least one processor executes the code generation method as claimed in any one of claims 1-12.

Images