如何構建AI文化：AI的啓蒙之路

譯者 | 大愚若智

編輯 | Natalie

從九十年代的經驗中學習

在 Web 誕生之初，當時還有專門負責寫「代碼」的「開發者」。這些代碼在寫好後會交到「運營」人員手中，而你也知道，實際上企業用來賺錢的網站，當時都是這些運維人員負責的，例如系統管理員、數據中心工做人員、數據庫管理員（差點忘了他們至今還存在着，DBA 們，大家好啊！）。當時，網站的發佈管理須要遵照很是嚴格的規定，測試過程充滿痛苦，任何新內容發佈都要經歷冗繁的過程。

還記得 Joel 測試嗎？是的，估計據說過這東西的都是三四十歲的「古董級」工程師了。

對於測試中的任何問題，若是你的答案是否認的，那麼意味着你的團隊文化出現了某種問題。

1. 使用源代碼控制系統了嗎？ 不少工程師常常擔憂本身也許會（或者已經）弄壞他人的代碼。例如由於硬盤故障致使全部代碼丟失。

2. 可否一鍵點擊開始構建？ 工程師總有或多或少的時間要花在構建工做中。須要執行的步驟越多，出錯的可能就越大；但生成構建的次數越少，新代碼的測試速度就越慢。

3. 是否進行每日構建？ 若是某個構建出錯了，可能要在一段時間後才能注意到。（如今你們都開始持續集成了，其實這早已不是新鮮事物！）

4. 是否有 Bug 數據庫？ 電子郵件、即時貼、來自憤怒的客戶和「業務」夥伴的電話通話…… 總有某些 Bug 會被遺忘。還有不少 Bug 未能妥善記錄，甚至沒法重現。

5. 你是否會在寫新代碼前先修復 Bug？ 技術債會拖慢新功能的發佈速度。若是將整個代碼庫的重構項目交給小型團隊負責，那麼可能得等待一年才能最終實現。

6. 是否有始終保持最新的計劃安排？ 具體日期毫無心義，該完工的時候終歸就完工了。當你胡亂預估的時候，必定得考慮好這類問題。

7. 具體規範肯定了嗎？ 工程師代替產品經理來思考，可是完工後呢？「這根本不是我想要的！可否實現另一個如何如何的功能？」

8. 程序員們能獲得安寧的工做環境嗎？ 咱去喝咖啡吧！嘿，某事我具體該怎麼作？天哪，HR 發的這封郵件你看了嗎？有些工程師問公司可否爲他們的耳機買單，被 HR 拒絕了。

9. 你是否已經用上了市面上最棒的工具？ 愛抱怨的工程師，效率每每都不會過高。

10. 你有測試人員嗎？Bug 的數量每每更多。

11. 新招的求職者在面試中是否寫出了代碼？ 團隊中偶爾就會遇到某些人，簡歷裏充斥着各類時髦的關鍵字，但工做中遇到具體問題後甚至沒法學習新的編程語言來解決問題。

12. 是否會進行易用性測試？ 工程師開發了某個功能，可幾個月後發現用戶根本不喜歡。這就致使了經典的「易用性問題」。

全部這些問題有一個共通之處：會拖累工程團隊的速度。可用的軟件發佈給用戶的速度變慢，用戶反饋的速度變慢，產品創新的速度變慢，業務爲客戶創造價值的速度變慢。

能更快速爲用戶創造價值的競爭對手終將打敗你本身。這一切可能都由於你沒有使用構建系統。

問題一開始可能顯得微不足道。這些問題已經能夠很熟練地隨着時間的積累產生愈來愈大的影響。對於技術進步，咱們每每抱有一種直觀線性發展的觀點，例如會認爲，經過今天所實現的節奏能夠預測將來的發展速度。若是隨着時間累積，軟件交付速度以指數形式減速，咱們就會由於這種線性的觀點而低估將來的交付速度會慢到何種程度。

更多優質內容請關注微信公衆號「AI 前線」，（ID：ai-front）

衡量速度

