A knowledge graph construction method, system, product and medium based on large language model iterative knowledge extraction

Abstract

A knowledge graph construction method, system, product and medium based on large language model iterative knowledge extraction, related to the field of knowledge graph. The method comprises: obtaining ontology information and to-be-processed text, the attribute definition in the ontology information contains organizing attribute values into a hierarchical value domain from root category to leaf category; generating structured prompt words according to attribute definition and relationship definition; inputting the structured prompt words and the to-be-processed text into the large language model to recognize entity instances, and performing polling matching in the current level candidate category range from the root category according to the hierarchical value domain; performing constraint verification on the matching result, generating a correction prompt word and re-matching when the verification fails, and entering the next level category until reaching the leaf category when the verification passes, obtaining attribute values; extracting relationship instances and packaging them into a knowledge graph file. The present application divides the one-time distinguishing task of candidate values with similar semantics into multiple matching of gradual convergence, improving the accuracy of attribute values.

Description

Technical Field

[0001] This application relates to the field of knowledge graphs, and in particular to a knowledge graph construction method, system, product, and medium based on iterative knowledge extraction from a large language model. Background Technology

[0002] With the increasing application of large language models in the field of natural language understanding, extracting entities and attributes from text based on predefined ontology and automatically constructing knowledge graphs has become an important technical direction in the field of knowledge engineering. How to guide large language models to accurately determine the values ​​of entity attributes is a key factor affecting the quality of the constructed knowledge graph.

[0003] Related technologies typically employ an ontology-guided knowledge extraction method, which includes: pre-defining optional value ranges for each entity attribute in the ontology and organizing candidate values ​​within these ranges into a candidate list; when extracting attribute values, writing the entity instance identified in the text to be processed, along with the candidate list, into prompt words and inputting them into a large language model; the large language model then selects the value corresponding to the entity instance from the candidate values ​​contained in the candidate list during a matching process, and uses the selected value as the attribute value result for the entity instance.

[0004] In practical applications, when constructing knowledge graphs for certain professional fields, the range of selectable values ​​for entity attributes includes a large number of candidate values, and different candidate values ​​are semantically similar. In this case, the large language model needs to distinguish between a large number of semantically similar candidate values ​​in a single matching process, which increases the probability that the large language model selects a candidate value that does not correspond to the entity instance, thereby reducing the accuracy of the attribute value results and the reliability of the constructed knowledge graph. Summary of the Invention

[0005] This application provides a knowledge graph construction method, system, product, and medium based on iterative knowledge extraction from a large language model, which can improve the accuracy of attribute value results and the reliability of the constructed knowledge graph.

[0006] Firstly, this application provides a knowledge graph construction method based on iterative knowledge extraction using a large language model, applied to a knowledge graph construction system. The method includes: acquiring ontology information and text to be processed; the ontology information includes entity types, attribute definitions corresponding to the entity types, and relation definitions; the attribute definitions include organizing attribute values ​​into hierarchical value domains from root category to leaf category; generating structured prompt words corresponding to the entity types based on the attribute definitions and relation definitions; inputting the structured prompt words and text to be processed into a preset large language model, identifying entity instances belonging to the entity types in the text to be processed, and, based on the hierarchical value domains, extracting information from the root category within the candidate category range of the current level. Entity instances undergo polling matching to obtain the matching results for the current level. Constraint validation is then performed on the matching results at the current level based on attribute definitions to obtain validation results. If the validation result fails, a correction prompt is generated, and polling matching and constraint validation are re-executed until the validation result passes or the number of retries reaches a preset repetition threshold. If the validation result passes, polling matching and constraint validation are repeated for the next level category until the leaf category is reached to obtain the attribute values ​​of the entity instances. Based on the relationship definition, relationship instances between entity instances and target entity instances of the target entity type are extracted from the text to be processed. The validated attribute values ​​and relationship instances are then encapsulated to obtain the knowledge graph file.

[0007] By adopting the above technical solution, the knowledge graph construction system organizes attribute values ​​into hierarchical value domains from the root category to the leaf categories, and performs polling matching on entity instances within the candidate categories included in the current level, starting from the root category. Since the candidate category range at each level is relatively small, and the semantic differences between candidate categories at the same level are significant, the differentiation task faced by the knowledge graph construction system at each level is transformed from a one-time differentiation among a large number of semantically similar candidate values ​​to a progressively converging differentiation within a small range, thereby reducing the probability of selecting a category that does not correspond to the entity instance. Based on this, the knowledge graph construction system performs constraint verification on the matching results at each level, and generates correction prompts and re-executes polling matching and constraint verification when verification fails, allowing illegal values ​​to be intercepted and corrected. Only after verification passes does it delve deeper into the leaf categories. Therefore, the attribute values ​​determined by the knowledge graph construction system are checked at each level in terms of value range and constraints, improving the accuracy of attribute value results and the reliability of the constructed knowledge graph.

[0008] In conjunction with some embodiments of the first aspect, in some embodiments, based on the hierarchical value range, polling and matching are performed on entity instances within the candidate category range included in the current level, starting from the root category, to obtain the matching result of the current level. Specifically, this includes: sequentially traversing each candidate category within the candidate category range included in the current level, calculating the matching degree between the entity instance and each candidate category; determining the candidate category with the highest matching degree and greater than a preset matching threshold as the matching result of the current level; and determining the matching result of the current level as a miss when there is no candidate category within the candidate category range with a matching degree greater than the preset matching threshold.

[0009] By employing the above technical solution, the knowledge graph construction system sequentially traverses each candidate category within the current level's candidate category range and calculates the matching degree between the entity instance and each candidate category. The candidate category with the highest matching degree, exceeding a preset matching threshold, is determined as the matching result. Because of the introduction of this preset matching threshold as a lower limit criterion, the knowledge graph construction system only adopts a matching result when there are enough matching candidate categories, avoiding the forced selection of a candidate category with a low matching degree when the entity instance does not match any candidate categories. When there are no candidate categories within the candidate category range with a matching degree greater than the preset matching threshold, the knowledge graph construction system determines it as a miss. In summary, the knowledge graph construction system ensures that the adopted matching results have a definite lower limit of matching degree and explicitly identifies situations where unreliable classification is impossible, preventing misclassification from propagating down the hierarchy and being amplified at each level, thus ensuring the accuracy of hierarchical matching.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, when the verification result is unsuccessful, polling matching is re-executed. Specifically, this includes: when the number of retries for polling matching at the current level reaches a preset repetition threshold and the verification result is still unsuccessful, or when the matching result at the current level is a miss: if there is a parent category at the current level, then the process falls back to the parent category; within the candidate category range corresponding to the parent category, after excluding the candidate categories that have been determined to be unsuccessful in the current verification result, polling matching is re-executed to obtain the matching result of the parent category; if there is no parent category at the current level, then error information is recorded and the entity instance is skipped.

[0011] By adopting the above technical solution, when the number of retries at the current level reaches the preset repetition threshold and the verification still fails, or when the matching result at the current level is a miss, the knowledge graph construction system backtracks to the previous level category. It then excludes the candidate categories that were determined to fail in this instance from the candidate category range corresponding to the previous level category and re-executes the polling matching. Because a misselection at a previous level can cause subsequent levels to expand within the incorrect candidate category range during progressively deeper matching, and unidirectional downward progress cannot correct such errors, the knowledge graph construction system backtracks and excludes failed candidate categories, allowing the previously misselected path to be abandoned and other feasible paths to continue matching. Error information is only recorded and the entity instance is skipped when backtracking to the root category still fails to find a match or pass the verification. In this way, the knowledge graph construction system avoids directly obtaining incorrect values ​​or discarding the entire entity instance due to a single-level misselection, improving the success rate and accuracy of attribute value retrieval.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, constraint validation is performed on the matching results of the current level according to the attribute definition to obtain a validation result, including: performing validation on the matching results of the current level in a preset order of existence validation, mandatory validation, type conversion validation, range validation, enumeration value validation and uniqueness validation; if any of the existence validation, mandatory validation, type conversion validation, range validation, enumeration value validation and uniqueness validation fails, the validation result is determined to be unsuccessful, and subsequent unexecuted validations are skipped.

[0013] By adopting the above technical solution, the knowledge graph construction system performs checks on the matching results sequentially according to a preset order: existence check, mandatory check, type conversion check, range check, enumeration value check, and uniqueness check. If any check fails, the system determines the check result as failed and skips subsequent checks that have not yet been performed. Because this preset order is arranged from low to high check cost and from front to back dependencies, the knowledge graph construction system executes checks with low cost that are depended upon by subsequent checks first. This avoids meaningless checks such as range checks that depend on a value not yet meeting the conditions for subsequent checks. Furthermore, by short-circuiting and terminating immediately upon detecting an invalid value, the system saves the overhead of continuing to execute other checks after an invalid value has been determined, thus improving the execution efficiency of constraint checks while ensuring the integrity of multi-dimensional constraints.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, the verification result includes failed constraints and corresponding error information; when the verification result is failed, a correction prompt word is generated, specifically including: based on the failed constraints and corresponding error information, adding a correction constraint field to the structured prompt word to generate a correction prompt word.

[0015] By adopting the above technical solution, the knowledge graph construction system records the failed constraints and their corresponding error information when the verification result is unsuccessful. Based on these constraints and error information, it adds correction constraint fields to the structured prompt words to generate correction prompt words. Since the correction prompt words clearly indicate which constraint the previous output was invalid on and the reason for it, the knowledge graph construction system guides the large language model to perform targeted correction for that specific constraint, rather than regenerating it indiscriminately. This allows the large language model to avoid known invalid values ​​when re-outputting. In summary, the knowledge graph construction system increases the probability of obtaining a valid value on a single retrieval, reduces the number of retries required to obtain a value that passes verification, and makes the "generation-verification-correction" error correction process more targeted.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, after obtaining the ontology information and the text to be processed, the method further includes: initializing the queue to be processed, and storing the entity type in the ontology information as the starting point for extraction into the queue to be processed as the entity type.

[0017] By adopting the above technical solution, the knowledge graph construction system initializes a queue to be processed after acquiring ontology information, and stores the entity types from the ontology information that serve as the starting point for extraction into this queue. Since the extraction process for each entity type is incorporated into a unified queue scheduling framework, the knowledge graph construction system can retrieve entity types sequentially in a defined order and perform extraction on them, without needing to pre-specify all entity types to be processed at once. This queue also provides a structure for dynamically adding new target entity types when relation instances are extracted. Therefore, the knowledge graph construction system organizes the originally independent entity type extraction processes into a schedulable, scalable, and ordered process.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, after extracting the relationship instances between entity instances and target entity instances under the target entity type from the text to be processed based on the relationship definition, the method further includes: when the target entity type does not belong to the entity types in the queue to be processed, adding the target entity type to the tail of the queue to be processed; taking the next entity type from the queue to be processed in a first-in-first-out order, and repeatedly performing the generation of structured prompt words, identification of entity instances, polling matching, constraint verification and extraction of relationship instances for the taken entity type until the queue to be processed is empty.

