A payment data processing method and device based on semantic analysis

Abstract

The application discloses a payment data processing method and device based on semantic analysis, and relates to the technical field of artificial intelligence. The method comprises the following steps: in response to a received natural language processing instruction, analyzing a data processing intention and a target payment data identifier, and then calling a heterogeneous data interface to obtain structured payment data in a business system, associated business data, and unstructured image attachment data in an image system; performing semantic understanding on the unstructured image attachment data to generate structured attachment information; matching a verification rule set containing explicit logic and implicit prompt words from a pre-set hierarchical rule library; performing consistency verification processing on the fused multi-source data to generate a data processing result containing rule execution details; and mapping the data processing result with the target payment data identifier and performing visual multi-level state marking. The problems of low utilization rate of unstructured data, rigid rule logic and non-transparent audit results in the prior art are solved.

Description

Technical Field

[0001] This invention belongs to the field of artificial intelligence technology, and in particular relates to a payment data processing method and apparatus based on semantic analysis. Background Technology

[0002] As enterprises deepen their digital transformation and their business scale continues to expand, payment processing has become the most frequent and risk-concentrated aspect of corporate financial management. In traditional financial approval processes, auditors need to handle massive amounts of payment requests, which involve not only structured data from business systems (such as payment amount, receiving account, and nature of payment) but also a large number of unstructured image attachments (such as scanned copies of contracts, invoice images, and project acceptance forms). To ensure fund security and compliance, auditors must frequently switch between multiple heterogeneous systems and manually compare the consistency and legality of documents.

[0003] However, existing technologies have significant limitations when dealing with complex fund payment verification scenarios. First, traditional automated verification tools can typically only perform simple logical checks on structured fields in business systems (such as NOT NULL checks and amount threshold controls). For unstructured image attachments that carry critical business documents, they often lack effective deep analysis methods. Although some solutions have introduced Optical Character Recognition (OCR) technology, it mostly remains at the level of simple text extraction, lacking the ability to understand the semantics of the text. It cannot effectively integrate the extracted fragmented information with the business context, making it difficult to automatically identify deeper risks such as "inconsistent documents".

[0004] Secondly, existing review rule engines are mostly built on fixed logical expressions, which can only handle explicit, rigid rules (such as "whether the amounts are equal"). When faced with implicit rules involving semantic understanding and compliance judgment (such as "whether the reason for payment conforms to the service scope agreed in the contract" or "whether there is a description of illegal transfer of benefits"), rigid rule engines are helpless. As a result, a large number of high-risk documents still need to be reviewed manually, which is time-consuming and laborious, and seriously restricts the improvement of review efficiency.

[0005] Furthermore, the existing system's feedback mechanism for review results is rather rudimentary, typically only returning "passed" or "rejected" status codes, lacking precise identification and explanation of the error's cause. When a verification failure occurs, business personnel struggle to intuitively determine which clause in which attachment conflicts with the payment data, leading to high communication costs and lengthy troubleshooting cycles. In conclusion, existing technologies, lacking the semantic understanding capabilities for multimodal data and flexible implicit rule processing mechanisms, cannot meet the urgent needs of modern enterprises for intelligent, precise, and efficient fund payment review. Summary of the Invention

[0006] This invention provides a payment data processing method and apparatus based on semantic analysis, which solves the problems of low utilization rate of unstructured data, rigid rule logic, and opaque audit results in the prior art.

[0007] In a first aspect, embodiments of the present invention provide a payment data processing method based on semantic analysis, the method comprising: In response to the received natural language processing instructions, the data processing intent and target payment data identifier in the natural language processing instructions are parsed. Based on the target payment data identifier, the heterogeneous data interface is called to obtain the structured payment data, related business data and unstructured image attachment data from the business system and the image system, respectively. Optical character recognition (OCR) is performed on unstructured image attachment data to extract attachment text features. These attachment text features are then input into a pre-trained large language model for semantic understanding to generate structured attachment information. Simultaneously, structured payment data is parsed to extract key features, including business attribute features. Based on the business attribute features in the key features and the parsed data processing intent, the corresponding verification rule set is matched from the pre-set hierarchical rule base. The verification rule set includes explicit verification rules based on logical expressions and implicit verification rules based on the large language model prompt word engineering. The consistency verification process is performed on the merged structured payment data, related business data, and structured attachment information using the verification rule set, generating a data processing result that includes the overall verification conclusion and rule execution details. The data processing results are associated with the target payment data identifier, and the fields corresponding to the target payment data identifier are marked with multiple levels of status on the interactive interface according to the preset visualization rendering strategy.

[0008] Preferably, prior to responding to a received natural language processing instruction, the method further includes: Execute scheduled monitoring tasks to monitor incremental payment data in the business system that is in an unprocessed state; For incremental payment data, a pre-verification process is triggered, which involves calling heterogeneous data interfaces to obtain data, optical character recognition processing, semantic understanding, and consistency verification. Generate pre-validation results and store them in the results database; In response to received natural language processing instructions, including: firstly querying the result database to see if a pre-verification result corresponding to the target payment data identifier exists, If a pre-validation result exists, the pre-validation result will be directly retrieved as the data processing result. If no pre-verification result is found, subsequent steps based on the target payment data identifier are triggered.

