《Arduino家居安全系統建構實戰》——1.7 我們學到了什麼

本節書摘來異步社群《機器學習項目開發實戰》一書中的第1章，第1.7節，作者：【美】mathias brandewinder（馬蒂亞斯·布蘭德溫德爾），更多章節内容可以通路雲栖社群“異步社群”公衆号檢視

我們在本章中介紹了許多基礎知識！在機器學習方面，你現在已經熟悉了一些關鍵概念和方法學。如果你是f#的新手，現在也已經編寫了第一段f#代碼！

下面回顧一些要點，先從機器學習方面開始。

首先，我們讨論了交叉驗證——使用不同資料集進行訓練和驗證，留出某些資料評估預測模型品質的過程。這從許多方面看都是關鍵的過程。首先，它為你提供一個基準——指導試驗的“真實狀态”。沒有驗證集，就無法判斷特定模型是否比另一個模型好。交叉驗證可以科學地計量品質，它的作用類似于自動化測試套件，可以在開發工作偏離方向時提出警告。

建立了交叉驗證機制，就可以在可量化的基礎上試驗、選擇模型或者方向。反複嘗試方法是“進行機器學習”的關鍵部分。沒有一種方法能夠事先知道特定的方法是否有效，是以必須在資料上嘗試，自行觀察，是以為成功做好準備，接受“可複制研究”的思路非常重要。盡可能用腳本使你的研究過程自動化，大量使用源代碼控制，以便在任何時點、沒有人工幹預的情況下複制模型的每一步。總而言之，做好準備，使自己能夠輕松地更改和運作代碼。

在數字識别器的探索中，我們發現所使用的距離中的小小變化就能顯著地改進模型，大部分（所有？）機器學習模型的核心中都有一個距離函數。所有學習過程歸根結底都是計算機找出為特定問題搭配已知資料的最佳方式的嘗試——“最佳搭配”的定義完全封裝在距離函數中。

在某種程度上，距離函數的作用是利用數學方法，将你的目标從人類了解的形式轉換成機器了解的語句。距離函數也常常被稱作代價函數，從代價上考慮更多地強調了“壞”解決方案之是以不好的原因——所招緻的懲罰，幫助我們避免選擇不好的解決方案。

在我的經驗中，花時間思考代價函數總是值得的。不管使用的算法有多巧妙，如果代價函數有缺陷，結果就很糟糕。想象一個包含兩個計量值的個人資料集：以英尺為機關的身高和以磅為機關的體重。如果我們按照圖像識别中使用的方法，在資料集中搜尋“最相似的人”，就會發生這樣的情況：身高的範圍通常在5～6英尺（1英尺0.3048米）之間，而體重的範圍更廣，差别更大，例如100～200磅（1磅=0.4536千克）。是以，直接根據兩個計量值之間的內插補點計算距離實際上将忽略身高的差别，因為1英尺的差别等價于1磅的差别。解決這個問題的方法之一是轉換所有身體特征，確定它們處于一緻的比例——這一過程稱作“規格化”，是後面将要詳細讨論的一個主題。幸運的是，所有像素都在相同的标度上編碼，在本章中可以忽略這個問題，但是我希望這個“距離産生錯誤”的例子能夠讓你認識到，為什麼距離函數需要深思熟慮！

這也是正确的數學定義真正起作用的情況之一。如果你翻起在學校時的數學筆記，就會看到距離函數（數學家們有時候稱之為“度量标準”）由幾個屬性定義：

在本章中我們隻關注兩種距離，但是滿足上述屬性的函數多種多樣，每一種都以不同的方式定義了相似性。是以，模型中的代價函數不需要滿足所有屬性，但是一般來說，如果不滿足某些屬性，你應該問問自己可能會是以引起什麼意外的副作用。例如，在曼哈頓距離的第一個例子中，如果我們忽略了絕對值，就明顯地違反了規則1（距離非負）和規則3（對稱性）。在某些情況下，随意使用不為度量名額的函數有充足的理由，但是發生這種情況時，應該多花一點時間思考可能出現問題的地方！

最後，我希望強調的是，有效的模型并不一定很複雜！不管在c#還是f#中，兩個分類器都很小，使用的是相當簡單的數學方法。當然，有些複雜模型也能提供驚豔的結果，但是如果能用容易了解和修改的簡單模型得到相同的結果，那麼為什麼不省點事呢？

這一原則稱作“奧卡姆剃刀”，名稱來源于中世紀哲學家“奧卡姆的威廉”。奧卡姆剃刀遵循經濟原理。試圖解釋某一事物時，在多個可能合适的模型中選擇最簡單的一個。隻有在簡單的解釋無法奏效時，才選擇複雜的模型。

同理，我們首先實施“可能有效的最簡方法”，我很鼓勵你遵循這一方法。如果不這樣做，可能會發生這樣的情況：你開始實施幾個可能有效的方法，它們激發出新的思路，是以很快你将有許多不成熟的原型，在叢林中越陷越深，而沒有清晰的過程或者方法。突然之間，你将意識到自己已經為編碼花費了幾周，卻還沒有确定任何有效的方法或者前進的方向。這不是一種好的感覺。管理自己的時間，花費一天（或者一周、一小時——任何對你的問題來說切合實際的時間）用能夠想到的最蠢、最簡單的預測模型建立一個端到端模型。這個模型可能已經足夠好了，這樣的情況下就不會浪費任何時間。如果它不夠好，此時你已經有了合适的機制，準備了資料內建和交叉驗證，也很有可能已經發現了資料集中存在的意外問題。你将從合适的位置進入叢林。

如果這是你第一次遭遇f#，開始時可能會覺得奇怪：我為什麼介紹那種語言，而不堅持使用c#? 我希望書中的例子清楚地說明了原因！在我看來，c#雖然是一種很出色的語言，但是f#和機器學習及資料探索的搭配簡直不可思議！在接下來的幾章中将看到f#的更多特性，但是我希望這些理由在本章中就已經很清晰。

首先，f#的互動執行和腳本環境絕對可以節約時間。在開發機器學習模型時，快速試驗、更改代碼、檢視效果是至關重要的，是以需要一個腳本環境。我的典型f#工作流是在每天開始時将資料加載到互動執行環境中。我不需要再次加載它們——資料已經在記憶體中，可以自由地擺弄模型。相比之下，在c#中測試新思路迫使我重建代碼并重新加載資料，這最終會成為一個巨大的時間陷阱。

而且，f#的一些語言特性使其極适合于資料操縱。它聚焦于函數而非對象，擅長将函數應用到資料，以任何需要的方式組成函數。管道向前操作符|>對組合這些轉換很友善，建立了一個管道，以非常容易了解的方式表現資料轉換工作流。結合将資料打包為元組和用模式比對解包元組的能力，以及array、list和seq子產品中大量的内建函數，就可以得到和linq一樣的增強功能，以任何方式轉換和改造資料。