閱讀326 返回首頁    go 阿裏雲 go 技術社區[雲棲]


機器學習會產生哪些用戶體驗問題?(機器學習入門第五篇)

本文是機器學習入門教程的第五篇,前四篇分別是:

1.機器學習能為你的業務做什麼?有些事情你肯定猜不到
2.關於機器學習算法 你需要了解的東西
3.如何開發機器學習模型?
4.機器學習團隊中的角色、技能和組織結構技能詳解

我們之前已經討論過“如何使團隊能夠更加有效地運作”這個問題了。下麵,我們來看看如何幫助用戶從機器學習係統中獲益吧。

機器學習模型和結果並不容易解釋

許多機器學習算法都是黑匣子:輸入大量的數據,然後獲得一個以某種神秘方式工作的模型。這使得很難向用戶解釋機器學習的結果。在許多算法中,還存在著交互效應(各種特征互相之間存在著某些關係,不能僅僅通過將每個特征的效果簡單相加來解釋),這使得模型更加難以解釋了。你可以把這個看成是特征之間的複合效應,特征之間以多種奇怪而又複雜並且不為人類所理解的方式結合在一起,整體效應大於各個部分效應的總和。

也就是說,你和你的團隊需要確信機器學習的結果是有道理且解釋得通的。並且,如果你能在超出統計標準的水平之上理解了結果,那解釋起來就更容易了。這也有助於確定未覆蓋的情況或結果無意義的領域,正如我們模型構建階段所看到的那樣。這對用戶來說更為重要,在很多時候,他們需要得到一個解釋才會相信你的結果。即使你的結果是100%準確的,也不會有人相信,所以你需要把呈現出來的結果向用戶解釋。在極端情況下,你甚至還可能有法律上的義務去解釋結果,比如拒絕貸款申請。在法律上,你必須給予客戶拒絕的理由。由於增加了複雜性,模型不會100%準確,即使有80%的準確性也是相當不錯的了。所以在某些情況下,用戶會想了解實際上是錯誤的結果!

我們所麵臨的挑戰並不僅限於針對外部客戶的模型,同時也要獲得內部用戶的信任。即使內部團隊支持你,他們也不太可能采用他們自己無法理解或者不信任的結果。我曾看到過一些案例,團隊傾向於使用易於理解的規則引擎,而不使用可能會產生更好結果的機器學習模型,隻是因為規則引擎是可以解釋的:人們寫出規則,這樣,大家就能夠理解它們了。

在構建模型之前,這個問題不能忽略。我們需要提前考慮用戶可能希望看到的模型數據和組件,考慮如何讓呈現出來的結果得到用戶的信任。這可能會讓原先構建模型的方法發生改變,還有助於防止出現你有答案而無法向用戶解釋的情況。

可解釋性建模

對可解釋性的需求可能會影響到模型構建的方式。假設我們正在基於Marc Andreessen框架為投資者建立一個評估創業公司的平台,任何一個創業公司都具備三個核心要素,分別是團隊、產品和市場。現在,Andreessen認為,市場是最重要的因素,但其他一些投資者認為,一個好的團隊可以找到將小市場培育長大的方法,所以團隊更重要。你可以將創業公司的這三個維度結合起來計算出一個總的評分或者成功的概率,並給出一些你認為正確的“絕對真理”,但投資者未必會對此感興趣。更具體一點說,投資者可能想了解一下公司在其他某些方麵表現得怎麼樣。除了模型之外,你更需要讓他們看到這個。這裏有幾種不同的方法:

  • 為市場、產品和團隊構建三個獨立模型,使用這三個模型在單一的維度上評估公司。然後構建一個將所有這些特征(以及潛在的其他特征)結合在一起的綜合模型。這樣,投資者既可以看到總體結果,也可以看到他們最關心的某個具體維度。

  • 構建聚合模型,從中找出一種提取最適合於每個維度特征的方法,並讓用戶感覺到它們的價值和重要性,或者顯示與每個維度一致的數據點,以樹立用戶對結果的信心。

