An entity relationship network analysis method and system based on a knowledge graph

Abstract

This invention relates to the field of data analysis technology, specifically disclosing a method and system for entity relationship network analysis based on knowledge graphs. The method includes: acquiring entities to be normalized; comparing evidence items item by item between any two entities to be normalized; merging the entities to be normalized into a normalized entity; generating relationship edges; registering the number of supporting evidence items, the number of independent sources, the evidence time interval, and other connected paths for each relationship edge; labeling the relationship strength level; determining whether the supporting paths are independent of each other; performing removal recalculation for each supporting path; encapsulating the evidence chain; and outputting the entity relationship network analysis results. This method solves the problems of entity recognition lacking robustness to homonyms, abbreviation variants, noisy characters, and attributes; entity alignment using static thresholds that cannot be dynamically calibrated; and relationship construction being unable to characterize high-order implicit relationships formed by spatiotemporal co-occurrence and event coupling.

Description

Technical Field

[0001] This invention relates to the field of data analysis technology, specifically to a method and system for entity relationship network analysis based on knowledge graphs. Background Technology

[0002] In scenarios such as business operations, financial regulation, and project management, business data is typically scattered across multiple systems, tables, interfaces, documents, and logs. Different data sources exhibit significant heterogeneity in namespaces, encoding systems, field sparsity, temporal granularity, and semantic definitions, making it difficult to reconstruct the true relationships between people, organizations, vehicles, projects, funds, contracts, and events.

[0003] Currently, there are still some shortcomings in entity relationship network analysis based on knowledge graphs. Specifically, entity recognition relies on single-field matching or fixed dictionaries, which lacks robustness to homonyms, abbreviation variants, noisy characters, and attributes; entity alignment uses static thresholds and cannot be dynamically calibrated based on field information entropy, source reliability, conflict intensity, and neighborhood topology; relationship construction focuses on explicit edges, making it difficult to characterize higher-order implicit relationships formed by spatiotemporal co-occurrence and event coupling; and graph reasoning results lack uncertainty estimation, evidence propagation paths, and counterfactual verification. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a knowledge graph-based entity relationship network analysis method and system, which can effectively solve the problems mentioned in the background technology.

[0005] To achieve the above objectives, the present invention provides the following technical solution: The first aspect of the present invention provides a knowledge graph-based entity relationship network analysis method, comprising the following steps: The original records from multiple business systems are rewritten into event-based records in a unified format, evidence pointers are registered, and a collection of event-based records is output.

[0006] Obtain entities to be unified from the event-based record collection, compare the evidence items of any two entities to be unified item by item, generate a list of paired judgment criteria, and merge the entities to be unified into unified entities based on the list of paired judgment criteria.

[0007] By combining the normalized entities, relation edges are generated from the event-based record set. For each relation edge, the number of supporting evidences, the number of independent sources, the evidence time interval, and other connected paths are registered. The relation strength level is marked according to a fixed comparison order, and the initial relation network is output.

[0008] Based on the initial relationship network, the supporting paths between two unified entities are enumerated, it is determined whether the supporting paths are independent of each other, and a removal recalculation is performed on each supporting path to determine the potential relationship conclusion.

[0009] The evidence chain is encapsulated for the event-based record set, normalized entities, initial relationship network, and potential relationship conclusions, and the entity relationship network analysis results are output.

[0010] A second aspect of the present invention provides a knowledge graph-based entity relationship network analysis system, comprising: The event-based record rewriting module is used to rewrite the original records of multiple business systems into event-based records in a unified format, register evidence pointers, and output a collection of event-based records.

[0011] The Unified Entity Merging Module is used to obtain entities to be unified from the event-based record collection, compare the evidence items of any two entities to be unified item by item, generate a list of paired judgment criteria, and merge the entities to be unified into a unified entity based on the list of paired judgment criteria.

[0012] The initial relation network output module is used to combine normalized entities to generate relation edges from the event-based record set, register the number of supporting evidences, the number of independent sources, the evidence time interval, and other connected path information for each relation edge, label the relation strength level according to a fixed comparison order, and output the initial relation network.

[0013] The potential relationship conclusion determination module is used to enumerate the support paths between two unified entities based on the initial relationship network, determine whether the support paths are independent of each other, perform removal recalculation for each support path, and determine the potential relationship conclusion.

[0014] The evidence chain encapsulation module is used to encapsulate the evidence chain of the event record set, normalized entity, initial relationship network and potential relationship conclusion, and output the entity relationship network analysis results.

[0015] Compared with the prior art, the embodiments of the present invention have at least the following advantages or beneficial effects: (1) This invention provides a knowledge graph-based entity relationship network analysis method and system. By unifying event-based rewriting and evidence pointer registration, it effectively solves the problem of data heterogeneity in multiple business systems, providing a standardized data foundation that is traceable and verifiable for subsequent analysis. In the entity merging stage, it adopts a multi-evidence item comparison and a judgment logic based on the law of contradiction, avoiding erroneous merging caused by static thresholds or single-field matching, and significantly improving the accuracy and robustness of entity alignment.

[0016] (2) In the relational network construction of this invention, not only explicit behavioral relationships are extracted, but implicit associations are also mined through co-occurrence and spatiotemporal continuity. Furthermore, the strength of relationships and potential conclusions are double-checked using the number of independent sources and a removal and recalculation mechanism, eliminating accidental connections caused by single weak evidence and enhancing the credibility of the reasoning results. Through five-layer evidence chain encapsulation and completeness checks, it is ensured that each conclusion can be traced back to the original record layer by layer, significantly improving the interpretability of the analysis process and the verifiability of the results, providing reliable and transparent entity relationship analysis capabilities for scenarios such as government affairs, finance, and regulation. Attached Figure Description

[0017] The present invention will be further described with reference to the accompanying drawings, but the embodiments in the drawings do not constitute any limitation on the present invention. For those skilled in the art, other drawings can be obtained based on the following drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the method steps of the present invention.

[0019] Figure 2 This is a schematic diagram of the system module connections of the present invention.

[0020] Figure 3 This invention encapsulates the evidence chain of the event-based record set, normalized entities, initial relationship network, and potential relationship conclusions, and outputs the entity relationship network analysis results. Detailed Implementation

[0021] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0022] Reference Figure 1 As shown, the first aspect of the present invention provides a knowledge graph-based entity relationship network analysis method, comprising: rewriting the original records of multiple business systems into event-based records in a unified format, registering evidence pointers, and outputting a collection of event-based records.

[0023] For each data source that is connected, the data source identifier, data source affiliation, data reading method, and original record location method are registered at the time of connection.

[0024] The data source is a business system that provides the original records.

[0025] The original record is the smallest, unmodified unit of data read once from a single data source.

[0026] Based on the data source type, determine the granularity of reading raw records from multiple business systems.

[0027] Data source identifier: A unique number assigned to each data source. The number format is determined by the access party, and must be unique within the scope of this method. Example: SRC-A01, SRC-A02.

[0028] Data source affiliation: This registers which unit is responsible for maintaining the content of this data source, and whether the content of this data source is synchronized from other data sources in batches. This is the basis for subsequent determination of independent sources.

[0029] Data reading method: Register the technical method used to read this data source, including database connection method, file reading method, and API call method.

[0030] Original record location method: Registers the combination of fields or position string required to uniquely locate an original record within this data source. Example: Database tables are located by primary key, and documents are located by filename plus paragraph number plus sentence number.

[0031] The granularity of reading raw records in a multi-service system includes: Database table: A row in the table is considered a single original record.

[0032] Spreadsheet: A row in a spreadsheet is considered a single original record.

[0033] Document: A paragraph in a document is considered a single original record. If a single paragraph exceeds one sentence, it is split into multiple original records, with the sentence ending punctuation as the boundary. Each original record records its paragraph number and sentence number within the document.

[0034] Log file: A line in the log is considered a raw record.

[0035] The purpose of defining the granularity of the read is to ensure consistency in backtracking. When unfolding the chain of evidence, it is essential to be able to directly locate the original record read by following the evidence pointer; an unclear definition of the granularity will lead to location failure.

[0036] Obtain the field mapping table. Based on the field mapping table, rewrite each original record into an event-based record containing seven elements. The names and order of the seven elements are fixed. Obtain the seven elements as follows: subject of behavior, action, recipient, time of occurrence, location of occurrence, source of information, and original text location.

[0037] Element 1: Subject of the action: The party that initiates the action in this record.

[0038] Element 2, Action: The behavior described in this record.

[0039] Element 3: The recipient: The party that passively receives the action.

