Interface calling method, electronic device, and storage medium

Abstract

This application discloses an interface invocation method, electronic device, and storage medium. The method includes: responding to a received target access request by preloading a target constraint file; analyzing the true intent of the user request using a target language model and outputting initial parameters; mapping the initial parameters to initial structured parameters according to the types, structures, and parameter dependencies defined in the target constraint file; evaluating the degree of matching between the initial structured parameters and the standard parameter specifications of each cloud interface in the target constraint file, and matching the target cloud interface from the interface list; verifying the initial structured parameters according to the target parameter specifications corresponding to the target cloud interface, and, if the verification is successful, invoking the target cloud interface using the initial structured parameters. This method solves the technical problem of low accuracy of interface parameters output by models in related technologies, and improves the efficiency of interface invocation to cloud platforms.

Description

Technical Field

[0001] This application relates to the field of computers, and more particularly to an interface calling method, an electronic device, and a storage medium. Background Technology

[0002] With the rapid development of cloud technology, the types and number of services provided by cloud platforms have exploded, and the complexity of interfaces has also increased accordingly. As the number and types of business demands from users increase and become more complex and varied, calling cloud interfaces has become a pressing problem that needs to be solved.

[0003] In related technologies, key information is typically extracted from user-input natural language commands using keyword matching or regular expressions. Then, a one-to-one matching principle is used to filter target API call parameters from predefined standard API call parameters. However, these two traditional methods are prone to inaccurate semantic understanding and omission of necessary key parameters when processing natural language commands containing complex semantics or colloquial expressions, resulting in low accuracy of the generated API call parameters. This leads to inefficiency in the process of calling cloud APIs. Summary of the Invention

[0004] This application provides an interface invocation method, an electronic device, and a storage medium to at least solve the problem of low efficiency in the process of invoking cloud interfaces in related technologies. According to one aspect of an embodiment of this application, an interface invocation method is provided, comprising: responding to a received target access request, loading a target constraint file, wherein the target constraint file includes formal specifications of the semantics, structure, and inter-parameter dependencies of structured parameters used in the cloud interface invocation process; inputting the target access request into a target language model, outputting initial parameters, and mapping the initial parameters to initial structured parameters based on the target constraint file; evaluating the degree of matching between the initial structured parameters and the standard parameter specifications of each cloud interface in the target constraint file, and matching a target cloud interface from a predefined interface list based on the evaluation result; verifying the initial structured parameters based on the target parameter specifications corresponding to the target cloud interface, and, if the verification passes, invoking the cloud service corresponding to the target cloud interface through the initial structured parameters.

[0005] According to another aspect of the embodiments of this application, an interface invocation apparatus is also provided, comprising: a loading unit, configured to load a target constraint file in response to a received target access request, wherein the target constraint file includes a formal specification of the semantics, structure, and inter-parameter dependencies of the structured parameters used in the constraint cloud interface invocation process; a first processing unit, configured to input the target access request into a target language model, output initial parameters, and map the initial parameters to initial structured parameters based on the target constraint file; a second processing unit, configured to evaluate the degree of matching between the initial structured parameters and the standard parameter specifications of each cloud interface in the target constraint file, and match the target cloud interface from a predefined interface list based on the evaluation result; and an invocation unit, configured to verify the initial structured parameters based on the target parameter specification corresponding to the target cloud interface, and, if the verification is successful, invoke the cloud service corresponding to the target cloud interface through the initial structured parameters.

[0006] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the steps of any of the above-described interface calling methods through the computer program.

[0007] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, and the computer program is configured to execute the steps of any of the above-described interface call methods at runtime.

[0008] According to another aspect of the embodiments of this application, a computer program product or computer program is provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps of any of the above-described interface invocation methods.

[0009] By employing the embodiments provided in this application, a target constraint file is pre-loaded. After extracting initial parameters from the target access request sent by the user using the target language model, the initial parameters are mapped to initial structured parameters that meet the semantic and structural requirements of the constraints defined in the formal specification. Then, the matching degree between the initial structured parameters and the standard parameter specifications of each cloud interface in the target constraint file is evaluated, and the target cloud interface with the highest matching degree is selected. The target parameter specification corresponding to the target cloud interface is called to verify the initial structured parameters, and if the verification is successful, the target cloud interface is called using the initial structured parameters. In other words, by performing comprehensive formal reduction on the parameter output process of the target language model and the output initial parameters, the semantics and structure of the final output structured parameters meet the specification requirements, improving the accuracy of the interface call parameter generation results and achieving the technical effect of improving the calling efficiency of cloud interfaces. Attached Figure Description

[0010] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram illustrating an application scenario of an interface calling method according to an embodiment of this application.

[0012] Figure 2 This is a flowchart of an optional interface invocation method according to an embodiment of this application.

[0013] Figure 3 This is a schematic diagram of the overall architecture of an optional interface calling method according to an embodiment of this application.

[0014] Figure 4 This is an overall flowchart of an optional interface calling method according to an embodiment of this application.

[0015] Figure 5 This is a structural block diagram of an optional interface calling device according to an embodiment of this application. Detailed Implementation

[0016] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0017] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0018] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0019] According to one aspect of the embodiments of this application, an interface invocation method is provided. Optionally, in this embodiment, the above-described interface invocation method may be applied to, but is not limited to, applications such as... Figure 1 In the hardware scenario shown, the server device may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The server device may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the server equipment described above. For example, the server equipment may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0020] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the interface calling method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to server devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0021] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the server device. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0022] The interface invocation method of this application embodiment can be executed by a server device, or by a server device in combination with at least one of a terminal device (which can also be understood as input / output device 108). Alternatively, the terminal device can execute the interface invocation method of this application embodiment by a client installed on it.

[0023] The technical solutions in this application can be applied, but are not limited to, to scenarios where complex cloud interfaces are invoked through natural language interaction, aiming to improve the accuracy of the generated interface call parameters and the efficiency of interface calls. Specific examples of common application scenarios are given below.

[0024] In the daily operations of large enterprises or cloud computing data centers, operations and maintenance personnel frequently need to perform complex operations on cloud resources, such as creating, configuring, updating, or deleting virtual machines, database instances, and storage volumes. Traditional graphical interfaces or script-based methods are inefficient and prone to errors when dealing with large-scale, diverse, and dynamically changing cloud resources. Using the solution proposed in this application, operations and maintenance personnel can complete these operations quickly and accurately through a simple and natural dialogue interface, improving operational efficiency and accuracy while reducing the risk of misoperation.

[0025] Unified Resource Scheduling in Multi-Cloud Environments: In multi-cloud or hybrid cloud architectures, different cloud service providers offer their own independent and differentiated APIs (Application Programming Interfaces), increasing the complexity of resource management. This application's solution, through standardized interface schema constraints, can automatically adapt to the APIs of different cloud platforms, realizing the conversion from natural language commands to precise parameters for each cloud platform. This supports managing heterogeneous cloud resources with a unified dialogue interface. For example, operations personnel only need to input "create a high-performance database server on cloud platform A and cloud platform B," and based on the different interface schemas, two sets of parameters conforming to the API interface specifications of their respective cloud platforms will be automatically generated. This allows for the invocation of the database creation interfaces on both cloud platforms, simplifying resource scheduling and management in multi-cloud environments.

[0026] The following example demonstrates how the server executes the interface call method in this embodiment. Figure 2 This is a flowchart illustrating an optional interface calling method according to an embodiment of this application, such as... Figure 2 As shown, the process of this method may include steps S202 to S208.

[0027] Step S202: In response to the received target access request, load the target constraint file, wherein the target constraint file includes the semantics, structure, and formal specifications of the structured parameters used in the constraint cloud interface call process, as well as the dependencies between parameters.

[0028] Step S204: Input the target access request into the target language model, output initial parameters, and map the initial parameters to initial structured parameters based on the target constraint file.

[0029] Step S206: Evaluate the degree of matching between the initial structured parameters and the standard parameter specifications of each cloud interface in the target constraint file, and match the target cloud interface from the predefined interface list based on the evaluation results.

[0030] Step S208: Verify the initial structured parameters based on the target parameter specification corresponding to the target cloud interface, and if the verification is successful, call the cloud service corresponding to the target cloud interface through the initial structured parameters.

[0031] To facilitate understanding, the technical terms involved in the embodiments of this application will be briefly described first.

[0032] LLM (Large Language Model): In this embodiment of the application, it refers to the core natural language processing model used for instruction semantic recognition and preliminary parameter extraction.

[0033] Schema: Interface specification, in this application embodiment, may refer to, but is not limited to, a formal specification used to describe metadata such as cloud interface parameter structure, type, and constraints, and is the basis for constraint generation and verification.

[0034] API (Application Programming Interface): Refers to the service interface provided by the cloud platform that can be called programmatically, such as creating virtual machines and querying databases.

[0035] CSG (Constrained Structural Generation): A key technology in this application embodiment refers to the process of using interface schema as a hard constraint during the generation of language model parameters to ensure that the output result is always structurally valid.

[0036] PIC (Parameter-wise Consistency Checking): refers to the deterministic validation of generated parameters field by field based on the interface schema to ensure their full compliance.

[0037] SHR (Self-Healing Resampling): When PIC verification fails, the system automatically and specifically regenerates the erroneous parameters to achieve "self-repair" without user intervention.

[0038] JSON (JavaScript Object Notation): A lightweight data exchange format. In this embodiment, it is used as the basic format for parameter objects and defined using JSON Schema.

[0039] DAG (Directed Acyclic Graph): Used to represent dependencies between parameters to optimize the questioning order in a multi-round clarification process.

[0040] PIR (Parameter Intermediate Representation): An internal data structure used for explicit normalization and information traceability between parameter extraction and validation.

[0041] RBAC / ABAC (Role-Based / Attribute-Based Access Control): An access control model in the field of information security. In this embodiment, it is used to verify the caller's operation permissions.

[0042] The purpose of this application is to provide a cloud interface self-healing parameter extraction system and method based on schema constraints and clarification mechanisms. This aims to solve the problems of low parameter extraction accuracy, low interaction efficiency, and low task success rate in existing technologies when using natural language to call cloud platform interfaces, due to semantic ambiguity, missing parameters, or format errors. By introducing interface specifications (Schema) to strongly constrain the output of the language model inference unit, combining multi-layered verification and intelligent clarification interaction, and incorporating a closed-loop post-processing mechanism of parameter consistency verification and self-healing resampling, a secure, reliable, and efficient conversion from natural language to accurate and complete cloud interface parameters is achieved.

[0043] To facilitate understanding, let's first combine... Figure 3 The overall architecture diagram shown provides a brief introduction to the above interface call methods.

[0044] The system proposed in this application is a layered, modular architecture designed to accurately translate unstructured natural language requests into structured, directly executable cloud platform interface calls. The system as a whole consists of... Figure 3 The five core layers shown are the user interaction layer, semantic understanding layer, parameter validation layer, clarification interaction layer, and execution and feedback layer, together with the basic data structures that support the operation of these layers.

[0045] The user interaction layer is primarily responsible for receiving natural language commands from users, providing clarification interactions when parameters fail validation, and displaying the final API call status. As the system's portal, the user interaction layer is mainly responsible for all interactions with the end user. It provides an interface, typically a human-computer interaction terminal integrated into the cloud management platform portal, to receive users' natural language commands. When the system encounters uncertainty in subsequent processing, this layer is also responsible for clearly displaying clarification questions generated by the clarification interaction layer and receiving supplementary input from the user. Finally, after the backend API execution is complete, it provides feedback on the execution result or status to the user in a structured, easy-to-understand format (such as a list, card, or text summary).

[0046] The semantic understanding layer can, but is not limited to, utilize the target language model to understand the user intent in the target access request and extract initial parameters from it. Then, it maps the initial parameters to compliant initial structured parameters through the target constraint file. Finally, by evaluating the degree of matching between the initial structured parameters and the standard parameter specifications of each cloud interface, the best cloud interface, i.e., the target cloud interface, is selected from the interface list.

