前言

昨天比較了不同的 Chunking 策略，今天要更深入探討兩個關鍵參數：**Chunk Size（每段長度）**與 Overlap（重疊長度），這兩個參數的設定，往往比選哪種切分演算法影響更大。

Chunk Size 的取捨

沒有一個「正確答案」，需要依據：

• 使用者問題的類型（簡短事實查詢適合小 chunk，需要脈絡理解的問題適合大 chunk）
• Embedding 模型的最佳輸入長度（不同模型有各自的「甜蜜點」）
• LLM 的 context window 大小（chunk 太大，檢索到的內容塞進 Prompt 後可能超過限制）

Overlap 的作用

Overlap 是指相鄰的 chunk 之間保留一段重複的內容，用意是避免關鍵資訊剛好卡在切分邊界，被硬生生切成兩半、導致語意不完整。

Chunk 1: [.......................重疊區域]
Chunk 2:                    [重疊區域.......................]

一般建議 Overlap 設定為 Chunk Size 的 10%-20%。

實驗設計

為了找出適合我們知識庫的參數，設計一個簡單的實驗：

configs = [
    {"chunk_size": 200, "overlap": 20},
    {"chunk_size": 500, "overlap": 50},
    {"chunk_size": 1000, "overlap": 100},
]

results = []
for cfg in configs:
    chunks = recursive_split(documents, cfg["chunk_size"], cfg["overlap"])
    index = build_index(chunks)
    score = evaluate_retrieval(index, test_questions)  # 用 Day 23 會介紹的評估方式
    results.append({**cfg, "recall": score})

透過固定的測試問題集，比較不同參數組合下的 Context Recall（檢索結果中包含正確答案的比例），找出最適合的設定，而不是憑感覺猜。

觀察與取捨

一般經驗法則：

• 事實型問答（FAQ）：適合較小的 chunk（200-400 字），因為答案通常集中在一小段
• 概念說明型問答：適合中等 chunk（500-800 字），保留足夠上下文
• 需要跨段落推理的問題：可能需要在 Retrieval 階段做「取回相鄰 chunk」的策略，而不只是單純加大 chunk size

小結

Chunk Size 與 Overlap 沒有普世的最佳值，必須透過實驗，針對自己的資料與問題類型去調校。比起憑感覺設定參數，建立一個小型測試集去量化比較，是更可靠的做法。明天我們要來看 Metadata 的設計，這是提升檢索精準度的另一個關鍵。