Large model-based financial task auditing method and apparatus

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

(19) State Intellectual Property Office (12) Invention Patent Application (10) Application Publication Number (43) Application Publication Date (21) Application Number 202610195428.9 (22) Application Date 2026.02.10 (71) Applicant: Chia Tai Tianqing Pharmaceutical Group Co., Ltd. Address: No. 369, Yuzhou South Road, Lianyungang City, Jiangsu Province, 222062 (72) Inventors: Xie Chengrun, Cao Fenze, Wu Zhaoxuan, Zhang Peng (51) Int.Cl. G06Q 40 / 12 (2023.01) G06F 16 / 242 (2019.01) G06F 16 / 2455 (2019.01) G06F 16 / 2458 (2019.01) G06N 5 / 04 (2023.01) (54) Invention Title: A Financial Task Audit Method and Device Based on a Large Model (57) Abstract: This disclosure provides a financial task audit method and device based on a large model, relating to the field of digital processing technology, specifically to the field of large models and intelligent agents. The method includes: acquiring fuzzy task information input by a user on a payment request interface; using 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 using the large model to generate a payment request task to be audited based on the target payment request information selected by the user in the related payment request information; using the large model to extract a first key descriptor from the payment request task to be audited, 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 the target audit rule corresponding to the key prompt word; using the large model to audit the payment request task to be audited according to the prompt information corresponding to the target audit rule, and obtaining the audit result. This method improves the accuracy and efficiency of financial data auditing. Claims 3 pages, Description 21 pages, Drawings 6 pages, CN 121685183 A 2026.03.17 CN 1 21 68 51 83 A 1. A financial task review method based on a large model, characterized in that it includes: obtaining fuzzy task information input by a user on a request interface; using a preset large model to search for related request information corresponding to the fuzzy task information within the user's corresponding permission boundary, and using the large model to generate a request task to be reviewed based on the target request information selected by the user in the related request information; wherein, the permission boundary is 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 request 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 that it is related to the first key descriptor.The method is described in the following way: 1. The method is described in the following way: 2. The method is described in the following way: 3. The method is described in the following way: 4. The method is described in the following way: 5. The method is described in the following way: 6. The method is described in the following way: 7. The method is described in the following way: 8. The method is described in the following way: 9. The method is described in the following way: 10. The method is described in the following way: 11. The method is described in the following way: 12. The method is described in the following way: 13. The method is described in the following way: 14. The method is described in the following way: 15. The method is described in the following way: 16. The method is described in the following way: 17. The method is described in the following way: 18. The method is described in the following way: 19. The method is described in the following way: 10. The method is described in the following way: 19 ... Using the large model, the search is performed sequentially in the target information pool using the fuzzy task search terms according to the search priority and the search order determined by the search priority. This sequentially yields sub-related payment requests corresponding to each fuzzy task search term. Different confidence levels correspond to different search methods: a precise search is used when the confidence level exceeds a preset confidence threshold, while a fuzzy search is used when the confidence level does not exceed the preset confidence threshold. The large model is then used to aggregate the sub-related payment requests to obtain the related payment requests corresponding to the fuzzy task information. 3. The method according to claim 2, characterized in that, determining the permission boundary based on the real-time trust assessment value, the implicit permissions, and the risk perception value includes: 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; determining the user's implicit permissions based on the organizational relationship diagram to determine the user's reporting relationship and business process context; wherein, the organizational relationship diagram is composed of nodes acting as users, departments, projects, and costs, and edges connecting different nodes constructed according to management, participation, and responsibility relationships; 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; and determining the permission boundary based on the real-time trust assessment value, the implicit permissions, and the risk perception value. Claims 1 / 3 Page 2 CN 121685183 A 4. The method according to claim 3, characterized in that, determining the user's implicit permissions based on the organizational relationship diagram...The implicit permissions of the user are determined by reporting relationships and business process context, including: 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 the permission set of the backup node based on the edges representing management relationships in the organizational relationship diagram; In response to the 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 permission 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; Determining the user's implicit permissions based on the permission set of the backup node, the resource access permissions, and the information preview permissions. 5. The method according to claim 3, characterized in that, determining the risk perception value based on at least one of time, estimated amount, supplier, access geolocation, and device fingerprint contained in the fuzzy task information 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 a payment request risk level based on the estimated amount in the fuzzy task information and the user's historical payment request records; determining 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, the payment request 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 according to claim 1, characterized in that it further comprises: using the large model to determine the associated business process corresponding to the pending payment request task 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 pending payment request task; determining the audit material information related to auditing the pending payment request task according to the target audit rule; in response to the audit material information containing other audit information involved in other business process links in the complete business chain that are located before the pending payment request task, verifying the other audit information; in response to the other audit information being abnormal, creating an other information completion task and notifying the task handler corresponding to the other audit information to complete the other audit information. 7. The method according to claim 1, characterized in that it further comprises: obtaining the manual confirmation feedback of the audit result, the historical hit effect data of the target audit rule, and the description of newly emerging financial audit scenarios; based on the manual confirmation feedback, identifying the actual but not described by the first key description in the pending payment request task.The violation features covered by the predicate are described to generate candidate key descriptors; based on the historical hit effect data, at least one of the following optimization operations are performed on the key descriptors in the preset key descriptor set: semantic focusing or splitting of 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 of association rule review; the optimized key descriptors are matched and verified with the newly emerging financial audit scenario description, and the key descriptors that pass the verification are updated to the preset key descriptor set. 8. The method according to claim 1, characterized in that, the step of using the large model to review the pending payment request task according to the prompt information corresponding to the target review rule, and obtaining the review result, includes: assembling structured prompt information based on the content of the target review rule and the task information of the pending payment request task, wherein 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 rule, used to inject specific review basis into the large model; a task context part, extracted from key information in the pending payment request task, 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 result output by the large model; inputting the structured prompt information and the complete content of the pending payment request task together into the large model to instruct the large model to complete the review reasoning based on the guidance of the prompt information, and obtaining the output review result that meets the requirements of the output specification part. 9. The method according to any one of claims 1-8, comprising: generating and displaying audit process visualization information in response to audit completion; wherein the generation of the audit process visualization information comprises: constructing and displaying an audit tracing graph based on the original data of the pending audit request task, the intermediate inference data during the large model audit, and the audit result; wherein the audit tracing graph is presented in an interactive graph structure, its nodes including 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 being used to represent logical deduction, evidence support, or temporal relationships between nodes. 10. 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 execute the financial task audit method based on a large model according to any one of claims 1-9. ClaimsPage 3 / 3 4 CN 121685183 A Financial Task Audit Method and Equipment Based on Large Model 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 particularly to a financial task audit method and equipment based on a large model. Background Technology

