大模型安全开发者手册——架构与信任边界

271 阅读24分钟

与依赖预定义算法和静态数据库的传统Web应用不同,大型语言模型(LLM)通过庞大的神经网络生成动态且语境感知的响应。这种范式转变带来了独特的安全挑战,与传统Web应用中遇到的问题大相径庭。尽管研究人员已经对Web应用及其漏洞进行了详尽研究,但LLM安全领域仍相对稚嫩。

本章旨在弥合这一知识差距,通过剖析LLM的基本元素,阐明其与传统技术的不同之处。我们将从AI、神经网络以及它们与大型语言模型的关系入手,然后深入探讨支撑当今大多数LLM的核心架构——Transformer模型。接着,我们会介绍各种由LLM驱动的应用,例如聊天机器人和代码助手。

然而,除了理解这些技术之外,安全专业人员还必须意识到LLM特有的新型信任边界。这些边界标志着应用中不同信任级别的区域,包括用户输入的提示、上传的内容、训练与测试数据、数据库、插件及其他我们将在本章稍后详细说明的边界系统。


人工智能、神经网络与大型语言模型:有什么不同?

“人工智能(AI)”、“神经网络”和“大型语言模型(LLM)”这些术语经常被混用,但它们分别代表了机器学习和计算智能领域的不同层面。为更好地理解它们在技术和安全中的独特角色,让我们逐一解析:

人工智能(AI)

人工智能本质上是一个多学科领域,旨在创建能够完成通常需要人类智能的任务的系统。这些任务包括问题解决、感知能力以及语言理解。AI涵盖了从基于规则的系统到机器学习算法的广泛技术和方法,是实现人工智能的各种路径的总称。需要注意的是,随着技术进步,人工智能的定义一直在变化,并在过去几十年中不断演进。

神经网络

神经网络是受人类大脑结构启发的一种AI技术。它们是一种计算模型,旨在识别模式并根据处理的数据做出决策。神经网络的复杂程度可以从简单的少层结构(浅层神经网络)到高度复杂的多层连接结构(深度神经网络)。它们是许多现代AI应用的核心,包括图像识别、自然语言处理和自动驾驶等领域。

大型语言模型(LLMs)

LLM是神经网络的一种特定类型,通常采用先进的神经网络形式(如Transformer模型)来分析和生成基于训练数据的文本。其显著特点在于其大规模性和专注于语言任务的能力,这些任务涵盖了从简单的文本补全到复杂的问答和摘要生成。


为什么区分这些概念很重要?

对安全专业人员而言,理解这些差异至关重要。从广义的AI技术到专门的LLM,每一层都会引入独特的漏洞,并需要专门的安全措施。在分析LLM的复杂性时,认识它们在更广泛的AI领域中的位置,对于讨论如何有效保护它们至关重要。

本书接下来的内容将以此为基础,深入探讨如何识别和缓解LLM的安全风险。让我们继续这个探索之旅!

Transformer革命:起源、影响与LLM的联系

Transformer架构是人工智能演进史上的一个重要里程碑,对AI领域,特别是大型语言模型(LLM),产生了深远的影响。让我们一起探索Transformer革命的故事——它从何而来,何时出现,以及它为AI和LLM带来的巨变。


Transformer的起源

Transformer架构首次出现在2017年由Ashish Vaswani等人发表的开创性论文《Attention Is All You Need》中。这篇论文提出了一种全新的自然语言处理(NLP)方法,摆脱了传统依赖递归神经网络(RNNs)和卷积神经网络(CNNs)的模型。Transformer的核心创新是自注意力机制(self-attention),它使模型能够衡量句子中不同单词的重要性,从而更有效地理解上下文。

在Transformer出现之前,神经网络领域虽充满希望,但常常难以实现其高远的目标。传统架构如RNNs和CNNs推动了AI能力的进步,但也存在固有局限性。这些局限性主要在于它们无法有效捕获和利用上下文,尤其是在自然语言理解中。

  • RNNs:虽然适合处理序列数据,但在处理长序列时难以维持上下文,表现出一种“短期记忆”问题,使其不擅长捕捉复杂的关系和长距离依赖。
  • CNNs:尽管在图像识别领域表现卓越,但在处理语言等需要理解单词和句子上下文的序列数据时力不从心。

