An intelligent supervision and audit reasoning code generation method and system based on a knowledge graph and a templated mapping, an electronic device and a computer readable storage medium

Abstract

The application belongs to the cross field of artificial intelligence and software engineering, and discloses an intelligent supervision and audit reasoning code generation method and system based on a knowledge graph and a templated mapping. The method first constructs a supervision and audit field knowledge graph containing regulations, rules, cases, entities and risk nodes and their associated relationships. Secondly, through a pre-defined node mapping rule set, various nodes in the graph are parsed into standardized logical element tuples, and a point execution function is generated according to the node type and the corresponding pre-set Python code template. At the same time, control code describing the reasoning logic between nodes is generated based on the pre-defined relationship mapping rules. Finally, using a reasoning chain automatic assembly algorithm based on graph traversal, starting from the target entity node, the related node functions and control code are dynamically aggregated into an executable complete audit reasoning program according to the dependency relationship between nodes. The application significantly improves the intelligent level and response speed of supervision and audit work.

Description

Technical Field

[0001] This invention belongs to the interdisciplinary field of artificial intelligence and software engineering, and specifically relates to a method and system for generating intelligent monitoring and auditing reasoning code based on knowledge graphs and templated mapping, an electronic device, and a computer-readable storage medium, which are used to realize the automated conversion from domain knowledge to executable auditing reasoning programs. Background Technology

[0002] With increasingly stringent regulatory requirements across industries, oversight and auditing play a crucial role in risk control and compliance review. Traditional oversight and auditing primarily rely on manual review of regulations, rules, and historical cases, combined with expert experience for reasoning and judgment. However, with the increasing complexity of regulatory systems and the explosive growth of business data, traditional manual methods face problems such as inefficiency, inconsistent standards, and difficulties in knowledge transfer.

[0003] To enhance the intelligence level of oversight and auditing, knowledge graph technology has been introduced into this field in recent years for the structured storage of regulations, rules, cases, entities, and their relationships. However, most existing knowledge graph-based oversight and auditing applications remain at the level of knowledge retrieval and visualization. Users still need to manually interpret the relationships in the graph and make judgments based on their own experience, failing to achieve direct driving from knowledge to decision-making logic. In other words, knowledge graphs are only used as static knowledge bases, lacking the ability to dynamically transform the nodes and relationships in the graph into executable reasoning code.

[0004] On the other hand, developing audit reasoning programs using traditional manual coding methods is not only time-consuming and costly to maintain, but also results in significant differences in coding styles and logical structures among different auditors, making it difficult to guarantee code consistency and reliability. Furthermore, manual coding struggles to respond promptly to continuous updates to business rules and dynamic adjustments to regulatory requirements, leading to insufficient adaptability and flexibility in the audit system.

[0005] Therefore, how to automatically generate dynamic, reliable, and maintainable audit reasoning code from static monitoring and audit knowledge graphs has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0006] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method and system for generating intelligent monitoring and audit reasoning code based on knowledge graphs and templated mapping, as well as an electronic device and a computer-readable storage medium, to solve the problem of automatically generating dynamic, reliable, and maintainable audit reasoning code from static monitoring and audit knowledge graphs.

[0007] This invention provides a method for generating intelligent monitoring and auditing reasoning code based on knowledge graphs and templated mapping. The method includes the following steps:

[0008] Step 1: Construct a knowledge graph for the field of supervision and auditing. The knowledge graph includes legal nodes, rule nodes, case nodes, entity nodes, and risk nodes, as well as the relationships between the nodes.

[0009] Step 2: Based on a predefined set of node mapping rules, parse the various types of nodes in the knowledge graph into standardized logical element tuples, and call the corresponding pre-set Python code template according to the node type to generate node execution functions;

[0010] Step 3: Based on predefined relation mapping rules, generate control code to describe the reasoning logic between nodes. The control code includes entity-level control modules corresponding to entity nodes and global-level control modules that coordinate multiple entity-level control modules.

[0011] Step 4: Using a graph traversal-based automatic assembly algorithm for reasoning chains, starting from the target entity node, the node execution functions and control code are dynamically aggregated according to the dependencies between nodes in the knowledge graph to generate an executable and complete audit reasoning program.

[0012] The intelligent monitoring and audit reasoning code generation method based on knowledge graph and templated mapping described above includes at least the following five types of special relationships in the knowledge graph: entity-rule relationship, rule-risk relationship, entity-risk relationship, regulation-rule relationship, and case-rule relationship.

[0013] As described above, in the intelligent monitoring and auditing reasoning code generation method based on knowledge graphs and templated mapping, step 1 specifically includes:

[0014] Step 1.1: Define the metamodel of the knowledge graph according to the predefined metamodel construction rules;

[0015] Step 1.2: Using the meta-model as the extraction template, natural language processing (NLP) technology is used to identify and extract specific nodes and relationships from various data sources;

[0016] Step 1.3: Using the meta-model as the fusion benchmark, clean, align, merge, and verify the results extracted in Step 1.2 to obtain the fused nodes and relationships, so as to ensure the consistency and standardization of the knowledge graph;

[0017] Step 1.4: The nodes and relationships fused in Step 1.3 are stored in the graph database according to the semantics defined in the meta-model to form the final knowledge graph.

[0018] The intelligent monitoring and auditing reasoning code generation method based on knowledge graph and templated mapping, as described above, specifies the allowed node types, node attributes, relationships between nodes, and semantic constraints in the knowledge graph.

[0019] As described above, in the intelligent monitoring and auditing reasoning code generation method based on knowledge graphs and templated mapping, step 2 specifically includes:

[0020] Step 2.1: Predefine a set of mapping rules for five types of nodes in the field of supervision and auditing. Each mapping rule defines the attribute extraction rules, logical element generation rules and the corresponding code template identifier.

[0021] Step 2.2: Read the nodes to be processed from the knowledge graph, identify their node types, and match the corresponding mapping rules from the mapping rule set according to the node types;

[0022] Step 2.3: According to the attribute extraction rules and logical element generation rules defined in the matching mapping rules, parse the attributes of the nodes to generate standardized logical element tuples. The standardized logical element tuples include the following fields: node type field, node identifier field, function name field, node description field, parsed logical element field, and metadata field.

[0023] Step 2.4: Select the corresponding code template from the preset template library based on the node type and template identifier in the mapping rules;

[0024] Step 2.5: Fill the corresponding placeholders in the selected code template with the generated logical element tuples to generate complete node execution function code;

[0025] Step 2.6: Perform syntax validation on the generated function code. Once the validation is successful, register it in the global function library to form a callable node execution function.

