Training method and device of inquiry model, equipment and storage medium

Abstract

The invention belongs to the technical field of artificial intelligence, and discloses an inquiry model training method and device, equipment and a storage medium, and the method comprises the steps: obtaining inquiry dialogue data; inputting the inquiry dialogue data into the heavy-weight large language model, and outputting logical reasoning data for reply data of a diagnoser; performing quality screening on the logical reasoning data to obtain standard reasoning data meeting a preset quality standard; combining the inquiry dialogue data and the standard reasoning data corresponding to the inquiry dialogue data to form a training sample of a preset lightweight large language model; and taking the question data of the patient in the training sample as input data of the lightweight large language model, taking the reply data and the standard reasoning data of the diagnoser in the training sample as output data of the lightweight large language model, and training a preset lightweight large language model to obtain a trained inquiry model. The problems that an interrogator cannot accurately reply during inquiry and the inquiry speed is too low are solved.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of artificial intelligence, and is applied to the fields of financial technology and medical health, and particularly relates to a training method and device of a diagnosis model, equipment and a storage medium. BACKGROUND

[0002] With the development of technology, more and more business activities can be carried out online. For example, in the insurance industry, when submitting insurance data for medical insurance, it is usually necessary to submit one's own physical health proof materials, but the authenticity and timeliness of the physical health proof materials submitted by the user cannot be guaranteed. Therefore, the insurance industry can use a real-time diagnosis system to diagnose the user's real physical condition.

[0003] However, the current diagnosis system is in the form of dialogue, and the dialogue output by the diagnostician to the inquirer is usually only a result and professional vocabulary, which is difficult for the inquirer to understand, and further reply to the diagnostician's required answer. In addition, in order to ensure accuracy, the current diagnosis system usually uses large-scale dialogue data for model training to obtain a diagnosis model, which usually has too many parameters, resulting in slow diagnosis speed. SUMMARY

[0004] The present application provides a diagnosis model training method, device, equipment and storage medium, which can solve the problems of inaccurate reply and slow diagnosis speed of the inquirer in the prior art.

[0005] In a first aspect, the present application provides a diagnosis model training method, comprising: obtaining diagnosis dialogue data, wherein the diagnosis dialogue data comprises question data of a patient and reply data of a diagnostician; inputting the diagnosis dialogue data into a heavyweight large language model to output logical reasoning data corresponding to the reply data of the diagnostician, wherein the parameter quantity of the heavyweight large language model is above a first threshold value; performing quality screening on the logical reasoning data based on a preset quality standard to obtain standard reasoning data meeting the preset quality standard; combining the diagnosis dialogue data and the standard reasoning data corresponding to the diagnosis dialogue data to form a training sample of a preset lightweight large language model, wherein the parameter quantity of the lightweight large language model is below a second threshold value, and the second threshold value is less than the first threshold value; The question data of the patients in the training samples is taken as input data of the lightweight large language model, the reply data of the doctors in the training samples and the standard reasoning data are taken as output data of the lightweight large language model, the preset lightweight large language model is trained, and a training completed interrogation model is obtained.

[0006] In a second aspect, the present application provides a training device of an interrogation model, comprising: A model construction module is configured to acquire typhoon forecast data in a preset geographical region, and construct a typhoon probability field model covering the preset geographical region according to the typhoon forecast data, wherein the typhoon probability field model comprises disaster-causing factors of each spatial grid point in the preset geographical region and intensity probability distributions of each disaster-causing factor. An information acquisition module is configured to acquire target asset information of a target user and target location information of the target asset information. A matching module is configured to match a target spatial grid point corresponding to the target location information in the spatial grid points. An input module is configured to input the target spatial grid point into the typhoon probability field model to obtain a target disaster-causing factor corresponding to the target location information and an intensity probability distribution of the target disaster-causing factor. A loss output module is configured to input the intensity probability distribution of the target disaster-causing factor and the target asset information into a preset asset loss model to output a loss value of the target asset information. A risk assessment module is configured to assess the loss value based on a preset quantitative risk index, and output a typhoon risk assessment result for the target asset information.

[0007] In a third aspect, a computer device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the steps of the above interrogation model training method when executing the computer program.

[0008] In a fourth aspect, a computer readable storage medium is provided, and the computer readable storage medium stores a computer program, and the computer program implements the steps of the above interrogation model training method when executed by a processor.

[0009] The training method, device and equipment of the above-mentioned inquiry model and the storage medium realize the scheme, generate logical reasoning data for the diagnosis reply through the heavyweight large language model, combine the inquiry dialogue data to form the training sample of the lightweight large language model, and fine-tune the lightweight model in the way of freezing the original parameters and injecting the low-rank adapter matrix, without relying on the deployment of the heavyweight model of expensive hardware and avoiding the resource consumption of full fine-tuning. The process not only guarantees the medical logic of the training data by means of the strong reasoning ability of the heavyweight model, but also adapts to the resource-limited scene through the lightweight characteristics of the lightweight model. In the medical field, the model can be deployed in the primary health hospital and the mobile diagnosis terminal. In the financial field, the model can be integrated into the health insurance underwriting applet and the medical credit risk control port. The balance between high-quality reasoning and low-cost deployment is realized through model cooperation and efficient fine-tuning throughout the process, without manual disassembly of medical logic or manual annotation of training samples. It can be seen that the scheme migrates the capability of the heavyweight model to the lightweight model, and solves the core contradiction between high deployment cost and low diagnosis accuracy of the traditional inquiry model from the technical level, greatly reducing the landing threshold of medical AI and the computing power cost of financial health services.

[0010] In addition, the core reason for poor quality of training data in the related art is that the inquiry data screening standard is single-sided and the reasoning data lacks medical compliance verification. In the scheme, when obtaining the inquiry dialogue data, the sequence model is used to evaluate the completeness, the frequency of medical keywords is counted, and the emotion analysis model is used to output the positive change score. The comprehensive quality score is calculated according to the preset weight, so as to ensure the effective information density of the input data. Further, after generating the logical reasoning data, the end-to-end consistency verification model is used to verify the logical correlation between the reasoning data and the inquiry dialogue, and the multi-task classification model is combined with the standard database to filter the standard reasoning data conforming to the medical theory and intervention technology, so as to eliminate invalid and logically broken data and exclude reasoning content not conforming to the medical specification, avoiding the problem of model misdiagnosis caused by low-quality data from the data source. In the medical field, the diagnosis suggestion output by the model is more in line with the clinical guidelines, and in the financial field, the health risk based on the model data evaluation, such as chronic disease drug compliance and disease deterioration probability, is more accurate, ensuring the reliability of the business in both fields.

[0011] Further, the core of the medical logic reasoning missing in the inquiry model in the related art is that the medical basis behind the diagnosis answer is not mined, and only the surface text matching of the question and answer is learned by the model, while the scheme explicitly generates the logic reasoning data of the diagnosis answer through the heavyweight large language model, and combines the data with the inquiry dialogue data as training samples; the lightweight model takes the question data as input and the answer data and reasoning data as output during training, and the essence is to make the model not only learn the dialogue interaction form, but also understand the corresponding medical logic chain of the answer. This design makes the content output by the model no longer a mechanical imitation, but has an interpretable medical basis, which can assist primary doctors to quickly master the diagnosis idea in the medical field, and reduce the risk of missed diagnosis; in the financial field, the reasoning data output by the model can be used to formulate differentiated health insurance premium strategies, filling the technical gap of traditional models that only give results but not basis, and further improving the professionalism and credibility of the double-field business. BRIEF DESCRIPTION OF DRAWINGS

[0012] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the description of the embodiments of the present application. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can also be obtained by those skilled in the art without creative labor.

[0013] Figure 1 is a flowchart of the training method of the inquiry model in an embodiment of the present application.

[0014] Figure 2 is Figure 1 is a flowchart of step S110 in the embodiment.

[0015] Figure 3 is Figure 1 is a flowchart of step S120 in the embodiment.

[0016] Figure 4 is Figure 1 is another flowchart of step S120 in the embodiment.

[0017] Figure 5 is another flowchart of the training method of the inquiry model in an embodiment of the present application.

[0018] Figure 6 is Figure 1 is a flowchart of step S140 in the embodiment.

[0019] Figure 7 is Figure 1 is a flowchart of step S160 in the embodiment.

[0020] Figure 8This is a schematic diagram of a training device for a medical history model in one embodiment of the present invention.

[0021] Figure 9 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention.

[0022] Figure 10 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

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

[0024] Figure 1 A flowchart of the training method for the medical history model provided in the embodiments of the present invention is shown below. Figure 1 As shown, the training method for the medical history model provided in this embodiment of the invention includes the following steps.

[0025] Step S110: Obtain consultation dialogue data, wherein the consultation dialogue data includes the patient's question data and the diagnostician's response data.

[0026] It should be noted that the core of step S110 is to acquire consultation dialogue data with both medical clinical value and financial risk assessment value through a closed-loop mechanism of "multi-source data collection, multi-dimensional quality assessment, and precise screening," ensuring the "high quality and high compliance" of subsequent model training samples. This mechanism replaces the subjective judgment of traditional manual screening with techniques such as sequence modeling, keyword statistics, and sentiment analysis. It also adapts to the medical and health field's need for "completeness of medical information" and the fintech field's need for "clarity of risk-related information," providing a reliable data foundation for consultation models shared by both fields.

[0027] In some embodiments of the present invention, such as Figure 2 As shown, step S110 includes the following steps: Step S111: Obtain the consultation dialogue data to be filtered; Step S112: Input the consultation dialogue data to be screened into the sequence model, and use the sequence model to identify and evaluate the completeness of the consultation dialogue data to be screened. Step S113: Extract the consultation keywords from the consultation dialogue data to be filtered; Step S114: Calculate the frequency of occurrence of the consultation keywords in the preset medical keyword standard database; Step S115: Input the consultation dialogue data to be screened into a preset sentiment analysis model and output the positive emotion change score of the patient during the dialogue process. Step S116: Based on the preset weights of the completeness, the frequency of occurrence, and the positive change score of emotion, the preset weights of the completeness, the frequency of occurrence, and the positive change score of emotion are weighted to obtain the comprehensive quality score of each of the consultation dialogue data to be screened. Step S117: Select the consultation dialogue data to be screened that meets the preset score conditions as the final consultation dialogue data.