这种对上下文理解的缺乏是传统神经网络的“阿喀琉斯之踵”。它们一次只能处理文本的局部内容,无法全面理解整体语义。这种局限类似于仅通过随机几句话试图理解整本小说的内容。这种能力差距限制了AI在自然语言理解中的实际应用,而Transformer架构的出现填补了这一空白,引发了一波进步浪潮,重新定义了AI驱动语言模型的格局。


Transformer架构对AI的影响

Transformer架构的推出不仅是NLP的里程碑,也是AI多个领域的范式转变。尽管研究人员最初使用Transformer架构解决文本理解和生成问题,但很快发现其能力远超文本处理。以下是Transformer架构产生重大影响的一些领域:

自然语言处理(NLP)

Transformer的首要影响自然是在NLP领域。Transformer模型现已成为翻译、摘要生成、问答、情感分析等语言任务的中坚力量。它们设立了新的性能基准,有时甚至在特定任务上超越了人类水平。

计算机视觉

Transformer架构在计算机视觉中的应用令人惊讶。尽管CNNs长期以来是图像处理任务的黄金标准,但基于Transformer的模型(如Vision Transformer, ViT)在图像分类、目标检测和分割等任务中表现出竞争力,甚至在某些情况下表现更为优异。

语音识别

Transformer架构的灵活性也使其在语音识别中表现出色。结合卷积层与Transformer层的混合模型(如Conformer),其在语音语言理解方面树立了新标杆。

自动驾驶与自主系统

Transformer在自动驾驶等自主系统中的应用令人着迷。这些车辆需要强大的上下文理解能力以确保安全导航,Transformer模型成为特斯拉等公司自动驾驶系统的核心技术。

医疗保健

在医疗领域,Transformer模型正在帮助完成从药物研发到医学图像分析的任务。它们能够处理并解释海量数据,从而加速研究进展,并可能提高诊断的准确性。


Transformer架构的革命性影响与安全挑战

Transformer架构的兴起掀起了AI多个领域的革命,不仅改变了一个领域,而是推动了多个领域的进步。然而,这种多功能性也为各种应用带来了独特的安全挑战。随着我们更深入地探讨LLM安全,Transformer架构的普及性使得我们必须采取多层次的方法来保护AI系统。

基于LLM的应用类型

两种常见的基于LLM的应用是聊天机器人(Chatbots)助手工具(Copilots) 。让我们简要了解它们,以帮助您理解开发者如何使用LLM以及各种架构选择的背景,为进一步学习奠定基础。


聊天机器人

聊天机器人是一种能够模拟与人类对话的计算机程序,常用于客服应用,帮助回答问题并支持客户服务。此外,聊天机器人在娱乐领域也表现出色,例如玩游戏或讲故事。第一章中的Tay是一个娱乐型聊天机器人的例子。以下是更多基于LLM的聊天机器人示例:

  • Sephora:帮助顾客找到适合其肤质和需求的产品。
  • H&M:帮助顾客找到符合其风格的衣服和配饰。
  • Domino’s Pizza:允许顾客通过X(Twitter)或Facebook Messenger点餐。
  • Fandango:帮助顾客查询电影时间和附近影院。
  • JetBlue Airways:回答顾客有关航班的问题。
  • Amtrak:帮助顾客订票、查看火车状态并回答相关问题。
  • 金州勇士队:帮助粉丝购买门票、了解即将举行的比赛以及获取球队新闻。

助手工具

助手工具是能够协助人类完成写作、编程和研究任务的AI系统。它们可以帮助用户生成创意、识别错误并改进工作成果。虽然助手工具尚在开发中,但它们有可能彻底改变我们的工作和学习方式。以下是一些基于LLM的助手工具示例:

  • GrammarlyProWritingAid:帮助用户改进写作,通过识别和纠正语法错误、提供风格改进建议以及反馈。
  • GitHub CopilotGoogle Gemini Code AssistAWS CodeWhisperer:帮助程序员更快、更高效地编写代码,生成代码建议、实现编程语言间的转换并帮助调试。
  • Microsoft 365 CopilotGoogle Workspace 的 Gemini:分别集成于微软和谷歌办公套件中的AI工具,帮助用户更高效地工作并激发创意。

注意
像ChatGPT这样的聊天机器人可以阅读和审查文本块,并提供改进建议。然而,使用Grammarly这样的助手工具处理这种特定任务的体验通常显著不同且优于聊天机器人。


