從零搭建AI工程能力這件事我前前后后折騰了差不多兩年。最早的時(shí)候我也走過彎路——買了一堆講Transformer推導(dǎo)的書把注意力機(jī)制的公式背得滾瓜爛熟結(jié)果真到要上線一個(gè)文本分類服務(wù)的時(shí)候連推理延遲怎么壓、顯存怎么省、模型版本怎么管都搞不清楚。后來我才慢慢想明白一件事AI工程不是機(jī)器學(xué)習(xí)理論的延伸它是一門獨(dú)立的工程學(xué)科核心矛盾在于“研究態(tài)的模型”和“生產(chǎn)態(tài)的系統(tǒng)”之間那道巨大的鴻溝。這篇內(nèi)容就是把我踩過的坑、試過的方案、以及最終沉淀下來的一套從零構(gòu)建AI工程能力的路徑完整地?cái)傞_來講。不管你是剛轉(zhuǎn)方向的算法同學(xué)還是想從后端切進(jìn)AI領(lǐng)域的工程師或者帶團(tuán)隊(duì)做AI落地的技術(shù)負(fù)責(zé)人應(yīng)該都能從中找到能直接抄作業(yè)的部分。1. 先搞清楚AI工程到底在解決什么問題1.1 模型能跑通和系統(tǒng)能上線之間隔著什么很多人對(duì)AI工程的第一個(gè)誤解是把它等同于“調(diào)模型”。我在早期也這么想過覺得只要模型精度夠高剩下的都是常規(guī)后端活兒。但實(shí)際情況是一個(gè)在notebook里F1跑到0.92的模型直接搬到線上可能連0.7都保不住甚至根本跑不起來。這中間的差距就是AI工程要填的坑。我把它拆成幾個(gè)層面來看。第一層是數(shù)據(jù)層面的一致性訓(xùn)練時(shí)用的特征管道和線上推理時(shí)的特征管道如果實(shí)現(xiàn)方式不同就會(huì)出現(xiàn)訓(xùn)練-服務(wù)偏差training-serving skew。我見過一個(gè)推薦場景離線AUC 0.85上線后CTR幾乎沒漲排查了兩周才發(fā)現(xiàn)是線上某個(gè)特征做了截?cái)喽x線沒有。第二層是性能層面訓(xùn)練可以慢慢跑推理不行用戶等不了。一個(gè)7B參數(shù)的模型如果不做量化、不做批處理、不做KV Cache優(yōu)化單條推理可能要幾百毫秒甚至上秒QPS根本上不去。第三層是運(yùn)維層面模型不是部署完就完事了數(shù)據(jù)分布會(huì)漂移模型會(huì)退化你需要監(jiān)控、需要回滾、需要灰度。所以AI工程的核心命題其實(shí)是把不確定性極高的模型包裝成一個(gè)確定性可用的服務(wù)。這句話聽起來簡單但每一個(gè)字背后都是一堆工程決策。1.2 一個(gè)合格的AI工程師需要哪幾塊能力拼圖我觀察身邊做得好的AI工程師能力結(jié)構(gòu)其實(shí)相當(dāng)復(fù)合。純算法出身的人往往在系統(tǒng)設(shè)計(jì)上偏弱純后端出身的人又容易低估數(shù)據(jù)和模型的特異性。我總結(jié)下來大概需要這么幾塊拼圖。數(shù)據(jù)處理與特征工程不是會(huì)用pandas就行而是要理解數(shù)據(jù)管道怎么設(shè)計(jì)才能保證離線和線上一致特征怎么存儲(chǔ)和讀取才能兼顧訓(xùn)練吞吐和推理延遲。模型訓(xùn)練與微調(diào)知道什么場景該從頭訓(xùn)、什么場景該微調(diào)、什么場景直接調(diào)API就夠了。不是所有問題都值得訓(xùn)一個(gè)模型。推理優(yōu)化量化、蒸餾、批處理、緩存、算子融合這些是讓模型真正能扛住線上流量的關(guān)鍵。服務(wù)化與部署模型怎么打包、怎么版本管理、怎么灰度發(fā)布、怎么A/B測試。監(jiān)控與迭代上線只是開始數(shù)據(jù)漂移檢測、模型性能監(jiān)控、badcase回流、持續(xù)再訓(xùn)練這套閉環(huán)才是長期戰(zhàn)斗力。這五塊拼圖里我認(rèn)為最容易被人忽視的是第一塊和第五塊。大家往往把注意力放在模型本身但真正決定一個(gè)AI系統(tǒng)能不能長期穩(wěn)定跑的恰恰是數(shù)據(jù)和監(jiān)控這兩端。1.3 為什么“從零”這個(gè)路徑反而更適合大多數(shù)人市面上講AI的課程和文章大多是從理論出發(fā)的先講線性回歸再講神經(jīng)網(wǎng)絡(luò)再講Transformer最后提一句部署。但我自己的經(jīng)驗(yàn)是從工程問題出發(fā)倒推著學(xué)效率高得多。原因很簡單當(dāng)你帶著一個(gè)具體問題去學(xué)的時(shí)候知識(shí)的留存率完全不一樣。比如你要做一個(gè)圖片分類服務(wù)你會(huì)被迫去搞清楚輸入圖片怎么預(yù)處理、模型怎么導(dǎo)出成通用格式、推理引擎怎么選、并發(fā)怎么處理。這些問題會(huì)倒逼你去理解模型輸入輸出的形狀、算子的兼容性、內(nèi)存的分配方式。這些理解比單純看論文推導(dǎo)要扎實(shí)得多?！皬牧恪边€有一層意思是不依賴重型框架的封裝。我建議在早期至少手動(dòng)實(shí)現(xiàn)一遍最核心的流程比如手寫一個(gè)簡單的推理循環(huán)、手動(dòng)管理一次模型版本切換。這樣你才知道那些框架幫你做了什么出問題的時(shí)候才有排查的方向。等你理解了底層再去用那些高度封裝的平臺(tái)就是如虎添翼而不是被黑盒牽著走。2. 數(shù)據(jù)管道AI工程里最不性感但最要命的部分2.1 訓(xùn)練-服務(wù)偏差是怎么產(chǎn)生的我先講一個(gè)真實(shí)踩過的坑。之前做一個(gè)文本意圖分類的服務(wù)離線評(píng)估準(zhǔn)確率0.91上線后一周監(jiān)控發(fā)現(xiàn)準(zhǔn)確率掉到0.78。排查過程很痛苦因?yàn)槟Ｐ蜎]變、代碼沒變唯一變的是數(shù)據(jù)來源。最后定位到問題離線訓(xùn)練時(shí)文本清洗用的是某個(gè)正則表達(dá)式把連續(xù)空格合并成一個(gè)而線上服務(wù)在預(yù)處理時(shí)用的是另一個(gè)庫的默認(rèn)分詞器它對(duì)空格的處理方式不同。就這么一個(gè)細(xì)節(jié)導(dǎo)致線上輸入的特征分布和訓(xùn)練時(shí)不一致。這就是典型的訓(xùn)練-服務(wù)偏差。它的根源在于離線和線上用了兩套代碼路徑來處理同一份數(shù)據(jù)。要根治這個(gè)問題核心原則是特征計(jì)算邏輯必須只有一份實(shí)現(xiàn)。具體怎么做我推薦兩種方案。第一種是特征存儲(chǔ)Feature Store把特征計(jì)算邏輯統(tǒng)一封裝離線和線上都調(diào)用同一個(gè)接口。第二種更輕量是把預(yù)處理邏輯固化進(jìn)模型本身比如用可以序列化的預(yù)處理層讓模型文件自帶預(yù)處理能力。小團(tuán)隊(duì)我建議先用第二種成本低、見效快。2.2 特征存儲(chǔ)到底該不該上Feature Store這個(gè)概念這幾年很火但我得說句實(shí)話不是所有團(tuán)隊(duì)都需要它。我見過一些團(tuán)隊(duì)業(yè)務(wù)量不大硬上了一套Feature Store結(jié)果維護(hù)成本比收益還高。判斷要不要上我一般看三個(gè)信號(hào)。第一特征復(fù)用率高不高。如果多個(gè)模型都在用同一批特征那統(tǒng)一管理就有價(jià)值。第二團(tuán)隊(duì)規(guī)模。如果只有一兩個(gè)人做特征口頭對(duì)齊就夠了沒必要上系統(tǒng)。第三實(shí)時(shí)性要求。如果需要在線實(shí)時(shí)計(jì)算特征且延遲要求嚴(yán)格那Feature Store的在線存儲(chǔ)部分就有意義。對(duì)于大多數(shù)中小團(tuán)隊(duì)我的建議是先用約定代碼規(guī)范的方式過渡所有特征計(jì)算邏輯放在一個(gè)獨(dú)立的包里離線和線上都從這個(gè)包導(dǎo)入配合單元測試保證一致性。等業(yè)務(wù)復(fù)雜到一定程度再考慮上專門的系統(tǒng)。2.3 數(shù)據(jù)版本管理別讓“這次用的是哪版數(shù)據(jù)”成為玄學(xué)數(shù)據(jù)版本管理是另一個(gè)容易被忽視的點(diǎn)。模型有版本代碼有版本但數(shù)據(jù)往往沒有。結(jié)果就是三個(gè)月后你想復(fù)現(xiàn)一個(gè)實(shí)驗(yàn)結(jié)果發(fā)現(xiàn)根本不知道當(dāng)時(shí)用的是哪份數(shù)據(jù)。我的做法是給每次訓(xùn)練用的數(shù)據(jù)集打上內(nèi)容哈希而不是簡單的日期或序號(hào)。因?yàn)槿掌跁?huì)重復(fù)序號(hào)會(huì)混亂只有內(nèi)容哈希能唯一標(biāo)識(shí)一份數(shù)據(jù)。具體操作上可以在數(shù)據(jù)加載完成后計(jì)算一個(gè)校驗(yàn)和把它記錄到訓(xùn)練配置里。這樣任何時(shí)候都能通過哈希反查到具體的數(shù)據(jù)快照。另外原始數(shù)據(jù)永遠(yuǎn)不要覆蓋。我習(xí)慣把原始數(shù)據(jù)、清洗后數(shù)據(jù)、特征數(shù)據(jù)分層存儲(chǔ)每一層都保留版本。清洗和特征計(jì)算都是可重放的純函數(shù)這樣即使中間某一步出了問題也能從原始數(shù)據(jù)重新跑一遍。2.4 數(shù)據(jù)質(zhì)量監(jiān)控的幾個(gè)實(shí)用指標(biāo)數(shù)據(jù)管道上線后必須有監(jiān)控。我常用的幾個(gè)指標(biāo)包括空值率、數(shù)值特征的分布偏移比如用PSI或KL散度衡量、類別特征的取值集合變化、樣本量突變。其中分布偏移最值得關(guān)注。我的經(jīng)驗(yàn)是當(dāng)某個(gè)關(guān)鍵特征的PSI超過0.2時(shí)就要警惕了可能意味著上游數(shù)據(jù)源發(fā)生了變化或者用戶行為模式發(fā)生了遷移。這時(shí)候不一定要立刻重訓(xùn)模型但至少要拉個(gè)告警讓人去看一眼。提示數(shù)據(jù)監(jiān)控的閾值不要拍腦袋定最好基于歷史數(shù)據(jù)的波動(dòng)范圍來設(shè)定。我一般會(huì)先跑兩周只觀察不告警看看正常波動(dòng)有多大再定閾值。3. 模型訓(xùn)練與微調(diào)什么時(shí)候該自己動(dòng)手3.1 調(diào)用API、微調(diào)、從頭訓(xùn)練的三層決策這是我在實(shí)際項(xiàng)目里被問得最多的問題之一。我的決策框架很簡單按成本和需求兩個(gè)維度來。方案適用場景成本數(shù)據(jù)需求調(diào)用現(xiàn)成API通用任務(wù)、快速驗(yàn)證、數(shù)據(jù)量少最低幾乎不需要微調(diào)開源模型垂直領(lǐng)域、有標(biāo)注數(shù)據(jù)、對(duì)延遲和成本敏感中等幾百到幾萬條從頭訓(xùn)練有獨(dú)特架構(gòu)需求、數(shù)據(jù)量極大、有充足算力最高百萬級(jí)以上我的建議是永遠(yuǎn)從最便宜的方案開始驗(yàn)證。先用API跑通業(yè)務(wù)閉環(huán)確認(rèn)這個(gè)AI能力真的能帶來價(jià)值再考慮往下走。很多團(tuán)隊(duì)一上來就要訓(xùn)自己的模型結(jié)果業(yè)務(wù)還沒驗(yàn)證清楚算力和人力已經(jīng)燒了一大半。3.2 微調(diào)時(shí)最容易翻車的幾個(gè)細(xì)節(jié)微調(diào)看起來簡單但坑不少。我挑幾個(gè)最典型的講。學(xué)習(xí)率設(shè)置。微調(diào)的學(xué)習(xí)率通常要比從頭訓(xùn)練小一到兩個(gè)數(shù)量級(jí)。我一般從1e-5開始試如果loss不降再往上調(diào)。用太大的學(xué)習(xí)率很容易把預(yù)訓(xùn)練學(xué)到的知識(shí)沖掉出現(xiàn)災(zāi)難性遺忘。數(shù)據(jù)配比。如果你只用自己的領(lǐng)域數(shù)據(jù)微調(diào)模型可能會(huì)過擬合到你的數(shù)據(jù)分布上通用能力下降。我的做法是混入一定比例的通用數(shù)據(jù)比例大概在10%到30%之間具體看領(lǐng)域數(shù)據(jù)的規(guī)模。這樣能在保持領(lǐng)域能力的同時(shí)不至于把通用能力丟光。評(píng)估集的設(shè)計(jì)。很多人微調(diào)時(shí)只看訓(xùn)練loss這是大忌。必須有一個(gè)獨(dú)立的、和訓(xùn)練數(shù)據(jù)同分布但不同來源的驗(yàn)證集。我甚至建議再準(zhǔn)備一個(gè)通用能力測試集用來監(jiān)控微調(diào)后通用能力有沒有明顯退化。序列長度。這個(gè)細(xì)節(jié)容易被忽略。如果你的領(lǐng)域數(shù)據(jù)普遍很長而預(yù)訓(xùn)練模型的默認(rèn)上下文窗口較短直接微調(diào)會(huì)導(dǎo)致長樣本被截?cái)?。要么調(diào)整窗口要么做數(shù)據(jù)切分不能不管。3.3 小樣本場景下的幾條實(shí)用策略現(xiàn)實(shí)中很多場景標(biāo)注數(shù)據(jù)就是很少幾百條甚至幾十條。這種情況下硬微調(diào)效果往往不好。我常用的策略有幾個(gè)。第一是提示工程少樣本示例。如果用的是支持上下文學(xué)習(xí)的模型直接在提示里放幾個(gè)示例往往能拿到不錯(cuò)的效果成本幾乎為零。第二是數(shù)據(jù)增強(qiáng)。文本場景可以用回譯、同義詞替換、句式改寫圖像場景可以用裁剪、旋轉(zhuǎn)、顏色抖動(dòng)。但要注意增強(qiáng)后的數(shù)據(jù)分布不能偏離真實(shí)分布太遠(yuǎn)。第三是參數(shù)高效微調(diào)比如只訓(xùn)練一小部分參數(shù)或者加低秩適配層。這種方式在數(shù)據(jù)量少的時(shí)候更不容易過擬合而且訓(xùn)練成本低適合快速迭代。第四是主動(dòng)學(xué)習(xí)。先用一個(gè)基礎(chǔ)模型跑一遍未標(biāo)注數(shù)據(jù)挑出模型最不確定的樣本讓人標(biāo)注這樣能用最少的標(biāo)注量拿到最大的效果提升。我在一個(gè)項(xiàng)目里用這個(gè)方法只標(biāo)了300條就把準(zhǔn)確率從0.72提到了0.86。3.4 訓(xùn)練過程的可復(fù)現(xiàn)性怎么保證可復(fù)現(xiàn)性是工程化的基礎(chǔ)。我要求自己團(tuán)隊(duì)的每次訓(xùn)練都必須滿足幾個(gè)條件隨機(jī)種子固定、依賴版本鎖定、數(shù)據(jù)版本記錄、超參數(shù)完整保存、環(huán)境用容器固化。其中依賴版本鎖定最容易被忽視。Python生態(tài)里一個(gè)小版本升級(jí)就可能改變數(shù)值計(jì)算結(jié)果。我一般用鎖文件把整個(gè)依賴樹固定下來配合容器鏡像保證任何時(shí)候都能重建出一模一樣的環(huán)境。隨機(jī)種子這塊要注意不只是Python的random和numpy的seed深度學(xué)習(xí)框架自己的seed也要設(shè)而且如果用了GPU還要考慮CUDA的確定性設(shè)置。有些算子默認(rèn)是非確定性的需要顯式開啟確定性模式代價(jià)是可能慢一點(diǎn)。4. 推理優(yōu)化讓模型真正扛得住線上流量4.1 量化精度和速度的平衡點(diǎn)在哪量化是我認(rèn)為性價(jià)比最高的推理優(yōu)化手段。它把模型參數(shù)從高精度浮點(diǎn)降到低精度整數(shù)直接減少內(nèi)存占用和計(jì)算量。常見的方案有幾種。量化方案精度損失速度提升適用場景動(dòng)態(tài)量化較小中等CPU推理、快速驗(yàn)證靜態(tài)量化中等較大對(duì)延遲敏感的CPU場景訓(xùn)練后量化中等較大GPU推理、通用場景量化感知訓(xùn)練最小較大對(duì)精度要求極高的場景我的經(jīng)驗(yàn)是大多數(shù)場景用訓(xùn)練后量化就夠了精度損失通常在1%以內(nèi)但推理速度能提升2到4倍顯存占用能降一半以上。如果量化后精度掉得厲害再考慮量化感知訓(xùn)練但那個(gè)成本高不少。有一個(gè)細(xì)節(jié)要注意量化不是萬能的。有些模型對(duì)量化特別敏感尤其是參數(shù)量小的模型量化后精度可能崩掉。所以量化后一定要在驗(yàn)證集上重新評(píng)估不能想當(dāng)然。4.2 批處理與并發(fā)吞吐和延遲的取舍批處理是提升吞吐的利器但會(huì)增加單條請(qǐng)求的延遲。因?yàn)橐纫慌?qǐng)求湊齊才能一起推理。這個(gè)取舍怎么定取決于業(yè)務(wù)場景。如果是離線批處理任務(wù)那批越大越好吞吐優(yōu)先。如果是在線實(shí)時(shí)服務(wù)就要控制批的大小和等待時(shí)間。我常用的做法是設(shè)置一個(gè)最大等待窗口比如10毫秒窗口內(nèi)湊到多少就處理多少窗口結(jié)束就立即處理。這樣在延遲和吞吐之間取一個(gè)平衡。并發(fā)方面要注意推理引擎本身的線程模型。有些引擎內(nèi)部已經(jīng)做了多線程你再在外面套一層多進(jìn)程反而會(huì)因?yàn)橘Y源競爭導(dǎo)致性能下降。我一般會(huì)先壓測找到最優(yōu)的并發(fā)配置而不是拍腦袋設(shè)。4.3 緩存策略哪些請(qǐng)求值得緩存緩存是另一個(gè)提升有效吞吐的手段。但不是所有請(qǐng)求都值得緩存。我的判斷標(biāo)準(zhǔn)是請(qǐng)求的重復(fù)率高不高且結(jié)果對(duì)時(shí)間不敏感。比如一個(gè)FAQ問答服務(wù)用戶問的問題高度重復(fù)那緩存命中率就很高效果顯著。但如果是一個(gè)個(gè)性化推薦每個(gè)用戶的請(qǐng)求都不一樣緩存就沒意義。緩存還要注意失效策略。模型更新后舊緩存必須清掉否則會(huì)返回過期結(jié)果。我一般用模型版本號(hào)作為緩存key的一部分模型一更新key就變了自然失效。4.4 推理引擎選型的幾個(gè)考量維度推理引擎的選擇直接影響性能和開發(fā)效率。我一般從幾個(gè)維度考量硬件支持、模型格式兼容性、社區(qū)活躍度、部署復(fù)雜度、性能表現(xiàn)。對(duì)于GPU場景主流的引擎在性能上差距其實(shí)沒有想象中那么大更多是生態(tài)和易用性的差異。對(duì)于CPU場景不同引擎的優(yōu)化程度差別就比較明顯了需要實(shí)際壓測。我的建議是不要過早鎖定引擎。先把模型導(dǎo)出成通用的中間格式這樣可以在不同引擎之間切換。等業(yè)務(wù)穩(wěn)定了再針對(duì)性地做深度優(yōu)化。注意推理引擎的版本和模型格式的版本要匹配。我踩過一次坑引擎升級(jí)后舊模型加載失敗排查了半天才發(fā)現(xiàn)是格式版本不兼容。所以升級(jí)引擎前一定要在測試環(huán)境驗(yàn)證。5. 服務(wù)化與部署把模型變成可靠的服務(wù)5.1 模型服務(wù)的基本架構(gòu)長什么樣一個(gè)典型的模型服務(wù)我一般會(huì)拆成幾層。最底層是推理運(yùn)行時(shí)負(fù)責(zé)加載模型、執(zhí)行推理。往上是服務(wù)層處理請(qǐng)求解析、批處理、超時(shí)控制。再往上是路由層負(fù)責(zé)版本管理、灰度、負(fù)載均衡。最外面是網(wǎng)關(guān)層處理鑒權(quán)、限流、日志。這個(gè)分層的好處是職責(zé)清晰便于獨(dú)立擴(kuò)展。比如推理運(yùn)行時(shí)是計(jì)算密集型的可以單獨(dú)擴(kuò)容網(wǎng)關(guān)層是IO密集型的可以獨(dú)立部署。對(duì)于小團(tuán)隊(duì)我建議先用單體架構(gòu)快速上線把模型和HTTP服務(wù)打包在一起。等流量上來了再把推理部分拆出來做獨(dú)立服務(wù)。不要一上來就搞微服務(wù)維護(hù)成本太高。5.2 模型版本管理與灰度發(fā)布模型版本管理我堅(jiān)持一個(gè)原則任何一次模型更新都必須可回滾。具體做法是每個(gè)模型版本都有唯一標(biāo)識(shí)部署時(shí)新版本和舊版本并存通過路由規(guī)則控制流量分配?；叶劝l(fā)布我一般分幾步走。先內(nèi)部測試用真實(shí)流量的一小部分比如1%驗(yàn)證。觀察一段時(shí)間沒問題后逐步放量到10%、50%、100%。每一步都要有明確的觀察指標(biāo)和回滾條件。回滾條件要提前定好不能等出問題了再臨時(shí)決定。我常用的回滾觸發(fā)條件包括錯(cuò)誤率超過閾值、延遲超過閾值、核心業(yè)務(wù)指標(biāo)下降超過閾值。一旦觸發(fā)自動(dòng)回滾不需要人工介入。5.3 A/B測試在AI服務(wù)里的特殊之處A/B測試在普通后端服務(wù)里很成熟但在AI服務(wù)里有幾個(gè)特殊點(diǎn)。第一模型效果有延遲性。比如推薦模型用戶點(diǎn)了沒點(diǎn)可能要過一段時(shí)間才能觀察到。所以A/B測試的觀察窗口要足夠長。第二模型之間有相互影響。如果兩個(gè)模型共享底層特征或資源一個(gè)模型的變化可能影響另一個(gè)。所以實(shí)驗(yàn)設(shè)計(jì)要考慮隔離性。第三冷啟動(dòng)問題。新模型上線初期可能因?yàn)闆]積累夠數(shù)據(jù)而表現(xiàn)不佳這時(shí)候不能急著下結(jié)論。我一般會(huì)設(shè)置一個(gè)預(yù)熱期預(yù)熱期內(nèi)的數(shù)據(jù)不納入評(píng)估。5.4 資源調(diào)度與成本控制AI服務(wù)的成本大頭在算力?？刂瞥杀镜氖侄斡袔讉€(gè)。彈性伸縮是最直接的根據(jù)流量自動(dòng)調(diào)整實(shí)例數(shù)。但要注意冷啟動(dòng)時(shí)間模型加載慢的話擴(kuò)容跟不上流量突增?；旌喜渴鹗橇硪粋€(gè)思路把不同優(yōu)先級(jí)的任務(wù)混在一起跑提高資源利用率。比如在線推理和離線批處理共享GPU離線任務(wù)用低優(yōu)先級(jí)在線任務(wù)來了就搶占。模型分級(jí)也有效。不是所有請(qǐng)求都需要大模型簡單的請(qǐng)求用小模型處理復(fù)雜的才走大模型。這樣能顯著降低平均成本。6. 監(jiān)控與持續(xù)迭代上線只是開始6.1 模型性能監(jiān)控該看哪些指標(biāo)模型上線后監(jiān)控分兩個(gè)層面。系統(tǒng)層面看QPS、延遲、錯(cuò)誤率、資源利用率這些和普通服務(wù)一樣。模型層面要看預(yù)測分布的偏移、置信度的變化、以及業(yè)務(wù)指標(biāo)的變化。預(yù)測分布偏移是我最看重的指標(biāo)。如果模型輸出的類別分布突然變化往往意味著輸入數(shù)據(jù)變了或者模型出了問題。我一般會(huì)監(jiān)控輸出分布的KL散度超過閾值就告警。置信度也值得關(guān)注。如果模型平均置信度持續(xù)下降說明它遇到的樣本越來越“陌生”可能需要重新訓(xùn)練了。6.2 數(shù)據(jù)漂移檢測的落地方法數(shù)據(jù)漂移檢測我一般從輸入特征和輸出預(yù)測兩頭做。輸入側(cè)對(duì)每個(gè)關(guān)鍵特征計(jì)算分布統(tǒng)計(jì)量和訓(xùn)練時(shí)的基準(zhǔn)分布對(duì)比。數(shù)值特征用PSI或KS檢驗(yàn)類別特征用新出現(xiàn)的取值比例。輸出側(cè)監(jiān)控預(yù)測類別的分布變化。檢測頻率上離線服務(wù)可以每天跑一次在線服務(wù)可以按小時(shí)甚至更細(xì)粒度。但要注意漂移不一定是壞事也可能是業(yè)務(wù)正常變化。所以檢測到漂移后要結(jié)合業(yè)務(wù)判斷而不是無腦重訓(xùn)。6.3 Badcase回流與再訓(xùn)練閉環(huán)Badcase是模型迭代最寶貴的資源。我要求團(tuán)隊(duì)建立一套自動(dòng)化的badcase收集機(jī)制線上預(yù)測置信度低的、用戶反饋錯(cuò)誤的、人工抽檢發(fā)現(xiàn)問題的都自動(dòng)進(jìn)入badcase池。然后定期對(duì)badcase做分析歸類問題類型。是數(shù)據(jù)問題、模型問題、還是業(yè)務(wù)理解問題。針對(duì)性地補(bǔ)充標(biāo)注數(shù)據(jù)加入下一輪訓(xùn)練。這個(gè)閉環(huán)跑起來后模型迭代就有了持續(xù)的動(dòng)力。我見過做得好的團(tuán)隊(duì)每周都能跑一輪小迭代模型效果穩(wěn)步提升。6.4 從監(jiān)控到自動(dòng)再訓(xùn)練的完整鏈路再往上一層是把監(jiān)控和訓(xùn)練打通做自動(dòng)再訓(xùn)練。當(dāng)漂移檢測觸發(fā)、或者badcase積累到一定量、或者定時(shí)周期到了自動(dòng)觸發(fā)訓(xùn)練流程。但自動(dòng)再訓(xùn)練有幾個(gè)前提。訓(xùn)練流程必須完全自動(dòng)化從數(shù)據(jù)拉取到模型評(píng)估到部署不能有人工環(huán)節(jié)。評(píng)估必須嚴(yán)格新模型要在多個(gè)維度上不劣于舊模型才能上線?；貪L必須可靠一旦新模型表現(xiàn)不好能快速切回舊版本。我建議自動(dòng)再訓(xùn)練先從半自動(dòng)開始訓(xùn)練自動(dòng)跑但上線前人工確認(rèn)。等流程穩(wěn)定了再逐步放開。7. 我在這條路上踩過的幾個(gè)印象深刻的坑7.1 一個(gè)特征不一致導(dǎo)致的線上事故前面提過訓(xùn)練-服務(wù)偏差這里展開講一個(gè)具體案例。當(dāng)時(shí)做一個(gè)風(fēng)控模型離線評(píng)估各項(xiàng)指標(biāo)都很好。上線后第一天就發(fā)現(xiàn)誤殺率異常高。排查了整整三天最后發(fā)現(xiàn)是時(shí)間特征的時(shí)區(qū)問題。離線數(shù)據(jù)用的是UTC時(shí)間線上服務(wù)用的是本地時(shí)間差了8小時(shí)。結(jié)果模型看到的“凌晨交易”特征在線上變成了“白天交易”判斷邏輯完全錯(cuò)亂。這個(gè)坑的教訓(xùn)是任何涉及時(shí)間、編碼、單位的特征都要在離線和線上做一致性校驗(yàn)。我后來養(yǎng)成了一個(gè)習(xí)慣上線前會(huì)寫一個(gè)腳本用同一批樣本分別跑離線和線上的特征計(jì)算逐字段對(duì)比不一致就報(bào)錯(cuò)。7.2 模型加載慢導(dǎo)致的擴(kuò)容失效還有一次服務(wù)流量突增自動(dòng)擴(kuò)容觸發(fā)了但新實(shí)例遲遲起不來。查下來是模型文件太大加載要幾分鐘。擴(kuò)容的速度趕不上流量增長的速度結(jié)果服務(wù)被打掛了。后來我做了幾個(gè)改進(jìn)。一是模型文件做精簡去掉訓(xùn)練相關(guān)的冗余信息。二是預(yù)熱機(jī)制新實(shí)例啟動(dòng)后先加載模型再接入流量。三是預(yù)留緩沖實(shí)例平時(shí)就多留一兩個(gè)實(shí)例應(yīng)對(duì)突發(fā)流量。7.3 過度依賴單一評(píng)估指標(biāo)的教訓(xùn)早期我特別迷信準(zhǔn)確率覺得準(zhǔn)確率高就是好模型。后來做一個(gè)類別極不平衡的場景正樣本只占1%模型全預(yù)測負(fù)類準(zhǔn)確率99%但完全沒用。從那以后我評(píng)估模型一定看多個(gè)指標(biāo)精確率、召回率、F1、AUC還要看混淆矩陣和分桶表現(xiàn)。特別是分桶能發(fā)現(xiàn)模型在某些子群體上表現(xiàn)特別差的問題這在整體指標(biāo)上是看不出來的。7.4 忽略推理成本導(dǎo)致的預(yù)算超支有一次做圖像識(shí)別服務(wù)模型選了個(gè)精度最高的沒太考慮推理成本。結(jié)果上線后GPU賬單遠(yuǎn)超預(yù)算。后來做了量化、換了更輕量的模型架構(gòu)、加了緩存成本降了七成多精度只掉了不到一個(gè)點(diǎn)。這件事讓我明白AI工程里精度不是唯一目標(biāo)成本、延遲、精度要一起權(quán)衡。很多時(shí)候犧牲一點(diǎn)點(diǎn)精度換取大幅的成本下降是完全值得的。8. 給不同階段從業(yè)者的進(jìn)階建議8.1 剛?cè)腴T的人應(yīng)該先補(bǔ)哪塊如果你剛進(jìn)入這個(gè)領(lǐng)域我建議先把一個(gè)完整的服務(wù)跑通哪怕模型很簡單。從數(shù)據(jù)準(zhǔn)備、模型訓(xùn)練、導(dǎo)出、部署、到監(jiān)控完整走一遍。這個(gè)過程會(huì)讓你對(duì)全貌有認(rèn)知知道每個(gè)環(huán)節(jié)大概在干什么。然后挑一個(gè)環(huán)節(jié)深入。我建議從推理優(yōu)化入手因?yàn)檫@塊最工程化也最容易看到效果。把量化、批處理、緩存這幾個(gè)手段玩熟你對(duì)模型和硬件的理解會(huì)上一個(gè)臺(tái)階。8.2 有一定基礎(chǔ)后如何突破瓶頸如果你已經(jīng)能獨(dú)立完成AI服務(wù)的搭建想再往上走我建議往系統(tǒng)設(shè)計(jì)和成本優(yōu)化兩個(gè)方向發(fā)力。系統(tǒng)設(shè)計(jì)方面多思考高可用、可擴(kuò)展、可觀測這三個(gè)詞在AI場景下的具體含義。比如模型服務(wù)怎么做多活、怎么做流量調(diào)度、怎么做故障隔離。成本優(yōu)化方面深入理解硬件特性和模型特性的匹配。什么模型適合什么硬件怎么壓榨硬件性能怎么在精度和成本之間找最優(yōu)解。這塊做得好能給團(tuán)隊(duì)省下真金白銀。8.3 團(tuán)隊(duì)負(fù)責(zé)人該關(guān)注哪些工程能力建設(shè)如果你是帶團(tuán)隊(duì)的我建議重點(diǎn)建設(shè)三樣?xùn)|西。一是標(biāo)準(zhǔn)化的流程從數(shù)據(jù)到訓(xùn)練到部署每個(gè)環(huán)節(jié)都有規(guī)范減少人為失誤。二是自動(dòng)化的工具鏈把重復(fù)勞動(dòng)自動(dòng)化讓工程師專注在創(chuàng)造性工作上。三是可觀測的體系讓問題能被及時(shí)發(fā)現(xiàn)和定位。還有一點(diǎn)很重要培養(yǎng)團(tuán)隊(duì)的工程審美。什么叫好的AI工程不是用了多新的技術(shù)而是系統(tǒng)穩(wěn)定、迭代高效、成本可控。這個(gè)價(jià)值觀要自上而下地傳遞。8.4 這個(gè)領(lǐng)域未來值得關(guān)注的方向從工程角度看我覺得幾個(gè)方向值得關(guān)注。一是推理效率的持續(xù)優(yōu)化硬件和算法都在快速演進(jìn)這塊空間還很大。二是AI系統(tǒng)的可觀測性隨著模型越來越復(fù)雜怎么理解和調(diào)試模型行為是個(gè)大問題。三是端側(cè)部署把AI能力放到終端設(shè)備上對(duì)隱私和延遲都有好處但工程挑戰(zhàn)也不小。不管方向怎么變?cè)鷮?shí)的工程基本功永遠(yuǎn)是立身之本。數(shù)據(jù)管道、服務(wù)架構(gòu)、性能優(yōu)化、監(jiān)控體系這些底層能力不會(huì)過時(shí)。最后分享一個(gè)我自己的習(xí)慣每做完一個(gè)項(xiàng)目我都會(huì)寫一份復(fù)盤文檔記錄當(dāng)時(shí)的技術(shù)選型理由、遇到的問題、以及如果重來會(huì)怎么做。這份文檔過一段時(shí)間再看往往會(huì)有新的收獲。AI工程這個(gè)領(lǐng)域變化快但很多底層的工程原則是相通的把這些原則沉淀下來比追逐每一個(gè)新技術(shù)更重要。