Medication guidance system and method based on knowledge graph and vector retrieval fusion

Abstract

The application provides a medication guidance system and method based on knowledge graph and vector retrieval fusion, and relates to the technical field of artificial intelligence, comprising an application access layer, a service interface layer and a hybrid retrieval engine layer; the application access layer is used for receiving external demand information and transmitting the external demand information to a large model platform; the service interface layer is used for receiving a query instruction of the large model platform, transmitting the query instruction to the hybrid retrieval engine layer, and transmitting a retrieval result to the large model platform, so that the large model platform outputs the retrieval result; the hybrid retrieval engine layer is used for generating a graph database query statement and a query semantic vector according to the query instruction, performing a structured query on a graph database according to the graph database query statement, and performing semantic similarity retrieval on a vector database based on the query semantic vector, and generating a graph retrieval result and a vector retrieval result for the large model platform. Through the above medication guidance system, professional medication guidance can be realized.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a medication guidance system and method based on the fusion of knowledge graph and vector retrieval. Background Technology

[0002] In modern medical practice, accurate medication guidance and safe medication consultation are crucial for developing personalized treatment plans and improving the quality of medical care. With the development of medical technology and the increasing variety of drugs, drug labels have become the primary means for medical institutions to manage and utilize drug information. Drug labels contain a wealth of drug data, such as indications, dosage, drug interactions, contraindications, and adverse reactions. This data provides valuable information resources for predicting safe drug use. However, extracting valuable information from this vast and complex dataset and transforming it into knowledge helpful for clinical decision-making remains a significant challenge.

[0003] In recent years, with the rapid development of Natural Language Processing (NLP) technology and deep learning, methods based on large-scale language models have been increasingly applied to the medical field to uncover the potential value in drug instructions. Large-scale language models, through their powerful representation capabilities, can understand and generate medically relevant text content, providing a new approach for automated drug use guidance. However, traditional text retrieval methods struggle to handle complex drug association queries and multi-drug interaction analysis, limiting their deployment in real-world medical environments. Summary of the Invention

[0004] In view of this, this application proposes a medication guidance system and method based on the fusion of knowledge graph and vector retrieval.

[0005] In the first aspect, this application provides a medication guidance system based on the fusion of knowledge graph and vector retrieval, including: an application access layer, a service interface layer, and a hybrid retrieval engine layer;

[0006] The application access layer is used to receive external demand information and transmit the external demand information to the large model platform;

[0007] The service interface layer provides a unified tool interface based on the interface protocol, which is used to receive query instructions from the large model platform, transmit the query instructions to the hybrid retrieval engine layer, receive the retrieval results from the hybrid retrieval engine layer, and transmit the retrieval results to the large model platform so that the large model platform can output the retrieval results.

[0008] The hybrid retrieval engine layer is used to generate graph database query statements and query semantic vectors according to the query instructions, perform structured queries on the graph database according to the graph database query statements, and perform semantic similarity retrieval on the vector database based on the query semantic vectors, generating graph retrieval results and vector retrieval results for the large model platform.

[0009] In one embodiment, the medication guidance system based on the fusion of knowledge graph and vector retrieval further includes: a data preprocessing layer and a data processing layer;

[0010] The data preprocessing layer is used to preprocess the pharmaceutical material documents to generate structured data in the target format;

[0011] The data processing layer is used to receive structured data in the target format, and to perform block processing on the structured data in the target format. The block-processed document fragments are converted into semantic vector representations and embedded into the vector database, and converted into standard triples and embedded into the graph database.

[0012] In one embodiment, the data preprocessing layer includes: a document processing module and an intelligent chunking module;

[0013] The document processing module is used to extract data from the drug material file, and sequentially perform data cleaning, unified encoding format processing, and conversion of fields at predetermined positions in the drug material file into predefined standard fields based on a standard field mapping mechanism, and convert the obtained data into structured data in the target format.

[0014] The intelligent segmentation module is used to perform overlapping segmentation processing on the structured data of the target format based on preset overlap parameters, and to segment array type fields in document fragments one by one according to the standard delimiters in medical literature, thereby decomposing complex medical concepts into independent semantic units.

[0015] In one embodiment, the data processing layer includes: a medical data augmentation module, a knowledge graph construction module, and a vector encoding module;

[0016] The medical data augmentation module is used to receive document fragments output by the data preprocessing layer, and automatically identify and normalize the variant names of the document fragments based on a standardized mapping dictionary to obtain medical augmented document fragments.

[0017] The knowledge graph construction module is used to add structured tags to each medical augmented document fragment, identify medical entities and relation types based on pharmaceutical domain knowledge, construct standard triples and embed them into the graph database;

[0018] The vector encoding module is used to perform semantic vectorization processing on the medical augmented document fragment using a pre-trained semantic embedding model to obtain a semantic vector representation, and then embeds the semantic vector representation into the vector database.

[0019] In one embodiment, the hybrid retrieval engine layer includes: a graph query engine and a vector query engine;

[0020] The graph query engine is used to convert the query command into a graph database query statement using an embedded statement conversion model, perform a structured query on the graph database according to the graph database query statement, perform a structured conversion of the query results into a target format, and obtain the graph retrieval results.

[0021] The vector query engine is used to convert the query instruction into a query semantic vector using a vectorization model, perform semantic similarity retrieval in a vector database based on the query semantic vector, filter the semantic retrieval results, and perform a structured conversion of the filtered results into a target format to obtain the vector retrieval results.

[0022] In one embodiment, the vector query engine includes: a retrieval module and a reordering module;

[0023] The retrieval module is used to convert the query instruction into a query semantic vector using a vectorization model, calculate the cosine similarity between the query semantic vector and the document vectors in the vector database, and return the top-k documents with the highest similarity based on the retrieval data threshold to obtain preliminary screening results.

[0024] The reordering module is used to input the query semantic vector into the reordering model, score the semantic relevance of each document unit in the preliminary screening results, and reorder the preliminary screening results based on the scoring results to obtain the final screening results.

[0025] Secondly, this application provides a medication guidance method based on the fusion of knowledge graph and vector retrieval, wherein the medication guidance method is executed based on the medication guidance system described in the first aspect; the medication guidance method includes:

[0026] Receive external demand information and transmit the external demand information to the large model platform;

[0027] Receive the query instruction from the large model platform, and generate a graph database query statement and a query semantic vector based on the query instruction;

