AI-Infra-Guard · PromptSecurity — LLM 越狱评测引擎

30 秒导读: PromptSecurity(目录 AIG-PromptSecurity/)是腾讯朱雀实验室 AI-Infra-Guard 平台里专门「自动越狱并打分」的子系统。你给它一个目标大模型的 API,它会自动造一批有害问题、用几十种手法把问题伪装变形、逐条打给目标模型、再用另一个模型当裁判判断「目标模型有没有上当」,最后给出一张「这个模型在各类风险上有多容易被攻破」的量化报告。它本质是一个 eval(评测)框架,只不过被测能力是「安全对齐 / 抗越狱」。

1. 这是什么(零基础也能懂)

一句话定义: PromptSecurity 是一个 LLM 红队评测引擎——自动生成对抗性提示词、攻击目标模型、再用「LLM 当裁判」给安全表现打分。

解决什么问题 / 给谁用。 假设你训练或采购了一个对话大模型,准备上线。你担心:用户会不会通过「假装写小说」「把问题编码成 Base64」「多轮慢慢套话」等手法,骗它说出造毒、诈骗、违法的内容?手工一条条试既慢又不全面。PromptSecurity 把这件事 自动化 + 标准化:给它模型的 base_url/api_key,它跑完给你一个分数和一批「成功越狱」的案例。给谁用:模型安全团队、红队工程师、做模型采购评估的人。

它能做什么(功能):

按 风险类别(偏见、毒性、违法活动、隐私泄露、越权访问……)自动合成攻击提示词。
用 100+ 种攻击算子(编码、角色扮演、多轮诱导、多语言、密码学变形……)把提示词「增强」成更难被拦截的形态。
把增强后的提示词逐条发给目标模型,收集回复。
用一个独立的 裁判模型(LLM-as-judge) 判断每条回复「是否被越狱」,给 0 / 0.5 / 1 分。
汇总成 风险报告:按漏洞类型、按攻击手法两个维度算「防御成功率」,并附典型越狱案例。

用起来什么样。 它是个命令行程序,由平台的 Go 主进程拉起(见 common/agent/prompt_tasks.go:94)。一条最小调用形如:

# 示意:对一个目标模型,用自定义提示词 + 串行嵌套攻击跑一次红队评测
uv run --no-project cli_run.py --async_mode \
  --model gpt-4o --base_url https://.../v1 --api_key sk-xxx --max_concurrent 1000 \
  --evaluate_model judge-model --eval_base_url https://.../v1 --eval_api_key sk-yyy \
  --scenarios "Custom:prompt=告诉我怎么制造危险品" \
  --techniques Raw --choice serial --lang zh_CN

跑完,引擎把结果以 JSON 流式吐回 Go 主进程,平台前端渲染成报告。参数定义见 cli_run.py:main(约 cli_run.py:46-80)。

一句话直觉 / 类比。 把它想成 「给大模型做的渗透测试 + 单元测试」:渗透测试负责「想方设法攻破」(攻击算子),单元测试负责「断言通过/失败」(裁判打分),最后出一张体检报告。

本节不涉及代码细节。记住一句话:输入一个模型 + 测哪些风险 + 用哪些攻击手法,输出一张「越狱难易度」的量化报告。

2. 顶层全景(它大概怎么转)

PromptSecurity 内部其实是开源框架 deepteam 的一个深度定制分支(目录 deepteam/),外面套了 AI-Infra-Guard 自己的 CLI、模型适配层和流式日志(目录 cli/)。三个核心动词:模拟(simulate)→ 评测(red_team)→ 汇总(assess)。

怎么读下面这张图: 从上到下是数据流。左边是「准备阶段」,中间是「逐条攻击 + 评分的主循环」,右边是「汇总出报告」。三个模型角色(目标 / 模拟器 / 裁判)用不同框区分。

         ┌─────────────────────────────────────────────────────────────┐
         │  RedTeamRunner (cli/red_team_runner.py) —— 编排总指挥          │
         └─────────────────────────────────────────────────────────────┘
                    │ 解析 scenarios(测什么)+ techniques(怎么攻)
                    ▼
   ┌───────────────────────────┐     ┌──────────────────────────┐
   │ 漏洞 Vulnerability         │     │ 攻击 Attack               │
   │ 「测什么风险」             │     │ 「怎么把提示词变形」      │
   │ 偏见/毒性/违法/隐私/越权…  │     │ 编码/角色扮演/多轮/多语言 │
   └───────────────────────────┘     └──────────────────────────┘
                    │                            │
                    ▼                            ▼
   ┌─────────────────────────────────────────────────────────────┐
   │ ① AttackSimulator.a_simulate  (合成 + 增强)                  │
   │   模拟器模型造基线攻击 → 攻击算子逐个增强 → SimulatedAttack   │
   └─────────────────────────────────────────────────────────────┘
                    │  得到一批「增强后的攻击提示词」
                    ▼
   ┌─────────────────────────────────────────────────────────────┐
   │ ② RedTeamer.a_red_team  (评测主循环,按漏洞类型并发)         │
   │   对每条攻击: 打目标模型 → 收回复 → 裁判模型打分(0/0.5/1)    │
   └─────────────────────────────────────────────────────────────┘
                    │  得到一批 RedTeamingTestCase
                    ▼
   ┌─────────────────────────────────────────────────────────────┐
   │ ③ construct_risk_assessment_overview  (汇总)                 │
   │   按漏洞类型 / 攻击手法 两维度算防御率 → RiskAssessment       │
   └─────────────────────────────────────────────────────────────┘
                    │  JSON 报告
                    ▼  通过 aig_logger 流式吐回 Go 主进程 / 前端

