你同意「數據比演算法重要」這個說法嗎?
觀點來自這裡:
http://anand.typepad.com/datawocky/2008/03/more-data-usual.html作者說谷歌的強不是強在 PageRank 演算法,而在於它是第一個在排名時把鏈接——而不只是文字和標題——考慮進去的。又以自己教的數據挖掘課為例。他讓學生以 Netflix 用戶對一萬八千多部電影的打分為基礎數據,寫程序為她們推薦別的電影。其中有組學生的演算法較優,另外一組學生演算法一般,但使用了外部數據——IMDB 對電影類型的歸類。結果第二組的結果勝過了第一組。
雖然不能這麼絕對的判斷一定誰比誰重要,但在實際應用中很多時候的確是數據更加重要。有幾方面的原因:
- 在很多問題中,演算法的『好壞』在沒有大量有效數據的支撐下是沒有意義的。換句話說,很多演算法得到的結果的質量完全取決於其和真實數據的擬合程度。如果沒有足夠的數據支撐、檢驗,設計演算法幾乎等於閉門造車。
- 很多演算法會有一堆可調參數。這些參數的選擇並沒有什麼標準可依,無非是扔給大量數據,看參數的變化會帶來什麼樣的結果的變化。大量、有效的數據成為優化這類演算法的唯一可行方法。
- 更極端的例子是,演算法本身很簡單,程序的完善全靠數據訓練。比如神經網路。
- 對於很多成熟的演算法,優化演算法的增量改善通常遠小於增大輸入數據(這是個經濟性的考慮)。
比如問題中舉例的 Google。在它之前的搜索引擎已經把基於網頁內容的索引演算法做得很好了,要想有更大的改善需要換思路。PageRank 演算法的採用大大增加了輸入的數據量,而且鏈接數據本身對於網頁排名相當關鍵(當然他們也做了大量演算法的優化)。【插話:在這樣的思想指導下,Google 想要插手社交網路或微博也不足為奇了吧?實時搜索、排名沒有真人的互動怎麼可能。】
Netflix 挑戰賽的例子中,Netflix 本身的推薦演算法也是優化到極致了。再從演算法本身去找改進之處,投入產出比太低。引文中的學生僅僅是加入了 IMDB 資料庫關於電影分類(從而更加明確觀眾的偏好)就能帶來比複雜演算法更加顯著的改善,試想如果他們能拿到 Rotten Tomatoes 的數據會怎樣?
When people are equally smart, big data wins. 這個結論的悲摧之處在於,在類似行業中,今後小的創業公司想要打敗巨頭就不那麼容易。要麼要改變思路,要麼要改變策略。指望靠小聰明扳倒大象會很成問題。
當然這也不是絕對的。比如典型的反例(演算法比數據重要)是 Google 剛被批准收購的 ITA Software。這家牛 B 烘烘(估計是現存最大的 Lisp shop)的公司的機票搜索引擎驅動著世界各大航空公司、票務中介的後台系統。它的數據來自一個各大航空公司授權的公司,其他競爭者也可以花錢(雖然不便宜)買到同樣的數據。但它的牛 B 之處在於能從同樣的數據里比別人更快挖出更好的結果。數據比演算法更重要,這是有一定道理的,但是在拿它當信條之前,必須知道在什麼場景下它有道理。所有的格言都一樣,是對態度簡短有力的描述,但因為簡短,就不可能全面。比如「成功在於堅持」,當然有道理,但不加分析地事事堅持,就很沒道理了。
數據比演算法更重要,它的意義在於告訴我們,在試圖設計更複雜的演算法去提高性能之前,先看看有沒有辦法收集更多的、質量更高的數據,因為這往往是提高性能更簡潔有效的手段。另外,除了先驗知識外,演算法能達到的最佳性能,受限於數據所提供的有用信息容量,當演算法性能接近這個容量時,不管你再怎麼改進演算法,基本都沒有意義了,唯一的手段就是去獲得更多有用的數據。但要注意的是,這句話的意思決不是說演算法沒有用,或者沒有必要去研究演算法,好的演算法之所以好就在於它能充分地利用數據,如果你的演算法根本就不能有效利用數據,獲取再多的數據也是徒勞。
具體到Anand Rajaraman的帖子,我記得Netflix Prize獲獎團隊主要成員Yehuda Koren有一個評論:在他們的實驗里,IMDB的數據根本沒用。因為IMDB的數據主要能用來描述item-item關係,如果Netflix Prize競賽中這方面數據稀疏,那IMDB的數據就是很好的補充。但是Netflix Prize競賽中,item數量只有不到兩萬,提供的數據已經足夠構建item-item關係,根本用不著IMDB的數據。Netflix Prize競賽中數據的不足主要在於user-item關係得不到充分描述,因為user數量太大了(50萬?)。剛才看了看帖子,沒有找到這條評論,可能是在別人轉述的帖子上Yehuda Koren做了評論。我強烈同意數據比演算法重要!雖然我們可以打官腔說這兩個同樣重要,但如果是一個資深的機器學習和數據挖掘研究人員,絕對不會掩飾他們對數據的渴望,當然對他們來說設計好的演算法是很容易的,但好的數據卻是不容易拿到的。
- 海量數據是金礦,演算法只是發掘金礦的工具。
- 淘金者可能發財也可能破產,真正掙錢的是向淘金者出售牛仔褲和工具的人。
我認為演算法和數據不能割裂開來看。寬泛一點說,考慮採用什麼樣的數據也是演算法設計中的一部分。
程序 = 數據結構 + 演算法,數據結構用來幹啥的,裝數據的呀。
數據能幹啥?數據是信息的源泉,沒有足夠的數據,就沒有信息,信息技術沒有信息啥都沒有。
演算法能幹啥?把數據中信息提取出來,不經過提取,數據還是數據,變不成有用的信息。
這倆不是並列的關係,而是一體的,如何能說誰重要呢?腦子重要還是心臟重要,你給我說說。
此外,數據的好壞如何衡量?不是越多越好,當然數據越多往往所蘊含的信息越大,這個容易看得出來;演算法的好壞如何衡量?不是越複雜約好,能從海量的垃圾中找到有用的信息的演算法就是好的演算法,雖然不這麼複雜,不是所有的人都能看到這點。
我最想說的是什麼?如果不是事不關己的旁觀者,數據往往是自己能拿到最多的數據,然後根據自己的這些數據去找最合適的演算法。嚴格角度講,數據重要,演算法也重要。但是,我覺得大多數情況下,數據更加重要。第一,演算法對於整個研究領域而言是相對透明的,你能想到的方法別人也可以想到,一般成熟的演算法都是已經提出來兩三年的,是業界公認的;第二,數據往往更加事倍功半,演算法改進很難(如果已經有一定基礎的話),但是,如果能得到優質數據,一旦數據量達到原來數倍甚至更多的增加,發現效果會得到十分明顯的改善;第三,優質的數據往往能為演算法提供方向,甚至直接驅動需求;機器學習領域常出現這樣的情況,在一個數據集上得到的結論往往在一個更大更複雜的數據集上變得不同(有人做過實驗,採用一種公認很差的演算法能在一些曾經被使用的比較toy的數據集上取得比好演算法差不多甚至更好的效果),所以,好的接近實際應用的數據集才能告訴什麼是真正好的演算法;而對實際數據分析的結果往往會改變我們固有的對主要問題的觀念,就是你覺得重要的不一定重要,你沒注意的反而是影響問題的最重要因素。第四,好演算法常有而優質數據不常有;看論文總是可以看到更多更好的idea,但是優質數據(比如淘寶)卻是可遇而不可求;
LZ的問題就好像 廚藝和食材哪個重要。。
讓人啼笑皆非的描述,因為演算法,其實是處理數據的(廣義的)。 存在兩個過程,數據的表述和數據的處理(流動),這從來就不是誰重要誰不重要的問題,而是缺了誰,就沒法運行的問題。
這要看怎麼定義「演算法」,其實多數時候,所指的「演算法」是指「策略」。那麼這時候,加入一個新的輸入特徵,其實就是加入了新的「策略」,而不是數據本身的改進。當然,也可以認為增加了新的「數據」。如果認為純純的、與任何數據無關的通用「演算法」本身,例如隨機森林這個方法本身,那麼我也認同,在工程上,數據不是重要,而是我們玩的就是數據,演算法沒什麼可搞的,10年左右會有一批牛人來一次提升,絕大多數工程師都搞不出什麼來的。
這是一個balance的問題,泛泛比較無從談起。當數據多到壓倒演算法的優越性時,可以說數據作用較大,反之亦然。
在學術界,評價同一演算法時,要比較不同規模訓練數據集上的效果,而在評價不同演算法時,要比較在同一訓練數據集上的效果,這樣才有可比性。
在實際中,由於演算法的差距容易縮小,但數據量的差距難以彌補。因此數據量明顯佔優的那方,最終效果會好些。完全同意。
1.對用戶體驗數據極其極其重要 如果只是想讓產品做的更好 把養科學家們的錢換成請相對廉價的勞動力去標數據更划算2.演算法 如果是基於rule的 人工精心設計的rule非常重要 3.對於極其多的數據 並行化演算法相比於不並行的很重要 4.對於發論文 寫作非常重要 人際圈子很重要
還是不要這麼比較吧,意義不大。具體問題要具體分析。雖然我這說了和沒說一樣,我只是不同意這樣做這樣的比較。
演算法和數據是一件事的多個面,您舉的例子里,我看到的主要評價標準就是「數據挖掘結果的有效性」這一點。而從其中拆分出的「演算法 和 數據 孰輕孰重」的問題似乎是要在一元標準上建立兩個主次標準,我認為這樣做只會讓這件事更糊塗。
如果想知道現在的時間,最好只看一個表。對於做事來說,就是只選擇一個參照系來做評判,即使所選擇的參照系(「表」)不太准,你也能得到一個比較清晰的結論。如果再拆分出更多的「表」來評價這件事,不僅把問題複雜化了,也增加了很多無效的思考工作。在很多領域其實都會出現這種現象,比如有的老闆認為績效需要考勤作為基礎,為了提高績效而抓員工的考勤,從而制定出考勤+績效的雙重考核標準,這樣看起來很科學,實際上更多只是徒增了管理成本,我認為這是費力不討好的。
數據可以直接賣錢,演算法要等算出數據才能賣錢。
在數據挖掘領域當然是數據更重要。在解決大部分工程性問題的時候,數據結構往往比演算法分析更實用。因此似乎很容易得出數據比演算法重要的結論,但演算法更多體現的是一種思想,是一種思考並解決問題的方法,數據結構的選擇更是這種思想的體現。
借用一個比方,要做魚香肉絲,演算法是菜譜,數據是裡脊胡蘿蔔。沒有菜譜,做出來的可能是鍋包肉或溜肉段,但做不出來鍋包肉;反過來,沒有原料肯定不行,原料多了,存在進一步改良菜譜的可能,鍋包肉有了新的口味。理解了二者的關係就足夠了,非要分清誰更重要,圖什麼呢?
在一堆繁雜的數據面前,好的演算法尤為重要,沒有演算法,你壓根不知道這一堆是啥東西!
一個是雪中送炭,一個是錦上添花。沒有諸葛亮,只有一群臭皮匠難成大器;有了諸葛亮,卻不能充分發揮其才能,也是白瞎
推薦閱讀:
※進行數據挖掘時演算法需要學習到什麼樣的程度?
※如何構造 n 個數使其最小公倍數(LCM)=其和?( n 個數互不相等)
※std::unique為什麼不用一個hash table實現,而是要先std::sort?
※如何優雅地證明這道卡片排序問題?
※如何求解遞推式 T(n) = T(n-1) + T(floor(n/2)) + 1?