Automatic function chain generation method and device based on graph database and medium

Abstract

The embodiment of the invention discloses an automatic function chain generation method and device based on a graph database and a medium, and relates to the technical field of graph databases, and the method comprises the steps: receiving natural language query information triggered by a user, carrying out intention analysis on the natural language query information through a preset language model, determining a structured query condition, and sending the structured query condition to the user; the structured query condition comprises a query intention category, a query entity parameter and logic step disassembly information; according to the structured query condition, mixed retrieval is carried out in a pre-constructed graph database, a candidate API calling path set is determined, the graph database comprises an API knowledge graph and node semantic vector information, and the candidate API calling path set comprises at least one candidate API calling path; and performing multi-dimensional scoring on candidate API call paths in the candidate API call path set, and dynamically generating an executable function chain to determine an API call chain code of the target programming language corresponding to the executable function chain.

Description

TECHNICAL FIELD

[0001] The present specification relates to the technical field of graph database, and particularly relates to a function chain automatic generation method based on a graph database, equipment and a medium. BACKGROUND

[0002] As the core carrier connecting business requirements and technical implementation, the generation efficiency and reliability of API call function chain directly affect the automation level of business system. With the increasing complexity of Web business system, complex business systems in e-commerce, finance and other fields usually contain a large number of API interfaces, and their call logic may involve multi-step dependence, dynamic parameter transmission and exception handling.

[0003] In the traditional API integration development process in complex business scenarios, the implicit dependence between parameters forms a dark net, and there is a parameter dependence blind area. When parameters are transmitted across APIs, there is a lack of explicit declaration, such as the user_id of the order query API needs to come from the output of the user filtering API; the parameter value domain is affected by the upstream and downstream business rules, such as the amount field of the payment API needs to meet the threshold check of the risk control system. Analyze in three aspects of common interface description documents Swagger, Postman collection, and code comments. Swagger document only describes the parameter format of a single API, missing cross-interface association, such as the address_id of the order creation API needs to call the address book API first, but the document has no guidance. Postman collection hardcodes parameter transmission paths and cannot dynamically adapt to interface changes, such as when user service upgrades replace user_id with user_code, all test cases fail. The manually maintained dependency description in code comments is easy to be outdated and incomplete, such as a new developer misusing an obsolete parameter causing price calculation errors. In addition, static arrangement cannot adapt to interface dynamic changes, and there is a problem of rigid call path. In addition, the threshold is high, and non-technical personnel need professional training to complete complex call chain design. Business analysts need to understand the JSON technical details of the API, map business requirements, which increases the use threshold difficulty. When quickly verifying new scenarios, operations personnel need to rely on the development team to write test scripts, which causes new scenario verification to be not timely.

[0004] Therefore, in the traditional API integration development process, there are problems of interface parameter dependence blind area and rigid call path, and dependence on professional technical knowledge, which causes the matching degree of function chain and business requirements and the development efficiency to be unable to meet the business requirements of complex business systems. SUMMARY

[0005] One or more embodiments of the present specification provide a graph database-based function chain automatic generation method, device and medium, to solve the following technical problems: in the traditional API integration development process, there are interface parameter dependency blind area and calling path rigidity problems, and professional technical knowledge is required, which leads to the matching degree of function chain and business demand and the development efficiency cannot meet the business demand of complex business systems.

[0006] One or more embodiments of the present specification adopt the following technical solutions:

[0007] One or more embodiments of the present specification provide a graph database-based function chain automatic generation method, which comprises: receiving a user-triggered natural language query information, performing intent analysis on the natural language query information through a preset language model to determine a structured query condition, wherein the structured query condition comprises a query intent category, a query entity parameter and logical step disassembly information; performing mixed retrieval in a pre-constructed graph database according to the structured query condition to determine a candidate API calling path set, wherein the graph database comprises an API knowledge graph and node semantic vector information, and the candidate API calling path set comprises at least one candidate API calling path; performing multi-dimensional scoring on the candidate API calling paths in the candidate API calling path set, dynamically generating an executable function chain to determine the API calling chain code of the target programming language corresponding to the executable function chain.

[0008] One or more embodiments of the present specification provide a graph database-based function chain automatic generation device, comprising:

[0009] at least one processor; and

[0010] a memory in communication connection with the at least one processor; wherein

[0011] The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the above method.

[0012] One or more embodiments of the present specification provide a non-volatile computer storage medium, which stores computer executable instructions, and the computer executable instructions are configured to execute the above method.

[0013] The at least one technical scheme adopted by the embodiments of the present specification can achieve the following beneficial effects: through the technical scheme of the embodiments of the present specification, the traditional method often causes parameter type mismatch or redundant calling due to the lack of global parameter dependence on the view, the API knowledge graph constructed by the graph database of the embodiments of the present specification explicitly records the parameter passing relationship between interfaces, and the parameter consistency is forcibly checked in the hybrid retrieval stage, which significantly improves the execution efficiency; the calling chain generated by the traditional hard coding or rule engine cannot adapt to interface changes and business logic evolution, the embodiments of the present specification support dynamically generating the optimal path through the hybrid retrieval (semantic matching, graph traversal) and multi-dimensional scoring mechanism, and the logical step decomposition information makes the calling chain flexibly adapt to the business rule changes; the traditional development process requires developers to be proficient in interface documents and dependency relationships, and the embodiments of the present specification directly map user requirements to structured query conditions through natural language analysis, so that business personnel can generate executable calling chains without coding, which effectively improves the development efficiency, and is especially suitable for fast iteration business scenarios such as financial compliance strategy adjustment and Internet of Things device linkage rule update; through the multi-dimensional scoring mechanism and parameter optimization strategy, the generated code has high reliability and high performance; through natural language understanding, dynamic graph retrieval and intelligent code generation, end-to-end automation from business requirements to technical implementation is realized, and the core problems of parameter blind area, path rigidity and high threshold in the traditional development process are solved. In complex business scenarios such as e-commerce, finance, medical treatment and Internet of Things, the precision, flexibility and efficiency can significantly improve the response speed of the business system and reduce the operation and maintenance cost. BRIEF DESCRIPTION OF DRAWINGS

[0014] In order to more clearly illustrate the technical solutions in the embodiments of the present specification or the prior art, the drawings needed to be used in the embodiments or prior art description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments described in the present specification, and other drawings can be obtained by those skilled in the art without creative labor. In the drawings:

