Target path determination method and device, storage medium, electronic equipment and product

Abstract

The application discloses a target path determination method and device, a storage medium, and an electronic device and product, relates to the technical field of cloud computing, and comprises the following steps: matching a plurality of interface nodes that meet a query request from an interface knowledge graph, the plurality of interface nodes being in a corresponding relationship with a plurality of intents corresponding to the query request; taking the plurality of interface nodes as starting points, presetting a node depth as a traversal scale, and determining a plurality of extended interface nodes that have a first dependency relationship with the plurality of interface nodes from the interface knowledge graph; establishing a candidate subgraph based on the plurality of interface nodes, the plurality of extended interface nodes, and a second dependency relationship existing between the plurality of extended interface nodes; and counting a plurality of interface calling paths existing in the candidate subgraph, and determining a target path from the plurality of interface calling paths through a scoring model. The application solves the problems that the number of interfaces of a cloud management platform is large, the dependency relationship is complex, a traditional retrieval method is difficult to accurately understand user intents, and path planning is inaccurate.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and more specifically, to a method, apparatus, storage medium, electronic device, and product for determining a target path. Background Technology

[0002] In existing automated API call solutions for cloud management platforms, the common approach is to respond to user natural language commands by either using keyword-based document retrieval or directly calling an LLM (Large Language Model) for "tool selection." The former relies on manually written API (Application Programming Interface) documentation, which can only match interfaces at a coarse-grained level using keywords and cannot understand the logical relationships between intents, making it difficult to handle complex tasks with multiple steps and parameter dependencies. While the latter introduces the semantic understanding capabilities of the LLM, its planning process is a one-time, unstructured black-box generation, lacking the ability to model explicit dependencies between APIs. The generated call sequences often fail due to missing prerequisite operations, inability to pass parameters, or violations of execution order, and it lacks path evaluation and optimization mechanisms, making it impossible to select the optimal solution from multiple candidate solutions.

[0003] There is currently no effective solution to the problem that cloud management platform interfaces are numerous and have complex dependencies, and that traditional retrieval methods are unable to accurately understand user intent, leading to inaccurate path planning. Summary of the Invention

[0004] This application provides a method, apparatus, storage medium, electronic device, and product for determining a target path, in order to at least solve the problems in related technologies such as the large number of cloud management platform interfaces, complex dependencies, and the difficulty of accurately understanding user intent using traditional retrieval methods, which lead to inaccurate path planning.

[0005] According to one embodiment of this application, a method for determining a target path is provided, comprising: matching multiple interface nodes that match a query request from an interface knowledge graph, wherein the multiple interface nodes correspond to multiple intents corresponding to the query request; using the multiple interface nodes as the starting point and a preset node depth as the traversal scale, determining multiple extended interface nodes that have a first dependency relationship with the multiple interface nodes from the interface knowledge graph; establishing a candidate subgraph based on the multiple interface nodes, the multiple extended interface nodes, and a second dependency relationship between the multiple extended interface nodes; statistically analyzing multiple interface call paths existing in the candidate subgraph, and determining a target path from the multiple interface call paths using a scoring model.

[0006] According to another embodiment of this application, a target path determination device is provided, comprising: a matching module, configured to match multiple interface nodes that match a query request from an interface knowledge graph, wherein the multiple interface nodes correspond to multiple intents corresponding to the query request; a first determination module, configured to determine multiple extended interface nodes that have a first dependency relationship with the multiple interface nodes from the interface knowledge graph, using the multiple interface nodes as the starting point and a preset node depth as the traversal scale; a building module, configured to build a candidate subgraph based on the multiple interface nodes, the multiple extended interface nodes, and a second dependency relationship between the multiple extended interface nodes; and a second determination module, configured to count multiple interface call paths existing in the candidate subgraph and determine the target path from the multiple interface call paths using a scoring model.

[0007] According to yet another embodiment of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, and the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0008] According to yet another embodiment 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 above method embodiments.

[0009] According to yet another embodiment of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0010] This application identifies multiple semantic intents from user query requests and matches them with corresponding initial API nodes in the interface knowledge graph, achieving a semantic association between intents and interfaces. Then, starting from these initial nodes and using a preset traversal depth as a scale, it actively explores extended interface nodes in the interface knowledge graph that have a direct "first dependency relationship" (such as execution prerequisites). Based on this, it integrates the initial nodes, extended nodes, and their mutual "second dependencies" (such as sequential, parallel, or parameter passing constraints) to construct a candidate subgraph covering the complete business process. Finally, the system enumerates all feasible interface call paths in the subgraph and, combined with a multi-factor scoring model considering semantic relevance, execution cost, permission matching, and parameter completeness, comprehensively evaluates and selects the optimal target path. This technical solution solves the problem of inaccurate path planning caused by the large number of interfaces and complex dependencies in cloud management platforms, and the difficulty of accurately understanding user intent using traditional retrieval methods. Then, by matching the initial interface node corresponding to the user's intent through the interface knowledge graph, a subgraph with structured dependencies is expanded at a preset depth, generating and scoring multiple candidate execution paths, thereby intelligently selecting the optimal target path and achieving accurate and structured automated task planning. Attached Figure Description

[0011] 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.

[0012] Figure 1 This is a hardware structure block diagram of a server device for a method of determining a target path according to an embodiment of this application;

[0013] Figure 2 This is a flowchart of a method for determining a target path according to an embodiment of this application;

[0014] Figure 3 This is a schematic diagram of a cloud management platform interface dependency modeling and dynamic path planning system architecture based on an interface knowledge graph, according to an embodiment of this application.

[0015] Figure 4 This is a schematic diagram of a cloud management platform interface dependency modeling and dynamic path planning method based on interface knowledge graph according to an embodiment of this application;

[0016] Figure 5 This is a system architecture block diagram with a caching mechanism according to an embodiment of this application;

[0017] Figure 6This is a structural block diagram of a target path determination device according to an embodiment of this application; Detailed Implementation

[0018] 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.

[0019] 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.

[0020] 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.

