現(xiàn)如今，以大數(shù)據(jù)、云計算、人工智能、工業(yè)互聯(lián)網(wǎng)為代表的數(shù)字科技正飛速發(fā)展，帶領(lǐng)技術(shù)與產(chǎn)業(yè)向數(shù)字化、智能化的方向展開變革——數(shù)字科技正逐漸成為推動世界經(jīng)濟(jì)高質(zhì)量發(fā)展的核心驅(qū)動力，數(shù)字經(jīng)濟(jì)應(yīng)運(yùn)而生。而對于企業(yè)來說，數(shù)字化轉(zhuǎn)型則是發(fā)展數(shù)字經(jīng)濟(jì)的必由之路。

（數(shù)學(xué)）模型，作為企業(yè)數(shù)字化轉(zhuǎn)型的重要資產(chǎn)正受到越來越多的矚目——從“微觀”到“宏觀”再到“新的微觀”，模型能夠幫助人們撥開迷霧、簡化人們的認(rèn)知成本。然而目前，模型在開發(fā)、應(yīng)用的工作流中也存在不少普遍性的問題，很大程度地影響著效率。下文將聚焦于此，引入 ModelOps 的概念，以探尋解決此類問題的可行性。

從真實世界中模型開發(fā)應(yīng)用的場景說起

本節(jié)將以三個真實的典型案例闡述模型在各行業(yè)企業(yè)的使用現(xiàn)狀與現(xiàn)存問題。除所屬行業(yè)各不相同外，三個場景下模型在對應(yīng)企業(yè)生產(chǎn)中發(fā)揮的具體作用也大相徑庭。

場景一

當(dāng)模型參與到企業(yè)產(chǎn)品設(shè)計、研發(fā)、決策生產(chǎn)的全流程中…

企業(yè) A 是一家航空航天制造公司，主要研制中大型運(yùn)載火箭等系列工業(yè)產(chǎn)品，數(shù)學(xué)模型作為強(qiáng)有力的工具手段被廣泛應(yīng)用于其火箭產(chǎn)品設(shè)計研發(fā)的全流程中——得益于計算機(jī)技術(shù)水平的飛速發(fā)展，多學(xué)科的研發(fā)人員能夠發(fā)揮其不同的專業(yè)能力，通過不同的建模軟件、編程語言輸出階段性的產(chǎn)研成果。

而針對步驟與步驟間的模型成果傳遞，由于企業(yè) A 需要傳遞的不是模型文件，而是模型跑出的結(jié)果，因此他們選用傳統(tǒng)文檔作為載體，以自然語言 + 截圖的形式記錄模型相關(guān)公式、數(shù)據(jù)、關(guān)鍵計算過程、計算結(jié)果及分析內(nèi)容。而這樣一份以文檔為載體的模型成果在后續(xù)工作中將參與以下幾個步驟：被引用，前序模型跑出的結(jié)果可能是下一階段模型的輸入；被匯報，傳統(tǒng)文檔將作為模型成果展示的重要材料匯報給上級人員，由他們拍板做出決策；被修改，火箭研發(fā)的相關(guān)參數(shù)需要成百上千次的實驗，繁復(fù)的修改、優(yōu)化需一應(yīng)被記錄于模型成果中。

而企業(yè) A 在重復(fù)進(jìn)行上述操作后，敏銳察覺到了該流程中存在系列問題：

對于產(chǎn)品設(shè)計研發(fā)流程本身來說，目前的操作存在技術(shù)上的壁壘——由傳統(tǒng)文檔承載的所謂“成果”不能精確表達(dá)設(shè)計元素之間的關(guān)系與模型結(jié)果，設(shè)計語言及模型語言在與自然語言進(jìn)行轉(zhuǎn)化時常存在歧義，受限于撰寫人的主觀想法與文字能力，這其中的“人為誤差”少則降低工作效率，多則影響模型相關(guān)的人為決策。

而對于研發(fā)流程中涉及到的各部門工作人員，工作流也并未完全打通——工業(yè)產(chǎn)品設(shè)計研發(fā)作為多學(xué)科系統(tǒng)工程，由于各部門人員所選用的建模軟件、編程語言都各有不同，極容易出現(xiàn)協(xié)同困難，最終形成“信息孤島”。

最后，模型的成果與成果間存在傳承關(guān)系，產(chǎn)研流程本身牽一發(fā)而動全身，上游模型成果中微小的改變所引起的連鎖效應(yīng)需要相關(guān)人員在下游成果中手動一一更迭，不僅繁瑣，且從下游成果中難以追溯首次發(fā)生改變的模型究竟存在于哪一步。