[0009] Preferably, optical character recognition processing is performed on the unstructured image attachment data to extract attachment text features, and the attachment text features are input into a pre-trained large language model for semantic understanding to generate structured attachment information, including: Identify raw text information in unstructured image attachment data using optical character recognition technology; For the raw text information derived from invoice image data, a first prompt word template containing detailed characteristics of goods and business type classification logic is constructed. The original text information and the first prompt word template are input into the large language model. The generalization reasoning ability of the large language model is used to determine the business type corresponding to the invoice and generate structured attachment information containing the invoice classification results.

[0010] Preferably, based on the business attribute characteristics in the structured payment data, a corresponding set of verification rules is matched from a pre-set hierarchical rule base, including: The business type field, payment nature field, and project classification field in the key features are used as business attribute features; In the hierarchical rule base, the business type field is used as the first-level index and the payment nature field is used as the second-level index to retrieve the corresponding rule subset and determine the rule subset as the verification rule set. The hierarchical rule base includes a logical expression library for comparing numerical values ​​and formats, and a prompt word rule base for judging semantic content compliance.

[0011] Preferably, a consistency verification process is performed on the merged structured payment data, related business data, and structured attachment information using a set of verification rules, including: When executing explicit validation rules, the fields to be compared in the structured payment data, related business data and structured attachment information are extracted, and then substituted into the preset logical operator expressions to perform numerical or character matching calculations to obtain the explicit rule validation results. When executing implicit validation rules, a second prompt word template is constructed based on structured payment data, related business data, and structured attachment information. This template includes role settings, validation logic descriptions, a set of variables to be validated, and output format specifications. The second prompt word template is input into the big language model, which analyzes the consistency or compliance of the data in the set of variables to be verified based on contextual semantics, and parses the returned content of the big language model to obtain the implicit rule verification conclusion. Summarize the results of explicit rule validation and the conclusions of implicit rule validation to generate data processing results.

[0012] Preferably, in the step of analyzing the data consistency or compliance of the set of variables to be verified based on contextual semantics using a large language model, the verification process for the amount of fund payment includes: Extract the total contract amount and agreed progress payment ratio from the structured attachment information; extract the amount of payment requested this time from the structured payment data; and extract the amount due for this period from the payment order from the related business data. Construct a third prompt word template containing calculation logic. The calculation logic requires calculating the product of the total contract amount and the agreed progress payment ratio to obtain the theoretical payable amount, and determining whether the current application payment amount is equal to both the theoretical payable amount and the amount payable in the current period of the payment order. It receives the text results output by the large language model, which includes the calculation process and difference comparison. If there are differences, it extracts the reasons for the differences as the rule execution details.

[0013] Preferably, in the step of analyzing the data consistency or compliance of the set of variables to be verified based on the contextual semantics of the large language model, the verification process for the compliance of the payment reason includes: Extract payment summary text from structured payment data, and extract contract scope of work text from structured attachment information; Construct a fourth prompt word template containing semantic matching logic. The semantic matching logic is used to determine whether the activity described in the payment summary text falls within the semantic scope defined in the contract scope text, and whether it contains preset violation semantic features. The system utilizes the natural language understanding capabilities of large language models to identify semantic conflicts or illegal content, and outputs a binary judgment result and risk explanation.

[0014] Preferably, according to a preset visualization rendering strategy, the fields corresponding to the target payment data identifier on the interactive interface are marked with multi-level status, including: At the data list level, a first-level status label is rendered in the data row corresponding to the target payment data identifier. The first-level status label is used to indicate the overall verification conclusion. At the data field level, identify the specific data fields associated with the rules that failed the validation, and overlay a second-level visual marker in the display area of ​​the specific data field. The second-level visual marker distinguishes the validation status by color. Configure the interactive response logic so that when a hover or click operation is detected on the second-level visual marker, the corresponding rule description and rule execution details are displayed in the floating window.

[0015] Preferably, the method further includes a data version tracing step: When it is detected that structured payment data has been split or merged to generate new payment data identifiers, the association between the original payment data identifier and the new payment data identifier is recorded; The data processing results of the new payment data identifier are associated and stored with the historical processing records of the original payment data identifier; It provides a traceability query interface, builds a version history tree based on the associated stored data, and displays rule execution snapshots and attachment text features before and after data changes.

[0016] Secondly, embodiments of the present invention also provide a payment data processing apparatus based on semantic analysis, the apparatus comprising: The instruction interaction module is used to respond to received natural language processing instructions and parse the data processing intent and target payment data identifier in the natural language processing instructions. The data fusion module is used to call heterogeneous data interfaces based on the target payment data identifier to obtain structured payment data, related business data and unstructured image attachment data from the image system. The intelligent recognition module is used to perform optical character recognition processing on unstructured image attachment data to extract attachment text features, and input the attachment text features into a pre-trained large language model for semantic understanding to generate structured attachment information. At the same time, it parses structured payment data to extract key features, including business attribute features. The rules engine module is used to match the corresponding validation rule set from the pre-built hierarchical rule base based on the business attribute features in the key features and the parsed data processing intent. The validation rule set includes explicit validation rules based on logical expressions and implicit validation rules based on the large language model prompt word engineering. The verification execution module is used to perform consistency verification on the merged structured payment data, related business data and structured attachment information using the verification rule set, and generate data processing results that include the overall verification conclusion and rule execution details; The results visualization module is used to establish a mapping between the data processing results and the target payment data identifier, and to perform multi-level status marking on the fields corresponding to the target payment data identifier on the interactive interface according to the preset visualization rendering strategy.