[0026] The intelligent monitoring and audit reasoning code generation method based on knowledge graph and templated mapping described above includes mapping rules for rule nodes, regulatory nodes, risk nodes, entity nodes and case nodes.

[0027] As described above, in the intelligent monitoring and auditing reasoning code generation method based on knowledge graphs and templated mapping, step 3 specifically includes:

[0028] Step 3.1: Predefine a set of mapping rules for relationships specific to the monitoring and auditing domain; each mapping rule defines the applicable relationship type, source node type constraints, target node type constraints, control code semantics, and the corresponding code generation template identifier;

[0029] Step 3.2: Based on the mapping rule set, extract various types of relation edges from the knowledge graph, and classify and aggregate them according to the source nodes to form a relation set with the source nodes as the unit;

[0030] Step 3.3: For each set of relations, select the corresponding preset control code generation template according to its relation type, fill the template with the aggregated relation data, and generate control code fragments with the source node as the unit;

[0031] Step 3.4: Integrate and encapsulate the generated control code fragments to generate an entity-level control module for each entity node. The entity-level control module integrates all control code fragments of the entity as the source node into one, and provides external calls through a unified execution interface.

[0032] Step 3.5: Generate a global-level control module for the entire inference process, and integrate all entity-level control modules into a unified control system. The global-level control module includes the code for controlling inter-entity dependencies and the main execution function framework.

[0033] As described above, in the intelligent monitoring and auditing reasoning code generation method based on knowledge graphs and templated mapping, step 4 specifically includes:

[0034] Step 4.1: Starting from the target entity node, traverse the knowledge graph according to the predefined relation type traversal strategy to determine the scope of modules to be activated; the scope of modules includes: entity-level control modules that need to be activated from the pre-generated control module library, and rule node execution functions and risk node execution functions that need to be imported from the node execution function library;

[0035] Step 4.2: Based on the determined module scope, perform dependency analysis on the rule nodes and risk nodes that need to be imported, construct a dependency graph based on the call dependencies between nodes, and use topological sorting to determine the hierarchical execution order of the nodes. Among them, the entity node, as the starting point of inference, is executed first, the rule node is executed after the entity node, and the risk node is executed after the rule node that triggered it.

[0036] Step 4.3: Import the entity-level control modules corresponding to the entity nodes from the pre-generated control module library, and import the node execution functions corresponding to the rule nodes and risk nodes from the node execution function library;

[0037] Step 4.4: According to the hierarchical execution order, dynamically bind the imported entity-level control modules with the node execution functions, and assemble them into an executable reasoning program for the target entity based on the pre-generated global control module framework;

[0038] Step 4.5: Execute the inference program, generate the result output interface, and format the inference result into a structured output.

[0039] This invention also provides an intelligent monitoring and auditing reasoning code generation system based on knowledge graphs and templated mapping. This system executes the intelligent monitoring and auditing reasoning code generation method based on knowledge graphs and templated mapping described above. The system includes a knowledge graph construction module, a templated mapping module, a control code generation module, and a reasoning chain assembly module; wherein...

[0040] The knowledge graph construction module is used to build a knowledge graph for the supervision and auditing field that includes legal nodes, rule nodes, case nodes, entity nodes, and risk nodes, as well as the relationships between the nodes.

[0041] The templated mapping module is used to parse the nodes in the knowledge graph into logical element tuples based on a predefined set of node mapping rules, and call the corresponding pre-set Python code template to generate node execution functions;

[0042] The control code generation module is used to generate control code describing the reasoning logic between nodes based on predefined relation mapping rules. The control code includes an entity-level control module corresponding to the entity node, and a global-level control module that coordinates multiple entity-level control modules.

[0043] The inference chain assembly module uses a graph traversal-based automatic inference chain assembly algorithm to start from the target entity node and dynamically aggregate the node execution functions and control code according to the dependencies between nodes in the knowledge graph to generate an executable and complete audit inference program.

[0044] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the method described in any of the preceding claims.

[0045] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor of an electronic device, causes the electronic device to perform any of the methods described above.

[0046] To achieve the above objectives, this invention adopts the following technical solution: First, a knowledge graph for the supervision and audit domain, including regulations, rules, cases, entities, risk nodes, and their relationships, is constructed. Second, through a predefined set of node mapping rules, various nodes in the graph are parsed into standardized logical element tuples, and corresponding pre-set Python code templates are called according to the node type to generate node execution functions. Simultaneously, control code describing the reasoning logic between nodes is generated based on predefined relationship mapping rules. Finally, using a graph traversal-based automatic assembly algorithm for reasoning chains, starting from the target entity node, relevant node functions and control code are dynamically aggregated into an executable complete audit reasoning program according to the dependencies between nodes in the knowledge graph. This invention, by designing a dedicated template system and structured mapping rules for the supervision and audit domain, achieves efficient automatic conversion from static knowledge to dynamic, reliable, and maintainable audit reasoning programs. It solves the technical problems of traditional knowledge graph applications being limited to retrieval and unable to directly drive decision-making, as well as the low efficiency and poor consistency of manual coding, significantly improving the intelligence level and response speed of supervision and audit work. Attached Figure Description

[0047] Figure 1 A flowchart illustrating the intelligent monitoring and auditing reasoning code generation method based on knowledge graph and templated mapping provided in this embodiment of the invention;

[0048] Figure 2 This is a schematic diagram of the architecture of an intelligent monitoring and auditing reasoning code generation system based on knowledge graphs and templated mapping provided in an embodiment of the present invention.

[0049] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0050] Figure 4 This is a schematic diagram of the structure of a computer-readable storage medium provided in an embodiment of the present invention. Detailed Implementation

[0051] To further illustrate the technical means and effects adopted by the present invention to achieve its intended purpose, the following, in conjunction with the accompanying drawings and preferred embodiments, details the specific implementation, structure, features, and effects of the intelligent monitoring and auditing reasoning code generation method and system, electronic device, and computer-readable storage medium based on knowledge graph and templated mapping proposed by the present invention. In the following description, different "one embodiment" or "another embodiment" do not necessarily refer to the same embodiment. Furthermore, specific features, structures, or characteristics in one or more embodiments can be combined in any suitable form.

[0052] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0053] The following describes in detail, with reference to the accompanying drawings, the specific solutions of the intelligent monitoring and auditing reasoning code generation method and system, electronic device, and computer-readable storage medium based on knowledge graph and templated mapping provided by the present invention.

[0054] Example 1:

[0055] Please see Figure 1 This is a flowchart illustrating the intelligent monitoring and auditing reasoning code generation method based on knowledge graph and templated mapping provided in this application embodiment. Figure 1 As shown, the process of generating intelligent monitoring and audit reasoning code based on knowledge graphs and templated mapping is specifically illustrated.

