在事务文件中查找 100 个事务中依次出现 5 个以上序列号的事件

Posted 2023-05-09

【中文标题】在事务文件中查找 100 个事务中依次出现 5 个以上序列号的事件

【英文标题】：Finding events in a transaction file where more than 5 serial numbers appear in sequence within 100 transactions

【发布时间】：2009-07-02 10:16:29

【问题描述】：

我有一个不寻常的客户请求，涉及在线抽奖中的欺诈检测，我试图通过将尽可能多的任务推送到 SQL 中来尽可能高效地构建它。

结构如下：

表：代码 抽奖代码 |票类型 |顺序 A00000001 红色 1 A00000002 红色 2 ... A0000000X 红色 X B00000001 蓝色 1 ETC

可以有 X 个 ticket_types，每个都有自己的序列。抽奖代码是唯一的哈希，我只是为示例进行了简化。

现在的问题是这些代码是随机发布的，任何按顺序输入它们的事件（可能）都是欺诈性的。代码的输入记录在事务文件中，如下所示：

表：交易 用户 ID |抽奖代码 |交易号 |时间戳 1 A00000032 1 等等...

理想的规则是，如果在一组给定的 100 笔交易中按顺序输入了超过 5 个给定类型的抽奖代码，则它是可疑的，应该拉出所涉及的用户。

我最初的想法是首先尝试检测欺诈事件，然后为每个欺诈事件分别挖掘欺诈性用户交易。我想到的粗略的 SQL 是这样的：

选择 c.raffle_code, MIN(t.timestamp), MAX(t.timestamp), MIN(t.transaction_number), MAX(t.transaction_number) FROM 代码 c，交易 t WHERE c.raffle_code = t.raffle_code GROUP BY c.raffle_code HAVING ( MAX(c.sequence) - MIN(c.sequence) ) = ( COUNT(*) -1 ) AND (MAX(t.transaction_number) - MIN(t.transaction_number)) 4;

（感谢 Bell 在this question 中激发了这个想法）

这将在交易文件（transaction_number 范围和时间戳范围）中提供一个位置，以重新查询用户 ID。这需要对可疑事件进行直接验证才能被宣布为欺诈，但目前这是系统公认的警告。

上述 SQL 的问题是，如果在给定的 100 笔交易中出现序列为“3,4,5,6,7,48”的“红色”票证，则由于范围为 45，因此无法检测到，这很远大于 6 的计数，因此如果门票是随机输入的，则这是预期的发生。

事务文件注定会非常大并且经常被点击，因此使用服务器代码一次挖掘 100 个事务并构建事务堆栈以进行分析将变得非常低效。

有人遇到过这样的事情吗？除了非常短的文本简介之外，客户对他们的要求仍然很模糊，所以我也在考虑检测顺序输入的替代概念。

【问题讨论】：

“相当大”有多大？特定工单类型有多少行？

我们一开始预计会有数十万，但可能会根据反应扩大。

【参考方案1】：

我从您的问题中得到的印象是，您所说的“3,4,5,6,7,48”集合不算作欺诈，因为它不符合指定的标准，但您感觉到了应该算，因为感觉有点可疑。

检测可能的欺诈交易集的问题当然是棘手的——我们很容易感觉到交易集是欺诈性的，而无法为计算机定义明确的规则来遵循。

为什么不简单地降低被视为欺诈的序列集的长度？

您的直觉可能是这会引发太多误报。除非您有数据备份，否则请忽略它！

考虑一下：

非作弊用户输入几个作为两个连续抽奖代码的概率是多少？将此概率称为 X。 作弊用户输入两个连续抽奖代码的概率是多少？将此概率称为 Y。

如果 X >> Y，则任何两个或多个连续抽奖代码的集合都有很高的欺诈概率。

尝试首先将欺诈交易集定义为包含来自同一用户的两个或多个连续抽奖代码（在一组 100 个交易中）。看看这种情况实际发生的频率。

如果您发现误报过多，请将最小序列长度增加到 3。根据需要重复。

我觉得您过于谨慎地将不属于潜在欺诈的交易集识别为欺诈行为。尽量不要想太多。

这更多地与概率有关，而不是精度，因此您永远不会 100% 正确，而且您一开始也不会接近 100% 正确。对实际发生的情况进行一些培训、测试和检查是更好的方法。

【讨论】：

我同意收集误报几乎是不可避免的，合法用户可能会获得一系列票，因为它们是从一个池中实际发行的。您提出的第一点当然是对的，3,4,5,6,7,48 是欺诈性的，但只有 3,4,5,6,7 - 忽略 48，我想我通过说一个序列来混淆问题45 的范围是可以预期的，如 3、12、48 是可以的，但上面不是。合法与欺诈的概率是一个很好的观点，我一直在开发一个用户加权系统，可以突出显示超过一定数量的可疑行为的用户。