Business database natural language question and answer processing method fused with large model technology

Abstract

The invention discloses a business database natural language question and answer processing method fused with a large model technology. The method comprises the following steps: S1, receiving an emergency query request input by a user in a natural language form; and S2, carrying out analysis and intention recognition on the emergency query request based on a large language model, and generating a group of candidate query intentions arranged in a descending order according to matching degree scores and corresponding key entity information. According to the method, a core link can be optimized by introducing a large language model technology: in an intention recognition stage, intention recognition accuracy is improved through a formula of fusing semantic similarity and entity type matching degree; a priority-based asynchronous execution strategy is adopted to improve the response efficiency; the response reliability is guaranteed through real-time and conflict verification; meanwhile, the system performance is continuously improved in combination with an offline model optimization link, the defects of an existing processing method are finally overcome, and an accurate, efficient and reliable solution is provided for business database natural language question answering in an enterprise emergency scene.

Description

Technical Field

[0001] This invention relates to the field of processing methods, specifically to a natural language question-answering processing method for business databases that integrates large model technology. Background Technology

[0002] Natural language question answering (NQA) for business databases refers to an interactive model where users initiate query requests to a business database in natural language, and the system must understand the natural language request, correlate it with the business database data, and then generate a natural language response. Its core objective is to break down the barriers between natural language input from non-technical users and structured data queries from the business database. This allows non-technical personnel such as operations and maintenance staff to quickly obtain critical data supporting decision-making from the business database without needing to master SQL syntax or database structure, making it particularly suitable for the critical need for data access in emergency situations.

[0003] The natural language question-answering (NLE) processing method for business databases is a specific process system for implementing the aforementioned question-answering interaction. It typically covers core steps such as receiving query requests, parsing query intent and extracting key entities, matching the business database schema, generating database query statements, executing queries to obtain data, and generating natural language responses. An ideal processing method should ensure that natural language queries can be accurately translated into database executable operations, and that the responses are accurate, efficient, and tailored to user needs. However, existing processing methods have significant shortcomings, failing to guarantee data security and system stability during the question-answering process. In emergency scenarios, existing methods often suffer from intent recognition bias, omission of key entities, disordered query execution, and lack of reliability verification in responses, making it difficult to meet the needs of enterprises for accurate, fast, and reliable emergency queries. This negatively impacts the practical application of natural language question answering for business databases. Therefore, this paper proposes a natural language question-answering processing method for business databases that integrates large-scale model technology. Summary of the Invention

[0004] The present invention solves the above-mentioned technical problems through the following technical solution, and the present invention includes the following steps: Step S1: Receive the emergency query request entered by the user in natural language. Step S2: Based on the large language model, the emergency query request is parsed and the intent is identified to generate a set of candidate query intents and corresponding key entity information arranged in descending order of matching degree score; Step S3: Based on the key entity information, perform matching and mapping in the preset business database schema library to determine the target data table and related fields, and obtain the mapped database fields; Step S4: Based on the candidate query intent, key entity information and mapped database fields, dynamically construct a set of structured query language query statements, i.e., a set of SQL statements. Each SQL statement in the set of SQL statements corresponds to the parsing result of a candidate query intent, and assign an execution priority weight that is positively correlated with the matching score to each SQL statement. Step S5: Based on the execution priority weight, execute the set of SQL query statements using the corresponding strategy to obtain the corresponding structured data result set from the business database; Step S6: Input the structured data result set, the original emergency query request and the corresponding query intent into the large language model. The large language model will then perform information integration, reasoning and natural language generation to form a preliminary emergency response text. Step S7: Perform real-time and conflict checks on the initial emergency response text to ensure that it is consistent with the latest status data in the business database; Step S8: Output the final emergency response after verification.

