Intelligent slot filling and mode linking method based on RAG and M-Schema

Abstract

The invention relates to the technical field of natural language processing, and discloses an intelligent slot filling and mode linking method based on RAG and M-Schema, and the method comprises the steps: rapidly matching a preset FAQ knowledge base through an RAG-FAQ module, and extracting a predefined medical intention and a slot structure; if the matching fails, starting an NLU module to perform intention classification and slot position extraction; performing entity linking and normalization on the slot value by utilizing an RAG-medical field knowledge base context enhancement module, performing multi-dimensional verification in combination with M-Schema metadata of a target database, and outputting a matching column and a confidence score; aiming at uncertainty types such as medical term ambiguity and business rule conflict, a clarification problem is dynamically generated, user feedback is received, SQL query conforming to business rules is generated after slot position information is corrected, and finally the SQL query is transmitted to a medical database execution module to output an analysis result. According to the invention, the availability and accuracy of the general framework in the scene facing the hospital management field can be improved.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of natural language processing, and in particular to an intelligent slot filling and mode linking method based on RAG and M-Schema. BACKGROUND

[0002] In recent years, text-to-SQL technology based on large language models has made significant progress. Among them, the XiYan-SQL framework realizes leading execution accuracy on multiple public benchmark datasets through innovative M-Schema database schema representation methods, multi-generator integration strategies, efficient schema linking and SQL optimizers, and other technologies, and exhibits universality and technical advantages.

[0003] However, the data in the hospital management field has the characteristics of numerous domain terms and aliases, complex data patterns and implicit business rules, diverse user query intentions and strong context dependence. Such a general framework still has significant limitations when faced with scenarios with high domain characteristics and complex business logic (such as the hospital management field). As can be seen from the above, how to improve the usability and accuracy of the general framework when faced with the hospital management field scenario still needs to be solved. SUMMARY

[0004] In order to improve the usability and accuracy of the general framework when faced with the hospital management field scenario, the application provides an intelligent slot filling and mode linking method based on RAG and M-Schema.

[0005] In a first aspect, the application provides an intelligent slot filling and mode linking method based on RAG and M-Schema, which adopts the following technical solution: An intelligent slot filling and mode linking method based on RAG and M-Schema, comprising: A user question input interface is used to receive natural language queries in the medical field, a RAG-FAQ rapid matching module is used to perform text similarity matching based on a preconfigured FAQ knowledge base in the medical field, and a matching degree is obtained. If the matching degree is higher than a preconfigured matching threshold, a preconfigured medical intent and slot structure are directly extracted, and a corresponding preliminary intent label, slot name-slot value pair and optional sub-scene label are output based on the medical intent and slot structure. If no matching is found or the matching confidence is lower than the preconfigured matching threshold, an NLU fine-grained analysis module is started, a fine-tuned sequence labeling model is used to classify the user question and extract the slot, and a corresponding preliminary intent label, slot name-slot value pair and optional sub-scene label are output. retrieve context from the medical domain knowledge base through a RAG-medical domain knowledge base context enhancement module based on the preliminary intent label, slot name-slot value pair, and sub-scene label, perform entity linking and normalization on the preliminary extracted slot value, and perform multi-dimensional verification on the entity linked and normalized slot value in combination with the M-Schema metadata of the target medical database, output the final matched medical database column and confidence score, and the M-Schema metadata includes column name, column description, data type, example value, and primary-foreign key relationship; identify the medical field-specific uncertainty types based on the final matched medical database column and the confidence score, the uncertainty types include medical term ambiguity, business rule conflict, and missing key slot, dynamically generate clarification questions and suggestion options for medical users based on the uncertainty types, receive user feedback on the clarification questions and suggestion options and update the medical slot information, and output the corrected slot name-slot value pair and corrected confidence score; generate a SQL query that conforms to the medical business rules based on the corrected slot name-slot value pair, the final matched medical database column, and the sub-scene label, and pass the generated SQL query to a medical database execution module to output the corresponding analysis result.

[0006] Optionally, in the process of entity linking and normalization of the preliminary extracted slot value by the RAG-medical domain knowledge base context enhancement module, the method further comprises: based on the preliminary extracted slot value and the entity alias mapping table in the medical domain knowledge base, link the slot value to the standard entity name in the medical domain knowledge base through semantic similarity calculation, and output the normalized slot value and the corresponding entity identifier after normalization; based on the normalized slot value and the medical business rules, perform compliance verification on the normalized slot value, adjust the statistical scope or filter sensitive fields, and output the final slot value that meets the compliance requirements of the medical database and the business rule verification status.

[0007] Optionally, in the process of multi-dimensional verification, the method further comprises: based on the final slot value and the data type definition of the medical database column, check the data type compatibility of the slot value and the medical database column, and automatically convert non-standard formats, output the candidate column after data type verification and the verification status; based on the verified candidate column and the example value of the medical database column, compare the matching degree of the slot value and the example value through semantic similarity calculation, improve the ranking of the candidate options, and output the ranked candidate column list; based on the candidate column list and the primary-foreign key relationship of the medical database, optimize the candidate column combination to ensure that the table connection logic meets the medical business requirements, and output the final matched medical database column and confidence score.

[0008] Optionally, the method further comprises: Based on the final matched medical database column and the confidence score, identifying the medical term ambiguity situation in which the slot value is mapped to multiple candidate columns, and generating a clarification question to determine the corresponding candidate column direction; Based on the confidence score and the medical business rules, determining whether there is a missing key slot, and generating a supplementary suggestion option to perfect the corresponding slot information; Based on the candidate column direction and the slot information integration, generating a clarification question and a suggestion option for the medical user, and outputting the clarification interaction content to be confirmed by the user.

[0009] Optionally, in the updating process of the revised slot name-slot value pair, the method further comprises: Based on the user's confirmation of the non-standard format slot value, updating the slot value and marking it as a standard format, and outputting the slot value after data type correction and the marking state; Based on the user's explicit selection of the candidate column direction, updating the slot value and preferentially matching the candidate column, and outputting the slot value after ambiguity candidate item correction and the candidate column identifier; Based on the slot value after data type correction and the candidate column identifier after ambiguity candidate item correction, integrating the revised slot name-slot value pair, and outputting the final slot information that meets the medical business rules.

[0010] Optionally, in the process of generating a SQL query that meets the medical business rules, the method further comprises: Based on the revised slot name-slot value pair and the sub-scene label, applying specific business rules, and outputting the SQL template after business rule verification and the rule adaptation state; Based on the SQL template after business rule verification and the primary-foreign key relationship of the medical database, optimizing the table connection logic to ensure that the SQL query meets the medical business specifications, and outputting the finally generated SQL query statement; Passing the finally generated SQL query statement to the medical database execution module, and outputting the corresponding analysis result.

[0011] Optionally, the medical database execution module comprises the following steps: Based on the generated SQL query execution result, if it is detected that the SQL query execution fails, triggering an exception handling process, prompting the user to check the input or contact the medical database administrator, and outputting the exception handling prompt information; Based on the query result content, filtering sensitive data to ensure compliance with medical data security and privacy protection requirements, and outputting the final analysis result after security filtering; Returning the final analysis result to the user interaction interface to complete the closed-loop interaction of the medical database query.