[0040] Element 4: Time of Occurrence: The time when the behavior described in this record occurred.

[0041] Element 5, Location: The location where the behavior described in this entry occurred.

[0042] Element Six: Information Source: Identifier of the data source that generated this record.

[0043] Element 7: Original record location: The location string of this original record within the data source.

[0044] The selection criteria for the seven elements are: any business record, regardless of its origin from any business system, can be described as one party performing a certain action on another party at a certain time and place. This allows structured records, semi-structured records, unstructured text, and logs to be integrated into the same structure.

[0045] Complete steps for generating a field mapping table: Retrieve all column names from the data source. For databases, retrieve the table structure; for spreadsheets, retrieve the first row header; for log files, retrieve the log format description; for document-type data sources without column names, skip this step and proceed directly to special processing.

[0046] The special processing involves extracting elements from each paragraph in the document-type data source using the following steps: The first step is to divide the paragraph into sentences, using the punctuation marks at the end of the sentence (period, question mark, exclamation mark, semicolon) as the boundary to divide it into single sentences.

[0047] The second step is to perform word segmentation and part-of-speech tagging on each sentence to obtain a word sequence and the part-of-speech tag for each word.

[0048] The third step is to perform dependency parsing on each single sentence to obtain a dependency parsing tree, in which each word node contains a dependency relation label.

[0049] The fourth step is to take the root node (the node with the dependency relationship label "root") in the dependency syntax tree as the value of the action element.

[0050] Fifth, take the node with dependency relationship label nsubj (noun subject) or nsubjpass (passive subject) as the value of the behavioral subject element; if there are multiple subject nodes, take the one closest to the root node.

[0051] Step 6: Take the node with dependency label dobj (direct object) or iobj (indirect object) as the value of the subject element; if there are multiple object nodes, take the one closest to the root node.

[0052] Step 7: Take the node with dependency relationship label tmod (time modifier) ​​or part-of-speech label TIME and all its child nodes as the occurrence time element value.

[0053] Step 8: Take the node with dependency relationship label loc (location modifier) ​​or part-of-speech label LOCATION and all its child nodes as the location element value.

[0054] Step 9: Fill the extracted element values ​​into the corresponding positions in the event record, leaving blanks for elements that cannot be extracted.

[0055] For non-text content or sentences in the document that fail dependency parsing, all elements in the corresponding event record should be left blank.

[0056] Dependency parsing is performed using a mature syntactic parsing model in the field, and the element extraction rules are executed based on the general definition of dependency relation tags, without relying on the output format of a specific model.

[0057] For each column, extract one actual value and write it into the field sample value column. The purpose of sampling is to allow the person filling out the form and the person reviewing it to see intuitively what is in this column, avoiding guesswork based solely on the column name. For example, if the column name is "code" and the sample value is 91340100MA2XXXX, it can be identified as the Unified Social Credit Code; if the sample value is H01, it can be identified as an internal sub-category code.

[0058] Determine whether each column serves as a unique identifier. The determination is based on three objective conditions; if any one of them is met, it is considered a unique identifier.

[0059] Condition 1: The values ​​in this column are not repeated within the data source; that is, each row has a different value.

[0060] Condition 2: The values ​​in this column conform to the composition of national or industry standardized codes, such as unified social credit code, resident identity number, motor vehicle license plate number, and bank account number.

[0061] Condition 3: This column is used as a primary key or unique key by the data source itself.

[0062] After the determination is correct, the identifier type must also be filled in. The type name should be selected from the following general types: Unified Social Credit Code, Resident Identity Number, Vehicle License Plate Number, Bank Account Number, Project Number, Contract Number, Merchant Number, Organization Code. If this column does belong to an identifier but is not among the above types, fill in "Other" and specify the name in the remarks. The Organization Code is only used to handle cases where the Organization Code is still used in historical data.

[0063] Regarding the mandatory field type: In the second step of comparing the first type of evidence, the identifier type is compared first. If the types are different, no comparison is made. If the type is not filled in here, the subsequent comparison cannot be performed. Therefore, the identifier type is a mandatory field, not an optional one.

[0064] Determine whether each column is considered an attribute. An attribute is a registered item that describes the characteristics of an entity, such as legal representative, registered address, company status, registered capital, bank, and industry.

[0065] Judgment criteria: The values ​​in this column describe the characteristics of the entities, not the actions between entities, nor the time and place when the actions occur.

[0066] After confirming the result, fill in the attribute name. Attribute names must be consistent within this method; attributes with the same meaning must use the same attribute name across different data sources. For example, in the business registration database, it might be named `legal_person`, and in the banking system, it might be named `corp_rep`; both should use the attribute name "legal representative".

[0067] Regarding the standardization of attribute names: Standardizing attribute names is a prerequisite for comparing the second type of evidence items by attribute name in the second step. If two data sources enter different names for the same attribute, they will be treated as two different attributes during the comparison, resulting in an empty intersection and being mistakenly judged as blank items.

[0068] For columns that are neither identifiers nor attributes, determine which of the seven elements they correspond to.

[0069] Corresponding actor: This list is for the party that initiates the action, such as company name, personnel name, or license plate number.

[0070] Corresponding actions: This list contains the actions themselves, such as winning a bid, transferring funds, affiliation, communication, and opening an account.

[0071] Corresponding recipient: This list is for the party that passively receives the action, such as the project name, the receiving account, or the subordinate unit.

[0072] Corresponding occurrence time: This column lists the time when the action occurred.

[0073] Corresponding location: This list indicates the location where the action occurred.

[0074] Corresponding information source or original text location: Do not fill in. These two items are automatically assigned by the reading program and do not come from the mapping table.

[0075] Not included in mapping: This column is not used in this method, such as notes, serial number, operator employee number, and record creation time (system time, not business time).

[0076] A common mistake when entering the creation time: This column records the time when data enters the system, not the time when the business activity occurred. This column should be filled with "not participating in mapping," and the "occurrence time" should be taken from the business time column.

[0077] For columns whose corresponding element is the time of occurrence, the time format must be recorded. The recorded content is the way the values ​​in this column are constructed, such as 4-digit year, 2-digit month, and 2-digit day; 4-digit year, 2-digit month, 2-digit day, 2-digit hour, and 2-digit minute; 4-digit year, 2-digit month; and text description.

[0078] For columns whose corresponding element is the location, the location level must be recorded. The level value should be selected from the following general levels: house number, street, district / county, city, and province.

[0079] The time format determines whether the first step can parse out comparable time values. If the format cannot be parsed, the time element will be blank, and the spatiotemporal compatibility comparison cannot be performed. The location level determines to which level the locations of both parties are unified during the second step of comparison. If the level is unclear, comparison is impossible.

[0080] After the field mapping table is filled in, each item must pass the following validations before reading this data source can be allowed.

[0081] Each column in the data source field list has a corresponding row in the mapping table, and each row is either filled with the corresponding feature name or explicitly marked as not participating in the mapping. Unregistered columns are not allowed.

[0082] Failed processing: Suspend reading from this data source and return for further information.

[0083] The following six items must not be empty in each row: data source identifier, original field name, field sample value, corresponding feature name, uniqueness identifier, and attribute.

[0084] Failed processing: Returned for supplementary information.

[0085] For rows where the uniqueness identifier is "yes", the identifier type must be filled in; for rows where the attribute is "yes", the attribute name must be filled in; for rows where the corresponding element is the time of occurrence, the time format must be filled in; for rows where the corresponding element is the location of occurrence, the location level must be filled in.

[0086] The general location hierarchy is set according to the administrative division hierarchy: provinces correspond to provincial-level administrative regions, cities correspond to prefecture-level administrative regions, districts / counties correspond to county-level administrative regions, streets correspond to township-level administrative regions, and house numbers correspond to basic-level geographic code points. The subordinate relationship between the levels is as follows: provinces include cities, cities include districts / counties, districts / counties include streets, and streets include house numbers.

[0087] Failed processing: Returned for supplementary information.

[0088] A column cannot simultaneously contain both a unique identifier and an attribute. A column can correspond to one of the seven elements and be an attribute, but identifiers and attributes are mutually exclusive because identifiers are used to determine entity identity, while attributes are used to describe entity characteristics, and they play different roles in the second step.

[0089] Failed to pass the review: Returned for revision.

[0090] Each data source must have at least one column filled in as a unique identifier, or be explicitly registered as an unidentified column with a reason stated. If a data source has no identifier column at all, then all entities to be unified extracted from that data source will be unidentified, all first-class evidence items in the second step will be blank, and entity unification will have to rely on the other four types of evidence items, resulting in a significant decrease in effectiveness.

