Financial data query-oriented natural language question and answer processing method and device

Abstract

The invention relates to a financial data query-oriented natural language question and answer processing method and device. The method comprises the following steps of: obtaining an original query statement input by a user; intention analysis processing is carried out on the original query statement, the original query statement is converted into a target query statement, and intention analysis processing comprises intention recognition, intention rewriting and intention clarification; extracting a financial entity from the target query statement, and retrieving and matching the financial entity in a pre-constructed financial data metadata database to obtain a mapping result of the financial entity in the financial data metadata database; generating a target SQL statement in combination with the target query statement and the mapping result; and executing the target SQL statement in a pre-constructed financial database to generate a query result. Through the method, financial requirements can be accurately understood, the problems of financial term ambiguity, table association logic complexity and the like are effectively solved, the accuracy, stability and interactive experience of financial data query are integrally and remarkably improved, and the financial data analysis threshold is reduced.

Description

Technical Field

[0001] This invention relates to the field of natural language processing technology, and more specifically, to a natural language question-answering processing method and apparatus for financial data queries. Background Technology

[0002] In the current context of profound digital transformation, financial data has become a core support for corporate decision-making, risk management, and compliance auditing, and its scale and complexity are growing exponentially. Corporate financial data is typically stored in structured databases, covering multiple dimensions of information such as general ledger, subsidiary ledgers, reports, and tax declarations. It also needs to comply with certain industry standards and is characterized by strong domain specialization, high data correlation, and significant format differences.

[0003] Traditional financial data querying and analysis relies on technical personnel writing Structured Query Language (SQL). However, core business personnel such as financial analysts and financial managers often lack SQL programming skills, requiring technical personnel to process requests. This leads to inefficient data acquisition and inaccurate request transmission, making it difficult to meet the company's need for real-time financial insights. Against this backdrop, Text-to-SQL (T2SQL) technology has emerged. Its core capability is to automatically convert natural language-described query requests into executable SQL statements, breaking down the interaction barriers between non-technical personnel and structured financial data, and providing technological possibilities for lightweight and efficient financial data analysis.

[0004] With the iterative development of Large Language Models (LLMs), Text2SQL technology has significantly improved its semantic understanding and complex sentence processing capabilities, and is gradually penetrating into vertical fields such as finance and healthcare. In financial scenarios, Text2SQL technology can be widely applied to financial statement analysis, cost accounting, budget control, compliance monitoring, and other scenarios. It is expected to significantly shorten the financial data analysis cycle, lower the operational threshold, and reduce human error, becoming a key supporting technology for the digital transformation of enterprise finance.

[0005] However, existing Text2SQL technologies generally suffer from the following technical problems when targeting financial data query scenarios: insufficient domain adaptability leads to weak professional semantic understanding; lack of generation accuracy and stability leads to prominent illusion and inconsistency issues; weak generalization ability leads to high deployment and iteration costs; and insufficient multilingual and colloquial adaptation leads to limited interactive experience. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to provide a natural language question-answering processing method and apparatus for financial data query, which aims to solve at least one of the above-mentioned technical problems.

[0007] In a first aspect, the technical solution of the present invention to solve the above-mentioned technical problem is as follows: a natural language question-answering processing method for financial data query, the method comprising: Obtain the original query statement entered by the user; The original query statement is subjected to intent analysis processing, which transforms it into the target query statement; intent analysis processing includes intent identification, intent rewriting, and intent clarification. Financial entities are extracted from the target query statement, and the financial entities are retrieved and matched in a pre-built financial data element database to obtain the mapping results of the financial entities in the financial data element database; the mapping results include the target table name, the target column name, and the relationship between the target tables; Combine the target query statement and the mapping results to generate the target SQL statement; Execute the target SQL statement in a pre-built financial database to generate query results.

[0008] The beneficial effects of this invention are as follows: The natural language question-answering processing method for financial data queries provided by this invention first obtains the original query statement input by the user, and performs intent analysis processing on the original query statement to transform it into a target query statement. This intent analysis processing includes intent recognition, intent rewriting, and intent clarification, effectively solving the problems of insufficient understanding of colloquial and ambiguous financial queries and easy intent bias in existing technologies, and significantly improving the accuracy of intent understanding. Then, financial entities are extracted from the target query statement, and the financial entities are retrieved and matched in a pre-built financial data metadata database to obtain a mapping result containing target table names, target column names, and relationships between target tables. This effectively solves the problems of weak adaptability and inability to handle the ambiguity of financial terms and complex table relationship logic in existing technologies. Then, the target query statement and mapping result are combined to generate a target SQL statement. Finally, the target SQL statement is executed in the pre-built financial database to generate query results, realizing end-to-end automated processing from natural language queries to financial data results. The overall solution significantly improves the accuracy, stability, and user experience of financial data queries.

[0009] Based on the above technical solution, the present invention can be further improved as follows.

[0010] Furthermore, the original query statement undergoes intent analysis processing to transform it into a target query statement, including: By combining a pre-trained intent classification model and a pre-built financial intent labeling system, the intent of the original query statement is identified, and preliminary financial element information is extracted. By combining intent, financial element information, pre-constructed financial knowledge graphs, and financial sentence templates, the original query statement is optimized and rewritten to obtain the intent-rewritten query statement. Based on intent and financial information, the intent-rewritten query statement is validated a second time to obtain the initial target query statement after the validation is passed. The initial target query statement is assessed for completeness. If it is complete, the initial target query statement is determined to be the target query statement; otherwise, the intent of the initial target query statement is clarified through interactive feedback to obtain the target query statement.

[0011] Furthermore, the financial entities are retrieved and matched in a pre-built financial data metadata database to obtain the mapping results of the financial entities in the financial data metadata database, including: The data of financial entities is retrieved and matched with the metadata of the financial data metadata database to obtain several candidate mapping results; Based on the pre-constructed financial knowledge graph, the candidate mapping results are screened for relevance to obtain several initial mapping results. These initial mapping results are then used as context inputs to a pre-trained financial big data model for entity mapping to determine the final mapping results.

[0012] Furthermore, by combining the target query statement and the mapping results, the target SQL statement is generated, including: Combining the target query statement and the mapping results, a pre-trained SQL generation model generates several candidate SQL statements; each candidate SQL statement is generated using a hierarchical strategy. A progressive verification and scoring process is performed on several candidate SQL statements to determine the target SQL statement.

[0013] Furthermore, a progressive verification and scoring process is performed on several candidate SQL statements to determine the target SQL statement, including: Each candidate SQL statement is sequentially subjected to syntax validation, semantic validation, and business logic validation. Each candidate SQL statement that passes the validation is scored based on the consistency of the query results after execution and its own statement quality. The candidate SQL statement with the highest score is selected as the target SQL statement.

[0014] Furthermore, each candidate SQL statement is generated using a hierarchical strategy, including: Based on the mapping results, a main SQL framework containing core tables, join conditions, and filter conditions is generated. Based on the main SQL framework, and combined with the intent of the target query statement, aggregate functions, sorting conditions, grouping conditions, and calculation logic are populated to generate candidate SQL statements.

