Financial task auditing method and device based on large model

Abstract

The invention provides a financial task auditing method and device based on a large model, and relates to the technical field of digital processing, in particular to the technical field of large models and agents. The method comprises the following steps: acquiring fuzzy task information input by a user in a payment request interface; using a preset large model to search associated payment request information corresponding to the fuzzy task information in a permission boundary corresponding to the user, and using the large model to generate a to-be-audited payment request task based on target payment request information selected by the user from the associated payment request information; extracting a first key description word from the to-be-audited payment request task by using a large model, determining a second key description word matched with the first key description word in a preset key description word set as a key prompt word, and determining a target auditing rule corresponding to the key prompt word; and auditing the to-be-audited payment request task by using the large model according to prompt information corresponding to the target auditing rule to obtain an auditing result. According to the method, the accuracy and efficiency of financial data auditing are improved.

Description

Technical Field

[0001] This disclosure relates to the field of digital processing technology, specifically to the field of large model and intelligent agent technology, and in particular to a method and device for auditing financial tasks based on a large model. Background Technology

[0002] In today's digital age, intelligent financial auditing technology, powered by the development of artificial intelligence, is bringing significant changes to corporate financial management. Through machine learning and data analysis, AI can quickly process large amounts of financial data, automatically identify abnormal transactions and risks, and improve auditing efficiency. Furthermore, intelligent auditing technology can reduce human intervention, minimize human error, and ensure the accuracy and compliance of financial information. Simultaneously, AI can continuously learn and optimize auditing processes, providing real-time data insights to help companies make more accurate decisions, thereby improving overall financial management. Summary of the Invention

[0003] This disclosure presents an embodiment of a financial task auditing and electronic device based on a large model, which improves the accuracy and efficiency of financial data auditing.

[0004] In a first aspect, this disclosure proposes a financial task review method based on a large model, comprising: acquiring fuzzy task information input by a user on a reimbursement interface; using a preset large model to search for associated reimbursement information corresponding to the fuzzy task information within the user's corresponding permission boundaries, and using the large model to generate a reimbursement task to be reviewed based on the target reimbursement information selected by the user in the associated reimbursement information; wherein, the permission boundaries are determined comprehensively based on the user's real-time trust assessment value, implicit permissions derived from organizational topology, and risk perception value of the current task context; using the large model to extract a first key descriptor from the reimbursement task to be reviewed, and determining a second key descriptor matching the first key descriptor in a preset set of key descriptors as a key prompt word, and determining a target review rule corresponding to the key prompt word; wherein, the correspondence between different key prompt words and different review rules is pre-recorded, and the review rules include: multiple review actions and the execution sequence between different review actions; using the large model to review the reimbursement task to be reviewed according to the prompt information corresponding to the target review rule, and obtaining the review result.

[0005] Secondly, this disclosure proposes a financial task review device based on a large model, comprising: an information acquisition unit configured to acquire fuzzy task information input by a user on a request interface; a task generation unit configured to use a preset large model to search for associated request information corresponding to the fuzzy task information within the user's corresponding permission boundaries, and to use the large model to generate a request task to be reviewed based on the target request information selected by the user in the associated request information; wherein the permission boundaries are determined comprehensively based on the user's real-time trust assessment value, implicit permissions derived from organizational topology, and risk perception value of the current task context; a rule determination unit configured to use the large model to extract a first key descriptor from the request task to be reviewed, and to determine a second key descriptor matching the first key descriptor in a preset set of key descriptors as a key prompt word, and to determine the target review rule corresponding to the key prompt word; wherein the correspondence between different key prompt words and different review rules is pre-recorded, and the review rules include: multiple review actions and the execution sequence between different review actions; and a task review unit configured to use the large model to review the request task to be reviewed according to the prompt information corresponding to the target review rule, and obtain the review result.

[0006] Thirdly, embodiments of this disclosure provide an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to implement the large-model-based financial task auditing method as described in the first aspect.

[0007] Fourthly, embodiments of this disclosure provide a non-transitory computer-readable storage medium storing computer instructions that enable a computer to perform the large-model-based financial task auditing method as described in the first aspect.

[0008] Fifthly, embodiments of this disclosure provide a computer program product including a computer program that, when executed by a processor, can implement the steps of the financial task auditing method based on a large model as described in the first aspect.

[0009] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0010] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1This is an exemplary system architecture to which this disclosure can be applied; Figure 2 A flowchart illustrating a financial task auditing method based on a large model, provided for embodiments of this disclosure; Figure 3 A flowchart illustrating a method for determining corresponding associated reimbursement information based on acquired fuzzy task information, as provided in this embodiment of the disclosure; Figure 4 A flowchart illustrating a method for supplementing audit material information related to a payment request task to be audited, provided in this embodiment of the disclosure; Figure 5 A flowchart illustrating a method for optimizing and updating key descriptors provided in this embodiment of the disclosure; Figure 6 A flowchart illustrating a method for outputting audit results based on prompt information in a large-scale indicator model, as provided in this disclosure embodiment; Figure 7 A structural block diagram of a device for outputting audit results based on prompt information, provided in an embodiment of this disclosure; Figure 8 This is a schematic diagram of the structure of an electronic device suitable for performing a financial task auditing method based on a large model, as provided in an embodiment of this disclosure. Detailed Implementation

[0011] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding; these should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0012] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0013] Figure 1 An exemplary system architecture 100 is shown, in which embodiments of the large-model-based financial task auditing method and electronic devices of this disclosure can be applied.

[0014] like Figure 1As shown, the exemplary system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the terminal devices 101, 102, and 103 and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0015] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various applications for enabling information communication between the terminal devices 101, 102, and 103 and server 105 can be installed. These applications include financial auditing applications, web browser applications, and instant messaging applications.

[0016] Terminal devices 101, 102, and 103 and server 105 can be either hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices with displays, including but not limited to smartphones, tablets, laptops, and desktop computers. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices, and can be implemented as multiple software programs or software modules, or as a single software program or software module; no specific limitation is made here. When server 105 is hardware, it can be implemented as a distributed server cluster composed of multiple servers, or as a single server. When server 105 is software, it can be implemented as multiple software programs or software modules, or as a single software program or software module; no specific limitation is made here.

[0017] Server 105 can provide various services through its built-in applications. Taking a financial auditing application as an example, which generates and reviews pending payment requests based on fuzzy task information input by the user, Server 105 can achieve the following effects when running this application: First, it obtains the fuzzy task information input by the user on the payment request interface; then, it uses a preset large model to search for related payment request information corresponding to the fuzzy task information within the user's corresponding permission boundaries, and uses the large model to generate pending payment requests based on the target payment request information selected by the user from the related payment request information; wherein, the permission boundaries are based on the user's real-time trust assessment value and organizational structure. The implicit permissions derived from the relationship and the risk perception value of the current task context are comprehensively determined. Then, the first key descriptor is extracted from the pending payment request task using a large model, and the second key descriptor that matches the first key descriptor in the preset key descriptor set is determined as the key prompt word, and the target review rule corresponding to the key prompt word is determined. Among them, the correspondence between different key prompt words and different review rules is pre-recorded. The review rules include: multiple review actions and the execution sequence between different review actions. Finally, the large model is used to review the pending payment request task according to the prompt information corresponding to the target review rule to obtain the review result.

[0018] It should be noted that, in addition to being obtained from terminal devices 101, 102, and 103 via network 104, fuzzy task information can also be pre-stored locally on server 105 through various means. Therefore, when server 105 detects that this data is already stored locally (e.g., when starting to process previously retained financial audit tasks), it can choose to retrieve this data directly from the local storage. In this case, the exemplary system architecture 100 may also exclude terminal devices 101, 102, and 103 and network 104.

[0019] Since generating and reviewing pending payment requests based on fuzzy task information input by the user requires significant computing resources and capabilities, the large-model-based financial task review method provided in subsequent embodiments of this disclosure is generally executed by a server 105 with strong computing power and abundant computing resources. Correspondingly, the large-model-based financial task review device is also generally located within the server 105. However, it should also be noted that when terminal devices 101, 102, and 103 also possess sufficient computing power and resources, they can also complete the aforementioned calculations performed by the server 105 through their installed financial review applications, thereby outputting the same results as the server 105. Especially when multiple terminal devices with different computing capabilities exist simultaneously, but the financial review application determines that its terminal device possesses strong computing power and abundant remaining computing resources, the terminal device can perform the aforementioned calculations, thereby appropriately reducing the computing pressure on the server 105. Accordingly, the large-model-based financial task review device can also be located within terminal devices 101, 102, and 103. In this case, the exemplary system architecture 100 may also exclude the server 105 and the network 104.