場景二

當(dāng)模型賦能企業(yè)的生產(chǎn)調(diào)優(yōu)…

企業(yè) B 扎根國內(nèi)新能源業(yè)，主營風(fēng)機(jī)發(fā)電業(yè)務(wù)。不同于企業(yè) A 在產(chǎn)品設(shè)計研發(fā)全流程中都有數(shù)學(xué)模型的參與，企業(yè) B 在生產(chǎn)風(fēng)機(jī)階段主要使用傳統(tǒng)辦法，而需要模型介入的是風(fēng)機(jī)投入使用后的發(fā)電場景。

企業(yè) B 基于 Pycharm 開發(fā)模型，一方面根據(jù)不同風(fēng)機(jī)發(fā)電時的實際風(fēng)電風(fēng)場環(huán)境，輸入環(huán)境數(shù)據(jù)調(diào)用模型，進(jìn)行風(fēng)機(jī)使用時的參數(shù)調(diào)優(yōu)，并做使用預(yù)警；另一方面基于模型，比對風(fēng)機(jī)實際運(yùn)行情況與風(fēng)機(jī)出廠時的原始發(fā)電數(shù)據(jù)，分析風(fēng)電業(yè)務(wù)的關(guān)鍵指標(biāo)，進(jìn)行風(fēng)機(jī)的生產(chǎn)調(diào)優(yōu)。

而優(yōu)化過后，企業(yè) B 會生產(chǎn)出新的風(fēng)機(jī)、使用新的運(yùn)行參數(shù)，此時原有模型不再適用，開發(fā)人員將優(yōu)化原模型以匹配新場景——生產(chǎn)調(diào)優(yōu)結(jié)果反哺建模工作，企業(yè) B 因此實現(xiàn)風(fēng)機(jī)、模型一輪輪的循環(huán)迭代。

然而，由于模型本身具備特殊性（詳見第二節(jié)），它們的優(yōu)化迭代并不僅僅是“將 A4 紙上的字跡劃掉重寫”，而意味著大量“版本管理”工作。事實上，模型本身及一切與模型相關(guān)聯(lián)的元素，包括開發(fā)環(huán)境、數(shù)據(jù)、項目、訓(xùn)練記錄等都需要版本管理，且相關(guān)元素的版本管理不是“孤立的”，而要與模型本身存在“映射關(guān)聯(lián)”。打個比方，一篇論文需要引用一份數(shù)據(jù)，但此時數(shù)據(jù)出現(xiàn)更新，撰寫者在保留原始數(shù)據(jù)的基礎(chǔ)上修改數(shù)據(jù)、記錄修改時間，這是對數(shù)據(jù)本身的版本管理，而論文的引用部分也要做出相應(yīng)修改，這就是映射關(guān)聯(lián)。作為具備一定規(guī)模的中大型企業(yè)，在繁復(fù)的版本管理工作前，企業(yè) B 不堪其憂。

另一方面，企業(yè) B 還面臨計算資源調(diào)度方面的問題。由于上萬臺風(fēng)機(jī)的迭代優(yōu)化都是持續(xù)且同步的，涉及到數(shù)量繁多的模型計算工作，而每個企業(yè)的計算資源又是有限的，企業(yè) B 目前首先希望能夠充分有效地利用全部資源，其次需要一套合理的計算資源調(diào)度規(guī)則。企業(yè) B 的技術(shù)人員不希望再花費精力于計算資源的分配使用上，而可以專注于模型研發(fā)。

場景三

除了后臺生產(chǎn)，企業(yè)前臺工作中同樣也有模型的廣泛參與…

企業(yè) C 是一家供應(yīng)鏈咨詢公司，為食品、日化等快消、零售企業(yè)提供供應(yīng)鏈相關(guān)的解決方案，如選品下單系統(tǒng)等。企業(yè) C 內(nèi)部開發(fā)、部署模型主要供銷售人員調(diào)用以完成產(chǎn)品售賣、提升銷售效率——基于所開發(fā)的模型，銷售人員通過輸入客戶背景信息等能夠完成用戶畫像構(gòu)建與高潛客戶識別，通過輸入客戶與客服的對話內(nèi)容能夠完成語音語義分析等智慧營銷動作。

模型在企業(yè) C 中的應(yīng)用場景十分清晰，但其同樣面臨工作流上的種種問題：

