AI 扩展计划 / Playbooks

AI Anomaly Detection / Risk Monitoring Playbook

以下来源作为本文的外部锚点。正式项目应记录访问日期、版本、内部 policy mapping、模型验证结论和审批证据。

794 行AI_ANOMALY_DETECTION_RISK_MONITORING_PLAYBOOK.md

AI Anomaly Detection / Risk Monitoring Playbook

受众：AI PM、AI Architect、Risk Platform PM、Fraud / AML Product Owner、Model Risk、Security、SRE、Data Platform、Compliance、Internal Audit。

核心问题：如何把 anomaly detection/risk monitoring platform 从“模型报警器”设计成金融零售企业的实时风险控制面，覆盖 fraud/AML/ops incidents/model drift/security/cost anomaly，并能持续校准阈值、减少 alert fatigue、沉淀标签闭环、形成治理证据。

重要说明：本文是学习、架构设计和作品集材料，不构成法律、监管、审计或正式模型验证意见。金融零售正式项目必须由 business owner、risk、compliance、security、privacy、model risk、operations、legal、internal audit 共同确认适用要求和残余风险接受机制。

1. Source Anchors

以下来源作为本文的外部锚点。正式项目应记录访问日期、版本、内部 policy mapping、模型验证结论和审批证据。

Anchor	Link	本手册使用方式
Isolation Forest original paper	https://doi.org/10.1109/ICDM.2008.17	用“随机切分更容易隔离异常点”的思想理解高维交易、账户、设备、商户、门店、接口调用和成本行为中的无监督异常检测。
scikit-learn IsolationForest	https://scikit-learn.org/stable/modules/generated/sklearn.ensemble.IsolationForest.html	作为工程实现锚点：参数、contamination、decision_function、score_samples、随机森林式隔离路径和上线时的特征输入约束。
PyOD	https://pyod.readthedocs.io/en/latest/	作为 Python anomaly detection 工具箱锚点，用于比较 Isolation Forest、LOF、ECOD、HBOS、autoencoders 等算法并建立统一实验接口。
NAB - Numenta Anomaly Benchmark	https://github.com/numenta/NAB	作为 streaming anomaly detection 评测锚点，强调时间窗口、早发现奖励、迟发现惩罚和漏报成本，而不是只看静态 accuracy。
NIST AI RMF	https://www.nist.gov/itl/ai-risk-management-framework	用 Govern / Map / Measure / Manage 组织 AI 风险识别、度量、处置、监控、证据和治理汇报。
NIST / SEMATECH e-Handbook - Control Charts	https://www.itl.nist.gov/div898/handbook/pmc/section3/pmc3.htm	用 statistical process control 和控制图思想设计稳定过程、控制限、漂移识别和运营异常解释。
MITRE ATLAS	https://atlas.mitre.org/	用于把安全异常、模型攻击、prompt injection、data poisoning、exfiltration 与 AI-native 风险监控连接。
OpenTelemetry Semantic Conventions	https://opentelemetry.io/docs/specs/semconv/	用于把服务、模型调用、工具调用、成本、延迟、错误和业务上下文落到 trace / metric / log。

2. 一句话定位

AI anomaly detection / risk monitoring 是企业风险控制面的“早期雷达”。它把交易、账户、客户、设备、商户、门店、模型、提示词、知识库、工具调用、成本、权限和运营流程转成可监控的 entity/time/window 信号，并通过规则、统计、机器学习、深度学习和人工反馈持续发现异常、解释风险、分流处置、校准阈值和沉淀治理证据。

高级角色要能回答五个问题：

问题	高级答案应该覆盖
监控什么	entity/time/window、业务事件、模型行为、系统指标、成本、权限、标签、反馈和处置结果。
如何检测	statistical process control、规则、Isolation Forest、autoencoders、图异常、序列模型、streaming anomaly detection、ensemble 和人工规则组合。
如何减少误报	threshold calibration、precision/recall 权衡、分群阈值、风险分级、告警抑制、重复合并、反馈学习。
如何运营	告警路由、case management、SLA、analyst queue、二线升级、runbook、postmortem、dashboard、治理会。
如何治理	模型清单、数据血缘、阈值审批、变更门禁、偏差审查、审计证据、风险接受、NIST AI RMF 映射。

3. 为什么重要

金融零售里的异常不是一个统一概念。它可能是信用卡盗刷、账户接管、AML 可疑交易、商户套现、门店库存异常、支付通道失败、客服机器人幻觉、RAG 检索漂移、AI agent 越权工具调用、模型质量退化、token 成本失控、供应商接口延迟、批处理对账差错或安全攻击。

如果只用单个模型报警，平台会很快走向三种失败：

失败模式	业务后果	架构根因
漏报	欺诈损失、AML 迟报、客户伤害、运营事故扩大	没有把异常定义映射到业务实体、时间窗口、风险等级和处置 SLA。
误报爆炸	analyst 疲劳、队列积压、真正风险被淹没	缺少 threshold calibration、告警治理、重复合并、反馈闭环和 precision/recall 管理。
无法审计	上线后说不清为什么报警、为什么不报警、谁批准阈值	数据血缘、特征版本、模型版本、阈值策略、处置结果和风险接受没有统一证据链。

这份 playbook 的核心立场：

异常检测不是数据科学实验，而是风险运营系统。模型分数只是中间信号；最终价值来自“发现足够早、解释足够清、分流足够准、处置足够快、证据足够完整”。

