本文出自

培養超強經理人

培養超強經理人

2016年2月號

演算法也需要經理人

Algorithms Need Managers, Too
麥可.魯卡 Michael Luca , 喬恩.克萊恩博 Jon Kleinberg , 桑希爾.穆萊納桑 Sendhil Mullainathan
瀏覽人數:27592
  • 文章摘要
  • "演算法也需要經理人"

  • 字放大
  • 授課文章購買
    購買〈演算法也需要經理人〉文章
  • 個人收藏購買
    購買〈演算法也需要經理人〉PDF檔
    下載點數 10
如何發揮「演算法」這個強大預測工具的最大效能?畢竟,如果運用不當,情況可能會失控。因此,設定演算法時,必須明確陳述目標,也要考慮演算法使用的資料可能造成的長期影響。此外,更要從多元來源收集廣泛的資料。

大多數經理人的工作都涉及到預測。人力資源專家決定聘請什麼人時,是在預測哪些人會有最高的工作效能。行銷人員選擇配銷通路時,是在預測產品將在哪些通路賣得最好。創投業者決定是否投資一家新創企業時,是在預測這家公司能否成功。企業如今做各種商業預測時,愈來愈仰賴電腦演算法。這些演算法以不可思議的速度與規模,一步步地完成分析作業。

演算法能提高預測的準確性,但也會產生特有的風險,尤其是如果我們不了解它們的話,更有可能如此。廣為人知的事例很多。奈飛(Netflix)曾舉辦百萬美元獎金的競賽,要求參賽者開發一個可辨識用戶會喜歡哪些電影的演算法。一些資料科學家組成團隊,創造出得獎的演算法。但那個演算法是DVD 租借時期的產物;後來奈飛用戶轉為以線上播放影片為主後,他們的偏好改變了,原本有效的演算法也就顯著失效。

另一個例子來自社群媒體。現在,有很多網站利用演算法,來決定對用戶顯示哪些廣告和連結。如果演算法過度專注在提高點擊率,社群網站上會有「點擊誘餌」(click bait)氾濫成災的問題,它們以連結劣質內容居多。點擊率上升了,但整體的客戶滿意度可能大跌。

這種問題並非無可避免。我們替各種組織設計和執行演算法,以及尋找新資料來源的經驗顯示,問題往往不是因為演算法本身有問題,而是我們與演算法互動的方式有問題。為免失策,企業經理人必須了解演算法的優點和局限,了解演算法可以解決什麼問題,以及對哪些問題無能為力。

聰明的演算法讓人走錯路?

愈來愈多證據顯示,人性化的演算法讓我們覺得比較自在。這一點是有用的,例如,你設計自動接聽系統時會發現,人們較願意聽真人的聲音而不是電子合成音。但這衍生出一個根本的問題:許多人像對待員工、上司或同事那樣對待演算法,以及執行演算法的機器,但在以下兩個重要方面,演算法的表現與人類大不相同。

演算法是極度刻板的

在最新的《復仇者聯盟》(The Avengers)中, 東尼. 史塔克(Tony Stark,也就是「鋼鐵人」)創造出奧創(Ultron),要求這個人工智慧型防衛系統保護地球。但奧創刻板地理解它的任務,得出以下結論:拯救地球的最好方法,是消滅所有的人類。奧創在許多方面的表現就像典型的演算法:它精確執行接到的任務,忽略其他所有的考量。如果我們不審慎管理演算法,便會遇到這種麻煩。

在忽然之間遭點擊誘餌淹沒的社群媒體網站,也掉進了類似的陷阱。這些網站的總目標是很明確的,就是為用戶提供最誘人、最有意思的內容。為了把這個目標傳達給演算法,這些網站擬定一組看來能準確反映目標的指令,要求演算法找出用戶最可能點擊的東西。這個指令看來不錯,因為人們一般會點擊他們有興趣的內容。但純粹追求點擊率,會很快導致這些網站出現大量膚淺和令人厭惡的內容,因而損害網站的名聲。正常人會明白,網站設計者希望「以點擊率為參考標準,盡可能提高內容品質」,而不是「盡可能提高點擊率,犧牲內容品質也在所不惜」。但演算法只能明白它接收到的明確指示。

演算法是黑盒子

