Self-adaptive evolution and reconstruction method of semantic map structure

Abstract

The invention discloses a semantic graph adaptive evolution and reconstruction method and system of an active medical system, and provides a closed-loop adaptive mechanism for solving the problems of medical AI knowledge lag and insufficient individualization caused by a static knowledge graph. Three collaborative optimization processes are driven based on trigger conditions: 1) individualized knowledge evolution: an exclusive semantic map subset is dynamically adjusted through continuous learning of user health data and feedback; 2) fusing new knowledge, executing semantic consistency verification and ethical compliance verification on the received external medical knowledge, and updating the atlas; and 3) performing model performance-driven reconstruction, and automatically triggering traceability analysis and structure reconstruction to repair knowledge defects when the reasoning performance index is reduced. According to the system, an incremental learning algorithm and a graph network adjustment technology are adopted, dynamic updating and personalized adaptation of a medical AI knowledge core are achieved, the problems of time lag and stiffness of a static knowledge base are solved, the long-term precision, safety and user credibility of the system are remarkably improved, and the system has great practical value.

Description

Technical Field

[0001] This invention relates to the field of computer technology, specifically to artificial intelligence, data processing, and knowledge engineering technologies, and particularly to a method and system for constructing, maintaining, and optimizing semantic graphs for proactive and intelligent medical and health management systems. Background Technology

[0002] With the rapid development of artificial intelligence (AI) technology, its application in the healthcare field is becoming increasingly widespread and in-depth, covering multiple aspects such as disease-assisted diagnosis, personalized treatment recommendations, chronic disease management, and health risk prediction. In these applications, knowledge graphs, as a key knowledge representation technology, can describe medical concepts, entities, and the complex relationships between them in a structured graph form, providing AI systems with powerful knowledge reasoning and decision support capabilities. Active medical systems represent an important development direction in smart healthcare, emphasizing that the system not only passively responds to user queries but also proactively monitors the user's health status, anticipates potential risks, and provides forward-looking health intervention suggestions. At the core of such systems is a high-quality, timely medical knowledge graph.

[0003] However, the core knowledge graphs of most current AI systems applied in the medical field are often static after construction, or their update mechanisms are very primitive and inefficient. This inherent deficiency of "static knowledge" poses a serious technical challenge in the rapidly evolving medical field, specifically in the following aspects:

[0004] First, there is the issue of "knowledge lag." Medicine is a constantly evolving science, with new diseases, diagnostic criteria, treatment methods, drug interactions, and other knowledge emerging continuously. A static knowledge graph built at a specific point in time will rapidly become outdated over time. For example, in the face of emerging infectious diseases like COVID-19, if the AI ​​system's knowledge graph cannot be updated in a timely manner, it cannot provide users with accurate early warnings and protective advice. This knowledge lag directly leads to a decline in the quality of the AI ​​system's output, and may even produce misleading or harmful conclusions, severely weakening the system's practical value and long-term viability.

[0005] Secondly, there is the issue of "lack of individualized adaptation." Medical practice emphasizes the principle of individualization, meaning that different individuals may have significantly different "normal" ranges for their physiological indicators due to factors such as genetics, lifestyle, and environment. For example, athletes who consistently exercise may have a resting heart rate far lower than the normal value for the general population, but this is considered normal physiological bradycardia. Traditional knowledge graphs built on universal medical knowledge struggle to capture and adapt to this individual specificity. When the system detects a low heart rate in an athlete, it may frequently issue unnecessary health alerts, not only bothering the user but also reducing their trust in the system.

[0006] Secondly, there is the issue of "decreased system robustness and reliability." Static knowledge graphs may contain errors or inaccurate knowledge associations introduced from the initial construction stage. During long-term system operation, these potential defects can be amplified by continuous data input, causing the inference engine to repeatedly deviate or fail in specific scenarios. For example, the ability to differentiate between certain diseases with complex and easily confused symptoms (such as anxiety disorder and certain heart problems) remains consistently low. Without effective self-correction and optimization mechanisms, the overall performance and reliability of the system will continue to decline, ultimately making it difficult to meet the stringent requirements of the medical field for high security and high reliability.

[0007] Currently, to address the aforementioned challenges, the industry has proposed several methods for updating knowledge graphs. For example, Chinese patent CN116383413B discloses a knowledge graph updating method based on medical data extraction. This method supplements the knowledge graph by extracting keywords and relationships from data sources such as electronic medical records. This method achieves automated incremental updates of knowledge to a certain extent, but its limitations are also quite obvious. It mainly relies on the statistics and extraction of existing data, lacking deep semantic verification of new knowledge, and cannot guarantee the logical consistency and medical rigor of the integrated knowledge. At the same time, its update is data-driven rather than system performance feedback-driven, and cannot proactively discover and repair deep defects in the graph structure that may lead to reasoning errors. In addition, it focuses more on updating general knowledge and is insufficiently involved in the deep individualized knowledge evolution. Another Chinese patent CN113111242A describes an adaptive learning path recommendation method based on knowledge graphs in the field of education. Although it also embodies the idea of ​​"adaptiveness," its adaptability is mainly reflected in planning paths in the existing knowledge graph according to the learner model, without involving the structural evolution and reconstruction of the knowledge graph itself.