[0047] In other words, the semantic understanding layer is mainly used for semantic understanding and intent recognition of natural language commands input by users, as well as interface selection. Specifically, when a user inputs the above request, the request is first sent to the semantic understanding layer. The intent recognition model of this layer analyzes the statement and identifies the core action as "create" and the core object as "server" (i.e., virtual machine). The model performs semantic matching on all registered cloud interfaces and finds that the create_vm (create virtual machine) interface has the highest matching degree. At the same time, the model may find that interfaces such as create_bare_metal_server (create physical server) also have some similarity, but the confidence level is low. Therefore, the system selects create_vm as the first choice candidate intent and loads its corresponding interface schema to prepare for parameter extraction. If the confidence levels of multiple interfaces are very close, the system will trigger a clarification interaction, asking the user "Do you want to create a virtual machine or a physical server?"

[0048] It's important to note that the semantic understanding layer is the core of converting natural language into machine-understandable intents. This layer receives raw text from the user interaction layer and first analyzes the user's primary purpose through a language model inference unit. For example, "Help me build a test server" is recognized as the intent to "create a virtual machine." After identifying the intent, the system selects one or more of the most matching candidate cloud interfaces from a predefined list of interfaces. Then, preliminary slot extraction is performed, which involves extracting parameters related to the candidate interfaces from the user input, such as "2-core CPU" and "8GB memory."

[0049] The parameter validation layer performs standardization validation on the initial structured parameters corresponding to the target cloud interface. This primarily includes execution type validation, format validation, range validation, enumeration validation, mandatory field checks, and parameter normalization, ensuring parameter consistency and compliance. Simultaneously, it triggers a self-healing resampling (SHR) mechanism to attempt to automatically correct parameter errors generated by the model.

[0050] The clarification interaction layer is used when the parameter validation layer fails to validate the initial structured parameters and the error cannot be corrected by the self-healing resampling mechanism. It then uses a pre-built clarification question library and template engine to generate clarification questions corresponding to the erroneous fields. Its purpose is to obtain missing or conflicting parameter information with the fewest possible dialogue rounds.

[0051] The clarification interaction layer is primarily activated when the parameter validation layer detects any form of parameter conflict, missing information, or ambiguity, or when the semantic understanding layer is uncertain about the user's intent (e.g., multiple candidate interfaces have similar confidence levels). Its core responsibility is to proactively eliminate uncertainty, rather than directly denying service. This layer follows the principle of "minimizing information entropy" or "minimal clarification," generating highly targeted questions to obtain the key information needed for decision-making. For example, if the operating system parameter is missing, it generates the question "Please select the operating system type of the virtual machine: 1. CentOS, 2. Ubuntu, 3. Windows Server." These questions can be multiple-choice, fill-in-the-blank, or yes / no questions, designed to provide the most effective information to the user with minimal cognitive load.

[0052] The execution and feedback layer is responsible for assembling the parameters into a valid API call request and sending it to the cloud resource management platform when all parameters have passed validation and are unambiguous. This layer monitors the return status of the interface call. If the call is successful, it parses the business data and formats it into a user-friendly result display; if the call fails or an exception occurs, it captures the error and retryes according to preset strategies or generates error messages.

[0053] In addition, the basic data structure predefines the standard format of the call parameters required to call different cloud interfaces (i.e., the content of the target constraint file), clarifies the dialogue state table during the interaction process, supports parameter reuse and correction, and includes a thesaurus and alias library. Support and evolution mechanisms can include, but are not limited to, automated monitoring and adaptation mechanisms for cloud platform API changes, enabling automatic schema updates and synchronization, and extending the system's service scope from a single private cloud environment to multi-cloud and hybrid cloud environments. By adapting the APIs of different cloud environments to corresponding schema constraints, it achieves the management of heterogeneous cloud resources using a unified natural language interactive experience.

[0054] Among them, in order to support Figure 3 To ensure the efficient operation of the hierarchical framework shown, this application embodiment designs three key basic data structures.

[0055] (1) Interface Schema: For each API in the cloud platform that can be called using natural language, a corresponding interface schema is defined. This schema adopts the industry-standard JSON Schema format, which is a standardized specification for defining and validating JSON (JavaScript Object Notation) data structures. The schema file precisely describes all the parameters required for an API call, including the name of each parameter, its data type (such as string, number, boolean), whether it is required, the range or enumeration list of valid values, the default value, and the dependencies between parameters.

[0056] For example, the schema of an interface for creating a virtual machine, `create_vm`, defines fields such as `vm_name` (string, required), `cpu_cores` (integer, range 1~64, required), `memory_gb` (integer, required), and `os_type` (string, enumerated values ​​are ['centos', 'ubuntu'], default value is centos). The schema is not only the basis for parameter validation, but more importantly, it is used to constrain the output of the Language Model (LLM) inference unit, ensuring that the generated parameter objects are always structurally valid. To enhance its expressiveness, the schema constraints in this application embodiment also include at least the following extensions.

[0057] 1) Required fields and mutual exclusion dependencies: Complex parameter constraints are formally described by introducing requires, oneOf, anyOf, allOf, and custom x-mutualExclusive (mutual exclusion) and x-dependsOn (dependency) fields. For example, the iops field is only required when disk_type is cloud_ssd.

[0058] 2) Version and evolution information: Each schema contains metadata such as schema_version (version number), deprecation_date (deprecation date), and compatibility_rules (compatibility rules) to support the smooth evolution of the interface.

[0059] 3) Normalized Mapping Table: The schema can embed or link a normalized mapping table to map colloquial expressions to standard parameter values. Each entry in this table must contain at least the following fields: source (source word), target (target value), rule (transformation rule, such as regular expression), and confidence (confidence level).

[0060] (2) Syntax Constraint Assembler: The system compiles the interface schema into a Weighted Finite State Automaton (WFSA) or an equivalent Context-Free Grammar (CFG), and incorporates it as a hard constraint during the CSG decoding stage. This assembler supports automatic translation of oneOf / anyOf / allOf, mutual exclusion / dependency, and enumeration range, reducing structural biases caused by model degrees of freedom. For cross-field constraints that cannot be directly syntacticized, the PIC performs a two-stage verification.

[0061] 1) Dialogue State Table: To effectively manage multi-turn dialogues, the system maintains a dynamic dialogue state table for each user session. This table acts like a short-term memory for the session, recording the currently determined user intent, all extracted and validated slots, and their corresponding values. As the user provides information through multiple rounds of interaction, the table is updated in real time. For example, in the first round, the user inputs "create virtual machine," and the state table records the intent; in the second round, the user inputs "use Ubuntu system," and the state table updates the os_type slot. This mechanism avoids repeated questioning, ensures the continuity of the dialogue, and supports more complex interaction logic, such as the user correcting provided parameters during the dialogue, or reusing parameters confirmed in a session (such as "availability zone ID") in subsequent related interface calls.

[0062] 2) Synonym and Alias ​​Library: To bridge the gap between users' colloquial and diverse expressions and standard terminology, the system maintains an extensible synonym and alias library. This library establishes a mapping relationship from informal expressions to standardized parameter names or values. For example, user inputs such as "virtual machine," "VM," and "server" can be mapped to the internally unified virtual_machine entity; "two-core" and "dual-core processor" can be mapped to cpu_cores:2. This library can be continuously enriched through manual compilation and automatic mining from historical interaction data, improving the system's natural language understanding capabilities and user experience.

[0063] (3) Parameter Intermediate Representation (PIR): A type-safe intermediate representation is introduced between CSG and PIC to explicitly normalize unit conversions (e.g., "8GB / 8192MB"), regional aliases, and model family trees. PIR stores field values, units, normalization results, sources, and confidence levels in a 5-tuple of "value, unit, canonical, proofance, conf". PIC only verifies canonical data, and SHR only writes back the value / unit of failed fields, keeping the remaining fields frozen.

[0064] In this embodiment, after receiving the user's input of a target access request, an initial parameter set is first generated using a target language model (such as LLM). This process transforms natural language into a semantic representation that a computer can understand. However, due to the ambiguity and openness of natural language, the parameters generated by the model may not fully conform to the schema requirements in terms of syntax or semantics. Therefore, the next step is to map these preliminary parameters to initial structured parameters based on the target constraint file, ensuring that they structurally match the schema.

[0065] Assessing the degree of match between the initial structured parameters and the standard parameter specifications defined in the target constraint file is a key step. By comparing the generated parameters with the schema, their consistency is quantified, and based on this, the most suitable cloud interface is selected from a predefined list of interfaces. For example, if the user intent is identified as "create virtual machine," the system will select the best cloud interface that best matches virtual machine creation from multiple APIs.

[0066] After the target cloud interface is determined, the initially generated structured parameters will be validated according to the schema of the target cloud interface. Validation includes, but is not limited to, checking the parameter type, format, range, and whether all required fields are met. When the parameters pass all validations, the system will use these structured parameters to call the corresponding cloud service, for example, to actually create a virtual machine instance.

[0067] Conversely, if the verification passes, the cloud service corresponding to the target cloud interface is called directly using the initial structured parameters, and then an instance that meets the user's needs is created, such as the virtual machine instance required by the user.

[0068] By employing the embodiments provided in this application, and by loading the target constraint file, i.e., the interface schema, strong constraints can be imposed on the semantics, structure, and dependencies of the parameters before and during model output. This means that, whether in the language model inference stage or the parameter transformation process, the generated parameters can be ensured to strictly adhere to the rules defined by the API, including parameter types, value ranges, default values, and mutual exclusion or dependency relationships between parameters. This mechanism improves the accuracy and consistency of parameter extraction, reduces the need for subsequent verification and clarification, and thus solves the problems caused by the lack of deep understanding and constraints in traditional methods, achieving efficient and error-free conversion from natural language to structured parameters.

[0069] In an exemplary embodiment, the above-described mapping of the initial parameters to initial structured parameters based on the target constraint file includes: obtaining explicit information in the target access request; mapping the explicit information to a first type of parameter in the target lexicon, wherein the semantics and structure of each parameter in the target lexicon satisfy the formal specifications indicated by the target constraint file.

[0070] This embodiment aims to map the initial parameters output by the target language model after determining the target cloud interface. Specifically, the explicit information (i.e., declarative information) in the initial parameters is directly mapped to the first type of parameters in the target lexicon. The formal specifications of the first type of parameters (including the semantics, structure, and inter-field dependencies of each field) all meet the specifications and requirements in the target constraint file.

[0071] In addition to the mapping processing of the display information in the initial parameters output by the model as described above, this embodiment also provides another processing method. That is, firstly, based on the key request information in the target access request obtained by the target language model, and considering the degree of matching between the standard parameter specifications of various cloud interfaces in the industry based on the key request information, the target cloud interface is matched from the interface list. Then, the target parameter specification (i.e., interface schema) of the target cloud interface and the target access request are used as input to guide the target language model in constraining its structured generation (CSG), such as the initial structured parameters. This process forces the parameters output by the target language model to strictly adhere to the field names, data types, and nested structures in the target constraint file.

[0072] For example, explicit information in the initial parameters, such as "Availability Zone A", can be accurately extracted directly through entity recognition and synonym mapping to obtain availability_zone:"cn-A".

[0073] For the first processing method described above, the type, format, and field name are strictly validated according to the interface schema during the mapping process to ensure that the generated parameters fully comply with the specifications in terms of both semantics and structure. This process provides an accurate parameter basis for subsequent parameter validation, clarification, and execution steps.

[0074] In other words, by mapping explicit information to first-class parameters that satisfy the interface constraint specification, the accuracy of the conversion from natural language to structured parameters is ensured, laying the foundation for subsequent processing steps.

[0075] In an exemplary embodiment, the above-described mapping of the initial parameters to initial structured parameters based on the target constraint file includes: obtaining implicit information in the target access request; parsing the cloud resource requirements represented by the implicit information and mapping the cloud resource requirements to parameter slots defined in the target constraint file, wherein the parameter slots include a parameter name field, a parameter type field, and a parameter value field; and filling the parameter slots based on the parameter types and constraints defined in the target constraint file to obtain a second type of parameter, wherein the initial structured parameters include a first type of parameter and a second type of parameter.