4. 异常类型地图：从业务风险到监控对象

4.1 金融零售高价值异常场景

场景	典型异常	核心 entity	关键窗口	处置 owner
Fraud	账户接管、盗刷、撞库后小额试探、退款滥用、设备指纹突变、商户套现	customer、account、card、device、merchant、IP、session	秒级、分钟级、小时级、7 天滚动	Fraud Ops / Risk Product
AML	structuring、round-dollar pattern、异常资金流、制裁名单邻近、壳公司网络、交易目的异常	customer、beneficial owner、counterparty、account、transaction network	日级、30 天、90 天、年度回看	AML Compliance / FCC
Ops incidents	支付失败率突增、对账差错、批处理延迟、库存扣减异常、客服积压	service、channel、store、batch、queue、case type	分钟级、小时级、日切窗口	SRE / Operations
Model drift	特征分布漂移、模型分数分布变化、拒绝率变化、人工覆盖率升高、judge 分数退化	model、segment、feature、prompt、index、use case	小时级、日级、版本发布后	Model Risk / AI Platform
Security	prompt injection、异常工具调用、权限绕过、数据外泄、异常登录、机器人流量	user、role、tool、tenant、secret、endpoint	实时、会话级、24 小时	Security / SOC
Cost anomaly	token 激增、长上下文滥用、embedding 任务爆量、retry loop、供应商路由异常	use case、model、team、tenant、workflow、route	分钟级、小时级、账期	AI Platform / FinOps

4.2 entity/time/window 是平台建模的第一原则

异常检测的输入不是“全局一条时间序列”，而是 entity/time/window 的组合：

entity: 被观察对象
time: 事件发生时间、处理时间、入湖时间、模型调用时间
window: 用于聚合、比较、判断和告警的时间范围

示例：

业务问题	entity	time	window
某客户是否账户接管	customer + device + IP	login_time、transaction_time	5 分钟、1 小时、24 小时、历史 30 天基线
某商户是否套现	merchant + card BIN + MCC	authorization_time、settlement_time	日、周、月、节假日对比
某 AI use case 是否成本异常	use_case + model_route + tenant	request_time、billing_time	15 分钟、小时、日、账期累计
某 AML 网络是否异常	customer + counterparty graph	transaction_time、case_open_time	30 天、90 天、年度回看
某模型是否漂移	model + segment + feature	scoring_time、label_time	发布前后、日级、周级

设计平台时先定义 entity/time/window，再谈算法。否则模型会混淆季节性、促销、工资日、节假日、批处理周期和真实风险。

5. 检测平台架构

5.1 目标架构

Event Sources
  -> Stream / Batch Ingestion
  -> Data Quality + Identity Resolution
  -> Feature / Signal Layer
  -> Detection Engine
  -> Threshold + Policy Engine
  -> Alert / Case Orchestration
  -> Analyst Feedback + Label Store
  -> Monitoring Dashboard + Governance Evidence

5.2 核心组件

组件	责任	金融零售落地要点
Event ingestion	接入交易、登录、支付、订单、库存、模型调用、工具调用、成本、日志和安全事件	支持实时 Kafka / Pulsar、批量文件、CDC、API；保留 event_time 与 ingestion_time。
Entity resolution	统一客户、账户、设备、商户、门店、员工、模型、工具、供应商和租户身份	需要 ID mapping、主数据、隐私分级、跨系统 lineage 和变更历史。
Feature / Signal layer	生成聚合、比率、速度、频率、偏差、图关系、序列和模型行为特征	特征必须有版本、窗口、freshness、owner、质量 SLO 和回放能力。
Detection engine	运行规则、SPC、Isolation Forest、autoencoders、图模型、序列模型、ensemble	高风险场景保留可解释规则和人工审查入口，不能只有黑箱分数。
Threshold + policy engine	将模型分数变成风险等级、告警、拦截、人工复核或观察	支持分群阈值、动态阈值、风险偏好、业务日历、模型版本和审批记录。
Alert orchestration	去重、合并、抑制、升级、路由、SLA、case 创建	重点治理 alert fatigue；把重复信号合并成同一 case narrative。
Case management	支持 analyst 调查、证据查看、处置、升级、审计记录	必须能回看原始事件、特征、模型分数、阈值、同群体对比和历史处置。
Label store	存储 confirmed fraud、false positives、benign anomaly、SAR filed、model issue、cost issue 等标签	标签要区分即时反馈、延迟真值、专家意见、客户投诉和监管结论。
Feedback loop	将处置结果回流到阈值、规则、模型、训练集、评测集和 runbook	防止把 analyst 偏见直接训练进模型；高风险标签需独立复核。
Governance evidence	记录数据、特征、模型、阈值、变更、审批、效果和残余风险	支持模型风险、审计、合规、运营风险和管理层报告。

5.3 C4 风格上下文视图

外部参与者 / 系统	与平台的关系
Core banking / payment / card / POS / ecommerce	提供交易、订单、账户、清算、库存、退款和通道事件。
Identity / IAM / device intelligence	提供用户、设备、会话、权限和登录上下文。
AI gateway / model gateway	提供模型调用、prompt、tool call、token、成本、judge、guardrail 事件。
SIEM / SOC tooling	提供安全告警，接收 AI-native security anomaly。
Case management / CRM	接收告警，承载 analyst 调查和客户补救动作。
Model registry / feature store	管理模型、特征、版本、发布和回滚。
Governance / audit repository	接收阈值审批、效果报告、事故复盘和控制证据。

