AI Explainability / Contestability / Adverse Action Architecture 解读

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_EXPLAINABILITY_CONTESTABILITY_ADVERSE_ACTION_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

Source Anchors

核心导读

Explainability 不是把模型内部推理展示给客户，也不是给每个 AI 输出附上一段“解释文字”。在金融零售场景里，解释是一种受治理的产品界面：它必须绑定正式决策、事实证据、政策版本、reason code、客户下一步、可争辩路径和审计证据。

Contestability 也不是“如有疑问请联系客服”。它是客户能够纠错、补资料、申诉、触发人工复核、获得结果说明，并让组织把 upheld appeal 回流到模型、流程、公平性和客户伤害控制中的闭环。

可以把它理解为：

explainability architecture =
  governed explanation layers
  + reason-code source of truth
  + evidence grounding
  + contestability workflow
  + faithfulness evaluation
  + adverse-action evidence

1. 问题定义

金融 AI 的解释风险来自两个误解。第一个误解是把“可解释”理解成展示模型推理；第二个误解是把“客户解释”交给生成模型自由组织。前者可能暴露不该披露的内部推理、规则和 PII，后者可能编造拒绝原因、引用过期政策、改变正式口径或给出误导性下一步。

正确的边界是：

internal reasoning is not customer explanation

客户看到的解释必须是可验证、可理解、可行动的；审计和监管看到的证据必须能追溯到 decision record、reason code、source、policy version、template version、生成文本和客户沟通记录。

解释架构的本质，是把“为什么”拆成不同层次的证据产品，而不是让一个 LLM 对所有受众回答同一个为什么。

2. 架构模型

Adverse action 和高影响解释需要一个明确的 source-of-truth 架构。高风险反模式是：

LLM reads application + invents plausible denial reason

正确模型是：

decision engine / policy system
  -> canonical reason code
  -> evidence fields
  -> approved reason language
  -> user-facing explanation assembly
  -> contestability workflow
  -> audit record

这套架构对 RAG、agentic workflow 和传统评分模型同样适用。区别在于证据来源不同：RAG 需要 source citation 和文档版本，agent 需要 tool action 和 approval trace，评分模型需要 reason code 和输入特征证据。

3. 关键机制/生命周期

Explanation 生命周期从决策前就开始，而不是从生成文本开始。

define decision and explanation scope
  -> bind reason-code source
  -> map evidence fields
  -> approve language and policy versions
  -> generate user-facing explanation
  -> run faithfulness checks
  -> deliver explanation with recourse path
  -> receive correction / appeal / missing evidence
  -> human review and reconsideration
  -> notify outcome
  -> update eval, controls and monitoring

Contestability 是该生命周期的运行层：

customer receives explanation
  -> understands reason and next action
  -> submits correction / appeal / missing evidence
  -> human review
  -> data correction or decision reconsideration
  -> outcome notification
  -> evidence retained
  -> monitoring updates

它必须明确：

• 哪些决定、解释或服务限制可以被争辩。
• 客户可以提交哪些新证据或纠错信息。
• 谁复核，是否需要重新运行规则、模型或人工判断。
• 多久给出结果，结果如何解释。
• 维持原决定和改变决定分别需要什么证据。
• upheld appeal 如何回流到质量、客户伤害、公平性和 release gate。

Faithfulness eval 负责把“解释看起来合理”升级成“解释与正式证据一致”。

4. 证据与控制

Explainability control 的关键不是保留一份生成文本，而是保留解释如何从正式决策、证据、政策和模板生成出来，以及客户如何被告知和如何争辩。

Adverse action evidence pack 可以建模为结构化记录，而不是空白文档：

核心 KRI：

5. 金融零售/AI产品场景

Credit denial explanation assistant

AI 可以把正式 reason code 转成易懂语言、解释客户可采取的下一步、检查是否缺少 required disclosure。AI 不可以发明拒绝原因、修改正式 reason code、给出不一致的重新申请建议或把推测性原因写成事实。关键控制是 reason-code mapping、approved language、faithfulness eval、adverse action evidence 和 appeal workflow。

Overdraft fee explanation

AI 可以引用 fee schedule、解释交易时间线、引导客户发起争议。主要风险是过度自信解释复杂交易顺序、忽略客户投诉、忽略 vulnerable customer signal 或把政策例外说成绝对规则。关键控制是 source citation、policy version、transaction timeline grounding、complaint escalation 和 customer harm monitoring。

Fraud false positive

AI 可以解释安全验证步骤、给客户恢复访问路径和说明需要的材料。主要风险是透露欺诈检测规则、让客户承担过度证明负担、不给清晰恢复路径。关键控制是最小必要解释、账户恢复 SLA、human review、false positive feedback 和不披露 rule logic 的措辞控制。

Collections communication

AI 可以把政策允许的内容整理成一致话术和下一步说明。主要风险是使用不当语气、遗漏 hardship 或 vulnerable customer 线索、对不同客户给出不一致选项。关键控制是 script governance、language QA、vulnerability escalation 和 contact frequency guardrail。

6. 反模式

7. 最终心智模型

Explainability 是“受治理的客户界面 + 可追溯证据链”，contestability 是“客户能改变错误结果的操作路径”。两者结合，才能让金融 AI 不只是会解释，而是能被质疑、被纠正、被审计。

最终要形成一条稳定链路：

decision source
  -> reason code
  -> evidence fields
  -> approved explanation
  -> customer recourse
  -> review outcome
  -> monitoring and control update

如果一个系统能生成漂亮解释，却说不清正式原因从哪里来、事实依据是什么、客户如何纠错、申诉结果如何回流、审计如何重建原始解释，它就还不是金融零售可用的 explainability architecture。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。