Risk control feature mining method and device based on large model, medium and product

Abstract

The embodiment of the invention relates to the technical field of information, and discloses a risk control feature mining method and device based on a large model, a medium and a product. The method comprises the following steps: in response to a risk control feature mining request, generating an initial feature extraction SQL statement containing a sample table and an association table by using a large model; obtaining an execution plan tree of the initial feature extraction SQL statement in a database, analyzing table associated operation nodes in the execution plan tree, and extracting hash predicate conditions and filtering predicate conditions of the table associated operation nodes; verifying the initial feature extraction SQL statement based on a verification rule, wherein verification at least comprises time sequence anti-crossing verification for the table association operation node; if verification is not passed, feedback information is generated based on a verification result and input into the large model, so that the large model is driven to correct the initial features to extract the SQL statements; and determining a target feature extraction SQL statement until the generated SQL statement passes verification, thereby performing risk control feature mining.

Description

Technical Field

[0001] This application relates to the field of information technology, and in particular to a method, device, medium and product for risk control feature mining based on a large model. Background Technology

[0002] In financial business areas such as credit risk control, anti-fraud, and insurance underwriting, the predictive performance of machine learning models largely depends on the quality of feature engineering. Traditional feature engineering processes rely heavily on close collaboration between business experts and data engineers: business experts propose hypotheses based on experience, such as "calculate the average spending of users over the past 30 days," and data engineers translate these into complex SQL queries and execute them in the data warehouse. This manual approach is not only costly and has a long iteration cycle, but it also struggles to cope with rapidly changing risk and fraud patterns. With breakthroughs in Large Language Model (LLM) technology, automatically generating SQL code using large models has become an important direction for improving feature mining efficiency. Existing technical solutions typically involve directly inputting business requirements into a large model, which then generates feature extraction SQL in a single step.

[0003] However, existing feature generation technologies based on large models face severe challenges in practical industrial applications, especially in financial scenarios with extremely high requirements for temporal logic. First, feature calculation must be strictly based on data prior to the "observation point," but existing large models lack a deep understanding of temporal causal logic, often resulting in hidden "feature crossing" problems in the generated SQL. For example, in multi-table joins, only the user ID is used while ignoring time constraints, or the partition key in the window function is not set correctly, leading to data confusion between different loan orders for the same user. This crossing error is extremely subtle; traditional text matching detection based on regular expressions struggles to cover complex nested queries, resulting in inflated offline metrics during model training and a significant drop in online application performance, posing serious business risks. Second, credit scenario data tables typically contain ultra-wide table structures with hundreds of fields. Directly injecting the complete table structure into a large model can lead to context window overflow or distraction, making it difficult to generate accurate queries. Furthermore, existing generation solutions are mostly single-execution, lacking the memory and utilization of historical successes and failures, and failing to achieve continuous accumulation and automated evolution of feature engineering knowledge. Summary of the Invention

[0004] One objective of this application is to provide a method, device, medium, and product for risk control feature mining based on large models, at least to solve the technical problems in the prior art where it is difficult to automatically detect and correct hidden feature crossing errors, cannot effectively handle ultra-wide table structures, and lacks continuous learning capabilities when generating risk control feature SQL using large models.

[0005] To achieve the above objectives, some embodiments of this application provide the following aspects:

[0006] Firstly, some embodiments of this application provide a risk control feature mining method based on a large model, the method comprising:

[0007] In response to the risk control feature mining request, the large model is used to generate the initial feature extraction SQL statement containing the sample table and the related table;

[0008] Obtain the execution plan tree of the SQL statement extracted from the initial features in the database, parse the table association operation nodes in the execution plan tree, and extract the hash predicate conditions and filtering predicate conditions of the table association operation nodes;

[0009] The initial feature extraction SQL statement is validated based on the validation rules. The validation includes at least a time-series anti-crossing validation for the table association operation node. The time-series anti-crossing validation includes: when the hash predicate condition contains a user dimension identifier field, verifying whether the filtering predicate condition contains a time field for the associated table and a time-series constraint condition relative to the sample table's baseline time.

[0010] If the verification fails, feedback information is generated based on the verification result and input into the large model to drive the large model to correct the initial feature extraction SQL statement;

[0011] The process continues until the generated SQL statement passes the verification, at which point the target feature extraction SQL statement is determined.

[0012] Secondly, some embodiments of this application also provide an electronic device, the electronic device comprising: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method described above.

[0013] Thirdly, some embodiments of this application also provide a computer-readable medium having computer program instructions stored thereon, which can be executed by a processor to implement the method described above.

[0014] Fourthly, some embodiments of this application also provide a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the method described above.

[0015] Compared with related technologies, the solution provided in this application achieves semantic-level deep anti-travel verification by acquiring and parsing the execution plan tree of the database. Unlike traditional text matching detection based on regular expressions, this invention directly analyzes the hash predicates and filtering predicates after database compilation and optimization, which can accurately identify time-series travel paths nested in complex subqueries or aliases. By verifying the time comparison expressions in table association operations and the dimension partition keys in window functions and aggregation operations, it can fundamentally eliminate data travel problems caused by missing time constraints or sample dimension confusion, ensuring the logical correctness of the mined features and the consistency between online and offline models. Furthermore, when time-series travel, missing dimensions, or syntax errors are detected, the system can automatically locate the error node and generate natural language prompts containing standard correction patterns based on the error type mapping table. This mechanism transforms the underlying execution plan errors into semantic instructions that the large model can understand, driving the large model to perform targeted self-correction, greatly improving the success rate of generating complex feature SQL and reducing the cost of manual intervention. Simultaneously, a feature iteration record library was constructed, and combined with Retrieval Enhanced Generation (RAG) technology, the system was able to reuse historical high-gain feature templates and avoid known errors, realizing dynamic adjustment of feature mining strategies and continuous accumulation of knowledge, significantly improving the overall efficiency and effectiveness of feature engineering. Attached Figure Description

[0016] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0017] Figure 1 An exemplary flowchart of a risk control feature mining method based on a large model, provided for some embodiments of this application;

[0018] Figures 2 to 5 A schematic diagram illustrating the verification rules for a risk control feature mining method based on a large model, provided for some embodiments of this application;

[0019] Figure 6 A schematic diagram of an iterative loop for a risk control feature mining method based on a large model, provided for some embodiments of this application;

[0020] Figure 7 An exemplary structural diagram of the electronic device provided for some embodiments of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] Figure 1 An exemplary flowchart of a risk control feature mining method based on a large model, provided for some embodiments of this application, is shown below. The method includes:

[0023] S101. In response to the risk control feature mining request, use the large model to generate an initial feature extraction SQL statement containing the sample table and the related table.

[0024] Specifically, after receiving a risk control feature mining request (e.g., "mining a user's borrowing behavior over the past six months"), the system first initiates preparations for feature generation. Considering that data tables in risk control scenarios (such as user information tables and transaction logs) typically contain ultra-wide table structures with hundreds of fields, to avoid excessive token consumption or distraction caused by directly inputting all fields into the large model, the system can first perform a compression optimization process. By acquiring metadata from the sample table and related tables, the fields are cleaned based on preset field priority classification rules, retaining key primary key identifiers and time fields (P0 level), sampling numerical fields (P1 level) proportionally, and filtering out low-priority descriptive text. The filtered and simplified table structure information is then injected into preset prompts, driving the large model to generate initial feature extraction SQL statements containing the sample table (e.g., loan application table) and related tables (e.g., loan history table). For example, this addresses the requirement that credit risk control features must be aggregated by loan order dimension.

