Query parameter generation method and device under AI intelligent number asking scene

By defining a JSON-formatted query parameter data structure in the AI ​​intelligent query system, and combining it with a large language model and indicator knowledge base, the system solves cross-database compatibility and intelligence issues, achieves efficient query parameter generation, and improves the system's versatility and maintainability.

CN121579644APending Publication Date: 2026-02-27杭州玳数科技有限公司
View PDF 0 Cites 1 Cited by

Patent Information

Application Number
CN202511772156.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-11-28
Publication Date
2026-02-27

AI Technical Summary

Technical Problem

Existing AI-powered data query systems struggle to achieve cross-database compatibility in multi-source, heterogeneous data environments, have limited intelligence, high maintenance costs, and are difficult to adapt quickly to business changes.

Method used

By defining a unified query parameter data structure in JSON format, rewriting user query statements using a large language model, and combining an indicator knowledge base and vector search, a standardized query parameter data structure is generated, decoupling SQL generation and supporting multi-database adaptation.

Benefits of technology

It improves the system's versatility and portability, enhances the accuracy of query intent recognition and system maintainability, and reduces operating costs.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121579644A_ABST
    Figure CN121579644A_ABST
Patent Text Reader

Abstract

The invention discloses a query parameter generation method and device in an AI intelligent question scene. The query parameter generation method comprises the steps of obtaining natural language-based query statement data input by a user; performing semantic understanding and standardized rewriting on the natural language query statement data input by the user to obtain a rewritten query statement; on the basis of the rewritten query statement, recalling and screening related index information from an index knowledge base; based on the rewritten query statement and the index information, analyzing query parameters, and generating a standardized query parameter data structure; and executing data query based on the query parameter data structure and outputting a result. The method has the advantages that by defining a unified query parameter data structure, decoupling with a database is achieved, and universality and portability are improved.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the field of query, in particular to a query parameter generation method and device in an AI intelligent query scenario. BACKGROUND

[0002] With the rapid development of artificial intelligence generated content (AIGC) technology, AI intelligent query (i.e., issuing queries to data systems through natural language) has become an important way for enterprise data analysis and decision support. In this scenario, users do not need to master complex query languages (such as SQL), but only need to input query intentions in natural language, and the system can automatically parse and return the required data results.

[0003] Currently, mainstream AI intelligent query systems usually adopt the following technical path: first, according to the natural language query statement input by the user, the table structure in the database is matched; then, a large language model (LLM) is used to directly convert the natural language into a structured query language (SQL), and finally the query is executed and the result is returned. This method reduces the user's threshold to a certain extent and improves the convenience of data query.

[0004] However, the existing technology still has significant deficiencies in practical application: Poor universality: due to the differences in SQL syntax, function support and query optimization of different database systems (such as MySQL, Oracle, ClickHouse, etc.), it is difficult for the SQL statements generated by the large model to be compatible across databases. In a multi-source heterogeneous data environment, the system often needs to customize different SQL generation logic for different data sources, resulting in high adaptation cost and poor portability.

[0005] Limited intelligence: the existing method relies on rules templates or models to directly infer related tables and fields in the semantic recognition stage, and lacks deep understanding of business semantics. Especially in complex query scenarios, the system is difficult to accurately associate user intentions with underlying data models, often resulting in situations where the query results do not match the user's real needs, such as misselecting indicators, missing dimensions, or inaccurate filtering conditions.

[0006] High maintenance cost: when business indicators or data models change, the existing system usually needs to readjust the SQL generation rules or model training data, resulting in a large amount of maintenance work. In addition, due to the close coupling of query logic and specific databases, the system's scalability is limited, making it difficult to quickly adapt to business changes. SUMMARY

[0007] The purpose of the present application is to solve the technical problems in the prior art and provide a query parameter generation method and device in an AI intelligent query scenario.

[0008] Technical solution: The application provides an AI intelligent question scene query parameter generation method, including: Obtain natural language-based query sentence data input by a user; Perform semantic understanding and standardized rewriting on the natural language query sentence data input by the user to obtain a rewritten query sentence; Based on the rewritten query sentence, recall and filter relevant index information from an index knowledge base; Based on the rewritten query sentence and the index information, parse the query parameters and generate a standardized query parameter data structure; Based on the query parameter data structure, perform data query and output results.

