Natural language index query method and system based on semantic graph and hybrid analysis

Abstract

This invention discloses a natural language indicator query method and system based on semantic graph and hybrid parsing, belonging to the field of intelligent data query technology. It aims to solve the technical problem that natural language indicator query systems cannot automatically select the optimal physical storage table based on query time granularity, leading to a trade-off between query performance and data granularity. The method includes: acquiring and parsing the user-input natural language query statement to identify the target indicator and query time granularity; determining a set of candidate fact tables corresponding to the target indicator and query time granularity based on a pre-constructed granularity-fact table mapping graph; and assigning differentiated weights to data scale cost and timeliness cost based on the storage type of each candidate fact table in the candidate fact table set. This invention has the advantages of embedding physical storage mapping information into the semantic graph and performing multi-objective routing decisions based on query cost and granularity matching, thereby balancing query response speed and analytical flexibility.

Description

Technical Field

[0001] This invention relates to the field of intelligent data query technology, and more specifically, to a natural language index query method and system based on semantic graph and hybrid parsing. Background Technology

[0002] With the development of enterprise data warehouse construction, to optimize query performance, the same business metrics are often redundantly stored at different time granularities. For example, daily detailed fact tables support daily drill-down analysis, while monthly summary fact tables support monthly report generation. However, existing natural language metric query systems typically decouple semantic parsing from physical query execution in their architecture design. After receiving the logical query generated by semantic transformation, the query engine lacks the ability to perceive the underlying multi-fact table storage model and has an intelligent routing mechanism. When a user asks a question with time granularity information in natural language, the system can only route the query to a specific fact table according to preset fixed rules, and cannot dynamically select the optimal storage table based on the specific time granularity of the query. If the fixed routing is to the detailed fact table, although the data granularity is flexible and can meet arbitrary drill-down requirements, the query needs to scan massive amounts of detailed data, resulting in excessively high response latency. If the fixed routing is to the summary fact table, although the query speed can be improved, the fine-grained analysis capability is lost, and the user's query needs for lower time-level data cannot be responded to.

[0003] A more prominent problem is that existing technologies cannot quantitatively assess the query costs of different candidate fact tables before query execution, cannot establish an automatic trade-off decision-making mechanism between data granularity accuracy and query execution efficiency, and cannot provide users with transparent data source explanations when a slightly coarser-granularity alternative fact table must be chosen. These technical deficiencies severely restrict the engineering application of natural language query systems in data-intensive business scenarios such as financial analysis, where there are strict requirements for query response speed and analytical granularity. In view of this, we propose a natural language indicator query method and system based on semantic graphs and hybrid parsing. Summary of the Invention

[0004] The purpose of this invention is to provide a natural language index query method and system based on semantic graph and hybrid parsing, so as to solve the technical problem that the natural language index query system cannot automatically select the optimal physical storage table according to the query time granularity, resulting in a trade-off between query performance and data granularity.

[0005] To address the aforementioned technical problems, this invention provides the following technical solution: a natural language index query method based on semantic graphs and hybrid parsing, comprising: Obtain and parse the natural language query statement input by the user, and identify the target metrics and query time granularity; Based on a pre-built granularity-fact table mapping, a set of candidate fact tables corresponding to the target metric and the query time granularity is determined; Based on the storage type of each candidate fact table in the candidate fact table set, differentiated weights are assigned to the data scale cost and the timeliness cost, and the expected query cost of each candidate fact table is calculated. Calculate the granularity matching degree between the original time granularity of each candidate fact table and the query time granularity, and weight and combine the granularity matching degree with the expected query cost to obtain the routing decision score. Select the candidate fact table with the highest routing decision score as the target fact table. When the time granularity of the target fact table does not exactly match the query time granularity, data source annotation information indicating the alternative time granularity level is generated, and the query is executed based on the target fact table, returning query results containing the data source annotation information.

[0006] Preferably, the calculation of the expected query cost for each candidate fact table includes: Based on the physical storage mapping information recorded in the granularity-fact table mapping diagram, the number of data rows to be scanned and the number of partitions to be accessed are estimated, and the data refresh latency is obtained. The expected query cost is calculated using the following expression. : ; in, To estimate the number of rows of data that need to be scanned, This is an estimate of the maximum number of rows in all fact table records within the granularity-fact table mapping diagram. This represents the number of partitions that need to be accessed. This represents the maximum number of partitions involved in a single query in the granularity-fact table mapping graph. The data refresh delay time for the fact table. The preset maximum acceptable delay time, The cost weight for the number of rows corresponding to the storage type. The partition cost weight corresponding to the storage type. The weight is the timeliness cost weight corresponding to the storage type, and the weight value is greater when the storage type is detailed level storage than when it is summary level storage.

[0007] Preferably, the calculation of the granularity matching degree between the native time granularity of each candidate fact table and the query time granularity, and the routing decision score, includes: The granularity matching degree is calculated according to the following expression. : ; in, To query the hierarchical distance between the time granularity and the native time granularity of the candidate fact table in the time hierarchy sequence defined by the semantic graph. This represents the maximum hierarchical distance of the time-level sequence. The routing decision score is calculated according to the following expression. : ; in, For the expected query cost, The maximum value of the query cost estimates in the current candidate fact table set. and These are the granularity matching degree weight and the query cost weight, respectively. .