首先，在企業(yè) C 內(nèi)部，開發(fā)部署模型的人員與實際調(diào)用模型的人員是不同的，一方面，現(xiàn)有的模型研發(fā)方式忽略了公司內(nèi)部跨部門、跨角色的協(xié)同需求；另一方面，企業(yè) C 缺少供開發(fā)人員與銷售人員同時使用的、統(tǒng)一的模型開發(fā)管理平臺，因此模型的開發(fā)與管理工作是割裂的——類比一下便是，在計算機(jī)內(nèi)完成文檔撰寫后，無法將文檔置于計算機(jī)文件夾內(nèi)收納，而需要將其打印出來統(tǒng)一收于實體抽屜。

其次則是模型的部署調(diào)用問題。企業(yè) C 場景下，模型主要面向公司一線的內(nèi)部人員，模型的部署工作不應(yīng)該是模型全生命周期中的重點，但由于目前缺少敏捷部署模型的途徑，因此浪費了模型開發(fā)的時間。另外，銷售人員調(diào)用模型在企業(yè) C 中屬于高可用的并發(fā)場景，服務(wù)器能否支撐是首當(dāng)其沖的問題；而模型的調(diào)用記錄應(yīng)如何完整記錄并管理，才能使其反哺相關(guān)的迭代優(yōu)化工作也正是企業(yè) C 所思考的問題。

基于以上的種種問題，企業(yè)面對模型工作流的期待是什么？

為了能夠順暢地開發(fā)并應(yīng)用數(shù)學(xué)模型，企業(yè)們期望：

首先，對于模型本身來說，從開發(fā)訓(xùn)練，到部署調(diào)用，再到優(yōu)化迭代，每一個步驟都應(yīng)該是極致順滑的，如，開發(fā)訓(xùn)練階段有合適的環(huán)境即開即用；部署調(diào)用階段若沒有特殊需求，應(yīng)能夠做到一鍵部署、一鍵調(diào)用；優(yōu)化迭代步驟不需要開發(fā)人員花費額外的精力復(fù)現(xiàn)環(huán)境、做版本管理等。

其次，企業(yè)希望模型在公司內(nèi)部跨部門、跨角色的全工作流程中能夠跑通，不存在技術(shù)、信息上的壁壘。例如，模型在成果傳遞時信息傳達(dá)能夠在無誤、無歧義的基礎(chǔ)上做到高效、便捷；而對于企業(yè)模型工作流上不同角色的人員來說，希望能夠發(fā)揮其自身優(yōu)勢、做到有效協(xié)同。

最后，在計算資源的問題上，企業(yè)們希望有合理的調(diào)度規(guī)則，能夠使計算資源最大程度地跟得上使用需求。

接下來，我們將引入 ModelOps 的概念

為解決上述應(yīng)用場景中出現(xiàn)的種種問題、匹配企業(yè)們在模型工作流中的種種需求，我們將在本節(jié)引入 ModelOps 的概念。那么首先，ModelOps 是什么？

ModelOps 是…

相信大部分 IT 從業(yè)者們都對 XOps 的概念并不陌生。在經(jīng)歷了 DevOps 與 MLOps 的時代后，2018年12月，IBM Research 的 AI 研究員 Waldemar Hummer 與 Vinod Muthusamy 在 IBM Programming Languages Day 上首次提出 ModelOps。作為 MLOps 的突破與延申，ModelOps 面向一切“可復(fù)用、獨立于平臺且可組合的 AI 工作流的編程模型”，提供強(qiáng)大的管理能力解決模型開發(fā)與模型部署之間的問題，確保所有模型都能夠運(yùn)行投產(chǎn)，并能夠?qū)⒓夹g(shù)與業(yè)務(wù)績效指標(biāo)聯(lián)系、管理相應(yīng)風(fēng)險。

無獨有偶，國際知名行研咨詢公司 Gartner 于2021年9月發(fā)布了有關(guān)“AI 信任、風(fēng)險和安全管理”的 Market Guide，Gartner 認(rèn)為，ModelOps 'is primarily focused on the end-to-end governance and life cycle management of all analytics, AI and decision models'。

綜合兩方觀點，我們可以認(rèn)為，ModelOps 專注于模型全生命周期的端到端管理，目的是解決模型工作流中出現(xiàn)的種種問題。

從 ModelOps 中的 Model 談起

現(xiàn)在我們已經(jīng)知道了 ModelOps 是可以幫助解決模型工作流中種種問題的途徑，但還有些概念還未被界定，比如 ModelOps 具體面向哪些 Model？Ops (Operations) 又具體包含哪些步驟？