[0056] The present invention provides an intelligent monitoring and auditing reasoning code generation method based on knowledge graphs and templated mapping, the implementation process of which is as follows:

[0057] Step 1: Construct a knowledge graph for the field of supervision and auditing. The knowledge graph includes legal nodes, rule nodes, case nodes, entity nodes, and risk nodes, as well as the relationships between the nodes.

[0058] It's important to note that a knowledge graph is a technical approach that uses graph models to describe the relationships between knowledge and everything else. It typically consists of nodes and edges. Nodes represent entities or concepts in the real world, while edges represent the various semantic relationships between nodes. Knowledge graphs can organize massive amounts of heterogeneous and multi-source information in a way that more closely resembles human cognition, providing machines with the ability to understand the world.

[0059] In this invention, to meet the specific needs of the field of monitoring and auditing, it is first necessary to construct a specialized domain knowledge graph. Monitoring and auditing is a systematic work aimed at ensuring that organizational activities comply with applicable laws, policies, and standards, and assessing their effectiveness, efficiency, and compliance. The knowledge involved in this field is characterized by diverse sources (such as national laws, industry standards, and internal corporate regulations), complex structure (containing a large number of conditional judgments and logical deductions), and dynamic changes.

[0060] Therefore, the knowledge graph in the field of supervision and auditing constructed in this invention is not a general knowledge base, but rather specifically designed for subsequent automated reasoning. Its core lies in transforming the experience of auditing experts, scattered legal provisions, and historical cases into graph-structured data that computers can understand and process. Specifically, this knowledge graph contains at least the following five types of core nodes and the relationships between them:

[0061] 1. Node type definition

[0062] 1.1. An entity node represents a specific object of interest in the audit process. Entity nodes are the starting and ending points of audit inference, and all risk analysis revolves around these specific objects. Examples include: "Company XX", "Zhang San", "Purchase Contract A2023-001", "Equipment Procurement Project", and "Financial Statements - Q3 2025".

[0063] 1.2. Regulation Nodes represent various normative documents that need to be followed in monitoring and auditing activities. Depending on their source and legal effect, regulation nodes can contain the following subtypes, but they are uniformly stored as "Regulation Node" type in the knowledge graph, with their specific subtypes recorded through node attributes (such as the "source_type" field):

[0064] Legal and regulatory sub-types: Normative documents with legal force formulated by national legislative or administrative organs, such as the "Tendering and Bidding Law of the People's Republic of China" and the "Supervision Law of the People's Republic of China." These types of documents represent the highest level of basis for audit judgments.

[0065] Industry standard subtype: Technical specifications or codes of conduct issued by industry associations, professional organizations, or regulatory agencies that have general binding force within a specific industry, such as the "Basic Norms for Enterprise Internal Control," the "Standards for Measurement and Pricing of Construction Projects," and the "Chinese Certified Public Accountant Auditing Standards." These standards are important bases for audit judgments within their respective professional fields.

[0066] Internal regulations subtype: Management rules, operating procedures, implementation details, etc., formulated internally by the organization.

[0067] Examples include "XX Company Procurement Management Regulations" and "XX Unit Financial Reimbursement System." These types of documents reflect specific management requirements within the organization.

[0068] Although the aforementioned subtypes differ in their drafting entities and legal effect, from an audit reasoning perspective, they are all normative texts serving as the basis for judgment. Therefore, they are uniformly represented as "regulatory nodes" in the knowledge graph. This unified representation simplifies the subsequent code generation processing logic, while retaining necessary distinguishing information through attribute fields, facilitating refined processing when needed.

[0069] 1.3. A rule node represents the transformation of abstract regulations, standards, or systems into concrete, executable audit judgment logic. Rule nodes are typically expressed in the form of condition-conclusion (If-Then) statements, serving as a bridge connecting normative text and executable code.

[0070] For example, an audit rule for a "procurement project" could be defined as: "If the 'procurement method' of the 'procurement project' is 'single source,' and the 'budget amount' of the 'procurement project' is greater than 1 million yuan, and the 'procurement project' does not provide a 'single source expert review report,' then a 'high risk' condition is triggered." In this example, "procurement method" and "budget amount" are attributes of the entity node, while "not providing a 'single source expert review report'" needs to be correlated with the case node or document entity node for judgment.

[0071] Rule nodes and regulatory nodes form a "source-transformation" relationship: regulatory nodes store the original normative text, while rule nodes store the parsed, executable judgment logic. This separation design makes the source of knowledge traceable (meeting audit compliance requirements) while ensuring the flexibility of knowledge application.

[0072] 1.4. Case Nodes represent historically significant audit cases or typical issues that have reference value. For example, "A company was penalized for violating single-source procurement regulations." This node includes a description of the case, the risks involved, and the final penalty. Case nodes supplement rule nodes, used for reasoning based on similarity or to provide explanatory evidence.

[0073] 1.5. A risk node represents a specific type of risk or issue identified during the audit process. Risk nodes are conclusive points in audit reasoning and are typically associated with specific entity nodes. Examples include: "bid rigging risk," "budget overrun risk," "data breach risk," and "conflict of interest risk."

[0074] 2. Definition of relationships between nodes

[0075] The value of a knowledge graph lies not only in the nodes themselves, but also in the relationships between them. These relationships describe the inherent logic of knowledge and form the basis for subsequent code generation and reasoning. This invention employs specialized relationship types tailored to the auditing and monitoring domain, enabling the knowledge graph to directly reflect the thought models of domain experts and reducing the semantic understanding difficulty during subsequent code generation.

[0076] 2.1. Entity-Risk Relationship (HAS_RISK) indicates that an entity carries a certain risk. This relationship directly expresses the core audit concern—the association between the entity and the risk. For example, establishing an HAS_RISK relationship between the entity node "Purchase Contract A2023-001" and the risk node "Bid Collusion Risk" indicates that the purchase contract carries the risk of bid rigging.

[0077] 2.2. The DERIVED_FROM relationship indicates which law, standard, or system a rule is based on. This relationship ensures the legality and traceability of the rule's source, meeting the core requirements of audit compliance. For example, the rule node "Single Source Procurement Exceeding Limit Inspection Rule" establishes a DERIVED_FROM relationship with the relevant clauses of the "Tendering and Bidding Law of the People's Republic of China" law node, clarifying the legal basis of the rule.

[0078] 2.3. Rule-Risk Association (LEADS_TO) indicates what kind of risk will be triggered when a certain rule's condition is met. This relationship establishes a causal chain, enabling the system to deduce risk identification from rule triggering.

