A method and apparatus for compensating for a failed transfer transaction

Abstract

The embodiment of the specification relates to the technical field of artificial intelligence, and provides a transfer transaction failure compensation method and device, which comprises the following steps: in response to a transfer transaction failure record and obtaining a transaction log thereof, a transaction feature vector is extracted according to the transaction log and input into a first classification model to obtain a first transaction failure type; if the first transaction failure type belongs to a preset classification set, a preset compensation mechanism is used for processing; if not, a word vector model is used for word meaning feature vector extraction and input into a second classification model to obtain a second transaction failure type; if the second transaction failure type belongs to the preset classification set, the preset compensation mechanism is used for processing; if not, an error information is generated and sent to an operation and maintenance personnel. Through the embodiment of the specification, the transaction failure type identification accuracy can be improved, the transfer failure processing efficiency is improved, and the manual intervention cost is reduced.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of artificial intelligence technology, and in particular to a method and apparatus for compensating for failed transfer transactions. Background Technology

[0002] As an indispensable infrastructure for socio-economic activities, electronic payment and transfer systems inevitably experience some transaction failures due to the rapid increase in transaction volume. Currently, two common methods are used to handle these failures. One method relies on manual processing, where operations personnel monitor the list of failed transactions, manually query logs, analyze the causes, and then decide whether to retry, provide compensation, or notify the user. This method is inefficient, slow, and places immense pressure on the operations team during peak transaction periods, making it difficult to guarantee timely service and user experience. The other method is rule-based automated processing. This involves the system pre-setting a series of "IF-THEN" rules. For example, if the log contains the keyword "timeout," it automatically retryes; if it contains "balance not enough," it terminates the transaction and notifies the user. While this method improves efficiency to some extent, simple rules or a single classification model cannot fully understand the complex semantic information contained in transaction logs, leading to many unconventional and rare failure types that cannot be accurately identified, ultimately requiring manual intervention in the processing flow. Therefore, there is an urgent need for a method to compensate for failed transfer transactions, which can improve the accuracy of identifying transaction failure types, thereby improving the efficiency of handling failed transfers and reducing the cost of manual intervention. Summary of the Invention

[0003] In view of the above-mentioned problems in the prior art, the purpose of the embodiments of this specification is to provide a method and apparatus for compensating for failed transfer transactions, so as to solve the problems of low accuracy in identifying transaction failure types, low efficiency in handling transfer failures, and high cost of manual intervention in the prior art.

[0004] To solve the above-mentioned technical problems, the specific technical solutions of the embodiments in this specification are as follows: On the one hand, the embodiments of this specification provide a method for compensating for failed transfer transactions, the method including: Responding to failed transfer transaction records; Obtain the transaction log of the failed transfer transaction record, and extract the transaction feature vector based on the transaction log; The transaction feature vector is input into a pre-trained first classification model to obtain the first transaction failure type; Determine whether the first transaction failure type belongs to a preset category set; If so, the failed transfer transaction record will be processed according to the preset compensation mechanism; If not, then the word vector model is used to extract semantic feature vectors from the transaction logs; The word meaning feature vector is input into a pre-trained second classification model to obtain the second transaction failure type; Determine whether the second transaction failure type belongs to a preset category set; If so, the failed transfer transaction record will be processed according to the preset compensation mechanism; If not, an error message is generated and sent to the maintenance personnel.

[0005] Further, extracting transaction feature vectors from the transaction logs includes: The transaction logs are one-hot encoded to obtain one-hot encoded feature vectors; Extract the transaction return code, timestamp, and destination flag from the transaction log to obtain the basic transaction feature vector; Obtain the system performance monitoring logs and transaction logs associated with the failed transfer transaction records; The time-series pattern feature vector is extracted from the system performance monitoring log; The link topology feature vector is extracted from the transaction link log; The one-hot encoding feature vector, the basic transaction feature vector, the time sequence pattern feature vector, and the link topology feature vector are fused to obtain the transaction feature vector.

[0006] Furthermore, time-series pattern features are extracted from the system performance monitoring logs, including: Based on the system performance monitoring logs, obtain a sequence of performance index values ​​from multiple systems that are time-related to the failed transfer transaction records; Each performance index numerical sequence is converted into a binary state sequence, where the state at each time point is determined by whether the index value at that time point exceeds its corresponding preset threshold. The binary state sequence is segmented using a sliding window, and the abnormal time sequence pattern of each time window is determined according to a pre-constructed abnormal time sequence pattern template. Each of the aforementioned abnormal temporal patterns is encoded into a corresponding pattern identifier, and the corresponding severity score is calculated. The temporal pattern feature vector is obtained based on the pattern identifier and the corresponding severity score for each time window.

[0007] Further, the link topology feature vector is extracted from the transaction link log, including: Based on the transaction identifier of the failed transfer transaction record and the transaction link log, obtain the full-link tracking data of the associated service node; A transaction call graph is constructed based on the end-to-end tracing data. The nodes in the transaction call graph represent service nodes, and the edges represent the call relationships between service nodes. The call relationships include synchronous calls and asynchronous calls. Extract topological feature vectors from the transaction call graph. The topological feature vectors include at least path length, maximum number of concurrent branches, proportion of asynchronous nodes, and node centrality index. Determine the root node of transaction failure and its failure time in the transaction call graph; Traverse all asynchronous call nodes and determine the suspended asynchronous call nodes based on the transaction failure root node and its failure time point; Perform feature statistics on the suspended asynchronous call nodes to generate a suspended asynchronous call node feature vector; The link topology feature vector is obtained based on the topology feature vector and the suspended asynchronous call node feature vector.

[0008] Furthermore, the first classification model includes multiple sub-classification models; the transaction feature vector is input into the pre-trained first classification model to obtain the first transaction failure type, including: The transaction feature vector is input into each sub-classification model in the first classification model; Obtain the preliminary classification results and local confidence scores output by each sub-classification model; Based on the transaction feature vector, the weights of each sub-classification model are calculated using a meta-decision maker; Based on the preliminary classification results, local confidence scores, and weights of each sub-classification model, a weighted vote is performed to obtain the first transaction failure type and its first confidence score.

