Vector retrieval method and device for protecting data privacy

Abstract

The embodiments of this specification disclose a vector retrieval method and device for protecting data privacy. The method involves a client and a server, wherein the server stores the plaintext or ciphertext corresponding to each group of object vectors, and the client stores the centroid vector of each group of object vectors. The method includes: the client calculates the similarity between the corresponding query vector and each centroid vector based on the user's query input, obtains the target group identifier corresponding to the highest similarity, and then sends the ciphertext corresponding to the query vector and several group identifiers containing the target group identifier to the server. The server performs homomorphic operations based on its local storage and received data to obtain a first ciphertext, and its corresponding plaintext is used to measure the similarity between the query vector and each object vector in p groups. The client decrypts the inner product ciphertext sent by the server, and based on the decryption result, determines the object vectors in the target group that rank in the top k in similarity with the query vector.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of data security processing technology, and more particularly, to a vector retrieval method and apparatus for protecting data privacy, a computer-readable storage medium, and a computing device. Background Art

[0002] Vector search services have become a key component in a wide range of current applications, including Large Language Model (LLM) prompt engineering, recommender systems, search engines, and drug discovery. Vector search services efficiently retrieve relevant information by encoding multimodal, unstructured data into high-dimensional vector representations. In this workflow, user profile features and private queries are embedded into vectors and transmitted to a vector database server. The server then calculates similarity to identify the most relevant objects from the data owner's vector collection and returns the results to the user.

[0003] However, current vector retrieval service solutions are difficult to meet the higher requirements in practical applications, such as optimizing communication and computing overhead, and reducing service latency while protecting data privacy. Summary of the Invention

[0004] The embodiments of this specification describe a vector search method and device that can meet higher requirements in practical applications.

[0005] According to a first aspect, a vector retrieval method for protecting data privacy is provided, involving a client and a server, wherein the server stores the plaintext or ciphertext corresponding to each of m groups of object vectors, and the client stores the centroid vector of each group of object vectors. The method, applied to the client, includes:

[0006] According to the user's query input, the similarity between the corresponding query vector and the centroid vector is calculated to obtain the target group identifier corresponding to the highest similarity. The ciphertext corresponding to the query vector and p group identifiers are sent to the server; wherein p < m, the p group identifiers include the target group identifier. A first ciphertext is received, and its corresponding plaintext is used to measure the similarity between the query vector and each object vector in the p groups; the first ciphertext is determined by the server based on its locally stored vectors and the received vectors by performing homomorphic operations. Based on the decryption result of the first ciphertext, the similarity between the query vector and each object vector in the target group is determined to obtain the query result corresponding to the query input.

[0007] In one embodiment, the m groups of object vectors and centroid vectors are determined by the data provider based on the following steps: clustering is performed on the object vector set to obtain m clusters and the centroid vector of each cluster, where the number of vectors in each cluster is less than or equal to a preset value n. The m groups of object vectors are initialized using the m clusters. For each group, a nearest neighbor search algorithm is used to determine, from the object vector set, a batch of vectors whose similarity to the centroid vector of the group is within a preset range. The group is then populated based on the batch of vectors until the number of vectors in the group reaches n and there are no duplicate vectors.

[0008] Furthermore, in a specific embodiment, clustering processing is performed based on the object vector set to obtain m clusters, including: performing a first clustering processing on the object vector set to obtain multiple first clusters; for each first cluster, when it is determined that the number of vectors therein is greater than n, performing a second clustering processing on it, and classifying the multiple second clusters obtained into the m clusters; otherwise, directly classifying the first cluster into the m clusters.

[0009] In one embodiment, determining the p group identifiers includes: based on the target partition identifier, randomly selecting p-1 other partition identifiers from the m group identifiers and including the other partition identifiers in the p group identifiers.

[0010] In one embodiment, the server is implemented as a third-party server, which stores the ciphertext corresponding to each group of object vectors, and the ciphertext is provided by the data provider.

[0011] Furthermore, in a specific embodiment, the method also includes: receiving the ciphertext of the centroid vector from the third-party server, which is obtained by the data party encrypting the centroid vector using a symmetric key; decrypting the ciphertext of the centroid vector using the symmetric key, and storing the decrypted plaintext.

[0012] In one embodiment, the server is implemented as a private server of the data party, in which the plaintexts corresponding to the m groups of object vectors are stored.

[0013] Furthermore, in a specific embodiment, the method further includes: receiving m centroid vectors corresponding to the m groups of object vectors from the private server and storing them.

[0014] In one embodiment, the first ciphertext includes an inner product ciphertext, and its corresponding plaintext includes the inner product between the query vector and each object vector in the p groups.

[0015] In one embodiment, determining the similarity between the query vector and each object vector in the target group based on the decryption result of the first ciphertext includes: for each object vector in the target group, extracting the inner product between the query vector and the decryption result as the corresponding similarity.

[0016] In one embodiment, the client further stores the norm of each object vector in the m groups; wherein, based on the decryption result of the first ciphertext, determining the similarity between the query vector and each object vector in the target group includes: for each object vector in the target group, extracting the inner product between it and the query vector from the decryption result, and determining the similarity between the object vector and the query vector based on the inner product, the norm of the object vector and the norm of the query vector.

[0017] In one embodiment, after determining the similarity between the query vector and each object vector in the target group, the method further includes: determining k object IDs corresponding to the top k similarities as the query result.

[0018] According to the second aspect, a vector retrieval method for protecting data privacy is provided, involving a client and a server, wherein the server stores the plaintext or ciphertext corresponding to each group of object vectors in m groups of object vectors, and the client stores the centroid vector of each group of object vectors. The method is applied to the server, comprising: receiving the ciphertext corresponding to the query vector and p group identifiers from the client; wherein p < m, the p group identifiers include a target group identifier; the centroid vector of the target group has a higher similarity to the query vector than other groups, and the query vector is determined based on the user's query input. A homomorphic operation is performed based on the locally stored vector and the received vector to obtain a first ciphertext, the corresponding plaintext of which is used to measure the similarity between the query vector and each object vector in the p groups. The first ciphertext is sent to the client, so that the client determines the similarity between the query vector and each object vector in the target group based on the decryption result of the first ciphertext, so as to obtain the query result corresponding to the query input.

[0019] In one embodiment, the server is implemented as a third-party server; the method further includes: receiving ciphertext corresponding to each group of object vectors from a data source.

[0020] Furthermore, in a specific embodiment, the server is implemented as a private server of the data party, in which the plaintext corresponding to each group of object vectors is stored.

[0021] In one embodiment, the first ciphertext includes an inner product ciphertext, and its corresponding plaintext includes the inner product between the query vector and each object vector in the p groups.

[0022] Furthermore, in a specific embodiment, the server stores the plaintext or ciphertext corresponding to each group of object vectors; each group of object vectors includes n object vectors, and the corresponding plaintext is a first rearranged vector of the group of object vectors, the first rearranged vector including d groups of elements, where the jth element in any i-th group is the i-th element of the j-th object vector in the group of object vectors; or the ciphertext corresponding to each group of object vectors is obtained by encrypting the first rearranged vector using the user's public key. The ciphertext corresponding to the query vector is obtained by encrypting a second rearranged vector using the public key, the second rearranged vector including d groups of elements, where the elements in any i-th group are the i-th elements of the query vector.

