Financial data analysis integration method based on large language model

Abstract

The invention discloses a financial data analysis integration method based on a large language model, and the method comprises the steps: carrying out the deep intention recognition of a natural language instruction of a user, precisely analyzing a multi-dimensional business entity including mechanism recognition, and seamlessly translating an analysis result into programmed calling of a series of standardized background service APIs. The method has the advantages of high precision and high efficiency.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data analysis, and particularly relates to a financial data analysis integration method based on a large language model. BACKGROUND

[0002] The existing Text-to-SQL (natural language text conversion to structured SQL; SQL, Structured Query Language) technology has inherent defects of low accuracy and high risk when processing complex financial queries. The traditional data service mode sets a high use threshold for non-technical background business personnel, and the response cycle is long, which restricts the instant conversion of data value. The present application provides a natural language driven self-service data exploration system, which compresses the data acquisition cycle and improves the agility of business decision-making by supporting conversational interaction. The traditional data query tool has fixed functions and lacks the ability to dynamically adapt to user needs and evolve itself.

[0003] The heterogeneous information system architecture commonly existing in financial institutions leads to a highly complex data environment, which is characterized by complex data model structure, and a complete view of a single business theme often needs to associate tens of data tables, and different source systems have significant differences in field naming and business scope in the definition of the same business entity. Therefore, effective data analysis is heavily dependent on the construction of complex cross-table association queries, which sets a significant technical barrier for non-technical background business personnel and directly leads to a long and inefficient data acquisition process, forming a key data service bottleneck that restricts business development.

[0004] The specific problems are as follows:

[0005] 1. Low accuracy and reliability in complex query scenarios

[0006] The data analysis of financial business often involves multi-table association, deep nested queries and complex business logic encapsulation. The existing Text-to-SQL model has difficulty in stably generating completely accurate and efficient SQL code when processing such highly complex queries. The SQL generated by the model is prone to logical errors or low performance, resulting in unreliable query results. In the financial field, incorrect SQL execution and inaccurate data results are unacceptable and pose a high business risk.

[0007] 2. High security and compliance risk, difficult to control

[0008] The core of Text-to-SQL technology is generating SQL code to directly manipulate the underlying database. This bypasses the fine-grained access control and data security auditing mechanisms that financial institutions typically set up at the application service layer. SQL automatically generated by the model and not rigorously reviewed may lead to unauthorized access, sensitive data leaks, and even high-risk database operations. This method of directly exposing database operation interfaces makes it difficult to meet the stringent data security and compliance requirements of the financial industry.

[0009] 3. The system has high maintenance costs and poor adaptability.

[0010] This technology requires large models to have a precise understanding of the underlying physical database table structure and complex business semantics. In financial institutions, business rules and data models frequently change. Once the underlying data structure changes or business definitions are adjusted, the Text-to-SQL model or its related hints engineering needs to be frequently re-adapted and validated, resulting in extremely high operation and maintenance costs and poor system robustness.

[0011] 4. Inability to effectively utilize existing data service assets

[0012] Many financial institutions have invested heavily in building data platforms and encapsulated standardized data services and mature business logic through APIs. Text-to-SQL technology, which directly targets the database, neglects these stable, secure, and pre-packaged API service assets, resulting in redundant construction of technical resources and a waste of existing investments.

[0013] This invention employs an integrated financial data analysis method based on a large language model, mapping natural language to pre-defined service API calls, thus ensuring the accuracy of business logic execution and system stability from an architectural perspective. User feedback is used as a key input for model iteration, enabling the system to continuously evolve and better meet ever-changing business needs. Summary of the Invention

[0014] The purpose of this invention is to provide an integrated method for financial data analysis based on a large language model, which has the advantages of high accuracy and high efficiency.

[0015] To achieve the above objectives, this invention provides an integrated financial data analysis method based on a large language model. This method performs deep intent recognition on user natural language commands and accurately parses out multi-dimensional business entities, including institutional identification. The parsing results are seamlessly translated into a series of standardized backend service API programmatic calls. The "backend" refers to the backend of the data processing system. The method includes: Step S1, receiving user natural language commands and performing preliminary parsing to obtain request object data; the request object data contains key contextual metadata and is obtained by parsing the user's natural language commands; Step S2, processing the request object data to obtain complete API parameters and API mappings; Step S3, validating the complete API parameters and obtaining corresponding visualization data based on the API mappings; Step S4, integrating and processing the visualization data for output.

