優(yōu)與生成約束)
RAG 這個(gè)詞這兩年出現(xiàn)的頻率越來(lái)越高但凡聊到讓大模型“說(shuō)自己的話(huà)、答自己的料”基本繞不開(kāi)它。我最早接觸 RAG 是在一個(gè)內(nèi)部知識(shí)庫(kù)問(wèn)答的需求里當(dāng)時(shí)團(tuán)隊(duì)想讓模型能回答產(chǎn)品手冊(cè)、運(yùn)維文檔里的細(xì)節(jié)問(wèn)題直接微調(diào)成本太高、更新又慢于是把目光轉(zhuǎn)向了檢索增強(qiáng)生成這條路。實(shí)測(cè)下來(lái)RAG 確實(shí)是目前把私有數(shù)據(jù)接進(jìn)大模型最務(wù)實(shí)的一種做法不用動(dòng)模型權(quán)重?cái)?shù)據(jù)更新只需重建索引回答還能給出出處排查問(wèn)題時(shí)心里有底。這篇內(nèi)容我想把 RAG 的原理講透再把本地化落地這一整套流程拆開(kāi)揉碎講清楚——從文檔怎么切、向量怎么選、檢索怎么調(diào)到生成環(huán)節(jié)怎么約束模型別亂編。適合剛接觸 RAG 想搞明白底層邏輯的開(kāi)發(fā)者也適合已經(jīng)跑通 demo 但效果不穩(wěn)定、想找優(yōu)化方向的朋友。全文基于我在幾個(gè)內(nèi)部項(xiàng)目里的實(shí)際做法整理涉及參數(shù)的地方會(huì)給計(jì)算過(guò)程和取舍理由能直接抄作業(yè)的部分我會(huì)盡量寫(xiě)細(xì)。1. RAG 到底在解決什么問(wèn)題1.1 大模型的三個(gè)硬傷與 RAG 的定位先把問(wèn)題擺清楚不然容易把 RAG 當(dāng)成萬(wàn)能藥。大模型有三個(gè)繞不過(guò)去的硬傷一是知識(shí)有截止時(shí)間訓(xùn)練數(shù)據(jù)之后發(fā)生的事情它不知道二是私有數(shù)據(jù)進(jìn)不去公司內(nèi)部的文檔、代碼、工單它沒(méi)見(jiàn)過(guò)三是容易一本正經(jīng)地胡說(shuō)也就是幻覺(jué)尤其在它不確定的時(shí)候反而答得更自信。解決這三類(lèi)問(wèn)題常見(jiàn)有三條路微調(diào)、長(zhǎng)上下文直接塞、RAG。微調(diào)是把知識(shí)“焊”進(jìn)權(quán)重里成本高、更新慢而且容易災(zāi)難性遺忘適合學(xué)風(fēng)格和格式不適合頻繁變動(dòng)的知識(shí)。長(zhǎng)上下文是把資料全塞進(jìn) prompt簡(jiǎn)單粗暴但受窗口限制、成本隨長(zhǎng)度線(xiàn)性上漲資料一多就撐不住。RAG 的思路不一樣它是在生成之前先去外部知識(shí)庫(kù)里檢索相關(guān)內(nèi)容把檢索結(jié)果作為上下文喂給模型讓模型“看著資料答題”。打個(gè)生活化的比方微調(diào)像是讓學(xué)生把整本教材背下來(lái)考試RAG 像是開(kāi)卷考試允許帶資料進(jìn)場(chǎng)答題前先翻到相關(guān)那幾頁(yè)。開(kāi)卷的好處是資料可以隨時(shí)換、答案有據(jù)可查壞處是翻書(shū)翻得不準(zhǔn)就會(huì)答偏——這也正是 RAG 效果好壞的關(guān)鍵所在。所以 RAG 的定位很明確它解決的是“知識(shí)從哪來(lái)”的問(wèn)題不解決“模型會(huì)不會(huì)推理”的問(wèn)題。檢索到的資料質(zhì)量決定了回答的上限模型的能力決定了能不能把資料用好。理解這個(gè)邊界后面調(diào)優(yōu)時(shí)就不會(huì)把檢索的鍋甩給模型也不會(huì)指望換個(gè)更大的模型就能救回爛檢索。1.2 RAG 的完整鏈路拆解一條完整的 RAG 鏈路我習(xí)慣拆成離線(xiàn)和在線(xiàn)兩段。離線(xiàn)段是數(shù)據(jù)準(zhǔn)備文檔采集、清洗、切分、向量化、入庫(kù)這一步是一次性或周期性的。在線(xiàn)段是每次問(wèn)答實(shí)時(shí)跑的query 進(jìn)來(lái)先做向量化去庫(kù)里檢索 top-k 相關(guān)片段拼進(jìn) prompt交給模型生成最后把答案和出處一起返回。這里面每一環(huán)都有坑。切分切得不好一個(gè)完整語(yǔ)義被攔腰截?cái)鄼z索出來(lái)就是半句話(huà)向量模型選得不對(duì)語(yǔ)義相似度算不準(zhǔn)該召回的沒(méi)召回top-k 設(shè)得太大噪聲片段擠占上下文模型反而被帶偏prompt 約束不到位模型看著資料還能自由發(fā)揮。我見(jiàn)過(guò)不少 demo 跑得挺順、一上真實(shí)數(shù)據(jù)就拉胯的案例問(wèn)題基本都出在這幾個(gè)環(huán)節(jié)的細(xì)節(jié)上而不是框架本身。下面這張表是我對(duì)鏈路各環(huán)節(jié)影響權(quán)重的粗略判斷基于幾個(gè)項(xiàng)目的調(diào)優(yōu)經(jīng)驗(yàn)不是絕對(duì)數(shù)值但能幫你判斷優(yōu)化優(yōu)先級(jí)環(huán)節(jié)對(duì)最終效果的影響調(diào)優(yōu)難度常見(jiàn)問(wèn)題文檔切分高中語(yǔ)義截?cái)?、塊過(guò)大過(guò)小向量模型高低換模型即可領(lǐng)域不匹配、中文支持差檢索策略高中高單一向量召回漏檢重排序中中排序不準(zhǔn)、引入延遲Prompt 約束中高低模型自由發(fā)揮、不引用生成模型中低換模型即可指令遵循差從表里能看出來(lái)切分、向量、檢索這三塊是重頭戲也是本地化實(shí)踐里最花時(shí)間的地方。生成模型反而是最容易換的效果不行換一個(gè)就行但前面三塊爛了換再?gòu)?qiáng)的模型也白搭。2. 本地化落地的整體架構(gòu)設(shè)計(jì)2.1 為什么選擇本地化而不是調(diào) API先說(shuō)清楚為什么要本地化。調(diào)云端 API 跑 RAG 當(dāng)然省事但有幾類(lèi)場(chǎng)景繞不開(kāi)本地部署數(shù)據(jù)敏感不能出內(nèi)網(wǎng)、調(diào)用量大成本扛不住、需要離線(xiàn)可用、對(duì)延遲有硬要求。我參與的幾個(gè)項(xiàng)目基本都是前兩個(gè)原因內(nèi)部文檔涉及業(yè)務(wù)細(xì)節(jié)走外網(wǎng)不合規(guī)量大了按 token 計(jì)費(fèi)一個(gè)月賬單能?chē)標(biāo)廊恕１镜鼗暮诵氖前严蛄磕Ｐ?、向量?kù)、生成模型三樣都放在自己機(jī)器上。這里有個(gè)關(guān)鍵取舍生成模型本地跑對(duì)硬件要求最高7B 級(jí)別的模型量化后大概需要 6-8G 顯存13B 要 12-16G再大就得靠多卡或者更激進(jìn)的量化。如果硬件有限一個(gè)折中方案是檢索和向量化本地做生成走內(nèi)網(wǎng)自建的推理服務(wù)既保證數(shù)據(jù)不出內(nèi)網(wǎng)又不至于被單機(jī)顯存卡死。我的建議是先把鏈路跑通再談性能。一開(kāi)始別追求大模型7B 量化版足夠驗(yàn)證流程等檢索調(diào)好了、prompt 定型了再根據(jù)效果決定要不要上更大的模型。很多人一上來(lái)就糾結(jié)模型選型結(jié)果檢索一塌糊涂換了三個(gè)模型都沒(méi)救回來(lái)白白浪費(fèi)時(shí)間。2.2 組件選型與硬件估算組件選型我按“夠用、好維護(hù)、社區(qū)活躍”三個(gè)標(biāo)準(zhǔn)來(lái)。向量模型優(yōu)先看中文語(yǔ)義能力本地部署常用的是 BGE 系列或者 M3E 這類(lèi)中文優(yōu)化過(guò)的模型維度一般是 768 或 1024。向量庫(kù)方面數(shù)據(jù)量在百萬(wàn)級(jí)以?xún)?nèi)輕量方案完全夠用沒(méi)必要上重型分布式庫(kù)數(shù)據(jù)量再大或者要支持復(fù)雜過(guò)濾再考慮更專(zhuān)業(yè)的向量數(shù)據(jù)庫(kù)。硬件估算給個(gè)參考算法。向量庫(kù)內(nèi)存占用大致等于向量條數(shù) × 維度 × 4 字節(jié)float32比如 50 萬(wàn)條 768 維向量就是 500000 × 768 × 4 ≈ 1.5GB加上索引開(kāi)銷(xiāo)按 1.5 倍算2GB 出頭很輕。生成模型這邊7B 模型 FP16 需要約 14GB 顯存4bit 量化后約 4-5GB加上 KV cache 和上下文開(kāi)銷(xiāo)8G 顯存能跑但上下文別開(kāi)太大。這些數(shù)字是我實(shí)測(cè)的粗略值具體會(huì)因框架和量化方式有浮動(dòng)。注意向量維度不是越高越好。1024 維比 768 維召回略好但存儲(chǔ)和計(jì)算都漲三成數(shù)據(jù)量不大時(shí)收益不明顯。先用 768 維跑通效果不夠再升維。3. 文檔處理與切分RAG 效果的地基3.1 文檔清洗與格式統(tǒng)一這一步最枯燥但最不能省。真實(shí)文檔五花八門(mén)PDF 有頁(yè)眉頁(yè)腳、掃描件是圖片、Word 里有大量樣式標(biāo)記、網(wǎng)頁(yè)抓下來(lái)一堆導(dǎo)航欄。直接把這些丟進(jìn)去切分切出來(lái)的全是噪聲。我的做法是先統(tǒng)一轉(zhuǎn)成純文本或 Markdown再做一輪清洗。PDF 提取優(yōu)先用能保留結(jié)構(gòu)的解析方式掃描件得先走 OCR。清洗規(guī)則我一般會(huì)做這幾件事去掉連續(xù)空行和多余空格、剔除頁(yè)眉頁(yè)腳這類(lèi)重復(fù)出現(xiàn)的行、把表格轉(zhuǎn)成結(jié)構(gòu)化文本表格直接切分很容易散架、統(tǒng)一標(biāo)點(diǎn)和全半角。這里有個(gè)容易忽略的點(diǎn)保留標(biāo)題層級(jí)信息。標(biāo)題是天然的語(yǔ)義邊界切分時(shí)如果能帶上所屬章節(jié)標(biāo)題檢索出來(lái)的片段可讀性和相關(guān)性都會(huì)好很多。清洗完建議抽樣人工看幾十條確認(rèn)沒(méi)有大面積亂碼或結(jié)構(gòu)丟失。我踩過(guò)一次坑某批 PDF 提取出來(lái)中文全是亂碼沒(méi)檢查就入庫(kù)了結(jié)果檢索永遠(yuǎn)召回一堆亂碼片段排查了半天才發(fā)現(xiàn)是提取環(huán)節(jié)的問(wèn)題。3.2 切分策略與參數(shù)計(jì)算切分是 RAG 里最需要?jiǎng)幽X子的環(huán)節(jié)。切太大一個(gè)塊里混了好幾個(gè)主題檢索精度下降切太小語(yǔ)義不完整模型拿到半句話(huà)沒(méi)法答。業(yè)界常用的起點(diǎn)是塊大小 500-800 字符、重疊 50-100 字符但這個(gè)值必須按你的文檔類(lèi)型調(diào)。重疊的作用是防止語(yǔ)義在邊界被切斷。比如一句話(huà)正好跨在兩個(gè)塊之間有重疊就能保證至少有一個(gè)塊包含完整句子。重疊比例一般取塊大小的 10%-20%太小起不到保護(hù)作用太大又造成冗余存儲(chǔ)和重復(fù)召回。我一般用遞歸切分先按段落切段落超長(zhǎng)再按句子切句子還超長(zhǎng)才硬切。這樣能最大限度保住語(yǔ)義邊界。代碼上大致是這樣from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size600, chunk_overlap80, separators[\n\n, \n, 。, , , , , ], ) chunks splitter.split_text(cleaned_text)注意 separators 里中文標(biāo)點(diǎn)要放在英文空格之前因?yàn)橹形奈臋n主要靠句號(hào)問(wèn)號(hào)斷句。這個(gè)順序錯(cuò)了切分質(zhì)量會(huì)明顯下降。另外技術(shù)文檔和 FAQ 類(lèi)文檔的切分邏輯不一樣FAQ 最好一問(wèn)一答作為一個(gè)塊別把問(wèn)題和答案切開(kāi)技術(shù)文檔按章節(jié)切更合理。沒(méi)有萬(wàn)能參數(shù)只能拿真實(shí)數(shù)據(jù)試切完抽幾條看看是不是完整語(yǔ)義。3.3 元數(shù)據(jù)設(shè)計(jì)被低估的檢索增強(qiáng)手段很多人只存文本和向量其實(shí)元數(shù)據(jù)能大幅提升檢索質(zhì)量。我通常會(huì)給每個(gè)塊打上來(lái)源文件名、章節(jié)標(biāo)題、頁(yè)碼、更新時(shí)間這些標(biāo)簽。好處有兩個(gè)一是檢索時(shí)可以按元數(shù)據(jù)過(guò)濾比如只搜某個(gè)產(chǎn)品線(xiàn)的文檔二是生成時(shí)可以把出處帶給用戶(hù)答案可信度立刻不一樣。更進(jìn)一步可以在塊文本前面拼上章節(jié)標(biāo)題再向量化相當(dāng)于給每個(gè)塊加了“上下文前綴”。實(shí)測(cè)這個(gè)做法對(duì)召回率有肉眼可見(jiàn)的提升因?yàn)闃?biāo)題里往往包含關(guān)鍵主題詞能幫向量模型更好地理解這個(gè)塊在講什么。成本幾乎為零強(qiáng)烈建議加上。4. 向量化與檢索調(diào)優(yōu)實(shí)戰(zhàn)4.1 向量模型的選擇與本地部署向量模型決定了語(yǔ)義相似度算得準(zhǔn)不準(zhǔn)是檢索質(zhì)量的天花板。選型時(shí)重點(diǎn)看兩點(diǎn)中文語(yǔ)義能力和領(lǐng)域匹配度。通用模型在通用語(yǔ)料上表現(xiàn)不錯(cuò)但遇到專(zhuān)業(yè)術(shù)語(yǔ)密集的領(lǐng)域比如醫(yī)療、法律、工控召回會(huì)明顯下降。這種情況要么找領(lǐng)域微調(diào)過(guò)的模型要么自己拿領(lǐng)域語(yǔ)料做對(duì)比學(xué)習(xí)微調(diào)后者成本高但效果最實(shí)在。本地部署向量模型很輕一個(gè)幾百 M 的模型 CPU 都能跑批量向量化時(shí)用 GPU 加速會(huì)快很多。部署時(shí)注意歸一化算余弦相似度前要把向量歸一化成單位向量這樣內(nèi)積就等于余弦相似度檢索時(shí)直接用內(nèi)積索引更快。很多框架默認(rèn)幫你做了但自己寫(xiě)代碼時(shí)容易漏。批量向量化有個(gè)細(xì)節(jié)batch size 別設(shè)太大顯存不夠會(huì) OOM也別太小吞吐上不去。我一般從 32 開(kāi)始試看顯存占用往上加。另外入庫(kù)前一定要校驗(yàn)向量維度一致混入不同模型產(chǎn)生的向量會(huì)導(dǎo)致檢索結(jié)果完全錯(cuò)亂這種問(wèn)題排查起來(lái)很痛苦。4.2 檢索策略從單一向量到混合召回單一向量檢索有個(gè)天然短板它對(duì)精確匹配不敏感。用戶(hù)問(wèn)一個(gè)具體的型號(hào)、編號(hào)、專(zhuān)有名詞向量檢索可能召回一堆語(yǔ)義相近但沒(méi)命中關(guān)鍵詞的片段。解決辦法是混合檢索向量召回負(fù)責(zé)語(yǔ)義相似關(guān)鍵詞召回比如 BM25負(fù)責(zé)精確匹配兩路結(jié)果融合排序。融合常用 RRF倒數(shù)排名融合邏輯很簡(jiǎn)單每個(gè)文檔在每路召回里的排名取倒數(shù)相加排名越靠前得分越高兩路都靠前的文檔最終得分最高。這個(gè)算法不需要調(diào)權(quán)重魯棒性好我基本默認(rèn)用它。偽代碼大概是這樣def rrf_fusion(vector_results, keyword_results, k60): scores {} for rank, doc_id in enumerate(vector_results): scores[doc_id] scores.get(doc_id, 0) 1 / (k rank 1) for rank, doc_id in enumerate(keyword_results): scores[doc_id] scores.get(doc_id, 0) 1 / (k rank 1) return sorted(scores.items(), keylambda x: x[1], reverseTrue)k 取 60 是論文里的經(jīng)驗(yàn)值實(shí)際用下來(lái) 40-80 之間差別不大?；旌蠙z索的代價(jià)是多一路召回和融合計(jì)算延遲會(huì)漲一些但對(duì)召回率的提升很值尤其是文檔里專(zhuān)有名詞多的時(shí)候。4.3 重排序用精度換召回檢索階段為了不漏top-k 一般設(shè)得比較大比如 20-50但真正喂給模型的只能留幾條3-5 條不然上下文塞滿(mǎn)噪聲。這中間的篩選就靠重排序。重排序模型reranker比向量模型更重、更準(zhǔn)它對(duì) query 和每個(gè)候選片段做交叉編碼算出精細(xì)的相關(guān)性分?jǐn)?shù)再取 top-n。這個(gè)思路叫“召回求全、排序求精”。向量檢索快但粗reranker 慢但準(zhǔn)兩級(jí)配合能在延遲可控的前提下大幅提升精度。實(shí)測(cè)下來(lái)加了 reranker 之后喂給模型的片段相關(guān)性明顯提升模型答非所問(wèn)的情況少了很多。代價(jià)是延遲。reranker 對(duì)每個(gè)候選都要跑一次模型20 個(gè)候選就是 20 次推理用 GPU 加速后一般能控制在幾百毫秒。如果對(duì)延遲極敏感可以只對(duì) top-10 做重排或者用更小的 reranker 模型。我的經(jīng)驗(yàn)是這一步的性?xún)r(jià)比很高除非延遲卡死否則別省。4.4 檢索參數(shù)調(diào)優(yōu)的實(shí)操方法參數(shù)調(diào)優(yōu)別拍腦袋要有評(píng)估集。做法是人工構(gòu)造幾十到上百條“問(wèn)題-標(biāo)準(zhǔn)答案-應(yīng)召回的文檔塊”三元組然后跑檢索看命中率。核心指標(biāo)看兩個(gè)Recallk前 k 條里有沒(méi)有包含正確塊和MRR正確塊排得靠不靠前。Recall 低說(shuō)明召回不夠加大 k 或換模型MRR 低說(shuō)明排序不準(zhǔn)上 reranker。我一般按這個(gè)順序調(diào)先固定切分和向量模型調(diào) k 看 Recall 曲線(xiàn)找到 Recall 不再明顯上升的拐點(diǎn)再上混合檢索看提升最后加 reranker 看 MRR。每一步都記錄指標(biāo)別一次改多個(gè)變量不然不知道是哪個(gè)改動(dòng)起的作用。這套流程聽(tīng)起來(lái)笨但比憑感覺(jué)調(diào)靠譜得多。5. Prompt 設(shè)計(jì)與生成約束5.1 上下文拼裝與引用規(guī)范檢索到的片段怎么拼進(jìn) prompt直接影響模型能不能用好。我的模板一般包含三部分系統(tǒng)指令你是基于資料回答的助手資料里沒(méi)有就說(shuō)不知道、檢索到的片段帶編號(hào)和出處、用戶(hù)問(wèn)題。片段之間用明確的分隔符隔開(kāi)并標(biāo)注來(lái)源方便模型引用。關(guān)鍵約束有兩條只依據(jù)資料回答、資料不足時(shí)明確說(shuō)不知道。這兩條能大幅壓低幻覺(jué)率。但光寫(xiě)指令不夠模型有時(shí)還是會(huì)自由發(fā)揮所以我會(huì)在 prompt 里要求它回答時(shí)標(biāo)注引用的片段編號(hào)這樣即使它編了也能通過(guò)引用是否對(duì)得上快速發(fā)現(xiàn)。提示片段數(shù)量別貪多。3-5 條高質(zhì)量片段比 10 條混雜的效果好因?yàn)樯舷挛脑介L(zhǎng)模型越容易抓錯(cuò)重點(diǎn)而且長(zhǎng)上下文本身有“中間遺忘”現(xiàn)象關(guān)鍵信息放中間容易被忽略。把最相關(guān)的放最前面。5.2 生成模型本地部署與量化取舍本地跑生成模型量化是繞不開(kāi)的話(huà)題。常見(jiàn)的有 4bit、8bit 量化量化越狠顯存占用越小但精度損失越大。我的經(jīng)驗(yàn)是8bit 量化基本無(wú)損4bit 在多數(shù)問(wèn)答任務(wù)上可接受但涉及數(shù)字計(jì)算、代碼生成這類(lèi)任務(wù)時(shí) 4bit 容易出錯(cuò)。如果硬件允許優(yōu)先 8bit實(shí)在緊張?jiān)偕?4bit并且重點(diǎn)驗(yàn)證量化后在你任務(wù)上的表現(xiàn)。推理框架方面本地部署常用的是支持量化和高效推理的那幾套選型時(shí)看它對(duì)量化格式的支持和吞吐表現(xiàn)。部署時(shí)注意上下文長(zhǎng)度設(shè)置RAG 場(chǎng)景下上下文要能裝下系統(tǒng)指令加幾條片段一般設(shè) 4K-8K 夠用設(shè)太大反而吃顯存。溫度參數(shù)建議調(diào)低0.1-0.3RAG 要的是忠實(shí)于資料不需要?jiǎng)?chuàng)造性。5.3 答案后處理與出處回填生成完別直接返回做一層后處理能提升體驗(yàn)。常見(jiàn)的有把模型標(biāo)注的片段編號(hào)映射回真實(shí)出處文件名、頁(yè)碼拼在答案末尾檢查答案里有沒(méi)有“根據(jù)資料”這類(lèi)空話(huà)有的話(huà)精簡(jiǎn)掉對(duì)超長(zhǎng)答案做截?cái)嗷蚍侄?。如果模型輸出了引用編?hào)但內(nèi)容對(duì)不上可以標(biāo)記為“低置信”提示用戶(hù)核實(shí)。這一層還能做兜底如果檢索階段最高分低于某個(gè)閾值說(shuō)明庫(kù)里可能根本沒(méi)有相關(guān)內(nèi)容這時(shí)直接返回“未找到相關(guān)資料”比讓模型硬答要誠(chéng)實(shí)得多。閾值怎么定拿評(píng)估集跑一遍看正樣本和負(fù)樣本的分?jǐn)?shù)分布取一個(gè)能分開(kāi)兩者的值我一般取正樣本最低分的 80% 左右作為保守閾值。6. 常見(jiàn)問(wèn)題排查與避坑實(shí)錄6.1 效果問(wèn)題的定位思路RAG 效果不好先別急著換模型按鏈路逐段排查。我總結(jié)了一個(gè)排查順序先看檢索再看拼裝最后看生成。具體做法是拿一個(gè)答錯(cuò)的問(wèn)題手動(dòng)看檢索出來(lái)的片段里有沒(méi)有正確答案。如果沒(méi)有問(wèn)題在檢索切分、向量、召回策略如果有但模型沒(méi)答對(duì)問(wèn)題在拼裝或生成prompt、上下文順序、模型能力。這個(gè)二分法能快速定位問(wèn)題域。我見(jiàn)過(guò)太多人一上來(lái)就懷疑模型不行結(jié)果一查檢索正確片段壓根沒(méi)召回?fù)Q十個(gè)模型也沒(méi)用。反過(guò)來(lái)檢索沒(méi)問(wèn)題但答案還是錯(cuò)那才輪到調(diào) prompt 或換模型。6.2 高頻問(wèn)題速查表下面這張表是我在實(shí)際項(xiàng)目里整理的高頻問(wèn)題和對(duì)應(yīng)處理辦法按出現(xiàn)頻率排序現(xiàn)象可能原因排查與處理答非所問(wèn)檢索召回不相關(guān)檢查切分是否截?cái)嗾Z(yǔ)義換向量模型加混合檢索說(shuō)不知道但庫(kù)里有召回沒(méi)命中加大 top-k檢查 query 改寫(xiě)確認(rèn)向量維度一致答案含資料外內(nèi)容prompt 約束不足強(qiáng)化“僅依據(jù)資料”指令降低溫度要求引用專(zhuān)有名詞答錯(cuò)精確匹配弱加 BM25 關(guān)鍵詞召回混合融合長(zhǎng)文檔答不全上下文截?cái)鄼z查塊大小和 top-k確認(rèn)上下文長(zhǎng)度夠響應(yīng)慢reranker 或模型推理慢減候選數(shù)換小模型開(kāi) GPU 加速重復(fù)召回同一段重疊過(guò)大降低 chunk_overlap檢索后去重6.3 幾個(gè)踩過(guò)的坑第一個(gè)坑是向量庫(kù)更新不同步。文檔更新了但索引沒(méi)重建用戶(hù)問(wèn)新內(nèi)容永遠(yuǎn)答舊版本。解決辦法是把文檔更新和索引重建做成流水線(xiàn)文檔一變就觸發(fā)重建或者至少定時(shí)全量重建。增量更新要小心刪除舊向量不然新舊混在一起更亂。第二個(gè)坑是query 和文檔表述差異大。用戶(hù)口語(yǔ)化提問(wèn)文檔是書(shū)面語(yǔ)向量相似度算出來(lái)偏低。一個(gè)低成本辦法是做 query 改寫(xiě)讓模型先把用戶(hù)問(wèn)題改寫(xiě)成更接近文檔表述的形式再檢索實(shí)測(cè)召回率有提升。這個(gè)改寫(xiě)可以用小模型做延遲增加不多。第三個(gè)坑是評(píng)估集偏差。自己構(gòu)造的評(píng)估問(wèn)題往往和文檔表述接近測(cè)出來(lái)指標(biāo)虛高上線(xiàn)后真實(shí)用戶(hù)問(wèn)法千奇百怪效果打折扣。建議評(píng)估集里刻意混入口語(yǔ)化、模糊、帶錯(cuò)別字的問(wèn)法盡量貼近真實(shí)分布。7. 性能與成本的實(shí)際權(quán)衡本地化 RAG 跑起來(lái)之后性能和成本的賬要算清楚。延遲主要花在三塊向量化 query幾十毫秒、檢索加 reranker幾百毫秒、生成取決于輸出長(zhǎng)度和模型大小幾秒到十幾秒。生成是大頭想壓延遲優(yōu)先從生成端下手減輸出長(zhǎng)度、換更小的模型、開(kāi)推理加速。成本主要是硬件折舊和電費(fèi)。一臺(tái)帶單卡的機(jī)器能撐起中小規(guī)模的內(nèi)部問(wèn)答量再大要考慮多實(shí)例和負(fù)載均衡。我的經(jīng)驗(yàn)是先單機(jī)跑通、壓測(cè)找瓶頸再?zèng)Q定擴(kuò)不擴(kuò)別一上來(lái)就堆硬件很多瓶頸其實(shí)是檢索參數(shù)沒(méi)調(diào)好導(dǎo)致的無(wú)效計(jì)算。還有一個(gè)容易被忽略的成本是維護(hù)成本。文檔在變、模型在迭代、用戶(hù)問(wèn)法在演化RAG 系統(tǒng)不是一勞永逸的得有定期評(píng)估和調(diào)優(yōu)的機(jī)制。我一般會(huì)留一個(gè)反饋入口讓用戶(hù)對(duì)答案點(diǎn)“有用/沒(méi)用”攢一批 badcase 定期分析這比拍腦袋調(diào)參有效得多。我個(gè)人在實(shí)際操作中的體會(huì)是RAG 的難點(diǎn)從來(lái)不在“把鏈路搭起來(lái)”demo 半天就能跑通難的是讓它在真實(shí)數(shù)據(jù)、真實(shí)問(wèn)法下穩(wěn)定好用。切分、向量、檢索這三塊的地基打不牢后面怎么調(diào)都是事倍功半。所以如果你正準(zhǔn)備上手我的建議是前期多花時(shí)間在數(shù)據(jù)清洗和切分上多構(gòu)造評(píng)估集把檢索指標(biāo)盯住生成端反而是最后才需要操心的部分。這套流程走下來(lái)一個(gè)能用的本地 RAG 系統(tǒng)基本就成型了。 RAG本地化落地全解析：從原理到檢索調(diào)優(yōu)與生成約束
RAG 這個(gè)詞這兩年出現(xiàn)的頻率越來(lái)越高但凡聊到讓大模型“說(shuō)自己的話(huà)、答自己的料”基本繞不開(kāi)它。我最早接觸 RAG 是在一個(gè)內(nèi)部知識(shí)庫(kù)問(wèn)答的需求里當(dāng)時(shí)團(tuán)隊(duì)想讓模型能回答產(chǎn)品手冊(cè)、運(yùn)維文檔里的細(xì)節(jié)問(wèn)題直接微調(diào)成本太高、更新又慢于是把目光轉(zhuǎn)向了檢索增強(qiáng)生成這條路。實(shí)測(cè)下來(lái)RAG 確實(shí)是目前把私有數(shù)據(jù)接進(jìn)大模型最務(wù)實(shí)的一種做法不用動(dòng)模型權(quán)重?cái)?shù)據(jù)更新只需重建索引回答還能給出出處排查問(wèn)題時(shí)心里有底。這篇內(nèi)容我想把 RAG 的原理講透再把本地化落地這一整套流程拆開(kāi)揉碎講清楚——從文檔怎么切、向量怎么選、檢索怎么調(diào)到生成環(huán)節(jié)怎么約束模型別亂編。適合剛接觸 RAG 想搞明白底層邏輯的開(kāi)發(fā)者也適合已經(jīng)跑通 demo 但效果不穩(wěn)定、想找優(yōu)化方向的朋友。全文基于我在幾個(gè)內(nèi)部項(xiàng)目里的實(shí)際做法整理涉及參數(shù)的地方會(huì)給計(jì)算過(guò)程和取舍理由能直接抄作業(yè)的部分我會(huì)盡量寫(xiě)細(xì)。1. RAG 到底在解決什么問(wèn)題1.1 大模型的三個(gè)硬傷與 RAG 的定位先把問(wèn)題擺清楚不然容易把 RAG 當(dāng)成萬(wàn)能藥。大模型有三個(gè)繞不過(guò)去的硬傷一是知識(shí)有截止時(shí)間訓(xùn)練數(shù)據(jù)之后發(fā)生的事情它不知道二是私有數(shù)據(jù)進(jìn)不去公司內(nèi)部的文檔、代碼、工單它沒(méi)見(jiàn)過(guò)三是容易一本正經(jīng)地胡說(shuō)也就是幻覺(jué)尤其在它不確定的時(shí)候反而答得更自信。解決這三類(lèi)問(wèn)題常見(jiàn)有三條路微調(diào)、長(zhǎng)上下文直接塞、RAG。微調(diào)是把知識(shí)“焊”進(jìn)權(quán)重里成本高、更新慢而且容易災(zāi)難性遺忘適合學(xué)風(fēng)格和格式不適合頻繁變動(dòng)的知識(shí)。長(zhǎng)上下文是把資料全塞進(jìn) prompt簡(jiǎn)單粗暴但受窗口限制、成本隨長(zhǎng)度線(xiàn)性上漲資料一多就撐不住。RAG 的思路不一樣它是在生成之前先去外部知識(shí)庫(kù)里檢索相關(guān)內(nèi)容把檢索結(jié)果作為上下文喂給模型讓模型“看著資料答題”。打個(gè)生活化的比方微調(diào)像是讓學(xué)生把整本教材背下來(lái)考試RAG 像是開(kāi)卷考試允許帶資料進(jìn)場(chǎng)答題前先翻到相關(guān)那幾頁(yè)。開(kāi)卷的好處是資料可以隨時(shí)換、答案有據(jù)可查壞處是翻書(shū)翻得不準(zhǔn)就會(huì)答偏——這也正是 RAG 效果好壞的關(guān)鍵所在。所以 RAG 的定位很明確它解決的是“知識(shí)從哪來(lái)”的問(wèn)題不解決“模型會(huì)不會(huì)推理”的問(wèn)題。檢索到的資料質(zhì)量決定了回答的上限模型的能力決定了能不能把資料用好。理解這個(gè)邊界后面調(diào)優(yōu)時(shí)就不會(huì)把檢索的鍋甩給模型也不會(huì)指望換個(gè)更大的模型就能救回爛檢索。1.2 RAG 的完整鏈路拆解一條完整的 RAG 鏈路我習(xí)慣拆成離線(xiàn)和在線(xiàn)兩段。離線(xiàn)段是數(shù)據(jù)準(zhǔn)備文檔采集、清洗、切分、向量化、入庫(kù)這一步是一次性或周期性的。在線(xiàn)段是每次問(wèn)答實(shí)時(shí)跑的query 進(jìn)來(lái)先做向量化去庫(kù)里檢索 top-k 相關(guān)片段拼進(jìn) prompt交給模型生成最后把答案和出處一起返回。這里面每一環(huán)都有坑。切分切得不好一個(gè)完整語(yǔ)義被攔腰截?cái)鄼z索出來(lái)就是半句話(huà)向量模型選得不對(duì)語(yǔ)義相似度算不準(zhǔn)該召回的沒(méi)召回top-k 設(shè)得太大噪聲片段擠占上下文模型反而被帶偏prompt 約束不到位模型看著資料還能自由發(fā)揮。我見(jiàn)過(guò)不少 demo 跑得挺順、一上真實(shí)數(shù)據(jù)就拉胯的案例問(wèn)題基本都出在這幾個(gè)環(huán)節(jié)的細(xì)節(jié)上而不是框架本身。下面這張表是我對(duì)鏈路各環(huán)節(jié)影響權(quán)重的粗略判斷基于幾個(gè)項(xiàng)目的調(diào)優(yōu)經(jīng)驗(yàn)不是絕對(duì)數(shù)值但能幫你判斷優(yōu)化優(yōu)先級(jí)環(huán)節(jié)對(duì)最終效果的影響調(diào)優(yōu)難度常見(jiàn)問(wèn)題文檔切分高中語(yǔ)義截?cái)?、塊過(guò)大過(guò)小向量模型高低換模型即可領(lǐng)域不匹配、中文支持差檢索策略高中高單一向量召回漏檢重排序中中排序不準(zhǔn)、引入延遲Prompt 約束中高低模型自由發(fā)揮、不引用生成模型中低換模型即可指令遵循差從表里能看出來(lái)切分、向量、檢索這三塊是重頭戲也是本地化實(shí)踐里最花時(shí)間的地方。生成模型反而是最容易換的效果不行換一個(gè)就行但前面三塊爛了換再?gòu)?qiáng)的模型也白搭。2. 本地化落地的整體架構(gòu)設(shè)計(jì)2.1 為什么選擇本地化而不是調(diào) API先說(shuō)清楚為什么要本地化。調(diào)云端 API 跑 RAG 當(dāng)然省事但有幾類(lèi)場(chǎng)景繞不開(kāi)本地部署數(shù)據(jù)敏感不能出內(nèi)網(wǎng)、調(diào)用量大成本扛不住、需要離線(xiàn)可用、對(duì)延遲有硬要求。我參與的幾個(gè)項(xiàng)目基本都是前兩個(gè)原因內(nèi)部文檔涉及業(yè)務(wù)細(xì)節(jié)走外網(wǎng)不合規(guī)量大了按 token 計(jì)費(fèi)一個(gè)月賬單能?chē)標(biāo)廊恕１镜鼗暮诵氖前严蛄磕Ｐ?、向量?kù)、生成模型三樣都放在自己機(jī)器上。這里有個(gè)關(guān)鍵取舍生成模型本地跑對(duì)硬件要求最高7B 級(jí)別的模型量化后大概需要 6-8G 顯存13B 要 12-16G再大就得靠多卡或者更激進(jìn)的量化。如果硬件有限一個(gè)折中方案是檢索和向量化本地做生成走內(nèi)網(wǎng)自建的推理服務(wù)既保證數(shù)據(jù)不出內(nèi)網(wǎng)又不至于被單機(jī)顯存卡死。我的建議是先把鏈路跑通再談性能。一開(kāi)始別追求大模型7B 量化版足夠驗(yàn)證流程等檢索調(diào)好了、prompt 定型了再根據(jù)效果決定要不要上更大的模型。很多人一上來(lái)就糾結(jié)模型選型結(jié)果檢索一塌糊涂換了三個(gè)模型都沒(méi)救回來(lái)白白浪費(fèi)時(shí)間。2.2 組件選型與硬件估算組件選型我按“夠用、好維護(hù)、社區(qū)活躍”三個(gè)標(biāo)準(zhǔn)來(lái)。向量模型優(yōu)先看中文語(yǔ)義能力本地部署常用的是 BGE 系列或者 M3E 這類(lèi)中文優(yōu)化過(guò)的模型維度一般是 768 或 1024。向量庫(kù)方面數(shù)據(jù)量在百萬(wàn)級(jí)以?xún)?nèi)輕量方案完全夠用沒(méi)必要上重型分布式庫(kù)數(shù)據(jù)量再大或者要支持復(fù)雜過(guò)濾再考慮更專(zhuān)業(yè)的向量數(shù)據(jù)庫(kù)。硬件估算給個(gè)參考算法。向量庫(kù)內(nèi)存占用大致等于向量條數(shù) × 維度 × 4 字節(jié)float32比如 50 萬(wàn)條 768 維向量就是 500000 × 768 × 4 ≈ 1.5GB加上索引開(kāi)銷(xiāo)按 1.5 倍算2GB 出頭很輕。生成模型這邊7B 模型 FP16 需要約 14GB 顯存4bit 量化后約 4-5GB加上 KV cache 和上下文開(kāi)銷(xiāo)8G 顯存能跑但上下文別開(kāi)太大。這些數(shù)字是我實(shí)測(cè)的粗略值具體會(huì)因框架和量化方式有浮動(dòng)。注意向量維度不是越高越好。1024 維比 768 維召回略好但存儲(chǔ)和計(jì)算都漲三成數(shù)據(jù)量不大時(shí)收益不明顯。先用 768 維跑通效果不夠再升維。3. 文檔處理與切分RAG 效果的地基3.1 文檔清洗與格式統(tǒng)一這一步最枯燥但最不能省。真實(shí)文檔五花八門(mén)PDF 有頁(yè)眉頁(yè)腳、掃描件是圖片、Word 里有大量樣式標(biāo)記、網(wǎng)頁(yè)抓下來(lái)一堆導(dǎo)航欄。直接把這些丟進(jìn)去切分切出來(lái)的全是噪聲。我的做法是先統(tǒng)一轉(zhuǎn)成純文本或 Markdown再做一輪清洗。PDF 提取優(yōu)先用能保留結(jié)構(gòu)的解析方式掃描件得先走 OCR。清洗規(guī)則我一般會(huì)做這幾件事去掉連續(xù)空行和多余空格、剔除頁(yè)眉頁(yè)腳這類(lèi)重復(fù)出現(xiàn)的行、把表格轉(zhuǎn)成結(jié)構(gòu)化文本表格直接切分很容易散架、統(tǒng)一標(biāo)點(diǎn)和全半角。這里有個(gè)容易忽略的點(diǎn)保留標(biāo)題層級(jí)信息。標(biāo)題是天然的語(yǔ)義邊界切分時(shí)如果能帶上所屬章節(jié)標(biāo)題檢索出來(lái)的片段可讀性和相關(guān)性都會(huì)好很多。清洗完建議抽樣人工看幾十條確認(rèn)沒(méi)有大面積亂碼或結(jié)構(gòu)丟失。我踩過(guò)一次坑某批 PDF 提取出來(lái)中文全是亂碼沒(méi)檢查就入庫(kù)了結(jié)果檢索永遠(yuǎn)召回一堆亂碼片段排查了半天才發(fā)現(xiàn)是提取環(huán)節(jié)的問(wèn)題。3.2 切分策略與參數(shù)計(jì)算切分是 RAG 里最需要?jiǎng)幽X子的環(huán)節(jié)。切太大一個(gè)塊里混了好幾個(gè)主題檢索精度下降切太小語(yǔ)義不完整模型拿到半句話(huà)沒(méi)法答。業(yè)界常用的起點(diǎn)是塊大小 500-800 字符、重疊 50-100 字符但這個(gè)值必須按你的文檔類(lèi)型調(diào)。重疊的作用是防止語(yǔ)義在邊界被切斷。比如一句話(huà)正好跨在兩個(gè)塊之間有重疊就能保證至少有一個(gè)塊包含完整句子。重疊比例一般取塊大小的 10%-20%太小起不到保護(hù)作用太大又造成冗余存儲(chǔ)和重復(fù)召回。我一般用遞歸切分先按段落切段落超長(zhǎng)再按句子切句子還超長(zhǎng)才硬切。這樣能最大限度保住語(yǔ)義邊界。代碼上大致是這樣from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size600, chunk_overlap80, separators[\n\n, \n, 。, , , , , ], ) chunks splitter.split_text(cleaned_text)注意 separators 里中文標(biāo)點(diǎn)要放在英文空格之前因?yàn)橹形奈臋n主要靠句號(hào)問(wèn)號(hào)斷句。這個(gè)順序錯(cuò)了切分質(zhì)量會(huì)明顯下降。另外技術(shù)文檔和 FAQ 類(lèi)文檔的切分邏輯不一樣FAQ 最好一問(wèn)一答作為一個(gè)塊別把問(wèn)題和答案切開(kāi)技術(shù)文檔按章節(jié)切更合理。沒(méi)有萬(wàn)能參數(shù)只能拿真實(shí)數(shù)據(jù)試切完抽幾條看看是不是完整語(yǔ)義。3.3 元數(shù)據(jù)設(shè)計(jì)被低估的檢索增強(qiáng)手段很多人只存文本和向量其實(shí)元數(shù)據(jù)能大幅提升檢索質(zhì)量。我通常會(huì)給每個(gè)塊打上來(lái)源文件名、章節(jié)標(biāo)題、頁(yè)碼、更新時(shí)間這些標(biāo)簽。好處有兩個(gè)一是檢索時(shí)可以按元數(shù)據(jù)過(guò)濾比如只搜某個(gè)產(chǎn)品線(xiàn)的文檔二是生成時(shí)可以把出處帶給用戶(hù)答案可信度立刻不一樣。更進(jìn)一步可以在塊文本前面拼上章節(jié)標(biāo)題再向量化相當(dāng)于給每個(gè)塊加了“上下文前綴”。實(shí)測(cè)這個(gè)做法對(duì)召回率有肉眼可見(jiàn)的提升因?yàn)闃?biāo)題里往往包含關(guān)鍵主題詞能幫向量模型更好地理解這個(gè)塊在講什么。成本幾乎為零強(qiáng)烈建議加上。4. 向量化與檢索調(diào)優(yōu)實(shí)戰(zhàn)4.1 向量模型的選擇與本地部署向量模型決定了語(yǔ)義相似度算得準(zhǔn)不準(zhǔn)是檢索質(zhì)量的天花板。選型時(shí)重點(diǎn)看兩點(diǎn)中文語(yǔ)義能力和領(lǐng)域匹配度。通用模型在通用語(yǔ)料上表現(xiàn)不錯(cuò)但遇到專(zhuān)業(yè)術(shù)語(yǔ)密集的領(lǐng)域比如醫(yī)療、法律、工控召回會(huì)明顯下降。這種情況要么找領(lǐng)域微調(diào)過(guò)的模型要么自己拿領(lǐng)域語(yǔ)料做對(duì)比學(xué)習(xí)微調(diào)后者成本高但效果最實(shí)在。本地部署向量模型很輕一個(gè)幾百 M 的模型 CPU 都能跑批量向量化時(shí)用 GPU 加速會(huì)快很多。部署時(shí)注意歸一化算余弦相似度前要把向量歸一化成單位向量這樣內(nèi)積就等于余弦相似度檢索時(shí)直接用內(nèi)積索引更快。很多框架默認(rèn)幫你做了但自己寫(xiě)代碼時(shí)容易漏。批量向量化有個(gè)細(xì)節(jié)batch size 別設(shè)太大顯存不夠會(huì) OOM也別太小吞吐上不去。我一般從 32 開(kāi)始試看顯存占用往上加。另外入庫(kù)前一定要校驗(yàn)向量維度一致混入不同模型產(chǎn)生的向量會(huì)導(dǎo)致檢索結(jié)果完全錯(cuò)亂這種問(wèn)題排查起來(lái)很痛苦。4.2 檢索策略從單一向量到混合召回單一向量檢索有個(gè)天然短板它對(duì)精確匹配不敏感。用戶(hù)問(wèn)一個(gè)具體的型號(hào)、編號(hào)、專(zhuān)有名詞向量檢索可能召回一堆語(yǔ)義相近但沒(méi)命中關(guān)鍵詞的片段。解決辦法是混合檢索向量召回負(fù)責(zé)語(yǔ)義相似關(guān)鍵詞召回比如 BM25負(fù)責(zé)精確匹配兩路結(jié)果融合排序。融合常用 RRF倒數(shù)排名融合邏輯很簡(jiǎn)單每個(gè)文檔在每路召回里的排名取倒數(shù)相加排名越靠前得分越高兩路都靠前的文檔最終得分最高。這個(gè)算法不需要調(diào)權(quán)重魯棒性好我基本默認(rèn)用它。偽代碼大概是這樣def rrf_fusion(vector_results, keyword_results, k60): scores {} for rank, doc_id in enumerate(vector_results): scores[doc_id] scores.get(doc_id, 0) 1 / (k rank 1) for rank, doc_id in enumerate(keyword_results): scores[doc_id] scores.get(doc_id, 0) 1 / (k rank 1) return sorted(scores.items(), keylambda x: x[1], reverseTrue)k 取 60 是論文里的經(jīng)驗(yàn)值實(shí)際用下來(lái) 40-80 之間差別不大?；旌蠙z索的代價(jià)是多一路召回和融合計(jì)算延遲會(huì)漲一些但對(duì)召回率的提升很值尤其是文檔里專(zhuān)有名詞多的時(shí)候。4.3 重排序用精度換召回檢索階段為了不漏top-k 一般設(shè)得比較大比如 20-50但真正喂給模型的只能留幾條3-5 條不然上下文塞滿(mǎn)噪聲。這中間的篩選就靠重排序。重排序模型reranker比向量模型更重、更準(zhǔn)它對(duì) query 和每個(gè)候選片段做交叉編碼算出精細(xì)的相關(guān)性分?jǐn)?shù)再取 top-n。這個(gè)思路叫“召回求全、排序求精”。向量檢索快但粗reranker 慢但準(zhǔn)兩級(jí)配合能在延遲可控的前提下大幅提升精度。實(shí)測(cè)下來(lái)加了 reranker 之后喂給模型的片段相關(guān)性明顯提升模型答非所問(wèn)的情況少了很多。代價(jià)是延遲。reranker 對(duì)每個(gè)候選都要跑一次模型20 個(gè)候選就是 20 次推理用 GPU 加速后一般能控制在幾百毫秒。如果對(duì)延遲極敏感可以只對(duì) top-10 做重排或者用更小的 reranker 模型。我的經(jīng)驗(yàn)是這一步的性?xún)r(jià)比很高除非延遲卡死否則別省。4.4 檢索參數(shù)調(diào)優(yōu)的實(shí)操方法參數(shù)調(diào)優(yōu)別拍腦袋要有評(píng)估集。做法是人工構(gòu)造幾十到上百條“問(wèn)題-標(biāo)準(zhǔn)答案-應(yīng)召回的文檔塊”三元組然后跑檢索看命中率。核心指標(biāo)看兩個(gè)Recallk前 k 條里有沒(méi)有包含正確塊和MRR正確塊排得靠不靠前。Recall 低說(shuō)明召回不夠加大 k 或換模型MRR 低說(shuō)明排序不準(zhǔn)上 reranker。我一般按這個(gè)順序調(diào)先固定切分和向量模型調(diào) k 看 Recall 曲線(xiàn)找到 Recall 不再明顯上升的拐點(diǎn)再上混合檢索看提升最后加 reranker 看 MRR。每一步都記錄指標(biāo)別一次改多個(gè)變量不然不知道是哪個(gè)改動(dòng)起的作用。這套流程聽(tīng)起來(lái)笨但比憑感覺(jué)調(diào)靠譜得多。5. Prompt 設(shè)計(jì)與生成約束5.1 上下文拼裝與引用規(guī)范檢索到的片段怎么拼進(jìn) prompt直接影響模型能不能用好。我的模板一般包含三部分系統(tǒng)指令你是基于資料回答的助手資料里沒(méi)有就說(shuō)不知道、檢索到的片段帶編號(hào)和出處、用戶(hù)問(wèn)題。片段之間用明確的分隔符隔開(kāi)并標(biāo)注來(lái)源方便模型引用。關(guān)鍵約束有兩條只依據(jù)資料回答、資料不足時(shí)明確說(shuō)不知道。這兩條能大幅壓低幻覺(jué)率。但光寫(xiě)指令不夠模型有時(shí)還是會(huì)自由發(fā)揮所以我會(huì)在 prompt 里要求它回答時(shí)標(biāo)注引用的片段編號(hào)這樣即使它編了也能通過(guò)引用是否對(duì)得上快速發(fā)現(xiàn)。提示片段數(shù)量別貪多。3-5 條高質(zhì)量片段比 10 條混雜的效果好因?yàn)樯舷挛脑介L(zhǎng)模型越容易抓錯(cuò)重點(diǎn)而且長(zhǎng)上下文本身有“中間遺忘”現(xiàn)象關(guān)鍵信息放中間容易被忽略。把最相關(guān)的放最前面。5.2 生成模型本地部署與量化取舍本地跑生成模型量化是繞不開(kāi)的話(huà)題。常見(jiàn)的有 4bit、8bit 量化量化越狠顯存占用越小但精度損失越大。我的經(jīng)驗(yàn)是8bit 量化基本無(wú)損4bit 在多數(shù)問(wèn)答任務(wù)上可接受但涉及數(shù)字計(jì)算、代碼生成這類(lèi)任務(wù)時(shí) 4bit 容易出錯(cuò)。如果硬件允許優(yōu)先 8bit實(shí)在緊張?jiān)偕?4bit并且重點(diǎn)驗(yàn)證量化后在你任務(wù)上的表現(xiàn)。推理框架方面本地部署常用的是支持量化和高效推理的那幾套選型時(shí)看它對(duì)量化格式的支持和吞吐表現(xiàn)。部署時(shí)注意上下文長(zhǎng)度設(shè)置RAG 場(chǎng)景下上下文要能裝下系統(tǒng)指令加幾條片段一般設(shè) 4K-8K 夠用設(shè)太大反而吃顯存。溫度參數(shù)建議調(diào)低0.1-0.3RAG 要的是忠實(shí)于資料不需要?jiǎng)?chuàng)造性。5.3 答案后處理與出處回填生成完別直接返回做一層后處理能提升體驗(yàn)。常見(jiàn)的有把模型標(biāo)注的片段編號(hào)映射回真實(shí)出處文件名、頁(yè)碼拼在答案末尾檢查答案里有沒(méi)有“根據(jù)資料”這類(lèi)空話(huà)有的話(huà)精簡(jiǎn)掉對(duì)超長(zhǎng)答案做截?cái)嗷蚍侄?。如果模型輸出了引用編?hào)但內(nèi)容對(duì)不上可以標(biāo)記為“低置信”提示用戶(hù)核實(shí)。這一層還能做兜底如果檢索階段最高分低于某個(gè)閾值說(shuō)明庫(kù)里可能根本沒(méi)有相關(guān)內(nèi)容這時(shí)直接返回“未找到相關(guān)資料”比讓模型硬答要誠(chéng)實(shí)得多。閾值怎么定拿評(píng)估集跑一遍看正樣本和負(fù)樣本的分?jǐn)?shù)分布取一個(gè)能分開(kāi)兩者的值我一般取正樣本最低分的 80% 左右作為保守閾值。6. 常見(jiàn)問(wèn)題排查與避坑實(shí)錄6.1 效果問(wèn)題的定位思路RAG 效果不好先別急著換模型按鏈路逐段排查。我總結(jié)了一個(gè)排查順序先看檢索再看拼裝最后看生成。具體做法是拿一個(gè)答錯(cuò)的問(wèn)題手動(dòng)看檢索出來(lái)的片段里有沒(méi)有正確答案。如果沒(méi)有問(wèn)題在檢索切分、向量、召回策略如果有但模型沒(méi)答對(duì)問(wèn)題在拼裝或生成prompt、上下文順序、模型能力。這個(gè)二分法能快速定位問(wèn)題域。我見(jiàn)過(guò)太多人一上來(lái)就懷疑模型不行結(jié)果一查檢索正確片段壓根沒(méi)召回?fù)Q十個(gè)模型也沒(méi)用。反過(guò)來(lái)檢索沒(méi)問(wèn)題但答案還是錯(cuò)那才輪到調(diào) prompt 或換模型。6.2 高頻問(wèn)題速查表下面這張表是我在實(shí)際項(xiàng)目里整理的高頻問(wèn)題和對(duì)應(yīng)處理辦法按出現(xiàn)頻率排序現(xiàn)象可能原因排查與處理答非所問(wèn)檢索召回不相關(guān)檢查切分是否截?cái)嗾Z(yǔ)義換向量模型加混合檢索說(shuō)不知道但庫(kù)里有召回沒(méi)命中加大 top-k檢查 query 改寫(xiě)確認(rèn)向量維度一致答案含資料外內(nèi)容prompt 約束不足強(qiáng)化“僅依據(jù)資料”指令降低溫度要求引用專(zhuān)有名詞答錯(cuò)精確匹配弱加 BM25 關(guān)鍵詞召回混合融合長(zhǎng)文檔答不全上下文截?cái)鄼z查塊大小和 top-k確認(rèn)上下文長(zhǎng)度夠響應(yīng)慢reranker 或模型推理慢減候選數(shù)換小模型開(kāi) GPU 加速重復(fù)召回同一段重疊過(guò)大降低 chunk_overlap檢索后去重6.3 幾個(gè)踩過(guò)的坑第一個(gè)坑是向量庫(kù)更新不同步。文檔更新了但索引沒(méi)重建用戶(hù)問(wèn)新內(nèi)容永遠(yuǎn)答舊版本。解決辦法是把文檔更新和索引重建做成流水線(xiàn)文檔一變就觸發(fā)重建或者至少定時(shí)全量重建。增量更新要小心刪除舊向量不然新舊混在一起更亂。第二個(gè)坑是query 和文檔表述差異大。用戶(hù)口語(yǔ)化提問(wèn)文檔是書(shū)面語(yǔ)向量相似度算出來(lái)偏低。一個(gè)低成本辦法是做 query 改寫(xiě)讓模型先把用戶(hù)問(wèn)題改寫(xiě)成更接近文檔表述的形式再檢索實(shí)測(cè)召回率有提升。這個(gè)改寫(xiě)可以用小模型做延遲增加不多。第三個(gè)坑是評(píng)估集偏差。自己構(gòu)造的評(píng)估問(wèn)題往往和文檔表述接近測(cè)出來(lái)指標(biāo)虛高上線(xiàn)后真實(shí)用戶(hù)問(wèn)法千奇百怪效果打折扣。建議評(píng)估集里刻意混入口語(yǔ)化、模糊、帶錯(cuò)別字的問(wèn)法盡量貼近真實(shí)分布。7. 性能與成本的實(shí)際權(quán)衡本地化 RAG 跑起來(lái)之后性能和成本的賬要算清楚。延遲主要花在三塊向量化 query幾十毫秒、檢索加 reranker幾百毫秒、生成取決于輸出長(zhǎng)度和模型大小幾秒到十幾秒。生成是大頭想壓延遲優(yōu)先從生成端下手減輸出長(zhǎng)度、換更小的模型、開(kāi)推理加速。成本主要是硬件折舊和電費(fèi)。一臺(tái)帶單卡的機(jī)器能撐起中小規(guī)模的內(nèi)部問(wèn)答量再大要考慮多實(shí)例和負(fù)載均衡。我的經(jīng)驗(yàn)是先單機(jī)跑通、壓測(cè)找瓶頸再?zèng)Q定擴(kuò)不擴(kuò)別一上來(lái)就堆硬件很多瓶頸其實(shí)是檢索參數(shù)沒(méi)調(diào)好導(dǎo)致的無(wú)效計(jì)算。還有一個(gè)容易被忽略的成本是維護(hù)成本。文檔在變、模型在迭代、用戶(hù)問(wèn)法在演化RAG 系統(tǒng)不是一勞永逸的得有定期評(píng)估和調(diào)優(yōu)的機(jī)制。我一般會(huì)留一個(gè)反饋入口讓用戶(hù)對(duì)答案點(diǎn)“有用/沒(méi)用”攢一批 badcase 定期分析這比拍腦袋調(diào)參有效得多。我個(gè)人在實(shí)際操作中的體會(huì)是RAG 的難點(diǎn)從來(lái)不在“把鏈路搭起來(lái)”demo 半天就能跑通難的是讓它在真實(shí)數(shù)據(jù)、真實(shí)問(wèn)法下穩(wěn)定好用。切分、向量、檢索這三塊的地基打不牢后面怎么調(diào)都是事倍功半。所以如果你正準(zhǔn)備上手我的建議是前期多花時(shí)間在數(shù)據(jù)清洗和切分上多構(gòu)造評(píng)估集把檢索指標(biāo)盯住生成端反而是最后才需要操心的部分。這套流程走下來(lái)一個(gè)能用的本地 RAG 系統(tǒng)基本就成型了。