Knowledge graph application and construction method thereof, electronic equipment, computer storage medium and program product

Abstract

The embodiment of the invention provides a knowledge graph application and a construction method thereof, electronic equipment, a computer storage medium and a program product, and the knowledge graph application method comprises the steps that a knowledge graph matched with request data is determined, and in the knowledge graph, attribute data corresponding to nodes are stored on edges between the nodes; querying and determining nodes corresponding to the request data and edges corresponding to the nodes in the knowledge graph; and obtaining result data associated with the request data at least based on the attribute data of the node stored on the edge corresponding to the node. According to the embodiment of the invention, discovery and mining among different knowledge of different nodes are more efficient.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a knowledge graph application method, a knowledge graph construction method, an electronic device, a computer storage medium, and a computer program product. Background Technology

[0002] A knowledge graph (KG) is a structured data representation used to describe entities and their relationships. Knowledge graphs organize various types of information in the form of graphs, enabling computers to understand and reason about this information, thus supporting more complex data queries, knowledge discovery, and artificial intelligence applications.

[0003] Currently, knowledge graph construction often involves identifying entities and their corresponding related information within a document, then storing the relevant information as attribute data on the entity nodes, with entities as nodes and relationships between entities as edges. However, this approach is not conducive to mining the relationships between different knowledge components of different nodes. Summary of the Invention

[0004] In view of this, embodiments of this application provide a knowledge graph application and its construction scheme to at least partially solve the above problems.

[0005] According to a first aspect of the embodiments of this application, a knowledge graph application method is provided, comprising: determining a knowledge graph that matches requested data, wherein, in the knowledge graph, attribute data corresponding to nodes are stored on edges between nodes; querying and determining nodes in the knowledge graph that correspond to the requested data, and determining edges corresponding to the nodes; wherein, the edges corresponding to the nodes are edges with the nodes corresponding to the requested data as one of their endpoints; and obtaining result data associated with the requested data based at least on the attribute data of the nodes stored on the edges corresponding to the nodes.

[0006] According to a second aspect of the embodiments of this application, a knowledge graph construction method is provided, comprising: segmenting a document to be processed to obtain a plurality of document fragments corresponding to the document; for each of the plurality of document fragments, obtaining entities in the document fragment and attribute data corresponding to the entities; constructing a subgraph for the document fragment based on the obtained entities and attribute data, wherein in the subgraph, the entities are nodes and the attribute data is stored on the edges between the nodes; and generating a knowledge graph corresponding to the document based on the subgraphs corresponding to the plurality of document fragments respectively.

[0007] According to a third aspect of the present application, an electronic device is provided, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus; the memory is used to store at least one executable instruction, wherein the executable instruction causes the processor to perform an operation corresponding to the method described in the first or second aspect.

[0008] According to a fourth aspect of the embodiments of this application, a computer storage medium is provided that stores a computer program thereon, which, when executed by a processor, implements the method as described in the first or second aspect.

[0009] According to a fifth aspect of the embodiments of this application, a computer program product is provided, including computer instructions that instruct a computing device to perform an operation corresponding to the method described in the first or second aspect.

[0010] According to the solution provided in this application embodiment, unlike traditional knowledge graphs where node attribute data is stored within the nodes themselves, the knowledge graph in this application embodiment stores the attribute data corresponding to nodes on the edges between nodes. Therefore, on the one hand, when relevant data needs to be retrieved from the knowledge graph, only the nodes and their corresponding edges need to be determined to obtain the required data, without affecting the retrieval results; on the other hand, because the attribute data of adjacent nodes are stored on the edges rather than within the nodes, the attribute data of adjacent nodes is more explicit to each other. Furthermore, since this attribute data is related to both adjacent nodes, it is easier to reflect the relationships between different nodes, making the subsequent discovery and mining of different knowledge between different nodes more efficient. Attached Figure Description

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

[0012] Figure 1 A schematic diagram of an exemplary system to which the embodiments of this application are applicable;

[0013] Figure 2A This is a flowchart illustrating the steps of a knowledge graph construction method according to Embodiment 1 of this application;

[0014] Figure 2B for Figure 2A A schematic diagram of a knowledge graph construction process in the illustrated embodiment;

[0015] Figure 2C for Figure 2A A schematic diagram of an exemplary knowledge graph in the illustrated embodiment;

[0016] Figure 2D for Figure 2A A schematic diagram of a knowledge graph update process in the illustrated embodiment;

[0017] Figure 3A This is a flowchart illustrating the steps of a knowledge graph application method according to an embodiment of this application.

[0018] Figure 3B for Figure 3A A schematic diagram of an information fusion example in the illustrated embodiment;

[0019] Figure 3C for Figure 3A A schematic diagram of a knowledge graph application example in the illustrated embodiment;

[0020] Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0021] To enable those skilled in the art to better understand the technical solutions in the embodiments of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art should fall within the protection scope of the embodiments of this application.

[0022] The specific implementation of the embodiments of this application will be further described below with reference to the accompanying drawings.

[0023] Figure 1 An exemplary system applicable to embodiments of this application is shown. For example... Figure 1 As shown, the system 100 may include a cloud server 102, a communication network 104, and / or one or more user devices 106. Figure 1 The example in the text shows multiple user devices.

[0024] The cloud server 102 can be any suitable device for storing information, data, programs, and / or any other suitable type of content, including but not limited to distributed storage system devices, server clusters, computing cloud server clusters, etc. In some embodiments, the cloud server 102 can perform any suitable function. For example, in some embodiments, the cloud server 102 can be used to construct a knowledge graph. As an optional example, in some embodiments, the cloud server 102 can divide a document to be processed into multiple document fragments; first construct a subgraph for each document fragment, and then form a knowledge graph corresponding to the entire document based on the subgraphs of each document fragment. Unlike traditional methods, in this embodiment, the attribute data of nodes in the subgraphs constructed by the cloud server 102 is stored on the edges between nodes, thereby ensuring that the entire knowledge graph formed based on the subgraphs uses the edges between nodes to store the attribute data of the nodes. As another example, in some embodiments, the cloud server 102 can also perform information queries based on the constructed knowledge graph. For example, after receiving request data sent by user device 106, cloud server 102 can determine the matching knowledge graph based on the request data, and obtain the node information and the attribute data stored on the edges corresponding to the nodes from the knowledge graph as the result data. Furthermore, in some instances, cloud server 102 can also send the obtained result data to user device 106.

[0025] In some embodiments, the communication network 104 can be any suitable combination of one or more wired and / or wireless networks. For example, the communication network 104 can include any one or more of the following: the Internet, an intranet, a wide area network (WAN), a local area network (LAN), a wireless network, a digital subscriber line (DSL) network, a frame relay network, an asynchronous transfer mode (ATM) network, a virtual private network (VPN), and / or any other suitable communication network. The user equipment 106 can be connected to the communication network 104 via one or more communication links (e.g., communication link 112), and the communication network 104 can be linked to the cloud server 102 via one or more communication links (e.g., communication link 114). The communication link can be any communication link suitable for transmitting data between the user equipment 106 and the cloud server 102, such as a network link, a dial-up link, a wireless link, a hardwired link, any other suitable communication link, or any suitable combination of such links.

[0026] User device 106 may include any one or more user devices suitable for interacting with a user and having a human-computer interaction interface. In some embodiments, user device 106 may receive user input data and generate request data based on it, sending it to cloud server 102 to obtain matching result data from the knowledge graph through cloud server 102. In some embodiments, user device 106 may include any suitable type of device. For example, in some embodiments, user device 106 may include mobile devices, tablet computers, laptop computers, desktop computers, wearable computers, game consoles, media players, vehicle entertainment systems, and / or any other suitable type of user device.

[0027] Based on the above system, the solution of this application will be described through multiple embodiments. Below, we will first introduce the construction method of the knowledge graph in the embodiments of this application, and then describe the application of the constructed knowledge graph.

[0028] Reference Figure 2A The diagram illustrates a flowchart of a knowledge graph construction method according to Embodiment 1 of this application.

[0029] The knowledge graph construction method in this embodiment includes the following steps:

[0030] Step S202: Segment the document to be processed to obtain multiple document fragments corresponding to the document.

[0031] In this embodiment of the application, the document to be processed contains at least text content. For example, the document to be processed can be a plain text document or a rich text document.