聊天机器人和助手工具的相似点

  • 都是基于LLM的应用。
  • 都能生成文本。
  • 都可以协助人类完成任务。

聊天机器人和助手工具的区别

  • 聊天机器人模拟与人类的对话,而助手工具协助完成特定任务。
  • 聊天机器人通常用于客户服务应用,而助手工具用于写作、编程和研究应用。
  • 聊天机器人通常更具互动性,而助手工具更专注于完成任务。

在深入研究LLM架构的细节时,请记住这些概念。虽然两种应用类型共享类似的组件,但基于不同的安全考量,您可能会在实现这些组件时做出不同的决策。

LLM应用架构

开发者通常将LLM视为独立的实体,能够完成令人印象深刻的文本生成和理解任务。然而,在实际应用中,LLM很少是一个孤立的系统;它通常是构成智能应用复杂体系的一部分。这些应用由多个相互连接的组件组成,每个组件都对应用的整体功能和性能起着关键作用。无论是对话代理、自动内容生成工具,还是编程助手(Copilot),LLM通常与用户、数据库、API、网页甚至其他机器学习模型等各种元素交互。

理解这些复合系统的架构不仅是技术熟练度的问题,也是制定有效安全计划的关键。组件间的交互引入了多个信任和数据流层,定义了远离传统Web应用安全模型的新安全边界。例如,用户输入可能不仅仅是简单的文本字段,还可能包括语音命令、图像或实时协作编辑。类似地,LLM的输出可能被传递到其他系统进行进一步处理,这增加了潜在的漏洞和风险。

从本质上讲,LLM应用的整体视图超越了对语言模型本身的安全保护。它需要一种全面的方法,涵盖从数据获取和存储到模型服务和用户交互的整个架构的安全性。只有理解这些复杂性,才能制定出有效的策略,以保护这种复杂系统免受其固有的各种漏洞的威胁。

在本章中,我们将深入剖析LLM应用的各个典型组成部分,分析它们的角色,并探讨每个组件带来的独特安全挑战。这种理解将成为为LLM应用构建强大多层安全方案的基础。

图3-1展示了一个高度简化的示意图,用以说明使用LLM的应用中的组件、关系和数据流。后续章节将对这些领域进行详细探讨。

image.png

信任边界

在应用安全中,信任边界是一条无形但至关重要的分界线,用于区分不同组件或实体的可信度级别。这些边界标识出数据或控制流从一个信任级别过渡到另一个信任级别的区域,例如从用户控制的输入到内部处理的转换,或从安全的内部数据库到面向公众的API的过渡。这些边界如同安全检查点,开发者应在此严格应用安全措施,如身份验证、授权和数据验证,以防止漏洞的产生。

警告
理解信任边界对于威胁建模至关重要。正确定义并识别这些边界,可能决定一个系统是安全的还是易受威胁的。

图3-2在我们的架构图中添加了信任边界,以进一步说明它们的作用和位置。

image.png

这些边界,如图所示,充当了LLM与多种组件交互的入口——包括来自网络的公共数据、结构化数据库、用户的即时交互或内部的训练数据集。每个划定的边界都凸显了我们在考虑数据流入和流出LLM时需要注意的问题。以下是一个快速概述,我们将在下一节深入探讨:

用户交互

需要考虑如何保护模型免受用户或系统可能引入的对抗性或误导性输入的影响。同时,还需关注模型输出的有害、不准确或敏感数据被返回给用户的风险。

野外训练数据

LLM通常使用大量互联网数据进行训练。需要将这些数据视为不可信,特别要警惕潜在的有害内容、偏见和对抗性数据中毒,我们将在第7章详细讨论这些问题。

内部测试和训练数据

可以使用内部精心策划的数据对模型进行微调,从而显著提高模型的准确性。但需警惕可能摄取和暴露敏感、机密或个人身份信息的问题。我们将在第5章进一步讨论这一点。

外部服务

需要积极控制LLM与连接的服务(如数据库或API)之间的交互,防止未经授权的操作或数据泄露。我们将在第7章详细探讨这一主题。

公共数据访问

实时从网络中提取数据是一种增强应用功能的强大方式。然而,这些数据应被视为不可信,需防范诸如间接提示注入等问题,我们将在第4章中详细讨论。

关键点