[0021] As an optional implementation, the method embodiments provided in this application can be executed on a server device or a similar computing device. Taking running on a server device as an example, Figure 1 This is a hardware structure block diagram of a server device according to an embodiment of the present application for a method of determining a target path. Figure 1 As shown, the server device may include one or more ( Figure 1 Only one is shown in the image. A processor 102 (which may include, but is not limited to, a microprocessor MPU 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.

[0022] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the target path determination 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.

[0023] 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.

[0024] This embodiment provides a method for determining a target path, applied to the aforementioned server device. Figure 2 This is a flowchart of a method for determining a target path according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:

[0025] Step S202: Match multiple interface nodes that match the query request from the interface knowledge graph, wherein the multiple interface nodes correspond to multiple intents corresponding to the query request;

[0026] Step S204: Starting from the multiple interface nodes, and using the preset node depth as the traversal scale, determine multiple extended interface nodes that have a first dependency relationship with the multiple interface nodes from the interface knowledge graph.

[0027] Optionally, the first dependency relationship is the "dependsOn" relationship, which represents that the execution of one interface requires the successful invocation of another interface as a prerequisite. In step S204, the system starts with multiple initial API nodes matched by the user intent, and expands outward along directed edges to their direct predecessor nodes according to the predefined "dependencies" relationships in the interface knowledge graph, thereby identifying the extended interface nodes necessary to complete the intent that have not yet been explicitly mentioned by the user. For example, when the initial node is "createServer", the system identifies through the "dependencies" relationship that it must depend on two extended nodes, "queryNetwork" and "queryFlavor", to ensure that the parameters are complete and the execution prerequisites are met. The core function of this relationship is to achieve complete intent completion and prevent the path from becoming unexecutable due to the omission of prerequisite operations.

[0028] Step S206: Based on the plurality of interface nodes, the plurality of extended interface nodes, and the second dependency relationship between the plurality of extended interface nodes, establish a candidate subgraph;

[0029] Optionally, the second dependency relationship is the "input-output mapping" relationship and the "depends-on" relationship between extended interface nodes, which is used to characterize the data flow or collaborative execution logic between multiple extended interface nodes. In step S206, based on the determined initial node and extended nodes, the system further analyzes whether there are parameter passing paths (such as the output of one interface serving as the input of another interface) or execution order constraints (such as the sequential dependency relationship between multiple extended nodes), thereby constructing a candidate subgraph with a complete causal chain and data flow. For example, the output field "network_id" of the "query network" interface is automatically bound to the input parameter of the "create virtual machine" interface through the "input mapping" relationship, while there is a "dependency" relationship between the two extended nodes "create storage volume" and "mount storage volume", forming a serial link. The core function of this relationship is to organize isolated nodes into a logically rigorous directed acyclic graph with automatic parameter passing, ensuring that the generated path is not only complete but also truly executable.

[0030] Step S208: Count the multiple interface call paths existing in the candidate subgraph, and determine the target path from the multiple interface call paths using a scoring model.

[0031] The above method identifies multiple semantic intents from user query requests and matches them with corresponding initial API nodes in the interface knowledge graph, achieving a semantic association between intents and interfaces. Then, starting from these initial nodes and using a preset traversal depth as a scale, the system actively explores extended interface nodes in the interface knowledge graph that have a direct "first dependency relationship" (such as execution prerequisites). Based on this, the system integrates the initial nodes, extended nodes, and their mutual "second dependencies" (such as sequential, parallel, or parameter passing constraints) to construct a candidate subgraph covering the complete business process. Finally, the system enumerates all feasible interface call paths in the subgraph and, combined with a multi-factor scoring model considering semantic relevance, execution cost, permission matching, and parameter completeness, comprehensively evaluates and selects the optimal target path. This technical solution solves the problems of a large number of interfaces and complex dependencies in cloud management platforms, where traditional retrieval methods struggle to accurately understand user intent, leading to inaccurate path planning. Then, by matching the initial interface node corresponding to the user's intent through the interface knowledge graph, a subgraph with structured dependencies is expanded at a preset depth, generating and scoring multiple candidate execution paths, thereby intelligently selecting the optimal target path and achieving accurate and structured automated task planning.

[0032] In an exemplary embodiment, matching multiple interface nodes that match a query request from an interface knowledge graph includes: encoding multiple intents corresponding to the query request to obtain a first semantic vector; calculating the similarity between the first semantic vector and a second semantic vector corresponding to each interface node in the interface knowledge graph to obtain multiple similarity scores; identifying interface nodes with similarity scores greater than a preset similarity threshold as candidate interface nodes to obtain multiple candidate nodes; and further processing the multiple candidate nodes based on a preset multi-dimensional filtering strategy to obtain the multiple interface nodes.

[0033] Understandably, if a user inputs a natural language query: "Create a virtual machine with 2 cores and 4GB of memory for the development environment and bind it to a public IP address," the system first encodes the core intents "create virtual machine" and "bind public IP address" in the query into a first semantic vector using a pre-trained BERT (Bidirectional Encoder Representations from Transformers) model. This first semantic vector is then compared with the second semantic vector pre-stored in the interface knowledge graph (such as createServer, allocatePublicIp, rebootServer, etc.), generated based on their interface summaries and parameter descriptions, to obtain multiple similarity scores. Candidate nodes with similarity scores higher than 0.70 are selected, including createServer (0.91), allocatePublicIp (0.87), and createNetwork (0.72). Subsequently, a multi-dimensional filtering strategy is used for further refinement, resulting in multiple interface nodes that serve as the starting point for subsequent path planning.

[0034] In summary, by implementing the above methods, user query intent is encoded into a semantic vector and similarity matching is performed by combining it with the semantic representation of interface nodes in the knowledge graph. Then, irrelevant or low-reliability nodes are removed through a multi-dimensional filtering strategy, which improves the accuracy of interface matching and context awareness, and realizes intelligent mapping from fuzzy natural language to high-confidence executable interfaces.

[0035] In an exemplary embodiment, the plurality of candidate nodes are further processed based on a preset multi-dimensional filtering strategy to obtain the plurality of interface nodes, including: determining a plurality of keywords for a plurality of intents corresponding to the query request, and a plurality of business domain tags corresponding to a plurality of candidate nodes in the interface knowledge graph; counting business domain tags containing at least one of the plurality of keywords to obtain a plurality of target tags; and determining the plurality of interface nodes based on the candidate nodes corresponding to the plurality of target tags.

[0036] Optionally, if a user enters the query "Create a 2-core, 4GB cloud host for the development environment and bind it to a public IP address", the system first obtains a set of candidate nodes through semantic retrieval, including createServer, allocatePublicIp, createNetwork, and rebootServer. Then, it extracts the keywords "create", "cloud host", and "public IP address" from the query and matches them against the business domain tags associated with each candidate node in the interface knowledge graph (e.g., createServer "computing domain", allocatePublicIp "network domain", createNetwork "network domain", rebootServer "computing domain"). Statistical analysis shows that "create" matches "cloud host" to "computing domain", and "public IP address" matches "network domain". Therefore, the candidate nodes createServer and allocatePublicIp, belonging to the "computing domain" and "network domain" respectively, are selected. createNetwork, although belonging to the "network domain", lacks a description related to "binding IP address", and rebootServer is irrelevant to the intent, and are therefore eliminated. Finally, only createServer and allocatePublicIp, which are semantically strongly associated with the keywords and precisely correspond to the business domain, are retained as the target interface nodes.

[0037] In summary, by implementing the above methods, the keywords in the query intent are semantically matched with the business domain tags of the interface nodes, accurately filtering out interface nodes that are functionally related and consistent with the domain. This effectively filters out redundant nodes that are semantically similar but functionally different, thus improving the accuracy and efficiency of path planning.

[0038] In an exemplary embodiment, before matching multiple interface nodes matching the query request from the interface knowledge graph, the method further includes: if the query request is the first request issued by the target object, extracting semantic entities from the query request, and combining structured intent units based on the semantic entities, wherein each structured intent unit includes an operation intent and the interface input parameters corresponding to the operation intent; determining the number of combinations of the structured intent units, and counting the number of logical connectives used to connect multiple intents contained in the query request; determining the complexity level corresponding to the query request through the number of combinations and the number of connections, and selecting a path planning strategy corresponding to the complexity level.

[0039] In other words, when a user first enters a query into the system: "Create a virtual machine with 2 cores, 4GB of RAM, and a 100GB system disk for the development team, then bind it to a public IP address and add a 50GB data disk," the system detects that this is the first request in the user's session and immediately initiates the intent structured process: through named entity recognition and regular expression matching, it extracts the semantic entities "2 cores, 4GB of RAM," "100GB system disk," "public IP address," "50GB data disk," and "development team," and constructs three structured intent units based on these: {Operation: Create virtual machine,} Parameters: cpu=2, ram=4GB, disk=100GB}, {Operation: Bind public IP, parameter: server_id=to be filled}, {Operation: Create and mount data disk, parameter: size=50GB}; Simultaneously, the system identifies that the query contains two logical connectives, "then" and "and", indicating a sequential and parallel combination of three intents; based on "3 intent units" and "2 connectives", the system determines the request to be of "high complexity" level, and then triggers a multi-path subgraph expansion and Directed Acyclic Graph (DAG) construction strategy, initiating a depth graph traversal to discover pre-dependent nodes such as queryFlavor, queryNetwork, and createVolume, and generating a complete execution path with parallel branches; in contrast, if the user only enters "query virtual machine list", the system will identify it as a low-complexity request of "single intent, no connectives", and directly adopt a lightweight single-interface call strategy.

[0040] In summary, by analyzing the number of structured intent units and the complexity of logical connectors in the initial query, the complexity level of user intent is intelligently identified, and an appropriate path planning strategy is dynamically selected. This achieves an adaptive balance between lightweight and fast response for low-complexity requests and deep intelligent planning for high-complexity tasks, thereby improving system efficiency and user experience.

[0041] In an exemplary embodiment, determining the complexity level of the query request based on the number of combinations and the number of connections includes: determining the query type of the query request as a simple query when the number of combinations is not zero and the number of connections is zero; and determining the query type of the query request as a complex query when the number of combinations is not zero and the number of connections is not zero.

[0042] In simple terms, if a user enters the query "Query all running virtual machines" for the first time, the system extracts a single structured intent unit: "Action: Query virtual machines, Parameter: Status (Running)", with a combination count of 1. The query does not contain logical connectives such as "then", "and", or "simultaneously", so the connection count is 0. The system thus determines it as a "simple query". However, when the user enters "Create a 2-core 4GB virtual machine, then bind it to a public IP address, and mount a 50GB data disk", the system identifies three structured intent units, including the connectives "then" and "and", with a connection count of 2 and a combination count of 3. The system then determines it as a "complex query".

[0043] In summary, through the above implementation methods, based on the simple binary rule of the number of intent combinations and the number of logical connectors, the complexity level of user queries can be accurately distinguished, and the intelligent diversion of lightweight single-step operations and multi-step collaborative tasks can be achieved, thereby improving system response efficiency and resource utilization.

[0044] In one exemplary embodiment, the process of statistically analyzing multiple interface call paths existing in the candidate subgraph and determining a target path from these multiple interface call paths using a scoring model includes: extracting path parameters from the multiple interface call paths according to multiple scoring factors in the scoring model to obtain multiple sets of scoring parameters; wherein the multiple scoring factors include: semantic relevance, path cost, permission matching degree, and parameter completeness; performing weighted summation on the multiple sets of scoring parameters to obtain multiple scoring results; and determining the target path based on the multiple scoring results.

[0045] In simple terms, the system generates multiple candidate interface call paths that meet user intents based on the interface knowledge graph. For each path, it extracts four key parameters: semantic relevance (whether it accurately matches the user intent), path cost (calculated by weighting latency and failure rate), permission matching degree (whether the user has the right to execute), and parameter completeness (whether the required parameters can be automatically completed), forming a score set. Then, it performs a weighted summation of each set of parameters according to preset weights to obtain a comprehensive score for each path. Finally, it selects the path with the highest score as the target path, realizing intelligent and multi-dimensional automatic selection of the optimal execution plan.

[0046] In summary, through the above implementation methods, a weighted evaluation mechanism that integrates four-dimensional scoring factors—semantic relevance, path cost, permission matching degree, and parameter completeness—intelligently selects the optimal call path that balances intent accuracy, execution efficiency, security compliance, and parameter completeness, thereby improving the intelligence, reliability, and practicality of cloud management task planning.

[0047] In one exemplary embodiment, the path cost among the plurality of scoring factors is equal to the latency weight multiplied by the sum of the average latency of all interfaces on the path, plus the failure rate weight multiplied by the sum of the failure rates of all interfaces.

[0048] In simple terms, path cost is calculated by weighting the "time overhead" and "failure risk" of all interfaces on the path: the latency weight is multiplied by the sum of the average response times of all interfaces to reflect the execution speed; the failure rate weight is multiplied by the sum of the failure probabilities of all interfaces to reflect the execution stability; the sum of the two is the comprehensive path cost, and the lower the cost, the better the path.

[0049] In an exemplary embodiment, the multiple sets of scoring parameters are weighted and summed to obtain multiple scoring results, including: determining a first weight corresponding to the semantic relevance parameter, a second weight corresponding to the path cost parameter, a third weight corresponding to the permission matching parameter, and a fourth weight corresponding to the parameter completeness parameter in each set of scoring parameters; calculating a first product value of the semantic relevance parameter and the first weight, a second product value of the path cost parameter and the second weight, a third product value of the permission matching parameter and the third weight, and a fourth product value of the parameter completeness parameter and the fourth weight; summing the first product value, the second product value, the third product value, and the fourth product value to obtain a scoring result corresponding to each set of scoring parameters; and summing the scoring results corresponding to each set of scoring parameters to obtain the multiple scoring results.

[0050] Optionally, if the system generates two candidate paths for the user to "create a virtual machine with a public IP address": Path A and Path B, the scoring parameters for each path are extracted: Path A has a semantic relevance of 0.95, path cost of 0.22, permission matching score of 1.0, and parameter completeness of 1.0; Path B has a semantic relevance of 0.78, path cost of 0.15, permission matching score of 1.0, and parameter completeness of 0.6. The system uses preset weights: first weight (semantic) 0.4, second weight (cost) 0.3, third weight (permission) 0.15, and fourth weight (completeness) 0.15. The following scores were calculated: Path A score = 0.95 × 0.4 – 0.22 × 0.3 + 1.0 × 0.15 + 1.0 × 0.15 = 0.584; Path B score = 0.78 × 0.4 – 0.15 × 0.3 + 1.0 × 0.15 + 0.6 × 0.15 = 0.467.

[0051] In summary, through the above implementation methods, the four scoring dimensions of semantic relevance, path cost, permission matching degree and parameter completeness are weighted and summed. The system then performs a comprehensive score on each candidate path, achieving multi-objective, quantitative and comparable path optimization.

[0052] In one exemplary embodiment, determining the target path based on the plurality of rating results includes: sorting the rating values ​​corresponding to the plurality of rating results by size and determining the largest rating value in the sorted results; and determining the interface call path associated with the largest rating value as the target path.

[0053] Understandably, when a user inputs the natural language command "Create a virtual machine with 2 cores, 4GB of memory, and a public IP address for the development environment," the system generates three candidate paths through the interface knowledge graph: Path A is "Query network → Query image → Create virtual machine → Bind public IP address," Path B is "Query image → Create virtual machine → Bind public IP address" (missing network query), and Path C is "Query specifications → Create virtual machine → Bind public IP address" (specification parameters do not match). The system calculates a weighted score for each of the three paths: Path A scores 92 points due to high semantic matching, complete parameters, compliant permissions, and a high historical success rate; Path B scores 78 points due to low completeness caused by missing network parameters; Path C scores 83 points because its semantic relevance decreases due to inconsistency with the user's specification description of "2 cores and 4GB of memory." After sorting the three paths by score, the system identifies Path A as having the highest score (92 points) and thus determines it as the target path.

[0054] In summary, by implementing the above methods, the path with the highest score is selected as the target path to achieve intelligent decision-making, ensuring that the selected execution plan has the best overall performance and improving the planning accuracy.

[0055] In an exemplary embodiment, after determining the interface call path associated with the maximum score value as the target path, the method further includes: obtaining the execution order, dependencies, and parameter information to be set for each node in the target path; converting the target path into a directed acyclic graph based on the execution order, dependencies, and parameter information, and using the directed acyclic graph as the target execution plan; and scheduling the execution of the interface call according to the target execution plan.

[0056] Optionally, once the system determines that "query network → query specification → create virtual machine → bind public IP" is the highest-scoring target path, it immediately extracts the execution order (which must be executed in sequence), dependencies (e.g., "binding public IP" depends on "creating virtual machine" to complete and return the virtual machine ID), and the parameter information required by each node in this path (e.g., "creating virtual machine" requires the image ID and specification ID, while "binding public IP" requires the virtual machine ID from the previous step). Subsequently, the system constructs a DAG based on this information: each node represents an API call (e.g., createServer, attachEIP), edges represent the dependency flow, and parameters are automatically bound to downstream nodes through "input mapping" relationships. The above DAG is encapsulated into the final target execution plan and is scheduled for execution by the execution engine in topological order: first, queryNetwork is called to obtain the network ID, then queryFlavor is called to obtain the specification ID, then createServer is called with these parameters to obtain the server_id, and finally the server_id is automatically passed as input to the attachEIP interface to complete the public IP binding. The entire process requires no manual intervention, achieving an end-to-end closed loop from intent to secure, orderly, and automated execution.

[0057] In summary, by implementing the above methods, the optimal path is transformed into a directed acyclic graph (DAG) with a clear structure and explicit dependencies as an execution plan, thus achieving orderly, parallel, and automated scheduling of interface calls. This ensures that the task execution logic is rigorous, resource dependencies are controllable, and operating efficiency is optimal.

[0058] In an exemplary embodiment, after transforming the target path into a directed acyclic graph based on the execution order, the dependencies, and the parameter information, and using the directed acyclic graph as the target execution plan, the method further includes: performing parameter integrity verification on the target execution plan to obtain a verification result; if the verification result indicates that there are missing parameters in the target execution plan, generating a query request based on the description information of the missing parameters in the interface knowledge graph, wherein the query request is used to request the target object to supplement the value of the missing parameters.

[0059] In simple terms, when the optimal path generated by the system based on the interface knowledge graph is "query network → query specifications → create virtual machine → bind public IP", the system performs parameter integrity verification on the DAG before execution. It finds that the "create virtual machine" node is missing the required image ID parameter. The system then queries the description information of this parameter in the interface knowledge graph (such as "used to specify the operating system image, optional values: A and B"), and calls the language generation module to automatically generate a natural language clarification request: "Please select the operating system image used to create the virtual machine: A or B". This question is pushed to the user interface in real time. After the user replies, the system automatically completes the parameters and continues to execute subsequent calls.

[0060] In summary, through the above implementation methods, the system intelligently verifies the integrity of parameters in the execution plan and automatically generates natural language clarification requests based on the interface knowledge graph. While ensuring the accuracy of task execution, the system also improves the user-friendliness of human-computer interaction and avoids execution failures caused by missing parameters.

[0061] In an exemplary embodiment, after scheduling the execution of the interface call according to the target execution plan, the method further includes: if any interface call in the target execution plan fails, querying the interface knowledge graph for a preceding node that has a compensation relationship with the failed node; and sequentially calling the compensation interface corresponding to the preceding node in reverse order of the target execution plan to restore the state before the execution of the target execution plan.

[0062] In other words, when the system sequentially calls "Create Virtual Machine" → "Bind Public IP" according to the DAG execution plan, if "Bind Public IP" ultimately fails due to network timeout, the execution engine immediately triggers an automatic rollback mechanism: it queries the "compensation with" relationship of the failed node in the interface knowledge graph and finds that the compensation operation of its corresponding predecessor node "Create Virtual Machine" is "Delete Virtual Machine"; then the system executes the compensation action in reverse order along the DAG, automatically calls the deleteServer interface and passes in the ID of the created virtual machine, successfully removes the semi-finished resource, and rolls the system state back to the pure state before the task started.

[0063] In summary, through the above implementation methods, automatic reverse rollback is achieved based on the predefined "compensation with" relationship in the interface knowledge graph. When the task execution fails, the system can accurately and efficiently restore the resource state, ensuring the atomicity of multi-step operations and system consistency, and improving the reliability and security of cloud environment operation and maintenance.

[0064] In an exemplary embodiment, before scheduling the execution interface call according to the target execution plan, the method further includes: generating a unique idempotent key for all write operation nodes marked as non-idempotent in the target execution plan; binding the idempotent key with the corresponding interface call parameters, execution timestamp, and identity identifier of the target object, and storing it in an idempotent key log library; and, in the case where the target object repeatedly initiates the same intent query in different sessions, identifying historical successful execution records by comparing with the idempotent key log library, and directly returning the original execution result.

[0065] Understandably, when a user submits the command "create a 2-core, 4GB virtual machine and mount a 100GB system disk" twice in different sessions, the system automatically generates a unique idempotent key (e.g., UUID: id-7a8b9c) for the non-idempotent `createServer` operation before the first execution. This key is then bound to the request parameters, execution timestamp, and user identity and stored in the idempotent key log. When the second request arrives, the system compares the log and finds that the idempotent key already exists and the corresponding operation was successful. It immediately determines this as a duplicate request, avoids repeatedly calling the backend interface, and directly returns the ID of the first successfully created virtual machine and the response result. In summary, through the above implementation method, automatically generating and binding a unique idempotent key for non-idempotent write operations can accurately identify and intercept duplicate requests, achieving idempotency protection across sessions, effectively preventing duplicate resource creation or accidental modification, and improving operational security and consistency.

[0066] In an exemplary embodiment, when the query request is a second request issued by the target object, the context reference information carried in the query request is obtained, wherein the context reference information is used to point to the operation intent in the first query request; the new operation intent is determined based on the context reference information and the session semantic cache information corresponding to the context reference information, and subgraph expansion is performed only on the new operation intent in the interface knowledge graph.

[0067] Optionally, when a user first requests to "create a virtual machine with 2 cores and 4GB of memory", the system completes the planning and executes the request successfully, and stores the generated virtual machine ID (e.g., server-uuid-123) and the selected execution path in the current session semantic cache. Subsequently, in the second request, the user inputs "add a 50GB data disk to it". The system recognizes "it" as a contextual pronoun through natural language understanding, and combines it with historical information in the session semantic cache to accurately locate the referent pointing to the first-created virtual machine server-uuid-123. Thus, it determines that the intent of this new operation is only "create and mount a data disk". At this time, the system no longer performs a full graph search on the entire interface knowledge graph, but only targets the two new nodes "createVolume" and "attachVolume", using server-uuid-123 as known input, and performs local subgraph expansion to quickly construct an incremental execution path.

[0068] In summary, by implementing the above methods, the contextual reference information is parsed using session semantic caching, and local subgraph expansion is performed only for newly added operation intentions. This improves the efficiency and response speed of path planning in multi-round interactions, while reducing computational overhead and semantic ambiguity, and ensuring the continuity of operations and a smooth and natural user experience.

[0069] In an exemplary embodiment, before matching multiple interface nodes that match the intent corresponding to the query request from the interface knowledge graph, the method further includes: extracting multiple interface semantic nodes from the interface documents of the cloud management platform; constructing semantic association edges based on the business logic associations and data dependencies between the multiple interface semantic nodes, wherein the semantic association edges include at least one of the following: a first semantic association edge for indicating the order of interface execution, a second semantic association edge for indicating the parameter passing path between interfaces, and a third semantic association edge for indicating the correspondence between write operation interfaces and reverse operation interfaces; and constructing the interface knowledge graph based on the interface semantic nodes and the semantic association edges.

[0070] Optionally, the OpenAPI documentation of the cloud management platform is first parsed to extract semantic nodes for interfaces such as createServer (create virtual machine), queryNetwork (query network), attachVolume (attach storage volume), and deleteServer (delete virtual machine). Semantic enhancement is then applied to their summaries, parameters, and response structures to generate corresponding vector representations. Subsequently, based on business logic analysis, three types of core semantic association edges are constructed: a first semantic association edge, "depends on," is established between queryNetwork and createServer, indicating that a network query is required before creating a virtual machine; a second semantic association edge, "input mapping," is established between the server_id response field of createServer and the server_id input parameter of attachVolume to enable automatic parameter passing; and a third semantic association edge, "compensates with," is established between createServer and deleteServer to provide a logical basis for subsequent rollback. Finally, these semantic nodes and the three types of association edges are integrated into a structured, semantically rich interface knowledge graph, enabling subsequent query requests (such as "create virtual machine with network") to accurately match candidate interfaces based on the entity relationships in the interface knowledge graph.

[0071] In summary, through the above implementation methods, semantic nodes are extracted from the interface documents, and structured semantic association edges are constructed based on the three major business logics of execution dependency, parameter flow, and operation compensation, thereby transforming scattered API information into a reasonable and executable intelligent interface knowledge graph.

[0072] In an exemplary embodiment, the interface knowledge graph includes a hot update mechanism, which includes: when a change is detected in the interface document of the cloud management platform, parsing the changed interface document to obtain a parsing result; based on the parsing result, performing at least one of the following operations on the corresponding interface nodes and semantic association edges in the interface knowledge graph: adding, modifying, or marking as deprecated; and establishing a version mapping relationship between the interface nodes marked as deprecated and the new version nodes.

[0073] Optionally, when the cloud management platform upgrades from V2.1 to V2.2, its OpenAPI documentation marks the original interface / servers / {id} / start (starting a virtual machine) as "deprecated" and adds a new interface / servers / {id} / actions / start with consistent semantics but more standardized parameters. The system's backend hot update mechanism monitors the changes in the document's hash value in real time, then parses the added and deprecated content, marks the original startServer node as "deprecated" in the interface knowledge graph, and creates a new startServerV2 node, establishing an explicit version mapping relationship (deprecatedFor:startServerV2) between the two. In addition, it automatically updates all "dependency" relationship edges and "input mapping" paths that depend on this operation, ensuring that existing path planning such as "starting a virtual machine and binding an IP" can still adapt to the new interface through version mapping. The entire update process is completed in the background without service interruption. Users and upper-layer applications can still call the original interface name, and the system intelligently routes to the new version, thereby ensuring the real-time performance, compatibility, and operational continuity of the interface knowledge graph.

[0074] In summary, through the above implementation methods, changes to the cloud management platform interface documents are automatically parsed, nodes and related edges in the interface knowledge graph are dynamically updated, and the addition, modification, or marking of obsolete nodes is supported. A mapping relationship between obsolete nodes and new version nodes is established, realizing uninterrupted hot updates and smooth version evolution of the interface knowledge graph.

[0075] To facilitate understanding of the implementation methods of this application, relevant scenarios are explained below, but these explanations do not limit the scope of this application.

[0076] In related technologies, when dealing with complex API orchestration in cloud management platforms, there are common problems such as shallow intent understanding, static planning processes, and lack of execution guarantees. Traditional methods based on keyword matching or manual document review cannot capture the multi-step business intent implied in natural language, and can only return a fragmented list of interfaces, making it difficult to build a complete execution chain. Although some solutions attempt to use large language models for tool invocation, their planning is a one-time, memoryless, single-round inference, which cannot identify the contextual dependencies in subsequent user commands (such as "add a disk to the virtual machine just now"), resulting in the need to replan from scratch and low efficiency. More seriously, these solutions generally ignore fault tolerance and consistency in the execution process, lack idempotency control for write operations and automatic rollback mechanisms based on semantic relationships, and failure in any link may lead to the interruption of the entire task.

[0077] Optionally, in a private or hybrid cloud environment, the cloud management platform serves as the core management hub, providing a vast number of API interfaces for configuring, operating, and monitoring underlying resources such as computing, networking, storage, and databases.

[0078] Optionally, an API (Application Programming Interface) is a collection of functions, methods, or protocols provided by a platform or system for interaction with external applications or other components.

[0079] Optionally, Large Language Models (LLMs) are a type of pre-trained language models that acquire powerful language capabilities through pre-training. Pre-training is a strategy for training deep learning models, the core of which lies in using large-scale datasets to initially train the model, enabling it to learn general feature representations. This process is similar to the basic learning stage humans undergo before learning new knowledge, accumulating experience through extensive reading and observation.

[0080] To avoid the aforementioned problems, as an optional implementation method, this application proposes a knowledge graph-based cloud management platform interface dependency modeling and dynamic path planning method and system. The core of this technical solution lies in constructing an interface knowledge graph that integrates semantic relationships and runtime attributes. Through three key relationships—"dependence," "input mapping," and "compensation with"—it transforms fragmented APIs into a structured network with execution order, parameter passing, and transaction rollback logic. After receiving a natural language query, the system first locates the intent-related interface nodes through semantic vector matching, then traverses the graph at a preset depth, dynamically expanding candidate subgraphs containing pre-, post-, and parallel nodes. Based on a multi-factor scoring model including semantic relevance, execution cost, permission matching, and parameter completeness, it selects the optimal execution chain from multiple candidate paths, ultimately generating a directed acyclic graph driven by the execution engine. During execution, parameters are automatically inherited, idempotent keys are injected to prevent duplicate operations, and in the event of failure at any node, a reverse rollback is intelligently triggered based on the "compensation with" relationship, achieving highly reliable atomic task delivery. Simultaneously, it combines session semantic caching to achieve path reuse and incremental planning under multi-round interactions, overcoming the bottlenecks of semantic barriers, static planning, and fragile execution in traditional methods.

[0081] Optionally, a knowledge graph (KG) is a technique that uses graph structures to model the relationships between knowledge and entities, and is the semantic foundation of this application (equivalent to the interface knowledge graph in this application).

[0082] Optionally, a Directed Acyclic Graph (DAG) is a graph structure where nodes represent tasks, directed edges represent dependencies between tasks, and there are no cycles in the graph. This application uses it to represent the final interface call plan.

[0083] Optional, Figure 3 This is a schematic diagram of a cloud management platform interface dependency modeling and dynamic path planning system architecture based on knowledge graph, according to an embodiment of this application. The architecture includes at least: a knowledge graph construction layer 30, a query parsing layer 32, a path retrieval and planning layer 34, a parameter completion and execution layer 36, and an optimization and monitoring layer 38.

[0084] Optionally, a knowledge graph construction layer 30 is constructed. By automatically parsing the OpenAPI and other interface documents of the cloud management platform, static attributes (such as operation names, parameters, and permissions) and dynamic runtime data (such as latency and success rate) of the API are extracted, and the semantics of the nodes are enriched by named entity recognition and semantic embedding technology. Furthermore, three types of core relationship edges, namely "dependent on", "input mapping" and "compensation with", are constructed to transform the scattered APIs into a domain-aware knowledge network with execution order, parameter flow and transaction rollback logic, providing a structured semantic foundation for the entire system.

[0085] Optionally, Named Entity Recognition (NER) is a natural language processing technique that is primarily used to automatically identify entities with specific meanings from text, such as names of people, places, organizations, or domain-specific terms (such as "virtual machine").

[0086] Optionally, query parsing layer 32. After receiving the user's natural language query, it accurately extracts the operation intent and key parameters through named entity recognition, synonym normalization, and semantic vector encoding. It combines domain dictionary and regular rules to identify structured entities such as IP (Internet Protocol) and UUID. It adopts a two-stage strategy of semantic retrieval and keyword filtering to efficiently recall multiple starting point API nodes most relevant to the user's intent in the knowledge graph, realizing a precise mapping from fuzzy semantics to computable graph query entry points.

[0087] Optionally, a UUID (Universally Unique Identifier) ​​is a 128-bit number used to uniquely identify information in a computer system, often used to generate idempotent keys or resource IDs.

[0088] Optional, path retrieval and planning layer 34. This layer first uses the starting node output by the query parsing layer 32 as the core, performs k-hop graph traversal, and dynamically expands to candidate interface nodes that have dependencies or parameter passing relationships with it, constructing a subgraph containing complete execution logic; then, based on a multi-factor scoring model such as semantic relevance, path cost (latency and failure rate weighted), permission matching degree, and parameter completeness, it comprehensively sorts all potential call paths, and finally transforms the optimal path into an executable directed acyclic graph, and combines it with session semantic caching to realize incremental planning and path reuse in multi-turn dialogues.

[0089] Optional, Parameter Completion and Execution Layer 36. This layer schedules API calls based on the DAG blueprint, automatically inheriting the required parameters from the responses of preceding nodes according to the "input mapping" relationship; for missing required parameters, it intelligently generates clarifying natural language questions to guide the user to complete them; for non-idempotent write operations, it injects a unique UUID idempotent key to prevent duplicate creation; when any node fails to execute, it actively queries the "compensation with" relationship in the knowledge graph, triggering a reverse call to the compensation interface of the preceding operation to achieve automated and atomic transaction rollback, ensuring resource state consistency.

[0090] Optional, the optimization and monitoring layer 38. This layer continuously collects user query, path selection, execution results, and feedback data. Through offline learning and reinforcement mechanisms, it dynamically optimizes the weights of the path scoring model and the knowledge graph structure. At the same time, it monitors core KPIs such as path coverage, end-to-end latency, token consumption, task success rate, clarification rate, and rollback success rate, forming a closed-loop system of "execution-feedback-learning-iteration" to ensure that the system continuously improves its intelligence level and operational efficiency in long-term operation.

[0091] Optionally, KPI (Key Performance Indicator) is a quantitative indicator used to measure the performance of a system or process on a specific objective, such as path coverage and task success rate in this application.

[0092] Optional, Figure 4 This is a flowchart illustrating a knowledge graph-based cloud management platform interface dependency modeling and dynamic path planning method according to an embodiment of this application, specifically including the following steps:

[0093] Step 1: Construct a multidimensional semantic knowledge graph. The specific construction process includes the following steps:

[0094] Step 1.1: API Node Extraction and Attribute Enrichment. By parsing the interface definition documents of the cloud management platform, the core information of each API is identified and extracted to construct semantic entity nodes representing the interface functions in the knowledge graph. This includes the following steps:

[0095] Step 1.1.1: The system automatically parses industry-standard interface description files (such as OpenAPI / Swagger format), extracting the core static attributes of each API as the foundational data for building API nodes in the knowledge graph. These attributes include, but are not limited to:

[0096] (1) Operation ID: A unique identifier for the interface, such as createServer or getNetworkDetails.

[0097] (2) Summary and Description: A high-level summary and detailed description of the interface functions, which are key inputs for subsequent semantic understanding.

[0098] (3) Request path and method: The URL (Uniform Resource Locator) path of the interface (e.g., / servers / {server_id} / action) and the HTTP method (e.g., POST, GET).

[0099] Optionally, HTTP (Hypertext Transfer Protocol) is an application layer protocol for distributed, collaborative, and hypermedia information systems. It is the foundation of web data communication and the primary protocol for API calls.

[0100] (4) Parameters: A detailed list of parameters, each of which includes its name, location (path, query, header, request body), whether it is required, data type (such as string, integer, boolean), and format constraints.

[0101] (5) Input / output structure (Schema): The JSON structure definition of the request body and response body clarifies the input and output format of the data.

[0102] Optionally, JSON (JavaScript Object Notation) is a lightweight data interchange format that is easy for humans to read and write, and also easy for machines to parse and generate. It is widely used in API request and response bodies.

[0103] (6) Security Tags: The user role or permission scope required to execute this interface, such as project:admin or domain:reader.

[0104] Step 1.1.2: To enhance the semantic expressive power of API nodes, the system introduces natural language processing technology to perform deep semantic analysis on the interface summary and description text. The specific process is as follows:

[0105] Through a named entity recognition model, the system automatically identifies and labels key entities highly relevant to the cloud computing domain, such as "virtual machine," "IP address," "storage volume," and "UUID," and standardizes them as semantic entities in a knowledge graph. Simultaneously, the system incorporates an extensible domain synonym mapping table, unifying semantically equivalent expressions such as "virtual machine," "cloud host," and "instance" under the same internal concept identifier, effectively eliminating terminological ambiguity and improving the robustness of intent matching. Furthermore, for fixed enumeration values ​​appearing in interface parameters (such as virtual machine status: ACTIVE, SHUTDOWN, ERROR), the system automatically extracts and stores them as node attributes in a structured manner, providing precise constraints for subsequent parameter validation, semantic completion, and intelligent interaction.

[0106] Step 1.1.3: The system generates a semantic embedding vector for each API node. This vector is calculated by inputting textual information such as the node's summary, description, and operation name into a pre-trained language model (such as BERT or other Transformer models). The calculated vector captures the core function and intent of the interface, serving as the basis for subsequent semantic similarity calculation and retrieval.

[0107] Optionally, BERT (Bidirectional Encoder Representations from Transformers) is a pre-trained language model based on the Transformer architecture, which is good at capturing deep semantic information of text and can be used to generate semantic embedding vectors in this application.

[0108] Optional, pre-trained language models generally refer to language model training tasks designed based on large-scale corpora (including language training materials such as sentences and paragraphs). A large-scale neural network algorithm structure is trained to learn and implement the model, and the resulting large-scale neural network algorithm structure and parameters constitute the pre-trained language model. Subsequent tasks can then be performed on this model, with feature extraction or task fine-tuning to achieve specific objectives. The idea behind pre-training is to first train a set of model parameters for one task, then use these parameters to initialize the network model parameters, and finally use the initialized network model to train other tasks, obtaining models adapted for those tasks. By pre-training on large-scale corpora, neural language representation models can learn powerful language representation capabilities, extracting rich syntactic and semantic information from text. Pre-trained language models can provide tokens with rich semantic information and sentence-level features for downstream tasks. They can also be fine-tuned directly on the pre-trained model for downstream tasks. This means that small-scale training is performed on specific task objectives (downstream tasks) and task data (downstream data) to make minor adjustments to the parameters of the pre-trained model, ultimately resulting in a model adapted to specific tasks and data.

[0109] It should be noted that the neural network algorithm structure used to train the pre-trained language model can be CNN (Convolutional Neural Network), RNN (Recurrent Neural Network), LSTM (Long Short-Term Memory), etc., or it can be a model built with attention networks, such as Transformer, BERT (Bidirectional Encoder Representations from Transformers), GPT (Generative Pre-trained Transformer), CLIP (Contrastive Language-Image Pre-training). This application does not impose any limitations on this. Here, attention network refers to a network model trained using an attention mechanism. This model extracts more important feature information from the input sequence by assigning different weights to each part of the input sequence, resulting in a more accurate output.

[0110] Step 1.2: Relationship Modeling and Construction. Define and construct edges between API nodes, connecting isolated interfaces into a knowledge network with logical relationships. For typical business characteristics in cloud management platforms such as strong dependencies between interfaces, parameter flow, and transaction compensation, several key edge types are defined, as follows:

[0111] (1) "dependsOn" relationship: This means that the successful invocation of one interface is contingent upon the successful invocation of another interface. This is a strong sequential constraint. For example, the attachVolume (mount storage volume) interface depends on the createServer (create virtual machine) interface because a virtual machine instance must exist before a storage volume can be mounted on it. This relationship can usually be found in business process documents or by analyzing interface call logs.

[0112] (2) "belongsToDomain" relationship: The interface is divided into different business domains according to its function, such as "computing domain", "network domain", "storage domain" etc. This helps to perform preliminary scope screening during path planning and quickly narrow down the set of candidate interfaces. For example, both createServer and rebootServer belong to the "computing domain".

[0113] (3) Input-Output Mapping Relationship: This is key to achieving automatic parameter passing. This relationship connects two interfaces and indicates that the output parameter of one interface can be used directly or after simple transformation as the input parameter of another interface. For example, the response body of the createServer interface contains server_id, while the path parameter of the getServerDetails (query virtual machine details) interface requires server_id. The system will construct an input-output mapping relationship from createServer to getServerDetails and mark the source parameter (output.body.server.id) and target parameter (input.path.server_id) of the mapping.

[0114] (4) "compensatesFor" relationship: Defines the rollback or undo operation of the write operation interface. For example, the deleteServer (delete virtual machine) interface compensatesFor the createServer interface. This relationship is the basis for implementing automatic rollback after a task chain failure.

[0115] It should be noted that the sources of relationships are diverse: some can be automatically extracted from the descriptions in the interface documentation through rules or models; others, especially critical business process dependencies, can be supplemented and reviewed by analyzing operation and maintenance scripts, orchestration templates (such as Heat, Terraform), or by introducing manual annotations from domain experts to ensure the accuracy of the knowledge graph.

[0116] Step 1.3: Dynamic Attributes and Version Management. To make path planning more intelligent and closer to actual operation, the knowledge graph nodes not only contain static descriptions but also integrate dynamically changing runtime attributes. The system connects to a monitoring system and periodically or in real-time updates the following information for each API node:

[0117] (1) Frequency: How frequently the interface is called.

[0118] (2) Average Latency: The statistical value of interface response time (e.g., P95 / P99).

[0119] (3) Success Rate: The ratio of successful to failed API calls.

[0120] (4) Cost Estimation: For operations that require a large amount of computing or storage resources, their execution costs can be estimated.

[0121] In summary, the aforementioned dynamic attributes are crucial inputs to the path ranking and scoring function, enabling the system to favor interface paths that have historically demonstrated greater stability and faster performance. Furthermore, the system supports interface version management. When cloud management platform upgrades lead to interface changes, older versions of nodes and relationships can be marked as "Deprecated" and associated with newer versions, ensuring the evolution and backward compatibility of the knowledge graph.

[0122] Step 1.4: Hot Update Mechanism. To ensure that the knowledge graph and the cloud management platform remain synchronized, a hot update mechanism is designed. This mechanism continuously monitors the storage location of the interface documents (such as a code repository or file server) through a background service. Once a change is detected in a document (such as a change in the hash value of the file content), an incremental update process is triggered. This process parses the changed interface parts and creates, modifies, or marks nodes and relationships in the knowledge graph accordingly.

[0123] It should be noted that the above update operation is performed on a temporary, background copy of the knowledge graph. After completion, an atomic switch operation (similar to blue-green deployment) is used to point the online service to the new knowledge graph version. The entire process is transparent to the upper-layer application and does not interrupt the service.

[0124] Step 2: Semantic-driven Intention Understanding and Dynamic Location of Query Starting Point. Convert the natural language query input by the user into a machine-understandable structured intention, and determine the starting point for retrieval in the knowledge graph. Specifically, it includes the following steps:

[0125] Step 2.1: Natural Language Understanding and Intention Recognition. When receiving a user query, such as "Find all virtual machines in the Beijing area that are in the running state and restart them", first perform the following steps on this query request:

[0126] Step 2.1.1: Preprocessing. Perform standard operations such as text cleaning, word segmentation, and stop word removal. Specifically, preliminarily organize the query request input by the user, remove irrelevant words (such as "of", "already", "them"), split the query request into individual words or phrases, clean up garbled characters or extra spaces, and lay a foundation for subsequent analysis.

[0127] Step 2.1.2: Entity Extraction. Use the aforementioned named entity recognition model and regular expressions to accurately extract key information entities from the query. For example, in the above query request, the region: "Beijing", the status: "running", and the operation: "restart" can be identified. For entities with strong format features such as IP addresses and UUIDs, regular expressions can provide efficient and accurate recognition.

[0128] Step 2.1.3: Synonym Normalization. With the help of a domain synonym dictionary, unify colloquial or diverse expressions into standard terms. For example, unify "cloud host", "server", etc. into "virtual machine".

[0129] Step 2.1.4: Query Complexity Analysis. Analyze features such as the number of entities and logical connectives (such as "and", "then", "if") included in the query to determine the complexity of the query.

[0130] Optionally, if a query only contains a single operation intention (such as "Query the virtual machine list"), start a lightweight single-path planning, directly match and call the corresponding interface; if the query involves multiple related operations, there is a sequence or logical combination (such as "Create a virtual machine and then bind it to a public IP"), it is recognized as a multi-step workflow, trigger the deep path planning process, dynamically combine multiple interfaces through the knowledge graph, and generate a structured execution sequence to ensure the integrity and consistency of complex tasks.

[0131] In summary, after natural language processing, the user's vague colloquial request is accurately converted into a clear structured instruction. Each instruction unit clearly includes "what to do" (target operation) and "what to do it to and with what parameters" (entity information), providing an accurate basis for subsequent automatic execution of the system.

[0132] Step 2.2: Selecting the Starting Point for Graph Query. After determining the user's intent, it is necessary to find the most relevant "entry point" or "starting point" API node in the vast knowledge graph to begin path exploration. A hybrid retrieval strategy is employed, which can be executed through the following steps:

[0133] Step 2.2.1: Semantic Retrieval. First, the parsed user intent (especially the operation description in the query request) is encoded into a semantic embedding vector. Then, across all API nodes in the entire knowledge graph, the cosine similarity between the user intent vector and the pre-stored semantic embedding vectors of each node is calculated. The API nodes with the highest similarity scores are selected as a coarsely filtered candidate set.

[0134] The advantage of the above implementation is that even if the user's description is completely different from the official name of the interface, it can still be successfully recalled as long as the semantics are similar. For example, if a user says "turn off the machine," the stopServer interface with the summary "shut down a virtual machine" can be matched.

[0135] Step 2.2.2: Keyword and Business Domain Filtering. Based on the candidate set retrieved through semantic retrieval, the system uses strong signal entities (such as IP, UUID) and business domains (such as "network" and "storage") extracted from the query for further precise matching and filtering. If a candidate API's parameter list or description explicitly contains the user-provided entity type, or if its business domain is highly relevant to the user's intent, it will be given higher weight.

[0136] In summary, by employing a two-stage approach of first performing semantic recall and then precise keyword filtering, we can efficiently and accurately locate a small set of starting APIs that are most likely to meet user needs, laying the foundation for subsequent path planning.

[0137] Step 3: Dynamic path planning based on subgraph expansion and multi-factor ranking. The system intelligently traverses interface dependencies on the knowledge graph, combines the optimal operation chain, and generates an executable directed acyclic graph execution plan based on multi-factor evaluation such as semantics, performance, and permissions. This includes the following steps:

[0138] Step 3.1: Hybrid Retrieval and Chain-Based Planning Process. The starting point is precisely located through semantic recall and keyword filtering. Then, multi-hop subgraph expansion is performed based on the knowledge graph, dynamically combining interface paths and ranking them using multiple factors to generate the optimal execution chain. The specific process includes the following steps:

[0139] Step 3.1.1: Full Graph Search and Initial Recall. This step is seamlessly connected to the starting point selection of the query parsing layer. The system calculates the semantic similarity between the semantic vector of the user's intent and the triple descriptions of each interface in the knowledge graph (such as "<interface name, function, description>"), and recalls a batch of candidate interfaces whose semantics are closest to the user's needs, which serve as the initial entry set for path planning.

[0140] Step 3.1.2: Subgraph Expansion and Exploration. For each core interface initially recalled, the system performs a k-hop traversal on the knowledge graph. This means starting from the node, exploring its neighboring nodes, and the neighboring nodes of those neighboring nodes, along edges such as "dependency" and "input mapping," and so on, until a preset depth k is reached. The purpose of this process is to discover those pre-, post-, or supplementary interfaces that, although not directly mentioned by the user, are essential for completing the entire task. For example, when the user's intent is "create virtual machine," subgraph expansion might discover queryImage, queryNetwork, etc., as pre-dependent interfaces. The result of the expansion is a candidate subgraph containing all potentially related interfaces and their interrelationships.

[0141] Step 3.1.3: Path Combination and Multi-Factor Ranking. On the candidate subgraph, there are multiple potential paths from the starting point to the ending point (the node that satisfies the user's final goal). These paths are ranked using a multi-factor scoring model to select the optimal path. The design of the scoring function Score comprehensively considers the following dimensions:

[0142] (1) Semantic Relevance: The overall semantic similarity between the functional descriptions of all nodes on the path and the user's original intent.

[0143] (2) Path Cost: The total execution cost of a path.

[0144] Optionally, the path cost is a weighted function that combines the average latency and historical failure rate (1 - success rate) of all interfaces on the path. The specific calculation formula is as follows:

[0145] PathCost=w_latency×Σ(avg_latency)+w_error×Σ(1-success_rate);

[0146] Here, PathCost represents the total cost of the path; a higher value means a greater cost (time, risk, etc.) to execute the path. w_latency is the latency weighting coefficient, used to adjust the importance of response time in the total cost. Σ(avg_latency) represents the sum of historical average latency for all interfaces in the path, where Σ is the summation sign and avg_latency is the average response time for a single interface. w_error is the failure rate weighting coefficient, used to adjust the importance of failure risk in the total cost. Σ(1-success_rate) represents the sum of historical failure rates for all interfaces in the path, where success_rate is the success rate of a single interface call.

[0147] (3) Permission Match: Whether the permissions required by all interfaces on the path are within the current user's permission range. Paths with mismatched permissions will be demoted or excluded directly.

[0148] (4) Parameter Completeness: How many of the key input parameters that are necessary and indispensable for the successful execution of each interface in the path can be satisfied by the user's initial input or the output of the preceding nodes in the path.

[0149] In summary, the final path score is a weighted sum of the above factors. The system calculates the scores of all candidate paths and selects the path with the highest score as the preferred execution plan. Specifically, it is calculated using the following formula: TotalScore = w_sem × SemanticRelevance - w_cost × PathCost + w_perm × PermissionMatch + w_param × ParameterCompleteness;

[0150] Among them, TotalScore is the final score of the path, and the system will prioritize the path with the highest final score; w_sem, w_cost, w_perm, and w_param are the weight coefficients of semantic relevance, path cost, permission matching, and parameter completeness, respectively; SemanticRelevance is the semantic relevance score between the path and the user's intent; PathCost is the total cost of the path calculated by the above formula. A negative value indicates that the higher the cost, the lower the total score; PermissionMatch is the permission matching score. If the user's permissions meet the path requirements, the score will be high; ParameterCompleteness is the parameter completeness score. The more complete the parameters required by the path, the higher the score.

[0151] Step 3.1.4: Chain Path Generation. After the highest-ranked path is selected, the system converts it into a Directed Acyclic Graph (DAG). In this DAG, each node represents a specific API call, and the nodes are labeled with the parameters that need to be passed in (including parameters inherited from user input or previous nodes). Edges represent the execution order and dependencies between nodes. For API calls without direct dependencies, they can be represented as parallel branches in the DAG to improve execution efficiency. This DAG is the final, clear, and executable "task blueprint" delivered to the execution layer.

[0152] Step 3.2: Session-level Dynamic Pruning and Path Reuse. To address the issue of traditional solutions being unable to handle multi-turn dialogues, a session-level memory and dynamic pruning mechanism is introduced. Specifically, the system maintains a session semantic cache for each user session, which stores the semantic vectors of the most recent rounds (e.g., the most recent 5 rounds) of queries, the entities provided by the user, and the finally selected execution path.

[0153] Optionally, when a new query arrives, the similarity between the semantic vector of the new query and the historical query vectors in the cache is first calculated. If the similarity is very high (exceeding a threshold, such as 0.9), and the new query does not introduce conflicting entities, the system will determine that this may be a duplicate query or a simple confirmation. In this case, the path and results of the previous round can be directly reused to avoid redundant calculations and achieve a response time of seconds. If the similarity is relatively high (e.g., between 0.7 and 0.9), the system will determine that this is likely a supplementary or corrective query. For example, the first round is "create a virtual machine", and the second round is "add a 50G data disk to it". The system will recognize that the second round query is highly related to the "virtual machine" subject of the first round operation. In this case, instead of planning from scratch, a part of the subgraph generated in the first round is directly reused, and incremental planning is performed on this basis: the interfaces related to "adding a data disk" (such as createVolume, attachVolume) are found and connected to the nodes representing the created virtual machines to form a new, extended DAG. This dynamic pruning strategy greatly reduces unnecessary graph traversal and path search, significantly improving planning efficiency and consistency in multi-round interaction scenarios.

[0154] Step 3.3: Path Caching and Incremental Maintenance. For frequently invoked, fixed task paths across the entire system (e.g., "query a list of all virtual machines and display their IP addresses"), the system caches their DAG and related subgraph structures. When subsequent queries hit these high-frequency patterns, the system can directly load the pre-calculated path plan from the cache, bypassing the complex planning process and further reducing end-to-end latency.

[0155] Step 4: Automatic parameter inheritance, idempotent control, and atomized rollback execution. This involves transforming the planned DAG blueprint into a practical, safe sequence of interface calls and handling various details during execution, specifically including the following steps:

[0156] Step 4.1: Parameter Inheritance and Differentiated Completion. When scheduling the execution of the DAG, the executor strictly adheres to the dependencies between nodes. One of its core functions is automatic parameter inheritance. After a node completes execution, the executor automatically extracts the specified output value (e.g., the server_id returned by createServer) from its response body based on the predefined "input-output mapping" relationship in the knowledge graph, and injects it into the request parameters of subsequent dependent nodes (e.g., the server_id required by attachVolume).

[0157] Optionally, before path execution, the executor performs a parameter completeness check. It traverses all nodes in the DAG, checking if all required parameters for each node can be obtained from the user's initial input or the output of the preceding nodes. If any missing required parameters are found, the system will enter a differential completion process, specifically including:

[0158] (1) Automatic matching: First, the system will attempt to automatically fill in the missing information using the knowledge graph. For example, if the missing parameter is a parameter with an enumeration value (such as network_type), and the user input contains related synonyms, the system can automatically match it.

[0159] (2) Generating Clarifying Questions: If automatic matching fails, the system will not directly report an error. Instead, it will use a large language model to generate a clear and user-friendly one-time clarifying question based on the name, description, and possible enumerated values ​​of the missing parameters. For example, if image information is missing when creating a virtual machine, the system will ask: "Which operating system image do you want to use to create the virtual machine? For example: CentOS 7.9, Ubuntu 20.04, or Windows Server 2019?" The user's answer will be used to complete the parameters, and then execution will continue. This proactive and guided interaction greatly enhances the user experience.

[0160] Step 4.2: Security and Idempotency Control. To ensure the security and consistency of write operations (create, update, delete, etc.), an idempotency control mechanism is introduced. For write operation nodes in the DAG marked as non-idempotent by the knowledge graph, the executor generates a unique idempotency key, typically a UUID, before its first invocation. The executor then places this key into a specific HTTP header (e.g., X-Idempotency-Key) of the API request.

[0161] Optionally, the backend interface of the cloud management platform needs to be modified accordingly to cooperate with the above mechanism. Specifically, when the interface receives a request with an idempotent key, it first checks whether this key has been processed recently (e.g., within the past 24 hours). If so, it indicates that this is a duplicate request, and the interface will not execute the actual operation again, but will directly return the result of the first successful execution. If not, the operation is executed normally, and the idempotent key is associated with the execution result and stored. Through this mechanism, even if the client retryes due to network problems, or the user accidentally submits a duplicate request, it can be ensured that the resource will not be created or modified repeatedly, thus guaranteeing the idempotency of the operation.

[0162] Step 4.3: Execute flow control and automatic rollback on failure. The executor schedules interface calls according to the topological order of the DAG. For parallel branches without dependencies, they can be executed concurrently to shorten the overall execution time. During execution, the system implements a comprehensive flow control and fault tolerance mechanism, as follows:

[0163] (1) Timeout and Retry: Set an independent timeout for each interface call. For failures caused by momentary problems such as network jitter, a limited number of automatic retries can be performed according to a preset strategy (such as exponential backoff).

[0164] (2) Circuit Breaker: If an interface fails to be called multiple times in a short period of time, the circuit breaker will "trip". For the next period of time, all calls to the interface will be immediately rejected and an error will be returned to avoid putting more pressure on the already problematic service.

[0165] (3) Automatic rollback upon failure: When a task node ultimately fails after a retry, the automatic rollback mechanism is activated. The executor checks if the currently failed node has a preceding node pointed to by a "compensatesFor" relationship in the knowledge graph. If so, the executor will traverse the successfully executed path in reverse and call the compensation interfaces of these preceding nodes in sequence. For example, if a task is "create a virtual machine and bind it to a public IP address", and the "bind public IP address" step fails, the rollback mechanism will automatically call the deleteServer interface to delete the previously created virtual machine, thereby restoring the system resources to the state before the task execution, avoiding the creation of "orphan" resources, and ensuring the atomicity of the entire workflow.

[0166] Step 4.4: Output Aggregation and Summarization. After all nodes in the DAG have been successfully executed, the executor collects the output results of all nodes. For scenarios that need to be displayed to the user, this raw, structured JSON data may not be user-friendly. The output aggregation and summarization module processes this data according to the user's initial intent, as follows:

[0167] (1) Aggregation: Merge, deduplicatize, or statistically analyze list data returned by multiple interfaces.

[0168] (2) Formatting: Extract the key information and format it according to the predefined template.

[0169] (3) Summarize: Use a large language model to convert the formatted data into a fluent and easy-to-understand natural language description or a clear table as the final answer to the user's query.

[0170] Step 5: Session Memory-Driven Incremental Planning and Closed-Loop Optimization System. This involves measuring, analyzing, and optimizing the system's long-term operation to form a closed loop of continuous learning and improvement. Specifically, it includes the following steps:

[0171] Step 5.1: Use feedback collection and continuous learning. Record detailed data for each user query, including: the original query, the parsed intent, all candidate paths and their scores, the final selected path, the parameter completion process, the execution result of each interface (success / failure, delay), and the user's implicit or explicit feedback on the final result (e.g., whether the user initiated a revised query after receiving the result).

[0172] Optionally, the data recorded above can be used for the following operations:

[0173] (1) Optimize the path ranking model: By employing reinforcement learning or offline training ranking models, adjust the weights (such as w_sem, w_cost, etc.) in the multi-factor scoring function based on the final success or failure of the task. Successful paths should receive higher scores, while failed paths or paths that lead to user corrections should be downweighted.

[0174] (2) Incremental learning knowledge graph: By analyzing frequently occurring interface combinations that are not yet defined in the current knowledge graph, new "dependencies" or "input mappings" can be automatically discovered and recommended to the administrator for review, thereby continuously enriching and improving the knowledge graph.

[0175] Step 5.2: Indicator Monitoring and Manageability. Continuously monitor the system's key performance and quality indicators, and display them to operations and maintenance personnel through dashboards to ensure the system's healthy operation and manageability. Core monitoring indicators include:

[0176] (1) Path coverage: The degree of matching between the optimal path planned by the system and the standard path defined by human experts on the standard test set.

[0177] (2) End-to-end delay: the average time and percentile from receiving a user query to returning the final result (P95, P99).

[0178] (3) Token consumption: The number of tokens consumed each time an interaction with a large language model is a key indicator for measuring the system's operating cost.

[0179] (4) Task success rate: The percentage of all initiated tasks that are ultimately successfully completed.

[0180] (5) Clarification rate: The proportion of queries that require clarification from the user. A decrease in this metric usually indicates an improvement in the system's ability to understand intent.

[0181] (6) Rollback success rate: The percentage of automatic rollback operations that are successfully completed when a failure occurs.

[0182] In summary, the above indicators provide data support for evaluating system performance, identifying bottlenecks, and verifying the effectiveness of algorithm improvements.

[0183] Optionally, to ensure planning quality while achieving low latency and low cost, the system deeply integrates three types of cache, such as... Figure 5 As shown, Figure 5 This is a system architecture block diagram with a caching mechanism according to an embodiment of this application, specifically including the following three types of caching mechanisms:

[0184] (1) Interface Card Cache 52: For each API, a lightweight "interface card" is pre-generated, containing key information such as its ID, summary, required parameters, and call examples, and its size is limited (e.g., less than 1KB). At certain stages of path planning, when only the summary information of the interface is needed, the system can directly and quickly retrieve it from this cache without calling a large language model for summary generation or accessing the complete graph database node, which significantly reduces token consumption.

[0185] (2) Session Semantic Cache 54: This cache stores the most recent interaction history for each user session, including semantic vectors, selected paths and parameters. It is the core of realizing session-level dynamic pruning, path reuse and parameter inheritance, and is the key to ensuring the coherence and efficiency of multi-turn dialogues.

[0186] (3) Execution Feedback Cache 56: Caches the actual result summary of recent interface calls. When a query is highly similar to a historical query, if the result of its corresponding interface call is relatively static (e.g., querying configuration information that does not change frequently), the system can even directly reuse the execution result in the cache to achieve a sub-second response, which is especially effective for query-type (GET request) operations.

[0187] Optionally, in a cloud management task scenario involving multiple rounds of interaction, an operations engineer needs to perform a two-phase task:

[0188] Phase 1: Create a virtual machine for web services with the following specifications: 2-core CPU, 4GB RAM, 100GB system disk, and add it to the production network named "prod-network-A".

[0189] Phase 2: Mount an additional 50GB data disk to the newly created virtual machine.

[0190] Optionally, the above scenario can be achieved by performing the following steps:

[0191] Step 1: Pre-construction of the knowledge graph. Before the system provides services, the knowledge graph construction layer has automatically completed the following tasks:

[0192] 1. API Node Extraction. The OpenAPI documentation of the cloud management platform is scanned and parsed. Corresponding API nodes are created for hundreds of APIs, including createServer (create virtual machine), createVolume (create storage volume), attachVolume (mount storage volume), queryNetwork (query network), and queryFlavor (query specification). Each node contains static attributes such as its name, description, HTTP method, path, all parameters (name, type, required), and permission tags.

[0193] 2. Attribute Enrichment. Using NER technology, the core entity "virtual machine" is identified from the description "create a new virtual machine instance" of createServer. Simultaneously, semantic embedding vectors are generated for each API node using models such as BERT.

[0194] 3. Relationship Building. This specifically includes building the following three types of relationships:

[0195] (1) Dependency relationship. By recognizing that the execution prerequisite for the attachVolume interface is the existence of a virtual machine, a dependOn relationship is established from attachVolume to createServer.

[0196] (2) Input mapping relationship. Through analysis, it was found that the response body of the createServer interface contains server.id, while the request body of the attachVolume interface requires server_id. Therefore, an inputOutputMapping relationship was established from createServer to attachVolume, and the specific parameter mapping path was marked.

[0197] (3) CompensatesFor Relationship. By identifying that deleteServer is the inverse operation of createServer, a compensatesFor relationship from deleteServer to createServer is established, preparing for subsequent rollback. Similarly, a corresponding compensation relationship is also established for createVolume.

[0198] 4. Dynamic attribute integration. The system is connected to a monitoring system, at which point each API node is equipped with dynamic information such as recent average latency and success rate.

[0199] Step 2: Process the first phase task (first round of interaction), which specifically includes:

[0200] 1. User Input. Users can input natural language commands via command line or web interface: "Create a virtual machine with 2 cores, 4GB of memory, and a 100GB system disk, and join it to the prod-network-A network."

[0201] 2. Query parsing. After receiving the instruction, the query parsing layer performs the following operations:

[0202] (1) Entity extraction: Identified operation: "Create virtual machine", specifications: {cpu: 2, ram: 4GB}, system disk: 100GB, network: "prod-network-A".

[0203] (2) Starting point selection: "Create virtual machine" is encoded as a semantic vector, and semantic retrieval is performed in the knowledge graph. The createServer interface is hit with a high score. Combined with other entities, the system confirms that createServer is the core target node of this task.

[0204] 3. Path Retrieval and Planning. The path retrieval and planning layer initiates the planning process, as follows:

[0205] (1) Subgraph expansion: A k-skip graph traversal is performed starting from the createServer node. During the traversal, the system finds that createServer requires flavorRef (specification ID) and networkId (network ID) as input parameters. Following the reverse edge of the inputOutputMapping relationship, the system finds the two prerequisite dependency interfaces queryFlavor and queryNetwork.

[0206] (2) Path Combination and Ordering: First, the system constructs a core path, specifically: queryNetwork->queryFlavor->createServer. Then, a multi-factor scoring model evaluates this path, comprehensively considering its semantic relevance to the user's intent, the historical average latency and success rate of each interface along the path, and the matching degree between the required execution permissions and the current user's permissions. Because this path fully satisfies the user's intent and has a good historical performance, it received the highest score.

[0207] (3) DAG construction: The system transforms the optimal path into a directed acyclic graph (DAG), which clarifies the execution order.

[0208] 4. Parameter Completion and Execution. After receiving the DAG, the parameter completion and execution layer begins to perform the following operations:

[0209] (1) Parameter completeness check: The executor check found that createServer also needs an imageRef (image ID) parameter, which the user did not provide.

[0210] (2) Generate clarifying questions: The system will not fail immediately, but will instead use LLM to generate a friendly question: "Which operating system image would you like to use to create the virtual machine? (e.g., CentOS 8, Ubuntu 22.04)"

[0211] (3) User completion and parameter inheritance: The user replies "Using CentOS 8". The executor captures this information. Then, it first executes queryNetwork (passing in prod-network-A) to obtain the network ID; then it executes queryFlavor (passing in "2 cores 4G") to obtain the specification ID. Then, it automatically populates these IDs and the image ID provided by the user into the parameter list of createServer.

[0212] (4) Idempotency execution: Before calling createServer (a write operation), the executor generates a unique UUID as the idempotency key and sends it in the X-Idempotency-Key request header. The cloud management platform backend ensures that even if the request is retried, the virtual machine will only be created once.

[0213] (5) Execution and Output: createServer executes successfully and returns a response containing the new virtual machine ID (e.g., server-uuid-123). The executor collects this result and uses the session semantic cache to record the context of this interaction, including the newly created virtual machine ID. Finally, the output aggregation and summarization module reports to the user: "Virtual machine (ID: server-uuid-123) has been successfully created, with specifications of 2 cores, 4GB memory, and a 100GB system disk, and has been connected to the prod-network-A network."

[0214] Step 3: Handle the second phase task (second round of interaction), which specifically includes:

[0215] 1. User input: The user continued to input: "Add a 50G data disk to it".

[0216] 2. Session-level dynamic programming, specifically including:

[0217] (1) Query parsing: The query parsing layer identifies the operation: "add data disk", capacity: 50GB, and a pronoun "it".

[0218] (2) Session awareness: The path retrieval and planning layer calculates the semantic similarity between the new query and the previous query and finds a high correlation. It identifies that "it" refers to the subject of the previous operation, virtual machine server-uuid-123.

[0219] (3) Dynamic pruning and incremental planning: The system no longer starts from scratch, but directly reuses server-uuid-123 in the session semantic cache. It performs small-scale path planning with the intention of "adding a data disk", and quickly finds the path createVolume->attachVolume in the knowledge graph.

[0220] (4) New DAG construction: The system constructs a new, smaller DAG, where createVolume requires the parameter size: 50, and the server_id parameter of attachVolume is automatically filled with server-uuid-123.

[0221] 3. Demonstration of automatic rollback upon execution and failure, specifically including:

[0222] (1) Parameter inheritance execution: The executor begins to execute the new DAG. First, createVolume is called, and an idempotent key is generated for it. If the call is successful, the new storage volume ID is returned (e.g., volume-uuid-456).

[0223] (2) Simulation failure: The executor calls attachVolume, attempting to mount volume-uuid-456 to server-uuid-123. Assume that due to a temporary backend storage failure, this interface call eventually fails after multiple retries.

[0224] (3) Automatic rollback: After the executor captures a failed interface call, it immediately initiates a rollback mechanism. By querying the knowledge graph, it is found that the createVolume interface has a compensatesFor relationship, which points to its compensation interface deleteVolume. The executor then calls the deleteVolume interface and passes the volume-uuid-456 that was just created but failed as a parameter.

[0225] (4) State recovery: The deleteVolume call was successful, and the "orphan" data disk that failed to be mounted was completely deleted. The system resource state was rolled back to the state before the start of the second phase of the task.

[0226] (5) Report to user: The system finally reports to the user: "An error occurred when trying to add a 50GB data disk for you. The operation has been automatically rolled back without any cost or resource residue. Error reason: [Backend storage failure]".

[0227] In summary, this application, by constructing an interface knowledge graph and introducing natural language understanding, allows users to express their business intentions using high-level, fuzzy natural language. Simultaneously, it can automatically decompose, plan, and map this intention into a series of precise API call sequences. This frees operations personnel from tedious and error-prone API details, allowing them to focus on the business objectives themselves, thus improving work efficiency and automation levels. Secondly, this application also introduces session semantic caching and dynamic pruning mechanisms. When users supplement, correct, or follow up on tasks during multi-turn conversations, the system can understand the context, reuse existing planning results and operation objects, and perform efficient incremental planning. Furthermore, through idempotency control and automatic failure rollback mechanisms, it solves the problem that any single point of failure can lead to inconsistent resource states and the residual "orphan resources." In summary, this application integrates dynamic runtime attributes such as average latency and success rate of interfaces into knowledge graph nodes. Its multi-factor ranking model can dynamically select the "optimal" path. Furthermore, through continuous learning from user feedback and execution results, the system can self-evolve, constantly optimizing its ranking model and the knowledge graph itself, forming a virtuous cycle of performance improvement. Simultaneously, the deep integration of three core caching mechanisms (interface cards, session semantics, and execution feedback) ensures that the system provides high-quality planning while maintaining low latency and low cost.

[0228] 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. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0229] This embodiment also provides a target path determination device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs 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.

[0230] Figure 6 This is a structural block diagram of a target path determination device according to an embodiment of this application, such as... Figure 6 As shown, the device includes:

[0231] The matching module 62 is used to match multiple interface nodes that match the query request from the interface knowledge graph, wherein the multiple interface nodes correspond to multiple intents corresponding to the query request;

[0232] The first determining module 64 is used to determine, starting from the multiple interface nodes and using a preset node depth as the traversal scale, multiple extended interface nodes that have a first dependency relationship with the multiple interface nodes from the interface knowledge graph.

[0233] Module 66 is used to establish a candidate subgraph based on the plurality of interface nodes, the plurality of extended interface nodes, and the second dependency relationship between the plurality of extended interface nodes;

[0234] The second determining module 68 is used to count multiple interface call paths existing in the candidate subgraph and determine the target path from the multiple interface call paths through a scoring model.

[0235] The aforementioned device identifies multiple semantic intents from user query requests and matches them with corresponding initial API nodes in the interface knowledge graph, thus establishing a semantic association between intents and interfaces. Subsequently, starting from these initial nodes and using a preset traversal depth as a scale, the system actively explores extended interface nodes in the interface knowledge graph that have a direct "first dependency relationship" (such as execution prerequisites). Based on this, the system integrates the initial nodes, extended nodes, and their mutual "second dependencies" (such as sequential, parallel, or parameter passing constraints) to construct a candidate subgraph covering the complete business process. Finally, the system enumerates all feasible interface call paths in the subgraph and, combined with a multi-factor scoring model considering semantic relevance, execution cost, permission matching, and parameter completeness, comprehensively evaluates and selects the optimal target path. This technical solution solves the problems of a large number of interfaces and complex dependencies in cloud management platforms, where traditional retrieval methods struggle to accurately understand user intents, leading to inaccurate path planning. Then, by matching the initial interface node corresponding to the user's intent through the interface knowledge graph, a subgraph with structured dependencies is expanded at a preset depth, generating and scoring multiple candidate execution paths, thereby intelligently selecting the optimal target path and achieving accurate and structured automated task planning.

[0236] In an exemplary embodiment, the matching module is further configured to encode multiple intents corresponding to the query request to obtain a first semantic vector; calculate the similarity between the first semantic vector and the second semantic vector corresponding to each interface node in the interface knowledge graph to obtain multiple similarity scores; determine the interface nodes with similarity scores greater than a preset similarity threshold as candidate interface nodes to obtain multiple candidate nodes; and process the multiple candidate nodes again based on a preset multi-dimensional filtering strategy to obtain the multiple interface nodes.

[0237] In an exemplary embodiment, the matching module is further configured to determine multiple keywords of multiple intents corresponding to the query request, and multiple business domain tags corresponding to multiple candidate nodes in the interface knowledge graph; count the business domain tags containing at least one of the multiple keywords to obtain multiple target tags; and determine the multiple interface nodes based on the candidate nodes corresponding to the multiple target tags.

[0238] In an exemplary embodiment, the above apparatus further includes: a selection module, configured to, before matching multiple interface nodes that match the query request from the interface knowledge graph, include: if the query request is the first request issued by the target object, extracting semantic entities from the query request, and combining structured intent units based on the semantic entities, wherein each structured intent unit includes an operation intent and interface input parameters corresponding to the operation intent; determining the number of combinations of the structured intent units, and counting the number of connections of logical connectives used to connect multiple intents contained in the query request; determining the complexity level corresponding to the query request through the number of combinations and the number of connections, and selecting a path planning strategy corresponding to the complexity level.

[0239] In an exemplary embodiment, the selection module is further configured to determine that the query type corresponding to the query request is a simple query when the number of combinations is not zero and the number of connections is zero; and to determine that the query type corresponding to the query request is a complex query when the number of combinations is not zero and the number of connections is not zero.

[0240] In an exemplary embodiment, the second determining module is further configured to extract path parameters from the multiple interface call paths according to multiple scoring factors in the scoring model to obtain multiple scoring parameter sets; wherein, the multiple scoring factors include: semantic relevance, path cost, permission matching degree, and parameter completeness; perform weighted summation on the multiple scoring parameter sets respectively to obtain multiple scoring results; and determine the target path based on the multiple scoring results.

[0241] In an exemplary embodiment, the second determining module is further configured to determine the first weight corresponding to the semantic relevance parameter, the second weight corresponding to the path cost parameter, the third weight corresponding to the permission matching parameter, and the fourth weight corresponding to the parameter completeness parameter in each set of scoring parameters; calculate the first product value of the semantic relevance parameter and the first weight, the second product value of the path cost parameter and the second weight, the third product value of the permission matching parameter and the third weight, and the fourth product value of the parameter completeness parameter and the fourth weight; sum the first product value, the second product value, the third product value, and the fourth product value to obtain the scoring result corresponding to each set of scoring parameters; and summarize the scoring results corresponding to each set of scoring parameters to obtain the plurality of scoring results.

[0242] In an exemplary embodiment, the second determining module is further configured to sort the score values ​​corresponding to the plurality of score results by size and determine the maximum score value in the sorted results; and determine the interface call path associated with the maximum score value as the target path.

[0243] In an exemplary embodiment, the second determining module further includes: an acquisition unit, configured to, after determining the interface call path associated with the maximum score value as the target path, acquire the execution order, dependency relationship, and parameter information to be set for each node of the target path; convert the target path into a directed acyclic graph based on the execution order, dependency relationship, and parameter information, and use the directed acyclic graph as the target execution plan; and schedule the execution of the interface call according to the target execution plan.

[0244] In an exemplary embodiment, the acquisition unit further includes: a verification subunit, configured to, after converting the target path into a directed acyclic graph based on the execution order, the dependency relationship, and the parameter information, and using the directed acyclic graph as the target execution plan, perform parameter integrity verification on the target execution plan to obtain a verification result; and, if the verification result indicates that there are missing parameters in the target execution plan, generate a query request based on the description information of the missing parameters in the interface knowledge graph, wherein the query request is used to request the target object to supplement the value of the missing parameters.

[0245] In an exemplary embodiment, the acquisition unit further includes a query subunit, configured to, after scheduling the execution of the interface call according to the target execution plan, if any interface call in the target execution plan fails, query the preceding node in the interface knowledge graph that has a compensation relationship with the failed node; and sequentially call the compensation interface corresponding to the preceding node in reverse order of the target execution plan to restore the state before the execution of the target execution plan.

[0246] In an exemplary embodiment, the acquisition unit further includes: a generation subunit, configured to generate a unique idempotent key for all write operation nodes marked as non-idempotent in the target execution plan before scheduling the execution interface call according to the target execution plan; bind the idempotent key with the corresponding interface call parameters, execution timestamp, and identity identifier of the target object, and store them in an idempotent key log library; and, in the case where the target object repeatedly initiates the same intent query in different sessions, identify historical successful execution records by comparing them with the idempotent key log library, and directly return the original execution result.

[0247] In an exemplary embodiment, the above apparatus further includes: an acquisition module, configured to, when the query request is a second request issued by the target object, acquire context reference information carried in the query request, wherein the context reference information is used to point to the operation intent in the first query request; determine a new operation intent based on the context reference information and the session semantic cache information corresponding to the context reference information, and perform subgraph expansion only on the new operation intent in the interface knowledge graph.

[0248] In an exemplary embodiment, the above apparatus further includes: an extraction module, configured to extract multiple interface semantic nodes from the interface documents of the cloud management platform before matching multiple interface nodes that conform to the intent corresponding to the query request from the interface knowledge graph; construct semantic association edges based on the business logic associations and data dependencies between the multiple interface semantic nodes, wherein the semantic association edges include at least one of the following: a first semantic association edge for indicating the order of interface execution, a second semantic association edge for indicating the parameter passing path between interfaces, and a third semantic association edge for indicating the correspondence between the write operation interface and the reverse operation interface; and construct the interface knowledge graph based on the interface semantic nodes and the semantic association edges.

[0249] In an exemplary embodiment, the above apparatus further includes: a parsing module, configured to parse the changed interface document when a change is detected in the cloud management platform interface document, and obtain a parsing result; and to perform at least one of the following operations on the corresponding interface nodes and semantic association edges in the interface knowledge graph based on the parsing result: adding, modifying, or marking as deprecated; and to establish a version mapping relationship between the interface nodes marked as deprecated and the new version nodes.

[0250] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when run.

[0251] 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.

[0252] Embodiments of this application also provide an electronic device, 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 above method embodiments.

[0253] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0254] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

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

[0256] The embodiments described herein also provide a computer program that 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 in any of the above method embodiments.

[0257] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0258] 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.