[0008] Preferably, the process of constructing the granularity-fact table mapping includes: Obtain financial indicator definitions and time aggregation granularity information from multi-source business databases, and generate an indicator knowledge graph with indicator entities as nodes; In the indicator knowledge graph, time granularity compatibility edges are added to each indicator entity to represent the native time granularity and compatible time granularity paths supported by the indicator entity. Based on the physical storage model of the underlying data warehouse, each indicator entity is associated with a corresponding fact table at each compatible time granularity. The storage type, estimated number of data rows, partition coverage, and data refresh latency of the fact table are recorded in the physical storage mapping information to obtain the granularity-fact table mapping diagram.

[0009] Preferably, determining the set of candidate fact tables corresponding to the target metric and the query time granularity based on a pre-constructed granularity-fact table mapping includes: In the granularity-fact table mapping diagram, all fact table records associated with the target indicator are traversed; Filter out fact tables whose supported time granularity exactly matches the query time granularity or are reachable via the time granularity compatibility edge; When the natural language query statement contains dimensional constraints, fact tables that do not meet the dimensional drill-down requirements are removed, and the remaining fact tables are included in the candidate fact table set.

[0010] Preferably, the step of acquiring and parsing the natural language query statement input by the user, and identifying the target metric and query time granularity includes: The rule matcher based on the prefix tree structure is used to match the indicator names of the natural language query statement, the vector retrieval engine is called to calculate the semantic vector similarity, and graph traversal matching is performed based on the indicator entity attribute path in the granularity-fact table mapping graph to obtain the candidate indicator set. The candidate indicator set is sorted by confidence level. If the difference between the highest confidence result and the second highest confidence result meets the predetermined fuzzy conditions, a human-computer interaction clarification process is triggered to lock the target indicator. Otherwise, the highest confidence result is directly selected as the target indicator, and the time expression and dimensional constraints are parsed simultaneously.

[0011] Preferably, the returned query results containing data source annotation information include: After obtaining the query result data, the visualization intent is determined based on the data characteristics and dimensional composition of the query result data, and corresponding chart description information is generated; The inference process data, query result data, chart description information, and data source labeling information are pushed to the front-end interface in stages through a streaming protocol.

[0012] A natural language index query system based on semantic graph and hybrid parsing, comprising: The semantic graph construction module is used to build a semantic graph containing indicator entity nodes and time-granularity compatible relationships, and to extend the physical storage mapping information of indicator entity nodes to form a granularity-fact table mapping graph.

[0013] The hybrid parsing module is used to acquire the natural language query statement input by the user, and to identify the target indicators and query time granularity in the natural language query statement by using direct rule matching based on semantic graph, similarity retrieval based on vector semantics, and graph matching based on entity attribute path, and to extract structured query elements.

[0014] The fact table routing decision module is used to determine the set of candidate fact tables based on the granularity-fact table mapping graph, evaluate the expected query cost of each candidate fact table, and select the target fact table based on the multi-objective routing decision of granularity matching degree and query cost.

[0015] The query execution and result return module is used to convert structured query elements into structured query statements based on the target fact table and execute the query, as well as return the query result data to the front end.

[0016] An electronic device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the program to implement a natural language index query method based on semantic graph and hybrid parsing.

[0017] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a natural language index query method based on semantic graph and hybrid parsing.

[0018] Compared with the prior art, the beneficial effects of the present invention are: 1. This invention achieves intelligent fact table selection at the physical execution layer for natural language queries by constructing a granularity-fact table mapping graph and executing multi-objective routing decisions based on query cost and granularity matching. The system can automatically obtain all candidate fact tables associated with indicator entities and their physical storage mapping information from the semantic graph based on the query time granularity contained in the user's question. It then performs a multi-dimensional comprehensive quantitative evaluation based on data row scan cost, partition access cost, and data timeliness cost. Simultaneously, it calculates the closeness between the native time granularity of the candidate fact tables and the query time granularity. Through a weighted decision model, it uniformly weighs the granularity matching and query execution overhead, selecting the optimal target fact table from the candidate fact table set for query execution. This significantly reduces the data scanning scale and query latency while ensuring that the query results meet the analytical granularity requirements, overcoming the shortcomings of traditional solutions where query performance and data granularity cannot be simultaneously achieved due to fixed routing.

[0019] 2. Furthermore, this invention, building upon the construction of a granularity-fact table mapping and the execution of multi-objective routing decisions based on query cost and granularity matching, further improves the accuracy of routing decisions by introducing storage type weight coefficients to differentiate the query costs of detailed fact tables and summary fact tables. The system identifies whether a candidate fact table is a detailed-level or summary-level storage table based on its storage type recorded in the physical storage mapping information. Accordingly, it assigns different weight coefficients to the data row scan cost, partition access cost, and timeliness cost. This ensures that the detailed fact table, due to its large row count, is evaluated with a greater emphasis on scan cost, while the summary fact table, whose data is generated through periodic aggregation, is evaluated with a greater emphasis on data refresh timeliness. This accurately reflects the actual impact of different storage structures on query performance, ensuring that the routing decision score closely matches the actual overhead structure of the underlying data storage, and avoiding decision bias caused by uniform weight evaluation.