在莎劇《凱撒大帝》(Julius Caesar)中,一名占卜師提醒凱撒「小心3 月15 日」。這顯然是很明確地建議凱撒要小心,但這個訊息也是完全無法理解的。小心什麼?為什麼?凱撒對這個神祕的訊息感到無助,決定不理這名占卜師,說「他在做夢,不要理他。」但3 月15 日,真的成了凱撒遭遇厄運的日子。問題在於那名占卜師提供的訊息不完整,而且旁人無從判斷該訊息少了些什麼,以及那有多重要。

一如莎劇中的占卜師,演算法往往可以很準確地預測未來,但不會告訴你是什麼導致某件事,以及原因何在。例如,演算法可以讀完《紐約時報》裡每一篇文章,然後告訴你哪一篇最可能在推特(Twitter)上瘋傳,但它未必會告訴你人們為什麼傳這篇文章。演算法也可以告訴你哪些員工最可能成功,但不說明哪些特質對成功最重要。

認清演算法的這兩個局限,是改善演算法管理的第一步。我們來看看還有哪些做法,可以幫助我們更有效地運用演算法。

所有目標都必須非常明確

人人都有目標要追求,或是有任務要完成,但我們也知道,不能為了達到目的而不擇手段。我們知道,可能有往往沒說出口的軟性目標(soft goal)必須兼顧,有時也必須有所折衷。我們可能會選擇犧牲今天的一點利潤,換取將來的名譽。我們可能會力求平等,即使這會造成組織的短期問題。但演算法只會一心一意地追求指定的目標。避免因此造成問題的最好方法,是非常清楚地擬定自己想達成的所有目標。

人類知道必須顧及軟性目標和折衷需要,演算法卻會一心一意地追求指定的目標。

如果你有軟性目標要兼顧,就必須陳述它、界定它,以及算出它有多重要。軟性目標如果很難測量,在根據演算法提供的結果做決定時,就必須把軟性目標納入考量。

在Google(該公司資助我們在其他課題上的一些研究),用來決定展示什麼廣告的演算法,出現了一個軟性目標問題,這是哈佛大學教授拉坦亞.史溫尼(Latanya Sweeney)在一項研究中揭露的。她發現,如果你輸入典型的美國黑人姓名,例如「Latanya Farrell」,Google 會顯示有關調查遭逮捕紀錄服務的廣告,但如果你搜尋像「Kristen Haring」這種名字就不會。Google 把廣告點擊率極大化的「硬目標」,導致演算法因長期根據用戶的回饋意見自我調整,實際上產生詆毀特定姓名人士的結果。這是因為用戶搜尋特定姓名時,較可能點擊那些調查遭逮捕紀錄的廣告,導致這類廣告更常出現,產生一種自我強化的回饋意見迴路。這很可能不是Google 故意追求的結果,但如果不加入一個軟性目標,就不會有機制阻止演算法這麼做。

最近,我們看到了軟性目標在實際行動上的重要性。本文其中一名作者與美國西岸某城市合作,協助提升該市餐廳衛生檢查的效率。數十年來,該市主要是採用隨機檢查的方式,但也較常檢查有違規前科的地方。但選擇檢查目標這項工作,非常適合交給演算法。在違規前科之外,我們的演算法找到許多具預測作用的變數。結果是衛生部門可較容易找到違規者,而且就算檢查次數大幅減少,也能找到相同數量的違規者。

相關官員很樂見檢查工作的效率得以提升,希望開始使用新方法。我們問相關人員是否有問題或擔心的事。經過一陣尷尬的沉默之後,有人舉手說:「有點不知道該怎麼講,但我想有個問題必須討論。」她表示,在一些人煙較稠密的社區,餐廳違規事例通常較多。這些社區剛好也是收入較低的少數族群聚居地。她不希望演算法過度針對這些社區。她提出了一個有關公平的軟性目標。我們的因應方法很簡單:替每個社區接受檢查的次數設一個上限,藉此把這個軟性目標納入演算法中。這麼一來,演算法既可達到硬目標(找出最可能有問題的餐廳),也能兼顧軟性目標(確保不會過度針對貧窮社區)。注意,我們能把軟性目標納入演算法中,是靠這個額外的一步:讓每個人都有機會清楚說明他們擔心的事。我們發現,當人們提出軟性目標時,通常是提出某些擔心的事。因此明確問人們是否有擔心的事,可促成較開放和有效的討論。此外,容許人們坦誠直言,也是極為重要的,這樣他們才會說出平常不會講的話。這種做法有助於發現各種問題,但我們最常看到的,通常與公平和如何處理敏感情況有關。

