大模型安全评估与防护实操指南：从资产盘点、Garak 扫描到配置落地

简介：安全牛发布的《人工智能大模型安全评估与防护技术应用指南》是一份面向大模型研发、安全评估与运营人员的系统性技术文档，重点解决模型全生命周期中的安全风险识别、量化评估与防护落地问题。文档从数据、算法、模型、服务、应用五个维度拆解威胁传导链，覆盖提示注入、越狱、对抗样本等典型攻击范式，并给出红蓝对抗演练框架、三级安全评估体系、大模型安全运营中心建设规范，以及国密算法、可信执行环境等国产化与安全基础设施适配方案，同时引用多项国家及行业标准条款，便于合规审计与追溯。资源为单个PDF文件，大小约25.31MB，内容紧凑、结构清晰，适合作为企业安全基线建设、模型上线前评估和安全运营体系设计的参考手册。目前已有123人学习下载。

1. 模型上线前不做安全评估，等于把门钥匙挂在门口

很多团队把 AI 大模型跑通的那一刻当成分水岭：Demo 演示效果惊艳，业务方点头，服务上线。结果一周之后，有人在聊天框里输入一段精心构造的文本，模型就乖乖吐出了内部知识库里的合同摘要；还有人用几句"角色扮演"就绕过了系统设定，让模型以客服身份承诺不存在的退款。这不是段子，是把大模型直接暴露在真实流量里的常见翻车现场。安全牛这份《AI大模型安全评估与防护技术应用指南》pdf 解决的就是这个问题：在模型上线之前和运行期间，系统性地评估它会被怎么攻击、会泄露什么、能扛住多大强度，再把防护手段落到可执行的配置上。适合 AI 应用开发、模型运维、安全合规岗位的人读，也适合那些已经在做本地部署、正被"模型为什么这么容易被套话"困扰的工程师。它不教你怎么训模型，教你怎么给模型上锁、试锁、换锁。

2. 先拆清楚评估对象和威胁边界：不知道防什么，就谈不上怎么防

2.1 评估对象不止"模型权重"：资产边界先画清楚

我第一次给客户做评估时，客户负责人指着 GPU 服务器说"模型就在那儿，你测吧"。真开始做才发现，大模型安全评估的评估对象是一个链条，权重文件只是其中一环。

常见做法是把资产分成五类：模型文件本身（权重、分词器、配置文件）、推理服务（API 端点、本地推理脚本、部署框架如 vLLM 或 llama.cpp）、提示词模板与系统设定（就是常说的 System Prompt）、外部数据通路（RAG 知识库、向量数据库、联网检索插件、工具调用）、训练与微调数据（如果模型是自训或微调的）。每一类资产都是攻击面。

这份指南给我的一个关键提醒是：评估的入口不是"找个越狱测试集跑一遍"，而是资产盘点。很多团队把精力花在收集对抗样本上，结果是项目都做完了，才发现生产环境里真正暴露的是第三方工具调用的 API Key——和模型本身半毛钱关系没有。资产边界画不清楚，后面所有结论都是空中楼阁。

做资产盘点时我一般会问三句话：这个模型跑在哪里，谁能碰到它，它出去能碰到谁。谁能碰到它决定了威胁面；它出去能碰到谁决定了数据泄露的上限。比如同样一个 7B 模型，纯本地推理和应用接入了联网搜索工具，两者的评估重点完全不同，后者要额外测工具调用链上的权限边界。资产清单一列出来，评估用例的优先级自然就出来了。

2.2 威胁模型：攻击者想从模型里拿什么，决定用例怎么写

资产盘点回答"有什么"，威胁模型回答"怕什么"。大模型安全评估不能只拿着公开的越狱样例库跑一遍，更常见的问题是把"攻击者目标"翻译成本场景的威胁条目。指南里把威胁分成四类，我个人觉得这个分类足够落地：

数据泄露是最高频的。攻击者通过提示注入让模型把系统设定、训练数据里的个人信息、知识库里的保密文档吐出来。注意这里不只是"用户问敏感问题"，而是模型本身被诱导越过权限边界。

指令注入与越狱是通道。经典手法是 DAN 式角色扮演、假设性场景、多语言编码绕过、Base64 混淆等。到了 2025 年，单纯的"忽略之前所有指令"已经不够看，攻击者更常用的是把恶意指令藏在工具返回内容或长文档里，这叫间接提示注入。