[0015] Figure 1 A flowchart of a function chain automatic generation method based on a graph database provided by the embodiments of the present specification is shown in the figure;

[0016] Figure 2 An API knowledge graph construction flowchart provided by the embodiments of the present specification is shown in the figure;

[0017] Figure 3 An application scenario diagram of a function chain automatic generation method based on a graph database provided by the embodiments of the present specification is shown in the figure;

[0018] Figure 4 A flowchart of a natural language analysis and hybrid retrieval method provided by the embodiments of the present specification is shown in the figure;

[0019] Figure 5 A method flow diagram of dynamic function generation and closed-loop optimization provided for an embodiment of the present specification is shown in the following figure:

[0020] Figure 6 A structural diagram of a function chain automatic generation device based on a graph database provided for an embodiment of the present specification is shown in the following figure. DETAILED DESCRIPTION

[0021] In order to enable those skilled in the art to better understand the technical solutions in the present specification, the technical solutions in the present specification will be described clearly and completely in the following with reference to the drawings in the embodiments of the present specification. Obviously, the described embodiments are only part of the embodiments of the present specification, not all the embodiments. Based on the embodiments of the present specification, all other embodiments obtained by those skilled in the art without creative labor should be within the scope of protection of the present specification.

[0022] The embodiments of the present specification provide a function chain automatic generation method based on a graph database. It should be noted that the execution subject in the embodiments of the present specification can be a server or any device with data processing capability. Figure 1 A flow diagram of a function chain automatic generation method based on a graph database provided for an embodiment of the present specification is shown in the following figure: Figure 1 As shown in the figure, the method mainly includes the following steps:

[0023] In step S101, the natural language query information triggered by the user is received, and the natural language query information is analyzed by a preset language model to determine a structured query condition.

[0024] The structured query condition includes a query intent category, a query entity parameter, and logical step disassembly information.

[0025] In an embodiment of the present specification, natural language query information input by a user is acquired, where the natural language query information is query text input by the user, for example, "display unpaid orders of Zhang San", the business requirement of the user is displayed in the form of self-input query text, the language model after fine-tuning is used to analyze the intent of the natural language query information, and the query intent category, query entity parameter and logical step decomposition information are determined. It should be noted that in the technical architecture of the automatic generation of the API calling chain, the natural language analysis and the generation of the structured query condition are the core pivots connecting the user demand and the underlying technology implementation. The traditional scheme relies on artificial rules or keyword matching to analyze the user request, and it is difficult to deal with semantic ambiguity, nested entities and complex logical relationships in natural language. For example, in the financial risk control scene, the user may propose a complex request such as "verify the credit of user A and check the risk of its recent three months transaction", and the traditional method cannot disassemble the multi-intent of credit verification and risk analysis and parameter mapping such as user A mapping to user ID and recent three months mapping to time range, resulting in the generated calling chain missing necessary steps or parameter transmission errors. Through structured analysis, the user demand can be accurately disassembled into intent, entity and logical steps that can be understood by the machine, providing standardized input for subsequent hybrid retrieval and path generation, and avoiding semantic gap problems from the root. In addition, the logical step decomposition information in the structured query condition, such as "first authentication and then query", directly restricts the generation order of the API calling chain, ensuring the compliance of the business process, which is particularly important in medical data access, cross-border payment and other strong compliance scenarios.

[0026] The natural language query information is analyzed by a preset language model to determine a structured query condition, specifically including: collecting historical natural language query information of a user and corresponding labeled data, where the labeled data includes a query intent category, a nested entity type and a parameter mapping relationship; based on the historical natural language query information of the user and the corresponding labeled data, fine-tuning model attention layer parameters based on a pre-trained language model to determine a fine-tuned language model; according to the fine-tuned language model, the natural language query information is analyzed to output a structured analysis result, where the structured analysis result includes an intent category confidence, an entity value pair list and a logical step decomposition sequence; when the intent category confidence is greater than a preset confidence threshold, the structured query condition is determined based on the structured analysis result.

[0027] In an embodiment of the present specification, a high-quality labeled data set is first constructed. Historical user natural language query data such as customer service work orders and business requirement documents are collected, and the intent category is labeled, such as "order query" " risk control verification", and the nested entity is labeled, such as "user A ”Mapping to user_id, "near three months" to start_time and end_time, and logical steps such as "step 1: authentication, step 2: query" also need to be labeled. The labeling process needs to cover multiple field scenarios (e-commerce, finance, IoT, etc.) to ensure the model's generalization ability. Based on a pre-trained language model (such as DeepSeek), the model's attention layer is fine-tuned on the labeled data to enhance the model's ability to recognize domain-specific terms, composite entities, and logical connection words. For example, the model needs to learn to parse "and" as parallel logical steps and "then" as sequential dependencies.

[0028] According to the fine-tuned language model, the natural language query information parsing process is as follows: multi-label classification is performed on the user's natural language request to determine the main intent (such as "order export") and sub-intent (such as "filter by time range"). The BIO labeling system is used to identify composite entities (such as "last week" mapped to the time range entity, "unpaid" mapped to the order status entity). Complex requests are decomposed into sequential or parallel API call steps, such as "first call the user authentication interface, then call the order export interface". After the user inputs the natural language request and the fine-tuned model parses it, the intent category confidence, entity value pair list, and logical step decomposition sequence are output. The intent category confidence is used to measure the reliability of the current parsing result, for example, when the user inputs "help me check the order", the model may output the intent "order query" with a confidence of 0.92 (threshold set to 0.85). The entity value pair list needs to complete parameter type mapping, such as mapping "unpaid" to status = unpaid, and the logical step decomposition explicitly defines the API call sequence or parallel relationship. If the intent confidence is below the threshold, such as 0.7 due to ambiguous user input, a clarification interaction will be triggered, such as "please confirm that you need to query the order or logistics information", to avoid incorrect parsing being passed down to the downstream. When the intent category confidence is greater than the pre-set confidence threshold, the structured parsing result is determined, and the fine-tuned language model outputs the structured query condition, including intent classification results, entity recognition results, and logical step decomposition. The intent classification result refers to the operation type determined after intent disambiguation of the user's natural language request, such as "order query" " User authentication" and so on. The entity recognition result refers to the entity parameters and their types extracted from the user's request, such as user name, order status, time range, etc. The logical step decomposition refers to the decomposition of complex requests into sequential or parallel API call steps, such as "first call the authentication interface, then call the order query interface".