[0012] In a second aspect, the application provides an intelligent slot filling and schema linking system based on RAG and M-Schema, which adopts the following technical solution: An intelligent slot filling and schema linking system based on RAG and M-Schema, comprising: A matching degree acquisition module receives a natural language query in the medical field through a user question input interface, performs text similarity matching based on a pre-set FAQ knowledge base in the medical field through a RAG-FAQ fast matching module, and is used to acquire a corresponding matching degree. If the matching degree is higher than a pre-set matching threshold, a pre-defined medical intent and slot structure are directly extracted, and a corresponding preliminary intent label, slot name-slot value pair and optional sub-scene label are output based on the medical intent and slot structure. If there is no matching or the matching confidence is lower than the pre-set matching threshold, a NLU fine-grained analysis module is started, a fine-tuned sequence labeling model is used to classify the intent and extract the slot of the user question, and a corresponding preliminary intent label, slot name-slot value pair and optional sub-scene label are output. A retrieval module retrieves context from a medical field knowledge base through a RAG-medical field knowledge base context enhancement module based on the preliminary intent label, slot name-slot value pair and sub-scene label, performs entity linking and normalization on the preliminarily extracted slot value, combines the entity linked and normalized slot value with the M-Schema metadata of the target medical database for multi-dimensional verification, and outputs the final matched medical database column and confidence score. The M-Schema metadata includes column name, column description, data type, example value and primary-foreign key relationship. A medical slot information updating module identifies the uncertainty types specific to the medical field based on the final matched medical database column and the confidence score, the uncertainty types including medical term ambiguity, business rule conflict and missing key slot. The clarification questions and suggestion options for medical users are dynamically generated based on the uncertainty types. User feedback on the clarification questions and suggestion options is received and used to update the medical slot information, and the corrected slot name-slot value pair and corrected confidence score are output. A SQL query generation module is used to generate a SQL query conforming to the medical business rules based on the corrected slot name-slot value pair, the final matched medical database column and the sub-scene label. The generated SQL query is transmitted to a medical database execution module, and a corresponding analysis result is output.

[0013] In a third aspect, the application provides an intelligent slot filling and schema linking system based on RAG and M-Schema, which adopts the following technical solution: The application provides an intelligent slot filling and schema linking system based on RAG and M-Schema, comprising a processor, wherein the processor runs a program of the intelligent slot filling and schema linking method based on RAG and M-Schema.

[0014] In a fourth aspect, the application provides a storage medium, which adopts the technical scheme as follows: A storage medium, which stores the program of the intelligent slot filling and schema linking method based on RAG and M-Schema.

[0015] In summary, the application has at least one beneficial technical effect as follows: the deep integration of RAG and M-Schema significantly improves the usability and accuracy of the general framework in the medical field. Specifically: The RAG-FAQ module quickly matches high-frequency medical scenarios (such as "querying patient medical records in a certain department"), generates dynamic clarification questions, and forms a closed loop with user feedback, greatly reducing the failure of interaction caused by ambiguous or missing information input, so that non-professional users can also efficiently complete complex queries; at the same time, sensitive data filtering and abnormal processing mechanism ensures the stability and compliance of the system, meeting the stringent requirements of hospital management on safety. Entity linking and normalization based on the medical knowledge base (such as mapping "angina pectoris" to ICD-10 code I20) and multi-dimensional verification driven by M-Schema metadata (data type checking, primary-foreign key relationship optimization) ensure the accurate matching of slot values and database columns, avoiding query errors caused by term ambiguity or structural mismatch in traditional methods; in addition, business rule checking and table connection logic optimization further strengthen the compliance of SQL generation, so that the query results strictly conform to the medical business specifications. Through the subdivision of scenario tags (such as "inpatient expense analysis" and "chronic disease follow-up statistics") and dynamic adaptation of medical business rules, the system can flexibly cope with diversified query requirements in hospital management (such as cross-department data association and time dimension statistics), solving the problem of insufficient requirements for professional terminology, data association and privacy protection in the medical scene of the general framework, thereby realizing the precise closed loop from natural language to database operation. BRIEF DESCRIPTION OF DRAWINGS

[0016] Figure 1 is a flowchart of an intelligent slot filling and schema linking method based on RAG and M-Schema according to an exemplary embodiment.

[0017] Figure 2 is a structural block diagram of an intelligent slot filling and schema linking method device based on RAG and M-Schema according to an exemplary embodiment. DETAILED DESCRIPTION

[0018] Embodiments of the present application are described in detail below, examples of which are shown in the accompanying drawings.

[0019] In the description of the present specification, the description referring to the terms "certain embodiments", "one embodiment", "some embodiments", "illustrative embodiments", "example", "specific example", or "some examples" means that the particular feature, structure, material, or characteristic being described is included in at least one embodiment or example of the present application. The illustrative representations of the above terms in the present specification do not necessarily refer to the same embodiment or example. Moreover, the particular features, structures, materials, or characteristics being described can be combined in any suitable manner in one or more embodiments or examples.

[0020] In the field of medical management, accurate parsing of natural language queries and efficient linking of database schemas are core challenges for intelligent data analysis. Although existing text-to-SQL technologies (such as the XiYan-SQL framework) perform well in general scenarios, they still have significant limitations in practical applications in the medical field. The particularity of medical data mainly manifests in three aspects: first, there are many domain-specific terms and a large number of aliases (such as the equivalence of "average hospitalization days" and "average hospitalization days"); second, the database schema is complex and implies a large number of business rules (such as statistical standards and data security requirements); third, the context dependence of user queries is strong, and the intent can only be accurately understood in combination with the sub-scenarios (such as "hospitalization analysis" and "patient statistics"). In addition, the sensitivity of medical data requires the system to balance accuracy and security when generating SQL queries to avoid data leakage or analysis bias caused by misinterpretation of user input or incorrect linking of database columns.

[0021] To address the above problems, the present application proposes an intelligent slot filling and schema linking method based on Retrieval-Augmented Generation (RAG) and M-Schema, which realizes accurate parsing of natural language queries and deep adaptation of database schemas in the medical field through a hierarchical processing strategy and a dynamic interaction mechanism. The core innovations of the present application include: Hierarchical intent recognition and slot extraction: Combining RAG-FAQ fast matching and NLU fine-grained analysis, balancing efficient response to high-frequency questions and accurate extraction of low-frequency questions; Context enhancement driven by medical knowledge base: Through entity linking, term normalization and business rule verification, solve medical term ambiguity and compliance problems; M-Schema multi-dimensional verification: Based on the metadata of medical databases (column name, data type, primary-foreign key relationship), perform data type verification, example value matching and table connection optimization to ensure the accuracy of SQL generation; Dynamic clarification and user feedback loop: actively identify uncertainties (such as term ambiguity, missing key slots) and generate clarification questions to guide users to supplement information, improve interaction efficiency and query accuracy.