[0020] 3. Furthermore, this invention, based on the introduction of storage type weighting coefficients to differentiate the query costs of detailed fact tables and summary fact tables, achieves transparency in granularity degradation routing by generating data source annotation information when the time granularity of the target fact table does not precisely match the query time granularity. When the system autonomously selects a summary fact table with a native time granularity slightly coarser than the user's query granularity as the target fact table to optimize query performance, it automatically appends this alternative granularity level to the query results in the form of data source annotations. This annotation, along with the query result data, chart description information, and inference process data, is pushed to the front-end interface via a streaming protocol. This allows users to enjoy an efficient query response experience while clearly understanding the actual time granularity level upon which the current result data is based and the difference between it and the original query granularity. This eliminates concerns about the analytical scope caused by the system's autonomous routing decisions being a complete black box to the user, and enhances the reliability of the natural language query system in rigorous business scenarios such as financial analysis. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the overall method flow of the present invention; Figure 2 This is a flowchart illustrating the hybrid parsing mechanism of the present invention; Figure 3 This is a schematic diagram of the process for determining the candidate fact table and making routing decisions in this invention; Figure 4 This is a schematic diagram illustrating the process of constructing the granularity-fact table mapping diagram of this invention. Detailed Implementation

[0022] To facilitate understanding of the technical solution of the present invention by those skilled in the art, the technical solution of the present invention will now be further described in conjunction with the accompanying drawings.

[0023] Example 1, such as Figures 1-4 As shown, this invention provides a natural language index query method based on semantic graph and hybrid parsing, the method comprising: S1. Construct a semantic graph for the field of financial indicators.

[0024] S2. Obtain and parse the natural language query statement input by the user, and identify the target metrics and query time granularity.

[0025] S3. Match and retrieve data in the granularity-fact table mapping graph to determine the candidate fact table set.

[0026] S4. Evaluate the expected query cost for each candidate fact table.

[0027] S5. Perform multi-target routing decisions and determine a target fact table.

[0028] S6. Generate and execute structured query statements to obtain query result data.

[0029] S7. Return the query results to the front end.

[0030] In this embodiment of the invention, the above steps work together to form a complete closed loop from knowledge construction and semantic understanding to intelligent routing and query execution. Step S1 provides a structured decision-making basis for the entire method by deeply associating business semantics with physical storage structure. Step S2 ensures that user intent can be accurately captured and extracts the core elements required for routing decisions. Subsequently, steps S3 to S5 constitute the core decision chain of this method: the system is not confined to a fixed query path according to rules like traditional solutions, but first delineates all possible candidate sets based on the compatibility relationship in the semantic graph, which is the "breadth"; then, it introduces physical storage mapping information to quantitatively evaluate the query cost and granularity matching degree of each candidate fact table, which is the "depth"; finally, it makes the optimal solution through multi-objective trade-offs. This process perfectly solves the dilemma of choosing between a daily detail table with a large scan volume but good timeliness or a monthly summary table with a small scan volume but slightly worse timeliness when faced with a query such as "querying the average daily sales last month", achieving an intelligent and dynamic balance between query performance and result timeliness.

[0031] Take a specific financial analysis application scenario as an example. A company has stored several years' worth of sales data in its data warehouse. Every day at midnight, the data warehouse's ETL task loads the previous day's sales data into a "Daily Sales Details Table" with a storage type of detailed fact table. At the beginning of each month, another task aggregates and summarizes the previous month's daily data to generate a "Monthly Sales Summary Table" with a storage type of summary fact table. Both fact tables are associated with the same financial indicator, "Sales Revenue." The system pre-executes step S1, constructing the above mapping relationship for the "Sales Revenue" indicator node in the semantic graph. It also records in the physical storage mapping information that the estimated number of data rows in the "Daily Sales Details Table" is 500 million, the partition coverage is daily, and the data refresh latency is 1 hour; and the estimated number of data rows in the "Monthly Sales Summary Table" is 600,000, the partition is monthly, and the data refresh latency is 24 hours. At the same time, a time-granularity compatible relationship edge connects the "Daily" and "Monthly" nodes. When a user inputs "Query the company's total sales for last month," the hybrid parsing mechanism in step S2 identifies the target metric as "sales revenue," the query time granularity as "month," and the time range as "last month." Step S3 filters the granularity-fact table mapping diagram for the target metric "sales revenue," selecting both the "Daily Sales Details Table" and the "Monthly Sales Summary Table," which both satisfy a compatibility relationship (daily data can be aggregated upwards to be compatible with monthly granularity queries). These two tables together constitute a candidate fact table set. Subsequent steps S4 and S5 will comprehensively evaluate the cost and matching degree of these two candidate tables.

[0032] In one embodiment, the process of constructing a semantic graph and forming a granularity-fact table mapping graph in step S1 includes: acquiring financial indicator definitions, indicator calculation methods, indicator dimension associations, and time aggregation granularity information from a multi-source business database, and generating an indicator knowledge graph with indicator entities as nodes and relationships between indicators as edges; adding time granularity compatible relationship edges to each indicator entity in the indicator knowledge graph, whereby the time granularity compatible relationship edges represent the native time granularity supported by the indicator entity and the compatible time granularity paths for upward aggregation or downward drilling; based on the physical storage model of the underlying data warehouse, associating each indicator entity with a corresponding fact table under each compatible time granularity, and recording the storage type of the fact table, the estimated number of data rows based on statistical information, the partition coverage, and the data refresh latency in the physical storage mapping information, thereby obtaining the granularity. The fact table mapping graph; this semantic graph also contains organizational dimension hierarchical relationships and indicator business domain classification information.