5.4 数据契约

异常检测数据契约至少包含：

字段族	示例字段	说明
Identity	entity_id、entity_type、tenant_id、customer_segment、risk_tier	保证分群、路由、权限和审计一致。
Time	event_time、ingestion_time、processing_time、window_start、window_end	支持乱序、延迟到达和回放。
Event	event_type、channel、amount、currency、status、counterparty、MCC、store_id	业务事件原始语义。
AI behavior	model_id、prompt_version、index_version、tool_name、judge_score、token_count、route_policy	AI 系统风险监控必备。
Feature	feature_name、feature_version、value、baseline_value、z_score、percentile	解释异常来源。
Score	detector_id、detector_version、raw_score、normalized_score、threshold、severity	连接算法与业务处置。
Decision	alert_id、case_id、action、reason_code、policy_version、approver	形成可审计决策链。
Label	label_type、label_source、label_time、confidence、reviewer_role	支持反馈闭环和延迟标签。

6. 检测方法选择

6.1 方法选型矩阵

方法	适合场景	优势	限制	推荐用法
规则 / 专家策略	明确政策、监管阈值、已知攻击模式、快速止血	可解释、可审批、可立即上线	覆盖有限，容易被绕过，维护成本高	作为高风险底线控制和模型解释补充。
statistical process control	稳定运营指标、失败率、延迟、成本、队列、批处理、模型分数分布	简洁、可解释、适合运营过程稳定性监控	对复杂非线性和多维异常不足	用控制图、移动均值、EWMA、季节性基线监控 process shift。
Isolation Forest	高维表格特征、交易行为、商户行为、账户行为、成本行为	无监督、可扩展、对异常比例低的场景有效	分数解释需要辅助；contamination 设置影响阈值	与特征贡献、peer group、规则 reason code 组合。
autoencoders	高维稠密行为、序列压缩、非线性模式、图像或复杂模式	能学习复杂正常模式，重构误差可作异常分数	数据、训练、漂移和解释成本更高	用于成熟数据域，配套漂移监控、重训练门禁和专家抽样。
聚类 / 距离方法	客群、商户、门店、设备行为 peer group 异常	直观，适合分群基线	高维距离可能失真	先分群再做阈值，避免全局阈值误伤。
图异常	AML 网络、团伙欺诈、设备共享、商户网络、资金流	能发现关系型风险	数据建模和解释复杂	与 case investigation 图谱和可疑网络 narrative 结合。
序列 / 变点检测	登录序列、支付失败、库存流、模型质量趋势、成本趋势	适合时间依赖和突变	需要处理季节性和延迟	用于 streaming anomaly detection 和运营稳定性监控。
Ensemble	多种信号互补，降低单模型盲区	稳健，便于多场景复用	治理、解释和阈值更复杂	使用 score normalization、权重治理、champion/challenger。

6.2 Isolation Forest 适合怎么用

Isolation Forest 的产品解释可以这样讲：

异常点通常更容易被随机切分隔离；
如果一个样本需要很少切分就能被单独分开，它更可能异常。

金融零售适合输入的特征：

场景	特征例子
信用卡交易	最近 5 分钟交易次数、跨境标记、金额相对历史百分位、设备新颖度、MCC 稀有度。
商户风险	退款率、拒付率、夜间交易占比、平均客单价突变、卡 BIN 集中度、同设备多卡。
AI 成本	单 request token、context 长度、retry 次数、judge 调用次数、cache miss 率、成本相对同 use case 分位。
模型漂移	模型分数分布、拒答率、人工覆盖率、低 groundedness 占比、segment-level score shift。

关键治理点：

决策	高级检查点
contamination	不要把业务异常率机械等同于参数；先用历史标注、analyst 容量和风险偏好估算。
特征窗口	同时保留短窗口速度特征与长窗口基线特征，避免只看瞬时尖峰。
分群训练	高净值客户、普通零售客户、小微商户、门店、渠道、国家地区不应强行共用一个基线。
分数解释	用 peer comparison、top contributing features、历史对比和规则 reason code 补解释。
上线方式	先 shadow，再 analyst review，再有限自动化；高风险动作保留人工或双人审批。

6.3 autoencoders 适合怎么用

autoencoders 通过学习“正常行为如何被压缩再重构”来识别异常。重构误差高，说明样本不像训练中的正常模式。

适用条件：

条件	判断
正常样本充足	有足够稳定、清洗过、覆盖季节性的正常行为数据。
特征结构复杂	线性规则或简单统计不足以表达正常模式。
能承受治理成本	可以解释训练数据、漂移、阈值、重训练、误报和漏报。
有专家反馈	analyst 或运营专家能复核高分样本并回传标签。

在金融零售里，autoencoders 更适合二线检测或复杂模式发现，而不是一开始就承担强制拦截。推荐形态：

规则底线控制
  + SPC 监控运营稳定性
  + Isolation Forest / PyOD 发现高维异常
  + autoencoders 发现复杂行为偏离
  + analyst feedback 生成标签与阈值校准证据

6.4 PyOD 的定位

PyOD 的价值不是“直接拿一个算法上线”，而是给团队一个统一实验框架：

