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 级注意力文档级注意力数据量大按 token 记录小按切片和文档聚合噪声高单 token 波动大低聚合后更稳定检测目标定位到具体词定位到证据来源告警友好度不容易设阈值容易和检索排序、引用对齐和 RAG 日志关联弱强可以直接对应 doc_id我在实际项目里更倾向于把 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 最后总结一个排查顺序面对注意力告警时我通常按照这个顺序处理先看检索日志确认哪几个切片进入了上下文。再看重排分数确认排序是否合理。检查上下文组装顺序排除位置影响。看注意力指标分布确认是集中、碎片化还是漂移。打开高注意力切片原文判断内容是否能正常阅读。对照文档来源和入库时间确认是否为新增、外部上传或标签异常。最后才决定是调整 prompt、修正解析链路还是隔离问题文档。不要一上来就改模型参数也不要直接封禁某个上传功能。RAG 投毒检测的难点不在于技术多复杂而在于能不能建立完整日志、把注意力信号和文档来源一起纳入判断。回到标题RAG 投毒可致注意力崩溃检测需关注文档级注意力。这个方向能投入多少取决于你有没有完整的推理日志。我的建议是就算短期不做自动化告警也要先让每次生成都留下结构化记录检索了谁、组装了谁、每个片段被注意力分配了多少权重、答案引用了谁。先把观测做起来再谈拦截。