[0259] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0260] The foregoing has provided a detailed description of a method, apparatus, storage medium, electronic device, and product for determining a target path. 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 its core ideas. 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. A method for determining a target path, characterized in that, include: Multiple interface nodes matching the query request are identified from the interface knowledge graph, wherein the multiple interface nodes correspond to multiple intents corresponding to the query request; Starting from the multiple interface nodes, and using the preset node depth as the traversal scale, multiple extended interface nodes that have a first dependency relationship with the multiple interface nodes are determined from the interface knowledge graph. Based on the multiple interface nodes, the multiple extended interface nodes, and the second dependency relationship between the multiple extended interface nodes, a candidate subgraph is established; The candidate subgraph contains multiple interface call paths, and the target path is determined from these multiple interface call paths using a scoring model. The step of matching multiple interface nodes that match the query request from the interface knowledge graph includes: initially determining multiple candidate interface nodes that match multiple intents corresponding to the query request from the interface knowledge graph through semantic similarity matching; and filtering out candidate nodes corresponding to business domain tags that contain at least one keyword from the multiple keywords based on the matching relationship between multiple keywords corresponding to the multiple intents of the query request and multiple business domain tags associated with the multiple candidate interface nodes, thereby obtaining the multiple interface nodes. The step of statistically analyzing multiple interface call paths existing in the candidate subgraph and determining the target path from the multiple interface call paths using a scoring model includes: scoring the multiple interface call paths according to multiple scoring factors in the scoring model, and determining the target path based on the scoring results. The multiple scoring factors include: semantic relevance, path cost, permission matching degree, and parameter completeness.