[0091] Failed processing: Prompt the access personnel to confirm. If there is indeed no identifier column, register the reason and continue. At the same time, after reading, focus on monitoring the percentage of unused records in this data source.

[0092] Compare the attribute names of the newly created mapping table with those of the existing tables. Attributes with the same meaning must use the same attribute name in different data sources.

[0093] Handling inconsistencies: Unify the names to the same standard and re-verify. Common inconsistencies include legal representative and legal person representative, registered address and place of registration, and company status and operating status.

[0094] Check for instances where the record creation time was mistakenly entered as the occurrence time. The method is to check if the sample value in this column is close to the current date and includes hours, minutes, and seconds, and if there is another column for business time in the data source.

[0095] Failed to pass the review: Returned for revision.

[0096] Obtain evidence pointers for each original record. Evidence pointers include data source identifier, original text location, and read batch number.

[0097] The evidence pointer is an identifier string that points to the location of the original record that generated a certain event record.

[0098] The data source identifier is written to the data source registration table during the access registration phase, and each read operation of the reading program targets only one data source. Reading parameters (connection address, reading method, field mapping table) are configured individually for each data source; therefore, the reading program knows which data source it is currently reading from when it starts. During assignment, the data source identifier of this data source is directly retrieved.

[0099] The original location and the value vary depending on the data source type, but are all automatically generated by the reading program during the reading process. When reading a database table, the primary key value of the record is retrieved based on the original record location method registered in the data source registration table. If a unique key combination is registered, the values ​​of each field in the combination are concatenated in the order of registration. Example: Reading the bid_record table of SRC-A03, if the primary key field value of a certain row is B20260318001, the second part is automatically written as the primary key B20260318001 of the bid_record table.

[0100] Spreadsheets typically do not have primary keys. The reading program automatically maintains a row number counter as it reads row by row, starting from 1 and incrementing by one after each row read. The current count is used as the row location, and the worksheet name is retrieved and combined to form the worksheet name and row number. Example: Reading sheet1 of SRC-A0X, currently at row 47 (the first row is the header), the second paragraph is automatically written as row 47 of sheet1.

[0101] The document and text file reading program reads documents by paragraph, maintaining a paragraph number counter starting from 1 and incrementing by one for each paragraph read. If a single paragraph contains multiple sentences, it is further segmented by the punctuation at the end of each sentence, maintaining a sentence number counter starting from 1 and incrementing by one for each sentence extracted. The filename is used to locate the paragraph and sentence numbers. For example, when reading meeting_20260402.docx from SRC-A05, the current sentence is the first sentence of the third paragraph; the second paragraph is automatically written as the first sentence of the third paragraph of the file meeting_20260402.docx.

[0102] Log files are read line by line, maintaining a line number counter and using the log filename and line number as the location. If the logging system provides a stable timestamp and sequence number for each line, the system-provided sequence number is used first, because the line number may change after log rolling archiving, while the system-provided sequence number remains unchanged. Example: Reading gate_20260318.log from SRC-A04, currently at line 1207, the second segment is automatically written to line 1207 of the file gate_20260318.log.

[0103] The batch number is automatically generated by the reading program each time a read operation is initiated. The format is a batch start date. All event-driven records within the same batch share the same batch number. The batch number is generated based on the system date. The reading program reads the system date once at the start of the batch. If multiple read operations are initiated on the same day, the batch number is appended with the current day's sequence number. For example, the second read on the same day is written as B20260801-2. The sequence number is automatically generated by a daily counter maintained by the reading program, incrementing by one with each read operation and resetting to zero across days. The batch number allows each event-driven record to identify which read operation it entered, enabling location of a specific batch of data.

[0104] If two event-based records with identical evidence pointers appear within the same batch, it indicates that the same original record has been read repeatedly. The solution is to remove duplicates and retain only one event-based record.

[0105] If a certain element cannot be obtained from the original record, the corresponding element will be filled in as blank, without affecting the registration of the evidence pointer.

[0106] If a certain element cannot be obtained from the original record, then the corresponding element should be filled in as blank; Based on the event-based records and evidence pointers of each original record, output a collection of event-based records.

[0107] In one specific implementation, the integration challenge of heterogeneous data from multiple business systems was effectively solved by unifying data access specifications and standardizing event-based rewriting. During the data source access phase, identifiers, affiliations, reading methods, and location methods were registered, and the reading granularity for different data types was clearly defined, ensuring that each original record could be accurately located and traced back, laying a consistent foundation for subsequent evidence chain development. A field mapping table uniformly mapped the original records to seven fixed elements: subject, action, recipient, time of occurrence, location of occurrence, information source, and original text location. This brought structured, semi-structured, unstructured, and log data into the same expression system, eliminating semantic differences across systems. Simultaneously, the mapping table generation process was supplemented by multiple verification rules, including sample sampling, identifier and attribute determination, and time and location format registration, forcing unified attribute naming and preventing misfilling of time fields, ensuring data quality from the source. The evidence pointer integrates the data source identifier, original text location, and reading batch number, combined with a deduplication mechanism, ensuring that each event-based record is independently traceable and non-repeating, providing a reliable and auditable data foundation for entity merging, relationship construction, and evidence chain encapsulation.

[0108] Obtain entities to be unified from the event-based record collection, compare the evidence items of any two entities to be unified item by item, generate a list of paired judgment criteria, and merge the entities to be unified into unified entities based on the list of paired judgment criteria.

[0109] From the subject and object elements of the event-based record collection, extract all noun components and treat them as entities to be unified.

[0110] An entity to be unified is an entity extracted from the event-based record that has not yet been determined whether it points to the same real-world object as other entities.

[0111] When the same nominal component appears in multiple event records, it is merged into the same entity to be unified, and the corresponding evidence pointer set is accumulated.

[0112] Each entity to be unified is registered with its entity identifier, original name, set of evidence pointers, set of attribute values, and set of unique identifiers. Entity to be unified identifier: Automatically numbered, consisting of a fixed prefix (letter E) + batch number + sequence number within the batch. Example: E-B20260801-0001. After retrieving a noun phrase from the subject or object element of an event-based record, first check the existing name index. If the noun phrase does not exist in the index, create a new entity to be unified and assign a new number; if it already exists, do not create a new one, reuse the existing number, and only append the evidence pointer of the current event-based record to its evidence pointer set.

[0113] Original name: The original text extracted from the event record, without normalization.

[0114] Evidence pointer set: Evidence pointers to all event-based records of the entity to be normalized.

[0115] Attribute value set: Extract the field values ​​marked as attributes from the field mapping table in the original record pointed to by the evidence pointer.

[0116] Unique identifier set: Extract the field values ​​marked as unique identifiers from the original record pointed to by the evidence pointer in the field mapping table.

[0117] For any two entities to be normalized, compare each piece of evidence, including identity consistency, attribute consistency, spatiotemporal compatibility, and overlap of related objects.

[0118] Obtain the source level of each of the two entities to be normalized. The source level does not participate in the determination of support and conflict items, but is only used to select the preferred name of the entity to be normalized.

[0119] The evidentiary item is a verifiable fact used to determine whether two entities to be unified can be merged.

[0120] For identifier consistency, first compare whether the identifier types in the unique identifier sets of the two entities to be normalized are the same. If the identifier types are different, no comparison is made and blank is output. If the identifier types are the same, if there are identifiers with exactly the same value, output consistent; if there are no identifiers with exactly the same value, output inconsistent; if there is a blank value on either side, output blank.

[0121] For attribute consistency, compare the values ​​of the same attribute name in the attribute value sets of the two entities to be normalized. If the values ​​are the same, output "consistent"; if the values ​​are different, output "contradictory"; if there is a blank value for the same attribute name in either entity, output "blank".

[0122] For spatiotemporal compatibility, compare the occurrence time and location of the two entities to be unified: take the occurrence time and location of all event records of the two entities to be unified. If the occurrence time values ​​of two event records fall within the same natural day and the occurrence location values ​​are different at the district / county level or above, then output contradiction; if the above situation does not occur, output compatibility; if the occurrence time element or occurrence location element of either party is completely blank, then output blank. Spatiotemporal compatibility only applies to personnel-type entities to be unified. For organization-type entities to be unified, spatiotemporal compatibility is directly output as compatible.

[0123] Explanation of the criteria for determining spacetime compatibility: The reason for using the same natural day at the same time is that the time granularity of different data sources is inconsistent. Some are accurate to the second, while others are only accurate to the day. Using the same natural day is the greatest common criterion that can accommodate all time granularities.