[0022] The technical implementation process of the application will be described in detail below in combination with specific implementation steps; the embodiment of the application discloses an intelligent slot filling and mode linking method based on RAG and M-Schema, referring to Figure 1 , including.

[0023] S100, receiving a natural language query in the medical field through a user question input interface, performing text similarity matching based on a pre-set FAQ knowledge base in the medical field through a RAG-FAQ fast matching module, obtaining a corresponding matching degree, if the matching degree is higher than a pre-set matching threshold, directly extracting a pre-defined medical intent and slot structure, and outputting a corresponding preliminary intent label, slot name-slot value pair and optional sub-scene label based on the medical intent and slot structure; if there is no matching or the matching confidence is lower than the pre-set matching threshold, starting an NLU fine-grained analysis module, using a fine-tuned sequence labeling model to classify the intent and extract the slot of the user question, and outputting a corresponding preliminary intent label, slot name-slot value pair and optional sub-scene label.

[0024] The detailed execution process of the S100 step includes the following sub-steps: Step 1, the user question input interface receives the natural language query in the medical field: first, the system receives the natural language query in the medical field through the user question input interface (such as API interface, chat robot interaction interface, etc.). The interface is responsible for passing the user's original question (for example, "query A hospital's average hospitalization days last month") to the subsequent processing module in the form of text. The design of the input interface needs to support multi-channel access (such as web page, mobile terminal, speech recognition system, etc.), and ensure the uniformity of the input data format and the validity verification.

[0025] Step 2, after receiving the user input, the system calls the RAG-FAQ fast matching module to perform text similarity matching based on the pre-set FAQ knowledge base in the medical field. The core logic of this module is: Vectorization: Convert user questions into vector representations through pre-trained embedding models (e.g., BERT, bge-base, etc.), while vectorizing the question-answer pairs in the FAQ knowledge base; Similarity calculation: Calculate the similarity scores between the user question vector and all question-answer pair vectors in the FAQ knowledge base using algorithms such as cosine similarity or Euclidean distance; Matching threshold judgment: If the similarity score of a question-answer pair is higher than the pre-set matching threshold (e.g., 0.85), it is considered that the current user question is highly related to this question-answer pair, and the next step is entered; otherwise, trigger the NLU fine-grained analysis process.

[0026] Step 3: When the matching degree is higher than the threshold, the system directly extracts the corresponding pre-defined medical intent and slot structure from the FAQ knowledge base. For example: intent label: such as "query indicator value" or "get patient information"; slot name-slot value pair: such as {"institution name": "A hospital", "indicator name": "average hospitalization days"}; sub-scene label (optional): such as "hospitalization analysis" or "patient statistics", used to further refine business rules.

[0027] It should be noted here that the above process relies on the pre-defined rules of the FAQ knowledge base to ensure fast response and consistent output for high-frequency questions.

[0028] Step 4: If the matching degree is lower than the threshold or no FAQ entry is matched, the system starts the NLU fine-grained analysis module. The NLU fine-grained analysis module, based on fine-tuned sequence labeling models (such as BiLSTM-CRF, BERT-BiLSTM, etc.), processes the user question as follows: Intent classification: Identify the intent of the user question (such as "query", "statistics", "filter") through a classification model (such as Softmax classifier); slot extraction: Identify key entities in the question (such as time, institution, indicator name) and extract them as slot values using a sequence labeling model; structured output: Generate a structured result consistent with the FAQ module, including the preliminary intent label, slot name-slot value pair, and sub-scene label.

[0029] Step 5: Regardless of whether it is through FAQ matching or NLU analysis, the system will output a unified format of preliminary results: Preliminary intent label: such as "query indicator value"; Slot name-slot value pair: such as {"institution name": "A hospital", "time": "last month"}; Sub-scene label (optional): such as "hospitalization analysis".

[0030] It should be noted here that the preliminary results serve as input for subsequent steps (such as context enhancement, entity linking) to drive the entire process forward.

[0031] Based on the above sub-steps of S100, the efficient parsing and structured output of natural language queries in the medical field are realized through a hierarchical processing strategy (combination of RAG-FAQ fast matching and NLU fine-grained parsing). This step balances efficiency and accuracy in the medical scenario: on the one hand, for high-frequency problems, the predefined intent and slot structure are directly extracted from the FAQ knowledge base, significantly shortening the response time; on the other hand, for low-frequency or complex problems, the user's intent and key information are accurately identified relying on the fine-tuned sequence labeling model, ensuring the accuracy of slot extraction. Finally, the standardized slot name-slot value pairs and intent labels output by S100 provide a reliable basis for the subsequent context enhancement, entity normalization, and SQL generation, ensuring the coherence and stability of the entire intelligent slot filling and pattern linking process.

[0032] S200, based on the preliminary intent label, slot name-slot value pair, and sub-scene label, retrieves the context from the medical field knowledge base through the RAG-medical field knowledge base context enhancement module, performs entity linking and normalization on the preliminary extracted slot values, and combines the entity linked and normalized slot values with the M-Schema metadata of the target medical database for multi-dimensional verification, outputs the final matched medical database column and confidence score, and the M-Schema metadata includes column name, column description, data type, example value, and primary-foreign key relationship.

[0033] The detailed execution process of S200 step includes the following sub-steps: Step 1, after the preliminary extraction of slot name-slot value pairs, the system calls the RAG-medical field knowledge base context enhancement module to retrieve relevant context information from the medical field knowledge base. The core logic of this module is: Knowledge base retrieval: based on the preliminary extracted slot values (such as "average hospitalization days" and "outpatient volume"), relevant entity aliases, business rules, and statistical indicators are retrieved from the medical field knowledge base; for example, "outpatient volume" may be expressed as "outpatient visits" or "outpatient number" by users, and the knowledge base needs to cover the diversity of these terms.

[0034] Semantic similarity calculation: through an embedding model (such as BERT), the slot value is compared with the standard entity in the knowledge base, and the semantic similarity score is calculated. If the similarity score of an entity is higher than the preset threshold (such as 0.9), it will be considered as a candidate entity for subsequent processing.

[0035] Step 2, after retrieving the relevant context, the system performs entity linking and normalization on the slot values to ensure consistency with the standard entities in the medical field knowledge base. In the process of entity linking and normalization of the preliminary extracted slot values in the embodiments of the present application, the method further includes: S2001, After preliminary extraction of slot value, the system calls the entity alias mapping table in the medical knowledge base to match the user's input non-standard terminology with the standard entity name: Alias mapping retrieval: Through the entity alias mapping table (such as "outpatient volume"→"outpatient visits", "average length of stay"→"average hospitalization day"), directly match the common alias of the slot value. If the slot value is completely consistent with a certain standard entity name, output the entity name and the corresponding entity identifier (such as {"normalized slot value": "average hospitalization day", "entity ID": "HOS-001"}).

