您当前的位置:首页 > IT > 新闻内容

IT工程师也掉进人性的弱点

时间:2019-02-11 11:32:46  来源:  作者:  浏览量:

 IT工程师也掉进人性的弱点

 

在和刘同学长谈之后,我再次对前一段时间的想法进行了反思,结合聊天中的新感受,整理在这里。(注:标题里的算法,指机器学习算法,或者说“算法工程师”这个职位名称里的“算法”,不是“算法与数据结构”里的那个算法。谁能告诉我有没有什么更好的名字来区别这它们,或许是“机器学习算法”与“传统算法”?)

算法与算法工程师先来一段我在知乎里回答“做算法工程师是一种怎样的体验?”的答案(其中的思想并非原创,而是山寨自新加坡某大学一门Quantitative Investment课程的ppt)

理想中的算法工程师:提出假设->收集数据->训练模型->解释结果。

实际中的算法工程师:提出假设->收集数据->预处理->预处理->训练模型->调试->调试->重新收集数据->预处理->收集更多数据->调试->调试->调试->…->放弃。

这个答案被点了几十个赞,在24个答案中排在第二位,说明具有一定的普遍性。排名第一的有100+赞,而他的观点是:每天最重要的就是跑数据!这不是段子,而是事实。为什么“高大上”的算法工程师实际上是个数据民工,要寻找这种理想与现实的差距的原因,首先要理解一个事实:只有人能够理解数据,机器不能。不管我们用什么机器学习算法——无论是LR,SVM,k-means,EM——对于它们来说,输入数据都是一堆浮点数组成的矩阵而以(如果说的更本质一点,只是一堆01序列)。如果有一个特征是“小时”,而它出现了25,任何一个智商正常的人类都能明白,这是一个错误,然后在数据清洗的时候把这样的数据排除。但是机器就无法理解这一点。要具备小时的概念,又要理解什么是时间,一天有多少个小时…机器怎么能自动化完成这样的数据清洗工作?更进一步,如果人发现“小时”这个特征中大部分数据是0到12,而混入少量13(但13的数量又不是太少以至不能被当成离群点排除),人就会怀疑,是不是使用了12小时制而13是一个错误。机器目前是无法做到这一点的。

再说人肉特征。一个是特征变换,比如需要一个特征是某两列数据的比率,这种除法是线性模型不能涵盖的。当然可以增大模型的假设空间,但是太小涵盖不了需要的变换,太大又容易过拟合。另一个是加特征,比如我认为点击率和屏幕分辨率有关系。于是我去找屏幕分辨率数据加入特征,如果没有还要想办法采集。这些机器都做不了。但是,人一但把数据准备好,接下来就是机器学习算法发挥的时候了。但是,算法工程师的主要工作不在这里,这是因为软件有个特点,可以近乎无成本的复制。只要这个世界上有一个人实现了LR(知识产权的问题这里不考虑,更何况开源软件很多),其他需要用LR的人都可以拿过来用了。显然,这些算法工程师们也正是这么做的。然而,等算法输出结果以后,又需要人的工作了——怎样用结果解释实际问题,应用到业务中去。显然这个过程和前面数据清洗、人肉特征的性质类似,都是只有人能完成,机器做不到的任务。做过数学建模的同学对这个过程可能很熟悉——如何把一个问题描述成数学问题,再如何把结果应用到实际问题上。这有点类似于通信中的“最后一公里”问题,主干网的光纤建设的很强大,而最终用户的接入却成了一个麻烦事。对于机器学习的应用问题来说,算法和相应的软件包都是标准化、通用化的,像骨干网;而数据如何“接入”,则是只能由人完成。因为,只有人能够理解数据。技术与技术人员这个问题可以推广到整个计算机领域。把算法工程师代换成程序员,把机器学习算法代换成软件,这个观点就变成了:大部分程序员所解决的,是通用的计算机工具和具体的实际业务之间的“最后一公里”接入问题。为什么这么说,我们先来看历史:计算机技术发展了几十年,程序员的入门门槛是逐步降低的。最初的程序,要在裸机上写汇编。后来有了unix,c语言,程序员至少不用亲自调度进程了。java出现之后,连内存都不用管了。而(世界上最伟大的)php出现之后,网络编程的门槛进一步降低,任何人都可以在短时间内搭建一个网站。原来的那些问题去哪儿了呢?被少数造“”轮子的程序员们解决了——那些写操作系统、编译器、虚拟机、运行时环境、框架…等等的程序员们。这个趋势一直在持续——新兴的rust、golang等语言试图解决多核时代出现的并发问题,hadoop、spark、mesos试图屏蔽分布式系统底层的细节……可以预见,以后的并行编程和分布式编程门槛将会大大降低。这个过程是必然的,因为一项技术的发展,就是为了让更多的人能更方便的使用它。而这些计算机工具不能直接应用于业务,因为计算机不能理解人类的语言,所以就有了大量的程度员存在,把人类的语言“翻译”成计算机语言。这些程序员是使用“轮子”的。