[0016] Preferably, step S1 includes: step S11, receiving user natural language instructions and capturing user instructions; step S12, encapsulating the captured user instructions to form request object data; specifically, automatically encapsulating a series of key context metadata to form a structured request object data; step S13, adding a secure transmission component to the request object data and transmitting it.

[0017] Preferably, the request object data includes: User id: a unique identifier for the current user, used for subsequent permission authentication; Session id: a unique identifier for the current session, used to support possible multi-round follow-up dialogues; UserProfile: user profile information, used to parse entities that may be ambiguous or require permission scope limitation; QueryText: the user's original query text string; Timestamp: the timestamp of the request initiation, used for auditing and logging.

[0018] Preferably, step S2 includes: step S21, analyzing Query Text and UserProfile based on request object data to obtain preprocessed text; step S22, analyzing the preprocessed text using a large language model to obtain core intent data; step S23, extracting all parameters related to the core intent data from the request object data based on the core intent data to form a parameter dictionary; step S24, organizing the parameter dictionary into a parameter set through domain entities; and step S25, obtaining complete API parameters and API mapping based on the core intent data and parameter set.

[0019] Preferably, the domain entity is an organization or a time.

[0020] Preferably, step S24 includes: step S241, querying the organizational tree knowledge base according to the parameter dictionary; step S242, mapping the parameter dictionary to the organizational tree knowledge base through a large language model; and step S243, outputting the parameter set after mapping.

[0021] Preferably, step S25 includes: step S251, querying the API metadata directory; step S252, matching the core intent data and parameter set with the API metadata directory; and step S253, generating complete API parameters and API mapping paths.

[0022] Preferably, the organization tree knowledge base should contain detailed information about the entity category "organization", including: organization name, unique organization number, and hierarchical relationship; the API metadata directory includes: natural language function description of the API and detailed definition of input parameters.

[0023] Preferably, step S3 includes: step S31, adjusting and standardizing the complete API parameters; step S32, performing multi-level permission verification, which includes at least: function permission verification, checking whether the data representing Userid in the core intent data has permission to call the service API; data permission verification, checking whether the data representing Userid in the core intent data has permission to access the corresponding query backend data; if successful, proceed to step S33; if unsuccessful, the process ends. S33, API mapping invocation and execution; S34, obtaining visualization data.

[0024] Preferably, step S4 includes: step S41, receiving visualization data and performing structural analysis; step S42, intelligent decision-making for the visualization scheme, including: analyzing the data structure and identifying that the data consists of multiple discrete key indicators for a single entity; integrating user intent to obtain the user's original core intent from core intent data; deciding on the optimal chart: for the data display, deciding on a visualization display scheme of "key indicator card" or "dashboard"; S43, outputting the results.

[0025] In summary, compared with existing technologies, the integrated financial data analysis method based on a large language model provided by this invention has the following beneficial effects:

[0026] First, the integrated financial data analysis method based on a large language model proposed in this invention ensures the determinism of business logic execution and the accuracy of data results by mapping query intent to pre-defined service APIs. This transforms the task of the large model from uncertain code generation to high-precision service addressing, fundamentally solving the application bottleneck of existing technologies in serious fields such as finance.

[0027] Secondly, the integrated financial data analysis method based on a large language model proposed in this invention achieves end-to-end, financial-grade security control over data access by constructing an API scheduling layer that includes permission verification and security auditing. All data requests are executed through a controlled API gateway, ensuring the traceability and compliance of every operation and overcoming the inherent shortcomings of existing technologies in terms of security.

[0028] Third, the integrated financial data analysis method based on a large language model proposed in this invention utilizes the abstraction layer of service APIs to achieve technical decoupling between upper-layer semantic understanding and lower-layer data implementation. This design enables the system to have greater flexibility and lower maintenance costs when responding to changes in backend business rules or data structures, significantly improving the system's long-term availability and robustness.

