未來是屬於演算法的,不是程式碼

黃小非發表於2017-04-11

大資料的時代已經來臨。資料帶來的狂潮就猶如又一次工業革命一樣席捲著人類。在大資料的時代,人類對世界的理解方法從有限具體抽象過渡,這也就是為什麼演算法比程式碼更加重要的原因。

說到大資料……

如果把人類的歷史壓縮到一天,那麼我們可以忽略之前的時間,直接從晚上11點07分開始說起。這本該是安靜的一天,但是就在這一天快結束的短短的時段裡,突然產生出大量的知識和資訊,需要在人與人之間進行傳播。你可以想象一下,之前,人類的知識和資訊的傳播方式是通過口口相傳,代代相傳,由父到子,師授徒承的方式來進行的。而在某一個時刻,人類社會所產生出的知識和資訊的體量已經達到了傳統方式無法承載的地步。

我們需要某種方式來對如此規模的知識和資訊進行儲存和傳播。以前,採用書寫的方式記錄知識和資訊,被認為是人類社會的重大技術革新。然而,柏拉圖在《斐德羅篇》中寫道:“蘇格拉抵對採用書本進行知識傳承的方法表示擔憂,因為他認為書本並不能激發真正的知識和智慧,正確的方法應該是口口相傳。”

他的觀點正好代表了知識和資訊的有限傳播方法。你和你認識的人通過說話進行直接交流,那麼在交流對話過程中就有正向和反向的觀點產生。而一本書,則完全不同,這是一種抽象的交流傳播方法,因為讀者和作者之間並沒有直接的交流。書的作者不可能知道是誰,多少人,在什麼時候什麼地點讀了他們的作品。書的作者也許可以根據讀者們的情況對作品進行一些優化調整,但是總的來說這還是一種抽象的知識傳播和學習的方法。

大資料和等腰三角形

大資料時代產生的另外一項重要變革,就是我們會從簡單計算向抽象計算過度。也就是形成了定理、符號、演算法等等被稱之為數學的思想。人類歷史上有記載的最早的計算始於公元前 2500 年的美索不達米亞。當時美索不達米亞人需要算出一個裝滿的穀倉能夠養活多少人。

美索不達米亞人的問題是非常具體的。他們的計算問題是為了解決生活中的相應問題。這種一個計算問題對應一個生活中具體問題的模式,就被稱作是有限具體問題。這也是為什麼很多專家認為美索不達米亞人的計算並不是數學的起源。這種有限具體的計算模式一直持續了很久,直到公元前500年的古希臘。那時的畢達哥拉斯學派的學者們開始研究奇怪的三角形的問題。比如:等腰三角形的邊長是不是都是整數。

如果你採用有限具體的方法來解答這類問題,就要像畢達哥拉斯學派的學者們當時做的那樣,通過把具體的數字代入進去看情況是不是滿足。不過,隨著代入數字的數量越來越多,複雜性的問題出現了。你究竟需要代入多少資料,才能最終證明這個命題是真還是假呢?(順便說一下,這個命題是假的,不可能所有等腰三角形的邊長都是整數。)等腰三角形邊長問題的不同之處在於,它是不具體的。因為這個命題沒有限定三角形的面積,也沒有限定邊長範圍。因此可能的情況是無窮多的。不過一旦你開始把理性思維應用到大量數字上,那麼就形成了數學思想。這也就是大資料的意思。畢達哥拉斯學派的思維方式將人類帶向了更接近抽象的數學本質,我們今天也在用符號、規則系統以及理性的思維來解決這類抽象的問題。

也許你能在人類歷史上找出更多關於大資料的例子,但是從本文的目的出發,我則要直接跳到20世紀,來看看編碼是如何興起,以及如何在現代科技世界中扮演重要角色的。

程式設計的興起