[0079] For example, when the "Single Source Procurement Exceeding Limit Inspection Rule" is triggered, the LEADS_TO relationship points to the risk node "Procurement Compliance Risk", indicating that the consequence of triggering the rule is the identification of procurement compliance risk.

[0080] 2.4. Entity-Rule Associations (TRIGGERS) indicate which rules need to be applied to a given entity for inspection. This relationship clarifies the scope of inspection, enabling the system to quickly locate the rules that need to be applied starting from the entity.

[0081] For example, all entities of type "procurement project" can be linked to rule nodes such as "single-source procurement exceeding limits inspection rules" and "open bidding ratio inspection rules" through the TRIGGERS relationship.

[0082] 2.5. Case-Rule Relationship (SUPPORTS) indicates that a historical case is a specific manifestation or supplement to a rule. This relationship introduces empirical evidence and provides case support for audit conclusions. For example, the case node "A Company's Violation of Single-Source Procurement Regulations and Being Penalized" is linked to the rule node "Single-Source Procurement Exceeding Limits Inspection Rule" through the SUPPORTS relationship, indicating that this case is a specific manifestation of the rule.

[0083] 3. Construction of Knowledge Graphs

[0084] In the specific implementation of this step, the knowledge graph is constructed using a combination of top-down (ontology defined by domain experts) and bottom-up (knowledge extracted from structured or unstructured data sources) approaches. This process is an iterative, progressive, and mutually validated closed-loop process to ensure that the constructed knowledge graph not only conforms to the thinking of domain experts but also fully covers the knowledge in the actual data. Specifically, it includes the following four sub-steps:

[0085] Step 1.1: Based on the predefined metamodel construction rules, define the conceptual model of the knowledge graph, i.e., the metamodel. This metamodel specifies the allowed node types, node attributes, relationships between nodes, and their semantic constraints in the knowledge graph. It serves as the "syntax rules" for all subsequent steps, as shown in Table 1 below:

[0086] Table 1: Definition of Metamodel

[0087]

[0088] The meta-model plays the following roles throughout the construction process: (1) guiding knowledge extraction: clarifying "what to extract" and telling the NLP module which types of entities and relationships to focus on; (2) constraining knowledge fusion: providing a benchmark for alignment and merging to ensure that the fused knowledge conforms to the predefined specifications; (3) verifying the construction results: serving as a verification standard to check the legality and completeness of the final knowledge graph.

[0089] Step 1.2: Knowledge Extraction -- Identifying knowledge from multi-source data based on meta-models. It uses the meta-model defined in Step 1.1 as the extraction template and utilizes Natural Language Processing (NLP) technology to automatically or semi-automatically identify and extract specific nodes and relationships from various data sources.

[0090] The data sources include: legal documents such as the "Tendering and Bidding Law of the People's Republic of China" and the "Supervision Law of the People's Republic of China"; industry standards such as the "Basic Norms for Enterprise Internal Control"; internal systems such as the organization's internal procurement management methods and financial reimbursement systems; audit reports such as findings and recommendations from historical audit projects; and a case library of typical violations and penalty cases.

[0091] The extraction process is as follows: (1) Text preprocessing: The original document is formatted, paragraphs are segmented, and sentences are split; (2) Entity recognition: Based on the node types defined in the meta-model, candidate entities in the text are identified, including: identifying the name of the regulation and the clause number (corresponding to the regulation node); identifying conditional statements and action descriptions (corresponding to the rule node); identifying the company name, personnel name, and project name (corresponding to the entity node); (3) Relationship extraction: Based on the relationship types defined in the meta-model, the semantic relationship between entities is identified, including: identifying the expression "formulated in accordance with a certain regulation" (corresponding to the DERIVED_FROM relationship); identifying the expression "causes a certain risk" (corresponding to the LEADS_TO relationship); (4) Attribute filling: The attribute values ​​of the nodes are extracted from the text, including: the effective date and issuing authority are extracted from the regulatory clauses; and the conditional expression and severity are extracted from the rule description.

[0092] Output: A preliminary set of nodes and relationships (which may contain redundancy, conflicts, or non-compliance with meta-model specifications).

[0093] Step 1.3: Knowledge Fusion -- Alignment and merging based on the meta-model. It uses the meta-model defined in Step 1.1 as the fusion benchmark, cleansing, aligning, merging, and verifying the results extracted in Step 1.2 to obtain the fused nodes and relationships, so as to ensure the consistency and standardization of the knowledge graph.

[0094] Step 1.4: Knowledge Storage -- Store the standardized knowledge in the graph database; store the nodes and relationships merged in Step 1.3 in the graph database according to the semantics defined by the meta-model to form the final usable knowledge graph.

[0095] The knowledge graph constructed in the above manner is not only comprehensive and logically rigorous, but also specifically optimized for subsequent automated code generation, realizing a leap from "knowledge storage" to "knowledge application".

[0096] Step 2: Based on a predefined set of node mapping rules, parse the various types of nodes in the knowledge graph into standardized logical element tuples, and call the corresponding pre-set Python code template according to the node type to generate node execution functions;

[0097] It should be noted that after constructing the knowledge graph for the supervision and auditing domain, the subsequent step is to transform the static knowledge in the graph into executable code. The core of this step lies in using a predefined set of node mapping rules to parse different types of nodes into standardized logical element tuples, and then generating node execution functions using pre-defined code templates. This process achieves an automated conversion from "knowledge representation" to "code representation."

[0098] 1. Definition of node mapping rule set

[0099] The node mapping rule set is a predefined set of transformation rules for the surveillance and audit domain, used to guide how to extract logical elements from the attributes of knowledge graph nodes. These rules are developed based on the analysis and abstraction of a large number of audit regulations, rules, and cases, ensuring the accuracy and consistency of the transformation process.

[0100] 1.1. Composition of the mapping rule set

[0101] Each mapping rule contains the following elements:

[0102] Applicable node types: Which type of node the rule applies to (legal node, rule node, case node, entity node, risk node);

[0103] Attribute extraction rules: How to extract key information from the attributes of a node, such as extracting the condition expression from the condition attribute and the action type from the action attribute;

[0104] Logical element generation rules: How to organize the extracted information into a standardized tuple structure;

[0105] Template identifier: The code template ID used to generate this node function (e.g., TEMPLATE_RULE, TEMPLATE_REGULATION, TEMPLATE_RISK, etc.).

[0106] 1.2. Definition of mapping rules for five types of nodes:

[0107] Based on the characteristics of knowledge in the field of supervision and auditing, this invention defines specific mapping rules for five types of core nodes, as shown in Table 2:

[0108] Table 2: Mapping rules for the five types of nodes

[0109]