因而後來誕生了以「速率（Velocity）」這一律念爲主的敏捷社區。這是一種診斷式的指標，用於衡量團隊能夠用多快的速度基於現有代碼庫發佈複雜代碼。在每次衝刺結束後，須要加入用於衡量團隊速率的故事點（Story point）。若是速率下降了，意味着團隊發佈複雜「故事」的速度變慢了，所以能夠認爲存在方向性錯誤。趕忙採起措施吧！

問題在於，速率取決於不少東西。咱們很難知道該怎樣作才能將其推向正確的方向。毫無疑問，這個問題的解決須要時間，全部看似簡單快速的解法（例如團隊擴員）其實都解決不了最核心的問題。

而且產品的構建並不僅是工程師的責任。項目經理、用戶體驗團隊、設計師，人人有責！咱們很難單純使用一個相似於「咱們的速度足夠快嗎」這樣的指標來歸納地衡量產品構建過程當中的方方面面。速率沒法徹底體現全部這一切，咱們可能依然在構建你們並不想要的產品。

接着又出現了精益創業（Lean Startup）。

精益創業方法論

對於產品有本身的想法？作出假設 > 構建最小可行產品（MVP） > 驗證本身的假設。要儘量快速地完成整個過程（即一次迭代）。

負責產品構建的人終於看到了這些徵兆。速度很重要。迭代的速度很重要。

快速迭代 = 成功。機器學習領域尤爲如此。

咱們的 CTO Prashast 曾開發了幾個被 Google 用於搭建生產用機器學習系統的工具，他認爲任何機器學習配置都必須能實現快速迭代，對此他是這樣解釋的：

你不能僅僅「從事機器學習」就開始以爲一切都會奇蹟般地生效。訓練後就遺忘（Train-and-forget）的心態意味着模型很快將變得陳舊不堪。產品會發生變化，用戶會發生變化，行爲會發生變化。實際上，持續不斷的實驗探索和改進是一條漫長的路。你須要首先用簡單的事情進行嘗試，隨後在模型中嘗試不一樣的特徵。數據並不是老是潔淨，你須要用不一樣的模型進行實驗，隨後進行 A/B 測試。生產環境中不免會出錯，可能須要花數月時間不斷調整才能正常使用。

一旦着手進行，你就須要將其視做一種軟件項目。須要構建、測試、部署、迭代。每一個迭代週期都會讓結果日漸完善。能夠迭代的次數越多，機器學習環境的完善速度就越快。

爲了驗證這種說法，咱們與數據科學團隊討論了他們對機器學習技術的使用方式。你可能已經想到了，這個團隊涉及的領域很普遍，會有極爲老練的團隊負責處理 PB 級別的數據，天天須要交付數十億次預測結果，而這些結果會被其餘團隊用於訓練本身的第一個模型。

固然，成熟的團隊都面對快速迭代作好了準備。Uber 的內部機器學習平臺就是個例子。

然而這些團隊並不是老是喜歡這樣作，彷佛整個團隊的啓蒙都會經歷一條曲線。

圖中內容：大數據就像青少年的「啪啪啪」：你們都在談，沒人知道到底該怎麼作，每一個人都認爲其餘全部人都正在作，因而每一個人都宣稱本身正在作……

關於機器學習，這種說法一樣適用！

這方面，不一樣組織的作法可分爲兩種類型。一種類型採起了「精益 AI」的方法，另外一種則採起了「我看一篇文章說咱們須要創建本身的 AI 策略」的方法。

大部分團隊都會經歷這樣的啓蒙曲線，緣由在於 AI 文化的構建是一段旅途。團隊須要從一些能夠快速交付的簡單事務着手，藉此展現價值並以此爲基礎進行完善。大部分時候，着手 AI 方面的工做意味着須要退回曲線上以前的階段。團隊可能須要花費大量時間處理全部數據，進行清洗並從新思考數據基礎架構，而這僅僅多是由於這些因素拖累了 AI 工做。

對於認爲「既然已經有 AI 策略了，那麼咱們直接構建機器學習平臺吧」，進而直接跳到曲線中間階段的團隊，一般將會失敗。這種作法放大了產品團隊（包括數據科學家！）和董事會之間的斷裂。也難怪數據科學家會感受受挫而且不少公司開始遇到 AI 冷啓動問題。