[0017] Thirdly, embodiments of the present invention provide an electronic device, the electronic device comprising: At least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by at least one processor, such that the at least one processor can perform the method proposed in the first aspect of the present invention.

[0018] Fourthly, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as proposed in the first aspect of embodiments of the present invention.

[0019] Beneficial effects: This invention provides a payment data processing method based on semantic analysis. Through heterogeneous data fusion and semantic enhancement using a large language model, combined with explicit and implicit dual-track rule verification, it effectively overcomes the shortcomings of existing technologies, such as low utilization of unstructured data, rigid rules, and opaque results. This method leverages the synergy of OCR and a pre-trained large language model to transform unstructured images into structured semantic information and deeply integrates it with business data and related business data, breaking down data barriers. By constructing a dual-model system of explicit rules containing logical expressions and implicit rules based on prompt word engineering, it can handle both rigid numerical comparisons and accurately assess semantic compliance in complex scenarios, significantly improving risk identification capabilities. Furthermore, a multi-level state marking mechanism based on a visualization rendering strategy achieves accurate mapping and intuitive display of processing results and original data, greatly reducing the cost of manual review and communication difficulties, and significantly improving the processing efficiency and security of fund payment transactions. Attached Figure Description

[0020] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a schematic diagram of the electronic device structure of the hardware operating environment involved in the embodiments of the present invention; Figure 2 This is a flowchart illustrating the steps of a payment data processing method based on semantic analysis provided in an embodiment of the present invention. Figure 3 This is a schematic diagram of the functional modules of a payment data processing device based on semantic analysis provided in an embodiment of the present invention. Detailed Implementation

[0021] To more clearly illustrate the technical solutions in the embodiments of the invention or the prior art, the invention will be briefly introduced below in conjunction with the accompanying drawings and descriptions of the embodiments or the prior art. Obviously, the following description of the structure of the drawings is merely some embodiments of the invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. It should be noted that the description of these embodiments is for the purpose of aiding understanding the invention, but does not constitute a limitation on the invention. The solution of the present invention will be further described below in conjunction with the accompanying drawings.

[0022] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0023] Reference Figure 1 , Figure 1 This is a schematic diagram of the electronic device structure of the hardware operating environment involved in the embodiments of the present invention.

[0024] like Figure 1 As shown, the electronic device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen or an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (Wi-Fi interface). The memory 1005 may be a high-speed random access memory (RAM) or a stable non-volatile memory (NVM), such as a disk drive. Optionally, the memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0025] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0026] like Figure 1As shown, the memory 1005, serving as a storage medium, may include an operating system, a data storage module, a network communication module, a user interface module, and electronic programs. In the illustrated electronic device, the network interface 1004 is primarily used for data communication with a network server; the user interface 1003 is primarily used for data interaction with the user; the processor 1001 and memory 1005 in the electronic device of this invention can be disposed within the electronic device. The electronic device uses the processor 1001 to call the semantic analysis-based payment data processing device stored in the memory 1005 and executes the semantic analysis-based payment data processing method provided in this embodiment of the invention.

[0027] Reference Figure 2 This embodiment provides a payment data processing method based on semantic analysis. This method aims to address the problems in existing fund payment verification processes, such as low utilization of unstructured image data (e.g., contracts, invoices), rigid verification rules (only capable of processing explicit numerical rules), and opaque feedback of verification results. By integrating OCR technology with a Large Language Model (LLM), it achieves deep fusion and semantic understanding of multi-source heterogeneous data, and employs a dual-track rule engine ("explicit + implicit") to improve the automation and accuracy of the verification process. The method in this embodiment mainly includes the following steps S101 to S106: S101, in response to the received natural language processing instruction, parse the data processing intent and target payment data identifier in the natural language processing instruction.

[0028] The data processing intent will be used for preliminary screening in subsequent rule matching (e.g., distinguishing between executing audit rules and query rules). In the business scenario of fund payment, financial auditors or managers often need to interact with the system through natural language to trigger specific audit tasks. This step aims to convert unstructured voice or text instructions into structured operation commands that the system can execute. Specifically, step S101 includes the following sub-steps: S1011 receives natural language processing instructions input by the user.

[0029] The instruction can be in voice form (converted to text via speech recognition technology) or text form. For example, a user might enter: "Please review the progress payment application for contract number CT20231001" or "Check all pending project payments for this month."

[0030] S1012, preprocess the natural language processing instructions.

[0031] The preprocessing process includes stop word removal, word segmentation, and error correction to improve the accuracy of subsequent semantic analysis.

[0032] S1013, using a Natural Language Understanding (NLU) model to identify the intent slot in the instruction.

[0033] The system identifies the user's intent as "to perform payment review" or "to check the review status." Simultaneously, it extracts key entity information, namely the "target payment data identifier." This identifier is a unique ID that identifies a payment application within the business system, such as a payment order number, contract number, or project code. In this embodiment, it is assumed that the extracted target payment data identifier is "PAY_2024_001".

[0034] S102, based on the target payment data identifier, calls the heterogeneous data interface to obtain structured payment data, related business data, and unstructured image attachment data from the image system.

[0035] The core challenge in fund payment verification lies in the multi-source heterogeneity of the data. Business data is typically stored in Enterprise Resource Planning (ERP) or financial systems and is structured; while supporting materials (invoices, contracts, acceptance forms) are typically stored in image systems or Object Storage Service (OSS) and are unstructured. This step achieves full data collection.