[0005] Furthermore, step S2, which involves parsing and identifying the intent of the emergency query request based on a large language model, specifically includes: S21. Use a large language model to extract the entity set from the query request. and intent keyword set ; S22. Input sets E and K into the intent classification module of the large language model. This module calculates the intent... Match score with the current query To sort, the matching score The calculation formula is: ; in, This represents the query keyword set K and the predefined intent. Keyword templates Semantic similarity between them Represents the query entity set E and intent Required entity type template Type link matching degree between them This is the weighting adjustment coefficient; S23. Select the top N intents with the highest matching scores as the candidate query intents, and sort them in descending order of scores.

[0006] Furthermore, step S4, which involves dynamically constructing a set of structured query language query statements, specifically includes: S41, for each intent in the candidate query intents Based on the business database schema information it is mapped to, a corresponding SQL query framework is generated; S42. Use the key entity information extracted in step S2 as values ​​to fill the WHERE clause of the SQL query framework; S43, according to intent Match score Calculate the execution priority weight of the corresponding SQL statement. .

[0007] Furthermore, step S5 employs a priority-based asynchronous execution strategy, including: S51, Priority weighting for execution The highest-level SQL query statement; S52. While executing high-weight queries, asynchronously execute other queries with lower weights; S53. If a high-priority query returns a non-empty result set that meets the confidence threshold, then terminate the execution of some or all low-priority queries in advance to save system resources and improve response speed.

[0008] Furthermore, in step S6, the information integration, reasoning, and natural language generation performed by the large language model specifically involve: Structured data result sets returned by multiple SQL queries The text is organized into a predefined text format and, together with the user's query Q and intent I, forms a prompt. This prompt is then input into a large language model, which is instructed to answer question Q based on dataset D, generating a coherent preliminary emergency response text A that integrates the data query results. .

[0009] Furthermore, the real-time and conflict verification in step S7 specifically includes: S71. Real-time Verification: Extract time-sensitive conclusions from the initial emergency response text A and compare them with the latest update timestamp of the corresponding data table in the business database. Compare the current time. If the time limit exceeds the predefined time threshold, a prompt message will be added to the final response; S72. Conflict Validation: Check whether there are logical conflicts in the result sets returned from different priority query paths; if there are conflicts, the results of the higher priority query path are adopted first, and the reasons for adoption are generated based on the large language model, and the explanation is incorporated into the final response.

[0010] Furthermore, it also includes an offline model optimization phase: Collect queries, successfully executed SQL statements, and ultimately adopted correct answers from historical emergency Q&A records to construct training sample pairs. ; The sample was used to perform supervised fine-tuning (SFT) on the large language model to optimize its accuracy in intent recognition and entity extraction in step S2, and the quality of answer generation in step S6.

[0011] Compared with existing technologies, this invention has the following advantages: This business database natural language question answering method, which integrates large-scale model technology, extracts entity sets and intent keywords from queries using a large language model, and accurately sorts candidate intents using a matching score formula to quickly identify core needs. In case of emergencies, enterprises can directly trigger queries quickly via natural language without manually parsing each request, reducing the time spent understanding intents. It employs a priority-based asynchronous execution strategy, prioritizing the execution of high-weight SQL statements while asynchronously processing low-weight statements; if a high-priority query returns a valid result, low-priority queries can be terminated early.

[0012] By using a pre-built business database schema library, key entity information is precisely mapped to target data tables and related fields. Then, a set of SQL statements is dynamically generated, ensuring that each SQL statement corresponds to the parsed result of the candidate query intent. This avoids problems such as field matching errors and table join mistakes that may occur with traditional manual SQL writing, guaranteeing the accuracy of the transformation from intent to data query and providing reliable data support for emergency response plans.

[0013] Extract time-sensitive conclusions from the initial response and compare them with the latest update timestamp in the database. If the timeliness threshold is exceeded, a prompt is added to avoid developing emergency plans based on expired data. Check for logical conflicts in query results of different priorities, prioritize the adoption of high-priority results and generate explanations. Support users to input emergency query requests in natural language. No enterprise employees need to master SQL syntax or database structure. The system automatically completes intent parsing, SQL generation and data querying. It does not rely on the assistance of the technical team, reduces cross-departmental communication costs, makes emergency queries operable by everyone, and improves the overall emergency response collaboration efficiency of the enterprise.