[0032] To facilitate document processing, the document can be divided into multiple document fragments. When the document to be processed is a rich text document, the rich media data and its corresponding text content can be grouped into the same document fragment. It should be noted that, in the embodiments of this application, unless otherwise specified, "multiple," "various types," and other quantities related to "multiple" all refer to two or more.

[0033] The document segmentation of the document to be processed can be implemented by those skilled in the art in any appropriate way according to actual needs, including but not limited to segmenting according to the document's article structure, or segmenting according to the semantics between paragraphs, or segmenting according to a preset number of words or a preset number of paragraphs, etc. This application embodiment does not limit this.

[0034] In one feasible approach, there may be multiple documents to be processed, in which case each document needs to be segmented. That is, for each document, it is segmented to obtain multiple document fragments corresponding to each document.

[0035] Step S204: For each document fragment in the multiple document fragments, obtain the entities in the document fragment and the attribute data corresponding to the entities; based on the obtained entities and the attribute data corresponding to the entities, construct a subgraph for the document fragment.

[0036] In the subgraph corresponding to the document fragment, the entities in the document fragment are used as nodes, and the attribute data of the entities are stored on the edges between the nodes.

[0037] For each document fragment, named entity recognition can be used to identify the entities within it. As for the attribute data corresponding to the entities, after entity identification, the corresponding attribute data can be obtained from the document fragment for each entity. For example, entity attribute analysis can be performed on the text content related to the entity, or the attribute data corresponding to the entity can be extracted directly from the text of the current document fragment according to preset attribute fields. Furthermore, during the graph construction process, relationship information between entities is extracted from the document fragment, such as through dependency analysis and semantic parsing. Nodes in the subgraph can be constructed using the identified entities; edges between different nodes in the subgraph can be formed using the relationship information between entities; in this embodiment, the obtained entity attribute data is stored on the edges, not in the nodes corresponding to the entities. For example, a document fragment records the event of person A visiting person B. The entities in this document fragment include person A and person B, with person A corresponding to node A in the subgraph and person B corresponding to node B in the subgraph. The attribute data of node A includes the event information of person A visiting person B. In this embodiment, the attribute data of node A, that is, the event information of person A visiting person B, is stored on the edge between node A and node B, rather than stored in node A.

[0038] An edge between nodes has two endpoints, which represent two entities. These two entities, as endpoints of the edge, are related. Entity attribute data is stored on the edges between nodes; specifically, it's stored on edges between nodes with that node as one of their endpoints. For example, in the document fragment, entity A corresponds to node A in the subgraph, entity B corresponds to node B, and entity C corresponds to node C. Entity A / node A is related to entity B / node B and entity C / node C, respectively. Entity A's attribute data includes attribute data AB and attribute data AC. Attribute data AB is related to entities A and B, and attribute data AC is related to entities A and C. For instance, attribute data AB indicates that entity A visited entity B, and attribute data AC indicates that entity A and entity C are in conflict. In this example, entity A's attribute data AB is stored on the edge between entities A and B, and entity A's attribute data AC is stored on the edge between entities A and C.

[0039] In some implementations, the edges between nodes are also called the edges of the nodes. Storing entity attribute data on the edges between nodes is also described as storing entity attribute data on the edges of that node.

[0040] Generally, a node typically includes metadata and attribute data. Metadata describes the basic structural information of the object corresponding to the node (in this embodiment, this could be an entity, document, knowledge base, or user, etc.), such as the object's creation time, contained elements, and its own structure. Attribute data describes certain attributes possessed by the object, such as corresponding events, information sources, associated information, or even statistical data based on that information. Those skilled in the art can understand this using conventional definitions of node metadata and attribute data. For ease of distinction, in this embodiment, nodes corresponding to entities are called entity nodes; nodes corresponding to knowledge bases are called knowledge base nodes; and in one implementation, nodes corresponding to documents and users associated with documents are both called document nodes. This embodiment uses this approach for explanation. Since users associated with documents are typically those who perform related operations on the document, such as creation or modification, and have a close relationship with the document, and in the subsequent use of user nodes, users are usually combined with their associated documents, this approach strengthens the relationship between documents and users in the knowledge graph, facilitating subsequent processing. In another implementation, the node corresponding to the document is called a document node, and the node corresponding to the user is called a user node. This approach more clearly expresses the node type, allowing for targeted processing. When used alone, "node" can be understood as a general term for all these node types.

[0041] Furthermore, unlike traditional methods, the knowledge graph in this application embodiment also includes document-specific subgraphs to facilitate data tracing and document update operations. When generating a subgraph for a document, document information can be obtained first, including but not limited to at least one of the following: document operation data, information about the knowledge base to which the document belongs, and the correspondence between the document and entities. The document operation data includes information about the document's creation or modification, as well as information about the user who created or modified it; the information about the knowledge base to which the document belongs indicates which knowledge base the current document belongs to; and the correspondence between the document and entities indicates which entities the current document contains and the relationships between them. Therefore, document metadata can be recorded in the knowledge graph, and the real-time progress of knowledge graph construction can be queried on the knowledge graph.

[0042] Based on this, documents, users, and knowledge bases can be used as nodes, and edges can be constructed between nodes according to the relationships between documents and users, and documents and knowledge bases. Specifically, the edge between the node corresponding to a document and the node corresponding to a user can store the document's operation data; the edge between the node corresponding to a document and the node corresponding to the knowledge base can store the association information between the document and the knowledge base. Furthermore, based on the correspondence between documents and entities, the document node can be associated with its corresponding entity node, establishing edges between them.

[0043] In other words, for a specific document, the operation data for that document is obtained; based on this operation data, a document subgraph for that document is constructed, and the operation data is stored on the edges between nodes in the document subgraph. If there are multiple documents, the operation data for each document can be obtained; based on this operation data, a document subgraph corresponding to each document is constructed, where the operation data is stored on the edges between nodes in the document subgraph.

[0044] Step S206: Generate a knowledge graph corresponding to each document based on the subgraphs corresponding to the multiple document fragments.

[0045] Because each document fragment corresponds only to a part of the current document, its data is limited and partial. To obtain the complete knowledge graph corresponding to the current document, it is necessary to merge multiple subgraphs corresponding to multiple document fragments to generate the knowledge graph corresponding to the document. For example, if the document X to be processed is divided into 5 document fragments, and a subgraph is constructed for each document fragment, resulting in 5 subgraphs, then these 5 subgraphs need to be merged to obtain the knowledge graph corresponding to document X.

[0046] Subgraph merging includes both node merging and relation merging. For multiple subgraphs corresponding to multiple document fragments of the same document, they may contain the same nodes and relations, or they may contain different nodes and relations. For identical nodes, if the attribute data stored on their corresponding edges is consistent, they can be merged directly; otherwise, both the attribute data and the node must be merged. For different nodes and relations corresponding to different subgraphs, they can be merged directly.

[0047] For ease of explanation, let's take two simple subgraphs X1 and X2 as examples. Assume X1 contains nodes A, B, C, and D. The edge between A and B stores attribute data S1 and S2; the edge between A and C stores attribute data S3; and the edge between C and D stores attribute data S4. Subgraph X2 contains nodes A, B, C, and E. The edge between A and B also stores attribute data S1 and S2; the edge between A and C stores attribute data S3 and S5; and the edge between B and E stores attribute data S6.

[0048] Therefore, when merging subgraphs X1 and X2, one subgraph can be used as a reference to merge the other into that reference subgraph. In this example, subgraph X1 is used as the reference, and subgraph X2 is merged into X1. Specifically, since the attribute data stored on nodes A and B, as well as their edges, are the same in both X1 and X2, only nodes A and B and their edges in X1 need to be retained. For nodes A and C, although the nodes are the same, the attribute data on their edges is different, so the attribute data S5 in subgraph 2 can be copied or transferred to the edges between nodes A and C in subgraph X1. Node D does not exist in subgraph X2 and can be retained in subgraph X1. The attribute data S6 stored on the relationship between nodes E, B, and E, and their edges in subgraph X2 does not exist in subgraph X1 and needs to be copied or transferred to subgraph X1. After merging the two subgraphs X1 and X2, they contain nodes A, B, C, D, E, and their edges.<A,B> ,<A,C> ,<C,D> ,<B,E> Among them, the edge<A,B> The data stored above includes attribute data S1 and S2, and edge data.<A,C> The upper part stores attribute data S3 and S5, and edges.<C,D> The data stored above includes attribute data S4 and edge data.<B,E> The attribute data S6 is stored on it.

