来源：Charlotte数据挖掘

作者：Justin ho

链接：https://www.zhihu.com/question/31284094/answer

1.接到一个项目之后心潮澎湃,脑子里马上闪现出faster rcnn,resnet,mask rcnn等各种的算法。

2.结果发现图片都不知道存在哪.....于是反馈给产品经理,开了一通会议,确定图片数据库在某个位置,准备读表爬虫!

3.结果发现表的信息是乱七八糟的,一张表里面有图片链接,但没有这个图片的标签信息;另一张表里面有标签信息,但又没有图片链接。找了许久才发现两张表可以用图片id来结合,行吧,不就是查表的事情,写一堆代码把这些信息整理起来吧!

4.花了一天终于整理出图片链接的csv了,交给爬虫组爬了三天三夜,期间在YY到时图片下下来之后可以用什么算法。

5.拿到图片了,发现类别有了,但是bbox,关键点坐标信息都没有啊!咋整,上网找了个labelme，自己整个1000张用着先呗,然后花了两天整了少量图片出来,期间还要劝服同事帮忙。

6.剩下的图片交给标注员去标注。接着就是根据前两天YY到的算法,上github找找有没有现成的模型,然后git clone。修改了一点输入输出，用公共数据集顺利跑通!看来还是不错的嘛!

7.回头把自己的数据放进去试试,简直一塌糊涂,那是当然的。现在就得回去仔细研究论文,看看作者的各种实现细节,然后魔改模型finetune.再次测试,咦,有点效果喔~

8.这时候领导紧急开了个会议,说现在目标有点改变,我们往另一个方向走吧。

9.开始研究这个领域的所有经典论文,每篇论文都看上好几次,看到最后几乎把整个领域的主要脉络摸清了,然后磨刀霍霍向模型!

10.国际惯例先找github,但是很不幸我想要的算法并没有开源实现,那我来做第一个吧!

11.马上照着菜单(论文),啪啪啪构建proposal模型,各种自定义层结构,特殊的菜单中提到的weight decay,learning rate decrease,几乎把论文所有角落的细节都翻遍了,目前为止进度还行,但是慢看!论文里提到的一个层,作者只是一笔带过了,没详细说明这是怎么实现的!

12.都到这地步了还能放弃?开玩笑,立刻照着上related work那一章提到的所有论文寻找线索,于是各种谷歌github知乎stackoverflow，终于弄懂了这个层的数学原理!

13.好不容易把模型复现出来了,好家伙,开始用标注员准备好的数据来训练。14.慢着,这loss曲线不对劲啊?为啥会是直线,而且一轮收敛?不不不,肯定哪里出了错误,我得把代码重头检查一遍!

15. 费好大劲终于找出bug，代码也顺利跑通了，然后进入各种调参无限死循环。

16.老板:那个，我们决定还是换个方向吧，需求变了。

17.算法工程师时常自嘲成调包师，而且外行人听多了就还真以为调包很容易，深度学习和其它机器学习算法不同的是，一篇新论文算法的出现都要写很长的代码去复现。而且前提是你深刻了解作者的思想，蛋疼的是，有时候作者不会把所有细节都告诉你！！！容易吗我！

作者：天雨粟链接：https://www.zhihu.com/question/31284094/answer/331809395

我这些回答仅是从我的几份实习中总结出来的，只是写自己的看法与感受，当然有些同学跟我所做的内容有些差别，所以答案仅供参考啦！

在算法模型领域大概实习了1年多的时间了，突然看到这个问题，也顺便总结一下自己过去实习的经历。

看到各位知乎大佬的答案，我仅从实习的这个角度来浅显地谈一谈我在工业界做算法和日常做小project之间的不同感受。

在我目前的理解上，算法工程师分为两类。其中一类是偏研究型的算法工程师，例如复现paper，改善模型，发paper，出专利，这一类人才大都是科研大佬。第二类则是更加贴近业务的算法工程师，不如称为「算法应用工程师」。这一类同学主要是与业务同学进行搭档，通过现有的一些成熟模型来帮助业务同学解决问题。

我所从事的主要是后者，即算法应用。

在我的工作中，大多数时间都花在定义问题、数据预处理（包含ETL、特征工程、特征筛选等）、模型评估上，而模型的训练、调参等所花费的仅仅是少数时间。这也印证了吴叔叔（Andrew Ng）所说的“实用化的机器学习基本就是在做特征工程”。

下面分别从这三个方面来具体说下：

首先是定义问题。定义问题包括很多方面，例如业务需求定义、模型产出形式、变量的定义与衍生、目标y的定义等等。在大多数时候，业务方同学对自己的需求并不是那么明晰，很可能只是说“我需要一个简单的用户画像or某个客群识别or某个值的预测”，但是具体的细节例如这个模型未来的使用场景、变量的要求等等都是不清楚的，需要在不断的讨论与数据验证过程中进行定义与修改。甚至更多的时候要考虑到模型在未来业务变化的情况下是否能保持稳定的产出，尽量减小模型的衰减。

