建议使用以下浏览器,以获得最佳体验。 IE 9.0+以上版本 Chrome 31+ 谷歌浏览器 Firefox 30+ 火狐浏览器
温馨提示

抱歉,您需设置社区昵称后才能参与社区互动!

前往修改
我再想想

2020华为软件精英挑战赛

话题 : 430 成员 : 6437

加入HCSD

关于数据集的个人看法和建议

佚名 2020/5/7 1918

个人观点,不喜勿喷:

比赛题目是找循环转账,而非找环。人们转账实际上与社交圈子密不可分,试想我们转账是否因为地域、工作等原因有比较固定的经常转账的渠道,这渠道构成一个个转账圈子,所以会容易呈现多个接近完全图的子图组合成数据集的现象,这是比较接近现实的(或许数据集就是来自真实的银行转账记录)。

另外我们测试发现线上和民间数据集一个巨大的差别是金额筛选能力:这个大多数人可能都发现了,也不是什么重要特征,就分享给大家,线下金额条件过滤掉的环远远多于环内节点不相等过滤掉的环,因此如果先判断金额,金额不符合不用判断后面,能更快一点,线下测试也确实普遍更快,但到线上就成了负优化。原因很简单,线下数据集金额是完全随机的(我们按照现在主流的11W节点200W边生成数据集,金额是从0到INT32_MAX随机,刚好有效环是2000W左右),随便找两条“转账”,金额差距都十分大,现实中哪有这样的?商品价格都比较固定,同一圈子经济水平又比较接近。所以线上数据集确实可能是真实转账数据,至少也是比较接近的。找环本就没有绝对优秀的算法,只是针对不同特征与现实场景有不同适合的算法,我猜这个题原本的目的就是研究适合找金融转账的环的算法,随机生成的数据集并不能体现金融转账的特征,所以希望官方保持初心,不要更改数据集的特征,毕(不)竟(然)研(之)究(前)现(的)实(研)问(究)题(就)才(白)更(费)有(了)趣(╮(╯﹏╰)╭)。

但民愤也不是没有道理,这个比赛确实一定程度上变成了IO大赛,原因也是无奈(大佬:算法太快,怪我咯╮( •́ω•̀ )╭),IO不仅包括读写文件,还包括int字符串互转、输出前结果的储存等(以下说IO部分指的是包括这些),这些与搜索无关的部分时间占比真的很严重,如何让IO占比减少?一般提高数据规模是无效的,因为转账圈子不会扩大,只会让圈子数量增多,而每个圈子相对独立(圈子间的转账环很少),搜索增多的同时输入、转换、输出也等比例增多,IO占比还是很大,所以针对这点我有如下建议:

  • 规则上更改让搜索部分更复杂一点(感觉已经晚了请忽略),如分支转账,某洗钱团伙将大金额分成多份转账不同支路再最终汇集起来...

  • 降低鲁棒性,是的没错,是降低鲁棒性,维持鲁棒性意味着要做很多额外处理,这些处理多在IO部分,导致IO占比进一步提高,如果告诉选手ID是从0开始的连续的节点或者是固定长度的(如8位字符串),那么相信大家IO时间就能缩短很多,或许有人说对鲁棒性高的人不公平,如果大家都知道(在赛题中说明),那也是公平的,因为...我们真的缺这点鲁棒能力吗。

  • 线下研究用数据集太小,稍微抖一抖,优化就没有,很难针对金融转账的特征研究算法,导致选手们不得不自己造民间数据集,经常线下正优化,线上负优化,线上线下一直盲猜浪费时间也制约着最后的算法上线。或许怕根据数据集的特征“取巧”,如果是针对数值特征的取巧那可能是真的取巧,去鲁棒性后相信没什么可以取巧的了,如果是根据数据分布特征的“取巧”,那不正是符合对金融转账应用场景的专属优化算法吗。如果担心该测试集取自线上评测测试集,会让算法更偏向于一个银行的情况(假设这些测试集都来自一个银行),大可测评运行来自多个银行的混合测试集或者运行多份来自不同银行的同等量级的测试集取平均,前者选手研究的特征也是金融转账的普遍特征,没有“过拟合”一说,后者选手也至少能做真正的查找循环转账的研究。所以建议开放一份至少20W条转账的测试集。

可能由于我了解的信息不够,推理不一定正确,如有问题还望指出,一起分析。


回复 (1)

2020/5/7 17:35

这个比赛是目的为了推广鲲鹏芯片服务器,让选手们学习相关的性能优化技巧,并选拔出算法/系统优化能力优秀的选手。如果是为了应用到实际的金融场景,就不会要求这么简单的算法,也没必要让选手追求极致的运行速度。

公司显然没有真实的金融转账数据。如果要人工构造类似的数据特征,那么就至少应该公布线上测试数据或者与其同分布的数据,按照类似大学生超算竞赛的模式进行,否则竞赛选**的就不会是算法/系统优化方面的能力最强的选手。


"ba chu" is a censored word ??? why ???

上划加载中
标签
您还可以添加5个标签
  • 没有搜索到和“关键字”相关的标签
  • 云产品
  • 解决方案
  • 技术领域
  • 通用技术
  • 平台功能
