Anomaly Detection：Isolation Forest、Autoencoder 与 Risk Monitoring
Anomaly detection 的产品价值不在模型打分，而在把异常信号变成 risk monitoring system: 明确实体、窗口、异常类型、阈值、运营容量、分流策略、反馈标签和 incident 升级路径。
Anomaly Detection / Isolation Forest / Autoencoder / Risk Monitoring 解读
本篇为经典论文精读（历史回顾/经典打底定位），机制正文以原论文为锚点；最新进展见文末「SOTA 检查」。
核心问题: 异常检测不是“发现奇怪点”。金融零售 AI 需要把低频、高噪声、高代价事件转成可解释、可校准、可分流、可反馈、可审计的风险监控与运营闭环。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| Isolation Forest paper | https://ieeexplore.ieee.org/document/4781136 | 理解用随机切分和路径长度识别异常点（论文 2008-12, ICDM 2008） |
| scikit-learn IsolationForest | https://scikit-learn.org/stable/modules/generated/sklearn.ensemble.IsolationForest.html | 参考常用实现、参数和生产约束（访问日期: 2026-07-01） |
| PyOD | https://pyod.readthedocs.io/ | 参考多模型异常检测工具箱和集成方式（访问日期: 2026-07-01） |
| Numenta Anomaly Benchmark | https://github.com/numenta/NAB | 参考流式异常检测评估和早发现价值（访问日期: 2026-07-01） |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 把异常检测纳入 AI 风险管理和监控证据（AI RMF 1.0 发布 2023-01；GenAI Profile NIST-AI-600-1 发布 2024-07） |
核心导读
Anomaly detection 的产品价值不在模型打分，而在把异常信号变成 risk monitoring system: 明确实体、窗口、异常类型、阈值、运营容量、分流策略、反馈标签和 incident 升级路径。
Isolation Forest、Autoencoder、统计过程控制和流式检测各自解决不同信号问题。真正的系统取舍是误报与漏报、实时与批处理、解释性与发现能力、全局阈值与分层策略、模型信号与人工运营容量之间的平衡。
金融零售里的异常分数很少能直接变成客户动作。它更适合作为 alert routing、risk review、incident triage、模型监控或控制测试的输入；是否冻结账户、拒绝交易、提交 SAR、触发客户沟通或调整策略，需要规则、证据、人工判断和审批链共同决定。好的异常检测架构会保留 baseline、阈值版本、触发原因、处置结果和反馈标签，让系统能持续校准而不是制造无法解释的告警噪声。
问题定义
异常不是单一概念。没有 taxonomy 的异常检测会变成泛化告警池，最后被运营团队关闭。
| 异常类型 | 例子 | 主要风险 |
|---|---|---|
| Point anomaly | 单笔交易金额异常高 | 欺诈、误操作、系统错误 |
| Contextual anomaly | 节假日正常，普通日异常 | 阈值失真、误报 |
| Collective anomaly | 多个小额交易组合异常 | 洗钱、账户接管、羊毛党 |
| Drift anomaly | 模型输入分布突然变化 | 模型失效、策略过期 |
| Operational anomaly | 队列积压、SLA 下降 | 客诉、监管时效、成本失控 |
| Security anomaly | prompt injection 激增、工具拒绝率异常 | AI 安全事件 |
| Cost anomaly | token、GPU、model call 成本突增 | 平台预算和滥用风险 |
异常检测系统要先回答:
监控哪个实体，在什么时间窗口内，检测哪类偏离，
触发什么动作，由谁处理，如何记录结果并校准下一次？
核心原理
Isolation Forest
Isolation Forest 的直觉是: 异常点更容易被随机切分单独隔离，所以平均路径更短。它适合表格型特征、标签稀缺、快速 baseline 和相对可解释的异常分数。
生产风险:
| 风险 | 控制 |
|---|---|
| contamination 假设不准 | 用风险偏好和运营容量校准阈值 |
| 特征尺度和口径漂移 | 建立 feature contract 和分布监控 |
| 随机切分时间泄漏 | 用时间窗口回测 |
| 分数不是业务原因 | 配合 top deviation、case narrative 和人工证据 |
Autoencoder
Autoencoder 学习重构常见模式，重构误差大的样本可能是异常。它适合高维行为、日志、embedding 和非线性模式，但解释性弱，且训练数据被污染时可能学会重构异常。
Autoencoder 应作为 signal generator，而不是直接决策器。它的输出应进入 risk scoring、alert routing 或 human review，不应单独决定冻结账户、拒绝交易或处罚客户。
统计过程控制
规则和统计基线仍然重要:
| 方法 | 用途 |
|---|---|
| Z-score / robust z-score | 单指标偏离监控 |
| EWMA | 平滑趋势突变 |
| Control chart | 过程稳定性监控 |
| Seasonal baseline | 按小时、星期、节假日比较 |
| Rule threshold | 明确业务红线 |
金融零售更适合组合:
business rule -> statistical baseline -> ML anomaly score -> policy threshold -> triage workflow
系统/架构模型
Risk monitoring platform:
events/logs/transactions
-> entity registry
-> stream and batch window features
-> anomaly model ensemble
-> threshold and policy engine
-> alert grouping and suppression
-> triage workbench
-> case outcome labels
-> recalibration and monitoring
-> incident management
核心组件:
| 组件 | 职责 |
|---|---|
| Entity registry | 定义客户、账户、商户、设备、模型、服务、团队等监控对象 |
| Window feature service | 管理滚动窗口、季节窗口、同群对比和延迟数据 |
| Model ensemble | Isolation Forest、autoencoder、统计规则、图信号、签名规则 |
| Policy engine | 管理阈值、风险等级、容量、升级和禁止动作 |
| Alert dedup | 合并重复告警，减少噪声和重复处理 |
| Triage workbench | 展示证据、原因、历史、推荐动作、影响范围 |
| Feedback loop | 记录 true positive、false positive、override、root cause |
| Drift monitor | 监控输入、分数、告警量、处理结果和模型退化 |
流式异常检测要显式设计窗口、延迟和合并逻辑。NAB 的启发是早发现有价值，但早发现也会提高噪声，必须用运营动作和损害函数衡量。
关键机制与取舍
| 取舍 | 判断方式 |
|---|---|
| Precision vs recall | 欺诈拦截偏 recall，人工队列和客户摩擦场景必须控制 precision |
| 全局阈值 vs 分层阈值 | 客户等级、商户类型、地区、渠道和风险等级不同，阈值不应一刀切 |
| 实时拦截 vs 事后调查 | 资金损失类需要实时，AML 和运营异常可批量 review |
| 单模型 vs ensemble | 单模型简单，ensemble 更稳但解释和校准更复杂 |
| 自动动作 vs 人工复核 | 高损害动作必须接 policy 和 human review |
| 告警量 vs 运营容量 | 告警超过可处理容量时，系统实际失效 |
阈值策略应是 policy，而不是模型服务里的常量:
score >= P99 and high-value entity -> immediate review
score >= P95 and repeated within 24h -> queue priority 1
score >= P90 and low-risk entity -> monitor only
known incident signature -> bypass ML threshold and escalate
证据与控制
异常检测的证据链包括模型证据和运营证据:
| 证据 | 说明 |
|---|---|
| Backtest | 用历史窗口评估早发现、误报、漏报和业务损失 |
| Alert quality | precision、false positive、true positive、inconclusive |
| Capacity fit | 每日告警量、处理 SLA、积压和人力消耗 |
| Root cause | fraud、campaign、system issue、data delay、model drift、security |
| Fairness slice | 不同客群、地区、商户、渠道是否被不公平误伤 |
| Incident linkage | 大规模异常是否能升级为 SEV 流程 |
| Recalibration | 阈值、特征、模型和规则如何根据反馈更新 |
标签 schema:
| 字段 | 示例 |
|---|---|
| alert_id | 唯一告警 |
| entity_id | 客户、账户、商户、模型、服务 |
| anomaly_type | fraud / AML / ops / drift / security / cost |
| decision | dismiss / monitor / investigate / block / escalate |
| outcome | true positive / false positive / inconclusive |
| root_cause | campaign / attack / data delay / model drift |
| reviewer | 人工复核人 |
| evidence | 关键证据链接 |
不要把“没有处理”当成负样本。未处理告警只是未观察结果，直接当负样本会污染模型。
AI产品/金融零售场景
欺诈交易异常
实体包括 account、card、merchant、device。特征包括金额、频次、地理、设备、商户类别、历史行为偏离。系统可组合 Isolation Forest baseline、图信号和规则阈值，输出短信确认、人工 review、临时限额或强认证。核心指标是 fraud capture、false positive、customer friction 和 review SLA。
AML 告警队列异常
实体包括 customer、case type、analyst team。监控告警量、关闭率、重开率、SAR 转化率和队列年龄。适合 seasonal baseline + collective anomaly，用于临时调配人员、排查规则变更和控制监管时效。
AI 平台成本异常
实体包括 app、team、model、tenant。特征包括 token、latency、cache hit、model route、tool calls。EWMA + Isolation Forest 可用于检测成本突增，动作包括 rate limit、模型降级、缓存策略调整和 incident review。
AI 安全异常
Prompt injection attempt、工具拒绝率、policy deny、RAG ACL mismatch 和敏感输出都可以作为安全异常流入 SecOps。这里异常检测与安全检测不是两套孤岛。
反模式
- 先选模型再定义异常类型、实体、窗口和处理动作。
- 用一个全局 anomaly score 管所有业务风险。
- 阈值只按模型分数设置，不考虑人工容量、误伤成本和风险等级。
- 告警没有 dedup、suppression 和 priority，导致告警疲劳。
- 只统计 AUC，不统计 precision、处理 SLA、false positive 和根因。
- 自动阻断高价值客户或高风险业务动作，却没有人工复核和审计。
- 反馈结果不回流，阈值和模型长期不校准。
最终心智模型
异常检测不是模型任务，而是风险运营系统。模型负责发现偏离，policy 负责决定动作，triage 负责处理证据，feedback 负责校准下一轮，incident 流程负责处理大规模或高损害异常。
判断系统是否成熟，不看用了 Isolation Forest 还是 Autoencoder，而看它能否在误报、漏报、客户摩擦、运营容量和审计证据之间稳定运行，并把每一次告警转化为更好的阈值、特征、规则或流程。
SOTA 检查 (2026-07-01)
- Isolation Forest (2008-12) 在表格型/无标签场景仍是主流 baseline，未被替代：2025-2026 的检索结果显示 iForest 因通用性和可扩展性仍被称为"最流行的异常检测器之一"，2025 年仍有生产级混合方案发布（如电力欺诈检测中 Isolation Forest 无监督筛查 + XGBoost 有监督分类的 hybrid 框架，MDPI Energies 2025）。本篇把 iForest 定位为"快速 baseline + signal generator 而非决策器"的结论仍成立。
- iForest 的已知短板已有明确的改进谱系：轴平行切分在高维/非线性可分空间失效 + 对 artefact 区域打分偏低的算法偏差，主流补丁是 Deep Isolation Forest（arXiv 2206.06602，2022-06，IEEE TKDE 2023 版），用随机表示集成替换轴平行切分，在表格/图/时序数据上超越原版 iForest 和多个深度检测器，同时保留 iForest 的可扩展性；以及 OptIForest（arXiv 2306.12703，2023-06）。若本篇的 "Model ensemble" 组件要升级，Deep iForest 是首选替代信号源。
- 时序异常检测的研究前沿已转向 foundation model 路线（2025-2026）：综述《Foundation Models for Anomaly Detection: Vision and Challenges》（AI Magazine, 2025）把 FM 按 encoder/detector/interpreter 分类；VLM4TS（AAAI 2026 Oral）用 vision-language 模型在 11 个工业异常基准上超过统计模型、深度模型和 TimesFM/UniTS 等时序基础模型；TimeRadar（KDD 2026）、ChronosAD（arXiv 2606.01300，2026-06）等继续推进。这条线目前主要影响本篇 "Drift/Operational anomaly" 类监控信号，对交易级欺诈的表格特征场景冲击较小。
- 金融风控落地侧 2026 年的主叙事是 agentic 化，而非换检测模型：McKinsey（2026）与 arXiv 2606.17555（2026-06，银行多向量欺诈+AML 安全 agent）描述的方向是"检测信号 → AI agent 发起工单/调证/按风险阈值升级 + LLM 助手辅助分析师查询政策与数据"——这正好落在本篇 triage workbench / policy engine / human review 的框架上，即变化发生在检测层之后的运营层。库内配套案例见
docs/aipa/day1-aml-copilot-product-discovery-jtbd.md与docs/aipa/day2-aml-ai-competitive-landscape.md（2026-06，AIPA-120 P1）。 - 治理锚点更新：NIST AI RMF 1.0（2023-01）仍是现行框架，未发布 2.0；其 Generative AI Profile（NIST-AI-600-1，2024-07）新增的 12 类 GenAI 风险（含 confabulation、prompt injection）直接对应本篇 "Security anomaly / Cost anomaly" 两行——把 prompt injection 激增、工具拒绝率、token 成本突增纳入异常监控实体的做法与其对齐。
- 不随版本过时的框架性结论：异常 taxonomy（point/contextual/collective/drift/ops/security/cost）、"business rule → statistical baseline → ML score → policy threshold → triage workflow" 的组合管线、阈值即 policy 而非模型常量、告警量必须匹配运营容量、"未处理告警 ≠ 负样本" 的标签纪律——这些与具体检测算法解耦，换成 Deep iForest 或 TSFM 后依然成立。