A Smart Slot Filling and Pattern Linking Method Based on RAG and M-Schema

Abstract

This application relates to the field of natural language processing (NLP) technology, and discloses an intelligent slot filling and pattern linking method based on RAG and M-Schema. The method includes: quickly matching a pre-built FAQ knowledge base using the RAG-FAQ module to extract predefined medical intents and slot structures; if matching fails, activating the NLU module for intent classification and slot extraction; using the RAG-medical domain knowledge base context enhancement module to perform entity linking and normalization of slot values, and combining this with multi-dimensional verification using the target database's M-Schema metadata, outputting matching columns and confidence scores; dynamically generating clarification questions and receiving user feedback for uncertainties such as ambiguity in medical terminology and conflicts in business rules, correcting slot information, generating SQL queries that conform to business rules, and finally passing the results to the medical database execution module. This application can improve the usability and accuracy of a general framework in hospital management scenarios.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of natural language processing, and in particular to an intelligent slot filling and pattern 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 pattern linking, and SQL optimizers, and exhibits generality 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 general frameworks still have 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 general frameworks in the face of hospital management field scenarios remains to be solved. SUMMARY

[0004] In order to improve the usability and accuracy of general frameworks in the face of hospital management field scenarios, the application provides an intelligent slot filling and pattern linking method based on RAG and M-Schema.

[0005] In a first aspect, the application provides an intelligent slot filling and pattern linking method based on RAG and M-Schema, which adopts the following technical solution:

[0006] An intelligent slot filling and pattern linking method based on RAG and M-Schema, comprising:

[0007] 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 to obtain a matching degree. If the matching degree is higher than a preconfigured 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 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 slots, and a corresponding preliminary intent label, slot name-slot value pair, and optional sub-scene label are output.

[0008] 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;

[0009] identify the uncertainty types specific to the medical field 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;

[0010] 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.

[0011] Optionally, the RAG-medical domain knowledge base context enhancement module performs entity linking and normalization on the preliminary extracted slot value through the following steps, and the method further comprises:

[0012] 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;

[0013] 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.

[0014] Optionally, during the multi-dimensional verification process, the method further comprises:

[0015] 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;

[0016] 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 candidate item sorting, and output the sorted candidate column list;

[0017] Based on the primary-foreign key relationship 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 matched medical database column and confidence score are output.

[0018] Optionally, the method further comprises:

[0019] Based on the final matched medical database column and confidence score, identify the ambiguity of the medical term when the slot value is mapped to multiple candidate columns, and generate a clarification question to determine the corresponding candidate column direction;

[0020] Based on the confidence score and medical business rules, determine whether there are missing key slots, and generate a supplement suggestion option to perfect the corresponding slot information;

[0021] Based on the candidate column direction and slot information integration, generate a clarification question and suggestion option for medical users, and output the clarification interaction content to be confirmed by the user.

[0022] Optionally, in the updating process of the slot name-slot value pair, the method further comprises:

[0023] Based on the user's confirmation of the non-standard format slot value, update the slot value and mark it as a standard format, and output the slot value after data type correction and the marked state;

[0024] Based on the user's explicit selection of the candidate column direction, update the slot value and preferentially match the candidate column, and output the slot value after ambiguity candidate option correction and candidate column identification;

[0025] Based on the slot value after data type correction and the candidate column identification after ambiguity candidate option correction, integrate the corrected slot name-slot value pair, and output the final slot information that meets the medical business rules.

[0026] Optionally, in the process of generating a SQL query that meets the medical business rules, the method further comprises:

[0027] Based on the corrected slot name-slot value pair and the sub-scene label, apply specific business rules, and output the SQL template after business rule verification and rule adaptation state;

[0028] Based on the SQL template after business rule verification and the primary-foreign key relationship of the medical database, optimize the table connection logic to ensure that the SQL query meets the medical business specifications, and output the final generated SQL query statement;

[0029] Pass the final generated SQL query statement to the medical database execution module, and output the corresponding analysis result.

[0030] Optionally, the medical database execution module comprises the following steps:

[0031] Based on the generated SQL query execution result, if it is detected that the SQL query execution fails, an exception handling process is triggered, prompting the user to check the input or contact the medical database administrator, and outputting an exception handling prompt information;

[0032] Based on the query result content, sensitive data is filtered to ensure compliance with medical data security and privacy protection requirements, and the final analysis result after security filtering is output;

[0033] The final analysis result is returned to the user interaction interface, completing the closed-loop interaction of the medical database query.

[0034] In a second aspect, the application provides an intelligent slot filling and mode linking system based on RAG and M-Schema, which adopts the following technical solution:

[0035] An intelligent slot filling and mode linking system based on RAG and M-Schema, comprising:

[0036] 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, the pre-defined medical intent and slot structure are directly extracted, and the 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, the NLU fine-grained analysis module is started, the fine-tuned sequence labeling model is used to classify the intent and extract the slot of the user question, and the corresponding preliminary intent label, slot name-slot value pair and optional sub-scene label are output.

[0037] A retrieval module, 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 a RAG-medical field knowledge base context enhancement module, performs entity linking and normalization on the preliminarily extracted slot value, and combines the entity linked and normalized slot value 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;

[0038] The medical slot information updating module identifies the uncertainty type specific to the medical field based on the final matched medical database column and the confidence score, and the uncertainty type includes medical term ambiguity, business rule conflict, and missing key slot; the clarification question and the suggestion option facing the medical user are dynamically generated based on the uncertainty type; the user feedback of the user to the clarification question and the suggestion option is received and used to update the medical slot information, and the corrected slot name-slot value pair and the corrected confidence score are output;

[0039] The SQL query generation module is used to generate the SQL query conforming to the medical business rule based on the corrected slot name-slot value pair, the final matched medical database column, and the subdivided scene label; and the generated SQL query is transmitted to the medical database execution module, and the corresponding analysis result is output.

[0040] In a third aspect, the present application provides an intelligent slot filling and schema linking system based on RAG and M-Schema, which adopts the following technical solution:

[0041] An intelligent slot filling and schema linking system based on RAG and M-Schema comprises a processor, and the processor runs the program of the intelligent slot filling and schema linking method based on RAG and M-Schema according to any one of the above.

[0042] In a fourth aspect, the present application provides a storage medium, which adopts the following technical solution:

[0043] A storage medium stores the program of the intelligent slot filling and schema linking method based on RAG and M-Schema according to any one of the above.

[0044] In summary, the present application has at least one of the following beneficial technical effects: through the deep integration of RAG and M-Schema, the present application significantly improves the usability and accuracy of the general framework in the medical field. Specifically:

[0045] By quickly matching high-frequency medical scenarios (such as "querying the patient's medical record in a certain department") through the RAG-FAQ module, combining dynamic clarification question generation and user feedback loop, the system greatly reduces the interaction failure caused by user input ambiguity or missing information, 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. Based on the entity linking and normalization of the medical knowledge base (such as mapping "angina pectoris" to ICD-10 code I20) and the multi-dimensional verification driven by M-Schema metadata (data type verification, primary-foreign key relationship optimization), the system ensures 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 verification and table connection logic optimization further strengthen the compliance of SQL generation, making the query results strictly conform to medical business specifications. By subdividing scene tags (such as "inpatient expense analysis" "chronic disease follow-up statistics") and dynamically adapting to medical business rules, the system can flexibly respond to diverse query requirements in hospital management (such as cross-department data association, time dimension statistics), solving the problem of insufficient requirements for professional terminology, data association, and privacy protection in general frameworks in medical scenarios, thereby realizing the precise closed loop from natural language to database operation. BRIEF DESCRIPTION OF DRAWINGS

[0046] 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.

[0047] 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

[0048] The embodiments of the present application are described in detail below with reference to the accompanying drawings. Examples of the embodiments are shown in the accompanying drawings.

[0049] In the description of the present specification, the description of the terms "certain embodiments", "one embodiment", "some embodiments", "illustrative embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in connection with the described embodiments or examples are included in at least one embodiment or example of the present application. In the present specification, the illustrative description of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0050] 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 (e.g., the equivalence of "average hospitalization days" and "average hospitalization days"); second, the database schema is complex and implies a large number of business rules (e.g., statistical standards, 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 (e.g., "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 due to misinterpretation of user input or incorrect linking of database columns.

[0051] 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. Through a hierarchical processing strategy and a dynamic interaction mechanism, the method achieves accurate parsing of natural language queries and deep adaptation of database schemas in the medical field. The core innovations of the present application include:

[0052] Hierarchical intent recognition and slot extraction: Combining RAG-FAQ fast matching and NLU fine-grained analysis, the method balances 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, the method solves the problems of medical term ambiguity and compliance; M-Schema multidimensional verification: Based on the metadata of medical databases (column name, data type, primary-foreign key relationship), the method performs data type verification, example value matching, and table connection optimization to ensure the accuracy of SQL generation; Dynamic clarification and user feedback loop: The method actively identifies uncertainties (such as term ambiguity and missing key slots) and generates clarification questions to guide users to provide additional information, improving interaction efficiency and query accuracy.

[0053] The technical implementation process of the present application will be described in detail below in conjunction with specific implementation steps. The present application discloses an intelligent slot filling and schema linking method based on RAG and M-Schema, which is described in detail with reference to Figure 1 , including.

[0054] 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 an RAG-FAQ rapid matching module, obtaining a 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 subdivision scene label based on the medical intent and slot structure; if no matching or 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 perform intent classification and slot extraction on the user question, and outputting a corresponding preliminary intent label, slot name-slot value pair and optional subdivision scene label.

