SQL (Structured Query Language) sequence anomaly judgment method based on Top-K hit

Abstract

The invention provides a Top-K hit-based SQL (Structured Query Language) sequence anomaly judgment method, which comprises the following steps of: modeling keywords in an SQL operation sequence in a generative sequence modeling mode, and introducing a Top-K hit-based anomaly judgment mechanism on the basis of predicting a possible SQL keyword candidate set at each position. And carrying out position-by-position analysis on the occurrence condition of the keyword in the SQL operation. The method comprises the following steps: step 1, constructing an ID mapping data set; 2, grammar analysis is conducted on the original SQL statement through the analysis script; step 3, carrying out normalization processing on the structured SQL module; 4, performing ID (Identity) replacement on the normalized structured JSON (JavaScript Object Notation); step 5, for the structured JSON after ID replacement, splicing the ID of each module according to a fixed sequence, and generating a standardized token sequence; step 6, carrying out pre-training on the IitGPT; step 7, performing reinforcement learning fine tuning on the LogGPT; 8, optimizing model parameters through embedding fusion and autoregression learning; and 9, LogGPT reinforcement learning training is carried out.

Description

Technical Field

[0001] This invention relates to a method for determining SQL sequence anomalies based on Top-K hits, applicable to anomaly detection and analysis of database access behavior, application logs, or other structured instruction sequences. Background Technology

[0002] With the widespread application of database systems in critical sectors such as finance, government affairs, and the internet, the security and reliability of database operations are of paramount importance for data asset protection. Database logs, as a crucial component of database systems, record user queries, updates, and management operations performed on the database, serving as the primary basis for security audits, access control, and operational monitoring. Analyzing database logs can uncover potential abnormal operational behaviors, such as unauthorized access, abnormal data modification, or unauthorized deletion, thereby providing support for ensuring the security and integrity of the database system.

[0003] Existing technologies for anomaly detection in database logs mainly include methods based on statistical analysis, traditional machine learning, and deep learning. Common methods in statistical analysis and traditional machine learning-based approaches include Principal Component Analysis (PCA), Isolation Forest, and a class of Support Vector Machines (OCSVM). These methods typically vectorize log entries by manually designing features and determine anomalies based on feature distribution or anomaly scoring. However, due to the high dimensionality, diversity, and strong contextual relevance of SQL operations in database logs, these methods often rely on pre-defined assumptions or linear relationship modeling, making it difficult to accurately characterize the complex patterns of database access behavior. Furthermore, they have weak adaptability to changes in log format and the evolution of access patterns.

[0004] In recent years, deep learning methods have been increasingly applied to database log anomaly detection. Some existing techniques borrow from sequence modeling in natural language processing, treating database logs as operation sequences and using recurrent neural networks (such as LSTM) to build log language models to predict whether the next SQL operation conforms to normal behavior patterns. Representative methods include LSTM-based DeepLog and LogAnomaly. These methods improve anomaly detection performance to some extent, but due to the limitations of the recurrent neural network structure, they are prone to gradient vanishing or information forgetting problems when processing long sequences, making it difficult to fully capture long-range dependencies in SQL operation sequences.

[0005] To overcome the aforementioned shortcomings, some existing technologies employ the Transformer architecture to construct log language models, using a self-attention mechanism to model the contextual relationships within log sequences, thereby enhancing the processing capability for long sequences. However, existing log language model-based methods typically use the prediction of whether a complete SQL operation or its template appears in the first K candidate results as the criterion for anomaly detection. Their training objectives mainly focus on the overall sequence prediction probability, making it difficult to fine-grainedly characterize the normal occurrence patterns of keywords in different positions within the SQL statement sequence.

[0006] Regarding anomaly detection strategies, existing log language modeling methods typically employ a Top-K prediction mechanism. This means that if an observed SQL operation or template does not appear in the top K candidate results predicted by the model, the operation is considered an anomaly. However, this approach usually uses the complete SQL statement or template as the smallest unit of judgment, without analyzing SQL keywords or tags positionally. When the SQL statement is long, complex, or has frequently changing parameters, even if the order or combination of some keywords is abnormal, it may not be identified because the overall prediction result hits the Top-K, thus affecting the granularity and accuracy of anomaly detection.

[0007] Furthermore, the training objectives of existing log language models typically focus on minimizing prediction errors or increasing the overall sequence generation probability, which deviates from the actual business scenario's need for anomaly detection based on keyword-level behavior. The model training process fails to directly optimize for anomaly detection decisions, resulting in the model's adaptability and robustness in practical applications still needing improvement.

[0008] In summary, existing database log anomaly detection technologies suffer from the following problems: When detecting anomalies in database log sequences, existing methods lack the ability to model complex contextual relationships and long-range dependencies in SQL operation sequences; the anomaly determination process typically only predicts or matches complete SQL statements, making it difficult to fine-grainedly characterize the normal occurrence patterns of SQL keywords in the sequence, resulting in anomalies being difficult to accurately identify when SQL statements are long, complex in structure, or have frequent parameter changes; furthermore, there is a discrepancy between the model training objectives of some methods and the actual anomaly determination logic, affecting the accuracy of anomaly detection and its practical application effectiveness. Summary of the Invention

