機器學習著名研究者 pedro domingos 教授寫了篇文章《機器學習那些事》（a few useful things to know about machine learning）。這是一篇極好的文章，首先作者是在機器學習方面有著深厚功底、非常擅長教人的老師，其次內容豐富全面，更何況他只用了 9 頁紙就寫完了。
我們知道，監督機器學習模型能夠從輸入資料中**輸出，但模型構建過程究竟是怎麼一回事呢？所有的機器學習演算法（建模的材料）基本上都由以下三部分組成：
一組可行的模型，有待檢驗
一種測試模型是否好用的方法
一種聰明的方法，只用為數不多的幾次測試就能檢驗模型是否好用
這就像在你家附近找一家好吃的餐館：先選出一些備選來，然後測試那裡的飯是否好吃。不過，第三項要稍微難辦些，你得在不在每家餐館都就餐的前提下，挑選出一家好的餐館。或許你可以看一下選單，或者周圍環境。或者你問一些人。總之，有很多種方法不全部就餐也能作出判斷。最終你選出來的，可能不是最好的一家；選出最好的一家需要花費很多功夫，而且有可能完全沒有必要。你會選出不錯的一家，這樣就行了。
回到機器學習上來，事情會更加複雜：對於真正的機器學習演算法而言，可能的模型數量十分巨大，很多時候甚至是無限的。好在我們已經知道了很多聰明的判別方法，最終能夠找到合適的模型。
而一旦你找到了好的模型，成敗也在接下來的實踐過程之中。我們都希望這個模型也適用於原始資料庫以外的資料，這樣你就能在不清楚目標的時候從輸入中進行**。然而，就連這麼簡單的一點，學習模型失敗的方式也有很多，當然，你也有很多種方式確保它們不會失敗。
domingos 在**中總結了最常見的一些問題。
**的這一節主要講了一定要用樣本以外的資料評估分類器的效能。也就是說，要弄清楚你的模型是不是好用，你至少得用訓練資料以外的資料做一次測試。即使這次測試通過了，要真正弄明白，你最好做幾次（每次都以不同的方式拆分資料）。如果你的資料是按照時間分布的（比如每週銷售額），那麼你最好這樣做測試：用一周以外的資料做訓練，然後用那一周的資料做測試，最好每一周都這樣來一遍。
再怎麼拆分資料做訓練和做測試也不為過。你甚至應當自己想象一些資料，然後**結果，檢驗模型在特定情形下是否可靠。只有這麼做，你才能明白模型是否好用，模型出錯了是錯在什麼地方。
domingos 重點介紹了一種分析模型錯誤的方法，叫做偏置方差分解（bias-variance decomposition），這裡有乙個77頁的 pdf 詳解。
假設你有乙個模型，輸入一些欄位會輸出一些字段，結果沒有你期望中好。你首先想到的是要不要增加一些輸入字段。畢竟，在現有輸入的基礎上，模型得到的資料更多，結果不應該更好嗎？
先別急。這種方法要是你增加的輸入欄位是有用的（能夠很好地**結果）還好，要是你增加的輸入欄位是沒用的，或者資訊冗餘，那麼你將得到乙個比原先還糟糕的模型。原因之一是，你輸入的字段越多，模型發現它們之間存在某種關聯的可能性就越大，而實際上這種關聯並不存在，只是噪音罷了。因此，這種情況下模型就會將原本不重要的輸入字段誤判為很重要，當然效能就比原來的還糟糕了。
在實踐中，這意味著當你增加輸入欄位的時候，你的訓練資料也必須增加，從而抵消輸入字段增多而引起的誤差。
這在機器學習裡也被稱為維度災難（curse of dimensionality），它只是輸入欄位過多而引發的眾多問題裡的其中乙個。你可以通過只選擇那些有關的字段作為輸入解決這個問題，也可以在建模時開放配置面板，取消不大相關的字段。
許多機器學習**都會給出炫酷的數學公式，然後說只要你的訓練集達到一定規模，就能確保模型的錯誤率好過某些值。問題是，這些理論保證往往並沒有用，因為它們保證的值在實踐中根本不會有演算法達到。
我從事機器學習這些年，見過類似的現象。「演算法 x」不好因為它不是神經網路，或者不是支援向量機，或者你能想到的例子。我們的 ceo 曾經說過一家大公司機器學習專案失敗的例子，他們失敗的原因是一位高管認為當時用的分類器比他在大學本科時聽過的一種分類器要差一些。人家是高管，證據不足也只能聽他的，結果就是專案到後期打散重來，浪費公司好幾千萬美元。
這種對演算法的偏見還可能引發更嚴重的後果。現在我們知道了，要看乙個演算法是否適合你的資料，唯一的方法是做測試。沒有先入之見，才能找到最好的答案。
這個話題十分重要，實際上，domingos 將其稱為決定機器學習專案成敗「最重要的因素」。乙個機器學習專案大部分時間都花在特徵工程上面，這句話說得很對。根據我的經驗，70%的時間做特徵工程，20% 用於想出如何評估演算法，只有 10% 花在選擇演算法和微調上面。
那麼，如何做出乙個好的特徵來呢？一條經驗是盡量設計特徵，當某一類值上公升時，整個欄位的值也上公升。不過，通常來說不會發生單一的乙個資料變化就導致學習的容易程度大增。但一般你總有可做的事情。機器學習厲害之處在於，當你了解你手頭的資料，當人和機器順利合作時——人利用知識找出相關的特徵，機器則發揮它擅於優化的特長。
資料是王道。不只是 domingos 這麼說；越來越多的證據表明，解決很多問題時，乙個簡單的機器學習演算法加上龐大的資料量能夠勝過乙個強大的分類器。
很大部分原因是由於，一定你確定好了輸入字段，能夠做的分析就非常有限了。學習模型的計算機演算法能夠做的事情不多，大多數相差並不巨大。因此，演算法跟演算法之間的效能差距通常並不明顯。所以，如果你要好的分類器，你應該把時間花在：①特徵工程，②找到更多高質量的資料。
在這一節，domingos 討論了模型整合的力量。一般來說，在不同的隨機資料集上學習多個分類器能夠建立更強大的模型。這種做法的壞處是會丟失一部分可解釋性；比起單一的一組問答序列，現在每個模型都有乙個序列，最終投票的模型也有乙個序列。不過，若是你的應用非常注重效能，丟失部分可解釋性是值得的。
著名的奧坎姆剃刀原理說：若無必要，勿增實體。如果你想不起來昨天晚上做了什麼，乙個解釋是你被外星人綁架了，它們還在你腦子裡植入了晶元，另乙個解釋是你喝醉了。由於後者更加簡單，因此我們選擇相信後者。
機器學習也一樣，要是有兩個模型都很好地匹配資料，那麼一般會選擇更加簡單的那個。經驗告訴我們，更加簡單的那個模型由於引數少，在樣本資料以外的訓練也會更好，也即過擬合的可能性低。
但這一原則並非任何情況下都適用。很多時候，額外的複雜度會對效能有好處。此外，要說是複雜程度導致了過擬合是不準確的。因此，你可以因為簡單模型規模更小、更容易解釋、適合度更高而選擇它，而不是因為它效能好；判斷模型是否好用的唯一標準是做測試檢測它。
演算法有可能在你資料的基礎上建立乙個好的模型，然而建立乙個好的模型可能需要更多的資料，或者演算法根本找不到好的模型——存在好的模型並不意味著演算法能夠找到這個好的模型。
這是另乙個做特徵工程的好理由：如果演算法找不到好的模型，但你確信好的模型是存在的，那麼你做特徵工程，會讓這個好的模型更容易被演算法找到。
由於常被提起，相關不等於因果似乎已不值得贅述，但 domingos 還是花了一節討論它，可見其重要性。在解釋模型時，不能因為 a 表明 b 就認定 a 導致 b，這一點要尤其當心。
機器學習是十分強大的工具，因此誤用的後果也很嚴重。因此，有必要了解機器學習的原理及其可能存在的陷阱。如果你覺得有找到了乙個好的模型，首先盡全力找出可能的漏洞來，尤其注意過擬合或特徵太多。要是模型表現不如意，也別灰心！特徵工程加上大資料，通往成功的道路比你想的更近。
關於快取你需要知道的
作後端開發的同學，快取是必備技能。這是你不需要花費太多的精力就能顯著提公升服務效能的靈丹妙藥。前提是你得知道如何使用它，這樣才能夠最大限度發揮它的功效，並抑制其 本文將介紹最如何正確的新增和更新快取。這部分將介紹在開始加快取之前我們必須要做的事情。這步非常重要，如果沒弄好，很有可能加了快取反而不如不...
關於棧，你需要知道這些
分別用四個字描述棧和佇列 棧 後進先出 佇列 先進先出 棧 一種特殊的線性表，其只允許在固定的一端進行插入和刪除元素操作。進行資料插入和刪除操作的一端稱為棧頂，另一端稱為棧底。棧中的資料元素遵守後進先出lifo last in first out 的原則。它的三個核心操作 入棧 棧的插入操作叫做進棧...
（1）關於ROS 你需要知道的
ros的版本名稱是按字母順序e f g h i j k l排列的，electric fuerte groovy hydro indigo jade kinetic lunar.ros的fuerte和groovy版本中會有ros create package和rosmake等命令，而hydro及以後都...