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