[0049] Similarly, multiple subgraphs can be merged into a knowledge graph corresponding to a single document.

[0050] If there are multiple documents to be processed, a total knowledge graph corresponding to each document can be generated from the individual knowledge graphs of those documents. For example, the individual knowledge graphs of multiple documents can be merged again to generate a total knowledge graph. A total knowledge graph built from multiple documents can carry richer information.

[0051] In addition, similar to the above, based on the information of each document, a document subgraph can be generated for each document; then, based on the document subgraphs and the knowledge graphs for each document, a total knowledge graph for multiple documents can be generated.

[0052] In one feasible approach, the information of each document includes at least one of the following: the operation data of each document, the information of the knowledge base to which each document belongs, and the correspondence between each document and an entity.

[0053] In this scenario, generating a total knowledge graph corresponding to multiple documents, based on the document subgraphs and knowledge graphs corresponding to each document, can be achieved by: establishing associations between each document and the generated knowledge graph based on the correspondence between each document and entities; and generating the total knowledge graph corresponding to multiple documents based on the document subgraphs, the associations, and the generated knowledge graphs. Optionally, the document subgraphs for each document can be constructed based on the operation data of each document and / or the information of the knowledge base to which each document belongs. This approach expands the types of nodes and edges included in the knowledge graph, enriches the knowledge information carried by the knowledge graph, and effectively establishes associations between document nodes and entity nodes, further facilitating subsequent data retrieval and data update efficiency based on the knowledge graph.

[0054] Further, optionally, after constructing the knowledge graphs corresponding to each document, when merging the multiple knowledge graphs corresponding to multiple documents to generate the total knowledge graph corresponding to multiple documents, in one example, for each document, it can be determined whether the knowledge graphs of other documents besides the current document contain the same node; if the same node is contained, then based on the attribute data stored on the same node and its corresponding edge, the multiple knowledge graphs corresponding to multiple documents are merged to generate the total knowledge graph corresponding to multiple documents.

[0055] In one possible scenario, multiple documents may have strong correlations, such as involving the same or related content. For example, both *Records of the Three Kingdoms* and *Romance of the Three Kingdoms* involve figures and events related to the Three Kingdoms period. Therefore, multiple knowledge graphs generated from such documents are highly likely to contain identical nodes, relationships between nodes, and node attribute data. In this case, when merging multiple knowledge graphs, on the one hand, each document's knowledge graph remains associated with its source document; on the other hand, it can enrich its own information with the help of information from other documents. Merging in this scenario does not delete nodes, relationships, or attribute data from the knowledge graphs of different documents; it mainly involves adding data and information obtained from other knowledge graphs to its own knowledge graph. For example, suppose that in the knowledge graph corresponding to *Romance of the Three Kingdoms*, the edge between the nodes Liu Bei and Zhang Fei stores attribute data, specifically events T1, T2, and T3 in this example; and in the knowledge graph corresponding to *Records of the Three Kingdoms*, the edge between the nodes Liu Bei and Zhang Fei stores events T2, T3, and T4. Therefore, after merging these two knowledge graphs, the edges between the nodes Liu Bei and Zhang Fei in both graphs will store events T1, T2, T3, and T4.

[0056] In an example of a knowledge graph built from multiple documents, the attribute data stored on the edges between nodes can include at least one of the following: event information corresponding to the entity, source document information for each event, and information about the images associated with each event in the source document. Specifically, the event information of an entity describes the related events between two entity nodes (e.g., the Oath of the Peach Garden between Liu Bei and Zhang Fei, or multiple battles Liu Bei and Zhang Fei participated in together); the source document information for each event indicates which of the multiple documents each event originates from (e.g., Battle A, in which Liu Bei and Zhang Fei participated, originates from *Romance of the Three Kingdoms*, Battle B, in which they participated, originates from *Records of the Three Kingdoms*, etc.). The source document information can be implemented as the identifier of the source document or other information that uniquely identifies the source document. If the relevant document also contains images associated with the event, the attribute data can further include information about the associated images in the source document. Optionally, this associated image information can also be implemented as the identifier of the associated image, such as an ID or image address. This effectively integrates information from multiple documents and allows for rapid location of the source document when needed, achieving efficient location and search.

[0057] Through the above process, a knowledge graph or a total knowledge graph carrying rich information can be obtained. Furthermore, since the attribute data of nodes is stored on the edges between nodes, it is not necessary to store it on each node, which saves data storage burden, improves data retrieval efficiency, and makes the relationships between nodes more explicit and easier to mine.

[0058] The use of the overall knowledge graph format in this application embodiment can also effectively improve the data update efficiency of the overall knowledge graph. In one feasible approach, after the overall knowledge graph is constructed, if document deletion information is received, the document node corresponding to the document indicated by the document deletion information and the entity nodes connected to the document node are searched in the overall knowledge graph; the document node and the edge between the document node and the entity node are deleted; and, based on the attribute data of the entity node, it is determined whether the entity node is still associated with other documents; if not, the entity node and its corresponding edge are deleted; if they are associated, the attribute data corresponding to the document in the attribute data of the entity node are deleted. In this way, it can be ensured that the corresponding overall knowledge graph can be quickly updated when a document is deleted. Furthermore, since the attribute data of the node is stored on the edge, it is possible to efficiently determine the information related to the document in the overall knowledge graph and delete it quickly, while avoiding accidental operations on entity nodes associated with other documents.

[0059] In one alternative approach, if only a portion of a document's content has been updated, the corresponding document segment can be identified for the updated portion. The subgraph corresponding to the original document segment can be deleted, a new subgraph corresponding to the new document segment can be created, and then merged with the subgraphs of other document segments. This eliminates the need to operate on the entire document as in traditional methods, improving document update efficiency and reducing update costs.

[0060] As can be seen, the knowledge graph constructed through this embodiment can more efficiently realize information retrieval, document deletion, or updating. Furthermore, the overall knowledge graph built based on multiple documents can deeply explore the relationships between these documents, forming a network-like global knowledge structure, thus solving the problem of knowledge limitations.

[0061] The following is for reference Figure 2B and Figure 2C The above knowledge graph construction method and the constructed knowledge graph are illustrated by a specific example.

[0062] First, refer to Figure 2B This specific example uses the construction of a knowledge graph for a document with the document number 001 as an example. The construction process includes:

[0063] Process 1: Split the document into multiple document fragments.

[0064] In this example, document 001 is split into three document fragments, simply illustrated as document fragments 1, 2, and 3.

[0065] Process 2: Write multiple document fragments to disk.

[0066] That is, persistently storing multiple document fragments, such as storing them on external storage devices like hard drives. In this example, we set up storing the three document fragments of document 001 on the hard drive.

[0067] Process 3: Based on the multiple document fragments after being written to disk, perform graph generation (exemplarily, as in subsequent processes 3201-3219) and knowledge base storage operations (exemplarily, as in subsequent processes 311-313).

[0068] After multiple document fragments are written to disk, graph generation and knowledge base storage operations can be performed either sequentially or in parallel. These will be explained separately below.

[0069] For example, knowledge base storage operations may include the following procedures 311, 312 and 313.

[0070] in:

[0071] Process 311: Perform document expansion using Doc2query on multiple document fragments.

[0072] Document expansion Doc2query is a widely used document expansion technique in information retrieval and machine learning. It trains a model to generate a series of potentially related queries for a given input document (Doc). These generated queries are appended to the original document to enrich its content representation, thereby improving information retrieval performance. One feasible approach is to use a generative base model for document expansion. A generative base model is an artificial intelligence model, such as LLM (Large Language Model), that generates various outputs based on user input data, using massive training datasets, neural networks, and deep learning architectures. LLM models possess natural language understanding, analysis, and text generation capabilities, and document expansion can be effectively achieved using LLMs. However, this is not the only approach; other methods of document expansion are also applicable to the solutions described in this application.

[0073] Process 312: Embedding is performed on the document fragments after document expansion to obtain the corresponding text embedding.

[0074] This embedding process can be implemented by those skilled in the art in any appropriate manner, including but not limited to word2vec, and the embodiments of this application do not impose any restrictions on it.

[0075] Process 313: Embed the text into the knowledge base via the writing engine.

