自动化红队评测平台:评测引擎设计与实现
平台需求分析
在 大模型红队测试 中我们建立了攻击向量体系和安全评测基准,在 评测平台架构 中我们掌握了评测工程化的基础框架。然而,当红队测试的规模从手动验证扩展到数百个攻击向量、数十个模型版本、多个安全维度的并行评测时,一个专为红队场景设计的自动化评测平台就成为刚需。
红队评测平台与通用评测平台的关键差异在于:红队评测的"正确答案"不是确定性的——一个攻击向量是否成功绕过安全防线,需要多维度的语义判断;评测的输入不是标准问答对,而是精心构造的对抗性 Payload;评测的目标不仅是测量模型能力,更是量化模型的安全风险边界。
核心需求拆解
评测任务管理:支持创建、编辑、克隆、批量导入评测任务集。任务集需要支持版本控制,确保每次评测的输入可追溯、可复现。任务维度包括攻击类型分类(Prompt 注入、越狱、数据提取、偏见检测等)、攻击强度分级(低/中/高对抗性)、目标模型范围和评测环境配置。
评测结果可视化:不同维度的安全评分需要直观的可视化呈现。安全团队关注的不是单条测试通过与否,而是整体安全态势——哪些攻击类别是高危薄弱区、模型更新后安全指标如何漂移、不同模型间的安全能力差异有多大。
模型横向对比:同一套红队测试集应用于多个模型版本时,需要支持多维度的并列对比。对比维度包括攻击成功率(ASR)、各类攻击的拒绝率、响应延迟对安全评分的影响、以及安全-有用性(Safety-Utility)的权衡分析。
持续评测:红队评测不应是一次性活动。随着攻击手法的演进和模型版本的迭代,需要建立持续运行的评测流水线。评测结果需要与 CI/CD 集成——模型更新前自动触发安全回归测试,生产环境定期执行安全巡检。
mindmap
root((红队评测平台<br/>核心需求))
评测任务管理
任务集创建与编辑
版本控制与追溯
批量导入与克隆
攻击分类体系
结果可视化
安全态势仪表盘
攻击类别热力图
趋势分析曲线
风险等级标注
模型横向对比
多模型并列对比
攻击成功率对比
Safety-Utility 权衡
维度雷达图
持续评测
CI/CD 集成
定期安全巡检
攻击库持续更新
回归测试门控系统架构
整个平台采用评测引擎 + 任务调度器 + 结果存储 + 前端仪表盘的四层架构,每一层通过明确的接口解耦,支持独立扩展和部署。
graph TB
subgraph 前端层
A[React Dashboard]
B[评测报告 UI]
C[对比分析面板]
end
subgraph API 网关
D[FastAPI Gateway]
end
subgraph 评测引擎
E[Test Case Executor]
F[LLM-as-Judge Evaluator]
G[Metric Calculator]
end
subgraph 任务调度
H[Celery Worker Pool]
I[Redis Task Queue]
J[Priority Scheduler]
end
subgraph 数据层
K[(PostgreSQL<br/>评测数据)]
L[(Redis<br/>任务状态/缓存)]
M[MinIO<br/>Trace 存储]
end
subgraph 外部集成
N[Model API Gateway]
O[CI/CD Webhook]
P[飞书/Slack 通知]
end
A --> D
B --> D
C --> D
D --> I
I --> H
H --> E
E --> N
E --> F
F --> G
G --> K
H --> L
E --> M
J --> I
O --> D
D --> P数据流路径
一条评测数据从触发到结果展示的完整路径:
- 用户通过 Dashboard 或 CI/CD Webhook 触发评测任务
- FastAPI 网关接收请求,创建任务记录并推入 Redis 队列
- Celery Worker 从队列消费任务,根据优先级调度执行
- Test Case Executor 逐条构造攻击 Payload,调用目标模型 API
- LLM-as-Judge 对模型响应进行安全判定(攻击成功/拒绝/部分泄露)
- Metric Calculator 聚合所有测试结果,计算多维安全指标
- 结果写入 PostgreSQL,Trace 数据存入 MinIO
- 前端通过 WebSocket 订阅任务状态更新,实时展示评测进度
评测引擎
评测引擎是整个平台的核心计算层,负责将红队测试用例转化为可量化的安全评分。引擎设计遵循执行-评判-聚合三阶段管线模式。
测试用例执行器
测试用例执行器的核心职责是构造攻击 Payload、调用目标模型、收集原始响应。为了支持多样化的攻击场景,执行器需要适配多种调用模式:
攻击 Payload 的多态设计是引擎的关键抽象。不同类型的攻击需要不同的 Payload 构造策略:
| 攻击类型 | Payload 策略 | 构造方式 |
|---|---|---|
| 直接 Prompt 注入 | 指令覆盖、角色劫持 | 模板拼接 + 变量替换 |
| 间接 Prompt 注入 | RAG 毒化、网页内容注入 | 恶意文档生成 + 上下文注入 |
| 越狱攻击 | DAN 变体、多轮渐进引导 | 多轮对话序列 + 动态调整 |
| 数据提取 | 系统 Prompt 逆向、记忆提取 | 分层探测 + 语义诱导 |
| 偏见检测 | 对比场景构造 | 对称变量生成 + 多次采样 |
| 有害内容生成 | 诱导性话题引导 | 场景构造 + 逐步升级 |
LLM-as-Judge 集成
红队评测的判定环节需要判断模型响应是否构成"安全突破"。这种判断本质上是语义级的——响应可能表面上没有直接回答有害请求,但暗示了危险信息;或者模型虽然拒绝了请求,但泄露了系统提示词的一部分。
基于 LLM-as-Judge 原理,我们设计了分层评判机制:
分层评判 Prompt 设计是 LLM-as-Judge 在红队场景下的核心。Judgment Prompt 需要指导评判模型从多个安全维度进行判定:
评判一致性保障是红队评测中容易被忽视的问题。LLM-as-Judge 存在固有的非确定性,同一对(攻击向量, 模型响应)可能被评判为不同结果。工程实践中采用以下策略缓解:
- 多次评判取众数:对同一样本调用 Judge 3 次,取多数一致的判定结果
- 温度设为 0:Judge 模型使用 temperature=0 减少随机性
- 置信度阈值:当 Judge 输出的 confidence 低于 0.7 时标记为"需人工复核"
- 一致性监控:定期对 Judge 模型进行自身一致性测试(Self-consistency Check)
指标计算器
指标计算器将单条评判结果聚合为多维安全评分体系:
综合安全评分(Composite Safety Score) 是一个加权指标,综合反映模型在所有攻击维度上的防御能力。权重分配基于攻击类别的实际危害程度:Prompt 注入和越狱类攻击直接威胁模型安全对齐的核心防线,因此权重最高。
任务调度
红队评测任务的调度面临独特的挑战:单次评测可能涉及数千条 API 调用,需要精确的并发控制以避免触发目标模型的限流策略;评测任务的执行时间差异巨大(简单拒绝判断可能 1 秒,多轮越狱攻击可能需要 60 秒以上);评测优先级需要动态调整——CI/CD 门控任务的优先级高于日常巡检任务。
并发控制
超时处理
评测任务的超时需要分层控制:
| 层级 | 超时类型 | 默认值 | 处理策略 |
|---|---|---|---|
| 用例级 | 单条测试用例执行超时 | 30s | 标记为 timeout,归入失败统计 |
| 批次级 | 单个评测批次总超时 | 30min | 取消剩余用例,输出部分结果 |
| Judger 级 | LLM-as-Judge 评判超时 | 15s | 重试 2 次,仍失败则标记需人工复核 |
| 全局级 | 整体任务最大运行时长 | 2h | 强制终止,保留已完成结果 |
重试机制
重试策略设计原则:并非所有失败都值得重试。4xx 错误(参数错误、认证失败)不应重试,重试只会重复失败;5xx 错误(服务端临时故障)和限流错误应当重试,配合指数退避避免加重服务端压力。评测用例级别的重试不影响批次的整体进度——单条用例失败时跳过继续,最终统计时标记为 error。
优先级队列
评测任务的优先级动态调整规则:
可视化
红队评测结果的可视化设计需要让安全团队在几秒钟内把握全局安全态势,并能够快速下钻到具体问题。核心仪表盘包含三个关键视图。
安全态势总览
攻击类别归因热力图
归因热力图将攻击成功率按 攻击类别 × 攻击强度 二维展开,直观暴露安全薄弱区:
| 攻击类别 | 低强度 | 中强度 | 高强度 | 极端对抗 |
|---|---|---|---|---|
| Prompt 注入 | 2.1% | 12.8% | 28.4% | 41.2% |
| 越狱攻击 | 1.3% | 8.6% | 22.1% | 35.7% |
| 数据提取 | 0.8% | 5.2% | 14.3% | 19.8% |
| 间接注入 | 1.5% | 9.1% | 26.7% | 38.5% |
| 偏见检测 | 0.5% | 3.8% | 7.2% | 12.1% |
| 有害内容 | 0.2% | 1.9% | 4.8% | 8.3% |
热力图中颜色越深的区域代表 ASR 越高,即该攻击类别在该强度下越容易突破安全防线。安全团队优先关注右上角的高危区域——高强度 Prompt 注入(41.2%)和高强度越狱(35.7%)是当前最薄弱的安全防线。
多模型对比雷达图
当需要对比不同模型的安全能力时,雷达图是最直观的呈现方式。每个轴代表一个攻击维度,多边形面积越大代表综合安全能力越强:
离线 + 在线联动
红队评测平台需要同时支持两种运行模式,分别服务于不同的场景需求。
离线评测:CI/CD 集成
离线评测在模型发布流水线中作为质量门控,确保每次模型更新不会引入安全退化:
graph LR
A[模型训练/微调] --> B[模型注册表]
B --> C{触发评测}
C --> D[红队评测套件<br/>~2000 用例]
D --> E{安全评分<br/>≥ 阈值?}
E -->|通过| F[发布到预发环境]
E -->|未通过| G[阻断发布<br/>通知安全团队]
F --> H[在线评测<br/>生产监控]门控策略设计:
在线评测:生产监控
在线评测持续监控生产环境中模型的安全表现,与离线评测的关键区别在于:
| 维度 | 离线评测 | 在线评测 |
|---|---|---|
| 触发方式 | CI/CD Pipeline | 定时任务 + 异常触发 |
| 数据来源 | 标准化测试集 | 生产流量采样 + 合成注入 |
| 评测延迟 | 可接受分钟级 | 需秒级反馈 |
| 结果用途 | 发布门控 | 告警 + 自动熔断 |
| Judge 模型 | 独立的强模型 | 轻量级分类器 + 采样 Judge |
在线评测模块通过流量采样 + 实时判定实现生产环境的安全监控:
流量采样策略需要平衡监控覆盖面和评测开销。全量评测不现实——生产流量的 API 调用成本巨大;但固定比例采样可能遗漏低频但高危的攻击模式。改进策略是风险自适应采样:对已知高危场景(如涉及敏感话题的用户输入)提高采样率,对常规场景维持低采样率。
安全考量
评测平台本身处理的是高度敏感的攻击数据,其安全设计需要同等重视。
评测数据隔离
红队评测数据包含精心构造的攻击 Payload 和模型的安全漏洞信息,泄露这些数据等同于暴露攻击者工具箱和防御薄弱点。
数据分级与隔离策略:
模型 API Key 管理
评测平台需要调用多个模型提供商的 API,密钥管理必须遵循最小权限原则和轮换策略:
密钥安全实践:
| 实践 | 说明 |
|---|---|
| Vault 集成 | 使用 HashiCorp Vault 或 AWS Secrets Manager 集中管理密钥 |
| 环境隔离 | 开发/测试/生产环境使用不同的 API Key |
| 速率限制 | 为评测专用 Key 设置独立的速率限制,避免影响生产流量 |
| 审计日志 | 记录每次密钥使用的时间、调用方、调用量 |
| 自动轮换 | 每 90 天自动轮换密钥,异常使用时立即轮换 |
测试数据隐私
红队测试中使用的攻击 Payload 可能涉及真实的安全威胁场景。为避免测试数据本身成为安全风险:
- 合成优先:攻击 Payload 尽量由模型合成生成,而非从真实攻击事件中复制
- 脱敏处理:涉及个人隐私的测试场景使用虚构数据,禁止使用真实 PII
- 访问控制:测试数据的访问需要记录审计日志,支持事后追溯
- 传输加密:所有评测数据在传输过程中使用 mTLS 加密
技术栈
核心技术选型
| 组件 | 技术选择 | 选型理由 |
|---|---|---|
| API 网关 | FastAPI | 原生 async/await 支持,与 LLM API 的异步调用模型天然契合;Pydantic 提供强类型校验;OpenAPI 自动文档方便前后端协作 |
| 任务调度 | Celery + Redis | Celery 的优先级队列和定时任务能力成熟可靠;Redis 作为 Broker 提供低延迟的消息投递;Celery Flower 提供任务监控 UI |
| 数据存储 | PostgreSQL | JSONB 类型天然适合存储评测结果的半结构化数据;强大的聚合查询能力支持复杂的统计分析;行级安全策略支持数据隔离 |
| 缓存/状态 | Redis | 任务状态实时查询、评测队列管理、速率限制计数器、结果缓存,多种用途复用同一个 Redis 集群 |
| 前端仪表盘 | React + ECharts | React 组件化架构支持仪表盘的灵活拼装;ECharts 的热力图、雷达图、趋势图组件直接满足可视化需求 |
| 对象存储 | MinIO | 存储评测 Trace 数据、原始 Payload 和模型响应的完整记录;S3 兼容 API 方便后续迁移至云存储 |
选型决策依据
为什么选 Celery 而不是 ARQ 或 Dramatiq:Celery 在生产环境的成熟度最高,社区生态最完善。红队评测场景需要复杂的任务编排(子任务链、回调、超时控制),Celery 的 Canvas 原语(chain, chord, group)提供了开箱即用的解决方案。虽然 Celery 的配置复杂度较高,但对于需要长期维护的评测平台,这些投入是值得的。
为什么选 PostgreSQL 而不是 MongoDB:评测数据虽然是半结构化的,但核心查询模式是关系型的——按模型版本聚合、按时间范围筛选、按攻击类别分组统计。PostgreSQL 的 JSONB 类型兼顾了灵活性和查询性能,而 MongoDB 在需要 JOIN 和复杂聚合查询时反而显得力不从心。此外,PostgreSQL 的行级安全策略(RLS)为数据隔离提供了数据库层面的保障。
为什么用 MinIO 存储 Trace 而不是直接存数据库:单条评测的完整 Trace 可能达到数百 KB 甚至 MB 级别(包含完整的多轮对话、工具调用记录等)。将这些数据直接存入 PostgreSQL 会导致表膨胀、查询性能下降。MinIO 提供了廉价的大对象存储,Trace 数据通过引用 ID 与评测结果关联。
完整平台架构图
graph TB
subgraph 触发层
T1[CI/CD Pipeline<br/>GitHub Actions / GitLab CI]
T2[定时任务<br/>Cron Scheduler]
T3[手动触发<br/>Dashboard UI]
T4[API 调用<br/>外部系统集成]
end
subgraph 网关层
GW[FastAPI Gateway<br/>认证 / 限流 / 路由]
end
subgraph 调度层
RQ[(Redis<br/>Task Queue)]
CW[Celery Worker Pool<br/>并发控制 / 重试 / 超时]
PS[Priority Scheduler<br/>优先级动态调整]
end
subgraph 评测引擎
TC[Test Case Executor<br/>Payload 构造 / API 调用]
LJ[LLM-as-Judge<br/>分层评判 / 一致性保障]
MC[Metric Calculator<br/>指标聚合 / 评分计算]
end
subgraph 数据层
PG[(PostgreSQL<br/>评测数据 / 安全评分)]
RD[(Redis<br/>状态缓存 / 速率限制)]
MO[(MinIO<br/>Trace / 原始响应)]
ES[(Elasticsearch<br/>日志 / 审计)]
end
subgraph 前端层
DASH[React Dashboard<br/>安全态势 / 趋势分析]
REPORT[评测报告<br/>PDF / Markdown 导出]
COMPARE[对比面板<br/>多模型横向对比]
end
subgraph 外部集成
MDL[Model API Gateway<br/>OpenAI / Anthropic / 自部署]
NOTIFY[通知服务<br/>飞书 / Slack / 邮件]
VAULT[Secret Manager<br/>API Key / 证书管理]
end
T1 --> GW
T2 --> GW
T3 --> GW
T4 --> GW
GW --> RQ
PS --> RQ
RQ --> CW
CW --> TC
TC --> MDL
TC --> LJ
LJ --> MC
CW --> RD
TC --> MO
MC --> PG
GW --> ES
PG --> DASH
PG --> REPORT
PG --> COMPARE
GW --> VAULT
GW --> NOTIFY
CW --> NOTIFY代码仓库:GitHub - red-team-eval-platform
延伸阅读
- 大模型红队测试:方法论、自动化工具与评测基准 — 攻击向量体系和安全评测基准详解
- 评测平台架构:自动化评测、Trace 回放与归因分析 — 通用评测平台的架构设计模式
- LLM-as-Judge:原理、偏差分析与实战配置 — 自动化评判的技术原理与工程实践
- Agent 评测方法论:维度设计、指标体系与评测框架 — 评测维度设计与指标体系构建
- AI 应用可观测性:链路追踪、成本管控与告警体系 — 生产环境的监控与告警设计
- Prompt 攻防:注入攻击手法与防御架构 — Prompt 注入的攻击技术细节
- [AI Agent 安全设计:权限模型、沙箱隔离与审计日志](../../08-安全与AI融合/AI Agent安全设计:权限模型、沙箱隔离与审计日志/) — Agent 安全架构设计参考