[0009] Preferably, the semantic understanding and standardized rewriting of the natural language query sentence data input by the user include: Configure large language model parameters; Write prompt words, define roles, tasks and output rules; Rewrite the query sentence using a large language model.

[0010] Preferably, based on the rewritten query sentence, recall and filter relevant index information from an index knowledge base, including: Write business index information into an index knowledge base; Based on the rewritten query sentence, use a full-text search and vector search hybrid method to recall TopN relevant indexes; Use a large language model to filter out index information related to the user's natural language query sentence from the recalled relevant indexes.

[0011] Preferably, the business index information includes index name, index description, and dimension information.

[0012] Preferably, based on the rewritten query sentence and the index information, the query parameters are parsed and a standardized query parameter data structure is generated, including: Use a natural language tool to parse the rewritten query sentence to obtain a time range; Write different instructions, use a large language model to parse the rewritten query sentence to obtain query dimensions, filtering conditions, data analysis scenarios and display methods; Summarize and generate a standardized query parameter data structure.

[0013] Preferably, the query parameter data structure is in JSON format and includes the following parts: Define the query target; Define the data analysis type; Define the data display method.

[0014] Preferably, the definition of the query target includes: List of metrics, list of dimensions, time range, and filter conditions; The filtering conditions include logical symbols and a list of conditional expressions.

[0015] Preferably, the defined data analysis type supports multiple analysis types, including at least one of point lookup, year-on-year and month-on-month comparison, and TopN analysis.

[0016] Preferably, the defined data display method includes at least one of tables, line charts, bar charts, and pie charts.

[0017] This application proposes a query parameter generation device for AI-powered intelligent query scenarios, comprising: The acquisition unit is used to acquire query data based on natural language input by the user; The rewriting unit is used to perform semantic understanding and normalization rewriting on the natural language query data input by the user to obtain the rewritten query statement; The filtering unit is used to retrieve and filter relevant indicator information from the indicator knowledge base based on the rewritten query statement; The parsing unit is used to parse the query parameters based on the rewritten query statement and the indicator information, and generate a standardized query parameter data structure. The output unit is used to perform data queries based on the query parameter data structure and output the results. Beneficial effects

[0018] By defining a unified query parameter data structure, decoupling from the database is achieved, improving versatility and portability. This method does not directly generate SQL; instead, it innovatively defines a standardized and extensible JSON data structure to carry query intents (such as metrics, dimensions, and filtering conditions). This intermediate layer structure allows the system backend to develop a unified "interpreter" for different databases (such as MySQL, ClickHouse, and Doris), converting JSON parameters into the specific database's SQL dialect. This fundamentally solves the problem of existing technologies struggling to adapt to multi-source heterogeneous databases due to differences in SQL syntax, greatly improving the system's versatility and portability.

[0019] By combining query rewriting with metric recall and filtering in a multi-stage process, the accuracy and intelligence of query intent recognition are significantly improved. First, the original user query is rewritten using an LLM-driven normalization mechanism. Then, a hybrid "vector search + full-text search" approach is used to recall and initially filter relevant metrics from a metric knowledge base. Finally, LLM is used again for final filtering. This process effectively overcomes the limitations of single rules or models in semantic understanding. The rewriting step corrects non-standard user input; the hybrid recall ensures broad retrieval coverage; and the LLM final filtering removes irrelevant metrics based on deep semantics, thereby accurately pinpointing the user's true intent.

[0020] A modular, step-by-step query parameter parsing strategy enhances the system's maintainability and robustness. Employing a divide-and-conquer approach, dedicated tools (such as JionLP) and specifically designed prompts are used to independently parse the time range, dimensions, filtering conditions, analysis types, and display methods. This modular design allows each parsing step to be independently optimized and updated. When new analysis types (such as period cluster analysis) or new filtering operators need to be supported, only the corresponding module's prompt or logic needs to be modified, without refactoring the entire SQL generation process. This reduces maintenance complexity and improves the system's scalability and agility in adapting to business changes.

