1. 為什么說文本分塊決定了RAG的上限1.1 檢索單元與生成質(zhì)量的連鎖關(guān)系做RAG項目這幾年我一直有個判斷評估一個檢索增強(qiáng)生成系統(tǒng)的上限最先看的是文本分塊策略而不是Embedding模型選得多強(qiáng)、Prompt寫得多么花哨。原因是整個RAG流水線里向量化、檢索、重排、生成這幾個環(huán)節(jié)全部圍繞一個核心單位展開——被切出來的文本塊chunk。文本塊既是向量的最小載體也是檢索召回的最小單元更是喂給大模型的最小上下文。可以這么理解如果把RAG系統(tǒng)比作一家餐廳Embedding模型是廚師大模型是最終上菜的顧客文本分塊則是后廚的切配工序。切得好后廚出菜穩(wěn)定、顧客吃得舒服切得稀碎再好的廚師也難做出完整的菜。分塊直接決定三件事召回質(zhì)量、上下文完整性、生成答案的準(zhǔn)確率。你切出來的塊如果把一個完整句子攔腰截斷檢索召回后大模型看到的只能是一堆語無倫次的碎片反之如果塊太大又容易被向量模型壓縮成平均語義導(dǎo)致檢索結(jié)果不精準(zhǔn)。適合閱讀這篇內(nèi)容的人我大致分為三類一是剛開始搭RAG知識庫、被“為什么我的問答效果這么差”困擾的開發(fā)者二是已經(jīng)在用LangChain做文檔問答但想系統(tǒng)搞懂文本分割器Splitter參數(shù)怎么調(diào)的人三是需要處理各種格式文檔PDF、Markdown、Word、HTML并希望保留結(jié)構(gòu)化信息的工程師。我會把LangChain家族里常用的文本分割器全部過一遍再給出一個可以直接套用的實戰(zhàn)流程。1.2 分塊不佳的典型翻車現(xiàn)場先看幾個真實踩過的坑方便你對照自己是否正在經(jīng)歷。第一個翻車現(xiàn)場不分塊整本手冊直接塞進(jìn)向量庫。某同事最開始做產(chǎn)品說明書問答時把一份30頁的PDF整篇丟進(jìn)Embedding模型向量庫倒是建成了但用戶問“怎么重置設(shè)備密碼”時召回的結(jié)果永遠(yuǎn)是一整本手冊的向量雷同度極高Top 5全是一個模子出來的。大模型看著一整篇泛泛的文檔只能給出一句“請參考說明書第X章”。這是典型的塊粒度過大導(dǎo)致向量表征失焦。第二個翻車現(xiàn)場分塊太機(jī)械每500字符一刀切。另一個項目拿字符數(shù)作為唯一標(biāo)準(zhǔn)500個字符一切結(jié)果把表格、代碼片段、標(biāo)題和正文完全撕裂。用戶問“API的鑒權(quán)參數(shù)在哪”召回來的塊里只剩半個表格列名都在上一個塊里。大模型再怎么生成也拼不出正確答案因為信息本身就被拆散了。第三個翻車現(xiàn)場完全不做重疊overlap。很多教程教你設(shè)chunk_size500但沒提overlap結(jié)果正好把一段邏輯連貫的話從中間切斷塊與塊之間丟失了上下文銜接。雖然每兩個相鄰塊在語義上都存在斷點檢索時關(guān)鍵詞剛好落在斷裂處的概率還不低但召回的塊側(cè)來看信息往往是不完整的。這三個問題有一個共同點工程上看起來都沒報錯向量庫也建出來了可就是召回質(zhì)量差。所以把文本分塊單獨拉出來重點講是RAG落地繞不開的基礎(chǔ)課。2. LangChain文本分割器全景先選對工具2.1 常用Splitter一覽與選型LangChain的langchain_text_splitters模塊提供了一整套文本分割器用之前建議先對家族成員有個整體認(rèn)知。我按適用場景列一個速查表分割器切分依據(jù)適用場景注意事項RecursiveCharacterTextSplitter遞歸匹配分隔符列表通用文檔、純文本、代碼混合文檔默認(rèn)首選需自定義分隔符CharacterTextSplitter固定字符分隔分隔符非常明確的文本分隔符單一遇到復(fù)雜布局容易失效TokenTextSplitterToken數(shù)量對接模型上下文窗口不同類型模型Token計算方法不同SentenceTransformersTokenTextSplitter模型內(nèi)部分詞與特定Embedding模型深度綁定依賴對應(yīng)分詞庫MarkdownHeaderTextSplitterMarkdown標(biāo)題層級筆記、文檔站、README天然保留結(jié)構(gòu)化信息HTMLHeaderTextSplitterHTML標(biāo)簽結(jié)構(gòu)網(wǎng)頁正文抓取后的清洗要配合HTMLSectionSplitter理解布局RecursiveJsonSplitterJSON鍵/數(shù)組元素配置、接口返回等半結(jié)構(gòu)化數(shù)據(jù)按深度切分適合層級很大的JSON單看表會很抽象實際選型只需要記住一個原則先用最通用的工具發(fā)現(xiàn)它在特定格式上不夠好再換針對性工具。對我來說RecursiveCharacterTextSplitter是90%場景的起點Markdown/HTML分隔器則是做文檔站和知識庫時的有力補(bǔ)充。2.2 RecursiveCharacterTextSplitter才是默認(rèn)首選為什么把RecursiveCharacterTextSplitter放到默認(rèn)首選位置因為它解決了一個其他分割器沒解決的問題文檔中分隔符的優(yōu)先級是不同的。段落之間的雙換行是最高級別的分隔單換行次之空格再弱一些最后才是字符級的暴力切割。多數(shù)技術(shù)文檔恰恰是按這種層級組織文本的。換個生活化的說法它像人切菜時的思路先沿最自然的大紋理切切出來的塊還太大就沿小紋理繼續(xù)切直到每個塊都符合大小要求。而不是拿一把砍刀固定長度亂剁。RecursiveCharacterTextSplitter內(nèi)部維護(hù)一個分隔符列表默認(rèn)大概是這樣的順序[\n\n, \n, , ]處理流程可以歸納成三步用最高優(yōu)先級分隔符\n\n段落把原始文本切成若干段如果某一段長度還是超過chunk_size就用下一級分隔符\n繼續(xù)切如果切到最后仍超長就用空字符串逐個字符切這一步是兜底避免死循環(huán)。簡單說它盡量保持語義上自然的塊實在超過了上限才犧牲語義完整性。對應(yīng)的使用示例也很直接from langchain_text_splitters import RecursiveCharacterTextSplitter text 項目背景介紹 本系統(tǒng)是一套面向內(nèi)部業(yè)務(wù)的跨平臺數(shù)據(jù)管理系統(tǒng)核心功能包括數(shù)據(jù)接入、質(zhì)量校驗、可視化分析。 主要模塊如下 - 數(shù)據(jù)接入模塊支持多種數(shù)據(jù)源并提供增量同步能力。 - 質(zhì)量校驗?zāi)K基于規(guī)則引擎對字段缺失、值域異常進(jìn)行實時檢查。 splitter RecursiveCharacterTextSplitter( chunk_size50, chunk_overlap10, length_functionlen ) chunks splitter.split_text(text) for idx, chunk in enumerate(chunks): print(f chunk {idx} ) print(chunk)注意這里chunk_size50的“50”指的是50個字符len統(tǒng)計并不是50個Token。先記住這個區(qū)別后面我會專門講字符與Token之間的關(guān)系。2.3 其他Splitter的適用場景拆解再看幾個值得掌握的專用分割器。CharacterTextSplitter是最簡樸的分割器它只按單個分隔符切分。適合那種分隔符非常規(guī)整、不會出現(xiàn)嵌套結(jié)構(gòu)的文本。比如按句號分、按分號分。缺點是遇到復(fù)雜布局就非常吃力一旦段落里出現(xiàn)多級分隔固定分隔符就顯得僵化。MarkdownHeaderTextSplitter很有意思它根據(jù)Markdown的一級標(biāo)題、二級標(biāo)題、三級標(biāo)題層級來分塊。比如一份技術(shù)文檔的結(jié)構(gòu)是“# 第一章”下面的“## 1.1 背景”它會把“## 1.1 背景”下的正文切成一個塊并把“第一章”“1.1 背景”作為標(biāo)題元數(shù)據(jù)保留下來。這種做法對知識庫極其友好因為檢索召回某一個塊時你能知道它屬于哪個章節(jié)可以做更精準(zhǔn)的引用溯源。后續(xù)如果想做父子塊檢索或者分層檢索這是很關(guān)鍵的一步。TokenTextSplitter按模型分詞后的Token數(shù)量切分更貼近模型視角。用一個實際的Embedding服務(wù)時如果模型最大輸入是512個Token用TokenTextSplitter(chunk_size256)會比用字符數(shù)分塊安全得多因為不會出現(xiàn)誤算了中英文長度導(dǎo)致向量化報錯的問題。實操上我經(jīng)常組合使用先按Markdown標(biāo)題切分出大段落再用RecursiveCharacterTextSplitter將過長的段落二次切分同時把標(biāo)題信息透傳到每個子塊。語言環(huán)境里的中文用戶對這種方式接受度最高既保住了結(jié)構(gòu)又控制住了長度。3. 實戰(zhàn)手把手完成一個知識庫分塊流程3.1 準(zhǔn)備示例文檔和依賴我以一個模擬項目X的運維手冊為例演示完整的文本分塊流程。先建立一個示例文檔ops_manual.md# 運維手冊 ## 1. 系統(tǒng)部署 ### 1.1 環(huán)境要求 生產(chǎn)環(huán)境需要本次安裝的運行時版本大于等于某個指定版本內(nèi)存建議不低于8GB磁盤剩余空間不低于20GB。 ### 1.2 部署步驟 1. 解壓安裝包到指定目錄。 2. 修改配置文件中的連接串信息。 3. 執(zhí)行初始化腳本等待數(shù)據(jù)庫結(jié)構(gòu)創(chuàng)建完成。 4. 啟動主服務(wù)觀察日志輸出。 ## 2. 故障排查 ### 2.1 服務(wù)無法啟動 確認(rèn)端口是否被占用檢查日志中的錯誤碼定位異常模塊。 ### 2.2 磁盤空間不足 清理臨時文件歸檔歷史日志必要時擴(kuò)縮容磁盤資源。然后在工程里創(chuàng)建虛擬環(huán)境并安裝依賴pip install langchain langchain-text-splitters langchain-openai chromadb這里需要說明一下langchain-text-splitters的導(dǎo)入路徑與早期LangChain版本不同。如果你沿用舊代碼里from langchain.text_splitter import ...的寫法在較新版本中可能已經(jīng)不可用。統(tǒng)一的寫法是from langchain_text_splitters import ...。3.2 參數(shù)調(diào)優(yōu)chunk_size與chunk_overlap的正確打開方式很多人把chunk_size和chunk_overlap看成兩個孤立的參數(shù)但實際上它們是一組配合使用的約束。我把它們的含義翻譯成大白話chunk_size每個塊的目標(biāo)“最大長度”超過會被繼續(xù)切分。chunk_overlap相鄰兩個塊之間共享的“重疊長度”目的是讓跨塊的上下文信息不要徹底丟失。為什么需要重疊因為你永遠(yuǎn)無法保證一個語義完整的句子恰好落在一個塊內(nèi)。句子的后半句可能垂到下一個塊如果沒有重疊檢索時如果命中的是上一個塊下一個塊中的承接內(nèi)容就無法被模型看到。加上重疊之后塊與塊之間有了緩沖帶上下文銜接更自然。重疊數(shù)值的設(shè)定我通常取chunk_size的10%到20%。比如chunk_size500時chunk_overlap取50到100。如果太大會出現(xiàn)嚴(yán)重的重復(fù)存儲問題同一個句子被多個塊重復(fù)引用向量庫里冗余度暴增檢索時一個關(guān)鍵詞還會召回到大量內(nèi)容雷同的塊反而干擾重排模型。太小則等于沒有重疊。再看一個實際數(shù)字案例。假設(shè)文檔總長度為2000個字符chunk_size500、chunk_overlap50理論上生成的塊數(shù)可以用一個簡單公式估算塊數(shù) ceil((總長度 - overlap) / (chunk_size - overlap))代入ceil((2000 - 50) / (500 - 50)) ceil(1950 / 450) ≈ 5。也就是說會產(chǎn)生5個左右的塊。如果完全不重疊ceil(2000 / 500) 4。多出來的一個塊就是重疊機(jī)制帶來的上下文冗余這是合理代價。在這個模擬項目X里先用一段腳本打印分塊結(jié)果from langchain_text_splitters import RecursiveCharacterTextSplitter with open(ops_manual.md, r, encodingutf-8) as f: raw_text f.read() splitter RecursiveCharacterTextSplitter( chunk_size80, chunk_overlap12, length_functionlen, add_start_indexTrue ) chunks splitter.split_text(raw_text) for idx, chunk in enumerate(chunks): print(f----- chunk {idx} -----) print(chunk)chunk_size80是我為了演示故意調(diào)小的生產(chǎn)環(huán)境不會這么小。通過輸出可以清楚看到總會被優(yōu)先以段落邊界切割過長的段落繼續(xù)以單換行切分單換行還不滿足再按空格切。中文文本沒有空格分隔兜底邏輯就會按字符切這也是為什么中文場景下要重視自定義分隔符。3.3 元數(shù)據(jù)保留與后處理真正生產(chǎn)環(huán)境里我們不僅需要分塊文本本身還要保留來源信息。單純split_text只能拿回字符串列表無法攜帶文件名、章節(jié)、頁碼這些上下文。更推薦的方式是使用create_documents或split_documents來處理Document對象。我通常這樣組織from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter loader TextLoader(ops_manual.md, encodingutf-8) documents loader.load() splitter RecursiveCharacterTextSplitter( chunk_size256, chunk_overlap40, length_functionlen, ) split_docs splitter.split_documents(documents) for doc in split_docs: print(doc.page_content[:20], | meta:, doc.metadata)注意split_documents會把原Document中的metadata自動復(fù)制到每個子塊。如果有多個文件來源加載時為每個文檔加上source字段后續(xù)檢索定位到某個塊就能知道它來自哪個文件。這一步看似簡單但沒做的話等知識庫膨脹到幾千個塊時你根本沒法溯源問答系統(tǒng)給出答案用戶也沒法核對。實際開發(fā)中我還會在分塊后做一次清洗和后處理。比如塊內(nèi)有多余空行我會壓縮成單個換行塊首尾出現(xiàn)孤立標(biāo)點我會嘗試把它們合并到相鄰塊塊內(nèi)容如果只有一兩個字符我會直接丟棄因為它們基本是純噪聲。這些后處理邏輯不需要很復(fù)雜但能顯著提升向量入庫的質(zhì)量。4. 參數(shù)背后的原理與經(jīng)驗值4.1 chunk_size到底取多少三條經(jīng)驗法則被問得最多的問題是“chunk_size到底選多少合適”這個問題沒有標(biāo)準(zhǔn)答案但有三條經(jīng)驗法則可以參考。第一條取決于Embedding模型和重排模型的輸入上限。如果采用的向量接口最長輸入是512個Token那么塊長建議控制在256到384個Token留出安全余量。一旦塊長超過模型輸入上限向量化階段會出現(xiàn)截斷或直接報錯。第二條取決于檢索方案。如果只用向量Top K召回塊小一些200到300 Token通常更精準(zhǔn)。如果后面還接了重排序模型塊可以適當(dāng)放大到400到600 Token先寬松召回再由重排模型精挑細(xì)選。重排模型能幫你補(bǔ)救一些塊稍大帶來的語義稀釋但前提是你得先有重排環(huán)節(jié)。第三條取決于文檔本身的結(jié)構(gòu)密度。操作手冊這類強(qiáng)結(jié)構(gòu)文檔按章節(jié)切分最理想塊的大小天然由內(nèi)容決定。法律合同、學(xué)術(shù)論文這類長段落文檔塊往往需要一個上限防止一個1000字的段落整段入庫。代碼文檔的特殊性更強(qiáng)最好讓代碼塊和說明文字分開切分否則“代碼注釋正文”揉在一起檢索定位會很難受。我用一張表總結(jié)不同場景的經(jīng)驗區(qū)間場景建議塊長建議重疊理由通用知識庫問答300-500 Token10%-15%平衡語義完整性與召回精準(zhǔn)度代碼檢索增強(qiáng)150-300 Token5%-10%代碼塊獨立性強(qiáng)重疊過多會引入冗余法律/學(xué)術(shù)長文本500-800 Token10%-15%避免破壞論證結(jié)構(gòu)塊太小會丟失上下文結(jié)構(gòu)化文檔按標(biāo)題章節(jié)切0-5%標(biāo)題是天然語義邊界不必強(qiáng)湊字?jǐn)?shù)面向重排模型400-600 Token10%-15%給重排模型足夠的候選上下文這些數(shù)據(jù)不是死標(biāo)準(zhǔn)我是拿真實項目調(diào)試出來的。也建議你在自己的語料上做A/B對比往下看我會給一個簡單評估方法。4.2 用Token而非字符數(shù)來度量進(jìn)到實際工程階段建議盡早拋棄“字符數(shù)”這個度量單位。中文場景下用len計算字符數(shù)容易產(chǎn)生嚴(yán)重誤判。舉個直觀例子一段純中文的80字文本在大多數(shù)模型里大概是35到45個Token而一段包含大量英文和數(shù)字符號的80字符文本Token數(shù)可能達(dá)到60以上。如果Embedding模型限512 Token你按500字符切英文場景很容易悄悄超限。用Token計數(shù)的寫法如下import tiktoken from langchain_text_splitters import RecursiveCharacterTextSplitter tokenizer_name cl100k_base tokenizer tiktoken.get_encoding(tokenizer_name) def token_len(text): return len(tokenizer.encode(text)) splitter RecursiveCharacterTextSplitter( chunk_size256, chunk_overlap30, length_functiontoken_len, separators[\n\n, \n, 。, , , , ], )tiktoken是一個常用的分詞庫如果你用的是其他模型通常也能在它的配套SDK里找到分詞器。關(guān)鍵是length_function參數(shù)完全可定制你傳入什么函數(shù)分割器就以什么單位衡量長度。這是LangChain文本分割器非常優(yōu)雅的設(shè)計。chunk_size256表示256個Tokenoverlap設(shè)30只占總長的12%左右基本符合我上面提到的經(jīng)驗區(qū)間。4.3 常見分塊誤區(qū)第一個誤區(qū)是把所有文檔都交給同一個Splitter處理。PDF轉(zhuǎn)出來的文本、網(wǎng)頁抓取后的正文、Markdown源文件它們的結(jié)構(gòu)差異非常大。PDF文本經(jīng)常丟失換行和縮進(jìn)網(wǎng)頁正文有大量HTML殘留Markdown則有清晰標(biāo)題。統(tǒng)一用一套參數(shù)來處理效果一定差。正確做法是先識別文檔類型再選擇匹配的Splitter。第二個誤區(qū)是只關(guān)注塊的長度不關(guān)注塊的邊界質(zhì)量。好的分塊應(yīng)該“塊內(nèi)主題唯一塊間語義清晰”。如果一塊里包含了兩個完全無關(guān)的段落即使長度完全符合chunk_size檢索時也很容易因為關(guān)鍵詞分散導(dǎo)致向量被平均化。這也是為什么我前面一直強(qiáng)調(diào)盡量優(yōu)先按段落和標(biāo)題切分再考慮長度上限。第三個誤區(qū)是忽視重疊帶來的副作用。重疊并不是越多越好。我見過有人把overlap設(shè)成chunk_size的一半結(jié)果向量庫存儲量直接膨脹30%以上而且Embedding成本明顯增加。檢索階段經(jīng)常召回幾個只有少許差別的相似塊白白占滿Top K名額。重疊的目的是緩沖不是復(fù)制。第四個誤區(qū)是忽略塊與塊之間的連續(xù)性驗證。分塊完成后不少人直接入庫從不檢查相鄰塊首尾是否斷裂。建議在入庫前跑一個抽查腳本把相鄰塊的尾部與頭部拼接起來看看如果出現(xiàn)明顯句子斷裂就要重新調(diào)整分隔符或overlap。這一步特別花時間但對中文文本尤其值得。5. 常見問題與排查技巧實錄5.1 典型問題速查表把真實項目里高頻出現(xiàn)的問題整理成速查表方便你直接對照現(xiàn)象可能原因排查方向生成的塊是空字符串連續(xù)多個分隔符導(dǎo)致空段加載文檔后先做空行壓縮與strip中文句子被硬切破碎分隔符列表沒有包含中文標(biāo)點在separators中加入“?！钡葮?biāo)點向量化時報長度超限字符長度與Token長度判斷偏差改用Token長度函數(shù)一個Markdown章節(jié)被拆成多塊且丟失標(biāo)題直接使用通用分割器而非結(jié)構(gòu)化分割器使用MarkdownHeaderTextSplitter表格內(nèi)容拆分后無法閱讀固定字符切割破壞行列結(jié)構(gòu)優(yōu)先整表切塊或按行合并后再切代碼和說明被切到同一塊文檔混雜代碼與正文按代碼塊邊界先拆分再分別處理召回結(jié)果全是內(nèi)容重復(fù)的塊overlap設(shè)置過大調(diào)低重疊比例抽查相鄰塊重復(fù)度某個主題提問永遠(yuǎn)召回不到該主題恰好被切到多塊向量互相稀釋縮小chunk_size按更細(xì)主題重新切這些問題的共同點在于它們不是報錯形式出現(xiàn)的問題往往藏在實際問答效果里排查周期特別長。所以建立分塊后的人工抽查習(xí)慣比等系統(tǒng)出問題再找原因效率高很多。5.2 三個實測有效的調(diào)優(yōu)技巧第一個技巧是組合使用不同分割器。有一次處理一批Markdown格式的課程講義直接使用RecursiveCharacterTextSplitter結(jié)果所有標(biāo)題被當(dāng)作普通文本切斷。后來改成先用MarkdownHeaderTextSplitter切出章節(jié)再對超長章節(jié)二次切分。整體效果提升明顯檢索召回到的塊都自帶標(biāo)題上下文回答時模型能說出“根據(jù)第X章的內(nèi)容”可信度大增。第二個技巧是為不同段落設(shè)置不同的chunk_size。一個折中方案是文檔加載后先按段落長度做粗分類短段落保留為完整塊長段落再做遞歸切分。也就是說短的自然段落可以作為不可再分的最小單元防止過小的切分破壞語義。LangChain的TextSplitter本身沒有內(nèi)置這個邏輯但你可以先分組再調(diào)用或者自定義一個繼承TextSplitter的類重寫split_text方法。第三個技巧是在分塊前做一次文本標(biāo)準(zhǔn)化。常見處理包括壓縮連續(xù)空行、統(tǒng)一換行符、去掉不可見字符、將全角空格轉(zhuǎn)半角或刪除。這些看起來不起眼的操作往往能大幅提升分隔符匹配的穩(wěn)定性。我記得有一份來源不明的手冊里面夾雜著大量全角空格和Windows換行普通\n匹配效果極差做完標(biāo)準(zhǔn)化后分塊才走上正軌。5.3 分塊效果如何快速評估很多人不知道分塊效果怎么評估。其實不必一上來就做復(fù)雜的端到端評測先用一個“三看”法就能過濾掉大部分問題。一看塊內(nèi)完整性隨機(jī)抽20個塊看每塊的句子是否完整、主題是否單一。我通常讓助手角色腳本隨機(jī)抽一些塊打印出來人工掃一遍半小時內(nèi)就能判斷有沒有嚴(yán)重切割問題。二看檢索命中率先準(zhǔn)備10到15個標(biāo)準(zhǔn)問題用簡單的向量檢索把Top 3結(jié)果打印出來看正確答案是否在召回結(jié)果里。如果好幾個問題根本召回不到相關(guān)塊基本可以懷疑分塊粒度過大或過小。三看生成質(zhì)量這個問題只在大模型生成端看不考慮Prompt優(yōu)化先用一個中規(guī)中矩的Prompt做問答。如果答案經(jīng)常出現(xiàn)“上下文不完整”的表述說明召回到的塊沒有覆蓋答案所需信息如果答案出現(xiàn)內(nèi)容相互矛盾說明塊內(nèi)信息源混亂可能多個塊把不同主題揉在一起了。這套三看法不用任何額外框架適合在項目初期快速定位問題。我個人在實際操作中的體會是文本分塊在整個RAG系統(tǒng)里屬于投入產(chǎn)出比極高的環(huán)節(jié)。很多人花大量時間調(diào)Embedding模型、換數(shù)據(jù)庫卻忽略了最基礎(chǔ)的分塊策略。其實修正分塊往往立竿見影召回準(zhǔn)確率上來了大模型拿到的上下文干凈了答案質(zhì)量自然就提升。如果你正在做一個RAG項目建議先把這個環(huán)節(jié)打磨透再去碰那些花哨的高級功能。最后再分享一個小技巧所有分塊參數(shù)在代碼里最好用配置項而不是硬編碼這樣你就能在同一個語料集上快速做多組參數(shù)對比。我用這種方式曾經(jīng)把某個內(nèi)部知識庫的Top 5召回命中率從62%逐步提升到81%過程不復(fù)雜就是不斷切、不斷看、不斷調(diào)。