[0023] Based on this, the homomorphic operation includes: for any group of the p groups, performing a homomorphic multiplication operation on the plaintext or ciphertext of the first rearranged vector of the group and the ciphertext of the second rearranged vector to obtain the current vector ciphertext; performing log2d iterations on the current vector ciphertext, wherein any sth iteration includes: performing a step of n*d / 2 on the current vector ciphertext s cyclic rotation; updating the current vector ciphertext to the result of a homomorphic addition operation between the current vector ciphertext and the result of the rotation of the vector; determining the inner product ciphertext based on the iterated current vector ciphertext, wherein the first n elements of the plaintext corresponding to the current vector ciphertext are the inner products between the query vector and each object vector in the corresponding group.

[0024] Furthermore, in one example, determining the inner product ciphertext based on the iterated current vector ciphertext includes: performing a homomorphic multiplication operation on the current vector ciphertext using a mask vector to obtain a masked result ciphertext; the first n bits of the mask vector are predetermined non-zero values, and the remaining bits are zero. Merging the p masked result ciphertexts corresponding to the p groups includes: performing a cyclic rotation with a step size of (i-1)*n bits on the i-th masked result ciphertext; and performing a homomorphic addition operation on the p rotation results corresponding to the p masked result ciphertexts to obtain the inner product ciphertext.

[0025] According to a third aspect, a vector retrieval device for protecting data privacy is provided. The device is integrated into a client, wherein a corresponding server stores the plaintext or ciphertext corresponding to each of m groups of object vectors, and the client stores the centroid vector of each group of object vectors. The device comprises:

[0026] The target group determination unit is configured to calculate the similarity between the query vector corresponding to the user's query input and the centroid vector, and obtain the target group identifier corresponding to the highest similarity. The query data sending unit is configured to send the ciphertext corresponding to the query vector and p group identifiers to the server; wherein p < m, the p group identifiers include the target group identifier. The inner product ciphertext receiving unit is configured to receive a first ciphertext, the corresponding plaintext of which is used to measure the similarity between the query vector and each object vector in the p groups; the first ciphertext is determined by the server based on its locally stored vectors and the received vectors through homomorphic operations. The query result determination unit is configured to determine the similarity between the query vector and each object vector in the target group based on the decryption result of the first ciphertext, so as to obtain the query result corresponding to the query input.

[0027] According to a fourth aspect, a vector retrieval device for protecting data privacy is provided, which is integrated into a server, wherein the server stores the plaintext or ciphertext corresponding to each of m groups of object vectors, and a client corresponding to the server stores the centroid vector of each group of object vectors. The device includes:

[0028] The query data receiving unit is configured to receive the ciphertext corresponding to the query vector and p group identifiers from the client; wherein p < m, the p group identifiers include the target group identifier; the similarity between the centroid vector of the target group and the query vector is higher than that of other groups, and the query vector is determined based on the user's query input. The first ciphertext determination unit is configured to perform homomorphic operations based on the locally stored vector and the received vector to obtain a first ciphertext, the corresponding plaintext of which is used to measure the similarity between the query vector and each object vector in the p groups. The first ciphertext sending unit is configured to send the first ciphertext to the client, so that the client determines the similarity between the query vector and each object vector in the target group based on the decryption result of the first ciphertext, so as to obtain the query result corresponding to the query input.

[0029] According to a fifth aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed in a computer, the computer is caused to execute the method provided in the first aspect or the second aspect.

[0030] According to a sixth aspect, a computing device is provided, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method provided in the first aspect or the second aspect is implemented.

[0031] In summary, the above-mentioned method and device disclosed in the embodiments of this specification are adopted to introduce FHE to realize data privacy protection for users and data parties, and it is proposed to move the selection of branches to the user side, so that the range of vector similarity search can be determined before reaching the server side. Through this design, the user side and the server side jointly build a complete vector index structure, which effectively makes up for the shortcomings of FHE in complex logical judgment. Furthermore, it is proposed to simplify the distance or similarity calculation in FHE to the inner product calculation, and optimize the inner product calculation mode to effectively reduce the computational complexity. Furthermore, it is proposed to compress and merge the result ciphertext corresponding to each partition to obtain the inner product ciphertext, thereby improving the space utilization of the ciphertext slot and effectively reducing the communication overhead. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0033] Figure 1 Schematic diagram of the interactive architecture of the vector search service in plain text mode.

[0034] Figure 2 Schematic data is the interactive architecture of the vector search service in the encrypted form mode;

[0035] Figure 3 This illustrates the trusted wall design implemented by the encryption algorithm in the improved solution disclosed in the embodiments of this specification;

[0036] Figure 4 This illustrates the basic model for calculating the inner product between vector ciphertexts based on FHE disclosed in the embodiments of this specification;

[0037] Figure 5 This illustrates the client-server collaborative structure disclosed in the embodiments of this specification;

[0038] Figure 6 This section illustrates the service model architecture of the vector security retrieval service disclosed in the embodiments of this specification;

[0039] Figure 7 This illustrates the optimization mode for calculating the inner product between vector ciphertexts based on FHE disclosed in the embodiments of this specification;

[0040] Figure 8 The embodiment disclosed in this specification Figure 7 The process of merging and compressing the result ciphertext in ;

[0041] Figure 9This is a functional structural diagram of a vector search device integrated into a client disclosed in an embodiment of this specification;

[0042] Figure 10 This is a functional structure diagram of a vector search device integrated in a server disclosed in an embodiment of this specification. DETAILED DESCRIPTION

[0043] The solution provided in this specification is described below in conjunction with the accompanying drawings.

[0044] As mentioned previously, current vector retrieval (or search) service solutions struggle to meet the higher demands of real-world applications. Specifically, current service offerings pose serious security and privacy risks to users and data owners, particularly when these systems and products are deployed as managed cloud services.

[0045] See also Figure 1 Existing vector search system architectures present three major data leakage risks: First, user private queries are submitted in plaintext to public cloud servers; second, query data is transmitted to the data owner's private server. Both scenarios expose sensitive user information to the service provider. Third, when outsourcing databases, the data owner's vector collection (which often contains sensitive or proprietary information) can be leaked to the public cloud service provider. This disclosure poses a potential threat to the data owner's intellectual property and commercial interests.

[0046] However, there is currently no practical solution that can protect the privacy information of users and data owners at the same time with acceptable overhead and practical performance to build such Figure 2 Security vector database for untrusted scenarios shown.

[0047] To build Figure 2 The vector security search architecture shown in this paper proposes the following two improvement directions:

[0048] 1) Vector retrieval based on secure multiparty computation (MPC). MPC is a method for building secure protocols with low computational requirements, but it incurs high communication costs due to the large number of interactions using oblivious transfers and garbled circuits.

[0049] 2) Vector retrieval based on fully homomorphic encryption (FHE). FHE supports direct computation on encrypted data without redundant interaction. While this significantly reduces communication overhead, it also imposes a significant computational burden.

[0050] Furthermore, the embodiments of this specification propose an improved FHE-based vector retrieval scheme (or simply the improved scheme), which can provide privacy protection for users and data parties, while at the same time effectively reducing communication and computing overhead.