[0110] 2. Generation of standardized logical element tuples

[0111] Logical element tuples are the structured parsing results of node content, transforming the natural language descriptions or semi-structured attributes of nodes into a standardized format that can be processed by computers. This process forms the basis for subsequent template filling.

[0112] 2.1. Based on the above mapping rule set, the nodes in the knowledge graph are parsed into standardized logical element tuples according to the following steps:

[0113] (1) Node type identification -- Read the type attribute of the node to determine the node type;

[0114] (2) Mapping rule matching -- Select the corresponding mapping rule according to the node type;

[0115] (3) Attribute value extraction -- Read attribute values ​​from nodes according to the attribute extraction rules defined in the mapping rules;

[0116] (4) Logical element parsing -- According to the logical element generation rules defined by the mapping rules, the attribute values ​​are transformed into a standardized structure;

[0117] (5) Tuple encapsulation -- Encapsulate the parsing results into standardized logical element tuples.

[0118] 2.2. Structure of Logical Element Tuples

[0119] Regardless of the node type, the generated logical element tuples after parsing all adopt a unified standardized structure, containing the following core fields, as shown in Table 3 below:

[0120] Table 3: Core Fields Included in Logical Element Tuples

[0121]

[0122] 3. Pre-built Python code template library

[0123] Code templates are predefined code snippets containing placeholders used to populate the logical elements parsed from nodes. This invention designs specialized templates for different types of nodes to ensure that the generated code has a unified structure, consistent style, and is easy to maintain. The templates are implemented using mainstream template engines (such as Jinja2) and support advanced features such as conditional statements, loops, and variable substitution. See Table 4 for the template types and functions:

[0124] Table 4: Five Template Types and Function Tables

[0125]

[0126] The design principles of the above templates take into account the following aspects: (1) Uniformity: Use the same template for nodes of the same type to ensure that the generated function style is consistent; (2) Readability: The template itself has good readability, making it easy to understand and maintain; (3) Extensibility: The template reserves extension points to adapt to changes in node attributes; (4) Security: The template only contains the code skeleton and does not contain specific business logic to ensure security.

[0127] 4. Generation process of node execution functions

[0128] Based on the above mapping rule set, parsing process, and template library, this invention generates node execution functions according to the following process:

[0129] 4.1. Node Reading: Read a node to be processed from the knowledge graph and obtain all attribute information of the node;

[0130] 4.2. Type Identification and Rule Matching: Read the node's `type` attribute to determine the node type (rule node, regulatory node, risk node, entity node, or case node). Based on the node type, match the corresponding mapping rule from the mapping rule set.

[0131] 4.3. Logical Element Parsing: The node attributes are parsed according to the attribute extraction rules and logical element generation rules defined in the matching mapping rules.

[0132] For rule nodes, the condition attribute is parsed into structured condition elements (left operand, operator, right operand), and the action attribute is parsed into structured action elements (action type, risk type, severity).

[0133] For regulatory nodes, extract the core requirements for compliance checks from the content attribute and record metadata such as source_type and effective_date;

[0134] For risk nodes, the indicators attribute is parsed into a list of indicators that can be checked one by one, generating a logical framework for risk assessment.

[0135] After parsing, the results are encapsulated into standardized logical element tuples.

[0136] 4.4. Template Selection: Select the corresponding code template from the preset template library based on the node type and template identifier in the mapping rules.

[0137] 4.5. Template Population: Using the generated logical element tuples as population data, the template engine populates the selected code template. During the population process, placeholders in the template are replaced with the actual parsed results, generating complete, executable Python function code.

[0138] 4.6. Syntax Validation: Perform syntax checks on the generated Python function code to ensure its correctness. If a syntax error is found, log the error message and trigger an alert.

[0139] 4.7. Function Registration: After syntax validation, the generated functions are registered in the global function library, using the function name as the key and the function object as the value, for use in subsequent steps. The executable functions generated in this step, corresponding to various types of nodes, form the node execution function library, including rule node execution functions, risk node execution functions, entity node execution functions, etc.

[0140] Through the above steps, this invention successfully transforms static nodes in a knowledge graph into executable Python functions, laying the foundation for subsequent inference chain assembly and execution. This process achieves an automated conversion from "knowledge representation" to "code representation," representing the core of the "knowledge graph as code" technological paradigm.

[0141] Step 3: Based on predefined relationship mapping rules, generate control code that describes the reasoning logic between nodes;

[0142] It's important to note that after generating the node execution functions, each node in the knowledge graph has been transformed into an executable Python function. However, these functions are currently isolated and haven't yet formed an organic reasoning whole. The core of this step lies in using predefined relation mapping rules to transform the edges (i.e., the relationships between nodes) in the knowledge graph into control code describing the calling logic between nodes, enabling node functions to work collaboratively and form a complete reasoning logic. Specifically, the relationships processed in this step are the five types of specialized relationships mentioned earlier: TRIGGERS, LEADS_TO, HAS_RISK, DERIVED_FROM, and SUPPORTS.

[0143] Step 3.1: Definition of the relation mapping rule set

[0144] The relation mapping rule set is a predefined set of transformation rules for the five types of specialized relations mentioned above, used to guide how to generate corresponding control codes from relations in the knowledge graph. Each mapping rule contains the following elements, as shown in Table 5 below:

[0145] Table 5: Core Elements of Relation Mapping Rules

[0146]

[0147] The mapping rules for these five core relationships are defined in Table 6:

[0148] Table 6: Definition of Mapping Rules for Five Types of Relationships

[0149]

[0150] For each relation type, the system pre-designs a corresponding control code template. The template contains the logical framework implemented during the inference process of that type of relation, and reserves dynamic information that needs to be filled in (such as source node function name, target node function name, node ID, etc.).

[0151] Step 3.2: Control code generation

[0152] Based on the above relationship mapping rules and preset control code templates, the system generates specific control code according to the following steps:

[0153] Step 3.2.1: Relational Data Extraction

[0154] Read all the relation edges that need to be processed from the knowledge graph. For each relation, extract the following information: relation type (e.g., TRIGGERS); source node ID and its type; target node ID and its type; relation attributes (e.g., confidence, evidence description, etc.).

[0155] Step 3.2.2: Relationship Classification and Aggregation

[0156] Relationships are categorized and aggregated based on their source nodes, forming a set of relationships with each source node as the unit: For entity nodes, all TRIGGERS and HAS_RISK relationships are aggregated. For rule nodes, all LEADS_TO, DERIVED_FROM, and SUPPORTS relationships are aggregated.

[0157] Step 3.2.3: Template Selection and Filling

