RAG 文檔切分實戰(zhàn)chunk_size、chunk_overlap、遞歸分塊與語義分塊怎么選RAG 回答不準確不一定是 Embedding 模型或向量庫的問題。很多時候真正的錯誤發(fā)生在入庫之前一條因果關系被從中間切斷標題和正文分開表格被拆成無法理解的碎片。本文從“一個 Chunk 能否獨立回答一個子問題”出發(fā)給出中文文檔可運行代碼、策略選擇、參數(shù)掃描和評估方法。一、切分為什么會決定 RAG 的上限RAG 的檢索單元不是整份文檔而是切分后寫入索引的 Chunk。查詢只能召回已經存在的單元如果答案橫跨兩個互不相鄰的 Chunk后面的向量檢索、重排和大模型都只能設法補救無法恢復從未被一起檢索到的上下文。圖 1硬切分可能讓原因與結果分離適量重疊可以緩解邊界信息丟失。原創(chuàng)教學圖Image2 生成。因此切分要同時滿足三個目標語義完整一個 Chunk 盡量圍繞一個主題或可回答單元檢索可區(qū)分不要塞入太多無關主題避免向量表達被平均成本可控制Chunk 數(shù)量、重復內容、Embedding 次數(shù)和送入 LLM 的 Token 都不能無限增長。調整參數(shù)原始 PDF / Markdown / HTML解析標題、段落、表格與代碼塊按文檔結構劃分語義單元遞歸限制 Chunk 大小并增加重疊寫入來源、標題和位置元數(shù)據向量化并建立索引查詢檢索 Top-K評估 Hit Rate、上下文覆蓋與成本二、固定長度、遞歸分塊、語義分塊有什么區(qū)別圖 2固定長度、遞歸分塊與語義分塊的工作方式和適用場景。原創(chuàng)教學圖Image2 生成。1. 固定長度快但不認識文檔結構每隔固定字符或 Token 切一刀實現(xiàn)簡單、吞吐高適合結構弱的日志、聊天記錄和短文本。缺點是邊界可能落在句子、代碼塊或表格中間。它適合作為基線不適合作為所有知識庫的默認答案。2. 遞歸分塊通用文本的可靠起點遞歸分塊先嘗試用段落分隔符切塊仍過大時再依次嘗試換行、空格、標點最后才退化到字符級。LangChain 當前文檔將RecursiveCharacterTextSplitter作為通用文本的推薦起點默認分隔順序為雙換行、換行、空格和空字符串。圖 3LangChain 官方說明遞歸分塊會盡可能保留段落、句子和單詞。來源https://docs.langchain.com/oss/python/integrations/splitters/recursive_text_splitter3. 語義分塊邊界更自然但成本更高典型語義分塊先把文本切成句子對句子或句子窗口生成向量再計算相鄰位置的語義距離當距離突然升高時把它視為主題切換點。優(yōu)點是邊界更符合內容缺點是需要額外 Embedding、閾值依賴數(shù)據分布并可能生成過大或過小的塊。因此仍要設置最大長度兜底。三、中文遞歸分塊的可運行寫法安裝獨立文本切分包pipinstall-Ulangchain-text-splitters中文沒有穩(wěn)定的空格邊界應把中文句號、問號、感嘆號、分號、逗號等加入分隔符列表并保留最后的空字符串作為兜底。fromlangchain_text_splittersimportRecursiveCharacterTextSplitter separators[, ,。,,,,,、, ,]splitterRecursiveCharacterTextSplitter(separatorsseparators,chunk_size600,chunk_overlap100,length_functionlen,add_start_indexTrue,is_separator_regexFalse,)documentssplitter.create_documents([text])fordocindocuments:print(doc.metadata[start_index],doc.page_content)這里的 600 和 100 按字符數(shù)計算因為length_functionlen。如果 Embedding 模型或生成模型按 Token 限制應使用與模型匹配的 tokenizer 計數(shù)不能把“600 個中文字符”誤認為“600 Token”。另外chunk_overlap是目標重疊量不應假設所有輸出塊都精確重疊同樣長度自然分隔符和章節(jié)邊界會影響實際結果。四、結構優(yōu)先不要把所有文檔先壓成純文本Markdown、HTML、代碼和解析良好的 PDF 本身就有標題、段落、列表、表格、函數(shù)和類。更穩(wěn)健的流程是先按標題、標簽或語法塊切成有意義的結構單元把標題路徑寫進 metadata僅對超長結構單元再次做遞歸分塊表格、代碼塊和圖片說明盡量保持整體。圖 4LangChain 展示先用 Markdown 標題保留 metadata再用遞歸切分器限制長度。來源https://docs.langchain.com/oss/python/integrations/splitters/markdown_header_metadata_splitter需要注意標題切分后overlap 通常只在某個章節(jié)內部再次拆分時出現(xiàn)不會跨越文檔或章節(jié)邊界。跨章節(jié)強行重疊反而可能把兩個主題混在一起。Unstructured 的by_title策略也遵循相同思想遇到 Title 元素就關閉當前 Chunk讓一個 Chunk 不同時包含兩個章節(jié)的正文并可通過參數(shù)合并過小章節(jié)。圖 5Unstructured 官方說明 by_title 會保留章節(jié)邊界。來源https://docs.unstructured.io/open-source/core-functionality/chunking五、chunk_size 和 overlap 該設置多大圖 6塊大小和重疊都存在收益遞減目標是形成可獨立回答子問題的檢索單元。原創(chuàng)教學圖Image2 生成。chunk_size 太小句子間關系容易被拆散同一答案需要召回更多 Chunk索引條目和 metadata 數(shù)量上升但每個 Chunk 主題更集中精確問題可能更容易命中。chunk_size 太大上下文更完整但可能混入多個主題Embedding 向量表達被“平均”查詢與塊的相似度下降Top-K 中攜帶更多無關 Token擠占生成上下文重排成本也會增加。overlap 太小或太大重疊太小會增加邊界丟失過大則會產生大量重復向量檢索結果可能返回同一段內容的多個副本既浪費 Token也降低結果多樣性?？捎糜诘谝惠唽嶒灦侵苯由暇€的字符級起點文檔類型chunk_sizechunk_overlap首選策略中文 FAQ、短知識點300–600 字符10%–15%標題/問答對優(yōu)先技術文檔、教程600–1000 字符10%–20%結構切分 遞歸兜底長報告、論文800–1500 字符10%–15%章節(jié)優(yōu)先必要時試語義分塊源代碼按函數(shù)/類少量或不重疊語法結構切分這些范圍只是建立實驗網格。真正的單位應該由模型 tokenizer、文檔語言和“一個證據片段需要多長”共同決定。有標題/章節(jié)代碼文件沒有明顯結構否是能不能文檔有可靠結構嗎先按標題或 HTML 標簽切分按函數(shù)、類或語法塊切分使用遞歸字符分塊對超長章節(jié)再次遞歸分塊主題切換頻繁且質量要求很高掃描 chunk_size 與 overlap能接受額外嵌入成本嗎試驗語義分塊并設置最大長度用真實問答集評估六、怎樣評估而不是憑感覺看幾個例子準備一組真實問題并為每個問題標出能回答它的原文位置。對多組參數(shù)批量測試至少記錄檢索命中率 Hit RateKTop-K 中是否出現(xiàn)包含答案證據的 Chunk上下文覆蓋率證據是否完整是否缺少限定條件、主語或因果鏈上下文精度召回內容中無關部分的比例答案正確性與忠實度LLM 是否依據檢索證據作答成本指標Chunk 總數(shù)、重復率、Embedding Token、查詢 Token、P95 延遲。實驗時一次只改變一個維度。例如先固定策略掃描chunk_size400/600/800/1000找到合理區(qū)間后再掃描 10%、15%、20% 的 overlap。否則無法判斷提升來自哪里。七、六個高頻錯誤所有文件先轉成純文本標題、表格和代碼結構全部丟失。把字符數(shù)當 Token 數(shù)不同語言和 tokenizer 的比例并不固定。overlap 越大越好重復結果會占滿 Top-K。只評估最終回答無法區(qū)分切分、檢索、重排還是生成環(huán)節(jié)出錯。語義分塊不設最大長度主題長期不變時可能生成超大 Chunk。更改切分后不重建索引Chunk 內容和標識已改變必須重新向量化并寫入索引?？偨YRAG 切分沒有萬能數(shù)字但有可靠順序保留文檔結構與 metadata通用文本從遞歸分塊開始用自然標點適配中文掃描 chunk_size 與 overlap而不是憑經驗拍一個值只有主題邊界復雜且收益能覆蓋成本時再試語義分塊用真實問答集同時評估命中、上下文質量和成本。最終標準不是“每塊有多少字”而是召回任意一個 Chunk 時它能否攜帶足夠、聚焦且可追溯的證據獨立回答一個子問題。