Distributed knowledge graph new entity relationship reasoning system and method based on privacy evidence capsule

Abstract

The application discloses a distributed knowledge graph new entity relationship reasoning system and method based on privacy evidence capsules, and belongs to the technical field of knowledge graph reasoning. The method comprises the following steps: a server end receives an inductive knowledge graph completion query and activates a client end; the client end searches for local evidence related to the current query, performs privacy filtering, generates a privacy evidence capsule, and sends the privacy evidence capsule to the server end; the server end performs semantic alignment and calculates routing weight on the privacy evidence capsule, then performs evidence fusion to obtain a comprehensive support score, generates a conflict penalty term, and finally outputs a missing fact prediction result. The application reduces the risk of privacy leakage, adapts to the application scene of heterogeneous knowledge graphs of multiple institutions and multiple platforms, improves the reasoning pertinence and resource utilization efficiency, avoids the reasoning deviation caused by the simple aggregation mode, improves the accuracy and robustness of the new entity missing relationship prediction, and can output the evidence source and conflict explanation, and enhance the explainability of the reasoning result.

Description

Technical Field

[0001] This invention relates to a new entity relationship reasoning system and method based on privacy evidence capsules in distributed knowledge graphs, belonging to the field of knowledge graph reasoning technology. Background Technology

[0002] Knowledge graphs, which structure factual knowledge using triples of head entity-relationship-tail entity, have been widely applied in scenarios such as intelligent question answering, recommendation systems, medical auxiliary diagnosis, risk identification, industrial fault analysis, and enterprise knowledge management. Due to the continuous updating and iteration of knowledge, knowledge graphs often contain missing facts, thus requiring knowledge graph completion techniques to infer potential triple relationships.

[0003] Most existing knowledge graph completion methods are based on the transitive assumption that entities involved in the testing phase have already appeared in the training phase, and the model can learn fixed embedding representations for them. However, in practical applications, knowledge graphs are constantly evolving, with new users, patients, enterprises, devices, and products constantly emerging. These new entities have not participated in model training and cannot be directly used for reasoning through pre-trained embedding representations. To address this issue, inductive knowledge graph completion techniques can infer missing relationships based on a small number of supporting facts for new entities. However, existing solutions typically assume that the supporting facts for new entities are centrally stored in a single knowledge graph, which is not suitable for distributed data scenarios involving multiple institutions and platforms.

[0004] In real-world distributed scenarios, information related to the same entity is often scattered across multiple data holders. For example, different hospitals may hold partial medical records for the same patient, different industrial systems may store operation, maintenance, and alarm data for the same equipment, and different internet platforms may record different interactive behaviors of the same user. Due to restrictions related to privacy protection, data security, business competition, and compliance requirements, different data holders cannot directly exchange raw knowledge graph triples, nor can they centralize their local knowledge graph structures on a unified server for reasoning.

[0005] While federated learning enables model training and parameter aggregation without data leaving the local machine, traditional federated learning focuses on parameter sharing during the training phase. This makes it difficult to dynamically match relevant evidence to specific queries in inductive completion scenarios, and it also fails to effectively handle issues such as differences in the timeliness, semantic inconsistencies, and content conflicts of multi-source evidence. Simple parameter aggregation or score averaging can easily lead to biased inference results, making it difficult to guarantee the accuracy, robustness, and interpretability of predicting missing relationships for new entities. Summary of the Invention

[0006] To address the problems existing in the background technology, the present invention provides a new entity relationship reasoning system and method based on privacy evidence capsules in distributed knowledge graphs.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: a distributed knowledge graph-based new entity relation reasoning system based on privacy evidence capsules, comprising a server and multiple clients, each communicatively connected to the server, for storing local knowledge graphs; the server is equipped with a query receiving module for receiving inductive knowledge graph completion queries, a client activation module for filtering candidate client sets related to the current query based on query information, an evidence capsule alignment module for semantically aligning privacy evidence capsules returned by multiple clients, a reliability routing module for calculating routing weights for each privacy evidence capsule, a conflict-aware fusion module for detecting conflicts between multiple privacy evidence capsules and generating conflict penalty terms, a candidate entity ranking module for calculating the final score of candidate entities and outputting the prediction result of missing facts, and a result explanation module for outputting explanation information of the reasoning results; the clients are equipped with a local evidence retrieval module for retrieving local evidence related to the current query in the local knowledge graph, a privacy filtering module for performing privacy filtering on local evidence to hide sensitive information that can restore the local graph structure, and an evidence capsule generation module for generating irreversible privacy evidence capsules based on the privacy-filtered local evidence.