[0076] Assuming that, as described in the above embodiment, initial parameters are first output using the target language model and then mapped, for implicit information in the initial parameters, i.e., fuzzy information, such as "high configuration," the system will query a preset configuration template library and may find a template marked "high_performance." This template defines a specific CPU and memory combination, such as cpu_cores:16, memory_gb:32. The system will use these values ​​as the initial extracted parameters.

[0077] For example, assuming the initial parameters "for my development team" and "test server" are identified from the target access request, the system may resolve them as part of a tag or name, such as generating tags:["dev-team","test"], or suggesting a virtual machine name vm_name: "dev-test-server".

[0078] After the parameters are extracted, the parameter validation layer immediately intervenes and performs a comprehensive validation of the extracted structured parameters {availability_zone:"cn-A",cpu_cores:16,memory_gb:32...} according to the schema constraint specifications to ensure that their types, value ranges, etc. are all valid.

[0079] In other words, for ambiguous information that cannot be directly extracted, the system first performs deep analysis of the user's natural language request to parse out the implicit cloud resource requirements. These requirements are then mapped to parameter slots defined in the target constraint file (i.e., the interface schema). This process includes identifying parameter names, determining parameter types, and inferring possible parameter values. Finally, based on the parameter types and constraints specified in the schema, the mapped parameter slots are filled to generate a second type of parameter.

[0080] Through the above steps, not only is the problem of converting implicit information in user requests solved, but the legality and completeness of the conversion results are also guaranteed, thereby improving the accuracy of parameter generation and the success rate of tasks. This demonstrates the effectiveness and flexibility of implicit information processing in the conversion process from natural language to cloud interface calls in the embodiments of this application.

[0081] In an exemplary embodiment, the above-described evaluation of the matching degree between the initial structured parameters and the standard parameter specifications of each cloud interface in the target constraint file includes: sequentially obtaining each cloud interface as the current cloud interface from the various cloud interfaces; obtaining the current similarity between the initial structured parameters and the current standard fields defined by the current standard parameter specification, wherein the current standard parameter specification is a formal specification of the current structured parameters used to call the current cloud interface; based on the initial structured parameters, determining the fill rate of key parameters (which can also be understood as required parameters or required items) in the parameter slots corresponding to the current cloud interface, wherein the fill rate represents the ratio between the number of filled parameters in the key parameters and the total number of key parameters; obtaining the historical call success rate of the current cloud interface in the historical period; and determining the current evaluation result of the current cloud interface based on the current similarity, the fill rate, and the historical call success rate.

[0082] When a cloud platform contains multiple cloud interfaces, a deterministic control loop is designed, and a scoring function is used to filter or match the optimal cloud interface from among the multiple cloud interfaces. Specifically, the following processing is performed for each of the multiple cloud interfaces.

[0083] (1) Calculation of current similarity: The user request is compared with the standard parameters defined in the schema (standard parameter specification) of each cloud interface to calculate the similarity between them. For example, the schema of the create_vm interface defines fields such as availability_zone and instance_class. The system will analyze the degree of matching between "Availability Zone A" and the availability_zone field, and between "high configuration" and the instance_class field in the user request.

[0084] (2) Fill rate determination: Check the coverage of parameters provided in the user request, such as "Availability Zone A", with the required parameters defined in the create_vm interface schema (such as availability_zone, instance_class, os_type, etc.), and calculate the fill rate of key parameters. For example, if the schema defines 4 required parameters and the user request provides 2 of them, the fill rate is 50%.

[0085] (3) Obtaining historical call success rate: Query the call success rate of each candidate interface in the historical period. For example, the ratio of the number of successful calls to the total number of calls of the create_vm interface in the past three months reflects the stability and efficiency of the interface.

[0086] (4) Determination of the current evaluation result: Based on the above calculation results, the current evaluation result of each candidate interface is calculated.

[0087] The above evaluation results comprehensively reflect the degree of matching between the interface and the user request, the completeness of the parameters, and the historical performance of the interface, enabling the system to objectively select the most suitable cloud interface to execute the user's natural language request.

[0088] In addition to the current similarity, fill rate, and historical call success rate mentioned above, more influencing factors need to be considered, such as the number of parameter supplementation interactions and the number of constraints. Specifically, this is achieved through the following implementation: obtaining the number of constraints in the constraints indicated by the current standard parameter specification that are not satisfied by the initial structured parameters; and weighting the current similarity, fill rate, historical call success rate, number of parameter supplementation interactions, and number of constraints to obtain the current evaluation result.

[0089] The specific implementation process for matching the target cloud interface from multiple cloud interfaces can be determined, but is not limited to, by the scoring function shown in the following formula (1).

[0090] Score(API)=α·SchemaFit+β·ParamCompleteness+γ·HistSuccess-δ·ClarifyCost-ε·ConflictRisk (1)

[0091] SchemaFit is used to measure the degree of matching between entities extracted from user input and interface schema definitions (field names, types, constraints), and is estimated by calculating the Jaccard similarity or word vector cosine similarity between the extracted entities and schema fields.

[0092] ParamCompleteness measures the coverage of required parameters (slots) being satisfied in the current dialog state. Its value is the ratio of the number of filled required slots to the total number of required slots.

[0093] HistSuccess represents the success rate or near-real-time health score of the interface in historical calls, such as the rolling success rate of the interface calls over the last 7 days.

[0094] ClarifyCost is used to estimate the number of clarification interaction steps required to complete the parameters needed for the interface. Its value is a normalized representation of the number of missing required parameters, or an estimate of the expected number of clarification rounds using a small predictive model.

[0095] ConflictRisk represents the risk of triggering a conflict based on the mutual exclusion or dependency relationships defined in the schema. Its value is a normalized representation of the number of constraints violated by the current parameter set.

[0096] The weighting factors α, β, γ, δ, and ε are learnable or configurable parameters. For example, they can be set to α=0.35, β=0.25, γ=0.2, δ=0.1, and ε=0.1.

[0097] Adaptive Weighted Learning Unit: The weight vector w=[α,β,γ,δ,ε] of the scoring function is configured for online updates. The system iteratively estimates w using multi-armed slot machine or Bayesian optimization to maximize the weighted objective of "offline verification pass rate and online task success rate". The update period is a configurable window (e.g., hourly), and it reverts to the previous version w when confidence is insufficient. This mechanism reduces the sensitivity of fixed weights to interface evolution and business seasonality.

[0098] By designing the aforementioned scoring function, the applicability and risks of each candidate cloud interface can be comprehensively evaluated, providing data support for subsequent intelligent selection. This process ensures that even in cases where parameters are partially missing or potential conflicts exist, the system can intelligently determine the optimal cloud interface invocation strategy, thereby improving task success rate and user experience.

[0099] The aforementioned scheme for determining the target cloud interface not only considers the matching degree between parameters and the interface and the completeness of the user request, but also quantifies the clarification costs and compliance risks. Finally, a comprehensive evaluation result is obtained through weighted summation, guiding the system to make optimal decisions and select the most suitable cloud interface to execute the user request. This mechanism demonstrates the intelligence, efficiency, and robustness of the embodiments of this application in processing the conversion from natural language to cloud interface calls.

[0100] In an exemplary embodiment, the above-mentioned matching of a target cloud interface from a predefined list of interfaces based on the evaluation results includes: sorting the evaluation results of each cloud interface to obtain a sorting result; selecting the target evaluation result that ranks higher based on the sorting result; and matching the target cloud interface from the list of interfaces based on the target evaluation result.

[0101] The evaluation results for each cloud interface are sorted. Based on the sorting, the highest-ranked target evaluation result is selected. Then, the target cloud interface with the highest evaluation score is determined and chosen as the primary target for executing the user request. This selection process ensures that the system can accurately match the most suitable cloud interface based on a detailed analysis and comprehensive evaluation of the current request, thereby improving the success rate and efficiency of task execution.

[0102] For example, when the system receives a user request such as "Create a high-configuration server for data analysis, with good performance," it first uses the target language model to semantically understand the user request, identify and match candidate cloud interfaces related to the request. Then, it performs a deep evaluation of each interface, including parameter matching degree, fill rate, historical success rate, clarification cost, and constraint risk, generating its own evaluation results.

[0103] The system ranks the evaluation results of multiple candidate interfaces and intelligently selects the target evaluation result with the highest score from the ranking. This process ensures that the system can make objective and intelligent decisions based on multi-dimensional analysis of user requests, selecting the most suitable cloud interface to execute the task, greatly improving the success rate of the task.

[0104] In an exemplary embodiment, the above-mentioned verification of the initial structured parameters based on the target parameter specification corresponding to the target cloud interface includes: finding the target parameter specification from the target constraint file based on the target interface identifier of the target cloud interface; and verifying each field in the initial structured parameters based on the target parameter specification to obtain a verification result.

[0105] Once the system identifies the target cloud interface using a scoring function, it searches for the corresponding interface schema file in the interface registry based on the interface's unique identifier (such as the interface ID). The interface schema defines in detail the parameters required by the cloud interface, parameter types, constraints, default values, and dependencies between parameters, serving as the core basis for parameter verification and clarification processes. This search process ensures that subsequent parameter validation is based on the most accurate and comprehensive interface specifications.

[0106] Based on the obtained target parameter specifications (i.e., the interface schema), each field in the initial structured parameters transformed from the user request is validated one by one. The validation process includes checking whether the field name exists in the schema, whether the data type of the field value matches, whether the field value meets the range or enumeration restrictions defined in the schema, and whether any required fields are missing. This series of validations ensures the integrity and validity of the parameter object, providing a reliable guarantee for subsequent cloud interface calls.

[0107] It should be noted that the system in this application embodiment may, but is not limited to, be designed to dynamically adapt to the continuous evolution of cloud platform APIs. Its core is an interface registration center, which includes at least the following contents.

[0108] (1) Interface Change Detector: This module is configured to periodically or by subscribing to messages to detect changes to the interface schema. If a change is detected, it will automatically trigger a compatibility check process, which includes at least: 1) replaying the historical offline use case set covering the interface to assess the impact; 2) if necessary, automatically updating or prompting to update the relevant weights of the multi-interface selection scoring function described above.

[0109] (2) Parameter Mapper: To ensure backward compatibility, when a disruptive change occurs to the interface (such as field renaming), this module is configured to automatically map parameters from historical conversations or old version requests (e.g., the old field `region`) to the new field `availability_zone` according to the `compat_rules` in the schema, and can populate default values ​​according to the rules. This ensures that even if the interface is upgraded, ongoing multi-turn conversation tasks or requests based on history can still continue to execute.

[0110] Through the above mechanism, the system achieves "hot update" and "uninterrupted adaptation" of interface evolution without modifying the core code or stopping the service.

[0111] Through precise matching and verification processes, potential errors in parameter objects were effectively identified, providing a solid foundation for subsequent parameter supplementation, self-healing resampling, and cloud API calls. Simultaneously, it ensures that even when faced with complex and diverse user requests, parameter objects conforming to cloud API call specifications can be generated. This achieves a seamless connection from natural language to precise parameter conversion, which is crucial for ensuring the automation, accuracy, and efficiency of cloud platform operations and maintenance.

[0112] In an exemplary embodiment, the above-mentioned method of finding the target parameter specification from the target constraint file based on the target interface identifier of the target cloud interface includes: obtaining the index relationship between a pre-created interface identifier and the parameter specification in the target constraint file; and finding the target parameter specification from the target constraint file according to the target interface identifier and the index relationship.

[0113] After selecting the target cloud interface according to the method in the above embodiments, the operationId of the target cloud interface (which can also be understood as the target interface identifier) ​​can be obtained. Then, the schema constraints of the interface can be obtained according to the target interface identifier, and the model output can be validated according to the constraints. For example, if the target cloud interface contains a field pageSize (used for pagination), and the schema is defined as a numeric type, but the model outputs a string, it is necessary to validate and correct it according to the schema.

