Metadata adaptive compression method and system for natural language models

Abstract

The application discloses a metadata adaptive compression system, method, equipment and medium for a natural language model, and relates to the fields of databases and artificial intelligence. The system comprises seven modules of frequency statistics storage, metadata cache, table selection, prompt word construction, large language model client, frequency feedback and metadata change synchronization. The cumulative count and timestamp are stored by tenant bucketing, the key word / historical frequency / default row number signals are selected by a unified weighted fusion formula, recent access is given a higher weight by exponential decay, the serialization is differentiated according to the detail level, the actual reference table name of SQL is backfilled according to the tenant to form a cross-query closed loop, and the disappeared table is cleaned up across tenants when the Schema is refreshed. The application does not need to train a neural network, and the token consumption is reduced by 99.2% and the API cost is about 61.5% under the condition of 500 tables, the recall rate is improved by 8.3 to 15.8 percentage points compared with the full amount baseline, and the context window overflow is avoided.

Description

Technical Field

[0001] This invention relates to the fields of database technology and artificial intelligence technology, and in particular to a method and system for adaptive compression of metadata for natural language models, computer equipment and storage media, which can be applied to metadata control protocol (MCP) servers, intelligent database agents, enterprise-level business intelligence (BI) tools and natural language database query scenarios. Background Technology

[0002] With the rapid development of Large Language Model (LLM) capabilities, "Text-to-SQL" (NL2SQL) has become a popular requirement for enterprise data applications. Its typical workflow is as follows: the user describes the query request in natural language, the system uses the LLM to convert it into a Structured Query Language (SQL) statement that can be executed on a relational database, and returns the results.

[0003] To ensure accurate SQL generation by the large language model, the system needs to inject the database's schema metadata (including table names, column names, data types, primary keys, foreign keys, indexes, constraints, table and column comments, row count estimates, and other structural information) into the large language model's prompt context. However, real-world production databases often contain dozens to thousands of tables, each with dozens to hundreds of columns. Injecting all schema metadata into the large language model's prompts would cause the following problems: First, the token consumption for prompts would balloon dramatically, often reaching tens of thousands of tokens, far exceeding the limited context window of mainstream large language models. Second, for large language model services that are billed by tokens, the prompt length is linearly related to API call costs, and full injection would result in high operational costs. Third, excessively long prompts would significantly increase the time-to-first-token latency, impacting user experience. Fourth, critical metadata from relevant tables would be diluted by metadata from irrelevant tables, significantly reducing the accuracy of the large language model in identifying relevant tables during SQL generation. Fifth, in extreme cases, the prompt length might exceed the large language model's context window limit, rendering the system unavailable.

[0004] To address the aforementioned issues, existing technologies offer several solutions. One is schema linking based on deep learning, such as aligning query tokens with schema elements within the model using a relation-aware self-attention mechanism. Limitations of this approach include: the need for pre-trained specialized models, resulting in high deployment costs; strong coupling between the model and the specific schema, requiring retraining when migrating to a new database; and the inability to use this mechanism as an independent input preprocessing layer before calling a large language model. Another approach is suggestion word compression based on natural language tokens, such as calculating token perplexity using a small language model and deleting low-perplexity tokens. Limitations of this approach include: operating on natural language tokens and lacking awareness of the structured semantics of the schema; potential for accidental deletion of key identifiers such as table names and column names, compromising SQL generation accuracy; and reliance on additionally trained small models for perplexity calculation. A third approach is context compression based on retrieval enhancement, such as generating summaries from retrieved documents using extractive or generative compressors. The limitations of this type of method are: the objects of operation are natural language documents, which are not suitable for structured schemas; a dedicated compressor needs to be trained; the compression decision is only based on the current query and does not have the ability to accumulate learning across queries. Fourthly, there are adaptive retrieval methods based on semantic similarity, such as dynamically selecting the retrieval volume through similarity distribution or difficulty classifiers. The limitations of this type of method are: the decision-making basis is the features of a single query (similarity, difficulty), without utilizing historical information across queries; it is not designed for structured schema metadata; some methods still require training a classifier. Fifthly, there are fixed compression methods based on templates or rules, such as manually selecting key tables or filtering by table name prefixes. The limitations of this type of method are: static rules cannot adapt to the diversity of queries; maintenance costs are high, requiring manual intervention from database administrators; rules need to be updated synchronously after schema changes, which is prone to errors.

[0005] A search revealed several existing patents related to the NL2SQL scenario. For example, CN118820277B discloses a two-stage prompt strategy, which first calls a large language model to perform table filtering and then assembles complete prompts. Its table selection relies on additional calls to the large language model and does not introduce a cross-query frequency feedback mechanism. CN118861081B discloses an intelligent SQL query generation scheme based on fine-tuning the SQL-Qwen32B large language model, which relies on a specially trained neural network model, resulting in high operating costs and deployment barriers. US20260133964A1 discloses a scheme for verifying SQL generated by a large language model based on directed graphs, involving dynamic Schema metadata retrieval and local caching. However, its focus is on post-generation verification rather than pre-call Schema selection, and it does not involve cross-tenant frequency feedback or cumulative learning. Furthermore, open-source / commercial solutions such as LangChain SQL Agent, LlamaIndex, Vanna.AI, and Alibaba PolarDB NL2SQL mostly rely on vector retrieval or RAG training methods to process the schema, and do not disclose frequency statistics by tenant bucketing or a cross-tenant DDL synchronization mechanism. The aforementioned existing patents and commercial solutions mainly focus on optimizing the SQL generation end (such as knowledge distillation, self-correction, and parsing optimization) or schema pre-filtering based on vector similarity. However, a complete solution has not yet been provided for the independent technical problem of adaptive compression of schema input based on cross-query frequency feedback before calling large language models. Furthermore, existing technologies do not offer systematic solutions for query history isolation and differentiated schema recommendation mechanisms in multi-user, multi-tenant scenarios, nor for frequency statistical consistency maintenance mechanisms when schema changes are caused by Database Definition Language (DDL) events.

[0006] Therefore, there is an urgent need for a technical solution that can dynamically compress and inject the schema context into a large language model based on the historical frequency feedback across queries without training any neural network model, and supports multi-tenant isolation, cross-query cumulative learning, and robust DDL maintenance, in order to solve the shortcomings of existing technologies in terms of token explosion, API costs, context window overflow, and multi-user personalization. Summary of the Invention

[0007] In view of the above-mentioned problems in the prior art, the present invention provides a method and system for adaptive compression of metadata for natural language models, a computer device and a storage medium, which aims to solve the problems of high consumption of prompt tokens, high API costs, easy overflow of context windows, dilution of key information by irrelevant metadata and lack of multi-tenant isolation and cross-query learning capabilities in the prior art. In this way, it can realize runtime adaptive compression of schema metadata, cross-tenant differentiated recommendation, cross-query cumulative learning and robust maintenance of DDL changes, without the need to train any neural network model.

[0008] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0009] In a first aspect, embodiments of the present invention provide an adaptive metadata compression system for natural language models, comprising:

[0010] The frequency statistics storage module is used to store the usage records of the database table in buckets according to the tenant identifier. The usage records include at least two forms: cumulative count and access timestamp list.

[0011] The metadata caching module is used to pull database schema metadata from the system directory of the target database through an asynchronous timed refresh mechanism and maintain an in-memory cache.