[0009] Further, determining whether the first transaction failure type belongs to a preset classification set includes: Determine whether the first transaction failure type belongs to a preset classification set, and whether the first confidence level is higher than a first threshold; If so, then execute the step of processing the failed transfer transaction record according to the preset compensation mechanism; If the first transaction failure type belongs to a preset classification set and the first confidence level is lower than the first threshold, or if the first transaction failure type does not belong to the preset classification set, then the step of extracting semantic feature vectors from the transaction log using a word vector model is executed.

[0010] Furthermore, the word vector model includes a first word vector sub-model and a second word vector sub-model. The word vector model is used to extract semantic feature vectors from the transaction logs, including: The transaction logs are parsed using a multimodal method to obtain a text description modality and a structured code modality. The text description modality is input into the first word vector sub-model to obtain the text semantic vector; The structured code modality is input into the second word vector sub-model to obtain the code semantic vector; The text semantic vector and the code semantic vector are fused across modally to obtain the fused word meaning feature vector.

[0011] Furthermore, the semantic feature vector is input into a pre-trained second classification model to obtain the second transaction failure type, including: Calculate the weighted cosine similarity between the word sense feature vector and all samples in the sample library, wherein the sample library includes historical transfer transaction failure records and their corresponding word sense feature vectors and transaction failure types; Based on the weighted cosine similarity, a preset number of samples with the highest similarity are selected from the sample library as nearest neighbor samples; Based on a predefined business cost matrix, the expected cost of predicting the failed transfer transaction record as the transaction failure type corresponding to each nearest neighbor sample is calculated, wherein each element in the business cost matrix represents the business cost of predicting one failure type as another failure type. The transaction failure type with the lowest expected cost is designated as the second transaction failure type.

[0012] Further, determining whether the second transaction failure type belongs to a preset classification set includes: Obtain the second confidence score output by the second classification model; Determine whether the second transaction failure type belongs to a preset classification set, and whether the second confidence level is higher than a second threshold; If so, then execute the step of processing the failed transfer transaction record according to the preset compensation mechanism; If not, then perform cluster analysis on the semantic feature vector of the failed transfer transaction record and the semantic feature vector of all failed transfer transaction records in the historical cache that are not classified into the preset classification set; When a new type of transaction failure is identified, a new failure mode discovery notification is sent to the operations and maintenance personnel.

[0013] On the other hand, embodiments of this specification provide a transfer transaction failure compensation device, the device comprising: The response module is used to respond to failed transfer transaction records; The acquisition module is used to acquire the transaction logs of the failed transfer transactions and extract transaction feature vectors based on the transaction logs. The first classification module is used to input the transaction feature vector into the pre-trained first classification model to obtain the first transaction failure type; The first judgment module is used to determine whether the first transaction failure type belongs to a preset classification set; The first processing module is used to process the failed transfer transaction record according to a preset compensation mechanism if the case is true. The extraction module is used to extract semantic feature vectors from the transaction logs using a word vector model if the condition is not met. The second classification module is used to input the word meaning feature vector into a pre-trained second classification model to obtain the second transaction failure type; The second judgment module is used to determine whether the second transaction failure type belongs to a preset classification set; The second processing module is used to process the failed transfer transaction record according to a preset compensation mechanism if the case is true. The generation module is used to generate error information and send the error information to the operation and maintenance personnel if the condition is not met.

[0014] By adopting the above technical solution, the transfer transaction failure compensation method provided in this specification, through extracting transaction feature vectors based on transaction logs and initially determining the failure type using a first classification model, can quickly match common and high-frequency transaction failure types, ensuring that most compensable scenarios receive immediate responses and improving the processing efficiency of basic failure types. For transaction failure scenarios that do not match the preset classification set, word semantic feature vectors are extracted using a word vector model and then classified a second time using a second classification model, overcoming the limitations of single feature extraction. This expands the coverage of failure scenarios that can be handled by the preset compensation mechanism and improves the accuracy of transaction failure type identification, avoiding omissions in user compensation due to incomplete failure type determination. For compensable transaction failures, a rapid response and corresponding compensation operation are executed, reducing user losses caused by transaction failures. At the same time, uncompensable abnormal scenarios are promptly reported to maintenance personnel, thereby reducing manual intervention costs and improving the efficiency of transfer failure processing.

[0015] The above description is merely an overview of some embodiments of the technical solutions in this specification. In order to better understand the technical means of some embodiments of this specification and to implement them in accordance with the content of the specification, and to make the above and other objects, features and advantages of the embodiments of this specification more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This specification illustrates the steps of a method for compensating for failed transfer transactions in some embodiments. Figure 2 This specification shows schematic diagrams illustrating the steps of the transaction feature vector extraction process in some embodiments; Figure 3 The following diagram illustrates the steps of the temporal pattern feature vector extraction process in some embodiments of this specification; Figure 4 This specification illustrates the steps of the link topology feature vector extraction process in some embodiments. Figure 5 This specification illustrates the steps for obtaining a first transaction failure type using a first classification model in some embodiments. Figure 6 This specification illustrates the steps for determining whether a first transaction failure type belongs to a preset classification set in some embodiments. Figure 7 This specification illustrates the steps of the word meaning feature vector extraction process in some embodiments. Figure 8 This specification illustrates the steps for obtaining a second transaction failure type using a second classification model in some embodiments. Figure 9 This specification illustrates the steps for determining whether a second transaction failure type belongs to a preset classification set in some embodiments. Figure 10 This specification shows a schematic diagram of the structure of a transfer transaction failure compensation device in some embodiments; Figure 11 A schematic diagram of the structure of a computer device is shown in this specification.

[0018] Explanation of symbols in the attached drawings: 1001, Response Module; 1002. Acquisition Module; 1003, First Classification Module; 1004, First Judgment Module; 1005. First processing module; 1006. Extraction module; 1007. Second Classification Module; 1008. Second Judgment Module; 1009. Second processing module; 1010. Generation Module; 1102. Computer equipment; 1104. Processor; 1106. Memory; 1108. Drive mechanism; 1110. Input / output module; 1112. Input devices; 1114. Output devices; 1116. Presentation device; 1118. Graphical User Interface; 1120. Network interface; 1122. Communication link; 1124. Communication bus. Detailed Implementation

[0019] The technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0020] It should be noted that the terms "first," "second," etc., used in this specification, claims, and the foregoing drawings 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 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, apparatus, product, or device 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 devices.

