PoisonedRAG

当RAG知识库遭遇"投毒"攻击：PoisonedRAG深度解析

攻击场景：你的AI助手正在被悄悄误导

试想这样一个场景：你在企业内部部署了一个基于RAG（检索增强生成）的智能问答系统，员工们每天向它咨询技术文档、操作手册、内部规范。它给出的回答看起来专业、流畅、有理有据——但你不知道的是，攻击者早已在你们的文档数据库中埋入了精心构造的"毒药文本"。当员工提出特定问题时，系统会绕过正常检索逻辑，优先返回这些被篡改的内容，导致AI给出完全错误甚至恶意的操作指令。这就是PoisonedRAG所揭示的安全威胁。

PoisonedRAG 是来自清华大学&北京大学的学术研究团队在 USENIX Security 2025 发表的开源工具，首次系统性地揭示了针对检索增强生成（RAG）系统的知识库投毒攻击。它不仅仅是概念验证（POC），而是一套完整的攻击框架，涵盖了从投毒文本生成到攻击效果评估的全流程。

研究背景：RAG安全为何被忽视？

RAG（Retrieval-Augmented Generation）是当前大模型落地的主流范式——用私有知识库补充通用大模型的知识不足，让AI能够回答"你自己的数据"相关的问题。企业用它搭建客服机器人、代码助手、合同审查工具，开发者用它让本地模型理解最新文档。但问题在于：RAG系统的检索环节天然存在被攻击面。

传统的对抗攻击研究集中在两个方向：一是Prompt注入（直接在提示词中埋指令），二是训练数据投毒（在模型微调阶段混入恶意数据）。这两者已被广泛研究，有成熟的防御方案。但知识库层面的攻击——即在不修改模型权重、不污染提示词的情况下，通过篡改检索数据库本身来操控最终输出——此前几乎无人系统研究。

PoisonedRAG 填补了这一空白。它证明：攻击者只需向目标 RAG 系统的文档库中注入少量精心设计的对抗文本（每条约15-100词），无需任何模型访问权限，即可实现对特定问题回答的定向操控——让正确答案替换为错误答案，或者让模型按照攻击者意图行事。

核心原理：如何给RAG"下毒"？

攻击流程分两步：

第一步：对抗文本生成（Adversarial Corpus Generation）

攻击者首先获取目标 RAG 系统使用的检索模型（如 Contriever）。给定一个查询（Query）和期望的操控输出（Target Answer），PoisonedRAG 使用两种方法生成"投毒文本"：

• 黑盒方法（LM_targeted）：利用大语言模型（如 GPT-4、PaLM2）自动生成投毒文本。攻击者提供"原始问题 + 正确答案"，LLM 自动生成"包含错误答案且语义上与查询高度相关"的段落。这种方法不需要访问检索模型，适合对商业 RAG 系统发起攻击。

• 白盒方法（HotFlip）：基于梯度优化的方法，计算检索模型对文本嵌入的梯度，反向找到能最大化检索相似度的词级扰动。这是一种更精细的控制方法，生成的投毒文本在语义和语法上都更接近正常文本。

第二步：数据库植入与攻击触发

生成的投毒文本被植入目标知识库。当普通用户提出特定问题时，由于这些投毒文本与查询的语义相似度极高（检索模型被"欺骗"了），检索组件优先返回这些被污染的文本。大模型在上下文窗口中看到这些错误内容后，按照攻击者预设的逻辑生成错误或恶意回答。

值得注意的是，这种攻击具有高度定向性：投毒文本只在特定查询被触发时生效，对其他不相关的问题完全不产生影响，因此很难被传统的内容审核或数据校验方法发现。

技术架构：四层模块设计

PoisonedRAG 的代码组织清晰，分为四个核心模块：

• src/attack.py：攻击引擎核心，实现了 Attacker 类和 HotFlip 梯度攻击算法。get_attack() 方法根据配置的投毒策略生成对抗文本，hotflip_attack() 实现了基于梯度的词级扰动优化。
• src/models/：模型封装层，支持 GPT-3.5/4（OpenAI API）、PaLM2（Google API）、LLaMA-2（通过 HuggingFace Access Token）、Vicuna（通过 FastChat）等多种 LLM 的统一调用。
• src/contriever_src/：Contriever 检索模型的实现，基于 sentence-transformers，用于对检索结果进行语义编码和相似度计算。
• src/utils.py + src/prompts.py：数据加载和提示词管理工具，支持 BEIR 标准数据集的自动下载和解析。