作為數(shù)字化轉(zhuǎn)型的重要資產(chǎn)，對于許多企業(yè)來說，應(yīng)用模型的根本目的是“從數(shù)據(jù)中找尋規(guī)律”，因此 ModelOps 中的 Model 應(yīng)泛指一切能夠從數(shù)據(jù)中找尋規(guī)律的模型?；貧w到 Gartner，Gartner 認(rèn)為 ModelOps 應(yīng)面向人工智能與決策模型，決策模型包括機(jī)器學(xué)習(xí)、知識圖譜、規(guī)則、優(yōu)化、語言學(xué)和基于 Agent 的模型等，是一個比較寬泛的定義。

正因為如此，ModelOps 中的 Model 不局限于 MLOps 中的 Machine Learning，也不局限于 AI 中的 Artificial Intelligence，因為 ML 或 AI 都只是高級模型中的一種。事實上，國內(nèi)大部分企業(yè)的大部分時間在使用的都是更基礎(chǔ)的決策模型，而由于種類各異、部署環(huán)境也各不相同，這些基礎(chǔ)決策模型的載體與流程反而是缺乏重視的，這也就是在 MLOps 的基礎(chǔ)上提出 ModelOps 這一概念的原因之一。

ModelOps 中的 Ops (Operations) 具體包含…？

作為全球最具影響力的獨立研究咨詢公司之一，F(xiàn)orrester 認(rèn)為模型的全生命周期管理有以下六個步驟：

1. 理解數(shù)據(jù)：從真實世界的眾多數(shù)據(jù)中篩選與待解決問題相關(guān)的一批——對應(yīng)到第一節(jié)的場景二，即從風(fēng)機(jī)發(fā)電這一真實世界，挑選真正與發(fā)電效果息息相關(guān)的環(huán)境數(shù)據(jù)，諸如“周期”、“范圍”等。

2. 準(zhǔn)備數(shù)據(jù)：運(yùn)用計算機(jī)技術(shù)處理從真實世界中取出的相關(guān)數(shù)據(jù)，使其成為有研究價值的“研究數(shù)據(jù)集”。

3. 開發(fā)模型：通過統(tǒng)計學(xué)方法或機(jī)器學(xué)習(xí)等算法，研發(fā)能夠解決真實世界問題的模型，回歸到第一節(jié)的場景中，三類模型分別解決火箭的設(shè)計問題、風(fēng)機(jī)的高效運(yùn)營問題及銷售的效率問題。

4. 評估：開發(fā)人員將對模型進(jìn)行數(shù)次的訓(xùn)練與測試，以確保模型在部署后能夠完成工作任務(wù)。

5. 部署：將模型投入企業(yè)真實的生產(chǎn)工作中。

6. 監(jiān)控：監(jiān)控模型在真實世界的運(yùn)作情況，一般來說，模型在真實世界的使用情況會與研發(fā)情形有所出入，那么就會涉及到模型的優(yōu)化迭代，隨后，回歸到模型全生命周期管理的第一步，理解數(shù)據(jù)。

除了由 Forrester 提出的六個步驟外，我們認(rèn)為還有第七個步驟同樣隱藏于 ModelOps 的 Operations 中，那就是輔助決策，在此我們會提到 BI（Bussiness Intelligence）。商務(wù)智能，是人們對于技術(shù)的某種期望，期望能夠通過技術(shù)的手段實現(xiàn)某種智能化甚至是自動化，輔助人們做出正確的商業(yè)決策。作為決策的輔助工具，BI 最典型的應(yīng)用是儀表報表，通過儀表報表，企業(yè)管理層能夠了解企業(yè)的經(jīng)營狀況，隨后通過人為分析進(jìn)行決策與行動。而企業(yè)中，模型同樣應(yīng)該具備該功能。例如場景一，技術(shù)人員通過模型解決火箭的研發(fā)設(shè)計問題，將模型跑出的成果交由上級，由他們拍板定論后，設(shè)計成果才會投入生產(chǎn)。

將 Model 視作 BI 的典型應(yīng)用之一，ModelOps 的 Operations 因此有理解數(shù)據(jù)、準(zhǔn)備數(shù)據(jù)、開發(fā)模型、評估、部署、輔助決策、監(jiān)控七個步驟。

從全局看，打通上述 Operations 的全流程是解決模型資產(chǎn)管理、模型穩(wěn)定性、模型風(fēng)險、模型持續(xù)運(yùn)營等問題的大前提，由此，才能夠真正提升機(jī)器學(xué)習(xí)、AI 等其他決策模型的開發(fā)與運(yùn)行服務(wù)效率。