[0036] Prior to this step, to improve the system's response speed, this embodiment of the invention preferably introduces a "pre-verification mechanism." Therefore, before executing step S101, the method further includes the following preprocessing steps (S201-S203): S201, execute a scheduled monitoring task to monitor incremental payment data in the business system that is in an unprocessed state.

[0037] It is configured with a timer (such as Quartz or CronJob) to scan the business database at preset time intervals (such as 5 minutes). The scan criteria are "status = pending review" and "creation time > last scan time".

[0038] S202 triggers a pre-verification process for incremental payment data, which involves calling a heterogeneous data interface to obtain data, optical character recognition processing, semantic understanding, and consistency verification.

[0039] For each incremental data entry scanned, the background silently initiates complete verification logic (i.e., the core logic covering subsequent S103 to S105). This process is performed without the user's awareness, making full use of the server's idle computing power.

[0040] S203, generate the pre-verification result and store it in the result database.

[0041] The pre-verification results include whether the verification passed, description of anomalies, risk level, etc., and are stored in a high-performance read-write database (such as Redis or MongoDB) in key-value format, where the key is the payment data identifier.

[0042] Based on the above preprocessing mechanism, the "response" logic in step S101 is further optimized as follows: S1014, Check if the query result database contains a pre-verification result corresponding to the target payment data identifier.

[0043] S1015, if a pre-verification result exists, the result is directly retrieved as the data processing result, and the process proceeds directly to S106 for result display, skipping the real-time calculation steps from S102 to S105.

[0044] S1016 If there is no pre-verification result (e.g., the data has just been submitted and has not yet been captured by the scheduled task), then steps S102 to S105 are triggered, that is, the heterogeneous data interface is called based on the target payment data identifier and subsequent processing is performed.

[0045] In the specific implementation of real-time data acquisition, step S102 includes: S1021, Construct a heterogeneous data query request.

[0046] Based on the identifier "PAY_2024_001", construct a Structured Query Language (SQL) query statement for the ERP system and an Application Programming Interface (API) request for the image management system.

[0047] S1022, Obtain structured payment data from the business system.

[0048] The returned data is in JavaScript Object Notation (JSON) format and contains key fields: payment_amount (application payment amount), payee_account (payee account), contract_id (associated contract number), payment_type (payment type, such as "progress payment"), and project_category (project category).

[0049] S1023, Obtain related business data.

[0050] Further query the contract ledger or fund disbursement plan table based on contract_id to obtain reference data such as planned_amount_current (amount due for disbursement in the current period) and contract_total_amount (total contract amount).

[0051] S1024, acquire unstructured image attachment data from the image system.

[0052] Download all associated attachments, typically in JPG, PNG, or PDF format. Attachments may include: invoice images, scanned copies of contracts, project progress confirmations, acceptance reports, etc.

[0053] S103: Perform optical character recognition processing on unstructured image attachment data to extract attachment text features, and input the attachment text features into a pre-trained large language model for semantic understanding to generate structured attachment information. At the same time, parse structured payment data to extract key features, including business attribute features.

[0054] The key features include business attribute features (such as business type and payment nature) used for rule indexing and numerical features used for specific calculations. This step is crucial for "multimodal data fusion." Simple OCR can only produce fragmented text, which cannot be directly used for logical judgment. This invention uses LLM to transform OCR results into entity information with semantic structure.

[0055] Specifically, step S103 includes the following sub-steps: S1031 uses optical character recognition technology to identify raw text information in unstructured image attachment data.

[0056] The image is detected and recognized using a deep learning OCR engine (such as a text recognition model based on CRNN or Transformer architecture). For tabular documents (such as invoices), a table structure restoration algorithm is enabled to output text blocks containing coordinate information.

[0057] Preferably, in order to solve the problem of tedious manual classification caused by the diversity of invoice types, this embodiment includes special processing logic for invoice classification in S103 (i.e., S1032-S1033): S1032, For the original text information derived from invoice image data, construct a first prompt word template that includes detailed characteristics of goods and business type classification logic.

[0058] After identifying the current attachment as an invoice, it's not sufficient to simply extract the amount; it's necessary to understand the business attributes corresponding to the invoice content. The constructed prompt is shown below: "You are a financial classification expert. The following is the text of the goods details identified from the invoice: '[OCR_TEXT]'. Please classify according to the following logic: If it contains 'cement' or'rebar', classify it as 'engineering materials'; if it contains 'printing paper' or 'ink cartridges', classify it as 'office supplies'. Please output in JSON format: {"invoice_type": "type result"}." S1033, Input the original text information and the first prompt template into the large language model, and use the generalization and reasoning ability of the large language model to determine the business type corresponding to the invoice, and output the structured invoice classification result.

[0059] Based on the pre-trained knowledge and context understanding ability of the large language model, even if there are some typos in the OCR result (such as 'cement' misspelled as '水尼'), it can correct it according to the context and correctly classify it as 'engineering materials'. The structured information generated in this step provides accurate input for subsequent rule matching.

[0060] S1034, Extract the semantics of other types of attachments to generate structured attachment information.