[0012] The table selection module is used to read the candidate table set from the metadata cache module when a natural language query is received, and to perform a comprehensive score on each candidate table according to a unified weighted fusion formula based on the frequency data of the frequency statistics storage module in order to select a relevant table subset.

[0013] The prompt word construction module is used to serialize the metadata of each table in the relevant table subset according to the level of detail associated with the frequency score of the table, and concatenate them into a prompt word context.

[0014] The large language model client module is used to input the prompt word context into an external large language model and obtain the generated SQL statement;

[0015] The frequency feedback module is used to fill the set of table names actually referenced by the SQL statement back into the frequency statistics storage module according to the tenant identifier after the SQL statement is executed, forming a feedback loop across queries;

[0016] The metadata change synchronization module is used to compare the schema differences before and after the metadata cache module completes the refresh, and to synchronize and clean up the frequency data of the disappeared tables in all tenants.

[0017] In a preferred embodiment of the system described in this invention, the unified weighted fusion formula used by the table selection module is:

[0018] ,

[0019] in , , These are keyword matching rate, normalized historical frequency score, and normalized default priority, all of which are normalized to the [0,1] range. , , These are configurable weighting coefficients, and the sum of the three is equal to 1.

[0020] As a preferred embodiment of the system described in this invention, wherein: The selection module of the table is based on the exponential decay formula:

[0021] ,

[0022] The calculation shows that λ is the attenuation coefficient; when λ is zero, it degenerates into a timestamp list length count; when λ is greater than zero, the weight of recent visits is significantly higher than that of long-term visits.

[0023] In a preferred embodiment of the system described in this invention, the frequency feedback module increments the cumulative count by one when backfilling frequency data according to the tenant identifier, and appends the current timestamp to the access timestamp list; the access timestamp list is set with a maximum length limit for a single table, and when the limit is exceeded, only the most recent timestamps are retained.

[0024] As a preferred embodiment of the system described in this invention, the metadata change synchronization module identifies the set of table names that have been dropped, clears the records belonging to the set of table names for the frequency data under all tenant identifier dimensions, keeps the frequency data of unchanged tables unchanged, and automatically includes newly added tables in the candidate table set of the table selection module.

[0025] As a preferred embodiment of the system described in this invention, the table selection module automatically reverts to the frequency data corresponding to the predefined global tenant identifier for scoring calculation when the frequency data of the specified tenant is empty.

[0026] As a preferred embodiment of the system described in this invention, the prompt word construction module divides the level of detail into three levels: complete, standard, and concise; and sorts the tables in the relevant table subset in descending order of frequency score, mapping the first part of the sort to the complete level, the middle part to the standard level, and the rest to the concise level.

[0027] In a preferred embodiment of the system described in this invention, when the frequency statistics storage module is empty, the table selection module selects a preset number of tables from the candidate table set as a subset of relevant tables by using the estimated row count in descending order as the primary sorting key and the full table name in alphabetical order as the secondary sorting key.

[0028] Secondly, embodiments of the present invention also provide an adaptive compression method for metadata of natural language models, comprising: maintaining usage records of database tables by tenant identifier; pulling database schema metadata and maintaining a memory cache through an asynchronous timed refresh mechanism; selecting a subset of relevant tables according to a unified weighted fusion formula when a natural language query is received; serializing and concatenating the query context according to the level of detail; inputting the query context into a large language model to obtain an SQL statement; backfilling the table names actually referenced by the SQL statement into the usage records by tenant identifier; comparing schema differences after refreshing the memory cache and synchronously cleaning up the frequency data of tables that have disappeared in all tenants.

[0029] Thirdly, embodiments of the present invention also provide a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement any operating step of the above-described system or any step of the above-described method.

[0030] Fourthly, embodiments of the present invention also provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements any operating step of the above-described system or any step of the above-described method.

[0031] The beneficial effects of this invention include the following aspects.

[0032] First, it significantly reduces the amount of schema context data injected into large language model prompt words: This invention decouples the schema metadata scale of injected prompt words from the actual number of tables in the target database through a unified weighted fusion formula and a level of detail coupling mechanism. In a production-scale schema with 500 tables, it can reduce prompt word token consumption by 99.2%, and the token consumption remains constant as the schema scale expands from 15 to 500 tables, which is different from the existing proportional compression method where the token consumption increases linearly with the schema scale.

[0033] Second, it reduces the probability of prompt words exceeding the upper limit of the context window of a large language model: This invention can completely avoid the problem that the length of prompt words approaches or even exceeds the upper limit of the context window of a large language model due to the full injection of schema metadata, thus avoiding system unavailability caused by prompt word truncation or call failure in large-scale schema scenarios and improving the availability of the system in large schema scenarios.

[0034] Third, improve the recall rate of related tables: This invention uses a frequency feedback loop for cross-query cumulative learning and a frequency data isolation mechanism for tenant-based bucketed storage to enable the selection of related tables to be continuously optimized in multiple queries. The actual test showed that the recall rate of related tables generated by SQL was 8.3 to 15.8 percentage points higher than the full schema injection baseline, and solved the problem that irrelevant metadata dilutes key information under a large schema, which causes the full injection recall rate to decrease.

[0035] Fourth, improve system robustness after DDL changes: This invention uses a metadata change synchronization module to clean up the frequency data of tables that have been dropped across tenants after each metadata cache refresh, ensuring the consistency of frequency statistics with the latest schema, avoiding SQL execution errors caused by recommending tables that no longer exist, and enabling the system to still run stably when facing frequent schema changes in the production database.

[0036] Fifth, it supports multi-tenant isolation and cold start rollback: This invention stores usage records in buckets according to tenant identifiers and sets a predefined global tenant identifier as a fallback view, which can simultaneously support the isolation of query history for multiple users, multiple sessions, and multiple business teams, and enable newly added tenants to inherit the relevant table recommendations of the group's usage history even if they have no usage history.

[0037] Sixth, it supports timely tracking of user interest shifts: This invention assigns higher weight to recent visits through an exponential decay formula, enabling the system to track user query preferences in a timely manner when they shift, which is closer to real business intuition than pure counting methods.

[0038] Seventh, deployment-friendly: This invention requires no training of any neural network model and can be deployed directly to any database query system based on a large language model. In addition to the main technical effects mentioned above, as an auxiliary economic benefit, since the call cost of the large language model API service, which is billed per token, is linearly related to the length of the prompt word, this invention significantly reduces prompt word token consumption while correspondingly reducing LLM API call costs by approximately 61.5%. Attached Figure Description

[0039] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, 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, and those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0040] Figure 1A schematic diagram of the overall structure of an adaptive metadata compression system for natural language models provided in an embodiment of the present invention;

[0041] Figure 2 This is a schematic diagram of the main process of the adaptive metadata compression method for natural language models provided in an embodiment of the present invention;

[0042] Figure 3 This is a schematic diagram of frequency statistics, exponential decay, and feedback closed loop provided in an embodiment of the present invention;

[0043] Figure 4 This is a schematic diagram of the table selection decision for the unified weighted fusion formula provided in an embodiment of the present invention;

[0044] Figure 5 This is a schematic diagram of the data flow for multi-tenant frequency isolation and global fallback provided in an embodiment of the present invention;

[0045] Figure 6 This is a schematic diagram of a computer device structure provided in an embodiment of the present invention.