用法	产出
快速比较多种 detector	同一数据切分、同一指标、同一阈值策略下比较模型。
建立 champion/challenger	现有规则或 Isolation Forest 做 champion，PyOD 中其它算法做 challenger。
分场景特征实验	fraud、AML、model drift、cost anomaly 分别建立特征集和评测集。
训练产品判断	让 PM / Architect 看到同一 alert volume 下 precision/recall 如何变化。

6.5 NAB 的启发

NAB 的核心启发是：流式异常检测不能只看最终是否命中，还要看“发现是否及时”。

对生产平台的转换：

NAB 思想	平台设计含义
anomaly window	每个业务异常要定义有效发现窗口，超过窗口才报警可能已经无价值。
early detection reward	fraud、security、cost spike 和 ops incidents 越早发现越有价值。
delayed detection penalty	AML 和模型漂移允许较长窗口，但不能无限延迟。
false positives cost	误报会消耗 analyst 容量并导致 alert fatigue，必须被计入平台指标。

7. 流式 / 批式检测

7.1 streaming anomaly detection

流式检测适合“错过几分钟就会放大损失”的场景：

场景	延迟目标	典型动作
卡交易欺诈	毫秒到秒级	step-up authentication、交易拒绝、人工复核、限额调整。
账户接管	秒级到分钟级	强制 MFA、冻结高风险动作、会话中断。
支付通道事故	分钟级	通道路由切换、限流、告警值班。
prompt injection / tool misuse	实时	阻断工具调用、隔离会话、升级安全队列。
token cost spike	分钟级	限额、降级模型、暂停 retry loop、切换缓存策略。

流式架构要点：

Kafka / Pulsar topic
  -> stream processing
  -> online feature store
  -> detector service
  -> policy engine
  -> alert / action sink

高风险流式平台必须处理：

问题	设计要求
乱序事件	使用 watermark、allowed lateness、补偿更新。
特征新鲜度	online feature 有 freshness SLO，过期时降级或转人工。
幂等	同一事件重复到达不能重复冻结账户或重复建 case。
背压	高峰期优先处理高风险 entity 和高金额事件。
可回放	每次阈值或模型变更前能用历史流重放评估 alert volume。

7.2 批式检测

批式检测适合“需要更长上下文、更完整关系或监管审查”的场景：

场景	窗口	典型动作
AML 网络异常	30 / 60 / 90 天	case review、EDD、SAR 评估、关系图调查。
商户风险	日 / 周 / 月	商户分级、保证金、风控策略、通道限制。
模型漂移	日 / 周 / 发布周期	validation review、回滚、重训练、变更审批。
门店运营异常	日 / 周	库存盘点、损耗调查、排班和培训。
成本治理	日 / 账期	预算归因、quota 调整、模型路由优化。

批式架构要点：

Lakehouse / warehouse
  -> batch feature pipeline
  -> detector batch job
  -> score table
  -> case generation
  -> dashboard + governance pack

7.3 Lambda / Kappa 的产品取舍

选项	适合	风险
纯批式	早期探索、低风险运营分析、AML 回看	对实时欺诈、安全和成本失控反应慢。
纯流式	高实时场景、事件模式稳定	长窗口关系和复杂回看不足，治理证据容易碎片化。
流批一体	金融零售主路径	架构复杂，但最能平衡实时止损、长周期分析和审计证据。

推荐：高风险事件用流式做早发现和临时控制，批式做完整复核、模式发现、阈值回放和治理报告。

8. 阈值与告警治理

8.1 threshold calibration

阈值不是数据科学家的私有参数，而是风险偏好、运营容量、客户体验和监管义务的交界面。

阈值校准步骤：

步骤	输出
定义损失函数	漏报损失、误报成本、客户摩擦、analyst 容量、监管影响。
选择评估窗口	以 entity/time/window 为单位回放历史数据。
画 precision/recall 曲线	让业务看到同一模型在不同阈值下的代价。
选风险分级阈值	例如 observe、review、step-up、block、executive escalation。
分群校准	对客户段、商户段、渠道、国家地区、产品、模型 use case 分别校准。
压力测试	用节假日、大促、工资日、系统故障、模型升级和攻击样本回放。
审批记录	保存阈值理由、批准人、有效期、监控指标和回顾周期。

8.2 precision/recall 与 false positives

在异常检测里，accuracy 往往是误导指标。因为真实异常占比很低，即使模型全部预测正常，也可能有很高 accuracy。

更重要的是：

指标	产品解释	风险含义
precision	报出的告警里有多少是真的	低 precision 会制造 false positives 和 analyst 疲劳。
recall	真实异常里有多少被发现	低 recall 会漏掉欺诈、AML、安全和事故信号。
alert volume	每天进入队列的告警量	超过团队容量会导致 SLA 失效。
time to detect	从异常发生到平台发现的时间	流式场景的关键价值指标。
time to triage	从告警到初步分级的时间	决定是否能及时止损。
action yield	告警导致有效处置的比例	衡量告警是否可操作。
customer friction	MFA、冻结、拒绝、人工复核对客户体验的影响	防止风控过度伤害好客户。

高级产品判断不是“提高 recall 到最高”，而是在风险偏好下选择可运营的平衡：