為什么非 ModelOps 不可？

前文提及，ModelOps 的概念是在 DevOps 與 MLOps 之后被提出的，那么為什么一定是 ModelOps？ModelOps 相比于傳統(tǒng)的 DevOps、MLOps，對于企業(yè)中各類模型的適用性高在哪里？

DevOps 源于軟件工程，是一種強(qiáng)調(diào)軟件開發(fā)、IT 運(yùn)維及質(zhì)量保障溝通合作的管理方式，通過自動化軟件交付與架構(gòu)變更的流程，使得軟件的構(gòu)建、測試、發(fā)布更加快捷、頻繁、可靠。然而，DevOps 主要面向業(yè)務(wù)軟件，而 ModelOps 面向的是決策模型。對于 ModelOps 來說，針對模型“優(yōu)化迭代”的管理是經(jīng)久不衰的主旋律，這是由于模型具備以下特質(zhì)：

1. 模型的輸出在大部分場景沒有最優(yōu)的概念，且隨著數(shù)據(jù)的變化、業(yè)務(wù)的變化，天生需要不斷迭代；

2. 模型的輸入是數(shù)據(jù)流，數(shù)據(jù)會隨著業(yè)務(wù)變化，且數(shù)據(jù)的積累反過來可以指導(dǎo)模型迭代；

3. 模型的效果評價在大部分場景下是個異步的動作，異步的周期可能很長，模型效果數(shù)據(jù)的獲取會指導(dǎo)模型的選擇與模型的優(yōu)化；

4. 模型的研發(fā)過程會伴隨著特殊的三要素：數(shù)據(jù)、鏡像、算力；

5. 模型與模型之間可能存在依賴關(guān)系；

6. 模型經(jīng)常用于決策輔助，所以生產(chǎn)模型的過程也需要作為成果的一部分被考慮。

另一方面，DevOps 缺乏對于“優(yōu)化迭代”的關(guān)注，針對業(yè)務(wù)軟件，DevOps 的全流程到“交付”步就幾乎停止了?？梢哉f，ModelOps 是 DevOps 在面向決策模型的發(fā)展與更新時衍生出的新體系、新理念、新技術(shù)。

而當(dāng)比較對象是 MLOps 時，事情會變得更簡單。正如機(jī)器學(xué)習(xí)是 AI 與決策模型的一個子集，MLOps 也是 ModelOps 的一個子集。與僅關(guān)注 Machine Learning 且僅將 Ops 重點放在“開發(fā)與運(yùn)維”本身的 MLOps 相比，ModelOps 關(guān)注全種類的 AI 與決策模型，且作為“模型全生命周期”的管理手段，ModelOps 覆蓋模型從出生到消亡（被迭代）的一切步驟。

ModelOps 扎根于 DevOps，又是 MLOps 的擴(kuò)展。然而，當(dāng)前 ModelOps 尚未達(dá)到與 DevOps 相同的成熟度。據(jù) CB Insights 中國調(diào)查顯示，各企業(yè)中平均仍有87%的決策模型從未真正上線運(yùn)行，ModelOps 的體系因此亟待進(jìn)一步的開發(fā)與拓展。

基于 ModelOps 的產(chǎn)品實現(xiàn)

可以看出，ModelOps 本身是一個比較概念化的東西，告訴人們“對模型做端到端的全生命周期管理”能夠解決“模型工作流中的種種問題”，那么如何實現(xiàn)這種管理？2019年6月，ModelOps 的提出者 Hummer 與 Muthusamy 對其既往觀點進(jìn)行了擴(kuò)展，他們認(rèn)為，應(yīng)將 ModelOps 視作一個基于云的框架或平臺。經(jīng)過各種探索，概括地說，ModelOps 概念的具象實現(xiàn)是建立自動化、標(biāo)準(zhǔn)化、流程化、可視化的模型統(tǒng)一運(yùn)營管理平臺。

數(shù)據(jù)科學(xué)協(xié)同平臺 ModelWhale 基于 ModelOps，將其作為底層邏輯設(shè)計產(chǎn)品，期待為上述場景下各行業(yè)企業(yè)中模型工作流的種種問題提供具體的解決方案。本節(jié)將從模型的研發(fā)優(yōu)化迭代階段、模型的交付階段、及模型工作流中跨部門跨角色的協(xié)作協(xié)同，三個 Modelops 在考慮的問題出發(fā)，展開討論。

