Financial analysis method and system based on hierarchical scene and associated data table extension

Abstract

The present application belongs to the technical field of computer data processing, and discloses a financial analysis method and system based on hierarchical scene and associated data table expansion. The analysis method obtains a candidate standard question condition from a large language model, checks to obtain a target standard question condition, determines a target scene set and a scene expansion range, screens data tables associated with the target scene set and the scene expansion range from a data table association index table to form a candidate data table set, checks to form a target data table set, generates and executes a multi-table query task to obtain a query result, and generates a financial analysis report. The analysis system includes a management and maintenance module, a question analysis module, a user and question condition checking module, a target scene set and scene expansion range determination module, a target data table set generation module, a multi-table query task module, and a financial analysis report generation module. The present application automatically completes multi-table data extraction through natural language questions without specifying data tables.

Description

Technical Field

[0001] This invention belongs to the field of computer data processing technology, specifically relating to a financial analysis method and system based on hierarchical scenarios and related data table extensions. Background Technology

[0002] When companies conduct operational analysis, budget execution analysis, or analysis of indicators such as expenses and profits, the required financial data is typically distributed across multiple dimensions, including indicator summaries, revenue and cost details, expense details, and tables organized by organization, project, and account. For example, when analysts encounter the question "A company's profit margin has decreased compared to the previous period," they often need to first confirm the indicator definition, then search for relevant data based on organizational and period conditions, and summarize and verify the results from different sources. This process relies on the analyst's familiarity with the purpose of the data tables, the meaning of the fields, and the data definitions. When there are many data tables or the analysis dimensions change, incomplete data retrieval, duplicate data retrieval, or inconsistent definitions can easily occur.

[0003] Existing financial data platforms typically use pre-configured datasets, subject areas, reports, or single data tables as query boundaries. Users can set conditions such as organization, time, and indicators within a given scope, and some systems also support inputting query conditions via natural language. However, the results of natural language processing usually still need to fall within the selected dataset or report range. When a problem involves indicator results, influencing factors, and organizational dimensions simultaneously, or when the required fields are scattered across different data tables, users still need to manually determine which data tables to supplement and how to link them. Therefore, there is a need for a financial analysis method and system that can automatically determine the query scope and automatically organize related data tables based on the financial analysis problem. Summary of the Invention

[0004] The technical problem this invention aims to solve is: when a user poses a financial analysis question in natural language without specifying a particular data table, how to automatically determine the executable set of target data tables and multi-table query tasks, thereby avoiding manual table selection, repeated data retrieval, and mismatch of data types; it also aims to solve the problem of connecting the natural language parsing results with the database query structure.

[0005] To address the aforementioned technical problems, this invention employs a combination of offline configuration and online analysis. The offline configuration component maintains the financial analysis scenario, data table relationships, question parsing rules, and parameterized query templates; the online analysis component, based on the user's natural language questions, sequentially completes question parsing, condition validation, scenario determination, data table expansion, and query task orchestration. The technical solution adopted by this invention is as follows: The financial analysis method based on hierarchical scenarios and related data tables includes the following steps: S1. Establish a financial domain scenario index table, a data table association index table, and a scenario matching rule table based on a relational database; construct a problem parsing vector library based on a text embedding model and a vector database; and register parameterized query templates based on a structured query language. S2. Receive financial analysis requests through the user interaction terminal, convert natural language questions into query vectors, retrieve candidate entries from the question parsing vector library, and use the large language model to perform structured parsing of natural language questions, candidate entries, and the current date to obtain candidate standard question conditions. S3. Verify the user and candidate standard question conditions. Obtain the user's authorized organization set and accessible data table set through verification. Form the target standard question conditions based on the verified candidate standard question conditions. S4. Compare the target standard problem conditions with the scene matching rules in the scene matching rule table to determine the target scene set and determine the scene expansion range; S5. Filter the data tables that are related to the target scene set and the scene extension range from the data table association index table to form a candidate data table set, and verify the candidate data table set to form the target data table set; S6. Generate a multi-table query task based on the target data table set, execute the multi-table query task, and obtain the query results; S7. Generate a financial analysis report based on the target scenario set, target data table set, and query results.

[0006] Preferably, the financial domain scenario index table in S1 records multiple financial analysis scenarios. Each financial analysis scenario records at least one of the following: scenario identifier, scenario level, scenario weight, applicable analysis scope, target indicator, and scenario keywords, as well as the parent scenario identifier or associated scenario identifier. The data table association index table includes a data table registration information table, a scenario-data table association record table, and a data table association path table. The problem parsing vector library stores problem classification templates, a financial terminology dictionary, an organizational object dictionary, and time expression recognition rules, as well as search entries in the problem classification templates.

[0007] Preferably, the financial analysis request in S2 includes a natural language question and a user identifier. The text embedding model is called to convert the natural language question into a query vector. The cosine similarity between the query vector and the search entries is calculated in the question parsing vector library. Several search entries with high cosine similarity are selected as candidate entries. The natural language question, candidate entries, and current date are concatenated into prompt words and input into the large language model. The large language model outputs candidate standard question conditions. The candidate standard question conditions include at least the analysis scope, target indicators, organizational objects, time conditions, and comparison methods.

