Retrieval enhancement generation method and device

Abstract

The invention discloses a retrieval enhancement generation method and device. And each node performs privacy processing on the difficult negative sample to obtain ETP. And the server can only contact the desensitized data, so that private domain data leakage is avoided. And by comparing the query activeness with the upper limit threshold, the control node uploads the ETP and the weight adjustment value of the local micro-adaptation layer to the server, receives and replays the ETP and issues the weight adjustment value, and reduces the overall bandwidth peak value. And the server shuffles the ETP to obtain a playback ETP, so that local training data is enriched, the model generalization is improved, the node cannot deduce the original data distribution of other nodes, and the privacy is further protected. And the server integrates the weight adjustment value to obtain an issued weight adjustment value, so that the model is prevented from deviating from global optimum due to local optimization, and individuation and generalization capabilities are balanced. The node receives data to perform negative sample training, continuously updates a local retriever, improves interference item elimination capability and retrieval result correlation, and optimizes long-tail query processing capability.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and apparatus for retrieval enhancement generation. Background Technology

[0002] Retrieval-Augmented Generation (RAG), applied to large language models, can enhance knowledge fragments retrieved from external corpora, enabling the large language model to output more factual answers. However, external private corpora are usually scattered across multi-tenant data centers, local servers, and mobile terminals, resulting in poor data privacy.

[0003] To address the issue of poor data privacy, federated learning (FL) has been introduced in existing technologies. This method allows nodes to train locally and only upload gradients for aggregation. However, traditional FL methods only aggregate weights at the model level, failing to synchronize new knowledge or negative samples from the retrieval end, which can easily lead to overfitting of the retrieval system. Furthermore, it lengthens the update cycle of large language models, making it difficult to meet the minute-level knowledge injection requirements. Summary of the Invention

[0004] To address the aforementioned issues, this application provides a method and apparatus for retrieval enhancement generation, thereby overcoming the shortcomings of existing RAG methods in terms of privacy protection and real-time updates.

[0005] This application discloses a method for generating enhanced search results, the method comprising:

[0006] Each node performs privacy processing on the difficult negative samples encountered during the local retrieval process to obtain the Evidence Token Packet (ETP).

[0007] Each node obtains the query activity level during the local retrieval process;

[0008] When the query activity is greater than or equal to a preset upper limit threshold, the node uploads the ETP and the weight adjustment value of the local micro-adaptation layer to the server, and receives the replay ETP and the distributed weight adjustment value from the server; the replay ETP is obtained by the server shuffling all the received ETPs, and the distributed weight adjustment value is obtained by the server integrating all the received weight adjustment values.

[0009] The nodes perform local training based on the replay ETP and the distributed weight adjustment value, and update the local retrieval machines of each node.

[0010] Optionally, each node performs privacy processing on the difficult negative samples in the local retrieval process to obtain an Evidence Token Packet (ETP), including:

[0011] During the local retrieval process, the difficult negative samples in the local retrieval device are obtained;

[0012] Laplace noise and Gaussian noise are added to the difficult negative sample and the generation preference of the difficult negative sample to obtain the ETP with differential privacy noise.

[0013] Optionally, each of the nodes obtains the query activity during the local retrieval process, including:

[0014] During the local retrieval process, basic counts are collected in real time; these basic counts include the number of query calls, the number of terms returned by the query, and the number of terms generated within a preset time window.

[0015] The basic count is normalized using a sliding window method to obtain a normalized count vector;

[0016] The query activity is calculated based on the normalized counting vector.

[0017] Optionally, after each node obtains the query activity during the local retrieval process, the method further includes:

[0018] If the query activity level is between the upper limit threshold and the preset lower limit threshold, the node's upload behavior is stopped, and only the replay ETP and the weight adjustment value are received.

[0019] If the query activity level is less than or equal to the lower threshold, the node's upload and receive behavior shall be stopped.

[0020] Optionally, the server shuffles all received ETPs to obtain the replay ETP, and replays the replay ETP to each of the nodes, including:

[0021] The server delivers the received ETP to a temporary sub-queue corresponding to the source node of the ETP; the temporary sub-queue is obtained by the server setting up a temporary storage area and dividing the temporary storage area.

[0022] When the accumulated data in the temporary storage area reaches a preset data volume, or when the temporary storage area reaches a preset shuffling cycle, the server performs random shuffling on the ETPs in the temporary storage area to obtain the replay ETPs.

[0023] After the shuffling is completed, the server randomly selects a target node for each replay ETP; the target node is different from the source node of the replay ETP.

[0024] The server replays each of the replay ETPs to the target node corresponding to the replay ETP.

[0025] Optionally, the server integrates all received weight adjustment values ​​to obtain the issued weight adjustment value, including:

[0026] The server performs a weighted average of the weight adjustment values ​​according to the query volume of each node to obtain a global update weight adjustment value; the global update weight adjustment value is used for the global update of low-rank adaptation LoRA.

[0027] The server reads the difficult negative samples from the received ETP;

[0028] The server injects the difficult negative samples into the low-rank adaptation backbone through knowledge distillation to obtain distillation weight adjustment values;

[0029] The server adds the global update weight adjustment value and the distillation weight adjustment value together to obtain the distributed weight adjustment value.

[0030] Optionally, before the server replays each of the replay ETPs to the target node corresponding to the replay ETP, the method further includes:

[0031] The server sets a counter for each node to record the number of difficult negative samples for that node;

[0032] When the server replays the replay ETP to the node, the value of the node's counter increases;

[0033] When the node completes training or reaches a preset timeout, the value of the node's counter decreases.

[0034] If the server determines, based on the value of the counter, that the number of difficult negative samples in the target node exceeds a preset number, the target node for the replay ETP will be replaced.

[0035] Optionally, after obtaining the weight adjustment value, the method further includes:

[0036] The server obtains the bandwidth utilization rate and the rate of decrease in global verification loss within a preset time period.

[0037] The server adjusts the upper limit threshold based on the bandwidth utilization and the rate of decrease.

[0038] Optionally, after updating the local retriever of each node, the method further includes:

[0039] The nodes split and map the local index to obtain a Bloom bitmap;

[0040] The node merges the Bloom bitmap to obtain a routing label;

[0041] The node performs chained Poseidon hashing on the Bloom bitmap to obtain the root hash;