模型的研發(fā)與優(yōu)化迭代

在模型的研發(fā)與優(yōu)化迭代階段，ModelWhale 的產(chǎn)品關(guān)鍵詞是“版本管理”。首先，讓我們捋一下版本管理與 ModelOps 所看重的模型迭代優(yōu)化之間的關(guān)系：事實上，一切需要更迭的事物都有做版本管理的必要，例如，在撰寫畢業(yè)論文時做出的每次大改，大部分人比起直接在原文修改，更傾向于新建一個 .docx 并標(biāo)注上日期，因為前一個版本也還有再利用的可能性。那么為什么似乎只有模型的版本管理聽起來格外繁重呢？首先，模型所關(guān)聯(lián)的元素太多了，包括開發(fā)環(huán)境、數(shù)據(jù)、項目、訓(xùn)練記錄等每一項，都有做版本管理的必要；其次，模型的開發(fā)應(yīng)用是多人協(xié)作的過程而非“單打獨斗”，不同人員產(chǎn)出的不同成果同樣也是“版本”的一種。綜上，ModelWhale 將版本管理作為重點，為內(nèi)部的所有生產(chǎn)資料都提供了相應(yīng)功能，用戶們可以隨時進(jìn)行數(shù)據(jù)、項目代碼等的版本比對與版本回溯。

當(dāng)然，僅僅“孤立的”版本管理還是不夠的，在場景二中我們還提到過“映射關(guān)聯(lián)”的概念，以確保模型相關(guān)的不同元素在版本更新后不會出現(xiàn)關(guān)聯(lián)上的偏差。ModelWhale 為數(shù)據(jù)、研究項目、模型成果提供映射關(guān)系，三者之間可相互追溯。例如，對于數(shù)據(jù)與研究項目，模型研究者可以基于不同版本的數(shù)據(jù)直接創(chuàng)建項目、跳轉(zhuǎn)至分析界面；對于研究項目與模型應(yīng)用，在模型應(yīng)用發(fā)布時，平臺會默認(rèn)記錄該模型使用的項目版本，模型研究者可在模型應(yīng)用頁面選擇對應(yīng)的項目版本進(jìn)行回溯。最后，ModelWhale 重視數(shù)據(jù)、項目、模型的可描述性，為任何版本信息提供文字描述區(qū)域。

特別地，針對模型研究特殊的一大要素，研發(fā)環(huán)境，ModelWhale 不僅關(guān)注其的“版本管理”與“映射關(guān)聯(lián)”。ModelOps 看重模型開發(fā)的流暢性，理想中的狀態(tài)是能夠即時開始模型研究，而事實上，不同的操作系統(tǒng)、系統(tǒng)依賴、編程語言、所需工具包不僅讓模型研究者難以“開啟”一個新項目，也讓其難以“復(fù)現(xiàn)”前人或團(tuán)隊伙伴的已有成果——無窮盡的環(huán)境報錯正困擾著開發(fā)人員。ModelWhale 在云端提供即開即用的分析環(huán)境，利用容器——鏡像——封裝各項目所需的環(huán)境信息，針對特定的研究項目，甚至項目的某一具體版本，用戶可通過 ModelWhale 跟蹤記錄其使用的具體鏡像。

解決了模型研究特殊三要素中的數(shù)據(jù)與鏡像，下一步便是計算資源問題。在場景二中，計算資源不足已嚴(yán)重拉低了企業(yè) B 的模型工作流效率，事實上，計算資源貫穿了 ModelOps 步驟從理解數(shù)據(jù)到監(jiān)控的每一步。ModelWhale 為模型研究人員提供計算資源支持。通過該平臺，企業(yè)模型研發(fā)部門的管理員可利用圖形化操作界面，對算力進(jìn)行管理。而算力同鏡像一樣支持即開即用，模型研究人員在開始項目前自主選取所需算力，即可一鍵完成資源調(diào)用，開始模型研究工作。項目關(guān)閉、算力使用結(jié)束后，資源也會自動釋放，供企業(yè)其他有需要的人員使用。