[0008] Preferably, the verification method for candidate standard problem conditions in S3 is as follows: the target indicator is matched and verified with the financial terminology dictionary to confirm the standard indicator name and scope; the organizational object is matched and verified with the organizational object dictionary to confirm the standard organizational identifier; the start and end dates obtained from the time condition conversion are verified with the time expression recognition rules to confirm that the current period and the comparison period are valid accounting periods; the analysis scope is matched and verified with the problem classification template to confirm the standard analysis scope; after all the target indicators, organizational objects, time conditions and analysis scope verifications are passed, the target standard problem conditions are formed.

[0009] Preferably, in S4, the comparison between the target standard problem conditions and the scenario matching rules adopts a vector retrieval and large language model fallback method; the scenario expansion scope includes the associated scenarios that are allowed to be used in order to supplement the necessary fields missing in the target scenario, or to connect the association paths between data tables that are not directly related.

[0010] Preferably, in S5, based on the target scene set, scene expansion range, and target standard problem conditions, the scene-data table association record table is retrieved, and the data table that is associated with the scenes in the target scene set and scene expansion range and whose association weight reaches the current association weight threshold is added to the candidate data table set.

[0011] Preferably, in S6, each query task records at least the target data table identifier, scenario identifier, query template identifier, template version, runtime parameters, and preceding task identifier.

[0012] Preferably, the analytical text in the financial analysis report in S7 is generated by the large language model based on the query results, and numerical constraints are imposed on the large language model: the numerical values ​​in the financial analysis report can only be taken from the query results and cannot be written by the user.

[0013] The financial analysis system based on hierarchical scenarios and related data tables is used to implement the aforementioned financial analysis method based on hierarchical scenarios and related data tables. The financial analysis system is deployed between the user interaction terminal and the financial data platform, and includes: management and maintenance module, problem analysis module, user and problem condition verification module, target scenario set and scenario expansion scope determination module, target data table set generation module, multi-table query task module and financial analysis report generation module. The management and maintenance module is used to manage and maintain the financial domain scenario index table, data table association index table, scenario matching rule table, problem parsing vector library, and parameterized query templates. The question parsing module is used to convert natural language questions into query vectors, retrieve candidate entries from the question parsing vector library, and input the natural language question, candidate entries, and current date into the large language model; The user and issue condition verification module is used to verify users and candidate standard issue conditions. Through verification, it obtains the user's authorized organization set and accessible data table set, and forms the target standard issue conditions based on the verified candidate standard issue conditions. The target scenario set and scenario expansion range determination module is used to compare the target standard problem conditions with the scenario matching rules to determine the target scenario set and to determine the scenario expansion range; The target data table set generation module is used to filter data tables that are related to the target scene set and the scenes in the scene extension range from the data table association index, form a candidate data table set, and verify the candidate data table set to form the target data table set; The multi-table query task module is used to generate multi-table query tasks based on the target data table set, and to interact with the financial data platform to execute the multi-table query tasks and obtain query results. The financial analysis report generation module is used to generate financial analysis reports based on the target scenario set, the target data table set, and the query results.

[0014] The beneficial effects of this invention are: Based on the inherent characteristics and patterns of financial statements and analytical needs, this invention uses a hierarchical financial analysis scenario as an intermediate carrier for understanding problems and organizing data. The large language model is only used to generate candidate conditions. The final query structure is constrained by the scenario index, data table association index, and parameterized query template. Users are no longer required to pre-determine which data tables to query. Instead, they can gradually determine the relevant data tables, fields, and their association paths within the authorized scope, based on the confirmed indicators, organization, period, and analytical intent. When the information required for analysis is scattered across multiple tables, it can automatically organize interconnected query tasks, reducing manual table selection, duplicate data retrieval, and mismatched definitions, thereby improving the efficiency and accuracy of financial analysis. Attached Figure Description

[0015] Figure 1 This is a flowchart of the financial analysis method according to Embodiment 1 of the present invention; Figure 2 This is an architecture diagram of the financial analysis system according to Embodiment 2 of the present invention. Detailed Implementation

[0016] The technical solution of the present invention will be described below with reference to the accompanying drawings and specific embodiments. The described embodiments are only some implementations of the present invention and are not intended to limit the scope of protection of the present invention.

[0017] Example 1

[0018] like Figure 1As shown, Embodiment 1 of the present invention provides a financial analysis method based on hierarchical scenarios and related data tables. The scenario names, weight values, table identifiers, thresholds, and data contents used are all examples. The specific steps are as follows: S1. Before receiving financial analysis requests, first establish a financial domain scenario index table, a data table association index table, and a scenario matching rule table; construct a problem parsing vector library; and register parameterized query templates. A financial domain refers to a specific business area within an enterprise or data system, categorized around capital changes, accounting, and financial management, encompassing the entire chain of financial activities and their data sets, including financing, investment, revenue and expenditure, costs, taxes, and reports.

[0019] The financial domain scenario index table, data table association index table, and scenario matching rule table are established through the configuration interface provided by the management and maintenance module. Administrators fill in the scenario, data table association, and matching rule information in the form on the configuration interface. The management and maintenance module saves the information as basic data tables (financial domain scenario index table, data table association index table, and scenario matching rule table) in a relational database (such as MySQL, a database software that stores data in a row and column format for a long time). The basic data tables are stored permanently in the database on the application server. Each time a financial analysis begins, the system reads the basic data tables required for the analysis from the database into memory for use. After the analysis ends, the data in memory is released, but the basic data tables in the database are retained for future use.