[0036] Semantic similarity calculation: For slot values that are not directly matched (such as user input "average length of stay"), the system calculates the similarity score between the vector of the input and the vector of the standard entity name in the knowledge base through an embedding model (such as BERT). For example, the similarity between "average length of stay" and "average hospitalization day" may be as high as 0.98, much higher than other candidate entities (such as "hospitalization duration" 0.85).

[0037] Candidate entity screening: According to the similarity score, screen the top N candidate entities (such as N=3), and preferentially select entities with high relevance to the current scenario (such as "hospitalization analysis") based on business rules. For example, in the "hospitalization analysis" scenario, "average hospitalization day" may be preferentially matched.

[0038] S2002, After entity linking, the system outputs the normalized slot value and the corresponding entity identifier: Normalized result generation: Replace the user's input non-standard terminology with the standard entity name in the knowledge base (such as normalize "outpatient volume" to "outpatient visits"), and associate the entity identifier (such as {"normalized slot value": "outpatient visits", "entity ID": "HOS-002"}).

[0039] Multiple candidate processing: If there are multiple high-similarity candidate entities (such as "outpatient volume" may be mapped to "outpatient visits" or "outpatient number"), the system will record all candidate entities and their similarity scores for further processing in subsequent steps (such as dynamic clarification).

[0040] S2003, Based on the normalized slot value, the system performs compliance verification based on medical business rules: Statistical caliber adaptation: According to the medical business rules (such as "outpatient visits per day statistics"), supplement or adjust the statistical logic of the normalized slot value. For example, if the user inputs "outpatient volume" without specifying the statistical period, the system will automatically supplement the default rule (such as "daily statistics") to generate {"normalized slot value": "outpatient visits", "statistical caliber": "daily statistics"}.

[0041] Sensitive field filtering: Identify and filter sensitive fields (e.g., "patient name", "ID number") that may involve patient privacy. For example, if the normalized slot value contains "patient ID", the system checks whether it belongs to a sensitive field and decides whether to keep or de-identify it according to the rules.

[0042] Business rule conflict detection: Check if the normalized slot value conflicts with the business rules of the medical database. For example, if the user inputs "average hospitalization days" with the requirement to exclude "unresolved cases", the system checks whether this condition complies with the business rules of the medical database (e.g., whether it is allowed to filter by "case status").

[0043] S2004, after completing the compliance check, the system outputs the final slot value and the business rule check status: Final slot value generation: Integrate the normalized slot value with the adjusted statistical scope or filtering conditions (e.g., { "final slot value": "average hospitalization days", "statistical scope", "exclude unresolved cases", "sensitive field filtering": true}).

[0044] Check status marking: Mark the business rule check status according to the check results (e.g., "pass", "need clarification", "conflict"). For example, if the normalized slot value does not conflict with the business rules and the sensitive fields have been filtered, it is marked as "pass"; if there is ambiguity (e.g., multiple candidate entities), it is marked as "need clarification".

[0045] Based on the above execution steps S2001 to S2004, the entity linking and normalization solve the term ambiguity problem in natural language queries, while combining medical business rules to ensure that the output results comply with the database specifications. Specifically, the system uses entity alias mapping table and semantic similarity calculation to map the user's input non-standard terms (e.g., "average hospitalization days") to standard entity names (e.g., "average hospitalization days"), achieving term unification; through statistical scope supplement, sensitive field filtering and conflict detection, it ensures that the slot value complies with the medical business specifications in terms of data statistical logic and privacy security; in addition, the output check status (e.g., "need clarification") provides the basis for subsequent dynamic interaction mechanism, avoiding query failure due to ambiguity or rule conflict. Finally, this step provides precise and compliant standardized slot value input for the medical field Text-to-SQL task, laying a solid foundation for subsequent SQL generation and schema linking.

[0046] Step 3, the system combines the M-Schema metadata of the target medical database (including column name, column description, data type, example value, primary-foreign key relationship) to perform multi-dimensional verification on the normalized slot value: S2011, after obtaining the final slot value, the system performs compatibility check based on the data type definition of the medical database columns (e.g., integer, string, date type, etc.): Data type matching check: Compare the slot value and the candidate column data type to see if they are consistent. For example, if the slot value is "100" and the candidate column data type is "integer," a direct match is determined. If the candidate column is "string," further processing is required.

[0047] Automatic conversion of non-standard formats: Automatically convert incompatible data types. For example, converting "one hundred" to the integer 100 to fit an "integer" column, or converting "2025-06-26" to a date format to fit a "date" column. If the conversion fails (for example, "outpatient volume" cannot be converted to a date format), the system marks the candidate column as "incompatible" and removes it.

[0048] Output verification results: Generate a list of candidate columns after data type verification and verification status (such as "compatible", "need to be converted", "incompatible"), for example {"Candidate column": "Inpatient statistics table.Average_Hospital_Days", "Verification status": "Compatible"}.

[0049] In S2012, the system further optimized the candidate column ranking based on the sample values ​​of the medical database columns: Semantic similarity calculation: Using an embedding model (such as BERT), slot values ​​and example values ​​of candidate columns are vectorized and their semantic similarity is calculated. For example, the slot value "未下案" may be more similar to the example value "active" than "completed," thus giving priority to matching "case table.status" over "patient table.status."

[0050] Dynamic sorting of candidate columns: Candidate columns are dynamically sorted based on semantic similarity scores, with columns with high similarity being prioritized. For example, if "Average Stay" matches "Hospitalization Statistics Table.Average_Hospital_Days" (similarity 0.95) and "Department Statistics Table.Average_Stay" (similarity 0.85), the former will be prioritized.

[0051] Output the sorted candidate column list: Generate an optimized candidate column list and its sorting weights, for example, {"Candidate column sorting":"Inpatient statistics table.Average_Hospital_Days","Department statistics table.Average_Stay","Sort by":"Semantic similarity"}.

[0052] In S2013, the system verifies the logic of candidate column combinations based on the primary and foreign key relationships in the medical database: Primary-foreign key path check: Verify if the candidate columns meet the primary-foreign key association rules. For example, if the slot value "patient ID" needs to be associated with the "diagnosis table", the system checks if there is a valid primary-foreign key path (e.g., "patient table.patient_id" → "diagnosis table.patient_id").

[0053] Business logic check: Combine medical business rules (e.g., "patient ID must be associated with the diagnosis table") to exclude candidate column combinations that do not meet logical requirements. For example, if the candidate column "diagnosis table.patient_id" has a foreign key association with "patient table.patient_id", it is retained; if the candidate column "patient table.status" has no direct association with "diagnosis table.status", it is excluded.

[0054] Output final matching results: Generate the final matching medical database columns and confidence scores. For example, { "final matching column": "hospital statistics table.Average_Hospital_Days", "confidence score": 0.92}, where the confidence score takes into account data type verification, example value similarity, and primary-foreign key relationship weight.

