Intelligent data query method for natural language processing based on intelligent cyclic iteration

Abstract

This invention relates to an intelligent data query method based on intelligent iterative natural language processing. This method constructs a fully configurable rule system by sequentially loading five types of configuration files according to preset priorities: database connection, business rules, business terminology mapping, database table structure, and complex query examples. Upon receiving user natural language query input, it performs scenario judgment and initiates an intelligent iterative mechanism for the triggered scenario. During the iteration, it sequentially executes seven-level priority entity recognition, table association and tenant isolation rule application, standardized SQL statement generation, and multi-dimensional validation of query results. After normal termination of the loop, the results are formatted and output in Markdown table format with attached business interpretation. This invention effectively solves the shortcomings of existing technologies in terms of security, accuracy, and flexibility, achieving multi-tenant isolation, SQL write operation interception, prioritized entity recognition, and automatic calculation of data indicators. It is suitable for complex data query scenarios involving multiple modules in enterprises.

Description

Technical Field

[0001] This invention belongs to the field of natural language processing, database query and artificial intelligence technology, specifically, it relates to a natural language processing intelligent data query method based on intelligent iterative loops. Background Technology

[0002] As enterprises deepen their digital transformation, the demand for database queries using natural language is growing stronger among non-technical personnel. Natural Language to Structured Query Language (NLP) technology aims to automatically convert users' natural language queries into standardized SQL statements, thereby enabling database queries to be completed without requiring specialized SQL knowledge.

[0003] Existing TextToSQL technologies mainly fall into two categories: rule-based technologies, which rely on hard-coded business logic and require modification and redeployment when business scenarios change, resulting in high maintenance costs; and machine learning technologies, which rely on large amounts of labeled data for training and have low accuracy in data-scarce scenarios. Both of these technologies suffer from the following core drawbacks: First, there are insufficient security vulnerabilities. Existing technologies do not implement multi-tenant isolation mechanisms, cannot automatically add tenants and organizational isolation conditions, and are prone to unauthorized data access; they do not strictly restrict SQL write operations, which may generate dangerous statements such as INSERT, UPDATE, DELETE, and DROP; they do not limit the number of rows in the query results, which poses a risk of mass leakage of sensitive data; and they lack SQL injection detection mechanisms.

[0004] Second, accuracy is insufficient. Existing entity recognition technologies do not prioritize entities according to business importance, making it difficult to accurately identify key information such as order numbers and business verbs; SQL generation is not standardized, with no table name restrictions for fields and no automatic addition of Chinese aliases, resulting in poor readability of query results; there is a lack of data indicator linkage capabilities, making it impossible to automatically identify indicator calculation needs and load calculation formulas; and there is no result verification mechanism, leading to frequent instances where queries succeed but the results are inconsistent.

[0005] Third, there is a lack of flexibility. The business logic of the existing technology is hard-coded and cannot be flexibly adjusted through configuration files; when an exception occurs during the query process, parameters cannot be automatically adjusted and retried, requiring manual intervention; cross-module queries rely on manually writing the association logic, which is prone to errors.

[0006] Therefore, existing technologies cannot meet the comprehensive needs of enterprises for data query security, accuracy, and flexibility in multi-tenant, multi-scenario environments. Summary of the Invention

[0007] The purpose of this invention is to overcome the shortcomings of existing TextToSQL technology in terms of security, accuracy and flexibility, and to provide a natural language processing intelligent data query method based on intelligent cyclic iteration. Through the deep integration of a fully configurable rule system and an intelligent cyclic iteration closed-loop mechanism, it can achieve secure, accurate, efficient and flexible enterprise data query.

