Business process reconstruction method and system based on large model and knowledge graph collaboration

Abstract

The invention provides a business process reconstruction method and system based on cooperation of a large model and a knowledge graph, and relates to the technical field of enterprise digital transformation, and the method comprises the steps: receiving a business demand description text uploaded by a user; determining target interface entities matched with the business demand description text and reasoning an interface relationship between the target interface entities through the target large model based on an interface knowledge graph so as to obtain an initial execution plan; and through the target large model, based on the interface knowledge graph, identifying whether a target interface entity contained in the initial execution plan has an execution blocking condition in a calling process, and if yes, inserting an execution adaptive node at a specified position in the initial execution plan to obtain a target execution plan. According to the method, the problems of unclear API interface relationship, difficulty in fusion of a large model and a business system, imperfect security and authority management, high difficulty in operation of new employees and the like in the existing business process reconstruction process are effectively solved.

Description

Technical Field

[0001] This invention relates to the field of enterprise digital transformation technology, and in particular to a business process reengineering method and system based on the collaboration of large models and knowledge graphs. Background Technology

[0002] As enterprises become increasingly digitalized, their business processes become more complex, involving interaction and collaboration between multiple systems. As a bridge for data interaction between systems, APIs (Application Programming Interfaces) face many challenges in management and application.

[0003] First, the relationships between API interfaces lack clear, structured definitions. API interfaces from different business systems vary significantly in terms of functional descriptions, parameter settings, and calling rules. For example, in a company's sales and inventory management system, the sales system's "Order Creation API" requires customer information in a specific code format, while the inventory system's "Inventory Update API" outputs customer information in the form of customer names. This necessitates complex adaptation processing for data integration between the two APIs, increasing the difficulty and cost of system integration. Statistics show that such additional development and maintenance costs due to API incompatibility account for 30%-40% of the total cost of a company's digital transformation.

[0004] Secondly, integrating large-scale models with enterprise business system APIs presents challenges. While large-scale models possess powerful natural language understanding and logical reasoning capabilities, they lack accurate understanding of the specific functions, parameter constraints, and inter-dependencies of APIs within enterprise business systems. Currently, the integration of large-scale models with APIs largely relies on manually writing fixed calling templates. This approach lacks flexibility; once the API changes (e.g., version updates, feature adjustments), the template needs to be rewritten, failing to meet the demands of rapidly evolving business needs. For example, after introducing a new marketing campaign management system, a company experienced a disruption in its business processes and significant economic losses because the new system's API calling methods were incompatible with the existing templates, preventing the large-scale model from effectively collaborating with it.

[0005] Furthermore, the security and access control management of API calls is inadequate. Security policies and access controls for different APIs within an enterprise are independent, lacking a unified management mechanism. In actual business processes, access vulnerabilities or security risks may arise. For example, in the financial approval process, the "Expense Reimbursement API" and the "Payment Confirmation API" each have their own access verification steps. However, if the access inheritance relationship between the two is not properly handled in the process design, low-privilege personnel may bypass some access verifications to perform sensitive operations, posing financial risks to the enterprise.

[0006] Finally, new employees face significant challenges in mastering business processes. Traditional business processes are often presented through complex code logic and static documentation, making it difficult to intuitively grasp key information such as API call relationships and data flow. New employees need to spend considerable time and effort learning and understanding these elements to become proficient in business operations. This not only prolongs the adaptation period for new employees but may also increase the error rate, impacting the normal operation of the business. For example, a newly hired employee at a company made an error in processing order-related business due to unfamiliarity with the call order and parameter passing relationships between multiple APIs, resulting in a poor customer experience.

[0007] Existing technologies have limitations in addressing the aforementioned issues. While knowledge graphs can be used to store entity relationships, they largely focus on the business data itself and fail to effectively model the characteristics of API interfaces. Research on large models in tool invocation also tends to focus on the functionality of individual APIs, lacking a comprehensive plan for the collaborative relationships among multiple APIs. Therefore, developing a method that can effectively integrate large models and knowledge graph technologies to achieve intelligent restructuring of enterprise business processes is of significant practical importance. Summary of the Invention

[0008] In view of this, the purpose of this invention is to provide a business process refactoring method and system based on the collaboration of large models and knowledge graphs, which effectively solves the problems of unclear API interface relationships, difficulty in integrating large models and business systems, imperfect security and permission management, and difficulty for new employees to get started in the existing business process refactoring process.

[0009] Firstly, this invention provides a business process refactoring method based on the collaboration of a large model and a knowledge graph, applied to a business process refactoring system. The business process refactoring system has a built-in target large model and stores a pre-configured interface knowledge graph. The interface knowledge graph describes multiple interface entities and the interface relationships between these entities; including: Receive user-uploaded text describing business requirements; By using the target big model and based on the interface knowledge graph, we determine the target interface entities that match the business requirement description text and infer the interface relationships between the target interface entities in order to obtain the initial execution plan. Using the target big model and based on the interface knowledge graph, we identify whether there are execution obstacles in the calling process of the target interface entity contained in the initial execution plan. If so, we insert an execution adapter node at a specified position in the initial execution plan to obtain the target execution plan. Among them, the execution obstacles include at least data transmission incompatibility and / or lack of security mechanisms. The execution adapter node is used to eliminate the execution obstacles.

[0010] In one implementation, using a target large model and based on an interface knowledge graph, it identifies whether there are execution obstacles in the invocation process of the target interface entities included in the initial execution plan. If so, an execution adapter node is inserted at a specified position in the initial execution plan to obtain the target execution plan, including: If, based on the interface knowledge graph, it is found that there is data transmission incompatibility between target interface entities included in the initial execution plan, a first execution adapter node is inserted between the target interface entities; and / or, if, based on the interface knowledge graph, it is determined that there is a lack of security mechanism in the target interface entities included in the initial execution plan, a second execution adapter node is inserted before the target interface entities to obtain an intermediate execution plan. Based on the intermediate execution plan, a target execution plan in the form of a directed acyclic graph is generated.

[0011] In one implementation, when data transfer incompatibility is identified between target interface entities included in the initial execution plan based on the interface knowledge graph, a first execution adapter node is inserted between the target interface entities, including: From the interface knowledge graph, extract the parameter passing rules corresponding to the target interface entities contained in the initial execution plan, and perform the following operations for any two target interface entities that have an interface relationship: Based on the parameter passing rules corresponding to the two target interface entities, identify whether there is a data transmission incompatibility between the two target interface entities; If so, determine the conversion steps and / or parameter passing method between the two target interface entities according to the preset large model conversion prompt words; A first execution adapter node is inserted between the two target interface entities. The first execution adapter node is used to implement the conversion steps and / or parameter passing methods to eliminate data transmission incompatibility between the two target interface entities.

[0012] In one implementation, if it is determined, based on the interface knowledge graph, that a target interface entity included in the initial execution plan lacks a security mechanism, a second execution adapter node is inserted before the target interface entity, including: From the interface knowledge graph, extract the permissions and security rules corresponding to the target interface entities contained in the initial execution plan, and perform the following operations on the target interface entities whose permissions and security rules are not empty: Based on the pre-set large model planning prompts, determine the permission verification node, security measure execution node, and node execution order corresponding to the target interface entity; among them, the second execution adaptation node includes the permission verification node and the security measure execution node; Before the target interface entity, insert permission verification nodes and security measure execution nodes in the order of node execution to eliminate the lack of security mechanisms in the target interface entity.

[0013] In one implementation, by using a target large model and based on an interface knowledge graph, the target interface entities for matching business requirement description texts are determined, and the interface relationships between target interface entities are inferred to obtain an initial execution plan, including: Perform the following operations using the target large model: Parse the key requirement information corresponding to the business requirement description text; The key information of the requirements is matched with the tool description information corresponding to the interface entities contained in the interface knowledge graph to determine the target interface entity for matching the business requirement description text. Based on the interface relationships between interface entities contained in the interface knowledge graph, the interface relationships between target interface entities are inferred to obtain the initial execution plan.

[0014] In one implementation, the method further includes: Perform rigid validation of the target execution plan using a graph database and flexible validation using a large model. The target execution plan is executed after passing both rigid validation of the graph database and flexible validation of the large model.