[0033] In this embodiment, by explicitly and structurally representing the mapping knowledge from business to physical storage, a knowledge base is constructed that can be efficiently traversed and computed by the query routing decision module. The time-granularity compatible relationship edges not only describe "what it is" but also "how it can be transformed," making it possible to flexibly route from coarse-grained queries to fine-grained fact tables, and vice versa. The physical storage mapping information provides crucial quantitative basis for subsequent cost estimation.

[0034] As a specific implementation method, when acquiring information from multi-source business databases, a unified data governance platform can scan the data dictionary, metadata, and ETL task logs of each business database to automatically or semi-automatically extract metric definitions, scope, correlation dimensions, and the storage type and partition information of fact tables. For the estimated number of data rows, the row count value in the statistics table updated periodically by the database management system (such as Oracle or MySQL) can be directly referenced. Data refresh latency can be estimated by monitoring the execution completion time of ETL tasks, adding the average task execution time to the scheduling interval, and periodically updating the physical storage mapping information.

[0035] In one embodiment, the physical storage mapping information constructed in step S1 above records fact table types including detailed fact tables and summary fact tables; the data size estimation information includes estimated data row count and partition coverage; the data update characteristics include data refresh latency; the granularity-fact table mapping also stores the dimension granularity and drill-down dimension levels supported by the fact tables, as well as the roll-up and drill-down paths between fact tables.

[0036] In this embodiment, the distinction between fact table types (detailed and summary) serves as the basis for setting different weights in subsequent cost evaluation, as the two differ fundamentally in data volume and storage organization. Data size estimation information (number of rows and number of partitions) directly affects the I / O overhead of the query engine. Storage dimension granularity and roll-up / drill-down paths enable the routing decision module to accurately determine whether the data granularity of the fact table is fine enough to meet the requirements of dimension drill-down when processing queries with dimension constraints, avoiding the selection of fact tables with insufficient data granularity that would prevent the query results from reflecting the expected dimensional details.

[0037] As a specific implementation method, the dimensional granularity and drill-down dimensional hierarchy information supported by fact tables can be obtained by analyzing the primary key and foreign key definitions of the fact table, combined with dimensional modeling knowledge of data warehouses. For example, if the primary key of a fact table contains "Date" and "Store ID", then its native time granularity is "Day", and its dimension granularity includes the "Store" level. Its roll-up path may point to another summary fact table that only contains "Month" and "Region ID".

[0038] In one embodiment, the process of parsing natural language query statements using the hybrid parsing mechanism in step S2 above further includes: using a rule matcher based on a Trie prefix tree structure to quickly match the query statement with indicator names and aliases; simultaneously calling a vector retrieval engine to calculate the semantic vector similarity of the query statement; and performing graph traversal matching of associated indicators based on the indicator entity attribute paths in the semantic graph; ranking the candidate indicator set obtained through direct rule matching, similarity retrieval, and graph matching based on entity attribute paths with confidence scores; if the difference between the highest confidence result and the second highest confidence result meets a predetermined fuzzy condition, a human-computer interaction clarification process is triggered to lock the target indicator; otherwise, the highest confidence result is directly selected as the target indicator, and the time expression and dimensional constraints in the query statement are parsed simultaneously.

[0039] The hybrid parsing mechanism provided in this embodiment combines precise matching, semantic understanding, and contextual association capabilities. The Trie tree-based rule matcher achieves millisecond-level precise matching, solving the problem of rapid identification of standard indicator names and common aliases. Vector similarity retrieval can cover colloquial and ambiguous expressions from users; for example, when a user inputs "total sales amount," it can successfully match the standard indicator "sales revenue" with a similar semantic vector representation. Graph matching based on entity attribute paths utilizes the "indicator-business domain" attribution relationship in the semantic graph, enabling the location of specific indicators within a domain based on contextual business domain information, effectively avoiding cross-domain indicator ambiguity. Through a three-way recall confidence fusion and divergence handling mechanism, the robustness of indicator identification is greatly improved, and it can proactively trigger clarification interactions with users when ambiguity exists, avoiding queries based on erroneous inferences.

[0040] As a specific implementation, a rule matcher based on a Trie prefix tree can preload all standard metric names and their aliases registered in the business system. The vector retrieval engine can encode and index all metrics and their business descriptions using a pre-trained semantic model (such as BERT), calculating the cosine similarity between the query statement and the index vector in real time during parsing. Predefined fuzzy conditions can be set such that when the ratio of the highest confidence score to the second-highest confidence score is less than a threshold (e.g., 1.2) or the difference is less than a threshold (e.g., 0.15), a clarification process is triggered, displaying the Top-N candidate metrics on the interface for the user to select and confirm.

[0041] In one embodiment, the step of determining the candidate fact table set in step S3 above includes: traversing all fact table records associated with the target metric in the granularity-fact table mapping graph; filtering out fact tables whose supported time granularity precisely matches the query time granularity or are reachable via a time granularity compatible path; and when the query statement contains dimensional constraints, removing fact tables that do not meet the dimensional drill-down requirements and including the remaining fact tables in the candidate fact table set.