模型滥用被很多团队忽略。模型被用来生成钓鱼文案、批量制造虚假评论、自动翻写恶意代码。这类威胁不偷数据，但让模型沦为攻击工具，合规和舆情风险很高。

供应链投毒最隐蔽。开源模型在 Hugging Face 这类平台上的权重被替换、微调数据集里埋触发词、依赖库被供应链攻击。评估时通常要核对模型文件的哈希值，并对微调数据做敏感词扫描。

把这四类威胁映射到评估用例上，逻辑就清楚了：数据泄露对应"信息提取类用例"，指令注入对应"鲁棒性攻击类用例"，模型滥用对应"内容安全基准类用例"，供应链投毒对应"文件完整性校验"。我一般按这个映射搭一个用例矩阵，每一类至少覆盖三类手法，而不是东拼西凑在网上找一堆 Prompt 乱测。

3. 照做的评估流程：从资产清单到风险报告的五个步骤

3.1 资产盘点与分级：先给每个模型贴标签

评估流程的第一步不是跑代码，而是把第 2 章盘出来的资产做成一张分级表。我通常按三个维度打分：数据敏感度（模型能接触到的最高敏感级数据）、暴露面（对外 API、内网服务、离线单机）、业务影响（挂了/泄露了会造成什么损失）。三个维度都是高，就标记为 P0 优先级，先评估、重点评估。

这个环节不涉及任何技术参数，但最容易翻车。翻车点有两个：一是只盘了模型和推理服务，漏掉 RAG 知识库和工具调用；二是分级时只按"是否公网暴露"分，没按数据敏感度分。我见过一个内网模型，表面上看暴露面很小，但它连着包含上万条客户手机号的知识库，内部员工都能访问，数据敏感度极高，实际风险比对外 API 还大。

分级完成后，产出一张表：资产名、类型、位置、敏感等级、暴露面、风险优先级。这张表既是评估的输入，也是后续整改验收的基线。指南里没有给统一模板，但按这个思路做下来，评审会上至少能说清楚"为什么先测这个模型而不是那个"。

3.2 搭评估环境：本地跑还是云端跑，参数差在哪

评估环境的选择直接影响结论可信度。这里有个常常被忽略的问题：你评估的是"模型本身"还是"你部署的这套服务"。如果目标是前者，就在隔离环境里直接加载模型权重测；如果目标是后者，就必须连推理服务的鉴权、注入、限流一并测。

我一般优先用本地隔离环境跑，原因很朴素：可重复。云端 API 服务可能随时调整版本、过滤规则，测试结果难以复现。本地环境里常见的硬件情况是 32G 内存的机器想跑 7B 或 14B 量化模型做评估——从热词看这也是很多人在搜的问题。这里直接给结论：32G 内存能装，但能不能跑得动取决于两个参数，量化位数和上下文长度。

以 llama.cpp 的服务端为例，最常见的启动参数是-c控制上下文长度、--mlock锁定内存防止被换出。7B 模型 Q4_K_M 量化后权重约 4.4GB，但 KV Cache 会随上下文长度增长：-c 2048大约占用 2-3GB，-c 8192就要 8GB 以上。32G 内存跑 7B 是够的，但别同时开十几个并发会话，否则内存和 CPU 都会被打满。跑评估时我建议把上下文调低到 2048 或 4096，不是测模型能力，而是避免内存溢出干扰评估进程——这是血泪经验。如果你用 GPU 评估，记得看显存带宽；很多入门卡跑 14B 模型时瓶颈不在显存容量，而在带宽，一个单轮对话能等半分钟。

3.3 执行用例：用开源评估工具跑一组最小可复现命令

资产和环境就绪后，进入实际执行环节。常见做法是引入开源评估框架，以 Garak 和 PyRIT 这类工具为代表。下面以 Garak 为例跑一组最小命令，这套流程可以照抄，但参数要根据模型路径调整：

# 安装评估框架（Python 3.10+） pip install garak # 扫描模型能加载的最小配置，先确认服务可用 garak --model_type huggingface --model_name /data/models/qwen2.5-7b-instruct-q4_k_m.gguf # 跑针对性探测：提示注入 + 越狱 + 数据泄露三类各 10 个用例 garak --model_type huggingface \ --model_name /data/models/qwen2.5-7b-instruct-q4_k_m.gguf \ --probes promptinject,dan,dialogues \ --max_requests 50

