ML&DEV[14] | 浅谈解决问题的能力

【ML&DEV】

这是大家没有看过的船新栏目！ML表示机器学习，DEV表示开发，本专栏旨在为大家分享作为算法工程师的工作，机器学习生态下的有关模型方法和技术，从数据生产到模型部署维护监控全流程，预备知识、理论、技术、经验等都会涉及，近期内容以入门线路为主，敬请期待！

往期回顾：

• ML&DEV[9] | gRPC初体验

• ML&DEV[10] | gRPC的应用

• ML&DEV[11] | 浅谈模型的局限性

• ML&DEV[12] | ML中的数学学习

• ML&DEV[13] | 快速从无到有建模完成思路
  

浅谈解决问题的能力

最近多少有点强烈的想法想聊聊这个从机器学习任务触发但是又不局限在机器学习本身问题——问题的解决能力。下面聊的东西可能有点方法论甚至有点哲学，有没有兴趣大家看着办吧。

目标旨在让大家更好更快地解决问题。好的定义是高准招、低出错率。

算法问题的解决思路

算法问题不外乎是两种：

• 从无到有，处理一个算法问题。目标检测怎么做，意图识别怎么做，实体识别怎么做之类的。

• 算法的优化，已有算法A，我现在要提升他的准招，或者是某个业务指标，例如点击率。

能直接百度到的问题都不叫问题em。

前者其实并不难，但是要求一个人的基础足够扎实，如果一个人自己已经积累，例如代码啥的，就会很快，这个非常吃经验和积累，对于一片荒芜，一个人要开垦，需要做的事情很多也很杂。举个例子，现在要做一个文本分类，说着简单，fasttext、textcnn甚至现在流行的bert都有现成的代码可以用，现代文明的成果被层层打开，大家可以尽情的享用，但是样本从哪来、怎么构建，这就是个难题，爬虫、论文、开源数据集之类的都是获取的好方法，能是出浑身解数解决这个“棋筋”级别的问题，整个问题也就解决了，论文可以有、需求也可以满足。

后者是很多大厂算法工程师常做的工作，产品或者你的kpi其实挺明确的，提升准招，这是模型的效果指标，然后还有点击率、gmv之类的业务指标，这种问题的难点往往在于难以下手，我这里给一些建议吧

• 多看case，NLP问题就直接看bad case，看看能不能总结出规律，NLP问题哪怕是深度学习模型，很多时候就是一个统计问题。

• 推荐之类的问题，由于本身是一个系统，流程会比较长，多去推演用户的推荐过程吧，就会发现有什么地方给用户整了不合适的东西，或者我们判断用户喜欢的东西用户是否真的喜欢。

要优化模型要找到突破口，然后尝试去解决，往玄学的说就是业务理解，真实的其实来源于自己有没有足够多的想法，这个依赖于积累，看论文够不够、看别人的例子够不够，别人会有一些优化方法和思路，无论是策略上还是特征模型上，其实都可以借鉴。

工程问题的解决思路

相对真正专业的工程同学而言，工程能力往往是算法同学的短板。刚开始工作，Java看的懂写不好，c++是大一还是大二学的皮毛，hadoop之类更别说了，没接触过，spark我是最近才会写的，这个真的非常正常，不会其实不可怕，怕的就是不能快速学会然后尽快上手完成主干问题——例如我们的算法问题。

回到工程，问题往往是这几个层次。

• 怎么做。一般是基础不足，多看教程之类的自己多写，然后开始完成特定的任务，算法题是一个比较好的联系。

• 程序怎么跑。百度！

• 怎么报错了。看看报的什么错！报错信息，看看什么意思，然后转到下一个问题

• 为什么报这个错。百度！

• 为啥同一个错他解决了我没解决。多看几条百度，还不行开始尝试深入了解，例如看看文档，看看源码。

• 程序一样，为什么结果还不一样。找不同，不只是代码，还有数据。

• 怎么不报错？那我到底错在哪。玄学阶段了，只能自己开始找问题，这个有时候就是很久。

• 最后根据自己本身有的时间和有的资源，开始问人吧。

整个这些问题的思路，其实都是围绕自己来去解决的。工程很考验一个人独立解决问题的能力，除了一些违法违纪信息的检索，在百度谷歌上估计很大一部分都是程序员的搜索query了，自己查的多，尝试的多，其实就知道怎么去解决各种问题，“久病成医”让人心疼，但是在写代码这件事上，遇到的问题多了，能解决的问题就多了，这就是所谓的“经验”，很多不知道自己不知道的事情是可以通过实践来补充。

有关提问

首先把提问的礼仪摆出来：如何优雅的提问？希望更多的人能理解，作为一个虽然号不是很大但是博主，但也接触了各色各样的人，希望大家提问，作为求人的一方，至少礼貌诚恳点，不要把事情当做理所当然吧，这个要求真的不高，聊到这，懂的人早就懂了，不懂的人怎么说也没办法。自认为是一个脾气还行的人，只不过授人以渔的回答方式可能会让伸手党不太舒服，不过对白嫖、理所当然、无脑喷的人非常的抗拒。

什么东西该被拿来提问，尤其是在问人的时候，其实我觉得这不只是一个解决问题本身的问题，还是一个资源消耗的问题，其实每一次提问都在消耗和你认识的人的资源，所以精心思考什么问题该问不该问，该问谁都是很重要的。

• 自己解决的时间是否足够。有时间给你造真的建议自己多研究一会，难是难，上坡路才是困难的。

• 是否是那种，不问一定不知道的问题。举个例子，找公司内部对接人，大部分情况不问真的不知道该找谁，换个工程点的例子，部门的c++用的是什么编译，用tf的什么版本之类的。

• 是不是合适的人给出了答案，这件事就可以结束了。知其然知其所以然，很多事情我们是需要知道我们原理的，除了老师家人，真的很难要求谁事无巨细的告诉你。

当然的，人际关系实质上是要经营的，没有谁理所当然要对你好，每次提供帮助后会损失一些，那日后你还要再补回，消耗完了不补充那朋友就没了。

小结

回到问题，打铁还需自身硬，自己有足够强的能力，那很多问题都能轻松解决，对于一名一线技术人员，更多的是亲力亲为，自己解决，真的就是最好的方式。