來源：TensorFlow

本文約17800字，建議閱讀10+分鐘。

本文件旨在幫助已掌握機器學習基礎知識的人員從 Google 機器學習的最佳實踐中受益。

本文件旨在幫助已掌握機器學習基礎知識的人員從 Google 機器學習的最佳實踐中受益。它介紹了一種機器學習樣式，類似於 Google C++ 樣式指南和其他常用的實用程式設計指南。如果您學習過機器學習方面的課程，或者擁有機器學習模型的構建或開發經驗，則具備閱讀本文件所必需的背景知識。

術語

在我們討論有效的機器學習的過程中，會反覆提到下列術語：

• 例項：要對其進行預測的事物。例如，例項可以是一個網頁，您希望將其分類為"與貓相關"或"與貓無關"。

• 標籤：預測任務的答案，它可以是由機器學習系統生成的答案，也可以是訓練資料中提供的正確答案。例如，某個網頁的標籤可能是"與貓相關"。

• 特徵：預測任務中使用的例項的屬性。例如，某個網頁可能具有"包含字詞'貓'"這一特徵。

• 特徵列：一組相關特徵，例如使用者可能居住的所有國家/地區的集合。樣本的特徵列中可能包含一個或多個特徵。"特徵列"是 Google 專用的術語。特徵列在 Yahoo/Microsoft 使用的 VM 系統中被稱為"名稱空間"或場。

• 樣本：一個例項（及其特徵）和一個標籤。

• 模型：預測任務的統計表示法。您使用樣本訓練一個模型，然後使用該模型進行預測。

• 指標：您關心的一個數值。也許（但不一定）可以直接得到優化。

• 目標：演算法嘗試優化的一種指標。

• 管道：機器學習演算法的基礎架構。管道包括從前端收集資料、將資料放入訓練資料檔案、訓練一個或多個模型以及將模型運用到生產環境。

• 點選率：點選廣告中的連結的網頁訪問者所佔的百分比。

概覽

要打造優質的產品：

請把自己看成是一位出色的工程師，而不是一位機器學習專家。

實際上，您將面臨的大部分問題都是工程問題。即使在使用出色的機器學習專家掌握的所有資源的情況下，大多數收穫也是由合適的特徵（而非精確的機器學習演算法）帶來的。所以，進行機器學習的基本方法是：

1. 確保管道從頭到尾都穩固可靠。

2. 從制定合理的目標開始。

3. 以簡單的方式新增常識性特徵。

4. 確保管道始終穩固可靠。

上述方法將在長時間內取得很好的效果。只要您仍然可以通過某種簡單的技巧取得進展，就不應該偏離上述方法。增加複雜性會減緩未來版本的釋出。

當您充分利用了所有的簡單技巧，或許就到了探索機器學習最前沿技術的時候了。請參閱第三階段的"機器學習專案"部分。

本文件結構如下：

1. 第一部分可幫助您瞭解構建機器學習系統的時機是否已經成熟。

2. 第二部分介紹瞭如何部署第一個管道。

3. 第三部分介紹了在向管道新增新特徵時如何進行釋出和迭代、如何評估模型，以及如何應對訓練-應用偏差。

4. 最後一部分介紹了當您達到穩定階段時該怎麼做。

5. 之後是相關資源列表和附錄，附錄針對多次作為示例在本文件中提及的系統，提供了一些背景資訊。

在進行機器學習之前

第 1 條規則：不要害怕釋出未採用機器學習技術的產品。

機器學習技術很酷，但它需要資料。從理論上講，您可以採用來自其他問題的資料，然後針對新產品調整模型，但其效果很可能不如基本的啟發式演算法。如果您認為機器學習技術能為您帶來 100% 的提升，那麼啟發式演算法可為您帶來 50% 的提升。

例如，如果您要對應用市場中的應用進行排名，則可以將安裝率或安裝次數作為啟發式演算法指標。如果您要檢測垃圾郵件，則可以濾除以前傳送過垃圾郵件的釋出商。此外，也不要害怕手動修改。如果您需要對聯絡人進行排名，可以按使用聯絡人的時間順序由近及遠對其排序（或按字母順序排序）。如果您的產品並非必須使用機器學習技術，則在獲得足夠的資料之前，請勿使用該技術。

第 2 條規則：首先設計並實現指標。

在正式確定機器學習系統的功能之前，儘可能在當前系統中跟蹤指標的值。這樣做的原因如下：

• 提前行動有助於更輕鬆地從系統的使用者獲得授權。

• 如果您認為將來可能需要考慮某個方面，最好立即開始收集相關歷史資料。

• 如果您在設計系統時考慮到指標測量，將來會省下很多力氣。具體而言，您不希望自己以後在日誌中苦苦查詢字串以測量指標！

• 您將發現哪些內容發生了變化以及哪些內容始終未變。例如，假設您希望直接優化單日活躍使用者數。但是，在早期操縱系統的過程中，您可能會發現使用者體驗的顯著改變並沒有使該指標發生明顯變化。

Google+ 團隊會衡量每次閱讀的展開次數、 轉發次數、+1 次數、評論次數，以及每位使用者的評論次數、轉發次數等，然後在應用模型時利用這些資料來衡量帖子的質量。另請注意，實驗框架非常重要，您必須在實驗框架中將使用者分組為多個分桶，並按實驗彙總統計資訊。 請參閱第 12 條規則。

通過以更加自由的方式收集指標，您可以更加全面地瞭解您的系統。發現問題了？新增指標對其進行跟蹤！對上個版本中發生的一些量變激動不已？新增指標對其進行跟蹤！

第 3 條規則：選擇機器學習技術而非複雜的啟發式演算法。

簡單的啟發式演算法有利於推出產品。但複雜的啟發式演算法難以維護。當您獲得足夠的資料並基本確定自己要嘗試實現的目標後，請考慮使用機器學習技術。與大多數軟體工程任務一樣，您需要不斷更新方法（無論是啟發式演算法還是機器學習模型），而且您會發現機器學習模型更易於更新和維護（請參閱第 16 條規則）。

機器學習第一階段：您的第一個管道

重點關注第一個管道的系統基礎架構。雖然展望您將要進行的創新性機器學習的方方面面是一件很有趣的事，但如果您不先確認管道的可靠性，則很難弄清楚所發生的情況。

第 4 條規則：確保第一個模型簡單易用，並正確實施基礎架構。

第一個模型可以最有效地提升您的產品質量，因此不需要花哨，簡單易用即可。但是，您會遇到很多預料之外的基礎架構問題。在公開推出您精心構建的新機器學習系統之前，您必須確定以下幾點：

