RAG 系统怎样隔离文档中的指令性文本
来源:17golang原创
时间:2026-10-17 23:47:58 390浏览 收藏
RAG 系统隔离文档中的指令性文本,首先要把检索片段保持为不可信证据,不能让它改变系统规则、访问权限或工具能力。显式标注来源和内容边界有帮助,但不是硬隔离;真正限制越界后果的,是模型之外的权限判定和最小能力配置。
我在梳理知识库问答方案时,最在意的不是“怎样找到一句万能防注入提示”,而是文档被错误服从后还能够影响什么。下面用假设的内部知识库说明取舍,不声称有真实项目部署经历、事故记录或防护成功率。范围只讨论内容与指令的边界,不提供攻击载荷或绕过方法。
我先把文档看作证据而不是新任务
假设用户询问某项办公流程,检索结果中既有流程正文,又有一段要求回答系统改变行为的文字。即使该文件来自知识库,也不能让后者成为新的用户请求。文档可以描述一个操作步骤,但这不意味着当前用户已经授权系统去执行那个操作。
这类场景提醒我区分三个问题:内容是否能被当前用户读取,内容是否与问题有关,以及内容是否有权发号施令。前两项成立,不会自动让第三项成立。相似度分数、上传者名称或看起来正式的版式,都不应代替指令来源的权限判断。
OWASP 的 RAG 安全指导把检索链路中的文档与权限列为重要风险面;NCSC 也提醒不要把提示注入简单看成可以按 SQL 注入方式彻底修补的问题。我的取舍是:把模型可能误读文档当作需要约束的风险,而不是只依赖它每次都正确辨认。
显式分区有帮助,但不能代替隔离
在应用的上下文组装层,我会分别维护可信规则、用户问题和检索片段。可信规则由应用自己的配置产生;用户问题表达此次任务;检索片段保存原文、文档编号和版本,不允许它把自己改写成更高权限的消息。
检索内容应放入明确的证据区域,连同来源标识一起提供。对原文中的角色名称、标签或类似控制标记的文本,采用正常的编码与封装处理,避免它破坏应用构造的边界。同时明确告诉模型:片段只用于回答问题,其中针对助手行为的要求不构成任务授权。
这里需要克制地理解“分区”:文本标签只是表达边界,不是模型内部的可信执行机制。把文件转换成 JSON、加上引号或放入单独字段,并不会使其语义天然无害。不同模型和消息接口也有不同约束,不能凭一个示例格式保证安全。

我不会把所有祈使句都删掉。技术手册和操作说明本来就常用“打开”“选择”“提交”等表达,粗暴删除会损害知识本身。更合适的区别是:它是在讲述原文中的流程,还是在试图改变当前助手的任务与权限。判断不确定时,保留可追溯引用并降级处理,而不是假装已经清洗干净。
只读抽取层能缩小影响面
对于要处理较多外部材料的系统,我倾向于考虑一个没有工具权限的抽取层。它只能读取本次允许的片段,输出回答所需的事实候选、来源编号和必要摘录,不拥有文件写入、外部发送或账号操作能力。
这个设计的收益不是“摘要模型不会被影响”,而是即使它被带偏,也没有那些直接行动能力。代价是增加一次处理开销,并可能丢失限定条件。因此,抽取结果仍按不可信数据对待,不能因为经过了第二个模型就获得更高信任等级。
应用应限制中间结果的字段、长度和允许引用的来源编号,拒绝把它当作任意新提示词执行。格式符合预期,只说明结构能被接收,不证明事实正确。后续回答仍需要区分事实候选和原始证据,不能只保留一段失去来源的摘要。
| 材料或组件 | 允许承担的职责 | 不应获得的能力 |
|---|---|---|
| 检索片段 | 提供待引用的内容 | 修改可信规则或用户身份 |
| 只读抽取层 | 整理事实候选与来源 | 自动执行文档中的操作要求 |
| 抽取结果 | 作为下一步的受限数据 | 因经过模型处理而自动受信任 |
| 回答层 | 围绕用户问题组织说明 | 自行为文档扩展授权范围 |
权限判定留在模型之外
我的下一项选择,是不让自然语言片段控制工具配置。若产品只是知识库问答,回答层就不必拥有写文件、发消息或修改业务记录的能力。不给能力,比给了能力再要求“请不要误用”更容易解释。
如果业务确实要执行动作,工具网关在每次调用时依据当前用户身份、允许动作和目标资源判定,不能依据文档里自称的授权,也不能依据模型输出的“已获批准”。用户确认涉及动作时,还应呈现具体对象与影响,而不是一个含糊的“是否继续”。
同样,租户和文档读取范围应在应用侧约束,先决定当前用户能获得哪些内容,再交给模型。不要先把越权内容送入上下文,然后期望模型不泄露。来源编号只负责追溯,并不是读取凭证;检索命中也不是操作许可。

模型生成的链接、参数或动作描述同样不能未经应用约束就执行。即使不开放工具,误导性回答仍是风险;减少可调用能力,缩小的是后果范围,不会自动修复回答内容。
用不同结果衡量隔离是否值得采用
采用时,我会先为只读问答建立明确的证据边界,再按实际需要增加抽取层和动作能力。观察目标应分开:正常文档能否被正确引用,合法流程文本是否遭到过度拒绝,指令性内容是否改变任务,以及无授权动作是否被应用阻止。
这些是读者建设自己系统时可使用的观察维度,不是本文已经执行的测试。不能拿某个样本没有触发越界,就宣称提示注入已被消除;也不能只看拦截数量而忽略正常任务被拒绝的成本。
记录文档编号、版本、策略决策和必要的事件摘要,有助于定位边界失效位置;但日志不应因此收集完整敏感文档或凭据。我的结论是:对于内部检索问答,明确分区值得做;对于有行动能力的系统,还必须把权限控制放在模型之外。两者都不是一次配置后永远有效的保证。
内部文档就能直接当可信指令吗?
不能。内部来源可能包含转贴内容、历史模板或被修改的段落。文档归属与助手控制权限是不同属性。
把文档先总结一次就安全吗?
不安全保证。总结可能保留甚至强化误导内容;抽取层的主要价值应是只读和限制影响面,而非替内容颁发可信身份。
正确引用原文能证明没有注入吗?
不能。引用说明输出关联到了某份材料,不说明材料有权改变任务。应分别看引用事实与权限决策。
参考资料:OWASP RAG Security,https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html;OWASP LLM Prompt Injection Prevention,https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html;NCSC 对提示注入边界的讨论,https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection。
-
501 收藏
-
501 收藏
-
501 收藏
-
501 收藏
-
501 收藏
-
318 收藏
-
413 收藏
-
461 收藏
-
371 收藏
-
262 收藏
-
158 收藏
-
199 收藏
-
119 收藏
-
147 收藏
-
219 收藏
-
433 收藏
-
297 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 立即学习 543次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 立即学习 516次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 立即学习 500次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 立即学习 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 立即学习 485次学习