據(jù)、特征、訓(xùn)練、服務(wù)全鏈路實(shí)戰(zhàn))
1. 從零搭建AI工程體系為什么我勸你別急著調(diào)包ai-engineering-from-scratch這個(gè)標(biāo)題第一次看到的時(shí)候我愣了一下。市面上講AI的教程鋪天蓋地但絕大多數(shù)都是教你import torch然后跑個(gè)預(yù)訓(xùn)練模型或者調(diào)個(gè)API接口就完事。真正從零開(kāi)始、把AI工程當(dāng)作一門(mén)系統(tǒng)工程來(lái)拆解的內(nèi)容少得可憐。我自己在這個(gè)坑里摸爬滾打了幾年帶過(guò)幾個(gè)從零起步的團(tuán)隊(duì)也見(jiàn)過(guò)太多人卡在模型跑通了但上線就崩的階段。所以看到這個(gè)標(biāo)題我特別有感觸——它戳中的不是怎么訓(xùn)一個(gè)模型而是怎么把AI這件事當(dāng)作一個(gè)工程問(wèn)題來(lái)對(duì)待。這篇文章適合誰(shuí)看如果你是剛轉(zhuǎn)行做AI的開(kāi)發(fā)者或者帶團(tuán)隊(duì)從傳統(tǒng)軟件轉(zhuǎn)向AI產(chǎn)品的技術(shù)負(fù)責(zé)人又或者是那種模型指標(biāo)很好看但線上效果一塌糊涂的從業(yè)者那接下來(lái)的內(nèi)容應(yīng)該能幫你省下不少試錯(cuò)成本。我會(huì)從整體設(shè)計(jì)思路、核心環(huán)節(jié)拆解、實(shí)操落地、問(wèn)題排查幾個(gè)維度把從零搭建AI工程這件事講透。需要提前說(shuō)明的是AI工程不等于算法研究。算法研究關(guān)心的是這個(gè)模型能不能在benchmark上刷到SOTA而AI工程關(guān)心的是這個(gè)系統(tǒng)能不能在真實(shí)場(chǎng)景下穩(wěn)定、可維護(hù)、可迭代地跑下去。兩者的思維方式完全不同這也是為什么很多算法很強(qiáng)的團(tuán)隊(duì)做出來(lái)的產(chǎn)品卻一塌糊涂。2. 整體架構(gòu)設(shè)計(jì)先想清楚數(shù)據(jù)怎么流再想模型怎么選2.1 為什么從零反而是一種優(yōu)勢(shì)很多人覺(jué)得從零開(kāi)始是劣勢(shì)沒(méi)有積累、沒(méi)有現(xiàn)成的輪子。但我的經(jīng)驗(yàn)恰恰相反——從零搭建AI工程體系最大的好處是你被迫想清楚每一個(gè)環(huán)節(jié)的必要性。如果你接手的是一個(gè)已經(jīng)跑了兩年的系統(tǒng)里面可能堆滿(mǎn)了歷史遺留的補(bǔ)丁數(shù)據(jù)管道里塞了一堆硬編碼的清洗規(guī)則模型服務(wù)里嵌了業(yè)務(wù)邏輯監(jiān)控只覆蓋了CPU和內(nèi)存。你想改任何一處都牽一發(fā)而動(dòng)全身。從零開(kāi)始你可以按照數(shù)據(jù)→特征→訓(xùn)練→評(píng)估→部署→監(jiān)控→反饋這條主線把每個(gè)環(huán)節(jié)的邊界劃清楚。我通常會(huì)把整個(gè)體系分成四層數(shù)據(jù)層負(fù)責(zé)原始數(shù)據(jù)的采集、清洗、版本管理特征層負(fù)責(zé)特征的計(jì)算、存儲(chǔ)、服務(wù)化模型層負(fù)責(zé)訓(xùn)練、評(píng)估、版本管理服務(wù)層負(fù)責(zé)推理、監(jiān)控、反饋閉環(huán)這四層之間通過(guò)明確的接口通信任何一層的改動(dòng)不應(yīng)該影響其他層的內(nèi)部實(shí)現(xiàn)。這個(gè)原則聽(tīng)起來(lái)簡(jiǎn)單但實(shí)際操作中90%的團(tuán)隊(duì)都會(huì)在特征層和模型層之間糊掉——訓(xùn)練時(shí)用的特征計(jì)算邏輯和線上服務(wù)時(shí)用的邏輯不一致這是最經(jīng)典的坑。2.2 技術(shù)選型的核心邏輯別追新追可控選型這件事我的原則是優(yōu)先選擇你能完全掌控的技術(shù)棧而不是社區(qū)最火的那個(gè)。舉個(gè)例子特征存儲(chǔ)這塊市面上有Feast、Tecton等各種方案。但如果你團(tuán)隊(duì)只有三五個(gè)人我建議直接用Redis加一套簡(jiǎn)單的元數(shù)據(jù)管理就夠了。為什么因?yàn)镕east的抽象層很厚出問(wèn)題的時(shí)候你排查成本極高。而Redis你至少知道它什么時(shí)候會(huì)掛、掛了怎么恢復(fù)。模型服務(wù)這塊也是同理。TorchServe、Triton、BentoML各有各的好但如果你對(duì)推理性能沒(méi)有極致要求直接用FastAPI包一層PyTorch模型反而更靈活。我見(jiàn)過(guò)太多團(tuán)隊(duì)為了用Triton花了兩周搭環(huán)境結(jié)果發(fā)現(xiàn)自己的模型根本用不上動(dòng)態(tài)batching。這里給一個(gè)我常用的選型對(duì)照表供參考環(huán)節(jié)小團(tuán)隊(duì)推薦中大型團(tuán)隊(duì)推薦選擇理由數(shù)據(jù)版本管理DVCLakeFS小團(tuán)隊(duì)用DVC足夠大團(tuán)隊(duì)需要更強(qiáng)的并發(fā)和權(quán)限控制特征存儲(chǔ)Redis 自建元數(shù)據(jù)Feast / Tecton小團(tuán)隊(duì)優(yōu)先可控性大團(tuán)隊(duì)優(yōu)先復(fù)用性實(shí)驗(yàn)管理MLflowWB / MLflowMLflow開(kāi)源可控WB體驗(yàn)更好但依賴(lài)外部服務(wù)模型服務(wù)FastAPI PyTorchTriton / TorchServe小團(tuán)隊(duì)優(yōu)先靈活性大團(tuán)隊(duì)優(yōu)先性能監(jiān)控Prometheus Grafana同上 自定義指標(biāo)基礎(chǔ)監(jiān)控方案通用關(guān)鍵是自定義業(yè)務(wù)指標(biāo)這張表不是標(biāo)準(zhǔn)答案而是一個(gè)思考框架。核心邏輯是你的團(tuán)隊(duì)規(guī)模決定了你能承受的抽象層厚度。人越少抽象層越薄越好。2.3 數(shù)據(jù)流設(shè)計(jì)把訓(xùn)練-服務(wù)一致性放在第一位AI工程里最容易被低估的問(wèn)題就是訓(xùn)練和服務(wù)的數(shù)據(jù)處理不一致。訓(xùn)練的時(shí)候你用Pandas做特征線上你用Java做特征兩邊邏輯稍微有點(diǎn)差異模型效果就會(huì)大打折扣。我的做法是特征計(jì)算邏輯只寫(xiě)一次訓(xùn)練和服務(wù)共用同一套代碼。具體來(lái)說(shuō)我會(huì)把特征計(jì)算封裝成獨(dú)立的Python模塊訓(xùn)練時(shí)直接調(diào)用服務(wù)時(shí)通過(guò)一個(gè)輕量級(jí)的服務(wù)框架比如FastAPI暴露出去。這樣雖然犧牲了一點(diǎn)性能但換來(lái)的是邏輯一致性。如果性能確實(shí)扛不住那就退而求其次用同一套配置文件和同一套測(cè)試用例來(lái)保證兩邊邏輯一致。每次改動(dòng)特征邏輯必須同時(shí)更新訓(xùn)練和服務(wù)的測(cè)試用例CI里跑通才能合并。3. 核心環(huán)節(jié)拆解數(shù)據(jù)、特征、訓(xùn)練、服務(wù)每個(gè)環(huán)節(jié)都有坑3.1 數(shù)據(jù)層別急著清洗先做好版本管理數(shù)據(jù)層最容易犯的錯(cuò)誤就是一上來(lái)就寫(xiě)清洗腳本。今天發(fā)現(xiàn)缺失值多了加一條填充規(guī)則明天發(fā)現(xiàn)某個(gè)字段格式不對(duì)加一條正則替換。三個(gè)月后你的清洗腳本變成了一團(tuán)亂麻沒(méi)人敢改。正確的做法是先把原始數(shù)據(jù)原封不動(dòng)地存下來(lái)做好版本管理然后再在上面做清洗。原始數(shù)據(jù)存儲(chǔ)這塊我建議用對(duì)象存儲(chǔ)比如S3兼容的MinIO按日期和來(lái)源分目錄。每次數(shù)據(jù)更新打一個(gè)版本標(biāo)簽。這樣你隨時(shí)可以回到任何一個(gè)歷史版本復(fù)現(xiàn)當(dāng)時(shí)的訓(xùn)練結(jié)果。清洗邏輯則單獨(dú)放在一個(gè)模塊里每個(gè)清洗步驟都有明確的輸入和輸出。我習(xí)慣用DVC來(lái)管理數(shù)據(jù)版本配合一個(gè)簡(jiǎn)單的dvc.yaml定義清洗流水線stages: clean: cmd: python clean.py --input data/raw --output data/clean deps: - data/raw - clean.py outs: - data/clean這樣每次跑dvc reproDVC會(huì)自動(dòng)檢查依賴(lài)是否變化決定要不要重新執(zhí)行清洗。數(shù)據(jù)版本和代碼版本綁定在一起復(fù)現(xiàn)實(shí)驗(yàn)的時(shí)候不會(huì)出現(xiàn)數(shù)據(jù)對(duì)不上的問(wèn)題。注意原始數(shù)據(jù)永遠(yuǎn)不要覆蓋。我見(jiàn)過(guò)團(tuán)隊(duì)為了省存儲(chǔ)空間清洗后直接覆蓋原始數(shù)據(jù)結(jié)果后來(lái)發(fā)現(xiàn)清洗邏輯有bug想回滾都回不去。3.2 特征層離線在線一致性是生命線特征層的核心挑戰(zhàn)就是離線特征和在線特征的一致性。離線訓(xùn)練時(shí)你用Spark算特征在線服務(wù)時(shí)你用Redis查特征兩邊如果對(duì)不上模型效果直接崩盤(pán)。我的解決方案是特征定義用同一份配置離線在線各自實(shí)現(xiàn)但用同一套測(cè)試用例驗(yàn)證。具體來(lái)說(shuō)我會(huì)定義一個(gè)特征配置文件比如features.yamlfeatures: user_avg_order_value: type: float source: orders computation: mean(amount) over last 30 days user_order_count_7d: type: int source: orders computation: count(*) over last 7 days離線側(cè)用Spark讀取這個(gè)配置生成特征計(jì)算任務(wù)在線側(cè)用Python讀取同一個(gè)配置生成Redis查詢(xún)邏輯。然后寫(xiě)一套測(cè)試用例用同一批模擬數(shù)據(jù)分別跑離線和在線對(duì)比結(jié)果是否一致。這套機(jī)制聽(tīng)起來(lái)有點(diǎn)重但它是保證特征一致性的唯一可靠辦法。我試過(guò)靠人工review來(lái)保證一致性結(jié)果每次發(fā)版都提心吊膽后來(lái)還是老老實(shí)實(shí)上了自動(dòng)化測(cè)試。3.3 訓(xùn)練層實(shí)驗(yàn)管理不是可選項(xiàng)是必選項(xiàng)訓(xùn)練層最容易失控的地方就是實(shí)驗(yàn)管理。今天調(diào)個(gè)學(xué)習(xí)率明天換個(gè)網(wǎng)絡(luò)結(jié)構(gòu)如果沒(méi)有系統(tǒng)化的實(shí)驗(yàn)管理兩周后你根本記不清哪個(gè)模型對(duì)應(yīng)哪組參數(shù)。MLflow是我用得最順手的實(shí)驗(yàn)管理工具。每次訓(xùn)練自動(dòng)記錄參數(shù)、指標(biāo)、模型文件還可以把模型注冊(cè)到Model Registry里標(biāo)記哪個(gè)版本可以上線。一個(gè)典型的訓(xùn)練腳本大概長(zhǎng)這樣import mlflow import mlflow.pytorch with mlflow.start_run(): mlflow.log_params({lr: 0.001, batch_size: 64, epochs: 10}) for epoch in range(10): train_loss train_one_epoch(model, train_loader) val_loss validate(model, val_loader) mlflow.log_metrics({train_loss: train_loss, val_loss: val_loss}, stepepoch) mlflow.pytorch.log_model(model, model)這樣每次訓(xùn)練完你都能在MLflow UI里看到完整的實(shí)驗(yàn)記錄。更重要的是模型注冊(cè)后服務(wù)層可以直接從Registry拉取指定版本的模型不需要手動(dòng)拷貝文件。實(shí)操心得實(shí)驗(yàn)命名一定要有規(guī)范。我習(xí)慣用{項(xiàng)目名}-{日期}-{改動(dòng)點(diǎn)}的格式比如recommend-20240115-add-user-features。這樣半年后回頭看還能快速定位到某次實(shí)驗(yàn)的上下文。3.4 服務(wù)層推理性能不是唯一指標(biāo)服務(wù)層這塊很多人一上來(lái)就盯著QPS和延遲。當(dāng)然這很重要但我想說(shuō)的是可觀測(cè)性比性能更重要。一個(gè)推理服務(wù)如果QPS很高但出了問(wèn)題時(shí)你完全不知道哪里出了錯(cuò)那這個(gè)服務(wù)就是不可維護(hù)的。我通常會(huì)在服務(wù)層加三類(lèi)監(jiān)控基礎(chǔ)監(jiān)控CPU、內(nèi)存、GPU利用率、請(qǐng)求量、延遲分布業(yè)務(wù)監(jiān)控輸入特征分布、輸出預(yù)測(cè)分布、異常輸入比例模型監(jiān)控預(yù)測(cè)置信度分布、特征缺失率、模型版本業(yè)務(wù)監(jiān)控和模型監(jiān)控是很多人會(huì)忽略的。舉個(gè)例子如果某天輸入特征的分布突然偏移了比如用戶(hù)年齡字段突然全是0模型預(yù)測(cè)結(jié)果肯定會(huì)出問(wèn)題。如果你只監(jiān)控了CPU和延遲根本發(fā)現(xiàn)不了這個(gè)問(wèn)題。我習(xí)慣用Prometheus加自定義指標(biāo)來(lái)實(shí)現(xiàn)這套監(jiān)控。比如在FastAPI里加一個(gè)中間件記錄每次請(qǐng)求的輸入特征統(tǒng)計(jì)信息from prometheus_client import Histogram feature_age_hist Histogram(feature_age, Distribution of user age) app.middleware(http) async def monitor_features(request, call_next): body await request.json() if age in body: feature_age_hist.observe(body[age]) response await call_next(request) return response這樣在Grafana里就能看到特征分布的變化趨勢(shì)一旦發(fā)現(xiàn)異?？梢约皶r(shí)告警。4. 實(shí)操落地從零搭建一個(gè)可運(yùn)行的AI工程原型4.1 環(huán)境準(zhǔn)備與項(xiàng)目結(jié)構(gòu)說(shuō)了這么多理論接下來(lái)我?guī)銖牧愦钜粋€(gè)可運(yùn)行的AI工程原型。這個(gè)原型包含數(shù)據(jù)清洗、特征計(jì)算、模型訓(xùn)練、模型服務(wù)、監(jiān)控五個(gè)環(huán)節(jié)代碼量不大但結(jié)構(gòu)完整。先看項(xiàng)目結(jié)構(gòu)ai-engineering-from-scratch/ ├── data/ │ ├── raw/ │ └── clean/ ├── features/ │ ├── features.yaml │ ├── offline.py │ └── online.py ├── training/ │ ├── train.py │ └── evaluate.py ├── serving/ │ ├── app.py │ └── monitor.py ├── tests/ │ └── test_feature_consistency.py ├── dvc.yaml └── requirements.txt這個(gè)結(jié)構(gòu)的關(guān)鍵在于features/目錄下的offline.py和online.py共用同一份features.yaml配置tests/目錄下的測(cè)試用例保證兩邊邏輯一致。環(huán)境準(zhǔn)備很簡(jiǎn)單Python 3.9以上裝幾個(gè)核心依賴(lài)pip install pandas scikit-learn fastapi uvicorn prometheus-client dvc mlflow4.2 數(shù)據(jù)清洗與特征計(jì)算假設(shè)我們的場(chǎng)景是用戶(hù)購(gòu)買(mǎi)行為預(yù)測(cè)原始數(shù)據(jù)是一份訂單記錄CSV。清洗邏輯很簡(jiǎn)單去掉金額為負(fù)的記錄填充缺失的用戶(hù)年齡。# clean.py import pandas as pd def clean_data(input_path, output_path): df pd.read_csv(input_path) df df[df[amount] 0] df[age] df[age].fillna(df[age].median()) df.to_csv(output_path, indexFalse) if __name__ __main__: clean_data(data/raw/orders.csv, data/clean/orders.csv)特征計(jì)算這塊離線用Pandas在線用Redis查詢(xún)但都讀取同一份features.yaml# features/offline.py import pandas as pd import yaml def compute_features(df, config_pathfeatures/features.yaml): with open(config_path) as f: config yaml.safe_load(f) features pd.DataFrame() features[user_avg_order_value] df.groupby(user_id)[amount].mean() features[user_order_count_7d] df.groupby(user_id)[amount].count() return features在線側(cè)的邏輯類(lèi)似只是數(shù)據(jù)源從DataFrame變成了Redis# features/online.py import redis import yaml r redis.Redis(hostlocalhost, port6379) def get_features(user_id, config_pathfeatures/features.yaml): with open(config_path) as f: config yaml.safe_load(f) features {} features[user_avg_order_value] float(r.get(fuser:{user_id}:avg_order_value) or 0) features[user_order_count_7d] int(r.get(fuser:{user_id}:order_count_7d) or 0) return features4.3 模型訓(xùn)練與評(píng)估訓(xùn)練腳本用MLflow記錄實(shí)驗(yàn)?zāi)Ｐ陀胹cikit-learn的隨機(jī)森林# training/train.py import mlflow import mlflow.sklearn import pandas as pd from sklearn.ensemble import RandomForestClassifier from sklearn.model_selection import train_test_split from sklearn.metrics import accuracy_score def train(): df pd.read_csv(data/clean/orders.csv) features pd.read_csv(data/clean/features.csv) X features y df[is_high_value] X_train, X_test, y_train, y_test train_test_split(X, y, test_size0.2) with mlflow.start_run(): model RandomForestClassifier(n_estimators100, max_depth5) model.fit(X_train, y_train) preds model.predict(X_test) acc accuracy_score(y_test, preds) mlflow.log_param(n_estimators, 100) mlflow.log_param(max_depth, 5) mlflow.log_metric(accuracy, acc) mlflow.sklearn.log_model(model, model) print(fAccuracy: {acc}) if __name__ __main__: train()評(píng)估這塊除了準(zhǔn)確率我還會(huì)看特征重要性和混淆矩陣。特征重要性可以幫你判斷模型是不是學(xué)到了合理的模式混淆矩陣可以幫你判斷模型在哪個(gè)類(lèi)別上表現(xiàn)差。4.4 模型服務(wù)與監(jiān)控服務(wù)層用FastAPI包一層加載MLflow注冊(cè)的模型# serving/app.py import mlflow.pyfunc from fastapi import FastAPI from features.online import get_features from prometheus_client import Histogram, make_asgi_app app FastAPI() model mlflow.pyfunc.load_model(models:/order_value_model/Production) prediction_hist Histogram(prediction_score, Distribution of prediction scores) app.post(/predict) def predict(user_id: str): features get_features(user_id) input_df pd.DataFrame([features]) score model.predict(input_df)[0] prediction_hist.observe(score) return {user_id: user_id, score: float(score)} app.mount(/metrics, make_asgi_app())監(jiān)控這塊除了Prometheus的基礎(chǔ)指標(biāo)我還加了一個(gè)預(yù)測(cè)分?jǐn)?shù)分布的直方圖。如果某天預(yù)測(cè)分?jǐn)?shù)突然集中到某個(gè)值說(shuō)明輸入特征可能出了問(wèn)題需要排查。4.5 特征一致性測(cè)試最后是特征一致性測(cè)試這是保證離線在線一致的關(guān)鍵# tests/test_feature_consistency.py import pandas as pd from features.offline import compute_features from features.online import get_features def test_feature_consistency(): df pd.DataFrame({ user_id: [u1, u1, u2], amount: [10.0, 20.0, 30.0] }) offline_features compute_features(df) # 模擬在線特征實(shí)際測(cè)試中需要先寫(xiě)入Redis online_features { u1: get_features(u1), u2: get_features(u2) } for user_id in offline_features.index: for feature_name in offline_features.columns: offline_val offline_features.loc[user_id, feature_name] online_val online_features[user_id][feature_name] assert abs(offline_val - online_val) 1e-6, \ fMismatch for {user_id}.{feature_name}: {offline_val} vs {online_val}這個(gè)測(cè)試跑通才能保證上線后模型效果和離線評(píng)估一致。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 模型上線后效果暴跌怎么排查這是最經(jīng)典的問(wèn)題。模型離線AUC 0.85上線后業(yè)務(wù)指標(biāo)反而下降。排查思路按以下順序來(lái)檢查特征一致性跑一遍特征一致性測(cè)試看離線在線特征是否對(duì)齊。這是最常見(jiàn)的原因占我遇到問(wèn)題的60%以上。檢查數(shù)據(jù)分布偏移對(duì)比訓(xùn)練數(shù)據(jù)和線上推理數(shù)據(jù)的特征分布。如果線上某個(gè)特征分布明顯偏移說(shuō)明訓(xùn)練數(shù)據(jù)不能代表線上場(chǎng)景。檢查標(biāo)簽定義有時(shí)候離線標(biāo)簽和業(yè)務(wù)指標(biāo)的定義不一致。比如離線用7天內(nèi)是否復(fù)購(gòu)作為標(biāo)簽但業(yè)務(wù)關(guān)心的是30天GMV兩者優(yōu)化目標(biāo)不同。檢查服務(wù)延遲如果推理延遲過(guò)高可能導(dǎo)致請(qǐng)求超時(shí)實(shí)際生效的請(qǐng)求比例很低。我整理了一個(gè)排查速查表現(xiàn)象可能原因排查方法離線指標(biāo)好線上指標(biāo)差特征不一致跑特征一致性測(cè)試線上指標(biāo)逐漸下降數(shù)據(jù)分布偏移對(duì)比特征分布線上指標(biāo)波動(dòng)大服務(wù)不穩(wěn)定檢查延遲和錯(cuò)誤率某些用戶(hù)效果特別差冷啟動(dòng)問(wèn)題分析新老用戶(hù)分組指標(biāo)5.2 特征計(jì)算太慢訓(xùn)練等不起怎么辦特征計(jì)算慢是另一個(gè)高頻問(wèn)題。我的優(yōu)化思路分三步第一步增量計(jì)算。不要每次全量重算只計(jì)算新增數(shù)據(jù)對(duì)應(yīng)的特征。比如用戶(hù)過(guò)去30天訂單數(shù)只需要在昨天的基礎(chǔ)上加上今天的新訂單減去30天前的舊訂單。第二步并行化。用Spark或者Dask把特征計(jì)算并行化按用戶(hù)ID分片。這一步通常能帶來(lái)10倍以上的加速。第三步預(yù)計(jì)算。把常用的特征提前算好存到Redis或者特征存儲(chǔ)里訓(xùn)練時(shí)直接讀取。代價(jià)是存儲(chǔ)成本增加但訓(xùn)練速度會(huì)快很多。實(shí)操心得特征計(jì)算優(yōu)化不要一步到位。先跑通全量計(jì)算確認(rèn)邏輯正確再做增量化和并行化。我見(jiàn)過(guò)團(tuán)隊(duì)一上來(lái)就搞增量計(jì)算結(jié)果邏輯寫(xiě)錯(cuò)了排查了兩周才發(fā)現(xiàn)。5.3 模型版本管理混亂怎么治理模型版本管理混亂的典型表現(xiàn)是線上跑的是哪個(gè)模型沒(méi)人知道回滾的時(shí)候找不到上一個(gè)版本。治理方案很簡(jiǎn)單所有模型必須通過(guò)Model Registry管理禁止手動(dòng)拷貝模型文件。MLflow的Model Registry可以給模型打標(biāo)簽比如Staging、Production、Archived。服務(wù)層加載模型時(shí)只認(rèn)Production標(biāo)簽不認(rèn)具體版本號(hào)。這樣回滾的時(shí)候只需要把上一個(gè)版本重新標(biāo)記為Production服務(wù)層自動(dòng)加載新版本。from mlflow.tracking import MlflowClient client MlflowClient() client.transition_model_version_stage( nameorder_value_model, version3, stageProduction )這套機(jī)制配合CI/CD可以實(shí)現(xiàn)模型的自動(dòng)化發(fā)布和回滾。5.4 監(jiān)控告警太多怎么降噪監(jiān)控告警太多最后大家都不看了這是監(jiān)控體系失效的開(kāi)始。降噪的核心思路是只對(duì)可行動(dòng)的問(wèn)題告警。什么叫可行動(dòng)就是收到告警的人知道該做什么。比如CPU利用率超過(guò)90%是可行動(dòng)的因?yàn)榭梢詳U(kuò)容但某個(gè)特征均值偏移了0.1%就不可行動(dòng)因?yàn)椴恢酪灰幚?。我的做法是分兩?jí)告警P0告警服務(wù)不可用、錯(cuò)誤率超過(guò)閾值、延遲超過(guò)閾值。這類(lèi)告警直接打電話(huà)。P1告警特征分布偏移、預(yù)測(cè)分?jǐn)?shù)異常、模型版本不一致。這類(lèi)告警發(fā)到群里工作時(shí)間處理。P1告警的閾值不要設(shè)得太敏感否則每天幾十條告警大家很快就麻木了。我通常會(huì)用過(guò)去7天的數(shù)據(jù)計(jì)算一個(gè)基線只有偏移超過(guò)3個(gè)標(biāo)準(zhǔn)差才告警。6. 一些踩坑之后的個(gè)人體會(huì)從零搭建AI工程體系這件事我最大的體會(huì)是工程能力比算法能力更稀缺。我見(jiàn)過(guò)太多算法很強(qiáng)的團(tuán)隊(duì)模型指標(biāo)刷得很高但工程體系一塌糊涂上線就崩。也見(jiàn)過(guò)算法一般但工程扎實(shí)的團(tuán)隊(duì)模型效果雖然不是頂尖但系統(tǒng)穩(wěn)定可靠業(yè)務(wù)價(jià)值反而更大。如果你正在從零搭建AI工程體系我的建議是先把數(shù)據(jù)層和特征層做扎實(shí)這兩層是地基。模型層和服務(wù)層可以先用最簡(jiǎn)單的方案跑通后面再逐步優(yōu)化。不要一上來(lái)就追求大而全的架構(gòu)那樣很容易陷入架構(gòu)很漂亮但跑不起來(lái)的困境。另外測(cè)試和監(jiān)控一定要從第一天就加上。我試過(guò)先跑通再補(bǔ)測(cè)試結(jié)果補(bǔ)測(cè)試的時(shí)候發(fā)現(xiàn)一堆隱藏問(wèn)題改起來(lái)比從頭寫(xiě)還麻煩。特征一致性測(cè)試、模型版本管理、基礎(chǔ)監(jiān)控這三樣是底線不能省。最后分享一個(gè)我常用的檢查清單每次上線新模型前過(guò)一遍特征一致性測(cè)試是否通過(guò)模型是否注冊(cè)到Model Registry并標(biāo)記為Production服務(wù)層是否加載了正確的模型版本基礎(chǔ)監(jiān)控和業(yè)務(wù)監(jiān)控是否覆蓋回滾方案是否準(zhǔn)備好這個(gè)清單不長(zhǎng)但能擋住80%的上線事故。 從零搭建AI工程體系：數(shù)據(jù)、特征、訓(xùn)練、服務(wù)全鏈路實(shí)戰(zhàn)
1. 從零搭建AI工程體系為什么我勸你別急著調(diào)包ai-engineering-from-scratch這個(gè)標(biāo)題第一次看到的時(shí)候我愣了一下。市面上講AI的教程鋪天蓋地但絕大多數(shù)都是教你import torch然后跑個(gè)預(yù)訓(xùn)練模型或者調(diào)個(gè)API接口就完事。真正從零開(kāi)始、把AI工程當(dāng)作一門(mén)系統(tǒng)工程來(lái)拆解的內(nèi)容少得可憐。我自己在這個(gè)坑里摸爬滾打了幾年帶過(guò)幾個(gè)從零起步的團(tuán)隊(duì)也見(jiàn)過(guò)太多人卡在模型跑通了但上線就崩的階段。所以看到這個(gè)標(biāo)題我特別有感觸——它戳中的不是怎么訓(xùn)一個(gè)模型而是怎么把AI這件事當(dāng)作一個(gè)工程問(wèn)題來(lái)對(duì)待。這篇文章適合誰(shuí)看如果你是剛轉(zhuǎn)行做AI的開(kāi)發(fā)者或者帶團(tuán)隊(duì)從傳統(tǒng)軟件轉(zhuǎn)向AI產(chǎn)品的技術(shù)負(fù)責(zé)人又或者是那種模型指標(biāo)很好看但線上效果一塌糊涂的從業(yè)者那接下來(lái)的內(nèi)容應(yīng)該能幫你省下不少試錯(cuò)成本。我會(huì)從整體設(shè)計(jì)思路、核心環(huán)節(jié)拆解、實(shí)操落地、問(wèn)題排查幾個(gè)維度把從零搭建AI工程這件事講透。需要提前說(shuō)明的是AI工程不等于算法研究。算法研究關(guān)心的是這個(gè)模型能不能在benchmark上刷到SOTA而AI工程關(guān)心的是這個(gè)系統(tǒng)能不能在真實(shí)場(chǎng)景下穩(wěn)定、可維護(hù)、可迭代地跑下去。兩者的思維方式完全不同這也是為什么很多算法很強(qiáng)的團(tuán)隊(duì)做出來(lái)的產(chǎn)品卻一塌糊涂。2. 整體架構(gòu)設(shè)計(jì)先想清楚數(shù)據(jù)怎么流再想模型怎么選2.1 為什么從零反而是一種優(yōu)勢(shì)很多人覺(jué)得從零開(kāi)始是劣勢(shì)沒(méi)有積累、沒(méi)有現(xiàn)成的輪子。但我的經(jīng)驗(yàn)恰恰相反——從零搭建AI工程體系最大的好處是你被迫想清楚每一個(gè)環(huán)節(jié)的必要性。如果你接手的是一個(gè)已經(jīng)跑了兩年的系統(tǒng)里面可能堆滿(mǎn)了歷史遺留的補(bǔ)丁數(shù)據(jù)管道里塞了一堆硬編碼的清洗規(guī)則模型服務(wù)里嵌了業(yè)務(wù)邏輯監(jiān)控只覆蓋了CPU和內(nèi)存。你想改任何一處都牽一發(fā)而動(dòng)全身。從零開(kāi)始你可以按照數(shù)據(jù)→特征→訓(xùn)練→評(píng)估→部署→監(jiān)控→反饋這條主線把每個(gè)環(huán)節(jié)的邊界劃清楚。我通常會(huì)把整個(gè)體系分成四層數(shù)據(jù)層負(fù)責(zé)原始數(shù)據(jù)的采集、清洗、版本管理特征層負(fù)責(zé)特征的計(jì)算、存儲(chǔ)、服務(wù)化模型層負(fù)責(zé)訓(xùn)練、評(píng)估、版本管理服務(wù)層負(fù)責(zé)推理、監(jiān)控、反饋閉環(huán)這四層之間通過(guò)明確的接口通信任何一層的改動(dòng)不應(yīng)該影響其他層的內(nèi)部實(shí)現(xiàn)。這個(gè)原則聽(tīng)起來(lái)簡(jiǎn)單但實(shí)際操作中90%的團(tuán)隊(duì)都會(huì)在特征層和模型層之間糊掉——訓(xùn)練時(shí)用的特征計(jì)算邏輯和線上服務(wù)時(shí)用的邏輯不一致這是最經(jīng)典的坑。2.2 技術(shù)選型的核心邏輯別追新追可控選型這件事我的原則是優(yōu)先選擇你能完全掌控的技術(shù)棧而不是社區(qū)最火的那個(gè)。舉個(gè)例子特征存儲(chǔ)這塊市面上有Feast、Tecton等各種方案。但如果你團(tuán)隊(duì)只有三五個(gè)人我建議直接用Redis加一套簡(jiǎn)單的元數(shù)據(jù)管理就夠了。為什么因?yàn)镕east的抽象層很厚出問(wèn)題的時(shí)候你排查成本極高。而Redis你至少知道它什么時(shí)候會(huì)掛、掛了怎么恢復(fù)。模型服務(wù)這塊也是同理。TorchServe、Triton、BentoML各有各的好但如果你對(duì)推理性能沒(méi)有極致要求直接用FastAPI包一層PyTorch模型反而更靈活。我見(jiàn)過(guò)太多團(tuán)隊(duì)為了用Triton花了兩周搭環(huán)境結(jié)果發(fā)現(xiàn)自己的模型根本用不上動(dòng)態(tài)batching。這里給一個(gè)我常用的選型對(duì)照表供參考環(huán)節(jié)小團(tuán)隊(duì)推薦中大型團(tuán)隊(duì)推薦選擇理由數(shù)據(jù)版本管理DVCLakeFS小團(tuán)隊(duì)用DVC足夠大團(tuán)隊(duì)需要更強(qiáng)的并發(fā)和權(quán)限控制特征存儲(chǔ)Redis 自建元數(shù)據(jù)Feast / Tecton小團(tuán)隊(duì)優(yōu)先可控性大團(tuán)隊(duì)優(yōu)先復(fù)用性實(shí)驗(yàn)管理MLflowWB / MLflowMLflow開(kāi)源可控WB體驗(yàn)更好但依賴(lài)外部服務(wù)模型服務(wù)FastAPI PyTorchTriton / TorchServe小團(tuán)隊(duì)優(yōu)先靈活性大團(tuán)隊(duì)優(yōu)先性能監(jiān)控Prometheus Grafana同上 自定義指標(biāo)基礎(chǔ)監(jiān)控方案通用關(guān)鍵是自定義業(yè)務(wù)指標(biāo)這張表不是標(biāo)準(zhǔn)答案而是一個(gè)思考框架。核心邏輯是你的團(tuán)隊(duì)規(guī)模決定了你能承受的抽象層厚度。人越少抽象層越薄越好。2.3 數(shù)據(jù)流設(shè)計(jì)把訓(xùn)練-服務(wù)一致性放在第一位AI工程里最容易被低估的問(wèn)題就是訓(xùn)練和服務(wù)的數(shù)據(jù)處理不一致。訓(xùn)練的時(shí)候你用Pandas做特征線上你用Java做特征兩邊邏輯稍微有點(diǎn)差異模型效果就會(huì)大打折扣。我的做法是特征計(jì)算邏輯只寫(xiě)一次訓(xùn)練和服務(wù)共用同一套代碼。具體來(lái)說(shuō)我會(huì)把特征計(jì)算封裝成獨(dú)立的Python模塊訓(xùn)練時(shí)直接調(diào)用服務(wù)時(shí)通過(guò)一個(gè)輕量級(jí)的服務(wù)框架比如FastAPI暴露出去。這樣雖然犧牲了一點(diǎn)性能但換來(lái)的是邏輯一致性。如果性能確實(shí)扛不住那就退而求其次用同一套配置文件和同一套測(cè)試用例來(lái)保證兩邊邏輯一致。每次改動(dòng)特征邏輯必須同時(shí)更新訓(xùn)練和服務(wù)的測(cè)試用例CI里跑通才能合并。3. 核心環(huán)節(jié)拆解數(shù)據(jù)、特征、訓(xùn)練、服務(wù)每個(gè)環(huán)節(jié)都有坑3.1 數(shù)據(jù)層別急著清洗先做好版本管理數(shù)據(jù)層最容易犯的錯(cuò)誤就是一上來(lái)就寫(xiě)清洗腳本。今天發(fā)現(xiàn)缺失值多了加一條填充規(guī)則明天發(fā)現(xiàn)某個(gè)字段格式不對(duì)加一條正則替換。三個(gè)月后你的清洗腳本變成了一團(tuán)亂麻沒(méi)人敢改。正確的做法是先把原始數(shù)據(jù)原封不動(dòng)地存下來(lái)做好版本管理然后再在上面做清洗。原始數(shù)據(jù)存儲(chǔ)這塊我建議用對(duì)象存儲(chǔ)比如S3兼容的MinIO按日期和來(lái)源分目錄。每次數(shù)據(jù)更新打一個(gè)版本標(biāo)簽。這樣你隨時(shí)可以回到任何一個(gè)歷史版本復(fù)現(xiàn)當(dāng)時(shí)的訓(xùn)練結(jié)果。清洗邏輯則單獨(dú)放在一個(gè)模塊里每個(gè)清洗步驟都有明確的輸入和輸出。我習(xí)慣用DVC來(lái)管理數(shù)據(jù)版本配合一個(gè)簡(jiǎn)單的dvc.yaml定義清洗流水線stages: clean: cmd: python clean.py --input data/raw --output data/clean deps: - data/raw - clean.py outs: - data/clean這樣每次跑dvc reproDVC會(huì)自動(dòng)檢查依賴(lài)是否變化決定要不要重新執(zhí)行清洗。數(shù)據(jù)版本和代碼版本綁定在一起復(fù)現(xiàn)實(shí)驗(yàn)的時(shí)候不會(huì)出現(xiàn)數(shù)據(jù)對(duì)不上的問(wèn)題。注意原始數(shù)據(jù)永遠(yuǎn)不要覆蓋。我見(jiàn)過(guò)團(tuán)隊(duì)為了省存儲(chǔ)空間清洗后直接覆蓋原始數(shù)據(jù)結(jié)果后來(lái)發(fā)現(xiàn)清洗邏輯有bug想回滾都回不去。3.2 特征層離線在線一致性是生命線特征層的核心挑戰(zhàn)就是離線特征和在線特征的一致性。離線訓(xùn)練時(shí)你用Spark算特征在線服務(wù)時(shí)你用Redis查特征兩邊如果對(duì)不上模型效果直接崩盤(pán)。我的解決方案是特征定義用同一份配置離線在線各自實(shí)現(xiàn)但用同一套測(cè)試用例驗(yàn)證。具體來(lái)說(shuō)我會(huì)定義一個(gè)特征配置文件比如features.yamlfeatures: user_avg_order_value: type: float source: orders computation: mean(amount) over last 30 days user_order_count_7d: type: int source: orders computation: count(*) over last 7 days離線側(cè)用Spark讀取這個(gè)配置生成特征計(jì)算任務(wù)在線側(cè)用Python讀取同一個(gè)配置生成Redis查詢(xún)邏輯。然后寫(xiě)一套測(cè)試用例用同一批模擬數(shù)據(jù)分別跑離線和在線對(duì)比結(jié)果是否一致。這套機(jī)制聽(tīng)起來(lái)有點(diǎn)重但它是保證特征一致性的唯一可靠辦法。我試過(guò)靠人工review來(lái)保證一致性結(jié)果每次發(fā)版都提心吊膽后來(lái)還是老老實(shí)實(shí)上了自動(dòng)化測(cè)試。3.3 訓(xùn)練層實(shí)驗(yàn)管理不是可選項(xiàng)是必選項(xiàng)訓(xùn)練層最容易失控的地方就是實(shí)驗(yàn)管理。今天調(diào)個(gè)學(xué)習(xí)率明天換個(gè)網(wǎng)絡(luò)結(jié)構(gòu)如果沒(méi)有系統(tǒng)化的實(shí)驗(yàn)管理兩周后你根本記不清哪個(gè)模型對(duì)應(yīng)哪組參數(shù)。MLflow是我用得最順手的實(shí)驗(yàn)管理工具。每次訓(xùn)練自動(dòng)記錄參數(shù)、指標(biāo)、模型文件還可以把模型注冊(cè)到Model Registry里標(biāo)記哪個(gè)版本可以上線。一個(gè)典型的訓(xùn)練腳本大概長(zhǎng)這樣import mlflow import mlflow.pytorch with mlflow.start_run(): mlflow.log_params({lr: 0.001, batch_size: 64, epochs: 10}) for epoch in range(10): train_loss train_one_epoch(model, train_loader) val_loss validate(model, val_loader) mlflow.log_metrics({train_loss: train_loss, val_loss: val_loss}, stepepoch) mlflow.pytorch.log_model(model, model)這樣每次訓(xùn)練完你都能在MLflow UI里看到完整的實(shí)驗(yàn)記錄。更重要的是模型注冊(cè)后服務(wù)層可以直接從Registry拉取指定版本的模型不需要手動(dòng)拷貝文件。實(shí)操心得實(shí)驗(yàn)命名一定要有規(guī)范。我習(xí)慣用{項(xiàng)目名}-{日期}-{改動(dòng)點(diǎn)}的格式比如recommend-20240115-add-user-features。這樣半年后回頭看還能快速定位到某次實(shí)驗(yàn)的上下文。3.4 服務(wù)層推理性能不是唯一指標(biāo)服務(wù)層這塊很多人一上來(lái)就盯著QPS和延遲。當(dāng)然這很重要但我想說(shuō)的是可觀測(cè)性比性能更重要。一個(gè)推理服務(wù)如果QPS很高但出了問(wèn)題時(shí)你完全不知道哪里出了錯(cuò)那這個(gè)服務(wù)就是不可維護(hù)的。我通常會(huì)在服務(wù)層加三類(lèi)監(jiān)控基礎(chǔ)監(jiān)控CPU、內(nèi)存、GPU利用率、請(qǐng)求量、延遲分布業(yè)務(wù)監(jiān)控輸入特征分布、輸出預(yù)測(cè)分布、異常輸入比例模型監(jiān)控預(yù)測(cè)置信度分布、特征缺失率、模型版本業(yè)務(wù)監(jiān)控和模型監(jiān)控是很多人會(huì)忽略的。舉個(gè)例子如果某天輸入特征的分布突然偏移了比如用戶(hù)年齡字段突然全是0模型預(yù)測(cè)結(jié)果肯定會(huì)出問(wèn)題。如果你只監(jiān)控了CPU和延遲根本發(fā)現(xiàn)不了這個(gè)問(wèn)題。我習(xí)慣用Prometheus加自定義指標(biāo)來(lái)實(shí)現(xiàn)這套監(jiān)控。比如在FastAPI里加一個(gè)中間件記錄每次請(qǐng)求的輸入特征統(tǒng)計(jì)信息from prometheus_client import Histogram feature_age_hist Histogram(feature_age, Distribution of user age) app.middleware(http) async def monitor_features(request, call_next): body await request.json() if age in body: feature_age_hist.observe(body[age]) response await call_next(request) return response這樣在Grafana里就能看到特征分布的變化趨勢(shì)一旦發(fā)現(xiàn)異?？梢约皶r(shí)告警。4. 實(shí)操落地從零搭建一個(gè)可運(yùn)行的AI工程原型4.1 環(huán)境準(zhǔn)備與項(xiàng)目結(jié)構(gòu)說(shuō)了這么多理論接下來(lái)我?guī)銖牧愦钜粋€(gè)可運(yùn)行的AI工程原型。這個(gè)原型包含數(shù)據(jù)清洗、特征計(jì)算、模型訓(xùn)練、模型服務(wù)、監(jiān)控五個(gè)環(huán)節(jié)代碼量不大但結(jié)構(gòu)完整。先看項(xiàng)目結(jié)構(gòu)ai-engineering-from-scratch/ ├── data/ │ ├── raw/ │ └── clean/ ├── features/ │ ├── features.yaml │ ├── offline.py │ └── online.py ├── training/ │ ├── train.py │ └── evaluate.py ├── serving/ │ ├── app.py │ └── monitor.py ├── tests/ │ └── test_feature_consistency.py ├── dvc.yaml └── requirements.txt這個(gè)結(jié)構(gòu)的關(guān)鍵在于features/目錄下的offline.py和online.py共用同一份features.yaml配置tests/目錄下的測(cè)試用例保證兩邊邏輯一致。環(huán)境準(zhǔn)備很簡(jiǎn)單Python 3.9以上裝幾個(gè)核心依賴(lài)pip install pandas scikit-learn fastapi uvicorn prometheus-client dvc mlflow4.2 數(shù)據(jù)清洗與特征計(jì)算假設(shè)我們的場(chǎng)景是用戶(hù)購(gòu)買(mǎi)行為預(yù)測(cè)原始數(shù)據(jù)是一份訂單記錄CSV。清洗邏輯很簡(jiǎn)單去掉金額為負(fù)的記錄填充缺失的用戶(hù)年齡。# clean.py import pandas as pd def clean_data(input_path, output_path): df pd.read_csv(input_path) df df[df[amount] 0] df[age] df[age].fillna(df[age].median()) df.to_csv(output_path, indexFalse) if __name__ __main__: clean_data(data/raw/orders.csv, data/clean/orders.csv)特征計(jì)算這塊離線用Pandas在線用Redis查詢(xún)但都讀取同一份features.yaml# features/offline.py import pandas as pd import yaml def compute_features(df, config_pathfeatures/features.yaml): with open(config_path) as f: config yaml.safe_load(f) features pd.DataFrame() features[user_avg_order_value] df.groupby(user_id)[amount].mean() features[user_order_count_7d] df.groupby(user_id)[amount].count() return features在線側(cè)的邏輯類(lèi)似只是數(shù)據(jù)源從DataFrame變成了Redis# features/online.py import redis import yaml r redis.Redis(hostlocalhost, port6379) def get_features(user_id, config_pathfeatures/features.yaml): with open(config_path) as f: config yaml.safe_load(f) features {} features[user_avg_order_value] float(r.get(fuser:{user_id}:avg_order_value) or 0) features[user_order_count_7d] int(r.get(fuser:{user_id}:order_count_7d) or 0) return features4.3 模型訓(xùn)練與評(píng)估訓(xùn)練腳本用MLflow記錄實(shí)驗(yàn)?zāi)Ｐ陀胹cikit-learn的隨機(jī)森林# training/train.py import mlflow import mlflow.sklearn import pandas as pd from sklearn.ensemble import RandomForestClassifier from sklearn.model_selection import train_test_split from sklearn.metrics import accuracy_score def train(): df pd.read_csv(data/clean/orders.csv) features pd.read_csv(data/clean/features.csv) X features y df[is_high_value] X_train, X_test, y_train, y_test train_test_split(X, y, test_size0.2) with mlflow.start_run(): model RandomForestClassifier(n_estimators100, max_depth5) model.fit(X_train, y_train) preds model.predict(X_test) acc accuracy_score(y_test, preds) mlflow.log_param(n_estimators, 100) mlflow.log_param(max_depth, 5) mlflow.log_metric(accuracy, acc) mlflow.sklearn.log_model(model, model) print(fAccuracy: {acc}) if __name__ __main__: train()評(píng)估這塊除了準(zhǔn)確率我還會(huì)看特征重要性和混淆矩陣。特征重要性可以幫你判斷模型是不是學(xué)到了合理的模式混淆矩陣可以幫你判斷模型在哪個(gè)類(lèi)別上表現(xiàn)差。4.4 模型服務(wù)與監(jiān)控服務(wù)層用FastAPI包一層加載MLflow注冊(cè)的模型# serving/app.py import mlflow.pyfunc from fastapi import FastAPI from features.online import get_features from prometheus_client import Histogram, make_asgi_app app FastAPI() model mlflow.pyfunc.load_model(models:/order_value_model/Production) prediction_hist Histogram(prediction_score, Distribution of prediction scores) app.post(/predict) def predict(user_id: str): features get_features(user_id) input_df pd.DataFrame([features]) score model.predict(input_df)[0] prediction_hist.observe(score) return {user_id: user_id, score: float(score)} app.mount(/metrics, make_asgi_app())監(jiān)控這塊除了Prometheus的基礎(chǔ)指標(biāo)我還加了一個(gè)預(yù)測(cè)分?jǐn)?shù)分布的直方圖。如果某天預(yù)測(cè)分?jǐn)?shù)突然集中到某個(gè)值說(shuō)明輸入特征可能出了問(wèn)題需要排查。4.5 特征一致性測(cè)試最后是特征一致性測(cè)試這是保證離線在線一致的關(guān)鍵# tests/test_feature_consistency.py import pandas as pd from features.offline import compute_features from features.online import get_features def test_feature_consistency(): df pd.DataFrame({ user_id: [u1, u1, u2], amount: [10.0, 20.0, 30.0] }) offline_features compute_features(df) # 模擬在線特征實(shí)際測(cè)試中需要先寫(xiě)入Redis online_features { u1: get_features(u1), u2: get_features(u2) } for user_id in offline_features.index: for feature_name in offline_features.columns: offline_val offline_features.loc[user_id, feature_name] online_val online_features[user_id][feature_name] assert abs(offline_val - online_val) 1e-6, \ fMismatch for {user_id}.{feature_name}: {offline_val} vs {online_val}這個(gè)測(cè)試跑通才能保證上線后模型效果和離線評(píng)估一致。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 模型上線后效果暴跌怎么排查這是最經(jīng)典的問(wèn)題。模型離線AUC 0.85上線后業(yè)務(wù)指標(biāo)反而下降。排查思路按以下順序來(lái)檢查特征一致性跑一遍特征一致性測(cè)試看離線在線特征是否對(duì)齊。這是最常見(jiàn)的原因占我遇到問(wèn)題的60%以上。檢查數(shù)據(jù)分布偏移對(duì)比訓(xùn)練數(shù)據(jù)和線上推理數(shù)據(jù)的特征分布。如果線上某個(gè)特征分布明顯偏移說(shuō)明訓(xùn)練數(shù)據(jù)不能代表線上場(chǎng)景。檢查標(biāo)簽定義有時(shí)候離線標(biāo)簽和業(yè)務(wù)指標(biāo)的定義不一致。比如離線用7天內(nèi)是否復(fù)購(gòu)作為標(biāo)簽但業(yè)務(wù)關(guān)心的是30天GMV兩者優(yōu)化目標(biāo)不同。檢查服務(wù)延遲如果推理延遲過(guò)高可能導(dǎo)致請(qǐng)求超時(shí)實(shí)際生效的請(qǐng)求比例很低。我整理了一個(gè)排查速查表現(xiàn)象可能原因排查方法離線指標(biāo)好線上指標(biāo)差特征不一致跑特征一致性測(cè)試線上指標(biāo)逐漸下降數(shù)據(jù)分布偏移對(duì)比特征分布線上指標(biāo)波動(dòng)大服務(wù)不穩(wěn)定檢查延遲和錯(cuò)誤率某些用戶(hù)效果特別差冷啟動(dòng)問(wèn)題分析新老用戶(hù)分組指標(biāo)5.2 特征計(jì)算太慢訓(xùn)練等不起怎么辦特征計(jì)算慢是另一個(gè)高頻問(wèn)題。我的優(yōu)化思路分三步第一步增量計(jì)算。不要每次全量重算只計(jì)算新增數(shù)據(jù)對(duì)應(yīng)的特征。比如用戶(hù)過(guò)去30天訂單數(shù)只需要在昨天的基礎(chǔ)上加上今天的新訂單減去30天前的舊訂單。第二步并行化。用Spark或者Dask把特征計(jì)算并行化按用戶(hù)ID分片。這一步通常能帶來(lái)10倍以上的加速。第三步預(yù)計(jì)算。把常用的特征提前算好存到Redis或者特征存儲(chǔ)里訓(xùn)練時(shí)直接讀取。代價(jià)是存儲(chǔ)成本增加但訓(xùn)練速度會(huì)快很多。實(shí)操心得特征計(jì)算優(yōu)化不要一步到位。先跑通全量計(jì)算確認(rèn)邏輯正確再做增量化和并行化。我見(jiàn)過(guò)團(tuán)隊(duì)一上來(lái)就搞增量計(jì)算結(jié)果邏輯寫(xiě)錯(cuò)了排查了兩周才發(fā)現(xiàn)。5.3 模型版本管理混亂怎么治理模型版本管理混亂的典型表現(xiàn)是線上跑的是哪個(gè)模型沒(méi)人知道回滾的時(shí)候找不到上一個(gè)版本。治理方案很簡(jiǎn)單所有模型必須通過(guò)Model Registry管理禁止手動(dòng)拷貝模型文件。MLflow的Model Registry可以給模型打標(biāo)簽比如Staging、Production、Archived。服務(wù)層加載模型時(shí)只認(rèn)Production標(biāo)簽不認(rèn)具體版本號(hào)。這樣回滾的時(shí)候只需要把上一個(gè)版本重新標(biāo)記為Production服務(wù)層自動(dòng)加載新版本。from mlflow.tracking import MlflowClient client MlflowClient() client.transition_model_version_stage( nameorder_value_model, version3, stageProduction )這套機(jī)制配合CI/CD可以實(shí)現(xiàn)模型的自動(dòng)化發(fā)布和回滾。5.4 監(jiān)控告警太多怎么降噪監(jiān)控告警太多最后大家都不看了這是監(jiān)控體系失效的開(kāi)始。降噪的核心思路是只對(duì)可行動(dòng)的問(wèn)題告警。什么叫可行動(dòng)就是收到告警的人知道該做什么。比如CPU利用率超過(guò)90%是可行動(dòng)的因?yàn)榭梢詳U(kuò)容但某個(gè)特征均值偏移了0.1%就不可行動(dòng)因?yàn)椴恢酪灰幚?。我的做法是分兩?jí)告警P0告警服務(wù)不可用、錯(cuò)誤率超過(guò)閾值、延遲超過(guò)閾值。這類(lèi)告警直接打電話(huà)。P1告警特征分布偏移、預(yù)測(cè)分?jǐn)?shù)異常、模型版本不一致。這類(lèi)告警發(fā)到群里工作時(shí)間處理。P1告警的閾值不要設(shè)得太敏感否則每天幾十條告警大家很快就麻木了。我通常會(huì)用過(guò)去7天的數(shù)據(jù)計(jì)算一個(gè)基線只有偏移超過(guò)3個(gè)標(biāo)準(zhǔn)差才告警。6. 一些踩坑之后的個(gè)人體會(huì)從零搭建AI工程體系這件事我最大的體會(huì)是工程能力比算法能力更稀缺。我見(jiàn)過(guò)太多算法很強(qiáng)的團(tuán)隊(duì)模型指標(biāo)刷得很高但工程體系一塌糊涂上線就崩。也見(jiàn)過(guò)算法一般但工程扎實(shí)的團(tuán)隊(duì)模型效果雖然不是頂尖但系統(tǒng)穩(wěn)定可靠業(yè)務(wù)價(jià)值反而更大。如果你正在從零搭建AI工程體系我的建議是先把數(shù)據(jù)層和特征層做扎實(shí)這兩層是地基。模型層和服務(wù)層可以先用最簡(jiǎn)單的方案跑通后面再逐步優(yōu)化。不要一上來(lái)就追求大而全的架構(gòu)那樣很容易陷入架構(gòu)很漂亮但跑不起來(lái)的困境。另外測(cè)試和監(jiān)控一定要從第一天就加上。我試過(guò)先跑通再補(bǔ)測(cè)試結(jié)果補(bǔ)測(cè)試的時(shí)候發(fā)現(xiàn)一堆隱藏問(wèn)題改起來(lái)比從頭寫(xiě)還麻煩。特征一致性測(cè)試、模型版本管理、基礎(chǔ)監(jiān)控這三樣是底線不能省。最后分享一個(gè)我常用的檢查清單每次上線新模型前過(guò)一遍特征一致性測(cè)試是否通過(guò)模型是否注冊(cè)到Model Registry并標(biāo)記為Production服務(wù)層是否加載了正確的模型版本基礎(chǔ)監(jiān)控和業(yè)務(wù)監(jiān)控是否覆蓋回滾方案是否準(zhǔn)備好這個(gè)清單不長(zhǎng)但能擋住80%的上線事故。