A knowledge ontology-based industry and finance data processing method and system

Abstract

The application relates to the technical field of data processing, and provides a business and financial data processing method and system based on a knowledge ontology, which comprises the following steps: performing intention recognition and entity extraction on a received business and financial data processing request according to a business domain, and determining a target business domain and a target entity; based on a business relationship, pulling out an associated subgraph with the target entity as a starting point, and matching a corresponding rule set and an index set according to the object type of a business object in the associated subgraph; assembling the object attributes of the associated subgraph, the intermediate values of the index set and the context of the rule set into a decision context, generating a dynamic tool execution plan based on the decision context and performing controlled execution to obtain a decision result; and rendering the decision result based on an output template corresponding to the target business domain, and generating a structured report. The application realizes unified business and financial semantics, dynamic reuse of rules and full-link traceability of decision-making.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to a business and financial data processing method and system based on knowledge ontology. Background Technology

[0002] Currently, in the field of integrated business and financial data processing, there is a common reliance on distributed business systems. Data is extracted and stored in data warehouses using ETL tools, and then fixed reports or simple models are overlaid on top to achieve query functions. However, existing solutions only support returning static data results based on preset reports matched with keywords, lacking semantic understanding capabilities, unable to dynamically associate multi-source heterogeneous data, and with rules and business logic hard-coded in the code, making it difficult to adapt to rapidly changing business needs.

[0003] Existing business and finance data processing solutions suffer from defects such as semantic fragmentation, rigid rules, black boxes in decision-making, and isolated scenarios. Inconsistent definitions of business terms across different systems can easily lead to contradictory data results; rule changes require code modifications, hindering rapid responses to policy adjustments; outputting results without tracing the basis for decisions poses audit and compliance risks; and data isolation across scenarios such as expenses, contracts, and budgets prevents cross-domain correlation analysis, severely restricting the depth and efficiency of business and finance integration. Summary of the Invention

[0004] The purpose of this application is to provide a business and financial data processing method and system based on knowledge ontology, so as to achieve the technical effects of unified business and financial semantics, dynamic reuse of rules, and traceability of the entire decision-making chain.

[0005] Firstly, a business data processing method based on a knowledge ontology is provided. The knowledge ontology includes a business domain as an intent anchor, business objects as data carriers, and business relationships as the basis for subgraph retrieval. This method may include: For the received business data processing request, perform intent recognition and entity extraction according to the business domain to determine the target business domain and target entity; Based on the business relationship, a related subgraph is pulled out starting from the target entity, and the corresponding rule set and indicator set are matched according to the object type of the business object in the related subgraph. The object attributes of the associated subgraph, the median value of the indicator set, and the context of the rule set are assembled into a decision context. A dynamic tool execution plan is generated based on the decision context and executed in a controlled manner to obtain the decision result. Based on the output template corresponding to the target business domain, the decision result is rendered to generate a structured report.

[0006] In one possible implementation, the business domain is configured with core keywords; For the received business data processing request, intent recognition and entity extraction are performed according to the business domain to determine the target business domain and target entity, including: The text of the business and financial data processing request is matched with the core keywords, and the business domain that is successfully matched is determined as the target business domain; Extract entity information from the business and financial data processing request to obtain the target entity.

[0007] In one possible implementation, the business relationship is configured with cardinality and / or expansion depth; Based on the aforementioned business relationship, a related subgraph is extracted starting from the target entity, including: Starting with the business object corresponding to the target entity as the starting node, the associated business objects are traversed along the direction of the business relationship according to the cardinality and / or expansion depth of the business relationship to obtain the association subgraph.

[0008] In one possible implementation, the rule set includes risk levels and associated skills; Matching the corresponding rule set and indicator set based on the object type of the business object in the associated subgraph includes: Identify the object type of each business object in the associated subgraph, and match and inject the corresponding rule set and indicator set according to the object type; wherein, the rule set judges the object attributes based on the risk level and associated skills.

[0009] In one possible implementation, the dynamic tool execution plan includes an ordered arrangement of data query tools, rule execution tools, and indicator calculation tools; The process of generating a dynamic tool execution plan based on the decision context and executing it in a controlled manner to obtain decision results includes: The planner generates the dynamic tool execution plan based on the decision context, and the dynamic tool execution plan defines the execution order of the data query tool, rule execution tool, and indicator calculation tool; The intelligent agent, in a controlled manner, invokes the data query tool, rule execution tool, and indicator calculation tool according to the execution order to obtain the decision result.

[0010] In one possible implementation, the intent recognition and entity extraction are achieved through a large language model or a natural language processing model.

[0011] In one possible implementation, the decision result is rendered based on the output template corresponding to the target business domain to generate a structured report, including: Based on the intent type determined by the intent recognition or the target business domain, select the corresponding output template; The indicator variables, rule result sets, and graph trajectories from the decision results are filled into the output template to generate the structured report.

[0012] In one possible implementation, during the process of extracting the associated subgraph based on the business relationship and starting from the target entity, the method further includes: Maintain the set of visited nodes; When traversing to a visited business object node, terminate the continued expansion of the current path to avoid forming circular references during the subgraph retrieval process; When the number of nodes in the associated subgraph exceeds a preset node count threshold, pruning is performed according to the priority of business relationships, retaining the highest priority relationship paths.

[0013] Secondly, a business and financial data processing system based on a knowledge ontology is provided. The knowledge ontology includes a business domain as an intent anchor, business objects as data carriers, and business relationships as the basis for subgraph retrieval. The system includes: The intent recognition module is configured to perform intent recognition and entity extraction according to the business domain for the received business data processing request, and to determine the target business domain and target entity. The subgraph retrieval module is configured to retrieve associated subgraphs based on the business relationship, starting from the target entity; The rule matching module is configured to match the corresponding rule set and indicator set based on the object type of the business object in the associated subgraph; The decision execution module is configured to assemble the object attributes of the associated subgraph, the median value of the indicator set, and the context of the rule set into a decision context, generate a dynamic tool execution plan based on the decision context, and execute it in a controlled manner to obtain the decision result; The output rendering module is configured to render the decision results based on the output template corresponding to the target business domain, and generate a structured report.

