搜索
随着大模型在行业的落地，大模型逐步成为数智化系统的关键基础设施，其潜在的主体地位和应用广度，也带来了新的安全风险和安全挑战。企业研发和应用大模型的过程中，如何正确认识大模型的安全风险，更好的发现、评估和解决相应的安全问题，对于模型落地至关重要。
在不久前举办的 AICon 全球人工智能开发与应用大会上 360 智脑总裁张向征为我们带来了精彩专题演讲“大模型安全研究与实践”，演讲介绍大模型落地过程中的各类安全风险，然后从系统安全、内容安全、内容可信三个方面讲述遇到的技术挑战和研究进展，并结合不同场景给出大模型安全的解决方案。
内容亮点：
- 了解大模型落地过程中的各类安全风险
- 了解大模型安全技术挑战和研究进展
- 了解大模型安全解决方案
以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。
从去年到今年，我们已经看到大模型在多个行业中的应用，尤其是在面向消费者的产品和服务中。人们普遍认识到大模型为业务带来的积极影响，许多客户在购买大模型解决方案时，更倾向于关注它们如何帮助业务发展和解决用户问题。然而，对于大模型背后存在的潜在风险，人们的关注度似乎还不够。360 公司不仅涉足大模型领域，同时也是安全领域的领军企业，因此我们在大模型安全方面投入了相当的精力。今天，我希望能够分享我们在这一领域的一些工作成果。
大模型安全挑战
当我们谈论大模型时，我们往往关注的是模型本身，比如 ChatGPT、DeepSeek、360 智脑、文心一言、智谱 GLM、通义千问等不同的模型。但实际上，模型在提供服务时，背后是由一系列服务框架支持的，包括前端服务端使用的 cache、prompt 模板管理框架、底层应用市场等。在模型训练阶段，还会用到 Pytorch、Tensorflow 等基础服务框架。因此，大模型的安全不仅仅涉及模型本身或训练过程中的安全问题，还包括基础服务框架和模型应用过程中的潜在风险。
每个环节面临的安全风险都有所不同。在训练环节，我们需要关注数据资产的安全，比如是否存在数据泄露、原始数据是否被投毒或污染，以及是否存在隐私泄露的问题。在模型文件资产方面，我们还需要考虑模型是否会被窃取，以及是否存在模型投毒、逆向和对抗等问题。在最终的服务环节，用户信息资产的安全也至关重要，比如是否存在身份盗窃、隐私泄露、账号泄露等问题，以及数据是否被滥用。此外，我们还需要关注模型输出内容的合规性，以及是否被用于违规或违法的场景。
在 Huntr 平台上，我们对大模型相关的软件生态中的漏洞进行了统计分析。从 2023 年底到 2024 年底，我们收集了大量数据，发现其中与大模型生态链相关的漏洞超过 400 个，这些漏洞分布在 50 多个不同的仓库中。特别是 2024 年第二季度，漏洞数量激增至 225 个，显示出明显的上升趋势。这些漏洞类型多样，涉及的风险包括传统的目录穿越、不合理的权限控制以及跨站脚本攻击等。对于大模型本身，也存在模型服务攻击，包括能够调用后端 API 和执行后端代码的漏洞。
一个典型的案例是 ShadowRay 的漏洞，这个漏洞影响了 OpenAI 等公司使用的框架。如果使用的版本存在漏洞，攻击者可以远程控制公司的计算设备，泄露大量敏感信息，甚至公司的计算资源可能被用于其他恶意活动。据统计，受到感染的机器和计算能力的总价值接近 10 亿美元。
另一个例子是 Ollama 的漏洞，我自己也会在个人电脑上使用 Ollama 来玩一些开源模型，并在端侧验证效果。Ollama 在特定版本中存在漏洞，这些漏洞包括任意文件写入和远程代码执行。我们对 Ollama 的服务进行了网络资产探测，发现有几千个主机的服务暴露在公网且存在相关漏洞。这种服务的暴露意味着用户面临模型文件被远程替换、系统相关设置被篡改的风险，导致用户在处理敏感信息或文档时出现非预期结果或者数据泄漏。
不同的业务方面临着各自独特的问题和挑战。对于采购方来说，他们最关心的问题是他们所购买的智能服务是否安全。在很多情况下，他们可能没有进行充分的评估，也缺乏必要的安全评估手段。他们对安全漏洞可能带来的影响范围并不清晰，同时，合规性问题也是他们担忧的一个方面。安全部门同样面临挑战。他们需要检测大模型系统的安全性，但对新型漏洞的认知不足，检测技术也不完善。
随着大模型新框架和开源工具的出现，安全防护的压力越来越大。此外，新发现的漏洞可能需要时间来处理，这导致了响应速度的滞后。开发者在使用基础组件时也面临安全问题。他们可能会从网上获取模型或使用开源框架，如向量数据库、Langchain 等。但这些组件的安全性是否经过了充分的测试？上线后对内部业务可能产生的影响是否得到了评估？在很多情况下，这些问题的答案并不明确。此外，由于涉及的组件众多，修复成本也相对较高。
依据 TC260 国家标准，生成式人工智能服务安全的基本要求大致可以分为两大类：首先是内容安全。这涉及到人工智能服务是否违背了社会价值观，是否包含歧视性内容，是否存在商业违规或信息泄露等问题。在内容安全方面，一个重要的考虑是模型输出的内容是否可能带来负面影响。
例如，如果模型在智能客服或问答系统中提供了错误或不可靠的信息，可能会直接导致业务损失或产品可信度下降。其次是内容结果的可信度。这关系到模型输出结果的准确性和内容的可靠性。在关键业务场景中，如金融或医疗领域，模型的输出必须严格遵守行业规范和法律法规，以确保其建议或信息的合规性。
在第一类问题中，价值观错误是一个常见问题。许多模型在训练时可能基于开源数据或开源模型基座，而这些开源资源可能没有经过充分的数据过滤或安全性对齐，导致模型可能存在歧视、偏见或低俗违禁内容的风险。除了通用的价值观和违规问题，还有与特定行业业务场景紧密相关的安全性问题。例如，在金融领域，模型的输出必须合规，不能诱导用户使用或推荐某些金融产品。
这些规则在传统的大模型训练语料中可能无法学到，因此在业务场景中需要进行特别的安全对齐。此外还有提示注入攻击。攻击者可能会通过巧妙构造的提示语，诱导模型输出违规内容。例如，直接询问如何制造炸弹的问题，大多数模型不会回答，但如果将问题伪装成教育场景，模型可能会输出相关信息，从而绕过安全检测。
在第二类问题中，我们不得不提及所谓的“幻觉”问题，这通常分为两类：事实性幻觉和忠实性幻觉。事实性幻觉涉及到模型输出与现实不符的情况。例如，模型可能会错误地将《战狼 2》的上映年份从 2017 年说成 2014 年，或者错误地描述一个运动员在巴黎奥运会的成绩。
这些错误可能是由于模型没有及时更新知识库，或者未能准确遵循知识库内容导致的，从而产生了误导性的信息。忠实性幻觉则涉及到模型对输入信息的误解或错误总结。这可能表现为模型未能准确遵循指令，或者在生成摘要时引入了原文中不存在的信息，或者输出内容存在逻辑冲突。
这里讨论的安全问题主要集中在大模型在落地应用过程中，特别是在推理或提供服务时的风险。我们讨论的风险包括系统安全风险，如模型环境中的漏洞；生成恶意内容的风险，这主要涉及到价值观的对齐；生成错误信息的风险，这关乎内容的可信度；以及 Agent 流程失控的风险，尤其是在企业事业单位使用大模型进行内部业务系统调度时，如果模型具备访问或修改后台数据的权限，那么流程可能会存在失控风险。
大模型软件生态安全
我们关注的是大模型服务的整个生命周期，从上游到下游，涉及众多环节。我们可以将这些环节分为两大层次：应用服务组件和训练推理组件。服务组件层次涉及到我们对外提供服务时所依赖的一系列组件，如向量数据库、缓存系统、代码执行器等，训练推理组件涵盖模型训练和推理所依赖的平台和框架。它被进一步细分为四个子层次。
首先是用户层，这一层主要负责与用户的交互，包括前端 UI、提示工程以及缓存系统。其次是模型层，它包含了代码解释器、大模型本身以及依赖的向量库等关键组件。第三层是推理层，这一层主要涉及推理服务，如 Ollama，以及可能存在的隐私泄露风险和模型市场中潜在的恶意模型。最后是训练层，它涉及到底层的数据管理、OPS 平台、计算框架等基础设施。
在这些层次中，每个层级或组件都可能存在潜在风险，如跨站脚本攻击、代码执行漏洞等。为了应对这些风险，我们需要对大模型的上下游组件进行梳理，并建立一套系统的框架，以便分析和分层级或分环节地识别所有潜在风险。
传统安全漏洞
传统安全漏洞在大模型的应用中依然存在。一个例子是提示工程中的模板注入，这与 SQL 注入的概念相似。为了简化业务模板的配置，我们通常会使用提示工程管理框架，该框架允许我们将模板集中管理，并将用户输入作为变量实时替换。然而，如果模板框架本身存在安全漏洞，攻击者可能会注入恶意代码。当用户调用这些模板时，恶意代码可能会被执行，从而改变输出结果，使其与用户的实际指令不符。
另一个例子是向量数据库的拒绝服务（DoS）攻击。在智能客服和智能问答等应用场景中，大模型依赖于向量数据库来处理和检索信息。如果攻击者利用向量数据库的漏洞，如整型溢出或 GraphQL 注入错误，来使数据库无法正常工作，那么整个智能客服系统可能会因此而瘫痪，无法提供服务。
新型安全风险
大模型能够将自然语言转化为可执行的脚本或 SQL 代码，这一能力在处理计算任务时可能会出现错误，如简单的加减乘除运算。为了解决这一问题，一些实现手段采用了 PoT（Program of Thought）技术，将大模型的指令转换为简单的数学公式或代码，然后由后端执行器执行，这无疑带来了新的安全风险。以 AutoGen 为例，存在潜在的间接提示注入漏洞。模型可能会通过 URL 访问并获取内容，然后基于这些内容进行文本抽取和总结。攻击者可以在公开网址上注入诱导模型执行脚本指令的代码，绕过系统设置的指令要求。常见的防护手段可能仅对用户输入进行风险判别，但如果攻击指令隐藏在 URL 返回的信息中，这种防护手段就可能失效。
另一个典型案例是 Text2SQL，它可以通过自然语言生成 SQL 指令来获取数据库信息，甚至可能通过漏洞修改数据库内容，导致后续访问时输出被篡改的数据。
大模型的另一类信息安全风险是记忆投毒。为了降低计算成本和时延，系统可能会缓存用户问题和答案。如果缓存服务使用向量数据库或关键词召回等手段，攻击者可能会在用户问题中注入恶意指令，当新用户提出相似问题时，缓存的恶意内容可能被触发，导致输出恶意指令的结果。
此外，还有持久性的提示劫持风险，如 Ollama 漏洞所示。如果攻击者利用文件写入漏洞修改了系统提示词，那么无论用户提出什么问题，模型都可能被诱导输出恶意或有导向的内容。
大模型软件生态安全解决方案
大模型软件生态安全涉及众多环节的复杂系统。为了确保这一生态系统的安全性，我们采取了包括 RAG 和 Agent 方案在内的多种策略来增强底层防护能力。我们的检测技术基础广泛，涵盖了模糊测试、控制流分析和数据流分析等关键领域。这些技术从多个角度进行评估，包括数据安全、接口安全、配置安全以及业务安全。我们关注的风险类型不仅包括传统漏洞，也包括针对大模型的新型威胁。
检测对象全面，包括文件数据、模型、数据集、配置和代码，同时也涉及服务类型，尤其是常见的服务类型如 Agent 或 RAG 流程。对于这些服务，我们会对其上下游链路进行详细的检测和潜在攻击手段的探测，确保整个流程的安全性。特别是那些常见的开源代码库。我们会对这些库中的关键类别进行重点检测，以防止潜在的安全风险。
在行业场景中，安全性的考量并不局限于特定行业，而是与业务场景紧密相关，这包括业务场景所使用的工作流和组件依赖。这种全面的方法确保了我们能够为各种业务场景提供定制化的安全解决方案，从而保护大模型软件生态免受各种安全威胁。通过这种多层次、多角度的安全防护策略，我们能够为大模型的稳定运行和数据安全提供坚实的保障。
大模型内容安全
大模型内容安全防护方案
在大模型内容安全方面，我们面临着一系列挑战，这些挑战主要分布在四个关键环节。
- 在系统输入层面，早期的内容安全主要依赖关键词匹配和基于规则的方法，但这种方法在长文本场景下容易出现误判。去年大模型刚上线时，由于缺乏细致的内容安全防控方案，很多用户的输入被错误拒绝。随着时间的推移，我们引入了基于大模型的风险识别策略，显著降低了拒识率。
- 工具增强，我们采用了如 RAG 的方案，以权威内容为参考，提高输出结果的可靠性和价值观的准确性。
- 模型训练层面，我们专注于基础模型的原生安全增强，通过继续预训练，使用安全数据进行微调，以及强化学习，使模型更好地与人类价值观对齐。
- 系统输出层面，我们对输出结果进行新一轮的改写、探测和拦截，以确保内容的安全性。
通过一张简化的图，我们可以展示这个流程：最内层是模型的原生安全增强，中间层是知识增强，即模型在请求时参考更优质的语料库，最外层是内容的安全护栏，包括输入和输出层面的防护。
在 LLama 3 的验证中，我们观察到不同加固手段的效果变化。使用原始 LLama 3 8B 模型的得分大约是 78 分。经过安全数据集的预训练后，得分提升至 81 分。进一步的安全微调，使用更多安全语料的 QA 对，得分提升至 87 分。通过强化学习，得分提升至 93 分。使用全网优质语料库作为参照，得分接近 96 分，但要达到 100% 的安全仍然具有挑战。
在优化和检测手段上，我们采取了多种策略。首先是安全检测的大模型，这需要涵盖 TC260 国家标准中的 5 大类 31 小类，我们内部有十几个大类和超过 100 个小类，需要对这些细分类型进行分类标记，并根据不同业务场景和风险类型采取相应的处置手段。
训练过程中，数据是关键，包括用户日志、开源数据集、合作方数据集，以及内部红队攻击手段生成的恶意主题和语料，以提高风险数据的覆盖度。此外，我们还进行数据增强，利用大模型生成更多恶意问题，通过评测方式识别处理不当的情况，持续迭代优化模型的安全性。
安全回复大模型的训练
在构建安全回复的大模型时，训练和微调的方法与常规手段相似，但关键在于拥有优质的语料库。国内有官方媒体和权威网站提供的丰富优质语料，以及一些开源语料库，这些都是训练语料的宝贵资源。在安全的对齐阶段，我们会进行更细致的工作，重点在于标注和数据增强，包括红蓝对抗攻击的模拟，以增强模型的安全性。
我们内部研发了一个的攻击大模型，它主要用于辅助大模型的安全能力研发。这个模型通过使用恶意语料和黑语料进行增量训练、SFT 微调、强化训练对齐，能够生成潜在的风险问题。这种方法允许我们用恶意语料来测试大模型的输出，并使用评测大模型来挑选出处理不当的风险问题，然后将这些反馈用于下一轮的迭代，形成一个快速循环迭代的过程。
通过这种攻击大模型的方式，我们可以显著提高安全语料构建的效率。如果依靠安全运营人员手动标注，每天可能只能处理几百条语料，而使用攻击大模型进行筛选，每天可以处理上万条，效率提升了上百倍。这种方法不仅加快了安全语料的构建速度，也提高了模型训练的质量和效率，使得大模型在面对潜在的安全威胁时能够更加稳健和可靠。
大模型的检、防、攻、测体系
大模型的检、防、攻、测体系构成了一个完整的服务流程，这一流程通过四个关键组成部分来实现：安全检测大模型、安全回复大模型、攻击大模型和安全评测大模型。
安全检测大模型负责识别和评估输入内容的安全性，确保没有潜在的风险。安全回复大模型则针对识别出的风险问题，提供安全、合理的回答方案，以避免直接拒绝用户输入而影响用户体验。
攻击大模型和安全评测大模型则更多地用于大模型的迭代和优化过程。攻击大模型通过模拟恶意攻击，帮助识别和强化模型的弱点。安全评测大模型则对模型的安全性进行评估，确保其在各种情况下都能提供安全可靠的输出。
对于业务方来说，他们主要关心的是输入和输出的安全性。因此，他们可能只需要使用安全检测和安全回复大模型。这样，他们可以确保业务流程中的输入和输出内容是安全的，并且在遇到风险问题时，能够得到恰当的回答，从而维护用户体验。
对于那些致力于大模型迭代的企业来说，他们还需要利用攻击大模型和安全评测大模型来加速安全数据的标注和策略迭代，以提升运营效率。这意味着他们需要一个更为全面和动态的安全体系，以适应不断变化的安全需求。
在私有化部署的情况下，企业可能会获得静态的安全检测和安全回复大模型。为了进一步满足自身业务的需求，他们需要一个安全运营系统，这个系统能够管理词表、分析用户日志，并根据不同的风控类型和等级进行相应的处理和配置。这样的系统能够帮助企业在保持模型安全性的同时，也能够根据业务数据进行迭代和优化，确保大模型在实际应用中的有效性和安全性。
大模型幻觉检测
大模型幻觉问题主要分为两类：事实性幻觉和忠实性幻觉。事实性幻觉是指那些我们可以验证的事实不一致，例如电影《战狼 2》的上映年份或运动员的成绩，这些信息可以通过官方媒体的报道来确认。而捏造性幻觉则涉及那些无法查证的信息，我们难以判断其真实性。
为了判断幻觉的类型，我们首先需要确定用户的输入是否遵循了指令，以及这些指令是否与上下文信息一致。接着，我们要评估模型的回复是否正确，这包括代码的正确性、计算的准确性以及推理效果的合理性。代码的正确性可以通过编译器和自动化测试来验证，计算的准确性可以通过计算工具来检验，而推理效果则可能需要人工评估或大模型打分。
大模型幻觉解决方案
在解决大模型幻觉问题上，我们采取了一套完整的对齐方案。这包括在查询处理阶段对输入进行处理，利用工具增强，如代码解释器、搜索引擎增强，以及第三方数据接口来获取权威数据，避免幻觉的产生。RAG 增强专注于对非结构化知识的增强，同时在幻觉检测和训练环节也涉及到算法细节。在推理环节，我们采用多种手段，如让模型多次输出并进行投票校验，或使用多个模型进行校验。
我们内部开发的基于幻觉检测的 Agent，主要利用 RAG 手段，结合搜索引擎，使用全网信息进行校验和修改，专注于事实性幻觉。这个 Agent 的原子能力包括声明抽取、信息验证、证据判定和幻觉修正。如果发现与知识库信息冲突，幻觉修正模块会根据参考文档对输出进行修正，并将修正结果和验证结果积累为语料，用于后续模型训练和数据标注。
我们的架构在 query 处理阶段，会对原始 query 进行变换和处理，甚至进行多步搜索。在 rerank 阶段，我们需要对拆分后的 query 进行细致的数据标注和对齐，以优化排序算法。
在 SuperCLUE-RAG 的评测中，关注几个关键维度：拒答能力，即模型在没有明确答案时是否能够正确表示“不知道”；检测纠错能力，即模型是否能够针对用户输入进行必要的修正；信息整合能力，特别是在多文档场景下整合多个来源的信息；以及答案的及时性，即模型是否能够访问到最新的知识，避免时效性错误。
在真实的业务场景中，尤其是在搜索场景下，我们会遇到一些典型问题，比如医疗类问题的处理。在这些情况下，原始的医疗社区讨论可能包含错误信息，模型在第一轮总结时可能会继承这些错误。
为了提高答案的准确性，我们采取了一种更为细致的模型自我反思和自我修正的处理方法：首先，从文本中抽取出多个事实性的声明；然后，对这些声明进行新一轮的检索；最后，基于检索结果重新修正答案。这种方法能够有效地纠正中间的错误。
通过线上验证，我们发现这种细致校验和修改的方法显著提升了用户体验，大约增加了 32%。与简单地总结一段文本相比，我们的方法能够识别并修正大约 20% 的错误信息。这样的改进不仅提高了信息的准确性，也增强了用户对模型输出结果的信任，从而提升了整体的服务质量。
总结与展望
在本次分享中，我们主要关注了三类大模型应用中的风险问题：软件生态安全、内容安全以及幻觉问题。
软件生态安全分为四个层次：用户层、模型层、推理层和训练层。这些层次面临的风险既包括传统风险，也包括针对大模型的新型风险，如提示注入、NL2SQL、记忆投毒和提示劫持等。为了应对这些风险，我们内部开发了一套系统安全扫描解决方案，适用于 SaaS 化扫描和私有化部署，能够针对 RAG 或 Agent 中的链路进行扫描。
开发者需要关注代码实现的安全性，组件开发者应避免组件误用并定期更新以防止漏洞扩散。业务方应意识到大模型系统安全的风险，而安全研究人员则需要关注模型、代码、硬件、业务和具身智能等不同层级的安全问题。
内容安全防护体系包括四类模型和一个安全运营系统。这四类模型分别是风险检测模型、安全回复模型、攻击模型和安全评测模型。风险检测模型负责对请求进行分级和分类，安全回复模型针对有风险内容提供安全代答，攻击模型加速模型安全能力迭代，安全评测模型则进行内容巡查和开源模型对比。
原生安全增强需要在语料、训练、微调、强化等层级进行。内容安全护栏方案依赖于风险检测和安全回复能力，对输入输出进行修改。业务方除了关注模型业务能力评测外，还应关注安全评测。对于私有化模型，需要在内部业务场景中建立相应的安全解决方案。大模型解决方案提供方需要建立全流程的检防攻测体系，并构建特定安全语料。
在幻觉问题方面，我们区分了事实性幻觉和忠实性幻觉，并介绍了检测幻觉的原子化能力，如声明抽取和修正。解决方案重点是引入外部知识库，优化 query 理解和 rerank 技术。大模型提供方和业务方可以直接调用第三方搜索引擎，但需要注意语义完整性。
对于领域知识，需要自建领域知识库。大模型提供方应避免幻觉，特别是指令遵循和推理能力，以降低忠实性幻觉。许多大模型提供方已在平台和 API 接口上提供 RAG 构建方案，业务部门可以直接使用这些方案或补充自己的知识库。
随着大模型的广泛应用，它将成为基础设施，用户的输入和输出将越来越依赖于大模型。大模型也将成为中枢，调度其他第三方工具和内部系统平台接口。因此，安全是大模型应用的底线。构建安全可信的大模型应用不仅是模型提供方的责任，还需要业务方、组件开发方和安全研究人员的共同努力。我们期待大模型在未来能够越来越安全，避免业务场景中的安全风险，同时享受业务收益并规避潜在风险。