[0029] Fourth, the integrated financial data analysis method based on a large language model proposed in this invention achieves a value leap from "data acquisition" to "interactive insight" by introducing an intelligent visualization engine that is linked to user intent. It can automatically transform data into the most insightful visualization form, greatly improving data readability and user analysis efficiency—something existing technical solutions lack. Attached Figure Description

[0030] Figure 1 This is a flowchart of the integrated financial data analysis method based on a large language model proposed in this invention. Detailed Implementation

[0031] The following will be combined with the appendix in the embodiments of the present invention. Figure 1 The technical solutions, structural features, objectives and effects achieved in the embodiments of the present invention will be described in detail.

[0032] It should be noted that the accompanying drawings are in a very simplified form and use non-precise proportions. They are only used to facilitate and clarify the purpose of illustrating the embodiments of the present invention, and are not intended to limit the implementation conditions of the present invention. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportional relationship, or adjustments to the size should still fall within the scope of the technical content disclosed in the present invention, provided that they do not affect the effects and objectives that the present invention can produce.

[0033] It should be noted that, in this invention, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only the expressly listed elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus.

[0034] This invention proposes an integrated financial data analysis method based on a large language model. The method performs deep intent recognition on user natural language commands and can accurately parse out multi-dimensional business entities, including institutional identification. The parsing results are seamlessly translated into a series of standardized back-end service API (Application Programming Interface) programmatic calls. The so-called back-end refers to the back-end of the data processing system.

[0035] Specifically, the core workflow of this invention is a complete closed loop from unstructured natural language input to structured, visualized data output. The method includes:

[0036] Step S1: Accept the user's natural language command and perform preliminary parsing to obtain the requested object data;

[0037] This stage is responsible for receiving user natural language commands and encapsulating them into standardized request objects that can be transferred within the method procedure, preparing for subsequent in-depth processing. The request object data contains key contextual metadata, obtained by parsing the user's natural language commands.

[0038] Step S2: Process the request object data to obtain complete API parameters and API mapping;

[0039] This stage is driven by a large language model, which performs in-depth intent recognition and entity extraction on the user's query request (request object data) and standardizes domain entities (such as organizations), ultimately determining one or more backend service APIs that need to be called and their required parameters.

[0040] Step S3: Validate the complete API parameters and obtain the corresponding visualization data according to the API mapping;

[0041] This stage, acting as the execution layer, is responsible for verifying permissions and formatting parameters for the complete API parameters, and for securely and reliably calling the backend service API to obtain the corresponding data.

[0042] Step S4: Integrate and process the visualized data and output it.

[0043] This stage is the value presentation layer, which is responsible for integrating and processing the raw data obtained from the backend, and presenting it to the user in the best visualization way according to the user's intent and data characteristics, supporting further interactive exploration.

[0044] In a specific embodiment, step S1 includes:

[0045] Step S11: Accept user natural language commands and capture user commands;

[0046] Specifically, users input query commands through the natural language input interface provided by the interaction and presentation unit, thereby capturing user commands.

[0047] Step S12: Encapsulate the captured user instructions to form request object data;

[0048] In this step, a series of key context metadata are automatically encapsulated to form a structured request object data;

[0049] This request object data contains:

[0050] User id: A unique identifier for the current user, used for subsequent authorization.

[0051] Session id: A unique identifier for the current session, used to support possible multi-turn follow-up dialogues.

[0052] User Profile: Brief information about the user, such as their affiliated organization ("Branch X" and its organization number), used to resolve entities that may be ambiguous or require restricted access.

[0053] Query Text: The user's original query text string.

[0054] Time stamp: The timestamp at which the request was initiated, used for auditing and logging.

[0055] Step S13: Add the request object data to the secure transmission component and transmit it.

[0056] In a specific embodiment, step S2 includes:

[0057] Step S21: Analyze the Query Text and User Profile based on the request object data to obtain the preprocessed text;

[0058] Step S22: The large language model analyzes the preprocessed text to obtain core intent data;

[0059] Step S23: Based on the core intent data, extract all parameters related to the core intent data from the request object data to form a preliminary, non-standardized parameter dictionary.

[0060] This step can be understood as the comprehensive extraction of multi-dimensional parameter entities. While recognizing intent, the large language model performs "slot filling".