[0020] The Financial Domain Scenario Index Table records multiple financial analysis scenarios. Each financial analysis scenario is stored as a single row in the Financial Domain Scenario Index Table. The meanings of the fields in each row are as follows: Scene identifier: A unique number for the financial analysis scene, such as SC01; Scene hierarchy: The level of a scene in the hierarchical structure is represented by a number. 1 represents the indicator summary layer, and 2 represents the detailed composition layer. The scene hierarchy is used to limit the depth of subsequent scene expansion. Scene weight: A value between 0 and 1, with a larger value indicating that the scene is more frequently used; scene weight is used to sort the processing order of multiple scenes within the same level; Applicable analysis scope: The name of the analysis scope to which this scenario applies, such as "profit analysis"; Target metric: The name of the financial metric being queried in this scenario, such as "profit margin"; Scene keywords: Prompt words describing the scene, such as "profit margin, profit, revenue, cost and expenses", used for subsequent scene matching; One of the following: parent scene identifier or associated scene identifier: the parent scene identifier points to the scene above, indicating a hierarchical inheritance relationship; the associated scene identifier points to other scenes, indicating a cooperative relationship.

[0021] Financial analysis scenarios are connected through parent-child or association relationships: parent scenarios represent a broader scope of analysis, corresponding to data tables summarizing indicators; child scenarios represent the constituent dimensions such as revenue, cost, and expense corresponding to the target indicators, or the analysis dimensions such as organization, subject, and project, corresponding to data tables of details; association scenarios provide auxiliary fields that are missing in other scenarios, such as organizational dimension analysis scenarios that provide the correspondence between organizational codes and organizational levels.

[0022] In a relational database, the data table association index table consists of three tables: a data table registration information table, a scenario-data table association record table, and a data table association path table. The data table registration information table includes at least the data table identifier, physical table name, field set, organization field, time field, applicable organization scope, applicable time range, data table status, table structure version, and query template status for each record. The scenario-data table association record table describes the use of a data table in a given scenario. Each record includes at least the scenario identifier, data table identifier, association type, field mapping, data table priority, and association weight. The association weight ranges from 0 to 1, indicating the degree of relevance between the data table and the scenario. When the same data table is associated with multiple financial analysis scenarios, corresponding association records are saved separately. The data table association path table describes the available connection relationships between multiple data tables. Each record includes at least the associated data table identifier, associated field mapping, and connection order, for example, "Expense Details Table.Organization Code = Organization Dimension Table.Organization Code".

[0023] Scenario matching rules are stored in a relational database in the form of a mapping table. Each row in the mapping table records a target indicator, an analysis scope, and a scenario identifier, along with the scenario name and scenario keywords. The scenario matching rules also record the correspondence between the analysis scope and the maximum expansion level of the scenario, as well as the association weight threshold. For example, the target indicator "profit margin" and the analysis scope "comprehensive profit analysis" are mapped to the scenario identifier SC01.

[0024] The question resolution vector library is stored in a vector database (such as Milvus, a database software specifically designed to store vectors and perform fast retrieval based on cosine similarity). The question resolution vector library stores question classification templates, a financial terminology dictionary, an organizational object dictionary, and time expression recognition rules. It also stores the search entries from the question classification templates: the sample text for each search entry (e.g., "Query profit margin and revenue, cost, and expense composition") is first converted into a fixed-length floating-point vector by a text embedding model, and then written into the vector database along with the entry identifier, entry type, and original content for long-term storage. A text embedding model is a model that can convert a piece of text into a set of numbers (i.e., vectors). Texts with similar meanings will produce similar vectors. This embodiment uses the locally deployed Qwen series text embedding model. The financial terminology dictionary records the correspondence between aliases of financial indicators and standard indicator names and definitions, such as "net profit margin" corresponding to the standard indicator "profit margin"; the organizational object dictionary records the correspondence between organizational abbreviations and standard organizational identifiers, such as "East China Company" corresponding to organizational code ORG001; the time expression recognition rules record the conversion methods between common time writing in financial analysis and accounting periods, such as "2026Q2" being converted to the accounting period from April 1 to June 30, 2026, and "the same period last year" being converted to the same accounting period of the previous year.

[0025] Parameterized query templates are stored in the template table of the relational database in the form of Structured Query Language (SQL) statement templates. SQL query statements are the standard language for requesting data from the database; parameterized query templates are like pre-written fill-in-the-blank questions: the fixed structure of which data tables, fields, joins, and summaries are involved in the query is pre-written, leaving only question mark placeholders (i.e., value parameter positions) in the organizational conditions, time conditions, and filter values. At runtime, only the specific condition values ​​are filled into the placeholders. Parameterized query templates also record a structure identifier whitelist, i.e., a list of physical table names and field names allowed to appear in the query structure. Taking the Expense Details table (table structure version v2.1, fields include department code, expense subject code, accounting period, expense amount, organizational code, and project code) as an example, the template for the Expense Details table is shown in Table 1: Table 1

[0026] A correspondence is established between parameterized query templates and data table registration information and table structure version; when the table structure changes, parameterized query templates that are incompatible with the new table structure version are put into a pending review status.