[0019] By adopting the above technical solution, after extracting relation instances, the knowledge graph construction system adds the target entity type to the tail of the queue if it does not belong to the entity type in the queue. Then, following a first-in-first-out (FIFO) order, it repeatedly performs prompt word generation, entity instance identification, polling matching, constraint verification, and relation instance extraction until the queue is empty. Because newly discovered associated entity types are continuously added and processed sequentially, the knowledge graph construction system expands from the extraction starting point along the relation definition in a breadth-first manner to each associated entity type in the ontology. This avoids knowledge omissions and relation chain breaks caused by processing only the starting entity type. Simultaneously, by judging the queue and already processed entity types, the knowledge graph construction system does not repeatedly add entity types already in the queue or processed, avoiding processing redundancy or infinite loops caused by repeatedly enqueuing the same entity type.

[0020] Secondly, this application provides a knowledge graph construction system, which includes: an ontology parsing module for acquiring ontology information and text to be processed; the ontology information includes entity types, attribute definitions and relation definitions corresponding to the entity types, and the attribute definitions include organizing attribute values ​​into hierarchical value domains from root category to leaf category; a prompt word generation module for generating structured prompt words corresponding to entity types based on the attribute definitions and relation definitions corresponding to the entity types; a large model interaction module for inputting the structured prompt words and text to be processed into a preset large language model to identify entity instances belonging to the entity types in the text to be processed; and a polling matching module for performing polling matching on entity instances within the candidate category range included in the current level, starting from the root category, based on the hierarchical value domain, to obtain the matching result of the current level; attributes; The verification module performs constraint validation on the matching results of the current level based on attribute definitions, obtaining the validation result. When the validation result fails, the prompt word generation module is triggered to generate a correction prompt word, and the polling matching module and attribute validation module are triggered to re-execute polling matching and constraint validation until the validation result passes or the number of retries reaches the preset repetition threshold. When the validation result passes, the polling matching module and attribute validation module are triggered to enter the next level category to repeat polling matching and constraint validation until the leaf category is reached to obtain the attribute values ​​of the entity instance. The relationship processing module extracts the relationship instances between entity instances and target entity instances under the target entity type from the text to be processed based on the relationship definition. The encapsulation module encapsulates the validated attribute values ​​and relationship instances to obtain the knowledge graph file.

[0021] Thirdly, this application provides a computer-readable storage medium storing computer instructions that, when executed on a knowledge graph construction system, cause the knowledge graph construction system to perform the methods described in the first aspect and any possible implementation thereof.

[0022] Fourthly, this application provides a computer program product, including a computer program or instructions that, when run on a knowledge graph construction system, cause the knowledge graph construction system to perform the method described in the first aspect and any possible implementation thereof.

[0023] Understandably, the knowledge graph construction system provided in the second aspect, the computer-readable storage medium provided in the third aspect, and the computer program product provided in the fourth aspect are all used to execute the methods provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of a system structure of a knowledge graph construction system in an embodiment of this application;

[0025] Figure 2 This is a flowchart illustrating a knowledge graph construction method based on iterative knowledge extraction from a large language model, as described in an embodiment of this application.

[0026] Figure 3 This is another flowchart illustrating a knowledge graph construction method based on iterative knowledge extraction from a large language model, as described in this application embodiment.

[0027] Figure 4 This is a timing diagram of an example of operation in this application. Detailed Implementation

[0028] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification of this application, the singular expressions “a,” “an,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0029] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0030] Combination Figure 1 For an explanation of the system architecture of the knowledge graph construction system provided in this application, please refer to [link to relevant documentation]. Figure 1This is a schematic diagram of the system structure of the knowledge graph construction system in the embodiments of this application.

[0031] The knowledge graph construction system 100 includes an ontology parsing module 101, a prompt word generation module 102, a large model interaction module 103, a polling matching module 104, an attribute verification module 105, a relationship processing module 106, an encapsulation module 107, and an output interface 108.

[0032] It should be noted that the above modules can be physically deployed on the same server or terminal device, or distributed in a cluster consisting of multiple servers and terminal devices. The modules interact with each other through internal function calls, inter-process communication, or network interfaces. The above modules can be implemented in pure software (e.g., as program modules, functions, classes, or services that can be loaded and executed by a processor), or in a combination of software and hardware. This application does not limit the implementation in this regard. In a typical implementation, the knowledge graph construction system 100 is deployed as a software service, providing an ontology input interface and a topic word (or text to be processed) input interface to the outside world. Internally, data flows sequentially according to the main data flow: ontology parsing module 101 → prompt word generation module 102 → large model interaction module 103 → polling matching module 104 → attribute verification module 105 → relationship processing module 106 → encapsulation module 107 → output interface 108. A "generation-verification-correction" feedback loop is formed between the attribute verification module 105, the polling matching module 104 and the prompt word generation module 102.

[0033] The knowledge graph construction system 100 is used to iteratively extract structured knowledge that conforms to ontology constraints from the text to be processed (or the knowledge internalized by the large language model) based on the user's predefined ontology information, and encapsulate it into a standard knowledge graph file to improve the accuracy of attribute value results and the reliability of the constructed knowledge graph.

[0034] The specific functions of each module and the connection relationships between modules are explained in detail below.

[0035] The ontology parsing module 101 is used to obtain ontology information and text to be processed. The ontology information includes entity type, attribute definition and relation definition corresponding to entity type. The attribute definition includes organizing attribute values ​​into a hierarchical value range from root category to leaf category.

[0036] Specifically, the ontology parsing module 101 can read ontology information expressed in JSON Schema, OWL (Web Ontology Language) files, or other custom structured formats, and parse it into a unified data structure within the system. Entity types represent object categories in the knowledge graph, such as surface ships and carrier-based aircraft; attribute definitions describe the attributes of each entity type, with each attribute containing an attribute name, data type (e.g., string, integer, floating-point, date, boolean, enumerated value), whether it is required, whether it is unique, and constraint information such as value range; relationship definitions describe the associations between entity types, and may include relationship name, source entity type, target entity type, cardinality constraints (one-to-one, one-to-many, many-to-many), and whether it is symmetric.

[0037] Furthermore, for situations where there are many selectable values ​​for attributes in certain professional fields and their semantics are similar, the ontology parsing module 101 organizes the attribute values ​​into a hierarchical value domain from the root category to the leaf categories when parsing the attribute definition. The hierarchical value domain is a tree-like multi-level classification structure, where the root category is at the top level, representing the coarsest-grained value division, and the leaf categories are at the bottom level, representing the finest-grained specific values. The classification is refined level by level from the root category to the leaf categories, with each level containing several candidate categories, and a candidate category at the upper level expanding downwards to become the candidate category range at the lower level. For example, for the attribute "ship type," the root category may contain candidate categories such as "combat ships" and "auxiliary ships." "Combat ships" can be expanded downwards to candidate categories such as "aircraft carriers," "destroyers," and "frigates." "Aircraft carriers" can then be expanded downwards to specific model categories, thus organizing the originally flat and numerous candidate values ​​into a hierarchical structure that can converge at each level. The ontology parsing module 101 provides the parsed entity types, attribute definitions (including hierarchical value domains), and relation definitions to the prompt word generation module 102, polling matching module 104, attribute verification module 105, and relation processing module 106 for them to call.

[0038] The prompt word generation module 102 is used to generate structured prompt words corresponding to entity types based on the attribute definitions and relationship definitions corresponding to entity types.

[0039] Specifically, the prompt word generation module 102 obtains the entity type E to be processed and all its attribute definitions (P1, P2, ..., Pn) and relation definitions (R1, R2, ..., Rm) from the ontology parsing module 101, and dynamically assembles structured prompt words according to a preset prompt word template. The generated structured prompt words include at least the following fields: system setting fields for setting the role and output specifications of the large language model (e.g., "You are a knowledge graph building assistant, please strictly follow the following format to output JSON"); entity type requirement fields for constraining the scope of entity recognition; attribute constraint description fields generated for each attribute based on its data type, value range constraints, enumeration range, mandatory content, and uniqueness (e.g., "Displacement is of floating-point type, unit is tons, value range ≥ 0, please use null if unknown"); relation description fields generated for each relation based on its target entity type and direction; and output format fields for standardizing the returned data form (e.g., specifying the output as a JSON array and providing an example). When dealing with attributes involving hierarchical value ranges, the prompt word generation module 102 can write the range of candidate categories included in the current level into the prompt word, guiding the large language model to take values ​​within that range.

[0040] Furthermore, the prompt generation module 102 is also used to generate a corrected prompt when the verification result of the attribute verification module 105 is unsuccessful. In some embodiments, the prompt generation module 102, based on the unsuccessful constraint item and the corresponding error information fed back by the attribute verification module 105, adds a corrected constraint field (e.g., "The previously returned country value is not within the allowed range, please select only from the United States / China / Russia / United Kingdom") to the original structured prompt, thereby generating a corrected prompt. The prompt generation module 102 outputs the generated structured prompt or corrected prompt to the large model interaction module 103.

[0041] The large model interaction module 103 is used to input structured prompts and text to be processed into a preset large language model to identify entity instances of entity type in the text to be processed.

[0042] Specifically, the large model interaction module 103 encapsulates the calling process of the preset large language model, shielding the underlying interface differences from the outside, and providing a unified calling entry point for the inward prompt word generation module 102 and the polling matching module 104. The preset large language model can be a general large language model (such as GPT, Wenxin Yiyan, Qianwen, etc.) or a domain-specific large language model constructed using fine-tuning or retrieval-augmented generation (RAG) techniques. The large model interaction module 103 sends the structured prompt words generated by the prompt word generation module 102 and the text to be processed (in the scenario where knowledge extraction is based solely on ontology and topic words, the text to be processed can be topic words or entity instance names extracted in the previous round) to the large language model. It receives the structured data (usually a JSON array) returned by the large language model and performs format parsing and preliminary cleaning (such as removing redundant characters and correcting the JSON structure) on the returned data, thereby identifying each entity instance belonging to the entity type and its attribute values ​​and relational target information, and provides the identification results to the polling matching module 104.

[0043] The polling matching module 104 is used to perform polling matching on entity instances within the candidate category range included in the current level, starting from the root category, based on the hierarchical value range, to obtain the matching result of the current level.