[0051] Next, we will introduce practical application scenarios and define a threat model. We will then discuss the cost and practical performance challenges faced when applying FHE to vector retrieval. We will then explain the design considerations and overall architecture of the improvement solution, and finally provide a detailed implementation process for the improvement solution.

[0052] 1. Actual Application Scenarios and Threat Models

[0053] 1. Actual application scenarios

[0054] The improvement plan aims to protect the privacy and security of users and data holders in the vector search service. Its architecture includes the following three core roles.

[0055] 1) User (or client): The user submits a query vector to the system to retrieve similar object vectors. Because leaking the query vector could lead to advertising harassment or financial losses, the user's query vector must remain confidential and cannot be accessed by other parties.

[0056] 2) Data Providers: Companies such as pharmaceutical companies, financial institutions, and e-commerce platforms act as data providers and provide datasets. These datasets can be hosted on the data provider's own servers or external servers. When hosting data on external servers, the confidentiality of sensitive data must be ensured to prevent unauthorized access. It should be noted that the term "external server" can also be referred to as a public server or a third-party server. Furthermore, the term "third party" in this article refers to parties other than users and data providers.

[0057] 3) Server: Responsible for vector retrieval processing and data storage. The server can be a server managed by a third-party service provider (such as a cloud server). In this case, the data provider may face the risk of data leakage due to the third-party hosting of their data. Alternatively, the server can be a private server owned by the data provider, in which case this risk is eliminated. The following description focuses on the former scenario, which is more common in practical applications and poses a data leakage risk.

[0058] 2. Threat Model

[0059] The following two potential threats are considered in vector security retrieval.

[0060] 1) User Privacy Threats: User privacy faces dual threats from data providers and public servers. When users send query vectors to public servers for processing, both the public servers and data providers can potentially use this data to infer sensitive user information. This can expose users' search history and related preferences.

[0061] 2) Data Confidentiality Threats: Data sets primarily face threats from public servers and external attackers. When hosted on public servers, these datasets are vulnerable to unauthorized access by third-party service providers or other malicious attackers, posing the risk of leaking proprietary or sensitive data. For example, a dataset includes object vectors, or encoding vectors, corresponding to multiple business objects.

[0062] The improvement scheme aims to adopt effective encryption measures to deal with the above threats and protect the interests of users and data holders, while maintaining efficient and secure vector similarity search capabilities.

[0063] 2. Basic Solutions and Challenges

[0064] 1. Solution design

[0065] like Figure 3 As shown in the figure, the design goal is to establish two trustworthy barriers, or two trust walls, for users and data parties.

[0066] Table 1 below briefly shows the process of Algorithm 1, ie, the secure approximate nearest neighbor search algorithm (ANNS).

[0067] Table 1

[0068]

[0069] In order to protect the privacy of user queries, when the user needs to When it goes to the server, it will first use its public key pk to Encrypted to ciphertext form . Complete homomorphic FHE operations on the cloud server After that, the result of the operation in ciphertext form It is returned to the user and decrypted into plain text using the private key sk held only by the user. Thus, the user's query information is protected.

[0070] It should be understood that evk represents the evaluation key, rk represents the relinearization key, and gk represents the Galois key. These keys are used for FHE calculations. For a detailed introduction to these keys, please refer to the introduction to FHE algorithms such as the CKKS (Cheon-Kim-Kim-Song) algorithm or the BFV (Brakerski-Fan-Vaikuntanathan) algorithm. They are not elaborated here.

[0071] To protect the privacy of data providers, data providers encrypt their collected datasets using the user's public key pk before deploying them to untrusted public servers. It should be noted that if a service is provided to h users, h encryption steps are required.

[0072] Based on the above design, two trust walls are established to ensure the data security of users and data providers. In addition, the cloud server holds the keys: evk, rk, and gk, which can perform FHE calculations to obtain the distance ciphertext or similarity ciphertext between vector ciphertexts without leaking any information.

[0073] 2. Challenges

[0074] Although FHE provides strong security guarantees and can perform computations directly on ciphertext, it introduces additional overhead in several aspects of the process in Algorithm 1, including the computational overhead in line 4, the communication overhead in line 5, and the index structures involved in lines 3 and 7. These challenges will be discussed below.

[0075] 1) Computational overhead

[0076] Introducing FHE into ANNS will result in limited programmability and incur huge computational overhead.

[0077] The current FHE library is not designed for specific applications and can only be used to implement FHE primitives, including homomorphic addition, homomorphic multiplication, and rotation operations. These operations are Single Instruction Multiple Data (SIMD) instructions. Furthermore, individual encrypted elements in the ciphertext cannot be indexed; any function applied to a vector ciphertext simultaneously applies to all of its elements.

[0078] Inner Product is not only a common type of distance calculation, but also a major pre-step for other complex distances (such as L2 norm and cosine distance). When providing vector retrieval services under the FHE architecture, each service involves converting the inner product calculation into a series of FHE operation primitives on large vectors. Figure 4The basic pattern of calculating the inner product between vector ciphertexts is shown in Figure 1 to intuitively illustrate the overhead incurred by FHE in calculating the inner product.

[0079] Figure 4 Assume that the vector dimension is 4. Due to the characteristics of SIMD, the query vector ( ) is copied into multiple copies and filled into the ciphertext with the same length as the ciphertext of other vectors. Figure 4 In the figure, other vectors are n object vectors: }, , , it can be understood that the object vector has the same dimension as the query vector. When in dense form, the calculation Figure 4 The inner product between the query vector shown in the first line and the n object vectors shown in the second line includes the following steps:

[0080] Mult(), i.e. homomorphic multiplication operation: First, a homomorphic multiplication operation is performed between the query ciphertext and the object vector ciphertext. The result of the operation can be seen in Figure 4 The third line, or the first blue line, shows the plaintext corresponding to the result of the Mult() operation: .

[0081] Rotate(), that is, the circular rotation operation of the vector: Then, based on the above Mult() operation results, three circular rotation operations are performed to convert each , All elements in are moved to the same index positions as the ciphertext of the vector, which are in Figure 4 Circled in red.

[0082] Add(), i.e. homomorphic addition operation: Then, perform homomorphic addition operation on the four blue vector ciphertexts, accumulating the elements into the bottom ciphertext, thus obtaining all , ,like Figure 4 As shown in line 7 of .

[0083] The above describes the calculation process in the basic mode. This process can be extended from 4 dimensions to any d dimensions. Each execution of this calculation process requires at least one Mult(), Rotate() and Add() operations.

[0084] Experiments show that the overhead of a single FHE operation is in the microsecond to millisecond range. However, for ANNS queries, since the similarity calculation under a vector search involves thousands of FHE operations, the computational overhead under the above basic mode is relatively high.

[0085] 2) Communication overhead

[0086] In FHE algorithms such as CKKS, the size of the vector will expand several times when it is converted from plaintext to encrypted bits. Figure 4 The IP distance calculation result at the bottom is Figure 4 In line 7, the valid slots of the ciphertext are only a part of the total slots, which leads to a huge waste of space and thus a waste of communication overhead.

[0087] 3) Index structure dilemma

[0088] In ANNS, almost all vector index structures contain unavoidable logical branches, leading to a conflict between dynamism and confidentiality. For clustering or tree-based ANNS indexes, when a query arrives, the system selects the cluster closest to the query vector or the region in multiple hyperplanes where the query might be located, calculates the similarity distance, and scans nearby vectors to obtain the top k most similar results.