[0028] Specifically, in step S111, the consultation dialogue data to be screened needs to be obtained from compliant and authoritative multiple channels, covering data needs in both fields. The specific sources and characteristics are as follows: Offline medical institution channels: including outpatient clinics of tertiary hospitals, community health service centers, and specialist clinics, face-to-face consultation dialogues are collected through medical-specific encrypted recording equipment and transcribed into text by the ASR system. The data characteristics are "authentic diagnosis and treatment scenarios and authoritative medical information". In the medical field, complete "symptom-diagnosis-treatment" link data can be obtained from this (such as a dialogue of "diabetic patients adjusting medication during follow-up visits"). In the financial field, it can be used as "strong evidence data" for underwriting (such as a user claiming "no chronic diseases" when applying for insurance, but offline dialogues show a record of hypertension treatment). Online consultation platform channels: covering internet hospitals and medical and health apps, directly collecting online dialogues in text or audio-visual transcription. The data characteristics are "large volume, high frequency, and diverse scenarios". In the medical field, a massive amount of dialogue samples on common diseases (such as colds and gastroenteritis) can be obtained; in the financial field, data on the correlation between "health consultation + insurance needs" can be obtained (such as dialogues where "after consulting on the diagnosis and treatment of thyroid nodules, one simultaneously inquires about critical illness insurance"). Medical and financial cooperation channels include collaboration with health insurance companies and medical credit institutions to obtain anonymized data on the integration of "consultation + financial needs" (such as pre-insurance health check dialogues and medical condition description dialogues when applying for medical loans). The data is characterized by "high risk correlation." In the medical field, scenario data combining "treatment recommendations and financial decisions" can be obtained; in the financial field, health information strongly correlated with risk assessment can be directly obtained.

[0029] The acquired data needs to be temporarily stored in an encrypted intermediate library and labeled with source tags (such as "offline - cardiology" or "online - health insurance consultation") to provide a scenario basis for subsequent quality assessment.

[0030] Specifically, in step S112, the sequence model needs to use an architecture with long text semantic understanding capabilities (such as BiLSTM or Transformer-based models), and needs to be fine-tuned using medical and financial dual-domain corpora (such as integrating the texts of the "Clinical Practice Guidelines" and the "Health Insurance Underwriting Rules") to ensure accurate identification of the "information completeness of the consultation dialogue." The completeness assessment focuses on the core information dimensions of both domains: the medical domain completeness dimension includes whether the "symptom description (such as location, frequency, triggering factors), past medical history (such as disease, surgery, allergy history), and the diagnostician's response (such as information confirmation and treatment suggestions)" are complete. For example, the dialogue "Patient: Headache for the past 3 days; Diagnostician: Rest is recommended" lacks key information such as "headache location, whether accompanied by nausea," resulting in a "low" completeness assessment. However, the dialogue "Patient: Throbbing pain in the right temple for the past 3 days, aggravated when bending over, no nausea; Diagnostician: Consider tension headache, suggest avoiding prolonged sitting," is different. The "blood pressure monitoring" aspect is rated as "high" in terms of completeness. In the financial sector, the completeness dimension additionally assesses the completeness of "health risk information (such as type and control status of chronic diseases) and financial needs (such as insurance type and loan purpose)." For example, the dialogue "Patient: Has hypertension, wants to purchase insurance; Diagnostic: Can be insured" is rated as "low" due to the lack of "duration of hypertension history, blood pressure control level, and type of insurance." However, the dialogue "Patient: Has a 2-year history of hypertension, blood pressure controlled at 130 / 80 mmHg, wants to purchase comprehensive medical insurance; Diagnostic: Premium increase of 10%" is rated as "high" in terms of completeness. The model outputs a completeness score (0-10, with 10 being the most complete), which serves as one of the core dimensions for the subsequent comprehensive quality score.

[0031] Specifically, in step S113, the extraction of consultation keywords needs to be achieved through a "dual-domain adapted named entity recognition (NER) model." The model needs to predefine keyword categories in the medical and financial fields to ensure the accuracy of extraction: medical keyword categories include symptom categories (such as "sore throat, chest tightness"), disease categories (such as "hypertension, diabetes"), medication categories (such as "metformin, ibuprofen"), and treatment behavior categories (such as "electrocardiogram, biopsy"). For example, from the dialogue "Patient: Postprandial blood glucose is 10.5 mmol / L in the past week; Diagnostician: It is recommended to add metformin..." In the context of "metformin," the extracted keywords are "postprandial blood glucose 10.5 mmol / L, metformin." In the financial sector, keyword categories are expanded beyond medical keywords to include risk-related categories (e.g., "duration of medical history, control status"), financial needs categories (e.g., "million-dollar medical insurance, critical illness insurance"), and underwriting conclusion categories (e.g., "premium increase, standard underwriting"). For example, from the dialogue "Patient: thyroid nodules, TI-RADS2 class, wants to purchase critical illness insurance; Diagnostic: standard underwriting available," the extracted keywords are "thyroid nodules, TI-RADS2 class, critical illness insurance, standard underwriting." After extraction, the keywords need to be standardized (e.g., "diarrhea" is standardized to "diarrhea," "hyperthyroidism" to "hyperthyroidism") to ensure matching with the subsequent standard database.

[0032] Specifically, in step S114, the preset medical keyword standard database needs to construct a dual structure of "medical core sub-database and financial related sub-database", and needs to be updated regularly (the medical sub-database is synchronized with the "ICD-10 Disease Code" and "National Essential Medicines List" annually, and the financial sub-database is updated with the "Health Insurance Underwriting Keyword Manual" quarterly): the medical core sub-database stores keywords necessary for clinical diagnosis and treatment and frequency benchmarks (such as in the consultation of "acute myocardial infarction", the frequency of keywords such as "chest pain, profuse sweating, ST segment elevation on electrocardiogram" should be ≥1 time); the financial related sub-database stores keywords that are strongly related to health risks and frequency benchmarks (such as in the dialogue of "hypertension insurance", the frequency of keywords such as "duration of medical history, blood pressure value, medication status" should be ≥2 times). When calculating keyword frequency, it's necessary to calculate "the frequency of keyword matching in the standard database / the total number of standard keywords in this scenario." For example, in the medical scenario "acute cough" dialogue, the extracted keywords "cough, no sputum, fever 38.5℃" all match the sub-database, with a frequency of 3 times, and the total number of standard keywords is 3 times, resulting in a frequency of 100%. In the financial scenario "diabetes insurance" dialogue, the extracted keywords "diabetes, 2-year medical history, no medication" match the sub-database, with a frequency of 3 times, and the total number of standard keywords is 4 times (missing "blood glucose control value"), resulting in a frequency of 75%. The higher the frequency, the more abundant the dual-domain key information contained in the data.

[0033] Specifically, in step S115, the preset sentiment analysis model needs to adopt a BERT-based fine-grained sentiment classification architecture and needs to be fine-tuned through "consultation scenario sentiment corpus" (such as labeling sentiment change tags such as "anxiety-relief" and "doubt-clarity"), and output a positive sentiment change score (0-10 points, 0 points for no positive change and 10 points for significant improvement in sentiment). The dual-domain emotional change assessment focuses on different core aspects: In the medical domain, the focus is on the change in the patient's emotions from "anxiety / doubt" to "understanding / reassurance." For example, at the beginning of the conversation, the patient is "worried that the headache is a stroke" (anxiety). After the diagnostic explains that "it is a tension headache, with no serious risk," the patient feels "reassured and will rest as advised" (reassurance), and the score for positive emotional change is 8 points. If the patient is still "worried about missing a diagnosis" after the conversation, the score is 2 points. In the financial domain, the focus is additionally on the patient's emotional changes regarding "financial decisions." For example, at the beginning, the patient is "worried that nodules will affect insurance" (concern). After the diagnostic explains that "TI-RADS Class 2 is insurable at standard risk," the patient is "satisfied and wants to apply for insurance immediately" (positive), and the score is 9 points. If the patient is dissatisfied with "increased premiums," the score is 3 points.

[0034] A higher score for positive emotional changes indicates a stronger "effectiveness" of the consultation dialogue (effective diagnosis and treatment in the medical field, and fulfillment of needs in the financial field), and better data quality.

[0035] Specifically, in step S116, the calculation of the comprehensive quality score requires setting differentiated preset weights based on the needs of both domains. The total weights are 100%, and the score is calculated using the "weighted summation" formula: Comprehensive Quality Score = Completeness × Weight 1 + Keyword Frequency × Weight 2 + Positive Emotional Change Score × Weight 3. Weight settings for the medical domain: Because "completeness of medical information" directly affects the accuracy of the model's diagnosis, the completeness weight 1 is set to 50%, the keyword frequency (reflecting the density of medical information) weight 2 is set to 30%, and the emotional score (reflecting the effectiveness of the consultation) weight 3 is set to 20%. For example, if a medical dialogue has a completeness score of 8, a keyword frequency of 90% (equivalent to 9 points), and an emotional score of 7, the comprehensive quality score = 8 × 50% + 9 × 30% + 7 × 20% = 4 + 2.7 + 1.4 = 8.1 points. Weight settings for the financial domain: Because "risk-related keywords" directly support underwriting decisions, the keyword frequency weight 2 is set to 40%, the completeness (reflecting the completeness of health and financial needs) weight 1 is set to 35%, and the emotional score (reflecting data credibility) weight 3 is set to 25%. For example, a financial dialogue might have a completeness score of 7, a keyword frequency of 80% (8 points), and an emotion score of 9. The overall quality score would be 7 × 35% + 8 × 40% + 9 × 25% = 2.45 + 3.2 + 2.25 = 7.9 points. The weighting settings need to be calibrated through dual-domain expert review (e.g., inviting clinicians and underwriting experts to jointly adjust) to ensure they meet actual business needs.

[0036] Specifically, in step S117, the preset score conditions need to be set with differentiated thresholds according to the dual-domain business scenarios. Only the data to be screened with a comprehensive quality score ≥ the threshold can be used as the final consultation dialogue data: In the medical domain, the threshold is set to 7 points (out of 10) to support the model's rigorous diagnostic logic. High-scoring data (e.g., 8.1 points) can be used as core training samples for lightweight models (e.g., training for common disease diagnosis in primary healthcare AI); data below 7 points (e.g., 5.2 points) need to be removed or re-evaluated due to incomplete information. In the financial domain, the threshold is set to 6.5 points to ensure the reliability of underwriting decisions. High-scoring data (e.g., 7.9 points) can be used for the model's "health insurance underwriting reasoning" training; data below 6.5 points (e.g., 5.8 points) need to be excluded from financial scenario training due to ambiguous risk information. After screening, the final data needs to be labeled with "domain label - quality level" (e.g., "medical - high level" "financial - high level") for easy subsequent scenario-based access.

[0037] Understandably, step S110 addresses the core pain points of traditional consultation data screening through "multi-dimensional quantitative assessment + dual-domain weight adaptation": traditional methods rely on manual sentence-by-sentence review, which is not only inefficient (reviewing a single data entry takes 3-5 minutes) but also prone to inconsistent standards due to subjective judgment (such as different reviewers having different definitions of "information completeness"); at the same time, traditional screening does not differentiate between medical and financial needs, resulting in data that cannot be simultaneously adapted to dual-domain model training (e.g., medical data lacks financial keywords, and financial data lacks medical details). This solution achieves "automated quantitative assessment" through technologies such as sequence models, NER, and sentiment analysis, improving efficiency by more than 100 times (processing 50+ data entries per second) and ensuring uniform standards; through differentiated weights and thresholds, the screened data meets both the "completeness of medical information" requirement in the medical field and the "clear risk information" requirement in the financial field, achieving "one set of data for dual-domain reuse".

