OOD 感知决策与可信强化学习：从置信度评估到安全回退

文章目录

- 关键词
- [1. 检测之后，才是真正的挑战](#1. 检测之后，才是真正的挑战)
- [2. 置信度的陷阱：agent 真的知道自己不知道吗？](#2. 置信度的陷阱：agent 真的知道自己不知道吗？)
- - [2.1 过度自信的神经网络](#2.1 过度自信的神经网络)
  - [2.2 四类置信度信号对比](#2.2 四类置信度信号对比)
- [3. Confidence Calibration：让置信度说真话](#3. Confidence Calibration：让置信度说真话)
- - [3.1 什么是校准](#3.1 什么是校准)
  - [3.2 RL 中校准什么](#3.2 RL 中校准什么)
  - [3.3 实用校准方法](#3.3 实用校准方法)
- [4. 四种 OOD-aware 决策架构](#4. 四种 OOD-aware 决策架构)
- - [4.1 Hard Switch：硬切换](#4.1 Hard Switch：硬切换)
  - [4.2 Soft Weighting：软加权](#4.2 Soft Weighting：软加权)
  - [4.3 Safety Filter：安全过滤器](#4.3 Safety Filter：安全过滤器)
  - [4.4 Human-in-the-Loop：人工接管](#4.4 Human-in-the-Loop：人工接管)
  - [4.5 四种架构对比总结](#4.5 四种架构对比总结)
- [5. 工业与机器人领域的实际案例](#5. 工业与机器人领域的实际案例)
- - [5.1 SODA-MPC：OOD 时切换安全控制器](#5.1 SODA-MPC：OOD 时切换安全控制器)
  - [5.2 SCOD：高效的任务相关不确定性估计](#5.2 SCOD：高效的任务相关不确定性估计)
  - [5.3 Duckietown 嵌入式 OOD 检测](#5.3 Duckietown 嵌入式 OOD 检测)
  - [5.4 Task-Relevant Failure Detection](#5.4 Task-Relevant Failure Detection)
- [6. Robust RL：从源头提升分布偏移下的鲁棒性](#6. Robust RL：从源头提升分布偏移下的鲁棒性)
- - [6.1 离线 RL 的保守学习](#6.1 离线 RL 的保守学习)
  - [6.2 Dynamics Shift 下的鲁棒性](#6.2 Dynamics Shift 下的鲁棒性)
  - [6.3 Distributionally Robust RL](#6.3 Distributionally Robust RL)
- [7. Trustworthy RL 全景](#7. Trustworthy RL 全景)
- [8. 可迁移的 OOD-aware RL 系统模板](#8. 可迁移的 OOD-aware RL 系统模板)
- [9. 部署时应该记录什么](#9. 部署时应该记录什么)
- [10. 五条实践原则](#10. 五条实践原则)
- - [10.1 单一信号不够](#10.1 单一信号不够)
  - [10.2 阈值必须校准](#10.2 阈值必须校准)
  - [10.3 区分 OOD 和任务风险](#10.3 区分 OOD 和任务风险)
  - [10.4 检测器不能拖慢主系统](#10.4 检测器不能拖慢主系统)
  - [10.5 回退策略必须可用且经过验证](#10.5 回退策略必须可用且经过验证)
- [11. 论文与开源代码地图：从"能检测"到"能接管"](#11. 论文与开源代码地图：从“能检测”到“能接管”)
- - [11.1 OOD / 不确定性 / 校准工具](#11.1 OOD / 不确定性 / 校准工具)
  - [11.2 决策门控、安全回退与 Safety Filter](#11.2 决策门控、安全回退与 Safety Filter)
  - [11.3 Safe RL 基准环境与算法框架](#11.3 Safe RL 基准环境与算法框架)
  - [11.4 离线 / 保守 / 不确定性感知 RL](#11.4 离线 / 保守 / 不确定性感知 RL)
  - [11.5 面向本文模板的仓库选型](#11.5 面向本文模板的仓库选型)
  - [11.6 持续追踪关键词](#11.6 持续追踪关键词)
- [12. 总结](#12. 总结)
- 参考文献

系列导航 ：本文是"强化学习 OOD 与可信决策"系列的第 2 篇，侧重检测之后的 决策与行动。第 1 篇《强化学习中的 OOD 检测：从状态异常到分布偏移》介绍了 OOD 的定义、分类和检测方法，建议先阅读。
适合读者：已了解 RL OOD 检测的基本概念，想进一步理解------检测到 OOD 之后系统应该如何决策、如何校准置信度、如何设计安全回退机制。
摘要：OOD 检测不是终点。对于强化学习系统来说，真正重要的问题是：当 agent 发现当前状态或动态可能偏离训练分布时，系统应该如何行动？本文聚焦检测之后的决策链路------从置信度评估的陷阱、校准方法，到四种主流决策架构（硬切换、软加权、安全过滤器、人工接管），再到工业案例、鲁棒 RL 和一个可迁移的系统模板。

关键词

OOD-aware Decision Making Confidence Calibration Trustworthy RL Safe RL Fallback Controller Safety Filter

1. 检测之后，才是真正的挑战

上一篇我们建立了 RL OOD 检测的知识框架。但在真实系统中，检测本身只是中间环节------很多论文止步于 AUROC / FPR95 等检测指标，却没有回答一个更关键的问题：

检测到 OOD 之后，agent 应该采取什么行动？

可能的选择至少有七种：

继续使用原 RL policy（信任模型的泛化能力）
降低 RL policy 的决策权重（部分信任）
切换到规则策略或保守策略（完全回退）
使用 safety filter 修正动作（保留 RL 输出但约束边界）
请求人工接管（高风险场景）
暂停系统并收集数据（保守但安全）
将该样本加入后续再训练数据（长期改进）

一个完整的 RL 部署系统不是简单的 state → policy → action，而是：

复制代码

state
  ↓
OOD / uncertainty / confidence 评估    ← 第 1 篇的内容
  ↓
decision gate（决策门控）               ← 本篇的核心
  ├── trust RL policy
  ├── use conservative policy
  ├── apply safety filter
  └── request human intervention
  ↓
execute action
  ↓
logging & monitoring                   ← 持续改进

本篇围绕这个 decision gate 展开。

2. 置信度的陷阱：agent 真的知道自己不知道吗？

在设计 decision gate 之前，必须先理解一个根本问题：RL agent 的置信度信号可靠吗？

2.1 过度自信的神经网络

一个 policy network 在某个 从未见过的 状态下可能输出：

复制代码

π(a₁ | s) = 0.98,  π(a₂ | s) = 0.01,  π(a₃ | s) = 0.01

看起来非常确定，但这个"确定"毫无意义------神经网络在 OOD 输入上也经常产生高置信度输出。这就是所谓的 overconfidence on OOD 问题。

因此，不能直接拿 policy 的 softmax 输出当作"是否可信"的判据。我们需要更多维度的信号，以及校准手段。

2.2 四类置信度信号对比

上一篇已介绍了 OOD 检测方法。这里从 decision gate 的视角 重新审视四类常用信号的可靠性：

信号	计算方式	优势	关键局限	适合驱动决策吗？
Policy Entropy	H ( π ) = − ∑ π ( a ∣ s ) log ⁡ π ( a ∣ s ) H(\pi) = -\sum \pi(a\|s) \log \pi(a\|s) H(π)=−∑π(a∣s)logπ(a∣s)	零额外开销	OOD 时也可能低 entropy	仅作辅助信号
Q Ensemble Variance	多个 Q 网络输出方差	直接反映动作价值可靠性	需要 ensemble，开销较大	推荐用于连续控制
Dynamics Uncertainty	多个 dynamics model 预测分歧	能检测环境变化	仅适用于 model-based RL	推荐用于机器人/控制
Conformal Score	任意分数 + 校准集分位阈值	有统计保证	需要校准数据	推荐用于安全关键场景

核心原则 ：单一信号不可靠。实际系统应组合 至少两类信号（如 Q variance + dynamics uncertainty），并通过校准为阈值提供统计依据。

3. Confidence Calibration：让置信度说真话

3.1 什么是校准

置信度校准的目标：

当模型说"我有 90% 的把握"时，它在这类情况下真的应该有大约 90% 的正确率。

在分类任务中，校准常用 ECE（Expected Calibration Error）、Brier score、temperature scaling。但在 RL 中，校准更难------agent 的"正确性"不只是单步预测，还涉及长期回报和系统安全。

3.2 RL 中校准什么

校准对象	含义	为什么重要
Action probability	动作概率是否反映可靠性	防止 overconfident 动作被盲目执行
Value / Q estimate	价值估计是否过度乐观	离线 RL 中 Q 过估计直接导致策略失效
Dynamics uncertainty	不确定性是否对应真实误差	不确定性偏低 → 错误信任模型预测
Failure probability	失败风险预测是否可靠	安全关键系统的底线

3.3 实用校准方法

Temperature Scaling（最简单）：

python 复制代码

# 对 policy logits 做温度缩放
calibrated_logits = logits / temperature
# temperature > 1 → 降低过度自信
# temperature 通过 validation set 的 NLL 最小化来学习

Conformal Prediction（有统计保证）：

python 复制代码

# 1. 在 calibration set 上收集 nonconformity scores
cal_scores = [detector.score(s) for s in calibration_states]
# 2. 取 95% 分位数作为阈值
threshold = np.quantile(cal_scores, 0.95)
# 3. 部署时超过阈值 → 标记为不可信

PAC Confidence Sets：在理论上保证"以至少 1-δ 的概率，真实值落在预测区间内"。计算复杂但适合需要形式化安全证明的系统。

实践建议 ：如果只能选一个校准方法，选 Conformal Prediction------它对底层分数类型没有假设，阈值来自数据而非拍脑袋，且 95% 分位数这个概念对工程师和审核人员都容易解释。

4. 四种 OOD-aware 决策架构

这是本篇的核心。检测到 OOD 或低置信度后，系统如何行动？以下四种架构从简单到复杂排列。

4.1 Hard Switch：硬切换

最简单的方式------设阈值，过了就切。

python 复制代码

if ood_score > threshold or calibrated_confidence < min_confidence:
    action = safe_policy(state)
    reason = "ood_fallback"
else:
    action = rl_policy(state)
    reason = "rl_policy"

维度	评价
优点	实现简单、可解释、审计友好
缺点	阈值附近容易频繁切换（chattering）；对"灰色地带"处理粗糙
适合场景	快速原型、对安全要求极高（宁可多切也不能冒险）的系统

工程改进 ：加入 hysteresis（滞回） 机制缓解频繁切换------用两个阈值 θ h i g h \theta_{high} θhigh 和 θ l o w \theta_{low} θlow，进入 OOD 需要超过 θ h i g h \theta_{high} θhigh，恢复正常需要降到 θ l o w \theta_{low} θlow 以下。

python 复制代码

class HysteresisSwitch:
    def __init__(self, theta_high, theta_low):
        self.theta_high = theta_high
        self.theta_low = theta_low
        self.in_safe_mode = False

    def should_use_safe_policy(self, ood_score):
        if not self.in_safe_mode and ood_score > self.theta_high:
            self.in_safe_mode = True
        elif self.in_safe_mode and ood_score < self.theta_low:
            self.in_safe_mode = False
        return self.in_safe_mode

4.2 Soft Weighting：软加权

根据信任度连续融合 RL 策略和安全策略的输出：

a = α ⋅ a rl + ( 1 − α ) ⋅ a safe a = \alpha \cdot a_{\text{rl}} + (1 - \alpha) \cdot a_{\text{safe}} a=α⋅arl+(1−α)⋅asafe

其中 α ∈ [ 0 , 1 ] \alpha \in [0, 1] α∈[0,1] 是信任权重，可以来自：

归一化后的 OOD score（取反）
校准后的 policy confidence
Q ensemble agreement

维度	评价
优点	比硬切换更平滑，可以表达"部分信任"
缺点	两个策略的动作空间需要可比和可混合；安全性形式证明困难
适合场景	连续控制任务（动作可以线性插值），如机器人关节角度控制

注意：对离散动作空间，软加权通常不适用（不能取两个离散动作的"中间值"）。此时可以改为在 动作概率分布 上做加权混合。

4.3 Safety Filter：安全过滤器

Safety filter 不否定 RL policy，而是 事后检查并修正 其输出：

python 复制代码

candidate_action = rl_policy(state)

if safety_filter.is_safe(state, candidate_action):
    action = candidate_action              # 通过安全检查
else:
    action = safety_filter.project_to_safe_set(state, candidate_action)
    # 将动作投影到最近的安全集合内

工作原理 ：safety filter 维护一个 安全约束集合（如关节力矩上限、最小安全距离、状态边界），RL 的动作只要不违反这些约束就放行，否则投影到约束边界上最近的合法动作。

维度	评价
优点	RL 策略的自由度最大化------只在必要时干预；与 OOD 检测解耦
缺点	需要明确定义安全约束（很多场景约束难以形式化）；投影操作可能引入新问题
适合场景	存在明确硬约束的任务------机器人力矩限制、自动驾驶最小跟车距离、工业过程温度/压力上限

典型实现：Control Barrier Function (CBF)、Hamilton-Jacobi reachability、constrained optimization layer。

4.4 Human-in-the-Loop：人工接管

高风险场景下的最后一道防线------系统检测到 OOD 后请求人工接管。

维度	评价
优点	安全性最高
缺点	人工响应延迟、注意力疲劳、不可 24/7
适合场景	医疗决策、工业安全系统、自动驾驶极端场景、高价值设备控制

三个关键设计原则：

不要所有不确定性都交给人工，否则人工负担过重、alert fatigue 会导致真正重要的警报被忽略。应设计触发条件和事件优先级。
接管过程必须平滑------系统在等待人工响应期间应自动切换到保守策略，而不是"冻结"。
记录人工接管数据------这些数据是最有价值的再训练样本，因为它们标注了"模型失败但人类成功"的边界场景。

4.5 四种架构对比总结

架构	复杂度	安全性保证	适合动作空间	典型场景
Hard Switch	低	依赖 safe policy 质量	离散/连续	快速原型、高安全要求
Soft Weighting	中	难以形式化	连续	机器人控制
Safety Filter	中-高	约束层面可形式化	连续	有明确硬约束的控制
Human-in-Loop	高	最高（人类兜底）	任意	医疗、高价值设备

实践中最常见的组合：Hard Switch + Safety Filter------先用 OOD score 决定信任 RL 还是回退，再用 safety filter 对最终动作做约束检查。

5. 工业与机器人领域的实际案例

5.1 SODA-MPC：OOD 时切换安全控制器

方向：Safe, Out-of-Distribution-Adaptive Model Predictive Control with Conformalized Neural Network Ensembles
核心做法：使用 neural network ensemble 做预测 → conformal detector 判断是否 OOD → 如果预测模型不可靠，切换到更保守的安全 MPC 控制器。
启发：OOD 检测不应该只输出报警，而应该 直接影响控制策略的选择。这正是 decision gate 的工程化体现。

5.2 SCOD：高效的任务相关不确定性估计

论文：Sketching Curvature for Efficient Out-of-Distribution Detection for Deep Neural Networks
代码：StanfordASL/SCOD
核心做法 ：基于 curvature / Fisher information 估计模型不确定性，目标是高效地为深度模型提供 OOD score，适合部署到机器人、自动驾驶等需要 毫秒级推理 的系统。
关键价值 ：证明了 OOD detector 的 计算效率 不是次要问题------如果 detector 推理需要 100ms 而控制周期只有 10ms，这个 detector 就无法上线。

5.3 Duckietown 嵌入式 OOD 检测

场景：Duckietown 自主机器人
代码：CPS-NTU-Public
核心做法 ：用轻量 VAE 检测视觉输入是否 OOD → 在嵌入式设备上实时运行 → 检测到异常触发 emergency braking。
启发：对真实系统来说，OOD detector 必须同时考虑实时性、资源限制和安全动作。一个完美但跑不动的 detector 不如一个粗糙但能实时响应的 detector。

5.4 Task-Relevant Failure Detection

代码：NVlabs/pred-fail-detector
核心观点 ：不是所有预测误差都同等重要，应优先检测 会影响下游决策或安全的错误。

这一点非常关键：

一个系统可能遇到很多分布变化，但只有一部分变化真的影响任务表现。实际部署时，应尽量检测 task-relevant OOD，而不是把所有统计偏移都视为风险。否则会导致过多的误报和不必要的回退。

6. Robust RL：从源头提升分布偏移下的鲁棒性

除了部署时的 decision gate，还可以在 训练阶段 就提高模型对分布偏移的抵抗力。

6.1 离线 RL 的保守学习

（详细方法介绍见第 1 篇第 5 节，此处列出核心对比）

方法	核心策略	代码
CQL	压低 OOD 动作的 Q 值	CQL
MOPO	用 dynamics 不确定性作为 reward penalty	MOPO
MOReL	将未知区域建模为悲观吸收状态	MOReL
UWAC	对高不确定 (s, a) 降低训练权重	UWAC
IQL	避免显式选择数据外动作	IQL

这些方法本质上都在训练阶段就植入了"对 OOD 的戒心"，使得模型部署后天然地远离不可靠区域。

6.2 Dynamics Shift 下的鲁棒性

当环境动态本身发生变化时，常见应对方式：

Domain Randomization：训练时随机化环境参数，让策略见过更多变化。
Dynamics Ensemble：用多个动力学模型，高分歧区域自动悲观。
Online Adaptation：部署时持续微调模型。
Robust Policy Optimization：优化最坏情况下的表现。

6.3 Distributionally Robust RL

DR-RL 假设测试分布可能落在训练分布附近的某个不确定集合内，优化目标是 最坏情况表现：

max ⁡ π min ⁡ P ∈ U E P [ Return ( π ) ] \max_\pi \min_{P \in \mathcal{U}} \mathbb{E}_P[\text{Return}(\pi)] πmaxP∈UminEP[Return(π)]

权衡：安全性更高，但保守性也更强------可能牺牲平均性能来换取最坏情况的底线。适合高风险、低容错的系统。

7. Trustworthy RL 全景

OOD-aware decision making 是 可信强化学习（Trustworthy RL） 的一个核心组件。完整的可信 RL 涉及多个方向：

方向	关注问题	与 OOD 的关系
Robustness	分布变化、扰动、攻击下是否稳定	OOD 检测是鲁棒性的前置条件
Safety	是否避免危险状态和非法动作	safety filter 是 OOD 后的主要执行机制
Generalization	是否能泛化到新环境	泛化失败 = 某种形式的 OOD
Explainability	决策是否可解释	OOD 回退原因需要可解释
Uncertainty	是否知道自己不确定	不确定性估计驱动 decision gate
Calibration	置信度是否可靠	校准后的置信度才能可靠地驱动决策
Monitoring	部署后是否持续监控	OOD 事件日志是监控的核心数据

这些方向不是孤立的------它们沿着一条链路连接：

复制代码

OOD detection → uncertainty estimation → confidence calibration
    → safe / conservative decision making → deployment monitoring

8. 可迁移的 OOD-aware RL 系统模板

以下给出一个可迁移到各类 RL 项目的完整系统模板。

python 复制代码

import numpy as np
from dataclasses import dataclass, field
from typing import Any, Dict, List


@dataclass
class DecisionRecord:
    """单步决策的完整记录，用于事后分析和模型迭代"""
    state: Any
    action: Any
    ood_score: float
    raw_confidence: float
    calibrated_confidence: float
    decision_reason: str  # "rl_policy" / "ood_fallback" / "low_confidence" / "safety_repair"
    safety_check_passed: bool


class OODAwareAgent:
    """OOD 感知的 RL Agent 模板"""
    
    def __init__(self, rl_policy, safe_policy, detector, calibrator, safety_filter):
        self.rl_policy = rl_policy          # 主策略（学习得到）
        self.safe_policy = safe_policy      # 保守策略（规则/手工设计）
        self.detector = detector            # OOD 检测器
        self.calibrator = calibrator        # 置信度校准器
        self.safety_filter = safety_filter  # 安全过滤器
        self.decision_log: List[DecisionRecord] = []
    
    def act(self, state) -> tuple:
        features = extract_features(state)
        
        # 1. OOD 检测
        ood_score = self.detector.score(features)
        
        # 2. 置信度评估 + 校准
        raw_confidence = self.rl_policy.confidence(state)
        calibrated_confidence = self.calibrator(raw_confidence)
        
        # 3. Decision Gate
        if ood_score > self.detector.threshold:
            action = self.safe_policy(state)
            reason = "ood_fallback"
        elif calibrated_confidence < 0.5:
            action = self.safe_policy(state)
            reason = "low_confidence"
        else:
            action = self.rl_policy(state)
            reason = "rl_policy"
        
        # 4. Safety Filter（最后一道防线）
        safety_passed = self.safety_filter.is_safe(state, action)
        if not safety_passed:
            action = self.safety_filter.project_to_safe_set(state, action)
            reason = "safety_repair"
        
        # 5. 记录
        record = DecisionRecord(
            state=state, action=action,
            ood_score=ood_score,
            raw_confidence=raw_confidence,
            calibrated_confidence=calibrated_confidence,
            decision_reason=reason,
            safety_check_passed=safety_passed,
        )
        self.decision_log.append(record)
        
        return action, record.__dict__
    
    def get_statistics(self) -> Dict:
        """统计各类决策的占比，用于评估系统健康度"""
        if not self.decision_log:
            return {}
        reasons = [r.decision_reason for r in self.decision_log]
        total = len(reasons)
        return {
            "total_decisions": total,
            "rl_policy_ratio": reasons.count("rl_policy") / total,
            "ood_fallback_ratio": reasons.count("ood_fallback") / total,
            "low_confidence_ratio": reasons.count("low_confidence") / total,
            "safety_repair_ratio": reasons.count("safety_repair") / total,
            "mean_ood_score": np.mean([r.ood_score for r in self.decision_log]),
            "mean_confidence": np.mean([r.calibrated_confidence for r in self.decision_log]),
        }

这个模板包含五个关键部件，缺一不可：

部件	作用	如果缺失会怎样
RL policy	主要学习策略	没有智能决策能力
OOD detector	判断是否偏离训练分布	在 OOD 状态下盲目执行
Confidence calibrator	校准置信度	过度自信导致错误信任
Safe policy	低风险保守策略	检测到 OOD 但无处回退
Safety filter	检查/修复动作	即使回退也可能违反硬约束

9. 部署时应该记录什么

OOD-aware 系统上线后，日志质量直接决定了后续迭代的速度。推荐记录：

字段	用途
`ood_score`	事后分析 OOD 分布趋势
`calibrated_confidence`	检查校准是否漂移
`decision_reason`	统计各策略使用占比
`safety_check_passed`	评估 safety filter 触发频率
`state` / `action`	复现问题、构造再训练数据
`timestamp`	时序分析，发现渐变式 drift

关键指标 ：如果 ood_fallback_ratio 持续升高，说明环境可能在持续偏移，需要重新收集数据或在线适应。如果 safety_repair_ratio 非零但稳定，说明 safety filter 在正常工作。

10. 五条实践原则

10.1 单一信号不够

不要只用 policy entropy 或只用 OOD score 来驱动 decision gate。推荐组合至少两类信号（如 state OOD score + Q ensemble variance），用 conformal 方法统一校准。

10.2 阈值必须校准

不要凭直觉设阈值：

python 复制代码

# 不推荐
if ood_score > 0.5: ...

# 推荐：基于 calibration set 的分位数
threshold = np.quantile(calibration_scores, 0.95)

10.3 区分 OOD 和任务风险

不是所有 OOD 都危险，也不是所有危险都表现为 OOD。更实用的目标是：

检测 会影响任务表现或安全的 分布变化（task-relevant OOD）。

过于敏感的 detector 会导致频繁误报和不必要的回退，反而降低系统表现。

10.4 检测器不能拖慢主系统

部署时要考虑：detector 推理延迟是否低于控制周期？是否可以缓存特征？是否可以异步运行？是否需要用轻量模型（如 SCOD）？

经验法则：detector 推理时间应 < 主策略推理时间的 50%。

10.5 回退策略必须可用且经过验证

如果系统检测到 OOD，却没有可靠的 fallback policy，那么检测结果只能变成报警，无法真正提升系统可靠性。

OOD-aware RL 的三要素缺一不可：

复制代码

detector + decision gate + fallback policy

11. 论文与开源代码地图：从"能检测"到"能接管"

说明：标注 ✅ 表示有公开仓库，可作为复现实验起点；标注 ⚠️ 表示论文/项目明确相关但代码不完整、维护较弱或需自行补齐；标注 📄 表示重要论文但暂未检索到稳定公开代码。

这一节参考 FJSP 笔记的组织方式，不再只列"推荐阅读"，而是按 检测与校准 → 决策门控与安全回退 → SafeRL 基准 → 离线鲁棒 RL 四条线索整理。

11.1 OOD / 不确定性 / 校准工具

这一类代码本身不一定是 RL 专用，但可以直接接入前文的 detector、calibrator 或 decision gate 模块。

仓库	框架	核心能力	对应论文 / 项目	代码状态
kkirchheim/pytorch-ood	PyTorch	OOD detector、训练后评分、AUROC/FPR95 等指标	PyTorch OOD 工具库	✅
Jingkang50/OpenOOD	PyTorch	generalized OOD benchmark、方法集合、统一评估	OpenOOD / Full-Spectrum OOD Detection	✅
SeldonIO/alibi-detect	Python	异常检测、数据漂移检测、对抗样本检测	Alibi Detect 工程工具库	✅
StanfordASL/SCOD	PyTorch	curvature / Fisher 近似的高效 OOD score	Sketching Curvature for Efficient OOD Detection, ICRA 2021	✅
NVlabs/pred-fail-detector	PyTorch	任务相关失败预测，而非泛化地检测所有分布偏移	Task-Relevant Failure Detection	✅
IntelLabs/AVUC	PyTorch	Accuracy versus Uncertainty Calibration	Improving Model Calibration with Accuracy versus Uncertainty Optimization, NeurIPS 2020	⚠️ 已归档
awslabs/fortuna	JAX / Python	calibration、conformal prediction、Bayesian UQ	AWS Fortuna 不确定性量化工具库	⚠️ 已归档但文档完整

选型建议：

做图像或通用深度模型的 OOD 基线，优先用 OpenOOD 或 pytorch-ood。
做真实部署监控，Alibi Detect 的漂移检测与告警链路更接近工程形态。
控制周期很短、不能承受大 ensemble 开销时，优先看 SCOD 这类轻量不确定性估计。
目标不是"发现任何异常"，而是"发现会导致任务失败的异常"时，优先参考 pred-fail-detector。

11.2 决策门控、安全回退与 Safety Filter

这类工作最贴近本文主题：检测到不可信之后，系统不是停在告警，而是切换、修正或接管。

仓库 / 论文	场景	核心方法	适合接入本文哪个模块	代码状态
CMU-IntentLab/UNISafe	机器人视觉控制	world model epistemic uncertainty + conformal threshold + HJ reachability	`safety_filter` + `detector`	✅
abalakrishna123/recovery-rl	安全探索 / 机器人控制	task policy 与 recovery policy 分离，风险升高时由 recovery policy 拉回安全区	`safe_policy` / fallback controller	✅
liuzuxin/safe-mbrl	Safety Gym 连续控制	uncertainty-aware dynamics ensemble + robust CEM / MPC	model-based `decision gate`	✅
Safe, Out-of-Distribution-Adaptive MPC with Conformalized Neural Network Ensembles	自动驾驶 / MPC	conformalized ensemble 识别 OOD 预测，触发 reachability-based fallback	`detector` + hard switch + fallback MPC	📄
Safety on the Fly: RPCBF	非线性系统安全控制	runtime policy CBF，在线构造 robust safety filter	`safety_filter`	📄 / 项目页
Safe RL via Shielding	形式化安全约束	shield 在运行时屏蔽不安全动作	离散动作 `safety_filter`	📄

方法差异：

Recovery RL 的思路最容易迁移到普通 RL 项目：保留主策略，再额外训练一个"救援策略"。
UNISafe 更适合高维视觉与机器人任务：它把 world model 的 epistemic uncertainty 纳入 reachability，专门处理 unseen failure。
SODA-MPC 是本文 decision gate 思想最清晰的控制版本：OOD 分数不是展示指标，而是直接决定是否使用安全 MPC。
Shielding / CBF 更偏形式化安全：当硬约束能写清楚时，比单纯置信度阈值更可靠。

11.3 Safe RL 基准环境与算法框架

如果研究目标是系统比较"安全性、回报、泛化、回退频率"，不要从零搭环境，优先用以下框架。

仓库	框架	定位	适合做什么实验	代码状态
PKU-Alignment/omnisafe	PyTorch	SafeRL 算法库，覆盖 CPO、PPO-Lag、FOCOPS、COptDICE、Recovery RL 等	对比安全约束优化算法	✅
PKU-Alignment/safety-gymnasium	Gymnasium / MuJoCo	SafeRL 统一环境，step 返回 reward 与 cost	训练和评估 constrained RL / SafeRL	✅
learnsyslab/safe-control-gym	PyBullet + CasADi	CartPole / Quadrotor，带符号动力学与安全约束	连接传统控制、MPC、RL、安全过滤器	✅
openai/safety-gym	Gym / MuJoCo	早期 SafeRL 安全探索基准	复现经典 SafeRL 论文	⚠️ 维护较弱
SafeRL-Lab/Robust-Gymnasium	Gymnasium	鲁棒 RL 基准，覆盖状态、动作、奖励、动力学扰动	OOD / domain shift 压力测试	✅
openai/procgen	Gym	程序生成环境，训练/测试关卡分离	RL 泛化与视觉 OOD 测试	✅
google-research/rliable	Python	RL 结果统计评估，IQM、置信区间、性能分布	让 OOD / SafeRL 实验报告更可信	✅

实验设计建议：

如果要验证"安全约束是否满足"，用 Safety-Gymnasium 或 safe-control-gym，因为它们把 cost / constraint 显式暴露出来。
如果要验证"分布偏移下是否退化"，用 Robust-Gymnasium、Procgen 或自定义动力学扰动。
如果要写论文或技术报告，不要只报 mean reward；用 rliable 报 IQM、bootstrap CI、probability of improvement，更符合近年 RL 评估规范。

11.4 离线 / 保守 / 不确定性感知 RL

这些方法不一定在部署时做 OOD 检测，但它们从训练目标上抑制 OOD 动作或 OOD 状态-动作对，是 decision gate 的前置防线。

仓库	方法	核心思想	与 OOD-aware decision 的关系	代码状态
aviralkumar2907/CQL	Conservative Q-Learning	压低数据外动作的 Q 值，减少过估计	降低部署时盲目选择 OOD action 的概率	✅
tianheyu927/mopo	MOPO	model uncertainty 作为 reward penalty	把 dynamics uncertainty 转化为保守回报	✅
SwapnilPande/MOReL	MOReL	将未知区域建模为悲观吸收状态	训练阶段就把 OOD 区域视为风险区	✅
apple/ml-uwac	UWAC	用 epistemic uncertainty 下调高不确定样本权重	直接把 OOD state-action pair 的贡献降权	✅
ikostrikov/implicit_q_learning	IQL	避免显式选择数据外动作	简洁强基线，适合与 CQL/UWAC 对比	✅
tinkoff-ai/CORL	CORL	单文件高质量 Offline RL 实现集合	快速搭建 CQL/IQL/Cal-QL/ReBRAC 等对比	✅

定位区别：

CQL / IQL 是离线 RL 的强基线，适合先确认任务本身是否可学。
MOPO / MOReL 更适合 model-based 场景，因为它们显式利用模型不确定性。
UWAC 与本文主题最直接：它将 epistemic uncertainty 用作 OOD state-action pair 的训练权重。
CORL 适合做统一复现实验，减少不同仓库之间的工程噪声。

11.5 面向本文模板的仓库选型

复制代码

你的目标是什么？
├── 做 OOD score / calibration 基线
│   └── 推荐：OpenOOD、pytorch-ood、SCOD、AVUC
├── 做"检测后如何行动"的安全回退
│   ├── 连续控制 / MPC：SODA-MPC、safe-mbrl
│   ├── 机器人视觉控制：UNISafe
│   └── 简洁可迁移 fallback：Recovery RL
├── 做 SafeRL 算法对比
│   └── 推荐：OmniSafe + Safety-Gymnasium
├── 做控制理论 + RL 安全过滤器
│   └── 推荐：safe-control-gym、CBF / shielding 相关实现
├── 做分布偏移下的泛化评估
│   └── 推荐：Robust-Gymnasium、Procgen、rliable
└── 做离线 RL 的保守训练
    └── 推荐：CQL、IQL、UWAC、CORL

11.6 持续追踪关键词

GitHub topics：safe-reinforcement-learning、offline-reinforcement-learning、out-of-distribution-detection、uncertainty-estimation
arXiv 关键词：OOD reinforcement learning、uncertainty-aware safety filter、conformal prediction control、safe model-based reinforcement learning、distributionally robust reinforcement learning
会议方向：CoRL / ICRA / RSS 的机器人安全过滤器，NeurIPS / ICML / ICLR 的 SafeRL 与 Offline RL，AAAI / IJCAI 的可信决策与形式化安全。

12. 总结

OOD-aware decision making 的核心不是"检测到异常"本身，而是 检测之后如何行动。

一个可靠的强化学习系统应该具备以下完整链路：

复制代码

OOD detection        → 识别分布偏移
  ↓
uncertainty estimation → 量化不确定性
  ↓
confidence calibration → 校准置信度（让数字说真话）
  ↓
decision gate          → 选择 RL / 保守 / 安全修复 / 人工接管
  ↓
monitoring & logging   → 记录事件、持续改进

这条链路也是从普通强化学习走向 可信强化学习、鲁棒强化学习和安全部署 的关键路径。

参考文献

Lakshminarayanan, B. et al. (2017). Simple and Scalable Predictive Uncertainty Estimation using Deep Ensembles. NeurIPS.
Guo, C. et al. (2017). On Calibration of Modern Neural Networks. ICML.
Kumar, A. et al. (2020). Conservative Q-Learning for Offline Reinforcement Learning. NeurIPS.
Yu, T. et al. (2020). MOPO: Model-based Offline Policy Optimization. NeurIPS.
Sharma, A. et al. (2021). Sketching Curvature for Efficient Out-of-Distribution Detection (SCOD). ICRA.
Garcia, J. & Fernandez, F. (2015). A Comprehensive Survey on Safe Reinforcement Learning. JMLR.
Gu, S. et al. (2022). A Review of Safe Reinforcement Learning: Methods, Theories and Applications.
Vovk, V. et al. (2005). Algorithmic Learning in a Random World (Conformal Prediction).
Thananjeyan, B. et al. (2021). Recovery RL: Safe Reinforcement Learning with Learned Recovery Zones. IEEE Robotics and Automation Letters . [代码]
Liu, Z. et al. (2020). Safe Model-based Reinforcement Learning with Robust Cross-Entropy Method. [代码]
Seo, J. et al. (2025). UNISafe: Uncertainty-aware Latent Safety Filters for Avoiding Out-of-Distribution Failures. CoRL . [项目] [代码]
Alshiekh, M. et al. (2018). Safe Reinforcement Learning via Shielding. AAAI . [论文]
Liu, A. et al. (2024). Safe, Out-of-Distribution-Adaptive Model Predictive Control with Conformalized Neural Network Ensembles. [论文]
So, O. et al. (2024). Safety on the Fly: Runtime Policy CBF for Safe Reinforcement Learning. [项目]
Ji, J. et al. (2024). OmniSafe: An Infrastructure for Accelerating Safe Reinforcement Learning Research. JMLR . [代码]
Ji, J. et al. (2023). Safety-Gymnasium: A Unified Safe Reinforcement Learning Benchmark. NeurIPS Datasets and Benchmarks . [代码]
Yuan, Z. et al. (2022). safe-control-gym: a Unified Benchmark Suite for Safe Learning-based Control and Reinforcement Learning in Robotics. IEEE RA-L . [代码]
Ray, A. et al. (2019). Benchmarking Safe Exploration in Deep Reinforcement Learning. [Safety Gym]
Wu, P. et al. (2021). Uncertainty Weighted Actor-Critic for Offline Reinforcement Learning. [代码]
Agarwal, R. et al. (2021). Deep Reinforcement Learning at the Edge of the Statistical Precipice. NeurIPS . [代码]