[0020] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0021] Please refer to Figure 2 , Figure 2 A flowchart of a financial task auditing method based on a large model provided for embodiments of this disclosure, wherein process 200 includes the following steps: Step 201: Obtain the fuzzy task information entered by the user on the payment request interface; This step is intended for the implementation of a financial task auditing method based on a large model (e.g., Figure 1 The server 105 shown obtains fuzzy task information entered by the user on the payment request interface. The payment request interface provides interactive controls (such as a search box) that support free text input, allowing mixed input of numbers, text, and symbols (e.g., "team building expenses in March 2024: approximately 5,000"). The controls have built-in real-time syntax validation, filtering obviously invalid characters (such as special code symbols) on the front end. Fuzzy task information refers to the task description entered by the user on the payment request interface that does not fully conform to the precise format or complete semantics required by traditional systems. This means that the user can initiate a task using natural language fragments, unstructured keywords (such as "labor fees for supplier A last week"), or statements lacking key fields (such as only filling in the amount range without specifying the contract number).

[0022] Step 202: Use the preset large model to search for related reimbursement information corresponding to the fuzzy task information within the user's corresponding permission boundaries, and use the large model to generate a reimbursement task to be reviewed based on the target reimbursement information selected by the user in the related reimbursement information. In this embodiment, the executing entity uses a pre-defined large model to search for associated remittance information corresponding to fuzzy task information within the user's corresponding permission boundaries. The permission boundaries are dynamically defined data access ranges. Their core value lies in breaking through the traditional financial system's permission control model based on static roles (such as "department manager"). Instead, they are determined comprehensively based on the user's real-time trust assessment value, implicit permissions derived from organizational topology, and risk perception values ​​from the current task context. The real-time trust assessment value is generated by analyzing dynamic indicators such as the user's recent operational compliance rate and login behavior patterns. Implicit permissions are derived based on a pre-defined organizational relationship graph, combined with the user's department, project affiliation, and position in the business process. The risk perception value is based on risk assessment of sensitive elements (such as amount and supplier) in the fuzzy task information. Associated remittance information refers to candidate datasets selected by the large model from historical remittance records and / or a pre-defined remittance information list through semantic matching within the data range defined by the permission boundaries.

[0023] In this embodiment, the executing entity uses a large model to generate a pending payment request task based on the target payment request information selected by the user from the associated payment request information. The target payment request information refers to the payment request information manually selected by the user from the associated payment request information. Specifically, after the user selects the target payment request information, the large model parses the target payment request information, determines the identifier fields such as attachment ID and contract number, and automatically associates and supplements data based on these identifier fields, outputting a structured pending payment request task.

[0024] Step 203: Use the large model to extract the first key descriptor from the pending payment request task, and determine the second key descriptor in the preset key descriptor set that matches the first key descriptor as the key prompt word, and determine the target review rule corresponding to the key prompt word; In this embodiment, the executing entity uses a large model to extract a first key descriptor from the pending payment request task, and identifies a second key descriptor matching the first key descriptor from a preset set of key descriptors as a key prompt word, and determines the target review rule corresponding to the key prompt word. Here, the first descriptive keyword refers to a semantic unit extracted from the pending payment request task that can characterize the core features of the task (such as "medical expert labor" or "team building fee prepayment"). The large model uses natural language processing to parse the structured data (such as contract number, fee type, and department information) in the pending payment request task, extracting high-dimensional features associated with the review rule. For example, "payment type name: team building" and "business type name: team building" in the pending payment request task can be extracted as "team building fee".

[0025] In this embodiment, the executing entity first vectorizes the first key descriptive word using a large model, then retrieves the second key descriptive word with the highest similarity from a preset key descriptive word set as the key prompt word, and determines the target review rule corresponding to the key prompt word. The preset key descriptive word set is a predefined standardized terminology library stored in the database of the rule management module. The library pre-records the correspondence between different key prompt words and different review rules. The review rules include multiple review actions and the execution sequence between different review actions. Its core function is to unify semantic expression and avoid rule matching failures due to user input ambiguity (such as "expert teaching fee" and "expert labor").

[0026] Step 204: Use the large model to review the payment request task according to the prompts corresponding to the target review rules, and obtain the review results.

[0027] In this embodiment, the executing entity uses the large model to review the payment request task according to the prompts corresponding to the target review rules, and obtains the review result. The target review rules are a predefined set of review logic, including multiple review actions (such as "verifying contract validity" and "verifying invoice authenticity") and their execution sequence (the order in which the actions occur). Essentially, the timing constraints ensure the rigor of the review logic; for example, contract validity must be verified before checking the invoice amount to avoid risk control loopholes due to disordered action order. The prompts are the core instructions driving the large model to execute the review; they transform the rule clauses into contextual instructions that the large model can understand.

[0028] In this embodiment, the executing entity first obtains the review actions and execution sequence of the target review rules, and extracts key factual data (such as applicant, amount, reason, attachment summary, etc.) from the pending payment request task. Based on a preset template, the review actions, execution sequence, and factual data are integrated to construct a structured prompt message. The prompt message and the pending review task are submitted to the large model. The large model will consider the rules contained in the prompt message one by one, look for supporting or violated evidence in the factual data, and weigh the importance of different information through its internal attention mechanism and other components. Finally, a natural text that meets the output format requirements is generated as the review result. The review result usually includes an overall review conclusion (such as "passed", "not passed" or "supplementary materials required"), as well as an explanation of the execution status and logical basis of each applicable rule, making the review result interpretable.

[0029] In this embodiment, various strategies can be employed to construct prompts. Specifically, the level of detail in the prompts can be dynamically adjusted for review tasks of varying complexity: for simple tasks, the prompts may only include core compliance clauses; for high-risk or complex tasks, the prompts can further incorporate key points from similar historical cases and excerpts from relevant policy documents to provide richer reasoning context. Furthermore, the construction of prompts can also incorporate optimization mechanisms. For example, based on feedback from human reviewers regarding the model's reasoning chain during historical reviews, the way rules are expressed or arranged in the prompts can be automatically adjusted to increase the model's attention weight to key rules, thereby continuously improving the accuracy of the review. The effective implementation of this step ensures the automation, intelligence, and standardization of the review process, representing the core technological foundation for transforming static rules into dynamic intelligent decisions.

[0030] The financial task review method based on a large model provided in this disclosure first obtains fuzzy task information input by the user on the reimbursement interface; then, it uses a preset large model to search for related reimbursement information corresponding to the fuzzy task information within the user's corresponding permission boundaries, and uses the large model to generate a reimbursement task to be reviewed based on the target reimbursement information selected by the user in the related reimbursement information. By introducing permission boundaries, the system can safely and intelligently transform the user's fuzzy and informal task intentions into standardized reimbursement tasks to be reviewed; next, it uses the large model to extract a first key descriptor from the reimbursement task to be reviewed, and determines a second key descriptor in the preset key descriptor set that matches the first key descriptor as a key prompt word, and determines the target review rule corresponding to the key prompt word; finally, it uses the large model to review the reimbursement task to be reviewed according to the prompt information corresponding to the target review rule, and obtains the review result. Through the precise matching of key descriptors and predefined review rules, complex business rules are transformed into prompt information that the large model can execute, thereby driving the large model to simulate experts to complete automated review. This embodiment realizes an integrated process from intent understanding, access control, rule adaptation to intelligent decision-making, which significantly improves the intelligence level, security and interpretability of financial task processing, and improves the accuracy and efficiency of financial data auditing.

[0031] Based on any of the above embodiments, to deepen the understanding of how to obtain fuzzy task information and determine the corresponding associated reimbursement information, please refer to... Figure 3 , Figure 3 This flowchart illustrates a method for determining corresponding associated reimbursement information based on acquired fuzzy task information, as provided in this embodiment of the disclosure. It aims to provide a specific implementation for determining corresponding associated reimbursement information based on acquired fuzzy task information, wherein process 300 includes the following steps: Step 301: Obtain multiple fuzzy task search terms entered by the user on the payment request interface; In this embodiment, the executing entity acquires multiple fuzzy task search terms entered by the user on the reimbursement interface. Specifically, the user expresses their reimbursement intention by entering unstructured natural language or keyword fragments on the reimbursement interface. These inputs are captured by the system and defined as multiple fuzzy task search terms. For example, the user may enter multiple phrases such as "customer hospitality for the Shanghai project last week" and "restaurant invoice," which together constitute a fragmented description of their fuzzy request.

[0032] Step 302: Determine the search priority based on the user's ranking information for each fuzzy task search term; In this embodiment, the executing entity determines the search priority based on the user's ranking information for each fuzzy task search term. Specifically, the request interface can support direct drag-and-drop operations, allowing users to intuitively arrange their desired order by dragging terms up and down; this order can serve as ranking information. Alternatively, each search term can be provided with an independent priority selection control, such as a drop-down menu or a numeric input box, allowing users to assign a numerical value representing priority to each term. After obtaining this raw ranking information, the executing entity maps it to search priorities. For example, it normalizes the drag-and-drop order position (e.g., first, second) or the user-specified priority value into a sequence for controlling the execution order. The search term ranked first is assigned the highest priority and will be used first to initiate queries in subsequent processes.

[0033] Step 303: Based on the user's probability values ​​for each fuzzy task search term, determine the confidence level of each fuzzy task search term; In this embodiment, the executing entity determines the confidence level of each fuzzy task search term by supplementing the probability values ​​of each fuzzy task search term with the user's input. The probability value supplementation operation can be implemented through the human-computer interaction of the request interface. For example, next to each entered fuzzy task search term, a slider, a set of percentage option buttons, or a level selector from "uncertain" to "very certain" is provided. The user can specify a numerical value or level representing their confidence level for each term by manipulating these elements. The executing entity maps this to a standardized confidence value, such as a decimal between 0 and 1. This confidence value is then tightly bound to the fuzzy task search term, becoming part of its attributes.

[0034] In this embodiment, the execution entity system integrates multiple fuzzy task search terms, search priorities, and confidence levels to generate structured fuzzy task information. The fuzzy task information explicitly includes the original set of search terms, the search priority sequence determined in previous steps, and the confidence value determined independently for each term at this moment, thus preparing the data for subsequent processing.

[0035] Step 304: Determine the permission boundaries based on real-time trust assessment values, implicit permissions, and risk perception values, and determine the corresponding target information pool according to the permission boundaries; In this embodiment, the executing entity determines the permission boundary based on real-time trust assessment value, implicit permissions, and risk perception value, and then determines the corresponding target information pool based on the permission boundary. The real-time trust assessment value is generated by analyzing dynamic indicators such as the user's recent operational compliance rate and login behavior patterns. Implicit permissions are derived based on a pre-set organizational relationship graph, combined with the user's department, project affiliation, and position in the business process. The risk perception value is based on sensitive elements (such as amount and supplier) in fuzzy task information for risk assessment. The permission boundary is essentially a set of access control rules that integrates the real-time trust assessment value, implicit permissions, and risk perception value. It takes into account user identity, historical behavior, organizational context, and current operational risks to filter and limit the scope of accessible data, thereby determining a secure target information pool, for example, containing only the user's department and historical payment records for projects they have participated in.

[0036] In this embodiment, the process of determining the corresponding target information pool based on permission boundaries is a data filtering and mapping process. Specifically, the executing entity maintains multiple logically or physically isolated data sets (e.g., a request record database divided by department, project, or security level). Using permission boundaries as input conditions, it dynamically selects one or more data subsets for merging through query rules or access control lists to form the target information pool that is allowed to be scanned in this search. For example, a high-trust, low-risk user may be granted access to cross-project data pools, while queries with high risk perception values ​​may be strictly restricted to records initiated by the user themselves.

[0037] In this embodiment, the specific implementation steps for the executing entity to determine the permission boundary based on real-time trust assessment value, implicit permissions, and risk perception value include: determining the user's real-time trust assessment value based on the user's historical operation behavior sequence and the current compliance risk of associated users. For example, the user's historical operation behavior sequence includes detecting login patterns, audit operation compliance rate, frequency of operations at unusual times, etc. The current compliance risk of associated users refers to the fact that if closely related colleagues in the organizational collaboration network exhibit high-risk behavior (such as being marked by audits), it may mean that there are potential risks in shared processes or projects, thus requiring a systematic reduction in the trust assessment of related users; determining the user's reporting relationship and business process context based on the organizational relationship diagram, and determining the user's... The implicit permissions are defined in an organizational graph consisting of nodes representing users, departments, projects, and costs, and edges connecting these nodes according to management, participation, and responsibility relationships. A risk perception value is determined based on at least one of the following contained in the fuzzy task information: time, estimated amount, supplier, access geolocation, and device fingerprint. Determining the risk perception value is a feature extraction and risk assessment process that can parse multiple risk characteristics from the fuzzy task information, such as whether the "time" is close to the closing date, whether the "estimated amount" is abnormally high, whether the "supplier" is on a blacklist, and whether the "access geolocation" or "device fingerprint" is inconsistent with common patterns. The permission boundaries are determined based on the real-time trust assessment value, implicit permissions, and risk perception value. The executing entity inputs the output values ​​of these three dimensions (usually normalized to numerical values ​​or level labels) into a central policy decision point. This decision point can be a simple weighted summation formula or a more complex policy engine. It generates the final permission boundary based on preset fusion rules (e.g., "high trust allows for moderately relaxed risk restrictions, but high risk requires strict permission constraints"). This boundary may be expressed as a set of filtering conditions directly understandable by the data access layer, such as "allow access to departments A and B, and project X, with an amount screening threshold not exceeding Y yuan." This embodiment dynamically constructs a fine-grained, adaptive, and context-aware permission boundary by integrating real-time user behavior trust, context-related implicit permissions derived from organizational relationship diagrams, and multi-dimensional risk perception of the current operation. It responds in real-time to changes in user behavior credibility, adapts to dynamic rights and responsibilities in organizational structure and business processes, and automatically tightens permissions for high-risk operations. This achieves intelligent and precise permission management while ensuring data security, effectively balancing business flexibility and security compliance requirements.

[0038] In this embodiment, the execution entity determines the permission boundary based on real-time trust assessment value, implicit permissions, and risk perception value. The weights of the three dimensions are not fixed, but can be dynamically adjusted according to the business category to which the current task belongs (such as "travel expense reimbursement" and "asset procurement"). In the procurement scenario, more emphasis is placed on supplier risk, while in the travel scenario, more attention is paid to anomalies in time and geographical location.

[0039] In this embodiment, the executing entity determines the user's reporting relationship and business process context based on the organizational chart, and determines the user's implicit permissions. Specifically, in response to detecting that the user's direct superior is in an inaccessible state, based on the edges representing management relationships in the organizational chart, it determines the backup nodes that can temporarily replace the direct superior and the set of permissions for the backup nodes. The set of regular approval or viewing permissions associated with these backup nodes will be temporarily granted to the current user to ensure that the business process will not be interrupted due to a single point of failure. In response to fuzzy task information being associated with a preset project, based on the edges representing participation relationships in the organizational chart, it determines the user's project role in the preset project, and determines the resource access permissions related to the project context based on the project role. That is, based on the predefined role-permission mapping table, the executing entity grants the user resource access permissions related to this project context, such as access to the project's dedicated budget details, historical contracts, or specific supplier lists. Based on the business process stage of the current task to be created and the edges representing responsibility relationships in the organizational chart, it determines the information preview permissions that the user can inherit from subsequent nodes. Based on the set of permissions for backup nodes, resource access permissions, and information preview permissions, it determines the user's implicit permissions. This embodiment models entities and relationships within an organization in a graph format, and dynamically calculates users' implicit permissions by traversing specific relationship edges between nodes in the graph in real time and combining them with the current specific business context. This allows the capture of the unwritten and contextualized allocation logic of rights and responsibilities that exists extensively in the actual operation of an enterprise.

[0040] In this embodiment, when determining backup nodes, the executing entity can not only follow the management relationship chain but also introduce priority evaluation, comprehensively considering factors such as the node's current workload and the degree of collaboration with the current user to select the optimal backup node. Permissions determined by project roles can be further subdivided to the task level, allowing users to have differentiated data operation permissions in different project tasks. The scope of information preview permissions can also be dynamically controlled hierarchically, for example, by determining the level of detail of information that a user can preview based on their real-time trust assessment value. This series of mechanisms works together to make user permissions a dynamically evolving attribute that changes with organizational status, project context, and business process stage, greatly enhancing the flexibility and adaptability of the permission system.

[0041] In this embodiment, the executing entity determines the risk perception value based on at least one of the following included in the fuzzy task information: time, estimated amount, supplier, access geolocation, and device fingerprint. Specifically, based on the relationship between the input time of fuzzy task information and key nodes in the financial cycle, a time sensitivity coefficient is determined. For example, a high-amount payment request initiated in the last hour before closing will have its time sensitivity coefficient increased because there may be an attempt to circumvent the normal review process. Based on the estimated amount in the fuzzy task information and the user's historical payment request records, the deviation of the estimated amount from the user's historical average amount and frequency, or whether it exceeds the conventional approval threshold corresponding to their role, is calculated to determine the payment request risk level. Based on the suppliers in the fuzzy task information, internal or external supplier risk control databases are queried to check whether the supplier has records of historical disputes, legal proceedings, credit downgrades, or being blacklisted, thereby determining supplier risk. The current access geolocation, device fingerprint, and the user's historical access patterns are compared to determine an abnormal access score. If any of the current access geolocation, device fingerprint, and the user's historical access patterns deviate, the abnormal access score is increased. The time sensitivity coefficient, payment request risk level, supplier risk, and abnormal access score are aggregated through a preset risk aggregation model to output a risk perception value. The risk aggregation model can be a rule-based decision tree (e.g., if "supplier risk" is high, the overall risk is directly rated as high), or a lightweight machine learning classifier trained on historical risk cases (such as a logistic regression model). The task of the risk aggregation model is to perform weighted or non-linear fusion based on the importance and interrelationships of each indicator, ultimately outputting a unified, standardized "risk perception value." This value can be a score, a level (high, medium, low), or a probability, providing direct input regarding the degree of danger of the current operation request for subsequent determination of "authorization boundaries." This embodiment, by establishing and parallelizing multiple independent feature risk indicators, and then comprehensively evaluating them through an aggregation model, can more comprehensively and robustly capture complex risk patterns, avoiding defense vulnerabilities caused by misjudgments of a single indicator.

[0042] In this implementation, the threshold for judging abnormal access can be temporarily adjusted based on the user's recent business trip plans or equipment replacement notifications to reduce false alarms. The risk aggregation model can adopt an online learning approach. When subsequent manual review confirms real high-risk cases that the system failed to accurately warn of, or overturns the system's false alarms, this feedback data can be used to fine-tune the model's aggregation weights. This allows the entire risk perception system to continuously evolve with changes in the enterprise's security posture, improving its predictive accuracy and business adaptability.

[0043] Step 305: Using the large model, search in the target information pool according to the search priority determined by the search order, use each fuzzy task search term to search with the corresponding confidence level, and obtain the sub-association request information corresponding to each fuzzy task search term in turn; In this embodiment, the executing entity uses the large model to sequentially search the target information pool using each fuzzy task search term according to the search priority determined by the search order, and obtains the sub-association request information corresponding to each fuzzy task search term. Different confidence levels correspond to different search methods: those with confidence levels exceeding a preset confidence threshold use precise search, while those below the preset confidence threshold use fuzzy search.

[0044] In this example, precise and fuzzy searches can be further subdivided into multiple levels, dynamically linked to specific numerical ranges of confidence, rather than simply comparing to a fixed threshold. Furthermore, a feedback mechanism can be introduced into the search process, dynamically adjusting the search scope or confidence threshold of subsequent terms based on the quantity and quality of search results for the preceding high-priority term. For example, if the first high-confidence term returns too few results, the system can automatically lower the confidence threshold for subsequent terms, employing more fuzzy search to attempt to obtain more relevant clues. This strategic multi-round retrieval mechanism allows the information discovery process to both focus on key points and be flexible in dealing with uncertainty.

[0045] Step 306: Use the large model to summarize the reimbursement information of each sub-related reimbursement to obtain the related reimbursement information corresponding to the fuzzy task information.

[0046] In this example, the executing entity uses a large model to summarize the reimbursement information of each sub-related reimbursement request to obtain the related reimbursement information corresponding to the fuzzy task information. Specifically, the executing entity first inputs the sub-related payment request information into the large model. The large model identifies the core entities in each sub-related payment request information (such as payment request number, project name, supplier, date, and amount) and determines which sub-related payment request information points to the same payment request (for example, the two sub-information items "travel expenses for Project A" and "reimbursement for last week's trip to Shanghai" are associated with the same travel reimbursement form). Second, conflict detection and information fusion are performed. When different sub-related payment request information have different descriptions of the same attribute (such as amount), the model will judge based on the reliability of the information source (such as potentially assigning higher weight to search results corresponding to high-confidence terms) or based on logical consistency, and generate the most reliable version. Finally, information completion and structured presentation are performed. The model integrates complementary details scattered in different sub-information (such as one sub-information providing the amount and another providing the attachment number) into a complete payment request record description, removes completely duplicated content, and finally outputs a list of related payment request information that is non-repeating, information-rich, and uniformly formatted, as a clear option for the user to choose from.

[0047] In this embodiment, when the large model aggregates the information of each sub-related reimbursement request, in addition to analyzing the information itself, it can also refer to the search priority in the fuzzy task information, giving higher retention weight or ranking to results from high-priority search terms. Furthermore, the aggregation logic can be designed to be configurable, for example, providing different fusion modes that prioritize recall or precision. In recall mode, it tends to retain more potentially relevant records, while in precision mode, it performs stricter deduplication and consistency checks to adapt to different user search preferences. This intelligent aggregation step is crucial for transforming fragmented search results into usable knowledge, directly determining the quality of information and the user experience ultimately presented.

[0048] The method disclosed in this embodiment for determining corresponding related payment requests based on acquired fuzzy task information constructs a structured query intent by prioritizing and labeling multiple fuzzy search terms input by the user, and limits the secure data search scope based on dynamically calculated permission boundaries. Furthermore, it utilizes confidence-driven differentiated search strategies to achieve an intelligent balance between comprehensiveness and precision. Finally, it fuses multiple rounds of search results through a large model, thereby efficiently, securely, and accurately transforming fuzzy and informal user intents into a complete and standardized list of related payment requests, significantly improving the intelligence level of information retrieval and user experience in complex business scenarios.

[0049] Based on any of the above embodiments, in order to proactively identify and verify the pre-dependency information of the pending payment request task in the complete business chain, please refer to... Figure 4 , Figure 4 The flowchart of a method for supplementing audit material information related to a payment request task provided in this embodiment of the present disclosure aims to supplement audit material information related to a payment request task and provides a specific implementation method, wherein process 400 includes the following steps: Step 401: Use the large model to determine the associated business process corresponding to the pending payment request task in the preset business process library; In this embodiment, the executing entity uses a large model to determine the associated business processes corresponding to the pending payment request task from a pre-defined business process library. The business process library refers to a structured definition of standardized steps, sequences, and data transfer relationships for various business processes within the enterprise. Once the pending payment request task is generated, the executing entity uses the large model to analyze the task's key attributes (such as the projects involved, cost centers, and types of reasons), performs pattern matching and association reasoning in the business process library, and thus determines the associated business processes corresponding to the pending payment request task. Associated business processes refer to other business process steps in a complete business chain that are logically related to the business steps corresponding to the pending payment request task.

[0050] Step 402: Determine the relevant audit materials information for the pending payment requests based on the target audit rules; In this embodiment, the executing entity determines the audit material information related to the pending payment request task based on the target audit rules. Specifically, the executing entity parses out all the audit material information necessary to complete the audit based on the specific requirements of the target audit rules (e.g., the rules may require "acceptance must be qualified before the final payment is made"). This list not only includes the documents attached to the task itself, but also explicitly includes other audit information that needs to be retrieved from the complete business chain and is located before the payment request stage (e.g., the approval status and conclusion of the acceptance report).

[0051] Step 403: In response to other audit information contained in the audit materials that is involved in other business process steps in the complete business chain that precede the pending payment request task, verify the other audit information; In this embodiment, when the audit materials information includes other audit information related to other business process stages preceding the pending payment request task in the complete business chain, the executing entity verifies the other audit information. Specifically, the executing entity automatically accesses or queries the database, document management system, or business system storing the audit results of upstream stages according to the path defined in the related business process, obtains other audit information, and verifies whether its status and content meet the requirements of the current audit. For example, if the audit materials information indicates that the approval status of a related contract needs to be verified, the executing entity will automatically access the contract management system through a pre-integrated application programming interface based on the contract number extracted from the pending payment request task, query whether the signing process of the contract has been fully completed, and obtain the final approval conclusion document; if the materials information requires confirmation of the project budget balance, the executing entity will initiate a query to the project management or budget system to obtain dynamic data such as the total budget, incurred costs, and current available funds for the project.

[0052] Step 404: In response to an anomaly in other audit information, create an other information completion task and notify the task handlers corresponding to the other audit information to complete the other audit information.

[0053] In this embodiment, when other audit information is abnormal, the executing entity creates an "Other Information Completion Task" and notifies the corresponding task handler of the other audit information to complete it. Abnormalities in other audit information include: complete absence of required information, information status not meeting requirements (e.g., contract status is "draft" instead of "effective"), logical contradictions in information content (e.g., acceptance date is later than payment request date), or values ​​exceeding thresholds. When the above abnormalities occur, the executing entity creates an "Other Information Completion Task," which is an independent workflow object. Its content records at least: a description of the specific information to be completed (e.g., "Please upload a signed scanned copy of the final acceptance report for project X"), the associated original business process step and document identifier, the detailed reason for the abnormality, and the corresponding task handler. The logic for determining the handler typically stems from the definition of the responsible role or node in the associated business process for that upstream step. Subsequently, the executing entity notifies the task handler by integrating the enterprise's internal workflow engine, instant messaging tools, or email system. The notification includes a link or key information for the completion task, guiding the responsible person to complete it.

[0054] The method disclosed in this embodiment for supplementing audit material information related to a pending payment request task achieves a shift from isolated document auditing to full-process collaborative risk control by placing the pending payment request task within its complete business process chain for context awareness and correlation analysis. The executing entity can intelligently identify and automatically verify the audit information of the preceding stages on which the pending payment request task depends, thereby discovering and preventing financial risks caused by upstream business interruptions or defects in advance. When an anomaly is detected, a supplementary task can be automatically created and driven, forming a closed-loop management mechanism of "problem discovery - precise location - collaborative repair". This not only improves the reliability of a single audit but also promotes the overall compliance and integrity of cross-departmental business processes.

[0055] Based on any of the above embodiments, to ensure that the preset key descriptor set can adapt to business changes, please refer to... Figure 5 , Figure 5 A flowchart of a method for optimizing and updating key descriptors is provided as an embodiment of this disclosure. The method aims to optimize and update key descriptors and provides a specific implementation. The process 500 includes the following steps: Step 501: Obtain manual confirmation feedback on the audit results, historical hit data of the target audit rules, and descriptions of newly emerging financial audit scenarios; In this embodiment, the executing entity obtains manual confirmation feedback on the audit results, historical hit effect data of the target audit rules, and descriptions of newly emerging financial audit scenarios. Specifically, the executing entity obtains manual confirmation feedback on the audit results through a convenient interactive interface, allowing authorized financial auditors to make final confirmations or corrections to the correctness of the audit results output by the large model after reviewing them. This confirmation goes beyond a simple "right / wrong" label; it should capture more nuanced feedback, such as highlighting violations missed or compliance items misjudged by the system. These fine-grained annotations become valuable data for identifying blind spots in the system's understanding. The implementing entity continuously records and statistically analyzes audit logs in the background to obtain historical hit rate data for target audit rules. Whenever an audit rule is triggered, the implementing entity needs to record the trigger context, the rule's judgment result, and the final manual confirmation result for the audit task. By aggregating and analyzing these logs, the hit rate data of the audit rules can be calculated, such as their trigger frequency, the consistency rate (accuracy rate) between audit conclusions and manual conclusions, and the specific scenario categories that led to disputes or misjudgments. The implementing entity can establish an input channel for external knowledge or policy updates to obtain descriptions of newly emerging financial audit scenarios. For example, subscribing to regulatory change notices issued by authoritative institutions, having business personnel manually enter descriptions of new business models (such as "remote work subsidies"), or monitoring internal corporate communications summaries of discussions on new expense types. Descriptions of newly emerging financial audit scenarios are typically presented as fragments of new domain knowledge in natural language or structured tagging.

[0056] Step 502: Based on manual confirmation feedback, identify the violation features that actually exist in the pending payment request tasks but are not covered by the first key descriptor, and generate candidate key descriptors; In this embodiment, the executing entity identifies, based on manual confirmation feedback, the violation features that actually exist in the pending payment request task but are not covered by the first key descriptor, and generates candidate key descriptors. Specifically, firstly, the text in the manual confirmation feedback is parsed, and entity recognition, keyword extraction, and semantic analysis techniques are used to extract the violation features indicated by the manual confirmation feedback, such as extracting key concepts and their relationships, such as "personal account" and "corporate refund." Then, the violation feature descriptions are compared with the original feature extraction results of the first key descriptor used to generate the pending payment request task, and semantic similarity is also calculated with existing entries in the preset key descriptor set. If it is confirmed that the violation feature description cannot be fully represented or matched by existing entries, it is determined that it is not covered. Finally, the executing entity summarizes the violation feature descriptions into a more general expression (such as abstracting "using a personal account to receive a corporate refund" as "mixed use of public and private accounts"), or decomposes them into several combinable key elements, thereby forming one or more structured candidate key descriptors.

[0057] Step 503: Based on historical hit performance data, perform at least one of the following optimization operations on the key descriptors in the preset key descriptor set: semantically focus or split key descriptors with ambiguous matching, reduce the weight or archive key descriptors that have not been hit for a long time, and redefine key descriptors with low success rate of association rule review. In this embodiment, the executing entity performs at least one of the following optimization operations on key descriptors in the preset key descriptor set based on historical hit effect data: semantic focusing or splitting key descriptors with ambiguous matching, downgrading or archiving key descriptors that have not been hit for a long time, and redefining key descriptors with low success rate in association rule review. Specifically, the following three types of targeted optimization operations are performed based on historical hit effect data: First, for terms that perform unstablely during matching, semantic focusing or splitting key descriptors with ambiguous matching is performed. For example, if a key descriptor named "entertainment expenses" frequently matches both compliant client meeting catering and non-compliant internal welfare meals, causing fluctuations in the accuracy rate of subsequent rule review, it indicates that the semantics of this term are too broad. The executing entity can tighten its definition by semantic focusing and adding restrictive context labels (such as "external business entertainment"), while the "splitting" operation decomposes it into two more precise terms, such as "client entertainment catering" and "internal team building catering"; Second, by analyzing all terms in the terminology database over a longer period of time... The number of triggers within a cycle identifies terms that have not been triggered by any payment requests for a long time. For these terms, downgrading means reducing their priority in the matching algorithm so that they will not interfere with the matching of high-frequency terms. Archiving means moving them to a historical database or a waiting area to free up the capacity and efficiency of the active term database. Third, when the matching of a key descriptor itself is accurate, but the association rules triggered and executed by it continue to produce low accuracy audit results, the problem may be that the definition of the violation feature pointed to by the term is biased. At this time, the executing entity triggers the "redefinition" process. Based on specific failure cases, the large model suggests or the administrator intervenes manually to modify the text description or feature vector of the key descriptor to more accurately depict the business concept it originally intended to represent.

[0058] Step 504: Perform association matching verification between the optimized key descriptors and the newly emerging financial audit scenario description, and update the verified key descriptors to the preset key descriptor set.

[0059] In this embodiment, the executing entity performs association matching verification between the optimized key descriptors and the newly emerging financial audit scenario description, and updates the verified key descriptors to the preset key descriptor set. Specifically, the executing entity first obtains the newly emerging financial audit scenario description (e.g., "new regulations on reimbursement of network expenses for remote work"); then, it uses each verified key descriptor one by one to attempt to calculate the semantic relevance with the financial audit scenario description. This is done by comparing the distance between the word embedding vectors of both parties in the semantic space, or by using a lightweight large model for rapid relevance judgment, to determine whether the key descriptor can reasonably identify or associate with the compliance points or risk characteristics that may be contained in the newly emerging financial audit scenario description. For example, an optimized term "mixed use of public and private accounts" should be able to generate a high degree of relevance with a newly emerging financial audit scenario description about "advancing expenses for public projects through personal payment tools". Only those key descriptors that show clear and reasonable relevance in the verification are considered "verified"; finally, an update operation is performed to formally incorporate these verified terms into the preset key descriptor set.

[0060] The method for optimizing and updating key descriptors disclosed in this embodiment introduces a closed-loop self-learning and optimization mechanism based on human feedback, historical performance data, and new scenario descriptions. This allows the preset set of key descriptors to be continuously updated and optimized. The executing entity can not only automatically discover and supplement uncovered violation features from auditing practice, but also accurately optimize existing keywords and ensure their applicability through verification with new scenarios. This process realizes a transformation from static rule matching to dynamic knowledge growth, significantly reducing manual maintenance costs and ensuring that the large model can adapt to business changes and maintain high accuracy and broad scenario coverage in the long term.

[0061] Based on any of the above embodiments, to improve the professionalism, accuracy, and parsability of large model review results, please refer to... Figure 6 , Figure 6 A flowchart of a method for outputting review results based on prompt information in an indicator model, provided as an embodiment of this disclosure, aims to provide a specific implementation of outputting review results based on prompt information in an indicator model, wherein process 600 includes the following steps: Step 601: Based on the content of the target audit rules and the task information of the payment request to be audited, assemble structured prompt information. The structured prompt information includes at least the following sequentially concatenated parts: a role definition part, used to assign a specific identity related to financial audit to the large model; a rule injection part, derived from the target audit rules, used to inject specific audit basis into the large model; a task context part, extracted from key information in the payment request to be audited, used to provide the large model with the factual background required for audit; and an output specification part, used to constrain the specific format and structure of the audit results output by the large model. In this embodiment: Based on the content of the target audit rule and the task information of the payment request to be audited, the executing entity assembles a structured prompt message. The structured prompt message includes at least the following sequentially concatenated parts: a role definition part, used to assign a specific identity related to financial auditing to the large model, usually a fixed or configurable text, such as "Please play the role of a rigorous corporate financial auditing expert. Your responsibility is to strictly audit payment requests in accordance with company policies and identify any potential compliance risks and errors"; and a rule injection part, derived from the target audit rule, used to inject specific audit basis into the large model, transforming the natural language clauses or structured logic of the target audit rule into clear and unambiguous instructions, for example, injecting a rule " The phrase "Travel allowance review must not exceed the daily standard" is transformed into "Please verify the travel dates and allowance amount in the application to determine whether the daily allowance amount exceeds the company's stipulated standard of XXXX (specific amount) yuan." The task context extracts key information from the pending payment request (such as applicant, department, amount, reason, date, etc.) and embeds it in a concise and objective manner into the prompt information to provide the large model with the necessary factual background for review. The output specification constrains the specific format and structure of the large model's output review results, for example, "Please strictly follow the following JSON format, including three fields: 'Conclusion,' 'Result of each rule check,' and 'Risk Warning,' where 'Conclusion' can only be 'Pass' or 'Fail.'" These four parts are concatenated sequentially to form a complete instruction chain from identity setting, basis provision, factual input to format constraints.

[0062] Step 602: Input the structured prompt information and the complete content of the payment request task to be reviewed into the large model to instruct the large model to complete the review reasoning based on the prompt information and obtain the review result that meets the requirements of the output specification.

[0063] In this embodiment, the executing entity inputs structured prompts along with the complete content of the payment request task to the large model, instructing the large model to complete the review reasoning based on the prompts and obtain an output review result that conforms to the requirements of the output specification. Specifically, the executing entity concatenates the structured prompt text with the original or standardized text of the payment request task (such as key-value pairs of form fields or parsed summaries of attachments) to form a complete input string. This string is sent to the large model service via a network request. The large model does not simply answer the question but generates the data strictly following the instructions required by the output specification. For example, if the output specification requires a specific JSON structure, the model will strive to ensure that the generated text strictly conforms to the syntax and field definitions of that structure. Finally, the model service and the executing entity return the generated text parsed into a structured review result. The review result not only includes a "pass" or "fail" conclusion but also a compliance judgment, brief basis, and possible risk warnings for each injection rule, fully conforming to the preset format and structure requirements.

[0064] This embodiment discloses a method for outputting audit results based on prompt information in a large-scale model. By constructing a structured prompt information assembly and injection mechanism, it transforms abstract target audit rules and specific task contexts into a "thinking framework" and "output template" that the large-scale language model can accurately execute. This effectively guides the general-purpose large-scale model to conduct controllable and reliable reasoning in the professional field of financial auditing. Furthermore, by defining roles to assign expert status to the model, providing clear audit basis through rule injection, providing factual background through task context, and constraining the result format through output specifications, it ultimately achieves standardization of the audit process and structured result output, significantly improving the professionalism, accuracy, and parsability of the large-scale model's audit.

[0065] Based on any of the above embodiments, in order to achieve transparency and auditability of the review decision, when the review is completed, the executing entity generates and displays visual information about the review process. The generation of this visual information includes: constructing and displaying an audit tracing graph based on the original data of the pending payment request, the intermediate inference data during the large model's review, and the review results. The audit tracing graph is presented in an interactive graph structure, with nodes including at least input nodes representing the original data, trigger nodes representing rule matching, intermediate nodes representing different inference steps, and output nodes representing the final conclusion. Edges are used to represent logical deductions, evidence support, or temporal relationships between nodes. This embodiment captures and structurally presents these steps, constructing an audit tracing graph from input to output. This externalizes the internal logic of the large model, serving as both a record of the large model's working process and providing an intuitive path to verify the correctness of the review conclusions, understand the model's decision-making basis, and even discover potential rule defects.

[0066] To enhance understanding, this disclosure also provides a specific implementation scheme based on a particular application scenario: Suppose that employee "Zhang San" of Company A needs to claim reimbursement for travel expenses to Shanghai for a technical exchange with a client on "Project B". Company A has designed an intelligent financial system as follows. This intelligent financial system is deployed on the company's internal server, and its core workflow consists of the following steps: Phase 1: Fuzzy Task Input and Intent Understanding 1. Zhang San entered a vague message in the natural language input box on the payment request interface: "Request payment for travel expenses and meals for meeting clients at Project B in Shanghai last week. I have attached the invoices." 2. The intelligent financial system parses fuzzy information into multiple fuzzy task search terms: "Shanghai", "XX project", "customer communication", "travel", and "catering".

[0067] 3. Zhang San set the search priority of "Project B" and "Shanghai" to high priority by dragging and dropping multiple fuzzy task search terms.

[0068] 4. Zhang San's confidence level for "Project B" is 95% (very certain), and his confidence level for "Catering" is 60% (he remembers eating, but is not sure which meals).

[0069] 5. The intelligent financial system generates structured fuzzy task information based on the above steps.

[0070] Phase Two: Determining Dynamic Permission Boundaries 1. Real-time Trust Assessment: The intelligent financial system queries Zhang San's historical expense reimbursement records (all compliant), and his team has no recent risk events, so it determines his real-time trust assessment value as "high".

[0071] 2. Implicit Permission Derivation: The intelligent financial system, through querying the organizational chart, discovers: a. Zhang San's direct supervisor, Li Si, is currently on a business trip (inaccessible). Based on the management relationship edge, the intelligent financial system identifies Wang Wu (another team leader in the same department) as a backup node, and Zhang San temporarily gains partial approval preview permissions from Wang Wu. b. The "Project B" node shows Zhang San as a participating member, therefore he automatically gains resource access permissions to view the project's budget and historical reimbursements. c. The current task is in the "Reimbursement Application" stage. Based on the responsibility relationship edge, the system allows Zhang San to preview some policy basis required for the next stage, "Department Approval."

[0072] 3. Risk Perception Calculation: The intelligent financial system analyzes the fuzzy task information and obtains the following information: the time is last week (reasonable), the estimated amount is 5,000 yuan (slightly higher than the historical level but not exceeding the threshold), the supplier is a commonly used ticketing platform and hotel (low risk), and the login IP and device are Zhang San's commonly used computer (no abnormalities). Based on the above information, the risk perception value is assessed as "medium to low".

[0073] 4. Determine the boundaries of permissions and the target information pool: Based on the comprehensive real-time trust assessment (high), risk (medium-low) and the derived implicit permissions, the intelligent financial system defines the boundaries of permissions as follows: access to all historical records of Zhang San, all reimbursement data of Project B, and publicly available data within Wang Wu's group obtained through the backup node mechanism, thereby determining the corresponding target information pool.

[0074] Phase Three: Multi-round Differentiated Security Search and Information Integration 1. The intelligent financial system uses a large model to prioritize and first use the high-confidence term "Project B" (>95%) to conduct a precise search in the target information pool (strictly matching the project name) to find all relevant payment requests for that project; then it uses "Shanghai" to conduct a precise search and filter out records with Shanghai as the destination from the above results.

[0075] 2. The intelligent financial system uses a large model to perform a fuzzy search on "catering" (60%) with a low confidence level (expanding synonyms such as "meal expenses" and "entertainment" and lowering the similarity threshold) to associate potentially related catering invoices from the preceding results.

[0076] 3. After aggregating and deduplicating the search results, the intelligent finance system generates a list of related reimbursement requests and displays it to Zhang San. Zhang San selects a historical travel record as a reference template, and the intelligent finance system, based on this and his input, generates a structured reimbursement task awaiting review. Furthermore, the intelligent finance system supports querying and retrieving reimbursement tasks based on their application type, scenario name, unique identifier, task status (pending execution, successful execution, failed execution, manually marked as complete), creation time, and task notification status (whether the review result has been notified to a designated system).

[0077] Phase 4: Rule Matching and Cross-Process Association Verification 1. The intelligent financial system uses a large model to extract the first key descriptor from the pending reimbursement tasks, such as "travel expenses" and "entertainment expenses", and matches it with a preset set of key descriptors. The second key descriptor in the preset set of key descriptors that matches the first key descriptor, such as "travel reimbursement - external customers", is identified as the key prompt word. Then, the target review rules (including transportation standards, accommodation standards, entertainment expense limits, etc.) corresponding to the key prompt word are hit.

[0078] 2. The intelligent financial system determines the audit materials that need to be verified based on the target audit rules, including: this invoice, travel approval form, and the budget status of Project B.

[0079] 3. The intelligent financial system uses a large model to locate the complete business chain associated with the current pending expense request in the business process library: "Business trip application approval → Business trip execution → Reimbursement application". The intelligent financial system then queries other approval information (i.e., electronic approval forms) for the "Business trip application approval" stage of this business trip.

[0080] 4. The approved budget in the electronic approval form is 4,500 yuan, but the reimbursement application is for 5,000 yuan, which is abnormal (over budget).

[0081] 5. The intelligent financial system automatically creates other information completion tasks and notifies Li Si (Zhang San's superior, who is now accessible) who is in charge of the task in the business trip approval process, with the message "Zhang San's Shanghai business trip reimbursement application amount (5,000 yuan) exceeds the approved budget (4,500 yuan). Please provide supplementary explanations or adjust the budget."

[0082] Phase 5: Structured Hints and Large Model Review 1. Assemble structured prompts: Role – “You are the company’s financial audit specialist, and you are required to strictly review the compliance of travel expense reimbursements.” Rules – “Rule 1: The maximum standard for domestic business trip accommodation is 600 yuan per night. Rule 2: Meal expenses for entertaining clients must be reported in advance…” Context—"Applicant: Zhang San; Department: R&D Department; Project: Project B; Itinerary: Shanghai, 3 days; Receipts: Hotel A invoice for 2 nights totaling 1300 yuan, Restaurant B invoice for 800 yuan..." Output guidelines: "Please output in JSON format, including: overall conclusion, review results and basis for each rule, and risk warnings." The structured prompts support flexible configuration and management, including the ability to add, modify, search, and enable / disable various parts of the prompts.

[0083] 2. The intelligent financial system inputs the structured prompts and detailed information of the pending payment requests into the big model. After reasoning, the big model outputs the audit results: the accommodation fee is compliant (650 yuan < 600 yuan * 2 nights? Calculation error, it should be 1300 yuan > 1200 yuan, so it should actually trigger failure), but the catering fee is non-compliant because there is no prior reporting record. The overall conclusion is "failure", and a "budget overrun" risk is indicated.

[0084] Phase 6: Visualization and Optimization of the Review Process 1. After the review is completed, the intelligent financial system generates a review traceability graph and displays it to Zhang San and the finance staff. The review traceability graph shows: input nodes (original invoice data), trigger nodes (matching the "travel reimbursement - external customer" rule set), intermediate inference nodes and their basis ("calculate total accommodation amount of 1300 yuan", "query accommodation standard of 1200 yuan", "judgment: exceeding the standard"), review result (conclusion: not approved), and manual feedback annotations, clearly showing the data flow and logical judgment basis.

[0085] 2. The finance staff manually confirmed the audit results were correct and noted in the manual feedback that "the basis for the over-budget calculation is clear." The intelligent finance system recorded that the "accommodation standard" rule was hit accurately and effectively. At the same time, the intelligent finance system generated the candidate keyword "extra-budget expenditure" from this case of "failure to report over-budget in advance." After further verification, it will be added to the thesaurus to better capture such future risks.

[0086] 3. The intelligent financial system supports calculating the success rate of target audit rules within a preset time period, and optimizing the target audit rules and audit prompts based on the success rate; it can also calculate the hit rate between the financial information to be audited and the matched audit prompts to optimize the target audit rules and audit prompts.

[0087] This embodiment demonstrates how an intelligent financial system can transform a vague natural language request into a compliant, in-depth, and traceable audit operation through dynamic access control, intelligent search, contextual association, rule-based prompts, and large-scale model reasoning. In this process, it achieves self-optimization and collaborative correction, fully demonstrating the commercial value and technical feasibility of the intelligent financial system.

[0088] Further reference Figure 7 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a financial task review device based on a large model. This device embodiment is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0089] like Figure 7As shown, the financial task auditing device 700 based on a large model in this embodiment may include: an information acquisition unit 701, a task generation unit 702, a rule determination unit 703, and a task auditing unit 704. The system includes: an information acquisition unit 701, configured to acquire fuzzy task information input by the user on the payment request interface; a task generation unit 702, configured to use a preset large model to search for related payment request information corresponding to the fuzzy task information within the user's corresponding permission boundaries, and to generate a payment request task to be reviewed based on the target payment request information selected by the user in the related payment request information; wherein the permission boundaries are determined comprehensively based on the user's real-time trust assessment value, implicit permissions derived from organizational topology, and risk perception value of the current task context; a rule determination unit 703, configured to use the large model to extract a first key descriptor from the payment request task to be reviewed, and to determine a second key descriptor matching the first key descriptor in the preset key descriptor set as a key prompt word, and to determine the target review rule corresponding to the key prompt word; wherein the correspondence between different key prompt words and different review rules is pre-recorded, and the review rules include: multiple review actions and the execution sequence between different review actions; and a task review unit 704, configured to use the large model to review the payment request task to be reviewed according to the prompt information corresponding to the target review rule, and obtain the review result.

[0090] In this embodiment, the specific processing of the information acquisition unit 701, task generation unit 702, rule determination unit 703, and task review unit 704 in the large-scale model-based financial task review device 700, and the resulting technical effects, can be found in the following references: Figure 2 The relevant descriptions of steps 201-204 in the corresponding embodiments will not be repeated here.

[0091] In some optional implementations of this embodiment, the information acquisition unit 701 is further configured as follows: a search term input module, configured to acquire multiple fuzzy task search terms entered by the user on the request interface; a priority determination module, configured to determine the search priority based on the user's sorting information for each fuzzy task search term; and a confidence level determination module, configured to determine the confidence level of each fuzzy task search term based on the user's probability value supplementation operation for each fuzzy task search term; wherein, the fuzzy task information includes: multiple fuzzy task search terms, search priority, and each confidence level; correspondingly, the task generation unit 702 is further configured as: an information pool determination module, configured to determine the information pool based on real-time trust evaluation. Valuation, implicit permissions, and risk perception values ​​determine the permission boundaries, and the corresponding target information pool is determined based on the permission boundaries. The multi-round search module is configured to use the large model to search the target information pool sequentially using each fuzzy task search term according to the search priority determined by the search model, and obtain the sub-related reimbursement information corresponding to each fuzzy task search term. Different confidence levels correspond to different search methods: those with confidence levels exceeding the preset confidence threshold use precise search, and those with confidence levels below the preset confidence threshold use fuzzy search. The reimbursement information determination module is configured to use the large model to summarize the sub-related reimbursement information to obtain the related reimbursement information corresponding to the fuzzy task information.

[0092] In some optional implementations of this embodiment, the information pool determination module in the task generation unit 702 includes: a trust assessment module, configured to determine the user's real-time trust assessment value based on the user's historical operation behavior sequence and the associated user's current compliance risk; an authorization determination module, configured to determine the user's implicit authorization based on an organizational relationship diagram to determine the user's reporting relationship and business process context; wherein the organizational relationship diagram consists of nodes acting as users, departments, projects, and costs, and edges connecting different nodes constructed according to management, participation, and responsibility relationships; a risk perception module, configured to determine a risk perception value based on at least one of time, estimated amount, supplier, access geographical location, and device fingerprint contained in the fuzzy task information; and an authorization boundary determination module, configured to determine the authorization boundary based on the real-time trust assessment value, implicit authorization, and risk perception value.

[0093] In some optional implementations of this embodiment, the permission determination module in the task generation unit 702 includes: in response to detecting that the user's direct superior is in an inaccessible state, determining a backup node that can temporarily replace the direct superior and a set of permissions for the backup node based on the edges representing management relationships in the organizational relationship diagram; in response to fuzzy task information being associated with a preset project, determining the user's project role in the preset project based on the edges representing participation relationships in the organizational relationship diagram, and determining resource access permissions related to the project context based on the project role; determining the information preview permissions that the user can inherit from subsequent nodes based on the business process stage of the current task to be created and the edges representing responsibility relationships in the organizational relationship diagram; and determining the user's implicit permissions based on the set of permissions for the backup node, resource access permissions, and information preview permissions.

[0094] In some optional implementations of this embodiment, the risk perception module in the task generation unit 702 includes: determining a time sensitivity coefficient based on the relationship between the input time of the fuzzy task information and key nodes in the financial cycle; determining the payment request risk level based on the estimated amount in the fuzzy task information and the user's historical payment request records; determining the supplier risk based on the supplier in the fuzzy task information; determining an abnormal access score by comparing the current access geolocation, device fingerprint, and the user's historical access patterns; and aggregating the time sensitivity coefficient, payment request risk level, supplier risk, and abnormal access score through a preset risk aggregation model to output a risk perception value.

[0095] In some optional implementations of this embodiment, the financial task review device 700 based on a large model further includes: a business process determination unit, configured to use the large model to determine the associated business process corresponding to the payment request task to be reviewed in a preset business process library; wherein, the associated business process refers to other business process links in a complete business chain that are logically related to the business links corresponding to the payment request task to be reviewed; a review material determination unit, configured to determine the review material information related to the payment request task to be reviewed according to the target review rules; a review information verification unit, configured to verify other review information in response to other review information included in the review material information that is involved in other business process links in the complete business chain that are located before the payment request task to be reviewed; and a completion task creation unit, configured to create other information completion tasks and notify the task handlers corresponding to the other review information to complete the other review information in response to the occurrence of abnormalities in other review information.

[0096] In some optional implementations of this embodiment, the financial task auditing device 700 based on a large model further includes a descriptor optimization unit. The descriptor optimization unit includes: obtaining manual confirmation feedback of audit results, historical hit effect data of target audit rules, and descriptions of newly emerging financial audit scenarios; based on manual confirmation feedback, identifying violation feature descriptions that actually exist in the pending payment request task but are not covered by the first key descriptor, and generating candidate key descriptors; based on historical hit effect data, performing at least one of the following optimization operations on the key descriptors in the preset key descriptor set: semantically focusing or splitting key descriptors with ambiguous matching, downgrading or archiving key descriptors that have not been hit for a long time, and redefining key descriptors with low success rates in association rule audits; performing association matching verification between the optimized key descriptors and the newly emerging financial audit scenario descriptions, and updating the verified key descriptors to the preset key descriptor set.

[0097] In some optional implementations of this embodiment, the task review unit 704 in the financial task review device 700 based on a large model includes: assembling structured prompt information based on the content of the target review rules and the task information of the payment request task to be reviewed. The structured prompt information includes at least the following sequentially concatenated parts: a role definition part, used to assign a specific identity related to financial review to the large model; a rule injection part, derived from the target review rules, used to inject specific review basis into the large model; a task context part, extracted from key information in the payment request task to be reviewed, used to provide the large model with the factual background required for review; and an output specification part, used to constrain the specific format and structure of the review results output by the large model. The structured prompt information and the complete content of the payment request task to be reviewed are input into the large model to instruct the large model to complete the review reasoning based on the guidance of the prompt information, and obtain the review results that meet the requirements of the output specification part.

[0098] In some optional implementations of this embodiment, the financial task auditing device 700 based on a large model further includes an audit graph construction unit. The audit graph construction unit includes: generating and displaying audit process visualization information in response to audit completion; wherein, the generation of audit process visualization information includes: constructing and displaying an audit tracing graph based on the original data of the payment request task to be audited, the intermediate inference data during the large model's audit execution, and the audit results; wherein, the audit tracing graph is presented in an interactive graph structure, and its nodes include at least input nodes representing original data, trigger nodes representing rule matching, intermediate nodes representing different inference steps, and output nodes representing the final conclusion, and its edges are used to represent logical deduction, evidence support, or temporal relationships between nodes.

[0099] This embodiment exists as a device embodiment corresponding to the above method embodiment. The financial task review device based on a large model provided in this embodiment first obtains the fuzzy task information entered by the user on the remittance interface; then, it uses a preset large model to search for related remittance information corresponding to the fuzzy task information within the user's corresponding permission boundaries, and uses the large model to generate a remittance task to be reviewed based on the target remittance information selected by the user in the related remittance information. By introducing permission boundaries, the system can safely and intelligently transform the user's fuzzy and informal task intentions into standardized remittance tasks to be reviewed; next, it uses the large model to extract the first key descriptor from the remittance task to be reviewed, and determines the second key descriptor in the preset key descriptor set that matches the first key descriptor as the key prompt word, and determines the target review rule corresponding to the key prompt word; finally, it uses the large model to review the remittance task to be reviewed according to the prompt information corresponding to the target review rule, and obtains the review result. Through the precise matching of key descriptors and predefined review rules, complex business rules are transformed into prompt information that the large model can execute, thereby driving the large model to simulate experts to complete automated review. This embodiment realizes an integrated process from intent understanding, access control, rule adaptation to intelligent decision-making, which significantly improves the intelligence level, security and interpretability of financial task processing, and improves the accuracy and efficiency of financial data auditing.

[0100] According to embodiments of this disclosure, this disclosure also provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to implement the large-model-based financial task auditing method described in any of the above embodiments.

[0101] According to embodiments of this disclosure, this disclosure also provides a readable storage medium storing computer instructions that, when executed by a computer, enable the implementation of the large-model-based financial task auditing method described in any of the above embodiments.

[0102] According to embodiments of this disclosure, this disclosure also provides a computer program product that, when executed by a processor, can implement the financial task auditing method based on a large model as described in any of the above embodiments.

[0103] Figure 8A schematic block diagram of an exemplary electronic device 800 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0104] like Figure 8 As shown, the electronic device 800 includes a computing unit 801, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 802 or a computer program loaded from a storage unit 808 into a random access memory (RAM) 803. The RAM 803 may also store various programs and data required for the operation of the electronic device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0105] Multiple components in electronic device 800 are connected to I / O interface 805, including: input unit 806, such as keyboard, mouse, etc.; output unit 807, such as various types of displays, speakers, etc.; storage unit 808, such as disk, optical disk, etc.; and communication unit 809, such as network card, modem, wireless transceiver, etc. Communication unit 809 allows electronic device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0106] The computing unit 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as a large-model-based financial task auditing method. For example, in some embodiments, the large-model-based financial task auditing method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 800 via ROM 802 and / or communication unit 809. When the computer program is loaded into RAM 803 and executed by the computing unit 801, one or more steps of the large-model-based financial task auditing method described above can be performed. Alternatively, in other embodiments, the computing unit 801 may be configured, by any other suitable means (e.g., by means of firmware), to perform a financial task auditing method based on a large model.