[0027] S2. Receive financial analysis requests. These requests contain natural language questions and user identifiers, obtained by the system from the user's client via the Hypertext Transfer Protocol (HTTP) interface. During parsing, the system first replaces jargon and organizational abbreviations in the natural language questions with standard expressions according to the financial terminology dictionary and the organizational object dictionary, for example, replacing "net profit margin" with "profit margin." Then, it calls the same text embedding model used to build the question parsing vector library to convert the replaced standard expressions of the natural language questions into fixed-length query vectors. Next, it calculates the cosine similarity between the query vectors and each search entry in the question parsing vector library (cosine similarity measures the closeness of text meaning by the cosine of the angle between two vectors; a value closer to 1 indicates closer meaning), and sorts them from high to low cosine similarity, for example, taking the top K as candidate entries, where K is 5.

[0028] The large language model then performs structured parsing: it concatenates the natural language question, candidate entries, and current date into prompts, which are then input into the large language model (e.g., a locally deployed DeepSeek or Qwen series model). The large language model outputs candidate standard question conditions according to the predefined correspondence between field names and field values. Candidate standard question conditions include at least the analysis scope, target metric, organizational object, time condition, and comparison method. The time condition is converted by the large language model according to time expression recognition rules; that is, it converts time expressions such as "2026Q2" and "last year's period" to the start and end dates of the current and comparison periods based on the current date. If the conversion fails, the most recent closed accounting period is used by default. The analysis scope indicates the content that needs to be covered in this round of querying, used to determine the scenario expansion level and association weight threshold. In S2, the large language model only generates candidate standard question conditions and does not generate unvalidated physical table names, field names, or query structures.

[0029] S3. Verify the user and candidate standard question conditions. The user verification method is as follows: The system reads the permission data table pre-configured by administrators in the relational database based on the user identifier to obtain the user's authorized organization set and accessible data table set. The candidate standard question conditions verification method is as follows: Match the target indicator with entries in the financial terminology dictionary to confirm its corresponding standard indicator name and scope; verify whether the organization object belongs to the authorized organization set by matching the organization object with entries in the organization object dictionary to confirm its corresponding standard organization identifier; verify the start and end dates obtained from the time condition conversion with the time expression recognition rules to confirm that both the current period and the comparison period are valid accounting periods; match the analysis scope with entries in the question classification template to confirm its corresponding standard analysis scope.

[0030] Target standard problem conditions can only be formed after necessary conditions such as target metrics, organizational objects, time conditions, and analysis scope have been verified and passed. Candidate standard problem conditions that fail verification will not be used to determine the target scenario set, candidate data table set, or generate query tasks. In cases where necessary conditions are missing or multiple candidate standard problem conditions exist that cannot be eliminated, user confirmation is required before continuing execution.

[0031] S4. The target scenario set is determined by comparing the standard problem conditions with the scenario matching rules, and the scope of scenario expansion is also determined. The comparison employs a dual-channel approach: vector retrieval and a large language model as a fallback. The scenario names and keywords for each financial analysis scenario have been converted into scenario vectors by a text embedding model and stored in a vector database. During comparison, the target indicators and analysis scope text in the standard problem conditions are converted into condition vectors. The cosine similarity between the condition vectors and each scenario vector is calculated in the vector database and used as the scenario matching degree. The scenario with the highest matching degree that reaches the matching threshold (e.g., 0.5) is selected as the target scenario. When no scenario reaches the matching threshold, the large language model selects a target scenario from all financial analysis scenarios based on the scenario names and keywords of each scenario. The scenario matching degree is used for filtering target scenarios and determining the order in which subsequent data tables are added.

[0032] The scope of scenario expansion includes allowed association scenarios used to supplement necessary fields missing in the target scenario, or to connect association paths between data tables that are not directly related.

[0033] Based on the analysis scope, the maximum expansion level and association weight threshold of the scene are found in the scene matching rules: the wider the data content corresponding to the analysis scope, the larger the allowed expansion level. Single indicator query corresponds to expansion level 1 and association weight threshold 0.8, that is, only the scene from which the target indicator originates is expanded; comprehensive analysis corresponds to expansion level 2 and association weight threshold 0.6, that is, expansion to the sub-scenes corresponding to the constituent dimensions of the target indicator is allowed.

[0034] During the scenario expansion process, the parent-child relationship financial analysis scenarios and related relationship financial analysis scenarios are traversed in the order of scenario level, scenario weight, and scenario matching degree. Scenarios that have already been included in the target scenario set or scenario expansion scope are not processed repeatedly, and finally the target scenario set and scenario expansion scope are formed.

[0035] S5. Expand the data tables associated with the target scene set and the scenes within the scene expansion range from the data table association index to form a candidate data table set, and verify the candidate data table set to form the target data table set.

[0036] Based on the target scenario set, scenario expansion scope, and target standard problem conditions, retrieve scenario-data table association records. Data tables that are associated with scenarios in the target scenario set and scenario expansion scope, and whose association weight reaches the current association weight threshold, are added to the candidate data table set. The order in which data tables are added is determined by scenario weight, scenario matching degree, data table priority, and association weight.

[0037] When a data table is associated with multiple scenarios through multiple scenario-data table association records, only one data table identifier is retained in the candidate data table set, while all valid association records between that data table and each scenario are retained, in order to distinguish the use of the data table in different scenarios.

