风险处置
先说结论
风险处置是指当模型出现安全、合规或业务风险事件时，对异常进行识别、分级、遏制、恢复、通报和复盘的全过程。
为什么我会单独记这一篇
大模型系统会出现传统系统也有、但更加复杂的事故：
- 越狱成功
- 敏感信息泄漏
- 恶意工具执行
- 大面积幻觉
- 合规违规
如果没有明确的处置机制，问题往往只能“修一条 prompt”，无法真正止损和复盘。
核心机制
常见事件类型
- 安全事件：越狱、泄密、越权访问、恶意工具执行。
- 质量事件：大面积幻觉、错误决策建议、输出不稳定。
- 合规事件：隐私违规、日志保留不合规、使用范围超界。
典型处置链路
- 告警与识别
- 事件分级
- 遏制与止损
- 恢复与回滚
- 证据保全
- 复盘与回归测试
设计时真正要权衡什么
- 快速止损 vs 服务连续性：直接下线、降级还是切只读模式。
- 广谱阻断 vs 精准修复：广谱更快，精准影响更小。
- 保留证据 vs 立即清理：要兼顾取证与用户保护。
容易踩的坑
- 没定义什么算事故，导致升级滞后。
- 只有模型质量指标，没有安全事件分级和 on-call 流程。
- 事故后只改 prompt，不改权限、工具、日志和回滚机制。
- 无法还原输入、检索文档、工具调用和输出链路。
- 只修当前样本，没有沉淀成回归测试和策略更新。
工程落地时我会怎么做
- 建立
P0 / P1 / P2等明确分级。 - 预置止损开关：下线模型版本、关闭高危工具、关闭自动执行、切安全降级回复。
- 事件证据包至少包含：request ID、trace ID、用户 / 租户、prompt 版本、检索片段、工具参数与结果、安全分类结果。
- 事故后把样本沉淀进红队集、回归集和策略规则库。
- 明确责任边界：模型团队、平台团队、业务 owner、法务 / 合规。
如果要对外讲，可以怎么概括
“LLM 风险处置不能停留在‘修一句提示词’。真正有效的做法是把它纳入标准 incident response：有分级、有止损开关、有证据包、有回滚路径、有复盘闭环。这样才能把一次事故变成下一轮策略和评测的输入。”
最后记几条
- 风险处置要覆盖识别、分级、止损、恢复、复盘。
- 预置止损开关比临场救火更重要。
- 没有 request ID 和 trace ID 很难真正复盘。
- 安全、质量和合规事件要分别定义。
- 事故样本最终应进入回归测试和红队集。