[0014] Through offline model optimization, samples from historical emergency question-and-answer sessions, showing the correct SQL queries leading to correct answers, are collected. Supervised fine-tuning of the large model continuously improves the accuracy of intent recognition, entity extraction, and answer generation. As enterprises accumulate emergency scenarios, the system will gradually adapt to more diverse emergency query types, and the accuracy of responses will continuously improve, forming a virtuous cycle of use, optimization, and further usability, thus meeting the iterative needs of enterprises for intelligent emergency question-and-answer systems in the long term. Attached Figure Description

[0015] Figure 1 This is a flowchart of the present invention. Detailed Implementation

[0016] The embodiments of the present invention are described in detail below. These embodiments are implemented based on the technical solution of the present invention, and provide detailed implementation methods and specific operation processes. However, the scope of protection of the present invention is not limited to the following embodiments.

[0017] like Figure 1 As shown, this embodiment provides a technical solution: a natural language question-answering method for business databases that integrates large-scale model technology, including the following steps: Step S1: Receive the emergency query request entered by the user in natural language. Step S2: Based on the large language model, the emergency query request is parsed and the intent is identified to generate a set of candidate query intents and corresponding key entity information arranged in descending order of matching degree score; Step S3: Based on the key entity information, perform matching and mapping in the preset business database schema library to determine the target data table and related fields, and obtain the mapped database fields; Step S4: Based on the candidate query intent, key entity information and mapped database fields, dynamically construct a set of structured query language query statements, i.e., a set of SQL statements. Each SQL statement in the set of SQL statements corresponds to the parsing result of a candidate query intent, and assign an execution priority weight that is positively correlated with the matching score to each SQL statement. Step S5: Based on the execution priority weight, execute the set of SQL query statements using the corresponding strategy to obtain the corresponding structured data result set from the business database; Step S6: Input the structured data result set, the original emergency query request and the corresponding query intent into the large language model. The large language model will then perform information integration, reasoning and natural language generation to form a preliminary emergency response text. Step S7: Perform real-time and conflict checks on the initial emergency response text to ensure that it is consistent with the latest status data in the business database; Step S8: Output the final emergency response after verification.

[0018] Step S2, which involves parsing and intent recognition of the emergency query request based on a large language model, specifically includes: S21. Use a large language model to extract the entity set from the query request. and intent keyword set ; S22. Input sets E and K into the intent classification module of the large language model. This module calculates the intent... Match score with the current query To sort, the matching score The calculation formula is: ; in, This represents the query keyword set K and the predefined intent. Keyword templates Semantic similarity between them Represents the query entity set E and intent Required entity type template Type link matching degree between them This is the weighting adjustment coefficient; S23. Select the top N intents with the highest matching scores as the candidate query intents, and sort them in descending order of scores; By refining the emergency query request parsing and intent recognition process based on a large language model, from core information extraction and scientific calculation of matching degree to candidate intent screening, this approach comprehensively solves problems such as ambiguity, directional deviation, and response interruption in natural language query intent in enterprise emergency scenarios. It provides key support for generating accurate query solutions and quickly acquiring emergency data, ensuring that enterprises can efficiently identify needs and advance decision-making through intelligent question answering in emergency situations. Taking an emergency scenario where a business system experiences a sudden order anomaly as an example, when operations personnel need to quickly locate the problem, they can enter a query request in natural language: "Query records of order payments that failed within the last 15 minutes on e-commerce platforms in the xx region and the amount exceeded 500 yuan."

[0019] First, in step S21, the large language model accurately extracts the core information from the query, including the entity set E = {"last 15 minutes" (time entity), "region" (geographic entity), "e-commerce platform" (business system entity), "order payment failure" (business status entity), "500 yuan" (amount threshold entity)}, and the intent keyword set K = {"query" (action keyword), "order payment failure" (demand keyword), "amount exceeds threshold" (filter condition keyword), "record" (result type keyword)}. This step avoids the "information omission" problem that may occur in traditional intent recognition. For example, if the last 15 minutes are not extracted, the query scope will be expanded to the entire day's data, increasing emergency response time. If the xx region is omitted, orders from other regions may be mistakenly searched, deviating from the emergency needs. However, the accurately extracted entities and keywords directly define a clear scope for subsequent intent matching, turning emergency queries from vaguely finding directions into precisely targeting them.

