RAG 切分策略:7 種方法依檢索數據排名 (2026)

RAG 切分策略:7 種方法依檢索數據排名 (2026)

RAG 切分策略,在任何一次查詢執行之前,就決定了檢索器能找到什麼。Chroma 在 2024 年 7 月的研究中,用 text-embedding-3-large 對五個語料庫執行了 472 則查詢,結果顯示:你選的分割器會讓召回率相差約五個百分點。單純的 token 分割器是 86.7%,GPT-4o 分割器是 91.7%,每次查詢檢索 5 個區塊。精確率的波動更大,整份報告中從 1.5% 到 8.0% 都有。這讓 chunk 大小的選擇,本質上是一個披著品質外衣的成本決策。然而每篇登上首頁的教學都列出同樣七種方法,卻沒有一篇告訴你哪一種檢索效果更好。

重點整理

• 切分會在嵌入前把文件拆開,切分點決定了檢索器找得到什麼、找不到什麼。
• 在 Chroma 2024 年 7 月、472 則查詢的研究中,各分割器的召回率介於 86.7% 到 91.7%。
• 精確率的波動是召回率的好幾倍,所以 chunk 大小主要是一個 token 成本決策。
• 從 512 token、10% 重疊開始,再用自己的評估集調整。

該用哪一種 RAG 切分策略?(排名)

對多數以連貫散文為主的團隊來說,遞迴字元切分設成 512 token、10% 重疊,就是正確的預設值。它會尊重段落與句子邊界,不花額外成本,而且在 Chroma 的 472 則查詢基準測試中,召回率只比 LLM 分割器低 3.2 個百分點。只有當你的文件具有很強的結構,或你的評估集給出相反證據時,才考慮換掉它。

我們的看法:從遞迴字元切分開始。在 Chroma 的數據中,它的召回率只輸給 cluster 和 LLM 分割器,而 LLM 分割器 3.9% 的精確率,代表每個相關 token,你要餵給生成器大約兩倍的雜訊。多數團隊沒有切分問題,他們有的是一個從來沒量測過的 chunk 大小問題。

數據到底怎麼說 chunk 大小?

唯一一份公開、針對 RAG 切分策略 做的對照比較,是 Chroma 的技術報告「Evaluating Chunking Strategies for Retrieval」(Brandon Smith 與 Anton Troynikov,2024 年 7 月 3 日發表)。他們對 5 個語料庫(328,208 個 token)執行了 472 則查詢,全部用 OpenAI text-embedding-3-large 嵌入,每次查詢檢索 5 個區塊。下表各列來自該報告附錄中,所有語料庫在 text-embedding-3-large、檢索 5 個區塊條件下的表格,因此彼此可以直接比較:

Chroma 的主要結果表(採用不同的檢索設定)把 cluster 分割器的最佳精確率列為 8.0%、召回率 87.3%,並把所有分割器的精確率範圍拉開到 1.5%(KamradtSemanticChunker)到 8.0%。來源:Chroma Research, Evaluating Chunking Strategies

Anthropic 的「Introducing Contextual Retrieval」(2024 年 9 月 19 日發表)從另一個角度切入這個問題。他們的 top-20 檢索失敗率基準是 5.7%。單用情境嵌入降到 3.7%(減少 35%),再疊上情境 BM25 降到 2.9%(49%),加上重新排序後壓到 1.9%(67%)。Anthropic 沒有公開使用的確切 chunk 大小或重疊,所以請把這些當成方法層級的證據,而不是大小層級。來源:Anthropic, Contextual Retrieval。

我們的看法:從這些數字可以推出三個結論。第一,分割器的選擇確實能換來召回率,Chroma 也講得很明白:某些策略的召回率比其他高出最多 9%。在它的主要結果表中,召回率從 83.6%(KamradtSemanticChunker)到 91.9%(LLMSemanticChunker),而在上面檢索 5 個區塊的幾列中,也仍有 86.7% 到 91.7% 的差距。精確率在同一份數據上變動更大:1.5% 到 8.0%,是 5.3 倍的差距,相對之下召回率只有 1.1 倍。所以召回率是你多拿幾個百分點的地方,而精確率和 token 成本才是這個選擇真正影響你的地方。第二,LLM 分割器用最低的精確率換來最高的召回率:你要為每份文件付一次 LLM 呼叫的代價,還要餵給生成器更多雜訊。第三,Anthropic 的數字顯示,為區塊補充脈絡(5.7% 降到 3.7%)對失敗率的改善,比 Chroma 表中任何一種分割器選擇都大。先豐富區塊內容,再去重新調整分割器。重新排序能救回被分割器切壞的區塊,而混合式搜尋把 BM25 和向量檢索結合起來,理由相同。