[0009] The purpose of this invention is to address the shortcomings of existing technologies by proposing a Top-K hit-based SQL sequence anomaly detection method. This method models keywords in SQL operation sequences using generative sequence modeling. Based on predicting the candidate sets of SQL keywords that may appear at each position, it introduces a Top-K hit-based anomaly detection mechanism to analyze the occurrence of keywords in SQL operations position by position, thereby improving the accuracy, granularity, and business adaptability of database log anomaly detection.

[0010] The technical solution adopted by this invention to solve the above problems is: a method for determining SQL sequence anomalies based on Top-K hits, characterized by including the following steps: Step 1: Construct an ID mapping dataset of SQL keywords, table names, and column names to provide basic dictionary support for subsequent normalization; Step 2: Use a parsing script to perform syntax parsing on the original SQL statement, extract structured information, and convert it into JSON format; Step 3: Normalization processing of the Structured SQL module; The structured JSON output from step 2 is normalized at the module level to eliminate syntactic differences and redundant information and unify the expression format. Step 4: Using the mapping file generated in Step 1, perform ID replacement on the normalized structured JSON, converting text-type table names, column names, and SQL keywords into corresponding numeric IDs; Step 5: Concatenate the IDs of each module into a standardized token sequence in a fixed order in the structured JSON after ID replacement; Step 6: Pre-train InitGPT; Step 7: Fine-tune LogGPT using reinforcement learning; Step 8: Optimize model parameters through embedding fusion and autoregressive learning; Step 9: LogGPT reinforcement learning training, focusing on sequence cutting, multiple rounds of sampling, reward loss calculation, and gradient update to complete parameter optimization.

[0011] In step 1 of this invention, the ID mapping dataset contains the following three types of core mapping files: (1) SQL Keyword and Conditional Logic Operator Mapping File: Define the ID mapping rules for SQL keywords and conditional logic operators; write the mapping relationship into a CSV file using the script in coreWordTranslete.txt; (2) Table name mapping file: stores the correspondence between database table names and table IDs; (3) Column name mapping file: stores the correspondence between database column names and column IDs.

[0012] Step 2 of the present invention includes the following steps: (1) Input the original SQL statement and parse it into a syntax tree object using the sqlparse library; (2) Extract structured fields, including the following steps: (21) Extract column names, aggregate functions and wildcards in the SELECT clause; (22) Extract table names and aliases in the FROM clause; (23) Extract the type, associated table name and ON condition in the JOIN clause; (24) Extract the condition expression in the WHERE clause, remove redundant spaces and punctuation, split it according to AND / OR logic and retain the connector to form a condition list; (25) Extract the sorting field or grouping field in the GROUP BY and ORDER BY clauses respectively; (26) Extract the offset and record number in the LIMIT clause; (27) If the SQL contains the UNION keyword, split it into multiple subqueries and parse them separately, and store them in the UNION field list.

[0013] Step 3 of the present invention includes the following steps: (1) SELECT_COLS normalization; (2) WHERE / JOIN condition normalization; (3) ORDER_BY normalization; (4) JOIN type standardization.

[0014] Step 4 of this invention includes the following steps: (1) Load the mapping file: construct the mapping dictionary in memory; (2) Processing the FROM clause: split the table name and alias, match the table_name in tables.csv with the table name in uppercase, replace it with the corresponding table_id, ignore the alias and keep only the ID; (3) Processing the JOIN clause: Perform the same replacement logic on the associated table names in the JOIN clause as on the FROM clause; (4) Constructing alias mapping: Based on the table name and alias in the FROM clause, establish the mapping relationship between alias and table name; (5) Full column name matching: For column names in SELECT_COLS, GROUP_BY, and ORDER_BY, if they contain aliases, they are converted to full table names + column names through alias mapping. Column names without aliases are directly matched and replaced according to the column name itself. (6) Function column processing; (7) Keyword and condition type replacement; (8) SQL keywords in structured JSON; (9) Handling of unmatched items: If no matching item is found in the mapping file for table name, column name, or keyword, the original value is retained or marked as the default ID.

[0015] Step 5 of this invention includes the following steps: (1) Concatenate according to the fixed logical order of SELECT→FROM→JOIN→WHERE→GROUPBY→ORDERBY→LIMIT; (2) Sequence format processing: Separate all the concatenated IDs with commas to form a string-type token sequence; (3) Output results: Associate the standardized token sequence with the corresponding user identifier and anomaly label to form the final model input dataset.

[0016] In step 5(1) of this invention, the splicing rules for each module are as follows: (11) SELECT module: First concatenate the SELECT keyword ID, then concatenate the IDs of each column in SELECT_COLS in sequence; (12) FROM module: First concatenate the FROM keyword ID, then concatenate the IDs of each table in FROM in sequence; (13) JOIN module: For each JOIN item, concatenate the JOIN type ID, the associated table ID, the ON keyword ID, and the association condition ID in sequence; (14) WHERE module: First concatenate the WHERE keyword ID, then concatenate the IDs of each condition in WHERE in sequence; (15) GROUPBY and ORDERBY modules: First concatenate the GROUPBY and ORDERBY keyword IDs respectively, and then concatenate the corresponding field IDs in sequence; (16) LIMIT module: First concatenate the LIMIT keyword ID, then concatenate the LIMIT category ID.