[0046] Figure 2 The correspondence between steps S101 to S108 and S201 to S203 shown in the diagram and steps one to seven of the method is as follows: Step two corresponds to S102 and S201; Step three corresponds to S101, S103, S104, and S105; Step four corresponds to S106; Step five corresponds to the large language model invocation part of S107; Step six corresponds to the SQL execution part of S107 and S108; Step seven corresponds to S202 and S203; The maintenance of the usage record described in step one is continuously completed by the frequency feedback of S108 and is not... Figure 2 It is presented in separate steps. Detailed Implementation

[0047] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of the present invention.

[0048] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0049] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0050] Example 1: Overall System Implementation

[0051] This embodiment describes the overall structure and operation flow of the system of the present invention. (Refer to...) Figure 1 The metadata adaptive compression system for natural language models provided in this embodiment consists of seven modules: frequency statistics storage module, metadata caching module, table selection module, prompt word construction module, large language model client module, frequency feedback module, and metadata change synchronization module.

[0052] The seven modules expose a unified query tool interface to the outside world through the Metadata Control Protocol (MCP) server, accepting natural language queries and optional tenant identifiers from the application.

[0053] The frequency statistics storage module is used to bucket the usage records of the database table according to the tenant identifier. In this embodiment, the frequency statistics storage module maintains two nested dictionary data structures in memory.

[0054] The first nested dictionary uses the tenant identifier as the outer key, the full table name as the inner key, and the cumulative count (integer) as the value; the second nested dictionary uses the tenant identifier as the outer key, the full table name as the inner key, and the access timestamp list (floating-point list) as the value.

[0055] The tenant identifier is a string that can be explicitly passed in by the application when calling the query tool. When the application does not pass in the tenant identifier, the system will by default classify the usage records of this query into the bucket corresponding to the predefined global tenant identifier (such as "__global__").

[0056] The global tenant identifier has a dual function: first, as a fallback bucket key in scenarios where no tenant is specified; second, as a global fallback view for newly added tenants without any usage history.

[0057] Regarding the collaborative maintenance of the cumulative count and access timestamp list, each time the frequency feedback module backfills the table name actually referenced by the SQL to the frequency statistics storage module, the cumulative count of the corresponding table is incremented by one, and the access timestamp list is appended with the UNIX timestamp of the current moment.

[0058] The access timestamp list has a maximum length limit for a single table, such as 10,000 timestamps. When the access timestamp list of a certain table exceeds the limit after appending, the frequency statistics storage module only retains the most recent few timestamps, that is, it truncates the end of the list.

[0059] This mechanism ensures that the memory usage of the frequency statistics storage module remains bounded during continuous system operation, thus avoiding memory leaks caused by prolonged operation.

[0060] The metadata caching module is used to pull database schema metadata from the system directory of the target database through an asynchronous timed refresh mechanism and maintain an in-memory cache.

[0061] The schema metadata includes at least the table name, table comments, estimated number of rows, column names, column data types, column nullability, column primary key markers, column foreign key references, column comments, and table-level index information. In this embodiment, the metadata caching module periodically calls the system directory query interface of the target database (e.g., system tables such as pg_class, pg_attribute, and pg_index in PostgreSQL) at a preset refresh period (default 3600 seconds) through an asynchronous task scheduler (e.g., APScheduler).

[0062] During each refresh process, the metadata caching module retrieves at least five types of metadata queries in a concurrent manner, including table queries, column queries, primary key queries, foreign key queries, and index queries.

[0063] In a multi-database connection configuration, the metadata caching module independently maintains metadata caching and refresh scheduling for each database instance.

[0064] The metadata caching module prevents concurrent refresh conflicts through a singleton lock mechanism (such as asyncio.Lock), avoiding cache inconsistency caused by being interrupted by another refresh before one refresh is completed.

[0065] The table selection module is used to perform comprehensive scoring and selection of candidate tables when a natural language query is received. In this embodiment, the table selection module supports two working modes: a covered concatenation mode and a weighted fusion mode.

[0066] In the weighted fusion mode, the table selection module calculates a comprehensive score for each of the candidate tables returned by the metadata caching module according to a unified weighted fusion formula, and selects the top K tables as the relevant table subset in descending order of the comprehensive score, where K is a preset upper limit for the number of relevant tables.

[0067] In the overlay serial mode, the table selection module sequentially performs four serial steps: keyword matching, foreign key association expansion, high-frequency supplementation, and frequency sorting, as a backward compatibility fallback scheme for the weighted fusion mode.

[0068] The two modes are switched by a configuration switch to ensure backward compatibility of the system and prevent new features from disrupting the behavior of existing application users.

[0069] The prompt word building module is used to serialize the selected relevant table subset into a prompt word context.

[0070] In this embodiment, the prompt word construction module divides the level of detail into three levels: complete, standard, and concise.

[0071] The metadata serialization result of the full-level profile includes all information such as table name, table comments, row count estimate, column name, column data type, column primary key marker, column foreign key reference, column nullability, column comments, and table-level constraints; the metadata serialization result of the standard-level profile omits column nullability, column comments, and table-level constraints; the metadata serialization result of the simplified profile only includes table name, table comments, and a list of column names (excluding column types).

[0072] The prompt word construction module sorts the relevant table subsets in descending order of frequency based on the frequency scores of each table in the relevant table subsets, and maps the first table to the full level, the middle table to the standard level, and the remaining table to the simplified level according to a preset ratio.

[0073] For example, the preset ratio is that the first 25% is mapped to the full gear, the next 50% is mapped to the standard gear, and the remaining 25% is mapped to the simplified gear.

[0074] The large language model client module is used to input the prompt word context output by the prompt word construction module into the external large language model and obtain the generated SQL statement.

[0075] In this embodiment, the large language model client module is compatible with the OpenAI protocol and can connect to any large language model service that conforms to the protocol, such as GPT-4o, GPT-4o-mini, Claude, and Zhipu GLM.

[0076] The large language model client module is equipped with a two-layer protection system of rate limiting (AsyncLimiter) and concurrency control (asyncio.Semaphore) to avoid overloading the external large language model service in high-concurrency scenarios.

[0077] The frequency feedback module is used to backfill the set of table names actually referenced by the SQL statement into the frequency statistics storage module according to the tenant identifier after the SQL statement is executed.

[0078] In this embodiment, the frequency feedback module extracts all referenced table names from the generated SQL statement using an SQL parser (e.g., based on the sqlglot abstract syntax tree).

[0079] The SQL parsing is performed according to the following process:

[0080] The first step is to parse the SQL statement into an Abstract Syntax Tree (AST) and identify the top-level statement type of the AST. The top-level statement type includes SELECT statements, INSERT statements, UPDATE statements, DELETE statements, and compound statements containing WITH clauses.

[0081] The second step involves traversing the abstract syntax tree to extract all referenced table nodes from the FROM and JOIN clauses of the SELECT statement (including various join forms such as INNERJOIN, LEFT JOIN, RIGHT JOIN, FULL OUTER JOIN, CROSS JOIN, etc.), the INTO target table of the INSERT statement, the target table of the UPDATE statement, the FROM target table of the DELETE statement, and the reference scope of the Common Table Expression (CTE) defined in the WITH clause. This process fully covers the table reference forms in various Data Manipulation Language (DML) statements.

[0082] The third step is to restore the aliases of the referenced table nodes, and map the table aliases used in the query (such as "o" and "u" in "SELECT * FROM orders o JOIN users u ON o.user_id=u.id") back to their original table names according to the SQL scope, so as to avoid mistakenly recording the table aliases in the frequency statistics storage module.