[0008] Furthermore, the inductive knowledge graph completion query includes new entities, query relationships, and positions to be predicted. The inductive knowledge graph completion query takes the form of tail entity prediction query and head entity prediction query.

[0009] Furthermore, the local evidence includes at least one of the following: a one-hop fact of the new entity, a relational neighborhood, a local path summary, an attribute summary, local time records and event records, local candidate entity scores, or relational role statistics.

[0010] The present invention discloses a reasoning method for a distributed knowledge graph-based novel entity relation reasoning system based on privacy evidence capsules, the method comprising the following steps:

[0011] S1: The server receives the knowledge graph completion query through the query receiving module;

[0012] S2: The server uses the client activation module to filter out a set of candidate clients related to the current query from multiple clients based on the query information, and sends query tasks to the candidate clients to complete the client activation;

[0013] S3: The activated client retrieves local evidence related to the current query from its own stored local knowledge graph through the local evidence retrieval module;

[0014] S4: The activated client performs privacy filtering on the retrieved local evidence through the privacy filtering module;

[0015] S5: The activated client generates an irreversible privacy evidence capsule based on the privacy-filtered local evidence through the evidence capsule generation module, and sends the privacy evidence capsule to the server.

[0016] S6: The server performs semantic alignment on the privacy evidence capsules returned by multiple clients through the evidence capsule alignment module, and then calculates the corresponding routing weight for each privacy evidence capsule through the reliability routing module.

[0017] S7: The server fuses evidence from multiple privacy evidence capsules based on routing weights to obtain a comprehensive support score for the candidate entity;

[0018] S8: The server detects conflicts between multiple privacy evidence capsules through the conflict-aware fusion module and generates corresponding conflict penalty items;

[0019] S9: The server uses the candidate entity sorting module to calculate the final score of the candidate entity by combining the comprehensive support score, conflict penalty score and basic link prediction score. Based on the final score, the candidate entities are sorted and the missing fact prediction results are output.

[0020] S10: The server outputs the prediction results of missing facts and simultaneously outputs the corresponding inference result explanation information through the result interpretation module.

[0021] Furthermore, step S2 includes the following steps:

[0022] S201: Match the client-coverable relationship types based on the query relationship;

[0023] S202: Determine whether the client may possess relevant partial evidence;

[0024] S203: Calculate the client activation score;

[0025] S204: Select clients with scores higher than the preset threshold as the activated clients.

[0026] Furthermore, step S4 includes the following steps:

[0027] S401: Anonymize, hash, or de-identify the original entity identifier;

[0028] S402: Deletion, generalization, or bucketing of sensitive attributes;

[0029] S403: Truncate the complete reasoning path and retain only the path type summary;

[0030] S404: Summarize the detailed adjacency structure;

[0031] S405: Add noise to local evidence, perform secure aggregation processing, or encrypt transmission according to a preset privacy level.

[0032] Further, S4 includes the following steps: S5 The privacy evidence capsule includes at least one of the following: a relation role summary indicating that the new entity is closer to the head entity role, tail entity role, or hybrid role in the current query relation; a local support vector indicating the support strength of the client's local evidence for the candidate entity or candidate entity set; a candidate entity sketch indicating the candidate entity in the form of a hash identifier, a bucket identifier, a secure alignment identifier, or an anonymous candidate set; a time validity label indicating the recentity, long-term validity, or expiration status of the local evidence; an uncertainty estimate indicating the sparsity of the local evidence, model confidence, relation coverage, and calibration error; and a privacy processing label indicating the privacy processing methods of entity anonymization, relation generalization, path truncation, noise injection, secure aggregation, or encrypted transmission.

[0033] Furthermore, the semantic alignment described in S6 includes at least one of the following:

[0034] S60101: Perform safe alignment of candidate entity sketches returned by different clients;

[0035] S60102: Perform unified mapping of relation role summaries;

[0036] S60103: Normalize time validity labels;

