Intelligent search system based on knowledge graph

Abstract

The present invention discloses an intelligent search system based on a knowledge graph, including a data management module, a data processing module, a natural language processing service module, a knowledge graph construction module, and an information retrieval module; the data management module, the data processing module, the natural language processing service module, the knowledge graph construction module, and the information retrieval module are connected in parallel. Based on the BERT pre-training model, the following three NLP services are implemented, including triple extraction, named entity recognition, and semantic matching. Through the python-based flask framework. A knowledge graph based on data from a specific field is developed, and a method for secondary training of a triple extraction model is proposed to reduce the workload of manual annotation of training data, achieve as little manual annotation as possible for the original specific data set, and train a triple extraction model for this data set; to a certain extent, the search engine can understand the user's intention, making the enterprise-level search engine more intelligent.

Description

Technical Field

[0001] The present invention relates to an intelligent search system for enterprise data based on a knowledge graph, and belongs to the field of computer technology. Background Art

[0002] After years of development, general search engine technology has continued to advance. For example, well-known search engines such as Google, Baidu, and Bing have all made significant progress in knowledge-based search technology. The knowledge graph is a concept proposed by Google in 2012. Its goal is to improve search results by describing various entities and concepts in the real world, as well as the relationships between these entities and concepts. By constructing a knowledge graph, a semantic network is formed. On this basis, search engines can understand user intent to a certain extent based on the entities and relationships in the knowledge graph and find the information they truly need. Knowledge graph-based search supports more accurate and concise result returns. Knowledge search often maps the user's search statement to a structured query statement. The ultimate location target is an entity in a knowledge base, which contains a wealth of relevant information. Therefore, as long as the entity in the knowledge base is accurately located, it can easily return a precise and concise search result to the user.

[0003] The application of search engine technology extends beyond general search scenarios covering the entire internet, such as Baidu and Google. There are also personalized search engines for enterprise-level data. Currently, most enterprise-level search engines are still in their infancy. They merely process, index, and store enterprise data. Users search using keywords, and documents containing the keywords are returned. These search engines fail to understand the semantic meaning of the user's search, reducing user interactivity with the search engine and search accuracy, failing to meet users' growing search needs. Recent advances in knowledge graphs and natural language processing have provided new development opportunities for search engines. Knowledge graphs use graph models to describe and construct knowledge. By extracting and storing entities and relationships, they form a network of triples, enabling the construction of a domain-specific knowledge base. This domain-specific knowledge base provides more complex semantic relationships between data. Therefore, it is crucial to apply knowledge graph technology to enterprise-level search engines. By searching within a domain-specific knowledge base, a certain level of natural language understanding can be achieved. The construction and application of knowledge graphs can enhance the accuracy of search results, strengthen the relevance of results to user input, and provide better search services for domain-specific data. Summary of the Invention

[0004] The purpose of the present invention is to provide an intelligent search system based on knowledge graphs, provide a solution for natural language search, and design and develop an intelligent search system based on knowledge graphs to implement natural language search for enterprise-level data in specific fields.

[0005] The present invention applies natural language processing technologies such as triple extraction, named entity recognition, and semantic matching, combines the search engine Solr and the graph database Nebula-Graph used in the present invention, and uses Java, Python, SpringBoot framework, etc. to develop an intelligent search system.

[0006] In order to achieve the above objectives, the technical solution adopted by the present invention is an intelligent search system based on knowledge graph, which is divided into the following five submodules from a functional perspective: data management module, data processing module, natural language processing service module, knowledge graph construction module, and information retrieval module; the data management module, data processing module, natural language processing service module, knowledge graph construction module, and information retrieval module are connected in parallel, such as Figure 1 As shown. In the natural language processing module, the present invention implements the following three NLP services based on the BERT pre-training model, including triple extraction (for the construction of knowledge graphs), named entity recognition, and semantic matching. Through the python-based flask framework, services are provided to the system in the form of a web service interface, and the return results are encapsulated. The system calls the corresponding interface in the part where natural language processing is required to parse and process the results. In the knowledge graph construction part, a knowledge graph is constructed based on data from a specific field, and a method for secondary training of triple extraction models is proposed to reduce the workload of manual annotation of training data, achieve as little manual annotation as possible for the original specific data set, and train a triple extraction model for this data set. In the natural language search part, semantic search based on named entity recognition and template matching is implemented, and improvements are made on this basis, and a method of semantic matching between sentences and relational words is proposed, so that enterprise-level search engines can understand users' natural language search requests.

