Retrieval-Augmented Generation (RAG) enables large language models to use external knowledge, but outsourcing the RAG service raises privacy concerns for both data owners and users. Privacy-preserving RAG systems address these concerns by performing secure top-k retrieval, which is typically implemented using secure sorting to identify relevant documents. However, existing systems face challenges supporting arbitrary k due to their inability to change k, new security issues, and in particular, efficiency degradation with large k. This is a significant limitation because applications such as finance, law, and healthcare require a k that is large enough to cause huge overhead for existing systems. Also, modern long-context models generally achieve higher accuracy with larger retrieval sets. We propose P2RAG, an efficient privacy-preserving RAG service that supports arbitrary top-k retrieval. Unlike existing systems, P2RAG avoids sorting candidate documents. Instead, it uses an interactive bisection method to determine the set of top-k documents. For security, P2RAG uses secret sharing on two semi-honest non-colluding servers to protect the data owner's database and the user's prompt. It enforces restrictions and verification to defend against malicious users and tightly bounds the information leakage of the database. The experiments show that P2RAG is 3--300× faster than the state-of-the-art PRAG for k=16--1024.
Figures & tables
Figure 1: The workflow of P 2 RAG. During the offline stage, the data owner sets up the secret-shared database. During the distance calculation, the servers compute the secret-shared distances between each document and the user’s prompt. During the distance bisection, the user determines a distance threshold dk for the top- k documents. The bisection iteration ends when dk is found, or the number of iterations exceeds an upper bound. During the text retrieval, the user retrieves textual documents using the indices of the top- k documents.
Figure 2: Relevance score (higher is better) with varying numbers of retrieved documents k′
Figure 3: Server time (lower is better) with varying numbers of documents N and retrieved documents k′ . k′=16 and N=217 for the two figures, respectively.
N\mathchar59k′
P 2 RAG
PRAG
Speedup
214\mathchar5916
0.106s
0.400s
3.78 ×
217\mathchar5916
0.751s
2.84s
3.78 ×
220\mathchar5916
6.89s
22.9s
3.33 ×
217\mathchar59128
0.594s
19.5s
32.9 ×
217\mathchar591024
0.448s
144s
322 ×
Table 1: Server time behind Figure 3 .
Comm. Type
Volume (B)
RTT
User-server
16384+4224S+16N
S+1
Intra-server
64N+16NS+32
S+1
N , k′
Volume of US, IS
RTT
217 , 16
2.168 MB, 35.65 MB
14
217 , 128
2.156 MB, 29.36 MB
11
220 , 16
16.86 MB, 335.5 MB
17
Table 2: Communication volume and number of RTTs.
Appendix figures & tables4 assets
Supplementary material from the paper’s appendix.
Appendix
Dataset
N
Avg.
Max
S
nfcorpus
3\mathchar59633
6.2
8
8
fiqa
57\mathchar59638
6.2
12
12
trec-covid
171\mathchar59332
6.8
14
14
quora
522\mathchar59931
6.2
15
15
trec-news
594\mathchar59977
6.1
16
16
Appendix
Table 3: Empirical number of iterations with k′=16 .
Link
RTT
Bandwidth
Intra-server (SG ↔ HK)
33.3ms
640Mbps
User ↔ Server (SG)
40.2ms
40.7Mbps
User ↔ Server (HK)
8.14ms
58.0Mbps
Appendix
Table 4: Network setup: latency and bandwidth.
N\mathchar59k′
P 2 RAG
PRAG
Text. per doc.
Text.
217\mathchar5916
0.751s
2.84s
3.60ms
57.6ms
217\mathchar59128
0.594s
19.5s
3.60ms
0.461s
220\mathchar5916
6.88s
22.9s
10.4ms
0.166s
Appendix
Table 5: Server time (lower is better) with varying numbers of documents N and retrieved documents k′ .