[0028] The graph database is structured according to the graph database query statement, and semantic similarity is performed in the vector database based on the query semantic vector. Graph retrieval results and vector retrieval results are generated and sent to the large model platform so that the large model platform can output the retrieval results.

[0029] In one embodiment, before receiving external demand information, the method further includes:

[0030] Obtain the drug material files and preprocess them to generate structured data in the target format;

[0031] The structured data in the target format is segmented, and the segmented document fragments are converted into semantic vector representations and embedded into the vector database, and converted into standard triples and embedded into the graph database.

[0032] Thirdly, this application provides an electronic device, including a processor and a memory; the memory stores a computer program, wherein the computer program, when executed by the processor, implements the medication guidance method based on the fusion of knowledge graph and vector retrieval as described in the second aspect.

[0033] Fourthly, this application provides a computer storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the medication guidance method based on the fusion of knowledge graph and vector retrieval as described in the second aspect.

[0034] The medication guidance system that integrates knowledge graph and vector retrieval proposed in this application has the following advantages over related technologies:

[0035] 1. This medication guidance system, based on the fusion of knowledge graph and vector retrieval, efficiently receives external requests and accurately transmits them to the large model platform through the application access layer, ensuring the timeliness and accuracy of request transmission. The service interface layer, relying on standardized interaction logic, receives query commands from the large model platform and links with the hybrid retrieval engine layer, supporting flexible interaction modes and achieving efficient bidirectional transmission of search results, providing stable support for the output results of the large model. The hybrid retrieval engine layer generates graph database query statements and query semantic vectors, respectively realizing structured queries on the graph database and semantic similarity retrieval on the vector database. Precise retrieval is achieved through graph database query statements, supporting complex logical reasoning and relation traversal, suitable for complex drug interaction query scenarios. Furthermore, the semantic matching capability of vector retrieval can handle fuzzy queries and concept associations. A separate result return strategy is adopted to maintain the independence and integrity of different retrieval types, avoiding information loss caused by mixing different types of results, providing a more flexible result selection mechanism for upper-layer applications, reducing the limitations of a single retrieval method while maintaining high accuracy.

[0036] 2. By leveraging the complementary advantages of the two retrieval methods, the large model platform can ultimately obtain comprehensive and accurate spectral retrieval results and vector retrieval results, thereby efficiently outputting reliable drug interaction analysis, medication safety assessment, and personalized medication recommendations. This not only enhances the professionalism, safety, and personalization of medication guidance but also strengthens the system's adaptability and flexibility, meeting the medication guidance needs in different scenarios. Attached Figure Description

[0037] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 This is a schematic diagram of the structure of a medication guidance system that integrates knowledge graph and vector retrieval in one embodiment of this application;

[0039] Figure 2 This is a schematic diagram of the structure of a medication guidance system that integrates knowledge graph and vector retrieval in another embodiment of this application;

[0040] Figure 3 This is a schematic diagram illustrating the process of constructing a knowledge graph and vector index in one embodiment of this application;

[0041] Figure 4 This is a schematic diagram of the vector index construction process based on the RAG system in one embodiment of this application;

[0042] Figure 5 This is a schematic diagram illustrating the design of entity relationships in a drug knowledge graph according to one embodiment of this application;

[0043] Figure 6 This is a schematic diagram of the internal architecture of the hybrid retrieval engine layer in one embodiment of this application;

[0044] Figure 7 This is a flowchart illustrating a medication guidance method that integrates knowledge graphs and vector retrieval in one embodiment of this application.

[0045] Figure 8 This is a schematic diagram of the internal structure of an electronic device according to an embodiment of this application.

[0046] Explanation of reference numerals in the attached figures:

[0047] 1-Application Access Layer, 2-Service Interface Layer, 3-Hybrid Retrieval Engine Layer, 31-Graph Query Engine, 32-Vector Query Engine, 4-Data Preprocessing Layer, 41-Document Processing Module, 42-Intelligent Blocking Module, 5-Data Processing Layer, 51-Medical Data Enhancement Module, 52-Knowledge Graph Construction Module, 53-Vector Encoding Module. Detailed Implementation

[0048] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0049] In some embodiments, such as Figure 1 As shown, this application provides a medication guidance system based on the fusion of knowledge graph and vector retrieval, comprising: an application access layer 1, a service interface layer 2, and a hybrid retrieval engine layer 3.

[0050] Application access layer 1 is used to receive external demand information and transmit it to the large model platform. The external demand information can be a query language entered by the user.

[0051] Application access layer 1 can adopt a multi-protocol support design, for example, providing both HTTP RESTful API and standard MCP protocol access methods. The HTTP API interface supports direct system integration and development debugging, providing complete drug knowledge retrieval functions; the MCP protocol server implements a standardized model context interface based on the FastMCP framework, supporting tool call integration with large model platforms. This protocol has good cross-platform compatibility and can seamlessly interface with mainstream large model platforms such as Dify and LangChain, realizing natural language dialogue and intelligent question answering services through the Function Calling mechanism. The dual-protocol architecture meets diverse application needs from direct API calls to intelligent dialogue assistants. A standardized MCP server built on the FastMCP framework achieves seamless integration with large model platforms.

[0052] For example, the MCP server configuration includes server initialization, utility function definition, and transport protocol settings. The core utility function is defined as the `search` utility, which receives `QueryRequest` parameters, including structured parameters such as `query` (query text), `disease_names` (a list of disease names), and `drug_count` (the number of drugs). The MCP server uses the standard HTTP transport protocol and supports the Function Calling mechanism to implement structured utility calls. The large model platform acts as an MCP client, calling the `search` utility function through the standard MCP protocol. Request processing supports multiple query modes: single drug queries, multi-drug interaction queries, and complex medical query scenarios such as disease treatment drug recommendations. Response processing supports streaming output mode; the system achieves streaming responses through SSE (Server-Sent Events), with an average response time controlled at around ten seconds. The standardized interface design of the MCP protocol ensures the system's cross-platform compatibility, thus supporting seamless integration with mainstream large model platforms such as Dify and LangChain.

[0053] Service Interface Layer 2 provides a unified tool interface based on an interface protocol. This interface receives query commands from the large model platform and transmits them to the hybrid retrieval engine layer 3. It also receives the retrieval results from the hybrid retrieval engine layer 3 and transmits these results back to the large model platform, enabling the platform to output the search results. It should be noted that the interface protocol can be the MCP protocol.

