RAG投毒致注意力崩溃，文档级注意力是关键检测信号

RAG 投毒这套攻击思路，凡是做过知识库问答的人应该都不陌生。但我第一次真正意识到“投毒能打崩注意力”时，并不是因为模型输出了明显有害的话，而是因为一次很普通的问答：用户问某个政策条款，检索系统返回了三篇文档，模型却只盯着其中一段来自外部上传文件的表述，把答案引到了一个完全跑偏的方向。事后看日志，答案里的引用和检索排序并不是完全一致，模型的注意力几乎全部落在那个高相关但高风险的片段上。这件事提醒我：RAG 系统的安全检查，不能只看最终回答是否正当，还要看模型在生成时看了哪些文档、把注意力放在了哪里。

这篇文章想聊的，就是把文档级注意力当成 RAG 投毒检测的一个关键信号。RAG 投毒可致注意力崩溃，检测需要关注文档级注意力。适合正在做 RAG 应用、Agent 知识库、安全评测的读者。最值得关注的不是某个万能拦截规则，而是一条完整链路：检索日志、上下文组装、注意力观测、告警和复盘。下面按真实落地顺序拆一遍。

1. RAG 投毒攻击的不是答案，而是检索和注意力链路

1.1 很多人把 RAG 安全等同于 Prompt 安全

我在看同类项目时发现一个普遍误区：一提 RAG 安全，第一反应就是加 Prompt 过滤、禁止模型输出敏感内容，或者做一轮关键词拦截。这些措施有用，但拦截对象是“显式注入”。攻击者把一段明显带指令的话放进知识库，模型确实可能被执行，这种情况现在很容易被识别。

真正难处理的是另一种形态：投毒文档本身不包含任何“给我一个危险答案”的指令，它只是一段语义上特别相关、但结论有误的普通文本。比如某个公开知识库允许用户上传文档，攻击者上传的文本和大量业务 query 在向量空间里高度接近，表面上谈的是同一个主题，把结论悄悄改掉。Prompt 层根本看不出来，因为模型没有违反任何显式规则，它只是“信了错误资料”。

所以，RAG 投毒更准确的描述是：攻击者不直接操纵模型，而是操纵模型赖以生成答案的上下文。投毒的目标从“让模型输出恶意内容”变成了“让模型把注意力放到错误文档上”。

1.2 投毒文档真正影响的是上下文组装

要理解这一点，得先看 RAG 的完整链路。一个标准的 RAG 流程是：

query -> 文档加载 -> 切分 -> 向量化 -> 检索 TopK -> 重排 -> 上下文组装 -> 生成

攻击者不需要碰模型权重，也不需要碰向量库底层，只需要让自己的文档进入候选集，并且在排序阶段尽量靠前。如果向量检索算法有问题，或者文档元数据、标签可以被污染，恶意文档进入 TopK 的概率会明显增加。

真正被影响的是“上下文组装”这一层。模型拿到的 prompt 是由多个文档切片拼接出来的，每个切片在上下文里的位置、长度、分隔方式都会影响模型注意力。投毒文档一旦被拼接进去，它就会在生成时参与注意力计算。由于它在语义上与 query 高度相关，模型很容易给它分配更高权重，再往下就是答案引用错误、来源可信度崩塌。

这个环节最大的问题是隐蔽。从产品侧看，用户只看到“模型答错了”，不会看到“模型在生成时把注意力交给了哪个片段”。如果不做日志记录，投毒检测只能依赖用户投诉，延迟会非常大。

1.3 为什么标题强调“注意力崩溃”

注意力崩溃不是模型死机，而是注意力分布出现结构性异常。正常生成时，模型会参考多个文档切片，注意力相对分散。遇到投毒文档时，可能出现三种异常：单一文档或切片占据过高的注意力比例；注意力熵明显降低，模型几乎只围绕一个片段生成；又或者注意力在不同文档之间剧烈漂移，同一个 query 在不同时间得到完全不同的证据依赖。

这类异常比最终答案错误出现得更早，也更稳定。答案可能因为模型本身的泛化能力被“兜住”，没有明显跑偏，但注意力日志已经暴露了风险。这也是我建议把注意力当成检测信号的核心原因。