[0007] like Figure 2The figure shows the architecture of the entire system, with the five key modules designed within it highlighted. Solr is a search engine, and in this invention, it can be broadly considered a database. Collections are created using the Java client provided by Solr. Each collection stores enterprise data in a specific field. This invention stores enterprise data collections called "query collections." Data stored in Solr is displayed in JSON format on the Solr admin interface. A collection stores multiple documents (docs), each of which is a piece of data. Each piece of data, or document, has multiple fields, with the id field being the unique identifier of the data within the collection.

[0008] nebula-graph is the graph database product used in this project. A nebula-graph instance consists of one or more graph spaces. Each graph space is physically isolated, allowing users to store different datasets in different graph spaces within the same instance. A spaceName uniquely identifies a dataset. Each space corresponds to a collection and stores a type of entity-relationship data, specifically triples extracted from the data in the corresponding collection, forming the semantically defined knowledge base for that collection. For each space, a schema configuration must be defined. The nebula-graph schema is shown in Table 1.

[0009] Table 1 Graph space configuration of nebula-graph

[0010]

[0011] Data management module: Solr and Nebula-Graph both have some data and basic configurations that need to be "managed". In this invention, the creation and deletion of Solr collections, the addition, deletion and modification of Solr collection fields, and the creation and deletion of Nebula-Graph spaces are all implemented by the data management module. The data management module manages the data and basic configurations of the entire system and mainly implements the following four functions: Solr data management, Nebula-Graph data management, triple ontology schema configuration management, and natural language question template configuration management. Figure 3 shown.

[0012] The Solr data management module is responsible for creating, configuring, and deleting dataset collections, as well as configuring, adding, and deleting collection fields. The creation and deletion of a collection corresponds to the creation and deletion of a space in the nebula-graph. That is, the creation and deletion methods of a space must be called from the creation and deletion methods of a collection. The space and the collection share the same name, and together they constitute the dataset for users to search. The collection is the original dataset to be queried, and the data stored in the space is the extracted knowledge base corresponding to the collection data.

[0013] The nebula-graph data management component is responsible for creating and deleting spaces in the nebula-graph graph database. It is also responsible for managing the schema configuration of nebula-graph spaces, namely, creating and deleting tags or vertex types (tags), creating and deleting edge types (edgetypes), creating and deleting tag indexes, and creating and deleting edge indexes.

[0014] Triple schema configuration management module: triples are subject, predicate, and object, namely, head entity, relationship, and tail entity. Triple schema is the type of subject, predicate, and object. This module is used to build a knowledge graph. The present invention requires triple extraction of the collection data to construct the corresponding knowledge graph, and triple extraction is achieved by calling the web interface provided by the natural language processing service module. The present invention is based on the BERT pre-trained language model, and the parameters of the model are modified accordingly through this downstream task, and then the triple extraction character is trained. The training requires schema configuration and training data labeled according to the schema configuration. The schema configuration is stored in the data set with the suffix "_schema" corresponding to the data set to be searched, and is used to manage the schema. The function of this module is to add, modify, and delete the schema, review and re-label the data of the collection to be queried according to the schema, and write the configuration to the training data to train the triple extraction model. Triple ontology configuration management such as Figure 3 shown.

[0015] Natural language question template management: For the schema configured for the collection to be queried, a relationship, also known as a predicate, can be obtained from each schema. Based on all the relationships (predicates) in the knowledge graph, a question matching template can be generated. This template management part is responsible for adding, deleting, and modifying matching templates. These question templates are stored in the corresponding collection with the suffix "_template".

[0016] Data processing module: In this project, there are two parts of data storage, namely the search engine Solr and the graph database Nebula-Graph.

