A verifiable private information retrieval method against poisoning attacks on RAG knowledge base

Abstract

This application proposes a verifiable private information retrieval method against RAG knowledge base poisoning attacks, comprising the following steps: The server maps each data fragment in the knowledge base to a polynomial form in a polynomial ring to obtain the server-side knowledge base; the client generates a query polynomial and a private key based on the polynomial ring, generates a private commitment based on the private key, constructs a private query, and sends it to the server; the server performs ciphertext field retrieval calculation on the polynomial ring based on the private query to generate a ciphertext polynomial for the retrieval response; the client performs decryption operation on the ciphertext polynomial for the retrieval response in the response message using the private key to obtain the retrieval result. This scheme generates a unique version identifier and knowledge base commitment for the server-side knowledge base. When the knowledge base content is legally updated, a new knowledge base commitment and version identifier are generated and published simultaneously, without the need to reconstruct the entire knowledge base index, significantly reducing the preprocessing overhead and time cost of dynamic updates to the knowledge base in private retrieval.

Description

Technical Field

[0001] This application relates to the field of retrieval enhancement generation, and in particular to a verifiable private information retrieval method for RAG knowledge base poisoning attacks. Background Technology

[0002] Retrieval Augmentation (RAG) technology, by deeply integrating external knowledge base retrieval with the generation capabilities of large language models, effectively alleviates the inherent illusion problem of large models and significantly improves the accuracy and timeliness of responses in scenarios such as knowledge-intensive question answering and industry knowledge base services. Since its inception in 2020, it has become one of the most widely applied technical frameworks in the field of artificial intelligence. Existing RAG-related research mainly focuses on document vectorization optimization, retrieval re-ranking mechanisms, and caching strategy upgrades. The core goal is to improve retrieval accuracy and generation quality, but it generally assumes that the retrieval backend and knowledge base are completely trustworthy, and fails to establish a systematic verification mechanism for the authenticity, completeness, and timeliness of the results during the retrieval stage. Knowledge base poisoning attacks have become a core security threat to RAG systems. Attackers can inject malicious and misleading content into the knowledge base, allowing the contaminated data to directly enter the model context during retrieval, continuously misleading the generated results. Current technologies cannot block the core propagation path of this attack during the retrieval stage.

[0003] Private Information Retrieval (PIR), as a core cryptographic protocol for protecting user query privacy, ensures that user search content and access patterns are completely invisible to the server, making it naturally suited to the privacy-sensitive RAG application needs in fields such as healthcare, finance, and corporate confidential data. Since its inception in 1995, PIR technology has undergone multiple rounds of optimization. Schemes such as SealPIR, SimplePIR, and YPIR have achieved significant breakthroughs in communication overhead and computational efficiency. The introduction of verifiable PIR (vPIR) has also initially achieved the verification of the correctness of search results. However, existing schemes still have significant limitations: most assume that the server honestly executes the protocol, lack effective verification of database state consistency and freshness, require high preprocessing overhead for database content updates, and are not deeply adapted to RAG business processes, making it difficult to simultaneously ensure query privacy protection, result verifiability, and system operating efficiency.

[0004] Currently, the integrated application of RAG and PIR technologies still faces technical bottlenecks, making it difficult to simultaneously address the issues of privacy protection in retrieval, reliable verification of results, and defense against poisoning attacks. In practical scenarios involving untrusted retrieval servers and dynamically updated knowledge bases, there is a lack of an efficient and verifiable private information retrieval solution that is compatible with the entire RAG process, and targeted technological breakthroughs are urgently needed. Summary of the Invention

[0005] This application provides a verifiable private information retrieval method against RAG knowledge base poisoning attacks. This solution generates a unique version identifier and knowledge base commitment for the server-side knowledge base. When the knowledge base content is legally updated, a new knowledge base commitment and version identifier are generated and published simultaneously. There is no need to reconstruct the entire knowledge base index, which significantly reduces the preprocessing overhead and time cost of dynamic updates of the knowledge base in private retrieval.

[0006] In a first aspect, embodiments of this application provide a verifiable private information retrieval method for RAG knowledge base poisoning attacks, the method comprising:

[0007] S100. The server maps each data fragment in the knowledge base to a polynomial form in a polynomial ring to obtain the server knowledge base. The server knowledge base generates a public knowledge base commitment and a server knowledge base version identifier for the server knowledge base. The knowledge base commitment is used to verify the immutability of the data in the corresponding server knowledge base. S200: The client generates a query polynomial and a private key based on the polynomial ring, generates a private commitment based on the private key, and constructs a private query with the query polynomial, private query parameters generated based on the private key, private commitment, target query, and target knowledge base version identifier and sends it to the server. The private commitment corresponds to the private key. S300: The server performs encrypted domain retrieval calculation on the polynomial ring based on the private query to generate the encrypted polynomial of the retrieval response. Based on the private commitment, knowledge base commitment, server knowledge base version identifier and the encrypted polynomial of the retrieval response, the server hash verification parameters are generated. Based on the server hash verification parameters, the verification proof is generated. The server hash verification parameters, the verification proof, the encrypted polynomial of the retrieval response and the server knowledge base version identifier are encapsulated into a response message and returned to the client. S400: The client verifies the response message based on the knowledge base commitment, private commitment, and target knowledge base version identifier. Once the verification is successful, the client uses the private key to perform a decryption operation on the ciphertext polynomial of the retrieval response in the response message to obtain the retrieval result.

[0008] Secondly, embodiments of this application provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute a verifiable private information retrieval method for RAG knowledge base poisoning attacks.

[0009] The main contributions and innovations of this invention are as follows: In this embodiment, the server maps each data fragment in the knowledge base to a polynomial form within a polynomial ring, transforming discrete knowledge base data fragments into a unified algebraic form suitable for polynomial ring encryption and retrieval operations. This provides a consistent computational foundation for subsequent ciphertext domain retrieval and the entire encryption / decryption process. This embodiment generates a public knowledge base commitment for the mapped server-side knowledge base, satisfying computational binding and computational hiding. This cryptographically locks the data immutability of the server-side knowledge base, preventing the server from replacing, tampering with, or injecting poisoned content into the knowledge base without detection. This solution generates a unique version for the server-side knowledge base. The system identifies and commits to the knowledge base. When the knowledge base content is legally updated, a new knowledge base commitment and version identifier are generated and published simultaneously. This eliminates the need to reconstruct the entire knowledge base index, significantly reducing the preprocessing overhead and time cost of dynamic knowledge base updates in private searches. In this embodiment, the client uses the same hash calculation method to perform hash calculations and compares them with the corresponding parameters returned by the server. At the same time, the verification proof π is verified. Only when all verifications pass does the decryption process begin. The client can independently complete the entire verification process locally without relying on a third-party trusted institution. This allows the client to verify whether the search results come from the committed legitimate knowledge base, whether they are strictly executed according to the current query, and whether they have been tampered with.

[0010] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0011] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart of a verifiable private information retrieval method for RAG knowledge base poisoning attacks, according to an embodiment of this application. Figure 2 This is an experimental result graph showing the attack success rate under different Top-k search strategies according to embodiments of this application; Figure 3 These are experimental results figures from comparative experiments conducted on different task datasets and different large language models according to embodiments of this application; Figure 4 This is a graph showing the experimental results of testing rejection rate and attack success rate under different poisoning ratios according to the embodiments of this application; Figure 5 These are experimental results diagrams illustrating the verification of system performance based on embodiments of this application; Figure 6 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0012] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0013] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0014] Example 1 This application provides a verifiable private information retrieval method against RAG knowledge base poisoning attacks. This method generates a unique version identifier and knowledge base commitment for the server-side knowledge base. When the knowledge base content is legally updated, a new knowledge base commitment and version identifier are generated and published simultaneously, without needing to reconstruct the entire knowledge base index. This significantly reduces the preprocessing overhead and time cost of dynamic knowledge base updates in private retrieval. Specifically, refer to... Figure 1 The method includes: S100. The server maps each data fragment in the knowledge base to a polynomial form in a polynomial ring to obtain the server knowledge base. The server knowledge base generates a public knowledge base commitment and a server knowledge base version identifier for the server knowledge base. The knowledge base commitment is used to verify the immutability of the data in the corresponding server knowledge base. S200: The client generates a query polynomial and a private key based on the polynomial ring, generates a private commitment based on the private key, and constructs a private query with the query polynomial, private query parameters generated based on the private key, private commitment, target query, and target knowledge base version identifier and sends it to the server. The private commitment corresponds to the private key. S300: The server performs encrypted domain retrieval calculation on the polynomial ring based on the private query to generate the encrypted polynomial of the retrieval response. Based on the private commitment, knowledge base commitment, server knowledge base version identifier and the encrypted polynomial of the retrieval response, the server hash verification parameters are generated. Based on the server hash verification parameters, the verification proof is generated. The server hash verification parameters, the verification proof, the encrypted polynomial of the retrieval response and the server knowledge base version identifier are encapsulated into a response message and returned to the client. S400: The client verifies the response message based on the knowledge base commitment, private commitment, and target knowledge base version identifier. Once the verification is successful, the client uses the private key to perform a decryption operation on the ciphertext polynomial of the retrieval response in the response message to obtain the retrieval result.