[0021] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the acquisition, storage, use, and processing of data in the technical solutions described in the embodiments of this application all comply with relevant regulations.

[0022] To address the aforementioned issues, this specification provides an embodiment of a method for compensating for failed transfer transactions. Figure 1 This diagram illustrates the steps of a method for compensating for failed transfer transactions as provided in an embodiment of this specification. This specification provides the operational steps of the method described in the embodiments or flowcharts, but based on conventional or non-inventive methods, more or fewer operational steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual system or device products, the methods shown in the embodiments or drawings can be executed sequentially or in parallel. Specifically, as shown in the diagram... Figure 1 As shown, the method may include: S101: Response to a failed transfer transaction record; S102: Obtain the transaction log of the failed transfer transaction record, and extract the transaction feature vector based on the transaction log; S103: Input the transaction feature vector into the pre-trained first classification model to obtain the first transaction failure type; S104: Determine whether the first transaction failure type belongs to a preset classification set; S105: If so, the failed transfer transaction record shall be processed according to the preset compensation mechanism; S106: If not, then use a word vector model to extract semantic feature vectors from the transaction logs; S107: Input the word meaning feature vector into the pre-trained second classification model to obtain the second transaction failure type; S108: Determine whether the second transaction failure type belongs to a preset classification set; S109: If so, the failed transfer transaction record shall be processed according to the preset compensation mechanism; S1010: If not, generate an error message and send the error message to the maintenance personnel.

[0023] By adopting the above technical solution, the transfer transaction failure compensation method provided in this specification, through extracting transaction feature vectors based on transaction logs and initially determining the failure type using a first classification model, can quickly match common and high-frequency transaction failure types, ensuring that most compensable scenarios receive immediate responses and improving the processing efficiency of basic failure types. For transaction failure scenarios that do not match the preset classification set, word semantic feature vectors are extracted using a word vector model and then classified a second time using a second classification model, overcoming the limitations of single feature extraction. This expands the coverage of failure scenarios that can be handled by the preset compensation mechanism and improves the accuracy of transaction failure type identification, avoiding omissions in user compensation due to incomplete failure type determination. For compensable transaction failures, a rapid response and corresponding compensation operation are executed, reducing user losses caused by transaction failures. At the same time, uncompensable abnormal scenarios are promptly reported to maintenance personnel, thereby reducing manual intervention costs and improving the efficiency of transfer failure processing.

[0024] In this embodiment of the specification, when a transfer transaction fails to execute successfully due to system failure, business rule restrictions, network anomalies, or other reasons, the system generates and records a transfer transaction failure record. This step captures such failure events in real time or near real time by monitoring the transaction system's message queue, polling the failure record table in the database, or receiving failure notifications actively pushed by the system, thereby triggering subsequent compensation processing procedures.

[0025] In the embodiments of this specification, step S102 retrieves complete log information related to the failed transaction from a distributed log system, application log file, or dedicated transaction log database based on a unique identifier in the failure record, such as a transaction serial number, and then extracts transaction feature vectors from the transaction logs. In some embodiments of this specification, reference is made to... Figure 2 Extracting transaction feature vectors from transaction logs includes the following steps: S201: Perform one-hot encoding on the transaction log to obtain a one-hot encoded feature vector; S202: Extract the transaction return code, time stamp, and destination flag from the transaction log to obtain the basic transaction feature vector; S203: Obtain the system performance monitoring logs and transaction link logs associated with the failed transfer transaction records; S204: Extract the time-series pattern feature vector from the system performance monitoring log; S205: Extract the link topology feature vector from the transaction link log; S206: The one-hot encoding feature vector, the basic transaction feature vector, the time sequence pattern feature vector, and the link topology feature vector are fused to obtain the transaction feature vector.

[0026] Understandably, step S201, which performs one-hot encoding on the transaction log, specifically includes: first, constructing a global keyword dictionary based on a large number of historical transaction logs; then, iterating through the current transaction log, setting the i-th bit to 1 if the i-th keyword appears, otherwise setting it to 0. The one-hot encoded feature vector of the current log is represented as [x1, x2, ..., xn-1, xn], where xi ∈ {0, 1}, xi = 0 indicates that the i-th word in the keyword dictionary does not appear in the transaction log, and xi = 1 indicates that the i-th word in the keyword dictionary appears in the transaction log. For example, if the original log text is "2025-08-23 11:02:33 Transaction failed: connection failed, please check the log", its one-hot encoded feature vector can be represented as [1, 0, 0, ..., 0]. Step S202 extracts key business features from the structured fields of the transaction logs, including transaction return codes, timestamps, and remittance route markers. Transaction return codes include system return codes, bank return codes, and business rule return codes, reflecting the direct cause of transaction failure. Timestamps include time-related features such as the specific time period and date type of the transaction. Remittance route markers include routing information such as the settlement channel, payment network, and cross-border identifier used by the transaction. These numerical and categorical features are standardized and encoded to form a basic transaction feature vector. Step S203 retrieves relevant system logs within the transaction execution time window from the distributed log system based on the unique identifier of the failed transfer transaction record. These logs include system performance monitoring logs and transaction link logs. System performance monitoring logs include infrastructure performance indicators such as server CPU utilization, memory usage, disk I / O, network latency, and database connection count. Transaction link logs record detailed information about each system component or service node a transaction passes through from its initiation to its final completion or failure, including the call order, time consumption, and exception information of each service. Step S204, the time-series pattern feature vector, is a numerical representation extracted from system performance monitoring logs that characterizes the dynamic behavior of the system during transaction execution. This feature captures dynamic anomaly patterns in system performance, thus providing environmental context features for failure analysis. Step S205, the link topology feature vector, is a numerical vector extracted from transaction link logs that describes the call relationships and execution path characteristics between services in a distributed system. This feature vector accurately pinpoints which specific service node the transaction failed on, whether due to a fault in the node itself or a problem with the dependencies between nodes, thus providing crucial path context features for failure analysis.Step S206 performs feature fusion on the extracted feature vectors to obtain the final transaction feature vector. First, the feature vectors are dimensionality normalized and standardized to eliminate the influence of dimensions. Then, they are weighted and concatenated according to the importance and relevance of the features. Finally, principal component analysis or autoencoder is used to reduce the dimensionality of the features to remove redundant information and generate the transaction feature vector. This vector contains multi-dimensional features, thus providing a rich and accurate input feature set for the subsequent classification model.