[0042] The node performs BLS signature processing on the root hash to obtain a signature;

[0043] The node uploads the routing tag, the root hash, and the signature to the server, so that the server determines the initial screening node based on the routing tag, obtains the zero-knowledge proof of the initial screening node according to the Bloom-Hash Signature Chain Protocol, and accesses the authorized local index based on the signature and the zero-knowledge proof after the initial screening node has completed the verification.

[0044] Based on the above-mentioned method for generating retrieval enhancement, this application also discloses an apparatus for generating retrieval enhancement, including: a processing unit, an acquisition unit, an uploading unit, and a training unit;

[0045] The processing unit is used by each node to perform privacy processing on the difficult negative samples in the local retrieval process to obtain the Evidence Token Packet (ETP).

[0046] The acquisition unit is used by each node to acquire the query activity during the local retrieval process;

[0047] The upload unit is configured to, when the query activity is greater than or equal to a preset upper limit threshold, upload the ETP and the weight adjustment value of the local micro-adaptation layer to the server, and receive the replay ETP and the distributed weight adjustment value from the server; the replay ETP is obtained by the server shuffling all the received ETPs, and the distributed weight adjustment value is obtained by the server integrating all the received weight adjustment values.

[0048] The training unit is used for the nodes to perform local training based on the replay ETP and the distributed weight adjustment value, and to update the local retrieval of each node.

[0049] Optionally, the processing unit includes:

[0050] The sample acquisition subunit is used to acquire the difficult negative samples in the local searcher during the local search process;

[0051] A noise-adding subunit is used to add Laplace noise and Gaussian noise to the difficult negative sample and the generation preference of the difficult negative sample to obtain the ETP with added differential privacy noise.

[0052] Optionally, the acquisition unit includes:

[0053] The counting subunit is used to collect basic counts in real time during the local retrieval process; the basic counts include the number of query calls, the number of terms returned by the query, and the number of terms generated within a preset time window;

[0054] The normalization subunit is used to perform sliding window normalization on the basic count to obtain a normalized count vector;

[0055] An activity calculation subunit is used to calculate the query activity based on the normalized count vector.

[0056] Optionally, the device further includes:

[0057] The upload stop unit is used to stop the node's upload behavior when the query activity is between the upper limit threshold and the preset lower limit threshold, and only receive the replay ETP and the weight adjustment value.

[0058] The freeze unit is used to stop the node's upload and receive behavior when the query activity is less than or equal to the lower threshold.

[0059] Optionally, the upload unit includes:

[0060] The delivery subunit is used by the server to deliver the received ETP to a temporary subqueue corresponding to the source node of the ETP; the temporary subqueue is obtained by the server setting up a temporary storage area and dividing the temporary storage area.

[0061] The shuffling subunit is used to randomly shuffle the ETPs in the temporary storage area when the accumulated data in the temporary storage area reaches a preset data amount or the temporary storage area reaches a preset shuffling cycle, so as to obtain the replay ETP.

[0062] The extraction subunit is used to randomly select a target node for each replay ETP after the shuffling is completed; the target node is different from the source node of the replay ETP.

[0063] The replay subunit is used by the server to replay each replay ETP to the target node corresponding to the replay ETP.

[0064] Optionally, the upload unit includes:

[0065] The averaging subunit is used by the server to perform a weighted average of the weight adjustment values ​​according to the query volume of each node to obtain a global update weight adjustment value; the global update weight adjustment value is used for the global update of low-rank adaptation LoRA.

[0066] A reading subunit is used by the server to read the difficult negative samples in the received ETP;

[0067] The distillation subunit is used by the server to inject the difficult negative samples into the low-rank adaptation backbone through knowledge distillation, thereby obtaining the distillation weight adjustment value.

[0068] The overlay subunit is used by the server to overlay the global update weight adjustment value and the distillation weight adjustment value to obtain the issued weight adjustment value.

[0069] Optionally, the device further includes:

[0070] A recording unit is provided for the server to set a counter for each node to record the number of difficult negative samples of the node.

[0071] An incrementing unit is provided to increment the value of a counter on the node when the server replays the replay ETP to the node.

[0072] A reduction unit is used to reduce the value of the counter of a node when the node completes training or reaches a preset timeout.

[0073] The replacement unit is used to replace the target node for the replay ETP when the server determines, based on the value of the counter, that the number of difficult negative samples in the target node exceeds a preset number.

[0074] Optionally, the device further includes:

[0075] The feedback acquisition unit is used by the server to acquire the bandwidth utilization rate and the rate of decrease of global verification loss within a preset time period;

[0076] A threshold adjustment unit is used by the server to adjust the upper limit threshold according to the bandwidth utilization rate and the rate of decrease.

[0077] Optionally, the device further includes:

[0078] A mapping unit is used by the node to split and map the local index to obtain a Bloom bitmap;

[0079] A merging unit is used by the nodes to merge the Bloom bitmap to obtain routing tags;

[0080] A hash unit is used by the node to perform chained Poseidon hashing on the Bloom bitmap to obtain the root hash.

[0081] A signature unit is used by the node to perform BLS signature processing on the root hash to obtain a signature;

[0082] The verification unit is used for the node to upload the routing tag, the root hash, and the signature to the server, so that the server can determine the initial screening node based on the routing tag, obtain the zero-knowledge proof of the initial screening node according to the Bloom-Hash Signature Chain Protocol, and access the authorized local index based on the signature and the zero-knowledge proof after the initial screening node has completed the verification.

[0083] This application discloses a method and apparatus for generating enhanced search results. Each node performs privacy processing on difficult negative samples encountered during the local search process to obtain an Evidence Token Packet (ETP). This ensures that the server can only access the anonymized data, preventing the leakage of nodes' private data. When the query activity is greater than or equal to a preset upper threshold, the node uploads the ETP and the weight adjustment values ​​of its local micro-adaptation layer to the server and receives the echo ETP and the distributed weight adjustment values ​​from the server. This upper threshold provides flexible dynamic gating for the node's upload frequency and downlink rhythm, reducing the overall bandwidth peak. The echo ETP is obtained by the server shuffling all received ETPs, which not only enriches the local training data and improves the model's generalization ability but also prevents nodes from inferring the original data distribution of other nodes through ETP features, further protecting privacy. The distributed weight adjustment values ​​are obtained by the server integrating all received weight adjustment values, avoiding local optimization that could cause the model to deviate from the global optimum, balancing personalization and generalization ability. Nodes train on negative samples based on the echo ETP and the distributed weight adjustment values, improving their ability to eliminate interference and the relevance of search results, and gradually optimizing their ability to handle long-tail queries. Furthermore, negative samples can provide feedback, helping the model to more quickly identify optimization directions and reducing the number of training iterations. Nodes continuously update their local retrieval machines based on training results, forming a virtuous cycle of "training-feedback-retraining". Attached Figure Description

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