[0025] S102. Obtain the execution plan tree of the initial feature extraction SQL statement in the database, parse the table association operation nodes in the execution plan tree, and extract the hash predicate conditions and filtering predicate conditions of the table association operation nodes.

[0026] Specifically, after generating the initial SQL statement, the system sends an EXPLAIN command to the database to obtain the compiled and optimized execution plan tree (EPT). The system traverses this EPT and identifies various operation nodes based on preset parsing rules. For table join nodes, the system uses regular expressions to extract their core attributes. The system can identify the join type (such as HASH JOIN) and accurately extract hash predicates (usually corresponding to the ON equi-join condition in SQL) and other predicates / filter predicates (usually corresponding to the WHERE clause or non-equi-join condition) from the execution plan text. This process directly obtains the actual logical path of database execution, providing accurate data for subsequent deep validation.

[0027] S103. Verify the initial feature extraction SQL statement based on the verification rules. The verification includes at least a time-series anti-crossing verification for the table association operation node. The time-series anti-crossing verification includes: when the hash predicate condition is detected to contain a user dimension identifier field, verifying whether the filtering predicate condition contains a time field for the associated table and a time-series constraint condition relative to the sample table's base time.

[0028] Specifically, the system performs strict logical compliance checks based on the extracted predicate information. The core of the check rules lies in time-series anti-travel verification. When the system detects that the hash predicate condition of a table join operation node contains a user-dimensional identifier field (such as user_id), it means that the operation has associated all historical user data, posing a very high risk of data traversal. At this time, the system triggers a mandatory verification mechanism to check whether the filtering predicate condition of the node contains a time-series constraint condition relative to the sample table's baseline time for the time field of the joined table. This can be verified by parsing the time comparison expression to check whether the comparison operators (such as <=, <) represent a time-series relationship where the time field of the joined table (such as loan_date) is no later than the sample table's baseline time (such as listing_time). If any of the above verification logic is not satisfied (for example, only the user ID is associated without a time limit), the system determines that the verification has failed.

[0029] S104. If the verification fails, feedback information is generated based on the verification result and input into the large model to drive the large model to correct the initial feature extraction SQL statement.

[0030] Specifically, in this step, once a validation failure is detected, an automated feedback correction process will be initiated. The system first determines the specific node location information (such as Step ID) that failed the validation and extracts the table name, field aliases, and missing join key information of the data table involved in that node. Subsequently, the system matches the corresponding natural language interpretation template based on a preset error type mapping table. For example, for JOIN crossing, the template might be "When joining the table [Table], it was detected that only the user ID was used for the join, and the time sequence constraint relative to the sample time [Time] is missing. Please add the time filter condition." The system uses the extracted specific information to fill in the above template, constructing a structured prompt word containing the standard correction pattern. This process translates the underlying execution plan error into a business logic instruction that the large model can understand, and inputs this feedback information into the large model, driving it to specifically correct the time sequence or dimensional defects in the SQL statement while maintaining the original calculation logic.

[0031] S105. Until the generated SQL statement passes the verification, the target feature extraction SQL statement is determined.

[0032] Specifically, after the large model generates the corrected SQL statement based on the feedback information, the system will repeat the above steps of obtaining the execution plan and verification, forming a closed loop of "action-feedback-correction" until the generated SQL statement passes all preset anti-crossing and dimensional integrity verifications, and is finally determined as the target feature extraction SQL statement.

[0033] In this embodiment, semantic-level deep anti-travel verification is achieved by parsing the execution plan tree of the database. Compared with traditional text regular expression matching, directly analyzing hash predicates and filtering predicates can accurately identify time-series travel paths nested in complex subqueries. Combined with the partition key verification of windows and aggregate functions, feature travel problems caused by missing time constraints or sample dimension confusion are eliminated at the source, ensuring the consistency of online and offline model performance. At the same time, an automated correction closed loop based on natural language feedback is constructed, transforming obscure low-level execution plan errors into correction instructions that the large model can understand, significantly improving the success rate of generating complex SQL, thereby significantly improving the efficiency and quality of risk control feature mining.

[0034] In one embodiment, the step of verifying whether the filtering predicate condition contains a time field for the associated table and a time-series constraint relative to the baseline time of the sample table when the hash predicate condition is detected to contain a user dimension identifier field specifically includes:

[0035] Parse the hash predicate condition and detect whether the hash predicate condition contains a user dimension identifier field;

[0036] In response to detecting that the hash predicate condition contains the user dimension identifier field, the filtering predicate condition is parsed, and a time comparison expression containing the time field of the association table and the baseline time field of the sample table is extracted;

[0037] Verify the comparison operator in the time comparison expression to determine whether the comparison operator represents the temporal relationship that the time field of the associated table is no later than the base time of the sample table.

[0038] Specifically, such as Figure 2 and 3 As shown, after generating the initial SQL statement, the system obtains the compiled and optimized execution plan tree of the SQL statement, traverses the execution plan tree, and identifies various operation nodes based on preset parsing rules. For table join operation nodes, the system uses regular expressions to extract their core attributes. The system can identify the JOIN type (such as HASHJOIN) and accurately extract hash predicates (usually corresponding to the ON equi-join condition in SQL) and filtering predicate conditions from the execution plan text. Semantic parsing is performed on the hash predicate conditions extracted from the execution plan tree to identify whether the current table join operation involves the risk of aggregation of sample dimensions. In the database execution plan, hash predicates usually correspond to the equi-join condition in the SQL statement (e.g., ON t1.uid=t2.uid). The system scans these predicate texts to detect whether they contain preset user dimension identifier fields (e.g., user_id, customer_id, or cert_no). The purpose of this step is to identify potential associations, because once an association is made based on the user ID, it means that all of the user's historical behavior records (such as all loan orders and all transaction records) may be associated with the current sample row, which is a high-risk point for feature crossing.

[0039] Upon detecting that the hash predicate condition contains the user dimension identifier field, a deep parsing of the filtering predicate condition is triggered. Filtering predicate conditions typically correspond to the WHERE clause in SQL or non-equivalence constraints applied during the join process. The system uses regular expressions or syntax tree parsing techniques to search for expressions involving time attributes in the filtering predicate, focusing on extracting time comparison expressions that simultaneously contain time fields from the related tables (e.g., transaction_time in the transaction table or repayment_date in the repayment table) and baseline time fields from the sample tables (e.g., loan_time or obs_time in the sample table). This step aims to confirm whether time-dimensional slicing logic is explicitly defined in the SQL logic, i.e., whether data is limited to a specific time range.