[0027] In some embodiments of this specification, reference is made to Figure 3 The temporal pattern feature vector extraction process specifically includes the following steps: S301: Obtain a sequence of performance index values ​​from multiple systems that are time-related to the failed transfer transaction record based on the system performance monitoring log; S302: Convert each performance index numerical sequence into a binary state sequence, wherein the state at each time point is determined by whether the index value at that time point exceeds its corresponding preset threshold. S303: Use a sliding window to segment the binary state sequence, and determine the abnormal time sequence pattern of each time window according to the pre-constructed abnormal time sequence pattern template; S304: Encode each of the aforementioned abnormal time-series patterns into a corresponding pattern identifier, and calculate the corresponding severity score; S305: Obtain the temporal pattern feature vector based on the pattern identifier and corresponding severity score for each time window.

[0028] Understandably, step S301 retrieves relevant system performance data within the transaction execution time window based on the transaction identifier of the failed transfer transaction record. This includes systems such as database systems, application servers, middleware, network devices, and third-party service interfaces. Performance indicators include, but are not limited to, key performance indicators such as CPU utilization, memory utilization, disk I / O rate, network latency, database connection pool utilization, message queue backlog length, and service response time. Step S302 first sets an adaptive threshold for each performance indicator based on the statistical characteristics of historical data. When the indicator value exceeds the upper limit of the threshold, it is marked as an abnormal state; when it is below the lower limit, it is marked as a normal state; and when it is in the intermediate range, it maintains the previous state, thereby achieving state discretization processing of the performance indicator sequence. In some embodiments, to avoid frequent state reversals, a state maintenance time constraint is added, and a state transition is only confirmed when the abnormal state persists for a minimum duration. Step S303, the abnormal time sequence pattern template, is based on the analysis of a large number of system performance monitoring logs to obtain typical abnormal patterns, such as fluctuation abnormal patterns, instantaneous abnormal patterns, and continuous abnormal patterns. These templates can be described by defining the morphological characteristics of the state sequence. During matching, a sliding window is used to extract the binary state sequence, and then the similarity between the sequence within the window and each template is calculated, such as by calculating the Euclidean distance or dynamic time warping distance of the state sequences. The template with the highest similarity is selected as the anomalous pattern for that window. To facilitate subsequent processing, step S304 assigns a unique identifier (ID) to each successfully matched anomalous temporal pattern template. Since different anomalous patterns have different degrees of impact, a quantitative indicator is needed to represent their severity. In some embodiments, a severity score can be calculated based on factors such as the duration of the anomalous pattern, the frequency of the pattern's occurrence within the time window, and the location of the anomalous occurrence. Step S305 integrates the pattern identifier and severity score obtained after sliding window processing in chronological order to obtain the temporal pattern feature vector.

[0029] In some embodiments of this specification, reference is made to Figure 4 The link topology feature vector extraction process specifically includes the following steps: S401: Based on the transaction identifier of the failed transfer transaction record and the transaction link log, obtain the full-link tracking data of the associated service node; S402: Construct a transaction call graph based on the full-link tracing data. The nodes in the transaction call graph represent service nodes, and the edges represent the call relationships between service nodes. The call relationships include synchronous calls and asynchronous calls. S403: Extract a topological feature vector from the transaction call graph. The topological feature vector includes at least path length, maximum number of concurrent branches, proportion of asynchronous nodes, and node centrality index. S404: Determine the root node of transaction failure and its failure time point in the transaction call graph; S405: Traverse all asynchronous call nodes and determine the suspended asynchronous call node based on the transaction failure root node and its failure time point; S406: Perform feature statistics on the suspended asynchronous call node to generate a suspended asynchronous call node feature vector; S407: Obtain the link topology feature vector based on the topology feature vector and the suspended asynchronous call node feature vector.

[0030] Understandably, step S401 involves precisely matching the transaction identifier with the tracking records in the transaction link log to filter out the call tracking data of all service nodes directly related to the transfer transaction, forming full-link tracking data. Step S402, based on the caller-callee relationship in the full-link tracking data, constructs a transaction call graph using a graph structure modeling method. Each service node serves as a node in the graph, with node attributes including service node ID, service type, deployment instance, and call status. The call relationships between service nodes serve as edges in the graph, with edge attributes including call type marker, call sequence number, call duration, and call return status. Step S403 uses topological feature vectors to quantify the characteristics of the call graph structure, reflecting the complexity of the link, parallelism, asynchronous proportion, and core node distribution, providing a quantitative basis for failure type diagnosis in terms of structural dimensions. In some embodiments, this includes path length, maximum number of concurrent branches, asynchronous node proportion, and node centrality indicators. The path length refers to the total number of service nodes traversed by a transaction from the initiating node to the final processing node, determined by traversing the graph to find the shortest path from the initiating node to all terminal nodes and taking the maximum value. The maximum number of concurrent branches refers to the maximum number of parallel calls initiated simultaneously by a service node in the graph, calculated by counting the number of outgoing edges of each node and the concurrency markers in the edge attributes. The proportion of asynchronous nodes refers to the ratio of the number of service nodes marked as asynchronous calls in the graph to the total number of service nodes in the entire link, calculated by filtering call relationships with asynchronous call attributes and counting the number of duplicates of the corresponding called nodes. Node centrality indicators include degree centrality, betweenness centrality, etc., calculated by traversing the graph nodes and edges using a centrality algorithm in graph theory.