[0107] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0108] Program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0109] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0110] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0111] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0112] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and Virtual Private Server (VPS) services, such as high management difficulty and weak business scalability.

[0113] According to the technical solution of this disclosure, the financial task review method based on a large model provided in this disclosure first obtains the fuzzy task information entered by the user on the remittance interface; then, using a preset large model, it searches for related remittance information corresponding to the fuzzy task information within the user's corresponding permission boundaries, and uses the large model to generate a remittance task to be reviewed based on the target remittance information selected by the user in the related remittance information. By introducing permission boundaries, the system can safely and intelligently transform the user's fuzzy and informal task intentions into standardized remittance tasks to be reviewed; next, it uses the large model to extract a first key descriptor from the remittance task to be reviewed, and determines a second key descriptor matching the first key descriptor in the preset key descriptor set as a key prompt word, and determines the target review rule corresponding to the key prompt word; finally, it uses the large model to review the remittance task to be reviewed according to the prompt information corresponding to the target review rule, and obtains the review result. Through the precise matching of key descriptors and predefined review rules, complex business rules are transformed into prompt information that the large model can execute, thereby driving the large model to simulate experts to complete automated review. This embodiment realizes an integrated process from intent understanding, access control, rule adaptation to intelligent decision-making, which significantly improves the intelligence level, security and interpretability of financial task processing, and improves the accuracy and efficiency of financial data auditing.