[0014] Thirdly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when executed by a processor, the computer program implements any of the steps of the method described in the first aspect above.

[0015] This application constructs a knowledge ontology encompassing business domains, business objects, and business relationships. Using business domains as anchors for intent recognition and business relationships as the basis for subgraph retrieval, the system accurately understands the business intent behind natural language requests and dynamically retrieves related data. This eliminates entity definition conflicts between different systems and achieves unified business and financial semantics. By binding rule sets and indicator sets to business object attributes, rules are automatically matched and injected based on object type after subgraph retrieval. This allows rule changes to be reused across scenarios without code refactoring, significantly improving the flexibility and responsiveness of rule configuration. By assembling decision contexts and generating dynamic tool execution plans, which are then executed under agent control, this application achieves end-to-end dynamic orchestration from data querying and indicator calculation to rule verification. It not only supports natural language input to replace manual report retrieval, significantly reducing decision-making time, but also ensures traceability of the entire execution trajectory, meeting audit compliance requirements. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a knowledge ontology-based business and financial data processing method provided in this application embodiment; Figure 2 This is a schematic diagram of the structure of a business and financial data processing system based on knowledge ontology, provided in an embodiment of this application. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application. Unless otherwise defined, the technical or scientific terms used in this application should have the ordinary meaning understood by those skilled in the art. The terms "first," "second," and similar terms used in this application do not indicate any order, quantity, or importance, but are only used to distinguish different components. The terms "comprising" or "including," etc., mean that the element or object preceding the word covers the element or object listed after the word and its equivalents, but does not exclude other elements or objects. The terms "connection," "coupled," or "linked," etc., are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect.

[0019] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0020] The knowledge ontology-based business and financial data processing method provided in this application dynamically couples the various stages of business and financial data processing by constructing a knowledge ontology that includes business domains, business objects, and business relationships, thereby achieving automated generation from natural language requests to structured decision reports.

[0021] A knowledge ontology can include: the business domain as the anchor point of intent, the business object as the data carrier, and the business relationship as the basis for subgraph retrieval.

[0022] (1) A business domain is a top-level organizational unit that defines a set of objects, rules, indicators and relationships within a certain business scope. It is used to determine the processing scope when a processing request is received. Specifically, a business domain is the anchor point for intent recognition: when a user mentions keywords such as "reimbursement", "contract", "budget" and "payment", the system first matches the corresponding domain and then carries out subsequent processing within that domain.

[0023] In one example, the business domain management interface provides functions for creating, editing, viewing, and deleting business domains. When creating a new business domain, the system administrator fills in the domain name (e.g., "Expense Reimbursement Domain"), domain identifier (e.g., "Expense_Domain"), configures core keywords (separated by commas, such as "reimbursement, invoice, expense, travel, hospitality"), selects or checks the included object types, bound rules and bound metrics, fills in a description, and saves the settings, setting the status to "activated". Only activated business domains can participate in intent matching. Examples of business domains are shown in Table 1.

[0024] Table 1

[0025] (2) Business objects are the typed representation of real business entities in the system, including object type and core attribute fields, and serve as the data carrier of dynamic context; business relationships define the connection method between different business objects and are the core basis for dynamically pulling related subgraphs.

[0026] In one example, the business object management interface supports filtering by domain (All / Expense Reimbursement / Contract Management / Budget Management / Customer Receivables) and searching by object name. When creating a new business object, the system administrator selects the business domain, fills in the object name and object identifier, maintains a list of core attribute fields (separated by commas or added one by one via a form), configures associated objects (for subgraph expansion), and after saving, can add edges to the object in "Business Relationships". Examples of business objects are shown in Table 2.

[0027] Table 2

[0028] (3) Business relationship definition defines the connection relationship between business objects, and is configured with cardinality (one-to-one / one-to-many / many-to-one), expansion depth and bidirectional traversal switch.

[0029] In one example, when creating a new business relationship, the system administrator selects the source object, relationship type, target object, sets the cardinality (one-to-one / one-to-many / many-to-one), and configures the expansion depth and bidirectional traversal switch. After saving, the "subgraph path" in the system chain will be able to reference this relationship chain. Examples of business relationships are shown in Table 3.

[0030] Table 3

[0031] Figure 1 This is a flowchart illustrating a knowledge ontology-based business and financial data processing method provided in an embodiment of this application. Figure 1 As shown, the method may include: Step S110: For the received business data processing request, perform intent recognition and entity extraction according to the business domain to determine the target business domain and target entity.

[0032] When the system receives a user's request for business and financial data processing, it parses the request text using natural language processing (NLP). The system compares the parsed text features with the configuration information of each business domain in the knowledge ontology to identify the target business domain to which the request belongs. Simultaneously, it extracts key entity information from the request text, such as object names, IDs, or specific attribute values, as target entities for subsequent processing. By using the business domain as an intent anchor, the system can accurately understand the business intent behind the natural language request, avoiding semantic fragmentation caused by conflicts in entity definitions between different systems.

[0033] Step S120: Based on business relationships, pull out the associated subgraph starting from the target entity, and match the corresponding rule set and indicator set according to the object type of the business object in the associated subgraph.

[0034] After identifying the target entity, the system takes the business object corresponding to the target entity as the starting node, traverses other associated business objects along the business relationship direction defined in the knowledge ontology, and thus pulls out an associated subgraph containing multiple associated nodes and edges.

