切割長度應該如何決定
為什麼要切割文章？
在 RAG（Retrieval-Augmented Generation） 系統中，文章內容需要先轉換成向量，存放到向量資料庫裡。
但是：
- 文章太長 → 一個向量塞進去會模糊不清，檢索時相關性降低
- 文章太短 → 太過零碎，語境斷裂，查詢時找不到完整資訊
因此，如何切割文章內容，是影響 RAG 檢索效果的重要關鍵。
常見切割策略
1. 固定長度切割
例如：每 500 個字或 500 個 Token 就切一段。
優點：
- 簡單直接，容易實作
- 可以控制向量數量 缺點：
- 有可能切斷句子或段落 → 造成語境不完整
2. 依語意單位切割
例如：以段落（paragraph）、句號（.）、換行符號（\n\n）當分界。
優點：
- 保持語意完整
- 更接近人類閱讀邏輯
缺點：
- 有些段落過長，還是可能超過模型的 Token 限制
- 切割後的長度不均
3. 重疊切割（Sliding Window / Overlap）
例如：每 500 個字切一段，但保留 50 個字重疊。
優點：
- 減少重要資訊被切掉的機率
- 提高查詢的上下文一致性
缺點：
- 會增加向量數量（儲存成本變高）
長度設定的權衡
在實務上，我們需要平衡：
-
檢索準確度：切太長，向量過於「平均」；切太短，缺乏上下文。
- 效能與成本：切割越短 → 向量數量增加 → Pinecone / 向量庫成本增加。
- 模型限制：不同 LLM 有輸入 Token 限制（Gemini、GPT、Claude 都有上限）。
建議：
- 一般文章：300 ~ 500 tokens
- 技術文件 / 程式碼：150 ~ 300 tokens
- 長篇文章：可以 500 ~ 800 tokens + overlap 50~100 tokens
整理
| 切割長度 | 優點 | 缺點 | 適用情境 |
|---|---|---|---|
| 短 Chunk (100~200 tokens) | 檢索精準、減少不相關資訊 | 缺乏上下文、回答可能片段化、向量數量龐大、成本較高 | FAQ、單句查詢、簡短技術文件 |
| 中 Chunk (300~500 tokens) | 保留語意完整，精準與成本平衡 | 偶爾仍會切斷語境，但影響不大 | 新聞文章、部落格、知識文件（建議預設） |
| 長 Chunk (600~1000 tokens) | 保持完整上下文，降低切斷風險 | 檢索時可能引入過多無關資訊、模糊化 | 長篇論文、故事、需要完整語境的文本 |