[0055] The detailed execution process of S100 includes the following sub-steps:

[0056] Step 1: The user question input interface receives a natural language query in the medical field: first, the system receives a natural language query in the medical field through a user question input interface (such as an API interface, a 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 pages, mobile terminals, speech recognition systems, etc.), and ensure the uniformity of the input data format and the validity verification.

[0057] Step 2: After receiving the user input, the system calls the RAG-FAQ rapid 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:

[0058] Vectorization processing: convert the user question into a vector representation through a pre-trained embedding model (such as BERT, bge-base, etc.), and store the question and answer pairs in the FAQ knowledge base in a vectorized manner;

[0059] Similarity calculation: calculate the similarity scores of the user question vector and all question and answer pair vectors in the FAQ knowledge base through cosine similarity or Euclidean distance algorithms;

[0060] Matching threshold judgment: if the similarity score of a question and answer pair is higher than a pre-set matching threshold (such as 0.85), it is considered that the current user question is highly related to the question and answer pair, and the next step is performed; otherwise, the NLU fine-grained analysis process is triggered.

[0061] Step 3, when the matching degree is higher than the threshold, the system directly extracts the corresponding predefined 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.

[0062] It should be pointed out here that the above process relies on the predefined rules of the FAQ knowledge base to ensure quick response and consistent output for high-frequency questions.

[0063] 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 model (such as BiLSTM-CRF, BERT-BiLSTM, etc.) processes the user question as follows:

[0064] 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 (such as time, institution, indicator name) in the question and extract them as slot values using a sequence labeling model; structured output: generate a structured result consistent with the FAQ module, including preliminary intent label, slot name-slot value pair, and sub-scene label.

[0065] Step 5, whether through FAQ matching or NLU analysis, the system will output a unified format of preliminary results:

[0066] Preliminary intent label: such as "query indicator value";

[0067] Slot name-slot value pair: such as {"institution name": "A hospital", "time": "last month"};

[0068] Sub-scene label (optional): such as "hospitalization analysis".

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

[0070] 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.

[0071] 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.

[0072] The detailed execution process of S200 step includes the following sub-steps:

[0073] 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:

[0074] 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.

[0075] 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 a preset threshold (such as 0.9), it is considered as a candidate entity for subsequent processing.

[0076] 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 comprises:

[0077] S2001, after preliminary extraction of slot value, the system calls the entity alias mapping table in the medical knowledge base to match the non-standard terms input by the user with the standard entity names:

[0078] Alias mapping retrieval: Through the entity alias mapping table (such as "outpatient volume"→"outpatient visits", "average length of stay"→"average length of stay"), the common alias of the slot value is directly matched. If the slot value is completely consistent with a certain standard entity name, the entity name and the corresponding entity identifier (such as { "normalized slot value": "average length of stay", "entity ID": "HOS-001"} ) are directly output.

[0079] 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 slot value 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 length of stay" may be as high as 0.98, much higher than other candidate entities (such as "length of stay" 0.85).

[0080] Candidate entity screening: According to the similarity score, the top N candidate entities (such as N=3) are screened, and the entity with high correlation to the current scene (such as "hospital analysis") is preferentially selected according to the business rules. For example, in the "hospital analysis" scenario, "average length of stay" may be preferentially matched.

[0081] S2002, after completing entity linking, the system outputs the normalized slot value and the corresponding entity identifier:

[0082] Normalized result generation: Replace the non-standard term input by the user with the standard entity name in the knowledge base (such as "outpatient volume" is normalized to "outpatient visits"), and associate the entity identifier (such as { "normalized slot value": "outpatient visits", "entity ID": "HOS-002"}).

[0083] 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).

[0084] S2003, based on the normalized slot value, the system performs compliance verification based on medical business rules:

[0085] Statistical caliber adaptation: According to medical business rules (such as "outpatient visits are counted by day"), the statistical logic of the normalized slot value is supplemented or adjusted. 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"}.

[0086] Sensitive field filtering: Identify and filter sensitive fields that may involve patient privacy (such as "patient name" and "ID number"). For example, if the normalized slot value contains "patient ID", the system will check whether it belongs to a sensitive field and decide whether to retain or desensitize it according to the rules.

[0087] Business rule conflict detection: Check whether the normalized slot value conflicts with the business rules of the medical database. For example, if the user inputs "average hospitalization days" and requires excluding "unresolved cases", the system will check whether this condition conforms to the business rules of the medical database (such as whether it is allowed to filter by "case closure status").

[0088] S2004, after completing the compliance verification, the system outputs the final slot value and the business rule verification status:

[0089] Final slot value generation: Integrate the normalized slot value and the adjusted statistical caliber or filtering conditions (such as { "final slot value": "average hospitalization days", "statistical caliber", "exclude unresolved cases", "sensitive field filtering": true}).