[0076] By embedding text content into a knowledge base, a method is provided for subsequent acquisition of effective information through Retrieval-augmented Generation (RAG) to provide richer input data for LLMs, enabling them to generate more accurate text. RAG is a technique that provides external knowledge sources to generative foundation models such as LLMs, allowing them to generate accurate and context-aware answers while reducing model illusions. RAG includes several processes: retrieval, augmentation, and generation. The retrieval process retrieves relevant context from external knowledge sources based on the input data. In implementation, an embedding model can be used to embed the user query into the same vector space as the additional context in the vector database to perform similarity searches and return the retrieved context data. The augmentation process generates prompts based on the input data and the context data obtained from the retrieval process. The generation process then feeds these prompts into the LLM.

[0077] As can be seen, the above processes 311-313 provide a way to process user request data with the help of RAG+LLM, making the processing more intelligent.

[0078] Knowledge graph generation based on document fragments may, for example, include the following process:

[0079] Process 3201: Update the document information table to be processed based on multiple document fragments.

[0080] The document information table to be processed is used to store information about the documents for which the knowledge graph is to be generated.

[0081] Process 3202: Send an update request to update the knowledge graph.

[0082] For example, the request can be sent to the request queue metaq to await processing. Metaq is a distributed, queue-based message middleware that enables sequential processing of requests for knowledge graphs.

[0083] This update request can be used to request updates to an existing knowledge graph, including but not limited to operations such as adding, deleting, and modifying. The update in this example is an addition operation.

[0084] Process 3203: Determine whether the updated knowledge graph version number is greater than the existing knowledge graph version number; if yes, proceed to process 3204; otherwise, end the process.

[0085] By checking the version number, rollback operations on the knowledge graph can be effectively avoided, ensuring that updates to the knowledge graph are updates to new knowledge.

[0086] Process 3204: Determine if the knowledge graph is currently being operated on; if yes, return to process 3202 and continue waiting; if no, execute process 3205.

[0087] This operation includes both accessing the knowledge graph (such as searching for information within it) and updating the knowledge graph itself, as well as other operations. This effectively prevents abnormal situations from occurring when accessing or manipulating the knowledge graph.

[0088] Procedure 3205: Lock the current document.

[0089] By locking the current document, you can ensure that no other operations are performed on the current document while it is being processed, thus preventing processing errors or crashes caused by operations on the currently being processed document during the update process.

[0090] Procedure 3206: Update meta-map information based on document fragments.

[0091] In knowledge graphs, meta-graph information refers to metadata about the graph structure, entity types, relationship types, attribute types, and the interaction rules between these elements. This information plays a crucial role in the construction, management, and querying of the knowledge graph. Updating meta-graph information ensures the timeliness, accuracy, and completeness of the knowledge graph. New document fragments may cause changes to the aforementioned meta-graph information, necessitating its updating.

[0092] Procedure 3207: Increase the number of document chunks sequentially.

[0093] In this example, entities and relations are extracted from the document using LLM. Therefore, the number of document fragments can be increased within the acceptable range of LLM, so that it can process one or more document fragments at a time, thereby improving processing speed and efficiency.

[0094] Procedure 3208: Determine whether the size of the current number of document fragments exceeds the size of the data receiving window of the LLM model; if it does, reduce the number of document fragments and return to the determination operation to continue execution; if it does not exceed the size, execute procedure 3209.

[0095] Process 3209: Extract entities and relations from at least one document fragment using LLM; if extraction fails, continue to try for the preset number of extraction repetitions; if successful, execute process 3210.

[0096] The preset number of extraction repetitions can be set by those skilled in the art according to actual needs, and this application embodiment does not limit this.

[0097] Entity extraction includes both the extraction of the entity itself and the extraction of the attribute data corresponding to the entity.

[0098] Procedure 3210: Determine whether the processing of all document fragments in the current document has been completed; if completed, execute procedure 3211; if not completed, return to procedure 3207.

[0099] Process 3211: Based on the extracted entities and relationships, construct a knowledge graph for the current document.

[0100] In this step, we can first construct a subgraph for each document fragment based on the entities corresponding to each document fragment, the attribute data of the entities, and the relationships between the entities. Then, we construct the knowledge graph corresponding to the current document based on the subgraphs of each document fragment.

[0101] For example, based on the entities and relations corresponding to each extracted document fragment, entity merging and referential resolution can be performed to construct a subgraph corresponding to each document fragment; then, the subgraphs can be merged to construct the entire knowledge graph corresponding to the current document.

[0102] Procedure 3212: Store the entities and relationships corresponding to the current document.

[0103] For example, the implementation and relationships corresponding to the current document can be stored in the table storage system OTS.

[0104] Procedure 3213: Obtain the graph update lock for the knowledge graph.

[0105] By locking the current knowledge graph, it can be ensured that no other update operations are performed on the knowledge graph while updating the knowledge graph based on the current document. This avoids abnormal updates or crashes of the knowledge graph caused by other update operations during the update process.

[0106] In one feasible approach, only a portion of the knowledge graph corresponding to the current document fragment can be locked, while other parts of the graph remain accessible. This allows for updating the knowledge graph without affecting normal access to parts unrelated to the update.

[0107] Process 3214: Determine whether the acquisition of the graph update lock was successful; if successful, proceed to process 3215; if unsuccessful, continue to acquire and determine the lock.

[0108] Process 3215: Retrieve the entities and relations of the current knowledge graph that have been stored.

[0109] Process 3216: Update the knowledge graph based on the newly acquired entities and relations of the current document, as well as the entities and relations of the current knowledge graph that have been stored.

[0110] For example, the knowledge graph can be updated based on the results of entity merging and reference resolution of the entities and relations obtained from these two parts.

[0111] Procedure 3217: Release the map update lock.

[0112] After releasing the graph update lock, subsequent graph updates can be performed. When building a knowledge graph based on multiple documents, releasing the graph update lock allows operations to be performed on the next document to achieve knowledge graph updates based on that document.

[0113] Procedure 3218: Release the document update lock.

[0114] After the document update lock is released, the current document can be accessed or operated on in other ways.

[0115] Process 3219: Update the version number of the knowledge graph and display the update progress.

[0116] The process described above begins by dividing the input document into multiple document chunks of a predefined size. Then, LLM (Local Level Management) is applied to each chunk for named entity recognition and relation recognition, constructing a subgraph corresponding to each chunk based on the recognition results. After processing multiple chunks within a document, all subgraphs for that document are merged. For multiple documents, after all documents have been learned, the knowledge graphs corresponding to all documents are merged to form a unified knowledge graph for all documents. During the construction process, in addition to utilizing the LLM recognition results, document metadata information is added to the knowledge graph to construct document subgraphs for each document. Subsequently, these document subgraphs are merged with the knowledge graphs for all documents to form the final knowledge graph.

[0117] At this point, the knowledge graph update for a single document is complete.

[0118] An example of a knowledge graph constructed based on the above process is as follows: Figure 2C As shown, Figure 2C In the diagram, squares represent nodes, diamonds represent relationships between two nodes, and ellipses on the sides represent node attribute data. It should be noted that... Figure 2C In this process, when building the knowledge graph, an instance node is pre-built as the initial node for the current knowledge graph or a portion thereof. This node can be used to associate its associated knowledge graph or portion with a pre-defined application or function, thereby facilitating the management and maintenance of the knowledge corresponding to that application or function. For example, this instance node could be, for instance, an AI (Artificial Intelligence) assistant node (corresponding to a specific AI assistant, supporting its functionality), or an electronic customer service node, and so on. Different instance nodes are isolated from each other.

[0119] Under the instance node, there are document nodes, knowledge base nodes, etc. Among them, the document node has its corresponding entity node, as well as other nodes, such as user nodes. The node information of other nodes may include, but is not limited to, metadata.

[0120] Furthermore, as mentioned earlier, although the attribute data of nodes is stored on the edges between nodes, the metadata corresponding to the nodes (non-attribute data related to the entity or document corresponding to the node) can still be stored in the nodes themselves, such as... Figure 2C An ellipse on a node. This metadata includes, but is not limited to: the identifier, name, type, size, location, creation time, and modification time of the entity, document, or knowledge base corresponding to the node.

[0121] The constructed knowledge graph is dynamic and changeable. If a document is updated (added, modified, deleted, etc.), the corresponding knowledge graph will also be updated dynamically.

