Reinforcement Learning / Offline RL：CQL 与策略决策
强化学习不是“让模型自己试错”的产品话术，而是一套描述连续决策的系统语言：在某个业务状态下，系统可以采取哪些动作，动作带来什么即时反馈，又如何改变未来状态、成本、风险和客户关系。金融零售和企业 AI 的关键难点通常不在算法名，而在历史轨迹是否完整、奖励是否代表真实目标、离线策略能否被可靠评估、线上探索是否会伤害客户，以及高风险动作是否被合规、风控和人工门禁约束。
Reinforcement Learning / Offline RL / CQL / Policy Decisioning 解读
Source Anchors
| Source | Link | 读它要抓住什么 |
|---|---|---|
| Sutton & Barto, Reinforcement Learning | http://incompleteideas.net/book/the-book-2nd.html | MDP、policy、value、reward、exploration、on-policy/off-policy 的基本语言 |
| DQN | https://www.nature.com/articles/nature14236 | value function、experience replay、target network 如何让深度 RL 成为可训练系统 |
| OpenAI Spinning Up | https://spinningup.openai.com/en/latest/ | policy gradient、actor-critic、PPO 等深度 RL 方法的概念地图 |
| Conservative Q-Learning | https://arxiv.org/abs/2006.04779 | offline RL 中 distribution shift 和 value overestimation 的核心风险，以及保守 Q 值估计 |
| Decision Transformer | https://arxiv.org/abs/2106.01345 | 把轨迹建模成序列预测任务的另一条 offline decision learning 路线 |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 把策略学习系统纳入风险识别、测量、管理和持续监控 |
核心导读
强化学习不是“让模型自己试错”的产品话术，而是一套描述连续决策的系统语言：在某个业务状态下，系统可以采取哪些动作，动作带来什么即时反馈，又如何改变未来状态、成本、风险和客户关系。金融零售和企业 AI 的关键难点通常不在算法名，而在历史轨迹是否完整、奖励是否代表真实目标、离线策略能否被可靠评估、线上探索是否会伤害客户，以及高风险动作是否被合规、风控和人工门禁约束。
Offline RL 和 CQL 的价值，是在不能随意在线试验的场景中，从历史策略留下的数据学习候选策略，同时主动压低分布外动作的价值估计。它把“更聪明的决策模型”转化为一套 policy decisioning architecture：数据轨迹、行为策略、奖励建模、保守学习、离线评估、灰度上线、人工覆核、审计证据和持续监控必须一起成立。
问题定义
很多金融零售决策不是一次性分类问题。欺诈系统不只是判断“是否欺诈”，还要选择放行、强认证、延迟、人工复核、额度收紧或拒绝；催收系统不只是预测“会不会还款”，还要选择触达渠道、宽限、还款计划、暂停触达或升级关怀；企业 Agent 不只是回答问题，还要决定检索、澄清、调用工具、拒答、升级人工或停止。
这些动作会改变后续状态。一次强认证可能降低欺诈损失，也可能增加客户流失；一次催收电话可能提高短期回款，也可能提高投诉、压力和长期损害；一次 Agent 工具调用可能完成任务，也可能扩大数据暴露面。把这类问题压成单点分类，会把系统推向短期、局部、不可审计的优化。
序列决策问题需要先回答七个边界问题：
| 边界问题 | 架构含义 |
|---|---|
| 状态是否完整 | 决策时可见的信息必须可重放，不能用未来信息训练 |
| 动作集合是否受控 | 高风险动作要有资格条件、审批、限额和禁区 |
| 奖励是否稳健 | 奖励不能只看短期收益，要纳入投诉、损失、合规、人工成本和长期关系 |
| 历史策略是否可识别 | 必须知道历史动作为什么被选中，否则离线学习会误读选择偏差 |
| 评估是否可信 | 不能只看训练分数，要有 off-policy evaluation、回放、反事实敏感性分析 |
| 探索是否允许 | 金融场景常常只能做受限探索或影子运行 |
| 谁拥有最终决策 | 策略服务可以推荐动作，但责任边界、覆核和停机权必须明确 |
核心原理/方法
MDP 把业务决策抽象成 state -> action -> reward -> next state。Policy 是在状态下选择动作的规则；value function 估计某状态或状态-动作组合的长期价值；reward 不是业务 KPI 的简单替身，而是对即时收益、未来风险和约束违背的工程化表达。
Bandit、监督学习和强化学习的边界要分清：
| 方法 | 适合的问题 | 主要盲点 |
|---|---|---|
| 监督学习 | 预测一个结果，如欺诈概率、还款概率、流失概率 | 不直接回答“采取哪个动作最优” |
| Contextual bandit | 单步动作选择，如 offer、排序、提示策略 | 弱化动作对未来状态的影响 |
| Online RL | 可在线探索且反馈充分的连续控制 | 对客户、合规和资金风险不友好 |
| Offline RL | 从历史轨迹学习候选策略 | 容易对历史数据没覆盖的动作过度乐观 |
| CQL | 保守的 offline value learning | 可能牺牲收益上限，换取分布外安全性 |
| Decision Transformer | 把轨迹当序列建模 | 仍需要可控动作、奖励定义和离线评估 |
CQL 的核心不是“更复杂的 Q-learning”，而是对 offline RL 最危险的错误做结构性约束：当训练数据没有充分观察某些动作时，普通 value learning 可能因为函数逼近误差把这些动作估得过高；CQL 通过保守正则项压低未充分支持动作的 Q 值，让策略更倾向选择历史数据支持较好的动作。它降低的是 overestimation 和 distribution shift 风险，不是替代业务控制。
Off-policy evaluation 是上线前的关键控制层。重要的不是某个估计器名称，而是组合证据：行为策略覆盖、propensity/selection bias、重要性采样稳定性、doubly robust 估计、分层 cohort 表现、极端场景回放、约束违背率、敏感性分析和人工抽样复核。
系统/架构模型
一个可上线的 offline policy decisioning 系统至少需要以下链路：
业务事件与决策日志
-> 状态构建与时间点特征
-> 行为策略识别与动作约束
-> 奖励与风险标签建模
-> 轨迹数据集与质量门禁
-> Offline RL / CQL policy lab
-> 离线评估与反事实回放
-> 策略注册、审批和版本管理
-> runtime policy service
-> 人工覆核、限额、kill switch
-> 监控、漂移、反馈和审计证据
关键架构对象：
| 对象 | 必须记录什么 |
|---|---|
| Decision event | 时间、主体、状态快照、可选动作、实际动作、动作来源、审批路径 |
| Behavior policy | 历史策略版本、规则/模型/人工来源、选择概率或可解释选择逻辑 |
| Trajectory | 同一主体跨时间的状态、动作、反馈和终局结果 |
| Reward contract | 收益、成本、风险、约束罚项、时间窗口、不可优化指标 |
| Action guardrail | 动作资格、硬性禁区、人工门槛、额度、频率、冷却期 |
| OPE report | 数据覆盖、估计方法、分层表现、置信区间、失效模式 |
| Policy artifact | 模型版本、训练数据版本、约束版本、审批记录和回滚路径 |
Runtime 不应该直接暴露“模型决定”。更稳健的服务形态是 recommendation + rationale + confidence + guardrail decision + evidence link，由规则、权限、限额、人工覆核和业务流程共同完成最终动作。
关键机制与取舍
状态设计的取舍是信息充分性与泄漏风险。状态必须代表决策时真实可见的信息，不能把未来还款、后续欺诈确认、人工调查结论等事后信息混入训练特征。金融场景还要保留“为何可见”的 lineage，否则审计无法判断模型是否使用了不该使用的数据。
动作设计的取舍是策略灵活性与可控性。动作空间越细，策略可能越精准，但数据覆盖越稀疏，离线评估越不稳定。催收、欺诈、额度、Agent 工具调用这类场景通常要把动作分层：低风险动作可自动执行，中风险动作限额执行，高风险动作只推荐给人工。
奖励设计的取舍是短期 KPI 与长期责任。单纯用回款、拦截欺诈、节省人工成本作为 reward，会把系统推向过度干预。更合理的 reward contract 要纳入客户伤害、投诉、复逾、误杀、监管风险、人工处理成本、延迟和公平性约束。某些指标不能被 reward 化，只能作为硬约束，例如禁止对受保护群体产生不可接受差异影响。
CQL 的取舍是保守性与收益上限。保守策略可能错过历史策略没有尝试过的好动作，但金融零售上线通常先要求“不做坏事”，再逐步证明增益。若业务需要探索，应使用受控实验、低风险 cohort、人工复核和逐步放量，而不是让 offline policy 在全量客户上直接承担探索。
策略上线的取舍是自动化速度与责任清晰度。高成熟路径通常是：
离线回放 -> shadow mode -> 人工辅助推荐 -> 低风险自动执行 -> 分层放量 -> champion/challenger
每一步都要定义降级条件、异常处理、人工覆盖权和回滚触发器。
证据与控制
Offline RL 系统的证据包不应只是模型指标。最小可审计证据包括：
| 控制域 | 证据 |
|---|---|
| 数据完整性 | 决策日志覆盖率、缺失动作分析、时间点特征校验、标签延迟说明 |
| 策略可识别性 | 历史策略版本、规则配置、人工队列逻辑、动作选择偏差说明 |
| 奖励治理 | reward contract、业务签署、风险罚项、不可优化约束 |
| 离线评估 | OPE 方法、置信区间、cohort 结果、压力场景、敏感性分析 |
| 模型风险 | 分布外动作检测、价值估计上界、漂移监控、校准和复核计划 |
| 决策控制 | 动作 guardrail、人工覆核、职责隔离、审批、override 和 kill switch |
| 运行审计 | 每次建议的状态快照、策略版本、约束版本、解释、最终动作和操作者 |
证据控制的核心是可重放。审计或问题复盘时，团队应能回答：当时系统看到了什么、可选动作是什么、为何推荐该动作、哪些约束生效、谁批准或覆盖、后续反馈如何进入监控但不污染历史基线。
金融零售/AI产品场景
催收策略决策适合用 offline RL 思维建模，但不适合无约束自动化。状态包括逾期阶段、还款历史、承诺履约、渠道偏好、投诉风险、困难客户标识和监管限制；动作包括短信、电话、邮件、宽限、还款计划、暂停触达和人工关怀；reward 要平衡回款、复逾、投诉、客户伤害和运营成本。高风险客户或脆弱客户应进入人工路径。
欺诈干预策略可以把单笔风险评分升级为序列干预策略。动作包括放行、强认证、延迟、人工复核、额度调整和拒绝。系统要避免把“拦得更多”误当成功，因为误杀会造成客户流失、投诉和支付失败。CQL 的保守性适合限制历史未覆盖的激进动作。
信用额度和营销触达可以用 contextual bandit 或 constrained policy learning，而不必强行使用完整 RL。若动作对长期风险、客户关系和资金成本影响强，才需要上升到序列决策。方法选择应由反馈延迟、动作后果和可探索性决定。
企业 Agent 的工具调用策略也可以用同一语言：状态是用户意图、权限、上下文、证据缺口和风险等级；动作是检索、询问、调用工具、生成草稿、拒答或升级；reward 是任务完成、证据充分、低幻觉、低泄露、低成本和人工满意度。高风险工具调用应受 policy service 与审批流约束。
反模式
| 反模式 | 为什么危险 |
|---|---|
| 把 RL 当万能优化器 | 没有状态、动作、奖励、轨迹和评估，算法不会自动产生业务策略 |
| 用短期 KPI 当唯一 reward | 会诱导过度催收、过度拦截、过度触达或过度自动化 |
| 忽略行为策略 | 历史数据来自旧规则、人工偏好和队列限制，不能当作无偏样本 |
| 不记录可选动作 | 只知道实际动作，无法判断当时策略真正面对的选择空间 |
| 离线分数好就上线 | 分布外动作、选择偏差和反馈延迟会让离线收益失真 |
| 让模型绕过硬约束 | 合规、权限、客户保护和资金风险边界不能交给 reward 学出来 |
| 没有 kill switch | 策略漂移、数据管道错误或奖励污染时无法快速止损 |
最终心智模型
Offline RL 是一种从历史轨迹中学习候选策略的技术路线；CQL 是把候选策略拉回数据支持区域的保守机制；金融零售真正需要的是可控、可评估、可审计的 policy decisioning system。
判断一个方案是否成熟，不看它是否使用了强化学习术语，而看它能否同时说明：
状态是否真实可见
+ 动作是否受控
+ 奖励是否代表长期业务责任
+ 历史策略是否可识别
+ 离线评估是否可信
+ 上线是否分阶段、有人工门禁和回滚
+ 每一次建议是否可重放、可解释、可审计
只要其中任何一项缺失，系统就不应被包装成“智能策略优化”；它最多只是一个高风险预测模型外接自动化流程。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。