注意：这里说的注意力崩溃是针对检索增强生成场景的一种观测现象，不是模型内部触发了崩溃。判断它需要日志数据，不能只凭感觉。

2. 注意力崩溃为什么比“答错”更隐蔽

2.1 注意力分数不是黑盒，是可以观测的信号

很多人觉得注意力机制不可解释，其实在本地开源模型和一部分托管模型上，注意力权重是可以拿到的。模型在生成每个 token 时，会对 prompt 中的每个 token 计算注意力权重。我们不需要看每一层每一个头，只需要按文档切片做聚合，就能得到“模型在回答这个问题时，到底依赖了哪些片段”。

退一步说，即使模型接口不开放注意力权重，也可以从行为日志里做近似观测。例如：答案中引用了哪些文档；答案片段和哪个文档切片有最高的文本重叠；检索排序第一的文档有没有被生成过程真正采纳；模型在长上下文里是否只使用了后半段内容。这些信号叠加起来，可以还原出注意力分配的大致轮廓。

2.2 投毒场景下常见的四类注意力异常

从检测角度，我会重点关注四类模式：

第一类是注意力过度集中。正常回答通常会综合多个相关片段，如果某个文档切片突然占据了极其夸张的注意力比例，比如超过七成，就需要重新检查这个片段的来源和内容。投毒文档为了在检索阶段挤进前几名，往往会做得“和所有 query 都相关”，这种片段很容易把注意力吸走。

第二类是注意力碎片化。每个片段占比都不高，模型没有稳定依据，东拼西凑出一个答案。这类情况不一定是投毒，可能是切分太碎、检索召回质量差，但如果同时伴随引用混乱，也要考虑是否存在故意插入的干扰片段。

第三类是注意力漂移。同一个 query 多次运行，模型依赖的文档切片每次都不一样。正常情况下，相同或相似 query 的证据依赖应该比较稳定。如果发现同一 query 在几天之内从依赖 A 文档变成依赖 B 文档，且 B 文档是新入库的，就需要关注。

第四类是注意力与检索排序严重背离。检索排第一的文档在注意力占比里很低，检索排到第六、第七的文档反而占据主导。这种背离说明重排或上下文组装环节出了问题，也可能是某个恶意片段绕过了正常排序，靠位置或文本噪声获得了注意力优势。

2.3 文档级注意力比 token 级注意力更适合做告警

token 级注意力数据量太大，而且单 token 的权重波动非常明显。比如一个文档切片里某个单词触发了模型注意，不代表整个文档都被依赖。如果直接用 token 级注意力做告警，会产生大量噪声。

文档级注意力把注意力权重按文档切片聚合，更稳定，也更接近产品层面的判断。我们关心的不是模型看了哪个词，而是模型在决策时把多少权重给了哪份文档、哪个切块、哪一次注入的片段。用表格对比会更清楚：

我在实际项目里更倾向于把 token 级注意力作为诊断工具，把文档级注意力作为告警指标。

3. 在真实 RAG 链路里观察文档级注意力

3.1 先记录“谁被检索了”，再记录“谁被注意力选中了”

很多 RAG 项目连基础的检索日志都不完整。出了问题只能看到模型答案，看不到当时检索了哪些文档、每个文档的分数、切片在 prompt 中的位置、模型引用了哪些来源。这会导致排查非常被动。

我建议至少在语义上拆成两类日志：

• 检索侧日志：query 文本、检索 TopK、每个切片 id、向量相似度、重排分数、最终进入上下文的切片列表和顺序。
• 生成侧日志：模型使用的 prompt 快照或片段摘要、每个切片的注意力聚合值、答案中的引用来源、生成耗时。

两条日志用 request_id 关联起来。这样一旦发现注意力异常，可以反查“是哪个切片被喂进了上下文”，也能确认“这个切片是不是新入库的、来源是谁”。

3.2 计算文档级注意力需要用到的指标

文档级注意力不是说一个数字就能覆盖所有场景，我一般会同时看几个指标：

