分塊處理 是什麼？
Chunking：分塊處理 的完整解釋
分塊處理是指將大型資料集或文本分割成更小、更易於管理的部分，以便於模型處理和分析，提升效率。
容易混淆
分塊處理 vs 斷詞 分塊處理是把長內容切段，斷詞是把文字切成 token 或詞。
分塊處理 vs 批次處理 分塊處理是在內容上切段，批次處理是在計算流程上分批送入。
分塊處理 vs 完整輸入 完整輸入一次吃完，分塊處理則是拆開後逐段處理。
記住這句就好
先看它要解決的是什麼問題，再看它是不是最合適的方法。
實際案例
案例 1：長 PDF 摘要 把文件切成可讀的小段，模型才有機會逐段理解。
案例 2：RAG 檢索 切塊後每塊更容易被檢索命中，也比較好放進上下文。
深入了解
面向 重點 核心 把長內容切成可處理的單位，避免上下文和記憶體超載。 做法 常會加重疊、加入標題資訊，讓切段不會太碎。 注意 切太小會失去上下文，切太大又會塞爆模型。
中英對照與它在 RAG 裡的位置
| 中文 | 英文 | 說明 |
|---|---|---|
| 分塊 / 切塊 | chunking | 把長文件切成適合檢索的段落 |
| 塊 | chunk | 切出來的每一段 |
| 重疊 | overlap | 相鄰兩塊之間刻意重複的部分 |
| 分塊策略 | chunking strategy | 決定怎麼切的規則 |
在檢索增強生成（RAG）流程裡，分塊是文件進入知識庫的第一道加工。它決定了之後檢索能撈到什麼，也就決定了模型能拿什麼來回答。分塊做壞，後面所有環節都救不回來。
四種常見策略與怎麼選
固定長度切分。 每 N 個字元或 token 切一刀。最簡單，但會把句子甚至詞切斷，語意破碎。
依分隔符切分（遞迴切分）。 先試著在段落處切，太長就退而在句號處切，再太長才切字元。這是多數框架的預設，也是實務上的合理起點。
依文件結構切分。 Markdown 依標題層級切、程式碼依函式切、HTML 依區塊切。文件本身有明確結構時，這個方法明顯優於前兩種，因為切出來的每一塊本來就是一個完整單元。
語意切分。 逐句計算嵌入向量，在語意轉折處切開。效果好但成本高，而且對嵌入模型的品質很敏感。
| 參數 | 常見設定 | 判斷方式 |
|---|---|---|
| 塊大小 | 300 到 800 token | 塊大則上下文完整但雜訊多，塊小則精準但缺脈絡 |
| 重疊 | 塊大小的 10% 到 20% | 避免答案剛好被切在交界處 |
一個實務上很有效的補強：把父段落一起帶上。 檢索時比對小塊（精準），命中之後回傳它所屬的大段落（脈絡完整）。這個做法常見的名字是 parent document retriever 或 small-to-big，能同時拿到兩邊的好處。
另一個常被忽略的細節：每一塊都要帶元資料。 來源檔名、標題路徑、頁碼、更新日期。沒有這些，回答時就標不出出處，使用者無法查證，出錯時你也追不出是哪一塊造成的。
情境判斷
Q1（判斷題）： 一篇超長報告要丟給模型，先分塊通常會更好嗎？ → 通常會，因為模型更容易逐段處理。
Q2（判斷題）： 分塊越小就越好嗎？ → 不是，太小會把關鍵上下文切散。
相關術語
常見問題
chunk size 要怎麼選？
要看模型上下文長度、任務需求和資料結構。
可以重疊切塊嗎？
可以，而且常常很有幫助，因為它能保留跨段資訊。
分塊後一定要做摘要嗎？
不一定，但摘要或標題化通常能提升檢索和理解效果。