3. 异常检测概述
在重复付款与重复报销的治理中，异常检测不是单一算法，而是一套从业务定义到技术落地的完整体系。理解异常类型、检测范式和主流方法的边界，决定了后续模型选型、规则编写与误报控制的成败。本节将建立这一认知框架，为后续实战打下基础。
一、核心原理：异常的本质与三类异常
异常检测的核心假设是：正常数据存在高密度、可重复的模式，而异常数据偏离这些模式。在财务场景中，异常并不等同于错误，它只是“值得进一步核查”的信号。根据偏离方式，可将异常分为三类：
- 点异常（Point Anomaly）：单条记录本身异常。例如同一张发票号在一天内被报销两次，金额、商户、时间高度一致。
- 上下文异常（Contextual Anomaly）：单看数值正常，但在特定上下文中异常。例如某员工平时差旅费每月2000元，某月突然报销2万元，金额本身合法，但相对其历史行为异常。
- 集体异常（Collective Anomaly）：一组记录整体异常，单条看都正常。例如多个供应商在同一周集中提交小额发票，合计金额巨大，呈现拆分报销特征。
重复付款与重复报销主要对应点异常和集体异常；而“同一员工短期内高频报销”则属于上下文异常。检测前必须先明确目标异常类型，否则规则与模型会失焦。
二、检测范式：从规则到学习的连续谱
异常检测范式可分为三大类，它们在可解释性、泛化能力和维护成本上形成权衡：
- 基于规则：由业务专家编写确定性条件，如“发票号相同且金额相同则标记”。优点是透明、可审计、零训练成本；缺点是难以覆盖未知模式，规则膨胀后维护困难。
- 基于统计与距离：假设正常数据服从某种分布，偏离均值超过阈值即异常。例如对报销金额做Z-score，|Z|>3标记。适合数值型、分布稳定的场景。
- 基于机器学习：包括无监督（孤立森林、LOF、自编码器）与有监督（XGBoost、逻辑回归）。无监督无需标签，适合冷启动；有监督精度高，但依赖高质量标注。
实际项目中，最佳实践是“规则引擎兜底 + 机器学习提召回”的混合范式。规则负责高置信、可解释的硬性重复，模型负责发现隐蔽的集体异常和上下文异常。
三、方法流程：一个可落地的检测流水线
无论采用哪种方法，异常检测流程都遵循相似步骤。以下是一个面向重复报销的典型流水线：
1. 数据接入：报销单、发票、付款记录、供应商主数据
2. 特征工程：金额、时间差、发票号哈希、商户名归一化、员工历史均值
3. 规则层：精确匹配（发票号+金额+日期）→ 输出高置信重复
4. 模型层：孤立森林对剩余记录打分 → 输出异常分数
5. 融合层：规则命中直接告警；模型分数 > 0.85 进入人工复核
6. 反馈闭环：复核结果回写标签，用于模型迭代与规则调优
其中特征工程是成败关键。例如“发票号”需先做去空格、大小写归一化；“商户名”需做别名合并，否则“京东”与“京东商城”会被误判为不同商户，导致重复检测漏报。
四、规则引擎与机器学习方法对比
下表从六个维度对比两类方法，帮助你在不同阶段做出选择：
| 对比维度 | 规则引擎 | 机器学习方法 |
|---|---|---|
| 可解释性 | 高，每条告警可追溯至具体条件 | 低至中，需SHAP等工具辅助解释 |
| 冷启动成本 | 低，专家经验即可上线 | 中高，需历史数据与特征工程 |
| 未知模式发现 | 弱，只能覆盖已知模式 | 强，可发现隐蔽集体异常 |
| 误报控制 | 阈值明确，误报可控但易漏报 | 需调参，误报与漏报需权衡 |
| 维护成本 | 规则膨胀后维护高 | 需持续监控数据漂移与模型衰减 |
| 适用阶段 | 初期快速上线、合规审计 | 数据积累后提升召回与覆盖率 |
建议采用“规则先行、模型增强”的演进路线：先用规则覆盖80%的明确重复，积累标签后再引入无监督模型挖掘剩余异常。
五、案例与误区复盘
案例：某企业差旅报销重复检测
该企业初期仅用“发票号+金额”规则，上线首月命中120笔重复，但复核发现其中35笔为同一发票分次报销（业务允许），误报率29%。引入上下文特征后，增加“同一发票号在7天内出现次数>1且报销人相同”条件，误报降至8%。随后用孤立森林对剩余记录打分，又发现17笔“不同发票号但商户、金额、时间高度接近”的拆分报销，属于规则无法覆盖的集体异常。
常见误区一：把异常检测等同于找错误。异常只是信号，必须结合业务上下文复核。误区二：追求零误报。过度收紧阈值会导致漏报，重复付款的漏报成本远高于误报。误区三：忽视数据质量。发票号格式不统一、商户名未归一化，会让任何算法失效。
复盘要点：先定义异常类型，再选择检测范式；规则与模型不是替代关系，而是互补关系；上线后必须建立“告警—复核—反馈”闭环，否则模型会随业务变化而衰减。