[0044] Specifically, the polling matching module 104 matches the entity instances identified by the large model interaction module 103, starting from the root category of the hierarchical value domain and proceeding downwards level by level. At each level, the polling matching module 104 sequentially traverses each candidate category within the current level's candidate category range, calculates the matching degree between the entity instance and each candidate category (the matching degree can be obtained based on semantic similarity, string similarity, or by using a large language model for scoring), and determines the candidate category with the highest matching degree that is greater than a preset matching threshold as the matching result for the current level. In the implementation method of obtaining the matching degree by using a large language model for scoring, in the "generation-verification-correction" closed loop formed by the polling matching module 104, the attribute verification module 105, and the prompt word generation module 102, the corrected prompt words generated by the prompt word generation module 102 serve as new inputs to the large language model, changing its classification scoring output, thereby making the matching result obtained by re-executing the polling matching different from the previous one, achieving targeted correction of the current level's value; when there is no candidate category within the candidate category range with a matching degree greater than the preset matching threshold, the matching result for the current level is determined to be a miss. Therefore, the polling matching module 104 decomposes the matching task, which originally required a one-time distinction among a large number of semantically similar candidate values, into multiple matchings that converge step by step within a smaller candidate range at each level, thereby reducing the probability of misselection.

[0045] Furthermore, the polling matching module 104 and the attribute verification module 105 work together to perform iterative, step-by-step in-depth matching: after the matching result of the current level passes the constraint verification of the attribute verification module 105, the polling matching module 104 enters the next level candidate category range corresponding to the matching result and continues to perform polling matching until it reaches the leaf category; when the number of retries for re-performing polling matching at the current level reaches the preset repetition threshold and the verification result is still unsuccessful, or the matching result of the current level is a miss, if there is a previous level category at the current level, the polling matching module 104 falls back to the previous level category, excludes the candidate categories that have been determined to be unsuccessful in this instance from the candidate category range corresponding to the previous level category, and then re-performs polling matching; if there is no previous level category at the current level, the error information is recorded and the entity instance is skipped.

[0046] The attribute verification module 105 is used to perform constraint verification on the matching results of the current level according to the attribute definition and obtain the verification result. When the verification result is unsuccessful, the prompt word generation module 102 is triggered to generate a correction prompt word, and the polling matching module 104 and the attribute verification module 105 are triggered to re-execute the polling matching and constraint verification until the verification result is successful or the number of retries reaches the preset repetition threshold. When the verification result is successful, the polling matching module 104 and the attribute verification module 105 are triggered to enter the next level category and repeat the polling matching and constraint verification until the leaf category is reached to obtain the attribute values ​​of the entity instance.

[0047] Specifically, the attribute verification module 105 can be implemented using a rule engine combined with custom verification functions. In some embodiments, the attribute verification module 105 performs verification on the values ​​of scalar attributes and the final values ​​of hierarchical value domain attributes obtained at the leaf categories in a preset order of existence verification, mandatory verification, type conversion verification, range verification, enumeration value verification, and uniqueness verification. For each intermediate-level matching result of the hierarchical value domain attribute, the attribute verification module 105 only verifies whether its matching degree is greater than a preset matching threshold. Existence verification is used to determine whether the matching result contains the attribute; mandatory verification is used to determine whether the attribute is missing when it is marked as mandatory; type conversion verification is used to convert the value according to the data type defined by the attribute (such as toFloat, toString, parseDate) and determine whether the conversion is successful; range verification is used to determine whether the numerical value falls within the min / max range or whether the string meets the regular expression pattern; enumeration value verification is used to determine whether the value is in the allowed enumeration list; uniqueness verification is used to determine whether the value is duplicated with an existing entity within the global or same type of entity scope. If any of the above checks fails, the attribute verification module 105 determines that the verification result is unsuccessful, skips the subsequent checks that have not yet been performed, and records the failed constraint items and their corresponding error information.

[0048] It should be noted that the constraint validation performed by the attribute validation module 105 is adaptively selected according to the current level's position in the hierarchical value domain. For the matching results of intermediate levels (i.e., non-leaf categories), since they represent the category to which the entity instance belongs at that level rather than the final value, the constraint validation mainly includes hit validation (determining whether the matching degree of the matching result is greater than the preset matching threshold) and validity validation (determining whether the matching result belongs to the range of candidate categories allowed by the current level). Only when the polling match reaches a leaf category and it is necessary to determine the specific attribute value of the entity instance, the constraint validation further includes type conversion validation, range validation, enumeration value validation, and uniqueness validation for scalar values. In other words, the preset order of existence validation, mandatory validation, type conversion validation, range validation, enumeration value validation, and uniqueness validation described below is a specific implementation method of constraint validation when leaf-level scalar value validation is involved.

[0049] Furthermore, the attribute verification module 105, the prompt word generation module 102, and the polling matching module 104 form a closed-loop feedback loop: when the verification result is unsuccessful, the attribute verification module 105 feeds back the unsuccessful constraint items and error information to the prompt word generation module 102 to generate corrected prompt words, and triggers the large model interaction module 103 and the polling matching module 104 to re-execute the recognition and polling matching, and then the attribute verification module 105 re-executes the constraint verification, and so on until the verification result is successful or the number of retries reaches the preset repetition threshold; when the verification result is successful, the attribute verification module 105 performs normalization processing on the value (such as unit unification and case standardization), and triggers the polling matching module 104 to enter the next level category to continue execution, until the leaf category is reached, and finally obtains the attribute value of the entity instance and stores it in the verified entity library (for example, storing it with the globally unique identifier GUID as the key and the entity type and attribute value as the value).

[0050] The relation processing module 106 is used to extract the relationship instance between the entity instance and the target entity instance under the target entity type from the text to be processed based on the relation definition.

[0051] Specifically, for each entity instance verified by the attribute verification module 105, the relationship processing module 106 reads the relationship definition corresponding to the entity type provided by the ontology parsing module 101. For each relationship R, if the data returned by the large model interaction module 103 already contains the target instance information of the relationship (e.g., the list of target instance names is given in the relation field of the instance), the relationship processing module 106 extracts it directly from it; if not, the relationship processing module 106 triggers the prompt word generation module 102 to construct a special relationship prompt word for the relationship (e.g., "Given the entity Nimitz (type is surface ship), please list the names and types of carrier-based aircraft instances that have deployment relationships with it"), and obtains the target instance list of the relationship through the large model interaction module 103. The relationship processing module 106 then normalizes the extracted relationship into a unified triple intermediate format (source entity instance, relationship, target entity instance), and supports relationship expressions with various cardinality constraints such as one-to-one, one-to-many, many-to-one, and many-to-many. If the target instance does not yet exist in the verified entity library, the relationship processing module 106 can temporarily store its name and mark it as "to be obtained" for subsequent iteration processing.

[0052] In some embodiments, the loop control function in the knowledge graph construction system 100 is carried out by the relationship processing module 106 (in other embodiments, the loop control function may also be carried out by the polling matching module 104, or by a separately set loop controller, which is not limited in this application). The module carrying the loop control function is used to maintain the queue to be processed: after obtaining the ontology information, the queue to be processed is initialized and the entity type as the starting point for extraction is stored in the queue; after the relationship processing module 106 extracts the relationship instance, when the target entity type does not belong to the queue to be processed or to the set of processed entity types, the target entity type is added to the tail of the queue to be processed; and the next entity type is taken out from the queue to be processed in a first-in-first-out order, triggering the prompt word generation module 102, the large model interaction module 103, the polling matching module 104, the attribute verification module 105 and the relationship processing module 106 to repeat the above processing until the queue to be processed is empty.

[0053] Encapsulation module 107 is used to encapsulate the validated attribute values ​​and relationship instances to obtain a knowledge graph file.

[0054] Specifically, after all entity types have been processed and the relational data is complete, the encapsulation module 107 converts the data in the verified entity database and relational database into standard "subject-verb-object" triples according to the Resource Description Framework (RDF) data model. For entity triples, the encapsulation module 107 generates a type triple (<entity URI>rdf:type<entity type URI>) for each entity instance and an attribute triple (<entity URI><attribute URI><attribute value>) for each attribute value. Attribute values ​​are enclosed in quotes when they are strings and output as literals when they are numbers or dates. URIs can be generated by concatenating from a preset custom namespace (e.g., http: / / kg.example / ). For relation triples, the encapsulation module 107 generates a relation triple (<source entity URI><relationship URI><target entity URI>) for each relation instance. The encapsulation module 107 then serializes these triples according to N-Triples (NT) format (one triple per line ending with a "."), thus obtaining the knowledge graph file.

[0055] Output interface 108 is used to output the knowledge graph file obtained by encapsulation module 107.

[0056] Specifically, output interface 108 can write NT format knowledge graph files to local storage or upload them to a graph database or triplet storage system. Since the knowledge graph file uses the standard N-Triples serialization format, it can be directly loaded, queried, and visualized by mainstream tools such as Apache Jena, RDF4J, and Neo4j (which supports RDF via the n10s plugin), without requiring additional format parsing or conversion. This achieves seamless integration from large language model knowledge extraction to industrial-grade knowledge storage.

[0057] Through the collaborative work of the above modules, the knowledge graph construction system 100 can automatically complete the entire process of ontology parsing, structured prompt word generation, large language model interaction, hierarchical value domain step-by-step polling and matching, multi-dimensional attribute constraint verification, relation instance extraction, and standard triple encapsulation and output based solely on ontology information and topic words (or text to be processed). In particular, through the hierarchical value domain step-by-step polling and matching and the "generation-verification-correction" closed-loop control, the one-time task of distinguishing a large number of semantically similar candidate values ​​is decomposed into multiple small-range matchings that converge at each level. This effectively reduces the probability that the large language model selects values ​​that do not correspond to entity instances, thereby improving the accuracy of attribute value results and the reliability of the constructed knowledge graph.

[0058] The method provided in this embodiment is described in detail below. Please refer to [link / reference]. Figure 2This is a flowchart illustrating a knowledge graph construction method based on iterative knowledge extraction from a large language model, as described in an embodiment of this application.

[0059] S201. Obtain ontology information and text to be processed. Ontology information includes entity type, attribute definition and relation definition corresponding to entity type. Attribute definition includes organizing attribute values ​​into a hierarchical value range from root category to leaf category.