[0083] The fourth step is to perform schema.table normalization on the referenced table names, unifying them to "".<schema_name> .<table_name> The format includes, but is not limited to: completing table names without explicitly specified schemas (such as "orders") to "public.orders" or the corresponding schema of the current search_path according to the default schema of the target database; normalizing identifiers enclosed in double quotes (such as "\"Orders\"") according to the case-insensitive policy of the target database; and converting case-insensitive databases to lowercase, thereby ensuring that the normalized table full name format is consistent with the table full name format maintained by the metadata caching module.

[0084] The fifth step is to remove the temporary table name of the common table expression (CTE) defined in the WITH clause from the set of referenced table names. The reason is that the temporary table name of the CTE is only valid within the lexical scope of the current SQL statement and does not correspond to the actual table in the target database. If it is not removed, it will pollute the frequency statistics storage module.

[0085] Step 6: The set of actual referenced table names, processed as described above, along with the tenant identifier of the current query, is passed to the frequency statistics storage module. The frequency feedback module further includes a failure-free backfill mechanism: the backfill operation is only performed when the SQL statement executes successfully on the target database (i.e., the target database does not throw an SQL execution exception, does not trigger a constraint violation, does not return a database error code, and returns a result set or the number of affected rows); when the SQL statement fails, the frequency feedback module skips this backfill, thereby preventing irrelevant or non-existent tables referenced by erroneous SQL generated by the large language model from being incorrectly accumulated in the frequency statistics storage module, and preventing error signals from polluting subsequent related table selections.

[0086] The backfilling operation is strictly isolated by tenant, and the query history of different tenants is not visible to each other. Furthermore, when a newly added tenant has no history, it can obtain a fallback recommendation of the group's usage history through the global tenant identifier.

[0087] The metadata change synchronization module is used to maintain the consistency between frequency data and the latest schema after the metadata cache module completes the refresh. In this embodiment, the metadata change synchronization module compares the schema differences before and after each metadata refresh to identify the set of table names that have been dropped (i.e., tables that exist in the old schema but not in the new schema).

[0088] For each table name in the set of table names that have been dropped, the metadata change synchronization module traverses all tenant identifier dimensions in the frequency statistics storage module and clears the cumulative count records and access timestamp records belonging to that table name, thereby ensuring that the frequency data does not reference tables that no longer exist.

[0089] The metadata change synchronization module outputs structured logs during cleanup, recording the table name being cleaned up, the number of affected tenants, and the cleanup timestamp, which facilitates auditing by operations and maintenance personnel.

[0090] Example 2: Implementation of the Unified Weighted Fusion Formula

[0091] This embodiment provides a detailed explanation of the unified weighted fusion formula and scoring process for the table selection module. (Refer to...) Figure 4The table selection module selects each candidate table t according to the formula:

[0092] ,

[0093] The overall score is calculated by weighted summing of three components: keyword matching rate, keyword matching percentage, ... Normalized historical frequency scores and normalization default priority .

[0094] Keyword matching rate The calculation method is as follows: First, extract a list of keywords from the natural language query q. The extraction method can be based on the word segmentation results of a word segmenter (such as jieba or stanza) or the entity extraction results based on rules. Then, for each candidate table t, count the number of times the keyword is contained in its table name, table comments, and column names. Finally, divide the number of hit keywords by the total number of keywords extracted from the query q to obtain the normalized matching rate.

[0095] Keyword matching rate The value range is [0,1], where 0 indicates that the candidate table is completely unrelated to the query, and 1 indicates that the metadata of the candidate table completely contains all the keywords in the query.

[0096] Normalized historical frequency score The calculation method is as follows: First, the frequency statistics storage module is called to obtain the original frequency score of candidate table t under tenant tid. When exponential decay is enabled in the configuration options, the original frequency fraction According to the exponential decay formula:

[0097] ,

[0098] Calculation, where The i-th timestamp in the access timestamp list is used, where now is the current time and λ is the attenuation coefficient; when exponential attenuation is not enabled in the configuration, the original frequency fraction is... It is equal to the length of the list of timestamps accessed in this table (i.e., the cumulative number of accesses).

[0099] Then, the maximum value of the original frequency scores from all tables in the candidate set is used as the normalized denominator. Finally, the original frequency scores of each candidate table are divided by... Obtain the normalized frequency fraction The value range is [0,1].

[0100] Normalization default priority The calculation method is as follows: First, obtain the estimated number of rows in candidate table t. The data can be read from the schema query results of the metadata caching module; then, the maximum value of the estimated number of rows in all tables in the candidate set is used as the normalized denominator. Finally, divide the estimated number of rows in each candidate table by... Obtain normalized default priority The value range is [0,1].

[0101] The row count estimate reflects the data size of the candidate tables. Tables with larger data sizes generally have a higher probability of being hit by business queries. It serves as a fallback signal in cold start scenarios.

[0102] Weighting coefficient , , It can be set by configuration items, and the sum of the three is equal to 1.

[0103] In this embodiment, the default configuration of the weighting coefficients is as follows: , , This default configuration achieves superior results in selecting relevant tables across various typical business scenarios.

[0104] When the configuration item is set to , , When the unified weighted fusion formula degenerates into a pure keyword-driven selection, the configuration item is set to... , , When the configuration option is set to [specific setting], it degenerates into a purely historical frequency-driven selection; when the configuration option is set to [specific setting], it reverts to a purely historical frequency-driven selection. , , At that time, it degenerates into a pure cold start heuristic selection.

[0105] This ablative design provides empirical support for the non-obviousness of the present invention: when all three weights are non-zero positive numbers, the table selection effect of the unified weighted fusion formula maintains a robust SQL execution recall rate and low prompt word token consumption in various business scenarios, which is different from any single-item configuration; especially in large-scale schema scenarios (such as when the number of tables exceeds 100), single-item configurations may experience a decrease in recall rate or an increase in token consumption because they only rely on one signal among keywords, historical frequency or row number, while the unified weighted fusion formula can maintain a high recall rate while keeping token consumption constant. For detailed ablative experimental data, please refer to Example 6.

[0106] After the table selection module completes the comprehensive score calculation for all candidate tables, the top K tables are selected as the relevant table subset in descending order of comprehensive score, where K is the upper limit of the number of relevant tables preset in the configuration item.

[0107] After selecting the relevant table subset, the table selection module further expands the relevant table subset along the foreign key relationships in the schema metadata, adding the associated tables that have foreign key reference relationships with any table in the relevant table subset to the relevant table subset, until the upper limit of K is reached.

[0108] The foreign key expansion mechanism ensures that multiple tables associated by foreign keys are not truncated when concatenated into the prompt words, thus preventing errors in the large language model when generating join queries due to missing metadata of associated tables.

[0109] Example 3: Implementation of the Exponential Decay Rule

[0110] This embodiment illustrates the exponential decay rule in the frequency statistics storage module and its actual effect in user interest drift scenarios.

[0111] Reference Figure 3 The frequency feedback module fills back the actual table name referenced into the frequency statistics storage module according to the tenant identifier after each SQL execution.

[0112] The updated access timestamp list, combined with an adjustable attenuation coefficient λ, enables the frequency statistics storage module to distinguish between two types of frequency data with different values: "recent intensive access" and "long-standing historical access".

[0113] In the exponential decay formula:

[0114] ,