[0015] In the current embodiment, the polynomial ring is an algebraic structure. The polynomial ring is constructed based on system security parameters. All subsequent encryption and decryption calculations are performed within the scope defined by the polynomial ring to ensure the security and consistency of the calculations.

[0016] Specifically, the polynomial ring is represented as follows:

[0017] in, It is a polynomial ring. For modulus, For a predefined polynomial, For the set of integers, It is an undetermined element.

[0018] Specifically, the server-side knowledge base is obtained by mapping data fragments within the knowledge base to elements within a polynomial ring, as expressed by the formula:

[0019] in, For server-side knowledge base, The total number of data fragments within the knowledge base. For indexing data fragments, , These are the polynomial coefficients mapped to the polynomial ring.

[0020] Specifically, the server performs polynomial mapping on the knowledge base data in order to transform the data fragments within the knowledge base into a form suitable for encryption and retrieval on a polynomial ring.

[0021] In step S100, a knowledge base commitment is generated based on the data fragments in the server-side knowledge base. The knowledge base commitment satisfies computational binding and computational hiding, thereby ensuring that the server cannot replace or tamper with the content of the server-side knowledge base without being detected in the subsequent retrieval stage, thus ensuring the immutability of the data in the server-side knowledge base.

[0022] For example, when the server-side knowledge base is poisoned, causing data fragments to be modified, the system will realize that the server-side knowledge base has been poisoned because the publicly disclosed knowledge base commitments cannot correspond to the poisoned server-side knowledge base. Furthermore, the incompatibility between the knowledge base commitments and the poisoned server-side knowledge base will also cause the client's retrieval to fail. Therefore, the poisoning of the server-side knowledge base will not affect the client, thus ensuring the security of both the server and the client.

[0023] In step S100, when the data content of the server-side knowledge base is legally updated, the server generates and publishes a new knowledge base commitment and a server-side knowledge base version identifier based on the updated server-side knowledge base.

[0024] Specifically, when knowledge base maintainers add, delete, or modify knowledge base content, the polynomial representation in the server-side knowledge base is updated synchronously to complete the legitimate update of the server-side knowledge base.

[0025] Specifically, when the data content of the server-side knowledge base is legally updated, the knowledge base commitment and the server-side knowledge base version identifier are updated and made public simultaneously to ensure that the updated server-side knowledge base can be retrieved normally. In other words, when facing database updates, this solution only needs to update the knowledge base commitment and the server-side knowledge base version identifier again, without having to reconstruct the entire knowledge base index, which greatly reduces the time required for knowledge base updates.

[0026] For example, the server-side knowledge base version identifier in this solution is updated in an incremental manner. For instance, if the current server-side knowledge base version identifier is 1.0.0, then the updated server-side knowledge base version identifier will be 1.0.1.

[0027] Specifically, a one-to-one correspondence is established between the knowledge base commitments identified by different server-side knowledge base versions and the content of the server-side knowledge base, in order to prevent the server from performing retrieval calculations on expired or rolled-back server-side knowledge bases.

[0028] In this solution, the knowledge base commitment and the server-side knowledge base version identifier are made public to ensure that the client can perform private queries against the server-side knowledge base, and the knowledge base commitment and the server-side knowledge base version identifier are used as the basis for verifying the search results in subsequent protocol interactions.

[0029] In step S200, the query polynomial is the query carrier of the current query, and the query polynomial is randomly generated with each query. The private key is privately stored by the client, and the target query is the data index information in the target knowledge base.