• 如何為您的學習演算法獲取樣本。

• 初步確定對於您的系統來說，"好"和"壞"的定義是什麼。

• 如何將模型整合到應用中。您可以線上應用模型，也可以離線使用樣本對模型進行預計算，並將結果儲存在表格中。例如，您可能需要對網頁進行預分類並將結果儲存在表格中，但也可能需要線上對聊天訊息進行分類。

選擇簡單的特徵可以更輕鬆地確保：

• 將這些特徵正確應用於您的學習演算法。

• 模型學習出合理的權重。

• 將這些特徵正確應用於伺服器端。

當您有了能可靠做到上述三點的系統時，則表示您已完成大部分工作。簡單的模型可為您提供基準指標和基準行為，您可以利用這些指標和行為測試更復雜的模型。某些團隊以"中性"作為首次釋出的目標 - 在首次釋出時明確淡化機器學習成果，以避免分心。

第 5 條規則：撇開機器學習，單獨測試基礎架構。

確保基礎架構可測試，且對系統的學習部分進行封裝，以便測試這些部分之外的方方面面。具體而言：

• 測試資料匯入演算法的效果。檢查應填充的特徵列是否已填充。在隱私權許可的情況下，手動檢查輸入到訓練演算法的資料。如果可能的話，檢視管道中的統計資訊，並與在其他地方處理的相同資料的統計資訊進行比較。

• 測試從訓練演算法得出模型的效果。確保訓練環境中的模型與應用環境中的模型給出的分數相同（請參閱第 37 條規則）。

機器學習具有不可預測性，因此要有用於訓練環境和應用環境中建立樣本的程式碼的測試；並確保您可以在應用期間載入和使用固定模型。此外，瞭解您的資料至關重要：請參閱分析大型複雜資料集的實用建議。

第 6 條規則：複製管道時注意丟棄的資料。

通常，我們通過複製現有管道來建立新管道（即貨物崇拜程式設計），且舊管道會丟棄一些新管道需要的資料。例如，Google+ 熱門資訊的管道會丟棄時間較早的帖子（因為它會不斷嘗試對最新的帖子進行排名）。此管道被複制用於 Google+ 資訊流，在資訊流中，時間較早的帖子仍然有意義，但舊管道仍會丟棄它們。另一種常見模式是僅記錄使用者看到的資料。因此，如果我們想要對使用者看不到特定帖子的原因進行建模，此類資料就毫無用處，因為管道已丟棄所有負分類樣本。Play 中也曾出現過類似的問題。在處理 Play 應用首頁時，建立了一個新管道，其中還包含來自 Play 遊戲著陸頁的樣本，但無任何特徵可區分各個樣本的來源。

第 7 條規則：將啟發式演算法轉變為特徵或在外部處理它們。

通常，機器學習嘗試解決的問題並不是全新的問題。有一個現有的系統，它可用於排名、分類，或解決您正嘗試解決的任何問題。這意味著有多種規則和啟發式演算法。使用機器學習進行調整後，此類啟發式演算法可為您提供便利。 您應該挖掘自己的啟發式演算法，瞭解它們所包含的任何資訊，原因有以下兩點。首先，向機器學習系統的過渡會更平穩。其次，這些規則通常包含大量您不願意丟棄的關於系統的直覺資訊。您可以通過以下四種方法使用現有啟發式演算法：

• 使用啟發式演算法進行預處理。如果特徵非常好，則可以選擇執行此操作。例如，在垃圾郵件過濾器中，如果發件人已被列入黑名單，則不要試圖重新學習"已列入黑名單"的含義。遮蔽該郵件即可。這種方法最適合在二元分類任務中使用。

• 建立特徵。直接通過啟發式演算法建立特徵是一種很好的做法。例如，如果您使用啟發式演算法來計算查詢結果的相關性分數，則可以將此分數納為一個特徵的值。您日後可能想要使用機器學習技術調整該值（例如，將該值轉換為一個有限離散值組中的一個，或與其他特徵相組合），但是首先請使用啟發式演算法生成的原始值。

• 挖掘啟發式演算法的原始輸入。如果某個應用啟發式演算法結合了安裝次數、文字中的字元數以及星期值，考慮將這些內容拆分開來，並作為輸入單獨提供給學習演算法。部分適用於整合學習的技巧也適用於此（請參閱第 40 條規則）。

• 修改標籤。當您感覺啟發式演算法會獲取當前標籤中未包含的資訊時，可以選擇進行此操作。例如，如果您正在嘗試最大程度地增加下載次數，但同時也想要優質的內容，則可能的解決方案是用標籤乘以應用獲得的平均星數。您可以非常靈活地修改標籤。請參閱"您的第一個目標"。

在機器學習系統中使用啟發式演算法時，請務必留意是否會帶來額外的複雜性。在新的機器學習演算法中使用舊啟發式演算法有助於實現平穩過渡，但思考下是否有可以達到相同效果的更簡單的方法。

監控

在一般情況下，請實行良好的警報安全機制，例如設計解決警報的步驟以及提供"資訊中心"頁面。

第 8 條規則：瞭解您的系統對新鮮程度的要求。

如果您使用一天前的模型，效果會降低多少？一週前的模型呢？一個季度前的模型呢？此類訊息有助於您瞭解需要優先監控哪些方面。如果一天不更新模型會對您的產品質量產生嚴重影響，則最好讓工程師持續觀察相關情況。大多數廣告投放系統每天都有新廣告要處理，並且必須每天更新。例如，如果不更新 Google Play 搜尋的機器學習模型，則不到一個月便會產生負面影響。Google+ 熱門資訊的某些模型中沒有帖子識別符號，因此無需經常匯出這些模型。其他具有帖子識別符號的模型的更新頻率要高得多。另請注意，新鮮程度會隨著時間而改變，尤其是在向模型中新增特徵列或從中移除特徵列時。

第 9 條規則：先檢測問題，然後再匯出模型。

很多機器學習系統都會經歷匯出模型以應用模型的階段。如果匯出的模型存在問題，則是面向使用者的問題。

在匯出模型之前，請進行健全性檢查。具體而言，確保模型在處理預留資料方面表現合理。或者說，如果您一直認為資料存在問題，請不要匯出模型。很多經常部署模型的團隊在匯出模型之前，會先檢查 ROC 曲線下面積（簡稱 AUC）。尚未匯出的模型存在問題時，需要傳送電子郵件提醒；但面向使用者的模型出現問題時，可能需要通過一個頁面進行宣佈。 因此，最好先等待檢查完畢並確保萬無一失後再匯出模型，以免對使用者造成影響。