[0017] In step 6 of this invention, the length of the generated token sequence is adapted based on the max_lens parameter configured in the model; if the sequence length exceeds max_lens, it is truncated from the end to max_lens; if the sequence length is less than max_lens, it is padded at the end of the sequence. <pad>The corresponding ID; if a serious error occurs during SQL statement parsing or ID mapping, the sequence will be marked as invalid, and its token sequence will be uniformly set to full. <pad>ID.

[0018] In step 7 of this invention, a GPT2Config object is constructed based on the model structure parameters loaded from the options dictionary, wherein the vocabulary size is set to the total length of the vocabulary, and special symbol IDs are mapped to the values ​​in the vocabulary. <bos> 、 <eos> 、 <pad> 、 <unk> 、 <mask>The corresponding ID has its maximum sequence length bound to the max_lens parameter.

[0019] This invention introduces a verification and early stopping mechanism into the LogGPT reinforcement learning fine-tuning process.

[0020] Compared with the prior art, the present invention has the following advantages and effects: The present invention performs keyword-level modeling of SQL operations and predicts the set of SQL keywords that may appear at each position based on the sequence generation model. In the anomaly detection stage, anomaly determination is made based on whether the actual SQL keyword hits the Top-K candidate results of the corresponding position. Thus, while ensuring effective modeling of the database log sequence, the accuracy and stability of identifying abnormal SQL operations are improved, and more reliable determination of abnormal database operations is achieved, thereby improving the security and operational stability of the database system. Attached Figure Description

[0021] Figure 1 This is a diagram illustrating the overall architecture of an embodiment of the present invention. Detailed Implementation

[0022] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. The following embodiments are explanations of the present invention, but the present invention is not limited to the following embodiments.

[0023] I. A method for determining anomalies in SQL sequences based on Top-K hits according to an embodiment of the present invention includes the following steps: Step 1: Construct an ID mapping dataset of SQL keywords, table names, and column names to provide basic dictionary support for subsequent normalization.

[0024] This dataset contains the following three types of core mapping files: (1) SQL Keyword and Conditional Logical Operator Mapping File: Define the ID mapping rules for SQL keywords (segments 1000~1999) and conditional logical operators (segments 5000~5999). The SQL keywords cover DML (SELECT, INSERT, etc.), DDL (CREATE, DROP, etc.), TCL (COMMIT, ROLLBACK, etc.), DCL (GRANT, REVOKE, etc.), functions (COUNT, SUM, etc.) and other operators. The conditional logical operators include comparison classes (COND_EQ, COND_GT, etc.) and logical classes (AND, OR, etc.). The above mapping relationship is written to a CSV file through the script in coreWordTranslete.txt. The file contains three columns: "token", "token_type", and "id".

[0025] (2) Table name mapping file: Stores the correspondence between database table names and table IDs. The file contains two columns, "table_name" and "table_id". "table_name" is the table name in uppercase (including the database name prefix, such as BI_BI.DWD_D_MRT_LY_BLDG_INFO), and "table_id" is a unique identifier ID used for standardized replacement of table names.

[0026] (3) Column name mapping file (columns.csv): Stores the correspondence between database column names and column IDs. The file contains two columns: "full_column_name" and "column_id". "full_column_name" is the full column name in uppercase format (including the table name prefix, such as A.BUILD_ID), and "column_id" is the unique identifier ID, ensuring accurate mapping of column names.

[0027] Step 2: Use a parsing script to parse the original SQL statement, extract structured information, and convert it to JSON format, thus converting unstructured text into structured data. This includes the following steps: (1) Input the original SQL statement and parse it into a syntax tree object (statement) through the sqlparse library. It supports handling complex SQL scenarios such as subqueries, UNION, and multi-table JOIN.

[0028] (2) Extracting structured fields, including the following steps: (21) SELECT_COLS: Extracts column names, aggregate functions (such as count(1), sum(CASE...)) and wildcards (*) from the SELECT clause. Wildcards are uniformly marked as "ALL_COLUMNS". Column names with table aliases retain their original format (such as TT.SORT_ID).

[0029] (22) FROM: Extracts the table name and alias (such as bi_bi.dwa_M_mrt_ly_bldg_extd_listA) in the FROM clause, supports processing subqueries, subqueries are marked as "SUBQUERY" and the internal structure is parsed recursively.

[0030] (23) JOIN: Extract the type of the JOIN clause (LEFTJOIN, INNERJOIN, etc.), the name of the associated table, the ON condition, and terminate at subsequent keywords such as WHERE and GROUPBY to ensure that the association logic is completely extracted.