[0030] Specifically, the query polynomial is obtained by uniformly and randomly sampling within the polynomial ring, which is unpredictable. Constructing a private query using the query polynomial allows the server to obtain the query result simply by performing decryption operations within the polynomial ring without knowing the query intent. In addition, since the query polynomial is randomly generated with each query, it effectively prevents replay attacks.

[0031] Specifically, the private key is kept privately by the client throughout the entire process and is never disclosed to the server or any third party. When the client receives the encrypted polynomial of the search response, it performs the operation within the polynomial ring using the private key to obtain the actual search result, thus ensuring the confidentiality of the private search.

[0032] In step S200, a private polynomial is constructed based on the query polynomial, the private key, the noise polynomial, and the target query. The formula is expressed as:

[0033] in, For private polynomials, To query a polynomial, For private keys, It is a noise polynomial. Query for target; A private query is constructed based on the private polynomial, the query polynomial, the private commitment, and the target knowledge base version identifier. The formula is expressed as:

[0034] in, For private queries, To query a polynomial, For private polynomials, For private commitments, This is the version identifier for the target knowledge base.

[0035] In other words, this solution hides the target query in the private polynomial by using query polynomials, private polynomials, and noisy polynomials, making it impossible for the server to know the accurate search intent.

[0036] Specifically, the computational indistinguishability of private queries is guaranteed by introducing a noise polynomial.

[0037] Specifically, to ensure the accuracy of the server-side retrieval process, a corresponding private commitment is generated based on the private key. Since both the private key and the target query in this scheme are located in... If the server does not perform a search according to the target query, the private key will change due to computational effects. Unable to By doing so, the client will know that the server did not perform the search according to the target query when it receives the search results.

[0038] In other words, this scheme constrains the server's computational behavior during the retrieval phase by verifying the correspondence between the private key and the private commitment.

[0039] In step S300, the server parses the target knowledge base version identifier in the private query. If the target knowledge base version identifier does not match the server knowledge base version identifier, the private query is rejected.

[0040] In other words, encrypted domain retrieval is only allowed when the target knowledge base version identifier in the private query matches the server-side knowledge base version identifier. This avoids generating retrieval results in an expired or rolled-back knowledge base state and ensures consistency constraints between subsequent retrieval responses and the committed knowledge base state.

[0041] When the target knowledge base version identifier matches the server knowledge base version identifier, the formula for the server to perform encrypted domain retrieval calculation on the polynomial ring is expressed as:

[0042] in, To retrieve the ciphertext polynomial of the response, To query a polynomial, For the polynomial representation of the server-side knowledge base, For the auxiliary polynomial carried in the private query, obtain based on the private query. and .

[0043] Specifically, because the client embeds the target query hidden within the private query when constructing it... Therefore, the retrieval response ciphertext polynomial completes the selection of target data without exposing the query retrieval. At the same time, the perturbations introduced by the noise term are naturally preserved in the ciphertext structure to maintain the security of the protocol under the assumption of loop learning error.

[0044] In step S300, the server-side hash verification parameters include server-side binding hash parameters and server-side verification challenge parameters. The formula for generating the server-side binding hash parameters is as follows:

[0045] in, Bind hash parameters to the server. For hash calculation, For the knowledge base commitment, To retrieve the ciphertext polynomial of the response, This serves as the version identifier for the server-side knowledge base.

[0046] The formula for generating server-side verification challenge parameters is expressed as follows:

[0047] in, To verify the challenge parameters on the server side, For hash calculation, For private commitments, For the knowledge base commitment, To retrieve the ciphertext polynomial of the response, This serves as the version identifier for the server-side knowledge base.

[0048] Specifically, the server-side binding hash parameter is used to bind the ciphertext polynomial of the retrieval response to the knowledge base commitment, so as to ensure that the ciphertext polynomial of the retrieval response is the content obtained by performing a ciphertext domain retrieval on the server-side knowledge base.

[0049] Specifically, the server-side verification challenge parameter is used to bind the ciphertext polynomial of the retrieval response, the private commitment, and the knowledge base commitment, so as to ensure that the server can only retrieve the correct ciphertext polynomial of the retrieval response from the unpoisoned knowledge base for this query.

[0050] Furthermore, the formula for generating the verification proof based on the hash verification parameters is expressed as follows:

[0051] in, To verify and prove, To prove the generation algorithm, For private commitments, For the knowledge base commitment, This is a commitment from the server regarding the results generated in response to the search query. To retrieve the encrypted message, These are the verification challenge parameters generated based on the hash verification parameters.