每个点都可能成为潜在的漏洞,一旦忽视便可能被利用。在不断发展的LLM应用场景中,保护这些信任边界不仅是最佳实践,更是防止未经授权的数据访问、减轻数据篡改和避免系统入侵的必要措施。
认识到这些边界及其意义,是构建稳健LLM安全架构的基石。接下来,我们将对每个领域进行详细阐述,确保您具备足够的背景知识,深入了解后续章节中对风险领域和缓解措施的详细分析。

模型

语言模型是任何LLM应用的智力核心,负责接收数据、生成响应并推动交互。根据架构和需求,可以通过第三方服务提供的公共API与语言模型交互,也可以运行私有部署的模型。例如,可以从GitHub或Hugging Face下载Meta的强大Llama模型版本并在本地运行。

公共API:便利性与风险

使用公共API访问语言模型具有便利性且前期成本较低。第三方会负责管理和更新这些模型,从而降低组织的资源负担。然而,这种方式的权衡在于更高的数据泄露风险。当向第三方模型发送请求时,数据会跨越信任边界,从您的安全网络传输到外部系统。这一过程可能导致数据保密性问题,并且根据第三方的安全措施,可能增加遭遇数据泄露的风险。

私有部署模型:更大的控制权与不同的风险

选择私有部署模型可以让您更好地控制数据,严格管理信任边界,同时根据需求对模型进行定制或微调。然而,运行私有部署模型也带来一系列挑战,例如维护、更新以及确保模型本身没有漏洞——这实质上暴露在供应链风险之下。如果使用开源模型,确保模型的来源和完整性尤为重要,以避免嵌入的漏洞或偏见。

风险考量

以下是一些与模型选择及其部署位置相关的安全考量:

  • 敏感数据暴露
    公共API可能增加敏感信息暴露的风险,而私有部署模型提供更好的控制,但需要强大的内部安全措施。
  • 供应链风险
    模型的来源至关重要,无论是经过严格审查的公共服务还是开源下载。被破坏的模型可能为您的应用引入漏洞,成为攻击的后门。我们将在第9章深入探讨这一点。

选择考量

通过仔细考虑模型的托管环境,可以更好地评估与敏感数据暴露和供应链漏洞相关的权衡与风险。这些考量将指导您建立适当的信任边界和安全协议,以适应所选模型架构的需求。

用户交互

虽然用户输入表面上看是从用户到应用的一种单向信息流,但在LLM应用的背景下,实际情况通常更复杂。用户交互不仅包括从用户接收输入,还包括将输出返回给用户。这种双向交互是创造一个吸引人且实用的用户体验的基础,但同时也引入了更复杂的安全风险。

提示词是用户交互的重要组成部分。提示词不仅仅是信息请求,还起到指导用户如何与LLM交互的作用。精心设计的提示词可以引导模型提供有价值且准确的信息,而模糊或构造不当的提示词可能导致输出不清晰甚至误导性内容。因此,提示词管理成为应用安全的关键。例如,恶意用户可能通过精心设计的提示词欺骗模型泄露不应公开的信息,或生成有害内容。在第1章中提到的案例“Tay”,她正是因为4chan黑客利用提示词误导而陷入困境。

鉴于这种双向交互的重要性,保护输入和输出同样至关重要。在输入方面,输入验证、数据清理和速率限制等措施对于防范注入攻击等漏洞至关重要。在输出方面,确保模型的响应经过适当过滤,并防止应用泄露敏感信息同样重要。LLM的性质使得这一点比传统应用更具挑战性,我们将在本书后续部分探讨更多相关技术。

这种与用户的交互层在应用架构中形成了一个关键的信任边界。无论是输入还是输出,跨越这一边界的数据都需要仔细管理以避免安全风险。额外的保护层包括对敏感输出使用加密,以及通过实时监控标记潜在的有害或敏感数据流动。我们将在第7章中更详细地讨论这些内容。


训练数据

训练数据是LLM构建其理解和能力的基石。无论用于初始训练还是后续微调,数据的性质和来源对模型的性能和安全性都有重要影响。其中一个关键的区别是数据是内部来源的还是从公共或外部来源(“野外数据”)收集的。

内部生成或策划的数据
在组织内部生成或策划的数据通常比公共来源的数据经过更严格的审查。这些数据往往与应用的特定需求或用例对齐,因此通常更可靠和相关。受控的环境还允许更好地实施安全措施,如加密、访问控制和审计。然而,这些数据可能包含敏感或专有信息,其信任边界与内部安全协议密切相关。如果此级别的安全措施出现漏洞,可能导致数据泄露或训练集被破坏。