[0042] This embodiment details the logic of the initial screening of the fact table. This process does not consider all related tables at once, but rather generates a candidate set that is both feasible in terms of results and selectable in terms of performance through two screening criteria: "time granularity reachability" and "dimension satisfaction." Specifically, when the query time granularity is "month," a detailed fact table with a native granularity of "day" is considered "reachable" because it can generate monthly data through a compatible upward aggregation path. However, when the query includes a "view by store" dimension constraint, a summary table that only summarizes to the "region" level will be eliminated because it does not meet the drill-down requirement to the "store" level. This ensures that the candidate set for routing decisions is logically qualified from the outset.

[0043] As a specific implementation method, determining the time-granularity compatible path can be achieved through a graph search algorithm. For example, starting from the query time granularity, a depth-first or breadth-first search can be performed on the time-level relationship edges of the semantic graph to find a path from the original granularity node of the fact table to the target granularity node. The verification of the dimension drill-down requirement can be achieved by comparing the dimension name in the "dimensional constraint" with the finest granularity of each dimension level in the "supported dimension granularity" list stored in the fact table. If the dimension granularity supported by the fact table is equal to or finer than the dimension of the constraint, then the requirement is met.

[0044] In one embodiment, the step of evaluating the expected query cost of each candidate fact table in step S4 above includes: determining whether the candidate fact table is a detailed-level storage or a summary-level storage based on its storage type; estimating the number of data rows to be scanned and the number of partitions to be accessed based on the data size estimation information recorded in the physical storage mapping information, combined with the query time granularity and the time filtering conditions contained in the query statement; evaluating whether the data freshness of the fact table meets the timeliness requirements of the query time granularity based on the data update characteristics recorded in the physical storage mapping information; and generating a query cost estimate for each candidate fact table by combining the storage type, estimated number of rows, number of partitions, and timeliness evaluation results; wherein the query cost estimate is determined according to the following expression: ; in, This is an estimate of the query cost for the candidate fact table. To estimate the number of rows of data that need to be scanned, This is an estimate of the maximum number of rows in all fact table records within the granularity-fact table mapping diagram. This represents the number of partitions that need to be accessed. This represents the maximum number of partitions involved in a single query in the granularity-fact table mapping graph. The data refresh delay time for the fact table. The preset maximum acceptable delay time, The cost weight for the number of rows corresponding to the storage type. The partition cost weight corresponding to the storage type. The weight is the timeliness cost weight corresponding to the storage type, and the weight value is greater when the storage type is detailed level storage than when it is summary level storage.

[0045] This embodiment provides a specific method for quantifying multi-dimensional performance and timeliness factors into a single, comparable query cost. This cost formula comprehensively considers I / O intensity (number of rows scanned). ), calculate scheduling overhead (number of partitions) ) and data freshness (refresh latency) Its core principle lies in the weighting coefficient (). , , The weighting is not static but strongly correlated with the storage type of the fact table. Detail-level storage typically involves extremely large amounts of data, making the number of scanned rows and partitions the main performance bottlenecks; therefore, the weights for row count and partition cost are high. Summary-level storage, on the other hand, has smaller data volumes and is less sensitive to scans, but its data refresh latency is usually longer, making timeliness its main weakness; therefore, the weight for timeliness cost is amplified in the comparison. Through this differentiated weighting, the model can adaptively adjust its optimization focus based on storage characteristics, making the evaluation of detail tables more focused on "speed" and the evaluation of summary tables more focused on "newness."

[0046] As a specific implementation method, and The estimation can be completed by the query plan pre-analysis module. For example, if the query time range is "January 2024", for a daily detail table partitioned by day, it can be estimated that all partitions from January 1st to January 31st, 2024 need to be scanned, and the number of rows in the partition information statistics can be combined to obtain the result. and . The system administrator can preset the timeliness of data according to the business requirements. For example, it can be set to 5 minutes for real-time monitoring business and 48 hours for monthly review business. , , Equal weights can be optimized through offline experiments, simulating different query loads and measuring actual execution time and data freshness, using linear regression or machine learning methods.

[0047] In one embodiment, the step of performing multi-target routing decision in step S5 above includes: calculating a granularity matching score for each candidate fact table, the granularity matching score representing the closeness between the time granularity of the candidate fact table and the query time granularity; weighting and combining the granularity matching score with the expected query cost to obtain a routing decision score; selecting the candidate fact table with the highest routing decision score as the target fact table; when the time granularity of the target fact table does not exactly match the query time granularity, generating data source annotation information, the data source annotation information being used to indicate the alternative time granularity level on which the query result is based; wherein, the granularity matching score is calculated according to the following expression: ; in, The granularity matching score is the score. To query the hierarchical distance between the time granularity and the native time granularity of the candidate fact table in the time hierarchy sequence defined by the semantic graph. The maximum hierarchical distance for this time-level sequence; the routing decision score is calculated according to the following expression: ; in, Scoring of routing decisions To query the cost estimate, The maximum value of the query cost estimates in the current candidate fact table set. and These are the granularity matching degree weight and the query cost weight, respectively. .