[0015] Furthermore, before generating the target SQL statement by combining the target query statement and the mapping results, the following steps are included: The query difficulty level of the target query statement is determined based on the number of tables, aggregate functions, and nesting levels contained in the mapping results, as well as the classification results of the pre-trained classifier. Based on the query difficulty level, a pre-trained SQL generation model that matches it is selected to generate the target SQL statement.

[0016] Furthermore, before extracting financial entities from the target query, the process includes: Determine whether the target query is a financial query. If so, perform financial entity extraction; otherwise, output a pre-defined non-financial query prompt to the user.

[0017] Secondly, to solve the above-mentioned technical problems, the present invention also provides a natural language question-answering processing device for financial data query, the device comprising: The acquisition module is used to acquire the original query statement input by the user; The intent analysis module is used to perform intent analysis on the original query statement and transform it into the target query statement; intent analysis processing includes intent identification, intent rewriting, and intent clarification. The entity extraction module is used to extract financial entities from the target query statement, retrieve and match the financial entities in the pre-built financial data element database, and obtain the mapping results of the financial entities in the financial data element database; the mapping results include the target table name, the target column name, and the relationship between the target tables; The target SQL statement generation module is used to combine the target query statement and the mapping results to generate the target SQL statement; The query module is used to execute target SQL statements in a pre-built financial database and generate query results.

[0018] Thirdly, in order to solve the above-mentioned technical problems, the present invention also provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the natural language question-answering processing method for financial data query of the present application.

[0019] Fourthly, in order to solve the above-mentioned technical problems, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the natural language question-answering processing method for financial data query of the present application.

[0020] Additional aspects and advantages of this application will be set forth in part in the description which follows, and will become apparent from the description or may be learned by practice of this application. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments of the present invention will be briefly introduced below.

[0022] Figure 1 A flowchart illustrating a natural language question-answering method for financial data querying, provided as an embodiment of the present invention; Figure 2 A schematic diagram of the structure of a natural language question-answering processing device for financial data querying provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an electronic device provided in one embodiment of the present invention. Detailed Implementation

[0023] The principles and features of the present invention are described below. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0024] The technical solution of the present invention and how the technical solution of the present invention 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 the present invention will now be described with reference to the accompanying drawings.

[0025] The data acquisition process involved in this invention follows the principles of legality, legitimacy, and necessity. Based on obtaining the explicit authorization and consent of the user, only the minimum necessary information required to achieve the purpose is collected, and data security protection obligations are fulfilled in accordance with the law.

[0026] The solution provided in this invention can be applied to any application scenario requiring target detection. This invention provides a possible implementation method, such as... Figure 1 The diagram shows a flowchart of a natural language question-answering processing method for financial data queries. This method can be executed by any electronic device, such as a terminal device, or by both a terminal device and a server. For ease of description, the method provided in this embodiment will be described below using a terminal device as the execution subject. Figure 1 The flowchart shown indicates that the method may include the following steps: S10, Obtain the original query statement input by the user; S20, perform intent analysis on the original query statement and transform it into the target query statement; intent analysis includes intent identification, intent rewriting and intent clarification; S30: Extract financial entities from the target query statement, retrieve and match the financial entities in the pre-built financial data element database, and obtain the mapping results of the financial entities in the financial data element database; the mapping results include the target table name, the target column name, and the relationship between the target tables; S40, combine the target query statement and the mapping results to generate the target SQL statement; S50 executes the target SQL statement in a pre-built financial database and generates query results.

[0027] The natural language question-answering method for financial data queries provided by this invention first obtains the original query statement input by the user and performs intent analysis processing on the original query statement to transform it into a target query statement. This intent analysis processing includes intent recognition, intent rewriting, and intent clarification, effectively solving the problems of insufficient understanding of colloquial and ambiguous financial queries and easy intent bias in existing technologies, and significantly improving the accuracy of intent understanding. Then, financial entities are extracted from the target query statement and retrieved and matched in a pre-built financial data metadata database to obtain a mapping result containing target table names, target column names, and relationships between target tables. This effectively solves the problems of weak adaptability and inability to handle the ambiguity of financial terms and complex table relationship logic in existing technologies. Then, the target query statement and mapping result are combined to generate a target SQL statement. Finally, the target SQL statement is executed in the pre-built financial database to generate query results, realizing end-to-end automated processing from natural language query to financial data results, significantly improving the accuracy, stability, and user experience of financial data queries.

[0028] The technical solution of the present invention and how the technical solution of the present invention 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 the present invention will now be described with reference to the accompanying drawings.

[0029] The solution provided in this invention can be applied to any application scenario requiring financial data query and analysis. A natural language question-answering method for financial data querying provided in this invention may include the following steps: S10, Obtain the original query statement input by the user.

[0030] Specifically, in this embodiment, the original query statement input by the user is first obtained. The original query statement can be text input by the user in natural language form. For example, the original query statement input by the user can be "Calculate the operating gross profit margin for the third quarter of 2024" or "Compare the profit situation of each business unit last year and this year".

[0031] S20, perform intent analysis on the original query statement and transform it into the target query statement; intent analysis includes intent identification, intent rewriting and intent clarification.

[0032] Intent analysis processing of raw query statements can transform users' colloquial, vague, or incomplete queries into standardized query statements that are machine-understandable, complete, and well-expressed—the target query statement. This lays a solid foundation for subsequent processing and enables full lifecycle management of user query intent, namely a complete closed loop from intent identification, rewriting, clarification to final confirmation. This ensures that the query statements entering subsequent processes are clear, complete, and unambiguous.

[0033] In a preferred embodiment, step S20 further includes the following sub-steps: S201 combines a pre-trained intent classification model and a pre-built financial intent labeling system to identify the intent of the original query statement and extract preliminary financial element information.

[0034] Specifically, a pre-trained intent classification model is invoked. This model is based on a collected and organized historical financial question corpus, fine-tuned using SFT (Supervised Fine-Tuning) combined with LoRA (Low-Rank Adaptation) on the Qwen3-4B base model. The financial question corpus refers to a pre-collected and labeled dataset of natural language questions in the financial domain. Each question is labeled with a corresponding intent category (e.g., report query, indicator calculation, trend analysis, anomaly detection, etc.), used to train the model to learn the mapping relationship between natural language expressions and financial intents. The model's input is the user's original query statement, and the output is the intent label corresponding to that statement.

[0035] The aforementioned financial intent labeling system refers to a pre-constructed set of classification labels used to describe the core intent of financial queries. For example, it may include categories such as "report query" (e.g., querying balance sheet and profit and loss statement data), "indicator calculation" (e.g., calculating gross profit margin and debt-to-equity ratio), "trend analysis" (e.g., analyzing the trend of indicators over time), and "anomaly detection" (e.g., identifying abnormal financial data or fluctuations). This labeling system provides a standardized output target for the intent classification model, enabling the model to map natural language questions to predefined intent categories.