[0089] However, in encrypted scenarios, finding neighboring clusters and possible hyperplanes is difficult to achieve because this process requires selecting and determining directions based on the known distances between the query vector and each logical branch. Specifically, selecting neighboring clusters requires comparing the distances between all centroid vectors and the query vector, while finding possible hyperplanes requires knowing each dimension of the query vector. It should be understood that the centroid vector of a cluster can be the average vector of all vectors in that cluster. However, the query vector and distances should be invisible to the server, which is a difficult dilemma to reconcile. Graph-based ANNS indexing further complicates the situation. When a query vector arrives, the search process begins at the entrance of the graph. Each time the search path passes through a point in the graph, it selects the nearest point among all connected points and continues in a greedy manner. This means that each time a new point is reached through a connecting edge, a direction must be chosen among multiple branches, and this choice depends on the known distances and the query data in plaintext.

[0090] Word-wise fully homomorphic encryption (FHE) only provides SIMD vector computing capabilities and cannot handle branching. While bit-wise FHE theoretically supports implementing any logic through circuit gates, it is difficult to implement complex choices in various dynamic ANNS strategies using only static Boolean circuits.

[0091] Therefore, when faced with unavoidable branches, one can either choose to perform a brute-force distance calculation between the query vector and all encrypted vectors in the database, or send the encrypted data back to the user every time a branch is encountered, allowing the user to decrypt and make a choice. However, both methods increase computational and communication overhead.

[0092] The above describes the challenges faced by the process in Algorithm 1. Next, we will explain the design considerations and overall architecture of the improved solution.

[0093] 3. Design considerations for improvement plans

[0094] In order to address the three major challenges of communication, computing, and indexing structure faced when applying FHE to ANNS, the applicant formulated the following design considerations when developing a privacy-preserving and secure vector retrieval system.

[0095] 1. Optimize distance calculation based on FHE

[0096] Figure 4 The computational flow in the basic mode is shown, and its computational complexity increases linearly with the increase of vector dimension. Therefore, it is proposed to reduce the number of FHE operations in a single vector search.

[0097] 2. Improve the utilization rate of ciphertext slots during communication

[0098] Due to the inherent characteristics of FHE technology, the expansion of message size is inevitable after its introduction. In order to reduce the communication burden, it is proposed to make full use of all slots in the ciphertext. dimensional query vector and indivual When the inner product between dimensional object vectors is generated, the generated inner product ciphertext contains slots, but there are only This results in a scalar inner product, which means a significant waste of space in the ciphertext. Therefore, we propose to fill more inner product results into the ciphertext slots to achieve high ciphertext slot utilization, thereby reducing the amount of ciphertext and alleviating the communication burden. Experiments show that the communication burden can be reduced to less than 1 / 10.

[0099] 3. Delegate the branching of the index structure to the user end

[0100] The preceding analysis of the logical branches of various ANNS index types highlighted the low feasibility of branch selection when dealing with unknown distances in ciphertext. Therefore, we propose moving branch selection to the user side, allowing the scope of the vector similarity search to be determined before reaching the server. This design allows the user and server to jointly construct a complete vector index structure, effectively addressing the shortcomings of FHE in complex logical judgments. Field-tested evaluations have demonstrated good load performance on the user side, with both memory usage and CPU runtime remaining within acceptable limits.

[0101] 4. Overall Architecture of the Improvement Plan

[0102] The following introduces the client-server collaborative architecture and service model in the improvement plan.

[0103] 1. Client-Server Collaborative Architecture. Considering the inevitable branch selection and high communication overhead, we propose moving branch selection to the user side and reducing the number of communication rounds between the user and server. Although the graph-based ANNS index demonstrates superior performance in plaintext mode, its dynamic greedy strategy requires multiple rounds of communication to determine the next action direction, or incurs significant overhead in comparing ciphertexts.

[0104] Therefore, in an improved solution, we propose the use of a partition-based ANNS index, which is similar to cluster-based and tree-based ANNS indexing schemes. It should be understood that partitions can also be referred to as groups, and similar object vectors are pre-assigned to the same partition or group. The m groups created based on the data cube's object vector set (or all object vectors) can be instantiated as multiple clusters in a cluster-based ANNS index or multiple hyperplanes in a tree-based ANNS index.

