本地 RAG 問答做久了你會發(fā)現(xiàn)一個很尷尬的現(xiàn)象明明知識庫里的文檔寫得清清楚楚用戶問一句它的參數(shù)是多少系統(tǒng)就開始胡言亂語。問題往往不在大模型本身而在于檢索環(huán)節(jié)——用戶這句話里的它到底指什么檢索器根本不知道。我前后折騰過好幾套本地 RAG 方案從最樸素的向量檢索到帶重排序的流水線踩過的坑基本都集中在三個地方多輪對話里的指代消解、向量化模型的選擇、以及 TXT 文檔的切分策略。這篇就把這三塊拆開講透尤其是多輪指代消解 云端語義向量 TXT 章節(jié)切分這套組合拳是我實測下來在本地環(huán)境里性價比最高、最容易復(fù)現(xiàn)的方案。1. 為什么本地 RAG 的準(zhǔn)字最難做1.1 檢索不準(zhǔn)的三個真實來源很多人第一次搭 RAG思路很直接文檔切塊、向量化、存庫、檢索、拼 prompt。跑通 Demo 沒問題但一上真實場景就露餡。我把檢索不準(zhǔn)的原因歸成三類這三類在本地環(huán)境里尤其明顯。第一類是查詢本身有歧義。多輪對話中用戶大量使用代詞和省略比如它支持多少并發(fā)那這個怎么配置上面說的那個參數(shù)默認(rèn)值是多少。這些查詢單獨拿出來看向量化之后和知識庫里的任何一段都不像檢索器只能瞎猜。這是多輪 RAG 最致命的短板也是本文要重點解決的第一塊。第二類是向量語義表達不足。本地跑嵌入模型受限于顯存和算力往往選的是參數(shù)量很小的模型比如各種 mini、small 版本。這類模型對短查詢、專業(yè)術(shù)語、中英混排的語義捕捉能力有限導(dǎo)致語義相近的文檔排不到前面。這是第二塊要解決的。第三類是切分粒度不對。TXT 文檔沒有結(jié)構(gòu)信息如果按固定字符數(shù)硬切一個完整的章節(jié)可能被切成兩半檢索命中前半段卻丟了后半段的關(guān)鍵結(jié)論。這是第三塊要解決的。1.2 本地環(huán)境的能力邊界在哪先把預(yù)期擺正。本地 RAG 的優(yōu)勢是數(shù)據(jù)不出內(nèi)網(wǎng)、成本可控、可離線劣勢是算力和顯存有限。這意味著你不能指望本地跑一個幾百億參數(shù)的嵌入模型也不能指望本地大模型有云端那種推理能力。所以正確的思路是分工把重的語義理解交給云端嵌入 API把輕的編排和生成留在本地。云端語義向量服務(wù)按調(diào)用量計費一次嵌入成本極低但語義質(zhì)量比本地小模型高一個檔次。而多輪指代消解這種需要結(jié)合上下文的邏輯可以在本地用規(guī)則 輕量模型完成不必上大模型。TXT 章節(jié)切分則是純工程問題本地處理零成本。提示如果你的場景對數(shù)據(jù)出境極度敏感云端嵌入這條路走不通那就得接受本地小模型的效果折損或者自建嵌入服務(wù)。本文方案默認(rèn)你接受文本片段送云端做向量化這一前提。1.3 這套方案的整體數(shù)據(jù)流在動手之前先把整條鏈路理清楚后面每一節(jié)都是在這條鏈路上做文章。用戶提問進來先經(jīng)過多輪指代消解模塊結(jié)合最近幾輪對話歷史把它這個那個替換成明確的實體輸出一個自包含的查詢Self-contained Query。這個查詢再送去云端語義向量服務(wù)做嵌入得到查詢向量。然后用這個向量去本地向量庫檢索拿到 Top-K 候選片段。候選片段和改寫后的查詢一起拼進 prompt交給本地大模型生成答案。整條鏈路里指代消解決定了問得對不對云端向量決定了找得準(zhǔn)不準(zhǔn)章節(jié)切分決定了切得全不全。三者缺一不可。2. 多輪指代消解讓它變成明確的實體2.1 指代消解到底在解決什么問題指代消解Coreference Resolution在 NLP 里是個老話題但在 RAG 場景下我們要的不是學(xué)術(shù)意義上的完整消解而是一個更務(wù)實的目標(biāo)把依賴上下文的查詢改寫成不依賴上下文的獨立查詢。業(yè)內(nèi)常把這個動作叫 Query Rewriting。舉個具體例子。第一輪用戶問LangChain4j 的 Easy RAG 怎么配置第二輪問它的默認(rèn)分塊大小是多少。如果直接把第二輪送去檢索它會被向量化成無意義的噪聲檢索結(jié)果大概率跑偏。但如果改寫成LangChain4j Easy RAG 的默認(rèn)分塊大小是多少檢索命中率立刻上來了。關(guān)鍵點在于改寫不是簡單地把上一輪的主語拼過來而是要判斷當(dāng)前查詢里哪些詞是指代性的哪些是實體性的。指代性的詞需要替換實體性的詞要保留。2.2 三種改寫策略的取舍我在實際項目里試過三種策略各有適用場景。策略一規(guī)則替換。維護一個指代詞表它、他、這個、那個、該、此、上述、前面提到的……檢測到查詢里出現(xiàn)這些詞就把最近一輪對話里的核心實體填進去。優(yōu)點是零成本、零延遲、完全本地缺點是遇到復(fù)雜指代比如它的第二個參數(shù)就抓瞎而且容易誤替換。策略二小模型改寫。本地跑一個 1B 到 3B 的指令微調(diào)模型專門做 Query Rewriting。給它一個 prompt根據(jù)對話歷史把用戶最后一句話改寫成不依賴上下文的獨立問題。優(yōu)點是能處理復(fù)雜指代缺點是要占顯存而且小模型改寫質(zhì)量不穩(wěn)定偶爾會把原意改歪。策略三規(guī)則 小模型兜底。先用規(guī)則快速判斷如果查詢里沒有指代詞直接放行零開銷如果有指代詞再調(diào)用小模型改寫。這是我最終采用的方案兼顧了成本和效果。策略延遲顯存占用復(fù)雜指代處理推薦場景純規(guī)則替換極低無差對話簡單、指代詞固定小模型改寫中1-3GB好對話復(fù)雜、算力充足規(guī)則小模型兜底低1-3GB好大多數(shù)本地場景2.3 規(guī)則層的實現(xiàn)細(xì)節(jié)規(guī)則層看起來簡單但有幾個細(xì)節(jié)不注意就會翻車。第一指代詞檢測要區(qū)分詞性。它作為代詞要替換但其他里的他不能動。中文沒有空格簡單的字符串匹配會誤傷。我的做法是用分詞工具先切詞再在詞級別匹配指代詞表避免子串誤匹配。第二實體來源要選對。改寫時填入的實體應(yīng)該來自最近一輪的用戶查詢而不是上一輪的模型回答。因為模型回答里實體太多容易填錯。如果最近一輪用戶查詢里也沒有明確實體就往前再找一輪最多回溯三輪。第三改寫后要做校驗。改寫完的查詢?nèi)绻L度異常比如比原文短很多或者長很多說明改寫可能出錯了這時候?qū)幙煞艞壐膶懹迷樵儥z索也不要送一個錯誤的查詢進去。# 規(guī)則層指代消解的核心邏輯示意 PRONOUNS {它, 他, 她, 這個, 那個, 該, 此, 上述, 其} def rewrite_by_rule(query, history, max_back3): tokens jieba.lcut(query) if not any(t in PRONOUNS for t in tokens): return query, False # 無指代直接放行 # 回溯最近幾輪用戶查詢找核心實體 entity None for turn in reversed(history[-max_back:]): if turn[role] user: entity extract_main_entity(turn[content]) if entity: break if not entity: return query, False # 找不到實體放棄改寫 rewritten query for p in PRONOUNS: rewritten rewritten.replace(p, entity) # 校驗長度變化過大則放棄 if len(rewritten) len(query) * 3 or len(rewritten) len(query) * 0.5: return query, False return rewritten, True2.4 小模型改寫的 prompt 設(shè)計規(guī)則層搞不定的復(fù)雜指代交給小模型。prompt 設(shè)計是成敗關(guān)鍵我調(diào)了好幾版才穩(wěn)定下來。核心原則有三條。一是給足上下文但別給太多最近三輪對話足夠給太多反而干擾。二是明確輸出格式要求模型只輸出改寫后的查詢不要解釋、不要加引號。三是給示例few-shot 能顯著提升小模型的穩(wěn)定性。你是一個查詢改寫助手。根據(jù)對話歷史把用戶最后一句話改寫成 不依賴上下文、可以獨立檢索的完整問題。 規(guī)則 1. 只輸出改寫后的問題不要任何解釋 2. 保留原句中的專業(yè)術(shù)語和實體 3. 如果原句已經(jīng)完整原樣輸出 對話歷史 用戶LangChain4j 的 Easy RAG 怎么配置 助手Easy RAG 通過 EasyRagConfig 配置主要設(shè)置 embedding 和 store 用戶它的默認(rèn)分塊大小是多少 改寫結(jié)果LangChain4j Easy RAG 的默認(rèn)分塊大小是多少實測下來1.5B 到 3B 的指令模型在這個任務(wù)上表現(xiàn)已經(jīng)夠用再大就是浪費。注意 prompt 里的示例要和你的實際領(lǐng)域貼近通用示例的效果會打折扣。2.5 改寫失敗的兜底與降級再好的改寫也有失敗的時候。我的兜底策略是雙路檢索改寫后的查詢和原始查詢各檢索一次把兩路結(jié)果合并去重再統(tǒng)一重排序。這樣即使改寫錯了原始查詢還能兜住一部分正確結(jié)果。代價是檢索次數(shù)翻倍延遲增加。所以只在改寫置信度低的時候啟用雙路。置信度怎么判斷我的經(jīng)驗是看改寫前后的向量相似度——如果改寫后查詢和原查詢的向量余弦相似度低于某個閾值比如 0.6說明改寫改動很大風(fēng)險高就啟用雙路。3. 云端語義向量本地小模型的語義補強3.1 本地嵌入模型的真實短板先說清楚本地嵌入模型差在哪才知道云端補的是什么。本地能跑的嵌入模型參數(shù)量普遍在 100M 到 500M 之間。這類模型在通用語義相似度任務(wù)上還行但遇到三種情況就拉胯專業(yè)術(shù)語密集的查詢比如ontology rag 和 kg 知識庫的區(qū)別、中英混排比如langchain4j easy rag 怎么用、短查詢比如分塊大小。短查詢尤其致命因為信息量太少小模型很難把它映射到正確的語義空間。我做過一個對比測試同一批 50 個查詢本地小模型和云端嵌入服務(wù)的 Top-5 命中率差了將近 20 個百分點。這個差距在 Demo 里看不出來但在真實問答里就是答對和答錯的區(qū)別。3.2 云端嵌入的調(diào)用與成本控制云端語義向量服務(wù)的調(diào)用很簡單基本就是發(fā) HTTP 請求傳文本數(shù)組拿回向量數(shù)組。但有幾個工程細(xì)節(jié)要注意。批量調(diào)用。不要一條一條調(diào)把多個文本片段打包成一批一次請求搞定。大多數(shù)服務(wù)單次支持幾十到上百條批量調(diào)用能把網(wǎng)絡(luò)往返開銷攤薄。緩存。知識庫文檔的向量是固定的算一次存起來就行不要每次檢索都重算。只有查詢向量需要實時算。所以實際調(diào)用量 查詢次數(shù)而不是查詢次數(shù) × 文檔數(shù)。失敗重試。網(wǎng)絡(luò)請求會失敗要有重試機制但別無限重試。我的做法是重試兩次還失敗就降級到本地小模型保證服務(wù)不中斷。import hashlib import json class EmbeddingClient: def __init__(self, api_endpoint, api_key, cache_pathemb_cache.json): self.endpoint api_endpoint self.key api_key self.cache self._load_cache(cache_path) def embed(self, texts, batch_size64): results [] for i in range(0, len(texts), batch_size): batch texts[i:ibatch_size] # 先查緩存 miss [t for t in batch if self._hash(t) not in self.cache] if miss: vecs self._call_api(miss) # 帶重試 for t, v in zip(miss, vecs): self.cache[self._hash(t)] v results.extend(self.cache[self._hash(t)] for t in batch) return results def _hash(self, text): return hashlib.md5(text.encode()).hexdigest()注意緩存 key 用文本的哈希不要用文本本身否則緩存文件會巨大。另外緩存要定期落盤別只放內(nèi)存里進程重啟就沒了。3.3 查詢向量和文檔向量必須同源這是最容易踩的坑也是很多人忽略的。查詢向量和文檔向量必須用同一個嵌入模型生成否則兩個向量根本不在同一個語義空間里余弦相似度算出來毫無意義。我見過有人文檔用云端模型嵌入查詢用本地模型嵌入然后納悶為什么檢索結(jié)果全是亂的。原因就在這里。向量空間不對齊相似度計算就是隨機數(shù)。所以方案里要明確既然文檔向量用了云端服務(wù)查詢向量也必須用同一個云端服務(wù)。本地小模型只在云端不可用時作為降級方案而且降級時要用本地模型重新嵌入整個知識庫保證同源。3.4 向量維度與存儲的權(quán)衡云端嵌入服務(wù)通常提供多種維度的模型比如 768、1024、1536、3072。維度越高語義表達越豐富但存儲和檢索成本也越高。本地向量庫比如 FAISS、Chroma存的是浮點數(shù)組維度翻倍存儲就翻倍。假設(shè)你有 10 萬個文檔片段1536 維的 float32 向量大約占 600MB3072 維就是 1.2GB。本地環(huán)境內(nèi)存有限這個賬要算清楚。我的建議是優(yōu)先選 1024 或 1536 維這是效果和成本的平衡點。除非你的場景對語義精度要求極高否則沒必要上 3072 維。另外可以考慮量化存儲把 float32 壓成 int8存儲直接砍到四分之一精度損失在可接受范圍內(nèi)。維度10萬片段存儲(float32)語義精度適用場景768約 300MB中資源緊張、場景簡單1024約 400MB中高通用推薦1536約 600MB高專業(yè)領(lǐng)域、精度優(yōu)先3072約 1.2GB極高特殊需求、資源充足4. TXT 章節(jié)切分別讓固定長度毀了檢索4.1 固定長度切分的致命傷TXT 文檔沒有 HTML 標(biāo)簽、沒有 Markdown 標(biāo)題很多人圖省事就按固定字符數(shù)切比如每 500 字一塊重疊 50 字。這個做法在結(jié)構(gòu)松散的文檔上勉強能用但遇到有明確章節(jié)的文檔就是災(zāi)難。問題出在語義完整性被破壞。假設(shè)一個章節(jié)講配置參數(shù)前半段列參數(shù)名后半段講每個參數(shù)的默認(rèn)值和取值范圍。固定切分正好切在中間前半塊只有參數(shù)名沒有默認(rèn)值后半塊只有默認(rèn)值不知道對應(yīng)哪個參數(shù)。用戶問某參數(shù)默認(rèn)值是多少檢索命中后半塊但后半塊里沒有參數(shù)名模型根本不知道在說哪個參數(shù)。4.2 基于章節(jié)特征的切分策略TXT 雖然沒有顯式結(jié)構(gòu)但章節(jié)特征往往藏在文本里。我總結(jié)了幾個可用的信號。編號信號。像第一章1.1一、一這類編號是天然的章節(jié)邊界。用正則匹配這些模式在匹配位置切分?？招行盘枴Ｕ鹿?jié)之間通常有空行分隔連續(xù)兩個以上換行往往意味著一個新章節(jié)開始。標(biāo)題特征信號。章節(jié)標(biāo)題通常比較短一行以內(nèi)且后面緊跟正文?？梢越Y(jié)合行長度和上下文判斷。關(guān)鍵詞信號。像概述配置參數(shù)說明注意事項示例這類詞經(jīng)常出現(xiàn)在章節(jié)標(biāo)題里。實際實現(xiàn)時我會把這些信號組合起來打分超過閾值就判定為章節(jié)邊界。純規(guī)則實現(xiàn)不依賴模型本地跑零成本。import re # 章節(jié)邊界檢測的正則模式 SECTION_PATTERNS [ r^第[一二三四五六七八九十百][章節(jié)部分], # 第一章、第二節(jié) r^\d\.\d\s, # 1.1 開頭 r^\d\.\s, # 1. 開頭 r^[一二三四五六七八九十]、, # 一、開頭 r^[一二三四五六七八九十], # 一開頭 r^(概述|簡介|配置|參數(shù)|示例|注意|說明|總結(jié)), # 關(guān)鍵詞開頭 ] def is_section_boundary(line): line line.strip() if not line or len(line) 40: # 標(biāo)題一般不超過40字 return False for pat in SECTION_PATTERNS: if re.match(pat, line): return True return False def split_by_section(text): lines text.split(\n) sections [] current [] for i, line in enumerate(lines): # 空行 下一行是標(biāo)題特征 章節(jié)邊界 if is_section_boundary(line) and current: sections.append(\n.join(current).strip()) current [line] else: current.append(line) if current: sections.append(\n.join(current).strip()) return [s for s in sections if s]4.3 章節(jié)內(nèi)的二次切分章節(jié)切分完還要處理一個問題有的章節(jié)太長。一個章節(jié)幾千字直接嵌入會超出模型的最大輸入長度而且語義太雜檢索精度反而下降。所以章節(jié)內(nèi)還要做二次切分。二次切分的策略和固定切分不同要優(yōu)先在段落邊界切。段落是天然的語義單元在段落之間切比在句子中間切好得多。我的做法是按段落累加長度超過閾值比如 400 字就切一刀同時保留上一段的最后一句作為重疊保證跨塊的語義連貫。def split_section(section, max_len400, overlap_sentences1): paragraphs [p for p in section.split(\n) if p.strip()] chunks [] current for para in paragraphs: if len(current) len(para) max_len and current: chunks.append(current.strip()) # 保留上一塊最后一句作為重疊 last_sent re.split(r[。], current)[-2] if 。 in current else current last_sent para else: current para \n if current.strip(): chunks.append(current.strip()) return chunks4.4 切分參數(shù)的調(diào)優(yōu)經(jīng)驗切分參數(shù)沒有萬能值要根據(jù)文檔特點調(diào)。我總結(jié)了幾條經(jīng)驗。塊大小。中文文檔單塊 300 到 500 字比較合適。太小語義不完整太大檢索精度下降。英文文檔可以適當(dāng)放大到 500 到 800 詞。重疊長度。重疊是為了防止關(guān)鍵信息正好落在切分點上被切斷。重疊 10% 到 15% 比較合適也就是 400 字的塊重疊 40 到 60 字。重疊太多會導(dǎo)致檢索結(jié)果重復(fù)浪費上下文窗口。章節(jié)優(yōu)先于長度。如果章節(jié)邊界和長度閾值沖突優(yōu)先按章節(jié)切。寧可某一塊短一點也不要跨章節(jié)切?？缯鹿?jié)的塊語義混亂檢索出來會誤導(dǎo)模型。提示切分完一定要人工抽查幾塊看看有沒有把完整語義切碎。這一步花十分鐘能省掉后面幾小時的調(diào)參。5. 三塊拼起來完整鏈路的聯(lián)調(diào)與驗證5.1 聯(lián)調(diào)時最容易出問題的環(huán)節(jié)三塊單獨跑通不難拼起來才是考驗。我踩過的聯(lián)調(diào)坑主要有三個?？右桓膶懞蟮牟樵儧]同步給檢索和生成。改寫發(fā)生在檢索前但生成階段拼 prompt 時如果用的是原始查詢而不是改寫后的查詢模型看到的上下文和檢索結(jié)果對不上答案會跑偏。記住改寫后的查詢要貫穿整條鏈路?？佣蛄烤彺婧臀臋n更新不同步。文檔更新了但緩存里還是舊向量檢索結(jié)果就是舊的。解決辦法是給文檔加版本號或更新時間戳文檔一變就清掉對應(yīng)緩存?？尤鹿?jié)切分和向量化的順序。正確順序是先切分再向量化每個塊單獨嵌入。如果先整篇嵌入再切分切出來的塊沒有對應(yīng)向量檢索無從談起。5.2 一套可復(fù)現(xiàn)的驗證方法怎么判斷這套方案到底有沒有效果不能靠感覺要有量化指標(biāo)。我搭了一個小評測集準(zhǔn)備 50 到 100 個真實問題每個問題標(biāo)注好它應(yīng)該命中的文檔片段ground truth。然后跑檢索看 Top-1、Top-3、Top-5 的命中率。對比開啟和關(guān)閉指代消解、本地和云端嵌入、固定切分和章節(jié)切分這幾組變量就能清楚看到每塊的價值。配置Top-1 命中率Top-3 命中率說明基線固定切分本地嵌入無改寫52%68%對照組章節(jié)切分61%76%切分貢獻明顯云端嵌入74%87%嵌入貢獻最大指代消解82%92%多輪場景提升顯著這組數(shù)據(jù)是我自己項目里的實測值具體數(shù)字會因文檔和查詢而異但趨勢是穩(wěn)定的云端嵌入帶來的提升最大指代消解在多輪場景下提升明顯章節(jié)切分是基礎(chǔ)但不可省。5.3 延遲與成本的實測賬效果之外還要算延遲和成本的賬否則方案再準(zhǔn)也落不了地。延遲方面指代消解規(guī)則層幾乎零延遲小模型改寫增加 200 到 500 毫秒云端嵌入一次請求 100 到 300 毫秒本地向量檢索幾十毫秒本地大模型生成是主要耗時幾秒到十幾秒。整體看檢索鏈路增加的開銷在可接受范圍內(nèi)瓶頸還是生成。成本方面云端嵌入按 token 計費一次查詢通常幾十個 token成本可以忽略。真正要控制的是別把文檔向量反復(fù)重算靠緩存解決。只要緩存做得好日常運行的成本基本就是查詢嵌入的費用非常低。5.4 幾個提升魯棒性的小技巧最后分享幾個讓方案更穩(wěn)的小技巧。查詢改寫加超時。小模型改寫偶爾會卡住加個超時比如 1 秒超時就退回規(guī)則層結(jié)果別讓整個請求掛死。檢索結(jié)果去重。雙路檢索或者重疊切分會導(dǎo)致重復(fù)片段檢索后按內(nèi)容哈希去重避免同樣的內(nèi)容占滿上下文窗口。保留原始查詢做日志。改寫后的查詢用于檢索但日志里要同時記錄原始查詢和改寫結(jié)果方便排查為什么這次答錯了。很多時候問題就出在改寫把原意改歪了。定期重建索引。文檔更新、嵌入模型升級、切分策略調(diào)整都會讓舊索引失效。定個周期比如每周重建一次索引保證檢索質(zhì)量。這套方案我在幾個本地知識庫項目里都跑過從技術(shù)文檔問答到內(nèi)部資料檢索效果比裸奔的 RAG 穩(wěn)定太多。核心就一句話把查詢改對、把向量算準(zhǔn)、把文檔切好剩下的交給大模型。