[0114] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0115] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A large model-based financial task auditing method, characterized in that, The method comprises the following steps: obtaining fuzzy task information input by a user in a request interface; searching, by using a preset large model, associated request information corresponding to the fuzzy task information within a permission boundary corresponding to the user, and generating a to-be-audited request task based on target request information selected by the user in the associated request information by using the large model; wherein the permission boundary is determined based on a real-time trust evaluation value of the user, an implicit permission derived from an organizational topology relationship, and a risk perception value of a current task context; extracting, by using the large model, a first key description word from the to-be-audited request task, determining a second key description word matching the first key description word in a preset key description word set as a key prompt word, and determining a target audit rule corresponding to the key prompt word; wherein a correspondence relationship between different key prompt words and different audit rules is recorded in advance, and the audit rule comprises a plurality of audit actions and an execution time sequence between different audit actions; auditing, by using the large model, the to-be-audited request task according to prompt information corresponding to the target audit rule, and obtaining an audit result.

2. The method of claim 1, wherein, The method comprises the following steps: obtaining fuzzy task information input by a user in a request interface; obtaining a plurality of fuzzy task search words input by the user in the request interface; determining a search priority according to sorting information of each fuzzy task search word by the user; determining a confidence degree of each fuzzy task search word according to a probability value supplement operation of each fuzzy task search word by the user; wherein the fuzzy task information comprises a plurality of fuzzy task search words, the search priority, and the confidence degree; correspondingly, the method comprises the following steps: determining the permission boundary based on the real-time trust evaluation value, the implicit permission, and the risk perception value, and determining a corresponding target information pool according to the permission boundary; searching, by using the large model, each fuzzy task search word in the target information pool according to a search order determined by the search priority in a corresponding confidence degree in sequence, and obtaining sub-associated request information corresponding to each fuzzy task search word in sequence; wherein different confidence degrees correspond to different search methods, and a confidence degree exceeding a preset confidence threshold is subjected to accurate search, and a confidence degree not exceeding the preset confidence threshold is subjected to fuzzy search; 3. The method of claim 2, wherein, aggregating, by using the large model, each sub-associated request information to obtain associated request information corresponding to the fuzzy task information. The method comprises the following steps: determining the real-time trust evaluation value of the user based on a historical operation behavior sequence of the user and a current compliance risk of an associated user; determining the implicit permission of the user based on a report relationship and a business process context of the user determined by an organizational relationship diagram; wherein the organizational relationship diagram is composed of nodes of users, departments, projects, and costs, and edges connecting different nodes according to management, participation, and responsibility relationships. determine the risk perception value based on at least one of time, estimated amount, supplier, access geographical location and device fingerprint contained in the fuzzy task information; determine the permission boundary based on the real-time trust evaluation value, the implicit permission and the risk perception value.