[0036] While recognizing the intent, the model also extracts preliminary financial information, such as time, indicators, and entities. For example, given the input "Calculate the gross profit margin for Q3 2024", the model recognizes the intent as "indicator calculation" and simultaneously extracts the time element "Q3 2024" and the indicator element "gross profit margin".

[0037] Optionally, before calling the pre-trained intent classification model in S201, the method further includes: using a financial stop word library filter and keyword weighting mechanism to purify the original query statement and strengthen the core intent features.

[0038] Among them, the financial stop word library refers to a pre-constructed collection of words that have no financial semantic value. These words only serve as grammatical connectors or tone aids, such as "trouble", "help me", "a little", "probably", "of", "data", "situation", etc.

[0039] Filtering the original query using a financial stop word database can be achieved through a combination of word-by-word matching and batch removal. For example, firstly, after the user enters the original query, a financial-specific word segmentation model is used to segment the input text. This model is trained on a financial corpus and can avoid missegmentation of financial terms (such as "operating revenue" and "debt-to-asset ratio"). Secondly, the segmented words are matched one by one against the financial stop word database. For example, if the user enters "Could you please help me find out which companies are most likely to be in Q3 of 2024?", the search query might be incomplete or incomplete. The phrase "Our company's operating revenue data" is segmented into a word sequence: [trouble, help me, query, a quick look, recently, approximately, Q3 2024, our company, of, operating revenue, data, situation]. Then, stop words that match the financial stop word list are removed in batches, such as invalid information like [trouble, help me, query, a quick look, recently, approximately, of, data, situation]. Finally, the filtered and purified text is output: "Our company's operating revenue in Q3 2024," retaining only the core content related to financial inquiries.

[0040] After filtering out invalid information from the financial deactivated keyword database, the core intent can be further strengthened through the keyword weighting mechanism.

[0041] Optionally, the keyword weighting mechanism includes: The filtered and purified text is classified and matched with keywords to determine the category and corresponding weight of each word; the weight of each word is calculated, and high-weight core keywords with non-zero weights are retained; high-weight keywords are highlighted by weighting, and the keywords and their weights are used as input features and fed into the subsequent intent classification model.

[0042] Specifically, the filtered and purified text is classified and matched using keywords to determine the weight of each retained word. Only high-weight keywords with non-zero weights are retained, and after weighted highlighting, they are output to the subsequent intent classification model. Keyword classification and corresponding weights can be obtained based on training with historical data. For example, keyword classification and corresponding weights include: an indicator dimension with a weight of 10 points, example words including "operating revenue," "gross profit margin," "asset-liability ratio," and "net profit," etc. This dimension represents the core indicators in financial queries, has the highest weight, and is a key basis for intent determination; a time dimension with a weight of 8 points, example words including "Q3 2024," "2023," "last three years," and "last month," etc. This dimension represents the time range of the query, has the second highest weight, and is used to limit the time boundary of the query; the main body... The first dimension, with a weight of 7 points, includes example words such as "our company," "parent company," "East China region," and "Business Unit A." This dimension represents the main object of the query and is used to clarify the data's attribution. The second dimension, with a weight of 6 points, includes example words such as "year-on-year," "month-on-month," "compare," and "compared to." This dimension represents the comparative relationship of the query and is used to identify trend analysis or comparative analysis needs. The third dimension, with a weight of 0 points, includes example words such as "company," "business," and "data" (in non-core contexts). These words have no financial semantic value and are removed during weight calculation.

[0043] For example, the filtered clean text is "Our company's operating revenue in Q3 2024". First, keyword classification matching is used to determine the category and corresponding weight of each word in the clean text. Second, irrelevant residual keywords with a weight of 0 are removed. For example, if the clean text contains the word "company", the keyword will be removed. Finally, high-weight keywords are retained, including "Q3 2024" (8 points), "our company" (7 points), and "operating revenue" (10 points). Finally, high-weight keywords are weighted and highlighted. The keywords and their weights are used as input features and fed into the subsequent intent classification model. The model prioritizes judging the core intent based on the high-weight keyword ("operating revenue"), and then combines medium and low-weight keywords (time, subject) to refine the intent type. This allows the model to quickly identify its core intent as "financial indicator query", and further subdivide it into "our company's operating revenue query in Q3 2024", effectively avoiding intent classification bias caused by the lack of prominence of core features.

[0044] S202 combines intent, financial element information, pre-built financial knowledge graph, and financial sentence templates to optimize and rewrite the original query statement, resulting in an intent-rewritten query statement.

[0045] After identifying the intent and preliminary financial element information, the original statement can be optimized and rewritten using a pre-built financial knowledge graph and financial sentence templates. The optimization and rewriting process addresses ambiguous, incomplete, and colloquial expressions input by the user. Specifically, ambiguous expressions are resolved, such as clarifying "profit growth rate" as "operating profit year-on-year growth rate" or "net profit year-on-year growth rate" using the knowledge graph; incomplete expressions are supplemented by adding missing information, such as completing "calculate gross profit margin" as "calculate the gross profit margin of the main business in Q3 2021" based on the context; and colloquial expressions are standardized by rewriting them into standard sentences that conform to financial logic. Intent rewriting does not directly process the original query statement input by the user, but uses the intent of the original query statement as the sole input basis. The advantage of this approach is that the rewriting process is based on the identified intent and financial element information, avoiding interference from colloquial, redundant, or noisy information in the original query statement.

[0046] In this embodiment of the invention, the financial sentence template predefines a standardized financial question structure. A financial knowledge graph is a structured knowledge representation model for the financial domain, composed of nodes and edges, used to store financial entities and their semantic relationships. It includes financial terminology, synonyms, hierarchical relationships, and accounting logic relationships, providing knowledge support for intent rewriting, entity normalization, and ambiguity resolution.

[0047] Specifically, in the constructed financial knowledge graph, nodes can represent all entities in the financial field that have clear semantics and can exist independently, including concepts, terms, rules, and subjects, not just entity keywords in the financial field. Based on financial semantic types, nodes can be divided into: financial indicator nodes, which are core indicators used for accounting and analysis in the financial field, including standard terms and multiple expression variations. Their core attributes include standard name, calculation logic, relevant report, related accounts, unit, and compatibility with accounting standards; and financial subject nodes, which are the specific subjects (internal or external related subjects of the enterprise) for financial queries and accounting. Their core attributes include standard name, hierarchical relationship, region, etc. Accounting scope and default subject identifier; financial time nodes, the time range or node for financial accounting and query (including standard format and fuzzy description), whose core attributes include standard format, time type (calendar year or accounting year), corresponding accounting period and time granularity; financial rule nodes, accounting standards, corporate financial system, accounting rules, verification rules, etc., whose core attributes include rule number, applicable scenario, rule content, priority and related indicators or subjects; financial carrier nodes, the storage and presentation carrier of financial data (such as reports, subjects, database tables, etc.), whose core attributes include carrier name, included indicators or subjects, related carriers, data source and permission level.