[0037] S60104: Parsing privacy processing tags;

[0038] S60105: Uniformly number and merge candidate entity support information from different clients.

[0039] Furthermore, the conflict mentioned in S8 includes at least one of the following: candidate entity conflict, which describes different clients supporting different candidate entities; relationship role conflict, which describes different clients having inconsistent judgments on the role of a new entity in the query relationship; time conflict, which describes new and old evidence giving different degrees of support to the same candidate entity; source credibility conflict, which describes conflict between high-credibility data sources and low-credibility data sources giving contradictory evidence; and privacy strength conflict, which describes differences in evidence availability due to different levels of privacy processing.

[0040] Furthermore, the final score of the candidate entity described in S9 is calculated as follows:

[0041] Final score for candidate entity = Overall support score - Conflict penalty score + Basic link prediction score

[0042] in:

[0043] The overall support score is obtained by weighted fusion of privacy evidence capsules from multiple clients;

[0044] The conflict penalty score is calculated by the conflict perception fusion module based on the conflict type and conflict intensity.

[0045] The basic link prediction score is generated by a knowledge graph completion model.

[0046] Compared with the prior art, the beneficial effects of the present invention are:

[0047] This invention generates irreversible privacy evidence capsules locally on the client side, enabling distributed collaborative reasoning among multiple data holders without sharing the original knowledge graph triples or exposing the local complete graph structure. This effectively reduces the risk of privacy leakage and is suitable for heterogeneous knowledge graph application scenarios across multiple institutions and platforms. It employs a query-driven client-side dynamic activation mechanism, which can match relevant evidence sources for specific completion tasks, improving the targeting of reasoning and the efficiency of resource utilization. Based on a reliability routing and conflict awareness fusion mechanism, it comprehensively evaluates the quality, timeliness, and conflict status of multi-source evidence, avoiding reasoning biases caused by simple aggregation methods and improving the accuracy and robustness of predicting missing relationships for new entities. Simultaneously, it can output evidence sources and conflict explanations, enhancing the interpretability of the reasoning results. Attached Figure Description

[0048] Figure 1 This is a structural block diagram of the system of the present invention;

[0049] Figure 2 This is a flowchart of the method of the present invention. Detailed Implementation

[0050] 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 invention, 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.

[0051] A novel distributed knowledge graph entity relation reasoning system based on privacy evidence capsules includes a server that does not centrally store the original knowledge graph triple data, but only receives queries, schedules clients, processes privacy evidence capsules, and outputs reasoning results; and multiple clients, each communicatively connected to the server, deployed in different data holders or different business systems to store local knowledge graphs. The server includes a query receiving module for receiving inductive knowledge graph completion queries, a client activation module for filtering a set of candidate clients related to the current query from multiple clients based on query information, an evidence capsule alignment module for semantically aligning the privacy evidence capsules returned by multiple clients, and a mechanism for evaluating the relationship between the privacy evidence capsule and the current query relation based on the semantic relevance of the privacy evidence capsule and the matching degree between the candidate entity and the privacy evidence capsule, the support strength of local support vectors, the coverage of local client relations, the validity of evidence time, and uncertainty estimation. The system includes a reliability routing module that calculates routing weights for privacy evidence capsules on different clients based on client historical reliability and privacy processing strength; a conflict-aware fusion module that detects conflicts between multiple privacy evidence capsules and generates conflict penalty terms; a candidate entity ranking module that calculates the final score of candidate entities based on the comprehensive support score, conflict penalty terms, and basic link prediction score and outputs the prediction result of missing facts; and a result explanation module that outputs explanation information for the reasoning results. The client is equipped with a local evidence retrieval module that retrieves local evidence related to the current query in the client's local knowledge graph; a privacy filtering module that performs privacy filtering on the retrieved local evidence to delete or hide the original entity identifier, sensitive attributes, complete relational paths, detailed adjacency structures, and sensitive information that can restore the local graph structure; and an evidence capsule generation module that generates irreversible privacy evidence capsules based on the privacy-filtered local evidence.

[0052] The modules are connected sequentially according to the data flow direction, and the query data and evidence data are transmitted and processed sequentially along the module links.

[0053] Furthermore, the inductive knowledge graph completion query includes new entities, query relationships, and positions to be predicted. The inductive knowledge graph completion query takes the form of tail entity prediction query and head entity prediction query.