[0021] By constructing a vectorized metric knowledge base as the sole source of fact, system maintenance costs are reduced. Business metrics and their metadata (name, description, dimensions) are stored in the vector knowledge base, serving as the benchmark for metric identification and retrieval throughout the system. When business metrics change or are added, administrators only need to update the knowledge base content on the metric platform; the system does not need to modify hard-coded rules or retrain models to adapt to these changes. This design achieves loose coupling between query logic and the underlying data model, making system maintenance simple and efficient, and significantly reducing operating costs in the long run. Attached Figure Description

[0022] Figure 1 A schematic diagram of the method framework for this invention is provided; Figure 2 A schematic diagram of the method flow framework for this invention is provided; Figure 3 This is a block diagram of a device structure provided in one embodiment of this application; Figure 4 This is a block diagram of an electronic device structure provided in one embodiment of this application. Detailed Implementation

[0023] To make the technical solution of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. Example

[0024] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions in the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention. Unless otherwise defined, the technical or scientific terms used herein should have the ordinary meaning understood by those skilled in the art. The terms "comprising" and similar expressions used herein mean that the element or object preceding the word covers the element or object listed following the word and its equivalents, but do not exclude other elements or objects.

[0025] In response to the problems existing in the current technology, such as Figure 1 As shown, a method for generating query parameters in AI-powered intelligent query scenarios is proposed, including: S1. Obtain query data based on natural language input from users. Receive the user's most raw, unprocessed query request. Users do not need to learn SQL or complex query tools. They can ask questions directly in everyday language, which greatly improves the ease of use and accessibility of data query. S2. The system performs semantic understanding and normalization on the user-input natural language query data to obtain a rewritten query statement. It leverages the general language understanding capabilities of a large language model to clean and standardize the original input, which may contain ambiguities, abbreviations, or grammatical errors. This allows it to handle non-standard input, making the system more accommodating to various user expression habits. Providing clean input for downstream tasks: A clearly structured and semantically clear rewritten statement significantly improves the accuracy of subsequent metric recall and parameter parsing, forming the foundation for a smooth process. S3. Based on the rewritten query, relevant indicator information is retrieved and filtered from the indicator knowledge base. The goal is to accurately associate the "business concepts" in the user's statement with the "standardized indicators" defined in the indicator knowledge base. Precisely locating the specific business indicator the user wants to query is the fundamental prerequisite for generating a correct query. Through vectorized retrieval, not only can synonyms or near-synonyms of keywords be matched, but the understanding capability is also stronger.

[0026] Using LLM for secondary screening can effectively eliminate noise in the search results, ensuring that subsequent steps are based on the most relevant and accurate indicator information, thus avoiding "answering the wrong question" from the source. S4. Based on the rewritten query statement and the indicator information, the query parameters are parsed, and a standardized query parameter data structure is generated. This structure assembles the results of the previous steps (clear intent, accurate indicators) into a structured execution plan containing complete query elements. It generates a neutral, standardized JSON structure, rather than SQL for a specific database. This allows the backend to develop adapters for different databases, greatly enhancing the system's versatility. This data structure not only includes the "indicators" to be queried but also specifies the "dimensions" (by which groups), "filter conditions" (where), "time range" (when), and "how to analyze and display" (TopN trend chart). This is a more business-oriented and comprehensive query blueprint than SQL.

[0027] The analysis dimensions, conditions, and analysis types can be performed in parallel or independently, making the system easy to maintain and expand.

[0028] S5. Perform a data query based on the query parameter data structure and output the results.

[0029] In some specific embodiments, semantic understanding and normalized rewriting of user-input natural language query data are performed, including: Configure large language model parameters; Specifically, in some instances, `temperature=0.7` is configured. This parameter controls the randomness of the generation: 0.7 is a balanced value that allows the model some creativity in rewriting sentences (such as synonym substitution and structural adjustment), ensuring that the output is both flexible and reliable. Configuring the API URL, key, and model name ensures the correctness and professionalism of service calls.

[0030] Write prompts, define roles, tasks, and output rules; Define roles: This allows the model to enter a specific scenario and invoke relevant professional capabilities from its knowledge base.

