Financial service data processing method and device, equipment and storage medium

Abstract

The embodiment of the invention provides a financial service data processing method and device, equipment and a storage medium, and relates to the field of financial science and technology. The method comprises the following steps: acquiring query information input by a user; extracting target original service data corresponding to the query information from a database according to the query information and pre-stored user permission information; performing preprocessing according to the query information and the target original service data, and determining to-be-analyzed service data; performing analysis processing according to the to-be-analyzed service data and a pre-established deep learning model to obtain a service state judgment result; and when it is detected that the service state judgment result is a normal state, performing secondary verification processing according to the to-be-analyzed service data, a preset cue word and a pre-established large language model to obtain early warning verification information, and sending the early warning verification information to a human-computer interaction interface for visualization processing to complete early warning. Through multi-stage service state analysis of the deep learning model and the large language model, the accuracy of service detection is improved.

Description

Technical Field

[0001] This application relates to the field of financial technology, and in particular to a financial service data processing method, apparatus, device, and storage medium. Background Technology

[0002] Interface services serve as the central channel for exchanging data and instructions between various financial business systems. They typically encapsulate business functions based on standardized calling protocols, ensuring the continuity of transaction flows and the integrity of data processing. To accurately assess the health of interface services during operation, multi-dimensional operational data must be continuously collected and analyzed to analyze service performance and identify abnormal trends. For example, response time, call frequency, and concurrency stored in logs are used to measure performance load. Analysis of operational data allows for early warnings before failures impact the transaction chain. The stability of interface services is crucial to the continuity of financial operations and the overall reliability of the system.

[0003] In existing technologies, API service detection typically relies on collecting operational logs and monitoring metrics, and then analyzing and judging them through rule-based methods. Specifically, service logs are collected and key fields such as request time, response time, call status code, and caller identifier are extracted. These fields are then compared and judged according to preset alarm rules. Common rules include fixed threshold judgments (e.g., an API's consecutive timeouts exceeding a set value) and keyword matching (e.g., specific error codes or exception information appearing in the logs). When alarm triggering conditions are met, a corresponding alarm event is generated, and the user is notified through interface prompts or push notifications for timely handling.

[0004] However, these methods primarily rely on static thresholds and fixed rules, making them unable to flexibly adjust to dynamic changes in the actual business environment. This can lead to false positives or false negatives, reducing the accuracy of service anomaly detection. Therefore, there is an urgent need for a financial service data processing method to address the technical problem of low accuracy in existing financial service detection technologies. Summary of the Invention

[0005] This application provides a financial services data processing method, apparatus, device, and storage medium to solve the technical problem of low accuracy in financial services data detection.

[0006] In a first aspect, this application provides a financial services data processing method, including:

[0007] Obtain the query information entered by the user;

[0008] Based on the query information and the pre-stored user permission information, extract the target original service data corresponding to the query information from the database;

[0009] Preprocessing is performed based on the query information and the target raw service data to determine the service data to be analyzed;

[0010] The service status judgment result is obtained by analyzing and processing the service data to be analyzed and the pre-built deep learning model.

[0011] When the service status judgment result is detected as normal, a secondary verification process is performed based on the service data to be analyzed, preset prompt words, and pre-built large language model to obtain early warning verification information;

[0012] When the warning verification information indicates that there is an anomaly in the service, the warning verification information is sent to the human-computer interaction interface for visualization processing to complete the warning.

[0013] Secondly, this application provides a financial services data processing apparatus, comprising:

[0014] The data acquisition module is used to obtain the query information input by the user;

[0015] The database module is used to extract the target original service data corresponding to the query information from the database based on the query information and the pre-stored user permission information;

[0016] The backend processing module is used to preprocess the query information and the target original service data to determine the service data to be analyzed.

[0017] The backend processing module is used to analyze and process the service data to be analyzed and the pre-built deep learning model to obtain the service status judgment result.

[0018] The backend processing module is used to perform secondary verification processing based on the service data to be analyzed, preset prompt words, and pre-built large language model when the service status judgment result is detected as normal, so as to obtain early warning verification information.

[0019] The front-end display module is used to send the warning verification information to the human-computer interaction interface for visualization processing when the warning verification information is detected as indicating an anomaly in the service, thus completing the warning process.

[0020] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0021] The memory stores computer-executed instructions;

[0022] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0023] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0024] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0025] This application provides a financial service data processing method, apparatus, device, and storage medium. By acquiring user-input query information and combining it with pre-stored user permission information, this application extracts the target original service data corresponding to the query information from the database, achieving data access permission isolation and result accuracy, and ensuring data security and access control in a multi-user environment. Furthermore, by preprocessing the query information and target original service data, structured service data to be analyzed is constructed, improving the input standardization and data adaptability of subsequent model analysis, effectively supporting the stability and accuracy of deep analysis tasks. The service data to be analyzed is input into a pre-built deep learning model for analysis and processing, enabling dynamic judgment of service operation status. The multi-dimensional feature recognition capability of the deep learning model enhances the flexibility and adaptability of data processing, thereby improving the accuracy of service detection. When the judgment result is normal, a second verification is performed using a large language model combined with preset prompt words, constructing a semantic-level reasoning mechanism, achieving early identification of service faults and perception of trend anomalies. Finally, the verification results of anomalies are sent to a human-computer interaction interface for visualization, realizing intuitive display and immediate feedback of early warning information, improving operation and maintenance response efficiency and monitoring interaction capabilities. In summary, this enhances the flexibility of data processing in financial services, thereby improving the accuracy of service testing. Attached Figure Description

[0026] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0027] Figure 1 A flowchart illustrating the financial service data processing method provided in this application embodiment;

[0028] Figure 2 This is a schematic diagram of a method for obtaining and visualizing alarm troubleshooting information provided in an embodiment of this application;

[0029] Figure 3 A schematic diagram of the financial service data processing apparatus provided in this application;