[0122] To ensure that the knowledge graph can delete the corresponding parts when a document is deleted, entity attribute data is stored on edges, such as edges from the entity to the document, and edges between entities. This way, when a document is deleted, only the attribute data of that entity within the current document is removed, without affecting other attribute data.

[0123] An exemplary knowledge graph update process when a document is deleted is as follows: Figure 2D As shown, the process includes:

[0124] Process A: Delete the stored document metadata and relationships based on the document deletion information.

[0125] Process B: Query all entities contained in the deleted document.

[0126] Process C: Delete all edges between the entity nodes corresponding to the entities contained in the deleted document and the document nodes corresponding to the deleted document in the knowledge graph, as well as the document nodes corresponding to the deleted document.

[0127] Process D: For each entity node in the entity nodes corresponding to all entities, query whether the entity node is associated with other documents through the reverse relationship of the entity node, and determine whether the entity node is an isolated node based on the query result; if it is an isolated node, delete the entity node from the knowledge graph; otherwise, execute process F.

[0128] When querying whether an entity node is associated with other documents through the reverse relationship of the entity node, the entity node can be used as the starting node to query other nodes that have connections with it. Based on the source document information stored on the edges between the entity node and other connected nodes, it can be determined whether the entity node is associated with other documents. If it is not associated with other documents, it can be considered an isolated node.

[0129] Process F: Determine whether all entity nodes corresponding to entities contained in the deleted document have been traversed; if yes, end the process; if no, return to process B to continue execution.

[0130] Through the above process, rapid and accurate dynamic updates of the knowledge graph are achieved.

[0131] Once a knowledge graph or a general knowledge graph is constructed or updated, it can be used for various applications. The following explains the applications of knowledge graphs.

[0132] Reference Figure 3AThe diagram illustrates a flowchart of the steps of a knowledge graph application method according to an embodiment of this application.

[0133] The knowledge graph application method in this embodiment includes the following steps:

[0134] Step S402: Determine the knowledge graph that matches the requested data.

[0135] The request data can be data corresponding to a user's input request to perform a certain function, such as question data (request for a response), instruction data (request to perform a certain operation), query request (request to perform a data query), etc. This application embodiment does not limit the specific implementation method of the request data.

[0136] In one feasible approach, the request data can be user-inputted request data used to instruct the LLM model to process and generate a corresponding response.

[0137] At least one knowledge graph is deployed on the server-side, such as a cloud server. Different knowledge graphs may correspond to different domains, such as knowledge graphs for the medical field, e-commerce field, legal field, and so on. The specific deployment of knowledge graphs can be carried out by those skilled in the art according to actual needs, and the embodiments of this application do not impose any restrictions on this.

[0138] It should be noted that the knowledge graph in this embodiment may be a knowledge graph built based on a single document, or it may be a total knowledge graph built based on multiple documents. In this embodiment, the term "knowledge graph" is used to refer to it uniformly. The document is divided into multiple document fragments. For details on document fragments and how to segment a document to obtain document fragments, please refer to the above embodiments, which will not be repeated here.

[0139] Upon receiving the requested data, it is necessary to determine the matching knowledge graph. For example, if the requested data involves a medical issue, then the corresponding knowledge graph is a knowledge graph in the medical field. And so on; this embodiment will not list them all.

[0140] In this embodiment, the knowledge graph deployed on the server can be a knowledge graph constructed based on the knowledge graph construction method described in the foregoing embodiments. In the knowledge graph constructed in this way, the attribute data corresponding to the nodes is stored on the edges between the nodes.

[0141] In one feasible approach, the knowledge graph of this embodiment is constructed based on at least one document, and the nodes in the knowledge graph include at least one of the following: entity nodes corresponding to entities in the document, document nodes corresponding to the metadata of the document, and knowledge base nodes corresponding to the knowledge base to which the document belongs.

[0142] Based on this, if the nodes in the knowledge graph are entity nodes, the attribute data stored on the edges between entity nodes includes at least one of the following: event information corresponding to the entity obtained from multiple documents, source document information for each event, and information about the images associated with each event in the source document. The source document information may include the identification information of the source document (such as an ID) and / or information about specific source document fragments (such as identification information or location information within the source document).

[0143] If the nodes in the knowledge graph are document nodes, then the attribute data stored on the edges between document nodes shall include at least the following: historical operation data for the document, including but not limited to modification information (such as the content modified) and creation information (such as the reason for creation).

[0144] If the nodes in the knowledge graph are knowledge base nodes, then the data stored on the edges between the knowledge base nodes and document nodes shall include at least the domain, type and other attribute data of the knowledge base.

[0145] An exemplary knowledge graph such as Figure 2C As shown.

[0146] Step S404: Query and determine the node in the knowledge graph that corresponds to the requested data, and determine the edge corresponding to the node.

[0147] In this context, an edge between adjacent nodes has two endpoints, which represent two entities. These two entities, acting as endpoints of the edge, are related. The node corresponding to the requested data and its corresponding edge are also defined. Specifically, an edge corresponding to a node is an edge whose endpoint is the node corresponding to the requested data. That is, an edge corresponding to a node may be an edge between two adjacent nodes or an edge connecting to a single node.

[0148] The requested data typically contains entity data. Therefore, in one feasible approach, this step can be implemented as follows: obtaining the entities from the requested data; based on the entities, querying and determining the nodes corresponding to the entities in the knowledge graph, and determining the edges corresponding to the nodes. The nodes include at least one of entity nodes, document nodes, and knowledge base nodes. Correspondingly, the edges corresponding to the nodes are the edges corresponding to these determined nodes.

[0149] As mentioned earlier, knowledge graphs contain various types of nodes, including entity nodes, document nodes, and knowledge base nodes. Based on the entities in the requested data, their corresponding entity nodes can be determined. Furthermore, based on the relationships between entity nodes and document nodes, and between document nodes and knowledge base nodes, the document nodes and knowledge base nodes corresponding to the entities in the requested data can be determined sequentially. After determining each node, their corresponding edges can be identified.

[0150] Step S406: Obtain result data associated with the requested data, based at least on the attribute data of the node stored on the edge corresponding to the node.

[0151] In this embodiment of the application, the attribute data of the nodes are stored on the edges between the nodes. Therefore, the corresponding result data can be obtained based on the attribute data stored on the nodes that match the requested data and their corresponding edges.

[0152] However, data directly obtained from a knowledge graph may be difficult for users to understand. Therefore, in one feasible approach, this step can be implemented as follows: determining the entity node in the knowledge graph corresponding to the entity in the requested data; obtaining the attribute data of the entity stored on the edge corresponding to the determined entity node and / or the source document information of each event in the attribute data; generating corresponding entity description information based on the entity's attribute data, and / or obtaining the corresponding document based on the source document information of each event in the attribute data; or, generating corresponding entity description information based on the entity's attribute data, and / or obtaining document fragments in the corresponding document based on the entity node and the source document information of each event, wherein the document contains multiple document fragments.

[0153] Among the feasible methods mentioned above, the following implementation methods are included:

[0154] In one implementation, attribute data of entities stored on the edges corresponding to a determined entity node is obtained. The attribute data includes at least one of the following: event information corresponding to the entity obtained from the plurality of documents, source document information for each event, and information about images associated with each event in the source document. Corresponding entity description information is generated based on the attribute data; that is, corresponding entity description information is generated based on at least one of the event information, source document information, and information about images associated with the source document.

[0155] In another implementation, the attribute data of the entity stored on the edge corresponding to the determined entity node is obtained, wherein the attribute data includes at least the source document information of each event. The corresponding document is obtained based on the source document information of each event in the attribute data, and / or, document fragments from the corresponding document are obtained based on the entity node and the source document information of each event.

[0156] In another implementation, attribute data of the entity stored on the edge corresponding to the determined entity node is obtained, wherein the attribute data includes at least the source document information of each event information. Optionally, the attribute data may also include at least one of the following: event information corresponding to the entity obtained based on the multiple documents, and information about the images associated with each event information in the source document. Corresponding entity description information is generated based on the attribute data; and, the corresponding document is obtained based on the source document information of each event in the attribute data, and / or, document fragments in the corresponding document are obtained based on the entity node and the source document information of each event.

[0157] The source document information for each event in the attribute data is also called the source document information corresponding to the attribute data.