[0055] Through data type verification, example value matching, and primary-foreign key relationship optimization, the accuracy and reliability of schema linking in the medical field Text-to-SQL task are significantly improved. Among them, data type adaptation ensures that the slot value and the database column are compatible in data format, avoiding query failure due to format errors; example value matching optimizes candidate column ordering through semantic similarity calculation, prioritizing the most relevant columns in the business scenario (e.g., "unresolved" corresponding to "case table.status"); primary-foreign key relationship check ensures that table connection logic meets the association rules of medical databases (e.g., "patient ID" correctly associated with "diagnosis table"). Finally, this multi-dimensional verification mechanism effectively solves the core problems of slot value and database column matching errors, table connection logic errors, etc., providing accurate technical support for intelligent data analysis.

[0056] S300, based on the final matching medical database column and the confidence score, identify the uncertainty types specific to the medical field, including medical term ambiguity, business rule conflict, and missing key slots; dynamically generate clarification questions and suggestion options for medical users based on the uncertainty types; receive user feedback on the clarification questions and suggestion options and update the medical slot information, output the corrected slot name-slot value pair and the corrected confidence score.

[0057] Among them, the detailed execution process of S300 includes the following sub-steps: Step 1, based on the final matched medical database column and confidence score, analyze the inconsistency between the current slot value and the database column, identify three types of uncertainty specific to the medical field: Ambiguity of medical terms: For example, the user input "average hospitalization days" may correspond to "average hospitalization day" or "average hospitalization days", it needs to be judged whether there is polysemy.

[0058] Business rule conflict: For example, the slot value "patient ID" may be associated with multiple tables (such as "diagnosis table" and "case table"), but according to the medical business rules, it needs to match the main table (such as "diagnosis table") first.

[0059] Missing key slots: For example, the user does not explicitly provide the "department name" or "diagnosis time" and other key information, resulting in incomplete query conditions. By classifying the uncertainty type, it provides the basis for subsequent targeted clarification questions, avoiding blind feedback.

[0060] Step 2, according to the identified uncertainty type, dynamically generate concise and clear clarification questions and suggestion options: For ambiguity of medical terms: Generate questions such as "Do you mean 'average hospitalization day' or 'average hospitalization days' for 'average hospitalization days'?" and provide options (such as "Option 1: average hospitalization day", "Option 2: average hospitalization days").

[0061] For business rule conflicts: Generate questions such as "The current 'patient ID' can be associated with 'diagnosis table' or 'case table', which table do you want to match first?" and provide options (such as "Option 1: diagnosis table", "Option 2: case table").

[0062] For missing key slots: Generate questions such as "You did not provide 'department name', do you need to supplement this information to complete the query?" and provide options (such as "Option 1: supplement department name", "Option 2: ignore this field"). By structuring the question to guide the user to clarify the intention, reduce ambiguity, and provide options to speed up user decision-making.

[0063] Step 3, receive user feedback on clarification questions and suggestion options, and dynamically adjust slot information: Parse user selection: If the user selects "Option 1: average hospitalization day", update the slot value to "average hospitalization day"; if the user selects "Option 2: ignore this field", remove the slot.

[0064] Update confidence score: Adjust the confidence score according to user feedback. For example, if the user explicitly selects a high matching item (such as "diagnosis table"), the confidence score is increased; if the user selects a low matching item (such as "ignore this field"), the confidence score is decreased.

[0065] Output correction result: generate the corrected slot name-slot value pair and updated confidence score, for example {“slot name”: “average hospital stay”, “slot value”: “10.5”, “confidence score”: 0.95}.

[0066] Objective: Through real-time feedback and closed loop, ensure that the slot information is consistent with the user's real needs, and quantify the confidence change to guide the subsequent SQL generation.

[0067] It should be noted here that in the updating process of the corrected slot name-slot value pair, the method further comprises: Step 1, based on the user's confirmation of the non-standard format slot value, update the slot value and mark it as standard format, that is, when the user confirms the non-standard format slot value (such as “10 days” or “unconcluded”), the system automatically converts it to a database-compatible standard format (such as “10” or “open”) and marks it as “standardized”. For example: the user inputs “hospitalization days for 10 days”, the system identifies “10 days” as a non-standard format, converts it to an integer “10” and marks it as “integer type”; the user inputs “case status as unconcluded”, the system identifies “unconcluded” as a non-standard format, converts it to “open” and marks it as “string type”.

[0068] Step 2, based on the user's explicit selection of the candidate column, update the slot value and preferentially match the candidate column, that is, when the user explicitly selects a column (such as “diagnosis table. patient_id” or “case table. status”) from multiple candidate columns, the system binds the slot value to the column and marks it as “preferentially matched”. For example: the user selects “diagnosis table. patient_id” as the candidate column for “patient ID”, the system updates the slot value to {“slot name”: “patient ID”, “slot value”: “12345”, “candidate column”: “diagnosis table. patient_id”, “priority”: “high”}. If the user does not select other candidates, the system defaults to ignoring low-priority columns and only retaining the user-confirmed column.

[0069] Step 3, based on the data type-corrected slot value and candidate column identification, integrate and generate the corrected slot name-slot value pair, that is, the system integrates the standardized slot value (such as “10”) with the preferentially matched candidate column identification (such as “diagnosis table. patient_id”) to generate the final slot name-slot value pair, and verifies that it conforms to the medical business rules: Data type verification: Ensure that the standardized slot value is consistent with the data type of the candidate column (e.g., "10" is an integer, matching the "patient_id" column). • Primary key verification: Verify whether there is a primary key association between candidate columns (e.g., whether "diagnosis table. patient_id" and "case table. patient_id" are consistent).

[0070] Output result: Generate final slot information that meets medical business rules, such as {"slot name": "patient ID", "slot value": "12345", "candidate column": "confidence score": 0.98, "standard format": "standardized", "priority": "high"}.

[0071] Through non-standard value standardization, candidate column priority matching, and business rule verification, the problems of inconsistent slot value format and ambiguous candidate columns in the medical scene are solved, ensuring that the final slot information not only meets the database format requirements but also accurately associates with core business tables, providing high-quality and compliant input basis for intelligent data analysis.

[0072] S400, based on the corrected slot name-slot value pair, the final matched medical database column, and the sub-scene label, generate a SQL query that meets the medical business rules; pass the generated SQL query to the medical database execution module and output the corresponding analysis result.

[0073] The detailed execution process of S400 includes the following sub-steps: Step 1, the system generates a SQL query statement that meets the medical business rules based on the corrected slot name-slot value pair (e.g., {"slot name": "patient ID", "slot value": "12345", "candidate column": "diagnosis table. patient_id"}), the final matched medical database column (e.g., "diagnosis table. patient_id"), and the sub-scene label (e.g., "patient diagnosis record query"). For example: Scenario 1, single table query: If the slot information points to a single table (e.g., "diagnosis table"), generate a query similar to SELECT * FROM diagnosis table WHERE patient_id = '12345';.

[0074] Scenario 2, multi-table association query: If it involves primary key association (e.g., "patient table. patient_id" and "diagnosis table. patient_id"), generate a query similar to SELECT patient table. name, diagnosis table. diagnosis FROM patient table INNER JOIN diagnosis table ON patient table. patient_id = diagnosis table. patient_id WHERE diagnosis table. patient_id = '12345';.