[0030] Figure 4 A schematic diagram of the structure of the electronic device provided in this application.

[0031] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0032] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0033] 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, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0034] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0035] It should be noted that the financial service data processing method, apparatus, equipment and storage medium provided in this application can be used in the financial service field, or in any field other than financial services. The application field of the financial service data processing method, apparatus, equipment and storage medium in this application is not limited.

[0036] The service data processing method provided in this application is mainly applied to businesses that use interface services as the primary communication mechanism. Typical deployment scenarios include financial trading platforms, internet service systems, and enterprise information systems. In fintech scenarios, interface services undertake functions such as account management, transaction execution, and risk control calls, requiring support for high-frequency data interaction and high-concurrency access, with diverse request sources and complex call chains. In such environments, operations and maintenance personnel need to rely on a large amount of interface logs to judge the service's operational status to ensure business continuity and data processing integrity. However, in actual operation, the following problems are often encountered: on the one hand, the log data volume is huge but the content structure is complex, and relying on manual rules or fixed thresholds for alarm judgment can easily lead to false alarms and missed alarms; on the other hand, the service data involved by different users varies greatly, lacking a flexible data processing mechanism, making it difficult to meet dynamic analysis needs.

[0037] Based on the aforementioned technical problems and practical needs, the inventive concept of this application is to provide a service data processing method to improve the flexibility of data analysis and the accuracy of service status identification. According to user query information, corresponding raw service data is extracted through permission restrictions, and preprocessed in conjunction with the query information to obtain service data to be analyzed that reflects the service's operational status. This data is then input into a pre-built deep learning model to determine the service status, including whether the service is in a normal state. If the service is determined to be in a normal state, a secondary verification analysis is performed by constructing a large language model containing preset prompt words to achieve in-depth analysis and supplementary judgment of potential service faults, improving the accuracy and foresight of early warnings. When the large language model determines that an anomaly exists, the early warning verification information is pushed to the human-computer interaction interface, enabling intuitive display and immediate response to the alarm content. This approach improves the flexibility of service detection and the accuracy of early warnings while ensuring data processing accuracy.

[0038] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0039] Figure 1 This is a flowchart illustrating the financial service data processing method provided in an embodiment of this application. Figure 1 As shown, it includes:

[0040] S11, obtain the query information input by the user.

[0041] In this embodiment, user-inputted query information is received through a front-end interactive interface. Query information refers to the query conditions or instructions actively entered by the user to obtain service data. Its content may include service name, service call time range, module identifier, data field selection, indicator type, calculation requirements, or other parameter configurations. For example, information input can be achieved through various forms such as graphical interfaces, text boxes, drop-down menus, or structured input components to meet the operating habits and needs of different users. Furthermore, to ensure the standardization and validity of the input information, format validation and semantic parsing can be performed on the user-inputted query information to determine whether the query conditions are complete and whether the field types match. If incomplete or mismatched, the user can be prompted to supplement or correct the information. It should be noted that the format validation and semantic parsing performed on the user-inputted query information can employ various existing implementation methods. The core purpose is to accurately identify the user's query intent and extract content that can be used for subsequent data processing. Any technical solution that can achieve the above-mentioned identification and extraction objectives can be applied to the implementation process of this application; the specific implementation details of this part will not be elaborated here. This embodiment establishes a request channel between the user and service data processing by acquiring query information, realizing the expression and structural parsing of personalized data call requirements, and providing a foundation for subsequent data extraction and analysis.

[0042] S12, extract the target original service data corresponding to the query information from the database based on the query information and the pre-stored user permission information.

[0043] In this embodiment, based on the query information and pre-stored user permission information, the target original service data corresponding to the query information is extracted from the database. The pre-stored user permission information is permission configuration data maintained for each user, recording information such as the user's role (e.g., administrator or ordinary user), the scope of services accessible, and the types of metrics that can be retrieved, used to implement access control and data isolation. During database access, the query results are restricted according to the permission information to ensure that users can only access service data within their authorized scope. By obtaining query information and combining it with user permissions to extract database data, a user-controllable service data access mechanism is achieved. On the one hand, this reduces the problem of unauthorized data access, ensuring data security and compliance; on the other hand, by linking query information with permissions, the purpose of differentiated settings for service data for different user types is achieved, enhancing overall applicability and flexibility.

[0044] S13. Based on the query information and the target original service data, preprocess the data to be analyzed to determine the service data.

[0045] In this embodiment, the target raw service data refers to the underlying service operation records obtained from the database after permission filtering, which meet the user's query conditions. For example, the operation record information includes the server's operating status and interface usage, such as caller and receiver IP addresses, response time, status codes, request body size, memory usage, and other multi-dimensional performance and behavioral parameters. Preprocessing refers to performing a series of cleaning, filtering, calculation, and format conversion operations on the target raw service data based on the analytical indicators, statistical formulas, time granularity, aggregation dimensions, etc., contained in the query information. Preprocessing methods include, but are not limited to: segmenting and summarizing data according to time windows, filling or removing outliers or missing values, performing aggregation statistics according to interface paths or service modules, calculating error rates based on status code distribution, or performing combined operations on multiple fields. During the preprocessing process, the calculation requirements defined in the query information are automatically parsed, and a built-in data processing engine (such as an SQL-based computing framework or distributed computing component) is used to complete the batch conversion of the data.

[0046] The output of preprocessing is the service data to be analyzed, which refers to a standardized and indexed dataset with a clear field structure and temporal correlation, serving as input for subsequent deep learning model analysis and large language model inference. This step extracts feature information relevant to the user's goals from the raw data, improving the targeting and efficiency of data analysis. This embodiment combines query information and target raw service data to perform data processing operations, transforming raw data into analyzable data. This establishes a structured and standardized data foundation for subsequent service status judgment and early warning verification, while ensuring the consistency and effectiveness of model input.

[0047] S14. Based on the service data to be analyzed and the pre-built deep learning model, the service status judgment result is obtained.