[0054] The tail entity prediction query is: new entity - query relationship - tail entity to be predicted;

[0055] The head entity prediction query is the head entity to be predicted — query relationship — new entity;

[0056] New entities refer to entities that did not appear or were not fully modeled during the training phase, such as new users, new patients, new enterprises, new equipment, new products, new failure events, or new risk events.

[0057] Furthermore, the local evidence includes at least one of the following: a one-hop fact of the new entity, a relational neighborhood related to the query relation, a local path summary related to the candidate entity, an attribute summary of the new entity, local time records and event records, local candidate entity scores, or relational role statistics of the new entity in the query relation (head-end role, tail-end role, or mixed role).

[0058] The present invention discloses a reasoning method for a distributed knowledge graph-based novel entity relation reasoning system based on privacy evidence capsules, the method comprising the following steps:

[0059] S1: The server receives the knowledge graph completion query through the query receiving module;

[0060] S2: The server parses the query content through the client activation module, extracts the new entity anonymization identifier, query relationship, predicted location, and task constraints. Based on the query information, it filters out a set of candidate clients related to the current query from multiple clients deployed in different data holders or business systems, and issues query tasks to the candidate clients to complete client activation. The task constraints include at least one of the following: candidate entity type constraints, time range constraints, client access permission constraints, privacy level constraints, and maximum communication rounds constraints. The query information includes query relationships, new entity anonymization identifiers, client relationship pattern coverage information, historical inference validity information, and security matching results.

[0061] S3: The activated client retrieves local evidence related to the current query from its own stored local knowledge graph through the local evidence retrieval module;

[0062] S4: The activated client performs privacy filtering on the retrieved partial evidence through the privacy filtering module to prevent the leakage of raw data;

[0063] S5: The activated client generates an irreversible privacy evidence capsule based on the local evidence after privacy filtering through the evidence capsule generation module, and sends the privacy evidence capsule to the server. The client only uploads the privacy evidence capsule and does not upload the original knowledge graph triples, complete adjacency lists, complete reasoning paths or local complete graph structures.

[0064] S6: The server performs semantic alignment on the privacy evidence capsules returned by multiple clients through the evidence capsule alignment module, and then calculates the corresponding routing weight for each privacy evidence capsule based on the evidence quality and query relevance through the reliability routing module.

[0065] When the evidence capsule has high support strength, recent time stamp, low uncertainty, and high historical reliability, a higher routing weight is assigned; when the evidence capsule has sparse evidence, expired time stamp, or strong privacy perturbation, a lower routing weight is assigned.

[0066] S7: The server fuses evidence from multiple privacy evidence capsules based on routing weights to obtain a comprehensive support score for the candidate entity;

[0067] Specifically, for each candidate entity, the server performs a weighted calculation based on the local support strength of each evidence capsule and the corresponding routing weight to obtain the evidence support score of the candidate entity, i.e., the comprehensive support score.

[0068] S8: The server detects conflicts between multiple privacy evidence capsules through the conflict-aware fusion module and generates corresponding conflict penalty items based on the conflict type and intensity.

[0069] The conflict handling rules are as follows: when the conflict level is lower than a preset threshold, the server will downgrade the conflict evidence; when the conflict level is higher than the preset threshold, the server will divide the conflict evidence into different evidence clusters and calculate the candidate entity ranking for each evidence cluster.

[0070] S9: The server uses the candidate entity sorting module to calculate the final score of the candidate entities by combining the comprehensive support score, conflict penalty score and basic link prediction score. The candidate entities are sorted from high to low according to the final score, and the missing fact prediction results are output.

[0071] S10: The server sorts the candidate entities according to their final scores and outputs the missing fact prediction results. Simultaneously, the server outputs the corresponding reasoning result explanation information through the result interpretation module.

[0072] The inference results description includes the predicted entity, the Top-K candidate entity ranking, the confidence level, a summary of the evidence source, a description of the conflict type, and a description of the privacy handling process.

[0073] When the server detects a significant conflict among multiple privacy evidence capsules, the server may initiate a secondary evidence request to at least one client. The secondary evidence request is used to request the client to return a statistical summary, candidate entity reordering results, local consistency proof, or supplementary privacy evidence capsules to further optimize the inference results.