[0008] The technical solution adopted in this invention is as follows: A natural language processing-based intelligent data query method based on intelligent iterative loops includes the following steps: Initialization configuration loading steps: When the system starts, five types of configuration files are loaded sequentially according to preset priority. The five types of configuration files are: database connection and tenant isolation configuration file, business rule configuration file, business terminology mapping configuration file, database table structure configuration file, and complex query example configuration file. All configuration files support hot updates and can take effect without modifying the core code. User input reception and scenario judgment steps: Receive natural language query input or direct SQL command input from the user, and determine the scenario type of the current input according to the triggering rules in the business rule configuration file; when it is determined to be a triggered scenario, import the input into the intelligent loop iteration process for processing; when it is determined to be a non-triggered scenario, transfer the input to an external interface for processing. Intelligent loop iteration initialization steps: For the triggering scenario, start the intelligent loop iteration mechanism, set the loop termination condition and initialize the loop parameters. The loop termination condition includes normal termination condition and abnormal termination condition. The normal termination condition includes that the query result is valid and meets the indicator requirements. The abnormal termination condition includes that the number of retries reaches the preset limit or the user manually terminates the loop. Establish a loop log to record the execution status and parameter adjustment records of each iteration step. Entity recognition steps: Based on the rules in the configuration file, the entities in the user input are recognized according to the preset priority order, and an entity recognition result set is generated; if there is an abnormality in the recognition result, a loop retry is triggered, the recognition parameters are adjusted and the step is re-executed until the recognition result is valid or the retry limit is reached; Schema validation and field selection steps: Based on the entity recognition result set and database table structure configuration file, the legality of the tables and fields involved is validated, and the query fields are automatically selected according to the preset priority rules to generate a list of fields associated with the table name, and the total number of fields does not exceed the preset limit; if there are abnormalities in the field list, a loop retry is triggered; Rule application steps: Based on the rules in the configuration file, apply table association rules, tenant isolation rules, data indicator rules, and cross-table summary query rules to the entity recognition result set and field list respectively to improve the query conditions and table association logic; among them, the tenant isolation rule is used to automatically add tenant identifier and organization identifier isolation filtering conditions to the query conditions; if there is an exception in the rule application, a loop retry will be triggered; SQL generation steps: Based on the processing results of the preceding steps and combined with SQL generation rules, generate standardized and secure SQL query statements; in the SQL query statements, all fields must be qualified with table names, all fields must be appended with Chinese aliases, business status codes must be converted to Chinese descriptions through conditional branch statements, and query results must be appended with sorting conditions in descending order of creation time and row count limits; generating SQL statements containing write operations is prohibited; after the SQL statement is generated, it undergoes syntax and security checks, and if the checks fail, a loop retry is triggered; SQL execution and result verification steps: Establish a database connection and execute the SQL query statement, and verify the legality, security, and reasonableness of the query results; if execution fails or result verification is abnormal, trigger a loop retry or terminate the loop abnormally according to the exception type. Result formatting and output steps: After the loop terminates normally, the query results are formatted, hiding technical details such as status codes and internal identifiers, and the query results are displayed in Markdown table format. Column names use Chinese business terms, and a brief business interpretation is generated. Both command line output and code call output are supported. Process termination steps: Close the database connection, record the complete log of this query, and complete the entire process.

[0009] Furthermore, in the entity recognition step, the following seven types of recognition are performed sequentially in descending order of priority: Order number recognition (priority level 1), which extracts the order number entity by matching a preset order number prefix; Verb recognition (priority level 2), which identifies business verbs by matching business verb configurations and associating them with the corresponding target tables; Business entity matching (priority level 3), which identifies business entities by matching table names and synonyms according to priority fields in the business term mapping configuration file; Cross-table summary detection (priority level 4), which detects summary keywords in the input and identifies cross-table summary query requirements; Status keyword recognition (priority level 5), which matches business status values ​​to provide a basis for subsequent status code conversion; Condition extraction (priority level 6), which extracts query conditions such as supplier name, customer name, and time range, where the time range is identified through time macro configuration; and Aggregation detection (priority level 7), which detects aggregation keywords and identifies indicator calculation and aggregation query requirements.

[0010] Furthermore, in the schema validation and field selection steps, the query fields are selected according to the following priority order: first, core default fields are selected, including identifier fields, document number fields, status fields, and creation time fields; second, time fields related to the query scenario are selected; third, foreign key fields used for table association are selected; then, amount-related fields are selected; then, remark fields are selected; and finally, custom fields explicitly specified in the user input are selected, with custom fields taking precedence over default fields; the total number of fields does not exceed fifteen.

[0011] Furthermore, in the rule application steps, the table association rules are applied as follows: based on the foreign key fields appearing in the field list, the corresponding left outer join statement is automatically generated to connect the main table with related tables such as the supplier table, customer table, employee table, material table, and warehouse table. All association logic is read from the business term mapping configuration file and does not require manual writing.