[0048] In this embodiment, the pre-built deep learning model refers to an analysis model that has been trained and optimized. It is typically built upon structures such as temporal neural networks, convolutional neural networks, or multilayer perceptrons, and possesses the ability to learn and recognize patterns in multi-dimensional service operation characteristics. This deep learning model is trained using historical service operation data and can identify feature boundaries between normal and abnormal states, adapting to differences in service scale, operational load, and indicator fluctuations. In specific implementation, the service data to be analyzed is used to construct a model input feature vector according to time sequence, indicator dimensions, and service instance classification. The input vector can contain the current value, historical value, and statistical measures (such as mean, variance, range, etc.) of multiple indicators. The deep learning model automatically identifies whether the input data matches a normal service operation mode based on its position in the multi-dimensional space. Unlike traditional judgment mechanisms based on fixed thresholds, the pre-built deep learning model can dynamically determine the service status and make a comprehensive judgment based on the nonlinear relationship between indicators. When processing input data, the model may also output intermediate feature representations for further state classification or result visualization.

[0049] The service status assessment result refers to the classification output of the deep learning model on the current service operation status. For example, it typically includes status types such as normal and abnormal, and may also include multiple alarm levels (e.g., low, medium, high), along with corresponding abnormal feature indicators or abnormal dimensions. This service status assessment result not only reflects the service's operational health status within the current time window but also provides a basis for subsequent early warning verification, cause investigation, and visualization output. This embodiment achieves service operation status analysis and assessment by combining the service data to be analyzed with a pre-built deep learning model. It can adapt to the differences in the operating modes of different types of services, supports multi-indicator collaborative judgment, and has adaptive threshold adjustment and alarm level classification capabilities, thereby improving the sensitivity and accuracy of service anomaly detection.

[0050] S15, when the service status judgment result is detected as normal, a secondary verification process is performed based on the service data to be analyzed, preset prompt words, and pre-built large language model to obtain early warning verification information.

[0051] In this embodiment, if the service status assessment result is normal, a secondary verification process will be performed to further identify potential anomalies that may be on the verge of collapse but have not yet been marked as abnormal by the deep learning model. This process, based on the service data to be analyzed, preset prompt words, and a pre-built large language model, aims to construct a redundant verification path for service health status, thereby improving the ability to perceive near-abnormal states. The preset prompt words are input instruction templates set for the large language model, including, for example, guidance for service anomaly identification, contextual explanations related to the current scenario, indicator threshold description rules, and analysis direction prompts. The prompt words are constructed in a structured or semi-structured form and can embed dynamic variables (such as current indicator values, fluctuation ranges, time trends, etc.) to guide the large language model to focus on specific dimensions or trend features. In this embodiment, the current service data to be analyzed is combined with the preset prompt words to form a complete input, which is then input into the pre-built large language model.

[0052] The pre-built large language model refers to a natural language inference model that has been trained and integrated into the backend, possessing the ability to perform pattern recognition and probabilistic judgment under complex text conditions. In this embodiment, the large language model does not directly rely on fixed threshold judgment rules, but rather achieves fuzzy identification and prediction of potential anomalies through semantic and multi-indicator collaborative language modeling inference. When the model detects that an indicator is running at a high level, fluctuating abnormally, or trending upwards, even if its value has not exceeded the alarm boundary defined by the deep learning model, it can still provide warning verification information such as "potential fault exists" or "please pay close attention" through the contextual inference mechanism of the language model. The output form of the warning verification information includes semantic-level judgment of the current service status and fault prediction explanation. It can be displayed as prompt information in the subsequent visualization interface. By setting up a secondary verification mechanism, an auxiliary judgment link outside the deep model is constructed, improving the prediction and detection capabilities of boundary states or trend faults, effectively reducing the probability of false negatives, and providing users with a more forward-looking service operation security awareness capability. By integrating the service data to be analyzed, preset prompt words, and pre-built large language models, the semantic layer of service status is used to verify possible anomalies, which strengthens the shortcomings of deep learning models in threshold edge judgment and thus builds a more robust alarm analysis framework.

[0053] S16. When the warning verification information indicates that there is an anomaly in the service, the warning verification information is sent to the human-computer interaction interface for visualization processing to complete the warning.

[0054] In this embodiment, the early warning verification information is a semantic-level judgment result output by a large language model based on the service data to be analyzed and preset prompt words. Its content includes not only the classification conclusion of the service status (such as "potential anomaly exists" or "performance degradation may occur"), but also elements such as the name of the anomaly indicator, trend description, and summary of anomaly features. Before being sent to the human-computer interaction interface, this information is encapsulated into a standardized visual object, structurally containing the judgment result, analysis basis, data summary, and timestamp, so that the front end can accurately parse and efficiently render it. The human-computer interaction interface is a user-facing front-end display platform, typically implemented on a web page or client, supporting various information presentation methods such as charts, text, lists, and color coding. The visualization processing of early warning information in the front-end interface includes, but is not limited to: marking the abnormal service status in the monitoring panel with highlighted colors or icons; displaying the model's output anomaly description and data summary in the alarm details pop-up window; and marking the abnormal time period in the trend chart with auxiliary lines or warning blocks. This embodiment achieves a complete link from the back-end model inference result to the user-perceptible alarm display by instantly pushing the early warning verification information to the human-computer interaction interface and performing structured visualization processing. This ensures that even if the deep learning model fails to identify anomalies, it still possesses the ability to provide anomaly alerts based on a language reasoning model, thereby significantly enhancing overall robustness and foresight. This mechanism allows for more flexible service data processing, further improving the accuracy of service detection, enabling users to promptly grasp anomaly information, proactively deploy preventative measures, and reduce the further escalation of anomalies.