[0020] In step S22, the system inputs the extracted E and K into the intent classification module of the large language model. The intent matching degree is calculated by fusing semantic similarity and entity type matching degree to ensure that the core intent is not deviated.

[0021] The formula for calculating the matching score in this stage is: ,in Represents the set of query keywords K and the predefined intent Keyword templates semantic similarity, Represents the query entity set E and intent Required entity type template Type link matching degree, This is a weighting adjustment coefficient (which enterprises can set according to the needs of emergency scenarios; for example, if "accuracy of demand direction" is more important in an emergency, it can be set to...). ).

[0022] Assume the system predefines three emergency intents related to orders: To query order records with specific status (including thresholds) for a specified time / region / system, To count the total number of failed order payments in a specified system To query all abnormal orders on e-commerce platforms in the xx region.

[0023] During the calculation, K and The keyword templates (including queries, specified time, specified region, specified system, specific order status, threshold, and record) have highly overlapping semantics. ; E and The entity type template (including time range, region, business system, order status, and amount threshold) is a perfect match. Substituting into the formula, we get .

[0024] and The keyword template lacks descriptions related to time, region, and monetary thresholds. The entity type template lacks time, region, and amount thresholds. Calculated ; The keyword template lacks time, payment failure, and amount threshold. The entity type template is missing time, order status, and amount threshold. Calculated .

[0025] Through this scientific calculation, the system can accurately determine... To best match the intent, avoid misjudgments caused by relying solely on keyword or entity matching as a single dimension. For example, if only entity matching is considered... It also includes xx region and e-commerce platform, but cannot meet the emergency needs of payment failure and amount threshold. This formula, through dual-dimensional integration, ensures that intent recognition is fully aligned with the emergency query needs of operations personnel.

[0026] In step S23, the system selects the top N intents with the highest matching scores (e.g., N=3 for enterprises based on emergency fault tolerance requirements) as candidate query intents, and sorts them in descending order of score. This design provides redundancy for emergency queries by enterprises, preventing the intelligent question-and-answer system from being interrupted due to the failure of a single link.

[0027] For example, subsequent based on The generated SQL statement needs to query the order payment exception details table, but this table is temporarily inaccessible due to a sudden data synchronization failure (a potential local database issue in enterprise emergency scenarios). In this case, the system does not need to restart the intent recognition process and can directly use the second-highest priority method. This generates an SQL statement to query "the total number of failed payment orders on e-commerce platforms in the xx region in the last 15 minutes". Although it doesn't directly filter records with amounts exceeding 500 yuan, it quickly obtains the overall number of failed payment orders. Operations personnel can use this data to initially assess the scale of the anomaly while waiting for the order payment anomaly details table to be restored, thus avoiding further issues caused by... The failure of the corresponding query path led to an emergency stalemate with no data available, buying valuable time for subsequent order exception handling plans and further ensuring the stability and continuity of the enterprise's emergency intelligent Q&A system.

[0028] Step S4, which involves dynamically constructing a set of Structured Query Language query statements, specifically includes: S41, for each intent in the candidate query intents Based on the business database schema information it is mapped to, a corresponding SQL query framework is generated; S42. Use the key entity information extracted in step S2 as values ​​to fill the WHERE clause of the SQL query framework; S43, according to intent Match score Calculate the execution priority weight of the corresponding SQL statement. ; By refining the process of dynamically constructing a set of Structured Query Language (SQL) statements, in enterprise emergency intelligent question-and-answer scenarios, we have achieved accurate and efficient conversion of candidate query intents into executable SQL in the database. This avoids problems such as table field mismatch, query condition deviation, and disordered execution order in traditional SQL construction, providing key support for rapid acquisition of emergency data and decision support. Continuing with the emergency scenario: Enterprise IT operations personnel input natural language to query records showing that server B in the xx branch's data center has exceeded 80% memory usage in the past 30 minutes. Candidate intents have been identified (e.g., ...). : Query records where resource metrics exceed the threshold at a specified time / location / device, with a matching degree of 0.97; : Statistically analyze the historical data of the specified device resources (match degree 0.56), and step S3 has been mapped to the target table server resource monitoring table (including monitoring time, data center location, server number, and memory usage fields).