[0090] Verification status marking: Mark the business rule verification status according to the verification result (such as "pass", "clarify", "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 (such as multiple candidate entities), it is marked as "clarify".

[0091] 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 meet the database specifications. Specifically, the system uses entity alias mapping table and semantic similarity calculation to map non-standard terms input by users (such as "average hospitalization days") to standard entity names (such as "average hospitalization days"), achieving term unification; through statistical caliber supplementation, sensitive field filtering and conflict detection, it ensures that the slot value meets the medical business specifications in terms of data statistical logic and privacy security; in addition, the output verification status (such as "clarify") 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.

[0092] Step 3: The system performs multi-dimensional verification of the normalized slot values ​​by combining the M-Schema metadata of the target medical database (including column names, column descriptions, data types, sample values, and primary and foreign key relationships):

[0093] S2011, after obtaining the final slot value, the system performs a compatibility check based on the data type definition of the medical database column (such as integer, string, date, etc.):

[0094] Data type matching check: Compare whether the data type of the slot value is consistent with that of the candidate column. For example, if the slot value is "one hundred" and the data type of the candidate column is "integer", it is necessary to determine whether a direct match is possible; if the candidate column is "string", further processing is required.

[0095] Automatic conversion of non-standard formats: Automatically converts mismatched data types. For example, converts "one hundred" to the integer 100 to fit an "integer" column, or converts "2025-06-26" to a date format to fit a "date" column. When a conversion fails (such as "outpatient volume" failing to convert to a date), the system marks the candidate column as "incompatible" and removes it.

[0096] Output validation results: Generate a list of candidate columns after data type validation and validation status (such as "compatible", "needs conversion", "incompatible"), for example {"candidate column": "hospital statistics table.Average_Hospital_Days", "validation status": "compatible"}.

[0097] In S2012, the system further optimized the candidate column sorting by combining sample values ​​from the medical database columns:

[0098] Semantic similarity calculation: The slot value and the example value of the candidate column are vectorized by an embedding model (such as BERT), and the semantic similarity between them is calculated. For example, the similarity between the slot value "unclosed" and the example value "active" may be higher than that between "completed", thus prioritizing the matching of "case table.status" rather than "patient table.status".

[0099] Dynamic sorting of candidates: Candidate columns are dynamically sorted based on semantic similarity scores, with priority given to candidate columns with high similarity. For example, if "Average length of stay" matches "Hospital Statistics Table.Average_Hospital_Days" (similarity 0.95) and "Department Statistics Table.Average_Stay" (similarity 0.85), the former will be sorted first.

[0100] Output the sorted candidate column list: Generate the optimized candidate column list and its sorting weights, for example, {"Candidate Column Sorting": "Hospital Statistics Table.Average_Hospital_Days", "Department Statistics Table.Average_Stay", "Sorting Basis": "Semantic Similarity"}.

[0101] S2013, the system verifies the logical consistency of candidate column combinations based on the primary and foreign key relationships in the medical database:

[0102] Primary and foreign key path check: Verifies whether candidate columns conform to primary and foreign key association rules. For example, if the slot value "Patient ID" needs to be associated with the "Diagnosis Table", the system will check whether a valid primary and foreign key path exists (such as "Patient Table.patient_id" → "Diagnosis Table.patient_id").

[0103] Business logic validation: Based on medical business rules (such as "patient ID must be associated with the diagnosis table"), eliminate candidate column combinations that do not conform to logic. For example, if the candidate column "diagnosis table.patient_id" has a foreign key relationship with "patient table.patient_id", it is retained; if the candidate column "patient table.status" has no direct relationship with "diagnosis table.status", it is discarded.

[0104] Output the final matching result: Generate the final matching medical database columns and their 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 validation, sample value similarity, and primary / foreign key relationship weights.

[0105] By optimizing data type validation, example value matching, and primary / foreign key relationships, the accuracy and reliability of schema linking in Text-to-SQL tasks within the medical field have been significantly improved. Specifically, data type adaptation ensures that slot values ​​are compatible with the data format of database columns, preventing query failures due to format errors; example value matching optimizes candidate column sorting through semantic similarity calculations, prioritizing the matching of the most relevant columns in the business scenario (e.g., "Unresolved Cases" corresponds to "Case Table.status"); and primary / foreign key relationship validation ensures that table join logic conforms to the association rules of medical databases (e.g., "Patient ID" correctly associates with "Diagnosis Table"). Ultimately, this multi-dimensional validation mechanism effectively solves core problems such as inaccurate matching of slot values ​​and database columns, and errors in table join logic, providing precise technical support for intelligent data analysis.

[0106] S300, identifying medical field-specific uncertainty types based on the final matched medical database column and confidence score, the uncertainty types including medical term ambiguity, business rule conflict, missing key slot; dynamically generating clarification questions and suggestion options for medical users based on the uncertainty types; receiving user feedback on the clarification questions and suggestion options and updating the medical slot information, and outputting the corrected slot name-slot value pair and the corrected confidence score.

[0107] The detailed execution process of S300 includes the following sub-steps:

[0108] 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, and identify three medical field-specific uncertainty types:

[0109] Medical term ambiguity: for example, the user input "average hospitalization days" may correspond to "average hospitalization day" or "average hospitalization days", and it needs to be determined whether there is polysemy.

[0110] 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, the main table (such as "diagnosis table") needs to be matched first.

[0111] Missing key slot: for example, the user does not explicitly provide the key information such as "department name" or "diagnosis time", resulting in incomplete query conditions. By classifying uncertainty types, it provides a basis for subsequent generation of targeted clarification questions, avoiding blind feedback.

[0112] Step 2, dynamically generate concise and clear clarification questions and suggestion options according to the identified uncertainty types:

[0113] For medical term ambiguity: generate questions such as "Do you mean 'average hospitalization day' or 'average hospitalization days'?" and provide options (such as "Option 1: average hospitalization day", "Option 2: average hospitalization days").

[0114] For business rule conflict: 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").

[0115] For missing key slot: 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.

[0116] Step 3: Receive user feedback on clarifying questions and suggested options and dynamically adjust slot information:

[0117] Parse user selection: If the user selects "Option 1: Average hospital stay," update the slot value to "Average hospital stay." If the user selects "Option 2: Ignore this field," remove the slot.

[0118] Update confidence score: Adjust the confidence score based on user feedback. For example, if the user explicitly selects a high-matching item (such as "Diagnosis table"), the confidence score increases. If the user selects a low-matching item (such as "Ignore this field"), the confidence score decreases.

[0119] Output the corrected result: Generate the corrected slot name-slot value pair and updated confidence score, such as { "Slot Name": "Average hospital stay", "Slot Value": "10.5", "Confidence Score": 0.95}.

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

[0121] It should be noted that in the process of updating the corrected slot name-slot value pair, the method further comprises:

[0122] Step 1: Based on user confirmation of non-standard format slot values, 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 "unresolved"), 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 is unresolved", the system identifies "unresolved" as a non-standard format, converts it to "open" and marks it as "string type".

