什麼是 chunking 切塊?決定 RAG 檢索品質的第一個關鍵選擇

Chunking 切塊,是指在建立 RAG 檢索系統前,把長文件切成一段一段可被檢索的小片段的過程。這些片段會各自被轉成向量、存進資料庫,使用者提問時,系統再從中撈出最相關的幾段餵給大型語言模型作答。一句話說:chunking 決定了模型「能看到什麼」,而模型只能根據它看到的東西回答。

這也是為什麼我們常對客戶說,RAG 做不好,八成問題不在模型,而在切塊。

什麼是 chunking 切塊?為什麼它是第一個關鍵選擇

想像你有一份三十頁的供應合約,要拿它來做一個「合約問答」的內部工具。你不可能每次提問都把整份三十頁塞給模型,一來塞不下,二來就算塞得下,雜訊太多,模型反而抓不到重點。所以你得先把它切開。

問題是,怎麼切?這一步沒有標準答案,而不同的切法,會讓同一個問題得到完全不同的答案。

我用一份真實合約的段落來示範。假設合約裡有這麼一段:

第 8 條 付款條件。買方應於驗收完成後三十日內付清全額。逾期未付者,每日按未付金額萬分之五計算違約金。第 9 條 保固。賣方保固期為交貨後十二個月⋯⋯

現在使用者問:「逾期付款的違約金怎麼算?」

同一份合約,三種切法,三種答案

切法一:固定長度硬切。 很多人上手 RAG 的第一版就是這樣做的——不管語意,每 200 個字切一刀。結果「每日按未付金額萬分之五計算違約金」這句話,剛好被切在「每日按未付金額」和「萬分之五計算違約金」中間,拆成兩塊。檢索時系統撈到前半塊,模型看到「每日按未付金額」卻不知道比例是多少,只能回你一句模稜兩可的話,或者更糟,自己編一個數字。這就是我們最怕的 hallucination,而根源不是模型笨,是切塊把答案切斷了。

切法二:按語意邊界切。 改成沿著條號、句號這些自然邊界切,讓「第 8 條 付款條件」整條保持完整。這次系統撈到完整的付款條款,模型能正確回答「每日萬分之五」。品質立刻上一個檔次。這也是為什麼實務上我們幾乎都從語意切塊(semantic chunking)起步,而不是固定長度。

切法三:重疊切塊加保留上下文。 但語意切塊也有陷阱。如果使用者問的是「第 9 條的保固和第 8 條的付款有沒有先後關係」,而你把每一條切成獨立一塊、彼此不重疊,模型就看不到兩條之間的關聯。這時我們會加入 overlap(相鄰片段留一小段重疊),並在每個片段前面補上「來自合約 X、第 8 條」這類 metadata。切片變得知道自己「從哪來、旁邊是誰」,跨條款的問題才答得準。

把這三種切法整理成一張表,差異一目了然:

沒有「最好」的切法,只有「最適合這份資料」的切法

看完上面你可能想問:那我全部都用切法三不就好了?不是這麼簡單。重疊會讓片段數量膨脹,向量儲存和檢索成本跟著上升;切太細,單一片段資訊量不足;切太粗,又把雜訊一起塞進模型的視窗。切塊大小、重疊比例、要不要保留表格與標題結構,每一項都是取捨,而正確答案取決於你的文件長什麼樣、使用者會問什麼。

合約和產品規格書該切的方式不一樣。醫療衛教文章和製造 SOP 又是兩回事。這是為什麼「先看資料再決定切法」永遠比「套一個網路上抄來的參數」可靠。

我們踩過的雷是:曾經有個案子,團隊把切塊參數當成一次性設定,上線後就再也沒回頭看。三個月後使用者抱怨答案越來越不準,一查才發現,新進的文件格式變了——多了大量表格,而原本的切法會把表格拆得七零八落。切塊不是一勞永逸的設定,而是要跟著資料一起維運的東西。

在 Tenten,我們把切塊當成 RAG 專案的第一個工程決策來認真對待:先用客戶真實文件跑一輪切塊實驗,拿實際問題去驗檢索命中率,再決定策略,而不是先接模型、出了問題才回頭補救。Demo 那天答得漂亮不算數,上線三個月後還答得準,才算數。