[0158] For each set of relations, a corresponding control code generation template is selected based on its relation type. The aggregated relation data is then populated into the template to generate specific control code snippets. Table 7 below shows the content of the code snippets generated from the relation sets:

[0159] Table 7: Code snippet content for generating relation sets

[0160]

[0161] Step 3.2.4: Code Snippet Storage

[0162] The generated control code fragments are indexed and stored according to their respective source nodes, forming a set of control code fragments based on the source node.

[0163] Step 3.3: Integration and Encapsulation of Control Code

[0164] Through the above relational classification and aggregation, a series of aggregation control code fragments are generated, each based on a source node. These aggregation fragments contain the control logic for all relations involved in each source node. For example, a complete control code fragment containing its TRIGGERS rule list, HAS_RISK predefined risk list, and associated relational mapping information such as LEADS_TO, DERIVED_FROM, and SUPPORTS is generated for each entity node. These node-based aggregation fragments need to be further integrated into a complete, executable control module to coordinate their operation during inference. This invention achieves the integration of control code through the following two-layer mechanism:

[0165] First-level integration: Entity-level control module (entity relationship router)

[0166] A dedicated entity relationship router is generated for each entity node, integrating all control code snippets related to that entity into a complete control module. The entity-level control module performs the following integration tasks during code generation, as detailed in Table 8:

[0167] Table 8: Integration of Entity-Level Control Modules

[0168]

[0169] Through the above integration process, the generated entity-level control module not only integrates scattered control code fragments but, more importantly, achieves encapsulation—providing a unified `execute(self, context)` interface externally while internally hiding the specific implementation details such as the rule call list and various mapping tables. This encapsulation allows upper-level callers to complete the entire inference logic of the entity simply by calling the unified execution interface, without needing to know how many rules exist within the entity or how these rules are organized. Simultaneously, through this integration, the generated entity-level control module is a complete Python class definition, containing all the data structures and execution logic required for the entity's audit inference. These modules will be statically stored in the code repository for subsequent inference steps to call.

[0170] Second-level integration: Global-level control module (inference chain controller)

[0171] When reasoning involves multiple entities, a global control module is generated for the entire reasoning process, integrating multiple entity relationship routers into a unified control system. The global control module performs the following tasks during code generation, as detailed in Table 9:

[0172] Table 9: Integration of Global-Level Control Modules

[0173]

[0174] It's important to note that the entity-level control modules generated above, corresponding to each entity node, along with the generated global-level control module, constitute the control module library. Meanwhile, the global-level control module generated in step 3 is a separate Python code file containing the definitions of all entity-level control modules and the coordination logic between them. However, at this point, this module is not yet bound to specific input data, nor does it form a complete executable program entry point—it's more like a "component library," awaiting dynamic assembly in step 4 based on the specific inference objective.

[0175] Step 4: Using a graph traversal-based automatic assembly algorithm for reasoning chains, starting from the target entity node, the node execution functions and control code are dynamically aggregated according to the dependencies between nodes in the knowledge graph to generate an executable and complete audit reasoning program.

[0176] After generating the node execution function (step 2) and control code (step 3), this invention has all the "components" for building the inference program. The core of this step lies in dynamically assembling these "components" into a complete, executable audit inference program.

[0177] It should be noted that: Step 3 has already pre-created entity-level control modules for all entities in the knowledge graph and generated a global control framework for the entire system. Step 4 does not regenerate these modules, but rather, starting from the specific reasoning objective, determines which pre-generated modules need to be activated and dynamically assembles them with the node execution functions generated in Step 2 into a reasoning program for the specific objective.

[0178] 4.1 Definition of the Inference Chain Assembly Algorithm

[0179] The inference chain assembly algorithm is a graph traversal algorithm specifically designed for the field of supervision and auditing. Its core idea is to start from the target entity node, traverse along the relation edges in the knowledge graph, determine which pre-generated control modules need to be activated, determine the execution order based on the dependencies between nodes, and finally dynamically aggregate the node execution functions and control modules into an executable inference program.

[0180] 4.2 Node Collection Based on Graph Traversal -- Determining the Modules to be Activated

[0181] The first stage of the algorithm starts from the target entity node, traverses the knowledge graph, and determines which modules need to be activated from the module library pre-generated in step 3.

[0182] 4.2.1 Definition of Traversal Strategy

[0183] Based on the role of relation types in the reasoning process, this invention defines different traversal strategies, as shown in Table 10:

[0184] Table 10: Traversal Strategies for Different Relation Types

[0185]

[0186] 4.2.2 Description of the traversal process

[0187] The traversal process is performed according to the following steps:

[0188] (1) Initialization: Add the target entity node to the queue to be traversed and mark it as visited;

[0189] (2) Looping: Take a node from the queue and query all outgoing edges of that node;

[0190] (3) Relationship filtering: Based on the traversal strategy, determine whether each outgoing edge needs to be traversed further;

[0191] (4) Node collection: Add the target node that needs to be traversed to the queue, and at the same time record all related nodes (including nodes that do not need to be traversed) into the node set;

[0192] (5) Termination condition: When the queue is empty, the traversal ends and a complete set of nodes to be executed is obtained.

[0193] It should be noted that the traversal here is fundamentally different from the relation aggregation in step 3: (1) The relation aggregation in step 3 is global and static - control modules are pre-created for all entities in the knowledge graph, regardless of whether these entities will be used in the future; (2) The graph traversal in step 4 is targeted and dynamic - the modules to be activated are selected from the pre-generated module library according to the specific reasoning target (a certain entity).

[0194] 4.3 Determining the execution order based on dependencies

[0195] The second stage of the algorithm is to perform dependency analysis on the collected nodes to determine their execution order in the inference process.

[0196] 4.3.1 Dependency Analysis

[0197] The dependencies between nodes are determined by the relation edges in the knowledge graph, as shown in Table 11 below:

[0198] Table 11: Dependency Relationships Between Nodes

[0199]

[0200] 4.3.2 Method for Determining Execution Order

[0201] Based on the above dependencies, this invention uses topological sorting to determine the hierarchical execution order of nodes:

[0202] (1) Construct a dependency graph: Construct a dependency graph with nodes as vertices and dependencies as directed edges. If node A depends on node B, there is an edge from A to B (indicating that B should be executed before A).

[0203] (2) Topological sorting: Perform topological sorting on the dependency graph to obtain the linear execution order of the nodes. Topological sorting guarantees that for any dependency relationship, the node that is depended on is always ranked before the node that depends on it.

[0204] (3) Hierarchical execution: The topology sorting results are grouped by level. Nodes at the same level have no mutual dependence and can be executed in parallel.

[0205] 4.4 Generation of Executable Reasoning Programs