[0008] To more clearly demonstrate the innovation and progress of this invention compared to existing technologies, the following table compares several typical technical solutions: feature Existing technology 1: Manual maintenance Existing technology 2: Simple data extraction (e.g.) Invention Solution Update trigger mechanism Artificial, periodic, passive Data-driven (when new medical records are available) Multidimensional triggers: individual data patterns, new external knowledge, and system performance degradation. Individualization No (general knowledge) Statistical association based on population data Deep personalization (e.g., adjusting individual physiological baselines) Knowledge Verification Expert review (slow, expensive) Basic cleaning rules (such as frequency thresholds) Automated semantic consistency and ethical rule verification Error correction capability Passive, manual repair Limited or None Proactive, performance-driven self-originating and structural reconfiguration Adaptation mechanism Content updates only Content updates only Dynamic evolution and reconstruction of the graph structure itself

[0009] In summary, existing technologies fail to provide a comprehensive, closed-loop solution to address the three core challenges of knowledge graphs in medical AI systems: dynamism, personalization, and credibility. Knowledge updates, personalized adaptation, and system performance self-optimization are often fragmented and incomplete. Therefore, a novel technical solution is urgently needed to organically combine these three elements, establishing an adaptive evolution and reconstruction mechanism that transforms the medical knowledge graph from a static "knowledge base" into a continuously learning and self-improving "living" knowledge entity. This is precisely the technical problem that this invention aims to solve. Summary of the Invention

[0010] This invention aims to address the technical shortcomings of existing proactive medical AI systems, namely, the static and rigid nature of their knowledge graphs, their lack of individualized adaptability, and their absence of self-correction mechanisms. Specifically, the core technical problem this invention addresses is: how to design a method and system that enables medical semantic graphs to automatically and continuously optimize their structure and content to adapt to the uniqueness of individual users, keep pace with the latest advancements in medical science, and self-correct based on the system's own performance, thereby fundamentally solving the problems of knowledge lag, insufficient individualized adaptation, and long-term decline in credibility.

[0011] To address the aforementioned technical problems, this invention provides a method for the adaptive evolution and reconstruction of semantic graphs in proactive healthcare systems. This method is executed on a computing device including a processor and memory, and its core lies in establishing a closed-loop self-optimization process driven by multi-dimensional triggering conditions. The method includes the following key steps:

[0012] First, the system continuously collects multimodal data from various data sources, such as wearable devices, electronic health records, and authoritative medical literature databases. This data is divided into two categories: one is personalized data reflecting the health status of a specific user, and the other is public medical knowledge data representing general medical knowledge.

[0013] Secondly, the system includes a trigger monitoring module that monitors a set of preset trigger conditions in real time. These conditions are carefully designed into three categories, each corresponding to different graph optimization needs: The first type of trigger condition is related to a specific and persistent pattern presented in individualized data. For example, the system detects that a user's physiological indicator has been consistently deviating from the general normal range for several consecutive months, but their overall health assessment is good. The second type of triggering condition is related to the receipt of new public medical knowledge data. For example, the system obtains an updated clinical guideline for a new drug through an interface. The third type of trigger condition is related to a decline in the performance of the proactive healthcare system itself. For example, the system's diagnostic accuracy for a certain type of disease has decreased by more than a preset percentage in the past quarter.

[0014] Then, based on the different triggering conditions detected, the system will initiate the corresponding adaptive process: When the first type of triggering condition is met, the system initiates a personalized knowledge evolution process. This process precisely locates the personalized subgraph in the semantic graph that is relevant to the specific user and fine-tunes its structure or parameters. For example, it adjusts the "normal" threshold range of the user's specific physiological indicators, or strengthens or weakens the knowledge associations related to their lifestyle habits. When the second type of triggering condition is met, the system initiates the new knowledge integration process. This process is responsible for safely and reliably integrating new public medical knowledge into the main knowledge graph. A key innovation is that this process includes a semantic consistency check step to ensure that the new knowledge does not conflict with existing core medical axioms (such as "penicillin is contraindicated for those with penicillin allergy") or ethical rules (such as avoiding racial bias) in the knowledge graph, thereby maintaining the logical consistency and security of the entire knowledge system. When the third type of triggering condition is met, the system initiates a performance-driven refactoring process. This is a deep self-healing mechanism. The system first uses source tracing analysis technology to backtrack and analyze error cases that led to performance degradation, accurately locating potentially defective structural parts in the graph (such as incorrect associations, missing paths, etc.). Subsequently, the system automatically optimizes these problematic subgraph structures, such as adding necessary associations, deleting or weakening incorrect connections, and even reorganizing the hierarchical structure of local subgraphs.

[0015] This invention also provides a system for implementing the above-described method. The system includes a data acquisition module, a trigger monitoring module, and an individualized evolution module, a new knowledge integration module, and a performance-driven reconstruction module, each executing the three core processes described above. These modules work together to form a complete and intelligent knowledge graph adaptive evolution and reconstruction system.