[0123] Step 2: Based on the user's explicit selection of the candidate column, update the slot value and prioritize matching 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 "priority matching". 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.

[0124] Step 3: Based on the data type corrected slot value and candidate column identification, integrate to generate the corrected slot name-slot value pair, that is, the system integrates the standardized slot value (such as "10") with the priority-matched candidate column identification (such as "diagnosis table. patient_id") to generate the final slot name-slot value pair, and verifies its compliance with medical business rules:

[0125] Data type verification: Ensure that the standardized slot value is consistent with the data type of the candidate column (such as "10" for integer, matching "patient_id" column). • Primary key verification: Verify whether there is a primary key association between candidate columns (such as whether "diagnosis table. patient_id" and "case table. patient_id" are consistent).

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

[0127] Through non-standard value standardization, candidate column priority matching and business rule verification, the problems of non-uniform slot value format and ambiguous candidate columns in medical scenarios 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.

[0128] 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 complies with medical business rules; pass the generated SQL query to the medical database execution module and output the corresponding analysis result.

[0129] Among them, the detailed execution process of S400 step includes the following multiple sub-steps:

[0130] Step 1, the system dynamically generates SQL query statements that comply with 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"} and the final matched medical database column (e.g., "diagnosis table.patient_id"), combined with the sub-scene label (e.g., "patient diagnosis record query"). For example:

[0131] 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';.

[0132] Scenario 2, multi-table association query: If it involves primary-foreign 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';.

[0133] Scenario 3, aggregation statistics: If the slot contains statistical requirements (e.g., "average hospitalization days"), generate a query similar to SELECT AVG(hospitalization days) FROM diagnosis table WHERE department = 'internal medicine';.

[0134] By analyzing the corrected slot information and business scene labels, the system generates SQL statements that accurately match the medical database structure, ensuring that the query logic is consistent with business requirements.

[0135] Step 2, before passing the SQL query to the execution module, the system performs the following verification:

[0136] Syntax checking: Check if the SQL statement conforms to the database syntax specifications (e.g., whether the field name is correct, whether the JOIN condition is complete).

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

[0138] Data range verification: If the slot value contains a time range (e.g., "2023-01-01 to 2023-12-31"), verify that the time format complies with the database requirements (e.g., YYYY-MM-DD).

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

[0140] Step 3: Pass the generated SQL query to the medical database execution module:

[0141] Connect to the database: Establish a connection through the preset 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 the list of patient diagnosis records), 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").

[0142] 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 time.