[0031] Step S404, the transaction failure root node, refers to the service node that fails first in the entire chain. The failure of this node is the direct source of subsequent node call failures or the final failure of the transaction, rather than a chain of failures caused by upstream node failures. This embodiment combines the node call order of the transaction call graph with the return status code and error description in the node attributes, using a backtracking method to traverse the chain. Starting from the final failed node, it traces back all its upstream calling nodes, selecting the first node to return a non-success status code with the earliest error timestamp; this is the transaction failure root node, and the call end timestamp of this node is the failure time point. Step S405, the suspended asynchronous call node, refers to an asynchronous call node that is still executing after the transaction failure root node fails, has not terminated normally, and whose execution result is meaningless for the final completion of the transaction. This embodiment first traverses all called nodes in the transaction call graph whose edge attributes are marked as asynchronous calls, obtaining the initiation timestamp and execution status of each asynchronous node. Then, the initiation timestamps of each asynchronous node are compared with the failure timestamp of the root node. If the initiation timestamp of an asynchronous node is earlier than or equal to the failure timestamp of the root node, and its current execution status is running, or although it has terminated, its termination timestamp is later than the failure timestamp of the root node, then the node is determined to be a suspended asynchronous call node. Step S406 performs feature statistics on suspended asynchronous call nodes, including the number of suspended asynchronous nodes, the proportion of suspended nodes, the average suspension duration, and the branch depth of suspended nodes. The above statistical features are arranged in a preset order to form a suspended asynchronous call node feature vector with fixed dimensions. In this way, the impact of invalid asynchronous nodes on the link can be quantified, providing a quantitative basis for the model to judge the resource consumption risk and data consistency risk of transaction failure. Step S407 fuses the topology feature vector and the suspended asynchronous call node feature vector to obtain the link topology feature vector. The fused link topology feature vector contains the static structural characteristics and dynamic abnormal characteristics of the transaction link, which can support the model to accurately identify the transaction failure types caused by complex link structure, core node failure, invalid asynchronous calls, etc.

[0032] In this embodiment of the specification, the first classification model in step S103 is an ensemble learning model based on a tree model, including multiple sub-classification models, such as random forest and gradient boosting decision tree. This model is pre-trained using historical transaction failure data and their correct classification labels. After receiving the transaction feature vector, the model outputs a prediction result of the first transaction failure type for the current failure record through its internal multi-level decision rules, and simultaneously outputs the confidence score of the prediction. Specifically, in this embodiment of the specification, refer to... Figure 5 The transaction feature vector is input into the pre-trained first classification model to obtain the first transaction failure type, which includes the following steps: S501: Input the transaction feature vector into each sub-classification model in the first classification model; S502: Obtain the preliminary classification results and local confidence scores output by each sub-classification model; S503: Based on the transaction feature vector, use the meta-decision maker to calculate the weight of each sub-classification model; S504: Based on the preliminary classification results, local confidence scores, and weights of each sub-classification model, a weighted vote is performed to obtain the first transaction failure type and its first confidence score.

[0033] Understandably, step S503 analyzes the characteristics of the input transaction feature vector through the meta-decision maker and dynamically adjusts the weights of each sub-model according to the feature distribution pattern, so that the sub-model that is more likely to perform better under the current feature pattern has a greater influence, thereby improving the overall classification accuracy.

[0034] The embodiments in this specification are referred to Figure 6 Step S104 determines whether the first transaction failure type belongs to the preset category set, specifically including the following steps: S601: Determine whether the first transaction failure type belongs to a preset classification set, and whether the first confidence level is higher than the first threshold; S602: If so, then execute the step of processing the failed transfer transaction record according to the preset compensation mechanism; S603: If the first transaction failure type belongs to a preset classification set and the first confidence level is lower than the first threshold, or if the first transaction failure type does not belong to the preset classification set, then the step of extracting semantic feature vectors from the transaction log using a word vector model is executed.

[0035] Understandably, the preset classification set includes common failure types that can be automatically handled, such as user input errors, payment route anomalies, and technical / infrastructure failures. The embodiments in this specification match the output of the first classification model with this set, while also considering whether the prediction confidence level is higher than a preset threshold. Only when the type matches and the confidence level meets the threshold is it identified as a failure type that can be automatically handled. For failure types that can be automatically handled, the corresponding compensation processor is invoked. The compensation mechanism includes, but is not limited to: automatically retrying the transaction, performing a reversal operation, transferring to a backup channel, and recording for subsequent batch processing. In some embodiments, the process and results of the compensation operation are recorded, and the transaction status is updated.

[0036] When the first classification model fails to classify with high confidence, the embodiments of this specification use a word vector model to perform semantic analysis on the unstructured text content (such as error descriptions, exception stacks, custom messages, etc.) in the transaction log, generating word semantic feature vectors that can capture deep semantic information. In some embodiments of this specification, reference is made to... Figure 7The word vector model includes a first word vector sub-model and a second word vector sub-model. Step S106, the word meaning feature vector extraction process, specifically includes the following steps: S701: Perform multimodal parsing on the transaction log to obtain the text description modality and the structured code modality; S702: Input the text description modality into the first word vector sub-model to obtain the text semantic vector; S703: Input the structured code modality into the second word vector sub-model to obtain the code semantic vector; S704: Perform cross-modal fusion of the text semantic vector and the code semantic vector to obtain the fused word meaning feature vector.

[0037] It is understandable that step S701, the text description modality, refers to the natural language description portion extracted from the logs, including unstructured content such as error messages, exception descriptions, and custom log text. The structured code modality refers to the structured code elements extracted from the logs, including error codes, function names, API endpoints, class names, and method signatures. By splitting the log data into two semantically independent and formatted modal data, the problem of semantic extraction difficulties caused by the mixing of natural language and structured code in transaction logs is solved. Step S702, the first word vector sub-model, uses a semantic encoding model fine-tuned for text characteristics such as professional terminology and fault description sentence patterns in financial trading scenarios. A lightweight BERT model or RoBERTa model is preferred. After word segmentation and standardization of the text description modality, the standardized word sequence is input into the first word vector sub-model. The first word vector sub-model captures the bidirectional contextual relationships between words and finally outputs the global semantic representation vector of the text description, i.e., the text semantic vector. Each dimension of this vector corresponds to a semantic feature dimension, which can quantify the meaning of the fault scenario in the text description. Step S703: The second word vector sub-model adopts a hybrid architecture combining Word2Vec and a hierarchical attention mechanism. The Word2Vec model learns the basic semantic vector of a single code, while the hierarchical attention mechanism fuses the semantic relationships between multiple codes, ultimately outputting a code semantic vector with the same dimension as the text semantic vector. This achieves semantic quantification of structured code, transforming discrete code into continuous semantic vectors to supplement the system-level semantic information not covered by the text semantic vector. Step S704: First, the semantic correlation between the text semantic vector and the code semantic vector is calculated to assess their consistency in describing the same fault. Then, a cross-modal attention network is used to dynamically adjust the contribution weights of each modality. Based on the assigned weights, the text semantic vector and the code semantic vector are summed element-wise to obtain an intermediate fused vector. This intermediate fused vector is normalized to eliminate the influence of dimensional differences on subsequent models. Finally, the normalized intermediate fused vector is used as the word sense feature vector. The fused word sense feature vector avoids the one-sidedness of single-modal semantic information, thus providing high-quality semantic input for the second classification model to accurately identify complex and rare transaction failure types.