当然这之间并不是非黑即白的,一个软件在多大程度上可以被称为轮子,取决于它的复用性。如果一段代码只能在一个地方使用,它显然不能称为轮子。而事实是,大部分为具体的业务逻辑所写的代码,复用程度很低。对于把通用计算机工具应用到具体业务这个过程,中间到底有多少问题是技术性的?大部分技术困难被操作系统、编译器、虚拟机解决掉了,剩下的主要是大型软件(如果这是个大型软件)的复杂性控制——而这个问题又主要由少数高级别的架构师负责。对于写具体代码的程序员,剩下的技术性困难已经很少了。举一个我供职过的公司,这是一家互联网公司,整个网站99%的代码是php,基本上没有java。没有专门的前端工程师,php、html和javascript代码混在一起。测试几乎等于没有,基本都是开发人员自测。上线流程只是个形式,质量控制部门唯二的作用就是向服务器上同步代码和出现事故之后给开发人员定责任。我曾经和另一个部门合作,他调用我提供的接口,而他在我的接口没上线的时候就上线了,导致一场事故。我本来是算法工程师,写php只是客串,而在这个过程中,没有任何上线依赖的控制,连提示也没有,甚至没有人对我进行上线流程的培训。然而,这是一家中等规模的互联网公司,己经发展了十来年,占据了所在细分市场领域的头号份额,并且己经上市。我举这个例子并不是要黑它,而是想用事实支持上面的观点:大部分程序员,大部分所谓的“科技”公司,所面临的技术问题比想象的要少的多(这也许是那家公司没有CTO的原因)。这不是个别情况,大多数公司都存在类似的问题——从技术角度看,它就是个渣,你会很奇怪它怎么还没死。然而事实是,它不但没死,反而活的生机勃勃,甚至上市了。公司的拥有者们早已实现了屌丝逆袭迎娶白富美的理想,而辱骂他们的程序员们还在苦苦的为房贷或者首付挣扎。这里面,有大量的非技术因素起着关键作用,尽管它们都自称科技公司。越来越多的人意识到了技术的局限性。年初,一个同学找工作,他向来是个“纯技术流”的工程师,曾经写过很好的技术博客,甚至发起过开源项目。然而这次他说,“不想再做最底层的工程师了”,希望能做一些“高层的、能看到项目整体的”、以及“和人打交道,能够把自己的想法向外推动,并产生价值”的工作。于是,他去某公司负责带几个小弟去了。当我把这些转述给另一个同学的时候,他的反应是“我最近也有这样的想法”。还有个同学,说写了几年C++,技术上没学到多少,反而是接触的业务知识比较多。再比如我之前的leader,他是数学博士出身,曾经对算法有一种近乎天真的信仰;在我离职的时候,他已经完全转型为业务和产品导向了。而某个几年前就开始淡化技术,聚会时大讲“软实力”的同学,早已在BAT做了Team Leader,生活滋润,终日以跑步为乐。为何?其实原因很简单:公司里没有那么多技术问题需要解决。

已有位网友发表评论
网友评论

登录名: 匿名发表