为什么很少做模型？在大家的想象中，算法工程师所做的就是今天看论文，明天实现论文，后天上线使用。那么公司的收入就会增加，我们的工资和级别也会跟着增加。上升。但实际上，大部分岗位的工程师并不是每天都这样。国外一位有名的大佬（名字忘了）曾经说过，算法工程师70%的时间花在数据上，只有不到20%的时间花在模型和调参上。这句话你可能或多或少听过，但可能不是很理解。为什么会这样？为什么不花更多的时间制作模型呢？原因也很简单，不是不想，而是不能。不能的原因有很多，我只举几个最常见的。限框模型不能随便移动的原因有很多。一般来说，最常见的是帧限制。这种情况在大公司和小公司都存在。比如我在大公司的时候，公司的框架已经很成熟了，很少会写代码去实现某个模型，更多的是对接可视化界面。行和设置操作。问题来了。在这个场景中，可视化界面中的可选模型是固定的，都是由基础团队开发的。他们开发了那么多模型，我们只能用那么多模型，除非我们脱离整个过程，但显然这是不可能的。所以当时很长一段时间，我们只能在有限的车型中选择。直到后来公司开发了一个新的框架工具，可以让我们自定义神经网络的代码来实现深度模型。霰弹枪的变化这才迎来全面升级。小公司虽然不像大公司那样有成熟的、不易改变的框架，但一般都有自己的一套流程。比如公司前辈留下的链接，就是基于开源的xgboost开发的。如果你想用TensorFlow来训练神经网络模型而不是原来的xgboost，一般来说，这肯定是有效的，肯定会迎来一个提升。但问题是你可能需要重构整个训练模型和在线调用模型的环节。很多算法工程师不太会开发，也不愿意做工程重构。再加上工作量不小，容易出现大家都知道怎么做比较好，但是由于投入大，大家都不愿意做，一直拖延的情况。效果难以保证。第二个原因是有些模型和做法纸上谈兵，效果其实很难保证。如果你读过论文，你会发现论文的结论往往有很多前提。比如某个数据或场景，前期强大的召回和过滤系统，或者完善的特征准备等等，这些都不会写在论文里，只会写实践和结果。所以这就导致了很多在论文中大肆炒作写出来的方法在实际应用中可能并不能很好地发挥作用。这不是纸上谈兵，而是你们不具备同样的条件。比如阿里的数据嵌入非常准确，准确到用户从打开应用到关闭应用的每一个动作和行为，每个产品或模块在用户站点上展示了多长时间，甚至用户打开页。速度被完全和完整地记录下来。这种数据，一般规模的小公司根本做不来。如果你做不到这个数据，你就没有论文中的精确特征。那么如何保证你用阿里的模型达到同样的效果呢？我们都知道优先权问题。事情可以按照紧急和重要分为四类，不重要不紧急，紧急不重要，紧急重要，重要不紧急。很多人也知道，最重要的是做好那些重要而不紧急的事情。每个人都会说，但其实并不是每个人都会选择。当你面临KPI考核的压力时，一线工程师可能只关注紧急的事情。因为他们需要快速做出一些成就来完成他们的表现，所以完成他们表现的最好方法绝不是升级或更新模型，而是找到一些特征来做，或者使用一些猫腻的方法，看看他们是否可以增强效果。花时间更新模型是很费力的，而且不一定有效。但是做特征的成本是很小的。一个不行，可以再做一个，迭代很快。其实这不完全是工程师的短视，也是整个职场氛围影响的结果。每个人都看重性能和性能，以至于每个人都陷入了局部最优解，反而离整体最优解越来越远。为了避免这种情况，需要有远见和统筹的架构师或领导者，能够承受模型升级的风险压力。对未来可能出现的情况和要做的事情有足够详细的计划，有足够的经验去应对各种可能发生的事情。但大家也都知道，具备这种能力的领导在职场上是凤毛麟角。在大公司很少见，在小公司更难得。做什么样的数据说完模型的问题，再来说说数据。由于模型不能经常更改，工程师只能做更多的数据。那么工程师们在处理什么样的数据呢？毛呢布要花那么多时间？有训练数据的大公司都有完整的流程。我们设计好流程后，训练数据、测试数据、模型训练、部署就可以一站式流水线完成。但在中小型公司，这往往是不可能的。原始数据不能直接用于训练模型，需要复杂的处理过程。首先，需要采样。以CTR预估场景为例。一般来说，真实场景中的点击率不会超过10%。但是在模型训练中，正负样本的比例一般在1:3左右，所以这就需要我们对负样本进行采样。不能直接取样本，因为这些样本中可能有很多脏数据或者非法数据。我们需要在采样之前对这些有问题的数据进行过滤，从而保证我们的数据是干净的。采样后，我们需要搜索并完成特征和字段。因为数据往往是分开存储的，比如用户基本信息是一个表，用户行为数据是另一个表，产品信息是一个表，各种数据存储在各个地方。.有了样本之后，我们还需要找大量的数据来收集所有需要用到的字段。当我们收集完所有需要的数据后，我们就可以开始制作真实样本了，也就是使用我们搜索收集的原始数据来生成输入模型的样本特征。每个特征可能都有自己独特的生成逻辑，这也是一项浩大的工程。这一步还没有结束，还需要将数据转换成模型需要的格式。比如tfdata或者tensor，json之类的。经过这样一系列的步骤，大公司一般都有一套完整的自动化调度流程。工程师们不需要担心，他们只需要使用它。但是在中小型公司，可能只有一些手动的工具，需要数据就需要手动运行一些任务或者脚本。在运行过程中，可能会出现故障和各种问题。虽然不起眼，不值钱，但这些东西需要做大量的工作。新功能怎么样？在kaggle等比赛中，可能用pandas写两个函数，或者几行处理逻辑就可以完成。但实际上绝非如此简单。让我举一个最简单的例子。比如我们把年龄归一化，让它成为标准化年龄的一个特征。这个简单，我们用比较简单的归一化最大值和最小值的方法。公式就是：算法工程师为什么整天做数据，做的是什么数据？归一化后，这个特征值会被缩放到0-1的区间。但是这里用到了两个参数，一个是最大值，一个是最小值。这两个参数是怎么来的呢？大家可能觉得这不简单，我们遍历一下数据就知道了。但问题是你不会只使用一次这些数据。以后每次生成训练数据都需要生成这个特征。每次运行都是手动遍历数据找最大值和最小值吗？而且数据是在变化的，用户的最大和最小年龄可能每天都不一样。如果我们想运行几天的训练数据怎么办？设计一个新特性很简单，但是其中的一些参数会使事情变得复杂，我们往往需要设计复杂的机制来将新完成的特性添加到流程中。效果分析效果分析中也有很大一部分是数据处理。效果分析有两种类型。首先是做一些以前没有做过的指标和相关分析，或者应老板的要求，做一些业务指标分析，达到我们的目的。表现。比如CTR、CVR、收入等最基础的数据，还有一些老板临时想看的数据。比如分析某些特征的分布，比如看某个特定组的样本数量或者数据的情况等等，等等。二是我们的模型做好后的效果分析。如果模型的效果还不错，那就可以了。如果效果不好，问题就来了，我们怎么判断哪里出了问题？是不是模型本身性能不够？还是我们的功能不够或者功能有问题？还是我们的数据质量不够高？或者哪里有bug？算法不像工程学。工程中的大多数事情都是确定的。如果结果是错误的，那一定是由于逻辑上的错误。只要仔细测试，分析原因，总能解决的。对于难以复现且找不到原因的问题是非常少见的。但算法不同，大多数情况下没有绝对的对错，甚至没有绝对的理由。我们扮演的角色更像是侦探，根据一些线索猜测问题的原因，然后通过实验尝试解决问题。这个过程涉及大量的数据处理和分析。例如，如果你怀疑某些特征的分布有问题导致模型表现不佳，那么你就需要分析特征的分布。如果怀疑数据有BUG，那么就需要设计方案，筛选数据，仔细找出数据中的问题，验证自己的想法。如果你觉得训练数据量不够，那么就需要加大训练量，设计对比实验……总之，排查问题需要大量的数据分析，不仅仅是看代码，而是想一想就会得出结论。我感觉很多想做算法的人，在真正做算法之后，往往会感到幻灭。入职会有一种面试造航母、拧螺丝的强烈感觉。原因也很简单。面试的时候问了各种模型，各种先进的理念和方法，但是进入工作后，面对的是各种数据分析和数据准备。比如我大部分时间都在写SQL做数据，一度怀疑公司的岗位安排。但是当我明白这一切是如何运作的时候，我就明白了。实际工作场景不同于在线算法竞赛。在在线比赛中，我们可以使用各种技巧来提高成绩。还可以搞各种跨界混搭。比如今年腾讯算法大赛的冠军，就将BERT应用到了用户行为分析的场景中。但在实际场景中，由于系统和各方面的限制，这些想法难以实现，效果也难以保证。最终还是需要有基础的数据支撑才能落地。打个不准确的比方，各种算法模型就像是工具箱里的各种工具。我们只了解工具是没有用的。最重要的是了解工具将被使用的场景，这样才能根据需要选择最合适的工具。但遗憾的是，我们对数据和场景的理解是很难量化的，所以在面试的时候，我们只能问你工具的使用情况。从长远来看，很多人本末倒置，把核心竞争力搞错了，貌似是对的。采访中出现各种批评也就不足为奇了。