第 10 條規則：注意隱藏的問題。

相比其他型別的系統，這種問題更常見於機器學習系統。假設關聯的特定表格不再更新，那麼，機器學習系統會進行相應調整，其行為仍然會相當好，但會逐漸變糟。有時，您會發現有些表格已有幾個月未更新，只需重新整理一下，就可以獲得比相應季度做出的所有其他改進都更有效的效果提升！特徵的覆蓋率可能會因實現變化而發生改變：例如，某個特徵列可能在 90% 的樣本中得到填充，但該比率突然下降到 60%。Google Play 曾有一個過時 6 個月的表格，但僅重新整理了一下該表格，安裝率就提升了 2%。如果您對資料的統計資訊進行跟蹤，並不時地手動檢查資料，就可以減少此類失敗。

第 11 條規則：提供特徵列的所有者及相關文件。

如果系統很大，且有很多特徵列，則需要知道每個特徵列的建立者或維護者。如果您發現瞭解某個特徵列的人要離職，請確保有人知道相關資訊。儘管很多特徵列都有說明性名稱，但針對特徵的含義、來源以及預計提供幫助的方式提供更詳細的說明，是一種不錯的做法。

您的第一個目標

您會關注很多有關係統的指標或測量結果，但通常只能為您的機器學習演算法指定一個目標，即您的演算法"嘗試"優化的數值。 在這裡，我介紹一下目標和指標有何區別：指標是指您的系統報告的任意數字，可能重要，也可能不重要。另請參閱第 2 條規則。

第 12 條規則：選擇直接優化哪個目標時，不要想太多。

您想賺錢，想讓使用者滿意，想讓世界變得更美好。您關注的指標有很多，而且您應該對所有這些指標進行測量（請參閱第 2 條規則）。不過，在早期的機器學習過程中，您會發現這些指標都呈上升趨勢，甚至那些您沒有選擇直接優化的指標也是如此。例如，假設您關注點選次數和使用者在網站上停留的時間。如果您優化點選次數，則使用者在網站上停留的時間很可能也會增加。

所以，當您仍然可以輕鬆增加所有指標時，保持簡單，不要過多考慮如何在不同的指標間實現平衡。但不要過度使用此規則：不要將您的目標與系統最終的執行狀況相混淆（請參閱第 39 條規則）。此外，如果您發現自己增大了直接優化的指標，但決定不釋出系統，則可能需要修改某些目標。

第 13 條規則：為您的第一個目標選擇一個可觀察且可歸因的簡單指標。

您往往並不知道真正的目標是什麼。您以為自己知道，但當您盯著資料，對舊系統和新的機器學習系統進行對比分析時，您發現自己想調整目標。此外，團隊的不同成員通常無法就什麼是真正的目標達成一致意見。機器學習目標應是滿足以下條件的某種目標：易於測量且是"真正的"目標的代理。實際上，通常沒有"真正的"目標（請參閱第 39 條規則）。因此，請對簡單的機器學習目標進行訓練，並考慮在頂部新增一個"策略層"，以便您能夠新增其他邏輯（最好是非常簡單的邏輯）來進行最終排名。

要進行建模，最簡單的指標是可直接觀察到且可歸因到系統操作的使用者行為：

• 使用者是否點選了此已排名連結？

• 使用者是否下載了此已排名物件？

• 使用者是否轉發/回覆/使用電子郵件傳送了此已排名物件？

• 使用者是否評價了此已排名物件？

• 使用者是否將此顯示的物件標記為了垃圾郵件/色情內容/攻擊性內容？

避免一開始對間接影響進行建模：

• 使用者第二天訪問網站了嗎？

• 使用者在網站上停留了多長時間？

• 每日活躍使用者數有多少？

其實，間接影響可成為出色的指標，可以在 A/B 測試和釋出決策期間使用。

最後，不要試圖讓機器學習系統弄清楚以下問題：

• 使用者在使用產品時是否感到滿意？

• 使用者是否對使用體驗感到滿意？

• 產品是否提升了使用者的整體滿意度？

• 這會對公司的整體執行狀況產生什麼樣的影響？

所有這些都很重要，但也極難衡量。請改為使用代理指標：如果使用者感到滿意，他們會在網站上停留更長時間。如果使用者感到滿意，他們明天會再次訪問網站。就滿意度和公司執行狀況而言，需要進行人為判斷，以便將任意機器學習目標與您銷售的產品的性質和業務計劃關聯起來。

第 14 條規則：從可解釋的模型著手可更輕鬆地進行除錯。

線性迴歸、邏輯迴歸和泊松迴歸均由概率模型直接推動。每個預測都可看作是一個概率或預期值。這樣一來，相較於使用目標（0-1 損失、各種合頁損失函式等）以嘗試直接優化分類準確度或對效果進行排名的模型，這種模型更易於進行除錯。例如，如果在訓練中得出的概率與採用並排分析方式或通過檢查生產系統的方式預測的概率之間存在偏差，則表明存在問題。

例如，線上性迴歸、邏輯迴歸或泊松迴歸中，有一部分平均預測期望值等於平均標籤值（一階矩校準，或只是校準）的資料。假設您沒有正則化且演算法已收斂，那麼理論上即是如此，實際上也是差不多這種情形。如果您有一個特徵，對於每個樣本來說，其值要麼是 0，要麼是 1，則會校準 3 個特徵值為 1 的樣本集。此外，如果您有一個特徵，對於每個樣本來說，其值均為 1，則會校準所有樣本集。

藉助簡單的模型，您可以更輕鬆地處理反饋環（請參閱第 36 條規則）。通常情況下，我們會根據這些概率預測來做出決策；例如，以期望值（點選概率/下載概率等）為標準，按降序對帖子進行排名。 但是，請注意，當選擇要使用的模型時，您的決定比模型給出的資料概率更為重要（請參閱第 27 條規則）。

第 15 條規則：在策略層中區分垃圾內容過濾和質量排名。