[0075] Scenario 3, Aggregated Statistics: If the slot contains statistical requirements (such as "average hospital stay"), generate a query similar to SELECT AVG(hospital stay) FROM diagnosis table WHERE department = 'internal medicine';.

[0076] By parsing the corrected slot information and business scenario tags, generate SQL statements that accurately match the medical database structure, ensuring that the query logic is consistent with business requirements.

[0077] Step 2, before passing the SQL query to the execution module, the system performs the following verification: Syntax verification: Check if the SQL statement conforms to the database syntax specifications (such as whether the field name is correct, and whether the JOIN condition is complete).

[0078] Business rule verification: Ensure that the query logic complies with medical business rules (such as "patient ID" must be associated with "diagnosis table", not "case table").

[0079] Data range verification: If the slot value contains a time range (such as "2023-01-01 to 2023-12-31"), verify that the time format conforms to the database requirements (such as YYYY-MM-DD).

[0080] Through multi-dimensional verification, avoid query failure due to syntax errors or business logic errors, and improve execution success rate.

[0081] Step 3, pass the generated SQL query to the medical database execution module: Connect the database: Establish a connection through the pre-set medical database connection configuration (such as IP address, port, username, password); execute SQL query: submit the verified SQL statement to the database execution module to obtain the query result; process execution result: if the execution is successful, return the query result (such as patient diagnosis record list), if the execution fails (such as database connection timeout, insufficient permissions), record error logs and feedback to the user interface (such as prompt "query failed, please check network or permission settings").

[0082] Through the execution process of step 2 above, it can be ensured that the SQL query is executed efficiently and safely in the real medical database environment, and the execution status is fed back in a timely manner.

[0083] Step 4, output the corresponding analysis results: Result formatting: Convert raw query results (e.g., JSON or table data) into user-friendly formats (e.g., tables with headers, statistical charts); Add explanations: Add business explanations to the results (e.g., "3 records found for 'internal medicine' diagnosis"); Return user interface: Display the final results to the user through the front-end interface (e.g., pop-up display or export as an Excel file).

[0084] By converting the corrected slot information into a SQL query that complies with medical business rules, and combining compliance verification and execution optimization, the natural language query is accurately mapped to the database operation, while ensuring stable execution and readable results, ultimately achieving an efficient closed loop for medical data analysis.

[0085] In the embodiments of the present application, in the process of generating a SQL query that complies with medical business rules, the method further comprises: Step 1, the system combines the corrected slot name-slot value pair (e.g., "diagnosis time = 2023-05-15") and the sub-scene label (e.g., "patient hospitalization record query"), calls the preset medical business rule library, generates a preliminary SQL template and marks the rule adaptation status. For example: Time format verification: If the scene involves time range query, the system requires "diagnosis time" to comply with "year-month-day" format, otherwise it is marked as "format error"; Field dependency verification: If the scene is "patient hospitalization record", the system requires that "patient ID" and "hospitalization ID" fields must be included, otherwise it is marked as "field missing"; Value range limit verification: If the slot is "diagnosis type", the system requires that its value must come from the preset medical coding list (e.g., ICD-10 standard), otherwise it is marked as "value range abnormal".

[0086] Through business rule verification, it is ensured that the generated SQL template completely complies with the special specifications of the medical field in terms of syntax and logic, avoiding query failure or data deviation due to rule conflicts.

[0087] Step 2, the system dynamically adjusts the table connection logic according to the SQL template that passes the verification (e.g., "query records with diagnosis time of 2023-05-15") and the primary-foreign key relationship of the medical database (e.g., "patient table" and "diagnosis table" are associated through "patient ID"). Primary-foreign key priority matching: If the query involves multi-table association (e.g., "patient table" and "diagnosis table"), the system prioritizes using the primary-foreign key field (e.g., "patient ID") as the connection condition, ensuring the shortest connection path and compliance with business specifications. For example, the system will automatically associate "patient name" with "diagnosis record" through "patient ID", rather than redundant fields.

[0088] Redundant connection elimination: If the SQL template contains unrelated tables (e.g., "case table" and "diagnosis table" have no direct connection), the system automatically removes redundant connections to reduce computational resource consumption.

[0089] Index optimization suggestion: If the connection field is not indexed (e.g., "diagnosis time"), the system will prompt to add an index for this field in the database to improve query efficiency.

[0090] Through the connection optimization driven by the primary-foreign key relationship, the SQL query is ensured to meet the business logic while maximizing execution efficiency and reducing redundant operations.

[0091] Step 3, the system passes the optimized SQL query (e.g., "query the diagnosis record of a patient according to the patient ID") to the medical database execution module, and completes the following steps: Securely connect to the database: Establish a stable connection through pre-set database connection parameters (e.g., IP address, port, username, password); Execute the query and get the result: After submitting the SQL query, the system obtains the original data (e.g., a list of patient diagnosis records) from the database; Result processing and feedback: If the query is successful, the system converts the result into a user-friendly format (e.g., table or chart) and adds business explanations (e.g., "a total of 3 records meet the conditions"); if the query fails (e.g., field does not exist or insufficient permissions), the system records error logs and provides prompt information (e.g., "please check if the 'diagnosis time' field exists").

[0092] Through the execution process of the above steps, the SQL query can be efficiently executed in the real medical database environment, and the user interaction experience can be improved through the result processing mechanism.

[0093] Through business rule verification, primary-foreign key driven connection optimization, and execution result processing, the compliance and efficiency of the medical field Text-to-SQL task are further strengthened. The specific effects include: through the pre-defined medical business rule library, it is ensured that the generated SQL template is completely consistent with the medical scene requirements in terms of semantics and logic; based on the primary-foreign key relationship, the table connection path is dynamically adjusted to reduce redundant operations and improve query performance; through the formatted output and error feedback mechanism, it is ensured that the user obtains accurate and interpretable analysis results.

[0094] In the embodiments of the present application, the medical database execution module includes the following steps: Step 1, when the generated SQL query fails to execute in the medical database (e.g., field does not exist, insufficient permissions, syntax error), the system automatically triggers an exception handling process: Error classification identification: The system identifies the type of exception based on error codes or information (e.g., "field does not exist" "insufficient permissions" "connection timeout"); User prompt generation: Generate corresponding prompt information for different exception types (e.g., "Please check if the 'diagnosis time' field exists" "The current user has no permission to access the 'patient table'"); Administrator notification mechanism: If it is a system-level error (such as database service unavailable), the system automatically sends a notification to the medical database administrator's mailbox or intranet message, facilitating rapid response.

[0095] Through classification prompts and automated notifications, help users accurately locate problems and quickly fix them, while ensuring the stability of database services.

[0096] Step 2, the system filters sensitive data from the original results returned by SQL queries (such as patient name, ID number, diagnosis details) to ensure compliance with medical data security and privacy protection requirements: Data desensitization rules application: Anonymization: Desensitize direct identifiers such as patient names and ID numbers (e.g., "Zhang San" → "XXX"); Fuzzification: Fuzz indirect identifiers such as addresses and phone numbers (e.g., "Beijing Chaoyang District XX Street 123" → "Beijing Chaoyang District XX Street XXXX").