[0105] like Figure 5 As shown, the user side and the server side ( Figure 5 A trusted wall based on FHE is established between the client and the cloud server (shown in the figure). The client holds multiple partition IDs, for example, {1, 2, ..., n-1, n}, and the plaintext centroid vector corresponding to each partition ID. When the client initiates an ANNS query, the nearest partition is selected by calculating the similarity between the query vector and the n centroid vectors, for example, {3, i, n-2}. The number of partitions selected, p, can be 1 or more.

[0106] When the number of partitions selected is p ≥ 2, one embodiment determines the p centroid vectors with the top p similarities to the query vector, and selects the corresponding p partitions. In another embodiment, in addition to selecting a nearest-neighbor partition, a user-definable coefficient is provided to introduce p-1 randomly generated misleading (or obfuscating) partition IDs into the final p partitions. In this case, the p selected partitions reveal the fuzzy range associated with the query, which can better protect the privacy of the user's query.

[0107] After encrypting the query vector to obtain the corresponding query ciphertext, the user sends the query ciphertext and the selected p partition identifiers to the server. Based on the received p partition identifiers, the server reads the plaintext or ciphertext corresponding to the object vector under each of the p partitions from the local server. The inner product ciphertext can be calculated using FHE and then returned to the user.

[0108] Finally, the user can decrypt the returned inner product ciphertext locally to obtain the k objects closest to his query.

[0109] It should be noted that the following description primarily uses the inner product ciphertext, obtained by the server using FHE and returned to the client, as an example. This is not limited to inner product ciphertexts; the corresponding plaintext can be used to measure the similarity between the query vector and each object vector in the p groups. This can be designed based on existing similarity metrics. Furthermore, it should be noted that the "first" in "first ciphertext," as well as similar terms like "second" elsewhere in the text, are intended to distinguish between similar entities and do not have any other limiting effects, such as ranking.

[0110] The above introduces the client-server collaborative architecture in the improvement plan.

[0111] 2. Service Model

[0112] like Figure 6 As shown, the FHE algorithm is illustrated as the CKKS algorithm. The CKKS algorithm is used to encrypt vectors involved in homomorphic operations and perform inner product calculations on the ciphertext. Furthermore, the Advanced Encryption Standard (AES) is used to encrypt the binary bytes of the centroid vector corresponding to each partition to protect the partition's information security. It should be understood that the FHE algorithm is not limited to the CKKS algorithm; the key used to encrypt and decrypt the centroid vector is not limited to the symmetric key under AES, although it can reduce the encryption and decryption burden of the centroid vector compared to reusing the key of the CKKS algorithm.

[0113] The data party first Figure 6 The entire vector index is deployed on a cloud server (shown in the diagram). If the server is public rather than private, the index data is encrypted and then uploaded to the public server. A connection is then established between the client and the server to begin the vector retrieval service. During this connection, the centroid vector is transmitted to the client. If the centroid vector originates from a public server, its corresponding ciphertext is decrypted on the client side into the plaintext centroid vector. If the distance (or similarity) is calculated using the L2 norm or cosine distance, the magnitude of the centroid vector is also transmitted to the client to reduce computational overhead.

[0114] After the connection is established, the user can encrypt the query vector using the CKKS public key pk and determine the nearest partitions (referring to one or more) locally. Then, the query ciphertext and the IDs of the partitions will be provided to the server. On the server, the FHE engine calculates the inner product ciphertext between the query ciphertext and the object vector ciphertext. Figure 6 The inner product ciphertext is returned to the user. Finally, the user decrypts the inner product ciphertext to obtain the k objects most similar to the query vector.

[0115] The above introduces the overall architecture of the improvement plan.

[0116] V. Specific Implementation of the Improvement Plan

[0117] In this section, we first discuss the design of indexes that reflect the characteristics of ciphertexts. Then, compared with Figure 4 The basic model for calculating the inner product ciphertext based on FHE is shown in the figure, an optimization model is proposed, and how to compress the inner product ciphertext to reduce the traffic overhead of network communication is explained.

[0118] 1. Index construction to achieve balanced and fully utilized partitions.

[0119] As previously analyzed, we proposed using partition-based indexing as the basis for this improved solution. Furthermore, we proposed that simple partitioning methods could be optimized to better support FHE computations.

[0120] For multiple object vectors held by the data provider, such as multiple product vectors corresponding to multiple products, or multiple molecule vectors corresponding to multiple drug molecules, conventional methods of grouping similar vectors into the same partition or group may result in unbalanced partitioning. When combining partition-based ANNS with FHE computation, unbalanced partitioning can lead to significant waste of ciphertext slots and invalidate many subsequent SMID computations.

[0121] In order to make the partitions balanced and fully filled, it is proposed to use a clustering algorithm, especially a hierarchical K-Means clustering algorithm, to obtain balanced partitions and fill the partitions with nearby vectors until the maximum ciphertext length is reached.

[0122] Specifically, clustering can be performed based on the object vector set to obtain m clusters and the centroid vector of each cluster, where the number of vectors in each cluster is less than or equal to a preset value n (or denoted as max). Then, m groups of object vectors are initialized using the m clusters. For each group, a nearest neighbor search algorithm is used to determine a batch of vectors from the object vector set whose similarity to the centroid vector of the group is within a preset range. The group is then filled based on this batch of vectors until the number of vectors in the group reaches n and there are no duplicate vectors. It should be understood that the centroid vector of a group can be the average vector of all object vectors in the group.

[0123] Furthermore, in a specific embodiment, the clustering process may include: performing a first clustering process on the object vector set to obtain multiple first clusters; for each first cluster, if it is determined that the number of vectors therein is greater than n, performing a second clustering process on it, and assigning the obtained multiple second clusters to the m clusters; otherwise, directly assigning the first cluster to the m clusters. Exemplarily, the clustering algorithm used in both the first and second clustering processes may be the K-Means algorithm. In this way, m clusters with a balanced vector distribution are obtained.

[0124] In a specific embodiment, the nearest neighbor search algorithm used when filling each partition may be a K-Nearest Neighbors Algorithm (KNN), etc. In addition, during the filling process, some heuristic filling methods may be used for optimization.

[0125] Table 2 below gives an example of an algorithm for determining index partitions.

[0126] Table 2

[0127]

[0128] In Algorithm 2, the first line of code performs K-Means clustering on the object vector set V to obtain the initial partition result P. Lines 2-5 of the code indicate that for each partition p∈P, if the number of vectors in the partition is greater than max, K-Means clustering is performed on p and p is replaced with the cluster obtained by clustering. This ensures that the size of all partitions is within max, achieving partition balance.

[0129] Lines 6-13 indicate that all partitions are filled with the neighboring vectors of the centroid of each partition, and the size of each filled partition is max. Lines 7-8 indicate that when the number of vectors in p is less than max, the centroid of p is determined from the set V based on the KNN algorithm. The max nearest vectors form a set F. Lines 9-11 of the code indicate that p is filled with F, and the filled vector f is a vector that was not originally in p to prevent subsequent repeated calculations. In addition, the filled p contains max vectors.

[0130] 2. FHE Computing Optimization

[0131] against Figure 4To address the heavy computational and communication burden of FHE in the basic model shown, an optimization scheme is proposed. First, most common similarity or distance metrics used in vector retrieval are based on the inner product (IP), including L2 distance and cosine distance. When obtaining the top k nearest neighbors, only the inner product, or the inner product and norm, is used in the comparison process. Therefore, an improved scheme proposes transmitting the inner product as FHE ciphertext to the user end for determining the k neighboring objects.

[0132] To help understand the algorithm flow of the optimized mode, Algorithm 3 is shown below. It shows the basic process of inner product calculation using FHE primitives in basic mode. Given a d-dimensional query vector (line 1) and a single vector partition containing 𝑛 d-dimensional vectors (line 2), the inner product between the query vector and these 𝑛 vectors is calculated.

[0133] Table 3

[0134]

[0135] In Algorithm 3, multiple copies of the query vector are needed to fill the query ciphertext for subsequent operations. First, the Mult multiplication operation is performed (line 4). Then, in order to obtain the inner product result Due to the SIMD characteristics of FHE, it is necessary to rotate the elements of each dimension of the product of the query vector and each vector to the same slot index position. In the specific implementation: it takes one Rotate operation to move a single-dimensional element of each vector to the target slot. After all dimensions of the vector are shifted to the specified slots, you need to pass The final result is obtained by performing additions and rotations. Given that a single operation has millisecond latency, an optimized computing model must be designed to reduce the number of FHE operations.

[0136] In the optimized mode, the data layout of the vector ciphertext and the FHE inner product calculation mode are optimized to reduce the number of calls to the FHE SIMD primitive. As shown in Table 4 below, the basic mode has the following vector dimensions: The optimized mode reduces the number of Add() and Rotate() operations to Second-rate.

[0137] Table 4: Statistics of the number of FHE operations during inner product calculation

[0138]

[0139] Both modes call Mult() once for each ciphertext. The optimized FHE calculation process is as follows Figure 7 shown.

[0140] Unlike the basic mode, the optimized mode restructures the data layout so that the elements of each vector dimension are compactly arranged instead of in sequence. Figure 7 In the example, the query vector is rearranged into the second rearranged vector shown in the first row, which includes d groups of elements arranged consecutively, and the elements in any i-th group are the query vectors The i-th element of It should be noted that the second rearrangement vector is determined on the user side, and after the user side encrypts the second rearrangement vector using its public key (such as the user public key under the CKKS algorithm), it provides the obtained ciphertext (or query ciphertext) to the server side.

[0141] exist Figure 7 In the example, for any set of object vectors, the n object vectors contained therein are rearranged into the first rearranged vector shown in the second row, which also includes d groups of elements, and the j-th element in any i-th group is the i-th element of the j-th object vector in the set of object vectors. It should be noted that the first rearrangement vector may be stored in plain text on the data party's private server, or the data party may determine the first rearrangement vector locally, encrypt it using the user's public key, and then provide it to the public server for storage.

[0142] The optimized data layout above can make FHE calculations between encryption vectors more efficient.

[0143] Specifically, first, perform a homomorphic multiplication operation on the query ciphertext and the plaintext (or ciphertext) of the first rearranged vector to obtain the current vector ciphertext. For this, please refer to Figure 7 Then, the current vector ciphertext is iterated for log2d times, where any sth iteration includes: 1) performing a step of n*d / 2 on the current vector ciphertext s cyclic rotation; 2) updating the current vector ciphertext to the result of a homomorphic addition operation between the current vector ciphertext and the result of the vector rotation.

