1. 先搞明白AI工程和“調(diào)模型”到底差在哪1.1 什么是真正的 ai-engineering而不是跑通一個(gè) demo先說個(gè)我自己的經(jīng)歷。前兩年我第一次接觸一個(gè)所謂的“AI項(xiàng)目”實(shí)際上就是拿到一個(gè)公開的模型權(quán)重寫了個(gè)30行的Python腳本調(diào)用了一下輸出了幾個(gè)結(jié)果。那叫“用AI”不叫“AI工程”。真正讓我意識到兩者差距的是后來接了一個(gè)內(nèi)部需求公司想讓員工在一個(gè)集中式入口里用自然語言提問然后系統(tǒng)從幾十萬份技術(shù)文檔里找到答案還要帶著來源引用返回。一開始我覺得這有什么難的——模型加載起來做個(gè)embedding接個(gè)向量庫完事了。結(jié)果真正做下去才發(fā)現(xiàn)模型加載跑通只是這個(gè)項(xiàng)目里最不起眼的5%。剩下95%的時(shí)間都在處理數(shù)據(jù)質(zhì)量、環(huán)境一致性、訓(xùn)練穩(wěn)定性、線上延遲、評測標(biāo)準(zhǔn)、回歸回歸回歸——這才是ai-engineering from scratch的核心。所以這篇文章想分享的不是某一個(gè)模型的調(diào)用代碼而是當(dāng)你決定“從零開始把一條AI產(chǎn)品線真正落地”時(shí)你需要面對的那些繞不開的問題以及我踩過之后留下的方案。適合剛?cè)腴T的算法工程師、想把模型產(chǎn)品化的后端開發(fā)以及正在復(fù)現(xiàn)論文或開源項(xiàng)目、卻被環(huán)境、數(shù)據(jù)、部署折磨到懷疑人生的學(xué)生。標(biāo)題里的“from scratch”有兩層含義技術(shù)棧上的從零不是用別人封裝好的Paas平臺拖幾個(gè)組件而是自己掌握鏈路里的每一個(gè)關(guān)鍵環(huán)節(jié)。認(rèn)知上的從零打破“模型就是一切”的幻覺建立工程化思維。1.2 為什么選擇自建而不是直接套現(xiàn)成平臺做AI工程第一件事通常是選型用現(xiàn)成的大模型API還是自己微調(diào)部署用托管的向量數(shù)據(jù)庫還是自己起一個(gè)這里沒有標(biāo)準(zhǔn)答案但有決策框架。我當(dāng)時(shí)的判斷標(biāo)準(zhǔn)是四看看數(shù)據(jù)敏感性企業(yè)內(nèi)部文檔涉及業(yè)務(wù)細(xì)節(jié)不能隨便出網(wǎng)。看定制深度問答效果依賴對私有術(shù)語的理解通用模型明顯不夠。看長期成本調(diào)用量上來之后按token付費(fèi)的費(fèi)用遠(yuǎn)高于自建推理。看團(tuán)隊(duì)成長希望團(tuán)隊(duì)借這個(gè)項(xiàng)目真正建立AI工程能力而不是變成一個(gè)API轉(zhuǎn)發(fā)器。四條下來“自建 開源模型微調(diào) 私有部署”是唯一合理的路徑。但自建有一個(gè)被嚴(yán)重低估的代價(jià)鏈路變長了。以前用一個(gè)API只需要關(guān)注輸入輸出自建之后你要關(guān)注數(shù)據(jù)管道、GPU資源、訓(xùn)練穩(wěn)定性、推理吞吐、監(jiān)控告警。每多一個(gè)環(huán)節(jié)就多了一批潛在的故障點(diǎn)。這是所有從零開始的人要先做好的心理建設(shè)。1.3 一個(gè)貫穿全文的實(shí)例內(nèi)部文檔問答機(jī)器人為了讓下面的內(nèi)容不至于飄在理論上我以“企業(yè)內(nèi)部文檔問答機(jī)器人”作為貫穿案例。項(xiàng)目目標(biāo)很明確用戶輸入一個(gè)問題系統(tǒng)返回一段答案并附帶來源文檔和頁碼。業(yè)務(wù)上要求準(zhǔn)確率不低于85%首字節(jié)延遲低于2秒支持30個(gè)并發(fā)。訓(xùn)練數(shù)據(jù)來自公司內(nèi)部的技術(shù)文檔、產(chǎn)品手冊、歷史工單大約50萬條。這個(gè)例子覆蓋了AI工程的主要模塊數(shù)據(jù)管道、模型微調(diào)、推理部署、評測反饋。后面每個(gè)章節(jié)都會用它來說明“為什么這么做”“參數(shù)怎么定”“踩了什么坑”。2. 環(huán)境與基礎(chǔ)設(shè)施搭地基的姿勢決定上層建筑的穩(wěn)定程度2.1 GPU選型與驅(qū)動別一上來就被顯存卡死做AI工程第一道坎通常是硬件環(huán)境。我當(dāng)時(shí)拿到的是一臺雙卡機(jī)器配置是2塊24G顯存的GPU。很多人會問“顯存選多大”其實(shí)這個(gè)問題不應(yīng)該脫離模型規(guī)模去談。如果目標(biāo)是微調(diào)一個(gè)7B參數(shù)量的模型采用LoRA方式24G顯存跑fp16是夠的如果要全參數(shù)微調(diào)24G會很吃力。訓(xùn)練和推理的顯存需求差異也很大推理階段可以用量化大幅壓縮。選型的時(shí)候我列過一個(gè)粗略的評估表模型規(guī)模推理最低顯存FP16微調(diào)推薦顯存LoRA全參微調(diào)推薦顯存1B以下4G8G16G7B16G24G80G13B32G48G160G注意這只是經(jīng)驗(yàn)值實(shí)際要看序列長度和batch size。序列越長、batch越大顯存需求越高。驅(qū)動和CUDA版本這塊我吃過一次虧機(jī)器上預(yù)裝了CUDA 11.8但PyTorch版本要求CUDA 12.1結(jié)果程序沒有報(bào)CUDA錯(cuò)誤而是直接報(bào)“illegal memory access”排查了一天最后才發(fā)現(xiàn)是版本不匹配。現(xiàn)在我的原則是先查PyTorch官方對應(yīng)的CUDA版本再回過頭配置驅(qū)動。跑一個(gè)簡單的驗(yàn)證命令確認(rèn)環(huán)境正常python -c import torch; print(torch.__version__, torch.cuda.is_available(), torch.cuda.get_device_name(0))如果輸出顯示的GPU名稱正確CUDA可用再開始裝模型能省掉一大半玄學(xué)問題。2.2 用Docker把環(huán)境固化下來不要相信“在我電腦上是好的”AI工程的復(fù)現(xiàn)性有一個(gè)大敵環(huán)境漂移?！霸谖译娔X上跑得好好的”這句話在AI項(xiàng)目里出現(xiàn)的頻率遠(yuǎn)超其他軟件項(xiàng)目。原因很簡單訓(xùn)練腳本依賴的Python包有幾百個(gè)每個(gè)包又有不同版本某次升級一個(gè)小版本可能就帶來數(shù)值變化。為了把環(huán)境固化我強(qiáng)烈建議從第一步就引入Docker。我用的基礎(chǔ)鏡像形如FROM pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime RUN apt-get update apt-get install -y git curl RUN pip install --no-cache-dir transformers datasets accelerate peft trl COPY ./requirements.txt /app/ RUN pip install --no-cache-dir -r /app/requirements.txt這樣做的好處有三個(gè)環(huán)境與宿主隔離不會再因?yàn)橄到y(tǒng)Python升級導(dǎo)致依賴崩掉。訓(xùn)練、推理、測試用同一個(gè)鏡像結(jié)果可以對比。部署的時(shí)候直接把鏡像推到內(nèi)部倉庫生產(chǎn)機(jī)和開發(fā)機(jī)環(huán)境完全一致。我用的是conda還是Docker答案是都要。conda負(fù)責(zé)創(chuàng)建Python虛擬環(huán)境Docker負(fù)責(zé)把整個(gè)系統(tǒng)層傳下去。在Docker里面再用conda管理Python環(huán)境可以兼顧靈活與可復(fù)現(xiàn)。2.3 實(shí)驗(yàn)跟蹤沒有記錄的訓(xùn)練都是白訓(xùn)從零開始做AI工程最容易忽略的一個(gè)環(huán)節(jié)是實(shí)驗(yàn)記錄。我早期就是這樣改個(gè)參數(shù)跑一晚上第二天醒來發(fā)現(xiàn)效果好了但忘了昨天改了什么。那種“明明前一天還在變好現(xiàn)在怎么退步了”的困惑基本都源于沒有做好跟蹤。后來我引入了MLflow配合一套簡單的命名規(guī)范。每個(gè)實(shí)驗(yàn)記錄三樣?xùn)|西超參數(shù)學(xué)習(xí)率、batch size、epoch數(shù)、LoRA rank指標(biāo)訓(xùn)練loss、驗(yàn)證loss、準(zhǔn)確率、F1產(chǎn)物模型檢查點(diǎn)路徑、評測報(bào)告、日志文件命名規(guī)范是“日期-模型-版本-說明”比如“20240601-bert-base-zh-v01-lr2e5”。不要小看命名一個(gè)清晰的名字能讓你三個(gè)月后翻記錄時(shí)省下大量時(shí)間。如果你不想引入額外的服務(wù)也可以用最簡單的CSV記錄表。核心不是工具而是“每次改動都有跡可循”這個(gè)習(xí)慣。2.4 項(xiàng)目目錄結(jié)構(gòu)讓數(shù)據(jù)、代碼、模型、實(shí)驗(yàn)各歸其位從零搭建AI工程第一個(gè)該建立的不是模型而是目錄結(jié)構(gòu)。混亂的目錄是后期維護(hù)的地獄。我最后固定的結(jié)構(gòu)是這樣的ai-engineering/ ├── configs/ # 所有訓(xùn)練、推理、評測的配置 ├── data/ # 數(shù)據(jù)原始、清洗后、切分后 ├── src/ # 代碼 │ ├── data/ # 數(shù)據(jù)處理邏輯 │ ├── models/ # 模型定義 │ ├── train/ # 訓(xùn)練腳本 │ ├── infer/ # 推理邏輯 │ └── eval/ # 評測邏輯 ├── experiments/ # 實(shí)驗(yàn)記錄與產(chǎn)物 ├── models/ # 最終模型權(quán)重 └── scripts/ # 運(yùn)行入口腳本這個(gè)結(jié)構(gòu)的原則是數(shù)據(jù)和模型不跟代碼混在一起配置和實(shí)驗(yàn)結(jié)果又跟代碼分開。實(shí)際用下來的好處是很多時(shí)候只需要拷貝某個(gè)子目錄就能完成交接不用把“那一堆亂七八糟的文件”一起拷走。3. 數(shù)據(jù)是真正的上線難點(diǎn)清洗、版本化、切分3.1 從原始文檔到訓(xùn)練數(shù)據(jù)清洗規(guī)則怎么定很多從零開始做AI工程的人會低估數(shù)據(jù)處理的比重。真實(shí)情況是一個(gè)生產(chǎn)中可用的模型其數(shù)據(jù)工程耗時(shí)往往占總工時(shí)的60%以上。尤其像文檔問答這種場景原始數(shù)據(jù)是PDF、Word、HTML混在一起排版各異直接拿去訓(xùn)練根本不可能。我的清洗分四步走第一步做格式轉(zhuǎn)換。PDF用解析工具抽出文本W(wǎng)ord轉(zhuǎn)成純文本HTML剝掉標(biāo)簽。這里要注意PDF雙欄排版很容易抽取錯(cuò)亂需要按欄切分再拼接。第二步做段落切分。按標(biāo)題層級和段落邊界把文檔切成“語塊”而不是簡單按字符數(shù)硬切。我當(dāng)時(shí)用了一套基于標(biāo)題編號的規(guī)則同時(shí)保留每塊的來源元數(shù)據(jù)文檔名、章節(jié)路徑、頁碼。第三步做規(guī)則過濾。批量去掉頁眉頁腳、導(dǎo)航重復(fù)段落、空行、亂碼字符。規(guī)則要寫成腳本反復(fù)迭代不要手動刪。第四步做人工抽檢。每清洗完一批數(shù)據(jù)隨機(jī)抽100條檢查質(zhì)量。如果錯(cuò)誤率超過2%說明清洗規(guī)則還需要補(bǔ)。一點(diǎn)心得清洗規(guī)則寧多勿少因?yàn)榕K數(shù)據(jù)給模型帶來的傷害是隱性的——它不會報(bào)錯(cuò)只會讓效果差一點(diǎn)、再差一點(diǎn)最終你根本不知道是模型的問題還是數(shù)據(jù)的問題。3.2 數(shù)據(jù)版本管理改過什么永遠(yuǎn)要能查談到數(shù)據(jù)AI工程師圈子里流傳著一句話“模型是數(shù)據(jù)的影子?！蹦愀牧艘话鏀?shù)據(jù)模型效果完全不同。這時(shí)如果你沒記錄數(shù)據(jù)版本那么復(fù)現(xiàn)就是一個(gè)笑話。我做數(shù)據(jù)版本管理的辦法不復(fù)雜用類似DVC的方式但核心是把兩樣?xùn)|西固定下來——數(shù)據(jù)文件的哈希值和一份數(shù)據(jù)清單。每當(dāng)數(shù)據(jù)變更我會生成一個(gè)新的數(shù)據(jù)版本號格式是“v日期-序號”并記錄原始數(shù)據(jù)來源清洗腳本版本清洗參數(shù)清洗后樣本數(shù)量人工抽檢結(jié)果這份記錄放在數(shù)據(jù)目錄的“CHANGELOG.md”里。為什么這么在意因?yàn)楫?dāng)我發(fā)現(xiàn)模型效果下降時(shí)第一件事就是檢查數(shù)據(jù)版本是否被動過。有一次團(tuán)隊(duì)同事順手“優(yōu)化”了清洗腳本去掉了一個(gè)去重步驟結(jié)果數(shù)據(jù)量從50萬變成55萬模型準(zhǔn)確率掉了3個(gè)點(diǎn)。查了兩天最后定位到就是數(shù)據(jù)版本變了。如果一開始就查CHANGELOG十分鐘就能解決。3.3 切分與分布檢查訓(xùn)練集驗(yàn)證集的劃分要防止“作弊”數(shù)據(jù)切分看起來是個(gè)簡單問題——隨機(jī)分一下就行其實(shí)不是。文檔問答場景有一個(gè)典型風(fēng)險(xiǎn)同一份文檔的不同段落可能既出現(xiàn)在訓(xùn)練集又出現(xiàn)在驗(yàn)證集。模型見過相關(guān)內(nèi)容驗(yàn)證集分?jǐn)?shù)虛高上線后面對新文檔效果驟降。這就是數(shù)據(jù)泄露。我的切分原則是按文檔級別切分而不是按段落切分。同一篇文檔的段落放進(jìn)同一個(gè)集合。驗(yàn)證集和測試集不使用同一批文檔。切分之后人工檢查類別分布。比如工單類的數(shù)據(jù)占了60%驗(yàn)證集也要保持類似的占比否則指標(biāo)會有偏。切分完一定要跑一個(gè)簡單的分布檢查腳本輸出訓(xùn)練/驗(yàn)證/測試三個(gè)集合的樣本量、來源分布、平均長度?？吹饺M數(shù)字大致匹配再進(jìn)入訓(xùn)練環(huán)節(jié)。這里特別提醒一點(diǎn)不要反復(fù)在測試集上調(diào)參。測試集的唯一使命是最終評估一次。想調(diào)參用驗(yàn)證集。這個(gè)原則違反了你的指標(biāo)就只是“對測試集的記憶”不是真實(shí)能力。4. 模型訓(xùn)練與微調(diào)的實(shí)操從加載到收斂4.1 訓(xùn)練循環(huán)骨架每一行都有存在的理由從零開始寫訓(xùn)練循環(huán)不是把模型的forward和backward拼在一起就完事。一個(gè)生產(chǎn)可用的訓(xùn)練腳本要考慮的東西比教科書示例多得多梯度累積、混合精度、梯度裁剪、checkpoint保存、日志頻率。我用的訓(xùn)練循環(huán)骨架大致長這樣for epoch in range(num_epochs): model.train() for step, batch in enumerate(train_loader): batch {k: v.to(device) for k, v in batch.items()} outputs model(**batch) loss outputs.loss / grad_accum_steps loss.backward() if (step 1) % grad_accum_steps 0: torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0) optimizer.step() scheduler.step() optimizer.zero_grad() if step % log_steps 0: logger.info(fepoch {epoch}, step {step}, loss {loss.item():.4f}) # 每N步做一次驗(yàn)證 evaluate(model, val_loader)看起來平平無奇但有幾個(gè)點(diǎn)值得展開。梯度累積是為了在單卡顯存受限時(shí)用多個(gè)小batch模擬大batch的效果。grad_accum_steps 理想batch size / 實(shí)際batch size。比如理想batch是32顯存只放得下8那accum_steps就是4?；旌暇華MP可以讓訓(xùn)練加速且省顯存。PyTorch里用torch.cuda.amp即可一般不改業(yè)務(wù)代碼。但要注意部分模型在FP16下數(shù)值不穩(wěn)定loss會突變成nan。如果你遇到這種問題可以退回FP32或者用BF16在許多新卡上更穩(wěn)。4.2 超參數(shù)的起點(diǎn)以及調(diào)參的順序邏輯超參數(shù)是玄學(xué)嗎某種意義上是的但調(diào)參順序是有邏輯的。我的經(jīng)驗(yàn)是從學(xué)習(xí)率開始調(diào)。找一個(gè)大致的范圍比如1e-5到5e-5先用小數(shù)據(jù)集快速跑幾個(gè)epoch觀察loss走勢。loss不降說明學(xué)習(xí)率太小或者模型結(jié)構(gòu)有問題loss震蕩說明學(xué)習(xí)率太大。選定學(xué)習(xí)率之后再調(diào)batch size。batch size主要影響訓(xùn)練穩(wěn)定性和收斂速度太大會顯存爆炸太小會導(dǎo)致梯度噪聲大、收斂慢。再然后是epoch數(shù)。epoch數(shù)其實(shí)不是一個(gè)需要“調(diào)”的參數(shù)而是和早停early stopping配合的概念。我一般設(shè)置一個(gè)上限比如10個(gè)epoch如果驗(yàn)證指標(biāo)連續(xù)3個(gè)epoch沒有提升就提前結(jié)束訓(xùn)練并保存驗(yàn)證集上表現(xiàn)最好的那個(gè)檢查點(diǎn)。warmup比例也值得一說。很多模型微調(diào)時(shí)會設(shè)置一段“預(yù)熱期”學(xué)習(xí)率從零線性上升到目標(biāo)值再按余弦曲線下降。warmup的比例我習(xí)慣設(shè)為總步數(shù)的3%到5%。它的作用是防止訓(xùn)練初期由于學(xué)習(xí)率過大導(dǎo)致模型參數(shù)劇烈震蕩。4.3 什么時(shí)候上分布式單卡能解決的事別浪費(fèi)時(shí)間在多卡上很多從零開始的人有個(gè)誤區(qū)一上來就研究分布式訓(xùn)練框架。其實(shí)大多數(shù)項(xiàng)目單卡就能搞定。我的判斷標(biāo)準(zhǔn)是如果單卡訓(xùn)練一輪的時(shí)間在可接受范圍內(nèi)比如一個(gè)晚上能跑完就絕對不要上分布式。分布式訓(xùn)練帶來的增益不是沒有但它同時(shí)引入通信開銷、調(diào)試難度和版本兼容問題。性價(jià)比極低。只有當(dāng)訓(xùn)練時(shí)間超過資源容忍度比如單卡要跑一周以上才是考慮DDPDistributedDataParallel的時(shí)機(jī)。如果可以優(yōu)先用LoRA這種參數(shù)高效微調(diào)技術(shù)而不是全參微調(diào)。它在保持效果接近的情況下顯存占用和訓(xùn)練時(shí)間都能大幅降低。微調(diào)一個(gè)7B模型的LoRA24G單卡完全夠用。這個(gè)決策讓我的團(tuán)隊(duì)省下了一整臺A100預(yù)算。4.4 模型產(chǎn)物管理檢查點(diǎn)怎么存選哪個(gè)版本上線一個(gè)訓(xùn)練任務(wù)跑完會留下很多檢查點(diǎn)每個(gè)epoch保存一次加上早停保存的最佳檢查點(diǎn)以及最后一輪檢查點(diǎn)。不可能全部上線需要一套選擇邏輯。我現(xiàn)在的規(guī)則是候選檢查點(diǎn)都跑一遍評測集記錄核心指標(biāo)準(zhǔn)確率、F1、延遲。上線選擇不只看單一指標(biāo)。比如準(zhǔn)確率最高的檢查點(diǎn)可能在某類問題上的穩(wěn)定性很差我會看分項(xiàng)指標(biāo)再決定。所有檢查點(diǎn)統(tǒng)一命名格式模型名-訓(xùn)練數(shù)據(jù)版本-epoch號-指標(biāo)值。這個(gè)格式保證三個(gè)月后還能定位到“為什么選它”。保存檢查點(diǎn)的時(shí)候不只是存權(quán)重還要把訓(xùn)練配置和tokenizer一起打包。有過一次教訓(xùn)三個(gè)月后想恢復(fù)一個(gè)模型繼續(xù)訓(xùn)練結(jié)果只找到權(quán)重文件tokenizer配置丟了那個(gè)模型直接報(bào)廢。權(quán)重可以不要tokenizer和config一定要留在模型目錄里。5. 推理部署與性能調(diào)優(yōu)模型跑起來只是開始5.1 在線服務(wù)還是離線批量先想清楚業(yè)務(wù)形態(tài)部署的第一步不是寫API而是判斷業(yè)務(wù)到底需要什么形態(tài)。文檔問答這個(gè)場景用戶需要實(shí)時(shí)交互所以必須是在線服務(wù)接口響應(yīng)要快。而像“每周自動給全量工單打標(biāo)簽”這種就不需要API跑一個(gè)批量腳本就行。在線服務(wù)又分同步和異步。同步返回適合單次問答場景簡單直接。異步適合處理慢操作比如生成很長的答案先返回任務(wù)ID用戶再通過輪詢拿結(jié)果。我當(dāng)時(shí)的業(yè)務(wù)首字節(jié)延遲要求是2秒同步就夠用沒有引入額外的消息隊(duì)列。這里提醒一點(diǎn)不要為了“看起來高級”而加消息隊(duì)列。每多一個(gè)組件就多一層運(yùn)維負(fù)擔(dān)。先把同步接口做好發(fā)現(xiàn)瓶頸再演進(jìn)。5.2 推理加速量化、批處理、緩存三板斧模型部署之后第一件事就是壓測。我的經(jīng)驗(yàn)是不要憑感覺判斷性能直接用壓測工具跑指標(biāo)。壓測看三個(gè)數(shù)字QPS每秒能處理多少請求、P99延遲最慢的1%請求耗時(shí)、顯存占用。我的壓測結(jié)果是單卡初始QPS只有5P99延遲4秒遠(yuǎn)遠(yuǎn)不夠。之后我做了三板斧優(yōu)化第一板斧是量化。把模型從FP16量化到INT8或INT4顯存占用直接下降50%以上推理速度提升明顯。當(dāng)時(shí)用的是類似GPTQ的思路通過校準(zhǔn)集選擇量化參數(shù)。INT4的量化會讓效果略有下降但在這個(gè)業(yè)務(wù)場景下可接受。第二板斧是批處理。在線推理服務(wù)默認(rèn)是一個(gè)請求一個(gè)請求地過模型GPU利用率很低。改成動態(tài)批處理服務(wù)在極短的時(shí)間窗口比如50ms內(nèi)收集多個(gè)請求合并成一個(gè)batch同時(shí)推理。這個(gè)改動把GPU利用率從20%拉到80%以上QPS直接翻了幾倍。第三板斧是結(jié)果緩存。高頻問題往往占線上請求的大頭。對完全相同或高度相似的query直接用Redis緩存之前的結(jié)果。這個(gè)改動把30%的請求變成“零推理”效果立竿見影。優(yōu)化后我的最終指標(biāo)是QPS 25P99延遲1.2秒滿足業(yè)務(wù)需求。別小看這些優(yōu)化它們是“從能跑到能扛流量”的關(guān)鍵。5.3 API服務(wù)怎么做才像話模型推理服務(wù)本質(zhì)上是一個(gè)高并發(fā)的接口服務(wù)工程上不能裸奔。我用FastAPI搭的服務(wù)骨架大概長這樣from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class Query(BaseModel): question: str top_k: int 3 app.post(/v1/qa) async def qa(query: Query): try: result pipeline.run(query.question, top_kquery.top_k) return {answer: result[answer], sources: result[sources]} except Exception: raise HTTPException(status_code500, detailinternal error)但光有這個(gè)還不行生產(chǎn)環(huán)境至少還要有超時(shí)控制每個(gè)推理請求設(shè)置超時(shí)上限比如5秒避免慢請求拖垮線程池。重試策略對偶發(fā)的GPU顯存不足、臨時(shí)CUDA錯(cuò)誤做有限重試。限流對用戶或客戶端IP做每分鐘請求數(shù)限制防止惡意調(diào)用。隊(duì)列上限當(dāng)并發(fā)過大時(shí)服務(wù)的策略是“快速失敗”還是“排隊(duì)等待”要提前定好。我當(dāng)時(shí)選的是快速失敗返回503讓調(diào)用方自己退避。5.4 上線后的監(jiān)控沒有監(jiān)控的服務(wù)是一顆定時(shí)炸彈服務(wù)上線后我開始搭建最基本的監(jiān)控指標(biāo)。不是要什么花哨的可觀測性平臺而是先把最關(guān)鍵的指標(biāo)看住。GPU監(jiān)控利用工具每10秒采集一次顯存使用率、GPU利用率和溫度寫入時(shí)序數(shù)據(jù)庫畫到面板上。顯存持續(xù)上漲是泄漏的典型信號基本可以斷定服務(wù)代碼或推理框架有內(nèi)存管理問題。請求監(jiān)控記錄QPS、P99/平均延遲、超時(shí)率和5xx錯(cuò)誤率。延遲突增和錯(cuò)誤率飆升是兩大核心告警。數(shù)據(jù)漂移監(jiān)控上線后的模型會面對未知的線上數(shù)據(jù)分布。我的做法是定期從線上日志里取最新的query樣本和訓(xùn)練時(shí)的query做embedding距離分布對比。如果分布偏移過大就需要考慮重新訓(xùn)練。這個(gè)問題在文檔問答場景很常見——業(yè)務(wù)人員提問習(xí)慣會隨時(shí)間變化。不做監(jiān)控模型就像蒙著眼開車。你永遠(yuǎn)不知道它在生產(chǎn)環(huán)境里已經(jīng)被用戶的真實(shí)請求折磨成什么樣了。6. 評測體系與回歸測試不評測等于白做6.1 評測集是AI工程的“法律文件”模型好用不好用不是訓(xùn)練指標(biāo)說了算而是評測集說了算。很多人只盯著訓(xùn)練集上的loss降沒降這是最大的誤區(qū)。Loss降了可能是過擬合可能是數(shù)據(jù)泄漏可能只是“背題”。真正衡量模型能力的是一份和訓(xùn)練集完全獨(dú)立、由人工標(biāo)注、覆蓋真實(shí)業(yè)務(wù)場景的評測集。我當(dāng)時(shí)花了兩周時(shí)間做評測集。從50萬條數(shù)據(jù)里挑出2000條作為評測樣本覆蓋幾十種問題類型每條由三個(gè)人獨(dú)立標(biāo)注取多數(shù)作為最終答案。同時(shí)保證評測集里的文檔不會出現(xiàn)在訓(xùn)練集里。評測集要包含兩類樣本常規(guī)樣本絕大多數(shù)線上請求長什么樣評測集就長什么樣。邊界樣本故意放一些模糊問題、帶錯(cuò)別字的query、語義相近但答案不同的陷阱題。沒有邊界樣本你的評測分?jǐn)?shù)會很漂亮但上線后被真實(shí)用戶一問就原形畢露。6.2 自動化回歸測試改一個(gè)參數(shù)不要把全線上搞掛有了評測集下一步是把評測自動化。我設(shè)計(jì)了一套回歸測試流程每次模型更新或者數(shù)據(jù)更新都會跑一遍。流程分三段第一段是冒煙測試。用10條左右的高置信度樣本驗(yàn)證模型能不能正常加載、推理會不會報(bào)錯(cuò)。耗時(shí)兩分鐘作用是把明顯的代碼問題擋在門口。第二段是核心評測。用完整的2000條評測集跑一遍生成詳細(xì)報(bào)告。包括總體準(zhǔn)確率、分類型準(zhǔn)確率、和上一版模型的對比。如果新版模型總體指標(biāo)下降超過1%除非有明確理由否則默認(rèn)不通過。第三段是錯(cuò)誤case留檔。每次評測失敗的樣本自動記錄下來標(biāo)記“待人工分析”。這些case是數(shù)據(jù)迭代最寶貴的來源。我從這個(gè)流程里吃到最大的甜頭是再也不用擔(dān)心團(tuán)隊(duì)里任何人“偷偷把參數(shù)改了”之后影響線上效果看不到——自動化測試會用指標(biāo)說話。6.3 基于bad case的迭代閉環(huán)AI工程的“永動機(jī)”效果提升不是靠突然的靈感而是靠對bad case的持續(xù)分析。我的操作流程是收集錯(cuò)誤樣本從評測失敗和線上日志里匯總bad case。聚類分析把bad case歸類。比如“模型分不清‘退款’和‘退貨’的區(qū)別”“模型對縮寫理解錯(cuò)誤”“檢索結(jié)果缺失導(dǎo)致生成失敗”。每類給一個(gè)標(biāo)簽。定位根因有些bad case是數(shù)據(jù)問題有些是檢索問題有些是模型能力邊界。根因不同解決方案完全不同。數(shù)據(jù)補(bǔ)強(qiáng)針對根因補(bǔ)充對應(yīng)的訓(xùn)練數(shù)據(jù)或調(diào)整清洗規(guī)則。重新訓(xùn)練和評測回到訓(xùn)練階段跑完自動化測試看是否解決。這個(gè)循環(huán)跑上個(gè)10輪模型效果就會逐步逼近業(yè)務(wù)預(yù)期。數(shù)據(jù)版本管理、實(shí)驗(yàn)記錄、自動化評測的意義在這個(gè)閉環(huán)里全部體現(xiàn)出來。7. 常見問題與排查技巧實(shí)錄7.1 環(huán)境與訓(xùn)練階段的高頻問題現(xiàn)象常見原因排查思路啟動就報(bào)“illegal memory access”CUDA版本與PyTorch不匹配先核對PyTorch官方要求的CUDA版本再檢查驅(qū)動與CUDA訓(xùn)練中途顯存OOMbatch size過大或顯存碎片化先減小batch size或開啟梯度累積再檢查是否有變量未釋放loss是NaN學(xué)習(xí)率過大、FP16數(shù)值不穩(wěn)定、數(shù)據(jù)里有臟標(biāo)簽降低學(xué)習(xí)率可嘗試BF16檢查數(shù)據(jù)清洗loss一直不降學(xué)習(xí)率太小或訓(xùn)練數(shù)據(jù)分布混亂快速跑5個(gè)epoch看loss斜率排除數(shù)據(jù)標(biāo)簽大量錯(cuò)誤訓(xùn)練完指標(biāo)高線上效果差數(shù)據(jù)泄漏或評測集覆蓋不足檢查切分是否按文檔級別補(bǔ)充邊界樣本OOM是我遇到最多的。一開始我以為是GPU顯存不夠排查老半天發(fā)現(xiàn)是某個(gè)代碼片段把中間結(jié)果列表全部積在內(nèi)存里batch的loss都正常但內(nèi)存先爆了。用free -g看一眼系統(tǒng)內(nèi)存能快速區(qū)分是顯存還是內(nèi)存問題。7.2 部署與服務(wù)階段的高頻問題現(xiàn)象常見原因排查思路P99延遲持續(xù)走高并發(fā)排隊(duì)過多或批處理窗口設(shè)置不合理看隊(duì)列長度調(diào)整動態(tài)批處理最大等待時(shí)間GPU顯存使用率只增不減推理框架或服務(wù)代碼內(nèi)存泄漏用監(jiān)控工具觀察顯存曲線最小化復(fù)現(xiàn)定位是框架還是業(yè)務(wù)代碼請求大量返回503隊(duì)列上限觸發(fā)快速失敗放寬隊(duì)列上限或增加實(shí)例檢查限流配置是否誤傷正常用戶修改代碼后推理結(jié)果變了未固定隨機(jī)種子或模型未加載同一檢查點(diǎn)固定PYTHONHASHSEED和隨機(jī)種子核對模型路徑與config服務(wù)重啟后首次請求特別慢模型冷加載上線時(shí)寫預(yù)熱腳本啟動后發(fā)送幾條請求讓模型預(yù)熱再對外服務(wù)部署階段有個(gè)細(xì)節(jié)容易被忽視模型文件的加載路徑。我犯過一次錯(cuò)部署時(shí)從網(wǎng)盤下載模型下載完成度沒有校驗(yàn)結(jié)果服務(wù)用的是一半的權(quán)重文件準(zhǔn)確率低到不可思議還沒有報(bào)錯(cuò)。后來我在所有模型加載環(huán)節(jié)都加了一步校驗(yàn)加載后跑一遍冒煙測試檢查輸出是否符合預(yù)期。這個(gè)習(xí)慣救了我好幾次。7.3 數(shù)據(jù)層面的問題排查數(shù)據(jù)的問題最隱蔽因?yàn)椴粓?bào)錯(cuò)。我發(fā)現(xiàn)過一個(gè)現(xiàn)象模型對英文縮寫理解特別差一開始以為是模型能力問題后來分析是清洗腳本把所有句點(diǎn)都去掉了導(dǎo)致“U.S.A”這種詞被粘連成“USA”含義還算對但“app.v1.2.3”這種版本號被破壞訓(xùn)練樣本全亂了。這類問題只能靠“清洗后人工抽檢”和“數(shù)據(jù)分布統(tǒng)計(jì)”這類預(yù)防機(jī)制出了再查往往為時(shí)已晚。另一個(gè)高發(fā)問題是重復(fù)數(shù)據(jù)。很多文檔的內(nèi)容是重復(fù)粘貼的如果不做去重某些句子在訓(xùn)練集中出現(xiàn)幾十次模型就會嚴(yán)重偏向這些說法對其他同義表達(dá)不敏感。至少做一次MinHash或simhash去重比任何調(diào)參都管用。8. 最后分享兩個(gè)親測有效的習(xí)慣寫到最后說點(diǎn)不太能寫進(jìn)項(xiàng)目匯報(bào)里的體會。第一個(gè)習(xí)慣是把每一步的關(guān)鍵決策和踩坑記錄下來。不是寫API文檔那種而是記錄“為什么當(dāng)時(shí)那么選”“后來發(fā)現(xiàn)有什么問題”“下次怎么做更好”。這種草根筆記看著不起眼但在項(xiàng)目中期回頭查問題時(shí)它的價(jià)值超過任何一本教科書。第二個(gè)習(xí)慣是永遠(yuǎn)從最小閉環(huán)開始。不要一開始就規(guī)劃一個(gè)完美的大系統(tǒng)而是先做一個(gè)丑但通全鏈路的版本10條數(shù)據(jù)、1個(gè)模型、1個(gè)接口、10條評測樣本。跑通之后再一步步把工程化能力加進(jìn)去。所有大的AI工程問題都是在閉環(huán)里逐個(gè)暴露、逐個(gè)解決的。從零到一搭建AI工程確實(shí)不容易但這個(gè)過程建立的工程判斷力和排錯(cuò)能力才是真正的資產(chǎn)。項(xiàng)目會結(jié)束模型會迭代但這些能力會留在這個(gè)團(tuán)隊(duì)的血液里后面的路自然會越走越穩(wěn)。