[0012] Furthermore, in the SQL generation step, the data indicator calculation formula is embedded in the SQL statement in the following way: when an indicator calculation requirement is identified, the aggregate function configuration of the corresponding indicator is loaded from the business rule configuration file. The aggregate function configuration includes the calculation formula expression, template fields and default field mapping relationships. The calculation formula expression is embedded in the selection list of the SQL statement to realize the automatic calculation of composite indicators such as completion rate, complete set rate, and inventory age. In the calculation formula expression, the denominator is protected by a null value replacement function to avoid division by zero error, and the calculation result is rounded to retain a specified number of decimal places.

[0013] Furthermore, in the result verification step, if the number of query result rows exceeds the preset maximum row limit, the result is truncated to the limit and a warning message is recorded to the user; if the indicator calculation result exceeds a reasonable range, a loop retry is triggered, and the indicator calculation formula or field mapping is adjusted before re-execution; for SQL execution failure error messages, only the technical details are shown to the administrator, and are hidden from ordinary users. Beneficial effects of the invention: 1. Automatically attach multi-tenant isolation conditions through tenant isolation rules to prevent unauthorized data access; strictly prohibit SQL write operations and perform security checks on generated SQL statements to prevent malicious injection and data misoperation; limit the number of rows of query results to prevent the bulk leakage of sensitive data.

[0014] 2. The priority-based entity recognition mechanism can accurately extract key information such as order number, business verb, and business entity; the intelligent loop iteration mechanism can automatically retry abnormal steps and dynamically adjust parameters, significantly improving the query success rate; the data indicator linkage mechanism can automatically identify indicator calculation requirements and load calculation formulas, avoiding errors when manually writing SQL.

[0015] 3. The fully configurable rule system allows all business rules to be adjusted by modifying configuration files without modifying the core code, supports hot configuration updates, and significantly shortens the adaptation cycle for new business scenarios; configurable table association rules enable integrated queries across modules and systems without the need for manual writing of association logic, reducing operation and maintenance costs; multiple input and output methods enable the system to flexibly adapt to the business differences of different industries and enterprises. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is an overall flowchart of the intelligent data query method for natural language processing based on intelligent iterative loops, as described in this invention. Figure 2 This is a block diagram of the intelligent data query system for natural language processing based on intelligent iterative loops, as described in this invention. Detailed Implementation

[0018] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0019] This invention provides a natural language processing-based intelligent data query method based on intelligent iterative loops. Taking data query of multiple modules such as procurement, sales, production, and inventory in an enterprise ERP system as a typical application scenario, it adopts the core technical idea of ​​"deep integration of configuration-driven and intelligent iterative loops" to achieve full-process automation from user natural language input to execution of standardized SQL statements to formatted output of results.

[0020] When the system starts, it loads five types of configuration files in the following priority order. All configuration files are stored in key-value pairs or tree structure, and external modifications are supported and take effect immediately without restarting the system: The first type is the database connection and tenant isolation configuration file, which stores connection parameters such as database host address, port, username, password, and database name, as well as multi-tenant isolation parameters such as tenant identifier and list of organization identifiers. The second category is business rule configuration files, which store core business rules such as trigger scenario rules, entity recognition rules, field selection rules, SQL generation rules, security restriction rules, output format rules, cross-table summary query configuration, aggregate function configuration, verb recognition configuration, and status code mapping configuration. The third category is the business term mapping configuration file, which stores the mapping relationship between business terms and database table names and field names (including synonyms, with each term accompanied by a priority value), as well as inter-table association rules (including association types and association conditions), for accurate entity recognition and cross-module queries; The fourth category is the database table structure configuration file, which stores the complete structure information of all database tables, including table comments, field names, field data types, field comments and primary key information, and is used for schema validation and field selection; The fifth category is the complex query example configuration file, which stores natural language examples of typical complex queries, corresponding SQL examples, and business logic descriptions to assist in entity recognition and SQL generation.

[0021] When loading each type of configuration file, the configuration loading module performs a validity check. If a configuration is missing or the format is incorrect, a warning is immediately issued and the location of the error is indicated. The system will not proceed to the subsequent query process.