[0031] (24) WHERE: Extract the conditional expression in the WHERE clause, remove extra spaces and punctuation, split it according to AND / OR logic and keep the connector to form a condition list.

[0032] (25) GROUP_BY / ORDER_BY: Extract the sorting field or grouping field from the GROUPBY and ORDERBY clauses respectively, supporting single field, multiple fields and function expressions (such as sum(score)).

[0033] (26) LIMIT: Extract the offset and record number in the LIMIT clause, and classify them as "1106" (≤100) or "1107" (>100) depending on whether the record number exceeds 100.

[0034] (27) UNION: If the SQL contains the UNION keyword, it splits into multiple subqueries and parses them separately, storing them in the UNION field list.

[0035] Step 3: Normalization processing of the Structured SQL module.

[0036] The structured JSON output from step 2 is normalized at the module level to eliminate syntactic differences and redundant information, and to unify the expression format. This includes the following steps: (1) SELECT_COLS normalization: Use regular expression matching to normalize aggregate functions (count, sum, avg, min, max) into the format "FUNC_AGG(function name)", such as "count(1)" → "FUNC_AGG(COUNT)" and "sum(CASE...)" → "FUNC_AGG(SUM)", keeping the column name and table name prefix unchanged, and the wildcard "*" is kept as "ALL_COLUMNS".

[0037] (2) WHERE / JOIN condition normalization: Handling IN(...) blocks: Identify IN(...) expressions in SQL (supporting nested parentheses), replace them with placeholders and uniformly mark them as "COND_IN" to avoid interference from complex internal content in normalization. Condition type classification: Split conditions according to top-level AND / OR, map the comparison logic to standard condition types, such as "="→"COND_EQ", ">="→"COND_GTE", "LIKE"→"COND_LIKE", "BETWEEN"→"COND_BETWEEN", and uniformly mark conditions that cannot be classified as "COND_OTHER". Logical operator standardization: Convert AND and OR to uppercase uniformly, keep the condition connection relationship unchanged, and the final output format is such as "COND_EQANDCOND_INANDCOND_GTE".

[0038] (3) ORDER_BY normalization: only the aggregate functions are normalized (the rules are the same as SELECT_COLS), the sorting field and table name prefix are preserved, and the consistency of sorting logic is ensured.

[0039] (4) JOIN type standardization: Convert JOIN types (LEFTJOIN, INNERJOIN, etc.) to uppercase, maintain the normalized format of table names and association conditions, and ensure the consistency of association logic and null value handling.

[0040] (5) Delete empty fields or empty lists in the structured JSON to ensure the simplicity of the normalization result.

[0041] Step 4: Using the three types of mapping files generated in Step 1, perform ID replacement on the normalized structured JSON, converting text-type table names, column names, and SQL keywords into corresponding numeric IDs. This includes the following steps: (1) Load the mapping file: construct the mapping dictionary in memory.

[0042] (2) Process the FROM clause: split the table name and alias (e.g., "BI_DW.TC_USER_CB_RH_DETAIL_D_202412R" → table name "BI_DW.TC_USER_CB_RH_DETAIL_D_202412" + alias "R"), match "table_name" in tables.csv with the table name in uppercase, replace it with the corresponding "table_id", ignore the alias and keep only the ID.

[0043] (3) Handling the JOIN clause: Perform the same replacement logic as the FROM clause on the associated table names in the JOIN to ensure the consistency of table name IDs.

[0044] (4) Constructing alias mapping: Based on the table name and alias in the FROM clause, establish the mapping relationship of "alias → table name" (e.g., "R" → "BI_DW.TC_USER_CB_RH_DETAIL_D_202412").

[0045] (5) Full column name matching: For column names in SELECT_COLS, GROUP_BY, and ORDER_BY, if they contain aliases (such as "R.area_id"), they are converted to full table names + column names (such as "BI_DW.TC_USER_CB_RH_DETAIL_D_202412.area_id") through alias mapping. "full_column_name" in columns.csv is matched in uppercase and replaced with the corresponding "column_id". Column names without aliases are directly matched and replaced according to the column name itself.

[0046] (6) Function column processing: The "FUNC_AGG(...)" format after normalization in SELECT_COLS is matched with "token" in all_sql_tokens.csv in uppercase and replaced with the corresponding function ID.

[0047] (7) Keyword and condition type replacement: The normalized "COND_*" type (such as COND_EQ, COND_IN) in the WHERE / JOIN condition matches "token" in all_sql_tokens.csv and is replaced with the corresponding condition ID.

[0048] (8) SQL keywords (such as SELECT, FROM, JOIN) in structured JSON are matched with all_sql_tokens.csv in uppercase and replaced with the corresponding keyword ID.

[0049] (9) Handling of unmatched items: If no matching item is found in the mapping file for table name, column name, or keyword, the original value is retained or marked as the default ID (to avoid data loss).