High-severity fraud / security: 更偏 recall，但要用 step-up 和人工复核降低客户伤害。
AML: 更重证据完整性、case quality、可解释性和监管审查。
Ops incidents: 更重 time to detect、blast radius、SLO 和恢复动作。
Cost anomaly: 更重早期趋势、预算阈值、自动限额和业务例外。
Model drift: 更重分群、版本对比、质量回归和上线门禁。

8.3 alert fatigue 治理

alert fatigue 是风险监控平台失效的常见前兆。治理手段要系统化：

手段	做法
去重	同一 entity、同一根因、同一窗口内合并为一个 case。
抑制	已知维护窗口、促销活动、批处理峰值、已确认事故期间降低重复告警。
分层	将 observe、low、medium、high、critical 分开，不让低风险噪音挤占高风险队列。
路由	fraud、AML、SRE、security、AI platform、FinOps 分别接收相关告警。
聚合 narrative	多个 detector 命中时生成统一调查叙事，而不是发多条碎片告警。
容量约束	阈值和队列 SLA 必须考虑 analyst 人数、班次和积压。
反馈回写	false positives 必须回到阈值、规则、特征、模型和抑制策略。

8.4 告警等级

等级	定义	默认动作
Observe	异常信号弱或业务影响低	进入 dashboard，不打断运营。
Review	需要 analyst 判断	创建 case，附证据和推荐调查路径。
Step-up	风险较高但不宜直接拦截	增加强认证、人工确认或额外证据收集。
Block / Contain	高置信、高损失或安全高危	暂停交易、冻结动作、阻断工具、降级服务或限额。
Executive Escalation	客户、监管、资金、安全或声誉重大影响	启动 incident command、legal / compliance / risk 参与和管理层报告。

9. 标签 / 反馈闭环

9.1 标签不是一个字段

异常检测标签有来源、延迟、可信度和用途差异：

标签类型	示例	使用方式
即时运营标签	analyst 标记 suspicious、benign、needs review	反馈阈值和队列路由，但需要质量抽样。
延迟真值标签	confirmed fraud、chargeback、SAR filed、customer complaint upheld	用于模型评测、回放和治理报告。
系统标签	detector fired、policy blocked、feature stale、model fallback	用于平台可靠性分析。
客户体验标签	customer friction、MFA abandoned、false decline complaint	用于平衡风控与体验。
安全标签	prompt injection confirmed、secret exposure、tool misuse	用于 SOC 和 AI 安全闭环。
成本标签	budget breach、retry loop、long-context misuse	用于 AI FinOps 和路由策略。

9.2 Feedback Loop 架构

Alert / case
  -> analyst action
  -> label capture
  -> label quality review
  -> feature / model / threshold evaluation
  -> release gate
  -> monitoring dashboard
  -> governance evidence

9.3 避免反馈闭环污染

风险	控制
analyst 偏见被模型学习	做 reviewer calibration、双人复核、分群 fairness review。
only-alerted bias	未被报警的样本也要抽样复核，否则模型只学习已知告警空间。
延迟标签滞后	分离 short-term operational label 与 long-term confirmed label。
规则自我实现	如果某类客户总被 step-up，后续行为会被策略改变，训练时要识别 policy effect。
标签定义漂移	标签字典、reason code、case disposition 需要版本化。

10. 产品与运营机制

10.1 用户角色

角色	关注问题	需要的产品能力
Fraud analyst	这个客户、设备、商户是否真的有风险	entity timeline、peer comparison、证据包、处置按钮、误报反馈。
AML investigator	是否形成可疑活动叙事	transaction graph、counterparty network、case narrative、EDD / SAR 证据。
SRE / Ops	是局部波动还是事故	SLO、blast radius、dependency map、runbook、suppression。
Security analyst	是否攻击、越权或数据外泄	tool span、IAM context、prompt injection evidence、SIEM integration。
AI platform PM	哪个 use case、模型、prompt、index、route 出现异常	model / prompt / index version dashboard、cost ledger、drift view。
Risk / Compliance	控制是否有效、残余风险是否可接受	threshold approval、case quality、effectiveness report、audit evidence。
Executive	风险趋势、损失、队列、客户影响、监管暴露	risk heatmap、trend、top drivers、决策请求。

10.2 Case UX 原则

一个好 case 不是把 30 个指标堆给 analyst，而是回答：

问题	页面必须呈现
为什么现在报警	命中的 detector、分数、阈值、窗口、相对历史变化。
哪个实体受影响	customer / account / device / merchant / model / workflow 的关联图。
和正常行为差在哪里	peer group、历史基线、关键特征贡献、最近事件时间线。
平台建议什么	review、step-up、block、escalate、observe 的推荐理由和置信度。
analyst 能做什么	调查、标记、升级、抑制、调整 case priority、记录叙事。
证据如何保留	原始事件、特征、模型版本、阈值、处置动作、审批链。

10.3 运营节奏

节奏	会议 / 机制	产出
每日	高风险队列 review	积压、SLA、top false positives、critical case。
每周	Threshold and Alert Review	阈值变更、告警量、precision/recall、误报原因、队列容量。
每双周	Model / Detector Review	champion/challenger、漂移、特征质量、label quality、segment performance。
每月	Risk Monitoring Governance	residual risk、重大事件、审计证据、政策例外、管理层指标。
每季度	Scenario and Tabletop	欺诈攻击、AML 网络、AI cost spike、prompt injection、模型漂移演练。

11. 风险治理