[0029] To support multi-field adaptation, a field adaptation layer needs to be introduced during model fine-tuning. For example, in the financial scenario, "risk level" " Transaction flow" and other entity types are added, and in the IoT scenario, "device ID"”" The model realizes entity recognition and logical disassembly across scenes by dynamically loading a field-related parameter mapping table. In addition, feedback data of the user on the generated API call chain, such as execution failure logs, is collected regularly, and the annotated data set and model parameters are optimized in reverse, forming a closed-loop iteration.

[0030] Through the above technical solutions, the traditional method relies on manual writing of regular expressions or rule templates, which is difficult to cover long-tail expressions in natural language, such as "orders that user Zhang San did not pay for last week". By fine-tuning the semantic understanding ability of the language model, the implicit parameters and complex logic in the unstructured request can be recognized, such as "no payment" mapping to status = unpaid, "exclude refunded orders first and then calculate the amount"; through model fine-tuning and field adaptation mechanism, only a small amount of incremental annotation is needed to support new scenarios, greatly reducing manual intervention. In large enterprise systems, the number of interfaces may reach thousands, and the maintenance cost of the traditional method grows exponentially, and through automated analysis, linear expansion is realized; through the structured query conditions (intention, entity, logical steps) output, technical personnel are provided with transparent intermediate results, when the generated call chain fails in sandbox verification, the entity mapping error can be found through reverse tracing, such as "user number" misinterpreted as user_id instead of client_id, so as to optimize the model or annotated data; through the logical step disassembly, the parallel / sequential relationship is explicitly defined, so that the generated call chain can be compatible with complex patterns such as asynchronous execution and event triggering, thereby meeting the needs of Internet of Things, distributed systems and other scenarios.

[0031] Step S102, according to the structured query condition, mixed retrieval is performed in the pre-constructed graph database to determine a candidate API call path set.

[0032] The graph database includes API knowledge graph and node semantic vector information, and the candidate API call path set includes at least one candidate API call path;

[0033] According to the structured query condition, the method further includes: parsing the pre-acquired API interface description file to extract interface information corresponding to the API interface, wherein the interface information includes an interface name, an endpoint path, a calling method, input parameter data, output parameter data, and a semantic description field of natural language description of the API interface; creating API nodes in the graph database according to the interface information corresponding to the API interface, collecting API calling logs in real time through a log collection tool, and counting cross-API parameter passing information, wherein the cross-API parameter passing information includes parameter passing frequency and calling success rate; generating a current dependency relationship weight between the API nodes based on the cross-API parameter passing information, to determine a current API knowledge graph through the current dependency relationship weight, wherein the API nodes in the current API knowledge graph are connected through directed edges, and the edge attribute of each edge includes a calling frequency weight and a success rate weight; vectorizing and encoding the interface name and the semantic description field of the API node to determine node semantic vector information corresponding to each API node, and building an association relationship between the node semantic vector information and the API node to store in the graph database.

[0034] The traditional method relies on static documents (such as Swagger) or manually maintained interface relationship tables. In high-iteration business scenarios such as e-commerce and finance, the generated calling chain is disconnected from the actual system because the interface changes and calling behavior evolution cannot be captured in real time. For example, when an order query interface is migrated from RESTful to GraphQL, the traditional static analysis will fail due to endpoint path changes; when a risk control interface adds an input parameter due to policy upgrade, the knowledge graph that is not updated will generate an invalid calling chain with missing parameters. Through the constructed API knowledge graph, the interface metadata, dynamic calling logs, and semantic vectors are fused to reflect the parameter passing, dependency relationship, and semantic association between interfaces in real time, solving the path generation deviation problem caused by information lag in traditional solutions.

[0035] In an embodiment of the present specification, Figure 2 An API knowledge graph construction process schematic diagram provided by an embodiment of the present specification is shown in Figure 2 Swagger / OpenAPI and other multi-source interface description files are parsed to extract the endpoint path, calling method (GET / POST, etc.), input parameter list (parameter name, data type, mandatory flag), output parameter list, and semantic field of natural language description of the API, such as “get user account balance” and “get user unpaid order list”.

[0036] Based on the extracted metadata, create API nodes in a graph database (e.g. Neo4j), with each node property containing the interface name, path, method, input / output parameter details, and semantic description fields. For example, the node properties for the user service interface get_user_info include the path / api / users / {id}, method GET, input parameter user_id (string), output parameter user_name (string), and semantic description "Query basic information based on user ID". Define relationships, including strong dependency relationships, i.e. REQUIRES relationships, representing mandatory dependencies for API calls, such as completing user authentication before calling the order query interface; parameter passing relationships, i.e. FEEDS relationships, representing cross-API parameter passing, such as the user information interface outputting user_id as an input parameter for the order query interface; and recommended dependency relationships, i.e. SUGGESTS relationships, representing recommended dependencies, such as suggesting additional logistics status query after order query.

[0037] Collect API call logs in real-time using log collection tools, such as Filebeat, recording interface names, input parameter values, output parameter values, and call results (success / failure). Use stream processing engines, such as Apache Flink, to perform windowed aggregation analysis on the logs, counting cross-interface parameter passing frequencies, such as the number of times the output parameter order_id of interface A is called as an input parameter by interface B. Based on the passing frequency and historical success rate, such as 90% success when interface B calls the order_id output by interface A, dynamically calculate the weight of the FEEDS relationship edge.

[0038] It should be noted that, in the dynamic calculation of the edge weight of the FEEDS relationship edge based on the transmission frequency and the historical success rate, the output parameter order_id of interface A is called as an input parameter by interface B. First, the number of times that the output parameter order_id of interface A is called as an input parameter by interface B within a preset time window is counted to determine the cross-interface parameter transmission times. At the same time, the total number of accumulated interface calls within the preset time window is counted. It should be noted that the total number of accumulated interface calls refers to the total number of call times of interface calls within the preset time window, that is, as long as an interface is called, the number of times is counted once. The cross-interface parameter transmission frequency of interface B calling interface A is determined by the ratio of the cross-interface parameter transmission times to the total number of accumulated interface calls. Secondly, the historical success rate of interface B calling the order_id output by interface A within the preset time window is counted. The initial edge weight of the FEEDS relationship edge is determined by the product of the cross-interface parameter transmission frequency and the historical success rate, that is, the initial edge weight of the FEEDS relationship edge between interface B and interface A. In the above embodiment, the preset time window can be set according to requirements. The size of the preset time window is related to the update period of the edge weight. The smaller the preset time window, the more frequent the update of the edge weight, that is, the edge weight is calculated once for the incremental data every preset time window to update the edge weight and realize incremental update.