[0022] This step accepts two types of user input: one is natural language query (e.g., "query the audit status of purchase receipt CGRK260204002"); the other is direct SQL query command (e.g., query the first few records of a table).

[0023] The system performs scenario judgment on user input based on the trigger rules in the business rule configuration file. The judgment logic is as follows: Triggering scenarios include: complex statistics (multi-table joins, summary analysis), indicator calculation (composite indicators such as completion rate, complete set rate, and inventory age), summary queries (inventory surplus and shortage, inventory inflow and outflow summaries, etc.), custom SQL queries, and cross-module data analysis; inputs belonging to triggering scenarios enter the intelligent loop iteration process.

[0024] Non-triggering scenarios include: write operations (creating, modifying, approving, deleting documents, etc.) and simple queries (single document query, list pagination, etc.). Inputs belonging to non-triggering scenarios are transferred to external interfaces for processing, and the system does not generate SQL for them, thus eliminating the security risks caused by write operations from the source.

[0025] For SQL commands directly entered by the user, the system performs preliminary security checks during the receiving phase. If the system detects that the command contains write operation keywords, it will refuse to execute the command and return an error message.

[0026] In response to the triggering scenario, the system initiates an intelligent loop iteration mechanism to complete the following initialization operations: setting loop termination conditions, including normal termination conditions (valid query results, meeting the reasonableness requirements of indicators, reaching the query row limit) and abnormal termination conditions (the number of retries reaches the preset limit, or the user manually terminates). Initialize loop parameters, including the maximum number of retries (default is three, which can be adjusted through the configuration file), the parameter adjustment rules for each stage during each retry (such as increasing the recognition priority weight of specific entities), and the priority weight of each stage. Establish a circular log structure to record the execution status of each step in each iteration, snapshots of input and output parameters, and parameter adjustment records, which will facilitate subsequent troubleshooting and system optimization.

[0027] This step, based on the rules in the configuration file, performs seven types of entity recognition on the user input in descending order of priority. The specific implementation of each type of recognition is as follows: Level 1 - Order Number Recognition: Using a string prefix matching algorithm, extract strings from user input that meet the preset order number prefix rules (such as numbers starting with prefixes like CGRK, CGDD, XSDD, SO, PO, MO, etc.) and use them as the core query conditions; Level 2 - Verb Recognition: Through regular expression pattern matching, identify business verbs in user input (such as "receive materials", "replenish materials", "return materials", "inbound", "outbound", etc.), and associate the corresponding target database table with the verb recognition configuration in the business rule configuration file; Level 3 - Business Entity Matching: From the term list in the business term mapping configuration file, match terms in descending order of priority value to identify the business entities (such as "purchase order", "inventory", "supplier" etc.) and their corresponding database table names in the user input. Level 4 - Cross-table summary detection: Detects summary-related keywords (such as "summary", "total", etc.) in user input, matches them with cross-table summary query configurations in the business rule configuration file, and identifies cross-table summary query requirements; Level 5 - Status Keyword Recognition: Matches words describing business status (such as "under review", "approved", "in production", etc.) from the status keyword list in the business rule configuration file. The recognition results are used for status code conversion in the subsequent SQL generation stage. Level 6 - Condition Extraction: Extract named query conditions such as supplier name and customer name from user input; for time range conditions, convert natural language time descriptions such as "today" and "last seven days" into specific date range expressions based on the time macro configuration in the business term mapping configuration file; Level 7 - Aggregation Detection: Detects aggregation keywords (such as "summary quantity", "completion rate", "complete set rate", etc.) in user input, matches them with the aggregation function configuration in the business rule configuration file, and identifies scenarios that require indicator calculation or aggregation query.

[0028] After all seven types of identification are completed, the system performs deduplication and conflict verification on the entity identification result set. If no core entity is identified in the result set (e.g., no order number or business entity), or if contradictory entities are identified, it is considered an identification anomaly, triggering a loop retry mechanism. The identification parameters are adjusted (e.g., the priority weight of specific entity types is increased), and this step is re-executed until the result set method or the retry limit is reached.