[0029] S41 generates SQL framework: for Generate a framework that adapts to the table structure: "SELECT monitoring time, memory usage rate FROM server resource monitoring table WHERE monitoring time >= [] AND data center location = [] AND server number = [] AND memory usage rate > []", to avoid incorrectly querying irrelevant tables such as "network device monitoring table" and ensure that the SQL is aligned with the database structure; S42 Fill Key Entity Conditions: Fill the extracted entities (last 30 minutes, xx branch office server room, server B, 80%) into the frame to obtain the specific SQL, "SELECT monitoring time, memory usage rate FROM server resource monitoring table WHERE monitoring time >= DATE_SUB(NOW(), INTERVAL 30MINUTE) AND server room location = 'xx branch office server room' AND server number = 'server B' AND memory usage rate > 80%", to avoid problems such as incorrect server room information and threshold deviations, and to ensure that the query conditions meet emergency needs; S43 calculates execution priority weights: weights are set according to the matching degree of candidate intents. Weight = 0.97 (Weight = 0.56) The corresponding SQL is executed first to quickly retrieve the critical emergency data of "memory over-threshold records" without waiting for low-priority queries, thus improving response efficiency.

[0030] Step S5 employs a priority-based asynchronous execution strategy, including: S51, Priority weighting for execution The highest-level SQL query statement; S52. While executing high-weight queries, asynchronously execute other queries with lower weights; S53. If a high-priority query returns a result set that is not empty and meets the confidence threshold, then terminate the execution of some or all low-priority queries in advance to save system resources and improve response speed. In enterprise emergency scenarios, the most critical need is to quickly obtain data directly related to the sudden problem. This strategy prioritizes executing the SQL query with the highest priority weight, eliminating the need to wait for low-priority SQL queries and ensuring that core data is returned as quickly as possible. For example, when operations and maintenance personnel encounter an emergency due to abnormal server memory usage, a high-priority SQL query can return "Server B has had 3 records of exceeding 80% memory usage in the past 30 minutes" within 1-2 seconds. Operations and maintenance personnel can immediately use this data to investigate process usage issues, avoiding delays in troubleshooting due to waiting for secondary query results.

[0031] While prioritizing the execution of high-weight SQL queries, other low-weight queries are executed asynchronously. This approach maintains the response speed for core requirements and allows for the acquisition of secondary data as a backup plan. For example, while high-weight SQL queries are being executed, a low-weight SQL query that tracks the memory usage trend of server B over the past 30 minutes can be run asynchronously. If the core SQL queries are delayed due to temporary data table access issues, the trend data from the secondary SQL queries can provide operations personnel with an initial assessment of whether memory usage is continuously increasing. This avoids an emergency deadlock caused by a single query path being blocked, resulting in no available data, while maximizing the utilization of idle system resources without adding extra response time.

[0032] When a high-priority query returns a non-empty result set that meets the confidence threshold (e.g., a clear record of memory exceeding the threshold has been obtained), the system will prematurely terminate some or all low-priority queries. For example, if the core SQL has accurately returned 3 records exceeding the threshold, fully meeting the fault location requirements, terminating the still-executing low-weight SQL for historical memory fault statistics on server B can prevent system resources such as CPU and database connections from being consumed by invalid queries. In enterprise emergencies, system resources often need to support multiple tasks simultaneously, including querying, fault handling, and alarm push notifications. The saved resources can be used more efficiently for other emergency operations, improving overall emergency response efficiency.