編碼,或者叫程式設計(我們在這裡認為這兩個詞是一個意思)首次出現在歷史舞臺,要追溯到美國女海軍少將Grace Hooper女士1945年在哈佛Mark I型計算機上工作的那個年代。在此之前,電腦(Computer)這個詞,現在大家都這麼叫,就是單純的“計算機器”。第二次世界大戰期間,發射火炮需要參照一個彈道表來計算彈道。彈道表上的資料,是用偏微分方程代入上百個不同的引數因子算出來的,這些引數包括:距離,海拔,風速,溫度,溼度等等。順便說一下,“電腦”(Computer)這個詞,是軍方用來形容那些戰爭期間操作計算機器的女性操作員的。這些女性操作員以“電腦”而聞名。她們需要把計算卡插入計算機器,然後搖動手柄解出方程。製作一張計算卡當時需要170個人月的工作量。

程式設計的出現,源於人們想找到一種更簡單的方式來執行計算過程。如果我們能夠為計算機器設計一套指令,讓硬體能夠根據指令來執行操作,那麼那些對機器的手工操作就可以淘汰了。

這種方式聽上去是不是很耳熟?美索不達米亞人採用泥板來進行計算,而程式設計則是20世紀人類使用的“新泥板”。儘管程式設計看上去比泥板要先進多了,但是本質上都是對具體問題進行的有限計算。只是用程式設計的方式計算效率更高。程式設計淘汰了手動計算的方式,讓人類有能力去處理大量的資料。

演算法 vs. 程式碼

演算法:用一系列步驟來描述解決某種問題的思想,執行這些步驟後可以達到問題的正確性條件和終結條件。演算法是對計算的一種抽象描述,與具體的實現無關。

程式碼:計算機的一套指令集。在特定平臺上使用特定的計算機語言對計算問題進行具體實現。

計算機提供的指令操作的方式讓人類可以通過演算法來實現複雜的計算。而演算法本身卻是遠在程式設計發明之前就存在的。穆斯林數學家Al-Khawarizm在公元820年就提出了一次和二次方程的求根演算法。而演算法(Algorithm)這個詞就是從Al-Khawarizm的名字的拉丁語譯名“Algoritmi”演變而來,“代數”(Algebra)這個詞則是來自於阿拉伯語“al-jabr”,這是Al-Khawarizm在解二次方程時所用的一個步驟的名稱。演算法要求其步驟或指令是有限的,可實現的,而且能得到結果。正如我們所見,程式設計可以直接給計算機下指令。這種方式正好對實現演算法非常有利,因為從本質上來說,程式設計就是讓計算機按照一定的順序執行不同的指令。

在大資料時代的早期,我們要處理的資訊量大大增加。不過通過設計和應用,可以讓我們在程式設計方面取得優勢,再加上“摩爾定律”帶來的機器效能上的進步,讓我們有能力處理人類世界日益增長的數字化需求。但是用計算機解決有限具體問題的本質並沒有變,因為人類是通過寫程式碼來告訴計算機硬體具體需要執行哪些操作。不管這些操作本身有多複雜,但是終究還是來自於人類的指令。不過,演算法已經展示出了巨大的潛力,或許能開創一個全新的抽象時代。

演算法的興起

從下面這個角度,我們可以看到演算法與編碼的巨大不同:你可以用程式碼實現演算法。並且,演算法的不同實現方式會影響演算法的效能。例如,使用binary heap來搜尋序列中的最大或最小元素就比較高效,用來排序則沒那麼高效。但是你會程式設計並不意味著你能設計演算法,這和你能唱歌不一定就能寫歌是一個道理。

所有人都知道,“摩爾定律”預言的硬體效能的增長刺激了數字化經濟的發展,但是很少有人知道,在很多領域,演算法帶來的效能增長遠比硬體來得更高。實際上,根據2010年的聯邦報告顯示,演算法在語音識別,自然語言處理,物流等方面都帶來了顯著的效能增長。