[0074] Furthermore, step S2 includes the following steps:

[0075] S201: Match the client-coverable relationship types based on the query relationship;

[0076] S202: Determine whether the client may hold relevant local evidence based on the new entity desensitization identifier or security matching results;

[0077] S203: Calculate the client activation score based on the client's historical reasoning validity, response latency, and data credibility;

[0078] S204: Select clients with scores higher than the preset threshold as the activated clients.

[0079] Furthermore, step S4 includes the following steps:

[0080] S401: Anonymize, hash, or de-identify the original entity identifier to hide the entity's true identity;

[0081] S402: Sensitive attributes are deleted, generalized, or bucketed to reduce the identifiability of attribute information;

[0082] S403: Truncate the complete inference path, retain only the path type summary, and do not disclose the complete inference link;

[0083] S404: Summarize the detailed adjacency structure to prevent the server from reconstructing the complete local graph structure based on adjacency information;

[0084] S405: Add noise, perform secure aggregation processing, or encrypt transmission to local evidence according to the preset privacy level to further enhance privacy protection.

[0085] Furthermore, the privacy evidence capsule described in S5 is an irreversible evidence summary related to the query, including at least one of the following: a relation role summary indicating that the new entity is closer to the head entity role, tail entity role, or hybrid role in the current query relation; a local support vector indicating the strength of support of the client's local evidence for the candidate entity or candidate entity set; a candidate entity sketch indicating the candidate entity in the form of a hash identifier, a bucket identifier, a secure alignment identifier, or an anonymous candidate set; a time validity label indicating the recentity, long-term validity, or expiration status of the local evidence; an uncertainty estimate indicating the sparsity of the local evidence, model confidence, relation coverage, and calibration error; and a privacy processing label indicating privacy processing methods such as entity anonymization, relation generalization, path truncation, noise injection, secure aggregation, or encrypted transmission.

[0086] Furthermore, the semantic alignment described in S6 includes at least one of the following:

[0087] S60101: Perform safe alignment of candidate entity sketches returned by different clients;

[0088] S60102: Perform unified mapping of relation role summaries;

[0089] S60103: Normalize time validity labels;

[0090] S60104: Parse privacy processing tags to determine the strength of evidence availability;

[0091] S60105: Uniformly number and merge candidate entity support information from different clients.

[0092] Furthermore, the conflict mentioned in S8 includes at least one of the following: candidate entity conflict, which describes different clients supporting different candidate entities; relationship role conflict, which describes different clients having inconsistent judgments on the role of a new entity in the query relationship; time conflict, which describes new and old evidence giving different degrees of support to the same candidate entity; source credibility conflict, which describes conflict between high-credibility data sources and low-credibility data sources giving contradictory evidence; and privacy strength conflict, which describes differences in evidence availability due to different levels of privacy processing.

[0093] Furthermore, the final score of the candidate entity described in S9 is calculated as follows:

[0094] Final score for candidate entity = Overall support score - Conflict penalty score + Basic link prediction score

[0095] in:

[0096] The overall support score is obtained by weighted fusion of privacy evidence capsules from multiple clients;

[0097] The conflict penalty score is calculated by the conflict perception fusion module based on the conflict type and conflict intensity.

[0098] The basic link prediction score is generated by a knowledge graph completion model;

[0099] The knowledge graph completion model includes a knowledge graph embedding model, a graph neural network model, a rule-based reasoning model, a path-based reasoning model, a large language model-enhanced reasoning model, or a combination of the above models.

[0100] Example 1:

[0101] This embodiment addresses the scenario of missing fault relationship reasoning for newly connected devices in an industrial setting. Different business systems store local status information of the device, including the device operation system, maintenance record system, alarm monitoring system, and production scheduling system. None of the business systems can directly upload the original triplet data to the server.

[0102] The specific reasoning process is as follows:

[0103] S1: Server receives query: New device E—may occur—?;

[0104] Among them, the new device E is a new entity that did not appear in the training phase. It may be a query relationship. The position to be predicted is the tail entity, which is to predict the possible fault types of the new device E.

