1. 課題組私有AI的落地路徑拆解1.1 為什么通用大模型在課題組場景里總差一口氣課題組做研究跟企業(yè)做產(chǎn)品有個本質(zhì)區(qū)別數(shù)據(jù)量小、領(lǐng)域窄、但精度要求極高。你拿一個通用大模型去問它“這個材料的XRD衍射峰在2θ32.5°對應(yīng)什么晶相”它大概率給你一段聽起來很專業(yè)但完全不對的回答。原因不復(fù)雜——通用模型的訓(xùn)練語料里你這個細(xì)分方向的內(nèi)容可能只占百萬分之一模型根本沒有足夠信號去學(xué)到這層知識。我試過直接拿某國產(chǎn)開源模型去回答組里的專業(yè)問題十次里有六次在編。后來想明白了通用模型是“通才”它知道很多領(lǐng)域的常識但對你的課題組的“私有知識”——那些發(fā)在組內(nèi)論文、實驗記錄本、師兄師姐畢業(yè)論文里的東西——它一無所知。這就是為什么必須走“領(lǐng)域微調(diào)知識庫構(gòu)建本地化部署”這條路。私有AI的核心價值在于三點第一把課題組多年積累的論文、實驗記錄、會議紀(jì)要變成可檢索、可問答的知識資產(chǎn)第二讓模型學(xué)會你們組的“行話”和推理范式第三數(shù)據(jù)不出本地實驗數(shù)據(jù)的安全性有保障。適合誰來參考研究生、博后、課題組的技術(shù)負(fù)責(zé)人以及任何需要在小規(guī)模數(shù)據(jù)上構(gòu)建專屬AI能力的人。1.2 整體技術(shù)路線的選型邏輯整條路線可以拆成四層模型層、數(shù)據(jù)層、訓(xùn)練層、部署層。每一層都有坑我一個個說。模型層選型我建議優(yōu)先考慮國產(chǎn)開源模型。Qwen系列Qwen2.5-7B/14B、ChatGLM系列、Baichuan系列、InternLM系列都是成熟選項。為什么優(yōu)先國產(chǎn)一是中文語料占比高對中文學(xué)術(shù)文本的理解天然更好二是社區(qū)活躍遇到問題容易找到解決方案三是本地化部署的文檔和工具鏈更完善。7B級別適合單卡24G顯存做QLoRA微調(diào)14B級別需要雙卡或A100 40G起步。數(shù)據(jù)層是整條路線里最容易被低估的環(huán)節(jié)。很多人一上來就想著調(diào)參結(jié)果數(shù)據(jù)沒整理好訓(xùn)出來的模型還不如原版。領(lǐng)域語料構(gòu)建包括論文PDF解析、實驗記錄結(jié)構(gòu)化、問答對生成、數(shù)據(jù)清洗去重。這一步的工作量通常占總項目的60%以上。訓(xùn)練層有兩條路RAG和微調(diào)。這兩者不是二選一而是互補。RAG解決“知識檢索”問題微調(diào)解決“行為對齊”問題。我的經(jīng)驗是先搭RAG把知識庫跑通再根據(jù)RAG的bad case決定要不要微調(diào)。如果RAG已經(jīng)能回答80%的問題微調(diào)的優(yōu)先級可以降低如果模型總是答非所問、格式不對那就需要LoRA/QLoRA來教它“怎么說話”。部署層選vLLM做推理引擎配合GPTQ/AWQ量化壓縮能在有限顯存下實現(xiàn)高并發(fā)。量化后的7B模型在單張24G卡上可以跑到每秒幾十個token的輸出速度同時支撐十幾個并發(fā)請求對課題組內(nèi)部使用完全夠用。2. 領(lǐng)域語料構(gòu)建與知識庫搭建實操2.1 論文與實驗記錄的清洗流水線課題組的數(shù)據(jù)來源通常很雜PDF論文、Word實驗報告、Excel數(shù)據(jù)表、手寫記錄拍照、組會PPT。第一步是把這些異構(gòu)數(shù)據(jù)統(tǒng)一成純文本。PDF解析我踩過最大的坑是公式和表格。PyPDF2對學(xué)術(shù)論文的公式支持很差經(jīng)常把公式拆成亂碼。后來換成PyMuPDFfitz 針對性的正則清洗效果好很多。表格用pdfplumber單獨提取保留結(jié)構(gòu)信息。掃描版PDF必須走OCRPaddleOCR對中文學(xué)術(shù)文檔的識別率明顯優(yōu)于Tesseract尤其是包含公式和上下標(biāo)的場景。import fitz # PyMuPDF import re def extract_pdf_text(pdf_path): doc fitz.open(pdf_path) full_text [] for page in doc: text page.get_text(text) # 清理頁眉頁腳通常是重復(fù)出現(xiàn)的短行 lines text.split(\n) cleaned [l for l in lines if len(l.strip()) 5] full_text.append(\n.join(cleaned)) doc.close() return \n.join(full_text) def clean_academic_text(text): # 去除引用標(biāo)記 [1] [2,3] text re.sub(r\[\d(,\d)*\], , text) # 合并被換行打斷的句子 text re.sub(r(\w)\n(\w), r\1\2, text) # 去除多余空白 text re.sub(r\s, , text) return text.strip()清洗完之后要做去重。學(xué)術(shù)論文里方法部分高度相似如果不去重RAG檢索時會返回一堆幾乎一樣的片段浪費上下文窗口。我用SimHash做近似去重閾值設(shè)在0.85左右既能去掉重復(fù)又不誤殺。注意清洗階段一定要保留原文的章節(jié)結(jié)構(gòu)信息標(biāo)題、小節(jié)號后面做chunk切分時這些結(jié)構(gòu)信息能顯著提升檢索質(zhì)量。2.2 文本切分策略固定長度還是語義切分文本切分是RAG的“隱形殺手”。切得不好檢索出來的片段要么缺上下文要么包含太多無關(guān)信息。固定長度切分比如512 token一段重疊50 token是最簡單的方案適合快速驗證。但它的問題很明顯可能把一個完整的論證切成兩半檢索時只命中一半模型拿到的是殘缺信息。語義切分按段落、按章節(jié)切保持語義完整性。我的做法是先按標(biāo)題層級切分成大塊如果某塊超過800 token再按句子邊界切分。句子邊界用中文標(biāo)點。和換行符共同判斷。def semantic_chunk(text, max_tokens800, overlap_sentences1): # 按章節(jié)標(biāo)題切分 sections re.split(r\n(?#{1,3}\s|\d\.\d*\s), text) chunks [] for sec in sections: if len(sec) max_tokens: chunks.append(sec) else: # 按句子切分 sentences re.split(r(?[。]), sec) current for sent in sentences: if len(current) len(sent) max_tokens: chunks.append(current) # 保留上一句作為重疊 current sentences[max(0, sentences.index(sent)-overlap_sentences)] sent else: current sent if current: chunks.append(current) return chunks實際用下來語義切分的檢索命中率比固定長度切分高15%到20%。代價是切分邏輯更復(fù)雜需要針對不同文檔類型調(diào)參。2.3 向量化與檢索embedding模型怎么選知識庫的檢索質(zhì)量一半取決于切分一半取決于embedding模型。中文場景下BGE系列BAAI/bge-large-zh-v1.5是目前開源里綜合表現(xiàn)最好的。M3E系列也可以但在長文本上略遜一籌。向量數(shù)據(jù)庫選型數(shù)據(jù)量在百萬級以下Chroma或FAISS完全夠用。Chroma的優(yōu)勢是自帶持久化和元數(shù)據(jù)過濾FAISS的優(yōu)勢是快。課題組場景我推薦Chroma因為元數(shù)據(jù)過濾很實用——你可以按“論文年份”“作者”“章節(jié)類型”過濾檢索范圍。from chromadb import Client from chromadb.utils import embedding_functions client Client() ef embedding_functions.SentenceTransformerEmbeddingFunction( model_nameBAAI/bge-large-zh-v1.5 ) collection client.create_collection( namelab_knowledge, embedding_functionef, metadata{hnsw:space: cosine} ) # 批量寫入 collection.add( documentschunks, metadatas[{source: f, year: y, section: s} for f, y, s in meta_list], ids[fid_{i} for i in range(len(chunks))] )檢索時用混合檢索向量相似度 BM25關(guān)鍵詞匹配加權(quán)融合。純向量檢索對專有名詞比如某個材料牌號不敏感BM25能補上這個短板。實測混合檢索的hit rate比純向量高10%以上。3. LoRA與QLoRA微調(diào)實戰(zhàn)3.1 什么時候該微調(diào)什么時候不該先潑一盆冷水不是所有場景都需要微調(diào)。如果你的需求是“讓模型能回答課題組論文里的問題”RAG就夠了。微調(diào)真正解決的問題是模型輸出格式不對、推理風(fēng)格不符合組內(nèi)習(xí)慣、對特定術(shù)語的理解有偏差。我判斷的標(biāo)準(zhǔn)很簡單拿100條測試問題跑一遍RAG如果準(zhǔn)確率超過75%且錯誤主要是“知識缺失”而非“格式錯誤”那就繼續(xù)優(yōu)化RAG。如果模型總是答非所問、輸出格式混亂、或者對某些概念的理解系統(tǒng)性偏離那就上微調(diào)。微調(diào)的數(shù)據(jù)量要求LoRA微調(diào)通常需要500到2000條高質(zhì)量問答對。少于500條效果不穩(wěn)定多于5000條邊際收益遞減。數(shù)據(jù)質(zhì)量比數(shù)量重要得多——100條精準(zhǔn)的問答對效果可能好過1000條粗糙的。3.2 LoRA微調(diào)的關(guān)鍵參數(shù)與實操LoRA的核心思想是在原模型權(quán)重旁邊掛一個小矩陣只訓(xùn)練這個小矩陣。這樣顯存占用大幅降低7B模型用LoRA微調(diào)只需要16G左右顯存。關(guān)鍵參數(shù)參數(shù)推薦值說明lora_rank8-32秩越大容量越強但過擬合風(fēng)險增加lora_alpha16-64通常設(shè)為rank的2倍lora_dropout0.05-0.1防止過擬合learning_rate1e-4到3e-4LoRA可以用比全量微調(diào)更大的學(xué)習(xí)率epochs3-5多了容易過擬合batch_size4-8根據(jù)顯存調(diào)整配合梯度累積from peft import LoraConfig, get_peft_model from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments model AutoModelForCausalLM.from_pretrained( Qwen/Qwen2.5-7B-Instruct, torch_dtypeauto, device_mapauto ) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-7B-Instruct) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) training_args TrainingArguments( output_dir./lora_output, per_device_train_batch_size4, gradient_accumulation_steps4, learning_rate2e-4, num_train_epochs3, logging_steps10, save_strategyepoch, fp16True )target_modules的選擇很關(guān)鍵。Qwen系列通常選q_proj、k_proj、v_proj、o_proj這四個注意力層的投影矩陣。如果效果不夠可以加上gate_proj和up_proj。但加得越多顯存占用越大訓(xùn)練越慢。3.3 QLoRA單卡24G跑14B模型的秘訣QLoRA在LoRA基礎(chǔ)上加了兩層優(yōu)化4-bit量化基座模型 分頁優(yōu)化器。效果是顯存占用進一步降低14B模型在單張24G卡上也能微調(diào)。from transformers import BitsAndBytesConfig import torch bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_quant_typenf4, bnb_4bit_compute_dtypetorch.bfloat16, bnb_4bit_use_double_quantTrue ) model AutoModelForCausalLM.from_pretrained( Qwen/Qwen2.5-14B-Instruct, quantization_configbnb_config, device_mapauto )nf4量化類型是QLoRA論文推薦的對正態(tài)分布權(quán)重最友好。double_quant是二次量化進一步壓縮量化常數(shù)省顯存但不影響精度。實操心得QLoRA訓(xùn)練速度比LoRA慢30%到50%因為每次前向傳播都要反量化。如果顯存夠用優(yōu)先用LoRA顯存緊張再上QLoRA。3.4 知識蒸餾讓小模型學(xué)會大模型的本事知識蒸餾在課題組場景里有個特殊用法用大模型比如Qwen2.5-72B生成高質(zhì)量的問答對然后拿這些數(shù)據(jù)去微調(diào)小模型7B。這樣小模型能學(xué)到接近大模型的回答質(zhì)量但推理成本低得多。具體做法準(zhǔn)備500到1000個領(lǐng)域問題用大模型生成回答人工篩選后作為訓(xùn)練數(shù)據(jù)。溫度設(shè)高一點0.7到0.9讓大模型輸出更多樣的回答增加數(shù)據(jù)多樣性。蒸餾數(shù)據(jù)的質(zhì)量取決于兩個因素大模型的能力和篩選標(biāo)準(zhǔn)。我通常會讓大模型對每個問題生成3個回答然后人工選最好的那個或者用另一個模型做自動評分。4. 量化壓縮與vLLM高并發(fā)部署4.1 GPTQ與AWQ量化怎么選量化是把模型權(quán)重從FP16壓縮到INT4或INT8減少顯存占用和推理延遲。GPTQ和AWQ是目前最主流的兩種4-bit量化方案。GPTQ是逐層量化用校準(zhǔn)數(shù)據(jù)集來最小化量化誤差。優(yōu)點是成熟、工具鏈完善缺點是量化過程較慢對校準(zhǔn)數(shù)據(jù)敏感。AWQ是激活感知的量化核心思路是保護對激活值影響大的權(quán)重通道。優(yōu)點是量化后精度通常比GPTQ高一點尤其是小模型缺點是工具鏈相對新一些。對比項GPTQAWQ量化速度較慢較快精度保持好略好工具鏈成熟度高中vLLM支持完善完善推薦場景通用小模型/高精度要求我的經(jīng)驗7B模型用AWQ14B以上用GPTQ差別不大。量化后的模型在vLLM上跑顯存占用約為FP16的1/3推理速度提升2到3倍。# 用AutoAWQ量化 python -m awq.entry --model_path Qwen/Qwen2.5-7B-Instruct \ --w_bit 4 --q_group_size 128 \ --save_dir ./qwen2.5-7b-awq4.2 vLLM部署與并發(fā)調(diào)優(yōu)vLLM的核心優(yōu)勢是PagedAttention把KV Cache分頁管理顯存利用率大幅提升并發(fā)能力比HuggingFace原生推理高一個數(shù)量級。python -m vllm.entrypoints.openai.api_server \ --model ./qwen2.5-7b-awq \ --quantization awq \ --dtype auto \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 16 \ --port 8000關(guān)鍵參數(shù)說明gpu-memory-utilization設(shè)0.9留10%給系統(tǒng)max-num-seqs控制并發(fā)序列數(shù)7B模型在24G卡上設(shè)16比較穩(wěn)max-model-len根據(jù)實際需求設(shè)設(shè)太大浪費顯存。注意vLLM啟動時會預(yù)分配顯存如果OOM先降max-model-len再降max-num-seqs。不要一上來就把gpu-memory-utilization設(shè)到0.95系統(tǒng)不穩(wěn)定。4.3 RAG與微調(diào)模型的聯(lián)合部署最終架構(gòu)是vLLM跑微調(diào)后的模型Chroma做知識庫檢索中間加一層路由邏輯。import requests def rag_query(question, collection, top_k5): # 檢索 results collection.query(query_texts[question], n_resultstop_k) context \n.join(results[documents][0]) # 構(gòu)造prompt prompt f基于以下參考資料回答問題。如果資料中沒有相關(guān)信息請明確說明。 參考資料 {context} 問題{question} 回答 # 調(diào)用vLLM response requests.post(http://localhost:8000/v1/completions, json{ model: ./qwen2.5-7b-awq, prompt: prompt, max_tokens: 1024, temperature: 0.3 }) return response.json()[choices][0][text]路由邏輯簡單的事實性問題走RAG復(fù)雜的推理問題走微調(diào)模型直接回答混合問題先RAG檢索再讓微調(diào)模型整合。5. 常見問題與排查技巧實錄5.1 RAG檢索命中率低的排查思路這是被問得最多的問題。排查順序先看切分再看embedding最后看檢索策略。切分問題chunk太大檢索到的片段包含太多無關(guān)信息chunk太小上下文不完整。用“問題-答案”對做測試看檢索到的片段是否包含答案。如果不包含調(diào)整切分參數(shù)。embedding問題中文場景用BGE-large-zh不要用英文模型。如果領(lǐng)域術(shù)語多考慮在領(lǐng)域語料上微調(diào)embedding模型或者用BGE的instruction版本。檢索策略問題純向量檢索對專有名詞不敏感加BM25混合檢索。如果還不行加rerank模型BGE-reranker做二次排序。癥狀可能原因解決方案檢索不到相關(guān)片段切分太碎/embedding不匹配調(diào)整chunk size換中文embedding檢索到無關(guān)片段切分太大/檢索策略單一減小chunk加BM25混合檢索答案不完整top_k太小增大top_k加rerank專有名詞檢索失敗向量模型對術(shù)語不敏感加BM25或微調(diào)embedding5.2 微調(diào)后模型“變傻”了怎么辦這是過擬合的典型表現(xiàn)。模型在訓(xùn)練集上表現(xiàn)很好但泛化能力下降甚至通用能力也退化了。解決方案降低lora_rank從32降到8或16增加lora_dropout從0.05升到0.1減少epochs從5降到3增加訓(xùn)練數(shù)據(jù)多樣性。如果還不行在訓(xùn)練數(shù)據(jù)里混入10%到20%的通用指令數(shù)據(jù)防止模型“忘記”通用能力。另一個常見問題是災(zāi)難性遺忘。LoRA本身對原模型影響較小但如果target_modules選得太多比如把所有線性層都加上遺忘風(fēng)險會增加。我的建議是只加注意力層的q_proj、k_proj、v_proj、o_proj不要動FFN層。5.3 量化后精度下降明顯怎么調(diào)AWQ量化對校準(zhǔn)數(shù)據(jù)敏感。如果量化后精度下降超過3%換一組更有代表性的校準(zhǔn)數(shù)據(jù)。校準(zhǔn)數(shù)據(jù)應(yīng)該覆蓋模型的典型使用場景不要只用通用語料。GPTQ量化可以調(diào)group_size默認(rèn)128降到64或32能提升精度但顯存占用增加。per-channel量化比per-tensor精度高但推理速度略慢。實操心得量化前先跑一遍FP16的baseline記錄準(zhǔn)確率。量化后再跑一遍對比下降幅度。下降在2%以內(nèi)可以接受超過5%就要重新量化。5.4 vLLM部署的顯存與并發(fā)調(diào)優(yōu)vLLM的顯存管理很智能但配置不當(dāng)也會OOM。排查順序先看max-model-len再看max-num-seqs最后看gpu-memory-utilization。max-model-len設(shè)太大是常見錯誤。如果實際輸入輸出不超過4096 token就不要設(shè)8192。每增加1024 token的max-model-lenKV Cache顯存占用增加約10%。并發(fā)調(diào)優(yōu)max-num-seqs不是越大越好。設(shè)太大每個序列分到的顯存少可能觸發(fā)搶占反而降低吞吐。7B模型在24G卡上max-num-seqs設(shè)16到24比較合適。用vLLM的metrics接口監(jiān)控吞吐和延遲找到最優(yōu)值。# 監(jiān)控vLLM指標(biāo) curl http://localhost:8000/metrics | grep vllm關(guān)注vllm:num_requests_running和vllm:gpu_cache_usage_perc。如果cache usage持續(xù)超過90%說明顯存緊張需要降低并發(fā)或max-model-len。5.5 知識庫更新與版本管理課題組的論文在不斷增加知識庫需要定期更新。我的做法是每月跑一次增量更新新論文解析后追加到Chroma同時用SimHash去重。舊版本的知識庫保留快照方便回溯。embedding模型如果換了整個知識庫需要重新向量化。所以embedding模型的選擇要慎重一旦確定就不要輕易換。如果必須換預(yù)留一天時間做全量重嵌入。微調(diào)模型的版本管理同樣重要。每次微調(diào)后保存LoRA權(quán)重和對應(yīng)的訓(xùn)練數(shù)據(jù)版本號方便復(fù)現(xiàn)和對比。我習(xí)慣用日期數(shù)據(jù)版本命名比如“l(fā)ora_20250115_v2_data500”。6. 一些踩坑后的個人體會整條路線跑下來最大的體會是數(shù)據(jù)質(zhì)量決定上限工程細(xì)節(jié)決定下限。我見過太多人花大量時間調(diào)參結(jié)果訓(xùn)練數(shù)據(jù)里有一半是重復(fù)的、格式混亂的。先把數(shù)據(jù)洗干凈比什么都重要。另一個體會是不要追求一步到位。先搭一個最小可用的RAG跑通“解析-切分-檢索-生成”全流程再逐步優(yōu)化。微調(diào)可以放到最后等RAG的bad case積累夠了再針對性地做微調(diào)。最后分享一個小技巧在RAG的prompt里加一句“如果參考資料中沒有相關(guān)信息請明確說明”能顯著降低幻覺率。模型在不知道答案時傾向于編造這句話給了它一個“安全出口”。這個方向后續(xù)還可以擴展的地方很多多模態(tài)知識庫圖片、表格的檢索、Agent化的知識問答自動調(diào)用工具查數(shù)據(jù)、持續(xù)學(xué)習(xí)新論文自動增量微調(diào)。但那是下一步的事了先把當(dāng)前這套跑穩(wěn)。