取消

佚名

角色:成员

话题:8

发消息
发表于2020年05月07日 12:50:57 19181
直达本楼层的链接
楼主
正序浏览 只看该作者
[复赛问题咨询] 关于数据集的个人看法和建议

个人观点,不喜勿喷:

比赛题目是找循环转账,而非找环。人们转账实际上与社交圈子密不可分,试想我们转账是否因为地域、工作等原因有比较固定的经常转账的渠道,这渠道构成一个个转账圈子,所以会容易呈现多个接近完全图的子图组合成数据集的现象,这是比较接近现实的(或许数据集就是来自真实的银行转账记录)。

另外我们测试发现线上和民间数据集一个巨大的差别是金额筛选能力:这个大多数人可能都发现了,也不是什么重要特征,就分享给大家,线下金额条件过滤掉的环远远多于环内节点不相等过滤掉的环,因此如果先判断金额,金额不符合不用判断后面,能更快一点,线下测试也确实普遍更快,但到线上就成了负优化。原因很简单,线下数据集金额是完全随机的(我们按照现在主流的11W节点200W边生成数据集,金额是从0到INT32_MAX随机,刚好有效环是2000W左右),随便找两条“转账”,金额差距都十分大,现实中哪有这样的?商品价格都比较固定,同一圈子经济水平又比较接近。所以线上数据集确实可能是真实转账数据,至少也是比较接近的。找环本就没有绝对优秀的算法,只是针对不同特征与现实场景有不同适合的算法,我猜这个题原本的目的就是研究适合找金融转账的环的算法,随机生成的数据集并不能体现金融转账的特征,所以希望官方保持初心,不要更改数据集的特征,毕(不)竟(然)研(之)究(前)现(的)实(研)问(究)题(就)才(白)更(费)有(了)趣(╮(╯﹏╰)╭)。

但民愤也不是没有道理,这个比赛确实一定程度上变成了IO大赛,原因也是无奈(大佬:算法太快,怪我咯╮( •́ω•̀ )╭),IO不仅包括读写文件,还包括int字符串互转、输出前结果的储存等(以下说IO部分指的是包括这些),这些与搜索无关的部分时间占比真的很严重,如何让IO占比减少?一般提高数据规模是无效的,因为转账圈子不会扩大,只会让圈子数量增多,而每个圈子相对独立(圈子间的转账环很少),搜索增多的同时输入、转换、输出也等比例增多,IO占比还是很大,所以针对这点我有如下建议:

  • 规则上更改让搜索部分更复杂一点(感觉已经晚了请忽略),如分支转账,某洗钱团伙将大金额分成多份转账不同支路再最终汇集起来...

  • 降低鲁棒性,是的没错,是降低鲁棒性,维持鲁棒性意味着要做很多额外处理,这些处理多在IO部分,导致IO占比进一步提高,如果告诉选手ID是从0开始的连续的节点或者是固定长度的(如8位字符串),那么相信大家IO时间就能缩短很多,或许有人说对鲁棒性高的人不公平,如果大家都知道(在赛题中说明),那也是公平的,因为...我们真的缺这点鲁棒能力吗。

  • 线下研究用数据集太小,稍微抖一抖,优化就没有,很难针对金融转账的特征研究算法,导致选手们不得不自己造民间数据集,经常线下正优化,线上负优化,线上线下一直盲猜浪费时间也制约着最后的算法上线。或许怕根据数据集的特征“取巧”,如果是针对数值特征的取巧那可能是真的取巧,去鲁棒性后相信没什么可以取巧的了,如果是根据数据分布特征的“取巧”,那不正是符合对金融转账应用场景的专属优化算法吗。如果担心该测试集取自线上评测测试集,会让算法更偏向于一个银行的情况(假设这些测试集都来自一个银行),大可测评运行来自多个银行的混合测试集或者运行多份来自不同银行的同等量级的测试集取平均,前者选手研究的特征也是金融转账的普遍特征,没有“过拟合”一说,后者选手也至少能做真正的查找循环转账的研究。所以建议开放一份至少20W条转账的测试集。

可能由于我了解的信息不够,推理不一定正确,如有问题还望指出,一起分析。


点赞1 举报
分享

分享文章到朋友圈

分享文章到微博

288acbf2fe6c2f8deb82

角色:成员

话题:3

发消息
发表于2020年05月07日 17:35:30
直达本楼层的链接
沙发
只看该作者

这个比赛是目的为了推广鲲鹏芯片服务器,让选手们学习相关的性能优化技巧,并选拔出算法/系统优化能力优秀的选手。如果是为了应用到实际的金融场景,就不会要求这么简单的算法,也没必要让选手追求极致的运行速度。

公司显然没有真实的金融转账数据。如果要人工构造类似的数据特征,那么就至少应该公布线上测试数据或者与其同分布的数据,按照类似大学生超算竞赛的模式进行,否则竞赛选**的就不会是算法/系统优化方面的能力最强的选手。


"ba chu" is a censored word ??? why ???

点赞 评论 引用 举报

游客

您需要登录后才可以回帖 登录 | 立即注册