[0002] In the current digital age, intelligent financial audit technology, relying on 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 audit efficiency. In addition, intelligent audit technology can reduce human intervention, reduce human error, and ensure the accuracy and compliance of financial information. At the same time, AI can also continuously learn, optimize the audit process, provide real-time data insights, help enterprises make more accurate decisions, and thus improve the overall level of financial management. Summary of the Invention

[0003] The embodiments of this disclosure propose a financial task audit and electronic device based on a large model, which improves the accuracy and efficiency of financial data audit.

[0004] In a first aspect, embodiments of this disclosure propose a financial task review method based on a large model, comprising: obtaining fuzzy task information input by a user on a request interface; using a preset large model to search for associated request information corresponding to the fuzzy task information within the user's corresponding permission boundaries, and using 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; using the large model to extract a first key descriptor from the request 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 request task to be reviewed according to the prompt information corresponding to the target review rule, and obtaining the review result.

[0005] In a second aspect, embodiments of this disclosure propose 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 reimbursement interface; and a task generation unit configured to use a preset large model to search for associated reimbursement information corresponding to the fuzzy task information within the user's corresponding permission boundaries, and to use 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 based on the user's real-time trust assessment value, implicit permissions derived from organizational topology, and the current task context.The risk perception value is determined comprehensively; the rule determination unit is configured to extract the first key descriptor from the pending payment request task using the large model, and determine the second key descriptor matching the first key descriptor in the preset key descriptor set as the key prompt word, and determine the target audit rule corresponding to the key prompt word; wherein, the correspondence between different key prompt words and different audit rules is pre-recorded, and the audit rules include: multiple audit actions and the execution sequence between different audit actions; the task audit unit is configured to audit the pending payment request task according to the prompt information corresponding to the target audit rule using the large model, and obtain the audit result.

[0006] In a third aspect, embodiments of this disclosure provide an electronic device, which includes: at least one processor; and a memory communicatively connected to at least one processor; wherein, the memory stores instructions executable by at least one processor, which are executed by at least one processor to enable the financial task audit method based on the large model as described in the first aspect when executed by at least one processor.

[0007] In a fourth aspect, embodiments of the present disclosure provide a non-transitory computer-readable storage medium storing computer instructions that, when executed by a computer, enable the implementation of the large-model-based financial task auditing method as described in the first aspect.

[0008] In a fifth aspect, embodiments of the present disclosure provide a computer program product including a computer program that, when executed by a processor, enables the implementation of the steps of the large-model-based financial task auditing method as described in the first aspect.

[0009] It should be understood that the content described in this section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become readily apparent from the following 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 1 is an exemplary system architecture to which this disclosure can be applied; Figure 2 is a flowchart of a financial task auditing method based on a large model provided by an embodiment of this disclosure; Figure 3 is a flowchart of a method for determining corresponding related reimbursement information based on acquired fuzzy task information provided by an embodiment of this disclosure; Figure 4 is a flowchart of a method for supplementing audit material information related to a reimbursement task to be audited provided by an embodiment of this disclosure; Figure 5 is a flowchart of a method for optimizing and updating key descriptive terms provided by an embodiment of this disclosure; Figure 6 is a flowchart of a method for an instruction large model to output audit results based on prompt information provided by an embodiment of this disclosure; Figure 7 is a structural block diagram of an apparatus for an instruction large model to output audit results based on prompt information provided by an embodiment of this disclosure;Figure 8 is a schematic diagram of the structure of an electronic device suitable for performing a financial task auditing method based on a large model, provided by an embodiment of this disclosure. Detailed Description

[0011] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments of this disclosure to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art should 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, without conflict, the embodiments and features in the embodiments of this disclosure can be combined with each other.

[0012] In the technical solutions of this disclosure, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0013] Figure 1 shows an exemplary system architecture 100 of an embodiment of the financial task auditing method and electronic device based on a large model of this disclosure that can be applied. Specification 2 / 21 pages 6 CN 121685183 A

[0014] As shown in FIG1, the exemplary system architecture 100 may include terminal devices 101, 102, 103, network 104, and server 105. Network 104 is used as a medium to provide a communication link between terminal devices 101, 102, 103, and server 105. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

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

[0016] Terminal devices 101, 102, 103, and server 105 can be 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, without specific limitations. 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 is software, it can be implemented as multiple software programs or software modules, or as a single software program or software module, without specific limitations.

[0017] Server 105 can provide various services through its built-in applications. Taking a financial auditing application as an example, which can generate and review 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. The large model is used to generate a pending payment request task based on the target payment request information selected by the user in the associated payment request information. The permission boundary is determined by combining the user's real-time trust assessment value, the implicit permissions derived from the organizational topology relationship, and the risk perception value of the current task context. Then, the large model is used to extract the first key descriptor from the pending payment request task, 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. The correspondence between different key prompt words and different review rules is recorded in advance. 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 the fuzzy task information can be obtained from the terminal devices 101, 102, and 103 through the network 104, or it can be stored in advance on the local server 105 in various ways. Therefore, when server 105 detects that this data is already stored locally (e.g., when it starts processing previously retained financial audit tasks), it can choose to directly retrieve this data from the local storage. In this case, the exemplary system architecture 100 may not include terminal devices 101, 102, 103 and network 104.

[0019] Since generating and auditing pending payment requests based on fuzzy task information input by the user requires a lot of computing resources and strong computing power, the financial task auditing method based on a large model provided in the subsequent embodiments of this disclosure is generally executed by server 105, which has strong computing power and a lot of computing resources. Correspondingly, the financial task auditing device based on a large model is also generally set in server 105. However, it should also be noted that when terminal devices 101, 102, and 103 also have sufficient computing power and computing resources, terminal devices 101, 102, and 103 can also complete the various calculations that are performed by server 105 through the financial auditing applications installed on them, and thus output the same results as server 105. Especially when multiple terminal devices with different computing capabilities exist simultaneously, but the financial auditing application determines that the terminal device it is using has strong computing power and a large amount of remaining computing resources, it can allow the terminal device to...To perform the above calculations, thereby appropriately reducing the computational pressure on server 105, the financial task auditing device based on the large model can also be set in terminal devices 101, 102, and 103. In this case, the exemplary system architecture 100 may also exclude server 105 and network 104.