以上從生產(chǎn)資料的版本管理、映射關(guān)聯(lián)，再到環(huán)境的可復(fù)現(xiàn)性與計算資源的調(diào)度管理，其實都是在解決模型代碼的可運(yùn)行性。然而，模型與模型間的優(yōu)劣不僅僅與代碼本身有關(guān)，與最后產(chǎn)生的模型文件關(guān)聯(lián)的應(yīng)是一次具體的訓(xùn)練記錄，這也就是 ModelOps 所關(guān)注的“評估”步。換句話說，在代碼不變的情況下，調(diào)整模型的訓(xùn)練參數(shù)，甚至調(diào)整相應(yīng)計算資源，所生產(chǎn)出的模型文件也是不一樣的。針對模型的此類特質(zhì)，ModelWhale 提供訓(xùn)練記錄的產(chǎn)品功能。通過訓(xùn)練記錄，模型研究者可實時查看和記錄模型訓(xùn)練每次實驗的 Loss，Accuracy 及硬件使用情況；針對訓(xùn)練記錄的各版本，ModelWhale 提供可視化比對分析；最后，研究者通過 ModelWhale 還可直觀的查看模型組成、模型結(jié)構(gòu)、及每層網(wǎng)絡(luò)節(jié)點的輸入輸出與對應(yīng)的參數(shù)說明。

在模型交付前，ModelWhale 實現(xiàn)了將研究項目成果與相關(guān)元素一鍵打包，意味著模型作為成果交付后依然能夠輕松“向前”追溯，回到版本管理功能，有效幫助模型后續(xù)優(yōu)化迭代。

模型的交付

ModelOps 作為 XOps 的一種，與其他 Ops 同樣關(guān)注對交付的管理，那么模型的交付物應(yīng)如何延拓？對于傳統(tǒng)的模型應(yīng)用，首先，模型的發(fā)布部署過程復(fù)雜，專業(yè)門檻高，例如將模型發(fā)布為 APP 的形式，就會因一系列的調(diào)試配置操作耗費大量開發(fā)人員的精力；另外，若通過第三方軟件輸入數(shù)據(jù)、本地運(yùn)行模型的形式又易出現(xiàn)效率低、速度慢的問題。模型的發(fā)布部署不應(yīng)成為模型開發(fā)工作流中的重點，因此，ModelWhale 研發(fā)了相關(guān)產(chǎn)品功能。

對于模型成果，研究者可在項目頁將其一鍵部署為 REST 服務(wù)或離線預(yù)測，降低模型發(fā)布操作的專業(yè)技術(shù)門檻。在模型調(diào)用時，使用者可以通過 API 或網(wǎng)頁服務(wù)兩種方式進(jìn)行調(diào)用操作，若模型被發(fā)布為網(wǎng)頁應(yīng)用，使用者即可在網(wǎng)頁端填寫表單后一鍵獲取模型的運(yùn)行結(jié)果。另外，ModelWhale 后臺將為企業(yè)保留全套的模型調(diào)用記錄，記錄企業(yè)內(nèi)外部使用者對于模型的調(diào)用歷史，使企業(yè)能夠掌握模型的使用情況，以便其進(jìn)行模型的再訓(xùn)練與迭代優(yōu)化。

除了變成一個 API 或者網(wǎng)頁應(yīng)用，模型成果其實還有更多元的交付形式。例如，對于形成模型的的項目代碼片段，可以進(jìn)行沉淀，供下一次開發(fā)類似模型直接使用。通過 ModelWhale Jupyter Notebook 側(cè)邊欄中的代碼片段庫功能，模型研究者可在既往研究中預(yù)先收藏有幾率被復(fù)用到的代碼片段，后續(xù)進(jìn)行新一輪研究時，在該代碼庫“我的收藏”中找到相應(yīng)代碼片段直接插入，即可完成復(fù)用。

前文提到，各企業(yè)中平均仍有87%的決策模型從未真正上線運(yùn)行，而對于未被部署為應(yīng)用的模型文件，也可將其作為階段性成果供后續(xù)使用。利用 ModelWhale 算法庫，用戶們可以將已產(chǎn)出的算法模型輔以文字說明進(jìn)行沉淀，實現(xiàn)對模型的整理與分享。

模型工作流中跨部門、跨角色的協(xié)作協(xié)同

ModelOps 關(guān)注模型全生命周期的流暢性，而模型的開發(fā)應(yīng)用又常是多人協(xié)同，因此 ModelWhale 研發(fā)了一系列功能應(yīng)對團(tuán)隊工作中常出現(xiàn)的“沖擊對撞”。

例如，在上文中提到的生產(chǎn)要素版本管理、環(huán)境的可復(fù)現(xiàn)性、計算資源的調(diào)度等，全都支持跨部門、跨角色的打通——對于模型項目代碼，不同人員可在同時段協(xié)作協(xié)同；對于鏡像，不必人人造輪子，任意鏡像可分發(fā)給組織內(nèi)的任意成員進(jìn)行復(fù)用；對于算力，除了普通的算力分配，ModelWhale 還提供資源申用機(jī)制，當(dāng)現(xiàn)有計算存儲資源不夠用時，模型項目組的管理員可直接通過發(fā)起申請及時獲得算力補(bǔ)給，應(yīng)對不同研發(fā)需求。

