AI 不确定性体验架构：Abstention / Confidence / Escalation

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

Date: 2026-06-30 Status: evergreen Audience: 已具备 CBAP 级业务分析基础的金融零售 AI 产品、架构与治理从业者。 Output: 一套把 uncertainty UX、abstention、confidence language、safe refusal、partial answer、request-more-info、human escalation、evidence 和 monitoring 连接起来的系统学习笔记。

---

Source Anchors

Source nuance:

• Conformal prediction、calibration、置信区间和模型评分只能形成技术层面的 uncertainty signal，不能自动决定客户看到什么、员工如何接手、监管证据如何保留。
• Human-AI interaction guideline 提醒系统要表达能力边界和错误恢复；金融零售场景还必须把这些原则落到产品状态机、policy engine、case workflow、approved language 和 audit trail。
• NIST 和 ISO 提供风险管理与管理体系结构；本文将其转换为运行时决策、控制证据、升级流程和持续改进机制。

---

核心导读

AI uncertainty UX 不是 tooltip，也不是把 confidence_score 暴露给用户。它是一个运行时 decision-control architecture：系统在每一次交互中判断 AI 应该回答、限定回答、部分回答、追问、拒答、升级、阻断，还是只保留证据等待人工处理。

金融零售的关键挑战是：模型不确定性、证据不完整、政策边界、身份授权、客户影响、行为可逆性和弱势客户信号会同时出现。如果只用一个低置信度阈值触发人工，系统会误把“模型分数”当作“服务责任”。高级设计必须把不确定性翻译成可执行、可审计、可运营的服务动作。

technical uncertainty signal
  + evidence state
  + policy boundary
  + authorization
  + customer impact
  + reversibility
  + vulnerability context
  -> allowed action class
  -> approved language
  -> workflow owner
  -> evidence packet
  -> monitoring and improvement loop

---

1. 问题定义：从模型不确定性到服务责任

很多 AI 产品把不确定性处理成三件表层动作：

• 显示一个百分比。
• 加一句 “AI may be wrong”。
• 低 confidence 时转人工。

这些动作在金融零售里不足够。客户是否受到伤害，不只取决于模型是否“知道答案”，还取决于系统是否知道哪些话会被理解为承诺、建议、资格判断、账户裁决或合规结论。一个答案即使事实上大体正确，也可能因为越过授权边界、缺少证据、暗示审批结果、隐藏申诉路径而造成产品和监管风险。

1.1 运行时核心问题

Given a user intent, context, evidence state, model uncertainty,
policy boundary, authorization state and customer impact:
what should the system do next, who owns the next action,
what should the user see, and what evidence must be retained?

这不是文案问题，而是产品状态机、控制平面和运营模型的问题。

1.2 不确定性的七类来源

不要把 uncertainty 简化成模型概率。金融零售至少要区分七类不确定性：

1.3 设计原则

confidence is an internal signal
uncertainty language is a user contract
abstention is a product action
escalation is an operating model
evidence is the accountability layer

---

2. 架构模型：Uncertainty Decision Control Plane

不确定性体验应被设计为一个 control plane，而不是散落在 prompt、UI 文案和人工流程里的补丁。它的核心是：从 intent、impact、evidence、policy、authorization 和 confidence 推导出允许的 action class，再绑定 language、workflow、evidence 和 monitoring。

flowchart TD
  A[User / Employee Intent] --> B[Context and Impact Assessment]
  B --> C[Evidence State]
  B --> D[Policy Boundary]
  B --> E[Authorization State]
  B --> F[Model / Retrieval / Tool Confidence]
  C --> G[Uncertainty Decision Policy]
  D --> G
  E --> G
  F --> G
  G --> H{Action Class}
  H -->|answer| I[Answer with evidence and calibrated language]
  H -->|partial answer| J[Scope answer + missing facts + next step]
  H -->|ask more| K[Structured clarification or document request]
  H -->|safe refusal| L[Boundary explanation + allowed alternative]
  H -->|escalate| M[Case workflow + owner + SLA]
  H -->|block| N[Stop unsafe action + incident/control signal]
  I --> O[Telemetry and Evidence Packet]
  J --> O
  K --> O
  L --> O
  M --> O
  N --> O
  O --> P[Monitoring / Eval / Governance / CAPA]
  P --> G

Key idea: uncertainty architecture is a closed-loop system. It does not end when AI says “I am not sure”; it ends when the case reaches the right outcome, evidence is complete, and control owners can improve the policy.

2.1 Runtime Components

2.2 Action Classes

---

3. 关键机制与生命周期

3.1 Abstention Taxonomy

Abstention 不是单一拒答。成熟系统必须区分“为什么不能继续”，因为不同原因对应不同 UX、owner、SLA 和证据。

3.2 Escalation Policy

Escalate when:
  impact severity is high
  OR action is irreversible
  OR customer-facing statement could create regulated obligation
  OR evidence is conflicting
  OR policy boundary is unclear
  OR customer harm / complaint / vulnerability signal exists
  OR AI would need to infer facts that should come from system of record.

Escalation 不是把风险甩给人工。它要定义接手 owner、队列、SLA、用户承诺、handoff payload、closure event 和 feedback loop。没有这些，转人工只是 UI 上的安慰。

3.3 Confidence Language

Raw percentages often create false precision. A customer who sees “82% confident” cannot know whether it means factual accuracy、policy fit、retrieval match、approval chance or model probability. The better pattern is to express what is known, why it is known, what is missing and what the system will do next.