[0020] It should be understood that the number of terminal devices, networks, and servers in FIG1 is merely illustrative. Depending on the implementation needs, there can be any number of terminal devices, networks, and servers.

[0021] Please refer to FIG2, which is a flowchart of a financial task auditing method based on a large model provided in an embodiment of the present disclosure, wherein process 200 includes the following steps: Step 201: Obtain fuzzy task information entered by the user in the request interface; This step is intended for the execution subject of the financial task auditing method based on the large model (e.g., server 105 shown in FIG1) to obtain the fuzzy task information entered by the user in the request interface. The payment request interface includes 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 out obviously invalid characters (such as special code symbols). Fuzzy task information refers to task descriptions entered by users on the payment request interface that do not fully conform to the precise format or complete semantics required by traditional systems. This means allowing users to initiate tasks using natural language fragments, unstructured keywords (e.g., "Labor fees for supplier A last week"), or statements lacking key fields (e.g., only entering the amount range without specifying the contract number).

[0022] Step 202: Use a preset large model to search for related payment requests corresponding to the fuzzy task information within the user's corresponding permission boundaries, and use the large model 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; In this embodiment, the executing entity uses a preset large model to search for related payment requests corresponding to the 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 mode based on static roles (such as "department manager"). The permissions 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. The real-time trust assessment value is generated by analyzing dynamic indicators such as the user's recent operation compliance rate and login behavior patterns. Implicit permissions can be derived based on a preset organizational relationship graph, combined with the user's department, project affiliation, and position in the business process. The risk perception value can be assessed based on sensitive elements (such as amount and supplier) in the fuzzy task information. Related payment requests refer to the information obtained by the large model from historical payment request records through semantic matching within the data range defined by the permission boundaries.And / or candidate datasets selected from a pre-defined list of payment requests.

[0023] In this embodiment, the executing entity uses a large model to generate a payment request task to be reviewed based on the target payment request information selected by the user in 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 in the target payment request information, and automatically associates supplementary data based on the identifier fields to output a structured payment request task to be reviewed.

[0024] Step 203: Use the large model to extract the first key descriptor from the payment request task to be reviewed, and determine the second key descriptor in the pre-defined set of key descriptors that matches the first key descriptor as a 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 the first key descriptor from the payment request task to be reviewed, and determines the second key descriptor in the pre-defined set of key descriptors that matches the first key descriptor as a key prompt word, and determines the target review rule corresponding to the key prompt word. The first descriptive keyword refers to the semantic unit extracted from the pending payment request task that can represent 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 and extracts the high-dimensional features associated with the review rules. For example, "Payment type name: Team building instruction manual 4 / 21 pages 8 CN 121685183 A" 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 uses the large model to vectorize the first key descriptive word, and then retrieves the second key descriptive word with the highest similarity from the 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 term 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 failure due to user input ambiguity (such as "expert lecture fee" and "expert labor").

[0026] Step 204: 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.

[0027] In this embodiment, the executing entity uses the large model to review the payment request task to be reviewed according to the prompt information corresponding to the target review rule, and obtains the review result. Among them, the target review rule is a predefined set of review logic, which includesMultiple audit actions (such as "verifying contract validity" and "checking invoice authenticity") and their execution sequence (the order in which the actions occur) essentially ensure the rigor of the audit logic through temporal constraints. For example, contract validity must be verified before invoice amount checks to avoid risk control loopholes caused by disordered action order. The prompts are the core instructions driving the large-scale model to execute audits; they can transform rule clauses into contextual instructions that the large-scale model can understand.

[0028] In this embodiment, the executing entity first obtains the audit actions and execution sequence of the target audit 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 audit actions, execution sequence and factual data are integrated to construct a structured prompt information; the prompt information and the pending audit task are submitted to the large model, which will consider the rules contained in the prompt information one by one, look for supporting or violated evidence in the factual data, weigh the importance of different information through its internal attention mechanism and other components, and finally generate a natural text that meets the output format requirements as the audit result. The audit result usually includes an overall audit 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, so that the audit result is interpretable.

[0029] In this embodiment, various strategies can be used to construct the prompt information. 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 the prompts can incorporate optimization mechanisms. For example, based on feedback from human reviewers regarding the model's reasoning chain in 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 embodiment first obtains the fuzzy task information input 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.The system identifies key prompts and determines the corresponding target audit rules. Finally, a large-scale model is used to audit the payment requests according to the prompts corresponding to the target audit rules, yielding audit results. Through precise matching of key descriptive words with predefined audit rules (page 5 / 21, CN 121685183 A), complex business rules are transformed into executable prompts for the large-scale model, thereby driving the model to simulate experts and complete automated audits. This embodiment achieves an integrated process from intent understanding, access control, rule adaptation to intelligent decision-making, significantly improving the intelligence, security, and interpretability of financial task processing, and enhancing 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 related payment request information, please refer to Figure 3. Figure 3 is a flowchart of a method for determining the corresponding related payment request information based on the obtained fuzzy task information provided by an embodiment of this disclosure. It aims to provide a specific implementation method for determining the corresponding related payment request information based on the obtained fuzzy task information. The 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 obtains multiple fuzzy task search terms entered by the user on the payment request interface. Specifically, the user expresses their payment request intention by entering unstructured natural language or keyword fragments on the payment request 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". These phrases together constitute a fragmented description of their fuzzy request.

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

[0033] Step 303: 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; In this embodiment, the execution entity determines the confidence level of each fuzzy task search term based on the user's probability value supplementation operation for each fuzzy task search term.The confidence level of each fuzzy task search term. 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. Users 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 executing 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 independently determined for each term at this moment, preparing data for subsequent processing.

[0035] Step 304: Determine the permission boundary based on the real-time trust assessment value, implicit permissions, and risk perception value, and determine the corresponding target information pool according to the permission boundary; In this embodiment, the executing entity determines the permission boundary based on the real-time trust assessment value, implicit permissions, and risk perception value, and determines the corresponding target information pool according to the permission boundary. Among them, the real-time trust assessment value is generated by analyzing dynamic indicators such as the user's recent operation compliance rate and login behavior pattern; the implicit permissions can be derived based on the preset organizational relationship map, combined with the user's department, project affiliation, and position in the business process; the risk perception value can be based on the sensitive elements (such as amount, supplier) in the fuzzy task information for risk assessment. The essence of the permission boundary is a set of rules in the Access Control Specification (6 / 21 pages, 10 CN 121685183 A). It integrates three dimensions: real-time trust assessment value, implicit permissions, and risk perception value, taking into account user identity, historical behavior, organizational context, and current operational risks. This is used to filter and limit the scope of accessible data, thereby determining a secure target information pool, such as containing only the user's department and historical requisition records for projects they have participated in.