[0033] Step S6, where the large language model performs information integration, reasoning, and natural language generation, specifically involves: Structured data result sets returned by multiple SQL queries The text is organized into a predefined text format and, together with the user's query Q and intent I, forms a prompt. This prompt is then input into a large language model, which is instructed to answer question Q based on dataset D, generating a coherent preliminary emergency response text A that integrates the data query results. ; In enterprise emergency scenarios, the operators of intelligent question-and-answer systems may be non-technical personnel such as maintenance and operations staff, who are often unfamiliar with the interpretation logic of structured database data (such as query result tables with multiple columns and rows). In this case, the large language model converts the structured data result set (such as "3 records showing that server B in the xx branch's data center had more than 80% memory usage in the past 30 minutes, specifically at 10:05, 10:18, and 10:25, with memory usage rates of 82%, 85%, and 83% respectively") into natural language text, eliminating the need for users to analyze the meaning of data columns or construct data logic themselves. For example, maintenance personnel can quickly learn from the "preliminary emergency response text" that "server B experienced three instances of memory usage exceeding 80% in the past 30 minutes, concentrated between 10:00 and 10:30, with a peak usage rate of 85%" without needing to view the original data table returned by SQL, significantly reducing data understanding costs and meeting the need for rapid acquisition of effective information in emergency scenarios.

[0034] Integrate multi-source query results to avoid fragmented emergency information; Step S5 may execute multiple SQL queries (corresponding to different candidate intents), generating multiple structured data result sets (such as "over-threshold records" for the core intent and "memory usage trends" for secondary intents). In this case, the large language model integrates these scattered result sets with the original query and query intent into the same Prompt, generating a coherent response and avoiding information fragmentation. For example, if a high-priority SQL returns "3 over-threshold records" and a low-priority SQL returns "average memory usage of server B during the same period is 72%", the large language model will integrate them to generate "Server B in the xx branch's data center experienced memory usage exceeding 80% three times in the past 30 minutes (specific times: 10:05 / 10:18 / 10:25, highest 85%), with an average memory usage of 72% during the same period. The over-threshold situation is a sudden anomaly." Users do not need to compare multiple sets of data themselves; they can directly obtain the integrated complete information, providing direct evidence for emergency judgment (such as "whether it is a common problem or a sudden problem").

[0035] By explicitly including the "original emergency query request" and the "corresponding query intent" in the Prompt input, the large language model will generate a response based on these two elements, avoiding situations where "the data is accurate but irrelevant to the needs." For example, if the user's original query is "records of server B in the xx branch's computer room exceeding 80% memory usage in the past 30 minutes," with the intent to pinpoint the specific time period when memory usage exceeded the threshold, even if the structured data includes CPU usage data for server B, the large language model will focus on the memory exceeding the threshold record in its response, avoiding redundant CPU information output. This ensures that the response always revolves around the core emergency need (such as locating the period of abnormal memory usage to investigate the cause), avoiding information interference and saving emergency decision-making time.

[0036] Compared to fragmented structured data, the initial emergency response text generated by the large language model is logically coherent and fully expressed natural language. It can be directly used for cross-functional communication in emergency scenarios (such as operations personnel reporting a memory anomaly on server B to their supervisor) or for decision-making records (such as filling in emergency handling logs). No additional data formatting or supplementary explanations are required, further streamlining emergency operation processes and meeting the enterprise's needs for "efficient communication and rapid record-keeping" in emergency scenarios.

[0037] The real-time and conflict checks in step S7 specifically include: S71. Real-time Verification: Extract time-sensitive conclusions from the initial emergency response text A and compare them with the latest update timestamp of the corresponding data table in the business database. Compare the current time. If the time limit exceeds the predefined time threshold, a prompt message will be added to the final response; S72. Conflict Validation: Check whether there is a logical conflict in the result sets returned from different priority query paths; if there is a conflict, the result of the higher priority query path is adopted first, and the reason for adoption is generated based on the large language model, and the explanation is incorporated into the final response. Through a dual verification mechanism of real-time and conflict verification, this system accurately addresses potential issues in enterprise emergency scenarios, such as data expiration leading to decision-making errors and conflicting results causing confusion in intelligent question answering. It ensures that the initial emergency response text is consistent with the latest state of the business database and logically inconsistent, providing reliable and unbiased information support for enterprise emergency decision-making. Specific benefits include: At the real-time verification (S71) level, enterprise emergency scenarios have extremely high requirements for data timeliness. If a solution is developed based on expired data, the best time to handle the fault may be missed, or even secondary problems may be caused.