第一个是文档注意力占比。把某个切片内所有 token 的平均注意力权重汇总，除以整个上下文里所有 token 的注意力权重之和，得到该切片在生成过程中的影响力。占比越高，说明模型越依赖这个片段。

第二个是注意力熵。对上下文中的文档切片分布计算熵值。熵值过低，表示模型几乎只盯着一个来源；熵值过高，表示依据过于分散。两者都值得关注。

第三个是 Top-1 集中度。把注意力最高的那个文档切片的占比单独拎出来，和整个候选集对比。如果 Top-1 集中度明显高于历史分布，就要检查是否存在单点依赖。

第四个是引用覆盖率。看答案中提到的来源和注意力高权重来源是否一致。如果模型引用了 A 文档，但实际注意力几乎全部在 B 文档，说明引用生成不可靠，也可能存在“引用正确来源、但答案被错误片段带偏”的混合风险。

3.3 从查询日志和推理日志里还原注意力异常

举一个我在测试中见过的典型例子。某个企业知识库里放了三份文档，用户问“请假审批需要几步”。文档 A 是正规制度，文档 B 是某个人上传的工作总结，里面顺带写了一句“请假只要找组长口头说一声就行”，文档 C 是旧版制度。

从向量检索看，A 和 B 分数接近，B 因为表述简短、关键词密度高，排到了第二位。生成阶段，模型给 B 的注意力占比到了 0.65，给 A 只有 0.21。最终答案居然真的采信了“口头说一声”的错误结论。这个案例里，模型没有输出恶意内容，也没有被显式提示，但它被一段相关性极高的投毒文本带偏了。

如果只看最终答案，可能觉得是模型理解能力不行。看检索日志和注意力日志后会发现，真正的问题出在文档入库阶段的污染。B 文档来源不明，且和 query 的相关性属于“异常高”，这种模式完全可以进入告警。

3.4 Agentic RAG 场景要多看一轮工具调用

现在很多系统已经不满足于单轮 RAG，而是把检索、重排、工具调用、多轮追问组合成 Agentic RAG。这个场景里的投毒影响会更隐蔽。Agent 可能在第一轮检索到一份被污染的文档，然后把其中错误的实体、参数或结论作为下一轮工具调用的依据。这时候注意力异常可能不在最终回复里，而是出现在工具参数里。

处理方法是多记录一层：每一轮 Agent 的 tool call 输入输出、检索结果快照、当前上下文引用了哪些来源。只有把 Agent 的决策过程拆开，才能定位到注意力是在哪一步开始偏移的。

注意：Agent 场景里，文档级注意力异常往往先表现为“工具参数异常”，而不是“回答异常”。排查时要顺着工具调用链往回找。

4. 设计一套文档级注意力巡检系统

4.1 检测不能只放在生成后，要拆成五个检查点

投毒检测如果只盯着最终答案，会很被动。我把整个检测流程拆成五个检查点：

第一，文档入库前。检查文档来源、上传者身份、元数据、标签、文件格式。这里的目标不是判断内容是否“看起来正常”，而是确认“来源是否可信”。允许外部用户上传文档的系统，必须把“未知来源”和“历史可信来源”分开标记。

第二，检索结果检查。当某个新增文档在短时间内在大量不同 query 下都进入 TopK，或者检索分数分布异常集中，就要警惕。正常文档通常只和特定主题匹配，投毒文档为了扩大影响面，往往会覆盖更多语义空间。

第三，重排后候选集检查。看进入最终 prompt 的文档是不是都来自可信来源，是否存在一个来源不明的切片突然到了前排。重排模型本身也可能被投毒数据影响，所以不能只查向量检索。

第四，上下文组装检查。看切片顺序、长度、重复情况。有些攻击不靠内容本身，而是靠把恶意切片放在 prompt 特定位置，比如放在正常文档前面。检查时要关注上下文里是否有大量重复文本、是否有特殊分隔符异常。

第五，生成后检查。这一步就是我们前面说的注意力指标、引用一致性、事实一致性。结合检索日志，判断最终答案依据的来源是否和检索候选集一致。

4.2 告警阈值怎么定

