如何保障RAG应用的安全？

Promptfoo熊猫伸手去拿伟大的知识之球，也就是向量数据库。

在我们之前的博客文章中，我们讨论了基础模型的安全风险。在这篇文章中，我们将探讨关于微调模型和部署RAG架构的担忧。

创建像Llama 3.2、Claude Opus或gpt-4o这样复杂的LLM是多年工作和数百万美元计算能力的结晶。大多数企业会战略性地选择基础模型，而不是从头开始创建自己的LLM。这些模型就像可以被系统架构和提示工程塑造成业务需求的粘土。一旦选择了基础模型，下一步就是确定如何应用该模型以及在哪里可以使用专有数据来增强它。

为什么知识截止点很重要

正如我们在之前的博客文章中提到的，基础模型是在大量数据上训练的，这些数据决定了模型的表现。这些训练数据也会影响LLM的事实回忆能力，即LLM访问和再现存储在其参数中的事实知识的过程。

虽然LLM可能基于其训练数据包含广泛的知识，但总有一个知识截止点。基础模型提供者可能会在模型卡片中披露这一点以保持透明。例如，Llama 3.2的模型卡片指出其知识截止点是2023年8月。问基础模型一个关于2023年9月事件的问题，它根本不会知道（尽管它可能会产生幻觉以提供帮助）。

我们可以通过向ChatGPT询问历史问题与今天的时事问题来了解这一点。

在这个回答中，gpt-4o基于其神经网络权重中编码的信息再现了事实知识。然而，输出的准确性可能会因提示和模型中的任何训练偏差而广泛变化，从而损害LLM事实回忆的可靠性。由于无法“引用”LLM生成回答所使用的来源，你不能仅仅依赖基础模型的输出作为唯一的事实来源。

换句话说，当基础模型产生事实知识时，你需要带着怀疑的态度去接受。信任，但要验证。

当您询问模型关于最近事件的问题时，可以看到基础模型的知识截止点的一个例子。在下面的例子中，我们问ChatGPT关于最新的通货膨胀新闻。你可以看到模型完成了一个功能，它搜索网络并总结结果。

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

虽然基础模型有其优势，但它们在特定领域任务和实时分析中的实用性也有限。希望利用LLM与专有数据或外部来源的企业将需要确定他们是否要微调模型和/或部署RAG架构。以下是每种选项的高级概述。

	对输出高度依赖提示工程	在特定领域任务中性能提升	实时检索可引用的来源	减少事实回忆中的幻觉风险
基础模型	✅
微调模型		✅		✅
检索增强生成	✅	✅	✅	✅

微调的案例

在某些情况下，微调模型是最合理的选择。通过在更小、更有针对性的数据集上进行训练，微调可以提升大型语言模型（LLM）在特定领域任务上的表现。结果是，模型的权重将被调整以优化在该任务上的性能，从而提高LLM的准确性和相关性，同时保持模型的通用知识。

想象一下，你的LLM从大学毕业，记住了所有大学课程的知识。微调就相当于让你的LLM去攻读硕士学位。它将记住大二时的微积分I的所有内容，但现在它能够回答在代数拓扑和概率论硕士课程中遇到的问题。

当从业者希望用一个静态的知识库来增强基础模型时，微调策略最为成功。这在医学等领域特别有用，因为这些领域拥有广泛而深入的知识库。在2024年4月发表的一篇研究论文中，研究人员观察到，与基础模型相比，经过微调的模型在医学知识方面的表现有了显著提升。

在这里我们可以看到，全参数微调模型在大学生物学、大学医学、医学遗传学和专业医学方面的MMLU表现有所提升。

一个经过医学知识训练的微调模型可能对科学家和医学生特别有帮助。但是，当医院的临床医生在治疗她的病人时，如何利用一个微调模型呢？这就是大型语言模型应用从检索增强生成（RAG）中受益的地方。

检索增强生成的案例

本质上，检索增强生成（RAG）是一个框架，旨在通过整合外部知识源来增强LLM的能力。简单来说，基于RAG的架构通过在提示中提供额外的上下文来增强LLM的响应。可以把它想象成在电子邮件中附加一个文件。

没有RAG的情况下，一个基本的聊天机器人流程会是这样的。

有了RAG，流程可能会是这样：

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

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

答案在于可扩展性和访问性。单个用户可以从他的本地存储中检索一个PDF，并将其附加到查询中发送给像ChatGPT这样的LLM。但RAG的美丽之处在于连接异构且庞大的数据源，这些数据源可以为用户提供强大的上下文——即使用户没有直接访问该数据源的权限。

假设你为家里购买了一个智能恒温器，但在设置时遇到了麻烦。你联系了一个支持聊天机器人，询问它如何帮助你，但当聊天机器人询问型号时，你真的不知道。收据和恒温器盒子早已被回收，而且你特别懒，不想检查设备以找到型号。

当你提供联系方式时，聊天机器人检索到你购买的恒温器的详细信息，包括购买日期和型号。然后，利用这些信息，它通过总结用户手册中的材料，甚至从其他客户已解决的类似支持票中提取解决方案，帮助你解决你的问题。

