Retrieval / RAG / IR · Chunk Size
分塊大小
每個檢索內容塊預計保留的字數或 token 長度。
這個詞真正影響的是內容怎麼被切分、召回、重排與回指，最後能不能穩定組成可驗證的答案。
chunk length塊大小
每個檢索內容塊預計保留的字數或 token 長度。
這個詞真正影響的是內容怎麼被切分、召回、重排與回指，最後能不能穩定組成可驗證的答案。
在這份 SEO 大辭典裡，「分塊大小」被當成 Retrieval / RAG / IR 的核心語彙之一。它指的是每個檢索內容塊預計保留的字數或 token 長度。真正重要的不是背定義，而是理解這個詞會影響你怎麼規劃內容、怎麼安排頁面訊號，以及怎麼把搜尋能見度接回商業目標。
如果你在做 AI 搜尋、RAG 或答案引擎，這個詞真正幫你判斷的是：每個檢索單位保留多少內容才足以回答問題又不會帶進太多噪音。
這頁把 chunk size 放回內容模板與回答品質，而不是單純工程參數。
這組來源不是在做同一種事。官方平台決定能力邊界，研究決定理論與評測語言，基礎設施文件決定檢索怎麼跑，系統文件則把它翻成可部署流程。
官方平台把「分塊大小」放在 每個檢索單位保留多少內容才足以回答問題又不會帶進太多噪音 的能力邊界裡，重點是系統到底提供什麼設定、限制哪些做法，以及哪些行為會直接影響檢索與答案組裝。
拿來校正平台對這個詞的正式定義、設定面與能力邊界。
官方來源學術研究更在意「分塊大小」如何影響召回、排序、可解釋性與評估框架。它提供的是理論與評測邏輯，幫你知道這個詞不是行銷新名詞，而是有可驗證方法的檢索問題。
拿來看這個詞在檢索研究、評測指標與理論語言裡到底代表什麼。
官方來源基礎設施與搜尋引擎文件通常把「分塊大小」寫成索引、查詢、過濾或 ranking pipeline 的一部分，讓你直接看到它在 production system 裡怎麼被實作。
拿來對齊 production retrieval stack 裡的索引、召回與排序實作。
官方來源實務平台文件會把「分塊大小」翻成可部署的工作流，例如 top-k 要怎麼取、哪些欄位要拿來重排、哪些 metadata 要先過濾，重點是讓這個詞真正落地。
拿來把這個詞翻成可部署的工作流、參數與系統治理方式。
官方來源跨來源共識是：「分塊大小」不是抽象 AI 術語，而是直接決定召回範圍、相關性品質與引用穩定性的檢索機制。網站內容要進入答案組裝流程，最終都會被它影響。
差異主要在層級。官方平台決定能力邊界與設定面；學術研究決定評測與理論語言；基礎設施文件決定索引與搜尋怎麼跑；實務平台則把它翻成部署細節與 pipeline 參數。
chunk size 太大會拖低精準召回，太小又會讓答案缺前後文。它直接決定回答是精準引用還是模糊拼裝。
如果你是第一次接觸這個詞，先把下面三個問題讀完，通常就能抓到它和相近概念真正差在哪。
分塊大小指的是每個檢索內容塊預計保留的字數或 token 長度。在Retrieval / RAG / IR的語境裡，它通常用來判斷頁面該怎麼被組織、理解與衡量。
這一頁把「分塊大小」當成 canonical 詞條，頁內也保留常見別名與同義詞。實務上要先看團隊怎麼命名，再看工具與文件如何對應，避免同一概念被拆成多個頁面。
先看它要解的決策問題。對這個詞來說，重點是判斷頁面訊號是否清楚，是否足以支撐搜尋與內容決策。如果沒有先鎖定這一點，就很容易變成有做名詞、沒有做結果。