[0038] In this embodiment of the specification, step S107, the second classification model, is a cost-sensitive classification model based on the K-nearest neighbor algorithm. After receiving the word meaning feature vector, the model calculates its similarity to each sample in the sample library, and combines it with a predefined business cost matrix to select the failure type with the lowest expected business cost as the second transaction failure type. (Refer to...) Figure 8 The word sense feature vectors are input into a pre-trained second classification model to obtain the second transaction failure type. The specific steps include: S801: Calculate the weighted cosine similarity between the word sense feature vector and all samples in the sample library, wherein the sample library includes historical transfer transaction failure records and their corresponding word sense feature vectors and transaction failure types; S802: Select a preset number of samples with the highest similarity from the sample library as nearest neighbor samples based on the weighted cosine similarity; S803: Calculate the expected cost of predicting the failed transfer transaction record as the transaction failure type corresponding to each nearest neighbor sample according to the predefined business cost matrix, wherein each element in the business cost matrix represents the business cost generated by predicting one transaction failure type as another transaction failure type. S804: The transaction failure type with the lowest expected cost is selected as the second transaction failure type.

[0039] It is understood that the sample library is a structured database generated through offline training, containing historical cases of failed transfer transactions that have been manually confirmed or system-verified. Each sample contains a complete semantic feature vector and a verified transaction failure type label. Based on the discriminative power of each feature dimension in historical classification, appropriate weights are assigned to different dimensions of the semantic feature vector to enhance the contribution of key semantic features. In the embodiments of this specification, the weighted cosine similarity in step S801 is calculated according to the following formula:

[0040] in, This is the semantic feature vector of the current transfer transaction. For the first in the sample library i The word sense feature vector of each sample, Let be the sample weight coefficient of the i-th sample, and D be the dimension of the word sense feature vector. For the first k Dimensional weights of dimensional features For the current transfer transaction k 3D word meaning feature vector For the first in the sample library i The first sample k2N word semantic feature vectors. Compared to traditional Euclidean distance, weighted cosine similarity is more suitable for high-dimensional sparse word vector spaces and can better capture semantic similarity. Step S802: The preset number is a hyperparameter determined based on experimental optimization, which can be adjusted based on the density distribution of the samples to be classified in the feature space. In some embodiments, if the highest similarity among the initial nearest neighbor samples is lower than a preset threshold, the number of samples is automatically expanded to 2N to ensure that the nearest neighbor samples have sufficient semantic relevance. If there are still no samples that meet the threshold after expansion, all samples with non-zero similarity are retained as nearest neighbor samples. Step S803: The business cost matrix is ​​an M×M square matrix, where M is the total number of transaction failure types. The matrix elements represent the business cost generated when the actual failure type is A and it is predicted as B. The higher the business cost value, the greater the business loss caused by misjudgment. The transaction failure types of all nearest neighbor samples are deduplicated to obtain a candidate failure type set. For each candidate failure type, the expected total cost of using it as the prediction result is calculated using the following formula:

[0041] in, The transaction failure type in the nearest neighbor samples is The sample set, The weighted cosine similarity between this sample and the current transaction. Let be the true transaction failure type of the i-th nearest neighbor sample. Step S804 selects the type with the smallest expected cost from all candidate failure types as the final classification result, and calculates the confidence level of this classification based on the difference in expected cost between the optimal and suboptimal decisions.

[0042] In the embodiments of this specification, refer to Figure 9 Step S108 determines whether the second transaction failure type belongs to the preset category set, specifically including the following steps: S901: Obtain the second confidence level output by the second classification model; S902: Determine whether the second transaction failure type belongs to a preset classification set, and whether the second confidence level is higher than the second threshold; S903: If so, then execute the step of processing the failed transfer transaction record according to the preset compensation mechanism; S904: If not, then perform cluster analysis on the semantic feature vector of the failed transfer transaction record and the semantic feature vector of all failed transfer transaction records in the historical cache that are not classified into the preset classification set. S905: When a new transaction failure type is identified, a new failure mode discovery notification is sent to the operations and maintenance personnel.

[0043] Understandably, upon obtaining a second transaction failure type, a second verification and judgment will be performed to confirm whether the output of the second classification model belongs to the set of failure types that can be automatically handled. This step also considers classification confidence to ensure that only classifications with high confidence will trigger automatic compensation. For automatically handleable types confirmed by the second classification model, the system performs the corresponding compensation operation, following the same process as S105, but will specifically indicate that this result originates from the second-level classification for subsequent model optimization analysis. For transaction failure types that cannot be confirmed by the two-level classification model, an error report containing complete contextual information will be generated, including the original logs, feature extraction results, classification results and confidence levels of the two-level models, and associated system monitoring data, etc., and will be promptly sent to relevant operations and maintenance personnel for manual handling via email, SMS, or operations and maintenance platform notifications. In some embodiments, for transaction failure types that cannot be identified even after a two-level classification model, the semantic feature vectors of the failed transfer transaction records are clustered with the semantic feature vectors of all failed transfer transaction records in the historical cache that are not classified into the preset classification set. Batch pattern mining is performed on failure records that cannot be automatically processed. Clustering identifies potential similar failure scenarios, providing data support for the subsequent discovery of new failure types and avoiding the accumulation of scattered unprocessed records. The historical cache is a distributed cache specifically for storing failed transfer transaction records not classified into the preset classification set. Each cache record contains a semantic feature vector, a transaction timestamp, and anonymized core transaction information. When a new transaction failure type is identified, a prompt message is automatically generated and sent to maintenance personnel for confirmation. This enables proactive discovery and alerting of new failure modes, helping maintenance personnel to update the preset classification set and model training sample library in a timely manner, continuously expanding the coverage of the system's automatic processing, and improving the system's adaptability to complex and rare failure types.