[0050] Step 5: For the structured JSON after ID replacement, concatenate the IDs of each module in a fixed order to generate a standardized token sequence, which will serve as input for the subsequent anomaly detection model. This includes the following steps: (1) Concatenate the tokens according to the fixed logical order of "SELECT→FROM→JOIN→WHERE→GROUPBY→ORDERBY→LIMIT" to ensure that the token sequence structure of different SQL statements is consistent. The concatenation rules for each module are as follows: (11) SELECT module: First concatenate the SELECT keyword ID, then concatenate the IDs of each column in SELECT_COLS in sequence. (12) FROM module: First concatenate the FROM keyword ID, then concatenate the IDs of each table in FROM in sequence.

[0051] (13) JOIN module: For each JOIN item, concatenate the JOIN type ID, the associated table ID, the ON keyword ID, and the association condition ID in sequence.

[0052] (14) WHERE module: First concatenate the WHERE keyword ID, then concatenate the IDs of each condition in WHERE in sequence.

[0053] (15) GROUPBY and ORDERBY modules: First, concatenate the GROUPBY and ORDERBY keyword IDs, and then concatenate the corresponding field IDs in sequence.

[0054] (16) LIMIT module: First concatenate the LIMIT keyword ID, then concatenate the LIMIT category ID (1106 or 1107).

[0055] (2) Sequence format processing: Separate all the concatenated IDs with commas to form a string-type token sequence, as shown in the example below: "1000,3001,3002,1055,1056,1009,4001,1013,4002,1017,5000,1010,5000,5001,5002,1018,3001,3002,1020,3001,1037,1106.

[0056] (3) Output results: Associate the standardized token sequence with the corresponding user identifier (BlockId) and anomaly label (Label) to form the final model input dataset, which is used for the training and inference of the subsequent anomaly detection model.

[0057] Step 6: Pre-train InitGPT.

[0058] Based on the `max_lens` parameter configured in the model, the length of the generated token sequence is adjusted. If the sequence length exceeds `max_lens`, it is truncated to `max_lens` length from the end; if the sequence length is less than `max_lens`, it is padded to the end. <pad>The corresponding ID (default 0) ensures that all token sequences have the same length, adapting to the model's input requirements. Example: If max_lens=25 and the original sequence length is 22, then 3 more tokens are added. <pad>The final ID sequence is: "1000,3001,3002,1055,1056,1009,4001,1013,4002,1017,5000,1010,5000,5001,5002,1018,3001,3002,1020,3001,1037,1106,0,0,0".

[0059] Abnormal sequence handling: If a serious error occurs during SQL statement parsing or ID mapping (such as no valid SELECT clause, or no matching ID for table / column names), the sequence will be marked as "invalid sequence," and its token sequence will be uniformly set to full. <pad>ID, the label defaults to "abnormal (1)" to avoid invalid data interfering with model training.

[0060] Dataset encapsulation: A structured dataset is constructed by associating standardized token sequences with their corresponding user identifiers (BlockId) and exception labels (Labels). The dataset is stored in DataFrame format, with core columns including: BlockId: User's unique identifier (original input); EventSequence: A standardized sequence of tokens (string format, IDs separated by commas). Label: Abnormal label (0=normal, 1=abnormal); Seq_Length: The original length of the token sequence (before padding), used for subsequent model performance analysis.

[0061] Output Result Verification: Validate the generated standardized token sequence to ensure that: the sequence contains no illegal characters (only numbers and commas); and the tokens are valid (not illegal). <pad>The proportion of IDs should be no less than 80% (excluding invalid sequences); keyword IDs, table IDs, and column IDs should all be within the valid range of the corresponding mapping file. The validated dataset can be directly used as input to the InitGPT model for subsequent pre-training, reinforcement learning fine-tuning, and anomaly detection prediction.

[0062] Dataset splitting and concatenation: The validated structured dataset is divided into training and test sets according to the data splitting rules in main.py. Training set: The first N samples of normal data (N is specified by the train_samples parameter, default is 5000), all with labels 0; Test set: The last M samples of normal data (M = total normal data volume - N) + all abnormal data samples, with labels of 0 or 1 mixed. Input the split dataset directly to start the model training and prediction process.

[0063] Step 7: Build the model configuration and data adaptation environment.

[0064] (1) Initialize Model Configuration First, load the core parameters required to build the model based on the configuration dictionary, including the number of Transformer layers, the number of attention heads, and the dimension of the embedding vectors (default is 768). Simultaneously, determine the size of the vocabulary and specify the corresponding positions of special symbols (such as start symbols, end symbols, padding symbols, unknown symbols, and mask symbols) in the vocabulary. This configuration is mainly determined by the following five key elements: First, the size of the vocabulary list is determined by its total length. 2. Network depth: that is, the number of layers in the Transformer; Three attention mechanism scales: namely, the number of attention heads; The four feature dimensions, namely the width of the embedding layer, determine the richness of the model's representational capabilities. 5. Sequence length limit: Sets the maximum text sequence that the model can process.

[0065] (2) Constructing a user identity embedding layer and a fusion projection layer In order for the model to recognize different user patterns, we introduced a "user embedding" mechanism: User Embedding Layer: This is a lookup table structure. Its function is to map each unique user identifier (BlockId) to a low-dimensional real-valued vector. This vector captures the user's feature information.