2. The method for determining the target path according to claim 1, characterized in that, By using semantic similarity matching, multiple candidate interface nodes that match multiple intents corresponding to the query request are initially identified from the interface knowledge graph, including: The multiple intents corresponding to the query request are encoded to obtain a first semantic vector; Calculate the similarity between the first semantic vector and the second semantic vector corresponding to each interface node in the interface knowledge graph to obtain multiple similarity scores; Interface nodes with similarity scores greater than a preset similarity threshold are identified as candidate interface nodes, thus obtaining the multiple candidate nodes.

3. The method for determining the target path according to claim 1, characterized in that, Before matching multiple interface nodes that match the query request from the interface knowledge graph, the method further includes: When the query request is the first request issued by the target object, the semantic entities in the query request are extracted, and structured intent units are combined based on the semantic entities. Each structured intent unit contains an operation intent and the interface input parameters corresponding to the operation intent. Determine the number of combinations of the structured intent units, and count the number of logical connectors in the query request used to connect multiple intents; The complexity level of the query request is determined by the number of combinations and the number of connections, and a path planning strategy corresponding to the complexity level is selected.

4. The method for determining the target path according to claim 3, characterized in that, The complexity level of the query request is determined by the number of combinations and the number of connections, including: If the number of combinations is not zero and the number of connections is zero, the query type corresponding to the query request is determined to be a simple query. If the number of combinations is not zero and the number of connections is not zero, the query type corresponding to the query request is determined to be a complex query.