[0036] In this embodiment, the execution entity determining the corresponding target information pool based on the permission boundary is a data filtering and mapping process. Specifically, the execution entity maintains multiple logically or physically isolated data sets (e.g., requisition record databases divided by department, project, or security level). Using the permission boundary as input, 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 user with high trust and low risk may be granted access to cross-project data pools, while queries with high risk perception values ​​may be strictly limited 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 as audited), it may mean that there is a potential risk in the shared process or project, 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 implicit permissions. 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; determining the risk perception value based on at least one of the following contained in the fuzzy task information: time, estimated amount, supplier, access geographical location, and device fingerprint. The determination of the risk perception value is a feature extraction and risk assessment process, which can parse features such as "time" from the fuzzy task information. Multiple risk characteristics are considered, such as whether the closing date is approaching, whether the "estimated amount" is abnormally high, whether the "supplier" is on a blacklist, and whether the "access location" or "device fingerprint" is inconsistent with common patterns. Based on real-time trust assessment values, implicit permissions, and risk perception values, permission boundaries are determined. 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 boundaries according to preset fusion rules (e.g., "high trust can moderately relax risk restrictions, but high risk must strictly restrict permissions"). This boundary may be expressed as a set of filtering conditions that can be directly understood by the data access layer, such as "allow access to departments A and B, and project X, and the amount screening threshold does not exceed 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 trust, 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, during the process of determining the permission boundary based on real-time trust assessment values, implicit permissions, and risk perception values, the weights of the three dimensions are not fixed but can be adjusted according to the business category to which the current task belongs (e.g., ...).The "travel expense reimbursement" and "asset procurement" are dynamically adjusted. In the procurement scenario, more emphasis is placed on supplier risk, while in the travel scenario, more attention is paid to the anomalies of 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 relationship diagram, and determines the user's implicit permissions. Specifically, in response to the detection that the user's direct superior is in an inaccessible state, the entity determines the backup nodes that can temporarily replace the direct superior and the set of permissions of the backup nodes according to the edges representing the management relationship in the organizational relationship diagram. 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 the fuzzy task information being associated with a preset project, the entity determines the user's project role in the preset project according to the edges representing the participation relationship in the organizational relationship diagram, and determines the resource access permissions related to the project context according to the project role. That is, according to 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 exclusive budget details, historical contracts, or specific supplier list. Based on the current business process stage of the task to be created and the edges representing the responsibility relationship in the organizational relationship diagram, the information preview permission that the user can inherit from subsequent nodes is determined; based on the permission set, resource access permission, and information preview permission of the backup node, the user's implicit permissions are determined. This embodiment, by performing graph modeling of entities and relationships within the organization, dynamically calculates the user's implicit permissions by traversing specific relationship edges between nodes in the graph in real time and combining the current specific business context, thereby capturing the unwritten, contextualized allocation logic of rights and responsibilities that exists extensively in the actual operation of enterprises.

[0040] In this embodiment, when determining backup nodes, in addition to following the management relationship chain, the executing entity can also introduce priority evaluation, comprehensively considering factors such as the current workload of the node and the closeness of collaboration with the current user to select the optimal backup node. For permissions determined by project roles, they can be further subdivided to the task level, so that users have differentiated data operation permissions in different project tasks. The scope of information preview permissions can also be dynamically graded and controlled, for example, the level of detail of the information that can be previewed can be determined based on the user's real-time trust evaluation value. These mechanisms work 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 contained in the fuzzy task information: time, estimated amount, supplier, access geolocation, and device fingerprint. Specifically, based on the input of the fuzzy task information...The relationship between time and key nodes in the financial cycle is analyzed to determine the time sensitivity coefficient. For example, a high-amount payment request initiated in the last hour before closing will have its time sensitivity coefficient increased because it may indicate 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 is calculated, or whether it exceeds the conventional approval threshold corresponding to the user's role, 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 these deviations occurs, 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 interrelationship of each indicator, and finally output a unified and standardized "risk perception value". This value can be a score, a level (high, medium, low), or a probability, providing direct input on the degree of danger of the current operation request itself for subsequent determination of "permission boundaries". This embodiment establishes and calculates multiple independent feature risk indicators in parallel, and then performs a comprehensive evaluation through an aggregation model, which can capture complex risk patterns more comprehensively and robustly, and avoid defense vulnerabilities caused by misjudgment of a single indicator.

[0042] In this embodiment, the judgment threshold of abnormal access scoring can be temporarily adjusted according to the user's recent business trip plan or equipment replacement notification to reduce false alarms. The risk aggregation model can be learned online. When subsequent manual review confirms that the system did not accurately warn of real high-risk cases, or overturns the system's false alarms, this feedback data can be used to fine-tune the aggregation weights of the model, so that the entire risk perception system can continuously evolve with the changes in the enterprise's security situation, improving its prediction accuracy and business adaptability.

[0043] Step 305: Using the large model, search in the target information pool according to the search order determined by the search priority, and search with the corresponding confidence level using each fuzzy task search term, 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: a precise search is used when the confidence level exceeds a preset confidence threshold, and a fuzzy search is used when the confidence level does not exceed the preset confidence threshold.

[0044] In this example, the precise search and fuzzy search can be further subdivided into multiple levels, dynamically linked to the specific numerical range of the confidence level, rather than simply comparing with a fixed threshold. Furthermore, a feedback mechanism can be introduced into the search process, that is, the search range or confidence threshold of subsequent terms can be dynamically adjusted based on the quantity and quality of the search results of the previous high-priority term. For example, if the first high-confidence term returns too few results, the system can automatically lower the confidence judgment standard of subsequent terms and use more fuzzy search to try to obtain more relevant clues. This strategic multi-round retrieval mechanism allows the information discovery process to focus on key points while also having the flexibility to cope with uncertainty.

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