[0038] For the candidate data table set, first delete data tables that are not in the current user's accessible data table set, and exclude related records of data tables whose applicable organizational scope or applicable time range does not cover the target standard problem conditions. If no valid related records exist in the same data table that can support the current target scenario or the scenario's extended scope, then that data table is deleted from the candidate data table set.

[0039] Perform a global field coverage check on the candidate data table set after deletion and exclusion operations to verify whether the candidate data table set collectively covers the target indicator field, organization field, time field, and necessary fields corresponding to the target scenario. The global field coverage check does not require a single data table to contain all necessary fields. When necessary fields are located in multiple data tables, the candidate data table set is considered to meet the field coverage condition only if there are usable data table association paths between these data tables.

[0040] When the candidate data table set lacks necessary fields, and there are still unprocessed valid scenario-data table association records or data table association paths within the scenario expansion range, the search continues from the unprocessed scenario-data table association records within the scenario expansion range according to scenario weight, scenario matching degree, data table priority, and association weight, and a new data table is added. When there are no unprocessed association records within the scenario expansion range, the search continues by lowering the association weight threshold or expanding the scenario expansion range. The scenario-data table association records between the newly added data table and its actual associated scenario are retained. If a data table cannot be connected to an available data table association path, or if the overall field coverage condition is still not met after expansion, the corresponding isolated data table is excluded or the generation of this round of query task is terminated.

[0041] After completing the overall field coverage verification, the following checks are performed: table status, table structure version, query template status (i.e., verifying whether each data table has a published parameterized query template that matches its table structure version; one data table can correspond to one or more parameterized query templates), and data table association paths. Candidate data tables whose status is unavailable, whose table structure version is incompatible with the query template, or whose query template is not published or cannot be accessed via an available association path are excluded. The candidate data tables that pass the above verification, along with their associated records, field mappings, and data table association paths, constitute the target data table set.

[0042] The data generated during the processing of S1 to S5, including candidate standard problem conditions, target standard problem conditions, target scenario set, scenario expansion scope, candidate data table set, and target data table set, are all generated in memory by each module of the system in the form of field names and field values. They are passed as input to the next step and are released from memory after this round of analysis is completed. They are not stored separately for a long time. The only content that needs to be retained is the query task and query results in S6. They are written to the query log table of the relational database for long-term storage and are used for the traceability of values ​​in the financial analysis report.

[0043] S6. Generate a multi-table query task based on the target data table set, execute the multi-table query task, and obtain the query results. Select a query template from published parameterized query templates that are compatible with the target data table, table structure version, and target standard question conditions; physical table names, field names, and join relationships are selected only from the data table registration information and structure identifier whitelist, and cannot be directly generated or changed by natural language questions or unvalidated candidate standard question conditions; organizational conditions, time conditions, indicator conditions, and filter values ​​are written to the value parameter bits through binding parameters to form a read-only query task. The original text of the natural language question is not included in the physical table name, field name, or query structure location. Read-only means that the query task only allows reading data and does not allow modification or deletion of data.

[0044] Each query task records at least the target data table identifier, scenario identifier, query template identifier, template version, runtime parameters, and preceding task identifier. Query tasks that depend on a preceding task are executed only if the preceding task executes successfully and its query results satisfy the input conditions of the subsequent task; for example, if a preceding task retrieves a list of organization codes for the target organization and its subordinate organizations from the organization dimension table, the subsequent task will write this list into its own value parameter as an organization condition. Query tasks without preceding dependencies and whose input conditions are already met can be executed in parallel.

[0045] The query task is submitted to the financial data platform for execution through a read-only database connection interface (such as JDBC). The financial data platform uses a relational database (such as MySQL or Doris). During execution, prepared statements are used to fill the condition values ​​into the value parameter bits to obtain the query results. The query results, along with the query task record, are written to the query log table of the relational database for long-term storage.

[0046] S7. Generate a financial analysis report based on the target scenario set, target data table set, and query results. The analytical text in the financial analysis report is generated by the large language model based on the query results, and numerical constraints are imposed on the large language model: the numerical values ​​in the financial analysis report can only be taken from the query results and cannot be written by the user. The chart section generates a Graphical Description Language (DSL) based on the query results and scenario identifiers. The DSL must at least record the query result identifier, scenario identifier, chart type, dimension field, indicator field, sorting field, and display parameters. Before generating the chart, verify that the query result identifiers and fields referenced by the DSL exist in the corresponding query results. If the verification passes, the chart is generated; otherwise, the corresponding chart is not generated.

[0047] The report establishes a referencing relationship between key values ​​and the query result identifiers and result fields that generated those values, enabling the key values ​​to be traced back to their corresponding data tables and query results. The generated financial analysis report is permanently stored in a relational database's financial analysis report table, available for users to view and export on the user interface.

[0048] In Embodiment 1 of this invention, users pose financial analysis questions in natural language without specifying data tables. The system determines the target standard question conditions through question parsing vector library retrieval and large language model parsing. It then determines the target scenario set through scenario vector comparison and a two-channel matching process using the large language model as a fallback. Finally, it automatically generates an executable target data table set and a read-only query task through data table association indexes and multi-dimensional verification. Throughout the process, the large language model is used only in controlled locations: it only generates candidate question conditions, participates in scenario fallback selection, and writes report text. Physical table names, field names, and query structures are always constrained by the financial domain scenario index, data table association index, structure identifier whitelist, and parameterized query templates. Report values ​​are always taken from actual query results. Combined with permission, table structure, template status, and association path verification, the query task is constrained before execution, reducing manual table selection, duplicate data retrieval, and mismatched definitions, and ensuring the traceability of every value in the financial analysis report.