[0039] The name and semantic description text of the API node are input into a pre-trained language model (such as Deepseek) to generate a high-dimensional semantic vector. For example, the semantic description "get unpaid orders" of the interface get_unpaid_orders is encoded into a 768-dimensional vector and stored in a vector database such as Milvus. The mapping relationship between the semantic vector and the API node in the graph database is established through the vector database to support fast semantic matching in subsequent hybrid retrieval. At the same time, the dynamic weight (call frequency, success rate) is stored in the edge attribute of the graph database to provide real-time basis for path sorting.

[0040] Through the above technical solution, the technical problem of relying on manual maintenance of the interface relationship table or periodic full update, which cannot respond to interface changes in real time, is solved. Through real-time analysis of logs by stream processing, the knowledge graph can be updated within a few minutes, ensuring that the call chain generation is strictly synchronized with the online system. Especially in high-concurrency scenarios such as "Double Eleven", the interface call mode may change instantaneously due to traffic scheduling. The dynamic weight mechanism can adjust the path priority in real time to avoid timeout failure of the call chain due to dependence on overloaded interfaces.

[0041] In one embodiment of the present specification, the consistency of the types of upstream and downstream interface parameters can also be detected, such as the type conflict between interface A output user_id (int) and interface B input user_id (string), and the illegal dependent edge is automatically excluded to ensure the physical executability of the graph. The traditional scheme ignores parameter type checking, and may generate a type conflict call chain, such as passing the user_id of string type to the integer parameter. By forcibly detecting the parameter type consistency in the graph construction stage, for example, when interface A outputs a timestamp type parameter and interface B needs a date type, the generation of A → B FEEDS edge is automatically blocked, fundamentally avoiding runtime type conversion errors.

[0042] According to the structured query condition, mixed retrieval is performed in the pre-constructed graph database to determine a candidate API call path set, specifically including: according to the query intent category and the query entity parameter, semantic retrieval is performed in the node semantic vector information of the graph database to determine a plurality of initial candidate API nodes; taking the initial candidate API node as a starting point, according to the logical step disassembly information and the query entity parameter, path expansion retrieval is performed in the API knowledge graph of the graph database to determine the candidate API call path set.

[0043] The traditional method relies on a single retrieval mode, such as keyword matching or static rule traversal, and in complex business scenarios such as e-commerce and finance, due to the inability to balance semantic understanding and topological dependence, there are path generation deviation or low efficiency problems. For example, the user request "query user A unpaid order and export Excel ” , if only relying on semantic retrieval, it may mismatch the "order list" interface, lacking the export function, and only relying on graph traversal may generate a long path, such as "authentication -> query -> log record -> export". Through the combination of semantic preliminary screening and path expansion of mixed retrieval, high-relevant API nodes such as get_unpaid_orders and export_excel can be accurately locked, and compliant call chains can be generated based on logical step constraints such as "query first and then export".

[0044] According to the query intention category and the query entity parameter, semantic retrieval is performed in node semantic vector information of the graph database to determine a plurality of initial candidate API nodes, specifically including: converting the query intention category into a query intention semantic vector, performing semantic similarity matching in the node semantic vector information based on the query intention semantic vector, and determining an intention matching API node set meeting a preset requirement; performing node filtering in the intention matching API node set according to the query entity in the query entity parameter, to determine the plurality of initial candidate API nodes, wherein a matching degree of interface input parameter data of each initial candidate API node and the query entity exceeds a preset matching degree threshold.

[0045] In an embodiment of the present specification, the intention category and entity parameter in the structured query condition of the user are converted into a semantic vector. First, the intention category such as “order export” is encoded into an intention vector by a pre-trained model, and cosine similarity calculation is performed with the semantic vector of the API node in the graph database. According to the size order of the cosine similarity, Top5 related nodes such as get_orders and export_orders are sequentially screened out. The screening quantity here can be actually set according to the demand. Specifically, the intention category of “order export” is converted into a high-dimensional semantic vector, and the vector is generated by the model embedding layer, which emphasizes the weight of the intention keyword (such as “export”). In the Milvus vector database, the intention vector is calculated with the pre-stored API node semantic vector to obtain the top 5 nodes with the highest similarity as the intention matching set. For example, the user intention “order export” will preferentially match the export_orders and get_orders interfaces, and get_users is excluded due to low semantic correlation. Subsequently, the query entity parameter (such as status = unpaid) is used to perform secondary filtering on the intention matching set corresponding to the screened candidate nodes. It is detected whether the input parameter list of each API node contains the entity parameter name and is consistent in type. If there is a same name parameter (such as status) in the interface input parameter and the data types match (such as both are string), it is retained as an initial candidate node. For example, the interface get_orders supports the input parameter status (string), which meets the filtering condition; while the interface get_order_details only supports order_id (int), and is excluded due to mismatched parameter names. This stage ensures that the candidate nodes meet both semantic correlation and parameter executability.

