Tokenization 與 Chunking 怎麼做？AI 文本處理與 RAG 分塊指南

在 AI 文字處理裡，很多人把「tokenization」和「chunking」都叫做切分，卻因此在成本、檢索品質與引用正確性上踩坑。兩者其實解決不同問題：tokenization 是模型把文字轉成可計算 token ID 的方式；chunking 是應用程式把長文件拆成可獨立處理、嵌入或檢索的片段。前者通常由你選用的模型與 tokenizer 決定，後者則是資料管線與產品設計的選擇。

若你正在建立 RAG、知識庫問答、文件摘要、客服輔助或長文件分析，真正該問的不是「一段要切幾個字」，而是：使用者的問題需要哪一種上下文？模型實際會消耗多少 token？一個檢索結果能否保留完整意思與來源？當文件更新、權限改變或解析錯誤時，能否重新建立並追蹤每一個片段？把這些問題設計清楚，分塊才會從一個預設參數變成可驗證的系統能力。

Tokenization：模型不是用字數或詞數來閱讀

Tokenizer 會把原始文字處理成模型輸入所需的 token 與 ID。以 Hugging Face 的Tokenizers 文件為例，常見流程包含正規化、預先切分、子詞模型與後處理；模型會依自己的詞彙與規則將片段映射為 ID，並可能加入特殊 token。這表示相同的一段文字，換到不同模型或不同 tokenizer，token 數可能不同。

因此，中文字數、英文單字數、字元數都只能作為粗略估計，不能直接拿來保證上下文不超限或計算成本。數字、網址、程式碼、罕見名稱、表情符號、標點、不同語言混用與格式標記都可能讓 token 比例改變。正式流程應該使用實際目標模型或相容 tokenizer 計算 token，並為系統提示、工具定義、檢索內容、使用者輸入與模型輸出預留空間，而不是把整個 context window 全部填滿。

Chunking：為文件建立可檢索的上下文單位

Chunking 不是模型內部 token 化，而是將大文件拆成能被單獨嵌入、儲存與取回的內容單位。LangChain 的Text Splitters 文件指出，分塊讓大型文件可個別檢索，也能放進模型的上下文限制；可採文字結構、長度或文件結構等策略。最好的切法取決於內容與任務，並不存在一個所有 RAG 專案都適用的固定大小。

例如，政策或說明文件常以標題、段落和條列組織，應盡量保留標題與段落的從屬關係；程式碼比較適合以函式、類別或邏輯區塊切分；HTML、Markdown 與 JSON 則能利用其結構避免把一個物件或章節從中間截斷。若文件本來有清楚的語意邊界，先尊重邊界，再用長度限制作為保護，通常比純粹每 N 個字切一刀更容易得到完整、可引用的結果。

先決定目標，再選擇分塊策略

檢索問答與 RAG

RAG 的分塊目標，是讓真正包含答案的內容能被找回，同時讓模型有足夠上下文回答而不混入太多無關資訊。每個 chunk 應盡量是一個可獨立理解的小主題，保留章節標題、文件名稱、來源連結、版本、日期、存取權限和原始位置。當回答需要引用來源時，這些 metadata 比單純的文字向量更重要：它能讓系統顯示來源、排除過期文件、遵守權限，並在文件更新後追蹤哪些 chunk 必須重新建立。

長文摘要與報告整理

摘要不一定需要將每個小段落各自檢索。對很長的報告，常見做法是先對章節產生局部摘要，再將局部摘要以保留來源脈絡的方式合併。若直接把長文硬切成相同大小，重要結論可能和前提、例外條件或數字定義被拆開，最後得到看似通順但漏掉限制的總結。這類工作要特別測試「是否保留條件與例外」，而不是只看摘要變短了多少。

分類、抽取與表單處理

若任務是抽取固定欄位、判定類別或找出少量關鍵資訊，分塊需要保留欄位名稱、單位、日期與相鄰說明。把欄位值拆到另一個 chunk，會讓模型失去它代表什麼的依據。文件含有多欄資料或視覺排版時，先驗證解析結果是否正確；錯誤的 OCR 或錯置的閱讀順序，即使切分策略完美，也只會把錯誤內容更有效率地送進模型。

Chunk size 與 overlap 不是越大越好，也不是越多越安全

較大的 chunk 可以保留較完整的背景，但可能讓檢索結果混入太多無關內容、增加嵌入與生成成本，並降低精準度。較小的 chunk 比較容易命中單一事實，卻可能把定義、前提和結論拆散。Overlap 的用途是降低邊界被切斷造成的資訊遺失；但重疊太多會製造幾乎相同的內容、提高索引與 context 成本，也可能讓檢索結果被重複段落佔滿。

不要從網路上抄一組固定數字就上線。先用實際 tokenizer 設定可接受的 token 範圍，再依文件結構與問答需求選擇初始值；接著比較不同策略在自己的測試集上的取回率、引用完整度、答案正確性、延遲與成本。若某個答案必須同時看到前後兩段才能成立，與其無限加大 overlap，不如考慮保留父章節、在檢索後擴展相鄰段落，或採用階層式摘要。

每個 chunk 都應保留可追溯身分

一個可用於正式系統的 chunk，不該只有 `text` 和向量。至少要能追溯它來自哪份文件、哪個版本、哪個章節、在原文的什麼位置、何時建立、使用哪個解析器與切分策略、適用哪些存取權限。若有父文件 ID、章節路徑、頁碼或字元範圍，也能在回答時呈現可理解的引用，而不是只顯示一段孤立的文字。

這些資料還能支援變更管理。文件更新時，系統可以定位受影響的段落並重新解析、刪除舊向量或標示版本，而不是在索引中混入新舊內容。權限改變時，也可以在檢索之前就排除不該被目前使用者看到的 chunk。對知識庫而言，來源、版本與權限不是附加資訊，而是答案是否可信與是否合規的一部分。

用測試集決定策略，不用直覺決定

建立一小組代表性問題：有精確事實查詢、有需要跨段落理解的問題、有找不到答案時應明確拒答的問題，也要包括不同語言、長標題、列表、掃描文件和近期更新內容。為每一題標記可接受的來源與必要條件，然後測試不同 chunk 策略能否取回正確證據。除了答案品質，也記錄每題取回的段落數、重複比例、token 使用量、延遲、無答案時的行為與引用是否真的對應原文。

分塊策略一旦調整，embedding 模型、解析器、文件清理規則或 metadata schema 也可能需要重新建立與回歸測試。不要只用單一漂亮案例判斷效果；真正的品質來自不同文件格式、不同問題意圖和更新後資料的一致表現。對重要領域，還應讓熟悉內容的人抽查答案是否省略條件、誤解定義或引用錯誤來源。

常見誤解與實務提醒

第一，tokenization 不等於中文斷詞，也不等於單純以空白切字；token 是模型的輸入單位，實際切法應依 tokenizer 驗證。第二，chunking 不等於把文件任意切小；它應服務檢索、摘要、抽取或分類的目標。第三，向量相似不等於答案正確；仍需保留來源、讓模型根據取回內容回答，並在證據不足時說明限制。第四，重建索引不是一次性工作；文件、解析器、模型、權限與測試集都會變，系統應知道何時需要重新驗證。