[0046] In this example, the executing entity uses the large model to summarize the sub-related reimbursement information 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 summarizes the information of each sub-related reimbursement request, in addition to analyzing the sub-related reimbursement request information itself, it can also refer to the search priority in the fuzzy task information and give higher retention weight or higher ranking to the results from high-priority search terms. In addition, the summarization logic can be designed to be configurable, for example, to provide options to pursue recall or pursue...Different fusion modes of precision search tend to retain more potentially relevant records in recall mode, while performing stricter deduplication and consistency checks in precision mode to adapt to different user search preferences. This intelligent aggregation step is the key to transforming fragmented search results into usable knowledge, which directly determines the quality of information presented to the user and the user experience.

[0048] The method disclosed in this embodiment for determining the corresponding related payment request information based on the obtained 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 range based on dynamically calculated permission boundaries. Then, it uses confidence to drive differentiated search strategies to achieve an intelligent balance between recall and precision. Finally, it fuses multiple rounds of search results through a large model, thereby efficiently, securely and accurately transforming fuzzy and informal user intent into a complete and standardized list of related payment request information, which significantly improves the intelligence level of information retrieval and user experience in complex business scenarios.

[0049] Based on any of the above embodiments, in order to actively identify and verify the pre-dependent information of the pending payment request task in the complete business chain, please refer to Figure 4. Figure 4 is a flowchart of a method for supplementing the audit material information related to the pending payment request task provided by an embodiment of this disclosure. It aims to supplement the audit material information related to the pending payment request task and provides a specific implementation method. The process 400 includes the following steps: Step 401: Use a large model to determine the associated business process corresponding to the pending payment request task in a preset business process library; In this embodiment, the executing entity uses a large model to determine the associated business process corresponding to the pending payment request task in a preset business process library. Among them, the business process library refers to the standardized links, sequences and data transmission relationships of various businesses within an enterprise defined in a structured manner. Once a payment request task is generated, the executing entity uses a large model to analyze the key attributes of the task (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 payment request task. Associated business processes refer to other business process links in a complete business chain that are logically related to the business links corresponding to the payment request task.

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

[0051] Step 403: In response to the inclusion of other review information in the review material information that is involved in other business process stages in the complete business chain that are located before the payment request task to be reviewed, the other review information is checked; In this embodiment, when the review material information contains other review information involved in other business process stages in the complete business chain that are located before the payment request task to be reviewed, the executing entity checks the other review information. Specifically, the executing entity automatically accesses or queries the database, document management system or business system that stores the review results of the upstream stages according to the path defined by the associated business process, obtains other review information and verifies whether its status and content meet the requirements of the current review. For example, if the audit material information indicates that the approval status of the related contract needs to be checked, the executing entity will automatically access the contract management system through the pre-integrated application interface based on the contract number extracted from the pending payment request task, query whether the signing process of the contract has been completed, and obtain the final approval conclusion document; if the material 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 the abnormality of other audit information, create an other information completion task and notify the task handler corresponding to the other audit information to complete the other audit information.

[0053] In this embodiment, when the other audit information is abnormal, the executing entity creates an other information completion task and notifies the task handler corresponding to the other audit information to complete the other audit information. Among them, the abnormality of other audit information includes: the required information is completely missing, the information status does not meet the requirements (such as the contract status is "draft" instead of "effective"), the information content is logically contradictory (such as the acceptance date is later than the payment request date), or the value exceeds the threshold, etc. When other audit information shows the above-mentioned anomalies, the executing entity will create an additional information completion task. This additional information completion task is an independent workflow object (see page 10 / 21 of the manual, CN 121685183 A). Its content will at least record: 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 steps and document identifiers, the detailed reason for the anomaly, and the corresponding task handler. The logic for determining the handler usually stems from the definition of the responsible role or node in the associated business process for that upstream step. Subsequently, the executing entity will notify the task handler by integrating the enterprise's internal workflow engine, instant messaging tools, or email system. The notification will include a link to the completion task or key information to guide the responsible person in processing it.

[0054] The method disclosed in this embodiment for supplementing the audit material information related to the pending payment request task achieves a transformation 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 links 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 is a flowchart of a method for optimizing and updating key descriptors provided by an embodiment of this disclosure. It aims to optimize and update key descriptors and provides a specific implementation method. The process 500 includes the following steps: Step 501: Obtain manual confirmation feedback of the audit results, historical hit effect data of the target audit rules, and description of newly emerging financial audit scenarios; In this embodiment, the executing entity obtains manual confirmation feedback of the audit results, historical hit effect data of the target audit rules, and description of newly emerging financial audit scenarios. Specifically, the executing entity obtains manual confirmation feedback of the audit results by providing a convenient interactive interface, allowing authorized financial auditors to make final confirmation or correction of 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 executing entity continuously records and statistically analyzes audit logs in the background to obtain historical hit data for target audit rules. Whenever an audit rule is triggered, the executing 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 data for 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 leading to disputes or misjudgments. The executing 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 in the pending payment request task that actually exist but are not covered by the first key descriptor, and generate candidate key descriptors; In this embodiment, the executing entity identifies the violation features in the pending payment request task that actually exist but are not covered by the first key descriptor based on manual confirmation feedback, and generates candidate key descriptors. Specifically, the process begins by analyzing the text in the manual confirmation feedback. Using entity recognition, keyword extraction, and semantic analysis techniques, it extracts the violation characteristics indicated in the feedback, such as key concepts like "personal account" and "refund to a public entity" and their relationships. Then, it compares the violation characteristics with the original feature extraction results of the first key descriptor used to generate the pending payment request task. It also performs semantic similarity calculations with existing terms in the preset key descriptor set (page 11 / 21, CN 121685183 A) of the instruction manual. If the violation characteristics cannot be fully represented or matched by existing terms, it is determined that it is not covered. Finally, the executing entity summarizes the violation characteristics into a more general expression (e.g., abstracting "using a personal account to receive a refund to a public entity" as "mixing public and private accounts"), or breaks them down into several combinable key elements, thus forming one or more structured candidate key descriptors.

[0057] Step 503: Based on historical hit effect 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 the key descriptors in the preset key descriptor set based on historical hit effect data: 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. Specifically, based on historical hit performance data, the following three types of targeted optimization operations are performed: First, for terms that perform inconsistently during matching, semantic focus or splitting of ambiguous key descriptors is performed. For example, if a key descriptor named "entertainment expenses" frequently matches both compliant client meeting catering and non-compliant internal welfare meals simultaneously, causing fluctuations in the accuracy of subsequent rule review, it indicates that the term's semantics are too broad. The implementing entity can tighten its definition by semantic focus and adding restrictive contextual labels (such as "external business entertainment"), while the "splitting" operation breaks it down into two more precise terms, such as "client entertainment catering" and "internal team building catering"; Second, by analyzing the trigger frequency of all terms in the terminology library over a longer statistical period, those terms that have not been triggered for a long time are identified.For any terms triggered by a request task, de-weighting means reducing their priority in the matching algorithm so that they do not interfere with the matching of high-frequency terms. Archiving means moving them to a historical database or an observation area to release the capacity and efficiency of the active term database. Third, when the matching of a key descriptor 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 so that it more accurately describes the business concept it originally intended to represent.

[0058] Step 504: Perform association matching verification between the optimized key descriptor and the newly emerging financial audit scenario description, and update the key descriptor that passes the verification 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 effect 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 the transformation from static rule matching to dynamic knowledge growth, significantly reduces manual maintenance costs, and ensures 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, in order to improve the professionalism, accuracy and parsability of the large model review, please refer to Figure 6. Figure 6 is a flowchart of a method for instructing a large model to output review results based on prompt information provided by an embodiment of this disclosure. It aims to provide a specific implementation method for instructing a large model to output review results based on prompt information. The process 600 includes the following steps: Step 601: Based on the content of the target review rule and the task information of the payment request task to be reviewed, a structured prompt information is assembled. The structured prompt information includes at least the following parts concatenated in sequence: Role definition part, used to assign a specific identity related to financial review to the large model; Rule injection part, derived from the target review rule, used to inject specific review basis into the large model; 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; Output specification part, used to constrain the specific format and structure of the large model output review results. In this embodiment: the executing entity assembles structured prompt information based on the content of the target audit rules and the task information of the payment request to be audited. 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 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"; a rule injection part, derived from the target audit rules, used to inject specific audit basis into the large model, transforming the natural language clauses or structured logic of the target audit rules into clear and unambiguous instructions, for example, transforming a rule "The audited travel allowance shall not exceed the daily standard" into "Please check the travel dates and allowance amount in the application and determine whether the daily allowance amount exceeds the company's standard of XXXX (specific amount) yuan"; and a task context part, extracted from key information in the payment request to be audited (such as applicant, department, amount, reason, date, etc.). The prompts are embedded in a concise and objective manner to provide the large model with the factual background required for the review. The output specification section is used to constrain the specific format and structure of the large model's output review results. For example, "Please strictly follow the following JSON format for output, including three fields: 'Conclusion', 'Result of each rule check', and 'Risk Warning'. 'Conclusion' can only be 'Pass' or 'Fail'." These four parts are concatenated in sequence to form a complete instruction chain from identity setting, basis provision, factual input to format constraints.

[0062] Step 602: Input the structured prompts 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 prompts and obtain the review results that meet the requirements of the output specification section.

[0063] In this embodiment, the executing entity inputs structured prompt information along with the complete content of the payment request task to be reviewed into the large model, instructing the large model to complete the review reasoning based on the prompt information and obtain the review result that conforms to the requirements of the output specification. Specifically, the executing entity concatenates the structured prompt information text with the original or standardized text of the payment request task to be reviewed (such as key-value pairs of form fields, 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 make its generated text strictly conform to the syntax and field definitions of that structure. Finally, the model service and the executing entity will 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] The method for outputting audit results based on prompt information disclosed in this embodiment of the large-scale model transforms abstract target audit rules and specific task contexts into a "thinking framework" and "output template" that the large-scale model can accurately execute by constructing a structured prompt information assembly and injection mechanism. This effectively guides the general large-scale model to conduct controllable and reliable reasoning in the professional field of financial auditing. Furthermore, by defining the role of the model as an expert, providing clear audit basis through rule injection, providing factual background through task context, and constraining the result format through output specifications, the standardization of the audit process and the structuring of the result output are ultimately achieved, significantly improving the professionalism, accuracy, and parsability of the large-scale model 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 the review process visualization information; wherein, the generation of the review process visualization information includes: constructing and displaying an review tracing graph based on the original data of the pending payment request task, the intermediate inference data during the large model's review, and the review results; wherein, the review tracing graph is presented in an interactive graph structure, and its nodes include 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, and its edges are used to represent logical deduction, evidence support, or temporal relationships between nodes. This embodiment captures and structurally presents these steps to construct an review tracing graph from input to output, which can externalize the internal logic of the large model. This is both a record of the large model's working process and provides a way to verify the correctness of the review conclusion and understand...The model's decision-making basis even reveals intuitive paths to potential rule defects.

[0066] To deepen understanding, this disclosure also provides a specific implementation scheme in conjunction with a specific application scenario: Assume that Zhang San, an employee of Company A, needs to reimburse travel expenses for a trip to Shanghai to participate in a technical exchange with a client for "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 is divided into the following steps: First stage, fuzzy task input and intent understanding 1. Zhang San inputs fuzzy information in the natural language input box of the reimbursement interface: "Reimbursement for travel expenses and meal expenses for meeting a client at Project B in Shanghai last week. I have attached the invoices." 2. The intelligent financial system parses the fuzzy information into multiple fuzzy task search terms: "Shanghai", "Project XX", "Client exchange", "Travel", "Meals".

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

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

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

[0070] Second stage, dynamic permission boundary determination 1. Real-time trust assessment: The intelligent financial system queries Zhang San's historical expense 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 deduction: The intelligent financial system finds by querying the organizational relationship diagram that: a. Zhang San's direct superior, Li Si, is on a business trip (inaccessible). Based on the management relationship edge, the intelligent financial system determines Wang Wu (another team leader in the same department) as a backup node, and Zhang San temporarily obtains some approval preview permissions from Wang Wu. b. The "Project B" node shows that Zhang San is a participating member, so he automatically obtains resource access permissions to view the project budget and historical expense reports. c. The current task is in the "Reimbursement Application Manual 14 / 21 Page 18 CN 121685183 A Please" stage. According to the responsible relationship, the system allows Zhang San to preview some policy basis required for the next step "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 amount but not exceeding the threshold), the supplier is a commonly used ticketing platform and hotel (low risk), the login IP and device are Zhang San's commonly used computer (no abnormality). Based on the above information, the risk perception value is assessed as "medium-low".

[0073] 4. Determine the permission boundary and target information pool: Based on the comprehensive real-time trust assessment (high), risk (medium-low) and deductionThe implicit permissions of the intelligent financial system are defined as follows: it can access all of Zhang San's personal history records, the reimbursement data of the entire B project group, and the public data within Wang Wu's group obtained through the backup node mechanism, thereby determining the corresponding target information pool.

[0074] The third stage, multi-round differentiated security search and information integration 1. The intelligent financial system uses the big model to prioritize and first use the high confidence word "B project" (>95%) to conduct a precise search in the target information pool (strictly matching the project name) to find all relevant reimbursement forms for the 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 then uses the big model to conduct a fuzzy search using the lower confidence word "catering" (60%) (expanding synonyms such as "meal expenses" and "entertainment" and lowering the similarity threshold) to associate potentially related catering invoices in the previous results.

[0076] 3. After summarizing and deduplicating the above search results, the intelligent financial system generates a list of related reimbursement information and displays it to Zhang San. Zhang San selects a historical travel record as a reference template. Based on this, the intelligent financial system generates a structured reimbursement task to be reviewed, combined with his input. In addition, the intelligent financial system supports querying and retrieving the reimbursement task based on the application type, scenario name, unique identifier, task status (pending execution, successful execution, failed execution, manually marked as completed), creation time, and task notification status (whether to notify the designated system of the review result).

[0077] Fourth stage, rule matching and cross-process association verification 1. The intelligent financial system uses a large model to extract the first key descriptor from the reimbursement task to be reviewed, such as "travel" and "entertainment expenses", and matches it with the preset key descriptor set. The second key descriptor in the preset key descriptor set that matches the first key descriptor, "travel reimbursement - external customers", is determined as the key prompt word, and then the target review rule (including transportation standards, accommodation standards, entertainment expense amount, etc.) corresponding to the key prompt word is hit.

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

[0079] 3. The intelligent financial system uses the large model to locate the complete business chain associated with this pending reimbursement task in the business process library: "Travel application approval → Travel execution → Reimbursement application". The intelligent financial system queries other audit information (i.e., electronic approval form) in the "Travel application approval" stage of this trip.

[0080] 4. The approved budget in the electronic approval form is 4,500 yuan, while the reimbursement application for this trip is 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) of the task handler in the travel approval stage, prompting "Zhang San's Shanghai travel reimbursement application amount (5,000 yuan) exceeds the approved budget.""Calculate (4500 yuan), please provide supplementary explanations or adjust the budget."