[0097] Compliance verification: Verify the desensitized content according to medical data security standards (such as "Personal Information Protection Law" "HIPAA") to ensure that sensitive information is not leaked.

[0098] Dynamic filtering strategy: Dynamically adjust the filtering strength according to user roles (e.g., normal users only show desensitized data, administrators can view complete data).

[0099] Through multi-level desensitization and compliance verification, ensure that query results meet business needs while strictly protecting patient privacy and data security.

[0100] Step 3, the system returns the filtered safe results to the interactive interface (such as web, mobile or desktop applications) in a user-friendly format, completing the query loop: Result formatting: Convert raw data into tables, charts or text summaries (e.g., "3 records found that meet the conditions"); Interaction enhancement: Support users to perform secondary operations on the results (such as exporting to Excel, filtering specific fields, viewing raw data details); Status feedback: Display query status (such as "query successful" "part of the data is desensitized" "exception prompt") in the interface, making it easy for users to understand the source and integrity of the results.

[0101] Through intuitive display and interactive functions, the user's understanding and use efficiency of the query results are improved, and the data processing status is clearly marked to enhance the user's trust. Through the exception handling mechanism, SQL execution problems are quickly located and repaired, combined with the data desensitization strategy to strictly protect patient privacy, and the analysis results are efficiently delivered in a user-friendly manner, thereby achieving comprehensive security, compliance, and user experience in medical database operations, providing an end-to-end reliable closed-loop process for medical data analysis.

[0102] Based on the scheme, assume that the user inputs a natural language query: "Query the patient ID of patients who visited the internal medicine department in 2023 and have not been closed".

[0103] S100-S200: The system first identifies the user's intent through natural language processing technology (S100) and extracts key information: "2023" (time range), "internal medicine" (department), and "not closed" (case status). Then, S200 uses the table structure and field description of the medical database to match the slots to the candidate columns, such as "diagnosis table.diagnosis date" (time field), "diagnosis table.department name" (department field), and "case table.case status" (status field), generating preliminary slot name-slot value pairs such as "time: 2023, department: internal medicine, status: not closed".

[0104] S300-S400: In S300, the system converts the non-standard format "2023" to a standard date range (e.g., January 1, 2023 to December 31, 2023) through user confirmation and marks it as "date type"; "not closed" is mapped to the standard status code in the database (e.g., "open"). At the same time, based on the user's selected candidate columns (e.g., "diagnosis table.department name"), the system optimizes the table join logic to ensure that the query directly associates the primary and foreign key fields (e.g., patient ID) of the "diagnosis table" and "case table". Finally, a SQL template that conforms to medical business rules is generated, such as connecting the diagnosis table and case table, using patient ID as the association field, and filtering records with diagnosis date in 2023, department as internal medicine, and case status as not closed.

[0105] In S400, after the system executes the query, if it detects insufficient field permissions (e.g., "case table.case status" is not accessible), it will trigger an exception handling process to prompt the user to check the input or contact the administrator. At the same time, the returned patient ID is filtered for sensitive data (e.g., desensitization processing), and only part of the information (e.g., PXXX001) is displayed. Finally, the results are returned to the user interface in the form of a table, and "part of the data is desensitized" is marked. The entire process solves the problems of format inconsistency, ambiguous matching, and data leakage in traditional queries through business rule verification, primary and foreign key optimization, and privacy protection mechanisms, demonstrating the innovation of the scheme in intelligent and compliant queries in the medical field.

[0106] The embodiment of the application discloses an intelligent slot filling and schema linking system based on RAG and M-Schema, referring to Figure 2 , comprising: The matching degree acquisition module 001 receives a natural language query in the medical field through a user question input interface, performs text similarity matching based on a pre-set FAQ knowledge base in the medical field through a RAG-FAQ fast matching module, and is used to acquire a corresponding matching degree. If the matching degree is higher than a pre-set matching threshold, a pre-defined medical intent and slot structure are directly extracted, and a corresponding preliminary intent label, slot name-slot value pair and optional subdivision scene label are output based on the medical intent and slot structure. If no matching is found or the matching confidence is lower than the pre-set matching threshold, a NLU fine-grained analysis module is started, a fine-tuned sequence labeling model is used to classify the intent and extract the slot of the user question, and a corresponding preliminary intent label, slot name-slot value pair and optional subdivision scene label are output. The retrieval module 002 retrieves the context from the medical field knowledge base based on the preliminary intent label, slot name-slot value pair and subdivision scene label through a RAG-medical field knowledge base context enhancement module, performs entity linking and normalization on the preliminarily extracted slot value, combines the entity linked and normalized slot value with the M-Schema metadata of the target medical database for multi-dimensional verification, and outputs the finally matched medical database column and confidence score. The M-Schema metadata includes column name, column description, data type, example value and primary-foreign key relationship. The medical slot information updating module 003 identifies the uncertainty types specific to the medical field based on the finally matched medical database column and confidence score, and the uncertainty types include medical term ambiguity, business rule conflict and missing key slot. The clarification questions and suggestion options for medical users are dynamically generated based on the uncertainty types. User feedback on the clarification questions and suggestion options is received and used to update the medical slot information, and the corrected slot name-slot value pair and corrected confidence score are output. The SQL query generation module 004 is used to generate a SQL query conforming to the medical business rules based on the corrected slot name-slot value pair, finally matched medical database column and subdivision scene label. The generated SQL query is transmitted to the medical database execution module, and the corresponding analysis result is output.

[0107] The embodiment of the application also discloses an intelligent slot filling and schema linking system based on RAG and M-Schema, comprising a processor, and the processor runs a program of the intelligent slot filling and schema linking method based on RAG and M-Schema.

[0108] The embodiment of the present application further discloses a storage medium, which stores the program of the intelligent slot filling and mode linking method based on RAG and M-Schema.

[0109] Although the embodiments of the present application have been shown and described above, it should be understood by those skilled in the art that the above embodiments are exemplary and cannot be understood as limiting the present application, and those skilled in the art can make changes, modifications, replacements and variations to the above embodiments within the scope of the present application.

Claims