[0060] In this context, ontology information refers to the schema definition used to constrain the knowledge structure in the knowledge graph. It can be expressed using JSONSchema, OWL (Web Ontology Language) files, or other custom structured formats, such as an ontology in the field of military equipment. Entity types represent the categories of objects in the knowledge graph, such as "surface ships" and "carrier-based aircraft." Attribute definitions represent the attributes and constraints of a given entity type, and can include attribute names, data types (such as strings, integers, floating-point numbers, dates, booleans, and enumerations), whether they are required, whether they are unique, and their value range. Relationship definitions represent the associations between entity types, and can include relationship names, source entity types, target entity types, cardinality constraints (one-to-one, one-to-many, many-to-many), and whether they are symmetric. The hierarchical value range refers to organizing the attribute values ​​of a certain attribute into a tree-like multi-level classification structure that is progressively refined from the root category to the leaf categories. The root category represents the coarsest-grained value division, and the leaf categories represent the finest-grained specific values. Each level of category contains several candidate categories. For example, the root category of the attribute "ship type" includes "combat ships" and "auxiliary ships". "Combat ships" expands downwards to "aircraft carriers", "destroyers", etc. The text to be processed refers to the input text that the large language model uses to extract knowledge. In scenarios where extraction is based solely on ontology and keywords, the keywords or the entity instance names obtained in the previous round of extraction can be used.

[0061] This step is executed when the knowledge graph construction process starts. Specifically, the knowledge graph construction system receives the ontology information and text to be processed submitted by the user through the external input interface, parses the ontology information, and converts the entity types, attribute definitions, and relation definitions into a unified data structure within the system. For attributes with a large number of selectable values ​​and similar semantics, the knowledge graph construction system organizes the attribute values ​​into the aforementioned hierarchical value domains during parsing and establishes parent-child expansion relationships between candidate categories at each level for subsequent steps to call level by level.

[0062] S202. Generate structured prompts for entity types based on the attribute and relation definitions corresponding to the entity types.

[0063] Among them, structured prompts refer to text dynamically assembled according to preset templates to guide the large language model to output knowledge in a specified format. It includes at least system setting fields for setting the roles and output specifications of the large language model, entity type requirement fields for constraining the scope of entity recognition, attribute constraint description fields generated based on the data type and constraints of each attribute, relation description fields generated based on the target entity type and direction of each relation, and output format fields for standardizing the form of returned data, such as requiring "displacement to be a floating-point number, unit ton, value ≥ 0, and null if unknown" and specifying the output as a JSON array.

[0064] This step is executed after the knowledge graph construction system obtains the ontology information. Specifically, the knowledge graph construction system reads the entity type E to be processed and all its attribute definitions (P1, P2, ..., Pn) and relation definitions (R1, R2, ..., Rm). It then assembles the attribute name, data type, value range constraint, enumeration range, required field, and uniqueness into attribute constraint description fields, and assembles the relation name, target entity type, and direction into relation description fields. For attributes involving hierarchical value ranges, it also writes the candidate category range included in the current level into the prompt words, thereby generating semantically clear and constraint-complete structured prompt words.

[0065] S203. Input the structured prompts and the text to be processed into the preset large language model, identify the entity instances belonging to the entity type in the text to be processed, and perform polling matching on the entity instances within the candidate category range included in the current level, starting from the root category, according to the hierarchical value range, to obtain the matching result of the current level.

[0066] Among them, the preset large language model refers to a pre-configured model with natural language understanding and generation capabilities. It can be a general large language model (such as GPT, Wenxin Yiyan, and Qianwen) or a domain-specific large language model constructed through fine-tuning or retrieval-augmented generation (RAG) technology. Entity instance refers to a specific object identified by the large language model from the text to be processed and belonging to a certain entity type, such as "Nimitz" belonging to the "surface ship" type. Polling matching refers to the process of comparing entity instances one by one within the candidate categories included in the current level, starting from the root category of the hierarchical value domain, to determine the category to which it belongs. The current level refers to the level in which this polling matching is performed, initially the level of the root category. The matching result refers to the candidate category to which the entity instance determined by the polling matching at this level belongs.

[0067] This step is performed after the knowledge graph construction system generates structured prompts. Specifically, the knowledge graph construction system sends the structured prompts and the text to be processed to a pre-set large language model. It receives the structured data (usually a JSON array) returned by the large language model, and after format parsing and preliminary cleaning, identifies each entity instance belonging to that entity type, along with its attribute values ​​and relational target information. Then, based on the hierarchical value range, it takes the level of the root category as the current level. Within the candidate categories included in the current level, it compares each entity instance one by one to determine the corresponding candidate category, obtaining the matching result for the current level. Thus, the knowledge graph construction system decomposes the task of distinguishing between a large number of semantically similar candidate values ​​all at once into multiple matches that converge progressively within smaller ranges at each level.

[0068] The matching degree can be calculated based on the semantic similarity and string similarity between the entity instance text and the candidate category text. Alternatively, it can be obtained by a large language model classifying and scoring the entity instance within the candidate category range included in the current level. Specifically, the large language model outputs the candidate category to which the entity instance belongs and its corresponding confidence score, using this confidence score as the matching degree. In the implementation using a large language model to score the matching degree, the matching result of the current level depends on the classification output given by the large language model for the current level's candidate category range.

[0069] S204. Perform constraint validation on the matching results of the current level according to the attribute definition to obtain the validation result.

[0070] Constraint validation refers to the process of checking the validity of the matching results at the current level based on attribute definitions. Constraint validation performed on intermediate-level matching results focuses on hit detection and candidate category validity. For scalar values ​​determined by leaf-level matching results, further validations are performed, including type conversion, range, enumeration value, and uniqueness checks. In other words, the specific validation items for constraint validation are adaptively selected based on the current level's hierarchy. The applicable validation items are determined by the current level's position within the hierarchical value domain.

[0071] When the current level is an intermediate level of the hierarchical value domain attribute (i.e., between the root category and the leaf category, but before reaching the leaf category), the constraint validation applies to the hit validation, which determines whether the matching result of the current level is hit - if the matching degree is greater than the preset matching threshold, it is considered a hit and the validation is considered to pass; if the matching degree is not greater than the preset matching threshold, it is considered a miss and the validation is considered to fail.

[0072] When the current level is a leaf category of a hierarchical value domain attribute, or when the current attribute is a scalar attribute without a configured hierarchical value domain, the constraint validation applies to six types of validations: existence, mandatory, type conversion, range, enumeration value, and uniqueness.

[0073] It should be noted that since the intermediate-level matching results are selected from the current level's candidate category range, type conversion checks, range checks, and other checks targeting numerical or string scalar values ​​are not applicable to this type of intermediate-level matching results. Furthermore, enumeration value checks always pass for categories selected from the candidate list. Therefore, intermediate-level constraint checks only perform hit checks. The six types of checks mentioned above are only performed after delving deeper into the leaf categories to obtain the final value of the attribute. Thus, constraint checks are performed at every level, and the checks performed at each level are adapted to the form of the matching results at that level.

[0074] This step is executed after the knowledge graph construction system obtains the matching results for the current level. Specifically, the knowledge graph construction system reads the attribute definitions corresponding to the current entity type and checks each attribute result against the constraints specified in the attribute definitions, such as data type, value range, enumeration range, mandatory content, and uniqueness. When the matching result meets all constraints, the knowledge graph construction system determines the verification result as passed; when the matching result does not meet any constraint, the knowledge graph construction system determines the verification result as failed and can record the constraint that caused the failure and its corresponding error information for use in generating correction prompts later.

[0075] S205. When the verification result is not passed, generate a correction prompt and re-execute polling matching and constraint verification until the verification result is passed or the number of retries reaches the preset repetition threshold.

[0076] Among them, the correction prompt word refers to the prompt word formed by adding correction constraints on the basis of the original structured prompt word for the case that the current verification failed. It is used to guide the large language model to correct its previous output. The preset repetition threshold refers to the maximum number of times that polling matching and constraint verification are allowed to be re-executed for the same matching result. It is used to prevent the process from looping indefinitely due to the large language model repeatedly outputting illegal values. It can be preset by the user according to the trade-off between accuracy and time cost. It is usually set to 2 to 5 times, for example, 3 times.

[0077] This step is executed when the knowledge graph construction system determines that the validation result is unsuccessful. Specifically, after determining that the validation result is unsuccessful, the knowledge graph construction system generates a correction prompt word, re-acquires the output of the entity instance through a preset large language model, and then re-executes constraint validation. For attributes with configured hierarchical value domains, the knowledge graph construction system re-executes polling matching within the candidate category range corresponding to the current level before performing constraint validation; for scalar attributes without configured hierarchical value domains, there is no polling matching of candidate categories, and the knowledge graph construction system re-acquires the scalar value of the attribute based on the correction prompt word and directly re-executes constraint validation, i.e., performing "re-value acquisition and validation" on scalar attributes.

[0078] The knowledge graph construction system checks the validation result and the number of retries after each retry to determine if they have passed and if the preset repetition threshold has been reached.

[0079] If the verification result passes, the retry at this level ends;

[0080] If the verification result still fails but the number of retries has not reached the preset repetition threshold, then continue to repeat the above process of generating correction prompts, polling for matching and constraint verification.

[0081] If the number of retries has reached the preset repetition threshold and the verification result still fails, the knowledge graph construction system stops retries for the current level and processes the entity instance according to the preset failure handling strategy. In some embodiments, the failure handling strategy includes: skipping the current attributes of the entity instance and recording the error information; or, in the case of a configured hierarchical value range, falling back to the previous level category and selecting another candidate category to re-execute the polling matching (see details below). Figure 3 (See the illustrated embodiment). Therefore, the knowledge graph construction system provides definite processing exits for both the "verification failed after retry" and "current level not matched" scenarios, preventing the process from stalling when no matching results are available.

[0082] S206. When the verification result is passed, proceed to the next level category to repeat the polling matching and constraint verification until the leaf category is reached to obtain the attribute values ​​of the entity instance.

[0083] Among them, the next level category refers to the range of candidate categories located at the next level below the current level, which is expanded downward from the candidate categories corresponding to the matching results of the current level; the attribute value refers to the specific value of the entity instance on the attribute that is finally determined after step-by-step polling matching and constraint verification, corresponding to the end value of the value path formed from the root category to the leaf category in the hierarchical value domain.

[0084] This step is executed when the knowledge graph construction system determines that the verification result of the current level is passed. Specifically, after the verification of the current level is passed, the knowledge graph construction system can perform normalization processing on the values ​​(such as unifying units and standardizing capitalization), and take the next level candidate category range corresponding to the matching result of the current level as the new current level, and repeat the polling matching and constraint verification of steps S203 to S205; this is carried out level by level until the current level reaches the leaf category of the hierarchical value domain and passes the verification. The knowledge graph construction system takes the value corresponding to the leaf category as the attribute value of the entity instance, and can store it together with the entity type into the verified entity database (for example, stored with the globally unique identifier GUID as the key).

[0085] S207. Based on the relationship definition, extract the relationship instance between the entity instance and the target entity instance under the target entity type from the text to be processed.

