LLM-based query semantic caching method for access scene, electronic equipment and medium
By constructing a query semantic cache and utilizing historical query vectors and domain-specific languages, the problems of prolonged response time and high resource consumption in enterprise data queries were solved, achieving efficient and accurate data queries and reducing the number of calls to the large language model and operating costs.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- ZHEJIANG UNIV
- Filing Date
- 2026-01-14
- Publication Date
- 2026-04-21
AI Technical Summary
Existing technologies suffer from problems such as prolonged response time, error propagation risk, and high resource consumption in enterprise data queries. In particular, when using large language models for multi-step queries, they are difficult to meet the needs of real-time interaction and have high operating costs.
By constructing a query semantic cache, utilizing historical query vectors and domain-specific language, the system retrieves information from the cache based on the current user's query vector, generates prompt words, and outputs the final domain-specific language through a large language model, thereby reducing repeated calls to the large language model.
It reduced response time, improved query accuracy, reduced the number of requests to large language models, and lowered operating costs.
Smart Images
Figure CN121901273A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of data query technology, and particularly relates to a query semantic caching method, electronic device, and medium based on LLM for data retrieval scenarios. Background Technology
[0002] As enterprises deepen their digital transformation, data analytics is playing an increasingly prominent role in business decision-making. To lower the barrier to data acquisition and enable non-technical personnel to easily extract valuable information from massive amounts of data, Natural Language Interface to Database (NLIDB) is gradually becoming a core function of intelligent business intelligence (BI) systems.
[0003] In enterprise-level data query tasks, the core objective is to transform user-input natural language questions into executable query logic, thereby obtaining query results or corresponding visualizations. Because enterprise data is typically highly complex, and business requirements for the verifiability of intermediate results and the consistency of final semantics are stringent, existing technologies typically do not directly output the final data from the model. Instead, they choose to generate a Domain-Specific Language (DSL) as an intermediate representation, which is then mapped to the final query results or visualizations via a post-processing engine.
[0004] Currently, with the rapid development of Large Language Models (LLMs), using LLMs for text-to-DSL (Text-to-DSL) conversion has become the mainstream solution. To handle complex business logic and improve generation accuracy, existing enterprise data query tasks based on LLMs typically employ a step-by-step processing strategy, breaking down the entire DSL generation process into multiple sub-stages, usually including: problem decomposition, table selection, dimension parsing, measure parsing, and filter parsing. In these sub-stages, the system typically needs to call the large language model multiple times, gradually constructing the complete DSL through multi-round interactions or chained calls.
[0005] However, the existing technical solutions based on multi-step LLM calls have the following significant problems in practical applications: 1. Long response latency: Since each sub-step (such as table selection, parsing dimension, parsing metric, etc.) involves inference calls of the large language model, and subsequent steps often depend on the output of the preceding steps, this serial or multiple call method results in a long total time for generating the final DSL, which is difficult to meet the user's demand for real-time interactive experience.
[0006] 2. Error propagation risk: In a multi-stage pipeline process, if an error occurs in a preceding stage (such as incorrect data table selection or problem decomposition deviation), the error will be propagated and amplified to subsequent dimension and metric parsing, causing the final generated DSL semantics to deviate completely from the user's intent, resulting in poor system robustness.
[0007] 3. High resource consumption: Each query requires a complete LLM inference of the entire process, resulting in huge token consumption and high operating costs.
[0008] Therefore, how to effectively utilize historical query experience, reduce repeated calls to large language models, and ensure the accuracy of query semantics while reducing latency and cost is a technical problem that current intelligent query technology for data retrieval scenarios urgently needs to solve. Summary of the Invention
[0009] To address the shortcomings of existing technologies, embodiments of the present invention provide a query semantic caching method, electronic device, and medium based on LLM for data retrieval scenarios.
[0010] In a first aspect, embodiments of the present invention provide a query semantic caching method based on LLM for data retrieval scenarios, the method comprising the following steps: Retrieve the full historical query data and its corresponding domain-specific language; Convert all historical queries into historical query vectors; filter the historical query vectors and build a query semantic cache based on the filtered historical query vectors and their corresponding domain-specific languages; Obtain the current user query and convert it into a current user query vector; The current user query vector is used to search the query semantic cache. If the current user query vector hits the query semantic cache, then prompt words are constructed based on the matched historical query vector and its corresponding domain-specific language. In response to prompts, the large language model outputs the final domain-specific language.
[0011] In a second aspect, embodiments of the present invention provide an electronic device, comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores one or more computer programs that can be executed by the at least one processor, and the one or more computer programs are executed by the at least one processor to enable the at least one processor to execute the above-described query semantic caching method based on LLM for data retrieval scenarios.
[0012] Thirdly, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described query semantic caching method based on LLM for data retrieval scenarios.
[0013] Fourthly, embodiments of the present invention provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements the above-described query semantic caching method based on LLM for data retrieval scenarios.
[0014] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention provides a query semantic caching method based on LLM for data retrieval scenarios. By constructing a query semantic cache, the method retrieves data based on the current user's query vector within the cache. If the current user's query vector matches the query semantic cache, it constructs prompt words based on the matched historical query vectors and their corresponding domain-specific languages. The final domain-specific language is then output through a large language model. This invention uses similar historical semantic queries and their corresponding domain-specific languages as references, generating domain-specific language results with only one large language model request. Compared to traditional enterprise scenarios, this avoids multiple large language model requests, reducing response time while improving the final query accuracy. Attached Figure Description
[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0016] Figure 1 This is a flowchart illustrating the query semantic caching method based on LLM for data retrieval scenarios provided in this embodiment of the invention. Figure 2 A block diagram of an LLM-based query semantic caching method for data retrieval scenarios provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation
[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0018] It should be noted that, unless otherwise specified, the features in the following embodiments and implementation methods can be combined with each other.
[0019] like Figure 1 and Figure 2 As shown, this embodiment of the invention provides a query semantic caching method based on LLM for data retrieval scenarios. The method includes the following steps: Step S1: Obtain the full set of historical queries and their corresponding Domain-Specific Languages (DSLs).
[0020] Step S2: Convert all historical queries into historical query vectors; filter the historical query vectors and construct a query semantic cache based on the filtered historical query vectors and their corresponding domain-specific languages.
[0021] Furthermore, the process of converting the entire set of historical queries into historical query vectors includes: Perform entity recognition on non-key query structures in historical queries; Remove identified non-critical query structure entities from historical queries; The historical queries after removing non-critical query structure entities are vectorized to obtain the corresponding historical query vectors.
[0022] Furthermore, the process of filtering historical query vectors and constructing a query semantic cache based on the filtered historical query vectors and their corresponding domain-specific languages includes: Clustering is performed on the entire historical query vector; in this example, K-means clustering is used. Historical query vectors are filtered according to graph theory rules, which are based on the intra-cluster connectivity of historical query vectors to select the historical query vectors that are most associated with the historical query vectors within the same cluster. Specifically, this includes: constructing a connected graph in the class, calculating the connectivity of each historical query vector with other historical query vectors, and selecting the top K historical query vectors with the highest connectivity as the representative historical query vectors in that class. A query semantic cache is constructed based on the filtered historical query vectors and their corresponding domain-specific languages.
[0023] Step S3: Obtain the current user query and convert the current user query into a current user query vector.
[0024] Specifically, entity recognition of non-key query structures is performed on the current user query; Remove the identified non-critical query structure entities from the current user query; The current user query, after removing non-critical query structure entities, is vectorized to obtain the corresponding current user query vector.
[0025] Step S4: Retrieve from the query semantic cache based on the current user query vector. If the current user query vector hits the query semantic cache, construct prompt words based on the matched historical query vector and its corresponding domain-specific language.
[0026] Specifically, the process of retrieving data from the query semantic cache based on the current user query vector and determining whether the current user query vector hits the query semantic cache includes: Calculate the similarity between the current user query vector and each historical query vector in the query semantic cache; The historical query vector with the highest similarity is selected as the best matching query vector; Determine whether the similarity corresponding to the best matching query vector is greater than a preset similarity threshold; if so, determine that the current user query vector hits the query semantic cache.
[0027] In step S5, in response to the prompt word, the large language model outputs the final domain-specific language.
[0028] For example, the prompt word can be set as follows: "In the previous stage, you generated several DSL configurations for data querying based on the user's query. Now, you need to rewrite the DSL configuration corresponding to the current query based on the current user's query and the DSL configurations corresponding to similar queries." "In addition, this step will provide table rules that need to be supplemented with indicator rules based on the `table rules`:", "## Knowledge of Indicator Rule Configuration", "The following is the configuration information for your indicator rules. You will need to refer to this information in the subsequent rule configuration process." 1. Field data types: Date, DateTime, String, Integer, Floating-point, Boolean. 2. Field Roles: Dimensions, Metrics. "Dimensions contain quantitative values (such as names, dates, or geographic data). Dimensions can be used to categorize, segment, and reveal detailed information within data. Dimensions affect the level of detail in a view." "Metrics contain measurable quantitative values and have a defined aggregation state. Dimension fields can also be aggregated using methods such as count, deduplication count, maximum value, and minimum value to form metrics. For example, the number of users can be the deduplication count of usernames." 3. Indicator aggregation status: Aggregated, Not aggregated. "Already aggregated: The indicator fields have already been aggregated and do not need to be aggregated again." "Not Aggregated: The metric field is not aggregated, and the aggregation method needs to be determined. The aggregation method is one of the following: sum, count, deduplicated count, average, maximum, or minimum. Different data types of fields can use different aggregation methods, specifically:", a. Integers and floating-point numbers: summation, counting, deduplication, average, maximum, minimum. "b. Strings, Dates, Date and Time: Count, Deduplication Count, Maximum Value, Minimum Value", 4. Advanced Calculation - Year-on-Year and Month-on-Month Comparison: Year-on-year and month-on-month comparisons calculate the data comparison between different time intervals. It is necessary to determine the year-on-year and month-on-month comparison type, the type of comparison result, and the time dimension used. Choose one of the following types for year-on-year and month-on-month comparisons: a. Month-on-Month Comparison: Comparing the current period's data with the previous period's data. The current period and the previous period are adjacent time periods, such as today's data and yesterday's data, this week's data and last week's data, or the data from the last 3 days and the last 6 to 4 days. "b. Month-on-Month Comparison: Comparing this period's data with the period two weeks ago, for example, comparing this week's Tuesday with the Tuesday of the week before last." c. Year-on-year comparison: This week's data compared to the same period last week, for example, Tuesday's data this week compared to Tuesday's data last week. d. Year-on-year comparison: Comparing the current period's data with the same period last month, for example, comparing the data for the 3rd of this month with the data for the 3rd of last month, or comparing the data for the 10th-20th of this month with the data for the 10th-20th of last month. "e. Year-on-year comparison: Comparing the current period's data with the data from the same period last year, for example, comparing the data from September 3rd of this year with the data from September 3rd of last year, or comparing the data from October of this year with the data from October of last year." Choose one of the following types of comparison results: a. Change: The change in data from the current period compared to the previous period. b. Rate of change: The percentage change in data from the previous period compared to the current period's data. c. Comparison value: The data value compared to the previous period. 5. Advanced Calculation - TopN: Divided into TopN and BottomN, requiring the value of N to be determined. TopN calculation only applies to one metric. a. TopN: Calculates the top N items according to the current sorting rule. "b. BottomN: Calculate the last N items according to the current sorting rule", 6. Advanced Calculation - Percentage: Calculates the percentage of data for an indicator within its corresponding dimension category. Percentage only applies to one indicator. Prioritize using existing dimension percentage fields; if no percentage field exists, use advanced calculation percentage. 7. Advanced Calculation - Daily Average: Requires specifying the date field. Output format: { 'Field Name': 'Indicator Field Name', 'Daily Average': 'Date Field'} 8. Sorting Rules: The sorting rules for indicator fields include ascending order, descending order, and no sorting. "## Dimension Rule Generation", "1. Based on the dimension items in the **dimensional configuration** and the dimension-related parts in the **table rules**, find the most matching field from the candidate fields (multiple fields can be matched; please refer to business knowledge and field metadata). If it is a set of dimensions in business knowledge, these fields need to be used as dimension fields simultaneously. If it is a date field, the date granularity needs to be determined." ## Configuration knowledge of filtering rules "The following is the configuration information for your filtering rules. You will need to refer to this information in the subsequent rule configuration process." **Field data types: Date, Date & Time, String, Integer, Floating-point, with corresponding matching types** "### 'String' type field", "The 'string' type field has two matching types: exact match and fuzzy match." "Exact match: This means that the condition value is matched exactly. An exact match occurs if and only if the expression 'equals', '=', or 'is' corresponds to the condition value." "Fuzzy matching: This refers to the fuzzy matching condition value. It is used only if the following expressions are used: 'related', 'about', 'related', 'similar', 'contains', 'includes', 'series', 'involves', etc. The default value is 'case-insensitive and space-insensitive'." "### 'Date' and 'Datetime' type fields", "For fields of type 'date' and 'datetime', the matching types are 'relative time' and 'absolute time'." "Relative Time: A description of the time period relative to a specific time anchor point:", "- Single Day Type: Enumerated values include today, yesterday, the day before yesterday, and the latest data date", "- Recent n days type: The standard form is 'Recent X days', where X is a positive integer. Similarly, the most recent x days / the previous x days are all normalized to 'Recent x days', and the last three days -> the last 3 days". - Periodicity type: Enumerated values include this week, last week, this month, last month, this quarter, last quarter, this double month, last double month. "- If the user query does not mention any time-related information, the default selection is the single-day type in the relative time: yesterday." "Absolute Time: A specific start and end time range, containing at least one start and end time. Date and time descriptions need to be converted to a standard format during processing. If no year is specified, there are two categories: 1. If the month has already occurred, the default is the current year; 2. If the month has not yet occurred, the default is the year before the current year. For example: Today is April 7, 2025. If a user queries for data from November 1st to November 20th, the query will return data from November 1st to November 20th, 2024; if a user queries for data from January 1st to March 20th, the query will return data from January 1st to March 20th, 2025." "- 'October-November 2024': ['2024-10-01', '2024-11-30']", "- 'May to October': ['2024-05-01', '2024-10-31']", "- 'Third Quarter of 2024': ['2024-07-01', '2024-09-30']", "- 'October 1, 2024 - Present': ['2024-10-01','2025-08-24']", "- 'x days ago': [null, '2024-11-20']", "### 'Integer', 'Floating-point' type fields", "Fields with integer or floating-point types can match conditions including `equal to`, `not equal to`, `greater than`, `greater than or equal to`, `less than`, `less than or equal to`, `within range`, and `not empty`. For conditions within a range, two values are required. "The following is the historical DSL configuration you generated:\n", User query: {_query}\nDSL configuration: {_dsl}\n" User query: {_query}\nDSL configuration: {_dsl}\n" Here is the new user query that you need to rewrite:\n f"User query: {query}\n", "Given the DSL configuration, query, and table data mappings, please generate a usable DSL configuration for the current user's query based on the mapping relationships in the generated historical DSL configurations. Do not generate configuration items that do not exist in the historical DSL configurations. The generated configuration should be in JSON format, completely consistent with the historical DSL configurations. Your answer should not include any additional information besides the configuration format." In summary, this invention provides a query semantic caching method based on LLM for data retrieval scenarios. By constructing a query semantic cache, the method retrieves results based on the current user's query vector within the cache. If the current user's query vector matches the query semantic cache, it constructs prompt words based on the matched historical query vectors and their corresponding domain-specific languages. The final domain-specific language is then output through a large language model. This invention generates domain-specific language results with only one large language model request, based on similar historical semantic queries and their corresponding domain-specific languages as references. Compared to traditional enterprise scenarios, this avoids multiple large language model requests, reducing response time while improving the final query accuracy.
[0029] Furthermore, the method also includes: If the current user query vector does not hit the query semantic cache, a domain-specific language is generated for the current user query vector using the large language model, specifically including: The current user query vector is parsed using a large language model, and the pre-generated results of the Measure, Dimension, and Filter are obtained. The parsing result of the current user query vector is input into the large language model to select a table, and the table information that matches the current user query vector is obtained. In response to table information, metric pre-generated results, dimension pre-generated results, filter pre-generated results, metric configuration rules, dimension configuration rules, and filter configuration rules, the large language model outputs metric configuration, dimension configuration, and filter configuration. Alternatively, in response to table information, metric pre-generation results, and metric configuration rules, the large language model outputs metric configurations; in response to table information, dimension pre-generation results, and dimension configuration rules, the large language model outputs dimension configurations; in response to table information, filter pre-generation results, and filter configuration rules, the large language model outputs filter configurations. The metric configuration, dimension configuration, and filter configuration constitute the domain-specific language corresponding to the current user's query vector.
[0030] It should be noted that a metric is a dynamically calculated result obtained by performing aggregation operations (such as summation or counting) or arithmetic operations on one or more fields; a dimension is an attribute field used to group, slice, or subdivide data; and a filter is a constraint condition that limits the range of data by filtering data rows. This filtering operation can be applied before or after aggregation calculation.
[0031] For example, table information, pre-generated dimension results, and dimension configuration rules are filled into the prompt word template, and the large language model outputs the dimension configuration according to the prompt word template; wherein, the prompt word template is set as follows: # Role You are a professional BI tool configuration expert, skilled in configuring BI tool dimension rules.
[0032] In the preceding steps, the AI has already extracted the dimensions from the query. You need to configure the dimension rules based on this 'dimensional configuration' information. Additionally, this step will provide table rules, which you will need to supplement with dimension rules. # Workflow ## Dimension Rule Generation 1. Based on the dimension items in the **dimensional configuration** and the dimension-related parts in the `table rules`, find the most matching field from the candidate fields (multiple fields can be matched; please refer to business knowledge and field metadata). If it is a set of dimensions in business knowledge, these fields need to be used as dimension fields simultaneously. If it is a date field, the date granularity needs to be determined. ## Output Requirements ### Output Requirements The output content must meet the following requirements 1. Output Validation: a. Strictly adhere to dimension value configuration and table rules; do not make your own inferences. b. Dimension fields must not contain fields not in the candidate field list. c. Date dimensions must include 'time granularity'. 2. The "Field Name" in the output dimension list must strictly use the "Field Name" from the "Candidate Fields" list. 3. The output includes each dimension and its configuration information. Only the dimension content is output. If there is no dimension, it can be empty.
[0033] #### Output JSON format ## Output Example #### Example 1 (Example of date as a dimension) **User query:** Searching for monthly search volume for "probiotics for pregnant women" and "probiotics during pregnancy" from January to October 2024. **Dimension Configuration**: {"Dimension": ["Search Term","Date-Month"]} "Sort": [Date - Ascending] (Non-dimensional fields ignored) Candidate fields: [ {"Field Name": "Search Term", "Field Alias": "Search Term (Case-sensitive and Space-sensitive)", "Data Type": "String", "Role": "Dimension"}, {"Field Name": "Community First-Level Category", "Field Alias": "Community First-Level Category, (Old) Notes First-Level Category, (Old) Notes First-Level Category Name, Notes First-Level Category, Keyword First-Level Category", "Data Type": "String", "Role": "Dimension",} {"Field Name": "Community Second-Level Category", "Field Alias": "Community Second-Level Category, (Old) Notes Second-Level Category, (Old) Notes Second-Level Category Name, Notes Second-Level Classification", "Data Type": "String", "Role": "Dimension",}, {"Field Name": "Community Level 3 Category", "Field Alias": "Community Level 3 Category, (Old) Notes Level 3 Category, (Old) Notes Level 3 Category Name, Notes Level 3 Classification", "Data Type": "String", "Role": "Dimension",} {"Field Name": "Brand Name", "Field Alias": "Brand Name", "Data Type": "String", "Role": "Dimension",}, {"Field Name": "Brand ID -- String Filter", "Data Type": "Array", "Role": "Dimension",}, {"Field Name": "Time", "Data Type": "Date", "Role": "Dimension", "Partitioned": "Yes", "Business Date": "Yes",}, {"Field Name": "Anonymous Community Search Volume", "Field Alias": "Search Volume - Anonymous, Search Volume (PV) - Anonymous", "Data Type": "Floating-point Number", "Role": "Indicator",}, {"Field Name": "Number of Anonymous Community Search Users", "Field Alias": "Search Index (UV) - Anonymous, Search Index - Anonymous", "Data Type": "Floating-point Number", "Role": "Indicator",}, {"Field Name": "Anonymous Search Volume for Community Keywords (without trending terms)", "Field Alias": "Anonymous Search Volume for Keywords (without trending terms)", "Data Type": "Floating-point Number", "Role": "Indicator"} ] Dimensional and dimension value knowledge: - Brand Name: Everyday Probiotics, Pregnant Women's Formula - Community secondary category: Maternity outfits - Community Primary Category: Maternal and Infant Products Business knowledge (used only if related to the current user's query): The table rules (those related to the current user's query) are as follows: - Unless otherwise specified in the user query, dates mentioned in the user query are filtered using `time` by default. - When processing filter criteria, a 'time' condition must be added. **Output**: { "Dimension List": [ { "Field Name": "Search Term"}, { "Field Name": "Time", "Time Granularity": "Month", "Sort": "Ascending"}} According to embodiments of the present invention, the present invention also provides an electronic device and a readable storage medium.
[0034] Figure 3 A schematic block diagram of an electronic device that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.
[0035] The electronic device includes a computing unit 101, which can perform various appropriate actions and processes according to a computer program stored in ROM 102 or a computer program loaded into RAM 103 from storage unit 108. RAM 103 may also store various programs and data required for the operation of the electronic device. The computing unit 101, ROM 102, and RAM 103 are interconnected via bus 104. I / O interface 105 is also connected to bus 104.
[0036] Multiple components in the electronic device are connected to the I / O interface 105, including: an input unit 106, such as a keyboard, mouse, etc.; an output unit 107, such as various types of displays, speakers, etc.; a storage unit 108, such as a disk, optical disk, etc.; and a communication unit 109, such as a network card, modem, wireless transceiver, etc. The communication unit 109 allows the electronic device to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.
[0037] The computing unit 101 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 101 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 101 performs the various methods and processes described above. For example, in some embodiments, the methods in the multidimensional early warning system for pressure injuries can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 108. In some embodiments, part or all of the computer program can be loaded and / or installed on an electronic device via ROM 102 and / or communication unit 109. When the computer program is loaded into RAM 103 and executed by the computing unit 101, one or more steps of the methods in the multidimensional early warning system for pressure injuries described above can be performed. Alternatively, in other embodiments, the computing unit 101 can be configured to perform the methods in the multidimensional early warning system for pressure injuries by any other suitable means (e.g., by means of firmware).
[0038] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.
[0039] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.
[0040] In the context of this invention, a readable storage medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A readable storage medium can be a machine-readable signal medium or a machine-readable storage medium. A readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0041] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including voice input, speech input, or tactile input).
[0042] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.
[0043] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.
[0044] The above embodiments are only used to illustrate the design concept and features of the present invention, and their purpose is to enable those skilled in the art to understand the content of the present invention and implement it accordingly. The protection scope of the present invention is not limited to the above embodiments. Therefore, all equivalent changes or modifications made based on the principles and design ideas disclosed in the present invention are within the protection scope of the present invention.
Claims
1. A query semantic caching method based on LLM for data retrieval scenarios, characterized in that, The method includes the following steps: Retrieve the full historical query data and its corresponding domain-specific language; Convert all historical queries into historical query vectors; filter the historical query vectors and build a query semantic cache based on the filtered historical query vectors and their corresponding domain-specific languages; Obtain the current user query and convert it into a current user query vector; The current user query vector is used to search the query semantic cache. If the current user query vector hits the query semantic cache, then prompt words are constructed based on the matched historical query vector and its corresponding domain-specific language. In response to prompts, the large language model outputs the final domain-specific language.
2. The query semantic caching method based on LLM for data retrieval scenarios according to claim 1, characterized in that, The process of filtering historical query vectors and constructing a query semantic cache based on the filtered historical query vectors and their corresponding domain-specific languages includes: Cluster the entire set of historical query vectors; Historical query vectors are filtered according to graph theory rules, which are based on the intra-cluster connectivity of historical query vectors to select the historical query vectors that are most associated with the historical query vectors within the same cluster. A query semantic cache is constructed based on the filtered historical query vectors and their corresponding domain-specific languages.
3. A query semantic caching method based on LLM for data retrieval scenarios according to claim 1 or 2, characterized in that, The process of filtering historical query vectors and constructing a query semantic cache based on the filtered historical query vectors and their corresponding domain-specific languages also includes: Cluster the entire set of historical query vectors; Construct a connected graph within the class, calculate the connectivity between each historical query vector and other historical query vectors; select the top K historical query vectors with the highest connectivity as the representative historical query vectors in this class; A query semantic cache is constructed based on the representative historical query vectors and their corresponding domain-specific languages.
4. The query semantic caching method based on LLM for data retrieval scenarios according to claim 1, characterized in that, The method further includes: If the current user query vector does not hit the query semantic cache, a domain-specific language is generated for the current user query vector using the large language model.
5. A query semantic caching method based on LLM for data retrieval scenarios according to claim 4, characterized in that, If the current user query vector does not hit the query semantic cache, the process of generating a domain-specific language for the current user query vector using the large language model includes: The current user query vector is parsed using a large language model, and the pre-generated metric, pre-generated dimension, and pre-generated filter results are obtained. The parsing result of the current user query vector is input into the large language model to select a table, and the table information that matches the current user query vector is obtained. In response to table information, metric pre-generated results, dimension pre-generated results, filter pre-generated results, metric configuration rules, dimension configuration rules, and filter configuration rules, the large language model outputs metric configuration, dimension configuration, and filter configuration. The metric configuration, dimension configuration, and filter configuration constitute the domain-specific language corresponding to the current user's query vector.
6. A query semantic caching method based on LLM for data retrieval scenarios according to claim 1, characterized in that, The process of converting historical queries into historical query vectors and converting current user queries into current user query vectors includes: Perform entity identification on non-critical query structures in the query; Remove the identified non-critical query structure entities from the query; The query after removing non-critical query structure entities is vectorized to obtain the corresponding query vector.
7. A query semantic caching method based on LLM for data retrieval scenarios according to claim 1, characterized in that, The process of retrieving data from the query semantic cache based on the current user query vector and determining whether the current user query vector hits the query semantic cache includes: Calculate the similarity between the current user query vector and each historical query vector in the query semantic cache; The historical query vector with the highest similarity is selected as the best matching query vector; Determine whether the similarity corresponding to the best matching query vector is greater than a preset similarity threshold; if so, determine that the current user query vector hits the query semantic cache.
8. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores one or more computer programs that can be executed by the at least one processor, and the one or more computer programs are executed by the at least one processor to enable the at least one processor to execute the LLM-based query semantic caching method for data retrieval scenarios as described in any one of claims 1-7.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the LLM-based query semantic caching method for data retrieval scenarios as described in any one of claims 1-7.
10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the LLM-based query semantic caching method for data retrieval scenarios as described in any one of claims 1-7.