[0206] The third stage of the algorithm involves dynamically generating an executable inference program based on the determined set of nodes and execution order, following a hierarchical execution sequence. This "generation" is a dynamic assembly based on the control module pre-generated in step 3. It is performed according to the following steps:

[0207] (1) Module import: Import the modules marked as "need to be activated" (such as the target entity's entity router, related rule functions, risk functions, etc.) from the control module library generated in step 3.

[0208] (2) Node execution function binding: Import the node execution functions to be called from the node function library generated in step 2, and associate them with the rule list in the entity router.

[0209] (3) Execution framework instantiation: Bind the main execution function framework in the global control module generated in step 3 to the target entity of this inference to generate specific execution code.

[0210] (4) Input interface generation: Generate data input interface to map the externally passed audit context to the internal data structure of the program.

[0211] (5) Output interface generation: Generate the result output interface and format the reasoning result into a structured output.

[0212] As can be seen, the inference program here is dynamically assembled based on the control modules pre-generated in step 3. The core work of step 4 is to select appropriate modules from the pre-generated module library according to the specific inference goal, and dynamically bind them with the node execution functions of step 2 to form an executable program for a specific entity. This approach ensures both code reusability and flexibility for different goals.

[0213] Example 2:

[0214] Please see Figure 2 This is a schematic diagram of the architecture of the intelligent monitoring and auditing reasoning code generation system based on knowledge graphs and templated mapping provided in the embodiments of this application. Figure 2 As shown, the system architecture of the intelligent monitoring and auditing reasoning code generation system based on knowledge graphs and templated mapping is specifically illustrated.

[0215] This invention discloses an intelligent monitoring and auditing reasoning code generation system based on knowledge graphs and templated mapping. This system executes the intelligent monitoring and auditing reasoning code generation method based on knowledge graphs and templated mapping described in the above embodiments. The system includes a knowledge graph construction module, a templated mapping module, a control code generation module, and a reasoning chain assembly module.

[0216] The knowledge graph construction module is used to build a knowledge graph for the supervision and auditing field that includes legal nodes, rule nodes, case nodes, entity nodes, and risk nodes, as well as the relationships between the nodes.

[0217] The templated mapping module is used to parse the nodes in the knowledge graph into logical element tuples based on a predefined set of node mapping rules, and call the corresponding pre-set Python code template to generate node execution functions;

[0218] The control code generation module is used to generate control code describing the reasoning logic between nodes based on predefined relation mapping rules. The control code includes an entity-level control module corresponding to the entity node, and a global-level control module that coordinates multiple entity-level control modules.

[0219] The inference chain assembly module uses a graph traversal-based automatic inference chain assembly algorithm to start from the target entity node and dynamically aggregate the node execution functions and control code according to the dependencies between nodes in the knowledge graph to generate an executable and complete audit inference program.

[0220] Example 3:

[0221] See Figure 3 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application, such as... Figure 3 As shown, the electronic device 3000 includes a memory 3100, a processor 3200, and a computer program stored in the memory 3100 and executable by the processor. When the processor 3200 executes the program code of the method steps according to the present invention, it executes each step of the method in the present invention, thereby realizing an intelligent monitoring and auditing reasoning code generation method based on knowledge graphs and templated mapping. The intelligent monitoring and auditing reasoning code generation method based on knowledge graphs and templated mapping has been described in detail above and will not be repeated here.

[0222] The memory 3100 may be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. The memory 3100 has storage space 3300 for storing program code for performing any of the method steps described above, which is used to execute the method steps according to the invention. The program code for performing the method steps according to the invention can be read from or written to one or more computer program products. These computer program products include program code carriers such as hard disks, CDs, memory cards, or floppy disks. Such computer program products are typically, for example... Figure 4 The computer-readable storage medium is described above. A computer device may include multiple processors, each of which may be a single-core (single CPU) processor or a multi-core (multi CPU) processor. Here, a processor may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0223] Example 4:

[0224] Please see the appendix Figure 4 This is a schematic diagram of the structure of a computer-readable storage medium provided in an embodiment of the present invention, such as... Figure 4 As shown, a computer-readable storage medium 4000 stores program code 4100 for executing the method steps according to the present invention. When executed by a processor, the program code 4100 for executing the method steps according to the present invention is used to implement the intelligent monitoring and auditing reasoning code generation method based on knowledge graphs and templated mapping as described above. The intelligent monitoring and auditing reasoning code generation method based on knowledge graphs and templated mapping has been described in detail above and will not be repeated here.

[0225] The methods described in the above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. The computer-readable storage medium 4000 may include computer storage media and communication media, and may also include any medium capable of transferring a computer program from one place to another. The storage medium can be any target medium accessible by a computer.

[0226] As one possible design, the computer-readable storage medium 4000 may include a compact disc read-only memory (CD ROM), RAM, ROM, EEPROM, or other optical disc storage; the computer-readable medium may include a disk storage device or other disk storage device. Furthermore, any connecting cable may also be appropriately referred to as a computer-readable storage medium. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. As used herein, disks and optical discs include optical discs (CD), laser discs, optical discs, digital versatile discs (DVD), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while optical discs optically reproduce data using lasers.

[0227] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention without departing from the principles and spirit of the present invention.

Claims

1. A method for generating intelligent monitoring and auditing reasoning code based on knowledge graphs and templated mapping, characterized in that, Includes the following steps: Step 1: Construct a knowledge graph for the field of supervision and auditing. The knowledge graph includes legal nodes, rule nodes, case nodes, entity nodes, and risk nodes, as well as the relationships between the nodes. Step 2: Based on a predefined set of node mapping rules, parse the various types of nodes in the knowledge graph into standardized logical element tuples, and call the corresponding pre-set Python code template according to the node type to generate node execution functions; Step 3: Based on predefined relation mapping rules, generate control code to describe the reasoning logic between nodes. The control code includes entity-level control modules corresponding to entity nodes and global-level control modules that coordinate multiple entity-level control modules. Step 4: Using a graph traversal-based automatic assembly algorithm for reasoning chains, starting from the target entity node, the node execution functions and control code are dynamically aggregated according to the dependencies between nodes in the knowledge graph to generate an executable and complete audit reasoning program; Step 4 includes: Step 4.1: Starting from the target entity node, traverse the knowledge graph according to the predefined relation type traversal strategy to determine the scope of modules to be activated; the scope of modules includes: entity-level control modules that need to be activated from the pre-generated control module library, and rule node execution functions and risk node execution functions that need to be imported from the node execution function library; Step 4.2: Based on the determined module scope, perform dependency analysis on the rule nodes and risk nodes that need to be imported, construct a dependency graph based on the call dependencies between nodes, and use topological sorting to determine the hierarchical execution order of the nodes. Among them, the entity node, as the starting point of inference, is executed first, the rule node is executed after the entity node, and the risk node is executed after the rule node that triggered it. Step 4.3: Import the entity-level control modules corresponding to the entity nodes from the pre-generated control module library, and import the node execution functions corresponding to the rule nodes and risk nodes from the node execution function library; Step 4.4: According to the hierarchical execution order, dynamically bind the imported entity-level control modules with the node execution functions, and assemble them into an executable inference program for the target entity node based on the pre-generated global control module framework; Step 4.5: Execute the inference program, generate the result output interface, and format the inference result into a structured output.

