算法工程师分析问题和解决问题的能力，以及落地能力

reference：
摘自机智的叉烧的知乎回答和微信推文
https://www.zhihu.com/people/ceng-guan-rong-72/answers
https://mp.weixin.qq.com/s/xdJcQZgHUeGjZLzxUAp36g

1. NLP二分类任务，为什么各种模型最后的训练结果(F1,ACC)都相差甚微（使用Glove词向量）？

1）分析问题：遇到问题首先，要知道症在哪，要知道的核心就在于你要足够理解病症问题，对于算法问题，大到看数据整体分布，看数据整体特点，小到看bad case情况，尝试去归因（这个是真的难，每个人看问题的角度不同）。
问自己几个问题：

1. 什么场景，这个场景有什么特点。
2. 训练集测试集数据量多少，正负样本比例多少。
3. 训练集测试集本身的质量怎么样，准确率咋样。
4. 分类句子长度分布怎么样，平均最长最短中位数。
5. 目标准招是多少，现在多少，预期多少合理？
6. 各个模型的bad case是什么样的，有什么特点，特点的占比怎样。
7. 甚微是多甚微，那对错，各个模型有没有什么优势和劣势？

2）从知识库中挑选方法/模型：平时，要注意积累自己手里的方法，同时也要足够理解这些方法，因地制宜的一个前提是得有足够的方法供你选，第二个前提是知道方法的优缺点，才知道怎么选。说白了，就是两个词，一个是积累，另一个是理解。

然后就是找到合适的方法解决这个问题了。举个例子，短句10来字比较多，textcnn比较合理，长文本问题那就试试lstm之类的rnn系列方法，如果关键词类，知识类依赖多那bert之类的是可以尝试的，如果是类似黄反识别，文化作品这种对文本词汇比较敏感的，建议用文本匹配的方式去做。相比一把梭，不去花时间多分析分析问题，然后解决问题，而且做过的问题足够多的应该知道，有很多问题是模型解决不了的，只能逼近。

2. 传统方法优于深度学习的场景

深度学习更适合于学习可泛化的内容。深度学习的几个核心缺点：

• 需要大量样本才能解决问题。
• 训练需要时间和资源（内存，计算资源）。
• 推理阶段，深度学习远远比不上规则的快。

什么情况下规则会比深度学习更适合呢？

1）准确率要求超高的问题
规则保准确模型保召回。

2）名词性质明显的问题
词典干预是非常可靠，稳定，敏捷的方法。
其一，oov是一个历史难题，无论是人还是模型，一个没见过的词都很难推断他的意思，同样是天气之子，没听说过的，那他很可能就是不认识。
其二，这些名词是有时间性质的，例如新冠，耗子尾汁，10年前大家肯定没听说过，数据里也很难有，模型也学不到，现在有了，那我们是重训模型吗，肯定不合理，学是学不完的，会持续有新词出来。
其三，名词是有严格文本意义的，少年的你是电影，年轻的你就不是那一部了，甚至都不是了，深度学习能轻易对词汇进行泛化，但这种名词不合适。

3）人工特征强的问题
用户特征强的问题，只要构造好特征，模型将不会是效果的瓶颈。比如推荐系统项目初期，数据不足，大部分用户还在探索阶段，这时候深度学习并不适用。再说一个关键点，现在的推荐模型很多时候会考虑各种因素，公平性，时效性，长期兴趣啥的，这对于还在初期的推荐系统统统不合适，因为现在的系统就不存在这个问题，片面的看方法厉害而忽略问题本身，一定会栽跟头的，到时候可别说是方法不靠谱了。这时候，用简单的机器学习模型做一个泛化，可能更好，lr，xgboost，足矣，关注点放在特征上，表征好用户和物料，就可以让系统跑起来。

划重点，关注问题本身，来决定要使用的方法。

4）难标注问题

监督学习是深度学习的核心主力，虽然半监督无监督也在进行，但是还有很多场景落不了地。
比如关键词抽取，至今我手上的基线还是tfidf，原因很简单，tfidf强且不需要训练，有一批语料就能统计了，而且效果不差。

3. 算法工程师的落地能力

所谓落地能力，就是指我现在有一个算法，我要把他整到让用户可用的水平，什么叫做用户可用，即用户能够用得到我们的算法。举个例子，头条的推荐系统，里面有大量复杂的推荐算法，他被用户使用到了，这涉及的一系列流程就是落地能力，而针对算法本身相关的，那就涉及数据处理、算法搭建和训练、算法服务打包等多个工作，这些统称落地能力。

1）数据操纵能力
我说的是数据操纵，而非操作，是因为这里面有两个层面的使用。

一个是，懂得数据的操作，能够规范化，整理成模型需要的格式，甚至包括写SQL，确认数据的来源等等，这个对于大部分做过实验、有过实践操作的人来说其实不是一件难事。说白了，这个层面解决的其实是可行性问题。

第二个层面，能够更高效的完成上面的功能，你需要有一定的算法常识，找到操作的空间和时间复杂度尽可能低的方法，从而让程序更加高效的运行，那种把CPU、内存、GPU之类的打爆的程序肯定不可取，一定要有这个观念。

2）模型的设计和开发能力
首先是模型设计，说到设计，其实就是要求你根据实际情况来选择甚至是设计合适的模型算法来解决问题，学术界讲究高准确度之类的说法其实在现实应用并不可取，要考虑很多现实问题。首先，不是所有模型都适用于任何数据规模的情况，有的模型就是对小规模的数据有用，然后，对于不同的数据质量，不同模型的耐受能力是不同的，有的模型要求数据的正确性很高，但是实际上你遇到的数据会有很多问题，另外诸如样本不平衡等原因，很多模型其实并不适用，最后还有一点，就是实际的可用性的问题，举个例子，在现实场景，用户对一些等待的耐受性很高，可以等10秒，但是有些场景，其实用户等3秒就等不下去了，这个时候即使你的模型很强，但是时间太长，其实也不可取，这是个业务层面的问题了。

然后是开发能力，能把你的模型发布出去让用户去用，这个理解起来很简单，你不能把模型的代码给一个用户去跑吧，那你要打包，要上线，可能你需要一些前端或者应用端的帮助，但是至少你这个模型能作为一个服务上线，能被人调用，这就OK了。

3）项目的部署和监控
模型做完了，要上线，这里的上线，危险程度就会提升，所以过程也就会根本更加谨慎。

1. 对于模型，是否有不可容忍的bad case。

2. 上线流程是都规范，如果是大项目，你的模块的更新是否会对有关模块产生影响。

3. AB实验，实验的目标、内容以及检测的内容。

4. 检测线上是否有问题，检测内容。

5. 线上有问题后，是否有可马上回滚的方案。

6. 埋点，一方面确认你的程序正常运行（监控），另一方面记录必要的数据，方便日后还可能要使用（迭代）。