[0082] Fifth stage, structured prompts and large model review 1. Assemble structured prompt information: Role - "You are the company's financial audit specialist, and you need to strictly review the compliance of travel reimbursements." Rules - "Rule 1: The upper limit of domestic business trip accommodation standard is 600 yuan per night. Rule 2: The cost of entertaining clients must be reported in advance..." Context - "Applicant: Zhang San; Department: R&D Department; Project: Project B; Itinerary: Shanghai, 3 days; Invoices: Hotel A invoice for 2 nights totaling 1300 yuan, Restaurant B invoice for 800 yuan..." Output specifications - "Please output in JSON format, including: overall conclusion, review results and basis for each rule, and risk warnings." "Structured prompts support flexible configuration and management, including support for adding, modifying, searching and enabling / disabling functions for each part of the prompts.

[0083] 2. The intelligent financial system inputs the structured prompts and detailed information of the pending payment request into the large model. After reasoning, the large 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] Sixth stage, visualization and optimization of the audit process 1. After the audit is completed, the intelligent financial system generates an audit traceability map and displays it to Zhang San and the financial staff. Among them, The audit traceability graph shows: input node (original invoice data), trigger node (matched to the "travel reimbursement - external customer" rule set), intermediate inference node and basis ("calculate total accommodation amount of 1300 yuan", "query accommodation standard of 1200 yuan", "judgment: exceeding the standard"), audit result (conclusion: not passed), and manual feedback annotation, clearly showing the data flow and logical judgment basis.