[0066] Fusion and Projection: Since the total dimension of the concatenated "text word vectors" and "user vectors" exceeds the original input requirements of the model, we need a linear projection layer (essentially a fully connected layer). Its input is the sum of the "word vector dimension" and the "user vector dimension," and its output is the standard model input dimension. This step ensures that features incorporating user information can be successfully input into the model for computation.

[0067] (3) Dataset Standardization and Batch Processing: In the data preparation stage, we need to convert the raw logs into a format that the model can read. Digital transformation: Converting text log sequences into token ID sequences using a vocabulary.

[0068] Length adaptation: Based on the preset maximum sequence length, excessively long sequences are truncated and excessively short sequences are padded to ensure that all data have the same length.

[0069] Batch processing and attention masks: During training, data is loaded in batches. For each batch of data, in addition to having a uniform length, an attention mask needs to be generated. The purpose of this mask is to tell the model which positions are truly valid data (marked as valid) and which positions are merely placeholders (marked as invalid), thereby preventing the model from learning meaningless padding information.

[0070] Device migration: Finally, the processed sequence data, mask data, and user mapping data are converted into tensor format and moved to the GPU or CPU for computation.

[0071] Step 8: Embedding Fusion and Autoregressive Pre-training Numbers. This includes the following steps: (1) Generating dual embedding representations: For a batch of input log sequences, the model performs two operations in parallel: One approach is to use a word embedding layer to convert each word (Token) in the log into a high-dimensional vector.

[0072] Secondly, the user ID to which the log belongs is converted into a user vector through the user embedding layer.

[0073] (2) Dimension Expansion and Feature Fusion To inject "global user information" into "every word in the sequence," we copy and expand the user vector to align it with the word vector sequence in the sequence length direction. Then, we concatenate the expanded user vector with the word vectors along the feature dimension. The concatenated vector contains two parts: "the word at this moment" and "the overall features of this user." Finally, through the projection layer defined in step 7, this ultra-long vector is compressed back to the standard model dimension to form the final input embedding.

[0074] (3) Autoregressive loss calculation and parameter update Forward propagation: The fused embeddings are input into the GPT2 model, and the model outputs the predicted probability distribution for the next word.

[0075] Loss calculation: The cross-entropy loss function is used to measure the difference between the predicted result and the actual log. Simply put, if the model predicts the next word that matches the word in the actual log, the loss is small; otherwise, the loss is large.

[0076] Backpropagation and optimization: Based on the calculated loss value, the gradients of all trainable parameters in the model are calculated. The optimizer is then used to update the parameters based on the gradients, making the model increasingly accurate.

[0077] Model saving: Monitor model performance in real time on the validation set. Whenever the current loss value is found to be lower than the historical low, save all current parameters to ensure that we finally obtain the best performing model version.

[0078] Step 9: Reinforcement learning training optimizes parameters by focusing on sequence splitting, multiple rounds of sampling, reward loss calculation, and gradient updates. Specifically, it includes the following steps: (1) Sequence splitting and prefix input: The complete log sequence is split into two parts according to a certain proportion (e.g., 20%): the first half is used as "Prompt" input to the model, and the second half is hidden as "Ground Truth".

[0079] (2) Multi-round sampling generation allows the model to attempt to predict the content of the second half based on the prefix of the first half. We will have the model sample multiple times (e.g., 3 times), generating a prediction sequence each time. A greedy strategy is used during sampling, that is, the word with the highest probability is selected each time.

[0080] (3) Calculate reward and loss based on prediction sequence: This step quantifies and scores the generation quality of the model through reward and advantage function: First, perform anomaly detection based on Top-K hit rate. If the real log word appears in the top K candidates predicted by the model, it is considered a successful prediction and a positive reward is given. Otherwise, it is considered an anomaly and the reward is reduced or a penalty is imposed, and the final reward value is normalized to the range of 0 to 1. On this basis, in order to reduce training fluctuations, a moving average baseline is introduced to calculate the advantage function. The difference between the current reward and the historical average baseline is used as the advantage value. If the current reward is higher than the baseline (i.e. the advantage value is positive), the current strategy is explicitly encouraged. The baseline is dynamically updated with the training process to maintain the stability of the evaluation.

[0081] (4) Calculate policy gradient loss based on the advantage function: construct the policy gradient loss by combining the calculated advantage value with the probability of the generated sequence by the model. The intuitive logic is to improve the generation probability of high advantage value sequences by optimizing the algorithm. Then, calculate the average loss of multiple rounds of sampling and perform backpropagation. Gradient pruning is implemented before formally updating the parameters to prevent gradient explosion. Finally, the model parameters are updated with a small fine-tuning learning rate to complete this round of reinforcement learning optimization.