4. The method of claim 3, wherein, The determining the implicit permission of the user based on the organizational relationship graph includes: in response to detecting that the direct superior of the user is in an inaccessible state, determining a backup node capable of temporarily replacing the direct superior and a permission set of the backup node according to an edge representing a management relationship in the organizational relationship graph; in response to the fuzzy task information being associated with a preset project, determining a project role of the user in the preset project according to an edge representing a participation relationship in the organizational relationship graph, and determining a resource access permission related to a project context according to the project role; determining that the user can inherit an information preview permission from a subsequent node according to a business process stage in which the to-be-created task is currently located and an edge representing a responsible relationship in the organizational relationship graph; determining the implicit permission of the user according to the permission set of the backup node, the resource access permission and the information preview permission.

5. The method of claim 3, wherein, The determining the risk perception value based on at least one of time, estimated amount, supplier, access geographical location and device fingerprint contained in the fuzzy task information includes: determining a time sensitivity coefficient according to a relationship between an input time of the fuzzy task information and a key node of a financial period; determining a reimbursement risk level according to an estimated amount in the fuzzy task information and a historical reimbursement record of the user; determining a supplier risk according to a supplier in the fuzzy task information; determining an abnormal access score by comparing a current access geographical location, a device fingerprint and a historical access pattern of the user; aggregating the time sensitivity coefficient, the reimbursement risk level, the supplier risk and the abnormal access score through a preset risk aggregation model to output the risk perception value.