[0048] In a financial knowledge graph, edges act as bridges connecting two nodes, representing the financial-specific semantic relationships between corresponding entity nodes. These relationships can include: synonym / equivalence relationships, indicating that the two nodes are semantically identical, differing only in their expression (including abbreviations, colloquialisms, and synonyms), such as gross profit and operating profit margin, revenue and operating income, this year and 2024 (calendar year); and computational logic relationships, representing the computational dependencies between core nodes (indicators) and related nodes (indicators or accounts), such as the computational dependencies between operating profit margin and operating income, operating profit margin and operating costs, and net profit and operating profit. Relationships can be categorized into several types: Hierarchical / Subordinate relationships, indicating that a lower-level node is subordinate to a higher-level node, exhibiting a hierarchical or inclusive relationship. Examples include the hierarchical relationship between Business Unit A and its parent company, revenue and profit statement, and cost of goods sold and profit statement. Correspondence / Mapping relationships indicate a clear correspondence between two nodes (not hierarchical, not computationally oriented, but semantically related). Examples include the correspondence between Q3 2024 and July to September 2024 (accounting period), and the relationship between the profit statement and the balance sheet. Applicability / Constraint relationships indicate the constraint or applicability of a rule node to other nodes (indicators, subjects, time). Examples include the constraint or applicability between the gross profit margin calculation rule and operating gross profit margin, and the relationship between IFRS accounting standards and net profit. Fuzzy association relationships indicate that a node's description is ambiguous and can be associated with multiple explicit nodes, used for ambiguity and fuzzy judgment. For example, a vague relationship between a company and its parent company, or between a company and its subsidiaries, means that "company" may refer to either "parent company" or "subsidiary"; a vague relationship between the recent period and Q2 2024, or between the recent period and Q3 2024, means that "recent period" may refer to either "Q2 2024" or "Q3 2024".

[0049] For example, one specific implementation of S202 above is as follows: First, based on the intent of the original query, a corresponding standardized sentence template is selected from a pre-set financial sentence template library. For example, if the intent of the original query is "indicator calculation", the template "Calculate [the [subject]'s] [standard indicator] at [time], with the calculation logic being [indicator calculation logic]" is selected. The financial sentence template library stores standardized sentence structures corresponding to different intent types. After selecting a template, the types of placeholders to be filled in the template are determined, including indicator placeholders, time placeholders, subject placeholders, calculation logic placeholders, etc.

[0050] Secondly, the association relationship of "operation intent nodes" in the pre-built financial knowledge graph is invoked to map the colloquial expressions of the original query intent (such as "check" or "calculate") to the standardized operation expressions in the template (such as "query" or "calculate"), ensuring that the operation intent expressions are consistent. The financial knowledge graph stores the mapping relationship between colloquial operations and standardized operations, such as "check" corresponding to query, "calculate" corresponding to calculation, "compare" corresponding to comparative analysis, and "pull" corresponding to retrieval.

[0051] Example: The original example, "Calculate my gross profit for the third quarter of this year," is identified as "indicator calculation" by the intent recognition module. The corresponding calculation template is selected, and the operation description is standardized to "calculate" based on the relationship between "calculate" and "calculate" in the financial knowledge graph. Finally, by combining the extracted financial element information, the placeholders in the template are filled in to generate a standardized intent. For example, if the user's original input is "Calculate my gross profit for the third quarter of this year," the intent is determined to be "indicator calculation," and the corresponding calculation template is selected. Through the association relationship of "calculate the corresponding calculation" in the financial knowledge graph, the operation expression is standardized to "calculate." Combining the extracted financial elements (time element "third quarter of this year" and indicator element "gross profit"), a standardized intent is generated: "Calculate the operating gross profit of [entity] in the third quarter of 2024, the calculation logic is (operating revenue - operating cost) / operating revenue." If the entity element is missing, it is completed according to the enterprise's default rules or context; if "gross profit" has ambiguity, it is resolved to "operating gross profit" using the knowledge graph.

[0052] S203, based on intent and financial element information, perform a second validation on the intent-rewritten query statement to obtain the initial target query statement after the validation passes.

[0053] The rewritten query statement undergoes a second validation to ensure that it remains logically faithful to the user's original intent (the intent of the original query statement) and that the extracted financial information is accurate. For example, it validates whether the rewritten "Calculate the gross profit margin for Q3 2024" is completely consistent with the original intent "Calculate the gross profit margin for Q3 2024". Once the validation passes, the initial target query statement is obtained.

[0054] Optionally, the specific method of secondary verification is as follows: the semantic matching degree of the intent to rewrite the query statement and the intent of the original query statement is calculated. If the matching degree is lower than the preset threshold, it is determined that the rewriting is deviated and a correction mechanism is triggered, such as regenerating the rewriting result or confirming with the user. If the matching degree passes the verification, the intent to rewrite the query statement is used as the initial target query statement and the process proceeds to S204.

[0055] Through the above processing flow, a closed loop of "identification-rewriting-verification" is formed, ensuring that the final output target query statement is both standardized and complete, and faithful to the user's original query statement intent.

[0056] S204, perform an information integrity check on the initial target query statement. If it is complete, determine that the initial target query statement is the target query statement; if it is incomplete, clarify the intent of the initial target query statement through interactive feedback to obtain the target query statement.

[0057] Perform an information integrity check on the initial target query statement to see if it contains the key information required to execute the query, such as time dimension, subject dimension, indicator dimension, comparison dimension, etc., and determine whether there is any missing or ambiguous information.

[0058] After obtaining the initial target query statement, it is necessary to first determine whether information is missing or ambiguous to ascertain whether intent clarification is required. Information missing refers to the absence of essential elements corresponding to the intent type in the initial target query statement, which cannot be filled in using a financial knowledge graph or enterprise default rules. Missing non-essential elements will not trigger the clarification process; examples include "comparison dimension" in trend analysis intents and "detailed scope" in indicator calculation intents. Information ambiguity refers to situations where the elements of the financial query have content, but the expression lacks a unique focus, has multiple possible interpretations, and cannot be resolved through a financial knowledge graph or context (the rewritten intent lacks additional context).

[0059] Optionally, before step S204, a determination of missing information is made for the initial target query statement, including: Determine the intent of the current query based on the intent of the original query statement; By comparing the pre-built list of required elements, check whether all the required elements corresponding to the intent type have been filled in the initial target query statement; If any required element is missing, it is determined whether the element can be completed using a financial knowledge graph or the company's default rules. If so, it is automatically completed and not considered as missing information; otherwise, it is considered as missing information.

[0060] Optionally, before step S204, the initial target query statement is subjected to information fuzziness determination, including: The initial target query statement is considered to have information ambiguity when any of the following conditions are met: The scope of the element description is too broad and lacks clear boundaries, making it impossible to pinpoint the specific query range; or The element descriptions are ambiguous, and there are no default resolution rules in the financial knowledge graph, making it impossible to determine a unique meaning; or The elements are vaguely described and cannot match the standard nodes of the financial knowledge graph.

