“风控算法工程师”是一个很火的岗位，但也是一个水深火热的岗位。
笔者最近在朋友圈写了一个段子，请大家参考。
算法现在真是个苦逼工种。
早上先跟业务沟通需求，情商不够就等着被坑；
中午开始学习业务知识，不了解业务背景做出来的model就等着挨骂；
下午发现数据有问题，开始各种撕逼查数；
临下班的时候终于可以撸一点代码，发现Job怎么都跑不过去，哪个**又在占集群资源了；
下班回到家已是深夜，还得赶紧充电各种算法，不会点AI你都不好意思开开口。
周末，不提也罢。
虽是一个吐槽段子，但也是对风控算法工程师的一个工作总结。虽然都是槽点，但其中蕴含了对个人能力的要求。如果你都具备了，那我相信你绝对会是一名非常优秀的算法工程师。
当然，今天我们讨论的是如何成为一名合格的算法工程师，既然讲“合格”，我们还是重在职业技能。
“风控算法工程师”这个职位按字面意思可以拆成3个词：风控、算法、工程师，对应的能力就是业务知识、算法理论、编程能力。
如果经过一定时间的学习和培养你在这三个方面还有特别明显的短板，那很难称之为“合格”。
业务知识
熟悉业务知识是基本功。
了解业务才能够建立实际可用的模型，目前还不存在解决所有问题的万能算法，还是回到现实，从业务学习开始。
互联网金融领域有着非常丰富的业务场景，同时它和传统银行业务场景差别非常大。用户没有面签不直接见面，依赖的数据是弱数据、大数据，是数据和技术驱动的业务场景，但这并不代表你不需要去理解业务的内涵。
每一个现实场景就是一个应用题，作为算法人员需要理解题干，从场景中抽象出需要解决的问题，将它翻译成算法问题，然后再使用合适的算法去解决它。
很多时候对业务问题的理解和抽象，相当于在设定模型开发的大纲。比如在白条场景中，我们想要预测授信用户的信用风险，我们首先就需要考虑以下问题：
我们要观察多久的订单？
逾期多少天才算坏用户？
逾期定义中是否需要考虑金额限制？
好用户怎么定义？
需不需要考虑样本不均衡的问题？
为了保证模型的稳定性如何进行窗口验证比较科学？
针对业务的一些变动，比如订单制和账单制的调整，我们如何去修正模型的目标变量？
总之基本的信贷概念和业务模式是必须去了解的，有助于你设计开发大纲。除了大纲，风控模型的开发也需要知道业务细节。这在Y变量定义，X变量加工，模型评估都会涉及。
以Y变量定义为例，一般金融行业会把样本分为四部分：G（好用户）；B（坏用户）；I（不确定用户）；E（剔除用户）。
实操中对这四个群体通常会有不同定义的微调。有的时候是从算法角度考虑，但更多时候是从业务需求角度考虑。预测用户未来的白条消费金额，止付用户就会被划入E类用户；预测欺诈用户，因为样本很少，信用风险用户也被划入了B类坏用户。X变量除了根据业务知识挑选数据源外，更多时候业务知识指导特征构造。
这里我插一句，不要轻视特征工程，特征工程仍然是非常重要的内功，不是你搞一个深度学习框架就可以解决一切。
金融行业的业务复杂通常和时间挂钩，必须掌握业务概念的细节。对于白条业务，就有下单，到账，应还款，实际还款，最低还款，逾期，退款等一系列细节概念，它们都是在一个时间轴上的，特征加工很讲究这些细节。
只有清楚这些概念，而且知道这些行为如何产生和被记录，才能够构造相关的有效特征。好的特征不但可以提高模型效果，也便于从业务上把握模型的跨时间有效性。
业务场景很多时候还决定了你模型效果评估的方式，因为业务很灵活，可以做到有取有舍。有些场景需要模型是为了在误杀尽可能少的情况下抓住更多的坏人；有些场景需要模型需要有更好的排序能力但并不注重绝对值预测；有些场景需要模型需要有很准确的数值预测。
了解场景，挑选合适的评估方式，才能够构造出合适的模型，当然争辩是免不了的。
算法理论
首先，算法很多，没有人能够面面俱到，重在基本功。
对于转行的同学，推荐两本入门的基础读物：周志华的“西瓜书”和李航的“蓝皮书”。
作为算法工程师，对算法本身在公式的层面并不一定像考试那样需要死记硬背。比如工作中不会有人问你LBFGS算法对于海森矩阵是怎么估计的的（即便在面试中背出来都未必是加分项）。但是，LR的基本公式，SVM的基本原理还是需要去熟练掌握。
对各个算法的优缺点、适用范围以及可能失效的场景需要了熟于胸，某种程度上算法掌握深度和灵活度跟场景以及场景下数据很有关系。
企业工作时风控算法工程师的典型工作是在面对场景需求进行建模，理论深度是有一定必要的。因为实际工作没有时间让你研究理论，但是需要你掌握理论。
算法工程师搭建算法模型的时候，往往没有充分的时间去扫参调优，于是这会导致与在学校的时候建模发paper是完全不同的工作模式。
需要考虑的可能更应该是算法的鲁棒性，即算法模型在数据和计算环境一定幅度的波动下，仍然能够保持稳定的工作。
不然的话，支持线上工作的算法模型一旦崩溃，轻则是大半夜不定的报警短信把你招到公司改bug，重则是造成重大财产损失——想想某业务本来大体只会授信一半的用户，结果被奔溃的模型完全放行了……这将会是什么画风？
因为没有太多的时间扫参数空间，所以最好对于各个常用模型的“性能”以及主要工作的参数空间有一个清晰的概念。
这意味着，你不能像以前在学校一样，对于每个模型都用效果最佳的参数，而需要“常见”的参数，去实现基本的业务功能，日后业务方有需要再去优化。工程上，过度的算法“洁癖”和“强迫症”都会耽误很多事情。
特征工程还得再强调一遍，虽然它看上去不像理论那么高大上，但其实很多时候模型效果还就得靠那么一点特征工程作为作料。在算法里面我们更强调特征工程的一些处理手法和技巧，比如点击流数据的处理方法，怎么设置窗口，一些缺值数据的处理技巧，噪声数据的去除等，都能提升模型的效果。
而且这其实有其近乎“艺术”的一面，正所谓“戏法人人会变，各有其奥妙不同”。
评价指标要选好，评价指标的坑很多，并不是说当你建好了模型之后，算一算precision、AUC、KS、F-measure就好了。
要对这些指标的原理，特别是局限性了然于心。
再强调一遍，特别是他们的局限性！甚至有时候你可能需要自己组合设计一些指标，来更好适应你的问题。
关于深度学习框架，目前各大厂小厂都在积极尝试，但是尚且没有全面推开在金融领域，我们在某些环节使用这些技术，同时也在向业务方普及这些技术。深度学习作为趋势，日后广泛应用是一定的，所以我们坚定看好它。
传统概率论和数理统计方面的知识也不能丢。即便我们不去参与贝叶斯派和频率派的撕逼，古典概型在考虑问题的时候也很有用。另外还有诸如随机变量及其分布、随机过程、大数定理、中心极限定理等等。毕竟，金融产品的普遍是建立在人们对“未来”的预期上的，而这一过程则需要基于概统来理解。
编程技能
首先，总的来说，算法工程师需要的是处理大数据和实施高性能计算。这在工程层面有多种实现方案，下面简单罗列一下常见的部署场景，大家可以各自去攀相应的科技树：
• 在数据层面，sql必不可少。
可以说SQL是数据的魔法石，让数据流动，转化，融合，迸发出巨大的威力。对于sql的熟练使用，以及一些小技巧的应用，能够给下一步的特征工程省很多事。在这个过程中，数据倾斜是要尤其关注的，拉数据或者计算过程中进程一直被卡在99%是一件很尴尬的事儿。
• 目前主流的编程语言越来越集中于python和R。
有新闻上说，有的中学已经在开始普及python了。所以至少最好能有所了解。这包括一些常用的库，如pandas、sklearn等。
当然，其他语言也可以有，C++在我们非常追求性能时会去考虑，JAVA也会在我们提供服务的时候使用。
• 关于高性能的并行计算，Spark是一中常见的构架，它包含一个数据挖掘的库MLlib。
• GPU（集群）是实现更高性能并行计算的另一个流行的方案，同时考虑到一些CNN、RNN模型的使用，所以学习注入TensorFlow、Caffe等等算法框架是很有必要的。
当然对于风控来说这是比较高阶的应用。
• 在建模过程中，对数据的简单统计分析进行可视化是非常必要的。
数据直观的展示出来之后，有些问题/方案就一目了然了。在这方面，python的可视化工具、R、Matlab等各有各的优势，大家可以按习惯取用。
• 最后，作为基础，写shell脚本的基础是必须的，要有一定的linux知识。
其次，特别是大型金融科技公司对编码要求已经和互联开发没有什么本质区别，因此要求在编程的过程中，工程考虑是一定要有的思维习惯。
这里的“工程考虑”并不仅仅是指算法的性能方面，还有考虑你自身的数据结构、表关系依赖关系、计算环境、服务器性能、可用资源等等，很多问题需要与研发或者平台的同学仔细沟通才能够提供一个真正的风控算法服务。
因为风控的敏感性，网上其实很少有相关的资料。尤其是现在金融科技公司中的新技术和传统银行技术差别较大，使得这个行业带有一定的神秘性。
其实，风控算法工程师和推荐系统算法工程师、搜索算法工程师等等没有太本质的区别，个人认为仍然属于互联网+下的算法工作，但是同金融科技这个新生业务产生了交集，对人才有了更复合的要求：同传统风控人员相比，它更强调了算法能力和工程能力，同普通算法人员相比，它更强调了金融业务理解能力。
从招聘的情况看，市场上目前具备这种综合素质的人才很少，是一个很有发展前景的职业。
作者：京东金融-彭南博
声明：本文来自京东数科安全，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