6. The method of claim 1, wherein, Further comprising: determining an associated business process corresponding to the to-be-audited reimbursement task in a preset business process library by using the large model; wherein the associated business process refers to other business process links in a complete business chain that are logically associated with the business link corresponding to the to-be-audited reimbursement task; determining audit material information related to the to-be-audited reimbursement task according to the target audit rule; in response to the audit material information containing other audit information related to other business process links located before the to-be-audited reimbursement task in the complete business chain, checking the other audit information; in response to the other audit information being abnormal, creating an other information completion task and notifying a task handler corresponding to the other audit information to complete the other audit information.

7. The method of claim 1, wherein, Further comprising: obtaining manual confirmation feedback of the audit result, historical hit effect data of the target audit rule, and newly appeared financial audit scene description; Based on the manual confirmation feedback, a rule feature description actually existing but not covered by the first key description word in the to-be-audited payment request task is identified, and a candidate key description word is generated; Based on the historical hit effect data, at least one optimization operation is performed on the key description words existing in the preset key description word set: semantic focusing or splitting is performed on the matching ambiguous key description words, the weight of the key description words that have not been hit for a long time is reduced or archived, and the key description words with low associated rule audit success rate are redefined; The optimized key description words are associated and matched with the newly emerging financial audit scene description, and the key description words that pass the verification are updated to the preset key description word set.

