切片策略全解析：從固定長度到語義切分)
1. 被忽視的切片為什么它才是RAG系統(tǒng)的隱形天花板做RAG檢索增強生成的人十有八九把精力砸在了模型選型、向量庫調(diào)參、Prompt工程上卻對切片Chunking這一步草草了事。我見過太多項目embedding模型用的是頂配向量數(shù)據(jù)庫也是企業(yè)級方案但最終問答效果就是上不去——答案要么缺胳膊少腿要么檢索出一堆無關(guān)內(nèi)容。排查到最后問題往往出在最開始那一步文檔切片沒做好。切片之所以不起眼是因為它太“前處理”了。大家潛意識里覺得把文檔按固定字數(shù)切開扔進向量庫就完事了。但實際情況是切片策略直接決定了檢索系統(tǒng)能“看到”什么粒度的信息。切得太碎語義被割裂檢索出來的片段缺乏上下文生成模型拿到手里也拼不出完整答案切得太粗一個片段里混了好幾個主題向量表示被稀釋檢索精度斷崖式下跌。更麻煩的是這兩種錯誤在系統(tǒng)上線初期往往不會暴露——簡單問題還能應(yīng)付一旦用戶問得稍微具體一點短板立刻現(xiàn)形。這篇文章面向的是正在搭建或優(yōu)化RAG系統(tǒng)的開發(fā)者無論你用的是LangChain、LlamaIndex還是自研管線切片這一步都繞不開。我會從切片的本質(zhì)目標講起拆解幾種主流策略的適用場景和坑點給出可落地的參數(shù)建議最后分享一些我在實際項目中踩過的坑和驗證過的調(diào)優(yōu)手法。讀完你至少能判斷自己手頭的切片方案到底合不合格以及該往哪個方向改。2. 切片的本質(zhì)在語義完整與檢索精度之間找平衡2.1 切片到底在解決什么問題RAG系統(tǒng)的核心鏈路是用戶提問 → 檢索相關(guān)文檔片段 → 把片段塞進上下文 → 生成答案。切片就是這條鏈路的起點它決定了“相關(guān)文檔片段”這個中間產(chǎn)物的質(zhì)量。理想情況下每個切片應(yīng)該是一個語義自洽的單元——它獨立存在時人能看懂它在說什么它被檢索出來時能直接回答或支撐某個具體問題。但現(xiàn)實很骨感。一份文檔的語義結(jié)構(gòu)是樹狀的章包含節(jié)節(jié)包含段段包含句。切片本質(zhì)上是在這棵樹上找一個切割面把連續(xù)文本切成離散塊。切在哪里直接決定了每個塊的語義邊界是否清晰。切在段落之間語義完整度高但塊可能很長切在句子之間塊短了但上下文可能斷裂。這就是切片的核心矛盾語義完整性和檢索精度之間的權(quán)衡。2.2 固定長度切片的致命缺陷最常見的做法是按固定字符數(shù)切比如每500個字符一刀。這種做法實現(xiàn)簡單但問題很致命。假設(shè)一段文本正好在“該方案的優(yōu)勢在于”后面被切斷下一個塊以“成本低、部署快”開頭。檢索時如果用戶問“這個方案有什么優(yōu)勢”第一個塊可能被召回但答案的后半截在第二個塊里生成模型拿到的上下文是殘缺的。更糟糕的是第二個塊單獨看完全不知道在說什么向量表示會非常模糊檢索時容易被漏掉。固定長度切片還有一個隱蔽問題它完全無視文檔的天然結(jié)構(gòu)。技術(shù)文檔有標題、段落、列表、代碼塊法律合同有條款論文有摘要和章節(jié)。這些結(jié)構(gòu)本身就是語義邊界的強信號按固定長度切等于把這些信號全部丟棄。我做過一個對比實驗同一份技術(shù)文檔固定長度切片和按結(jié)構(gòu)切片在相同檢索問題下的召回率差了將近30個百分點。2.3 語義完整性與檢索精度的量化關(guān)系要理解這個權(quán)衡可以看一個簡化模型。假設(shè)文檔總長度為L切片長度為c切片數(shù)量n≈L/c。檢索時系統(tǒng)從n個塊中召回top-k個。每個塊的語義信息量可以粗略認為與c正相關(guān)但塊內(nèi)主題純度與c負相關(guān)——塊越長混入多個主題的概率越大。當c很小時每個塊主題純度高向量表示尖銳檢索精度高但塊內(nèi)信息量不足生成模型可能拿不到完整答案。當c很大時塊內(nèi)信息量足但向量表示被多個主題平均檢索時容易召回“什么都沾一點”的塊精度下降。存在一個最優(yōu)c使得檢索精度和答案完整度的乘積最大。這個最優(yōu)值取決于文檔類型、問題類型和embedding模型的能力沒有萬能數(shù)字。注意不要迷信網(wǎng)上流傳的“最佳切片長度是512 tokens”這類說法。那是在特定數(shù)據(jù)集、特定模型下的經(jīng)驗值換一個場景可能完全不適用。3. 主流切片策略的實戰(zhàn)拆解與選型邏輯3.1 按字符數(shù)硬切什么時候可以用什么時候絕對不能用按字符數(shù)硬切是最簡單的策略代碼幾行就能實現(xiàn)。它的適用場景非常有限文檔結(jié)構(gòu)極其規(guī)整比如每段都是獨立的知識點段與段之間沒有依賴關(guān)系。比如FAQ文檔每個問答對就是天然切片硬切反而不會出大問題。但在絕大多數(shù)場景下硬切都是災難。技術(shù)文檔、研究報告、法律文書、產(chǎn)品手冊這些文檔的語義是跨段落的。一個概念的定義可能在第一段展開在第二段舉例在第三段。硬切會把它們打散檢索時只能召回其中一塊生成模型拿到的信息是碎片化的。如果非要用硬切至少加一個重疊窗口overlap。比如每500字符切一刀但相鄰塊之間重疊100字符。這樣即使切在了句子中間下一個塊也能包含前一個塊的尾部內(nèi)容緩解語義斷裂。重疊比例一般設(shè)在10%到20%之間太小起不到作用太大則冗余嚴重檢索時容易召回大量重復內(nèi)容。def fixed_size_chunk(text, chunk_size500, overlap100): chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) start end - overlap return chunks這段代碼看起來沒問題但實際用的時候要注意如果文檔里有代碼塊或表格硬切可能把代碼從中間截斷導致語法錯誤。表格被切散后行列對應(yīng)關(guān)系丟失檢索出來完全沒法用。所以硬切之前最好先把代碼塊和表格單獨提取出來不要參與常規(guī)切片。3.2 按段落和標題切利用文檔的天然結(jié)構(gòu)大多數(shù)文檔都有天然的結(jié)構(gòu)信號標題、子標題、段落分隔符。按這些信號切能最大程度保持語義完整性。具體做法是先按標題層級把文檔拆成樹狀結(jié)構(gòu)每個葉子節(jié)點最小標題單元下的內(nèi)容作為一個候選切片。如果某個葉子節(jié)點內(nèi)容太長再按段落進一步切分。這種策略的好處是每個切片都有明確的主題歸屬。檢索時如果用戶的問題匹配到某個標題可以直接定位到對應(yīng)切片精度很高。而且切片自帶層級信息可以在檢索時利用標題做過濾或加權(quán)。但要注意標題層級不一定規(guī)整。有些文檔標題層級混亂或者根本沒有標題。這時候可以退而求其次按段落切。段落是作者有意劃分的語義單元按段落切比按字符切合理得多。如果段落本身太長比如超過1000字再考慮按句子切分。import re def paragraph_chunk(text, max_length800): paragraphs re.split(r\n\s*\n, text) chunks [] current for para in paragraphs: if len(current) len(para) max_length: current para \n\n else: if current: chunks.append(current.strip()) current para \n\n if current: chunks.append(current.strip()) return chunks這個實現(xiàn)有個細節(jié)它不是簡單地把每個段落單獨成塊而是盡量把短段落合并到接近max_length。這樣避免產(chǎn)生大量過短的切片影響檢索效率。但合并時要注意不要把不同主題的段落硬湊在一起。一個簡單的判斷方法是看相鄰段落的相似度如果相似度低于閾值就不合并。3.3 遞歸切分LangChain的默認策略到底靠不靠譜LangChain的RecursiveCharacterTextSplitter是很多人用的默認方案。它的邏輯是先嘗試用第一優(yōu)先級分隔符比如雙換行切如果切出來的塊還是太大就用第二優(yōu)先級分隔符比如單換行繼續(xù)切以此類推。分隔符列表通常是[\n\n, \n, 。, , ]從粗到細。這個策略比硬切聰明因為它優(yōu)先在語義邊界處切。但它也有問題分隔符列表是固定的不感知文檔的實際結(jié)構(gòu)。比如一份Markdown文檔標題是用#標記的但分隔符列表里沒有#遞歸切分可能把標題和正文切開導致切片丟失標題信息。另外遞歸切分的終止條件是塊大小小于chunk_size但它不保證塊內(nèi)語義完整。如果文檔里有一段很長的連續(xù)文本沒有任何換行或標點遞歸切分最后會退化成按字符硬切。所以用這個策略時要針對文檔類型定制分隔符列表。比如處理Markdown時把## 、### 加進去處理代碼時把\nclass 、\ndef 加進去。3.4 語義切片用embedding找真正的語義邊界語義切片是更高級的做法先對文本按句子切分然后計算相鄰句子的embedding相似度。如果相似度低于某個閾值說明這里可能是主題轉(zhuǎn)換點就在這里切一刀。這樣切出來的塊內(nèi)部語義一致性高塊與塊之間的邊界也更有意義。具體實現(xiàn)上可以用sentence-transformers計算句子向量然后計算相鄰句子的余弦相似度。閾值一般設(shè)在0.5到0.7之間具體取決于文檔類型。技術(shù)文檔的閾值可以低一點因為技術(shù)概念之間的關(guān)聯(lián)性本身就弱敘事類文檔的閾值可以高一點因為故事線是連貫的。from sentence_transformers import SentenceTransformer import numpy as np model SentenceTransformer(all-MiniLM-L6-v2) def semantic_chunk(sentences, threshold0.6): embeddings model.encode(sentences) chunks [] current_chunk [sentences[0]] for i in range(1, len(sentences)): sim np.dot(embeddings[i-1], embeddings[i]) / ( np.linalg.norm(embeddings[i-1]) * np.linalg.norm(embeddings[i]) ) if sim threshold: chunks.append( .join(current_chunk)) current_chunk [sentences[i]] else: current_chunk.append(sentences[i]) if current_chunk: chunks.append( .join(current_chunk)) return chunks語義切片的缺點是計算成本高。一份長文檔可能有幾千個句子每個句子都要算embedding耗時可能幾十秒甚至幾分鐘。而且閾值不好定需要針對具體文檔調(diào)。我的經(jīng)驗是語義切片適合對精度要求極高的場景比如法律合同檢索、醫(yī)療文獻問答。對于一般的技術(shù)文檔或產(chǎn)品手冊按結(jié)構(gòu)切分已經(jīng)夠用了。3.5 策略選型對照表策略適用場景優(yōu)點缺點推薦參數(shù)固定長度硬切FAQ、短文本集合實現(xiàn)簡單速度快語義斷裂嚴重chunk_size300-500overlap10%-20%按段落/標題切結(jié)構(gòu)清晰的文檔語義完整自帶層級依賴文檔結(jié)構(gòu)質(zhì)量max_length500-1000遞歸切分通用場景平衡了結(jié)構(gòu)和靈活性分隔符需定制chunk_size500-800分隔符按文檔類型調(diào)整語義切片高精度要求場景語義邊界準確計算成本高閾值難調(diào)相似度閾值0.5-0.74. 切片參數(shù)調(diào)優(yōu)從500到1500我踩過的那些坑4.1 chunk_size不是拍腦袋定的很多人設(shè)chunk_size就是拍腦袋看別人用500就跟著用500。但chunk_size應(yīng)該由文檔類型和問題類型共同決定。如果用戶的問題通常很具體比如“XX功能的配置參數(shù)是什么”那切片應(yīng)該小一點讓檢索能精確定位到參數(shù)所在的段落。如果用戶的問題比較宏觀比如“這個系統(tǒng)的架構(gòu)設(shè)計思路”那切片可以大一點包含更多上下文。我一般會先分析用戶問題的平均長度和具體程度。如果問題平均在10個字以內(nèi)且大多是事實型查詢chunk_size設(shè)在300到500之間比較合適。如果問題平均在20字以上且涉及推理或總結(jié)chunk_size可以放到800到1200。另外embedding模型的最大輸入長度也是一個硬約束。比如all-MiniLM-L6-v2最大支持256個token如果chunk_size超過這個數(shù)后面的內(nèi)容會被截斷等于白切。4.2 overlap設(shè)多少才不浪費overlap的作用是防止語義在邊界處丟失但它不是越大越好。overlap太大相鄰切片重復內(nèi)容多檢索時會召回大量相似結(jié)果浪費上下文窗口。overlap太小起不到緩沖作用。我的經(jīng)驗是overlap設(shè)在chunk_size的10%到15%之間比較合理。比如chunk_size500overlap設(shè)50到75。但有一種情況需要加大overlap文檔里有很多跨段落的指代關(guān)系。比如第一段說“該方案有三個優(yōu)勢”第二段分別展開。如果切片正好切在第二段中間第一個切片可能只包含第一個優(yōu)勢第二個切片包含后兩個優(yōu)勢但第二個切片開頭沒有“該方案”的上下文檢索時可能匹配不上。這時候把overlap加大到20%到30%讓第二個切片也包含“該方案有三個優(yōu)勢”這句話就能解決。4.3 切片長度分布比平均值更重要調(diào)參時不要只看平均切片長度要看長度分布。如果大部分切片在500字左右但有幾個切片超過2000字這幾個超長切片就是隱患。它們可能包含多個主題向量表示模糊檢索時要么召不回要么召回了但生成模型被無關(guān)信息干擾。我一般會統(tǒng)計切片長度的百分位數(shù)。如果90分位數(shù)超過平均值的2倍說明切片長度分布不均勻需要調(diào)整切分策略。比如對超長段落做二次切分或者對過短切片做合并。理想情況下切片長度應(yīng)該集中在目標值附近標準差不要太大。4.4 用檢索指標反推切片質(zhì)量切片好不好最終要看檢索效果。我習慣在切片完成后構(gòu)造一批測試問題然后看檢索的召回率和精確率。具體做法是對每個測試問題人工標注哪些切片是相關(guān)的然后看系統(tǒng)召回的top-k里有多少是相關(guān)的。如果召回率低說明切片粒度太粗或語義邊界不清如果精確率低說明切片粒度太細或重疊太多。這個評估過程不需要很復雜幾十個測試問題就能看出趨勢。關(guān)鍵是測試問題要覆蓋不同類型的查詢事實型、推理型、總結(jié)型。如果某類問題的指標明顯偏低就針對性地調(diào)整切片策略。比如事實型問題召回率低就把chunk_size調(diào)小總結(jié)型問題召回率低就把chunk_size調(diào)大或增加overlap。5. 特殊文檔的切片處理代碼、表格、多語言混排5.1 代碼塊切片別把函數(shù)從中間切斷技術(shù)文檔里經(jīng)常夾雜代碼塊。代碼的語義單元是函數(shù)或類從中間切斷會導致語法錯誤檢索出來也沒法用。處理方法是先用正則表達式把代碼塊提取出來單獨作為一個切片或者按函數(shù)/類邊界切分。如果代碼塊太長可以按邏輯塊切比如一個函數(shù)一個切片但要在切片開頭保留函數(shù)簽名和注釋。import re def extract_code_blocks(text): pattern r(\w*)\n(.*?) blocks [] for match in re.finditer(pattern, text, re.DOTALL): lang match.group(1) code match.group(2) blocks.append({lang: lang, code: code, start: match.start(), end: match.end()}) return blocks提取出來后代碼塊不參與常規(guī)文本切片而是單獨建立索引。檢索時如果問題涉及代碼可以優(yōu)先從代碼塊索引中召回。這樣既保證了代碼完整性又不會干擾文本切片的語義純度。5.2 表格切片保留行列對應(yīng)關(guān)系表格被切散是另一個常見問題。一個表格如果被切成兩半前半部分有表頭沒有數(shù)據(jù)后半部分有數(shù)據(jù)沒有表頭檢索出來完全沒法解讀。處理方法是把整個表格作為一個切片如果表格太大按行切分但每個切片都要帶上表頭。具體做法是解析表格結(jié)構(gòu)提取表頭然后按行分組。每組行數(shù)根據(jù)表格寬度和chunk_size決定但每組都必須包含表頭。這樣每個切片都是一個自包含的小表格檢索出來可以直接用。5.3 多語言混排文檔的切片陷阱中英文混排的文檔按字符數(shù)切分會出現(xiàn)嚴重偏差。中文一個字符的信息量遠大于英文一個字符同樣500字符中文可能只有一段話英文可能有好幾段。如果按字符數(shù)統(tǒng)一切中文切片會偏長英文切片會偏短。解決辦法是按token數(shù)切而不是字符數(shù)。用tokenizer把文本轉(zhuǎn)成token序列然后按token數(shù)切分。這樣中英文的信息量就對齊了。大多數(shù)embedding模型都有對應(yīng)的tokenizer直接用就行。如果不想引入tokenizer也可以按語言分別處理中文按字符數(shù)切英文按單詞數(shù)切然后合并。6. 切片之后存儲、索引與檢索的聯(lián)動優(yōu)化6.1 切片元數(shù)據(jù)別只存文本切片存進向量庫時不要只存文本和向量。元數(shù)據(jù)至少應(yīng)該包含來源文檔ID、切片在文檔中的位置起止字符或頁碼、所屬標題層級、切片類型正文/代碼/表格。這些元數(shù)據(jù)在檢索時非常有用。比如可以按標題層級過濾只召回特定章節(jié)的內(nèi)容或者按切片類型加權(quán)代碼類問題優(yōu)先召回代碼切片。元數(shù)據(jù)還有一個用途是溯源。生成模型給出答案后可以展示答案來自哪個文檔的哪個部分方便用戶驗證。這在企業(yè)場景下尤其重要用戶不會盲目相信模型生成的內(nèi)容需要能追溯到原始文檔。6.2 父子切片用小塊檢索用大塊生成這是一個很實用的技巧建索引時用小塊生成時用大塊。具體做法是把文檔切成兩層父塊和子塊。父塊較大比如1000字保證語義完整子塊較小比如200字保證檢索精度。檢索時用子塊匹配問題命中后返回對應(yīng)的父塊給生成模型。這樣既解決了小塊檢索精度高但信息不足的問題又解決了大塊信息足但檢索不準的問題。實現(xiàn)上每個子塊存一個父塊ID檢索到子塊后根據(jù)ID取出父塊。LangChain的ParentDocumentRetriever就是干這個的但自己實現(xiàn)也不復雜。6.3 切片與embedding模型的匹配不同embedding模型對切片長度的敏感度不同。有些模型在短文本上表現(xiàn)好有些在長文本上更穩(wěn)。選切片策略時要結(jié)合embedding模型的特點。比如OpenAI的text-embedding-ada-002對512 token以內(nèi)的文本效果最好超過后性能下降。而有些開源模型支持更長的輸入但長輸入下的向量質(zhì)量未必好。我的做法是先用目標embedding模型跑一個切片長度掃描從200到1500每隔100取一個值看檢索指標的變化。通常能找到一兩個峰值選峰值對應(yīng)的長度作為chunk_size。這個掃描過程可能要多跑幾輪但比拍腦袋定參數(shù)靠譜得多。7. 我踩過的三個真實坑與修復過程7.1 坑一切片太碎導致答案拼不完整早期做一個產(chǎn)品手冊問答系統(tǒng)為了追求檢索精度把chunk_size設(shè)成了200。測試時發(fā)現(xiàn)簡單問題回答得挺好但稍微復雜一點的問題答案總是缺一部分。排查后發(fā)現(xiàn)用戶問“如何配置XX功能”相關(guān)說明分散在三個切片里第一個講配置前提第二個講具體步驟第三個講注意事項。檢索時只召回了第二個切片生成模型只看到了步驟沒看到前提和注意事項答案自然不完整。修復方法是把chunk_size調(diào)到600同時增加overlap到100。這樣三個切片被合并成兩個且相鄰切片有重疊檢索時更容易召回完整上下文。調(diào)整后復雜問題的答案完整度明顯提升。7.2 坑二表格被切散導致檢索失效另一個項目處理的是財務(wù)報表文檔里有大量表格。最初用遞歸切分表格被切得七零八落。用戶問“第三季度的營收是多少”檢索召回的切片里只有數(shù)字沒有表頭生成模型根本不知道這個數(shù)字對應(yīng)哪個季度。修復方法是單獨處理表格解析出表格結(jié)構(gòu)后把每個表格作為一個獨立切片并在切片開頭加上表頭。如果表格行數(shù)太多按行分組每組都帶表頭。這樣每個切片都是自解釋的檢索出來直接能用。7.3 坑三多語言文檔切片長度失衡一個中英文混排的技術(shù)文檔按字符數(shù)切分后中文切片平均800字英文切片平均300字。檢索時英文問題召回的中文切片太長噪音多中文問題召回的英文切片太短信息不足。后來改用tokenizer按token數(shù)切分中英文切片長度對齊到相同的token數(shù)問題才解決。這個坑的教訓是切片策略要跟文檔的語言特性匹配。純中文文檔可以按字符數(shù)切純英文文檔可以按單詞數(shù)切混排文檔最好按token數(shù)切。雖然tokenizer會引入額外依賴但為了檢索質(zhì)量這點成本值得花。8. 切片策略的迭代節(jié)奏與評估閉環(huán)切片不是一次調(diào)好就完事的。文檔在更新用戶問題在變化embedding模型也可能升級。我一般會建立一個評估閉環(huán)定期用一批標注好的測試問題跑檢索指標如果指標下降超過閾值就觸發(fā)切片策略的重新評估。評估時不要只看整體指標要分場景看。事實型問題、推理型問題、總結(jié)型問題的指標可能差異很大。如果某類問題指標持續(xù)偏低就針對性地調(diào)整切片參數(shù)。比如事實型問題召回率低就減小chunk_size總結(jié)型問題召回率低就增大chunk_size或增加overlap。另外用戶反饋也是重要信號。如果用戶經(jīng)常抱怨“答案不完整”或“答非所問”大概率是切片出了問題。這時候不要急著調(diào)模型或Prompt先回頭看看切片策略是不是跟當前文檔和問題類型匹配。很多時候把切片調(diào)好比換一個更大的模型效果更明顯。提示切片調(diào)優(yōu)的投入產(chǎn)出比很高?；ò胩鞎r間調(diào)切片可能比花一周時間調(diào)Prompt帶來的提升還大。但這一步太靠前容易被忽略。建議在RAG項目啟動時就把切片策略作為獨立模塊來設(shè)計和評估不要等到效果不好了才回頭補課。 RAG系統(tǒng)切片策略全解析：從固定長度到語義切分
1. 被忽視的切片為什么它才是RAG系統(tǒng)的隱形天花板做RAG檢索增強生成的人十有八九把精力砸在了模型選型、向量庫調(diào)參、Prompt工程上卻對切片Chunking這一步草草了事。我見過太多項目embedding模型用的是頂配向量數(shù)據(jù)庫也是企業(yè)級方案但最終問答效果就是上不去——答案要么缺胳膊少腿要么檢索出一堆無關(guān)內(nèi)容。排查到最后問題往往出在最開始那一步文檔切片沒做好。切片之所以不起眼是因為它太“前處理”了。大家潛意識里覺得把文檔按固定字數(shù)切開扔進向量庫就完事了。但實際情況是切片策略直接決定了檢索系統(tǒng)能“看到”什么粒度的信息。切得太碎語義被割裂檢索出來的片段缺乏上下文生成模型拿到手里也拼不出完整答案切得太粗一個片段里混了好幾個主題向量表示被稀釋檢索精度斷崖式下跌。更麻煩的是這兩種錯誤在系統(tǒng)上線初期往往不會暴露——簡單問題還能應(yīng)付一旦用戶問得稍微具體一點短板立刻現(xiàn)形。這篇文章面向的是正在搭建或優(yōu)化RAG系統(tǒng)的開發(fā)者無論你用的是LangChain、LlamaIndex還是自研管線切片這一步都繞不開。我會從切片的本質(zhì)目標講起拆解幾種主流策略的適用場景和坑點給出可落地的參數(shù)建議最后分享一些我在實際項目中踩過的坑和驗證過的調(diào)優(yōu)手法。讀完你至少能判斷自己手頭的切片方案到底合不合格以及該往哪個方向改。2. 切片的本質(zhì)在語義完整與檢索精度之間找平衡2.1 切片到底在解決什么問題RAG系統(tǒng)的核心鏈路是用戶提問 → 檢索相關(guān)文檔片段 → 把片段塞進上下文 → 生成答案。切片就是這條鏈路的起點它決定了“相關(guān)文檔片段”這個中間產(chǎn)物的質(zhì)量。理想情況下每個切片應(yīng)該是一個語義自洽的單元——它獨立存在時人能看懂它在說什么它被檢索出來時能直接回答或支撐某個具體問題。但現(xiàn)實很骨感。一份文檔的語義結(jié)構(gòu)是樹狀的章包含節(jié)節(jié)包含段段包含句。切片本質(zhì)上是在這棵樹上找一個切割面把連續(xù)文本切成離散塊。切在哪里直接決定了每個塊的語義邊界是否清晰。切在段落之間語義完整度高但塊可能很長切在句子之間塊短了但上下文可能斷裂。這就是切片的核心矛盾語義完整性和檢索精度之間的權(quán)衡。2.2 固定長度切片的致命缺陷最常見的做法是按固定字符數(shù)切比如每500個字符一刀。這種做法實現(xiàn)簡單但問題很致命。假設(shè)一段文本正好在“該方案的優(yōu)勢在于”后面被切斷下一個塊以“成本低、部署快”開頭。檢索時如果用戶問“這個方案有什么優(yōu)勢”第一個塊可能被召回但答案的后半截在第二個塊里生成模型拿到的上下文是殘缺的。更糟糕的是第二個塊單獨看完全不知道在說什么向量表示會非常模糊檢索時容易被漏掉。固定長度切片還有一個隱蔽問題它完全無視文檔的天然結(jié)構(gòu)。技術(shù)文檔有標題、段落、列表、代碼塊法律合同有條款論文有摘要和章節(jié)。這些結(jié)構(gòu)本身就是語義邊界的強信號按固定長度切等于把這些信號全部丟棄。我做過一個對比實驗同一份技術(shù)文檔固定長度切片和按結(jié)構(gòu)切片在相同檢索問題下的召回率差了將近30個百分點。2.3 語義完整性與檢索精度的量化關(guān)系要理解這個權(quán)衡可以看一個簡化模型。假設(shè)文檔總長度為L切片長度為c切片數(shù)量n≈L/c。檢索時系統(tǒng)從n個塊中召回top-k個。每個塊的語義信息量可以粗略認為與c正相關(guān)但塊內(nèi)主題純度與c負相關(guān)——塊越長混入多個主題的概率越大。當c很小時每個塊主題純度高向量表示尖銳檢索精度高但塊內(nèi)信息量不足生成模型可能拿不到完整答案。當c很大時塊內(nèi)信息量足但向量表示被多個主題平均檢索時容易召回“什么都沾一點”的塊精度下降。存在一個最優(yōu)c使得檢索精度和答案完整度的乘積最大。這個最優(yōu)值取決于文檔類型、問題類型和embedding模型的能力沒有萬能數(shù)字。注意不要迷信網(wǎng)上流傳的“最佳切片長度是512 tokens”這類說法。那是在特定數(shù)據(jù)集、特定模型下的經(jīng)驗值換一個場景可能完全不適用。3. 主流切片策略的實戰(zhàn)拆解與選型邏輯3.1 按字符數(shù)硬切什么時候可以用什么時候絕對不能用按字符數(shù)硬切是最簡單的策略代碼幾行就能實現(xiàn)。它的適用場景非常有限文檔結(jié)構(gòu)極其規(guī)整比如每段都是獨立的知識點段與段之間沒有依賴關(guān)系。比如FAQ文檔每個問答對就是天然切片硬切反而不會出大問題。但在絕大多數(shù)場景下硬切都是災難。技術(shù)文檔、研究報告、法律文書、產(chǎn)品手冊這些文檔的語義是跨段落的。一個概念的定義可能在第一段展開在第二段舉例在第三段。硬切會把它們打散檢索時只能召回其中一塊生成模型拿到的信息是碎片化的。如果非要用硬切至少加一個重疊窗口overlap。比如每500字符切一刀但相鄰塊之間重疊100字符。這樣即使切在了句子中間下一個塊也能包含前一個塊的尾部內(nèi)容緩解語義斷裂。重疊比例一般設(shè)在10%到20%之間太小起不到作用太大則冗余嚴重檢索時容易召回大量重復內(nèi)容。def fixed_size_chunk(text, chunk_size500, overlap100): chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) start end - overlap return chunks這段代碼看起來沒問題但實際用的時候要注意如果文檔里有代碼塊或表格硬切可能把代碼從中間截斷導致語法錯誤。表格被切散后行列對應(yīng)關(guān)系丟失檢索出來完全沒法用。所以硬切之前最好先把代碼塊和表格單獨提取出來不要參與常規(guī)切片。3.2 按段落和標題切利用文檔的天然結(jié)構(gòu)大多數(shù)文檔都有天然的結(jié)構(gòu)信號標題、子標題、段落分隔符。按這些信號切能最大程度保持語義完整性。具體做法是先按標題層級把文檔拆成樹狀結(jié)構(gòu)每個葉子節(jié)點最小標題單元下的內(nèi)容作為一個候選切片。如果某個葉子節(jié)點內(nèi)容太長再按段落進一步切分。這種策略的好處是每個切片都有明確的主題歸屬。檢索時如果用戶的問題匹配到某個標題可以直接定位到對應(yīng)切片精度很高。而且切片自帶層級信息可以在檢索時利用標題做過濾或加權(quán)。但要注意標題層級不一定規(guī)整。有些文檔標題層級混亂或者根本沒有標題。這時候可以退而求其次按段落切。段落是作者有意劃分的語義單元按段落切比按字符切合理得多。如果段落本身太長比如超過1000字再考慮按句子切分。import re def paragraph_chunk(text, max_length800): paragraphs re.split(r\n\s*\n, text) chunks [] current for para in paragraphs: if len(current) len(para) max_length: current para \n\n else: if current: chunks.append(current.strip()) current para \n\n if current: chunks.append(current.strip()) return chunks這個實現(xiàn)有個細節(jié)它不是簡單地把每個段落單獨成塊而是盡量把短段落合并到接近max_length。這樣避免產(chǎn)生大量過短的切片影響檢索效率。但合并時要注意不要把不同主題的段落硬湊在一起。一個簡單的判斷方法是看相鄰段落的相似度如果相似度低于閾值就不合并。3.3 遞歸切分LangChain的默認策略到底靠不靠譜LangChain的RecursiveCharacterTextSplitter是很多人用的默認方案。它的邏輯是先嘗試用第一優(yōu)先級分隔符比如雙換行切如果切出來的塊還是太大就用第二優(yōu)先級分隔符比如單換行繼續(xù)切以此類推。分隔符列表通常是[\n\n, \n, 。, , ]從粗到細。這個策略比硬切聰明因為它優(yōu)先在語義邊界處切。但它也有問題分隔符列表是固定的不感知文檔的實際結(jié)構(gòu)。比如一份Markdown文檔標題是用#標記的但分隔符列表里沒有#遞歸切分可能把標題和正文切開導致切片丟失標題信息。另外遞歸切分的終止條件是塊大小小于chunk_size但它不保證塊內(nèi)語義完整。如果文檔里有一段很長的連續(xù)文本沒有任何換行或標點遞歸切分最后會退化成按字符硬切。所以用這個策略時要針對文檔類型定制分隔符列表。比如處理Markdown時把## 、### 加進去處理代碼時把\nclass 、\ndef 加進去。3.4 語義切片用embedding找真正的語義邊界語義切片是更高級的做法先對文本按句子切分然后計算相鄰句子的embedding相似度。如果相似度低于某個閾值說明這里可能是主題轉(zhuǎn)換點就在這里切一刀。這樣切出來的塊內(nèi)部語義一致性高塊與塊之間的邊界也更有意義。具體實現(xiàn)上可以用sentence-transformers計算句子向量然后計算相鄰句子的余弦相似度。閾值一般設(shè)在0.5到0.7之間具體取決于文檔類型。技術(shù)文檔的閾值可以低一點因為技術(shù)概念之間的關(guān)聯(lián)性本身就弱敘事類文檔的閾值可以高一點因為故事線是連貫的。from sentence_transformers import SentenceTransformer import numpy as np model SentenceTransformer(all-MiniLM-L6-v2) def semantic_chunk(sentences, threshold0.6): embeddings model.encode(sentences) chunks [] current_chunk [sentences[0]] for i in range(1, len(sentences)): sim np.dot(embeddings[i-1], embeddings[i]) / ( np.linalg.norm(embeddings[i-1]) * np.linalg.norm(embeddings[i]) ) if sim threshold: chunks.append( .join(current_chunk)) current_chunk [sentences[i]] else: current_chunk.append(sentences[i]) if current_chunk: chunks.append( .join(current_chunk)) return chunks語義切片的缺點是計算成本高。一份長文檔可能有幾千個句子每個句子都要算embedding耗時可能幾十秒甚至幾分鐘。而且閾值不好定需要針對具體文檔調(diào)。我的經(jīng)驗是語義切片適合對精度要求極高的場景比如法律合同檢索、醫(yī)療文獻問答。對于一般的技術(shù)文檔或產(chǎn)品手冊按結(jié)構(gòu)切分已經(jīng)夠用了。3.5 策略選型對照表策略適用場景優(yōu)點缺點推薦參數(shù)固定長度硬切FAQ、短文本集合實現(xiàn)簡單速度快語義斷裂嚴重chunk_size300-500overlap10%-20%按段落/標題切結(jié)構(gòu)清晰的文檔語義完整自帶層級依賴文檔結(jié)構(gòu)質(zhì)量max_length500-1000遞歸切分通用場景平衡了結(jié)構(gòu)和靈活性分隔符需定制chunk_size500-800分隔符按文檔類型調(diào)整語義切片高精度要求場景語義邊界準確計算成本高閾值難調(diào)相似度閾值0.5-0.74. 切片參數(shù)調(diào)優(yōu)從500到1500我踩過的那些坑4.1 chunk_size不是拍腦袋定的很多人設(shè)chunk_size就是拍腦袋看別人用500就跟著用500。但chunk_size應(yīng)該由文檔類型和問題類型共同決定。如果用戶的問題通常很具體比如“XX功能的配置參數(shù)是什么”那切片應(yīng)該小一點讓檢索能精確定位到參數(shù)所在的段落。如果用戶的問題比較宏觀比如“這個系統(tǒng)的架構(gòu)設(shè)計思路”那切片可以大一點包含更多上下文。我一般會先分析用戶問題的平均長度和具體程度。如果問題平均在10個字以內(nèi)且大多是事實型查詢chunk_size設(shè)在300到500之間比較合適。如果問題平均在20字以上且涉及推理或總結(jié)chunk_size可以放到800到1200。另外embedding模型的最大輸入長度也是一個硬約束。比如all-MiniLM-L6-v2最大支持256個token如果chunk_size超過這個數(shù)后面的內(nèi)容會被截斷等于白切。4.2 overlap設(shè)多少才不浪費overlap的作用是防止語義在邊界處丟失但它不是越大越好。overlap太大相鄰切片重復內(nèi)容多檢索時會召回大量相似結(jié)果浪費上下文窗口。overlap太小起不到緩沖作用。我的經(jīng)驗是overlap設(shè)在chunk_size的10%到15%之間比較合理。比如chunk_size500overlap設(shè)50到75。但有一種情況需要加大overlap文檔里有很多跨段落的指代關(guān)系。比如第一段說“該方案有三個優(yōu)勢”第二段分別展開。如果切片正好切在第二段中間第一個切片可能只包含第一個優(yōu)勢第二個切片包含后兩個優(yōu)勢但第二個切片開頭沒有“該方案”的上下文檢索時可能匹配不上。這時候把overlap加大到20%到30%讓第二個切片也包含“該方案有三個優(yōu)勢”這句話就能解決。4.3 切片長度分布比平均值更重要調(diào)參時不要只看平均切片長度要看長度分布。如果大部分切片在500字左右但有幾個切片超過2000字這幾個超長切片就是隱患。它們可能包含多個主題向量表示模糊檢索時要么召不回要么召回了但生成模型被無關(guān)信息干擾。我一般會統(tǒng)計切片長度的百分位數(shù)。如果90分位數(shù)超過平均值的2倍說明切片長度分布不均勻需要調(diào)整切分策略。比如對超長段落做二次切分或者對過短切片做合并。理想情況下切片長度應(yīng)該集中在目標值附近標準差不要太大。4.4 用檢索指標反推切片質(zhì)量切片好不好最終要看檢索效果。我習慣在切片完成后構(gòu)造一批測試問題然后看檢索的召回率和精確率。具體做法是對每個測試問題人工標注哪些切片是相關(guān)的然后看系統(tǒng)召回的top-k里有多少是相關(guān)的。如果召回率低說明切片粒度太粗或語義邊界不清如果精確率低說明切片粒度太細或重疊太多。這個評估過程不需要很復雜幾十個測試問題就能看出趨勢。關(guān)鍵是測試問題要覆蓋不同類型的查詢事實型、推理型、總結(jié)型。如果某類問題的指標明顯偏低就針對性地調(diào)整切片策略。比如事實型問題召回率低就把chunk_size調(diào)小總結(jié)型問題召回率低就把chunk_size調(diào)大或增加overlap。5. 特殊文檔的切片處理代碼、表格、多語言混排5.1 代碼塊切片別把函數(shù)從中間切斷技術(shù)文檔里經(jīng)常夾雜代碼塊。代碼的語義單元是函數(shù)或類從中間切斷會導致語法錯誤檢索出來也沒法用。處理方法是先用正則表達式把代碼塊提取出來單獨作為一個切片或者按函數(shù)/類邊界切分。如果代碼塊太長可以按邏輯塊切比如一個函數(shù)一個切片但要在切片開頭保留函數(shù)簽名和注釋。import re def extract_code_blocks(text): pattern r(\w*)\n(.*?) blocks [] for match in re.finditer(pattern, text, re.DOTALL): lang match.group(1) code match.group(2) blocks.append({lang: lang, code: code, start: match.start(), end: match.end()}) return blocks提取出來后代碼塊不參與常規(guī)文本切片而是單獨建立索引。檢索時如果問題涉及代碼可以優(yōu)先從代碼塊索引中召回。這樣既保證了代碼完整性又不會干擾文本切片的語義純度。5.2 表格切片保留行列對應(yīng)關(guān)系表格被切散是另一個常見問題。一個表格如果被切成兩半前半部分有表頭沒有數(shù)據(jù)后半部分有數(shù)據(jù)沒有表頭檢索出來完全沒法解讀。處理方法是把整個表格作為一個切片如果表格太大按行切分但每個切片都要帶上表頭。具體做法是解析表格結(jié)構(gòu)提取表頭然后按行分組。每組行數(shù)根據(jù)表格寬度和chunk_size決定但每組都必須包含表頭。這樣每個切片都是一個自包含的小表格檢索出來可以直接用。5.3 多語言混排文檔的切片陷阱中英文混排的文檔按字符數(shù)切分會出現(xiàn)嚴重偏差。中文一個字符的信息量遠大于英文一個字符同樣500字符中文可能只有一段話英文可能有好幾段。如果按字符數(shù)統(tǒng)一切中文切片會偏長英文切片會偏短。解決辦法是按token數(shù)切而不是字符數(shù)。用tokenizer把文本轉(zhuǎn)成token序列然后按token數(shù)切分。這樣中英文的信息量就對齊了。大多數(shù)embedding模型都有對應(yīng)的tokenizer直接用就行。如果不想引入tokenizer也可以按語言分別處理中文按字符數(shù)切英文按單詞數(shù)切然后合并。6. 切片之后存儲、索引與檢索的聯(lián)動優(yōu)化6.1 切片元數(shù)據(jù)別只存文本切片存進向量庫時不要只存文本和向量。元數(shù)據(jù)至少應(yīng)該包含來源文檔ID、切片在文檔中的位置起止字符或頁碼、所屬標題層級、切片類型正文/代碼/表格。這些元數(shù)據(jù)在檢索時非常有用。比如可以按標題層級過濾只召回特定章節(jié)的內(nèi)容或者按切片類型加權(quán)代碼類問題優(yōu)先召回代碼切片。元數(shù)據(jù)還有一個用途是溯源。生成模型給出答案后可以展示答案來自哪個文檔的哪個部分方便用戶驗證。這在企業(yè)場景下尤其重要用戶不會盲目相信模型生成的內(nèi)容需要能追溯到原始文檔。6.2 父子切片用小塊檢索用大塊生成這是一個很實用的技巧建索引時用小塊生成時用大塊。具體做法是把文檔切成兩層父塊和子塊。父塊較大比如1000字保證語義完整子塊較小比如200字保證檢索精度。檢索時用子塊匹配問題命中后返回對應(yīng)的父塊給生成模型。這樣既解決了小塊檢索精度高但信息不足的問題又解決了大塊信息足但檢索不準的問題。實現(xiàn)上每個子塊存一個父塊ID檢索到子塊后根據(jù)ID取出父塊。LangChain的ParentDocumentRetriever就是干這個的但自己實現(xiàn)也不復雜。6.3 切片與embedding模型的匹配不同embedding模型對切片長度的敏感度不同。有些模型在短文本上表現(xiàn)好有些在長文本上更穩(wěn)。選切片策略時要結(jié)合embedding模型的特點。比如OpenAI的text-embedding-ada-002對512 token以內(nèi)的文本效果最好超過后性能下降。而有些開源模型支持更長的輸入但長輸入下的向量質(zhì)量未必好。我的做法是先用目標embedding模型跑一個切片長度掃描從200到1500每隔100取一個值看檢索指標的變化。通常能找到一兩個峰值選峰值對應(yīng)的長度作為chunk_size。這個掃描過程可能要多跑幾輪但比拍腦袋定參數(shù)靠譜得多。7. 我踩過的三個真實坑與修復過程7.1 坑一切片太碎導致答案拼不完整早期做一個產(chǎn)品手冊問答系統(tǒng)為了追求檢索精度把chunk_size設(shè)成了200。測試時發(fā)現(xiàn)簡單問題回答得挺好但稍微復雜一點的問題答案總是缺一部分。排查后發(fā)現(xiàn)用戶問“如何配置XX功能”相關(guān)說明分散在三個切片里第一個講配置前提第二個講具體步驟第三個講注意事項。檢索時只召回了第二個切片生成模型只看到了步驟沒看到前提和注意事項答案自然不完整。修復方法是把chunk_size調(diào)到600同時增加overlap到100。這樣三個切片被合并成兩個且相鄰切片有重疊檢索時更容易召回完整上下文。調(diào)整后復雜問題的答案完整度明顯提升。7.2 坑二表格被切散導致檢索失效另一個項目處理的是財務(wù)報表文檔里有大量表格。最初用遞歸切分表格被切得七零八落。用戶問“第三季度的營收是多少”檢索召回的切片里只有數(shù)字沒有表頭生成模型根本不知道這個數(shù)字對應(yīng)哪個季度。修復方法是單獨處理表格解析出表格結(jié)構(gòu)后把每個表格作為一個獨立切片并在切片開頭加上表頭。如果表格行數(shù)太多按行分組每組都帶表頭。這樣每個切片都是自解釋的檢索出來直接能用。7.3 坑三多語言文檔切片長度失衡一個中英文混排的技術(shù)文檔按字符數(shù)切分后中文切片平均800字英文切片平均300字。檢索時英文問題召回的中文切片太長噪音多中文問題召回的英文切片太短信息不足。后來改用tokenizer按token數(shù)切分中英文切片長度對齊到相同的token數(shù)問題才解決。這個坑的教訓是切片策略要跟文檔的語言特性匹配。純中文文檔可以按字符數(shù)切純英文文檔可以按單詞數(shù)切混排文檔最好按token數(shù)切。雖然tokenizer會引入額外依賴但為了檢索質(zhì)量這點成本值得花。8. 切片策略的迭代節(jié)奏與評估閉環(huán)切片不是一次調(diào)好就完事的。文檔在更新用戶問題在變化embedding模型也可能升級。我一般會建立一個評估閉環(huán)定期用一批標注好的測試問題跑檢索指標如果指標下降超過閾值就觸發(fā)切片策略的重新評估。評估時不要只看整體指標要分場景看。事實型問題、推理型問題、總結(jié)型問題的指標可能差異很大。如果某類問題指標持續(xù)偏低就針對性地調(diào)整切片參數(shù)。比如事實型問題召回率低就減小chunk_size總結(jié)型問題召回率低就增大chunk_size或增加overlap。另外用戶反饋也是重要信號。如果用戶經(jīng)常抱怨“答案不完整”或“答非所問”大概率是切片出了問題。這時候不要急著調(diào)模型或Prompt先回頭看看切片策略是不是跟當前文檔和問題類型匹配。很多時候把切片調(diào)好比換一個更大的模型效果更明顯。提示切片調(diào)優(yōu)的投入產(chǎn)出比很高?；ò胩鞎r間調(diào)切片可能比花一周時間調(diào)Prompt帶來的提升還大。但這一步太靠前容易被忽略。建議在RAG項目啟動時就把切片策略作為獨立模塊來設(shè)計和評估不要等到效果不好了才回頭補課。