做AI工程這一年多我最大的感受是很多人不是被模型難倒的而是被工程這兩個字難倒的。你花兩周把模型精度刷到了90%結(jié)果接下來兩個月全在折騰數(shù)據(jù)管線、部署腳本、監(jiān)控告警——這就是典型的跑通demo容易做成系統(tǒng)難。今天這篇東西我就想從從零開始的角度把AI工程ai-engineering這條完整鏈路重新捋一遍從你只有一個模糊的業(yè)務想法到模型上線后能穩(wěn)定迭代中間到底要跨過哪些坑、搭起哪些東西。內(nèi)容不會太偏理論更適合正在做項目落地、或者準備從算法崗往工程側(cè)延伸的朋友。哪怕你現(xiàn)在的項目還很小這套骨架也值得照著一遍。1. 從零開始AI工程究竟在解決什么問題1.1 模型只是冰山一角我先給一個不算精確但很形象的類比寫模型就像是學會炒一道招牌菜而做AI工程是開一家后廚。后者要管食材采購數(shù)據(jù)獲取、庫存保鮮數(shù)據(jù)版本、灶臺排班訓練調(diào)度、出菜節(jié)奏推理性能、食客反饋線上監(jiān)控以及最煩人的——食品安全測試與回歸。你不會只關(guān)心那道菜好不好吃你得保證它在高峰期也能30秒內(nèi)出鍋且連續(xù)一個月不出紕漏。實際項目里模型訓練這個環(huán)節(jié)通常只占20%左右的工作量剩下80%都在和數(shù)據(jù)、基礎(chǔ)設施、部署、監(jiān)控搏斗。很多人從Kaggle或公開數(shù)據(jù)集入門天然缺乏這部分體感——因為平臺把數(shù)據(jù)管線、算力管理、評測邏輯全包了。一旦回到真實的業(yè)務場景立刻發(fā)現(xiàn)無從下手。AI工程的核心命題其實就是把不確定性極高的模型開發(fā)過程變成一條確定性足夠高的生產(chǎn)線。1.2 一條完整的AI工程鏈路長什么樣一個從零起步的AI工程項目在我眼里從來不是訓練一個模型這六個字而是下面這串鏈條業(yè)務問題定義 → 數(shù)據(jù)方案設計 → 評估體系搭建 → 基線模型建立 → 迭代優(yōu)化 → 服務化部署 → 監(jiān)控與告警 → 持續(xù)迭代每個環(huán)節(jié)都有自己獨立的工程難點。業(yè)務問題定義要回答這個功能到底有沒有必要用模型數(shù)據(jù)方案要搞定獲取、清洗、標注、版本管理評估體系要防止你被驗證集的指標騙了基線模型要讓你搞清楚模型相對樸素規(guī)則的真實增益服務化部署要考慮延遲和吞吐的平衡監(jiān)控則要保證模型出了毛病你能在用戶察覺前發(fā)現(xiàn)。這條鏈路里任意一環(huán)做草率了都會在后面以更痛苦的方式找補回來。我見過太多團隊評估集隨便劃了幾百條數(shù)據(jù)就開訓結(jié)果線上性能一塌糊涂回頭才發(fā)現(xiàn)測試集本身就有數(shù)據(jù)泄漏。也見過項目上線半年沒人看過特征分布變化最后模型慢慢漂移成人工智障而不自知。這些都不是模型層面的問題是工程紀律的問題。1.3 為什么強調(diào)from scratch既然市面上已經(jīng)有很多現(xiàn)成的框架和平臺為什么我仍然建議你至少把一個項目從零完整走一遍因為黑盒會掩蓋大量細節(jié)。你用AutoML一鍵訓練很難理解特征預處理和評估集設計之間那些微妙的互相影響。我自己第一次從零搭項目的時候花了大量時間在網(wǎng)上查配置文件的寫法覺得效率很低但恰恰是這個過程讓我后來排查線上故障時腦子里有完整的全景圖——知道問題可能出在哪一層?？蚣軒湍闶〉舻臅r間后面你大概率會通過排查問題的方式還回去只是利息更高。2. 項目腳手架搭建第一行代碼之前的準備2.1 環(huán)境與工具鏈選型我見過太多項目死于環(huán)境不一致A同學的代碼在B的機器上跑不起來或昨天還能運行的訓練腳本換臺機器就莫名其妙報錯。所以從零開始的第一步是先把環(huán)境和依賴管理釘死。我的偏好是以Python 3.11或3.12為基準配合uv或Poetry做依賴管理。如果你還在用裸pip install加上requirements.txt我建議盡早切換。uv這類工具除了快更重要的是能嚴格鎖定傳遞依賴的版本避免在我的機器上明明沒問題這種經(jīng)典事故。Conda在安裝Python本身或一些帶二進制依賴的包時依然順手可以留著管理解釋器版本但項目依賴樹這件事我不推薦用conda全權(quán)處理。還有一個工具選型經(jīng)驗項目里所有成員最好鎖同一個Python版本。之前帶過一個項目有人在用3.9、有人用3.11結(jié)果因為Pydantic這類庫在版本間的行為差異聯(lián)調(diào)階段憑空多出兩天工作量。這類問題在定義工程完成標準時經(jīng)常被忽略但它的成本是很真實的。2.2 項目目錄結(jié)構(gòu)怎么設計好的目錄結(jié)構(gòu)應該做到新成員入職第一天瀏覽一遍目錄就能大致說出這個項目的數(shù)據(jù)在哪、模型代碼在哪、配置在哪、測試在哪。我常用的布局長這樣project_root/ ├── data/ │ ├── raw/ # 原始數(shù)據(jù)只讀 │ ├── processed/ # 清洗后數(shù)據(jù) │ └── versions/ # 數(shù)據(jù)版本歸檔 ├── src/ │ ├── data/ # 數(shù)據(jù)加載與預處理代碼 │ ├── features/ # 特征工程 │ ├── models/ # 模型定義 │ ├── train.py # 訓練入口 │ ├── evaluate.py # 評估入口 │ └── serve.py # 推理服務 ├── configs/ # 所有配置文件 ├── notebooks/ # 探索性分析只是一等公民但不是唯一 ├── tests/ # 單元與集成測試 └── scripts/ # 運維腳本有幾個原則我覺得值得展開說。第一個是原始數(shù)據(jù)只讀。data/raw里的文件一旦寫入就不允許修改誰要清洗就生成新的processed版本避免無意間污染源頭數(shù)據(jù)。第二個是配置外置。學習率、批量大小、特征列表這些不應該硬編碼在代碼里而應該放到configs目錄中最好用YAML這類格式統(tǒng)一管理。這樣你每一次實驗的超參數(shù)到底用了什么看配置文件就知道不需要靠記憶。2.3 從第一天就建立實驗追蹤和版本管理這個效果好的模型當時超參數(shù)是多少——這是沒有實驗追蹤系統(tǒng)時最讓人頭大的問題。所以哪怕是個人項目我也強烈建議從第一行代碼開始就接入實驗追蹤工具。MLflow和Weights Biases中二選一即可前者自托管成本低適合有隱私要求的場景后者上手快可視化界面更漂亮。具體追蹤什么我的最低要求是三樣超參數(shù)、指標、產(chǎn)物。每跑一次實驗把學習率、批次大小、數(shù)據(jù)版本、特征版本記錄下來把準確率、F1、AUC這些指標記錄下來把模型權(quán)重和預處理文件做artifact記錄。這樣你隨時能回答這個模型是用哪份數(shù)據(jù)、哪些特征、哪組超參訓練出來的。版本管理同樣分兩層。代碼用Git這是基本共識。但數(shù)據(jù)怎么管理傳統(tǒng)的做法是把數(shù)據(jù)集放進網(wǎng)盤或共享目錄靠文件名區(qū)分版本比如data_v3_final_真的最終版.csv——這種方案撐不到項目第三周。需要用DVC這樣的數(shù)據(jù)版本管理工具把數(shù)據(jù)和Git關(guān)聯(lián)起來。DVC的思路是用Git追蹤一個很小的元數(shù)據(jù)文件真正的數(shù)據(jù)文件存在本地或遠端存儲里需要時再取。好處是data/raw里的原始數(shù)據(jù)版本、特征集版本全都變成可追溯的。3. 數(shù)據(jù)與評估體系比模型訓練更值得花時間的部分3.1 數(shù)據(jù)管線設計的幾個現(xiàn)實問題做AI工程和做競賽最不一樣的地方就是數(shù)據(jù)的獲取和使用受限于真實環(huán)境。你在項目啟動階段必須想清楚幾件事。第一原始數(shù)據(jù)從哪里來。是業(yè)務數(shù)據(jù)庫導出的歷史記錄還是需要標注團隊處理的人工標注還是從第三方采購的公開集如果是業(yè)務數(shù)據(jù)要提前確認字段含義和更新頻率如果是人工標注必須要設計標注規(guī)范和質(zhì)量抽檢流程。這些不是模型層面的問題但沒有它們模型就是空中樓閣。第二數(shù)據(jù)的隱私合規(guī)邊界。即使用戶給了原始數(shù)據(jù)也會涉及脫敏、權(quán)限管理這些硬性要求。實際項目里這方面的處理經(jīng)常要占掉近一半數(shù)據(jù)工程工作量。我通常的建議是早做不做晚做先確認哪些字段屬于敏感信息哪些需要泛化處理哪些要嚴格禁止離開內(nèi)網(wǎng)環(huán)境。第三數(shù)據(jù)質(zhì)量的校驗機制。訓練集里混入大量重復樣本會導致模型評估虛高。比如某分類任務里一種樣本由于采集方式的原因重復了三次模型看到的數(shù)據(jù)分布和真實分布早就走樣了。沒有數(shù)據(jù)校驗環(huán)節(jié)你后續(xù)的一切工作都建立在錯誤的地基上所以我會專門寫一個數(shù)據(jù)校驗腳本做缺失率、去重、類別分布統(tǒng)計每次數(shù)據(jù)更新后都跑一遍。3.2 評估集設計不要被你的驗證集騙了評估集設計的好壞直接決定你能不能對模型的真實表現(xiàn)做出正確判斷甚至影響整個項目走向。我見過最可惜的做法是隨機切分一份驗證集就萬事大吉結(jié)果模型在驗證集上表現(xiàn)很好一上線就拉胯。幾個關(guān)鍵經(jīng)驗如下。首先評估集要和訓練集做時間切分。如果數(shù)據(jù)帶時間戳訓練集用過去的樣本測試集用未來的樣本這樣最貼近線上預測場景。其次要有哨兵用例。挑那些業(yè)務上最重要但模型當前可能搞不定的長尾場景單獨組成一小批數(shù)據(jù)每個迭代都去盯它有沒有退化。第三分組指標很重要。不要只看整體準確率按類別、按用戶群體去切分指標才能發(fā)現(xiàn)模型對某些少數(shù)群體的表現(xiàn)是不是已經(jīng)崩了。還有一個小細節(jié)測試集去重。訓練集里出現(xiàn)的樣本絕對不能出現(xiàn)在評估集里否則你評估的其實是模型記住了多少。我在實際項目里就吃過這個虧做文本分類時因為代碼邏輯疏漏導致一部分訓練文本和測試文本高度重疊離線指標虛高了好幾個點排查了整整一周。3.3 先建一個傻傻的基線模型我每次復盤項目都會強調(diào)基線模型的價值。所謂基線最簡單可以是一套基于規(guī)則或關(guān)鍵詞的啟發(fā)式方法比如文本分類里直接按關(guān)鍵詞命中來判斷或者推薦場景里直接推最熱門的商品。建基線的目的不是要效果多好而是給后續(xù)復雜的模型一把標尺。如果你的深度學習模型比規(guī)則基線只高了兩個點你得認真考慮投入產(chǎn)出比——也許規(guī)則的方案加一加特征成本低得多可解釋性也強得多。我見過太多團隊一上來就上BERT效果還行但運維成本也高最后反而不如隔壁團隊一個樸素但穩(wěn)定且易維護的規(guī)則系統(tǒng)省心。在工程層面基線模型的代碼通常非常簡單但它作為回歸測試的錨點非常管用。后續(xù)任何一次模型更新、特征改造都跑一遍基線對比保證新方案至少不會比簡單方案差。這在做模型上線評審時也特別好用——你拿基線指標一擺再拿新模型指標一擺業(yè)務方立刻明白提升是真實的還是偶然的。4. 從離線到在線服務化部署與監(jiān)控4.1 模型服務化的接口設計模型訓練完了離能用還差一步要把它變成一個穩(wěn)定提供預測的服務。我見過很多剛接觸AI工程的同學直接把訓練代碼里predict函數(shù)摳出來塞進一個Web框架里當接口用結(jié)果在線請求一多就超時。原因在于離線predict函數(shù)默認假設輸入已經(jīng)完全按訓練時的方式處理好但線上請求來的原始數(shù)據(jù)千奇百怪。缺失字段、格式不規(guī)范、范圍越界每一個都要在服務層獨立處理。所以我一般會為模型服務設計三個獨立的處理階段輸入校驗檢查字段是否齊全、類型是否正確、特征轉(zhuǎn)換把原始數(shù)據(jù)轉(zhuǎn)成模型需要的特征張量、模型推理加載權(quán)重計算輸出。每個階段獨立成函數(shù)配合日志記錄出問題時能精確定位在哪一步。接口schema也要提前定好。輸入用JSON字段描述清楚輸出除了預測值最好還帶上置信度或各個類別的概率分布。這樣下游系統(tǒng)可以做閾值控制而不是硬著頭皮相信一個label。4.2 性能優(yōu)化延遲和吞吐的取舍這里需要區(qū)分場景。你在做一個低并發(fā)的分類任務和做一個高并發(fā)的推薦服務優(yōu)化策略完全不同。對于大多數(shù)起步項目用FastAPI寫一個輕量異步接口配合模型批處理batch inference已經(jīng)能滿足需求。簡單說就是積攢多個請求一起過模型而不是一個請求過一遍吞吐通常能提升數(shù)倍。再往下走可以做模型壓縮和推理加速。ONNX Runtime或TensorRT是兩條常見路線但都不可避免要在效率和精度之間做權(quán)衡。我在實際項目中比較推薦先量化再蒸餾量化是性價比很高的加速手段。要注意的是量化后的模型一定要回到你的哨兵評估集里跑一遍確認指標沒有明顯垮掉。緩存也是性能優(yōu)化的大頭對于重復到來的輸入與其重新算不如直接把之前的結(jié)果返回。某些業(yè)務里命中緩存的請求可以到30%以上這在系統(tǒng)容量設計時是不可忽視的數(shù)字。4.3 你上線的那一天監(jiān)控系統(tǒng)就要存在很多項目上線時監(jiān)控做得都很粗糙甚至沒有監(jiān)控。但模型上線之后噩夢往往才開始。模型不是軟件它的性能會隨著現(xiàn)實數(shù)據(jù)的分布變化慢慢劣化而且這種劣化不是一條醒目的報錯而是悄悄發(fā)生的。我的最低監(jiān)控清單如下請求量、延遲P50/P95/P99、錯誤率、模型預測類別的分布變化、特征的分布漂移。后兩項是模型特有的監(jiān)控維度。特征漂移通常用PSI群體穩(wěn)定性指標來度量當PSI超過閾值一般0.1是警告線0.25是異常線就要開始排查是不是線上數(shù)據(jù)分布和訓練分布產(chǎn)生了系統(tǒng)性偏差。日志一定要結(jié)構(gòu)化。不要打那種predict error的日志要打請求ID、輸入摘要、預測結(jié)果、耗時、模型版本、特征版本這種能回溯的完整字段。我踩過的坑是上線初期日志很隨意結(jié)果線上出問題時完全無法定位影響范圍和原因只能靠猜。還有一個控制風險的工程手段灰度發(fā)布。新模型不要直接切全量流量先放5%的流量跑幾天對比新老模型在線上真實數(shù)據(jù)的表現(xiàn)確認沒有劣化后再逐步放量。這個機制配合完善的監(jiān)控指標可以極大降低模型更新把線上搞掛了的風險。4.4 回滾預案比你想的更常用說到灰度就必須提回滾預案。很多團隊上線流程里寫了如有問題則回滾但真到了要執(zhí)行的時候發(fā)現(xiàn)回滾需要重新構(gòu)建鏡像、重新加載數(shù)據(jù)耗時長到事故已經(jīng)釀成。正確做法是發(fā)布系統(tǒng)支持按版本一鍵回滾部署腳本里提前留好上一個版本的鏡像并且定期演練回滾流程。我個人經(jīng)歷過一次深夜事故新模型上線后線上指標暴跌但當時回滾流程要40分鐘期間用戶一直在受影響。改造成一鍵回滾后同樣的事故恢復時間壓縮到了兩分鐘。這是工程細節(jié)但它的價值在關(guān)鍵時刻不亞于模型本身的提升。5. 常見問題與排查技巧實錄5.1 離線指標好線上卻不行的經(jīng)典原因這是我被問過最多的問題。離線測試和線上表現(xiàn)差距大通常無外乎以下幾個原因。數(shù)據(jù)分布漂移是最常見的。訓練數(shù)據(jù)是過去幾個月的歷史樣本線上數(shù)據(jù)是此時此刻的真實流量兩者的特征分布和類別分布很可能早已不同。排查手段是定時計算線上特征的PSI并與訓練分布比對。特征不一致是第二大的坑。主要表現(xiàn)為特征處理代碼在離線訓練和在線推理兩套邏輯里不一致離線時用pandas做均值填充在線服務里隨手寫成了零填充模型表現(xiàn)自然天差地別。解決思路是把特征處理邏輯抽取成獨立模塊訓練和推理共用同一份代碼并且用測試用例保證輸入輸出一致。還有一個隱蔽原因是訓練/推理的數(shù)據(jù)流差異。離線時你可以一次性拿到全部特征然后批處理線上是按實時請求逐條處理的某些需要上下文或歷史信息的特征一旦沒有正確算出模型就等于在殘缺輸入上做預測。解決方法是定義清晰的特征依賴圖并在線上服務里對每個特征來源做顯式檢查。5.2 環(huán)境依賴與復現(xiàn)的坑在我機器上能跑是團隊協(xié)作里最讓人頭大的問題。解決這個問題沒有捷徑只能靠工具和紀律。依賴鎖版本是底線Lock文件必須進入版本控制。進一步是用容器化把訓練和推理環(huán)境都做成鏡像鏡像構(gòu)建過程完全可復現(xiàn)。這樣別人拿到你的項目一條命令能復現(xiàn)訓練流程才算得上一個規(guī)范的項目。說到復現(xiàn)我還有一個比較苛刻的標準項目必須支持一鍵評估。任何人拿到這個代碼庫用一個統(tǒng)一命令就能對你訓練出的模型做完整評估輸出全部報告的指標。這樣協(xié)作、評審、復盤才會變得輕松。達成這個目標的過程中你會被迫把很多暗藏的全局變量、隱式路徑、硬編碼參數(shù)清理干凈這本身就是一次很好的工程涅槃。5.3 排查問題的基本方法論AI系統(tǒng)一旦出問題理論上每個環(huán)節(jié)都可能是元兇。所以我總結(jié)了一個排查順序按成本從低到高的原則來。先是服務層看日志、看監(jiān)控、看錯誤信息確認是接口本身的問題還是上游數(shù)據(jù)的問題。其次是數(shù)據(jù)層檢查特征分布、字段缺失率評估集是不是過期、線上數(shù)據(jù)是否觸發(fā)了分布漂移。再次是模型層用線上抽樣的數(shù)據(jù)跑一遍離線推理看是否復現(xiàn)問題如果復現(xiàn)了就定位是特征還是模型權(quán)重的問題。最后才是代碼層檢查版本是否一致、配置是否生效、有沒有臟數(shù)據(jù)混入。排查的工具建議早準備。一是對比分析工具拿出問題時段和正常時段的數(shù)據(jù)做分布對比快速感知變化。二是特征重要性分析幫你判斷哪些特征的變化最可能導致模型輸出改變。三是A/B實驗平臺如果想驗證一個修復到底是否有效用一個受控對比實驗來確認比靠感覺判斷要靠譜得多。我遇到過的最難排查的問題之一是某個特征在線上經(jīng)常延遲返回導致服務默認填充0值。模型在0值上表現(xiàn)尚可但長期累計導致特征分布嚴重失真最終整體預測質(zhì)量下滑。這類問題只有當監(jiān)控指標特征缺失率PSI足夠完善時才能快速被發(fā)現(xiàn)。這也是為什么我一直強調(diào)監(jiān)控不是上線后的可選項而是系統(tǒng)設計的一部分。5.4 常見問題快查表癥狀可能原因排查方法離線指標好線上明顯差數(shù)據(jù)分布漂移或特征不一致計算線上特征PSI檢查特征處理是否訓練推理共用線上延遲突增模型推理耗時惡化或上游數(shù)據(jù)變慢查看P99延遲按階段拆分耗時預測結(jié)果全是同一類類別分布嚴重失衡或模型退化成常量檢查線上預測類別分布比對訓練分布新模型回滾后依然異常數(shù)據(jù)污染或特征邏輯改動沒回滾檢查配置版本、特征代碼是否一并回滾實驗指標忽高忽低訓練數(shù)據(jù)或評估集被污染檢查數(shù)據(jù)版本確認評估集去重6. 寫在最后的工程紀律聊了這么多我發(fā)現(xiàn)做AI工程其實最考驗人的不是某一個具體技術(shù)而是持續(xù)保持工程紀律的耐心和環(huán)境應變能力。我自己的經(jīng)驗是每次想快一點、先跳過這個測試的時候后面都會花雙倍甚至更多的時間來還債。如果只讓我給一個最核心的建議那就是把一條命令跑通整個流程當作衡量項目成熟度的標注。訓練、評估、部署、監(jiān)控全部要能自動化執(zhí)行。這個事情做成了你的AI工程能力算是真正邁過了一個門檻。另一個經(jīng)驗是保持對線上數(shù)據(jù)的敬畏永遠不要以為離線模型好就等于線上好監(jiān)控和數(shù)據(jù)校驗才是讓你安心睡覺的保障。AI工程的路很長但每解決一個工程問題你對系統(tǒng)整體認知的積累都是實實在在的。希望這篇分享能幫你在動手的時候少走幾步彎路也期待你在自己的項目里把這些方法驗證出屬于你自己的工作流。