[0038] This case explicitly extracts time-sensitive conclusions from the initial emergency response text and compares them with the latest update timestamp of the corresponding data table in the business database. When the time difference exceeds a predefined timeliness threshold, a prompt is added. For example, continuing the unified emergency scenario: An operations and maintenance personnel query "records of server B in the xx branch's data center exceeding 80% memory usage in the last 30 minutes." The initial response text shows "a total of 3 records exceeding the threshold, the latest being 10:25." However, during verification, it is found that the latest update timestamp of the corresponding "Server Resource Monitoring Table" is 10:00 (current time 10:30, a time difference of 30 minutes exceeds the "20-minute" timeliness threshold). The system will add "Note: The current query result is based on data before 10:00, and there may be unsynchronized latest records. It is recommended to confirm the data table update status." This mechanism prevents operations and maintenance personnel from mistakenly treating expired data as real-time information, such as mistakenly believing there are no abnormalities after 10:25 when in fact another threshold-exceeding situation occurs at 10:28. This ensures that emergency decisions are based on "the latest available data," reducing the decision-making risk caused by data lag.

[0039] At the conflict verification level, asynchronous execution of multi-priority SQL in step S5 may return logically conflicting results. If not handled, this will put emergency personnel in a dilemma about which one to trust, delaying decision-making.

[0040] This case addresses conflicts in query results from different priority paths by prioritizing the results from the higher-priority path and incorporating an explanation generated by a large language model into the final response. For example, in the scenario described above, the high-priority SQL returned "3 records exceeding the threshold," while the low-priority SQL, due to an oversight in its query conditions, only returned "1 record exceeding the threshold." After detecting the conflict, the system prioritized the high-priority result and provided an explanation that the response was based on the query results corresponding to the resource indicator exceeding the threshold (match degree 0.97) for the specified time / location / device. The low-priority query's result deviation was due to incomplete matching of the 80% threshold condition. This approach avoids conflicting results interfering with emergency judgment and, through explanation, helps operations personnel understand the reasons for the result differences.

[0041] It also includes an offline model optimization phase: Collect queries, successfully executed SQL statements, and ultimately adopted correct answers from historical emergency Q&A records to construct training sample pairs. ; The sample was used to perform supervised fine-tuning (SFT) on the large language model to optimize its accuracy in intent recognition and entity extraction in step S2, and the quality of answer generation in step S6. By collecting queries, successfully executed SQL statements, and ultimately adopted correct answers from historical emergency question-and-answer records to construct training sample pairs, and using these sample pairs to perform supervised fine-tuning (SFT) on the large language model, the accuracy of intent recognition and key entity extraction in step S2 can be effectively optimized. This reduces subsequent query deviations caused by misjudgment of intent or omission of entities, ensuring accurate query direction in enterprise emergency scenarios. Simultaneously, it optimizes the information integration, reasoning, and natural language generation quality of the large language model in step S6, making the initial emergency response text more aligned with enterprise emergency needs, data integration more coherent, and reasoning more accurate, avoiding a disconnect between responses and actual emergency decision-making requirements. Furthermore, this optimization step relies on existing historical emergency records, eliminating the need for extensive manual sample annotation, reducing model optimization costs and difficulty. This allows the system to continuously adapt to more diverse emergency queries as enterprise emergency scenarios accumulate, forming a virtuous cycle of use, accumulation, and optimization. This long-term improvement enhances the reliability and practicality of the enterprise's intelligent emergency question-and-answer system, better supporting the enterprise's need to obtain relevant solutions in emergency situations.