[0086] Among them, the target entity type refers to the entity type of the other end of the relation as specified in the relation definition, such as "surface ships" pointing to "carrier-based aircraft" through the "deployment" relation; the relation instance refers to the specific association established between the entity instance and the specific object under the target entity type, which can be represented as an intermediate format composed of the source entity instance, the relation and the target entity instance.

[0087] This step is executed after the knowledge graph construction system obtains the attribute values ​​of the entity instances. Specifically, for each entity instance whose attribute values ​​have passed validation, the knowledge graph construction system reads the relation definition corresponding to that entity type. For each relation: if the target instance information of the relation is already contained in the data previously returned by the large language model, the knowledge graph construction system extracts it directly from it; if not, the knowledge graph construction system constructs a special relation hint word for that relation and obtains the target instance list of the relation through the preset large language model; then, the knowledge graph construction system normalizes the extracted relations into relation instances composed of source entity instances, relations, and target entity instances, and supports relation expressions with various cardinality constraints such as one-to-one, one-to-many, many-to-one, and many-to-many.

[0088] S208. Encapsulate the validated attribute values ​​and relationship instances to obtain the knowledge graph file.

[0089] Encapsulation refers to the process of converting verified attribute values ​​and relation instances into standard triples according to a predetermined knowledge representation model and serializing them into a file. A knowledge graph file is a file obtained after encapsulation that can be loaded and used by a graph database or triple storage system, such as a file serialized in N-Triples (NT) format using the Resource Description Framework (RDF) data model.

[0090] This step is performed after the knowledge graph construction system obtains the relation instances. Specifically, the knowledge graph construction system converts the validated attribute values ​​and relation instances into "subject-verb-object" triples according to the RDF data model: For each entity instance, it generates its type triple (<entity URI>rdf:type<entity type URI>) and attribute triples corresponding to each attribute value (<entity URI><attribute URI><attribute value>), where attribute values ​​are enclosed in quotes when they are strings and output as literals when they are numbers or dates; for each relation instance, it generates a relation triple (<source entity URI><relation URI><target entity URI>); then, the knowledge graph construction system serializes the above triples line by line according to the N-Triples format and ends with "." to obtain the knowledge graph file, which can be written to local storage or uploaded to a graph database or triple storage system.

[0091] In this embodiment, by organizing attribute values ​​into a hierarchical value range from the root category to the leaf category, polling matching is performed on entity instances within the candidate category range included in the current level starting from the root category. Constraint verification is performed on the matching results of the current level according to the attribute definition. If the verification result fails, a correction prompt word is generated and polling matching and constraint verification are re-executed. If the verification result passes, the process proceeds to the next level category until the leaf category is reached. Therefore, the task of distinguishing between a large number of semantically similar candidate values ​​at once is decomposed into multiple matchings that converge at each level within a small range. The value at each level is checked and corrected step by step. This effectively solves the problem in related technologies where large language models select values ​​that do not correspond to entity instances when distinguishing candidate values ​​in a single matching process. This improves the accuracy of attribute value results and the reliability of the constructed knowledge graph.

[0092] In the above embodiments, the knowledge graph construction system, through hierarchical value domain polling and matching, constraint verification, and a "generation-verification-correction" feedback process, completes the determination of entity instance attribute values ​​and the encapsulation of knowledge graph files. In practical applications, the ontology constructed for certain professional fields often contains multiple interrelated entity types, and during the hierarchical value domain matching process, there may be situations where a certain level of matching result is not hit or fails verification even after multiple corrections and retries.

[0093] Based on the above embodiments, the method provided in this embodiment will be described in further detail below. Please refer to... Figure 3 This is another flowchart illustrating a knowledge graph construction method based on iterative knowledge extraction from a large language model, as described in this application.

[0094] S301. Obtain ontology information and text to be processed. The ontology information includes entity type, attribute definition and relation definition corresponding to entity type. The attribute definition includes organizing attribute values ​​into a hierarchical value range from root category to leaf category.

[0095] Step S301 is similar to step S201 in the above embodiments, and will not be repeated here.

[0096] S302. Initialize the queue to be processed, and store the entity type that is the starting point for extraction in the ontology information into the queue to be processed as the entity type.

[0097] The pending queue is a first-in-first-out queue used to store entity types that have not yet completed knowledge extraction. The knowledge graph construction system uses this pending queue to schedule the processing order of each entity type, thereby achieving a step-by-step in-depth knowledge acquisition similar to breadth-first traversal. The entity type that serves as the starting point for extraction refers to the entity type in the ontology information that is designated as the starting object for this knowledge extraction. It can be explicitly marked by the user in the ontology information, or the knowledge graph construction system can determine the entity type with the highest relevance to the keyword as the starting point. For example, when the keyword "US Navy" is used as the starting point, "surface ships" can be used as the entity type for the starting point of extraction.

[0098] This step is performed after the knowledge graph construction system obtains the ontology information and the text to be processed, but before generating structured prompts. Specifically, after completing the ontology parsing, the knowledge graph construction system creates an initially empty queue to be processed and stores the entity type that serves as the starting point for extraction into this queue.

[0099] In addition, the knowledge graph construction system can also create an initially empty set of processed entity types to record the entity types that have been extracted.

[0100] Subsequently, the knowledge graph construction system retrieves the entity type at the head of the queue as the current entity type to be processed in a first-in-first-out order, and proceeds to the next step S303 to generate structured prompt words for this entity type.

[0101] Therefore, the knowledge graph construction system incorporates the extraction process of each entity type into a unified queue scheduling framework, providing a basis for dynamically adding new target entity types when a relation instance is extracted and processing them in a loop until the queue is empty.

[0102] S303. Generate structured prompts for entity types based on the attribute and relation definitions corresponding to the entity types.

[0103] S304. Input the structured prompts and the text to be processed into the preset large language model, and identify entity instances of entity type in the text to be processed.

[0104] Steps S303 and S304 are similar to those described in the above embodiments as steps S203 and S204, and will not be repeated here.

[0105] S305. Take the level where the root category of the hierarchical value domain is located as the current level, perform polling matching starting from the root category, and sequentially traverse each candidate category within the candidate category range contained in the current level to calculate the matching degree between the entity instance and each candidate category.

[0106] Among them, candidate category refers to the various categories included in a certain level of the hierarchical value domain, which are used for the selection of entity instance affiliation, such as "combat ships" and "auxiliary ships" under the "ship type" attribute root category; candidate category range refers to the set of all candidate categories included in the current level; matching degree is used to represent the degree of consistency between an entity instance and a certain candidate category, and its value can be normalized to between 0 and 1. The higher the matching degree, the more consistent the two are. The matching degree can be calculated based on the semantic similarity (such as vector cosine similarity) and string similarity between the entity instance text and the candidate category text, or by scoring the degree of consistency between the two using a large language model.

[0107] In the implementation of scoring the degree of similarity between two data points using a large language model, when the output of the large language model is a continuous score, the knowledge graph construction system normalizes it to a range of 0 to 1 as the matching degree; when the output of the large language model is a discrete rating (such as high, medium, and low), the knowledge graph construction system quantizes the discrete rating into a value between 0 and 1 according to a preset mapping rule (for example, mapping high, medium, and low to 0.9, 0.6, and 0.3 respectively), so that the matching degree is a floating-point number that can be compared with a preset matching threshold.

[0108] This step is executed after the knowledge graph construction system identifies entity instances belonging to the entity type. Specifically, for each identified entity instance, the knowledge graph construction system sets the level of the root category of the attribute's hierarchical value domain as the current level for each attribute corresponding to that entity instance and configuring hierarchical value domains. It then defines the candidate categories expanding downwards from the root category as the candidate category range for the current level. Furthermore, the knowledge graph construction system sequentially traverses each candidate category within the current level's candidate category range, calculating the matching degree between the entity instance and each candidate category, thus obtaining a set of matching degrees for the entity instance relative to each candidate category at the current level. This set of matching degrees is used by subsequent step S306 to determine the matching result for the current level.

[0109] It should be noted that for attributes without configured hierarchical value domains, the knowledge graph construction system can directly extract and verify their values ​​based on the attribute definition, without performing the above-mentioned step-by-step polling and matching.

[0110] S306. The candidate category with the highest matching degree and greater than the preset matching threshold is determined as the matching result of the current level.

[0111] The preset matching threshold refers to the lower limit of the matching degree used to determine whether a candidate category is sufficiently consistent with an entity instance. Only when the matching degree of a candidate category is greater than the preset matching threshold can it be adopted as a matching result, thereby avoiding the forced selection of a candidate category with a low degree of consistency when the entity instance does not match any of the candidate categories. The preset matching threshold can be preset by the user according to the accuracy of matching and recall needs, and is usually set between 0.6 and 0.85. For example, setting it to 0.75 will result in stricter adoption and a lower probability of misselection, but the probability of missing will increase accordingly.

[0112] This step is performed after the knowledge graph construction system calculates the matching degree between the entity instance and each candidate category at the current level. Specifically, the knowledge graph construction system compares the matching degree of each candidate category at the current level, selects the candidate category with the highest matching degree, and compares this highest matching degree with a preset matching threshold: when the highest matching degree is greater than the preset matching threshold, the knowledge graph construction system determines the candidate category with the highest matching degree as the matching result for the current level, and provides this matching result to step S308 for constraint verification.

[0113] When multiple candidate categories have the highest matching degree, the knowledge graph construction system can further combine the default priority of the candidate categories in the hierarchical value domain or use methods such as re-judgment by a large language model to select one.

[0114] S307. When there are no candidate categories within the candidate category range with a matching degree greater than the preset matching threshold, the matching result of the current level is determined to be a no match.

[0115] "Missed" means that there is no candidate category within the current level that sufficiently matches the entity instance, indicating that the entity instance cannot be classified into any candidate category at the current level.

[0116] This step is performed after the knowledge graph construction system has completed the comparison of the matching degree of each candidate category at the current level. Specifically, when the knowledge graph construction system determines that the matching result of the current level is not a match if the matching degree of each candidate category within the current level is not greater than the preset matching threshold, the matching result of the current level is determined to be not a match.

[0117] Since a no-match means there are no matching results available for subsequent constraint verification at the current level, the knowledge graph construction system no longer performs constraint verification in step S308 at the current level, but instead directly proceeds to the rollback process in step S311:

[0118] If the current level has a parent category, then fall back to the parent category and re-execute the polling matching;

[0119] If the current level is the same as the root category and there is no parent category, then the error message is recorded and the entity instance is skipped.

[0120] Therefore, the knowledge graph construction system avoids forcibly obtaining incorrect attribute values ​​when the entity instance and the candidate category do not match through miss detection and subsequent rollback processing, thus ensuring the accuracy of the attribute value results.