这个命令的逻辑是：先加载本地量化模型，再按探测器（probes）分组跑对抗用例。promptinject是提示注入探测器，dan是越狱探测器，dialogues覆盖多轮对话下的越狱场景。--max_requests 50是总请求上限，防止某类用例卡死把评估时间拖到不可控。跑完会在输出目录生成一份报告，包含每个用例的成功率、平均响应延迟和被击穿的样本。

说明一下为什么用 50 这个量级：真实评估的用例量级通常是几百到几千条，但第一次摸底不需要跑满，先用 50 条验证评估链路本身没问题，再按需扩大。如果直接上万条用例压上去，遇到模型服务不稳定或内存溢出，你分不清是模型安全问题还是评估环境问题。参数调整的逻辑就是这样：小步快跑，先通链路，再放大规模。

3.4 结果判读与风险定级：同一个失败，不同定级

评估工具会输出成功率，但成功率本身不能直接用于决策。比如一个越狱用例成功率达到 30%，这听起来很严重，但要看被打穿的是什么内容。如果被打穿的是"模型回答了一句带玩笑性质的负面评价"，和被打穿的是"模型吐出了知识库里的客户身份证号"，风险定级完全不同。

我一般把结果分成三级。严重：模型泄露了明确敏感信息（身份证、密钥、未公开业务数据），或无需复杂构造即可绕过核心安全设定。高危：模型在特定诱导下输出违规内容或内部提示词，但需要多轮构造。一般：模型偶尔输出边界性内容，但核心设定未被突破。分级之后再决定整改优先级。

这里有个值得注意的坑：不要只看自动判定的成功率，要人工抽看被标记为"失败"（即模型成功抵御攻击）的样本。我遇到过自动评估工具把模型回答"我不能提供这个信息"判定为命中，但实际在这个场景里"拒答"本身就是业务不可接受的失败——一个客服模型如果对普通问题一律拒答，安全是安全了，业务也死了。所以结果判读一定要回到业务场景里做人工复核，安全评估的产出不是一堆数字，而是"哪里会被打穿、打穿后损失是什么、需不需要堵"的明确结论。

4. 防护配置实操：评估出问题之后，具体改哪些参数

4.1 输入侧：提示注入检测，先加一层不问模型的过滤器

评估发现的注入问题，最常见的整改手段是在模型前面加一层输入检测。这层检测不该依赖模型自己判断"我是不是被攻击了"，因为大模型天然容易被提示词带偏。常见做法是用独立的分类模型或规则引擎对用户输入打标。

我习惯用一套轻量规则加分类模型的组合，规则负责低延迟拦截，分类模型负责兜底。规则层主要匹配典型注入范式：要求忽略设定、要求扮演其他角色、包含 Base64 或十六进制编码指令等。分类模型则用一个小型序列分类模型判断输入是否含恶意意图。

# 输入侧提示注入检测的最小实现（伪代码） import re INJECTION_PATTERNS = [ r"忽略(之前|以上|所有).{0,20}(指令|设定)", r"system\s*prompt", r"你现在(是|扮演).{0,20}不受", r"64|base64|hex.{0,10}(解码|编码)", ] def detect_injection(user_input: str) -> tuple[bool, float]: matched = [p for p in INJECTION_PATTERNS if re.search(p, user_input, re.I)] if matched: return True, 0.95 # 这里接一个独立分类模型，输出恶意概率 prob = classify_injection_model.predict(user_input) return prob > 0.8, prob

这段逻辑很简单：正则层先扫一眼，命中直接判高风险并入隔离会话；未命中再交给分类模型。注意这里prob > 0.8的阈值是调出来的，不是拍脑袋定的。阈值太低会把正常业务请求拦掉，太高又拦不住注入。落地时我通常先跑一批线上真实请求做误报率统计，目标是让误报率低于 1%，再上线拦截策略。

输入侧防护有一个容易被忽略的点：检测对象不只是用户输入的第一句话，也包括多轮上下文。很多注入攻击是分步的，第一轮建立"假设场景"，第二轮才夹带恶意指令。所以检测模块读到的应该是整个会话的拼接文本，而不只是本轮消息。否则你等于只装了半扇门。

4.2 输出侧：敏感信息过滤，给模型加一张"嘴"

