6 月 9 日，Polytechnic of Porto、THALES SIX GTS 等机构的研究者提交了一篇 RAG 安全论文，题目叫 《Influence Factors on RAG Poisoning》。https://arxiv.org/pdf/2606.12469
这篇文章没有提出一个特别炫的新攻击方法，而是做了一件更贴近工程落地的事：把 RAG 投毒拆成多个系统变量，系统分析到底哪些配置会放大投毒风险。论文构建了 432 组 RAG 配置，覆盖数据集、检索器、top-k、数据库组成、chunk 参数和生成模型，并同时观察检索阶段与生成阶段的安全指标。RAG 系统的基本逻辑，是让大模型在回答问题前，先从外部知识库中检索相关材料，再把这些材料作为上下文输入给模型。这套架构解决了大模型知识过期、领域知识不足、幻觉等问题。但它也引入了一个新的安全依赖：模型回答的可靠性，开始取决于外部知识源是否可信。 一旦外部知识库被污染，模型可能会把错误材料当作证据，生成看起来有引用、有依据、但实际被攻击者操控的答案。论文也明确指出，RAG 的生成结果会直接受到检索知识完整性的影响。很多 RAG 投毒研究关注的是“能不能攻击成功”。这篇文章换了一个角度：同样是投毒，为什么有些 RAG 配置更容易中招，有些配置相对稳健？这个问题很重要。企业内部 RAG 系统往往不是单一组件，而是多个知识库、多个检索策略、多个切块参数、多个模型共同组成。攻击能否成功，通常不是由某一个毒文档决定的，而是由整个 RAG 管线的配置共同决定。实验设计：432 组配置，拆开看 RAG 的脆弱性作者采用的是全因子实验设计，把多个 RAG 配置变量组合起来，最终得到 432 组实验配置。这些变量包括：数据集、检索器类型、top-k、数据库数量、被投毒数据库数量、chunk size、chunk overlap 和生成模型。具体来说，实验用了两个数据集：HotpotQA 和 MS-MARCO。前者偏多跳推理，需要模型整合多个文档；后者偏开放域问答，更接近从大量文本中找出高相关 passage。为了降低实验开销，作者没有使用完整数据集，而是构建了 100 对语义相似的问题子集。一类是 BM25，代表传统稀疏词法检索，主要依赖词频、逆文档频率等统计特征。一类是 Dense BGE，代表稠密向量检索，通过 embedding 相似度匹配查询和文档。还有一类是 Graph-based retriever，也就是图检索，它不只看相似度，还利用文档之间的结构关系进行检索。top-k 设置为 2、3、5，用来观察召回文档数量对投毒暴露面的影响。知识库配置则分成三种：一个数据库且被投毒、两个数据库但只有一个被投毒、两个数据库都被投毒。这个设计很贴近企业真实环境，因为企业 RAG 往往接入多个知识源，污染可能只发生在一个源，也可能因为同步、复制、二次加工扩散到多个源。投毒方法：不是随便塞脏数据，而是制造“高相关错误证据”论文中的投毒策略并不是随机插入错误文本，而是专门面向 RAG 检索机制构造毒文档。对每个问题，攻击流程会先确定一个错误目标答案。如果问题本身包含“A or B”这样的选项，就直接选择错误选项作为攻击目标；如果没有显式选项，就让语言模型生成多个看似合理的干扰答案，再过滤掉和正确答案重复或过于接近的候选项。随后，系统会生成一段中立、百科式的攻击文本。关键在于，这段文本开头会同时包含原始问题和错误主张，并重复问题中的关键词，以提升和用户查询之间的词面重合度，同时避免出现正确答案。这解释了为什么 BM25 在实验中更容易受到影响。BM25 依赖词法匹配，而攻击文本刻意强化了问题关键词和表面相关性。换句话说，攻击者并不是单纯“污染知识库”，而是在制造一种特别适合被检索器召回的错误证据。这也是 RAG 投毒的危险之处：毒文档不需要像传统提示注入那样写得很“恶意”，它可以写得非常正常、非常客观、非常像企业知识库里的普通说明文档。评价指标：先看毒文档有没有进上下文，再看模型有没有被带偏作者使用了三个指标：Poison@k、Poison Rank 和 Score Margin。Poison@k 关注 top-k 检索结果中是否包含毒文档；Poison Rank 关注毒文档在检索结果中的排名；Score Margin 关注最高分毒文档和最高分干净文档之间的相似度差距。作者观察模型最终会出现三种结果：拒答或表示不确定，对应 Abstention Rate；回答正确，对应 Correct Answer Rate；被毒内容影响并输出错误目标答案，对应 ASR。这个指标拆分很有价值。因为在真实系统里，很多风险不是直接表现为“模型已经答错”，而是表现为：- 模型这一次没有被带偏，但下一次换个问题、换个模型、换个 top-k 就可能出问题。
所以，企业做 RAG 安全评测时，不能只看最终答案是否错误，还要把检索阶段的毒文档暴露情况纳入评估。因素一：检索器最关键，BM25 最容易被关键词型毒文档诱导实验结果显示，检索器架构是影响 RAG 投毒暴露面的核心因素之一。在检索层指标中，Graph retriever 对 Poison@k 的负向影响最大，系数为 -0.170；Dense BGE 也能降低 Poison@k，系数为 -0.040。在 Score Margin 上，Dense BGE 和 Graph retriever 也明显降低了毒文档相对干净文档的竞争力，系数分别为 -0.402 和 -0.317。通俗讲，BM25 更容易把这类毒文档召回来，因为攻击文本专门堆叠了问题关键词。Dense BGE 和 Graph 检索相对稳健，是因为它们不完全依赖词面重合，而会更多考虑语义相似度或文档结构关系。生成层也呈现类似趋势。Dense BGE 和 Graph retriever 能提高 Correct Answer Rate，并降低 ASR。表 2 中，Graph retriever 对 ASR 的影响系数为 -0.143，Dense BGE 为 -0.073。这给企业 RAG 一个很直接的启示：检索器不是单纯的效果组件，也是安全组件。很多团队选检索器时，主要看准确率、召回率、延迟和成本。但在 RAG 安全场景下，还需要多加一组评估：不同检索器在投毒数据下的 Poison@k、Poison Rank、Score Margin 和 ASR。top-k 是 RAG 系统里非常常见的调参项。很多团队为了提高召回率，会把 top-k 调大，让模型看到更多材料。但论文结果提醒我们：召回更多文档，也意味着给毒文档更多进入上下文的机会。表 1 中，top-k 从 2 增加到 3 和 5，都会提高 Poison@k。其中 top-k=5 对 Poison@k 的系数为 0.092，top-k=3 为 0.042。作者也明确指出，检索深度增加会显著提高毒文档进入检索上下文的概率。这并不是说 top-k 越小越安全。top-k 太小也可能导致干净证据不足，模型只能看到单一片段，反而被某一条毒文档主导。关键问题在于，top-k 不能只按“多召回一点总没错”的思路去调。在低风险场景中，top-k 可以根据准确率和成本调优；在高风险场景中，top-k 应该结合 reranker、来源可信度、文档去重、冲突检测一起使用；当检索结果中出现相互矛盾的证据时，不应该简单把所有材料塞给模型，而应该先做证据分层和风险过滤。换句话说，RAG 的上下文窗口不是“材料越多越好”，而是“证据越可信越好”。因素三：任务类型会改变投毒风险，HotpotQA 更脆弱论文发现，MS-MARCO 相比 HotpotQA 有更低的 Poison@k 和 Score Margin。也就是说，在这组实验里，MS-MARCO 上的毒文档更不容易被召回，或者即使被召回，也不一定能压过干净文档。HotpotQA 是多跳推理任务，需要模型整合多个文档。如果毒文档伪装成推理链条中的一个关键桥接证据，就可能影响最终答案。MS-MARCO 更偏开放域 passage retrieval，系统往往是在大量文本里找高相关段落，干净证据的竞争力可能更强。简单 FAQ、制度查询、产品说明问答，风险当然存在；但更需要警惕的是那些需要多文档综合的任务，比如：这些任务天然需要模型跨多个知识源综合判断。只要其中一环被污染，错误证据就可能进入推理链条，最终影响结论。因素四：多知识库不是天然安全，关键看毒内容是否扩散这篇论文比较有价值的一点，是把数据库组成纳入实验。作者设置了三种知识库形态：1 Total | 1 Poisoned，也就是一个数据库且被投毒；2 Databases | 1 Poisoned，也就是两个数据库但只有一个被投毒；2 Databases | 2 Poisoned，也就是两个数据库都被投毒。当系统有两个数据库，但只有一个被投毒时，额外的干净数据库会提供竞争性证据，把毒文档排名往后推，并提高正确回答率。相反，当两个数据库都包含毒内容时，毒文档的竞争力和攻击成功率都会上升。论文在结果部分指出，“2 Databases | 2 Poisoned” 会产生最高的 Score Margin，而 “2 Databases | 1 Poisoned” 会让 Poison Rank 更高，也就是毒文档排名更靠后。如果多个知识源彼此独立，而且大部分是干净的，多源信息可以稀释攻击影响。但如果同一条错误信息被同步到多个知识库，情况就完全不同了。模型看到的不是“一个来源说错了”，而是“多个来源都在支持同一个错误结论”。这会显著提高错误证据的可信外观。企业内部很容易出现这种情况：一份错误文档先进入 Confluence，然后被同步到客服知识库，再被整理进 FAQ，又被工单系统引用。最后 RAG 检索时，多个来源都召回了同一类错误信息。表面上看，这是多源验证；实际上，这是污染内容的复制扩散。所以，多知识库 RAG 的安全治理重点，不只是接入更多源，而是要做：RAG 投毒不只发生在检索阶段。毒文档进入上下文之后，最终还要看模型怎么处理这些证据。论文比较了两个生成模型：llama-4-scout-17b-16e-instruct 和 openai-gpt-oss-120b。结果显示，openai-gpt-oss-120b 的 Abstention Rate 更低，也就是更不愿意拒答或表示不确定；同时，它的 ASR 更高。表 2 中，openai-gpt-oss-120b 对 ASR 的影响系数为 0.169，是 ASR 中最大的正向影响因素。这说明一个很现实的问题：模型的“有问必答”倾向，本身可能放大 RAG 投毒风险。在正常场景下，一个模型如果很愿意根据上下文给出明确答案，会让用户感觉更流畅、更有帮助。但在投毒场景下，这种行为可能变成风险。只要错误证据进入上下文，模型就更可能顺着错误证据继续生成。相反，更谨慎的模型可能用户体验稍弱，因为它更容易拒答、更容易说“不确定”。但在高风险业务里，这种保守性反而是安全能力的一部分。当多个来源重复同一错误说法时，模型会不会误以为这是事实共识。RAG 系统里的“忠于上下文”，并不总是安全特性。上下文可信时，它是优势；上下文被污染时，它可能变成攻击入口。因素六：chunk size 和 overlap 在这组实验中影响较小作者测试了两种 chunk size：512 和 768 tokens；两种 chunk overlap：64 和 100 tokens。结果显示，在这几个配置点上，chunk size 和 overlap 对 Poison@k、Poison Rank、Score Margin、Abstention Rate、Correct Answer Rate、ASR 都没有表现出稳定且显著的影响。论文因此认为，在当前实验范围内，chunking 参数相比检索器、数据集、top-k、数据库组成和生成模型，影响较小。它并不等于“chunking 对 RAG 安全不重要”。它只能说明，在 512/768 tokens 和 64/100 overlap 这几个具体设置下，没有观察到明显差异。真实系统里，chunking 仍然可能影响投毒效果。比如：- chunk 太小，错误断言可能被切成多个孤立片段；
- chunk overlap 太大，毒内容可能被重复索引；
- chunk 太大，毒内容可能和大量正常内容混在一起，提高可信感；
- 切块规则如果不保留标题、来源、时间、权限等元数据，也会削弱后续风险判断。
所以，chunking 不应该被过度神化，也不能完全忽略。更准确的说法是：在这篇论文的实验条件下，chunk 参数不是最主要的影响因素。把六个因素合起来看，这篇论文真正想说的是：RAG 投毒不是一个孤立漏洞。它不是单纯的“知识库里有没有毒文档”，它也不是单纯的“检索器能不能识别相关内容”，它更不是单纯靠输出审核就能解决的问题。论文结论也强调，RAG 投毒的有效性不是由单一组件决定的，而是由完整 RAG pipeline 的综合行为决定；在检索层，检索器架构、数据集和 top-k 是主要因素；在生成层，检索质量和模型选择都会显著影响输出鲁棒性。这对企业安全建设的启发很直接：如果我们只在最后一层做输出审核，很可能已经太晚了。因为错误证据已经进入上下文，模型已经围绕它生成了答案。此时再判断答案是否错误，难度远高于在检索阶段就识别可疑证据。更合理的 RAG 安全架构，应该把防线前移到检索和上下文构造阶段。结合这篇论文，可以把企业 RAG 安全治理拆成六个动作。第一，建立 RAG 投毒评测集。不要只测正常问答准确率，要专门构造带有错误证据、冲突证据、重复污染证据的测试集。指标也不要只看最终答案，要同时看 Poison@k、Poison Rank、Score Margin 和 ASR。第二，把检索器纳入安全选型。BM25、Dense、Hybrid、Graph、Reranker 的比较，不能只看效果和延迟，还要看它们在投毒场景下是否更容易召回毒文档。第三，限制 top-k 的粗放扩张。top-k 不是越大越好。对高风险业务，top-k 应该和 reranker、来源可信度、证据冲突检测联动，而不是简单增加上下文数量。第四，对多知识库做来源治理。多个知识源之间要识别复制关系，避免同一条错误信息在多个库中重复出现后，被模型误认为“多源一致”。第五，评估模型的证据服从风险。模型越愿意根据上下文直接回答，在投毒上下文中越可能被带偏。企业需要测试模型面对错误上下文、冲突上下文、不充分上下文时的行为。第六，把防御放在生成前。论文也指出，这些结果支持在生成前对可疑检索片段进行过滤或降权。也就是说，安全能力不能只做输出审核，还要进入 retrieval-time filtering、reranking、context construction 这些环节。这篇论文的价值在于系统分析了 RAG 投毒的影响因素，但它也有几个明显限制。首先，实验只使用了 100 对 curated question pairs，而不是完整数据集。作者也说明，这样做是为了降低计算开销并便于跨数据集比较，不是为了代表完整分布。其次，攻击策略是 query-aware 的。毒文档围绕具体问题构造，并刻意提高词面重合度。这有助于分析不同检索器对关键词型毒文档的敏感性，但和真实世界中攻击者不知道具体查询的情况还有差距。第三，论文没有覆盖更多真实企业常见组件，比如 hybrid retrieval、reranker、source-aware ranking、trust score、权限过滤、文档版本治理、跨源冲突检测等。作者在 future work 中也提到，后续需要扩展到更多数据集、更多模型、更隐蔽和自适应的攻击策略，以及 re-ranking、hybrid retrieval、更复杂 chunking、更大规模数据库配置等方向。所以，这篇论文不能简单理解为“Graph 一定安全，BM25 一定不安全”或者“chunking 不重要”。更准确的理解是：RAG 投毒风险需要在具体任务、具体检索器、具体知识源和具体模型组合下评估。RAG 系统让大模型接入了外部知识，也让外部知识变成了新的攻击面。这篇论文最有价值的地方，是把 RAG 投毒从单点攻击拉回到工程系统视角。毒文档能否生效，不只取决于攻击者写得有多像真文档，还取决于检索器怎么排、top-k 怎么设、知识库怎么组织、模型是否盲从上下文。对企业来说，RAG 安全不能停留在“知识库别进脏数据”这一级。更关键的是建立一套完整的证据治理机制：当多个来源重复同一说法时，系统如何判断这是独立佐证，还是污染扩散。RAG 的风险，本质上是模型开始相信外部世界之后产生的风险。而 RAG 安全的核心，就是控制模型看见什么、引用什么、相信什么。
-- end --
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