阈值不能拍脑袋，也不能照着别人的项目抄。最稳妥的办法是用干净流量建立基线。先跑一段时间正常数据，统计出每个指标的正常分布，再取 p95 或 p99 作为告警线。

有一个参考思路：正常情况下，Top-1 文档注意力占比不会极端高；如果某个切片的注意力占比超过基线 p95 的 1.5 倍，或者注意力熵比同类型 query 的基线下降了 40% 以上，就可以进入人工复核。这个倍数和比例只是示例，你的模型、切分长度、文档来源结构都不同，阈值要靠自己调。

要做到低误报，不能只看一次生成。同一个 query 可以多次采样，如果每次都依赖同一个异常切片，才进入高置信告警。如果只是偶尔一次，可能和上下文截断、随机采样有关。

4.3 用结构化日志把告警和人工复盘接起来

告警只是起点，真正有价值的是复盘。我建议把每次生成的注意力观测记录成结构化日志，至少包含以下字段：

{ "request_id": "a1b2c3d4", "query": "请假审批需要几步", "retrieved_docs": [ {"doc_id": "doc_a", "score": 0.82, "rank": 1, "source": "hr_manual"}, {"doc_id": "doc_b", "score": 0.79, "rank": 2, "source": "external_upload"} ], "context_order": ["doc_a", "doc_b", "doc_c"], "attention": { "doc_attention_share": {"doc_a": 0.21, "doc_b": 0.65, "doc_c": 0.14}, "attention_entropy": 0.83, "top1_share": 0.65 }, "citation": ["doc_a"], "answer_snippet": "请假只需要找组长口头说一声即可" }

看到这段日志，问题会比较明显：答案引用了 doc_a，但 doc_b 的注意力占比最高，且来源是外部上传。人工复核只需要确认 doc_b 是不是新入库、上传者是否为可信账号、内容里有没有变更结论，就能快速分级处置。

线上可以先记录不分级，等有事件之后再回查。更成熟一点的方案，是每天定时跑一个固定问题集，把新增文档批量丢进测试流程，自动对比注意力指标的变化。这样即使攻击者选择慢速投毒，也能通过历史基线发现偏移。

4.4 巡检任务需要保持小步快跑

自动化告警系统很容易在刚上线时因为误报被打爆。建议先切一个小范围：只监控新增文档、外部上传文档、答案引用与注意力不一致的请求。等日志质量稳定后，再逐步扩大到全量 query。

不要一开始就做一个庞大的可视化平台。先用数据库存日志，再写一个批量脚本计算注意力指标，最后把这些指标灌进现有的告警通道，就能达到大部分检测目的。

5. 用评估基线验证检测能否拦住投毒

5.1 准备三层测试样本

检测系统上线前，最需要回答的问题是：它能不能在投毒发生时给出有效告警，同时又不打扰正常运营。我习惯准备三层测试样本。

第一层是干净基线。用你线上真实的历史 query 和文档，不加任何污染，统计正常注意力分布。这一层决定了阈值设置。

第二层是公开文档污染。把一些明显的错误信息、过期政策、同主题干扰内容放进测试知识库，看检测系统能不能识别出“注意力集中到了非可信来源”。这一层适合验证基础能力。

第三层是同主题对抗污染。构造和 query 高度相关但结论错误的文档，模拟最隐蔽的攻击。这一层才是真正的检测难点，因为只靠关键词过滤往往拦不住。

需要说明的是，我这里说的是防御性测试，目的是提升检测能力，不是去开发攻击样本。如果你的项目里有专门的安全测试角色，测试样本的构造、使用和销毁都要走评估审批流程。

5.2 关注四个评估指标

评估一套 RAG 投毒检测方案，不能只看“有没有告警”。我会关注四个指标：

另外还需要看两个辅助指标：引用准确率和答案事实一致性。如果注意力指标已经异常，但最终答案没有明显错误，说明模型还没有“被带崩”，但这不代表没有风险。检测对象应该是异常注意力信号，而不是等答案错了再补救。

5.3 不要只在离线数据上自测