[0048] In this embodiment, the decision-making process is upgraded from simple cost optimization to Pareto optimization based on "cost-accuracy". Granularity matching score. The introduction of this feature ensures that the system avoids choosing a coarse-grained fact table that deviates significantly from the user's intent in pursuit of ultimate performance. For example, if a user queries "daily sales," even if the query for "monthly summary table" is expensive... Extremely low, but the hierarchical distance between its native granularity "month" and the query granularity "day" is... The value is very high, resulting in a low matching score. Very low, thus lowering the overall score. The scoring calculation endows each candidate table with quantifiable comprehensive competitiveness. Meanwhile, the function of generating data source annotation information solves the transparency problem of routing decisions. When the system selects an alternative fact table with a non-exact match due to performance reasons, this mechanism does not silently return the result, but explicitly informs the user that "the currently returned data is aggregated from the monthly summary table," which greatly enhances the user's trust in the query results.

[0049] As a specific implementation, a time-level sequence can be defined as [second, minute, hour, day, week, month, quarter, year], with a distance of 1 between adjacent levels. The maximum level distance of this sequence is then defined. It is 7. and The configuration allows system administrators to adjust it according to the priorities of the business scenario. For example, in a real-time risk control scenario, the setting can be increased. Prioritize query performance; in granular auditing scenarios, the performance can be increased. This ensures that the returned data is highly consistent with the granularity of the query intent.

[0050] In one embodiment, the step of converting the structured query elements into a structured query statement for the target fact table in step S6 includes: encapsulating the target metrics, dimensions, time range, and filtering conditions into an intermediate query language; and having the multidimensional query engine dynamically compile the intermediate query language into a structured query statement adapted to the underlying data source according to the physical storage mode of the target fact table.

[0051] This embodiment constructs a query execution layer that decouples logical queries from physical implementation. An intermediate query language is used for encapsulation, allowing upstream routing decisions and semantic parsing modules to be uninvolved in whether the underlying database is a relational database or a columnar storage. The multidimensional query engine, as the compilation core, is responsible for adapting logical query intents to specific physical storage modes, achieving the effect of "parsing once, adapting to multiple platforms," ​​and enhancing the system's scalability to heterogeneous data sources.

[0052] As a specific implementation, the intermediate query language can be a JSON or XML structure based on standard SQL extensions, with metrics, dimensions, and time semantics. The multidimensional query engine internally maintains multiple dialect adapters. When the target fact table is located in a MySQL database, the MySQL dialect adapter is called to compile the intermediate language into MySQL. If the target fact table is a materialized view on Doris or ClickHouse, the corresponding dialect adapter is called to generate its specific query statement, and optimizations such as partition pruning and index hints may be performed for the specific engine.

[0053] In one embodiment, step S7 further includes: after obtaining the query result data, determining the visualization intent based on the data characteristics and dimensional composition of the query results, and generating corresponding chart description information; and pushing the reasoning process data, query result data, chart description information, and data source annotation information to the front-end interface in stages through a streaming protocol.

[0054] This embodiment enhances the intelligent and user experience aspects of the result return process. Automatically generating chart descriptions reduces the need for users to create tables from structured data, directly fulfilling their visualization needs. Employing a streaming protocol to push data in stages optimizes the user experience in long-running query scenarios. Users don't have to face a blank page with long wait times; instead, they can first see the system's reasoning process (e.g., "Indicator 'Sales' identified, selecting optimal data source..."), then receive data source annotations ("Queryed from: Daily Sales Details"), then see gradually unfolding charts, and finally obtain the complete dataset. This interactive mode significantly reduces user anxiety and provides transparency throughout the near-end of the decision-making process.

[0055] As a specific implementation method, visualization intent judgment can be based on a trained classification model. Taking into account factors such as the number of dimensions, the number of measures, and the data type of the query results, it can automatically determine the most suitable chart type, such as bar charts, line charts, and tables, and generate chart data JSON that matches the front-end chart component interface. The streaming protocol can employ Server Send Events (SSE) technology to push data from different stages as independent events to the browser in stages.

[0056] Example 2: The present invention also provides a natural language index query system based on semantic graph and hybrid parsing. The system includes: a semantic graph construction module, a hybrid parsing module, a fact table routing decision module, and a query execution and result return module.

[0057] The semantic graph construction module is used to build a semantic graph containing indicator entity nodes and time-granularity compatible relationships, and to extend the physical storage mapping information of indicator entity nodes to form a granularity-fact table mapping graph.

[0058] The hybrid parsing module is used to acquire the natural language query statement input by the user, and to identify the target indicators and query time granularity in the natural language query statement by using direct rule matching based on semantic graph, similarity retrieval based on vector semantics, and graph matching based on entity attribute path, and to extract structured query elements.

[0059] The fact table routing decision module is used to determine the set of candidate fact tables based on the granularity-fact table mapping graph, evaluate the expected query cost of each candidate fact table, and select the target fact table based on the multi-objective routing decision of granularity matching degree and query cost.

[0060] The query execution and result return module is used to convert structured query elements into structured query statements based on the target fact table and execute the query, as well as return the query result data to the front end.

[0061] It is understood that each module in this system corresponds to steps S1 to S7 and their progressive extension features in the method embodiments, possesses the function of executing the corresponding method steps, and can achieve the same or corresponding technical effects. Its specific functional principles and implementation details have been elaborated in the above method embodiments, and will not be repeated here to avoid repetition.

[0062] As an example, the semantic graph construction module typically runs on a computing server as a background batch processing task, periodically scanning data source metadata to update the graph. The hybrid parsing module, fact table routing decision module, and query execution and result return module can be deployed on the application server, working together as microservices to respond to natural language query requests from front-end users in real time.