[0054] Service Interface Layer 2, serving as the core of the system's business logic, integrates four key components to work collaboratively. The MCP server, based on the FastMCP framework, implements standard protocol specifications and handles tool calls from the large model platform; the FastAPI backend runs on port 8080, providing a complete RESTful API service; and the diagnostic controller encapsulates medical auxiliary diagnosis functions. This Service Interface Layer 2 implements a design pattern that supports multiple protocols and separates business logic.

[0055] The hybrid retrieval engine layer 3 generates graph database query statements and query semantic vectors based on query instructions. It then performs structured queries on the graph database using the graph database query statements and performs semantic similarity retrieval on the vector database based on the query semantic vectors, generating graph retrieval results and vector retrieval results for the large model platform. It should be noted that the graph database can be the Neo4j graph database, and the corresponding graph database query statement can be a Cypher query statement. The vector database can be the Qdrant vector database.

[0056] It is understandable that graph database queries are used to perform precise structured searches on graph databases storing structured knowledge, while semantic similarity-based association searches are performed in vector databases using query semantic vectors. Finally, the graph retrieval results and vector retrieval results obtained from both processes are integrated and synchronously transmitted to the large model platform, providing comprehensive data support for subsequent medication guidance analysis and recommendations. By allowing the advantages of the two retrieval methods to complement each other, the large model platform can obtain comprehensive and accurate graph retrieval results and vector retrieval results, thereby efficiently outputting reliable drug interaction analysis, medication safety assessment, and personalized medication recommendations. This improves the professionalism, safety, and personalization of medication guidance, while also enhancing the system's adaptability and flexibility, meeting the medication guidance needs of different scenarios.

[0057] In application, logical reasoning queries can prioritize the use of graph databases, semantic fuzzy queries rely primarily on vector retrieval, and comprehensive queries are executed in parallel with intelligent result fusion. This dual-path process achieves diversified knowledge representation and complementary retrieval capabilities, providing the system with an intelligent retrieval foundation that possesses both logical reasoning and semantic understanding.

[0058] The aforementioned medication guidance system, based on the fusion of knowledge graph and vector retrieval, efficiently receives external requests and accurately transmits them to the large model platform through the application access layer 1, ensuring the timeliness and accuracy of request transmission. The service interface layer 2, relying on standardized interaction logic, receives query commands from the large model platform and links with the hybrid retrieval engine layer 3, supporting flexible interaction modes and achieving efficient bidirectional transmission of search results, providing stable support for the output results of the large model. The hybrid retrieval engine layer 3 generates graph database query statements and query semantic vectors, respectively enabling structured queries on the graph database and semantic similarity retrieval on the vector database. Precise retrieval is achieved through graph database query statements, supporting complex logical reasoning and relation traversal, suitable for complex drug interaction query scenarios. Furthermore, the semantic matching capability of vector retrieval can handle fuzzy queries and concept associations. A separate result return strategy maintains the independence and integrity of different search types, avoiding information loss caused by mixing different types of results, providing a more flexible result selection mechanism for upper-layer applications, reducing the limitations of a single search method while maintaining high accuracy.

[0059] In some embodiments, such as Figure 2 As shown, the medication guidance system based on the fusion of knowledge graph and vector retrieval also includes: data preprocessing layer 4 and data processing layer 5.

[0060] Data preprocessing layer 4 is used to preprocess drug material documents to generate structured data in the target format.

[0061] The data processing layer 5 is used to receive structured data in the target format, and to perform block processing on the structured data in the target format. The block-processed document fragments are converted into semantic vector representations and embedded into the vector database, and converted into standard triples and embedded into the graph database.

[0062] The drug material files can be Excel data text files. The target format can be JSON. Data preprocessing layer 4 can transform the raw data from the drug material files into structured knowledge. Data processing layer 5 undertakes the most critical computational tasks of the system, realizing semantic vector generation and standard triple transformation.

[0063] In the application, data preprocessing layer 4 can extract structured data from multiple Excel files containing drug instruction manuals, which include 25 standard fields such as drug name, indications, dosage, contraindications, and adverse reactions. The data preprocessing module uses the pandas library to parse the Excel files, read drug records row by row, and perform data type checks and format standardization on each field. A forward imputation strategy is used for missing values, and duplicate records are deduplicated using the drug approval number. Data processing layer 5 employs a segmentation strategy that can use different processing methods based on field characteristics. For example, it can use a sliding window combined with line-by-line segmentation. The sliding window segmentation is specifically for long text fields such as dosage and adverse reactions, while line-by-line segmentation is for array fields such as indications and related diseases.

[0064] The process of constructing knowledge graphs and vector indexes can be as follows: Figure 3As shown, the knowledge graph can be constructed as follows: The drug knowledge graph extractor automatically identifies 18 entity types and 17 relation types through rule matching and regular expression technology. Entity types include Drug, Disease, Ingredient, Indication, Adverse Reaction, Dosage, Contraindication, Precaution, Specification, Manufacturer, URL, Pregnancy Use, Children Use, Elderly Use, Drug Interaction, Pharmacology, Pharmacokinetics, and Storage. The relation extraction algorithm includes 17 relation types: Treatment relations (TREATS) connect drug entities and disease entities, representing a treatment relationship; Ingredient inclusion relations (CONTAINS) connect drug entities and ingredient entities, representing an ingredient inclusion relationship; Manufacturing relations (MANUFACTURED_BY) connect drug entities and manufacturer entities; Adverse reaction relations (CAUSES_ADVERSE_REACTION) connect drug entities and adverse reaction entities, etc. The relation triple construction process converts the identified entities and relations into a standard triple format. Each triple contains three fields: source entity identifier (source_id), relation type (relationship_type), and target entity identifier (target_id). The entity identifier generation strategy adopts a hybrid mode: for entities with unique identifier fields (such as drug name, manufacturer name), the identifier is generated using the format "entity type:field value"; for entities without explicit identifiers, a random unique identifier is generated using a universally unique identifier (UUID) to ensure entity uniqueness and consistency.