[0055] This application achieves accuracy and access control for service data by acquiring user-input query information and extracting the target raw service data corresponding to the query information from the database in conjunction with pre-stored user permission information. This ensures the security and effectiveness of data access for different users. This not only guarantees data access control but also enhances the flexibility of data retrieval in multi-user scenarios. By preprocessing the query information and target raw service data, the service data to be analyzed is determined, realizing the transformation of raw data into a usable structure for the model. This makes subsequent model processing more targeted, effectively improving the accuracy and stability of data analysis. By inputting the service data to be analyzed into a pre-built deep learning model for analysis and processing, service status judgment results are obtained, achieving flexible identification and anomaly detection capabilities for service operation status. The deep learning model's multi-indicator fusion judgment capability and nonlinear mapping capability enable it to adapt to dynamic judgment needs under different service scales and indicator fluctuations, thereby improving the accuracy of service status analysis. When the service status assessment result is normal, a secondary verification process is further performed using the service data to be analyzed, preset prompt words, and a pre-built large language model. This effectively constructs a semantic-level risk assessment mechanism, enabling early identification of potential service risks before explicit anomalies appear. Through the reasoning capabilities of the language model, it possesses the ability to identify trend-based problems and perceive critical states, improving the ability to assess service security status. Finally, the early warning verification information output by the large language model is sent to the human-computer interaction interface for visualization, enabling real-time display of potential anomalies and user prompts. This allows users to intuitively understand changes in service status, enhancing the interactivity of monitoring and operational efficiency. While improving the flexibility of financial service data processing, it also improves the accuracy of service detection, achieving early identification and prompting of service failures.

[0056] In one embodiment, the acquisition of target raw service data in step S12 is provided as an implementation method based on the above embodiment, including:

[0057] S121, Determine the user's database access permissions based on the pre-stored user permission information;

[0058] S122, when it is detected that the database access permission is administrator privilege, the original service data of all users corresponding to the query information are extracted from the database as the target original service data according to the query information.

[0059] S123, when it is detected that the database access permission is ordinary user permission, the original service data of the user corresponding to the query information is extracted from the database as the target original service data according to the query information.

[0060] In this embodiment, the current user's database access permissions are determined based on pre-stored user permission information. This pre-stored user permission information is permission control data configured during user registration or authorization management, typically stored in the permission control module or metadata table as a mapping between user identifiers and permission levels. This information includes fields such as the user's organization, role type, accessible service scope, and queried data level, ensuring system data security and multi-tenant isolation. After parsing the user's query information, the current user's permission information is automatically retrieved for permission identification. When the identification result indicates that the database access permission is administrator-level, the user is considered to have global data access capabilities. In this case, based on the user's query information, the original service data of all users corresponding to the query information is extracted from the database as the target original service data for this analysis. This type of data extraction can cover service logs and operational metrics across multiple service modules, multiple tenants, or multiple subsystems, enabling centralized analysis and system-level early warning across businesses and services.

[0061] When the identification result indicates that the database access permission is that of a regular user, the user's access scope is limited to data resources within the service or project to which that user belongs. At this time, based on the query information, only the original service data relevant to the user is extracted from the database—that is, the service operation data within the user's permission scope. This strategy ensures that regular users can only access data resources directly related to their responsibilities or projects, preventing access to data from other service instances or business modules. This embodiment implements a service data access control mechanism based on permission levels by introducing permission identification and dynamic data extraction strategies. On the one hand, it ensures that administrator users have macro-level analytical capabilities for global data, meeting the administrator's need for overall observability; on the other hand, it restricts the access scope of regular users, reduces data leakage, and protects user data security.

[0062] In one embodiment, the query information includes indicator information and / or a preset calculation model.

[0063] In this embodiment, metric information refers to measures used to quantitatively describe the operational status of a service. These measures are typically formed from raw data collected during operation, after preprocessing and statistical calculation. Specifically, metric information may include standardized general operational metrics, such as Transactions Per Second (TPS), response latency, error rate, and CPU utilization. These metrics are usually pre-configured and maintain a correspondence with the raw fields in the database. For some metric information, such as items involving unit conversion, derived dimensions, or requiring standardization, a standard calculation formula corresponding to that metric information is also pre-stored. This standard formula defines how to calculate standardized metric values ​​from underlying raw fields (such as timestamps, status codes, resource usage values, etc.), for example, dividing the total number of service requests by the number of seconds in the time interval to obtain TPS, or calculating the error rate through status code distribution.

[0064] In addition to predefined metrics, users can also input custom preset calculation models based on their actual business needs. These models describe data processing logic in formula form, typically involving combined calculations of raw fields, conditional filtering, and sliding window calculations. Users construct model expressions using a graphical formula editor or natural language input, and the formula parser translates them into database calculation logic. Preset calculation models can perform analysis and calculations on specific service interfaces, specified time granularities, or customized dimensions to generate personalized metrics with business semantics, such as "average response time per unit of memory consumption" or "interface failure rate change rate." Therefore, this implementation method balances universality with user-specific needs. Standardized metrics support fast and efficient data extraction and analysis, ensuring consistency and comparability of metric meanings; custom calculation models provide users with flexible expression capabilities, thereby improving system availability, scalability, and user experience.

[0065] The service data to be analyzed in step S13 above includes:

[0066] S131, Perform indicator calculation processing on the target raw service data according to the indicator information to obtain the first calculation result corresponding to the indicator information, and determine the first calculation result as the service data to be analyzed.

[0067] S132, perform model calculation processing on the target original service data according to the calculation model to obtain the second calculation result corresponding to the calculation model, and determine the second calculation result as the service data to be analyzed.

[0068] In this embodiment, when the query information includes indicator information, the definition of the selected indicator in the indicator metadata is first identified, including the original field, statistical scope, calculation granularity, and standard formula corresponding to the indicator. Then, based on the standard formula associated with the indicator information, the target original service data is processed for indicator calculation. For example, when the indicator information is "transactions per second," the total number of requests within a specified time window is counted from the original data and divided by the time period length (in seconds) to obtain the average processing rate of the service within that time range. Similarly, when the indicator information is "error rate," the number of requests with error status codes (such as 4xx or 5xx) is counted and divided by the total number of requests to obtain the interface anomaly ratio within that time interval. The calculation process can use query statements in the database or be performed in batches by a data processing engine. The final generated numerical result is the first calculation result, which is used as input to the structured service data to be analyzed for subsequent model judgment.