公共来源或“野外”数据
来自公共存储库或“野外”的数据则带来了不同的挑战。虽然这些数据可以提供多样性和规模,但其可靠性和安全性通常无法保证。这些数据可能包含误导性信息、偏见或恶意输入,从而危及模型。这里的信任边界更加脆弱,延伸到生成或托管这些数据的外部实体:需要严格的过滤、验证和持续监控来减轻风险和漏洞。正如我们在第1章中看到的,Tay直接将用户提示词作为训练数据的一部分,结果有害提示词的残余成为她知识库的一部分,随后输出了有害内容。接受未过滤、不可信的用户输入到训练数据集中,是未能管理这一关键安全边界的最简单示例。

无论是内部来源还是公共数据,信任边界的概念都至关重要。对于内部来源的数据,边界通常在组织的控制环境内,更容易实施安全措施。而使用外部数据则实际上将信任边界扩展到那些外部来源,这些来源可能不符合您的安全标准。使用外部数据进行训练需要额外的验证和安全检查,以确保未经审查的数据不会破坏LLM应用的完整性或安全性。

了解训练数据的来源、相关的信任边界及其安全影响,对于保护您的LLM应用至关重要。必须制定全面的数据治理政策,以管理训练数据的生命周期,无论其来源如何。

访问实时外部数据源

实时外部数据源为LLM应用带来了新的维度,使其能够提供实时信息、上下文,甚至与第三方的集成。尽管访问实时外部数据可以增强用户体验和功能范围,但它也为应用的安全架构引入了新的复杂性。

例如,截至本章撰写时,OpenAI 的 ChatGPT 无法直接访问实时网络数据,因此仅限于使用其较早训练数据中的信息。另一方面,Google 的 Bard(现称为 Gemini)在测试中可以访问实时互联网数据。因此,尽管 GPT-4 模型在推理能力上无疑更强,但在许多基本任务上却不如 Bard 表现出色。图 3-3 展示了与 ChatGPT 的一次交互,图 3-4 则展示了与 Bard 的同一交互

image.png

image.png

访问外部数据源(如网站、API 或第三方数据库)虽具有优势,但也可能使应用暴露于潜在风险之中。从受损网站摄取虚假或有害信息,到成为传播恶意软件或未经授权数据访问的通道,摄取不可信外部数据源的风险多种多样。这些数据源的不可信特性使它们比内部资源更难以控制,从而增加了不确定性和风险的层次。

在访问公共互联网数据时,信任边界的概念尤为重要。与可以统一实施安全措施的内部服务不同,外部数据源可能遵循与您的组织安全标准不同的规范。这种信任差异需要额外的验证、安全检查和监控层,以确保跨越该边界的数据不会危及系统安全。


访问内部服务

内部服务(如数据库和内部 API)通常是 LLM 应用的后端支持结构。这些服务可能存储关键数据,包括用户资料、日志、配置设置,甚至在 SQL 或向量数据库中存储的大量数据。作为系统中经常与其他内部或外部元素交互的组成部分,内部服务在功能和安全方面都代表了应用架构中的关键点。

这些服务通常在组织的受控环境中运行,使得安全策略可以得到一致的应用。然而,仅因为这些服务是内部的,并不意味着可以放松警惕。它们同样容易受到多种威胁,包括未经授权的访问、数据泄露以及来自组织内部的威胁。

内部服务(如数据库、专有 API 和后端系统)往往构成 LLM 应用的操作支柱。这些资源通常位于组织的安全网络内,提供了比外部服务更高的信任和控制。然而,这种内部性质可能反而会放大安全风险,特别是当这些服务存储着组织的核心敏感数据或关键资产时。

确保对这些内部服务的严格保护,包括权限管理、审计和持续监控,是防止安全问题的关键。

总结

保护 LLM 应用程序是一项充满复杂性和挑战的任务,其难点显著不同于传统的 Web 应用程序。本章旨在为应对这一复杂领域提供基础知识,重点围绕以下三个关键领域展开:区分人工智能、神经网络和大型语言模型;理解 Transformer 架构的核心作用;深入探讨 LLM 应用架构,尤其是信任边界的概念。

了解 LLM 的独特之处,可以帮助我们更有效地定制安全策略,超越一般的人工智能或机器学习框架,为 LLM 应用的特殊需求提供有针对性的保护措施。