在 Web 誕生之初，當時還有專門負責寫“程式碼”的“開發者”。這些程式碼在寫好後會交到“運營”人員手中，而你也知道，實際上企業用來賺錢的網站，當時都是這些運維人員負責的，例如系統管理員、資料中心工作人員、資料庫管理員（差點忘了他們至今還存在著，DBA 們，你們好啊！）。當時，網站的釋出管理需要遵守非常嚴格的規定，測試過程充滿痛苦，任何新內容釋出都要經歷冗繁的過程。
還記得 Joel 測試嗎？是的，估計聽說過這東西的都是三四十歲的“古董級”工程師了。
對於測試中的任何問題，如果你的答案是否定的，那麼意味著你的團隊文化出現了某種問題。
-
使用原始碼控制系統了嗎？ 很多工程師經常擔心自己也許會（或者已經）弄壞他人的程式碼。例如因為硬碟故障導致所有程式碼丟失。
-
能否一鍵點選開始構建？ 工程師總有或多或少的時間要花在構建工作中。需要執行的步驟越多，出錯的可能就越大；但生成構建的次數越少，新程式碼的測試速度就越慢。
-
是否進行每日構建？ 如果某個構建出錯了，可能要在一段時間後才能注意到。（現在大家都開始持續整合了，其實這早已不是新鮮事物！）
-
是否有 Bug 資料庫？ 電子郵件、即時貼、來自憤怒的客戶和“業務”夥伴的電話通話…… 總有某些 Bug 會被遺忘。還有很多 Bug 未能妥善記錄，甚至無法重現。
-
你是否會在寫新程式碼前先修復 Bug？ 技術債會拖慢新功能的釋出速度。如果將整個程式碼庫的重構專案交給小型團隊負責，那麼可能得等待一年才能最終實現。
-
是否有始終保持最新的計劃安排？ 具體日期毫無意義，該完工的時候終歸就完工了。當你胡亂預估的時候，一定得考慮好這類問題。
-
具體規範確定了嗎？ 工程師代替產品經理來思考，但是完工後呢？“這根本不是我想要的！能否實現另外一個如何如何的功能？”
-
程式設計師們能得到安寧的工作環境嗎？ 我們去喝咖啡吧！嘿，某事我具體該怎麼做？天哪，HR 發的這封郵件你看了嗎？有些工程師問公司能否為他們的耳機買單，被 HR 拒絕了。
-
你是否已經用上了市面上最棒的工具？ 愛抱怨的工程師，效率往往都不會太高。
-
你有測試人員嗎？Bug 的數量往往更多。
-
新招的求職者在面試中是否寫出了程式碼？ 團隊中偶爾就會遇到某些人，簡歷裡充斥著各種時髦的關鍵字，但工作中遇到具體問題後甚至無法學習新的程式語言來解決問題。
-
是否會進行易用性測試？ 工程師開發了某個功能，可幾個月後發現使用者根本不喜歡。這就導致了經典的“易用性問題”。
所有這些問題有一個共通之處：會拖累工程團隊的速度。可用的軟體釋出給使用者的速度變慢，使用者反饋的速度變慢，產品創新的速度變慢，業務為客戶創造價值的速度變慢。
能更快速為使用者創造價值的競爭對手終將戰勝你自己。這一切可能都因為你沒有使用構建系統。
問題一開始可能顯得微不足道。這些問題已經可以很熟練地隨著時間的積累產生越來越大的影響。對於技術進步，我們往往抱有一種直觀線性發展的觀點，例如會認為，通過今天所實現的節奏可以預測未來的發展速度。如果隨著時間累積，軟體交付速度以指數形式減速，我們就會因為這種線性的觀點而低估未來的交付速度會慢到何種程度。
更多優質內容請關注微信公眾號“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 團隊實現更快速迭代的一些方法包括：
-
清潔、具備妥善的標籤，並且足夠一致的資料。
-
一鍵點選式模型訓練和部署機制。
-
自服務資料科學。降低迭代對模型本身的工程依賴性，例如嘗試新的特徵，構建新的模型，自動進行超引數（Hyperparameter）優化。
-
為資料訪問、資料操作、聚類模型訓練、模型部署和實驗、線上預測查詢以及候選人計分提供可縮放的高效能系統。
-
基礎架構運維人員將資料科學家視作使用自己工作成果的“一等公民”。
-
與生產型機器學習環境完全一致的開發用機器學習環境。
我們用來衡量 AI 團隊文化的 Joel 測試內容如下：
-
對資料管線進行版本控制並使其可再現。
-
確保管線可以一鍵（重新）構建。
-
在只需工程人員最少量幫助的情況下部署到生產環境。
-
成功的機器學習系統是一個漫長的遊戲，只能在遵守遊戲規則的情況下參與。
-
持續改善。實驗和迭代是一種工作態度。
因此我們開發了 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