[0015] In one implementation, the target execution plan undergoes both rigid validation using a graph database and flexible validation using a large model, including: Rigid verification of the target execution plan using a graph database includes: verifying whether there are loops in the target execution plan using a graph database, and determining whether the rigid verification of the graph database is passed if there are no loops in the target execution plan. In the case of rigid verification through graph database, the plan complexity level corresponding to the target execution plan is determined, so as to determine whether to perform large-scale flexible verification of the target execution plan based on the plan complexity level; If the judgment result is yes, the target execution plan is subjected to large-scale model flexible verification, including: using the target large-scale model, according to the preset large-scale model verification prompt words, based on the business requirement description text and interface knowledge graph, to determine the score value corresponding to the target execution plan. If the score value is higher than the preset threshold, the target execution plan is determined to have passed the large-scale model flexible verification.

[0016] Secondly, this invention also provides a business process refactoring system based on the collaboration of a large model and a knowledge graph. The business process refactoring system has a built-in target large model and stores a pre-configured interface knowledge graph. The interface knowledge graph is used to describe multiple interface entities and the interface relationships between these entities; including: The text receiving module is used to receive text describing business requirements uploaded by users. The initial plan generation module is used to determine the target interface entities that match the business requirement description text and to infer the interface relationships between the target interface entities based on the target large model and the interface knowledge graph, so as to obtain the initial execution plan. The target plan generation module is used to identify whether there are execution obstacles in the target interface entities contained in the initial execution plan during the invocation process through the target big model and based on the interface knowledge graph. If so, an execution adapter node is inserted at a specified position in the initial execution plan to obtain the target execution plan. The execution obstacles include at least data transmission incompatibility and / or lack of security mechanisms. The execution adapter node is used to eliminate the execution obstacles.

[0017] Thirdly, the present invention also provides an electronic device including a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement any of the methods provided in the first aspect.

[0018] Fourthly, the present invention also provides a computer-readable storage medium storing computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement any of the methods provided in the first aspect.

[0019] This invention provides a business process refactoring method and system based on the collaboration of a large model and a knowledge graph. The business process refactoring system has a built-in target large model and stores a pre-configured interface knowledge graph. The interface knowledge graph describes multiple interface entities and the interface relationships between them. First, it receives business requirement description text uploaded by the user. Then, using the target large model and the interface knowledge graph, it determines the target interface entities matching the business requirement description text and infers the interface relationships between these target interface entities to obtain an initial execution plan. Finally, using the target large model and the interface knowledge graph, it identifies whether there are execution obstacles in the invocation process of the target interface entities included in the initial execution plan. If so, an execution adapter node is inserted at a specified position in the initial execution plan to obtain the target execution plan. Execution obstacles include at least data transmission incompatibility and / or missing security mechanisms, and the execution adapter node is used to eliminate these obstacles. This invention, by designing a standardized API interface relationship model and combining the structured storage of the knowledge graph with the intelligent planning capabilities of the large model, achieves efficient API interface matching and invocation, improving the security, operability, and intelligence of business processes, and reducing the cost and risk of enterprise digital transformation.

[0020] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0021] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0022] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0023] Figure 1 A flowchart illustrating a business process reconstruction method based on the collaboration of a large model and a knowledge graph, provided in an embodiment of the present invention; Figure 2 A flowchart illustrating another business process reconstruction method based on the collaboration of a large model and a knowledge graph, provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an API interface relationship triple provided in an embodiment of the present invention; Figure 4 A technical framework diagram for collaborative planning of business processes using large models and knowledge graphs is provided in this embodiment of the invention. Figure 5 A DAG diagram of the execution plan for a "customer order processing" business process is provided in an embodiment of the present invention; Figure 6 A schematic diagram of the structure of a business process reengineering system based on the collaboration of a large model and a knowledge graph, provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] Currently, existing business process refactoring technologies suffer from problems such as unclear API interface relationships, difficulty in integrating large models with business systems, imperfect security and access control, and high learning curve for new employees. Based on this, the present invention provides a business process refactoring method and system based on the collaboration of large models and knowledge graphs, which can effectively solve the above problems.

[0026] To facilitate understanding of this embodiment, a detailed description of a business process refactoring method based on the collaboration of a large model and knowledge graph, disclosed in this embodiment of the invention, is first provided. This method is applied to a business process refactoring system, which has a built-in target large model and stores a pre-configured interface knowledge graph. The interface knowledge graph describes multiple interface entities and the interface relationships between them. (See also...) Figure 1 The diagram shows a business process reconstruction method based on the collaboration of a large model and a knowledge graph. The method mainly includes the following steps S102 to S106: Step S102: Receive the business requirement description text uploaded by the user.

[0027] Among them, the business requirement description text is the result of formally expressing business requirements using natural language.

[0028] Step S104: Using the target big model and based on the interface knowledge graph, determine the target interface entities that match the business requirement description text and infer the interface relationships between the target interface entities to obtain the initial execution plan.

[0029] In one implementation, the business requirement description text is parsed to extract key requirement information; the key requirement information is semantically matched with the tool description information associated with each interface entity in the interface knowledge graph to determine the target interface entity that matches the business requirement; based on the interface relationships (such as data dependency relationships, call order relationships, permission inheritance relationships, etc.) between predefined interface entities in the interface knowledge graph, the execution order and collaboration path between multiple target interface entities are reasoned to generate a corresponding initial execution plan, which is used to describe the target interface entities and the interface relationships between them.

[0030] Step S106: Using the target big model and based on the interface knowledge graph, identify whether there are execution obstacles in the calling process of the target interface entity contained in the initial execution plan. If so, insert an execution adapter node at a specified position in the initial execution plan to obtain the target execution plan. Among them, the execution obstacles include at least data transmission incompatibility and / or lack of security mechanisms. The execution adapter node is used to eliminate the execution obstacles.

[0031] In one implementation, if the interface knowledge graph determines that there are data format or protocol incompatibilities among the target interface entities in the initial execution plan, a first execution adaptation node is inserted between the corresponding target interface entities to achieve data conversion and transmission adaptation; and / or, if the interface knowledge graph determines that the target interface entities in the initial execution plan lack security mechanisms, including insufficient authentication, access control, or data encryption capabilities, a second execution adaptation node is inserted before the corresponding target interface entities to supplement the required security protection functions; after the above adaptation processing, an intermediate execution plan is obtained, and a target execution plan in the form of a directed acyclic graph is constructed based on the intermediate execution plan to guide subsequent process scheduling and execution.

[0032] The business process refactoring method based on the collaboration of large models and knowledge graphs provided in this invention achieves efficient matching and calling of API interfaces by designing a standardized API interface relationship model, combining the structured storage of knowledge graphs and the intelligent planning capabilities of large models, thereby improving the security, operability and intelligence level of business processes and reducing the cost and risk of enterprise digital transformation.

[0033] For ease of understanding, this invention provides a specific implementation of a business process reconstruction method based on the collaboration of a large model and a knowledge graph. See [link to relevant documentation]. Figure 2 The flowchart shown is another business process refactoring method based on the collaboration of large model and knowledge graph, which includes: defining API interface relationship triples; constructing API knowledge graph; collaboratively planning business processes with large model and knowledge graph to generate an execution plan presented in the form of a directed acyclic graph (DAG); executing the process and performing dynamic optimization; and providing visual interaction and auxiliary support.

[0034] The specific implementation process is as follows: Step 1: Define the API interface relationship triplet.

[0035] Construct a triple containing three key parts to clearly define API interface relationships: tool description, input relationship, and output relationship, such as... Figure 3 The diagram shows a structural diagram of an API interface relationship triple.

[0036] (1) Tool Description: Provide a comprehensive description of the API interface, covering the following: (1.1) Basic information: including the unique identifier of the API for accurate identification in the system; system information to which it belongs, specifying its source, such as "Enterprise Resource Planning (ERP) system"; category information, such as "data query type" and "business operation type", to facilitate the classification and management of APIs.

[0037] (1.2) Function description: Describe the core functions of the API in concise and clear language, such as "Query the detailed order history of the customer based on the input customer ID".

[0038] (1.3) Parameter description: List the names, data types, and constraints of the input and output parameters in detail. For example, the input parameter "Customer ID" is a string with a constraint that its length must be 10 digits; the output parameter "Total Order Amount" is a floating-point number with a value greater than 0.

[0039] (1.4) Permissions and security information: Clearly define the permission level required to call the API, such as "ordinary employee level" or "department manager level"; and the security protocol used, such as "HTTPS encrypted transmission" or "Token authentication".