質量排名是一門藝術，但垃圾內容過濾就像一場戰爭。對於使用您系統的使用者來說，您使用哪些訊號來確定高質量帖子將變得顯而易見，而且這些使用者會調整自己的帖子，使其具有高質量帖子的屬性。因此，您的質量排名應側重於對誠實發布的內容進行排名。您不應該因為質量排名學習器將垃圾內容排在前列而對其應用折扣。同樣，"少兒不宜"的內容也不應該在質量排名中進行處理。 垃圾內容過濾則另當別論。您必須明白，需要生成的特徵會不斷變化。通常情況下，您會在系統中設定一些明顯的規則（如果一個帖子收到三次以上的垃圾內容舉報，請勿檢索該帖子等等）。所有學習模型都必須至少每天更新。內容創作者的聲譽會發揮很大作用。

在某個層級，必須將這兩個系統的輸出整合在一起。請注意，與過濾電子郵件中的垃圾郵件相比，在過濾搜尋結果中的垃圾內容時，可能應該更加主動。這種說法的前提是您沒有正則化且演算法已收斂。一般來說大致是這樣。此外，從質量分類器的訓練資料中移除垃圾內容是一種標準做法。

機器學習第二階段：特徵工程

在機器學習系統生命週期的第一階段，重要的問題涉及以下三個方面：將訓練資料匯入學習系統、對任何感興趣的指標進行測量，以及構建應用基礎架構。當您構建了一個端到端的可穩定執行的系統，並且制定了系統測試和單元測試後，就可以進入第二階段了。

第二階段的很多目標很容易實現，且有很多明顯的特徵可匯入系統。因此，機器學習的第二階段涉及匯入儘可能多的特徵，並以直觀的方式將它們組合起來。在這一階段，所有的指標應該仍然呈上升趨勢，您將會多次釋出系統，並且非常適合安排多名工程師，以便整合建立真正出色的學習系統所需的所有資料。

第 16 條規則：制定釋出和迭代模型計劃。

不要指望您現在正在構建的模型會是您將要釋出的最後一個模型，也不要指望您會停止釋出模型。因此，請考慮此次釋出中增加的複雜性是否會減緩未來版本的釋出。很多團隊多年來每季度都會釋出一個或多個模型。釋出新模型的三個基本原因如下所示：

• 您將要新增新特徵。

• 您將要調整正則化並以新方式組合舊特徵。

• 您將要調整目標。

無論如何，構建模型時多考慮考慮並沒有什麼壞處：檢視提供到樣本中的資料有助於發現新訊號、舊訊號以及損壞的訊號。因此，在構建模型時，請考慮新增、移除或重新組合特徵的難易程度。考慮建立管道的全新副本以及驗證其正確性的難易程度。考慮是否可以同時執行兩個或三個副本。最後，不必擔心此版本的管道有沒有納入第 16 個特徵（共 35 個），下個季度會將其納入。

第 17 條規則：從可直接觀察和報告的特徵（而不是經過學習的特徵）著手。

這一點可能存在爭議，但可以避免許多問題。首先，我們來介紹一下什麼是學習的特徵。學習的特徵是由外部系統（例如非監督式叢集系統）或學習器本身（例如通過因子模型或深度學習）生成的特徵。這兩種方式生成的特徵都非常有用，但會導致很多問題，因此不應在第一個模型中使用。

如果您使用外部系統建立特徵，請注意，外部系統有其自己的目標。外部系統的目標與您當前的目標之間可能僅存在一點點關聯。如果您獲取外部系統的某個瞬間狀態，它可能就會過期。如果您從外部系統更新特徵，則特徵的含義可能會發生變化。如果您使用外部系統提供特徵，請注意，採用這種方法需要非常小心。

因子模型和深度模型的主要問題是，它們是非凸模型。因此，無法保證能夠模擬或找到最優解決方案，且每次迭代時找到的區域性最小值可能不同。這種變化導致難以判斷系統發生的某次變化的影響是有意義的還是隨機的。通過建立沒有深度特徵的模型，您可以獲得出色的基準效果。達到此基準後，您可以嘗試更深奧的方法。

第 18 條規則：探索可跨情境泛化的內容的特徵。

機器學習系統通常只是更大系統中的一小部分。例如，想象熱門資訊中可能會使用的帖子，在其顯示到熱門資訊之前，很多使用者已經對其進行 +1、轉發或評論了。如果您將這些統計資訊提供給學習器，它就會對在正在優化的情景中沒有資料的新帖子進行推廣。 YouTube 的"接下來觀看"可以使用來自 YouTube 搜尋的觀看次數或連看次數（觀看完一個視訊後觀看另一個視訊的次數）或明確的使用者評分來推薦內容。最後，如果您將一個使用者操作用作標籤，在其他情境中看到使用者對文件執行該操作可以是很好的特徵。藉助所有這些特徵，您可以向該情境中引入新內容。請注意，這與個性化無關：先弄清楚是否有人喜歡此情境中的內容，然後再弄清楚喜歡程度。

第 19 條規則：儘可能使用非常具體的特徵。

對於海量資料，學習數百萬個簡單的特徵比學習幾個複雜的特徵更簡單。正在被檢索的文件的識別符號以及規範化的查詢不會提供很多泛化作用，但可以讓您的排名與頻率靠前的查詢的標籤保持一致。因此，請不要害怕具有以下特點的特徵組：每個特徵適用於您的一小部分資料但總體覆蓋率在 90％ 以上。您可以使用正則化來消除適用樣本過少的特徵。

第 20 條規則：組合和修改現有特徵，以便以簡單易懂的方式建立新特徵。

有多種方式可以組合和修改特徵。藉助 TensorFlow 等機器學習系統，您可以通過轉換對資料進行預處理。最標準的兩種方法是"離散化"和"組合"。

"離散化"是指提取一個連續特徵，並從中建立許多離散特徵。以年齡這一連續特徵為例。您可以建立一個年齡不滿 18 週歲時其值為 1 的特徵，並建立年齡在 18-35 週歲之間時其值為 1 的另一個特徵，等等。不要過多考慮這些直方圖的邊界：基本分位數給您帶來的影響最大。

"組合"方法是指組合兩個或更多特徵列。在 TensorFlow 中，特徵列指的是同類特徵集（例如，{男性, 女性}、{美國, 加拿大, 墨西哥} 等等）。組合指的是其中包含特徵的新特徵列，例如，{男性, 女性} × {美國, 加拿大, 墨西哥}。此新特徵列將包含特徵（男性, 加拿大）。如果您使用的是 TensorFlow，並讓 TensorFlow 為您建立此組合，則此（男性, 加拿大）特徵將存在於表示加拿大男性的樣本中。請注意，您需要擁有大量資料，才能使用具有三個、四個或更多基準特徵列的組合學習模型。