[0115] In the middle, each historical timestamp The contribution to the current frequency score is equal to ,in =now- This represents the time interval between the timestamp and the current time.

[0116] when When the value is 0 (i.e., the access occurs at the current moment). =1, the contribution value is the largest; when When it increases, Decreases exponentially; when When it approaches infinity, The operator is used to truncate negative time differences to 0 in clock rollback or timestamp anomaly scenarios, preventing a single abnormal timestamp from causing abnormal amplification of the frequency fraction and ensuring the numerical robustness of the frequency fraction.

[0117] The exponential decay rule assigns higher weight to recent visits, which aligns with the business intuition that "user interests drift over time."

[0118] The value of the decay coefficient λ controls the rate of decay. When λ equals 0, the exponential decay formula degenerates into... (i.e., the length of the timestamp list), is equivalent to pure counting; when λ is greater than 0, the closer the access is to the current time, the more likely it is to be a valid access. The greater the contribution, the more significant the change; as λ approaches infinity, only the visits generated at the current moment become significant. There was a contribution, but all other historical data were suppressed to zero.

[0119] In the actual deployment of this embodiment, the typical value range of λ is 1e-6 to 1e-3, corresponding to a "half-life" of approximately 8 days and approximately 12 minutes, respectively.

[0120] Operations personnel can dynamically adjust λ according to the query patterns of business scenarios: for scenarios with relatively stable query patterns, λ can be a smaller value (such as 1e-6) to retain long-term statistics; for scenarios with rapid business evolution and frequent user interest shifts, λ can be a larger value (such as 1e-3) to promptly eliminate expired preferences.

[0121] To verify the actual effect of the exponential decay rule, a comparative experiment is constructed in this embodiment.

[0122] In the experimental setup, it is assumed that table A was created 1 hour ago ( =3600 seconds) was accessed intensively 100 times, and a certain table B was accessed sporadically 10 times in the last minute.

[0123] The frequency scores and rankings of the two tables for different values ​​of λ are as follows: When When the frequency score of Table A is 100 and that of Table B is 10, Table A is dominant; when At that time, the frequency score of Table A was approximately 99.65, and that of Table B was approximately 9.9996, with Table A being dominant; when At that time, the frequency score of Table A was approximately 70.11, and that of Table B was approximately 9.96, indicating that Table A still dominated; when At that time, the frequency score of Table A was approximately 2.87, and that of Table B was approximately 9.63, with Table B being the first to dominate; when At that time, the frequency score of Table A approached 0, while that of Table B was approximately 6.94, indicating that Table B was significantly dominant.

[0124] It is evident that at the critical point where λ is approximately 1e-3, the 10 recent visits within 1 minute surpass the 100 old visits from 1 hour ago for the first time, directly reflecting the business intuition that "user interests drift over time".

[0125] To prevent memory leaks caused by the unbounded growth of the access timestamp list, the frequency statistics storage module in this embodiment is equipped with a time window cleanup submodule.

[0126] The time window cleaning submodule periodically scans the access timestamp list according to a preset time window (e.g., 30 days) and deletes old timestamps that exceed the preset time window; for tables whose access timestamp list is empty after cleaning, its cumulative count records are synchronously deleted from the frequency statistics storage module.

[0127] The time window cleanup submodule works in conjunction with the maximum length limit of a single table (e.g., 10,000) to ensure that the memory usage of the frequency statistics storage module remains bounded from two dimensions.

[0128] Example 4: Implementation of Multi-tenant Isolation and Global Fallback

[0129] This embodiment describes the multi-tenant bucket storage mechanism and global rollback mechanism of the frequency statistics storage module.

[0130] Reference Figure 5 The frequency statistics storage module stores usage records in buckets according to tenant identifiers. The buckets corresponding to different tenants are independent of each other, and writes are completely isolated.

[0131] The tenant identifier is a string, explicitly passed in by the application when calling the query tool. The granularity of the tenant identifier is determined by the application and can be user-level, session-level, department-level, application-level, or any business-defined granularity, thus making the present invention flexibly applicable to various business scenarios.

[0132] The global tenant identifier is a special tenant identifier predefined by the system (e.g., "__global__"), which has a dual function.

[0133] Firstly, when the application calls the query tool without passing in a tenant identifier, the usage records of this query are defaulted to the bucket corresponding to the global tenant identifier, serving as a fallback bucket key in scenarios where no tenant is specified.

[0134] Secondly, when the table selection module reads an empty frequency data for a specified tenant during the scoring calculation process, the module automatically reverts to the frequency data corresponding to the global tenant identifier for scoring calculation. This ensures that newly added tenants, even without any usage history, can still receive relevant table recommendations based on group usage history. This global rollback mechanism automatically mitigates the "cold start" problem in the multi-tenant system when new users join.

[0135] To verify the actual effectiveness of the multi-tenant bucketed storage mechanism and global rollback mechanism, a comparative experiment is constructed in this embodiment. The experiment simulates two tenants with different business preferences:

[0136] The first tenant (named alice) simulates a customer management personnel, and its history shows that it frequently accesses the four core business tables: users, orders, order_items, and addresses.

[0137] The second tenant (named Bob) simulates a supply chain manager, whose history includes frequent visits to products, reviews, categories, and cars. The four core business tables are tems; there are also a small number of mixed records in the bucket corresponding to the global tenant identifier, with 5 accesses each to users and products.

[0138] Under the experimental setup described above, for the same ambiguous natural language query (e.g., "query related data"), the relevant table subsets selected by this system from different tenant perspectives are as follows: Alice's perspective: order_items, orders, addresses, users, audit_logs; Bob's perspective: reviews, car The relevant table subsets from the global tenant's perspective are users, products, categories, and audit_logs; the relevant table subsets from the perspective of the newly added third tenant (named Charlie, with no history) are users, products, audit_logs, order_items, and orders (completely consistent with the global tenant's perspective).

[0139] In the above experimental results, only one table (audit_logs, which is estimated to be recommended by the default signal) overlaps between the relevant table subsets from Alice's and Bob's perspectives. The Jaccard similarity between the two sets consisting of five tables is only 0.111 (i.e., the Jaccard distance is 0.889), which far exceeds the "significant difference" threshold (Jaccard distance > 0.5).

[0140] This data shows that the multi-tenant bucketed storage mechanism enables different business roles to obtain significantly differentiated schema recommendations.

[0141] Meanwhile, the perspective of the new tenant Charlie is completely consistent with that of the global tenants, indicating that the global rollback mechanism successfully enabled Charlie to inherit the recommendations of the group's usage history in the absence of a history.

[0142] Under the multi-tenant bucketed storage mechanism, the frequency statistics storage module supports the following interfaces:

[0143] First, the usage record is recorded using the interface record_table_usage(table_names, tenant), which writes usage records by the specified tenant.

[0144] Second, the statistics reading interface get_table_usage_stats(tenant) reads statistics data by the specified tenant;

[0145] Third, the statistics clearing interface clear_table_usage_stats(tenant) clears the statistics for a specified tenant. When tenant is None, all tenants are cleared.

[0146] Fourth, the tenant list interface list_tenants() returns a list of identifiers for all currently active tenants.

[0147] The four interfaces provide application providers with complete multi-tenant management capabilities.

[0148] Example 5: DDL Change Synchronization Implementation Method

[0149] This embodiment describes the workflow of the metadata change synchronization module and its robustness under DDL (Database Definition Language) events.