[0038] Furthermore, compared to schemes that rely solely on single indicators such as "dialogue length" or "fluency" for screening, this scheme employs a more comprehensive three-dimensional evaluation of "completeness, keywords, and sentiment." For example, a dialogue that is long but lacks core symptoms (in the medical field) or risk keywords (in the financial field) will still be filtered out; while short dialogues that are complete in information, have clear keywords, and exhibit positive sentiment can still be retained. This technically ensures the "accuracy" of data quality, laying a high-quality foundation for subsequent model training.

[0039] Step S120: Input the consultation dialogue data into a heavyweight large language model and output logical reasoning data for the diagnosis data of the patient, wherein the number of parameters of the heavyweight large language model is above a first threshold.

[0040] It should be noted that the logical reasoning data generation mechanism in step S120 is based on a precise guidance technology using "structured parameters, templates, and prompts." Its core lies in anchoring the reasoning direction through preset medical reasoning parameters and leveraging the strong medical logical reasoning capabilities of heavyweight large-scale language models (such as GPT-4 with ≥100 billion parameters or LLaMA270B) to uncover the professional basis behind the diagnostician's response. This mechanism aligns closely with the interpretability requirements of intelligent consultation in the healthcare field and the logical requirements of health risk assessment in the fintech field. In the medical field, reasoning data can supplement the medical basis of diagnostic recommendations, improving the credibility of model diagnosis; in the financial field, it can be transformed into risk logic support for health insurance underwriting, avoiding the one-sidedness of making decisions solely based on the response results.

[0041] In some embodiments of the present invention, such as Figure 3 As shown, step S120 includes the following steps: Step S1211: Generate structured fields corresponding to the preset medical inference parameters; Step S1212: Use the structured fields corresponding to the medical inference parameters as structured fields of the inference data instruction template to construct the inference data instruction template; Step S1213: Analyze the consultation dialogue data to obtain the medical inference parameter values ​​in the consultation dialogue data that correspond to the medical inference parameters; Step S1214: Fill the structured fields of the inference data instruction template with the medical inference parameter values ​​to obtain the updated inference data instruction template; Step S1215: Convert the updated inference data instruction template into structured prompt words; Step S1216: Input the structured prompt words into a heavyweight large language model and output logical reasoning data for the respondent's response data.

[0042] Specifically, in step S1211, the preset medical reasoning parameters need to cover the core dimensions of the entire "diagnosis, treatment, and risk" chain, such as symptom association basis, disease diagnosis logic, reasons for medication selection, dosage calculation basis, and causal relationship of risk warnings; the corresponding structured fields need to adopt the "key-value pair reserved space" format to ensure that the parameter values ​​can be accurately filled. In the healthcare field, structured fields such as "{symptom association basis}" and "{medication contraindication exclusion logic}" can be set; in the fintech field, additional risk reasoning fields such as "{the impact logic of medical history on insurance risk}" and "{the basis for medical expenditure estimation corresponding to treatment recommendations}" can be associated. For example, for the hypertension consultation scenario, the medical reasoning parameters may include "the association between blood pressure value and medication dosage", with the corresponding structured field being "{blood pressure value, medication dosage association basis}"; the financial association parameters may include "the association between hypertension control status and premium coefficient", with the corresponding structured field being "{blood pressure control level, premium increase logic}".

[0043] Specifically, in step S1212, the construction of the reasoning data instruction template needs to combine the design of guiding logic with the requirements of both domains. The main body of the template is a combination of natural language instructions and structured fields to ensure that the heavyweight large language model clearly defines the reasoning task and output format. The medical domain template focuses on the integrity of clinical logic. For example, "Based on the consultation dialogue data, analyze the logical reasoning process of the diagnostician's reply 'It is recommended to take XX antihypertensive drug 5mg / day'. The following structured fields need to be filled in: {symptom association basis} (explaining the association between the patient's symptoms and hypertension), {drug contraindication exclusion logic} (explaining why other antihypertensive drugs are excluded), {dosage calculation basis} (explaining the calculation basis of 5mg / day)"; the financial domain template needs to be superimposed with risk reasoning guidance. For example, "Based on the consultation dialogue data, analyze the logical reasoning process of the diagnostician's reply 'With stable blood pressure control, critical illness insurance can be purchased'. In addition to the medical structured fields, the following need to be added: {blood pressure control level - premium increase logic} (explaining the basis for the premium increase ratio corresponding to stable control), {medical history duration - underwriting approval rate association} (explaining the relationship between 3 years of medical history and underwriting approval rate)". Templates need to pre-set output format requirements (such as point-by-point explanations and logical loops) to avoid messy output content in large models.

[0044] Specifically, in step S1213, the analysis of consultation dialogue data to obtain parameter values ​​requires the use of medical-grade NLP technology (such as named entity recognition and relation extraction models) to extract key information from the patient's questions and the diagnostician's answers. In the medical field, for example, from the dialogue "The patient's average blood pressure over the past 3 months is 145 / 95 mmHg, with no history of kidney damage," the "symptom association basis" parameter value is extracted as "The patient's average blood pressure over the past 3 months is 145 / 95 mmHg, meeting the diagnostic criteria for essential hypertension (systolic blood pressure ≥140 mmHg or diastolic blood pressure ≥90 mmHg)," and the "medication contraindication exclusion logic" parameter value is extracted as "The patient has no history of kidney damage, excluding nephrotoxic antihypertensive drugs that should be avoided." In the financial field, from the dialogue "The patient has a 3-year history of hypertension, and their blood pressure has been controlled at 130 / 80 mmHg for the past 6 months," the "blood pressure control level and premium increase logic" parameter value is extracted as "Blood pressure controlled at 130 / 80 mmHg for the past 6 months (target value <140 / 90 mmHg), belonging to the 'stable control' level, corresponding to a premium increase of 10%-15%." During the extraction process, it is necessary to consult authoritative databases such as ICD-10 disease codes and the National Pharmacopoeia to ensure the medical accuracy of the parameter values.

[0045] Specifically, in step S1214, filling in the structured fields requires string matching and replacement. The parameter values ​​extracted in step S123 are accurately filled into the corresponding fields of the inference data instruction template to form the updated template. For example, the updated template in the medical field is as follows: "Based on the consultation dialogue data, analyze the logical reasoning process of the diagnostician's reply 'It is recommended to take XX antihypertensive drug 5mg / day'. The following structured fields need to be filled: {Symptom association basis: The patient's average blood pressure in the past 3 months is 145 / 95mmHg, which meets the diagnostic criteria for primary hypertension (systolic blood pressure ≥140mmHg or diastolic blood pressure ≥90mmHg)}, {Drug contraindication exclusion logic: The patient has no history of kidney damage, excluding nephrotoxic antihypertensive drugs that should be avoided}, {Dosage calculation basis: The patient's weight is 60kg, calculated according to the conventional dose of XX antihypertensive drug 0.08mg / kg, recommended 5mg / day}"; the updated template in the financial field needs to supplement risk parameter values ​​to ensure that the template content covers both medical logic and financial risk association. After filling in the fields, the completeness of the fields needs to be verified. If there are any parameter values ​​that have not been extracted, they should be marked as "to be supplemented" and a second information extraction should be triggered to avoid empty template fields.

[0046] Specifically, in step S1215, converting the structured prompts requires optimizing the updated template into an instruction format that conforms to the input habits of heavyweight large language models, typically using a three-part structure of "task description, input data, and output requirements." For example, a structured prompt in the medical field might be: "Task: Analyze the medical logical reasoning process of the diagnostician's response. Input consultation dialogue data: 'Patient: High blood pressure for the past 3 months, average 145 / 95 mmHg, no history of kidney damage; Diagnostician: Recommended to take XX antihypertensive drug 5mg / day.' Please output reasoning data based on the following filled-in template: Based on the consultation dialogue data, analyze the logical reasoning process of the diagnostician's response 'Recommendation to take XX antihypertensive drug 5mg / day,' symptom association basis: The patient's average blood pressure for the past 3 months is 145 / 95 mmHg, conforming to..." The patient meets the diagnostic criteria for essential hypertension (systolic blood pressure ≥140 mmHg or diastolic blood pressure ≥90 mmHg); Medication contraindication exclusion logic: The patient has no history of kidney damage, excluding nephrotoxic antihypertensive drugs that should be avoided; Dosage calculation basis: The patient weighs 60 kg, calculated based on the conventional dose of XX antihypertensive drug 0.08 mg / kg, with a recommended dose of 5 mg / day. Output requirements: Clear bullet points, logical coherence, and accurate medical terminology. "Financial domain prompts need to add risk reasoning output requirements, such as 'Additional output: The logic and basis for the impact of blood pressure control level on premiums.'"

[0047] Specifically, in step S1216, the selection of a heavyweight large language model must meet the requirements of medical professionalism and reasoning ability. A large-parameter model fine-tuned with medical data (such as GPT-4Medical or Med-PaLM2) can be used. The first threshold for the number of parameters is usually set to ≥100 billion to ensure the model can understand complex medical logic. After inputting structured prompts, the logical reasoning data output by the model must present a "field-content" correspondence. For example, in the medical field, the output might be: "Symptom association basis: The patient's average blood pressure over the past 3 months is 145 / 95 mmHg, meeting the diagnostic criteria for primary hypertension in the 'Chinese Guidelines for the Prevention and Treatment of Hypertension' (systolic blood pressure ≥140 mmHg or diastolic blood pressure ≥90 mmHg), therefore the diagnostician determines that drug intervention is necessary; Medication contraindication exclusion logic: The patient has no history of kidney damage, and XX antihypertensive drug has no significant nephrotoxicity, making it suitable for this patient; Dosage calculation basis: According to XX antihypertensive drug..." The medication instructions state the standard dose is 0.08 mg / kg. For a patient weighing 60 kg, the calculated recommended dose is 4.8 mg / day, rounded down to 5 mg / day for clinical use. The financial sector output needs to be combined with: "Blood pressure control level and premium increase logic: The patient's blood pressure has been controlled at 130 / 80 mmHg for the past 6 months, which falls under the 'stable control' category. Referring to the 'Health Insurance Underwriting Guidelines,' those with stable hypertension control receive a 10%-15% premium increase; 5. Correlation between duration of medical history and underwriting approval rate: A medical history of 3 years without complications results in an underwriting approval rate of approximately 80%." After outputting the data, the reasoning should be temporarily stored to prepare for subsequent quality screening.

[0048] Understandably, through a layered guidance mechanism of "structured parameters, templates, and prompts," step S120 significantly improves the relevance and accuracy of logical reasoning data compared to the traditional method of "directly inputting dialogue to generate reasoning." In the healthcare field, this mechanism ensures that the reasoning data closely aligns with the core medical logic of the diagnostician's response, injecting "interpretability" into lightweight consultation models. When primary care physicians use the model, they can not only obtain treatment suggestions but also view the underlying reasoning (such as the medication dosage calculation process), reducing the risk of missed or misdiagnosed diagnoses. Simultaneously, the reasoning data conforms to clinical guidelines and can serve as compliance support for medical AI models. In the fintech field, reasoning data transforms medical information into financial risk logic (such as the correlation between medical history and premiums), solving the problem of "disconnect between medical information and risk assessment" in traditional underwriting. Health insurance companies can verify the rationality of underwriting decisions based on reasoning data, avoiding pricing deviations caused by "only looking at the disease name without considering control conditions." Unlike the generalized inference content output by traditional large models, the structured inference data generated in this step can directly adapt to the interface requirements of dual-domain business systems (such as medical diagnosis terminals and financial underwriting platforms), achieving a seamless connection between "inference data and business applications." After generating the logical inference data, high-quality training materials with "medical logic and risk logic" in two dimensions are provided for subsequent quality screening and lightweight model training, further ensuring the dual performance of the final consultation model in terms of medical professionalism and financial adaptability.