[0031] Define the task: Clearly state "to rewrite the natural language query input by the user in a standardized manner" and provide specific instructions, such as "correcting spelling errors", "completing omitted components", and "standardizing technical terms".

[0032] Define output rules such as "the original meaning must remain unchanged" and "the output should only contain the rewritten sentence, without adding any explanation." This is to prevent the model from generating redundant content that cannot be processed by downstream programs.

[0033] Rewrite the query statement using a large language model. This is the execution phase, which puts the configurations and designs of the previous two steps into practice. Leveraging the powerful generation ability of the large language model, a high-quality rewritten query statement is produced. The model comprehensively applies its language knowledge to perform operations such as: correcting typos ("sales amount" -> "sales volume"), completing the subject / object ("show me" -> "show the total number of users"), standardizing expressions ("the top five best-selling" -> "the top five products with the highest sales volume"), eliminating ambiguities (clarifying vague references), etc.

[0034] In some specific embodiments, based on the rewritten query statement, relevant metric information is recalled and filtered from the metric knowledge base, including: Write the business metric information into the metric knowledge base; Standardize, structure, and store the scattered business metrics to lay the foundation for intelligent retrieval. Convert these metadata (especially names and descriptions) into vector embeddings and store them in a vector database (such as Milvus, Pinecone, Elasticsearch, etc.) to form a metric vector knowledge base; Based on the rewritten query statement, recall the top N relevant metrics using a hybrid approach of full-text search and vector search; conduct a preliminary and broad-spectrum relevance retrieval to ensure no potentially relevant metrics are missed. This is the recall phase, aiming for a high recall rate. Vector search: Convert the rewritten query statement into a vector as well and then calculate the similarity in the metric vector knowledge base. It can discover semantic-level associations. For example, when the user queries "revenue", it can recall metrics named "operating income", "total revenue". Full-text search: Perform traditional keyword matching (such as the BM25 algorithm) on the metric name and description fields. It can accurately match the name. For example, when the user queries "sales volume", it can directly recall the metric named "sales volume".

[0035] Use a large language model to screen out the metric information related to the user's natural language query statement from the recalled relevant metrics. Based on the broad-spectrum recall, perform precise "intelligent screening". This is the "fine screening" phase, aiming for a high precision rate, and its goal is to eliminate the metrics irrelevant to the user's true intention from the mixed recall results.

[0036] In some specific embodiments, the business metric information includes metric names, metric descriptions, and dimension information.

[0037] The metric name serves as the unique identifier and primary search keyword for the metric. It is typically a concise, standard business term, such as "sales revenue," "user retention rate," or "order quantity." It is unique within the system and used to accurately identify specific business metrics. It is also a key matching field for full-text search: enabling quick and accurate location of the metric when a user's query highly matches its name. Furthermore, it is a crucial source of text for vectorization.

[0038] Metric descriptions, semantic extensions, and business context are crucial for intelligent retrieval. A detailed explanation of the metric's business definition, calculation methods, and statistical rules is provided. It includes rich information such as synonyms, relevant business scenarios, and precautions. The primary semantic source for vector search: the richness of the description determines the quality of the vector representation. It addresses the issue of differing expressions: a user might say "revenue," while the metric name is "operating income." If the description includes synonyms such as "revenue" or "turnover," a semantic connection can be established. It provides sufficient business context for LLM (Local Management Model) to determine relevance.

[0039] Dimension information defines the analytical perspective and filtering criteria for metrics. It describes how metrics can be segmented and filtered, such as "by city," "by product category," or "by time." It typically includes a mapping between dimension IDs and dimension names. It enhances query intent understanding: when a user's query contains dimension information (such as "sales revenue per city"), the system can match more accurately. It provides the metadata foundation for generating the `dims` and `where` conditions in query parameters. In vectorization, dimension information serves as important context, improving retrieval accuracy.

[0040] In some specific embodiments, based on the rewritten query statement and the indicator information, query parameters are parsed and a standardized query parameter data structure is generated, including: The time range is obtained by parsing the rewritten query using natural language processing tools; its purpose is to extract time elements with high precision and reliability. The time range is the most structured parameter in the query, and its parsing requires absolute accuracy.

