作者 | Yorkie（雷姆）
文中為大家介紹的算法工程架構 Pipcook，它是一款面向前端開發者的機器學習架構，我們希望它會成為前端開發者學習和實踐機器學習的平台，進而推進前端智能化的程序。
助力 2020 雙十一
imgcook 在 2020 雙十一完成了90%的子產品覆寫率，除此之外，基于 Pipcook 的中台解決方案，也分别在 ICBU、菜鳥、飛豬、阿裡雲、阿裡健康和 Lazada 多點開花。
C端代碼解決方案
整個 imgcook 系統結構較為複雜，從一張設計稿到最後生成可上線的代碼，中間需要經曆很多步驟，大緻可包括圖層處理、物料識别、布局生成、語義化和邏輯綁定等，其中每個步驟中都可能需要多個算法模型協作完成，而非一個端到端的模型，比如：
- 在物料識别層，通過圖檔分類模型，可以将一些更為高階的元件（如按鈕、輪播圖、視訊控件、搜尋框等）從圖檔中識别，然後生成對應的元件代碼
- 在語義化層，通過 icon 識别模型，可以更準确地為代碼中的 icon 元素命名類名（ 推薦閱讀：Icon 如何在設計稿生成代碼中被識别？- Imgcook 3.0 系列 ）
- 在字段綁定層，通過文本分類模型，可以了解設計稿中某段文本的含義，進而使用正确接口字段來渲染對應元素
Pipcook 通過提供了通用的模型能力，比如圖檔分類、目标檢測、文本分類等，減少了在 imgcook 中從開發到上線這些模型的門檻，使得如此多的底層識别能力也具備快速疊代的可能性。
中台解決方案
而中台方面，也開放了一套基于 Pipcook 的智能中台方案。
中台的訴求，其實就是開發一個内部系統用于簡化流程，比如搭建系統、釋出系統以及營運工作台，它們往往是為了将一部分需要由開發承擔的工作，通過更簡單的互動和接口降低操作的門檻，進而可以讓整個團隊能一齊協作，提升産品效能。
但在這個過程中，中台的開發也遇到了一些問題，比如
- 并非所有團隊都具備前端開發能力，這大大增加了中台開發的門檻
- 并非所有中台都擁有很好的互動體驗，大部分小中台由工程師團隊自己完成，并未經過良好的互動設計
- 中台的需求往往千變萬化，這使得大中台的使用者和開發團隊總存在一些取舍
以上便是智能中台方案希望解決的問題所在，而我們的切入點首先是第一個問題，如何降低中台開發的門檻，而我們的答案便是通過設計稿生成中台前端代碼解決部分問題。
我們通過自動生成樣本的方式解決了設計稿收集困難的問題，這種方式覆寫了圖示、圖表、表單和表格這些基本素材。為了降低使用該方案的硬體門檻，也盡量使用了像 Tensorflow.js 和 mobilenet 這樣輕量化的架構和模型，讓訓練過程在 macbook 就能輕松完成。
imgcook 算法工程平台
在今年，imgcook 在集團内部也提供了全鍊路模型訓練的能力，從樣本生成/上傳，到選擇模型，最後到模型生成并使用，全部都可以在 imgcook 通過 GUI 的方式完成，而 Pipcook 在其中也承擔着非常重要的角色。
Pipcook Service 被部署在 GPU/CPU 的訓練叢集，然後在 imgcook 中通過內建 Pipcook SDK 來遠端調用 Pipcook 的訓練能力，菜鳥前端團隊也同樣采取了這種方式，搭建了屬于自己的 D2C 模型平台。
引子
在初步了解了 Pipcook 目前取得的一些進展後，接下來會從機器學習與前端的邂逅開始，講到 Pipcook 的初心，以及我們對于前端智能化的願景。相信讀者閱讀之後，就會對 Pipcook 的前世今生有一定的了解，同時也歡迎以各種方式參與進來！
前端與機器學習
提到前端智能化，就不得不說機器學習，因為這所謂的前端“革命”就是由機器學習/深度學習發起的，在一開始，機器學習作為人工智能的一門分支學科發展而來，主要研究的便是如何讓機器具備像人類一樣的學習能力。
但漸漸地，機器學習從人工智能領域慢慢向基礎領域拓展，由所謂的應用科學慢慢地變為向網際網路一樣的基礎設施，就像如今如火如荼的雲原生，它改變着人們進行産品研發和疊代的方式，機器學習一樣在慢慢地改變着人們在使用計算機的方式，從之前的面向細節的設計，轉而向面向學習的設計，當計算機具備了一些基礎的學習能力後，作為計算機工程師的我們，就需要學會如何去使用這種能力去替代一些腦（勞）動力。
然而真正的前端智能化并未如前面所說的那樣簡單。在如今的前端領域，存在着諸多的交叉領域，比如前端與嵌入式碰撞出了一些以 Web/JavaScript 為應用開發語言的嵌入式作業系統，再比如前端與區塊鍊碰撞出了可以計算 Gas 的 JavaScript 虛拟機，當然也包括前端智能化這樣一個領域。
但是，卻很少有人能定義出前端智能化到底碰撞出了什麼，因為這個組合詞描述的問題真的不小，是以我們先從最開始說起。
不得不說的 Tensorflow.js
可以說 Tensorflow.js 是前端智能化的先驅和前輩，卻也不是。
為什麼這麼說呢？它從 2017 年開源之初，主要的精力便是以支援在浏覽器端運作模型進行推理為主，在支援的粒度之外呢，Tensorflow.js 利用了像 WebGL、WebGPU 和 WebAssembly 對這個推理引擎做了各種各樣的優化，其目的也是圍繞着如何讓神經網絡在浏覽器中運作得更快、更高效。
是以 Tensorflow.js 很好地完成了作為一個神經網絡運作時/引擎的工作，但卻留下了兩個問題，一個是使用門檻的問題，另一個則是開發者生态。
盡管 Tensorflow.js 封裝了足夠簡單的 API，也提供了足夠詳細的文檔和教程，但對于前端工程師的入門來說，還是略顯晦澀，隻有當使用者了解機器學習/深度學習的一些知識後，才能很好地使用它。
造成這樣結果的原因無他，因為它本質上并不是為了讓前端開發者走向智能化的道路，而僅僅是為了能讓機器學習既有的開發者和學者們，通過 Tensorflow.js 具備在 Web 環境下進行模型推理的能力，進而拓展原先人工智能的使用者場景，比如：在 Web 浏覽器完成人臉識别、物體識别、進行照片的風格遷移等。
由此，便可大緻了解之前所說的 Tensorflow.js 是前端智能化的先驅，卻也不是。
第二個則是生态問題，在機器學習發展的這幾十年，Python 借着學術界和工業界的親和度紅利，已經形成了幾乎無法打破的生态壁壘以及完善度，即使号稱社群力量龐大的 JavaScript 圈子，要憑借短時間内有機地增長并取代 Python 生态也是做不到的。
這個問題幾乎會成為所有非 Python 腳本語言想要親近機器學習的門檻，Tensorflow.js 也不例外，幾乎是很難去做到讓學者和工程師遷移到 JavaScript 的鍊路上，為此就需要花費極大的精力去抹平那些存在于 Python 生态中的内容。
Node.js 與 Tensorflow
Tensorflow.js 的 Node.js 版本一直到比較滞後的版本才出現，在那之前，我也曾經基于 Tensorflow C API 寫過一個 yorkie/tensorflow-nodejs，但不久後我就停止更新了。
Node.js 對于 Tensorflow 來說，的确是一個比較尴尬的運作時，首先 Node.js 運作時環境并不像 Web 會給機器學習帶來一些新的互動場景，但是如果用來構模組化型，又如上一節所說，需要做大量的生态遷移工作。一旦 Python 生态有一些新模型時，往往都需要額外的遷移工作。
與 Node.js 形成對比的是 Tensorflow 的 Swift 版本，它基于 CPython 封裝了 Swift 調用 Python 的接口，進而不需要做任何的遷移工作，就可以使用 Swift 代碼調用所有 Tensorflow 在 Python 實作的功能。
CPython 是 Python 語言的官方實作，使用 C 語言編寫，是以叫 CPython，支援嵌入到任何環境，缺點是對于多線程/并行解釋支援不友好。
基于 Tensorflow Swift 的思路，Pipcook 創造了 Boa，它也是通過 CPython，提供了在 Node.js 中調用 Python 的能力，如下：
const { keras } = boa.import('tensorflow');
const { layers, Model } = keras;
class TestModel extends Model {
constructor() {
super();
this.conv1 = layers.Conv2D(32, 3, boa.kwargs({ activation: 'relu' }));
this.flatten = layers.Flatten();
this.d1 = layers.Dense(128, boa.kwargs({ activation: 'relu' }));
this.d2 = layers.Dense(10, boa.kwargs({ activation: 'softmax' }));
}
call(x) {
return this.conv1(x)
.flatten(x)
.d1(x)
.d2(x);
}
} 通過如上代碼，我們建構了一個4層的神經網絡模型類，以上代碼隻需要通過 Boa 安裝 tensorflow 包，即可運作成功。
在 Boa 的幫助下，對于 JavaScript 生态的提升非常大，維護者再也不需為了同步 Python 相關的代碼而花費精力，同時也能間接使用完整、穩定的 Tensorflow 功能。
Node.js 的機器學習生态
Boa 除了能協助減少 Tensorflow 使用的成本外，同樣對其他 Python 包一樣，比如 numpy、sklearn、pandas 等基礎庫，當然也包括 pytorch、tvm 等大型架構。
了解了 Boa 的背景後，現在重點說說 Node.js 的生态和機器學習生态融合所帶來的便利性。
對于不了解 Python 的前端開發者來說，上手的難度其實并沒有多簡單，對于新手而言、雖然文法可以快速入門，但包管理器、系統 API、熟悉各種庫以及對于語言的熟練程度都不是立馬能掌握的，此時如果能取長補短的話，帶來的便利性會大大提升。
比如我仍然可以使用像 Koa、Express、Midway 等架構去搭建服務，然後在路由控制器中使用 Boa 提供的橋接能力調用到 Tensorflow 來完成模型的推理服務，這樣對于一個已經熟悉 Node.js 生态的開發者來說，隻需要掌握 Tensorflow 相關的 API，而不需要學習如何使用 Python 來搭建 HTTP 服務。
正如上一個例子，Boa 并非是讓前端開發者用 JavaScript 來寫 Python 代碼，更大的價值還是生态的融合和補充，各自取長補短，在此基礎上，發展出适合前端生态圈自己的機器學習生态來。
通過以上三個小節，我們分别了解了機器學習在前端智能化的演進過程，從一開始的 Tensorflow.js 在浏覽器的使用，到 Tensorflow Node.js 的重新實作，再到通過 CPython 直接融合 Python 和 Node.js 生态，在我們的願景，未來的前端機器學習生态将繼續按照如下兩個方向進行：
- 以 Tensorflow.js、MNN 為代表的，主要針對 Web 環境的推理優化
- 以 Boa 為基礎發展出來的 Node.js 機器學習生态，主要通過複用兩個生态，來打通各工程和算法鍊路，實作前端機器學習的最優解
以上就是我們對于前端和機器學習目前問題的一些觀點，那麼接下來，我們會以 Pipcook 的視角，來講述關于 Pipcook 的故事。
智能化時代的 Node.js
大部分前端開發者一定對 Node.js 不陌生，從 2009 年 Ryan Dahl 開源以來，圍繞着 Node.js 展開的一系列标杆技術，包括：NPM、TypeScript、Koa、Webpack 等等，都與 Node.js 發展離不開。
Node.js 的誕生，不僅讓前端開發者的生态延展到了服務端開發的領域，也同樣觸及到了其他諸多領域，比如開發者們早就習慣了通過 commanderjs 或者 minist 來為自己開發簡單易用的指令行工具，再比如 Electron 通過 Node.js 和 Chromium 來開發跨端的用戶端應用，ReactNative/Weex 也間接使用了 Node.js 生态圈來幫助前端開發者建構移動應用，還有諸如 ShadowNode 和 IoT.js 這樣将 Node.js 應用在嵌入式領域。
Node.js 一直在賦能前端開發者，幫助他們做到一切他們想做的事情，而 Pipcook，希望成為智能化時代的 Node.js，賦予前端開發者們智能化的能力。
Pipcook、Node.js 與機器學習
如果要用一張圖來描述 Pipcook 與 Node.js 的關系，那麼上圖就是比較恰當的描述。對于 Pipcook 來說，我們的願景就是像 Node.js 一樣，成為前端工程師進階為機器學習工程師的一個簡單易用的平台。
那麼，前端工程師到底應該如何成為機器學習工程師呢？這裡的機器學習工程師又是什麼工種呢，要負責哪些事情，需要掌握什麼樣的知識？
首先我們來看看，對于 Node.js 體系下的服務端工程師都做了些什麼。
小王是一家創業公司的 Node.js 主程，公司的主要業務是一套 O2O 的線上交易系統，全部使用 Node.js 完成，那麼小王需要完成的工作包括根據交易系統的主鍊路，設計符合系統要求的資料庫、消息隊列、子服務以及網關服務等，資料庫方面使用了 MongoDB，消息隊列用了 ZMQ 和 Resque，網關使用 Nginx 配置完成。
小狼是一家大型網際網路公司的 Node.js 工程師，日常工作是根據業務需求，使用 Node.js 來研發業務系統，其中涉及到的技術則是通過 Node.js 對接公司内部的資料庫系統 XDB、内部消息隊列 XMQ。在業務上線後，發現系統的某個請求的 QPS 遠遠達不到實際的使用要求，是以通過針對個别場景的優化，并引入緩存和修改索引，完成了線上的要求。
看完了小王和小狼的經曆，其實可以看出來要完成這些工作，對于前端工程師并不容易，因為需要了解很多在伺服器開發領域會用到的概念，比如資料庫設計、消息隊列、網關等，同時問題的優化手段與以往的前端領域也是不同的，唯一相同的點是使用了相同的語言。
這有點像是一個國家，會分為各種不同的工種，有負責軍事的軍人，負責政治的政客、負責經濟的商人以及負責學術的學者，但他們同時都使用一種語言進行交流，當一名軍人退役後想要從商，同樣需要學習成為一名商人所需的素質和技能。
那麼 Node.js 也是如此，一名前端工程師與 Node.js 工程師都使用 JavaScript，轉型所需的知識和技能是必須要掌握的，不過 Node.js 會提供轉型所需的工具和平滑的學習路線。要成為一名機器學習工程師，也需要掌握機器學習的基礎知識，而 Pipcook 則是通過工具，幫助開發者更快地完成内化學習的過程。
接下來，我們就來看看 Pipcook 工具箱中都有哪些利器。
如何使用機器學習的生态
正如上一節末尾所說：
Boa 便是 Pipcook 工具箱中的利器之一，它快速地填充了前端與機器學習生态的離距，讓兩個生态能夠更加無縫地融合，那麼我們就來看看它是如何融合兩個生态的。
無論是 JavaScript 還是 Python，它們都是一門腳本語言，需要通過額外的虛拟機（V8 或 CPython）才能執行代碼，本文将會從更宏觀的角度來看待這個虛拟機這個技術問題。
虛拟機，顧其名思其義，就是在一個世界中模拟出另一個世界。那麼，可以這麼了解，虛拟機其實就是一個世界，這個世界上會有花、有草、有人，用程式設計領域的概念來說，就是有“對象”，那麼對于不同的虛拟機，就像是不同的世界，不同世界的遊戲法則就不同，對于不同“對象”的定義也不同，是以可以把 JavaScript 和 Python 看作是兩個不同的世界，并且由于規則的不同，衍生出來的生态也不同。
那麼要融合這兩個不同的世界，應當如何呢？如果要将兩個世界中的每個類别、對象都一一對應上去，這個工作是極大的，而且每個世界本身也在不斷地發展和壯大，是以永遠也不可能完成這個對應關系。
那麼得益于 Python 世界的架構之初，這優雅的設計（對象模型）使得 Python 萬物都可歸納于幾類，并且對身處高階世界的我們開放了控制對象的接口，這就使得我們能從 JavaScript 世界中通過這個接口來控制 Python 世界中的萬物，進而讓生活在 JavaScript 中的人們具備使用 Python 世界資源的能力。
希望上面這個生動的例子，可以幫助更好地了解 Pipcook 在融合 JavaScript 與 Python 生态所做的事情，那麼接下來，我們會從性能上來看看使用 Boa 時所帶來的開銷是否可以接受。
我們将使用以下兩種調用方式來進行對比：a）通過 Boa 調用 Python，b）全部使用 Python，答案是非常明顯的，就是性能上至少 a = b，極大可能 a > b。
通過上圖，無論對于 Boa 還是 Python，最底層都是在使用 Python Objects，它包含了 Python 中所有函數的定義、變量的定義以及操作符的定義等等，對于執行純 Python 代碼而言，它通過 CPython 的解釋器将代碼轉換成對 Python Objects 的調用。
對于 Boa 來說，也是一樣的，由 v8 完成對 JavaScript 代碼的解析，然後再将對應的操作映射到 Python Objects，是以兩者的差異就在于 v8 和 Python Interrupter 對于各自代碼的解釋/執行效率，那麼對于這一點來說，Python 和 JavaScript 都有各自的優化政策和方法，是以幾乎是不相伯仲的。
上述所表達的是，雖然聽上去是要從 JavaScript 調用到 Python，但其實從實作的機制來說，并非将 JavaScript 轉成 Python 代碼，然後再由 Python 解釋器執行，而是直接與 Python 底層的對象互動，這樣并不會增加額外的性能開銷，是以可以放心使用。
在性能問題解決之後，我們再說一下它對于前端機器學習的意義。
在有了它之後，我們不再需要像 nodejieba，tfjs-node 這樣的橋接庫了，它就像打開了一扇通往機器學習新世界的大門，從此 JavaScript 的世界中，可以以非常低的成本使用到最成熟、最前沿的機器學習生态了。
前端機器學習的領域語言
什麼是領域語言呢？或者我換一種說法 —— DSL，Pipcook 為了隐藏掉一些不必要的技術細節，基于 JSON 定義了一套用來描述如何訓練模型的語言，叫 Pipeline。
我們首先從一個簡單的 Pipeline 例子開始：
{
"plugins": {
"dataCollect": {
"package": "@pipcook/plugins-mnist-data-collect",
"params": {
"trainCount": 8000,
"testCount": 2000
}
},
"dataAccess": {
"package": "@pipcook/plugins-pascalvoc-data-access"
},
"dataProcess": {
"package": "@pipcook/plugins-tensorflow-image-classification-process",
"params": {
"resize": [224, 224]
}
},
"modelDefine": {
"package": "@pipcook/plugins-tensorflow-mobilenet-model-define",
"params": {}
},
"modelTrain": {
"package": "@pipcook/plugins-image-classification-tensorflow-model-train",
"params": {
"epochs": 15
}
},
"modelEvaluate": {
"package": "@pipcook/plugins-image-classification-tensorflow-model-evaluate"
}
}
} Pipeline 的結構看上去比較簡單，基本上是由不同的插件（plugins）構成，每個插件節點由 package 和 params 組成，前者指定了插件的包名，後者則指定了插件所需的參數。
我們将一個完整的訓練模型的過程，通過這種聲明式的方式，分為了不同的節點，每個節點定義明确的輸入與輸出，而對于想要訓練模型的開發者而言，隻需要配置對應的插件和參數即可。
比如當我想要更換上述 Pipeline 的資料集，那麼修改以下節點即可：
{
"plugins": {
"dataCollect": {
"package": "@pipcook/plugins-image-classification-data-collect",
"params": {
"url": "資料集的位址"
}
},
...
}
} 想要浏覽官方插件的可以點選這裡： https://github.com/imgcook?q=pipcook-plugin&type=&language =
通過這種聲明式的方式，可以幫助使用者在不需要了解任何代碼的情況下，就能用自己的資料集輕松訓練出自己的模型了，訓練完成後，會生成如下檔案：
output
┣ logs
┣ model
┣ package.json
┣ metadata.json
┗ index.js 在 output 目錄下執行 npm 安裝指令，即可通過 index.js 使用訓練好的模型了。
import * as predict from './output';
predict('your input data'); 使用 Pipcook 進階機器學習
上一節中介紹了我們如何降低前端開發者訓練一個模型的門檻，那麼本節将以之前提到的插件開發展開，說說如何通過 Pipcook 進一步學習機器學習的知識。
在機器學習界，流傳着一句這樣的名言：特征工程（Feature Engineering）決定着機器學習的上限，而模型要做的隻是無限地逼近它。對于 Pipcook 而言，同樣需要幫助所有開發者解決特征工程和模型訓練的問題，是以 Pipeline 将插件基本分為了兩大類：
- 資料類（DataCollect/DataAccess/DataProcess）解決資料和特征工程的問題
- 模型類（ModelDefine/ModelTrain/ModelEval）解決模型訓練的問題
特征工程是指在定義好一個機器學習任務後，定義真實資料中哪些特征值會被輸入到模型中去學習，這就好比當你分派一個任務給某人時，我們需要把任務的目标分解下去，并制定一些名額（KPI）去衡量，然後執行者就會通過這些名額去學習如何做好這件事，這個分解任務的過程就是特征工程，而後面執行者去學習的這個過程便是模型訓練。
雖然特征工程描述起來簡單，但真實的場景千變萬化，需要處理的資料類型也多種多樣，是以這是一項需要經驗積累慢慢成長的過程。但對于前端開發者而言，還缺少一些關鍵的工具庫，在 Python 生态下，有像 opencv、sklearn、numpy、pandas 這些強有力的工具能夠輔助特征工程，不過好在 Boa 能夠暫時幫我們補足這塊劣勢，通過 Node.js 也能快速使用這些工具。
是以，第一條成長路線便是通過幫助 Pipcook 拓展資料類插件，積累自己對于特征工程的經驗，在這個過程中的你，仍然需要閱讀這些倉庫的文檔，去了解每個函數在特征工程中的使用方式，最後以插件的形式提供給 Pipeline 使用者。
Pipeline 将訓練任務分成不同的類型放在不同節點去執行，這意味着它帶來了極大的靈活性，當資料不改變的情況下，使用者可以通過更換 ModelDefine 插件來對比模型效果，比如一個圖檔分類任務，當使用 mobilenet 效果不佳時，可以切換為 resnet 模型插件來對比效果，是以對于想在模型這條路上進階的開發者而已，仍然可以通過開發或者優化模型插件的方式來學習相關的底層知識。
未來與展望
機器學習的勢能已經讓前端智能化勢在必行，而 Pipcook 正如之前所說的一樣，會成為智能化時代的 Node.js，但對于今天的 Pipcook 而言是遠遠不足的，未來的一年，我們仍然會圍繞着機器學習生态和如何降低門檻為目标，讓大家更輕松地使用一些已經成熟的能力，來賦能前端社群。
生态再融合
如今的 Boa 借助于 Python 生态，算是補足了一部分機器學習的能力，但在使用的體驗上，還是有極大的提升空間。比如從安裝的角度來看，現在要使用 Boa，需要同時安裝 Python 和 Node.js，另外由于 Python 本身的限制，對于像 ARM 或 PowerPC 這樣的平台，支援起來并不容易。
是以如何更好地整合 Python/Node.js 的生态，以及提供更快、更輕以及相容性更好的 Python & Node.js 運作時，将是未來 Boa 努力的方向。
另一方面，使用者在使用 Boa 時，仍然需要閱讀 Python 的文檔，這一點也是我們期望改變的現實，Pipcook 團隊期望借助于 TypeScript、Python Interface(pyi) 以及一些源碼了解的能力，讓未來的 Boa 寫起來就像在用 JavaScript/TypeScript 一樣簡單。
擁抱 Web
Web 最大的優勢在于快速、跨平台以及輕量，現在要把訓練好的模型運作起來，仍然需要更高的成本，比如一個通過 Tensorflow（借助 Boa）訓練的模型，要部署到 Node.js 服務上，需要重新安裝 Boa 以及其他的 Python 依賴，這個過程往往又會浪費使用者大量的時間。
我們做過一個試探性的嘗試，在模型訓練完，使用 TVM 将模型直接編譯成 WebAssembly 格式，這樣使用者在部署模型時，隻需要在 Web 或 Node.js WASI 上加載編譯好的檔案就好，分發時不再需要安裝任何 Node.js 或 Python 的依賴，是以我們會将這一功能進行完整地支援。
TVM，Tensor Virtual Machine，是一種深度神經網絡的編譯器，用于将基于 Python 神經網絡編譯為更适合目标環境/機器運作的本地代碼，類似的産品還有 MLIR 和 Tensorflow XLA。
要做到上面所說的，完整地生成與訓練時無關的運作時代碼，我們還需要對目前特征工程，即資料類插件的部分進行重構，但現狀是這些插件仍然依賴于 Python 生态，而這些代碼是無法被 TVM 編譯為 WebAssembly 的。是以我們已經在和 danfojs 團隊共同開發 imgcook/datacook，它被定義為面向 Web 環境（也包括 Deno 和 Node.js）的特征工程庫。當它完成後，就能做到使用 TVM 将所有訓練時代碼編譯為面向 Web 環境的運作時代碼了。
另外，我們也希望面向 Web 端提供一些真正開箱即用的 Pipeline，一方面是為了降低使用門檻，讓使用者不需要伺服器就能用上 Pipcook 的能力，另一方面則是希望依托于浏覽器端，真正為前端開發者所服務的使用者，提供下一代的互動體驗。
從離線到線上
Pipcook 目前的應用場景大部分還是離線的開發者服務場景，并未直接地為使用者服務，這就讓 Pipcook 本身的業務價值并未完全發揮出來。
是以在新的一年，Pipcook 會基于一些推薦場景，打通從 MaxCompute 到推薦服務，再到端智能的鍊路，這對于 Pipcook 會提出一些全新的挑戰，然而，我們會全面擁抱雲原生，讓前端開發者零門檻也能搭建穩定可靠的推薦服務，實作前端智能化所帶來的業務價值。
最後，真誠地感謝過去對 Pipcook 提出寶貴意見和貢獻的開發者們，希望在接下來的一年，能一起，繼續探索通往前端智能化的道路。
關注「Alibaba F2E」
把握阿裡巴巴前端新動态