[0061] For example, the time element "recently" and "last year" lack specific time references, and the subject element "each department" lacks specific subject references; for example, "this year" can refer to a calendar year or an accounting year, which is ambiguous if the company does not have a default rule; "profit" can refer to operating profit or net profit, which cannot be determined with a unique meaning without contextual constraints; for example, "recent operating data" has no specific indicator references, and "core indicators of each segment" has no specific segment references, making it impossible to establish a mapping with the standard financial nodes in the knowledge graph.

[0062] If the initial target query is complete, it is determined as the target query. If the information is incomplete, such as the user only entering "compare gross profit margins," a clarifying question is automatically generated to interact with the user, such as: "Please confirm the entities to be compared (e.g., Business Unit A vs. Business Unit B) and the time range (e.g., 2023 vs. 2024)." Based on the user's feedback, the query is completed, ultimately forming a complete and clear target query.

[0063] In this embodiment of the invention, after the user provides supplementary information based on a clarifying question, the target query statement is updated according to the supplementary information to eliminate missing or ambiguous information and ensure that the query statement entering the subsequent process is clear, unambiguous, and unequivocal.

[0064] S30: Extract financial entities from the target query statement, retrieve and match the financial entities in the pre-built financial data element database, and obtain the mapping results of the financial entities in the financial data element database; the mapping results include the target table name, the target column name, and the relationship between the target tables.

[0065] Financial entities are extracted from the target query statement. Financial entities refer to key information units related to the financial domain from the target query statement, including indicator entities (such as "gross profit margin"), time entities (such as "Q3 2024"), entity entities (such as "parent company"), and database entities (such as "profit and loss statement"). In one specific embodiment, a pre-trained financial knowledge-enhanced named entity recognition (NER) model is used to extract financial entities from the target query statement.

[0066] Optionally, after extracting the financial entities, entity normalization processing can be performed on them in conjunction with the financial knowledge graph.

[0067] Entity normalization refers to mapping entities with inconsistent or multiple forms of representation in the financial field that correspond to the same core meaning into unique, standardized financial entities. Categories of entity normalization can include the normalization of multiple representations of financial indicators, financial entities, financial query times, financial data carriers, and financial operations.

[0068] In this embodiment of the invention, the extracted financial entities are normalized by combining financial knowledge graphs, which further eliminates confusion and ambiguity in financial statements and ensures the accuracy of subsequent retrieval and matching.

[0069] Optionally, before extracting financial entities from the target query, the following steps are included: Determine whether the target query is a financial query. If so, perform financial entity extraction; otherwise, output a pre-defined non-financial query prompt to the user.

[0070] By combining a keyword database and intent tagging system in the financial field, it is determined whether the target query falls within the scope of financial queries. If it is determined to be a non-financial question, such as a user asking "How's the weather today?", a fallback strategy can be triggered, outputting the fixed message: "This question is not within the scope of our service." Only when it is determined to be a financial question will it proceed to the subsequent financial entity extraction and processing process.

[0071] In this embodiment of the invention, after extracting the financial entity, a determination is made as to whether it is a financial issue, thus avoiding invalid processing of non-target domain issues and clearly informing the user of the service boundaries, thereby improving processing efficiency.

[0072] After extracting the financial entities, the financial entities are retrieved and matched in the pre-built financial data metadata database to obtain the mapping results of the financial entities in the financial data metadata database.

[0073] Optionally, the financial entity is retrieved and matched in a pre-built financial data metadata database to obtain the mapping results of the financial entity in the financial data metadata database, including: The data of financial entities is retrieved and matched with the metadata of the financial data metadata database to obtain several candidate mapping results; Based on the pre-constructed financial knowledge graph, the candidate mapping results are screened for relevance to obtain several initial mapping results; Several initial mapping results are used as context inputs to a pre-trained financial large model for entity mapping, and the final mapping result is determined.

[0074] Specifically, a financial data metadata database refers to a pre-built knowledge base that stores all metadata of a financial database, including table structure, inter-table relationships, mapping relationships between columns and financial indicators, and enterprise-defined financial rules. This metadata is stored in a vector database after vectorization, and schema semantic vectors are generated based on financial domain word segmentation and embedding models. Extracted financial entities are embedded and vectorized. By calculating the similarity between the vectors of financial entities and the vectors of metadata, the top-N candidate mapping results are retrieved. For example, for "gross profit margin," the retrieval might return the "revenue" column, the "cost of goods sold" column, and the related profit and loss statement.

[0075] For candidate mapping results, a pre-built financial knowledge graph is used for relevance filtering. The financial knowledge graph contains business logic and rules in the financial field; for example, the formula for calculating "gross profit margin" is (operating revenue - operating cost) / operating revenue. Using the financial knowledge graph, candidate fields unrelated to "gross profit margin," such as the "accounts receivable" field in the balance sheet, can be eliminated, thereby narrowing the matching range and obtaining more accurate initial mapping results.

[0076] This invention utilizes the financial business logic stored in the knowledge graph to accurately filter candidate mapping results, effectively solving the mismatch problem of "semantically similar but business-irrelevant" in traditional vector retrieval.

[0077] The initial mapping results obtained after filtering are used as context information and input into the pre-trained financial big data model for entity mapping to determine the final mapping result. Specifically, the financial big data model relies on pre-trained weights in the financial domain (adapted to accounting standards and corporate financial systems) and combines the node edge relationships of the financial knowledge graph to perform three-layer semantic matching, achieving a precise association between intent and schema. The three-layer semantic matching includes: Element-level matching: Matches the intent elements one by one with the fields or tables of the Schema candidate results to confirm that the field meanings, data types, and accounting methods are consistent. For example, whether the accounting method of "gross profit margin" in the intent matches the "gross profit margin" column in the profit statement. This is verified based on the calculation logic relationships in the financial knowledge graph. Relationship-level matching: Verifies whether the relationships between entities in the intent are consistent with the relationships between tables and fields in the Schema candidate results. For example, the "gross profit margin of Business Unit A" in the intent matches the relationship between the business unit dimension table and the profit statement. This is verified based on the attribution / subordination relationships in the financial knowledge graph. Intent-level matching: Ensures that the combination of Schema candidate results can fully support the realization of the user's intent. For example, a comparative analysis intent needs to ensure that the candidate table set can provide all the data required for comparison. This is verified based on the applicability / constraint relationships in the financial knowledge graph.

[0078] After three layers of semantic matching, the large model outputs the final mapping result, which includes the target table name, target column name, and core information about the relationships between target tables.

[0079] Optionally, when performing semantic deep matching on the financial big model, the final mapping result is selected from the candidate mapping result set based on the table usage description retrieved by RAG (Retrieval Enhancement Generation) and the user's historical query habits.