[0040] (2) Input Relationship: Describe the source of API input parameters, specifying which system and API each input parameter is obtained from, whether it comes from user input or system variables, and clarify the parameter conversion rules. For example, the input parameter "customer name" of a certain API comes from the output of the "customer information query API" of the "customer management system", and the conversion rule is to remove special characters and unify the capitalization.

[0041] (3) Output Relationship: Define the destination of API output parameters, that is, which other system APIs or modules the output parameters will be passed to, and the conversion operations that may be required during the transmission process. For example, the output parameter "order number" of "order creation API" will be passed to "order allocation API" of "logistics management system". When transmitting, a specific prefix needs to be added before the order number to meet the format requirements of the logistics system.

[0042] Step 2: Construct the API knowledge graph.

[0043] Based on the triples defined in step 1, an API knowledge graph is constructed, which includes the following three levels: (1) Entity layer: Each API is treated as an independent entity, and its corresponding tool description information is stored in the entity layer. For example, the "Customer Information Query API" entity contains its unique identifier, system to which it belongs, function description, parameter description, and detailed information such as permissions and security information.

[0044] (2) Relationship Layer: Defines various relationships between API entities, mainly including: (2.1) Data Dependency Relationship: Based on input and output relationships, this indicates the data transfer and dependency between APIs. For example, the "Order Creation API" depends on the "Customer Information Query API" to provide customer-related information, which means there is a data dependency relationship of "Customer Information Query API → Order Creation API".

[0045] (2.2) Call order relationship: The order of API calls is determined according to business logic. For example, in the order processing flow, the "Inventory Query API" must be called first to confirm that the inventory is sufficient before the "Order Creation API" can be called. That is, there is a call order relationship between "Inventory Query API" and "Order Creation API".

[0046] (2.3) Permission inheritance relationship: Record the permission inheritance between APIs. For example, the "Advanced Permission API" inherits some permissions from the "Normal Permission API", which means that the permission requirements of the "Normal Permission API" must be met before calling the "Advanced Permission API".

[0047] (3) Attribute layer: Stores dynamic attribute information of the API, such as the most recent call time, call success rate, average response time, etc. These attributes can reflect the running status of the API in real time and provide data support for subsequent process optimization. For example, by monitoring the average response time of the "order query API", if it is found that the response time is too long, it may be necessary to optimize the performance of the API or adjust its calling strategy in the business process.

[0048] Step 3: The large model and knowledge graph collaboratively plan business processes, generating an execution plan presented in the form of a directed acyclic graph (DAG). See also Figure 4 The diagram illustrates a technical framework for collaborative planning of business processes using a large-scale model and knowledge graph. This framework includes: receiving user natural language requirements (i.e., the aforementioned business requirement description text); obtaining a structured task description through the LLM requirement parsing module, combined with the API knowledge graph constructed in step 2; performing the following operations through the knowledge graph retrieval module: entity layer: matching the target API (i.e., the target interface entity); relation layer: extracting API dependencies / permissions / security rules; performing the following operations through the LLM process planning module: inferring the API call order, planning parameter passing / conversion paths; inserting permission / security verification nodes; generating a DAG execution plan; performing the following operations in conjunction with the knowledge graph verification module: verifying the legality of the call order, verifying parameter input / output compatibility, and checking permission / security rule matching; and finally, performing process execution and dynamic optimization through step 4.

[0049] After receiving business requirements expressed by users in natural language, the large model collaborates with the knowledge graph to plan the business process. The specific steps are as follows: (1) Requirement analysis, that is: analyzing the key information of the requirements corresponding to the business requirement description text.

[0050] In one implementation, the large model parses the user's natural language request into a structured task description, extracting key information such as the target of the operation, the type of operation, and relevant conditions. For example, for the user request "query orders from customers in Beijing within the past month and calculate the total order amount", the large model parses the target of the operation as "orders from customers in Beijing", the type of operation as "query" and "calculate the total order amount", and the relevant condition as "within the past month".

[0051] Specifically: (1.1) Prompt word template design (forced output structure): prompt_template = """ Please parse the following user natural language requirements into a structured task description, outputting it strictly in JSON format, including the following fields: 1. operation_object: The object of the operation (an entity noun, such as orders from customers in the Beijing area); 2. operation_type: Operation type (array, such as ["Query", "Total order amount"]); 3. conditions: Relevant conditions (dictionary, such as {"time range": "past month", "region": "Beijing"}); 4. expected_output: Expected output (e.g., "structured data containing a list of orders and total amount").

[0052] User requirements: {user_text} Output requirement: Return only a JSON string, without any other interpretation.

[0053] """ (1.2) Large model call and result parsing: (a) Fill in the prompt word template: prompt = prompt_template.format(user_text=user_text); (b) Call the large model interface: llm_response = Call the large model(prompt, model="qwen-x"); (c) Parse and validate the JSON.

[0054] (1.3) Output of the parsed result: { "operation_object": "Orders from customers in the Beijing area", "operation_type": ["query", "total order amount"], "conditions": {"Time range": "Past month", "Location": "Beijing"}, "expected_output": "List of customer orders and total order amount in the Beijing area over the past month" } (2) API matching, that is: matching the key information of the requirement with the tool description information corresponding to the interface entity contained in the interface knowledge graph to determine the target interface entity for matching the business requirement description text.

[0055] In one implementation, the large model retrieves target interface entities that match the parsed key demand information from the entity layer of the knowledge graph. For example, based on the operation "query order," it matches "order query API"; based on "statistics total order amount," it matches "order amount statistics API." Simultaneously, APIs with insufficient user permissions are filtered out based on the permission information in the knowledge graph.

[0056] Specifically: (2.1) The knowledge graph entity layer stores the structured metadata of the API; (2.2) Retrieval and Matching Logic: (a) Extract key semantic features from the input business requirement description text to generate a set of key requirement information; (a) Based on key demand information, preliminary matching is performed in the entity layer of the interface knowledge graph to locate candidate interface entities; (a) Perform access control filtering on candidate interface entities to exclude targets that the current user or context does not have permission to call; (a) Use the Large Language Model (LLM) to perform semantic completion and intent expansion on the original query, handle matching cases with ambiguous, incomplete or synonymous expressions, and improve recall and matching accuracy.

[0057] Furthermore, user requests can be dynamically completed through human-computer interaction: when the large language model, based on interface knowledge graph analysis, discovers that key contextual information is missing from the user's input request—such as the lack of explicit specification of the required data format, communication protocol, or permission restrictions—it automatically identifies the information gap and generates targeted rhetorical questions to guide the user in supplementing the relevant information. Exemplary rhetorical questions include: "Should the data you need be returned in JSON or CSV format?" or "Is your current account authorized to call the order query API?". In this embodiment of the invention, the interactive feedback mechanism can improve the semantic completeness of the request before execution, enhancing interface matching accuracy and system execution security.

[0058] (3) Relational reasoning, that is: based on the interface relationships between interface entities contained in the interface knowledge graph, reason the interface relationships between target interface entities to obtain the initial execution plan.

[0059] In one implementation, the large model leverages data dependencies and call order relationships within the relational layer of the interface knowledge graph to deduce the reasonable call order and data transfer path between APIs. For example, to fulfill the requirement of "querying orders from customers in Beijing within the past month," the large model, based on the relationships in the knowledge graph, determines to first call the "Customer Information Filtering API" to obtain a list of customers in Beijing, and then pass the customer list as a parameter to the "Order Query API" to obtain order information that meets the criteria.

[0060] Specifically: (3.1) Obtain the relational layer structure of the interface knowledge graph; (3.2) Execute reasoning logic based on the collaboration of interface knowledge graph and large language model, including: (a) Extract target interface entities and their calling relationships, dependencies, and data flow information from the knowledge graph; (b) Construct structured reasoning prompts, for example: prompt = f""" Given API relationships: {api_relations}, task description: {task_desc} Please deduce: 1. API call order (array, arranged in order of execution); 2. Data transfer path (dictionary, key is source API, value is target API + transferred fields).

[0061] Output format: JSON, containing "api_order" and "data_path" fields.

[0062] """ (c) The large model is invoked to perform inference processing based on structured inference prompts to generate an initial execution plan, which can be understood as an API call sequence; (d) Call the large model again or combine it with the graph traversal algorithm to perform knowledge graph consistency verification on the generated API call sequence, detect and eliminate potential circular dependencies, illegal call paths or data breakpoints, and ensure the schedulability and topology rationality of the execution plan.

[0063] (4) Parameter planning, that is: when data transmission incompatibility is found between target interface entities in the initial execution plan based on the interface knowledge graph, the first execution adapter node is inserted between the target interface entities.