[0082] Step 10: To monitor the model's generalization ability and avoid overfitting, a validation and early stopping mechanism is introduced during the LogGPT reinforcement learning fine-tuning process. The specific implementation is as follows: After each training round, parameter updates are paused, and a validation process consistent with the training phase is executed on an independent validation set (only multi-round sampling and backpropagation are removed) to calculate the average loss value as the unbiased evaluation basis. At the same time, an early stopping mechanism is enabled to track loss changes in real time. If the calculation shows that the decrease in the validation set loss relative to the previous round is less than 1% for three consecutive rounds, it is determined that the model has converged to the optimal state, and then training is forcibly stopped and the historical best model is saved, thereby avoiding invalid calculations and preventing performance degradation.

[0083] II. Comparison of the embodiments of the present invention with the prior art.

[0084] Table 1: Comparison of core performance indicators for anomaly detection.

[0085] .

[0086] As shown in Table 1, under the same dataset and model structure, the anomaly detection precision significantly improved from 42.8% to 75.2% using this invention, an improvement of 75.7%. Simultaneously, the anomaly detection recall reached 82.5%, a 105% improvement over the baseline method. The F1-score increased from 0.415 to 0.787, an improvement of 89.6%, indicating that this invention achieves a good balance between anomaly detection precision and recall. The AUC ROC index improved to 0.912, and the AUC PR index improved to 0.685, further validating the significant advantages of this method in overall discriminative ability and precision-recall balance. These performance improvements are mainly attributed to the multi-level feature extraction mechanism and adaptive threshold optimization strategy introduced in this invention.

[0087] Table 2: Comparison of overall classification performance and generalization ability.

[0088] .

[0089] As shown in Table 2, in a large-scale validation environment with a test sample size of 18,500 records, the method of this invention exhibits excellent generalization ability, with an overall detection accuracy of 91.8%. Of particular note is the effective control of the false positive rate at an extremely low level of 6.2%, a reduction of 66.5% compared to the benchmark method, while maintaining a high recall rate of 82.5% for anomalous samples. Experimental results demonstrate that the method of this invention possesses good stability and practicality in large-scale industrial log data scenarios, effectively balancing detection accuracy with the risk of false positives.

[0090] Table 3: Performance Analysis of Confusion Matrix

[0091] .

[0092] The confusion matrix analysis in Table 3 shows that the method of this invention achieved a normal sample identification accuracy of 94.8% and an abnormal sample recall of 82.5% on 18,500 test samples. The false positive rates were controlled at a low level of 5.2% (false positives for normal samples) and 17.5% (false negatives for abnormal samples), respectively, proving that the method has high reliability and practicality in real-world applications.

[0093] Table 4: Performance stability analysis under different dataset sizes.

[0094] .

[0095] Table 4 shows the performance of the method of the present invention under different data scales. As the data scale increases from 1,850 records to 37,000 records, all performance indicators show a steady upward trend, with the anomaly detection precision increasing from 73.5% to 75.8% and the recall rate increasing from 80.2% to 83.1%. This result indicates that the method of the present invention has good scalability and data adaptability, and can effectively meet the needs of industrial-grade log analysis of different scales.

[0096] This invention innovatively introduces a multi-scale feature fusion mechanism and an adaptive optimization strategy, achieving significant improvements in key indicators such as anomaly detection precision (75.2%), recall (82.5%), and overall accuracy (91.8%), while greatly reducing the false alarm rate (false positive rate 6.2%) and training cost, providing a reliable technical solution for industrial-grade log security monitoring.

[0097] Furthermore, it should be noted that the specific embodiments described in this specification may differ in the shape and name of their components, and the above description is merely illustrative of the structure of the present invention. All equivalent or simple variations made based on the structure, features, and principles described in this patent concept are included within the scope of protection of this patent.< / pad> < / pad> < / pad> < / pad> < / mask> < / unk> < / pad> < / eos> < / bos> < / pad> < / pad>

Claims

1. A method for determining SQL sequence anomalies based on Top-K hits, characterized in that: Includes the following steps: Step 1: Construct an ID mapping dataset of SQL keywords, table names, and column names to provide basic dictionary support for subsequent normalization; Step 2: Use a parsing script to perform syntax parsing on the original SQL statement, extract structured information, and convert it into JSON format; Step 3: Normalization processing of the Structured SQL module; The structured JSON output from step 2 is normalized at the module level to eliminate syntactic differences and redundant information and unify the expression format. Step 4: Using the mapping file generated in Step 1, perform ID replacement on the normalized structured JSON, converting text-type table names, column names, and SQL keywords into corresponding numeric IDs; Step 5: Concatenate the IDs of each module into a standardized token sequence in a fixed order in the structured JSON after ID replacement; Step 6: Pre-train InitGPT; Step 7: Fine-tune LogGPT using reinforcement learning; Step 8: Optimize model parameters through embedding fusion and autoregressive learning; Step 9: LogGPT reinforcement learning training, focusing on sequence cutting, multiple rounds of sampling, reward loss calculation, and gradient update to complete parameter optimization.

2. The SQL sequence anomaly determination method based on Top-K hits according to claim 1, characterized in that: In step 1, the ID mapping dataset contains the following three types of core mapping files: (1) SQL Keyword and Conditional Logic Operator Mapping File: Define the ID mapping rules for SQL keywords and conditional logic operators; write the mapping relationship into a CSV file using the script in coreWordTranslete.txt; (2) Table name mapping file: stores the correspondence between database table names and table IDs; (3) Column name mapping file: stores the correspondence between database column names and column IDs.