[0052] Specifically, the hash verification parameters include binding hash parameters. and verification challenge parameters Among them, binding hash parameters Used for verifying the consistency of response binding between the client and server, and verifying challenge parameters. Used to generate and verify proofs The client receives the binding hash parameter returned by the server. and verification proof Then, the binding hash parameters are recalculated based on the same input information as the server. and verification challenge parameters When the recalculated binding hash parameter If the result matches the result returned by the server, then the recalculated verification challenge parameters are used. Verification proof Perform the verification.

[0053] Specifically, the verification proof is used to prove that the server performed the retrieval calculation based on the established knowledge base state and according to the private query initiated by the client.

[0054] In step S400, the client parses the server-side knowledge base version identifier in the response message. If the target knowledge base version identifier does not match the server-side knowledge base version identifier, the client refuses to respond to the response message.

[0055] Specifically, by verifying the server-side knowledge base version identifier in the response message, search results generated based on expired or rolled-back database states are prevented from entering the subsequent processing stage.

[0056] Furthermore, in the client, a client hash verification parameter is generated based on the knowledge base commitment, private commitment, target knowledge base version identifier, and retrieval response ciphertext polynomial. The verification passes when the client hash verification parameter is the same as the server hash verification parameter.

[0057] Specifically, the client-side hash verification parameters include client-side binding hash parameters and client-side verification challenge parameters. The calculation formula for the client-side binding hash parameters is the same as that for the server-side binding hash parameters, and the calculation formula for the client-side verification challenge parameters is the same as that for the server-side verification challenge parameters. The formulas are expressed as follows:

[0058] in, Bind hash parameters to the client. To validate the challenge parameters for the client, For hash calculation, For the knowledge base commitment, To retrieve the ciphertext polynomial of the response, For server-side knowledge base version identification, For private commitments.

[0059] Specifically, the client, based on the client-bound hash parameters and client-verification challenge parameters, calls the corresponding verification interface to verify the verification proof π generated by the server. The verification interface verifies whether the verification proof π returned by the server is valid based on the knowledge base commitment, private commitment, result commitment, query ciphertext, retrieval response ciphertext polynomial, server-side knowledge base version identifier, and client-side verification challenge parameters. This verifies whether the aggregation relationship between the result commitment, knowledge base commitment, and private commitment is valid, and whether the retrieval response ciphertext polynomial was obtained by the server performing ciphertext domain retrieval calculation on the commitment knowledge base based on the private query. The client only accepts the retrieval result if the verification result shows that the retrieval response simultaneously satisfies the consistency with the commitment database state, the consistency with the private query parameters initiated by the client, and that the retrieval calculation process has not been tampered with or forged by the server.

[0060] In other words, if the verification fails, the client will not respond to the response message.

[0061] In step S400, the formula for performing the decryption operation on the ciphertext polynomial of the retrieved response message using the private key is expressed as follows:

[0062] in, For the search results, To retrieve the ciphertext polynomial of the response, For private keys, This is for decryption operations.

[0063] Specifically, for the successfully decrypted search results, the client inputs them as external knowledge evidence into the generative model to participate in the subsequent reasoning and generation process. Since the search results have passed the database state consistency check and verifiable consistency check before decryption, the propagation path of knowledge base poisoning or malicious search responses can be effectively blocked before the generation stage, ensuring that the generative model performs reasoning only based on credible search evidence.

[0064] In the current embodiment, to verify the effectiveness of the present invention in scenarios involving untrusted retrieval servers and knowledge base poisoning attacks, a systematic experimental evaluation of the present invention was conducted by combining multiple datasets, retrieval strategies, and generation models. The experimental results verified the technical effects brought about by each inventive point in terms of security, robustness, and performance overhead. To investigate the propagation behavior of knowledge base poisoning attacks during the retrieval and generation stages, the success rate of attacks under different Top-k retrieval strategies was analyzed. The experimental results are as follows: Figure 2 As shown. Figure 2The horizontal axis represents the randomly selected Top-k values, set to 1, 3, 5, and 10 respectively, and the vertical axis represents the attack success rate. The blue curve represents the attack success rate in the retrieval stage, and the orange curve represents the attack success rate in the generation stage. Figure 2 The results show that under the random Top-k retrieval setting, the attack sample can still be hit with a high probability during the retrieval stage, while the traditional retrieval-enhanced generation system will directly input the retrieval results into the generation model without a verification mechanism. In contrast, the proposed scheme significantly reduces the attack success rate during the generation stage, indicating that even if the attack content is hit by the retrieval, it can be effectively blocked before entering the generation stage, thereby cutting off the path of poisoning attack propagation from retrieval to generation.