[0049] In some embodiments of the present invention, such as Figure 4 As shown, step S120 includes the following steps: Step S1221: Input the consultation dialogue data into a heavyweight large language model with a number of parameters above the first threshold, wherein the deployment and execution of the heavyweight large language model depends on distributing its parameters to the storage units of multiple parallel computing units; Step S1222: Run the heavyweight large language model, perform forward computation through the multi-layer transformer structure inside the heavyweight large language model, and generate and output the logical reasoning data that conforms to the predefined format.

[0050] It should be noted that steps S1221 to S1222 constitute the core execution chain for processing consultation dialogue data using a heavyweight large language model. The core lies in overcoming the limitations of model parameter scale through distributed deployment, relying on the powerful semantic understanding and logical reasoning capabilities of a multi-layered transformer structure to generate structured logical reasoning data that meets the needs of both domains. This process highly aligns with the deep needs of the healthcare field for reasoning about complex cases and the precise analysis needs of the fintech field for the logical correlation of health risks. In the healthcare field, it can support the generation of reasoning bases for complex scenarios such as rare diseases and multiple complications; in the financial field, it can accurately uncover the deep correlation between health information and underwriting rules, providing traceable logical support for risk pricing.

[0051] Specifically, in step S1221, the parameter size of the heavyweight large language model needs to meet the first threshold requirement. Its parameter volume far exceeds the storage limit of a single node computing unit (such as the memory of a single GPU, which is usually 80GB-1TB and cannot accommodate hundreds of billions of parameters). Therefore, a distributed loading strategy needs to be adopted: the model parameters are split by layer or by attention and distributed to the storage units (such as GPU memory, distributed memory) of multiple parallel computing units (such as multi-GPU clusters, distributed TPU nodes). The collaborative call between parameter slices is realized through communication protocols (such as NCCL, MPI).

[0052] In the healthcare field, this distributed deployment adapts to the computational needs of complex consultation scenarios. For example, when processing multi-disease consultation dialogues involving "diabetes mellitus combined with coronary heart disease and renal insufficiency," the model needs to simultaneously call medical knowledge from multiple fields such as endocrinology, cardiovascular, and nephrology. Hundreds of billions of parameters can cover more comprehensive clinical guidelines and case data. Distributed loading ensures that the model can access the complete parameter library in real time, avoiding inference bias caused by parameter truncation. In the fintech field, for multi-source consultation dialogues involving "chronic disease history, multiple insurance records, and medical expense reimbursement data," distributed deployment supports the model to simultaneously associate multi-dimensional knowledge such as health insurance underwriting rules and medical expense actuarial models, ensuring the integrity of risk inference logic (e.g., the inference of "5-year history of diabetes, 2 hospitalizations per year - premium increase of 25%" requires calling multi-dimensional correlation parameters of medical history duration, hospitalization frequency, and premium coefficient).

[0053] When inputting consultation dialogue data, it must first undergo standardized preprocessing, such as removing sensitive information and converting it into a model-compatible token format. The data is then distributed to each computing unit through a data parallel mechanism to ensure that each unit synchronously obtains complete input information, providing a consistent contextual basis for subsequent forward computation.

[0054] Specifically, in step S1222, the core of running the heavyweight large language model is to perform forward computation through a multi-layer transformer structure: the encoder layer of the transformer captures the long-distance dependencies of "symptoms, medical history, and diagnostic suggestions" in the consultation dialogue data through a self-attention mechanism (such as the association between "heart attack surgery 3 years ago" and "current anticoagulant medication"). The decoder layer generates logical reasoning data based on the contextual semantic representation output by the encoder, combined with predefined reasoning formats (such as "diagnostic basis, medication logic, and risk warning" in the medical field, and "health information, underwriting rules, and pricing basis" in the financial field).

[0055] In the healthcare field, the computational process of multi-layer transformers can deeply analyze the diagnostic and treatment logic chain. For example, in the dialogue "The patient has fever and chest pain, and the diagnostician recommends an electrocardiogram (ECG)," the model captures the symptom combination of "fever and chest pain" through the bottom-layer transformer, associates it with the medical knowledge that "chest pain may indicate myocardial ischemia," and the top-layer transformer outputs inference data: "Symptom association: Chest pain is a typical manifestation of myocardial ischemia, and myocardial infarction needs to be ruled out; Examination basis: An ECG can quickly identify ST segment changes and is the preferred examination for differential diagnosis of chest pain; Risk exclusion: The patient has no history of trauma, and chest wall diseases are not considered as a priority." Moreover, the inference data must be associated with the specific clause number of the "Guidelines for the Diagnosis and Treatment of Chest Pain" to ensure traceability.

[0056] In the fintech field, transformer architectures can accurately link health information with financial rules. For example, in a dialogue stating "A patient has a 3-year history of hypertension, with blood pressure controlled at 135 / 85 mmHg, and the diagnostic person claims they are eligible for medical insurance," the model uses a self-attention mechanism to focus on key information such as "duration of medical history" and "blood pressure control level." Combined with parameters from the "Health Insurance Underwriting Manual" loaded in the decoder, it generates inference data: "Health information extraction: 3-year history of hypertension (<5 years), blood pressure 135 / 85 mmHg (mildly elevated); Underwriting rule matching: Meets the 'mild hypertension and stable control' clause (clause number A-03); Pricing basis: This clause corresponds to a 10% premium increase, therefore this option is recommended." The generated logical inference data must strictly adhere to a predefined format (such as punctuation and field alignment) to ensure direct parsing and reuse in subsequent steps—in the medical field, it must include the "source of medical evidence" (such as guideline name and clause number), and in the financial field, it must indicate the "source of underwriting rules" (such as manual chapter and actuarial model version).

[0057] Understandably, the mechanism of "breaking through parameter limitations through distributed deployment and parsing deep logic through multi-layer transformers" significantly improves the depth and accuracy of logical reasoning data compared to traditional small-parameter models. In the healthcare field, this mechanism supports the model's reasoning needs for handling complex cross-disciplinary cases, solving the problems of "incomplete knowledge coverage and broken logic chains" in traditional models. AI-assisted systems in primary healthcare institutions can rely on this kind of reasoning data to provide doctors with "evidence-based and traceable" diagnostic and treatment suggestions, reducing the risk of misdiagnosis due to knowledge gaps; at the same time, distributed deployment ensures that the model can be updated in real time with the latest clinical guidelines (such as the annually updated "Guidelines for the Prevention and Treatment of Hypertension"), maintaining the timeliness of the reasoning data.