[0065] The process of constructing a vector index can be as follows: The processed document fragments are vectorized using a Chinese semantic embedding model. The M3E-Large model, based on the BERT architecture, supports a maximum input length of 512 tokens and outputs a 1024-dimensional dense vector representation. GPU acceleration enables efficient semantic vector generation. An efficient vector index structure can be constructed using the HNSW (Hierarchical Navigable Small World) algorithm. For example, the parameters are configured as M=24 (maximum number of connections), ef_construct=150 (search parameters during construction), and ef_search=200 (search parameters during query). The Qdrant vector database storage configuration can include set creation, vector insertion, and metadata management. The set parameters are set as vector_size=1024 and distance=Cosine, ultimately storing 390,592 1024-dimensional vectors, supporting high-concurrency cosine similarity queries. For application details, the vector index construction process based on the RAG system can be found in [reference needed]. Figure 4 Semantic vector indexes are constructed using the RAG system.

[0066] In some embodiments, the data preprocessing layer 4 includes a document processing module 41 and an intelligent chunking module 42.

[0067] The document processing module 41 is used to extract data from the drug material documents, and sequentially perform data cleaning, unified encoding format processing, and conversion of fields at predetermined positions in the drug material documents into predefined standard fields based on a standard field mapping mechanism, and convert the obtained data into structured data in the target format.

[0068] The intelligent segmentation module 42 is used to perform overlapping segmentation processing on the structured data of the target format based on preset overlap parameters, and to segment array type fields in document fragments one by one according to the standard delimiters in medical literature, thus decomposing complex medical concepts into independent semantic units.

[0069] In the data preprocessing stage, taking Excel data as an example, the system first performs three steps of standardization on the original Excel data. The data extraction and cleaning stage uses the pandas library to automatically parse the Excel file, removing invalid content such as special characters and standardizing the encoding format. The field standardization stage establishes a mapping mechanism for 25 standard fields, uniformly converting different Excel column names into system standard fields. The format conversion stage converts the processed data into structured data in the target format, such as structured JSON, providing standard input for subsequent block processing.

[0070] Chunking processing implements differentiated strategies based on the characteristics of medical text. Sliding window chunking is specifically designed for long text fields such as dosage, administration, and adverse reactions. It allows setting a chunk size of 512 characters, an overlap area of ​​128 characters, and an overlap rate of 25%, ensuring semantic integrity through overlapping chunking. For example, for a 1000-character text on dosage, "Oral administration. Adults: 0.5g once every 6-8 hours, daily dose not exceeding 4g. Children: daily dose 20-40mg / kg, every 8 hours...", the first 512 characters are extracted as the first chunk, and then a second 512-character chunk is extracted starting from the 384th character position, ensuring a 128-character overlap between adjacent chunks and preventing critical medication information such as "daily dose not exceeding 4g" from being truncated by chunk boundaries. Specifically, optimal semantic segmentation can be achieved based on the structural characteristics of medical text. The sliding window chunking technique handles long text fields, and the chunk size, overlap area, and overlap rate can be configured according to the actual text characteristics. The formula for calculating the overlap rate is:

[0071]

[0072] This strategy ensures sufficient semantic continuity between adjacent text blocks, preventing important medical information from being truncated at block boundaries.

[0073] The system intelligently segments array fields such as indications and related diseases using medical delimiters (commas, semicolons, and pauses) to break down complex information into independent semantic units, improving search accuracy. Specifically, for the indication field "hypertension, angina pectoris, myocardial infarction, heart failure," the system automatically identifies the comma delimiter and splits it into four independent semantic units: "hypertension," "angina pectoris," "myocardial infarction," and "heart failure." Each disease name is indexed as an independent knowledge fragment. When a user searches for "medications for treating angina pectoris," the system can accurately match the semantic unit "angina pectoris," improving search accuracy.

[0074] In some embodiments, the data processing layer 5 includes: a medical data enhancement module 51, a knowledge graph construction module 52, and a vector encoding module 53.

[0075] The medical data augmentation module 51 is used to receive document fragments output by the data preprocessing layer 4, and automatically identify and normalize the variant names of the document fragments based on a standardized mapping dictionary to obtain medical augmented document fragments.

[0076] The knowledge graph construction module 52 is used to add structured tags to each medical augmented document fragment, identify medical entities and relation types based on pharmaceutical domain knowledge, construct standard triples and embed them into the graph database.

[0077] The vector encoding module 53 is used to perform semantic vectorization processing on medical augmented document fragments using a pre-trained semantic embedding model to obtain semantic vector representations, and then embeds the semantic vector representations into the vector database.

[0078] The medical data augmentation module 51 can maintain a standardized mapping dictionary of drug entities through the entity linking layer. Based on the standardized mapping dictionary, a sequence matching algorithm is used to automatically identify and standardize variant names. Similarity is calculated as follows:

[0079]

[0080] In the formula, s1 and s2 are the two strings to be compared (e.g., "hypertension" and "hypertension"); matches is the number of matching characters in the two strings, calculated using the longest common subsequence algorithm; len(s1) is the length of string s1 in characters; len(s2) is the length of string s2 in characters; similarity is the similarity score, ranging from [0, 1], where 1 indicates a perfect match and 0 indicates a complete mismatch. For example, when calculating the similarity between "hypertension" (length 4) and "hypertension" (length 3), the number of matching characters matches = 3 (the three characters "hypertension" are perfectly matched), so the similarity = 2.0 × 3 / (4 + 3) = 6 / 7 ≈ 0.857. When the similarity exceeds a preset threshold (default is 0.7) and the co-occurrence frequency reaches a certain number of times, the system automatically identifies highly similar term pairs as variant relationships and expands the term mapping dictionary.

[0081] By establishing rules for processing medical synonyms, medical concepts expressed in different ways can be unified, including the mapping between generic and brand names of drugs, the standardization of disease names, and the full expansion of medical abbreviations. The knowledge graph construction module 52 adds structured tags to each processed document fragment, including key information such as the source field identifier (section), drug approval number (approval_number), chunk unique identifier (chunk_id), entity type (entity_type), relation type (relation_type), and standardized drug name (standardized_drug_name), thereby supporting subsequent accurate retrieval and result traceability verification.