生成非常大的特徵列的組合可能會過擬合。例如，假設您正在執行某種搜尋，您的某個特徵列包含查詢中的字詞，另一個特徵列包含文件中的字詞。這時，您可以使用"組合"方法將這些特徵列組合起來，但最終會得到很多特徵（請參閱第 21 條規則）。

處理文字時，有兩種備用方法。最嚴苛的方法是點積。點積方法採用最簡單的形式時，僅會計算查詢和文件間共有字詞的數量。然後將此特徵離散化。另一種方法是交集：如果使用交集方法，當且僅當文件和查詢中都包含"pony"一詞時，才會出現一個特徵；當且僅當文件和查詢中都包含"the"一詞時，才會出現另一個特徵。

第 21 條規則：您可以線上性模型中學習的特徵權重數目與您擁有的資料量大致成正比。

關於模型的合適複雜度方面，有各種出色的統計學習理論成果，但您基本上只需要瞭解這條規則。在某次談話中，曾有人表達過這樣的疑慮：從一千個樣本中是否能夠學到任何東西，或者是否需要超過一百萬個樣本，他們之所以有這樣的疑慮，是因為侷限在了一種特定學習方式中。關鍵在於根據資料規模調整您的學習模型：

• 如果您正在構建搜尋排名系統，文件和查詢中有數百萬個不同的字詞，且您有 1000 個有標籤樣本，那麼您應該在文件和查詢特徵、TF-IDF 和多個其他高度手動工程化的特徵之間得出點積。您會有 1000 個樣本，十多個特徵。

• 如果您有一百萬個樣本，則使用正則化和特徵選擇（可能）使文件特徵列和查詢特徵列相交。這樣一來，您將獲得數百萬個特徵；但如果使用正則化，則您獲得的特徵會有所減少。您會有千萬個樣本，可能會產生十萬個特徵。

• 如果您有數十億或數千億個樣本，您可以使用特徵選擇和正則化，通過文件和查詢標記組合特徵列。您會有十億個樣本，一千萬個特徵。統計學習理論很少設定嚴格的限制，但能夠提供很好的起點引導。

最後，請根據第 28 條規則決定要使用哪些特徵。

第 22 條規則：清理不再使用的特徵。

未使用的特徵會產生技術負債。如果您發現自己沒有使用某個特徵，而且將其與其他特徵組合在一起不起作用，則將其從您的基礎架構中刪除。您需要讓自己的基礎架構保持簡潔，以便儘可能快地嘗試最有可能帶來良好效果的特徵。如有必要，他人可以隨時將您的特徵新增回來。

在決定要新增或保留哪些特徵時，要考慮到覆蓋率。即相應特徵覆蓋了多少個樣本？例如，如果您有一些個性化特徵，但只有 8% 的使用者有個性化特徵，那效果就不會很好。

同時，有些特徵可能會超出其權重。例如，如果您的某個特徵只覆蓋 1% 的資料，但 90% 具有該特徵的樣本都是正分類樣本，那麼這是一個可以新增的好特徵。

對系統的人工分析

在繼續探討機器學習的第三階段之前，請務必重點了解一下在任何機器學習課程中都無法學到的內容：如何檢查現有模型並加以改善。這更像是一門藝術而非科學，但是有幾個有必要避免的反模式。

第 23 條規則：您不是典型的終端使用者。

這也許是讓團隊陷入困境的最簡單的方法。雖然 fishfood（在團隊內部使用原型）和 dogfood（在公司內部使用原型）有許多優點，但員工應該看看是否符合效能要求。雖然應避免應用明顯比較糟糕的更改，但在臨近生產時，應對任何看起來比較合理的更改進行進一步測試，具體方法有兩種：請非專業人員在眾包平臺上回答有償問題，或對真實使用者進行線上實驗。

這樣做的原因有如下兩點。首先，您與程式碼的關係太密切了。您關注的可能是帖子的某個特定方面，或者您只是投入了太多感情（例如確認偏差）。其次，您的時間很寶貴。考慮一下九名工程師開一個小時會議所花的費用可以在眾包平臺上購買多少簽約的人工標籤。

如果您確實想獲得使用者反饋，請使用使用者體驗方法。在流程的早期階段建立使用者角色（請參閱比爾-布克斯頓的 Sketching User Experiences 一書中的描述），然後進行可用性測試（請參閱史蒂夫-克魯格的 Don't Make Me Think 一書中的描述）。使用者角色是指建立假想使用者。例如，如果您的團隊成員都是男性，則有必要設計一個 35 歲的女性使用者角色（使用使用者特徵完成），並檢視其生成的結果，而不是隻檢視 10 位 25-40 歲男性的結果。在可用性測試中請真實使用者體驗您的網站（通過本地或遠端方式）並觀察他們的反應也可以讓您以全新的視角看待問題。

第 24 條規則：衡量模型間的差異。

在向任何使用者展示您的新模型之前，您可以進行的最簡單（有時也是最有用）的一項衡量是，評估新模型的結果與生產有多大差別。例如，如果您有一項排名任務，則在整個系統中針對一批示例查詢執行這兩個模型，並檢視結果的對稱差分有多大（按排名位置加權）。如果差分非常小，那麼您無需執行實驗，就可以判斷不會出現很大變化。如果差分很大，那麼您需要確保這種更改可以帶來好的結果。檢視對稱差分較大的查詢有助於您瞭解更改的性質。不過，請確保您的系統是穩定的。確保模型與自身之間的對稱差分較低（理想情況下為零）。

第 25 條規則：選擇模型時，實用效果比預測能力更重要。

您的模型可能會嘗試預測點選率。但歸根到底，關鍵問題在於您用這種預測做什麼。如果您使用該預測對文件進行排名，那麼最終排名的質量比預測本身更重要。如果您要預測一個文件是垃圾內容的概率，然後選擇一個取捨點來確定要阻斷的內容，那麼允許的內容的精確率更為重要。大多數情況下，這兩項應該是一致的：當它們不一致時，帶來的優勢可能會非常小。因此，如果某種更改可以改善對數損失，但會降低系統的效能，則查詢其他特徵。當這種情況開始頻繁發生時，說明您該重新審視模型的目標了。

第 26 條規則：在衡量的錯誤中尋找規律，並建立新特徵。

假設您看到模型"弄錯"了一個訓練樣本。在分類任務中，這種錯誤可能是假正例，也可能是假負例。在排名任務中，這種錯誤可能是假正例和假負例，其中正例的排名比負例的排名低。最重要的是，機器學習系統知道自己弄錯了該樣本，如果有機會，它會修復該錯誤。如果您向該模型提供一個允許其修正錯誤的特徵，該模型會嘗試使用它。