[0049] Example 2

[0050] like Figure 2As shown, Embodiment 2 of the present invention provides a financial analysis system for implementing the financial analysis method based on hierarchical scenarios and related data table expansion described in Embodiment 1. The system includes: a management and maintenance module, a problem parsing module, a user and problem condition verification module, a target scenario set and scenario expansion scope determination module, a target data table set generation module, a multi-table query task module, and a financial analysis report generation module. The financial analysis system is deployed on an application server between the user interface and the financial data platform. The system receives natural language questions and user identifiers sent by the user interface via an HTTP interface, submits query tasks to the financial data platform via a read-only database connection interface, and receives the query results to generate a financial analysis report.

[0051] The management and maintenance module is used to manage and maintain the financial domain scenario index, data table association index, scenario matching rules, problem parsing vector library, and parameterized query templates in S1. The management and maintenance module provides a configuration interface through which administrators input financial domain scenarios, data table registration information, scenario-data table association records, data table association paths, scenario matching rules, search entries, financial terminology dictionary entries, organizational object dictionary entries, time expression recognition rules, and parameterized query templates. The input indexes and rules are saved as data tables in a relational database, while search entries and scenario keywords are generated into vectors by the management and maintenance module using a text embedding model and then written to a vector database.

[0052] The question parsing module is used to execute the steps in S2. It replaces the jargon and organizational abbreviations in the natural language question with financial terminology and organizational object dictionaries. It calls the text embedding model to convert the replaced question text into a query vector, initiates a similarity retrieval request to the vector database, selects the top K search entries as candidate entries based on cosine similarity, and concatenates the natural language question, candidate entries, and current date into a prompt word to call the large language model to obtain the candidate standard question conditions.

[0053] The user and issue condition verification module is used to execute the steps in S3. Based on the user identifier, it reads the permission data table to obtain the authorized organization set and the accessible data table set, and matches and verifies the candidate standard issue conditions item by item according to the financial terminology dictionary, organization object dictionary, time expression recognition rules and issue classification template to form the target standard issue conditions.

[0054] The target scene set and scene expansion range determination module is used to execute the steps in S4. It converts the target indicators and analysis range text into condition vectors, calculates the cosine similarity with the scene vectors of each scene to obtain the scene matching degree, and selects the scene with the highest matching degree that reaches the matching threshold as the target scene. If no scene reaches the threshold, the large language model is used as a fallback. Then, based on the analysis range, it finds the maximum expansion level of the scene and the association weight threshold, and traverses the parent-child relationship and association relationship between scenes according to the scene level, scene weight and scene matching degree to form the target scene set and scene expansion range.

[0055] The target data table set generation module is used to execute the steps in S5, retrieve scenario-data table related records to form a candidate data table set, and perform checks on the accessible data table set, applicable organizational scope, applicable time range, field coverage, data table status, table structure version, query template status, and data table association path to form the target data table set.

[0056] The multi-table query task module is used to execute the steps in S6. It generates read-only query tasks from published and adapted parameterized query templates, writes organizational conditions, time conditions, indicator conditions and filter values ​​into the value parameter bits, arranges the execution order according to the preceding task identifier, executes the query tasks on the financial data platform through the read-only database connection interface and pre-compiled statements, and writes the query tasks and query results into the query log table.

[0057] The financial analysis report generation module executes the steps in S7. Under numerical constraints, the large language model generates report text based on the query results, generates a graphical description language (DSL) and generates charts after verification, establishes the retracement relationship of key values, and writes the financial analysis report into the report table for saving.

[0058] Example 3

[0059] In Embodiment 3 of the present invention, a user's financial analysis request is used as an application example to specifically illustrate the execution process of the financial analysis method described in Embodiment 1 and the financial analysis system described in Embodiment 2.

[0060] First, the system receives a financial analysis request from the user interface, which includes a natural language question and user identifier. The specific content of the financial analysis request is: "Profit margin, revenue, cost and expense of East China Company in Q2 2026".

[0061] 1. Utilizing the various indexes, scenario matching rules, and problem parsing vector library built by the management and maintenance module, organize the relevant data table configurations according to the financial analysis scenarios. Table 2 provides an example of the financial analysis scenarios and data table configurations corresponding to this application instance.

[0062] Table 2

[0063] In Table 2, the scene identifier, scene level, analysis scene, and scene keywords correspond to the financial domain scene index; the associated data tables and data table uses correspond to the scene-data table related records; and the field mappings and join relationships correspond to the data table related paths. Profit analysis is the target scene for this round of requests. Revenue detail analysis, cost detail analysis, and expense detail analysis are sub-scenes of profit analysis, while organizational dimension analysis is a related scene used to supplement the organizational level fields.

[0064] 2. The question parsing module first replaces the question text with standard expressions according to the financial terminology dictionary and the organizational object dictionary. Then, it calls the text embedding model to obtain the query vector. In the question parsing vector library, it retrieves five candidate entries related to indicators, organizations, time, and question classification based on cosine similarity. The large language model performs structured parsing based on the natural language question, candidate entries, and the current date, generating the candidate standard question conditions shown in Table 3. Among them, "2026Q2" is converted into the accounting period from April 1 to June 30, 2026.