[0041] Specialized tools (such as JionLP and SUTime) use rule-based and pattern matching to provide consistent and deterministic parsing results for expressions like "last week," "Q3," and "last 30 days," accurately outputting standard formats such as {"start": "2024-06-10", "end": "2024-06-16"}. Compared to calling large models, these specialized tools, as lightweight libraries, offer faster response times and lower computational costs. They also prevent inconsistencies that may occur when parsing dates in large models.

[0042] Write different instructions and use a large language model to parse the rewritten query statement to obtain query dimensions, filtering conditions, data analysis scenarios and display methods; Analyze query dimensions: Identify what users want to "click" from the query and perform grouping analysis.

[0043] Example: Input "Sales revenue per city", output "City"; Input "Statistics by product category and channel", output "Product category" and "Channel".

[0044] Parse filter conditions: Identify all filter conditions, including dimension fields, operators, and values.

[0045] Example: Input "goods priced above 100 yuan in Beijing", output "city equal to Beijing" and "price greater than 100".

[0046] Analyze the data analysis scenario: Determine the type of analysis the user wishes to perform.

[0047] Example: Input "the five products with the highest sales", output "top N analysis"; input "monthly trend of user numbers", output "trend analysis".

[0048] Analysis of display methods: Determine the most suitable type of visualization chart.

[0049] Example: Input "Sales revenue over time", output "line chart"; input "percentage of each category", output "pie chart".

[0050] The data structure of the query parameters is summarized and generated.

[0051] In some specific embodiments, the query parameter data structure is in JSON format and includes the following parts: Define the query target; Define the data analysis type; Define the data display method.

[0052] In some specific embodiments, the definition of the query target includes: List of metrics, list of dimensions, time range, and filter conditions; Metric Information List: This list identifies the core business metrics being queried, including the metric's ID and name, ensuring an exact correspondence with the definitions in the metric knowledge base.

[0053] Dimension list: Defines the perspective from which the data is analyzed and observed, determines how the data is grouped and segmented, and includes dimension IDs and names.

[0054] Time range: Defines the time window for querying data and is a fundamental condition for most analyses. Standardized start and end times. Filtering conditions: Data is finely filtered using logical symbols (such as "AND" and "OR") and specific conditional expressions to ensure the accuracy of the result set.

[0055] The filtering conditions include logical symbols and a list of conditional expressions.

[0056] In some specific embodiments, the defined data analysis type supports multiple analysis types, including at least one of point lookup, year-on-year and month-on-month comparison, and TopN analysis.

[0057] Point-to-point query: The most basic query type, which directly retrieves the indicator value under specified conditions.

[0058] Year-on-year / month-on-month: Used to calculate the growth rate compared to the same period last year or the previous period, reflecting business trends.

[0059] TopN analysis: Obtaining the top N or bottom N data points, often used to focus on core issues or discover long tails.

[0060] In some specific embodiments, the defined data display method includes at least one of tables, line charts, bar charts, and pie charts.

[0061] Tables: Suitable for scenarios where precise values ​​need to be viewed and multi-dimensional comparisons need to be made.

[0062] Line chart: Best suited for showing the trend of data changing over time.

[0063] Bar charts are commonly used to compare the numerical values ​​between different categories.

[0064] Pie chart: Used to show the proportion of each part to the whole.

[0065] In other embodiments of the invention, combined with Figure 3 This invention discloses a query parameter generation device for AI-powered intelligent query scenarios, comprising: The acquisition unit 201 is used to acquire query statement data based on natural language input by the user; The rewriting unit 202 is used to perform semantic understanding and normalization rewriting on the natural language query data input by the user to obtain the rewritten query statement; The filtering unit 203 is used to retrieve and filter relevant indicator information from the indicator knowledge base based on the rewritten query statement; The parsing unit 204 is used to parse the query parameters based on the rewritten query statement and the indicator information, and generate a standardized query parameter data structure. Output unit 205 is used to perform data query based on the query parameter data structure and output the result.

