Scikit-learn和TensorFlow之间有很多显著差异,非常有必要同时了解它们。
Scikit-learn(sklearn)的定位是通用机器学习库,而TensorFlow(tf)的定位主要是深度学习库。一个显而易见的不同:tf并未提供sklearn那种强大的特征工程,如维度压缩、特征选择等。究其根本,我认为是因为机器学习模型的两种不同的处理数据的方式:
上图直观的对比了我们提到的两种对于数据的学习方式,传统的机器学习方法主要依赖人工特征处理与提取,而深度学习依赖模型自身去学习数据的表示。这两种思路都是现行并存的处理数据的方法,更加详细的对比可以参考: 人工智能(AI)是如何处理数据的?
sklearn更倾向于使用者可以自行对数据进行处理,比如选择特征、压缩维度、转换格式,是传统机器学习库。而以tf为代表的深度学习库会自动从数据中抽取有效特征,而不需要人为的来做这件事情,因此并未提供类似的功能。
sklearn中的模块都是高度抽象化的,所有的分类器基本都可以在3-5行内完成,所有的转换器(如scaler和transformer)也都有固定的格式。这种抽象化限制了使用者的自由度,但增加了模型的效率,降低了批量化、标准化的的难度(通过使用pipeline)。
clf = svm.SVC() # 初始化一个分类器 clf.fit(X_train, y_train) # 训练分类器 y_predict = clf.predict(X_test) # 使用训练好的分类器进行预测
而tf不同,虽然是深度学习库,但它有很高的自由度。你依然可以用它做传统机器学习所做的事情,代价是你需要自己实现算法。因此用tf类比sklearn不适合,封装在tf等工具库上的keras[2]才更像深度学习界的sklearn。
从自由度角度来看,tf更高;从抽象化、封装程度来看,sklearn更高;从易用性角度来看,sklearn更高。
sklearn主要适合中小型的、实用机器学习项目,尤其是那种数据量不大且需要使用者手动对数据进行处理,并选择合适模型的项目。这类项目往往在CPU上就可以完成,对硬件要求低。
tf主要适合已经明确了解需要用深度学习,且数据处理需求不高的项目。这类项目往往数据量较大,且最终需要的精度更高,一般都需要GPU加速运算。对于深度学习做“小样”可以在采样的小数据集上用keras做快速的实验,没了解的过朋友看一下keras的示例代码,就可以了解为什么keras堪比深度学习上的sklearn了。
model = Sequential() # 定义模型 model.add(Dense(units=64, activation='relu', input_dim=100)) # 定义网络结构 model.add(Dense(units=10, activation='softmax')) # 定义网络结构 model.compile(loss='categorical_crossentropy', # 定义loss函数、优化方法、评估标准 optimizer='sgd', metrics=['accuracy']) model.fit(x_train, y_train, epochs=5, batch_size=32) # 训练模型 loss_and_metrics = model.evaluate(x_test, y_test, batch_size=128) # 评估模型 classes = model.predict(x_test, batch_size=128) # 使用训练好的数据进行预测
不难看出,sklearn和tf有很大区别。虽然sklearn中也有神经网络模块,但做严肃的、大型的深度学习是不可能依靠sklearn的。虽然tf也可以用于做传统的机器学习、包括清理数据,但往往事倍功半。
更常见的情况下,可以把sklearn和tf,甚至keras结合起来使用。sklearn肩负基本的数据清理任务,keras用于对问题进行小规模实验验证想法,而tf用于在完整的的数据上进行严肃的调参(炼丹)任务。
而单独把sklearn拿出来看的话,它的文档做的特别好,初学者跟着看一遍sklearn支持的功能大概就对机器学习包括的很多内容有了基本的了解。举个简单的例子,sklearn很多时候对单独的知识点有概述,比如简单的异常检测(2.7. Novelty and Outlier Detection)。因此,sklearn不仅仅是简单的工具库,它的文档更像是一份简单的新手入门指南。
因此,以sklearn为代表的传统机器学习库(如瑞士军刀般的万能但高度抽象),和以tf为代表的自由灵活更具有针对性的深度学习库(如乐高般高度自由但使用繁琐)都是机器学习者必须要了解的工具。
工具是死的,人是活的。虽然做技术的一大乐趣就是造轮子,但不要把自己绑在一个轮子上,这样容易被碾死在滚滚向前的科技巨轮之下。
[1] Log Analytics With Deep Learning and Machine Learning - XenonStack
这个4年前的问题选择在这个时间点突然出现在我今天的时间线上显得非常 亦可赛艇!
Android是2008年初才发布,而Oracle在2009年就以7.4B$收购了Sun,是Google不够睿智吗?
非也!
1)如果Android没有如此成功,Java对于Google而言就是一坨shit,Google从来没有想到自己会站在一坨翔上面取得空前的成功,如果有算命的告诉Google的命中贵人是阿翔,它就是穿越回去吃也要把它吃下去,可惜历史不能假设!
2)Google一直有python基因,很多系统都是基于python的,你知道工程师主导文化的可怕性吗?这帮pythonic的nerd出于情怀或者节操或者叫清高或者叫偏执或者叫真爱,它说什么都不会去买Java的,“老子看不上”!谁知造化弄人,09年你对我爱答不理,18年老子叫你高攀不起88亿!(注:今天的Google在各种收购之后,Java服务的比重占的也非常大了,变成了一个杂合的技术栈,而官司也很可能打到高院,尚未定论)
3)Google一直有跟开源保持共存共荣共襄盛举的传统,它跟Mozilla做生意,赞助开源项目,捐赠Wiki,主张“不作恶”,简直就是一副乌托邦理想主义者的化身,圈粉无数(包含答主),像Java这种项目,它更可能的方式是烧一笔钱给它花,然后来几句“希望Java明天会更好”之类的废话,它根本就不曾想过有一个家伙抄底了,因为那时候Android根本就没有火,Google从来就没有想过Java也T-M-D算哪门子“底”?
4)Sun的主手人也是个技术型的,就是技术牛掰业务做的稀烂,当时怎么看Sun都处在夕阳,SPARC也是逼格满满业务下滑被Intel捣的稀烂,那个价格没有几家觉得划算的,幸好是Oracle这种剑走偏锋的收购了它,要是换一家公司收购多半就把Sun雪藏甚至捣腾碎了,Java也就没有今日风光了,而Google在坊间也有创业公司杀手的美称,也许这就已经是历史发展的最好结果了。
什么,你问我对于Oracle收购Sun和MySQL怎么看?
还能怎么看?好白菜都让猪给拱呢呗!
但是作为吃瓜群众,我最喜欢看大佬们掐架,Google与Oracle的这场官司绝对酸爽,大家保持关注,各家都有千百号律师,吵起架来想想都 亦可赛艇!学知识产权法/专利法/法理学的同学们千万不要错过,说不定两年后就能进教材作案例呢!
什么,你又问我Google应该怎么做?
靠,我有不是劈柴!按我的观点,Google这次是违反了Java的使用协议的(无意引战,定论的事情留给专业法官),不能因为体量大就以为能压死人,那可是在美帝,万事全靠律师一张嘴,怎么讲都有理!
大家还记得微软以前有个skydrive吗?在英国被判败诉了,最后也得改名叫OneDrive呢!Google有钱了不起啊,过来领罚单!
而Java的坑早早就埋在那里了,所以苹果直接一刀切:老子不支持,免得搞一嘴毛!Flash一身毛病,一刀切,老子不支持!
所以,我对Google的建议是:
这TM不是关乎技术,不是关乎信仰,不是关乎生态,不是关乎用户体验!
这TM关系到命!
什么?要我预测结果?
法官中间调停,你们俩和解,google把赚的钱按每部手机给Oracle付钱?什么你说太扯了?你每买一部Android,都要给微软钱,你造吗?Oracle就想躺着就把钱收了!