誠實的局限:兩項研究都只用單一嵌入模型、僅英文語料庫,而且都不是針對你的語料庫做的對照測試。在 472 則查詢中,檢索 5 個區塊時,最好與最差分割器的召回率差距約 5 個百分點,精確率的差距按比例則大得多。

為什麼 chunk 大小決定檢索品質?

Chunk 大小設定了檢索鍵的粒度。400 token 的區塊產生聚焦的嵌入,能比對到特定查詢;4,000 token 的區塊則把許多主題平均掉,結果什麼都比對不準。小区塊能檢索到確切的段落,但可能把一個答案拆散在多個結果裡。大區塊把脈絡保留在一起,卻削弱了嵌入訊號。

嵌入模型的上下文上限也很重要。如果你的模型上限是 512 個輸入 token,你卻餵給它 800 個,結尾會被悄悄截斷。你的嵌入只代表了區塊的三分之二,而且不會有任何錯誤記錄。

再看生成器那一端。Liu 等人在 「Lost in the Middle」(arXiv 2307.03172,2023)中證明,當相關文件落在長上下文的中段時,LLM 的準確率會下降超過 20%。檢索五個 1,000 token 的區塊,就是往提示詞裡倒進 5,000 個 token,而你需要的那個答案,可能正好落在模型讀得最差的位置。較小的區塊能讓相關段落更接近模型擅長處理的位置。

把它想成圖書館的索引卡。一張寫著「4.2 節,第 3 段:退款政策」的卡片,能帶你找到那一頁。一張寫著「關於 20 世紀商業的一切」的卡片,只能帶你找到那棟建築。你的嵌入就是那張卡片。從頭到尾打造一個 RAG 應用,看看切分在整個流程中的位置;再讀我們的情境工程指南,了解檢索到的區塊如何變成提示詞 token。Pinecone 的切分指南則從向量資料庫的角度,說明了同一個取捨。

固定大小與遞迴切分(從這裡開始)

固定大小是你衡量一切的基準,遞迴則是你實際上線會用的方法。

固定大小 token 切分

無論內容為何,每 N 個 token 切一次。

def fixed_size_chunks(text: str, size: int = 512, overlap: int = 50) -> list[str]:
    tokens = text.split()  # whitespace proxy; use tiktoken for real token counts
    chunks = []
    step = size - overlap
    for i in range(0, len(tokens), step):
        chunk = " ".join(tokens[i : i + size])
        chunks.append(chunk)
        if i + size >= len(tokens):
            break
    return chunks

適合:沒有標題結構的連貫散文、快速原型,以及任何基準比較。它並不蠢,它就是對照組。

遞迴字元切分

LangChain 的 RecursiveCharacterTextSplitter 依分隔符號層級切分:先 \n\n(段落),再 \n(行),接著 . (句子),最後 (字詞)。每個區塊都維持在 chunk_size 以下,同時尊重能容納的最大自然邊界。

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    separators=["\n\n", "\n", ". ", " ", ""],
    length_function=len,  # swap for tiktoken len for true token counts
)
chunks = splitter.split_text(document)

那份分隔符號清單,正是每個競爭對手都省略的部分。分割器會先試 \n\n,只有當某個段落超過 chunk_size 時,才退到 . 。如果你的 Markdown 有標題,就在 "\n\n" 之前加上 "## ",這樣章節才能保持完整。

Chunk 重疊的計算: 在 512 token、50 token 重疊下,步長是 462。一份 10,000 token 的文件會產生 ceil(10000 / 462) = 22 個區塊。嵌入的總 token 數:22 x 512 = 11,264,也就是說,你把語料庫的約 12.6% 作為重疊重複嵌入了一遍。這就是讓邊界句子不成為孤兒所需的儲存與 API 成本。

語義切分怎麼運作,值得那個成本嗎?

語義切分會嵌入每一個句子,測量相鄰句子嵌入之間的餘弦距離,並在該距離超過某個百分位閾值(常見是第 95 百分位)的地方切分。區塊在主題轉換處斷開,而不是在任意的 token 數。Greg Kamradt 的 「5 Levels of Text Splitting」 notebook 首創了這種百分位斷點法,Chroma 的研究也直接以他的分割器指名做基準測試。

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
splitter = SemanticChunker(
    embeddings,
    breakpoint_threshold_type="percentile",
    breakpoint_threshold_amount=95,
)
chunks = splitter.split_text(document)

