为什么很少做模型
在大家想象当中，可能算法工程师做的事情是今天看paper，明天把paper实现了，后天就上线使用，然后公司的收入刷刷涨，我们的工资、级别也跟着涨。但实际上，大多数岗位下的工程师日常并不是这样。国外有一个著名的大佬（我忘记名字了）曾经说过，算法工程师有70%的时间是投入在数据上的，花在模型和调参上的只有不到20%。
这句话大家可能或多或少都听过，但是想必都不是很理解，为什么会这样呢？为什么不能多花点时间做模型呢？原因也很简单，并非不想，而是不能。
不能的原因也很有很多，我随便举几个最常见的。
框架限制
模型不能随便动的原因有很多，一般来说最常见的是框架的限制。这种情况在大公司和小公司里都有，比如之前我在某大公司的时候，公司的框架非常成熟，以至于很少写代码去实现某一个模型，而更多的是可视化界面的连线以及设置操作。问题来了，在这个场景当中，可视化界面当中可选的模型是固定的，都是基础团队开发好的，他们开发好了这么多模型，我们就只能使用这么多模型，除非我们脱离这整个流程，但显然这是不可能的。
所以当时在很长的一段时间里，我们只能在有限的模型当中做选择。直到后来，公司开发出了新的框架工具，可以让我们自己定制神经网络的代码实现深度模型，这才鸟枪换炮迎来了全面升级。
小公司虽然不像大公司这样有一套成熟且不易改动的框架，但是一般也会有自己的一套流程。比如公司前人留下来链路是基于开源xgboost开发的，你想要使用TensorFlow训练神经网络模型代替原有的xgboost，一般来说这是肯定有效果的，也一定会迎来提升。但问题是，你可能需要把训练模型、线上调用模型的整个链路都重构。很多算法工程师的开发能力不太行，而且也不太愿意做工程重构的事情，再加上这块工作量也不小，所以很容易出现的情况就是，大家都明知道怎么做比较好，但是由于投入比较多，大家也都不愿意做，一直delay。
效果难保证
第二个原因是paper上的一些模型和做法，效果其实是很难保证的。如果你读过paper会发现paper的结论往往都有很多前提。比如某某特定的数据或者是场景，前期强大的recall以及过滤系统，或者是完善的特征准备等等。paper里不会把这些都写出来，它只会写上做法以及结果。所以这就导致了，很多paper里写得天花乱坠的方法，实际应用起来效果可能并不好。
这也不是paper吹牛，而是你没有同样的条件。举个例子，阿里的数据埋点非常精准，精准到用户从打开app到关闭app的每一个动作和行为都有记录，每一个商品或者是模块在用户处展示了多少时间，甚至是用户翻页的速度都有全面完整的记录。就这种数据，一般规模的小公司根本做不了。你做不了这个数据，你就没有paper里那些精准的特征。那你如何保证你使用阿里的模型也有同样的效果呢？
优先级问题
我们都知道，事情根据紧急以及重要可以分成四类，不重要不紧急、紧急不重要、紧急且重要、重要不紧急。很多人也都知道，最重要的事情是把那些重要且不紧急的事情做好。说起来大家都会说，但是实际上未必人人都会这么选。
当你面临KPI考核压力的时候，一线的工程师可能就只能盯着紧急的事情做。因为他们需要赶紧做出一点成绩来完成自己的业绩，完成自己业绩的最好方法绝不是去升级或者是更新模型，而是找一些特征做一做，或者是使用一些取巧的方法看看能否提升效果。花时间去更新模型，付出的劳动很大，也不一定有效果。但是做特征代价很小，做了一个没效果，可以再做一个，迭代也快。
这其实并不完全是工程师鼠目寸光，也是整个职场氛围的影响的结果。大家都看重业绩和绩效，以至于大家都陷入了局部最优解，但是却离整体最优解越来越远。
要想避免这种情况，需要有高瞻远瞩、统筹规划的架构师或者是leader，能够抗住升级模型的风险压力。对可能出现的情况以及将来要做的事情有充足、详细的规划，并且有足够的经验应对各种可能出现的事情。但是大家也都知道，拥有这种能力的leader在职场里凤毛麟角。大公司里都不多见，小公司里就更加难得了。
做哪些数据
说完了模型的问题，我们来聊聊数据，既然不能频繁地变更模型，工程师们就只能更多地来做数据了，那么工程师们到底又在做哪些数据，需要花费这么多时间呢？
训练数据
大公司里有完整的流程，我们把流程设计好了之后，训练数据、测试数据、模型训练以及部署可以一条龙流水线作业。但是在中小型公司里，这往往是做不到的。
原始数据是不能直接用来训练模型的，这中间需要复杂的处理流程。首先，需要做采样。就拿CTR预估的场景来举例，一般情况下真实场景下的点击率不会超过10%。但是模型训练一般正负样本的比例是1：3左右，那么这就需要我们对负样本进行采样。
采样你还不能直接采，因为可能这些样本当中还存在很多脏数据或者是非法的数据。我们需要先把这些有问题的数据过滤了之后，再进行采样，这样才能保证我们的数据是干净的。采样了之后，我们需要进行特征和字段的查找补全。因为数据往往是分开存储的，比如用户的基础信息是一张表，用户的行为数据又是一张表，商品的信息是一张表，各种各样的数据存放在各种各样的地方。我们有了样本之后，还需要去查找很多的数据，才能把所有需要用到的字段搜集齐。
当我们搜集了所有需要的数据之后，我们才能开始真正样本的制作，也就是使用这些我们查找以及搜集到的原始数据生成输入模型的样本特征。每一个特征可能都有自己独特的生成逻辑，这也是一个庞大的工程。这一步做完还没结束，还会需要把数据转化成模型需要的格式。比如tfdata或者是tensor、json之类的。
这么一系列步骤，大公司一般都有一整套完整的自动调度流程， 工程师们不需要操心，只需要拿来用就好了。但是在中小型公司，可能就只有一些手动工具了，需要数据都需要手工去跑一些任务或者是脚本。跑的过程当中还有可能会失败以及遇到各种问题，虽然说起来平平无奇，也没什么价值，但这些事情都是需要工作量的。
新的特征
特征怎么做？在kaggle之类比赛当中，可能就是使用pandas写两个函数，或者是几行处理的逻辑就搞定了。但实际上绝不是这么简单。
我举一个最简单的例子好了，比如我们将年龄进行归一化，做成一个标准化年龄的特征。这个简单吧，我们就用比较简单的最大最小值归一化方法好了，公式是：
算法工程师为什么成天做数据，都做哪些数据？
归一化之后，这个特征值会被缩放到0-1的区间里。但是这里面用到了两个参数，一个是最大值，一个是最小值。这两个参数怎么来？你可能会觉得这还不简单，我们遍历下数据不就知道了。但问题是这个数据你并不是只用一次，以后每次生成训练数据都需要生成这个特征，难道每次跑的时候都手动遍历一下数据找下最大最小值吗？而且数据是在变化的，每一天用户年龄的最大和最小值可能都不一样，假如说我们要跑好几天的训练数据怎么办？
设计一个新的特征是简单的，但是里面的一些参数会让事情变得复杂，我们往往需要设计复杂的机制来将新完成的特征加入流程。
效果分析
还有一块数据处理的大头在效果分析，效果分析有两种，第一种是做一些之前没有的指标以及相关的分析，或者是应老板的要求做一些业务指标的分析，达成我们的绩效。
比如像是最基础的CTR、CVR、收入等数据，也有像是老板临时起意想要看的某些数据。比如分析一下某些特征的分布，比如看一下某个特定族群中样本的数量或者是数据的情况，等等等等，不一而足。
第二种是我们模型做出来之后的效果分析，如果说模型的效果还，那还好。如果效果不好，问题就来了，我们怎么样确定是哪里出了问题？是因为模型本身的性能不足呢？还是我们的特征不够或者是特征当中存在问题呢？还是我们的数据质量不高呢？还是说什么地方存在bug呢？
算法不像是工程，工程当中绝大多数事情是确定的，结果不对一定是因为逻辑有bug，那么只要仔细测试，分析原因，总能解决。那种难以复现，找不到原因的问题非常罕见。但是算法不一样，大多数情况下并没有绝对的错误和正确，甚至没有绝对的原因。我们扮演的角色更多地像是侦探，根据一些蛛丝马迹推测导致问题的原因，然后用实验尝试着解决，在这个过程当中就涉及到大量的数据处理和分析的工作。
比如，如果你怀疑是某些特征分布有问题导致了模型效果不好，那么你需要分析特征的分布。如果你怀疑是数据存在bug，那么你需要设计方案，筛选数据，仔细甄别数据当中的问题，验证自己的想法。如果你觉得是训练数据量不够，那么你需要增大训练量，设计对比实验……总之，想要排查问题都需要大量的数据分析，绝不仅仅是看看代码，想一想就能有结论的。
感想
很多想要从事算法的人真正做了算法之后，往往会有幻灭感。会有一种强烈的面试造航母，入职拧螺丝的感觉。原因也很简单，我们面试的时候问的是各种各样的模型，各种先进的理念和方法，但是入职之后面临的工作却是各种各样的数据分析以及数据准备。比如我当年大部分时间都在写SQL做数据，我一度怀疑公司的职位安排。
但当我理解了这一切的运作机制之后，我就理解了。实际的工作场景和线上算法比赛不同，线上比赛我们可以使用各种各样的trick来提升成绩。还可以搞各种跨界混搭，比如今年的腾讯算法大赛的冠军的做法就是把BERT应用在了用户行为分析的场景下。但是在实际的场景当中，由于系统以及各方面的制约，这些想法都是很难实现的而且效果也难保证，最终还是要落实到基本的数据支撑上来。
打个不确切的比方，各种各样的算法模型就好像是工具箱里的各式工具，我们仅仅了解工具是没用的。最重要的是要理解使用工具的场景，从而可以根据需要选择最合适的工具。但很遗憾的是，我们对数据以及场景的理解是很难量化的，所以面试的时候只能退而求其次问你工具的使用了，长此以往很多人本末倒置，搞错了核心竞争力，出现对面试的种种非议也就不奇怪了。