[0114] In this embodiment, the index relationship refers to the establishment of a mapping relationship between cloud interface identifiers and their respective schemas. This index can be a simple mapping table where the key is the interface identifier, such as `create_vm` or `create_db_instance`, and the value is a path or index pointing to the parameter specification of the call parameters for each cloud interface in the interface schema file (i.e., the target constraint file). The purpose of creating the index is to enable quick retrieval of the complete parameter specification related to a specific interface in subsequent processes, thereby improving the system's response speed and processing efficiency.

[0115] Once the system identifies the target cloud interface using a scoring function, it quickly locates the parameter specification file associated with that interface using a pre-created index relationship. This search process is not only fast and efficient, but also ensures that subsequent parameter verification and clarification interactions are based on the most accurate parameter specification, avoiding processing errors caused by delays or incorrect matching in parameter specification lookup.

[0116] The interface identifier allows for quick retrieval of the target parameter specifications corresponding to the target cloud interface. These specifications can be used, but are not limited to, to perform validity checks on the initial structured parameters generated from user requests. This includes checking the accuracy of field names, the matching of field types, the range and enumeration restrictions of field values, and the completeness of required fields.

[0117] If any inconsistencies or omissions are found, a self-healing resampling or clarification interaction process can be initiated based on the details in the Schema file to resolve parameter conflicts or obtain necessary supplementary information, thereby ensuring the integrity and compliance of the final parameter set.

[0118] In an exemplary embodiment, the above-described verification of each field in the initial structured parameters based on the target parameter specification includes at least one of the following: sequentially obtaining each field from the initial structured parameters as the current field; comparing the field type of the current field with the target type defined in the target parameter specification to obtain a type verification result; verifying whether the field format of the current field meets the standard format defined in the target parameter specification to obtain a format verification result; verifying whether the current value of the current field is within the value range defined in the target parameter specification to obtain a value range verification result; and, if the current field is a key parameter, determining the filling status of the current field, wherein the filling status indicates whether the current field is missing.

[0119] To ensure the correctness and usability of the initial structured parameters output in the target language model set, the following is utilized: Figure 3 The parameter validation layer shown performs a series of rigorous automated validations on the parameters output by the semantic understanding layer. This process is entirely based on the predefined schema of the target interface. The specific validation content is as follows.

[0120] (1) Type validation: Ensure that the data type of the parameter value is correct. For example, the memory size should be a number (integer) and the virtual machine name should be a string (string).

[0121] (2) Format validation: Validate strings with specific format requirements, such as IP address format, date and time format, etc.

[0122] (3) Range check: Check whether the value is between the minimum and maximum allowed values. For example, the number of CPU cores must be between 1 and 128.

[0123] (4) Enumeration validation: Confirm whether the parameter value belongs to a predefined valid list. For example, the operating system type must be one of "CentOS", "Ubuntu" or "Windows Server".

[0124] (5) Required field check: Verify that all parameters marked as “required” in the Schema have been provided (which can also be understood as integrity verification).

[0125] In addition, the parameter validation layer is also responsible for parameter normalization, such as unifying "8G", "8GB" and "8 G" into the standard value 8, and filling in parameters that are not provided by the user but have default values ​​according to the schema.

[0126] It should be noted that type validation confirms that the data type of each field is consistent with the target type defined in the schema; format validation ensures that the field values ​​follow the standard format preset by the schema; value range validation confirms that the field values ​​fall within the legal value range; and key parameter fill status check identifies and completes all required fields to avoid parameter omissions.

[0127] The above parameter verification process can effectively identify potential errors in the parameters and, when necessary, initiate clarification interactions or self-healing resampling to automatically correct or supplement erroneous parameters, ensuring the complete compliance of the final parameter object.

[0128] In an exemplary embodiment, the method further includes: if the initial structured parameters are not validated based on the target parameter specification and the validation fails, an exception handling mechanism is executed based on the validation exception category.

[0129] First, it's crucial to accurately identify the specific reason for the parameter validation failure, i.e., the exception category. Exception categories may include, but are not limited to: field type mismatch, incorrect field format, values ​​outside the range, missing fields, or logical conflicts. This classification and identification process provides direction for subsequent exception handling mechanisms, ensuring the system can adopt the most appropriate response strategy for different types of errors.

[0130] Depending on the specific category of the validation exception, the corresponding exception handling mechanism is activated. This mechanism may include self-healing resampling (SHR), user clarification interaction, parameter default value filling, or error feedback, etc., aiming to ensure the final compliance of the parameter object, or to provide users with clear error information and remedial suggestions.

[0131] It should be noted that if the verification fails, the self-healing resampling method is used first, so that the target language model re-outputs the erroneous parameters or fields to ensure that the abnormal parameters are repaired or corrected as much as possible without having to interact with the user for clarification.

[0132] For example, suppose during the validation process, it's discovered that `image_id` (image ID) and `network_id` (network ID) are required parameters in the schema of the `create_vm` interface, but the user didn't provide them in the initial request. In this case, the system will calculate a unified ambiguity metric to determine whether to trigger clarification. This metric combines three factors: first, the uncertainty of intent, i.e., the system's understanding of which operation the user wants to perform (e.g., "create virtual machine" or "query virtual machine"); second, the proportion of missing required parameters, i.e., how much necessary information has not been provided; and finally, the number of parameter conflicts, i.e., whether there are logical contradictions in the information provided by the user. The system assigns different weights to these three factors and calculates a total score. When this score exceeds a preset threshold, it means the ambiguity is too great, and clarification interaction needs to be initiated. Conversely, if the score is within a certain threshold, clarification interaction is not needed, and the erroneous or missing fields can be corrected through other methods.

[0133] It's important to note that the clarification interaction layer follows the principle of minimum clarification, which essentially involves selecting the question that most effectively eliminates uncertainty. To this end, the system evaluates the expected information gain of each potential question. That is, how much the system expects to reduce the overall uncertainty regarding user intent, parameter completeness, and conflict states after posing the question. Simultaneously, the system also estimates the "cognitive cost" for the user to answer the question; for example, the cost of multiple-choice questions is lower than that of fill-in-the-blank questions.

[0134] Finally, the system will select the question with the highest cost-effectiveness—that is, the question that yields the greatest information gain with the least user response cost. The system can also combine multiple related questions into one (e.g., asking for both the mirror ID and the network ID simultaneously), as long as the complexity of the question does not place too much burden on the user.

[0135] In this embodiment, since the missing fields image_id and network_id cause the ambiguity metric to exceed the limit, the system will choose to clarify these two parameters and fill in all the necessary information through one or two rounds of precise question and answer.

[0136] By employing the above methods, the system not only ensures that it can intelligently handle potential errors in parameter generation even when faced with complex and diverse user requests, but also improves the overall success rate of tasks and user experience through fine-grained classification and targeted processing of exception categories.

[0137] In an exemplary embodiment, the above-described exception handling mechanism based on the validation exception category includes: when the validation exception category indicates that the parameter structure of the initial structured parameters is non-compliant, sending a resampling request carrying a correction instruction to the target language model, wherein the correction instruction is used to describe the erroneous field in the previously output initial structured parameters; resampling the target access request using the target language model, and re-outputting a resampled field with the same semantics and parameter slot as the erroneous field; and if the parameter structure of the resampled field is validated for compliance and the validation passes, replacing the erroneous field in the initial structured parameters with the resampled field.

[0138] In rare cases, even with schema constraints, the target language model inference unit may generate a structurally incomplete JSON object due to internal inference errors (e.g., misspelled field names or incorrect field placement). The parameter consistency verification (PIC) module in this embodiment is capable of capturing such structural errors.

[0139] When the PIC module detects that the output JSON fails schema validation, the system does not immediately fail or disturb the user. Instead, it initiates a defined Self-Healing Resampling (SHR) process. An internal request with correction instructions is sent to the target language model inference unit, pointing out the erroneous fields in the previous output and requesting that it regenerate only for the failed fields. This process is a closed-loop, system-wide "self-healing" behavior. For example, the system might report, "The field 'cpu_core' in the last generated JSON was misspelled; it should be 'cpu_cores.' Please regenerate." The system will attempt the SHR process a certain number of times (e.g., no more than a preset threshold N_max = 3 times).

[0140] If the regenerated fields pass validation, the system directly calls the target cloud interface to initialize the structured parameters. Conversely, if the model still cannot generate a compliant parameter structure after multiple resampling attempts, the system will trigger a fallback mechanism. In this case, it will abandon structured extraction and instead present the user with a more open-ended question or directly suggest that the user use a traditional form interface, providing a corresponding link. This ensures that the user's task path remains smooth even when the model performs poorly.

[0141] In a specific example, suppose that according to the technical solution in the above embodiments, the initial structured parameters output by the target language model have a minor error, for example, generating "storage-type":"essd" (using hyphens instead of underscores). During validation, the PIC will find that storage-type is a field not defined in the schema, and the validation will fail.

[0142] At this point, the SHR mechanism is activated. An internal correction request is sent to the LLM: "The storage-type field in the last generated parameters is invalid. According to the schema, the valid field name should be storage_type. Please correct only this field and regenerate." Upon receiving the instruction, the LLM quickly returns a PIR object with only this field corrected. This process is completely transparent to the user, achieving system self-healing.

[0143] After receiving a resampling request carrying correction instructions, the target language model resamples the erroneous field described in the instructions. The model generates a new field value that has the same semantics as the erroneous field but conforms to the parameter structure. The system then performs compliance verification on the generated resampled field again to ensure that it meets all constraints defined in the interface schema.

[0144] If the compliance check of the parameter structure of the resampled field passes, the corresponding erroneous field in the initial structured parameters is replaced with the resampled field. This replacement process is automatic and does not require the user to re-enter information, thereby reducing dialogue rounds and improving the smoothness of the conversion from natural language requests to cloud API calls.

[0145] In an exemplary embodiment, the above-described exception handling mechanism based on the validation exception category further includes: when the validation exception category indicates that there is a semantic conflict between fields in the initial structured parameters, generating a semantic logic problem based on the semantic conflict; and automatically correcting the target field with the semantic conflict by intelligently solving the semantic logic problem.

[0146] In addition to the method of regenerating erroneous fields at specific points as described in the above embodiments, this application also provides an intelligent conflict resolution unit to handle situations where user-provided parameters may conflict with each other (e.g., selecting model A but specifying a type B hard drive that is not supported by that model). When the system detects such a logical contradiction, it will not immediately abandon or disturb the user, but will initiate an intelligent "conflict resolution" process. This process transforms the conflict into a logical puzzle, which is then solved by a dedicated solver to determine whether there exists an effective solution that is "closest" to the user's intent.

[0147] If a simple solution is found: the solver tells the system that only minimal modifications (e.g., replacing a Class B hard drive with a compatible Class C drive) are needed to resolve the conflict. The system will adopt this suggestion and trigger a "self-healing" mechanism, automatically correcting only the problematic parameter.

[0148] If the problem is unsolvable—for example, if the solver finds that no matter how many minor modifications it makes, it cannot satisfy all the rules—it indicates a fundamental contradiction in the user's intent. Only then will the system seek clarification from the user, requesting explicit instructions.

[0149] In this way, the system can intelligently resolve many internal parameter conflicts, speed up the self-repair process, and avoid raising unnecessary questions for the user.

[0150] In an exemplary embodiment, the above-described exception handling mechanism based on the validation exception category further includes: when the validation exception category indicates that some fields in the initial structured parameters are missing, matching a field missing query template from the question template; and filling in the missing fields based on the target answer obtained from the field missing query template to obtain the filled structured parameters.

[0151] To improve the efficiency and quality of clarification interactions, this embodiment employs a hybrid decision-making strategy of "template priority, model fallback." The system has a built-in clarification question library containing highly optimized question templates for common clarification scenarios (such as missing required fields, enumeration value selection, range exceeding limits, and mutual exclusion conflicts). Each template is accompanied by an `applicability_rule` for quickly matching the currently detected anomaly type. For example, for a field with a missing enumeration value, the system will match the corresponding template and dynamically populate the field name and optional value list based on the schema. Furthermore, the system records a deterministic "question-answer-parameter" mapping table for each template, allowing the user's answer to be directly and unambiguously backfilled into the dialogue state table.