[0044] Based on the aforementioned method for compensating for failed transfer transactions, this specification also provides a corresponding device for compensating for failed transfer transactions. The device may include a system (including a distributed system), software (application), module, component, server, client, etc., using the method described in this specification, combined with necessary hardware implementation. Based on the same innovative concept, the devices in one or more embodiments provided in this specification are as described in the following embodiments. Since the implementation schemes and methods for solving the problem are similar, the implementation of specific devices in this specification can refer to the implementation of the aforementioned method, and repeated details will not be repeated. As used below, the terms "unit" or "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0045] Specifically, Figure 10This is a schematic diagram of the module structure of one embodiment of a transfer transaction failure compensation device provided in this specification. (Refer to...) Figure 10 As shown in the embodiments of this specification, a transfer transaction failure compensation device includes: Response module 1001 is used to respond to transfer transaction failure records; The acquisition module 1002 is used to acquire the transaction log of the failed transfer transaction record and extract the transaction feature vector based on the transaction log; The first classification module 1003 is used to input the transaction feature vector into a pre-trained first classification model to obtain the first transaction failure type; The first judgment module 1004 is used to determine whether the first transaction failure type belongs to a preset classification set; The first processing module 1005 is used to process the failed transfer transaction record according to a preset compensation mechanism if the case is true. The extraction module 1006 is used to extract semantic feature vectors from the transaction logs using a word vector model if no. The second classification module 1007 is used to input the word meaning feature vector into a pre-trained second classification model to obtain the second transaction failure type; The second judgment module 1008 is used to determine whether the second transaction failure type belongs to a preset classification set; The second processing module 1009 is used to process the failed transfer transaction record according to a preset compensation mechanism if the case is true. The generation module 1010 is used to generate error information and send the error information to the operation and maintenance personnel if the error is not found.

[0046] The beneficial effects obtained by the apparatus provided in the embodiments of this specification are consistent with the beneficial effects obtained by the methods described above, and will not be repeated here.

[0047] Reference Figure 11As shown, based on the aforementioned method for compensating for failed transfer transactions, this specification also provides a computer device 1102 in one embodiment, wherein the above-described method operates on the computer device 1102. The computer device 1102 may include one or more processors 1104, such as one or more central processing units (CPUs), each of which may implement one or more hardware threads. The computer device 1102 may also include any memory 1106 for storing any kind of information such as code, settings, data, etc. Non-limitingly, for example, the memory 1106 may include any type of RAM, any type of ROM, flash memory, hard disk, optical disk, etc. More generally, any memory can use any technology to store information. Further, any memory may provide volatile or non-volatile retention of information. Further, any memory may represent a fixed or removable component of the computer device 1102. In one case, when the processor 1104 executes associated instructions stored in any memory or combination of memories, the computer device 1102 may perform any operation of the associated instructions. The computer device 1102 also includes one or more drive mechanisms 1108 for interacting with any memory, such as a hard disk drive mechanism, an optical disk drive mechanism, etc.

[0048] Computer device 1102 may also include an input / output module 1110 (I / O) for receiving various inputs (via input device 1112) and providing various outputs (via output device 1114). A specific output mechanism may include a presentation device 1116 and an associated graphical user interface (GUI) 1118. In other embodiments, the input / output module 1110 (I / O), input device 1112, and output device 1114 may be omitted, and the device may function solely as a computer device within a network. Computer device 1102 may also include one or more network interfaces 1120 for exchanging data with other devices via one or more communication links 1122. One or more communication buses 1124 couple the components described above together.

[0049] Communication link 1122 can be implemented in any way, such as via a local area network, a wide area network (e.g., the Internet), a point-to-point connection, or any combination thereof. Communication link 1122 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc., governed by any protocol or combination of protocols.

[0050] Corresponding to, for example Figures 1 to 9 In addition to the method shown, embodiments of this specification also provide a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the above-described method.

[0051] This specification also provides computer-readable instructions, wherein when a processor executes the instructions, the program therein causes the processor to perform the following... Figures 1 to 9 The method shown.

[0052] This specification also provides a computer program product, including at least one instruction or at least one program segment, wherein the at least one instruction or the at least one program segment is loaded and executed by a processor to achieve the following: Figures 1 to 9 The method shown.

[0053] It should be understood that in the various embodiments of this specification, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this specification.

[0054] It should also be understood that, in the embodiments of this specification, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this specification generally indicates that the preceding and following related objects have an "or" relationship.

[0055] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this specification can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this specification.

[0056] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0057] In the several embodiments provided in this specification, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through some interfaces, devices, or units, or they may be electrical, mechanical, or other forms of connection.

[0058] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments described in this specification, depending on actual needs.

[0059] Furthermore, the functional units in the various embodiments of this specification can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0060] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this specification, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this specification. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0061] This specification uses specific embodiments to illustrate the principles and implementation methods of this specification. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this specification. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this specification. Therefore, the content of this specification should not be construed as a limitation of this specification.

Claims

1. A method for compensating for failed transfer transactions, characterized in that, The method includes: Responding to failed transfer transaction records; Obtain the transaction log of the failed transfer transaction record, and extract the transaction feature vector based on the transaction log; The transaction feature vector is input into a pre-trained first classification model to obtain the first transaction failure type; Determine whether the first transaction failure type belongs to a preset category set; If so, the failed transfer transaction record will be processed according to the preset compensation mechanism; If not, then the word vector model is used to extract semantic feature vectors from the transaction logs; The word meaning feature vector is input into a pre-trained second classification model to obtain the second transaction failure type; Determine whether the second transaction failure type belongs to a preset category set; If so, the failed transfer transaction record will be processed according to the preset compensation mechanism; If not, an error message is generated and sent to the maintenance personnel; The word meaning feature vector is input into a pre-trained second classification model to obtain the second transaction failure type, including: Calculate the weighted cosine similarity between the word sense feature vector and all samples in the sample library, wherein the sample library includes historical transfer transaction failure records and their corresponding word sense feature vectors and transaction failure types; Based on the weighted cosine similarity, a preset number of samples with the highest similarity are selected from the sample library as nearest neighbor samples; Based on a predefined business cost matrix, the expected cost of predicting the failed transfer transaction record as the transaction failure type corresponding to each nearest neighbor sample is calculated, wherein each element in the business cost matrix represents the business cost of predicting one transaction failure type as another transaction failure type. The transaction failure type with the lowest expected cost is designated as the second transaction failure type.