[0124] The reason why different locations are classified at the district / county level or above is that the granularity of location elements is inconsistent. Some are accurate to the house number, while others are only accurate to the city. The district / county level is a public level that can accommodate most location granularities. Different streets within the same district / county are not considered different locations.

[0125] Spatiotemporal compatibility only applies to personnel-type entities to be unified, because personnel cannot be in two different locations at the same time; organizational-type entities to be unified (such as enterprises and institutions) can conduct business in different locations at the same time, so spatiotemporal contradiction judgment is not applicable, and compatibility is directly output.

[0126] The distinction between personnel and organization categories is based on whether the unique identifier set of the entity to be unified contains a resident identity number. If it does, it is classified as a personnel category; otherwise, it is classified as an organization category.

[0127] Regarding the overlap of associated objects, obtain the other entities to be normalized from the event records that the first entity to be normalized has appeared, excluding the current first entity to be normalized, to form the first set of associated objects; obtain the other entities to be normalized from the event records that the second entity to be normalized has appeared, excluding the current second entity to be normalized, to form the second set of associated objects; if the first set of associated objects and the second set of associated objects have an intersection, output "overlapping"; if there is no intersection, output "not overlapping".

[0128] For source level, output the source level of each of the two entities to be normalized. It does not participate in the determination of support and conflict, but is only used as the basis for comparison when selecting the preferred name. The source quality is divided into four levels, as defined below: Level 1, Original Registration Source: Data sources directly generated from legally registered acts, including business registration databases, household registration databases, real estate registration databases, and vehicle registration databases.

[0129] Level 2, Business Processing Source: Data sources generated from the record-keeping of each business processing transaction, including bank account statements, bidding and tendering filings, contract filings, access control and vehicle passage logs.

[0130] Level 3, Publicly Disclosed Sources: Data sources disclosed by the entity itself, including the company's official website, public annual reports, bidding announcements, and recruitment information.

[0131] Level 4, paraphrased record sources: data sources generated by manual compilation or paraphrasing, including meeting minutes, work briefings, news reports, and interview records.

[0132] The source level of an entity to be unified is determined in the following manner: The first step is to retrieve the data source identifiers corresponding to all evidence pointers in the evidence pointer set of the entity to be unified, thereby obtaining all data sources that the entity to be unified has appeared in.

[0133] The second step is to retrieve the source level of each of the above data sources from the data source registration table.

[0134] The third step is to take the highest level among the above source levels as the source level of the current entity to be normalized; the order of the levels is: the first level is higher than the second level, the second level is higher than the third level, and the third level is higher than the fourth level.

[0135] Fourth step: If multiple data sources have the same highest level, take the source level of the data source that appears most frequently as the source level of the current entity to be normalized; if they appear the same number of times, take the source level of the data source whose data source identifier is ranked first.

[0136] The source level determination process is as follows: The first step is to determine whether the source data source is a first-level original registration source if the source data source's original record location method contains the words "registration database", "registration book" or "registration system" and the source data source's affiliation includes legal registration authorities such as market supervision and management departments, public security organs, natural resources departments, and transportation departments.

[0137] The second step is to determine whether the source of the data is a second-level business processing source if the original record location method contains the words "transaction log", "ledger", "filing", "log", or "pass record" and the data reading method is a database connection or interface call.

[0138] The third step is to determine whether the source data source is a third-level public disclosure source if the original record location method contains words such as official website, annual report, announcement, recruitment, or disclosure.

[0139] The fourth step is to determine if the source data source's original record location method contains words such as minutes, briefing, report, interview, or compilation, or if the data reading method is document reading, then it is determined to be a fourth-level paraphrase record source.

[0140] Explanation of the grading criteria: The grading is based on whether a third-party verification process exists during content generation. Level 1 is generated by legally mandated registration, and verification has already taken place during registration; Level 2 is generated by transaction-by-transaction records in the business system, and the recording process is traceable and verifiable; Level 3 is disclosed by the entity itself, without third-party verification; Level 4 is based on human interpretation, which may result in distortion. This grading is an objective description of the nature of the generation process, not a subjective score of the content's credibility.

[0141] For any two entities to be unified, they are denoted as a pair of entities to be unified. A list of paired judgment criteria is generated, which includes supporting items, conflicting items, and blank items.

[0142] Supporting items: Evidence items whose comparison results are consistent or overlapping, including consistent identifier output, consistent attribute output, and overlapping related objects output. Each evidence item category, specific comparison content, and evidence pointers from both parties are recorded.

[0143] Conflict items: Evidence items whose comparison results are contradictory, including contradictions in attribute consistency output and spatiotemporal compatibility output. Each evidence item category, specific contradiction point, and evidence pointers from both sides are recorded.

[0144] Blank items: Evidence items that cannot be effectively compared because the corresponding value of either party is blank. These include blank outputs for identifier consistency, attribute consistency, spatiotemporal compatibility, and overlapping of related objects. The category of each evidence item and the reason for its blankness are recorded.

[0145] The same piece of evidence will be classified into one of the following categories based on its comparison results: supporting item, conflicting item, or blank item; evidence items that have already been classified into conflicting items will not be counted again as supporting items or blank items.

[0146] Conflict items are only considered under the law of contradiction; only values ​​that cannot be true simultaneously are included in conflict items. Supporting items are only considered under positive evidence; only verifiable facts that clearly point to the same object are included in supporting items. Items lacking common ground are included in blank items.

[0147] The specific process of merging entities to be normalized into normalized entities based on the list of pairwise determination criteria is as follows: Based on the list of paired determination criteria, for each entity to be unified, the determination is performed in the following fixed order: once the previous criterion is met, a determination is made, and the next criterion is not considered.

[0148] If any conflict exists, it is determined that it cannot be merged, and a conflict is marked on the entity to be unified.

[0149] Selection Criterion: A conflicting term refers to two values ​​that cannot objectively be true simultaneously; in this case, they cannot point to the same real-world object. This criterion is based on the law of contradiction, not empirical statistical results.

[0150] If the identifiers are consistent, they are determined to be mergeable.

[0151] Selection criteria: The unique identifier is assigned by the registration act and is unique to the same real-world object within the same identifier system; identical values ​​point to the same real-world object. This criterion is based on the unique definition of the identifier itself, not empirical statistical results.

[0152] If the number of supporting items is zero, it is determined that it cannot be merged, and the entity to be unified is marked as pending.

[0153] The purpose of marking items to be supplemented is to allow for the re-comparison of new evidence items generated from newly added original records, without requiring recalculation of all items to be supplemented.

[0154] If there are at least two supporting items, it is determined that it can be merged; if there is exactly one supporting item and the attributes or identifiers are consistent, it is determined that it can be merged; if there is exactly one supporting item and the related objects overlap, it is determined that it cannot be merged and is marked as pending.

[0155] Regarding the threshold for the number of supporting items: The overlap of related objects only indicates that two entities to be unified co-occur with the same third-party entity; it cannot directly prove that the two entities to be unified point to the same real-world object. Therefore, a single instance of overlap of related objects is not sufficient as a basis for merging. Attribute consistency indicates that two entities to be unified have the same value under the same attribute name; identifier consistency indicates that two entities to be unified have completely identical values ​​under the same identifier type. Both have strong common orientation, and a single instance is sufficient to support merging. Two or more supporting items corroborate each other, which is sufficient to support merging. This threshold is not an empirically adjusted limit, but a logical distinction based on the differences in the probative value of each piece of evidence.

[0156] Pairs of entities that are determined to be mergeable and to be normalized are merged according to the transit rules and blocking rules, and the normalized entity is output. Transmission rule: If entity A to be unified and entity B to be unified can be merged, and entity B to be unified and entity C to be unified can be merged, then entity A, entity B, and entity C to be unified are merged into the same unified entity.

[0157] Blocking Rule: If there is a conflict between entity A and entity C to be unified, the above-mentioned transfer merging is blocked. At this time, entity A and entity B to be unified are merged into one unified entity, and entity C to be unified becomes a separate unified entity. A record of the blocked transfer merging is recorded, which includes the content of the conflict and the evidence pointers of both parties, to avoid mistakenly merging two entities with objective contradictions into the same unified entity through an intermediate entity.

[0158] Obtain the unified entity identifier, preferred name, original name set, unique identifier set, attribute value set, evidence pointer set, and merging basis. Register the unified entity identifier, preferred name, original name set, unique identifier set, attribute value set, evidence pointer set, and merging basis for each unified entity.

