簡介面向人工智能應(yīng)用開發(fā)者與行業(yè)技術(shù)決策者聚焦中文大語言模型向行業(yè)落地的核心環(huán)節(jié)涵蓋指令數(shù)據(jù)、安全對齊數(shù)據(jù)與說明文檔適用于構(gòu)建公司級或行業(yè)級大模型應(yīng)用場景。包內(nèi)共8個文件包含三個jsonl與三個json格式的數(shù)據(jù)文件以及兩個md說明文檔整體僅3.44MB便于下載與速覽。其中jsonl/json數(shù)據(jù)多與中文指令微調(diào)、安全提示及開發(fā)者指令相關(guān)md文檔則提供使用指引。該資源上線后已有208人學(xué)習(xí)/下載適合正在搭建中文大模型訓(xùn)練環(huán)境或推進(jìn)行業(yè)應(yīng)用的讀者參考。指令數(shù)據(jù)如alpaca中文數(shù)據(jù)、安全提示集等可直接用于模型微調(diào)與對齊測試說明文檔能幫助快速理解文件結(jié)構(gòu)和調(diào)用方式為落地行業(yè)大模型提供基礎(chǔ)數(shù)據(jù)支撐與排錯參考節(jié)省自行整理數(shù)據(jù)的時間。1. 中文大模型落地行業(yè)從解壓.zip到真能交付的最后一公里很多團(tuán)隊接觸行業(yè)大模型的第一份素材就是一個.zip壓縮包。解壓、翻目錄、把模型跑起來這些步驟半天就能完成但真正的交付難點在壓縮包之外——怎么把中文大語言模型做成公司內(nèi)部的私有化服務(wù)讓業(yè)務(wù)方愿意把生產(chǎn)數(shù)據(jù)喂進(jìn)來讓答案經(jīng)得起追問。做AI大模型應(yīng)用的同學(xué)大多有這種體會demo能跑通不是能力業(yè)務(wù)方點頭才是驗收。這篇文章按行業(yè)項目最常見的落地路徑展開覆蓋中文基座選型、業(yè)務(wù)數(shù)據(jù)整理、LoRA微調(diào)、vLLM部署、SSE實時渲染以及那些線上才會暴露的坑。適合準(zhǔn)備做行業(yè)大模型交付的算法工程師、平臺工程師和運維同學(xué)也適合正在評估要不要投入的技術(shù)負(fù)責(zé)人。2. 選中文基座模型先看許可證、參數(shù)量與權(quán)重格式再動手解包行業(yè)項目的選型不能在壓縮包里進(jìn)行。拿到.zip先別急著做環(huán)境配置基座選錯后面的微調(diào)、部署、評測全都要返工。選型的先后順序應(yīng)該是先看許可證再定參數(shù)規(guī)模最后確認(rèn)權(quán)重格式。順序反了大概率會在某個周五晚上發(fā)現(xiàn)模型不能商用或者部署的時候發(fā)現(xiàn)顯存差一半。2.1 基座怎么選為什么行業(yè)項目優(yōu)先看中文基座國內(nèi)業(yè)務(wù)場景優(yōu)先看中文基座原因很實際。中文基座的預(yù)訓(xùn)練語料里中文占比高行業(yè)術(shù)語、中文指令遵循能力和對話模板都更貼合。英文基座在中文業(yè)務(wù)上不是不能做但往往要花更多數(shù)據(jù)去矯正語言風(fēng)格同樣的微調(diào)預(yù)算效果會打折扣。選型時第一道門檻是許可證這個必須在立項時確認(rèn)清楚。公司級別或行業(yè)級別的交付意味著模型要部署在多臺服務(wù)器上可能還會打包給上下游伙伴商用許可不清晰的權(quán)重文件是重大合規(guī)隱患?，F(xiàn)在常見的做法是優(yōu)先選Apache 2.0這類寬松許可的中文基座系列法務(wù)審核會順暢很多交付物也能正常走采購流程。第二個看基座的中文SFT訓(xùn)練數(shù)據(jù)和對話模板。模板決定了后續(xù)數(shù)據(jù)整理的格式所以不要在「用哪套Prompt格式」上自己發(fā)明直接跟隨基座默認(rèn)的ChatML模板|im_start|和|im_end|圍起來的消息結(jié)構(gòu)后續(xù)接入推理框架和微調(diào)工具都不用改。如果基座模板和微調(diào)工具、推理框架三者不一致會出現(xiàn)「訓(xùn)練時正常部署時輸出亂七八糟」的玄學(xué)問題實際原因是模板錯位。2.2 參數(shù)量級怎么定從業(yè)務(wù)并發(fā)和顯存預(yù)算反推參數(shù)規(guī)模不應(yīng)該從「越大越聰明」來定而是從「部署環(huán)境能提供多少顯存、業(yè)務(wù)需要多少并發(fā)」反推。下面這組對應(yīng)關(guān)系是行業(yè)項目里比較常用的參考具體數(shù)值在不同推理引擎下會有浮動但量級是固定的。參數(shù)規(guī)模BF16推理顯存參考典型部署形態(tài)適用場景7B單卡24GB可跑量化后更低單機單卡vLLM或llama.cpp部門級知識問答、單業(yè)務(wù)線助手14B單卡40GB或雙卡24GB雙卡張量并行多個業(yè)務(wù)線共用一套模型服務(wù)72B多卡80GB或多卡量化多卡并行統(tǒng)一網(wǎng)關(guān)行業(yè)級底座面向全公司7B級別是目前行業(yè)落地的甜點位。在電氣、售后、法律這些垂直領(lǐng)域經(jīng)過良好微調(diào)的7B模型能覆蓋大量日常問答如果一次請求的上下文不超過兩千字單張24GB顯卡用vLLM部署7B就能扛住幾十個并發(fā)硬件成本在可接受范圍內(nèi)。14B和72B效果更強但對顯存、運維的要求是指數(shù)級上升的。做這個決策時有一個容易忽視的角度業(yè)務(wù)方要的不是「最強模型」而是「穩(wěn)定可用的服務(wù)」。與其上72B然后因為顯存不足把并發(fā)壓得很低不如先用7B跑通業(yè)務(wù)閉環(huán)把知識庫和提示詞工程做好等業(yè)務(wù)量明確再考慮升級。我見過不止一個項目死在第一步選了過大的基座導(dǎo)致推理成本超預(yù)算。2.3 拿到.zip先做三件事校驗包、清點權(quán)重格式、確認(rèn)部署形態(tài)拿到別人分享的行業(yè)大模型.zip以及內(nèi)部交付的資源包先按下面的順序過一遍不要直接解壓扔進(jìn)訓(xùn)練環(huán)境。sha256sum industry_model_bundle.zip unzip -l industry_model_bundle.zip第一行是校驗完整性第二行是列出壓縮包內(nèi)容清單。模型文件在傳輸過程中損壞并不少見損壞的權(quán)重在你訓(xùn)練或者推理時通常不報錯而是表現(xiàn)為「生成內(nèi)容胡說八道」非常容易誤判成基座能力問題。這里多說一句zip偽加密這種解壓小坑十分鐘能解決真正花時間的是后面——確認(rèn)包里是訓(xùn)練好的完整權(quán)重還是只有一份LoRA適配器這決定了你是直接部署還是要先做權(quán)重合并。下一步是確認(rèn)權(quán)重格式。常見的有三種safetensors格式HuggingFace標(biāo)準(zhǔn)訓(xùn)練和vLLM直接加載、GGUF格式llama.cpp系引擎和端側(cè)加載、AWQ/GPTQ量化格式低顯存推理。格式本身沒有優(yōu)劣取決于你的部署形態(tài)。如果目標(biāo)環(huán)境是Linux服務(wù)器上跑vLLM選safetensors如果要做Android App集成AI大模型GGUF是端側(cè)最常用的加載格式如果只有一兩張16GB的卡還想跑7B量化格式幾乎是唯一選擇。最后建議做一次基線測試直接用未微調(diào)的基座跑20條真實業(yè)務(wù)問題把回答存下來。這組基線記錄在后面微調(diào)完成后要做對比用來判斷微調(diào)到底帶來了什么改變。這一步不要省它決定了后面所有工作有沒有參照物。3. 用Qwen2.5-7B微調(diào)行業(yè)大模型數(shù)據(jù)整理、LoRA訓(xùn)練與權(quán)重合并基座定下來后最核心的工作是微調(diào)。做行業(yè)大模型微調(diào)數(shù)據(jù)整理的優(yōu)先級永遠(yuǎn)高于訓(xùn)練參數(shù)的調(diào)整。數(shù)據(jù)不對調(diào)參只是把錯誤答案訓(xùn)練得更流暢。如果你第一次做這個流程Qwen2.5-7B-Instruct加LLaMA-Factory是當(dāng)前走得通的組合環(huán)境配置、模型加載、數(shù)據(jù)集格式都有成熟方案周邊資料也多踩坑時容易找到對照。3.1 把行業(yè)語料轉(zhuǎn)成ChatML指令集一份最少可用的SFT樣本行業(yè)微調(diào)的數(shù)據(jù)格式直接決定訓(xùn)練能否被模型理解。中文基座大多原生支持ChatML格式也就是每條樣本包含system、user、assistant三個角色的消息序列。下面是一個設(shè)備診斷場景的SFT樣本這種形態(tài)在行業(yè)項目里非常典型。{messages: [{role: system, content: 你是恒泰設(shè)備的液壓系統(tǒng)診斷助理。只能依據(jù)維修手冊和設(shè)備參數(shù)回答不能編造壓力、流量等數(shù)值。}, {role: user, content: 液壓站壓力波動超過多少MPa必須停機排查}, {role: assistant, content: 當(dāng)系統(tǒng)壓力波動超過±1.5 MPa且持續(xù)10秒以上時應(yīng)停機排查溢流閥與蓄能器。}]}這里的關(guān)鍵是system里寫清角色邊界和禁止行為user保留業(yè)務(wù)原話assistant是人工校驗過的標(biāo)準(zhǔn)答案。注意不要一條樣本里塞進(jìn)多輪對話歷史SFT樣本應(yīng)該是一問一答的原子記錄多輪能力后期用提示詞工程補。行業(yè)語料需要清洗比如維修工單里的口語表達(dá)、錯別字、私聊信息都要處理剩下業(yè)務(wù)問答核心。樣本量上質(zhì)量遠(yuǎn)比數(shù)量重要。1000條經(jīng)過人工校驗的高質(zhì)量業(yè)務(wù)問答效果通常好于10萬條從網(wǎng)頁或工單里直接扒出來的噪聲數(shù)據(jù)。這里的教訓(xùn)是不要追求數(shù)據(jù)量堆積行業(yè)項目的周期瓶頸往往卡在答案審核而不是語料采集上。每條assistant答案都要有可追溯依據(jù)——來自哪個手冊、哪份參數(shù)表——不然模型學(xué)到的是「看似合理的編造」?！感W(xué)」地說數(shù)據(jù)里有多少幻覺模型就學(xué)多少幻覺。3.2 用LLaMA-Factory跑一輪LoRA微調(diào)命令與關(guān)鍵參數(shù)數(shù)據(jù)集準(zhǔn)備好之后推薦用LLaMA-Factory做微調(diào)。它支持Qwen系列模型和ChatML模板可以省掉自己寫訓(xùn)練腳本的時間。常見做法是先用LoRA做嘗試LoRA只訓(xùn)練一小部分適配器參數(shù)訓(xùn)練快、顯存占用低效果不滿意可以快速換數(shù)據(jù)重來全量微調(diào)放在后面效果驗證過再考慮。llamafactory-cli train \ --model_name_or_path /data/models/Qwen2.5-7B-Instruct \ --dataset industry_sft \ --finetuning_type lora \ --template qwen \ --output_dir /data/output/industry_7b_lora \ --num_train_epochs 3 \ --learning_rate 2e-4 \ --lora_rank 16 \ --lora_alpha 32 \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --max_length 2048 \ --logging_steps 20 \ --save_steps 500 \ --bf16 True幾個參數(shù)值得細(xì)說。lora_rank和lora_alpha控制適配器的容量行業(yè)指令數(shù)據(jù)量在幾千條時rank取16到32是常用區(qū)間rank太大容易過擬合小數(shù)據(jù)集太小則學(xué)不到位。learning_rate取2e-4是LoRA微調(diào)比較穩(wěn)妥的起點如果你同時混入了通用指令數(shù)據(jù)可以降到1e-4。max_length要覆蓋業(yè)務(wù)中最長的問題和答案行業(yè)場景里如果把歷史維修記錄塞進(jìn)上下文2048可能不夠要提前統(tǒng)計業(yè)務(wù)樣本的真實長度分布而不是隨手設(shè)個值。訓(xùn)練過程中l(wèi)oss曲線只是第一步門檻更重要的是每訓(xùn)練幾百步就保存一個checkpoint挑幾條固定業(yè)務(wù)問題做生成對比。畫畫loss曲線的意義有限真正要觀察的是模型回答的措辭在哪個checkpoint開始穩(wěn)定。我在實際項目中會下載save_steps對應(yīng)的中間產(chǎn)物手工試答幾條困難問題來判斷是繼續(xù)訓(xùn)練還是提前停。不要盲目跑滿epoch數(shù)——行業(yè)場景里L(fēng)oRA跑了兩個epoch就想吐訓(xùn)練集原話的情況非常常見。3.3 合并與導(dǎo)出從訓(xùn)練權(quán)重到生產(chǎn)可用的BF16/GGUFLoRA訓(xùn)練完成后產(chǎn)出的是一個小體積適配器文件而不是完整模型部署前需要把它合并進(jìn)基座權(quán)重。這個步驟的常見做法是使用LLaMA-Factory自帶的export功能。llamafactory-cli export \ --model_name_or_path /data/models/Qwen2.5-7B-Instruct \ --adapter_name_or_path /data/output/industry_7b_lora \ --template qwen \ --export_dir /data/output/industry_7b_merged合并之后會得到一個完整的safetensors格式模型這個模型可以直接給vLLM加載。注意--template qwen必須和訓(xùn)練時一致模板不一致會導(dǎo)致部署后回答格式錯亂。合并完先加載起來人工試幾條再做下一步。接下來根據(jù)部署環(huán)境決定是否量化。如果目標(biāo)服務(wù)器顯存充裕單卡24GB以上直接用BF16權(quán)重跑vLLM即可效果最好如果顯存緊張或者要做端側(cè)部署常見做法是用llama.cpp的轉(zhuǎn)換腳本把合并權(quán)重轉(zhuǎn)成GGUF格式再按需壓到Q4_K_M或Q8_0量化檔位。7B模型Q4_K_M量化后權(quán)重體積大約在5GB上下普通工作站就能跑起來。這里不要追求極致壓縮行業(yè)項目的推理質(zhì)量比體積重要Q4_K_M優(yōu)先Q8_0次之再低的量化檔位建議先做效果對比再決定。4. 公司級部署vLLM拉起本地服務(wù)、SSE實時渲染與模型網(wǎng)關(guān)微調(diào)完成的模型要變成業(yè)務(wù)方能調(diào)用的API服務(wù)通常選vLLM做推理引擎。vLLM在并發(fā)場景下吞吐表現(xiàn)穩(wěn)定而且自帶OpenAI兼容接口——這意味著我們不需要為它單獨設(shè)計一套協(xié)議應(yīng)用層可以直接按/v1/chat/completions的規(guī)范來對接大幅降低集成成本。整個部署鏈路是vLLM拉起模型服務(wù)、網(wǎng)關(guān)統(tǒng)一做鑒權(quán)和限流、前端走SSE流式輸出拿到實時渲染效果。4.1 vLLM最小啟動配置模型路徑、序列長度與并發(fā)參數(shù)先給一份最小可用的啟動命令之后按業(yè)務(wù)規(guī)模調(diào)整參數(shù)。python -m vllm.entrypoints.openai.api_server \ --model /data/output/industry_7b_merged \ --served-model-name industry-7b \ --port 8000 \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 32--model指向合并后的模型目錄--served-model-name是客戶端請求時要用的模型名不必和目錄名一致內(nèi)部項目可以取一個業(yè)務(wù)名比如industry-7b。--max-model-len直接決定模型能接受的最大上下文長度設(shè)太大占用顯存設(shè)太小長文檔對話會截斷報錯。我一般先用2048起步壓測時觀察業(yè)務(wù)方的真實請求長度再往上調(diào)。--gpu-memory-utilization 0.9意思是允許vLLM使用90%的顯存保留一部分給CUDA上下文和其他進(jìn)程這個值在大模型本地部署配置里很常用。--max-num-seqs控制并發(fā)序列數(shù)它和顯存是強相關(guān)的序列數(shù)越多KV cache占用越高。啟動后可以用curl發(fā)一個請求驗證服務(wù)是否正常確認(rèn)非流式接口返回正常后再測stream: true的流式參數(shù)。4.2 通過SSE流式輸出做回答實時渲染配合AbortController處理中斷大模型回答動輒幾百字等全部生成完再返回用戶體驗很差。行業(yè)應(yīng)用的標(biāo)準(zhǔn)做法是SSE流式輸出服務(wù)端邊生成邊推送前端收到一個詞就渲染一個詞配合abort機制處理用戶手動停止的場景。這里涉及的技術(shù)棧封裝AI交互邏輯的核心就兩塊解析SSE事件流、正確取消請求。以下是前端處理SSE流式輸出的一段核心JavaScript可以直接作為應(yīng)用層集成的參考。const controller new AbortController(); const resp await fetch(/v1/chat/completions, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ model: industry-7b, messages: [{ role: user, content: 壓力波動超過多少需要停機 }], stream: true }), signal: controller.signal }); const reader resp.body.getReader(); const decoder new TextDecoder(); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); const lines buffer.split(\n); buffer lines.pop(); // 保留未完成的行等下一段數(shù)據(jù)拼齊 for (const line of lines) { if (line.startsWith(data: )) { const payload line.slice(6); if (payload [DONE]) return; // 流結(jié)束標(biāo)記 render(JSON.parse(payload).choices[0].delta.content); } } } stopBtn.onclick () controller.abort();這里的邏輯要點是SSE協(xié)議的數(shù)據(jù)按行分割每行以data:開頭最后以[DONE]收尾。網(wǎng)絡(luò)包不會恰好按行邊界到達(dá)所以必須聲明一個buffer變量把不完整的行留到下一次讀取時拼接這是流式渲染最容易出錯的地方。abort的時機同樣重要用戶點擊停止時調(diào)用controller.abort()瀏覽器會斷開這個請求vLLM收到客戶端斷開后會自動釋放對應(yīng)的KV cache資源。如果不做abort用戶反復(fù)點擊「停止」實際上連接還掛在服務(wù)端會占用并發(fā)序列數(shù)累積起來就會拖垮接口。4.3 私有化場景的模型網(wǎng)關(guān)鑒權(quán)、限流與調(diào)用審計行業(yè)部署和私有化交付最核心的差異在于模型不能直接暴露給所有業(yè)務(wù)方。vLLM本身不帶業(yè)務(wù)鑒權(quán)如果公司多條業(yè)務(wù)線共用一套模型服務(wù)必須在其前增加一層網(wǎng)關(guān)負(fù)責(zé)API Key鑒權(quán)、按調(diào)用方限流和請求日志留痕。常見做法是使用Nginx開放REST API風(fēng)格的服務(wù)并關(guān)閉代理緩沖以支持SSE。location /v1/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-API-Key $http_x_api_key; proxy_buffering off; proxy_read_timeout 120s; }proxy_buffering off這行很關(guān)鍵它保證SSE流式響應(yīng)不會被Nginx截留成一次性返回。如果這里不關(guān)前端收到的內(nèi)容會在整個請求結(jié)束后一次性到達(dá)流式效果等于沒有而且首字延遲會很高體驗非常差。鑒權(quán)邏輯放在網(wǎng)關(guān)層對沒有正確API Key的請求直接返回401限流可以用Nginx的limit_req模塊實現(xiàn)按調(diào)用方的Key做每分鐘請求數(shù)限制防止某條業(yè)務(wù)線異常調(diào)用拖垮整個模型服務(wù)。日志審計在行業(yè)場景里往往被忽略但它其實是合規(guī)的前提。網(wǎng)關(guān)層記錄每次請求的用戶標(biāo)識、輸入摘要、模型輸出的首字延遲和完成狀態(tài)后續(xù)一旦出現(xiàn)問題能追溯到具體調(diào)用方。運維側(cè)建議把首字延遲TTFT和每秒請求數(shù)這兩個指標(biāo)接到監(jiān)控上后面避坑章節(jié)會具體展開為什么TTFT比總耗時更重要。5. 行業(yè)落地避坑指南五個血淚經(jīng)驗從顯存翻車到SSE被緩沖這里匯總一下行業(yè)項目里反復(fù)出現(xiàn)的五個問題每條都按「現(xiàn)象、原因、解決」來寫。這些多半在demo階段不會暴露都是上了生產(chǎn)環(huán)境之后才冒出來提前知道能省下不少排查時間。5.1 微調(diào)后「變笨」行業(yè)術(shù)語學(xué)會了通用對話能力卻崩了現(xiàn)象模型在業(yè)務(wù)問答上表現(xiàn)不錯但大家閑聊式的提問開始答非所問甚至重復(fù)同一個句式。原因這是災(zāi)難性遺忘。SFT數(shù)據(jù)里行業(yè)樣本占比過高模型反復(fù)學(xué)習(xí)某一種回答模式把基座原本的通用能力覆蓋掉了。LoRA學(xué)習(xí)率偏高或者epoch數(shù)跑滿也會放大這個問題。解決在行業(yè)數(shù)據(jù)里混入10%到20%的通用指令數(shù)據(jù)比如日常問答、百科類對話讓模型在訓(xùn)練時同時復(fù)習(xí)通用能力。學(xué)習(xí)率從2e-4降到1e-4訓(xùn)練過程按前面說的用固定業(yè)務(wù)問題做checkpoint對比發(fā)現(xiàn)回答僵化就提前停訓(xùn)別硬跑完。這類問題一旦發(fā)生調(diào)已經(jīng)訓(xùn)練完的適配器是沒有后悔藥的只能改數(shù)據(jù)重新訓(xùn)練所以預(yù)防要比事后補救重要。5.2 T4上部署OOMA100卻一切正常現(xiàn)象開發(fā)環(huán)境用的是A100部署到客戶T4 16GB顯卡上啟動就報CUDA out of memory項目當(dāng)場卡住。原因顯存估算只算了權(quán)重體積。7B模型BF16權(quán)重大概15GB再加上KV cache、CUDA上下文和vLLM預(yù)分配顯存16GB根本不夠。這是本地部署配置時的經(jīng)典誤區(qū)——權(quán)重能塞下不代表推理過程能跑起來。解決兩條路。一是顯存緊張的機器上改用量化格式例如用GGUF的Q4_K_M檔位量化后再啟動服務(wù)二是保留BF16權(quán)重但調(diào)低--max-model-len和--gpu-memory-utilization把序列長度限制在2048以內(nèi)給KV cache留出空間。更進(jìn)一步的方法是用AWQ等量化方案在vLLM里做等效推理。選型時建議先確認(rèn)客戶機器的顯存再做規(guī)模決策別等到部署階段翻車。5.3 SSE一直轉(zhuǎn)圈接口有響應(yīng)但頁面不渲染現(xiàn)象用curl請求后端stream: true能正?？吹綌?shù)據(jù)前端調(diào)接口頁面卻一直等像卡死一樣。原因前端代碼沒問題問題在中間的代理層。Nginx默認(rèn)開啟proxy_bufferingSSE響應(yīng)會被緩沖前端實際上要等整個流結(jié)束才拿到內(nèi)容一直在等待狀態(tài)。這類問題看起來像前端bug實際是服務(wù)器配置問題。解決在Nginx配置里加上proxy_buffering off;或者在后端響應(yīng)的HTTP頭里顯式添加X-Accel-Buffering: no。另外注意SSE對網(wǎng)關(guān)的連接超時設(shè)置proxy_read_timeout要足夠大模型生成慢的時候超過60秒就可能被切斷建議設(shè)到120秒以上。5.4 行業(yè)答案說得漂亮但數(shù)值是錯的現(xiàn)象模型回答的語句很流利語氣也很自信但關(guān)鍵參數(shù)、法規(guī)條款、設(shè)備型號之間出現(xiàn)張冠李戴業(yè)務(wù)方一核對就發(fā)現(xiàn)問題。原因模型本質(zhì)上是「概率生成」它沒有查證能力行業(yè)知識全靠訓(xùn)練時的記憶。微調(diào)能教會它話術(shù)和表達(dá)框架但它依然會用自己的語言習(xí)慣生成讀起來像真的、實際不存在的數(shù)值。解決把檢索增強生成RAG接入生產(chǎn)鏈路。業(yè)務(wù)知識先入庫做向量化用戶提問時先從知識庫檢索相關(guān)片段再把檢索結(jié)果和問題一起拼進(jìn)提示詞要求模型只能依據(jù)檢索內(nèi)容回答。同時加一層兜底在提示詞里明確「如果檢索內(nèi)容里沒有答案直接回答無法確定」。模型的能力上限不是唯一的交付標(biāo)準(zhǔn)給模型提供答案依據(jù)的檢索鏈路才是行業(yè)落地的分水嶺。5.5 上線第一天就被業(yè)務(wù)方說「太慢」現(xiàn)象接口耗時曲線難看業(yè)務(wù)方反饋首字遲遲不出來并發(fā)一高直接排隊。原因看監(jiān)控時只關(guān)注了單次請求總耗時忽略了首字延遲TTFT和并發(fā)排隊。--max-num-seqs設(shè)置偏小會讓并發(fā)的請求排隊等待上一個長請求不結(jié)束后面的請求就一直卡著。解決上線前用壓測工具模擬真實流量按業(yè)務(wù)預(yù)估的峰值并發(fā)打一輪關(guān)注TTFT的P95而不是平均總耗時。根據(jù)壓測結(jié)果調(diào)整--max-num-seqs和--max-model-len必要時限制單次請求的上下文輪次把歷史多輪對話截斷成最近幾輪以縮短生成長度。模型服務(wù)的響應(yīng)時間分布本來就比普通接口寬提前給業(yè)務(wù)方一個「首字延遲目標(biāo)值」作為預(yù)期管理也可以避免上線后被動挨告。6. 用一件小事守住交付品質(zhì)把行業(yè)評測集接進(jìn)更新流程行業(yè)模型上線后不是終點業(yè)務(wù)數(shù)據(jù)會增長話術(shù)會變化模型需要持續(xù)迭代。這個章節(jié)不是總結(jié)而是分享一個每家做落地交付的團(tuán)隊都該有的習(xí)慣建立一份自己的行業(yè)評測集并且把每次模型更新都跑一遍評測結(jié)果留下記錄再談上線。評測集不要盲目求大200條以內(nèi)即可但必須滿足兩點一是全部來自真實業(yè)務(wù)樣本或高頻問題二是包含一批容易翻車的困難樣例比如數(shù)值敏感的設(shè)備參數(shù)、有明確邊界條件的業(yè)務(wù)規(guī)則、用戶常見的口語化問法。標(biāo)注格式可以用一個極簡的JSONL文件每條包含問題、答案中必須出現(xiàn)的關(guān)鍵內(nèi)容、禁止出現(xiàn)的內(nèi)容。核驗?zāi)_本用規(guī)則匹配兜底減少人工重復(fù)勞動。import json golden [ {q: 壓力波動超過多少必須停機, must: [1.5, 停機], must_not: []}, {q: 保修期外維修怎么收費, must: [上門費, 工時費], must_not: [免費]}, ] def hit(pred: str, case: dict) - bool: ok_all all(k in pred for k in case[must]) bad_any any(k in pred for k in case[must_not]) return ok_all and not bad_any preds [json.loads(line) for line in open(preds.jsonl)] acc sum(hit(p[pred], golden[i]) for i, p in enumerate(preds)) / len(golden) print(facc{acc:.2%})規(guī)則腳本只能兜底每20條抽1條人工看一遍完整回答重點看流暢度和上下文邏輯。Checks要接進(jìn)模型更新的發(fā)布流程里模型版本發(fā)版前先跑評測集準(zhǔn)確率低于歷史平均值就攔住不發(fā)版。行業(yè)項目的交付穩(wěn)定比驚喜重要守住下限比追求高分更有價值。我自己的習(xí)慣是每次訓(xùn)練前把這份評測集的預(yù)測結(jié)果用git log對應(yīng)的方式存檔一份模型更新后直接對比前后差距哪些問題變好、哪些問題變差一目了然。模型微調(diào)的黑匣子特性決定了不可能每次訓(xùn)練都變好但有了這份記錄任何一次回滾都有依據(jù)。如果你正在做行業(yè)大模型落地建議從今天開始就把這個幾十條問題的評測集搭起來它會成為你的AI大模型應(yīng)用里最值錢的一份資產(chǎn)。希望幫到你。本文還有配套的精品資源點擊獲取