[0064] In one implementation, the large model plans the parameter transmission and transformation process based on the input and output relationships of the APIs. For example, the customer ID format output by the "Customer Information Filtering API" is slightly different from the format required by the "Order Query API". Based on the transformation rules defined in the input relationships, the large model plans to insert a parameter format transformation step between the two APIs to ensure that the data can be transmitted correctly.

[0065] Specifically: (4.1) Extract the parameter passing rules corresponding to the target interface entities contained in the initial execution plan from the interface knowledge graph. The parameter passing rules include, but are not limited to: the data format, field name, data type, structure definition of the output parameters of the preceding interface, and the receiving standards required by the input of the subsequent interface.

[0066] (4.2) For any two target interface entities that have an interface relationship, perform the following operation: (a) Based on the parameter passing rules corresponding to the two target interface entities, identify whether there is a data transmission incompatibility between the two target interface entities.

[0067] In one implementation, the actual output parameters of the preceding interface are compared item by item with the expected input parameters of the following interface. Specifically, this includes: determining whether the output data format (e.g., JSON, CSV) is supported by the following interface; checking whether the naming of key fields is consistent or conforms to a preset mapping relationship; verifying whether data types (e.g., integer, string, timestamp) match; and confirming whether nested structures (e.g., arrays, objects) can be correctly parsed. If any inconsistency or inability to be directly parsed is found in any of the above dimensions—for example, the preceding interface outputs XML while the following interface only accepts JSON, or a field name is "userId" but the following interface expects "user_id"—then it is determined that there is a data transmission incompatibility between the two.

[0068] (b) If so, determine the conversion steps and / or parameter passing method between the two target interface entities according to the preset large model conversion prompts. For example, the large model conversion prompts are as follows: prompt = f""" Given incompatible parameter pairs: {incompatible_pairs}, the transformation rules in KG are: {KG query all transformation rules()} Please plan for each incompatible pair: 1. Conversion steps (such as calling conversion functions / scripts); 2. Parameter passing method (e.g., direct passing / intermediate storage).

[0069] Output format: JSON, key is "source_api->target_api", value is the conversion rule.

[0070] """ In practical implementation, the large model infers the necessary transformation steps and parameter passing methods to achieve data compatibility based on the aforementioned clues. Transformation steps include, but are not limited to: data format conversion (e.g., converting JSON to XML), field name mapping (e.g., converting "orderId" to "order_id"), data type adjustment (e.g., converting strings to numbers), structural reorganization (e.g., flattening nested objects), or unit normalization (e.g., standardizing timestamp formats). Parameter passing methods include determining whether parameters are passed through the request body, query parameters, or request headers, and whether batch transmission or default values ​​are needed.

[0071] (c) Insert a first execution adapter node between the two target interface entities. The first execution adapter node is used to implement the conversion steps and / or parameter passing methods to eliminate the data transmission incompatibility between the two target interface entities.

[0072] In practical implementation, based on the transformation steps and / or parameter passing methods output by the large model, the system dynamically inserts a first execution adapter node into the execution link between two target interface entities. This node is configured to execute the transformation steps and / or parameter passing methods determined by the model, immediately reshaping and encapsulating data after the preceding interface outputs data, and forwarding parameters in a form acceptable to the subsequent interface, thereby achieving semantic and structural data alignment. This approach enables automatic construction of adaptation logic without manual intervention, eliminating data transmission barriers caused by differences in interface definitions, and improving the system's integration capabilities and execution reliability in complex environments.

[0073] (5) Security and permission planning, that is: if the target interface entity in the initial execution plan is found to have a missing security mechanism based on the interface knowledge graph, a second execution adapter node is inserted before the target interface entity.

[0074] In one implementation, by combining the permission and security information of APIs in the knowledge graph, the large model rationally plans the execution nodes of permission verification and security measures in the business process. For example, for APIs requiring advanced permissions, a "permission verification API" is planned to be inserted before the call to ensure that the user has the corresponding permissions; for APIs involving sensitive data, the appropriate security protocol is planned to be used for encryption during data transmission.

[0075] Specifically: (5.1) Extract the permissions and security rules corresponding to the target interface entities contained in the initial execution plan from the interface knowledge graph.

[0076] In one implementation, the system retrieves the permissions and security rules associated with each target interface entity included in the plan from the interface knowledge graph. Permission information includes, but is not limited to: the authentication type required to call the interface (e.g., API Key, OAuth token, JWT), user role or permission level requirements (e.g., administrator-only access), and access control policies of the organization or project domain. Security rules include, but are not limited to: whether HTTPS transmission is mandatory, whether sensitive fields in request parameters need to be encrypted, and whether there are call frequency limits or audit logging requirements.

[0077] (5.2) For target interface entities with non-empty permissions and security rules, perform the following operations: (a) Determine the permission verification node, security measure execution node, and node execution order corresponding to the target interface entity according to the preset large model planning prompt words. Among them, the second execution adaptation node includes the permission verification node and the security measure execution node. (b) Insert the permission verification node and the security measure execution node before the target interface entity according to the node execution order to eliminate the lack of security mechanisms in the target interface entity.

[0078] For example, large model planning prompts are shown below: prompt = f""" Given API security information: {api_security_info}, current user permissions: {get user permissions()} Please plan: 1. Permission verification node (e.g., inserting a permission verification API before a high-privilege API); 2. Implementation nodes of security measures (such as encryption before transmission of sensitive data and desensitization of output); 3. Node execution order (e.g., verification → API call → encrypted transmission).

[0079] Output format: JSON, containing "permission_nodes" and "security_nodes" fields.

[0080] """ In practical implementation, after extracting the permissions and security rules corresponding to the target interface entity, if analysis reveals that the current execution context lacks necessary authentication mechanisms or fails to meet the security constraints required for interface calls, a security adaptation logic generation process is initiated. The system decomposes and plans the security capabilities required for the interface based on preset large-scale model planning prompts. The large-scale model plans security execution schemes, including permission verification nodes, security measure execution nodes, and node execution order, according to the aforementioned prompts. Based on the security execution scheme generated by the large-scale language model, corresponding second execution adaptation nodes are dynamically inserted before the target interface entity according to the determined node execution order. The permission verification node is used to intercept illegal calls and verify the validity of access credentials; the security measure execution node is responsible for implementing specific security operations, such as key negotiation, field encryption, and access record generation. Through this method, a front-end protection chain that meets the interface security requirements can be automatically constructed at runtime, compensating for the lack of security mechanisms in the original call flow and ensuring that the entire execution process meets multi-dimensional security goals such as authentication, authorization, confidentiality, and auditability.

[0081] (6) Execution plan generation, that is: based on the intermediate execution plan, generate the target execution plan in the form of a directed acyclic graph.

[0082] In one implementation, the large model synthesizes the above analysis results to generate a detailed business process execution plan. This plan is presented in the form of a directed acyclic graph (DAG), containing information such as the call order of each API, parameter passing path, permission verification, and execution nodes of security measures. For example, the execution plan might include: first calling the "Customer Information Filtering API," then, after permission verification and data encryption, passing the output to the "Order Query API," then processing the output of the "Order Query API" and passing it to the "Order Amount Statistics API," and finally displaying the statistical results.