正確的方法在很大程度上取決於問題所屬的領域、可用的數據、建模方法等,但在進入模型的原型設計之前,應該進行充分討論和評估。

向用戶呈現結果

在確定如何顯示結果的時候,我們的目標是要讓結果清晰、可信,並且最重要的是,可行。這個沒有現成的指導手冊,我在這裏將介紹一些方法和注意事項,希望能為你提供一些思路。

  • 回溯。這種方法是將曆史數據插入到模型中使其產生過去的預測,這樣可以根據已知值對預測進行驗證。例如,如果你建立了一個用N-1年的數據來預測第N年值的模型,那麼你可以將兩年前的數據插入到模型中,看看一年前的預測是否正確,因為一年前的信息是可以獲取到的。這是測試模型的潛在方法。由於曆史數據存在是否完整的問題,在沒有某些簡化假設或模型調整的情況下,模型要獲得足夠的數據覆蓋是有難度的(例如,如果模型使用了來自社交網絡的數據,那麼你不能回溯到一個社交網絡還不存在的時間點)。對於某些模型,例如強化學習模型,這也是不可行的。

  • 解釋你的方法和輸入。隻需告訴用戶在模型中用到的數據類型,通過讓他們看到決策是基於相同類型的變量來建立信任,如果用戶不得不做出決定,他們就會考慮使用這些數據。在Andreessen對初創公司評估案例中,對市場評估部分的簡要說明是這樣的:“一家初創公司的市場潛力要考慮到市場上同類公司的數量和總的銷售額、在全球範圍內這個市場在過去5年的增長情況、新產品發布的數量、在該領域與宏觀經濟趨勢中的並購活動。” 雖然這不是一個完整的解釋,它確實讓用戶瞥見了這個黑匣子。如果你引入了一個新的評分,那麼這絕對是必要的,原因如前所述。

  • 公開一些基礎數據。這種方法是用戶最容易理解和相信的,因為他們親眼看到了數據。但這設計起來並不是最簡單的,它存在幾個缺點:你需要公開那些可能不希望或無法公開的數據(例如,由於法律方麵的約束,數據是專有的),在某些情況下,數據與結論可能並不一致(建模與概率有關),或者數據可能甚至不存在;該算法不需要對其評估的所有實體進行全麵的數據覆蓋。

  • 簡化並僅顯示指定的結果,以便於決策。不出所料,亞馬遜對於某些產品的推薦做得很好。我搜索了一個護膝套,看看下麵我從穀歌搜索結果中找到的頁麵。

亞馬遜並沒有給我30個類似的產品讓我來選擇,它知道每個相關產品確切的購買概率,所以給了我很簡單的兩個選擇:最便宜的商品,以及最暢銷且評價最高的商品。我不知道他們挑選產品的標準,以及判斷與我選擇的產品是否匹配的標準。在這一點上,亞馬遜讓我能夠輕鬆地做出決定,我無需關心上麵那些細節問題。


示例:從商品搜索跳轉過來的頁麵

  • 定義一個新指標。你應該考慮的一個問題是你是否創建了一個新的指標(一種新的“評分”)或者預測一個易於理解的指標:你可以構建模型來預測現有的指標(例如公司的收入、房屋的價值等等);或者,你可以創建一個體現某個概念但尚不具備可被接受的指標的評分,以便按照這個概念(例如“針對某個行業的FICO評分”)實現對實體的排名。這個決定很大程度上取決於是否存在一個單一的度量來表達商業目標,或者這是一個需要幾個因素權衡的混合體。例如,如果我們要評估商業房地產資產對零售業使用的吸引力,我們可能希望建立一個“零售健康評分”,其中包括幾個組成部分,比如每平方英尺的銷售額、每平方英尺總成本,以及區域品牌價值貢獻等等。在這種情況下,由於沒有包含這些指標的單一指標,因此你可能需要為每個組成部分單獨進行建模,然後再通過某種類型的相對權重將它們組合在一起。選擇新的評分時,你應該重點考慮一下你可能需要花更多的時間和精力來教你的用戶。

  • 精確度並不總是很重要。很多模型生成的結果是一個非常精確的數字。如果你向用戶展示如此精確的數字,那麼用戶就可能遇到比想象中更大的風險。預計價格為583,790美元的房屋並不一定比580,625美元的房屋更貴,誤差幅度可能遠大於3000美元。有時,向客戶展示過於精確的數字會適得其反。給用戶的結果最好不要是很精確的數字,可以考慮用範圍、等級或其他一些不是那麼精確的數字來表示。

  • 有策略地提供對原始數據的訪問。除了展示風險模型的結果之外,借貸公司還提供了它的原始數據,供其他人在這基礎上構建自己的機器學習模型。這個方法與你有關嗎?它能促進部分業務的增長嗎?除了提供潛在的貨幣選擇之外,這種方法還有助於機器學習研究界加快創新的步伐。例如,Microsoft的COCOCIFAR數據集的可用性已經極大地提高了圖像分類能力。