[0040] Finally, the comparison operators in the time comparison expressions are verified to determine the compliance of the time sequence logic. The system extracts the core comparison operators (e.g., <=, <, >=, >) from the expressions and performs logical inference based on the positional relationships of the fields. The system determines whether the comparison operators represent a time sequence relationship where the time field of the related table is no later than the baseline time of the sample table. Specifically, a valid time sequence constraint should ensure that the time of occurrence of the referenced related table data is earlier than or equal to the observation time of the sample (e.g., t.transaction_time <= s.loan_time). If the system detects a missing comparison operator, an incorrect direction (e.g., using > which leads to referencing future data), or no time comparison expressions involving the baseline time at all, the verification step is deemed to have failed, and the node is marked as having a time sequence travel risk. Through this layered parsing mechanism, the system can accurately intercept SQL statements that, although syntactically correct, logically violate the risk control time sequence principles.

[0041] In this embodiment, by deeply analyzing the hash predicates and filtering predicates in the database execution plan, high-risk operations that "only relate to the user dimension but lack time constraints" can be accurately identified at the execution logic level. Furthermore, by strictly defining the temporal boundaries of the data through verification and comparison operators, it ensures that the data in the related tables is never later than the sample baseline time. This mechanism fundamentally eliminates hidden time-series travel problems, guarantees the logical rigor of the mined risk control features, effectively avoids data leakage during model training, and ensures a high degree of consistency between the model's offline evaluation metrics and its actual online performance.

[0042] Furthermore, in one embodiment, the timing anti-travel verification also includes detection of scenarios involving multiple references to the same data source, specifically including:

[0043] Parse the execution plan tree to identify whether there is logic that performs multiple read operations and joins on the same physical table;

[0044] If it exists, locate the associated operation node involving the physical table and parse whether its association conditions contain a dimension identifier field used to distinguish individuals;

[0045] For association operations that include dimension identifier fields, verify whether there are non-equivalent time series constraints relative to the base time of the sample table, in order to determine whether there is a risk of data confusion across business documents.

[0046] Specifically, after obtaining the execution plan tree of the initial feature extraction SQL statement, the system identifies whether there are multiple reads of the same physical table name by parsing the table scan (SCAN) operation nodes. When the system detects that the SQL logic involves multiple self-joins to the same fact table (such as a transaction log table), it locates the corresponding table join (JOIN) operation node and extracts its hash predicate and filter predicate. First, it analyzes whether the hash predicate contains a dimension field used to identify individual users (such as user_id). Then, it forcibly verifies whether the filter predicate is configured with non-equivalent time-series constraints relative to the sample table's baseline time (such as listing_time) (e.g., requiring historical transaction times to be no later than the observation point time). Through this mechanism, the system can effectively identify the hidden crossover error of "mixing data from different documents for the same user" caused by the failure to perform time slicing on self-joined copies when calculating complex derived indicators such as "maximum consecutive borrowing days in history," thereby ensuring the time-series rigor of feature calculation.

[0047] In this embodiment, by introducing a specific verification method for self-association scenarios, the logical security of complex feature mining is significantly improved. Unlike traditional text matching detection based on regular expressions, this solution directly addresses the data reading path at the database execution plan level. This allows for accurate identification of self-association logic nested within complex subqueries or aliases, fundamentally preventing the "cross-loan data leakage" problem caused by missing dimensional constraints. This semantic-level deep verification ensures that the mined features strictly conform to the causal laws of risk control, effectively avoiding inflated model training metrics due to feature crossing, and guaranteeing the consistency of online and offline model performance. This significantly reduces decision-making risks in financial transactions while improving feature mining efficiency.

[0048] Furthermore, in one embodiment, if the associated table is a user dimension table, then it is verified whether the baseline time field is the sample loan time or the sample application time; if the associated table is a transaction flow fact table, then it is verified whether the time series constraint condition also includes a lower limit constraint on the time window for the time field of the associated table.

[0049] Specifically, the metadata information of the related tables is parsed to identify their table types. When the system determines that the related table is a user-dimensional table (e.g., a user profile table or a static attribute table), the key verification point is to confirm whether the baseline point of the time slice is accurate. The system checks the sample table fields used as cutoff times in the time-series constraints to verify whether the baseline time field is clearly the sample loan time or the sample application time. This step is to prevent the large model from misusing time fields unrelated to the current risk assessment (e.g., using "data entry update time" or "earliest user registration time") as anti-crossover cutoff points, ensuring that the obtained dimension table attributes strictly correspond to the moment when the user initiates the credit transaction.

[0050] Conversely, when the system determines that the associated table is a transaction history table (e.g., a bank statement), the verification focus expands to the integrity of the time window. For such massive amounts of time-series data, constraints preventing data loss (i.e., not later than the application time) alone are insufficient. The system parses the filtering predicates and verifies whether the time-series constraints also include a lower bound constraint on the time window for the time field of the associated table. Specifically, the system searches for an expression that defines the starting point of the time range (e.g., transaction_time >= sample_time - 180 days). If this lower bound constraint is missing, the system will prompt "Missing lower bound of the time window, which may lead to a full table scan," requiring the addition of a time range limit of the last N days or the last M months.

[0051] In this embodiment, by implementing differentiated and fine-grained validation on dimension tables and fact tables, the business accuracy and computational performance of feature engineering are significantly improved. For dimension tables, by forcibly validating the sample loan time or application time as a benchmark, feature distortion caused by incorrect selection of time benchmark points (such as misuse of update time) is avoided. For fact tables, by forcibly validating the lower limit constraint of the time window, the problem of full table scan of the database caused by missing time range restrictions is effectively prevented. This avoids huge waste of computing resources and eliminates noise interference from excessively old historical data. Thus, while ensuring the correctness of feature logic, SQL execution efficiency and model prediction accuracy are greatly improved.

[0052] In one embodiment, the step of validating the initial feature extraction SQL statement based on the validation rules further includes:

[0053] Parse the window function operation nodes in the execution plan tree and verify whether the partition key list of the window function operation nodes contains a unique identifier field for the sample dimension;

[0054] If the partition key list is missing the unique identifier field, the verification is deemed to have failed, and the corresponding node location information is added to the feedback information.

[0055] In one embodiment, the step of validating the initial feature extraction SQL statement based on the validation rules further includes:

[0056] Parse the aggregation operation node in the execution plan tree and verify whether the grouping key list of the aggregation operation node contains the unique identifier field of the sample dimension;

[0057] If the group key list is missing the unique identifier field, the verification is deemed to have failed, and the corresponding node location information is added to the feedback information.

[0058] Specifically, when the system validates the initial feature extraction SQL statement based on validation rules, it also focuses on performing dimensional integrity checks on window functions to prevent data confusion between samples. The system identifies and locates the window function operation nodes (analytic nodes) by parsing the execution plan tree. For example... Figure 4 As shown, window functions are often used to statistically analyze "the user's behavior in the past N loans" during risk control feature calculation. However, if the statistical scope is not limited to the period before the current document, or if different loan documents are not distinguished, a logical error will occur. The system extracts the partition key list (Partition ByKeys) of the node and verifies whether it explicitly contains a unique identifier field for the sample dimension (e.g., loan application ID listing_id or application form ID apply_id). If the system detects that the partition key list is missing the unique identifier field (e.g., partitioning only by user_id), it means that multiple loan documents from the same user at different times will be mixed and calculated within the same window, causing the feature value to not accurately correspond to the current observation sample. In this case, the system determines that the verification has failed and adds the corresponding node location information (e.g., Plan Step ID) and error type ("window function lacks sample primary key partition") to the feedback information.