[0080] Specifically, the candidate mapping result set returned during the RAG retrieval phase can also include usage descriptions for each table to differentiate the applicable scenarios for different tables. For example, the profit and loss statement is suitable for querying the financial statements of a single company, while the consolidated profit and loss statement is suitable for querying the consolidated financial statements of a group company. The financial-specific large-scale model, combined with this usage description, determines the scenario to which the current user intends and filters the matching tables. Simultaneously, the financial-specific large-scale model can also record the user's historical query habits. For example, if the user has frequently used the consolidated profit and loss statement in past queries, the consolidated profit and loss statement will be prioritized as the target table; if the user has frequently used the profit and loss statement in past queries, the profit and loss statement will be prioritized. Combined with RAG, the financial large-scale model can effectively solve the multiple mapping problem.

[0081] This invention integrates financial knowledge graphs, financial data metadata databases, and RAG to achieve accurate mapping between financial entities and target table names, target column names, and relationships between target tables in the financial data metadata database.

[0082] S40 combines the target query statement and the mapping results to generate the target SQL statement.

[0083] After obtaining accurate mapping results, the structured query intent and mapping information are transformed into executable SQL code.

[0084] Before generating the target SQL statement, this method may also include a model routing step to optimize the use of computing resources. Specifically, before step S40, the method further includes: The query difficulty level of the target query statement is determined based on the number of tables, aggregate functions, and nesting levels contained in the mapping results, as well as the classification results of the pre-trained classifier. Based on the query difficulty level, a pre-trained SQL generation model that matches it is selected to generate the target SQL statement.

[0085] The query complexity of the target query statement is classified, and the classification result is output as simple problem or complex problem. For example, if it is determined to be a simple problem (such as single table query, no nesting, basic aggregation operation), it is routed to a lightweight small model for SQL generation; if it is determined to be a complex problem (such as multi-table join, nested subqueries, multi-dimensional aggregation and comparison), it is routed to a high-performance large model for SQL generation.

[0086] Complexity classification is determined jointly by rules and models. Specifically, it involves weighted voting based on rules (number of tables involved in the query, number of aggregate functions, and number of nesting levels) and the output of a pre-trained financial problem complexity classifier to ultimately determine the routing strategy.

[0087] Specifically, this embodiment uses a joint rule-based and model-based approach to determine the query difficulty level of the target query statement. Rule-based determination is based on the number of tables, aggregate functions, and nesting levels in the mapping result, and is performed according to preset thresholds. If the number of tables is less than or equal to a preset threshold, the number of aggregate functions is less than or equal to a preset threshold, and the nesting levels are less than or equal to a preset threshold, the rule-based determination is a simple problem; otherwise, it is a complex problem. Model-based determination involves inputting the target query statement into a pre-trained financial problem complexity classifier, which outputs a classification result of either a simple or complex problem. The rule-based determination result and the model classification result are weighted and voted on to obtain the final query difficulty level. For example, if both are determined to be a simple problem, then it is ultimately determined to be a simple problem; if the two determination results are inconsistent, a weighted score is calculated based on preset weights (e.g., rule-based determination weight 0.4, model-based determination weight 0.6) to determine the final difficulty level. Based on the determined query difficulty level, a matching pre-trained SQL generator is selected for subsequent SQL generation.

[0088] This invention classifies the complexity of financial problems and selects a matching SQL generation model based on the query difficulty level of the target query statement. This enables on-demand allocation of model resources and avoids resource waste caused by over-reliance on large models or performance inadequacy caused by simply using small models.

[0089] After determining the SQL generation model, the target SQL statement is generated.

[0090] Optionally, in step S40, the target SQL statement is generated by combining the target query statement and the mapping result, including: By combining the target query statement and the mapping results, a number of candidate SQL statements are generated by a pre-trained SQL generation model. Each candidate SQL statement is generated using a hierarchical strategy.

[0091] The candidate SQL statements are sequentially validated and scored to determine the target SQL statement.

[0092] Specifically, by adjusting the decoding parameters of the SQL generation model (such as the temperature coefficient) and introducing different Prompt templates, 3-5 candidate SQL statements are generated. Furthermore, the generation of each candidate SQL statement employs a layered strategy, which refers to a trunk-detail layered generation strategy. This means first constructing the main framework of the SQL to ensure the core logic is correct, and then filling in the detailed content.

[0093] Optionally, each candidate SQL statement is generated using a hierarchical strategy, including: Based on the mapping results, a main SQL framework containing core tables, join conditions, and filter conditions is generated. Based on the main SQL framework, and combined with the intent of the target query statement, aggregate functions, sorting conditions, grouping conditions, and calculation logic are populated to generate complete candidate SQL statements.

[0094] For example, based on the mapping results, a main structure such as "SELECT column FROM table JOIN table ON association condition WHERE filter condition" is first constructed; on the basis of the main structure, the "calculation logic" is supplemented, such as "GROUP BY business unit HAVING gross profit margin > 10%".

[0095] The embodiments of the present invention adopt a layered strategy to generate SQL statements. By ensuring the correctness of the core logic first and then supplementing the details, not only can the failure of the overall SQL be avoided due to errors in details, but the robustness and accuracy of the results can also be improved.

[0096] Optionally, a progressive verification and scoring process is performed on several candidate SQL statements to determine the target SQL statement, including: Each candidate SQL statement is sequentially subjected to syntax validation, semantic validation, and business logic validation. Each candidate SQL statement that passes the validation is scored based on the consistency of the query results after execution and its own statement quality. The candidate SQL statement with the highest score is determined as the target SQL statement.

[0097] Specifically, a progressive validation process is used for candidate SQL statements, meaning that only candidate SQL statements that pass the previous level of validation can proceed to the next level. During validation, syntax validation, semantic validation, and business logic validation are performed sequentially. Syntax validation involves inputting each candidate SQL statement into the SQL parser for syntax correctness checks, eliminating candidate SQL statements with syntax errors, and obtaining a first set of candidate SQL statements that pass syntax validation. Semantic validation compares each candidate SQL statement in the first set with the intent expressed by the target query statement. For example, if the original query statement is "calculate year-on-year growth rate," then it checks whether the candidate SQL statements contain the year-on-year calculation logic of (current period value - previous period value) / previous period value, eliminating candidate SQL statements that are inconsistent with the user's intent, and obtaining a second set of candidate SQL statements that pass semantic validation. Business logic validation... Each candidate SQL statement in the second candidate SQL statement set is validated based on a financial domain rule base and knowledge graph to determine whether it complies with accounting standards and corporate financial regulations. For example, it verifies whether the calculation of "debt-to-asset ratio" is "total liabilities / total assets" and not other incorrect formulas, and whether the query results fall within the reasonable range of financial data (such as gross profit margin, which is typically between 0-100%). Candidate SQL statements that do not conform to financial business logic are eliminated, resulting in a third candidate SQL statement set that passes the business logic validation. Each candidate SQL statement in the third candidate SQL statement set is the SQL statement that has passed syntax validation, semantic validation, and business logic validation.

