AI Closed-Loop Learning：纠正行动架构
Closed-loop learning 不是“把用户反馈喂回模型”。在金融零售 AI 中，闭环学习应被设计成 corrective action architecture：识别问题、界定影响、找到根因、关联变更、验证修复、监控复发，并保留完整证据。反馈本身只是信号，不是事实；模型更新只是可能的修复动作之一，不等于问题关闭。
AI Closed-Loop Learning / Corrective Action Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_CLOSED_LOOP_LEARNING_CORRECTIVE_ACTION_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| NIST AI Risk Management Framework | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织风险、测量、处置、责任和持续改进证据 |
| ISO/IEC 42001 AI management system | https://www.iso.org/standard/42001 | 把 AI 改进闭环放进管理体系、目标、控制、记录、内审和持续改进 |
| Federal Reserve SR 26-2 | https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm | 2026 年模型风险管理锚点。Nuance: SR 26-2 替代 SR 11-7 / SR 21-8, 采用更风险导向和机构规模分层的模型风险框架; 但正式 scope 聚焦 banking organization 的 model risk management, 生成式 / agentic AI 仍需结合更广 AI governance、消费者合规、隐私、安全、第三方和业务控制。 |
| CFPB Consumer Complaint Database | https://www.consumerfinance.gov/data-research/consumer-complaints/ | 把投诉主题、客户叙述、公司响应和趋势作为外部 customer harm / corrective action 信号 |
核心导读
Closed-loop learning 不是“把用户反馈喂回模型”。在金融零售 AI 中，闭环学习应被设计成 corrective action architecture：识别问题、界定影响、找到根因、关联变更、验证修复、监控复发，并保留完整证据。反馈本身只是信号，不是事实；模型更新只是可能的修复动作之一，不等于问题关闭。
成熟闭环要把客户投诉、人工复核、异常监控、生产日志、模型评估、审计发现和业务损害连接到同一个 issue lifecycle。每一次修复都要回答：修的是什么，为什么这样修，影响哪些群体，如何证明修复有效，如何防止同类问题复发。
问题定义
AI 产品的持续学习容易被误解为更快迭代，但在高影响业务中，未经治理的学习会放大风险：
- 客服 RAG 引用旧费用政策，客户错过申诉窗口；团队只更新了知识库，但没有验证旧问题是否消失。
- 欺诈模型误拦截上升，员工大量 override；系统记录了 override count，却没有结构化原因和客户影响。
- 信贷解释生成器使用不完整 reason code，客户投诉“原因不对”；团队调整 prompt 后未做 segment-level 回归。
- 审计发现模型更新后没有证明原缺陷已被关闭，issue tracker 与 release record 断裂。
- 漂移 dashboard 报警，但没有 owner、SLA、修复证据和复发监控窗口。
问题不在于缺反馈，而在于反馈没有被转化成可治理的 corrective action。没有闭环的反馈会变成噪音；没有证据的修复会变成叙述。
核心原理/方法
闭环学习要区分四类概念：
| 概念 | 含义 | 不能混淆为 |
|---|---|---|
| Signal | 投诉、QA 失败、漂移告警、override、异常输出、监管发现 | 已验证事实 |
| Issue | 经过 triage 后确认需要管理的风险或缺陷 | 普通 backlog item |
| Corrective action | 有 owner、范围、计划、验证和关闭标准的修复动作 | 任意模型更新 |
| Effectiveness verification | 证明损害降低且问题没有复发 | 部署成功 |
根因分析不能只问“模型为什么错”。AI workflow 的根因可能落在多个层面：
| 根因层 | 示例 |
|---|---|
| Data / source | 政策文档过期、样本偏斜、标签错误、特征延迟 |
| Retrieval | chunk 粒度不对、ranking 错误、有效期过滤缺失、权限过滤错误 |
| Prompt / instruction | 指令鼓励过度自信、缺少拒答规则、没有 citation requirement |
| Model / eval | 基准集缺场景、某 segment 表现退化、模型升级未覆盖边界案例 |
| Tool / action | 工具权限过宽、幂等缺失、审批前执行、错误写入 system of record |
| Human operation | reviewer 校准不足、队列过载、reason code 粗糙、override 无独立复核 |
| Policy / product | 规则本身模糊、客户话术与实际产品条款不一致、灰区未定义 |
闭环学习的方法是把每个 confirmed issue 绑定到 change package，而不是让团队在多个系统中各自修补。
系统/架构模型
Signal Sources
-> Triage & Severity Classifier
-> AI Issue Registry
-> Impact Analysis & Population Query
-> Root Cause Workspace
-> Corrective Action Plan
-> Change Package Registry
-> Eval / Regression / Shadow Test
-> Release Gate
-> Effectiveness Monitoring
-> Closure & Learning Library
关键组件：
| 组件 | 职责 |
|---|---|
| Signal intake | 接入投诉、QA、人工复核、KRI、incident、审计、监管、生产异常 |
| Triage classifier | 按客户损害、合规风险、资金影响、重复性、覆盖面和紧急度分级 |
| Issue registry | 维护 issue id、affected use case、owner、SLA、状态、风险接受和证据 |
| Impact analyzer | 查询受影响客户、会话、输出、工具动作、产品、渠道和时间窗口 |
| Root cause workspace | 连接 trace、source、prompt、model、tool、review、policy 和 business event |
| Change package registry | 将数据、prompt、RAG、模型、规则、工具、培训、流程变更绑定到同一修复包 |
| Eval gate | 用 locked eval、regression set、adversarial cases、生产抽样验证修复 |
| Effectiveness monitor | 在生产后观察投诉、QA、override、KRI、repeat issue 和 segment-level 指标 |
这种架构把“学习”放在受控生命周期中：信号进入、问题确认、修复受控、证据关闭、经验复用。
关键机制与取舍
| 机制 | 取舍 |
|---|---|
| Active learning vs corrective action | Active learning 优化模型样本效率；corrective action 管理风险、责任和证据。金融场景不能把两者混成自动训练管道 |
| 快速 prompt patch vs 系统修复 | Prompt patch 可以止血，但根因可能在政策源、检索、工具或运营；必须有后续 root cause closure |
| 自动吸收反馈 vs 人工审核反馈 | 自动反馈循环速度快，但投诉、override 和客服备注含噪声、偏见和业务误解，需要 curated feedback |
| 单指标关闭 vs 多证据关闭 | 准确率改善不等于客户损害降低；关闭标准应覆盖行为、客户、运营和控制证据 |
| 局部修复 vs 横向复用 | 一个 intent 的问题可能暴露通用控制缺口，例如 effective-date filter、policy citation 或 reviewer calibration |
| 永久 eval set vs 动态风险库 | locked eval 保证可比性；risk library 要吸收新 typology 和真实损害场景 |
修复动作也不只有 retraining。可能的 action 包括：撤下过期 source、重建向量索引、增加 effective-date filter、收紧 tool permission、调整 policy gate、增加高风险人工复核、更新客服话术、补充 disclosure、改进 reviewer calibration、修复数据 lineage、通知受影响客户。
证据与控制
闭环学习要有 issue-level evidence bundle：
| 证据对象 | 关键内容 |
|---|---|
| Signal record | 来源、时间、客户/会话、触发规则、原始叙述、置信度、初始 severity |
| Issue decision | triage 结论、影响范围、客户损害、法规义务、owner、SLA |
| Root cause record | 支持根因的 trace、数据、政策、模型、prompt、tool、review 和样本分析 |
| Change package | 变更项、版本、审批、上线窗口、rollback plan、关联 issue id |
| Verification result | locked eval、回归集、shadow test、生产抽样、segment 指标、失败样本 |
| Effectiveness review | 投诉趋势、QA 通过率、override 率、repeat incident、客户补救状态 |
| Closure record | 关闭标准、批准人、残余风险、复发监控窗口、复用到控制库的条目 |
控制要确保问题不会被“部署完成”误关闭。关闭前至少要证明：受影响 population 已界定，客户补救路径已评估，修复覆盖根因，回归测试没有引入新风险，生产指标在观察窗口内恢复，重复问题有监控和升级规则。
金融零售/AI产品场景
费用政策 RAG 错误：客服 AI 错用旧版年费减免政策。修复不能只替换文档，还应禁用 superseded source、重建索引、加入 effective-date ranking、增加 fee-policy eval、抽样验证生产答案引用当前政策，并监控费用解释投诉两周以上。
欺诈误拦截上升：模型阻断率升高但客户投诉集中在特定商户类别。闭环要查询受影响交易、分析特征漂移和规则叠加，调整策略后用 holdout 和 shadow mode 验证，并确认 customer remediation 是否需要。
信贷拒绝解释不一致：生成器输出与 reason code 不一致。根因可能是 prompt 未强制引用 adverse action reason、数据映射错误或政策优先级模糊。修复要覆盖 reason-code mapping、output policy test、样本复核和投诉趋势。
门店销售助手话术越界：AI 草稿暗示保本收益。闭环应把 forbidden claim 加入 claim scanner、更新 approved content、培训员工、抽样已发送话术，并将事件纳入 conduct surveillance。
反模式
- 把所有 thumbs-down 当作训练标签，未区分客户不满、事实错误、政策灰区和体验偏好。
- 问题单关闭条件写成“代码已上线”或“模型已更新”。
- 修复只在一个 team 的 backlog 中完成，issue registry、release record 和 evidence store 无法关联。
- 只看整体准确率，不看受影响 segment、客户损害、投诉复发和人工 override。
- 纠正了输出文本，但没有处理受影响客户或错误业务动作。
- eval set 不吸收真实事故样本，导致同类问题反复发生。
- 根因分析停在“LLM hallucination”，没有追到 source、prompt、tool、policy 和人审流程。
最终心智模型
Closed-loop learning 在金融零售 AI 中应被理解为“带证据的纠正行动系统”。学习的价值不在于模型持续变化，而在于组织能把生产问题转化为受控修复，并证明客户损害下降、控制恢复、复发被监控。
一句成熟度判断：如果一个 AI 问题从投诉到根因、变更、验证、上线、客户补救、复发监控都能通过 issue id 串起来，闭环才存在；如果只能说“我们优化了 prompt”，那还只是局部调参。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。