[0017] This module is responsible for storing these two parts of data, adding, deleting, and modifying data in Solr collections, and inserting, deleting, and updating triple entities and relationships in Nebula-Graph.

[0018] The raw data needs to be processed before being stored in the Solr collection. This module implements three processing modules: short text filtering, text replacement, and segmentation and sentence separation. Finally, the processed data is indexed into the Solr collection. This part of the data processing is scalable and can be met by adding processing modules. For example, Figure 4 The triple data corresponding to the query collection is stored in a collection with the suffix "_extraction". The triple data in this collection, namely the relationships and entities, are stored in the nebula-graph, and connections are established between nodes through relationships to form a knowledge graph.

[0019] Natural language processing service module: This module is written in Python and implements four functions: triple extraction, named entity recognition, semantic matching between sentences and related words, and semantic matching between two sentences. It encapsulates them into interfaces and provides web services through the flask framework for Springboot projects to call. Figure 5 shown.

[0020] Triple extraction: This module implements the triple extraction function. First, the triple extraction model is trained, the trained model is saved on the server, and the code is written to provide web services to the outside world through the flask framework. The input is a short text set List <stringtext>The output is the triple corresponding to each short text of the input, including the extracted text and the triple information corresponding to the text, namely subject, subjectType, object, objectType, and predicate. The returned result is encapsulated in JSON format.

[0021] Named entity recognition: This module implements the named entity recognition function. First, the named entity recognition model is trained, the trained model is saved on the server, and code is written to provide a web service interface through the flask framework for the springboot project to call. The input is a short text collection, and the returned result is a named entity, which is encapsulated in json format.

[0022] Semantic matching: This section is divided into two parts: semantic matching between sentences and relational terms, and semantic matching between two sentences. Models are trained for each, and the trained models are saved on the server. Code is written to provide web services through the Flask framework, which will be called during the natural language search process. The purpose of semantic matching between sentences and relational terms is to obtain the entity with the closest relationship to a certain entity from the graph database; the purpose of semantic matching between two sentences is to find the question template most relevant to the user input sentence for subsequent search. This is introduced in detail in the natural language search section. Input: List <stringtext>Each text is divided into two parts, separated by "#". The output parameter "prob" represents the score, which reflects the matching degree of the two parts on the left and right of the "#". A threshold is set in the program. If the score exceeds this value, the two parts on the left and right of the "#" are considered to be matched.

[0023] Knowledge graph building blocks:

[0024] The purpose of this module is to extract triples from solrcollection data and store the extracted entity and relationship data into nebula-graph as a knowledge graph to support natural language search.

[0025] Knowledge graph construction process:

[0026] Step 1: Label the data in the Solr collection to be queried with triples.

[0027] Step 2: Train the triplet extraction model.

[0028] Step 3: Call the triple extraction interface of the natural language processing service module to extract, and store the extracted results in the corresponding collection of Solr.

[0029] Step 4: Review the extracted triples, i.e. the triple data stored in the corresponding collection in Solr.

[0030] Step 5: Store the reviewed data into the corresponding space in the graph database as the knowledge base corresponding to the data in this collection.

[0031] Information retrieval module: This module is used to retrieve data from databases (solr, nebula-graph). The information retrieval module is divided into a general retrieval module and a natural language search module for retrieval.

[0032] The general search module is implemented based on keyword matching and Solr encapsulated query parser.

[0033] The natural language search module is a scenario where users input natural language. It is necessary to convert the unstructured natural language query statements entered by users into structured query statements (for the query statements of the graph database, nebula-graph is used in this invention, and the unstructured query statements need to be converted into structured NGQL) to query the corresponding knowledge base (space). The returned query results are entity information, which is part of the result of the user's query. At the same time, the entity information is searched in the corresponding collection to return the final search results as another part of the user's query results. These two parts of the search results together constitute the user's query results. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 Diagram of the intelligent search system and its submodules.

[0035] Figure 2 This is the system architecture diagram.

[0036] Figure 3 Configure the management graph for the triple ontology.

[0037] Figure 4 This is the data processing module diagram.

[0038] Figure 5 Module diagram for natural language processing services.