[0105] S2: The server parses the query, determines the potential fault type of the new equipment E as the inference target, and activates the equipment operation system client, maintenance record system client, alarm monitoring system client and production scheduling system client based on the query relationship - possible, the de-identification identifier of the new equipment E and the client relationship coverage information.

[0106] S3: Each activated client retrieves relevant evidence from the local knowledge graph.

[0107] in,

[0108] The partial evidence retrieved by the equipment operation system client is as follows: the new equipment E has recently experienced high operating current, large temperature fluctuations, and abnormal load changes;

[0109] The partial evidence retrieved by the maintenance record system client is: the new equipment E and similar equipment have experienced bearing wear and transmission component abnormalities multiple times in the past;

[0110] The local evidence retrieved by the alarm monitoring system client is as follows: vibration alarms and temperature alarms have recently occurred in the area where the new device E is located;

[0111] The local evidence retrieved by the production scheduling system client is: new equipment E has been operating at high load for a recent period of time.

[0112] S4: Each client performs privacy filtering on local evidence separately.

[0113] The device operation system client hides the original device number, specific sensor number, and complete time series;

[0114] The maintenance record system client hides maintenance personnel information, specific maintenance order numbers, and detailed maintenance text;

[0115] The alarm monitoring system client hides the plaintext identifier of the alarm device and the complete alarm log;

[0116] The production scheduling system client hides team information, work plans in plain text, and specific production task numbers.

[0117] S5: Each client generates a privacy evidence capsule based on the privacy-filtered evidence and sends it to the server.

[0118] The equipment operation system client generates evidence capsule C1: the relation role summary is a new entity represented as the equipment role; the local support vectors are the supporting candidate faults—bearing abnormality, overload operation, transmission abnormality; the time validity label is recent; the uncertainty estimation is moderate; the privacy processing labels are anonymized equipment number, generalized sensor number, and time series summary.

[0119] The maintenance record system client generates evidence capsule C2: the relational role summary is a new entity represented as the equipment role; the local support vectors support candidate faults—bearing wear and transmission component abnormality; the time validity label is long-term validity; the uncertainty estimate is low; the privacy processing label is maintenance record summarization and maintenance personnel information deletion.

[0120] The alarm monitoring system client generates evidence capsule C3: the relation role summary is a new entity represented as a device role; the local support vectors support candidate faults—vibration anomaly, temperature anomaly; the time validity label is recent; the uncertainty estimate is low; the privacy processing labels are alarm log summarization and alarm source anonymization.

[0121] The production scheduling system client generates evidence capsule C4: the relational role summary is a new entity represented as an equipment role; the local support vector is the supporting candidate reason—continuous high load operation; the time validity label is recent; the uncertainty estimation is moderate; the privacy processing label is job task generalization and team information deletion.

[0122] S6: The server receives four evidence capsules. First, it performs semantic alignment, aligning bearing anomalies and bearing wear into the same candidate fault category, and aligning transmission anomalies and transmission component anomalies into the same candidate fault category. Then, it calculates the routing weight of each evidence capsule. C1 and C3 are from recent operation and alarm evidence, which are highly relevant to the current query and are assigned higher weights. C2 is from historical maintenance evidence, which is highly reliable but has a long validity period and is assigned medium-high weights. C4 is from production scheduling evidence, which is evidence explaining the cause of the fault rather than direct fault evidence and is assigned medium weights.

[0123] S7: The server merges multiple evidence capsules based on routing weights and calculates the overall support score for each candidate fault.

[0124] The fusion results are as follows: bearing abnormalities are supported by both C1 and C2; transmission abnormalities are supported by both C1 and C2; temperature abnormalities are supported by both C1 and C3; and overload operation is supported by both C1 and C4.

[0125] S8: The server performs conflict detection;

[0126] Among them, C3 shows that the recent temperature alarm is strong, but there is no corresponding historical fault record in C2, so it is marked as a time conflict. This evidence is not directly discarded, but is processed with reduced weight; C4 shows that the equipment has been running at high load for a long time, which serves as strengthening evidence for the candidate cause of overload operation, and there is no conflict.

[0127] S9: The server calculates and sorts the final scores of each candidate entity, and the output is as follows:

[0128] Top 1: Bearing malfunction;

[0129] Top 2: Transmission malfunction;

[0130] Top 3: Overload operation;

[0131] Top 4: Abnormal temperature.