[0098] Candidate SQL statements, validated through three layers of verification, are executed separately in a secure financial data sandbox environment (a real-time mirror of the production environment, allowing only query operations). The query results for each candidate SQL statement are then obtained. A self-consistency voting process is used based on the consistency of the query results, where candidate SQL statements with identical results receive higher voting weights. Simultaneously, a pre-trained financial SQL quality assessment model is employed to score each candidate SQL statement across three dimensions: logical completeness, conciseness, and compliance. Combining the self-consistency voting weights and the model scores, a weighted average score is calculated for each candidate SQL statement. The candidate SQL statement with the highest average score is then selected as the final target SQL statement.

[0099] This invention, through a multi-layered screening of all candidate SQL statements, determines the final target SQL statement, effectively resolving the illusion of large language models and thus improving the accuracy and robustness of the SQL results.

[0100] The embodiments of the present invention combine a hierarchical strategy to generate SQL statements, perform multi-dimensional verification and self-consistency voting on candidate SQL statements to determine the final target SQL statement, and ensure the accuracy of SQL statement generation from three levels: syntax, semantics and business logic. This solves the problems of SQL generation in the prior art that are prone to illusion, syntax errors and financial logic errors.

[0101] S50 executes the target SQL statement in a pre-built financial database and generates query results.

[0102] The final target SQL statement is executed in the enterprise's financial database to retrieve the query results. This enterprise financial database is a structured database system in the enterprise's production environment, used to store real financial data such as general ledgers, subsidiary ledgers, financial statements, and tax returns. Simultaneously, based on user intent, the results can be visualized or natural language explanations can be generated, such as outputting "The gross profit margin in Q3 2024 was 25.3%, an increase of 3.2 percentage points compared to the same period in 2023," thus ultimately completing the end-to-end automated processing from natural language queries to financial data results.

[0103] This invention addresses the shortcomings of existing technologies in understanding colloquial and ambiguous financial queries and preventing intent bias by acquiring the user's original query statement and performing intent analysis to transform it into a target query statement. This significantly improves the accuracy of intent understanding. Financial entities are then extracted from the target query statement and retrieved and matched in a pre-built financial data metadata database to obtain a mapping result containing target table names, target column names, and relationships between target tables. This effectively solves the problems of weak adaptability and inability to handle the ambiguity of financial terminology and complex table relationship logic in existing technologies. Finally, the target query statement and mapping result are combined to generate a target SQL statement, which is then executed in the pre-built financial database to generate query results. This achieves end-to-end automated processing from natural language queries to financial data results, significantly improving the accuracy, stability, and user experience of financial data queries.

[0104] Based on and Figure 1 Based on the same principle as the method shown, this embodiment of the invention also provides a natural language question-answering processing device 20 for financial data queries, such as... Figure 2 As shown, the natural language question-answering processing device 20 for financial data queries may include an acquisition module 210, an intent analysis module 220, an entity extraction module 230, a target SQL statement generation module 240, and a query module 250, wherein: The acquisition module 210 is used to acquire the original query statement input by the user; The intent analysis module 220 is used to perform intent analysis processing on the original query statement and transform it into a target query statement; the intent analysis processing includes intent identification, intent rewriting and intent clarification; The entity extraction module 230 is used to extract financial entities from the target query statement, retrieve and match the financial entities in the pre-built financial data element database, and obtain the mapping results of the financial entities in the financial data element database; the mapping results include the target table name, the target column name, and the relationship between the target tables; The target SQL statement generation module 240 is used to generate the target SQL statement by combining the target query statement and the mapping result; The query module 250 is used to execute the target SQL statement in the pre-built financial database and generate query results.

[0105] Optionally, when the intent analysis module 220 performs intent analysis processing on the original query statement and transforms it into a target query statement, it specifically performs the following: By combining a pre-trained intent classification model and a pre-built financial intent labeling system, the intent of the original query statement is identified, and preliminary financial element information is extracted. By combining intent, financial element information, pre-constructed financial knowledge graphs, and financial sentence templates, the original query statement is optimized and rewritten to obtain the intent-rewritten query statement. Based on intent and financial information, the intent-rewritten query statement is validated a second time to obtain the initial target query statement after the validation is passed. The initial target query statement is assessed for completeness. If it is complete, the initial target query statement is determined to be the target query statement; otherwise, the intent of the initial target query statement is clarified through interactive feedback to obtain the target query statement.

[0106] Optionally, when the entity extraction module 230 retrieves and matches financial entities in a pre-built financial data metadata database to obtain the mapping results of the financial entities in the financial data metadata database, it is specifically used for: The data of financial entities is retrieved and matched with the metadata of the financial data metadata database to obtain several candidate mapping results; Based on the pre-constructed financial knowledge graph, the candidate mapping results are screened for relevance to obtain several initial mapping results. These initial mapping results are then used as context inputs to a pre-trained financial big data model for entity mapping to determine the final mapping results.

[0107] Optionally, when generating the target SQL statement by combining the target query statement and the mapping result, the target SQL statement generation module 240 is specifically used for: Combining the target query statement and the mapping results, a pre-trained SQL generation model generates several candidate SQL statements; each candidate SQL statement is generated using a hierarchical strategy. A progressive verification and scoring process is performed on several candidate SQL statements to determine the target SQL statement.

[0108] Optionally, when the target SQL statement generation module 240 performs progressive verification and scoring on several candidate SQL statements to determine the target SQL statement, it is specifically used for: Each candidate SQL statement is sequentially subjected to syntax validation, semantic validation, and business logic validation. Each candidate SQL statement that passes the validation is scored based on the consistency of the query results after execution and its own statement quality. The candidate SQL statement with the highest score is selected as the target SQL statement.

[0109] Optionally, each candidate SQL statement is generated using a hierarchical strategy, including the following steps: Based on the mapping results, a main SQL framework containing core tables, join conditions, and filter conditions is generated. Based on the main SQL framework, and combined with the intent of the target query statement, aggregate functions, sorting conditions, grouping conditions, and calculation logic are populated to generate candidate SQL statements.

[0110] Optionally, before generating the target SQL statement by combining the target query statement and the mapping results, the apparatus further includes: The model selection module is used to determine the query difficulty level of the target query statement based on the number of tables, aggregate functions, and nesting levels contained in the mapping result, as well as the classification results of the pre-trained classifier; and selects a matching pre-trained SQL generation model based on the query difficulty level to generate the target SQL statement.

[0111] Optionally, before extracting financial entities from the target query, the apparatus further includes: The judgment module is used to determine whether the target query statement belongs to the financial query question. If it does, financial entity extraction is performed; otherwise, a preset non-financial question prompt message is output to the user.

[0112] The natural language question-and-answer processing device for financial data query in this embodiment of the invention can execute the natural language question-and-answer processing method for financial data query provided in this embodiment of the invention. The implementation principle is similar. The actions performed by each module and unit in the natural language question-and-answer processing device for financial data query in each embodiment of the invention correspond to the steps in the natural language question-and-answer processing method for financial data query in each embodiment of the invention. For detailed functional descriptions of each module of the natural language question-and-answer processing device for financial data query, please refer to the descriptions in the corresponding natural language question-and-answer processing methods for financial data query shown above, which will not be repeated here.