[0121] S308. Perform verification on the matching results of the current level in the preset order of existence verification, mandatory verification, type conversion verification, range verification, enumeration value verification and uniqueness verification.

[0122] Among them, existence verification refers to checking whether the matching results at the current level contain the attribute to be verified; mandatory verification refers to checking whether the attribute to be verified is missing when it is marked as mandatory; type conversion verification refers to converting the matching results according to the data type defined by the attribute (such as toFloat, toString, parseDate) and checking whether the conversion is successful; range verification refers to checking whether the numerical value falls within the min / max range defined by the attribute, or whether the string value meets the preset regular expression pattern; enumeration value verification refers to checking whether the value is in the enumeration list allowed by the attribute definition; uniqueness verification refers to checking whether the value is duplicated with an existing entity within the global or same entity type range; the preset order refers to the order in which the above six types of verifications are executed, which are arranged according to the principle of verification cost from low to high and dependency relationship from front to back, so that the verification with low cost and the verification that is depended on by subsequent verifications are executed first.

[0123] This step is executed after the knowledge graph construction system obtains the matching results for the current level. Of the six types of checks mentioned above, existence and hit checks apply to matching results at all levels, while type conversion, range, enumeration value, and uniqueness checks are mainly applicable when reaching leaf categories and determining scalar attribute values. For intermediate-level matching results, the knowledge graph construction system skips scalar checks that are not applicable and only executes checks applicable to that level. Specifically, the knowledge graph construction system reads the attribute definitions corresponding to the current entity type and performs these checks item by item on the current-level matching results in a preset order: existence, mandatory, type conversion, range, enumeration value, and uniqueness checks. Since subsequent checks are usually contingent on the success of previous checks (e.g., range checks require successful type conversion), the knowledge graph construction system executes these checks sequentially in this preset order. This allows for the early detection of invalid values ​​while avoiding meaningless checks on values ​​that do not yet meet the verification conditions, thereby improving verification efficiency.

[0124] It should be noted that for attributes configured with hierarchical value ranges, the matching results of each intermediate level are categories selected from the candidate category range. Type conversion checks, range checks, and other checks targeting numerical or string scalar values ​​are not meaningful for the matching results of this type of intermediate level, and enumeration value checks always pass for categories selected from the candidate list. Therefore, for attributes configured with hierarchical value ranges, the knowledge graph construction system only determines the hit at each intermediate level based on whether the matching degree is greater than the preset matching threshold (i.e., steps S306 and S307). After delving deeper into the leaf categories and obtaining the final value of the attribute, constraint checks are then performed on the final value in the aforementioned preset order.

[0125] S309. During the process of performing the above validation on the final value of the leaf category of the scalar attribute or the hierarchical value domain attribute, if any of the validations of existence, mandatory content, type conversion, range, enumeration value and uniqueness fails, the validation result is determined to be unsuccessful, and the subsequent validations that have not yet been performed are skipped.

[0126] When all checks performed in the preset order pass, the check result is determined to be passed.

[0127] Among them, the constraint item refers to the specific constraint condition specified in the attribute definition and checked by one of the above checks, such as "data type is floating point", "value range ≥ 0", "enumeration range is United States / China / Russia / United Kingdom", etc.; the error message refers to the information describing the reason why the constraint item failed, such as "the country value 'in service' is not within the allowed enumeration range".

[0128] This step is performed during the constraint validation process in the knowledge graph construction system according to a preset order. Specifically, when the knowledge graph construction system performs validation item by item in the preset order, if a validation fails, the system determines that the validation result is failed, records the failed constraint item and its corresponding error information, and skips subsequent unexecuted validations, without continuing to check downwards; when all validations performed in the preset order pass, the knowledge graph construction system determines that the validation result is passed.

[0129] By adopting the above-mentioned method of "short-circuiting and skipping subsequent checks if any value fails", the knowledge graph construction system avoids the overhead caused by performing subsequent checks after the value has been determined to be invalid. On the other hand, the recorded failed constraints and error information can serve as the basis for generating correction prompts in the subsequent step S310, making the correction more targeted.

[0130] If the verification result is unsuccessful, proceed to step S310; if the result is successful, proceed to step S312.

[0131] The verification results include the failed constraints and the corresponding error messages.

[0132] S310. When the validation result is unsuccessful, based on the unsuccessful constraint items and the corresponding error information, a correction constraint field is added to the structured prompt words to generate correction prompt words. Then, based on the correction prompt words, the current level of polling matching and constraint validation is re-executed until the validation result is successful or the number of retries reaches the preset repetition threshold.

[0133] Among them, the correction constraint field refers to the constraint description generated for the failed constraint items and their error messages, which is used to guide the large language model to correct the previous output. For example, "The country value returned last time is not within the allowed range. Please select only from the United States / China / Russia / United Kingdom". The preset repetition threshold refers to the maximum number of times that polling matching and constraint verification are allowed to be re-executed for the current level. It is used to prevent the process from looping indefinitely due to the large language model repeatedly outputting illegal values. It can be preset by the user according to the trade-off between accuracy and time cost. It is usually set to 2 to 5 times, for example, 3 times.

[0134] This step is executed when the knowledge graph construction system determines that the current level's verification result is failed. Specifically, the knowledge graph construction system reads the failed constraint items and their error information recorded in step S309, adds corresponding correction constraint fields to the original structured prompt words, and generates correction prompt words.

[0135] The knowledge graph construction system then inputs the correction prompts along with the candidate category range included in the current level into a preset large language model. The large language model then retrieves the output of the entity instance at the current level based on the correction prompts and re-executes the polling matching (i.e., steps S305 and S306) and constraint verification at the current level for that output. It should be noted that the polling matching and rollback processing described in steps S305 to S307 and S311 are for attributes with configured hierarchical value domains. For scalar attributes without configured hierarchical value domains, when the verification fails, the knowledge graph construction system only retrieves the scalar value based on the correction prompts and re-executes the constraint verification in steps S308 and S309, without involving polling matching and step-by-step rollback of candidate categories.

[0136] It should be noted that the above "re-acquiring the output of the entity instance at the current level" does not mean recalculating on the exact same input:

[0137] The correction prompt clearly indicates the constraints under which the previous output was invalid and the reason for it. As a new input to the large language model, the correction prompt changes the constraint information on which the large language model is based, so that the content output by the large language model (including the candidate category to which the entity instance belongs in the current level, the score of each candidate category, or the normalized representation of the entity instance) is different from the previous one.

[0138] The matching degree and matching result obtained by the re-execution of the polling matching are also changed accordingly, thereby avoiding idling on the same matching result during retries, and making the error correction process of "generation-verification-correction" equally effective on the hierarchical value domain attribute.

[0139] After each retry, the knowledge graph construction system determines whether the validation result passes and whether the number of retries for the current level has reached the preset repetition threshold.

[0140] If the verification result is successful, the current retry will end and the process will proceed to step S312.

[0141] If it still fails but the number of retries has not yet reached the preset repetition threshold, then continue to repeat the above process of generating correction prompts, polling for matching and constraint verification.

[0142] If the number of retries has reached the preset repetition threshold and the verification result still fails, then stop the retries at this level and proceed to the rollback process in step S311.

[0143] Furthermore, for cases where the matching degree is calculated using deterministic methods such as semantic similarity and string similarity, and the matching result remains unchanged after retrying with corrected prompts, the knowledge graph construction system proceeds to the failure rollback process in step S311 after the number of retries reaches a preset repetition threshold, rolling back to the next higher-level category to select another feasible path. Thus, the "corrected prompt rematch" and "failure rollback" mechanisms complement each other, jointly ensuring that step-by-step matching converges under various matching degree calculation methods.

[0144] S311. When the number of retries for re-executing polling matching at the current level reaches the preset repetition threshold and the verification result is still unsuccessful, or the matching result at the current level is a miss:

[0145] If a parent category exists in the current category, then fall back to the parent category. Within the candidate category range corresponding to the parent category, exclude the candidate categories that have been determined to fail in the current verification result, and re-execute the polling matching to obtain the matching result of the parent category.

[0146] If the current level does not have a parent category, an error message is logged and the entity instance is skipped.

[0147] Among them, the upper-level category refers to the category level in the hierarchical value domain that is one level above the current level and whose candidate category expands downward to form the scope of candidate categories in the current level; recording error information means recording the situation where a legal attribute value cannot be determined for the entity instance and the related reasons, for subsequent investigation.

[0148] This step is executed when the knowledge graph construction system determines that the current level's retries have reached a preset repetition threshold and the verification still fails, or when the current level's matching result is a no-match. Specifically, the knowledge graph construction system first determines whether the current level has a parent category:

[0149] If a parent category exists at the current level, the knowledge graph construction system reverts to the parent category. Within the candidate category range corresponding to the parent category, it excludes the candidate category that, after being expanded downwards, forms the candidate category range for the current level (i.e., the candidate category selected at the parent level that leads to its inclusion at the current level, but which the current level cannot match or fails the validation). It then re-executes the polling matching within the remaining candidate category range to obtain the matching result for the parent category. The polling matching in steps S305 and S306 is then re-executed within the remaining candidate category range to obtain the matching result for the parent category. This matching result is then transferred back to step S308 for constraint validation and subsequent progressively deeper processing.

[0150] If the current level does not have a parent category (i.e., the current level has fallen back to the level of the root category but still cannot be found or pass the verification), the knowledge graph construction system records the error information corresponding to the entity instance and skips the entity instance, and will no longer determine the value of the attribute for it.

[0151] Therefore, the knowledge graph construction system improves the success rate and accuracy of attribute value retrieval by backtracking step by step and excluding failed candidate categories, and by choosing other feasible paths when a certain value retrieval path is not feasible.

[0152] S312. When the verification result is passed, proceed to the next level category to repeat the polling matching and constraint verification until the leaf category is reached to obtain the attribute values ​​of the entity instance.

[0153] S313. Based on the relation definition, extract the relationship instance between the entity instance and the target entity instance under the target entity type from the text to be processed.

[0154] Steps S312 and S313 are similar to steps S206 and S207 in the above embodiments, and will not be repeated here.

[0155] S314. If the target entity type does not belong to the entity types in the queue to be processed, add the target entity type to the tail of the queue to be processed.

[0156] The tail of the queue refers to the last end of the queue to be processed. Newly added entity types are placed at the tail to ensure that the first ones added are processed in a first-in, first-out (FIFO) order.

[0157] This step is executed after the knowledge graph construction system extracts the relationship instances between entity instances and target entity types. Specifically, for the target entity type involved in the extracted relationship instances, the knowledge graph construction system determines whether the target entity type already exists in the pending queue and whether it already exists in the set of processed entity types:

[0158] When the target entity type is neither a type of entity in the queue to be processed nor a type of entity that has been processed, the knowledge graph construction system adds the target entity type to the tail of the queue to be processed, so that it can be retrieved and knowledge extraction can be performed on it later.

[0159] When the target entity type already exists in the queue to be processed or the set of processed entity types, the knowledge graph construction system will not add it again, thereby avoiding the same entity type being repeatedly enqueued, which would lead to processing redundancy or getting stuck in an infinite loop.

[0160] For example, when processing "surface ships", the knowledge graph construction system extracts the "carrier-based aircraft" that it points to through the "deployment" relationship. If the "carrier-based aircraft" has not yet joined the queue and has not been processed, the "carrier-based aircraft" is added to the tail of the queue to be processed.

[0161] S315. Retrieve the next entity type from the queue in a first-in-first-out order. Repeat the generation of structured prompts, identification of entity instances, polling matching, constraint verification, and extraction of relation instances for the retrieved entity type until the queue is empty.

[0162] The next entity type refers to the entity type that should be taken from the head of the queue and processed in a first-in-first-out (FIFO) order.

[0163] This step is executed after the knowledge graph construction system completes the extraction of relation instances of the current entity type and the enqueueing of the target entity type. Specifically, the knowledge graph construction system adds the currently processed entity type to the set of processed entity types, and then checks whether the queue to be processed is empty: if the queue to be processed is not empty, the knowledge graph construction system takes the next entity type from the head of the queue in a first-in-first-out order as the new current entity type, and returns to step S303. For the retrieved entity type, the system repeatedly performs the following processes: generation of structured prompt words (S303), identification of entity instances (S304), step-by-step polling and matching from the root category (S305 to S307), constraint verification (S308, S309), correction retry and rollback (S310, S311), step-by-step exploration until the leaf category obtains the attribute values ​​(S312), and extraction of relation instances (S313). Then, according to step S314, the newly appearing target entity type is added to the tail of the queue. This process is repeated until the queue to be processed is empty. Therefore, the knowledge graph construction system uses a breadth-first traversal approach, starting from the entity type at the extraction point and gradually expanding to all related entity types in the ontology, thus avoiding knowledge omissions and relationship chain breaks.

[0164] It should be noted that the aforementioned hierarchical value range polling matching is mainly used to improve the accuracy of individual attribute value results, while the breadth-first iteration mechanism based on the queue to be processed in this step is used to solve the problems of knowledge omission and relationship chain breakage: after extracting relationship instances, the knowledge graph construction system dynamically adds newly emerging target entity types to the queue and processes them in a loop, expanding from the extraction starting point to each associated entity type in the ontology. Both improve the quality of the constructed knowledge graph from the aspects of value accuracy and knowledge completeness, respectively.

[0165] S316. When the queue to be processed is empty, the knowledge graph file is obtained by encapsulating the verified attribute values ​​and relationship instances.

[0166] This step is executed after the knowledge graph construction system determines that the processing queue is empty, meaning that knowledge extraction has been completed for all entity types. Specifically, when the processing queue is empty, the knowledge graph construction system assumes that the current knowledge extraction process has fully covered all related entity types in the ontology. It then converts the validated attribute values ​​in the verified entity database and the relation instances in the relational database into "subject-verb-object" triples according to the Resource Description Framework (RDF) data model.

[0167] For each entity instance, the knowledge graph construction system generates its type triple (<entity URI>rdf:type<entity type URI>) and attribute triples corresponding to each attribute value (<entity URI><attribute URI><attribute value>). Attribute values ​​are enclosed in quotes when they are strings, and output as literals when they are numbers or dates. URIs can be based on preset custom namespaces (e.g., ...). <Source Entity URI><Relationship URI><Target Entity URI>). Then, the knowledge graph construction system serializes the above triples line by line according to the N-Triples (NT) format and ends with a "." to obtain a knowledge graph file. This file can be written to local storage or uploaded to a graph database or triple storage system for subsequent loading, querying, and visualization.

[0168] In this embodiment, the matching degree of each level of matching is controlled by a preset matching threshold and a miss judgment in the hierarchical value domain polling matching. When the number of retries reaches the preset repetition threshold and the verification still fails or the matching result is a miss, the process reverts to the previous level category and excludes the candidate categories that have been determined to fail before re-executing the polling matching. The process performs multi-dimensional constraint verification in a preset order and adds correction constraint fields based on the failed constraint items and error information to generate correction prompt words. Furthermore, the target entity type is added to the tail of the queue and processed in a first-in-first-out order. Therefore, the one-time differentiation task of candidate values ​​is decomposed into hierarchical convergence matching and the misselection in hierarchical matching is corrected. It also fully covers all related entity types, effectively solving the problems of inaccurate values ​​due to the large number of candidate values ​​and their similar semantics, as well as knowledge omissions and relationship chain breaks due to only processing the starting entity type. This improves the accuracy of attribute value results and the reliability of the constructed knowledge graph.

[0169] To more clearly illustrate the execution process of the above method, the following example uses the construction of a weapon and equipment knowledge graph around the keyword "U.S. Navy" as an example, combined with... Figure 4 This describes one running example. Please refer to [link / reference]. Figure 4 The diagram is a timing diagram of an example of operation in this application. The timing diagram shows the interaction process and internal processing process between the knowledge graph construction system and the preset large language model from time T0 to T9.

[0170] In this example, the ontology information submitted by the user includes two entity types: "Surface Ships" and "Carrier-based Aircraft". The attributes for "Surface Ships" include: "Name" (string, required, unique), "Displacement" (floating-point number, in tons, value range ≥ 0), "Country of Origin" (enumerated value, allowed values ​​are USA / China / Russia / UK), and "Ship Type". "Ship Type" is configured as a hierarchical value domain, with its root category containing "Combat Ships" and "Auxiliary Ships". Under the root category, "Combat Ships" expands downwards to "Aircraft Carriers", "Destroyers", "Frigides", and "Amphibious Ships". "Aircraft Carriers" further expands downwards to leaf categories such as "Enterprise-class", "Nimitz-class", and "Ford-class". "Surface Ships" also defines a "Deployment" relationship (one-to-many) pointing to "Carrier-based Aircraft". In this example, the preset matching threshold is set to 0.75, and the preset duplicate threshold is set to 3.

[0171] At time T0: The knowledge graph construction system receives the above ontology information and the keyword "US Navy" submitted by the user through the input interface, and parses the ontology information, organizing the candidate categories of the "ship type" attribute into hierarchical value domains according to the parent-child expansion relationship (corresponding to step S301).

[0172] Time T1: The knowledge graph construction system initializes a queue to be processed and a set of processed entity types, and stores the entity type "surface ships" as the starting point for extraction into the queue to be processed. At this time, the queue to be processed is "surface ships".

[0173] At time T2: The knowledge graph construction system retrieves the "surface ships" at the head of the queue in first-in-first-out order, generates structured prompts based on the attribute and relation definitions of the ships, and sends the structured prompts and the text to be processed (here, the keyword "US Navy" is used) to the preset large language model (corresponding to steps S303 and S304).

[0174] At time T3: The pre-defined large language model returns a JSON array, one element of which is {"entity_name":"Nimitz","displacement":100000,"country":"United States","ship type":"Nimitz-class nuclear-powered aircraft carrier","relations":{"deployment":[{"target_name":"F-35"}]}}. The knowledge graph construction system performs format parsing and preliminary cleaning on the returned data, identifying the entity instance "Nimitz" belonging to the "surface ship" type.

[0175] Time T4:

[0176] At time T4a (Attribute Constraint Verification and Correction Retry): The knowledge graph construction system sequentially performs constraint verification on the scalar attributes of "Nimitz". For "Country of Origin", during the enumeration value verification, it is found that the value "United States" is not within the allowed enumeration range, and the verification result is determined to be unsuccessful. The unsuccessful constraint item ("Country of Origin Enumeration Range is United States / China / Russia / United Kingdom") and the error message ("Value 'United States' is not within the allowed range") are recorded, and subsequent verifications are skipped (corresponding to steps S308 and S309). Then, based on this constraint item and error message, the knowledge graph construction system adds the correction constraint field "The previously returned Country of Origin value is not within the allowed range, please select only from United States / China / Russia / United Kingdom" to the original structured prompt word, generates the correction prompt word and re-acquires it through the large language model. The large language model returns "United States", and the re-verification passes (corresponding to step S310).

[0177] At time T4b (hierarchical value domain progressive polling matching): For the "ship type" attribute configured as a hierarchical value domain, the knowledge graph construction system takes the level of the root category as the current level, and sequentially traverses the candidate categories ["combat ships" and "auxiliary ships"] of the current level, calculates the matching degree between "Nimitz" and each candidate category (0.90 and 0.15 in this example, respectively), and determines "combat ships" with the highest matching degree and greater than the preset matching threshold of 0.75 as the matching result of the current level and passes the constraint verification (corresponding to steps S305 to S308); then it moves to the next level, expanding the candidate categories ["aircraft carriers", "destroyers", "escorts"] of "combat ships" Within the categories of "frigate" and "amphibious ships", a polling and matching process is re-executed. The "aircraft carrier" category has the highest matching score of 0.94, which is greater than the threshold. It is determined to be the matching result for this level and passes the verification. The process then proceeds to the next level and performs polling and matching within the categories of "enterprise class", "Nimitz class", and "Ford class". The "Nimitz class" category has the highest matching score of 0.91, which is greater than the threshold. It is determined to be the matching result for this level and passes the verification. At this point, the system has reached the leaf category. The knowledge graph construction system uses "Nimitz class" as the "ship type" attribute value for "Nimitz" and stores "Nimitz" along with its attribute values ​​in the verified entity database using a globally unique identifier as the key (corresponding to step S312).

[0178] It should be noted that in another operational instance, if a semantically ambiguous surface warship entity instance is initially matched to "destroyer" under "combat ships," but after entering the next level of candidate categories expanded from "destroyer," the matching degree of each candidate category is not greater than the preset matching threshold, then the knowledge graph construction system determines that the matching result at this level is a miss. Since there is a higher-level category at the current level, the knowledge graph construction system falls back to the higher-level category, excludes the previously determined "destroyer" from ["aircraft carrier," "destroyer," "frigate," "amphibious ship"], and re-executes the polling matching, thereby changing the match to "frigate" and continuing to delve deeper level by level; if falling back to the root category level still fails to match or pass the verification, the knowledge graph construction system records the error information and skips the entity instance (corresponding to steps S307 and S311). This demonstrates the processing process that combines hierarchical value domain step-by-step polling matching with failure fallback.

