IEEE-CIS Fraud Detection（一）

IEEE-CIS Fraud Detection（一）

本博客是对kaggle上的一个检测欺诈的项目的top1方案的翻译，部分是博主自己翻译的，部分是机翻，中间会加上自己的补充，力求小白也能看懂。

题目
IEEE-CIS工作于各种人工智能和机器学习领域，包括深层神经网络、模糊系统、进化计算和群体智能。今天，他们与世界领先的支付服务公司Vesta Corporation合作，寻求欺诈预防行业的最佳解决方案，现在邀请您加入挑战。
在这个竞赛中，你将在一个具有挑战性的大规模数据集上对机器学习模型进行基准测试。这些数据来自Vesta的真实电子商务交易，包含从设备类型到产品特征等等数据。您也有机会创建新的特征来改进您的结果。

标记说明
大多数代码块前面都会有一段注释，是博主对代码段作用的描述或者部分代码的解释(当然部分是博主自己写的，部分是博主在网上找来的资料)。空了一行后，是kaggle的大佬的代码。

数据集和属性含义
本项目有两个数据集：身份信息数据集、交易数据集
在交易数据集中，有以下属性：

• transactionDT：与题目给定的参考时间的相差时间（不是实际时间戳）
• transactionAMT：交易付款金额（美元）
• transactionCD：产品代号（每次交易中的产品）
• card1 - card6：支付卡的信息（如卡的类型、卡的种类、发卡银行、国家等）。
• addr：地址
• dist：距离
• P_ and (R__) emaildomain：购买者和收件人电子邮件域
• C1-C14：计数，例如找到与支付卡关联的地址数等。其实际含义未知
• D1-D15：时间间隔，例如距上一个交易的天数等。
• M1-M9：匹配，如卡上的姓名和地址等。
• Vxxx：Vesta 设计了丰富的功能，包括排名、计数和其他实体关系。

在身份信息数据集中的变量是标识信息与事务关联的网络连接信息（IP、ISP、代理等）和数字签名（UA/浏览器/os/版本等）。

以下就是top1大佬写的思路的翻译了。

时间并不是最重要的
对抗性验证的AUC=1的原因并不是因为欺诈的性质随着时间的推移发生了根本性的变化，而是因为数据集中的客户随着时间的推移发生了根本性的变化。
你一旦明白了这个，你将会知道在这个比赛中的挑战是建立一个能预测没有见过的用户的模型（而不是未知时间）。下图展示了在私有数据集（此数据集有400,000行）上的数据。68.2%的数据中的用户在训练集中没有出现。16.4%的数据集中的用户在训练集和测试集中都出现了。还有15.4%我们无法确定。每一条蓝线都代表一个用户。每一个用户做了很多交易，蓝线的左端是用户第一次交易的时间并且蓝线的右端是用户最后的交易时间。

