作為從業(yè)者我經(jīng)常被問到同一個問題AI到底怎么從零落地不只是跑通一個開源模型而是從環(huán)境、數(shù)據(jù)、訓(xùn)練、部署到維護(hù)走完一個完整的工程閉環(huán)。這個叫ai-engineering-from-scratch的項目乍看像一份學(xué)習(xí)清單實際上它本質(zhì)上是把AI工程實踐的可復(fù)制路徑完整梳理了一遍。我當(dāng)初看到這個標(biāo)題就來了興趣因為業(yè)內(nèi)最缺的恰恰是這種從零到一的系統(tǒng)性拆解而不是東拼西湊的代碼片段。這篇博文我就圍繞這個主題把我實際落地AI工程時積累的思路、步驟和那些坑原原本本寫出來。1. 到底什么是AI工程先搞懂從零開始的邊界很多人一說AI工程第一反應(yīng)就是訓(xùn)練模型。這個理解說對了一半但恰恰是最容易誤導(dǎo)人的那一半。真正把AI系統(tǒng)落地到生產(chǎn)環(huán)境的人都知道模型訓(xùn)練在整個工程鏈路里只占一小塊真正的復(fù)雜度分布在數(shù)據(jù)治理、實驗管理、部署上線、監(jiān)控迭代這些臟活累活上。我在接觸ai-engineering-from-scratch這類實踐項目時最深的一點體會就是從零開始指的絕不是從零寫網(wǎng)絡(luò)結(jié)構(gòu)而是從零搭建一條能持續(xù)產(chǎn)出、評估、交付模型的能力流水線。1.1 別把AI工程等同于訓(xùn)練模型AI工程是一個系統(tǒng)邊界極其模糊的領(lǐng)域它的核心難點在于橫跨了軟件工程、數(shù)據(jù)工程、MLOps和業(yè)務(wù)邏輯四塊知識體系。我見過不少團(tuán)隊模型在Notebook里跑得很漂亮一上生產(chǎn)就崩原因不是模型本身問題而是周圍的工程腳手架沒搭起來。舉個例子你在Jupyter里做完數(shù)據(jù)清洗下一步要進(jìn)入模型訓(xùn)練是不是經(jīng)常發(fā)現(xiàn)環(huán)境依賴沖突今天裝了這個庫明天更新了那個庫結(jié)果半年后復(fù)現(xiàn)不了實驗。這不是你技術(shù)不行而是缺少工程化的約束。AI工程里環(huán)境一致性、數(shù)據(jù)版本化、實驗可復(fù)現(xiàn)這三件事優(yōu)先級永遠(yuǎn)排在模型結(jié)構(gòu)之上。解決不了這三個問題即使你把Loss調(diào)得再低交付的時候一樣寸步難行。1.2 這套工程棧的整體架構(gòu)長什么樣我自己落地AI項目時習(xí)慣把整條鏈路拆成六個環(huán)節(jié)基礎(chǔ)設(shè)施、數(shù)據(jù)、訓(xùn)練、評估、部署、監(jiān)控。它們的關(guān)系不是線性的而是循環(huán)迭代?；A(chǔ)設(shè)施環(huán)境管理、依賴鎖定、容器化封裝數(shù)據(jù)層采集、清洗、標(biāo)注、特征工程、版本管理訓(xùn)練層基線模型、超參調(diào)優(yōu)、實驗追蹤評估層離線指標(biāo)、線上反饋、人工評測部署層推理服務(wù)、網(wǎng)關(guān)路由、資源調(diào)度監(jiān)控層數(shù)據(jù)漂移、效果衰退、自動告警我說過很多次的一句話是模型只占20%剩下的80%全是工程。這80%恰恰就是ai-engineering-from-scratch這個主題想要表達(dá)的核心價值——把隱性知識顯性化把零散的實踐變成系統(tǒng)路徑。不管你是做NLP、CV還是推薦系統(tǒng)外層任務(wù)會變底層骨架幾乎是一樣的。2. 環(huán)境準(zhǔn)備與基礎(chǔ)設(shè)施先把地基打牢環(huán)境問題是我見過勸退新手最多的一個環(huán)節(jié)。同樣是Python版本不同行為就不一樣同樣是PyTorchCUDA版本不對直接報錯。這些跟模型能力無關(guān)的問題耗費的精力往往比調(diào)參還多。所以從零開始搞AI工程第一課不是Transformer而是怎么把環(huán)境管明白。2.1 Python環(huán)境與依賴管理我先說Python版本。不要用系統(tǒng)自帶的Python更不要直接在全局環(huán)境里pip install這是新手最容易踩的坑。我建議直接用uv或者poetry這類工具來管理虛擬環(huán)境原因有三個環(huán)境隔離不同項目互不干擾依賴鎖定避免在我機器上是好的這類問題安裝速度快尤其是uv比pip快一個量級拿我自己常用的配置舉例。假設(shè)今天要新建一個項目我一般會做這么幾件事uv venv .venv --python 3.10 source .venv/bin/activate uv add torch --index-url https://download.pytorch.org/whl/cu118 uv add transformers datasets evaluate fastapi uvicorn這段配置里有幾個細(xì)節(jié)值得說。第一Python我固定用3.10不是越新越好很多深度學(xué)習(xí)庫對3.11、3.12的兼容性在當(dāng)時還不穩(wěn)定第二PyTorch要單獨指定CUDA版本的index否則默認(rèn)裝的是CPU版本你根本用不了GPU第三把FastAPI和uvicorn提前加進(jìn)來是提醒你自己模型最終是要部署的別等訓(xùn)練完了再手忙腳亂補服務(wù)。環(huán)境的復(fù)現(xiàn)性還體現(xiàn)在依賴鎖定上。poetry和uv都會生成一個lock文件團(tuán)隊協(xié)作時大家用同一個lock文件構(gòu)建出來的環(huán)境是一致的。我見過太多因為requirements.txt里寫的是范圍版本比如numpy1.21而導(dǎo)致的依賴沖突最后排查到崩潰。用鎖文件一次解決。2.2 用Docker封裝可復(fù)現(xiàn)的實驗環(huán)境虛擬環(huán)境解決了單機上的隔離問題但換一臺機器、換一個云服務(wù)器環(huán)境還是可能不一致。這時候就得上Docker。我在中后期項目的每一個實驗都會打一個鏡像好處是顯而易見的換機器、換GPU、換機房鏡像拉下來就能跑不會出現(xiàn)A機器能跑B機器跑不了的事。一個典型的AI訓(xùn)練鏡像我的Dockerfile大致長這樣FROM pytorch/pytorch:2.1.0-cuda11.8-cudnn8-runtime WORKDIR /workspace COPY requirements-lock.txt . RUN pip install --no-cache-dir -r requirements-lock.txt COPY src/ ./src/ COPY configs/ ./configs/ ENV PYTHONPATH/workspace ENV NVIDIA_VISIBLE_DEVICESall CMD [python, src/train.py, --config, configs/baseline.yaml]這里有一個我踩過很多次的坑默認(rèn)的pytorch/pytorch鏡像不是完整的跑訓(xùn)練環(huán)境很多常用庫比如scikit-learn、pandas、tensorboard都不在里面必須在裝完基礎(chǔ)鏡像后重新補裝。所以我會單獨維護(hù)一個requirements-lock.tx我們文件平時開發(fā)環(huán)境和訓(xùn)練鏡像都用它確保兩個環(huán)境高度一致。GPU的容器化還有一步要特別注意宿主機上必須安裝好NVIDIA Container Toolkit并且在docker run的時候帶上--gpus參數(shù)否則容器內(nèi)根本訪問不到GPU。我曾經(jīng)因為忘了裝toolkit在容器里用了CPU訓(xùn)練一個三個小時才能跑完的實驗浪費了整整一個下午。這種低級失誤經(jīng)歷一次就長記性了。3. 數(shù)據(jù)工程模型的糧食決定天花板模型再強也是吃數(shù)據(jù)長大的。我一直覺得數(shù)據(jù)質(zhì)量差的場景里你用再大的模型也白搭數(shù)據(jù)質(zhì)量到位一個相對小的模型就能出很好的效果。ai-engineering-from-scratch這種項目如果沒有單獨強調(diào)數(shù)據(jù)工程那一定是不完整的。3.1 數(shù)據(jù)收集與清洗流程數(shù)據(jù)清洗不是簡單drop掉空值。不同任務(wù)、不同模態(tài)的數(shù)據(jù)臟數(shù)據(jù)的表現(xiàn)完全不一樣。比方說做文本分類你要處理的可能是爬蟲抓下來的網(wǎng)頁正文里面混著導(dǎo)航欄、版權(quán)聲明、各種廣告文本做圖像任務(wù)要處理的是標(biāo)注錯位的框、模糊過曝的圖、重復(fù)樣本。我總結(jié)了一套比較通用的清洗流程基本能覆蓋90%的場景def clean_text(text: str) - str: # 1. 去掉HTML標(biāo)簽和亂碼 text re.sub(r[^], , text) # 2. 壓縮連續(xù)空白 text re.sub(r\s, , text).strip() # 3. 去掉過長無意義的重復(fù)內(nèi)容 if len(text) 10 or text.count(text[:20]) 5: return # 4. 去除非目標(biāo)語言字符按需調(diào) text re.sub(r[^\u4e00-\u9fa5a-zA-Z0-9?！丁贰尽?、\s], , text) return text這個簡單的清洗函數(shù)解決了我好幾個項目里的共性問題。值得注意的是不同任務(wù)的清洗強度完全不同。做對話系統(tǒng)的數(shù)據(jù)你要保留口語化特征不能把嗯嗯這種詞全刪掉做輿情分析表情符號可能本身是重要信號。所以清洗不是一勞永逸的事每個項目都需要單獨審視。3.2 特征工程與數(shù)據(jù)增強傳統(tǒng)機器學(xué)習(xí)時代特征工程是決定模型上限的關(guān)鍵深度學(xué)習(xí)以后很多人覺得特征工程沒用了這是另一個誤區(qū)。經(jīng)驗告訴我特征層面的先驗知識依然是效率最高的信息注入方式。比如做時間序列預(yù)測你把星期幾、是否節(jié)假日、過去一周均值這些特征拼進(jìn)去模型立刻就從魔怔擬合變得有業(yè)務(wù)sense了。數(shù)據(jù)增強這塊文本和圖像的路數(shù)完全不一樣。圖像可以用flip、rotation、cutout文本這邊常用的是回譯、同義詞替換、對抗噪聲注入。拿回譯舉例中文翻譯成英文再翻譯回中文表達(dá)方式就會發(fā)生變化數(shù)據(jù)量一下子就多了。但要小心一點回譯對口語化數(shù)據(jù)比較友好對專業(yè)術(shù)語多的數(shù)據(jù)效果很差術(shù)語可能被改得面目全非。3.3 數(shù)據(jù)版本管理全文我特別想強調(diào)的一點就是數(shù)據(jù)版本管理。代碼有Git管實驗有MLflow管數(shù)據(jù)要是沒有版本管理整個流水線的可復(fù)現(xiàn)性就是空談。很多團(tuán)隊數(shù)據(jù)集都是放在服務(wù)器某個文件夾里誰都不許動這其實是很原始的方案。我自己用DVCData Version Control來管數(shù)據(jù)集思路和Git一致但它是針對大文件設(shè)計的底層存儲可以對接S3、OSS、NAS這些地方。一個典型的流程是dvc init dvc remote add -d myremote s3://mybucket/dvc-store dvc add data/raw dvc push這樣每個實驗、每次訓(xùn)練用的數(shù)據(jù)是哪個版本都能在DVC的記錄里追溯到。之前出過一件事某團(tuán)隊訓(xùn)練數(shù)據(jù)被人手動替換了幾個文件模型效果莫名下降但沒人敢確定是哪天被改的。用DVC之后再也不會出現(xiàn)這種憑感覺猜版本的問題。4. 模型訓(xùn)練與迭代從基線到可用數(shù)據(jù)和環(huán)境都準(zhǔn)備好了才輪到真正的模型訓(xùn)練環(huán)節(jié)。這個環(huán)節(jié)我聊的不是某個網(wǎng)絡(luò)結(jié)構(gòu)有多精妙而是圍繞訓(xùn)練這件事本身的工程化操作怎么把實驗管起來怎么從一團(tuán)亂麻里找到有效的方向。4.1 選型策略選模型這件事我的建議是梯度式起步不要一開始就上最復(fù)雜的結(jié)構(gòu)。想做文本分類先跑個簡單的FastText或者TextCNN想做目標(biāo)檢測先用現(xiàn)成的YOLO預(yù)訓(xùn)練模型做遷移。用我自己的話說就是先用笨辦法把數(shù)據(jù)管線和評估流程跑通再逐步升級模型結(jié)構(gòu)檢驗天花板到底在哪。這種策略的好處太多了。一方面簡單模型的調(diào)試成本低出問題容易排查適合磨合數(shù)據(jù)管線另一方面它給你提供了一個扎實的基線后面換復(fù)雜模型時提升幅度是不是真的有用一眼就能對比出來。反過來一上來就跑大模型數(shù)據(jù)有小毛病你根本發(fā)現(xiàn)不了最后還會誤以為是模型不行。4.2 訓(xùn)練參數(shù)與實驗追蹤訓(xùn)練參數(shù)這塊我最常被問到一個問題學(xué)習(xí)率到底設(shè)多少合適我的回答是先看訓(xùn)練曲線再說。業(yè)界通用的做法是用學(xué)習(xí)率預(yù)熱加余弦退火初始值盡量偏小比如1e-5到1e-4這個區(qū)間起步讓模型穩(wěn)定訓(xùn)練幾個epoch之后再根據(jù)loss曲線調(diào)整。一個標(biāo)準(zhǔn)的訓(xùn)練步長配置我長期用下面這套o(hù)ptimizer: adamw learning_rate: 3e-5 warmup_ratio: 0.1 weight_decay: 0.01 batch_size: 32 gradient_accumulation_steps: 4 max_epochs: 5batch_size和gradient_accumulation_steps這兩個參數(shù)要連起來看。如果你的GPU顯存不夠一個batch只能塞8條數(shù)據(jù)那就通過梯度累積模擬更大的batch效果上接近32條真實數(shù)據(jù)但代價是訓(xùn)練時間會增加。這套東西的工程本質(zhì)就是用時間換顯存在資源受限的情況下把實驗跑起來。實驗追蹤方面我不用手寫日志文件而是直接上MLflow或者WandB。每一步迭代的loss、評測指標(biāo)、超參數(shù)、模型產(chǎn)物都能自動記錄后面要做橫向?qū)Ρ纫粋€頁面就全看完了。有人覺得記錄這些是浪費時間真到月底寫報告或者復(fù)現(xiàn)舊模型的時候你就知道一個規(guī)范化的實驗記錄能救多少命。4.3 評估與調(diào)優(yōu)閉環(huán)離線指標(biāo)不能光看單一值。分類任務(wù)不能只看Accuracy樣本不均衡的時候Accuracy會騙人要同時看Precision、Recall和F1。我建議你在訓(xùn)練腳本里就把這些指標(biāo)全部計算出來用一個統(tǒng)一的評估函數(shù)輸出而不是等訓(xùn)練結(jié)束再臨時寫腳本算。評估之后是調(diào)優(yōu)循環(huán)這里的關(guān)鍵在于每次只改一個變量。我先固定數(shù)據(jù)、模型結(jié)構(gòu)只動學(xué)習(xí)率和訓(xùn)練輪次有了相對好的結(jié)果再微調(diào)Batch size和權(quán)重衰減。一次動兩個以上的變量出了問題你根本不知道是哪個參數(shù)導(dǎo)致的。調(diào)優(yōu)過程中還要建立一套什么時候停的機制。我最常用的策略是Early Stopping監(jiān)控驗證集loss連續(xù)三個epoch不降就提前終止訓(xùn)練省時間也省算力。但有一點要注意早停的判定指標(biāo)要和最終目標(biāo)一致比如你做推薦系統(tǒng)最終看線上點擊率那就不要只看loss要結(jié)合驗證集的業(yè)務(wù)指標(biāo)來定。5. 部署上線與服務(wù)化讓模型真正跑起來模型訓(xùn)練得再好不部署上線就是紙上談兵。這一節(jié)應(yīng)該是ai-engineering-from-scratch里最有工程味的一部分也是我踩坑最多、收獲最大的環(huán)節(jié)。5.1 用FastAPI封裝推理服務(wù)模型部署最常見的形態(tài)是HTTP推理服務(wù)。我用FastAPI做過好幾個生產(chǎn)級的服務(wù)穩(wěn)定性和性能都很對得起它的口碑。一個標(biāo)準(zhǔn)的推理服務(wù)我通常分成這樣幾層from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class InferenceRequest(BaseModel): texts: list[str] class InferenceResponse(BaseModel): predictions: list[str] model None app.on_event(startup) def load_model(): global model model load_model_from_disk(models/best_model.pt) app.post(/predict, response_modelInferenceResponse) def predict(req: InferenceRequest): try: preds model.predict(req.texts) return InferenceResponse(predictionspreds) except Exception as e: raise HTTPException(status_code500, detailstr(e))這個代碼看起來簡單但里面有一個很多新手忽略的細(xì)節(jié)模型加載必須在startup階段完成不能在請求函數(shù)里加載。不然第一個請求進(jìn)來卡個幾十秒后面每個請求還得搶模型加載的鎖整個服務(wù)直接癱瘓。服務(wù)上線之后還要考慮并行和批量推理。GPU推理和CPU推理的資源模型完全不一樣CPU適合低并發(fā)、低延遲的請求GPU適合高吞吐、大批量的場景。我一般會設(shè)置一個max_batch_size參數(shù)把請求攢夠一定數(shù)量再一次性進(jìn)模型推理吞吐量能提升好幾倍。5.2 性能優(yōu)化與監(jiān)控部署層面的優(yōu)化手段有很多。首先是最簡單也最剛需的把推理過程轉(zhuǎn)成TensorRT或者ONNX格式。不要小看這一步我遇到過FP16量化后速度和精度雙豐收的情況。轉(zhuǎn)換的時候要仔細(xì)檢查算子的兼容性不是所有PyTorch算子都能轉(zhuǎn)成功。然后要加緩存。對于文本分類這類高頻重復(fù)的請求用Redis做一層精確匹配的緩存命中率如果達(dá)到30%整體QPS壓力能下降不少。我習(xí)慣在業(yè)務(wù)層面的分類模型前加一個文本哈希緩存成本極低收益肉眼可見。監(jiān)控是最后一個維度。除了常規(guī)的CPU、內(nèi)存、GPU顯存監(jiān)控還要特別關(guān)注數(shù)據(jù)漂移的問題。線上請求的文本長度分布、關(guān)鍵詞分布如果和訓(xùn)練集差異過大模型表現(xiàn)一定會衰退。我給線上服務(wù)專門配了一個特征分布日志每天自動算一遍KL散度一旦超過閾值就觸發(fā)告警。這個機制為我至少提前暴露過三次模型效果下滑的風(fēng)險。6. 常見問題排查實錄最后這部分我把實操中反復(fù)踩過的坑匯總一下做成一份問題速查表方便遇到問題時直接對照參考。很多問題看起來稀奇古怪但背后的原因其實就那么幾類。6.1 高頻問題速查表問題現(xiàn)象大概率原因解決辦法跑模型時CUDA out of memoryGPU顯存不足減小batch_size或增加gradient_accumulation_steps本地正常、容器里報缺庫環(huán)境不一致統(tǒng)一用鎖定依賴的鏡像不用裸pip安裝不同GPU上結(jié)果不一致CUDA版本或cuDNN不一致固定鏡像和CUDA版本使用確定性算法數(shù)據(jù)加載慢GPU利用率低DataLoader并行度不足調(diào)大num_workers開啟pin_memory模型線上效果比離線差太多數(shù)據(jù)漂移或特征不一致對比線上特征分布與訓(xùn)練集分布加漂移告警Early Stopping過早停止驗證集loss波動大增大patience或改用EMA平滑后的指標(biāo)FastAPI并發(fā)請求速度下降明顯模型加載邏輯錯誤或沒有批量推理把模型加載移到startup加批量推理邏輯模型推理延遲高算子沒有優(yōu)化轉(zhuǎn)ONNX或TensorRT開啟FP166.2 排查思路與快捷命令遇到問題不要慌先確定在哪個環(huán)節(jié)出了問題。我有一套固定的排查順序數(shù)據(jù)環(huán)節(jié)、環(huán)境環(huán)節(jié)、代碼環(huán)節(jié)、資源環(huán)節(jié)。先用最簡單的方式排除資源瓶頸再看環(huán)境一致性最后才懷疑模型結(jié)構(gòu)。幾個我常用的排查命令# 檢查GPU是否正常工作 nvidia-smi # 檢查容器內(nèi)能否訪問GPU docker run --gpus all nvidia/cuda:11.8-base nvidia-smi # 檢查Python依賴的版本沖突 pip check # 查看訓(xùn)練日志里有沒有隱式錯誤 tail -f nohup.out | grep ERROR一個特別想分享的技巧訓(xùn)練中遇到loss變成NaN別急著調(diào)學(xué)習(xí)率先看數(shù)據(jù)里有沒有NaN值或者無窮大值。我在金融數(shù)據(jù)處理時遇到過一位同事數(shù)據(jù)里有幾個無窮大的樣本整個embedding層直接崩了查了兩天才定位到原因就是數(shù)據(jù)處理階段少了一個clip操作。先查數(shù)據(jù)再查代碼最后查超參這個順序能幫你節(jié)省大量時間。關(guān)于早期的實踐我最后多說一句從零開始做AI工程不要迷信大模型和復(fù)雜結(jié)構(gòu)先扎扎實實把數(shù)據(jù)、環(huán)境、評估、部署這條鏈路走通一遍哪怕做的是一個很簡單的任務(wù)。鏈條通了的價值遠(yuǎn)大于某個模型刷到一個漂亮分?jǐn)?shù)。我自己回頭看最痛苦、成長最快的階段正是當(dāng)時把這條鏈路從無到有搭起來的那段日子。希望這篇基于ai-engineering-from-scratch的梳理能幫你少走一些我走過的彎路。