[0029] This step, based on the entity recognition result set, database table structure configuration file, and field selection rules, performs the following operations: Schema verification: Verify that each table and field involved in the entity recognition result set exists in the database table structure configuration file; if the table does not exist, record a warning message and trigger a loop retry to re-perform entity recognition; if the field does not exist, record a warning message and skip the field to continue to the next step.

[0030] Field selection: Add query fields in the following priority order, with a total number of fields not exceeding fifteen: Priority 1, core default fields: automatically added identifier field (id), document number field (order_no), status field (state), creation time field (create_time), etc.; Priority 2, Time Fields: Automatically add time fields related to the current query scenario, such as in stock time, approval time, and delivery time. Priority 3, Related Fields: Automatically add foreign key fields for table relationships, such as supplier identifier (supplier_id), customer identifier (custom_id), purchaser identifier (purchase_user_id), salesperson identifier (sales_user_id), etc.; Priority level four, amount field: automatically add an amount field (amount) or a total amount field (total_amount), etc.; Priority 5, Remark field: Add a remark field. Priority level six, custom fields: If a user explicitly specifies a particular field in the input, it can be added according to the user's needs. This type of field has the highest priority and can replace the default field of the same level.

[0031] After the fields are selected, the field list is checked for duplicates. If there are duplicate fields or fields that do not exist in the corresponding table structure, a loop retry is triggered.

[0032] This step, based on the configuration file, applies the following four types of rules to the entity recognition result set and field list: Table Association Rules: Based on the foreign key fields appearing in the field list, the corresponding association tables and association conditions are read from the table association configuration in the business term mapping configuration file, and a left outer join statement is automatically generated. Typical association rule examples are as follows: When the query field contains a supplier identifier, the tenant information table is automatically associated, with tenant type as the filter condition; when the query field contains a customer identifier, the customer information table is automatically associated; when the query field contains a purchasing agent identifier or a salesperson identifier, the employee information table is automatically associated; when the query field contains a material identifier, the material information table is automatically associated; when the query field contains a warehouse identifier, the warehouse information table is automatically associated.

[0033] Tenant isolation rules: If a tenant identifier parameter is configured in the database connection and tenant isolation configuration file, a tenant identifier filter condition will be automatically added to the query conditions (limiting the tenant identifier field of the query result to be equal to the tenant identifier value in the configuration file); if an organization identifier list parameter is also configured, an organization range filter condition will be added to the query conditions (limiting the value of the creation organization field of the query result to be within the range of the configured organization identifier list); the above isolation conditions are automatically added without manual intervention, ensuring data isolation in a multi-tenant environment.

[0034] Data Metric Rules: If a metric calculation requirement is detected during the entity identification phase, the calculation formula expression, template fields, and default field mapping relationships for the corresponding metric are read from the aggregation function configuration in the business rule configuration file. These are then associated with the field list to support metric calculations in the subsequent SQL generation phase. Taking the completion rate metric as an example, its calculation formula expression is: Where R is the percentage of completion rate, This is the actual quantity completed field. For the planned production quantity field, the COALESCE function is used to replace null values ​​with zero, the NULLIF function is used to replace zero denominators with null values ​​to avoid division by zero errors, the ROUND function is used to keep two decimal places in the result, and the coefficient 100 is used to convert the ratio to percentage form.

[0035] Cross-table summary query rules: If a cross-table summary query requirement is detected during the entity identification stage, the corresponding query template is read from the cross-table summary query configuration in the business rule configuration file, and the full union query method (UNION ALL) and the sub-query logic of each part are determined to realize the summary query of cross-table data.

[0036] If an error occurs during the application of the rule, such as an error in the associated logic or a missing tenant configuration parameter, a loop retry will be triggered.