想要構建 AI 文化？那就完全經歷曲線的每一個環節而且進行更快速的迭代。

AI 團隊實現更快速迭代的一些方法包括：

1. 清潔、具有妥善的標籤，而且足夠一致的數據。

2. 一鍵點擊式模型訓練和部署機制。

3. 自服務數據科學。下降迭代對模型自己的工程依賴性，例如嘗試新的特徵，構建新的模型，自動進行超參數（Hyperparameter）優化。

4. 爲數據訪問、數據操做、聚類模型訓練、模型部署和實驗、在線預測查詢以及候選人計分提供可縮放的高性能系統。

5. 基礎架構運維人員將數據科學家視做使用本身工做成果的「一等公民」。

6. 與生產型機器學習環境徹底一致的開發用機器學習環境。

咱們用來衡量 AI 團隊文化的 Joel 測試內容以下：

1. 對數據管線進行版本控制並使其可再現。

2. 確保管線能夠一鍵（從新）構建。

3. 在只需工程人員最少許幫助的狀況下部署到生產環境。

4. 成功的機器學習系統是一個漫長的遊戲，只能在遵照遊戲規則的狀況下參與。

5. 持續改善。實驗和迭代是一種工做態度。

所以咱們開發了 Blurr（https://github.com/productml/blurr）。將數據匯聚到一塊兒，針對機器學習的需求進行處理、清洗和混合，這種操做並非只進行一次就夠的。這是任何 AI 工做的基礎，而以此爲基礎進行持續不斷的改進，這對任何成功的 AI 文化都相當重要。Blurr 提供了一種基於 YAML 的高級語言，可供數據科學家 / 工程師定義數據轉換。本來須要花 2 天時間用 Spark 代碼完成的工做，使用 Blurr 能夠在 5 分鐘內搞定。

Blurr 是開源的，由於咱們認爲開源的方法能夠促進 AI 各領域的創新。該技術的開發甚至都是公開的，咱們的每週衝刺都已發佈到 GitHub，任何人均可以看到。

DevOps 工具市場的存在是爲了讓咱們更快速地發佈軟件。

咱們的願景在於，應該構建一種 MLOps 市場，幫助團隊更快速發佈機器學習產品，而 Blurr 的誕生是咱們向着這個目標邁進的第一步。由於目前最大的問題偏偏在於數據自己的迭代。

——咱們有着數據驅動的文化。AI 源自數據，所以咱們就有了 AI 文化！

——不，其實你並無。

「數據驅動」，僅僅只能消除決策工做中人的偏見。應用加載速度變長是壞事嗎？這個新模型比原來的好嗎？先看看數據再說話吧！

AI 文化是一種算法驅動的文化，由人類構建能在生產環境中作決策的機器，並經過部署的算法實現人類設法但願達成的目標（提升廣告的點擊率、轉化率、參與度等）。

AI 文化能夠很好地適應機率判斷（Probabilistic judgement）。推薦這種產品，會比推薦那種產品對客戶的吸引力提升 60%；40% 的時間裏，狀況都不會變得更好。感受這些結論很棒吧？那就開始着手並不斷完善吧！

AI 文化重在持續不斷的實驗和迭代。組織中的其餘全部部分都必須爲其提供支持。

人類很複雜。當咱們本身只能隨機作決策，甚至捎帶着具有模式識別能力和認知誤差時，咱們會期待着經過機器得到肯定性的行爲。人類經營着企業而且玩弄權術，在構建 AI 文化時，這些狀況可能會讓咱們極爲受挫。

這使得我好奇，當人類（以及相似企業這種人類發明的社會結構）面對具有超級智能的機器時會怎麼辦。歡迎來到 2029 年！

Blurr 目前已經發布了開發者預覽版，你能夠訪問 GitHub 瞭解詳情並給該項目加星！

閱讀英文原文：

https://hackernoon.com/how-to-build-ai-culture-go-through-the-curve-of-enlightenment-21c239c1d5a7