3. The SQL sequence anomaly determination method based on Top-K hits according to claim 1, characterized in that: Step 2 includes the following steps: (1) Input the original SQL statement and parse it into a syntax tree object using the sqlparse library; (2) Extract structured fields, including the following steps: (21) Extract column names, aggregate functions and wildcards in the SELECT clause; (22) Extract table names and aliases in the FROM clause; (23) Extract the type, associated table name and ON condition in the JOIN clause; (24) Extract the condition expression in the WHERE clause, remove redundant spaces and punctuation, split it according to AND / OR logic and retain the connector to form a condition list; (25) Extract the sorting field or grouping field in the GROUP BY and ORDER BY clauses respectively; (26) Extract the offset and record number in the LIMIT clause; (27) If the SQL contains the UNION keyword, split it into multiple subqueries and parse them separately, and store them in the UNION field list.

4. The SQL sequence anomaly determination method based on Top-K hits according to claim 1, characterized in that: Step 3 includes the following steps: (1) SELECT_COLS normalization; (2) WHERE / JOIN condition normalization; (3) ORDER_BY normalization; (4) JOIN type standardization.

5. The SQL sequence anomaly determination method based on Top-K hits according to claim 1, characterized in that: Step 4 includes the following steps: (1) Load the mapping file: construct the mapping dictionary in memory; (2) Processing the FROM clause: split the table name and alias, match the table_name in tables.csv by uppercase, replace it with the corresponding table_id, ignore the alias and keep only the ID; (3) Processing the JOIN clause: Perform the same replacement logic on the associated table names in the JOIN clause as on the FROM clause; (4) Constructing alias mapping: Based on the table name and alias in the FROM clause, establish the mapping relationship between alias and table name; (5) Full column name matching: For column names in SELECT_COLS, GROUP_BY, and ORDER_BY, if they contain aliases, they are converted to full table names + column names through alias mapping. Column names without aliases are directly matched and replaced according to the column name itself. (6) Function column processing; (7) Keyword and condition type replacement; (8) SQL keywords in structured JSON; (9) Handling of unmatched items: If no matching item is found in the mapping file for table name, column name, or keyword, the original value is retained or marked as the default ID.

6. The SQL sequence anomaly determination method based on Top-K hits according to claim 1, characterized in that: Step 5 includes the following steps: (1) Concatenate according to the fixed logical order of SELECT→FROM→JOIN→WHERE→GROUPBY→ORDERBY→LIMIT; (2) Sequence format processing: Separate all the concatenated IDs with commas to form a string-type token sequence; (3) Output results: Associate the standardized token sequence with the corresponding user identifier and anomaly label to form the final model input dataset.

7. The SQL sequence anomaly determination method based on Top-K hits according to claim 6, characterized in that: In step 5(1), the splicing rules for each module are as follows: (11) SELECT module: First concatenate the SELECT keyword ID, then concatenate the IDs of each column in SELECT_COLS in sequence; (12) FROM module: First, concatenate the FROM keyword ID, then concatenate the IDs of each table in FROM in sequence; (13) JOIN module: For each JOIN item, concatenate the JOIN type ID, the associated table ID, the ON keyword ID, and the association condition ID in sequence; (14) WHERE module: First concatenate the WHERE keyword ID, then concatenate the IDs of each condition in WHERE in sequence; (15) GROUPBY and ORDERBY modules: First concatenate the GROUPBY and ORDERBY keyword IDs respectively, and then concatenate the corresponding field IDs in sequence; (16) LIMIT module: First concatenate the LIMIT keyword ID, then concatenate the LIMIT category ID.

8. The SQL sequence anomaly determination method based on Top-K hits according to claim 1, characterized in that: In step 6, the length of the generated token sequence is adapted based on the max_lens parameter configured in the model; if the sequence length exceeds max_lens, it is truncated to max_lens from the end; if the sequence length is less than max_lens, it is padded to the end of the sequence. <pad> The corresponding ID;< / pad> If a serious error occurs during SQL statement parsing or ID mapping, the sequence will be marked as invalid, and its token sequence will be uniformly set to full. <pad> ID.< / pad> 9. The SQL sequence anomaly determination method based on Top-K hits according to claim 1, characterized in that: In step 7, a GPT2Config object is constructed by loading model structure parameters based on the options dictionary, where the vocabulary size is set to the total length of the vocabulary, and special symbol IDs are mapped to the values ​​in the vocabulary. <bos> 、 <eos> 、 <pad> 、 <unk> 、 <mask> The corresponding ID has its maximum sequence length bound to the max_lens parameter.< / mask> < / unk> < / pad> < / eos> < / bos> 10. The SQL sequence anomaly determination method based on Top-K hits according to claim 1, characterized in that: A verification and early stopping mechanism is introduced in the LogGPT reinforcement learning fine-tuning process.

Images