[0069] On the other hand, when the query information contains a preset calculation model, the target original service data will be processed according to the calculation logic defined in the model. The preset calculation model is usually user-defined and describes the combination relationships and calculation processes between multiple data fields, such as "average response time per unit of resource usage" or "the rate of change in the percentage of failed interfaces aggregated by caller." The calculation model is structured and translated into executable calculation expressions by a formula parsing engine, and then the original service data is calculated or aggregated line by line in the database layer or data stream processing. This calculation process can be combined with time windows, conditional filtering, field weighting, moving averages, and other operations to support more complex computational scenarios. After the calculation is completed, one or more numerical or vector results corresponding to the model will be obtained, which are the second calculation results and used as the service data to be analyzed for subsequent model inference modules.

[0070] This embodiment processes the target raw service data based on indicator information and a preset calculation model, achieving the transformation from data to an analytical structure. It ensures the consistency of indicator extraction and the standardization of results, while providing users with the flexibility to customize calculation paths, adapting to various business needs and analytical scenarios. The first and second calculation results provide a clear and quantifiable input basis for service status judgment and anomaly verification, improving overall data processing capabilities.

[0071] Furthermore, in step S14 above, the service status judgment result is obtained by analyzing and processing the service data to be analyzed and the pre-built deep learning model. This will be further explained through an embodiment. Based on the above embodiment, it includes:

[0072] S141, Input the service data to be analyzed into the pre-built deep learning model, so that the pre-built deep learning model can obtain the warning level information related to the service in the service data to be analyzed as the service status judgment result.

[0073] In this embodiment, the pre-built deep learning model refers to a model that has already been trained. This model uses historical service operation data as training samples and can learn multi-dimensional feature patterns and abnormal signals during the service state evolution process. In terms of model structure, Long Short-Term Memory (LSTM), Convolutional Neural Network (CNN), Transformer, or a fusion structure thereof can be used to adapt to the joint modeling requirements of time-series indicators, sudden anomalies, and trend anomalies. The service data to be analyzed is used as the input tensor of the deep learning model, organized into an input matrix according to time windows or service instances. After receiving the input data, the model first extracts features through multiple neural network layers, automatically constructing high-dimensional nonlinear representations between indicators. Based on this, combined with contextual information such as service scale, historical baseline, and coordinated changes in indicators, a comprehensive judgment is made on the current state.

[0074] During the model's inference process, it internally judges the distribution characteristics of the current data based on the discrimination boundaries learned during training, and generates classification results or anomaly scores related to the service status. For example, the model can output a multi-category label representing the service risk level, marking it as a warning level such as normal, low risk, medium risk, or high risk. This level information is the warning level information, which is the result obtained by the model after judging the current service operation status. For different service instances, the judgment warning conditions are different, and the output warning level is also different. For example, the same call volume indicator may be judged as an abnormal state if it corresponds to a service instance with low resource capacity; while for services with sufficient resources or a high historical call baseline, it can be regarded as normal fluctuation. Finally, this warning level information will be used as the service status judgment result for subsequent processing, such as anomaly verification, alarm display, or root cause analysis. This embodiment realizes a multi-level alarm system based on indicator combination features by inputting the service data to be analyzed into a pre-built deep learning model and generating warning level classifications by combining the model application results. It has stronger nonlinear modeling capabilities and dynamic threshold adaptability, enabling it to accurately identify abnormal trends in complex service behaviors and output structured service status levels, thereby improving the accuracy and practicality of service status monitoring.

[0075] In one specific implementation, the pre-built deep learning model can employ a hybrid neural network structure combining a one-dimensional convolutional neural network and a long short-term memory network. This structure is suitable for processing multi-dimensional financial service monitoring data with temporal characteristics. The input is time-series data composed of multiple service metrics (such as CPU utilization, TPS, error rate per second, etc.), in the format T×F, where T represents the time step and F represents the metric dimension at each time point.

[0076] First, the input data enters a one-dimensional convolutional layer. Multiple convolutional kernels slide along the time dimension to extract the fluctuation features of the indicator within a short time window, capturing local patterns of sudden changes in service operation. Then, a pooling layer performs feature downsampling, preserving key trends while reducing model complexity. Next, the pooled feature sequence is fed into an LSTM layer, utilizing its memory mechanism to model the long-term evolution of service status and identify potential anomalies caused by slow changes in indicators or the superposition of multiple factors. The LSTM output is further fed into a fully connected layer for feature fusion and mapping, and the output layer uses a Sigmoid or Softmax function for classification, outputting the corresponding service status judgment result or warning level label.

[0077] In one embodiment, the secondary verification in step S15 above is implemented in the following way: Based on the above embodiment, it includes:

[0078] S151, when the service status judgment result is detected as normal, the first calculation result and / or the second calculation result, as well as the preset warning prompt words are input into the pre-built large language model, so as to judge whether the first calculation result and / or the second calculation result meet the early warning judgment conditions through the pre-built large language model.

[0079] S152, When the first calculation result and / or the second calculation result are detected to meet the early warning judgment conditions, output the early warning verification information that the service is abnormal;

[0080] S153, when the first calculation result and / or the second calculation result are detected to not meet the early warning judgment conditions, output the early warning verification information of normal service.

