PoisonedRAG
sleeepeer/PoisonedRAG加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
试想这样一个场景：你在企业内部部署了一个基于RAG（检索增强生成）的智能问答系统，员工们每天向它咨询技术文档、操作手册、内部规范。它给出的回答看起来专业、流畅、有理有据——但你不知道的是，攻击者早已在你们的文档数据库中埋入了精心构造的"毒药文本"。当员工提出特定问题时，系统会绕过正常检索逻辑，优先返回这些被篡改的内容，导致AI给出完全错误甚至恶意的操作指令。这就是PoisonedRAG所揭示的安全威胁。
PoisonedRAG 是来自清华大学&北京大学的学术研究团队在 USENIX Security 2025 发表的开源工具，首次系统性地揭示了针对检索增强生成（RAG）系统的知识库投毒攻击。它不仅仅是概念验证（POC），而是一套完整的攻击框架，涵盖了从投毒文本生成到攻击效果评估的全流程。
RAG（Retrieval-Augmented Generation）是当前大模型落地的主流范式——用私有知识库补充通用大模型的知识不足，让AI能够回答"你自己的数据"相关的问题。企业用它搭建客服机器人、代码助手、合同审查工具，开发者用它让本地模型理解最新文档。但问题在于：RAG系统的检索环节天然存在被攻击面。
传统的对抗攻击研究集中在两个方向：一是Prompt注入（直接在提示词中埋指令），二是训练数据投毒（在模型微调阶段混入恶意数据）。这两者已被广泛研究，有成熟的防御方案。但知识库层面的攻击——即在不修改模型权重、不污染提示词的情况下，通过篡改检索数据库本身来操控最终输出——此前几乎无人系统研究。
PoisonedRAG 填补了这一空白。它证明：攻击者只需向目标 RAG 系统的文档库中注入少量精心设计的对抗文本（每条约15-100词），无需任何模型访问权限，即可实现对特定问题回答的定向操控——让正确答案替换为错误答案，或者让模型按照攻击者意图行事。
攻击流程分两步：
第一步：对抗文本生成（Adversarial Corpus Generation）
攻击者首先获取目标 RAG 系统使用的检索模型（如 Contriever）。给定一个查询（Query）和期望的操控输出（Target Answer），PoisonedRAG 使用两种方法生成"投毒文本"：
黑盒方法（LM_targeted）：利用大语言模型（如 GPT-4、PaLM2）自动生成投毒文本。攻击者提供"原始问题 + 正确答案"，LLM 自动生成"包含错误答案且语义上与查询高度相关"的段落。这种方法不需要访问检索模型，适合对商业 RAG 系统发起攻击。
白盒方法（HotFlip）：基于梯度优化的方法，计算检索模型对文本嵌入的梯度，反向找到能最大化检索相似度的词级扰动。这是一种更精细的控制方法，生成的投毒文本在语义和语法上都更接近正常文本。
第二步：数据库植入与攻击触发
生成的投毒文本被植入目标知识库。当普通用户提出特定问题时，由于这些投毒文本与查询的语义相似度极高（检索模型被"欺骗"了），检索组件优先返回这些被污染的文本。大模型在上下文窗口中看到这些错误内容后，按照攻击者预设的逻辑生成错误或恶意回答。
值得注意的是，这种攻击具有高度定向性：投毒文本只在特定查询被触发时生效，对其他不相关的问题完全不产生影响，因此很难被传统的内容审核或数据校验方法发现。
PoisonedRAG 的代码组织清晰，分为四个核心模块：
Attacker 类和 HotFlip 梯度攻击算法。get_attack() 方法根据配置的投毒策略生成对抗文本，hotflip_attack() 实现了基于梯度的词级扰动优化。根目录中的 run.py 是实验主入口，通过修改 test_params 字典配置数据集、模型和攻击参数后执行；main.py 是真正的执行主循环，负责参数解析、BEIR 数据集加载和攻击结果记录；gen_adv.py 是独立的投毒文本生成脚本，支持 4 种不同的提示词模板。
PoisonedRAG 使用 BEIR 检索基准的三个数据集进行评估：
评测指标包括：
实验结果显示，在 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)