另一方面，如果您嘗試根據系統不會視為錯誤的樣本建立一個特徵，該特徵將會被系統忽略。例如，假設某人在 Play 應用搜尋中搜尋"免費遊戲"。假設排名靠前的搜尋結果中有一個是相關性較低的搞笑應用。因此，您為"搞笑應用"建立了一個特徵。但是，如果您要最大限度地增加安裝次數，並且使用者在搜尋免費遊戲時安裝了搞笑應用，那麼"搞笑應用"特徵不會達到您想要的效果。

如果模型弄錯了您的某些樣本，請在當前特徵集之外尋找規律。例如，如果系統似乎在降低內容較長的帖子的排名，那麼新增帖子長度。不要新增過於具體的特徵。如果您要新增帖子長度，請不要試圖猜測長度的具體含義，只需新增十多個特徵，然後讓模型自行處理（請參閱第 21 條規則）。這是實現目標最簡單的方式。

第 27 條規則：嘗試量化觀察到的異常行為。

當現有的損失函式沒有捕獲您團隊中的部分成員不喜歡的某些系統屬性時，他們會開始有挫敗感。此時，他們應該竭盡所能將抱怨轉換成具體的數字。例如，如果他們認為 Play 搜尋中顯示的"搞笑應用"過多，則可以通過人工評分識別搞笑應用。（在這種情況下，您可以使用人工標記的資料，因為相對較少的一部分查詢佔了很大一部分流量。）如果您的問題是可衡量的，那麼您可以開始將它們用作特徵、目標或指標。一般規則是"先量化，再優化"。

第 28 條規則：請注意，短期行為相同並不意味著長期行為也相同。

假設您的新系統會檢視每個 doc_id 和 exact_query，然後計算每個查詢的每個文件的點選概率。您發現在並排分析和 A/B 測試中，其行為與您當前系統的行為幾乎完全相同，考慮到它的簡單性，您釋出了它。不過，您發現它沒有顯示任何新應用。為什麼？那是因為您的系統僅根據自己的查詢歷史記錄顯示文件，所以不知道應該顯示新文件。

瞭解這種系統長期行為的唯一方法是，僅使用模型線上時獲得的資料對其進行訓練。這一點非常難。

訓練-應用偏差

訓練-應用偏差是指訓練效果與應用效果之間的差異。出現這種偏差的原因可能是：

• 訓練管道和應用管道中資料的處理方式有差異。

• 訓練時和應用時所用資料有變化。

• 模型和演算法之間有反饋環。

我們注意到 Google 的生產機器學習系統也存在訓練-應用偏差，這種偏差對效能產生了負面影響。最好的解決方案是明確進行監控，以避免在系統和資料改變時引入容易被忽視的偏差。

第 29 條規則：確保訓練效果和應用效果一樣的最佳方法是，儲存在應用時使用的特徵集，然後將這些特徵通過管道傳輸到日誌，以便在訓練時使用。

即使您不能對每個樣本都這樣做，也對一小部分樣本這樣做，以便驗證應用和訓練之間的一致性（請參閱第 37 條規則）。採取了這項措施的 Google 團隊有時會對結果感到驚訝。 YouTube 首頁改用這種在應用時記錄特徵的做法後，不僅大大提高了質量，而且減少了程式碼複雜度。目前有許多團隊都已經在其基礎設施上採用了這種方法。

第 30 條規則：按重要性對取樣資料加權，不要隨意丟棄它們！

資料過多時，總會忍不住採用前面的檔案而忽略後面的檔案。這是錯誤的做法。儘管可以丟棄從未向使用者展示過的資料，但對於其他資料來說，按重要性加權是最佳選擇。按重要性加權意味著，如果您決定以 30% 的概率對樣本 X 進行抽樣，那麼向其賦予 10/3 的權重。按重要性加權時，您仍然可以使用第 14 條規則中討論的所有校準屬性。

第 31 條規則：如果您在訓練和應用期間關聯表格中的資料，請注意，表格中的資料可能會變化。

假設您將文件 ID 與包含這些文件的特徵（例如評論次數或點選次數）的表格相關聯。表格中的特徵在訓練時和應用時可能有所不同。那麼，您的模型在訓練時和應用時對同一文件的預測就可能會不同。要避免這類問題，最簡單的方法是在應用時記錄特徵（請參閱第 32 條規則）。如果表格只是緩慢發生變化，那麼您還可以每小時或每天建立表格快照，以獲得非常接近的資料。請注意，這仍不能完全解決問題。

第 32 條規則：儘可能在訓練管道和應用管道間重複使用程式碼。

批處理不同於線上處理。進行線上處理時，您必須在每個請求到達時對其進行處理（例如，您必須為每個查詢單獨進行查詢），而進行批處理時，您可以組合任務（例如進行關聯）。應用時，您進行的是線上處理，而訓練時，您進行的是批處理。不過，您可以通過一些方法來重複使用程式碼。例如，您可以專門為自己的系統建立一個物件，其中所有查詢結果和關聯都能以非常易於人類讀取的方式進行儲存，且錯誤也可以輕鬆進行測試。然後，收集了所有資訊後，您可以在應用和訓練期間使用一種共同的方法，在人類可讀物件（特定於您的系統）和機器學習需要的任何格式之間架起一座橋樑。這樣可以消除訓練-應用偏差的一個根源。由此推知，在訓練和應用時，儘量不要使用兩種不同的程式語言。如果這樣做，就幾乎不可能共享程式碼了。

第 33 條規則：如果您根據 1 月 5 日之前的資料生成模型，則根據 1 月 6 日及之後的資料測試模型。

一般來說，要衡量模型的效果，應使用在訓練模型所有資料對應的日期之後的日期收集的資料，因為這樣能更好地反映系統應用到生產時的行為。如果您根據 1 月 5 日之前的資料生成模型，則根據 1 月 6 日及之後的資料測試模型。您一般會發現，使用新資料時模型的效果不如原來好，但應該不會太糟。由於可能存在的一些日常影響，您可能沒有預測到平均點選率或轉化率，但曲線下面積（表示正分類樣本的分數高於負分類樣本的概率）應該非常接近。

第 34 條規則：在有關過濾的二元分類（例如，垃圾郵件檢測或確定有趣的電子郵件）中，在短期內小小犧牲一下效果，以獲得非常純淨的資料。