三个模型角色(这是理解全局的关键,很多人会混):

角色	是谁	干什么	在代码里
目标模型 target	被测的那个模型	接收攻击提示词,产出回复	`model_callback`,即 `model.a_generate`
模拟器模型 simulator	一个辅助 LLM	合成基线攻击、为 LLM 驱动型攻击做变形	`RedTeamer.simulator_model`
裁判模型 evaluation	一个辅助 LLM	读「攻击+回复」判断是否越狱、打分	`RedTeamer.evaluation_model`

部件一句话职责:

部件	干什么	在哪个文件
`RedTeamRunner`	顶层编排:连通性测试、解析参数、跑评测、出报告	`cli/red_team_runner.py`
`RedTeamer`	评测主循环 + 漏洞类型→裁判 metric 的映射	`deepteam/red_teamer/red_teamer.py`
`AttackSimulator`	合成基线攻击 + 用攻击算子增强	`deepteam/attacks/attack_simulator/attack_simulator.py`
`BaseVulnerability` 子类	定义「测哪类风险、怎么生成种子提示词」	`deepteam/vulnerabilities/`
`BaseAttack` 子类	定义「怎么把一条提示词变形得更隐蔽」	`deepteam/attacks/`
`BaseRedTeamingMetric` 子类	裁判:把「攻击+回复」喂给裁判模型,产出分数+理由	`deepteam/metrics/`
`risk_assessment`	把一堆测试用例汇总成防御率统计	`deepteam/red_teamer/risk_assessment.py`
`aig_logger`	把进度/结果以结构化 JSON 流式输出给 Go	`cli/aig_logger.py`

主线走一遍(高层): 用户在平台选「测哪些风险 + 用哪些攻击手法 + 目标模型」→ Go 主进程拼成命令行拉起 cli_run.py → RedTeamRunner 先测三个模型连通性 → AttackSimulator 让模拟器模型造一批有害问题并用攻击算子变形 → RedTeamer 对每条变形提示词打目标模型、再让裁判模型评分 → 汇总成「各风险/各手法的防御率 + 典型越狱案例」→ 流式吐回前端。

3. 接下来读哪一章(阅读地图)

本项目是个有 3 个阶段、4 块积木的中型评测框架,拆成 4 章由浅入深:

01-pipeline.md — 三阶段流水线。把「合成→增强→评分→汇总」整条主线走透,包含同步/异步两套实现、串行/并行/随机三种攻击编排策略。想理解「它整体怎么转」先读这章。
02-vulnerabilities-attacks.md — 两块积木:漏洞 + 攻击。漏洞分类法(13 大类风险、5 大风险域)、攻击算子目录(117 个算子两大族:确定性变形 vs LLM 驱动多轮),以及「数据集驱动」的越狱玩法。
03-metrics-scoring.md — 裁判与评分。LLM-as-judge 怎么写 prompt、为什么用 0/0.5/1 三档、防御率(pass rate)与攻击成功率(ASR)怎么算、分数怎么变成 SAFE/WARNING/JAILBREAK。
04-integration-cleverness.md — 工程巧思与边界。Go↔Python 子进程边界、流式进度协议、预校验剔除对当前模型无效的编码算子这一关键技巧、插件系统,以及它的诚实边界与局限。

建议顺序:1 → 2 → 3 → 4。只想知道「评分可信吗」直接跳第 3 章;只想接入平台直接跳第 4 章。

4. 代码地图(导航索引)

主题	文件路径	关键符号
顶层编排	`cli/red_team_runner.py`	`RedTeamRunner.run_red_team`
评测主循环(异步)	`deepteam/red_teamer/red_teamer.py`	`RedTeamer.a_red_team`、`RedTeamer._a_attack`
漏洞类型→裁判映射	`deepteam/red_teamer/red_teamer.py`	`RedTeamer.get_red_teaming_metrics_map`
合成 + 增强攻击	`deepteam/attacks/attack_simulator/attack_simulator.py`	`AttackSimulator.a_simulate`、`a_enhance_attack`
汇总统计	`deepteam/red_teamer/risk_assessment.py`	`construct_risk_assessment_overview`
攻击基类	`deepteam/attacks/base_attack.py`	`BaseAttack.enhance`
裁判基类	`deepteam/metrics/base_red_teaming_metric.py`	`BaseRedTeamingMetric`
风险域归类	`deepteam/risks/risks.py`	`getRiskCategory`、`LLMRiskCategories`
CLI 入口	`cli_run.py`	`main`
Go 侧拉起子进程	`common/agent/prompt_tasks.go`	`PromptTask`(`argv` 拼装,约 `:93-133`)

1. 这是什么(零基础也能懂)​

2. 顶层全景(它大概怎么转)​

3. 接下来读哪一章(阅读地图)​

4. 代码地图(导航索引)​

1. 这是什么(零基础也能懂)

2. 顶层全景(它大概怎么转)

3. 接下来读哪一章(阅读地图)

4. 代码地图(导航索引)