[0081] In this embodiment, when the service status judgment result is detected as normal, a secondary verification process based on language reasoning mechanism is executed to identify possible service anomalies that are in a critical state but have not yet triggered deep learning model alarms. This secondary verification process uses the first calculation result and / or the second calculation result as input data, and combines it with preset warning prompts. It performs semantic-level anomaly judgment through a pre-built large language model, thereby generating more interpretable and forward-looking warning verification information. The first and second calculation results are numerical results calculated from the target original service data based on indicator information and the preset calculation model, respectively. The preset warning prompts are guiding statement templates set for the large language model, used to semantically constrain and limit the intent of the input, prompting the model to conduct a comprehensive analysis from perspectives such as "whether there are unidentified boundary risks," "whether the current indicator is close to the anomaly threshold," and "whether it shows an unstable trend."

[0082] In the specific implementation process, the first and / or second calculation results are encoded into a textual structure (such as key-value pair descriptions, expressions embedded in natural language, etc.), which, together with preset warning prompts, construct the language model input context. This context is then input into a pre-built large language model for processing. The pre-built large language model possesses large-scale language understanding and semantic reasoning capabilities. Based on contextual semantic relationships and anomaly recognition knowledge learned during training, it performs multi-dimensional judgments on the trend characteristics and numerical states of input indicators. When the large language model identifies during the reasoning process that the current input calculation result is approaching the boundary range of historical anomaly samples, or exhibits characteristics such as gradually approaching the threshold, increasing frequency of occurrence, and amplified indicator fluctuations, it considers the first and / or second calculation results to meet the early warning judgment conditions and outputs a warning verification message of "Service anomaly exists." This warning verification message is typically described in natural language, including risk level judgment, indicators of concern, and a brief description of their trends, used to convey possible anomalies to the user.

[0083] Conversely, if the large language model, after comprehensive analysis, determines that the current indicator remains within a relatively stable and safe fluctuation range, without a significant upward or deteriorating trend, then the input result is considered not to meet the early warning judgment conditions, and a "service normal" warning verification message is output. This information can be used to display a green notification on the front-end interface, indicating that the current operating status is normal. Through this embodiment, after the deep learning model determines that the state is normal, the language reasoning capability of the large language model is further used to perform soft boundary analysis and semantic supplementation judgment on the calculation results, enhancing the ability to identify critical states and trend anomalies. This process constructs a safe redundancy between model layers, effectively compensating for the shortcomings of deep learning models in critical judgment capabilities, while improving interpretability and user trust.

[0084] Figure 2This is a schematic flowchart illustrating a method for obtaining and visualizing alarm troubleshooting information provided in an embodiment of this application. Based on the above embodiments, as follows... Figure 2 As shown, after analyzing and processing the service data to be analyzed and the pre-built deep learning model to obtain the service status judgment result, the following steps are also included:

[0085] S21. When the service status judgment result is detected as abnormal, the service alarm investigation information is obtained based on the service data to be analyzed, the preset alarm prompt words and the pre-built large language model.

[0086] S22, the service alarm investigation information is sent to the human-computer interaction interface for visual processing to complete the alarm.

[0087] In this embodiment, when an abnormal service status is detected, an alarm troubleshooting process is further triggered to generate service alarm troubleshooting information based on the service data to be analyzed and the reasoning capabilities of the language model. This process aims to assist users in quickly locating the cause of the anomaly and providing preliminary handling suggestions for reference, thereby improving fault response efficiency. Specifically, the service data to be analyzed is a set of indicators extracted and structured from the target raw service data during the preprocessing stage, reflecting the real-time status of the current service operation, including but not limited to parameters such as interface call volume, error rate, response time, and resource utilization ratio. When the service status judgment result indicates an anomaly, the service data to be analyzed, along with preset alarm prompts, is input into the pre-built large language model for further reasoning. The preset alarm prompts are natural language templates used to guide the large language model in fault analysis. Their content typically includes requesting the model to identify the cause of the anomaly, analyzing potentially affected components, analyzing the causal relationship between the abnormal indicators, and suggesting possible troubleshooting paths.

[0088] The pre-built large language model possesses complex semantic understanding and reasoning capabilities, enabling it to perform analogical analysis between service status, indicator trends, and historical failure modes based on prompts. During model operation, it can generate textual service alarm troubleshooting information by combining the numerical intensity, fluctuation characteristics, and joint distribution of abnormal indicators. This information includes a semantic summary of the current anomaly, the analyzed root cause of the failure, the possible scope of impact, and suggested troubleshooting steps or measures. For example, if an increased error rate is detected at a certain interface, it might output, "The service is experiencing high-frequency 5xx errors. Analysis shows that the failure was caused by the database connection pool being exhausted. It is recommended to check the number of database connections and response latency." The generated service alarm troubleshooting information is then sent to the human-computer interaction interface for visualization. After receiving the information, the front-end interface parses it into structured display content, typically including an alarm summary, highlighted abnormal indicators, model-generated failure cause analysis text, and suggested action blocks. Users can quickly browse alarm details in the interface, perform multi-dimensional filtering or time-retrospective operations, or directly click on action suggestions to initiate linked response actions. This implementation, upon identifying anomalies, automatically generates and displays service alarm troubleshooting information based on the interpretation capabilities of a pre-built large language model, thus transforming the process from alarm detection to alarm cause localization and response. This workflow not only improves the depth and semantic richness of responses to alarm events but also reduces the cost of relying on manual experience for problem localization, enhancing the overall automation and maintainability of alarms.

[0089] Furthermore, obtaining early warning and investigation information includes:

[0090] S211, Based on the first calculation result and / or the second calculation result, and based on the alarm information and preset prompt words of the deep learning model, use a pre-built large language model to output the reason for the service problem;

[0091] S212, perform root cause analysis based on the cause of the service problem, obtain root cause analysis information, and obtain troubleshooting solutions corresponding to the cause of the service problem;

[0092] S213 outputs service issues, root cause information, and troubleshooting solutions to the human-computer interaction interface.