5. The method for determining the target path according to claim 1, characterized in that, The multiple interface call paths are scored according to multiple scoring factors in the scoring model, and the target path is determined based on the scoring results, including: Based on the multiple scoring factors, path parameters are extracted from the multiple interface call paths to obtain multiple sets of scoring parameters; The multiple sets of scoring parameters are weighted and summed to obtain multiple scoring results; The target path is determined based on the multiple scoring results.

6. The method for determining the target path according to claim 1, characterized in that, The path cost among the multiple scoring factors is equal to the latency weight multiplied by the sum of the average latency of all interfaces on the path, plus the failure rate weight multiplied by the sum of the failure rates of all interfaces.

7. The method for determining the target path according to claim 5, characterized in that, The multiple sets of scoring parameters are weighted and summed to obtain multiple scoring results, including: Determine the first weight corresponding to the semantic relevance parameter, the second weight corresponding to the path cost parameter, the third weight corresponding to the permission matching parameter, and the fourth weight corresponding to the parameter completeness parameter in each set of scoring parameters; Calculate the first product of the semantic relevance parameter and the first weight, the second product of the path cost parameter and the second weight, the third product of the permission matching parameter and the third weight, and the fourth product of the parameter completeness parameter and the fourth weight; The first product value, the second product value, the third product value, and the fourth product value are summed to obtain the scoring result corresponding to each set of scoring parameters; The scoring results corresponding to each of the scoring parameter sets are summarized to obtain the multiple scoring results.

