如何從先期的失敗中找到一條成功之路，本文試圖作了一番**。——caleb kaiser寫於 2020 年 4 月 24 日。
20 年初，我們幾個人嘗試構建乙個端到端的機器學習(ml – machine learning)框架。我們從這次嘗試中得到的基本體會是，構建機器學習管道是乙個令人沮喪的、毫無邏輯的體驗，而且我們應該可以構建更好的東西。
這次嘗試並沒有按照原先計畫地進行。
我將在本文對這程式設計客棧次嘗試作乙個詳盡地介紹，下面先介紹大致情況：
在經歷了以上這些過程後，我ezctzilxz們構建了乙個更好的專案 - cortex，我們的模型服務基礎設施。對於任何對機器學習研究和/或應用感興趣的人來說，我們想讓這個過程成為一種警示：
生產型機器學習系統確實需要更好的使用者體驗，但是機器學習生態系統是非常複雜和不斷變化的，這使得構建乙個涵蓋大量用例的解決方案非常困難。
我們大多數人(cortex的貢獻者)都有devops和web開發的背景，習慣於將應用程式的不同層抽象為單個介面的框架。
當我們進入機器學習時，每個人都被工具的支離破碎所震驚。我們想構建推薦引擎和聊天機械人(或者更確切地說，會話**)，但在這樣做的過程中，我們發現自己不得不在不同的環境之間(jupyter notebook、終端、aws控制台等等)跳躍。然後把包含有膠水**和tensorflow樣板檔案的整個資料夾寫到一起，用乙個稱為「管道」的強力膠帶粘合起來。
如果我們可以用乙個配置檔案和命令粘合在一起來代替以上所有的步驟，比如：
$ deploy recommendation_engine那顯然是個好的主意。
所以我們就這麼做了。我們構建了這樣的乙個框架，它使用python轉換資料，使用yaml構建管道，並使用乙個cli(命令列介面)控制所有步驟：
當你使用我們支援的窄技術堆疊，同時加上對api的限制，向它提供kaggle資料集時，成為了乙個非常好的框架。
然而，如果你想嘗試在現實世界中使用它，基本上很可能它不會與你的技術堆疊一起工作。毫無疑問這是乙個問題。雖然這個問題的其中一部分原因歸結於我們的設計，但很大一部分原因實際上是因為構建端到端機器學習框架的固有侷限，我們只是在構建了這個端到端機器學習框架之後才發現這一點。
簡單的一種說法是：對於端到端的框架來說，生產型機器學習生態系統太簡單，不可能既不靈活又正確無誤。
機器學習工程師希望使用更好的ux工具，這一點我們沒有錯。我們的錯誤在於我們以為可以構建乙個覆蓋多個用例的端到端機器學習框架(特別在只有幾個貢獻者的情況下)。
有一件事很值得去做(而在專案的早期被我們忽略了)，那就是思考一下曾經給我們啟發的web框架，並記住他們第一次嶄露頭角的時候。
rails、django和symfony，作為web應用的新mvc框架浪潮的一部分，它們都是在 2004 年到 2005 年間發布的。當時的web開發還不能稱為「穩定」，尤其是考慮到自那以後它們是如何變得成熟的(在很大程度上要感謝那些框架)，但是web開發人員所做的工作和現在相比仍然有高度的相似性。
事實上，rails最早的口號之一是「你不是一片美麗而獨特的雪花」，正是基於這樣的乙個事實：大多數web開發人員正在構建架構上類似的應用程式，這些應用程式可以在相同的配置上執行。
生產型機器學習系統還未發展到那個階段。一切仍在變化之中。資料科學家處理的資料型別、使用的模型體系結構、喜歡的語言/框架、應用程式的推斷要求，以及幾乎所有你能想象到的一切東西，都在不斷變化中。
而且，這個領域本身變化也很快。自 18 個月前cortex首次發布以來：
所有這些都在不斷變化中，所以試圖構建乙個支援「合適」技術堆疊的端到端框架從一開始就注定了失敗。
每個人都會要求他們需要的「乙個特性」，而沒有人有相同的要求。我們試圖構建一些通用的特性，但很快就發現這是不可行的，至少不是我們想象的那樣。
構建乙個端到端的機器學習框架是很困難的，因為大部分的機器學習生態系統仍然是「蠻荒的西部」。然而，其中的「模型服務」已經具有了穩定性和一致性。
不管他們使用什麼堆疊，大多數團隊都是通過先將模型封裝在api中，然後部署到雲端(儘管他們不喜歡這樣做)來將其投入生產，。
資料科學家不喜歡它，因為用於構建彈性web服務的工具，如 docker、kubernetes、ec2/gce、負載均衡器等等，都不在他們的觸手可及之處。devops工程師對模型推斷的獨特之處感到惱火。
但是對我們來說，這是乙個機會。「模型作為微服務(model-as-a-microservice)」的設計模式對所有團隊來說是一致的，而它提供的工具，因為它是基礎設施(而不是機器學習生態系統)的一部分，所以非常穩定。更有利的是，作為軟體工程師，我們在構建生產型web服務方面比在構建機器學習管道方面更有經驗。
所以，我們想在模型服務上嘗試一下。我們應用了相同的設計原則，抽象了宣告性yaml配置和最小cli背後的所有低層次的不同，並自動化了將乙個經過訓練的模型轉換為乙個可伸縮的生產型web服務的過程：
通過專注於模型服務，我們可以對堆疊的其餘部不加理會(只要模型有python繫結，cortex就可以為其服務)。因為cortex可以插入任何堆疊，所以我們對cortex在底層使用的工具有了話語權，這又使得構建更高階別的特性變得更加容易。
例如，自從發布用於模型服務的cortex以來，我們增加了對gpu推斷、基於請求的自動縮放、滾動更新和**監視的支援。我們不需要為十幾個不同的容器執行時和集群編排器實現這些功能。cortex在底層使用docker和kubernetes，使用者從來不需要接觸它們中的任何一下。
到目前為止，這種改變似乎正在發揮作用：
從哲學上講，網路框架對我們如何看待cortex有很大的影響。
rails和django之類的框架使得程式設計師的工作效率和幸福感倍增。要構建乙個web應用程式，你不必擔心配置sql資料庫、實現請程式設計客棧求路由、或編寫自己的smtp方法來傳送電子郵件。所有這些都從直觀，簡單的介面中抽象出來。
簡而言之，這就是我們對cortex的看法。資料科學家不必學習kubernetes，他們應該專注於資料科學。軟體工程師們不必花上幾天的時間來研究如何避免5 gb的模型浪費他們的aws賬單，他們應該可以自由地構建軟體。
希望隨著機器學習生態系統的成熟和穩定，我們能夠將這一理念擴充套件到堆疊的其餘部分。目前，模型服務是乙個不錯的開始。
相關鏈結：https：
本文標題: 我們想研發乙個機器學習框架，6 個月後失敗了
本文位址:
想寫乙個ORM的框架
其實也是受公司框架啟發，公司寫bean都是自動生成，只要在乙個web應用中輸入包名和表名，就能自動生成bean，其中一種bean是普通的pojo，是資料庫表的一些字段，加上setget方法，另外一些就是增刪改查的table類。以上雖然看不到如何實現，但是無非也就是讀取databasemeta和res...
乙個遊戲框架
最近一段時間不是很忙，就寫了乙個自己的遊戲伺服器框架雛形，很多地方還不夠完善，但是基本上也算是能夠跑起來了。我先從上層結構說起，一直到實現細節吧，想起什麼就寫什麼。第一部分 伺服器邏輯 伺服器這邊簡單的分為三個部分，客戶端的連線首先到達閘道器伺服器，閘道器這裡有個執行緒用來監聽來自與客戶端的連線，然...
Python機器學習 第乙個機器學習專案
資料集 1.導入庫 import pandas as pd import numpy as np import matplotlib as plt from sklearn.model selection import train test split from sklearn.model sele...