[0093] In this embodiment, after identifying an abnormal service state, the system further combines the first and / or second calculation results, along with alarm information and preset prompts generated by the deep learning model, to call a pre-built large language model to perform semantic layer analysis on the current abnormal situation, outputting the cause of the service problem, and then performing root cause localization and troubleshooting solution generation based on this cause. That is, the above input content is assembled into a unified semantic reasoning context and input into the pre-built large language model. The pre-built large language model can analyze the cause of the service anomaly based on the input content. For example, if the alarm information indicates an increase in the error rate of a certain interface, and the second calculation result shows an abnormal increase in database connection time, the model may output a description of the problem cause: "The current service anomaly may be caused by a database connection bottleneck, resulting in request processing delay and triggering interface timeout." The output of the service problem cause is mainly in natural language generated text, which is clear, semantically complete, and facilitates users' quick understanding of the current fault phenomenon.

[0094] After determining the cause of the service issue, root cause analysis is performed. Root cause analysis refers to the specific problem identified based on the cause, such as "connection pool resource exhaustion," "downstream interface unreachable," or "decreased cache hit rate." The root cause analysis process can combine historical case knowledge, model memory capabilities, or existing indicator cross-analysis logic to further refine the source and scope of the problem. Based on this, a corresponding troubleshooting solution will be obtained. This solution includes suggested dimensions for inspection (such as database connection count, thread count, and interface dependency chains), possible configuration adjustments, and alternative recovery methods, guiding operations personnel or automation platforms in subsequent operations. Finally, the service issue, root cause analysis information, and troubleshooting solutions are packaged into structured, visualized data and displayed on a user interface. On the front-end interface, users can view anomaly summaries, root cause analysis processes, and suggested actions. They can also interactively expand to view relevant indicator curves, model-assisted judgment criteria, or export a troubleshooting report. This embodiment utilizes a large language model to perform semantic interpretation and causal analysis on service anomalies, outputting understandable and actionable service problem descriptions, root cause information, and troubleshooting suggestions, forming a response chain from problem identification to action. This mechanism effectively improves the automation capabilities in anomaly handling, reduces reliance on human experience, and enhances overall analysis efficiency and problem response speed in complex fault scenarios.

[0095] In one embodiment, before obtaining the query information input by the user, the method further includes:

[0096] S10 collects raw service data from the interface service in real time and stores the raw service data in the database.

[0097] In this embodiment, real-time data collection of the interface service's operational status is continuously performed, and the collected raw service data is stored in a database as the foundational data source for subsequent queries, calculations, and analyses. Raw service data refers to the unprocessed underlying operational metrics and interaction information generated during the interface service's operation. It is characterized by high timeliness, fine granularity, and broad coverage, comprehensively reflecting the service's operational status at different points in time. During data collection, the deployed data collection module acquires the service interface's operational data in real time through collection proxies integrated with each service node. The collected content typically includes, but is not limited to: request timestamps, interface paths, request methods, caller and receiver IP addresses, response times, response status codes, data packet sizes, user identifiers, CPU utilization, and memory usage. Depending on the service deployment architecture, collection methods may employ log retrieval, system call hooks, message queue subscriptions, or instrumented reporting mechanisms. To ensure the integrity and continuity of the collected data, an asynchronous collection and buffered writing strategy is adopted to achieve high-frequency, low-latency data collection without affecting the performance of the main business process.

[0098] The collected raw service data undergoes basic verification and format standardization processing before being archived and stored according to timestamps and service identifiers, and then written to the backend database. This database supports high-concurrency writes and multi-dimensional index retrieval, capable of supporting data storage needs for concurrent access by multiple users and services. The raw service data is stored in structured tables or log records, supporting efficient queries based on fields such as time range, service name, and interface path. This embodiment constructs a time-series data warehouse for service behavior by collecting various types of raw data during the real-time operation of interface services and performing standardized database processing. This provides a data foundation for subsequent indicator calculations, model analysis, and alarm judgment, ensuring the accuracy, completeness, and timeliness of the data, and effectively improving real-time analysis and response capabilities in multi-source, multi-dimensional, and high-frequency data scenarios.

[0099] In one embodiment, during the visualization process, the first and second calculation results are also visualized on the human-computer interaction interface, specifically including:

[0100] Based on the first calculation result and / or the second calculation result, a pre-built large language model is used to obtain the chart information corresponding to the first calculation result and / or the second calculation result, and the chart information is sent to the human-computer interaction interface for visualization display.

[0101] In this embodiment, based on the first calculation result and / or the second calculation result, a pre-built large language model is further used to obtain chart information corresponding to the calculation result, and the chart information is sent to the human-computer interaction interface for visualization display to enhance the user's understanding and perception of the analysis results. This processing flow aims to combine the numerical results output by the model with graphical representation, providing an intuitive and highly interactive visualization format to assist users in understanding trends, identifying anomalies, and making decisions. Specifically, the first calculation result and / or the second calculation result are used as input content, along with preset chart generation prompts, and are input into the pre-built large language model. The pre-built large language model has text understanding and structure mapping capabilities. After receiving the prompt information, it can automatically identify the type, trend, indicator meaning, and time distribution of the input data, and based on the chart generation knowledge accumulated during training, analyze the chart type and layout suggestions most suitable for the data structure. For example, for response latency data that changes over time, a line chart or bar chart may be generated; for resource utilization comparisons of multiple services, a stacked bar chart or radar chart may be selected for representation.

[0102] Chart information refers to the chart structure definition results generated by the large language model, including chart type, axis settings, data grouping method, legend, color coding, and necessary annotations. This chart information can be organized using a structured data format (such as JSON) and presented in the human-computer interaction interface after being parsed by the backend chart rendering engine. Users can dynamically adjust the time window, switch dimensions, filter service instances, or export chart content through interface interaction. This embodiment realizes the automatic generation and display conversion from model calculation results to visual charts, improving the intuitiveness of analysis results. This mechanism effectively expands the visualization capabilities of multi-dimensional indicators by setting a pre-built large language model for chart semantic modeling, enabling users to efficiently identify abnormal trends, compare service performance, and assist in decision-making within a graphical interface.