[0150] In a production environment, the database schema is not static. Database administrators may perform DDL operations such as DROP TABLE, CREATE TABLE, and ALTER TABLE as business needs evolve.

[0151] If the DDL operations are not detected and synchronized by the system in a timely manner, the frequency statistics will be inconsistent with the latest schema, which will lead the system to recommend tables that no longer exist and cause SQL execution errors.

[0152] To address this issue, the metadata change synchronization module is triggered immediately after each refresh of the metadata cache module.

[0153] The metadata change synchronization module compares the schema differences before and after the refresh. The specific operation steps are as follows:

[0154] First, denote the set of fully qualified table names in the old schema before the refresh as old_tables;

[0155] Second, the set of fully qualified table names in the refreshed new schema will be denoted as new_tables;

[0156] Third, calculate the difference set removed_tables = old_tables - new_tables to obtain the set of all table names that have been removed;

[0157] Fourth, symmetrically calculate the difference set added_tables = new_tables - old_tables to obtain the set of all newly added table names;

[0158] Fifth, for each table name in the removed_tables set, iterate through all tenant identifier dimensions (including the global tenant identifier) ​​in the frequency statistics storage module, and clear the record corresponding to the table name from the cumulative count dictionary and the access timestamp list dictionary respectively, thereby completing the cross-tenant synchronization and cleanup of frequency data of the disappeared tables;

[0159] Sixth, no special processing is required for the newly added tables in the added_tables set. The newly added tables will automatically appear in the candidate table set returned by the metadata caching module when the natural language query is received next time, and participate in the comprehensive scoring of the table selection module.

[0160] Seventh, the frequency data of the intersection of old_tables and new_tables (i.e., the tables that have not changed between the two refreshes) remains unchanged, and the cumulative count and access timestamp list corresponding to the tables that have not changed are not affected by the refresh process.

[0161] To verify the actual effect of the metadata change synchronization module, a comparative experiment was constructed in this embodiment. In the experiment setup, the initial schema contained 15 tables; the Alice tenant accessed the audit_logs (about to be dropped), users, and orders tables; the Bob tenant accessed car... The system contains two tables: `tems` (which will soon be dropped) and `products`; global tenants access `audit_logs`. Then, it simulates DDL events: `DROP audit_logs` and `DROP car`. TEMS and ADD notifications. After a DDL event triggers a metadata cache refresh, the metadata change synchronization module should meet the following seven verification criteria:

[0162] First, the frequency data in the audit_logs (which had been dropped) in alice was cleaned up;

[0163] Second, car in bob The frequency data of tems (already dropped) has been cleaned up;

[0164] Third, the frequency data of audit_logs (which had been dropped) in the global tenant was cleaned up;

[0165] Fourth, the frequency data for the users and orders (retained tables) in Alice remains unchanged;

[0166] Fifth, the frequency data in the products (retained table) of bob remains unchanged;

[0167] Sixth, newly added tables (notifications) are automatically included in the candidate pool;

[0168] Seventh, the metadata change synchronization module outputs a structured log recording of the cleaned-up table names, the number of affected tenants, and the cleanup timestamp.

[0169] In the actual test of this embodiment, the pass rate of the above seven verification items was 100%. An example of the structured log output by the metadata change synchronization module is: "DDL detection: Clean up frequency data of deleted tables (all tenants); affected_tenants=3; removed_count=2; removed_tables=['public.audit_logs','public.car tems']".

[0170] The structured logs provide operations and maintenance personnel with complete DDL event auditing capabilities.

[0171] The practical significance of the metadata change synchronization module is as follows:

[0172] First, avoid memory leaks and prevent frequency data from being retained in tables that no longer exist for a long time.

[0173] Second, to avoid incorrect recommendations and prevent the system from recommending tables that no longer exist to users after a schema change;

[0174] Third, ensure cross-tenant consistency to avoid inconsistent states where audit_logs in Alice have been cleared but audit_logs in Bob still remain.

[0175] Fourth, it works in conjunction with the frequency feedback module to ensure that the system can still operate stably when faced with frequent schema changes in the production database.

[0176] Example 6: Verification of the Coupling of Detail Levels and the Effect of Large Schema

[0177] This embodiment explains the level-coupling mechanism of the prompt word construction module and its token-saving effect in large schema scenarios.

[0178] Reference Figure 2 After the table selection module completes the selection of relevant table subsets, the prompt word construction module sorts the subsets in descending order of frequency based on the frequency scores of each table in the relevant table subsets, and maps the first, middle and last parts of the sort to three levels of detail: complete, standard and concise, according to a preset ratio.

[0179] The design principle of this coupling mechanism is as follows: high-frequency core tables are the most important to the current business and should be injected with prompt words in the most complete metadata form so that the large language model has the most sufficient context when generating SQL; mid-frequency tables serve as auxiliary references and some details can be omitted appropriately; low-frequency tables only participate when needed occasionally and can be injected in the simplest form to save valuable prompt word context quotas.

[0180] To verify the actual effect of the level of detail coupling mechanism, an extended schema experiment is constructed in this embodiment.

[0181] In the experimental setup, extended mock schemas of the target database were constructed, corresponding to four scales: 15 tables, 100 tables, 300 tables, and 500 tables.

[0182] Fifteen of these tables are core tables for e-commerce business (including 10 business tables such as users, orders, and products, and 5 redundant system tables such as audit_logs). The remaining tables are extended tables generated according to the "partitioning / archiving / data warehouse assistance" mode (such as logs_2024_q1, archived_orders_2023, etc.).

[0183] The token consumption of the proposed configuration (enabling all new features) and the full baseline configuration (no selection, full table injection) of this invention are compared under different schema scales as follows: When the schema has 15 tables, A0 consumes 264.6 tokens and B1 consumes 1022 tokens, with A0 saving 74.1%; when the schema has 100 tables, A0 consumes 264.6 tokens and B1 consumes 6567 tokens, with A0 saving 96.0%; when the schema has 300 tables, A0 consumes 264.6 tokens and B1 consumes 19717 tokens, with A0 saving 98.7%; when the schema has 500 tables, A0 consumes 264.6 tokens and B1 consumes 32874 tokens, with A0 saving 99.2%.

[0184] The above experimental results show that:

[0185] First, the present invention A0 claims that the configured token consumption does not increase with the schema size (constantly 264.6 tokens), which is different from the existing "fixed compression ratio" scheme;

[0186] Second, the token consumption of B1's full injection explodes linearly with the size of the schema. In a scenario with 500 tables, B1 consumes 124 times more tokens than A0.

[0187] Third, the recall rate of B1 actually decreased under the large schema (from 0.700 to 0.625), proving that there is an "irrelevant metadata dilution" effect in full injection; at this time, the recall rate of A0 remained at 0.783 while that of B1 decreased to 0.625, with A0 increasing by 15.8 percentage points compared to B1, corresponding to the upper limit of the "increase of 8.3 to 15.8 percentage points" range in the abstract and invention content;

[0188] Fourth, in a scenario with 500 tables, this invention saves 99.2% of tokens compared to B1. This saving percentage increases exponentially with the size of the schema, which is the core technical advantage of this invention that distinguishes it from existing token compression methods.

[0189] Furthermore, in this embodiment, the level of detail is turned off (i.e. all related tables uniformly use the full level) as the control group A4, and the configuration of A0 is compared with the control group A4 under the schema of 15 tables.