[0016] Compared with the prior art, the method and system proposed in this invention have the following significant advantages:

[0017] It achieves deep personalization and precision: Through a personalized knowledge evolution mechanism, the system transcends the "one-size-fits-all" general medical model, building and maintaining a dynamic, highly personalized health knowledge model for each user. The system "understands you better the more you use it," and the health advice and risk warnings it provides will be more closely aligned with the user's actual physical condition and lifestyle, greatly improving the accuracy of the service and the user experience.

[0018] It ensures the real-time and cutting-edge nature of knowledge: Through a new knowledge integration mechanism that includes semantic consistency verification, the system can quickly and securely absorb the latest medical research findings and clinical guidelines, effectively overcoming the "knowledge lag" problem of static knowledge bases. This enables the AI ​​system to always keep pace with the development of medical science, for example, to quickly develop cognitive and response capabilities in the face of emerging epidemics.

[0019] The system's robustness and long-term reliability have been enhanced: the innovative performance-driven refactoring mechanism empowers the system with self-reflection and repair capabilities. When the system performs poorly, it no longer passively awaits human intervention but proactively diagnoses the root cause of the problem and performs structural optimization. This closed-loop feedback self-improvement capability ensures that the system can maintain high performance over the long term, fundamentally enhancing the trust and security of the AI ​​system among users and medical professionals.

[0020] This invention significantly improves the automation level and economic efficiency of the system: It highly automates the entire lifecycle management of the knowledge graph (personalization, updating, and error correction), greatly reducing the reliance on expensive human expert resources for continuous maintenance. This not only reduces the operating costs of advanced medical AI systems but also enables their larger-scale promotion and application, possessing significant economic and social value. Attached Figure Description

[0021] Figure 1 This is a system architecture diagram for semantic graph adaptive evolution and reconstruction of an active medical system according to an embodiment of the present invention.

[0022] Figure 2 This is a general flowchart of a semantic graph adaptive evolution and reconstruction method according to an embodiment of the present invention.

[0023] Figure 3 yes Figure 2 The detailed flowchart of the individualized knowledge evolution sub-process in the method shown is as follows.

[0024] Figure 4 yes Figure 2 The method shown is illustrated with a detailed flowchart of how new knowledge is integrated into sub-processes.

[0025] Figure 5 yes Figure 2 The detailed flowchart of the model performance-driven refactoring sub-process in the method shown is as follows. Detailed Implementation

[0026] 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 embodiments of the present invention, and not all embodiments. 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.

[0027] Example 1: System Architecture

[0028] Reference Figure 1 This invention provides a system for the adaptive evolution and reconstruction of semantic graphs in proactive healthcare systems. The system can be deployed on a single server, a distributed server cluster, or in a cloud computing environment. Hardware-wise, the system relies on standard computing resources, including but not limited to one or more central processing units (CPUs), graphics processing units (GPUs), large-capacity memory, and persistent storage devices (such as solid-state drives and hard disk arrays). Software-wise, the system architecture is as follows... Figure 1 As shown, it mainly includes the following modules:

[0029] User & External Sources: This is the system's data input layer and the starting point of the entire adaptive evolution mechanism. It includes:

[0030] User devices (A): such as wearable devices like smartwatches, fitness trackers, smart scales, and continuous glucose monitors, as well as health management applications (Apps) on users' mobile phones. These devices continuously generate massive amounts of personalized data, such as heart rate, blood oxygen, sleep patterns, activity levels, and manually recorded dietary, symptom, and emotional feedback.

[0031] Electronic Health Record / Laboratory Information System (B): also known as EHR (Electronic Health Record) / LIS (Laboratory Information System). The system interfaces with the information systems of hospitals or medical examination institutions through standardized interfaces (such as HL7, FHIR) to obtain structured and unstructured medical data such as users' historical medical records, diagnostic records, test reports, and medication history.

[0032] Medical literature databases (C): such as PubMed, Cochrane Library, and official clinical guideline databases published by health departments in various countries. The system regularly retrieves the latest medical research papers, reviews, drug information, and treatment standards from these databases via web crawlers or API interfaces, serving as a source of public medical knowledge.

[0033] Core System: This is the core of the invention, responsible for data processing, knowledge storage, evolution, and application.

[0034] Data Acquisition Module (D): Acting as the system's "sensors," it connects to all external data sources and preprocesses the acquired raw data, including data cleaning, format conversion, deduplication, and preliminary entity recognition. For example, it aggregates continuous heart rate data from wearable devices into features such as daily averages and maximum / minimum values; and it extracts key entities such as symptoms, diseases, and medications from unstructured medical record text using Natural Language Processing (NLP) technology.

[0035] Semantic Graph Database (E): Serving as the "brain" of the system, it stores and manages core knowledge assets. In this embodiment, the graph is preferably constructed using the DIKWP (Data-Information-Knowledge-Wisdom-Intent) model. This is a multi-layered semantic network:

[0036] Data layer: Stores the most raw, uninterpreted observations, such as "heart rate: 52 bpm".

[0037] Information layer: Contextualizes and interprets data, such as "User A's resting heart rate is 52 bpm, which is lower than the standard (60-100 bpm)".

[0038] The Knowledge layer contains validated, universally applicable rules and relationships, such as "One of the diagnostic criteria for bradycardia (disease) is a resting heart rate below 60 bpm"; "Endurance athletes (population characteristics) may exhibit physiological bradycardia (knowledge)".

[0039] Wisdom layer: Contains higher-level meta-knowledge about ethics, principles, and trade-offs, such as "When providing health advice, non-invasive, low-risk interventions should be prioritized"; "Avoid causing unnecessary anxiety to users due to a single abnormal indicator."

[0040] The Purpose layer defines the goals of the system and the user, such as "the user's intention is to maintain health and prevent heart disease"; "the system's intention is to provide accurate, reliable, and personalized health management services".

[0041] This database is typically implemented using specialized graph database technologies (such as Neo4j, JanusGraph) to support efficient complex relation queries and graph traversal.12

[0042] The inference engine (F) uses knowledge stored in the semantic graph database (E) to analyze, reason, and make decisions on the input real-time data. For example, when new user data is received, the inference engine performs multi-step reasoning in the graph and finally outputs a specific system action (G), such as "sending a suggestion to the user: 'Your sleep quality has declined recently, and we suggest trying meditation before bed.'"

[0043] The performance monitoring module (H) acts as the system's "reflection" mechanism, continuously evaluating the output (G) of the inference engine (F). It compares the system's predictions or suggestions with the "gold standard" (such as subsequent doctor diagnoses or actual user feedback) to calculate key performance indicators (KPIs), such as diagnostic accuracy, suggestion adoption rate, and entropy reduction efficiency. These quantified performance indicators are crucial for driving graph reconstruction.

[0044] Trigger Monitoring Module (I): Serving as the "scheduling center" of the entire adaptive evolution mechanism. It receives data pattern analysis results from the data acquisition module (D), performance indicators from the performance monitoring module (H), and monitors update signals from external knowledge sources. Based on preset rules, it determines whether any of the three types of triggering conditions are met and activates the corresponding evolution / reconstruction module.

[0045] Core Evolution Engine: This is the most innovative part of the invention, consisting of three functional modules:

[0046] Individualized Evolution Module (J): Responsible for processing specific data patterns from individual users and fine-tuning the individualized subgraph for that user.

[0047] New Knowledge Integration Module (K): Responsible for safely integrating new, general medical knowledge from outside sources into the main atlas.

[0048] Performance-Driven Refactoring Module (L): Responsible for deep, structural repair and optimization of the graph when system performance degrades.

[0049] After receiving the instruction from the trigger monitoring module (I), these three modules will execute the corresponding algorithm and submit their modifications to the graph (modifying subgraphs, adding / modifying graphs, reconstructing graphs) to the semantic graph database (E), thereby completing a closed-loop adaptive optimization.

[0050] Example 2: Overall Method Flow

[0051] Reference Figure 2 This invention provides an overall process for a semantic graph adaptive evolution and reconstruction method. This process is a continuously running loop, ensuring the real-time nature and adaptability of the knowledge graph.

[0052] Step S201: Continuously collect multimodal data