[0066] In other embodiments of the present invention, an electronic device 400 is disclosed, such as... Figure 4As shown, the electronic device may include: one or more processors 401; a memory 402; a display 403; one or more application programs (not shown); and one or more computer programs 404. These devices can be connected via one or more communication buses 405. The one or more computer programs 404 are stored in the memory 402 and configured to be executed by the one or more processors 401. The one or more computer programs 404 include instructions that can be used to perform actions such as... Figure 1 And the steps in the corresponding embodiments.

[0067] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0068] In the various embodiments of the present invention, the functional units can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0069] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as flash memory, portable hard disk, read-only memory, random access memory, magnetic disk, or optical disk.

[0070] The above description is merely a specific implementation of the embodiments of the present invention, but the protection scope of the embodiments of the present invention is not limited thereto. Any changes or substitutions within the technical scope disclosed in the embodiments of the present invention should be covered within the protection scope of the embodiments of the present invention. Therefore, the protection scope of the embodiments of the present invention should be determined by the protection scope of the claims.

Claims

1. A method for generating query parameters in an AI-powered intelligent query scenario, characterized in that, include: Obtain query data based on natural language input from the user; The user-input natural language query data is semantically understood and normalized to obtain the rewritten query statement; Based on the rewritten query statement, relevant indicator information is retrieved and filtered from the indicator knowledge base; Based on the rewritten query statement and the indicator information, the query parameters are parsed out and a standardized query parameter data structure is generated. The data query is performed based on the query parameter data structure, and the results are output.

2. The method for generating query parameters in an AI-powered intelligent query scenario according to claim 1, characterized in that, Semantic understanding and normalization rewriting of user-input natural language query data, including: Configure large language model parameters; Write prompts, define roles, tasks, and output rules; Rewrite the query statement using a large language model.

3. The method for generating query parameters in an AI-powered intelligent query scenario according to claim 1, characterized in that, Based on the rewritten query, relevant indicator information is retrieved and filtered from the indicator knowledge base, including: Write business indicator information into the indicator knowledge base; Based on the rewritten query, a hybrid approach of full-text search and vector search was used to retrieve the Top N relevant metrics. Large language models are used to filter relevant recall metrics to identify those related to users' natural language queries.

4. The method for generating query parameters in an AI-powered intelligent query scenario according to claim 3, characterized in that, The business indicator information includes indicator name, indicator description, and dimension information.

5. The method for generating query parameters in an AI-powered intelligent query scenario according to claim 1, characterized in that, Based on the rewritten query statement and the indicator information, the query parameters are parsed, and a standardized query parameter data structure is generated, including: The time range is obtained by parsing the rewritten query using natural language processing tools. Write different instructions and use a large language model to parse the rewritten query statement to obtain query dimensions, filtering conditions, data analysis scenarios and display methods; The data structure of the query parameters is summarized and generated.

6. The method for generating query parameters in an AI-powered intelligent query scenario according to claim 1, characterized in that, The query parameter data structure is in JSON format and includes the following parts: Define the query target; Define the data analysis type; Define the data display method.

7. The method for generating query parameters in an AI-powered intelligent query scenario according to claim 6, characterized in that, The definition of the query target includes: List of metrics, list of dimensions, time range, and filter conditions; The filtering conditions include logical symbols and a list of conditional expressions.

8. The method for generating query parameters in an AI-powered intelligent query scenario according to claim 6, characterized in that, The defined data analysis type supports multiple analysis types, including at least one of point lookup, year-on-year and month-on-month comparison, and TopN analysis.

9. The method for generating query parameters in an AI-powered intelligent query scenario according to claim 6, characterized in that, The defined data display methods include at least one of tables, line charts, bar charts, and pie charts.

10. A device for generating query parameters in an AI-powered intelligent query scenario, characterized in that, include: The acquisition unit is used to acquire query data based on natural language input by the user; The rewriting unit is used to perform semantic understanding and normalization rewriting on the natural language query data input by the user to obtain the rewritten query statement; The filtering unit is used to retrieve and filter relevant indicator information from the indicator knowledge base based on the rewritten query statement; The parsing unit is used to parse the query parameters based on the rewritten query statement and the indicator information, and generate a standardized query parameter data structure. The output unit is used to perform data queries based on the query parameter data structure and output the results.

Citation Information

Cited By

  • Method, device and equipment for converting natural language into data service calling instruction

    CN122019688A