[0059] Furthermore, such as Figure 5As shown, the system also simultaneously performs dimensional granularity verification on aggregation operations to ensure that the feature calculation results are consistent with the baseline granularity of the sample table. The system extracts the grouping key list (GROUP BY Keys) by parsing the aggregation operation nodes in the execution plan tree. In feature engineering, if the aggregation granularity of subqueries or the final result set is too coarse, it can lead to the loss of sample features. The system verifies whether the grouping key list contains a unique identifier field for the sample dimension. For example, when calculating "device features at the time of this application," if grouping is done only by user ID and not by application ID, all historical application records for that user will be compressed into a single data entry, making it impossible for the model to distinguish the current application from other historical applications. If the grouping key list lacks the unique identifier field, the system determines that the verification has failed and adds the node position information of the aggregation node to the feedback information, prompting the large model to supplement the missing dimension field (e.g., "Please add listing_id to the GROUP BY clause").

[0060] In this embodiment, by performing dimensional integrity checks on window functions and aggregation operations in the execution plan, the common problems of "sample confusion" and "granularity mismatch" in credit risk control scenarios are effectively solved. When dealing with "one-to-many" (one user corresponding to multiple loan orders) data relationships, the existence of unique sample identifier fields (such as application ID) is forcibly checked to ensure that feature calculations are strictly limited to the granularity of "single document," preventing the disordered mixing of historical loan data and current loan data for the same user. This not only ensures the accuracy of feature data but also avoids data row collapse or expansion due to missing dimensions, thereby guaranteeing the independence of model training samples and the effectiveness of features.

[0061] The following table provides specific examples of the verification rules in one embodiment:

[0062] Table 1

[0063] Check rules Decision conditions Problem patterns Correct patterns Window function crossing PARTITION BY clause contains only user_id PARTITION BY user_id PARTITION BY listing_id Aggregation function crossing GROUP BY clause contains only user_id GROUP BY user_id GROUP BY listing_id or GROUP BY user_id, listing_id JOIN operation crossing JOIN condition uses user_id but lacks time constraint ON t.user_id = sample.user_id ON t.user_id = sample.user_id AND t.time < sample.listingtime Execution plan crossing hash_predicates contains sample.user_id but other_predicates lacks time field hash: user_id = user_id and other: none hash: user_id = user_id and other: time < listingtime

[0064] Furthermore, in one embodiment, parsing the aggregate operation node in the execution plan tree specifically includes:

[0065] The text content of the execution plan tree is segmented by line, and the outermost aggregation node in the execution plan tree is located by identifying text lines that do not contain indentation symbols.

[0066] Extract the grouping field declaration from the subsequent text lines of the outermost aggregation node, and check whether the grouping field declaration contains the unique identifier field of the sample dimension.

[0067] Specifically, the system first obtains the text-based explanation plan returned by the database (such as Impala or Hive), and then segments this long text content according to newline characters, converting it into an ordered sequence of text lines. The system traverses this sequence, using regular expressions or string indexing techniques to detect the number of leading whitespace characters (spaces or tabs) in each line of text. In the tree-like display structure of the database execution plan, the indentation depth strictly corresponds to the hierarchical relationship of the operators, where text lines without indentation symbols (Indentation Level=0) represent the root node or top-level operation of the execution plan tree. By identifying these unindented text lines, the system can exclude aggregation operations located inside subqueries that are used to calculate intermediate statistics (such as calculating the historical maximum overdue days for a user dimension in a subquery) in complex execution plans containing multiple AGGREGATE keywords, thereby accurately locating the outermost aggregation node.

[0068] After locking the outermost aggregation node, the system performs a targeted dimensional integrity check to ensure that the final generated feature set meets the document-level granularity requirements. Starting from this unindented aggregation node, the system continues scanning subsequent text lines until it encounters the next operation node identifier. Within this context, the system searches for key lines containing grouping field declarations (usually identified as GROUP BY: or group by keys:) and parses and extracts the subsequent field list. The system compares this list with preset metadata, checking whether the grouping field declarations contain a unique identifier field for the sample dimension (e.g., loan application ID listing_id or application ID apply_id). If the outermost aggregation key list lacks this unique identifier field, the system determines that although the intermediate logic of the SQL may be correct, the final output has suffered dimensional collapse (e.g., incorrectly outputting user granularity instead of document granularity), and generates a "missing aggregation dimension" feedback message to drive correction.

[0069] In this embodiment, a positioning algorithm based on indentation levels is used to accurately locate the outermost aggregation node that determines the final feature granularity by leveraging the text format characteristics of the execution plan, thus eliminating interference from intermediate aggregation operations within the subquery. This not only significantly reduces the false positive rate of the verification algorithm and ensures the relevance of the verification logic, but also guarantees that the final generated feature data strictly conforms to the document granularity requirements of the risk control model, thereby improving the robustness of automated feature engineering.

[0070] Furthermore, in one embodiment, before obtaining the execution plan tree of the initial feature extraction SQL statement in the database, the method further includes:

[0071] The initial feature extraction SQL statement is submitted to the database engine for syntax pre-checking.

[0072] If the database engine returns a syntax error log, the error log is parsed based on a preset syntax error translation rule base to identify the error type and error field;

[0073] The error type and error field are filled into a preset syntax correction prompt template and input as feedback information into the large model to drive the large model to correct the initial feature extraction SQL statement until it passes the syntax pre-check.

[0074] Specifically, to avoid execution plan generation failures due to basic syntax errors, the system performs a syntax pre-check and intelligent repair process before obtaining the execution plan tree. The system submits the initial feature extraction SQL statement generated by the large model to a big data computing engine (such as Impala, Hive, or Spark SQL) for pre-compilation or syntax checking. At this point, if the database engine returns syntax error logs (usually obscure AnalysisException, SemanticException, or Java stack traces), the system does not directly feed these raw logs back to the large model, as the large model often struggles to extract effective correction information from underlying system errors. The system calls a pre-defined syntax error translation rule base, using regular expressions to parse the error logs and accurately identify the error type (such as "field does not exist," "table name ambiguity," "function parameter type mismatch") and the names of the affected fields. Subsequently, the system fills the extracted error type and field information into a pre-defined syntax correction prompt template, constructing a natural language feedback such as "Database error: Field [Field_B] does not exist in table [Table_A]. Please check the metadata and correct it." This feedback is used as context input to the large model, driving it to correct the initial feature extraction SQL statement. This process may repeat until the generated SQL statement passes the syntax pre-check, is successfully compiled by the database and generates an execution plan tree, and then the system enters the subsequent anti-crossing logic verification stage.

[0075] In this embodiment, by introducing a syntax error translation mechanism, the technical challenge of large models struggling to understand the underlying database's raw error logs is effectively addressed. By translating obscure system-level error codes into semantically clear natural language correction instructions, the difficulty for large models to understand problems and self-repair is significantly reduced, greatly improving the SQL syntax pass rate. Simultaneously, using syntax pre-checking as a pre-processing "circuit breaker" step in execution plan parsing can quickly intercept and correct basic spelling or citation errors, improving the overall response speed and stability of the feature mining system.

[0076] In one embodiment, generating feedback information based on the verification results and inputting it into the large model includes:

[0077] Determine the location information of nodes that fail the verification, and extract the table name, field alias, and association key information of the data table involved in the node location information;

[0078] Based on the error type mapping table, the corresponding natural language interpretation template is matched, and the natural language interpretation template contains a standard correction pattern;

[0079] The natural language interpretation template is populated using the table name, field aliases, and association key information of the data table to construct structured prompts containing correction suggestions as feedback information.

[0080] Specifically, the system doesn't simply throw an error message; instead, it deeply analyzes the execution plan tree to determine the location information of the node that failed the verification (e.g., the specific Step ID or operator number). The system further scans the context of that node, extracting the table names, field aliases, and association key information of the data tables involved. For example, when a time-series crossing is detected in a hash join, the system extracts key metadata such as "Table involved: payment_flow, Alias: pf, Association key: user_id".

[0081] Subsequently, a pre-defined error type mapping table is invoked to transform underlying technical metrics into semantic interpretations. This table, built upon extensive historical experience with feature mining failures, maps underlying logical errors (such as "Hash Join Predicate Error" or "Partition Key Missing") into natural language interpretation templates easily understood by the larger model. These templates not only indicate the cause of the error but also include validated standard correction patterns. For example, for time-series errors, the template might be set as: "When joining table {TableName} (alias {Alias}), it was detected that only the user ID was used for the join, leading to future data leakage. Please be sure to add the time constraint '{Alias}.{TimeField}<= {Sample}.{BaseTime}' to the WHERE clause or ON condition." This templated design ensures consistency and professionalism in feedback statements.

[0082] Finally, the system dynamically populates the template using the extracted metadata to construct executable correction instructions. The system uses the table names, field aliases, and association key information to populate the natural language interpretation template, instantiating the abstract template into specific business instructions. For example, the template can be instantiated as: "When associated with the table payment_flow (alias pf)... please add the constraint pf.trans_time <= sample.loan_time". The system constructs the generated text into structured prompts containing correction suggestions and inputs them as feedback information into the large model. This structured feedback mechanism transforms ambiguous logical errors into explicit instructions, thereby driving the large model to accurately correct the erroneous parts while maintaining the original computational logic (such as aggregation methods) until the generated new SQL passes all validations.

[0083] In this embodiment, a "location-mapping-filling" feedback generation mechanism effectively bridges the gap between the underlying database execution plan and the semantic understanding capabilities of the large model. The system transforms obscure execution plan operator errors into natural language instructions containing specific table names, aliases, and standard correction patterns, significantly reducing the difficulty and illusion rate of the large model performing code self-correction. This mechanism ensures the accuracy and executability of the feedback information, enabling the system to efficiently guide the large model out of logical errors without human intervention, significantly improving the success rate of generating complex feature SQL and the efficiency of automated iteration.

[0084] In one embodiment, after the step of determining the target feature extraction SQL statement by ensuring that the generated SQL statement passes the verification, the method further includes:

[0085] Execute the target feature extraction SQL statement to extract feature data, and use the feature data to train the risk control model to obtain the model performance indicators and feature importance list of the risk control model;

[0086] Identify newly added features generated in the current mining round from the feature importance list and determine the ranking position of the newly added features;

[0087] Based on the model performance metrics and the ranking position, feature iteration records are generated, and the feature iteration records are associated with the target feature extraction SQL statements and stored in the feature iteration record library.

[0088] Specifically, such as Figure 6 As shown, once the target feature extraction SQL statement passes all logical checks and is determined to be the final execution version, the system enters the quantitative evaluation and experience accumulation stage of feature effectiveness, which aims to verify the actual business value of the features and accumulate iterative experience.

[0089] The system first submits the identified target feature extraction SQL statements to the big data computing engine to execute the data extraction task. It then associates the extracted feature data with the sample's label data (Label, such as whether it is overdue) to construct a standard training dataset. Using this dataset, the system automatically starts the training process of a risk control model (e.g., XGBoost, LightGBM, or logistic regression). After training, the system obtains key model performance metrics (such as AUC, KS value, or F1-Score) from the model output and extracts a list of model feature importance. The system iterates through this list, comparing feature names to identify newly generated features in the current mining round and determining the ranking of these new features among all features. This step aims to quantitatively measure whether the features generated by the large model have a significant gain compared to the baseline features, thereby objectively determining the effectiveness of this mining task.

[0090] Subsequently, the system generates feature iteration records based on the model performance metrics and ranking positions, and archives them for future reuse. The system integrates the input (prompt strategy), output (target SQL statement), and evaluation results (model metrics and feature ranking (TOPN)) of this task into a complete feature iteration record. To achieve structured knowledge management, the system establishes a strong association between the feature iteration record and the target feature extraction SQL statement, and persistently stores them in the feature iteration record repository. This process marks the end of the closed loop for a single feature mining task and also accumulates valuable data for the system. Regardless of whether the feature performance of this mining is excellent or mediocre, its corresponding record will be indexed in the record repository, serving as a source of contextual knowledge for retrieval augmentation generation (RAG) in subsequent tasks.

[0091] In this embodiment, an automated closed loop of "execution-training-evaluation-storage" is constructed, achieving a complete implementation from code generation to value verification. By quantitatively calculating the ranking position of newly added features, the system can objectively and accurately evaluate the actual business value of features generated by the large model, avoiding the trial-and-error costs of blind deployment. More importantly, by storing the evaluation results in a feature iteration record library in association with SQL statements, each mining task is transformed into the system's long-term memory, laying a solid data foundation for subsequent automated iterations and strategy optimization based on historical experience. This supports the system's continuous self-evolution of feature mining capabilities over long-term operation.

[0092] In one embodiment, the step of generating an initial feature extraction SQL statement containing a sample table and related tables using a large model in response to a risk control feature mining request includes:

[0093] Access the feature iteration record library, read the feature iteration records, and obtain the model performance evaluation metrics of the mined features;

[0094] The feature iteration direction for this round is determined based on the model performance evaluation index. The feature iteration direction includes feature derivation strategies that logically combine and adjust parameters for existing feature sets, or feature expansion strategies that introduce fields and switch themes for uncovered data domains.

[0095] Based on the feature iteration direction, prompt words are constructed to drive the large model to generate initial feature extraction SQL statements that conform to the feature iteration direction.

[0096] Specifically, before generating the initial feature extraction SQL statement, the system executes a strategy planning step based on historical performance feedback to establish the optimal path for feature mining in this round.

[0097] In response to a risk control feature mining request, the system first accesses the feature iteration record library, retrieves and reads historical feature iteration records, and extracts model performance evaluation metrics (such as AUC growth rate or KS index trend) of the mined features. The system performs time-series analysis on the model performance evaluation metrics to assess the performance convergence status of the current feature set. When historical metrics show that the model performance is in a rapidly rising range or has not reached a preset threshold, the system determines the feature iteration direction for this round as a feature derivation strategy. Under this strategy, the system guides the large model to focus on existing high-importance feature sets, performing logical combinations (such as combining numerical features using arithmetic operations) or parameter refinement (such as adjusting the time window slider), aiming to mine the deep value of existing data dimensions.