[0158] Entity description information is a set of data or text that provides a detailed description of the entity corresponding to a specific entity node. It aims to better understand the entity so that the corresponding entity node can be identified more quickly and accurately based on the requested data. For example, if an entity node corresponds to a historical figure in a historical document, then the entity description information for that entity node could include a brief biography of that historical figure and important events that occurred to them. Or, if an entity node corresponds to a model of equipment in an industrial field, then the entity description information for that entity node could include the equipment's product introduction, user manual, and effects.

[0159] In one feasible approach, an entity description template can be pre-set, and entity description information can be generated based on the template and the obtained entity attribute data. This method, on the one hand, generates more easily understandable information; on the other hand, it simultaneously provides corresponding documentation content, offering richer information for subsequent processing.

[0160] However, this is not the only possibility. In one feasible approach, knowledge graph description information can also be generated based on the source document information corresponding to each event information in the entity description information and / or attribute data. This allows for a more comprehensive and accurate understanding of the knowledge in the knowledge graph corresponding to the requested data. Knowledge graph description information is a detailed explanation and description of the knowledge graph itself and its content. In this embodiment, because it is generated based on the entity description information and / or documents corresponding to the requested data, it can provide a more comprehensive description of the knowledge involved in the knowledge graph from a knowledge graph perspective, obtaining more objective information. Furthermore, it allows for a faster determination of the knowledge graph corresponding to the requested data. For example, in one example, if the knowledge graph is a discipline in the medical field, then the knowledge graph description information includes a basic introduction to the discipline and a summary of the knowledge graph's information. In another example, if the knowledge graph is a knowledge graph corresponding to a literary work, then the knowledge graph description information includes a basic introduction to the literary work, the main characters and main events in the literary work, etc.

[0161] As can be seen from the above, the result data associated with the requested data can be data obtained directly from the knowledge graph, or it can be data that has been further processed based on the data obtained from the knowledge graph, including but not limited to at least one of the following: entity description information, documents corresponding to the source document information, and knowledge graph description information.

[0162] In one feasible approach, the aforementioned result data can be directly used as the response data for the requested data. However, in some scenarios, the aforementioned result data may only be intermediate data, requiring further processing. For example, in some LLM-based data processing scenarios, a user inputs request data, hoping to obtain corresponding response data through generative base models such as LLM. This request data may be question data, instruction data, or indication data. In this case, the knowledge graph can be stored in a knowledge base in the form of an embedded representation. Based on this, the following steps (all optional steps) can also be performed.

[0163] Step S408: Based on the request data and result data, generate prompt information for inputting the generative base model, so as to generate response data in response to the request data through the generative base model based on the prompt information.

[0164] As mentioned above, the result data may include at least one of the following: entity description information, the document corresponding to the source document information, or knowledge graph description information. Alternatively, the result data may include at least one of the following: entity description information, document fragments, or knowledge graph description information.

[0165] For example, in one feasible approach, the data stored in the knowledge graph can be represented in an embedding format. Then, for the request data, embedding can be performed first to obtain the request data embedding; based on this request data embedding, the knowledge graph is queried to obtain the result data, which is also in an embedding format; furthermore, the embedded result data is converted into text data and merged with the request data that has not undergone embedding processing to obtain input prompts for the LLM; the LLM processes these prompts to generate response data that responds to the request data.

[0166] To make the solution more flexible and diverse, in one feasible approach, generating prompts for inputting generative base models such as LLMs based on request and result data can be implemented as follows: after generating corresponding entity description information based on attribute data, determine whether the document or document fragment indicated by the source document information has been obtained; if the document or document fragment has not been obtained, generate prompts based on the entity description information; if the document or document fragment has been obtained, generate prompts based on the document or document fragment and the entity description information.

[0167] In other words, in this method, a prompt can be generated based solely on entity description information, or it can be generated based on entity description information and the obtained document, or it can be generated based on entity description information and the obtained document fragment.

[0168] Further optionally, in one feasible approach, if a document or document fragment is obtained, generating a prompt message based on the document or document fragment and entity description information can be implemented as follows: If a document or document fragment is obtained, predict whether the size of the prompt message generated based on the document or document fragment and entity description information exceeds the acceptable input size of a generative base model such as LLM; if it does not exceed the limit, directly generate the prompt message based on the document or document fragment and entity description information; if it exceeds the limit, remove content that is not directly related to the entity from the document or document fragment; generate the prompt message based on the document or document fragment after removing the content and entity description information. Optionally, the predicted size of the prompt message can be based on the sum of the sizes of the various parts of the data used to generate the prompt message. However, this is not limited to this, and other prediction methods are also applicable.

[0169] For LLM (Limited Language Management), the acceptable data size for prompt messages is limited. However, document content can be extensive, resulting in a large data volume that may cause the final generated prompt message size to exceed the acceptable limit of LLM. Therefore, when the size exceeds the acceptable limit of LLM, the document or document fragment can be processed. For example, content in the document or document fragment that is not directly related to the entity in the requested data can be removed (e.g., if a document or document fragment has three parts, and only the second part is related to the entity in the requested data, the second part can be retained, and the first and third parts removed). Then, based on the document or document fragment after content removal, as well as entity description information and recall information, a prompt message is generated. Methods such as semantic analysis, semantic similarity matching, or entity-document content similarity judgment can be used to determine whether the document content or document fragment content has a direct relationship with the entity. However, this is not limited to these methods; other methods for determining whether an entity has a direct relationship with the content in the document or document fragment are also applicable to the solutions in this application embodiment.

[0170] In one feasible approach, generating prompt information based on a document or document fragment with content removed and entity description information can be achieved by: predicting whether the size of the prompt information generated based on the document or document fragment with content removed and entity description information exceeds the acceptable input size of a generative base model such as LLM; if it does not exceed the limit, then generating prompt information based on the document or document fragment with content removed and entity description information; if it exceeds the limit, then generating knowledge graph description information based on a preset information extraction algorithm, and generating prompt information based on the knowledge graph description information and entity description information. The information extraction algorithm can be arbitrarily set by those skilled in the art according to actual needs, and this application embodiment does not limit it, including but not limited to algorithms such as: summarization algorithms, MD5 algorithms, etc.

[0171] For example, such as Figure 3B As shown, the system first determines whether an entity can be retrieved from the knowledge graph. If it can be retrieved, entity description information is generated. If it cannot be retrieved, the system can use the conventional retrieval method to retrieve the request data text and generate a prompt message based on the retrieved text and the request data.

[0172] After generating entity description information, it can be determined whether documents or document fragments can be recalled based on the knowledge graph output. If no documents or document fragments are recalled, a prompt message is generated based on the entity description information and the request data. However, this is not the only possibility. In one feasible approach, the request data can be processed in two ways: recalling via both the knowledge graph and conventional recall methods. In this case, if no documents or document fragments are recalled, a prompt message can be generated based on the entity description information, the request data, and the text or document fragments recalled via conventional recall methods. Furthermore, documents or document fragments recalled via conventional recall methods can undergo small2big processing, and a prompt message can be generated based on the result of this processing, the entity description information, and the request data.

[0173] If a document or document fragment is retrieved, a prediction can be made to determine whether the size of the prompt message generated based on the document or document fragment, entity description information, and request data exceeds the acceptable input size (also known as the LLM window) of the large model LLM. If it does not exceed the size, a prompt message can be generated based on the document or document fragment, entity description information, and request data. Optionally, if it does not exceed the size, a prompt message can be generated based on the result of the document or document fragment, entity description information, request data, and the regular retrieved text small2big. If it exceeds the size, the document or document fragment needs to be processed to remove content in the document or document fragment that is not directly related to the entities in the request data.

[0174] Based on this, the system further predicts whether the size of the prompt message generated from the content-removed document or document fragment, entity description information, and request data exceeds the LLM window size. If it does not exceed the window size, a prompt message can be generated based on the content-removed document or document fragment, entity description information, and request data. If it exceeds the window size, knowledge graph description information can be generated based on the entity description information and request data, such as through a summarization algorithm. Then, a prompt message is generated based on the knowledge graph description information and request data. Optionally, a prompt message can be generated based on the knowledge graph description information, request data, and the result of the regular small2big retrieval text.

[0175] After generating the prompt message using any of the above methods, the prompt message can be input into the LLM so that the LLM can generate a response based on the prompt message, thus obtaining response data in response to the requested data.

