做垂直領(lǐng)域大模型這件事我不打算繞彎子。過去一年多我陸續(xù)參與幾條行業(yè)線的落地項目覆蓋零售、保險、醫(yī)療、制造親眼看著不少團隊把“訓(xùn)練大模型”搞成一場燒錢大賽——模型訓(xùn)完了demo演示很驚艷上生產(chǎn)就崩崩完之后還不知道問題出在數(shù)據(jù)、參數(shù)還是評測上。所以這篇文章我想把從零開始建設(shè)垂直領(lǐng)域大模型的完整路徑寫清楚先講怎么判斷一個場景到底要不要做、怎么規(guī)劃路線再講技術(shù)架構(gòu)里的關(guān)鍵細節(jié)最后用三個行業(yè)案例把實戰(zhàn)場景完整復(fù)盤一遍。適合正在做技術(shù)選型的負責人、準備轉(zhuǎn)崗做行業(yè)大模型應(yīng)用的技術(shù)同學(xué)也適合想搞清楚“行業(yè)大模型到底是怎么搞出來的”的產(chǎn)品和運營同學(xué)。1. 先搞清楚垂直領(lǐng)域大模型到底解決什么問題1.1 通用模型的知識短板不是“不夠多”而是“不夠準”通用大模型的訓(xùn)練語料基本來自公開互聯(lián)網(wǎng)行業(yè)內(nèi)部的規(guī)章制度、業(yè)務(wù)口徑、歷史經(jīng)驗?zāi)Ｐ透緵]機會學(xué)到。行業(yè)里我們常講一個詞叫“專業(yè)可靠性”保險行業(yè)要的是條款引用準確醫(yī)療要的是術(shù)語表述嚴謹制造要的是故障編碼統(tǒng)一。表面看是“知識不夠”本質(zhì)是“表達體系和判定標準不對”。我給你舉一個實際場景。你在通用大模型里問“保險合同里投保人對被保險人具有保險利益的情況有哪些”它能給你答出一個大致框架看起來邏輯通順。但如果你把某家公司一份帶補充條款的合同扔進去讓它判斷一個具體案例是否屬于可保利益它就很難給出適用你業(yè)務(wù)規(guī)則的答案。這不是模型笨是因為它的訓(xùn)練數(shù)據(jù)里根本沒有你這套業(yè)務(wù)規(guī)則、術(shù)語體系和判定邏輯。垂直領(lǐng)域大模型做的就是把“通用的通才”訓(xùn)練成“某個行當?shù)男屑摇薄?.2 垂直化改造的三條路線提示工程、檢索增強、參數(shù)微調(diào)很多第一次接觸的人以為“做垂直大模型”就等于“微調(diào)”其實不是。行業(yè)落地上通常有三條彼此配合的技術(shù)路線它們的本質(zhì)區(qū)別非常大。路線改的是什么優(yōu)勢短板典型場景提示工程輸入輸出的組織方式零訓(xùn)練成本、見效快不引入新知識復(fù)雜任務(wù)不穩(wěn)定簡單抽取、格式轉(zhuǎn)換、少量few-shot問答檢索增強RAG回答時的信息來源知識可更新、答案可溯源表達風格難控制復(fù)雜推理仍受限知識庫問答、政策咨詢、條款查詢參數(shù)微調(diào)模型權(quán)重本身輸出風格穩(wěn)定、術(shù)語準確、格式可控成本高、知識更新難、有遺忘風險結(jié)構(gòu)化輸出、領(lǐng)域風格生成、專用分類我的經(jīng)驗是這三條路線不是互斥的很多跑得穩(wěn)的系統(tǒng)是“RAG提供知識 微調(diào)控制表達”。你可以這么理解RAG管“知不知道”微調(diào)管“會不會說”。知識缺口靠檢索補表達缺口靠訓(xùn)練補。如果只做RAG模型可能找到了答案但表達得不像行內(nèi)人如果只做微調(diào)行業(yè)知識更新一次就要重新訓(xùn)練一次成本扛不住。1.3 什么情況下你根本不需要做垂直大模型我見過太多團隊把“自建垂直大模型”當成政治任務(wù)做完才發(fā)現(xiàn)投入產(chǎn)出比很低。這里說幾個“不該做”的判斷標準。第一如果你的場景本質(zhì)是“從現(xiàn)有文檔里找答案”而且用戶能接受“檢索后閱讀”這種交互那RAG加提示工程就夠了完全不用訓(xùn)練。比如內(nèi)部政策問答、說明書答疑這些場景用現(xiàn)成的通用模型API加一個向量數(shù)據(jù)庫就能達到80分。第二業(yè)務(wù)數(shù)據(jù)撐不起來。做指令微調(diào)我的底線是至少一萬條高質(zhì)量樣本。如果只有三五千條模型訓(xùn)練完之后大概率只是“背下這些數(shù)據(jù)”換個說法就不行還不如直接用提示工程。第三業(yè)務(wù)方說不清楚“什么算答得好”。如果沒人能定義輸出格式、正確標準、邊界情況怎么處理那訓(xùn)練出來的模型也沒法驗收。我建議在動工之前先讓業(yè)務(wù)方寫十條真實問題的“標準答案”再來討論要不要做。第四預(yù)算撐不住。一次像樣的微調(diào)訓(xùn)練成本用云GPU跑折算下來幾千到幾萬塊不稀奇全量微調(diào)一次幾十萬也很正常。如果你的需求用API調(diào)用一年都花不到這個數(shù)那別自建。2. 建設(shè)路徑從0到1的五階段路線圖2.1 階段一業(yè)務(wù)目標與可行性評估第一步不是選模型而是把業(yè)務(wù)問題翻譯成技術(shù)問題。你需要回答四件事這個模型要替代或輔助什么任務(wù)在這之前人工是怎么完成的、耗時多少、錯誤率多少上線之后準確率達到多少才敢用數(shù)據(jù)資產(chǎn)在誰手里能不能拿來訓(xùn)練合規(guī)上有沒有障礙這個階段最重要的動作是做一個PoC用小成本驗證方向。我的習慣是拿現(xiàn)成的通用大模型API跑20到30個真實業(yè)務(wù)case讓業(yè)務(wù)方打分看差距到底在哪里。如果通用模型配合提示詞已經(jīng)能解決八成問題那你需要的只是RAG不是微調(diào)。如果業(yè)務(wù)方看了結(jié)果直搖頭你再把badcase整理出來作為后面建設(shè)數(shù)據(jù)集和評測集的起點。這一步經(jīng)常被跳過代價很大。我曾經(jīng)接手過一個項目團隊沒做PoC直接買卡開訓(xùn)兩個月后模型效果達不到上線標準回來補數(shù)據(jù)前面訓(xùn)練的算力錢基本白扔。一次PoC最多幾天時間換來的是真實的基線數(shù)字這筆賬非常劃算。2.2 階段二數(shù)據(jù)資產(chǎn)盤點與清洗數(shù)據(jù)是垂直大模型的天花板。模型訓(xùn)練只是把數(shù)據(jù)里的規(guī)律學(xué)出來數(shù)據(jù)里沒有的東西模型不可能憑空長出來。盤點數(shù)據(jù)時我習慣按四個來源分類內(nèi)部知識庫和制度文檔、歷史問答和工單記錄、結(jié)構(gòu)化業(yè)務(wù)數(shù)據(jù)、外部公開行業(yè)資料。清洗是重活也是最容易被低估的環(huán)節(jié)。至少要做四件事去重大量重復(fù)樣本會讓模型過度學(xué)習某一種表達隱私脫敏去掉個人信息、手機號、身份證號尤其是醫(yī)療金融場景合規(guī)紅線不能碰格式統(tǒng)一把PDF、掃描件、表格統(tǒng)一成純文本編碼混亂的要處理低質(zhì)過濾太短的、亂碼的、純廣告的樣本直接扔掉。更關(guān)鍵的是把業(yè)務(wù)語料變成模型能學(xué)的“指令-回答”結(jié)構(gòu)。FAQ就轉(zhuǎn)成問題答案對操作手冊可以拆成步驟問答歷史工單可以整理成“問題描述處理結(jié)果”的樣本報告文書可以轉(zhuǎn)成“原文結(jié)構(gòu)化字段”的抽取樣本。數(shù)據(jù)量參考值我放在這里簡單分類任務(wù)幾千條就能起步開放域問答建議至少一萬條涉及復(fù)雜推理和多種任務(wù)類型的十萬條才算充裕。清洗完之后一定要做一次人工抽檢。我堅持每次訓(xùn)練前隨機抽兩百條數(shù)據(jù)自己過一遍再放進訓(xùn)練集。這個土辦法看著慢實際是效率最高的操作它能攔住大量格式錯亂、標注錯誤、隱私遺漏的問題比訓(xùn)練完再排查省太多時間。2.3 階段三基座模型選型與合規(guī)確認選基座模型我通?？此膫€維度按優(yōu)先級排序語言適配度、推理能力、開源與商用授權(quán)、社區(qū)生態(tài)。中文行業(yè)場景里對中文語料支持不好的基座后面會吃很多苦頭要花額外數(shù)據(jù)量去補語言能力推理能力決定模型能不能處理復(fù)雜邏輯行業(yè)任務(wù)經(jīng)常需要多步判斷不能只看參數(shù)大小。模型規(guī)模怎么選我的經(jīng)驗七B左右的輕量模型足夠應(yīng)付分類、抽取、格式化輸出這類任務(wù)部署成本低、延時短十三B到三十四B適合復(fù)雜問答、長文檔分析和多輪對話如果你的預(yù)算充足、數(shù)據(jù)合規(guī)允許出域直接用主流閉源大模型的API做微調(diào)也不是不行但要注意數(shù)據(jù)外送和成本控制。合規(guī)問題我在這一步就拉響警報。開源不等于可以隨便商用每個模型都有自己的授權(quán)協(xié)議動手之前必須確認商用許可數(shù)據(jù)是否能出域涉密涉隱私的數(shù)據(jù)絕不允許送到外部API行業(yè)監(jiān)管要求也要提前調(diào)研比如金融、醫(yī)療領(lǐng)域?qū)I輔助決策普遍有更嚴格的管理要求。選型報告里我永遠把合規(guī)清單單獨列一頁因為這個環(huán)節(jié)出事不是返工的問題是法律風險的問題。2.4 階段四訓(xùn)練、評測與迭代閉環(huán)訓(xùn)練本身不是一次性的動作而是一個閉環(huán)先跑基線再訓(xùn)練再評測再分析badcase改進數(shù)據(jù)重新訓(xùn)練?；€就是微調(diào)之前用基座模型在評測集上跑一遍的結(jié)果記錄所有badcase。這一步的價值在于給你一個“不訓(xùn)練的參照系”。很多時候你以為模型效果差其實通用模型更差那說明建設(shè)方向是對的反過來如果通用模型已經(jīng)不錯了你要考慮的不是再訓(xùn)一個而是用工程手段補短板。評測集是最容易被糊弄的地方我的要求是三條固定、業(yè)務(wù)方認可、覆蓋典型場景。評測集不能邊做邊改否則分數(shù)不斷變化無法判斷迭代效果評測集必須由業(yè)務(wù)方參與定義不能是純技術(shù)團隊自嗨內(nèi)容上常見場景占七成邊界和疑難場景占三成全是簡單題測出來的高分沒有意義。還有一個細節(jié)評測集不能和訓(xùn)練集有重疊。有人把訓(xùn)練數(shù)據(jù)抽一部分當評測集測出來分數(shù)虛高上線就露餡。這就是典型的數(shù)據(jù)泄漏我見過不止一次。2.5 階段五工程化部署與監(jiān)控模型訓(xùn)練完了事情才剛做了一半。部署環(huán)節(jié)有三個關(guān)鍵動作推理加速包括量化、批處理、流式輸出用這些手段把延遲和成本壓下來服務(wù)化封裝把模型包裝成標準API定義好輸入輸出格式、錯誤碼、超時策略方便業(yè)務(wù)系統(tǒng)對接監(jiān)控體系至少要盯延遲、token消耗、調(diào)用失敗率、badcase回流四個指標。很多團隊做到“API能調(diào)通”就認為大功告成這是大錯特錯。上線之后模型在真實流量里的表現(xiàn)幾乎一定會和評測集有差異。我的做法是上線第一周每天抽聽線上badcase后面每周固定抽評一次把問題追加到數(shù)據(jù)池攢夠一批就做一輪增量微調(diào)或RAG知識更新。沒有這個回流閉環(huán)系統(tǒng)會隨著業(yè)務(wù)變化逐漸老化上線半年之后效果越來越差最后變成沒人敢用的擺設(shè)。3. 技術(shù)架構(gòu)與核心細節(jié)微調(diào)實操要點3.1 訓(xùn)練數(shù)據(jù)格式把業(yè)務(wù)語料變成模型能學(xué)的樣子準備訓(xùn)練數(shù)據(jù)不是寫一堆文本丟進去就行格式不統(tǒng)一損失函數(shù)根本不知道怎么算。指令微調(diào)最常用的是“指令-輸入-輸出”這種結(jié)構(gòu)把一條業(yè)務(wù)任務(wù)拆成三個字段。多輪對話場景則用“系統(tǒng)-用戶-助手”的結(jié)構(gòu)系統(tǒng)消息里固定角色和輸出風格。單輪指令格式大致長這樣{ instruction: 根據(jù)以下保險合同條款判斷該理賠申請是否屬于免責范圍, input: 客戶投保意外險駕駛機動車時發(fā)生單方事故導(dǎo)致骨折。保單免責條款寫明被保險人酒后駕車、無有效駕駛證駕駛或駕駛無有效行駛證的機動車期間發(fā)生的事故不在保障范圍內(nèi)。, output: 根據(jù)保險合同免責條款第2.3條該客戶駕駛無有效行駛證車輛期間發(fā)生事故屬于免責范圍理賠申請應(yīng)不予賠付。 }多輪對話格式則要求保持上下文連貫不能只給一對問答就結(jié)束。系統(tǒng)提示詞在行業(yè)場景里特別重要它相當于給模型立規(guī)矩。比如醫(yī)療場景系統(tǒng)提示詞就寫“你是某醫(yī)療機構(gòu)的病歷結(jié)構(gòu)化助手只輸出符合標準字段定義的JSON不輸出任何額外解釋”這樣模型在生成時天然傾向于遵循格式約束。構(gòu)建訓(xùn)練樣本的時候有幾個細節(jié)我反復(fù)強調(diào)樣本之間的風格要一致不能一會兒長篇大論一會兒幾個字答案必須是正確的寧可少做樣本也不要產(chǎn)出帶錯誤的答案每條樣本最好加上“這道題在業(yè)務(wù)上是什么場景”方便后面復(fù)盤。3.2 微調(diào)方式選型全量、LoRA、QLoRA怎么選微調(diào)不是只有“把全部參數(shù)訓(xùn)練一遍”這一種方式。現(xiàn)在行業(yè)里常用的有三種成本差一個數(shù)量級。方式更新參數(shù)顯存需求效果適用場景全量微調(diào)所有參數(shù)高上限最高數(shù)據(jù)量大、算力充足、任務(wù)復(fù)雜LoRA低秩增量矩陣中接近全量絕大多數(shù)行業(yè)項目的主力選擇QLoRA低秩增量量化基座低略遜于LoRA資源緊張、單卡微調(diào)LoRA的原理我用一個比喻講全量微調(diào)相當于把整本書重新謄一遍來糾錯LoRA則是在書后附一張勘誤表。原始權(quán)重保持不變旁邊訓(xùn)練一個低秩矩陣作為增量訓(xùn)練量通常只占全部參數(shù)的1%到2%但已經(jīng)足夠覆蓋常見的表達習慣修正和任務(wù)適配。QLoRA更進一步把基座模型量化到4bit精度再跑LoRA單張消費級顯卡就能微調(diào)幾十億參數(shù)的模型。我的選型建議比較直接團隊資源有限、數(shù)據(jù)量在十萬以內(nèi)、任務(wù)目標是“讓模型掌握行業(yè)術(shù)語和輸出格式”首選QLoRA或LoRA。全量微調(diào)只有在數(shù)據(jù)規(guī)模很大、任務(wù)復(fù)雜度很高、團隊又有充足算力的情況下才值得考慮真正常用的場景極少。很多團隊動不動就上全量微調(diào)純屬資源浪費。3.3 關(guān)鍵超參數(shù)與經(jīng)驗值超參數(shù)這東西不同基座模型、不同數(shù)據(jù)質(zhì)量最優(yōu)點都不一樣但行業(yè)里有幾組經(jīng)驗值可以當起點我在多個項目里實測下來基本靠譜。學(xué)習率是最先要檢查的超參數(shù)。全量微調(diào)一般用1e-5到2e-5LoRA可以用高一個數(shù)量級通常1e-4到2e-4。學(xué)習率太高loss會劇烈震蕩甚至發(fā)散太低模型學(xué)不動訓(xùn)練半天跟沒訓(xùn)一樣。批次大小不要看單卡batch要看有效的全局batch。我習慣用梯度累積把有效batch size做到128到256這樣訓(xùn)練更穩(wěn)定。epoch建議控制在2到3輪數(shù)據(jù)質(zhì)量很高可以只跑一輪跑太多輪很容易過擬合模型開始照著訓(xùn)練數(shù)據(jù)“背答案”稍微換個問法就廢。序列長度要根據(jù)領(lǐng)域文檔的平均長度來定常用2048或4096。這里有取舍序列越長一次能看到的信息越多但顯存和訓(xùn)練時間漲得也快。warmup比例給5%到10%權(quán)重衰減0.01到0.1這些是常規(guī)安全值。LoRA的rank怎么選我的經(jīng)驗分類抽取這類簡單任務(wù)rank給8到16就夠復(fù)雜生成和長文檔任務(wù)rank給32到64。rank不是越大越好在數(shù)據(jù)量有限的時候rank太大反而會引入噪聲訓(xùn)練更慢還容易過擬合。3.4 評測體系別用BLEU自欺欺人評測是垂直大模型項目里最容易被技術(shù)團隊自己騙自己的環(huán)節(jié)。很多人習慣用BLEU、ROUGE這類自動指標但生成式任務(wù)里這些指標和“用戶體驗”的相關(guān)性很低。模型完全可能輸出一段流暢但關(guān)鍵點全錯的回答而BLEU分數(shù)還挺高因為這些指標只衡量字面重合度不衡量語義正確性。我的評測方案分三層。第一層是規(guī)則和關(guān)鍵信息匹配適合抽取、分類、格式化輸出任務(wù)比如合同要素抽取要求的那些字段直接用精確匹配查有沒有抽對。第二層是強模型當裁判讓能力更強的模型當評分員按給定維度打分。這樣做效率高但要注意打分穩(wěn)定性同一個輸出換個表達可能要測多次取均值。第三層是人工評估這是最終拍板的標準業(yè)務(wù)方每周固定抽檢一批真實badcase按業(yè)務(wù)標準打標簽。評測結(jié)果需要形成閉環(huán)。我建過一個簡單的badcase管理表每條badcase記錄輸入、輸出、錯誤類型、來源場景然后定期反推是數(shù)據(jù)問題還是訓(xùn)練問題。數(shù)據(jù)問題就去補同類型樣本訓(xùn)練問題再調(diào)參數(shù)。沒有這種“評測-數(shù)據(jù)-模型”三閉環(huán)你永遠只能靠感覺調(diào)模型。4. 行業(yè)應(yīng)用實戰(zhàn)三個案例全流程拆解4.1 案例一保險理賠條款問答助手某個財險公司場景理賠員每天要查幾十份條款文檔線上客戶問詢也經(jīng)常要求理賠口徑統(tǒng)一。原來的流程是人工翻PDF單次查詢平均十五分鐘遇到少見案例可能要更久。技術(shù)方案我定為兩步先用RAG解決知識檢索問題把三千份條款文檔切塊入向量庫讓模型在回答前先檢索相關(guān)內(nèi)容再用指令微調(diào)解決表達問題讓模型學(xué)會“先引用條款、再給結(jié)論”的固定輸出格式。數(shù)據(jù)建設(shè)是重頭。我們從歷史工單里整理出兩萬對“客戶提問-坐席答復(fù)”又讓資深理賠專家重寫了其中三千條標準答案保證答案口徑正確。微調(diào)用LoRA跑了三輪效果不錯。上線后檢索命中率從67%提到89%單次查詢時間從十五分鐘降到三十秒以內(nèi)。這個項目踩過的坑很有代表性。條款文檔里有大量掃描件OCR識別質(zhì)量差很多章節(jié)標題識別成亂碼檢索時經(jīng)常漏掉關(guān)鍵內(nèi)容。后來我們改了方案給每個文檔建“章節(jié)標題正文”的雙層索引標題識別準確但正文模糊也能靠標題把候選段落撈出來。另外條款編號在各文件里寫法不統(tǒng)一有的叫“2.3條”有的叫“第2.3節(jié)”我們做了標準化映射才解決。4.2 案例二醫(yī)療機構(gòu)影像報告結(jié)構(gòu)化某醫(yī)療機構(gòu)想把放射科報告里的關(guān)鍵信息自動提取成結(jié)構(gòu)化字段比如病灶位置、大小、形態(tài)描述、結(jié)論意見。原來靠錄入員手工填表工作量大且容易漏項。這里我沒選RAG原因是報告結(jié)構(gòu)化的核心是輸出格式和術(shù)語理解知識都在文本本身里不需要外部知識庫。方案定為QLoRA微調(diào)直接讓模型把一段非結(jié)構(gòu)化報告轉(zhuǎn)成固定JSON結(jié)構(gòu)。數(shù)據(jù)準備花了比訓(xùn)練更多的時間。三千份脫敏報告由醫(yī)生團隊參與制定字段定義和標注規(guī)范再逐份標注。訓(xùn)練之后關(guān)鍵字段抽取F1從通用模型的78%提升到92%。上線前我們加了schema校驗?zāi)Ｐ蜕傻腏SON先做字段合法性檢查字段名不匹配或缺失就觸發(fā)兜底邏輯不允許臟數(shù)據(jù)直接進系統(tǒng)。踩坑的經(jīng)驗有兩條。第一是標注一致性兩位醫(yī)生對同一影像的描述用詞不同導(dǎo)致標注標準漂移模型一會兒學(xué)A風格一會兒學(xué)B風格。解決辦法是先花一周定標注規(guī)范做標注一致性測試通過后再批量標注。第二是合規(guī)醫(yī)療數(shù)據(jù)必須走脫敏和審批流程這個環(huán)節(jié)一點不能省我們在技術(shù)方案里就預(yù)留了字段級別的隱私保護。4.3 案例三制造企業(yè)維修工單智能分揀某制造企業(yè)每天收到上百張設(shè)備維修工單人工分揀到機械、電氣、液壓等不同維修組分錯一次維修周期就延長一天。這個場景本質(zhì)是分類任務(wù)加少量要素抽取不需要生成太多內(nèi)容。方案是輕量微調(diào)直接用小規(guī)模基座模型做故障類型分類同時抽取設(shè)備編號和故障部位。數(shù)據(jù)來自兩萬張歷史工單但我們先做了文本標準化工單口語化嚴重錯別字、縮寫隨處可見“電柜跳閘”寫成“電貴跳軋”直接拿去訓(xùn)練效果很差。先做錯別字糾正、縮寫展開、統(tǒng)一術(shù)語映射數(shù)據(jù)質(zhì)量上來之后再送訓(xùn)練。訓(xùn)練后分類準確率從人工標準下的78%提升到95%分揀時效從平均四十分鐘縮到秒級。這個項目給我的體會是不是所有場景都需要大模型但長尾表達復(fù)雜的分類任務(wù)確實比傳統(tǒng)規(guī)則引擎魯棒得多傳統(tǒng)關(guān)鍵詞匹配遇到口語化表達就崩潰微調(diào)模型能泛化到?jīng)]見過的說法。最大的坑是標簽體系。一開始工程部給的故障類型有四十幾種很多類型在語義上高度重疊模型怎么訓(xùn)都分不清。后來拉著維修組逐條梳理把類別合并成十二個大類并明確每個類型的判定邊界分類效果立刻上來了。標簽體系不穩(wěn)定模型不可能穩(wěn)定。5. 常見問題與排查技巧實錄5.1 訓(xùn)練階段的問題速查訓(xùn)練不收斂是最容易讓新手崩潰的問題?？吹絣oss不掉先別急著調(diào)參按順序排查第一條樣本格式對不對字段有沒有放錯第二條學(xué)習率是不是過高loss曲線如果一開始就劇烈震蕩大概率是學(xué)習率問題第三條數(shù)據(jù)質(zhì)量怎么樣有沒有混入大量亂碼或噪聲樣本。輸出變成亂碼是另一個高頻現(xiàn)象。我遇到過最典型的情況是訓(xùn)練數(shù)據(jù)里混入了OCR錯誤文本模型學(xué)著學(xué)著開始輸出生僻字和亂碼。排查方法是隨機抽兩百條訓(xùn)練樣本人工過一遍大概率能發(fā)現(xiàn)源頭。顯存不夠用也很常見處理思路是降低序列長度、調(diào)小batch size、用梯度累積實在不行換QLoRA相當于把模型“壓縮”了以后再微調(diào)?，F(xiàn)象可能原因排查與解決loss不降數(shù)據(jù)格式錯誤、學(xué)習率不合適檢查樣本結(jié)構(gòu)、調(diào)低學(xué)習率輸出亂碼訓(xùn)練數(shù)據(jù)里有噪聲、學(xué)習率過高抽檢樣本、降低學(xué)習率顯存溢出序列太長、batch太大縮短序列、調(diào)小batch、梯度累積訓(xùn)練很快但沒效果數(shù)據(jù)量太小或重復(fù)數(shù)據(jù)太多擴充數(shù)據(jù)、全量去重5.2 效果層面的問題速查災(zāi)難性遺忘是垂直大模型項目里最典型的副作用。模型學(xué)會了行業(yè)術(shù)語但通用能力下降連基本的語法和常識都開始出錯。原因通常是領(lǐng)域數(shù)據(jù)占比太高訓(xùn)練時把通用知識“擠掉”了。緩解手段三個訓(xùn)練數(shù)據(jù)里混合20%到30%的通用數(shù)據(jù)、降低學(xué)習率、少跑幾輪epoch用LoRA也能大幅緩解這個問題?；糜X問題要單獨說。很多團隊發(fā)現(xiàn)領(lǐng)域模型比通用模型更能一本正經(jīng)地胡說八道原因之一是訓(xùn)練數(shù)據(jù)里全是“標準答案”模型形成了“必須回答”的慣性。我的做法是在數(shù)據(jù)里加入足量的拒答樣本讓模型遇到超出范圍的問題時學(xué)會說“抱歉該問題超出我的知識范圍”同時結(jié)合RAG要求輸出必須引用檢索到的來源評測時單獨統(tǒng)計“無依據(jù)回答”的比例作為不可逾越的紅線。效果不好還有一個隱蔽原因數(shù)據(jù)泄漏。如果評測集里有訓(xùn)練數(shù)據(jù)的影子分數(shù)會虛高上線就露餡。建議訓(xùn)練前用去重工具把訓(xùn)練集和評測集之間的重復(fù)樣本清干凈再測才算數(shù)。5.3 部署與成本的實際問題推理慢是上線后最直接的體感問題。處理手段有三板斧量化把模型權(quán)重降到INT8甚至INT4速度提升明顯且效果損失可控批處理把同類型請求攢一批一起算吞吐量成倍提升流式輸出讓用戶體驗上感覺更快實際延遲改善不大但滿意度明顯提升。如果做完這些還是慢就要考慮換更小的基座模型畢竟行業(yè)任務(wù)里很多場景并不需要超大模型。成本失控是項目被砍的頭號原因。我的建議是做預(yù)算時把賬算透訓(xùn)練一次的成本包括GPU租賃、人力、數(shù)據(jù)標注和一年API調(diào)用費用放在同一張表里對比。如果訓(xùn)練成本比調(diào)用API高出太多就應(yīng)該回到RAG路線。另外連續(xù)三輪迭代后badcase數(shù)量減少不明顯說明模型已經(jīng)到這個方案的瓶頸了這時候應(yīng)該回頭改數(shù)據(jù)或者換思路而不是繼續(xù)燒錢調(diào)參。5.4 三條獨家心得第一數(shù)據(jù)質(zhì)量永遠是第一優(yōu)先級。模型是數(shù)據(jù)的鏡子壞數(shù)據(jù)會把錯誤的學(xué)習固化進去而且訓(xùn)練結(jié)束后很難通過調(diào)參救回來。我見過太多團隊把時間花在調(diào)學(xué)習率上卻不愿意花兩天時間清理訓(xùn)練集里的OCR亂碼。第二RAG和微調(diào)是互補關(guān)系不是競爭關(guān)系。行業(yè)知識日新月異靠微調(diào)更新知識既慢又貴行業(yè)表達風格相對穩(wěn)定靠RAG解決表達問題又力不從心。正確姿勢是讓RAG扛住知識層讓微調(diào)穩(wěn)住表達層。第三上線才是真正的開始。沒有badcase回流機制的系統(tǒng)很快會隨業(yè)務(wù)變化而老化。我堅持每個項目上線后至少跟蹤兩個月每周從真實流量里撈badcase攢夠一千條就做一輪增量更新。這個習慣救了不少項目的命。最后講一個我踩過最深的坑。我第一次帶領(lǐng)域微調(diào)項目的時候花了整整兩周調(diào)訓(xùn)練參數(shù)結(jié)果效果不升反降后來一查問題出在訓(xùn)練數(shù)據(jù)里混入了三千條OCR亂碼樣本——模型學(xué)著學(xué)著就開始輸出亂碼。從那以后我每次訓(xùn)練前都會隨機抽兩百條數(shù)據(jù)人工過一遍再交給模型。這個看似土辦法的檢查幫我避開了后面至少五次大返工。垂直大模型這條路真正的門檻不在訓(xùn)練這個動作而在你愿不愿意把數(shù)據(jù)的臟活累活做扎實。