3.2 文件分塊的必要性

文件讀進來之後，下一步是把它切成一小段一小段，這個步驟叫做分塊（chunking），切出來的每一段叫做一個 chunk。

為什麼要這樣做？不能直接把一整份文件轉成一個向量嗎？

不分塊會遇到的問題

嵌入模型有長度上限

每個嵌入模型能處理的輸入長度有限。超過的部分會被直接截掉，後面的內容根本沒被轉成向量，等於沒有存進去。

一個向量，裝不下一整份文件的所有意思

向量的長度是固定的。一份 50 頁的文件如果只變成一個向量，這個向量只能表達它「大致在講什麼」，每個細節都被稀釋了。使用者問一個細節問題，例如「加班費怎麼算」，比對時就很難從這個籠統的向量找出來。

找到的東西太大，塞不進模型

就算找到了正確的文件，如果把整份 50 頁都交給 LLM，一來可能超過上下文視窗的限制，二來成本高、速度慢，而且模型要在一大堆內容裡自己找答案，容易分心。

分塊解決了什麼

切成小塊之後：

• 每一塊的意思比較單一，向量比較能代表它。
• 檢索可以精準定位到相關的那一小段，而不是整份文件。
• 交給模型的是少量、相關的內容，省空間、省成本。

塊的大小要取捨

塊的大小是分塊最重要的參數，沒有標準答案，要在兩邊之間取捨：

	塊小	塊大
檢索精準度	高，意思集中	低，容易混進不相關的內容
上下文完整性	差，一句話可能被切在兩半，缺少前後文	好，意思完整
交給模型的成本	低	高
向量數量	多，儲存和搜尋成本高	少

可以用一個比喻：塊太小，像是拿一句話去問「這句話在說什麼」，沒頭沒尾；塊太大，像是翻出整本書的一章，只為了找其中一句話。

一個起點

常見的起點是幾百個字（大約一個到幾個段落），再依據資料類型調整：

• 條列式的規定、FAQ：本身就一條一條，可以小一點。
• 論述性的文章、論文：需要完整的推理脈絡，可以大一點。
• 程式碼：通常依函式或類別來切，而不是依字數。

注意　實際最好的大小，要用自己的資料和真實問題去試。第 6 章會講怎麼量化比較不同大小的效果。

切在哪裡也很重要

除了大小，切在哪裡也會影響品質。如果一句話、一個表格、一段推理被硬生生切成兩半，分開的兩塊都不完整，檢索效果就會變差。接下來兩節會介紹不同的切法：先看最簡單的固定大小，再看比較聰明的內容感知方法。