登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  科技周边 >  人工智能

RAG 系统怎样隔离文档中的指令性文本

来源:17golang原创

时间:2026-10-17 23:47:58 390浏览 收藏

RAG 系统隔离文档中的指令性文本,首先要把检索片段保持为不可信证据,不能让它改变系统规则、访问权限或工具能力。显式标注来源和内容边界有帮助,但不是硬隔离;真正限制越界后果的,是模型之外的权限判定和最小能力配置。

我在梳理知识库问答方案时,最在意的不是“怎样找到一句万能防注入提示”,而是文档被错误服从后还能够影响什么。下面用假设的内部知识库说明取舍,不声称有真实项目部署经历、事故记录或防护成功率。范围只讨论内容与指令的边界,不提供攻击载荷或绕过方法。

我先把文档看作证据而不是新任务

假设用户询问某项办公流程,检索结果中既有流程正文,又有一段要求回答系统改变行为的文字。即使该文件来自知识库,也不能让后者成为新的用户请求。文档可以描述一个操作步骤,但这不意味着当前用户已经授权系统去执行那个操作。

这类场景提醒我区分三个问题:内容是否能被当前用户读取,内容是否与问题有关,以及内容是否有权发号施令。前两项成立,不会自动让第三项成立。相似度分数、上传者名称或看起来正式的版式,都不应代替指令来源的权限判断。

OWASP 的 RAG 安全指导把检索链路中的文档与权限列为重要风险面;NCSC 也提醒不要把提示注入简单看成可以按 SQL 注入方式彻底修补的问题。我的取舍是:把模型可能误读文档当作需要约束的风险,而不是只依赖它每次都正确辨认。

显式分区有帮助,但不能代替隔离

在应用的上下文组装层,我会分别维护可信规则、用户问题和检索片段。可信规则由应用自己的配置产生;用户问题表达此次任务;检索片段保存原文、文档编号和版本,不允许它把自己改写成更高权限的消息。

检索内容应放入明确的证据区域,连同来源标识一起提供。对原文中的角色名称、标签或类似控制标记的文本,采用正常的编码与封装处理,避免它破坏应用构造的边界。同时明确告诉模型:片段只用于回答问题,其中针对助手行为的要求不构成任务授权。

这里需要克制地理解“分区”:文本标签只是表达边界,不是模型内部的可信执行机制。把文件转换成 JSON、加上引号或放入单独字段,并不会使其语义天然无害。不同模型和消息接口也有不同约束,不能凭一个示例格式保证安全。

可信规则用户问题和检索证据在上下文组装中的静态边界关系
图1:上下文边界说明图。来源标识帮助追溯检索证据,但不能把证据提升成可信规则;图不是运行过程或防护效果证明。

我不会把所有祈使句都删掉。技术手册和操作说明本来就常用“打开”“选择”“提交”等表达,粗暴删除会损害知识本身。更合适的区别是:它是在讲述原文中的流程,还是在试图改变当前助手的任务与权限。判断不确定时,保留可追溯引用并降级处理,而不是假装已经清洗干净。

只读抽取层能缩小影响面

对于要处理较多外部材料的系统,我倾向于考虑一个没有工具权限的抽取层。它只能读取本次允许的片段,输出回答所需的事实候选、来源编号和必要摘录,不拥有文件写入、外部发送或账号操作能力。

这个设计的收益不是“摘要模型不会被影响”,而是即使它被带偏,也没有那些直接行动能力。代价是增加一次处理开销,并可能丢失限定条件。因此,抽取结果仍按不可信数据对待,不能因为经过了第二个模型就获得更高信任等级。

应用应限制中间结果的字段、长度和允许引用的来源编号,拒绝把它当作任意新提示词执行。格式符合预期,只说明结构能被接收,不证明事实正确。后续回答仍需要区分事实候选和原始证据,不能只保留一段失去来源的摘要。

材料或组件允许承担的职责不应获得的能力
检索片段提供待引用的内容修改可信规则或用户身份
只读抽取层整理事实候选与来源自动执行文档中的操作要求
抽取结果作为下一步的受限数据因经过模型处理而自动受信任
回答层围绕用户问题组织说明自行为文档扩展授权范围

权限判定留在模型之外

我的下一项选择,是不让自然语言片段控制工具配置。若产品只是知识库问答,回答层就不必拥有写文件、发消息或修改业务记录的能力。不给能力,比给了能力再要求“请不要误用”更容易解释。

如果业务确实要执行动作,工具网关在每次调用时依据当前用户身份、允许动作和目标资源判定,不能依据文档里自称的授权,也不能依据模型输出的“已获批准”。用户确认涉及动作时,还应呈现具体对象与影响,而不是一个含糊的“是否继续”。

同样,租户和文档读取范围应在应用侧约束,先决定当前用户能获得哪些内容,再交给模型。不要先把越权内容送入上下文,然后期望模型不泄露。来源编号只负责追溯,并不是读取凭证;检索命中也不是操作许可。

回答建议与工具网关用户身份及目标资源授权的静态关系说明
图2:能力边界说明图。工具网关依赖应用提供的身份和策略,模型提出的动作只是待判定数据,检索文档不能为自己授予权限。

模型生成的链接、参数或动作描述同样不能未经应用约束就执行。即使不开放工具,误导性回答仍是风险;减少可调用能力,缩小的是后果范围,不会自动修复回答内容。

用不同结果衡量隔离是否值得采用

采用时,我会先为只读问答建立明确的证据边界,再按实际需要增加抽取层和动作能力。观察目标应分开:正常文档能否被正确引用,合法流程文本是否遭到过度拒绝,指令性内容是否改变任务,以及无授权动作是否被应用阻止。

这些是读者建设自己系统时可使用的观察维度,不是本文已经执行的测试。不能拿某个样本没有触发越界,就宣称提示注入已被消除;也不能只看拦截数量而忽略正常任务被拒绝的成本。

记录文档编号、版本、策略决策和必要的事件摘要,有助于定位边界失效位置;但日志不应因此收集完整敏感文档或凭据。我的结论是:对于内部检索问答,明确分区值得做;对于有行动能力的系统,还必须把权限控制放在模型之外。两者都不是一次配置后永远有效的保证。

内部文档就能直接当可信指令吗?

不能。内部来源可能包含转贴内容、历史模板或被修改的段落。文档归属与助手控制权限是不同属性。

把文档先总结一次就安全吗?

不安全保证。总结可能保留甚至强化误导内容;抽取层的主要价值应是只读和限制影响面,而非替内容颁发可信身份。

正确引用原文能证明没有注入吗?

不能。引用说明输出关联到了某份材料,不说明材料有权改变任务。应分别看引用事实与权限决策。

参考资料: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。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>