[0035] During the process of retrieving the related subgraph, the system identifies the object type of each business object in the subgraph and automatically matches and injects the corresponding rule set and indicator set according to the object type. The rule set contains the judgment logic for that type of business object, while the indicator set contains the indicator definitions used for quantitative evaluation.

[0036] This implementation method achieves decoupling of rules and data by dynamically matching rules and metrics based on object type. This allows rule changes to be reused across scenarios without refactoring the code, greatly improving the flexibility of rule configuration.

[0037] Step S130: Assemble the object attributes of the associated subgraph, the median value of the indicator set, and the context of the rule set into a decision context. Generate a dynamic tool execution plan based on the decision context and execute it in a controlled manner to obtain the decision result.

[0038] The dynamic tool execution plan includes the orderly arrangement of data query tools, rule execution tools, and indicator calculation tools.

[0039] First, the specific attribute values ​​of each business object in the retrieved subgraph, the intermediate values ​​in the calculation process of the indicator set, and the contextual information required for the execution of the rule set are packaged and assembled into a unified decision context.

[0040] Subsequently, the system's planner generates a dynamic tool execution plan based on this decision context. This plan defines the execution order of data query tools, rule execution tools, and indicator calculation tools. For example, the plan might first orchestrate the data query tool to acquire underlying data, then orchestrate the indicator calculation tool for quantitative calculations, and finally orchestrate the rule execution tool for compliance verification based on the calculation results. The agent, following this execution order, controllably invokes various tools to ultimately obtain the decision result. The dynamic tool execution plan generated by the planner can be expressed in a structured JSON format, including the tool invocation sequence, input parameter mappings for each step, and expected output fields. This plan is passed to the agent's execution engine through an internal interface. The agent strictly follows the planned sequence and does not have the ability to autonomously modify the plan, ensuring the controllability and auditability of the execution process. When a step fails, the agent terminates subsequent steps and returns an error message, allowing the upper-level system to decide whether to re-trigger the planning process.

[0041] The above implementation method achieves controlled execution by assembling contexts and generating dynamic tool execution plans, realizing dynamic orchestration of the entire chain from data querying and indicator calculation to rule verification. The execution trajectory of the entire chain is traceable, which meets audit compliance requirements.

[0042] Step S140: Based on the output template corresponding to the target business domain, render the decision results and generate a structured report.

[0043] The system has pre-set output templates corresponding to each business domain or intent type. After obtaining the decision result, the system selects the corresponding output template according to the target business domain determined in step S110, fills the output template with data such as indicator variable values, rule verification result sets, and graph traversal trajectories from the decision result, and renders and generates a structured report. This structured report can use formats such as Markdown and includes risk summaries, indicator values, and improvement suggestions. By rendering the output using templates, the complex decision-making process is transformed into a highly readable analysis report, improving the interpretability and usability of the decision results.

[0044] In some embodiments, this embodiment provides a detailed description of the specific implementation mechanism of intent recognition and entity extraction in step S110. The business domain is configured with core keywords, such as reimbursement, invoice, and expense keywords.

[0045] For received business and financial data processing requests, intent identification and entity extraction are performed according to the business domain to determine the target business domain and target entity, including: The text of the business and financial data processing request is matched with core keywords, and the successfully matched business domain is identified as the target business domain. Entity information is extracted from the business and financial data processing request as the target entity. Intent recognition and entity extraction are achieved through a large language model or a natural language processing model.