[0144] Figure 7 In the first iteration, the second half of the homomorphic multiplication ciphertext in line 3 is rotated using a rotation step of Move it to the beginning, then add the original ciphertext on the third line to the rotated ciphertext on the fourth line. After that, this process continues iteratively, with the rotation step length of each step adjusted to half the length of the previous step. After each rotation, add the ciphertext before and after the rotation again. When , the iterative process ends and we get Figure 7The first n elements of the plaintext corresponding to the ciphertext in the second to last row are the n inner product scalars between the query vector and the n object vectors corresponding to the second row.

[0145] Furthermore, the inner product ciphertext to be returned to the user terminal can be determined based on the iterated current vector ciphertext. In one embodiment, the p iterated current vector ciphertexts corresponding to the p groups can be directly returned to the user terminal as the inner product ciphertext.

[0146] In another embodiment, the mask vector can be used to extract the valid information in the current vector ciphertext so as to compress the ciphertext later, and the compressed ciphertext can be used as the inner product ciphertext. Specifically, Figure 7 The figure shows a homomorphic multiplication operation between the second to last row and the mask vector, retaining only the elements , and all other ciphertext slots are set to 0 to facilitate subsequent compression. It should be noted that the first n bits of the mask vector are predetermined non-zero values (such as 1), and the other bits are zero.

[0147] 3. Ciphertext Compression

[0148] for Figure 7 For each calculated distance ciphertext, also known as the masked ciphertext, IP distance ciphertext, or IP similarity ciphertext, its valid elements are rotated from the starting position to other slots, and the remaining positions are padded with zeros. Specifically, first, the masked ciphertext corresponding to any i-th group among the p groups is cyclically rotated with a step size of (i-1)*n bits. Then, the p rotation results corresponding to the p masked ciphertexts are homomorphically added to obtain the inner product ciphertext.

[0149] like Figure 8 As shown in , in order to fully utilize all slots in a single ciphertext, the Rotate() operation uses an alternating permutation pattern and spans 𝑛 steps. Finally, to achieve compression, FHE Add() is applied to all rotated ciphertexts to merge them into a single ciphertext containing multiple masked results. This compression method improves space utilization from It is increased to nearly 100%, significantly reducing the waste of ciphertext slots and alleviating communication overhead.

[0150] It should be noted that after receiving the inner product ciphertext sent by the server, the client can use the private key to decrypt the inner product ciphertext, regardless of whether it is compressed or not. The decrypted result includes the inner product of the query vector and each object vector in the p groups. From this, the inner product of the query vector and each object vector in the target group can be extracted. Based on this inner product, the object vectors in the target group with the top k similarity to the query vector are determined as the query result.

[0151] Regarding how to calculate the corresponding similarity or distance based on the inner product, in one embodiment, the calculated similarity is set to cosine similarity. Furthermore, in one embodiment, if the query vector and the object vector are both normalized vectors (that is, the modulus of the vector is 1), then the inner product can be directly used as the corresponding cosine similarity. In another embodiment, if one of the query vector and the object vector is not a normalized vector, then it is necessary to divide the inner product by the norm of the object vector and the query vector corresponding to the inner product (or the modulus of the vector, the size of the vector), and use the quotient obtained as the corresponding cosine similarity. It should be understood that the norm of the query vector can be calculated locally by the user end, and the norm of the object vector can be provided by the server end when providing the centroid vector to the client.

[0152] In another embodiment, the calculated distance is set to be the L2 norm. In this case, according to the definition of the L2 norm between two vectors:

[0153] (1)

[0154] Assume that a and b are query vector and object vector respectively, then That is, the square of the size of the query vector, is the inner product between two vectors, is the square of the magnitude of the object vector.

[0155] Therefore, based on formula (5), the L2 norm between the query vector and the object vector, as well as the inner product between the two vectors, can be calculated.

[0156] It can be understood that calculating similarity and distance is feasible. Distance is negatively correlated with similarity. Selecting object vectors with the top k similarities means selecting object vectors with the bottom k distances.

[0157] From the above, the user end can complete the determination of the top k similar object vectors as the query result, or further determine the corresponding k object identifiers as the query result.

[0158] In summary, the vector retrieval service method proposed in the embodiment of this specification is adopted to introduce FHE to achieve data privacy protection for users and data parties. In addition, it is proposed to move the branch selection to the user side, so that the range of the vector similarity search can be determined before reaching the server. Through this design, the user side and the server side jointly build a complete vector index structure, which effectively makes up for the shortcomings of FHE in complex logical judgment. Furthermore, it is proposed to simplify the distance or similarity calculation in FHE to the inner product calculation, and optimize the inner product calculation mode to effectively reduce the computational complexity. Furthermore, it is proposed to compress and merge the result ciphertext corresponding to each partition to obtain the inner product ciphertext, thereby improving the space utilization of the ciphertext slot and effectively reducing the communication overhead.

[0159] Corresponding to the above-mentioned vector search method, the embodiments of this specification also disclose a vector search device. The details are as follows:

[0160] Figure 9 The vector retrieval device 900 shown in FIG is integrated into a client, and the server corresponding to the client stores the plaintext or ciphertext corresponding to each group of object vectors in m groups of object vectors, and the client stores the centroid vector of each group of object vectors. Figure 9 As shown, the vector search device 900 includes the following functional modules:

[0161] The target group determination unit 910 is configured to calculate the similarity between the query vector corresponding to the user's query input and the centroid vector, and obtain the target group identifier corresponding to the highest similarity. The query data sending unit 920 is configured to send the ciphertext corresponding to the query vector and p group identifiers to the server; wherein p < m, the p group identifiers include the target group identifier. The inner product ciphertext receiving unit 930 is configured to receive a first ciphertext, the corresponding plaintext of which is used to measure the similarity between the query vector and each object vector in the p groups; the inner product ciphertext is determined by the server based on its locally stored vectors and the received vectors through homomorphic operations. The query result determination unit 940 is configured to determine the similarity between the query vector and each object vector in the target group based on the decryption result of the first ciphertext, so as to obtain the query result corresponding to the query input.

[0162] In one embodiment, the m groups of object vectors and centroid vectors are determined by the data provider based on the following steps:

[0163] A clustering process is performed based on the object vector set to obtain m clusters and the centroid vector of each cluster, where the number of vectors in each cluster is less than or equal to a preset value n. The m clusters are used to initialize m groups of object vectors. For each group, a nearest neighbor search algorithm is used to identify a batch of vectors from the object vector set whose similarity to the centroid vector of the group is within a preset range. The group is then populated based on this batch of vectors until the number of vectors in the group reaches n and there are no duplicate vectors.

[0164] Furthermore, in a specific embodiment, performing clustering based on the object vector set to obtain m clusters includes: performing a first clustering process on the object vector set to obtain multiple first clusters. For each first cluster, if it is determined that the number of vectors therein is greater than n, performing a second clustering process on the first cluster, and assigning the multiple second clusters obtained to the m clusters; otherwise, directly assigning the first cluster to the m clusters.