[0039] Figure 6 Diagram of the data management module and its submodules.

[0040] Figure 7 Build a flowchart for the knowledge graph.

[0041] Figure 8 Flowchart for natural language search. DETAILED DESCRIPTION

[0042] To make the purpose, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0043] The intelligent search system consists of multiple modules: data management module, data processing module, natural language processing service module, knowledge graph construction module, and information retrieval module. The overall architecture of the system is shown in the figure below. Figure 2 shown.

[0044] In the present invention, according to Figure 2 , the entire system architecture is described through the following steps.

[0045] Step 1: Data Management

[0046] The data management module and its submodules are shown in the figure Figure 6 shown.

[0047] First, create a Solr collection through the Solr data management module. Each collection represents enterprise data in a specific field.

[0048] After creating the collection, configure the fields of the collection;

[0049] Create a graph database space corresponding to the collection and configure the vertex type (tag) and edge type (edgetype) corresponding to the space;

[0050] Configure multiple attributes of tag and edgetype;

[0051] Create single indexes and joint indexes for the tag and edgetype attributes;

[0052] Configure the triple ontology or schema (subject type, relationship, and object type) used to construct the knowledge graph for the data in the collection to be queried. After the schema is configured, it is stored in the dataset with the suffix "_schema" corresponding to the dataset to be queried.

[0053] Step 2: Data Processing

[0054] Enterprise data is unstructured. Before indexing this data into a Solr collection, it requires some processing based on actual needs. This module implements three processing modules: short text filtering, text replacement, and segmentation. This data processing module can be customized for different data types by adding additional processing modules.

[0055] Step 3: Knowledge graph construction

[0056] The knowledge graph construction process of this system is as follows Figure 7 As shown. After the following steps:

[0057] 1. Configure the triple schema for the collection to be extracted;

[0058] 2. Train the triplet extraction model using the open source training set;

[0059] 3. Separate the data to be extracted from the collection into sentences;

[0060] 4. Extract the triples by calling the natural language processing service module and store the results in a collection with the suffix "_extraction";

[0061] 5. Review the triple extraction, cleaning, and re-labeling, and write the re-labeled training data for this collection into the training file (the purpose of this review step is to re-label the triple training data for the collection to be queried);

[0062] 6. For the collection to be queried, retrain the triple extraction model and store it in the corresponding collection;

[0063] 7. Review data (the purpose of this review is to store it in the database space);

[0064] 8. Store the data into the graph database nebula-graph.

[0065] Because the present invention constructs a knowledge graph for a collection of data to be queried, and the data in these collections often come from corporate customers or data in a specific field, the model trained with the open source triple extraction training data set may not necessarily have a good extraction effect on the data in this specific field. The general practice is to have specialized personnel manually label this specific data set according to the configured triple schema. The system then writes the labeled training data into the training set file, calls the extraction service of the natural language processing service module to extract triples, and then reviews and stores them in the database. To address this situation, the present invention adopts a small improvement scheme, namely, conducting two trainings to reduce the operation of manually annotating data and improve the efficiency of the entire process. That is, triples are first extracted from the collection through the open source data set. At this time, the extracted data is not stored in the graph database, but is reviewed and modified. The modified data is written into the training set as training data for a second training. The purpose of this review and modification is to re-annotate the data of the collection to be queried and to train a model for the data of this collection. The modified triple data and the corresponding text are used as the re-annotated data and written into the training set file. The training interface of the natural language processing module is called to train again in order to obtain a triple extraction model that conforms to the data set to be queried.

[0066] At this point, the model can be used to extract the data of the query dataset again and review it again. The purpose of this review is to store the final triple data and store the reviewed data in the nebula-graph space.

[0067] Step 4: Natural Language Search

[0068] The natural language search flow chart is as follows Figure 8 shown.

[0069] As previously described, a knowledge graph has been constructed for the collection to be queried, and natural language search needs to be performed based on this knowledge graph. User queries are written in unstructured natural language, but the knowledge graph is implemented using the nebula-graph graph database. This requires structured query statements to be used and the results returned. In this system, the essence of natural language search is to convert unstructured user natural language queries into structured queries based on the knowledge graph. The following steps are used to convert unstructured queries into structured queries.