[0143] Step 4: Output the corresponding analysis result:

[0144] Result formatting: Convert the original query result (such as JSON or table data) into a user-friendly format (such as a table with a title, statistical charts); Add explanation: Add business explanation (such as "a total of 3 diagnosis records conforming to 'internal medicine' are searched") in the result; Return to user interface: Display the final result to the user through the front-end interface (such as pop-up display or export as an Excel file).

[0145] By converting the corrected slot information into a SQL query that conforms to medical business rules, and combining compliance verification and execution optimization, it ensures that natural language queries are accurately mapped to database operations, while ensuring execution stability and result readability, ultimately achieving an efficient closed loop for medical data analysis.

[0146] In the embodiments of the present application, in the process of generating a SQL query that conforms to medical business rules, the method further comprises:

[0147] Step 1: The system combines the corrected slot name-slot value pair (such as "diagnosis time = 2023-05-15") and the sub-scene label (such as "patient hospitalization record query"), calls the preset medical business rule library, generates a preliminary SQL template and marks the rule adaptation status. For example:

[0148] Time format verification: If the scenario involves a time range query, the system requires that the "diagnosis time" must be in the "year-month-day" format. Otherwise, it is marked as "format error"; Field dependency verification: If the scenario is "patient hospitalization record", the system requires that both "patient ID" and "hospitalization ID" fields must be included. Otherwise, it is marked as "field missing"; Value range limitation verification: If the slot is "diagnosis type", the system requires that its value must come from a pre-set medical coding list (such as ICD-10 standard). Otherwise, it is marked as "value range abnormal".

[0149] Through business rule verification, ensure that the generated SQL template is completely consistent with the special specifications of the medical field in terms of syntax and logic, and avoid query failure or data deviation due to rule conflicts.

[0150] Step 2, the system adjusts the table connection logic according to the SQL template that passes the verification (such as "query records with diagnosis time of 2023-05-15") and the primary-foreign key relationship of the medical database (such as "patient table" and "diagnosis table" are associated through "patient ID"):

[0151] Primary-foreign key priority matching: If the query involves multi-table association (such as "patient table" and "diagnosis table"), the system prioritizes using the primary-foreign key field (such as "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.

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

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

[0154] Through primary-foreign key relationship driven connection optimization, ensure that the SQL query meets the business logic while maximizing execution efficiency and reducing redundant operations.

[0155] Step 3, the system passes the optimized SQL query (such as "query diagnosis records according to patient ID") to the medical database execution module and completes the following steps:

[0156] Securely connect to the database: Establish a stable connection through pre-set database connection parameters (such as IP address, port, username, password);

[0157] Execute the query and get the results: After submitting the SQL query, the system obtains the original data (such as the list of patient diagnosis records) from the database;

[0158] Result processing and feedback: If the query is successful, the system converts the results into a user-friendly format (such as tables or charts) and adds business explanations (such as "3 records found that meet the conditions"); if the query fails (such as the field does not exist or the permission is insufficient), the system records error logs and feedback prompts (such as "Please check if the 'diagnosis time' field exists").

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

[0160] 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.

[0161] In the embodiments of the present application, the medical database execution module includes the following steps:

[0162] Step 1, when the generated SQL query fails to execute in the medical database (such as the field does not exist, the permission is insufficient, the syntax error), the system automatically triggers the exception handling process:

[0163] Error classification identification: the system identifies the exception type according to the error code or information (such as "field does not exist", "permission is insufficient", "connection timeout"); user prompt generation: generate corresponding prompt information for different exception types (such as "Please check if the 'diagnosis time' field exists", "The current user has no permission to access 'patient table'"); administrator notification mechanism: if it is a system-level error (such as the database service is unavailable), the system automatically sends a notification to the medical database administrator's mailbox or intranet message, which facilitates quick response.

[0164] Through classification prompts and automatic notifications, users can accurately locate problems and quickly fix them, while ensuring the stability of the database service.

[0165] Step 2, the system filters the original results returned by the SQL query (such as patient name, ID number, diagnosis details) to ensure compliance with medical data security and privacy protection requirements:

[0166] Data desensitization rule application:

[0167] Anonymization: Direct identifiers such as patient names and ID numbers are desensitized (e.g., "Zhang San" → "XXX"); Fuzzification: Indirect identifiers such as addresses and phone numbers are fuzzified (e.g., "Beijing Chaoyang District XX Street 123" → "Beijing Chaoyang District XX Street XXXX").

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

[0169] 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).

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

[0171] Step 3, the system returns the filtered safe results to the interactive interface (such as web, mobile or desktop application) in a user-friendly form, completing the query loop:

[0172] 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); State feedback: Display query status (such as "query successful" "part of the data desensitized" "abnormal prompt") in the interface, making it easy for users to understand the source and integrity of the results.