[0165] In one embodiment, the vector retrieval apparatus 900 further includes a query data determination module configured to randomly select p-1 other partition identifiers from the m group identifiers based on the target partition identifier, group the selected partition identifiers into the p group identifiers, and perform encryption processing based on the query vector to obtain a query ciphertext.

[0166] In one embodiment, the server is implemented as a third-party server, which stores the ciphertext corresponding to each group of object vectors, and the ciphertext is provided by the data provider.

[0167] Furthermore, in a specific embodiment, the vector retrieval device 900 also includes: a centroid ciphertext receiving unit, configured to receive the ciphertexts of the respective centroid vectors from the third-party server, which are obtained by the data party encrypting the respective centroid vectors using a symmetric key; a centroid ciphertext decryption unit, configured to decrypt the ciphertexts of the respective centroid vectors using the symmetric key, and store the decrypted plaintexts.

[0168] In one embodiment, the server is implemented as a private server of the data party, in which the plaintexts corresponding to the m groups of object vectors are stored.

[0169] Furthermore, in a specific embodiment, the vector retrieval device 900 further includes: a centroid receiving unit configured to receive m centroid vectors corresponding to the m groups of object vectors from the private server and store them.

[0170] In one embodiment, the first ciphertext includes an inner product ciphertext, and the plaintext corresponding to the inner product ciphertext includes the inner product between the query vector and each object vector in the p groups.

[0171] In one embodiment, the query result determination unit 940 is specifically configured to: for each object vector in the target group, extract the inner product between the object vector and the query vector from the decryption result as the corresponding similarity.

[0172] In one embodiment, the client also stores the norm of each object vector in the m groups; the query result determination unit 940 is specifically configured to: for each object vector in the target group, extract the inner product between it and the query vector from the decryption result, and determine the similarity between the object vector and the query vector based on the inner product, the norm of the object vector and the norm of the query vector.

[0173] In one embodiment, the query result determination unit 940 is further configured to determine k object IDs corresponding to the top k similarities as the query result.

[0174] Figure 10 The vector search device 1000 shown in FIG is integrated into a server, which stores the plaintext or ciphertext corresponding to each group of object vectors in m groups of object vectors, and the client corresponding to the server stores the centroid vector of each group of object vectors. Figure 10 As shown, the vector search device 1000 includes the following functional modules:

[0175] The query data receiving unit 1010 is configured to receive the ciphertext corresponding to the query vector and p group identifiers from the client; wherein p < m, the p group identifiers include the target group identifier; the similarity between the centroid vector of the target group and the query vector is higher than that of other groups, and the query vector is determined based on the user's query input. The first ciphertext determining unit 1020 is configured to perform homomorphic operations based on the locally stored and received data to obtain a first ciphertext, the corresponding plaintext of which is used to measure the similarity between the query vector and each object vector in the p groups. The first ciphertext sending unit 1030 is configured to send the first ciphertext to the client, so that the client determines the similarity between the query vector and each object vector in the target group based on the decryption result of the first ciphertext, so as to obtain the query result corresponding to the query input.

[0176] In one embodiment, the server is implemented as a third-party server. The vector search device 1000 further includes a group ciphertext receiving unit configured to receive the ciphertext corresponding to each group of object vectors from the data source.

[0177] In one embodiment, the server is implemented as a private server of the data party, in which the plaintexts corresponding to the m groups of object vectors are stored.

[0178] In one embodiment, the first ciphertext includes an inner product ciphertext, and the plaintext corresponding to the inner product ciphertext includes the inner product between the query vector and each object vector in the p groups.

[0179] Furthermore, in a specific embodiment, each group of object vectors includes n object vectors, and the corresponding plaintext is a first rearranged vector of the group of object vectors, the first rearranged vector including d groups of elements, where the jth element in any i-th group is the i-th element of the j-th object vector in the group of object vectors; or, the ciphertext corresponding to each group of object vectors is obtained by encrypting the first rearranged vector using the user's public key. The ciphertext corresponding to the query vector is obtained by encrypting a second rearranged vector using the public key, the second rearranged vector including d groups of elements, where the elements in any i-th group are the i-th elements of the query vector.

[0180] The first ciphertext determination unit 1020 is specifically configured as follows: for any group in the p groups, perform a homomorphic multiplication operation on the plaintext or ciphertext of the first rearranged vector of the group and the ciphertext of the second rearranged vector to obtain a current vector ciphertext; perform log2d iterations on the current vector ciphertext, wherein any sth iteration includes: performing a step of n*d / 2 on the current vector ciphertext s cyclic rotation; updating the current vector ciphertext to the result of a homomorphic addition operation between the current vector ciphertext and the result of the rotation of the vector; determining the inner product ciphertext based on the iterated current vector ciphertext, wherein the first n elements of the plaintext corresponding to the current vector ciphertext are the inner products between the query vector and each object vector in the corresponding group.

[0181] Furthermore, in one example, the first ciphertext determining unit 1020 is configured to determine the inner product ciphertext based on the iterated current vector ciphertext, specifically including:

[0182] Performing a homomorphic multiplication operation on the current vector ciphertext using a mask vector to obtain a masked result ciphertext; the first n bits of the mask vector are predetermined non-zero values, and the remaining bits are zero. Merging the p masked result ciphertexts corresponding to the p groups, specifically comprising: performing a cyclic rotation with a step size of (i-1)*n bits on the i-th masked result ciphertext; and performing a homomorphic addition operation on the p rotation results corresponding to the p masked result ciphertexts to obtain the inner product ciphertext.

[0183] It should be noted that for the introduction of the above functional modules, reference can also be made to the relevant introduction of the process method in the aforementioned embodiment.

[0184] Those skilled in the art will appreciate that, in one or more of the above examples, the functions described herein may be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions may be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium.

[0185] The specific implementation methods described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific implementation method of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solution of the present invention should be included in the scope of protection of the present invention.

Claims

1. A vector retrieval method that protects data privacy, which involves a client storing the centroid vector of each group of object vectors; The method is applied to the client, comprising: Calculate the similarity between the query vector and the centroid vector according to the user's query input, and obtain the target group identifier corresponding to the highest similarity; Sending the ciphertext corresponding to the query vector and p group identifiers to the server; the p group identifiers include the target group identifier; receiving a first ciphertext whose corresponding plaintext is used to measure the similarity between the query vector and each object vector in the p groups; the first ciphertext is determined by the server by performing a homomorphic operation based on the locally stored vector and the received vector; Based on the decryption result of the first ciphertext, the similarity between the query vector and each object vector in the target group is determined to obtain a query result corresponding to the query input.

2. The method according to claim 1, wherein Each group of object vectors belongs to m groups of object vectors; wherein the m groups of object vectors and the centroid vector are determined by the data processor based on the following steps: Performing clustering based on the object vector set to obtain m clusters and the centroid vector of each cluster, wherein the number of vectors in each cluster is less than or equal to a preset value n; The m clusters are used to initialize m groups of object vectors. For each group, a nearest neighbor search algorithm is used to determine a batch of vectors whose similarity with the centroid vector of the group is within a preset range from the object vector set, and the group is filled based on the batch of vectors until the number of vectors in the group reaches n and there are no duplicate vectors.