Explanation rules:

1. Explain the decision class, not the model internals.
2. Tie confidence language to evidence quality, not AI personality.
3. Show what is known, unknown, assumed and next.
4. For customer-impacting decisions, provide reason codes and recourse path where policy allows.
5. For employee copilots, show conflicting evidence before recommended action.
6. For regulated advice boundaries, use approved copy and avoid personalized recommendations.
7. Never use confidence language to soften a hard compliance boundary.
8. Never use uncertainty as a way to avoid a complaint, dispute, appeal or accessibility path.

3.4 RAG / Agent / Copilot / Eval Lifecycle

---

4. 证据与控制

4.1 Metrics

4.2 Control Model

4.3 Evidence Packet

A replayable uncertainty decision needs enough information to reconstruct why the system answered, abstained or escalated.

uncertainty_event_id: ux-2026-06-30-000169
use_case: payment_dispute_assistant
intent: dispute_outcome_question
customer_impact_tier: high
evidence_state: missing_customer_cancellation_date
confidence_summary:
  retrieval: high
  tool_validation: high
  case_specific_conclusion: low
policy_decision: partial_answer_ask_more
policy_ids:
  - dispute_uncertainty_policy_v4
  - prohibited_outcome_promise_v2
approved_language_ids:
  - dispute_process_explanation_v7
output_class: partial_answer
escalation:
  required: false
  trigger_checked: hardship_or_fraud_signal
sources:
  - transaction_record_ref
  - dispute_policy_ref
human_feedback:
  override: false
monitoring_tags:
  - high_impact
  - missing_evidence

4.4 Eval Design

Uncertainty eval must cover the system’s ability to choose the right action, not only its ability to produce a fluent answer.

Score dimensions:

---

5. 金融零售场景

5.1 Credit Eligibility Assistant

Bad pattern:

"You are likely eligible for this credit card."

Why it fails:

• It may imply pre-approval.
• It may hide missing income, credit bureau, identity or product eligibility checks.
• It may create unfair treatment if the confidence threshold behaves differently across segments.

Better architecture:

5.2 Wealth Advice Boundary

User asks: “Should I sell my bond fund and buy the high-yield product?”

The uncertainty is not only model uncertainty. It is authorization, suitability, profile completeness, licensing and conduct risk uncertainty. A robust response classifies the intent as personalized investment advice, checks channel and role permissions, provides neutral education about risk/fees/liquidity/suitability concepts, refuses buy/sell recommendation and offers licensed advisor handoff.

5.3 Payment Dispute Claims

User asks: “Will I win this dispute?”

AI may collect transaction details, merchant interaction, delivery evidence and cancellation date; explain process and timelines; identify missing evidence; create case and route high-value, suspected-fraud or vulnerable-customer cases. AI must not promise outcome, invent chargeback reason, tell customer to misstate facts, or hide uncertainty about network rules and merchant evidence.

5.4 AML Analyst Assistant

Analyst asks: “Is this suspicious?”

AI may summarize alert facts, extract counterparties, typologies, transaction sequences and anomalies, cite source transactions and identify unresolved evidence gaps. It must not make SAR filing decisions, close cases without reviewer, generate unsupported suspicion narrative, or reveal SAR-sensitive reasoning to customer-facing teams.

Uncertainty UX here is employee-facing: field-level confidence, contradictory facts, missing KYC context and reviewer confirmation workflow.

5.5 KYC Document Extraction

AI extracts name, date of birth, address and document number. The design should support field-level abstention rather than forcing a whole-document pass/fail or hallucinating missing values.

5.6 Complaint Intelligence

Complaint AI should treat uncertainty as a preservation problem. It should preserve original narrative, summarize with span citations, separate allegation / verified fact / policy issue / harm signal / root cause hypothesis, and escalate legal-sensitive, vulnerable customer, repeated harm and regulatory-source cases.

Never let “low confidence” become a reason to not create a complaint case. In complaints, ambiguity often increases the need to preserve and route.

5.7 Contact Center Copilot

Agent guidance should be action-safe, not model-centric:

Recommended response: Explain dispute process and ask for merchant cancellation evidence.
Confidence: Medium
Why: Transaction is posted and policy found, but customer cancellation date is missing.
Do not say: "You will get your money back."
Escalate if: customer says hardship, fraud, legal threat, regulator, or prior unresolved complaint.

The agent does not need model math. The agent needs evidence status, forbidden language, safe next step and escalation triggers.

---

6. 反模式与修正

---

7. 最终心智模型

Uncertainty UX 的成熟度不在于 AI 是否“承认自己可能错”，而在于系统能否把不确定性转成正确的服务动作。高级系统会把每次交互拆成五个问题：

1. 当前 intent 是否允许 AI 在此渠道、角色和客户状态下回答？
2. 支撑这个回答的证据是否充分、新鲜、一致、授权可见？
3. 如果回答错了，客户影响、合规影响和可逆性是什么？
4. 最小有用动作是什么：回答、限定、部分回答、追问、拒答、升级还是阻断？
5. 六个月后投诉、审计或监管问询时，是否能重建当时的事实、规则、模型、文案和人工判断？

最终判断标准不是“模型有多自信”，而是：

Can the system make uncertainty actionable, humane, compliant, auditable and improvable?

做到这一点，AI 不确定性体验才从界面提示升级为金融零售 AI 的运行时治理架构。

---

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

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