8. The method of claim 1, wherein, The use of the large model to audit the to-be-audited payment request task according to the prompt information corresponding to the target audit rule to obtain an audit result, includes: Based on the content of the target audit rule and the task information of the to-be-audited payment request task, a structured prompt information is assembled, which at least includes the following parts spliced in sequence: a role definition part for giving the large model a specific identity related to financial audit; a rule injection part derived from the target audit rule for injecting specific audit basis into the large model; a task context part formed by extracting key information from the to-be-audited payment request task for providing the large model with factual background required for auditing; and an output specification part for constraining the specific format and structure of the output audit result of the large model; The structured prompt information and the complete content of the to-be-audited payment request task are input into the large model to instruct the large model to complete the audit reasoning based on the guidance of the prompt information, and an output audit result meeting the requirements of the output specification part is obtained.

9. The method of any one of claims 1-8, comprising: in response to the completion of the audit, generating and displaying audit process visualization information; wherein the generation of the audit process visualization information comprises: based on the original data of the to-be-audited payment request task, the intermediate reasoning data when the large model performs the audit, and the audit result, an audit traceability graph is constructed and displayed; wherein the audit traceability graph is presented in an interactive graph structure, and the nodes thereof at least include an input node representing original data, a trigger node representing rule matching, intermediate nodes representing different reasoning steps, and an output node representing a final conclusion, and the edges thereof are used to represent the logical derivation, evidence support, or time sequence relationship between the nodes.

10. An electronic device, comprising: at least one processor; and a memory communicatively connected with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the large model-based financial task auditing method of any one of claims 1-9.

Images