[0085] 2. The financial staff manually confirmed the audit result was correct and pointed out in the manual feedback annotation that "the basis for exceeding the standard is clear". The intelligent financial system recorded that the "accommodation standard" rule was hit accurately and effectively. At the same time, the intelligent financial system generated the candidate key descriptor "extra-budget expenditure" from this case of "exceeding the budget without prior reporting". After subsequent verification, it will be added to the word library to better capture such future risks.

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

[0087] This embodiment demonstrates how an intelligent financial system can process a vague natural language request through dynamic access control.The system integrates intelligent search, contextual association, rule-based prompts, and large-model reasoning, transforming them into a compliant, in-depth, and traceable audit operation. 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 referring to Figure 7, as an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a large-model-based financial task audit device. This device embodiment corresponds to the method embodiment shown in Figure 2, and the device can be specifically applied to various electronic devices.

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

[0090] In this embodiment, in the financial task audit device 700 based on the large model: the specific processing of the information acquisition unit 701, the task generation unit 702, the rule determination 703, and the task audit unit 704 and the technical effects thereon can be referred to the relevant descriptions of steps 201-204 in the corresponding embodiment of Figure 2, which will not be repeated here.

[0091] In some optional implementations of this embodiment, the information acquisition unit 701 is further configured as: a search term input module, configured to acquire multiple fuzzy task search terms entered by the user in the payment request interface; a priority determination module, configured to determine the search priority according to the sorting information of each fuzzy task search term by the user; and a confidence determination module, configured to determine the confidence of each fuzzy task search term according to the probability value supplement operation of each fuzzy task search term by the user.The fuzzy task information includes: multiple fuzzy task search terms, search priorities, and confidence levels. Correspondingly, the task generation unit 702 is further configured as: an information pool determination module, configured to 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; a multi-round search module, configured to use the large model to sequentially search the target information pool using each fuzzy task search term according to the search order determined by the search priority, and sequentially obtain the sub-association request information corresponding to each fuzzy task search term; wherein different confidence levels correspond to different search methods, with precise search used for confidence levels exceeding a preset confidence threshold, and fuzzy search used for confidence levels not exceeding the preset confidence threshold; and a request information determination module, configured to use the large model to summarize each sub-association request information to obtain the associated request 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 the 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 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; 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 the permission set of the backup node based on the edges representing management relationships in the organizational relationship diagram; in response to the 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 permission 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; determining the user's implicit permissions based on the permission set of 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 ...The estimated amount in the task information and the user's historical payment request records are used to determine the payment request risk level; the supplier risk is determined based on the supplier in the fuzzy task information; the abnormal access score is determined by comparing the current access geolocation, device fingerprint and the user's historical access pattern; and 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. Instruction manual 17 / 21 pages 21 CN 121685183 A

