如何保护 RAG 应用的安全？

字数 4142，阅读大约需 21 分钟

在当前企业加速AI落地的大背景下，理解并掌握RAG应用的安全防护措施对于构建可靠、合规的AI系统至关重要。本次推介的文章How Do You Secure RAG Applications?^[1] 深入探讨了检索增强生成(RAG)架构的安全隐患及其防护措施，为企业构建可靠、安全的AI应用提供实用指导。

为何企业选择基础模型而非自研？

打造Llama 3.2、Claude Opus或GPT-4o这类复杂大语言模型，往往需要数年研发和数百万美元算力投入。多数企业会选择现成的基础模型，而非从头自研。这些模型如同"数字黏土"，企业可通过系统架构和提示工程（prompt engineering）将其塑造成业务所需形态。选定基础模型后，下一步是确定如何应用模型，以及如何通过专有数据提升其价值。

知识截止日期的关键影响

基础模型是在庞大的数据语料库上训练的，这些数据会影响模型的表现。这些训练数据也会影响大模型的事实回忆能力，即大模型访问和复现存储在其参数中的事实知识的过程。

虽然大模型可能基于其训练数据包含广泛的知识，但总会有一个知识截止日期。基础模型提供商可能会在模型卡片中披露这一信息以保持透明度。例如，Llama 3.2的模型卡片表明其知识截止日期是2023年8月。向基础模型询问2023年9月的事件，它根本不会知道（尽管它可能会为了有所帮助而产生幻觉）。

以ChatGPT的问答表现为例：

在这个回答中，gpt-4o基于其神经网络权重中编码的信息复现了事实知识。然而，输出的准确性可能会根据提示和模型中的任何训练偏差而有很大差异，从而影响大模型事实回忆的可靠性。由于没有办法"引用"大模型生成回应时使用的来源，你不能仅仅依赖基础模型的输出作为唯一的事实来源。

换句话说，当基础模型提供事实知识时，你需要持保留态度。信任，但要验证。

基础模型知识截止日期的一个例子可以通过询问模型关于近期事件的问题来看到。在下面的例子中，我们向ChatGPT询问了最新的通胀新闻。你可以看到，模型完成了一个函数，它在网上搜索并总结结果。

这个输出依赖于一种检索增强生成（RAG）类型，它搜索最新的知识库并将相关信息集成到提供给大模型的提示中。换句话说，大模型通过嵌入来自第三方来源的上下文来增强其响应。我们将在本文后面深入探讨这种结构。

虽然基础模型有其优势，但对于特定领域的任务和实时分析，它们的用处也有限。想要利用大模型处理其专有数据或外部来源的企业需要确定是否要微调模型和/或部署RAG架构。以下是每个选项的高级功能概述。

微调的价值

某些情况下，微调模型是最合理的选择。微调通过在更小、更有针对性的数据集上训练来增强大模型在特定领域任务的表现。这一过程调整了模型权重，优化特定任务的性能，同时保留模型的通用知识。

把大模型想象成刚从大学毕业的学生，记住了所有课程知识。微调就像让它攻读硕士学位。它仍记得大二微积分的内容，但现在还能回答硕士阶段代数拓扑和概率论的问题。

当从业者希望用保持静态的知识库增强基础模型时，微调策略最为有效。这对于医学等有广泛深入知识库的领域特别有帮助。在2024年4月发表的一篇研究论文中，研究人员观察到与基础模型相比，微调模型在医学知识方面表现大幅改善。

可以看到，全参数微调模型在大学生物学、大学医学、医学遗传学和专业医学的MMLU表现更佳。

经过医学知识训练的微调模型可能对科学家和医学生特别有帮助。但是，医院的临床医生如何利用微调模型来治疗她的患者呢？这正是大模型应用需要检索增强生成（RAG）技术的地方。

检索增强生成（RAG）的优势

检索增强生成（RAG）本质上是一个通过整合外部知识源来增强大模型能力的框架。简单来说，RAG架构通过在提示中为大模型提供额外上下文来增强回答。可以把它想象成在邮件中附加文件。

没有RAG，基本的聊天机器人流程如下所示：

