1. 為什么要在本地搭一套帶情緒識(shí)別的RAG助手先把話說在前頭這套東西不是玩具。我在過去大半年里幫三個(gè)不同規(guī)模的小團(tuán)隊(duì)落地過本地知識(shí)庫(kù)問答系統(tǒng)從最初用云端API拼湊方案到后來被數(shù)據(jù)合規(guī)和調(diào)用成本逼著往本地遷踩過的坑足夠?qū)懸槐拘?cè)子。這次要聊的本地部署RAG感情智能助手核心訴求其實(shí)就兩件事——數(shù)據(jù)不出內(nèi)網(wǎng)以及讓機(jī)器聽懂人話里的情緒。傳統(tǒng)的RAG問答系統(tǒng)有個(gè)通病你問這個(gè)方案我覺得不太行它只會(huì)傻乎乎地去檢索方案相關(guān)的文檔然后給你返回一堆技術(shù)參數(shù)。但真實(shí)場(chǎng)景里用戶說這句話的時(shí)候情緒是負(fù)面的潛臺(tái)詞是我需要你說服我或者給我一個(gè)替代方案。如果系統(tǒng)能識(shí)別出這個(gè)情緒傾向就能調(diào)整檢索策略和回復(fù)語氣這才是感情智能助手和普通問答機(jī)器人的分水嶺。本地部署這件事繞不開幾個(gè)現(xiàn)實(shí)問題。第一是硬件門檻你得有張像樣的顯卡顯存至少12GB起步不然7B模型跑起來都費(fèi)勁。第二是檢索質(zhì)量純向量檢索在中文場(chǎng)景下經(jīng)常翻車尤其是面對(duì)專業(yè)術(shù)語和縮寫時(shí)所以混合檢索加重排序幾乎是標(biāo)配。第三是情緒識(shí)別模塊的集成這塊很多人直接忽略但它恰恰是讓助手有溫度的關(guān)鍵。適合誰來參考這篇內(nèi)容如果你手頭有一臺(tái)帶獨(dú)顯的工作站想搭一套能理解用戶情緒、檢索準(zhǔn)確率還過得去的本地問答系統(tǒng)那這篇就是寫給你的。如果你只是想跑個(gè)demo玩玩那可能用現(xiàn)成的云端服務(wù)更省事。我下面講的所有東西都是基于實(shí)際跑通并穩(wěn)定運(yùn)行了三個(gè)月的配置不是紙上談兵。提示本地部署的核心矛盾永遠(yuǎn)是效果和資源的平衡。別一上來就追求70B模型先把7B或14B跑順了再考慮往上堆。2. 硬件選型與模型量化別讓顯存成為你的天花板2.1 顯卡和內(nèi)存的真實(shí)需求測(cè)算很多人問我跑本地RAG要什么配置我一般先反問你打算用多大的模型參數(shù)量和顯存的關(guān)系有個(gè)粗略公式——FP16精度下每10億參數(shù)約需2GB顯存。也就是說7B模型全精度加載要14GB左右14B要28GB32B直接奔著64GB去了。這還沒算上KV Cache和檢索模塊的開銷。實(shí)際部署時(shí)量化是必選項(xiàng)。我實(shí)測(cè)下來Q4_K_M量化是效果和體積的最佳平衡點(diǎn)。7B模型量化后約4.5GB14B約9GB32B約20GB。加上檢索模型和重排序模型各占1-2GB再留2GB給系統(tǒng)緩沖配置就清晰了模型規(guī)模量化方式模型顯存檢索重排推薦顯卡最低內(nèi)存7BQ4_K_M4.5GB3GBRTX 3060 12G16GB14BQ4_K_M9GB3GBRTX 4080 16G32GB32BQ4_K_M20GB3GBRTX 4090 24G64GB7BQ8_08GB3GBRTX 4070 12G32GB我自己的主力機(jī)器是RTX 4080 Super加64GB內(nèi)存跑14B的Q4量化模型同時(shí)加載BGE-M3做向量檢索、BGE-Reranker-v2做重排序顯存占用穩(wěn)定在13GB左右留有余量。如果你只有12GB顯存老老實(shí)實(shí)上7B別硬撐。2.2 量化格式的選擇邏輯量化格式這塊GGUF和AWQ是兩條主流路線。GGUF的優(yōu)勢(shì)是CPU和GPU混合推理顯存不夠時(shí)可以往內(nèi)存里塞一部分代價(jià)是速度下降。AWQ則是純GPU推理速度快但顯存要求硬性。我建議顯存剛好夠選AWQ推理速度能快30%以上顯存有缺口選GGUF用n_gpu_layers參數(shù)控制卸載到GPU的層數(shù)追求極致效果Q8_0量化體積翻倍但精度損失極小有個(gè)細(xì)節(jié)很多人不注意量化會(huì)放大模型在情緒識(shí)別任務(wù)上的誤差。我對(duì)比過Q4和Q8在情感分類上的表現(xiàn)Q4的準(zhǔn)確率會(huì)掉3-5個(gè)百分點(diǎn)。所以如果你的情緒識(shí)別模塊是獨(dú)立的小模型建議用Q8如果是靠大模型自身能力判斷那Q4也能湊合。2.3 推理框架的取舍本地推理框架我主要用兩個(gè)Ollama和llama.cpp。Ollama勝在開箱即用一條命令就能拉模型跑起來適合快速驗(yàn)證。但它對(duì)多模型并發(fā)的支持一般而且自定義參數(shù)不夠靈活。llama.cpp則是底層控制力強(qiáng)可以精細(xì)調(diào)整n_batch、n_threads這些參數(shù)適合生產(chǎn)環(huán)境。我現(xiàn)在的方案是Ollama負(fù)責(zé)對(duì)話模型llama.cpp的server模式負(fù)責(zé)嵌入和重排序模型。這樣分工的好處是對(duì)話模型的顯存占用是動(dòng)態(tài)的而嵌入模型常駐顯存互不干擾。啟動(dòng)命令大概長(zhǎng)這樣# 對(duì)話模型 ollama run qwen2.5:14b-instruct-q4_K_M # 嵌入模型服務(wù) ./llama-server -m bge-m3-q8_0.gguf --embedding --port 8081 -ngl 99 # 重排序模型服務(wù) ./llama-server -m bge-reranker-v2-m3-q8_0.gguf --reranking --port 8082 -ngl 99-ngl 99的意思是所有層都卸載到GPU如果你的顯存不夠把這個(gè)數(shù)字調(diào)小讓部分層跑在CPU上。3. 混合檢索加重排序把找得準(zhǔn)這件事做到位3.1 純向量檢索為什么在中文場(chǎng)景下不夠用向量檢索的本質(zhì)是把文本映射到高維空間靠余弦相似度找近鄰。它在語義匹配上很強(qiáng)比如你搜怎么提升檢索準(zhǔn)確率它能找到優(yōu)化召回策略這種字面不同但意思相近的內(nèi)容。但它的短板也很明顯第一對(duì)專有名詞和縮寫不敏感。我測(cè)試過搜RAG瓶頸時(shí)純向量檢索會(huì)把RAG和瓶頸拆開理解返回一堆講檢索增強(qiáng)生成和性能優(yōu)化的文檔但真正講RAG系統(tǒng)在長(zhǎng)文檔場(chǎng)景下的檢索衰減的那篇反而排在第8位。第二對(duì)數(shù)字和代碼不友好。向量模型對(duì)v2.1和v2.2這種版本號(hào)幾乎無感但用戶搜的時(shí)候往往就是要精確匹配。第三長(zhǎng)尾查詢召回率低。當(dāng)查詢?cè)~在訓(xùn)練數(shù)據(jù)里出現(xiàn)頻率很低時(shí)向量表示會(huì)漂移導(dǎo)致檢索結(jié)果發(fā)散。3.2 BM25與向量檢索的融合策略混合檢索的核心思路是讓BM25負(fù)責(zé)精確匹配讓向量負(fù)責(zé)語義匹配然后加權(quán)融合。BM25是經(jīng)典的關(guān)鍵詞檢索算法它基于詞頻和逆文檔頻率打分對(duì)專有名詞和精確匹配特別有效。融合方式有兩種加權(quán)求和和倒數(shù)排名融合RRF。我推薦RRF因?yàn)樗恍枰獨(dú)w一化分?jǐn)?shù)對(duì)兩路檢索的分?jǐn)?shù)尺度不敏感。RRF的公式很簡(jiǎn)單RRF_score Σ 1 / (k rank_i)其中k通常取60rank_i是文檔在第i路檢索中的排名。我實(shí)測(cè)下來RRF在中文RAG場(chǎng)景下比加權(quán)求和穩(wěn)定得多尤其是當(dāng)兩路檢索的分?jǐn)?shù)分布差異很大時(shí)。具體實(shí)現(xiàn)時(shí)我一般這樣配置# 偽代碼示意 bm25_results bm25_search(query, top_k20) vector_results vector_search(query, top_k20) fused rrf_fusion([bm25_results, vector_results], k60)注意top_k要設(shè)大一點(diǎn)給重排序留足候選。我通常設(shè)20-30太少會(huì)導(dǎo)致重排序沒得選太多會(huì)增加延遲。3.3 重排序模型的實(shí)際效果驗(yàn)證重排序是檢索流程的最后一道關(guān)卡它用交叉編碼器Cross-Encoder對(duì)查詢和文檔逐對(duì)打分精度遠(yuǎn)高于向量檢索的雙塔結(jié)構(gòu)。代價(jià)是速度慢所以只能對(duì)少量候選做精排。我做過一組對(duì)比測(cè)試用同一個(gè)知識(shí)庫(kù)約2000篇技術(shù)文檔分別測(cè)純向量、混合檢索、混合重排三種方案方案Top1準(zhǔn)確率Top3召回率平均延遲純向量檢索62%78%120ms混合檢索(RRF)74%86%180ms混合重排序89%94%450ms重排序帶來的提升是肉眼可見的Top1準(zhǔn)確率從74%拉到89%。延遲增加了270ms但在本地部署場(chǎng)景下完全可以接受。我用的重排序模型是BGE-Reranker-v2-M3它對(duì)中文的支持比原版好很多而且支持多語言混合場(chǎng)景。有個(gè)坑要提醒重排序模型的輸入長(zhǎng)度有限制通常是512或1024個(gè)token。如果你的文檔塊切得太大重排序時(shí)會(huì)被截?cái)鄬?dǎo)致打分不準(zhǔn)。所以文檔切分時(shí)塊大小控制在300-500字比較穩(wěn)妥。4. 情緒識(shí)別模塊讓助手聽懂話外之音4.1 情緒識(shí)別的兩條技術(shù)路線給RAG助手加情緒識(shí)別有兩條路可走。第一條是獨(dú)立小模型路線用一個(gè)專門的情感分類模型比如基于BERT微調(diào)的對(duì)用戶輸入做分類輸出正面/負(fù)面/中性或者更細(xì)粒度的情緒標(biāo)簽。第二條是大模型自判路線直接在prompt里讓對(duì)話模型自己判斷用戶情緒然后調(diào)整回復(fù)策略。兩條路各有優(yōu)劣。獨(dú)立小模型的優(yōu)勢(shì)是快且穩(wěn)定一個(gè)6層BERT模型推理只要10-20ms而且分類邊界清晰不會(huì)因?yàn)閜rompt變化而漂移。劣勢(shì)是只能識(shí)別粗粒度情緒對(duì)反諷、隱喻這種復(fù)雜表達(dá)無能為力。大模型自判的優(yōu)勢(shì)是理解力強(qiáng)能捕捉到你說得都對(duì)但是……這種表面肯定實(shí)則否定的表達(dá)。劣勢(shì)是慢而且需要精心設(shè)計(jì)prompt否則模型容易忽略情緒判斷直接去檢索。我的方案是兩者結(jié)合小模型做快速初篩如果置信度低于閾值再交給大模型做二次判斷。這樣既保證了速度又兼顧了復(fù)雜場(chǎng)景。4.2 情緒標(biāo)簽體系的設(shè)計(jì)情緒標(biāo)簽不是越多越好。我見過有人設(shè)計(jì)了28種情緒標(biāo)簽結(jié)果標(biāo)注數(shù)據(jù)不夠模型根本學(xué)不會(huì)。對(duì)于RAG助手這個(gè)場(chǎng)景5-7個(gè)標(biāo)簽足夠了中性純信息查詢無情緒傾向困惑用戶沒看懂或找不到需要更詳細(xì)的解釋不滿對(duì)之前的回答不滿意需要換角度或承認(rèn)不足急切需要快速得到答案回復(fù)要簡(jiǎn)潔直接期待對(duì)某個(gè)方案感興趣需要展開說明懷疑對(duì)信息可信度存疑需要提供依據(jù)這套標(biāo)簽體系是我迭代了三版才定下來的。關(guān)鍵原則是每個(gè)標(biāo)簽都要對(duì)應(yīng)一個(gè)明確的回復(fù)策略。如果某個(gè)標(biāo)簽識(shí)別出來之后你不知道該怎么調(diào)整回復(fù)那這個(gè)標(biāo)簽就是多余的。4.3 情緒如何影響檢索和生成情緒識(shí)別出來之后怎么用我總結(jié)了三個(gè)層面的調(diào)整檢索層面當(dāng)識(shí)別到困惑時(shí)我會(huì)把檢索的top_k從5擴(kuò)大到10并且降低重排序的閾值讓更多可能相關(guān)的文檔進(jìn)入候選。當(dāng)識(shí)別到不滿時(shí)我會(huì)把上一輪的回答從檢索結(jié)果中排除避免重復(fù)返回同樣的內(nèi)容。重排序?qū)用鎸?duì)于急切情緒我會(huì)給短文檔更高的權(quán)重因?yàn)殚L(zhǎng)文檔需要更多閱讀時(shí)間。對(duì)于懷疑情緒我會(huì)給帶有引用來源和數(shù)據(jù)支撐的文檔加權(quán)。生成層面這是最直觀的。系統(tǒng)prompt會(huì)根據(jù)情緒動(dòng)態(tài)調(diào)整比如emotion_prompts { 中性: 請(qǐng)基于檢索結(jié)果準(zhǔn)確回答用戶問題。, 困惑: 用戶可能沒理解請(qǐng)用更通俗的語言解釋并舉例說明。, 不滿: 用戶對(duì)之前的回答不滿意請(qǐng)換一個(gè)角度回答或承認(rèn)之前回答的不足。, 急切: 用戶需要快速答案請(qǐng)直接給出結(jié)論省略推導(dǎo)過程。, 期待: 用戶對(duì)話題感興趣請(qǐng)展開說明提供更多細(xì)節(jié)。, 懷疑: 用戶對(duì)信息存疑請(qǐng)?zhí)峁?shù)據(jù)來源或引用依據(jù)。 }這套機(jī)制跑下來用戶滿意度我用的是簡(jiǎn)單的點(diǎn)贊/點(diǎn)踩統(tǒng)計(jì)從純RAG的68%提升到了82%。提升最明顯的是不滿和困惑兩個(gè)場(chǎng)景因?yàn)橄到y(tǒng)終于知道用戶不高興了我得換個(gè)說法。5. 文檔切分與知識(shí)庫(kù)構(gòu)建檢索質(zhì)量的地基5.1 切分粒度對(duì)檢索效果的影響文檔切分這件事看起來簡(jiǎn)單實(shí)際上決定了檢索質(zhì)量的上限。切太大一個(gè)塊里混了多個(gè)主題向量表示會(huì)模糊切太小上下文丟失檢索出來的片段沒法獨(dú)立回答問題。我試過三種切分策略固定長(zhǎng)度切分、按段落切分、語義切分。固定長(zhǎng)度最簡(jiǎn)單但經(jīng)常把一句話切成兩半。按段落切分保留了語義完整性但段落長(zhǎng)度參差不齊有的段落長(zhǎng)達(dá)上千字。語義切分用模型判斷句子間的語義連貫性效果最好但速度慢。我現(xiàn)在的方案是遞歸字符切分加語義邊界檢測(cè)先按段落切如果段落超過500字再按句子切同時(shí)用簡(jiǎn)單的規(guī)則判斷句子邊界比如句號(hào)、問號(hào)、分號(hào)。這樣既保證了塊大小可控又盡量不破壞語義。塊大小我建議300-500字重疊50-80字。重疊的目的是防止關(guān)鍵信息剛好落在切分邊界上。我實(shí)測(cè)過重疊50字和重疊100字的檢索效果差異不到2%但索引體積差了近20%所以50字是性價(jià)比最高的選擇。5.2 元數(shù)據(jù)設(shè)計(jì)讓檢索多一個(gè)維度很多人建知識(shí)庫(kù)時(shí)只存文本內(nèi)容忽略了元數(shù)據(jù)。但元數(shù)據(jù)在檢索時(shí)能發(fā)揮大作用。我一般會(huì)給每個(gè)文檔塊打上這些標(biāo)簽來源文件方便追溯和引用章節(jié)標(biāo)題提供上下文文檔類型技術(shù)文檔、FAQ、操作手冊(cè)等更新時(shí)間用于時(shí)效性加權(quán)情緒標(biāo)簽如果文檔本身帶有情緒色彩比如用戶反饋可以標(biāo)注檢索時(shí)這些元數(shù)據(jù)可以作為過濾條件。比如用戶問最新的部署方案我可以在檢索時(shí)加一個(gè)更新時(shí)間 2024-01-01的過濾避免返回過時(shí)信息。5.3 知識(shí)庫(kù)更新與增量索引知識(shí)庫(kù)不是建一次就完事的。我維護(hù)的知識(shí)庫(kù)每周都有新文檔進(jìn)來如果每次更新都全量重建索引2000篇文檔要跑將近半小時(shí)。所以增量索引是必須的。我的做法是用文檔哈希值判斷是否變更。每個(gè)文檔塊存一個(gè)MD5哈希更新時(shí)只對(duì)哈希變化的塊重新計(jì)算向量。這樣每周的增量更新只需要2-3分鐘。有個(gè)細(xì)節(jié)要注意刪除文檔時(shí)要同步刪除向量索引和BM25索引。我早期版本只刪了向量索引結(jié)果BM25還能檢索到已刪除的內(nèi)容導(dǎo)致回答里出現(xiàn)幽靈引用。這個(gè)bug排查了整整一個(gè)下午才定位到。6. 踩坑實(shí)錄那些文檔里不會(huì)寫的教訓(xùn)6.1 顯存泄漏跑著跑著就OOM了這個(gè)問題困擾了我將近兩周?，F(xiàn)象是系統(tǒng)剛啟動(dòng)時(shí)顯存占用12GB跑了幾十個(gè)請(qǐng)求后漲到15GB然后突然OOM崩潰。重啟后又恢復(fù)正常但過一陣子又崩。排查過程很曲折。我先用nvidia-smi監(jiān)控顯存發(fā)現(xiàn)每次請(qǐng)求后顯存都會(huì)漲一點(diǎn)點(diǎn)但不會(huì)釋放。一開始懷疑是模型加載的問題換了幾個(gè)推理框架都一樣。后來用Python的tracemalloc追蹤內(nèi)存分配發(fā)現(xiàn)是重排序模型的輸入張量沒有及時(shí)釋放。具體原因是我在每次請(qǐng)求時(shí)都新建了一個(gè)tokenizer對(duì)象而這個(gè)對(duì)象持有對(duì)模型權(quán)重的引用導(dǎo)致垃圾回收器無法釋放。改成全局單例之后顯存占用穩(wěn)定在13GB跑一整天都不漲。注意本地部署時(shí)任何在請(qǐng)求循環(huán)內(nèi)創(chuàng)建的對(duì)象都要警惕。tokenizer、session、連接池這些東西能復(fù)用就復(fù)用別每次新建。6.2 檢索結(jié)果看起來相關(guān)但答非所問這個(gè)問題更隱蔽。用戶問怎么配置重排序模型的batch size檢索返回的文檔標(biāo)題是重排序模型參數(shù)說明看起來完全對(duì)口但內(nèi)容講的是訓(xùn)練時(shí)的batch size不是推理時(shí)的。根因是向量檢索對(duì)配置和訓(xùn)練這兩個(gè)詞的區(qū)分度不夠。在向量空間里它們距離很近因?yàn)榻?jīng)常一起出現(xiàn)。但在實(shí)際語義上用戶要的是推理配置不是訓(xùn)練配置。解決方案有兩個(gè)一是在重排序階段引入查詢意圖分類先判斷用戶問的是訓(xùn)練還是推理然后給對(duì)應(yīng)文檔加權(quán)。二是在文檔切分時(shí)把訓(xùn)練配置和推理配置拆成兩個(gè)獨(dú)立的塊避免混在一起。我兩個(gè)都做了效果立竿見影。6.3 情緒識(shí)別的誤傷把正常提問當(dāng)成不滿情緒識(shí)別模塊上線第一周我收到一個(gè)反饋用戶正常問這個(gè)功能怎么用系統(tǒng)卻識(shí)別成不滿然后回復(fù)了一堆抱歉之前的回答讓您不滿意之類的話把用戶搞懵了。查了日志才發(fā)現(xiàn)問題出在訓(xùn)練數(shù)據(jù)偏差上。我的情感分類模型是用公開數(shù)據(jù)集微調(diào)的而那個(gè)數(shù)據(jù)集里的怎么用類問句大多來自客服場(chǎng)景標(biāo)注為不滿因?yàn)橛脩粢呀?jīng)嘗試過但失敗了。但在我的場(chǎng)景里用戶就是單純地問怎么用沒有不滿情緒。修復(fù)方法是用自己場(chǎng)景的數(shù)據(jù)重新微調(diào)。我收集了500條真實(shí)用戶問句人工標(biāo)注情緒然后對(duì)模型做了一輪增量訓(xùn)練。準(zhǔn)確率從71%提升到88%誤傷率大幅下降。這件事給我的教訓(xùn)是情緒識(shí)別模型必須用自己場(chǎng)景的數(shù)據(jù)調(diào)公開數(shù)據(jù)集只能做預(yù)訓(xùn)練不能直接拿來用。6.4 長(zhǎng)文檔檢索的中間迷失問題當(dāng)知識(shí)庫(kù)里有超過5000字的長(zhǎng)文檔時(shí)檢索效果會(huì)明顯下降?，F(xiàn)象是文檔開頭和結(jié)尾的內(nèi)容容易被檢索到但中間部分經(jīng)常被忽略。這就是所謂的中間迷失Lost in the Middle問題。原因是向量模型對(duì)長(zhǎng)文本的編碼會(huì)偏向開頭和結(jié)尾中間部分的權(quán)重被稀釋。解決方案是對(duì)長(zhǎng)文檔做分層切分先按章節(jié)切每個(gè)章節(jié)再按段落切檢索時(shí)先定位章節(jié)再在章節(jié)內(nèi)做細(xì)粒度檢索。我實(shí)現(xiàn)了一個(gè)簡(jiǎn)單的兩層檢索第一層用章節(jié)摘要做粗篩第二層用段落內(nèi)容做精排。這樣長(zhǎng)文檔的中間部分也能被有效檢索到Top3召回率從61%提升到83%。7. 性能調(diào)優(yōu)讓系統(tǒng)跑得更快更穩(wěn)7.1 批處理與并發(fā)控制本地部署的資源是有限的如果不控制并發(fā)幾個(gè)請(qǐng)求同時(shí)進(jìn)來就會(huì)把顯存打滿。我的做法是用隊(duì)列做請(qǐng)求緩沖設(shè)置最大并發(fā)數(shù)為2針對(duì)14B模型超出的請(qǐng)求排隊(duì)等待。批處理是另一個(gè)優(yōu)化點(diǎn)。嵌入模型和重排序模型都支持批處理一次處理8-16個(gè)文本塊比逐個(gè)處理快3-5倍。但批處理會(huì)增加顯存峰值所以要權(quán)衡。我的配置是嵌入模型batch_size16重排序模型batch_size8這樣顯存峰值控制在15GB以內(nèi)。7.2 緩存策略別重復(fù)計(jì)算RAG系統(tǒng)里有大量重復(fù)計(jì)算。同一個(gè)查詢可能被多個(gè)用戶問到同一個(gè)文檔塊可能被多次檢索。我加了兩級(jí)緩存查詢緩存對(duì)用戶查詢做歸一化去空格、轉(zhuǎn)小寫后哈希如果命中緩存直接返回結(jié)果。緩存有效期設(shè)為1小時(shí)因?yàn)橹R(shí)庫(kù)更新后緩存要失效。向量緩存文檔塊的向量計(jì)算一次后就存起來更新時(shí)只重算變化的塊。這個(gè)前面提過是增量索引的基礎(chǔ)。緩存帶來的提升很明顯重復(fù)查詢的響應(yīng)時(shí)間從450ms降到20ms整體QPS提升了近3倍。7.3 監(jiān)控與告警別等崩了才知道本地部署沒有云服務(wù)那種自動(dòng)告警得自己搭。我用的是最簡(jiǎn)單的方案一個(gè)Python腳本每30秒采集一次顯存占用、CPU使用率、請(qǐng)求延遲寫到本地文件再用Grafana做可視化。關(guān)鍵指標(biāo)有三個(gè)顯存占用率超過90%要告警請(qǐng)求延遲P99超過2秒要告警錯(cuò)誤率超過5%要告警。這三個(gè)指標(biāo)能覆蓋大部分異常情況。我還加了一個(gè)健康檢查接口定期發(fā)一個(gè)測(cè)試查詢驗(yàn)證整個(gè)鏈路是否正常。有次重排序模型服務(wù)掛了但對(duì)話模型還在跑用戶提問能返回結(jié)果但質(zhì)量很差。健康檢查發(fā)現(xiàn)重排序服務(wù)的響應(yīng)異常及時(shí)告警避免了更嚴(yán)重的問題。8. 實(shí)際效果與適用邊界這套系統(tǒng)在我這邊跑了三個(gè)月日均處理約200個(gè)查詢覆蓋技術(shù)文檔檢索、產(chǎn)品FAQ、內(nèi)部知識(shí)問答三個(gè)場(chǎng)景。幾個(gè)關(guān)鍵數(shù)據(jù)首答準(zhǔn)確率86%人工抽檢平均響應(yīng)時(shí)間1.2秒顯存占用穩(wěn)定在13-14GB連續(xù)運(yùn)行30天無崩潰。但它不是萬能的。有幾類場(chǎng)景效果明顯打折需要多跳推理的問題比如A和B的關(guān)系是什么這種關(guān)系對(duì)C有什么影響涉及最新事件的問題知識(shí)庫(kù)沒更新高度依賴圖表的問題純文本RAG處理不了圖片。這些邊界我心里有數(shù)遇到這類查詢會(huì)主動(dòng)提示用戶這個(gè)問題可能超出我的知識(shí)范圍。最后分享一個(gè)我踩過的小坑別在系統(tǒng)prompt里寫太多規(guī)則。我一開始寫了將近800字的prompt詳細(xì)規(guī)定各種情緒下該怎么回復(fù)結(jié)果模型經(jīng)常忽略其中的某幾條。后來精簡(jiǎn)到300字只保留最核心的規(guī)則遵守率反而提高了。模型不是人規(guī)則太多它會(huì)分心。