[0173] Through intuitive display and interactive functions, improve user understanding and use efficiency of query results, and clearly mark data processing status to enhance user trust. Through the abnormal processing mechanism, quickly locate and repair SQL execution problems, combined with data desensitization strategy to strictly protect patient privacy, and efficiently deliver analysis results in a user-friendly manner, thus realizing comprehensive security, compliance and user experience in medical database operations, providing an end-to-end reliable closed-loop process for medical data analysis.

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

[0175] S100-S200: The system first identifies the user intent through natural language processing techniques (S100), extracting key information: "2023" (time range), "internal medicine" (department), "unresolved" (case status). Subsequently, S200 step utilizes the table structure and field descriptions of the medical database to match slots to candidate columns, such as "diagnosis table. diagnosis date" (time field), "diagnosis table. department name" (department field), "case table. case status" (status field), generating preliminary slot name-slot value pairs, such as "time: 2023, department: internal medicine, status: unresolved".

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

[0177] In S400, after the system executes the query, if it detects insufficient field permissions (such as "case table. case status" is not accessible), it will trigger an exception handling process, prompting the user to check the input or contact the administrator. At the same time, sensitive data filtering (such as desensitization processing) is performed on the returned patient ID, only displaying part of the information (such as PXXX001), and finally returning the results to the user interface in the form of a table and marking "part of the data is desensitized". 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, and embodies the innovation of the scheme in the intelligent and compliant query in the medical field.

[0178] The embodiments of the present application disclose an intelligent slot filling and mode linking system based on RAG and M-Schema, referring to Figure 2 , comprising:

[0179] 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 an RAG-FAQ fast matching module, to obtain 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 or the matching confidence is lower than the pre-set matching threshold, an NLU fine-grained analysis module is started, a fine-tuned sequence labeling model is used for intent classification and slot extraction on the user question, and a corresponding preliminary intent label, slot name-slot value pair and optional subdivision scene label are output.

[0180] The retrieval module 002 retrieves a context from the medical field knowledge base based on the preliminary intent label, slot name-slot value pair and subdivision scene label through an RAG-medical field knowledge base context enhancement module, performs entity linking and normalization on the preliminarily extracted slot value, and combines the entity linked and normalized slot value with M-Schema metadata of a target medical database for multi-dimensional verification, to output a finally matched medical database column and a confidence score, and the M-Schema metadata includes column name, column description, data type, example value and primary-foreign key relationship.

[0181] The medical slot information updating module 003 identifies a medical field specific uncertainty type based on the finally matched medical database column and confidence score, the uncertainty type includes medical term ambiguity, business rule conflict and missing key slot; a clarification question and a suggestion option for a medical user are dynamically generated based on the uncertainty type; user feedback on the clarification question and the suggestion option is received and used to update the medical slot information, to output a corrected corrected slot name-slot value pair and a corrected confidence score.

[0182] The SQL query generation module 004 is used for generating a SQL query conforming to a medical business rule based on the corrected slot name-slot value pair, the finally matched medical database column and the subdivision scene label; the generated SQL query is transmitted to a medical database execution module, and a corresponding analysis result is output.

[0183] The application embodiment further discloses an intelligent slot filling and mode linking system based on RAG and M-Schema, comprising a processor, and a program of the intelligent slot filling and mode linking method based on RAG and M-Schema in any one of the above embodiments is run in the processor.

[0184] The application embodiment further discloses a storage medium, and the program of the intelligent slot filling and mode linking method based on RAG and M-Schema in any one of the above embodiments is stored in the storage medium.

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

Claims

1. A method for intelligent slot filling and schema linking based on RAG and M-Schema, characterized in that, The method comprises the following steps: 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 rapid 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 subdivision scene label based on the medical intent and slot structure; if 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 subdivision scene label; based on the preliminary intent label, slot name-slot value pair and subdivision scene label, retrieving the context from the medical field knowledge base through a RAG-medical field knowledge base context enhancement module, performing entity linking and normalization on the preliminary extracted slot value, and combining the entity linked and normalized slot value with the M-Schema metadata of the target medical database for multi-dimensional verification, outputting the final matched medical database column and confidence score, and the M-Schema metadata including column name, column description, data type, example value and primary-foreign key relationship; based on the final matched medical database column and the confidence score, identifying the uncertainty types specific to the medical field, the uncertainty types including medical term ambiguity, business rule conflict and missing key slot; based on the uncertainty types, dynamically generating clarification questions and suggestion options for medical users; receiving user feedback on the clarification questions and suggestion options and updating medical slot information, and outputting the corrected slot name-slot value pair and corrected confidence score; based on the corrected slot name-slot value pair, final matched medical database column and subdivision scene label, generating a SQL query conforming to the medical business rules; and passing the generated SQL query to a medical database execution module to output the corresponding analysis result.

