1. 從零搭建AI工程能力為什么大多數(shù)人卡在第一步聊到“從零開始做AI工程”這個(gè)話題我腦子里第一反應(yīng)不是某個(gè)框架、某個(gè)模型而是一個(gè)很現(xiàn)實(shí)的問題大部分人根本不知道自己該從哪一行代碼寫起。你可能已經(jīng)看過不少教程跟著跑通了幾個(gè)Notebook模型在MNIST上準(zhǔn)確率刷到了99%但一旦讓你從零搭一個(gè)能用的AI系統(tǒng)立刻就懵了。這不是你笨而是因?yàn)椤芭芡ㄒ粋€(gè)模型”和“構(gòu)建一套AI工程體系”之間隔著一整條工程化的鴻溝。ai-engineering-from-scratch這個(gè)標(biāo)題核心不在“AI”而在“engineering”和“from scratch”。它要解決的不是“怎么訓(xùn)練一個(gè)模型”而是“怎么像一名真正的AI工程師那樣從零開始把數(shù)據(jù)、模型、服務(wù)、監(jiān)控這一整條鏈路搭起來”。適合誰看適合那些已經(jīng)會(huì)寫Python、懂一點(diǎn)機(jī)器學(xué)習(xí)基礎(chǔ)但在實(shí)際項(xiàng)目中總覺得“差點(diǎn)意思”的人。也適合那些從后端、數(shù)據(jù)方向轉(zhuǎn)過來想搞清楚AI系統(tǒng)到底和普通軟件系統(tǒng)有什么本質(zhì)區(qū)別的工程師。我見過太多人一上來就沖去學(xué)Transformer架構(gòu)、研究注意力機(jī)制的數(shù)學(xué)推導(dǎo)結(jié)果連一個(gè)最簡(jiǎn)單的推理服務(wù)都部署不明白。這就像你想學(xué)做菜不去練刀工、火候先花三個(gè)月研究小麥的分子結(jié)構(gòu)。不是說底層原理不重要而是工程能力的構(gòu)建有它自己的順序搞反了順序投入產(chǎn)出比會(huì)低得讓你懷疑人生。這篇文章我會(huì)按照一個(gè)真實(shí)的從零構(gòu)建路徑來展開把每個(gè)階段該做什么、為什么這么做、容易踩什么坑全部拆開講清楚。你不需要有很深的數(shù)學(xué)背景但需要有一點(diǎn)耐心因?yàn)锳I工程本質(zhì)上是一門“手藝活”光看是看不會(huì)的。2. 先搞清楚AI工程和傳統(tǒng)軟件工程到底差在哪2.1 確定性系統(tǒng)與概率性系統(tǒng)的根本分歧傳統(tǒng)軟件工程的核心假設(shè)是給定相同的輸入系統(tǒng)應(yīng)該產(chǎn)生相同的輸出。你寫一個(gè)排序函數(shù)輸入[3,1,2]永遠(yuǎn)得到[1,2,3]。測(cè)試寫起來很直接——斷言輸出等于預(yù)期值就行了。但AI系統(tǒng)從根上就打破了這個(gè)假設(shè)。同一個(gè)輸入模型可能這次輸出“正面情感”下次輸出“中性情感”因?yàn)槟Ｐ蜋?quán)重是浮點(diǎn)數(shù)推理過程涉及大量矩陣運(yùn)算數(shù)值精度、硬件差異、甚至批次大小的變化都會(huì)影響最終結(jié)果。這意味著你不能再用傳統(tǒng)的單元測(cè)試思路來驗(yàn)證AI系統(tǒng)。你需要的是統(tǒng)計(jì)意義上的驗(yàn)證在一個(gè)分布上模型的準(zhǔn)確率、召回率、F1分?jǐn)?shù)是否達(dá)標(biāo)。這不是說傳統(tǒng)測(cè)試方法沒用了而是說你必須額外構(gòu)建一套針對(duì)概率性系統(tǒng)的評(píng)估體系。很多從傳統(tǒng)后端轉(zhuǎn)過來的工程師第一個(gè)跟頭就栽在這里——他們花大量時(shí)間寫精確斷言結(jié)果發(fā)現(xiàn)測(cè)試天天掛最后干脆不寫了系統(tǒng)裸奔上線。2.2 數(shù)據(jù)是代碼的一部分而且比代碼更難管在傳統(tǒng)工程里代碼是核心資產(chǎn)數(shù)據(jù)是附屬品。但在AI工程里數(shù)據(jù)的質(zhì)量和分布直接決定了系統(tǒng)的上限。你模型架構(gòu)再先進(jìn)訓(xùn)練數(shù)據(jù)里全是噪聲出來的東西就是垃圾。更麻煩的是數(shù)據(jù)不像代碼那樣可以用Git做版本控制——一個(gè)數(shù)據(jù)集動(dòng)輒幾個(gè)GB到幾個(gè)TB你不可能每次改動(dòng)都提交到倉庫里。所以AI工程從第一天起就要考慮數(shù)據(jù)版本管理的問題。常見做法是用DVC或者類似的工具來追蹤數(shù)據(jù)集的變更把數(shù)據(jù)文件的哈希值和元信息存到Git里實(shí)際數(shù)據(jù)放在對(duì)象存儲(chǔ)上。這個(gè)決策看起來很小但如果你一開始不做等到數(shù)據(jù)集迭代了十幾版之后你會(huì)發(fā)現(xiàn)根本搞不清楚哪個(gè)模型是用哪版數(shù)據(jù)訓(xùn)出來的復(fù)現(xiàn)實(shí)驗(yàn)變成了一場(chǎng)考古。2.3 部署之后才是真正麻煩的開始傳統(tǒng)軟件上線之后只要服務(wù)器不掛行為基本是穩(wěn)定的。AI系統(tǒng)上線之后模型會(huì)隨著時(shí)間推移而“退化”。原因很簡(jiǎn)單真實(shí)世界的數(shù)據(jù)分布在變而你的模型是在歷史數(shù)據(jù)上訓(xùn)練的。比如一個(gè)電商推薦系統(tǒng)訓(xùn)練時(shí)用的是去年的用戶行為數(shù)據(jù)今年用戶的偏好變了模型的推薦效果就會(huì)下降。這種現(xiàn)象叫“數(shù)據(jù)漂移”是AI系統(tǒng)特有的問題。所以AI工程必須包含監(jiān)控和反饋閉環(huán)。你需要持續(xù)追蹤模型的輸入分布、輸出分布、以及業(yè)務(wù)指標(biāo)點(diǎn)擊率、轉(zhuǎn)化率等一旦發(fā)現(xiàn)異常就要觸發(fā)重新訓(xùn)練。這套機(jī)制在傳統(tǒng)軟件里根本不存在你得從零設(shè)計(jì)。這也是為什么我說AI工程師不能只懂模型還得懂?dāng)?shù)據(jù)管道、懂服務(wù)架構(gòu)、懂監(jiān)控告警。3. 從零構(gòu)建的第一個(gè)階段把數(shù)據(jù)管道跑通3.1 為什么數(shù)據(jù)管道比模型更值得先投入我見過太多項(xiàng)目模型代碼寫得漂漂亮亮但數(shù)據(jù)管道一團(tuán)糟。訓(xùn)練腳本里硬編碼了數(shù)據(jù)路徑預(yù)處理邏輯散落在十幾個(gè)文件里每次換數(shù)據(jù)集都要改半天代碼。這種項(xiàng)目基本上活不過三個(gè)月。正確的做法是先把數(shù)據(jù)管道做成一個(gè)獨(dú)立的、可測(cè)試的、可復(fù)用的模塊然后再往上疊模型。數(shù)據(jù)管道要解決的核心問題就三個(gè)數(shù)據(jù)從哪里來、怎么變成模型能吃的格式、怎么保證每次訓(xùn)練用的數(shù)據(jù)是一致的。聽起來簡(jiǎn)單但每個(gè)環(huán)節(jié)都有坑。比如數(shù)據(jù)來源可能是數(shù)據(jù)庫、CSV文件、API接口格式五花八門預(yù)處理可能涉及缺失值填充、類別編碼、歸一化每一步的參數(shù)都需要保存下來推理時(shí)要用同樣的參數(shù)處理新數(shù)據(jù)一致性則要求你記錄每次訓(xùn)練的輸入數(shù)據(jù)版本和預(yù)處理配置。3.2 一個(gè)最小可用的數(shù)據(jù)管道長(zhǎng)什么樣假設(shè)你現(xiàn)在要做一個(gè)文本分類任務(wù)從零開始搭數(shù)據(jù)管道。我會(huì)建議你按這個(gè)順序來第一步定義一個(gè)數(shù)據(jù)加載層。不要直接在訓(xùn)練腳本里寫pd.read_csv()而是封裝一個(gè)DataLoader類負(fù)責(zé)從不同來源讀取原始數(shù)據(jù)返回一個(gè)統(tǒng)一的DataFrame格式。這樣做的好處是以后換數(shù)據(jù)源只需要改這一個(gè)類訓(xùn)練代碼完全不用動(dòng)。第二步定義預(yù)處理層。把所有預(yù)處理邏輯寫成一個(gè)Preprocessor類包含fit()和transform()兩個(gè)方法。fit()在訓(xùn)練數(shù)據(jù)上計(jì)算統(tǒng)計(jì)量比如均值、方差、詞表transform()用這些統(tǒng)計(jì)量處理數(shù)據(jù)。關(guān)鍵是要把fit()得到的參數(shù)保存到磁盤上推理時(shí)加載同樣的參數(shù)。這一步是保證訓(xùn)練和推理一致性的核心。第三步定義數(shù)據(jù)集劃分邏輯。訓(xùn)練集、驗(yàn)證集、測(cè)試集的劃分要固定隨機(jī)種子并且把劃分結(jié)果保存下來。不要每次跑訓(xùn)練都重新劃分否則你的實(shí)驗(yàn)結(jié)果根本沒法比較。import pandas as pd import numpy as np import pickle from sklearn.model_selection import train_test_split class DataLoader: def __init__(self, source_path): self.source_path source_path def load(self): df pd.read_csv(self.source_path) df df.dropna(subset[text, label]) return df class Preprocessor: def __init__(self): self.vocab {} self.max_len 128 def fit(self, texts): from collections import Counter word_counts Counter() for text in texts: word_counts.update(text.lower().split()) self.vocab {word: idx1 for idx, (word, _) in enumerate(word_counts.most_common(10000))} def transform(self, texts): sequences [] for text in texts: seq [self.vocab.get(w, 0) for w in text.lower().split()] seq seq[:self.max_len] seq seq [0] * (self.max_len - len(seq)) sequences.append(seq) return np.array(sequences) def save(self, path): with open(path, wb) as f: pickle.dump({vocab: self.vocab, max_len: self.max_len}, f) def load(self, path): with open(path, rb) as f: params pickle.load(f) self.vocab params[vocab] self.max_len params[max_len]這段代碼看起來很樸素但它解決了一個(gè)關(guān)鍵問題預(yù)處理參數(shù)和模型權(quán)重是分開保存的。推理時(shí)你先加載預(yù)處理器參數(shù)再加載模型權(quán)重兩者必須配套使用。我見過有人把預(yù)處理邏輯直接寫死在訓(xùn)練腳本里結(jié)果部署的時(shí)候忘了同步導(dǎo)致線上效果和離線評(píng)估差了十幾個(gè)百分點(diǎn)。3.3 數(shù)據(jù)版本管理的最小實(shí)踐你不需要一上來就搞一套復(fù)雜的數(shù)據(jù)版本管理系統(tǒng)。一個(gè)最簡(jiǎn)單的做法是每次數(shù)據(jù)集發(fā)生變更時(shí)計(jì)算整個(gè)數(shù)據(jù)文件的MD5哈希值把這個(gè)哈希值和變更說明記錄到一個(gè)data_versions.csv文件里。訓(xùn)練時(shí)在日志中記錄使用了哪個(gè)哈希值的數(shù)據(jù)。這樣至少能保證你事后能追溯。更進(jìn)一步的做法是用DVC。DVC的工作原理是在Git里存一個(gè)很小的.dvc文件里面記錄了數(shù)據(jù)文件的哈希值和存儲(chǔ)路徑實(shí)際數(shù)據(jù)存在本地目錄或?qū)ο蟠鎯?chǔ)上。當(dāng)你執(zhí)行dvc add data.csv時(shí)DVC會(huì)計(jì)算哈希、把數(shù)據(jù)移到緩存目錄、生成.dvc文件。這樣你的Git倉庫保持輕量同時(shí)數(shù)據(jù)版本和代碼版本是關(guān)聯(lián)的。注意數(shù)據(jù)版本管理不是可選項(xiàng)。如果你打算長(zhǎng)期維護(hù)一個(gè)AI系統(tǒng)從第一天就要做。否則三個(gè)月后你一定會(huì)遇到“這個(gè)模型到底是用哪版數(shù)據(jù)訓(xùn)的”這種問題。4. 模型訓(xùn)練環(huán)節(jié)從腳本到可復(fù)現(xiàn)的實(shí)驗(yàn)4.1 為什么你的實(shí)驗(yàn)總是無法復(fù)現(xiàn)“上次跑出來F1是0.85這次怎么只有0.82”——這是AI工程師最常遇到的靈魂拷問。原因通常有這幾個(gè)隨機(jī)種子沒固定、數(shù)據(jù)劃分變了、依賴庫版本升級(jí)了、硬件環(huán)境不同導(dǎo)致浮點(diǎn)運(yùn)算結(jié)果有差異。要解決這個(gè)問題你需要把訓(xùn)練過程當(dāng)成一個(gè)實(shí)驗(yàn)來管理而不是當(dāng)成一個(gè)腳本隨便跑跑。實(shí)驗(yàn)管理的核心是記錄。每次訓(xùn)練要記錄代碼版本Git commit hash、數(shù)據(jù)版本數(shù)據(jù)哈希、超參數(shù)配置、環(huán)境信息Python版本、關(guān)鍵庫版本、CUDA版本、隨機(jī)種子、以及最終的評(píng)估指標(biāo)。這些信息看起來很多但如果你用配置文件來管理超參數(shù)用工具來自動(dòng)記錄環(huán)境信息實(shí)際工作量并不大。4.2 配置文件驅(qū)動(dòng)的訓(xùn)練腳本我強(qiáng)烈建議你把所有超參數(shù)寫到一個(gè)YAML或JSON配置文件里訓(xùn)練腳本只負(fù)責(zé)讀取配置、執(zhí)行訓(xùn)練、保存結(jié)果。這樣做的好處是實(shí)驗(yàn)配置可以版本控制不同實(shí)驗(yàn)之間的差異一目了然復(fù)現(xiàn)時(shí)只需要用同一個(gè)配置文件跑一遍。# config/train_config.yaml data: source_path: data/raw/dataset.csv test_size: 0.2 val_size: 0.1 random_seed: 42 preprocessing: max_vocab_size: 10000 max_sequence_length: 128 model: embedding_dim: 128 hidden_dim: 256 num_layers: 2 dropout: 0.3 training: batch_size: 64 learning_rate: 0.001 epochs: 20 early_stopping_patience: 3 checkpoint_dir: checkpoints/訓(xùn)練腳本讀取這個(gè)配置用配置里的隨機(jī)種子初始化所有隨機(jī)數(shù)生成器訓(xùn)練完成后把最佳模型的權(quán)重、預(yù)處理器的參數(shù)、以及完整的配置一起保存到一個(gè)以時(shí)間戳命名的目錄里。這樣每個(gè)實(shí)驗(yàn)都是自包含的不會(huì)互相干擾。4.3 評(píng)估指標(biāo)的選擇比模型架構(gòu)更重要新手最容易犯的錯(cuò)誤是只看準(zhǔn)確率。在類別不平衡的數(shù)據(jù)集上準(zhǔn)確率會(huì)騙人。比如一個(gè)二分類任務(wù)正樣本占5%負(fù)樣本占95%你的模型只要全部預(yù)測(cè)為負(fù)準(zhǔn)確率就有95%但實(shí)際上一事無成。這時(shí)候你需要看精確率、召回率、F1分?jǐn)?shù)甚至AUC-ROC曲線。選擇什么指標(biāo)取決于你的業(yè)務(wù)場(chǎng)景。如果是垃圾郵件過濾你更關(guān)心精確率不能把正常郵件誤判為垃圾如果是疾病篩查你更關(guān)心召回率不能漏掉真正的病人。沒有萬能的指標(biāo)只有適合場(chǎng)景的指標(biāo)。在訓(xùn)練腳本里我通常會(huì)同時(shí)計(jì)算多個(gè)指標(biāo)保存到日志里方便后續(xù)分析。還有一個(gè)容易被忽略的點(diǎn)評(píng)估要在固定的測(cè)試集上做。不要每次訓(xùn)練都重新劃分測(cè)試集否則你的指標(biāo)波動(dòng)里有一部分是數(shù)據(jù)劃分帶來的噪聲你根本分不清模型是真的變好了還是運(yùn)氣好。5. 把模型變成服務(wù)推理部署的關(guān)鍵決策5.1 批處理、實(shí)時(shí)推理、流式推理怎么選模型訓(xùn)練好之后下一步是讓它能被調(diào)用。這里有三種常見的部署模式選擇哪種取決于你的業(yè)務(wù)需求模式適用場(chǎng)景延遲要求實(shí)現(xiàn)復(fù)雜度批處理離線分析、日?qǐng)?bào)生成小時(shí)級(jí)低實(shí)時(shí)推理在線推薦、風(fēng)控毫秒到秒級(jí)中流式推理實(shí)時(shí)監(jiān)控、事件驅(qū)動(dòng)秒級(jí)高批處理最簡(jiǎn)單寫個(gè)腳本定時(shí)跑就行。實(shí)時(shí)推理需要你搭一個(gè)HTTP服務(wù)通常用FastAPI或Flask。流式推理則需要消息隊(duì)列如Kafka和流處理框架復(fù)雜度最高。我的建議是從批處理開始確認(rèn)模型效果穩(wěn)定后再做實(shí)時(shí)服務(wù)。不要一上來就搞微服務(wù)架構(gòu)那是給自己找麻煩。5.2 用FastAPI搭一個(gè)最小推理服務(wù)FastAPI是目前Python生態(tài)里做推理服務(wù)最順手的選擇。它自帶異步支持、自動(dòng)生成API文檔、性能也夠用。一個(gè)最小的推理服務(wù)大概長(zhǎng)這樣from fastapi import FastAPI from pydantic import BaseModel import numpy as np import pickle import torch app FastAPI() class PredictRequest(BaseModel): text: str class PredictResponse(BaseModel): label: str confidence: float # 啟動(dòng)時(shí)加載模型和預(yù)處理器 preprocessor Preprocessor() preprocessor.load(artifacts/preprocessor.pkl) model torch.load(artifacts/model.pt, map_locationcpu) model.eval() LABELS [負(fù)面, 正面] app.post(/predict, response_modelPredictResponse) async def predict(request: PredictRequest): seq preprocessor.transform([request.text]) tensor torch.LongTensor(seq) with torch.no_grad(): logits model(tensor) probs torch.softmax(logits, dim-1) pred_idx torch.argmax(probs, dim-1).item() confidence probs[0][pred_idx].item() return PredictResponse( labelLABELS[pred_idx], confidenceround(confidence, 4) )這個(gè)服務(wù)看起來很簡(jiǎn)單但有幾個(gè)關(guān)鍵點(diǎn)模型在啟動(dòng)時(shí)加載一次不要每次請(qǐng)求都重新加載推理時(shí)用torch.no_grad()關(guān)閉梯度計(jì)算節(jié)省內(nèi)存輸入輸出用Pydantic模型定義自動(dòng)做類型校驗(yàn)和文檔生成。5.3 推理服務(wù)的性能優(yōu)化思路如果你的服務(wù)QPS要求不高比如每秒幾十個(gè)請(qǐng)求上面這個(gè)版本完全夠用。但如果要求更高就需要做一些優(yōu)化。最常見的優(yōu)化手段是批處理把多個(gè)請(qǐng)求攢成一個(gè)批次一起推理充分利用GPU的并行能力。實(shí)現(xiàn)方式可以是服務(wù)端定時(shí)攢批也可以是客戶端主動(dòng)發(fā)批量請(qǐng)求。另一個(gè)優(yōu)化方向是模型量化。把FP32的權(quán)重轉(zhuǎn)成INT8模型體積縮小4倍推理速度提升2-3倍精度損失通常在1%以內(nèi)。PyTorch提供了動(dòng)態(tài)量化和靜態(tài)量化兩種方式動(dòng)態(tài)量化最簡(jiǎn)單一行代碼就能搞定quantized_model torch.quantization.quantize_dynamic( model, {torch.nn.Linear}, dtypetorch.qint8 )但要注意量化后的模型在CPU上加速明顯在GPU上反而不一定。所以量化之前先確認(rèn)你的部署環(huán)境是什么。提示推理服務(wù)的第一個(gè)版本不要追求極致性能。先讓它跑起來能正確返回結(jié)果然后再根據(jù)實(shí)際壓測(cè)數(shù)據(jù)做優(yōu)化。過早優(yōu)化是萬惡之源。6. 上線之后監(jiān)控、反饋與持續(xù)迭代6.1 模型監(jiān)控到底該盯哪些指標(biāo)模型上線不是終點(diǎn)而是起點(diǎn)。你需要持續(xù)監(jiān)控三類指標(biāo)系統(tǒng)指標(biāo)、數(shù)據(jù)指標(biāo)、業(yè)務(wù)指標(biāo)。系統(tǒng)指標(biāo)包括請(qǐng)求延遲、QPS、錯(cuò)誤率、CPU/內(nèi)存使用率這些和普通服務(wù)監(jiān)控一樣。數(shù)據(jù)指標(biāo)包括輸入文本的長(zhǎng)度分布、詞匯分布、以及模型輸出的置信度分布。業(yè)務(wù)指標(biāo)則是最終的轉(zhuǎn)化率、點(diǎn)擊率等。數(shù)據(jù)指標(biāo)是AI系統(tǒng)特有的。如果輸入分布發(fā)生了明顯變化比如突然出現(xiàn)大量超長(zhǎng)文本模型的輸出可能變得不可靠。一個(gè)實(shí)用的做法是計(jì)算輸入數(shù)據(jù)的統(tǒng)計(jì)量均值、方差、分位數(shù)和訓(xùn)練數(shù)據(jù)的統(tǒng)計(jì)量做對(duì)比偏差超過閾值就觸發(fā)告警。6.2 建立反饋閉環(huán)的最小方案監(jiān)控發(fā)現(xiàn)問題之后你需要一個(gè)反饋閉環(huán)來修復(fù)。最簡(jiǎn)單的閉環(huán)是記錄線上推理的輸入和輸出定期人工標(biāo)注一部分樣本用新標(biāo)注的數(shù)據(jù)重新訓(xùn)練模型。這個(gè)流程不需要很復(fù)雜但必須要有。具體操作上你可以在推理服務(wù)里加一個(gè)日志模塊把每次請(qǐng)求的輸入文本、模型輸出、置信度、時(shí)間戳寫到一個(gè)日志文件或數(shù)據(jù)庫里。然后每周或每月抽樣一批低置信度的樣本交給人工標(biāo)注把標(biāo)注結(jié)果加入訓(xùn)練集。重新訓(xùn)練后在固定的測(cè)試集上評(píng)估確認(rèn)效果提升后再上線。這個(gè)閉環(huán)的關(guān)鍵是低置信度樣本的利用。模型不確定的樣本往往是最有信息量的人工標(biāo)注這些樣本的性價(jià)比最高。不要隨機(jī)抽樣那樣會(huì)浪費(fèi)大量標(biāo)注預(yù)算在模型已經(jīng)很有把握的樣本上。6.3 模型更新的灰度發(fā)布策略新模型訓(xùn)練好之后不要直接全量替換。先做灰度發(fā)布把一小部分流量比如5%導(dǎo)到新模型上對(duì)比新舊模型在相同流量下的業(yè)務(wù)指標(biāo)。如果新模型指標(biāo)更好逐步擴(kuò)大流量比例如果變差了立刻回滾?；叶劝l(fā)布需要一個(gè)路由層根據(jù)請(qǐng)求的某些特征比如用戶ID的哈希值決定走哪個(gè)模型。這個(gè)路由邏輯可以放在推理服務(wù)里也可以放在網(wǎng)關(guān)層。關(guān)鍵是保證同一個(gè)用戶在灰度期間始終走同一個(gè)模型否則用戶體驗(yàn)會(huì)不一致。7. 那些沒人告訴你但一定會(huì)踩的坑7.1 訓(xùn)練環(huán)境和推理環(huán)境不一致這是最經(jīng)典的坑。訓(xùn)練時(shí)用的是PyTorch 1.12 CUDA 11.6推理服務(wù)器上裝的是PyTorch 1.13 CUDA 11.7結(jié)果模型加載報(bào)錯(cuò)或者推理結(jié)果有細(xì)微差異。解決辦法是用Docker把訓(xùn)練和推理環(huán)境統(tǒng)一起來用同一個(gè)鏡像。如果做不到至少要把依賴版本寫死在requirements.txt里并且在CI流程里驗(yàn)證推理服務(wù)能正常加載模型。7.2 預(yù)處理邏輯在訓(xùn)練和推理時(shí)不一致訓(xùn)練時(shí)用sklearn的StandardScaler做了歸一化推理時(shí)忘了做或者用了不同的參數(shù)。這種錯(cuò)誤不會(huì)報(bào)錯(cuò)但模型效果會(huì)莫名其妙地差。解決辦法是把預(yù)處理邏輯封裝成一個(gè)獨(dú)立的類訓(xùn)練和推理共用同一份代碼參數(shù)從磁盤加載。7.3 忽略了對(duì)模型輸入的長(zhǎng)度限制文本分類模型通常有最大序列長(zhǎng)度限制。訓(xùn)練時(shí)你截?cái)嗟搅?28個(gè)token推理時(shí)用戶輸入了一篇1000字的文章你沒有截?cái)嗑椭苯游菇o模型結(jié)果要么報(bào)錯(cuò)要么模型只看了前128個(gè)token后面的信息全丟了。解決辦法是在推理服務(wù)里加一個(gè)截?cái)噙壿嫼陀?xùn)練時(shí)保持一致。7.4 沒有做輸入校驗(yàn)用戶輸入空字符串、純空格、超長(zhǎng)文本、特殊字符你的服務(wù)直接崩潰。推理服務(wù)必須做輸入校驗(yàn)檢查文本是否為空、長(zhǎng)度是否超限、是否包含非法字符。校驗(yàn)不通過就返回明確的錯(cuò)誤信息不要讓異常穿透到模型層。7.5 模型文件太大導(dǎo)致部署困難有些模型動(dòng)輒幾個(gè)GB部署到生產(chǎn)環(huán)境時(shí)傳輸和加載都很慢。解決辦法是在保存模型時(shí)只保存必要的權(quán)重不要保存優(yōu)化器狀態(tài)如果模型確實(shí)很大考慮量化或剪枝部署時(shí)用對(duì)象存儲(chǔ)分發(fā)模型文件服務(wù)啟動(dòng)時(shí)異步加載。8. 從零到一的路線圖我建議你這樣安排時(shí)間如果你現(xiàn)在要從零開始構(gòu)建AI工程能力我建議按這個(gè)順序推進(jìn)第一階段1-2周把數(shù)據(jù)管道跑通。選一個(gè)簡(jiǎn)單的數(shù)據(jù)集寫一個(gè)可復(fù)用的數(shù)據(jù)加載和預(yù)處理模塊實(shí)現(xiàn)數(shù)據(jù)版本管理。這個(gè)階段的目標(biāo)是讓你對(duì)“數(shù)據(jù)在AI系統(tǒng)里怎么流動(dòng)”有一個(gè)具體的感知。第二階段2-3周把訓(xùn)練過程規(guī)范化。用配置文件管理超參數(shù)固定隨機(jī)種子記錄實(shí)驗(yàn)元信息保存預(yù)處理參數(shù)和模型權(quán)重。這個(gè)階段的目標(biāo)是讓你的實(shí)驗(yàn)可復(fù)現(xiàn)。第三階段1-2周搭一個(gè)最小推理服務(wù)。用FastAPI把模型包裝成HTTP接口加上輸入校驗(yàn)和日志記錄。這個(gè)階段的目標(biāo)是讓你理解“模型怎么變成服務(wù)”。第四階段持續(xù)建立監(jiān)控和反饋閉環(huán)。記錄線上數(shù)據(jù)定期評(píng)估模型表現(xiàn)用新數(shù)據(jù)迭代模型。這個(gè)階段沒有終點(diǎn)因?yàn)锳I系統(tǒng)的維護(hù)是一個(gè)持續(xù)的過程。每個(gè)階段都不要追求完美先跑通再優(yōu)化。我見過太多人卡在“選哪個(gè)框架”這種問題上糾結(jié)好幾天其實(shí)FastAPI和Flask都能用PyTorch和TensorFlow都能訓(xùn)選一個(gè)順手的先干起來后面不合適再換。AI工程是一門實(shí)踐性極強(qiáng)的技能看十篇文章不如自己動(dòng)手搭一遍。你在第一個(gè)階段踩的坑會(huì)比這篇文章里寫的所有注意事項(xiàng)都更讓你印象深刻。