[0085] Figure 1 This is a flowchart illustrating a method for generating enhanced search results according to an embodiment of this application;

[0086] Figure 2 This is a schematic flowchart of another method for generating enhanced search results disclosed in an embodiment of this application;

[0087] Figure 3 This is a schematic diagram of the structure of a retrieval enhancement generation device disclosed in an embodiment of this application. Detailed Implementation

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

[0089] Example 1: This application discloses a method for retrieval enhancement generation.

[0090] For details, please refer to Figure 1 The retrieval enhancement generation method disclosed in this embodiment includes the following steps:

[0091] Step 101: Each node performs privacy processing on the difficult negative samples in the local retrieval process to obtain the Evidence Token Packet (ETP).

[0092] In the method of this embodiment, each node automatically captures segments that are misclassified as relevant by the local retrieval machine but are actually negative during the local inference process; these are known as hard negative samples. The hard negative samples and their generation preferences are then encapsulated together into an Evidence Token Pack (ETP). This ETP incorporates Laplace noise and Gaussian noise, and specifically may include the fields in the following table:

[0093] Table 1. Explanation of ETP Data Fields

[0094]

[0095] As a feasible approach, Laplace (0, σ) noise is added to each dimension of the vector, with the noise scale σ being Δ⁄ε. Here, Δ is the length of the vector. 1 Norm sensitivity, representing the maximum L of vectors in adjacent datasets. 1 Norm distance. By controlling σ with this sensitivity, the amount of noise can be sufficient without being excessive, which helps to maintain data availability and model performance while protecting privacy. Therefore, the output after adding noise satisfies (ε, 0) - DP (differential privacy) to ensure that the presence or absence of any single text has no more than ε as an effect on the distribution of the uploaded vector.

[0096] Simultaneously, a linear mapping is performed on the original generated preference logits, and they are rounded to 8-bit logarithmic values ​​to reduce their precision and size. A Gaussian (0, τ) quantization factor is added to each slot in the quantization space. 2 Noise, the τ 2L, derived from the same privacy budget (ε, δ) and logits 2 The sensitivity of the norm is derived. The derivation process is as follows:

[0097] The common sufficient condition for Gaussian noise mechanism to satisfy (ε, δ)-differential privacy is as follows:

[0098] (1)

[0099] In the formula, Δ2 is L 2 Norm sensitivity (i.e., the maximum L of vectors in neighboring datasets) 2 Norm distance), σ is the standard deviation of Gaussian noise.

[0100] Let τ 2 =σ 2 Let the noise variance be the formula, then we can obtain the following formula:

[0101] (2)

[0102] In the formula, τ 2 By adding noise to logits, the generated preference vector logits_q after uploading can be made to satisfy the given (ε, δ)-differential privacy budget.

[0103] In the method of this embodiment, the output result with added Gaussian noise satisfies (ε, δ)-DP (approximate differential privacy), which can prevent the re-identification of high-confidence word tokens.

[0104] In the method of this embodiment, a noisy random number generator can also be used to record a seed using a noise seed dp_seed, so as to perform privacy accounting on single or multiple rounds of uploaded data in subsequent periods.

[0105] In this embodiment, the ETP provides formal differential privacy guarantees in both the vector and logits spaces using a Laplacian-Gaussian double noise mechanism. This ensures that the server only receives the noisy vector and cannot infer the original text or precise probabilities. Simultaneously, it carries the necessary information for driving retrieval and collaborative training, laying a lightweight and secure data foundation for subsequent steps such as shuffling, replaying, and local training. Furthermore, the sizes of the noisy query vector q_embed, the hard negative sample vector neg_embed, and the quantized noisy logits_q are all compressed, keeping the size of each ETP at the KB level, supporting minute-level FL rounds without burdening the network.

[0106] Step 102: Each node obtains the query activity during the local retrieval process.

[0107] In this embodiment, Low-Rank Adaptation (LoRA) in FL scenarios sets up a smaller-granularity local micro-adaptation layer μ-Adapter on each node, facilitating independent aggregation or freezing. Since the update frequency of the μ-Adapter varies among nodes, high-traffic nodes require minute-level synchronization, while newer or long-tail service nodes should minimize bandwidth usage. Therefore, this embodiment first calculates the query activity of each node in real time to measure the actual call intensity of the μ-Adapter within the most recent time window, thereby distinguishing nodes based on their query activity.

[0108] As a feasible approach, during the local retrieval process, each node can collect basic counts in real time within its local memory. These basic counts can specifically include the number of query calls C_q within a preset time window, the number of terms returned by the query C_r (i.e., the total number of tokens returned by the retrieval, which can be approximated as the total number of characters in the top-k segments of the long-tail query), and the number of terms generated C_g (i.e., the total number of output tokens generated). The basic counts are then normalized using a sliding window method to obtain a normalized count vector.

[0109] As an feasible approach, the normalization process can be specifically implemented by setting a sliding time window of fixed length Δt (e.g., 10 min), and at the end of the window, dividing the current base count C = (C_q, C_r, C_g) by their respective reference upper limits C = (Ĉ_q, Ĉ_r, Ĉ_g) to obtain the normalized count vector c. norm This reference upper limit is updated daily by the server to ensure that the activity levels of nodes with different business volumes are comparable.

[0110] In the method of this embodiment, to avoid drastic fluctuations in query activity due to instantaneous traffic peaks, c can be... norm An exponential moving average is applied to smooth the historical query activity against the current instantaneous load. Specifically, it can be represented by the following formula:

[0111] (3)

[0112] In the formula, A i λ represents the query activity level, t represents time, and λ is the smoothing coefficient of the exponential moving average, which is used to control the weight ratio of historical query activity and current instantaneous load in the query activity calculation.