2. The RAG and M-Schema based intelligent slot filling and pattern linking method as claimed in claim 1, wherein, In the process of entity linking and normalization of the preliminary extracted slot value by the RAG-medical field knowledge base context enhancement module, the method further comprises the following steps: based on the preliminary extracted slot value and the entity alias mapping table in the medical field knowledge base, linking the slot value to the standard entity name in the medical field knowledge base through semantic similarity calculation, and outputting the normalized slot value and corresponding entity identifier after normalization; based on the normalized slot value and the medical business rules, performing compliance verification on the normalized slot value, adjusting the statistical scope or filtering sensitive fields, and outputting the final slot value and business rule verification state conforming to the compliance requirements of the medical database.

3. The RAG and M-Schema based intelligent slot filling and pattern linking method as claimed in claim 2, wherein, In the process of multi-dimensional verification, the method further comprises the following steps: based on the final slot value and the data type definition of the medical database column, checking the data type compatibility of the slot value and the medical database column, and automatically converting non-standard formats, outputting the candidate column and verification state after data type verification; Based on the checked candidate columns and the example values of the medical database columns, the matching degree of the slot value and the example value is compared by semantic similarity calculation, the candidate column list is sorted, and the sorted candidate column list is output; Based on the candidate column list and the primary-foreign key relationship of the medical database, the candidate column combination is optimized to ensure that the table connection logic meets the medical business requirements, and the final matched medical database column and confidence score are output.

4. The RAG and M-Schema based intelligent slot filling and pattern linking method as claimed in claim 3, wherein, The method further comprises: Based on the final matched medical database column and the confidence score, the ambiguity of the medical term of the slot value mapped to multiple candidate columns is identified, and a clarification question is generated to determine the corresponding candidate column direction; Based on the confidence score and the medical business rules, it is judged whether there is a missing key slot, and a supplementary suggestion option is generated to perfect the corresponding slot information; Based on the candidate column direction and the slot information integration, a clarification question and a suggestion option for medical users are generated, and the clarification interaction content to be confirmed by the user is output.

5. The RAG and M-Schema based intelligent slot filling and pattern linking method as claimed in claim 4, wherein, In the updating process of the 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 a standard format, and the slot value after data type correction and the marking state are output; Based on the user's explicit selection of the candidate column direction, the slot value is updated and the candidate column is preferentially matched, and the slot value after ambiguity candidate item correction and the candidate column identifier are output; Based on the slot value after data type correction and the candidate column identifier after ambiguity candidate item correction, the corrected slot name-slot value pair is integrated and generated, and the final slot information that meets the medical business rules is output.

6. The RAG and M-Schema based intelligent slot filling and pattern linking method as claimed in claim 5, wherein, In the process of generating a SQL query that meets the medical business rules, the method further comprises: Based on the corrected slot name-slot value pair and the sub-scene label, a specific business rule is applied, and a SQL template after business rule verification and a rule adaptation state are output; Based on the SQL template after business rule verification and the primary-foreign key relationship of the medical database, the table connection logic is optimized to ensure that the SQL query meets the medical business specifications, and the finally generated SQL query statement is output; The finally generated SQL query statement is passed to the medical database execution module, and the corresponding analysis result is output.

7. The RAG and M-Schema based intelligent slot filling and pattern linking method as claimed in claim 1, wherein, 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, an exception handling process is triggered, the user is prompted to check the input or contact the medical database administrator, and an exception handling prompt information is output; Based on the query result content, sensitive data is filtered to ensure that it meets the requirements of medical data security and privacy protection, and the final analysis result after security filtering is output; The final analysis result is returned to the user interaction interface, and the closed-loop interaction of the medical database query is completed.

8. A RAG and M-Schema based intelligent slot filling and schema linking system, characterized in that, It comprises: The 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 an 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 there is no matching or the matching confidence is lower than the pre-set matching threshold, an NLU fine-grained analysis module is started, a fine-tuned sequence labeling model is used for intent classification and slot extraction on the user question, and a corresponding preliminary intent label, slot name-slot value pair, and optional subdivision scene label are output. The retrieval module retrieves context from the medical field knowledge base based on the preliminary intent label, slot name-slot value pair, and subdivision scene label through an 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 identifies the uncertainty types specific to the medical field based on the finally matched medical database column and confidence score. The uncertainty types include medical term ambiguity, business rule conflict, and missing key slot. The medical user-oriented clarification questions and suggestion options are dynamically generated based on the uncertainty types. The 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 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.

9. A RAG and M-Schema based intelligent slot filling and schema linking system, characterized in that, A processor having a program of the RAG and M-Schema based intelligent slot filling and pattern linking method according to any one of claims 1-7 running therein.

10. A storage medium, characterized by A storage having a program of the RAG and M-Schema based intelligent slot filling and pattern linking method according to any one of claims 1-7.

Images