[0065] Table 3

[0066] 3. The user and issue condition verification module verifies the user and candidate standard issue conditions. It verifies the target indicator corresponding to "profit margin" using a financial terminology dictionary; verifies the organization code ORG001 corresponding to "East China Company" using an organization object dictionary; checks that the start and end dates obtained from the time condition conversion belong to a valid accounting period; and verifies the comprehensive profit analysis scope corresponding to "profit margin and revenue, cost, and expense status" using an issue classification template. The system confirms that organization code ORG001 belongs to the user's authorized organization set and obtains the set of data tables accessible to the user. Once verification passes, the target standard issue conditions are formed; candidate values ​​that fail verification are not included in the scenario and data table filtering.

[0067] 4. The target scenario set and scenario expansion scope determination module compares the target standard problem conditions with the scenario matching rules: The target indicator "profit margin" and the analysis scope "comprehensive profit analysis" text are converted into condition vectors, and the cosine similarity is calculated with the scenario vectors of each scenario. SC01 (scenario keywords "profit margin, profitability") has the highest scenario matching degree, which is 0.92 and reaches the matching threshold of 0.5. SC01 is selected as the target scenario. According to the analysis scope "comprehensive profit analysis", the maximum expansion level of the scenario is found to be 2, and the association weight threshold is 0.6. The child scenarios of SC01, SC02, SC03, and SC04, are traversed and included in the target scenario set. Scenarios at the same level are processed in order according to scenario weight and scenario matching degree.

[0068] In this round of analysis, since the necessary fields of SC01 include organizational hierarchy, while the profit indicator table and each detailed table only provide organizational codes, the system includes the associated scenario SC05 in the scenario extension scope to obtain the organizational dimension table and connect the organizational hierarchy fields.

[0069] 5. The target data table set generation module obtains the corresponding scenario-data table association records in the order of SC01, SC02, SC03, and SC04 to obtain the profit indicator table, revenue detail table, cost detail table, and expense detail table; then, based on the scenario expansion scope, it obtains the organizational dimension table associated with SC05 to form a candidate data table set {profit indicator table, revenue detail table, cost detail table, expense detail table, organizational dimension table}, and the association weight of each associated record reaches the threshold of 0.6.

[0070] The following validation is then performed: First, data tables where users lack access permissions are excluded, as well as data table association records whose applicable organizational scope and applicable time range do not cover the East China Company and the 2026Q2 data; then, overall field coverage and association path validation are performed: the Profit Indicator table provides profit margin, profit amount, and revenue amount fields; the Revenue Details table provides revenue amount field; the Cost Details table provides cost amount field; the Expense Details table provides expense amount and expense account code fields; and the Organization Dimension table provides organization code and organization level fields. The Profit Indicator table, Revenue Details table, Cost Details table, and Expense Details table all include organization code and accounting period. The Organization Dimension table establishes association paths with other data tables through organization code. All data tables are in a queryable state, the table structure version is compatible with the selected query template, and the query template is in a published state. The validation passes, and the target data table set remains {Profit Indicator table, Revenue Details table, Cost Details table, Expense Details table, Organization Dimension table}.

[0071] 6. The multi-table query task module reads the scenario-data table association records, field mappings, and data table association paths from the target data table set to generate query tasks: Task T1 is an organization code query task, which queries the organization code ORG001 and its subordinate organization code list and organization hierarchy mapping from the organization dimension table, and executes without any prerequisite dependencies; Task T2 is a profit indicator query task; Tasks T3, T4, and T5 are revenue, cost, and expense detail query tasks, respectively, all of which use the execution result of T1 as the organization condition parameter bit and execute in parallel after T1 executes successfully. Each query task is generated from a published parameterized query template that is compatible with the data table structure version and is limited to read-only queries; for example, the expense detail query task summarizes the expense amount according to the expense account code and accounting period. The tasks are executed through JDBC pre-compiled statements. After execution, the query results along with the query task records are written to the query log table.

[0072] 7. The financial analysis report generation module generates financial analysis reports. The analytical text in the report is generated by a large language model based on query results under numerical constraints. For example, "East China Company's profit margin in Q2 2026 was X%, with revenue of Y yuan, cost of Z yuan, and expenses of W yuan," where X, Y, Z, and W are directly taken from the query results. Charts are generated by a graphical description language (DSL), such as a bar chart with expense item codes as dimension fields and expense amounts as indicator fields. Key values ​​are linked to query result identifiers. After generation, the financial analysis report is saved in a financial analysis report table for users to view and export.

Claims

