我一直覺得把“ai-engineering-from-scratch”當成一個進階學習的路線圖比把它當成一個具體項目要更準確。因為真正從零開始做AI工程不是一個“跑通一個模型就算完事”的過程而是一整套關于數(shù)據(jù)、實驗、訓練、評估、部署、監(jiān)控的工程打磨。你可以把它理解為AI把模型做出來只算完成一半另一半是把模型變成一個穩(wěn)定、可維護、能持續(xù)迭代的系統(tǒng)。這篇內容適合兩類人。第一類是想入行AI工程、但手上只有零散代碼經(jīng)驗的人你需要知道該按什么順序建立能力。第二類是已經(jīng)在公司里接觸過模型開發(fā)但發(fā)現(xiàn)項目經(jīng)?？ㄔ凇澳Ｐ托Ч梢粤说緵]法上線”這一步的人你需要突破的點其實就在工程化鏈路里。1. 先想清楚AI工程和AI科研是兩回事1.1 到底什么是AI工程很多人第一次接觸“AI Engineering”這個詞時會把它想象成“調模型、刷精度”的技術活。我一開始也是這樣總以為把準確率從90%刷到95%就是工程能力的體現(xiàn)。真到項目里才發(fā)現(xiàn)AI工程的定義比這寬得多。把一個AI系統(tǒng)穩(wěn)定地跑在真實環(huán)境里讓它經(jīng)受住不同數(shù)據(jù)分布、不同時段流量、不同用戶行為的考驗這件事占掉了AI工程至少70%的精力。AI科研關心的是“這個方法是否有效”AI工程關心的是“這個系統(tǒng)是否可靠”。有效和可靠之間的差距就是工程化的工作量。舉個生活化的例子?？蒲邢袷窃趯嶒炇依镒鲆坏啦酥灰兜篮?、有理可依就行。工程像是開餐館要考慮出菜速度、食材供應、成本控制、廚師離職后配方還能不能復現(xiàn)、高峰期會不會出餐混亂。同樣是做菜目標完全不同。所以我們講AI工程第一件事就是把思維方式從“論文復現(xiàn)”切到“系統(tǒng)交付”。你在一個實際項目里至少要用工程視角同時處理五個問題數(shù)據(jù)基礎是否扎實、訓練流程是否可復現(xiàn)、評估指標是否反映業(yè)務目標、模型服務是否夠快夠穩(wěn)、線上反饋是否能閉環(huán)回到模型迭代。任何一個環(huán)節(jié)斷了模型的“好效果”都落不了地。1.2 從零開始的人最容易掉進的三個坑我見過很多人也包括當年的我自己都是從零開始做AI項目時踩坑。這些坑看起來是技術問題本質上是思路問題。第一個坑是“沒有指標就開始收集數(shù)據(jù)”。有的項目一開始只開會說要“做一個智能推薦”但推薦什么叫好是點擊率高還是用戶停留時間長沒人說清楚。最后數(shù)據(jù)收集了一堆訓練時才發(fā)現(xiàn)字段缺失、正負樣本定義模糊之前的活全白干。正確做法是先定義可量化的目標哪怕一開始粗糙一點也要把指標從“感覺好”變成“數(shù)字可度量”。第二個坑是“本地跑通了就直接部署”。本地一個小腳本能跑不代表生產環(huán)境能活。生產環(huán)境里要面對的是幾十倍甚至上百倍的請求量、不同的數(shù)據(jù)特征、網(wǎng)絡超時、資源限制。更麻煩的是本地模型的依賴環(huán)境往往沒固定下來換一臺機器就崩。這是典型的“實驗代碼”和“工程代碼”沒有區(qū)分開。第三個坑是“忽略baseline”。很多人拿到數(shù)據(jù)就直奔深度學習模型感覺不上一套復雜的神經(jīng)網(wǎng)絡就顯不出水平。但在工程里先做一個簡單的邏輯回歸或規(guī)則模型作為baseline能幫你快速判斷數(shù)據(jù)里有沒有信號、特征工程的方向對不對、數(shù)據(jù)量是否足夠。沒有baseline你連模型有沒有真正學習到模式都無法判斷更沒法跟復雜模型做對比。2. 環(huán)境搭建不是裝個Python就完事2.1 開發(fā)環(huán)境的最小可用配置從零開始做AI工程第一關是開發(fā)環(huán)境。這關看著簡單但環(huán)境問題能卡住你好幾天。Windows、Mac、Linux三套系統(tǒng)的處理方式完全不一樣GPU驅動、Python版本、包管理器之間的關系更是又細碎又重要。我的建議是先把基礎環(huán)境拆成三層來看。第一層是系統(tǒng)層包括操作系統(tǒng)和GPU驅動這一層決定了底層能力。第二層是Python解釋器和虛擬環(huán)境這一層與你的依賴包管理密切相關。第三層是AI框架和業(yè)務依賴比如PyTorch、TensorFlow、NumPy這些。很多環(huán)境問題出在層與層之間的版本匹配。裝Python時建議用conda或uv這類能同時管理Python版本和虛擬環(huán)境的工具不要直接往系統(tǒng)里塞一個全局Python。我在實際項目里用的環(huán)境創(chuàng)建命令大概是這樣的conda create -n ai-project python3.11 conda activate ai-project pip install \ torch2.3.0 \ torchvision0.18.0 \ --index-url https://download.pytorch.org/whl/cu121這套做法的關鍵是“純凈隔離”。每個項目都用自己的虛擬環(huán)境依賴版本互不污染。等踩過“A項目換依賴導致B項目跑不起來”的坑以后你就明白這不是多此一舉了。2.2 依賴管理是第一個工程化分水嶺環(huán)境能跑起來只是起點真正考驗工程化能力的是依賴管理。我見過不少團隊代碼放在Git里但依賴列表靠“誰記得就補一句”最后新同事clone代碼后根本跑不起來。依賴管理的核心目標是可復現(xiàn)。今天跑的代碼三個月后還能跑出一致的結果這才是工程化的基本要求。具體到操作上我建議至少做到三點。第一用鎖定版本的依賴清單。比如requirements.txt里直接寫死版本號或者更進一步用pyproject.toml加lock文件。為什么不用“1.0”這種寫法因為依賴庫里的小版本升級往往帶行為變化可能在某個陰間時刻給你埋雷。鎖版本能夠減少這種不確定性。第二把環(huán)境和代碼一起交付。最直接的手段是Docker。容器把系統(tǒng)依賴、Python依賴、代碼打包成鏡像任何人拿到鏡像都能在你的環(huán)境基礎上運行。在項目早期就引入Docker看起來慢實際上省掉了后面大量“在我機器上明明能跑”的扯皮時間。第三給實驗環(huán)境加固定種子。依賴管理管的是庫實驗可復現(xiàn)還需要固定隨機種子。深度學習訓練里數(shù)據(jù)shuffle、初始化、dropout都有隨機性。固定好numpy、python的random、torch的seed至少能讓實驗結果在大多數(shù)情況下可復現(xiàn)。2.3 數(shù)據(jù)與模型版本管理依賴和代碼都管理起來了還有一個經(jīng)常被忽略的東西數(shù)據(jù)。代碼可以用Git管但數(shù)據(jù)通常體積大、變更頻繁用Git反而會拖到崩潰。模型文件也一樣隨便用一個文件名加日期的方式存幾天之內就能把服務器磁盤塞滿還搞不清哪個版本對應哪次訓練。在實踐中適合普通團隊的做法是引入DVC這類數(shù)據(jù)版本管理工具或者退一步至少建立清晰的文件目錄和命名規(guī)范。datasets/ 2024-05-01_raw_v1/ 2024-05-08_raw_v2/ experiments/ 2024-05-01_lr_baseline/ 2024-05-03_bert_finetune/ models/ run_20240501_model.pt run_20240503_model.pt每個數(shù)據(jù)版本記錄下來源、清洗腳本、生成時間。每個實驗記錄下配置參數(shù)、訓練日志、評估結果。別小瞧這個階段的工作它決定著你出了問題之后能不能快速定位到是哪一版數(shù)據(jù)、哪一組參數(shù)導致的。我自己的經(jīng)驗是實驗記錄做得越細后面復盤越省力。這個教訓是我在連續(xù)跑廢三個實驗、卻找不到哪個參數(shù)變了之后才真正理解的。3. 數(shù)據(jù)工程大部分AI項目死在數(shù)據(jù)上3.1 數(shù)據(jù)采集與清洗的實戰(zhàn)要點數(shù)據(jù)是AI項目的燃料。我見過太多項目模型結構沒多大問題訓練也都正常最后效果不行一查根因還是數(shù)據(jù)出了岔子。從零開始做AI工程一定要在半路上專門騰出精力認真處理數(shù)據(jù)。采集數(shù)據(jù)的第一個原則是“先明確記錄元信息”。比如你采了一批商品評論不能只存評論文本還要存發(fā)布時間、用戶ID、評分字段、渠道來源。這些元信息以后做特征、做數(shù)據(jù)切分、做分布分析都用得上。我已經(jīng)數(shù)不清有多少次因為“當初沒存這個字段”不得不重新爬一份數(shù)據(jù)的經(jīng)歷。清洗環(huán)節(jié)最常用的是“按規(guī)則清洗人工抽檢”的組合。規(guī)則清洗包括去重、去除HTML標簽、編碼統(tǒng)一、異常值過濾。舉個例子處理文本數(shù)據(jù)時我一般會做完整去重之外還會做近似去重。文本里的表情符號、多余空格、全角半角差異都會導致同一句話被算成不同樣本。用哈希去重只能去掉完全一樣的用SimHash一類的方法可以去掉高度相似的重復內容。清洗之后要留一手不要把規(guī)則寫死。清洗腳本本身也要進Git清洗規(guī)則變更時要有記錄。因為清洗規(guī)則本質上是你對數(shù)據(jù)的理解和假設后面發(fā)現(xiàn)效果不對改的往往不是模型而是這些假設。3.2 標注質量如何把控有監(jiān)督學習繞不開標注。而標注質量往往決定了模型的上限。很多從零開始的項目把大量精力放在模型調參上卻對標注漏洞視而不見最后模型拼命擬合了錯誤答案還一臉懵。做標注質量把控重點不是“讓每個人標得都一樣”而是“讓不一樣的地方被暴露出來”。一種常見做法是同一條數(shù)據(jù)分配給至少兩個人標然后計算標注一致性。人工判斷一致性的簡單指標是Kappa系數(shù)核心邏輯是剔除掉“瞎蒙也能碰對”的部分看看兩個人真實一致率有多高。可以寫幾行Python模擬一下這個計算def kappa(observed_agreement, categories): p_o observed_agreement p_e sum([c * c for c in categories]) # 每種標簽占比的平方和 return (p_o - p_e) / (1 - p_e) if p_e ! 1 else 0這個值低于0.4說明標注標準不清晰至少要重新培訓和討論。Kappa算出來的數(shù)字不是用來供奉的而是用它判斷“哪個類別容易產生歧義”然后針對那個類別細化標注規(guī)范。還應當給標注環(huán)節(jié)設定期中抽檢。剛開始標100條就停下來隨機看幾條比全部標完再返工要劃算得多。質量問題的特點是發(fā)現(xiàn)越晚、修復成本越高這個規(guī)律在數(shù)據(jù)標注上體現(xiàn)得淋漓盡致。3.3 數(shù)據(jù)切分與數(shù)據(jù)泄露陷阱數(shù)據(jù)切分是機器學習里最容易被低估的一環(huán)。很多新手習慣用train_test_split直接隨機切一刀這在同分布獨立樣本上有道理但在真實項目中往往不成立。典型的場景是電商評論。同一條商品的評論可能被同一批用戶反復批評你隨機切分后訓練集和測試集里可能出現(xiàn)同一商品、甚至同一用戶的相似評論模型等于“已經(jīng)見過答案”。線上效果自然比驗證集效果差出一大截這不是玄學這就是數(shù)據(jù)泄露。解決這類問題有個原則按數(shù)據(jù)生成來源切分不要按行隨機切分。如果數(shù)據(jù)是按時間產生的就按時間前80%訓練、后20%驗證。如果數(shù)據(jù)按用戶匯聚就按用戶分桶切分確保同一個用戶的數(shù)據(jù)只出現(xiàn)在一個集合里。命名上可以直接叫“時間切分”或“用戶隔離切分”提醒自己這是經(jīng)過思考選擇的切分方式。數(shù)據(jù)泄露還有一種隱蔽形式是特征本身包含了未來信息。比如用當前時間點的訂單數(shù)據(jù)預測用戶是否會流失卻把“是否已經(jīng)流失”作為特征輸入進去了這是錯誤地用了未來的結果來預測未來。這類問題做數(shù)據(jù)審查的時候要多問一句這個特征在預測時刻真的可獲取嗎4. 模型訓練與評估從跑通到跑穩(wěn)4.1 基準模型與資源評估數(shù)據(jù)準備好之后自然進入模型訓練環(huán)節(jié)。但訓練的第一件事永遠不是直接上大模型。我在前面說過要對baseline認真對待這是有實際操作價值的。先訓練一個簡單模型比如邏輯回歸、線性回歸或者一個兩層的小MLP達到兩層目的。第一驗證整條數(shù)據(jù)鏈路是否通順——從數(shù)據(jù)讀取、特征轉換到損失計算、反向傳播跑通這一整套流程。第二提供一個效果下限參考后續(xù)如果復雜模型連這個底線都沒超過說明不是模型不夠復雜而是數(shù)據(jù)或特征出了問題。做基準模型的同時建議順手估算訓練資源。我自己習慣寫個粗略計算腳本把數(shù)據(jù)量、每epoch耗時、訓練總時長、顯存峰值都打印出來。這不單是為了看進度更是為了提前發(fā)現(xiàn)資源瓶頸。比如數(shù)據(jù)量從100萬漲到1000萬特征維度不變的情況下線性模型的內存和耗時增長是可預估的如果你發(fā)現(xiàn)腳本需要跑三天才能出結果那就應該及時優(yōu)化數(shù)據(jù)加載方式或調整batch size而不是傻等。這里給出一個開發(fā)階段的直接建議先只用數(shù)據(jù)的10%到20%做一次完整訓練確認loss能降、指標能動、時間可接受再放大到全量數(shù)據(jù)。我見過太多人一上來就用全量數(shù)據(jù)結果在浪費了十幾個小時后才發(fā)現(xiàn)不同的epoch之間loss完全不下降。小樣本試跑是幫你在“跑通”和“跑廢”之間建立一個安全緩沖。4.2 訓練過程的監(jiān)控指標訓練不是“命令一執(zhí)行等結果”這么簡單。一個合格的AI工程流程里訓練過程的實時監(jiān)控是必須的。至少要看四條曲線訓練集損失、驗證集損失、學習率變化、梯度范數(shù)。訓練集損失下降證明模型正在從數(shù)據(jù)里學到東西驗證集損失同步下降證明學到的東西有泛化能力驗證集損失開始回升而訓練集損失繼續(xù)下降這是過擬合的經(jīng)典信號。梯度范數(shù)過大說明優(yōu)化器可能積攢了爆炸性梯度過小說明訓練可能陷入停滯。四條曲線放在一起能讓很多問題一眼暴露。實際工程里我還會看每個epoch的耗時、數(shù)據(jù)加載耗時占比、GPU利用率。數(shù)據(jù)加載耗時太高光盯著訓練曲線是看不出到底瓶頸在哪里的。建議用psutil或nvidia-smi定時采集資源數(shù)據(jù)把訓練日志和系統(tǒng)指標匯總到一張表里觀察久了你就能夠憑經(jīng)驗判斷瓶頸是數(shù)據(jù)、顯存還是CPU。# 訓練過程中簡單記錄 import torch for epoch in range(epochs): train_loss 0.0 for batch in loader: optimizer.zero_grad() outputs model(batch) loss criterion(outputs, batch.label) loss.backward() grad_norm torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0) optimizer.step() train_loss loss.item() print(fepoch{epoch}, loss{train_loss:.4f}, grad_norm{grad_norm:.4f})這段代碼本身沒什么高深的但它表達了工程化監(jiān)控的內核不要只看最終精度要讓中間過程可見。4.3 評估不是只看accuracy訓練結束進入評估階段評估標準不能只掛著一個準確率。準確率在大部分真實場景里都不夠用因為它對類別不敏感。比如一個風控場景里99%的用戶都是正常用戶你只要全預測成正常準確率就有99%。但這個模型沒有任何用。實際項目里我建議根據(jù)業(yè)務目標設計一套評估矩陣。分類問題至少要看精確率、召回率、F1甚至要針對不同置信度切點畫出閾值-指標曲線。業(yè)務場景不同關注的重點不一樣反欺詐更看重召回因為漏掉一個壞賬損失巨大智能客服更看重精確率因為答錯比不答更讓用戶惱火。評估還要講究“與業(yè)務對應”。模型輸出的不是最終決策而是一個概率分。業(yè)務方完全可以根據(jù)這個分數(shù)自定義閾值。所以交付模型時除了給出最優(yōu)閾值最好給出精確率和召回率隨閾值變化的完整曲線。這能讓后續(xù)團隊根據(jù)風險偏好自行調整而不是硬編碼一個0.5的默認閾值。5. 交付部署與持續(xù)迭代AI工程的下半場5.1 模型部署的幾種方式模型部署是AI工程里最明顯的一道坎。很多人在離線環(huán)境里做得很順利一上線就手足無措。其實部署方案有固定套路關鍵是想清楚業(yè)務的實時性要求。如果業(yè)務允許離線計算比如生成日報、批量打標最簡單的方式是定時批處理腳本每天跑一次把結果寫入數(shù)據(jù)庫。這種方式對基礎設施要求最低成本也最容易控制。如果業(yè)務要求秒級響應比如在線推薦、實時風控那就需要把模型包裝成一個API服務。常見的做法是用FastAPI搭建服務加載模型后提供推理接口。部署時一定要把權重文件從代碼倉庫里拆出來模型文件放到對象存儲或專用模型倉庫服務啟動時動態(tài)拉取否則服務鏡像會又大又難管理。如果業(yè)務發(fā)生在手機或邊緣設備上還需要考慮模型量化、剪枝、轉成ONNX或CoreML這類格式。邊端部署是另一個大話題但從零開始可以先不碰只要知道它會帶來額外的優(yōu)化成本就行。from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class Item(BaseModel): text: str app.post(/predict) def predict(item: Item): inputs tokenizer(item.text, return_tensorspt) with torch.no_grad(): logits model(**inputs).logits return {score: float(logits.softmax(-1)[0, 1])}這個例子雖然簡單卻體現(xiàn)了一個關鍵原則模型服務和應用代碼要解耦。API層只負責把輸入變成輸出不摻入業(yè)務邏輯。業(yè)務判斷放在調用方這樣模型版本更新時不需要跟著改業(yè)務代碼。5.2 監(jiān)控、反饋與自動重訓部署上線不是終點是AI工程中后半段挑戰(zhàn)的開始。因為模型是基于歷史數(shù)據(jù)訓練的而真實世界的數(shù)據(jù)分布會隨時間改變。用戶行為會變、商品結構會變、季節(jié)會影響數(shù)據(jù)這些都會導致模型效果慢慢衰退。所以AI工程必須要有監(jiān)控。監(jiān)控分兩層系統(tǒng)監(jiān)控負責看API的延遲、錯誤率、吞吐量數(shù)據(jù)監(jiān)控負責看輸入特征的分布、預測結果的分布。系統(tǒng)監(jiān)控好理解就是服務器層面的可用性。數(shù)據(jù)監(jiān)控容易被忽略但它反映的是模型“適不適合當前環(huán)境”。一個直接的辦法是定期用新數(shù)據(jù)跑一遍模型預測看看預測結果的類別分布和訓練時期有沒有明顯偏移。如果你拿到的輸入特征普遍開始偏離訓練集范圍就說明該重新訓練了。反饋閉環(huán)是AI工程里最體現(xiàn)工程水平的地方。每一條線上預測如果后續(xù)得到了用戶的真實反饋最好都回流到日志系統(tǒng)形成“預測結果真實結果”的配對數(shù)據(jù)。累積一批之后用這些新數(shù)據(jù)增量訓練或重訓模型讓系統(tǒng)形成持續(xù)學習和迭代的能力。有了反饋閉環(huán)AI系統(tǒng)才不是一次性消費品而是一個可以在運營中不斷變好的產品。6. 從零到一一個可落地的推進順序與踩坑記錄6.1 一個具體的項目推進順序從零開始把AI工程落地我建議按固定順序走每一步都有明確的檢查點。很多項目失控是因為著急推進跳過了中間驗證步驟。第一步先定義業(yè)務目標和評估指標。比如“將客戶流失預警的召回率從現(xiàn)有規(guī)則模型的50%提升到70%”。這是業(yè)務級的定義。第二步盤點數(shù)據(jù)和資源。確認手上有什么數(shù)據(jù)、缺什么字段、標注樣本夠不夠、計算資源夠不夠。第三步做最小可行性驗證。用一小部分數(shù)據(jù)和最簡單模型跑通整個鏈路確認Pipeline沒有硬傷。第四步做baseline模型記錄效果。第五步迭代優(yōu)化引入更復雜的模型或更好的特征。第六步進入部署階段先以離線批處理或shadow mode跑一段時間讓模型先“陪伴”一段時間而不是直接替換業(yè)務。shadow mode的意思是模型同步進行預測但不影響真實決策這樣可以積累“模型預測與真實結果對照”的樣本安全地驗證模型可靠性。第七步正式上線并持續(xù)監(jiān)控。這個順序看起來不刺激卻是最穩(wěn)的。尤其shadow mode這一步被很多從零開始的人直接跳過但在業(yè)務價值敏感的系統(tǒng)里它幾乎是必須的。上線后的兩個小時內我就曾親眼見到一次誤判暴露出明顯的數(shù)據(jù)分布問題那種情況下如果沒有shadow mode先跑一周問題會直接作用在用戶身上。6.2 項目里遇到過的典型問題與排查思路把問題寫下來比泛泛而談“注意”要有用得多。我把自己常遇到的幾個問題和排查思路整理成一張速查表。第一模型在驗證集上很好線上表現(xiàn)一塌糊涂。優(yōu)先懷疑數(shù)據(jù)泄露和時間分布漂移檢查是否存在同源數(shù)據(jù)出現(xiàn)在兩個集合里深挖特征的獲取時間點。第二訓練loss不降或降得極慢。先打印一次prediction和label看看數(shù)值范圍是否異常是否分類數(shù)不對再用小樣本過擬合測試判斷代碼是否有bug。第三GPU顯存OOM?？梢韵葴p小batch size規(guī)范化模型輸入尺寸檢查是否有變量被誤加入計算圖及時把不需要的隱狀態(tài)detach掉。第四線上服務吞吐量不夠。先看瓶頸是把時間花在GPU推理、數(shù)據(jù)加載還是序列化上針對性地緩存預處理結果或改用更輕量模型。除此之外還有一個經(jīng)典check訓練時損失下降了但驗證集精度不動。這種情況大多是數(shù)據(jù)標簽噪聲過高模型即使把訓練集背下來也沒法泛化到新的驗證集。優(yōu)先回去看標注質量和樣本分布。6.3 個人體會AI工程能力的本質是什么從零開始做AI工程做的越久越發(fā)現(xiàn)真正的工程能力不是“會不會調參”而是“面對不確定性時有系統(tǒng)的方法去逼近事實”。當你遇到模型效果差、上線失敗、數(shù)據(jù)異常時靠的不是運氣而是一套你能穩(wěn)定復現(xiàn)的流程。環(huán)境是否可復現(xiàn)、數(shù)據(jù)是否有版本、實驗是否有日志、部署是否有監(jiān)控、反饋是否在閉環(huán)。每個環(huán)節(jié)多費一點心思整條系統(tǒng)就穩(wěn)一分。根據(jù)我的個人經(jīng)驗想在AI工程這條路上走得遠可以刻意訓練一個習慣每次完成一個實驗都寫下“如果我這次重新開始會先做什么”。這個習慣能讓你快速復盤出真正重要的事在別人還糾結某一個參數(shù)的精度時你已經(jīng)把整個系統(tǒng)的可靠性提上去了。從零開始的路不難難的是每一步都穩(wěn)著走。