[0152] The system only invokes the target language model's inference unit when no template is matched for a clarification scenario. It provides the model with the current dialogue context, detected ambiguities, and relevant schema information, allowing the model to generate a more natural and personalized clarification question. This hierarchical strategy ensures that most common clarifications can be resolved with maximum efficiency and minimum cost.

[0153] In other words, the embodiments of this application provide a hybrid ambiguity detector, which integrates rule-based and model-based methods to achieve high recall and high precision.

[0154] (1) Rule layer: Responsible for detecting deterministic, syntactic errors. This includes all issues found during the Parameter Consistency Check (PIC) process: missing required fields, data type mismatches, values ​​out of range or not in the enumeration list, and more complex mutual exclusion and dependency conflicts. Rule detection is fast and accurate, serving as the first line of defense against ambiguity.

[0155] (2) Model layer: Responsible for detecting nondeterministic, semantic ambiguity. In addition to analyzing the intent distribution entropy, this layer also uses the following two signals to enhance detection capabilities.

[0156] 1) n-best consistency signal: The language model inference unit can be configured to generate N best candidate parameter objects. The system checks the consistency of these N objects on key fields. If a significant inconsistency occurs (e.g., for the same user input, the cpu_cores values ​​of the three candidate objects are 2, 4, and 8 respectively), this inconsistency is used as a weighted signal to increase the overall ambiguity mentioned above.

[0157] 2) Field-level confidence output: When performing constrained structured generation (CSG), the language model inference unit is configured to output a confidence score (conf) for each generated slot (field). [0,1]. During the PIC phase, for fields with a confidence level below a certain threshold, even if their format is valid, the system can proactively mark them as potentially ambiguous and trigger clarification or self-healing resampling.

[0158] When any layer detects ambiguity due to missing fields and the ambiguity measure exceeds a preset threshold, a clarification process is triggered to ensure that the system's understanding is completely consistent with the user's intent before any operation is performed.

[0159] In other words, if the validation anomaly category indicates ambiguity among the parameters in the initial structured parameters, and the ambiguity metric exceeds a preset threshold, a clarification interaction process must be initiated. Specifically, by querying the target cloud interface's target parameter specifications, an inquiry template is obtained. This template is then populated with key question information related to the target access request, guiding the user to provide supplementary information to resolve ambiguity. For example, the target question might be, "To create an ESSD storage database instance for you in Availability Zone A, please provide the following information: database engine, instance specifications, storage space size," etc.

[0160] The ambiguity measure is calculated using a hybrid ambiguity detector and is used to measure the degree of ambiguity caused by the absence of multiple required fields.

[0161] If the ambiguity cannot be eliminated through the clarification interaction mechanism, repeat the entire process described above, which involves re-outputting using the target language model, parameter mapping processing, parameter validation, etc.

[0162] By accurately matching question templates and efficiently parsing user responses, automatic parameter completion was achieved, improving task success rate and user experience. This mechanism fully considers the balance between user cognitive load and information gain, optimizing the overall processing efficiency of the system by minimizing the number of clarification interactions.

[0163] Additionally, it should be noted that the clarification interaction mechanism in this embodiment may, but is not limited to, employing a dialogue-driven multi-turn interaction strategy. Specifically, it includes: when the initial structured parameters fail verification and the verification anomaly category indicates a logical contradiction in the initial structured parameters, constructing a target relationship graph representing the dependencies between the various structured parameters in the initial structured parameters based on the target parameter specification of the target cloud interface; performing multiple rounds of clarification interaction according to the topological relationship indicated by the target relationship graph; and correcting the initial structured parameters based on the result of the last round of interaction to obtain the corrected structured parameters.

[0164] In this embodiment, a more proactive dialogue strategy is employed to guide the interaction. Its core is a slot-dependent directed acyclic graph (DAG) automatically constructed based on the interface schema. This graph is used to represent the dependencies between parameters, optimizing the query order for multi-round clarification. In this graph, each node represents a parameter slot, and directed edges represent dependencies (e.g., the availability_zone node points to the subnet node because subnet selection depends on determining the availability zone first).

[0165] (1) Dependency-driven query order: During multi-round clarification, the system will ask questions along the topology of the DAG, prioritizing parent nodes without in-degree (such as regions and availability zones), and then asking child nodes that depend on them (such as subnets and mirrors). This strategy avoids invalid questions and logical backtracking after user answers, ensuring the one-wayness and efficiency of the dialogue.

[0166] (2) Merging Clarifications: Under the premise of following the DAG, if multiple parallel, non-dependent required slots are simultaneously missing (e.g., cpu_cores and memory_gb), the system is configured to merge the questions to them into one question ("How many CPU cores and how much memory are needed?"), as long as the total number of slots to be clarified does not exceed the cognitive load constraint k defined above. This further reduces the number of dialogue rounds.

[0167] Cognitive load constraint: The system controls the cost ceiling for the number of questions k to be merged and clarified in one time and the complexity of the answers (single choice / multiple choice / fill in the blank); when the estimated user cost exceeds the threshold, it automatically splits into a multi-round shortest path query sequence (based on DAG topology) to limit the average number of clarification rounds while ensuring completion.

[0168] The permission and isolation verification unit performs RBAC / ABAC matching verification on the resource identifier (project / tenant / VPC / subnet) in the parameters before execution. When the target resource is not within the caller's scope, the system prohibits execution and generates the minimum feasible alternative (such as switching to the same tenant's availability zone). This unit works in conjunction with high-risk operation classification to form a layered protection system.

[0169] The aforementioned mechanism demonstrates the flexibility and intelligence of the closed-loop conversion system in parameter correction. Even when faced with complex parameter dependencies and logical contradictions, the system can ensure that all parameters reach a fully compliant state through strategic clarification and correction, providing crucial technical support for achieving efficient conversion from natural language to cloud API calls. Through this mechanism, the system can more intelligently handle logical contradictions in user requests, ensuring the logical consistency and integrity of the final parameter set.

[0170] In the above-described verification anomaly handling process, this application embodiment also provides an anomaly and rollback strategy, because robust anomaly handling and rollback strategies are crucial to ensuring system reliability. This application also designs a response mechanism based on deterministic thresholds and traffic splitting rules.

[0171] (1) Formatting error or missing parameters: This is a relatively common exception, triggered by the ambiguity metric A>θ (threshold) defined above. The system will immediately initiate a clarification interaction to request the user to correct or supplement information. If the user chooses to give up during the clarification process or does not respond for a long time, the system will terminate the current interface call task and clear the relevant dialogue state.

[0172] (2) Interface Timeout or Failure: When a network timeout or an internal server error is returned during an API call to the backend cloud platform, the system will first record a detailed error log. Then, for idempotent operations (such as queries and updates), the system will adopt an automatic retry strategy. For non-idempotent operations such as creation and deletion, this application embodiment provides additional protection mechanisms, specifically including non-idempotent operation protection: before executing such operations, the system can be configured to force a dry-run (if the interface supports it) to verify the parameters. After a call failure, the system must perform an idempotent query to confirm whether the operation has unexpectedly produced side effects (e.g., whether the resource has already been created), thereby determining whether to retry or report the failure to the user.

[0173] (3) Parameter resampling failure and splitting: This is a self-healing and rollback mechanism for abnormal output of the Language Model (LLM) inference unit.

[0174] 1) Maximum SHR Count: The number of times Self-Healing Resampling (SHR) can be executed is limited by a configurable threshold N_max (e.g., 2 or 3). If parameters that pass the PIC cannot be generated after exceeding this number of times, resampling will stop.

[0175] 2) Dynamic traffic routing: The system monitors the SHR failure rate (FailRatio) of a specific interface over a period of time (e.g., 100 calls). If the FailRatio exceeds a certain threshold (e.g., 50%), it indicates that there is a persistent difficulty in generating parameters for that interface. The system will then switch directly to "form mode" or call a more powerful language model (LLM) inference unit instead of trying SHR first.

[0176] (4) Risk Classification of High-Risk Operations: For high-risk operations such as deletion and modification permissions, their interface schema can be marked as high-risk. When processing such requests, the system is configured to automatically add an "operation confirmation slot" in the clarification process, forcing users to explicitly answer "yes" or "no" to confirm their operation intention. Before obtaining explicit confirmation, the operation will be prohibited from being executed. Deletion / configuration type operations require secondary confirmation and (if available) successful dry-run before execution, and a confirmation hash log is recorded (for compliance evidence collection).

[0177] The technical solution proposed in this application is not only a theoretical framework, but also provides a feasible, step-by-step implementation, evolution and deployment path.

[0178] 1. Phased deployment.

[0179] Phase 1: Architecture Setup and Core Implementation. First, the basic framework of the system is built, including the interface schema management and registration mechanism, a schema-constrained parameter extraction module, the core parameter validation layer, and the dialogue state table. In this phase, the system can handle simple, fully-informed single-round requests.

[0180] Phase Two: Clarification Loop and Interactive Intelligence. This phase primarily involves integrating a hybrid ambiguity detector and a clarification question generation engine to achieve automatic detection and interactive clarification of missing and incorrect parameters. Upon completion of this phase, the system can handle multi-turn dialogues with incomplete information, forming a complete "request-detection-clarification-execution" closed loop.

[0181] Phase Three: Performance Optimization and Advanced Interaction. This phase introduces more advanced model optimization techniques, such as knowledge distillation of the language model's inference units to train smaller, faster, and more focused self-developed models, reducing inference costs and response latency. Simultaneously, it optimizes clarification strategies, supporting simultaneous clarification of multiple related slots (e.g., providing the server's CPU core count and memory size), and merging and ranking the N best candidate results from the model output to improve the accuracy of the preferred result.

[0182] Phase Four: Automated Evolution and Ecosystem Expansion. Establish an automated monitoring and adaptation mechanism for cloud platform API changes, achieving automatic schema updates and synchronization. Expand the system's service scope from a single private cloud environment to multi-cloud and hybrid cloud environments. By adapting APIs from different cloud vendors to corresponding schemas, manage heterogeneous cloud resources using a unified natural language interactive experience.

[0183] 2. Continuous learning and assessment.

[0184] To continuously improve the system's performance, this application also establishes a comprehensive continuous learning and evaluation mechanism.

[0185] (1) Data closed loop: The system anonymizes and records all historical dialogue data, interface call logs, and the final success or failure of the task. This real-world interaction data forms the basis for optimizing models and strategies.

[0186] (2) Offline evaluation set: Using the accumulated data, a high-quality offline evaluation set containing diverse scenarios and edge cases is constructed. This evaluation set contains triples of (natural language input, target interface, and ideal parameters in JSON) as the "gold standard" for model iteration.

[0187] (3) Counterfactual sample synthesizer: Based on historical dialogues, counterfactual samples with "parameter interference (synonyms / misspellings / unit variants) and structural interference (field missing / mutually exclusive conflicts)" are automatically generated; these are incorporated into offline regression and fine-tuning data to improve the system's robustness to long-tail expressions and interface changes. Failed samples within the current period (such as the last two weeks) are given priority weighting to form continuous adaptation.

[0188] (4) Offline autoregression and self-learning pipeline: This application embodiment also includes an offline self-learning pipeline, which is configured to meet the following requirements.

[0189] 1) Periodically (e.g., every night) automatically run a series of regression tests on the benchmark evaluation set, with metrics including at least: slot F1 score, structure validity rate, clarification-once resolution rate, end-to-end task success rate, and P95 response latency.

[0190] 2) When any key metric is detected to have dropped more than a preset threshold (e.g., 2%) relative to the previous version, the system will automatically mark the version as a performance rollback and trigger an alarm.

[0191] 3) The system will automatically replay the latest online problematic samples (e.g., conversations with many clarification attempts or failed SHR) onto the rolled-back model version to help locate the problem.

[0192] 4) Through weakly supervised learning and data augmentation techniques (e.g., synonym replacement, word order reversal, and noise addition to existing samples), more diverse colloquial training samples are automatically generated to fill in the long-tail distribution and to fine-tune or retrain a smaller language model dedicated to parameter extraction, thereby achieving continuous performance improvement and cost optimization.