成本計算是沒有人會先講清楚的部分。語義切分會把語料庫嵌入兩次:一次用來計算句子距離、找出斷點,一次用來嵌入產生的區塊以供索引。以 OpenAI text-embedding-3-large 每 100 萬 token 0.13 美元的價格,一個 1,000 萬 token 的語料庫,正常索引花 1.30 美元,用語義切分則是 2.60 美元。在一次查詢都還沒跑之前,你就已經付了兩倍。

那換來什麼?在 Chroma 檢索 5 個區塊的幾列中,cluster 語義分割器達到 89.0% 召回率、6.7% 精確率,而遞迴在同樣 200 token 大小下是 88.5% 與 7.0%。在主要結果表中,同一個分割器繳出全研究最佳的精確率 8.0%,召回率 87.3%。召回率左右只差半個百分點,精確率的結果還會隨著你讀的檢索設定而翻轉,嵌入帳單卻是兩倍。我們的結論:語義切分在主題多樣的語料庫(新聞檔案、論文集)上值得,因為固定邊界經常在主題中段切斷。對同質性高的語料庫(產品文件、單一知識庫),遞迴能用一半成本拿到 95% 的品質。如果你用 Ollama 在本機跑嵌入模型,兩倍嵌入的成本就降為運算時間。

文件感知切分:Markdown、HTML 與程式碼

結構感知切分使用文件本身的邊界(標題、清單項目、函式定義),而不是字元數。Markdown 的 H2 是一個人類刻意放置的語義邊界,字元分割器會把它切碎。

from langchain_text_splitters import MarkdownHeaderTextSplitter

headers = [("#", "h1"), ("##", "h2"), ("###", "h3")]
splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers)
splits = splitter.split_text(markdown_doc)
# Each split carries metadata: {"h1": "...", "h2": "...", "h3": "..."}

對程式碼來說,邊界是 AST 節點。LlamaIndex 的 NodeParsers 提供語言感知的分割器,會在函式與類別定義處斷開。關鍵細節:把 import 區塊和外層類別簽名,附在每個函式區塊上。沒有 import 的函式本體是無法嵌入的雜訊,所以把兩者都加在每個區塊前面,嵌入才能同時掌握函式做什麼,以及它依賴什麼。

特別針對程式碼 RAG:AST 邊界切分、import 前置、每個函式 256-512 token、零重疊。

那後置、階層式與代理式切分呢?

這些就是「RAG 2.0」討論背後那些進階的 RAG 切分策略,三者在搜尋結果中的覆蓋度都只有 1/10。

後置切分

後置切分由 Günther 等人在 「Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models」(arXiv 2409.04701,2024 年 9 月)提出。它先用長上下文模型嵌入整份文件,再把 token 層級的嵌入池化成區塊向量,因此每個區塊都帶有全文脈絡,「它每月 40 美元」也知道「它」指的是什麼。摘要聲稱在各項任務上檢索效果更佳,但沒有公開任何我們能驗證的標題數字。Weaviate 的文章解釋了運作機制,同樣也沒有做對照比較。證據狀態:有潛力,但未量化。

階層式(父子)切分

用小区塊(256 token)建索引供檢索,把父區塊(1,024 token)回傳給生成器。檢索器找到那根針,生成器拿到周圍的整捆稻草。你要維護兩個索引層級和一份父子對應關係。沒有公開的基準測試能孤立出這個效果。

LLM 型 / 代理式切分

Chroma 研究中的 LLMSemanticChunker 用 GPT-4o 為每份文件決定切分點:召回率 91.7%(最高)、精確率 3.9%(最低)。你在索引時要為每份文件付一次 LLM 呼叫(一個 10,000 份文件的語料庫約 100 美元),還要餵給生成器更多雜訊。把它留給真正不規則的語料庫:法律文件、沒有可擷取標題的掃描 PDF。

哪個 chunk 大小適合你的嵌入模型?

嵌入模型的最大輸入 token 數是截斷上限,不是建議值。一個接受 8,192 個 token 的模型,在 8,192 時的嵌入效果並不會比 512 時好。早在觸及上限之前,品質就會隨稀釋而退化:模型把意義平均到更多 token 上,向量便朝語料庫的中心漂移。下表的建議欄是 Techsy 的解讀,不是廠商的指引。

來源:OpenAI embeddings guide、Cohere embed docs、Voyage embeddings docs、BGE model card。