[0063] Example 3: The present invention also provides an electronic device, including a memory and a processor. The memory stores a computer program, and the processor executes the program to implement a natural language index query method based on semantic graph and hybrid parsing.

[0064] Example 4: The present invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements a natural language index query method based on semantic graph and hybrid parsing.

[0065] Example 5: This example uses a group's financial data warehouse as the test environment to provide a complete verification process for a natural language indicator query method based on semantic graphs and hybrid parsing.

[0066] The system first extracts financial indicator definitions and time-aggregated granularity information from multi-source business databases to generate an indicator knowledge graph. Taking the "sales revenue" indicator entity as an example, time-granularity compatible relationship edges are added to it, and the two fact tables storing the indicator data in the underlying data warehouse—the daily sales details fact table and the monthly sales summary fact table—are associated with this indicator entity. The physical storage mapping information is recorded in Table 1.

[0067] Table 1: Physical storage mapping information of the fact table mapping graph

[0068] The semantic graph also contains time-level sequences, arranged from finest to coarsest granularity as: day, week, month, quarter, year. The distance between adjacent levels is 1, and the maximum level distance is... Choose 4.

[0069] Users input a natural language query through the front-end interface: "Query the company's total sales last month." The hybrid parsing module first uses a rule matcher based on a Trie prefix tree structure to match the indicator name and alias of "total sales." Simultaneously, it calls a vector retrieval engine to calculate semantic vector similarity and performs graph traversal matching based on the indicator entity attribute paths in the semantic graph. The candidate indicator set and confidence scores obtained from the three-way recall are shown in Table 2.

[0070] Table 2: Candidate Indicator Set and its Confidence Level

[0071] Among them, "sales revenue" has the highest overall confidence level and the difference between it and the second highest confidence level is significant. Therefore, without triggering human-computer interaction for clarification, the target indicator is directly locked as "sales revenue". The query time granularity is parsed as "month" and the time range is "last month" (assuming the current month is July 2025 and the previous month is June 2025), with no additional dimensional constraints.

[0072] The system traverses all fact table records associated with the target metric "sales" in the granularity-fact table mapping graph, obtaining `sales_daily` and `sales_monthly`. `sales_daily` has a native time granularity of "day," and can generate monthly data through a compatible upward aggregation path, thus being determined as having reachable time granularity. `sales_monthly` has a native time granularity of "month," precisely matching the query's time granularity. The query statement does not contain dimension constraints, and both fact tables satisfy the dimension drill-down requirement. The candidate fact table set and compatibility criteria are shown in Table 3.

[0073] Table 3: Candidate Fact Table Set and Compatibility Determination

[0074] For the candidate fact tables sales_daily and sales_monthly, the number of data rows to be scanned and the number of partitions to be accessed are estimated based on the physical storage mapping information, and the data refresh latency is obtained. The query time range is June 2025 (30 days). The values ​​and sources of each parameter are shown in Table 4.

[0075] Table 4: Parameters for Querying Candidate Fact Tables

[0076] According to the expression Calculate the estimated query cost: For sales_daily: ; For sales_monthly: ; First, calculate the granularity matching score for each candidate fact table. The query time granularity is "month" (level 3), while the native granularity of sales_daily is "day" (level 1), with a level distance of... ;sales_monthly has a native granularity of "month" (level 3), and a level distance of . ; ; ; Then calculate the routing decision score. .Pick (Maximum value in the candidate set), set the granularity matching weight. Query cost weight ; ; For sales_daily: ; For sales_monthly: ; The overall scoring results are shown in Table 5.

[0077] Table 5: Multi-objective routing decision scoring

[0078] The `sales_monthly` function received the highest routing decision score and was selected as the target fact table. Because its native time granularity of "month" precisely matches the query time granularity, no data source annotation information needs to be generated.

[0079] The system encapsulates the target metric "sales revenue" and the time range "June 2025" into an intermediate query language. This language is then compiled into SQL statements by a multidimensional query engine based on the physical storage model of `sales_monthly` and executed in the data warehouse to obtain the query results. Subsequently, the system determines the visualization intent, generates bar chart descriptions, and pushes the inference process data, query results data, chart descriptions, and data source annotations (marked as empty or "exact match") to the front-end interface in stages via the SSE streaming protocol.

[0080] As can be seen from the above experimental verification process, when faced with the coexistence of candidates for daily detailed fact tables and monthly summary fact tables, this method can automatically make the optimal routing decision based on the quantified query cost and granularity matching degree, ensuring query response speed while taking into account the accuracy of data granularity, and achieving an intelligent balance between query performance and analysis granularity.

[0081] The embodiments disclosed in this invention are preferred embodiments, but are not limited thereto. Those skilled in the art can easily understand the spirit of this invention based on the above embodiments and make different extensions and variations, but as long as they do not depart from the spirit of this invention, they are all within the protection scope of this invention.

Claims

1. A natural language index query method based on semantic graph and hybrid parsing, characterized in that, include: Obtain and parse the natural language query statement input by the user, and identify the target metrics and query time granularity; Based on a pre-built granularity-fact table mapping, a set of candidate fact tables corresponding to the target metric and the query time granularity is determined; Based on the storage type of each candidate fact table in the candidate fact table set, differentiated weights are assigned to the data scale cost and the timeliness cost, and the expected query cost of each candidate fact table is calculated. Calculate the granularity matching degree between the original time granularity of each candidate fact table and the query time granularity, and weight and combine the granularity matching degree with the expected query cost to obtain the routing decision score. Select the candidate fact table with the highest routing decision score as the target fact table. When the time granularity of the target fact table does not exactly match the query time granularity, data source annotation information indicating the alternative time granularity level is generated, and the query is executed based on the target fact table, returning query results containing the data source annotation information.