[0053] After the system starts, the data acquisition module ( Figure 1 (D) It enters a continuous working state. It pulls or receives data in parallel from multiple sources, such as user devices, medical information systems, and medical literature databases, through various interfaces. The collected data is diverse, including but not limited to:

[0054] Personalized time-series data: such as heart rate per minute, blood glucose level per hour, and daily steps.

[0055] Personalized event data: such as a medical visit record, a medication event, or a user's feedback of "feeling unwell".

[0056] Personalized static data: such as the user's age, gender, allergy history, and genetic history.

[0057] Public knowledge data: such as a newly published meta-analysis article on treatment options for a disease, or an updated vaccination guideline from an authoritative organization.

[0058] All collected data will undergo preprocessing before flowing into subsequent analysis and storage modules.

[0059] Step S202: Check triggering conditions

[0060] Trigger monitoring module ( Figure 1 The "I" in this context is the core decision point of the process. It continuously analyzes information gathered from various modules to determine whether preset triggering conditions are met. This is a parallel, multi-dimensional monitoring process.

[0061] Monitoring Individual Data Patterns: The module's internal analytics engine performs pattern recognition on each user's long-term data. For example, using time-series analysis algorithms, it might detect that user A's resting heart rate has remained consistently between 50-55 bpm over the past 30 days, significantly lower than the common threshold of 60 bpm. This could constitute a "Type I trigger condition."

[0062] Monitoring the availability of new knowledge: The module polls or subscribes to external knowledge sources. When an event such as "The World Health Organization has released new diagnostic criteria for hypertension" is detected, a "Type II trigger condition" is met.

[0063] Monitoring system performance: The module will continuously receive data from the performance monitoring module ( Figure 1The report (H) shows that, for example, the system's recall for predicting "early risk of type 2 diabetes" dropped from 90% to 75%, below the preset threshold of 80%. This satisfies a "third-order trigger condition".

[0064] If no conditions are triggered at present, the process will return to step S201 to continue data collection and monitoring. If one or more conditions are triggered, the process will switch to the corresponding subprocess.

[0065] Step S203: Execute the individualized evolution process

[0066] If the first type of triggering condition is detected, the system will call the individualized evolution module ( Figure 1 (J) initiates fine-tuning of the knowledge graph for a specific user. The detailed steps of this process will be elaborated in Example 3. After the evolution is completed, the process returns to step S201.

[0067] Step S204: Implement the new knowledge integration process

[0068] If the second type of triggering condition is detected, the system will invoke the new knowledge integration module. Figure 1 (K in the original text) initiates the general knowledge update process. The detailed steps of this process will be described in Example 4. After integration is complete, the process returns to step S201.

[0069] Step S205: Execute the performance-driven refactoring process

[0070] If the third type of triggering condition is detected, the system will call the performance-driven refactoring module. Figure 1 (L in the diagram) initiates deep optimization of the spectral structure. The detailed steps of this process will be described in Example 5. After reconstruction is completed, the process returns to step S201.

[0071] Through such a closed-loop "collection-monitoring-response" process, the method of this invention can ensure that the semantic graph is always in a dynamic and self-improving process, thereby providing the highest quality and most reliable knowledge foundation for the upper-level inference engine.

[0072] Example 3: Detailed Explanation of the Individualized Knowledge Evolution Subprocess

[0073] Reference Figure 3 This process details how to personalize the semantic graph when the system detects meaningful data patterns related to a specific individual. The core idea of ​​this process is to enable the knowledge graph to "recognize" and "adapt" to the uniqueness of each user.

[0074] Step S301: Receive individualized trigger signal

[0075] The process begins with triggering the monitoring module ( Figure 1 The I) signal sends a specific, individualized trigger signal. This signal not only indicates the occurrence of the triggering event but also contains key contextual information, such as: {User ID: 'User123', Trigger Type: 'Persistent physiological indicator deviation', Indicator: 'Resting heart rate', Observation: 'Average 52 bpm', Duration: '90 days', Associated health status: 'Good'}.

[0076] Step S302: Locate the individualized subgraph and related nodes

[0077] Individualized Evolutionary Module ( Figure 1 Upon receiving the signal, J) first locates the user-specific subgraph within the vast semantic graph database based on the user ID. This subgraph stores all the user's personal information, historical data summaries, and personalized connections to the general knowledge graph. Next, based on the indicator information ("resting heart rate") in the signal, the module further locates specific nodes or relationships within this subgraph. This could be an attribute node representing "User123's normal resting heart rate range," or a relationship connecting the "User123" node and the general "bradycardia" knowledge node.

[0078] Step S303: Apply evolutionary algorithm to adjust the graph parameters

[0079] This is the core operation of this process. The module will select an appropriate algorithm to adjust the located map elements based on the specific content of the trigger signal.

[0080] Scenario 1: Adjusting the Threshold. Using the example of heart rate as the trigger signal, the definition of the "bradycardia" node in the general knowledge layer might be associated with a rule: IF heart rate < 60 THEN state = bradycardia. Since the trigger signal indicates that the user's low heart rate is benign, the evolutionary algorithm will create an override rule or modify its specific parameters for the User123 subgraph. For example, the lower limit of the "normal resting heart rate range" node in this user's subgraph might be adjusted from the default 60 to 50. This can be accomplished with a simple parameter update operation.

[0081] Scenario 2: Adjusting Relationship Weights. Suppose the system continuously monitors a user's blood glucose levels after high-intensity interval training (HIIT), noting a temporary increase in the short term but improved insulin sensitivity in the long term. Initially, a strong positive relationship may exist between "exercise" and "lower blood glucose." The individualized evolutionary process, based on the user's specific data, establishes a new, user-specific association between the "HIIT" node and the "short-term blood glucose increase" node, while simultaneously strengthening the relationship weight between "HIIT" and "long-term improvement in insulin sensitivity."

[0082] Algorithm Implementation: These adjustments can be implemented using various techniques. For example, Bayesian updates can be used, employing general knowledge as the prior probability and the user's continuous observation data as evidence to calculate the user-specific posterior probability, which is then used to update the relevant parameters in the graph. For adjusting relation weights, ideas from online learning or reinforcement learning can be borrowed, using user feedback (such as "This suggestion is very useful to me") as a reward signal to dynamically adjust the relation weights on the knowledge path that generated the suggestion.

[0083] Step S304: Record the evolutionary history and reasons

[0084] To ensure system transparency and traceability, every individualized evolutionary operation is meticulously recorded. The logs include snapshots of the graph before and after the evolution, specific data evidence triggering the evolution, the algorithms and parameters used, and the operation time. This facilitates auditing when needed, or allows for the rollback of personalized adjustments should a user's health condition undergo fundamental changes.

[0085] Step S305: Process ends

[0086] After completing the above steps, the user's knowledge subgraph is now more closely aligned with their individual circumstances. Subsequently, when the inference engine ( Figure 1 When processing the user's data again, F) will make inferences based on this evolved and more accurate subgraph, thereby avoiding false alarms or inappropriate suggestions caused by the inconsistency between the general model and individual differences.

[0087] Through this process, the present invention deeply personalizes the data and information layers of the DIKWP model. For the athlete user, the raw data "heart rate 52 bpm" is no longer incorrectly mapped to the generic message "warning: bradycardia," but is correctly understood as "the user's normal physiological baseline," which fully serves the user's purpose—to obtain truly meaningful health monitoring, rather than a distracting alarm.

[0088] Example 4: Detailed Explanation of New Knowledge Integration into Sub-processes

[0089] Reference Figure 4 This process describes how to safely and reliably integrate new general medical knowledge acquired from external sources into the existing semantic graph. The core of this process is the introduction of a "review-before-integration" mechanism to ensure the rigor and logical consistency of the knowledge system.

[0090] Step S401: Receive new knowledge data

[0091] The process begins with the data acquisition module ( Figure 1 (D) The system captures new public medical knowledge. This knowledge may be structured (such as an API update from a drug database) or unstructured (such as a PDF clinical research report). For example, the system retrieves a recent official guideline stating: "For patients with non-small cell lung cancer with specific gene mutations, the novel targeted drug Osimertinib is recommended as a first-line treatment."

[0092] Step S402: Knowledge Analysis and Formatting

[0093] New knowledge integration module ( Figure 1 K) first parses the raw data. If it is unstructured text, advanced natural language processing (NLP) techniques, including named entity recognition (NER) and relation extraction (RE), are used to convert it into a format that the graph can understand—a set of candidate nodes (entities) and relations (edges).

[0094] In the example above, the parsing result might be:

[0095] Candidate node 1: {Name: 'Osimertinib', Type: 'Drug'}

[0096] Candidate Node 2: {Name: 'Non-small cell lung cancer', Type: 'Disease', Attribute: 'Specific gene mutation'}

[0097] Candidate relation: {Head entity: 'Osimertinib', Relationship type: 'First-line recommended treatment', Tail entity: 'Non-small cell lung cancer'}

[0098] Step S403: Semantic Consistency Verification

[0099] This is the most crucial and innovative step in the process, serving as a "firewall" to ensure the security of medical AI. Before formally writing candidate knowledge into the graph, the system performs a rigorous verification procedure:

[0100] Logical conflict verification: The system compares candidate knowledge with a set of core medical axioms and rules stored in the Wisdom layer. These axioms are inviolable medical common sense. For example, suppose there is an axiom in the graph: "No treatment can conflict with a patient's known allergies or medications." If the new knowledge to be incorporated incorrectly recommends a drug containing sulfonamides to treat a disease, and sulfonamides are a common allergen, the verification system will detect a potential conflict. In implementation, this can be achieved using an ontology reasoner or a rule engine, such as Drools, for logical deduction and contradiction detection.

[0101] Ethical compliance verification: The system also performs checks based on a pre-defined set of ethical rules. For example, the rule set states: "Diagnostic or treatment recommendations must not be based on non-medically relevant discriminatory factors (such as race or region)." If research data to be integrated indicates that a certain therapy is more effective for a specific ethnic group, the system will ensure that this association is based on proven biological differences rather than simple statistical bias, and may add a "further verification required" label.

[0102] Data source credibility assessment: The system evaluates the authority of new knowledge sources. Guidelines from authoritative organizations such as the World Health Organization (WHO) and the U.S. Food and Drug Administration (FDA) have a much higher initial credibility weight than research papers from unknown journals.

[0103] Step S404: Conflict resolution decision

[0104] Based on the verification results, the system will make a decision:

[0105] Verification passed (S404-Yes): If the candidate knowledge does not conflict with any rules and the source is reliable, the process proceeds to the next step (S405).

[0106] Verification failed (S404-No): If a conflict or suspicious source is detected, the system will execute a preset conflict handling strategy. This may include:

[0107] Refuse to integrate: Simply discard this piece of knowledge.

[0108] Mark for review: Store this piece of knowledge in a queue that is "pending manual review" and send an alert to the system administrator.

[0109] Reduce weighting or add limiting conditions: If the conflict is not serious, the system may accept the knowledge, but reduce its relation weight, or add a context-limiting annotation node, such as: "This conclusion was only observed in the XX study and is yet to be validated in large-scale clinical trials".

[0110] Step S405: Perform incremental map update

[0111] After successful verification, the module performs a transactional database operation, formally writing the new nodes and relationships into the semantic graph database. This process preferably employs an incremental learning algorithm.14 Unlike fully retrained models, incremental learning can efficiently integrate new knowledge into the existing model without accessing all historical data, while maximizing the retention of learned old knowledge, effectively avoiding the "catastrophic forgetting" problem.16 This ensures that knowledge graph updates are efficient and stable.

[0112] Step S406: Process ends

[0113] Once the new knowledge is integrated, the entire knowledge graph reflects the latest medical advancements and can be immediately used by the inference engine to provide more cutting-edge and accurate services.

[0114] Example 5: Detailed Explanation of Performance-Driven Refactoring Subprocesses

[0115] Reference Figure 5 This process is the core mechanism by which the system achieves self-repair and continuous optimization in this invention. When the system's macroscopic performance encounters problems, it can delve into the microscopic structure of the knowledge graph and perform precise, "surgical" repairs.

[0116] Step S501: Receive performance alerts

[0117] The process begins with the performance monitoring module ( Figure 1 The H) detects that one or more key performance indicators (KPIs) are consistently below a preset health threshold and sends a notification to the monitoring module (H). Figure 1 (I) Issue an alert. For example, the alert content is: {Alert type: 'Performance decline', Indicator: 'Anxiety disorder diagnostic F1 score', Current value: '0.65', Threshold: '0.80', Time window: 'Last 30 days'}.

[0118] Step S502: Collect and analyze failure cases

[0119] Performance-driven refactoring module ( Figure 1 Once the L) is activated, the first step is to collect all failure cases related to the warning indicator within the specified time window. In the example above, the system will retrieve all cases that were misdiagnosed (missed or misdiagnosed) as anxiety disorder from the logs.

[0120] Step S503: Perform source tracing analysis

[0121] This is the technical challenge and core of the process. The module needs to trace the root cause from the surface phenomenon of "performance degradation" to the deeper "knowledge structure defects".

[0122] Reasoning Path Backtracking: For each failed case, the system backtracks its complete reasoning path in the knowledge graph. That is, from the input raw symptom data to the final erroneous conclusion, it traces which nodes the reasoning engine traversed and which relationships were activated.

[0123] Common Pattern Mining: The system aggregates and analyzes the reasoning paths of all failed cases to find common patterns. For example, the analysis found that more than 80% of misdiagnosed cases activated one path: "palpitations (symptom) -> coronary heart disease risk (knowledge)", while ignoring another equally important path: "palpitations (symptom) -> accompanied by recent major life stressor events (information) -> anxiety disorder (knowledge)".

[0124] Attribution analysis: By using graph algorithms and machine learning attribution techniques (such as gradient analysis and SHAP value analysis on graph neural networks), the system can quantitatively assess the magnitude of the “negative impact” contributed by each node and relationship in failed reasoning.

[0125] Locating the problem subgraph: Through the above analysis, the system can ultimately pinpoint the subgraph structure where the problem lies. In the example, the conclusion of the source analysis might be: "The direct association weight between the 'palpitation' node and the 'anxiety disorder' node is too low, and there is a lack of a critical path connecting the 'life stress event' information node, causing the model to overly favor organic heart disease in differential diagnosis."

[0126] Step S504: Generate and evaluate the refactoring strategy

[0127] Based on the conclusions of the source analysis, the module will automatically generate one or more map reconstruction strategies.

[0128] Strategy Generation: Based on the above conclusions, possible strategies include:

[0129] Add a relationship: Create a new, high-weight relationship edge between the "Life Stress Events" node and the "Anxiety Disorder" node.

[0130] Adjust weights: Significantly increase the weight of the existing relationship between the "palpitation" node and the "anxiety" node.

[0131] Deleting Relationships: If a relationship is found to be clearly misleading (e.g., an outdated or falsified theory), it is deleted.

[0132] Strategy Evaluation: Before being applied to the production graph, the system simulates and tests each strategy in a sandbox environment using a historical validation dataset. The system evaluates whether previously failed cases can be correctly diagnosed after applying the strategy, while ensuring that it does not negatively affect other correct diagnoses (i.e., regression testing).

[0133] Step S505: Perform atlas structure reconstruction

[0134] The system will select the reconstruction strategy with the best evaluation results and apply it to the main semantic graph database. This is an atomic, transactional operation to ensure data consistency.

[0135] Step S506: Verification and Curing

[0136] After the refactoring is complete, the performance monitoring module will continuously focus on the repaired performance metrics. If, after one or two monitoring cycles, the metric (such as the F1 score for anxiety diagnosis) significantly recovers and stabilizes above the threshold, the refactoring is considered successful, and the structural modifications are permanently implemented. If the results are unsatisfactory, the system may try suboptimal strategies or escalate the issue to human experts for intervention.

[0137] Step S507: Process ends

[0138] Through this closed-loop process of "monitoring-early warning-tracing-reconstruction-verification", the system of this invention has a strong self-evolution and error correction capability, ensuring its long-term accuracy and reliability in complex and ever-changing medical application scenarios.

[0139] In summary, this invention creatively solves a series of fundamental problems plaguing the field of medical AI by organically combining three mechanisms—individualized evolution, new knowledge integration, and performance-driven reconstruction—within a unified framework, providing a complete and novel technical solution for building a truly intelligent, reliable, and up-to-date proactive medical system.

Claims

1. A method for adaptive evolution and reconstruction of semantic graphs for proactive healthcare systems, applied to a computing device including a processor and a memory, wherein the memory stores a computer program, and the processor implements the method when executing the computer program, characterized in that... Includes the following steps: Continuously collect multimodal data from at least one data source, including individualized data for characterizing the health status of a specific individual and public medical knowledge data for characterizing general medical knowledge; monitor in real time a preset set of triggering conditions, including a first type of triggering condition, a second type of triggering condition and a third type of triggering condition; In response to the detection of the first type of triggering condition being met, a personalized knowledge evolution process is initiated. The first type of triggering condition is related to a specific pattern presented in the personalized data. The personalized knowledge evolution process is used to adjust the structure or parameters of the personalized subgraph associated with the specific individual in the semantic graph. In response to the detection of the second type of triggering condition being met, a new knowledge integration process is initiated. The second type of triggering condition is related to the receipt of new public medical knowledge data. The new knowledge integration process is used to integrate the new public medical knowledge data into the semantic graph. In response to the detection of the third type of triggering condition being met, a performance-driven reconstruction process is initiated. The third type of triggering condition is related to at least one performance evaluation index of the proactive healthcare system being lower than a preset threshold. The performance-driven reconstruction process is used to adjust the overall or partial topology of the semantic graph.

2. The method according to claim 1, characterized in that, The semantic graph is a multi-layered heterogeneous semantic network constructed based on the DIKWP model of data, information, knowledge, wisdom, and intention.

3. The method according to claim 1, characterized in that, The individualized knowledge evolution process specifically includes: based on the individualized data, identifying persistent physiological indicator baseline deviations or behavioral patterns that differ from the general group in a specific individual; locating nodes or relationships in the individualized subgraph that correspond to the physiological indicator baselines or behavioral patterns; and adjusting the parameters of the nodes or relationships, including but not limited to: modifying the normal range threshold of the physiological indicators, adjusting node weights, or changing the relationship strength.

4. The method according to claim 1, characterized in that, The new knowledge integration process specifically includes: parsing the new public medical knowledge data into a set of candidate nodes and candidate relationships; before adding the candidate nodes and candidate relationships to the semantic graph, performing a semantic consistency verification step, which is used to verify whether the candidate nodes and candidate relationships conflict with the preset medical axioms or ethical rule sets in the semantic graph; and solidifying the candidate nodes and candidate relationships into the semantic graph if and only if the semantic consistency verification passes.

5. The method according to claim 1, characterized in that, The performance-driven refactoring process specifically includes: when the at least one performance evaluation metric is lower than the preset threshold, collecting a set of erroneous reasoning cases that lead to performance degradation; performing source analysis on the set of erroneous reasoning cases to locate one or more problem subgraph structures in the semantic graph that lead to erroneous reasoning; and performing at least one structural optimization operation on the problem subgraph structure, wherein the structural optimization operation is selected from: adding missing nodes or relations, deleting erroneous nodes or relations, and adjusting the weights of existing nodes or relations.

6. The method according to claim 5, characterized in that, The performance evaluation metrics include at least one of diagnostic accuracy, prediction precision, recall, F1 score, or entropy reduction efficiency.

7. The method according to any one of claims 1 to 6, characterized in that, The individualized knowledge evolution process, the new knowledge integration process, and the performance-driven reconstruction process all employ incremental learning algorithms to update the semantic graph, so as to retain existing knowledge while integrating new information and avoid catastrophic forgetting.

8. A system for semantic graph adaptive evolution and reconstruction in an active healthcare system, comprising a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to implement the system, characterized in that, The system includes: a data acquisition module configured to continuously acquire multimodal data from at least one data source, the multimodal data including personalized data and public medical knowledge data; a trigger monitoring module configured to monitor in real time a preset set of trigger conditions, the set of trigger conditions including a first type of trigger condition related to the personalized data, a second type of trigger condition related to the public medical knowledge data, and a third type of trigger condition related to system performance evaluation indicators; a personalized evolution module configured to be activated when the trigger monitoring module detects that the first type of trigger condition is met, to adjust the personalized subgraph associated with a specific individual in the semantic graph; a new knowledge integration module configured to be activated when the trigger monitoring module detects that the second type of trigger condition is met, to integrate new public medical knowledge data into the semantic graph; and a performance-driven reconstruction module configured to be activated when the trigger monitoring module detects that the third type of trigger condition is met, to adjust the topology of the semantic graph.

9. The system according to claim 8, characterized in that, The new knowledge integration module includes a semantic consistency verification submodule, which is configured to verify whether the knowledge to be integrated conflicts with the preset medical axioms or ethical rule sets in the semantic graph during the main process of new knowledge integration.

10. The system according to claim 8, characterized in that, The performance-driven refactoring module includes a source analysis submodule, which is configured to locate the problematic subgraph structure in the semantic graph that causes performance degradation by analyzing erroneous reasoning cases in the main process of performance-driven refactoring.

Images