[0113] The value of λ can be between 0.8 and 0.9 to reflect load changes in a timely manner and maintain noise stability at low-flow nodes. A i The value ranges from 0 to 1, where 0 indicates that the value is basically idle and 1 indicates that the reference upper limit has been reached.

[0114] In this embodiment, query activity is calculated locally on the node, and only the query activity after λ-smoothing is uploaded. This avoids exposing the query content and only consumes byte-level bandwidth. Simultaneously, the update cycle is synchronized with the sliding window, supporting minute-level upload decisions.

[0115] Step 103: When the query activity is greater than or equal to the preset upper limit threshold, the node uploads the weight adjustment values ​​of the ETP and the local micro-adaptation layer to the server, and receives the echo ETP and the distributed weight adjustment values ​​from the server.

[0116] In this embodiment, the query activity is compared with preset upper and lower thresholds. When the query activity is greater than or equal to the upper threshold η_push, the node is considered a high-load node. In this case, the latest gradient needs to be incorporated into the FL (Flexible Adaptation Layer), meaning the ETP (Electronic Tolerance Protocol) and the weight adjustment values ​​of the local micro-adaptation layer are uploaded to the server, and the node receives echo ETPs and distributed weight adjustment values ​​from the server. When the query activity is between η_push and the lower threshold η_pull, the node needs to stop uploading and only receive echo ETPs and distributed weight adjustment values. When the query activity is less than or equal to η_pull, the node needs to be frozen, meaning both uploading and receiving activities cease.

[0117] Specifically, high-load nodes first perform differential encoding and 8-bit quantization on the weight adjustment value ΔW for this round of LoRA, and then package it together with the newly generated ETP. If the safe cooling interval T_cool (e.g., 30 seconds) has not yet been reached since the last upload to the server, to prevent concurrency spikes, the node will randomly jitter for a period of time (e.g., 0-5 seconds) before sending the packaged data to the server. After the server verifies the signature, it performs a weighted average on ΔW and shuffles the ETP. In this way, hot services can inject knowledge into the global model within minutes.

[0118] Accordingly, when query activity is between the two thresholds, the node temporarily refrains from sending ΔW and ETP for the current round. However, it continues to receive the global weight adjustment value ΔW_global from the server and merges ΔW_global with the local retriever to ensure the freshness of the local model without consuming uplink bandwidth. Simultaneously, the local gradients within the node accumulate in the cache. When subsequent query activity increases and exceeds η_push, these accumulated gradients are merged with the latest weight adjustment value and uploaded to the server all at once, preventing information loss.

[0119] Accordingly, the frozen node stops receiving ΔW_global from the server to save bandwidth and local merging power. Meanwhile, the gradient for this round is only stored locally on the node, and its weights are marked as frozen. When the node's query activity returns above η_pull within a subsequent preset number (e.g., two) sliding windows, the node is automatically unfrozen and performs the above steps according to the comparison with η_push and η_pull.

[0120] In this embodiment, a dual-gating mechanism using η_push and η_pull components divides query activity into three levels. This allows uplink data from highly active nodes to be fed into FL at minute-level speeds, while cooling intervals and random jitter smooth out concurrent bandwidth. Medium-active nodes maintain passive synchronization without generating uplink traffic, and low-active nodes freeze both uplink and downlink traffic, conserving local merging computational power. Furthermore, an accumulated recovery mechanism ensures that gradients are not lost during node quiet periods.

[0121] In this embodiment, the weight adjustment value is obtained by the server integrating all received weight adjustment values. Specifically, the server performs FedAvg weighted averaging on each weight adjustment value according to the query volume of each node to obtain a global update weight adjustment value ΔWavg. This global update weight adjustment value is used for the global update of LoRA. Simultaneously, the server reads logits_q and difficult negative samples from the received ETP, and injects the difficult negative samples into the LoRA backbone through teacher-student Kullback-Leibler knowledge distillation to obtain a distilled weight adjustment value ΔWdistill. Subsequently, the server superimposes the global update weight adjustment value and the distilled weight adjustment value to obtain the distributed weight adjustment value.

[0122] As a feasible approach, the server can also backtrack on the bandwidth utilization and the rate of decrease in global verification loss within a preset time period, and adjust the upper and lower thresholds based on this bandwidth utilization and decrease rate. For example, if the bandwidth remains below the preset value for an extended period and the convergence speed slows down, η_push can be automatically reduced and η_pull increased to encourage more nodes to upload. Conversely, if the bandwidth is close to saturation and the loss decreases steadily, η_push can be increased and η_pull decreased to suppress communication from secondary nodes. The updates to η_push and η_pull can be issued by the server on an hourly basis, without affecting ongoing window determination.

[0123] In this embodiment, the method achieves a dynamic self-balance between privacy, bandwidth, and convergence speed through periodic adaptive adjustment of the threshold on the server side. This enables rapid sharing of hot topics, bandwidth compression for long-tail services, and keeps overall communication and computing costs under control without sacrificing freshness.

[0124] In this embodiment, the replay ETP is obtained by the server shuffling all received ETPs. As one feasible approach, the server continuously receives ETPs from each node after each round of federation begins. At this time, the server only checks the field integrity and timestamp of each ETP, and delivers each ETP to the corresponding temporary sub-queue based on the anonymous hash value of the source node. The temporary sub-queue is created by the server after setting up a temporary storage area and dividing it. This operation avoids sending ETPs to their source nodes during replay. It also facilitates periodic scanning of each temporary sub-queue, discarding expired ETPs that have exceeded their survival window, thus ensuring that the training data remains up-to-date.

[0125] In the method of this embodiment, when the accumulated data in the temporary storage area reaches a preset data volume, or when the temporary storage area reaches a preset shuffling cycle, the server merges the ETPs in the temporary storage area into a unified buffer pool and performs random shuffling (e.g., performing a one-time Fisher-Yates shuffling algorithm). Through this random shuffling, the order of the ETPs can be disrupted, maximizing the weakening of the statistical correlation between the ETPs and the source node, so as to maintain uniformity and anonymity in the subsequent replay steps.