[0159] The first item, the unified entity identifier: fixed prefix + read batch number + serial number within the batch, with the prefix uniformly taking the letter G, example: G-B20260801-0001.

[0160] The second item, preferred name: within the merge set, take the original name of the entity to be normalized from the highest source level; if the levels are the same, take the original name that appears most frequently.

[0161] The third item, the original name text set: merges all the original names of entities to be normalized in the set, without normalization processing, and retains them all.

[0162] The fourth item is the set of unique identifiers: the unique identifiers of all entities to be unified in the merge set are retained after deduplication.

[0163] Fifth item, attribute value set: merge the attribute values ​​of all entities to be normalized in the set and group them by attribute name.

[0164] Item 6, Evidence Pointer Set: Merge all evidence pointers of entities to be unified within the set, and retain them after deduplication.

[0165] Item 7, Merging Basis: A list of all paired criteria that produced this unified entity.

[0166] Retain all entities to be unified and the complete list of pairwise determination criteria before the merger. If the addition of new original records subsequently causes a conflict within a merged unified entity, then the merger is revoked, the entity is reverted to its state before the merger, and a revocation record is recorded.

[0167] The revocation record contains three items: the reason for revocation, the evidence that triggered the revocation, and the revocation time.

[0168] The unified entity affected by the revocation will undergo a re-execution of the comparison and merging.

[0169] After the unified entity is revoked, perform the following cascading updates: The first step is to mark all relation edges that reference the revoked unified entity identifier as pending updates, and suspend the use of the above relation edges to determine potential relation conclusions.

[0170] The second step is to revoke all potential relationship conclusions that depend on the edges of the state relationship to be updated, and register a potential relationship conclusion revocation record. The record content includes the identifier of the revoked potential relationship conclusion, the reason for revocation, and the identifier of the unified entity that triggered the revocation.

[0171] The third step is to mark the chain of evidence corresponding to the revoked potential relationship conclusion as being in a state of needing reconstruction.

[0172] The fourth step is to update the starting and ending unified entity identifiers of all unupdated state relation edges after the unified entities have been merged again, re-mark the relation strength level, and re-determine the status of other connected paths.

[0173] The fifth step involves re-executing the supporting path enumeration, independence judgment, removal of duplicate calculations, and determination of potential relationship conclusions based on the updated initial relationship network.

[0174] The sixth step is to perform evidence chain encapsulation and completeness checks on the regenerated potential relationship conclusions, and output the updated entity relationship network analysis results.

[0175] It should be explained that a comprehensive comparison is made using five verifiable evidences: identifier, attribute, spatiotemporal, associated object, and source level, avoiding the one-sidedness of matching a single field. The judgment process strictly follows the law of contradiction and the principle of positive evidence. First, the unique identifier is used to quickly confirm that they are the same entity. Then, any objective conflict is used to block the merger. Finally, at least one piece of supporting evidence is used as the basis for merging. The entire process does not rely on empirical thresholds and is logically clear and interpretable. The introduction of source level improves the representativeness of the unified entity. The transfer merging combined with the blocking rules effectively prevents the erroneous merging of objects with objective contradictions through intermediate entities. All original evidence and the revocable mechanism are retained, making the merger results traceable and reversible, providing an accurate, stable, and auditable entity foundation for the subsequent construction of the relationship network.

[0176] By combining the normalized entities, relation edges are generated from the event-based record set. For each relation edge, the number of supporting evidences, the number of independent sources, the evidence time interval, and other connected paths are registered. The relation strength level is marked according to a fixed comparison order, and the initial relation network is output.

[0177] Generate relation edges from the event-based record set. The corresponding relation types include behavioral relations, co-occurrence relations, financial transaction relations, organizational hierarchy relations, and spatiotemporal continuity relations. Output the set of relation edges. Scenario 1: Behavioral Relationship: A behavioral relationship edge is generated between the subject and the recipient of the same event record. The relationship type of the edge is taken from the value of the action element of this event record.

[0178] Scenario 2, Co-occurrence Relationship: A co-occurrence relationship edge is generated between any two unified entities that appear simultaneously in the same event record.

[0179] Scenario 3: Fund Transaction Relationship: A fund transaction relationship edge is generated between the payer and payee in the event-based record of fund transactions. The basis for determining the payer and payee is that the value of the action element in the event-based record belongs to payment or receipt.

[0180] Scenario 4: Organizational Hierarchy Relationships: An organizational hierarchy relationship edge is generated between superiors and subordinates in the event-based log entries. The distinction between superiors and subordinates is based on whether the action element value in the event-based log entry belongs to a subordinate or subordinate category.

[0181] Scenario 5: Spatiotemporal continuity relationship: Two event records that occur within the same natural day and have the same location value will have a spatiotemporal continuity relationship edge generated between their respective actors.

[0182] Regarding the definition of a calendar day: It is taken from the calendar's definition of a calendar day, which is from midnight to midnight. It is not a manually set time window length and does not involve any adjustable parameters. The reason for using a calendar day instead of a shorter time period is that the time granularity of raw records across different data sources is inconsistent; some are accurate to the second, while others are only accurate to the day. The calendar day is the greatest commonality that can accommodate all time granularities.

[0183] Obtain the relation edge identifier, the starting unified entity identifier, the ending unified entity identifier, the relation type, the number of supporting evidence items, the number of independent sources, the evidence time interval, and the list of supporting evidence pointers.

[0184] The time interval for evidence is the earliest and latest occurrence times.

[0185] The strength level of the relationship is determined by a fixed comparison order.

[0186] The process of obtaining information on other connected paths is as follows: Using the starting and ending unified entities of the current relation edge as endpoints, enumerate all paths between the two points in the relation network after removing the current relation edge. If there is at least one path, register it as if there is another connected path; otherwise, register it as if there is no other connected path.

[0187] Other connected path cases refer to whether there is a connected path between the starting unified entity and the ending unified entity, other than the current relation edge, consisting of other relation edges.

[0188] When enumerating paths, the same unified entity is not repeatedly passed through, and the number of hops in a path does not exceed a preset hop limit. The preset hop limit is one-tenth of the total number of unified entities in the relational network and does not exceed five hops. The purpose of the hop limit is to control the enumeration computation and avoid an exponential number of paths in large-scale networks.

[0189] For each relation edge, register the relation edge identifier, the starting unified entity identifier, the ending unified entity identifier, the relation type, the number of supporting evidence items, the number of independent sources, the earliest and latest occurrence times, the list of supporting evidence pointers, the relation strength level, and other connectivity path information.

[0190] Relationship edge identifier: Format: fixed prefix + read batch number + sequence number within batch, the prefix is ​​uniformly the letter R, example: R-B20260801-0001.

[0191] Relationship type: Take the name of the relationship type corresponding to one of the five cases.

[0192] Number of supporting evidence entries: The number of event-based records pointing to this relationship edge.

[0193] Independent source count: The number of independent data sources among the data sources from which the supporting evidence originates. The number of independent data sources is calculated as follows: All data sources involved in the supporting evidence are aggregated according to their affiliation or batch synchronization relationship. Data sources with affiliation or batch synchronization relationship are grouped into the same data source set. Different data source sets are independent of each other. The total number of data source sets obtained is the independent source count of the relationship edge.

[0194] Earliest and latest occurrence times: Take the earliest and latest values ​​of the occurrence time elements of all supporting evidence.

[0195] Supporting Evidence Pointer List: Evidence pointers that point to all event-based records of this relation edge.

[0196] Relationship strength level: determined according to the calibration order.

[0197] The same event record can only serve as one piece of supporting evidence for the same relation edge, and repeated occurrences of the same event record are counted only once.

[0198] Determine if two data sources are independent of each other: Condition 1: The content maintenance of the two items is not handled by the same organization.

[0199] Condition 2: There is no data synchronization link between the two parties where one party synchronizes data in batches from the other.

[0200] Condition 3: The content of the two records is not generated from the same upstream record.

[0201] If conditions one, two, and three are all met simultaneously, the two data sources are independent of each other; otherwise, the two data sources are not independent of each other.

[0202] Output the initial relation network consisting of the normalized entities and the set of relation edges.

[0203] The specific process for determining the strength level of a relationship according to a fixed comparison order is as follows: Each relation edge is evaluated level by level in the following fixed order: those that meet the evaluation criteria of the previous level are marked as the corresponding level, and those that do not meet the criteria are moved to the next level for evaluation: If the number of independent sources of a relation edge is not less than two, then the relation strength level is five.

[0204] If the number of independent sources of a relation edge is less than two and the number of supporting evidence is not less than two, then the relation strength level is level four.