根目录中的 run.py 是实验主入口，通过修改 test_params 字典配置数据集、模型和攻击参数后执行；main.py 是真正的执行主循环，负责参数解析、BEIR 数据集加载和攻击结果记录；gen_adv.py 是独立的投毒文本生成脚本，支持 4 种不同的提示词模板。

评估体系：三个数据集，多维度验证

PoisonedRAG 使用 BEIR 检索基准的三个数据集进行评估：

• NQ（Natural Questions）：Google 搜索的真实问答对，最权威的开放域问答数据集，包含 3,612 个测试查询
• HotpotQA：多跳推理问答，需要跨多个文档的信息整合，考验 RAG 系统的推理能力
• MS MARCO：微软的搜索引擎查询数据集，查询更短、更口语化

评测指标包括：

• ASR（Attack Success Rate）：投毒攻击成功率，即被操控回答占总回答的占比
• EM（Exact Match）：精确匹配率，评估攻击后正确率下降程度
• F1 Score：词语级重叠度，量化回答质量变化

实验结果显示，在 NQ 数据集上，PoisonedRAG 可以将目标问题的正确率从约 90% 降低到不足 30%，同时对非目标问题的回答质量几乎无影响，展现了攻击的高度精准性。

上手指南：研究级代码的使用门槛

PoisonedRAG 不是开箱即用的产品，而是为安全研究者提供的实验工具。使用门槛较高：

环境要求：Python 3.10 + Conda 环境；NVIDIA GPU（8GB+ VRAM，CUDA 11.7）；PyTorch 1.13.0（CUDA 11.7 版本）；fschat（FastChat，用于 Vicuna 等模型调用）；sentence-transformers（Contriever 检索模型）。

API Key 配置：支持 OpenAI GPT-3.5/4、Google PaLM2、Meta LLaMA-2（通过 HuggingFace Access Token）、UC Berkeley Vicuna。用户需在 model_configs/ 目录下手动编辑 JSON 配置文件填入自己的 Key。

运行方式：修改 run.py 中的 test_params 字典，设置数据集、检索模型、LLM 类型和攻击参数，然后执行 python run.py，实验日志和结果自动保存到 logs/ 和 results/ 目录。

争议与局限：攻击容易防御难

攻击条件：PoisonedRAG 假设攻击者能够向目标知识库写入数据。在实际场景中，这需要攻破文档管理系统的写权限，或者通过供应链污染（如第三方数据提供商）植入投毒文本。完全封闭的内部知识库不在攻击范围内。

防御难点：投毒文本与正常文本在语言风格上高度相似，现有的文本质量检测工具难以区分；攻击的定向性使得全局异常检测失效——只有在特定查询被触发后，才能观察到回答异常。

模型依赖：代码目前仅支持特定的检索模型（Contriever）和 LLM API，迁移到其他模型（如 BM25 + Claude）需要修改代码。

行业意义：从"模型安全"到"数据安全"的视角扩展

PoisonedRAG 最重要的贡献是将安全研究的注意力从模型层扩展到了数据层。在此之前，大多数 AI 安全讨论聚焦于"如何保护模型不被对抗样本欺骗"或"如何防止训练数据被污染"。PoisonedRAG 提醒我们：在 RAG 架构中，知识库本身就是攻击面——一个未被充分保护的文档库，可以成为颠覆整个 AI 系统的支点。

这项研究的发表也反映出 RAG 安全领域的研究空白：目前尚无成熟的商业工具能够有效检测和防御知识库投毒攻击。PoisonedRAG 为后续研究者提供了一个标准化的攻击基准（Benchmark），有助于推动防御技术的发展。

对于 AI 开发者和企业安全团队而言，这个项目提供了三点核心启示：首先，RAG 系统的数据来源必须纳入访问控制和数据溯源体系；其次，知识库的内容审核不能只依赖传统的垃圾文本检测，而需要专门针对对抗语义的检测机制；第三，在高安全场景中，检索结果的可信度评估应当与大模型输出结合，形成多层防御。

---

论文引用：Zou, Wei and Geng, Runpeng and Wang, Binghui and Jia, Jinyuan. "PoisonedRAG: Knowledge Corruption Attacks to Retrieval-Augmented Generation of Large Language Models." 34th USENIX Security Symposium (USENIX Security 25), 2025. (arXiv:2402.07867)