11.1 Governance Control Map

控制域	控制问题	证据
Inventory	哪些 detector、模型、规则、阈值、场景在生产	detector registry、owner、risk tier、版本、适用范围。
Data governance	数据是否完整、及时、合法、可追溯	data contract、lineage、quality report、PII classification。
Model risk	算法、假设、训练、评估、漂移是否可验证	model card、validation report、monitoring plan、issue log。
Threshold governance	阈值由谁批准，何时回顾，风险偏好是什么	threshold policy、approval record、backtest、capacity analysis。
Change management	规则、模型、特征、阈值、路由变更是否受控	release ticket、diff、rollback plan、post-release monitoring。
Human oversight	人工复核是否有能力、有权限、有记录	analyst training、review log、quality sampling、override analysis。
Incident management	异常升级为事故时如何止血和复盘	incident timeline、containment、postmortem、corrective action。
Auditability	能否重现一次告警和处置	event snapshot、feature version、score、threshold、case disposition。
Fairness / customer impact	阈值是否系统性伤害特定客群	segment-level false positives、friction rate、complaint analysis。

11.2 与 NIST AI RMF 映射

NIST AI RMF Function	在本平台中的落点
Govern	owner、risk tier、阈值审批、模型清单、政策、三道防线、管理层报告。
Map	场景、实体、时间窗口、受影响客户、业务流程、损失函数、监管义务。
Measure	precision/recall、false positives、time to detect、drift、alert volume、case quality、成本。
Manage	阈值调整、告警抑制、case 处置、模型回滚、人工复核、风险接受、事故闭环。

11.3 自动化动作分级

动作	自动化条件	必要控制
Observe	低影响、低置信或探索性 detector	dashboard、抽样复核。
Notify	中低风险，影响团队响应	去重、路由、SLA。
Step-up	风险较高但客户伤害可控	MFA、附加验证、客户体验监控。
Soft hold	临时限制高风险动作	明确释放条件、客户沟通、人工复核。
Hard block	高置信、高损失、安全或监管高风险	双重控制、审计证据、事后复核、申诉通道。
AI tool kill switch	agent 工具异常、prompt injection、权限绕过	立即生效、最小化影响、事件指挥、回滚证据。

12. 模板

12.1 anomaly taxonomy 模板

字段	内容
Anomaly name	例如 account takeover velocity spike、AML structuring pattern、AI cost retry loop。
Business domain	fraud、AML、ops incidents、model drift、security、cost anomaly。
Entity	customer、account、device、merchant、store、model、tool、tenant。
Time / window	event_time、processing_time、5m、1h、24h、30d。
Risk impact	资金损失、客户摩擦、监管风险、服务中断、数据泄露、预算超支。
Detection method	rule、SPC、Isolation Forest、autoencoders、graph、sequence、ensemble。
Evidence required	原始事件、特征、分数、阈值、peer comparison、历史时间线。
Default action	observe、review、step-up、block、escalate。
Label definition	confirmed、benign、false positives、needs more evidence、policy exception。
Governance owner	business、risk、compliance、security、AI platform、operations。

12.2 detection architecture 模板

Use case:
Risk tier:
Entity:
Primary time windows:
Data sources:
Online features:
Offline features:
Detector portfolio:
Threshold policy:
Alert routing:
Case system:
Feedback source:
Dashboard:
Governance evidence:
Rollback / containment:

12.3 threshold policy 模板

字段	内容
Detector ID	模型、规则或组合策略标识。
Threshold owner	业务 owner、risk owner、platform owner。
Calibration data	使用的数据范围、排除项、回放窗口。
Metrics reviewed	precision/recall、false positives、alert volume、time to detect、customer friction。
Segment policy	哪些客群、渠道、地区、产品、use case 使用独立阈值。
Action bands	observe、review、step-up、block、escalate 的分数边界。
Capacity check	analyst 每日容量、SLA、预计积压。
Approval	批准人、日期、有效期、下一次复核日期。
Emergency override	事故期间谁可以临时调阈值，如何记录和回滚。

12.4 alert triage 模板

问题	记录
Alert ID / Case ID	唯一标识。
Severity	observe / review / step-up / block / executive escalation。
Trigger summary	哪些 detector 命中，分数和阈值是什么。
Entity context	相关客户、账户、设备、商户、模型、工具、租户。
Window context	当前窗口与历史基线、同群体基线的差异。
Evidence	原始事件、特征贡献、图关系、日志、trace、成本。
Analyst decision	confirmed、benign、false positives、escalated、suppressed。
Customer impact	是否有摩擦、冻结、拒绝、通知、投诉或补救。
Follow-up action	阈值调整、规则更新、模型复核、runbook 变更、事故升级。

12.5 label/feedback loop 模板

字段	内容
Label source	analyst、customer complaint、chargeback、SAR、SRE postmortem、security investigation、FinOps review。
Label type	confirmed risk、benign anomaly、false positives、missed detection、policy exception。
Label latency	即时、T+1、T+7、T+30、监管结论。
Confidence	low / medium / high / independently reviewed。
Training eligibility	是否可进入训练、评测、阈值回放或只用于运营分析。
Bias control	是否需要分群检查、抽样复核、二线确认。
Feedback target	feature、rule、model、threshold、case UX、runbook、policy。

12.6 runbook 模板