8. The method for determining the target path according to claim 5, characterized in that, Determining the target path based on the multiple scoring results includes: The score values ​​corresponding to the multiple scoring results are sorted by size, and the largest score value in the sorted results is determined. The interface call path associated with the maximum score value is determined as the target path.

9. The method for determining a target path according to claim 8, characterized in that, After determining the interface call path associated with the maximum score value as the target path, the method further includes: Obtain the execution order and dependencies between the target path nodes, as well as the parameter information to be set for each node; Based on the execution order, the dependencies, and the parameter information, the target path is transformed into a directed acyclic graph, and the directed acyclic graph is used as the target execution plan. The execution interface call is scheduled according to the target execution plan.

10. The method for determining a target path according to claim 9, characterized in that, After transforming the target path into a directed acyclic graph based on the execution order, the dependencies, and the parameter information, and using the directed acyclic graph as the target execution plan, the method further includes: Perform parameter integrity verification on the target execution plan and obtain the verification results; If the verification result indicates that there is a missing parameter in the target execution plan, a query request is generated based on the description information of the missing parameter in the interface knowledge graph. The query request is used to request the target object to supplement the value of the missing parameter.

11. The method for determining a target path according to claim 9, characterized in that, After scheduling the execution interface call according to the target execution plan, the method further includes: If any interface call in the target execution plan fails, query the preceding node in the interface knowledge graph that has a compensation relationship with the failed node. Following the reverse order of the target execution plan, the compensation interfaces corresponding to the preceding nodes are called sequentially to restore the state to that before the target execution plan was executed.