這個規律是:有硬性 512 token 上限的模型(Cohere v3、BGE)要求區塊遠低於 512,因為截斷是無聲的。餵給它 600 個 token,最後 88 個就從嵌入中消失,不會有任何錯誤記錄。上限很高的模型(OpenAI、Voyage、Cohere v4)能容忍較大的區塊,但不會因此獎勵你。模型的最大輸入長度是截斷限制,不是建議值。

把這個和我們的最適合 RAG 的嵌入模型評比、MTEB 分數到底在量什麼,以及 Voyage、OpenAI 與 Cohere 嵌入的並排比較一起看,再決定要用哪個模型。

非英文文件該怎麼切分?

Tokenizer 並不是語言中立的。Petrov 等人在 「Language Model Tokenizers Introduce Unfairness Between Languages」(arXiv 2305.15425,2023)中證明,同一句話翻譯成不同語言後,token 化的長度差異最多可達 15 倍。即使是字元層級和位元組層級的模型,某些語言對之間也有超過 4 倍的差異。一個 512 token 的區塊,在土耳其文、阿拉伯文或日文裡能裝的意義,遠比英文少。

下面是同一句話用 tiktoken 的 cl100k_base 編碼(GPT-4 的 tokenizer)切分的結果:

import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
en = "The retrieval system returns relevant documents."
tr = "Erişim sistemi ilgili belgeleri döndürür."
ja = "検索システムは関連文書を返します。"
print(len(enc.encode(en)), len(enc.encode(tr)), len(enc.encode(ja)))
# 7 tokens, 19 tokens, 19 tokens: same meaning, 2.7x token spread

數據以 tiktoken cl100k_base 於 2026 年 7 月 30 日產生。

實務建議:在固定 512 token 的 chunk 大小下,你的土耳其文和日文區塊能裝的意義,大約只有英文區塊的 37%,阿拉伯文區塊約 26%。請依語言改用字元數或句子數來切分,或按比例提高 token 預算(土耳其文約 1,400,阿拉伯文約 2,000)。中日韓語言沒有空白字詞邊界,所以字元分割器的表現會不同。阿拉伯文的詞形變化會把多個語法標記塞進單一 token,進一步膨脹 token 數。

挑選切分策略的決策樹

你的文件是哪一種?
├── 結構化(Markdown / HTML / 程式碼)
│   └── 依標題或 AST 邊界做文件感知切分
│       ├── 說明文件站 → MarkdownHeaderTextSplitter,512 token,0 重疊
│       └── 程式碼庫 → AST/函式分割器,256-512 token,import 前置
├── 連貫散文(文章、報告、書籍)
│   └── RecursiveCharacterTextSplitter,512 token,50 重疊
│       └── 主題多樣? → 試試第 95 百分位的 SemanticChunker
├── 對話紀錄(聊天、客服工單)
│   └── 依對話輪次邊界切分,每區塊 3-5 個輪次,256 token
└── 混合語料庫
    └── 依 MIME 類型分流 → 套用上述各類型策略
        └── 然後:預期答案有多長?
            ├── 短(1-2 句) → 子區塊 256,無父區塊
            └── 長(多段落) → 階層式:子區塊 256,父區塊 1,024

三個快速的處方。文件聊天機器人:MarkdownHeaderTextSplitter 設 512 token、零重疊,標題路徑放進中繼資料。程式碼搜尋助手:AST 邊界切分,每個函式 256-512 token,import 前置。混合的企業語料庫:在擷取時依文件類型分流,儲存到你用來放區塊的向量資料庫,並帶上類型中繼資料,日後好依類型調整。這種依文件分流,就是 RAG 應用中自適應切分的全部。

工具:LangChain vs LlamaIndex vs Chonkie

我們不賣其中任何一個。這個關鍵字排名前三的網頁,都是帶有產品 CTA 的廠商部落格。

來源:LangChain docs、LlamaIndex NodeParsers、Chonkie docs。

三者實作的核心演算法相同,所以就依你的流程已經在用什麼來選。若要了解分割器以外的更廣泛 RAG 工具鏈,以及儲存用的 Qdrant、Chroma 與 pgvector 比較,請看我們的系列指南。

Techsy 怎麼做切分

在客戶的 RAG 建置中,Techsy 團隊從 512 token、10% 重疊開始,而且在我們用客戶真實客服工單建好一個 20-50 題的評估集之前,絕不碰分割器。評估集優先,然後我們一次只改一個變數:大小、重疊、策略。沒有在同一組問題上的前後數字,就不換分割器。預約免費諮詢,讓第二雙眼睛為你的檢索流程把關。

關於作者