[0046] Specifically, after receiving a natural language request from a user (such as analyzing Xu XX's expense reimbursement behavior pattern), the system invokes a pre-built large language model or natural language processing model to perform vectorized encoding and semantic parsing of the request text. The large language model can effectively handle non-standardized natural language expressions, such as colloquial descriptions or inputs containing typos. During parsing, the model compares the extracted text features with the core keywords pre-configured for each business domain in the knowledge ontology. For example, when the business domain is expense reimbursement, its configured core keywords might include reimbursement, invoice, expense, and travel. If the user's input request text contains these keywords, the business domain is identified as a candidate target business domain. For example, when the text contains keywords such as reimbursement, invoice, and expense, it matches to the expense reimbursement domain; when it contains contracts, agreements, and procurement, it matches to the contract management domain; when it contains budgets, expenditures, and execution rates, it matches to the budget management domain; and when it contains payments, receivables, and payment terms, it matches to the customer receivables domain. The successfully matched business domain is then identified as the target business domain.

[0047] Simultaneously, the model utilizes named entity recognition technology to extract specific entity information from the request text, such as employee names, expense reimbursement numbers, or contract numbers, as target entities for subsequent processing. For example, given the input "Analyze Xu XX's expense reimbursement behavior pattern," the system extracts the following entity information: the employee entity "Xu XX" and its employee number "E005." Through the combination of a large language model and core keyword matching, the system can accurately anchor business intent and extract key data carriers, providing a precise starting point for subsequent subgraph retrieval.

[0048] As another implementation, the business domain is configured with core keywords and matching weights for each keyword. Intent recognition and entity extraction are performed according to the business domain to determine the target business domain and target entities, which may further include: The semantic similarity or keyword hit rate between the text of the business data processing request and the core keywords of each business domain is calculated. The matching score of each business domain is calculated by combining the matching weight, and the business domain with the highest matching score is determined as the target business domain.

[0049] In practical applications, the natural language input by users often has diversity, such as synonyms, abbreviations or colloquial expressions. Simple exact string matching cannot effectively cope with this diversity and is prone to incorrect intention determination. Therefore, this embodiment introduces a fuzzy matching and weight calculation mechanism. The system not only performs exact matching, but also calculates the semantic similarity or keyword hit rate between the request text and the core keywords of each business domain. For example, if the word input by the user is "chai bu" (a colloquial abbreviated variation of business travel), although it is not completely consistent with the core keyword "business travel", it can be determined to be highly relevant through semantic similarity calculation. Then, the system comprehensively scores each business domain in combination with the preset matching weights of each keyword. The weight configuration can be set according to the business attention degree. For example, higher weights are assigned to words corresponding to high-frequency core business objects. By comprehensively calculating semantic similarity, hit rate and matching weight, the system can select the candidate business domain with the highest matching score as the final target business domain among multiple candidate business domains. This mechanism significantly improves the accuracy and robustness of intention recognition, avoids intention misjudgment caused by users' different expressions, and enhances the system's adaptability to the diversity of natural language.

[0050] Further, when the business-finance data processing request hits multiple business domains at the same time, a cross-domain joint intention is identified, and all the hit multiple business domains are determined as target business domains; extracting the associated subgraphs includes extracting associated subgraphs respectively with the target entities under each target business domain as starting points, and merging each associated subgraph to form a cross-domain joint subgraph.

[0051] With the deepening of enterprise business-finance integration, many complex decision-making scenarios often involve multiple business domains. For example, when a user inputs "analyze the impact of reimbursement on budget execution", the request hits both the expense reimbursement domain and the budget management domain. At this time, the system recognizes that this is a cross-domain joint intention, and determines both the expense reimbursement domain and the budget management domain as target business domains. In the subsequent extraction of associated subgraphs, the system extracts respective associated subgraphs respectively with target entities in the expense reimbursement domain (such as employees, reimbursement forms) and target entities in the budget management domain (such as departments, budgets) as starting points. Then, the system merges the two independently extracted subgraphs into a unified cross-domain joint subgraph through node merging or edge connection. This cross-domain joint subgraph breaks the decision-making boundary of a single business domain, enabling rule matching and indicator calculation to be performed based on comprehensive cross-domain data, realizing cross-domain joint analysis and comprehensive decision-making, and effectively solving the technical problems of isolated scenarios and inability to perform cross-domain correlation analysis in traditional solutions.

[0052] In some embodiments, this embodiment describes in detail the traversal control and pruning mechanism in the associated subgraph extraction process in step S120. Wherein, the business relationship is configured with cardinality and / or expansion depth.

[0053] Based on the business relationship, extracting the associated subgraph with the target entity as the starting point includes:[ Starting with the business object corresponding to the target entity as the starting node, traverse the associated business objects along the direction of the business relationship according to the cardinality and / or expansion depth of the business relationship to obtain the association subgraph.

[0054] Specifically, cardinality defines the quantity constraint of target objects in business relationships, such as one-to-one, one-to-many, or many-to-one. Unfold depth defines the number of levels traversed outward from the starting node. When retrieving the associated subgraph, the system uses a graph traversal algorithm, enqueuing the business object corresponding to the target entity as the starting node. In each level of traversal, the system reads the business relationships associated with the current node, determines the number of nodes to be expanded at the next level based on the cardinality of that business relationship, and decides whether to continue traversing downwards based on the unfold depth. Through the dual control of cardinality and unfold depth, the system can flexibly define the size and boundaries of the subgraph, avoiding resource waste caused by fetching irrelevant data.

[0055] For example, if the business relationship is that an employee submits an expense report, the base is one-to-many, and the expansion depth is 2, then the system starts from the employee node, traverses all expense report nodes submitted by that employee, and stops expanding to deeper levels such as expense details when it reaches depth 2.

[0056] For example, when the target entity is "Xu XX (Employee E005)", the starting node is the employee object E005. If the business relationship is relationship REL001 (Employee → Submit → Expense Report, cardinality is "one-to-many", expansion depth is 2), the system starts from the employee node E005, traverses along the "Submit" relationship to all the expense report nodes it has submitted (EXP001, EXP002, etc.), with a depth of 1; then it traverses along the "Include" relationship (REL002) from each expense report node to the expense details node, with a depth of 2. After reaching the configured maximum expansion depth, the system stops expanding the path.

[0057] Finally, the system combines all traversed business object nodes and their relationship edges into the association subgraph. The association subgraph contains all relevant business objects and their relationships, centered on the target entity and expanded according to business relationships.

[0058] Furthermore, the process of extracting related subgraphs based on business relationships, starting from the target entity, may also include: Maintain a set of visited nodes; when traversing to a visited business object node, terminate the continued expansion of the current path to avoid circular references during subgraph retrieval; when the number of nodes in the associated subgraph exceeds a preset node count threshold, prune according to the priority of business relationships and retain the highest priority relationship paths.

[0059] In real-world business knowledge ontology, business objects often have complex network relationships, even bidirectional references or closed-loop paths. For example, an employee belongs to a department, the department manages the budget, and the budget may be inversely related to the employee's expense reports. Without an anti-loop mechanism, the graph traversal algorithm will get stuck in an infinite loop, leading to system crashes or resource exhaustion. Therefore, this embodiment maintains a set of visited nodes during the traversal process. Whenever the system accesses a business object node, it first checks whether the node already exists in the set of visited nodes. If it does, it means that the current path has formed a circular reference, and the system immediately terminates the continued expansion of the current path, thus ensuring the termination of the subgraph retrieval process. In addition, when the number of nodes in the associated subgraph exceeds a preset node threshold, the system triggers a priority pruning strategy. The priority of business relationships can be preset according to the strength of business associations or scenario configuration; for example, core business relationships have a higher priority than peripheral business relationships. The system prunes peripheral paths according to priority, retaining the highest priority relationship paths. By employing a loop detection and pruning mechanism, the system prevents the subgraph from expanding indefinitely or becoming too large due to bidirectional or multidirectional associations in business relationships. This ensures the termination and execution efficiency of the subgraph retrieval process, thereby guaranteeing the stability of the system under highly complex ontology structures.

[0060] In a preferred embodiment, when the target entity contains multiple business objects, subgraphs can be pulled from each business object as the starting node, and the multiple pulled subgraphs can be merged into a unified associated subgraph.

[0061] Specifically, when a user's business and financial data processing request mentions multiple entities, such as querying the expense reimbursement comparison of two employees, the system identifies multiple business objects as target entities. In this case, the system uses these two employee objects as starting nodes and executes the subgraph retrieval logic in parallel or sequentially, resulting in two independent subgraphs. Subsequently, the system merges these two independent subgraphs into a unified associated subgraph through node merging or edge connection, enabling subsequent rule matching and indicator calculation to perform cross-entity comparative analysis within the same context space.

[0062] In another preferred embodiment, the business relationship can be configured with a bidirectional traversal switch; When the bidirectional traversal switch is enabled, traversal is allowed in the reverse direction of the business relationship. For example, for the relationship "employee → submit → expense report", the reverse traversal is "expense report ← submit ← employee", that is, traversing backward from the expense report node to the employee node that submitted the expense report.

[0063] When the bidirectional traversal switch is off, traversal is performed only in the forward direction of the business relationship.

[0064] Traditional graph traversal typically only supports forward expansion from the source node to the target node. However, in business and financial data processing, different analytical perspectives require flexible traversal directions. For example, a business relationship is defined as an employee submitting an expense report, with the forward direction being from the employee to the expense report. When analyzing employee expense reporting behavior, forward traversal is sufficient. However, when it is necessary to trace back to the responsible employee from an abnormal expense report, if only forward traversal is supported, a full scan is required, which is extremely inefficient. Therefore, this embodiment introduces a bidirectional traversal switch. When the switch is on, the system allows traversal in the reverse direction of the business relationship, i.e., tracing back from the expense report to the employee; when the switch is off, the system only traverses in the forward direction. By controlling the direction of subgraph retrieval through the bidirectional traversal switch, both forward expansion from the main object to related objects and reverse traversal from related objects to the main object are supported, meeting the query needs of different analytical perspectives and solving the technical problem of missing perspectives.

[0065] Specifically, the value of the expansion depth is dynamically determined based on the target business domain and / or the object type of the target entity; different business domains and / or different object types correspond to different expansion depth configurations.

[0066] Specifically, different business domains or object types involve varying levels of complexity and business focus. For example, in the expense reimbursement domain, auditing expense detail objects typically requires in-depth information down to the invoice level, thus allowing for a depth configuration of 3 levels or more. However, for budget objects in the budget management domain, the relationship paths are relatively simple; excessive depth not only hinders decision-making but also increases system overhead. Therefore, the system dynamically reads the corresponding depth configuration value based on the target business domain and / or the object type of the target entity. This mechanism enables differentiated configuration of depth: core business domains or key object types allow deeper subgraph expansion to obtain more comprehensive relationship information, while non-core domains or secondary object types limit the depth to ensure query efficiency, balancing decision quality and system performance.

[0067] In some embodiments, this embodiment provides a detailed description of the dynamic matching and judgment logic of the rule set and the specific execution mechanism of the dynamic tool execution plan involved above. The rule set may include risk levels and associated skills.

[0068] After retrieving the associated subgraph, the corresponding rule set and indicator set are matched according to the object type of the business objects in the associated subgraph, including: First, the system identifies the object type of each business object in the associated subgraph. It iterates through all nodes in the retrieved associated subgraph and reads the object type identifier of each business object. This object type identifier is a type label configured for each business object during the ontology modeling phase, such as employee, expense report, expense details, merchant, contract, budget, etc. Different types of business objects have different attribute fields, and are subject to different rules and metrics accordingly.

[0069] Secondly, the system matches and injects corresponding rule sets and indicator sets according to the identified object types. Using the object type as the query key, the system retrieves all rules bound to that object type from the rule base and injects the retrieved rule sets into the current decision context. For example, when a node containing expense details is identified in the associated subgraph, the system automatically matches and injects rules related to expense details, such as integer invoice detection rules and abnormal amount detection rules; when an employee type node is identified, the system automatically matches and injects employee-related rules, such as rules for detecting the frequency of the same employee's purchases at the same merchant within 30 days and rules for comprehensive expense reimbursement behavior risk scoring; when a budget type node is identified, the system automatically matches and injects budget execution rate warning rules. Different object types correspond to different rule combinations, and the same object type can correspond to different rule combinations in different business domains—for example, employee objects in the expense reimbursement domain and employee objects in the human resources domain are bound to different rule sets.

[0070] Finally, the rule set dynamically assesses object attributes based on risk level and associated skills. Each rule is defined in the rule base as structured data, containing the following core fields: Target type: Specifies which type of business object this rule applies to; Triggering condition expression: Defines the triggering condition of the rule in the form of an executable logical expression, wherein the expression references the specific attribute of the object being acted upon as a variable; Risk level: Indicates the risk level corresponding to when the rule is triggered, including three levels: high risk, medium risk, and low risk; Associated skills: Indicates the checks or subsequent actions that need to be performed when the rule is triggered.

[0071] In one example, five rule examples can be shown in Table 4.

[0072] Table 4

[0073] For each rule, the system reads the triggering conditions (described in natural language or expressions), risk level (high risk / medium risk / low risk), and associated skills (executable checks) configured for that rule.

[0074] In practice, the system substitutes the specific attribute values ​​of the actual business objects in the current associated subgraph into the trigger condition expression, replacing the variable placeholders in the expression to form an executable conditional judgment statement. This statement is then executed to obtain a Boolean result of true or false. If the judgment result is true, the rule is triggered, the system outputs the risk level according to the risk level configured for the rule, and executes the associated skills configured for the rule. If the judgment result is false, the rule is not triggered, the system skips the rule, and continues to execute the next rule.

[0075] By defining the triggering conditions, risk levels, and associated skills of rules in the rule base in the form of structured data, the system automatically matches and injects the corresponding rule set according to the object type at runtime, and dynamically judges by substituting the object attribute values ​​into the triggering condition expression, thus achieving decoupling between the rule logic and the system code.

[0076] In some embodiments, a dynamic tool execution plan may include an ordered arrangement of data query tools, rule execution tools, and indicator calculation tools. The dynamic tool execution plan is generated based on the decision context and executed in a controlled manner to obtain decision results, including: The planner generates dynamic tool execution plans based on the decision context; the dynamic tool execution plans define the execution order of data query tools, rule execution tools, and indicator calculation tools. Specifically, after receiving the decision context, the planner identifies the type of operation to be performed (data query, rule execution, metric calculation), determines the input dependencies of each operation, and generates an ordered execution plan. This plan defines the execution order of various tools. For example, taking a cost audit scenario as an example, the execution plan is as follows: Obtain employee information → Obtain expense report list → Calculate M001 (total expense report amount) → Calculate M002 (number of integer invoices) → Calculate M010 (percentage of integer invoices) → Calculate M011 (total number of expense reports) → Check R001 (integer invoice detection) → Check R002 (frequent same merchant) → Check R003 (risk score for expense report behavior) → Generate conclusion.

[0077] Each step in the execution plan specifies the name of the tool to be invoked, the input parameters, and the expected output. The dynamic tool execution plan includes an ordered arrangement of data query tools, rule execution tools, and indicator calculation tools.

[0078] In one example, the tool layer pre-built tool examples can be shown in Table 5.

[0079] Table 5

[0080] Subsequently, the intelligent agent, in a controlled manner, invokes data query tools, rule execution tools, and indicator calculation tools according to the execution order to obtain the decision results.

[0081] Specifically, the intelligent agent is the core execution component of the DAP decision-making intelligent agent platform, responsible for calling the various tools in the tool layer according to the execution plan generated by the planner. The execution process is as follows: The first step is data query. The intelligent agent first calls the data query tool to obtain the required raw data from the business data source. For example, it calls the "Get Employee Information" tool, enters the employee number "E005", and obtains the basic information of employee Xu XX; it calls the "Get Expense Reimbursement List" tool, enters the employee number "E005" and the start and end dates, and obtains all expense reimbursement data for that employee.

[0082] The second step is indicator calculation. After acquiring the raw data, the agent calls the indicator calculation tool to calculate various indicators. For example, it calls the "Calculate Total Reimbursement Amount" tool, inputs the list of reimbursement forms and the time range, and calculates M001 (total reimbursement amount); it calls the "Calculate Integer Invoice Quantity" tool, inputs the expense details array, and calculates M002 (integer invoice quantity).

[0083] The third step is rule execution. After completing the indicator calculation, the agent calls the rule execution tool to verify the rules. For example, it calls the "Integer Invoice Detection Tool," inputs an array of expense details, checks for the existence of integer invoices, and outputs a list of integer invoices and their quantities; it calls the "Merchant Frequency Statistics Tool," inputs an array of expense details, and counts the consumption frequency of each merchant.

[0084] The fourth step is to generate decision results. The agent summarizes the execution results of all tools to form decision results. Decision results may include: the calculated values ​​of each indicator, the trigger status of each rule (triggered / not triggered), the risk level (high risk / medium risk / low risk / no risk), and decision recommendations.

[0085] In a preferred embodiment, the indicator set includes basic indicators and derived indicators, and the calculation of derived indicators depends on the basic indicators. After matching the corresponding indicator set, an indicator dependency graph is constructed, and the calculation is performed layer by layer from the bottom basic indicators upwards according to the indicator dependency graph, calculating only the indicators referenced by the rule set or required by the output template.

[0086] In practical business and financial data processing, indicator sets often contain a large number of indicator definitions, but not all indicators are used in every decision. Performing full calculations on all matched indicators would result in a huge waste of computing power and severely impact system response speed. Therefore, this embodiment introduces an indicator dependency graph and an on-demand calculation mechanism. After matching the corresponding indicator set, the system first parses the hierarchical dependencies between basic and derived indicators, constructing a directed acyclic indicator dependency graph. Basic indicators are located at the bottom layer of the dependency graph, while derived indicators are located at the top layer and point to the basic indicators they depend on.

[0087] During the calculation phase, the system reverse-engineers which metrics the current rule set references and which metric variables the output template requires, marking only these referenced or required metrics as pending calculation. Subsequently, the system calculates layer by layer from the bottom-level basic metrics upwards according to the metric dependency graph, only calculating the metrics marked as pending calculation and their dependent bottom-level metrics. For example, if a decision only requires the derived metric budget execution rate, and this derived metric depends on two basic metrics—monthly actual expenditure and monthly budget amount—the system only calculates these three metrics, ignoring other irrelevant metrics in the metric set. This on-demand calculation mechanism avoids calculating all matched metrics, significantly reducing computational overhead, improving decision response speed, and effectively ensuring the system's processing performance in high-concurrency scenarios.

[0088] In one example, the indicator system can adopt a three-tier architecture, including: basic indicators, derived indicators, and composite indicators. An example of an indicator set can be shown in Table 6.

[0089] Table 6

[0090] The system matches the corresponding set of indicators from the indicator system according to the identified object type. For example, for employee objects in the expense reimbursement domain, the matched set of indicators includes: M001 (total reimbursement amount), M002 (number of integer invoices), M010 (percentage of integer invoices), M011 (total number of reimbursement forms), etc.

[0091] In some embodiments, this embodiment provides a detailed description of the rendering mechanism of the output template and the report version management in step S140.

[0092] Based on the output template corresponding to the target business domain, the decision results are rendered to generate a structured report, including: Based on the intent type or target business domain determined by intent recognition, select the corresponding output template; fill the indicator variables, rule result set and graph trajectory in the decision results into the output template to generate a structured report.

[0093] Specifically, the system has a pre-set template mapping table, which records the correspondence between intent types or business domains and output template identifiers.

[0094] After the decision results are generated, the system first reads the intent type or target business domain identifier determined in the intent recognition stage, queries the template mapping table for a match, and selects the corresponding output template. The output template defines the report's structural skeleton and placeholders, such as the risk summary area, the indicator value table area, and the decision tracing link area. Subsequently, the system parses the decision results, extracting indicator variables and their calculated values, the rule verification result set (including the triggered rule number, risk level, and associated skill status), and the graph traversal trajectory (i.e., the sequence of nodes and edge paths traversed during subgraph retrieval). The system accurately fills these extracted data elements into the corresponding placeholders in the output template and renders a structured report. This report can be in Markdown or other formats, and not only includes quantitative values ​​but also fully preserves the decision-making reasoning path, making the final output highly interpretable and readable.

[0095] Furthermore, after generating the structured report, the process also includes: comparing the structured report with historical structured reports of the same target entity or the same target business domain to generate a difference comparison report, which includes the trend of indicator changes, changes in risk level, and changes in rule hit rate.

[0096] In actual business and financial management, business conditions and risk situations evolve dynamically. A single structured report can only reflect the current state, and managers often need to pay attention to trend changes. Traditionally, auditors or finance personnel need to retrieve multiple historical reports and manually check indicator values ​​and risk levels item by item, which is not only time-consuming and laborious but also prone to omissions due to fatigue. Therefore, this embodiment introduces a report version management and difference comparison mechanism. After generating the current structured report, the system retrieves the most recent historical structured report from the version database using the target entity identifier or target business domain identifier as the primary key. The system calculates the difference between the corresponding indicator variables in the current report and the historical reports to identify indicator trends (such as an increase or decrease in budget execution rate). Simultaneously, it compares the rule result sets in the two reports to identify newly hit risk rules, resolved risk rules, and rule items whose risk levels have shifted. The system assembles this difference information according to a preset difference template to generate a difference comparison report. For example, the difference comparison report can highlight that a certain expense indicator's month-on-month growth exceeded expectations and indicate that a new high-risk rule has been hit. This mechanism eliminates the pain point of manually comparing historical data item by item, helping users quickly identify trends in business operations or risk conditions, and significantly improving decision-making efficiency and audit response speed.

[0097] like Figure 2As shown, this embodiment provides a business and financial data processing system based on a knowledge ontology. Through the collaborative operation of various virtual modules, the system achieves fully automated processing of intent recognition, subgraph retrieval, dynamic rule matching, and controlled execution based on the structured definition of the ontology model. This ensures semantic consistency and decision interpretability in business and financial data processing at the system level. The system includes an intent recognition module 210, a subgraph retrieval module 220, a rule matching module 230, a decision execution module 240, and an output rendering module 250.

[0098] The intent recognition module 210 is configured to perform intent recognition and entity extraction according to the business domain for the received business data processing request, and to determine the target business domain and target entity.

[0099] The intent recognition module, serving as the system's entry point, receives natural language requests input by users through their terminal devices. This module integrates interfaces for calling large language models or natural language processing models, enabling vectorized encoding and semantic parsing of the request text. The intent recognition module compares the parsed text features with the configuration information of each business domain in the knowledge ontology to identify the target business domain to which the request belongs, and extracts key entity information from the request text as the target entity. By using the business domain as the intent anchor, the intent recognition module accurately understands the business intent behind the natural language request, avoiding semantic fragmentation caused by conflicts in entity definitions between different systems. The intent recognition module outputs the determined target business domain identifier and target entity information to the subgraph retrieval module.

[0100] The subgraph retrieval module 220 is configured to retrieve associated subgraphs based on business relationships, starting from the target entity.

[0101] The subgraph retrieval module, upon receiving the target entity information, uses the business object corresponding to that target entity as the starting node and traverses other associated business objects along the business relationship directions defined in the knowledge ontology, thereby retrieving an associated subgraph containing multiple associated nodes and edges. During the retrieval process, the subgraph retrieval module controls the scale of traversal based on the cardinality and expansion depth of the business relationships, maintains a set of visited nodes to avoid circular references, and performs priority pruning when the number of nodes exceeds a threshold. The subgraph retrieval module outputs the retrieved associated subgraph data structure to the rule matching module.

[0102] The rule matching module 230 is configured to match the corresponding rule set and indicator set based on the object type of the business object in the associated subgraph.

[0103] The rule matching module traverses all nodes in the association subgraph, reads the object type identifier of each business object, and automatically matches and injects the corresponding rule set and indicator set from the rule library and indicator library according to the object type. The rule set contains the judgment logic for this type of business object, while the indicator set contains the indicator definition for quantitative evaluation. By dynamically matching rules and indicators based on object type, the rule matching module decouples rules from data, enabling rule changes to be reused across scenarios without code refactoring. The rule matching module outputs the association subgraph context, which includes object attributes, the matched rule set, and the indicator set, to the decision execution module.

[0104] The decision execution module 240 is configured to assemble the object attributes of the associated subgraph, the intermediate values ​​of the indicator set, and the context of the rule set into a decision context, generate a dynamic tool execution plan based on the decision context, and execute it in a controlled manner to obtain the decision result.

[0105] The decision execution module is the core engine of the system, responsible for transforming static rules and metrics into dynamic execution processes. It packages the specific attribute values ​​of each business object in the retrieved relational subgraph, intermediate values ​​during metric calculation, and the contextual information required for rule set execution into a unified decision context. Subsequently, based on this decision context, the module generates a dynamic tool execution plan. This plan defines the execution order of data query tools, rule execution tools, and metric calculation tools, and controls the invocation of various tools to ultimately obtain the decision result. The decision execution module then outputs the decision result to the output rendering module.

[0106] The output rendering module 250 is configured to render the decision results based on the output template corresponding to the target business domain, and generate a structured report.

[0107] The output rendering module has pre-set output templates corresponding to each business domain or intent type. After obtaining the decision results, the output rendering module selects the corresponding output template based on the target business domain determined by the intent recognition module, and fills in the output template with data such as indicator variable values, rule verification result sets, and graph traversal trajectories from the decision results, generating a structured report. This structured report can use formats such as Markdown and includes risk summaries, indicator values, and improvement suggestions, improving the interpretability and usability of the decision results.

[0108] The functions of each functional unit in the knowledge ontology-based business and financial data processing system provided in the above embodiments of this application can be implemented through the above methods and steps. Therefore, the specific working process and beneficial effects of each unit in the knowledge ontology-based business and financial data processing system provided in the embodiments of this application will not be repeated here.

[0109] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores instructions that, when executed on a computer, cause the computer to perform any of the knowledge ontology-based business data processing methods described in the above embodiments.

[0110] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the knowledge ontology-based business data processing methods described in the above embodiments.

[0111] Those skilled in the art will understand that the embodiments in this application can be provided as methods, systems, or computer program products. Therefore, the embodiments in this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments in this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0112] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0113] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0114] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0115] Although preferred embodiments have been described in this application, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of this application.