[0205] If the number of supporting evidence for a relationship edge is less than two and the latest occurrence time is no more than the first preset time, then the relationship strength level is level three.

[0206] If the latest occurrence time of a relation edge is more than the first preset time from the current time, and there are other connected paths besides the current relation edge, then the relation strength level is level two.

[0207] If there are no other connected paths besides the current relation edge, the relation strength level is level one.

[0208] The first preset duration is set to three times the average data update cycle of all connected data sources. The data update cycle is the average time interval between two adjacent original records within the same data source. During the data source registration phase, the reading program automatically calculates the historical data update cycles of each data source, takes the average of all data sources, and multiplies it by three to obtain the first preset duration. The first preset duration means that if the latest occurrence time of a relationship edge is no more than the first preset duration from the current time, it indicates that the evidence supporting the relationship edge is still within the normal data update cycle, and the relationship has timeliness; if it exceeds the first preset duration, it indicates that the evidence has exceeded the normal update cycle, and the timeliness of the relationship decreases. If the average data update cycle of all data sources cannot be calculated (e.g., a newly connected data source has no historical data), then the first preset duration is set to 90 days as the default value.

[0209] It should be explained that the above-mentioned generation of relationship edges from five dimensions (behavior, co-occurrence, funding, organization, and spatiotemporal) not only captures explicit behavioral associations but also uncovers implicit connections through spatiotemporal continuity, effectively revealing higher-order cross-system relationships. Each relationship edge registers the number of supporting evidence items, the number of independent sources, and the time interval. The number of independent sources is strictly determined by three conditions (not maintained by the same unit, no synchronous link, and not generated from the same source) to ensure the independence and credibility of supporting evidence and avoid double-weighting of information from the same source. Relationship strength is labeled according to a fixed five-level order, comparing the number of independent sources, the number of evidence items, the time of origin, and path verification level by level. The logic is clear and does not rely on empirical thresholds, so that the relationship strength objectively reflects the sufficiency and timeliness of the evidence, providing a reliable and sortable relationship foundation for subsequent path enumeration and potential relationship inference.

[0210] Based on the initial relationship network, the supporting paths between two unified entities are enumerated, it is determined whether the supporting paths are independent of each other, and a removal recalculation is performed on each supporting path to determine the potential relationship conclusion.

[0211] Two unified entities that do not have a direct relationship edge in the initial relationship network and have at least one connected path between them with a length not exceeding the preset hop count limit are selected to form the entity pair to be searched; the entity pair to be searched can also be formed by the user directly specifying two unified entity identifiers.

[0212] In the initial relation network, all relation edge paths connecting the pairs of entities to be checked are enumerated. During enumeration, the same unified entity is not repeatedly passed through to obtain the supporting path. The number of hops in the path does not exceed the preset upper limit of hops, and the relation strength level of each relation edge in the path is not lower than level two. The preset upper limit of hops is one-tenth of the total number of unified entities in the initial relation network and does not exceed five hops.

[0213] A path is defined as a sequence of edges formed by connecting the beginning and end of relational edges, which do not repeatedly pass through the same unified entity.

[0214] The rule that paths do not repeatedly pass through the same unified entity ensures that the number of paths is finite, allowing enumeration to be completed in a finite number of steps.

[0215] For each supporting path, take the set of relational edges. For any two supporting paths, compare the set of relational edges. Paths with an empty intersection are independent supporting paths.

[0216] The specific process for performing removal recalculation on each support path to determine the potential relationship conclusion is as follows: Select a subset of mutually independent support paths from all support paths as follows: First, sort all support paths from high to low according to the average relation strength level of the relation edges they contain. If the relation strength levels are the same, sort them from low to high according to the number of relation edges they contain. Select support paths sequentially according to the sorting results. If the intersection of the relation edge set of the current support path and the set of all selected support paths is empty, select the current support path into the subset; otherwise, skip it. Continue until all support paths have been traversed. Output the number of support paths selected into the subset as the number of mutually independent support paths between the entity pairs to be queried.

[0217] For each independent support path, select the relationship edge with the lowest relationship strength level on the current support path. If there are multiple relationship edges with the same lowest level on the current support path, select the one with the fewest supporting evidence as the object to be removed.

[0218] The object to be removed is temporarily removed from the initial relationship network, while the rest of the relationship network remains unchanged. This removal is a temporary operation and does not change the content stored in persistent storage.

[0219] In the initial relational network after removal, the supporting paths between the entity pairs to be queried are re-enumerated.

[0220] If, after removal, there is still at least one supporting path between the entities to be investigated, the potential relationship conclusion supported by the current supporting path is recalculated after removal; if, after removal, there are no longer any supporting paths between the entities to be investigated, the potential relationship conclusion supported by the current supporting path is not recalculated after removal.

[0221] Removing and recalculating involves removing a piece of evidence supporting a conclusion and then re-performing the judgment to observe whether the conclusion still holds. The purpose of removing and recalculating is to check whether a supporting path depends solely on the weakest relation edge. If, after removing the weakest relation edge, there are still other paths connecting the pairs of entities under investigation, it indicates that the conclusion is not supported by a single weak piece of evidence. If the paths become disconnected after removal, it means that the conclusion depends entirely on this weakest relation edge. If this relation edge is incorrect, the conclusion is invalid and should not be output.

[0222] If the entity to be investigated has at least one mutually independent support path, and the number of support paths that can be recalculated by removing the mutually independent support paths is at least one, then a potential relationship conclusion is generated; otherwise, no potential relationship conclusion is generated.

[0223] If there are at least two support paths among the corresponding independent support paths that can be removed and recalculated, then the potential relationship level is confirmed.

[0224] If the number of support paths that can be removed from the corresponding independent support paths is exactly one, then the potential relationship level is the prompt level.

[0225] Regarding the requirement of two values ​​for condition one: These values ​​are not empirically tuned thresholds, but rather a direct result of logical necessity. If only one supporting path exists, it is impossible to distinguish whether this path reflects a genuine connection or a connection formed by chance within a relational network. Only when two independent supporting paths exist—that is, when two sets of non-overlapping evidence point to the same conclusion—can coincidence be ruled out. Therefore, selecting two values ​​is the minimum requirement for eliminating coincidence.

[0226] Regarding the explanation of one of the values ​​in condition two: This value directly expresses the requirement that at least one path still has other paths supporting it after its weakest link is removed. If the number of recalculated paths after removal is zero, it means that all paths depend solely on their respective weakest relation edges, and no conclusion is output in this case.

[0227] The potential relationship conclusion is that there is no direct relationship edge between two unified entities, but after enumeration of supporting paths and recalculation of removal, it is determined that there is a relationship.

[0228] The two levels are based on the following criteria: the more paths that are removed and recalculated, the less the conclusion relies on a single weak piece of evidence. The "confirmation" level indicates that at least two sets of non-overlapping evidence have been removed and recalculated, indicating a high reliability of the conclusion; the "information" level indicates that only one set of evidence has been removed and recalculated, suggesting that the conclusion is for reference but requires further manual verification.

[0229] Obtain potential relationship conclusion identifiers.

[0230] Potential relationship conclusion identification format: fixed prefix + read batch number + sequence number within the batch. The prefix is ​​uniformly taken as the letter PL. Example: PL-B20260801-0001.

[0231] The potential relationship conclusion is output as the identifier of the potential relationship conclusion, the identifiers of the two unified entities of the entity pair to be investigated, the composition of all supporting paths and their relationship edges, the removal recalculation result of each supporting path (including the removed objects and whether they are still connected after removal) and the potential relationship level.

[0232] In one specific embodiment, a finite set of paths that do not repeatedly pass through the same entity is enumerated to ensure that the supporting path set structure is clear and exhaustive. Path independence is determined by edge set intersection to ensure that the conclusion is based on a non-overlapping chain of evidence, excluding duplicate support from the same source. A removal and recalculation mechanism is introduced to temporarily remove and re-evaluate the weakest relation edge of each path, checking whether the conclusion overly relies on a single weak piece of evidence. If the connection remains after removal, it proves that the conclusion has multiple supports; if the connection is broken, no output is given, logically eliminating the possibility of accidental connectivity being misjudged as a real association. Simultaneously, setting at least two independent paths as a prerequisite eliminates coincidental connectivity from the source. Furthermore, the conclusion is divided into confirmation and suggestion levels based on the number of paths through removal and recalculation, providing users with differentiated credibility guidance and improving the reliability and decision-making reference value of the analysis results.