2. The method according to claim 1, characterized in that, Extracting transaction feature vectors from the transaction logs includes: The transaction logs are one-hot encoded to obtain one-hot encoded feature vectors; Extract the transaction return code, timestamp, and destination flag from the transaction log to obtain the basic transaction feature vector; Obtain the system performance monitoring logs and transaction logs associated with the failed transfer transaction records; The time-series pattern feature vector is extracted from the system performance monitoring log; The link topology feature vector is extracted from the transaction link log; The one-hot encoding feature vector, the basic transaction feature vector, the time sequence pattern feature vector, and the link topology feature vector are fused to obtain the transaction feature vector.

3. The method according to claim 2, characterized in that, The time-series pattern features extracted from the system performance monitoring logs include: Based on the system performance monitoring logs, obtain a sequence of performance index values ​​from multiple systems that are time-related to the failed transfer transaction records; Each performance index numerical sequence is converted into a binary state sequence, where the state at each time point is determined by whether the index value at that time point exceeds its corresponding preset threshold. The binary state sequence is segmented using a sliding window, and the abnormal time sequence pattern of each time window is determined according to a pre-constructed abnormal time sequence pattern template. Each of the aforementioned abnormal temporal patterns is encoded into a corresponding pattern identifier, and the corresponding severity score is calculated. The temporal pattern feature vector is obtained based on the pattern identifier and the corresponding severity score for each time window.

4. The method according to claim 2, characterized in that, The link topology feature vector is extracted from the transaction link log, including: Based on the transaction identifier of the failed transfer transaction record and the transaction link log, obtain the full-link tracking data of the associated service node; A transaction call graph is constructed based on the end-to-end tracing data. The nodes in the transaction call graph represent service nodes, and the edges represent the call relationships between service nodes. The call relationships include synchronous calls and asynchronous calls. Extract topological feature vectors from the transaction call graph. The topological feature vectors include at least path length, maximum number of concurrent branches, proportion of asynchronous nodes, and node centrality index. Determine the root node of transaction failure and its failure time in the transaction call graph; Traverse all asynchronous call nodes and determine the suspended asynchronous call nodes based on the transaction failure root node and its failure time point; Perform feature statistics on the suspended asynchronous call nodes to generate a suspended asynchronous call node feature vector; The link topology feature vector is obtained based on the topology feature vector and the suspended asynchronous call node feature vector.

5. The method according to claim 1, characterized in that, The first classification model includes multiple sub-classification models; the transaction feature vector is input into the pre-trained first classification model to obtain the first transaction failure type, including: The transaction feature vector is input into each sub-classification model in the first classification model; Obtain the preliminary classification results and local confidence scores output by each sub-classification model; Based on the transaction feature vector, the weights of each sub-classification model are calculated using a meta-decision maker; Based on the preliminary classification results, local confidence scores, and weights of each sub-classification model, a weighted vote is performed to obtain the first transaction failure type and its first confidence score.

6. The method according to claim 5, characterized in that, Determining whether the first transaction failure type belongs to a preset category set includes: Determine whether the first transaction failure type belongs to a preset classification set, and whether the first confidence level is higher than a first threshold; If so, then execute the step of processing the failed transfer transaction record according to the preset compensation mechanism; If the first transaction failure type belongs to a preset classification set and the first confidence level is lower than the first threshold, or if the first transaction failure type does not belong to the preset classification set, then the step of extracting semantic feature vectors from the transaction log using a word vector model is executed.

7. The method according to claim 1, characterized in that, The word vector model includes a first word vector sub-model and a second word vector sub-model. The word vector model is used to extract semantic feature vectors from the transaction logs, including: The transaction logs are parsed using a multimodal method to obtain a text description modality and a structured code modality. The text description modality is input into the first word vector sub-model to obtain the text semantic vector; The structured code modality is input into the second word vector sub-model to obtain the code semantic vector; The text semantic vector and the code semantic vector are fused across modally to obtain the fused word meaning feature vector.

8. The method according to claim 7, characterized in that, Determining whether the second transaction failure type belongs to a preset category set includes: Obtain the second confidence score output by the second classification model; Determine whether the second transaction failure type belongs to a preset classification set, and whether the second confidence level is higher than a second threshold; If so, then execute the step of processing the failed transfer transaction record according to the preset compensation mechanism; If not, then perform cluster analysis on the semantic feature vector of the failed transfer transaction record and the semantic feature vector of all failed transfer transaction records in the historical cache that are not classified into the preset classification set; When a new type of transaction failure is identified, a new failure mode discovery notification is sent to the operations and maintenance personnel.

9. A device for compensating for failed transfer transactions, characterized in that, The device includes: The response module is used to respond to failed transfer transaction records; The acquisition module is used to acquire the transaction logs of the failed transfer transactions and extract transaction feature vectors based on the transaction logs. The first classification module is used to input the transaction feature vector into the pre-trained first classification model to obtain the first transaction failure type; The first judgment module is used to determine whether the first transaction failure type belongs to a preset classification set; The first processing module is used to process the failed transfer transaction record according to a preset compensation mechanism if the case is true. The extraction module is used to extract semantic feature vectors from the transaction logs using a word vector model if the condition is not met. The second classification module is used to input the word sense feature vector into a pre-trained second classification model to obtain a second transaction failure type. The second classification module is further used to calculate the weighted cosine similarity between the word sense feature vector and all samples in the sample library, wherein the sample library includes historical transfer transaction failure records and their corresponding word sense feature vectors and transaction failure types. Based on the weighted cosine similarity, a predetermined number of samples with the highest similarity are selected from the sample library as nearest neighbor samples. Based on a predefined business cost matrix, the expected cost of predicting the transfer transaction failure record as the transaction failure type corresponding to each nearest neighbor sample is calculated, wherein each element in the business cost matrix represents the business cost of predicting one transaction failure type as another transaction failure type. The transaction failure type with the lowest expected cost is selected as the second transaction failure type. The second judgment module is used to determine whether the second transaction failure type belongs to a preset classification set; The second processing module is used to process the failed transfer transaction record according to a preset compensation mechanism if the case is true. The generation module is used to generate error information and send the error information to the operation and maintenance personnel if the condition is not met.

Images