其次是数据的预处理。这一步是非常消耗时间的，大多数情况下，数据并不是现成的放在面前，就等你跑个模型。我相信大多数学生党所接触到的机器学习都是拿到几张二维表，直接做个表连，然后调几个包，处理下特征，跑个模型。但真正在工业界（至少在我接触到的业务中），数据都是原始的、底层的，甚至是非结构化的，更甚至好不容易找到个相关数据源，但发现不维护了，数据质量得不到保证，就只能更换数据源。这类原始数据中充斥着各种脏数据，而我们的大多数工作就是在处理这些脏数据，让它们变成可以让我们的模型所使用的数据。其次很重要的就是特征的处理，俗话说“Garbage in, Garbage out”不是没有道理的。以前我做Kaggle的时候，总是想着，特征不用那么精细化处理，我随便调几个包，填个空值、做个特征排序就OK了。但其实在真正的业务中，是要对某一个特征的分布、数据的源头、加工逻辑有着严格的把控，一旦某个特征加工逻辑有问题就会导致结果非常差。由于我是做金融领域模型的，所以某些模型需要解释性，因此变量的筛选和特征工程就要做得非常精细化，否则即使模型效果再好，但没办法解释就无法上线（这也是为啥我们很少用DNN去做某些模型）。

第三点就是模型评估。在学校自己做project的时候，模型的评估无非就是MSE，MAE，混淆矩阵，precision，recall，F1 score等等，在validation上看看这些值，画几个图，再调调参数。但在工业界里，模型的评估是非常重要的一个环节。模型评估包含模型本身的性能、模型稳定性、变量的稳定性、可维护性等等方面，还要结合具体的业务指标进行验证。因为业务是经常发生变化的，所以要对模型的衰减有一个预估，保证在业务可接受的时间内稳定运行。

最后简单说几个和在学校做模型不同的地方：

1.工业界基本遵循“奥坎姆剃刀”原则，在不牺牲很大性能的情况下，更加愿意选择简单、稳定性强、可解释性强、可维护性好的算法与模型。其本身并不是像kaggle那样要追求那么高精准的结果，一个算法和模型的完成要综合考虑到方方面面。

2.特征工程十分重要！否则就是上面提到的“Garbage in, Garbage out”

3.业务规则>模型。做业务支持算法的同学可能对此有体会，有时候几个资深业务专家的规则的结果甚至要强于模型。现在我做模型也基本是规则+模型一起做。

4.数据分析很重要！这里包括对数据的理解、对统计学的认知等，一个好的算法工程师也一定是一个好的数据分析师。

5.统计学很重要！！！

6.对算法的原理、应用场景要非常熟悉，这也是一个算法工程师的基本功。

作者：flyingfish链接：https://www.zhihu.com/question/31284094/answer/3101401232017年，我做了一年机器学习，数据挖掘相关的工作。 工作体验和其他答主完全不一样，所以准备写一下部分难忘的经历。

可能在大公司做机器学习相关的工作容易很多吧，比如变量是现成的，甚至 标签也是现成的。 于是工作的日常就是抽取一些变量和标签进行建模，调整参数之类。每天不停的跑数据。

但是我们的工作完全不一样。

我们的目标在业务上是反欺诈，现有的特征不能使用，因为已经有建模的团队了。 为了提升反欺诈的效果，我们只能从数据角度出发，挖掘出更多更好的变量，不用现有的任何特征，目标却是比现有的模型效果更好。

了解了状况之后，于是开始做关系网络，因为这块是公司空缺的领域，而且整个行业来看的话，做的好的公司也没有几家。

说干就干，工作从研究数据类型，关系， 数据清洗开始。 遇到的第一个问题是 sql, 无法构造成图结构。 于是自己动手 写代码用 java 读写 hdfs 数据，在内存里面构图，计算特征。尽管搞到一台256G内存的机器，依然遇到 内存不够用的情况。 查的原因是 需要加载到内存的边太多，几亿条。 接下来，优化数据结构的内存开销，能用short 就不用integer, 能用long 就不用 string.  甚至自己做数据做分片。 计算特征的时候，仅仅加载该分片需要的所有数据到内存里面来。 终于第一个里程碑做到了， 特征有了， 标签有了。 从开始工作到第一个模型的建立，中间花了1.5个月。还好模型效果显著，得到了老大们的支持。

既然模型效果好，仅仅用了 xgboost 就效果显著了。那么就努力上线啊。这个时候才知道上线才是最大的困难。因为这个模型上线需要优先做到实时关系网络的构建。

关系网络数据存哪里？试过 Neo4j , OriginDB, Titan 等图数据库。 花了3个多星期用来写各种demo, 测试逻辑准确性，测试性能等等。 得到的结论是没有一个开源的图数据能够满足需求。

捉急啊，有价值的模型居然因为技术实现问题难以上线。总不能放弃吧。 最终决定只把边这一种数据保存到 HBASE 表里面。 让HBASE 帮我解决存储问题。 采用Flink 实时流框架，写了一堆代码暴力的往 HBASE里面写入 增量的边。 历时2个多月，完成 FLINK + kafka 做到实时关系网络的构建， 延时不到1秒。 并发的进程数量高达30多个。

后续还需要做 图的完整性测试，时效性测试，测试ok 后。 还需要自己写基于关系网络的特征工程，模型预测，预测结果还需要上线观察一个月。 真正意义上的上线都已经10月份了。从2月底开始尝试去做，到做成上线一共经历了7个月。

整个过程下来，建模的工作不超过2周。流计算，实时关系网络构建，特征工程，特征准确性测试等技术工程实现上花的时间占用99%。一条龙全部自己做。而业务使用上，只是到 hbase 的一张表里面根据 rowkey 拿模型预测分就好了。却无法感知上线路程之艰难。

模型的实际效果好，为之辛苦值得。

欢迎扫码关注：