[0176] Depend on Figure 3BAs can be seen, the overall generation of prompt information in this embodiment is a multi-path selection process. First, it determines whether the knowledge graph link has entity recall. If the knowledge graph does not have recall, a conventional text recall link is used. In this case, or when it is not possible to directly assess whether the knowledge graph has recall in the early stages, a certain threshold can be set for the conventional link to determine the confidence level of the text recall. If the confidence level of the link is determined to be high, the recall result of that link can be used directly. This threshold can be set by those skilled in the art according to actual needs; this example does not impose any restrictions on it.

[0177] When knowledge graphs have recall capabilities, entity description information can be generated based on the recalled entities, reducing the illusion of a large LLM model. Optionally, during knowledge graph recall, documents in which entities and relations appear are also recalled, thus obtaining the corresponding documents. If the combined document and entity description information does not exceed the window size of the large LLM model, a prompt can be generated for the large LLM model to use in generating response data. However, if it exceeds the window size of the large LLM model, the recalled documents can be further filtered based on the entities and relations identified in the request data to reduce the number of tokens (terms) subsequently input into the large LLM model. If, after filtering, it still exceeds the window size of the large LLM model, graph description information is generated using certain rules, and a prompt is generated based on this for the large LLM model to use.

[0178] The following is a further reference. Figure 3C The process of processing the requested data described above will be illustrated by way of an example. Specifically, the process includes:

[0179] Process 1: Obtain the request data and perform named entity recognition on the request data.

[0180] Optionally, LLM can be used to perform named entity recognition on the request data, but it is not limited to this. Other named entity recognition methods are also applicable to the scheme in this example.

[0181] Process 2: Determine if the requested entity has been obtained; if not, proceed to process 3; if obtained, proceed to process 6.

[0182] While request data usually contains entities, it may not in some cases. Therefore, after performing named entity recognition on the request data, it is also necessary to determine whether an entity has been identified. To facilitate differentiation from subsequent entities, in this example, the entities in the request data will be referred to as request entities.

[0183] Process 3: Perform text retrieval of the requested data in the usual manner.

[0184] For example, text retrieved from external databases (databases different from the aforementioned knowledge base) or web pages may be used as result data in response to the requested data. In this application embodiment, the specific implementation method for this retrieval is not limited.

[0185] Process 4: Reorder the recalled text.

[0186] Reranking is an operation that optimizes search results, i.e., result data, to improve the relevance and accuracy between the result data and the requested data. In this example, the reranking can be implemented by those skilled in the art in any appropriate manner according to the actual situation, and this application embodiment does not limit this. For example, a statistical reranking method or a machine learning model-based reranking method can be used, etc.

[0187] Step 5: Perform a small2big (small to large) operation on the reordered text to obtain the result data corresponding to the requested data. Then, proceed to Step 7.

[0188] If the requested data does not contain an entity, this process will obtain the result data in that case.

[0189] The small2big operation is a text processing strategy that divides text into different granularities or levels to improve the efficiency and effectiveness of text processing (such as retrieval and generation). Specifically, in this example, this operation can segment the obtained text into smaller text blocks (small) and larger text blocks (big) to carry information of different granularities in the subsequently generated prompts, facilitating better generation processing by the LLM (Local Language Module). The specific settings of "small" and "large" can be flexibly set by those skilled in the art according to actual needs, and this application embodiment does not impose any limitations on this.

[0190] Process 6: Retrieve entities from the knowledge graph that matches the requested data to obtain the corresponding result data.

[0191] The specific implementation of this process can be referred to the above. Figure 3A The method shown is implemented as follows, and as mentioned earlier, the data directly obtained from the knowledge graph may be entity attribute data (illustrated as "obtaining entity attributes" in the figure) and / or the source document information corresponding to the attribute data (illustrated as "obtaining entity n-degree relationship" in the figure). Based on this, at least one of the following can be generated: entity description information, documents (it is possible to obtain more than one document, i.e., a document set; in this case, the obtained documents can be sorted and deduplicated), and knowledge graph description information. All of these can be used as result data. It should be noted that the implementation of this process can refer to the description of the relevant parts in steps S406-S408 above, and will not be repeated here.

[0192] Furthermore, in one feasible approach, if an entity is recalled from the knowledge graph, request rewriting and / or intent rewriting can be performed on the request data based on that entity. Request rewriting includes, but is not limited to, replacing or expanding entities in the request data with the recalled entity; intent rewriting includes, but is not limited to, rewriting the entire request data or adding intent information based on the recalled entity.

[0193] Furthermore, the obtained n-degree relationships of entities can be labeled with the entities identified in the requested data to establish a correspondence between the two, facilitating subsequent comparison and use.

[0194] Process 7: Based on the result data and request data, generate a prompt message.

[0195] The implementation of this process can be referred to Figure 3B The process shown is described in detail here.

[0196] Step 8: Please enter the LLM prompt to generate the response data.

[0197] As can be seen, unlike traditional knowledge graphs where node attribute data is stored within the nodes themselves, the knowledge graph in this embodiment stores the attribute data corresponding to nodes on the edges between nodes. Therefore, on the one hand, when relevant data needs to be retrieved from the knowledge graph, only the nodes and their corresponding edges need to be identified to obtain the required data, without affecting the retrieval results; on the other hand, because the attribute data of adjacent nodes are stored on the edges rather than within the nodes, the attribute data of adjacent nodes is more explicit to each other. Furthermore, since this attribute data is related to both adjacent nodes, it is easier to reflect the relationships between different nodes, making the subsequent discovery and mining of different knowledge between different nodes more efficient.

[0198] Furthermore, in scenarios where LLM is used for response generation, the method described in this embodiment can provide richer and more effective input information to the LLM, making the LLM's response generation more accurate and efficient.

[0199] Reference Figure 4 This document illustrates a schematic diagram of an electronic device according to an embodiment of this application. The specific embodiments of this application do not limit the specific implementation of the electronic device.

[0200] like Figure 4As shown, the electronic device may include: a processor 502, a communications interface 504, a memory 506, and a communications bus 508.

[0201] in:

[0202] The processor 502, communication interface 504, and memory 506 communicate with each other via communication bus 508.

[0203] Communication interface 504 is used to communicate with other electronic devices or servers.

[0204] The processor 502 is used to execute program 510, which can specifically execute the relevant steps in any of the above method embodiments.

[0205] Specifically, program 510 may include program code that includes computer operation instructions.

[0206] The processor 502 may be a CPU, a GPU (Graphics Processing Unit), an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. The one or more processors included in the smart device may be processors of the same type, such as one or more CPUs; or they may be processors of different types, such as one or more CPUs and one or more ASICs.

[0207] Memory 506 is used to store program 510. Memory 506 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0208] Program 510 may include multiple computer instructions. Specifically, program 510 may use multiple computer instructions to cause processor 502 to perform the operation corresponding to the method described in any of the foregoing multiple method embodiments.

[0209] The specific implementation of each step in program 510 can be found in the corresponding steps and units described in the above method embodiments, and has corresponding beneficial effects, which will not be repeated here. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the devices and modules described above can be referred to the corresponding process descriptions in the foregoing method embodiments, and will not be repeated here.

[0210] This application also provides a computer storage medium storing a computer program thereon, which, when executed by a processor, implements the method described in any of the foregoing method embodiments. The computer storage medium includes, but is not limited to, compact disc read-only memory (CD-ROM), random access memory (RAM), floppy disk, hard disk, or magneto-optical disk.

[0211] This application also provides a computer program product, including computer instructions that instruct a computing device to perform an operation corresponding to any of the methods in the above-described multiple method embodiments.

[0212] Furthermore, it should be noted that the user-related information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to user input request data, sample data used for training the model, data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0213] It should be noted that, depending on the implementation needs, the various components / steps described in the embodiments of this application can be broken down into more components / steps, or two or more components / steps or parts of the operation of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of this application.

[0214] The methods described in the embodiments of this application can be implemented in hardware, firmware, or as software or computer code that can be stored in a recording medium (such as a CD-ROM, RAM, floppy disk, hard disk, or magneto-optical disk), or as computer code downloaded over a network that is originally stored in a remote recording medium or a non-transitory machine-readable medium and will be stored in a local recording medium. Thus, the methods described herein can be stored on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware (such as an Application Specific Integrated Circuit (ASIC) or a Field Programmable Gate Array (FPGA)). It is understood that the computer, processor, microprocessor controller, or programmable hardware includes storage components (e.g., Random Access Memory (RAM), Read-Only Memory (ROM), Flash Memory, etc.) capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods described herein. Furthermore, when a general-purpose computer accesses code used to implement the methods shown herein, the execution of the code transforms the general-purpose computer into a dedicated computer for executing the methods shown herein.