Runbook name:
Scenario:
Trigger:
Severity mapping:
First 15 minutes:
First hour:
Containment actions:
Required stakeholders:
Customer / regulator / executive communication rule:
Evidence preservation:
Rollback options:
Post-incident review:
Regression test:
Governance evidence location:

12.7 dashboard 模板

Dashboard section	指标
Executive view	risk heatmap、loss avoided、critical cases、residual risk、top drivers。
Queue health	alert volume、backlog、SLA breach、analyst capacity、suppression rate。
Detector quality	precision/recall、false positives、missed detections、segment performance。
Timeliness	time to detect、time to triage、time to contain、time to close。
Drift	feature drift、score drift、label drift、model version delta、prompt / index change impact。
AI cost	cost per use case、token spike、route anomaly、budget breach、retry loop。
Customer impact	false decline、MFA friction、complaints、appeals、remediation。
Governance	threshold approvals、open issues、policy exceptions、audit evidence completeness。

12.8 30-day/interview 模板

部分	内容
30-day artifact	一张架构图、一个 anomaly taxonomy、一个 threshold policy、一个 dashboard、一个面试答案集。
Case narrative	选择 fraud、AML、ops incidents、model drift、security、cost anomaly 中两个场景做端到端叙事。
Architecture answer	说明流批架构、entity/time/window、feature store、detector engine、case loop、governance evidence。
Product answer	说明如何减少 alert fatigue、平衡 precision/recall、处理 false positives、管理 analyst 体验。
Risk answer	说明阈值审批、模型验证、人工复核、NIST AI RMF 映射、审计证据。

13. 30 天训练计划

Week 1：异常检测业务地图与数据建模

Day	训练重点	产出
1	选定金融零售主场景：fraud、AML、ops incidents、model drift、security、cost anomaly	场景优先级矩阵。
2	为每个场景定义 entity/time/window	entity/window 设计表。
3	建立 anomaly taxonomy	10 类异常分类和处置动作。
4	设计数据契约	event、feature、score、decision、label 字段。
5	画检测平台上下文图	C4 Context + Container 草图。
6	设计标签来源和延迟真值	label dictionary。
7	复盘：把业务风险转成可监控信号	一页 executive brief。

Week 2：方法选择与评测

Day	训练重点	产出
8	statistical process control 与控制图	运营指标控制图设计。
9	Isolation Forest 原理与参数	适用场景、特征、阈值解释。
10	scikit-learn IsolationForest 工程用法	detector card。
11	PyOD 方法比较	champion/challenger 表。
12	autoencoders 风险与适用条件	autoencoder governance note。
13	NAB 与 streaming anomaly detection	time-to-detect 评测设计。
14	复盘：算法不是答案，运营闭环才是答案	方法选型 ADR。

Week 3：阈值、告警与运营闭环

Day	训练重点	产出
15	threshold calibration	阈值政策模板和审批逻辑。
16	precision/recall 和 false positives	阈值曲线解释稿。
17	alert fatigue 治理	去重、抑制、分层、路由策略。
18	Case UX	case 页面信息架构。
19	Label / feedback loop	标签闭环流程。
20	Runbook	fraud 或 cost spike runbook。
21	复盘：从告警到处置再到模型改进	运营机制图。

Week 4：治理、作品集与面试

Day	训练重点	产出
22	NIST AI RMF 映射	Govern / Map / Measure / Manage 对照表。
23	模型风险与变更管理	detector registry 和 release gate。
24	dashboard 设计	executive + analyst + platform 三层仪表盘。
25	tabletop 演练	prompt injection、cost spike、model drift 三个场景。
26	审计证据链	alert replay evidence pack。
27	系统设计面试	45 分钟白板答案。
28	产品面试	alert fatigue 与阈值治理答案。
29	风险治理面试	AI RMF、人工复核、残余风险答案。
30	总结作品集	一份完整 anomaly detection/risk monitoring platform playbook 摘要。

14. 面试答案

14.1 设计一个金融零售 anomaly detection/risk monitoring platform

30 秒版本

我会先按业务风险定义 anomaly taxonomy，再用 entity/time/window 建模，把交易、账户、设备、商户、模型调用、安全和成本事件接入流批一体的数据层。检测层不是单模型，而是规则、SPC、Isolation Forest、autoencoders、图异常和 streaming anomaly detection 的组合。模型分数进入 threshold policy 和 alert orchestration，再进入 case management、标签反馈、dashboard 和治理证据。核心指标不是 accuracy，而是 precision/recall、false positives、time to detect、case yield、客户摩擦和残余风险。

2 分钟版本

第一步是 Map：明确 fraud、AML、ops incidents、model drift、security、cost anomaly 的风险边界、实体、窗口、损失函数和处置 owner。第二步是 Measure：在 feature layer 生成速度、频率、偏差、peer group、图关系、模型行为和成本特征；用 statistical process control 监控稳定运营过程，用 Isolation Forest 发现高维行为异常，用 autoencoders 探索复杂正常模式偏离，用 NAB 思路评估流式检测的及时性。第三步是 Manage：通过 threshold calibration 把分数映射成 observe、review、step-up、block 和 executive escalation，并治理 alert fatigue。第四步是 Govern：保留数据契约、模型版本、阈值审批、case 处置、标签反馈、变更记录和审计证据，对齐 NIST AI RMF。

14.2 Isolation Forest、autoencoders、SPC 怎么取舍

