Data script automatic generation method and system based on multi-round dialogue intent recognition
Patent Information
- Application Number
- CN202611139686.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-30
- Publication Date
- 2026-09-29
AI Technical Summary
[0004]本发明提供了基于多轮对话意图识别的数据脚本自动生成方法及系统,用于解决现有数据脚本生成方法无法基于自然语言多轮对话进行意图理解并自动生成可执行的数据库脚本的技术问题
第一,本发明通过对当前轮次对话指令和历史对话状态信息进行多轮对话状态下的意图识别与槽位填充,将当前轮次信息与历史对话状态信息进行逐项比对,信息互补时追加、语义冲突时以当前轮次覆盖历史记录,与现有方法仅支持单轮对话相比,能够正确处理多轮对话中的查询条件补充和修正,生成包含操作类型、目标实体、时间范围、过滤条件和逻辑嵌套关系的结构化查询要素。
Smart Images

Figure CN122838432A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of semantic analysis and automatic script generation technology, specifically to a method and system for automatic data script generation based on multi-turn dialogue intent recognition. Background Technology
[0002] In data analysis and database management scenarios, business users frequently need to query and retrieve data from databases. Since business users typically lack the ability to write database query languages, they must submit their requirements to technical personnel, who then manually write the database query scripts after understanding the requirements. This communication model is inefficient, prone to misunderstandings during the requirement transmission process, resulting in scripts that do not match the actual needs of the business users.
[0003] Existing technologies support generating query scripts directly from natural language, but they typically only handle single inputs, requiring users to describe all query conditions completely at once. In real-world business scenarios, user needs are often defined progressively, and existing technologies cannot support multi-round interactions; users must re-enter the complete information when adding or modifying conditions. Furthermore, there are differences between business terminology used by business personnel and the technical table and field names in the database. Existing tools often rely on fixed mapping tables for conversion, leading to inaccuracies in the accuracy of table and field names in the generated scripts. Summary of the Invention
[0004] This invention provides a method and system for automatically generating data scripts based on multi-turn dialogue intent recognition, which solves the technical problem that existing data script generation methods cannot understand intents based on natural language multi-turn dialogue and automatically generate executable database scripts.
[0005] In a first aspect, the present invention provides a method for automatically generating data scripts based on multi-turn dialogue intent recognition, the method comprising: S10: Receive the current round of dialogue instructions input by the user in natural language form through the interactive interface, and obtain historical dialogue status information; S20: Based on the current round dialogue instruction and the historical dialogue state information, perform intent recognition and slot filling for the current round dialogue instruction under multi-round dialogue state, and generate structured query elements for the current round; S30: Based on the structured query elements, retrieve the database table structure information and field mapping information associated with the structured query elements from the pre-built domain knowledge graph; S40: Input the structured query elements, the database table structure information, and the field mapping information into the pre-trained data script generation model to generate a data script draft; S50: Verify the draft data script. If the verification passes, output the draft data script as the final data script. If the verification fails, generate error correction information and iteratively execute steps S10 to S40 until the verification passes and the final data script is output, thus completing the automatic generation of the data script.
[0006] Secondly, the present invention also provides an automatic data script generation system based on multi-turn dialogue intent recognition, the system comprising: The dialogue interaction module is used to receive the current round of dialogue instructions input by the user in natural language form through the interactive interface, and to obtain historical dialogue status information. The intent recognition module is used to perform intent recognition and slot filling for the current round of dialogue instructions in multi-round dialogue states based on the current round of dialogue instructions and the historical dialogue state information, and generate structured query elements for the current round. The knowledge retrieval module is used to retrieve database table structure information and field mapping information associated with the structured query elements from a pre-built domain knowledge graph based on the structured query elements. The script generation module is used to input the structured query elements, the database table structure information, and the field mapping information into a pre-trained data script generation model to generate a data script draft; The script verification module is used to verify the draft data script. If the verification passes, the draft data script is output as the final data script. If the verification fails, error correction prompts are generated and the dialogue interaction module is iteratively executed to the script verification module until the verification passes and the final data script is output, thus completing the automatic generation of the data script.
[0007] One or more technical solutions provided in this invention have at least the following technical effects or advantages: First, this invention performs intent recognition and slot filling in multi-turn dialogue states by comparing the current turn dialogue command and historical dialogue state information item by item. When the information is complementary, it adds information and when there is a semantic conflict, it overwrites the historical records with the current turn. Compared with existing methods that only support single-turn dialogue, this invention can correctly handle the supplementation and correction of query conditions in multi-turn dialogues and generate structured query elements that include operation type, target entity, time range, filtering conditions and logical nesting relationships.
[0008] Secondly, by retrieving database table structure information and field mapping information associated with structured query elements from a pre-built domain knowledge graph, this invention can automatically map the user's business concepts to accurate database table names and field names, compared to existing methods that do not combine domain knowledge graphs for retrieval, thus improving the accuracy of the generated script.
[0009] Third, this invention verifies the data script draft by executing it in a sandbox environment, compares the returned data with the expected execution result characteristics, generates error correction prompts and triggers iterative execution when the verification fails. Compared with existing methods that lack a verification feedback mechanism, this invention can automatically detect and correct errors in script generation, thus improving the reliability of the final output script. Attached Figure Description
[0010] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0011] Figure 1 This is a flowchart illustrating the automatic data script generation method based on multi-turn dialogue intent recognition provided in an embodiment of the present invention. Figure 2 This is a schematic diagram of the automatic data script generation method based on multi-turn dialogue intent recognition provided in this embodiment of the invention. Figure 3 This is a multi-turn dialogue example data table diagram provided by the embodiment of the present invention for the automatic generation method of data script based on multi-turn dialogue intent recognition; Figure 4 This is a structural diagram of the data script automatic generation system based on multi-turn dialogue intent recognition provided in this embodiment of the invention; The diagram is labeled as follows: Dialogue Interaction Module 11, Intent Recognition Module 12, Knowledge Retrieval Module 13, Script Generation Module 14, and Script Verification Module 15. Detailed Implementation
[0012] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.
[0013] Example 1, as Figure 1 As shown, this invention provides a flowchart illustrating a method for automatically generating data scripts based on multi-turn dialogue intent recognition; as... Figure 2 As shown, this invention provides a scheme logic diagram for an automatic data script generation method based on multi-turn dialogue intent recognition. The method includes: S10: Receive the current round of dialogue instructions input by the user in natural language form through the interactive interface, and obtain historical dialogue status information; In multi-turn dialogue scenarios automatically generated by data scripts, users gradually clarify their query needs through successive rounds of dialogue. The dialogue command in the current round may contain new query conditions, or it may supplement or modify the conditions proposed in previous rounds. If only the dialogue command in the current round is parsed independently, detached from the confirmed intent tags, filled slot key-value pairs, and confirmed logical conditions in the previous dialogues, the parsing result of this round will be disconnected from the context of the previous dialogues, and will be unable to accurately capture the continuation and changes of the user's intent across rounds of dialogue.
[0014] Step S10 provided in this embodiment of the invention includes: The current round of dialogue instructions are received through the interactive interface, and the current round of dialogue text is obtained. Obtain historical dialogue status information, which includes parsed intent tags, filled slot key-value pairs, and confirmed logical conditions in historical rounds. The slot key-value pairs include at least one or more of the following: indicator slots, time range slots, region slots, entity object slots, and operation type slots.
[0015] The specific implementation method is as follows: The interactive interface is a conversational input interface deployed on the user terminal, allowing users to input data query requirements in the form of natural language text. The user types the current round of dialogue command in the input box of the interactive interface and submits it. The interactive interface then sends the text content entered by the user as the current round of dialogue command to the dialogue management service, obtaining the current round of dialogue text.
[0016] The dialogue management service also retrieves historical dialogue state information from the dialogue state storage module. At the end of each dialogue round, the dialogue state storage module updates and persists the structured query elements for that round, including the intent tags, slot key-value pairs, and logical conditions parsed in that round. Historical dialogue state information includes all parsed intent tags, filled slot key-value pairs, and confirmed logical conditions from the first round to the previous round in this dialogue session.
[0017] The slots in the key-value pairs are divided into five categories according to business semantics: indicator slots, corresponding to the statistical indicators queried, such as sales revenue, profit margin, and order volume; time range slots, corresponding to the time interval queried, such as the first quarter of 2024 or the last 30 days; region slots, corresponding to the geographical scope queried, such as East China or Beijing; entity object slots, corresponding to the target entity queried, such as product A or supplier B; and operation type slots, corresponding to the operation method queried, such as summary, detailed query, and ranking. Each populated key-value pair consists of three parts: slot category, slot name, and slot value.
[0018] The storage format for historical dialogue status information is a serialized record organized by round. Each record contains the intent tag for that round, all key-value pairs of slots filled in that round, and the logical conditions parsed from that round. The logical conditions record the explicit filtering conditions in the dialogue of that round, such as the single condition "sales revenue greater than 1 million" or nested conditions "(region = East China and sales revenue greater than 1 million) or (region = North China and sales revenue greater than 500,000)".
[0019] For example, the user has completed two rounds of input in the current conversation. The first round of input, "Query sales figures for East China in the first quarter of 2024," was parsed to an intent tag of "sales data query," and the filled slot key-value pairs included a time range slot with the value "first quarter of 2024," a region slot with the value "East China," and an indicator slot with the value "sales figures." The second round of input, "Only view sales figures greater than 1 million," was parsed to an intent tag of "adding a filter condition," and the filled slot key-value pairs did not add any new entity slots, but the logical condition "sales figures greater than 1 million" was extracted. The historical conversation state information from both rounds is stored and available for retrieval in the current round.
[0020] The following technical effects were achieved through this step: The system uniformly receives the current round of dialogue text and obtains complete historical dialogue state information, summarizing the contextual information of the dialogue to provide a complete multi-round dialogue context for subsequent intent recognition and slot filling. Slots are categorized and managed according to indicators, time ranges, regions, entity objects, and operation types, ensuring that the query elements already filled in the dialogue state are stored in an orderly manner, facilitating comparison and updates with newly extracted slots in the current round.
[0021] S20: Based on the current round dialogue instruction and the historical dialogue state information, perform intent recognition and slot filling for the current round dialogue instruction under multi-round dialogue state, and generate structured query elements for the current round; User expressions in multi-turn dialogues exhibit continuity and progression: the current turn may be a further refinement of the conditions already established in previous turns, or it may be a modification or expansion of those conditions. If only the intent of the current turn is identified independently, ignoring the intents and slots accumulated in historical dialogues, it will be impossible to determine whether the current turn and historical turns are complementary or conflicting.
[0022] Step S20 provided in this embodiment of the invention includes: The current round dialogue instruction is input into a pre-trained domain adaptive semantic understanding model. The domain adaptive semantic understanding model performs intent classification on the current round dialogue instruction and identifies the current round intent label corresponding to the current round dialogue instruction. Based on the current round intent tag, fill the slots for the current round dialogue instruction and extract the current round slot key-value pairs associated with the current round intent tag; Based on the current round intent tag and the current round slot key-value pair, the current round logical conditions implied in the current round dialogue instruction are parsed, wherein the current round logical conditions include single-condition logical relations or multi-condition nested logical relations connected by logical connectors; Based on the historical dialogue status information, the current round intent tag, the current round slot key-value pair, and the current round logical condition are updated with the parsed intent tag, filled slot key-value pair, and confirmed logical condition in the historical dialogue status information to generate the structured query elements for the current round.
[0023] The current round intent tag, the current round slot key-value pair, and the current round logical condition are compared item by item with the parsed intent tags, filled slot key-value pairs, and confirmed logical conditions in the historical dialogue state information. When the information items in the current round intent tag, the current round slot key-value pair, and the current round logical condition do not have corresponding historical information records in the historical dialogue state information, it is determined that the information is complementary, and the current round intent tag, the current round slot key-value pair, and the current round logical condition are added to the historical dialogue state information to obtain the updated historical dialogue state information; When the information items in the current round intent tag, the current round slot key-value pair, and the current round logical condition have corresponding historical information records in the historical dialogue state information and the information values are different, it is determined to be a semantic conflict. The current round intent tag, the current round slot key-value pair, and the current round logical condition are used to overwrite the corresponding historical information records in the historical dialogue state information to obtain updated historical dialogue state information. The structured query elements for the current round are generated based on the updated historical dialogue status information. The structured query elements for the current round include at least the operation type, target entity, time range, filtering conditions, and logical nesting relationships.
[0024] The specific implementation method is as follows: The current round of dialogue instructions is input into a pre-trained domain-adaptive semantic understanding model. This model is a neural network used for semantic parsing of single-round dialogue text in multi-round dialogue scenarios. The input to the domain-adaptive semantic understanding model is the current round of dialogue text, and the output includes three parts: the current round intent label, representing the business intent category of the query in this round; the current round slot key-value pairs, representing the various types of slots extracted from the current round of dialogue text and their values; and the current round logical conditions, representing the implicit filtering condition logical expressions in the current round of dialogue text.
[0025] The pre-trained domain-adaptive semantic understanding model is obtained through domain-adaptive pre-training on the BERT model. The BERT model is a bidirectional encoder representation model based on the Transformer architecture, which has been pre-trained on a large-scale general corpus and possesses general language understanding capabilities. This embodiment uses the open-source BERT model as the initial semantic understanding model. Based on this initial semantic understanding model, domain-adaptive pre-training is performed using marketing domain corpora to enhance the initial semantic understanding model's ability to understand marketing domain terminology and business expression habits, resulting in the pre-trained domain-adaptive semantic understanding model.
[0026] The pre-training process of the domain-adaptive semantic understanding model is as follows: The first step is to construct a domain-specific corpus dataset. This involves collecting historical text data generated during marketing operations. This historical text data includes data governance work orders submitted by local governments, marketing operation manuals and rule documents, and natural language descriptions of requirements corresponding to historical data scripts. The collected historical text data is then cleaned, removing invalid characters and redundant spaces, and standardizing terminology. This cleaned historical text data is then used as the domain-specific corpus dataset.
[0027] The second step is to construct a domain lexicon. The text in the domain corpus dataset is segmented, and marketing-related professional terms and core vocabulary are extracted from the segmentation results. These professional terms and core vocabulary include business entity names, indicator names, and operation names. The extracted professional terms and core vocabulary are then compiled into a domain lexicon. This domain lexicon is used during pre-training to identify the domain vocabulary that the initial semantic understanding model needs to focus on learning.
[0028] The third step is to construct training samples. Text sequences are extracted from the domain corpus dataset as training samples. For each training sample, a portion of domain words are selected from the domain vocabulary according to a preset masking ratio and masked. The selected domain words are then replaced with masked markers to obtain the masked training sample.
[0029] The fourth step is to pre-train the initial semantic understanding model. The masked training samples are input into the initial semantic understanding model, which then predicts the probability distribution of each masked position in the training samples, indicating whether that position belongs to any word in the domain vocabulary. The cross-entropy loss between the predictions from the initial semantic understanding model and the masked real-world domain words is calculated. The parameters of the initial semantic understanding model are continuously updated with the goal of minimizing this cross-entropy loss, until the cross-entropy loss converges or a predetermined number of training epochs are reached. Training then stops, resulting in a pre-trained domain-adaptive semantic understanding model.
[0030] Optionally, the pre-trained domain-adaptive semantic understanding model can be fine-tuned on downstream tasks. Downstream tasks include intent classification and slot filling. The intent classification task identifies the current-round intent label corresponding to the user's current-round dialogue command, while the slot filling task extracts the current-round slot key-value pairs associated with the current-round intent label from the current-round dialogue command. Through domain-adaptive pre-training and downstream task fine-tuning, the pre-trained domain-adaptive semantic understanding model can accurately understand natural language commands in the marketing domain, providing a semantic understanding foundation for subsequently generating structured query elements for the current round.
[0031] Then, based on the intent tag of the current round, slots are filled for the dialogue instructions of the current round. Slot filling uses sequence labeling, labeling each word in the text with its corresponding slot type. The set of slot types associated with the intent tag of the current round is determined by the intent-slot association configuration, which is automatically learned from the labeled data during the training phase of the domain-adaptive semantic understanding model.
[0032] Based on the current round's intent tag and slot key-value pair, the implicit logical conditions of the current round's dialogue instructions are parsed. The parsing method involves identifying words and phrases representing conditional relationships from the dialogue text and converting them into structured logical expressions. Logical connectives include AND, OR, and NOT, corresponding to conjunction, disjunction, and negation relations between conditions, respectively. When the dialogue text contains nested conditions, the logical condition parsing layer outputs a tree-structured conditional expression, where internal branch nodes are logical connectives and leaf nodes are single conditions.
[0033] Furthermore, the intent tag, slot key-value pair, and logical condition of the current round are compared item by item with the parsed intent tags, filled slot key-value pairs, and confirmed logical conditions in the historical dialogue state information. The item-by-item comparison is performed separately for the three categories of intent tags, slot key-value pairs, and logical conditions.
[0034] For intent tags, the current round's intent tag is compared with the latest round's intent tag in the historical dialogue state information. If the current round's intent tag is not recorded in the historical dialogue state information, it is considered complementary, and the current round's intent tag is appended to the intent tag sequence. If the current round's intent tag is the same as the latest historical intent tag, and the historical intent tag's operation type is an overridable type, it is considered a semantic conflict, and the current round's intent tag overwrites the historical intent tag. The method for determining overridable types is: a preset intent tag overriding rule table defines whether each intent tag is allowed to be overridden by the same type of intent tag in the current round. For example, data query type intent tags cannot be overridden, and the sorting method specifies that type intent tags can be overridden.
[0035] For slot key-value pairs, each slot key-value pair extracted in the current round is compared with all filled slot key-value pairs in the historical dialogue state information. The comparison method is as follows: match one by one by slot category. When a slot key-value pair of a certain category does not exist in the history, it is determined to be complementary, and the slot key-value pair is appended to the history. When a slot key-value pair of a certain category already exists in the history but has a different value, it is determined to be semantically conflicting, and the slot value of the current round overwrites the corresponding slot value in the history. When a slot key-value pair of a certain category already exists in the history and has the same value, no update is made. For example, if the historical dialogue state information already has a region category slot value of East China, and the current round's region category slot value is North China, it is determined to be semantically conflicting, and North China overwrites East China. If the historical dialogue state information does not have a time range category slot, but the current round extracts a time range category slot value of Q1 2024, it is determined to be complementary, and it is appended to the history.
[0036] For logical conditions, the logical conditions extracted in the current round are compared with the confirmed logical conditions in the historical dialogue state information. The comparison method is as follows: if there is no logical condition record in the historical dialogue state information, it is determined that the information is complementary, and the logical condition of the current round is appended to the history record. If there is a logical condition record in the historical dialogue state information, the condition judgment objects involved in the two logical condition expressions are compared. When the condition judgment objects involved in the two logical condition expressions are the same, it is determined that there is a semantic conflict, and the logical condition of the current round overrides the corresponding logical condition in the history record. When the condition judgment objects involved in the two logical condition expressions are different, it is determined that the information is complementary, and the logical condition of the current round is appended to the historical logical conditions through logical connectors.
[0037] For example, if the historical logical condition is sales amount greater than 500,000, and the current round's logical condition is sales amount greater than 1,000,000, both conditions involve sales amount as the judgment object, it is determined to be a semantic conflict, and the condition of sales amount greater than 1,000,000 is used to cover sales amount greater than 500,000. Alternatively, if the historical logical condition is that the region is equal to East China, and the current round's logical condition is that sales amount greater than 1,000, the two conditions involve different judgment objects, and it is determined to be complementary information, generating a merged logical condition of region equal to East China and sales amount greater than 1,000,000.
[0038] The structured query elements for the current round are generated based on the updated historical dialogue state information. Each structured query element contains at least five fields: Operation Type, mapped from the updated intent tags, representing the data operation the user expects to perform, such as summary query, detailed query, or ranking query; Target Entity, determined by entity object class slot key-value pairs, representing the data object being queried; Time Range, determined by time range class slot key-value pairs, representing the time interval for the query; Filtering Conditions, determined by the updated logical conditions, representing the filtering conditions for the query; and Logical Nesting Relationship, determined by the logical connectors between conditions in the updated logical conditions, representing the conjunction, disjunction, or negation relationships between multiple conditions.
[0039] For example, Figure 3 This is a multi-turn dialogue example data table diagram provided by the embodiment of the present invention, which shows the process by which a user gradually clarifies their data query needs through three rounds of dialogue in the interactive interface, as well as the intent recognition, slot filling and status update results corresponding to each round of dialogue.
[0040] The following technical effects were achieved through this step: The domain-adaptive semantic understanding model for the current round of dialogue text input is subjected to unified intent classification, slot filling and logical condition parsing. After extracting deep semantic features through the text encoding layer, the domain-adaptive semantic understanding model outputs three types of structured information. Compared with existing methods that only rely on keyword matching or fixed templates, it can more accurately understand the user's natural language expression.
[0041] The current round parsing results are compared item by item with the historical dialogue state information. The dialogue state is updated according to the rules of information complementarity addition and semantic conflict coverage. Compared with the existing methods that only process single-round input, it can correctly handle various scenarios in multi-round dialogues where users supplement, correct or change query conditions, so that the final generated structured query elements fully reflect the query intent expressed by the user in all rounds.
[0042] S30: Based on the structured query elements, retrieve the database table structure information and field mapping information associated with the structured query elements from the pre-built domain knowledge graph; In the database, the data storage structure uses technical table names and field names that differ from the business terms used by users. For example, "sales revenue" in a user description might correspond to the "sale_amount" field in a database table, and "customer" might correspond to the "customer_info" or "client_data" table. If only fixed mapping tables or simple string matching are used to convert business terms to database fields, the correct table and field names cannot be accurately identified when there is no direct word-for-word correspondence between the business terms and database fields. It is important to note that there is a many-to-many mapping relationship between target entity text and business concept nodes. This embodiment uses a multi-layered mechanism, including edit distance initial screening, historical mapping frequency weighting, operation type matching secondary screening, and sandbox verification, to map and match the natural language target entities input by the user with predefined business concept nodes in the knowledge graph, ultimately accurately determining the mapping relationship.
[0043] Step S30 provided in this embodiment of the invention includes: Extract the target entity and operation type from the structured query elements, wherein the target entity is the value of the target entity field and the operation type is the value of the operation type field; Using the target entity as the retrieval condition, database table nodes that match the target entity are retrieved from the pre-constructed domain knowledge graph to form a candidate database table node set; Based on the operation type, select database table nodes that match the operation type from the candidate database table node set to obtain the target database table node; Database table structure information is extracted from the target database table node, and field mapping information is extracted from the mapping relationship between the target database table node and the target entity. The database table structure information includes at least the table name, field name, field data type, and primary and foreign key relationships. The field mapping information includes at least the correspondence between the attributes of the target entity and each field in the database table structure information.
[0044] The pre-construction process of the domain knowledge graph includes: Collect multi-source heterogeneous data, which includes structured data and unstructured data. The structured data includes at least database metadata, which includes table name, field name, field data type, primary and foreign key relationship, and field constraints. The unstructured data includes at least business rule documents, historical work order text, and historical data scripts. The historical data script is parsed to extract the table names and field names used in the historical data script. The business intent description of the historical data script is extracted by associating it with the historical work order text corresponding to the historical data script, forming a script-table field usage mapping record. The structured data, the business rule document, the historical work order text, and the script-table fields are semantically aligned and fused using mapping records. The business entities in the unstructured data are associated with the database table fields in the structured data, establishing a correspondence between business concepts and the physical structure of the database, and thus obtaining fused knowledge units. Based on the fused knowledge units, a domain knowledge graph is constructed. The domain knowledge graph includes business concept nodes, database table structure nodes, field nodes, as well as mapping relationship edges between the business concept nodes and the database table structure nodes, and inclusion relationship edges between the database table structure nodes and the field nodes.
[0045] The specific implementation method is as follows: First, extract the target entity and operation type from the structured query elements generated in step S20 for the current round. The target entity is the value of the target entity field in the structured query element, representing the business object queried by the user. The operation type is the value of the operation type field in the structured query element, representing the data operation the user expects to perform.
[0046] Then, using the target entity as the search condition, database table nodes matching the target entity are retrieved from the pre-built domain knowledge graph. The domain knowledge graph contains two core node types: business concept nodes and database table structure nodes, connected by mapping edges. The retrieval method involves calculating the text similarity between the target entity's text and the names of each business concept node in the domain knowledge graph. Text similarity is calculated using edit distance similarity, where edit distance similarity = 1 - edit distance ÷ the length of the longer text. Edit distance refers to the minimum number of single-character editing operations required to convert one string to another, including insertion, deletion, and replacement. The smaller the edit distance, the closer the edit distance similarity is to 1, indicating greater similarity between the two texts. For example, if the target entity text is "sales amount", the business concept node name is "sales amount", the edit distance is 1, and the longer text "sales amount" has a length of 4, the edit distance similarity is 1 - 1 ÷ 4 = 0.75. The target entity text is "customer", the business concept node name is "supplier", the edit distance is 3, the length of the longer text "supplier" is 3, and the edit distance similarity = 1 - 3 ÷ 3 = 0.
[0047] Business concept nodes with edit distance similarity greater than or equal to a preset similarity threshold are selected as matched business concept nodes. The preset similarity threshold is determined as follows: All business concept nodes in the domain knowledge graph are obtained; the edit distance similarity between each pair of business concept node names is calculated; and the arithmetic mean of all edit distance similarities is taken as the preset similarity threshold. The arithmetic mean represents the average similarity level between two randomly selected business concept node names. Using this value as the threshold ensures that the similarity between the matched business concept node and the target entity is higher than the average similarity in the graph. For example, if there are 120 business concept nodes in the domain knowledge graph, the arithmetic mean of the edit distance similarity between each pair is 0.62, and the preset similarity threshold is 0.62.
[0048] Search for directly connected database table structure nodes along the mapping relationship edges of the matching business concept nodes to form a candidate database table node set.
[0049] For example, the target entity in the structured query element is "sales amount", and the operation type is "summary query". The business concept node matching "sales amount" is retrieved from the domain knowledge graph. The "sales amount" business concept node is found, and the database table structure nodes "sales_record" and "sales_detail" are located along its mapping edges, forming a candidate database table node set.
[0050] Further, database table nodes matching the operation type are filtered from the candidate database table node set. The filtering method is as follows: each database table node stores a list of commonly used operation types associated with it, which records the types of operations historically performed on that database table. The operation type is matched against the list of commonly used operation types of the candidate database table node; if a match is found, that database table node is selected. After matching and filtering all nodes in the candidate database table node set, the target database table node is obtained. When there are multiple target database table nodes, they are sorted in descending order of the weight of the mapping relationship edges, and the target database table node with the highest weight is selected. The weight of the mapping relationship edge is the frequency of that mapping relationship in the historical scripts.
[0051] For example, the list of common operation types for the candidate database table node "sales_record" includes "summary query", and the list of common operation types for "sales_detail" includes "detail query". The operation type is "summary query", matching "sales_record", thus filtering out the target database table node "sales_record".
[0052] Next, the database table structure information is extracted from the target database table node. This information includes the table name, field names, field data types, and primary / foreign key relationships. The table name is the node name of the target database table node; the field names and data types are obtained from the containment relationships between the target database table node and other field nodes; and the primary / foreign key relationships are obtained from the primary / foreign key relationships between the target database table node and other database table nodes.
[0053] Finally, field mapping information is extracted from the mapping relationship between the target database table nodes and the target entities. This field mapping information includes the correspondence between the attributes of the target entity and the fields in the database table structure information. This correspondence is extracted from the attribute mapping table stored along the mapping relationship between business concept nodes and database table structure nodes.
[0054] For example, the table structure information of the target database table node "sales_record" includes the table name sales_record, the field names are sale_id, sale_amount, sale_date, and customer_id, and the field data types are integer, decimal, date, and integer, respectively. The primary and foreign key relationship is that the customer_id field is associated with the cust_id field of the customer_info table. The field mapping information includes the target entity "sales amount" attribute "sales amount value" corresponding to the sale_amount field, "sales date" corresponding to the sale_date field, and "customer" corresponding to the customer_id field.
[0055] The pre-construction process of the domain knowledge graph is as follows: The first step is to collect heterogeneous data from multiple sources. Structured data includes at least database metadata, exported from the database management system, including table names, field names, field data types, primary and foreign key relationships, and field constraints for each database table. Unstructured data includes at least business rule documents, historical work order texts, and historical data scripts. Business rule documents record business analysis criteria and data definition specifications; historical work order texts record data extraction requirements submitted by business personnel; and historical data scripts are database query scripts written by technical personnel based on historical work order texts.
[0056] The second step involves parsing the historical data scripts to extract the table and field names used within them. This parsing utilizes a database query language parser to parse the text-based scripts into an abstract syntax tree (AST), from which table name nodes and field name nodes are extracted. By associating the historical data scripts with corresponding historical work order texts, the business intent descriptions of the historical data scripts are extracted. This association is based on matching script filenames or work order numbers. The extracted table names, field names, and business intent descriptions are then combined into a script-table field mapping record.
[0057] The third step involves semantic alignment and fusion processing of structured data, business rule documents, historical work order texts, and script-table field mapping records. Semantic alignment includes: extracting business concept terms from business rule documents and historical work order texts using named entity recognition; obtaining the direct correspondence between business concept terms and database table and field names from script-table field mapping records; and matching and merging the extracted business concept terms with the direct correspondences to establish a complete correspondence between business concepts and the database physical structure. Fusion processing integrates all aligned correspondences between business concepts and the database physical structure into fused knowledge units. Each fused knowledge unit contains a business concept name, the corresponding database table name, a list of corresponding field names, and the source type of the mapping relationship.
[0058] The fourth step is to construct a domain knowledge graph based on fused knowledge units. The domain knowledge graph contains three types of nodes: business concept nodes, each storing a business concept name and a list of its aliases; database table structure nodes, each storing a database table name and its metadata; and field nodes, each storing a field name and its data type. The domain knowledge graph contains two types of edges: mapping edges, connecting business concept nodes and database table structure nodes, storing the attribute correspondence table between them and the frequency of this mapping relationship in historical scripts; and inclusion edges, connecting database table structure nodes and field nodes, storing the field's type and constraint information. Primary and foreign key relationships are stored as edges between two database table structure nodes, labeled as primary and foreign key association edges.
[0059] For example, in the domain knowledge graph, the business concept node "sales amount" is connected to the database table structure node "sales_record" through a mapping relationship edge, and the edge's attribute corresponds to the table record "sales amount value corresponds to the sale_amount field". The database table structure node "sales_record" is connected to the field node "sale_amount" through an inclusion relationship edge, and the edge's type information is labeled as decimal type.
[0060] The following technical effects were achieved through this step: By constructing a domain knowledge graph, the correspondence between business concepts and the physical structure of the database is stored in a structured manner. The database table nodes are matched and filtered in the graph using the target entity and operation type as retrieval conditions. Compared with existing methods that rely on fixed mapping tables or string matching, this method can make dynamic matching by comprehensively utilizing multi-source information such as database metadata, business rule documents and historical work order texts, thereby improving the accuracy of mapping from business terms to database table names and field names.
[0061] S40: Input the structured query elements, the database table structure information, and the field mapping information into the pre-trained data script generation model to generate a data script draft; Structured query elements describe users' data query requirements in business language, while database table structure information and field mapping information provide the technical details of data storage. Both need to be integrated and converted into a data script that conforms to the target database's query language syntax. If the conversion rules are written manually, it would require exhaustively listing various operation types, table structures, and condition combinations, resulting in high maintenance costs and difficulty in covering complex nested logic.
[0062] Step S40 provided in this embodiment of the invention includes: The structured query elements, the database table structure information, and the field mapping information are concatenated according to a preset template format to generate model input prompts. The preset template format includes a structured query element filling area, a table structure information filling area, and a field mapping information filling area in sequence. Each filling area organizes its filling content in key-value pairs. The input prompt words are input into the pre-trained data script generation model. The data script generation model determines the target table and target fields involved in the data script based on the database table structure information and the field mapping information. It also determines the operation type, time range, filtering conditions and logical nesting relationship of the data script based on the structured query elements, and generates a draft data script that conforms to the syntax structure of the target table and the target fields.
[0063] The pre-training process of the data script generation model includes: Obtain a historical data script sample set. Each sample in the historical data script sample set contains historical structured query elements, historical database table structure information, historical field mapping information, and the corresponding standard data script. Construct an initial data script generation model, which is a generative language model based on an encoder-decoder architecture; The historical structured query elements, the historical database table structure information, and the historical field mapping information are concatenated according to a preset template format and used as input to the initial data script generation model. The corresponding standard data script is used as a supervision label. The training objective is to minimize the difference between the data script output by the initial data script generation model and the standard data script. The initial data script generation model is trained in a supervised manner until the verification convergence is obtained, thus obtaining the pre-trained data script generation model.
[0064] The specific implementation method is as follows: The structured query elements, database table structure information, and field mapping information are concatenated according to a preset template format to generate model input prompts. The preset template format sequentially includes a structured query element population area, a table structure information population area, and a field mapping information population area. Each population area organizes its content using key-value pairs. The structured query element population area lists five fields in key-value pairs: operation type, target entity, time range, filter conditions, and logical nesting relationships. The table structure information population area lists four fields in key-value pairs: table name, field name list, field data type list, and primary / foreign key relationships. The field mapping information population area lists the correspondence between each attribute of the target entity and the fields in the database table, also in key-value pairs. Key-value pairs in each population area are connected by an equals sign, key-value pairs are separated by newline characters, and population areas are separated by blank lines.
[0065] For example, the content of the structured query element population area is "Operation Type = Summary Query", "Target Entity = Sales Amount", "Time Range = First Quarter of 2024", "Filter Condition = Sales Amount Greater Than 1 Million", and "Logical Nesting Relationship = None". The content of the table structure information population area is "Table Name = sales_record", "Field Name List = sales_id, sales_amount, sales_date, customer_id", "Field Data Type List = Integer, Decimal, Date, Integer", and "Primary-Foreign Key Relationship = Customer_id field is associated with the cust_id field of the customer_info table". The content of the field mapping information population area is "Sales Amount value corresponds to the sales_amount field", "Sales Date corresponds to the sales_date field", and "Customer corresponds to the customer_id field". The content of the three population areas combined constitutes the complete model input prompt.
[0066] The model inputs prompt words into a pre-trained data script generation model. The data script generation model is a generative language model based on an encoder-decoder architecture. The encoder receives the text sequence of prompt words as input, maps each word in the text sequence to a semantic vector, extracts the contextual semantic features of each word through a multi-layer self-attention mechanism, and outputs a sequence of semantic representation vectors for the prompt words. The decoder, using the semantic representation vector sequence output by the encoder as a condition, generates words for the data script draft one by one in an autoregressive manner. That is, when generating a word, the decoder uses the previously generated word as input, combines it with the semantic representation vector sequence of the encoder, and predicts the probability distribution of the next word through self-attention and cross-attention mechanisms, sampling to obtain the next word, until an end marker word is generated or the preset maximum generation length is reached. The data script draft is text conforming to the syntax of a structured query language.
[0067] The pre-training process of the data script generation model is as follows: Obtain a historical data script sample set. Each sample in the historical data script sample set is structured data and its corresponding script collected from historical data extraction work orders. Each sample contains four parts: historical structured query elements, obtained from the historical work order text through the domain adaptive semantic understanding model in step S20; historical database table structure information, retrieved from the domain knowledge graph in step S30; historical field mapping information, also retrieved from step S30; and a standard data script, which is a data script actually written and successfully executed by technical personnel for that historical work order.
[0068] An initial data script generation model is constructed. The initial data script generation model adopts an encoder-decoder architecture. The encoder of the initial data script generation model contains 6 transformer block layers, each with 8 multi-head self-attention heads. The hidden layer has a dimension of 512, and the feedforward network has a dimension of 2048. The decoder also contains 6 transformer block layers, each with 8 multi-head self-attention heads. The hidden layer has a dimension of 512, the feedforward network has a dimension of 2048, and there are 8 cross-attention heads. The word embedding layer has a word embedding dimension of 512, and the maximum length of the positional encoding is 2048. The weight parameters of each transformer block in the encoder and decoder are randomly initialized.
[0069] Historical structured query elements, historical database table structure information, and historical field mapping information are concatenated according to a preset template format and used as input to the initial data script generation model. The corresponding standard data script is used as the supervision label. The data script generation model generates an output script word by word in an autoregressive manner, outputting the probability distribution of the corresponding word at each position. The training objective is to minimize the difference between the model's output data script and the standard data script. The difference is measured using cross-entropy loss. The cross-entropy between the output word probability distribution and the standard word is calculated at each generation position, and the average value is taken over all positions to obtain the cross-entropy loss value.
[0070] Supervised training is performed on the initial data script-generated model. An adaptive moment estimation optimizer is used to update the model parameters. The initial learning rate is determined as follows: In the early stages of training, short-term training is conducted with different preset candidate learning rates, and the rate of decrease in validation loss corresponding to each candidate learning rate is compared. The candidate learning rate with the fastest decrease in validation loss is selected as the initial learning rate. For example, among the three candidate learning rates of 0.001, 0.0005, and 0.0001, 0.0005 corresponds to the fastest decrease in validation loss, so the initial learning rate is 0.0005. During each iteration of training, a preset number of samples are randomly selected from the sample set to form a batch. This preset number is called the batch size. The batch size is determined as follows: In the early stages of training, short-term training is conducted with different preset candidate batch sizes, and the training stability corresponding to each candidate batch size is compared. The candidate batch size with the smallest fluctuation in training loss is selected as the batch size. For example, among the three candidate batch sizes of 8, 16, and 32, 16 corresponds to the smallest fluctuation in training loss, so the batch size is 16. After each training round, the validation loss is calculated on the validation set. Early stopping is triggered when the validation loss stops decreasing for a predetermined number of consecutive rounds, stopping training. The number of rounds where the validation loss stops decreasing is set to 5. The model parameters corresponding to the round with the minimum validation loss are taken as the final parameters, resulting in the pre-trained data script-generated model.
[0071] For example, the input prompts to the model are encoded by the encoder to generate a semantic representation vector sequence. The decoder generates a draft data script word by word as follows: "Select the sales amount value, query the sales date from the sales record table, where the sales amount is greater than 1 million, the sales date is between January 1, 2024 and March 31, 2024, and sorted in descending order by sales amount value." This draft data script includes the query command corresponding to the operation type, the field name corresponding to the target entity, the time range, and the query statement corresponding to the filtering conditions. The logical nesting relationship is non-nested conditions.
[0072] The following technical effects were achieved through this step: The model input prompts are constructed by concatenating structured query elements, database table structure information, and field mapping information into a unified preset template format. This ensures that the three types of information, from different sources and with different structures, are organized in a uniform format before being input into the model. Compared to existing methods that rely on hard-coded rules for script assembly, this approach can flexibly adapt to different operation types, table structures, and condition combinations. The data script generation model uses an encoder-decoder architecture to semantically encode the prompts and then generates a script draft in an autoregressive manner. Compared to existing methods that use fixed templates for filling, this approach can generate complex nested query statements that conform to grammatical rules and are logically correct.
[0073] S50: Verify the draft data script. If the verification passes, output the draft data script as the final data script. If the verification fails, generate error correction information and iteratively execute the above steps until the verification passes and the final data script is output, thus completing the automatic generation of the data script.
[0074] The draft data script generated in step S40 is produced by the data script generation model in an autoregressive manner. Although the model learns the grammatical and semantic rules of historical scripts during pre-training, it may still encounter two types of errors when faced with new combinations of structured query elements: first, grammatical errors, where the generated script contains grammatical structures not supported by the target query language, causing the script to fail to execute in the database; second, semantic errors, where the script executes successfully, but the returned data does not match the user's query intent. If the draft script is delivered to the user for execution without verification, execution may fail due to grammatical errors, or unexpected query results may be generated due to semantic errors, requiring the user to repeatedly debug manually.
[0075] Step S50 provided in this embodiment of the invention includes: The data script draft is executed in a sandbox environment to obtain execution feedback information, which includes execution status and execution return data. Determine whether the data script draft was executed successfully based on the execution status. The operation type, filtering conditions, and logical nesting relationship are extracted from the structured query elements. The expected execution result features are determined according to the operation type. The execution return data is compared with the expected execution result features to obtain the comparison result, wherein the comparison result is consistent or inconsistent. When the draft data script is executed successfully and the comparison result is consistent, the draft data script is deemed to have passed the verification and is output as the final data script. If the draft data script fails to execute successfully, or if the draft data script executes successfully but the comparison result is inconsistent, the draft data script is determined to have failed verification. An error correction message is generated, the error correction message is returned to the interactive interface, and the interface waits to receive the next round of dialogue instructions to trigger iterative execution of steps S10 to S40.
[0076] The specific implementation method is as follows: Execute the draft data script in the sandbox environment and obtain execution feedback information. The sandbox environment is an independent database instance physically isolated from the production database. Its table structure and data content are consistent with the production database, but the execution operations will not affect the production data. The sandbox environment periodically synchronizes data from the latest backup of the production database, with a synchronization cycle of once a day. The draft data script is submitted to the data script execution engine in the sandbox environment. The execution engine parses and runs the script and returns execution feedback information. The execution feedback information includes two parts: execution status and execution return data. The execution status indicates the result of the script's execution in the sandbox environment, with values of success or failure. When the execution status is failure, the execution feedback information also includes a description of the failure reason; when the execution status is success, the execution return data is the result dataset returned by the script query.
[0077] The success of the data script draft is determined based on its execution status. If the execution status is "execution failed," the data script draft verification is deemed unsuccessful, and a description of the failure reason is extracted from the execution feedback information as part of the error correction message. This description typically includes the error type and location.
[0078] Extract operation types, filtering conditions, and logical nesting relationships from the structured query elements of the current round generated in step S20. Determine the corresponding expected execution result features based on the operation type. Expected execution result features describe the structural and content characteristics that the returned data should meet, and are categorized as follows based on the operation type: When the operation type is a summary query, the expected execution result is as follows: the returned data should contain a statistical value, and the statistical value should be structured as one row and one column. When the operation type is a detail query, the expected execution result is as follows: the returned data should contain detailed records within the specified time range, and the number of returned records should be greater than or equal to one. When the operation type is a ranking query, the expected execution result is as follows: the returned data should be returned according to the specified sorting rule, and the number of returned records should be greater than or equal to one. When the operation type is an existence query, the expected execution result is as follows: the returned data should contain a yes / no flag, with a value of either yes or no.
[0079] The returned execution data is compared with the expected execution result features to obtain the comparison result. The comparison method is as follows: extract the actual features corresponding to the expected execution result features from the returned execution data, and match and compare the actual features with the expected execution result features. If the actual features meet all the conditions of the expected execution result features, the comparison result is consistent; if the actual features do not meet any of the conditions of the expected execution result features, the comparison result is inconsistent.
[0080] For example, in the structured query element of step S20, the operation type is a summary query, and the expected execution result characteristics are that the returned data should contain a statistical value and have one row. After executing the script draft in the sandbox environment, the execution status is successful, and the returned data is one row and one column with a value of 8560000. The actual characteristics are one row, one column, and the statistical value is a numeric type, which meets all the conditions of the expected execution result characteristics, and the comparison result is consistent.
[0081] When the draft data script executes successfully and the comparison results are consistent, the draft data script is deemed to have passed verification, and the draft data script is output as the final data script. The final data script is output to the interactive interface in text form for user confirmation or direct use.
[0082] If the draft data script fails to execute, the verification is deemed unsuccessful. Similarly, if the draft data script executes successfully but the comparison results are inconsistent, the verification is also deemed unsuccessful. When verification fails, an error correction message is generated. The content of the error correction message is generated based on the reason for the verification failure: when the execution status is "execution failed," the error correction message includes a description of the reason for the failure; when the execution status is "execution successful" but the comparison results are inconsistent, the error correction message includes a description of the difference between the actual returned result and the expected result. The error correction message is then returned to the interactive interface and displayed to the user in an interactive dialogue format, prompting the user to supplement explanations or revise the query conditions in the next round of dialogue.
[0083] After the interactive interface displays the error correction prompt, it waits for the user to input the next round of dialogue instructions through the interactive interface, triggering iterative execution steps S10 to S40, regenerating structured query elements, retrieving the domain knowledge graph, generating a draft data script and verifying it again, until the draft data script passes verification in a certain iteration, and outputting the final data script.
[0084] For example, the draft data script executes successfully but returns empty data. The actual feature is zero rows, which does not match the expected result of having more than or equal to one row, resulting in an inconsistency. The error message is "Query executed successfully but no data returned. Possible reasons: The filter conditions are too strict or there is no matching data within the time range. Please verify the filter conditions or adjust the time range." Based on the error message, the user enters "Change the time range to the entire year of 2024" in the next round of dialogue, triggering a new iteration.
[0085] The following technical effects were achieved through this step: By executing the script draft in a sandbox environment and comparing the returned data with the expected execution results, the correctness of the script draft can be verified from both syntactic and semantic dimensions. This can automatically detect syntactic errors and semantic deviations in the script and complete quality verification before delivery to users.
[0086] When verification fails, an error correction message containing the specific reason for the error is generated and returned to the interactive interface, guiding the user to supplement or correct the query conditions in the next round of dialogue. This realizes automatic error diagnosis and correction guidance, and gradually improves the reliability of the final script through multiple rounds of human-computer collaboration.
[0087] This embodiment performs mapping disambiguation processing on the many-to-many mapping relationship between the target entity text and business concept nodes to determine a unique mapping match result. When there are two or more candidate business concept nodes whose edit distance similarity meets a preset similarity threshold, the weight value of the mapping relationship edge corresponding to each candidate business concept node is first obtained. The weight value is the frequency of the mapping relationship in the historical script. The candidate business concept nodes are sorted in descending order of weight value. Then, the operation type in the current structured query element is matched and verified with the list of common operation types of the database table nodes associated with each candidate business concept node, and candidate nodes with mismatched operation types are filtered out. Finally, the business concept node that ranks first and matches the operation type is selected as the target business concept node corresponding to the current target entity text mapping. If no candidate business concept node meets the conditions after filtering, a business concept missing prompt is generated and the user is returned to the interactive interface to guide the user to supplement the corresponding business definition information. During the actual matching, other slot information (region class, entity object class, etc.) in the historical dialogue state is also obtained, and the multi-turn dialogue context information and the attribute tags of the candidate business concept are used for matching.
[0088] Example 2, as Figure 4 As shown, based on the same inventive concept provided in Embodiment 1, this embodiment of the invention also provides a data script automatic generation system based on multi-turn dialogue intent recognition, the system comprising: The dialogue interaction module 11 is used to receive the current round of dialogue instructions input by the user in natural language form through the interactive interface, and to obtain historical dialogue status information. The intent recognition module 12 is used to perform intent recognition and slot filling on the current round dialogue instruction in the multi-round dialogue state based on the current round dialogue instruction and the historical dialogue state information, and generate the structured query elements of the current round. The knowledge retrieval module 13 is used to retrieve database table structure information and field mapping information associated with the structured query elements from a pre-built domain knowledge graph based on the structured query elements. The script generation module 14 is used to input the structured query elements, the database table structure information and the field mapping information into a pre-trained data script generation model to generate a data script draft; The script verification module 15 is used to verify the draft data script. If the verification passes, the draft data script is output as the final data script. If the verification fails, error correction prompts are generated and the dialogue interaction module is iteratively executed to the script verification module until the verification passes and the final data script is output, thus completing the automatic generation of the data script.
[0089] In one embodiment, the dialogue interaction module 11 is further configured to receive the current round dialogue instruction through the interactive interface and obtain the current round dialogue text; Obtain historical dialogue status information, which includes parsed intent tags, filled slot key-value pairs, and confirmed logical conditions in historical rounds. The slot key-value pairs include at least one or more of the following: indicator slots, time range slots, region slots, entity object slots, and operation type slots.
[0090] In one embodiment, the intent recognition module 12 is further configured to input the current round dialogue instruction into a pre-trained domain adaptive semantic understanding model, and classify the intent of the current round dialogue instruction through the domain adaptive semantic understanding model to identify the current round intent label corresponding to the current round dialogue instruction; Based on the current round intent tag, fill the slots for the current round dialogue instruction and extract the current round slot key-value pairs associated with the current round intent tag; Based on the current round intent tag and the current round slot key-value pair, the current round logical conditions implied in the current round dialogue instruction are parsed, wherein the current round logical conditions include single-condition logical relations or multi-condition nested logical relations connected by logical connectors; Based on the historical dialogue status information, the current round intent tag, the current round slot key-value pair, and the current round logical condition are updated with the parsed intent tag, filled slot key-value pair, and confirmed logical condition in the historical dialogue status information to generate the structured query elements for the current round.
[0091] The current round intent tag, the current round slot key-value pair, and the current round logical condition are compared item by item with the parsed intent tags, filled slot key-value pairs, and confirmed logical conditions in the historical dialogue state information. When the information items in the current round intent tag, the current round slot key-value pair, and the current round logical condition do not have corresponding historical information records in the historical dialogue state information, it is determined that the information is complementary, and the current round intent tag, the current round slot key-value pair, and the current round logical condition are added to the historical dialogue state information to obtain the updated historical dialogue state information; When the information items in the current round intent tag, the current round slot key-value pair, and the current round logical condition have corresponding historical information records in the historical dialogue state information and the information values are different, it is determined to be a semantic conflict. The current round intent tag, the current round slot key-value pair, and the current round logical condition are used to overwrite the corresponding historical information records in the historical dialogue state information to obtain updated historical dialogue state information. The structured query elements for the current round are generated based on the updated historical dialogue status information. The structured query elements for the current round include at least the operation type, target entity, time range, filtering conditions, and logical nesting relationships.
[0092] In one embodiment, the knowledge retrieval module 13 is further configured to extract target entities and operation types from the structured query elements, wherein the target entity is the value of the target entity field and the operation type is the value of the operation type field; Using the target entity as the retrieval condition, database table nodes that match the target entity are retrieved from the pre-constructed domain knowledge graph to form a candidate database table node set; Based on the operation type, select database table nodes that match the operation type from the candidate database table node set to obtain the target database table node; Database table structure information is extracted from the target database table node, and field mapping information is extracted from the mapping relationship between the target database table node and the target entity. The database table structure information includes at least the table name, field name, field data type, and primary and foreign key relationships. The field mapping information includes at least the correspondence between the attributes of the target entity and each field in the database table structure information.
[0093] The pre-construction process of a domain knowledge graph includes: Collect multi-source heterogeneous data, which includes structured data and unstructured data. The structured data includes at least database metadata, which includes table name, field name, field data type, primary and foreign key relationship, and field constraints. The unstructured data includes at least business rule documents, historical work order text, and historical data scripts. The historical data script is parsed to extract the table names and field names used in the historical data script. The business intent description of the historical data script is extracted by associating it with the historical work order text corresponding to the historical data script, forming a script-table field usage mapping record. The structured data, the business rule document, the historical work order text, and the script-table fields are semantically aligned and fused using mapping records. The business entities in the unstructured data are associated with the database table fields in the structured data, establishing a correspondence between business concepts and the physical structure of the database, and thus obtaining fused knowledge units. Based on the fused knowledge units, a domain knowledge graph is constructed. The domain knowledge graph includes business concept nodes, database table structure nodes, field nodes, as well as mapping relationship edges between the business concept nodes and the database table structure nodes, and inclusion relationship edges between the database table structure nodes and the field nodes.
[0094] In one embodiment, the script generation module 14 is further configured to concatenate the structured query elements, the database table structure information, and the field mapping information according to a preset template format to generate model input prompts. The preset template format includes a structured query element filling area, a table structure information filling area, and a field mapping information filling area in sequence, and each filling area organizes the filling content of the corresponding filling area in the form of key-value pairs. The input prompt words are input into the pre-trained data script generation model. The data script generation model determines the target table and target fields involved in the data script based on the database table structure information and the field mapping information. It also determines the operation type, time range, filtering conditions and logical nesting relationship of the data script based on the structured query elements, and generates a draft data script that conforms to the syntax structure of the target table and the target fields.
[0095] The pre-training process of the data script generation model includes: Obtain a historical data script sample set. Each sample in the historical data script sample set contains historical structured query elements, historical database table structure information, historical field mapping information, and the corresponding standard data script. Construct an initial data script generation model, which is a generative language model based on an encoder-decoder architecture; The historical structured query elements, the historical database table structure information, and the historical field mapping information are concatenated according to a preset template format and used as input to the initial data script generation model. The corresponding standard data script is used as a supervision label. The training objective is to minimize the difference between the data script output by the initial data script generation model and the standard data script. The initial data script generation model is trained in a supervised manner until the verification convergence is obtained, thus obtaining the pre-trained data script generation model.
[0096] In one embodiment, the script verification module 15 is further configured to execute the data script draft in a sandbox environment and obtain execution feedback information, wherein the execution feedback information includes execution status and execution return data; Determine whether the data script draft was executed successfully based on the execution status. The operation type, filtering conditions, and logical nesting relationship are extracted from the structured query elements. The expected execution result features are determined according to the operation type. The execution return data is compared with the expected execution result features to obtain the comparison result, wherein the comparison result is consistent or inconsistent. When the draft data script is executed successfully and the comparison result is consistent, the draft data script is deemed to have passed the verification and is output as the final data script. If the draft data script fails to execute successfully, or if the draft data script executes successfully but the comparison result is inconsistent, the draft data script is determined to have failed verification. An error correction message is generated, the error correction message is returned to the interactive interface, and the interface waits to receive the next round of dialogue instructions to trigger iterative execution of steps S10 to S40.
Claims
1. A method for automatically generating data scripts based on multi-turn dialogue intent recognition, characterized in that, The method includes: S10: Receive the current round of dialogue instructions input by the user in natural language form through the interactive interface, and obtain historical dialogue status information; S20: Based on the current round dialogue instruction and the historical dialogue state information, perform intent recognition and slot filling for the current round dialogue instruction under multi-round dialogue state, and generate structured query elements for the current round; S30: Based on the structured query elements, retrieve the database table structure information and field mapping information associated with the structured query elements from the pre-built domain knowledge graph; S40: Input the structured query elements, the database table structure information, and the field mapping information into the pre-trained data script generation model to generate a data script draft; S50: Verify the draft data script. If the verification passes, output the draft data script as the final data script. If the verification fails, generate error correction information and iteratively execute steps S10 to S40 until the verification passes and the final data script is output, thus completing the automatic generation of the data script.
2. The method for automatically generating data scripts based on multi-turn dialogue intent recognition according to claim 1, characterized in that, The system receives current-round dialogue commands input by the user in natural language through an interactive interface and retrieves historical dialogue status information, including: The current round of dialogue instructions are received through the interactive interface, and the current round of dialogue text is obtained. Obtain historical dialogue status information, which includes parsed intent tags, filled slot key-value pairs, and confirmed logical conditions in historical rounds. The slot key-value pairs include at least one or more of the following: indicator slots, time range slots, region slots, entity object slots, and operation type slots.
3. The method for automatically generating data scripts based on multi-turn dialogue intent recognition according to claim 1, characterized in that, Based on the current round of dialogue instructions and the historical dialogue state information, intent recognition and slot filling are performed on the current round of dialogue instructions under multi-round dialogue states to generate structured query elements for the current round, including: The current round dialogue instruction is input into a pre-trained domain adaptive semantic understanding model. The domain adaptive semantic understanding model performs intent classification on the current round dialogue instruction and identifies the current round intent label corresponding to the current round dialogue instruction. Based on the current round intent tag, fill the slots for the current round dialogue instruction and extract the current round slot key-value pairs associated with the current round intent tag; Based on the current round intent tag and the current round slot key-value pair, the current round logical conditions implied in the current round dialogue instruction are parsed, wherein the current round logical conditions include single-condition logical relations or multi-condition nested logical relations connected by logical connectors; Based on the historical dialogue status information, the current round intent tag, the current round slot key-value pair, and the current round logical condition are updated with the parsed intent tag, filled slot key-value pair, and confirmed logical condition in the historical dialogue status information to generate the structured query elements for the current round.
4. The automatic data script generation method based on multi-turn dialogue intent recognition according to claim 3, characterized in that, Based on the historical dialogue state information, the current round intent tag, the current round slot key-value pair, and the current round logical condition are updated with the parsed intent tags, filled slot key-value pairs, and confirmed logical conditions in the historical dialogue state information to generate the structured query elements for the current round, including: The current round intent tag, the current round slot key-value pair, and the current round logical condition are compared item by item with the parsed intent tags, filled slot key-value pairs, and confirmed logical conditions in the historical dialogue state information. When the information items in the current round intent tag, the current round slot key-value pair, and the current round logical condition do not have corresponding historical information records in the historical dialogue state information, it is determined that the information is complementary, and the current round intent tag, the current round slot key-value pair, and the current round logical condition are added to the historical dialogue state information to obtain the updated historical dialogue state information; When the information items in the current round intent tag, the current round slot key-value pair, and the current round logical condition have corresponding historical information records in the historical dialogue state information and the information values are different, it is determined to be a semantic conflict. The current round intent tag, the current round slot key-value pair, and the current round logical condition are used to overwrite the corresponding historical information records in the historical dialogue state information to obtain updated historical dialogue state information. The structured query elements for the current round are generated based on the updated historical dialogue status information. The structured query elements for the current round include at least the operation type, target entity, time range, filtering conditions, and logical nesting relationships.
5. The method for automatically generating data scripts based on multi-turn dialogue intent recognition according to claim 1, characterized in that, Based on the structured query elements, database table structure information and field mapping information associated with the structured query elements are retrieved from the pre-built domain knowledge graph, including: Extract the target entity and operation type from the structured query elements, wherein the target entity is the value of the target entity field and the operation type is the value of the operation type field; Using the target entity as the retrieval condition, database table nodes that match the target entity are retrieved from the pre-constructed domain knowledge graph to form a candidate database table node set; Based on the operation type, select database table nodes that match the operation type from the candidate database table node set to obtain the target database table node; Database table structure information is extracted from the target database table node, and field mapping information is extracted from the mapping relationship between the target database table node and the target entity. The database table structure information includes at least the table name, field name, field data type, and primary and foreign key relationships. The field mapping information includes at least the correspondence between the attributes of the target entity and each field in the database table structure information.
6. The method for automatically generating data scripts based on multi-turn dialogue intent recognition according to claim 5, characterized in that, The pre-construction process of a domain knowledge graph includes: Collect multi-source heterogeneous data, which includes structured data and unstructured data. The structured data includes at least database metadata, which includes table name, field name, field data type, primary and foreign key relationship, and field constraints. The unstructured data includes at least business rule documents, historical work order text, and historical data scripts. The historical data script is parsed to extract the table names and field names used in the historical data script. The business intent description of the historical data script is extracted by associating it with the historical work order text corresponding to the historical data script, forming a script-table field usage mapping record. The structured data, the business rule document, the historical work order text, and the script-table fields are semantically aligned and fused using mapping records. The business entities in the unstructured data are associated with the database table fields in the structured data, establishing a correspondence between business concepts and the physical structure of the database, and thus obtaining fused knowledge units. Based on the fused knowledge units, a domain knowledge graph is constructed. The domain knowledge graph includes business concept nodes, database table structure nodes, field nodes, as well as mapping relationship edges between the business concept nodes and the database table structure nodes, and inclusion relationship edges between the database table structure nodes and the field nodes.
7. The method for automatically generating data scripts based on multi-turn dialogue intent recognition according to claim 1, characterized in that, The structured query elements, the database table structure information, and the field mapping information are input together into a pre-trained data script generation model to generate a draft data script, including: The structured query elements, the database table structure information, and the field mapping information are concatenated according to a preset template format to generate model input prompts. The preset template format includes a structured query element filling area, a table structure information filling area, and a field mapping information filling area in sequence. Each filling area organizes its filling content in key-value pairs. The input prompt words are input into the pre-trained data script generation model. The data script generation model determines the target table and target fields involved in the data script based on the database table structure information and the field mapping information. It also determines the operation type, time range, filtering conditions and logical nesting relationship of the data script based on the structured query elements, and generates a draft data script that conforms to the syntax structure of the target table and the target fields.
8. The method for automatically generating data scripts based on multi-turn dialogue intent recognition according to claim 7, characterized in that, The pre-training process of the data script generation model includes: Obtain a historical data script sample set. Each sample in the historical data script sample set contains historical structured query elements, historical database table structure information, historical field mapping information, and the corresponding standard data script. Construct an initial data script generation model, which is a generative language model based on an encoder-decoder architecture; The historical structured query elements, the historical database table structure information, and the historical field mapping information are concatenated according to a preset template format and used as input to the initial data script generation model. The corresponding standard data script is used as a supervision label. The training objective is to minimize the difference between the data script output by the initial data script generation model and the standard data script. The initial data script generation model is trained in a supervised manner until the verification convergence is obtained, thus obtaining the pre-trained data script generation model.
9. The method for automatically generating data scripts based on multi-turn dialogue intent recognition according to claim 1, characterized in that, The draft data script is verified. If the verification passes, the draft data script is output as the final data script. If the verification fails, error correction information is generated, and steps S10 to S40 are executed iteratively until the verification passes and the final data script is output, thus completing the automatic generation of the data script, including: The data script draft is executed in a sandbox environment to obtain execution feedback information, which includes execution status and execution return data. Determine whether the data script draft was executed successfully based on the execution status. The operation type, filtering conditions, and logical nesting relationship are extracted from the structured query elements. The expected execution result features are determined according to the operation type. The execution return data is compared with the expected execution result features to obtain the comparison result, wherein the comparison result is consistent or inconsistent. When the draft data script is executed successfully and the comparison result is consistent, the draft data script is deemed to have passed the verification and is output as the final data script. If the draft data script fails to execute successfully, or if the draft data script executes successfully but the comparison result is inconsistent, the draft data script is determined to have failed verification. An error correction message is generated, the error correction message is returned to the interactive interface, and the interface waits to receive the next round of dialogue instructions to trigger iterative execution of steps S10 to S40.
10. A data script automatic generation system based on multi-turn dialogue intent recognition, characterized in that, The system for implementing the automatic data script generation method based on multi-turn dialogue intent recognition as described in any one of claims 1 to 9, the system comprising: The dialogue interaction module is used to receive the current round of dialogue instructions input by the user in natural language form through the interactive interface, and to obtain historical dialogue status information. The intent recognition module is used to perform intent recognition and slot filling for the current round of dialogue instructions in multi-round dialogue states based on the current round of dialogue instructions and the historical dialogue state information, and generate structured query elements for the current round. The knowledge retrieval module is used to retrieve database table structure information and field mapping information associated with the structured query elements from a pre-built domain knowledge graph based on the structured query elements. The script generation module is used to input the structured query elements, the database table structure information, and the field mapping information into a pre-trained data script generation model to generate a data script draft; The script verification module is used to verify the draft data script. If the verification passes, the draft data script is output as the final data script. If the verification fails, error correction prompts are generated and the dialogue interaction module is iteratively executed to the script verification module until the verification passes and the final data script is output, thus completing the automatic generation of the data script.