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