[0037] This step generates standardized and secure SQL query statements based on the processing results of the preceding steps and the SQL generation rules in the business rule configuration file. The specific specifications are as follows: Field specifications: All query fields are fully qualified using the format "table_name.field_name" to avoid ambiguity when querying multiple tables; all fields are given Chinese aliases, which are obtained from the field comments in the database table structure configuration file or the business terminology mapping configuration file. Status Transition: Based on the status code mapping configuration in the business rule configuration file, the status field is converted from status code to Chinese business description using a conditional branch statement (CASE WHEN structure) to make the query results conform to the cognitive habits of business personnel; Sorting and row count limits: The SQL statement must include a sorting condition that sorts the data in descending order by the creation time field to ensure that the query results are displayed in chronological order; it must also include a row count limit condition. The default maximum number of rows is 1,000, and the system allows an absolute upper limit of 10,000 rows. Results exceeding the row count will be truncated. Security Restrictions: The system prohibits the generation of statements containing the following write operation keywords in the SQL generation logic: INSERT, UPDATE, DELETE, DROP, TRUNCATE, ALTER, CREATE, REPLACE. After the SQL statement is generated, the system performs the following two checks: syntax check, verifying the structural integrity of the SQL statement; security check, detecting whether the SQL statement contains write operation keywords and whether it contains tenant isolation conditions. If either check fails, a loop retry is triggered, and the SQL generation parameters are adjusted before re-executing this step until a valid SQL statement is generated or the retry limit is reached. Cross-table summary query: If there is a need for cross-table summary query, generate a joint query statement containing a UNIONALL clause according to the cross-table summary query configuration to integrate the query results of multiple tables.

[0038] SQL Execution: Based on the database connection parameters in the database connection and tenant isolation configuration file, establish a database connection and execute SQL statements to obtain query results. If an SQL syntax error or database connection exception occurs during execution, a loop retry is triggered, re-executing the SQL generation steps or re-establishing the database connection.

[0039] Result verification is divided into the following three dimensions: Legality verification: Verify whether the query results match the user's input query requirements, including whether the order number exists in the result set, whether the status value is consistent with the user's description, etc.; at the same time, check whether there are a large number of null values ​​or data format errors in the result set. Security check: Check whether the number of rows in the query results exceeds the preset limit (10,000 rows). If it does, the results will be truncated to the limit value and a warning message will be recorded in the system log. Indicator rationality verification: If there is an indicator calculation requirement, verify whether the calculation result is within a reasonable range (e.g., the completion rate should be between zero and one hundred). If it is not reasonable, trigger a loop retry, adjust the field mapping of the indicator calculation formula, and re-execute.

[0040] Regarding exception handling, the system handles the following typical exceptions based on the error handling configuration in the business rule configuration file: for unrecognized entities, an error message containing the name of the unrecognized entity is returned to the user; for fields that do not exist, the field is skipped and a warning is recorded; for results exceeding the row limit, the results are truncated and the user is notified; for SQL execution failures, a complete technical error message is returned to the administrator, while only a general error message is returned to ordinary users, hiding the technical details.

[0041] After all results verifications pass, the system determines whether the normal termination conditions of the loop are met. If they are met, the loop terminates and the system proceeds to the result formatting step. If the conditions are not met and the number of retries has not reached the upper limit, the system returns to the corresponding abnormal step and re-executes. If the number of retries reaches the upper limit and the conditions are still not met, the loop terminates abnormally and an error message is returned to the user.

[0042] After the loop terminates normally, the query results are formatted as follows: Hiding technical details: Only showing users fields related to business needs, without exposing technical details such as raw state codes, internal database identifiers, and executed SQL statements; Status field processing: Ensure that all status fields have been converted into Chinese business descriptions through the conditional branching statements in the SQL generation phase, and do not display the original status codes to users; Standardized format: The query results are presented in Markdown format tables, and the table column names use Chinese business terms obtained from the database table structure configuration file or business term mapping configuration file. Business Interpretation: Based on the query results, automatically generate one or two brief business interpretations to help users quickly understand the business meaning of the query results; Output method adaptation: Supports two output methods: command line output (suitable for command line call scenarios) and code call output (suitable for secondary development and integration scenarios).

[0043] After the results are output, the system closes the database connection, releases connection resources, and records a complete log of this query. The log includes the user's original input, execution process record, final query result, and a complete record of the loop iteration. The entire TextToSQL intelligent data query process is now complete.

[0044] like Figure 2 As shown, the system involved in this invention adopts a layered modular architecture, which includes the following eight core modules and one auxiliary module. Each module is based on configuration file driving and has no hard-coded business logic: Configuration loading module: implements priority loading, memory storage and legality verification of five types of configuration files, and supports hot update mechanism.

[0045] User input and scenario judgment module: Implements natural language preprocessing (removing spaces, word segmentation, semantic cleaning), scenario matching, and preliminary SQL security verification.