[0103] Figure 3 A schematic diagram of the structure of the financial service data processing device provided in this application is shown below. Figure 3 As shown, the processing device 3 provided in this embodiment includes:

[0104] Data acquisition module 31 is used to acquire query information input by the user;

[0105] Database module 32 is used to extract the target raw service data corresponding to the query information from the database based on the query information and the pre-stored user permission information;

[0106] Backend processing module 33 is used to preprocess the query information and target raw service data to determine the service data to be analyzed.

[0107] The backend processing module 33 is used to analyze and process the service data to be analyzed and the pre-built deep learning model to obtain the service status judgment result.

[0108] The backend processing module 33 is used to perform secondary verification processing based on the service data to be analyzed, preset prompt words, and pre-built large language model when the service status judgment result is detected as normal, so as to obtain the warning verification information.

[0109] The front-end display module 34 is used to send the warning verification information to the human-computer interaction interface for visualization processing when the warning verification information is detected as indicating that there is an anomaly in the service, thus completing the warning.

[0110] The processing device 3 provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0111] Figure 4 A schematic diagram of the structure of the electronic device provided in this application. Figure 4 As shown, the electronic device 4 provided in this embodiment includes at least one processor 41 and a memory 42. Optionally, the electronic device 4 further includes a communication component 43. The processor 41, memory 42, and communication component 43 are connected via a bus 44.

[0112] In a specific implementation, at least one processor 41 executes computer execution instructions stored in memory 42, causing at least one processor 41 to perform the above-described method.

[0113] The specific implementation process of processor 41 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0114] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0115] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0116] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0117] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0118] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0119] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0120] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0121] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0122] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0123] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0124] When the integrated unit / module is implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic storage medium or magneto-optical storage medium.

[0125] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device. Based on this understanding, the technical solution of this application, 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 memory 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 of the various embodiments of this application.

[0126] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only. It should be understood that this application is not limited to the precise structures described above and shown in the drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A financial services data processing method, characterized in that, include: Obtain the query information entered by the user; Based on the query information and the pre-stored user permission information, extract the target original service data corresponding to the query information from the database; Preprocessing is performed based on the query information and the target raw service data to determine the service data to be analyzed; The service status judgment result is obtained by analyzing and processing the service data to be analyzed and the pre-built deep learning model. When the service status judgment result is detected as normal, a secondary verification process is performed based on the service data to be analyzed, preset prompt words, and pre-built large language model to obtain early warning verification information; When the warning verification information indicates that there is an anomaly in the service, the warning verification information is sent to the human-computer interaction interface for visualization processing to complete the warning.

2. The method according to claim 1, characterized in that, The step of retrieving the target original service data corresponding to the query information from the database based on the query information and pre-stored user permission information includes: Based on the pre-stored user permission information, determine the user's database access permissions; When the database access permission is detected to be administrator privileges, the original service data of all users corresponding to the query information are extracted from the database as the target original service data based on the query information; or, When the database access permission is detected to be ordinary user permission, the original service data of the user corresponding to the query information is extracted from the database as the target original service data based on the query information.

3. The method according to claim 1, characterized in that, The query information includes indicator information and / or a preset calculation model; The step of preprocessing based on the query information and the target original service data to determine the service data to be analyzed includes: Based on the indicator information, the target raw service data is processed by indicator calculation to obtain a first calculation result corresponding to the indicator information, and the first calculation result is determined as the service data to be analyzed; and / or The target raw service data is processed by model calculation according to the calculation model to obtain a second calculation result corresponding to the calculation model, and the second calculation result is determined as the service data to be analyzed.

4. The method according to claim 3, characterized in that, The step of analyzing and processing the service data to be analyzed and the pre-built deep learning model to obtain the service status judgment result includes: The service data to be analyzed is input into a pre-built deep learning model, so that the pre-built deep learning model can obtain the warning level information related to the service in the service data to be analyzed as the service status judgment result.

5. The method according to claim 3, characterized in that, When the service status judgment result is detected as normal, a secondary verification process is performed based on the service data to be analyzed, preset prompt words, and a pre-built large language model to obtain early warning verification information, including: When the service status judgment result is detected to be normal, the first calculation result and / or the second calculation result, as well as the preset warning prompt word, are input into the pre-built large language model so as to determine whether the first calculation result and / or the second calculation result meet the early warning judgment conditions through the pre-built large language model. When the first calculation result and / or the second calculation result are detected to meet the early warning judgment condition, an early warning verification message indicating an anomaly in the service is output; or, When the first calculation result and / or the second calculation result are detected to not meet the early warning judgment conditions, a service normal early warning verification message is output.

6. The method according to claim 1, characterized in that, After analyzing and processing the service data to be analyzed and the pre-built deep learning model to obtain the service status judgment result, the process further includes: When the service status judgment result is detected to be abnormal, service alarm investigation information is obtained based on the service data to be analyzed, the preset alarm prompt words and the pre-built large language model. The service alarm investigation information is sent to the human-computer interaction interface for visualization processing to complete the alarm.

7. The method according to any one of claims 1 to 6, characterized in that, Before obtaining the query information input by the user, the process also includes: The system collects raw service data from the interface service in real time and stores the raw service data in the database.

8. A financial services data processing device, characterized in that, include: The data acquisition module is used to obtain the query information input by the user; The database module is used to extract the target original service data corresponding to the query information from the database based on the query information and the pre-stored user permission information; The backend processing module is used to preprocess the query information and the target original service data to determine the service data to be analyzed. The backend processing module is used to analyze and process the service data to be analyzed and the pre-built deep learning model to obtain the service status judgment result. The backend processing module is used to perform secondary verification processing based on the service data to be analyzed, preset prompt words, and pre-built large language model when the service status judgment result is detected as normal, so as to obtain early warning verification information. The front-end display module is used to send the warning verification information to the human-computer interaction interface for visualization processing when the warning verification information is detected as indicating an anomaly in the service, thus completing the warning process.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

Images