[0126] In this embodiment, after shuffling, a replay ETP is obtained. The server randomly selects a target node for each replay ETP and forces that the target node to be different from the source node of the replay ETP. Each replay ETP is then replayed to its corresponding target node. As an feasible solution, if the selected target node already holds more difficult negative samples than the upper limit, the server can re-select a new target node for this replay ETP without increasing latency, to prevent training load imbalance. Specifically, the server can set a counter for each node to record the number of difficult negative samples in the node. When the server replays a replay ETP to a node, the counter value of that node can be increased by 1. Correspondingly, when the node completes training using a replay ETP or reaches a preset training timeout, the counter value of that node can be decreased by 1. In this way, the server can determine whether the number of difficult negative samples to be processed in the target node exceeds the preset number based on the counter value.

[0127] In the method of this embodiment, the replay ETP issued by the server only carries q_embed, neg_embed and noisy logits, while stripping redundant metadata such as source node identifier and noise seed, so as to compress bandwidth.

[0128] In this embodiment, since all data uploaded to the server undergoes differential privacy perturbation locally on the node, the server consistently faces a vector and quantized probability distribution masked by noise throughout the entire process. It neither accesses the original text nor can it reconstruct the plaintext corpus. Simultaneously, shuffling and replay further sever the visible link between the ETP and the source node. This continuously provides each node with high-value, difficult negative samples from different domains, thereby significantly improving the cross-domain discrimination capability of the local retrieval device while maintaining privacy and communication efficiency.

[0129] Step 104: The nodes perform local training based on the replay ETP and the distributed weight adjustment value, and update the local retrieval of each node.

[0130] In this embodiment, after receiving the replay ETP, each node incorporates q_embed and neg_embed into its local training process for comparative learning to improve the discriminative power of its local retrieval system. The logits_q in the replay ETP is used as an optional field for server-side aggregation distillation and does not participate in the node's local training. As one feasible approach, the node treats q_embed as an external query anchor point. Within its own vector index, it retrieves the closest segment vector labeled as a positive example based on cosine similarity, denoted as pos_embed(local). Subsequently, q_embed, pos_embed(local), and neg_embed are combined into a triplet as training data. The logits_q is only sent back to the server along with the uploaded ETP.

[0131] In this embodiment, after the node sends the triples to the local retrieval encoder (local retrieval unit), it first performs L2 normalization on the output vector to unify its magnitude to 1. Then, it sets the temperature hyperparameter τ (which can be 0.05~0.1) to control the discrimination intensity, and calculates the retrieval contrast loss using temperature-based noise contrastive estimation (InfoNCE). The formula is as follows:

[0132] (4)

[0133] In the formula, To retrieve the contrast loss, q is q_embed, p + For pos_embed, p - For neg_embed.

[0134] In this embodiment, the retrieval contrast loss can bring the angle between q_embed and pos_embed closer and widen the angle with neg_embed in the gradient direction, thereby improving the cross-domain discriminative power of the local retrieval unit. Furthermore, this loss calculation is based only on triples processed with differential privacy, without revealing plaintext. Nodes do not need to parse logits, and privacy boundaries remain clear.

[0135] In the method of this embodiment, after the local searcher of each node is trained, in order to enable the server to securely locate the correct node for the query without disclosing the content of private domain documents, and to allow the client to verify that the server has not exceeded its authority in one go, the method of this embodiment adds a verifiable search routing mechanism.

[0136] Specifically, each node can first split and map its local index to obtain a Bloom bitmap. One feasible approach is to first split each local index into m fragments (m is typically 128), and then map them to Bloom vectors of length L bits using k independent hash functions (k can be 6, L can be 4096). Performing a bitwise OR operation on the m vectors yields the fragment-level Bloom bitmap B. i The Bloom fingerprint only contains bit information and cannot be used to deduce the original text.

[0137] After obtaining the Bloom bitmap of each segment, the nodes are merged bitwise using an OR operation to obtain the routing tag, as shown in the formula below:

[0138] (5)

[0139] In the formula, RouteTag is the route tag.

[0140] Subsequently, the node adds the same level of privacy processing as ETP to each bit of the route tag. The RouteTag retains only the minimum information about which fragments may have appeared in the database. During subsequent queries, the server can use the RouteTag to perform simple bit matching to quickly filter out candidate nodes, while the RouteTag itself neither exposes the original text nor participates in integrity verification.

[0141] In this embodiment, the node performs chained Poseidon hashing on the Bloom bitmap to obtain the root hash. Specifically, the Bloom bitmap is divided into 256-bit blocks, compressing the variable-length bitmap into a fixed-length fingerprint. A Poseidon hash operation is then performed on each block to generate a fixed 256-bit digest h. i，0 h i，1...Then, the block digests of the same fragment are concatenated sequentially to obtain the public fingerprint of the fragment on the chain, Concat_idx (idx is the sequence number of the fragment in the chain), which the server can reference in subsequent retrieval requests. Then, treating the order of the fragments in the index as the chain order, the concatenated block digests are hashed with the cumulative value of the previous node using a Poseidon hash operation, resulting in the following formula:

[0142] (6)

[0143] In the formula, H i H is the summary of the i-th segment and the summaries of all preceding segments. i-1 The chain hash is obtained by performing Poseidon calculations together.

[0144] The final root hash H root That is, the chain hash H i The last one in the list represents the consistency of the entire database index; any insertion, deletion, or reordering operation on the index will change the root hash.

[0145] In this embodiment, the root hash alone verifies the structural integrity of the data, but this cannot prevent impersonation, data swapping, or rolling back of old hashes. Therefore, the node further performs BLS (Boneh-Lynn-Shacham) signature processing on the root hash using its private key, obtaining signature σ. The server can verify the signature using its public key to confirm that this hash was indeed generated by this node and has not been tampered with, thereby completely blocking the risk of forgery and tampering. The specific operation for generating the signature can be as follows:

[0146] (7)

[0147] In the formula, sk is the private key.

[0148] In this embodiment, the node compresses the entire private domain index into a unique and irreversible root hash and locks its integrity with a digital signature. Only the routing tag, root hash, and signature are uploaded to the server; the server cannot view any fragments or Bloom bitmaps, nor can it deduce any document content. When a node inserts, deletes, or reorders fragments, the root hash and signature immediately and automatically become invalid.