[0058] In the fintech field, this mechanism achieves a precise correlation between health information and underwriting rules, avoiding the one-sidedness of traditional underwriting models that "price based solely on disease names." Health insurance companies can explain the premium structure to customers by reasoning through the chain of "health information, matching, and pricing basis" in the data (e.g., "Because your blood pressure is well controlled, the premium will only increase by 10%, not 20%)," thereby increasing customer trust. Distributed deployment supports the model to simultaneously load underwriting rules for various product lines (such as medical insurance, critical illness insurance, and accident insurance), meeting the reasoning needs of multiple scenarios.

[0059] In some embodiments of the present invention, such as Figure 5 As shown, the following steps are included after step S120: Step S131: Concatenate the consultation dialogue data and the standard inference data to form a complete input sequence; Step S132: Input the complete input sequence into the pre-trained language model and output the comprehensive semantic representation encoded from the complete input sequence; Step S133: Input the comprehensive semantic representation into the end-to-end consistency verification model trained with positive and negative examples, and output the classification result of whether the question-and-answer dialogue data and the standard inference data are logically consistent. The positive examples are the data pairs corresponding to the question-and-answer dialogue data and the standard inference data that are logically consistent, and the negative examples are the data pairs corresponding to the question-and-answer dialogue data and the standard inference data that are not logically consistent. Step S134: If the classification result shows that the logical inference data between the consultation dialogue data and the standard inference data is inconsistent, then the logical inference data is regenerated.

[0060] It should be noted that steps S131 to S134 constitute a closed-loop mechanism of "logical consistency verification and anomaly correction." The core of this mechanism lies in ensuring the logical coherence and rationality of the consultation dialogue data and standard inference data through semantic encoding of the pre-trained language model and classification judgment of the end-to-end verification model. This mechanism aligns closely with the rigorous requirements of diagnostic logic in the healthcare field and the reliability requirements of risk assessment in the fintech field. In the medical field, it avoids the risk of misdiagnosis caused by contradictions between inference data and patient symptoms and medical history; in the financial field, it prevents underwriting decision biases caused by a disconnect between risk inference and health information, providing high-quality samples with "logical consistency" for subsequent model training.

[0061] Specifically, in step S131, the concatenation of the consultation dialogue data and standard inference data must adopt a "scenario-based separator, fixed order" approach to ensure that the complete input sequence retains the original semantics while clearly defining the relationship between the two. The concatenation order is uniformly set as "consultation dialogue data, special separator (such as '[reasoning basis]'), standard inference data," and the separator must be recognized as a semantic boundary marker by the pre-trained language model. In the healthcare field, for example, the concatenation result might be: "Patient: Fever for the past 3 days, body temperature 38.5℃, accompanied by cough; Diagnostic: Ibuprofen is recommended for fever reduction. [Reasoning Basis] Standard Inference Data: The patient's body temperature of 38.5℃ exceeds the fever reduction threshold of 38.3℃. Ibuprofen is a non-steroidal anti-inflammatory drug that can inhibit prostaglandin synthesis to achieve a fever reduction effect. Furthermore, the patient has no history of gastric ulcer disease and no contraindications to medication." In the fintech field, the concatenation result must include health insurance-related information, for example: "Patient: The patient has a 2-year history of diabetes, with blood sugar controlled at 7.0 mmol / L, and wishes to apply for medical insurance. Diagnosed: Insurable, premium increased by 12%. [Reasoning Basis] Standard reasoning data: The patient has a 2-year history of diabetes, with blood sugar controlled at 7.0 mmol / L (target value < 7.0 mmol / L), which falls under the 'well controlled' category. Referring to the "Health Insurance Underwriting Rules," this category corresponds to a premium increase of 10%-15%, therefore 12% is recommended. "After concatenation, data integrity needs to be verified to ensure no missing fields."

[0062] Specifically, in step S132, the selection of the pre-trained language model needs to be adapted to the semantic characteristics of both domains. In the medical domain, models fine-tuned with medical corpora (such as BioBERT and MedBERT) are preferred, while in the financial domain, financial semantic enhancement models (such as FinBERT and SecBERT) are used to ensure accurate understanding of professional terms (such as "glycated hemoglobin" and "underwriting exclusions"). During the encoding process, the complete input sequence is converted into a token sequence and input into the model. The hidden state at the last layer of the model is extracted as a comprehensive semantic representation. This vector integrates the overall semantics of the consultation dialogue and the inference data, quantifying the strength of their association. For example, in a medical scenario, if the consultation dialogue mentions "penicillin allergy," while the inference data includes "recommend amoxicillin (penicillin-type)," the comprehensive semantic representation will show low association characteristics. In a financial scenario, if the consultation dialogue shows "hypertension is not controlled," while the inference data states "premium has not increased," the vector will reflect semantic conflict. The encoded vector needs to be stored in floating-point array format, with dimensions consistent with the output of the pre-trained model.

[0063] Specifically, in step S133, the end-to-end consistency verification model is a binary classification model (such as a Transformer-based text classifier), and its training samples need to cover typical scenarios in both domains. Positive examples are logically consistent data pairs: in the medical field, such as "consultation dialogue contains 'renal insufficiency', inferred data 'avoid using nephrotoxic drugs'", and in the financial field, such as "consultation dialogue contains 'thyroid nodules TI-RADS2', inferred data 'underwriting can cover the standard risk'"; negative examples are logically contradictory data pairs: in the medical field, such as "consultation dialogue contains 'history of gastric ulcer' + inferred data 'recommend ibuprofen (may worsen ulcer)'", and in the financial field, such as "consultation dialogue contains 'no recurrence 5 years after lung cancer surgery' + inferred data 'reject insurance'". The model training uses the cross-entropy loss function, and the optimization objective is to minimize the deviation between "predictive consistency" and "true consistency". In the inference stage, after inputting the comprehensive semantic representation into the model, the classification result is output (e.g., "consistent" is 1, "inconsistent" is 0). In the medical field, this model can identify conflicts between inference data and symptoms and medical history; in the financial field, it can detect contradictions between risk inference and health status.

[0064] Specifically, in step S134, the trigger condition for regenerating the logical reasoning data is that the classification result is "inconsistent" (i.e., output 0). The regeneration process needs to reuse the mechanism of steps S121 to S126, but a "contradiction correction prompt" needs to be added. For example, in the medical field, if the verification finds a contradiction between "the reasoning data recommends nephrotoxic drugs" and "the consultation dialogue contains renal insufficiency," the structured prompt during regeneration needs to be added: "Note: The patient has a history of renal insufficiency, and the reasoning data needs to exclude the basis for recommending nephrotoxic drugs." In the financial field, if the verification finds a contradiction between "the reasoning data states that there is no premium increase" and "the consultation dialogue contains uncontrolled hypertension," the prompt needs to be added: "The patient's hypertension is uncontrolled (systolic blood pressure 150 mmHg). Referring to the underwriting rules, the reasoning data needs to correct the premium increase logic." After regeneration, steps S131 to S133 need to be executed again for verification until the classification result is "consistent," ensuring that the final reasoning data and the consultation dialogue form a logical closed loop.

[0065] Understandably, by employing a comprehensive "assembly, encoding, verification, and correction" mechanism, steps S131 to S134 achieve automated and high-precision logical contradiction detection compared to the traditional "manual verification of logical consistency," significantly improving data quality. In the healthcare field, this mechanism ensures that standard inference data strictly adheres to the clinical logical chain of "symptom-diagnosis-treatment," injecting "evidence-based medicine" into lightweight diagnostic models. When primary care physicians use the model, they can trust the underlying reasoning behind its output treatment recommendations, reducing medical accidents caused by logical errors. Simultaneously, the consistency verification results can serve as a basis for compliance review of medical AI models, meeting the accuracy requirements for AI output in the medical field stipulated in the "Interim Measures for the Administration of Generative Artificial Intelligence Services."

[0066] In the fintech field, this mechanism addresses the industry pain point of "two sets of logics: health information and risk reasoning." Health insurance underwriting systems can accurately anchor the correlation between "health status and premium pricing" based on logically consistent reasoning data (e.g., the reasoning "poor diabetes control - 20% premium increase" aligns with patient blood glucose data), avoiding pricing risks or customer complaints caused by contradictory reasoning. Unlike traditional methods relying on manual sampling, this mechanism achieves full data verification with a response time controlled within seconds, adapting to the efficiency requirements of high-frequency underwriting scenarios in the financial sector. After completing logical consistency verification and correction, the output combination of "consultation dialogue data and standard reasoning data" provides high-quality samples that are "semantically coherent and logically rigorous" for training subsequent lightweight consultation models, ensuring the model's dual reliability in generating medical treatment suggestions and supporting financial risk assessment.

[0067] Step S140: The logical reasoning data is screened for quality based on a preset quality standard to obtain standard reasoning data that meets the preset quality standard.

[0068] It should be noted that the core of step S140 is to construct a two-layer quality screening mechanism of "model identification and standard verification." This mechanism accurately extracts core elements (medical theories and intervention techniques) from the logical reasoning data through a multi-task classification model, and then verifies the compliance of these elements and their relationships using an authoritative standard database. This ensures that the final output standard reasoning data conforms to both clinical norms in the healthcare field and risk assessment requirements in the fintech field. This mechanism addresses the problems of "reliance on subjective human judgment and inconsistent standards" in traditional screening from two dimensions: "accuracy of element identification" and "standard compliance." In the medical field, it can exclude erroneous reasoning that violates clinical guidelines (such as evidence of contraindicated medication); in the financial field, it can screen out risk logic that does not meet underwriting medical standards (such as incorrect medical history-premium association), providing "highly compliant and highly reliable" sample materials for subsequent lightweight model training.

[0069] In some embodiments of the present invention, such as Figure 6 As shown, step S140 includes the following steps.

[0070] Step S141: Input the logical reasoning data into the multi-task classification model, and use the theoretical recognition head and technical recognition head in the multi-task classification model to identify the medical theory and intervention technology of the logical reasoning data respectively. Step S142: Input the data pairs formed by medical theories and intervention techniques into the standard database. Determine whether the medical theories, intervention techniques, and the correspondence between the medical theories and intervention techniques match the standard data in the standard database. If they match, standard reasoning data that meets the quality standards is obtained; otherwise, the logical reasoning data is filtered out.

[0071] Specifically, in step S141, the multi-task classification model needs to design a "dual recognition head, shared encoder" architecture for dual-domain characteristics. The shared encoder adopts a pre-trained model (such as MedFinBERT, which integrates the medical semantics of BioBERT and the financial semantics of FinBERT) fine-tuned by medical and financial dual-domain corpora to ensure accurate understanding of cross-domain professional terms. The two task recognition heads focus on "medical theory extraction" and "intervention technology extraction" respectively, both of which adopt a fully connected layer and softmax activation function structure to output the classification labels and text fragments of the corresponding elements. The medical theory identification head needs to extract the clinical evidence supporting the conclusions from the reasoning data, including authoritative guideline clauses, disease diagnostic criteria, and medication principles. For example, from the reasoning data "Patient's body temperature is 38.5℃, ibuprofen is recommended, because the body temperature exceeds 38.3℃, antipyretics are needed, and ibuprofen has no contraindications for gastric ulcers," the medical theory identified is "The 2024 Guidelines for the Diagnosis and Treatment of Acute Fever in Adults state that 'antipyretics can be used when the body temperature is ≥38.3℃'" and "Ibuprofen is suitable for patients with gastric ulcers." The intervention technology identification head needs to extract specific medical procedures or plans, including medication plans, examination items, and nursing recommendations. In the above example, the intervention technology identification result is "Oral ibuprofen (0.2g each time, once every 6 hours)." The medical theory identification head needs to extract medical standards related to risk assessment. For example, from the inference data "Patient has a 2-year history of diabetes, glycated hemoglobin is 6.5%, premium increases by 10%, because this indicator meets the standard, it meets the lenient underwriting standard," the medical theory identified is "The 'Health Insurance Underwriting Medical Standards' state that 'diabetic patients with glycated hemoglobin <7.0% are considered well-controlled'." The intervention technology identification head needs to extract specific technical basis related to medical expenses and risk level. In the above example, the intervention technology identification result is "Glycated hemoglobin is monitored once per quarter (annual monitoring cost is about 400 yuan)" and "The estimated annual medical expenses for well-controlled diabetic patients are 3000 yuan." After identification, the model will output the extracted medical theories and intervention technologies in the form of "text fragments and element type labels," forming data pairs to be verified (e.g., <Medical Theory: [Guideline Clause], Intervention Technology: [Medication Regimen]>).

[0072] Specifically, in step S142, the standard database needs to construct a dual-database architecture of "medical standard sub-database and financial standard sub-database". The two sub-databases are linked through the mapping relationship of "medical code and financial risk label" to ensure the consistency of cross-domain standards. The database needs to be updated regularly (the medical sub-database synchronizes the latest clinical guidelines every year, and the financial sub-database updates the underwriting rules and actuarial parameters every quarter) to ensure the timeliness and authority of the standards. The medical standards sub-library includes the "Compilation of Clinical Practice Guidelines" (such as the specialty guidelines published by the Chinese Medical Association), the "National Essential Medicines List," the "ICD-10 Disease Coding Library," and the "Drug Contraindications Database," etc., with the storage format being "Standard ID, Standard Content, Applicable Scenario," for example, "ID: MED-001, Content: Maximum single dose of ibuprofen for adults is 0.4g, Applicable Scenario: Acute fever reduction"; the financial standards sub-library includes the "Health Insurance Underwriting Rules Manual," the "Medical Expense Actuarial Database," and the "Risk Level and Premium Coefficient Mapping Table," etc., with the storage format being "Standard ID, Medical Basis, Financial Parameters," for example, "ID: FIN-005, Medical Basis: Glycated hemoglobin in diabetes <7.0%, Financial Parameters: Premium increase coefficient 10%-15%, estimated annual medical expenditure 3000-5000 yuan."

[0073] The matching and judgment logic process includes: verifying whether the medical theory exists in the medical standards sub-database (or the medical basis associated with the financial sub-database), and directly filtering it if it does not exist; verifying whether the intervention technology meets the requirements of the corresponding medical theory (such as whether the drug dosage is within the recommended range of the guidelines, and whether the medical expenditure estimate is consistent with the actuarial data); and verifying whether the correspondence between the two is reasonable (such as if the medical theory is "grade 2 hypertension requires antihypertensive drugs", and the intervention technology is "recommended exercise to lower blood pressure", then the correspondence is contradictory). In the medical field: If the medical theory behind the inference data is "cephalosporins can be used by those allergic to penicillin," and the intervention technique is "cefixime is recommended," and the "Drug Contraindications Database" in the medical standards sub-library clearly states that "there is a 3%-7% risk of cross-allergy when using cephalosporins by those allergic to penicillin, and these should be excluded first," then it is determined that "the medical theory conflicts with the standard," and the inference data is removed. In the financial field: If the medical theory behind the inference data is "no recurrence for 5 years after lung cancer surgery is considered a clinical cure," and the intervention technique is "annual medical expenditure estimated at 10,000 yuan," and the "Medical Expense Actuarial Database" in the financial standards sub-library shows that "the annual follow-up cost for clinically cured lung cancer patients is approximately 2,000 yuan," then it is determined that "the intervention technique deviates too much from the standard data," and the inference data is removed. If all three match (e.g., the medical theory conforms to the guidelines, the intervention technique meets the theoretical requirements, and the correspondence is reasonable), then the logical inference data is marked as "standard inference data" and proceeds to the subsequent sample construction stage.

[0074] Understandably, step S140 achieves "automation, standardization, and dual-domain adaptation" in the screening of logical reasoning data quality through "precise decomposition and interpretation of multi-task models and rigid verification using dual-domain standard libraries." In the healthcare field, this mechanism eliminates reasoning data that violates clinical norms (such as incorrect medication guidelines or logic that does not meet diagnostic criteria) from the source, ensuring that the treatment recommendations output by the subsequent lightweight consultation model are "based on authoritative evidence and free from medical risks." For example, when primary healthcare institutions use the model, they can trust that the recommended medication regimens comply with the National Pharmacopoeia, avoiding medical accidents caused by erroneous reasoning. At the same time, the regular updating mechanism of the standard database allows the model to adapt to the latest clinical guidelines in a timely manner, maintaining medical professionalism. In the fintech field, this mechanism addresses the core pain point of "the disconnect between medical standards and financial rules." Health insurance companies can use the data from the screened standards to ensure that the basis for underwriting decisions not only conforms to common medical knowledge (such as the criteria for "well-controlled diabetes") but also matches actuarial models (such as the correlation between medical expenditure estimates and premium pricing). This avoids pricing deviations caused by non-compliant reasoning data (such as increasing premiums for well-controlled diabetes patients according to the standards for severe illness) or customer complaints (such as the inability to provide medical evidence for premium increases). In addition, the dual-database linkage design allows the financial standards sub-database to directly reuse authoritative data from the medical standards sub-database, reducing the cost and errors of financial institutions building their own medical standards.

[0075] Step S150: Combine the consultation dialogue data and the standard inference data corresponding to the consultation dialogue data to form a training sample of a preset lightweight large language model, wherein the number of parameters of the lightweight large language model is below a second threshold, and the second threshold is less than the first threshold.

[0076] Specifically, in this step, the combinational logic is centered on "precise mapping between input and output." That is, the consultation dialogue data serves as the training input for the lightweight large language model, and the standard inference data serves as the training output for the model. The two are linked by semantic delimiters to ensure that the model can learn the complete logical chain of "health needs - professional response and reasoning basis." At the same time, the second threshold of parameters for the lightweight model needs to be set in combination with the dual-domain deployment requirements, usually between 100 million and 1 billion parameters (such as Llama27B and DistilMedBERT with 80 million parameters), which is significantly lower than the first threshold of the heavyweight model (≥100 billion parameters). This setting not only meets the dual-domain requirements for inference speed (inference time for a single sample <1 second), but also adapts to the computing power limit of resource-constrained devices (such as medical terminals and financial mini-programs) (no distributed cluster is required; ordinary GPUs / CPUs can run it). In the healthcare field: Consultational data includes "patient questions (e.g., 'sore throat and fever of 38.2℃ for the past 3 days') and diagnostic responses (e.g., 'I recommend taking Lanqin oral liquid')". Standard inference data must match medical guidelines, covering "medical theory (the 'Guidelines for the Diagnosis and Treatment of Acute Pharyngitis' states 'for sore throat with low-grade fever, traditional Chinese medicine for clearing heat and detoxifying'), intervention techniques (Lanqin oral liquid for adults, 10ml each time, 3 times daily, with no contraindications for spleen and stomach deficiency), and logical association (the patient's symptoms match acute pharyngitis, with no contraindications, therefore this drug is recommended)". This combination forms a training sample of "input: consultational dialogue about sore throat and fever; output: medical inference data", used for model learning of clinical diagnostic logic. In the fintech field: the consultation dialogue data includes "patient questions (e.g., 'Can I get critical illness insurance if I have breast nodules of BI-RADS2 type?') and the diagnostic answers (e.g., 'Standard coverage is available, no premium increase')". The standard inference data must conform to the underwriting rules and cover "medical theory ('BI-RADS2 type nodules are benign and have no risk of malignancy' according to the 'Medical Standards for Health Insurance Underwriting'), intervention techniques (annual check-up cost is about 300 yuan, with no additional medical expenses risk) and logical connections (benign nodules have no risk and meet the standard coverage conditions)". After combination, a training sample is formed with "input: health insurance consultation dialogue, output: underwriting inference data" to be used for the model to learn the logic of health risk assessment.

[0077] In addition, the samples must undergo quality control after construction: First, logical consistency verification is performed to ensure that there are no contradictions between the consultation dialogue data and the standard inference data (e.g., in the medical field, samples with "patient allergy to penicillin + inference data recommending amoxicillin" are excluded, and in the financial field, samples with "benign nodules + inference data showing increased premiums" are excluded); Second, deduplication and redundancy filtering is performed, using text hashing algorithms to identify duplicate samples (e.g., the same consultation dialogue, the same inference data), and retaining one high-quality sample; Third, domain labels are refined, with the medical field labeled with "disease type (e.g., acute pharyngitis) and treatment stage (e.g., medication recommendation)", and the financial field labeled with "business type (e.g., critical illness insurance underwriting) and risk level (e.g., low risk)", to ensure that the model accurately adapts to the subdivided scenarios of the two domains.

[0078] Understandably, this solution addresses the core pain point of traditional model training sample construction through "structured combination and lightweight adaptation": traditional solutions either train lightweight models using only "consultation dialogue data," resulting in models that only "imitate responses" without understanding the "reasoning basis" (e.g., medical models recommending drugs without explaining the reasons, or financial models providing underwriting conclusions without explaining the risk logic); or they rely on manual combination of "dialogue and reasoning" samples, which is inefficient (manual annotation of one sample takes 5-10 minutes) and costly (annotation cost of approximately 2 yuan per sample). This solution, through automated combination logic, improves sample construction efficiency by more than 100 times (processing at least 100 samples per second), while allowing lightweight models to learn the "logic behind the responses," thus technically solving the problem of "poor model interpretability."

[0079] Furthermore, the core reason for the difficulty in deploying lightweight models in related technologies is the mismatch between parameter scale and device computing power. Heavyweight models (≥100 billion parameters) require multi-GPU clusters and cannot be deployed on primary healthcare terminals (such as tablets in township health centers) or financial end-user scenarios (such as WeChat mini-programs). While traditional lightweight models (<100 million parameters) are easy to deploy, their inference capabilities are weak due to poor sample quality. This solution sets the parameters of lightweight models to 100 million to 1 billion, which is suitable for dual-domain deployment scenarios (approximately 8-16GB of VRAM on medical tablets and approximately 100 GFLOPS of computing power on financial mini-program end-users). Through high-quality samples of "dialogue + inference," it ensures that the model's inference capabilities are close to those of heavyweight models (≥95% compliance rate for medical treatment recommendations and ≥92% accuracy rate for underwriting conclusions in the financial field), thus balancing "deployment flexibility" and "inference accuracy" from a technical perspective.

[0080] Furthermore, the core reason for the difficulty in reusing dual-domain samples in related technologies is that the samples are not associated with domain characteristics. Traditional samples either only contain medical information, which cannot support financial risk assessment, or only contain financial information, which cannot adapt to medical diagnosis and treatment needs. This solution, through the design of "domain labels and dual-domain inference data," allows the same lightweight model to serve both medical and financial scenarios simultaneously: the medical scenario calls the inference logic of "medical theory and intervention technology," while the financial scenario calls the inference logic of "underwriting rules and risk assessment." This fills the technical gap of "one model for dual-domain reuse," significantly reduces the development and maintenance costs of dual-domain models (eliminating the need to develop separate models for medical and financial purposes), and further improves the cost-effectiveness of technology applications.

[0081] Step S160: Use the patient's question data in the training sample as the input data of the lightweight large language model, and use the diagnostic's response data and the standard recommendation data in the training sample as the output data of the lightweight large language model to train the preset lightweight large language model and obtain the trained consultation model.

[0082] It should be noted that the core of step S160 is to use an efficient training mechanism of "parameter freezing, low-rank adaptation, and targeted fine-tuning" to precisely inject professional logic from the fields of healthcare and fintech while retaining the general semantic understanding capabilities of lightweight large language models. This ultimately results in a diagnostic model that combines "lightweight deployment characteristics" with "dual-domain professional reasoning capabilities." This mechanism solves the problems of "high training cost and easy overfitting" associated with traditional full-parameter fine-tuning, and is particularly suitable for scenarios with large differences in sample size between the two domains and rapid updates in professional knowledge.

[0083] In some embodiments of the present invention, such as Figure 7 As shown, step S160 includes the following steps: Step S161: Freeze the original parameters of the lightweight large language model; Step S162: Inject a trainable low-rank adapter matrix into the query projection matrix and key projection matrix of the multi-head attention module of the lightweight large language model to generate the lightweight large language model to be fine-tuned. Step S163: Use the patient's question data in the training sample as the input data of the lightweight large language model to be fine-tuned, and use the diagnostic's response data and the standard recommendation data in the training sample as the output data of the lightweight large language model to be fine-tuned, and fine-tune the preset lightweight large language model to obtain the fine-tuned consultation model.

[0084] Specifically, in step S161, freezing the original parameters of the lightweight large language model is to preserve the general knowledge learned during the model's pre-training phase (such as natural language understanding and basic logical reasoning) and avoid "catastrophic forgetting" caused by fine-tuning coverage. The original parameters of the lightweight model (such as Llama2 with 1 billion parameters) include the ability to encode general vocabulary, grammatical structures, and cross-domain basic concepts (such as the basic semantics of "disease" and "insurance"), which are the foundation for understanding medical consultation dialogue data. The freezing scope covers all basic modules of the model: including word embedding layers (converting text into vectors), the value projection matrix of the multi-head attention module, feedforward neural network layers (FFN), layer normalization parameters, etc. The freezing mechanism is implemented by setting the parameters "requires_grad=False" to ensure that these parameters are not updated during fine-tuning, and only their pre-training weights are retained. For both domains, the value of freezing operations lies in the fact that the medical domain needs to retain the model's basic understanding of "symptom description-disease association" (such as the association between "fever" and "infection"), and the financial domain needs to retain the basic understanding of "health information-risk association" (such as the association between "chronic disease" and "insurance premium"), providing a "general semantic foundation" for the subsequent injection of domain expertise.

[0085] Specifically, in step S162, injecting a trainable low-rank adapter (LoRA) matrix is ​​the core technology for achieving "efficient domain adaptation". The principle is to reduce the number of parameters to be trained by low-rank decomposition (decomposing a high-dimensional matrix into the product of two low-dimensional matrices) and inserting the adapter only in the query (Q) and key (K) projection matrices of the multi-head attention module, thereby achieving the goal of "learning domain knowledge with a small number of parameters".

[0086] Specifically, in step S163, the fine-tuning process is centered on “input-output oriented learning”. It uses patient question data (input) and “diagnostic response + standard inference data” (output) in the training samples to update only the parameters of the low-rank adapter matrix, thereby enabling the model to learn the dual-domain professional logic. Fine-tuning parameter settings: The AdamW optimizer is used, with a learning rate of 3e-4 (a higher learning rate can be used because only a small number of adapter parameters are being trained), a weight decay coefficient of 0.01, and 8-15 training epochs (adjusted according to the sample size to ensure that the adapter parameters fully learn domain knowledge); the loss function still uses cross-entropy loss, but only the error between the output data and the model prediction is calculated, and the gradient is only backpropagated to the adapter matrices A and B; in the medical field: the input is "patient: 60 years old, history of hypertension for 5 years, blood pressure 160 / 95 mmHg in the past week, no change of medication", and the output is "response: it is recommended to increase the amlodipine dosage to 5mg / day; inference data: medical theory 'Guidelines for the Prevention and Treatment of Hypertension' 'blood pressure ≥160 / 90mmHg requires medication adjustment'; intervention technology: the maximum daily dose of amlodipine is 10mg, the current dose is 2.5mg, and it is safe to increase the dosage." During fine-tuning, the adapter matrix learns the mapping logic of "duration of hypertension history + current blood pressure value - medication adjustment range" to ensure that the model output conforms to clinical dosage standards. In the financial field: the input is "patient: 45 years old, with a 3-year history of gout, 2 attacks per year, wants to apply for medical insurance", and the output is "response: premium increase of 15%; inference data: medical theory 'underwriting standards' 'gout ≥ 2 attacks per year is medium risk'; intervention technology: average annual treatment cost of about 1200 yuan, risk coefficient 1.15". During fine-tuning, the adapter matrix learns the association rule of "gout attack frequency - risk coefficient - premium increase ratio" to ensure that the underwriting conclusion is consistent with the actuarial model.

[0087] More specifically, the validation of the fine-tuning effect needs to be evaluated through dual-domain-specific indicators to ensure that the model simultaneously meets the requirements of medical safety and financial reliability: Medical domain validation indicators: compliance rate of treatment recommendations (≥96%, consistent with the Clinical Guidelines), accuracy rate of medication dosage (≥98%, in line with the instructions), and completeness rate of reasoning basis (≥95%, including medical theory and intervention techniques). For example, for the question "poor blood glucose control in diabetic patients," the model should output "add SGLT-2 inhibitors" (compliant recommendation) and "according to the Diabetes Guidelines, this type of drug is suitable for patients with blood glucose ≥9.0 mmol / L" (complete reasoning); Financial domain validation indicators: accuracy rate of underwriting conclusions (≥93%, consistent with manual underwriting), risk coefficient matching degree (≥94%, premium increase ratio corresponds to risk level), and correctness rate of rule citation (≥96%, reasoning basis complies with the terms of the Underwriting Manual). For example, when consulting about insurance for "BI-RADS 3 breast nodules", the model should output "premium increase of 20%" (accurate conclusion) and "according to the terms, 'the risk of malignancy of 3 nodules is 1%-2%, corresponding to a risk coefficient of 1.2'" (correct rule reference).

[0088] Understandably, step S160 addresses three core pain points of traditional lightweight model training through its "parameter freezing and low-rank adaptation" fine-tuning mechanism: High training cost: Traditional full-parameter fine-tuning requires updating all model parameters (e.g., optimizing 1 billion parameters for a 1 billion-parameter model), resulting in long training times (10+ hours per round) and high computational consumption (requiring 8 GPUs). This solution trains only 0.1%-1% of the adapter parameters (1 million-10 million), reducing training time to 1-2 hours and computational costs by 90%, adapting to the rapid iteration needs of dual domains (e.g., annual updates to medical guidelines and quarterly adjustments to financial rules). Risk of overfitting: Limited high-quality samples across dual domains (e.g., rare disease diagnosis and treatment dialogues, special underwriting cases) make full-parameter fine-tuning prone to causing the model to "memorize" samples rather than learn the logic. This solution freezes general parameters to retain basic capabilities, learning domain knowledge only through adapters, reducing overfitting risk by over 60% (standard deviation of compliance rate in the medical field reduced from 5% to 2%). Domain Adaptation Conflict: The logic of the medical and financial domains differs greatly (medical care focuses on clinical safety, while finance focuses on risk pricing). Full fine-tuning can easily lead to improved model performance in one domain but decreased performance in another. This solution achieves "improved medical capabilities do not affect financial performance, and vice versa" by using dual-domain targeted fine-tuning adapters (medical adapter and financial adapter can be trained separately). For example, after medical fine-tuning, the accuracy of financial underwriting still remains at 93% (only a 1% decrease).

[0089] In summary, this mechanism provides a lightweight model training solution that is "low-cost, high-efficiency, and highly adaptable" for both domains. It ensures that the consultation model can be deployed in resource-constrained scenarios such as primary healthcare terminals and financial mini-programs, while also outputting professional responses that comply with medical standards and financial rules, providing key technical support for the implementation of business in both domains.

[0090] In one embodiment, a training device for a medical history taking model is provided, and the evaluation device corresponds one-to-one with the training method for the medical history taking model in the above embodiments. For example... Figure 8 As shown, the evaluation device includes a data acquisition module 810, a logical reasoning module 820, a quality screening module 830, a sample combination module 840, and a model training module 850. Detailed descriptions of each functional module are as follows: The data acquisition module 810 is used to acquire consultation dialogue data, wherein the consultation dialogue data includes the patient's question data and the diagnostician's response data; The logic reasoning module 820 is used to input the consultation dialogue data into a heavyweight large language model and output logical reasoning data for the respondent's response data, wherein the number of parameters of the heavyweight large language model is above a first threshold. The quality screening module 830 is used to perform quality screening on the logical reasoning data based on a preset quality standard to obtain standard reasoning data that meets the preset quality standard. The sample combination module 840 is used to combine the consultation dialogue data and the standard recommendation data corresponding to the consultation dialogue data to form a training sample of a preset lightweight large language model, wherein the number of parameters of the lightweight large language model is below a second threshold, and the second threshold is less than the first threshold. The model training module 850 is used to take the patient's question data in the training sample as the input data of the lightweight large language model, and the diagnostic's response data and the standard recommendation data in the training sample as the output data of the lightweight large language model to train the preset lightweight large language model and obtain the trained consultation model.

[0091] In one embodiment, the logic reasoning module 820 is specifically used for: Generate structured fields corresponding to the preset medical inference parameters; The structured fields corresponding to the medical inference parameters are used as structured fields of the inference data instruction template to construct the inference data instruction template; Analyze the consultation dialogue data to obtain the medical inference parameter values ​​corresponding to the medical inference parameters in the consultation dialogue data; The medical inference parameter values ​​are filled into the structured fields of the inference data instruction template to obtain the updated inference data instruction template; Convert the updated inference data instruction template into structured prompt words; The structured prompts are input into a heavyweight large language model, and the output is logical reasoning data for the diagnostician's response data.

[0092] In one embodiment, the logic reasoning module 820 is further configured to: The consultation dialogue data and the standard inference data are combined to form a complete input sequence; The complete input sequence is input into a pre-trained language model, and the output is a comprehensive semantic representation encoded from the complete input sequence. The comprehensive semantic representation is input into an end-to-end consistency verification model trained with positive and negative examples, and the output is a classification result of whether the question-and-answer dialogue data and the standard inference data are logically consistent. The positive examples are data pairs corresponding to the question-and-answer dialogue data and the standard inference data that are logically consistent, and the negative examples are data pairs corresponding to the question-and-answer dialogue data and the standard inference data that are not logically consistent. If the classification result shows a logical inconsistency between the consultation dialogue data and the standard inference data, then the logical inference data will be regenerated.

[0093] In one embodiment, the model training module 850 is specifically used for: Freeze the original parameters of the lightweight large language model; In the query projection matrix and key projection matrix of the multi-head attention module of the lightweight large language model, a trainable low-rank adapter matrix is ​​injected to generate the lightweight large language model to be fine-tuned. The patient's question data in the training sample is used as the input data of the lightweight large language model to be fine-tuned. The diagnostic's response data and the standard recommendation data in the training sample are used as the output data of the lightweight large language model to be fine-tuned. The preset lightweight large language model is then fine-tuned to obtain the fine-tuned consultation model.

[0094] In one embodiment, the logic reasoning module 820 is further specifically used for: The consultation dialogue data is input into a heavyweight large language model with a number of parameters above the first threshold, wherein the deployment and execution of the heavyweight large language model depends on distributing its parameters to the storage units of multiple parallel computing units; The heavyweight large language model is run, and forward computation is performed through the multi-layer transformer structure inside the heavyweight large language model to generate and output the logical reasoning data that conforms to the predefined format.

[0095] In one embodiment, the quality screening module 830 is specifically used for: The logical reasoning data is input into a multi-task classification model, and the medical theory and intervention technology of the logical reasoning data are identified by the theoretical identification head and the technical identification head in the multi-task classification model, respectively. The data formed by medical theories and intervention techniques are input into a standard database. The standard database is used to determine whether the medical theories, intervention techniques, and the correspondence between the medical theories and intervention techniques match the standard data in the standard database. If they match, standard inference data that meets the quality standard is obtained; otherwise, the logical inference data is filtered out.

[0096] In one embodiment, the data acquisition module 810 is specifically used for: Obtain the consultation dialogue data to be filtered; The consultation dialogue data to be screened is input into a sequence model, and the completeness of the consultation dialogue data to be screened is identified and evaluated by the sequence model. Extract the consultation keywords from the consultation dialogue data to be filtered; The frequency of the consultation keywords in the preset medical keyword standard database was statistically analyzed. The patient's consultation dialogue data to be screened is input into a preset sentiment analysis model, and the output is a score of the positive change in the patient's emotions during the dialogue process. Based on the preset weights of the completeness, frequency of occurrence, and positive emotional change score, the preset weights of the completeness, frequency of occurrence, and positive emotional change score are weighted to obtain the comprehensive quality score of each of the consultation dialogue data to be screened. The consultation dialogue data that meets the preset score conditions for the comprehensive quality score will be used as the final consultation dialogue data.

[0097] This invention provides a training device for a medical consultation model. It generates logical reasoning data for the patient's responses using a heavyweight large language model, combines this data with the consultation dialogue data to form training samples for a lightweight large language model, and then fine-tunes the lightweight model by freezing the original parameters and injecting a low-rank adapter matrix. This eliminates the need for expensive hardware deployment of the heavyweight model and avoids the resource consumption of full-scale fine-tuning. This process leverages the strong reasoning capabilities of the heavyweight model to ensure the medical logic of the training data while adapting to resource-constrained scenarios through the lightweight characteristics of the lightweight model. In the medical field, the model can be deployed in primary healthcare centers and mobile diagnostic terminals; in the financial field, it can be integrated into health insurance underwriting mini-programs and medical credit risk control ports. The entire process achieves a balance between high-quality reasoning and low-cost deployment through model collaboration and efficient fine-tuning, eliminating the need for manual disassembly of medical logic or manual annotation of training samples. Therefore, this solution migrates the capabilities of a heavyweight model to a lightweight model, technically resolving the core contradiction of high deployment costs and low diagnostic accuracy in traditional medical consultation models, significantly reducing the threshold for implementing medical AI and the computational costs of financial and health services.

[0098] Furthermore, the core reason for the poor training data quality in related technologies is the singular and one-sided selection criteria for consultation data and the lack of medical compliance verification in inference data. This solution, however, assesses the completeness of consultation dialogue data through sequence models, statistically analyzes the frequency of medical keywords, and uses sentiment analysis models to output scores for positive emotional changes. A comprehensive quality score is calculated according to preset weights to ensure the effective information density of the input data. Further, after generating logical inference data, an end-to-end consistency verification model is used to verify the logical correlation between the inference data and the consultation dialogue. Then, a multi-task classification model combined with a standard database is used to select standard inference data that conforms to medical theories and intervention techniques. This eliminates invalid and logically broken data, as well as inference content that does not comply with medical standards, preventing low-quality data from causing model misdiagnosis at the data source. In the medical field, the diagnostic suggestions output by the model are more aligned with clinical guidelines, and in the financial field, the health risks assessed based on model data, such as the compliance of chronic disease medication and the probability of disease worsening, are more accurate, ensuring the reliability of business in both fields.

[0099] Furthermore, the core issue with existing diagnostic models in related technologies—the lack of medical logical reasoning—lies in their failure to uncover the underlying medical evidence behind the patient's responses. The models merely learn the surface text matching of questions and answers. This solution, however, explicitly uses a heavyweight language model to generate logical reasoning data for the patient's responses and combines this data with the diagnostic dialogue data as training samples. The lightweight model, during training, takes question data as input and outputs response and reasoning data. Essentially, this allows the model to not only learn the dialogue interaction format but also understand the corresponding medical logical chain of the responses. This design ensures that the model's output is not merely mechanical imitation but possesses interpretable medical evidence. In the medical field, this can assist primary care physicians in quickly grasping diagnostic approaches and reducing the risk of missed diagnoses. In the financial field, it can be used to formulate differentiated health insurance premium strategies based on the model's output reasoning data, filling the technical gap of traditional models that only provide results without supporting evidence, further enhancing the professionalism and credibility of both business areas.

[0100] Specific limitations regarding the training device for the diagnostic model can be found in the above section on the training method for the diagnostic model, and will not be repeated here. Each module in the aforementioned training device for the diagnostic model can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0101] The training method based on the above-mentioned consultation model, such as Figure 9 As shown in the diagram, this embodiment of the invention also provides a structural schematic of a device for training a consultation model. The device includes a processor 91 and a memory 92 coupled to the processor 91. The memory 92 stores a computer program, which, when executed by the processor 91, causes the processor 91 to perform the steps of the consultation model training method described in the above embodiment.

