1. 先搞清楚AI工程到底在解決什么問題1.1 它和算法崗、數(shù)據(jù)崗有什么區(qū)別很多人一看到“AI工程”這四個字下意識會覺得這就是調(diào)模型、訓(xùn)練神經(jīng)網(wǎng)絡(luò)。實際情況完全不同。AI工程要解決的不是“怎么把模型精度提上去”而是“怎么讓一個模型穩(wěn)定、高效、可維護地跑在生產(chǎn)環(huán)境里并且持續(xù)創(chuàng)造業(yè)務(wù)價值”。模型只是中間產(chǎn)物數(shù)據(jù)管道、特征存儲、訓(xùn)練框架、評估體系、部署服務(wù)、監(jiān)控告警、模型迭代這一整條鏈路才是AI工程的核心。如果你去看招聘JD算法崗?fù)ǔＲ蟆笆煜ransformer、精通PyTorch、有頂會論文”而AI工程崗寫的大多是“熟悉Kubernetes、有CI/CD經(jīng)驗、懂得模型監(jiān)控和A/B測試”。一句話總結(jié)算法崗的目標是“造出一個好模型”AI工程的目標是“把模型變成一項可靠的服務(wù)”。這兩個方向有交叉但思維方式差異很大。從零開始的人如果一上來就死磕網(wǎng)絡(luò)結(jié)構(gòu)忽略了工程化能力反而容易把自己困在“訓(xùn)練demo很行、一上生產(chǎn)就崩”的怪圈里。1.2 為什么“從零開始”是個優(yōu)勢我面試過不少候選人科班出身的往往一上來就聊模型結(jié)構(gòu)、損失函數(shù)但問到“訓(xùn)練數(shù)據(jù)是怎么產(chǎn)生的數(shù)據(jù)分布有沒有偏移服務(wù)掛在K8s上怎么滾動更新”就沉默了。反而是那些從零開始、一路自己折騰出來的工程師能把這套鏈路講得頭頭是道。所以我一直覺得“from scratch”不是劣勢反而是一個很好的起點。因為沒有歷史包袱你不會被“我們之前一直這么做的”這種慣性束縛。你會從第一行代碼開始構(gòu)建自己的工程體系每一步都知道為什么要這么做。這種“知其所以然”的能力在AI工程這個領(lǐng)域比背熟某個框架的API值錢得多。學(xué)AI工程本質(zhì)上就是訓(xùn)練自己“用工程手段解決模型落地問題”的肌肉記憶而這套肌肉記憶完全可以依靠一個又一個端到端項目慢慢長出來。2. 從零開始的技術(shù)棧搭建先學(xué)什么、后學(xué)什么2.1 編程基礎(chǔ)Python只是入場券別急著學(xué)PyTorch先把Python基礎(chǔ)打牢。我說的基礎(chǔ)不是“會寫for循環(huán)”而是能熟練處理模塊化代碼、異常處理、類型注解、裝飾器、上下文管理器這些日常工程特性。AI工程里你寫的優(yōu)雅代碼大概率會在生產(chǎn)環(huán)境里跑很久不是你訓(xùn)練完就扔的玩具腳本。用Poetry或uv管理項目依賴而不是把幾十個包全部塞進全局環(huán)境這是第一個需要養(yǎng)成的工程習(xí)慣。除了Python至少還要掌握三樣?xùn)|西Git、Docker、Linux命令行。Git不只是“commit/push”要會分支管理、rebase和解決沖突Docker要能寫出干凈的多階段構(gòu)建鏡像理解為什么生產(chǎn)環(huán)境不用pip install而是構(gòu)建鏡像Linux至少要熟練操作日志查看、進程管理、端口排查、crontab定時任務(wù)。這些技能我當年都是被生產(chǎn)事故逼著學(xué)會的——某次模型服務(wù)半夜掛了連服務(wù)器都登錄不進去那一刻才發(fā)現(xiàn)基本功有多重要。2.2 機器學(xué)習(xí)與深度學(xué)習(xí)原理學(xué)到“夠用”就好學(xué)習(xí)ML/DL原理要把握一個度不需要啃完花書但也不能只調(diào)包。我建議從線性回歸、邏輯回歸、決策樹這些經(jīng)典模型開始把損失函數(shù)、梯度下降、正則化這些核心概念吃透。然后進入神經(jīng)網(wǎng)絡(luò)理解反向傳播、BatchNorm、Dropout、學(xué)習(xí)率調(diào)度的原理?？蚣苡肞yTorch就夠TensorFlow也能學(xué)不過現(xiàn)在PyTorch的社區(qū)生態(tài)更活躍。這里有一條少走彎路的經(jīng)驗學(xué)原理的時候一定要動手把一個小模型的訓(xùn)練循環(huán)自己寫一遍。比如用純Python和NumPy實現(xiàn)一個兩層神經(jīng)網(wǎng)絡(luò)在MNIST上跑到90%的準確率然后換成PyTorch實現(xiàn)同樣的模型。你會發(fā)現(xiàn)框架替你做了多少事也會理解為什么工程上要關(guān)注梯度爆炸、學(xué)習(xí)率過大、數(shù)據(jù)歸一化這些細節(jié)。這類基礎(chǔ)訓(xùn)練看似枯燥但在后面排查模型問題時特別有用——你不會看到一個NaN loss就束手無策。2.3 工程化三件套數(shù)據(jù)、實驗、部署從零走向AI工程繞不開三座大山數(shù)據(jù)處理、實驗管理、模型部署。數(shù)據(jù)處理至少要掌握Pandas、SQL和一種ETL工具。很多剛?cè)腴T的同學(xué)喜歡用Pandas處理一切但上了生產(chǎn)數(shù)據(jù)動不動上千萬行就必須學(xué)會用SQL在數(shù)據(jù)庫層面做聚合過濾再用Spark或Dask做分布式處理。特征工程更是AI工程里最吃經(jīng)驗的部分后面我用一個具體項目展開。實驗管理這塊很多人一開始覺得“不就是記錄一下參數(shù)和指標嗎”直到同時跑幾十組實驗?zāi)Ｐ臀募y成一鍋粥才知道MLflow或者WB這類工具的價值。我在本地一般用MLflow因為它開源、輕量、能自托管訓(xùn)練完的模型還能直接注冊進Model Registry方便后續(xù)部署。模型部署以前是寫一個Flask API就完事現(xiàn)在標準做法是用FastAPI封裝推理接口用Docker打包鏡像推到鏡像倉庫后用Kubernetes或輕量的docker-compose做服務(wù)編排。如果你只想從零開始先跑通那最輕的方式是直接用一個成熟的推理服務(wù)框架比如Triton或TorchServe然后再去理解它們內(nèi)部的批處理、動態(tài)batching、顯存管理邏輯。3. 用一個端到端項目驗證全鏈路3.1 項目選題從“庫存預(yù)測”到“知識庫問答”與其零零散散看教程不如直接做一個覆蓋全鏈路的項目。我推薦的入門項目是“電商商品庫存預(yù)測”。原因有二第一業(yè)務(wù)場景足夠清晰——預(yù)測未來N天的銷量評估指標是RMSE人人都能看懂。第二它天然需要你處理時間序列數(shù)據(jù)、做滑窗特征、處理節(jié)假日影響最后還要把模型包成一個可以按時調(diào)用的API服務(wù)。如果你對大模型應(yīng)用更感興趣也可以做“基于RAG的私人知識庫問答”。這個項目的工程鏈更長文檔解析、文本切分、向量化、檢索、重排、大模型調(diào)用、流式輸出。但從零開始的階段我更建議先做庫存預(yù)測這類傳統(tǒng)機器學(xué)習(xí)項目。因為它簡單、快、容易閉環(huán)你能在幾天內(nèi)體會“訓(xùn)練-評估-部署-反饋”的完整循環(huán)。等這條鏈路跑熟了再升級到RAG項目你才不會在工程細節(jié)里迷失。3.2 數(shù)據(jù)處理與特征工程實操要點這個項目的數(shù)據(jù)可以自己造也可以用公開的電商銷量數(shù)據(jù)。假設(shè)你有一張訂單表字段包括order_date、sku_id、category、sales_qty、price。第一步不是建模而是做數(shù)據(jù)審視檢查缺失值、異常值、時間跨度是否足夠。時間序列項目尤其要小心數(shù)據(jù)泄露比如你用了未來時間的信息做特征會讓線上效果慘不忍睹。特征工程方面我實踐下來的經(jīng)驗是對銷量預(yù)測最有用的特征有三類滯后特征過去7天、14天、30天的平均銷量、最大銷量、波動率日歷特征星期幾、是否月初、是否節(jié)假日、距離最近節(jié)假日的天數(shù)商品屬性價格區(qū)間、品類、是否促銷。一個需要特別留意的細節(jié)是滯后窗口的選擇。窗口太短模型學(xué)不到周期性窗口太長會引入太多噪聲。我建議先用畫圖的方式看銷量序列是否有明顯周期性再結(jié)合業(yè)務(wù)確定窗口。比如日用消耗品有7天周期就可以把窗口設(shè)成7、14、28天而不是隨便拍腦袋。3.3 訓(xùn)練、評估和模型調(diào)參的實操記錄模型選型上我第一次做這個項目用的XGBoost和LightGBM。原因很簡單表格數(shù)據(jù)上這兩個模型只要特征處理好效果基本不會差而且訓(xùn)練快、調(diào)參門檻低。如果你非要用深度學(xué)習(xí)可以考慮時序模型或者Transformer變體但效率上會低很多入門階段沒必要。訓(xùn)練配置有一個比較穩(wěn)妥的基線80%數(shù)據(jù)做訓(xùn)練10%做驗證10%做測試并且按照時間順序切分不能隨機打亂。這是時間序列任務(wù)最容易犯的錯——隨機切分會讓模型偷看到未來數(shù)據(jù)。LightGBM里我會重點關(guān)注learning_rate、num_leaves、min_data_in_leaf這幾個參數(shù)。初期先用默認參數(shù)跑一個baseline然后用Optuna做100次貝葉斯搜索目標函數(shù)就是驗證集的RMSE。評估階段不要只盯著一個指標。我習(xí)慣同時看RMSE、MAE和MAPE。RMSE對離群點敏感MAE更反映平均表現(xiàn)MAPE則能看出相對誤差。如果MAPE在促銷日附近飆得很高就說明模型對突發(fā)流量不敏感這時候需要增加促銷相關(guān)的特征或者單獨訓(xùn)練一個“促銷日增量模型”。3.4 打包、API服務(wù)和監(jiān)控模型訓(xùn)練完之后真正的AI工程才剛剛開始。我用MLflow把最優(yōu)模型存成onnx格式這樣部署時不用依賴完整Python環(huán)境推理速度也能快不少。然后用FastAPI包一個很簡單的接口輸入是SKU和預(yù)測日期范圍輸出是預(yù)測值。這一步要注意統(tǒng)一輸入輸出的數(shù)據(jù)校驗不要等到線上跑掛了才發(fā)現(xiàn)字段名對不上。接著寫Dockerfile。一個合格的Dockerfile不應(yīng)該把整個訓(xùn)練環(huán)境全塞進去推理鏡像只需要運行時依賴。多階段構(gòu)建時先用python:3.11-slim裝依賴、把代碼拷進去再在最終鏡像里只保留app代碼和模型文件。推薦鏡像體積能從幾個GB壓到幾百MB。部署方式上如果只有一臺小服務(wù)器docker-compose配合一個簡單的Nginx反向代理就夠用。還需要加一個監(jiān)控接口記錄每次請求的延遲、輸入特征分布、預(yù)測值分布。我當時是寫一個簡單的middleware把請求日志寫到本地JSON文件再用Prometheus Grafana去采集展示。這不是花架子只要模型上線你就必須知道它有沒有在變“笨”。一旦預(yù)測分布明顯偏離訓(xùn)練期分布說明數(shù)據(jù)漂移已經(jīng)發(fā)生需要重新評估模型了。4. 我在實操中踩過的坑與排查方法4.1 數(shù)據(jù)泄露最隱蔽的錯誤數(shù)據(jù)泄露在AI工程里屬于那種“指標很漂亮、上線就完蛋”的坑。我在訓(xùn)練銷售預(yù)測模型時做過一個騷操作直接用“當日真實銷量”作為特征結(jié)果訓(xùn)練集RMSE接近0模型在測試集上卻一塌糊涂。后來才反應(yīng)過來預(yù)測未來銷量時當天真實值根本還沒有發(fā)生這就叫標簽泄露。另一個容易踩的坑是特征工程中的滯后期特征使用到了未來信息。舉個例子如果你用“未來7天平均銷量”做滯后期特征模型訓(xùn)練時性能亮眼但線上根本拿不到這個數(shù)。排查這類問題的方法很簡單做特征時嚴格按時間戳順序執(zhí)行保證每個樣本的特征字段只包含該時刻之前的數(shù)據(jù)如果發(fā)現(xiàn)某個特征的線上缺失率很高優(yōu)先懷疑它是不是用了未來信息。4.2 過擬合與欠擬合的工程判斷很多新手一看到訓(xùn)練集損失低、測試集損失高就瘋狂加正則化或Dropout。但問題往往不在模型復(fù)雜度而是數(shù)據(jù)劃分不合理。比如訓(xùn)練集和驗證集同分布程度差太遠或者驗證集太小、噪聲太大導(dǎo)致評估指標劇烈波動。正確做法是先檢查數(shù)據(jù)切分是否按時間/層級分層然后做多次交叉驗證觀察指標方差。如果確認過擬合再逐步調(diào)整先降低模型復(fù)雜度比如LightGBM減小num_leaves再增加正則化系數(shù)最后再用早停。欠擬合則是另一回事模型連訓(xùn)練集都學(xué)不好這時候加更多特征、增加訓(xùn)練輪數(shù)、提高模型容量才有意義。判斷過擬合欠擬合不要只憑眼睛看曲線還得結(jié)合業(yè)務(wù)滿意度——有時候模型效果已經(jīng)足夠好了再復(fù)雜化只是增加維護成本。4.3 實驗管理混亂本地文件堆成山?jīng)]有實驗管理工具的時候我的目錄長這樣model_v1_final.pkl、model_v1_final_v2.pkl、model_真_final.pkl。后來某次模型回滾時我根本分不清哪個版本用了哪份數(shù)據(jù)、哪套參數(shù)只能憑文件名猜差點釀成線上事故。從那以后我把MLflow接進了所有項目每次實驗自動記錄代碼版本、參數(shù)、指標和模型產(chǎn)物回滾的時候一鍵就能拉出歷史版本。管理實驗的另一個關(guān)鍵點是一開始就要把隨機種子固定下來。不固定種子同參數(shù)跑兩次結(jié)果都不一樣調(diào)參時根本沒法判斷是參數(shù)的影響還是隨機的波動。我的習(xí)慣是全局設(shè)置一個SEED42并在所有涉及隨機數(shù)的地方都傳入它。別小看這一步它能幫你省掉很多無謂的調(diào)試時間。4.4 上線后的模型漂移靜默的殺手模型上線后常見的現(xiàn)象是一開始效果不錯過了一個月指標慢慢下滑。很多人第一反應(yīng)是模型不行了重新訓(xùn)練一遍就完事。但如果沒有監(jiān)控你可能根本不知道下滑是“什么時候開始”的更不知道是“數(shù)據(jù)變了”還是“業(yè)務(wù)變了”。我當時監(jiān)控庫存預(yù)測服務(wù)時設(shè)置了兩個簡單的告警一個是預(yù)測值的均值偏離訓(xùn)練期均值的幅度超過20%觸發(fā)告警一個是真實銷量回填后計算當日預(yù)測誤差滾動7天平均絕對值超過閾值觸發(fā)告警。后一個指標需要把預(yù)測結(jié)果落庫等真實值出來再回填對比雖然麻煩但這是唯一能判斷模型是否“還在狀態(tài)”的方法。一旦觸發(fā)告警不要急著重訓(xùn)先分析漂移來自哪個特征再決定是更新特征、重新標注還是徹底換模型架構(gòu)。5. 從零到一的下一步還能做什么5.1 從單機走向分布式訓(xùn)練與推理當你習(xí)慣了單機訓(xùn)練模型下一步就是理解“為什么大模型要分布式訓(xùn)練”。這不是說你必須馬上搭一個GPU集群而是要知道數(shù)據(jù)并行、模型并行、流水線并行這些概念。至少要學(xué)會用PyTorch的DistributedDataParallel跑一個多卡訓(xùn)練的小實驗理解其中的通信開銷、梯度同步邏輯。推理側(cè)的工程化也從單機擴展到水平擴展。比如同一個模型服務(wù)部署多個副本前面加負載均衡配合Kubernetes的自動伸縮讓服務(wù)在流量高峰時自動擴容、低谷時縮容。這些操作不是背命令而是理解背后的原理容器編排、資源配額、優(yōu)雅退出。能把這一步走通你的AI工程能力已經(jīng)超越不少“只會訓(xùn)練模型”的同行了。5.2 LLM應(yīng)用工程化是新的必修課現(xiàn)在幾乎所有AI工程崗位都會聊到LLM應(yīng)用所以建議把傳統(tǒng)ML和LLM應(yīng)用都上手一遍。LLM的AI工程和傳統(tǒng)ML工程最大的區(qū)別在于傳統(tǒng)ML的“模型”是一個靜態(tài)權(quán)重文件而LLM應(yīng)用里模型是外部API你真正要工程化的是Prompt、知識庫、上下文管理和流式輸出。我自己做過一個RAG客服機器人踩了不少坑。文本切分切得不好檢索出來的片段經(jīng)常是半句話回答質(zhì)量一塌糊涂向量化模型選得不合適中文語義匹配效果很差召回率上去了但精排沒做好中間夾了很多無關(guān)片段。這些環(huán)節(jié)每個都要單獨評測和調(diào)優(yōu)。另外Prompt版本管理同樣需要納入Git和MLflow因為Prompt就是LLM應(yīng)用的“代碼”改一個字都可能影響最終效果。如果你能把庫存預(yù)測這樣的經(jīng)典項目、RAG問答這樣的LLM項目都完整跑過一遍AI工程這條線基本就立起來了。我個人的體會是真正的成長不在于看了多少論文、調(diào)了多少參數(shù)而在于親手把一個又一個項目從零拉起、上線、維護然后踩一堆坑、爬起來再優(yōu)化。這套“建立-驗證-迭代”的節(jié)奏才是AI工程最核心的復(fù)利。