[0082] The entity relationship graph of the drug knowledge graph constructed by knowledge graph construction module 52 can be like this: Figure 5 As shown, Figure 5In this context, the Drug entity serves as the central node, connected to 17 other specialized entity types through 17 semantic relationships. The entity types are divided into six specialized areas according to function: the Disease Treatment Area contains the Disease entity, which establishes the drug-disease treatment association through the TREATS relationship; the Basic Information Area integrates core drug attribute entities such as Indication, Dosage, Specification, Manufacturer, and URL; the Ingredient Manufacturing Area handles the CONTAINS of the Ingredient entity; the Safety Information Area manages safety-related entities such as Adverse Reaction, Contraindication, and Precaution; the Special Population Area covers specific medication guidance for Pregnancy Use, Children Use, and Elderly Use; and the Pharmaceutical Information Area integrates professional pharmaceutical knowledge such as Drug Interaction, Pharmacology, Pharmacokinetics, and Storage.

[0083] The mathematical model for constructing a triplet is as follows:

[0084]

[0085] Where s∈E (subject entity), p∈R (predicate relation), o∈E (object entity); entity set E={Drug,Disease,Ingredient,...} (18 types).

[0086] The relation set R = {TREATS, CONTAINS, HAS_INDICATION, ...} (17 types).

[0087] Knowledge graph construction module 52 ensures entity uniqueness through a hybrid ID generation strategy. The entity ID generation algorithm is as follows:

[0088]

[0089] For example, (Aspirin, TREATS, Cardiovascular Disease) represents the knowledge relationship of aspirin treating cardiovascular disease. A hybrid ID generation strategy ensures entity uniqueness: for entities with unique identifier fields (such as drug names or manufacturer names), IDs are generated using the format "entity type:field value"; for entities without explicit identifiers, random unique IDs are generated using UUIDs.

[0090] A multi-layered entity recognition and relationship construction process was implemented through entity relationship extraction technology. The drug entity serves as the central node, and the knowledge graph construction module 52 sequentially processes 17 types of associated entities, each using a dedicated processing function for precise extraction. For complex ingredient information, the system employs regular expressions for structured extraction. The extraction of the main ingredient uses text pattern matching technology, identifying the content following the marker "The main ingredient is..." up to the period. For example, from the text "The main ingredient is amoxicillin. Excipients: starch, dextrin.", "amoxicillin" is extracted as the main ingredient, and an ingredient entity (Ingredient) is created for it, marked with the attribute is_active=True (active ingredient), establishing a containment relationship (CONTAINS) with the drug entity. Excipient extraction uses text pattern matching technology to identify the content following the "excipient:" or "excipient:" marker up to the period. For example, extracting "starch, dextrin" from the above text, and then splitting it into independent excipient names "starch" and "dextrin" according to commas, pauses, and other delimiters, creating component entities for each, marking the attribute is_active=False (inactive ingredient), and establishing an inclusion relationship with the drug entity to ensure the completeness and accuracy of component information.

[0091] The knowledge graph construction module 52 avoids the duplication of identical entities through entity ID checks, achieving entity deduplication and consistency guarantees, and establishing a robust entity management mechanism. For each new entity, the system first checks if the same entity ID already exists. If it does, it directly returns a reference to the existing entity; otherwise, it creates a new entity and adds it to the entity database. The relationship creation process employs strict type checking to ensure that the subject and object entity types of each relationship conform to the predefined graph pattern constraints, guaranteeing the structural consistency and semantic correctness of the knowledge graph.

[0092] This embodiment utilizes the Neo4j graph database to store the knowledge graph. Neo4j supports efficient graph querying and relational reasoning, and its batch import strategy improves the processing efficiency of large-scale data. A transaction mechanism ensures data integrity. Graph querying supports complex multi-drug relational reasoning; the system predefines multi-drug query templates, supporting complex medical query scenarios such as drug interactions and incompatibilities. The Cypher query language enables flexible graph traversal and pattern matching, providing rich knowledge retrieval capabilities for upper-layer applications.

[0093] Based on the aforementioned embodiments, users can describe their query needs using natural language, and the system automatically parses and generates corresponding graph database query statements, significantly improving the usability of the knowledge graph and the user experience. This knowledge graph design, through a star topology and partitioning, achieves a systematic representation and efficient querying of drug knowledge. By deeply integrating medical expertise with graph database technology and fully covering 18 entity types and 17 relation types, a specialized knowledge network encompassing the entire drug lifecycle is constructed, providing accurate and comprehensive knowledge support for intelligent medication guidance.

[0094] The vector encoding module 53 employs a Chinese semantic embedding model, specifically designed for semantic vectorization of Chinese medical text. In a specific embodiment, the M3E-Large pre-trained model can be used. The model parameters are configured as follows: output dimension 1024, input sequence maximum length 512 tokens. The vector encoding process is represented as follows:

[0095]

[0096] Where v is the generated vector representation; M3E_encode is the encoding function of the Chinese semantic embedding model, which is responsible for converting the input text into a numerical vector representation. When using the M3E-Large model, the M3E_encode function is used, and when using other Chinese semantic embedding models (such as BGE-Large-zh, Text2Vec-Large), the encoding function of the corresponding model (such as BGE_encode, Text2Vec_encode, etc.) is used; enhanced_text is the text content after medical data augmentation processing, which includes information such as drug name, field identifier and specific content.

[0097] Considering the stability requirements of large-scale data processing, the vector encoding module 53 can also establish a breakpoint resumption mechanism. The processing progress is calculated using the following formula:

[0098] Progress percentage:

[0099]

[0100] In the formula: P is the current processing progress percentage; processed_batches is the number of batches that have been processed; total_batches is the total number of batches.

[0101] Remaining processing time:

[0102]

[0103] In the formula: remaininging is the estimated remaining processing time; total_batches is the total number of batches; processed_batches is the number of batches that have been processed; avg_batch_time is the average processing time per batch, in seconds or minutes.

[0104] The system automatically saves processing checkpoints, records a list of completed document IDs and processing parameters, and supports resumption of processing at any interruption point, ensuring the reliability and efficiency of large-scale data processing.

[0105] In this embodiment, the medical data augmentation module 51 receives document fragments output from the data preprocessing layer 4. Based on a standardized mapping dictionary, it automatically identifies and standardizes variant names of the document fragments to obtain medical augmented document fragments, thereby achieving specialized processing such as terminology standardization and metadata optimization. Furthermore, a dual-path parallel design is adopted to fully leverage the advantages of structured knowledge and semantic retrieval. The knowledge graph construction path uses entity relation extraction technology to automatically identify medical entities and relation types based on the pharmaceutical domain ontology model, constructs standardized triplet knowledge representations, and imports them into the Neo4j graph database to form a structured knowledge network, supporting complex logical reasoning and multi-hop relation queries. The vector encoding module 53 can adopt a RAG construction path, converting the augmented document fragments into high-quality semantic vectors through M3E vector encoding; or it can use the LlamaIndex framework, which provides a unified RAG interface, to construct vector indexes and store them in the Qdrant database, forming a retrieval foundation with semantic understanding capabilities.