[0149] In the method of this embodiment, the server can determine the initial screening node based on the route tag, obtain the zero-knowledge proof of the initial screening node according to the Bloom-Hash signature chain protocol, and access the authorized local index after the initial screening node completes the verification based on the signature and the zero-knowledge proof. Specifically, when the server uses RouteTag to coarsely locate the query to the initial screening node and wants to retrieve a certain segment in the chain, the initial screening node needs to submit a one-time zero-knowledge proof to the final caller (client or upstream business) to prove that the server retrieves the set of segments covered by its own route tag, root hash, and signature, and has not exceeded its authority by retrieving more or less than authorized segments.

[0150] As a feasible approach, the server first performs a Top-k search in the local vector index of the initial screening node to find the segment most semantically similar to the query. Based on the pre-defined numbering rules (such as file path and offset) of the initial screening node, the position of this segment in the chained cumulative sequence is the sequence number (idx) of the target segment the server wants to obtain. Since the initial screening node has already concatenated all Poseidon block hashes of each segment sequentially to form Concat_idx when uploading the index, and included it with the RouteTag and H... root These are stored together on the server. Therefore, the server can obtain Concat_idx by looking up the table. To prevent the reuse of old proofs, the server can randomly generate a one-time random number nonce for this retrieval (e.g., a 128-bit binary number, example: 0x91F0 A3C7 …). Subsequently, the server sends the route tag, root hash, and signature along with the instruction "Please return to the fragment text" to the initial screening node. At this point, the only public parameters received by the initial screening node are the route tag, root hash, and signature, as well as the root hash and signature that the initial screening node itself uploaded.

[0151] Subsequently, the initial screening node performs the following operations locally: First, it indexes the local table using the sequence number idx to locate the target fragment and obtain its corresponding Bloom bitmap B. idx And read its value H at position idx–1 in the chained accumulation. idx-1 The nonce issued by the server is then recorded as a one-time password for this proof. This same nonce will be used in all subsequent steps with the zero-knowledge circuit; otherwise, client verification will fail. The final private witness, the input visible to the zero-knowledge proof circuit but invisible to the outside world, is (B... idx H idx-1 , nonce). They will be compared with the public parameters (H root The Poseidon chain circuit (i, idx, Concat_idx, nonce) is fed together with the next step to generate the zero-knowledge proof π.

[0152] In this embodiment, the initial screening node continues to perform the following operations locally: It divides the private witness and public parameters into two groups, making the public parameters visible to anyone, while storing the private witness only locally on the node. These two groups of data are then input into the installed Poseidon chain zero-knowledge circuit to activate the local prover. The prover is constrained as follows:

[0153] a) Use B first idx Recalculate the block hash and concatenate it; the result must be the same as Concat_idx.

[0154] b) Then connect Concat_idx and H idx-1 Perform a Poseidon accumulation and continue along the chain to the end; the resulting value must be H. root ;

[0155] c) The nonce in the private witness is exactly the same as the nonce in the public parameters.

[0156] When all three constraints are satisfied, the prover will issue a zero-knowledge proof; otherwise, it will report an error and refuse to output the proof.

[0157] In the method of this embodiment, after the initial screening nodes complete the circuit calculations, a binary file is obtained, namely the zero-knowledge proof π. It does not contain any text and does not expose B. idx or H idx-1 The fact that "all three constraints of the circuit are met" is compressed and saved using only a few elliptic curve points. At this point, the initial screening node returns the encrypted fragment text and π to the server.

[0158] In this embodiment, the server does not parse the encrypted fragment text and the content in π; instead, it acts merely as an intermediary, forwarding the message to the actual requester, the client. Upon receiving the message, the client performs two layers of verification: verifying the index's identity and integrity, and verifying the zero-knowledge proof.

[0159] Specifically, the client can store the node's public BLS key pk and the H broadcast during node registration. root And the signature σ, so the client first calls BLS.Verify(pk, H) root If the verification passes, H can be confirmed. root It originates from this node and has never been tampered with. Conversely, if signature verification fails, the client can discard the entire message.

[0160] Subsequently, the client publishes the parameters (H) rootThe data (idx, Concat_idx, nonce) along with π is fed into the validator verify(vk, public parameter, π), which outputs a truth or falsity conclusion. Here, vk is the public verification key associated with the Poseidon chain circuit, distributed along with the client software. If the conclusion is true, it means the server "only read each idx segment in the chain, did not modify the index, and the proof was valid only once." Conversely, if the conclusion is false, the client can reject the data.

[0161] In the method of this embodiment, through the above verification steps, the client can quickly give a credible conclusion without touching any private witness or official document, thereby leaving the document on the terminal side, with the server supporting retrieval and the terminal supporting verification.

[0162] The method described in this embodiment decouples the retrieval plane (local vector index + RouteTag coarse routing) from the generation plane (shared LLM backbone trained in a federated manner + LoRA μ-Adapter), and achieves knowledge injection and model updates in a privacy-constrained environment through a three-stage loop (local RAG - cross-node distillation - federated aggregation). Within the same federated RAG framework, it simultaneously achieves data remaining within its domain, rapid knowledge updates, controllable communication efficiency, and encrypted result verification.

[0163] Specifically, the method in this embodiment utilizes retrieval vectors with differential privacy perturbations, logits, and hard negative samples to encapsulate an ETP. After server shuffling, this ETP is rebroadcast to other nodes, forming cross-domain hard negative samples. Nodes simultaneously minimize temperature-normalized InfoNCE loss, enhancing the discriminative power of retrieval vectors, consistency of generated preferences, and personalization of responses, significantly improving the fit of answers to the local business context. Furthermore, each response is accompanied by verifiable proof, providing clear evidence for subsequent auditing and tracing. In addition, the μ-Adapter in this embodiment enables high-frequency, small-step updates, allowing newly added private domain knowledge to take effect quickly, achieving rapid knowledge injection. The large LoRA backbone model aggregates at a longer steady-state pace, avoiding frequent retraining and balancing update speed with overall convergence quality. Simultaneously, the dual-threshold gating mechanism for activity supports uploading incremental parameters and differentially privacy-enhanced ETPs when nodes are highly active, while inactive nodes are uploaded on demand or frozen. RouteTag and zero-knowledge proof mechanisms can streamline data volume, reduce the additional bandwidth overhead of a single retrieval, and significantly reduce overall traffic peaks. The method in this embodiment also employs a Bloom-hash signature chain and a zero-knowledge proof mechanism, ensuring that the server cannot access the original text during retrieval and must submit a one-time cryptographic proof. The client can then complete the dual verification quickly, confirming that the server has not accessed the content without authorization. This ensures both privacy and verifiability throughout the entire process.