了解核心目標和一系列的「擔心事項」之後,演算法設計者便可把需要折衷的地方納入演算法中。實際上的做法,往往是把根據重要性賦予權重的多種結果納入目標之中。

盡可能避免短視

一家在已包裝消費品這個領域相當成功的公司,從中國低價購入商品,然後在美國銷售。該公司利用一個演算法,預測哪些商品將最暢銷,然後據以進貨。起初生意很好,一切順利,但幾個月之後,消費者開始紛紛退貨。

這種意外居高不下的退貨率,其實是可預測的;儘管該公司的演算法並沒有預測到。該公司顯然也關心商品品質,但未把這項因素納入一個審慎預測顧客滿意度的演算法中,而只是要求演算法狹隘地關注銷售額。經過檢討之後,該公司希望演算法不但能預測哪些商品將暢銷,還要預測顧客有多滿意這些商品,以及它們的退貨率。該公司如今尋求供應那些顧客會在亞馬遜(Amazon)或其他平台上讚不絕口的商品,退貨率便大幅降低。

這家公司掉進了應用演算法的一個常見陷阱,就是未注意到演算法通常是短視的:它們聚焦在手上的短期資料,而這些資料往往與短期結果有關。長期利潤和公司整體目標,可能與短期成果有衝突。這對人類來說,是不言自明的,但如果你不明確告訴演算法,它們是不會明白的。

這個問題可在設定目標的階段解決,辦法是確認並明確制定長期目標。不過,企業經理人基於演算法的預測做決定時,必須根據演算法與長期目標有多一致,來做出適當的調整。

演算法如果因追求最大點擊率,而導致網站充斥著劣質內容,同樣是出現了短視的根本問題。在這種情況下,演算法根據一個可馬上測量到的目標,像是用戶是否點擊某個連結,去調整網站內容,但忽略了較長期和更重要的目標:維持用戶對網站使用經驗的滿意度。

行銷專案也可能出現短視的問題。想想Gap 公司藉由Google 做的一個普通廣告專案。它很可能提高Gap.com 的訪客人次,因為Google 的演算法擅長預測誰會點擊廣告。問題是:廣告的真正目標是提高營收,而非增加公司網站的訪客人次。為了處理這個問題,廣告平台可藉由各種管道,例如裝有支付系統的合作伙伴,來收集營收資料,然後把資料納入演算法中。

此外,造訪網站是短期行為,而廣告的長期影響,還包括對品牌形象和熟客生意的影響。雖然這種影響很難找到完美的資料,審慎的資料審核大有幫助。企業經理人應有系統地列出可能與手上專案有關的所有內部和外部資料。有關在Google 賣廣告,Gap 的行銷人員可先列出全部目標,像是增加營收、低退貨率,以及良好的聲譽等,然後找出測量每個目標的方法。退貨率、線上評價,以及「Gap」這個字的搜尋次數,都是很好的資料。高明的演算法可結合所有這些因素,並考慮它們的相對重要性,據此做出預測。

選對資料輸入

讓我們再回頭談談政府部門抽查餐廳,找出衛生違規者的問題。像是稍早提到的,許多城市向來是用隨機抽查的方式,也可能會考慮以前的檢查結果。本文其中一名作者與提供在地商家資訊的Yelp 公司合作,幫助波士頓市政府利用網路上的消費者評價,來辨別哪些餐廳最可能違反本地衛生法規,創造出一個比較評價文字與歷史檢查結果的演算法。波士頓市利用這個演算法,找到相同數量的違規事例,而檢查人員減少了40%,也就是說,這大幅提高了效率。

這個做法效果良好,不但是因為我們可檢視很多餐廳,還因為Yelp 評價提供了很好的資料,而市政當局之前忽略了這些資料。一則Yelp 評價可能有很多字,包含各種資訊。這種資料也相當多樣,因為它來自許多不同源頭。簡單來說,它與市政當局慣用的、檢查員創造的資料相當不同。

考慮採用哪些資料來源時,應記住以下原則:

● 廣一點比較好