[0179] At time T4 (relation extraction): The knowledge graph construction system reads the "deployment" relation definition corresponding to "surface ships", extracts the target instance "F-35" pointed to by "Nimitz" through the "deployment" relation from the relations field of the data returned by the large language model, normalizes it into a relation instance (Nimitz, deployment, F-35), and stores it in the relation database as a one-to-many cardinality; since the target instance "F-35" does not yet exist in the verified entity database, the knowledge graph construction system temporarily stores its name and marks it as to be retrieved (corresponding to step S313).

[0180] At time T5: The knowledge graph construction system determines that the target entity type "carrier-based aircraft" in the extracted relation instance does not belong to either the pending queue or the set of processed entity types. Therefore, "carrier-based aircraft" is added to the tail of the pending queue, and the pending queue is now ["carrier-based aircraft"]. At the same time, the "surface ships" that have been processed are added to the set of processed entity types (corresponding to step S314).

[0181] At time T6: The knowledge graph construction system determines that the queue to be processed is not empty, retrieves the "carrier-based aircraft" at the head of the queue in first-in-first-out order, generates structured prompt words based on its attribute definition (such as requesting the return of attributes such as "model", "maximum takeoff weight", and "combat radius"), and sends them to the preset large language model (corresponding to step S315 returning to S303 and S304).

[0182] Time T7: The preset large language model returns {"entity_name":"F-35","maximum takeoff weight":31.8,"combat radius":1160}.

[0183] At time T8: The knowledge graph construction system performs constraint verification on each attribute of "F-35" (and performs step-by-step polling matching from the root category on the same way for attributes with hierarchical value ranges). After the verification is passed, "F-35" is stored in the verified entity library. If "carrier-based aircraft" does not define a relationship pointing to other unprocessed entity types, no new target entity types will be added to the queue (corresponding to steps S312, S313, and S314).

[0184] At time T9: The knowledge graph construction system determines that the queue to be processed is empty, and assumes that the knowledge extraction has fully covered all entity types in the ontology, starting from "surface ships" and associated through the "deployment" relationship, such as "carrier-based aircraft". Therefore, it converts the verified attribute values ​​in the entity database and the relation instances in the relation database into "subject-verb-object" triples according to the Resource Description Framework (RDF) data model. For example, it generates a type triple (<Nimitz URI>rdf:type<surface ship URI>) and attribute triples (<Nimitz URI><ship type URI>"Nimitz-class") and (<Nimitz URI><displacement URI>100000) for "Nimitz", and generates relation triples (<Nimitz URI><deployment URI>) for relation instances. <f-35uri>Then, the above triples are serialized line by line in N-Triples (NT) format and ended with "." to obtain the knowledge graph file, which is then written to local storage or uploaded to a graph database or triple storage system (corresponding to step S316).

[0185] Thus, the knowledge graph construction system, based solely on ontology information and the keyword "US Navy," automatically extracts knowledge from related entity types such as "surface ships" and "carrier-based aircraft" through hierarchical value domain polling and matching, multi-dimensional constraint verification and correction retry, failure rollback, and breadth-first iteration based on the queue of pending processing. Finally, it encapsulates the knowledge into a standard knowledge graph file, improving the accuracy of attribute value results while avoiding knowledge omissions and relationship chain breaks.

[0186] The knowledge graph construction system in this application embodiment is described below from the perspective of hardware processing.

[0187] In some embodiments, the knowledge graph construction system includes a CPU that can perform various appropriate actions and processes based on a program stored in a read-only memory (ROM) or a program loaded from a storage portion into a random access memory (RAM), such as performing the methods described in the above embodiments. Various programs and data required for system operation are also stored in the RAM. The CPU, ROM, and RAM are interconnected via a bus. I / O interfaces are also connected to the bus.

[0188] The following components are connected to the I / O interface: input sections including audio input devices, push-button switches, etc.; output sections including liquid crystal displays (LCDs), audio output devices, indicator lights, etc.; storage sections including hard drives, etc.; and communication sections including network interface cards such as LAN (Local Area Network) cards and modems. The communication sections perform communication processing via networks such as the Internet. Drives are also connected to the I / O interface as needed. Removable media, such as disks, optical discs, magneto-optical discs, semiconductor memories, etc., are installed on the drive as needed so that computer programs read from them can be installed into the storage section as required.

[0189] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication component, and / or installed from a removable medium. When the computer program is executed by the CPU, it performs the various functions defined in this application.

[0190] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0191] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0192] Specifically, the knowledge graph construction system of this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the knowledge graph construction method based on iterative knowledge extraction of a large language model provided in the above embodiment.

[0193] In another aspect, this application also provides a computer-readable storage medium, which may be included in the knowledge graph construction system described in the above embodiments; or it may exist independently and not assembled into the knowledge graph construction system. The storage medium carries one or more computer programs, which, when executed by a processor of the knowledge graph construction system, enable the knowledge graph construction system to implement the knowledge graph construction method based on iterative knowledge extraction from a large language model provided in the above embodiments.

[0194] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0195] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if..." or "after..." or "in response to determining..." or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining..." or "in response to determining..." or "when (the stated condition or event) is detected" or "in response to detecting (the stated condition or event)".

[0196] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A knowledge graph construction method based on iterative knowledge extraction from a large language model, applied to a knowledge graph construction system, characterized in that, include: Obtain ontology information and text to be processed. The ontology information includes entity type, attribute definition and relation definition corresponding to the entity type, and the attribute definition includes organizing attribute values ​​into a hierarchical value range from root category to leaf category. Based on the attribute and relationship definitions corresponding to the entity type, generate structured prompt words corresponding to the entity type; The structured prompts and the text to be processed are input into a preset large language model to identify entity instances in the text to be processed that belong to the entity type. Based on the hierarchical value range, polling and matching are performed on the entity instances within the candidate category range included in the current level, starting from the root category, to obtain the matching result of the current level. Based on the attribute definition, constraint validation is performed on the matching results of the current level to obtain the validation result; When the verification result is failed, a correction prompt is generated and the polling matching and constraint verification are re-executed until the verification result is passed or the number of retries reaches the preset repetition threshold. When the verification result is passed, the polling matching and constraint verification are repeated in the next level category until the leaf category is reached to obtain the attribute values ​​of the entity instance. Based on the relationship definition, extract the relationship instance between the entity instance and the target entity instance under the target entity type from the text to be processed; The knowledge graph file is obtained by encapsulating the verified attribute values ​​and the relationship instances.

2. The method according to claim 1, characterized in that, Based on the hierarchical value range, the entity instances are polled and matched within the candidate category range included in the current level, starting from the root category, to obtain the matching result of the current level. Specifically, this includes: Iterate through each candidate category within the current level and calculate the matching degree between the entity instance and each candidate category. The candidate category with the highest matching degree and greater than the preset matching threshold is determined as the matching result of the current level; When there are no candidate categories within the candidate category range with a matching degree greater than the preset matching threshold, the matching result of the current level is determined to be a miss.

3. The method according to claim 2, characterized in that, When the verification result is unsuccessful, the polling matching is re-executed, specifically including: If the number of retries for re-executing the polling match at the current level reaches the preset repetition threshold and the verification result is still unsuccessful, or the matching result at the current level is a miss: If the current level has a parent category, then fall back to the parent category. Within the candidate category range corresponding to the parent category, exclude the candidate categories that have been determined to fail in the current verification result, and re-execute the polling matching to obtain the matching result of the parent category. If the current level does not have a parent category, then the error message is recorded and the entity instance is skipped.

4. The method according to claim 1, characterized in that, The step of performing constraint validation on the matching results of the current level according to the attribute definition to obtain the validation result includes: The matching results of the current level are checked sequentially according to the preset order of existence check, mandatory check, type conversion check, range check, enumeration value check and uniqueness check. If any of the existence check, the required field check, the type conversion check, the range check, the enumeration value check, and the uniqueness check fails, the check result is determined to be failed, and subsequent checks that have not yet been performed are skipped.

5. The method according to claim 4, characterized in that, The verification result includes the failed constraint items and the corresponding error information for the constraint items; When the verification result is "failed", a correction prompt is generated, specifically including: Based on the failed constraint items and the corresponding error information, a correction constraint field is added to the structured prompt word to generate the correction prompt word.

6. The method according to claim 1, characterized in that, After obtaining the ontology information and the text to be processed, the method further includes: Initialize the queue to be processed, and store the entity type that serves as the starting point for extraction from the ontology information into the queue as the entity type.

7. The method according to claim 6, characterized in that, After extracting the relationship instance between the entity instance and the target entity instance under the target entity type from the text to be processed based on the relationship definition, the method further includes: When the target entity type does not belong to the entity types in the queue to be processed, the target entity type is added to the tail of the queue to be processed; The next entity type is retrieved from the queue to be processed in a first-in-first-out (FIFO) order. For the retrieved entity type, the generation of structured prompt words, the identification of entity instances, the polling matching, the constraint verification, and the extraction of relation instances are repeated until the queue to be processed is empty.

8. A knowledge graph construction system, characterized in that, The knowledge graph construction system includes: The ontology parsing module is used to obtain ontology information and text to be processed. The ontology information includes entity type, attribute definition and relation definition corresponding to the entity type. The attribute definition includes organizing attribute values ​​into a hierarchical value range from root category to leaf category. The prompt word generation module is used to generate structured prompt words corresponding to the entity type based on the attribute definition and relationship definition corresponding to the entity type; The large model interaction module is used to input the structured prompt words and the text to be processed into a preset large language model, and identify entity instances in the text to be processed that belong to the entity type; The polling matching module is used to perform polling matching on the entity instance within the candidate category range included in the current level, starting from the root category, based on the hierarchical value range, to obtain the matching result of the current level; The attribute verification module is used to perform constraint verification on the matching results of the current level according to the attribute definition, and obtain the verification result; when the verification result is unsuccessful, the prompt word generation module is triggered to generate a correction prompt word, and the polling matching module and the attribute verification module are triggered to re-execute the polling matching and constraint verification until the verification result is successful or the number of retries reaches a preset repetition threshold; when the verification result is successful, the polling matching module and the attribute verification module are triggered to enter the next level category and repeat the polling matching and constraint verification until the leaf category is reached to obtain the attribute value of the entity instance; The relationship processing module is used to extract, based on the relationship definition, the relationship instance between the entity instance and the target entity instance under the target entity type from the text to be processed; The encapsulation module is used to encapsulate the verified attribute values ​​and the relationship instances to obtain a knowledge graph file.

9. A computer-readable storage medium storing computer instructions, characterized in that, When the computer instructions are run on the knowledge graph construction system, the knowledge graph construction system performs the method as described in any one of claims 1-7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is run on the knowledge graph construction system, the knowledge graph construction system performs the method as described in any one of claims 1-7.

Images