[0164] Example 2: This application discloses another method for search enhancement generation; please refer to [link to example]. Figure 2 This embodiment describes the entire process of updating the node local search engine.

[0165] Step 201: The node performs a local search, performs privacy processing on the difficult negative samples in the local searcher, and obtains the ETP.

[0166] Step 202: During the local search process, the node obtains the query activity of the local search engine in real time.

[0167] Step 203: The node determines whether the query activity level is greater than or equal to the upper limit threshold. If yes, proceed to step 204. If no, proceed to step 205.

[0168] Step 204: The node uploads the weight adjustment values ​​of ETP and the local micro-adaptation layer to the server. Proceed to step 208.

[0169] Step 205: The node determines whether the query activity level is less than or equal to the lower threshold. If yes, proceed to step 206. If no, proceed to step 207.

[0170] Step 206: Freeze the node, stopping its upload and receive operations. Return to step 203.

[0171] Step 207: Stop the node's upload operation. Proceed to Step 208.

[0172] Step 208: The node receives the replay ETP and the weight adjustment value from the server.

[0173] In the method of this embodiment, the replay ETP is obtained by the server shuffling all received ETPs, and the weight adjustment value is obtained by the server integrating all received weight adjustment values.

[0174] Step 209: The node performs local training based on the replay ETP and the distributed weight adjustment values, and updates the local retrieval tool. Return to step 201.

[0175] Based on the retrieval enhancement generation method disclosed in the above embodiments, this embodiment correspondingly discloses a retrieval enhancement generation apparatus. Please refer to... Figure 3 The retrieval enhancement generation device includes: a processing unit 301, an acquisition unit 302, an upload unit 303, and a training unit 304;

[0176] The processing unit 301 is used to perform privacy processing on the difficult negative samples in the local retrieval process by each node to obtain the Evidence Token Packet (ETP).

[0177] The acquisition unit 302 is used for each node to acquire the query activity during the local retrieval process;

[0178] The upload unit 303 is used to, when the query activity is greater than or equal to a preset upper limit threshold, upload the ETP and the weight adjustment value of the local micro-adaptation layer to the server, and receive the replay ETP and the distributed weight adjustment value from the server; the replay ETP is obtained by the server shuffling all the received ETPs, and the distributed weight adjustment value is obtained by the server integrating all the received weight adjustment values.

[0179] The training unit 304 is used for the nodes to perform local training based on the replay ETP and the distributed weight adjustment value, and to update the local retrieval of each node.

[0180] Optionally, the processing unit 301 includes:

[0181] The sample acquisition subunit is used to acquire the difficult negative samples in the local searcher during the local search process;

[0182] A noise-adding subunit is used to add Laplace noise and Gaussian noise to the difficult negative sample and the generation preference of the difficult negative sample to obtain the ETP with added differential privacy noise.

[0183] Optionally, the acquisition unit 302 includes:

[0184] The counting subunit is used to collect basic counts in real time during the local retrieval process; the basic counts include the number of query calls, the number of terms returned by the query, and the number of terms generated within a preset time window;

[0185] The normalization subunit is used to perform sliding window normalization on the basic count to obtain a normalized count vector;

[0186] An activity calculation subunit is used to calculate the query activity based on the normalized count vector.

[0187] Optionally, the device further includes:

[0188] The upload stop unit is used to stop the node's upload behavior when the query activity is between the upper limit threshold and the preset lower limit threshold, and only receive the replay ETP and the weight adjustment value.

[0189] The freeze unit is used to stop the node's upload and receive behavior when the query activity is less than or equal to the lower threshold.

[0190] Optionally, the upload unit 303 includes:

[0191] The delivery subunit is used by the server to deliver the received ETP to a temporary subqueue corresponding to the source node of the ETP; the temporary subqueue is obtained by the server setting up a temporary storage area and dividing the temporary storage area.

[0192] The shuffling subunit is used to randomly shuffle the ETPs in the temporary storage area when the accumulated data in the temporary storage area reaches a preset data amount or the temporary storage area reaches a preset shuffling cycle, so as to obtain the replay ETP.

[0193] The extraction subunit is used to randomly select a target node for each replay ETP after the shuffling is completed; the target node is different from the source node of the replay ETP.

[0194] The replay subunit is used by the server to replay each replay ETP to the target node corresponding to the replay ETP.

[0195] Optionally, the upload unit 303 includes:

[0196] The averaging subunit is used by the server to perform a weighted average of the weight adjustment values ​​according to the query volume of each node to obtain a global update weight adjustment value; the global update weight adjustment value is used for the global update of low-rank adaptation LoRA.

[0197] A reading subunit is used by the server to read the difficult negative samples in the received ETP;

[0198] The distillation subunit is used by the server to inject the difficult negative samples into the low-rank adaptation backbone through knowledge distillation, thereby obtaining the distillation weight adjustment value.

[0199] The overlay subunit is used by the server to overlay the global update weight adjustment value and the distillation weight adjustment value to obtain the issued weight adjustment value.

[0200] Optionally, the device further includes:

[0201] A recording unit is provided for the server to set a counter for each node to record the number of difficult negative samples of the node.

[0202] An incrementing unit is provided to increment the value of a counter on the node when the server replays the replay ETP to the node.

[0203] A reduction unit is used to reduce the value of the counter of a node when the node completes training or reaches a preset timeout.

[0204] The replacement unit is used to replace the target node for the replay ETP when the server determines, based on the value of the counter, that the number of difficult negative samples in the target node exceeds a preset number.

[0205] Optionally, the device further includes:

[0206] The feedback acquisition unit is used by the server to acquire the bandwidth utilization rate and the rate of decrease of global verification loss within a preset time period;

[0207] A threshold adjustment unit is used by the server to adjust the upper limit threshold according to the bandwidth utilization rate and the rate of decrease.

[0208] Optionally, the device further includes:

[0209] A mapping unit is used by the node to split and map the local index to obtain a Bloom bitmap;

