大模型安全风险分类体系应该如何设计？

简化版

安全风险分类体系不能只列“暴力、色情、违法”几个内容类别，还要描述谁受影响、风险如何发生、系统处于哪个阶段、可能造成多大后果。常用多轴包括伤害域、攻击向量、资产、能力、严重度和处置动作。

好的 Taxonomy 应满足类别定义互斥性尽可能强、覆盖完整、可由标注员稳定执行，并能直接映射到评测集、监控指标和响应流程。分类太粗无法定位，太细又会导致一致性低和样本不足，因此通常采用层级结构与多标签。

Taxonomy 的目标不是把风险“命名得漂亮”，而是让发现、评测、拦截和事故响应使用同一种语言。

详细版

可以用多轴事件记录，而不是强迫每个案例只进一个桶：

harm_domain: privacy
attack_vector: indirect_prompt_injection
affected_asset: customer_database
system_stage: tool_execution
severity: critical
outcome: blocked

例如恶意网页指令诱导 Agent 导出客户数据，同时属于提示注入、隐私泄露、工具越权和供应链输入风险。若只标“Prompt Injection”，后续无法统计真正受损资产和业务后果。

轴	示例	用途
伤害域	隐私、欺诈、自伤、仇恨	政策与专家归属
攻击路径	越狱、注入、数据投毒	防御设计
系统资产	模型、数据、工具、用户	影响分析
生命周期	训练、部署、输入、执行、输出	责任定位
严重度	Low～Critical	门禁与响应 SLA

完整版教学

1. 为什么单轴内容分类不够

同一段有害文本可能只是模型输出，也可能触发真实转账工具；文字相同，风险后果完全不同。只按内容类别无法表达系统能力和副作用。

因此要把“内容是什么”“如何发生”“影响什么”和“造成多大后果”分开记录。

2. 先明确 Taxonomy 的使用者

安全研究用它组织攻击，产品团队用它决定策略，评测团队用它分层抽样，事故响应团队用它确定优先级。设计前应列出这些决策需求。

如果某标签不能改变任何评测、监控或处置，就要质疑是否值得保留。

3. 层级结构如何设计

顶层类别保持稳定，例如内容安全、隐私、网络安全、欺诈、可靠性；二三级描述更具体的行为与场景。

Privacy
  ├─ Sensitive data exposure
  │   ├─ Training memorization
  │   ├─ RAG permission leak
  │   └─ Tool exfiltration
  └─ Identity misuse

上层用于管理报告，下层用于工程定位。层级不宜深到标注员难以选择。

4. 为什么需要多标签

风险往往交叉：仇恨骚扰可能同时针对未成年人并泄露地址；恶意代码可能通过间接注入触发工具执行。允许多标签能保留因果链。

但应指定 Primary Label 表示主要后果，Secondary Labels 表示路径和伴随风险，避免统计时一条事故被误算成多个独立事故。

5. 严重度如何独立于类别

同一类别内后果差异很大。轻微个人信息误提与大规模客户数据库泄露都属于隐私，但响应级别不同。

维度	问题
Impact	潜在伤害多大、是否可逆
Scale	影响一人还是大量用户
Exploitability	需要专家还是普通用户可复现
Reach	是否自动传播或触发外部动作
Confidence	证据是否充分

可以形成严重度矩阵，但 Critical 的定义必须有具体示例和审批规则。

6. 威胁、脆弱性与事件要区分

威胁是潜在攻击者或危险，脆弱性是系统弱点，事件是已经发生的行为，伤害是最终后果。把它们混成同一级标签会让根因统计混乱。

“提示注入成功”描述攻击与脆弱性；“客户数据被外传”描述事件后果。两者都要记录，但不能互相替代。

7. 生命周期轴如何帮助归因

风险可能发生在训练数据、模型权重、检索索引、Prompt、工具执行或输出展示。相同“错误回答”根因可能是数据投毒，也可能是检索权限错。

按阶段标注能把修复任务路由到数据、模型、平台或产品团队。

8. 如何验证分类体系可执行

准备覆盖各种边界的样本，让多名标注员独立标注，计算 Kappa/Alpha 并分析混淆。若“误导信息”和“欺诈协助”频繁混淆，需要明确意图与后果边界。

还要做覆盖审计：近期事故是否大量落入 Other。Other 占比持续高说明体系漏类或指南不够。

9. 如何从分类映射到评测

为每个高风险叶子节点定义最小样本量、攻击变体、正常反例和评分器。不能只有恶意正例，否则系统通过拒绝全部请求就得高分。

评测报告按严重度和类别单独展示 Recall、过拒率和事件数，避免被总体均值稀释。

10. 如何映射到监控与事件响应

每个标签应关联监控信号、日志字段、告警级别、负责人和响应时限。例如 Critical 工具越权直接 Pager，低风险风格问题进入周报。

事件复盘后检查：现有 Taxonomy 是否能准确表示根因和后果，是否需要新增子类或调整示例。

11. 版本治理为什么重要

政策和攻击会变化。标签需要稳定 ID、显示名称、定义、生效时间和弃用映射。重命名不能导致历史趋势断裂。

发布新版本时做旧标签到新标签的迁移表，并重算关键报表或明确不可比区间。

12. 如何避免分类体系过度膨胀

新事故不应自动创建新类别；先判断是否只是现有类别的新示例。只有处置、责任或评测需求明显不同，才值得新增标签。

定期合并低频且无法稳定区分的叶子节点，同时保留原始事件文本和旧标签用于审计。

13. 常见误区与追问

• 误区：安全分类就是有害内容分类。 还包括隐私、注入、工具越权、数据投毒和系统可靠性。
• 误区：每个事件只能有一个类别。 风险有路径、资产和后果多个维度，通常需要多标签。
• 误区：类别本身就代表严重度。 同一隐私类别可以从 Low 到 Critical。
• 误区：分类越细越专业。 过细会降低标注一致性并导致每类样本不足。
• 误区：Taxonomy 发布后保持不变。 新能力与攻击要求版本化演进。
• 追问：如何判断要不要新增标签？ 看它是否需要不同处置、负责人或评测覆盖，而不只是名称不同。
• 追问：Other 太多怎么办？ 聚类 Other 案例，判断缺失类别或指南歧义，再做版本更新。

14. 加强记忆

1. 多轴：伤害域、攻击路径、资产、阶段、严重度。
2. 层级加多标签：上层做治理，下层做定位，Primary 防重复统计。
3. 严重度独立：影响、规模、可利用性和传播范围共同决定。
4. 可执行验证：看标注一致性、Other 占比和事件覆盖。
5. 直接落地：每个标签映射评测、监控、负责人和响应 SLA。