[0065] To verify the universality of the proposed solution under different generative models and different task datasets, comparative experiments were conducted on the HotpotQA and Natural Questions datasets using various mainstream large language models. The experimental results are as follows: Figure 3 As shown. Figure 3 The top figure shows the experimental results on the Natural Questions dataset, and the bottom figure shows the experimental results on the HotpotQA dataset. The horizontal axis represents different generation models, and the vertical axis represents the attack success rate. The blue curve represents the semantic-level attack success rate, the orange curve represents the generation-stage attack success rate, and the green curve represents the attack success rate after incorporating the defense proposed in this invention. Figure 3 It can be seen that, without the introduction of a defense mechanism, different models have varying degrees of attack success rates at both the semantic and generation levels; however, after introducing the verifiable private information retrieval mechanism described in this invention, the attack success rate of each model at the generation stage is close to zero, indicating that the solution of this invention does not depend on a specific model structure or parameter configuration and can stably exert a defense effect in different model environments.

[0066] To evaluate the robustness of this invention under different poisoning intensities, the rejection rate and attack success rate were tested under different poisoning ratios. The experimental results are as follows: Figure 4 As shown. Figure 4 The horizontal axis represents the poisoning ratio, and the vertical axis represents the percentage. The blue curve represents the abnormal response rejection rate, the orange curve represents the attack success rate during the generation phase, and the green curve represents the attack success rate during the retrieval phase. The attack success rates during the retrieval and generation phases are consistently close to 0 (they appear almost overlapping in the image, therefore only the green curve is displayed). Figure 4As can be seen, with the continuous increase in the proportion of poisoning, the solution of the present invention can always maintain a high abnormal response rejection rate, while the attack success rate in the retrieval stage and the generation stage remains at an extremely low level. This shows that the present invention can stably identify and reject untrusted retrieval results under high-intensity poisoning attack conditions, verifying its robustness and reliability in malicious environments.

[0067] The present invention was evaluated from a system performance perspective. Analysis of the latency at each stage reveals that the main additional overhead after introducing the verifiable mechanism is the computational cost related to proof generation and verification. This overhead is relatively small compared to the overall time consumption of the private information retrieval and large language model inference stages, and it does not change the order of increase in server-side retrieval computational complexity. Experimental results are as follows... Figure 5 As shown. Figure 5 The table presents the average latency under different system settings, where the horizontal axis represents whether the verification mechanism is enabled and whether the large language model is called, and the vertical axis represents the average latency. Different colors correspond to the time consumed in each processing stage of the system. Figure 5 It is known that the system latency is mainly concentrated in the private information retrieval stage and the large language model inference stage, while the additional overhead of proof generation and verification after introducing the verifiable mechanism is relatively small overall. This invention provides verifiable retrieval results while maintaining overall system performance within an acceptable range, making it suitable for high-frequency query and low-latency application scenarios in retrieval enhancement generation systems.

[0068] Example 2 This embodiment also provides an electronic device, see reference. Figure 6 It includes a memory 404 and a processor 402, the memory 404 storing a computer program and the processor 402 being configured to run the computer program to perform the steps in any of the above method embodiments.