[0061] The parameter dictionary is as follows:

[0062] Target entity: XX line

[0063] Time range: last quarter

[0064] Business areas: Corporate banking

[0065] Query the list of indicators: ['X', 'Y']

[0066] Step S24: Based on the parameter dictionary, organize the parameters into a parameter set through domain entities;

[0067] In a preferred embodiment, the domain entity can be an organization, time, etc.; the following describes a specific embodiment when the domain entity is an organization.

[0068] Step S24 includes:

[0069] Step S241: Query the organization tree knowledge base according to the parameter dictionary;

[0070] The organizational tree knowledge base should contain detailed information for the entity category "Organization", including: organization name, unique organization number, and hierarchical relationship.

[0071] Step S242: Using the large language model, map the parameter dictionary to the organizational tree knowledge base;

[0072] For example, entity linking and disambiguation utilize a large language model to perform "entity linking" between the target entity "XX row" in the parameter dictionary and the record in the organizational tree knowledge base for disambiguation. If "XX row" is a specific name, the large language model will directly match it. If multiple ambiguous organizations with the same name exist, the large language model will further utilize the remaining information in the parameter dictionary to make a match.

[0073] Step S243: Output the parameter set after completion;

[0074] Ultimately, the output of this step is a recognizable organization number. For example, the parameter set may include organization number 1234, which is a standardized ID that can be used for subsequent API mapping.

[0075] Step S25: Obtain complete API parameters and API mapping based on core intent data and parameter set;

[0076] Step S251: Query the API metadata directory.

[0077] The API metadata directory includes: natural language function descriptions of the API, detailed definitions of input parameters, etc.

[0078] Step S252: Match the core intent data and parameter set with the API metadata directory;

[0079] Step S253: Generate complete API parameters and API mapping paths.

[0080] In a specific embodiment, step S3 includes:

[0081] Step S31: Adjust and standardize the complete API parameters.

[0082] The purpose here is to ensure the correct order of subsequent verifications.

[0083] Step S32: Perform multi-level permission verification, the verification including at least:

[0084] Function permission verification verifies whether the user ID data in the core intent data has permission to call the service API.

[0085] Data permission verification checks whether the data representing the User ID in the core intent data has permission to access the corresponding data in the query backend;

[0086] If successful, proceed to step S33; if unsuccessful, the process ends.

[0087] The process will only continue if all permission checks pass. Failure in any one of them will immediately halt the process and return an insufficient permissions message to the user.

[0088] S33, API mapping invocation and execution;

[0089] A secure, authenticated request is initiated to the corresponding service API endpoint in the backend interface layer through a centralized API gateway.

[0090] S34, Obtain visualized data;

[0091] Data acquisition and response processing execute complex business logic in the background, ultimately outputting the query results in a unified format.

[0092] Step S4 includes:

[0093] Step S41: Receive the visualization data and perform structural analysis;

[0094] Step S42, intelligent decision-making for visualization solutions, includes:

[0095] Analyze the data structure to identify that the data consists of multiple discrete key metrics for a single entity.

[0096] Integrate user intent to obtain the user's original core intent from core intent data;

[0097] Optimal Chart Decision: For data presentation, decide on a visualization scheme such as "key indicator cards" or "dashboards".

[0098] S43, Output the result.

[0099] In a specific embodiment, for example, a query command can be entered through the system's interactive interface: "Analyze the total loan amount and non-performing loan ratio of corporate business of XX bank in the last quarter."

[0100] In step S4, the visualized data includes two values: the total loan amount and the non-performing loan ratio of Bank XX. This generates a separate, eye-catching card for each indicator, clearly displaying the indicator name and value. Then, the charts are dynamically rendered and interactive. In this example, two cards are generated: Card 1: Titled "Total Corporate Loans"; Card 2: Titled "Non-Performing Loan Ratio". Interactive capabilities: The system can trigger a process of recommending questions to the user, further enabling in-depth, exploratory data analysis.

[0101] Although the present invention has been described in detail through the preferred embodiments above, it should be understood that the above description should not be considered as a limitation of the present invention. Various modifications and substitutions to the present invention will be apparent to those skilled in the art after reading the above description. Therefore, the scope of protection of the present invention should be defined by the appended claims.