[0193] In an exemplary embodiment, the above-mentioned invocation of the cloud service corresponding to the target cloud interface through the initial structured parameters includes: encapsulating the initial structured parameters into an interface invocation request; sending the interface invocation request to the cloud resource management platform and returning the request response status.

[0194] If all required parameters pass validation and are unambiguous, it will be triggered. Figure 3 The execution and feedback layer is shown. It is responsible for assembling the fully validated and organized parameters into a valid cloud interface API call request and sending it to the backend cloud resource management platform for execution.

[0195] During execution, this layer monitors the return status of the interface. If the call succeeds, it parses and formats the returned business data (such as the newly created virtual machine ID and IP address) and then passes it to the user interaction layer for display. If the interface call fails or times out, this layer catches torch exceptions and handles them according to a preset strategy (such as idempotent retry). If failures continue, it generates user-friendly error messages.

[0196] In another alternative example, assuming that, following the embodiments described above, the dialog state table has compiled a complete and validated set of parameters, the execution and feedback layer formats these parameters into a formal API call to the create_vm interface. The call is then sent to the cloud platform backend.

[0197] (1) Successful scenario: The backend successfully created the virtual machine and returned data containing information such as the virtual machine ID and IP address. The execution and feedback layer parses this data and generates a user-friendly message "Successfully created test server dev-test-server-01 for you, with IP address 192.168.1.000", which is then displayed to the user through the user interaction layer.

[0198] (2) Failure scenario: The backend returns an error, such as "Insufficient resources in the current availability zone". The execution and feedback layer will capture this error and translate it into language that the user can understand: "Sorry, the current computing resources in availability zone A are full and virtual machines cannot be created. You can try selecting another availability zone, or try again later." Depending on the type of error, the system may also automatically suggest alternative solutions, such as recommending an availability zone with available resources.

[0199] By employing the above methods, the system is able to translate user-verified and corrected parameters into actual cloud operations, thereby achieving seamless integration between user intent and the cloud resource management platform and providing users with an intuitive and efficient service experience.

[0200] In an exemplary embodiment, the method further includes: parsing and formatting the business data when the request response status indicates the return of business data, to obtain processed business data; sending the processed business data to the target terminal, and creating a database instance corresponding to the cloud service.

[0201] This embodiment primarily addresses the business data returned after a successful API call by the cloud resource management platform, introducing a parsing and formatting mechanism. When the API call request succeeds and returns business data, the system first performs structured parsing on this data to extract key information, such as the database instance ID, IP address, and creation time.

[0202] The extracted raw data is then formatted, transforming it into an easy-to-understand format, such as presenting database IDs and IP addresses as a clear list, or generating a text summary containing important information. This process ensures the readability and consumability of business data, facilitating the delivery of results to users in a user-friendly manner.

[0203] After being parsed and formatted, the business data is sent to the user's target terminal, which can be the user's device, cloud management control panel, or any interface for receiving results. This sending process ensures that the user can obtain the operation results in a timely and accurate manner, while providing intuitive feedback on the success of the operation, enhancing the user's trust in the system and their sense of confirmation of the operation.

[0204] By parsing and formatting business data and feeding the results back to the user, the integrity of the task loop and the optimization of the user experience are ensured. This is an indispensable step in the closed-loop conversion process, marking the successful completion of the entire conversion process and verifying the effectiveness and reliability of the system's conversion from natural language requests to cloud interface calls.

[0205] Through the above mechanism, efficient and intuitive interaction with users is achieved, ensuring that users can obtain task execution results in a timely and accurate manner. At the same time, the database instance creation operation within the system ensures the integrity and accuracy of operation records, providing a foundation for subsequent operation and maintenance management and auditing.

[0206] The above process not only demonstrates the automation and intelligence of the closed-loop transformation system in terms of result feedback, but also reflects the completeness of the system in terms of operation records and status management through the creation and updating of internal database instances, providing comprehensive technical support for the closed-loop transformation of cloud resource management.

[0207] In an exemplary embodiment, the method further includes: obtaining interface call exception information when the request response status indicates that the target cloud interface call failed; performing call retry processing based on the interface call exception information; and generating error message when the number of retries exceeds a preset threshold.

[0208] This embodiment plays a crucial role in handling scenarios where cloud API calls fail. When the system receives a request response status indicating that the target cloud API call has failed, the first step is to obtain detailed API call exception information. This exception information may include error codes, error descriptions, and reasons for failure, which are essential for understanding the cause of the call failure and provide a basis for subsequent error handling.

[0209] Based on the obtained interface call exception information, a call retry mechanism is introduced. This mechanism is particularly effective in handling transient network problems, brief unavailability of backend services, or temporary resource shortages. The system automatically determines whether to retry, as well as the number of retries and the interval, based on the nature and type of the exception information. Through call retries, the system can recover to a certain extent without requiring the user to re-initiate requests or perform additional operations.

[0210] If the target cloud API call still fails after reaching the preset retry limit, the system will generate a detailed error message and provide this information to the user through the user interaction layer. The error message not only includes the original exception information but may also provide possible solutions, alternative operation suggestions, or relevant technical support contact information so that the user can take appropriate action based on the error message. For example, re-outputting parameters using the target language model. This process emphasizes the importance of user experience, striving to provide sufficient information and guidance to users even in the event of a failed call, in order to minimize frustration and inconvenience.

[0211] Simultaneously, it can intelligently attempt multiple times when a call fails, improving the task success rate. If retries are unsuccessful, the system can provide detailed error information and solution suggestions, reducing the user burden and ensuring a smooth and efficient operation and maintenance process. This mechanism's design and implementation fully considers the complexity and volatility of cloud resource management scenarios, providing technical assurance for achieving highly stable and satisfactory cloud service calls.

[0212] Before sending the interface call request to the cloud resource management platform, the above method further includes: performing permission verification on the target account that sends the target access request through the target terminal, wherein the permission verification includes whether the target account has permission to use the cloud service.

[0213] To better understand the above interface call methods, the following will combine... Figure 4 The overall flowchart shown further describes it.

[0214] S402, the user inputs natural language commands.

[0215] S404 uses a target language model to understand and recognize instructions and extract preliminary parameters.

[0216] It is possible, but not limited to, through Figure 3 The semantic understanding layer shown above implements the parameter extraction process.

[0217] S406 uses an evaluation function to match the target cloud interface with the highest score from the interface list.

[0218] This matching process also utilizes... Figure 3 The semantic understanding layer shown is used to implement this, and the calculation process for the score of each cloud interface can be referred to the description in the above embodiments, which will not be repeated here.

[0219] S408 maps initial parameters to structured standard terms according to the interface contract of the best interface.

[0220] S410 performs parameter validation on the mapped structured parameter object.

[0221] This involves validating each field in the structured parameter object, including the field content, value range, inter-field dependencies, and whether there are any logical contradictions.

[0222] S412, determine whether the parameter verification passed.

[0223] If the test fails, proceed to step S414; otherwise, proceed to step S422.

[0224] S414 determines the type of the verification exception and executes different processing mechanisms based on the exception type.

[0225] S416. For problems such as occasional model errors / minor deviations that can be automatically corrected, self-healing resampling or other methods are used for correction.

[0226] S418, for errors that are not replaceable / safety boundaries, adopts a clarification interaction process.

[0227] Among them, the clarification interaction mainly addresses issues such as "information missing, uncertainty of true intent, ambiguity, or high-risk confirmation." These types of issues require verification from the user and are a key fallback mechanism for the system to avoid misoperation and ensure controllability in the production environment.

[0228] S420: After correcting or supplementing the erroneous fields or parameters that failed validation, perform parameter validation again.

[0229] After successful verification, proceed to step S422.

[0230] S422 calls the target cloud interface using verified structured parameters.

[0231] The technical effects of the embodiments of this application can be measured by a series of quantifiable acceptance indicators, including but not limited to the following:

[0232] (1) Parameter structure validity rate ≥ 99%: This indicator measures the proportion of parameter objects generated by CSG and verified by PIC that can pass the verification directly without SHR or clarification. It is the core indicator for measuring the structured output capability of this invention.

[0233] (2) Slot accuracy ≥ 96%: For a structurally valid parameter object, this indicator measures the proportion of all required slot values ​​that are exactly matched or equivalent to the manually labeled baseline values.

[0234] (3) The resolution rate of one-time clarification is ≥85%, and the false trigger rate of one-time clarification for high-risk operations is ≤1%. When the system triggers the clarification interaction, this indicator measures the proportion of tasks in which users can resolve all ambiguities or complete all missing information through one round of question and answer.

[0235] (4) Average number of clarification rounds ≤ 1.5: For all tasks that require clarification, the average number of dialogue rounds required to complete the task should not exceed 1.5 rounds, reflecting the efficiency of the interaction.

[0236] (5) End-to-end task success rate ≥ 90%: The overall task success rate from the user's initial request to the successful execution of the backend API and the return of the expected result.

[0237] (6) P95 response delay ≤ 2.5s (excluding backend API), clarification question generation delay P95 ≤ 600ms: In a single round of interaction, the 95th percentile delay from when the system receives user input to when it returns the next response (excluding backend API execution time).

[0238] (7) The regression pass rate within 24 hours after the interface evolution is ≥98% (covering the newly added / changed paths).

[0239] As can be seen from the descriptions of the above embodiments, the core parameter processing flow of the embodiments of this application is designed as a defined control closed loop, and a scoring function is used to solve the selection problem when multiple interfaces coexist.

[0240] The three-stage control closed loop includes: This closed loop ensures the quality of parameter generation, which is implemented as a finite state machine (FSM). This state machine is configured to precisely control the transitions of the parameter object from generation, verification, clarification to final execution. The states include at least {generation > verification > [resampling | clarification | execution] > end}.

[0241] (1) Constrained structured generation: This process is configured to force the language model inference unit to generate structurally valid parameter objects based on the schema of the target interface.

[0242] (2) Parameter consistency verification: This module is configured to perform deterministic verification and normalization of the type, format, range, enumeration and required fields of the generated parameter object according to the Schema.

[0243] (3) Self-healing resampling: This mechanism is configured to perform targeted resampling on the fields that failed the PIC verification when the PIC verification fails, in order to correct the error without disturbing the user. This process has a maximum limit (N_max). If the limit is exceeded, the process will proceed to the clarification interaction or rollback according to the strategy. If the PIC verification is successful, the process will proceed to the execution phase.

[0244] One of the technical effects achievable by the technical solution of this application is that, under a typical scale of thousands of interfaces, the parameter structure validity rate is no less than 99%, the end-to-end task success rate is improved by no less than 15%, and the average number of clarification rounds does not exceed 1.5. Furthermore, another technical effect of the technical solution of this application is that when the cloud interface evolves (such as adding parameters or changing enumeration values), the system does not need to modify the core code; it can achieve continuous adaptation to changes simply by updating its corresponding interface schema description.

[0245] To make the purpose, technical solution, and advantages of this application clearer, a detailed description of the technical solution will be provided below with reference to a specific embodiment. This embodiment uses the scenario of a user wanting to "create a high-IO-performance database instance for my web application in Availability Zone A" as an example to illustrate how the above-mentioned modules of the system work together.

[0246] Step 1: System initialization and schema loading.

[0247] When the system starts, the interface registry loads all defined cloud interface schemas. In this example, the system loads the schema for the create_rds_instance (create RDS instance) interface. This schema file (JSON format) defines the required parameters in detail.

[0248] For example, instance_name(string, optional): instance name; engine(string, required, enum:["mysql","postgresql"]): database engine; engine_version(string, required): engine version, whose value depends on the engine; instance_class(string, required): instance specification, which determines CPU and memory; storage_type(string, required, enum:["ssd","essd"]): storage type; storage_size(integer, required, range:[20,3000]): storage size (GB); availability_zone(string, required): availability zone ID; ags(object, optional): tags.

