2. 交易欺诈识别概述

在进入 Transformer 模型与序列建模之前，我们必须先把“问题本身”定义清楚：我们要识别的到底是什么欺诈？它发生在哪些业务场景？为什么传统规则和单点模型难以奏效？以及，最终用什么指标来判断模型是否真的有效。这一节将建立后续所有建模工作的业务与评估坐标系。

一、核心原理：欺诈识别的本质是“异常序列模式识别”

交易欺诈识别，本质上是在海量正常交易行为中，找出那些偏离正常模式且具有潜在资金损失风险的行为。它与传统二分类任务最大的区别在于：

• 极端类别不平衡：欺诈样本占比通常低于 0.1%，甚至低至百万分之一。
• 对抗性演化：欺诈者会主动调整策略，绕过已有规则与模型。
• 上下文依赖：单笔交易看似正常，但放在用户近期行为序列中则明显异常。
• 代价不对称：漏判（False Negative）造成的资金损失远高于误判（False Positive）带来的用户体验下降。

因此，欺诈识别不是简单的“分类”，而是在强对抗、强不平衡、强时序依赖下的风险排序问题。Transformer 之所以适合，正是因为它能对用户行为序列中的长距离依赖与全局上下文进行建模。

二、欺诈类型与业务场景

不同业务场景下的欺诈形态差异很大，识别策略也完全不同。下表梳理了常见类型及其关键特征：

三、识别难点：为什么传统方法容易失效

理解难点，才能理解为什么需要 Transformer。主要难点可归纳为四类：

1. 序列依赖与长距离上下文：用户当前交易是否异常，取决于过去数天甚至数周的行为。RNN/LSTM 在长序列上存在梯度消失与并行效率问题。
2. 概念漂移与对抗演化：欺诈模式随时间变化，昨天有效的规则今天可能失效。模型需要持续学习与快速迭代。
3. 标签稀疏与延迟：欺诈标签往往来自事后投诉、拒付或人工审核，存在数天到数周的延迟，导致训练样本滞后。
4. 误判成本高：拦截正常用户会带来客诉与流失，因此模型必须在高召回与低误杀之间精细平衡。

四、评估指标：从模型指标到业务指标

欺诈识别的评估必须同时关注模型排序能力与业务拦截效果。常用指标如下：

• PR-AUC（Precision-Recall AUC）：类别极不平衡时的首选指标，反映模型在不同阈值下的综合排序能力。
• Recall@K：在风险评分最高的 K 笔交易中，命中了多少真实欺诈。直接对应人工审核队列的容量。
• F1-Score / F-beta：当误判与漏判代价不同时，用 beta 调整权重。
• 业务指标：欺诈拦截率、资金损失率、误杀率、客诉率、人工审核通过率。

下面是一段典型的离线评估代码片段，展示如何在极不平衡数据上计算 PR-AUC 与 Recall@K：

from sklearn.metrics import average_precision_score, precision_recall_curve
import numpy as np

# y_true: 0/1 标签, y_score: 模型输出的欺诈概率
pr_auc = average_precision_score(y_true, y_score)
print(f"PR-AUC: {pr_auc:.4f}")

# Recall@K：取风险最高的 K 笔
def recall_at_k(y_true, y_score, k):
    order = np.argsort(-y_score)
    topk = y_true[order[:k]]
    return topk.sum() / max(y_true.sum(), 1)

for k in [100, 500, 1000]:
    print(f"Recall@{k}: {recall_at_k(y_true, y_score, k):.4f}")

五、案例复盘：一次典型的盗刷识别失败

某支付平台曾遇到一次盗刷事件：攻击者盗取用户账号后，先进行一笔小额充值（测试），再在 30 分钟后进行大额转账。传统规则只监控单笔金额，未捕捉到“小额测试→大额转账”的序列模式，导致漏判。

复盘发现：

• 单笔交易特征均未超过阈值；
• 但两笔交易的时间间隔、金额比例、设备切换构成了明显的异常序列；
• 若使用 Transformer 对用户近期交易序列建模，这种“测试-攻击”模式可以被注意力机制捕捉。

这个案例说明：欺诈识别的核心不在于单点特征，而在于序列中的行为模式与上下文关系。这正是后续章节中 Transformer 序列建模要解决的核心问题。