[0190] Experimental results show that the token consumption of the A4 control group was 378.9 tokens, while that of the A0 control group was 264.6 tokens. A0 saved 30.2% of tokens compared to A4, and the recall rates of the two groups were exactly the same (both were 0.783).

[0191] This comparison directly demonstrates that the level of detail coupling mechanism alone contributes approximately 30% of the token savings, which is one of the empirical supports for the non-obviousness of this invention.

[0192] To further reveal the independent contribution of each component in the unified weighted fusion formula and the engineering value of the level-of-detail coupling mechanism, this embodiment runs all 7 sets of end-to-end experiments under 15 table schemas. The 7 sets of configurations include:

[0193] A0 advocates configuring (enabling all new features), , , Enable exponential decay and enable detail level coupling.

[0194] A1 Keyword-Driven Configuration Only , , );

[0195] A2 only historical frequency driven configuration ( , , );

[0196] A3 Removes Exponential Decay Configuration (Decay Coefficient);

[0197] A4 disables the detail level coupling configuration (all related tables uniformly use the full level);

[0198] B1 Full Schema Injection Baseline (Injects complete metadata of all candidate tables into the prompt words without selecting any related tables).

[0199] B2 Overlay Serial Mode Baseline (executes four serial steps in sequence: keyword matching, foreign key association expansion, high-frequency supplementation, and frequency sorting).

[0200] The actual test data of the 7 sets of configurations under the 15-table schema are as follows: A0 proposed configuration average prompt keyword token consumption of 264.8 and related table recall rate of 0.783;

[0201] A1, with its keyword-driven configuration, achieved an average keyword token consumption of 255.1 and a relevance table recall rate of 0.804.

[0202] A2, driven solely by historical frequency, has an average prompt word token consumption of 254.9 and a related table recall rate of 0.782.

[0203] A3, without exponential decay configuration, had an average keyword token consumption of 264.6 and a related table recall rate of 0.783.

[0204] A4 with detail level coupling configuration off average prompt keyword token consumption of 378.9 and related table recall rate of 0.783;

[0205] The baseline for B1 full schema injection is an average keyword token consumption of 1022.0 and a related table recall rate of 0.700.

[0206] The baseline average cue token consumption for the B2 coverage-based concatenation model is 357.0, and the relevance table recall rate is 0.794.

[0207] Based on the above measured data, the engineering value analysis of the seven configurations is as follows:

[0208] First, under the 15-table small schema and stable query mode conditions in this embodiment, the A3 configuration without exponential decay has the same related table recall rate (0.783) as the A0 configuration, and the token consumption (264.6) is also the same. This indicates that under the experimental conditions, enabling only cumulative counting can achieve a single-time recall effect comparable to enabling exponential decay. However, the engineering value of the exponential decay mechanism is not applied to the immediate recall rate of a single query, but rather to its adaptive capability across the time dimension of queries. When user preferences drift over time, the pure counting of A3 cannot actively mitigate the influence of distant history, resulting in new preferences needing dozens or even hundreds of visits to cover old preferences in terms of frequency score. A0, on the other hand, actively decays the contribution of old timestamps at time intervals through exponential decay. In the λ critical point simulation described in Embodiment 3, it can make 100 old visits from 1 hour ago be overtaken by 10 new visits within the last minute. This is the core mechanism that distinguishes A0 from A3 in long-term operating scenarios.

[0209] Second, under the 15-table small schema and single query conditions in this embodiment, the recall rate of the relevant table of A1 (0.804) is slightly higher than that of A0 (0.783) by 2.1 percentage points, driven solely by keywords. The recall rate of A2 (0.782) driven solely by historical frequency is also close to that of A0, indicating that there is no significant difference between the immediate recall rate of the single-item configuration and the weighted fusion configuration under the experimental conditions. However, A1 and A2 each rely on a single signal. A1 does not have the ability to accumulate learning across queries. The table selection result under multiple queries by the same user is completely determined by the current query keywords. It cannot use historical preferences to suppress tables with high keyword hit rates but irrelevant to actual business. A2 does not have the ability to deal with new tables and ambiguous queries. When there are no keyword signals, new tables and cold start tables cannot be scored and distinguished. A0 integrates three orthogonal signals—keywords, historical frequency, and default row count—using a unified weighted fusion formula. This achieves robustness across multiple queries and scenarios at the cost of a slight reduction in single-query recall. This robustness is evidenced by the fact that the recall rate of related tables significantly decreased from 0.700 to 0.625 when the B1 full schema injection baseline was expanded from 15 to 500 schemas. Any scheme that doesn't prune the candidate set will degrade under large-scale schemas due to irrelevant metadata diluting key information. A0, however, advocates a configuration where the prompt token consumption remains constant at 264.6 and the related table recall rate remains at 0.783 as the schema size expands from 15 to 500 schemas. It is the only scheme among all ablation configurations that combines token consumption stability and recall rate stability.

[0210] Third, A0 claims that the configuration saves 30.2% of token consumption compared to the A4 off configuration, saves 74.1% of token consumption compared to the B1 full schema injection baseline and improves the recall rate by 8.3 percentage points, and saves 25.8% of token consumption compared to the B2 coverage-based concatenation mode baseline with a comparable recall rate (A0=0.783, B2=0.794, the difference is within the statistical noise range).

[0211] The above ablation experiment results show that the combination of key technical features of the present invention, such as frequency feedback by tenant bucketing, unified weighted fusion formula, level of detail coupling, and DDL change synchronization, has independent and indispensable engineering value relative to any single baseline, and is empirical support for the non-obviousness of the present invention.

[0212] To further verify the actual effect of the present invention in a real large language model API call scenario, an end-to-end experiment was conducted in this embodiment by integrating the GPT-4o-mini large language model.

[0213] The experiment ran all 7 configurations (A0 claim + four ablation methods for A1 / A2 / A3 / A4 + two baseline methods for B1 / B2), totaling 140 large language model calls with 0 errors. The cumulative cost of 20 queries for the A0 claim configuration was $0.001402, while the cumulative cost of 20 queries for the B1 full baseline configuration was $0.003642, resulting in a 61.5% API cost saving for A0. The recall rate for A0 claim was 0.783, while the recall rate for B1 baseline was 0.700, representing an 8.3 percentage point improvement in recall rate for A0. In small schema scenarios, end-to-end latency is dominated by the large language model inference time. The token compression of this invention has a limited marginal impact on latency. However, in large schema scenarios (over 500 tables), full injection will cause prompt words to approach the context window of the large language model (e.g., 128K in GPT-4o-mini), leading to significant prompt word processing latency and retry overhead. This invention can completely avoid this problem.

[0214] Example 7: Device Implementation and Storage Medium Implementation

[0215] Reference Figure 6 This embodiment provides a computer device, which may be a computer system or a server, for running the metadata adaptive compression method and system for natural language models described in this invention.

[0216] like Figure 6 As shown, the components of the computing device 600 may include, but are not limited to: one or more processors or processing units 601, system memory 602, and bus 603 connecting different system components (including system memory 602 and processing unit 601).

[0217] Computing device 600 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by computing device 600, including volatile and non-volatile media, removable and non-removable media.

[0218] System memory 602 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory. Computing device 600 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, read-only memory (ROM) can be used to read and write non-removable, non-volatile magnetic media (commonly referred to as a "hard disk drive").

[0219] The system memory 602 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of various embodiments of the present invention.