[0042] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0043] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0044] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A business database natural language question and answer processing method based on a large model fusion technology, characterized in that, The method comprises the following steps: Step S1, receiving an emergency query request input by a user in natural language form; Step S2, performing analysis and intent recognition on the emergency query request based on a large language model, to generate a set of candidate query intents and corresponding key entity information arranged in descending order of matching score; Step S3, matching and mapping in a pre-set business database schema library according to the key entity information, to determine a target data table and associated fields, and obtain mapped database fields; Step S4, dynamically constructing a structured query language query statement set, i.e., a SQL statement set, based on the candidate query intents, the key entity information, and the mapped database fields, each SQL statement in the SQL statement set corresponding to a parsing result of a candidate query intent, and each SQL statement being assigned an execution priority weight positively correlated with the matching score; Step S5, executing the SQL query statement set according to the execution priority weight, using a corresponding strategy, to obtain a corresponding structured data result set from the business database; Step S6, inputting the structured data result set, the original emergency query request, and the corresponding query intent into the large language model, to perform information integration, reasoning, and natural language generation by the large language model, to form a preliminary emergency response text; Step S7, performing real-time and conflict checking on the preliminary emergency response text, to ensure that it is consistent with the latest state data in the business database; Step S8, outputting a final emergency response after verification.

2. The business database natural language question and answer processing method of claim 1, wherein: The step S2 of performing analysis and intent recognition on the emergency query request based on the large language model specifically comprises: S21, extracting an entity set in the query request using a large language model and an intent keyword set ; S22, input the set E and K to an intent classification module of the large language model, which sorts the intents by calculating the matching degree score of the current query with the current query ; S23, selecting the top N intents with the highest matching score as the candidate query intents, and arranging them in descending order of score. 3.The business database natural language question answering processing method of claim 2, wherein: The step S4 of dynamically constructing the structured query language query statement set specifically comprises: S41、for each of the candidate query intents generate a corresponding SQL query framework according to the business database schema information mapped thereto; S42, filling the key entity information extracted in step S2 into the WHERE condition clause of the SQL query framework as a value; S43、According to the intention a matching score , calculate the execution priority weight of the corresponding SQL statement .

4. The business database natural language question answering processing method of claim 3, wherein: The corresponding strategy adopted in step S5 is a priority-based asynchronous execution strategy, which comprises: S51, preferentially executing the priority weight Highest SQL query statement; S52, executing the queries with low weight asynchronously while executing the query with high weight; S53, if the query with high priority returns a non-empty result set that meets the confidence threshold, terminate the execution of part or all of the queries with low priority in advance, to save system resources and improve response speed. 5.The business database natural language question answering processing method of claim 1, wherein: The step S6 of performing information integration, reasoning, and natural language generation by the large language model specifically comprises: Structured data result sets returned by multiple sql queries The structured data result sets returned by multiple SQL queries are organized into a predefined text format, and together with the user query Q and its intent I constitute a prompt word, which is input into a large language model, instructing it to answer the question Q according to the data set D, generating a preliminary emergency response text A that integrates the data query results and is coherent.

6. The business database natural language question answering processing method of claim 5, wherein: The real-time and conflict checking in step S7 specifically comprises: S71, real-time verification: extract the conclusion related to time sensitivity from the preliminary emergency response text A, and compare it with the latest update timestamp of the corresponding data table in the business database If the current time is greater than the predefined time threshold, add a prompt message in the final response. S72, conflict checking: checking whether the result sets returned from different priority query paths have logical conflicts; if there is a conflict, preferentially adopting the result of the query path with high priority, and generating an explanatory text based on the large language model to explain the reason, and integrating the explanatory content into the final response. 7.The business database natural language question answering processing method of claim 1, wherein: The method further comprises an offline model optimization link: Collect the query, the successfully executed SQL statement and the finally adopted correct answer in the historical emergency question and answer record to construct a training sample pair ; The sample is used to supervise the fine-tuning of the large language model, to optimize the accuracy of intent recognition and entity extraction in step S2, and the quality of answer generation in step S6.

Images