[0215] Those skilled in the art will recognize that the units and method steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for specific applications, but such implementations should not be considered beyond the scope of the embodiments of this application.

[0216] The above embodiments are only used to illustrate the embodiments of this application, and are not intended to limit the embodiments of this application. Those skilled in the art can make various changes and modifications without departing from the spirit and scope of the embodiments of this application. Therefore, all equivalent technical solutions also fall within the scope of the embodiments of this application, and the patent protection scope of the embodiments of this application should be defined by the claims.

Claims

1. A knowledge graph application method, comprising: A knowledge graph matching the requested data is determined, wherein the attribute data corresponding to the nodes is stored in the edges between the nodes in the knowledge graph; The query identifies the node in the knowledge graph that corresponds to the requested data, and determines the edge corresponding to the node; wherein the edge corresponding to the node is an edge with the node corresponding to the requested data as one of its endpoints; Based at least on the attribute data of the node stored on the edge corresponding to the node, result data associated with the requested data is obtained.

2. The method according to claim 1, wherein, The knowledge graph is constructed based on at least one document; The nodes in the knowledge graph include at least one of the following: entity nodes corresponding to entities in a document, document nodes corresponding to metadata of a document, and knowledge base nodes corresponding to the knowledge base to which the document belongs.

3. The method according to claim 2, wherein, If the nodes in the knowledge graph are entity nodes, the attribute data stored on the edges between entity nodes includes at least one of the following: event information corresponding to the entity obtained based on the multiple documents, source document information of each event information, and information of the image associated with each event information in the source document; If the nodes in the knowledge graph are document nodes, then the attribute data stored on the edges between document nodes includes at least: historical operation data for the document.

4. The method according to claim 2 or 3, wherein, The query determines the node in the knowledge graph corresponding to the requested data, and determines the edge corresponding to the node, including: Retrieve the entities from the requested data; Based on the entity, the node corresponding to the entity in the knowledge graph is determined by querying, and the edge corresponding to the node is determined. The node includes at least one of entity nodes, document nodes, and knowledge base nodes.

5. The method according to claim 4, wherein, The step of obtaining result data associated with the request data based at least on the attribute data of the node stored on the edges corresponding to the node includes: Determine the entity node corresponding to the entity; Obtain the attribute data stored on the edge corresponding to the determined entity node; Based on the attribute data, corresponding entity description information is generated.

6. The method according to claim 5, wherein, If the attribute data includes the source document information of each event, obtaining the result data associated with the request data based at least on the attribute data of the node stored on the edge corresponding to the node further includes: The corresponding document is obtained based on the source document information of each event in the attribute data; or, document fragments in the corresponding document are obtained based on the entity node and the source document information of each event, wherein the document contains multiple document fragments.

7. The method according to claim 6, wherein, The method further includes: Based on the entity description information and / or the document, generate knowledge graph description information.

8. The method according to claim 7, wherein, The request data is the request data used to request the generative basic model for processing. The method further includes: generating prompt information for inputting the generative base model based on the request data and the result data, so as to generate response data in response to the request data through the generative base model based on the prompt information; wherein the result data includes at least one of the following: the entity description information, the document, and the knowledge graph description information; or, the result data includes at least one of the following: the entity description information, the document fragment, and the knowledge graph description information.

9. The method according to claim 8, wherein, The step of generating prompt information for inputting the generative base model based on the request data and the result data includes: After generating the corresponding entity description information based on the attribute data, it is determined whether the document or the document fragment has been obtained; If the document or document fragment is not obtained, the prompt message is generated based on the entity description information; if the document or document fragment is obtained, the prompt message is generated based on the document or document fragment and the entity description information.

10. The method according to claim 9, wherein, If the document or document fragment is obtained, the prompt information is generated based on the document or document fragment and the entity description information, including: If the document or document fragment is obtained, predict whether the size of the prompt information generated based on the document or document fragment and the entity description information exceeds the size of the input that the generative base model can accept; If the limit is not exceeded, the prompt message is generated directly based on the document or document fragment and the entity description information; If the number of cases exceeds the limit, content that is not directly related to the entity is removed from the document or document fragment; based on the document or document fragment after removing the content and the entity description information, the prompt information is generated.

11. The method according to claim 10, wherein, The step of generating the prompt information based on the document or document fragment after removing the content, and the entity description information, includes: The prediction is based on whether the size of the generated prompt information, which is generated from the document or document fragment after removing the content and the entity description information, exceeds the size of the input that the generative base model can accept. If the limit is not exceeded, the prompt message is generated based on the document or document fragment after removing the content, and the entity description information; If the number of entries exceeds the limit, a knowledge graph description is generated based on a preset information extraction algorithm. Based on the knowledge graph description and the entity description, the prompt information is then generated.

12. A knowledge graph construction method, comprising: The document to be processed is segmented to obtain multiple document fragments corresponding to the document; For each of the plurality of document fragments, obtain the entity in the document fragment and the attribute data corresponding to the entity; based on the obtained entity and attribute data, construct a subgraph for the document fragment, wherein in the subgraph, the entity is used as a node and the attribute data is stored on the edges between the nodes; Based on the subgraphs corresponding to the multiple document fragments, a knowledge graph corresponding to the document is generated.

13. The method according to claim 12, wherein, The documents to be processed include multiple documents; The step of segmenting the document to be processed to obtain multiple document fragments corresponding to the document includes: segmenting the multiple documents to be processed into multiple document fragments corresponding to each document; The method further includes: generating a total knowledge graph corresponding to the multiple documents based on the multiple knowledge graphs corresponding to the multiple documents respectively.

14. The method according to claim 13, wherein, The step of generating a total knowledge graph corresponding to the multiple documents based on the multiple knowledge graphs corresponding to the multiple documents includes: Based on the information of each document in the multiple documents, a document subgraph is generated for each document; Based on the document subgraph and the knowledge graph corresponding to each document, a total knowledge graph corresponding to the multiple documents is generated.

15. The method according to claim 14, wherein, The information of each document includes at least one of the following: the operation data of each document, the knowledge base to which each document belongs, and the correspondence between each document and an entity; The step of generating a document subgraph for each document based on the information of each document in the plurality of documents includes: constructing a document subgraph corresponding to each document based on the operation data of each document and / or the knowledge base to which each document belongs; The step of generating a total knowledge graph corresponding to the multiple documents based on the document subgraphs and knowledge graphs corresponding to each document includes: establishing associations between each document and the generated knowledge graph based on the correspondence between each document and an entity; and generating a total knowledge graph corresponding to the multiple documents based on the document subgraphs, the associations, and the generated knowledge graphs.

16. The method according to claim 14 or 15, wherein, The step of constructing a document subgraph corresponding to each document based on the operation data of each document includes: Obtain the operation data corresponding to each document; Based on the operation data, a document subgraph corresponding to each document is constructed, wherein the operation data is stored on the edges between nodes in the document subgraph.

17. The method according to any one of claims 13-15, wherein, The step of generating a total knowledge graph corresponding to the multiple documents based on the knowledge graphs corresponding to the multiple documents respectively includes: For each document, determine whether the knowledge graphs of other documents besides the current document contain the same node; If there are identical nodes, the multiple knowledge graphs corresponding to the multiple documents are merged based on the attribute data stored on the identical nodes and their corresponding edges to generate a total knowledge graph corresponding to the multiple documents.

18. The method according to claim 17, wherein, The attribute data includes at least one of the following: event information corresponding to the entity, source document information of each event, and information about the image associated with each event in the source document.

19. The method according to claim 18, wherein, The method further includes: Received document deletion information; Locate the document node in the overall knowledge graph that corresponds to the document indicated by the document deletion information, and the entity node connected to the document node; Delete the document node and the edge between the document node and the entity node, and determine whether the entity node is still associated with other documents based on the attribute data of the entity node; If not associated, delete the entity node and the edge corresponding to the entity node; If associated, delete the attribute data corresponding to the document from the attribute data of the entity node.

20. An electronic device, comprising: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the operation corresponding to the method as described in any one of claims 1-19.

21. A computer storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in any one of claims 1-19.

22. A computer program product comprising computer instructions that instruct a computing device to perform an operation corresponding to any one of the methods described in claims 1-19.

Images