1. An intelligent slot filling and mode linking method based on RAG and M-Schema, characterized in that: include: Receive natural language queries in the medical field through the user question input interface, perform text similarity matching based on the preset medical field FAQ knowledge base through the RAG-FAQ fast matching module, obtain the corresponding matching degree, and directly extract the predefined medical intent and slot structure if the matching degree is higher than the preset matching threshold, and output the corresponding preliminary intent label, slot name-slot value pair and optional segmented scenario label based on the medical intent and slot structure; if there is no match or the matching confidence is lower than the preset matching threshold, start the NLU fine-grained parsing module, use the fine-tuned sequence annotation model to perform intent classification and slot extraction on the user question, and output the corresponding preliminary intent label, slot name-slot value pair and optional segmented scenario label; Based on the preliminary intent label, slot name-slot value pair and segmented scenario label, the context is retrieved from the medical domain knowledge base through the RAG-medical domain knowledge base context enhancement module, the preliminary extracted slot values ​​are entity linked and normalized, and the entity links and normalized slot values ​​are combined with the M-Schema metadata of the target medical database for multi-dimensional verification, and the final matching medical database column and confidence score are output. The M-Schema metadata includes column name, column description, data type, example value, primary and foreign key relationships; identifying uncertainty types specific to the medical field based on the final matched medical database columns and the confidence scores, the uncertainty types including medical term ambiguity, business rule conflicts, and missing key slots; dynamically generating clarification questions and suggested options for medical users based on the uncertainty types; receiving user feedback on the clarification questions and suggested options, updating medical slot information, and outputting revised slot name-slot value pairs and revised confidence scores; Generate an SQL query that complies with medical business rules based on the modified slot name-slot value pair, the final matching medical database column and the segmented scenario label; pass the generated SQL query to the medical database execution module and output the corresponding analysis result.

2. The intelligent slot filling and mode linking method based on RAG and M-Schema according to claim 1, characterized in that: The RAG-medical knowledge base context enhancement module performs entity linking and normalization on the initially extracted slot values ​​through the following steps, and the method further includes: Based on the initially extracted slot values ​​and the entity alias mapping table in the medical knowledge base, the slot values ​​are linked to the standard entity names in the medical knowledge base through semantic similarity calculation, and the normalized slot values ​​and corresponding entity identifiers are output; Based on the normalized slot value and medical business rules, the normalized slot value is checked for compliance, the statistical scope is adjusted or sensitive fields are filtered, and the final slot value and business rule verification status that meet the compliance requirements of the medical database are output.

3. The intelligent slot filling and mode linking method based on RAG and M-Schema according to claim 2, characterized in that: In the process of multi-dimensional verification, the method also includes: Based on the final slot value and the data type definition of the medical database column, check the compatibility of the slot value with the data type of the medical database column, automatically convert the non-standard format, and output the candidate column after data type verification and verification status; Based on the verified candidate columns and the sample values ​​of the medical database columns, the matching degree between the slot values ​​and the sample values ​​is compared through semantic similarity calculation, the candidate items are sorted, and the sorted candidate column list is output; Based on the primary and foreign key relationships between the candidate column list and the medical database, the candidate column combination is optimized to ensure that the table connection logic meets the medical business requirements, and the final matching medical database columns and confidence scores are output.

4. The intelligent slot filling and mode linking method based on RAG and M-Schema according to claim 3, characterized in that: The method also includes: Based on the final matched medical database columns and confidence scores, identify medical term ambiguities where slot values ​​are mapped to multiple candidate columns, and generate clarification questions to determine the corresponding candidate columns. Based on the confidence score and medical business rules, determine whether there are missing key slots and generate supplementary suggestions to complete the corresponding slot information; Based on the integration of candidate column pointers and slot information, clarification questions and suggested options are generated for medical users, and clarification interaction content is output for user confirmation.

5. The intelligent slot filling and mode linking method based on RAG and M-Schema according to claim 4, characterized in that: During the update of the correct slot name-slot value pair, the method further comprises: Based on the user's confirmation of the non-standard format slot value, the slot value is updated and marked as standard format, and the slot value and marking status after the data type is corrected are output; Based on the user's explicit selection of the candidate column, the slot value is updated and the candidate column is matched first, and the corrected slot value and candidate column identifier of the ambiguous candidate are output; Based on the slot values ​​after the data type correction and the candidate column identifiers after the ambiguous candidate items are corrected, the corrected slot name-slot value pairs are integrated and generated, and the final slot information that complies with the medical business rules is output.

6. The intelligent slot filling and mode linking method based on RAG and M-Schema according to claim 5, characterized in that: In the process of generating an SQL query that complies with medical business rules, the method further includes: Based on the revised slot name-slot value pairs and segmented scenario labels, specific business rules are applied to output the SQL template and rule adaptation status after business rule verification. Based on the SQL template verified by business rules and the primary and foreign key relationships of the medical database, optimize the table connection logic to ensure that the SQL query complies with medical business specifications and output the final generated SQL query statement; The final generated SQL query statement is passed to the medical database execution module to output the corresponding analysis results.

7. The intelligent slot filling and mode linking method based on RAG and M-Schema according to claim 1, characterized in that: The medical database execution module includes the following steps: Based on the generated SQL query execution results, if an SQL query execution failure is detected, the exception handling process is triggered, prompting the user to check the input or contact the medical database administrator, and outputting the exception handling prompt information; Filter sensitive data based on the query results to ensure compliance with medical data security and privacy protection requirements, and output the final analysis results after security filtering; The final analysis results are returned to the user interaction interface to complete the closed-loop interaction of medical database query.

8. An intelligent slot filling and mode linking system based on RAG and M-Schema, characterized in that: include: The matching degree acquisition module receives natural language queries in the medical field through the user question input interface, and performs text similarity matching based on the preset medical field FAQ knowledge base through the RAG-FAQ fast matching module to obtain the corresponding matching degree. If the matching degree is higher than the preset matching threshold, the predefined medical intent and slot structure are directly extracted, and the corresponding preliminary intent label, slot name-slot value pair and optional segmented scenario label are output based on the medical intent and slot structure; if there is no match or the matching confidence is lower than the preset matching threshold, the NLU fine-grained parsing module is started, and the user question is classified and slot extracted using the fine-tuned sequence annotation model, and the corresponding preliminary intent label, slot name-slot value pair and optional segmented scenario label are output; A retrieval module, based on the preliminary intent label, slot name-slot value pair and segmented scenario label, retrieves context from the medical domain knowledge base through the RAG-medical domain knowledge base context enhancement module, performs entity linking and normalization on the initially extracted slot values, and performs multi-dimensional verification on the entity links and normalized slot values ​​in combination with the M-Schema metadata of the target medical database, and outputs the final matching medical database column and confidence score, wherein the M-Schema metadata includes column name, column description, data type, example value, primary and foreign key relationships; a medical slot information update module, which identifies uncertainty types unique to the medical field based on the final matched medical database column and the confidence score, including medical terminology ambiguity, business rule conflicts, and missing key slots; dynamically generates clarification questions and suggested options for medical users based on the uncertainty types; receives user feedback on the clarification questions and suggested options and uses it to update medical slot information, and outputs revised slot name-slot value pairs and revised confidence scores; The SQL query generation module is used to generate an SQL query that complies with medical business rules based on the modified slot name-slot value pair, the final matching medical database column and the segmented scenario label; the generated SQL query is passed to the medical database execution module to output the corresponding analysis results.

9. An intelligent slot filling and mode linking system based on RAG and M-Schema, characterized in that: The method comprises a processor running a program of the intelligent slot filling and mode linking method based on RAG and M-Schema according to any one of claims 1 to 7.

10. A storage medium, characterized in that: A program for the intelligent slot filling and mode linking method based on RAG and M-Schema as described in any one of claims 1 to 7 is stored.

Images