在過濾任務中，標記為負分類的樣本不會向使用者顯示。假設您的過濾器在應用時可遮蔽 75% 的負分類樣本。您可能會希望從向使用者顯示的例項中提取額外的訓練資料。例如，如果使用者將您的過濾器未遮蔽的電子郵件標記為垃圾郵件，那麼您可能想要從中學習規律。

但這種方法會引入取樣偏差。如果您改為在應用期間將所有流量的 1% 標記為"預留"，並向使用者傳送所有預留樣本，則您可以收集更純淨的資料。現在，過濾器遮蔽了至少 74% 的負分類樣本。這些預留樣本可以成為訓練資料。

請注意，如果過濾器遮蔽了 95% 或以上的負分類樣本，則此方法的可行性會降低。即便如此，如果您希望衡量應用效果，可以進行更低比例的取樣（比如 0.1% 或 0.001%）。一萬個樣本足以非常準確地評估效果。

第 35 條規則：注意排名問題中存在的固有偏差。

當您徹底改變排名演算法，導致出現不同的排名結果時，實際上改變了您的演算法以後會處理的資料。這時，就會出現固有偏差，您應該圍繞這種偏差來設計模型。具體方法有多種。以下是讓您的模型青睞已見過的資料的方法。

• 對覆蓋更多查詢的特徵（而不是僅覆蓋一個查詢的特徵）進行更高的正則化。通過這種方式，模型將青睞專門針對一個或幾個查詢的特徵，而不是泛化到所有查詢的特徵。這種方法有助於防止十分熱門的查詢結果顯示到不相關的查詢中。請注意，這與以下更為傳統的建議相左：對具有更多唯一值的特徵列進行更高的正則化。

• 僅允許特徵具有正權重。這樣一來，就可確保任何好特徵都比"未知"特徵合適。

• 不選擇只處理文件資料的特徵。這是第一條規則的極端版本。例如，即使指定應用是熱門下載應用（無論查詢是什麼），您也不想在所有地方都展示它。如果不選擇只處理文件資料的特徵，這一點很容易做到。您之所以不想在所有地方展示某個特定的熱門應用，是因為讓使用者可以找到所有所需應用至關重要。例如，如果一位使用者搜尋"賞鳥應用"，他/她可能會下載"憤怒的小鳥"，但那絕對不是他/她想要的應用。展示此類應用可能會提高下載率，但最終卻未能滿足使用者的需求。

第 36 條規則：通過位置特徵避免出現反饋環。

內容的位置會極大地影響使用者與其互動的可能性。如果您將應用放在首位，則應用獲得的點選率更高，導致您認為使用者更有可能點選該應用。處理此類問題的一種方法是新增位置特徵，即關於內容在網頁中的位置的特徵。您可以使用位置特徵訓練模型，使模型學習（例如）對特徵"1st­position"賦予較高的權重。因此，對於具有"1st­position=true"特徵的樣本的其他因素，模型會賦予較低的權重。然後，在應用時，您不向任何例項提供位置特徵，或為所有例項提供相同的預設特徵，因為在決定以怎樣的順序顯示候選例項之前，您就對其進行了打分。

請注意，因為訓練和測試之間的這種不對稱性，請務必在位置特徵與模型的其餘特徵之間保持一定的分離性。讓模型成為位置特徵函式和其餘特徵函式之和是理想的狀態。例如，不要將位置特徵與任何文件特徵組合在一起。

第 37 條規則：測量訓練/應用偏差。

一般來說，很多情況都會引起偏差。此外，您可以將其分為以下幾個部分：

• 訓練資料和預留資料的效果之間的差異。一般來說，這種情況始終存在，而且並非總是壞事。

• 預留資料和"次日"資料的效果之間的差異。同樣，這種情況始終存在。您應該調整正則化，以最大程度地提升次日資料的效果。不過，如果與預留資料相比，次日資料效果下降明顯，則可能表明某些特徵具有時效性，而且可能會降低模型的效果。

• "次日"資料和實時資料的效果之間的差異。如果您將模型應用於訓練資料中的某個樣本，並在應用時使用同一樣本，那麼您得到的結果應該完全相同（請參閱第 5 條規則）。因此，此處的差異很可能表示出現了工程錯誤。

機器學習第三階段：緩慢增長、優化細化和複雜模型

第二階段即將結束時會出現一些訊號。首先，月增長開始減弱。您將開始在指標之間做出取捨：在部分試驗中，您會看到一些指標上升了，而另一些指標下降了。情況變得有趣起來。由於越來越難實現增長，因此機器學習系統必須變得更加複雜。注意：相比之前兩個部分，本部分中會有較多的純理論性規則。我們見過許多團隊在機器學習的第一階段和第二階段非常滿意。但到了第三階段後，他們必須找到自己的道路。

第 38 條規則：如果目標不協調，併成為問題，就不要在新特徵上浪費時間。

當您的衡量結果穩定時，您的團隊會開始關注當前機器學習系統的目標範圍之外的問題。如前所述，如果現有演算法目標未涵蓋產品目標，則您需要修改演算法目標或產品目標。例如，您可以優化點選次數、+1 次數或下載次數，但讓釋出決策部分依賴於人工評分者。

第 39 條規則：釋出決策代表的是長期產品目標。

Alice 有一個關於減少預測安裝次數的邏輯損失的想法。她新增了一個特徵。邏輯損失降低了。當她執行線上實驗時，看到安裝率增加了。但是，在釋出評審會上，有人指出，每日活躍使用者數減少了 5%。於是，團隊決定不釋出該模型。Alice 很失望，但現在她意識到釋出決策取決於多個條件，只有一部分條件可以通過機器學習直接得到優化。

事實上，現實世界並不是網遊世界：沒有"生命值"來確定產品的執行狀況。團隊必須使用自己收集的統計資訊來嘗試有效地預測系統未來的表現會如何。他們需要關注互動度、日活躍使用者數 (DAU)、30 日 DAU、收入以及廣告主的投資回報率。這些可在 A/B 測試中衡量的指標本身僅代表了以下更長期目標：讓使用者滿意、增加使用者數量、讓合作伙伴滿意以及實現盈利，進一步，您還可以認為它們代表了釋出優質且實用的產品，以及五年後公司繁榮發展。

唯一可以輕鬆做出釋出決策的情況是，所有指標都在變好（或至少沒有變差）。 如果團隊能夠在複雜的機器學習演算法和簡單的啟發式演算法之間做出選擇，而對所有這些指標來說，簡單的啟發式演算法可以提供更好的效果，那麼應該選擇啟發式演算法。此外，並未對所有可能的指標值進行明確排名。具體而言，請考慮以下兩種情形：

