什么是风控系统，风控系统架构及建设详解？-营销圈

什么是风控系统，风控系统架构及建设详解？

用户投稿 • 2022年5月13日 am7:50 • 网络资讯 • 阅读 519

最近我在思考如何让团队主动写单元测试，提高系统质量的问题。越想越觉得这不是一个简单的没空写单测的问题，而是一个工程可行性的问题。我分享一个在前东家做风控系统时的『工程可行性』故事。

我的前东家是一家互联网金融公司，刚加入公司后不久，我用Clojure实现了一套风控系统。之后就不断地有人站出来，号称用更先进的技术——比如用大数据技术或机器学习技术等——重构风控系统，但直到我离开公司，那套系统也没被成功取代掉。反倒大数据总监与算法总监是换了一任又一任；并且他们团队的规模也一度超过300人，而我们小组成员从来没超过20人。

我以前也没想明白其中的道理，直到从前东家出来后，作为旁观者反而能想通了一些原因：与其他团队相比，我们做对了的一件事情就是『工程可行性』。

做数据处理相关的系统时，最脏最累的活儿就是特征工程：一来是要到处求爷爷告奶奶，让其他系统提供获取数据的途径；二来是拿到数据后，还得清洗并计算出非常多的特征变量。做数据或算法工程的团队往往有一个幻觉：觉得特征变量的数量是会收敛的，到了某个时间点后，特征变量将不再新增或只需少量新增。但被现实打脸的恰恰就是这个问题，特征变量就像有机物一样会快速地繁殖，失败的团队没解决好的问题就是特征变量数量爆炸问题。

以计算信用卡账单的特征变量为例，需要分别计算近1、3、6、9、12个月的信用卡交易次数、交易总金额、平均交易金额，即5*3=15个特征变量。记得我离开时线上总共有20多款金融产品，每款产品至少3套以上模型（授信模型、风险模型、欺诈模型等），每套模型的每个版本都至少有成百上千个特征变量，其中有大量前面描述的那种排列组合式的相似变量。

面对这样庞大的特征变量池，其他团队都是清一色通过堆人来解决，即使团队人数长期保持在百人以上的规模，但仍然举步维艰。到最后他们开始转移工作量，让提需求的同学自己用SQL开发特征变量，把工作量从数据团队转移到上游团队，但实际上没有解决本质问题。

我们团队的解法不太一样，我们开发的风控系统虽然经历过Clojure、Java、Groovy等多次重写，但都会通过『宏』、『Javassist』等神奇的技术实现用代码生成代码：通过样板代码自动排列组合出大量的特征变量。

这项技术让特征变量的开发同学工作效率有了上百倍的提升，极大地缩短了变量开发时间，降低了后期维护成本。最重要的是，当特征变量需求膨胀，让原本不可能按时完成的变量开发任务变得可能，在工程上变得可行！

回到文章开头的单元测试问题上，写单元测试何尝不是一件工程不可行的问题？没实现一个新的函数，都得从正常、异常、边界等多个角度来测试这个函数，也是会出现组合爆炸，并且当原始函数修改，这一系列单元测试用例都会失效，因此维护成本非常高！如果这个问题不解决，光靠爱发电是无法让单元测试真正落地下去的！

好了，这篇文章的内容营销圈就和大家分享到这里，如果大家对网络推广引流和网络创业项目感兴趣，可以添加微信：Sum8338 备注：营销圈引流学习，我拉你进直播课程学习群，每周135晚上都是有实战的推广引流技术和网络创业项目课程分享，当然是免费学！

什么是风控系统，风控系统架构及建设详解？

相关推荐