[0070] 1. Get the subject of the text through named entity recognition;

[0071] Named entity recognition is the first step in converting unstructured query statements into structured query statements. It requires obtaining the key entity information of the user input statement, that is, the subject.

[0072] 2. Obtain the relationship predicate through semantic matching;

[0073] First, construct an NGQL query statement for nebula-graph based on the subject obtained in step 1 (this NGQL does not specify edgetype or relationship). The purpose is to obtain all the predicates corresponding to this subject in the graph database.

[0074] Combine each relational word with the user's input sentence to get a List <stringtext>gather;

[0075] This set is used as a parameter to call the relational semantic matching structure of the natural language processing service module. A matching score is returned for each set of relations and query statements. When the matching score reaches a certain threshold, the relation is considered to be a relational term that can reflect the query statement entered by the user, and the relational term with the highest score is selected as the predicate.

[0076] Use the obtained subject and predicate to construct a structured NGQL query statement for nebula-graph, and query the tail entity (object) in the nebula-graph space. This entity will be part of the returned results.

[0077] 3. Use the obtained tail entity as the query keyword to query the collection to be queried in Solr as another part of the returned result.

[0078] In summary, the present invention realizes NLP downstream tasks such as triple extraction and named entity recognition through the research and application of the BERT model. Through the application of NLP technology and the knowledge graph constructed by enterprise data, that is, data in a specific field, to a certain extent, the search engine can understand the user's intention, realize the user's natural language search, and make the enterprise-level search engine more intelligent.< / stringtext> < / stringtext> < / stringtext>

Claims

1. An intelligent search system based on knowledge graph, characterized by: It includes a data management module, a data processing module, a natural language processing service module, a knowledge graph construction module, and an information retrieval module; the data management module, the data processing module, the natural language processing service module, the knowledge graph construction module, and the information retrieval module are connected in parallel; In the natural language processing module, the following three NLP services are implemented based on the BERT pre-trained model: triple extraction, named entity recognition, and semantic matching. The Python-based Flask framework provides services to the system in the form of a web service interface, encapsulating the return results. The corresponding interface is called in the part where natural language processing is required to parse and process the results. Based on this, we improved upon it by proposing a semantic matching method between sentences and relational words, which enabled enterprise-level search engines to understand users' natural language search requests. The nebula-graph data management component is responsible for creating and deleting spaces in the nebula-graph graph database. It is also responsible for managing the schema configuration of the nebula-graph space, including creating and deleting labels or vertex types, edge types, tag indexes, and edge indexes. Triple schema configuration management module: A triple is composed of subject, predicate, and object, i.e., head entity, relationship, and tail entity. The triple schema is the type of the subject, predicate, and object. This module is used to build knowledge graphs. Based on the BERT pre-trained language model, the model parameters are modified accordingly through downstream tasks, and then triple extraction character training is performed. Training requires schema configuration and training data labeled according to the schema configuration. The schema configuration is stored in the dataset with the suffix "_schema" corresponding to the dataset to be searched and is used to manage the schema. This module is responsible for adding, modifying, and deleting schemas, reviewing and re-labeling the data in the query collection according to the schema, and writing the configuration to the training data for training the triple extraction model. Natural Language Processing Service Module: Written in Python, it implements four functions: triple extraction, named entity recognition, semantic matching between sentences and related words, and semantic matching between two sentences. These functions are encapsulated into interfaces and provided as web services through the Flask framework for Spring Boot projects to call. Triple extraction: This module implements the triple extraction function. First, the triple extraction model is trained, the trained model is saved on the server, and the code is written to provide web services to the outside world through the flask framework. The input is a short text set List<String text> The output is the triple corresponding to each short text input, including the extracted text and the triple information corresponding to the text, namely subject, subjectType, object, objectType, and predicate. The returned result is encapsulated in JSON format. Named Entity Recognition: This module implements the named entity recognition function. First, the named entity recognition model is trained and saved on the server. Then, code is written to provide a web service interface through the Flask framework for the SpringBoot project to call. The input is a short text collection, and the returned result is a named entity, which is encapsulated in JSON format. Semantic matching: This part is divided into two parts: semantic matching between sentences and related words, and semantic matching between two sentences. Models are trained for each part, and the trained models are saved on the server. Code is written and web services are provided through the Flask framework, which will be called during the natural language search process.