[0061] For the scanned contract, extract long text information such as 'contract terms', 'payment node description', 'liability for breach of contract', etc.; for the acceptance form, extract 'acceptance conclusion', 'acceptance date', etc. Finally, form a unified JSON object, for example: { "contract_summary": { "total_amount": 1000000.00, "payment_terms": "Progress payment is made at 30%", "scope": "Construction and decoration of the main computer room" }, "invoice_list": {"code": "...", "amount": 300000.00, "type": "engineering materials"} } S1035, Extract the key features of the structured payment data.

[0062] Standardize and clean the business data obtained in S102, remove spaces, and unify the monetary unit (such as unified to 'yuan') to ensure that it is in the same dimension as the data extracted by OCR.

[0063] ​S104. Based on the business attribute features in the key features and the parsed data processing intent, match the corresponding verification rule set from the pre-set hierarchical rule base. The verification rule set includes explicit verification rules based on logical expressions and implicit verification rules based on the large language model prompt word engineering.

[0064] To address complex business scenarios, this invention designs a hierarchical rule indexing mechanism and a "dual-track" rule type system.

[0065] S1041, extract business attribute features from the key features, specifically including business type field, payment nature field and project classification field.

[0066] For example, extract the business type as "engineering construction", the payment type as "progress payment", and the project category as "infrastructure".

[0067] S1042, In the hierarchical rule base, the business type field is used as the first-level index and the payment nature field is used as the second-level index to retrieve the corresponding rule subset, and the rule subset is determined as the verification rule set for this processing.

[0068] First, the system locates the rule package for "Engineering Construction," and then further narrows it down to the specific rules for "Progress Payments." This hierarchical indexing avoids the performance overhead and logical conflicts that come with matching all rules.

[0069] S1043, Load two types of rules from the hierarchical rule base.

[0070] Category 1: Explicit Rules. These are hard rules based on a logic expression library, used to handle deterministic numerical and format comparisons. For example: "Application amount <= Remaining contract amount".

[0071] The second category: Implicit Rules. These are flexible rules based on a prompt word rule base, used to determine the compliance of semantic content. For example: "Determine whether the payment summary conforms to the scope of work stipulated in the contract." These rules are stored in the form of Prompt Templates.

[0072] S105: Use the verification rule set to perform consistency verification on the merged structured payment data, related business data and structured attachment information, and generate data processing results that include the overall verification conclusion and rule execution details.

[0073] This step is the core execution phase of the entire method, performing explicit and implicit checks separately and aggregating the results.

[0074] S1051, Execute explicit validation rules. Extract the fields to be compared from the structured payment data, related business data, and structured attachment information, substitute them into preset logical operator expressions to perform numerical or character matching calculations, and calculate the explicit rule validation result (pass / fail). For example, rule ID: R001 (invoice amount verification). The logical expression is:

[0075] in, This represents the function for calculating absolute value. This represents the summation function. This represents the amount of a single invoice extracted from structured attachment information. This indicates the amount of payment requested in this application, extracted from structured payment data. This is a preset allowable error threshold, which can be configured to accommodate the accuracy requirements of different currencies. The system automatically calculates whether the absolute value of the difference between the two is less than 0.01.

[0076] S1052, Execute implicit validation rules. Based on the fused structured payment data, related business data, and structured attachment information, construct a second prompt word template that includes role settings, validation logic descriptions, a set of variables to be validated, and output format specifications. Input the second prompt word template into the large language model, which analyzes the consistency or compliance of the data in the set of variables to be validated based on contextual semantics, and parses the returned content of the large language model to obtain the implicit rule validation conclusion. The following describes the execution process of implicit validation in detail for two specific preferred scenarios: Scenario 1: Linked verification of complex fund payment amounts (corresponding to sub-process A of S1052).

[0077] In this scenario, the accuracy of the payment amount is not simply a matter of "A=B", but involves the calculation of the proportions stipulated in the contract terms.

[0078] Step A1: Extract the total contract amount and agreed progress payment ratio from the structured attachment information, extract the payment amount requested this time from the structured payment data, and extract the amount due for this period from the related business data.