幕后是一个精心实施的RAG框架。

RAG编排的关键组件

一个RAG框架将由多个关键组件组成。

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

好的，我们已经对RAG框架如何工作有了大致的了解，但可能导致安全问题的配置错误有哪些呢？

RAG架构的安全关注点

适当的认证和授权流程

根据您的LLM应用程序的使用场景，您可能需要要求认证。从安全角度来看，这有两个主要好处：

• 强化问责和日志记录
• 部分缓解钱包拒绝（DoW）和服务拒绝（DoS）的风险

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

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

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

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

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

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

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

永远不要信任用户

您应该假设存储在向量数据库中的任何内容都可以通过LLM检索并返回给用户。只要有可能，您永远不应该在向量数据库中索引个人身份信息（PII）或敏感数据。

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

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

可能出错的地方？

在没有授权流程的基于RAG的LLM应用程序中，用户可以访问他们想要的任何信息。在某些用例中，这可能是有意义的，例如仅用于帮助用户浏览帮助中心文章的聊天机器人。

然而，如果您正在部署多租户应用程序或暴露敏感数据，如PII或PHI，那么正确的RAG实现至关重要。

在传统的渗透测试中，我们可以通过创建租户、实体和用户的映射来测试授权流程。然后我们会针对这些实体进行测试，看看我们是否能够与本不应交互的资源进行交互。我们理论上可以为单个注入点——LLM端点内的RAG架构创建相同的矩阵进行测试。

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

提示注入

使用RAG的LLM应用程序仍然容易受到提示注入和越狱攻击。如果LLM应用程序依赖系统提示来限制LLM输出，那么LLM应用程序仍然可能容易受到传统的提示注入和越狱攻击。 这些漏洞可以通过精细的提示工程以及输入和输出的内容防护措施来缓解。

上下文注入

上下文注入攻击涉及操纵提供给大型语言模型（LLM）的输入或上下文，以改变其行为或输出，使其产生非预期的结果。通过精心设计提示或注入误导性内容，攻击者可以迫使LLM生成不当或有害的内容。

上下文注入攻击类似于提示注入，但恶意内容被插入到检索的上下文中，而不是用户输入中。有一些优秀的研究论文详细介绍了上下文注入技术。

数据中毒

在某些情况下，用户可能能够将文件上传到LLM应用程序中，这些文件随后会被其他用户检索。当上传的数据存储在向量数据库中时，它会与可信数据混合，变得难以区分。如果用户有权上传数据，那么就存在一个攻击向量，即数据可能被污染，从而导致LLM生成不准确或误导性的信息。

敏感数据泄露

LLM应用程序与其他任何应用程序一样，存在相同的授权配置错误风险。在Web应用程序中，我们可以通过使用单独的会话Cookie或头进行交叉测试操作，或尝试通过IDOR攻击检索未经授权的信息来测试授权漏洞。对于LLM，检索未经授权敏感数据的注入点是提示。测试基于用户访问和对象属性的对象是否具有强大的访问控制至关重要。

可以实施内容防护措施，限制个人身份信息（PII）或个人健康信息（PHI）等敏感数据的暴露。然而，依赖内容防护措施来限制输出中返回PII是一个单点故障。与WAF类似，内容防护措施可以通过独特的负载或技术绕过。因此，强烈建议在接触向量数据库之前清除所有PII，并强制执行内容防护措施。我们将在后续文章中讨论实施内容防护措施。

上下文窗口溢出

所有LLM都有一个上下文窗口，类似于其工作记忆。它决定了模型可以利用多少先前的上下文来生成连贯且相关的响应。对于应用程序，上下文窗口必须足够大，以容纳以下内容：

1. 系统指令
2. 检索的上下文
3. 用户输入
4. 生成的输出

缓解RAG的控制措施

通过用无关信息超载上下文窗口，攻击者可以挤出重要上下文或指令。因此，LLM可能会“忘记”其指令并失控。

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

缓解RAG的控制措施

通过精心实施和设计安全的控制措施，使用RAG框架的LLM应用程序可以产生非凡的结果。

您可以通过运行Promptfoo红队评估来获得对LLM应用程序风险的基本理解，该评估配置为您的RAG环境。一旦您了解了应用程序中存在的漏洞，就可以实施多种控制措施，使用户能够安全地与LLM应用程序交互。

1. 输入和输出验证与净化：实施强大的输入验证，过滤掉潜在的有害或操纵性提示
2. 上下文锁定：限制模型在任何给定时间可以访问的对话历史或上下文量
3. 提示工程：使用提示分隔符清晰地区分用户输入与系统提示
4. 增强过滤：分析整个输入上下文，而不仅仅是用户消息，以检测有害内容
5. 持续研究和改进：及时了解新的攻击向量和防御机制，并持续扫描您的LLM应用程序以识别新漏洞

在我们的下一篇博客文章中，我们将探讨AI代理的激动人心的世界以及如何防止它们失控。祝您提示愉快！