[0046] Intelligent Loop Iteration Control Module (Core Module): Responsible for starting and controlling the intelligent loop iteration mechanism, scheduling the execution order of each functional module, monitoring the execution status of each module, triggering loop retries and dynamically adjusting parameters when an exception occurs, and recording iteration logs.

[0047] Entity recognition module: Implements priority recognition of seven types of entities, result deduplication and conflict verification, and reports anomalies to the intelligent loop iteration control module.

[0048] Schema Validation and Field Selection Module: Implements table structure validity validation, priority field selection and field list verification, and reports exceptions to the intelligent loop iteration control module.

[0049] Rule application module: Implements table association logic generation, tenant isolation condition attachment, data indicator formula loading, and cross-table summary query rule application, and reports anomalies to the intelligent loop iteration control module.

[0050] The SQL generation and execution module generates standardized SQL statements, performs syntax and security checks, manages database connections, reports exceptions to the intelligent loop iteration control module, and closes the database connection after execution. The result validation and formatting module validates the legality, security, and reasonableness of query results, formats the output, and records query logs.

[0051] Data indicator configuration module (auxiliary module): Loads aggregate function configurations and indicator calculation formulas, identifies indicator calculation requirements, verifies the rationality of indicator calculation results, and supports adding or modifying indicator calculation formulas through configuration files.

[0052] Without departing from the core technical solution of this invention, the following alternative embodiments are also within the protection scope of this invention: Firstly, the implementation method is simplified: instead of building a complete intelligent loop iteration mechanism, only the three core links of entity recognition, SQL generation, and security verification are retained, which is suitable for lightweight query scenarios with relatively simple business scenarios and strict limitations on system resources.

[0053] Secondly, alternative entity recognition models: replace the rule matching method in the entity recognition process with a lightweight machine learning model (such as a Naive Bayes classifier or a lightweight pre-trained language model) to improve the recognition accuracy in scenarios with complex business entities and many synonyms.

[0054] Third, configuration file integration method: The five types of configuration files are integrated into two types (basic configuration files and business rule configuration files), which simplifies the configuration and deployment process and is suitable for enterprises with relatively simple business scenarios; at the same time, a visual editing interface for configuration files can be added to lower the configuration threshold for non-technical personnel.

[0055] In the description of this specification, the references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0056] The above description is merely an example and illustration of the concept of the present invention. Those skilled in the art can make various modifications or additions to the specific embodiments described or use similar methods to replace them, as long as they do not deviate from the concept of the invention or exceed the scope defined in the claims, they should all fall within the protection scope of the present invention.

Claims

1. A method for natural language processing intelligent data query based on intelligent cycle iteration, characterized in that, Includes the following steps: Initialization configuration loading steps: Load the configuration file, which includes business rules, business terminology mapping, and database table structure configuration files; User input reception and scenario determination steps: Receive natural language query input or direct SQL command input, and determine whether it belongs to a triggered scenario or a non-triggered scenario based on the business rule configuration file; If it is a triggered scenario, import the intelligent loop iteration process; if it is a non-triggered scenario, execute the preset processing. Intelligent loop iteration initialization steps: For the triggering scenario, set normal termination conditions and abnormal termination conditions, initialize loop parameters and establish loop log; Entity recognition steps: Recognize entities in the input according to a preset priority order to generate an entity recognition result set; if an error occurs, trigger a loop retry. Schema validation and field selection steps: Based on the entity recognition result set and the database table structure configuration file, select query fields in a preset priority order to generate a field list; if an exception occurs, trigger a loop retry. Rule application steps: Apply table association rules and data indicator rules to the entity recognition result set and the field list; if an exception occurs, trigger a loop retry. SQL generation steps: Generate an SQL query statement with additional row count restrictions and security limitations, and validate the SQL query statement. If it fails, trigger a loop retry. SQL execution and result verification steps: Execute the SQL query statement and verify the legality, security and reasonableness of the query results. If any abnormality occurs, trigger a loop retry or terminate abnormally. Result formatting and output steps: After the loop terminates normally, format and output the query results.