离线评测有一个常见问题：样本量小，覆盖率不够，指标容易虚高。我见过有的项目在几十条测试样本上召回 100%，上线后面对真实流量还是漏检。

更可靠的做法是分三阶段推进。第一阶段离线跑历史日志，确认指标和人工标注匹配；第二阶段灰度新文档入库流程，只读检测；第三阶段才开启告警拦截。拦截动作也要保守，先发通知，不直接删除文档，避免误伤正常内容。

评测框架可以借用 RAGAS 这类库里的 faithfulness、answer relevance 指标，也可以自己计算引用重叠率。但要注意，这些框架主要面向内容质量，不是专门为投毒检测设计的。真正有用的，还是要结合你自己的知识库来源分布和注意力日志来定制。

5.4 把注意力指标纳入日常评测体系

如果项目已经在做 RAG 评估，建议把文档级注意力字段直接加进评测结果里。比如评估报告除了“答案是否切题”，再增加一列“证据来源是否可靠”“注意力集中度是否异常”。

这样做的好处是，即使某次投毒没有导致明显答案错误，也能在评测阶段发现异常，而不是等用户投诉。长期积累后，这些注意力日志还能训练更精准的异常检测模型。

6. 常见误判和排查顺序

6.1 看起来是投毒，实际是文档解析和切分问题

我在排查注意力告警时，经常会先排除一个常见问题：文档加载解析失败，导致文本内容错位。比如 PDF 转文本后表格内容被截断，某一段文字前后拼接出完全不相关的语义，模型在生成时对这段错位内容产生依赖，看起来像注意力崩溃，实际上是解析污染。

遇到高注意力占比告警，先打开对应文档切片看一眼。如果切片内容本身读不通，应该先修文档加载链路，而不是急着判定投毒。

6.2 看起来是注意力崩溃，实际是上下文过长或 Prompt 顺序问题

上下文窗口过长时，模型对中间内容的注意力会衰减。有些模型对 prompt 中后部内容更敏感，如果某份正常文档恰好被放在最后一个位置，它也可能获得过高注意力占比。这种情况不是投毒，是上下文组装策略不合适。

排查时要看上下文中的切片顺序。尝试调整顺序、增加分隔符、移除低相关切片后，如果注意力分布恢复正常，就说明问题出在组装环节。正常文档的“注意力集中”和投毒文档的“注意力集中”，对排查人员来说，必须用来源可信度来区分，不能只看注意力数值。

6.3 看起来是注意力异常，实际是标签和元数据污染

另一种误判来自向量化环节。有些系统在向量化时会把文档标题、标签、上传者信息一并编码进向量。攻击者不需要修改正文，只要给文档添加和大量 query 匹配的标签，就可能让这条文档在检索阶段大量出现。生成阶段模型看到的正文本身没有毒性，但检索排序已经失真。

检查方法是看检索日志里进入 TopK 的那些文档，其标题和标签在向量表示里占多大比重。可以先做一轮只读取正文内容的向量化对比，如果排序结果差异很大，就要调整向量化字段。

6.4 最后总结一个排查顺序

面对注意力告警时，我通常按照这个顺序处理：

1. 先看检索日志，确认哪几个切片进入了上下文。
2. 再看重排分数，确认排序是否合理。
3. 检查上下文组装顺序，排除位置影响。
4. 看注意力指标分布，确认是集中、碎片化还是漂移。
5. 打开高注意力切片原文，判断内容是否能正常阅读。
6. 对照文档来源和入库时间，确认是否为新增、外部上传或标签异常。
7. 最后才决定是调整 prompt、修正解析链路，还是隔离问题文档。

不要一上来就改模型参数，也不要直接封禁某个上传功能。RAG 投毒检测的难点不在于技术多复杂，而在于能不能建立完整日志、把注意力信号和文档来源一起纳入判断。回到标题：RAG 投毒可致注意力崩溃，检测需关注文档级注意力。这个方向能投入多少，取决于你有没有完整的推理日志。我的建议是，就算短期不做自动化告警，也要先让每次生成都留下结构化记录：检索了谁、组装了谁、每个片段被注意力分配了多少权重、答案引用了谁。先把观测做起来，再谈拦截。