[0046] In addition to the above manner, according to the query intention category and the query entity parameter, semantic retrieval is performed in the node semantic vector information of the graph database to determine the plurality of initial candidate API nodes, and the following manner can also be implemented: the structured query condition is composed of three parts of intention classification results, entity recognition results and logical step decomposition, and respectively acts on different stages of mixed retrieval. The intention classification result determines the operation type (such as "order query " User authentication") requested by the user, which is used to limit the retrieval range. The entity recognition result is used to extract the parameter entity in the user request (such as user_name=Zhang San, order_status=unpaid), which is used for parameter matching verification. The logical step decomposition decomposes the complex request into sequential or parallel API calling steps (such as "authentication first and then query"), which is used for path generation priority control.

[0047] First, the intention-driven semantic filtering is performed based on the intention classification result, if the user intention is "order export", the semantic retrieval stage only matches the API nodes related to "order" (such as get_orders, export_orders), and excludes irrelevant interfaces (such as get_weather). In the Milvus vector database, the semantic vector of the user request is calculated with all API semantic vectors; according to the intention classification result, the API nodes (such as interfaces containing " order ” ) strongly related to the target intention are set with a similarity weighting coefficient (such as 1.2 times), and the sorting priority is improved. Secondly, the semantic matching is enhanced based on the entity parameter. The user request contains "unpaid order", and the semantic retrieval preferentially matches the interfaces containing status=unpaid in the API description (such as get_unpaid_orders). When generating the semantic vector of the user request, the local attention is enhanced for the entity parameter (such as status=unpaid), so that the model pays more attention to the key entity; in the semantic similarity calculation, the API nodes containing the matching entity keywords (such as the semantic description containing "unpaid ” ") are improved in matching weight. The intention classification result and the entity recognition result in the user natural language request are encoded into semantic vectors in the above manner, and the initial API node set is obtained from the vector database through vector similarity matching.

[0048] According to the logical step disassembled information and the query entity parameter, path expansion retrieval is performed in the API knowledge graph of the graph database, taking the initial candidate API node as a starting point, to determine the candidate API calling path set, specifically including: determining the logical step disassembled information, when the logical step disassembled information is a sequential calling step, determining that the path expansion constraint condition is a forced path order; when the logical step disassembled information is a parallel calling step, determining that the path expansion constraint condition is to allow independent expansion of a sub-path; performing bidirectional breadth search in the graph database according to the path expansion constraint condition and a preset traversal depth threshold, taking the initial candidate API node as a starting point, to determine an initial expansion path set; performing node parameter consistency checking on each initial expansion path in the initial expansion path set according to the entity parameter in the query entity parameter, and filtering a parameter type conflict path, to determine the candidate API calling path set.

[0049] In an embodiment of the present specification, the initial candidate node is taken as a starting point, and the path expansion direction is constrained according to the logical step disassembled information. If the disassembled information is a sequential step (such as "authentication -> query -> export", the path is expanded along the REQUIRES relationship edge downstream, and it is forced to require that the preceding API must be present in the path. For example, when traversing upstream from export_orders, it is found that it depends on get_orders, and get_orders further depends on the auth interface, forming an auth → get_orders → export_orders path. If the disassembled information is a parallel step (such as "query user information and order list"), independent expansion of a sub-path without parameter dependence (such as parallel execution of get_users and get_orders) is allowed.

[0050] Bidirectional breadth-first search (BFS) is adopted in the traversal process, and the initial node is expanded upstream and downstream respectively, and the maximum depth limit can be set to 3 layers. For example, when searching 1 layer upstream from get_orders, auth is found, and when searching 2 layers downstream, export_orders and log_operation are found, generating two candidate paths. This depth limit can avoid the problem of combinatorial explosion caused by a large number of interfaces. At the same time, high-weight relationship edges (such as FEEDS edges with a historical success rate of 95%) are preferentially selected for expansion to ensure path reliability.

[0051] The parameter passing integrity of the expanded path set is checked. The input parameters of each API node in the path are detected layer by layer to determine whether they can be covered by the output parameters of the upstream nodes, and the data types are strictly consistent. For example, the path auth → get_orders →In the export_orders, the auth outputs a token (string) for the Authorization header of get_orders; the get_orders outputs an order_list (array) for the data parameter of export_orders. If the parameter types conflict at a certain layer, such as the upstream outputting a user_id (int) and the downstream needing a user_id (string), the path is discarded. This step avoids runtime type errors from the source and ensures the executability of the generated path.

[0052] By the above technical solution, in view of the problems that semantic retrieval in the traditional method is susceptible to description ambiguity, and pure graph traversal cannot understand user intent, the hybrid retrieval is used to lock high-relevance nodes through semantic preliminary screening, and a compliant path is generated based on a knowledge graph, taking into account semantic relevance and dependence legality. In addition, a conventional path generation tool (such as a rule engine) needs to hardcode a logical sequence for each business scenario. The embodiment of the specification supports flexible business logic adaptation by dynamically constraining path expansion directions through logical step decomposition in a structured query condition. The hybrid retrieval of the embodiment of the specification reduces the search range from the full graph to the Top5 nodes through semantic preliminary screening, and combines depth limitation and parameter checking to reduce the number of paths from exponential to linear. For example, in an e-commerce promotion scenario, the hybrid retrieval can generate a high-optimal path in a short time, avoiding response timeout caused by traversing the full graph.

[0053] In step S103, the candidate API call paths in the candidate API call path set are scored in multiple dimensions, and an executable function chain is dynamically generated to determine the API call chain code of the target programming language corresponding to the executable function chain.

[0054] The candidate API call paths in the candidate API call path set are scored in multiple dimensions, and an executable function chain is dynamically generated to determine the API call chain code of the target programming language corresponding to the executable function chain, specifically including: scoring the candidate API call paths in multiple dimensions to determine the path evaluation indicators of each candidate API call path, wherein the scoring dimensions of the multiple dimensions include semantic matching degree, path length, historical call success rate, and historical call frequency weight; according to the path evaluation indicators, path screening is performed to generate an API call directed acyclic graph optimized by parameter inheritance, and an executable function chain is generated, wherein the API call directed acyclic graph includes parallel execution branches and sequential execution constraints; the executable function chain is converted into the API call chain code corresponding to the target programming language through a target programming language template.

[0055] The API call directed acyclic graph is identified to have multiple specified API node pairs repeatedly requesting for the same parameter, according to an upstream-downstream relationship between the multiple specified API nodes, a parameter acquisition request of an upstreammost API node in the multiple specified API nodes is retained, and redundant parameter acquisition requests of downstream API nodes other than the upstreammost API node are eliminated, and in the API call directed acyclic graph, an API sub-path without a parameter dependency relationship is identified to generate a parallel call code segment corresponding to the API sub-path.

[0056] The traditional method relies on manual rules or simple priority sorting, and in a complex business scenario, such as financial transactions and Internet of Things device linkage, it is difficult to dynamically weigh the semantic fit degree, execution efficiency and historical reliability of the path, and it is easy to generate redundant or high-risk call chains. For example, in an e-commerce promotion scenario, a user requests to "preferentially use a discount after a full reduction", and the traditional scheme may generate a long path and repeatedly call a user authentication interface, while ignoring parameter inheritance optimization, resulting in repeated interface calls and resource waste; in a medical data query scenario, if the candidate path does not perform mandatory parameter type checking, such as a patient ID being a hash value rather than plaintext, data leakage may occur. Through multi-dimensional scoring and parameter inheritance optimization, a path with high semantic matching, low redundancy and historical reliability is dynamically screened, and executable code that takes into account efficiency and security is generated, solving the blind spot of the traditional scheme in path selection and code generation.

[0057] In an embodiment of the present specification, each candidate API call path is scored in multiple dimensions according to semantic matching degree, path length, historical call success rate and historical call frequency weight, to determine a path evaluation index of each candidate API call path. The semantic matching degree is used to measure the semantic consistency of the candidate path and the user request.

[0058] First, the user's natural language request is encoded into a high-dimensional semantic vector using a pre-trained language model. Simultaneously, the semantic description of each API node in the path (e.g., "get user's unpaid orders") is also encoded into a vector using the same model. The cosine similarity between the user request vector and the vectors of all API nodes in the path is calculated, and the weighted average is taken as the overall semantic matching degree of the path. For example, if the path contains three API nodes with similarities of 0.85, 0.92, and 0.78 with the user request, the overall semantic matching degree is the average of the three, 0.85. For paths containing multiple steps, key nodes (such as the path's start or end point) can be assigned higher weights to strengthen the semantic contribution of core interfaces. The path length is based on the number of steps in the call chain; fewer steps result in a higher score. In the specific implementation, the path length is normalized to a score value of 0 to 1: a maximum allowed step size (e.g., 10 steps) is set; if the actual step size is N, the score is (10-N) / 10. For example, a 5-step path scores 0.5, and a 3-step path scores 0.7. Meanwhile, for critical business scenarios (such as financial transactions), the maximum step size threshold can be dynamically adjusted. If the path step size exceeds the threshold, it will be directly eliminated to avoid generating overly complex call chains. Historical call success rate data for each API node within the path is obtained from the graph database. Success rate calculation is based on call logs over a past period (e.g., the last 30 days), calculating the ratio of successful calls to total calls. The overall success rate of the path is the weighted average of the node success rates, with weights dynamically allocated based on interface importance. For example, the core authentication interface has a weight of 0.4, while non-critical interfaces have a weight of 0.1. For instance, if the path contains interface A (95% success rate), interface B (90%), and interface C (85%), with weights of 0.4, 0.3, and 0.3 respectively, then the path success rate is 0.4 × 0.95 + ...

[0059] 0.3 × 0.9 + 0.3 × 0.85 = 0.905 (90.5%). Call frequency weight reflects the stability and business importance of the interface. Historical call frequencies for each interface are extracted from the graph database, and the call counts are statistically analyzed by time window (e.g., the last 7 days) and normalized (the highest frequency interface is set to 1, and the rest are calculated proportionally). Path frequency weight is the average of the node frequency weights; the higher the proportion of high-frequency interfaces, the greater the weight. For example, if a path contains high-frequency interface A (frequency weight 1.0) and mid-frequency interface B (0.6), then the path frequency weight is (1.0 + 0.6) / 2 = 0.8.

[0060] The scores of the four dimensions are integrated into a total score according to preset weights, where the weights can be set according to specific business scenarios. For example, the semantic matching degree weight is set to 50%, the path length is set to 20%, the success rate is set to 20%, and the frequency weight is set to 10%. The total score calculation formula is total score = semantic matching degree x 0.5 + path length score x 0.2 + success rate x 0.2 + frequency weight x 0.1. During screening, paths with a total score higher than a threshold value (such as 0.7) are retained and ranked in descending order of the score. If multiple paths have similar total scores (such as a difference of less than 5%), the path with a higher historical success rate is selected first. Finally, the top N candidate paths are generated to enter the subsequent optimization stage to determine the optimal candidate path with the highest total score.

[0061] Parameter redundancy elimination is performed on the selected path. The acquisition requests of multiple nodes in the path for the same parameter (such as user_id) are identified, and only the parameter call of the most upstream node is retained, such as get_user_info to acquire user_id. The downstream nodes such as get_orders and export_excel directly inherit the parameter value, and the redundant explicit calls are deleted. The node set without parameter dependency, such as get_product_info and get_user_info without common parameters, is split into parallel execution branches, which are mapped as asynchronous calls in the code, such as Python's asyncio.gather or Java's CompletableFuture. The optimized path is converted into a directed acyclic graph (DAG) to clearly define the sequence constraints and parallel branches.

[0062] According to the predefined code templates of the target programming language (such as Python and Java), the DAG is mapped into executable code. Each API node is converted into an HTTP method call in the target language, such as Python's requests.get, and the necessary parameters are injected, such as the header authentication token Authorization:Bearer

[0063] {token}; parameter passing code is automatically generated according to the DAG dependency, such as passing the output user_id of get_user_info to the input of get_orders; exponential backoff retries (such as a maximum of 3 retries with intervals of 2 seconds, 4 seconds, and 8 seconds) are added for key interfaces (such as payment services); backup interfaces with similar semantics (such as get_user_info_v2 as a backup for get_user_info) are configured, and the main interface is automatically switched when it fails; CPU / memory occupation is monitored during sandbox execution, and if it exceeds the limit, the fuse is triggered and the executed operations are rolled back.

[0064] By the technical solution, the traditional rule engine relies on fixed weights, such as forced path length priority, and is difficult to adapt to business changes. Through the multi-dimensional dynamic scoring in the embodiment of the specification, the weight of the high compliance path can be automatically increased in the financial risk control scene, such as forcedly including the anti-money laundering verification interface, and the low delay path is preferentially selected in the Internet of Things scene. When the historical success rate of an interface decreases due to version upgrade, the system dynamically reduces the weight of the interface, thereby avoiding generating a high-risk call chain. The conventional method usually serially executes all interface calls, resulting in resource waste. The embodiment of the specification eliminates redundant calls through parameter inheritance, and compresses the execution time of independent interfaces to the maximum value (max (T1, T2)) through parallelization. The traditional hard coding scheme needs to be repeatedly developed for different languages, while the embodiment of the specification realizes cross-language support through a template engine.

[0065] In an embodiment of the specification, the actual success rate, time consumption and other data collected in sandbox execution are used to update the weight of the knowledge graph in reverse, forming a continuous optimization closed loop. For example, when the success rate of a path temporarily decreases due to network jitter, the weight of the path is automatically degraded and a backup path is selected. When the network recovers, the weight gradually recovers as the success rate increases. This dynamic adjustment mechanism significantly improves the robustness of the system in a high volatility scenario, such as an e-commerce system during a promotion period.

[0066] Through the technical solution of the embodiment of the specification, the conventional method often causes parameter type mismatch or redundant calls due to the lack of a global parameter dependency view. The embodiment of the specification explicitly records the parameter passing relationship between interfaces through the API knowledge graph constructed by the graph database, and forcibly checks the parameter consistency in the hybrid retrieval stage, thereby significantly improving the execution efficiency. The call chain generated by the traditional hard coding or rule engine cannot adapt to interface changes and business logic evolution. The embodiment of the specification supports dynamically generating an optimal path through hybrid retrieval (semantic matching, graph traversal) and multi-dimensional scoring mechanism. The logical step decomposition information enables the call chain to flexibly adapt to changes in business rules. The traditional development process requires developers to be proficient in interface documentation and dependency relationships. The embodiment of the specification directly maps user requirements to structured query conditions through natural language parsing, enabling business personnel to generate executable call chains without coding, thereby effectively improving development efficiency, especially in fast iteration business scenarios such as financial compliance policy adjustment and Internet of Things device linkage rule update. Through the multi-dimensional scoring mechanism and parameter optimization strategy, the generated code has high reliability and high performance. Through natural language understanding, dynamic graph retrieval and intelligent code generation, end-to-end automation from business requirements to technical implementation is realized, solving the core problems of parameter blind area, path rigidity and high threshold in the traditional development process. In complex business scenarios such as e-commerce, finance, medical care and Internet of Things, precision, flexibility and efficiency can significantly improve the response speed of business systems and reduce operation and maintenance costs.

[0067] Figure 3 This is a schematic diagram illustrating an application scenario of an automatic function chain generation method based on a graph database, as provided in the embodiments of this specification. Figure 3 As shown, the knowledge graph construction module extracts interface metadata (endpoint paths, input / output parameters, semantic descriptions) by parsing API documentation (such as Swagger / OpenAPI), and dynamically generates dependencies (such as FEEDS, REQUIRES) between API nodes by combining real-time API call log statistics on parameter transmission frequency and success rate. A graph database (such as Neo4j) stores the API knowledge graph, and the weights of directed edges between nodes are updated in real-time by a stream processing engine (such as Flink), ensuring that interface changes (such as parameter type adjustments or the addition of authentication) are immediately reflected in path generation. After user natural language requests are parsed into structured query conditions by a large language model, vector semantic retrieval (Milvus vector database matching) and graph structure traversal (BFS / DFS extension) are triggered to form a candidate path set. This design solves the parameter dependency blind spots and path rigidity problems in traditional solutions. For example, in e-commerce scenarios, the dynamic graph can capture parameter changes of the inventory interface in real time, avoiding the generation of invalid call chains.

[0068] Figure 4 This is a flowchart illustrating a natural language parsing and hybrid retrieval method provided in an embodiment of this specification, as shown below. Figure 4 As shown, the intent understanding engine, through a fine-tuned DeepSeek NLP model, decomposes user input (such as "export high-risk transactions from last week") into intent classification (risk control data export), entity extraction (time range = last week, risk level = high), and logical step decomposition (authentication → query → export). Structured query conditions drive the hybrid retrieval engine to execute in a dual-path manner. User requests are encoded as semantic vectors, which are matched against Top-K relevant API nodes in Milvus (such as get_high_risk_transactions). Starting from the initial node, BFS / DFS expansion is executed according to logical step constraints (forced sequential / parallel), combined with parameter type validation to filter illegal paths. Finally, Top-N candidate paths are generated through path scoring (semantic similarity, path length, historical success rate). This solution overcomes the limitations of traditional keyword matching. For example, in a medical scenario, "statistics of incomplete test items" can be accurately associated with the get_pending_lab_reports interface, rather than the literally similar get_completed_reports, significantly improving semantic matching accuracy.

[0069] Figure 5 This is a schematic flowchart illustrating a method for dynamic function generation and closed-loop optimization provided in an embodiment of this specification, as shown below. Figure 5As shown, the path optimization algorithm performs multi-dimensional evaluation on the candidate paths, dynamically prunes based on historical success rate and path length, eliminates inefficient paths; identifies sub-paths without parameter dependence (such as querying user information and product inventory at the same time), generates asynchronous calling code; and eliminates parameter type conflicts or redundant requests (such as repeatedly obtaining user_id). The optimized path is converted into a directed acyclic graph (DAG), rendered into target language code (such as requests library calling in Python) through a template engine, and injected with exception handling logic (retry, circuit breaker, backup interface switching). The execution engine collects result data (delay, success rate, resource consumption) in real time, feeds back to the reinforcement learning agent, and dynamically updates the edge weights and node attributes of the knowledge graph. For example, when the success rate of an interface is improved due to version upgrade, the system automatically increases its weight, affecting subsequent path selection. In the financial scenario, the closed-loop optimization mechanism can make the call priority of the risk control verification interface adaptively adjust with the changes in regulatory policies, ensuring compliance.

[0070] The embodiments of the present specification also provide a function chain automatic generation device based on a graph database, as shown in the accompanying drawings. Figure 6 As shown, the device comprises at least one processor; and a memory connected in communication with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the above method.

[0071] The embodiments of the present specification also provide a non-volatile computer storage medium, which stores computer executable instructions, and the computer executable instructions are configured to execute the above method.

[0072] Each of the embodiments in the present specification is described in a progressive manner, and the same and similar parts of each embodiment can be referred to each other. Each embodiment focuses on the difference from other embodiments. In particular, for the device, equipment, and non-volatile computer storage medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the part of the method embodiment.

[0073] The above only describes one or more embodiments of the present specification and does not limit the present specification. One or more embodiments of the present specification can have various modifications and changes for those skilled in the art. Any modification, equivalent replacement, improvement, etc. within the spirit and principles of one or more embodiments of the present specification shall be included in the scope of the claims of the present specification.

Claims

1. A function chain automatic generation method based on a graph database, characterized in that, The method comprises: receiving a user-triggered natural language query information, performing intent analysis on the natural language query information through a preset language model, and determining a structured query condition, wherein the structured query condition comprises a query intent category, a query entity parameter, and logical step disassembly information; performing mixed retrieval in a pre-constructed graph database according to the structured query condition to determine a candidate API call path set, wherein the graph database comprises an API knowledge graph and node semantic vector information, and the candidate API call path set comprises at least one candidate API call path; performing multi-dimensional scoring on the candidate API call paths in the candidate API call path set, dynamically generating an executable function chain, and determining an API call chain code of a target programming language corresponding to the executable function chain. 2.The function chain automatic generation method based on a graph database according to claim 1, characterized in that, The method comprises: collecting user historical natural language query information and corresponding labeled data, wherein the labeled data comprises a query intent category, a nested entity type, and a parameter mapping relationship; fine-tuning model attention layer parameters based on a pre-trained language model using the user historical natural language query information and corresponding labeled data to determine a fine-tuned language model; analyzing the natural language query information according to the fine-tuned language model to output a structured analysis result, wherein the structured analysis result comprises an intent category confidence, an entity value pair list, and a logical step disassembly sequence; when the intent category confidence is greater than a preset confidence threshold, determining the structured query condition based on the structured analysis result. 3.The function chain automatic generation method based on a graph database according to claim 1, characterized in that, Before performing mixed retrieval in a pre-constructed graph database according to the structured query condition to determine a candidate API call path set, the method further comprises: parsing a pre-acquired API interface description file to extract interface information corresponding to the API interface, wherein the interface information comprises an interface name, an endpoint path, a calling method, input data, output data, and a semantic description field of a natural language description of the API interface; creating an API node in the graph database according to the interface information corresponding to the API interface, collecting API call logs in real time through a log collection tool, and counting cross-API parameter transfer information, wherein the cross-API parameter transfer information comprises parameter transfer frequency and call success rate; based on the cross-API parameter transfer information, generating a current dependency relationship weight between the API nodes to determine a current API knowledge graph through the current dependency relationship weight, wherein the API nodes in the current API knowledge graph are connected through directed edges, and the edge attributes of each edge contain call frequency weight and success rate weight; vectorizing the interface name and the semantic description field of the API node to determine node semantic vector information corresponding to each API node, constructing an association relationship between the node semantic vector information and the API node, and storing the association relationship in the graph database.

4. The function chain automatic generation method based on a graph database according to claim 1, characterized in that, According to the structured query condition, mixed retrieval is performed in a pre-constructed graph database to determine a candidate API call path set, specifically including: According to the query intent category and the query entity parameter, semantic retrieval is performed in node semantic vector information of the graph database to determine a plurality of initial candidate API nodes. According to the initial candidate API node as a starting point, according to the logical step disassembly information and the query entity parameter, path expansion retrieval is performed in the API knowledge graph of the graph database to determine the candidate API call path set.

5. The function chain automatic generation method based on a graph database according to claim 4, characterized in that, According to the query intent category and the query entity parameter, semantic retrieval is performed in node semantic vector information of the graph database to determine a plurality of initial candidate API nodes, specifically including: The query intent category is converted into a query intent semantic vector, and based on the query intent semantic vector, semantic similarity matching is performed in the node semantic vector information to determine an intent matching API node set that meets a preset requirement; According to the query entity in the query entity parameter, node filtering is performed in the intent matching API node set to determine the plurality of initial candidate API nodes, wherein the matching degree of the interface input parameter data of each initial candidate API node and the query entity exceeds a preset matching degree threshold.

6. The function chain automatic generation method based on a graph database according to claim 4, characterized in that, According to the initial candidate API node as a starting point, according to the logical step disassembly information and the query entity parameter, path expansion retrieval is performed in the API knowledge graph of the graph database to determine the candidate API call path set, specifically including: Determine the logical step disassembly information, when the logical step disassembly information is a sequential calling step, determine the path expansion constraint condition as a forced path order; When the logical step disassembly information is a parallel calling step, determine the path expansion constraint condition as allowing independent expansion of sub-paths; According to the initial candidate API node as a starting point, according to the path expansion constraint condition and a preset traversal depth threshold, bidirectional breadth search is performed in the graph database to determine an initial expansion path set; According to the entity parameter in the query entity parameter, node parameter consistency checking is performed on each initial expansion path in the initial expansion path set, and parameter type conflict paths are filtered to determine the candidate API call path set.

7. The function chain automatic generation method based on a graph database according to claim 1, characterized in that, Multi-dimensional scoring is performed on the candidate API call paths in the candidate API call path set to dynamically generate an executable function chain to determine an API call chain code of a target programming language corresponding to the executable function chain, specifically including: Multi-dimensional scoring is performed on the candidate API call paths to determine a path evaluation index of each candidate API call path, wherein the scoring dimensions of the multi-dimensional scoring include semantic matching degree, path length, historical calling success rate, and historical calling frequency weight; According to the path evaluation index, path screening is performed to generate an API call directed acyclic graph optimized in parameter inheritance to generate an executable function chain, wherein the API call directed acyclic graph includes parallel execution branches and sequential execution constraints; The executable function chain is converted into a corresponding API call chain code of a target programming language through a target programming language template.

8. The function chain automatic generation method based on a graph database according to claim 7, characterized in that, The API call directed-acyclic graph is generated by parameter inheritance optimization, specifically including: Identifying repeated parameter acquisition requests of a plurality of specified API nodes in the API call directed-acyclic graph; According to an upstream-downstream relationship among the plurality of specified API nodes, retaining a parameter acquisition request of an upstreammost API node among the plurality of specified API nodes, and eliminating redundant parameter acquisition requests of downstream API nodes other than the upstreammost API node; In the API call directed-acyclic graph, identifying an API sub-path with no parameter dependency relationship to generate a corresponding parallel call code segment of the API sub-path.

9. A function chain automatic generation device based on a graph database, characterized by, The device comprises: at least one processor; and a memory connected in communication with the at least one processor; wherein The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

10. A non-transitory computer storage medium storing computer-executable instructions that, when executed, cause a computer to perform: The computer executable instructions are configured to perform the method of any one of claims 1-8.

Images