[0083] Specifically, the DAG generation prompts are as follows: prompt = f""" Please generate an execution plan in DAG format based on the following planning information: 1. API call order: {final_plan["api_order"]} 2. Parameter passing / conversion rules: {final_plan["transfer_rules"]} 3. Permission verification nodes: {final_plan["permission_nodes"]} 4. Security measures nodes: {final_plan["security_nodes"]} DAG requirements: - A node contains node_id, node_type, action, and dependencies; - An edge contains source_node, target_node, and param_mapping; - Ensure acyclicity and strictly adhere to the dependency order; - Includes all permission / security nodes, located in accordance with the plan.

[0084] Output format: JSON, containing "nodes" and "edges" fields.

[0085] The large model generates a target execution plan in DAG format based on the above prompts.

[0086] Furthermore, the target execution plan can be subjected to rigid graph database validation and flexible large-model validation. If both validations pass, the target execution plan is executed. For example, the validation process is as follows: (I) Perform graph database rigid verification on the target execution plan, including: verifying whether there are loops in the target execution plan through the graph database, and determining whether the graph database rigid verification is passed if there are no loops in the target execution plan.

[0087] Specifically, the system maps the target execution plan to a graph-based relationship of nodes and edges, and imports it into a graph database for topology analysis. By traversing the interface call sequence in the execution path, it detects whether there are circular dependencies or closed-loop call paths. If an interface is found to be repeatedly triggered in the execution chain and form a closed loop, a loop is determined to exist, and the execution plan does not meet the scheduling requirements; only when it is confirmed that the entire execution path is an acyclic directed structure, i.e., there are no feedback loops, is the system considered to have passed the rigid verification of the graph database.

[0088] (II) Under the condition of rigid verification through graph database, determine the plan complexity level corresponding to the target execution plan, so as to determine whether to perform large model flexible verification on the target execution plan based on the plan complexity level.

[0089] Specifically, based on the rigid verification, the complexity of the execution plan is further evaluated. The system comprehensively judges the complexity of its execution logic based on characteristics such as the number of interfaces included in the plan, the branching degree of the data transmission path, the frequency of cross-system calls, and the existence of conditional branches, classifying it into low, medium, and high complexity levels. Based on the determined complexity level, the system decides whether to initiate large-scale model flexible verification. Low-complexity plans with simple structures and clear paths can be directly adopted; however, for medium-to-high complexity execution plans, due to the potential risk of implicit semantic biases or insufficient understanding of business intent, the system determines that further semantic-level review is required, thus triggering the large-scale model flexible verification process.

[0090] Specifically, the technical characteristics of the target execution plan can be extracted from the following dimensions: 1) Number of Interfaces (N): The total number of independent interface call nodes included in the execution plan. The more interfaces there are, the longer the process, and the higher the probability of errors and the more difficult it is to manage.

[0091] 2) Branching degree of the data transmission path (B): This refers to whether there are parallel branches or multiple outputs during execution, i.e., the output of one interface is consumed by multiple subsequent interfaces simultaneously. The system measures the branching degree by analyzing the maximum fan-out value in the data dependency graph.

[0092] 3) Cross-system call frequency (C): This counts the number of calls between different business systems or service domains involved in the execution plan. Cross-system calls are often accompanied by issues such as protocol conversion, network latency, and access control isolation, increasing coordination costs.

[0093] 4) Does a conditional branch exist (D)? This determines whether the execution path contains branch logic dynamically selected based on runtime data (e.g., "If the coal quality test result exceeds the standard, then trigger the alarm process"). The existence of a conditional branch indicates that the process has non-linear behavior, significantly increasing the difficulty of understanding and verification. If a branch exists, D=1; otherwise, D=0.

[0094] After obtaining the above features, the system uses a weighted scoring method to comprehensively calculate a plan complexity score. This is used to quantify the overall level of complexity. An example calculation method is as follows: ; in, , , , Preset weighting coefficients (e.g.) This reflects the degree to which each factor contributes to the overall complexity. Indicates the number of interfaces Normalization was performed to mitigate the difference in magnitude. Indicates the frequency of cross-system calls Nonlinear compression is performed to improve smoothness.

[0095] Then, the calculated score The complexity level is determined by comparing it with a preset threshold range. For example: if (e.g., 1.5) is then classified as low complexity, indicating a simple, highly linear process that is easy to understand and execute; if (e.g., 1.5 ≤ S < 3.0), then it is classified as medium complexity, and potential semantic biases should be treated with caution; if If the value is ≥ 3.0, it is judged as a high complexity level, indicating that the process structure is complex and there is a high risk of misunderstanding or execution failure.

[0096] Ultimately, the complexity level is used as a control signal to determine whether to enter the large model flexible verification stage: only when the medium to high complexity level is triggered will the deep semantic consistency verification based on the large language model be initiated, thereby achieving an organic combination of efficient resource allocation and intelligent review.

[0097] (III) If the judgment result is yes, perform large model flexible verification on the target execution plan, including: using the target large model, according to the preset large model verification prompt words, based on the business requirement description text and interface knowledge graph, determine the score value corresponding to the target execution plan, and if the score value is higher than the preset threshold, determine that the target execution plan has passed the large model flexible verification.

[0098] After initiating flexible verification, the system invokes the large model, combining the original business requirement description text and the underlying interface knowledge graph to comprehensively evaluate the target execution plan. Specifically, the execution plan content, the functional definitions of relevant interfaces, and task background information are organized into natural language input according to preset large model verification prompts, guiding the model to score from multiple dimensions such as semantic consistency, functional coverage, and call rationality. The score reflects the degree of matching between the target execution plan and the user's original business intent, as well as the execution risks it may face in the actual scenario. When the score is higher than the preset rationality threshold, it indicates that the plan is not only structurally compliant but also highly aligned with the business objectives at the semantic level, thus passing the large model flexible verification; otherwise, it is marked as an item to be optimized and returned to the adjustment module for correction. Through the above-mentioned layered verification mechanism, dual protection of structural security and semantic correctness is achieved, ensuring system stability while improving the credibility and usability of intelligent orchestration results.

[0099] Step 4: Execute the process and perform dynamic optimization.

[0100] (1) Execution Plan Implementation: The system calls each API sequentially according to the execution plan generated by the large model. Before calling each API, permission verification and security measures are implemented to ensure the legality and security of the API call. For example, before calling the "Order Creation API", the "Permission Verification API" is called to verify user permissions, and the input parameters are encrypted according to the security protocol. During the API call process, parameter passing and conversion are strictly carried out according to the parameter plan to ensure the accuracy and consistency of the data.

[0101] (2) Exception Handling: If an exception occurs during the API call, such as the API returning an error message or parameter mismatch, the system will take corresponding measures according to the exception type. For example, if the "Order Query API" returns the error message "Data does not exist", the system will query the knowledge graph to see if there is a backup API or data source and try to obtain the required data through other means; if it is a parameter mismatch problem, the system will dynamically adjust the parameters according to the parameter relationships and transformation rules recorded in the knowledge graph and re-call the API.

[0102] (3) Dynamic Optimization: The system monitors the running status of APIs and the execution of business processes in real time. Based on the dynamic attribute information of APIs recorded in the attribute layer of the knowledge graph, such as call success rate and average response time, the system dynamically optimizes the business processes. For example, if the call success rate of a certain API is found to be low, the system will automatically adjust the call frequency of that API in the business process or try to find a more reliable alternative API; if the average response time of a certain API is too long, the system will analyze whether the response time can be shortened by optimizing the parameter passing method or adjusting the call order. At the same time, the knowledge graph will regularly update the information of its relationship layer and attribute layer according to the actual running status of the API to ensure the accuracy and timeliness of the knowledge graph.

[0103] Step 5: Provide visual interaction and assistance support.

[0104] (1) Visualization: The business process execution plan is presented to the user in an intuitive graphical way through a visual interface. The graph clearly marks the location of each API, the call order, the parameter passing path, and the execution nodes of permission verification and security measures, so that the user can understand the whole picture of the business process at a glance. For example, the "order processing process" is displayed in the form of a flowchart, with each API represented by a node, the connection between nodes indicating the direction of data transmission, and the relevant parameters and operation information marked on the nodes and the connection.

[0105] (2) New Employee Assistance Function: Provides comprehensive support for new employees to help them quickly understand and master business processes. When a new employee inputs business requirements, the system will intelligently recommend relevant APIs and business process templates based on information in the knowledge graph, and explain in detail the function, parameter requirements, and role of each API in the business process. During the actual operation of the new employee, the system provides real-time operation prompts and guidance, such as which API to call and which parameters to input. If the new employee encounters problems during the operation, the system will combine information in the knowledge graph to provide detailed fault diagnosis and solution suggestions. For example, when a new employee encounters insufficient permissions when calling the "Order Creation API", the system will prompt that the corresponding permissions need to be applied for, and provide the specific process for permission application and relevant responsible person information.

[0106] In summary, the embodiments of the present invention have at least the following characteristics: 1. Improve API Interface Management Efficiency: By defining standardized API interface relationship triples, the functionality, parameters, and permissions of API interfaces are clearly and accurately described, effectively solving the problem of unclear API interface relationships. This not only reduces the difficulty of system integration but also reduces development and maintenance costs caused by interface incompatibility. According to statistics from actual application cases, after adopting the method of this invention, enterprises have shortened development time due to API interface issues by more than 50% and reduced maintenance costs by about 40% during the integration of new systems.

[0107] 2. Enhanced Integration of Large-Scale Model with Business Systems: This invention achieves deep integration of the large-scale model with enterprise business system APIs. Leveraging the comprehensive understanding of APIs through knowledge graphs, the large-scale model can accurately understand business requirements and plan reasonable API call flows, eliminating reliance on fixed call templates and improving the applicability and flexibility of the large-scale model in enterprise business scenarios. For example, when facing frequent changes in enterprise business processes, the large-scale model can quickly re-plan API call flows based on new business requirements and information from the knowledge graph, ensuring the normal operation of the business and reducing response time from several days in traditional methods to several hours.

[0108] 3. Enhanced Security and Access Control: A unified security and access control mechanism built on a knowledge graph effectively avoids access vulnerabilities and security risks during API calls. By rationally planning the execution nodes of access verification and security measures during the business process planning phase, it ensures that every API call is conducted securely and compliantly. In practical applications, the incidence of security incidents caused by API calls has been reduced by more than 80%, safeguarding the security of enterprise data and the stability of business operations.

[0109] 4. Reduced Learning Difficulty for New Employees: The visual interactive interface and new employee assistance features significantly reduce the learning cost and learning difficulty for new employees regarding business processes. Through intuitive visual displays and real-time operation guidance, new employees can quickly understand the logic and operation methods of business processes, reducing business errors caused by operational mistakes. According to internal training data, the time it takes for new employees to master business processes has been shortened from several weeks with traditional training methods to several days, and the operational error rate has been reduced by about 60%, improving the company's business operation efficiency.

[0110] 5. Dynamic Business Process Optimization: The system can monitor the API's operational status and business process execution in real time, and dynamically optimize them based on actual conditions. Through analysis of API dynamic attributes and real-time updates of the knowledge graph, business processes are continuously adjusted to improve efficiency and quality. For example, during peak business periods, the system can automatically optimize business processes based on API response time and call success rate, ensuring efficient business operation and improving overall business processing efficiency by more than 30%.

[0111] Furthermore, this embodiment of the invention provides an application example of a business process refactoring method based on the collaboration of a large model and knowledge graph. Taking a company's sales order processing business as an example, it involves key APIs such as "Customer Information Query API," "Inventory Query API," "Order Creation API," and "Payment Verification API." The business process is refactored according to the method of this invention. See also Figure 5 The diagram shown is a DAG (Directed Acyclic Graph) of the execution plan for a "customer order processing" business process. Specifically: 1. Define API interface relationship triples: (1) Customer Information Query API: ① Tool Description: Basic information: The unique identifier is "API-CUS-001", the system it belongs to is "Customer Relationship Management (CRM) System", and the category is "Data Query".

[0112] Function Description: Based on the entered customer ID or customer name, query detailed customer information, including contact information, credit rating, etc.

[0113] Parameter description: Input parameter "Customer Identifier", data type is string, can accept customer ID or customer name; Output parameter "Customer Details", data type is structure, containing fields such as "Contact Information" (string type) and "Credit Rating" (enumeration type, values ​​are "A", "B" or "C").

[0114] Access and security information: The access level is "Ordinary Employee Level" and the "HTTPS encrypted transmission protocol" is used.

[0115] ② Input Relationship: The input parameter "Customer Identifier" can be derived from user input without the need for conversion rules.

[0116] ③ Output Relationship: The output parameter "Credit Rating" will be passed to the "Order Creation API" as one of the criteria for determining whether an order can be created, and no conversion is required.

[0117] (2) Inventory Query API: ① Tool Description: Basic information: The unique identifier is "API-STOCK-001", the system it belongs to is "Inventory Management System", and the category is "Data Query".

[0118] Function Description: Based on the input product number, query the current inventory quantity of the product.

[0119] Parameter description: Input parameter "Product Number", data type is string; Output parameter "Inventory Quantity", data type is integer.

[0120] Permissions and security information: The permission level is "Ordinary Employee Level" and the security protocol is "Token Authentication".

[0121] ② Input relationship: The input parameter "product number" comes from the sales order entry module and does not require conversion rules.

[0122] ③ Output Relationship: The output parameter "Inventory Quantity" is passed to the "Order Creation API" to determine whether the inventory is sufficient, and no conversion is required.

[0123] (3) Order Creation API: ① Tool Description: Basic information: Unique identifier "API-ORDER-001", system to which it belongs is "Order Management System", category is "Business Operation".

[0124] Function Description: Creates sales orders based on customer information, product information, and inventory quantity, and generates a unique order number.

[0125] Parameter description: Input parameters include "Customer Details" (from the "Customer Information Query API" output), "Product Number" (same as the "Inventory Query API" input parameter), and "Inventory Quantity" (from the "Inventory Query API" output); Output parameter is "Order Number", and the data type is string.

[0126] Access and security information: The access level is "Department Manager Level" and uses the "HTTPS encrypted transmission + signature verification" protocol.

[0127] ② Input relationships: "Customer details" comes from the output of "API-CUS-001", "Product number" comes from the sales order entry module, and "Inventory quantity" comes from the output of "API-STOCK-001". No conversion rules are required for any of them.

[0128] ③ Output relationship: The output parameter "order number" is passed to the "payment verification API" for association with the order in the payment process, and no conversion is required.

[0129] (4) Payment Verification API: ① Tool Description: Basic information: The unique identifier is "API-PAY-001", the system it belongs to is "Payment Management System", and the category is "Business Operation".

[0130] Function Description: Verify the payment status of an order based on its order number.

[0131] Parameter description: Input parameter "Order Number", data type is string; Output parameter "Payment Status", data type is enumeration, values ​​are "Paid", "Unpaid", "Paying".

[0132] Access and security information: The access level is "financial personnel level", and the security protocol is "HTTPS encrypted transmission + two authentication".

[0133] ② Input relationship: The input parameter “order number” comes from the output of “API-ORDER-001”, and no conversion rules are required.

[0134] ③ Output relationship: The output parameter "payment status" is fed back to the order management system to update the order status, without the need for conversion.

[0135] 2. Construct an API knowledge graph (1) Entity Layer: In the entity layer of the knowledge graph, four entities are created: “API-CUS-001”, “API-STOCK-001”, “API-ORDER-001”, and “API-PAY-001”. Each entity stores the corresponding tool description information. For example, the “API-ORDER-001” entity stores its system, function description, parameter description, and permission and security information.

[0136] (2) Relationship layer: ① Data Dependencies: Establish the following data dependencies: “API-CUS-001” → “API-ORDER-001” (“API-ORDER-001” depends on “API-CUS-001” for providing customer details), “API-STOCK-001” → “API-ORDER-001” (“API-ORDER-001” depends on “API-STOCK-001” for providing inventory quantity), and “API-ORDER-001” → “API-PAY-001” (“API-PAY-001” depends on “API-ORDER-001” for providing order number).

[0137] ② Call order relationship: Determine the call order relationship of “API-CUS-001” and “API-STOCK-001” being able to be called in parallel, then “API-ORDER-001” being called, and finally “API-PAY-001” being called.

[0138] ③ Permission inheritance relationship: The "API-ORDER-001" permission is inherited from the "Ordinary Employee" permission (because obtaining some input parameters requires ordinary employee permission), and it also needs "Department Manager" permission; the "API-PAY-001" permission is inherited from the "Department Manager" permission (because obtaining the order number requires permission verification for order creation), and it also needs "Finance Personnel" permission.

[0139] (3) Attribute layer: Real-time recording of dynamic attributes of each API. For example, the most recent call time of "API-CUS-001" is "2024-10-10 10:00:00", the call success rate is 99%, and the average response time is 0.5 seconds; the most recent call time of "API-ORDER-001" is "2024-10-10 10:05:00", the call success rate is 98%, and the average response time is 1 second, etc.

[0140] 3. Collaborative Planning of Large Models and Knowledge Graphs Suppose a user requests that "create a sales order for customer 'Zhang San' containing product 'P001' and verify the payment status."

[0141] (1) Requirement analysis: The large model analyzes the operation objects as customer "Zhang San" and product "P001", and the operation types are creating a sales order and verifying payment status.

[0142] (2) API Matching: Based on the requirements, "API-CUS-001" is matched to obtain information about customer "Zhang San", "API-STOCK-001" is matched to query the inventory of product "P001", "API-ORDER-001" is matched to create an order, and "API-PAY-001" is matched to verify the payment status. At the same time, based on the permission information, it is confirmed that the user has the permission to call these APIs (assuming the user is a department manager, who has the permission required for "API-ORDER-001", and the financial personnel's permission can be satisfied through subsequent processes to call "API-PAY-001").

[0143] (3) Relational reasoning: Based on the relational layer of the knowledge graph, it is determined that “API-CUS-001” is called first to obtain customer information, and “API-STOCK-001” is called in parallel to query inventory. Then, the results of both are passed to “API-ORDER-001” to create an order, and finally the order number is passed to “API-PAY-001” to verify the payment status.

[0144] (4) Parameter planning: The output "Customer Details" of "API-CUS-001" is directly passed to "API-ORDER-001", and the output "Inventory Quantity" of "API-STOCK-001" is also passed to "API-ORDER-001". Since the API parameter formats are matched, no additional parameter conversion steps are required.

[0145] (5) Security and Access Control Planning: Before calling “API-ORDER-001”, plan to call the “Access Control API” to verify whether the user has “Department Manager Level” permissions; before calling “API-PAY-001”, plan to call the “Access Control API” to verify whether the user has “Finance Personnel Level” permissions. At the same time, in accordance with the security protocols of each API, perform corresponding encryption and verification operations during data transmission.

[0146] (6) Execution Plan Generation: The execution plan generated by the large model is presented in the form of a DAG graph, including nodes “API-CUS-001”, “API-STOCK-001” (parallel execution), “API-ORDER-001”, and “API-PAY-001”, and the lines between nodes indicate the direction of data transmission. At the same time, the execution nodes for permission verification and security measures are marked. For example, “Department Manager Permission Verification” is marked before the “API-ORDER-001” node, and “Finance Personnel Permission Verification” is marked before the “API-PAY-001” node.

[0147] 4. Process Execution and Dynamic Optimization (1) Execution Plan Implementation: According to the execution plan, the system first calls "API-CUS-001" and "API-STOCK-001" in parallel. Before calling "API-CUS-001", HTTPS encrypted transmission is performed; before calling "API-STOCK-001", token authentication is performed. "API-CUS-001" returns the detailed information of customer "Zhang San", and "API-STOCK-001" returns the inventory quantity of product "P001". Then, this information is passed to "API-ORDER-001". Before calling "API-ORDER-001", HTTPS encrypted transmission and signature verification are performed, and the user's "department manager level" permissions are verified. "API-ORDER-001" successfully creates an order and returns the order number. Finally, the order number is passed to "API-PAY-001". Before calling "API-PAY-001", HTTPS encrypted transmission and two-factor authentication are performed, and the user's "financial personnel level" permissions are verified. "API-PAY-001" returns the payment status.

[0148] (2) Exception Handling: Suppose that when calling "API-ORDER-001", the call fails due to network issues. After detecting the exception, the system queries the knowledge graph and finds that the API has an alternative call address (assuming a backup mechanism exists). It then attempts to call "API-ORDER-001" again from the alternative address. If the alternative call also fails, the system records the failure information and reports the exception to the user, indicating that there may be a system failure and suggesting that they try again later. At the same time, the knowledge graph updates dynamic attributes such as the success rate of "API-ORDER-001" calls.

[0149] (3) Dynamic Optimization: The system continuously monitors the operational status of each API. For example, it was found that the average response time of "API-PAY-001" was gradually increasing, which was analyzed to be due to excessive load on the payment system server. Based on this situation, the knowledge graph marked the performance of "API-PAY-001" as degraded, and the system attempted to adjust the business process, such as delaying the payment verification operation of some non-urgent orders during peak payment periods, in order to reduce server pressure and optimize the overall business process.

[0150] 5. Visual interaction and auxiliary support (1) Visual Display: The sales order processing flow is displayed in the form of a flowchart through a visual interface. Each API is represented by a node, with the API name and brief function labeled inside the node, such as "API-CUS-001 (Query Customer Information)". The lines between nodes indicate the direction of data transmission, and the parameters transmitted are labeled on the lines, such as "Customer Details" and "Inventory Quantity". At the same time, permission verification and security measures information are labeled near the nodes, such as "Department Manager Permission Verification, HTTPS Encryption + Signature Verification" next to the "API-ORDER-001" node.

[0151] (2) New Employee Assistance Function: When a new employee inputs the requirement of "creating a sales order and verifying payment for a customer" on the operation interface, the system recommends relevant APIs such as "API-CUS-001", "API-STOCK-001", "API-ORDER-001", and "API-PAY-001" based on knowledge graph information, and provides a detailed introduction to the function, parameter requirements, and role of each API in the process. When a new employee selects to call "API-ORDER-001", the system prompts in real time that "department manager level" permissions are required and guides the new employee through the permission application process (if permissions are insufficient). If the new employee encounters problems during the operation, such as incorrect input parameter format, the system provides the error reason and solution based on the knowledge graph, such as prompting "The format of the customer ID you entered does not match the API requirements. It should be a 10-digit number. Please re-enter it".

[0152] As can be seen from the above embodiments, the present invention can effectively realize the collaborative reconstruction of enterprise business processes driven by large models and knowledge graphs, solve many problems in existing business processes, and improve the efficiency and quality of enterprise business processing.

[0153] Based on the foregoing embodiments, this invention provides a business process refactoring system based on the collaboration of a large model and a knowledge graph. The business process refactoring system has a built-in target large model and stores a pre-configured interface knowledge graph. The interface knowledge graph is used to describe multiple interface entities and the interface relationships between them; see also... Figure 6 The diagram shown illustrates the architecture of a business process reengineering system based on the collaboration of a large model and a knowledge graph. This system includes the following components: Text receiving module 602 is used to receive business requirement description text uploaded by users; The initial plan generation module 604 is used to determine the target interface entities that match the business requirement description text and to infer the interface relationships between the target interface entities through the target large model and based on the interface knowledge graph, so as to obtain the initial execution plan. The target plan generation module 606 is used to identify whether there are execution obstacles in the calling process of the target interface entity contained in the initial execution plan through the target big model and based on the interface knowledge graph. If so, an execution adapter node is inserted at a specified position in the initial execution plan to obtain the target execution plan. The execution obstacles include at least data transmission incompatibility and / or lack of security mechanisms. The execution adapter node is used to eliminate the execution obstacles.

[0154] The business process refactoring system based on the collaboration of large models and knowledge graphs provided in this invention achieves efficient matching and calling of API interfaces by designing a standardized API interface relationship model, combining the structured storage of knowledge graphs and the intelligent planning capabilities of large models, thereby improving the security, operability and intelligence of business processes and reducing the cost and risk of enterprise digital transformation.

[0155] In one implementation, the target plan generation module 606 is specifically used for: If, based on the interface knowledge graph, it is found that there is data transmission incompatibility between target interface entities included in the initial execution plan, a first execution adapter node is inserted between the target interface entities; and / or, if, based on the interface knowledge graph, it is determined that there is a lack of security mechanism in the target interface entities included in the initial execution plan, a second execution adapter node is inserted before the target interface entities to obtain an intermediate execution plan. Based on the intermediate execution plan, a target execution plan in the form of a directed acyclic graph is generated.

[0156] In one implementation, the target plan generation module 606 is specifically used for: From the interface knowledge graph, extract the parameter passing rules corresponding to the target interface entities contained in the initial execution plan, and perform the following operations for any two target interface entities that have an interface relationship: Based on the parameter passing rules corresponding to the two target interface entities, identify whether there is a data transmission incompatibility between the two target interface entities; If so, determine the conversion steps and / or parameter passing method between the two target interface entities according to the preset large model conversion prompt words; A first execution adapter node is inserted between the two target interface entities. The first execution adapter node is used to implement the conversion steps and / or parameter passing methods to eliminate data transmission incompatibility between the two target interface entities.

[0157] In one implementation, the target plan generation module 606 is specifically used for: From the interface knowledge graph, extract the permissions and security rules corresponding to the target interface entities contained in the initial execution plan, and perform the following operations on the target interface entities whose permissions and security rules are not empty: Based on the pre-set large model planning prompts, determine the permission verification node, security measure execution node, and node execution order corresponding to the target interface entity; among them, the second execution adaptation node includes the permission verification node and the security measure execution node; Before the target interface entity, insert permission verification nodes and security measure execution nodes in the order of node execution to eliminate the lack of security mechanisms in the target interface entity.

[0158] In one implementation, the initial plan generation module 604 is specifically used for: Perform the following operations using the target large model: Parse the key requirement information corresponding to the business requirement description text; The key information of the requirements is matched with the tool description information corresponding to the interface entities contained in the interface knowledge graph to determine the target interface entity for matching the business requirement description text. Based on the interface relationships between interface entities contained in the interface knowledge graph, the interface relationships between target interface entities are inferred to obtain the initial execution plan.

[0159] In one implementation, a plan execution module is also included, for: Perform rigid validation of the target execution plan using a graph database and flexible validation using a large model. The target execution plan is executed after passing both rigid validation of the graph database and flexible validation of the large model.

[0160] In one implementation, the plan execution module is specifically used for: Rigid verification of the target execution plan using a graph database includes: verifying whether there are loops in the target execution plan using a graph database, and determining whether the rigid verification of the graph database is passed if there are no loops in the target execution plan. In the case of rigid verification through graph database, the plan complexity level corresponding to the target execution plan is determined, so as to determine whether to perform large-scale flexible verification of the target execution plan based on the plan complexity level; If the judgment result is yes, the target execution plan is subjected to large-scale model flexible verification, including: using the target large-scale model, according to the preset large-scale model verification prompt words, based on the business requirement description text and interface knowledge graph, to determine the score value corresponding to the target execution plan. If the score value is higher than the preset threshold, the target execution plan is determined to have passed the large-scale model flexible verification.

[0161] The system provided in this embodiment of the invention has the same implementation principle and technical effects as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0162] This invention provides an electronic device, specifically, the electronic device includes a processor and a memory; the memory stores a computer program, which, when run by the processor, executes the method described in any of the above embodiments.

[0163] Figure 7 The present invention provides a schematic diagram of the structure of an electronic device 100, which includes a processor 70, a memory 71, a bus 72 and a communication interface 73. The processor 70, the communication interface 73 and the memory 71 are connected through the bus 72. The processor 70 is used to execute executable modules, such as computer programs, stored in the memory 71.

[0164] The memory 71 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 73 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0165] Bus 72 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0166] The memory 71 is used to store programs. After receiving an execution instruction, the processor 70 executes the programs. The methods executed by the system defined by the flow process disclosed in any of the foregoing embodiments of the present invention can be applied to the processor 70 or implemented by the processor 70.

[0167] The processor 70 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 70 or by instructions in software form. The processor 70 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 71. Processor 70 reads the information in memory 71 and, in conjunction with its hardware, completes the steps of the above method.

[0168] The computer program product of the readable storage medium provided in the embodiments of the present invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the foregoing method embodiments. For specific implementation, please refer to the foregoing method embodiments, which will not be repeated here.

[0169] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0170] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A business process refactoring method based on the collaboration of large models and knowledge graphs, characterized in that, This is applied to a business process refactoring system, which has a built-in target large model and stores a pre-configured interface knowledge graph. The interface knowledge graph describes multiple interface entities and the interface relationships between these entities; including: Receive user-uploaded text describing business requirements; Using the target big model and based on the interface knowledge graph, the target interface entities for matching the business requirement description text are determined, and the interface relationships between the target interface entities are inferred to obtain an initial execution plan. Based on the target big model and the interface knowledge graph, the system identifies whether there are execution obstacles in the invocation process of the target interface entity contained in the initial execution plan. If so, an execution adapter node is inserted at a specified position in the initial execution plan to obtain the target execution plan. The execution obstacles include at least data transmission incompatibility and / or missing security mechanisms. The execution adapter node is used to eliminate the execution obstacles.

2. The business process reconstruction method based on the collaboration of large models and knowledge graphs according to claim 1, characterized in that, Using the target large model and based on the interface knowledge graph, identify whether there are execution obstacles in the invocation process of the target interface entity included in the initial execution plan. If so, insert an execution adapter node at a specified position in the initial execution plan to obtain the target execution plan, including: If, based on the interface knowledge graph, it is found that there is data transmission incompatibility among the target interface entities included in the initial execution plan, a first execution adapter node is inserted between the target interface entities; and / or, if, based on the interface knowledge graph, it is determined that there is a lack of security mechanism among the target interface entities included in the initial execution plan, a second execution adapter node is inserted before the target interface entities to obtain an intermediate execution plan; Based on the intermediate execution plan, a target execution plan in the form of a directed acyclic graph is generated.

3. The business process reconstruction method based on the collaboration of large models and knowledge graphs according to claim 2, characterized in that, If, based on the interface knowledge graph, data transfer incompatibility is identified among the target interface entities included in the initial execution plan, a first execution adapter node is inserted between the target interface entities, including: From the interface knowledge graph, extract the parameter passing rules corresponding to the target interface entities contained in the initial execution plan, and perform the following operations for any two target interface entities that have the interface relationship: Based on the parameter passing rules corresponding to the two target interface entities, identify whether there is a data transmission incompatibility between the two target interface entities; If so, then determine the conversion steps and / or parameter passing method between the two target interface entities according to the preset large model conversion prompt words; A first execution adapter node is inserted between the two target interface entities. The first execution adapter node is used to implement the conversion steps and / or the parameter passing method to eliminate data transmission incompatibility between the two target interface entities.

4. The business process reconstruction method based on the collaboration of large models and knowledge graphs according to claim 2, characterized in that, If, based on the interface knowledge graph, it is determined that the target interface entity included in the initial execution plan lacks a security mechanism, a second execution adapter node is inserted before the target interface entity, including: From the interface knowledge graph, extract the permissions and security rules corresponding to the target interface entities contained in the initial execution plan, and perform the following operations on the target interface entities whose permissions and security rules are not empty: According to the preset large model planning prompts, determine the permission verification node, security measure execution node, and node execution order corresponding to the target interface entity; wherein, the second execution adaptation node includes the permission verification node and the security measure execution node; Before the target interface entity, the permission verification node and the security measure execution node are inserted in the order of node execution to eliminate the lack of security mechanisms in the target interface entity.

5. The business process reconstruction method based on the collaboration of large models and knowledge graphs according to claim 1, characterized in that, Based on the target big model and the interface knowledge graph, the target interface entities for matching the business requirement description text are determined, and the interface relationships between the target interface entities are inferred to obtain an initial execution plan, including: The following operations are performed using the target large model: Parse the key requirement information corresponding to the business requirement description text; The key information of the requirement is matched with the tool description information corresponding to the interface entities contained in the interface knowledge graph to determine the target interface entity that matches the business requirement description text. Based on the interface relationships between the interface entities contained in the interface knowledge graph, the interface relationships between the target interface entities are inferred to obtain an initial execution plan.

6. The business process reconstruction method based on the collaboration of large models and knowledge graphs according to claim 1, characterized in that, The method further includes: The target execution plan is subjected to rigid verification using a graph database and flexible verification using a large model. The target execution plan is executed after passing the rigid verification of the graph database and the flexible verification of the large model.

7. The business process refactoring method based on large model and knowledge graph collaboration according to claim 6, characterized in that, The target execution plan undergoes rigid validation of the graph database and flexible validation of the large model, including: Performing a graph database rigid verification on the target execution plan includes: verifying whether the target execution plan has loops through the graph database, and determining that the graph database rigid verification passes if the target execution plan does not have loops; If the rigid verification of the graph database is passed, the plan complexity level corresponding to the target execution plan is determined, so as to determine whether to perform large model flexible verification on the target execution plan based on the plan complexity level; If the judgment result is yes, perform a large-scale model flexible verification on the target execution plan, including: using the target large model, according to the preset large-scale model verification prompt words, based on the business requirement description text and the interface knowledge graph, determine the score value corresponding to the target execution plan, and if the score value is higher than the preset threshold, determine that the target execution plan passes the large-scale model flexible verification.

8. A business process reengineering system based on the collaboration of large models and knowledge graphs, characterized in that, The business process refactoring system has a built-in target large model and stores a pre-configured interface knowledge graph. This interface knowledge graph describes multiple interface entities and the interface relationships between them; including: The text receiving module is used to receive text describing business requirements uploaded by users. The initial plan generation module is used to determine the target interface entities that match the business requirement description text and to infer the interface relationships between the target interface entities based on the target big model and the interface knowledge graph, so as to obtain the initial execution plan. The target plan generation module is used to identify, through the target big model and based on the interface knowledge graph, whether there are execution obstacles in the invocation process of the target interface entity included in the initial execution plan. If so, an execution adapter node is inserted at a specified position in the initial execution plan to obtain the target execution plan. The execution obstacles include at least data transmission incompatibility and / or missing security mechanisms. The execution adapter node is used to eliminate the execution obstacles.

9. An electronic device, characterized in that, The method includes a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when invoked and executed by a processor, cause the processor to perform the method according to any one of claims 1 to 7.

Images