【ML專欄】可解釋性與修badcase
來自專欄 互聯網在孫嘉龍低維認知中的投影
TL;DR
- 高準確性場景下,策略類方案的核心競爭力是badcase的平均修復成本足夠低。
- 【可人工快速維護性】可能是可解釋性的一個更好的定義。這裡可維護性指:在不顯著影響其他case結果的情況下精確干預特定類別的case的結果。
- 純人工規則系統也未必就有可人工快速維護性。
- 目前來看,ML模型外加人工補丁系統可能是提升可人工快速維護性的唯一方式。
題外話
面試時經常發現一些應屆生同學總是覺得DL沒有可解釋性,而其他非DL模型是有可解釋性的,但深入探究時則各種語塞,所以才有此文。
可解釋性如何定義
要討論可解釋性,首先需要明確其定義,這裡我並不想討論目前互聯網中ML相關群體對此的認知,而是談下我個人的一些看法,希望能夠拋磚引玉。
第一代ML應用領域沒有可解釋性的強需求
首先,在一些領域中,其實沒有太多的可解釋性需求,例如廣告、一些推薦位、一些feed流場景。因為在這些場景中追求的是平均效果的提升,單次的結果不好其實並不會對用戶有明顯的體驗傷害。平均效果好就夠了,在乎規則是否可解釋並不是業務要關心的,為了可解釋性而犧牲效果也是不能接受的,這談不上討論可解性的高低。
就算是在一些需要給出推薦理由的場景,究竟是否需要有可解釋性的模型也是值得懷疑的。例如,(1)【因為你買過XX所以為你推薦YY、ZZ】,(2)【猜你喜歡AA(分類、領域)所以推薦BB】。
這裡(1)的情況在我來看根本算不上什麼解釋,因為你買了尿片所以給你推薦啤酒?(這是個ML的常見梗)在消費者看來根本是無厘頭的解釋。統計上的相關性不是因果關係,更何況很多時候你挖掘不到真正原因是什麼。
(2)這種目前似乎很少見了,想來是因為很容易分析錯理由。而且各種隱語義模型根本給不各個隱語義成分的分類名,只能靠給出一些代表性的對象靠人工標註。更何況對於某些分類我其實很懷疑是否真的有一個人能直觀理解的分類名。
一個例子就是滴滴早在3年之前就能夠以高的令人驚訝的質量挖掘出各個位置的上車點簇位置,但如何給這些上車點一個10米級的直觀的名字則是一個一直困擾技術人員的問題,因為你不看街景根本不知道那裡有一個廣告牌且適合上下車嘛。
目前來看,當你真的在業務上就需要給出一個理由的時候,基本為所有原因做一個單獨的多分類模型可能是一個更靠譜的思路,或者為每種理由單獨做一個二分類模型。這個模型有可解釋性么?其實可以沒有。
高準確性和可解釋性沒有關係
還有些同學會覺得在一些要求高準確性的場景會有更強的可解釋性需求。但其實有一個解釋不代表解釋就一定是對的,而有一個解釋未必就能讓系統更可靠。可以讓我們想像下面的場景:
- 你家的人臉識別門鎖有一次誤放了一個小偷進去,因為它對那個人的判定是99.99%的概率是你。
我相信你作為用戶是不會買賬的。若你作為開發人員,這個解釋對你來說有什麼用呢?
非深度模型的可解釋性?
一個常見觀點是LR這種線性模型的可解釋性很好,因為每個成分的係數是可見的。在某些領域中也確實是限制必須要LR這類模型,但他們到底要的是不是可解釋性我覺得是有待商榷的。
例如還是上面這個例子,假設那個模型是一個人工構造特徵+LR,你發現因為那個人眼間距是0.8,鼻子長度是1.2,嘴寬度是2.3,乘以各自的權重再sigmoid之後判定是你的概率就是99.99%。這算解釋了么,我覺得不算。
決策樹也是一樣,ML得到的決策樹類結果其實看起來也沒好到哪,且不說xgboost之類常見情況用到上百棵樹,就算是一個簡單決策樹,我告訴你這個人:
- 眼間距<0.8
- 鼻子長度是<1.2
- 嘴寬度<2.3
- 耳朵長度>2.5
- ……
在這個葉子節點上是你的概率99.99%,這算解釋了么?我覺得沒有。
不看數據分布就看單個case,你怎麼也給不出一個人想要的解釋,而且那個解釋可能根本就沒有。
規則系統也未必有可解釋性
一般人都覺得人工寫的一條一條規則是最有可解釋性的,如果一個規則只有不超過10個左右的分支的話,確實比較容易理解和修改。
但可能有些同學實際維護過幾十個甚至上百個分支的邏輯代碼,而且這些規則中很多是哪些對於一些連續性特徵的值的規則,而你作為新接手邏輯的人對這些值意味著什麼完全沒有頭緒。我相信你肯定會覺得這些規則基本和一個黑盒的ML模型也沒什麼太大的差別,只是人工構造特徵和選擇分裂位置而已,可能都還不是最佳的劃分方式。
以修badcase成本為核心能力的第二代ML應用領域
在O2O的很多新場景下,很多策略邏輯的正確率要求和前面說的第一代場景有著顯著的不同。原因如下:
- 單個badcase對用戶體驗的傷害特別大:可能導致一個用戶的直接流失,或需要比較高的成本來進行安撫。例如你打車時候預估30塊,到了目的地收你100塊。你叫個外賣,預估半小時送到,結果2小時才送到。這些絕不是一次feed流刷新給你推薦的不好所能相比的。
- badcase往往是場景穩定的。就是說如果你一旦命中的badcase,那可能就會一直命中。這往往是規則或者數據對於你附近的一些情況沒能很好的處理所導致的。
- 從業務上來說,這些badcase是不能忍受的,策略同學必須及時進行修復。
就是說如果第一代場景的準確率要求只有1個9的話(90%),那麼在一些新的場景下策略的正確率可能要2個9乃至4個9,而badcase率的降低甚至比平均效果的提升還要重要,某些時候甚至要改變產品形態來進行妥協。這也是為什麼醫療輔助診斷系統是一個比自動醫療診斷系統更靠譜的產品形態。
正因為如此,快速人工干預策略系統,修復badcase就變得非常重要。這直接關係到用戶留存,企業生死,甚至行業發展——例如uber無人駕駛撞人事件(雖然這個case即使人來駕駛也會傷亡)。
而這需要的就是系統的可人工快速維護性。這裡的快速因場景而已,可能是幾分鐘,也可能是幾周,但肯定不是等下一個靠譜的DL網路結構出來這種時間尺度。
某種意義上,滴滴和美團正在戰鬥的打車和外賣領域中,這樣的問題比比皆是。我們從美團外賣不強制騎手的按系統推薦順序配送中也可能看到其中的考量。
可人工快速維護性
在我來看,可人工快速維護性是一個更好也更狹義上的可解釋性定義,這裡的維護包括:(1)在不顯著影響其他case表現的情況下干預特定類別的case的表現。(2)新增對於某些種類case的規則。
在這個定義下,人工規則集未必就能夠滿足,而以DL為主體的系統也未必就不能滿足。
如何實現可人工快速維護性
複雜規則系統
正如前面所說,一個幾十個分支以上的規則系統的可理解性和可【局部修改而又不影響其他case的表現】性都已經相對比較差了。
這種系統無論是首次編寫還是後續維護都很讓人痛苦,目前這方面的我所知道的最佳實踐是:
仔細記錄每條請求/數據使用了哪個分支,這種日誌信息要隨結果一起保存。並注意觀察哪些分支已經不再被使用,修改策略時注意觀察影響了哪些case所命中的分支。
如果這個規則系統處理的是一個有限的數據集,那麼還好,我們能容易得知道:
- 哪些規則已經確實過期,不再被使用,可以刪掉。
- 修改了策略之後確實影響了哪些結果,這些影響是否符合我們的預期。
但很多時候這個規則系統是跑在線上代碼中的,面對的請求是無限的,無法窮舉。此時的方法就只有:
- 沒事不要碰它。
- 先在外面封裝一層,修改邏輯時候外層打補丁。
- 給每個分支加日誌,如果一個分支在相當長的時間內沒有被使用,那麼推測其已經失效。但是不是真要去掉是另外一個問題,一般都是不去掉,只是為如何設計下一代系統提供了信息。
這其實和面對一個ML黑盒沒啥差別了。
目前的有監督學習模型本身基本沒有可人工快速維護性
可能這個斷言有點過了,不過如果你真的有一個修復具體case又不影響其他case的方法,那你不就創造了一種新的模型參數優化方式?
一般來講除了類似分桶計數之類的方案,面對一個稍微複雜點的模型時,你都是很難人工修改單點的。
ML的救星1——模型結果數據化
如果ML模型本身不好人工維護,那我們就只能丟棄ML么,並不是。當面對有限的query/數據時,可以將所有的結果存下來,使用時直接查表。需要干涉結果時候直接修改結果數據。批量新增數據時使用模型結果作為初值。
這也是為什麼現在頭條快手在被監管之後大量擴展人工審核的原因,因為畢竟文章、視頻是有限的,可以人工干預。
這條線也可以參考我前面的文章:
孫嘉龍:【ML專欄】【2018Q1】(4)眾包vs有監督學習
ML的救星2——規則補丁
前面說的方式其實某種意義上是一個補丁,不過這個補丁沒有泛化能力,只是對於單個case。
當面對無限query時,存下所有結果是不可行的。但我們可以在ML外加一個人工規則補丁,當滿足XX條件時丟棄模型結果,使用我們硬編碼的一個結果,或是由規則產生的一個結果。由於這一般都是修復badcase,所以往往不太需要過多的泛化。
隨著系統運行,可能會積累下大量的規則補丁,如何管理這些補丁就會成為一個問題,下面有幾個建議:
- 如果使用的上游特徵數據是可以干預的,那麼可以把一部分規則固化為數據修改。
- 記錄每個規則被使用的頻率。這個被使用的定義是:被命中,且結果和ML模型結果不同。規則從增加到過期下線的整個生存期都應該被仔細管理。
- 可以把規則的badcase加入到模型訓練集中並額外加權,但這並不總有效。
- 嘗試用某種方式分析這些補丁case,找出新的特徵來把這些case納入到模型中。但這其實很難。
隨著規則複雜到一定程度,這個規則集可能性能會無法忍受,但說實話如果構造規則時候沒有仔細考慮未來成本的話這個問題很難解決。
還有某些情況是沒法、或者很難做規則補丁的,例如圖像、語音、視頻等,畢竟他們本來就是難以構造特徵,靠DL紅利才快速發展的。這方面要怎麼打補丁我也不是很清楚。
ML的潛在救星3——可微分編程
上面兩種補丁最大的問題是:(1)很難泛化,面對大量badcase時候難以人工干預。(2)對於某些難以人工構造特徵的場景下難以干預。
這方面我覺得可微分編程的思路可能是可行的,但現在感覺這方面的研究和框架都還比較少。
這條線總體的思路是:將整個策略分解為可解釋的幾個子模塊,每個模塊可以是DL黑盒,但各個模塊之間的關係還是一個簡單的規則/流程。這樣只要整體流程設計合理,我們就可以干預每個子模塊,這比干預整個系統成本要更低且更容易泛化。我覺得如果設計合理,這種方式可能還可以降低總模型的訓練成本。
補:談第二代ML應用領域
前面我有一個說法叫【第二代ML應用領域】,這裡解釋一下為什麼這麼叫。
其實,這個主要是從各個領域應用ML技術的時間上來說的,不是從技術上。從上面對ML模型的幾種補丁上來說,似乎和具體ML技術也沒有什麼關係。
但其實你想要做好一個有不錯泛化能力的規則補丁其實是需要對你的業務場景有深刻理解的,也就是所謂的領域經驗。所以也不能算和ML完全無關,畢竟如果你有了領域經驗,那就更容易做出一個更低成本更好效果的ML模型。
遺留問題
如何在給定一個DL模型和需要干涉的case的情況下為其選擇一個適合的干涉方式(選擇在某一層的位置做一個規則補丁),可能這是對於圖像、視頻類領域一個更實用的問題。
推薦閱讀:
※01-深度學習入門課程初體驗
※Learning Explanatory Rules from Noisy Data 閱讀筆記2
※谷歌今日上線基於TensorFlow的機器學習速成課程(免費中文版)
※模型部署
※Google機器學習速總結
TAG:機器學習 |