[0249] At the same time, the syntax constraint assembler compiles this schema into a context-free grammar (CFG), which will be injected into the LLM as a hard constraint during the decoding phase.

[0250] Step 2: Intent identification and interface selection.

[0251] The user enters a request through the interactive terminal: "Create a high-IO performance database instance for my web application in Availability Zone A".

[0252] The request is sent to the semantic understanding layer. After analysis by the LLM inference unit, the core intent is identified as "create a database instance". Through semantic matching, the system finds that the create_rds_instance interface has the highest confidence (e.g., 0.95), while other interfaces such as create_vm have very low confidence. Therefore, the system selects create_rds_instance as the target interface and prepares to use its corresponding schema and CFG.

[0253] Step 3: Constrained Structured Generation (CSG) and Parametric Intermediate Representation (PIR).

[0254] The system provides the user request along with the CFG of create_rds_instance to the LLM inference unit, instructing it to perform constrained structured generation.

[0255] (1) The LLM infers the relevant interface to be called based on the "database instance".

[0256] (2) “Availability Zone A” is identified by the entity and mapped to the standard ID, cn-Aa, with the help of the thesaurus.

[0257] (3) "High IO performance" is parsed and mapped to storage_type: "essd"` (ESSD is a higher performance SSD) based on the normalized mapping table or internal knowledge.

[0258] (4) "For my web application" is parsed as tags:{"app":"webapp"}.

[0259] (5) Under the constraints of CFG, LLM directly generates a structured Parametric Intermediate Representation (PIR) object.

[0260] It should be noted that several required fields, such as engine, instance_class, and storage_size, are still missing.

[0261] Step 4: Parameter Consistency Check (PIC) and Self-Healing Resampling (SHR).

[0262] The PIC module in the parameter validation layer directly validates the PIR object generated in the previous step or the final generated initial structured parameters. The validation of the PIR object will be explained as an example.

[0263] (1) Verification process: The PIC module checks the canonical value in the PIR according to the Schema. It finds that the values ​​of availability_zone and storage_type are both in the valid enumeration list and the types are correct.

[0264] (2) Problem found: The verification revealed that the four required fields, engine, engine_version, instance_class, and storage_size, were completely missing.

[0265] (3) SHR Scenario Simulation: To illustrate SHR, assume that there is a minor error in the output of the LLM in the previous step, for example, it generated "storage-type":"essd" (using hyphens instead of underscores). During validation, the PIC will find that storage-type is a field not defined in the schema, and the validation will fail. At this point, the SHR mechanism is activated. The system sends an internal correction request to the LLM: "The storage-type field in the last generated parameter is invalid. According to the schema, the valid field name should be storage_type. Please correct only this field and regenerate." After receiving the instruction, the LLM will quickly return a PIR object that only corrects this field. This process is completely transparent to the user, realizing the system's self-healing.

[0266] Step 5: Ambiguity detection and clarification interaction.

[0267] Returning to the main process, due to the absence of multiple required fields, the ambiguity metric calculated by the hybrid ambiguity detector far exceeds the threshold, necessitating the initiation of a clarification interaction.

[0268] 1. Constructing a Dependency Graph (DAG): The interaction layer constructs a dependency graph of parameters based on the schema, determining that `engine_version` depends on `engine`. Therefore, it is necessary to query `engine` first.

[0269] 2. Generate clarifying questions: Follow the principles of minimum clarification and merging clarifications. Ensure that there are no direct dependencies between engine, instance_class, and storage_size, and that the cognitive cost of querying these three parameters at once is within an acceptable range.

[0270] 3. Questions: The system asks questions to the user through the user interaction layer. The questions may be a combination of multiple choice and fill-in-the-blank questions. "Okay, an ESSD storage database instance will be created for you in Beijing Availability Zone A. Please continue to provide the following information."

[0271] (1) Database engine: [MySQL|PostgreSQL].

[0272] (2) Instance specification: [Please select or enter, such as rds.mysql.s1.small].

[0273] (3) Storage space size (GB): [Please enter a number between 20 and 3000].

[0274] Step 6: Dialogue state update and loop check.

[0275] After seeing the question, the user replied, "Use MySQL, select s1.small, and 50G of space."

[0276] 1. State Update: The system parses the user's response and updates the dialog state table and PIR object. The PIR object now contains "engine:"mysql", instance_class:"rds.mysql.s1.small", storage_size: 50".

[0277] 2. Re-verification: The PIC module is triggered again to verify the updated PIR. At this time, it finds that the engine_version field is still missing.

[0278] 3. Secondary Clarification: The system re-enters the clarification process. Since the engine has been determined to be MySQL, the system will query the schema to obtain a list of MySQL supported versions (such as ["5.7","8.0"]), and ask a more precise question: "Please select the MySQL version: [5.7|8.0]".

[0279] 4. After the user selects 8.0, the PIR is finally completed and passes the full PIC verification.

[0280] Step 7: Permission verification, execution, and feedback.

[0281] 1. Permission Verification: Before execution, the permission and isolation verification unit checks whether the current user has permission to create an RDS instance in the cn-Aa availability zone, the specified project, and the network environment. Verification passes.

[0282] 2. High-Risk Operation Confirmation (if applicable): If creating a database is a high-risk operation, the system will add an extra step to confirm, "Are you sure you want to create the MySQL database instance configured above? [Yes / No]". After user confirmation, the process continues.

[0283] 3. API Call: The execution and feedback layer assembles all canonical values ​​in the final PIR object into a fully valid "create_rds_instance" API request and sends it to the cloud platform backend.

[0284] 4. Result Feedback: The cloud platform successfully created the instance and returned the instance ID and connection address. The system formats this information and displays it to the user through the user interaction layer: "A MySQL 8.0 database instance has been successfully created for you. The instance ID is rds-00000. Please check its connection information later." If the execution fails (e.g., insufficient inventory), a user-friendly error message and suggestions will be returned.

[0285] Through the above implementation methods, this application embodiment transforms a vague and incomplete natural language request into a precise, complete, and secure API call through a closed-loop process of human-machine collaboration and self-repair, ultimately efficiently completing the user's task.

[0286] Compared with the prior art, the technical solution of this application brings at least the following beneficial effects.

[0287] (1) Improved accuracy of parameter extraction and task success rate: This application introduces Interface Schema as a hard constraint (CSG) during the language model generation stage, fundamentally eliminating structural errors in parameters (such as incorrect field names or type mismatches), resulting in a parameter structure validity rate of over 99%. Combined with closed-loop post-processing of Parameter Consistency Validation (PIC) and Self-Healing Resampling (SHR), it can automatically repair minor deviations that may occasionally occur in the model, further ensuring the correctness of parameter values. This dual insurance mechanism of "pre-constraint + post-self-healing" improves the end-to-end task success rate by more than 15% compared to the traditional "generate first, validate later" model.

[0288] (2) Improved efficiency of human-computer interaction and user experience: The clarification interaction mechanism of this application is intelligent and efficient. On the one hand, the self-healing resampling (SHR) mechanism can resolve a large number of internal errors without disturbing the user, avoiding unnecessary interactions. On the other hand, when clarification is necessary, the system, based on the parameter dependency graph (DAG) and the "minimum clarification" principle, can raise the most critical and logically ordered questions, and reduce the number of dialogue rounds by merging questions. This makes the average number of clarification rounds no more than 1.5, avoiding the aimless or repetitive questioning of traditional chatbots, and providing users with a smooth and efficient interactive experience.

[0289] (3) It achieves uninterrupted adaptive evolution of cloud interfaces, enhancing the robustness and maintainability of the system: The cloud platform API is continuously evolving. The technical solution of this application achieves high flexibility and adaptability by decoupling the interface definition from the core logic of the system. When the interface changes, maintenance personnel only need to update the corresponding interface schema file, and the system can automatically detect the change and adapt to the new parameter structure, constraints, and default values ​​without modifying any core code or retraining the model. This "hot update" capability ensures the continuity of system services and greatly reduces the cost of long-term development and maintenance.

[0290] (4) Enhanced security and compliance of cloud operations: The technical solution of this application incorporates key security checkpoints into the technical process. The pre-execution permission and isolation verification unit (RBAC / ABAC) ensures the compliance of user operations and prevents unauthorized access. The mandatory secondary confirmation mechanism for high-risk operations such as deletion and modification provides a final line of defense against accidental operations. These designs organically combine the convenience of natural language interaction with the security and seriousness required for enterprise-level applications, enabling the system to be securely applied in production environments.

[0291] (5) Reduced development threshold and cost for accessing new interfaces: By using a standardized interface schema as the core driver, the technical solution of this application provides a clear and low-cost path for accessing new cloud service APIs. Developers do not need to write complex parsing and validation code for each API; they only need to provide a schema description file that conforms to the specifications to quickly endow the system with new capabilities. This accelerates the expansion of system functions, enabling it to easily keep up with the rapid development of the cloud service ecosystem.

[0292] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0293] According to another aspect of the embodiments of this application, an interface calling device is also provided, the structural schematic diagram of which is shown below. Figure 5As shown, the system includes the following modules: a loading unit 502, used to load a target constraint file in response to a received target access request, wherein the target constraint file includes a formal specification of the semantics, structure, and inter-parameter dependencies of the structured parameters used in the cloud interface call process; a first processing unit 504, used to input the target access request into a target language model, output initial parameters, and map the initial parameters to initial structured parameters based on the target constraint file; a second processing unit 506, used to evaluate the degree of matching between the initial structured parameters and the standard parameter specifications of each cloud interface in the target constraint file, and match the target cloud interface from a predefined interface list based on the evaluation results; and a calling unit 508, used to verify the initial structured parameters based on the target parameter specifications corresponding to the target cloud interface, and, if the verification is successful, call the cloud service corresponding to the target cloud interface through the initial structured parameters.

[0294] The specific execution steps involved in the various calculation processes and dynamic optimization of storage space in the above modules can be referred to the description in the above embodiments, and will not be repeated here.

[0295] Obviously, the above-described interface calling device can be used to implement the interface calling method provided in the above embodiments, and will not be repeated hereafter. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0296] It should be noted that the loading unit 502 in this embodiment can be used to execute the above step S202, the first processing unit 504 in this embodiment can be used to execute the above step S204, the second processing unit 506 in this embodiment can be used to execute the above step S206, and the calling unit 508 in this embodiment can be used to execute the above step S208.

[0297] In an exemplary embodiment, the first processing unit 504 includes: a first acquisition module, configured to acquire explicit information in the target access request; and a first mapping module, configured to map the explicit information to a first type of parameter in the target lexicon, wherein the semantics and structure of each parameter in the target lexicon satisfy the formal specifications indicated by the target constraint file.

[0298] In an exemplary embodiment, the first processing unit 504 further includes: a second acquisition module, configured to acquire implicit information in the target access request; a parsing module, configured to parse the cloud resource requirements represented by the implicit information and map the cloud resource requirements to parameter slots defined in the target constraint file, wherein the parameter slots include a parameter name field, a parameter type field, and a parameter value field; and a filling module, configured to fill the parameter slots based on the parameter types and constraints defined in the target constraint file to obtain a second type of parameter, wherein the initial structured parameters include a first type of parameter and the second type of parameter.

[0299] In an exemplary embodiment, the second processing unit 506 includes: a third acquisition module, configured to sequentially acquire each cloud interface as the current cloud interface from the various cloud interfaces; a fourth acquisition module, configured to acquire the current similarity between the initial structured parameters and the current standard fields defined by the current standard parameter specification, wherein the current standard parameter specification is a formal specification of the current structured parameters used to call the current cloud interface; a first processing module, configured to determine the fill rate of key parameters in the parameter slots corresponding to the current cloud interface based on the initial structured parameters, wherein the fill rate represents the ratio between the number of filled parameters in the key parameters and the total number of key parameters; a fifth acquisition module, configured to acquire the historical call success rate of the current cloud interface within a historical period; and a second processing module, configured to determine the current evaluation result of the current cloud interface based on the current similarity, the fill rate, and the historical call success rate.

[0300] In an exemplary embodiment, the second processing module includes: a first acquisition submodule, configured to acquire the number of parameter supplementation interactions corresponding to the unfilled key parameters, wherein the number of parameter supplementation interactions represents the number of rounds of parameter follow-up questions required to complete the unfilled key parameters; a second acquisition submodule, configured to acquire the number of constraints in the constraints indicated by the current standard parameter specification where the initial structured parameters do not satisfy at least some of the constraints; and a first processing submodule, configured to perform weighted processing on the current similarity, the filling rate, the historical call success rate, the number of parameter supplementation interactions, and the number of constraints to obtain the current evaluation result.

[0301] In an exemplary embodiment, the second processing unit 506 includes: a sorting module, configured to sort the evaluation results of each cloud interface to obtain a sorting result; and a selection module, configured to select the top-ranked target evaluation result based on the sorting result, and match the target cloud interface from the interface list based on the target evaluation result.

[0302] In an exemplary embodiment, the above-mentioned calling unit 508 includes: a lookup module, configured to look up the target parameter specification from the target constraint file based on the target interface identifier of the target cloud interface; and a first verification module, configured to verify each field in the initial structured parameters based on the target parameter specification to obtain a verification result.

[0303] In an exemplary embodiment, the above-mentioned lookup module includes: a third acquisition submodule, configured to acquire the index relationship between a pre-created interface identifier and the parameter specification in the target constraint file; and a first query submodule, configured to find the target parameter specification from the target constraint file based on the target interface identifier and the index relationship.

[0304] In an exemplary embodiment, the first verification module includes a second processing submodule, configured to perform at least one of the following: sequentially obtaining each field from the initial structured parameters as a current field; comparing the field type of the current field with the target type defined in the target parameter specification to obtain a type verification result; verifying whether the field format of the current field meets the standard format defined in the target parameter specification to obtain a format verification result; verifying whether the current value of the current field is within the value range defined in the target parameter specification to obtain a value range verification result; and, if the current field is a key parameter, determining the filling state of the current field, wherein the filling state indicates whether the current field is missing.

[0305] In one exemplary embodiment, the above apparatus further includes: a third processing unit, configured to execute an exception handling mechanism based on the verification exception category if the initial structured parameters are not verified based on the target parameter specification.

[0306] In an exemplary embodiment, the third processing unit includes: a first sending module, configured to send a resampling request carrying a correction instruction to a target language model when the verification anomaly category indicates that the parameter structure of the initial structured parameters is non-compliant, wherein the correction instruction is used to describe an erroneous field in the previously output initial structured parameters; a second processing module, configured to resample the target access request using the target language model and re-output a resampled field with the same semantics and parameter slot as the erroneous field; and a replacement module, configured to replace the erroneous field in the initial structured parameters with the resampled field when the parameter structure of the resampled field passes compliance verification.

[0307] In an exemplary embodiment, the third processing unit includes: a third processing module, configured to generate a semantic logic problem based on the semantic conflict when the verification anomaly category indicates that there is a semantic conflict between the fields in the initial structured parameters; and a first correction module, configured to automatically correct the target field with the semantic conflict by intelligently solving the semantic logic problem.

[0308] In an exemplary embodiment, the third processing unit includes: a matching module, configured to match a field-missing query template from the question template when the verification anomaly category indicates that some fields in the initial structured parameters are missing; and a fourth processing module, configured to fill in the missing fields based on the target answer obtained from the field-missing query template, to obtain the filled structured parameters.

[0309] In an exemplary embodiment, the above apparatus further includes: a construction module, configured to, when the initial structured parameters fail verification and the verification anomaly category indicates that the initial structured parameters have logical contradictions, construct a target relationship graph representing the dependency relationships between the various structured parameters in the initial structured parameters based on the target parameter specification of the target cloud interface; and a second correction module, configured to perform multiple rounds of clarification interactions according to the topological relationships indicated by the target relationship graph, and correct the initial structured parameters based on the result of the last round of interactions to obtain corrected structured parameters.

[0310] In an exemplary embodiment, the above-mentioned calling unit 508 includes: an encapsulation module, used to encapsulate the initial structured parameters into an interface call request; and a second sending module, used to send the interface call request to the cloud resource management platform and return a request response status.

[0311] In an exemplary embodiment, the above apparatus further includes: a fourth processing unit, configured to parse and format the business data to obtain processed business data when the request response status indicates the return of business data; and a sending unit, configured to send the processed business data to a target terminal and create a database instance corresponding to the cloud service.

[0312] In one exemplary embodiment, the above apparatus further includes: an acquisition unit, configured to acquire interface call exception information when the request response status indicates that the target cloud interface call has failed; a fifth processing unit, configured to perform call retry processing based on the interface call exception information; and a sixth processing unit, configured to generate error message information when the number of retries exceeds a preset threshold.

[0313] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0314] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the interface invocation method embodiments described above.

[0315] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to execute the steps in any of the above-described interface invocation method embodiments at runtime.

[0316] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0317] According to another aspect of the embodiments of this application, a computer program product is also provided, the computer program product including a computer program, which, when executed by a processor, implements the steps in any of the above-described interface call method embodiments.

[0318] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described interface call method embodiments.

[0319] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0320] The above provides a detailed description of an interface invocation method provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. An interface invocation method, characterized in that: include: In response to the received target access request, a target constraint file is loaded, wherein the target constraint file includes a formal specification of the semantics, structure, and inter-parameter dependencies of the structured parameters used in the constraint cloud interface call process; By inputting the target access request into the target language model, initial parameters are output, and the initial parameters are mapped to initial structured parameters based on the target constraint file; Evaluate the degree of matching between the initial structured parameters and the standard parameter specifications of each cloud interface in the target constraint file, and match the target cloud interface from the predefined interface list based on the evaluation results; The initial structured parameters are verified based on the target parameter specifications corresponding to the target cloud interface, and if the verification is successful, the cloud service corresponding to the target cloud interface is called through the initial structured parameters. The evaluation of the matching degree between the initial structured parameters and the standard parameter specifications of each cloud interface in the target constraint file includes: sequentially obtaining each cloud interface as the current cloud interface from the various cloud interfaces; obtaining the current similarity between the initial structured parameters and the current standard fields defined by the current standard parameter specification, wherein the current standard parameter specification is the formal specification of the current structured parameters used to call the current cloud interface; determining the fill rate of key parameters in the parameter slots corresponding to the current cloud interface based on the initial structured parameters, wherein the fill rate represents the ratio between the number of filled parameters in the key parameters and the total number of key parameters; obtaining the historical call success rate of the current cloud interface in the historical period; obtaining the number of parameter supplementation interactions corresponding to unfilled key parameters, wherein the number of parameter supplementation interactions represents the number of parameter follow-up rounds required to complete the unfilled key parameters; obtaining the number of constraints in the constraints indicated by the current standard parameter specification that are not satisfied by the initial structured parameters; and weighting the current similarity, the fill rate, the historical call success rate, the number of parameter supplementation interactions, and the number of constraints to obtain the current evaluation result.

2. The method according to claim 1, characterized in that, The process of mapping the initial parameters to initial structured parameters based on the target constraint file includes: Obtain explicit information from the target access request; The explicit information is mapped to a first type of parameter in the target lexicon, wherein the semantics and structure of each parameter in the target lexicon satisfy the formal specifications indicated by the target constraint file.

3. The method according to claim 1, characterized in that, The process of mapping the initial parameters to initial structured parameters based on the target constraint file includes: Obtain implicit information from the target access request; Parse the cloud resource requirements represented by the implicit information and map the cloud resource requirements to the parameter slots defined in the target constraint file, wherein the parameter slots include a parameter name field, a parameter type field, and a parameter value field; Based on the parameter types and constraints defined in the target constraint file, the parameter slots are filled to obtain a second type of parameter. The initial structured parameters include both the first type of parameter and the second type of parameter.

4. The method according to claim 1, characterized in that, The process of matching the target cloud interface from a predefined list of interfaces based on the evaluation results includes: The evaluation results of each cloud interface are sorted to obtain the sorting results; Based on the sorting results, the top-ranked target evaluation results are selected, and the target cloud interface is matched from the interface list based on the target evaluation results.

5. The method according to claim 1, characterized in that, The verification of the initial structured parameters based on the target parameter specification corresponding to the target cloud interface includes: Based on the target interface identifier of the target cloud interface, the target parameter specification is found in the target constraint file; Based on the target parameter specification, each field in the initial structured parameters is validated to obtain the validation results.

6. The method according to claim 5, characterized in that, The process of finding the target parameter specification from the target constraint file based on the target interface identifier of the target cloud interface includes: Obtain the index relationship between the pre-created interface identifier and the parameter specifications in the target constraint file; Based on the target interface identifier and the index relationship, the target parameter specification is found from the target constraint file.

7. The method according to claim 5, characterized in that, The validation of each field in the initial structured parameters based on the target parameter specification includes at least one of the following: Each field is sequentially obtained from the initial structured parameters as the current field; The type verification result is obtained by comparing the field type of the current field with the target type defined in the target parameter specification; Verify whether the field format of the current field meets the standard format defined in the target parameter specification, and obtain the format verification result; Verify whether the current value of the current field is within the value range defined in the target parameter specification, and obtain the value range verification result; When the current field is a key parameter, the fill status of the current field is determined, wherein the fill status is used to indicate whether the current field is missing.

8. The method according to claim 1, characterized in that, The method further includes: If the initial structured parameters fail to be validated based on the target parameter specification, an exception handling mechanism is executed based on the exception category.

9. The method according to claim 8, characterized in that, The exception handling mechanism based on the exception category includes: If the verification anomaly category indicates that the parameter structure of the initial structured parameters is non-compliant, a resampling request carrying a correction instruction is sent to the target language model, wherein the correction instruction is used to describe the erroneous fields in the previously output initial structured parameters; The target access request is resampled using the target language model, and a resampled field with the same semantics and parameter slots as the error field is re-output. If the parameter structure of the resampled field is validated for compliance and passes the validation, the erroneous field in the initial structured parameters is replaced with the resampled field.

10. The method according to claim 8, characterized in that, The exception handling mechanism based on the exception category also includes: If the validation anomaly category indicates a semantic conflict between fields in the initial structured parameters, a semantic logic problem is generated based on the semantic conflict. By intelligently solving the semantic logic problem, the target field with the semantic conflict can be automatically corrected.

11. The method according to claim 8, characterized in that, The exception handling mechanism based on the exception category also includes: If the verification anomaly category indicates that some fields in the initial structured parameters are missing, a field missing query template is matched from the question template; Based on the target answer obtained from the missing field query template, the missing field is filled in to obtain the structured parameters after filling in the missing field.

12. The method according to claim 1, characterized in that, The method further includes: If the initial structured parameters fail verification and the verification anomaly category indicates that there is a logical contradiction in the initial structured parameters, a target relationship graph is constructed based on the target parameter specification of the target cloud interface to represent the dependency relationship between the various structured parameters in the initial structured parameters. According to the topological relationships indicated by the target relationship graph, multiple rounds of clarification interactions are performed, and the initial structured parameters are corrected based on the results of the last round of interactions to obtain the corrected structured parameters.

13. The method according to claim 1, characterized in that, The step of calling the cloud service corresponding to the target cloud interface through the initial structured parameters includes: The initial structured parameters are encapsulated into an interface call request; Send the API call request to the cloud resource management platform and return the request response status.

14. The method according to claim 13, characterized in that, The method further includes: If the request response status indicates that business data has been returned, the business data is parsed and formatted to obtain processed business data; The processed business data is sent to the target terminal, and a database instance corresponding to the cloud service is created.

15. The method according to claim 13, characterized in that, The method further includes: If the request response status indicates that the target cloud interface call failed, obtain the interface call exception information; Based on the interface call exception information, call retry processing is performed; If the number of retries exceeds a preset threshold, an error message will be generated.

16. An electronic device, comprising: include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the interface invocation method as described in any one of claims 1 to 15.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the interface invocation method as described in any one of claims 1 to 15.

18. A computer program product comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the interface invocation method as described in any one of claims 1 to 15.

Images