做AI工程的人如果從來沒有從零寫過一次Transformer訓(xùn)練沒有親手調(diào)過Embedding、搭過檢索鏈路那他做的東西本質(zhì)上是在玩盲盒。遇到問題只能靠猜效果不好只能換提示詞模型升級換代就得跟著跑完全沒有主動權(quán)。“ai-engineering-from-scratch”這個項目路線要解決的就是這個問題——把AI工程從黑盒變成白盒從調(diào)用工具變成真正理解工具、改進工具。以我的經(jīng)驗這條路最適合兩類人一類是剛?cè)胄?、想系統(tǒng)建立AI工程知識體系的開發(fā)者另一類是已經(jīng)調(diào)了很久API、但遇到復(fù)雜問題總覺得心里沒底的應(yīng)用工程師。它不會幫你造出GPT-5但能讓你把一條完整的AI系統(tǒng)鏈路——數(shù)據(jù)、模型、檢索、Agent、評估、部署——每個環(huán)節(jié)都講清楚來龍去脈出了問題也知道從哪里下手查。1. 為什么“從零開始”才是AI工程的正路1.1 調(diào)包俠和工程師的區(qū)別往往就隔著一個“重寫”我一直有個觀點能跑通別人搭好的框架和能自己從頭搭一遍是完全不同的兩種能力。前者是“會用”后者是“會造”。在傳統(tǒng)軟件工程里大家可能覺得“會用框架”就夠了但在AI工程這個領(lǐng)域事情變化太快你很難指望一個第三方框架永遠替你兜底。今天你用的向量庫方案明天可能被新的檢索范式替代今天你調(diào)的閉源模型明天可能因為成本、數(shù)據(jù)合規(guī)、效果上限等各種原因要換成開源模型。這時候如果你只懂調(diào)包一切就得推倒重來而如果你理解底層邏輯換的只是實現(xiàn)細(xì)節(jié)。from-scratch路線的價值就在這里它會強迫你去重寫那些看起來“不必要”的東西。比如為了做一個RAG系統(tǒng)你要自己寫文本切分、自己接一個開源的Embedding模型、自己實現(xiàn)向量索引的召回邏輯、自己做重排序甚至自己寫一段大模型推理代碼。這個過程會很痛苦但做完之后你對“檢索為什么不準(zhǔn)”“上下文為什么超限”“回答為什么亂編”這些問題的理解會完全不同。因為你見過每一層是怎么運作的排查問題就不是從現(xiàn)象猜測根因而是順著鏈路直接定位到具體環(huán)節(jié)。我遇到很多從API開發(fā)轉(zhuǎn)過來的朋友一開始覺得“為什么要自己訓(xùn)練模型直接用現(xiàn)成的不行嗎”我的回答是直接用現(xiàn)成模型當(dāng)然行但那不叫AI工程那叫API運維。AI工程的核心是你要能控制效果、控制成本、控制質(zhì)量這三件事沒有任何一個現(xiàn)成模型能替你全部完成。1.2 這個路線解決的核心痛點黑盒恐慌我觀察到一個很有意思的現(xiàn)象那些只調(diào)API的開發(fā)者往往特別害怕模型升級。模型一升級之前的提示詞可能不靈了輸出格式變了效果波動了他們只能被動跟著調(diào)。而那些做過from-scratch訓(xùn)練的開發(fā)者面對模型升級反而比較淡定。為什么因為他們是知道模型內(nèi)部發(fā)生了什么的人。他們知道輸出不穩(wěn)定大概率是采樣參數(shù)問題格式亂了就去結(jié)構(gòu)化輸出解析那里排查效果變差就去評估集上做回歸測試。這種“不慌”的底氣正是這個路線帶給你的最核心的收益。另外一個痛點也特別實際面試和崗位競爭?，F(xiàn)在AI方向的人才密度很高光說“我用過LangChain”已經(jīng)不算優(yōu)勢了因為人人都用過。但如果你能說出“我自己實現(xiàn)過一個簡化的Attention機制”“我給模型做過LoRA微調(diào)并且處理過災(zāi)難性遺忘”“我從零搭過一條包含重排序的RAG鏈路”這背后的信息量是完全不同的。前者說明你消費過工具后者說明你能創(chuàng)造工具。2. 看清全貌AI工程要啃的五大硬骨頭2.1 從數(shù)據(jù)到權(quán)重的模型構(gòu)建很多人以為AI工程就是“訓(xùn)練一個模型”其實模型訓(xùn)練只是中間段。完整的模型工程是數(shù)據(jù)采集 → 數(shù)據(jù)清洗 → 分詞器訓(xùn)練 → 預(yù)訓(xùn)練 → SFT指令微調(diào) → 對齊RLHF/DPO→ 評估 → 上線。任何一個環(huán)節(jié)做得粗糙都會在最終效果上暴雷。在實際從零項目里最容易被低估的是分詞器Tokenization和數(shù)據(jù)處理。我見過有人辛辛苦苦用別人的詞表訓(xùn)練一個中文模型結(jié)果發(fā)現(xiàn)分詞器對中文的支持極差一個字拆成好幾個token訓(xùn)練效率和生成效果都崩了。分詞器必須和語料一起做針對你的領(lǐng)域數(shù)據(jù)統(tǒng)計字節(jié)對頻率這一步不能省。數(shù)據(jù)清洗更是如此很多公開數(shù)據(jù)集里混著重復(fù)文本、HTML標(biāo)簽、莫名其妙的語言亂碼不清干凈模型訓(xùn)練到一半就出現(xiàn)嚴(yán)重過擬合生成的句子都是車轱轆話。預(yù)訓(xùn)練階段的核心是掌握訓(xùn)練節(jié)奏。你的loss曲線應(yīng)該呈現(xiàn)一種平滑下降的趨勢如果出現(xiàn)階梯狀跳水或突然的尖峰通常意味著學(xué)習(xí)率設(shè)置、batch size和數(shù)據(jù)順序有問題。到了SFT階段問題又變成“教什么、怎么教”。我通常把指令數(shù)據(jù)視作一個質(zhì)量遠高于預(yù)訓(xùn)練語料的小數(shù)據(jù)集它不需要太大但必須格式干凈、覆蓋目標(biāo)場景、避免重復(fù)。在這個階段我建議嚴(yán)格限制每條樣本的長度超出上下文窗口的數(shù)據(jù)直接截斷不然訓(xùn)練時長和效果都會收到明顯負(fù)面影響。2.2 RAG鏈路與向量工程RAG是當(dāng)前工程落地最多的方向但它絕不是“文檔切一下向量存起來檢索問答”這么簡單。一條完整的RAG鏈路包括文檔解析 → 清洗 → 分塊 → Embedding模型選型 → 向量索引構(gòu)建 → 召回 → 重排序 → 上下文拼裝 → 生成。我見過很多效果差的RAG問題根本不在模型而在鏈條前端的解析和分塊環(huán)節(jié)。舉一個常見的例子一個PDF文檔里有表格你用普通文本解析器把表格拆成一行一行的碎片然后喂給分割器最后檢索出來的都是殘缺的表格碎片模型再聰明也拼不出正確答案。正確的做法是要么用支持復(fù)雜版式的解析工具保留表格結(jié)構(gòu)要么干脆把表格整體當(dāng)做一個塊來處理。分塊策略同樣大有講究固定長度分塊最省事但會把語義完整的段落攔腰截斷語義分塊效果好但耗時高。工程上比較穩(wěn)的組合是“先按文檔結(jié)構(gòu)粗分再結(jié)合長度限制微調(diào)”既照顧了語義邊界又控制了塊的大小。Embedding模型的選型和檢索效果的關(guān)聯(lián)度經(jīng)常被低估。有些人圖省事直接用默認(rèn)的小模型結(jié)果在專業(yè)領(lǐng)域召回率慘不忍睹。我的經(jīng)驗是至少準(zhǔn)備兩個候選Embedding模型用一套人工標(biāo)注的評測集跑一遍召回率對比再決定用哪個。這一步多做幾小時能避免后續(xù)上線幾個月被用戶罵“檢索不準(zhǔn)”。2.3 Agent與工具調(diào)用Agent方向是過去一年演進最快、也最容易讓人迷失的部分。從純提示詞驅(qū)動的ReAct、到結(jié)構(gòu)化Function Calling、再到復(fù)雜多智能體協(xié)作每一步都在往前走。但從from-scratch的角度看Agent的核心其實不復(fù)雜就三件事規(guī)劃、工具調(diào)用、記憶管理。規(guī)劃對應(yīng)的是“模型如何決定下一步做什么”。最簡單的實現(xiàn)是在prompt里給出一組工具的描述和JSON Schema讓模型輸出一個結(jié)構(gòu)化的“思考行動”片段然后由代碼解析并執(zhí)行。這就是ReAct的基本形態(tài)。工具調(diào)用對應(yīng)“如何把自然語言意圖映射到具體函數(shù)參數(shù)”。這里最關(guān)鍵的細(xì)節(jié)是函數(shù)描述要寫得足夠清晰不要寫“搜索知識庫”而要寫“根據(jù)用戶問題在『產(chǎn)品文檔庫』中用關(guān)鍵詞或語義檢索找相關(guān)信息輸入?yún)?shù)為query字符串”模型看到這種描述才能正確傳參。記憶管理則是最大的隱性工程問題上下文有限必須做摘要、裁剪、優(yōu)先級淘汰這些邏輯全部需要手工實現(xiàn)。我自己的體會是Agent出問題90%出在工具調(diào)用格式不匹配上模型輸出了你想讓它輸出的JSON但包含了一個多余字段或者某個字段類型不對。所以做Agent工程的第一課不是學(xué)什么高深框架而是把“結(jié)構(gòu)化輸出的校驗與糾錯”模塊寫得非常健壯要有模式修正、類型強轉(zhuǎn)、重新請求這樣的兜底邏輯。2.4 評估、可觀測性與數(shù)據(jù)閉環(huán)這條可能是整個from-scratch路線里最勸退新手、但最應(yīng)該被重視的部分。很多人對模型的認(rèn)知只停留在“跑一次、看結(jié)果”完全沒有把質(zhì)量量化、把過程記錄下來的意識。但真正的AI工程比訓(xùn)練本身花更多時間的一定是評估。評估要解決的第一個問題是“什么叫好”。落地場景里不能只看模型給的0到1的滿意度評分要看具體指標(biāo)。答案是結(jié)構(gòu)化抽取類任務(wù)就看字段命中率和格式合法率開放問答類任務(wù)就用LLM-as-Judge讓一個更強的模型打分同時人工抽樣復(fù)核但檢索是單獨的指標(biāo)看召回率、命中位置、重排收益。把這些指標(biāo)匯總成一張離線評測表每次改動模型或prompt就重新跑一遍才能防止“改好一個問題、弄壞三個問題”?？捎^測性是另一個很多人忽略的點。上線之后你的系統(tǒng)每一個請求都會消耗算力產(chǎn)生遲延和成本。如果不對每次請求做鏈路日志記錄一旦效果變差你根本不知道是檢索環(huán)節(jié)沒召回到正確文檔還是模型回答環(huán)節(jié)跑偏了還是prompt模板拼錯了。我建議在RAG鏈路的每個環(huán)節(jié)都埋點檢索耗費多少毫秒、命中了哪些chunk、重排后取了哪些chunk、最終喂給大模型的上下文有多長、首token延遲是多少。這些日志和指標(biāo)是后期優(yōu)化最重要的依據(jù)。2.5 推理優(yōu)化與部署模型訓(xùn)練完、鏈路調(diào)通了下一步是上線。但線上環(huán)境跟本地實驗完全是兩個世界。本地實驗?zāi)阒恍枰尨a跑通線上你必須關(guān)注延遲、吞吐、并發(fā)、成本和穩(wěn)定性。推理優(yōu)化方面最常用的是量化和批處理。一個FP16的7B模型在單張A10上跑顯存勉強夠用但并發(fā)一高就OOM轉(zhuǎn)成INT8或者INT4量化之后顯存占用能降到原來的三分之一到一半吞吐大幅提升但精度會有輕微損失需要實測評估。批處理則是把多個并發(fā)請求拼成一個batch走一次前向計算能顯著提升吞吐但也會增加單個請求的等待時間需要權(quán)衡。部署方案上我個人的建議是能不用復(fù)雜的分布式系統(tǒng)就不用先把單機推理性能壓到極致。一個大模型服務(wù)節(jié)點加一個開源向量庫足以支撐中小規(guī)模的業(yè)務(wù)。等真正遇到瓶頸再往分布式部署遷移也不遲。頻繁更換架構(gòu)反而會引入很多和模型能力無關(guān)的穩(wěn)定性問題。3. 親手復(fù)現(xiàn)一遍從零訓(xùn)練一個真正能說話的小模型3.1 搭建最小訓(xùn)練管線需要的七件事如果你剛接觸from-scratch我建議把目標(biāo)定低一點不要一上來就盯著中文千億大模型先去把一個不超過1億參數(shù)的小模型訓(xùn)練到能輸出連貫句子這個目標(biāo)聽起來不大但足以讓你理解訓(xùn)練全流程。要做的事只有七件選數(shù)據(jù)集一個比較干凈、又是領(lǐng)域相近的文本語料比如英文小說、中文百科的子集都行。第一遍訓(xùn)練盡量用小數(shù)據(jù)控制在幾十MB到幾百MB。“tiny shakespeare”之類的經(jīng)典數(shù)據(jù)集是很好的起點規(guī)模小、文本結(jié)構(gòu)豐富。做分詞器直接在語料上訓(xùn)練一個BPE分詞器詞表大小設(shè)為5000到10000。這一步能讓你直觀感受到詞表大小對訓(xùn)練速度和模型參數(shù)量影響巨大。寫數(shù)據(jù)加載器把原始文本切成固定長度比如256或512個token的訓(xùn)練樣本設(shè)置好batch size和隨機打亂策略。實現(xiàn)模型結(jié)構(gòu)自己寫一個簡化版Transformer包括Embedding層、若干層DecoderBlock每層有多頭自注意力前饋網(wǎng)絡(luò)、LayerNorm和最后的輸出投影。如果嫌麻煩可以在PyTorch里一步步組裝但每一步都要明白它為什么存在。定義損失函數(shù)交叉熵?fù)p失就行關(guān)鍵是理解它是如何衡量“模型預(yù)測下一個token的分布 vs 真實下一個token”之間的差距的。寫訓(xùn)練循環(huán)前向傳播 → 計算損失 → 反向傳播 → 更新參數(shù)。加上學(xué)習(xí)率調(diào)度、梯度裁剪和定期保存checkpoint。寫生成腳本訓(xùn)練完成后寫一個推理采樣函數(shù)用temperature和top-p控制隨機性看看模型是否生成出語法基本正確的句子。這套流程完整跑一遍我對你的建議是別貪多重點是讓訓(xùn)練loss持續(xù)下降并且最終能生成自然語言片段。至于效果多驚艷那是后面的事先練就“控制訓(xùn)練過程”的本事。3.2 調(diào)參記錄我在一張消費級顯卡上跑通的經(jīng)驗我自己的實操參數(shù)可以給你做個參考。數(shù)據(jù)量大概200MB左右的英文小說語料詞表8000模型大概用了6層Decoder、8個注意力頭、隱藏維度512總參數(shù)量不到4000萬。序列長度256batch size我調(diào)到了16條等效一次前向處理的token數(shù)大概是4096。優(yōu)化器用AdamW初始學(xué)習(xí)率3e-4先做了500步線性warmup之后用余弦退火衰減到1e-5。梯度裁剪設(shè)為1.0避免loss出現(xiàn)尖峰炸掉。顯存方面單卡12GB完全夠用。batch size如果更大可以用梯度累積模擬但第一次跑建議不要搞復(fù)雜直接落到一個能裝滿顯存但不會OOM的數(shù)值就好。訓(xùn)練到loss降到2附近生成效果已經(jīng)能看出來明顯的語言結(jié)構(gòu)部分句子語法正確但邏輯跳躍。這個過程大概要三到五個小時取決于顯卡算力。訓(xùn)練過程中有幾點特別容易翻車第一學(xué)習(xí)率設(shè)置過高會出現(xiàn)loss突然飆升到NaN的“爆炸”第二沒有做梯度裁剪長數(shù)據(jù)集訓(xùn)練時會出現(xiàn)偶發(fā)的大梯度尖峰把已經(jīng)訓(xùn)好的參數(shù)沖壞第三隨機種子沒固定導(dǎo)致實驗之間無法橫向?qū)Ρ?。這幾點我都踩過寫在這里算是替你們提前探了雷。3.3 別把微調(diào)當(dāng)成煉丹SFT階段的三類典型坑預(yù)訓(xùn)練完成只代表模型學(xué)會了“說人話”不代表它“聽指令”。SFT階段用指令數(shù)據(jù)讓模型學(xué)會問答但這里坑非常多。第一類坑是數(shù)據(jù)污染和重復(fù)。指令數(shù)據(jù)如果不做去重同一個問題反復(fù)出現(xiàn)模型會把那幾句標(biāo)準(zhǔn)答案背下來遇到其他問法就啞火。我建議去做精確匹配和近似去重把重復(fù)樣本控制到最低比例給其他問題更多學(xué)習(xí)機會。第二類坑是過擬合到指令模板。如果所有指令都長成一個模板樣子模型的泛化能力會很差。訓(xùn)練集里要讓問題表達盡量多樣甚至人工改寫一些同義問法。我見過一個模型你把問題正常寫它回答得很好但問題里多了口語詞或網(wǎng)絡(luò)詞回答質(zhì)量立刻掉一截就是因為訓(xùn)練數(shù)據(jù)太“干凈”、太單一了。第三類坑是災(zāi)難性遺忘。用指令數(shù)據(jù)微調(diào)之后模型原先從預(yù)訓(xùn)練語料學(xué)到的通用語言能力可能會被沖掉。緩解的手段有幾個微調(diào)時混入一些小比例預(yù)訓(xùn)練語料進行聯(lián)合訓(xùn)練第二個是學(xué)習(xí)率不要太大微調(diào)階段一般用預(yù)訓(xùn)練的十分之一甚至更低第三個是做帶正則的LoRA只更新部分參數(shù)能顯著降低遺忘率。這些對策組合使用能幫你保住“底子”的同時學(xué)會“聽話”。4. 用from-scratch思路搭一條生產(chǎn)級RAG4.1 為什么我放棄了“關(guān)鍵詞搜索一步到位”的懶人方案很多人搭RAG的第一版喜歡圖省事文檔全扔進去調(diào)一個現(xiàn)成的檢索庫然后拼到prompt里讓大模型回答。這種方案Demo能跑但效果極不穩(wěn)定因為檢索的召回結(jié)果魚龍混雜真正有用的信息可能排在第三頁被大模型忽略。真正生產(chǎn)級的RAG要做的是“從源頭控制上下文質(zhì)量”而不是寄希望于大模型從垃圾里淘金。我的建議是至少分四級來做第一級是用Embedding做語義召回第二級是關(guān)鍵詞/BM25召回做互補第三級是用重排序模型Cross-Encoder對兩路結(jié)果做融合精排第四級才是把選出來的優(yōu)質(zhì)上下文交給大模型。前三級的目標(biāo)只有一個把最相關(guān)的信息穩(wěn)定地放進有限的上下文窗口里。4.2 分塊和嵌入的工程選型沒有銀彈只有權(quán)衡先說分塊。表格直接給你參考方便你對照業(yè)務(wù)選策略策略適用場景優(yōu)勢風(fēng)險固定長度chunk如512 token格式統(tǒng)一、內(nèi)容偏文本的文檔實現(xiàn)簡單、速度最快切斷語義邊界檢索結(jié)果完整性差按段落/章節(jié)分塊結(jié)構(gòu)化文檔、Markdown/HTML語義完整檢索精準(zhǔn)度高長段落可能超出嵌入模型長度限制語義分塊按句號/主題切混合格式、問答型文檔質(zhì)量最高處理耗時需要額外邏輯執(zhí)行上我建議先用按段落/章節(jié)粗分然后對超長段落用長度限制二次切分。分塊重疊設(shè)成20到50個token可以避免邊界信息丟失。分塊之后要做清洗去掉頁眉頁腳、無意義空行、亂碼字符這些噪音對Embedding的語義表征干擾很大。Embedding模型的選型我用過幾代開源模型之后總結(jié)出的原則是優(yōu)先選專門針對中文或你的業(yè)務(wù)語言進行過優(yōu)化、并且支持較長上下文比如512或1024以上 token的模型其次看維度維度越高表達能力越強但存儲和檢索成本也更高。上線前一定用一組人工標(biāo)注查詢?nèi)y試召回命中率我見過有些號稱很強的通用Embedding模型在垂直領(lǐng)域的效果遠不如一個小而專的模型所以別只看榜單。4.3 召回、精排、上下文壓縮完整配置帶你避坑具體的鏈路配置我按生產(chǎn)環(huán)境參數(shù)舉例說明。假設(shè)知識庫有10萬條文檔分塊Embedding維度768向量庫我用開源的HNSW索引M值設(shè)為16ef_construction設(shè)為200這種配置下召回質(zhì)量和查詢延遲平衡得不錯。查詢來時我同時跑兩路召回一路用Embedding做語義檢索取top20一路用BM25做關(guān)鍵詞檢索取top10。兩個結(jié)果合并去重后送進一個Cross-Encoder重排序模型。這個模型會把每一對查詢候選文檔打一個相關(guān)度分?jǐn)?shù)按分?jǐn)?shù)降序取top5作為最終上下文。重排序的意義在于它彌補了向量檢索對精確關(guān)鍵詞不敏感的缺點把最相關(guān)的幾篇文檔頂?shù)阶钋懊妗崪y下來加了一路重排之后回答的準(zhǔn)確率能提高10到20個百分點這在RAG鏈路里是非常大的收益了。最后一步是上下文拼裝。我的建議是做一個“prompt組裝器”而不是直接把文檔瞎拼進去。組裝器要做的事包括截斷過長的文檔摘要、給每條文檔加元信息來源文件名、章節(jié)路徑、刪掉明顯冗余的重復(fù)片段以及在上下文太長時做優(yōu)先級裁剪。這一層做得是否細(xì)致會直觀反映在回答穩(wěn)定性和可追溯性上。5. 實戰(zhàn)中經(jīng)常翻車的11個問題速查5.1 模型不收斂的四種死因與排查方向模型訓(xùn)練不收斂90%以上逃不出四個原因。第一學(xué)習(xí)率設(shè)置不當(dāng)過高導(dǎo)致震蕩甚至發(fā)散過低導(dǎo)致長時間停滯排查方法是觀察loss曲線上是不是出現(xiàn)鋸齒狀波動如果是就把學(xué)習(xí)率調(diào)低兩到三倍。第二數(shù)據(jù)問題比如標(biāo)簽錯亂、數(shù)據(jù)分布方差過大排查方法是抽樣看數(shù)據(jù)確認(rèn)輸入輸出對齊。第三參數(shù)初始化或模型結(jié)構(gòu)錯誤特別是LayerNorm位置、殘差連接這些細(xì)節(jié)排查方法是先跑一個極小的batch看能不能實現(xiàn)過擬合如果連一個batch都過擬合不了說明模型實現(xiàn)有問題。第四loss計算或掩碼錯誤導(dǎo)致某些位置被錯誤計算排查方法是寫一個極小的人工樣本手動推導(dǎo)出期望loss再和代碼輸出比對。5.2 檢索不準(zhǔn)、回答亂編的排查路線如果你的RAG系統(tǒng)效果差第一步先區(qū)分問題出在檢索還是生成方法很簡單把每次實際檢索到的chunk打印出來看如果這些chunk本身就不相關(guān)那么問題在檢索側(cè)如果chunk相關(guān)但模型仍然答錯那問題在生成側(cè)或prompt組裝側(cè)。檢索側(cè)繼續(xù)排查先看Embedding模型是不是和領(lǐng)域匹配再看分塊策略是否合理最后看召回數(shù)量是否足夠。我遇到過最典型的問題是文檔里信息很全但被切到了不同的chunk里兩者都不完整導(dǎo)致檢索出來每個都有一點相關(guān)但都不夠。生成側(cè)則重點排查提示詞是否說得足夠具體比如要讓模型“只能依據(jù)給定片段回答如果片段不足以回答則明確說不知道”這句話聽起來簡單但能顯著減少幻覺輸出。最后別忘了加一個可觀測層把每次請求的檢索chunk和模型輸出都打點記下來不然排查效率會非常低。5.3 部署性能與成本失控的隱蔽項很多人評估部署成本只看模型顯存大小這是一個大誤區(qū)。實際成本的大頭往往是并發(fā)吞吐、KV Cache、長上下文的算力消耗。一個支持4K上下文和32K上下文的模型推理成本可能是數(shù)倍差異每多一個并發(fā)請求延遲和顯存都會有非線性增長。部署層面最常見的坑有四個一是幾十個并發(fā)上來之后GPU顯存被KV Cache打爆二是沒有做請求排隊和限流導(dǎo)致壓力增大時服務(wù)整體抖動甚至雪崩三是量化版本沒有經(jīng)過評測集驗證上線才發(fā)現(xiàn)效果嚴(yán)重下滑四是日志和監(jiān)控缺失等到用戶反饋大量異常才后知后覺。我的建議是上線前先壓測用腳本模擬線上流量并發(fā)請求觀察延遲、吞吐和錯誤率把瓶頸找出來再調(diào)優(yōu)。6. 學(xué)習(xí)節(jié)奏與最后的經(jīng)驗之談6.1 一份可執(zhí)行的三個月實操路線我對想要系統(tǒng)走完這條路線的人提一個時間規(guī)劃你可以根據(jù)自己的基礎(chǔ)壓縮或拉長第1個月專攻模型搭建與訓(xùn)練。目標(biāo)就是跑通上面第3章的小模型訓(xùn)練并且能夠熟練調(diào)整關(guān)鍵超參數(shù)理解loss曲線的含義。第2個月主攻RAG與評估體系。搭一條至少包含召回、重排、生成三段的RAG鏈路同時建立一套離線評測集學(xué)會用指標(biāo)來衡量改動效果。第3個月綜合Agent、部署與優(yōu)化。把之前的小模型或開源模型部署起來做一個帶工具調(diào)用的Agent演示然后做一次量化、性能壓測和成本估算。這個節(jié)奏的好處是每個月都有看得見的成果不會陷入“學(xué)了很久但什么都沒做出來”的焦慮感。如果你本身有工程基礎(chǔ)時間可以壓縮但我不建議跳步驟。尤其不要跳過“從零訓(xùn)練模型”那一步它是理解后面一切工程的基石。6.2 寫在最后幾點掏心窩子的經(jīng)驗這條路我完整走過一遍最大的收獲不是“我會訓(xùn)練模型了”而是我建立了一套判斷問題的直覺。現(xiàn)在項目里模型效果不行我不會先懷疑模型不行而是會先檢查數(shù)據(jù)、檢查評估集、檢查檢索鏈路。90%的工程問題其實都出在“給你看的那一層”之外。另一個經(jīng)驗是不要試圖一次做完所有事。我見過太多人一開始就想做一個完美支持長上下文、多Agent協(xié)作、超大規(guī)模知識庫的系統(tǒng)結(jié)果項目半年都沒上線。真正務(wù)實的做法是先把一條最小閉環(huán)跑通哪怕效果糙一點再基于評估數(shù)據(jù)逐步優(yōu)化。工程不是炫技是讓系統(tǒng)在真實環(huán)境下穩(wěn)定產(chǎn)出價值。最后再分享一個小技巧務(wù)必養(yǎng)成記錄實驗的習(xí)慣。每一次調(diào)參、每一個prompt改動、每一版檢索鏈路更新都記錄下評估指標(biāo)的變化。這個習(xí)慣前期看起來很費時間但當(dāng)你積累了幾十條實驗記錄之后你會發(fā)現(xiàn)你對整個系統(tǒng)的理解會變得異常清晰別人問你效果為什么提升你能直接說出是哪個環(huán)節(jié)的哪個改動起了作用。這種掌控感就是從from-scratch一路走下來最值得的東西。