Claims

1. An integrated financial data analysis method based on a large language model, characterized in that: The method performs deep intent recognition on user natural language commands and can accurately parse out multi-dimensional business entities, including organizational recognition, and seamlessly translate the parsing results into a series of standardized backend service API programmatic calls; the so-called backend refers to the backend of the data processing system. The method includes: Step S1: Accept the user's natural language command and perform preliminary parsing to obtain the requested object data; The requested object data is data containing key contextual metadata, obtained by parsing the user's natural language commands; Step S2: Process the request object data to obtain complete API parameters and API mapping; Step S3: Validate the complete API parameters and obtain the corresponding visualization data according to the API mapping; Step S4: Integrate and process the visualized data and output it.

2. The integrated financial data analysis method based on a large language model according to claim 1, characterized in that, Step S1 includes: Step S11: Accept user natural language commands and capture user commands; Step S12: Encapsulate the captured user instructions to form request object data; Specifically, it automatically encapsulates a series of key context metadata to form a structured request object data; Step S13: Add the request object data to the secure transmission component and transmit it.

3. The integrated financial data analysis method based on a large language model according to claim 2, characterized in that, The request object data includes: User id: A unique identifier for the current user, used for subsequent authorization authentication; Session id: A unique identifier for the current session, used to support possible multi-turn follow-up dialogues; User Profile: Brief information about the user, used to resolve entities that may be ambiguous or require permission restrictions; Query Text: The user's original query text string; Time stamp: The timestamp at which the request was initiated, used for auditing and logging.

4. The integrated financial data analysis method based on a large language model according to claim 3, characterized in that, Step S2 includes: Step S21: Analyze the Query Text and User Profile based on the request object data to obtain the preprocessed text; Step S22: The large language model analyzes the preprocessed text to obtain core intent data; Step S23: Based on the core intent data, extract all parameters related to the core intent data from the request object data to form a parameter dictionary: Step S24: Based on the parameter dictionary, organize the parameters into a parameter set through domain entities; Step S25: Obtain complete API parameters and API mapping based on the core intent data and parameter set.

5. The integrated financial data analysis method based on a large language model according to claim 4, characterized in that, The entities in this domain are organizations and time.

6. The integrated financial data analysis method based on a large language model according to claim 5, characterized in that, Step S24 includes: Step S241: Query the organization tree knowledge base according to the parameter dictionary; Step S242: Using the large language model, map the parameter dictionary to the organizational tree knowledge base; Step S243: Output the corresponding parameter set after completion.

7. The integrated financial data analysis method based on a large language model according to claim 6, characterized in that, Step S25 includes: Step S251: Query the API metadata directory. Step S252: Match the core intent data and parameter set with the API metadata directory; Step S253: Generate complete API parameters and API mapping paths.

8. The integrated financial data analysis method based on a large language model according to claim 7, characterized in that, The organization tree knowledge base should contain detailed information about the entity category "organization", including: organization name, unique organization number, and hierarchical relationship; the parameter set includes: organization number 1234, which is the standardized ID and can be used for subsequent API mapping; the API metadata directory includes: natural language function description of the API and detailed definition of input parameters.

9. The integrated financial data analysis method based on a large language model according to claim 8, characterized in that, Step S3 includes: Step S31: Perform formal adjustments and standardization on the complete API parameters; Step S32: Perform multi-level permission verification, the verification including at least: Function permission verification verifies whether the user ID data in the core intent data has permission to call the service API. Data permission verification verifies whether the data representing the User ID in the core intent data has permission to access the corresponding data in the query backend; If successful, proceed to step S33; if it fails, the process ends. S33, API mapping invocation and execution; S34, Obtain visualized data.

10. The integrated financial data analysis method based on a large language model according to claim 9, characterized in that, Step S4 includes: Step S41: Receive the visualization data and perform structural analysis; Step S42, intelligent decision-making for visualization solutions, includes: Analyze the data structure to identify that the data consists of multiple discrete key indicators for a single entity; By integrating user intent, the user's original core intent can be obtained from the core intent data; Optimal chart for decision-making: For data presentation, decide on a visualization scheme of "key indicator cards" or "dashboards"; S43, Output the result.

Images