系统:运行中
← 返回所有攻击
DEFENSE LOW NEW

单一过滤器远远不够:为 RAG 聊天机器人设计的分层防御

2026 年 6 月中旬的一篇论文指出,单阶段的提示注入过滤器会放过被投毒的知识库文档,并测试了一套将攻击成功率从 71% 降至 11% 的三层流水线。

2026-07-04 // 6 min affects: rag-chatbots, llm-applications, retrieval-augmented-generation

这是什么?

2026 年 6 月 17 日,一篇题为 A Layered Security Framework Against Prompt Injection in RAG-Based Chatbots 的论文出现在 arXiv 上。其论点简单却值得认真对待:大多数提示注入防御只作用于流水线中的单一环节,而对于检索增强生成系统来说,单一环节永远不够。输入过滤器能看到用户的消息,却看不到检索器取回的文档;输出监控器能看到模型的回答,但那已是恶意载荷抵达模型之后。每一道控制都有盲区,而间接注入恰恰藏身于这些盲区之中。

提示注入仍是 OWASP LLM 应用十大风险中的头号条目——LLM01——而 RAG 使问题更严重而非更轻。在普通聊天机器人中,不可信文本只是用户所输入的内容;在 RAG 聊天机器人中,知识库本身成为攻击面:一份被投毒的文档只需被索引一次,就能危及每一位查询命中它的用户。论文将其贡献定位为以纵深防御来堵住这一缺口,而非依赖某个更聪明的单一分类器。

工作原理

这是一种防御性设计,而非攻击,因此没有任何可操作的内容需要删节。该框架在推理路径上放置了三道相互独立的检查,各自负责一个不同的信任边界。

第一层——输入筛查。 首先,用户消息由一个基于规则的模式库(已知的注入措辞、可疑的控制序列)与一个经过微调的语义异常分类器共同审查,后者标记那些看起来像是发给系统的指令、而非有待回答的问题的输入。这在门口拦截直接注入,但按设计并不指望它拦下一切。

第二层——基于来源的指令层级。 这是对 RAG 而言最关键的一层。在组装提示时——系统策略、检索到的文档、用户查询——框架按来源为每个片段打标签并强制排序:运营方策略高于用户输入,用户输入高于检索内容。来自检索文档的文本绝不允许被当作可以凌驾于运营方规则之上的指令来解读。一条被投毒的知识库条目仍可以写着”忽略你的指令”,但在组装时它携带最低权限,被视为数据而非命令。这直接应对了输入过滤器在结构上无法看到的间接注入路径。

第三层——输出审计。 生成之后,回答会经过一个策略规则引擎和一项语义漂移检查,将回答与既定任务进行比对。如果模型被诱导偏离——泄露系统提示内容、执行嵌入的指令、偏离用户的真实问题——这种偏差会在回答返回之前被捕获。

各层是刻意冗余的。其要旨不在于其中某一层完美无缺,而在于攻击必须同时击败三层,且三层以不同方式失效。

为何重要

所报告的数字给出了效应量的概念:在作者的评估中,叠加这三道控制将攻击成功率从约 71% 降至约 11%,同时将误报率保持在 5% 左右。这两个数字决定一项防御是否可部署——一个能拦截注入、却也拦下五分之一合法查询的过滤器,永远撑不过与真实用户的接触。

比精确百分比更重要的是可推广到该系统之外的结构性教训。团队常常在 RAG 部署上加装单一护栏——通常是输入分类器,因为那是最容易加的位置——便认为问题已解决。其实并未解决。检索步骤会在输入过滤器运行之后悄然重新引入不可信文本,而无论怎样调校该过滤器,它都无法审查一份它根本看不到的文档。具备来源意识的上下文组装,正是大多数部署所遗漏的一环,也正是它专门防御了 RAG 特有的失效模式:一份被索引的文档投毒多个会话。近期关于保护 RAG 聊天机器人的产业案例研究,如新竹智慧旅游部署,也从应用侧得出了相同结论。

防御措施

不要依赖单一过滤环节。 单独的输入分类器看不到检索内容;单独的输出监控器行动太迟。应假设每道控制都有盲区,在输入、上下文组装和输出三处布置相互独立的检查,使攻击必须逐一击败。

标注来源并强制指令层级。 按来源为组装提示中的每个片段打标签——系统、用户、检索——并让权限跟随来源:运营方策略高于用户,用户高于检索文档。无论检索文本说什么,它都应在结构上无法凌驾于你的规则之上。

将知识库视为攻击面。 在 RAG 中,一份被投毒的文档可能影响所有检索到它的用户。审查并监控被摄入的内容,限制谁可写入索引,并记录哪些文档促成了被标记的回答,以便追溯投毒。

审计输出的任务漂移,而不仅是违禁词。 将回答与既定任务比对的语义漂移检查,能发现关键词过滤器漏掉的诱导——系统提示泄露、悄然遵循嵌入指令而非用户问题的回答。

衡量误报率,而不仅是拦截率。 一项拦截攻击却拒绝大量合法查询的防御,最终会被关闭。上线前请同时报告两个数字,并将工作点调到仍然可用的水平。

Status

项目参考日期备注
论文arXiv:2606.196602026 年 6 月面向 RAG 聊天机器人的三层防御
第一层输入筛查:规则模式库 + 微调异常分类器在输入处拦截直接注入
第二层组装时基于来源的指令层级检索内容无法凌驾策略——关键的 RAG 防御
第三层输出审计:策略规则引擎 + 语义漂移在生成后捕获诱导
报告效果攻击成功率 ~71% → ~11%;误报率 ~5%作者自评
背景OWASP LLM01;相关 RAG 案例 arXiv:2509.213672025–2026提示注入被列为最关键的 LLM 风险

该框架并不声称能解决提示注入——如今没有任何防御能可信地做到——但它提出了一个具体且可检验的论点:RAG 部署需要在不止一个环节设防,而具备来源意识的上下文组装正是最常被省略的那一环。对任何运营检索增强聊天机器人的人而言,这都是一项成本低廉、值得对照这一真正棘手的失效模式加以评估的架构调整。

Sources