2. The method of claim 1, wherein, In the entity recognition step, recognition is performed sequentially according to the following seven priority levels: The first priority level is order number recognition. The string prefix matching algorithm is used to extract strings that meet the preset order number prefix rules as the core query conditions. The second priority level is verb recognition, which identifies business verbs and associates them with the corresponding target database tables through regular expression pattern matching; The third priority level is business entity matching. From the term list in the business term mapping configuration file, the terms are matched sequentially from high to low priority value to identify business entities and their corresponding database table names. The fourth priority level is cross-table summary detection, which detects summary-related keywords in the input and identifies cross-table summary query requirements; The fifth priority level is status keyword recognition, which matches business status values, and the recognition results are used for subsequent status code conversion; The sixth priority level is condition extraction, which extracts query conditions such as supplier name, customer name and time range from the input. The time range is converted into a specific date range expression based on the time macro configuration. The seventh priority level is aggregation detection, which detects aggregated keywords and identifies the needs for indicator calculation and aggregation query.

3. The method of claim 1, wherein, In the schema validation and field selection steps, the query fields are selected according to the following priority order: First priority, core default fields, including identifier field, document number field, status field and creation time field; The second priority is time fields related to the query scenario; The third priority is used for foreign key fields in table joins; Fourth priority: fields related to amount; Fifth priority: Remarks field; The sixth priority is the custom field explicitly specified in the input, which takes precedence over other default fields; The total number of fields shall not exceed fifteen.

4. The method of claim 1, wherein, In the rule application steps, the table association rule is applied as follows: based on the foreign key fields appearing in the field list, the corresponding association tables and association conditions are read from the table association configuration of the business term mapping configuration file, and a left outer join statement is automatically generated to connect the main table with the supplier information table, customer information table, employee information table, material information table, and warehouse information table. All association logic is read from the business term mapping configuration file and does not require manual writing.

5. The method of claim 1, wherein, In the rule application steps, the data indicator rules are applied as follows: when an indicator calculation requirement is identified, the calculation formula expression, template field, and default field mapping relationship of the corresponding indicator are read from the aggregation function configuration of the business rule configuration file, and the calculation formula expression is associated with the field list. In the calculation formula expression, the denominator is protected using a null value substitution function to avoid division by zero errors, and the calculation result is rounded to retain a specified number of decimal places using a rounding function.

6. The method of claim 1, wherein, In the SQL generation step, the specific content of the security restriction is as follows: the generated SQL query statement is prohibited from containing any of the write operation keywords INSERT, UPDATE, DELETE, DROP, TRUNCATE, ALTER, CREATE, or REPLACE; for the direct SQL instruction input, if it contains the above write operation keywords, it will be directly rejected and an error message will be returned, and it will not proceed to the subsequent execution steps.

7. The method of claim 1, wherein, In the SQL execution and result verification steps, the specific content of the security verification is as follows: verify whether the number of rows in the query result exceeds the preset maximum number of rows, which is 10,000 rows; if it exceeds the limit, the result will be truncated to the upper limit value, a warning message will be recorded in the system log, and a truncation prompt will be returned to the user. The default value for the row count limit condition attached to the SQL query statement is one thousand rows.

8. The method of claim 1, wherein, In the result formatting and output steps, two output methods are supported: command line output and code call output. The content displayed to the user does not include the original value of the status code, the database internal identifier, or the executed SQL query statement. The values ​​of all status fields are displayed in the form of Chinese business descriptions. The query results are accompanied by one or two sentences of business interpretation automatically generated based on the result content.

9. The method of claim 1, wherein, In the intelligent loop iteration initialization step, the normal termination condition includes that the query result is valid and meets the indicator rationality requirements; the abnormal termination condition includes that the number of retries reaches the preset limit or the user manually terminates; the loop parameters include the maximum number of retries, the parameter adjustment rules of each stage during each retry, and the priority weight of each stage; the loop log records the execution status of each stage, the snapshot of input and output parameters, and the parameter adjustment record in each iteration.

10. The method of claim 1, wherein, In the user input receiving and scenario judgment steps, the triggering scenarios include complex statistics, indicator calculation, summary query, custom SQL query, and cross-module data analysis; the non-triggering scenarios include write operations and simple queries; for the direct SQL command input, a preliminary security check is performed during the receiving stage, and if the keyword for write operation is detected, execution is directly rejected and an error message is returned.

Images