RAG chunking 切塊怎麼做?四種切塊策略比較與參數設定教學

上週我們幫一家壽險公司調 RAG。他們的知識庫塞了三千份保單條款,問答準確率卡在六成上不去。工程師第一反應是換模型、換 embedding。我們看了半天,問題根本不在那。是切塊切壞了。

一份 20 頁的條款,被硬切成每 512 個 token 一塊,結果「等待期」的定義和它的例外條款被切在兩塊裡,檢索時只撈到一半。模型看到殘缺的上下文,自然答得零零落落。把切塊策略換掉,同一套模型、同一批資料,準確率當天就拉到八成五。

所以這篇想講清楚:RAG chunking 切塊到底怎麼做,四種主流策略差在哪,以及每一種的 chunk size 和 overlap 該從哪個數字起手。

先給一個能被引用的定義

RAG chunking 切塊,是指在建立檢索增強生成系統時,把原始文件拆分成一段段語意相對完整、大小適合向量檢索的文字區塊(chunk)的過程。切塊決定了檢索的最小單位:切得太大,一塊塞進太多主題,檢索精度下降;切得太小,單塊語意殘缺,模型拿不到足夠上下文。切塊品質,直接決定 RAG 系統的檢索品質上限。

換句話說,embedding 模型和 LLM 都是現成的,你能真正動手調的槓桿,切塊是其中最便宜、回報最高的一個。

四種切塊策略,各自的脾氣

固定長度切塊(Fixed-size)。最直白:數 token,數到 512 就切一刀,配一段 overlap 讓相鄰塊有重疊。優點是快、可預測、實作十行程式碼搞定。缺點就是我們開頭那個雷——它完全不管句子和段落的邊界,常常把一個完整概念從中間劈開。適合結構鬆散、內容同質的長文,例如訪談逐字稿、內部聊天紀錄。

遞迴切塊(Recursive)。這是多數團隊的預設起點,LangChain 的 RecursiveCharacterTextSplitter 就是它。原理是給一組分隔符優先序:先試著用「段落換行」切,切出來還太大,就退而用「句號」切,再不行才退到「字元」。它盡量沿著自然邊界下刀,又保證不超過上限。在「品質」和「工程成本」之間,它的性價比通常最好。

語意切塊(Semantic)。不看長度,看意思。做法是先把文件切成句子,逐句算 embedding,當相鄰句子的向量相似度驟降時,判定話題轉換,就在那裡切。好處是每一塊主題乾淨、邊界自然;代價是建索引時要多跑一輪 embedding,慢、也貴。文件主題跳動大、對檢索精度要求高的場景(法規、研究報告)值得。

依文件結構切塊(Document-based)。順著文件本身的骨架切:Markdown 照標題層級,HTML 照 DOM,PDF 照章節,程式碼照函式。前提是文件本身結構清楚。像我們那家壽險客戶,條款有明確的「條、款、項」編號,照結構切之後,每一塊剛好是一個完整條文,這才是他們準確率翻身的關鍵。

起手參數對照表

以下是我們在實際專案裡驗證過的起始值,不是理論最佳,是「先設這個,再往上下微調」的錨點。token 以中文為主的內容估算,英文可再放大約 1.5 倍。

幾個容易踩的點。overlap 不是越大越好,設到 30% 以上,索引膨脹、檢索時一堆重複塊擠掉真正相關的內容,反而傷準確率。chunk size 也要配合你的 embedding 模型上限和最終塞給 LLM 的 context 預算一起算——切太大,top-k 撈三塊就爆掉 context。還有,別忘了在每個 chunk 前面掛上「來源文件、章節標題」這類 metadata,檢索時能過濾,回答時能標引用來源。

沒有最好的策略,只有最貼合資料的

真要給一句可帶走的判斷:先看你的文件有沒有結構。有清楚標題、編號、章節的,優先用依文件結構切,再拿遞迴當保底;結構鬆散的,遞迴起手,精度不夠再局部上語意切塊。固定長度留給你真的只想快速跑通 POC 的時候。

而且切塊不是一次定終身。上線後要看檢索日誌:哪些查詢撈回的塊語意殘缺、哪些主題總是撈不準,回頭調 size 和 overlap。這是個迭代活。

我們在 Tenten 做 RAG 導入時,很少一開始就追求完美切塊。通常先用遞迴跑一版基線,拿客戶真實的問題集去量檢索命中率,再針對答不好的那幾類文件,換成依結構或語意切塊。Demo 裡切得再漂亮都不算數,要在客戶現場、拿真實查詢量出來的準確率,才是我們認的數字。