[0069] Specifically, the processor 402 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0070] Memory 404 may include a mass storage device for data or instructions. For example, and not limitingly, memory 404 may include a hard disk drive (HDD), a floppy disk drive, a solid-state drive (SSD), flash memory, an optical disk drive, a magneto-optical disk drive, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 404 may include removable or non-removable (or fixed) media. Where appropriate, memory 404 may be internal or external to a data processing device. In a particular embodiment, memory 404 is non-volatile memory. In a particular embodiment, memory 404 includes read-only memory (ROM) and random access memory (RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable read-only memory (PROM), an erasable read-only memory (EPROM), an electrically erasable read-only memory (EEPROM), an electrically alterable read-only memory (EAROM), or flash memory, or a combination of two or more of these. Where appropriate, the RAM can be Static Random-Access Memory (SRAM) or Dynamic Random-Access Memory (DRAM). DRAM can be Fast Page Mode Dynamic Random-Access Memory (FPMDRAM), Extended Data Out Dynamic Random-Access Memory (EDODRAM), Synchronous Dynamic Random-Access Memory (SDRAM), etc.

[0071] The memory 404 can be used to store or cache various data files that need to be processed and / or communicated, as well as possible computer program instructions executed by the processor 402.

[0072] The processor 402 reads and executes computer program instructions stored in the memory 404 to implement any of the verifiable private information retrieval methods for RAG knowledge base poisoning attacks in the above embodiments.

[0073] Optionally, the electronic device may further include a transmission device 406 and an input / output device 408, wherein the transmission device 406 is connected to the processor 402, and the input / output device 408 is connected to the processor 402.

[0074] The transmission device 406 can be used to receive or send data via a network. Specific examples of the network described above may include wired or wireless networks provided by the communication provider of the electronic device. In one example, the transmission device includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 406 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0075] Input / output device 408 is used to input or output information. In this embodiment, the input information may be a private query, etc., and the output information may be a response message, search results, etc.

[0076] Optionally, in this embodiment, the processor 402 can be configured to perform the following steps via a computer program: S100. The server maps each data fragment in the knowledge base to a polynomial form in a polynomial ring to obtain the server knowledge base. The server knowledge base generates a public knowledge base commitment and a server knowledge base version identifier for the server knowledge base. The knowledge base commitment is used to verify the immutability of the data in the corresponding server knowledge base. S200: The client generates a query polynomial and a private key based on the polynomial ring, generates a private commitment based on the private key, and constructs a private query with the query polynomial, private query parameters generated based on the private key, private commitment, target query, and target knowledge base version identifier and sends it to the server. The private commitment corresponds to the private key. S300: The server performs encrypted domain retrieval calculation on the polynomial ring based on the private query to generate the encrypted polynomial of the retrieval response. Based on the private commitment, knowledge base commitment, server knowledge base version identifier and the encrypted polynomial of the retrieval response, the server hash verification parameters are generated. Based on the server hash verification parameters, the verification proof is generated. The server hash verification parameters, the verification proof, the encrypted polynomial of the retrieval response and the server knowledge base version identifier are encapsulated into a response message and returned to the client. S400: The client verifies the response message based on the knowledge base commitment, private commitment, and target knowledge base version identifier. Once the verification is successful, the client uses the private key to perform a decryption operation on the ciphertext polynomial of the retrieval response in the response message to obtain the retrieval result.

[0077] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0078] Generally, various embodiments can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects of the invention can be implemented in hardware, while others can be implemented by firmware or software executed by a controller, microprocessor, or other computing device, but the invention is not limited thereto. Although various aspects of the invention may be shown and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that, by way of non-limiting example, these blocks, apparatuses, systems, techniques, or methods described herein can be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0079] Embodiments of the present invention can be implemented by computer software, which may be executable by a data processor of a mobile device, such as a processor entity, or by hardware, or by a combination of software and hardware. Computer software or programs (also referred to as program products) including software routines, applets, and / or macros can be stored in any device-readable data storage medium, and they include program instructions for performing specific tasks. The computer program product may include one or more computer-executable components configured to perform the embodiments when the program is run. The one or more computer-executable components may be at least one piece of software code or a portion thereof. Additionally, it should be noted in this respect that, as Figure 5 Any box in the logical flow can represent a program step, or interconnected logic circuits, boxes and functions, or a combination of program steps and logic circuits, boxes and functions. Software can be stored on physical media such as memory chips or blocks of storage implemented within a processor, magnetic media such as hard disks or floppy disks, and optical media such as DVDs and their data variants, CDs, etc. The physical medium is a non-transient medium.