[0102] For further details regarding the implementation of the above technical solution by the processor 91 in the device for the training steps of the above-mentioned consultation model, please refer to the description in the training method of the consultation model provided in the above-mentioned embodiments of the invention, which will not be repeated here.

[0103] The processor 91 can also be called a CPU (Central Processing Unit). The processor 91 may be an integrated circuit chip with signal processing capabilities. The processor 91 can also be a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor, or the processor 91 can be any conventional processor.

[0104] like Figure 10 As shown in the diagram, this embodiment of the invention also provides a schematic diagram of a computer-readable storage medium, on which a readable computer program 101 is stored. The computer program 101 can be stored in the storage medium in the form of a software product, including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in various embodiments of the invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, magnetic disks or optical disks, ROM (Read-Only Memory), RAM (Random Access Memory), or terminal devices such as computers, servers, mobile phones, and tablets.

[0105] In the embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, apparatuses, or modules, and may be electrical, mechanical, or other forms.

[0106] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0107] Furthermore, the functional modules in the various embodiments of this invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium.

[0108] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0109] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium, or a semiconductor medium (e.g., SSD (solid state disk)).

[0110] The technical solution provided by the present invention has been described in detail above. Specific examples have been used to illustrate the principle and implementation of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core idea of ​​the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation and application scope based on the idea of ​​the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