[0106] In some embodiments, the hybrid retrieval engine layer 3 includes a graph query engine 31 and a vector query engine 32.

[0107] The graph query engine 31 is used to convert query instructions into graph database query statements using an embedded statement conversion model, perform structured queries on the graph database based on the graph database query statements, and perform structured conversion of the query results into the target format to obtain graph retrieval results.

[0108] The vector query engine 32 is used to convert query instructions into query semantic vectors using a vectorization model, perform semantic similarity retrieval in the vector database based on the query semantic vectors, filter the semantic retrieval results, and perform a structured transformation of the filtered results into the target format to obtain vector retrieval results.

[0109] The target format can be standard JSON.

[0110] In applications, such as Figure 6As shown, the hybrid retrieval engine layer 3 can be implemented based on the LlamaIndex framework, integrating the two core components, KnowledgeGraphQueryEngine and VectorStoreIndex. The graph query engine 31 connects to the Neo4j graph database and generates Cypher query statements through a large language model.

[0111] The query processing flow can be as follows: After receiving the user's natural language query, a custom Cypher prompt template is used to guide the large language model in generating the corresponding Cypher query statement. The prompt template contains complete graph pattern information, including detailed descriptions of 18 entity types and 17 relation types. For multi-drug query scenarios, the system predefines a dedicated query template to handle complex drug interaction analysis. The multi-drug query template contains parameterized Cypher query statements, supports passing in the `drug_names` array and `drug_count` parameters, and automatically generates Cypher statements for batch drug queries. When a multi-drug query requirement is detected, it automatically constructs structured query parameters in JSON format, supporting complex drug combination analysis and interaction retrieval. The vector query engine 32 can be implemented based on LlamaIndex's VectorStoreIndex and VectorIndexRetriever to achieve semantic similarity retrieval and result filtering. The hybrid retrieval engine layer 3 adopts a separate parallel architecture, simultaneously executing graph structured queries and vector semantic retrieval. The system returns a data structure containing two independent result sets: "graph_results" and "vector_results". This maintains the independence of results for different search types, avoids information loss caused by weighted fusion, and provides a flexible result selection mechanism for upper-layer applications to choose the appropriate result based on specific scenarios.

[0112] It should be noted that the LlamaIndex framework, as the technical foundation of the RAG system, provides a unified vector storage and retrieval interface. The framework integrates core functional modules such as document index building, metadata management, and query processing, supporting seamless integration with various vector database backends. The system achieves unified access to heterogeneous data sources through LlamaIndex's two core components: KnowledgeGraphQueryEngine and VectorStoreIndex. The hybrid retrieval engine layer 3 initialization process integrates key parameters such as graph database configuration, vector database configuration, and embedded model path, achieving coordinated management of multiple data sources through a unified configuration interface. For example, core parameter configurations include: similarity_top_k set to 6 to control the number of search results; reranker_path pointing to the BGE-Reranker-Base model path, providing result optimization capabilities; and embedding_model_path configuring the M3E-Large model location to ensure semantic encoding consistency.

[0113] The HNSW (Hierarchical Navigable Small World) algorithm can construct efficient vector indexes. It achieves fast approximate nearest neighbor search by building a multi-level graph structure. Its performance advantages are: query efficiency increases logarithmically with data size; that is, when the vector database size expands from 100,000 to 1 million, the query time only increases by about an order of magnitude; index construction time is proportional to the product of the data size and its logarithm; and storage space is proportional to the product of the total number of vectors and the average number of connections per node. Key parameters for the HNSW algorithm can be configured as follows:

[0114] The maximum number of connections, M=24, defines the maximum number of edges per node in the graph structure. This parameter determines the connectivity and search accuracy of the graph; a larger M value results in higher search accuracy but also higher storage space consumption. The construction search parameter, ef_construct=150, controls the search depth during the index construction phase. This parameter affects the quality and time cost of index construction; a larger ef_construct value results in higher index quality but longer construction time. The query search parameter, ef_search=200, controls the search depth during the query phase. This parameter directly affects the query recall and response time; a larger ef_search value results in higher recall but slower query speed. In application, based on a test environment with 390,000 vectors, the above parameter combination achieved a single query response time of less than 10 milliseconds and a recall rate above 95%. The vector database can use cosine similarity as the distance metric, with the vector dimension set to 1024.

[0115] The Qdrant database is specifically optimized for high-dimensional vector retrieval. The final 390,592 1024-dimensional vectors are stored in the Qdrant vector database, using cosine similarity as the distance metric. The core calculation formula for semantic retrieval in the RAG system is:

[0116]

[0117] Where: q = query vector, d = document vector; q · d = vector dot product; ||q||, ||d|| = L2 norm of the vector; return value range: [-1, 1], 1 indicates a complete match.

[0118] The retrieval process calculates the cosine similarity between the query vector and all document vectors, returning the top-k documents with the highest similarity. The Qdrant database is specifically optimized for high-dimensional vector retrieval, supporting large-scale vector similarity queries at the millisecond level, and achieves excellent retrieval performance in conjunction with the HNSW indexing algorithm. Furthermore, by deeply integrating general retrieval enhancement and generation techniques with the professional needs of the medical field, through medical data augmentation, intelligent chunking, and specialized vector encoding, the accuracy and practicality of medical knowledge retrieval are significantly improved, providing a solid technical foundation for intelligent medication guidance.

[0119] Figure 6 This diagram illustrates the internal architecture of the hybrid retrieval engine, based on the LlamaIndex framework. It achieves deep integration of structured reasoning and semantic matching by parallelizing the knowledge graph query engine 31 and the vector query engine 32. A separate result return strategy maintains the independence and integrity of different retrieval types. Hybrid retrieval engine layer 3 employs a parallel architecture design, simultaneously launching two independent processing flows: graph query and vector retrieval, maximizing retrieval efficiency and response speed. The system's core query method utilizes a dual-path parallel execution mechanism to construct a return structure containing two independent result sets: "graph_results" (graph retrieval results) and "vector_results" (vector retrieval results). Graph query engine 31 handles structured knowledge retrieval, supporting complex logical reasoning and relation traversal, while vector query engine 32 is responsible for semantic similarity matching, handling fuzzy queries and concept associations. The two engines run independently, avoiding mutual blocking, and achieving optimal performance through a parallel execution mechanism.