[0116] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims in this application and their equivalents, then this application also intends to include these modifications and variations.

Claims

1. A business and financial data processing method based on knowledge ontology, characterized in that, The knowledge ontology includes business domains as intent anchors, business objects as data carriers, and business relationships as the basis for subgraph retrieval. The method includes: For the received business data processing request, perform intent recognition and entity extraction according to the business domain to determine the target business domain and target entity; Based on the business relationship, a related subgraph is pulled out starting from the target entity, and the corresponding rule set and indicator set are matched according to the object type of the business object in the related subgraph. The object attributes of the associated subgraph, the median value of the indicator set, and the context of the rule set are assembled into a decision context. A dynamic tool execution plan is generated based on the decision context and executed in a controlled manner to obtain the decision result. Based on the output template corresponding to the target business domain, the decision result is rendered to generate a structured report.

2. The method according to claim 1, characterized in that, The business domain is configured with core keywords; For the received business data processing request, intent recognition and entity extraction are performed according to the business domain to determine the target business domain and target entity, including: The text of the business and financial data processing request is matched with the core keywords, and the business domain that is successfully matched is determined as the target business domain; Extract entity information from the business and financial data processing request to obtain the target entity.

3. The method according to claim 2, characterized in that, The business relationship is configured with a cardinality and / or expansion depth; Based on the aforementioned business relationship, a related subgraph is extracted starting from the target entity, including: Starting with the business object corresponding to the target entity as the starting node, the associated business objects are traversed along the direction of the business relationship according to the cardinality and / or expansion depth of the business relationship to obtain the association subgraph.