2. The natural language index query method based on semantic graph and hybrid parsing according to claim 1, characterized in that, The calculation of the expected query cost for each candidate fact table includes: Based on the physical storage mapping information recorded in the granularity-fact table mapping diagram, the number of data rows to be scanned and the number of partitions to be accessed are estimated, and the data refresh latency is obtained. The expected query cost is calculated using the following expression. : ； in, To estimate the number of rows of data that need to be scanned, This is an estimate of the maximum number of rows in all fact table records within the granularity-fact table mapping diagram. This represents the number of partitions that need to be accessed. This represents the maximum number of partitions involved in a single query in the granularity-fact table mapping graph. The data refresh delay time for the fact table. The preset maximum acceptable delay duration, The row count cost weight is assigned to the storage type. The partition cost weight corresponding to the storage type. The weight is the timeliness cost weight corresponding to the storage type, and the weight value is greater when the storage type is detailed level storage than when it is summary level storage.

3. The natural language index query method based on semantic graph and hybrid parsing according to claim 1, characterized in that, The calculation of the granularity matching degree between the native time granularity of each candidate fact table and the query time granularity, and the routing decision scoring, includes: The granularity matching degree is calculated according to the following expression. : ； in, To query the hierarchical distance between the time granularity and the native time granularity of the candidate fact table in the time hierarchy sequence defined by the semantic graph. This represents the maximum hierarchical distance of the time-level sequence. The routing decision score is calculated according to the following expression. : ； in, For the expected query cost, The maximum value of the query cost estimates in the current candidate fact table set. and These are the granularity matching weight and the query cost weight, respectively. .

4. The natural language index query method based on semantic graph and hybrid parsing according to claim 1, characterized in that, The process of constructing the granularity-fact table mapping includes: Obtain financial indicator definitions and time aggregation granularity information from multi-source business databases, and generate an indicator knowledge graph with indicator entities as nodes; In the indicator knowledge graph, time granularity compatibility edges are added to each indicator entity to represent the native time granularity and compatible time granularity paths supported by the indicator entity. Based on the physical storage model of the underlying data warehouse, each indicator entity is associated with a corresponding fact table at each compatible time granularity. The storage type, estimated number of data rows, partition coverage, and data refresh latency of the fact table are recorded in the physical storage mapping information to obtain the granularity-fact table mapping diagram.

5. The natural language index query method based on semantic graph and hybrid parsing according to claim 4, characterized in that, The process of determining a set of candidate fact tables corresponding to the target metric and the query time granularity based on a pre-built granularity-fact table mapping includes: In the granularity-fact table mapping diagram, all fact table records associated with the target indicator are traversed; Filter out fact tables whose supported time granularity exactly matches the query time granularity or are reachable via the time granularity compatibility edge; When the natural language query statement contains dimensional constraints, fact tables that do not meet the dimensional drill-down requirements are removed, and the remaining fact tables are included in the candidate fact table set.

6. The natural language index query method based on semantic graph and hybrid parsing according to claim 1, characterized in that, The process of acquiring and parsing the natural language query input by the user, identifying the target metrics and query time granularity, includes: The rule matcher based on the prefix tree structure is used to match the indicator names of the natural language query statement, the vector retrieval engine is called to calculate the semantic vector similarity, and graph traversal matching is performed based on the indicator entity attribute path in the granularity-fact table mapping graph to obtain the candidate indicator set. The candidate indicator set is sorted by confidence level. If the difference between the highest confidence result and the second highest confidence result meets the predetermined fuzzy conditions, a human-computer interaction clarification process is triggered to lock the target indicator. Otherwise, the highest confidence result is directly selected as the target indicator, and the time expression and dimensional constraints are parsed simultaneously.

7. The natural language index query method based on semantic graph and hybrid parsing according to claim 1, characterized in that, The returned query results, which include data source labeling information, include: After obtaining the query result data, the visualization intent is determined based on the data characteristics and dimensions of the query result data, and corresponding chart description information is generated; The inference process data, query result data, chart description information, and data source labeling information are pushed to the front-end interface in stages through a streaming protocol.

8. A natural language index query system based on semantic graph and hybrid parsing, characterized in that, include: The semantic graph construction module is used to construct a semantic graph containing indicator entity nodes and time-granularity compatible relationships, and to extend the physical storage mapping information of indicator entity nodes to form a granularity-fact table mapping graph. The hybrid parsing module is used to obtain the natural language query statement input by the user, and to identify the target indicators and query time granularity in the natural language query statement by using rule direct matching based on semantic graph, similarity retrieval based on vector semantics, and graph matching based on entity attribute path, and to extract structured query elements. The fact table routing decision module is used to determine the set of candidate fact tables based on the granularity-fact table mapping graph, evaluate the expected query cost of each candidate fact table, and select the target fact table based on the multi-objective routing decision of granularity matching degree and query cost. The query execution and result return module is used to convert structured query elements into structured query statements based on the target fact table and execute the query, as well as return the query result data to the front end.

9. An electronic device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the program to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 7.

Images