神奇的特征
我们不是在预测欺诈交易。一旦一个用户（或者一张信用卡）是具有欺诈性的，他们的整个账户就会转变为具有欺诈性的。因此，我们是在预测具有欺诈性的用户（或者信用卡）。
主办方Lynn所说：我们分类的逻辑是将记录为拒收的交易定义为欺诈交易并且把跟在交易后面的用户账户、电子邮件地址或者订单地址等直接与以上交易相关联的都视为欺诈的。如果以上属性都没有被记为欺诈并且发现该交易时长（第一次交易到最后一次交易）超过了120天，我们就将该交易定义为合法交易(isFraud=0）。
你可能认为在120天后，会有卡/用户变成无欺诈性的。但是在训练集中我们很少看到这样的。（可能是因为欺诈信用卡被停止而不是被重复利用）。下图的饼图展示了这一点。训练集有73838个用户（或者信用卡）有着两个及以上的交易。当然，71575（96.9%）是一直是无欺诈性的并且2134（2.9%）是一直为欺诈性的。只有129（0.2%）的用户是既有非欺诈性又有欺诈性的（即一段时间是欺诈性，一段时间是非欺诈性的）。

欺诈客户
下面是2134个示例中的一个，我可以向您展示isFraud=1的客户。这是client=2988694标识客户的关键是三列card1、addr1和D1。D1列为“客户（信用卡）开始使用的天数”。因此，如果我们创建D1n=TransactionDay-D1，我们得到卡片开始的日期（其中TransactionDay=TransactionDT/（246060））。在下面的示例中，此信用卡开始于日期=-81（大约是2017年9月10日，因为数据集被认为开始于2017年12月1日）。我们还可以看到D3n=TransactionDay-D3是每个用户上一个事务的日期的指针。（还有更多的属性可以帮助我们识别客户）。

防止过拟合
为了防止过拟合训练集和公共测试集的数据，我们不用直接使用UID，也不能使用大量的能帮助区分用户的属性，比如D、V和ID列。（你通过训练集/测试集的对抗验证得出的LGBM模型的属性重要性可以知道用哪些属性用来区分用户）。
我们不能将UID作为一个新属性添加进来。因为68.2%的在私测试集上的用户不在训练集上。所以我们必须创造联合属性（即多个属性的组合）。举个例子，我们可以取所有的C、M列，然后创造这样的新属性：df.groupby(‘uid’)[CM_columns].agg([‘mean’])。接着我们删除列uid。现在我们的模型有区分未见过的用户的能力。

如何找到uid
如何寻找UID（不同的鉴定）
训练集和测试集有着不同的用户集合（有些用户相同，有些用户不同），所以我们可以通过使用对抗验证来寻找哪些属性帮助区分用户（即将训练集和测试集混合在一起。然后增加一个新的布尔属性:这是训练集还是测试集？然后训练一个模型来区分交易是属于训练集还是测试集）。如果你在转换D属性后，只在前53个属性上做这些，你会发现AUC=0.999并且这些属性很重要。

我们发现最重要的用来区分用户的属性是D10n, D1n, D15n, C13, D4n, card1, D2n, card2, addr1, TransactionAmt和 dist1。这些是我们在寻找用户时必须使用的属性。

代码样例
为了提高模型的泛化能力，我们将从card1, addr1, D1n中生成uid，并且提供其他特性来提高其准确性。
D4n, D10n, D15n是特定的时间（其中，D4n=day-D4），所以我们产生聚合均值和标准差。如果一个特定的uid在D15上有标准差等于0，则我们知道所有的D15是相同的（不变的）。如果标准差不等于0，则特定的uid应该包含2个及以上的用户并且我们的模型应该将它们分开。
属性C13是一个累计和属性。因此我们更喜欢根据uid来聚集。如果聚集后的计数等于uid_FE（其中uid-FE是uid中的事务数），那么我们就知道这是一个客户。如果uid_FE不等于AG（C13,uid,nunique），则这个uid包含了2个及以上的用户，所以我们的模型要分开他们。

df['D1n'] = np.floor(df.TransactionDT / (24*60*60)) - df.D1
df['uid'] = df.card1.astype(str)+'_'+df.add1.astype(str)+'_'+df.D1n.astype(str)
encode_AG(['D4n','D10n','D15n'],['uid'],['mean','std'])
encode_AG(['TransactionAmt','dist1'],['uid'],['mean','std'])
encode_AG(['C13'], ['uid'],['nunique'])

V属性
我们只在V属性上使用对抗验证，依旧能得到AUC=0.999。以下的属性被发现是重要的：

属性V126-V136和属性V306-V320对区分用户都很重要。在使用了关联分析进行属性规约后，我们留下了以下的V属性并且使用他们在uid上聚集。

encode_AG(['V127','V136','V307','V309','V314,'V320`],['uid'],['nunique']) 

划分用户
上面的六行代码可以帮助我们找到用户/信用卡。现在我们必须给我们的模型提供大量的特征来划分用户。再一次地，我们通过在uid上聚集重要的属性来实现它。

encode_AG(['D9'],['uid'],['mean','std'])
encode_AG(['P_emaildomain','DT_M','id_02','cents'], ['uid'], ['nunique'])
encode_AG(['C'+str(x) for x in range(1,15) if x!=3],['uid'],['mean'])
encode_AG(['M'+str(x) for x in range(1,10)],['uid'],['mean'])

后处理
分析表明，来自一个客户的所有交易要么都是isFraud=0，要么都是isFraud=1。换句话说，他们所有的预测都是一样的。因此，我们的后处理是用一个客户的平均预测来替换来自一个客户的所有预测（包括来自训练集的isFraud值）。康斯坦丁写了一个脚本，在这里找到了uid。注意，我们的模型不使用脚本的uid。如上所述，我们的模型自己找到客户。

以上只是大佬方案的冰山一角，本来想把XGB代码放上，奈何太长，影响阅读效果。这一篇先写到这儿。