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