使用RAG，流程可能如下所示：

使用RAG框架，提示会生成一个查询到向量数据库，该数据库识别相关信息（"上下文"）以提供给大模型。这个上下文基本上是在发送到基础模型时"附加"到提示中的。

现在你可能会问——在提示中手动包含上下文（如在聊天机器人中附加PDF）与实现RAG架构有什么区别？

答案归结为可扩展性和访问权限。个人用户可以从本地存储中检索PDF并将其附加到对大模型（如ChatGPT）的查询中。但RAG的妙处在于连接异构和广泛的数据源，为用户提供强大上下文支持——即使用户无法直接访问这些数据源。

假设你为家里购买了一个智能温控器，但安装时遇到了麻烦。你联系了一个客服聊天机器人，它询问如何帮助你，但当聊天机器人询问型号时，你真不记得了。收据和包装早就丢了，又懒得去检查设备找型号。

当你提供联系信息时，聊天机器人找出了你购买的温控器的详细信息，包括购买日期和型号。然后利用这些信息，它通过总结用户手册中的材料，甚至可能从与其他客户类似问题的解决方案来帮你排障。

这背后正是精心实施的RAG框架。

RAG编排的关键组件

RAG框架将由以下几个关键组件组成：

1. 1. 编排层：这充当RAG系统的中央协调器，管理不同组件之间的工作流和信息流。处理用户输入、元数据和与各种工具的交互。常用的编排层工具包括LangChain和LlamaIndex。
2. 2. 检索工具：负责从知识库或API中检索相关上下文。例如包括向量数据库和语义搜索引擎，如Pinecone、Weaviate或Azure AI Search。
3. 3. 嵌入模型：根据提供的数据创建向量表示（嵌入）的模型。这些向量存储在将用于检索相关信息的向量数据库中。
4. 4. 大型语言模型：处理用户输入和上下文并产生输出的基础模型。

好的，现在我们大致了解了RAG框架工作方式，接下来看看哪些配置错误可能导致安全问题？

RAG架构的安全问题

身份验证和授权流程

根据大模型应用的使用场景，可能需要实施身份验证。安全角度看，这有两大好处：

1. 1. 强化责任追踪和日志记录
2. 2. 部分缓解钱包拒绝服务(DoW)和拒绝服务(DoS)的风险

如果需要限制对应用程序内某些数据的访问，那么身份验证将是授权流程的前提。RAG框架中实现授权有几种方式：

• • 文档分类：在文档摄取过程中为文档分配类别或访问级别
• • 用户-文档映射：创建用户/角色与文档类别之间的关系
• • 查询时过滤：在检索过程中，根据用户权限过滤结果
• • 元数据标记：将授权元数据包含在文档嵌入中
• • 安全嵌入存储：确保向量数据库支持访问控制

配置授权列表也有多种方法：

• • 基于角色的访问控制(RBAC)：为用户分配角色（例如管理员、编辑者、查看者），并根据这些角色授予权限。
• • 基于属性的访问控制(ABAC)：用户可以根据用户自身、资源和环境的属性访问资源。
• • 基于关系的访问控制(ReBAC)：根据用户与资源之间的关系定义访问权限。

RAG框架的优点在于可以将不同的异构数据源整合到一个统一的源中——向量数据库。但这也意味着需要建立一个统一的权限模式，能够映射来自不同来源的不同访问控制模型。还需要在向量数据库中与向量嵌入一起存储权限元数据。

用户发送提示后，随后需要采取双管齐下的方法：

1. 1. 查询前过滤：在执行前对向量搜索查询实施权限过滤
2. 2. 查询后过滤：确保搜索结果映射到授权文档

零信任原则

应该假设存储在向量数据库中的任何内容可能被通过大模型检索并返回给用户。尽可能避免在向量数据库中索引PII或其他敏感数据。

如果需要索引敏感数据，则应在数据库级别强制访问控制，并应使用用户令牌而不是全局授权执行查询。

授权流程不应该依赖于提示本身。相反，应该调用一个单独的函数，验证用户被允许访问什么，并根据用户的授权检索相关信息。