實驗	每日活躍使用者數	收入/日
A	100 萬	400 萬美元
B	200 萬	200 萬美元

如果當前系統是 A，那麼團隊不太可能會改用 B。如果當前系統是 B，那麼團隊不太可能會改用 A。這似乎與理性行為背道而馳；但是，對更改指標的預測可能會成功也可能不會，因此這兩種改變都蘊含著巨大的風險。每個指標都涵蓋了團隊所擔心的一些風險。

此外，沒有一個指標涵蓋團隊最關心的問題，即"五年後我的產品將何去何從"？

另一方面，個人更傾向於選擇可以直接優化的目標。 大多數機器學習工具也都青睞這樣的環境。在這樣的環境下，快速建立新特徵的工程師能穩定地進行一系列釋出。一種稱為"多目標學習"的機器學習已開始解決此問題。例如，您可以提出約束滿足問題，對每個指標設定下限，並優化指標的一些線性組合。不過，即使如此，也並不是所有指標都可以輕鬆框定為機器學習目標：如果使用者點選了文件或安裝了應用，那是因為相應內容展示出來了。但要弄清楚使用者為什麼訪問您的網站就難得多。如何預測整個網站未來的成功狀況屬於 AI 完備問題：與計算機視覺或自然語言處理一樣難。

第 40 條規則：保證整合學習簡單化。

採用原始特徵並直接對內容進行排名的統一模型是最易於進行除錯和理解的模型。但是，整合學習模型（將其他模型的分數結合到一起的模型）可以實現更好的效果。為了簡單起見，每個模型應該要麼是僅接受其他模型的輸入的整合學習模型，要麼是接受多個特徵的基本模型，但不能兩者皆是。 如果在單獨訓練的模型之上還有其他模型，則組合它們會導致不良行為。

使用簡單的模型進行整合學習（僅將"基本"模型的輸出作為輸入）。此外，您還需要將屬性強加到這些整合學習模型上。例如，基本模型生成的分數的升高不應使整合學習模型的分數有所降低。另外，如果傳入的模型在語義上可解釋（例如，經過校準），則最理想，因為這樣一來，即使基本模型發生改變，也不會擾亂整合學習模型。另外，強制要求：如果基本分類器的預測概率增大，不會使整合學習模型的預測概率降低。

第 41 條規則：效果達到平穩後，尋找與現有訊號有質的差別的新資訊源並新增進來，而不是優化現有訊號。

您新增了一些有關使用者的受眾特徵資訊，也新增了一些有關文件中字詞的資訊。您探索了模板，並調整了正則化。但在幾個季度的釋出中，關鍵指標的提升幅度從來沒有超過 1%。現在該怎麼辦？

是時候開始為截然不同的特徵（例如，使用者在過去一天內、一週內或一年內訪問的文件的歷史記錄，或者其他屬性的資料）構建基礎架構了。您可以使用維基資料條目或公司內部資訊（例如，Google 的知識圖譜）。利用深度學習。開始調整您對投資回報的預期，並付出相應的努力。與在任何工程專案中一樣，您必須對新增新特徵的好處與增加複雜性的成本進行一番權衡。

第 42 條規則：不要期望多樣性、個性化或相關性與熱門程度之間的聯絡有您認為的那樣密切。

一組內容中的多樣性可以有多種含義，其中內容來源的多樣性是最常見的一種。個性化意味著每個使用者獲得貼合其個人需求的結果。相關性意味著某個特定查詢的結果更適合該查詢，而非其他任何查詢。因此，這三個屬性均具有不同於常態的定義。

但常態往往很難被打敗。

請注意，如果您的系統在測量點選次數、訪問時間、觀看次數、+1 次數、轉發次數等資料，那麼您測量的是內容的熱門程度。團隊有時會嘗試學習具備多樣性的個性化模型。為實現個性化，他們會新增支援系統進行個性化（代表使用者興趣的部分特徵）或多樣化（表明相應文件是否與其他返回的文件有任何相同特徵的特徵，例如作者或內容）的特徵，然後發現這些特徵的權重比預期低（或者有時是不同的訊號）。

這並不意味著多樣性、個性化或相關性不重要。正如上一條規則中所指出的那樣，您可以進行後期處理來增加多樣性或相關性。如果您看到更長期的目標有所增長，您可以宣告除了熱門程度外，多樣性/相關性也很有價值。然後，您可以繼續採用後期處理方法，也可以根據多樣性或相關性直接修改目標。

第 43 條規則：在不同的產品中，您的好友基本保持不變，但您的興趣並非如此。

Google 的團隊通過以下做法取得了大量進展：採用一個預測產品中某種聯絡的緊密程度的模型，並使用該模型對其他產品進行準確預測。您的好友保持不變。另一方面，我曾見過幾個團隊在應對多個產品間的個性化特徵時捉襟見肘。是的，當時看起來應該可以奏效的。但現在看來並沒有。有時可以奏效的方法是，使用一個屬性的原始資料來預測另一個屬性的行為。此外，請注意，僅僅是知道使用者有其他屬性的歷史記錄也會有幫助。例如，兩個產品上出現了使用者活動或許本身就可以說明該問題。

相關資源

Google 內部和外部有許多關於機器學習的文件。

• 機器學習速成課程：應用機器學習簡介。

• 機器學習：概率法，凱文-墨菲著，幫助瞭解機器學習領域。

• 分析大型複雜資料集的實用建議：一種考慮資料集的資料科學方法。

• 深度學習，伊恩-古德費洛等著，幫助學習非線性模型。

• 關於技術負債的 Google 論文，其中提供了許多一般性建議。

• Tensorflow 文件。

致謝

感謝 David Westbrook、Peter Brandt、Samuel Ieong、Chenyu Zhao、Li Wei、Michalis Potamias、Evan Rosen、Barry Rosenberg、Christine Robson、James Pine、Tal Shaked、Tushar Chandra、Mustafa Ispir、Jeremiah Harmsen、Konstantinos Katsiapis、Glen Anderson、Dan Duckworth、Shishir Birmiwal、Gal Elidan、Su Lin Wu、Jaihui Liu、Fernando Pereira 和 Hrishikesh Aradhye 對本文件進行多處更正、提供建議和有用示例。此外，還要感謝 Kristen Lefevre、Suddha Basu 和 Chris Berg 對早期版本提供的幫助。任何錯誤、遺漏或（喘氣聲！）不受歡迎的看法均由本人承擔責任。