文件切片是 RAG 表現好壞的第一關，常見三種策略：Fixed Size 最簡單快速、Semantic 語義完整但慢且貴、Hierarchical 適合有章節結構的文件；作者建議第一版用 Fixed Size 500 tokens 加 50 overlap，Hit Rate 低於 70% 再試 Semantic，chunk_size 實務最佳為 300 到 800 tokens，overlap 取 10 到 20%。
發布 2026-05-30 · 最後更新 2026-09-27 · 作者 賴家榮 Andy Lai
文件切片（Chunking）是 RAG 表現好壞的第一關。切錯了，後面 Embedding 再強、Reranker 再準也救不回來。這篇教您三種策略與實作。
為什麼要切片？
- LLM context 有限，不能塞整本書
- 太大的 chunk 會稀釋相關度
- 切片可以保留來源 metadata（章節、頁碼）
策略 1：Fixed Size（固定大小）
最簡單：每 N 個 tokens 切一刀，相鄰 chunk 有 overlap。
from langchain.text_splitter import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=500,
chunk_overlap=50,
separators=["\n\n", "\n", "。", "，", " ", ""]
)
chunks = splitter.split_text(text)
優：簡單、快、可預測
缺：可能在句中切斷、語義不完整
建議參數：500 tokens + 50 overlap（中文）/ 800 + 100（英文）
策略 2：Semantic（語義切片）
用 embedding 偵測語義邊界——當相鄰句子的 embedding 距離大於門檻時切。
from llama_index.core.node_parser import SemanticSplitterNodeParser
splitter = SemanticSplitterNodeParser(
buffer_size=1,
breakpoint_percentile_threshold=95,
embed_model=embed_model
)
nodes = splitter.get_nodes_from_documents(docs)
優：語義完整、效果好
缺：慢、貴（每次切都要算 embedding）
策略 3：Hierarchical（階層式）
多層切：章 → 節 → 段。檢索時可以動態調整粒度。
# 結構化文件（有 H1, H2, H3）
def hierarchical_chunk(doc):
chapters = split_by_heading(doc, 'h1')
for chapter in chapters:
sections = split_by_heading(chapter, 'h2')
for section in sections:
paragraphs = split_by_size(section, 300)
yield {
'text': paragraph,
'metadata': {'chapter': ..., 'section': ...}
}
優：保留結構、利於檢索
缺：實作較複雜，適合有 H1/H2/H3 結構的文件
三種策略對比
| 策略 | 速度 | 品質 | 適合 |
|---|---|---|---|
| Fixed Size | 極快 | 中 | 大量純文字 |
| Semantic | 慢 | 高 | 高品質要求、量不大 |
| Hierarchical | 中 | 高 | 結構化文件（書、報告） |
實務建議
- 第一版用 Fixed Size 500/50，跑起來看效果
- 若 Hit Rate < 70%，試 Semantic
- 若文件本身有結構（章節清楚），用 Hierarchical
- 所有策略都要保留 metadata（來源、頁碼、章節）
中文切片的特殊問題
- 沒有 word boundary，分詞工具不可靠 → 直接用字元數切
- 句號、分號是好的切點
- 表格、清單建議整塊保留
- 標題與內文要連在一起，別切散
chunk_size 怎麼挑？
- 太小（< 200）：缺乏語境
- 太大（> 1500）：稀釋相關度
- 實務最佳：300–800 tokens
chunk_overlap 怎麼挑？
- 0：邊界資訊會丟
- 10–20%：剛好
- 50%+：重複、浪費儲存
常見問題
為什麼 RAG 需要做文件切片？
因為 LLM 的 context 有限，不能塞整本書；太大的 chunk 會稀釋相關度；切片還能保留章節、頁碼等來源 metadata。切片是 RAG 的第一關，切錯了後面的 Embedding 再強、Reranker 再準也救不回來。
Fixed Size、Semantic、Hierarchical 三種切片策略有什麼差別？
Fixed Size 每 N 個 tokens 切一刀並帶 overlap，極快、品質中等，適合大量純文字，缺點是可能在句中切斷。Semantic 用 embedding 偵測語義邊界，品質高但慢且貴，適合量不大的高品質需求。Hierarchical 依章、節、段多層切，速度中等、品質高，適合書籍與報告等結構化文件。
chunk_size 和 chunk_overlap 該設多少？
chunk_size 小於 200 會缺乏語境，大於 1500 會稀釋相關度，實務最佳是 300 到 800 tokens。overlap 設 0 會丟失邊界資訊，50% 以上會重複浪費儲存，10 到 20% 剛好。文章建議中文用 500 tokens 加 50 overlap，英文用 800 加 100。
中文文件切片有什麼特別要注意的？
中文沒有 word boundary，分詞工具不可靠，建議直接用字元數切；句號與分號是好的切點；表格與清單建議整塊保留；標題與內文要連在一起，不要切散。程式碼範例中的 separators 也依序放入換行、句號、逗號作為切點。
第一次做 RAG 該用哪種切片策略？
作者建議第一版用 Fixed Size 500/50 先跑起來看效果；若 Hit Rate 低於 70% 再試 Semantic；若文件本身章節清楚就改用 Hierarchical。不論哪種策略，都要保留來源、頁碼、章節等 metadata。