输入侧拦不住的部分，输出侧要兜底。输出侧的核心是敏感信息过滤器，它跑在模型生成结果之后、返回给用户之前。这里的参数主要在两方面：敏感信息类型清单和脱敏阈值。

类型清单包括手机号、身份证号、银行卡号、IP 地址、内部主机名、API Key 等。很多团队只做手机号和身份证，漏了 API Key 和内部主机名——后者才是真实泄露事故里最常出现的。模型在越狱成功后吐出知识库里的内容时，往往夹杂着这些非常规敏感字段。

脱敏阈值方面，常见做法是命中敏感字段就整条替换为占位符，而不是只打码部分字符。原因是模型可能把敏感信息拆成多段，只打码第一段，后续段照常输出。宁可多拦不可漏拦。如果业务方抱怨拦截误杀（比如用户正常输入了自己的手机号），就按业务场景放行指定字段，但放行规则里必须把"模型是否主动输出该字段"和"用户是否自己输入该字段"区分开——用户自己输入的可以回显，模型主动生成的必须拦。

输出侧防护的坑在于：过滤规则跑在推理之后，意味着每次被拦截的响应已经消耗了算力。如果拦截率很高，说明输入侧没拦住，应该回头调输入侧阈值，而不是只在输出侧堆规则。输出侧是安全网，不是主防线。

4.3 运行时：限速、审计日志与异常告警

防护不只在单次请求的输入输出上做文章，还要有运行时的态势感知。这里有三组参数值得记。

限速参数：普通用户和攻击者的请求模式差异很大。攻击者做批量越狱扫描时，请求频率高、上下文长度变化剧烈、同一模板反复换词。常见做法是在 API 网关上按用户维度限流，比如单用户每分钟不超过 30 次推理请求，单次上下文不超过 8192 token。限速本身不拦住所有攻击，但能把批量扫描的效率和隐蔽性打下来。

审计日志：记录每次请求的输入摘要（注意是摘要，不是原文；原文落库本身就是新的安全风险）、模型版本、命中哪些过滤规则、输出是否被拦截。日志要带 request_id 串联全链路，出事故时才能从日志还原攻击路径。我见过团队日志里不记模型版本，结果模型偷偷更新后安全问题复现，查了半天查不到原因——这是典型的排查黑匣子问题。

异常告警：告警阈值要按"被打穿的响应"设计。比如单小时拦截数突增 3 倍、同一来源 IP 触发越狱检测超过 10 次、模型响应中出现高敏感字段被脱敏超过 5 次。这几条阈值对应的是"有人在系统性试探"。告警别设太敏感，否则群里天天响，最后没人看。

5. 避坑记录：模型安全评估最容易翻车的五个地方

5.1 用例集和业务场景错位，评估结论等于白做

现象：用公开的通用越狱测试集跑了 95% 拦截率，报告很漂亮，上线后还是被打穿。

原因：通用测试集覆盖的是"模型能否抵御常见越狱"，但你真正的风险面在"模型是否会被诱导泄露知识库里的特定数据"。两者交集有限。

解决：在公开用例集基础上，加入业务自定义用例。做法是把真实业务里的敏感数据类别列出来，构造"帮我查一下 X 的合同编号""内部服务器的 IP 是多少"这类场景化提问，再包上几种越狱模板。评估用例必须来自资产分级表和威胁模型，不能只靠网上扒来的集子。

5.2 在 CPU 机器上跑大评估任务，时间失控

现象：32G 内存的机器跑 7B 量化模型评估，设定 1000 条用例，跑了 8 小时没出结果。

原因：CPU 推理本身慢，加上上下文设置过长，KV Cache 反复换出，推理速度降低到每秒几个 token。我之前把-c设成 8192，实际评估用不到那么长上下文，白白浪费内存带宽。

解决：评估环境单独调优。上下文压到 2048，模型量化用 Q4_K_M 而不是更高精度，--mlock锁内存防止换页。先把用例数压到 50 条估算单条耗时，再按可接受时间反推总用例数。评估的目的是出结论，不是跑满吞吐。

5.3 只测模型不测链路，漏掉工具调用层的注入

现象：模型本身越狱探测拦截率很高，但安全事故出在工具调用上——模型被诱导调用了一个"查询订单"工具，传了攻击者构造的参数，把别人订单信息拉出来了。