[0220] A program / utility having a set (at least one) of program modules may be stored, for example, in system memory 602, and such program modules include, but are not limited to, an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0221] The computing device 600 can also communicate with one or more external devices 604 (such as a keyboard, pointing device, display, etc.). This communication can be performed through an input / output (I / O) interface.

[0222] Furthermore, the computing device 600 can also communicate with one or more networks (such as local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via the network interface 605.

[0223] The processing unit 601 executes various functional applications and data processing by running programs stored in the system memory 602. For example, it maintains database table usage records by tenant identifier; retrieves database schema metadata and maintains a memory cache through an asynchronous timed refresh mechanism; selects a subset of relevant tables according to a unified weighted fusion formula when a natural language query is received; serializes and concatenates the query context according to detail levels; inputs the query context into a large language model to obtain the SQL statement; backfills the table names actually referenced by the SQL statement into the usage records by tenant identifier; and compares schema differences after refreshing the memory cache and synchronously cleans up the frequency data of disappeared tables in all tenants. The computer device can be a cloud server, an enterprise-deployed Metadata Control Protocol (MCP) server, a business intelligence application backend, or an intelligent agent terminal with database access capabilities.

[0224] This embodiment also provides a computer-readable storage medium storing a computer program (i.e., a program product). When the computer program is executed by a processor, it implements the steps described in the above method implementation, such as maintaining usage records by tenant identifier, refreshing the schema metadata cache, selecting relevant table subsets according to a unified weighted fusion formula, constructing prompt words according to detail levels, calling a large language model to generate SQL, backfilling usage records, and synchronizing DDL changes. The specific implementation methods of each step will not be repeated here.

[0225] It should be noted that examples of the computer-readable storage medium may include, but are not limited to: phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical and magnetic storage media, which will not be elaborated here.

[0226] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0227] In the several embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0228] Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some communication interface, device or unit, and can be electrical, mechanical or other forms.

[0229] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0230] In addition, the functional units in the various embodiments of the present invention 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.

[0231] If the functionality is implemented as a software functional unit and sold or used as an independent product, it can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a portion 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.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0232] Finally, it should be noted that the above embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

[0233] Furthermore, although the operations of the method of the present invention are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

Claims

1. An adaptive metadata compression system for natural language models, characterized in that, include: The frequency statistics storage module is used to bucket the usage records of the database table according to the tenant identifier. The usage records include at least two forms: cumulative count and access timestamp list. The tenant identifier includes a predefined global tenant identifier. The metadata caching module is used to pull database schema metadata from the system directory of the target database through an asynchronous timed refresh mechanism and maintain an in-memory cache. The table selection module is used to read the candidate table set from the metadata cache module when a natural language query is received, and to perform a comprehensive score on each candidate table according to a unified weighted fusion algorithm based on the frequency data of the frequency statistics storage module in order to select a relevant table subset. The prompt word construction module is used to differentially serialize the metadata of each table in the relevant table subset according to the level of detail associated with the frequency score of the table, and concatenate them into a prompt word context. The large language model client module is used to input the prompt word context into an external large language model and obtain the generated SQL statement; The frequency feedback module is used to fill the set of table names actually referenced by the SQL statement back into the frequency statistics storage module according to the tenant identifier after the SQL statement is executed. The metadata change synchronization module is used to compare the schema differences before and after the metadata cache module completes the refresh, and to perform cross-tenant synchronization and cleanup of the frequency data of the disappeared tables under the tenant identifier dimension in the frequency statistics storage module.

2. The system as described in claim 1, characterized in that: The unified weighted fusion formula used by the table selection module is: ， in The keyword normalized match rate between table t and query q. The normalized historical frequency score of table t under tenant tid. The default normalization priority for table t based on row count estimation. , and The weights are configurable and the sum of the three is equal to 1. The , , The value range is [0,1].

3. The system as described in claim 2, characterized in that: The The result is calculated by the table selection module according to the exponential decay formula, which is: ， in Let be the i-th timestamp in the access timestamp list, now be the current time, and λ be the decay coefficient.

4. The system as described in claim 1, characterized in that: When comparing the schema differences before and after the refresh, the metadata change synchronization module identifies the set of table names that have been dropped, and clears the cumulative count and access timestamp records belonging to the set of table names that have been dropped for the frequency data under the tenant identifier dimension of all tenant identifiers in the frequency statistics storage module. Frequency data for tables that have not been changed remains unchanged; The newly added table is automatically included in the candidate table set of the table selection module.

5. The system as described in claim 2, characterized in that: When the table selection module obtains frequency data by tenant identifier, if the frequency data of the specified tenant is empty, it automatically falls back to the frequency data corresponding to the global tenant identifier for scoring calculation.

6. The system as described in claim 1, characterized in that: The prompt word construction module divides the level of detail into three levels: complete, standard, and concise. The complete file contains all information about the table name, table comments, estimated number of rows, column names, column data types, column primary key markers, column foreign key references, column nullability, column comments, and table-level constraints. The standard profile omits column nullability, column comments, and table-level constraints; the simplified profile only includes table names, table comments, and a list of column names. The prompt word construction module sorts the relevant table subsets in descending order of frequency based on the frequency scores of each table in the relevant table subsets, and maps the first part of the sorted table to the complete gear, the middle part to the standard gear, and the rest to the simplified gear according to a preset ratio.

7. The system as described in claim 1, characterized in that: The frequency feedback module extracts the set of table names actually referenced by parsing the abstract syntax tree of the SQL statement. The abstract syntax tree parsing at least covers the FROM and JOIN clauses of the SELECT statement, the target table of the UPDATE statement, the target table of the INSERT statement, the target table of the DELETE statement, and the reference range of the common table expression in the WITH clause. The frequency feedback module performs alias restoration and schema.table normalization on the extracted table name set, and removes the temporary table name of the common table expression defined in the WITH clause from the actual referenced table name set; The frequency feedback module is also equipped with a mechanism to prevent backfilling in case of execution failure. The backfilling operation is only performed when the SQL statement is successfully executed on the target database. If the SQL statement fails to execute, the backfilling is skipped to avoid the table referenced by the erroneous SQL from polluting the historical signals of the frequency statistics storage module.

8. An adaptive metadata compression method for natural language models, the method being executed by a processor reading program instructions from memory, characterized in that, include: Step 1: The processor maintains the usage records of the database table in the frequency statistics area of ​​the memory according to the tenant identifier. The usage records include at least two forms: cumulative count and access timestamp list. Step 2: Pull the database schema metadata from the system directory of the target database and maintain the memory cache through an asynchronous timed refresh mechanism; Step 3: Upon receiving a natural language query, read the candidate table set from the memory cache and perform a unified weighted fusion formula on each candidate table: ， Calculate the overall score and select the relevant subset of tables; Step 4: Serialize the metadata of each table in the relevant table subset according to the level of detail associated with the frequency score of that table, and concatenate them into a prompt word context. Step 5: Input the context of the prompt words into an external large language model and obtain the generated SQL statement; Step 6: Fill the set of table names actually referenced by the SQL statement back into the usage record according to the tenant identifier; Step 7: After the memory cache is refreshed, compare the schema differences before and after the refresh, and synchronously clean up the frequency data of the disappeared tables in all tenants.

9. A computer device, comprising a memory and a processor, characterized in that: The memory stores a computer program, and when the processor executes the computer program, it implements the functions of the system as described in any one of claims 1 to 7 or the steps of the method as described in claim 8.

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

Images