潜在风险点

没有授权流程的RAG应用中，用户可能访问任何想要的信息。某些场景下这是合理的，比如仅用于帮用户查阅帮助中心文章的聊天机器人。

但是如果您正在部署多租户应用程序或涉及敏感数据（如个人信息或健康信息），那么正确实施RAG就至关重要。

在传统的渗透测试中，我们可以通过创建租户、实体和用户的映射来测试授权流程。然后，我们会针对这些实体进行测试，看看是否可以与不应该交互的资源进行交互。同样可以在单一注入点——大模型端点——内为RAG架构创建类似测试矩阵。

授权流程中永远不应信任用户提示，也不应仅依赖系统提示作为限制访问的唯一控制手段。

提示注入

使用RAG的大模型应用程序仍然容易受到提示注入和越狱的影响。如果应用仅依赖系统提示来限制输出，那么应用仍然可能容易受到传统的提示注入和越狱攻击。

这些漏洞可以通过精细的提示工程以及输入和输出的内容护栏来缓解。

上下文注入

上下文注入攻击涉及操纵提供给大模型的输入或上下文，以非预期的方式改变其行为或输出。精心制作提示或注入误导性内容可以强制大模型生成不适当或有害的内容。

上下文注入攻击类似于提示注入，但恶意内容被插入检索的上下文而非用户输入。有多篇优秀的研究论文^[2]概述了上下文注入技术。

数据中毒

在某些情况下，用户可能能够将文件上传到应用中，这些文件随后被其他用户检索。当上传的数据存储在向量数据库中时，会与可靠数据融为一体难以区分。如果用户有权限上传数据，那么就存在一个攻击向量，存在数据中毒的风险，导致模型生成不准确或误导性信息。

敏感数据泄露

大模型应用面临与任何其他应用相同的授权错误配置风险。在Web应用中，我们可以通过使用单独的会话cookie或标头交叉测试操作，或尝试通过IDOR攻击检索未授权信息来测试失效的授权。对于大模型，检索未授权敏感数据的注入点是提示。至关重要的是测试基于用户访问和对象属性的对象有强大的访问控制。

可以实施内容护栏限制敏感数据如个人信息或健康信息的暴露。然而，依靠内容护栏来限制在输出中返回PII是单点故障。就像WAF一样，内容护栏可以通特定payload或技术被绕过。建议在数据接触向量数据库之前就清理所有敏感信息，此外还要强制实施内容护栏。

上下文窗口溢出

所有大模型都有一个上下文窗口，相当于工作记忆。它决定了模型可以使用多少先前的上下文来生成连贯和相关的响应。应用中，上下文窗口必须足够大，以容纳以下内容：

• • 系统指令
• • 检索的上下文
• • 用户输入
• • 生成的输出

通过用无关信息填满上下文窗口，攻击可以推出重要的上下文或指令。因此，大模型可能"忘记"其指令并变得失控。

这种类型的攻击在上下文窗口较短的较小模型中更为常见。对于像Google的Gemini 1.5 Pro这样的模型，其上下文窗口有超过一百万个标记，溢出风险较低。对于像Llama 3.2这样的模型，最大上下文窗口为128,000个标记，风险可能更明显。

RAG的安全加固措施

通过精心设计和安全控制，RAG框架的大模型应用能产生卓越效果。

一旦您了解应用程序中存在哪些漏洞，就可实施多项控制措施确保用户安全使用大模型应用：

• • 输入和输出验证和清理：实施强大的输入验证，过滤潜在有害或操纵性提示
• • 上下文锁定：限制模型在任何时候可以访问多少对话历史或上下文
• • 提示工程：使用提示分隔来明确区分用户输入和系统提示
• • 增强过滤：分析整个输入上下文而非仅用户消息，以检测有害内容
• • 持续研究和改进：及时了解新的攻击向量和防御机制，对应用进行持续扫描发现新漏洞

引用链接

[1] How Do You Secure RAG Applications?: https://www.promptfoo.dev/blog/rag-architecture/[2] Context Injection Attacks on Large Language Models: https://arxiv.org/html/2405.20234v1