而針對模型交付階段的代碼庫 + 算法庫功能，兩者中的的代碼片段與模型文件都支持組織內(nèi)的權(quán)限管理與分發(fā)。另外，ModelWhale 還具備任務(wù)規(guī)劃的項目管理工具，項目負(fù)責(zé)人可以新建課題任務(wù)，并將其拆分成子任務(wù)進(jìn)行分發(fā)，協(xié)同模型研發(fā)團(tuán)隊共同完成復(fù)雜的項目研究。

甚至，ModelWhale 還針對團(tuán)隊協(xié)作提供更高維度的模型成果承載方式。當(dāng)企業(yè)內(nèi)部想讓模型資產(chǎn)變得更“高級”，那么模型的研究者就不應(yīng)只包含計算機(jī)開發(fā)人員，而應(yīng)包含更多的“業(yè)務(wù)人員”。舉例來說，在開發(fā)醫(yī)學(xué)相關(guān)模型時，除了在一線“敲代碼”的工作人員，模型的研究小組還應(yīng)有臨床醫(yī)生（業(yè)務(wù)人員）的參與。但是計算機(jī)技術(shù)并不是臨床醫(yī)生的強(qiáng)項，他們?nèi)绾卧诤雎约?xì)顆粒度代碼的前提下理解模型并提供一應(yīng)的指導(dǎo)意見？ModelWhale 因此提出，可將模型代碼封裝為可視化的組件與流程模板，利用這樣的封裝，業(yè)務(wù)人員不再需要理解代碼本身，而僅需理解一個代碼塊的作用。由此，業(yè)務(wù)人員在提供相關(guān)的指導(dǎo)意見時，就可以運(yùn)用此類模板搭建簡易的模型流程，與開發(fā)技術(shù)人員進(jìn)行良好的協(xié)同。此外，技術(shù)人員還能夠?qū)I(yè)務(wù)人員搭建的模型流程直接還原為 Notebook 代碼，省去了從零編寫的時間。

最后還有一個待解決的問題，就是階段性模型成果在企業(yè)內(nèi)部的傳遞問題。其一，我們可以使用算法庫功能，但當(dāng)一個企業(yè)更關(guān)注的是模型跑出的結(jié)果而非模型文件本身時，此方法便不再適用，類似于第一節(jié)中的場景一。針對企業(yè) A 長期苦于用傳統(tǒng)文檔 + 自然語言承載模型成果的問題，ModelWhale 對 Notebook 做了升級，Jupyter Notebook 不再僅支持版本管理、多人高效協(xié)作、隨時復(fù)現(xiàn)分析過程，還具備圖像交互、相互援引等功能——Cell 級的直接引用，可將模型結(jié)果直接匯總至總的成果報告中，同時支持高效溯源；最后，Notebook 也支持多格式導(dǎo)出，無論是 HTML，還是 Word、PDF，研發(fā)人員均可自行選擇。

結(jié)束語

本文主要關(guān)注企業(yè)數(shù)字化轉(zhuǎn)型的重要資產(chǎn)——模型——在企業(yè)生產(chǎn)工作流中出現(xiàn)的種種問題、引入 ModelOps 的概念、介紹了一種數(shù)據(jù)科學(xué)協(xié)同平臺 ModelWhale，以探尋 ModelOps 的產(chǎn)品實現(xiàn)與相關(guān)問題的具體解決方案。

作為一款數(shù)據(jù)科學(xué)領(lǐng)域的工具、平臺，真正發(fā)揮平臺的產(chǎn)品能力才是關(guān)鍵所在，ModelWhale 希望能用積累下來的經(jīng)驗與方法論，幫助企業(yè)們一起梳理使用場景，完成模型的全生命周期管理工作，為廣大企業(yè)帶來實質(zhì)性的幫助。

若你想更深入地了解 ModelWhale 有關(guān)模型研發(fā)應(yīng)用的各項功能與實際案例，歡迎進(jìn)入 ModelWhale 官網(wǎng) 注冊體驗，也可 點擊聯(lián)系產(chǎn)品顧問 了解更多詳情。文章來源地址http://www.zghlxwxcb.cn/news/detail-763470.html