Mert Batur 是 Techsy.io 的共同創辦人,團隊為 B2B 客戶打造 AI 代理、自動化系統,以及語音/SDR 流程。他撰寫 Techsy 團隊在生產環境中實際使用的 LLM 工具鏈,包括客戶知識庫建置背後的 RAG 與檢索工作。在 LinkedIn 上聯繫他。

常見問題

RAG 中的切分是什麼?

切分是在嵌入前,把文件拆成較小片段的預處理步驟,好讓檢索器能針對聚焦的段落比對查詢,而不是比對整份檔案。切分點決定了你的系統在查詢時找得到什麼、找不到什麼。

最適合 RAG 的切分策略是什麼?

對多數處理一般文件的生產系統來說,512 token、10% 重疊的遞迴字元切分是最強的預設值。在 Chroma 的 472 則查詢研究(2024 年 7 月)中,它的召回率為 88.5%,與最昂貴的 LLM 型方法只差 3.2 個百分點,而且不需額外成本。

RAG 的最佳 chunk 大小是多少?

從 512 token 開始。如果你的嵌入模型上限是 512 個輸入 token(Cohere v3、BGE),或你的查詢預期單句答案,就降到 256。只有當你的評估集顯示多段落答案被切碎時,才升到 1,024。永遠用你自己的問題來量測。

chunk 重疊該用多少?

chunk 大小的 10-20%(512 時為 50-100 token)。重疊能避免邊界句子成為孤兒:一個橫跨兩個區塊的事實,至少會在其中一個區塊中完整出現。超過 20%,你就為了遞減的報酬而重複嵌入太多語料庫。多數團隊落在 10%,之後再也不去動它。

語義切分比固定大小切分好嗎?

只好一點點,而且嵌入成本是兩倍。Chroma 2024 年 7 月的基準測試顯示,cluster 語義分割器是 89.0% 召回率、6.7% 精確率,而遞迴在同樣 token 大小下是 88.5% 召回率、7.0% 精確率,其 8.0% 的最佳精確率則來自不同的檢索設定。對主題多樣的語料庫值得,對同質性高的文件集則難以正當化。

chunk 大小要看嵌入模型嗎?

要。輸入上限 512 token 的模型(BGE、Cohere v3)要求區塊遠低於 512,因為截斷是無聲的。上限 8,192 以上的模型能容忍較大區塊,但不會獎勵你;嵌入品質會在觸及上限之前,就隨稀釋而退化。各模型的起始點請見上方的對照表。

程式碼在 RAG 系統中該怎麼切分?

依 AST 邊界(函式與類別定義)切分,而不是依 token 數。每個區塊維持在每函式 256-512 token,把檔案的 import 區塊和外層類別簽名前置,並使用零重疊,因為函式是自足單元。LlamaIndex 的 CodeSplitter 和 LangChain 的語言感知分割器都能處理。

什麼是後置切分?

後置切分先用長上下文模型嵌入整份文件,再把 token 層級的嵌入池化成區塊向量。每個區塊嵌入都帶有全文脈絡,解決了「『它』指的是什麼?」這個問題。由 Günther 等人提出(arXiv 2409.04701,2024 年 9 月)。目前還沒有公開的對照基準測試量化出它的增益。

英文以外的語言該怎麼切分文件?

Token 數不是語言中立的。同一句話在土耳其文和日文中的 token 數是英文的 2.7 倍,阿拉伯文是 3.9 倍(tiktoken cl100k_base)。固定 512 token 的預算,會無聲地讓非英文區塊裝進較少的意義。請依語言改用字元數或句子數來切分,或按比例提高預算。

我怎麼知道切分到底有沒有用?

在碰分割器之前,先用真實使用者查詢建一個 20-50 題的評估集。對你目前的區塊計算 hit@5 和 MRR。改一個變數(大小、重疊、策略),重跑,比較。沒有評估集,你只是在憑感覺調整。二十個問題就足以開始。

結論

• 從 512 token、10% 重疊的遞迴字元切分開始。這是連貫散文的正確預設值。
• 在有人量測過的四個分割器家族中,Chroma 的 472 則查詢讓召回率移動約 5 個百分點,精確率則移動好幾倍。先針對精確率與成本調整。
• 讓 chunk 大小符合嵌入模型的輸入上限。上限 512 token 的模型,要求區塊低於 512。
• 先為區塊補充脈絡(Anthropic 的失敗率從 5.7% 降到 3.7%),再去重新調整分割器。
• 先建評估集。任何沒有前後數字的分割器決策,都是猜測。

若要了解圍繞切分選擇的完整流程,請看從頭到尾打造一個 RAG 應用。還在檢索和微調之間猶豫?RAG 或微調拆解了各自何時勝出。