[0098] Conversely, when historical metrics show that model performance is converging or exhibiting diminishing marginal returns, the system switches its feature iteration direction to a feature expansion strategy. At this point, the system identifies data domains or related tables not covered by the current feature set and determines the operational path for field introduction and topic switching. Based on the determined iteration direction (feature derivation or feature expansion), the system constructs structured prompts containing specific strategy constraints. For example, under the feature expansion strategy, the prompts would explicitly instruct the large model to "ignore the fully utilized transaction dimensions and turn to user behavior logs or external data sources for feature construction." This prompt is input into the large model, driving it to generate initial feature extraction SQL statements that conform to the predetermined iteration direction, thereby achieving a dynamic balance between the depth and breadth of feature mining.

[0099] In this embodiment, by introducing an adaptive strategy planning mechanism based on historical performance metrics, the targeting and convergence efficiency of feature mining are significantly improved. The system abandons the traditional random generation mode and instead dynamically adjusts the mining strategy based on real-time feedback from model performance: during performance growth periods, it fully utilizes the value of existing data through feature derivation; during performance bottleneck periods, it introduces new data gains through feature expansion. This mechanism effectively avoids ineffective searches and wasted computational power in low-value feature spaces, ensuring that large models always perform feature construction on the path with the highest marginal returns, thereby quickly approaching the theoretical limits of model performance with minimal computational cost.

[0100] Furthermore, in one embodiment, if the feature iteration direction is the feature derivation strategy, then the top-ranked head features are extracted, and a preset feature cross template is called to construct a prompt word containing instructions requiring the large model to perform mathematical operations on the head features or a time-series window scaling instruction.

[0101] If the feature iteration direction is the feature expansion strategy, then the currently used field set is determined, candidate fields not included in the used field set are filtered from the data metadata, and prompt words containing logical instructions requiring the large model to generate new features based on the business meaning of the candidate fields are constructed.

[0102] Specifically, a differentiated prompt word construction process can be executed according to the determined iteration direction to finely control the granularity and coverage of feature generation.

[0103] When the system determines that the feature iteration direction is a feature derivation strategy, its execution logic focuses on the deep utilization of high-value features. The system first accesses the latest feature importance list, extracts the top-ranked head features (Top-K Features), and calls a preset feature cross-template. Using the original computational logic of these head features as the base context, the system constructs prompts containing explicit instructions, requiring the large model to perform mathematical operations on the head features (e.g., instructing the large model to divide "total loan amount in the last 30 days" by "number of loans in the last 30 days" to construct the "average amount per loan"), or to execute time-series window scaling instructions (e.g., instructing the large model to keep the computational logic unchanged but adjust the time span parameter in the filtering conditions from "last 7 days" to "last 90 days" to capture long-term risk features). This process iterates logically based on validated high-contribution features, aiming to enhance the expressive power of features through non-linear combinations or parameter tuning.

[0104] Conversely, when the system determines that the feature iteration direction is a feature expansion strategy, its execution logic focuses on exploring uncovered data domains. In this case, the system aims to overcome the information bottleneck of the current feature set and obtain new information gains. The system first scans all currently generated feature extraction SQL, parses and determines the currently used field set. Then, the system traverses the metadata of the data warehouse, calculates the difference between the full field set and the used field set, and filters out candidate fields not included in the used field set (e.g., unused "device sensor data" or "tracking logs"). The system extracts metadata descriptions of these candidate fields (such as field annotations and data types) and constructs prompts containing logical instructions requiring the large model to generate new features based on the business meaning of the candidate fields. For example, the prompt might include, "The field 'device_gyro' has not been used. Please combine it with the risk control business meaning to construct a new feature reflecting the stability of the user's device environment." Through this guided field introduction mechanism, the system drives the large model to cover the unknown feature space.

[0105] In this embodiment, by implementing a differentiated prompt word construction strategy, the path dependency and local optima problems commonly encountered in automated feature engineering are effectively addressed. Under the derivation strategy, by mathematically combining and temporally scaling the head features, the robustness and discriminative power of high-contribution features can be rapidly enhanced. Under the expansion strategy, by calculating field differences and forcibly introducing unused candidate fields, the system can proactively avoid the homogenization tendency of large model generation logic and uncover the potential risk prediction value of long-tail fields. This mechanism, combining "deep optimization" and "breadth coverage," ensures that the feature mining system can maximize the marginal benefits of existing data while continuously introducing new risk dimension gains.

[0106] Furthermore, in one embodiment, determining the feature iteration direction for the current round based on the model performance evaluation index specifically includes:

[0107] Calculate the AUC gain of the currently trained risk control model relative to the baseline model, and execute the preset strategy routing logic based on the AUC gain.

[0108] If the AUC gain value is greater than the preset effective gain threshold, the incremental optimization mode is triggered, and the feature iteration direction is determined as the optimization direction that increases the computational complexity of the existing feature logic or introduces multi-dimensional cross-talk.

[0109] If the AUC gain value is less than or equal to the effective gain threshold for a preset number of consecutive times, or if the ranking of the newly added feature in the feature importance list continues to decline, the topic switching mode is triggered, and the feature iteration direction is determined to abandon the current data domain and switch to the expansion direction of the unexplored field set.

[0110] If the feature iteration record library shows that the AUC gain values ​​of multiple historical features under different themes are all greater than the effective gain threshold, the combinatorial innovation mode is triggered, and the feature iteration direction is determined as a combinatorial direction based on the feature importance fusion of different theme feature logic.

[0111] First, the system sets a clear AUC gain threshold as the basis for policy diversion decisions. The system calculates the AUC gain of the current trained model relative to the baseline model. The system presets a validity threshold of 0.1%: if the AUC gain is greater than 0.1%, the current mining direction is deemed valid, and the system determines the feature iteration direction as a feature derivation strategy; if the gain is greater than 0.2% or 0.3%, it is further marked as a significant gain or a huge gain, and this logical template is prioritized. Conversely, if the AUC gain is less than or equal to 0.1%, or if multiple consecutive iterations are ineffective, the system determines that the current direction has reached a bottleneck and switches the feature iteration direction to a feature expansion strategy.

[0112] If a single feature exhibits robust gain (AUC > 0.1%), the system triggers an incremental optimization mode. The prompt guides the large model to gradually increase complexity while retaining the core logic of the feature, such as introducing a finer time window (e.g., dividing from monthly to weekly) or adding aggregation dimensions, explicitly requiring "further improvement of this feature to maximize its potential and avoid reimplementation." If the system detects that multiple features on different themes in the historical record all show positive gains, it triggers a combinatorial innovation mode. In this case, the prompt guides the large model to focus on feature importance ranking, logically fusing high-importance features from different data sources (e.g., cross-combining "static profile" features with "dynamic behavior" features), aiming to improve the model's performance ceiling through complementary mining.

[0113] When the system detects that a predetermined number of iterations (e.g., 3) have failed to generate effective gains (AUC gain ≤ 0.1%), or that the ranking of new features in the importance list continues to decline, the system determines that the marginal benefits of the current data domain have been exhausted. At this point, the system forcibly executes topic switching logic. The constructed prompt explicitly instructs the large model to "abandon the currently fully explored set of fields" and switch to uncovered candidate fields or related tables (e.g., switching from a transaction table to a log table). The prompt guides the large model to "re-explore new directions starting with simple features," seeking new performance growth points by introducing entirely new business dimensions.