1. A financial analysis method based on hierarchical scenarios and related data tables, characterized in that: Includes the following steps: S1. Establish a financial domain scenario index table, a data table association index table, and a scenario matching rule table based on a relational database; construct a problem parsing vector library based on a text embedding model and a vector database; and register parameterized query templates based on a structured query language. S2. Receive financial analysis requests through the user interaction terminal, convert natural language questions into query vectors, retrieve candidate entries from the question parsing vector library, and use the large language model to perform structured parsing of natural language questions, candidate entries, and the current date to obtain candidate standard question conditions. S3. Verify the user and candidate standard question conditions. Obtain the user's authorized organization set and accessible data table set through verification. Form the target standard question conditions based on the verified candidate standard question conditions. S4. Compare the target standard problem conditions with the scenario matching rules in the scenario matching rule table to determine the target scenario set and the scenario expansion range; S5. Filter the data tables that are related to the target scene set and the scene extension range from the data table association index table to form a candidate data table set, and verify the candidate data table set to form the target data table set; S6. Generate a multi-table query task based on the target data table set, execute the multi-table query task, and obtain the query results; S7. Generate a financial analysis report based on the target scenario set, target data table set, and query results.

2. The financial analysis method based on hierarchical scenarios and related data table expansion according to claim 1, characterized in that, The financial domain scenario index table in S1 records multiple financial analysis scenarios. Each financial analysis scenario records at least one of the following: scenario identifier, scenario level, scenario weight, applicable analysis scope, target indicator, scenario keyword, and either the parent scenario identifier or the associated scenario identifier. The data table association index table includes a data table registration information table, a scenario-data table association record table, and a data table association path table; the problem parsing vector library stores problem classification templates, a financial terminology dictionary, an organizational object dictionary, and time expression recognition rules, as well as search entries in the problem classification templates.

3. The financial analysis method based on hierarchical scenarios and related data table expansion according to claim 2, characterized in that, The financial analysis request in S2 contains a natural language question and a user identifier. The text embedding model is called to convert the natural language question into a query vector. The cosine similarity between the query vector and the search entries is calculated in the question parsing vector library. Several search entries with high cosine similarity are selected as candidate entries. The natural language question, candidate entries and the current date are concatenated into prompt words and input into the large language model. The large language model outputs candidate standard question conditions. The candidate standard question conditions include at least the scope of analysis, target indicators, organizational objects, time conditions and comparison methods.

4. The financial analysis method based on hierarchical scenarios and related data table expansion according to claim 3, characterized in that, The verification method for candidate standard problem conditions in S3 is as follows: Match the target indicator with the financial terminology dictionary to confirm the standard indicator name and scope; match the organizational object with the organizational object dictionary to confirm the standard organizational identifier; match the start and end dates obtained from the time condition conversion with the time expression recognition rules to confirm that the current period and the comparison period are valid accounting periods; match the analysis scope with the problem classification template to confirm the standard analysis scope; after all the target indicators, organizational objects, time conditions, and analysis scope verifications are passed, the target standard problem conditions are formed.

5. The financial analysis method based on hierarchical scenarios and related data table expansion according to claim 4, characterized in that, In S4, the comparison between the target standard problem conditions and the scenario matching rules adopts vector retrieval and large language model fallback methods; the scenario expansion scope includes the associated scenarios that are allowed to be used in order to supplement the necessary fields missing in the target scenario or to connect the association paths between data tables that are not directly related.

6. The financial analysis method based on hierarchical scenarios and related data table expansion according to claim 5, characterized in that, In S5, based on the target scenario set, scenario expansion range, and target standard problem conditions, the scenario-data table association record table is retrieved, and data tables that are associated with scenarios in the target scenario set and scenario expansion range and whose association weight reaches the current association weight threshold are added to the candidate data table set.

7. The financial analysis method based on hierarchical scenarios and related data table expansion according to claim 6, characterized in that, In S6, each query task records at least the target data table identifier, scenario identifier, query template identifier, template version, runtime parameters, and preceding task identifier.

8. The financial analysis method based on hierarchical scenarios and related data table expansion according to claim 7, characterized in that, In S7, the analytical text in the financial analysis report is generated by the large language model based on the query results, and numerical constraints are imposed on the large language model: the numerical values ​​in the financial analysis report can only be taken from the query results and cannot be written by the user.

9. A financial analysis system based on hierarchical scenarios and related data tables, characterized in that: To implement the financial analysis method based on hierarchical scenarios and related data table expansion as described in claim 1, the financial analysis system is deployed between the user interaction terminal and the financial data platform, including: a management and maintenance module, a problem analysis module, a user and problem condition verification module, a target scenario set and scenario expansion scope determination module, a target data table set generation module, a multi-table query task module, and a financial analysis report generation module; The management and maintenance module is used to manage and maintain the financial domain scenario index table, data table association index table, scenario matching rule table, problem parsing vector library, and parameterized query templates. The question parsing module is used to convert natural language questions into query vectors, retrieve candidate entries from the question parsing vector library, and input the natural language question, candidate entries, and current date into the large language model; The user and issue condition verification module is used to verify users and candidate standard issue conditions. Through verification, it obtains the user's authorized organization set and accessible data table set, and forms the target standard issue conditions based on the verified candidate standard issue conditions. The target scenario set and scenario expansion range determination module is used to compare the target standard problem conditions with the scenario matching rules in the scenario matching rule table to determine the target scenario set and the scenario expansion range; The target data table set generation module is used to filter data tables that are related to the target scene set and the scenes in the scene extension range from the data table association index table, form a candidate data table set, and verify the candidate data table set to form the target data table set; The multi-table query task module is used to generate multi-table query tasks based on the target data table set, and to interact with the financial data platform to execute the multi-table query tasks and obtain query results. The financial analysis report generation module is used to generate financial analysis reports based on the target scenario set, the target data table set, and the query results.

Images