重申一下,用戶體驗的選擇在很大程度上取決於主題、產品和用戶需求。上述任何選項都不會與你的產品無關。如果用戶無法理解,即使是最好的模式也毫無用處。

一個討厭但又很重要的注意事項

可解釋性是機器學習研究不斷發展的領域,研究人員正在積極尋求使模型不再是黑匣子的方法。這裏有一個例子,LIME:一個針對分類器模型的“解釋器”,它用於在模型構建完成後以人類可以理解的方式來解釋結果。

另一個研究領域是Layer-Wise Relevance Propagation(LRP),一種“解構”神經網絡預測的技術,以此來可視化並理解單個輸入變量對預測的貢獻。

產品經理應注意的工程問題

盡管穩固的係統架構主要是由工程團隊負責設計的,但業務需求也會影響到機器學習係統,從而將一個偉大的係統變得糟。作為一個項目經理,你直接跟工程團隊討論的越多,就越有可能最終構建出滿足業務需要的係統。雖然下麵這個列表並不完整,但應該會讓你產生一種相見恨晚的感覺。

  • 對實時的要求。算法的結果可以提前計算出來嗎,還是需要實時計算?當你獲取到新的數據,或者用戶輸入了特定信息或執行某些操作時,模型是否需要立即生成反映新數據的結果?實時係統的架構與可以處理脫機數據的係統架構相差很大。

  • 數據和模型的依賴關係。你的係統可能包含多個模型,其中一個模型的輸出是另一個模型的輸入。當一個模型的輸出發生變化時,是否需要重新運行其他的模型呢?當添加或修改數據時,哪些模型需要重新運行(有時甚至需要重新訓練)?應該以多快的速度進行更新,可接受的SLA是什麼呢?

  • 數據收集的頻率。數據收集和累積的速率會影響流水線的設計和存儲方法的選擇。數據收集的頻率取決於數據實際變化的頻率、數據變化的重要性以及獲取數據的成本(如果數據需要購買的話,就要考慮支付成本,以及檢索、處理和存儲成本)。例如,如果你正在收集有關地震的數據,數據的變化可能不會很頻繁,但一旦數據發生改變,就需要立即獲取到;如果你正在收集有關餐廳開門營業和關門休市的數據,那麼這個數據可能就會比地震數據變化得更頻繁一些,即使你可能早幾天或者晚幾天發現數據的變化,那也不會對產品的整體效用產生重要的影響。

  • 數據收集的方法。如何收集數據,批量還是流式傳輸?是推還是拉?對實時的要求使得數據收集進一步的複雜化。係統可能需要支持多種數據收集或上傳方法,例如,API、文件上傳等等。它需要模塊化以支持所有必需的方法,並將數據從數據處理中分離出來(這是一個很好的軟件工程設計原則)。

文章原標題《Machine Learning is Very Much a UX Problem》,作者:Yael Gavish,譯者:夏天,審校:主題曲哥哥。

文章為簡譯,更為詳細的你容,請查看原文

最後更新:2017-08-24 16:32:42

  上一篇:go  B2B網站教你網站如何快速收錄
  下一篇:go  IDC:阿裏雲安全能力和IaaS市場份額雙項領先