[0111] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, optical storage, etc.) containing computer-usable program code.

[0112] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0113] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0114] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0115] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A training method for a medical history taking model, characterized in that, include: Acquire consultation dialogue data, wherein the consultation dialogue data includes the patient's question data and the diagnostician's response data; The consultation dialogue data is input into a heavyweight large language model, and logical reasoning data for the diagnosis data is output. The number of parameters of the heavyweight large language model is above a first threshold. The logical reasoning data is screened for quality based on preset quality standards to obtain standard reasoning data that meets the preset quality standards. The consultation dialogue data and the corresponding standard inference data are combined to form a training sample for a preset lightweight large language model, wherein the number of parameters of the lightweight large language model is below a second threshold, and the second threshold is less than the first threshold. The patient's question data in the training sample is used as the input data of the lightweight large language model, and the diagnostic's response data and the standard inference data in the training sample are used as the output data of the lightweight large language model. The preset lightweight large language model is trained to obtain the trained consultation model.

2. The training method for the medical history model according to claim 1, characterized in that, The step of inputting the consultation dialogue data into a heavyweight large language model and outputting logical reasoning data for the respondent's response data includes: Generate structured fields corresponding to the preset medical inference parameters; The structured fields corresponding to the medical inference parameters are used as structured fields of the inference data instruction template to construct the inference data instruction template; Analyze the consultation dialogue data to obtain the medical inference parameter values ​​corresponding to the medical inference parameters in the consultation dialogue data; The medical inference parameter values ​​are filled into the structured fields of the inference data instruction template to obtain the updated inference data instruction template; Convert the updated inference data instruction template into structured prompt words; The structured prompts are input into a heavyweight large language model, and the output is logical reasoning data for the diagnostician's response data.