4. The method according to claim 3, characterized in that, The rule set includes risk levels and associated skills; Matching the corresponding rule set and indicator set based on the object type of the business object in the associated subgraph includes: Identify the object type of each business object in the associated subgraph, and match and inject the corresponding rule set and indicator set according to the object type; wherein, the rule set judges the object attributes based on the risk level and associated skills.

5. The method according to claim 4, characterized in that, The dynamic tool execution plan includes an orderly arrangement of data query tools, rule execution tools, and indicator calculation tools; The process of generating a dynamic tool execution plan based on the decision context and executing it in a controlled manner to obtain decision results includes: The planner generates the dynamic tool execution plan based on the decision context, and the dynamic tool execution plan defines the execution order of the data query tool, rule execution tool, and indicator calculation tool; The intelligent agent, in a controlled manner, invokes the data query tool, rule execution tool, and indicator calculation tool according to the execution order to obtain the decision result.

6. The method according to claim 1, characterized in that, The intent recognition and entity extraction are achieved through a large language model or a natural language processing model.

7. The method according to claim 1, characterized in that, Based on the output template corresponding to the target business domain, the decision result is rendered to generate a structured report, including: Based on the intent type determined by the intent recognition or the target business domain, select the corresponding output template; The indicator variables, rule result sets, and graph trajectories from the decision results are filled into the output template to generate the structured report.