[0120] In some embodiments, the vector query engine 32 includes a retrieval module and a reordering module.

[0121] The retrieval module uses a vectorization model to convert query commands into query semantic vectors, calculates the cosine similarity between the query semantic vector and the document vectors in the vector database, and returns the top-k documents with the highest similarity based on the retrieval data threshold, thus obtaining preliminary screening results.

[0122] The re-ranking module is used to input the query semantic vector into the re-ranking model, score the semantic relevance of each document unit in the preliminary screening results, and re-rank the preliminary screening results based on the scoring results to obtain the final screening results.

[0123] The retrieval process first encodes the query text into a query vector using the M3E-Large model, then performs a k-NN search in the Qdrant database, returning the top-k most similar document fragments. The re-ranking module uses the BGE-Reranker-Base model to perform a secondary ranking of the vector retrieval results. The re-ranking process calculates the relevance score between the query and each candidate document, using a Cross-Encoder architecture to simultaneously encode both the query and the document, and outputs the relevance score through a fully connected layer, improving the accuracy of semantic matching.

[0124] Based on the same inventive concept, such as Figure 7 As shown, this application also provides a medication guidance method based on the fusion of knowledge graph and vector retrieval, which is executed based on the medication guidance system described in any of the above schemes. This medication guidance method includes the following steps S701 to S703.

[0125] S701: Receives external demand information and transmits it to the large model platform.

[0126] S702: Receives query instructions from the large model platform and generates graph database query statements and query semantic vectors based on the query instructions.

[0127] S703: Perform a structured query on the graph database based on the query statement, and perform semantic similarity retrieval on the vector database based on the query semantic vector, generating graph retrieval results and vector retrieval results for the large model platform, so that the large model platform can output the retrieval results.

[0128] In one embodiment, prior to step S701, the medication guidance method based on the fusion of knowledge graph and vector retrieval further includes: acquiring drug material files and preprocessing the drug material files to generate structured data in the target format; performing block processing on the structured data in the target format, converting the block-processed document fragments into semantic vector representations and embedding them into a vector database, and converting them into standard triples and embedding them into a graph database.

[0129] It should be noted that the medication guidance method based on the fusion of knowledge graph and vector retrieval provided in this application embodiment and the medication guidance system based on the fusion of knowledge graph and vector retrieval provided in this application embodiment are based on the same inventive concept. Therefore, the specific implementation of this embodiment can refer to the implementation of the aforementioned medication guidance system based on the fusion of knowledge graph and vector retrieval, and the repeated parts will not be described again.

[0130] In some embodiments, an electronic device provided in this application includes a processor and a memory; the memory stores a computer program, wherein the computer program, when executed by the processor, implements the above-described medication guidance method based on the fusion of knowledge graph and vector retrieval.

[0131] Specifically, the processor may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor may also include onboard memory for caching purposes. The processor may be a single processing unit or multiple processing units for performing different actions of the method flow according to embodiments of this application.

[0132] Memory can be any medium capable of containing, storing, transmitting, propagating, or transmitting instructions. For example, memory can include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, instruments, or propagation media. Specific examples of memory include: magnetic storage devices such as magnetic tape or hard disk drives (HDDs); optical storage devices such as optical discs (CD-ROMs); and also random access memory (RAM) or flash memory; and / or wired / wireless communication links.

[0133] For example, such as Figure 8 As shown, electronic devices can include five core hardware components: system bus, processor, internal memory, network interface, and non-volatile storage medium.

[0134] System bus: As the communication backbone of the entire system, it is responsible for connecting various hardware components, ensuring efficient transmission of data and instructions between the processor, memory, network interface and storage media, and supporting the concurrent processing needs of large-scale vector computing and graph database queries.

[0135] Processor: Employing an 8-core CPU combined with a GPU-accelerated architecture, it is responsible for executing computational tasks of the hybrid retrieval engine, vector encoding processing of the M3E-Large model, result optimization of the BGE reorderer, and Cypher query generation of the DeepSeek-V3 model. The GPU is specifically used to accelerate inference computation of the M3E-Large embedding model, significantly improving the processing efficiency of semantic vector generation.

[0136] Internal Memory: Configured with 32GB of RAM for temporary storage of FastAPI application instances, MCP protocol processors, hybrid search engine running status, and cached data for the M3E model. An active HTTP connection pool, vector search index cache, and knowledge graph query result cache are maintained in memory to ensure the system's fast response capabilities.

[0137] Network Interface: Provides dual protocol support, including an HTTP RESTful API interface and a standard MCP protocol interface. The HTTP interface runs on port 8080, supporting direct API calls and system integration; the MCP Server is implemented based on the FastMCP framework, supporting tool calls from AI platforms such as Dify, and implementing structured intelligent dialogue services through the Function Calling mechanism.

[0138] Non-volatile storage media: Divided into three functional areas working together. The operating system area contains the Docker container environment and GPU drivers, providing the basic environment for application operation; the computer program area deploys core software components such as Python applications, the LlamaIndex framework, the M3E-Large embedding model, and the BGE-Reranker reordering model; the database area contains the Neo4j graph database storing a drug knowledge graph with 18 entity types and 17 relation types, and the Qdrant vector database storing 390,592 1024-dimensional drug knowledge vectors.

[0139] System Workflow: When a user initiates a query request via HTTP API or MCP protocol, the network interface receives the request and passes it to the processor. The processor calls the hybrid retrieval engine in memory to execute parallel queries, while simultaneously accessing the Neo4j and Qdrant databases in the storage medium to obtain structured knowledge and semantic vectors. Finally, the fused retrieval results are returned through the network interface. The entire process achieves efficient coordination between components through the system bus, ensuring system stability and high performance.

[0140] This application also provides a computer-readable medium storing a computer program that, when executed by a processor, implements the aforementioned medication guidance method based on the fusion of knowledge graph and vector retrieval. This computer-readable medium may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into that device / apparatus / system. The aforementioned computer-readable medium carries one or more programs, which, when executed, implement the method as described in the embodiments of this application.