[0080] Those skilled in the art should understand that the technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0081] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A verifiable private information retrieval method for RAG knowledge base poisoning attacks, characterized in that, Includes the following steps: S100. The server maps each data fragment in the knowledge base to a polynomial form in a polynomial ring to obtain the server knowledge base. The server knowledge base generates a public knowledge base commitment and a server knowledge base version identifier for the server knowledge base. The knowledge base commitment is used to verify the immutability of the data in the corresponding server knowledge base. S200: The client generates a query polynomial and a private key based on the polynomial ring, generates a private commitment based on the private key, and constructs a private query with the query polynomial, private query parameters generated based on the private key, private commitment, target query, and target knowledge base version identifier and sends it to the server. The private commitment corresponds to the private key. S300: The server performs encrypted domain retrieval calculation on the polynomial ring based on the private query to generate the encrypted polynomial of the retrieval response. Based on the private commitment, knowledge base commitment, server knowledge base version identifier and the encrypted polynomial of the retrieval response, the server hash verification parameters are generated. Based on the server hash verification parameters, the verification proof is generated. The server hash verification parameters, the verification proof, the encrypted polynomial of the retrieval response and the server knowledge base version identifier are encapsulated into a response message and returned to the client. S400: The client verifies the response message based on the knowledge base commitment, private commitment, and target knowledge base version identifier. Once the verification is successful, the client uses the private key to perform a decryption operation on the ciphertext polynomial of the retrieval response in the response message to obtain the retrieval result.

2. The verifiable private information retrieval method for RAG knowledge base poisoning attacks according to claim 1, characterized in that, In step S100, when the data content of the server-side knowledge base is legally updated, the server generates and publishes a new knowledge base commitment and a server-side knowledge base version identifier based on the updated server-side knowledge base.

3. The verifiable private information retrieval method for RAG knowledge base poisoning attacks according to claim 1, characterized in that, In step S200, the query polynomial is the query carrier of the current query, and the query polynomial is randomly generated with each query. The private key is privately stored by the client, and the target query is the data index information in the target knowledge base.

4. The verifiable private information retrieval method for RAG knowledge base poisoning attacks according to claim 1, characterized in that, In step S200, a private polynomial is constructed based on the query polynomial, the private key, the noise polynomial, and the target query. The formula is expressed as: in, For private polynomials, To query a polynomial, For private keys, It is a noise polynomial. Query for target; A private query is constructed based on the private polynomial, the query polynomial, the private commitment, and the target knowledge base version identifier. The formula is expressed as: in, For private queries, To query a polynomial, For private polynomials, For private commitments, This is the version identifier for the target knowledge base.

5. A verifiable private information retrieval method for RAG knowledge base poisoning attacks according to claim 1, characterized in that, In step S300, the server parses the target knowledge base version identifier in the private query. If the target knowledge base version identifier is inconsistent with the server knowledge base version identifier, the private query is rejected. In step S400, the client parses the server knowledge base version identifier in the response message. If the target knowledge base version identifier is inconsistent with the server knowledge base version identifier, the response message is rejected.

6. The verifiable private information retrieval method for RAG knowledge base poisoning attacks according to claim 1, characterized in that, In step 300, the formula for the server to perform ciphertext field retrieval calculation on the polynomial ring is expressed as follows: in, To retrieve the ciphertext polynomial of the response, To query a polynomial, For the polynomial representation of the server-side knowledge base, For the auxiliary polynomial carried in the private query, obtain based on the private query. and .

7. A verifiable private information retrieval method for RAG knowledge base poisoning attacks according to claim 1, characterized in that, In step S300, the server-side hash verification parameters include server-side binding hash parameters and server-side verification challenge parameters. The formula for generating the server-side binding hash parameters is as follows: in, Bind hash parameters to the server. For hash calculation, For the knowledge base commitment, To retrieve the ciphertext polynomial of the response, For server-side knowledge base version identification; The formula for generating server-side verification challenge parameters is expressed as follows: in, To verify the challenge parameters on the server side, For hash calculation, For private commitments, For the knowledge base commitment, To retrieve the ciphertext polynomial of the response, This serves as the version identifier for the server-side knowledge base.

8. A verifiable private information retrieval method for RAG knowledge base poisoning attacks according to claim 1, characterized in that, In the client, a client hash verification parameter is generated based on the knowledge base commitment, private commitment, target knowledge base version identifier, and retrieval response ciphertext polynomial. The verification passes when the client hash verification parameter is the same as the server hash verification parameter.

9. A verifiable private information retrieval method for RAG knowledge base poisoning attacks according to claim 1, characterized in that, In step S400, the formula for performing the decryption operation on the ciphertext polynomial of the retrieved response message using the private key is expressed as follows: in, For the search results, To retrieve the ciphertext polynomial of the response, For private keys, This is for decryption operations.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to execute a verifiable private information retrieval method for RAG knowledge base poisoning attacks as described in any one of claims 1-9.

Images