[0210] A merging unit is used by the nodes to merge the Bloom bitmap to obtain routing tags;

[0211] A hash unit is used by the node to perform chained Poseidon hashing on the Bloom bitmap to obtain the root hash.

[0212] A signature unit is used by the node to perform BLS signature processing on the root hash to obtain a signature;

[0213] The verification unit is used for the node to upload the routing tag, the root hash, and the signature to the server, so that the server can determine the initial screening node based on the routing tag, obtain the zero-knowledge proof of the initial screening node according to the Bloom-Hash Signature Chain Protocol, and access the authorized local index based on the signature and the zero-knowledge proof after the initial screening node has completed the verification.

[0214] The embodiments in this specification are described in a progressive manner. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant details can be found in the method section.

[0215] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0216] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0217] The features described in the embodiments of this specification can be substituted for or combined with each other, so that those skilled in the art can implement or use this application.

[0218] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for generating enhanced search results, characterized in that, include: Each node performs privacy processing on the difficult negative samples encountered during the local retrieval process to obtain the Evidence Token Packet (ETP). Each node obtains the query activity level during the local retrieval process; When the query activity is greater than or equal to a preset upper limit threshold, the node uploads the ETP and the weight adjustment value of the local micro-adaptation layer to the server, and receives the replay ETP and the distributed weight adjustment value from the server; the replay ETP is obtained by the server shuffling all the received ETPs, and the distributed weight adjustment value is obtained by the server integrating all the received weight adjustment values. The nodes perform local training based on the replay ETP and the distributed weight adjustment value, and update the local retrieval of each node.

2. The method according to claim 1, characterized in that, Each node performs privacy processing on the difficult negative samples encountered during the local retrieval process to obtain an Evidence Token Packet (ETP), which includes: During the local retrieval process, the difficult negative samples in the local retrieval device are obtained; Laplace noise and Gaussian noise are added to the difficult negative sample and the generation preference of the difficult negative sample to obtain the ETP with differential privacy noise.

3. The method according to claim 1, characterized in that, The nodes obtain query activity during the local retrieval process, including: During the local retrieval process, basic counts are collected in real time; these basic counts include the number of query calls, the number of terms returned by the query, and the number of terms generated within a preset time window. The basic count is normalized using a sliding window method to obtain a normalized count vector; The query activity is calculated based on the normalized counting vector.

4. The method according to claim 1, characterized in that, After obtaining the query activity during the local retrieval process at each of the aforementioned nodes, the method further includes: If the query activity level is between the upper limit threshold and the preset lower limit threshold, the node's upload behavior is stopped, and only the replay ETP and the weight adjustment value are received. If the query activity level is less than or equal to the lower threshold, the node's upload and receive behavior shall be stopped.

5. The method according to claim 1, characterized in that, The server shuffles all received ETPs to obtain the replay ETP, and then replays the replay ETP to each of the nodes, including: The server delivers the received ETP to a temporary sub-queue corresponding to the source node of the ETP; the temporary sub-queue is obtained by the server setting up a temporary storage area and dividing the temporary storage area. When the accumulated data in the temporary storage area reaches a preset data volume, or when the temporary storage area reaches a preset shuffling cycle, the server performs random shuffling on the ETPs in the temporary storage area to obtain the replay ETPs. After the shuffling is completed, the server randomly selects a target node for each replay ETP; the target node is different from the source node of the replay ETP. The server replays each of the replay ETPs to the target node corresponding to the replay ETP.

6. The method according to claim 1, characterized in that, The server integrates all received weight adjustment values ​​to obtain the issued weight adjustment value, including: The server performs a weighted average of the weight adjustment values ​​according to the query volume of each node to obtain a global update weight adjustment value; the global update weight adjustment value is used for the global update of low-rank adaptation LoRA. The server reads the difficult negative samples from the received ETP; The server injects the difficult negative samples into the low-rank adaptation backbone through knowledge distillation to obtain distillation weight adjustment values; The server adds the global update weight adjustment value and the distillation weight adjustment value together to obtain the distributed weight adjustment value.

7. The method according to claim 5, characterized in that, Before the server replays each of the replay ETPs to the target node corresponding to the replay ETP, the method further includes: The server sets a counter for each node to record the number of difficult negative samples for that node; When the server replays the replay ETP to the node, the value of the node's counter increases; When the node completes training or reaches a preset timeout, the value of the node's counter decreases. If the server determines, based on the value of the counter, that the number of difficult negative samples in the target node exceeds a preset number, the target node for the replay ETP will be replaced.

8. The method according to claim 6, characterized in that, After obtaining the weight adjustment value, the method further includes: The server obtains the bandwidth utilization rate and the rate of decrease in global verification loss within a preset time period. The server adjusts the upper limit threshold based on the bandwidth utilization and the rate of decrease.

9. The method according to claim 1, characterized in that, After updating the local retrievers of each of the nodes, the method further includes: The nodes split and map the local index to obtain a Bloom bitmap; The node merges the Bloom bitmap to obtain a routing label; The node performs chained Poseidon hashing on the Bloom bitmap to obtain the root hash; The node performs BLS signature processing on the root hash to obtain a signature; The node uploads the routing tag, the root hash, and the signature to the server, so that the server determines the initial screening node based on the routing tag, obtains the zero-knowledge proof of the initial screening node according to the Bloom-Hash Signature Chain Protocol, and accesses the authorized local index based on the signature and the zero-knowledge proof after the initial screening node has completed the verification.

10. A retrieval enhancement generation apparatus, characterized in that, include: Processing unit, acquisition unit, upload unit, and training unit; The processing unit is used by each node to perform privacy processing on the difficult negative samples in the local retrieval process to obtain the Evidence Token Packet (ETP). The acquisition unit is used by each node to acquire the query activity during the local retrieval process; The upload unit is configured to, when the query activity is greater than or equal to a preset upper limit threshold, upload the ETP and the weight adjustment value of the local micro-adaptation layer to the server, and receive the replay ETP and the distributed weight adjustment value from the server; the replay ETP is obtained by the server shuffling all the received ETPs, and the distributed weight adjustment value is obtained by the server integrating all the received weight adjustment values. The training unit is used for the nodes to perform local training based on the replay ETP and the distributed weight adjustment value, and to update the local retrieval of each node.

Images