3. The training method for the medical history model according to claim 1, characterized in that, After inputting the consultation dialogue data into a heavyweight large language model and outputting logical reasoning data for the diagnostician's response data, and before performing quality screening on the logical reasoning data based on preset quality standards to obtain standard reasoning data that meets the preset quality standards, the method further includes: The consultation dialogue data and the standard inference data are combined to form a complete input sequence; The complete input sequence is input into a pre-trained language model, and the output is a comprehensive semantic representation encoded from the complete input sequence. The comprehensive semantic representation is input into an end-to-end consistency verification model trained with positive and negative examples, and the output is a classification result of whether the question-and-answer dialogue data and the standard inference data are logically consistent. The positive examples are data pairs corresponding to the question-and-answer dialogue data and the standard inference data that are logically consistent, and the negative examples are data pairs corresponding to the question-and-answer dialogue data and the standard inference data that are not logically consistent. If the classification result shows a logical inconsistency between the consultation dialogue data and the standard inference data, then the logical inference data will be regenerated.

4. The training method for the medical history model according to claim 1, characterized in that, The step involves using the patient's question data from the training samples as input data for the lightweight large language model, and the diagnostician's response data and the standard inference data from the training samples as output data for the lightweight large language model, to train the preset lightweight large language model and obtain a trained consultation model, including: Freeze the original parameters of the lightweight large language model; In the query projection matrix and key projection matrix of the multi-head attention module of the lightweight large language model, a trainable low-rank adapter matrix is ​​injected to generate the lightweight large language model to be fine-tuned. The patient's question data in the training sample is used as the input data of the lightweight large language model to be fine-tuned. The diagnostic's response data and the standard inference data in the training sample are used as the output data of the lightweight large language model to be fine-tuned. The preset lightweight large language model is then fine-tuned to obtain the fine-tuned consultation model.

5. The training method for the medical history model according to claim 1, characterized in that, The step of inputting the consultation dialogue data into a heavyweight large language model and outputting logical reasoning data for the respondent's response data includes: The consultation dialogue data is input into a heavyweight large language model with a number of parameters above the first threshold, wherein the deployment and execution of the heavyweight large language model depends on distributing its parameters to the storage units of multiple parallel computing units; The heavyweight large language model is run, and forward computation is performed through the multi-layer transformer structure inside the heavyweight large language model to generate and output the logical reasoning data that conforms to the predefined format.

6. The training method for the medical history model according to claim 1, characterized in that, The process of screening the logical reasoning data based on preset quality standards to obtain standard reasoning data that meets the preset quality standards includes: The logical reasoning data is input into a multi-task classification model, and the medical theory and intervention technology of the logical reasoning data are identified by the theoretical identification head and the technical identification head in the multi-task classification model, respectively. The data formed by medical theories and intervention techniques are input into a standard database. The standard database is used to determine whether the medical theories, intervention techniques, and the correspondence between the medical theories and intervention techniques match the standard data in the standard database. If they match, standard inference data that meets the quality standard is obtained; otherwise, the logical inference data is filtered out.

7. The training method for the medical history model according to claim 1, characterized in that, The acquisition of consultation dialogue data includes: Obtain the consultation dialogue data to be filtered; The consultation dialogue data to be screened is input into a sequence model, and the completeness of the consultation dialogue data to be screened is identified and evaluated by the sequence model. Extract the consultation keywords from the consultation dialogue data to be filtered; The frequency of the consultation keywords in the preset medical keyword standard database was statistically analyzed. The patient's consultation dialogue data to be screened is input into a preset sentiment analysis model, and the output is a score of the positive change in the patient's emotions during the dialogue process. Based on the preset weights of the completeness, frequency of occurrence, and positive emotional change score, the preset weights of the completeness, frequency of occurrence, and positive emotional change score are weighted to obtain the comprehensive quality score of each of the consultation dialogue data to be screened. The consultation dialogue data that meets the preset score conditions for the comprehensive quality score will be used as the final consultation dialogue data.

8. A training device for a medical history taking model, characterized in that, include: The data acquisition module is used to acquire consultation dialogue data, wherein the consultation dialogue data includes the patient's question data and the diagnostician's response data; The logical reasoning module is used to input the consultation dialogue data into a heavyweight large language model and output logical reasoning data for the respondent's response data, wherein the number of parameters of the heavyweight large language model is above a first threshold. The quality screening module is used to perform quality screening on the logical reasoning data based on preset quality standards to obtain standard reasoning data that meets the preset quality standards. The sample combination module is used to combine the consultation dialogue data and the standard inference data corresponding to the consultation dialogue data to form a training sample of a preset lightweight large language model, wherein the number of parameters of the lightweight large language model is below a second threshold, and the second threshold is less than the first threshold. The model training module is used to take the patient's question data in the training samples as the input data of the lightweight large language model, and the diagnostic's response data and the standard inference data in the training samples as the output data of the lightweight large language model to train the preset lightweight large language model and obtain the trained consultation model.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the training method for the consultation model as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the training method for the consultation model as described in any one of claims 1 to 7.

Images