[0095] In some optional implementations of this embodiment, the financial task auditing 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 audited 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 audited; an audit material determination unit, configured to determine the audit material information related to the payment request task to be audited according to the target audit rules; an audit information verification unit, configured to verify other audit information in response to other audit information included in the audit 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 audited; and a completion task creation unit, configured to create other information completion tasks and notify the task handlers corresponding to other audit information to complete other audit information in response to the occurrence of abnormality in other audit 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 existing 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 rate of 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 the 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 parts in sequence: a role definition part, used to assign a specific identity related to financial review to the large model.The rule injection part, derived from the target review rules, is used to inject specific review basis into the large model; the task context part, extracted from key information in the payment request task to be reviewed, is used to provide the large model with the factual background required for review; the output specification part is 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 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 the 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 the completion of the audit; 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 when the large model performs the audit, and the audit result; wherein, the audit tracing graph is presented in an interactive graph structure, and its nodes include 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, 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 input by the user on the remittance interface; then, it uses a preset large model to search for associated 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 associated 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; Specification 18 / 21 pages 22 CN 121685183 A Next, the large model is used to extract the first key descriptor from the pending payment request task, and the second key descriptor in the preset key descriptor set that matches the first key descriptor is determined as the key prompt word, and the target review rule corresponding to the key prompt word is determined; finally, the large model is used to review the pending payment request task according to the prompt information corresponding to the target review rule, and the review result is obtained. Through the accurate 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 review.

[0100] According to embodiments of the present disclosure, the present 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 the present disclosure, the present disclosure also provides a readable storage medium storing computer instructions for enabling a computer to implement the large-model-based financial task auditing method described in any of the above embodiments.

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

[0103] FIG8 shows a schematic block diagram of an exemplary electronic device 800 that can be used to implement embodiments of the present disclosure. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workbenches, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices can also refer to 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 examples and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

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

[0105] Multiple components in the electronic device 800 are connected to the I / O interface 805, including: an input unit 806, such as a keyboard, mouse, etc.; an output unit 807, such as various types of displays, speakers, etc.; a storage unit 808, such as a disk, optical disk, etc.; and a communication unit 809, such as a network card, modem, wireless transceiver, etc. The communication unit 809 allows the 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 various general-purpose and / or special-purpose processing components with processing and computing capabilities.Examples of components 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated 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 may 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 may 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 may be performed. Alternatively, in other embodiments, computing unit 801 may be configured to perform a large-model-based financial task auditing method by any other suitable means (e.g., by means of firmware).

[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: implementation 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, that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transfer data and instructions to the storage system, the at least one input device, and the at least one output device.

[0108] Program code for implementing the methods of this disclosure may be written in any combination of one or more programming languages. These program codes can 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 can be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a standalone software package, 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 can contain or store information for use with...A program used 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 (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; 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 a 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 techniques described herein can be implemented in computing systems that include back-end components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include front-end components (e.g., a user computer with a graphical user interface or a web browser through which the user can interact with embodiments of the systems and techniques described herein), or computing systems that include any combination of such back-end components, middleware components, or front-end components. Components of the system can be interconnected via digital data communication (e.g., a communication network) of any form or medium. Examples of communication networks include: local area networks (LANs), wide area networks (WANs), and the Internet.

[0112] The computer system can include clients and servers. Clients and servers are generally geographically distant from each other and typically interact via a communication network. The client-server relationship is established by a computer program running on the corresponding computer and having a client-server relationship with each other (see page 20 / 21, CN 121685183 A). The server can be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system to solve the problem between traditional physical hosts and Virtual Private Servers (VPS).The Private Server service suffers from high management difficulty and weak business scalability.

[0113] According to the technical solution of the present disclosure, the financial task review method based on the large model provided by the present disclosure first obtains the fuzzy task information entered by the user on the request interface; then, it uses a preset large model to search for the associated request information corresponding to the fuzzy task information within the user's corresponding permission boundary, and uses the large model to generate the request task to be reviewed based on the target request information selected by the user in the associated request information. By introducing permission boundaries, the system can safely and intelligently transform the user's fuzzy and informal task intentions into standardized requests to be reviewed; then, it uses the large model to extract the first key descriptor from the request task to be reviewed, and determines the second key descriptor that matches the first key descriptor in the preset key descriptor set 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 request task to be reviewed according to the prompt information corresponding to the target review rule, and obtains the review result. Through the accurate 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, significantly improving the intelligence level, security and interpretability of financial task processing, and improving the accuracy and efficiency of financial data auditing.

[0114] It should be understood that various forms of processes shown above can be used to reorder, 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 above specific embodiments 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. Instruction manual, page 21 / 21, 25 CN 121685183 A, Figure 1, Figure 2, Instruction manual drawing, page 1 / 6, 26 CN 121685183 A, Figure 3, Instruction manual drawing, page 2 / 6, 27 CN 121685183 A, Figure 4, Instruction manual drawing, page 3 / 6, 28 CN 121685183 A, Figure 5, Instruction manual drawing, page 4 / 6, 29 CN 121685183 A, Figure 6, Figure 7, Instruction manual drawing, page 5 / 6, 30 CN 121685183 A, Figure 8, Instruction manual drawing, page 6 / 6, 31 CN121685183 A Abstract The present disclosure discloses a method and apparatus for financial task auditing based on a large model, and relates to the field of digital processing technologies, in particular to the fields of large model and agent technologies. The method includes: acquiring fuzzy task information input by a user at a payment request interface; by using a preset large model, searching for associated payment request information matching the fuzzy task information within a permission boundary corresponding to the user, and generating a payment request task to be audited according to target payment request information selected by the user from the associated payment request information; extracting a first key descriptor from the payment request task to be audited using the large model; determining a second key descriptor that matches the first key descriptor from a preset key descriptor set as a key prompt word, and determining a target auditing rule corresponding to the keyprompt word; and auditing the payment request task to be audited according to prompt information corresponding to the target auditing rule using the large model, so as to obtain an auditing result. The method enhances the accuracy and efficiency of financial data auditing.

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