[0233] like Figure 3 As shown, the evidence chain is encapsulated for the event-based record set, normalized entities, initial relationship network, and potential relationship conclusions, and the entity relationship network analysis results are output.

[0234] An evidence chain is generated by encapsulating the original records, the event-based record set, the unified entity, the initial relationship network, and the potential relationship conclusion. The evidence chain consists of five layers: the first layer is the original records, the second layer is the event-based record set, the third layer is the unified entity, the fourth layer is the initial relationship network, and the fifth layer is the potential relationship conclusion.

[0235] The chain of evidence is arranged from bottom to top, from the first to the fifth layer.

[0236] Each layer of the evidence chain sets a construction pointer to the layer above it, while the higher-level object stores a list of traceability identifiers pointing to the lower-level object, forming a chain that can be expanded in both directions; the layer above is the layer with a higher number, that is, the fifth layer is the top layer and the first layer is the bottom layer.

[0237] The expansion method is as follows: starting from a certain conclusion in the fifth layer, take all its supporting paths, take the relation edges contained in each path, take the supporting evidence pointers for each relation edge, take the corresponding event-based record for each evidence pointer, take the evidence pointer for each event-based record, and open the original record pointed to by each evidence pointer.

[0238] The pointer fields at each layer are as follows: the fifth layer potential relationship conclusion contains a list of supporting path identifiers, each supporting path contains a list of relationship edge identifiers, each relationship edge contains a list of supporting evidence pointers, each event-based record contains an evidence pointer, and the evidence pointer points to the original record at the first layer.

[0239] Perform a completeness check on the chain of evidence, checking whether the chain of evidence corresponding to each potential relation conclusion has all five levels of objects and all four inter-level pointers can be resolved.

[0240] If all five layers of the evidence chain corresponding to the potential relationship conclusion are complete and all four inter-layer pointers are resolvable, the evidence chain completeness check passes; otherwise, it fails, and an incomplete record is registered for the current potential relationship conclusion.

[0241] The evidence chain that passes the completeness check will be output as the entity relationship network analysis result.

[0242] In one specific embodiment, a five-layer progressive structure was constructed from the original record to the potential relationship conclusion (original record → event-based record → unified entity → initial relationship network → potential relationship conclusion). Each layer is equipped with a pointer to the layer above, forming a complete chain that unfolds layer by layer. This allows any conclusion to be traced back to the original record along the supporting path, relationship edge, and evidence pointer, achieving transparency and verifiability throughout the entire analysis process. A completeness check enforces the verification of the completeness of the five-layer objects and the resolvability of the pointers between the four levels for each conclusion. Any conclusion that fails to pass is recorded as an incomplete record and not output. This mechanism fundamentally eliminates the problem of untraceable conclusions due to data gaps or missing pointers. The final output entity relationship network analysis results not only possess logical rigor but also meet the requirements for auditing and evidence chain presentation, providing a solid basis for decision-making.

[0243] Reference Figure 2 As shown, the second aspect of the present invention provides an entity relationship network analysis system based on knowledge graphs, including: an event-based record rewriting module, a normalized entity merging module, an initial relationship network output module, a potential relationship conclusion determination module, and an evidence chain encapsulation module.

[0244] The event-based record rewriting module is used to rewrite the original records of multiple business systems into event-based records in a unified format, register evidence pointers, and output a collection of event-based records.

[0245] The Unified Entity Merging Module is used to obtain entities to be unified from the event-based record collection, compare the evidence items of any two entities to be unified item by item, generate a list of paired judgment criteria, and merge the entities to be unified into a unified entity based on the list of paired judgment criteria.

[0246] The initial relation network output module is used to combine normalized entities to generate relation edges from the event-based record set, register the number of supporting evidences, the number of independent sources, the evidence time interval, and other connected path information for each relation edge, label the relation strength level according to a fixed comparison order, and output the initial relation network.

[0247] The potential relationship conclusion determination module is used to enumerate the support paths between two unified entities based on the initial relationship network, determine whether the support paths are independent of each other, perform removal recalculation for each support path, and determine the potential relationship conclusion.

[0248] The evidence chain encapsulation module is used to encapsulate the evidence chain of the event record set, normalized entity, initial relationship network and potential relationship conclusion, and output the entity relationship network analysis results.

[0249] The above description is merely an example and illustration of the structure of the present invention. Those skilled in the art can make various modifications or additions to the specific embodiments described, or use similar methods to replace them, as long as they do not deviate from the structure of the invention or exceed the scope defined in the claims, all of which should fall within the protection scope of the present invention.

Claims

1. A knowledge graph-based entity relationship network analysis method, characterized in that, Includes the following steps: The original records from multiple business systems are rewritten into event-based records in a unified format, and evidence pointers are registered to output a collection of event-based records. The entity to be unified is obtained from the event record collection. The evidence items of any two entities to be unified are compared one by one to generate a list of paired judgment criteria. The entities to be unified are merged into a unified entity based on the list of paired judgment criteria. By combining the unified entity, relation edges are generated from the event-based record set. For each relation edge, the number of supporting evidences, the number of independent sources, the evidence time interval, and other connected paths are registered. The relation strength level is marked according to a fixed comparison order, and the initial relation network is output. Based on the initial relationship network, the supporting paths between two unified entities are enumerated, it is determined whether the supporting paths are independent of each other, and the removal recalculation is performed on each supporting path to determine the potential relationship conclusion. Select two unified entities that have no direct relationship edges in the initial relationship network and have at least one connected path between them with a length not exceeding the preset hop count limit to form the entity pair to be searched; In the initial relation network, all relation edge paths connecting the pairs of entities to be checked are enumerated. During enumeration, the same unified entity is not repeatedly passed through. Support paths are obtained. The number of hops in the path does not exceed the preset upper limit of the number of hops, and the relation strength level of each relation edge in the path is not lower than level two. For each supporting path, take the set of relation edges. For any two supporting paths, compare the set of relation edges. Paths with an empty intersection are independent supporting paths. The specific process for performing removal recalculation on each support path to determine the potential relationship conclusion is as follows: Select independent subsets of support paths from all support paths in the following manner: First, sort all support paths from high to low according to the average relation strength level of the relation edges they contain. If the relation strength levels are the same, sort them from low to high according to the number of relation edges they contain. Select support paths in order of sorting. If the intersection of the relation edge set of the current support path and the set of all selected support paths is empty, select the current support path into the subset; otherwise, skip it. Once all support paths have been traversed, the number of support paths in the selected subset will be output as the number of independent support paths between the entity pairs to be queried. For each independent support path, take the relationship edge with the lowest relationship strength level on the current support path. If there are multiple relationship edges with the same lowest level on the current support path, take the one with the fewest supporting evidence as the object to be removed. The object to be removed is temporarily removed from the initial relationship network, while the rest of the relationship network remains unchanged; In the initial relational network after removal, the supporting paths between the entity pairs to be searched are re-enumerated; If, after removal, there is still at least one supporting path between the entities to be investigated, the potential relationship conclusion supported by the current supporting path is recalculated by removal. If, after removal, there are no longer any supporting paths between the entities to be investigated, then the potential relationship conclusions supported by the current supporting paths have not been recalculated after removal. If the entity to be investigated has at least one mutually independent support path, and the number of support paths that can be recalculated by removing the mutually independent support paths is at least one, then a potential relationship conclusion is generated; otherwise, no potential relationship conclusion is generated. If there are at least two support paths that can be removed from the recalculated support paths that are mutually independent, then the potential relationship level is confirmed. If the number of support paths that can be removed from the corresponding independent support paths is exactly one, then the potential relationship level is the warning level. Identify potential relationship conclusions; The potential relationship conclusion is output as the identifier of the potential relationship conclusion, the identifiers of the two unified entities of the entity pair to be investigated, the composition of all supporting paths and their relationship edges, the removal and recalculation results of each supporting path and the potential relationship level. Encapsulate the chain of evidence for the event-based record set, normalized entities, initial relationship network, and potential relationship conclusions, and output the entity relationship network analysis results. The evidence chain is encapsulated based on the original records, the event-based record set, the unified entity, the initial relationship network, and the potential relationship conclusions. The evidence chain consists of five layers: the first layer is the original records, the second layer is the event-based record set, the third layer is the unified entity, the fourth layer is the initial relationship network, and the fifth layer is the potential relationship conclusions. Each layer of the evidence chain has a pointer to the layer above it, and the higher-level object stores a list of traceability identifiers pointing to the lower-level objects, forming a chain that can be expanded in both directions; the layer above is the layer with a higher number, that is, the fifth layer is the top layer and the first layer is the bottom layer; Perform a completeness check on the chain of evidence, checking whether the chain of evidence corresponding to each potential relation conclusion has all five layers of objects and all four inter-layer pointers can be resolved; If the five layers of evidence chain corresponding to the potential relationship conclusion are complete and all four inter-layer pointers can be resolved, the evidence chain completeness check passes; otherwise, it fails, and an incomplete record is registered for the current potential relationship conclusion. The evidence chain that passes the completeness check will be output as the entity relationship network analysis result.