[0132] Simultaneously, the following explanatory information is output: The prediction result is that the new equipment E may have a bearing abnormality; the main sources of evidence are equipment operation system evidence capsule C1 and maintenance record system evidence capsule C2; ​​the auxiliary sources of evidence are alarm monitoring system evidence capsule C3 and production scheduling system evidence capsule C4; the conflict explanation is that there is recent evidence of temperature abnormality but insufficient support from historical maintenance, which is output as an alternative risk; the privacy explanation is that each client did not upload the original triplet, complete path or local graph structure.

[0133] Example 2

[0134] This embodiment addresses the scenario of interest category relationship reasoning for new users in an internet context. Different platforms store the user's local behavioral data separately, including browsing platforms, purchasing platforms, content platforms, and membership service platforms. The original behavioral triplet data of the user cannot be directly shared between the platforms.

[0135] The specific reasoning process is as follows:

[0136] S1: The server receives a query: New user U—may be interested in—?;

[0137] S2: The server activates the browsing platform client, purchasing platform client, content platform client, and membership service platform client based on the query relationship—potentially interested and the de-identified identifier of new user U.

[0138] S3: Each client retrieves local evidence related to the new user U. The browsing platform retrieves a summary of the product categories the user recently browsed; the purchasing platform retrieves a summary of the user's historical purchasing behavior; the content platform retrieves a summary of the content topics the user recently clicked; and the membership service platform retrieves a summary of the user's subscription preferences.

[0139] S4: Each client performs privacy filtering and does not upload user plaintext IDs, product plaintext IDs, complete browsing paths, and original purchase records.

[0140] S5: Each client generates a privacy evidence capsule, which includes a summary of the user's role, a sketch of candidate interest categories, local support strength, time validity labels, and uncertainty estimates.

[0141] S6: The server performs semantic alignment on multiple evidence capsules, mapping candidate categories from different platforms to a unified interest category space; then, it calculates routing weights based on evidence recentity, platform historical reliability, and support strength.

[0142] S7: The server integrates the supporting information from each evidence capsule and calculates the overall support score for each candidate interest category.

[0143] S8: Server detects conflicts. If the browsing platform shows that the user has recently been interested in a certain type of product, while the purchase platform's history shows a preference for another type of product, it is identified as a time conflict. The weight of recent evidence is increased, while historical preferences are retained as alternative candidates.

[0144] S9: The server outputs the Top-K interest category prediction results and provides the main sources of evidence and conflict explanations.

[0145] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0146] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A novel entity relation reasoning system based on a distributed knowledge graph using privacy-preserving evidence capsules, comprising a server and multiple clients, each communicatively connected to the server, for storing local knowledge graphs; characterized in that: The server-side includes a query receiving module for receiving inductive knowledge graph completion queries, a client activation module for filtering candidate client sets related to the current query based on query information, an evidence capsule alignment module for semantically aligning privacy evidence capsules returned by multiple clients, a reliability routing module for calculating routing weights for each privacy evidence capsule, a conflict-aware fusion module for detecting conflicts between multiple privacy evidence capsules and generating conflict penalty terms, a candidate entity ranking module for calculating the final score of candidate entities and outputting the prediction result of missing facts, and a result explanation module for outputting explanation information of the reasoning results. The client-side includes a local evidence retrieval module for retrieving local evidence related to the current query in the local knowledge graph, a privacy filtering module for performing privacy filtering on local evidence to hide sensitive information that can restore the local graph structure, and an evidence capsule generation module for generating irreversible privacy evidence capsules based on the privacy-filtered local evidence.

2. The distributed knowledge graph-based new entity relation reasoning system based on privacy evidence capsules according to claim 1, characterized in that: The inductive knowledge graph completion query includes new entities, query relations, and positions to be predicted. The inductive knowledge graph completion query takes the form of tail entity prediction query and head entity prediction query.

3. The distributed knowledge graph-based new entity relation reasoning system based on privacy evidence capsules according to claim 1, characterized in that: The local evidence includes at least one of the following: one-hop facts of the new entity, relational neighborhood, local path summary, attribute summary, local time record and event record, local candidate entity score or relational role statistics.