企業常掉進一個陷阱,以為「巨量資料」(big data,又譯為「大數據」)不過是很多筆資料,例如,可分析一百萬筆顧客資料,而不是一萬筆。但這不過是講對了一半。想像一下,你把資料組織成一個表格,每一行記錄一名顧客的資料。顧客的數目,決定了這個表格有多長(有多少行),而你知道每一名顧客多少東西,決定了表格的寬度(每一行記錄了多少項資料)。做預測的一個關鍵原則,是利用廣泛的資料。多一個細節,便多一條線索,而且還可以與既有線索結合起來分析。文字檔案是很好的廣泛資料(wide data),因為每個字都是一條線索。

● 多樣性很重要

由此推論,資料最好是多樣的,也就是各個資料來源之間,沒有很高的相關性。多樣資料可產生額外的預測能力。我們可以把每個資料集當作是朋友的建議。如果資料集太相似,就算增加一個資料集,也不會產生很多額外貢獻。但如果每個資料集都有獨特的角度,便可以創造很多價值。

了解演算法的局限

了解演算法無法告訴你什麼,就跟了解它可以告訴你什麼一樣重要。我們很容易誤以為某種環境條件下的預測,換了環境條件一樣有效。正是因為這個問題,奈飛在2009 年的演算法競賽,無法帶給該公司較多好處:可準確預測用戶會借什麼DVD 的演算法,用來預測用戶會在線上點播什麼電影時,卻效果不佳。奈飛因為那個競賽得到有用的見解,以及良好的宣傳效果,但這些從DVD 用戶搜集到的資料,並不適用於預測線上點播的偏好。演算法利用既有資料,預測換一個稍微不同的背景、群體、時間或問題,會發生什麼事。

這實際上是把一種見解,從一個環境條件轉移到另一個環境條件。因此,如果我們希望把某個演算法用來解決某個新問題,最好是想想它可能不適用的種種理由,然後評估這些理由的重要性。例如,波士頓基於消費者評價和違規紀錄,來決定抽查什麼餐廳的演算法,用在奧蘭多可能效果不佳,因為奧蘭多的天氣較熱,面對的食物安全問題跟波士頓不同。

此外,不要忘記相關性不等於有因果關係。假設有個演算法提供這樣的預測:與較長的推特訊息相比,較短的訊息較常有人轉推。這個預測完全沒有建議你縮短推特訊息的意思。它是一項預測,不是一個建議。畢竟,短訊息會有效,其實有賴於很多其他因素。你不能把它當作建議,因為縮短訊息未必能產生使訊息有效的其他條件。

想想eBay 的經驗。該公司多年來藉由Google 賣廣告,發現看那些廣告的人較可能在eBay 購物。但eBay 不確定的是,這些顯示次數上百萬的廣告,是否真的促使人們前往eBay 網站,畢竟,這些廣告是刻意顯示給可能在eBay 購物的人。為釐清相關性與因果關係,eBay 做了一個大型實驗,隨機向某些人顯示廣告,同時不向其他人顯示廣告。結果顯示,該公司的廣告基本上是沒用的,因為看到這些廣告的人已經知道eBay,而他們即使沒看到廣告,也會在eBay 購物。

讓演算法有效發揮

即使我們擁有能做預測的演算法,在推論因果關係時仍得小心翼翼。這種演算法並不能代替對照實驗。但這種演算法的功能非常強大:它們可以辨識出人類無法察覺的微妙模式,並利用這些模式產生準確的見解,幫助我們提高決策品質。我們的挑戰在於,了解這些演算法的風險與局限,並藉由有效的管理,發揮它們驚人的潛力。

(許瑞宋譯自“Algorithms Need Managers, Too,”HBR , January–February 2016)



麥可.魯卡 Michael Luca

哈佛商學院企業管理助理教授。


喬恩.克萊恩博 Jon Kleinberg

康乃爾大學(Cornell University)電腦科學教授,與伊娃.塔爾杜斯(Eva Tardos)合著有教科書《演算法設計》(Algorithm Design ),以及與大衛.伊斯利(David Easley)合著《網絡、群眾與市場》(Networks, Crowds, and Markets )。


桑希爾.穆萊納桑 Sendhil Mullainathan

哈佛大學經濟學教授,與艾爾達.夏菲爾(Eldar Shafir)合著有《匱乏經濟學》(Scarcity: Why Having Too Little Means So Much )。


本篇文章主題分析