3. The method according to claim 2, wherein: Based on the object vector set, clustering is performed to obtain m clusters, including: Performing a first clustering process on the object vector set to obtain a plurality of first clusters; For each first cluster, if it is determined that the number of vectors therein is greater than n, a second clustering process is performed on it, and the obtained multiple second clusters are classified into the m clusters; otherwise, the first cluster is directly classified into the m clusters.

4. The method according to claim 1, wherein Each group of object vectors belongs to m groups of object vectors; wherein determining the p group identifiers includes: Based on the target group identifier, p-1 other partition identifiers are randomly selected from the m group identifiers and included in the p group identifiers.

5. The method according to claim 1, wherein The server is implemented as a third-party server, which stores the ciphertext corresponding to each group of object vectors, and the ciphertext is provided by the data party.

6. The method according to claim 5, further comprising: receiving a ciphertext of the centroid vector from the third-party server, which is obtained by the data party encrypting the centroid vector using a symmetric key; The ciphertext of the centroid vector is decrypted using the symmetric key, and the decrypted plaintext is stored.

7. The method according to claim 1, wherein The server is implemented as a private server of the data party, in which the plaintext corresponding to each group of object vectors is stored.

8. The method according to claim 7, further comprising: The centroid vector is received from the private server and stored.

9. The method according to claim 1, wherein The first ciphertext includes an inner product ciphertext, and its corresponding plaintext includes the inner product between the query vector and each object vector in the p groups.

10. The method according to claim 1 or 9, wherein Determining, based on the decryption result of the first ciphertext, the similarity between the query vector and each object vector in the target group, includes: For each object vector in the target group, the inner product between the object vector and the query vector is extracted from the decryption result as the corresponding similarity.

11. The method according to claim 1 or 9, wherein: The client further stores the norm of each object vector in each group of object vectors; wherein, determining the similarity between the query vector and each object vector in the target group based on the decryption result of the first ciphertext includes: For each object vector in the target group, an inner product between the object vector and the query vector is extracted from the decryption result, and a similarity between the object vector and the query vector is determined based on the inner product, a norm of the object vector, and a norm of the query vector.

12. The method according to claim 1, wherein After determining the similarity between the query vector and each object vector in the target group, the method further includes: The k object IDs corresponding to the top k similarities are determined as the query result.

13. A vector retrieval method for protecting data privacy, wherein the client stores the centroid vector of each group of object vectors; The method is applied to the server and includes: receiving, from the client, a ciphertext corresponding to a query vector and p group identifiers, wherein the p group identifiers include a target group identifier; a centroid vector of the target group having a higher similarity to the query vector than other groups, the query vector being determined based on a query input by a user; Performing a homomorphic operation based on the locally stored vector and the received vector to obtain a first ciphertext, the corresponding plaintext of which is used to measure the similarity between the query vector and each object vector in the p groups; The first ciphertext is sent to the client, so that the client determines the similarity between the query vector and each object vector in the target group based on the decryption result of the first ciphertext, so as to obtain a query result corresponding to the query input.

14. The method according to claim 13, wherein The server is implemented as a third-party server; the method further includes: The ciphertext corresponding to each group of object vectors is received from the data source.

15. The method according to claim 13, wherein The server is implemented as a private server of the data party, in which the plaintext corresponding to each group of object vectors is stored.

16. The method according to claim 13, wherein The first ciphertext includes an inner product ciphertext, and its corresponding plaintext includes the inner product between the query vector and each object vector in the p groups.

17. The method according to claim 16, wherein The server stores the plaintext or ciphertext corresponding to each group of object vectors; each group of object vectors includes n object vectors, and the corresponding plaintext is a first rearranged vector of the group of object vectors, the first rearranged vector includes d groups of elements, wherein the jth element in any i-th group is the i-th element of the j-th object vector in the group of object vectors; alternatively, the ciphertext corresponding to each group of object vectors is obtained by encrypting the first rearranged vector using the public key of the user; The ciphertext corresponding to the query vector is obtained by encrypting a second rearranged vector using the public key, the second rearranged vector including d groups of elements, wherein any element of the i-th group is an i-th dimension element of the query vector; The homomorphic operation includes: for any group of the p groups, performing a homomorphic multiplication operation on the plaintext or ciphertext of the first rearranged vector of the group and the ciphertext of the second rearranged vector to obtain the current vector ciphertext; performing log2d iterations on the current vector ciphertext, wherein any sth iteration includes: performing a step of n*d / 2 on the current vector ciphertext s cyclic rotation; updating the current vector ciphertext to the result of a homomorphic addition operation between the current vector ciphertext and the result of the rotation of the vector; determining the inner product ciphertext based on the iterated current vector ciphertext, wherein the first n elements of the plaintext corresponding to the current vector ciphertext are the inner products between the query vector and each object vector in the corresponding group.

18. The method according to claim 17, wherein Determining the inner product ciphertext based on the iterated current vector ciphertext includes: Performing a homomorphic multiplication operation on the current vector ciphertext using a mask vector to obtain a masked result ciphertext; the first n bits of the mask vector are predetermined non-zero values, and the remaining bits are zero; The p masked result ciphertexts corresponding to the p groups are merged, specifically comprising: performing a cyclic rotation with a step size of (i-1)*n bits on the i-th masked result ciphertext; and performing a homomorphic addition operation on the p rotation results corresponding to the p masked result ciphertexts to obtain the inner product ciphertext.

19. A vector retrieval device for protecting data privacy, integrated into a client, wherein the client stores the centroid vector of each group of object vectors; the device comprises: a target group determination unit configured to calculate the similarity between the query vector corresponding to the user's query input and the centroid vector, and obtain the target group identifier corresponding to the highest similarity; A query data sending unit configured to send the ciphertext corresponding to the query vector and p group identifiers to a server; the p group identifiers include the target group identifier; an inner product ciphertext receiving unit configured to receive a first ciphertext, the corresponding plaintext of which is used to measure the similarity between the query vector and each object vector in the p groups; the first ciphertext is determined by the server through a homomorphic operation based on the locally stored vector and the received vector; The query result determination unit is configured to determine the similarity between the query vector and each object vector in the target group according to the decryption result of the first ciphertext, so as to obtain a query result corresponding to the query input.

20. A vector retrieval device for protecting data privacy, integrated into a server, wherein a client corresponding to the server stores the centroid vector of each group of object vectors; the device comprises: a query data receiving unit configured to receive the ciphertext corresponding to the query vector and p group identifiers from the client; The p group identifiers include a target group identifier; The centroid vector of the target group has a higher similarity to the query vector than the other groups, wherein the query vector is determined based on the query input of the user; a first ciphertext determination unit configured to perform a homomorphic operation based on the locally stored vector and the received vector to obtain a first ciphertext, the corresponding plaintext of which is used to measure the similarity between the query vector and each object vector in the p groups; The first ciphertext sending unit is configured to send the first ciphertext to the client, so that the client determines the similarity between the query vector and each object vector in the target group based on the decryption result of the first ciphertext, so as to obtain a query result corresponding to the query input.

21. A computer-readable storage medium having a computer program stored thereon, wherein: When the computer program is executed in a computer, the computer is caused to execute the method according to any one of claims 1 to 18.

22. A computing device comprising a memory and a processor, wherein: The memory stores executable code, and when the processor executes the executable code, the method according to any one of claims 1 to 18 is implemented.

Images