2. The intelligent monitoring and auditing reasoning code generation method based on knowledge graph and templated mapping according to claim 1, characterized in that, The relationships in the knowledge graph include at least the following five types of specialized relationships: entity-rule relationship, rule-risk relationship, entity-risk relationship, regulation-rule relationship, and case-rule relationship.

3. The intelligent monitoring and auditing reasoning code generation method based on knowledge graph and templated mapping according to claim 1, characterized in that, Step 1 specifically involves: Step 1.1: Define the metamodel of the knowledge graph according to the predefined metamodel construction rules; Step 1.2: Using the meta-model as an extraction template, natural language processing (NLP) technology is used to identify and extract specific nodes and relationships from various data sources; Step 1.3: Using the meta-model as the fusion benchmark, clean, align, merge, and verify the results extracted in Step 1.2 to obtain the fused nodes and relationships, so as to ensure the consistency and standardization of the knowledge graph; Step 1.4: The nodes and relationships fused in Step 1.3 are stored in the graph database according to the semantics defined in the meta-model to form the final knowledge graph.

4. The intelligent monitoring and auditing reasoning code generation method based on knowledge graph and templated mapping according to claim 3, characterized in that, The meta-model specifies the allowed node types, node attributes, relationships between nodes, and semantic constraints in the knowledge graph.

5. The intelligent monitoring and auditing reasoning code generation method based on knowledge graph and templated mapping according to claim 1, characterized in that, Step 2 specifically involves: Step 2.1: Predefine a mapping rule set for five types of nodes in the field of supervision and auditing. The mapping rule set includes mapping rules for rule nodes, legal nodes, risk nodes, entity nodes and case nodes. Each mapping rule defines attribute extraction rules, logical element generation rules and corresponding code template identifiers. Step 2.2: Read the nodes to be processed from the knowledge graph, identify their node types, and match the corresponding mapping rules from the mapping rule set according to the node types; Step 2.3: According to the attribute extraction rules and logical element generation rules defined in the matching mapping rules, parse the node attributes to generate standardized logical element tuples. It includes the following fields: node type field, node identifier field, function name field, node description field, parsed logical element field, and metadata field; Step 2.4: Select the corresponding code template from the preset template library based on the node type and template identifier in the mapping rules; Step 2.5: Fill the corresponding placeholders in the selected code template with the generated logical element tuples to generate complete node execution function code; Step 2.6: Perform syntax validation on the generated function code. Once the validation is successful, register it in the global function library to form a callable node execution function.

6. The intelligent monitoring and auditing reasoning code generation method based on knowledge graph and templated mapping according to claim 2, characterized in that, Step 3 specifically involves: Step 3.1: Predefine a set of mapping rules for relationships specific to the monitoring and auditing domain; each mapping rule defines the applicable relationship type, source node type constraints, target node type constraints, control code semantics, and the corresponding code generation template identifier; Step 3.2: Based on the mapping rule set, extract various types of relation edges from the knowledge graph, and classify and aggregate them according to the source nodes to form a relation set with the source nodes as the unit; Step 3.3: For each set of relations, select the corresponding preset control code generation template according to its relation type, fill the template with the aggregated relation data, and generate control code fragments with the source node as the unit; Step 3.4: Integrate and encapsulate the generated control code fragments to generate an entity-level control module for each entity node. The entity-level control module integrates all control code fragments of the entity node as the source node into one, and provides external calls through a unified execution interface. Step 3.5: Generate a global-level control module for the entire inference process, and integrate all entity-level control modules into a unified control system. The global-level control module includes the dependency control code between entity nodes and the main execution function framework.

7. A smart monitoring and auditing reasoning code generation system based on knowledge graphs and templated mapping, characterized in that, The system executes the intelligent monitoring and auditing reasoning code generation method based on knowledge graph and templated mapping as described in any one of claims 1-6. The system includes a knowledge graph construction module, a templated mapping module, a control code generation module, and a reasoning chain assembly module; wherein... The knowledge graph construction module is used to build a knowledge graph for the supervision and auditing field that includes legal nodes, rule nodes, case nodes, entity nodes, and risk nodes, as well as the relationships between the nodes. The templated mapping module is used to parse the nodes in the knowledge graph into logical element tuples based on a predefined set of node mapping rules, and call the corresponding pre-set Python code template to generate node execution functions; The control code generation module is used to generate control code describing the reasoning logic between nodes based on predefined relation mapping rules. The control code includes an entity-level control module corresponding to the entity node, and a global-level control module that coordinates multiple entity-level control modules. The reasoning chain assembly module is used to automatically assemble the reasoning chain based on graph traversal. Starting from the target entity node, it dynamically aggregates the node execution functions and control code according to the dependency relationship between nodes in the knowledge graph to generate an executable complete audit reasoning program. The inference chain assembly module is specifically used for: Starting with the target entity node, the knowledge graph is traversed according to a predefined relation type traversal strategy to determine the scope of modules to be activated. The scope of modules includes: entity-level control modules that need to be activated from the pre-generated control module library, and rule node execution functions and risk node execution functions that need to be imported from the node execution function library. Based on the determined module scope, a dependency analysis is performed on the rule nodes and risk nodes that need to be imported. A dependency graph is constructed based on the call dependencies between nodes, and a topological sorting is used to determine the hierarchical execution order of the nodes. Entity nodes, as the starting point of inference, are executed first, rule nodes are executed after entity nodes, and risk nodes are executed after the rule nodes that trigger them. Import the entity-level control modules corresponding to the entity nodes from the pre-generated control module library, and import the node execution functions corresponding to the rule nodes and risk nodes from the node execution function library; Based on the hierarchical execution order, the imported entity-level control modules are dynamically bound to the node execution functions, and assembled into an executable inference program for the target entity node based on the pre-generated global control module framework. The inference program is executed to generate a result output interface, which formats the inference results into structured output.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by the processor of the electronic device, causes the electronic device to perform the method described in any one of claims 1 to 6.

Images