1. 從零搭建AI工程能力為什么我勸你別一上來就調(diào)包這兩年AI應(yīng)用開發(fā)的門檻肉眼可見地降低了隨便拉個(gè)框架、調(diào)個(gè)API就能跑出一個(gè)能對(duì)話的Demo。但我在團(tuán)隊(duì)里帶過不少新人也面試過大量號(hào)稱“做過AI項(xiàng)目”的候選人發(fā)現(xiàn)一個(gè)很普遍的現(xiàn)象模型能跑通但一遇到線上流量、數(shù)據(jù)漂移、推理延遲、成本失控這些真實(shí)工程問題立刻就抓瞎。這就是我特別想聊“ai-engineering-from-scratch”這個(gè)方向的原因——它不是教你如何調(diào)用某個(gè)大模型接口而是幫你補(bǔ)齊從零構(gòu)建AI工程能力的那套底層認(rèn)知和實(shí)操體系。所謂“from scratch”不是讓你手寫CUDA核函數(shù)或者從零訓(xùn)練一個(gè)GPT那不現(xiàn)實(shí)也沒必要。它真正的含義是把AI系統(tǒng)當(dāng)成一個(gè)完整的軟件工程項(xiàng)目來對(duì)待從數(shù)據(jù)管道、特征管理、模型訓(xùn)練、評(píng)估驗(yàn)證、部署推理到監(jiān)控迭代每一層你都要知道它在干什么、為什么這么設(shè)計(jì)、出了問題去哪里找原因。這套能力才是區(qū)分“會(huì)調(diào)包”和“能做AI工程”的分水嶺。這篇文章適合誰看如果你已經(jīng)會(huì)用Python寫點(diǎn)腳本、跑過幾個(gè)sklearn或PyTorch的示例但總覺得自己的項(xiàng)目“不成體系”上線就心虛那這篇內(nèi)容就是為你準(zhǔn)備的。我會(huì)按照一個(gè)真實(shí)AI工程項(xiàng)目的推進(jìn)順序把每個(gè)環(huán)節(jié)的核心思路、關(guān)鍵細(xì)節(jié)、實(shí)操要點(diǎn)和踩坑經(jīng)驗(yàn)都攤開來講盡量讓你看完就能對(duì)照著搭出自己的第一套AI工程骨架。2. 整體設(shè)計(jì)思路AI工程到底在工程什么2.1 先搞清楚AI工程和算法研究的邊界很多人把AI工程和算法研究混為一談結(jié)果項(xiàng)目推進(jìn)時(shí)職責(zé)不清、節(jié)奏混亂。我習(xí)慣用一句話來區(qū)分算法研究追求的是“上限”AI工程追求的是“下限”。研究側(cè)關(guān)心的是這個(gè)模型在理想條件下能跑到多高的準(zhǔn)確率工程側(cè)關(guān)心的是在真實(shí)流量、真實(shí)數(shù)據(jù)、真實(shí)硬件約束下這個(gè)系統(tǒng)能不能穩(wěn)定地跑出可接受的準(zhǔn)確率并且成本可控、可維護(hù)、可迭代。這個(gè)邊界一旦清晰你的技術(shù)選型和架構(gòu)設(shè)計(jì)就會(huì)理性很多。比如做推薦系統(tǒng)研究側(cè)可能花大量精力去試新的網(wǎng)絡(luò)結(jié)構(gòu)而工程側(cè)要解決的是特征怎么在毫秒級(jí)拼接完成、模型怎么熱更新不中斷服務(wù)、A/B實(shí)驗(yàn)怎么分流才能保證統(tǒng)計(jì)顯著性。這兩件事的難度不在一個(gè)維度上但工程側(cè)的問題不解決研究側(cè)的成果根本落不了地。我見過太多團(tuán)隊(duì)在早期把90%的資源砸在模型調(diào)優(yōu)上結(jié)果上線后發(fā)現(xiàn)推理延遲超標(biāo)、特征回填邏輯有bug、監(jiān)控指標(biāo)缺失導(dǎo)致問題定位花了兩天。這些坑本質(zhì)上都是AI工程能力缺失導(dǎo)致的。2.2 分層架構(gòu)把AI系統(tǒng)拆成可獨(dú)立演進(jìn)的模塊從零構(gòu)建AI工程能力第一步不是寫代碼而是建立分層思維。我通常把AI系統(tǒng)拆成五層每一層有明確的輸入輸出和職責(zé)邊界層級(jí)核心職責(zé)關(guān)鍵產(chǎn)出常見技術(shù)選型數(shù)據(jù)層數(shù)據(jù)采集、清洗、版本管理可復(fù)現(xiàn)的數(shù)據(jù)集DVC、Delta Lake、Great Expectations特征層特征計(jì)算、存儲(chǔ)、服務(wù)特征向量Feast、Redis、離線數(shù)倉(cāng)訓(xùn)練層模型訓(xùn)練、調(diào)參、實(shí)驗(yàn)管理模型產(chǎn)物元數(shù)據(jù)PyTorch、MLflow、Optuna推理層模型部署、服務(wù)化、加速在線預(yù)測(cè)接口ONNX Runtime、Triton、FastAPI監(jiān)控層指標(biāo)采集、漂移檢測(cè)、告警可觀測(cè)性面板Prometheus、Evidently、Grafana這個(gè)分層不是為了畫架構(gòu)圖好看而是為了讓每一層可以獨(dú)立測(cè)試、獨(dú)立替換、獨(dú)立擴(kuò)容。舉個(gè)例子當(dāng)你的特征層用Feast做了統(tǒng)一管理后訓(xùn)練時(shí)用的特征和線上推理時(shí)用的特征來自同一套定義就能從根本上避免“訓(xùn)練-服務(wù)偏差”這個(gè)經(jīng)典問題。再比如推理層用ONNX Runtime做加速訓(xùn)練層換模型結(jié)構(gòu)時(shí)只要導(dǎo)出ONNX格式推理層幾乎不用改動(dòng)。注意分層不是越細(xì)越好。我見過有人把特征層又拆成“特征計(jì)算層”和“特征存儲(chǔ)層”結(jié)果團(tuán)隊(duì)只有三個(gè)人維護(hù)成本直接爆炸。分層粒度要匹配團(tuán)隊(duì)規(guī)模和項(xiàng)目階段早期兩三層就夠了別為了架構(gòu)而架構(gòu)。2.3 為什么我堅(jiān)持“可復(fù)現(xiàn)”是AI工程的第一原則如果只能給AI工程定一條鐵律我會(huì)選“可復(fù)現(xiàn)”。一個(gè)AI項(xiàng)目如果做不到“給定同樣的數(shù)據(jù)和代碼能跑出同樣的模型和指標(biāo)”那后面所有的優(yōu)化、迭代、排查都是空中樓閣。可復(fù)現(xiàn)包含三個(gè)層面數(shù)據(jù)可復(fù)現(xiàn)、代碼可復(fù)現(xiàn)、環(huán)境可復(fù)現(xiàn)。數(shù)據(jù)可復(fù)現(xiàn)要求你對(duì)數(shù)據(jù)集做版本管理每次訓(xùn)練用的數(shù)據(jù)快照有唯一標(biāo)識(shí)代碼可復(fù)現(xiàn)要求你把隨機(jī)種子、依賴版本、超參數(shù)全部固化下來環(huán)境可復(fù)現(xiàn)要求你用容器或虛擬環(huán)境把運(yùn)行時(shí)依賴鎖死。我踩過最慘的一次坑是早期做文本分類時(shí)沒有固定隨機(jī)種子同一個(gè)腳本跑兩次F1差了3個(gè)點(diǎn)排查了一整天才發(fā)現(xiàn)是數(shù)據(jù)shuffle和權(quán)重初始化的隨機(jī)性疊加導(dǎo)致的。從那以后我在任何訓(xùn)練腳本的第一行都會(huì)加上種子設(shè)置并且把數(shù)據(jù)版本號(hào)寫進(jìn)模型元數(shù)據(jù)里。3. 核心細(xì)節(jié)解析數(shù)據(jù)、特征與訓(xùn)練的工程化要點(diǎn)3.1 數(shù)據(jù)管道別讓臟數(shù)據(jù)毀掉整個(gè)項(xiàng)目數(shù)據(jù)管道是AI工程里最不起眼但最容易出問題的環(huán)節(jié)。我的經(jīng)驗(yàn)是數(shù)據(jù)管道的復(fù)雜度往往被嚴(yán)重低估它占整個(gè)項(xiàng)目工作量的60%以上。一個(gè)健壯的數(shù)據(jù)管道需要解決四個(gè)問題數(shù)據(jù)采集的可靠性、數(shù)據(jù)清洗的規(guī)則化、數(shù)據(jù)版本的追溯性、數(shù)據(jù)質(zhì)量的監(jiān)控。先說數(shù)據(jù)采集。很多項(xiàng)目的數(shù)據(jù)來自多個(gè)源頭比如業(yè)務(wù)數(shù)據(jù)庫(kù)、日志文件、第三方接口。這時(shí)候你需要一個(gè)統(tǒng)一的采集層把不同格式的數(shù)據(jù)歸一化成統(tǒng)一的中間表示。我通常會(huì)用Apache Airflow或Prefect來做調(diào)度每個(gè)采集任務(wù)都有重試機(jī)制和失敗告警。這里的關(guān)鍵細(xì)節(jié)是采集任務(wù)必須冪等也就是說同一個(gè)時(shí)間窗口的數(shù)據(jù)重復(fù)采集不會(huì)產(chǎn)生重復(fù)記錄否則后續(xù)去重邏輯會(huì)非常痛苦。數(shù)據(jù)清洗是最考驗(yàn)工程經(jīng)驗(yàn)的地方。我的做法是把清洗規(guī)則寫成可配置的規(guī)則集而不是硬編碼在腳本里。比如用Great Expectations定義數(shù)據(jù)質(zhì)量斷言某列不能為空、某列的取值范圍在0到1之間、某列的分布不能偏離歷史均值超過3個(gè)標(biāo)準(zhǔn)差。這些斷言在每次數(shù)據(jù)加載時(shí)自動(dòng)執(zhí)行不通過就阻斷后續(xù)流程。這樣做的好處是數(shù)據(jù)問題在進(jìn)入訓(xùn)練之前就被攔截了而不是等到模型指標(biāo)異常才回頭查。數(shù)據(jù)版本管理我用的是DVC配合對(duì)象存儲(chǔ)。每次數(shù)據(jù)變更后DVC會(huì)生成一個(gè)哈希值這個(gè)哈希值就是數(shù)據(jù)集的唯一標(biāo)識(shí)。訓(xùn)練腳本引用這個(gè)哈希值就能保證任何時(shí)候都能復(fù)現(xiàn)出當(dāng)時(shí)的數(shù)據(jù)快照。這個(gè)習(xí)慣在團(tuán)隊(duì)協(xié)作中尤其重要當(dāng)同事說“我這邊指標(biāo)比你高”時(shí)你們可以先對(duì)一下數(shù)據(jù)版本號(hào)排除數(shù)據(jù)差異這個(gè)變量。3.2 特征工程訓(xùn)練和推理必須走同一條路特征工程是AI工程里最容易產(chǎn)生“訓(xùn)練-服務(wù)偏差”的地方。什么叫訓(xùn)練-服務(wù)偏差簡(jiǎn)單說就是訓(xùn)練時(shí)用的特征計(jì)算邏輯和線上推理時(shí)用的邏輯不一致導(dǎo)致模型在線上的表現(xiàn)遠(yuǎn)低于離線評(píng)估。這個(gè)問題的根源通常是訓(xùn)練時(shí)用Python pandas做特征線上用Java或Go重寫一遍兩套代碼邏輯難免有細(xì)微差異。解決這個(gè)問題的標(biāo)準(zhǔn)做法是特征平臺(tái)化。核心思想是特征的定義只寫一次訓(xùn)練和推理都調(diào)用同一套計(jì)算邏輯。Feast就是干這個(gè)的它把特征定義成Python函數(shù)離線訓(xùn)練時(shí)批量計(jì)算在線推理時(shí)通過特征服務(wù)實(shí)時(shí)獲取。這樣訓(xùn)練和推理的特征計(jì)算邏輯天然一致。如果項(xiàng)目規(guī)模還小用不上Feast這么重的方案那至少要做到把特征計(jì)算邏輯封裝成獨(dú)立的模塊訓(xùn)練和推理都import同一個(gè)模塊。千萬別訓(xùn)練一套代碼、推理一套代碼那是給自己埋雷。特征存儲(chǔ)的選型也有講究。離線特征通常存在數(shù)倉(cāng)或Parquet文件里在線特征需要低延遲讀取一般用Redis或內(nèi)存數(shù)據(jù)庫(kù)。這里的關(guān)鍵細(xì)節(jié)是在線特征的TTL設(shè)置要合理。TTL太短會(huì)導(dǎo)致特征頻繁回源計(jì)算增加延遲TTL太長(zhǎng)會(huì)導(dǎo)致特征過期影響預(yù)測(cè)準(zhǔn)確性。我的經(jīng)驗(yàn)是根據(jù)特征的更新頻率來定TTL比如用戶畫像特征每天更新一次TTL設(shè)24小時(shí)實(shí)時(shí)行為特征每秒更新TTL設(shè)幾秒到幾分鐘。3.3 訓(xùn)練流程實(shí)驗(yàn)管理比調(diào)參更重要很多人把訓(xùn)練環(huán)節(jié)等同于調(diào)參這是本末倒置。調(diào)參確實(shí)能提升指標(biāo)但如果沒有良好的實(shí)驗(yàn)管理你調(diào)了100次之后根本記不清哪次用了什么配置、對(duì)應(yīng)什么結(jié)果。實(shí)驗(yàn)管理才是訓(xùn)練環(huán)節(jié)的工程核心。我用MLflow做實(shí)驗(yàn)跟蹤每次訓(xùn)練自動(dòng)記錄超參數(shù)、數(shù)據(jù)集版本、代碼commit hash、評(píng)估指標(biāo)、模型產(chǎn)物路徑。這樣任何時(shí)候都能回溯到某次實(shí)驗(yàn)的完整上下文。更重要的是MLflow的模型注冊(cè)功能可以管理模型的生命周期從Staging到Production的每一步都有記錄方便回滾。訓(xùn)練腳本的結(jié)構(gòu)也值得說道。我習(xí)慣把訓(xùn)練腳本拆成四個(gè)部分配置加載、數(shù)據(jù)加載、模型構(gòu)建、訓(xùn)練循環(huán)。配置用YAML文件管理不同實(shí)驗(yàn)用不同的配置文件避免改代碼。數(shù)據(jù)加載部分要支持從數(shù)據(jù)版本號(hào)加載保證可復(fù)現(xiàn)。模型構(gòu)建部分把模型定義和權(quán)重初始化分開方便替換。訓(xùn)練循環(huán)部分要包含完整的日志記錄每個(gè)epoch的loss、指標(biāo)、學(xué)習(xí)率都記下來方便畫曲線分析。實(shí)操心得訓(xùn)練時(shí)一定要留一個(gè)驗(yàn)證集做早停但早停的指標(biāo)要和最終評(píng)估指標(biāo)一致。我見過有人用loss做早停但最終關(guān)心的是F1結(jié)果早停時(shí)選的模型不是F1最優(yōu)的。這種細(xì)節(jié)不注意調(diào)參調(diào)半天也白搭。4. 實(shí)操過程從零搭一套可運(yùn)行的AI工程骨架4.1 環(huán)境準(zhǔn)備與依賴鎖定動(dòng)手之前先把環(huán)境搞定。我的習(xí)慣是用conda創(chuàng)建獨(dú)立環(huán)境然后用pip-tools鎖定依賴版本。具體步驟是先寫一個(gè)requirements.in文件只寫頂層依賴比如torch、pandas、scikit-learn然后用pip-compile生成requirements.txt把所有間接依賴的版本都鎖死。這樣做的好處是半年后你重新建環(huán)境裝出來的依賴版本和當(dāng)初完全一致。conda create -n ai-eng python3.10 conda activate ai-eng pip install pip-tools pip-compile requirements.in pip-sync requirements.txt容器化方面我建議至少寫一個(gè)Dockerfile把環(huán)境和代碼打包成鏡像。這樣部署時(shí)不用在目標(biāo)機(jī)器上重新裝依賴減少環(huán)境差異導(dǎo)致的問題。Dockerfile里注意把依賴安裝和代碼拷貝分開利用Docker的層緩存加速構(gòu)建。4.2 數(shù)據(jù)版本管理與質(zhì)量校驗(yàn)數(shù)據(jù)這塊我用DVC做版本管理用Great Expectations做質(zhì)量校驗(yàn)。初始化DVC后把數(shù)據(jù)目錄納入DVC管理每次數(shù)據(jù)變更后執(zhí)行dvc add和dvc pushDVC會(huì)生成一個(gè).dvc文件記錄數(shù)據(jù)哈希。dvc init dvc add data/raw/train.csv dvc push質(zhì)量校驗(yàn)的配置我通常寫在一個(gè)JSON文件里定義每列的期望類型、取值范圍、缺失率上限。然后在數(shù)據(jù)加載函數(shù)里調(diào)用Great Expectations的校驗(yàn)接口不通過就拋異常。import great_expectations as ge df ge.read_csv(data/raw/train.csv) df.expect_column_values_to_not_be_null(label) df.expect_column_values_to_be_between(feature_1, 0, 1) results df.validate() if not results[success]: raise ValueError(Data quality check failed)這一步看起來簡(jiǎn)單但能攔截掉大量低級(jí)錯(cuò)誤。我遇到過好幾次因?yàn)樯嫌螖?shù)據(jù)表結(jié)構(gòu)變更導(dǎo)致特征列錯(cuò)位的情況有了質(zhì)量校驗(yàn)就能第一時(shí)間發(fā)現(xiàn)。4.3 特征計(jì)算模塊的封裝特征計(jì)算模塊我習(xí)慣寫成一個(gè)獨(dú)立的Python包訓(xùn)練和推理都從這個(gè)包導(dǎo)入。核心接口有兩個(gè)批量計(jì)算和單條計(jì)算。批量計(jì)算用于離線訓(xùn)練單條計(jì)算用于在線推理。# features/user_features.py def compute_user_features(user_id, user_profile, behavior_log): features {} features[age] user_profile[age] features[click_count_7d] behavior_log.query( user_id user_id and timestamp now() - 7d ).shape[0] return features這里的關(guān)鍵細(xì)節(jié)是特征計(jì)算函數(shù)必須是純函數(shù)不依賴外部狀態(tài)輸入確定則輸出確定。這樣離線批量計(jì)算和在線單條計(jì)算的結(jié)果才能一致。如果特征計(jì)算需要查數(shù)據(jù)庫(kù)把查詢結(jié)果作為參數(shù)傳進(jìn)來而不是在函數(shù)內(nèi)部直接查。4.4 訓(xùn)練腳本的標(biāo)準(zhǔn)化結(jié)構(gòu)訓(xùn)練腳本我按四段式組織配置、數(shù)據(jù)、模型、循環(huán)。配置用YAML管理數(shù)據(jù)加載引用DVC版本號(hào)模型定義和訓(xùn)練循環(huán)分離。import yaml import mlflow import torch with open(config/train.yaml) as f: config yaml.safe_load(f) mlflow.set_experiment(config[experiment_name]) with mlflow.start_run(): mlflow.log_params(config) train_data load_data(config[data_version]) model build_model(config[model]) for epoch in range(config[epochs]): train_loss train_one_epoch(model, train_data) val_metric evaluate(model, val_data) mlflow.log_metrics({train_loss: train_loss, val_metric: val_metric}, stepepoch) mlflow.pytorch.log_model(model, model)這個(gè)結(jié)構(gòu)的好處是換實(shí)驗(yàn)只需要改YAML文件代碼不用動(dòng)。MLflow自動(dòng)記錄所有參數(shù)和指標(biāo)實(shí)驗(yàn)對(duì)比一目了然。4.5 推理服務(wù)與性能優(yōu)化推理服務(wù)我用FastAPI做接口ONNX Runtime做加速。模型訓(xùn)練完后導(dǎo)出ONNX格式推理時(shí)用ONNX Runtime加載比原生PyTorch快不少尤其是在CPU上。import onnxruntime as ort from fastapi import FastAPI app FastAPI() session ort.InferenceSession(model.onnx) app.post(/predict) def predict(features: dict): input_array preprocess(features) outputs session.run(None, {input: input_array}) return {prediction: outputs[0].tolist()}性能優(yōu)化方面有幾個(gè)點(diǎn)值得注意。第一批處理如果QPS不高但單次請(qǐng)求延遲敏感可以攢一批請(qǐng)求一起推理提高吞吐。第二模型量化把FP32量化成INT8推理速度能提升2到4倍精度損失通常在1%以內(nèi)。第三緩存對(duì)于重復(fù)的輸入緩存預(yù)測(cè)結(jié)果避免重復(fù)計(jì)算。注意ONNX導(dǎo)出時(shí)要注意算子兼容性。有些PyTorch的自定義算子ONNX不支持導(dǎo)出會(huì)失敗。遇到這種情況要么改寫模型結(jié)構(gòu)要么用ONNX的自定義算子擴(kuò)展。我一般會(huì)在訓(xùn)練階段就避免使用太冷門的算子減少導(dǎo)出時(shí)的麻煩。5. 常見問題與排查技巧實(shí)錄5.1 訓(xùn)練指標(biāo)正常但線上效果差這是最經(jīng)典的問題原因通常是訓(xùn)練-服務(wù)偏差。排查思路是先對(duì)比訓(xùn)練時(shí)和推理時(shí)的特征分布看有沒有明顯差異。具體做法是在推理服務(wù)里把每次請(qǐng)求的特征向量記錄下來離線分析這些特征的分布和訓(xùn)練集的特征分布做對(duì)比。如果某個(gè)特征的分布差異很大那問題就出在這個(gè)特征的計(jì)算邏輯上。我遇到過一次訓(xùn)練時(shí)用戶年齡特征用的是注冊(cè)時(shí)填的年齡線上推理時(shí)用的是當(dāng)前時(shí)間減去出生日期算出來的年齡兩者差了一歲導(dǎo)致模型效果下降。這種問題不看特征分布根本發(fā)現(xiàn)不了。5.2 推理延遲突然飆升推理延遲飆升的原因可能有很多模型變大、請(qǐng)求量突增、特征服務(wù)超時(shí)、GC停頓。排查時(shí)先看監(jiān)控面板確認(rèn)是哪個(gè)環(huán)節(jié)的延遲增加了。如果是特征服務(wù)超時(shí)檢查特征存儲(chǔ)的負(fù)載和網(wǎng)絡(luò)延遲如果是模型推理本身變慢檢查是不是有請(qǐng)求觸發(fā)了冷啟動(dòng)或者模型熱更新。我的經(jīng)驗(yàn)是給每個(gè)環(huán)節(jié)都加上延遲監(jiān)控特征獲取、預(yù)處理、模型推理、后處理每個(gè)階段的耗時(shí)都記錄下來。這樣延遲飆升時(shí)能快速定位到具體環(huán)節(jié)。5.3 模型效果隨時(shí)間下降模型效果下降通常是數(shù)據(jù)漂移導(dǎo)致的。排查方法是定期計(jì)算線上數(shù)據(jù)的特征分布和訓(xùn)練數(shù)據(jù)的特征分布之間的差異常用的指標(biāo)是PSI或KL散度。如果某個(gè)特征的PSI超過0.2說明分布發(fā)生了顯著變化需要考慮重新訓(xùn)練模型。我通常會(huì)在監(jiān)控層加一個(gè)漂移檢測(cè)任務(wù)每天跑一次發(fā)現(xiàn)漂移就告警。重新訓(xùn)練時(shí)把新數(shù)據(jù)加入訓(xùn)練集但要注意新舊數(shù)據(jù)的比例避免新數(shù)據(jù)太少導(dǎo)致模型學(xué)不到新模式或者新數(shù)據(jù)太多導(dǎo)致模型遺忘舊模式。5.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案訓(xùn)練指標(biāo)正常但線上差訓(xùn)練-服務(wù)偏差對(duì)比特征分布統(tǒng)一特征計(jì)算邏輯推理延遲飆升特征服務(wù)超時(shí)/模型冷啟動(dòng)分環(huán)節(jié)延遲監(jiān)控加緩存/預(yù)熱模型模型效果隨時(shí)間下降數(shù)據(jù)漂移計(jì)算PSI/KL散度重新訓(xùn)練/增量學(xué)習(xí)訓(xùn)練結(jié)果不可復(fù)現(xiàn)隨機(jī)種子未固定檢查種子設(shè)置固定所有隨機(jī)源依賴沖突版本未鎖定檢查依賴樹pip-tools鎖定版本5.5 幾個(gè)容易被忽視的避坑技巧第一個(gè)技巧在訓(xùn)練腳本里記錄GPU顯存峰值。很多人訓(xùn)練時(shí)遇到OOM但不知道是哪個(gè)環(huán)節(jié)爆的。用torch.cuda.max_memory_allocated()記錄顯存峰值能幫你定位是數(shù)據(jù)加載、前向傳播還是反向傳播占用了過多顯存。第二個(gè)技巧給數(shù)據(jù)加載加預(yù)取。PyTorch的DataLoader支持num_workers和prefetch_factor參數(shù)合理設(shè)置能大幅提升訓(xùn)練速度。我的經(jīng)驗(yàn)是num_workers設(shè)為CPU核數(shù)的2到4倍prefetch_factor設(shè)為2到4。第三個(gè)技巧模型保存時(shí)同時(shí)保存預(yù)處理邏輯。很多人只保存模型權(quán)重推理時(shí)預(yù)處理邏輯另寫一套結(jié)果又引入了訓(xùn)練-服務(wù)偏差。正確的做法是把預(yù)處理邏輯和模型一起打包保存推理時(shí)直接調(diào)用。第四個(gè)技巧監(jiān)控里加上輸入數(shù)據(jù)的統(tǒng)計(jì)量。除了監(jiān)控模型輸出還要監(jiān)控輸入特征的均值、方差、缺失率。輸入數(shù)據(jù)異常往往是模型效果下降的前兆早發(fā)現(xiàn)早處理。6. 監(jiān)控與迭代讓AI系統(tǒng)持續(xù)產(chǎn)生價(jià)值6.1 可觀測(cè)性體系的搭建AI系統(tǒng)的監(jiān)控和傳統(tǒng)軟件監(jiān)控有個(gè)本質(zhì)區(qū)別傳統(tǒng)軟件監(jiān)控關(guān)注的是“系統(tǒng)是否正?！盇I系統(tǒng)監(jiān)控還要關(guān)注“模型是否正?！?。所以可觀測(cè)性體系要覆蓋三個(gè)層面系統(tǒng)層、數(shù)據(jù)層、模型層。系統(tǒng)層監(jiān)控CPU、內(nèi)存、GPU、網(wǎng)絡(luò)、磁盤這些基礎(chǔ)指標(biāo)用Prometheus采集Grafana展示。數(shù)據(jù)層監(jiān)控輸入特征的分布、缺失率、異常值比例用Evidently生成漂移報(bào)告。模型層監(jiān)控預(yù)測(cè)結(jié)果的分布、置信度、業(yè)務(wù)指標(biāo)比如點(diǎn)擊率、轉(zhuǎn)化率。這三個(gè)層面的監(jiān)控要聯(lián)動(dòng)。比如模型層發(fā)現(xiàn)預(yù)測(cè)結(jié)果分布異常就要去數(shù)據(jù)層看是不是輸入特征漂移了數(shù)據(jù)層發(fā)現(xiàn)特征缺失率飆升就要去系統(tǒng)層看是不是上游數(shù)據(jù)管道掛了。6.2 模型迭代的節(jié)奏把控模型迭代不是越頻繁越好。迭代太頻繁A/B實(shí)驗(yàn)的統(tǒng)計(jì)顯著性還沒出來就換模型根本不知道新模型是好是壞。迭代太慢模型效果下降得不到及時(shí)修復(fù)。我的經(jīng)驗(yàn)是根據(jù)業(yè)務(wù)變化速度來定迭代節(jié)奏。業(yè)務(wù)變化快的場(chǎng)景比如新聞推薦可能每天都要更新模型業(yè)務(wù)變化慢的場(chǎng)景比如信用評(píng)分可能一個(gè)月更新一次就夠了。關(guān)鍵是建立一套自動(dòng)化的重訓(xùn)練和評(píng)估流程讓迭代成本足夠低這樣該迭代時(shí)能快速迭代。重訓(xùn)練觸發(fā)條件我通常設(shè)三個(gè)定時(shí)觸發(fā)、漂移觸發(fā)、指標(biāo)觸發(fā)。定時(shí)觸發(fā)是每周或每天固定跑一次漂移觸發(fā)是PSI超過閾值時(shí)自動(dòng)觸發(fā)指標(biāo)觸發(fā)是業(yè)務(wù)指標(biāo)下降超過閾值時(shí)觸發(fā)。三個(gè)條件滿足任意一個(gè)就啟動(dòng)重訓(xùn)練。6.3 從項(xiàng)目到平臺(tái)的演進(jìn)路徑一開始不用追求大而全的平臺(tái)先把一個(gè)項(xiàng)目跑通把每個(gè)環(huán)節(jié)的最佳實(shí)踐固化下來然后再抽象成平臺(tái)能力。我的演進(jìn)路徑通常是腳本階段、模塊階段、平臺(tái)階段。腳本階段就是一堆Python腳本能跑通就行。模塊階段把數(shù)據(jù)、特征、訓(xùn)練、推理拆成獨(dú)立模塊有清晰的接口。平臺(tái)階段把模塊服務(wù)化提供統(tǒng)一的實(shí)驗(yàn)管理、特征管理、模型管理、監(jiān)控告警。這個(gè)演進(jìn)過程不能跳步。我見過團(tuán)隊(duì)一上來就搭平臺(tái)結(jié)果平臺(tái)功能一大堆但沒人用因?yàn)榇蠹疫B基本的工程規(guī)范都沒建立起來。先把一個(gè)項(xiàng)目做扎實(shí)再考慮平臺(tái)化這才是務(wù)實(shí)的路徑。6.4 團(tuán)隊(duì)協(xié)作中的工程規(guī)范AI工程項(xiàng)目往往需要多人協(xié)作工程規(guī)范就特別重要。我要求團(tuán)隊(duì)遵守幾條基本規(guī)范所有實(shí)驗(yàn)必須通過配置文件驅(qū)動(dòng)不允許硬編碼參數(shù)所有數(shù)據(jù)變更必須走DVC版本管理所有模型上線必須經(jīng)過離線評(píng)估和A/B實(shí)驗(yàn)所有代碼必須經(jīng)過review才能合并。這些規(guī)范看起來繁瑣但能避免大量協(xié)作中的混亂。比如配置文件驅(qū)動(dòng)這條當(dāng)同事復(fù)現(xiàn)你的實(shí)驗(yàn)時(shí)只需要拿到配置文件和代碼commit hash就能跑出一樣的結(jié)果不用問你“當(dāng)時(shí)學(xué)習(xí)率設(shè)的多少”。代碼review在AI項(xiàng)目里尤其重要因?yàn)锳I代碼的bug往往不會(huì)報(bào)錯(cuò)而是靜默地產(chǎn)生錯(cuò)誤結(jié)果。比如特征計(jì)算時(shí)用錯(cuò)了列、數(shù)據(jù)劃分時(shí)泄漏了驗(yàn)證集、評(píng)估指標(biāo)算錯(cuò)了這些bug不會(huì)讓程序崩潰但會(huì)讓模型效果大打折扣。有經(jīng)驗(yàn)的reviewer能發(fā)現(xiàn)這些問題。7. 一些個(gè)人體會(huì)這套從零構(gòu)建AI工程能力的方法我自己是一步步踩坑踩出來的。早期做項(xiàng)目時(shí)我也覺得調(diào)包能跑就行直到線上出問題排查了兩天兩夜才意識(shí)到工程能力的重要性。后來每做一個(gè)新項(xiàng)目我都會(huì)刻意把數(shù)據(jù)、特征、訓(xùn)練、推理、監(jiān)控這五個(gè)環(huán)節(jié)的工程化做扎實(shí)雖然前期多花一些時(shí)間但后期迭代和排查的效率提升是數(shù)量級(jí)的。如果你剛開始接觸AI工程我的建議是不要貪多先從一個(gè)最小的完整閉環(huán)做起一份數(shù)據(jù)、一個(gè)簡(jiǎn)單模型、一個(gè)推理接口、一個(gè)監(jiān)控面板。把這個(gè)閉環(huán)跑通再逐步往每個(gè)環(huán)節(jié)里加工程化的東西。這樣你既能快速看到成果又能循序漸進(jìn)地建立完整的工程能力。最后分享一個(gè)我常用的檢查清單每次新項(xiàng)目啟動(dòng)時(shí)過一遍能避免大部分低級(jí)問題數(shù)據(jù)版本號(hào)是否記錄、隨機(jī)種子是否固定、依賴是否鎖定、特征計(jì)算是否統(tǒng)一、推理服務(wù)是否有延遲監(jiān)控、模型效果是否有漂移檢測(cè)。這六條做到了你的AI項(xiàng)目就有了基本的工程保障。