[0114] In this embodiment, an automated decision-making mechanism for feature iteration is established through a quantified AUC gain threshold, enabling intelligent scheduling of two major strategies: "feature derivation" and "feature expansion." Under the derivation strategy, the system progressively optimizes and deeply mines the value of single points, and utilizes multi-dimensional complementarity through combination innovation to maximize the benefits of existing high-scoring features. Under the expansion strategy, the system uses a topic switching mechanism to stop losses in a timely manner, avoiding ineffective computation in an inefficient space. This hierarchical strategy execution framework ensures that the feature mining system can both improve model accuracy and discover new risk dimensions.

[0115] In one embodiment, the step of generating an initial feature extraction SQL statement containing a sample table and related tables using a large model in response to a risk control feature mining request further includes:

[0116] In response to the feature mining request, the semantic features of the request are parsed, and a feature iteration record matching the semantic features is retrieved from the feature iteration record library;

[0117] Extract the computational logic template of historical features and the error type record of historical failed attempts from the matched feature iteration records;

[0118] The computational logic template and the error type record are injected into the SQL generation prompt words as contextual knowledge to guide the large model in generating the initial feature extraction SQL statement.

[0119] Specifically, in response to the feature mining request, the system first uses natural language processing techniques (such as BERT or Embedding models) to parse the semantic features of the request, transforming the unstructured mining requirements into high-dimensional semantic vectors. The system then accesses a feature iteration record library and performs a retrieval operation based on vector similarity to retrieve feature iteration records that match the semantic features. For example, if the request involves "multiple borrowing risks," the system will retrieve historical mining task records that are highly semantically related to "multiple platform applications" and "frequent queries."

[0120] After acquiring the matching records, the system executes a process of extracting key information and constructing prompt words. The system extracts historical feature computational logic templates (i.e., SQL fragments verified as having high feature importance) and error type records of historical failed attempts (e.g., incorrect code that caused time-series errors or inefficient logic that caused memory overflows) from the matched feature iteration records. The system injects the computational logic templates and error type records into the SQL generation prompt words, constructing a composite context containing "few sample examples" and "negative constraints." The computational logic templates serve as positive references, displaying high-quality SQL structures that fit the current scenario to the large model; the error type records serve as warning information, explicitly listing prohibited logical patterns. These prompt words, as contextual knowledge, guide the large model to generate the initial feature extraction SQL statement, ensuring high logical compliance and business effectiveness from the outset.

[0121] In this embodiment, by constructing a prior knowledge injection mechanism based on Retrieval Enhancement (RAG) and reusing historical feature calculation logic templates, the system ensures that newly generated features follow a proven and efficient code structure, guaranteeing the baseline of feature performance. Simultaneously, by introducing error type records from historical failed attempts, it effectively prevents large models from repeatedly committing known logical or syntactic errors. This combined positive and negative avoidance strategy significantly improves the first-pass yield and code quality of the initial feature extraction SQL statements.

[0122] Furthermore, in one embodiment, before generating the initial feature extraction SQL statement containing the sample table and the related table using the large model, the method further includes:

[0123] Obtain the metadata of the sample table and the associated table, and parse all field names and field types contained in the metadata;

[0124] Based on preset field priority classification rules, all fields are divided into key fields that must be retained, high-priority fields sampled proportionally, and low-priority fields that can be filtered; the key fields include at least a primary key identifier field and a time type field.

[0125] Based on the preset large model context window threshold, a target field set is selected from all fields, and only the structural information of the target field set is injected into the prompt words used to generate SQL statements.

[0126] Specifically, before generating the initial feature extraction SQL statement, the system first connects to the data warehouse's metadata management service (e.g., Hive Metastore) to obtain the metadata of the sample table and the related tables, and parses and extracts all field names, field types (e.g., BIGINT, STRING, TIMESTAMP), and field annotation information contained in the tables. Considering that risk control wide tables often contain thousands of dimensions of features, directly inputting the full table structure into a large model would lead to token overflow or attention distraction. Therefore, the system performs hierarchical processing of all fields based on preset field priority classification rules: primary key identifier fields (e.g., user_id, listing_id) and time type fields (e.g., apply_time, trans_time) involved in table joins and time series judgments are marked as key fields that must be retained (P0 level); business fields with high information entropy, such as numerical or enumerable types, are marked as high-priority fields (P1 level); and fields that are too descriptive or have extremely low relevance (e.g., ETL job ID, redundant memo text) are marked as low-priority fields that can be filtered (P2 level).

[0127] Subsequently, the system executes a dynamic filtering process based on context window constraints. The system reads a preset large model context window threshold (e.g., the 8k or 32k token limit for GPT-4) and calculates the static token consumption of the current prompt template. The system prioritizes retaining all P0-level key fields; for P1-level high-priority fields, the system uses a proportional sampling strategy or a greedy selection strategy based on feature importance for truncation; P2-level fields are directly filtered. The system selects the final target field set from all fields and formats this set into a concise DDL (Data Definition Language) description or Markdown table. The system only injects the structural information of the target field set into the prompts used to generate SQL statements, thereby constructing refined prompts that contain core business information and conform to model input length specifications.

[0128] In this embodiment, a priority-based field hierarchical and dynamic filtering mechanism effectively resolves the technical contradiction between ultra-high-dimensional "wide table" data structures and the limited context window of large models. By forcibly retaining primary key and time fields, the generated SQL is ensured to possess basic relational and temporal logic capabilities. By sampling and filtering non-critical fields, input token consumption is significantly reduced while maximizing the retention of high-value business information. This mechanism not only significantly reduces the API cost and inference latency of large model calls, but more importantly, it avoids the attention divergence and illusion problems caused by input information overload, thereby improving the accuracy of SQL generation.

[0129] Furthermore, in one embodiment, generating feature iteration records based on the model performance metrics and the ranking position, associating the feature iteration records with the target feature extraction SQL statements and storing them in a feature iteration record library, further includes:

[0130] Obtain the training result set containing the complete model object and raw feature data;

[0131] Remove the non-serializable model objects and original data frames from the training result set;

[0132] Extract the head feature subset from the feature importance list and identify the newly added feature identifiers in the head feature subset;

[0133] The newly added feature identifier, the header feature subset, and the model performance evaluation metrics are reorganized into lightweight JSON format summary data, and the summary data is stored as the feature iteration record.

[0134] Specifically, after completing model training, the system first obtains the training result set, which includes the complete model objects and raw feature data. This result set typically resides in memory and contains large raw dataframes (such as Pandas or Spark DataFrames, potentially reaching several gigabytes), binary model files (Model Dumps), and complete intermediate computation logs. To avoid directly storing such high-dimensional, unstructured, and redundant data in the knowledge base, the system performs a cleanup operation, removing non-serializable model objects and raw dataframes from the training result set. The system then releases the memory space occupied by these heavy objects, retaining only the evaluation results at the metadata level.