“儘管公眾的理解程度並不高,但是仍然不能掩蓋其卓越的效果——在許多領域,演算法的進步帶來的效能增長要遠超CPU計算速度增長的貢獻。”——節選自“致總統和國會的報告:設計數字化未來”

抽象演算法

我們在目前的這個時代需要處理的資料量,讓我們必須放棄之前具體有限的思維方式。這是大資料迫使我們這麼做的。大資料迫使我們必須後退一步,這是抽象的一步,以便於我們能夠找到一種有效的方法,來處理當今時代洶湧氾濫的資料潮流。傳統的做法是,你寫一段程式碼,通過特定的引數或模式來對資料庫進行搜尋。比如,你要搜尋“客戶資料庫”,找出在兩週內購買2件以上物品,且支出超過30歐元的客戶有哪些。你想給這類客戶提供一些建議。所以你提供一種模式去搜尋這些使用者的資料。但是,大資料的方式是正好相反的,你需要通過大量的資料來找出模式是什麼樣的。

試想一下。這裡有海量的資料,人類無法從中直觀地找出模式。這時你就必須再退一步。這抽象的一步是為了讓我們利用聚類,分類,機器學習等為基礎的新方法(而不是具體的程式程式碼),從資料中找出有用的模式。這一步的關鍵在於,要找出你我看不見的模式。就像是光譜裡的波長一樣,人的肉眼是看不出來的,如果資料超過了一定的體量,那模式就不再直觀了。這種超過一定體量,我們無法直接看出模式的資料,就叫做大資料。

這抽象演算法的一步會走得更遠。它不僅能幫我們找出資料中隱藏的模式,甚至還能幫我們寫演算法的程式碼。在Pedro Domingos寫的“終極演算法”這本書裡,描述了一種“學習演算法”,通過機器學習的手段,這種演算法不但能夠創造新的演算法,而且還能寫出我們需要的程式碼,這樣計算機就能“自己寫程式碼了,就把人類從編碼中解放出來。”為了達到這樣的目的,我們就必須對這些演算法的工作原理有更好的瞭解,並通過改進這些演算法,讓它們能夠更貼合我們的需要。不然,我們就沒法充分發揮這種抽象轉變的巨大潛力。

“工業革命把人類從手工勞動中解放出來,而資訊革命將人類從腦力勞動中解放出來,但是機器學習則是讓計算機解放了自己。如果沒有機器學習,程式設計師將成為革命程式的瓶頸;有了它,進度就不成問題。”——Pedro Domingos, “終極演算法”

關於演算法的思考

在從具體有限的計算向抽象計算過度的過程中,我們還是需要各種各樣的程式設計師的。不過這不是問題的關鍵。我不是要說程式設計不重要,也不是說程式設計不會做出貢獻了。我想表達的觀點是,我們需要開始對演算法加以重視。演算法並不僅僅是數學家需要關心,或者在學校裡面才會用的東西。其實我們在程式設計的時候,演算法就在我們周圍,只是大家覺得不需要知道演算法的實現或者原理罷了。目前,已經有人在致力於把更先進的技術(例如遺傳演算法)應用到大資料上,從而探索在不同領域進行優化和改進的可能了。甚至有人對金屬冷卻的過程進行建模,然後建立了效率更好的優化演算法。(這種演算法叫做“退火法”,這是一個從非常規角度思考演算法的好例子,感興趣的可以瞭解一下。)

目前,程式設計已經被提高到了和讀書、寫字一樣的地位,在新的數字化經濟時代成為了一個關鍵技能。這種熱度反而掩蓋了我們對演算法的看法。演算法逐漸成為我們生活的一部分:想想那些網上電影推薦,新聞推薦,正是演算法根據我們的行為歸納了我們的模式。我們需要對演算法加深理解,只有這樣,我們才能更加深刻地理解我們的未來。

打賞支援我翻譯更多好文章,謝謝!

打賞譯者

打賞支援我翻譯更多好文章,謝謝!

未來是屬於演算法的,不是程式碼

相關文章