2. The entity relationship network analysis method based on knowledge graphs according to claim 1, characterized in that, The specific process of rewriting the original records of multiple business systems into event-based records in a unified format, registering evidence pointers, and outputting a collection of event-based records is as follows: For each connected data source, register the data source identifier, data source affiliation, data reading method, and original record location method upon connection. Based on the data source type, determine the granularity of reading raw records from multiple business systems; Obtain the field mapping table. Based on the field mapping table, rewrite each original record into an event-based record containing seven elements. Obtain the seven elements, which are: subject of behavior, action, recipient, time of occurrence, location of occurrence, source of information, and original text location. Obtain evidence pointers for each original record. Evidence pointers include data source identifier, original text location, and read batch number. If a certain element cannot be obtained from the original record, then the corresponding element should be filled in as blank; Based on the event-based records and evidence pointers of each original record, output a collection of event-based records.

3. The entity relationship network analysis method based on knowledge graphs according to claim 1, characterized in that, The specific process of obtaining entities to be unified from the event record collection, comparing the evidence items of any two entities to be unified, and generating a list of paired judgment criteria is as follows: Extract all nominal components from the behavioral subject elements and the subject elements of the event-based record collection, and treat them one by one as entities to be unified. When the same nominal component appears in multiple event records, it is merged into the same entity to be unified, and the corresponding evidence pointer set is accumulated. Each entity to be unified is registered with its entity identifier, original name, set of evidence pointers, set of attribute values, and set of unique identifiers. For any two entities to be unified, compare the evidence items item by item, where the evidence items include identity consistency, attribute consistency, spatiotemporal compatibility, and overlap of related objects; Obtain the source level of each of the two entities to be normalized. The source level of the entity to be normalized is the highest level among all the data sources in which the entity to be normalized has appeared. For identifier consistency, first compare whether the identifier types in the unique identifier sets of the two entities to be normalized are the same. If the identifier types are different, no comparison is made and blank is output. If the identifier types are the same, if there are identifiers with exactly the same value, output consistent; if there are no identifiers with exactly the same value, output inconsistent; if there is a blank value on either side, output blank. For attribute consistency, compare the values ​​of the same attribute name in the attribute value sets of the two entities to be normalized. If the values ​​are the same, output "consistent"; if the values ​​are different, output "contradictory"; if there is a blank value under the same attribute name in either party, output "blank". For spatiotemporal compatibility, compare the occurrence time and location of the two entities to be unified: take the occurrence time and location of all event records of the occurrence of the two entities to be unified. If there are two event records whose occurrence time values ​​fall within the same natural day and whose occurrence location values ​​are different at the district / county level or above, then output a contradiction; if the above situation does not occur, output compatibility; if the occurrence time element or occurrence location element of either party is completely blank, then output blank. Regarding the overlap of associated objects, the first set of associated objects is formed by obtaining the other entities to be normalized from the event records that have appeared before the first entity to be normalized, excluding the current first entity to be normalized; the second set of associated objects is formed by obtaining the other entities to be normalized from the event records that have appeared before the second entity to be normalized, excluding the current second entity to be normalized; if the first set of associated objects and the second set of associated objects have an intersection, the output is "overlapping"; if there is no intersection, the output is "not overlapping". For source level, output the source level of each of the two entities to be normalized; For any two entities to be unified, they are denoted as a pair of entities to be unified. A list of paired judgment criteria is generated, which includes supporting items, conflicting items, and blank items.

4. The entity relationship network analysis method based on knowledge graphs according to claim 3, characterized in that, The specific process of merging entities to be normalized into normalized entities based on the list of pairwise determination criteria is as follows: Based on the list of paired decision criteria, for each entity to be normalized, the decision is performed in the following fixed order: If any conflict exists, it is determined that it cannot be merged, and a conflict is marked on the entity to be unified. If the identifiers are consistent, they are determined to be mergeable; If the number of supporting items is zero, it is determined that it cannot be merged, and the entity to be unified is marked as pending completion. If there are at least two supporting items, it is determined that it can be merged; if there is exactly one supporting item and the attributes or identifiers are consistent, it is determined that it can be merged; if there is exactly one supporting item and the related objects overlap, it is determined that it cannot be merged and is marked as pending supplementation. Pairs of entities that are determined to be mergeable and to be normalized are merged according to the transit rules and blocking rules, and the normalized entity is output. Obtain the unified entity identifier, preferred name, original name set, unique identifier set, attribute value set, evidence pointer set, and merging basis. Register the unified entity identifier, preferred name, original name set, unique identifier set, attribute value set, evidence pointer set, and merging basis for each unified entity.

5. The entity relationship network analysis method based on knowledge graphs according to claim 1, characterized in that, Combining the normalized entities, generating relation edges from the event-based record set, registering the number of supporting evidence entries, the number of independent sources, the evidence time interval, and other connected paths for each relation edge, labeling the relation strength level according to a fixed comparison order, and outputting the initial relation network are the specific processes as follows: Generate relation edges from the event-based record set. The corresponding relation types include behavioral relations, co-occurrence relations, financial transaction relations, organizational hierarchy relations, and spatiotemporal continuity relations. Output the set of relation edges. Obtain the relationship edge identifier, the starting unified entity identifier, the ending unified entity identifier, the relationship type, the number of supporting evidence items, the number of independent sources, the evidence time interval, and the list of supporting evidence pointers; The time frame for the evidence is the earliest and latest occurrence times; The strength level of the relationship is determined according to a fixed comparison order; The process of obtaining information on other connected paths is as follows: Using the starting and ending unified entities of the current relation edge as endpoints, enumerate all paths between the two points in the relation network after removing the current relation edge. If there is at least one path, register it as if there are other connected paths; otherwise, register it as if there are no other connected paths. For each relation edge, register the relation edge identifier, the starting unified entity identifier, the ending unified entity identifier, the relation type, the number of supporting evidence items, the number of independent sources, the earliest and latest occurrence times, the list of supporting evidence pointers, the relation strength level, and other connectivity path information; Output the initial relation network consisting of the normalized entities and the set of relation edges.

6. The entity relationship network analysis method based on knowledge graphs according to claim 5, characterized in that, The specific process for determining the strength level of a relationship according to a fixed comparison order is as follows: Each relation edge is evaluated level by level in the following fixed order: those that meet the evaluation criteria of the previous level are marked as the corresponding level, and those that do not meet the criteria are moved to the next level for evaluation: If the number of independent sources of a relation edge is not less than two, then the relation strength level is five. If the number of independent sources of a relation edge is less than two and the number of supporting evidence is not less than two, then the relation strength level is four. If the number of supporting evidence for a relation edge is less than two and the latest occurrence time is no more than the first preset time, then the relation strength level is level three. If the latest occurrence time of a relation edge is more than the first preset time from the current time, and there are other connected paths besides the current relation edge, then the relation strength level is level two. If there are no other connected paths besides the current relation edge, the relation strength level is level one.

7. A knowledge graph-based entity relationship network analysis system, applied to the knowledge graph-based entity relationship network analysis method described in any one of claims 1-6, characterized in that, include: The event-based record rewriting module is used to rewrite the original records of multiple business systems into event-based records in a unified format, register evidence pointers, and output a collection of event-based records. The unified entity merging module is used to obtain entities to be unified from the event-based record collection, compare the evidence items of any two entities to be unified item by item, generate a list of paired judgment criteria, and merge the entities to be unified into a unified entity based on the list of paired judgment criteria. The initial relation network output module is used to combine the normalized entities to generate relation edges from the event-based record set, register the number of supporting evidences, the number of independent sources, the evidence time interval, and other connected paths for each relation edge, label the relation strength level according to a fixed comparison order, and output the initial relation network. The potential relationship conclusion determination module is used to enumerate the support paths between two unified entities based on the initial relationship network, determine whether the support paths are independent of each other, perform removal recalculation for each support path, and determine the potential relationship conclusion. The evidence chain encapsulation module is used to encapsulate the evidence chain of the event record set, normalized entity, initial relationship network and potential relationship conclusion, and output the entity relationship network analysis results.

Images