分析自家150個ML模型後,這家全球最大旅行網站得出了6條經驗教訓
在許多媒體文章中,我們都能看到「機器學習賦能 XX 行業」的字眼,但這種「能量」究竟體現在哪些方面,企業在引入機器學習模型的過程中要注意哪些問題,很多文章都沒有說清楚。在今年的 KDD 大會接收論文中,全球最大的線上旅行代理網站 Booking.com(繽客網)貢獻了一篇論文,分析了他們面向客戶的 150 個成功的機器學習應用以及從中得到的六條經驗教訓。本文是對這篇論文的簡短總結。
「150 successful Machine Learning models: 6 lessons learned at Booking.com」是一篇絕佳的綜述,它結合了 Booking.com 大約 150 個面向客戶的成功的機器成功應用以及從中得到的經驗教訓。奇怪的是,雖然論文的標題這麼寫了,在正文中卻從未明確列出這 6 條經驗教訓。不過,我們可以從論文的劃分中推斷出這些部分,以下是我的解讀:
- 使用機器學習模型的專案會創造巨大的商業價值
- 模型的效能不等同於經營業績
- 弄清你正在嘗試解決的問題
- 預測的延遲是個重要問題
- 及早獲取模型質量的反饋
- 用隨機對照試驗測試你的模型的商業影響力(第二點中也有提到)
當然,這篇論文中的好建議可不止這六條。
我們發現,發揮真實的商業影響力極為困難,更何況,將在建模方面所做的努力和觀測到的影響力之間的聯絡分離開來好好理解原本就是一件難事。我們主要的結論是:要用機器學習打造出這 150 個成功的產品,其根本在於,要有一個迭代的、由假設驅動的流程,並結合其他學科。
別把這段引文解讀為不值得在機器學習上投資。與之相反,我認為正如 DevOps 的現狀報告中所提到的高效能組織具有的所有其它特質一樣,提升一個組織設計、構建以及在面向使用者的場景中成功部署機器學習模型的能力,對於提升該組織的競爭力有根本性的作用。(而且,如果能在未來的報告中看到有資料證實或者證偽那個假設,不也是很有意思嘛!)
Booking.com 在構建模型時需要解決那些問題?
你大概聽說過 Booking.com,「世界上最大的線上旅行社」。給使用者傳遞良好的旅行體驗是個有挑戰性的任務,主要有以下幾個因素:
- 推薦的風險很高——預訂到一個錯誤的住處,可比播放一部你不喜歡的電影糟糕多了!
- 使用者在預訂旅程的時候,對於他們真正期待的東西往往沒有給足資訊。
- 住宿的供給受限,價位變動會影響住客的選擇傾向。
- 住客的選擇偏好在他們每次使用平臺的時候都可能發生變化(比如說,如果每年只預訂一兩次)。
- 住宿的相關資訊過多,使用者無法及時消化。
這 150 個模型都是什麼模型?
目前已經有大約 150 個機器學習模型部署到了生產中,因此,機器學習已經觸及了 Booking.com 使用者體驗的方方面面。有些模型非常具體,聚焦於特定背景下的特定情形;另外一些模型則像一個語義層,對某些在多種語境下都能派上用場的概念進行建模,比如基於使用者旅程的終點預測該使用者靈活性的模型。
Booking.com 所使用的模型可分為六個大類:
- 旅行者偏好模型:在語義層工作,對使用者的偏好做出各種預測。(如靈活度)
- 旅行者背景模型:同樣在語義層,預測旅程發生的背景(如家庭出行、與朋友出行、商務出行、……)
- 條目空間導覽模型:追蹤使用者的瀏覽記錄,使得推薦能整體考慮使用者個人歷史記錄和整個目錄。
- 使用者介面最佳化模型:最佳化背景圖片、字型大小、按鈕等 UI。有趣的是,「我們發現沒有某個特定的值是整體最優值,所以我們的模型會根據背景和使用者資訊,來確定最佳的使用者介面。」
- 內容策展模型:策劃並選擇性地展示人工生成的內容,如評論。
- 內容擴充模型:計算一個旅程所含元素的附加資訊,如當前哪些選擇物超所值,或者某個區域內的價位趨勢。
經驗教訓 1:使用機器學習模型的專案會創造巨大的商業價值
在 Booking.com,以上各類模型都提供了商業價值。而相比其它那些沒有使用機器學習的成功專案,基於機器學習的專案往往創造出更高的回報。
圖 2:各類模型相對於影響力中位數的商業影響力
而一旦投入使用,除卻即刻的商業利益,它們往往會繼續成為產品進一步發展的基石。下圖顯示了一系列產品部署的影響力,每一個都基於前者,又繼續改善商業產出。
圖 3:關於某推薦產品的一系列實驗。每個實驗測試了一個專攻某個領域的新版本或某個機器學習問題的設定。條形的長度為相對於初版的觀測值(都有顯著的統計學差異)
經驗教訓 2:模型的效能不等同於經營業績
Booking.com 透過隨機對照試驗衡量模型在某些商業指標上的影響力,以此來預估模型產生的價值。
我們有一項有趣的發現:提高模型的效能未必就能增加商業價值。
原因可能有以下幾點:商業價值的飽和(無論你做什麼,都沒什麼再能榨取的了)、受眾較少導致的部分飽和(新老模型效果大致相同)、對某些不能成功轉化為商業指標(如轉化率)的間接指標(如點選量)的過度最佳化、以及下圖中所闡釋的恐怖谷效應(人形玩具或機器人的模擬度越高人們越有好感,但當超過一個臨界點時,這種好感度會突然降低,越像人越反感恐懼,直至谷底,這種效應被稱為恐怖谷)。
圖 5:恐怖谷:人們有時候並不喜歡太過精準的預測(基於馬爾科夫鏈的目的地推薦器)。圖中的使用者抱怨稱:「booking.com 怎麼知道我在去薩爾斯堡之前要先去維也納?」
經驗教訓 3:弄清你正在嘗試解決的問題
在開始構建模型之前,有必要花時間去對你要解決的問題做一個仔細的定義。
構建問題的過程把某個商業案例或者概念作為輸入,把一個定義好的建模問題(通常是一個有監督的機器學習問題)作為輸出,以此找到一個好的解決方案來為這個商業案例或概念建模。
有些令人驚歎的改進並非來自於在給定體系下對模型進行最佳化,而是來自於改變體系本身。比如,把基於點選資料的使用者偏好模型改為基於住客評論資料的自然語言處理問題。
我們發現,通常最佳的問題並不是那些我們能直接想到的,而改變問題的設定能有效解鎖隱藏價值。
經驗教訓 4:預測的延遲是個重要問題
關於效能對於商業指標的影響力,我們還有另一個重要的點。在一個介紹合成延遲的實驗中,Booking.com 發現,如果延遲增加 30% 左右,轉化率就會下降 0.5%。「對我們的經營來說,這是一個相關成本。」
對於機器學習模型來說,這個尤為相關,因為它們需要強大的計算資源來做預測。即使是數學上簡單的模型,也有可能引入攸關結果的延遲。
Booking.com 採取多種方法降低模型引入的延遲,包括分發多個模型副本來達成橫向擴充套件、自研定製版線性預測引擎、更偏好引數少的模型、批次請求以及預計算和/或快取。
經驗教訓 5:及早獲取模型質量的反饋
當模型處理請求時,監控輸出質量非常重要,但至少有兩個問題不太好解決……
難以觀測到真實標籤,導致反饋不完整。
反饋延遲,比如,在使用者預訂時模型預測了使用者是否會留下評論,但直到旅行完成後才能評定這個預測是否準確。
Booking.com 在這樣的情形下有一招對於二分類問題效果不錯,就是看模型產生的回應的機率分佈。「有一個清晰穩定點的平滑雙峰分佈,大都表明模型能夠成功分辨兩個類別。」其它形狀(見下圖)則表示這個模型或許遇到了一些困難。
圖 7:回應分佈圖的例子
……證據表明,對回應分佈的分析非常有用,幫助我們在早期就能夠探測出模型中的缺陷。
經驗教訓 6:用隨機對照試驗測試你的模型的商業影響力
這篇文章中考察的機器學習成功案例,大都伴隨著精巧的實驗設計出現,有的實驗設計引導了開發的流程,有的則是為了檢測影響力。
文中提供了在不同情況下如何設定實驗的建議。
- 當不是所有被試都有資格參與某個變化的時候(比如他們沒有模型所需的特徵),在有資格的被試子集裡建立實驗組和對照組。
圖 8:對選擇性觸發的實驗設計
- 如果模型產生的結果只在一些情況下影響使用者體驗,那麼進一步限定實驗組和對照組的範圍,使模型在這個範圍裡能產生使用者可見的輸出(當然在對照組裡看不到)。為了評估效能的影響,增加第三個控制組,完全不呼叫模型。
圖 9:對依賴模型輸出的觸發的實驗設計,以及衡量效能影響的控制組
- 比較模型的時候,我們感興趣的是兩個模型不一致的情況。我們使用只呼叫了當前模型的控制組(假設我們在測試比對當前模型和一個候選的改進版本)。這樣的話實驗設計就是這樣的:
圖 10:比較模型時的實驗設計
結語
由假設驅動的迭代和跨學科交融是我們用機器學習創造價值時的核心力量。我們希望這項工作能為其他機器學習從業者提供指引,並在這個專題上激發更多的探索。
原論文連結:%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E9F04A3A78F7D3B8D&__acm__=1571126805_78c20d9477e51ffc6689ca98cd41eb6a
解讀連結: https://blog.acolyer.org/2019/10/07/150-successful-machine-learning-models/
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29829936/viewspace-2665333/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 需求分析經驗及教訓
- 一個小碼農這半年的經驗和教訓
- Heap使用Postgres SQL後的經驗教訓SQL
- 20+條軟體開發的經驗教訓
- 來自10位 IT 大牛的23條經驗教訓
- 面試經驗之教訓面試
- Supercell成立10週年的10條經驗和教訓
- 來自10位成功IT人士的23條經驗教訓
- 建立安卓應用的 30 個經驗教訓安卓
- 機器學習的教訓:5家公司分享的錯誤經驗機器學習
- 口袋妖怪Go手遊的幾個經驗教訓Go
- 17個創業公司的失敗經驗教訓創業
- 10+年程式猿總結的20+條經驗教訓
- AWS 運營 10 週年學到的 10 條經驗教訓
- 微服務遷移:經驗教訓微服務
- 作為專案經理的7個經驗教訓總結
- 經驗&教訓分享:我的第一個機器學習專案機器學習
- 給年青設計師們的10個經驗教訓
- 經驗教訓,慎用Oracle的審計Oracle
- 10+年程式設計師總結的20+條經驗教訓程式設計師
- 19歲程式設計師在谷歌學到的5條經驗教訓程式設計師谷歌
- 12年程式設計師得到的12個經驗教訓程式設計師
- 引入新程式語言的經驗教訓
- 使用MongoDB血淚般的經驗教訓MongoDB
- 關於Web 2.0 的SOA 經驗教訓Web
- 6條經過驗證的創業經驗分享創業
- 10+年程式設計師總結的20+條經驗教訓(轉)程式設計師
- 波士頓動力技術揭秘:後空翻、俯臥撐與翻車,6年經驗、教訓總結
- 來說說成功的雲遷移的10個經驗教訓
- 作為老司機使用 React 總結的 11 個經驗教訓React
- 10 年 Amazon Web Services 總結得到的 10 個經驗教訓Web
- 經驗教訓 給你預防病毒的八個忠告(轉)
- 中小型網際網路公司微服務實踐-經驗和教訓微服務
- 網站設計菜鳥得到的6個慘痛教訓網站
- [譯] Data Binding 庫使用的經驗教訓
- 我的軟體開發中經驗教訓
- 艱困之道中學到的經驗教訓
- 十分鐘教條與經驗,輕鬆搞定系統分析師的案例分析