[0079] Suppose the extracted data is as follows: Total contract amount ( = 1,000,000.00 yuan; agreed progress payment ratio ( = 30%; The amount of payment requested this time ( = 300,000.00 yuan; Amount due for this period in the payment order ( = 300,000.00 yuan.

[0080] Step A2: Construct a third prompt word template containing the calculation logic.

[0081] The prompt template is as follows: "Role: You are a senior auditor."

[0082] Input data: Total contract amount: RMB 1,000,000.00 Progress percentage: 30% Application amount: 300,000.00 yuan Payment order amount: 300,000.00 yuan Logical requirements: Calculate the theoretical amount payable The formula is:

[0083] in, For the total contract amount, This represents the progress percentage.

[0084] Judgment condition one: ? Judgment condition two: ? Output requirements: The conclusion should be PASS only if both conditions 1 and 2 are met; otherwise, it should be FAIL, with an explanation of the difference. Step A3: Receive the text results output by the large language model, which includes the calculation process and difference comparison.

[0085] LLM performs calculations: .

[0086] LLM comparison: (True), (True).

[0087] LLM returned: "Conclusion: PASS. Calculation process: 1 million × 30% = 300,000. The applied amount is consistent with the theoretical amount and the disbursement order amount." If a discrepancy exists, the system extracts the reason for the discrepancy as the rule execution details (e.g., "Conclusion: FAIL. Reason: The applied amount (350,000) is not equal to the theoretical amount payable (300,000).").

[0088] Scenario 2: Semantic verification of payment reason compliance (corresponding to sub-process B of S1052) In this scenario, the rules are difficult to express using mathematical formulas and rely mainly on semantic understanding.

[0089] Step B1: Extract the payment summary text from the structured payment data and extract the contract scope text from the structured attachment information.

[0090] Payment summary ( ): "Payment for the second phase of the computer room wall painting".

[0091] Scope of work under contract ( "The construction of the main server room includes ground hardening, server rack installation, and precision air conditioning debugging, but does not include decoration and renovation works."

[0092] Step B2: Construct a fourth prompt word template that includes semantic matching logic.

[0093] Prompt template: "Please determine whether the activity described in the payment summary 'Payment for the second phase of the data center wall painting' falls within the semantic scope of the contract 'Data center construction...excluding decoration and renovation work'? Does it contain any violation characteristics? Please output the judgment result and risk explanation." Step B3: Use the natural language understanding capabilities of the large language model to identify whether there are semantic conflicts.

[0094] LLM's analysis: "Wall painting is a decoration and renovation project, but the contract clearly states that it 'does not include decoration and renovation projects'." Output result: "Judgment result: Violation. Risk explanation: The reason for payment involves decoration work, which exceeds the scope of work stipulated in the contract (the contract explicitly excludes decoration)." S1053, Summarize the explicit rule verification results and the implicit rule verification conclusions to generate a data processing result that includes the overall verification conclusions and rule execution details.

[0095] Summarize all returns from S1051 and S1052. If any rule fails, the "Overall Validation Conclusion" is "Failed / High Risk"; if all rules pass, it is "Passed". The generated "Rule Execution Details" includes the ID, name, and LLM inference text or formula calculation value for each rule.

[0096] S106, establish an association mapping between the data processing results and the target payment data identifier, and perform multi-level status marking on the fields corresponding to the target payment data identifier on the interactive interface according to the preset visualization rendering strategy.

[0097] To enable reviewers to quickly understand complex LLM inference results, this invention provides an interactive visualization solution.

[0098] S1061, at the data list level, render the first-level status badge in the data row corresponding to the target payment data identifier.

[0099] The first-level status indicator is used to indicate the overall verification result. For example, on the payment list page, a red "risk" icon or a green "pass" icon is displayed next to the data ID.

[0100] S1062, at the data field level, identify the specific data field associated with the rule that failed the validation, and overlay the second-level visual marker in the display area of ​​the specific data field.

[0101] The second level of visual markers uses color to distinguish the verification status. For example, if the amount verification fails in Scenario 1, the system will automatically highlight the "Applied Payment Amount" input box on the details page, render its background color as light red, and thicken the border.

[0102] S1063, Configure interactive response logic. When a hover or click operation is detected on the second-level visual marker, the corresponding rule description and rule execution details are displayed in the floating window (Tooltip or Modal).

[0103] For example, when a user hovers their mouse over the red amount box, a pop-up appears: Rule violated: Progress payment amount consistency verification (implicit rule R004) Intelligent analysis: The contract stipulates a payment of 300,000 yuan, while the actual application amount is 350,000 yuan, a difference of +50,000 yuan. This also does not match the amount on the disbursement slip.

[0104] In addition, to ensure full lifecycle management of data, this method also includes a data version traceability step: S107 When it is detected that structured payment data is split or merged to generate a new payment data identifier, the association between the original payment data identifier and the new payment data identifier is recorded.

[0105] For example, a large payment is split into two smaller payments, generating new IDs. The system records lineage relationships in a graph database or relational table.

[0106] S108, associate and store the data processing results of the new payment data identifier with the historical processing records of the original payment data identifier.

[0107] S109 provides a traceability query interface, which builds a version history tree based on the associated stored data, and displays rule execution snapshots and attachment text features before and after data changes.

[0108] When users view a new document, they can click the "Trace Source" button, and the system will display a version tree. Clicking on an old node in the tree allows users to view the OCR recognition results and LLM verification records of the document before it was split, thus preventing violations such as splitting documents to circumvent certain monetary threshold rules.

[0109] This invention also provides a payment data processing device based on semantic analysis, referring to... Figure 3 The diagram illustrates a functional block diagram of a payment data processing device 200 based on semantic analysis according to the present invention. The device may include the following modules: The instruction interaction module 201 is used to respond to received natural language processing instructions, parse the data processing intent and target payment data identifier in the natural language processing instructions, and execute step S101. It integrates a speech recognition engine and an NLU unit, and is responsible for parsing the user's natural language instructions and extracting the intent and target_payment_id.

[0110] The data fusion module 202 is used to retrieve structured payment data from the business system, related business data, and unstructured image attachment data from the image system based on the target payment data identifier, by calling heterogeneous data interfaces; it is used to execute step S102. It contains multiple data connectors, adapted to the JDBC / ODBC protocol (for connecting to the business database) and the Restful / S3 protocol (for connecting to image storage). This module is also responsible for data preprocessing, cleaning, and standardization.

[0111] The intelligent recognition module 203 performs optical character recognition (OCR) processing on unstructured image attachment data to extract attachment text features. These features are then input into a pre-trained large language model for semantic understanding to generate structured attachment information. Simultaneously, it parses structured payment data to extract key features, including business attribute features. This module executes step S103. It integrates an OCR inference engine (supporting GPU acceleration) and an LLM agent interface. It is responsible for converting images into text and calling the LLM API for invoice classification and long document summary extraction.

[0112] The rule engine module 204 is used to match the corresponding validation rule set from a pre-built hierarchical rule base based on the business attribute features in the key features and the parsed data processing intent. The validation rule set includes explicit validation rules based on logical expressions and implicit validation rules based on large language model prompt word engineering; it is used to execute step S104. This module maintains the hierarchical rule base. It contains a rule router that distributes data to different rule sets according to the business type field.

[0113] The verification execution module 205 is used to perform consistency verification processing on the fused structured payment data, related business data, and structured attachment information using the verification rule set, and to generate data processing results containing the overall verification conclusion and rule execution details; it is used to execute step S105. This is the core of the device's calculation.

[0114] Logical computation unit: responsible for parsing and executing logical expressions of explicit rules.

[0115] The prompt word engineering unit is responsible for dynamically assembling the Prompt templates (first to fourth prompt word templates) described in S1052, managing the session context with the large language model, and receiving and parsing the returned text from the LLM.

[0116] The result visualization module 206 is used to establish an association mapping between the data processing results and the target payment data identifier, and to perform multi-level status marking on the fields corresponding to the target payment data identifier on the interactive interface according to a preset visualization rendering strategy. It is used to execute step S106. It is a front-end rendering service responsible for converting the back-end generated verification results (JSON) into the state attributes (such as CSS Classes and Tooltip content) of the front-end UI components, realizing the interactive effect of multi-level marking.

[0117] Preferably, it also includes a monitoring and tracing module: used to perform scheduled monitoring tasks (S201) and version tracing (S107-S109). It maintains the result database and data lineage map to ensure the operation of the pre-verification mechanism and the traceability of data history.

[0118] The device provided in this embodiment achieves end-to-end automation from instruction reception, data capture, intelligent analysis to result presentation through hardware and software collaboration. Its core advantage lies in utilizing the general semantic understanding capabilities of a large language model, filling the gap in traditional rule engines' inability to handle unstructured semantic rules, and significantly improving the intelligence level of fund payment verification.

[0119] Based on the same inventive concept, another embodiment of the present invention provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus. Memory, used to store computer programs; The processor, when executing a program stored in memory, implements the semantic analysis-based payment data processing method of the present invention.

[0120] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in the diagram, but this does not indicate that there is only one bus or one type of bus. The communication interface is used for communication between the aforementioned terminal and other devices. The memory can include Random Access Memory (RAM), or non-volatile memory, such as at least one disk storage device. Optionally, the memory can also be at least one storage device located remotely from the aforementioned processor.

[0121] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0122] Furthermore, to achieve the above objectives, embodiments of the present invention also propose a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the semantic analysis-based payment data processing method of the embodiments of the present invention.

[0123] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable hardware devices (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

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

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

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

[0127] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. "And / or" indicates that either one or both can be chosen. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes the element.

[0128] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A payment data processing method based on semantic analysis, characterized in that, The method includes: In response to a received natural language processing instruction, the data processing intent and target payment data identifier in the natural language processing instruction are parsed. Based on the target payment data identifier, the heterogeneous data interface is called to obtain the structured payment data, related business data and unstructured image attachment data from the business system and the image system, respectively. Optical character recognition (OCR) processing is performed on the unstructured image attachment data to extract attachment text features, and the attachment text features are input into a pre-trained large language model for semantic understanding to generate structured attachment information. At the same time, the structured payment data is parsed to extract key features, including business attribute features. Based on the business attribute features in the key features and the parsed data processing intent, the corresponding verification rule set is matched from the preset hierarchical rule base. The verification rule set includes explicit verification rules based on logical expressions and implicit verification rules based on the large language model prompt word project. The structured payment data, the associated business data, and the structured attachment information are subjected to consistency verification using the verification rule set, and a data processing result containing the overall verification conclusion and rule execution details is generated. The data processing results are associated with the target payment data identifier, and the fields corresponding to the target payment data identifier are marked with multiple levels of status on the interactive interface according to the preset visualization rendering strategy.

2. The payment data processing method based on semantic analysis according to claim 1, characterized in that, Prior to responding to a received natural language processing instruction, the method further includes: Execute scheduled monitoring tasks to monitor incremental payment data in the business system that is in an unprocessed state; The incremental payment data triggers a pre-verification process, which involves calling a heterogeneous data interface to obtain data, optical character recognition processing, semantic understanding, and consistency verification processing. Generate pre-validation results and store them in the results database; The response to the received natural language processing instruction includes: firstly querying the result database to see if a pre-verification result corresponding to the target payment data identifier exists. If the pre-verification result exists, then the pre-verification result is directly retrieved as the data processing result; If the pre-verification result does not exist, subsequent steps based on the target payment data identifier are triggered.

3. The payment data processing method based on semantic analysis according to claim 1, characterized in that, The step of performing optical character recognition processing on the unstructured image attachment data to extract attachment text features, and inputting the attachment text features into a pre-trained large language model for semantic understanding to generate structured attachment information, includes: The original text information in the unstructured image attachment data is identified using optical character recognition technology; For the original text information derived from invoice image data, a first prompt word template containing detailed product features and business type classification logic is constructed; The original text information and the first prompt word template are input into the large language model. The generalization reasoning ability of the large language model is used to determine the business type corresponding to the invoice, and the structured attachment information containing the invoice classification result is generated.

4. The payment data processing method based on semantic analysis according to claim 1, characterized in that, The step of matching the corresponding verification rule set from a pre-set hierarchical rule base based on the business attribute characteristics in the structured payment data includes: The business type field, payment nature field, and project classification field in the key features are used as the business attribute features; In the hierarchical rule base, the business type field is used as the first-level index and the payment nature field is used as the second-level index to retrieve the corresponding rule subset, and the rule subset is determined as the verification rule set; The hierarchical rule base includes a logical expression library for comparing numerical values ​​and formats, and a prompt word rule base for judging the compliance of semantic content.

5. The payment data processing method based on semantic analysis according to claim 1, characterized in that, The process of performing consistency verification on the merged structured payment data, the associated business data, and the structured attachment information using the verification rule set includes: When the explicit verification rule is executed, the fields to be compared in the structured payment data, the associated business data and the structured attachment information are extracted, and the preset logical operator expressions are substituted to perform numerical or character matching calculations to obtain the explicit rule verification result. When the implicit verification rule is executed, a second prompt word template is constructed based on the structured payment data, the associated business data, and the structured attachment information. This template includes role settings, verification logic descriptions, a set of variables to be verified, and output format specifications. The second prompt word template is input into the large language model, which analyzes the consistency or compliance of the data in the set of variables to be verified based on contextual semantics, and parses the returned content of the large language model to obtain the implicit rule verification conclusion. The data processing result is generated by summarizing the explicit rule verification results and the implicit rule verification conclusions.

6. The payment data processing method based on semantic analysis according to claim 5, characterized in that, In the step of analyzing the data consistency or compliance of the set of variables to be verified based on the contextual semantics of the large language model, the verification process for the amount of fund payment includes: Extract the total contract amount and agreed progress payment ratio from the structured attachment information; extract the payment amount requested this time from the structured payment data; and extract the amount due for this period from the payment order from the related business data. Construct a third prompt word template containing calculation logic. The calculation logic requires calculating the product of the total contract amount and the agreed progress payment ratio to obtain the theoretical payable amount, and determining whether the current application payment amount is equal to both the theoretical payable amount and the current payment amount of the disbursement order. The system receives the text results output by the large language model, which includes the calculation process and difference comparison. If differences exist, the reasons for the differences are extracted as rule execution details.

7. The payment data processing method based on semantic analysis according to claim 5, characterized in that, In the step of analyzing the data consistency or compliance of the set of variables to be verified based on the contextual semantics of the large language model, the verification process for the compliance of payment reasons includes: Extract payment summary text from the structured payment data, and extract contract scope of work text from the structured attachment information; Construct a fourth prompt word template containing semantic matching logic. The semantic matching logic is used to determine whether the activity described by the payment summary text belongs to the semantic category defined by the contract scope text, and whether it contains preset violation semantic features. The natural language understanding capabilities of the large language model are used to identify whether there are semantic conflicts or illegal content, and a binary judgment result and risk explanation are output.

8. The payment data processing method based on semantic analysis according to claim 1, characterized in that, The step of performing multi-level status marking on the fields corresponding to the target payment data identifier on the interactive interface according to a preset visualization rendering strategy includes: At the data list level, a first-level status label is rendered in the data row corresponding to the target payment data identifier. The first-level status label is used to indicate the overall verification conclusion. At the data field level, the specific data field associated with the rule that failed the verification is identified, and a second-level visual marker is overlaid in the display area of ​​the specific data field. The second-level visual marker distinguishes the verification status by color. Configure interactive response logic so that when a hover or click operation is detected on the second-level visual marker, the corresponding rule description and the rule execution details are displayed in the floating window.

9. The payment data processing method based on semantic analysis according to claim 1, characterized in that, The method also includes a data version tracing step: When it is detected that the structured payment data is split or merged to generate a new payment data identifier, the association between the original payment data identifier and the new payment data identifier is recorded; The data processing result of the new payment data identifier is associated and stored with the historical processing record of the original payment data identifier; It provides a traceability query interface, constructs a version history tree based on the associated stored data, and displays rule execution snapshots and attachment text features before and after data changes.

10. A payment data processing device based on semantic analysis, characterized in that, The device includes: The instruction interaction module is used to respond to received natural language processing instructions and parse the data processing intent and target payment data identifier in the natural language processing instructions. The data fusion module is used to call the heterogeneous data interface based on the target payment data identifier to obtain structured payment data, related business data and unstructured image attachment data from the business system and the image system, respectively. The intelligent recognition module is used to perform optical character recognition processing on the unstructured image attachment data to extract attachment text features, and input the attachment text features into a pre-trained large language model for semantic understanding to generate structured attachment information. At the same time, it parses the structured payment data to extract key features, including business attribute features. The rule engine module is used to match the corresponding verification rule set from the preset hierarchical rule base according to the business attribute features in the key features and the parsed data processing intent. The verification rule set includes explicit verification rules based on logical expressions and implicit verification rules based on the large language model prompt word engineering. The verification execution module is used to perform consistency verification processing on the fused structured payment data, the associated business data and the structured attachment information using the verification rule set, and generate a data processing result containing the overall verification conclusion and rule execution details; The results visualization module is used to establish an association mapping between the data processing results and the target payment data identifier, and to perform multi-level status marking on the fields corresponding to the target payment data identifier on the interactive interface according to a preset visualization rendering strategy.

Images