4. A reasoning method for a distributed knowledge graph novel entity relation reasoning system based on privacy evidence capsules according to any one of claims 1-3, characterized in that: The method includes the following steps: S1: The server receives the knowledge graph completion query through the query receiving module; S2: The server uses the client activation module to filter out a set of candidate clients related to the current query from multiple clients based on the query information, and sends query tasks to the candidate clients to complete the client activation; S3: The activated client retrieves local evidence related to the current query from its own stored local knowledge graph through the local evidence retrieval module; S4: The activated client performs privacy filtering on the retrieved local evidence through the privacy filtering module; S5: The activated client generates an irreversible privacy evidence capsule based on the privacy-filtered local evidence through the evidence capsule generation module, and sends the privacy evidence capsule to the server. S6: The server performs semantic alignment on the privacy evidence capsules returned by multiple clients through the evidence capsule alignment module, and then calculates the corresponding routing weight for each privacy evidence capsule through the reliability routing module. S7: The server fuses evidence from multiple privacy evidence capsules based on routing weights to obtain a comprehensive support score for the candidate entity; S8: The server detects conflicts between multiple privacy evidence capsules through the conflict-aware fusion module and generates corresponding conflict penalty items; S9: The server uses the candidate entity sorting module to calculate the final score of the candidate entity by combining the comprehensive support score, conflict penalty score and basic link prediction score. Based on the final score, the candidate entities are sorted and the missing fact prediction results are output. S10: The server outputs the prediction results of missing facts and simultaneously outputs the corresponding inference result explanation information through the result interpretation module.

5. The method according to claim 4, characterized in that: S2 includes the following steps: S201: Match the client-coverable relationship types based on the query relationship; S202: Determine whether the client may possess relevant partial evidence; S203: Calculate the client activation score; S204: Select clients with scores higher than the preset threshold as the activated clients.

6. The method according to claim 4, characterized in that: S4 includes the following steps: S401: Anonymize, hash, or de-identify the original entity identifier; S402: Deletion, generalization, or bucketing of sensitive attributes; S403: Truncate the complete reasoning path and retain only the path type summary; S404: Summarize the detailed adjacency structure; S405: Add noise to local evidence, perform secure aggregation processing, or encrypt transmission according to a preset privacy level.

7. The method according to claim 4, characterized in that: S4 includes the following steps: S5 The privacy evidence capsule includes at least one of the following: a relation role summary indicating that the new entity is closer to the head entity role, tail entity role, or hybrid role in the current query relation; a local support vector indicating the support strength of the client's local evidence for the candidate entity or candidate entity set; a candidate entity sketch indicating the candidate entity in the form of a hash identifier, a bucket identifier, a secure alignment identifier, or an anonymous candidate set; a time validity label indicating the recentity, long-term validity, or expiration status of the local evidence; an uncertainty estimate indicating the sparsity of the local evidence, model confidence, relation coverage, and calibration error; and a privacy processing label indicating the privacy processing methods of entity anonymization, relation generalization, path truncation, noise injection, secure aggregation, or encrypted transmission.

8. The method according to claim 4, characterized in that: The semantic alignment described in S6 includes at least one of the following: S60101: Perform safe alignment of candidate entity sketches returned by different clients; S60102: Perform unified mapping of relation role summaries; S60103: Normalize time validity labels; S60104: Parsing privacy processing tags; S60105: Uniformly number and merge candidate entity support information from different clients.

9. The method according to claim 4, characterized in that: The conflict described in S8 includes at least one of the following: candidate entity conflict, which describes different clients supporting different candidate entities; relationship role conflict, which describes different clients having inconsistent judgments on the role of a new entity in the query relationship; time conflict, which describes new and old evidence giving different degrees of support to the same candidate entity; source credibility conflict, which describes conflict between high-credibility data sources and low-credibility data sources giving contradictory evidence; and privacy strength conflict, which describes differences in evidence availability due to different levels of privacy processing.

10. The method according to claim 4, characterized in that: The final score of the candidate entity mentioned in S9 is calculated as follows: Final score for candidate entity = Overall support score - Conflict penalty score + Basic link prediction score in: The overall support score is obtained by weighted fusion of privacy evidence capsules from multiple clients; The conflict penalty score is calculated by the conflict perception fusion module based on the conflict type and conflict intensity. The basic link prediction score is generated by a knowledge graph completion model.

Images