[0141] According to embodiments of this application, a computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wired, optical fiber, radio frequency signals, etc., or any suitable combination thereof.

[0142] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application. Therefore, the scope of this application should not be limited to the above embodiments. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A medication guidance system based on the fusion of knowledge graph and vector retrieval, characterized in that, include: Data preprocessing layer, data processing layer, application access layer, service interface layer, and hybrid search engine layer; The data preprocessing layer includes a document processing module and an intelligent segmentation module. The document processing module extracts data from pharmaceutical material documents and sequentially performs data cleaning, unified encoding format processing, and a mapping mechanism based on standard fields to convert fields at predetermined positions in the pharmaceutical material documents into predefined standard fields, thereby converting the obtained data into structured data in the target format. The intelligent segmentation module performs overlapping segmentation processing on the structured data in the target format based on preset overlap parameters to obtain document fragments. It then segments array-type fields in the document fragments line by line according to standard delimiters in medical literature, breaking down complex medical concepts into independent semantic units. The data processing layer includes a medical data augmentation module, a knowledge graph construction module, and a vector encoding module. The medical data augmentation module receives document fragments output from the data preprocessing layer, automatically identifies and normalizes variant names of the document fragments based on a standardized mapping dictionary, and obtains medical augmented document fragments. The knowledge graph construction module adds structured tags to each medical augmented document fragment, identifies medical entities and relation types based on pharmaceutical domain knowledge, constructs standard triples, and embeds them into the graph database. The vector encoding module uses a pre-trained semantic embedding model to perform semantic vectorization processing on the medical augmented document fragments, obtaining semantic vector representations, and embeds these semantic vector representations into the vector database. The structured tags are used to support subsequent accurate retrieval and result traceability verification. The application access layer receives external demand information and transmits it to the large model platform. The service interface layer provides a unified tool interface based on the interface protocol, which is used to receive query instructions from the large model platform, transmit the query instructions to the hybrid retrieval engine layer, receive the retrieval results from the hybrid retrieval engine layer, and transmit the retrieval results to the large model platform, so that the large model platform can output reliable drug interaction analysis, medication safety assessment and personalized medication recommendations. The hybrid retrieval engine layer is used to generate graph database query statements and query semantic vectors according to the query instructions, perform structured queries on the graph database according to the graph database query statements, and perform semantic similarity retrieval on the vector database based on the query semantic vectors, generating graph retrieval results and vector retrieval results for the large model platform. Among them, the graph query supports complex multi-drug relationship reasoning. The system predefines multi-drug query templates, which are used to handle complex drug interaction analysis.

2. The medication guidance system based on the fusion of knowledge graph and vector retrieval as described in claim 1, characterized in that, The hybrid retrieval engine layer includes: a graph query engine and a vector query engine; The graph query engine is used to convert the query command into a graph database query statement using an embedded statement conversion model, perform a structured query on the graph database according to the graph database query statement, perform a structured conversion of the query results into a target format, and obtain the graph retrieval results. The vector query engine is used to convert the query instruction into a query semantic vector using a vectorization model, perform semantic similarity retrieval in a vector database based on the query semantic vector, filter the semantic retrieval results, and perform a structured conversion of the filtered results into a target format to obtain the vector retrieval results.

3. The medication guidance system based on the fusion of knowledge graph and vector retrieval as described in claim 2, characterized in that, The vector query engine includes: a retrieval module and a reordering module; The retrieval module is used to convert the query instruction into a query semantic vector using a vectorization model, calculate the cosine similarity between the query semantic vector and the document vectors in the vector database, and return the top-k documents with the highest similarity based on the retrieval data threshold to obtain preliminary screening results. The re-ranking module is used to perform secondary ranking of the vector retrieval results using the BGE-Reranker-Base model. The re-ranking process calculates the relevance score between the query and each candidate document, uses a Cross-Encoder architecture to encode both the query and the document simultaneously, and outputs the relevance score through a fully connected layer to re-rank the preliminary screening results based on the scoring results, thereby obtaining the final screening results.

4. A medication guidance method based on the fusion of knowledge graph and vector retrieval, characterized in that, The medication guidance method is performed based on the medication guidance system as described in any one of claims 1 to 3; the medication guidance method includes: Obtain the drug material file, extract the data from the drug material file, and sequentially perform data cleaning, unified encoding format processing, and convert the fields at predetermined positions in the drug material file into predefined standard fields based on a standard field mapping mechanism, and convert the obtained data into structured data in the target format. The structured data of the target format is processed by overlapping blocks based on preset overlap parameters to obtain document fragments. The array type fields in the document fragments are then segmented line by line according to the standard delimiters in medical literature, and the complex medical concepts are decomposed into independent semantic units. The document fragment is received, and its variant names are automatically identified and normalized based on a standardized mapping dictionary to obtain a medical enhanced document fragment. Structured tags are added to each medical augmented document fragment to identify medical entities and relation types based on pharmaceutical domain knowledge. Standard triples are constructed and embedded into a graph database. The structured tags are used to support subsequent accurate retrieval and result traceability verification. The medical augmented document fragment is semantically vectorized using a pre-trained semantic embedding model to obtain a semantic vector representation, and the semantic vector representation is then embedded into the vector database. The structured data in the target format is segmented, and the segmented document fragments are converted into semantic vector representations and embedded into a vector database, and converted into standard triples and embedded into the graph database. Receive external demand information and transmit the external demand information to the large model platform; Receive the query instruction from the large model platform, and generate a graph database query statement and a query semantic vector based on the query instruction; The graph database is structured according to the graph database query statement, and semantic similarity is performed in the vector database based on the query semantic vector. Graph retrieval results and vector retrieval results are generated and sent to the large model platform so that the large model platform can output reliable drug interaction analysis, medication safety assessment, and personalized medication recommendations. Graph query supports complex multi-drug relationship reasoning. The system predefines multi-drug query templates to handle complex drug interaction analysis.

5. An electronic device, characterized in that, It includes a processor and a memory; the memory stores a computer program, wherein the computer program, when executed by the processor, implements the medication guidance method based on the fusion of knowledge graph and vector retrieval as described in claim 4.

6. A computer storage medium, characterized in that, It stores a computer program, which, when executed by a processor, implements the medication guidance method based on the fusion of knowledge graph and vector retrieval as described in claim 4.

Images