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