[0113] The aforementioned natural language question-and-answer processing device for financial data queries can be a computer program (including program code) running on a computer device. For example, the natural language question-and-answer processing device for financial data queries is an application software. The device can be used to execute the corresponding steps in the method provided in the embodiments of the present invention.

[0114] In some embodiments, the natural language question-answering processing device for financial data query provided in this invention can be implemented using a combination of hardware and software. As an example, the natural language question-answering processing device for financial data query provided in this invention can be a processor in the form of a hardware decoding processor, which is programmed to execute the natural language question-answering processing method for financial data query provided in this invention. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0115] In other embodiments, the natural language question-answering processing device for financial data querying provided in this invention can be implemented in software. Figure 2 A natural language question-answering processing device for financial data querying, stored in a memory, is shown. It can be software in the form of programs and plug-ins, and includes a series of modules, including an acquisition module 210, an intent analysis module 220, an entity extraction module 230, a target SQL statement generation module 240, and a query module 250, for implementing the natural language question-answering processing method for financial data querying provided in the embodiments of the present invention.

[0116] The modules described in the embodiments of the present invention can be implemented in software or hardware. The names of the modules are not, in some cases, limiting the scope of the module itself.

[0117] Based on the same principles as the methods shown in the embodiments of the present invention, the embodiments of the present invention also provide an electronic device, which may include, but is not limited to: a processor and a memory; the memory for storing computer programs; and the processor for executing the methods shown in any embodiment of the present invention by invoking the computer programs.

[0118] In one alternative embodiment, an electronic device is provided, such as Figure 3 As shown, Figure 3 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present invention.

[0119] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0120] Bus 4002 may include a pathway for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 3 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0121] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0122] The memory 4003 stores application code (computer program) for executing the present invention, and its execution is controlled by the processor 4001. The processor 4001 executes the application code stored in the memory 4003 to implement the content shown in the foregoing method embodiments.

[0123] Among these, electronic devices can also be terminal devices. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0124] This invention provides a computer-readable storage medium storing a computer program that, when run on a computer, enables the computer to execute the corresponding content in the aforementioned method embodiments.

[0125] According to another aspect of the present invention, a computer program product or computer program is also provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various embodiments described above.

[0126] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0127] It should be understood that the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0128] The computer-readable storage medium provided in this invention can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0129] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the method shown in the above embodiments.

[0130] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

Claims

1. A natural language question-answering processing method for financial data queries, characterized in that, include: Obtain the original query statement entered by the user; The original query statement is processed by intent analysis and transformed into a target query statement; The intent analysis and processing includes intent identification, intent rewriting, and intent clarification; Financial entities are extracted from the target query statement, and the financial entities are retrieved and matched in a pre-built financial data element database to obtain the mapping result of the financial entities in the financial data element database; the mapping result includes the target table name, the target column name, and the relationship between the target tables; By combining the target query statement and the mapping result, a target SQL statement is generated; The target SQL statement is executed in the pre-built financial database to generate query results.

2. The method according to claim 1, characterized in that, The process of performing intent analysis on the original query statement and transforming it into a target query statement includes: By combining a pre-trained intent classification model and a pre-built financial intent labeling system, the intent of the original query statement is identified, and preliminary financial element information is extracted. By combining the stated intent, the financial element information, the pre-constructed financial knowledge graph, and the financial sentence template, the original query statement is optimized and rewritten to obtain the intent-rewritten query statement. Based on the intent and the financial element information, the rewritten query statement of the intent is subjected to a second verification to obtain the initial target query statement after the verification is passed. The initial target query statement is assessed for completeness. If it is complete, the initial target query statement is determined to be the target query statement. If it is incomplete, the intent of the initial target query statement is clarified through interactive feedback to obtain the target query statement.

3. The method according to claim 1, characterized in that, The step of retrieving and matching the financial entity in a pre-built financial data metadata database to obtain the mapping result of the financial entity in the financial data metadata database includes: The financial entity is retrieved and matched with the metadata of the financial data metadata database to obtain several candidate mapping results; The candidate mapping results are screened for relevance based on a pre-constructed financial knowledge graph to obtain several initial mapping results; these initial mapping results are then used as context inputs to a pre-trained financial big data model for entity mapping to determine the final mapping result.

4. The method according to claim 1, characterized in that, The step of combining the target query statement and the mapping result to generate the target SQL statement includes: Combining the target query statement and the mapping result, a number of candidate SQL statements are generated by a pre-trained SQL generation model; each candidate SQL statement is generated using a hierarchical strategy. The candidate SQL statements are sequentially validated and scored to determine the target SQL statement.

5. The method according to claim 4, characterized in that, The step of progressively verifying and scoring a plurality of candidate SQL statements to determine the target SQL statement includes: Each candidate SQL statement is sequentially subjected to syntax validation, semantic validation, and business logic validation. Each candidate SQL statement that passes the validation is scored based on the consistency of the query results after execution and its own statement quality. The candidate SQL statement with the highest score is determined as the target SQL statement.

6. The method according to claim 4, characterized in that, Each candidate SQL statement is generated using a hierarchical strategy, including: Based on the mapping results, a main SQL framework containing core tables, relational conditions, and filtering conditions is generated. Based on the main SQL framework, and combined with the intent of the target query statement, aggregate functions, sorting conditions, grouping conditions, and calculation logic are populated to generate the candidate SQL statement.

7. The method according to claim 1, characterized in that, Before generating the target SQL statement by combining the target query statement and the mapping result, the process includes: The query difficulty level of the target query statement is determined based on the number of tables, aggregate functions, and nesting levels contained in the mapping result, as well as the classification result of the pre-trained classifier. Based on the query difficulty level, a pre-trained SQL generation model that matches it is selected to generate the target SQL statement.

8. The method according to any one of claims 1 to 7, characterized in that, Before extracting financial entities from the target query, the process includes: Determine whether the target query statement belongs to the financial category. If so, perform financial entity extraction; otherwise, output a preset non-financial question prompt to the user.

9. A natural language question-answering processing device for financial data querying, characterized in that, include: The acquisition module is used to acquire the original query statement input by the user; The intent analysis module is used to perform intent analysis processing on the original query statement and transform it into a target query statement; the intent analysis processing includes intent identification, intent rewriting, and intent clarification; The entity extraction module is used to extract financial entities from the target query statement, retrieve and match the financial entities in a pre-built financial data element database, and obtain the mapping result of the financial entities in the financial data element database; the mapping result includes the target table name, the target column name, and the relationship between the target tables; The target SQL statement generation module is used to combine the target query statement and the mapping result to generate the target SQL statement; The query module is used to execute the target SQL statement in a pre-built financial database and generate query results.

10. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method of any one of claims 1-8.

Images