30 秒版本

SPC 适合稳定过程和运营指标，Isolation Forest 适合高维表格行为异常，autoencoders 适合复杂非线性模式，但治理成本更高。金融零售通常不是三选一，而是用规则和 SPC 做可解释底线，用 Isolation Forest 做可扩展无监督检测，用 autoencoders 做复杂模式发现，再用 case feedback 和阈值校准控制误报。

追问准备

追问	回答要点
为什么不用一个深度模型解决全部问题	高风险场景需要可解释、可审批、可回放和可运营；黑箱分数不能替代处置证据。
Isolation Forest 的主要风险	contamination、分群差异、特征漂移、分数解释、阈值和 analyst 容量。
autoencoders 什么时候值得上	正常样本充足、模式复杂、已有标签复核、能管理漂移和解释成本。

14.3 如何处理 alert fatigue

30 秒版本

alert fatigue 不能靠让 analyst 更努力解决，要从平台层治理：去重、抑制、分层、路由、case narrative、容量约束、阈值回放和反馈闭环。每条告警都要有 owner、证据、建议动作和可学习的 disposition，否则它只是噪音。

2 分钟版本

我会先建立告警健康指标：alert volume、precision、false positives、SLA breach、backlog、suppression rate、action yield 和 analyst override。然后按 entity/time/window 合并重复告警，把同一实体同一窗口内的多 detector 命中合成一个 case。对已知维护、大促、事故期间的重复噪音做抑制；对高风险 security、fraud、AML、cost spike 建立不同路由。阈值不能只看模型分数，要回放历史数据并结合 analyst 容量和风险偏好。最后把 false positives 和 missed detections 回写到阈值、特征、规则、模型和 runbook。

14.4 threshold calibration 如何做得可审计

30 秒版本

可审计的 threshold calibration 要记录数据窗口、损失函数、precision/recall、false positives、分群表现、alert volume、客户摩擦、审批人、有效期和复核周期。阈值变更要像模型和规则变更一样进入 release gate。

关键表达

Threshold is a risk appetite decision, not just a model parameter.

中文表达：

阈值是风险偏好、运营容量、客户体验和监管义务的交界面，不只是模型参数。

14.5 如何把 AI 模型漂移纳入异常监控

30 秒版本

我会把模型漂移拆成 feature drift、score drift、label drift、behavior drift 和 business outcome drift。对 AI 系统还要看 prompt version、index version、tool call pattern、judge score、human override、cost per request 和安全拦截率。漂移不是自动重训练信号，先要判断是否数据质量、业务季节性、发布变更、攻击或真实客户行为变化。

落地做法

漂移类型	监控指标	动作
Feature drift	PSI、分位数变化、缺失率、freshness	检查数据管道、特征契约、业务活动。
Score drift	模型分数分布、拒绝率、阈值命中率	分群分析、回放、临时阈值审查。
Label drift	confirmed risk rate、false positives、case yield	更新评测集、标签质量复核。
Behavior drift	prompt / tool / index 命中模式变化	回滚或冻结相关组件。
Outcome drift	损失、投诉、SLA、成本、人工覆盖率	启动治理 review 或 incident loop。

14.6 AML 异常检测和欺诈异常检测有什么不同

30 秒版本

欺诈更强调实时止损、客户摩擦和快速确认；AML 更强调长窗口、关系网络、证据叙事、监管可解释性和 case quality。两者都用异常检测，但 entity、window、处置动作和成功指标不同。

维度	Fraud	AML
时间窗口	秒、分钟、小时	30 天、90 天、年度回看
主要实体	card、account、device、merchant、session	customer、beneficial owner、counterparty、network
动作	step-up、decline、freeze、review	investigate、EDD、case narrative、SAR decision
指标	loss avoided、false decline、time to detect	case quality、SAR conversion、regulatory defensibility
模型解释	快速 reason code	完整交易叙事和关系证据

14.7 如何把成本异常纳入 AI 平台治理

30 秒版本

AI cost anomaly 要像安全和稳定性一样纳入监控。按 use case、tenant、model、route、prompt、index、tool 和 team 归因，监控 token、长上下文、retry loop、cache miss、judge 调用和 embedding 批任务。处置动作包括 budget cap、模型降级、context 限制、缓存策略、路由切换和 owner 审批。

高级点

成本异常不是财务报表问题，而是架构问题：长上下文、无界 agent loop、错误 retry、低效检索、过度 judge、模型路由失控都会把 unit economics 打穿。

15. 作品集呈现建议

一个高级作品集页面可以这样组织：

区块	展示内容
Problem framing	金融零售为什么需要 anomaly detection/risk monitoring platform。
Architecture	流批一体架构、entity/time/window、feature layer、detector engine、case loop。
Method selection	SPC、Isolation Forest、autoencoders、PyOD、NAB 的取舍。
Product operations	alert fatigue、threshold calibration、precision/recall、false positives、case UX。
Governance	NIST AI RMF 映射、阈值审批、模型风险、审计证据。
Capstone scenario	fraud + AI cost anomaly 或 AML + model drift 的端到端案例。
Interview readiness	30 秒、2 分钟、系统设计白板答案。

最终要让面试官看到的不是“我懂异常检测算法”，而是：

我能把异常检测做成金融零售企业可上线、可运营、可治理、可审计、可持续迭代的风险监控平台。