8. The method according to claim 1, characterized in that, Based on the aforementioned business relationship, in the process of extracting the associated subgraph starting from the target entity, the method further includes: Maintain the set of visited nodes; When traversing to a visited business object node, terminate the continued expansion of the current path to avoid forming circular references during the subgraph retrieval process; When the number of nodes in the associated subgraph exceeds a preset node count threshold, pruning is performed according to the priority of business relationships, retaining the highest priority relationship paths.

9. A business and financial data processing system based on knowledge ontology, characterized in that, The knowledge ontology includes business domains as intent anchors, business objects as data carriers, and business relationships as the basis for subgraph retrieval. The system includes: The intent recognition module is configured to perform intent recognition and entity extraction according to the business domain for the received business data processing request, and to determine the target business domain and target entity. The subgraph retrieval module is configured to retrieve associated subgraphs based on the business relationship, starting from the target entity; The rule matching module is configured to match the corresponding rule set and indicator set based on the object type of the business object in the associated subgraph; The decision execution module is configured to assemble the object attributes of the associated subgraph, the median value of the indicator set, and the context of the rule set into a decision context, generate a dynamic tool execution plan based on the decision context, and execute it in a controlled manner to obtain the decision result; The output rendering module is configured to render the decision results based on the output template corresponding to the target business domain, and generate a structured report.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-8.

Images