12. The method for determining the target path according to claim 9, characterized in that, Before scheduling the execution interface call according to the target execution plan, the method further includes: Generate a unique idempotent key for all write operation nodes marked as non-idempotent in the target execution plan; The idempotent key is bound to the corresponding interface call parameters, execution timestamp, and target object identity, and stored in the idempotent key log library; When the target object repeatedly initiates the same intent query in different sessions, the historical successful execution records are identified by comparing with the idempotent key log library, and the original execution result is returned directly.

13. The method for determining the target path according to claim 1, characterized in that, The method further includes: In the case where the query request is the second request issued by the target object, the context reference information carried in the query request is obtained, wherein the context reference information is used to point to the operation intent in the first query request; The new operation intent is determined based on the context reference information and the session semantic cache information corresponding to the context reference information, and subgraph expansion is performed only on the new operation intent in the interface knowledge graph.

14. The method for determining the target path according to claim 1, characterized in that, Before matching multiple interface nodes that match the intent of the query request from the interface knowledge graph, the method further includes: Extract multiple interface semantic nodes from the interface documentation of the cloud management platform; Based on the business logic association and data dependency relationship between the multiple interface semantic nodes, a semantic association edge is constructed, wherein the semantic association edge includes at least one of the following: a first semantic association edge for indicating the order of interface execution, a second semantic association edge for indicating the parameter passing path between interfaces, and a third semantic association edge for indicating the correspondence between the write operation interface and the reverse operation interface. The interface knowledge graph is constructed based on the interface semantic nodes and the semantic association edges.