2. The knowledge graph-based intelligent search system according to claim 1, characterized in that: Solr is a search engine. Collections are created through the Java client provided by Solr. Each collection stores enterprise data in a specific field. The collection that stores enterprise data is called a query collection. The data stored in Solr is displayed in JSON format on the Solr admin interface. A collection stores multiple documents, each of which is a piece of data. Each piece of data, i.e., a document, has multiple fields, with the id field serving as the unique identifier of the data in this collection. Nebula-graph is the graph database product used. A Nebula-graph instance consists of one or more graph spaces, each of which is physically isolated. Users use different graph spaces in the same instance to store different data sets. SpaceName uniquely identifies a data set. Each space corresponds to a collection, storing a type of entity-relationship data, that is, triple information extracted from the data in the corresponding collection, i.e., knowledge information.

3. The knowledge graph-based intelligent search system according to claim 2, characterized in that: Data Management Module: Both Solr and Nebula-Graph require data and basic configuration management. This includes creating and deleting Solr collections, adding, deleting, and modifying fields within Solr collections, and creating and deleting Nebula-Graph spaces. The Data Management Module manages the data and basic configurations across the entire system, implementing four functions: Solr data management, Nebula-Graph data management, triple ontology schema configuration management, and natural language question template configuration management.

4. The knowledge graph-based intelligent search system according to claim 1, characterized in that: The Solr data management module is responsible for creating, configuring, and deleting dataset collections, as well as configuring, adding, and deleting collection fields. The creation and deletion of a collection corresponds to the creation and deletion of a space in the nebula-graph. That is, the creation and deletion methods of the space must be called in the collection creation and deletion methods. The space name is the same as the collection, and the two together constitute the dataset for users to search. The collection is the original dataset to be queried, and the data stored in the space is the extracted knowledge base corresponding to the collection data.

5. The knowledge graph-based intelligent search system according to claim 1, characterized in that: Natural language question template management: For the schema configured for the collection to be queried, a relationship, also known as a predicate, is obtained from each schema. Based on all the relationships in the knowledge graph, a question matching template is created. This template management component is responsible for adding, deleting, and modifying matching templates. Question templates are stored in the corresponding collection with the suffix "_template".

6. The knowledge graph-based intelligent search system according to claim 1, characterized in that: Data processing module: This module has two data storage components: the search engine Solr and the graph database Nebula-Graph. It is responsible for storing data in both components, adding, deleting, and modifying data in Solr collections, and inserting, deleting, and updating triple entities and relationships in Nebula-Graph. Raw data requires processing before being stored in a Solr collection. This module implements three processing modules: short text filtering, text replacement, and segmentation and sentence segmentation. The processed data is ultimately indexed into a Solr collection. This data processing is scalable, allowing for the addition of additional processing modules to meet specific requirements. The triples corresponding to the collection to be queried are stored in a collection with the suffix "_extraction." The triples in this collection, namely the relationships and entities, are stored in a nebula-graph, with nodes connected through relationships to form a knowledge graph.

7. The knowledge graph-based intelligent search system according to claim 1, characterized in that: The knowledge graph construction module, the construction process is as follows: Step 1: Label the data in the Solr collection to be queried with triples; Step 2: Train the triplet extraction model; Step 3: Call the triple extraction interface of the natural language processing service module to extract the triples and store the extracted results in the corresponding collection of Solr; Step 4: Review the extracted triples, i.e. the triples stored in the corresponding collection in Solr; Step 5: Store the reviewed data into the corresponding space in the graph database as the knowledge base corresponding to the data in this collection.

8. The knowledge graph-based intelligent search system according to claim 1, characterized in that: The information retrieval module searches for data in the database. The information retrieval module is divided into a general search module and a natural language search module for retrieval.

Images