原因：这是间接提示注入的典型场景。攻击者没有直接攻击模型，而是通过工具返回的内容把恶意指令喂给模型，模型再按指令调用了工具。单测模型的用例覆盖不到这个链路。

解决：评估用例要覆盖"模型-工具-数据"三段，构造工具返回内容含恶意指令的样本。防护上对工具调用的入参做白名单校验，不允许模型自由拼接参数。这条是我做评估以来最值钱的教训，没有之一。

5.4 评估时用最新模型，生产环境跑的是旧版本

现象：评估显示某个漏洞已修复，但生产环境依然存在。

原因：模型版本漂移。评估环境和生产环境的模型权重不一致，可能是生产环境没更新，也可能是更新后评估基线没同步。

解决：评估报告里强制记录模型 SHA256 哈希和部署时间。每次模型更新，先跑一遍最小回归集，再把评估结论的版本号和生产环境对照。没有哈希记录的评估报告，一律视为无效。

5.5 把防护规则直接上线到生产，误杀率没人看

现象：输入侧注入检测上线 24 小时，业务方投诉用户正常提问被拦截，退货率上升。

原因：检测阈值设得太严，或者正则规则写得太宽。比如"忽略"两个字本身出现在很多正常提问里，"忽略我上一个问题"是普通用户常说的话，被规则打成了注入。

解决：上线前先跑离线回放，用一周线上真实请求做误报率测试，确认误报率低于 1% 再灰度。灰度期间只告警不拦截，观察误报情况，再逐步放开拦截比例。防护方案上线不是一次性动作，是按百分比推进的。

6. 进阶用法：把评估从"一次性项目"变成"持续回归"

如果你只照着前面的流程做了一次评估，完成了整改，那只是把安全评估当成了一次性项目。模型一换、提示词一改、RAG 知识库一更新，之前的评估结论就全部作废。这个教训我是在第二次翻车时彻底记住的：第一轮评估做了三周，报告很完整，一个月后产品经理把系统提示词从"你是客服助手"改成了"你是贴心管家"，顺手调了温度参数，之前测过的越狱用例直接被打穿了一半。

现在我做评估，一定会在交付时多搭一条持续回归的线。具体做法是：把评估用例集落成固定文件，按前面说的五类分批组织；模型或应用发布前，跑一遍最小回归集——几百条用例，十分钟内出结果；结果和上一次基线对比，新增的击穿项直接阻断发布。

# 持续回归的最小脚本逻辑（bash 伪代码） # 每次模型更新后执行，和上一轮基线对比 #!/bin/bash MODEL_PATH="/data/models/qwen2.5-7b-instruct-q4_k_m.gguf" # 运行 100 条核心回归用例，覆盖注入/越狱/泄露三类 garak --model_type huggingface \ --model_name "$MODEL_PATH" \ --probes promptinject,dan,dialogues \ --max_requests 100 \ --report_name base_regression_$(date +%F) # 生成 JSON 报告后与基线做对比，新增的击穿条目数超过阈值即告警 python compare_regression.py --baseline baseline.json --current base_regression_$(date +%F).json

这组命令有两个值得注意的参数。--report_name强制每次评估输出独立文件，方便对比，不会覆盖上一次结果。compare_regression.py是一段对比脚本，逻辑是把当前报告的"被击穿用例 ID"集合和基线做差集，新增超过 5 条就告警。这个"5 条"的阈值要按模型情况调：能力弱的模型本来击穿率就高，重点看的是新增量而不是绝对值。

回归频率方面，我的习惯是任何一次模型权重、系统提示词、RAG 知识库的变更都必须触发回归，而不是定时跑。定时回归能发现纠结，但发现不了"昨天改的那条提示词捅了娄子"——问题在于你根本不知道是哪次改动引入的。变更触发回归，还能顺带把锅定位到具体提交上，排查故障时能少熬夜。

最后一件事：安全评估不是一次性的交付物，也不是第三方测试机构的"盖章"。它是一套要跟着模型版本走的持续动作，评估用例要随攻击手法更新，防护参数要随误杀率数据调整，报告结论要能在三个月后还讲得清楚当时的版本和边界。我在做的项目里已经把这份指南的思路真正落成了发布流程上的一个卡点，之后再也没有出现过"模型上线一周被打穿"的事故。希望帮到你。

本文还有配套的精品资源，点击获取