[0135] Subsequently, the system executes a key information extraction and reorganization process. The system accesses the model's feature importance analysis results and extracts a subset of the top features (e.g., Feature6Importance Top-50) from the feature importance list. The system compares the feature names in this subset with the SQL parsing results generated in this round, identifying newly added feature identifiers in the top feature subset, thus clearly distinguishing between "original baseline features" and "effective gain features in this round." Finally, the system reorganizes the newly added feature identifiers, the top feature subset, and the model performance evaluation metrics (e.g., AUC, KS) into lightweight JSON-formatted summary data. This summary data typically occupies only a few kilobytes of space. The system stores this summary data as a feature iteration record and indexes it for quick access by the subsequent Retrieval Enhancement Generation (RAG) module.

[0136] The following is a schematic diagram of the storage structure for feature iteration records:

[0137]

[0138] In this embodiment, by removing non-serializable heavy data and retaining only the header feature subset representing core business value and performance metric summaries, a data compression rate of over 100 times is achieved. This not only significantly reduces the storage pressure on the feature iteration record library but also provides a structured, low-latency contextual data source for subsequent historical experience retrieval (RAG) based on large models, ensuring the long-term sustainability of the system.

[0139] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0140] Furthermore, some embodiments of this application also provide an electronic device. The electronic device can be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device can also be various forms of mobile devices, such as cellular phones, smartphones, wearable devices, and other similar computing devices.

[0141] The electronic device includes: one or more processors; and a memory storing computer program instructions that, when executed, cause the processor to perform the steps of the methods provided in any one or more of the above embodiments. Figure 7 An exemplary structural diagram of the electronic device is disclosed. The electronic device includes one or more processors 1101, a memory 1102, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0142] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103 and output device 1104 may be connected by a bus or other means, as shown in the figure, which is connected by a bus.

[0143] Input device 1103 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 1104 may include a display device, auxiliary lighting device (e.g., LED), and haptic feedback device (e.g., vibration motor). The display device may include, but is not limited to, a liquid crystal display, a light-emitting diode display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0144] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback); and input from the user can be received in any form (e.g., voice input or tactile input).

[0145] In this embodiment, a computer-readable medium stores a computer program / instructions that, when executed by a processor, implement the steps of the methods provided in any one or more of the above embodiments. This computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into that device. The aforementioned computer-readable medium carries one or more computer-readable instructions.

[0146] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0147] The memory 1102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 1102 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1102 may optionally include memory remotely located relative to the processor 1101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0148] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0149] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technologies, read-only optical discs, digital versatile optical discs or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0150] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0151] In the above embodiments, all or part of the implementation can be achieved through software, hardware, firmware, or any combination thereof. For example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the above steps or functions. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. In addition, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0152] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0153] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0154] The scope of this application is defined by the appended claims rather than the foregoing description, and is therefore intended to encompass all variations falling within the meaning and scope of equivalents of the claims. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device in software or hardware. Terms such as "first," "second," etc., are used only for distinguishing descriptions and do not indicate any particular order, nor should they be construed as indicating or implying relative importance.

[0155] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims, and the above embodiments should be regarded as exemplary and non-limiting.

Claims

1. A risk control feature mining method based on a large model, characterized in that, The method includes: In response to the risk control feature mining request, the large model is used to generate the initial feature extraction SQL statement containing the sample table and the related table; Obtain the execution plan tree of the SQL statement extracted from the initial features in the database, parse the table association operation nodes in the execution plan tree, and extract the hash predicate conditions and filtering predicate conditions of the table association operation nodes; The initial feature extraction SQL statement is validated based on the validation rules. The validation includes at least a time-series anti-crossing validation for the table association operation node. The time-series anti-crossing validation includes: when the hash predicate condition contains a user dimension identifier field, verifying whether the filtering predicate condition contains a time field for the associated table and a time-series constraint condition relative to the sample table's baseline time. If the verification fails, feedback information is generated based on the verification result and input into the large model to drive the large model to correct the initial feature extraction SQL statement; The process continues until the generated SQL statement passes the verification, at which point the target feature extraction SQL statement is determined.

2. The method according to claim 1, characterized in that, The step of verifying whether the filtering predicate condition contains a time field relative to the baseline time of the sample table when the hash predicate condition is detected to contain a user dimension identifier field specifically includes: Parse the hash predicate condition and detect whether the hash predicate condition contains a user dimension identifier field; In response to detecting that the hash predicate condition contains the user dimension identifier field, the filtering predicate condition is parsed, and a time comparison expression containing the time field of the association table and the baseline time field of the sample table is extracted; Verify the comparison operator in the time comparison expression to determine whether the comparison operator represents the temporal relationship that the time field of the associated table is no later than the base time of the sample table.

3. The method according to claim 1, characterized in that, The validation of the initial feature extraction SQL statement based on validation rules also includes: Parse the window function operation nodes in the execution plan tree and verify whether the partition key list of the window function operation nodes contains a unique identifier field for the sample dimension; and / or; Parse the aggregation operation node in the execution plan tree and verify whether the grouping key list of the aggregation operation node contains the unique identifier field of the sample dimension; If the partition key list or the group key list is missing the unique identifier field, the verification is deemed to have failed, and the corresponding node location information is added to the feedback information.

4. The method according to any one of claims 1 to 3, characterized in that, The step of generating feedback information based on the verification results and inputting it into the large model includes: Determine the location information of nodes that fail the verification, and extract the table name, field alias, and association key information of the data table involved in the node location information; Based on the error type mapping table, the corresponding natural language interpretation template is matched, and the natural language interpretation template contains a standard correction pattern; The natural language interpretation template is populated using the table name, field aliases, and association key information of the data table to construct structured prompts containing correction suggestions as feedback information.

5. The method according to claim 1, characterized in that, After the step of determining the target feature extraction SQL statement by verifying the generated SQL statement, the method further includes: Execute the target feature extraction SQL statement to extract feature data, and use the feature data to train the risk control model to obtain the model performance indicators and feature importance list of the risk control model; Identify newly added features generated in the current mining round from the feature importance list and determine the ranking position of the newly added features; Based on the model performance metrics and the ranking position, feature iteration records are generated, and the feature iteration records are associated with the target feature extraction SQL statements and stored in the feature iteration record library.

6. The method according to claim 1, characterized in that, The step of generating an initial feature extraction SQL statement containing sample tables and related tables using a large model in response to a risk control feature mining request includes: Access the feature iteration record library, read the feature iteration records, and obtain the model performance evaluation metrics of the mined features; The feature iteration direction for this round is determined based on the model performance evaluation index. The feature iteration direction includes feature derivation strategies that logically combine and adjust parameters for existing feature sets, or feature expansion strategies that introduce fields and switch themes for uncovered data domains. Based on the feature iteration direction, prompt words are constructed to drive the large model to generate initial feature extraction SQL statements that conform to the feature iteration direction.

7. The method according to claim 1, characterized in that, The step of generating an initial feature extraction SQL statement containing a sample table and related tables using a large model in response to a risk control feature mining request further includes: In response to the feature mining request, the semantic features of the request are parsed, and a feature iteration record matching the semantic features is retrieved from the feature iteration record library; Extract the computational logic template of historical features and the error type record of historical failed attempts from the matched feature iteration records; The computational logic template and the error type record are injected into the SQL generation prompt words as contextual knowledge to guide the large model in generating the initial feature extraction SQL statement.

8. An electronic device, characterized in that, The electronic device includes: One or more processors; and A memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method as described in any one of claims 1 to 7.

9. A computer-readable medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 7.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 7.

Images