TRACE：通过追踪 token 影响力检测 RAG 语料库投毒

这是什么？

TRACE 是一种轻量级检测方法，用于应对针对检索增强生成（RAG）系统的语料库投毒攻击。它出自论文 《Tracing Target Answers in Poisoned Retrieval Corpora via Token Influence Attribution》（arXiv:2606.25721，cs.CR），发表于 2026 年 6 月下旬。其思路是防御性和取证性的：TRACE 不靠文档的文字表现来识别投毒文档，而是靠它对模型所产生回答的影响力来识别。

语料库投毒指的是这样一类攻击：攻击者将精心构造的文档塞入 RAG 系统所检索的知识库中，使得受害者提出特定问题时，被投毒的段落会被检索出来，并将生成的回答引向攻击者选定的输出。这是较为顽固的 RAG 威胁之一，因为恶意文本对人工审阅者和困惑度（perplexity）过滤器而言都可能显得完全正常。TRACE 加入了一条新兴的”归因型”防御路线——与 AttnTrace 以及 RAGForensics 等更早的溯源工作并列——它们把检测视为来源溯源问题，而非内容问题。

工作原理

核心观察是：投毒文档若要奏效，就必须对模型输出的 token 施加异常大的牵引力。TRACE 把这种牵引力变得可度量。它分两个阶段运行，全部在推理阶段完成，不改动模型权重。

首先，它进行 token 影响力归因：对给定回答，估计每个被检索 token 对回答 token 的贡献，然后查找在检索集合中反复出现、影响力异常偏高的高影响力关键词。在干净语料库中，影响力往往是弥散的；而定向投毒会把它集中到承载攻击者载荷的那一小段文字上。

其次，一个 验证环节 会确认这些高影响力 token 是否真正驱动了模型预测，而非巧合。只有通过这道二次检查的 token 才被视为投毒证据。

有两个特性使其在运维上颇具吸引力。它不需要辅助分类器，也不需要充当裁判的第二个 LLM，从而避免了这些方案带来的计算开销和攻击面。而且由于该方法聚焦于产生回答的 token，它把攻击者预设的目标答案作为副产品揭示出来——你不仅知道语料库被投毒，还知道投毒试图让系统说出什么。作者报告称，在三个问答基准和六个不同 LLM 上均取得了稳健的检测效果。

为什么重要

RAG 如今已成为企业将私有数据接入 LLM 的默认方式，这让检索语料库成为一等攻击面。任何能向已索引来源写入内容的人——维基、工单系统、共享盘、被抓取的网页——都是潜在的投毒者，而回报很高：对特定查询的回答进行隐蔽而有针对性的操纵，同时其余一切照常运转。

多数已部署的防御位于检索阶段（在生成前过滤或重排文档），或依赖一个单独的模型来筛查输入。它们有帮助，但会增加延迟和成本，并且看不见那些被设计成”在生成前显得无害”的投毒。一种在回答阶段工作、足够廉价可内联运行、且兼作事件响应工具（指出该移除哪个文档、攻击者想要什么）的检测方法，填补了一处真实的空白。标记攻击的同一影响力信号，也提供了清除问题记录并审计影响范围所需的取证物。

防御

TRACE 本身就是一项防御性贡献，但实践要点在于把归因分层融入 RAG 流水线，而非依赖单一控制。

• 将回答归因到来源。 对每个回答，追踪哪些被检索的文档、哪些片段驱动了输出。这正是 TRACE、AttnTrace 以及 RAGForensics 式溯源所提供的能力，也是事后定位并移除投毒记录的关键。
• 保留检索阶段的过滤，但不止于此。 片段级的异常与困惑度过滤仍能在生成前抓住粗糙的投毒；将其与回答阶段的归因结合，以抓住那些为绕过内容检查而设计的投毒。
• 对来源进行可信度评分。 按来源可信度对文档加权，并在检索时把可写入、低可信的来源（公开维基、用户提交内容、被抓取的网页）视为更高风险。
• 面向响应而非仅面向预防进行埋点。 记录影响力归因，以便出现可疑回答时，分析人员能够回溯、识别目标答案并清理语料库——把检测转化为修复。
• 在真实流水线下重新测试防御。 对任何 RAG 防御都要端到端评估（分块、检索、重排、生成），因为攻击与防御在完整流水线介入后行为都会不同。

状态

项目	参考	日期	备注
TRACE（本文）	arXiv:2606.25721	2026-06	token 影响力检测 + 目标答案还原；3 个 QA 基准，6 个 LLM
AttnTrace	arXiv:2508.03793	2025-08	基于注意力的注入/污染上下文归因
Needle-in-RAG	arXiv:2605.01782	2026-05	字符级投毒片段溯源
RAGForensics / 溯源	arXiv:2504.21668	2025-04	将回答归因到被检索文档