15. The method for determining a target path according to claim 14, characterized in that, The interface knowledge graph includes a hot update mechanism, which includes: If a change is detected in the cloud management platform interface document, the changed interface document is parsed to obtain the parsing result; Based on the parsing results, perform at least one of the following operations on the corresponding interface nodes and semantic association edges in the interface knowledge graph: add, modify, or mark as deprecated; Establish a version mapping relationship between the interface nodes marked as deprecated and the corresponding new version nodes.

16. A device for determining a target path, characterized in that, include: The matching module is used to match multiple interface nodes that match the query request from the interface knowledge graph, wherein the multiple interface nodes correspond to multiple intents corresponding to the query request; The first determining module is used to determine, starting from the multiple interface nodes and using a preset node depth as the traversal scale, multiple extended interface nodes that have a first dependency relationship with the multiple interface nodes from the interface knowledge graph. A module is established to build a candidate subgraph based on the plurality of interface nodes, the plurality of extended interface nodes, and the second dependency relationship between the plurality of extended interface nodes; The second determining module is used to count multiple interface call paths existing in the candidate subgraph and determine the target path from the multiple interface call paths through a scoring model. The matching module described above is further configured to preliminarily determine multiple candidate interface nodes that match multiple intents corresponding to the query request from the interface knowledge graph through semantic similarity matching; and based on the matching relationship between multiple keywords corresponding to multiple intents of the query request and multiple business domain tags associated with the multiple candidate interface nodes, filter out candidate nodes corresponding to business domain tags that contain at least one keyword among the multiple keywords, thereby obtaining the multiple interface nodes. The second determining module is further configured to score the multiple interface call paths according to multiple scoring factors in the scoring model, and determine the target path based on the scoring results, wherein the multiple scoring factors include: semantic relevance, path cost, permission matching degree, and parameter completeness.

17. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the method for determining the target path as described in any one of claims 1 to 15.

18. 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 method for determining the target path as described in any one of claims 1 to 15.

19. 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 method for determining the target path as described in any one of claims 1 to 15.

Images